Archival Resource Key (ARK)

Eerder hebben wij in de kennisbank al eens geschreven over het nut van duurzame identifiers voor het op lange termijn identificeren van digitale objecten. Maar hoe gebruiken we dit nou in de praktijk en bij LDMax specifiek.

De PID als unieke identifier van een digitaal object

In Linked Data zijn de eerste twee uitgangspunten die Tim Berners-Lee beschreef als volgt:

1. Gebruik URI's als namen voor gegevens ("dingen").
2. Gebruik HTTP URI's zodat mensen deze namen kunnen opzoeken.
3. Als een gebruiker een URI opzoekt moet deze URI bruikbare informatie geven. Met de standaarden voor het uitwisselen van gegevens op het web zoals Resource Description Framework (RDF ofwel Triples) en SPARQL.
4. Voeg links naar andere URI's toe zodat gebruikers meer gegevens kunnen vinden.

Met het gebruik van PID's gaan we nog een stapje verder: de HTTP URI's mogen nadat ze zijn toegekend niet meer veranderen en duurzaam bij het digitale object blijven horen. In de context van Linked Data kunnen we dus de eerste twee uitgangspunten van Linked Data herschrijven als:

1. Gebruik PID's als namen voor digitale objecten.
2. Gebruik HTTP PID's zodat mensen deze namen kunnen opzoeken

Zo maken we URI's die niet veranderen, want wederom volgens Tim Berners-Lee, "Cool URIs don't change"

De PID als HTTP URI

In de praktijk wordt een PID vaak als synoniem gebruikt voor een HTTP URI. We zeggen bijvoorbeeld:

• de HTTP URI https://hdl.handle.net/20.1000/100 is een Handle PID
• de HTTP URI https://n2t.net/ark:/12345/6789/volume3 is een ARK PID

Toch is dat niet helemaal correct. De identifiers in bovenstaande voorbeelden zijn:

• 20.1000/100
• ark:/12345/6789/volume3

Maar zonder een HTTP URI zijn deze identifiers niet echt nuttig vandaar dat we er altijd een "http(s)://" adres voorplakken. Daardoor wordt de PID een HTTP URI die we kunnnen gebruiken als naam voor digitale objecten.

De PID als naam voor digitale objecten

Over het algemeen publiceren erfgoedinstellingen hun data vanuit een collectiebeheersysteem. Een dergelijk systeem produceert records: digitale eenheden die een bepaald object of gedeelte ervan beschrijven. Denk aan een record voor een foto, boek, archiefstuk, etc. Een record is dan de kleinst opvraagbare eenheid uit de dataset die nog een compleeet verhaal vertelt over het object. We willen een record dus een naam geven die voldoet aan de Linked Data principes: een HTTP URI.

Een voorbeeld:

Het Haags Historisch Museum beheert haar records in Axiell Collections. Daar is o.a. een record beschreven met als titel De Zeilwagen. In Axiell heeft dit record de interne database id 1 gekregen. Het museum heeft gekozen voor ARK als PID systeem en heeft een Name Assigning Authority Number (NAAN) aangevraagt en gekregen: 46850. Het museum heeft ervoor gekozen als basis url https://www.haagshistorischmuseum.nl/nl te gebruiken (dat heeft het museum opgegeven bij de aanvraag van de NAAN). Met die gegevens kunnen we nu de volgende HTTP URI gebruiken om het digitale record uniek te benoemen: https://www.haagshistorischmuseum.nl/nl/ark:/46860/collection/1

(Je kunt je afvragen of het gedeelte "/nl/" in de URI een verstandige keuze was bij het registreren van de NAAN, maar dit even terzijde.)

We gebruiken hier een handige mogelijkheid van ARK: de suffix passthrough. Door de naam van de Axiell database naam (collection) in de ARK PID op te nemen, hebben we een mooie URI gemaakt die uniek is. Als alternatief hadden we een UUID/GUID kunnen gebruiken die bij het record hoort, zonder suffix passthrough, bijvoorbeeld: https://www.haagshistorischmuseum.nl/nl/ark:/46860/f8551cfb-26ea-4a2a-93d0-2fc17329ef87

