Time/Place
Time: 11:00am Eastern Time (US)
Please see calendar invite for Zoom link.
Attendees
- Andrew Woods
- David Wilcox
- Danny Bernstein
- Thomas Bernhart
- Jon Dunn
- Raman Ganguly
- Scott Prater
- Ben Pennell
- Peter Winckles
- Jennifer Gilbert
- Doron Shalvi
- Jared Whiklo
- Robin Lindley Ruggaber
- Este Pope
- Mark Jordan
- Dan Field
Agenda
Open development questions
- To what extent should Fedora 6 support vanilla OCFL? i.e:
- Do we value Fedora being able to run on top of vanilla OCFL? - in a read-only fashion? in a read/write fashion?
- Do we value a post-Fedora OCFL that is not peppered with Fedora-specific system metadata?
Use cases
- As a systems integrator, I would like a simple GET/PUT HTTP server over OCFL
- As a Fedora 3 repository manager, I would like to export my content as vanilla OCFL
- As a repository manager, I would like to bring my vanilla OCFL into Fedora
- As a digital preservationist, I would like to keep the OCFL created by Fedora but stop using Fedora
Context
- In order for Fedora to manage repository content, Fedora-specific system metadata is required (caveat for vanilla OCFL)
- Although it is meaningful and self-describing, there is some stakeholder concern around including content in an OCFL object that is in addition to what the user provided
- Currently, Fedora segregates this system metadata into its own directory (".fcrepo/") within the OCFL object
What system metadata are we exactly talking about?
Structure and location of Fedora system metadata in an OCFL object
Notes
Open development questions:
- The OCFL Fedora generates is OCFL compliant.
- There have been stakeholders that have defined "Plain Vanilla" as including only user content - no application specific metadata.
- Migration from Fedora 6 to Fedora 10: will we support this? Will we ensure that there is compatibility going forward between Fedora versions ? YES!
- We can talk about stripping out .fcrepo directories - but is this a real use-case? Does anyone really need that capability?
- It is conceivable that we should specify the meaning of any files in .fcrepo (using JSON Schema or the like) so that future applications (Post Fedora) can make use of the .fcrepo.
- In a post Fedora world, .fcrepo stuff is converted to new application stuff to what extent can it deal with .fcrepo stuff in previous versions.
- We could support exporting to a new OCFL without the ./fcrepo sprinkles.
- Is JSON the right format for the metadata? Should we consider PREMIS xml? Or is a clear specification with a mapping to other formats sufficient?
- Caveats around Plain Vanilla OCFL:
- Fedora could manage PV with certain assumptions
- Discoveries, Observations, Opportunities if we want to support read-write with PV OCFL:
- Assumptions
- OCFL objects not authored by Fedora 6 must be treated as a collection of binaries
- You can add new binaries
- LDP relationships would not be supported beyond inherent "contains" relationships
- binary descriptions would not necessarily exist
- Opportunity
- Supporting this more general use-case would expand the relevance of Fedora
- What do we want to support?
- Supporting Plain Vanilla and Fedora with Sprinkles simultaneously in a single repo would add significant complexity
- However because OCFL is immutable don't we need to support the mixed case (The Swirl), no?
- Assumptions
- The major advantage of OCFL is transparency, not "purity" (ie freedom from any application specific information).
Action Items
- Type your task here, using "@" to assign to a user and "//" to select a due date