Persistente Identifiers

datum: 13-11-2024 Status: In ONTWIKKELING

Dit artikel is een discussiestuk over persistente identifiers, in het bijzonder toegepast op datasets.
Er liggen kansen bij Health-RI om in het afsprakenstelsel goede afspraken op te nemen over het gebruik van persistente identifiers voor datasets. Het is goed om hiervoor met experts en potentiële leveranciers samen te gaan zitten.

Wat is een Persistente identifier?

Een persistente identifier, meestal afgekort tot PID, is een serie lettertekens die kan worden gebruikt om voor langere tijd consistent te kunnen verwijzen naar een (digitaal) object, zoals een databestand of een dataset (focus in deze pagina), een persoon of een organisatie. Een goede PID heeft verschillende eigenschappen:

Hij is wereldwijd (universeel) uniek. Dit betekent dat niemand anders in de wereld dezelfde PID gebruikt om iets anders aan te duiden, en ook dat een PID nooit hergebruikt zal worden voor een verwijzing naar een ander object. Uniek betekent niet dat elk voorwerp of concept maar 1 PID heeft: verschillende PIDs kunnen naar hetzelfde object verwijzen.
Het is zowel voor mensen als machines mogelijk om direct te identificeren dat het om een PID gaat.
Er is een systeem (een resolver) die de PID kan omzetten in een verwijzing naar het voorwerp of concept. Voor een digitaal object is dat een URL. De resolver kan ook vaak andere metadata over het object bewaren (zie: kernel metadata).
Een PID-systeem moet daarom worden bijgewerkt wanneer de URL verandert. Hierop komen we verderop in dit document nog terug.
De reeks karakters die de PID vormt heeft geen diepere betekenis, er zit naast de herkenning als PID geen andere semantiek. Elke semantiek heeft namelijk het risico om tijdelijk te zijn en dus te kunnen verouderen. Het is een teken van heel slechte architectuur als een PID wordt samengesteld uit semantische onderdelen, tenzij het om het samenstellen gaat van een organisatiebrede prefix en een interne identifier tot een PID.

De FAIR principes vragen om een PID voor data en een PID voor metadata. Zo wordt het in de praktijk nog maar weinig gedaan: er is vaak maar 1 PID die wordt beschreven als de PID voor de data, maar in de praktijk naar een metadata-pagina verwijst waarop een machine niet vanzelf de data kan vinden.

Zie ook:

Kernel Metadata

Omdat de digitale objecten waar PIDs naar kunnen verwijzen nogal van elkaar verschillen is het soms nuttig om iets meer te weten voordat het eigenlijke object wordt opgezocht. Daarom is het mogelijk bij de resolver wat metadata over de PID op te slaan. Deze metadata wordt PID Kernel Metadata genoemd (ook wel PID metadata, identifier record of identity record). PID Kernel Metadata volgt een daarvoor gemaakt profiel, dat zoveel mogelijk moet worden afgestemd in een brede community.

Zie voor meer informatie over PID Kernel Metadata: https://doi.org/10.15497/rda00031

Binnen Health-RI zullen we of een bestaand PID Kernel Metadata profiel moeten adopteren, of er een voor onszelf maken die gebaseerd is op ervaringen van anderen.

In het kernelprofiel moeten waarschijnlijk worden opgenomen:

URLs die wijzen naar het beschreven object
URLs die wijzen naar de metadata die het object beschrijven
Het type object waar de PID naar verwijst. Types kunnen worden gedefinieerd op meerdere niveaus:
- Het format van de file (e.g. “JPEG”) dat definieert hoe de bytes in het object de inhoud coderen.
- Het soort informatie: gaat het bijvoorbeeld om een service, een workflow, of een databestand?
- Wat de inhoud van het bestand laat zien. Bijvoorbeeld: Is het een foto van een berg, of van een mens?

Zie voor meer informatie e.g. FAIR Digital Object Framework Documentation onder “object typing system”.

Bij het maken van een PID Kernel metadataprofiel moet in ogenschouw worden genomen dat het bewerkelijker is om deze informatie bij te werken dan het bijwerken van metadata in een eigen database, en dat mede daarom de gebruikers van PID kernel metadata nooit 100% kunnen vertrouwen op het bijgewerkt zijn van die metadata.

Zie voor een voorbeeld ook: A common PID Kernel Information Profile for the German Helmhol...

Verantwoordelijkheden van de datahouder

Een datahouder die een PID aanmaakt gaat ook de verplichting aan om de metadata die daarbij hoort te blijven bijwerken als dat nodig is. Dit is een belangrijke reden waarom we als Health-RI niet één contract kunnen aangaan met een leverancier van PID-systemen: elke datahouder moet zelf zijn eigen metadata beheren.

Semantiek van de resolver

Er zijn vaak verschillende manieren waarop de resolver kan worden aangesproken. De basisfunctionaliteit bestaat uit 2 delen: (a) het eigenlijke resolven van de PID naar de huidige locatie van het object, en (b) het opvragen van de informatie die beschikbaar is over de PID, de Kernel metadata.

Om de interoperabiliteit te waarborgen is het belangrijk dat binnen een organisatie zoals health-RI goede afspraken worden gemaakt over deze processen. Hieronder vallen:

Wanneer een PID wordt geresolved, waar komt de redirect dan uit? Is dat direct op het databestand? Op de metadata van dat databestand, en zo ja in welke vorm is die metadata? Of op een HTML “landingspagina”? Nog belangrijker dan het eigenlijke gedrag is dat alle PIDs in de organisatie dit op dezelfde manier doen. Bij het maken van een keuze is het belangrijk om ook automatische processen mogelijk te maken; een HTML-pagina is bijvoorbeeld vaak slecht door een machine te interpreteren. (FAIR Principe A1)
Welke persistency wordt er door een PID gegarandeerd? Oneindige geldigheid kan nooit worden gegarandeerd, maar wat is de termijn die men wel kan beloven? En wat gebeurt er met de PID als de data niet meer beschikbaar is? Welke informatie staat er dan op de “tomb stone”? (FAIR Principe A2)

