...
To anything digital, physical, abstract. That can include things that don't yet exist but to which you need to refer 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 create ARK strings as you wish, provided that you use only digits, letters , digitsupper- and lower-case letters (ASCII, no diacritics), and the following characters:
= ~ * + @ _ $ . /
The last two characters are reserved in case the event you want wish to reveal disclose ARK relationships. Hyphens A unique feature of ARKs is that hyphens ('-') can may appear but are identity inert, meaning that strings that differ only by hyphens are considered to be the same stringidentical; for example, these strings,
ark:/12345/141e86dc-d396-4e59-bbc2-4c3bf5326152
ark:/12345/141e86dcd3964e59bbc24c3bf5326152
must be treated as identical. This helps make all ARKs persistent because text formatting processes that introduce hyphens will break most other identifiers.
are always ignored in ARKs.
A `-' (hyphen) may appear in an ARK for readability, or it may have crept
in during the formatting and wrapping of text, but it must be ignored in
lexical comparisons.
identify the same thing. The reason for this feature is that text formatting processes out in the world routinely introduce extra hyphens into identifiers, breaking links to any server that treats hyphens as significant.
Regarding assignment strategy, it . It is common to leverage legacy identifiers; for . For example, a museum moth specimen number cd456_f987 could might be advertised under under the ark:/12345/cd456_f987 (assuming 12345 is your NAAN)cd456_f987. Some legacy identifiers may need to be altered in view of ARK character string restrictions, eg, be careful with hyphens..
The second common strategy is to make up entirely new strings for your ARKs. In this case If you are creating entirely new ARKs, it is important to consider whether to make them opaque , or non-opaque , (or a bit of both).
What are opaque identifiers?
Persistent identifier strings are typically opaque, deliberately revealing little about what they're assigned to, because non-opaque identifiers do not age or travel well. Organization names are notoriously transient, which is why NAANs are opaque numbers. As titles and dates are corrected, word meanings evolve (eg, and innocent old older acronyms may become offensive or infringing), strings meant to be persistent can become confusing or politically challenging. Generating The generation and assigning assignment of completely opaque strings come comes with risk too, for example, numbers assigned sequentially reveal time timing information and strings containing letters can unintentionally spell words.
| 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 |
With ARKs there are is no rules requirement for opacity, but it is recommended that at least the base ARK object name (the ARK minus any hostname or qualifier) be made opaque, since the base object tends to be the main focus of persistence efforts. Persistence, hence opacity, of any qualifiers that might follow tends to be less important.
You will probably want to consider tradeoffs regarding compatibility with legacy identifiers, as well as ease of string generation and transcription (eg, brevity, check digits). New strings can be created (minted) with date/time, UUID, and number generators, as well as Noid (Nice Opaque Identifiers) minters.
While opaque strings avoid these problems, they can also be hard to administer. (Hint:Finally, opaque strings can be hard to administer because they are so "mute". The situation is greatly relieved by identifiers that tell you about themselves, or ARKs that return metadata to the rescue!)
How do I serve my ARKs?
First, decide what the user experience of accessing your ARKs will be, for example, a spreadsheet file, a PDF, an image, a landing page filled with formatted metadata and a range of choices, etc. Whichever you choose, plan for your server to be able to respond with metadata if your ARK should arrive with a '?' inflection after it.
Otherwise, 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. 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 would update ARK-to-URL mapping tables residing at a non-local resolver. Examples of this can be found among vendors and in any organization that updates tables via ezid.cdlib.org (which, due to a special relationship, updates resolver tables at n2t.net).
How do I advertise my ARKs?
An important decision is whether you will advertise (release, publish, disseminate) your URL-based ARKs under a local hostname or the N2T.net resolver. If local control or branding is important enough, you would advertise ARKs based at your local resolver. If you're concerned about the stability of your local hostname, you would advertise your ARKs based at n2t.net (see examples of both).
Resolving your ARKs through n2t.net is always possible for users, regardless of how you advertise them.
...
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.
...
- To keep costs down.
- To work with exactly the metadata you want.
- To be able to create identifiers without metadata.
- To have an identifier as soon as even before you create the first draft of your data.
- To hold 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.
- Because ARKs were , built for generic application and don't have to be tortured into identifying physical samples or not just publication, fit naturally into identifying physical samples and field stations.
- Because they won't break as text formatting processes out in the world routinely introduce hyphens into identifiers.
- To be able to change vendor and/or infrastructure without having to coordinate a database transfers with a central authority.
- To be able to create a larger number of identifiers of a given length, since mixed case letters permit denser strings.
- To be able to deal with the namespace splitting problem without losing control of your identifiers.
- To link identifiers to different kinds of nuanced persistence commitments.
- To be able to add queries (eg, ?lang=en) when resolving your identifiers.
- To use open infrastructure consistent with your organization's values.
- To link directly to the objects you value instead of to landing pages.
- To create one identifier that enables millions (suffix passthrough).
- To access convenient, full-function metadata via inflections.
...