1. Export all audit events occurred/captured in the repository
This query is expected to return all audit events recorded in a Fedora 4 repository. The query results may be filtered by:
- a specific date range, within which the events occurred,
- a certain type of events,
- a particular user associated with the events, or
- any combination of the above
Example: TBA
2. Export all audit events associated with a resource
This query is expected to return all audit events associated with a specific Fedora 4 resource. As with the query 1, the results of this query may also be filtered by:
- a specific date range, within which the events occurred,
- a certain type of events,
- a particular user associated with the events, or
- any combination of the above
Example: TBA
Additional queries/use cases (based on Unresolved Questions)
- Adding custom/external events
- Deleting custom/external events
1 Comment
Eric James
These example endpoints cover node-centric audit exports very well, and as expressed in today's call could be used for repository wide events too (although what is a repository event? the potientially large superset of every node event? the set of all non-node event?). But Andrew touched on possibly using SPARQL, and I think there is a use case for making SPARQL queries for auditing reports. Something like "get me the uuid and title of all objects exported to Chronopolis in 2014". Once ontologies are in place, I guess this could be done with a SPARQL query to an external triplestore but as an alternative it seems the repository has the potential to something like a database stored procedure where the stored procedure is a SPARQL query that lives as an object at an endpoint like http://domain/rest/path/to/queries/query1?a=Chronopolis&b=2014. Having a slew of customized diagnostic-like-graph-query-objects like this may have general uses beyond auditing as well. In any case didn't get a chance to say it in the call today but wanted to raise the point.