Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

To understand this FAQ you should first read this introduction to shoulders. Briefly, a shoulder is a sub-namespace under a NAAN.   This sub-namespace is identified by a short, fixed  alphanumeric extension to the NAAN. For example, in

...

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

Many make the 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? If you're interested, the reason is that adding a "/" after "/x5" impliesmakes two false assertions to recipients:

  1. that ark:/12345/x5 is also names an actual object, and
  2. that the original object named (ark:/12345/x5/wf6789/c2/s4.pdf is ) 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 187180637 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.

...

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. Or a shoulder can "emerge" as a repeated prefix in ARKs that you assign. This sort of shoulder appears gradually instead of deliberate decisionone 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.

...