...
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.
...
It need not be expensive. Building metadata from scratch can be costly, but it's usually created and managed by object providers, in which case it can be leveraged efficiently for identifiers. Ideally, for strong persistence master metadata (maintained by object providers) should be reflected in independent servers (eg, EZID stores metadata at the N2T resolver) systems so that it is hard for someone to tamper undetectably with identifier associations. For example, digital object repositories that obtain ARKs and DOIs from the EZID service store a copy of their metadata with EZID.cdlib.org, which in turn stores another copy with the N2T.net resolver.
What metadata is recommended for ARKs?
If you already have mature metadata practices, there are some good options. it is best to keep following them and that follows a Dublin Core, DataCite, or Crossref
If you're not attached to any particular metadata practice, there are also some good options. If publication will be important, you may wish to adopt publisher-friendly metadata (eg, Crossref), then follow the advice above. If
World metadata is a mess. There are thousands of "standards", each applied according to unique local practices. none of which are followed strictly.
If you don't already have metadata
Metadata is messy business for all identifiers, not just ARKs. Across domains and object types there are thousands of standards, many of them overlapping yet conflicting, and each is applied according to local organizational customs and with varying levels of compliance. Choosing or creating a specification for your metadata depends on factors such as
- what metadata, if any, you are currently managing (hint: stay with it unless you have a good reason to switch),
- whether you want to officially publish (hint: prepare to be able to supply author, title, date, publisher/archive, and object type),
- the requirements and capabilities of your resolver (hint: your IT staff or vendor might have its own requirements), and
- whether you want to store non-standard elements (hint: N2T allows this, but most standards and vendors don't).
Reliable cross-domain interoperation may remain out of reach, but Dublin Core, DataCite, and Dublin Kernel are common metadata specifications in use with ARKs.
What is Dublin Kernel metadata for (who, what, when, where)?
An n ARK typically has a four-element kernel of highly generic metadata, beyond which it can have any metadata followed by any other metadata elements (name/value pairs) the provider wishes to provide. Since 2001 ARKs were meant to be interoperably indexable across the kernel elements for all object types digital, physical, and abstract. This was an unusually generic descriptive goal, shared by the seminal metadata standard, Dublin Core (DC), which nonetheless underlies most non-generic (domain-specific) metadata standards.
...