...
In Review
Expand Jira server DuraSpace JIRA jqlQuery filter=13100 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 Please squash a bug!
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 Tickets resolved this week:
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 Tickets created this week:
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
Notes
Part I
- Announcements:
- Good, well attended meeting in Switzerland. Interest in Fedora 6.
- Value prop of using Valkyrie with/without Fedora
- Fedora 4 & 5 about standardization
- Some performance issues
- Fedora 6 adding more preservation minded features
- Transparent, human-readable filesystem
- Rebuildability from FS
- Why better to use Fedora over Preservica?
- Preservica not active storage
- Fedora offers standard middleware integrations: notifications, robust api
- Fedora 4 & 5 about standardization
- Definition of Fedora rebuild
- Ability to recreate everything needed to run Fedora based on the files on disk (Daniel's exact words should be added here)
- Support unversioned content?
- Some use Fedora to author content over a period of time. They want to version when the content is ready and not have a version of every change.
- Clean version set
- Reduce bloat on disk
- Fedora currently offers the ability to mutate objects and create fixed versions. In OCFL, everything is immutable. How to reconcile this, and maintain Fedora functionality.
- Store everything in OCFL and make version logical structures on top of this
- Store only immutable content in OCFL
- Mutable content stored within OCFL's 'deposit' directory
- Fedora maintains mutable content
- Automatically periodically "flush" staged changes to OCFL
- OCFL versions would not be meaningful – requires logical versions
- There's a possibility that an object could never have a version. Is this okay?
- Auto-versioning should be toggle-able
- Islandora controls versioning – auto-versioning would be off by default
- Where does unversioned content live?
- OCFL 'deposit' directory is intended for short-lived version creation and not long-term storage
- OCFL 'deposit' directory space is out of spec and is up to the individual library to use it as it will
- Currently, you can delete version markers, but this is not possible if you store version markers in OCFL. Perhaps store version markers outside of OCFL?
- All changes stored in OCFL
- Fedora managed version file that maps OCFL versions to logical versions. This mapping is outside of the OCFL object.
- Pros about versioning every change in OCFL
- Easier to implement
- Easier to reason about
- Rebuildability is easier
- Cons about versioning every change in OCFL
- Binary bloat
- Inventory bloat
- OCFL versions are not presented in the API only Fedora versions are
- Some use Fedora to author content over a period of time. They want to version when the content is ready and not have a version of every change.
Part II
- 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
...