-
Notifications
You must be signed in to change notification settings - Fork 14
2025.05.15 Community Meeting
- Thursday, May 15th, from 9:00am PDT / 12:00pm EDT / 4:00pm GMT / Friday, May 22nd, 2025, 2:00 a.m. AEDT (Convert to your time zone)
- Zoom Link: https://emory.zoom.us/j/98034472848?pwd=U6eMrOyE58EecHBdTUoufGAahDqT3q.1
- Simeon Warner (Cornell)
- Andrew Woods (Harvard)
- Neil Jefferies (OPF)
- Sven Schlarb (AIT/E-ARK)
- Josh Westgard (UMD)
- Julian Morley (Stanford)
- Dan Fields (Fedora)
- Seth Erickson (UCSB)
- Becky Andresen (UW-Madison)
- Welcome and Introductions
- E-ARK and OCFL - Sven demonstrated an example repository to the group, illustrating how OCFL can work with E-ARK.
- OCFL v2.0 specification updates - Andrew provides an update on the progress of the next iteration of the specification. The majority of the conversation centered around the recent comments to the package per version use case
OCFL for AIP Repository In the meeting, Sven and Neil discussed the potential of using OCFL to construct data from an AIP repository, eliminating the need for repository migration. They also considered the possibility of making the AIP self-documenting by incorporating the specification into an extension. Andrew raised a question about the need for changes in the E-ARK specification to integrate it with OCFL, to which Sven responded that the E-ARK specification could be the place to explain how they want to use OCFL. Neil added that the AIP is a specification for a particular type of OCFL object, and OCFL describes how to physically instantiate that. They also discussed the idea of versioning within the AIP, with Neil suggesting that it makes more sense to do it at the OCFL level.
Implementing New Solution With OCFL Sven discussed the steps needed to implement a new solution, emphasizing the importance of input from solution providers. Andrew and Neil agreed that the new solution should be able to read from existing repositories, reducing the risk of data loss. Neil mentioned the National Archive in the UK's strategy of storing data in OCFL eliminates the risks associated with a proprietary solution. Andrew confirmed that Harvard's new solution requirements include the ability to read from existing OCFL.
Discussing OCFL V2 and Package Per Version Concerns Andrew led a discussion about the upcoming release of the specification. Seth raised concerns about the use of packaging in the specification, suggesting that the suggested language could be potentially confusing. Neil agreed with Seth's concerns and indicated that the specific field could be removed if it's not necessary. The team decided to continue discussing the specification and its components, focusing on simplifying and clarifying the language.
Preservation and Packaging Solutions The team discussed the challenges and potential solutions for implementing a preservation infrastructure that can handle both small and large files. They acknowledged that a package per version could lead to inefficiencies and divergence between implementations. The team also discussed the need for a system that can handle corruption and deletion, and how this could interact with packaging. They agreed to explore these issues further and potentially revisit the packaging approach at a later time. The team also mentioned their plans to attend the Open Repositories conference.
- your action item here
- your action item here