...
You are free to create ARK strings as you wish, provided you use only digits, letters (ASCII, no diacritics), and the following characters:
= ~ * + @ _ $ . /
The last two characters are reserved in the event you wish to disclose ARK relationships.
Another unique feature of ARKs is that hyphens ('-
') may appear but are identity inert, meaning that strings that differ only by hyphens are considered identical; for example, these strings
ark:/12345/141e86dc-d396-4e59-bbc2-4c3bf5326152
ark:/12345/141e86dcd3964e59bbc24c3bf5326152
identify the same thing. The reason for this feature is that text formatting processes out in the world routinely introduce extra hyphens into identifiers, breaking links to any server that treats hyphens as significant.
ARKs distinguish between lower- and upper-case letters, which makes shorter identifiers possible (52 vs 26 letters per character position). The "ARK way", however, is to use lower-case only unless you need shorter ARKs. The restriction makes it easier for resolvers to support your ARKs in case they arrive from the world with mixed- or upper-case letters, which happens regrettably often due to the lingering 50-year-old assumption that identifiers are case-insensitive. You might also consider using the character repertoire of the Noid tool, which creates transcription-safe strings using the strongest mainstream identifier check digit algorithm; it uses only digits and consonants minus 'l' (letter ell, often mistaken for the digit 1):
0123456789bcdfghjkmnpqrstvwxz
Regarding assignment, one common strategy is to leverage legacy identifiers. For example, a museum moth specimen number cd456f9_87
might be advertised under the ark:/12345/cd456f9_87
. Some legacy identifiers may need to be altered in view of ARK character restrictions. The second common strategy is to make up entirely new strings for your ARKs. In this case it is important to consider whether to make them opaque or non-opaque (or a bit of both).
What are opaque identifiers?
Persistent identifier strings are typically opaque, deliberately revealing little about what they're assigned to, because non-opaque identifiers do not age or travel well. Organization names are notoriously transient, which is why NAANs are opaque numbers. As titles and dates are corrected, word meanings evolve (eg, innocent older acronyms may become offensive or infringing), strings meant to be persistent can become confusing or politically challenging. The generation and assignment of completely opaque strings comes with risk too, for example, numbers assigned sequentially reveal timing information and strings containing letters can unintentionally spell words (which is why vowels are missing from the recommended character repertoire).
...
ARKs are not required to be opaque, but it is recommended that the base object name be made opaque, since it tends to name the main focus of persistence. If any qualifier strings follow that name, it is less important that they be opaque. To help choose your approach to opacity, you may wish to consider compatibility with legacy identifiers and ease of string generation and transcription (eg, brevity, check digits). New strings can be created (minted) with date/time, UUID, and number generators, as well as Noid (Nice Opaque Identifiers) minters.
Opaque strings are "mute" and therefore challenging to manage, which is why ARKs were designed to be "talking" identifiers. This means that if there's metadata131533174, an ARK that comes in to your server with the '?' inflection should be able to talk about itself.
AnchorservingARKs servingARKs
How do I make server content addressable with ARKs?
servingARKs | |
servingARKs |
First, decide what the user experience of accessing your ARKs will be, for example, a spreadsheet file, a PDF, an image, a landing page filled with formatted metadata and a range of choices, etc. Whichever you choose, plan for your server to be able to respond with metadata if your ARK should arrive with a '?' inflection after it.
Otherwise, serving ARKs is like serving URLs. Normally incoming URL strings address (get mapped to) content that your web server returns. If your server is ARK-aware, incoming ARKs (expressed as URLs) must be mapped to the same content. A common approach is to map the ARK to the URL using a software table that you update whenever the URL changes. In this case your server is acting as a local resolver. If you don't want to implement this yourself, there are ARK software tools and services that can help.
Another approach is to run your web server without change, but instead of updating local tables, you would update ARK-to-URL mapping tables residing at a non-local resolver. Examples of this can be found among vendors and in any organization that updates tables via EZID.cdlib.org (which, due to a special relationship, updates resolver tables at n2t.net).
How do I cite or advertise an ARK?
The URL (https or http) form of the ARK is preferred, for example,
https://n2t.net/ark:/99166/w66d60p2
An ARK meant for external use is generally advertised (released, published, disseminated) in this way in order to be an actionable identifier. If a more compact visual display of an ARK is needed, it should be hyperlinked; for example, a compact display of an HTML hyperlink can be achieved with
<a href="https://n2t.net/ark:/99166/w66d60p2"> ark:/99166/w66d60p2 </a>
An important decision is whether your URL-based ARKs will use the hostname of your local resolver or the N2T.net resolver. If local control or branding is important enough, you would advertise ARKs based at your local resolver (see about serving content with ARKs). If you're concerned about the stability of your local hostname, you would advertise your ARKs based at n2t.net (see examples of both).
Resolving your ARKs through N2T is always possible for users, regardless of how you advertise them.
...
N2T uses two kinds of stored data. First, it stores individual records for over 20 million object identifiers (eg, ARKs, DOIs) that it obtains from three sources: EZID.cdlib.org, Internet Archive, and YAMZ.net. When such records include a redirection URL (target) and descriptive metadata131533174, N2T can act on inflections131533174 as well as perform suffix passthrough and "content negotiation".
...
Yes, ARKs can be assigned at any level of granularity, such as to a manuscript, to chapters inside it, to chapter sections, subsections, etc. An ARK can also be assigned to a thing that encloses other things. In ARKs the character '/' is reserved to help the recipient understand about containment, for example, the first object below contains the second:
ark:/12148/btv1b8449691v
ark:/12148/btv1b8449691v/f29
That's the containment qualifier. There's only one other ARK qualifier, and it indicates variant forms of a thing by using the reserved character '.' in front of a suffix. For example, if these ARKs identify documents,
ark:/12148/btv1b8449691v/f29.pdf
ark:/12148/btv1b8449691v/f29.html
because they differ only by the suffix .pdf
or .html
, it can be inferred that they identify two different forms of the same document.
What is the purpose of the NAAN
...
?
NAANs subdivide the set of all possible ARKs (, which is called the ARK namespace). The subset of ARKs under a given NAAN can be further subdivided into shoulders (eg, 12345/x2, 98765/b4), which can make it easy to delegate autonomous ARK assignment to departments in a large organization. ARK resolution is loosely based on NAANs, but because organizations split, ARKs accommodate the namespace splitting problem by supporting management of a namespace by more than one organization. If you transition into or out of a vendor relationship, there is no impediment to taking your NAAN with you.
You can change a NAAN by filling out the same online form used for requesting a new NAAN. Example reasons for a change may include
...
. In obtaining a NAAN, your organization reserves a subset of the ARK namespace for its exclusive use in creating ARKs. If you transition into or out of a vendor relationship, there is no impediment to taking your NAAN with you.
Your NAAN namespace is made up of all possible ARKs that start with "ark:/
" followed by your NAAN and a "/
". ARK resolution is loosely based on NAANs, but also accommodates further subdivision of a NAAN namespace into something called "shoulders" (below). Effectively each subset of that is defined by how its ARKs start is its own infinite namespace, whether the subdivision is at the NAAN, shoulder, or even object level.
Set of all ARKs starting | Namespace defined | Example ARK in that namespace |
---|---|---|
ark:/ | ARK namespace | ark:/99999/fk4gt2m |
ark:/12345/ | 12345 NAAN namespace | ark:/12345/p987654 |
ark:/12345/x5 | 12345/x5 shoulder namespace | ark:/12345/x5wf6789 |
ark:/12345/x5wf6789/ | 12345/x5wf6789 object namespace | ark:/12345/x5wf6789/c2/s4.pdf |
Can I make changes to a NAAN entry?
You can change a NAAN by filling out the same online form used for requesting a new NAAN. Example reasons for a change may include
- notifying N2T that your organization's contact person or resolver URL will change,
- updating your organization's name assignment policy (sample policy),
- requesting an additional NAAN for a significant new body of ARKs or new organizational division, and
- transitioning your NAAN to another organization that will carry on your work and take over your NAAN.
What is a shoulder?
A shoulder is a (sub)namespace under a NAAN namespace, commonly used to help keep it organized. An organization may wish to delegate ARK assignment operations to several autonomous projects, and it rarely knows how it will want to use its namespace in the years ahead. Setting up each project under its own shoulder makes it impossible for any project's assignments to conflict with those of another – present, past, or future – because they take place in non-overlapping namespaces. Shoulders can also ease the namespace splitting problem.
In practical terms, a shoulder is usually a "/
", a letter, and a digit that come after the NAAN. For example, the shoulder is "/x5
" in:
ark:/12345/x5wf6789/c2/s4.pdf
Why is there no "/
" to mark the end of this important sub-namespace (ie, why isn't the shoulder "/x5/
")? There are several reasons.
According to ARK rules, if you published
ark:/12345/x5/wf6789/c2/s4.pdf
, the "/" after "/x5
" implies (a) thatark:/12345/x5
is also an object and (b) the object namedark:/12345/x5/wf6789/c2/s4.pdf
is contained in it. This is likely untrue, except in a way that has little meaning to the end user.It's very tempting to add that "
/
" because it makes the shoulder boundary obvious to in-house ARK administrators, but it doesn't help the end user who is uninterested in the structure of your assignment operations and you may waste time having to re-explain that the shoulder is not actually an object that contains everything in the shoulder namespace.In fact ARK administrators will always know where their shoulder boundary is if they follow the "first-digit convention" when choosing a shoulder, namely, a sequence of letters ending in a digit. The shoulder is then everything up to and including the first digit encountered after the NAAN.
...
ARK resolution is loosely based on NAANs, but also accommodates further subdivision of a NAAN namespace into "shoulders" (below), which can ease the namespace splitting problem
.
Are there restrictions on the use of NAANs?
...
- To keep costs down (details).
- To work with exactly the metadata you want.
- To be able to create identifiers without metadata.
- To be able to create an identifier even before your object exists.
- To have an identifier as soon as you create the first draft of your data.
- To hold that identifier private while the data and metadata evolve, and decide (maybe years) later, to publish or discard it.
- To retain that identifier upon publication, perhaps then assigning an additional identifier, such as a DOI.
- Because ARKs, built for generic application and not specifically for published content, fit naturally with physical objects like samples or field stations.
- Because ARK resolvers can deal with identifiers routinely damaged out in the world by text formatting processes that introduce hyphens.
- Because most ARKs carry a Noid check digit that can be used to detect all common transcription errors rather than just some of them.
- To be able to create shorter identifiers, since mixed-case permits denser strings (a larger number of strings of a given length).
- To be able to change vendor and/or infrastructure without having to coordinate database transfers with a central authority.
- To be able to deal with the namespace splitting problem without losing control of your identifiers.
- To link identifiers to different kinds of nuanced persistence commitments.
- To be able to add queries (eg, ?lang=en) when resolving your identifiers.
- To use open infrastructure consistent with your organization's values.
- To link directly to the objects you value instead of to landing pages.
- To create one identifier that enables millions (suffix passthrough).
- To access convenient, full-function metadata via inflections 131533174.
- To integrate easily with IIIF APIs using ARK qualifiers.
...
- Landing pages: Crossref and DataCite DOIs link to publisher landing pages constructed around but not directly to objects you care about, but ARKs can freely link directly to objects you care about, which is machine- and human-friendly since it does not require an extra human navigation step for common tasks such as
- opening an article's PDF file for reading,
- referencing an image file meant to be incorporated automatically inline into a document, and
- citing a spreadsheet to be used for direct data analysis by software.
- DOIs, Handles, etc. do not support ARK-style inflections131533174
- that permit access to metadata regardless of whether an identifier points to an object or its landing page.
- Unlike DOIs and Handles, ARKs don't have metadata requirements. ARKs that haven't been released into the world are easy to delete.
- All things eventually pass, including hostnames and the web itself and the "
https://"
protocol. When that first part of the identifier ceases to have meaning, only ARKs and URNs will include the label (eg, "ark:") indicating the type of identifier that remains. - For DOIs, Handles, and PURLs, you are required to use their respective resolvers. ARKs and URNs, permit you to use your own resolver.
- To create DOIs and Handles, you are required to pay a membership fee and, for DOIs, there are per-DOI charges passed on in various ways by allocating agencies. There are no fees for ARKs, PURLs, and URNs.
- To create Handles, you are required to install and maintain a local Handle server, which gives you another system to monitor, patch, and troubleshoot.
- Although you can use a local or vendor resolver for your ARKs and URNs, ARKs can be resolved via the global n2t.net resolver.
- The envisioned URN resolution infrastructure was never built, so URNs are currently resolved as URLs, and there is no designated global URN-as-URL resolver. In order to register to create URNs, you must apply for a URN namespace.
- ARKs have some unique features that support early object development: ARKs can be deleted, can be born with no metadata, and can exist with any metadata you care to store.
...
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 inflections131533174.
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.
...