Publicatie:Handboek Persistente URI’s voor cultureelerfgoedcollecties

Uit Meemoo Kennisbank
Naar navigatie springen Naar zoeken springen


Samenvatting

Dit document bevat richtlijnen en goede praktijken om cultureel erfgoedobjecten te identificeren op het web met persistente URI’s en is bedoeld voor beleidsmakers, collectiebeheerders, publieksmedewerkers en ICT-medewerkers in erfgoedorganisaties.


Referentie
Titel Handboek Persistente URI’s (Voorkeurstitel)
Locatie 20230602-Handboek-Persistente-URI's-voor-cultureelerfgoedcollecties.pdf
Uitgever
Jaar van uitgave 2023
Rechten CC-BY-SA
Persistent ID


Inleiding

In een digitale samenleving wordt van erfgoedorganisaties verwacht dat ze informatie en beelden over cultureelerfgoedobjecten delen via het web. Mensen zoeken informatie over cultureel erfgoed via zoekmachines en verwachten langs die weg ook betrouwbare antwoorden te vinden op hun vragen. Dat geldt voor cultuurliefhebbers die zich voorbereiden op een citytrip, voor studenten die een schoolopdracht krijgen, maar evenzeer voor onderzoekers die erfgoedobjecten als bron gebruiken voor hun onderzoek. Allemaal gebruiken ze het web als eerste zoekingang om informatie te verzamelen. Ook erfgoedorganisaties zelf maken in hun werking steeds meer gebruik van het web en ontwikkelaars verwachten dan ook dat alle content voor het bouwen van webapplicaties eenvoudig toegankelijk en herbruikbaar is via het web.

Uniform Resource Identifiers (URI) vormen een van de hoekstenen van het web. Het web is een virtuele ruimte waarin documenten en andere informatiepakketten uitgewisseld worden tussen computersystemen. URI’s vervullen daarin de rol van een ‘virtueel adres’ waarmee je documenten en informatiepakketten terugvindt op andere machines dan die van jou. Als je de documenten en informatiepakketten op lange termijn toegankelijk wil houden, zijn de URI’s best zo onveranderlijk, ‘persistent’ mogelijk.
Je kan dit handboek hier als PDF downloaden.
Om op de hoogte te blijven van nieuws en interessante gesprekken ivm PIDs en persistente URI's in de erfgoedsector, kan je lid worden van de PIDs&PURIs mailinglist.

Handboek

Dit document bevat richtlijnen en goede praktijken om op het web cultureelerfgoedobjecten te identificeren met persistente URI’s (pURI’s) en is bedoeld voor beleidsmakers, collectiebeheerders, publieksmedewerkers en ICT-medewerkers in erfgoedorganisaties.

Dit document legt uit:

  • hoe je erfgoedobjecten uniek identificeert met een URI;
  • hoe je erfgoedobjecten vindbaar maakt op het web met een URI;
  • hoe je een beleid ontwikkelt om URI’s persistent te maken.

De eerste draft van dit document was een eindproduct van het project ‘Duurzame koppelingen tussen kunstwerken, archieven en publicaties’ (2016). Dit project werd uitgevoerd door PACKED vzw (nu meemoo) in opdracht van het Departement Cultuur, Jeugd, Sport en Media van de Vlaamse overheid en gefinancierd met E-cultuurmiddelen. Dit document vormt een synthese van de expertise die werd opgebouwd in een serie projecten rond het gebruik van persistente URI’s voor de duurzame toegang tot erfgoedcollecties op het web. De richtlijnen en goede praktijken in dit document zijn gebaseerd op een aantal voorgaande rapporten en documenten, m.n.:

  1. D7.1.3  - Study on persistent URIs, with identification of  best practices and recommendations on the topic for the MSs and the EC, ISA, 2012
  2. Statement on Linked Data identifiers for museum objects, CIDOC, 2012
  3. Persistente Identificatie. Eindrapport, PACKED, 2014
  4. Persistente Identificatie en Open Cultuur Data, PACKED, 2016
  5. Persistent Identifier Wijzer, NDE, 2016
  6. Vlaamse URI-standaard voor data, Informatie Vlaanderen, 2017
  7. CultURIze en CultURIze-web

Wat is een persistente URI?

Wat is een URI?

'Persistent URI’ is een principe dat is ontstaan uit het concept van Linked Open Data, dat een methode definieert om alle kennis en data op het World Wide Web duurzaam met elkaar te verbinden en uitwisselbaar te maken om zo nieuwe kennis te verwerven. Informatie op het World Wide Web wordt door je webbrowser opgespoord met behulp van URI’s. Een Uniform Resource Identifiers (URI) is een webadres waarmee je webbrowser informatie terugvindt op andere op het web aangesloten machines dan die van jou.

Een URI kan twee rollen vervullen:

  1. Een URI kan verwijzen naar verschillende soorten digitale resources. Een resource kan verschillende gedaantes aannemen:
    • De gedaante van een resource waarmee we misschien het meest vertrouwd zijn, is die van een digitaal bestand. Met behulp van een URI kan je op een andere machine informatie in de vorm van een digitaal bestand ophalen, bijvoorbeeld een PDF-, JPG-, WAV- of HTML-bestand, en weergeven in je webbrowser. Klassieke, ‘statische’ websites waarvan de inhoud verpakt is in HTML-bestanden werken op deze manier
    • Een URI kan ook een instructie geven aan een softwaretoepassing op een andere machine om bepaalde informatie als een datapakketje te verpakken en terug te sturen naar je webbrowser. In dat geval gaat het om een URI die een service aanspreekt. Wanneer je bijvoorbeeld een zoekterm intikt in de Google-zoekmachine, wordt je zoekterm opgenomen in een URI waarmee Google vervolgens een resultaatpagina produceert. Om een softwaretoepassing ‘aanspreekbaar’ te maken met behulp van URI’s, moet ze beschikken over een soort ‘ontvanger’ die de instructies van een URI kan interpreteren. Zo’n ontvanger wordt een Application Programming Interface of API genoemd.
  2. Je kan een URI niet enkel als adres voor een digitaal bestand of als instructie voor een softwaretoepassing gebruiken, maar ook om te verwijzen naar reëel bestaande zaken. Het gaat dan om een URI die een object ‘identificeert’. Je gebruikt de URI dan niet om een digitaal bestand of datapakketje van een andere machine ‘op te halen’ Je gebruikt ze daarentegen wel om machines in staat te stellen om in de ‘virtuele’ wereld te ‘verwijzen naar’ zaken in de ‘echte’ wereld, zijnde concrete voorwerpen, mensen of dieren maar ook abstracte concepten of zaken die op een bepaald moment ‘gebeurd’ zijn, en die te identificeren.

