...
- 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).
Outstanding questions
- Do we have general agreement on the following points?
- Fedora should support being layered over vanilla OCFL objects
- In order to provide the value-added features of Fedora 6, Fedora-specific metadata will need to be added to OCFL objects
- Can we support Fedora/OCFL objects that come into Fedora as vanilla, but subsequently have Fedora 6 versions?
Action Items
- Type your task here, using "@" to assign to a user and "//" to select a due date