...
- Create a REST API endpoint for audit events attached to each resource, which allows creating external events and retrieving all events
- Update the repository to create audit event records in this container for internal events
- Create configurable option to allow or disallow deleting events in the repository
- Make sure that other repository functionality is not impacted by enabling or disabling in-repository audit event persistence
- Document end-to-end recipe for configuring event service with in-repository audit event persistence
Phase 2 Revised
Instead of creating a new REST API, we could simply create a container named, e.g., "audit" within any container. External events could be posted there using the existing LDP API, and we would need to update Fedora 4 to do that automatically for internal events. Much of the machinery needed to do this is already in place as part of the JMS module which currently listens to JCR events emits JMS events for all repository updates. We could either update the JMS module to also create audit nodes, or create a separate module just for listening to JCR events and creating audit nodes.
- A separate module has the advantage of being completely decoupled from the JMS module, which is particularly desirable for an optional module.
- Updating the JMS module has the advantage of being a smaller update to existing code, and making it easier to suppress JMS events related to creating audit nodes.
RDF Vocabulary
Following the Audit Service PROV-O vs PREMIS guidelines, a typical event encoded in RDF would look like this:
...