...
To understand this FAQ you should first understand read this introduction to shoulders. Briefly, a shoulder is a sub-namespace under under a NAAN. In particular, it is the set all ARKs starting with This sub-namespace is identified by a short, fixed fixed alphanumeric extension to the NAAN. For example, in
the shoulder, /x5, extends the NAAN, 12345.
How do I format a shoulder?
Start with your NAAN and decide on a short, fixed extension that you will add to it. The extension should
- start with one or more lowercase letters,
- end with a digit (non-zero preferred), and
- contain no vowels or the letter 'l' (ell).
Some more detail is given in response to the next question.
Why is there no "/" to mark the end of a shoulder?
In other words, in an ARK such as ark:/12345/x5wf6789, why is the shoulder "/x5" not followed by a "/"? According to ARK rules, if you had published
Many people make the initial mistake of adding a "/" between the end of the shoulder and the rest of the ARK, for example,
(please don't do this) ark:/12345/x5/wf6789/c2/s4.pdf
^ WRONG!
It's natural to want to visually mark the shoulder's end, but it's prohibited by ARK rules.
Why? The reason is that adding a "/" after "/x5" impliesmakes two false assertions:
- that
ark:/12345/x5is also names an actual object, and - that the original object named (
ark:/12345/x5/wf6789/c2/s4.pdfis ) is contained in it.
Both are likely untrue, at least in any way that can be easily explained to a user. It may seem natural to add a Adding a "/" because it makes might make the shoulder boundary obvious to in-house ARK administrators. Recalling that in-house specialists can afford to be inconvenienced, it doesn't help the end user either is uninterested and confused by your internal operational boundaries, or is so very interested that you , but recall that they are trained specialists. The end user has no business knowing your internal operational details, and if they did you would risk their trying to hold you to account for their inferences (eg, about consistent support levels across objects sharing the apparent containing object). Less transparency about administrative structure hides messy details and can save you user-support time in the end.
In fact, in-house ARK administrators always know where the shoulder ends, provided it was chosen using the "first-digit convention". A primordinal shoulder is a sequence of one or more betanumeric letters characters ending in a digit. This means that the shoulder is all letters (often just one) after the NAAN up to and including the first digit encountered after the NAAN. Another advantage of primordinal shoulders is that there is an infinite number of them possible under any NAAN.
...
There are different ways to implement a shoulder. Fundamentally, a shoulder is a the deliberate practice based on a decision you make to assign of assigning ARKs that start with a particular extension to your NAAN. A shoulder can then "emerge" while your practices consciously observe and incorporate that extension as a prefix in ARKs that you assign. This sort of shoulder appears gradually instead of suddenly in one moment of creation.
Having said that, there are two special cases where shoulder implementation does involve a kind of "creation" step. First, a system such as ezid.cdlib.org supports both the purely "decision-based" shoulders above (that emerge from user practice, eg, Smithsonian) as well as an administrative action that sets up a system-defined shoulder. The details depend on the system, for example, an "EZID shoulder" has accompanying minter service and registered API access point. By contrast, implementing a decision-based shoulder requires no explicit shoulder creation step, but does involve the creation of one or more ARKs that start with that shoulder.
a NAAN. You could implement two shoulders simply by assigning ARKs beginning ark:/12345/x8 only to apples and ARKs beginning ark:/12345/x9 only to oranges.
As a second special case applicable to ARKs stored in the N2T.net resolver (EZID, Internet Archive, and YAMZ ARKs), it is possible to create a short ARK identifier, such as If you use a service that stores ARKs in the N2T.net resolver, such as ezid.cdlib.org, then you can supplement that practice in two different ways. First, you could take advantage of N2T's suffix passthrough feature by creating a short ARK, such as ark:/99152/p0, that looks and acts like a shoulder. To make it work, it suffices for that ARK to redirect to a server URL that can handle N2T's suffix passthrough feature. The more familiar you are with this feature, the more you will be able to see that short ARK identifier as the root of a namespace that is, effectively, a shoulderall the ARKs on that shoulder (eg, the Smithsonian does this), and you wouldn't have to store or manage any other ARKs on that shoulder at N2T. Second, the EZID service (and perhaps others), associates a shoulder with a minter service and an API access point.
A completely different kind of shoulder "creation" step is needed to implement a shoulder under one of the few shared NAANs (below).
...
How do I request or make changes to a shoulder under a shared NAAN?
As mentioned, to implement a shoulder under your own NAAN requires no special request. To implement or change a shoulder under a shared NAAN, however, requires getting into the shared NAAN
...
shoulders registry, which means filling out an online shoulder form. For security purposes requests are processed manually. Example reasons for a change may include
- notifying N2T of a change in your organization's contact person or resolver URL,
- updating your organization's name assignment policy (sample policy),
- requesting an additional shoulder, eg, to support a significant new body of ARKs or new organizational division, and
- transitioning your shoulder to another organization that will carry on your work and future use of your shoulder.
Like NAANs, shoulders under shared NAANs are portable. If your organization transitions into or out of a vendor relationship, there is no impediment to taking your shoulder with you.