...
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?
Many people make the initial mistake of adding a "/" between the end of the shoulder and the rest of the ARK, for example,
...
It's natural to want to visually mark the shoulder's end, but it's prohibited by ARK rules.
Why? If you're interested, the The reason is that adding a "/" after "/x5" makes two false assertions to recipients:
- that
ark:/12345/x5also names an actual object, and - that the original object (
ark:/12345/x5/wf6789/c2/s4.pdf) is contained in it.
...
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. Or a shoulder can "emerge" as a repeated prefix in ARKs that you assign. This sort of shoulder appears gradually instead of one particular action.
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).
...
As mentioned, to implement a shoulder under your own NAAN requires no special request. To implement or change a shoulder under a shared NAAN requires , 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
...