...
To anything digital, physical, abstract. This often includes things that don't yet exist but that you need to reference from objects that you're in the process of creating or planning, such as a link from a draft article to a dataset under preparation, or a link from an archived digital letter to a planned finding aid.
One caveat is that you should generally assign ARKs to things that you own, control, or manage. ARKs, or any identifiers, that you assign to things you don't control are discouraged as they tend to be fragile.
...
Yes, ARKs can be assigned at any level of granularity, such as to a manuscript, to chapters inside it, to chapter sections, subsections, etc. An ARK can also be assigned to a thing that encloses other things. In ARKs the character '/' is reserved to help the recipient understand about containment, for example, the first ARK below contains the second ARK:
...
Yes, two ARKs that differ only by a suffix are considered variant forms of the same thing. The character '.' is reserved to help the recipient understand that, for example, these two ARKs identify two different formats of the same document:
ark:/12148/btv1b8449691v/f29.pdf
ark:/12148/btv1b8449691v/f29.html
...
Serving ARKs is like serving URLs.
How do I start serving my ARKs?
Serving ARKs is like serving URLs.
How do I start serving my ARKs?
Serving ARKs is like serving URLs. Normally incoming URL strings address (get mapped to) content that you returnyour web server returns. If your server is ARK-aware, incoming ARKs (expressed as URLs) must be mapped to the same content. A common approach is to map the ARK to the URL using a software table that you update whenever the URL changes. In this case your server is acting as a local resolver. That means that you will advertise your URL-based ARKs rooted at your own resolver's hostname. There are some plugins (eg, for Omeka), that do this for youIf you don't want to implement this yourself, there are ARK software tools and services that can help.
Another approach is to run your web server without change, but instead of updating local tables, you update ARK-to-URL mapping tables residing at a non-local resolver. Examples of this approach can be found in any organization that uses an API/UI to update tables residing at the n2t.net resolver via ezid.cdlib.org. There are vendors that provide similar services.
nstead of update ARK If you choose to run your own ARK infrastructure, you get complete autonomy at the expense of maintaining a server/resolver. On the one hand, you might run all custom infrastructure – including content management, web hosting, minting (generating unique identifier strings), and running your own server/resolver. That infrastructure could be very simple, such as server configured to map incoming ARK-based URLs to server file pathnames. When you request your NAAN you will be asked to supply the base URL of your local server or resolver.
At the other extreme, you might work with a vendor that supplies all the infrastructure so that, for example, you can focus on creating content. Hybrid solutions are also common, such as just taking your current web server arrangement and just adding an identifier management piece (eg, the API/UI provided by ezid.cdlib.org, which partners with n2t.net).
You will also want to think about whether to advertise (release, publish, disseminate) your ARKs based at your resolver or at n2t.net. You might choose the former for branding or the latter for stability. Resolving your ARKs through n2t.net is always possible, regardless of how you advertise them (this is a side-effect of obtaining a NAAN).
to anything digital, physical, abstract, etc. This often includes things that don't yet exist but that you need to reference from objects that you're in the process of creating or planning, such as a link from a draft article to a dataset under preparation, or a link from an archival object to a planned finding aid.
...
One caveat is that you should generally assign ARKs to things that you own, control, or manage. ARKs, or any identifiers, that you assign to things you don't control will tend to be fragile.
- Will you assign ARKs to things contained in larger things that have ARKs? This (granularity) is not a problem, and the '/' character may help.
- Where do you want your ARKs to resolve to? Examples: formatted file, surrogate for a physical thing, landing page with choices, etc.
- Which web server will host your objects? You are asked this when you request a NAAN, even if it's not yet working.
- Which web server/resolver will you use as hostname in the ARK-based URLs that you advertise/publish?
| Anchor | ||||
|---|---|---|---|---|
|
There's a partial list of software tools for persistent identification that includes
...