Met behulp van URI’s kan je dus dingen, ook dingen in de ‘echte’ wereld, benoemen en identificeren. Dat is analoog aan het gebruik van andere soorten namen, waarmee je ook zaken benoemt in een bepaalde wereld, een bepaald domein. Bijvoorbeeld:


Zoals de combinatie van familienaam en voornaam een persoon binnen een gemeenschap kan identificeren, of de combinatie van de naam van een museum en een inventarisnummer een kunstwerk in een collectie kan identificeren, zo kan de combinatie van een domeinnaam en een identifier (die samen een URI vormen) een real life resource in een webomgeving identificeren. De URI van zo’n real life resource wordt dan een labeltje, een punt op het web waarrond je verschillende andere resources ‘over’ die real life resource kan verzamelen.

Uit welke onderdelen bestaat een URI?

URI’s zijn een standaard waarmee machines informatie uitwisselen over het web. Ze volgen een strikt protocol. In zijn meest vereenvoudigde vorm ziet dat protocol er als volgt uit: scheme://domeinnaam/path

Een fictief voorbeeld: http://www.vvbad.be/meta/persistente-links waarin:

  • http://   het scheme of schema is, d.w.z. het communicatieprotocol dat je gebruikt om te communiceren over het netwerk;
  • www.vvbad.be  de domeinnaam is, d.w.z. de naam van de machine waaraan je informatie vraagt;
  • /meta/persistente-links  het path of pad is, d.w.z. de eigenlijke locatie op een machine waar je informatie opvraagt.

Wanneer de resource een digitaal bestand is, bijvoorbeeld een foto van het schilderij ‘Landschap met de vlucht naar Egypte’ van Joachim Patenir in het KMSKA, dan zou de link naar die foto er als volgt kunnen uitzien: http://kmska.be/foto/de-vlucht-naar-egypte.jpg

  • De domeinnaam (kmska.be) verwijst naar het computersysteem van het KMSKA.
  • Het path (/foto/de-vlucht-naar-egypte.jpg) verwijst naar een JPG-bestand in de map ‘foto’.

Wanneer je resource een service is waarmee je data over dat schilderij uit het collectiebeheersysteem van KMSKA haalt, zou de link naar de applicatie die de URI kan interpreteren er als volgt kunnen uitzien: http://kmska.be/api/485748930

  • De domeinnaam (kmska.be) verwijst opnieuw naar het computersysteem van het KMSKA.
  • Het path (/api/485748930) bevat een instructie om de API aan te spreken en het identificatienummer van het databankrecord dat de gewenste informatie bevat.

Wanneer de resource verwijst naar een reële zaak, bijvoorbeeld het schilderij zelf, dan zou de URI die het schilderij identificeert er als volgt uit kunnen zien: http://kmska.be/object/64

  • De domeinnaam (kmska.be) verwijst in dit geval vooral naar de organisatie die het schilderij beheert.
  • Het path (/object/64) verwijst naar het inventarisnummer van het schilderij.

De host vervult in deze URI niet zozeer de rol van een computersysteem, maar van een autoriteit die het schilderij ‘Landschap op de vlucht naar Egypte’ aanduidt met het nummer ‘64’.

Hoe kunnen URI’s persistent zijn?

Persistente-URI-linkrot.png

URI’s kunnen voor je publiek de rol van bronverwijzing naar je resources vervullen. Een belangrijk probleem bij het gebruik van URI’s als bronverwijzing is linkrot. De gebruiker krijgt dan een ‘pagina niet gevonden’-bericht. In de praktijk gebeurt het regelmatig dat digitale bestanden op een machine worden vervangen, met als gevolg dat bestandsnamen en dus ook het path (het adres) wijzigen. Ook worden softwaretoepassingen geüpdatet of vervangen, waardoor API’s anders werken en ze de instructies van de URI niet meer begrijpen.

Het ‘breken’ van links kan dus de communicatie met betrekking tot de collectie tussen een erfgoedorganisatie en o.a. onderzoekers, studenten en ontwikkelaars behoorlijk in de war sturen: een bron waaruit je ooit betrouwbare informatie kon putten, is plots niet meer beschikbaar.

