Fedora 4 Audit Service: Meeting 2015-03-19

[Andrew Woods]

Hello All,
Thank you for your input to-date. Development will begin two weeks from yesterday, on March 30th [1]. Our next Audit Service meeting [2] will be this coming Thursday (March 19th) @3pm ET.

Like other areas of Fedora4 development, I believe the following guiding principles should inform design:

1) Fedora4 features should be an implementation of LDP or an optional extension (ideally an existing standard)
2) Fedora4 features should favor existing tools over custom code
3) Fedora4 features should establish integration patterns where an implementation is not a part of the core code

In the absence of another ruler, I believe we should measure the success of the resulting implementation against collectively defined requirements.

I have distilled the initial requirements from the meetings and wiki on the Audit Service Design wiki page [3] (also inline below). Please review and comment on these candidate requirements, and offer additions/modifications. Do not be shy in commenting on the low-hanging redundancy that should be consolidated.

==========

Functional - Write/Import

==========

1) Audit service MUST automatically record who updated which resource when and with which action

2) Audit service MUST be able to include/import events that were performed external to the repository

3) Audit service MUST be able to purge events (??)

4) Audit service MUST be RDF-based, and use PATCH (??) semantics for updates

5) Audit service MUST store logs separately or protected separately from the repository resources themselves

6) Audit service MUST import events with RDF triples drawn from the specified ontologies (??)

7) Audit service MUST ensure that all events minimally include the following information:

7a) Event Agent

7b) Event Date/Time

7c) Event Activity

7d) Event Entity

==========

Functional - Read/Export

==========

1) Audit service SHOULD support map-reduce-style analytics

2) Audit service MUST provide evidence of fixity checking on a "routine basis"

3) Audit service MUST support dissemination of event/audit information

4) Audit service MUST be able to export full logs in RDF format

5) Audit service MUST service queries that vary by:

6a) Single or all resources

6b) Date range

6c) Event type

6d) Agent

7) Audit service MUST provide a single search endpoint for all repository resource-related events

8) Audit service MUST provide a SPARQL-Query search endpoint

==========

Non-Functional

==========

1) Scale?

2) Security?

3) Performance?

Regards,

Andrew
[1] https://wiki.duraspace.org/display/FF/Production+Sprint+Schedule#ProductionSprintSchedule-FeatureSprints

[2] https://wiki.duraspace.org/display/FF/2015-03-19+-+Audit+Service+Planning+Meeting
[3] https://wiki.duraspace.org/display/FF/Design+-+Audit+Service