...
- What is "auto-versioning"?
- On close of Fedora transaction an OCFL version is created – this happens regardless of whether or not auto-versioning is enabled
- Auto-versioning on: Fedora tag automatically created for every OCFL version
- Auto-versioning off: No Fedora tag created
- Absent a tag file that describes Fedora versions, OCFL versions are exposed
- Counter-prop: No auto-versioning. All Fedora versions must be manual.
- Cannot support tagging old OCFL versions with Fedora versions
- Concerns about exposing OCFL versions through Fedora APIs – don't want Fedora to be tied to OCFL
- How does this work when importing from old versions of Fedora?
- Fedora 4 & 5: can the versions be replayed?
- Fedora 4 → 5: Export 4, run transform, Import 5
- Fedora 5 → 6: Export 5, run transform that produces OCFL, point Fedora 6 to OCFL
- Fedora 3 → 6: Conversion of Fedora 3 files on disk to OCFL, point Fedora 6 to OCFL
- Transactions
- Transactions at the object level are do-able, but across multiple objects is trickier. May not need to implement multi object transactions.
- Bound to an archival group. Don't allow multi object transactions across different archival groups.
- Transaction endpoint exposed for every OCFL object
- Cannot make changes to objects out of scope of original transaction.
- How do you open a transaction for a new OCFL object?
- Create an empty object, open a transaction, update object, close transaction – would not remove the empty object on rollback
- Why limit transactions to just one object?
- Multi-object OCFL transactions are hard to implement
- Something in the import/export group for mapping to archival groups
Actions
- Aaron Birkland to look explore notion of OCFL client with database as authoritative metadata source + asynchronous writing of the inventory.json file
- Peter Eichman and maybe Ben Pennell to make recommendations re transaction side car specification.
- Andrew Woods will look into java 11 transition
...