2019.11.13 Community Meeting

Call-in Details

• 4pm BST / 11am EDT / 8am PDT
• 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. Andrew Woods
2. Ben Cail
3. David Wilcox
4. Peter Winckles
5. Joseph Rhoads
6. Andrew Hankinson

Agenda

1. Community updates (introductions, updates, implementations, plans, etc)
2. Latest updates on "extensions"
   • Comments on the general mechanism?
   • Comments on the "mutable-head" resolution?
3. Issues
   • "Fixity field structure" #406
   • "Characters allowed in paths" #407
4. Validators
   • Stanford OCFL-Tools
   • Oxford/OCFL validator
5. Next community meeting: Dec 11, 2019 (second Wednesday of the month)

Notes

Audio recording

• 2019-11-13.mp3

Updates

• Fedora sprint is currently persisting to OCFL

Extensions

• Mutable-head is generally fine, from an implementation perspective
• ocfl-java implementation of mutable-head
  • 'revision' directories within mutable-head approach being used for durability
  • Current impl in ocfl-java, deletion of file could leave an empty 'revision' dir
    • Implementation goal for the files within the 'revision' directory to be valid OCFL Objects/versions
    • If there is an empty 'revision' directory, not a technically valid OCFL object

Issues

1. "Fixity field structure" 406
   • Only useful for external tooling using the 'fixity' block
   • Not all files are required to be in the fixity block
   • Requires inverting the fixity block map, to use
   • Interest in keeping datastructures consistent throughout inventory.json
     • ..but only within reason
   • Scenario when everything is correct (all files exist in fixity block and no corruption), using the current structure works
   • We should further consider
     • ACTION: We need to add language addressing incomplete fixity blocks
2. "Characters allowed in paths" 407
   • ACTION: Add language to spec to warn users about problematic characters/sequences
     • Likely appropriate in the implementation-notes, i.e. path length
     • Peter W has a draft list of problematic paths
     • Peter W to add references to restrictions to github issue
     • ocfl-java approach to allow configurable options around whether to throw an exception vs having the software sanitize the paths

Action Items

• We need to add language addressing incomplete fixity blocks - who?
• Add language to spec to warn users about problematic characters/sequences - who?

Previous Action Items

• Neil to contact NDSA group regarding openness of preservation storage in the "Levels of Preservation"