-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
Feedback on Use CasesIn 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 CasesIn addition to reviewing comments, we are doing an informal poll for each use case that has been tagged as
The poll will remain open through the end of February 2024. |
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. |
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". |
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. |
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.
The text was updated successfully, but these errors were encountered: