Supporting Archival Resource Keys (ARKs)

[brittnylapierre]

Some of this work was done as part of the Preservation-Access Split project, but there is work to complete and discussions necessary with other parts of CRKN before announcing this as a feature.

CRKN asked for the allocation of a Name Assigning Authority Number (NAAN) for CRKN on August 19, 2019 (See Emails "NAAN request for CRKN")

Current entry in : http://n2t-dev.n2t.net/e/n2t_full_prefixes.yaml

ark:/69429:
type: "naan"
manager: "n2t"
name: "Canadian Research Knowledge Network (=) CRKN"
date: "2019.08.17"
redirect: "https://www.canadiana.ca/ark:$id"
na_policy: "NP | (:unkn) unknown | 2019 |"
We allocate NOID's for access object, which is currently:

Collections
Manifests
Canvases (currently only image canvases)
Taking https://www.canadiana.ca/view/oocihm.N_00208_18860727 as an example.

slug=oocihm.N_00208_18860727
noid=69429/m03j39020v85

If we try to go to the ARK resolver https://n2t.net/ark:/69429/m03j39020v85 , this redirects to https://www.canadiana.ca/ark:/69429/m03j39020v85 which is currently a "not found".

It is relatively simple to look up that NOID to find out what portal and what slug should be redirected to. The web interface might also provide a list of portals if the given noid is available on multiple portals.

Note to developer: While CAP is authored in Perl, the ARK redirection doesn't need to be. We use haproxy in front of all these URLs, and can send https://www.canadiana.ca/ark: to a special ARK handling web service.

ARKs have been discussed previously, such as: https://github.com/crkn-rcdr/Access-Platform/discussions/205.

CRKN will want to spend some time thinking about identifiers, which are persistent, which are opaque, and which are transparent.

We should ensure that identifiers that patrons reference our content with (in web pages, or as references in other documents) are persistent, and never changed once they are made public (other than for a legal take-down/etc, which we'll want to think about how to represent other than a "not found" message).

With the legacy platform there was only a single identifier for AIPs and for the website (what are currently slugs, now separate from AIP IDs).

With Archivematica the AIP identifiers (names) will be enforced to be opaque via a UUID being appended.

Reminder:

We have a system set up to redirect the old ECO platform links to the newer CAP platform, and I hope we will continue to do so.

Example: http://www.canadiana.org/ECO/ItemRecord/9_01391

Documents which reference the older URLs will always exist, and we should do our best to redirect people as close to what they wanted as we can.

For developers: that redirect logic is in https://github.com/crkn-rcdr/cap/blob/main/apache/httpd-vhosts.conf

Thought about in-context and out-of-context ARK's.

https://www.canadiana.ca/ark:/69429/m0dj58c9w20p would redirect to https://www.canadiana.ca/ark:/69429/m0dj58c9w20p:/69429/c0ht2gb0mr9d
Shows the same content as: https://www.canadiana.ca/view/oocihm.52709/1 , which is the first page of the manifest.

https://www.canadiana.ca/ark:/69429/m0dj58c9w20p:/69429/c00v89k2vv35
shows https://www.canadiana.ca/view/oocihm.52709/5 , which is the 5'th page of the manifest.

https://www.canadiana.ca/ark:/69429/c00v89k2vv35
Would show that page without the context provided by the manifest, and only show description that was given specifically to that page.

Supporting having multiple ARK ID's on a path would allow us to show context in a variety of situations, such as a manifest that might be within more than one collection so the URL would be specific about which collection. The old platform had the concept of a single "parent" for ordered collections, which doesn't make sense in a IIIF context.

If any of the NOIDS weren't found or weren't accessible for some reason, the additional context could be used to show something related (IE: the specified canvas within a different manifest, the specific manifest that no longer contains that canvas, etc).

(Copying from https://github.com/crkn-rcdr/Access-Platform/issues/536 )

I hope we will do something smarter with document viewing and collections.

a) Look up the slug or noid.
b) If the document is in the current portal, show it.
c) If the document has a collection list representing a single portal, then redirect to the correct portal.
d) if none of the above, then display a page indicating that the document exists, and what portals it is available on. Display a special note if no portal offers the document.

The current "404" page is the same whether the ID doesn't exist, or it exists but just not in the right collections.

Worth keeping this in mind:

https://arks.org/blog/images-and-the-promise-of-arks-with-iiif/