Om als betrouwbare online kennisbron op lange termijn informatie toegankelijk te maken op het web, dient een instelling de URI’s waarmee het publiek tot bij haar resources kan geraken ‘persistent’ te maken. Je kan verschillende maatregelen nemen om URI’s onveranderlijk of persistent te houden. In het algemeen zijn er twee mogelijke strategieën:

  1. Je richt een machine in specifiek voor het toegankelijk maken van je resources, met een eigen domeinnaam en met specifieke software om de adressen naar die resources (de URI’s) zo lang mogelijk onveranderd te houden. De naam van je erfgoedorganisatie kan veranderen, bijvoorbeeld door een fusie met een andere erfgoedorganisatie of een rebrandingsoperatie. Kies in zo’n geval voor een domeinnaam die specifiek is opgericht  voor het beheer van persistente URI’s. Soms biedt de overheid die dienst aan, bijvoorbeeld  https://data.gov.uk of http://opendata.vlaanderen.be. Voor de paths maak je vervolgens bij voorkeur gebruik van identificatiecodes die niet door een mens, maar door een machine geproduceerd zijn. Dat garandeert dat de paths uniek blijven, ook als je heel grote hoeveelheden resources identificeert met behulp van een machine.  
  2. De andere strategie gaat er vanuit dat URI’s sowieso veranderen, omdat elke organisatie eindig is, en dat het er dus op aankomt maatregelen te nemen om oude links door te laten verwijzen naar nieuwe links. Het HTTP-protocol voorziet die functionaliteit om oude URI’s ‘door te verwijzen’ naar nieuwe links. De uitdaging bestaat erin om bij een wijziging in het beheer van de URI’s te zorgen dat iemand de verantwoordelijkheid neemt om de persistentie van die URI’s te bewaken.

Vanzelfsprekend sluit de ene strategie de andere niet uit. De richtlijnen die hieronder volgen bevatten zowel maatregelen om URI’s zelf zo onveranderlijk mogelijk te maken als maatregelen om in geval van wijzigingen de koppeling tussen oude en nieuwe URI’s te bewaren.

Zelf URI’s toekennen of bestaande URI’s hergebruiken?

Wanneer is het voor je erfgoedorganisatie wenselijk om zelf URI’s toe te kennen aan objecten, data en beelden en in welke gevallen zijn er alternatieven mogelijk waarbij je reeds bestaande URI’s kan gebruiken?

Het antwoord op deze vragen varieert naargelang  je objecten, data en beelden uniek zijn. Is jouw organisatie m.a.w. de enige partij die over deze specifieke resources beschikt en ze dus ter beschikking kan stellen aan de samenleving?

  • Als het gaat om objecten, data en beelden die je online publiceert en die niet in andere databanken aanwezig zijn en door je eigen organisatie actueel worden gehouden, maak je best zelf persistente URI’s aan. De CIDOC-verklaring over Linked data identifiers voor museale objecten (2012) beargumenteert dat collectiebeherende erfgoedorganisaties zelf de meest aangewezen instantie zijn om op het web hun collectieobjecten te identificeren. Zij hebben namelijk als enige directe toegang tot al hun objecten. Persistente URI’s die een collectiebeherende erfgoedorganisatie zelf toekent en beheert, zijn voor haar een soort ‘online inventarisnummers’ voor alle objecten in haar eigen collectie. Met behulp van persistente URI’s stel je dus eerstehands informatie ter beschikking over de erfgoedobjecten in je collectie.
  • Voor andere data of personen, concepten hergebruik je best persistente URI’s die reeds door andere organisaties zijn toegekend, bijvoorbeeld omdat de corresponderende metadata en beelden vollediger en actueler zijn of omdat deze URI’s al door veel andere organisaties worden gebruikt. De persistente URI van het concept van een fles is bijvoorbeeld al reeds toegekend door de Art & Architecture Thesaurus (AAT) van Getty: http://vocab.getty.edu/aat/300045627.

Door toepassing van deze principes ontstaat er op het web een netwerk van autoriteiten en data. De data over specifieke objecten en de beelden ervan die op meerdere websites worden gepubliceerd, kunnen op die manier met elkaar geclusterd worden.

Hoe persistente URI’s implementeren?

Syntax

De syntax van een persistente URI dient de richtlijnen van bestaande standaarden te volgen, zoals de ISA Study on persistent URIs, with identification of best practices and recommendations on the topic for the MSs and the EC, ISA, 2012 of de Vlaamse URI-standaard voor data, Informatie Vlaanderen, 2017.

Voor persistente URI’s in de cultureelerfgoedsector bestaat er een set van regels:

1. Een persistente URI MOET het HTTPS of HTTP URI-schema gebruiken.

HTTP (HyperText Transfer Protocol) is één van de belangrijkste protocollen voor het versturen en ontvangen van bestanden op het World Wide Web. Het wordt ook gebruikt voor indexering van World Wide Web-documenten. De persistente URI’s moeten dus met http(s):// beginnen.

2. Een persistente URI MOET de volgende elementen bevatten: http(s):// {domein} / {identificatienummer}.

De elementen {domein} en {identificatienummer} zijn verplicht.

  • Het {domein} identificeert het computersysteem waar de persistente URI geregistreerd en beheerd wordt. Een persistente URI MOET een domeinnaam of subdomeinnaam bevatten die enkel en alleen voor het publiceren van persistente URI’s wordt gebruikt. Bijvoorbeeld: {hdl.handle.net}, {data.archief.be} of {id.momu.be}. Je kiest best voor een domeinnaam die onafhankelijk is van bv. merk, organisatie of product.  In een situatie waarbij men achteraf de domeinnaam toch wil veranderen, dient er een doorverwijzing van de oude naar de nieuwe domeinnaam worden ingericht. Zorg er zeker voor dat je organisatie of je PID-leverancier controle heeft over de domeinnaam.
  • Het {identificatienummer} identificeert de resource waarvoor de persistente URI wordt aangemaakt. Hier kies je best voor een logica die unieke onveranderlijke identifiers oplevert, bijvoorbeeld:
    • hergebruik van reeds bestaande identifiers (bv. onveranderlijke databanknummers of inventarisnummers);
    • software en best practices voor het maken (minten) van o.a. UUID’s en NOID’s;
    • gebruik van andere bestaande PID-protocollen: handle, DOI, ARK.

3. Een persistente URI MAG bijkomende elementen bevatten.