Het voordeel van deze tweede aanpak is dat bij verhuizing van het digitale object naar een ander collectiebeheersysteem de UUID mee kan verhuizen als uniek kenmerk in het collectiebeheersysteem.

Een gebruiker moet de PID op kunnen zoeken

Nu we een coole, duurzame HTTP URI hebben, willen we natuurlijk dat een gebruiker die kan opzoeken (2e principe van Linked Data). In Linked Data noemen we dit dereferencing of resolving (zie ook ons andere artikel over dit onderwerp) . In ons eerder voorbeeld van het Haags Historisch Museum zagen we dat zij ervoor gekozen hebben om https://www.haagshistorischmuseum.nl/nl/ te gebruiken om hun ARK's op te kunnen zoeken. Dat gaat echter niet vanzelf! De domeinnaam "www.haagsmuseum.nl" is in eigendom van het museum. Zij zijn dus de enige die ervoor kunnen zorgen dat de ARK URI's uiteindelijk bij het digitale object uitkomt. Momenteel hebben zij daar geen voorziening voor getroffen, waardoor de gebruiker een foutmelding krijgt: "Het spijt ons, maar deze pagina bestaat niet…".

Het wordt nog iets complexer omdat een "gebruiker" niet alleen een mens hoeft te zijn, maar ook een computer. Een mens wil waarschijnlijk een mooie interactieve webpagina zien van het digitale object, eventueel met afbeeldingen en andere functionaliteit. Een computer wil waarschijnlijk alleen de digitale data (in RDF formaat) hebben. De computer kan dan een zgn. HTTP Accept Header meesturen (bijvoorbeeld text/turtle) en krijgt dan op dezelfde HTTP URI een andere representatie van het digitale object opgelevert. Dit principe maakt integraal onderdeel uit van een goede Linked Data infrastructuur, we kunnen niet volstaan met alleen webpagina's met een downloadlink naar RDF data, het principe van Content-Negotiation zal ook door de eigenaar van de domeinnaam (Het Haags Historisch Museum in dit voorbeeld) gefaciliteerd moeten worden.

Alternatieve oplossing

Omdat het opzoeken van PID's zoals hierboven beschreven helemaal niet zo eenvoudig is, biedt LDMax een alternatieve oplossing. Als we weer de casus van het Haags Historisch Museum gebruiken, dan hadden zij in plaats van zelf een derefencer te (laten) maken en te onderhouden, ook kunnen kiezen voor een subdomein oplossing: data.haagsmuseum.nl (of een andere variant, maar"data" wordt veel gebruikt in dit soort situaties). Zij zijn dan nog steeds volledig in controle over hun eigen PID's, de domeinnaam blijft immers van hun. Het enige wat het Haags Museum nu nog hoeft te doen is de subdomeinnaaam data.haagsmuseum.nl te koppelen aan LDMax via "telefoonboek van het internet" DNS. Dat is een hele eenvoudige administrative aanpassing waarvoor verder geen technische expertise nodig is.

Stappenplan om zelf met ARK aan de slag te gaan

1. subdomeinnaam (data.voorbeeld.nl) bedenken en vastleggen in de DNS: data.voorbeeld.nl => www.ldmax.nl
2. NAAN aanvragen bij de ARK Alliance door dit formulier in te vullen. Bij het invullen geef je de subdomein op in stap 5 bij "Organization base URL".
3. Zorg dat je als identifier van je digitale objecten het patroon https://data.voorbeeld.nl/ark:/12345/... volgt.

Dat is alles! De rest regelt LDMax voor je, zowel de webpagina voor mensen (zie het voorbeeld van De Zeilwagen), als de content-negotiation voor computers.