...
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
...
, how can they be trusted?
Being able to delete identifiers actually helps make ARKs more trustworthy. The ability to delete is a vital part of healthy collection management that is denied to those non-ARK identifier types prohibiting it under the presumption that people, once they are asked to commit, won't make mistakes.
People, being only human, who regularly work with software do regularly leave tangles of systematic errors, even at the threshold of commitment. Making it difficult to clean up such messes requires dragging those messes forward in perpetuity.
Not perfect in this respect, ARKs still have the advantage that they can be created and deleted in the shadows, independent of publication or commitment to preservation.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?
...
Unlike 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 actually supports all of them.
If ARKs don't require it, why would I bother to create metadata?
...
Although inflections are commonly associated with ARKs, they are not "owned" by ARKs. In fact, contrary Contrary to popular belief, identifiers don't do anything – it's their resolvers that do or don't support such features. So, for example, inflections and suffix passthrough are supported by n2t.net for all identifier types, but not by doi.org or handle.net for any identifier types.
...