...
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.
...
NAAN stands for Name Assigning Authority Number, which is a unique 5-digit number that begins (after the "ark:" label) every ARK. The NAAN identifies the organization that assigned the ARK and ensures that ARKs assigned by two separate different organizations can never conflictassign the same ARK. If your NAAN were 12345 and your resolver were my.example.org, your ARKs would all start with
https://my.example.org/ark:/12345/...
You may request a NAAN by filling out an an online form. The NAAN you obtain will be listed alongside all other NAANs in the public NAAN registry. Use that same form to request a change to update your NAAN entry, for example, if you to make a change to the URL for of your local server or resolver.
ARKs and other identifiers
...
- To keep costs down.
- To work with exactly the metadata I you want.
- To be able to create identifiers without metadata.
- To create an identifier as soon as I you create the first draft of my your data.
- To keep that identifier private while the data and metadata evolve, and decide (maybe years) later, to publish or discard it.
- To retain that identifier upon publication, perhaps then assigning an additional identifier, such as a DOI.
- To be compatible with the Data Citation Index ℠ and ORCID.org researcher profiles profiles (ARKs appear in both places).
- To link identifiers to different kinds of nuanced persistence commitments.
- To be able to add queries (eg, ?lang=en) when resolving my your identifiers.
- To use open infrastructure consistent with my your organization's values.
- To create one identifier that enables millions (suffix passthrough).To link directly to the objects I you value instead of to landing pages.
- To create one identifier that enables millions (suffix passthrough).
- To access convenient, full-function metadata via DRAFT ARK Identifiers FAQ.
...
Creating metadata (extra information associated with or describing an object) has several key benefits. First, no matter what the ARK redirects to – whether a landing page or a file – metadata file – metadata gives users vital information about the object, such as references to newer versions, creation date, provenance, etc. For ARKs typically metadata is accessed via DRAFT ARK Identifiers FAQ.
Metadata also eases some persistence pain. By themselves, persistent identifier strings are often opaque, revealing little about what they identify (because non-opaque identifiers do not age or travel well). But opaque identifiers are difficult because they give you no clues as to what the identifiers were meant to identify, so in . In the absence of metadata you are forced to access the object itself to remind yourself what it is, and to trust that it's the correct object. Metadata to the rescuereally helps. Moreover, discrepancies between returned metadata and the accessed object help detect identifier changes and errors.
Metadata is for grownups. It , and is far less important for immature objects and their identifiers than for those that have been released. Access to metadata Metadata demonstrates basic provider credibility and commitment to high-functioning identifiers. Not every provider is up to this task.
But metadata It need not be expensive. Building it metadata from scratch can be costly, but metadata is 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) will should be reflected in independent copies so that it is hard for someone to tamper undetectably with identifier associations.
What metadata is recommended for ARKs?
servers (eg, EZID stores metadata at the N2T resolver) so that it is hard for someone to tamper undetectably with identifier associations.
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
n An ARK typically has a four-element kernel of highly generic metadata, beyond which it can have any metadata the provider wishes. Since 2001 ARKs were meant to be interoperably indexable across the kernel elements for all object types digital, physical, and abstract. This was also a goal of an unusually generic descriptive goal, shared by the seminal metadata standard, Dublin Core (DC), used by the kernel as a point of departure. Metadata which nonetheless underlies most non-generic (domain-specific) metadata standards.
Kernel metadata is structured as if in answer to the questions of who, what, when, and where regarding the expression of, or the "telling" of, an object:
...