2020.11.11 Community Meeting

Call-in Details

• Wednesday November 11th 4pm GMT / 11am EST / 8am PST | Thursday November 12th 3am AEDT
• https://lyrasis.zoom.us/my/vivo1
• or Telephone:
  • US: +1 669 900 6833 or +1 646 876 9923
  • Canada: +1 647 558 0588
  • Australia: +61 (0) 2 8015 2088
  • United Kingdom: +44 (0) 20 3695 0088
  • Meeting ID: 812 835 3771
  • International numbers available: https://zoom.us/u/MO73B

Attendees

1. Rosalyn Metz
2. Andrew Woods
3. David Wilcox
4. Peter Winckles
5. Ben Cail
6. Neil Jefferies
7. Simeon Warner

Agenda

1. Volunteer Notetaker?
2. Community updates (introductions, updates, implementations, plans, etc)
3. Review of action items
4. The specification
   1. "thoughts on OCFL over S3" - issue#522
   2. "sidecar file naming and format" - issue#520
5. Extensions
   1. Recent updates
   2. "Publishing released versions of extension 'specification'" - issue#37
   3. "Add 'Optional Extension Initializer'" - pull-36
6. Next community meeting: Wednesday December 9th | Thursday December 10th
   • Do we want to shift the time?

Notes

Community Updates

1. Ben Cail: Brown planning on moving into production with OCFL in early 2021
   1. Using dcfl-java library
2. OCFL export is on the roadmap for Invenio
3. JROST conference coming up
   1. Rosalyn leading a discussion session with Josh Hedro at IIIF on open standards and why they are important

Specification

1. Two issues to discuss
   1. "thoughts on OCFL over S3" - issue#522
      1. Is this a use case rather than an issue? Looking for community best practices. We can paraphrase this as a use case rather than moving the issue over
      2. Over 100TB of data
      3. Just use a bucket as a storage root? S3 will scale a bucket based on usage, so lots of data or a usage spike might not perform well until more resources are added, but this is only a problem if usage is spikey.
      4. Possible to create performance hotspots in a bucket but it is unlikely to be an issue
   2. "sidecar file naming and format" - issue#520
      1. If there was a fixed name for the inventory file it would be easier to find, particularly in object store implementations
      2. Can we provide a hint with a storage-root level statement via an extension?
      3. To be discussed at the next editors meeting

Extensions

1. Recent updates
   1. There have been a couple changes to parameters:
      1. They are now assigned types directly calling on JSON types.
      2. What used to be range is now a constraints field - the guidance is "whatever makes sense for the extension you're creating"
   2. The config file now always has the same name: config.json
2. "Publishing released versions of extension 'specification'" - issue#37
   1. Release versions of the extensions specification (i.e. the README)
   2. Add a field to extension definition headers that notes the version of the extensions specification to which an extension conforms, similar to the "Minimum OCFL Version" header field.
   3. Editors to take this up and deal with the specifics
3. "Add 'Optional Extension Initializer'" - pull-36
   1. Need to retain compliance with 1.0 spec but also directly access files in OCFL without doing a lot of rummaging around
   2. Establish a fixed name for the first extension that should be read when examining the contents of the extensions directory
   3. This could support an extension that is designed to organize the other extensions
   4. May choose a different name than init but otherwise this will move ahead

Next community meeting: Wednesday December 9th | Thursday December 10th

1. Due to daylight savings changes we'll need to choose a new time
2. Proposal to set the time at 10am AEDT / 6pm EST

Audio recording

• 2020-11-11.mp4

New Action Items

• Andrew to paraphrase issue#522 as a use case
• Rosalyn to create a ticket in the use case repository about Google storage

Previous Action Items

• None