Time/Place

Time: 11:00am Eastern Time (US)

Please see calendar invite for Zoom link.

Attendees

1. Andrew Woods
2. David Wilcox
3. Danny Bernstein 
4. Thomas Bernhart
5. Jon Dunn
6. Raman Ganguly
7. Scott Prater
8. Ben Pennell
9. Peter Winckles
10. Jennifer Gilbert
11. Doron Shalvi
12. Jared Whiklo
13. Robin Lindley Ruggaber
14. Este Pope
15. Mark Jordan
16. Dan Field

Agenda

Open development questions

1. To what extent should Fedora 6 support vanilla OCFL? i.e:
   1. Do we value Fedora being able to run on top of vanilla OCFL? - in a read-only fashion? in a read/write fashion?
   2. Do we value a post-Fedora OCFL that is not peppered with Fedora-specific system metadata?

Use cases

1. As a systems integrator, I would like a simple GET/PUT HTTP server over OCFL
2. As a Fedora 3 repository manager, I would like to export my content as vanilla OCFL
3. As a repository manager, I would like to bring my vanilla OCFL into Fedora
4. As a digital preservationist, I would like to keep the OCFL created by Fedora but stop using Fedora

Context

1. In order for Fedora to manage repository content, Fedora-specific system metadata is required (caveat for vanilla OCFL)
2. 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
3. Currently, Fedora segregates this system metadata into its own directory (".fcrepo/") within the OCFL object

   1. What system metadata are we exactly talking about?

      Click here to expand...

      # 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":
      ...

   2. Structure and location of Fedora system metadata in an OCFL object

      Click here to expand...

      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? 
• 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