ARK implementation best practices

ARK creation and object lifecycle

ARKs should be created at object birth, or even before. We sometimes name our babies before they’re born, and we name and refer to objects in the conception stages, sometimes long before they bear fruit. Depending on how elaborate the planning may be, your unborn objects could have full-function ARKs that resolve to an appropriate surrogate and return rich metadata, including persistence statements.

The only caveat is to be careful releasing (advertising) ARKs that have uncertain long term prospects. Some identifier management systems have features to help manage and resolve unreleased identifiers (eg, EZID has a “reserved” status). The more people who know about an ARK, the harder it is to delete.


Creating metadata (extra information associated with or describing an object) has several key benefits. First, no matter what the ARK redirects to – whether a landing page or a file – metadata gives users vital information about the object, such as references to newer versions, creation date, provenance, etc. For ARKs typically metadata is accessed via inflections.

Metadata really eases the difficulty of working with opaque identifiers, which reveal no clues as to what they identify. In the absence of metadata you are forced to access the object itself to remind yourself what it is, and also to trust that you’re accessing the correct object. Moreover, discrepancies between returned metadata and the accessed object help everyone detect identifier changes and errors. 

Metadata is for grownups, and is far less important for immature objects and their identifiers than for those that have been released. Having metadata demonstrates basic provider credibility and commitment to high-functioning identifiers. Not every provider is up to this task.

It need not be expensive. Building metadata from scratch can be costly, but it’s usually created and managed by object providers, in which case it can be leveraged efficiently for identifiers. Ideally, for strong persistence master metadata (maintained by object providers) should be reflected in independent systems so that it is hard for someone to tamper undetectably with identifier associations. For example, digital object repositories that obtain ARKs and DOIs from the EZID service store a copy of their metadata with, which in turn stores another copy with the resolver. 

Policy statements

The ARK inflection “??” at the end of a URL will lead the user to your policy statement. As an example, the California Digital Library (CDL) assigns identifiers within the ARK domain under the NAAN 13030 and according to the following principles:

  • No ARK shall be re-assigned; that is, once an ARK-to-object association has been made public, that association shall be considered unique into the indefinite future.
  • To help them age and travel well, the Name part of CDL-assigned ARKs shall contain no widely recognizable semantic information (to the extent possible).
  • CDL-assigned ARKs shall be generated with a terminal check character that guarantees them against single character errors and transposition errors.

Institutions that generate ARKs may want to follow similar principles or develop their own assignment policies.

Additional policy and persistence statement resources