Afhankelijk van welke standaard je wilt volgen en welke use case je hebt, kan je tussen {domein} en {identificatienummer} bijkomende elementen opnemen in de persistente URI:

  • {type} Het type duidt aan welk soort resource via de URI toegankelijk is. Hiervoor kan je bijvoorbeeld de volgende termen gebruiken, die in de use cases in de erfgoedsector van toepassing zijn :
    • id: de URI identificeert  louter het cultureelerfgoedobject;
    • data: de URI identificeert een dataset met informatie over een cultureelerfgoedobject;
    • representation: de URI identificeert een grafische representatie van een cultureelerfgoedobject.

De Vlaamse URI-standaard spreekt over volgende types: id, ns en doc: id: identifier is een referentie naar een object uit de echte wereld of een abstract concept; doc: document dat een representatie op het web, of een beschrijving is van objecten in de echte wereld of abstracte concepten. Het gaat hier om algemene beschrijvende informatie (webdocumenten); ns: namespace van een taxonomie, ontologie of vocabularium.

  • {concept} Het concept duidt aan welke categorie cultureelerfgoedobjecten persistent geïdentificeerd wordt. Hiervoor kan je de volgende termen gebruiken:
    • work;
    • concept;
    • agent;
    • place;
    • event.

Deze termen zijn ontleend aan de CIDOC CRM-ontologie en de ‘The Europeana Data Model’-ontologie.

Resolving

Persistente-Ideitficatie-resolver.png

De persistentie van een webadres staat of valt met de gebruikte infrastructuur en het duurzaam beheer ervan. Die infrastructuur bestaat in wezen uit twee belangrijke elementen: een webserver met de ‘URL forwarding’-functie en software die het mogelijk maakt om de URL forwarding of URL redirection te beheren.

  1. Het principe van URL forwarding zorgt ervoor dat wanneer een gebruiker op een persistente URI klikt, hij wordt ‘doorverwezen’ naar de locatie op het web waar de digitale resource vandaag aanwezig is (bv. een andere website, databank of beeldbank).
  2. De software die het beheer van de forwarding mogelijk maakt, wordt de resolver genoemd. Met behulp van deze software kan de beheerder ervoor zorgen dat elke gebruiker bij het aanspreken van een persistente URI steeds op de meest recente locatie van de digitale resource belandt.

Deze infrastructuur kan op verschillende manieren opgesteld worden:

1. Resolving met behulp van een eigen webserver

2. Resolving met behulp van een PID-webdienst

Er bestaan reeds ook meerdere PID-leveranciers die het aanmaken en activeren van persistente URI’s als een dienst aanbieden:

Hoe een beleid voor persistente URI’s opzetten?

PID-strategie

De persistentie van de URI’s kan enkel verzekerd worden door een duurzaam beleid hieromtrent. Een URI-beleid voor je organisatie dient de volgende vragen te beantwoorden:

Wat?

  • welke entiteiten worden geïdentificeerd? object? agent? place? event? concept?
  • welke entiteiten krijgen een eigen URI? enkel entiteiten die uniek zijn voor jouw collectie
  • welke entiteiten krijgen een externe URI?

Waarom?

  • voor welke use cases wil je persistente URI’s gebruiken ?
    • om zelf een autoriteit te worden?
    • om interne en externe workflows te vereenvoudigen?
    • om data te verrijken?

Voor wie?

  • wie zijn de stakeholders/gebruikers?

Hoe?

  • welke syntax verkies je?
  • welke infrastructuur gebruik je?
  • waar zijn de persistente URI’s zichtbaar?
  • welke werkprocessen moeten opgezet worden?
    • wie maakt de persistente URI’s aan? waar worden deze geregistreerd?
    • wanneer worden de persistente URI’s aangemaakt en geactiveerd?
    • wie beheert de persistente URI’s inhoudelijk?
    • wie beheert de technische infrastructuur voor de persistente URI’s?

De antwoorden op deze vragen neem je best op in een PID-strategie of in de digitale strategie van je organisatie. Enkele voorbeelden van een PID-strategie zijn opgenomen in Bijlage 2 van dit handboek.

Stappenplan

Om persistente URI’s in je organisatie te implementeren kan je het volgende stappenplan volgen:

1. Neem persistente URI’s op in je informatiebeleid.
  • Maak van de persistente identificatie van je collectie een doelstelling in je informatiebeleid.
  • Maak het doel van de persistente identificatie zo concreet mogelijk door ze te koppelen aan de strategische en operationele doelstellingen van je organisatie.
  • Creëer voor elke doelstelling één of meerdere gebruikersscenario's die in natuurlijke taal duidelijk maken hoe persistente URI’s bijdragen aan de missie en doelstellingen van je organisatie.
2. Bepaal welke dingen en informatie een persistente URI krijgen.
  • Identificeer de ‘dingen’ in je collectie en maak een inschatting van hun uniciteit in vergelijking met andere collecties.
  • Identificeer alle data over je collectie en de datasets waarin ze vastgelegd zijn.
  • Identificeer alle beelden of andere digitale resources van je collectie en hoe ze zich verhouden tot de ‘dingen’ die ze afbeelden.
3. Bepaal de syntax van de persistente URI.
  • Bepaal voor elk ding, datarecord en beeld de vorm van de persistente URI m.b.v. het standaardformaat.
  • Bepaal welke specifieke diensten je via pURI’s wil aanbieden (bestandsformaten, coderingen, datastructuren).
  • Identificeer de resolvertechnologie die jouw pURI’s kan implementeren.
  • Identificeer de velden in de (collectie)beheersystemen waar pURI’s gedocumenteerd worden.
  • Bepaal of de resolverservice in eigen beheer of extern wordt beheerd.
4. Bepaal wie verantwoordelijk is voor de persistente URI’s.
  • Bepaal wie de rol van beheerder van de pURI’s opneemt.
  • Bepaal wie de rol van ICT-verantwoordelijke opneemt.
  • Bepaal het budget voor het technisch beheer van de resolverservice.
  • Bepaal het budget voor het inhoudelijk beheer van persistente URI’s.
