...
The only prerequisite is to fill out an online request for a NAAN on behalf of your organization. There is no charge to obtain a NAAN and all memory organizations are welcome. Within a day or two you should receive an email containing a NAAN for your organization's exclusive use. Meanwhile consider the following.
...
To convert ordinary web server processes into ARK-aware processes, all you difference between providing access to ARK-identified objects vs URL-identified is like with providing access for ordinary URL-identified objects. For example, you could run all your own 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 convert 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 end of the spectrum, you could work with a vendor that supplies all the infrastructure so that, for example, you could 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).
If you run a resolver, you will also want to think about whether to advertise (publish) your ARKs based at your resolver or at n2t.net. Resolving through n2t.net is always possible as a cost-free side-effect of obtaining a NAAN.
...
Metadata is for grownups. It is far less important for immature objects and their identifiers than for those that have been released. Access to metadata demonstrates basic provider credibility and commitment to high-functioning identifiers. Not every provider is up to this task.
Metadata for identifiers But metadata need not be expensive. Building it from scratch is expensivecan be costly, but metadata is usually created and managed by object providers, in which case it can be leveraged efficiently for identifiers. Ideally, for strong persistence master metadata (maintained by object providers) will be reflected in independent copies so that it is harder hard for someone to tamper undetectably with identifier associations meant to be truly persistent.
What metadata is recommended for ARKs?
...
An ARK typically has a kernel of four elements of highly generic metadata, beyond which it can have any metadata the provider wishes. Since 2001 ARKs were meant to be interoperably indexable across the kernel elements for all object types digital, physical, and abstract. This was also a goal of the seminal metadata standard, Dublin Core (DC), used by the kernel as a point of departure. Metadata is structured as if in answer to the questions of who, what, when, and where regarding the expression of, or the "telling" of, an object:
- who "told" it (similar to DC Creator, Contributor, and Publisher, but also Inventor, Discoverer, Conductor, etc),
- what the "telling" was called (similar to DC Title, but also TissueSampleNumber, ArtifactBarcode, etc),
- when it was "told" (similar DC Date, but includes date ranges, approximate and BCE dates),
- where the "telling" can be found (from DC Identifier, but usually not needed because this is the ARK itself).
- who expressed it (Creator, Contributor, Publisher, Discoverer, Inventor, etc)
There's much more to say about ARK metadata (available soon at arks.org), with too many details to cover in a basic FAQ. Other elements are critical, such as
- how it was "told" (similar to ResourceType)
- redirection target URL, which is usually stored as an element of metadata
- persistence statements, to express the strength or weakness of an archival commitment
In order to be able to describe almost anything, ARKs typically have distinctively generic metadata. As if answering questions about an object's expression or form,
who expressed it (Creator, Contributor, Publisher, Discoverer, Inventor, etc)
what was the expression called (Title, Name, Catalog Number, or other human-readable identifier)
when was it expressed (Created, Modified, Discovered, Observed)
where the expression is to be found (the best persistent identifier for citation and external reference)
target URL (for resolvers, the best current URL to forward to)
XXX Uses extremely generic metadata elements
Why do ARKs use <who, what, when, where> (Dublin Kernel) metadata? xxx
Since their inception in 2001, ARKs have always had a distinctively generic approach to metadata. which other identifier types have begun ARKs were meant to cover an enormous range of object types, spanning everything digital, physical, and abstract, and crossing all domains and sectors. This is quite a challenge since each subdivision of such a vast range tends to have its own unique metadata vocabulary for describing things.
The first
discovery and use (or re-use by others)
...
| Anchor | ||||
|---|---|---|---|---|
|
...