Skip to content
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

Use external identifiers in place of digests to act as keys within the manifest #47

Closed
zimeon opened this issue Oct 30, 2023 · 4 comments
Labels
Confirmed: Out-of-scope Use case will not be included in the upcoming version of the spec or implementation notes.

Comments

@zimeon
Copy link
Contributor

zimeon commented Oct 30, 2023

Some preservation systems assign globally unique ids to content files. These could be used as keys within and OCFL Object manifest to link metadata, state and fixity information together, in place of the current use of a digest. Fixity would then only be in the fixity section which would then be mandatory.

@zimeon zimeon added the Proposed: In-Scope Use case is up for discussion and may change the spec, implementation notes, or become an extension. label Oct 30, 2023
@rosy1280
Copy link
Contributor

Feedback on Use Cases

In advance of version 2 of the OCFL, we are soliciting feedback on use cases. Please feel free to add your thoughts on this use case via the comments.

Polling on Use Cases

In addition to reviewing comments, we are doing an informal poll for each use case that has been tagged as Proposed: In Scope for version 2. You can contribute to the poll for this use case by reacting to this comment. The following reactions are supported:

In favor of the use case Against the use case Neutral on the use case
👍🏼 👎🏼 👀

The poll will remain open through the end of February 2024.

@srerickson
Copy link

The utility of manifest keys (in OCFL v1 ) is to uniquely identify content in a way that is independent of the underlying storage architecture. Under this proposal, the key would become an opaque unique identifier for linking "metadata, state and fixity information together". The key may originate in the external storage system, but an OCFL implementation can't really take advantage of that without adding the storage system as a dependency (i.e., for the purposes of validation), which seems undesirable. In addition, using identifiers to link different components of the inventory adds to the inventory size. A better approach might be structure the inventory.json in a way that makes these linkages unnecessary (here is an example).

Perhaps a concrete example would help address these concerns.

@je4
Copy link

je4 commented Nov 4, 2023

External identifiers could interfere with the idea of deduplication. There could be different identifiers for files with identical content. Therefore, the external identifier is not linked to the "content of the file", but to the "name of the file".

@rosy1280 rosy1280 added Confirmed: Out-of-scope Use case will not be included in the upcoming version of the spec or implementation notes. and removed Proposed: In-Scope Use case is up for discussion and may change the spec, implementation notes, or become an extension. Component: Specification labels Feb 29, 2024
@rosy1280
Copy link
Contributor

At the time of this comment the votes tallied to -2.

The recommendation from editors is if the need to record external identifiers is necessary, it should be implemented as an extension.

@rosy1280 rosy1280 closed this as not planned Won't fix, can't repro, duplicate, stale Feb 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Confirmed: Out-of-scope Use case will not be included in the upcoming version of the spec or implementation notes.
Projects
None yet
Development

No branches or pull requests

4 participants