Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Frequently Asked Questions and Answers about ARK Shoulders

How can I give feedback on this document?

By inserting comments into XXX this comment-friendly version.

What are Shoulders?

Please see this introductory material on shoulders.

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 "/x5not followed by a "/"? According to ARK rules, if you had published

(please don't do this)     ark:/12345/x5/wf6789/c2/s4.pdf

the "/" after "/x5" implies

  1. that ark:/12345/x5 is also an object and
  2. that the object named ark:/12345/x5/wf6789/c2/s4.pdf 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 "/" because it makes 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 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 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.

How do I implement a shoulder?

There are different ways to implement a shoulder. Fundamentally, a shoulder is a deliberate practice based on a decision you make to assign 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 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.

As a second special case applicable to ARKs stored in the resolver (EZID, Internet Archive, and YAMZ ARKs), it is possible to create a short ARK identifier, 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 shoulder.

A completely different kind of shoulder "creation" step is needed to implement a shoulder under one of the few shared NAANs (below).

Is there a quick way to get started creating test ARKs?

Yes. Instead of reserving a 99999 shoulder, if your organization already has its own NAAN, you can immediately create and use a "quick test ARK". This is an ARK that starts with ark:/99999/9NNNNN_, where NNNNN represents the NAAN (preceded by '9' and followed by '_'). There is no need to register a quick test namespace since it is automatically set aside for each NAAN. As with any prefix, there is an infinite number of possible test ARKs in each NAAN's quick test namespace. Two versions of an example quick test ARK belonging to the BnF (NAAN 12148) are

Note that is configured to forward any quick test ARK it receives (second version above) to the appropriate local resolver (first version).

Can I make changes to a NAAN or a shared shoulder?

You can change the registry entry for a NAAN by filling out the same online form used for requesting a new NAAN. 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 NAAN, eg, to support a significant new body of ARKs or new organizational division, and
  • transitioning your NAAN to another organization that will carry on your work and future use of your NAAN.

NAANs are portable. If your organization transitions into or out of a vendor relationship, there is no impediment to taking your NAAN with you.

  • No labels