Er zijn mogelijk nog andere semantische aspecten voor het resolven van de metadata, details daarvan zouden we aan experts moeten vragen.

Waarom hebben we persistente identifiers nodig?

Hoewel het soms lijkt alsof identifiers alleen binnen een organisatie of een beperkte groep organisaties worden gebruikt, is het al snel een goed idee om universele PIDs te gebruiken in plaats van lokaal gegenereerde en onderhouden identifiers:

Verwijzen naar de digitale objecten en hun metadata wordt daarmee onafhankelijk van de locatie waar dit wordt gedaan.
Het standaardiseren van de PID-semantiek kan ook de software vereenvoudigen en robuust maken naar de toekomst (bijvoorbeeld: als alle verwijzingen naar een digitaal object worden gevormd door PIDs hoeft men nieuwe typen digitale objecten niet overal in te bouwen; op veel plaatsen kan men volstaan met het bewaren en doorgeven van een PID).

PIDs zijn op deze manier gebruikt een goede manier voor elke plaats waarop gerefereerd moet worden aan een digitaal object. Een voorbeeld is voor het aanvraagproces van toegang tot een dataset: de catalogus kan het resultaat van een zoekopdracht zonder ambiguïteit inbrengen in de data-aanvraag als een lijst PIDs. Ook het vastleggen van relaties tussen datasets in de catalogus (ondersteund door DCAT) kan het best gedaan worden met PIDs.

PIDs kunnen ook worden gebruikt in de catalogus om de resultaten van een zoekopdracht te kunnen opslaan om die later precies nog een keer te kunnen terugvinden voor herhaalbaarheid of om dezelfde query op een later moment te kunnen herhalen op een catalogus met meer datasets (zie: Data Citation of Evolving Data: Recommendations of the Working Group on Data Citation (WGDC) ).

Waar halen we persistente identifiers vandaan?

De kwaliteit van PIDs berust op een stuk specifieke infrastructuur, die met hoge beschikbaarheid (redundant) en betrouwbaarheid tot in lengte van dagen moet draaien (FAIR principe A2). Hoewel het in principe mogelijk is om die infrastructuur in eigen hand te houden, is het met de beschikbaarheid van professionele PID-diensten veel beter om dit in te kopen. Zulke diensten zijn beschikbaar met verschillende kostenstructuren, met verschillende balans van een vaste abonnementsprijs en een prijs per ingevoerde identifier.

Veel gebruikte PID-systemen zijn gebaseerd op het Handle systeem dat in 1995 is bedacht door Bob Kahn, een van de bedenkers van TCP/IP. Omdat in diet tijd HTTP nog maar net was begonnen is het Handle systeem zo opgezet dat het wel gebruik kan maken van HTTP (de gebruikelijke resolvers zijn gebaseerd op HTTP), maar hier in principe niet op steunt. Zelfs als HTTP ooit uit de gratie valt zijn het Handle systeem en alle bijhorende PIDs nog steeds bruikbaar.

Een eerste overzicht van enkele mogelijkheden voor het verkrijgen van Handles is:

ePIC, “Persistent Identifiers for E-Research". Hier is SURF een van de providers. Zie https://www.pidconsortium.net/ en Persistent Identifiers . Als organisatie die deze dienst afneemt krijg je een vast prefix toegekend, en kunt daarbinnen zoveel PIDs maken als je wilt voor een vast bedrag van €45 per jaar.
DataCite, Create DOIs - DataCite . Een organisatie betaalt een bedrag per jaar, en daarvoor kan een gelimiteerd aantal PIDs worden gemaakt. Tot 1600 DOIs per jaar kosten €500 per jaar voor deelname plus €0,80 per DOI. Voor hele grote aantallen DOIs kost het €500+€25500 per jaar voor 10 M DOIs, of €0,0026 per DOI.

Verdere overwegingen bij de keuze zijn:

DataCite identifiers zijn DOIs en beginnen met 10.xxxx; dit wordt door nog meer mensen herkend dan andere Handles en DOIs worden naast voor de wetenschappelijke literatuur ook voor databestanden al veel ingezet. ePIC identifiers zijn ook Handles, maar beginnen met een ander getal.
DataCite en andere DOI providers bieden andere opties voor de kernel metadata dan de andere systemen gebaseerd op Handle.

Afspraken die we in Health-RI moeten maken over Persistente Identifiers

Binnen Health-RI zijn we een groep organisaties. Als onderdeel van ons afsprakenstelsel kunnen we een aantal zaken gaan regelen voor PIDs.

In elk geval moeten we een keuze maken voor de semantiek van de resolver, zodat binnen Health-RI de softwaretools daar rekening mee kunnen houden.
We moeten om dezelfde reden ook afstemming bereiken over de PID kernel metadata.
We kunnen ook met een leverancier van PID-services over contractvoorwaarden onderhandelen die worden aangeboden aan Health-RI partners.
In geen geval moeten verschillende organisaties in Health-RI alle PIDs onder één centraal contract met een leverancier maken. Elke datahouder moet zelf een contract met een PID-provider afsluiten (zie boven de sectie over de verantwoordelijkheden van een datahouder).
We kunnen aansluiten bij een nationale groep (of zo’n groep opzetten?) voor afstemming tussen organisaties zodat een betere nationale interoperabiliteit kan worden bereikt.

Health-RI wiki versie 4.0

Health-RI wiki v4.0 -> consultatie (open tot 03-12-2024)