...
- 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.
Why doesn't the global ARK resolver (n2t.net) have the word "ARK" in it?
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, 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, or 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.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.
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.
The concrete differences that we experience, such as metadata (object descriptions), 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.
If most ARKs run on their own resolvers, why 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 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 transientand 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, but and if it's an ARK they could can extract the core ARK identity (starting with "ark:") and present it to the global n2t.net resolver, as in
...
To avoid the risk of future inconvenience, an organization may – even one that runs its own resolver – may choose from the outset to advertise ("publish") its ARKs based at n2t.net.
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).
The concrete differences that we experience, such as metadata (object descriptions), 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.
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, so the N2T (Name-to-Thing) resolver and EZID (identifiers made easy) management interface were designed to work with all identifiers. Work 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).
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)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. 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.
Don't identifier types differ in metadata flexibility, content negotiation, inflections, and suffix passthrough?
...