spec
spec copied to clipboard
Should state how OCFL can work with Object Stores
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.
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
Refer to #522 #526 #605 #521 for relevant user experiences/comments.