5. Documenteer je beleid en strategie in een informatieplan.
  • Documenteer het beleid rond persistente URI’s in het informatiebeleidsplan of een PID-strategie.
  • Documenteer de procedures voor het dagelijkse beheer van persistente URI’s.
  • Maak een actieplan voor de uitrol van PID’s.
6. Maak een lijst met alle persistente URI’s en hun koppelingen.
  • Maak een basislijst met lokale ID’s voor alle dingen.
  • Ken persistente URI’s toe aan alle dingen.
  • Ken persistente URI’s toe aan alle data, koppel die aan het bijhorende ding en aan de URL met de bijhorende data.
  • Ken persistente URI’s toe aan alle beelden, koppel die aan het bijhorende ding en aan de URL met de bijhorende beelden.
7. Documenteer alle persistente URI’s in collectiebeheersystemen.
8. Activeer alle persistente URI’s met behulp van een resolverservice.
  • Installeer de gekozen resolverservice.
  • Activeer de persistente URI’s met behulp van een resolver (zorgt ervoor dat ze naar iets doorverwijzen).
9. Verspreid alle persistente URI’s via eigen en externe webplatformen.
  • Verspreid via je eigen online platformen.
  • Verspreid via externe platformen zoals bv. Europeana, APEX en Wikidata.
10. Verspreid persistente URI’s via de eigen collectieprocessen.
  • Geef de persistente URI’s mee in exports voor externe partners (bv. fotografen, databanken en andere instellingen en collecties).
  • Gebruik persistente URI’s in de interne processen van je digitale infrastructuur en in de koppelingen tussen verschillende systemen.


Bijlage 1. Praktijkvoorbeelden uit de erfgoedsector

De use cases hieronder geven een overzicht van de verschillende manieren om de principes beschreven in dit handboek te implementeren. Naarmate er meer voorbeelden van implementaties komen, zal dit stuk verder aangevuld worden.

Musea

VKC-musea: KMSKA, MSKGent en Musea Brugge

Implementatie volgens de resultaten van PID-projecten (2013-2016) uitgevoerd door PACKED vzw in samenwerking met VKC, CAHF, Lukas met steun van de Vlaamse overheid. Meer informatie: Project Persistente identificatie en Persistente identificatie en open cultuur data  

Kenmerken van de collectie
  • unieke objecten (kunstwerken)
  • schaalbaar aantal objecten met nood aan persistente identificatie (4000 - 9000 objecten)
  • vaak geen IT-kennis in huis
  • geen budget voorzien voor persistente URI’s
  • geen bestaand centrale resolverservice in Vlaanderen
Syntax URI Formaat:

http://{domeinnaam}/{concept}/{type}/{identificatienummer}

{domein} = de domeinnaam van het museum of het subdomein voor de resolvertool: ‘http://mskgent.be/collection/…’

{concept} = kunstwerk: ‘work’

{type}

‘id’ = identificatie van het object zelf

‘data’ = identificatie van data over het object

‘representation’ = identificatie van het referentiebeeld van het object

{identificatienummer}  = het bestaand objectnummer van het kunstwerk en een automatisch gegenereerd UUID

Voorbeeld:

http://mskgent.be/collection/work/data/1900-D  

http://kmska.be/collection/work/id/00omfv

http://kmska.be/collection/work/data/00omfv

https://collectie.museabrugge.be/collection/work/id/0000_GRO0162_I

Implementatie MSK Gent, Musea Brugge:
  • het beheer wordt semi-centraal georganiseerd op niveau van het samenwerkingsverband VKC
  • momenteel verwijzen de persistente URI’s door naar HTML-pagina’s die de musea zelf hebben gekozen (eigen website)
  • het beheer van de technische kant van de resolver (o.a.updates en CSV-imports) ligt bij de datamanager van Vlaamse Kunstcollectie
  • het beheer van de inhoudelijke kant van de resolver (waarnaar verwijzen de persistente URI’s de gebruikers door) wordt door een verantwoordelijke binnen het museum beheerd  
  • in de huidige versie van het Axiell-collectiebeheersysteem dat door Musea Brugge en MSK wordt gebruikt, zijn er geen velden beschikbaar om persistente URI’s op te slaan in de metadata bij een erfgoedobject (de komst van de nieuwe Erfgoeddatabank zal hiervoor wellicht een oplossing bieden)  .

KMSKA

  • momenteel verwijzen de persistente URI’s door naar HTML-pagina’s die de musea zelf hebben gekozen (eigen website)
  • KMSKA heeft een eigen resolver ontwikkeld en geïmplementeerd in zijn infrastructuur
  • de persistente URI’s worden bewaard in het collectiebeheersysteem TMS

Rijksmuseum Amsterdam

Gebaseerd op de interview met Lizzy Jongma (Databeheerder Rijkmuseum) op 16 april 2015 en de publicatie  https://collectieinforma.wordpress.com/persistent-identifiers-2/

Kenmerken van de collectie
  • grote collectie kunstwerken (1.200.000 objecten)
  • IT-kennis in huis
  • budget voorzien
Syntax URI Formaat:

http://{domein}/{code collectie}/{identificatienummer}

{domein} = de domeinnaam van de handle-service:  hdl.handle.net/

{code collectie} = een code die wordt toegekend aan een collectie binnen het handle-netwerk. Voor het Rijksmuseum is het ‘10934’

{identificatienummer}  = een nieuwe code toegekend aan elk object bij het toekennen van een persistente URI. De code bestaat uit verschillende componenten die inhoudelijke informatie over het object meegeven:

  • een code van een databank per deelcollectie (bv. ‘RM0001’)
  • een code die het databanktype weergeeft (bv. ‘COLLECT’, ‘PEOPLE’, ‘THESAU’)
  • een doorlopend nummer
