...
Given how little the schemes do for you, when choosing one you should 'll likely want to consider factors such as cost, risk, and openness.
...
- 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.
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.
If ARKs don't require metadata, how do people know what they refer to?
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 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 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 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.
Some trends have been observed. DOIs used to be known primarily as identifiers for scientific and scholarly publications, with a mature community and service offering around Crossref DOIs, but newer kinds of DOIs, such as those from DataCite and EIDR, are changing the nature of the DOI. Having said that, Crossref and DataCite DOIs have been successful in creating tools and services that integrate well with the scholarly publishing ecosystem. Meanwhile, PURLs have seen lots of use in identifying ontology terms.
...
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?
...
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.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 DOIsdoi.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-80418041
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:, 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