...
These are all major persistent identifier schemes (or identifier types). Superficially they They have much in common, starting with structure:
...
- 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 burden the end provider with the responsibility to update forwarding tables as URLs change.
- They all give access to any kind of thing, whether digital, physical, abstract, person, group, etc.
- They all identify content that is subject to change on future visits.
- They all break regularly and in large numbers (thousands and more).
- They all use ordinary redirection built in to web servers since 1994 and provided for free by hundreds of URL shortening services.They all (as a result) leave you wondering if you need them at all, and if so, at what cost
Given how little each scheme contributes to persistence, it is wise to consider cost, risk, and philosophy (eg, openness) when choosing a scheme.
How do ARKs differ from identifiers like DOIs, Handles, PURLs, and URNs?
...
There are no simple answers. If Identifiers (not things, but their names) are tricky to talk about, so if you hear of simple answers elsewhere, beware of common fallacies and remember that identifiers (names, not things) are tricky to talk about.
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 restrictions on identifier metadata (descriptions) and landing pages, are not properties of identifier stringsschemes per se, but properties of resolution and management services extended to or withheld from identifier strings. The basic service is identifiers. 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. Other possible Extra services include link checking, duplicate detection, report generation, and searching.
Typically, scheme-based services are designed as siloes ("walled gardens") to serve a particular identifier type (eg, Handle, DOI, or PURL) to the exclusion of other types. They all do the same things – metadata, forwarding, etc – so the only point of building siloes is to capture markets and exclude others. Such a design takes extra work requires artificially restricting database keys and violates basic principles of openness, so the N2T 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 can create sometimes creates surprising flexibility; for example, ARKs are sometimes 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). Here are some concrete differences in metadata
There are also softer differences, such as community attitudes and trends, based on numbers and "buzz". If we did free association in 2019, one might hear:
...
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 (, where it's called "partial redirect"), but not by doi.org or handle.net.
...