Ability to reference a file/datastream outside of an OCFL Object

[zimeon]

Separating this from comments with #27. The file or datastream might be in another OCFL object under the same OCFL Storage Root, or might be somewhere else.

Related to #27 and OCFL/spec#22

[zimeon]

Following #27, marking this out-of-scope for v1, but to consider for v2

[neilsjefferies]

general musing...so not completely thought out,

I can imagine a minor modification to the inventory that adds "inherits from ObjectID" type sections to the manifest. The digests that follow identify paths in other OCFL object(s). Other than that nothing else needs to change. When copying an object, parsing the manifest tells you which additional objects it has dependencies on. It would permit version forking and inter-object deduplication. this does mean that if object versions are not stored as a single units then each version has a new ID - this is not necessarily a bad thing.

...this might also be adapted to include "Inherits from external_storage_path" in some form.

[awoods]

Proposed for V2

[eocarragain]

See discussion of how Wellcome use the bagit fetch.txt convention to allow referencing of files/datastreams outside the object: https://stacks.wellcomecollection.org/how-we-store-multiple-versions-of-bagit-bags-e68499815184

In their implementation, they add constraints to fetch.txt:

• you can include a fetch.txt, but it can only refer to files within the storage service.
• a fetch.txt can only refer to files in previous versions of the same bag.