-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should state how OCFL can work with Object Stores #372
Labels
Implementation Notes
Tickets to be included in implementation notes
Milestone
Comments
Decided: there is language in the introduction of V1 that addresses this. We will look at this later for V2. |
Current implementation notes https://ocfl.io/1.1/implementation-notes/#an-example-approach-to-updating-ocfl-object-versions are written in the language of filesystem implementation. There is opportunity to be more helpful for those implementing over object stores |
This was referenced Feb 2, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Increasingly people are being pressed to use things like S3 for "preservation". We therefore need to explicitly say how OCFL can work with them. I know the detail has to be worked out for V2 but there are probably three points we can make right now:
Abtraction between logical and storage paths in inventories allows logical file paths to be mapped to object ID's.
Choice of UID to OCFL Object path mapping allows whole OCFL objects to have a flat mapping for whole object storage.
Inventory based versioning is a higher level abstraction for complex objects rather than per-component versioning.
However, I don't think OCFL can promise to solve all the problems of choosing such an approach. I'm not sure recoverability from a raw set of S3 objects is possible.
The text was updated successfully, but these errors were encountered: