Closed RussellMcOrmond closed 9 months ago
ARKs have been discussed previously, such as: Proposal: Collection member lists should reference slugs as opposed to noids.
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.
Shows the same content as: https://www.canadiana.ca/view/oocihm.52709/1 , which is the first page of the manifest.
shows https://www.canadiana.ca/view/oocihm.52709/5 , which is the 5'th page of the manifest.
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/
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 (@jjfriedman ) 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
We allocate NOID's for access object, which is currently:
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.