Voorbeeld:

http://hdl.handle.net/10934/RM0001.COLLECT.6417

Implementatie
  • lokaal een eigen instance van de handle-resolver die vanuit het museum wordt beheerd, maar alle doorverwijzingen lopen eerst via een centrale externe handle-service
  • de technische vragen en inhoudelijke vragen rond de persistente URI’s worden intern bij het Rijksmuseum beheerd
  • de URI’s resolven naar de records op de huidige website van het Rijksmuseum
  • persistente URI’s worden per object in een zelfgemaakt veld in het collectiebeheersysteem (Adlib) aangemaakt door middel van een script wat het doorlopende nummer van de URI baseert op de priref van het object
  • de URI’s van veranderde objectbeschrijvingen worden maandelijks met behulp van een ADAPL-script geupload naar de lokale instance van de resolver

KIK-IRPA

Kenmerken van de collectie
  • archiefbeelden en data over kunstwerken uit Belgische musea worden online toegankelijk gemaakt via BALaT KIK-IPRA catalogus (http://balat.kikirpa.be/)
Syntax URI Formaat http://{domein}/{type object}/{identificatienummer}

{domein} = http://balat.kikirpa.be/

{type object} = object

{identificatienummer} = Adlib-recordnummers

Voorbeeld:

http://balat.kikirpa.be/object/30000939

Implementatie Beheer
  • eigen resolverservice
  • pURI’s enkel voor records van objecten

Bibliotheken

Bibliothèque nationale de France

Gebasserd op de interview met Sebastien Peyrard (BNF) en Raphaëlle Lapôtre (BNF) 5 augustus 2016 en www.bnf.fr/en/professionals/issn_isbn_other_identifiers/a.ark_en.html

Kenmerken van de collectie
  • grote collectie publicaties
  • grotendeels gaat het over niet-unieke objecten
Syntax URI Formaat

http://{domein}/{ARK-code instelling}/{identificatienummer}/{qualifier}

{domein} = domeinnaam van de service die verantwoordelijk is voor het resolven van de persistente URI naar een specifiek portaal. Er bestaan verschillende portalen, bijvoorbeeld:

  • http://catalogue.bnf.fr voor bibliografische beschrijvingen van publicaties;
  • http://gallica.bnf.fr voor de digitale representaties van publicaties.

{ARK-code instelling} = een code van de instelling die gebruik maakt van het ARK-schema, toegekend door California Digital Library, en die uniek is binnen ARK

{identificatienummer} = een uniek nummer van een object dat wordt geïdentificeerd. BNF hergebruikt objectnummers die worden toegekend bij registratie van een ding in hun collectiebeheersysteem

{qualifier} = een suffix die aangeeft welke versie van een record een gebruiker mag verwachten achter een persistente URI (bv. een deel van een beeld, een thumbnail of een xml-record)

Voorbeeld:

http://gallica.bnf.fr/ark:/12148/bpt6k107371t

http://catalogue.bnf.fr/ark:/12148/cb31009475p

Implementatie
  • lokaal een eigen versie van ARK-service geïnstalleerd (beheer van technische en inhoudelijke vragen volledig in eigen handen)
  • de URI’s resolven naar de verschillende subdomeinen die per soort object werden opgesteld (data, beelden)
  • de publicatie als ‘ding’ wordt niet apart geïdentificeerd, enkel de bibliografische beschrijving en een digitale representatie krijgen persistente URI’s
  • ARK-resolver is gelinkt aan het collectiebeheersysteem, de identifiers worden in het collectiebeheersysteem opgenomen en in de MARC-records mee geëxporteerd

Universiteitsbibliotheek Gent

Gebaseerd op de interview met Dries Moreels (UGent Bibliotheek) 5 juni 2016

Kenmerken van de collectie
  • grote collectie gedrukte publicaties: tijdschriften, boeken
  • daarnaast unieke historische objecten: manuscripten, brieven, munten, borstbeelden en veel meer
Syntax URI Formaat:

Voor de bibliotheekcollectie is de URL waarop de dienstverlening online aangeboden wordt al persistent, waardoor er geen resolver nodig is.

Bijvoorbeeld onderstaande URI leidt naar een webpagina over het document (in dit geval een gedicht van Emile Verhaeren) waar alle dienstverlening opgesomd wordt:

http://{domein bibliotheek UGent}/{realm}/{identificatienummer}

(http://lib.ugent.be/catalog/rug01:001801167)

URL’s van vorige websites worden opgevangen en omgeleid, bv. http://search.ugent.be/meercat/x/view/rug01/001801167

Een van de voordelen hiervan is dat als gebruikers in een browser een adres bookmarken, dit dan vanzelf de permalink is. Anders ben je verplicht om zowel de permalink stabiel te houden, alsook de URI’s om de bookmarks niet te breken.

Als een browser de resource opvraagt, krijgt die een HTML-document aangeleverd: http://lib.ugent.be/catalog/rug01:001801167.html. Andere user agents kunnen andere representaties opvragen, bv. JSON of MARC of XML

http://{domein bibliotheek UGent}/{realm}/{identificatienummer}.{format}

(http://lib.ugent.be/catalog/rug01:001801167.json)

Al deze URLs zijn ook beschikbaar via HTTPS:

https://{domein bibliotheek UGent}/{realm}/{identificatienummer}.{format}

(https://lib.ugent.be/catalog/rug01:001801167.json)

Caveat: Als een record ooit wordt gedeleted in het bibliotheekbeheersysteem, dan wordt een persistente link gebroken. Mutatis mutandis als een record niet wordt gedeleted maar volledig overschreven met andere informatie, dan is de link nog wel persistent maar onzinnig.

Voor de Academische Bibliografie, de open access repository van UGent, wordt daarnaast ook nog een resolverdienst gebruikt, nl. Handle.

Publicaties worden door de betrokken UGent-auteur gedeponeerd in biblio.ugent.be:

http://{domein bibliografie UGent}/{realm}/{identificatienummer}.{format}

https://biblio.ugent.be/publication/8030816

Deze URI is op zich al persistent, maar toch wordt er ook nog een handle toegekend, vooral omdat een vorige versie van de repository gebaseerd was op DSpace, waar de handleservice standaard is ingebouwd. Eens een gedeelte van de collectie een handle heeft, en handles ook persistent moeten blijven, is het gemakkelijker om de hele collectie met handles te beschrijven.

http://{Handle domein}/{collectie identifier}/{record identifier}

http://hdl.handle.net/1854/LU-8030816

De records van de academische bibliografie zijn ook vindbaar via de bibliotheekcatalogus en krijgen daar dus ook een persistente link toegekend:

http://lib.ugent.be/en/catalog/pug01:8030816

Ook hier geldt dat er in het verleden voor de bibliografie andere applicaties bestaan hebben  die andere URL’s produceerden. Ook die URL’s worden nog steeds ondersteund, bv. http://lib.ugent.be/bibliografie

Implementatie
  • combinatie van verschillende oplossingen afhankelijk van de dingen die worden geïdentificeerd:
    • geen URL’s breken
    • de website als een RESTful service behandelen
    • URL’s herschrijven om bookmarks op te vangen van de oude naar de nieuwe vorm
    • voor wetenschappelijke publicaties van onderzoekers (BIBLIO) is een instance van de Handle ID minter lokaal geïnstalleerd, en resolven verloopt via de centrale Handle-service, vergelijkbaar met de DOI’s die uitgevers toekennen
  • bij elk object wordt automatisch een URI samengesteld op basis van de identifiers in het bibliotheekbeheerssysteem en die wordt persistent gehouden
  • er loopt een vast mechanisme dat elke dag test of persistente URI’s nog resolven
  • met URL-rewrite-mechanismen worden persistente URL’s die om technische (bijvoorbeeld nieuwe applicaties) of businessredenen (bijvoorbeeld van hoofddomein rug.ac.be naar ugent.be) van structuur moeten veranderen toch nog ondersteund

LIBIS - KU Leuven

Gebaseerd op de interview met Sam Alloing (LIBIS) 13 januari 2016, Info van Roxanne Wyns & Veerle kerstens, januari 2017 en http://resolver.libis.be/help  

Kenmerken van de collectie
  • grote collectie publicaties en archief
  • voor de grootste deel gaat het om niet-unieke objecten
Syntax URI Formaat Teneo – LIBIS-resolver links digitale representaties en metadata:

http://{LIBIS resolver domein}/{identificatienummer}/{service en functions}

{identificatienummer} = nieuwe nummers aan data en beelden toegekend

{service en functions} = stream, thumbnail, representation, metadata, cache, mms, list

Formaat Limo-permalink voor beschrijvende records:

http://{limo.libis.be}{view}{zoektab}{identificatienummer}

{limo.libis.be}: Limo-domein

{view}: weergave in de interface van een bepaalde instelling of toepassing

{zoektab}: weergave in deelcollectie (facultatief)

{identificatienummer}: uniek nummer van het record in Limo

Voorbeeld

Teneo - LIBIS-resolver links naar digitale representaties en metadata:

http://resolver.libis.be/IE157176/list

http://resolver.libis.be/IE157176/metadata

http://resolver.libis.be/FL157178/stream

http://resolver.libis.be/IE2334124/list

http://resolver.libis.be/IE2334124/metadata

http://resolver.libis.be/FL2334126/stream

Limo-permalinks voor beschrijvingsrecord:

http://limo.libis.be/KULeuven:ALL_CONTENT:32LIBIS_ALMA_DS71139186320001471

Implementatie - Limo-permalink: In Limo wordt de permalink momenteel nog door het systeem gegenereerd. Hier heeft KU Leuven – LIBIS minder controle over. In de nabije toekomst is het de bedoeling om ook aan Limo-records een resolverlink toe te kennen die systeemonafhankelijk is (zie onder voor meer informatie over de resolverlinks).

- Teneo - LIBIS Resolver-service:  De Resolver links zijn volledig systeemonafhankelijk en worden opgebouwd volgens een vaste en gedocumenteerde structuur. Bovenstaande resolverlinks zijn maar enkele van de beschikbare parameters die kunnen aangepast worden naargelang de noden van de organisatie en de partner (bv. resolverlinks naar thumbnail-, hoge resolutie- en PDF-representaties, al dan niet weergegeven in een viewerapplicatie, zijn allemaal mogelijk). Ook bij wijziging van domeinnamen, identifiers en softwaretoepassingen zorgt de resolverservice voor een continue mapping en doorverwijzing naar de digitale representatie en bijbehorende metadata.

Archieven

Archiefbank Vlaanderen (2016)

Resultaten van het pilootproject uitgevoerd in het kader van het traject 'Duurzame koppelingen tussen kunstwerken, archieven en publicaties’ (2016). In 2023 heeft Archiefbank een nieuwe naam ‘Archiefpunt en een nieuw platform. De persistente URI’s uit 2016 blijven wel werken.

Kenmerken van de collectie
  • een online catalogus van beschrijvingen van archieven bij externe personen en organisaties
Syntax URI Formaat

http://{Archiefbank domein}/{identificatienummer}

{Archiefbank domein} = http://www.archiefbank.be/dlnk/

{identificatienummer} = ‘AE_’ + bestaande nummers van fiches voor archieven binnen Archiefbank Vlaanderen

Voorbeeld:

http://www.archiefbank.be/dlnk/AE_9327

In 2023 werkt deze link nog steeds en verwijst hij door naar de nieuwe identifiers en persistente URI’s met UUID: https://archiefpunt.be/archief/CB49-59D7-60A7-1960-F9DC9327AE9A

Implementatie
  • interne resolverservice op de server van KADOC
  • beheer door de IT-dienst
  • aangemaakt bij publicatie van een fiche online

AMSAB-ISG

Gebaseerd op de interview met Kim Robensyn (AMSAB-ISG), Maarten Savels (AMSAB-ISG) en Donald Weber (AMSAB-ISG) 19 november 2015

Kenmerken van de collectie
  • data en beelden van archiefstukken op socialhistoryportal.org
Syntax URI Formaat

http://{Handle domein}/{code collectie}/{identificatienummer}

{Handle domein}

{code collectie}

  • voor ID wordt gebruik gemaakt van UUID (gegenereerd bij publicatie online)
Voorbeeld:

- voor records:

http://hdl.handle.net/10796/8F665E0A-19F9-42A4-8771-2AA24DA36521

- voor digitale representaties:

http://hdl.handle.net/10796/048C15A4-98CB-416C-A04D-2E920D032EA9  

Implementatie
  • resolverservice is Handle.net (https://pid.socialhistoryservices.org/)
  • de persistente URI’s worden voorzien voor de metadatafiches en de representaties voor de selectie van stukken uit de collectie die via de Social History Portal en Europeana aangeboden worden. In de praktijk gaat het altijd om gedigitaliseerde stukken of een gebruikskopie van born digital-stukken. Archiefstukken zelf als objecten worden voorlopig niet voorzien van persistente URI’s.

Overkoepelende platformen

DAMS Antwerpen

Gebaseerd op de interview met Jeroen De Meester (DAMS Antwerpen) en Peter Rogiest (Erfgoedbibliotheek Hendrik Conscience) 15 december 2015  

Kenmerken van de collectie
  • digital assets en metadata van objecten uit de collecties van Antwerpse erfgoedinstellingen
Syntax URI Formaat

http://{dams domein}/{identificatienummer}/{parameter}

Voorbeeld:

- record:

https://dams.antwerpen.be/asset/C1UXbcBLNSlZXNWgUIQZCKWz

https://dams.antwerpen.be/asset/C1UXbcBLNSlZXNWgUIQZCKWz.rdf

- beeld:

https://dams.antwerpen.be/asset/C1UXbcBLNSlZXNWgUIQZCKWz/embed

Implementatie Beheer
  • eigen resolver-service

Collectie van de Gentenaar

Kenmerken van de collectie - overkoepelend platform Collectie van den Gentenaar op stedelijk niveau

- data en beelden over erfgoedobjecten uit de collectie van de CoGent partners (Huis Van Alijn, Industriemuseum, Design Museum Gent, Stadsarchief Gent)

- agents en concepten (zonder een link naar een collectie)

- persistente URI’s om de LDES-infrastructuur (Linked Data Event Streams) te ondersteunen

Syntax URI Formaat:                

https://{domain}/{type}/{concept}(/{reference-basic})+(/{reference-version})

  • {domain} - CoGent maakt gebruik van het https://-protocol en gebruikt stad.gent als domeinnaam
  • {type}  - URI's voor alle entiteiten krijgen ‘id’ als {type} om aan te geven dat de persistente URI’s die entiteit ook identificeert.
  • {concept} - ontlenen van OSLO terminologie (‘mensgemaaktobject’)
  • {reference-basic}
    • een namespace per collectie (bv. ‘dmg’ voor Design Museum Gent)
    • een hash - een string van getallen, automatisch gegenereerd aan de hand van het Adlib-databanknummer (priref) en de timestamp van de creatie van het desbetreffende record.
  • {reference-version} - is enkel gebruikt voor elke nieuwe versie van een record en is standaard een timestamp van het moment van de aanpassing van een record in Adlib
  • + betekent dat er 1 of meerdere {reference-basic} kunnen zijn
  • ? betekent dat er maximum 1 {reference-version} aanwezig kan zijn
Voorbeeld:

https://stad.gent/data/mensgemaaktobject/dmg/530007194

https://stad.gent/data/mensgemaaktobject/dmg/530007194/2023-06-01T01:41:39.175Z

Implementatie Technisch:

-   het beheer wordt semicentraal geregeld in samenwerking met Stad Gent, District09 en de erfgoedinstellingen

Beheersmatig:

  • Het beheer van persistente URI's zal samen door de cultureelerfgoedorganisaties, District09 en de IT-afdeling van Stad Gent  worden gedragen. De cultureelerfgoedorganisaties zullen beslissen welke entiteiten een persistente URI zullen hebben en waar deze naartoe dienen te resolven. De technische implementatie van de LDES waarbij de persistente URI’s goed moeten worden geconfigureerd, zal de verantwoordelijkheid zijn van District09. De duurzame resolving van de persistente URI’s zal de verantwoordelijkheid zijn van Stad Gent, tenzij anders geconfigureerd in Adlib door de cultureelerfgoedorganisatie met een eigen resolver en domeinnaam. De praktische implementatie van deze strategie zal in de volgende fasen van het project met de cultureelerfgoedorganisaties worden besproken.

Bijlage 2. Voorbeelden PID-strategie

Naarmate er meer voorbeelden van implementaties komen, zal dit stuk verder aangevuld worden.

A Persistent Identifier (PID) policy for the European Open Science Cloud (EOSC)

Australian Research Data Commons (ARDC) Persistent Identifiers Policy  

Duurzaam vindbaar op het web: URI-strategie Nationaal Archief het gebruik van Handles en URI’s

URI-beleid voor Linked Data. Koninklijke Bibliotheek (KB)  

Bijlage 3. Studiedag Persistente identificatie

Slides Studiedag Persistente identificatie 19/09/2023 in Brussel: