-
Notifications
You must be signed in to change notification settings - Fork 13
2026.03.19 Community Meeting
- Thursday, March 19th, from 12:00 to 1:00 p.m. ET (Convert to your time zone)
- Zoom Link: https://harvard.zoom.us/j/97488417113?pwd=XOUTtAdUlPnu0xbNVGVSuMV7ccSYPg.1
- Andrew Woods
- Ross Spencer
- Seth Erickson
- John Kunze
- Julian M. Morley
- Neil Jefferies
- Simeon Warner
- Welcome
- News from the community
- OCFL Community Engagement Use Case
- Introductions and Open Topics
Prompt: Provide concise summary of this meeting with salient takeaways.
This was an open-ended OCFL community call focused on OCFL v2 progress, implementation concerns, and future-facing topics (AI, testing, sustainability), with side discussions on persistent identifiers and community engagement.
- Movement toward OCFL v2 is the primary driver of current activity.
- Implementers (e.g., Basel’s GoCFL) are actively refactoring to support both v1 and v2, with testing and error handling still evolving.
- Some institutions are waiting for v2 maturity (e.g., packaging support) before adopting or expanding usage.
Implication:
v2 readiness is gating broader adoption and tooling alignment.
- “Error handling” surfaced as an interest area but lacks clear shared direction.
- Strong interest in a language-agnostic test suite:
- Go beyond validation → include operation sequences (create/update/delete)
- Define expected end-state on disk after operations
- Challenge: OCFL defines storage outcomes, not APIs, making automation harder.
Implication:
A standardized behavioral test corpus could become critical infrastructure—especially for:
- interoperability
- onboarding new implementations
- AI-assisted development workflows
- File systems are becoming relevant again because AI agents interact well with filesystem abstractions.
- Ideas explored:
- Mount OCFL objects via FUSE for agent access
- Use read-only + overlay (copy-on-write) for safe AI interaction
- Strong emphasis on:
- Test suites enabling agents to self-validate code
- Tension in cultural heritage community about AI adoption
Implication:
OCFL’s filesystem-oriented design may become a strategic advantage in AI-native workflows.
- Harvard reports successful use of OCFL on S3-compatible storage, including migration workflows.
- Key nuance:
- Requires thoughtful object naming and layout strategy
- Real-world validation example:
- OCFL validation caught data loss during S3 copy, preventing silent corruption.
Implication:
OCFL’s storage abstraction is portable, but operational discipline matters.
- Repeated failures of preservation organizations (e.g., DPN, SPN) highlight systemic risk.
- Skepticism about:
- traditional org structures
- “preservation as a business model”
- ARK Alliance presented as an alternative:
- low-cost, decentralized, no formal entity
- Related ideas:
- blockchain / decentralized storage (e.g., Arweave) as persistence layers
Implication:
There is growing concern that institutional models—not just technology—are the weak point in long-term preservation.
- ARKs can be layered onto existing permalink systems with minimal effort (even “one-line config”).
- Value framed as:
- signaling persistence, not enforcing it
Implication:
Adoption barriers for PIDs may be more cultural than technical.
- Attendance is inconsistent; current cadence may be too frequent.
- Suggestions:
- Move to quarterly meetings
- Add short user showcases (10–15 min) to attract participation
Implication:
OCFL may be “quietly successful” infrastructure—but risks low visibility and engagement.
- Technically: OCFL is stable, useful, and evolving—v2 + better testing are the next major steps.
- Strategically: Its filesystem model aligns well with both cloud storage and emerging AI workflows.
- Organizationally: The biggest uncertainty is not the spec—it’s sustainable ecosystem governance and engagement.
- your action item here
- your action item here