Individual version directories can be stored external to the OCFL object

[ahankinson]

A library has limited on-site storage and is using an external provider with an object store for hosting the majority of its bitstreams. The OCFL Object inventory should be able to accommodate multiple remote storage locations for a version directory to allow for multi-site, off-site storage with the on-site inventory being used for local lookups.

There can be multiple storage roots, and these can be a mixture of both local and remote.

Related to #10

See: OCFL/spec#22

[ahankinson]

Additionally, multi-site storage can be used to provide distributed content resolution, e.g., distributing content to multiple cloud providers while still maintaining a local copy.

[zimeon]

It seems that putting storage location information INTO the inventory would break the idea that the OCFL object is an archival object because you'd have to change it when you change/migrate storage (something we know happens every few years).

If we want to add storage management into the scope of this work then I think we need a layered approach where there is still a core notion of an archival object that doesn't know where it lives (and thus doesn't change when it moves) at the core, and at a higher layer some notion of locations and distributions.

[zimeon]

... it could be that the core archival object becomes a version of a URI identified thing so that versions can live in different places. Rules from completeness and reconstitution may become complex however.

[ahankinson]

I think this comes from the idea that the 'archival object' is multi-homed; that is, redundant resolution endpoints are part of the process of archiving it.

Point taken about the 'change/migrate' and the associated updates to your objects, though.

[zimeon]

I note similarity with fetch.txt in bagit, and also idea of Complete and Valid bags

[ahankinson]

F2F 2018.09.05: This is out-of-scope for v1; it may be in-scope for v2.

[zimeon]

Per 2018-09-05 comment, reconsider for v2

[rosy1280]

potentially a sub-use case of #39

[neilsjefferies]

Editors 2023.09.22:
Replication is outside the remit of OCFL since it concerns objects in motion and logically sits above the storage root conceptual level.
Storage roots should be internally consistent and complete so sharding object versions between them should be avoided.
Other cases are covered by #39