*** This version of Confluence is for testing only and contains a copy of content from June 29th 2026. No changes will be preserved. ***
...
- Digital collection identifiers
- A long standing issue in the presentation of our digital collections is the lack of a reliable identifier
for the collections themselves. Collections move to new machines, collections change their delivery platform,
and collections change their default behaviors. We need to be able to locate collections reliably over a long period of time and discover aspects of collections for interoperating with other collections.
- A long standing issue in the presentation of our digital collections is the lack of a reliable identifier
- Persistent IDs for digital preservation preservation
- We are working on preserving the digital objects in two large collections, the Euclid journals and the arXiv.org preprints. In general, we can view the objects as having at least one content file and an object descriptor file containing metadata about the object. Most digital objects contain multiple content and metadata files. We need to be able to identify and locate the files for a long time, regardless of where they are located. Rather than changing the metadata in the descriptor file every time a file is moved-we would like to create persistent identifiers that can be mapped to the files' current locations.
- The number of component files to be preserved will be several times larger than the number of digital objects. With processing efficiency in mind, we would prefer a solution that will allow us to resolve the identifiers locally, without going out over the internet for each request for resolution.
- The digital objects' component files in our preservation system will not be directly accessible to the public; access will occur through a gated interface. The persistent identifier mechanism we use should be able to be produce identifiers that are private and not discoverable.
- We are working on preserving the digital objects in two large collections, the Euclid journals and the arXiv.org preprints. In general, we can view the objects as having at least one content file and an object descriptor file containing metadata about the object. Most digital objects contain multiple content and metadata files. We need to be able to identify and locate the files for a long time, regardless of where they are located. Rather than changing the metadata in the descriptor file every time a file is moved-we would like to create persistent identifiers that can be mapped to the files' current locations.
Requirements for an implementation
- We don't want to break any system currently used at CUL that uses persistent identifieres, such as the PURL server. It should be backward compatible.
- Every PID should be globally unique.
- PIDs must be globally resolvable, resolvable from anywhere.
- On the other hand, some PIDs must be optionally resolvable only within a constrained environment. In other words, the system must have the ability to make PIDs private, not discoverable. For example, an archiving system should be able to restrict access to low-level components of complex digital objects.
- The system should be able to ensure confidentiality. It should define a mechanism for client authentication and authorization to ensure data integrity and authority control.
- The system shoud should not have dependencies on external systems in order to resolve local PIDs. Reliance on the network outside CUL for every resolution request would introduce potential latency problems, slowing down all our systems.
- PID should be free of location semantics. For example, a file originally stored on a server as "/some/graphic/collection/file1234" should not be mapped to a PID like "cul:graphics_collection_00000001234." If ownership of the file changes, or location changes, or if the file is reassigned to another collection, the PID would have misleading and incorrect meaning. Any relationships among files, collections, and owners should be documented in metadata.
...