...
The only prerequisite is to fill out an online request for a NAAN on behalf of your organization. There is no charge to obtain a NAAN and all memory organizations are welcome. Within a day or two you should receive an email containing a NAAN for your organization's exclusive use. Meanwhile consider the following.
...
To convert ordinary web server processes into ARK-aware processes, all you difference between providing access to ARK-identified objects vs URL-identified is like with providing access for ordinary URL-identified objects. 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.
...
ARKs have some unique features that support early object development: ARKs can be deleted, can be born with no metadata, and can exist with any metadata you care to store.
But if ARKs can be deleted easily, can they be trusted?
Yes, and all the more so because deleting makes it possible to clean up the tangle of systematic errors that other identifier types are required to drag forward in perpetuity. Identifiers of all types are equally prone to the . That ARK
Can an object have both an ARK and a DOI?
Yes. To support early object development, starting with Sometimes this is useful, although it can become confusing if it happens often. Many people start by assigning ARKs to each thing they create in order to have a stable reference right from the beginning, even before they understand if they want to publish it, let alone keep it. Starting with an ARK, you benefit from being able to keep the original identifier from birth through to public release as the object and its metadata matures. To some of the ARK-identified objects you save, you might also want to assign a DOI.For the subset of things that you end up wanting to publish in places that require DOIs, you can assign DOIs at publication time. This is a way in which ARKs support early object development.
In such a scenario, to reduce the burden of maintaining both identifiers you could register 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 need maintain only one identifier (the ARK) to ensure correct resolution of both identifiers At the cost of maintaining just one identifier (the ARK), this would keep newly published links and links previously stored and bookmarked by your collaborators from breaking.
When should I use ARKs compared to DOIs, Handles, PURLs, or URNs?
...
What is meant by ARKs supporting early object development?
We People need identifiers long before we they know exactly what object they refer to, or even if they refer to anything usefulworth keeping. An identifier that requires mature metadata cannot be used created 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.
...
- 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 you will be added add as a an additional creator,
- when early feedback based on the tweeted identifier turns up a key insight and a new contributor,
- and so forth, through to archiving, abandonment, 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 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 DOIsUnlike Crossref and DataCite DOIs, which require specific metadata (eg, see the DataCite schema), ARKs do not constrain any of these activities. The N2T.net resolver in fact supports all of them.
If ARKs don't require it, why would I bother to create metadata?
...