...
And they all have little effect on persistence. See 10 persistent myths about persistent identifiers.
Wait, are you saying ARK, DOI, Handle, PURL, and URN are useless?
...
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.
From cradle to grave
Why are ARKs that haven't been "released into the world" easy to delete?
If no one knows about an identifier but you, there's no harm in deleting or withdrawing it. Stepping back, an identifier is actually an assertion that a given string of characters is associated with specific thing. The fewer people you tell, the easier it is to scrap that assertion. If you create a URL and share it only with your closest colleagues on an internal network, that is much easier to withdraw than if the URL appeared for a month on a public website where it was harvested by internet search engines. In contrast, it is hard to delete DOIs and Handles; once registered and made resolvable, they are essentially released to the world.
ARKs behave like URLs in this respect. Providers are free to create and share ARKs narrowly, in which case they're easy to delete. Even if shared more broadly, ARKs can come with persistence statements that tell you how much or how little commitment is made to them. ARKs were designed to articulate a variety of persistence statements. Persistent identifiers of other types exhibit a similar variety of commitment "flavors".
Finally, people make mistakes. ARKs, DOIs, Handles, PURLs, and URNs get broadcast in error and sometimes need to be withdrawn. When that happens, provider best practice is make a withdrawn identifier resolve to a page that explains and perhaps apologizes for the inconvenience. Despite what you may have heard, persistent identifiers are not guaranteed.
If ARKs don't require it, why would I bother to create metadata?
There are several key benefits to having metadata, which is strongly recommended for all ARKs that are mature (no longer under development) and released into the world. The standard way to retrieve the metadata is to resolve the ARK with a '?' or '??' appended to it.
First, no matter what the ARK redirects to, whether landing page or PDF file, metadata gives the user further information about the object, such as a description, other versions, etc. In contrast, so as make sure metadata is available, DOIs are required to redirect to landing pages (consistent with common publisher practice) and prohibited from linking directly to object content.
Second, it shores up the persistence of the binding between the ARK string and the identified object. The primary assertion of the binding is the experience of resolving the identifier to the object. A secondary, confirming assertion of the binding is the experience of resolving to its metadata. Any discrepancy between the the metadata and the object helps to detect changes in that binding.
Third, providing access to metadata demonstrates basic provider commitment. This adds credibility to the seriousness of its intentions since not every object provider can return object metadata. Finally, adding basic metadata, especially for objects that don't have textual representations, makes your objects more findable.
What metadata is recommended for ARKs? xxx
ARKs were always meant to cover an enormous range of object types, xxx Dublin Core Kernel metadata.
What is a NAAN and how do I change it? xxx
NAAN stands for Name Assigning Authority Number. It is a 5-digit number that identifies an individual or organization that can assign its own ARKs.
Obtaining a NAAN is the only condition before you can start assigning ARKs. NAANs are freely granted by any individual or organization that request a NAAN by filling this form: https://n2t.net/e/naan_request.
NAANs ensure that ARKs don't collide at the global level, that is, that two separate organizations don't assign identical identifiers to two different things. In other words, NAANs are the cornerstone of global ARK unicity.
All NAANs are documented in a public NAAN registry.
What is meant 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, sometimes lasting years, during 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. It is easy to abandon ARKs that have not been released into the world.
Like the object itself, metadata elements need a flexible place to grow and mature over time:
- starting in the planning phase, 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 above regarding early object development, if you start with an ARK, you benefit from being able to keep that original identifier through to public release as the metadata matures. For some of the objects you save you may also want a DOI.
Assuming you wish to maintain both the ARK and DOI 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 can ensure correct resolution of both identifiers while only having to maintain the ARK.
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.
What is an ARK "inflection" and how does it differ from "content negotiation"?
An inflection is a change to the ending of a word to express a shift in meaning, and it permits us to define a word such as "go" without also defining "goes" and "going". For an ARK that gets to an object, simply adding a '?' to the end (an example of an ARK inflection) permits us to request metadata without having to define a separate identifier for the object's metadata. This technique is simple enough to be used by humans using a web browser. The N2T resolver supports both inflections and content negotiation.
Content negotiation is a software technique for requesting alternate formats of an object, such as the PDF or RTF form of an HTML file. Although not designed for it, content negotiation has been twisted in certain contexts to request metadata under the kludgy assumption that formats often used to hold metadata are in fact metadata. Unlike inflections, "content negotiation for metadata" doesn't work at all for objects that have legitimate representations in those formats (the list of which is growing and known only by private agreement), nor can it be used directly by humans.
Can an object have both an ARK and a DOI?
Yes. As mentioned below regarding early object development, if you start with an ARK, you benefit from being able to keep that original identifier through to public release as the metadata matures. For some of the objects you save you may also want a DOI.
Assuming you wish to maintain both the ARK and DOI 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 can ensure correct resolution of both identifiers while only having to maintain the ARK.
When should I use ARKs compared to DOIs, Handles, PURLs, or 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 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 this applies to a subset of DOIs assigned via Crossref. What it means to be a DOI is becoming harder to 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 in creating tools and services for scholarly publishers.
- PURLs have seen lots of use in identifying metadata vocabulary and ontology terms.
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
Getting started
How do I start assigning ARKs?
The only prerequisite is to fill out an online request for a NAAN on behalf of your organization. Within a day or two you should receive an email containing a NAAN for your organization's exclusive use. There is no charge to obtain a NAAN.
Meanwhile, you might plan how to provide access to things you want to name, which generally should be things that you own, control, or manage. There are many possibilities. For example, you could run all your own custom infrastructure – including content management, web hosting, minting (generating unique identifier strings), and running your own server/resolver. That infrastructure could be very simple, such as server configured to convert incoming ARK-based URLs to server file pathnames. When you request your NAAN you will be asked to supply the base URL of your local server or resolver.
At the other end of the spectrum, you could work with a vendor that supplies all the infrastructure so that, for example, you could focus on creating content. Hybrid solutions are also common, such as just taking your current web server arrangement and just adding an identifier management piece (eg, the API/UI provided by ezid.cdlib.org, which partners with n2t.net).
If you run a resolver, you will also want to think about whether to advertise (publish) your ARKs based at your resolver or at n2t.net. Resolving through n2t.net is always possible as a cost-free side-effect of obtaining a NAAN.
What is a NAAN, and can I make changes to it?
NAAN stands for Name Assigning Authority Number, an it is a unique 5-digit number that begins (after the "ark:" label) every ARK. The NAAN identifies the organization that assigned the ARK and ensures that ARKs don't collide at the global level, so that two separate organizations will never be able to assign the same ARK to different things.
You may request a NAAN by filling out an an online form. The NAAN you obtain will be listed alongside all other registered NAAN in the public NAAN registry. Use the same form to request a change to your NAAN entry, for example, if you change the URL for your local server or resolver.
From cradle to grave
Why are ARKs that haven't been "released into the world" easy to delete?
If no one knows about an identifier but you, there's no harm in deleting or withdrawing it. Stepping back, an identifier is actually an assertion that a given string of characters is associated with specific thing. The fewer people you tell, the easier it is to scrap that assertion. If you create a URL and share it only with your closest colleagues on an internal network, that is much easier to withdraw than if the URL appeared for a month on a public website where it was harvested by internet search engines. In contrast, it is hard to delete DOIs and Handles; once registered and made resolvable, they are essentially released to the world.
ARKs behave like URLs in this respect. Providers are free to create and share ARKs narrowly, in which case they're easy to delete. Even if shared more broadly, ARKs can come with persistence statements that tell you how much or how little commitment is made to them. ARKs were designed to articulate a variety of persistence statements. Persistent identifiers of other types exhibit a similar variety of commitment "flavors".
Finally, people make mistakes. ARKs, DOIs, Handles, PURLs, and URNs get broadcast in error and sometimes need to be withdrawn. When that happens, provider best practice is make a withdrawn identifier resolve to a page that explains and perhaps apologizes for the inconvenience. Despite what you may have heard, persistent identifiers are not guaranteed.
What is meant 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, sometimes lasting years, during 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. It is easy to abandon ARKs that have not been released into the world.
Like the object itself, metadata elements need a flexible place to grow and mature over time:
- starting in the planning phase, 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.
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 Although inflections are commonly associated with ARKs, they are not "owned" by ARKs. In fact, contrary to popular belief, identifiers don't do anything – it's their resolvers that do or don't support such these features. So for For example, inflections and suffix passthrough are is a feature supported by n2t.net for all identifier types (and purl.org has something similar called "partial redirect"), but not by doi.org or handle.net for any identifier types.
When should I use ARKs compared to DOIs, Handles, PURLs, or 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 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 this applies to a subset of DOIs assigned via Crossref. What it means to be a DOI is becoming harder to 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 in creating tools and services for scholarly publishers.
- PURLs have seen lots of use in identifying metadata vocabulary and ontology terms.
Resolvers
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
Having to run and maintain your own resolver is the cost of complete autonomy. Using your own resolver also lets you do branding via 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 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:
.
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.
If ARKs don't require it, why would I bother to create metadata?
There are several key benefits to having metadata, which is strongly recommended for all ARKs that are mature (no longer under development) and released into the world. The standard way to retrieve the metadata is to resolve the ARK with a '?' or '??' appended to it.
First, no matter what the ARK redirects to, whether landing page or PDF file, metadata gives the user further information about the object, such as a description, other versions, etc. In contrast, so as make sure metadata is available, DOIs are required to redirect to landing pages (consistent with common publisher practice) and prohibited from linking directly to object content.
Second, it shores up the persistence of the binding between the ARK string and the identified object. The primary assertion of the binding is the experience of resolving the identifier to the object. A secondary, confirming assertion of the binding is the experience of resolving to its metadata. Any discrepancy between the the metadata and the object helps to detect changes in that binding.
Third, providing access to metadata demonstrates basic provider commitment. This adds credibility to the seriousness of its intentions since not every object provider can return object metadata. Finally, adding basic metadata, especially for objects that don't have textual representations, makes your objects more findable.
What metadata is recommended for ARKs? xxx
ARKs were always meant to cover an enormous range of object types, xxx Dublin Core Kernel metadata.
What is an ARK "inflection" and how does it differ from "content negotiation"?
An inflection is a change to the ending of a word to express a shift in meaning, and it permits us to define a word such as "go" without also defining "goes" and "going". For an ARK that gets to an object, simply adding a '?' to the end (an example of an ARK inflection) permits us to request metadata without having to define a separate identifier for the object's metadata. This technique is simple enough to be used by humans using a web browser. The N2T resolver supports both inflections and content negotiation.
Content negotiation is a software technique for requesting alternate formats of an object, such as the PDF or RTF form of an HTML file. Although not designed for it, content negotiation has been twisted in certain contexts to request metadata under the kludgy assumption that formats often used to hold metadata are in fact metadata. Unlike inflections, "content negotiation for metadata" doesn't work at all for objects that have legitimate representations in those formats (the list of which is growing and known only by private agreement), nor can it be used directly by humans.
Although inflections are commonly associated with ARKs, they are not "owned" by ARKs. In fact, contrary to popular belief, identifiers don't do anything – it's their resolvers that do or don't support such features. So for example, inflections and suffix passthrough are supported by n2t.net for all identifier types, but not by doi.org or handle.net for any identifier types.
Resolvers
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
Having to run and maintain your own resolver is the cost of complete autonomy. Using your own resolver also lets you do branding via 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). https://n2t.net/ark:/65665/3c2e39526e0c341aebe4f07558a9458eb