DDR Identifier documentation - DEPRECATED

Purpose of this document: This document lists identifiers used by the Duke Digital Repository (DDR), DukeSpace, and the Research Data Repository (RDR), and defines how they function within the systems.

Out of scope: External identifiers not recognized by the system or stored in explicit metadata properties.

REQUIRED FOR ALL REPOSITORY OBJECTS

UUIDs (id): Internal identifiers created by the DDR application. These will change with system migrations. UUIDs are generally not visible to end users, except that they are used to construct URLs for all DDR objects that aren't assigned a Local ID (see below).

ARKs (ark): Automatically minted for every object upon ingest into the DDR and PDR (through the EZID service). The ARK is the permanent identifier for the object and is intended to persist regardless of the repository system used. The ARK is used to construct the permalink to the object. An ARK may be created for any materials, there are no metadata requirements, and there is no requirement that an ARK be permanently resolvable.  

Example: ark:/87924/r49g5j97m, which is made actionable by prepending the address of the repository link resolver: https://idn.duke.edu/ark:/87924/r49g5j97m

Handles: Created automatically for all objects by the DSpace system (dukespace.lib.duke.edu), handles function as the permanent URLs to those objects, and are included in the public interface as citation links.

Example: http://hdl.handle.net/10161/14575

REQUIRED IF APPLICABLE OR OPTIONAL

DOIs (doi): DOIs are unique identifiers widely recognized as the standard way to cite digital academic materials.  DOIs will be assigned only to objects ingested and preserved in the RDR per our agreement with CrossRef, our DOI provider. DOIs are currently minted through CrossRef by the ingester via a feature in the RDR UI.. DOIs are reserved for scholarly works that expect to be cited, are issued only to objects for which there is a commitment to persistent access, and impose a minimum metadata requirement to ensure the integrity of the DOI system. Currently, the Research Data Repository is the only platform using DOIs, and DOIs are minted at the collection level for every collection at time of ingest unless the data collection has already been assigned a DOI from an external service or repository. 

Example: doi:10.7924/G8VD6WC6 which is made actionable by prepending the doi.org resolver address: http://doi.org/10.7924/G8VD6WC6.

Local IDs (local_id): Local identifiers, generally derived from Digital Production Center (DPC) identifiers, are stored in the local_id property on items in Digital Collections, which are used to construct custom URLs for these items (instead of constructing URLs using PIDs). 

Example: brpst023001

EAD IDs (ead_id): When a DDR resource is derived from a Rubenstein Library resource described in an EAD-encoded finding aid, we store the collection guide identifier in the ead_id property on the collection-level object in DDR which enables the 'Source Collection' feature on the portal page as well as the link from the item-level metadata record and sidebar.

Example: rushbenjaminandjulia

ArchivesSpace IDs (aspace_id): When a DDR resource has a corresponding component in ArchivesSpace, we store the identifier for this item in the aspace_id property which enables the 'View this item in context' functionality in the sidebar. This link drops the user directly into the appropriate place in the collection guide.

Example: 5f67670f35d7b87a014f665136ab236e