Call-in Details

• Wednesday August 9th 8pm ET / 5pm PT
• Thursday August 10th 12am GMT / 10am AEST
• Convert to your time zone

Zoom Link: https://emory.zoom.us/j/7074635164?pwd=SExsZ1NwYjVlNy9ZWHJHZ09BYXVxQT09

Attendees

1. Peter Sefton (UQ)
2. Alvin Sebastian (UQ)
3. Moises Sacal Bonequi (UQ)
4. Josh Westgard (UMD)
5. Andrew Woods (Harvard)
6. Rosalyn Metz (Emory)

Agenda

1. Welcome
   • Introductions: name, institution, interest in OCFL
2. Community Listening Sessions
   • Starter Questions
     • How are things going with implementing and conforming to version 1? Are there specific use cases that you feel need to be addressed or clarified?
       • it should be cheaper to find an id of an object (i.e., object id should be a file at the top root of the object)
     • How do you imagine your storage needs evolving over the next decade; what are you concerned about? How might OCFL help address these issues?
       • Discussion around object modeling and how OCFL impacts them. Towards a Generic Research Data Commons: A highly scalable standard-based repository framework for Language and other Humanities data and
       • One of the institutions is looking to move to an S3 backed repository; moving files is cumbersome so still looking at ways to limit it.
     • What issues are you concerned about when it comes to versioning your data? How might OCFL help address these issues?
       • versioning should be optional -- some believe that versioning is expensive. the mutable head extension is one solution to this problem (potentially).
       • flexibility of versioning is still needed. being able to turn it on and off. or perhaps a place to put ephemeral information (e.g., a list of objects that are part of the collection object, however it's also nice to have that list and be able to see when and how it grew).
   • Other Questions
     • Can an object id be changed? no https://ocfl.io/1.1/spec/#inventory-structure
     • How will it work when we change to version 2.0, the expectation is that the client should be able to handle objects that conform to version 1.0 of the specification and version 2.0 of the specification. we don't have a way of versioning the namaste file.
     • Is there a text version of the spec? The spec is in markdown and you can download it easily via the github repository version 1.1 text
     • Question about how to use the fixity block. Retaining multiple fixity values for files is possible, there is also discussion in the implementation notes about how to migrate to new hashes.
     • It is difficult to understand the spec, especially when you're new to the subject area and don't understand our weird conventions and why we do it that way. Putting more notes or better merging the spec and implementation notes might help. but how because maintaining a spec is hard and too many notes makes that job hard.
3. Next community meeting: Wednesday Sept. 13th 4pm GMT / 11am EST / 8am PST | Thursday July 14th 1am AEST Convert to your time zone

Recording

• Recording

New Action Items

• action item here

Previous Action Items

• Rosalyn to add registered extensions to the next editors meeting