...
Attendees and availability:
Agenda
- Discuss specific concerns in depth with Editors
- Identify method for moving forward
- Discuss how to message to Fedora Steering and Leaders
Notes
- Context Setting
- After initial design meetings (VA Beach): content would be pushed into OCFL when a version is created, because that's immutable (which lines up with OCFL).
- Stuff waiting for OCFL would be co-located at the object root; but the spec was changed to have it at the storage root; question came up about whether or not there is a need to have a second storage environment with content outside of OCFL.
- Community concerns: stuff will be outside OCFL.
- Well maybe we can put everything in OCFL, even things that are un-versioned. Which would mean that you could end up with thousands of versions. There are storage issues related to this because the inventory.json file grows rapidly with lots of versions.
- Considerations: Most recent version is mutable; and once a new version is created, the past version is written to OCFL and the new version now becomes mutable.
- Diving into concerns around stuff being outside OCFL.
- People who use Fedora and never use the versioning mechanism, then content may never end up in OCFL.
- How does this impact Fedora 3?
- Transactions - as people are making changes they are staged and not complete, this would not be in OCFL.
- Anything they have committed to Fedora should be preserved.
- Technically the spec doesn't describe a deposit directory <validate this>. And because of that the deposit directory is out of spec, which means the version you are creating is not in OCFL.
- Is it possible that if we make the most recent version mutable we are breaking something else.
Options to consider:
- Change the spec to support a Mutable HEAD. A Mutable HEAD is valid OCFL (inventory.json etc), but should be ignored by replication. The spec should make clear that the Mutable HEAD is not at rest.
- Specify the contents of the /deposit directory in a separate RFC.