2020.06.10 Community Meeting

Call-in Details

• Wednesday June 10th 8pm EDT / 5pm PDT | Thursday June 11th 1am BST / 10am AEST
• 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. Joshua Westgard
4. Peter Winckles
5. Simeon Warner
6. Julian Morley
7. Michael Lynch
8. Peter Sefton

Agenda

1. Community updates (introductions, updates, implementations, plans, etc)
2. Editorial updates
   • Releasing 1.0. Requirements to release 1.0
   • Commits since last community meeting
   • Open questions
3. Review of previous action items
4. OCFL Spec
   • Issues
   • Pull-requests
5. OCFL Extensions
   • Issues
   • Pull-requests
6. Next community meeting: July 8, 2020 (second Wednesday of the month) at 4pm BST / 11am EDT / 8am PDT

Notes

• Community updates / Intro
  • University of Technology Sydney is using OCFL and within the objects, ro-crate so its a standard within a standard
  • Index of Filesystems can expose a filesystem; Simeon is thinking about potentially using that to expose OCFL.
• Editorial Updates
  • Looking to release 1.0 at the end of the month
  • Editors are discussing processes for adding to 1.0 changes (e.g. 1.0.1 versus 1.1)
  • Reminder about use cases for OCFL 2.0; particularly distributed storage. Indiana University has some interesting use cases because they have of their method for storing media. Julian has spoken to Brian Wheeler, Rosalyn has a potential upcoming call
• OCFL Spec Issues and PRs
  • Issue #474 is on its way to being completed with PR#478
  • Issue #475 has a number of points that may need to be broken out so we can address some parts in 1.0
  • Issue #393 does it feel like we have enough to do a reasonable first pass at a validator? if we try to get to 100% test coverage for every error codes it means addressing edge cases. are we more likely to impede progress by not releasing? in the validator's readme provide a table of the list of validator codes and identify which ones are validated and which ones aren't.
• OCFL Extension Issues and PRs
  • PR #13 is around versioning extensions
  • PR #12 is an example around a storage hierarchy
  • PR #16 storage hierarchy PR submitted by pwinckles makes some assumptions that may or may not be true. is related to Spec Issue #477 in the spec
• Closing thoughts
  • University of Technology Sydney may run the validator against their OCFL storage root to see what comes up.
  • They are working on an application which is SOLR on top of an OCFL storage root and when its in a good place they'll provide more information to the community.

Audio recording

• 2020-06-10.mp4

New Action Items

• Simeon: Add a table to the readme of the validator making it transparent what error codes we do and don't have tests for.

Previous Action Items

• Neil: Add language specific to extensions, specifically layouts and parameterization. ext-issue-2