...
- 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
...
- 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
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