...
To anything digital, physical, abstract. That can include things that don't yet exist but that you need to reference from objects that you're in the process of creating or planning, such as a link from a draft article to a dataset under preparation, or a link from an archived digital letter to a planned finding aid.
One caution is that you should generally assign ARKs to things that you own, control, or manage. Assigning ARKs to things you don't control is discouraged because such identifiers tend to be fragile.
...
You are free to generate new strings as you wish. It is common to leverage legacy identifiers by taking, for example, by taking museum butterfly moth specimen number cd456_f987 and calling it ark:/12345/cd456_f987 (assuming 12345 is your NAAN). Some legacy identifiers may contain characters that need to be altered in view of ARK character string restrictions, eg, be careful with hyphens.
If you are creating entirely new ARK identifier strings, it is important to consider whether they will be to make them opaque, non-opaque, or a bit of both. Persistent identifier strings are often opaque, deliberately revealing very little about what they identify're assigned to, because non-opaque identifiers do not age or travel well. Here's a range of example strings:
...
Organization names are notoriously transient, which is why NAANs are numbers. As titles and dates are corrected, word meanings evolve, and innocent old acronyms become offensive or infringing, strings meant to be persistent can become confusing or politically challenging. Opaque identifiers avoid these problems, but on the other hand, can be hard to administer (hint: metadata really helps).
There are no rigid rules, only tradeoffs regarding things like ease of generation, legacy compatibility, transcribability (check digits), and brevity. Strings can be created (minted) with software counters, date/time and UUID generators, and Noid (Nice Opaque Identifiers) minters.
| Example strings with a range of opacity | |||
|---|---|---|---|
| non-opaque | Netscape Permanent Archive | Gay_Divorcee_1934_April_1 | Name-to-Thing Resolver |
| opaque-ish | x0001, x0002, ..., x9998 | GD/1934/04/01 | n2t.net |
| opaquer | 141e86dc-d396-4e59-bbc2-4c3bf5326152 | 19340401 | n2t |
| opaquest | 141e86dcd3964e59bbc24c3bf5326152 | h8k74926g | 12148 |
But opaque identifiers are difficult because they give you no clues as to what the identifiers were meant to identify. 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 really helps.
xxx opaque, non-opaque
You may assign ARKs using strings that you invent or generate (mint) at the moment of assignment or that leverage existing identifiers. have create construct any ARK strings you wish, provided they start with your NAAN The character strings used to construct ARKs are made of digits, letters (without diacritics), and a few extra characters xxx ref. Generally people concerned with persistence ch
...
How do I start serving my ARKs?
Serving ARKs is like serving URLs. Normally incoming URL strings address (get mapped to) content that your web server returns. If your server is ARK-aware, incoming ARKs (expressed as URLs) must be mapped to the same content. A common approach is to map the ARK to the URL using a software table that you update whenever the URL changes. In this case your server is acting as a local resolver. That means that you will advertise your URL-based ARKs rooted at your own resolver's hostname. If you don't want to implement this yourself, there are ARK software tools and services that can help.
Another approach is to run your web server without change, but instead of updating local tables, you update ARK-to-URL mapping tables residing at a non-local resolver. Examples of this approach can be found in any organization that uses an API/UI to update tables residing at the n2t.net resolver via ezid.cdlib.org.
xxx
nstead of update ARK If you choose to run your own ARK infrastructure, you get complete autonomy at the expense of maintaining a server/resolver. On the one hand, you might run all 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 map 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 extreme, you might work with a vendor that supplies all the infrastructure so that, for example, you can 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).
You will also want to think about whether to advertise (release, publish, disseminate) your ARKs based at your resolver or at n2t.net. You might choose the former for branding or the latter for stability. Resolving your ARKs through n2t.net is always possible, regardless of how you advertise them (this is a side-effect of obtaining a NAAN).
to anything digital, physical, abstract, etc. This often includes things that don't yet exist but that you need to reference from objects that you're in the process of creating or planning, such as a link from a draft article to a dataset under preparation, or a link from an archival object to a planned finding aid.
...
One caveat is that you should generally assign ARKs to things that you own, control, or manage. ARKs, or any identifiers, that you assign to things you don't control will tend to be fragile.
...
...
Yes, ARKs can be assigned at any level of granularity, such as to a manuscript, to chapters inside it, to chapter sections, subsections, etc. An ARK can also be assigned to a thing that encloses other things. In ARKs the character '/' is reserved to help the recipient understand about containment, for example, the first ARK below contains the second ARK:
ark:/12148/btv1b8449691v
ark:/12148/btv1b8449691v/f29
That's the containment qualifier. There's only one other ARK qualifier, and it indicates variant forms of a thing by using the reserved character '.' in front of a suffix. For example, if these ARKs identify documents,
ark:/12148/btv1b8449691v/f29.pdf
ark:/12148/btv1b8449691v/f29.html
because they differ only by the suffix .pdf or .html, it can be inferred that they identify two different forms of the same document.
...
Unlike Crossref and DataCite DOIs, which require specific metadata (eg, see the DataCite schema), ARKs do not constrain any of these activities. Moreover the N2T.net resolver actually supports all of them.
Anchor metadata metadata
If ARKs don't require it, why bother creating metadata?
| metadata | |
| metadata |
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 gives users vital information about the object, such as references to newer versions, creation date, provenance, etc. For ARKs typically metadata is accessed via inflections.
...