...
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,
...
Why? If you're interested, 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.
...
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).
...