...
- 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?
Expand No Format # all Fedora resources have: "parent":"info:fedora/new", "id":"info:fedora/new/child", "interactionModel":"http://www.w3.org/ns/ldp#BasicContainer", "createdDate":"2020-04-21T16:52:42.757566Z", "lastModifiedDate":"2020-04-21T16:52:42.757566Z", "createdBy":"", "createdDate":"", "stateToken":"A1FAFA3B80B37AD8C1B0CC519ABD30A2", "archivalGroup":false, "objectRoot":true # binaries also have: ... "filename":"notes.txt", "mimeType":"text/plain", "contentSize":282, "digests":[], ... # external content also has: ... "externalUrl":, "externalHandling": ...
Structure and location of Fedora system metadata in an OCFL object
Expand No Format test-object ├── 0=ocfl_object_1.0 ├── inventory.json ├── inventory.json.sha512 ├── v1/ │ ├── inventory.json │ ├── inventory.json.sha512 │ └── content/ │ ├── .fcrepo/ │ │ └── test-object.json │ └── test-object.nt ├── v2/ │ ├── inventory.json │ ├── inventory.json.sha512 │ └── content/ │ └── .fcrepo/ │ ├── empty-txt-description.json │ └── empty-txt.json ├── v3/ │ ├── inventory.json │ ├── inventory.json.sha512 │ └── content/ │ ├── .fcrepo/ │ │ ├── bar.xml-description.json │ │ └── bar.xml.json │ └── foo/ │ └── bar.xml └── v4/ ├── inventory.json ├── inventory.json.sha512 └── content/ ├── .fcrepo/ │ ├── image.tiff-description.json │ └── image.tiff.json └── image.tiff
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
- Assumptions
...
- 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
- 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