...
- David Wilcox
- Andrew Woods
- Nick Ruest
- Mark Jordan
- John Doyle
- Doron Shalvi
- John Rees
- Susan LaffertyEric James
- Michael Friscia
- Unknown User (escowles@ucsd.edu)Bria Parker
- Peter Eichman
- David Chandek-Stark
- Matt Critchlow
- Dr. Arif Shaon
- Charles Schoppet
- Joshua Westgard
- Yinlin Chen
Agenda
- Introduction and topic summary
- Proposed Plan
- Establish common understanding of function of Audit Service
- Brainstorm use-cases
- Compile initial requirements
- Summarize and Post use-cases and requirements
- Iterative meetings, as required
- Set deadline for feedback
- Create strawman design
- Set deadline for feedback
- Confirm commitments
- developer and stakeholders (verification)
- Sprint (Mar 23, Apr 13)
- Proposed Plan
- Use case discussion
- Audit service should automatically record who updated which resource when and with which action.
- Audit service should be able to include/import events that were performed external to the repository.
- Audit service should be able to purge events.
- Audit service should be RDF-based, and use PATCH semantics for updates.
- PROV-O ontology may be better suited than PREMIS.
- Audit service would ideally support map-reduce-style analytics.
- Evidence of fixity checking on a "routine basis", and with logs "stored separately or protected separately from the AIPs themselves" should be available.
- Fedora 4 REST API should support dissemination of event/audit information.
- Workplan and timelines
- Testing and validation
- Questions
Minutes
...
What is an audit service?
- Fedora 3 audit log
- Recording events that affect resources within the repository
- Events may occur within or without the repository
- Not everyone agrees that external events should be included
- Events may occur within or without the repository
- No particular structure or semantics
- Recording events that affect resources within the repository
- Fedora 4 audit service
- Should at least have the minimal features provided by Fedora 3
- Information should be centrally accessible
- Information should be captured in RDF and should be query-able using SPARQL
- Should be a REST-API endpoint
- Need to collect a list of common queries
- Supplementary information can be added to enrich event information
- Ontology to represent event types
- Purpose
- Problem-solving: find out when something went wrong and how to fix it
- Demonstrates to external entities that you are taking care of their assets
- Meeting ISO/TRAC specifications
- Selecting repository content for archiving
- ARL stats
- Internal vs. external events
- Is the scope of this audit service the repository or the resource?
- This needs to be discussed further
Use Cases
- Audit service should automatically record who updated which resource when and with which action.
- Audit service should be able to include/import events that were performed external to the repository.
- Migrate audit logs from F3 to F4 for example
- Audit service should be able to purge events.
- This could be problematic
- Maybe just retaining the most recent version of a checksum for example
- Perhaps certain events can be hidden from queries?
- Audit service should be RDF-based, and use PATCH semantics for updates.
- PROV-O ontology may be better suited than PREMIS.
- Need to do a comparative analysis
- Audit service would ideally support map-reduce-style analytics.
- Evidence of fixity checking on a "routine basis", and with logs "stored separately or protected separately from the AIPs themselves" should be available.
- Fedora 4 REST API should support dissemination of event/audit information.
Next Steps
- Refine use cases
- Compile a set of requirements
- Get commitments for developers and stakeholders
- Development
- Mohamed Mohideen Abdul Rasheed
- Unknown User (escowles@ucsd.edu)
- Need at least one more developer
- Testing/validation
- Matt Critchlow
- Nick Ruest
- Joshua Westgard
- Mark Jordan
- Development
- Will schedule another call after making some progress on use cases and requirements