...
- 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 evolvesand 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).
...
And they all have little effect on persistence.
...
Wait, are you saying ARK, DOI, Handle, PURL, and URN are
...
useless?
ThatNo, that's too strong a statement, however, it. But let's wise to 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 have identifiers for 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 use 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 give do for you, when choosing one you should consider factors such as cost, risk, and openness.
...
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 very 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's . It is never without cost to keep content access persistent in the long term, regardless of identifier type.
...
.
...
Although N2T (Name-to-Thing) is a resolver originally built for ARKs, principles of openness prevented it from becoming just another DOI/Handle/PURL-type silo, which all perform the same main functions. Thus the "global ARK resolver" also resolves DOIs, Handles, PURLs, URNs, and 600 other types of identifier.
This counter-silo principle can also be found in micro-service tools such as noid, which was built for ARKs and is widely used by organizations that mint ARKs and those that mint Handles.
How else do the identifier types differ?
...
- All things eventually pass, including hostnames and the web itself and the "
https://"protocol; when . 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 your own a local or a vendor resolver for your ARKs and URNs, all ARKs can be ARKs can be resolved via the global n2t.net, making it the closest thing to a "global ARK resolver" 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, and . ARKs that haven't been released into the world can be deletedare easy to delete.
Why doesn't the global ARK resolver (n2t.net) have the word "ARK" in it?
A resolver works by looking in a table for an identifier string, regardless of type, and redirecting it to the right place. When demand for a global ARK resolver arose, basic principles of openness and simple software design prevented the designers from creating yet another silo in the DOI/Handle/PURL mold. Instead they built 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. These principles aren't new; they guided the design of an earlier tool called noid, that was built for ARKs but is also regularly used by organizations that mint Handles.
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. This gives assigning organizations autonomy and an opportunity to do some branding. From the first two For example, this core ARK
can be resolved from either from the local ARK was published based at the gallica.bnf.fr resolver or from the n2t.net resolver:,
https://gallica.bnf.fr/ark:/12148/btv1b8449691v/f29
Running one's own resolver gives a provider autonomy, as well as an opportunity to carry branding to the left of the core ARK (which starts with the "ark:"). On the other hand, not every organization wants the burden of running its own resolver. Moreover, brands tend to make identifiers more fragile because brands are transient. Political and even legal (eg, trademarks) pressures may make supporting older branded identifiers difficult. People coming across a broken identifier in the future may find its hostname no longer exists, but if it's an ARK they could extract the core ARK and present it to the global n2t.net resolver, as in
https://n2t.net/ark:/12148/btv1b8449691v/f29
People coming across ARKs in the wild starting with hostnames that no longer exist will be able extract the core identifier (starting with "ark:") and present it to the global n2t.net resolver. Content providers who use their own hostnames in this way have an opportunity to obtain some branding even if it requires a future adjustment from users after the brand ceases to be relevant. Meanwhile, content providers who wish to avoid inconveniencing future users may from the outset prefer To avoid the risk of future inconvenience, an organization may choose from the outset to advertise ("publish") their its ARKs based at n2t.net.
The form of ARK branding just described is much preferable to branding inside the core identifier. Unfortunately all too common in DOIs and Handles, branding inside the core identifier create problems for longevity that span legal and political concerns.
XXX as that provide this limited form of branding serves as long as the provider is viable servers often don't last, so having one standard place in the world
to serve (resolve) ARKs better ensures persistence. This is the same concept
as global resolver for DOIs (doi.org), as well as the global resolvers for
Handles and PURLs.
When should I use ARKs compared to DOIs, Handles, PURLs, and URNs?
...