-
Notifications
You must be signed in to change notification settings - Fork 13
2025‐02‐13 Implementers Meeting
- Arran Griffith
- Becky Andresen
- Andrew Woods
- Rosalyn Metz
- Thomas Edvardsen
- Tom Wrobel
- Peter Winckles
- OCFL Version 2.0
- Requirements to implement
- Tool Implementation - At least two tools (validators, libraries, etc.) must implement three of the four new features, ensuring every feature is implemented at least once within tools.
- Updated Fixtures and Validators - All fixtures, validators, and error messages must address the new features in the specification.
- Community Feedback - We will give each alpha and beta release phase at least six months to gather and incorporate community feedback. For comparison, OCFL 1.0's alpha (0.1) and beta (0.3) releases lasted approximately nine and thirteen months, respectively.
- Features:
- Flagging Features at the Storage Root
- Tombstones
- Package Per Version
- Content Linking (Object Forking)
- Requirements to implement
OCFL v2.0
- Editors are thinking of doing an alpha version - possibly coming together to write in summer time
- But what are people interested in implementing in terms of features?
- And what does this mean about tools?
- Editors haven’t initiated anything specific at this moment.
Oxford - Purge file completely from OCFL object is a priority for them - Have a strong use case for this - Want to remove the object completely plus its version history - This would be covered in the Tombstones features - “How do we handle terabyte files” is a concern for us too, but Fedora can manage that with files by reference. It would be interesting to implement that in OCFL - Question for Fedora: Files by reference is technically implemented in Fedora 6 but how is it implemented in the OCFL? - In f4, File by Reference allows you to store a file outside of Fedora, but reference it in Fedora. The question is is this still available in Fedora 6, and how is it referenced in the OCFL?
Thomas Edvardsen
- Package per version conversation
- Haven’t implemented OCFL yet because they want this feature first
Harvard
- Interested in all the features
- But specifically want to be able too support file deletion
- Tombstone
- Squashing versions instead of full deletion - more interested in the current state of the object
- Less interested in Content Linking
- Not likely to use package per version
UW Madison
- Less interested in Content Linking and Package per Version
- May have a use case for tombstone, but this may be handled by their preservation service already
- Want to ensure that v2.0 is completely compatible with V1.0
Why v2 release without breaking changes?
- The standard is kind of a paradox because theoretically there should never be a breaking change
- Andrew: “you could create a version 2 inventory that is invalid in a v1.0, but v1.0 inventories would be valid in v2.0”
- All v1.0 objects will continue to be valid through the lens of version 2
Questions and conversations around ownership of the libraries and how/who can maintain and continue developing OCFL-java
- Peter’s time is becoming increasingly restricted, and while he doesn’t want to abandon it, he can’t commit to being solely responsible for it any more
- How can we support implementing the features of v2
Should be looking to this community of users to grow
- Need to start considering how to roadmap and engage community
- Other possible users of OCFL-java - https://github.com/OCFL/ocfl-java/network/dependents?package_id=UGFja2FnZS0zNzIyNzE5NzY2
How far along is the spec actually?
- Hope is that by summer (possibly) there may be an alpha
- If that is the case, then we should consider ways to bring more people to this meeting
- None
- Peter is planning to do a round of dependency updates and will release in the coming weeks
- Meetings occur quarterly on the 2nd Thursday of the month