What are ARKs?
ARKs (Archival Resource Keys) are high-functioning identifiers that lead you to things and to descriptions of those things. For example, this ARK,
https://n2t.net/ark:/67531/metadc107835/
gets you to a dissertation, and adding a '?' on the end of the ARK should get you to its description:
https://n2t.net/ark:/67531/metadc107835/?
What's an identifier?
On the internet, an identifier is a URL, or part of a URL. For example, this basic ARK identifier,
ark:/12148/btv1b8449691v/f29
appears inside two different URLs (Uniform Resource Locators, also known as web links or web addresses):
https://gallica.bnf.fr/ark:/12148/btv1b8449691v/f29
https://n2t.net/ark:/12148/btv1b8449691v/f29
ARKs are especially good at being persistent identifiers.
What's a persistent identifier?
The average lifetime of a URL was once said to be 44 days. At the end of its life, a URL link breaks, meaning it gives you the dreaded "404 Not Found" error that most of us have seen. Irritating as that may be, it's politically awkward when looking for publicly funded research, and it's a cultural disaster for libraries, archives, museums, and other memory organizations.
A persistent identifier (sometimes abbreviated PID) is a link that in principle keeps working far into the future, even as things move between websites. Normally when things move, everyone who ever recorded the old links would need to be told what the new links are, which is next to impossible. That's where identifier resolvers come in.
What's a resolver?
A resolver is a website that specializes in forwarding incoming identifiers (the ones originally advertised to users) to whichever websites are currently best able to deal with them. Overall, forwarding is called resolution; one step in a resolution process is called redirection.
For a resolver to work, its hostname must be carefully chosen so it won't ever need to be changed. Memory organizations, some of them centuries old, tend to have hostnames well-suited to be resolvers. Some well-known, younger resolvers are n2t.net (the ARK resolver), identifiers.org, doi.org, handle.net, and purl.org.
What are ARKs used for?
For anything and everything. Uses of ARKs include
- digital content, such as genealogical records (FamilySearch)
- publisher content (Portico)
- digitized manuscripts (Gallica)
- texts (Internet Archive)
- museum holdings (Smithsonian)
- vocabulary terms (yamz.net, perio.do)
- historical figures (snaccooperative.org)
- datasets, journals, living beings, and more.
Why would I use ARKs compared to, for example, DOIs?
- To keep costs down.
- To work with exactly the metadata I want.
- To be able to create identifiers without metadata.
- To create an identifier as soon as I create the first draft of my data.
- To keep 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.
- To integrate with the Data Citation Index ℠ and ORCID.org researcher profiles.
- To link identifiers to different kinds of nuanced persistence commitments.
- To be able to add queries (eg, ?lang=en) when resolving my identifiers.
- To use open infrastructure consistent with my organization's values.
- To create one identifier that enables millions (suffix passthrough).
What does ARK have in common with DOI, Handle, PURL, and URN?
These are all major so-called persistent identifier schemes (or identifier types). They have much in common, starting with structure.
https://n2t.net/ark:/99999/12345
https://doi.org/10.99999/12345
https://handle.net/10.99999/12345
https://purl.org/12345
https://<various>/urn:99999:12345
As seen in these examples, they all have three parts:
- the protocol (
https://) plus a hostname, - just for ARK and URN, there's also a label ("ark:" or "urn:"),
- the name assigning authority (
99999,10.99999, orpurl.org), which is the organization that created a particular identifier, - and finally, the name, or local identifier, that it assigned (
12345).
And they all have little effect on persistence.
Wait, are you saying ARK, DOI, Handle, PURL, and URN are useless?
No, that's too strong a statement. But let's keep these identifier schemes (types) in perspective.
- They all fail to stop the major causes of broken links: loss of funding, natural disaster, war, deliberate removal, human error, and provider neglect.
- They all require you, the end provider, to update forwarding tables as URLs change.
- They all identify content that is subject to change or removal on future visits.
- They all have identifiers that break regularly and in large numbers – many thousands and more.
- They all give access to almost any kind of thing, whether digital, physical, abstract, person, group, etc.
- A non-trivial fraction of each scheme's identifiers did, and will, fail permanently, requiring forwarding to "tombstone" pages.
- They all rely on ordinary redirection built in to web servers since 1994 and provided for free by hundreds of URL shortening services.
Given how little the schemes do for you, when choosing one you'll likely want to consider factors such as cost, risk, and openness.
How do ARKs differ from identifiers like DOIs, Handles, PURLs, and URNs?
The short answer is that ARKs are the only mainstream, non-siloed, non-paywalled identifiers that you can register to use in about 48 hours. DOIs, Handles, and PURLs require resolution and other services to come from their respective centralized systems (silos).
That's not to say that persistence is free. Making any identifier persistent burdens you, the provider, with the costs of content management, hosting, monitoring, and forwarding. You can do those things yourself or with help from a vendor. But with ARKs, just as with URLs, you will not be charged separately for your identifiers and you will not be locked in to a special-purpose resolution silo that also locks out other identifiers.
ARKs are unusual in being decentralized. While one can get resolution services from a global ARK resolver called n2t.net, over 90% of the ARKs in the world are published without reference to it. More than 500 registered organizations across the world have created an estimated 3.2 billion ARKs, and, as with URLs, no one has ever paid to create them. Of course maintaining them isn't free. It is never without cost to keep content access persistent in the long term, regardless of identifier type.
How else do the identifier types differ?
Here are some more differences between DOIs, Handles, PURLs, and URNs.
- 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, per-DOI charges. 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.
- Unlike DOIs and Handles, ARKs don't have metadata requirements. ARKs that haven't been released into the world are easy to delete.
For the purpose of supporting early object development, some distinguishing features of ARKs are that they can be deleted, they can exist with no metadata, and they can exist with any metadata you care to store.
Why are ARK that haven't been "released into the world" easy to delete?
If no one knows about an identifier, there's absolutely no problem in removing it. Identif
This is actually true for many types of identifier. An advertised identifier
What do you mean by ARKs supporting early object development?
We need identifiers long before we know exactly what they refer to, or even if they refer to anything useful. An identifier that requires mature metadata cannot be used during early object development since little is known about the object. So object creators almost always initially assign identifiers that have no metadata requirements, such as URLs or ARKs.
If you start with an ARK, you benefit from being able to keep the original identifier through to public release as the metadata matures. Many objects go through intensive development and revision phases, in which they are too immature to meet most metadata requirements. Nonetheless every object needs some sort of identifier from conception to maturity, where maturity could look like public release and further enhancement, or abandonment. Like the object itself, metadata elements need a flexible place to grow and mature over time:
- starting from the first plans, when it just needs an identifier,
- at the moment of birth, when its first digital representation needs a redirection target URL,
- after the first analysis, when its significance and a tentative title emerges,
- when creating dozens of discipline-specific metadata elements that violate most metadata standards except your own,
- during post-processing by a colleague whose name will be added as a creator,
- when early feedback based on the tweeted identifier turns up a key insight and a new contributor,
- and so forth, through public release, correction, revision, enhancement, etc.
Can an object have both an ARK and a DOI?
Yes. As mentioned, if you start with an ARK early in object development, you benefit from being able to keep that original identifier through to public release as the metadata matures. If in addition you think you need a DOI, that will become a second object identifier to maintain.
Assuming you wish to maintain both the new and old identifiers (to avoid breaking links that your collaborators had stored and bookmarked), an easy way forward is to set up the DOI to redirect to the ARK. In this way you could ensure correct resolution of both identifiers but only having to maintain the ARK.
But isn't presence of metadata a sign of quality?
, and such identifiers probably won't meet requirements. If assigning a certain kind of identifier (eg, a DataCite DOI) means meeting metadata requirements, that almost ensures that the object will become known by another identifier get a new and different identifier from it has been known by for what might be years of development. releasing mean that these objects for meet metadata requirements for publication it is impossible to meet metadata requirements identifier when it's ok not to have basic metadata.
Flexible metadata (object descriptions) is critical for keeping identifiers stable throughout object life cycles. In the digital age, objects often mature in public, where they may be referenced for years in tweets and whitepapers via whatever identifier is easy or possible. Unfortunately, when they are finally ready to enter the scholarly publication system, that is often the first time that metadata requirements can be met to obtain a DOI – in other words, these well-loved objects, at the peak of celebrity, are expected to become known by a new name. The old name might continue to work, but
Metadata required to create an object DOI, for example, may not be known until after the object has been developed from "embryo" to maturity, using another identifier regularly over a period of years to reference (eg, tweeting about) it with colleagues.
Many large and small scale endeavors in research and curation require the creation and nurturing of objects over periods of weeks, months, and years. Those objects all need to be referenced by identifiers, starting from their earliest embryonic form, and even before that when they were conceived in planning documents. As objects develop to maturity, perhaps years later, those identifiers will appear in tweets, emails, whitepapers,
which Many endeavors rder to means you can is meant the ability to store any metadata you want, including repeated elements, such as multiple authors and forwarding URLs, or no metadata at all. N2T has full metadata flexibility, while Crossref and DataCite have specific requirements (eg, the DataCite schema) to create their DOIs.
If ARKs can be deleted, how can they be trusted?
Only one resolver, n2t.net, supports all of these features, and it does so for any identifier stored with appropriate metadata. Contrary to popular belief, identifiers don't do anything – it's their resolvers that do or don't support these features. For example, suffix passthrough is a feature supported by n2t.net (and purl.org has something similar called "partial redirect"), but not by doi.org or handle.net.
By metadata flexibility is meant the ability to store any metadata you want, including repeated elements, such as multiple authors and forwarding URLs, or no metadata at all. N2T has full metadata flexibility, while Crossref and DataCite have specific requirements (eg, the DataCite schema) to create their DOIs.
Content negotiation to request descriptions of things, but human beings can't do it themselves, and it only works for things that are not already in formats that might contain descriptions. Fortunately, without restriction, both humans and software can use inflections, exemplified by the '?' at the top of this FAQ. N2T is one of the few resolvers that that does both.
When should I use ARKs compared to DOIs, Handles, PURLs, and URNs?
There are no simple answers. Identifiers (not things, but their names) are tricky to talk about, so if you hear simple answers elsewhere, beware of common fallacies.
Nothing inherent in ARKs, DOIs, Handles, PURLs, or URNs makes them more or less fit for any particular field, domain, or sector. With an identifier resolver and administrative management service, they all provide the core service of resolution (and so do properly managed URLs).
Generalizations about identifier types sometimes apply when resolution and management for that type is locked into one particular vendor or provider. For example, many PURL and Handle features and restrictions are well-defined by their respective administration silos. DOIs, which are built on top of Handles, have the same resolution features and restrictions as Handles, but metadata practices are diverse and evolving across registration agencies.
The concrete differences that we experience, such as metadata, landing pages, and tool integration (eg, publishing tools), are not properties of identifier schemes per se, but properties of resolution, management, and citation services that various providers extend to or withhold from different identifier types. Those services are shaped in turn by communities of practice and by markets. Basic services are founded on a reliable database storing each identifier along with metadata elements (creator, title, date, redirection URL, etc) that describe the identified object. Extra services include link checking, duplicate detection, report generation, and searching.
What are usage trends for ARKs, DOIs, Handles, PURLs, and URNs?
As of 2019, purely on an incomplete and anecdotal level, here are a few trends that have been observed.
- ARKs have seen broad adoption in cultural memory institutions – museums, archives, and libraries. There is especially strong adoption in France and francophone regions.
- DOIs until recently have mostly been known as reliable identifiers for scientific and scholarly literature, when in fact these are actually a subset of DOIs assigned via Crossref. What it means to be a DOI in general is becoming harder pin down because DOIs are being assigned to datasets, data management plans, field stations, etc. via DataCite, as well as to movies (eg, "Kung Fu Panda") via EIDR. Having said that, Crossref and DataCite DOIs have been successful creating tools and services for publishers of literature and research data.
- PURLs have seen lots of use in identifying metadata vocabulary and ontology terms.
If most ARKs run on their own resolvers, why is there also a global resolver for ARKs?
Most ARKs are created by organizations that advertise ("publish") them based at their own resolvers. For example, this ARK was published based at the gallica.bnf.fr resolver:
https://gallica.bnf.fr/ark:/12148/btv1b8449691v/f29
Running and maintaining your own resolver is the cost of complete autonomy. Having your own resolver also lets you insert branding in the hostname, the downside being that brands are transient and tend to make identifiers fragile. Political and even legal (eg, trademarks) pressures may make supporting older branded hostnames, hence their identifiers, difficult.
That's another reason for having the global ARK resolver. People coming across a broken identifier in the future may find its hostname no longer exists, and if it's an ARK they can extract the core identity (starting with "ark:") and present it to the global n2t.net resolver, as in
https://n2t.net/ark:/12148/btv1b8449691v/f29
To avoid the risk of future inconvenience, an organization – even one that runs its own resolver – may choose from the outset to advertise ("publish") its ARKs based at n2t.net.
Why doesn't the global ARK resolver (n2t.net) have the word "ARK" in it?
When demand for a global ARK resolver arose, basic principles of openness and generality prevented the designers from creating yet another silo in the DOI/Handle/PURL mold. Instead, the ARK resolver was built to be a generic, scheme-agnostic resolver called N2T (Name-to-Thing), which now resolves over 600 types of identifier, including ARKs, DOIs, Handles, PURLs, URNs, ORCIDs, ISSNs, etc. Resolution is essentially looking in a table for an identifier string, regardless of type, and redirecting it to the right place.
The same basic principles guided the design of an earlier tool called noid, which was built for ARKs but is also regularly used by organizations that mint Handles.
What do you mean by silos?
Typically, scheme-based services are designed as silos, or closed platforms, serving a particular identifier type such as Handle, DOI, or PURL. Each silo performs the same main functions – mapping names (identifiers strings) to things (objects or metadata). Excluding all but one type of identifier string may help to capture markets, but it's wasteful and non-inclusive. It requires building the same set of services over and over for each type and violates basic principles of openness.
In contrast the N2T (Name-to-Thing) resolver and EZID (identifiers made easy) management interface were designed to work with all identifiers. Effort put into any new feature can be efficiently leveraged across all types, which sometimes creates surprising flexibility. For example, ARKs are often stored in EZID with "DOI metadata", and every DOI stored in N2T can benefit from "ARK resolution features" such as inflections and suffix passthrough, which are not available via the main DOI resolver (doi.org).
I've heard that ARKs do something called "inflections" and DOIs do "content negotiation" – what does that mean?
Only one resolver, n2t.net, supports all of these features, and it does so for any identifier stored with appropriate metadata. Contrary to popular belief, identifiers don't do anything – it's their resolvers that do or don't support these features. For example, suffix passthrough is a feature supported by n2t.net (and purl.org has something similar called "partial redirect"), but not by doi.org or handle.net.
Content negotiation to request descriptions of things, but human beings can't do it themselves, and it only works for things that are not already in formats that might contain descriptions. Fortunately, without restriction, both humans and software can use inflections, exemplified by the '?' at the top of this FAQ. N2T is one of the few resolvers that that does both.
I've heard of ORCIDs, RORs, and UUIDs – where do they fit in?
Those are special kinds of persistent identifiers. ORCIDs (Open Researcher and Contributor Identifiers) only identify researchers, and they link to research works using ARKs, DOIs, etc. ORCIDs look like
https://orcid.org/0000-0001-7604-8041
ROR (Research Organization Registry) identifiers designate organizations. For example, here's the California Digital Library:
UUIDs are globally unique, 37-character strings that are easy for software to generate but only become usable as web addresses when made part of a URL, for example, in this ARK:
https://somehost.example.com/3c2e39526-e0c3-41ae-be4f-07558a9458eb
While embedding a UUID in an ordinary URL makes it actionable ("clickable"), you could expect more if it were embedded in an ARK such as
https://n2t.net/ark:/65665/3c2e39526-e0c3-41ae-be4f-07558a9458eb
As an ARK, for example, that UUID should return metadata (if available) and be insensitive to the hyphens, making this form equally viable:
https://n2t.net/ark:/65665/3c2e39526e0c341aebe4f07558a9458eb
