...
The average lifetime of a URL was once said to be 44 days. At the end of its life, a URL link breaks, meaning it gives you the dreaded "404 Not Found" error that most of us have seen. Irritating as that is – and we've all seen it – itmay be, it's a disaster for libraries, archives, museums, and other memory organizations.
...
For a resolver to work, its hostname must be carefully chosen so won't ever need to be changed. Memory organizations, some of them centuries old, tend to have hostnames well-suited to be resolvers. Some well-known, younger resolvers are n2t.net (the ARK resolver), identifiers.org, doi.org, handle.net, and purl.org.
...
What are ARKs used
...
for?
For anything and everything. ARKs are mostly used to identify digital content, such as genealogical records (FamilySearch), publisher content (Portico), and digitized manuscripts (Gallica), texts (Internet Archive), and museum holdings (Smithsonian). They are also used for datasets, journals, and vocabulary terms (yamz.net, perio.do). One group uses ARKs to identify historical figures (SNAC), and another to identify live customers.xxx
How does ARK compare to DOI, Handle, PURL, and URN?
...
As seen in these examples, they all begin with the protocol (https://) plus a hostname, followed by the Name Assigning Authority (99999, 10.99999, or purl.org), which is the organization that created a particular identifier. Finally there's the name, or local identifier, that it assigned (12345). Here are some Some more things these identifier schemes (types) have in common:
- 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.
...
That's not to say that making ARKs persistent is cost-free. Keeping Making any identifiers identifier persistent burdens every 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. With ARKs, just as with URLs, you are will not be charged separately for your identifiers and you are will not be locked in to a special-purpose resolution silo that also locks out other identifiers.
...
Are there more ways that these identifier types
...
differ?
Here's a longer list:are some more differences.
- When (, not if , (because all things pass), the
https://protocol and the hostname cease to exist, only ARKs and URNs will indicate 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.
- Although you can use your own or a vendor resolver for your ARKs and URNs, all ARKs can be resolved via n2t.net, making it the closest thing to a "global ARK resolver".
- For URNs there is No standard URN resolver was ever implemented, so URNs are currently resolved as if they were URLs. There is also no single global resolver for URNs-as-URLs. In order to register to create URNs, you must apply for a URN namespace.
- Unlike DOIs and Handles, ARKs can be deleted and don't have any metadata requirements.
...
There are no simple answers. Identifiers are abstract and tricky to talk about, so it helps to 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 can all provide the core service of resolution (for that matter, so can any just like properly managed URLs).
The concrete differences that we think we experience, such as restrictions on identifier metadata (descriptions) and landing pages, are not properties of identifier strings, but properties of resolution and management services extended to or withheld from those identifier strings. The foundation of these services is basic service is founded on a reliable database that stores storing each identifier and its along with metadata elements (eg, creator, title, date, redirection URL, etc) to that describe the identified object. Other possible services include things like link checking, duplicate detection, report generation, and searching.
Typically, services are built designed as siloes ("walled gardens") to serve a particular identifier type (eg, Handle, DOI, or PURL) to the exclusion of other types. Such practice a design takes extra work 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 sometimes creates can create surprising flexibility; for example, ARKs are sometimes 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
...