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
The goals for this meeting include:
- Establish shared understanding of Fedora 6's relationship with "vanilla" OCFL
- Gain consensus on expectations/requirements going forward, with respect to Fedora 6 and OCFL
Discussion
- 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.
- We can talk about stripping out .fcrepo directories - but is this a real use-case? Does anyone really need that capability?
- We should likely 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? - likely a schema and cross-walk to other standards is sufficient
- Additional use cases
- Migration from Fedora 6 to a future Fedora (e.g. Fedora 10): will we support this? Will we ensure that there is compatibility going forward between Fedora versions ? YES!
- As a repository manager, I want to add content directly to the OCFL managed by Fedora ("side-load"). Although not discussed, this has previously been noted as a "bulk ingest" use case
- Caveats around Plain Vanilla (PV) 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
- Relationships would not be supported between objects beyond inherent "ldp: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 may add significant complexity
- However because OCFL is immutable don't we need to support the mixed case (The Swirl), no? - unless PV objects are converted into F6 objects. The Swirl would be needed to properly read and serve previous versions of the object
- 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