Categorie archieven: Standaarden

Van DWDD naar FAIR Big Data

Geplaatst op door
Beantwoorden

big-data-1084656_960_720Gepubliceerd in InformatieProfessional 2017/8

Op 12 maart 2015 vertelde Matthijs van Nieuwkerk in De Wereld Draait Door dat we zélf konden gaan bepalen waarmee de wetenschap zich bezig moest gaan houden. Twaalfduizend reacties kwamen er op zijn oproep om vragen in te sturen voor de Nationale Wetenschapsagenda (NWA). Of die vragen allemaal even serieus genomen zijn, valt te betwisten. Maar het beeld van samenwerking en openheid dat NWA-directeuren Alexander Rinnooy Kan en Beatrice de Graaf opriepen, was ook zichtbaar in het vervolg van het proces. De oproep resulteerde uiteindelijk in vijfentwintig onderzoeksprogramma, of ‘routes’ in het jargon van de NWA.

Door: Rob Feenstra

Een van die onderzoeksprogramma’s heet Verantwoorde Waardecreatie met Big Data (VWData). Die (meer)waarde moet de komende tien jaar tot stand komen door het verbeteren van de infrastructuur en door de ontwikkeling van nieuwe instrumenten en technieken. In de eerste periode is er met name aandacht voor multidisciplinair onderzoek en voor het opzetten van proeftuinen en projecten waarin overheid en privésector samenwerken.

Het Portfolio for Research and Innovation, dat de routes beschrijft, noemt Nederland bij uitstek geschikt om het voortouw te nemen in het onderzoek naar big data. Samenwerking tussen verschillende eigenaren en afnemers van data is in landen met datamonopolies veel minder goed mogelijk en juist aan die samenwerking wordt veel waarde gehecht. Het gaat daarbij niet alleen om universiteiten en andere kennisinstellingen, maar ook om bedrijven en maatschappelijke instellingen. Het portfolio verwijst zelfs naar het Nederlandse poldermodel, dat door zou werken in het ontsluiten van gegevensbestanden. Nederland als gidsland, we hebben het vaker gezien.

Verantwoord gebruik

VWData past ook in een internationale tendens, namelijk om beter en meer verantwoord gebruik te maken van (big) data. Een voorbeeld hiervan zijn de FAIR Principles, een set van richtlijnen om (onderzoeks)data beter vindbaar, toegankelijk, uitwisselbaar en herbruikbaar te maken (zie kader). De FAIR Principles zijn in korte tijd breed geaccepteerd en veel subsidieverstrekkers willen dat onderzoekers de FAIR-richtlijnen hanteren. In Nederland is dat, naast bijvoorbeeld de KNAW, de Nederlandse Organisatie voor Wetenschappelijk Onderzoek (NWO), die het grootste deel van VWData, 2,5 miljoen euro, financiert. Bij een aantal van de nu al gedefinieerde VWData-projecten is een ruime plaats ingeruimd voor FAIR, soms gekoppeld aan zaken als privacy, digitale weerbaarheid van burgers, transparantie en waardevrijheid van algoritmen.

Zo buigt het project Fair News: Nieuwsvoorziening in een Big Data tijdperk zich over de vraag hoe ver algoritmes kunnen en mogen gaan bij het filteren van data en waar de verantwoordelijkheid ligt als er op basis van algoritmen onjuiste beslissingen worden genomen. Bij dit project, een samenwerkingsverband tussen de Universiteit van Amsterdam en de TU Delft, is ook de Volkskrant betrokken.

Een ander project waarbij het FAIR gebruik van data een grote rol speelt, is Distributed FAIR information systems to enable federated learning and reasoning. Deelnemers aan dit project buigen zich bijvoorbeeld over de vraag hoe je een FAIR datadienst opzet, waarbij concurrerende organisaties data kunnen delen en gebruiken voor een gezamenlijk vastgesteld doel zonder dat het voor andere doeleinden wordt gebruikt. Naast een viertal universiteiten nemen ook bedrijven als KLM en KPMG deel.

Eigen invulling

De vijftien FAIR Principes zijn geformuleerd in algemene termen. Zo kom je tot een brede acceptatie, maar bied je aan de andere kant veel ruimte voor eigen interpretatie. Dat kan weer tot gevolg hebben dat landen, wetenschapsgebieden, instellingen en individuen hun eigen invulling geven aan FAIR, waardoor oorspronkelijke uitgangspunten als herbruikbaarheid van data juist uit het zicht verdwijnen. De eerste projecten van VWData bevinden zich nog in de opstartfase. Het komende decennium gaan we zien hoe de deelnemers omgaan met die schijnbare tegenstelling.

Er is een lange weg afgelegd van de twaalfduizend vragen van ‘gewone’ mensen naar dit onderzoeksprogramma en het is twijfelachtig of veel van die vragen hierin beantwoord worden, maar met de gekozen insteek kunnen er in ieder geval wél antwoorden gezocht worden op vragen die maatschappelijk en economisch van belang zijn.

Rob Feenstra is projectleider/consultant bij de Universitaire Bibliotheken Leiden en heeft als aandachtsgebied bibliotheeksystemen en de digitale bibliotheek.

FAIR Principles

Een internationale groep van belanghebbenden stelde in 2016 de FAIR Principles op vanuit de groeiende behoefte om de infrastructuur voor de publicatie en het (her)gebruik van data te verbeteren. Het doel is om data Findable, Accessible, Interoperable en Re-Usable te maken. Daarbij gaat het zowel om de mogelijkheid van computers om de data te gebruiken als om het (her)gebruik door personen.

Findable (vindbaar): om goed vindbaar te zijn voor mens en machine moet er een beschrijving zijn van de metadata

F1. (Meta)data beschikken over een wereldwijd unieke en eeuwig persistente identifier
F2. Data worden beschreven door uitgebreide metadata
F3. Metadata bevatten de identifier van de data die worden beschreven
F4. Metadata worden geregistreerd of geïndexeerd in een doorzoekbare bron

Accessible (toegankelijk): de mogelijkheden en beperkingen voor toegang tot de (meta)data worden expliciet gemaakt.

A1. (Meta)data zijn opvraagbaar via de identifier door het gebruik van een gestandaardiseerd communicatieprotocol
A1.1. Het protocol is open, gratis en onbeperkt implementeerbaar
A1.2. Het protocol maakt, indien nodig, authenticatie en autorisatie mogelijk
A2. Zelfs als de data niet langer beschikbaar zijn, moeten de metadata toegankelijk blijven

Interoperable (uitwisselbaar): data kunnen gekoppeld worden aan andere data door zowel mens als computer.

I1. (Meta)data gebruiken een formele, toegankelijke en breed toepasbare taal voor kennisweergave
I2. (Meta)data gebruiken vocabularies die voldoen aan de FAIR Principles
I3. De (meta)data bevatten gespecificeerde referenties naar andere (meta)data

Reusable (herbruikbaar): de beschrijving van de (meta)data is zodanig dat er ook in de toekomst gebruik van kan worden gemaakt, zowel door mens als computer.

R1. De (meta)data worden uitgebreid beschreven met een veelheid aan nauwkeurige en relevante kenmerkende eigenschappen
R1.1 (Meta)data worden toegankelijke gemaakt door een duidelijke en toegankelijke (data)gebruikslicentie

R1.2 Het is duidelijk wat de herkomst van de (meta)data is
R1.3 (Meta)data sluiten aan op specifieke standaarden voor bepaalde onderzoeksgebieden

IIIF we could present images

Geplaatst op door
Beantwoorden

Je zou denken dat plaatjes aanleveren via het internet toch heel eenvoudig is. En dat is ook zo, tenminste voor de “normale” plaatjes. Maar als het gaat om plaatjes van meer dan 100 MB groot, dan wordt het wat ingewikkelder. Zeker als die plaatjes niet in zijn geheel afgebeeld kunnen worden op het beeldscherm omdat de afmeting van de plaatjes meer dan 10.000 pixels breed zijn. Je kan je afvragen of het dan verstandig is om voor het afbeelden van deze plaatjes de plaatjes in zijn geheel op de volledig beschikbare resolutie te versturen naar een scherm dat dat toch niet aan kan. Nou inderdaad, dat is niet verstandig.

Het is dan beter om een manier te hebben om het plaatje te versturen op 800 pixels breed naar iemand die een scherm heeft van 800 pixels breed en het hele plaatje wil zien. Of alleen de rechterbovenhoek van het plaatje op 800 pixels breed voor iemand die de rechterbovenhoek van het plaatje ingezoomd wil zien. Nu is dit al lang technisch mogelijk, maar sinds september 2014 is er een officiële API voor, gemaakt door het IIIF.

API staat voor Application Programming Interface. Dit is een beschrijving van hoe een stuk software communiceert met een ander stuk software. Het IIIF  is het International Image Interoperability Framework. Deze API beschrijft hoe je op een standaard manier (een deel van) een plaatje kan opvragen. En dat is niet het enige wat het beschrijft, maar daarover later meer.

Wat heb je nu aan zo’n API? Als een systeem deze API implementeert, dan kunnen andere systemen daar gebruik van maken, aangezien beschreven is hoe de API werkt en hoe die te gebruiken is. Als je plaatjes van een systeem wilt halen die de IIIF API implementeert, dan is het meteen duidelijk hoe je dat moet doen. Oftewel, het is voor iedereen duidelijk welke taal er wordt gesproken en aangezien het een taal is waar meerdere partijen het over eens zijn, kan je ook gebruikmaken van de systemen van meerdere partijen. En wat voor systemen zijn dat dan? Dat kan bijvoorbeeld gaan om een systeem wat een plaatje op een nette manier afbeeldt. Dit wordt ook wel een image viewer genoemd. Door de IIIF API is het dus mogelijk om verschillende image viewers te gebruiken, zolang die aan de IIIF API voldoen.

Er zijn 2 IIIF API’s beschikbaar: de IIIF image API en de IIIF presentation API.

Met de IIIF image API is het mogelijk om informatie over een plaatje op te vragen, zoals hoe groot het plaatje is, hoe ver ingezoomd kan worden, welke formaten beschikbaar zijn en wat er allemaal mogelijk is met dit plaatje via de IIIF image API. Ook kan natuurlijk (een deel van) het plaatje op een bepaalde grootte opgevraagd worden. Om dit te doen, kan een regio (deel van het plaatje) in absolute eenheden of percentage gevraagd worden. Daarna kan opgegeven worden hoe groot het resulterende deel van het plaatje teruggegeven moet worden. Eventueel kan ook opgegeven worden dat het plaatje in kleur, grijstinten of zwartwit geleverd wordt, en eventueel geroteerd of gespiegeld.

Hoe werkt het nu concreet? Hieronder een URL wat een deel van een plaatje opvraagt:

https://images-
dev.harvardx.harvard.edu/ids/iiif/47174896/750,840,256,256/256,/0/native.jpg

nativeWaarbij de URL uit de verschillende onderdelen bestaat, die  door de IIIF image API beschreven worden:

  • https://images-dev.harvardx.harvard.edu/ids/iiif/
    Dit is een IIIF image server URL
  • 47174896
    Dit is de image identifier
  • 750,840,256,256
    De regio van het plaatje wat gewenst is. Dit zijn achtereenvolgens de x, y en breedte en hoogte van de regio in absolute eenheden, ten opzichte van het originele plaatje. Dit kunnen ook percentages zijn. Om het hele plaatje op te vragen kan ‘full’ gebruikt worden.
  • 256,
    Dit is de grootte van het plaatje wat gewenst is. Hier wordt alleen de breedte gegeven, aangezien de hoogte hieruit afgeleid kan worden. Aangezien de breedte gelijk is aan de breedte die eerder in de regio gedefinieerd werd, kan dit ook worden vervangen door ‘full’, wat betekent dat de volledig beschikbare resolutie wordt gebruikt.
  • 0
    Dit is de rotatie in graden. Hier wordt niet geroteerd. Vaak worden alleen veelvouden van 90 ondersteund (dat is bij de IIIF image server ook het geval)
  • native
    Dit is de kwaliteit van het plaatje. Hier kan ook color (kleur), gray (grijstinten) of bitonal (zwart/wit) gebruikt worden.
  • jpg
    Dit is het formaat van het plaatje, andere waarden zijn onder andere png,tif en pdf

Op deze manier kan ook het volgende plaatje opgevraagd worden:

nativehttps://images-dev.harvardx.harvard.edu/ids/iiif/47174896/full/100,/180/native.jpg

Voor de duidelijkheid, het basisplaatje is steeds dezelfde, namelijk een plaatje met JPEG2000 formaat. Hieruit kunnen de andere plaatjes gegenereerd worden. De IIIF image API beschrijft alleen welk deel van het plaatje op welke manier geleverd moet worden, maar niet hoe dat gebeurt.

Ook kan de informatie van het plaatje opgevraagd worden met:

https://images-dev.harvardx.harvard.edu/ids/iiif/47174896/info.json

Dit levert het volgende resultaat:

{
“@context”:”https://library.stanford.edu/iiif/image-api/1.1/context.json”,
“@id”:”https://images-dev.harvardx.harvard.edu/ids/iiif/47174896″,
“width”:2087,
“height”:2550,
“scale_factors”:[1,2,4,8,16,32],
“tile_width”:256,
“tile_height”:256,
“formats”:[“jpg”],
“qualities”:[“native”],
“profile”:”https://library.stanford.edu/iiif/image-api/1.1/compliance.html#level1″
}

Hieruit wordt duidelijk wat de grootte van het plaatje is (width/height), welke schalen omndersteund worden (dus hoever ingezoomd kan worden) (scale_factors), in welke grootte de verschillende delen van het plaatje het best opgevraagd kunnen worden (tile_width/tile_height), welke formaten ondersteund worden (formats), de mogelijke kwaliteiten waarin het plaatje opgevraagd kan worden (qualities) en welke versie en niveau van de IIIF image API ondersteund wordt (profile). Zoals hier te zien is, wordt versie 1.1 van de IIIF image API gebruikt op level 1. Helaas ondersteunt dit niet alle hierboven genoemde mogelijkheden.

Met de IIIF image API kan een image viewer alle informatie en onderdelen van een plaatje opvragen om die op een nette manier af te beelden, zodat in- en uitgezoomd kan worden. Een voorbeeld van hoe dat werkt is hier te vinden.

Maar dit is nog niet alles, want waar het interessant wordt, is met de tweede API, de IIIF presentation API. Met deze API kan de structurele en presentatie informatie van een object opgevraagd worden. Een object? Het ging hier toch om plaatjes? Ja, maar een object bestaat hier uit een of meerdere plaatjes. Bijvoorbeeld een schilderij kan uit één plaatje bestaan, een foto uit 2 plaatjes (voor- en achterkant), een standbeeld uit 4 plaatjes (voor- en achterkant en beide zijkanten) en een boek uit meerdere plaatjes. De IIIF image API is bedoeld om een plaatje af te kunnen beelden, maar de IIIF presentation API is bedoeld om een object, bestaand uit allerlei plaatjes, in context te kunnen presenteren.

objectsHoe werkt het? De IIIF presentation API biedt de mogelijkheid om een manifest op te halen en in dit manifest staat beschreven hoe het object gepresenteerd moet worden en bevat een beschrijving (metadata) van het object en van de verschillende componenten van het object. Het manifest bevat 1 of meerdere opeenvolgingen (sequences) van beelden (canvas) voor het object. Een boek bijvoorbeeld heeft 1 opeenvolging van bladzijdes (in volgorde), maar er zijn boeken waar er meerdere opeenvolgingen mogelijk zijn. Elk beeld bevat ook weer inhoud (content). Dit kan bijvoorbeeld het plaatje zijn wat via de IIIF image API afgebeeld kan worden, maar het kan eveneens de OCR tekst zijn. Een beeld hoeft zelfs geen inhoud te hebben, wat het mogelijk maakt om een deels gescand boek ook netjes te beschrijven in een manifest en af te beelden (de niet-gescande bladzijdes blijven dan leeg).

Wat kan je er nu eigenlijk mee? Afbeelden van allerlei materiaal, maar wellicht kan het beter getoond worden dan beschreven. Hieronder enkele voorbeelden van de UniversalViewer, een viewer die beide IIIF API’s ondersteund.

Boek: The biocrats

Brief: Copied letter from Francis Crick to Michael Crick

Folio: Pseudo-Albert the Great

Collectie: The biological basis of medicine

Kaart: Typus Orbis Terrarum

De inhoud van het “more information” tabje (rechts) wordt geleverd via de IIIF presentation API, evenals de volgorde van de bladzijdes of zelfs de hiërarchie bij het collectie voorbeeld. Bemerk dat ook de attribution, conditions of use, de license en een link naar het catalogus record in sommige gevallen zijn opgenomen. Dit alles wordt ook door de IIIF presentation API ondersteund. Bij het kaart voorbeeld wordt duidelijk hoe ver ingezoomd kan worden en hoe soepel dit gaat. Ook kan het plaatje gedraaid worden terwijl al ingezoomd is, terwijl op de juiste plek gebleven wordt. Dit alles dankzij de IIIF image API.

 

Het idee is om deze twee IIIF API’s te ondersteunen binnen de nieuwe repository infrastructuur. Op deze manier kunnen we de objecten mooi presenteren, gebruikmakend van een IIIF-compatible viewer zoals de UniversalViewer. Maar andere partijen kunnen ook onze objecten of delen daarvan binnen hun eigen website afbeelden. Ook kunnen we binnen de repository infrastructuur (delen van) objecten presenteren van partijen die ook de IIIF API’s ondersteunen. Dus als we van een object maar een deel hebben, kunnen we een manifest maken dat andere delen bij andere partijen die de IIIF API’s ondersteunen, ophaalt.

De IIIF API’s bieden dus veel meerwaarden, maar we moeten er nog wel wat voor doen. Helaas worden deze IIIF API’s nog niet nu al ondersteund binnen de nieuwe repository infrastructuur. Maar we kunnen dit wel zelf (met hulp van derden) implementeren. Hierna kunnen we een bestaande IIIF-compatible viewer binnen de repository infrastructuur implementeren die gebruik maakt van deze API’s.

Zoals gezegd, het wordt mooi als we plaatjes kunnen presenteren!

Betere toegang tot digitale collecties door middel van persistente identifiers.

Geplaatst op door
Beantwoorden

De UBL wil in 2015 haar digitale collecties beter toegankelijk maken voor zowel mensen als machines. Het gaat hierbij bijvoorbeeld om kaartmateriaal, hoogleraarsportretten, onderzoeksdata en publicaties. Om digitale objecten beter toegankelijk te maken is het noodzakelijk dat objecten buiten het eigen systeem op een eenduidige manier te identificeren en te lokaliseren zijn.

Op 17 oktober 2014 was er in Utrecht een workshop over object identifiers, georganiseerd door U2Connect. U2Connnect is een samenwerking van enkele Nederlandse universiteiten waar geëxploreerd wordt hoe de diensten van het door de Europese Commissie gefinancierde EUDATproject ingezet kunnen worden met betrekking tot datamanagement.

Het EUDATproject ontwikkelt zogenaamde common services, gemeenschappelijke diensten die door veel andere diensten gebruikt kunnen worden. Te denken valt hierbij aan diensten om data te delen (B2SHARE), te vinden (B2FIND), repliceren (B2STORE) en beschikbaar te maken voor analyse (B2STAGE). Voor al deze diensten is het van belang om objecten op een eenduidige manier te kunnen identificeren en te lokaliseren.

URL’s kunnen gebruikt worden om objecten uniek te identificeren en lokaliseren. In de praktijk komt er echter regelmatig linkrot voor waardoor de URL’s niet meer verwijzen naar het object. Dit kan bijvoorbeeld het geval zijn als de objecten naar een andere server verplaatst zijn. Om identifiers en lokaties naar objecten goed te kunnen beheren zijn er identifiersystemen ontwikkeld. Er wordt ook wel gesproken van persistent identifiers om aan te geven dat de identifiers voor de lange termijn geldig zijn. Als er sprake is van persistente identifiers dan wordt er in het algemeen van uitgegaan dat zowel de identifier als het object voor de lange termijn geldig moeten zijn.

Er zijn verschillende oplossingen die gebruikt kunnen worden voor het identificeren en lokaliseren van objecten. Om een juiste keuze te maken is het van belang te kijken naar het beleid, de functionaliteit, de schaalbaarheid en het draagvlak van de aangeboden oplossingen.

Tijdens de workshop werden er presentaties gegeven van DataCite, URN:NBN en EPIC en werd er aangegeven hoe deze oplossingen door 3TU Datacentrum, DANS en SurfSara worden gebruikt.

Alle oplossingen hebben een aantal kenmerken met elkaar gemeen. Ze hebben een unieke alfanumerieke reeks nummers om een object te identificeren. Deze nummers zijn gekoppeld aan een locatie. Daarnaast is er een zogenaamde resolver waar je de locatie van een identifier kunt opvragen.

Een voorbeeld van een persistent identifier is:

https://hdl.handle.net/1887/13839 De identifier bestaat uit drie delen:

  • handle.net: verwijst naar de resolver die de identifiers toewijst en die er voor zorgt dat de gebruiker naar de locatie van het object wordt geleid
  • 1887; dit staat voor de databank, in dit geval het Leids Repositorium.
  • 13839: dit verwijst naar het object

De resolver zorgt ervoor dat de gebruiker naar de juiste locatie wordt geleid. In dit geval is dat https://openaccess.leidenuniv.nl/handle/1887/13839. Wanneer dit object, in dit geval een masterscriptie, naar een andere plek zou worden verplaatst, bijvoorbeeld naar https://masterscripties/leiden/98423, zorgt de resolver ervoor dat u via de persistent identifier (die niet verandert) naar deze nieuwe locatie wordt geleid. Om een bepaalde vorm van persistent identifiers te mogen toekennen, registreert de instelling zich bij een zgn Registration Agency. Dit is een organisatie die de afspraken rondom de toekenning van persistent identifiers vastlegt en bewaakt. Een voorwaarde die een Registration Agency kan stellen aan een persistent identifier is dat het digitale object dat er aan gekoppeld is, moet zijn opgeslagen in een Long Term Preservation depot. Voor het Nederlandse subdomein van URN:NBN fungeert de KB bijvoorbeeld als Registration Agency. De Registration Agency, die een onderdeel is van de KB, bewaakt alle afspraken rondom het NBN en tussen de stakeholders en registreert instellingen die NBN’s toekennen.

De oplossingen verschillen van elkaar wat betreft het doel, bereik en tijdspad waarvoor ze gebruikt kunnen worden. DataCite wordt gebruikt voor het refereren naar onderzoeksdata. DataCite maakt gebruik van DOI’s. De DOI’s kunnen geresolved worden door middel van het handle systeem. DataCite delegeert het uitgeven van DOI’s aan registratie-organisaties.

Voorbeeld: https://dx.doi.org/10.1594/PANGAEA.726855

URN:NBN worden gebruikt voor het refereren aan publicaties en onderzoeksdata. Er wordt gebruik gemaakt van de syntax van URN’s. De URN:NBN maakt gebruik van in eigen beheer ontwikkelde resolvers. De nationale bibliotheken zijn de registratie-organisaties van de URN:NBN en kunnen de uitgifte van URN:NBN’s delegeren.

Voorbeeld: URN:NBN:NL:UI:13-2UYT-ZI

Deze identifier bestaat uit vier delen:

1 – URN: Identifier scheme

2 – NBN: Namespace voor zogeheten National Bibliographic Numbers

3 – NL:UI: Geeft aan dat het om identifiers gaat die in Nederland zijn uitgegeven.

4 – 13-2UYT-ZI: Een unieke code voor de dataset, in dit geval binnen DANS.

EPIC kan gebruikt worden voor verschillende doeleinden. EPIC maakt gebruik van handles. Het EPIC consortium fungeert als registratie-organisatie. De handles kunnen geresolved worden door middel van het handlesysteem.

Voorbeeld: https://hdl.handle.net/1839/00-4F7E67EB-3358-48DD-8EB8-158A8EA99AF0@format=imdi@view

Er is geen one size fits all-oplossing die voor alle doeleinden ingezet kan worden. Interessant is het daarom te horen op welke wijze 3TU datacentrum, DANS en SurfSara gebruik maken van persistent identifiers.

3TU datacentrum gebruikt DataCite voor het refereren aan datasets. Elke dataset die voor de lange termijn bewaard moet worden en niet meer verandert krijgt een DOI. Het betreft hier statische datasets. De DOI’s verwijzen naar de metadata van een dataset. Er moet verplicht een aantal Dublin Corevelden ingevuld worden. Een aantal velden is optioneel. Indien er voldoende metadatavelden zijn ingevuld worden deze records doorgegeven aan de Data Citation Index van Thomson Reuters.

DANS maakt uit het oogpunt van duurzaamheid gebruik van URN:NBN. DANS hanteert hierbij hetzelfde principe als de KB. Aan alle door DANS toegankelijke datasets wordt een URN:NBN toegekend. Omdat URN:NBN een standaard is en de resolver- en registration agency in eigen beheer zijn kan DANS op deze wijze duurzame toegang tot datasets garanderen.

URN:NBN is niet erg bekend onder onderzoekers als een middel om te citeren naar onderzoeksdata. DANS wil om deze reden eveneens gebruik maken van DataCite voor het citeren van datasets.

DANS biedt naast een voorziening voor het bewaren van onderzoeksdata voor de lange termijn (EASY) ook een voorziening voor het delen van onderzoeksdata gedurende het lopende onderzoek (DataVerse). DataVerse maakt gebruik van handles voor het refereren naar de datasets.

SurfSara maakt in haar suite van B2 diensten veelvuldig gebruik van handles die beheerd en geresolved worden door de EPIC-infrastructuur. De B2-diensten worden onder andere gebruikt door onderzoeksprojecten waar grote hoeveelheden data beheerd worden. Identifiers worden niet alleen gebruikt voor het refereren naar een gehele dataset maar eveneens om individuele objecten voor zowel mens als machine toegankelijk te maken. De EPIC-infrastructuur is zo schaalbaar en robuust dat deze grote hoeveelheid identifiers goed verwerkt kunnen worden.

Om de digitale collecties van de UBL beter toegankelijk te maken voor zowel mensen als machines moet er goed gekeken worden voor welk doel de UBL deze identifiers wil gebruiken en welke voorwaarden de PI registration agencies aan het gebruik stellen.

De UBL heeft een projectvoorstel in voorbereiding om het bovenstaande verder uit te zoeken en een keuze te maken voor een of enkele PI-oplossingen. Een onmisbare component voor het nog beter toegankelijk maken van de digitale collecties van de UBL.

Rob Feenstra en Laurents Sesink

Open Annotation Collaboration

Geplaatst op door
Beantwoorden

Dit is een tweede post in de serie over dingen die mij opvielen tijdens OAI8. In deze post ga ik in op Open Annotation Collaboration (OAC). Over deze standaard heb ik tijdens OAI8 een presentatie en een workshop bijgewoond. Beide werden gegeven door Rob Sanderson van de Los Alamos National Library.

OAC is eigenlijk al een aantal jaren oud. Het werk begon rond 2010, en is min of meer onstaan in de periode waarin Herbert Van de Sompel als visiting researcher verbleef bij DANS en bij het Huyghens Instituut. Veel onderzoekers op het gebied van de digital humanities houden zich bezig met het annoteren van bronnen, zoals digitale edities van literaire teksten, of reproducties van kunstwerken. Vaak worden er daarbij specifieke systemen gebruikt en kunnen die annotaties niet gemakkelijk worden hergebruikt. Maar het annoteren van bronnen is uiteraard een breder fenomeen. In systemen zoals Flickr of FaceBook kunnen er uiteraard ook opmerkingen bij bronnen worden geschreven. Ook hier speelt het probleem dat deze opmerkingen vastzitten aan die specifieke omgevingen. Het doel van OAC is om een manier van annoteren te ontwikkelen die generiek is en die los van het systeem waarin deze bronnen worden beheerd.

Open Annotation is gebaseerd op een simpel data model, en maakt ook volledig gebruik van de architectuur van het web. In de visie van W3C bestaat het web uit entiteiten die worden geïdentificeerd door een URI. In het data model van Open Annotation bestaan alle componenten van de annotatie dus uit ‘Web Resources’ met een eigen URI. De basisgedachte is dat een annotatie bestaat uit twee onderdelen. De eerste bron is de annotatie zelf is (de ‘Body’). De tweede bron is datgene is dat wordt geannoteerd (de ‘Target’). Deze eerste twee bronnen worden bij elkaar gebracht door een derde Web Resource, namelijk de ‘Annotation’. Een ‘Target’ kan bijvoorbeeld een scan zijn van een schilderij, en een “Body” is dan een tekst waarin wordt toegelicht wat er op het schilderij te zien is. Een annotatie kan natuurlijk ook gaan over specifieke details van het schilderij. OAC voorziet ook in technieken waarmee specifieke onderdelen van bronnen kunnen worden geaddresseerd (zogenaamde ‘selectors’).

intro_model

Recentelijk zijn er nog een aantal termen aan het data model toegevoegd. Het is nu ook mogelijk om het doel van de annotatie op te geven (gaat het om wetenschappelijk onderzoek? Of is het een soort ‘Bookmark’ of geheugensteun?). Er zijn ook termen toegevoegd waarmee de “provenance” kan worden vastgelegd (de persoon die verantwoordelijk is voor de annotatie). Hiernaast is ook de term “SemanticTag” gedefinieerd, zodat er bij het annoteren ook termen uit bestaande ontologieën kunnen worden gebruikt.

Open Annotation is voor de UBL een heel interessante techniek. Terwijl de technologie rond nanopublicaties (die ook is gebaseerd op  Semantic Web technologie) toch voornamelijk toepassingen lijkt te hebben binnen de natuurwetenschappen, kunnen onderzoeksgroepen binnen de Geesteswetenschappen via OAC ook een stap zetten naar Linked Data en naar herbruikbare en gestructureerde onderzoeksannotaties. Een goed voorbeeld van humaniora-onderzoek waarin OAC momenteel al wordt toegepast is het Emblemata-project, waar onder meer ook onderzoekers van de Universiteit Utrecht aan deelnemen. Er zijn inmiddels ook al een aantal open source applicaties beschikbaar waarmee vrij gemakkelijk Open Annotations kunnen worden aangemaakt, namelijk SharedCanvas en in Pund.It. Voor bijvoorbeeld kunsthistorici die heel gedetailleerd bepaalde uitsnedes van kunstwerken willen beschrijven, of voor literatuurcritici die commentaar geven op specifieke tekstfragmenten, kunnen dit heel nuttige tools zijn.

Repositories gelijkzetten

Geplaatst op door
Beantwoorden

In juni bezocht ik het Open Archives Initiative congres in Genève. Dit congres richt op innovatieve technologie op het gebied van wetenschappelijke communicatie, en wordt om de twee jaar georganiseerd. OAI vond dit jaar al weer voor de achtste keer plaats. In verschillende blogposts bespreek ik een aantal interessante nieuwe ontwikkelingen die ik daar heb gehoord.

resourcesync_logo

Voorafgaand aan OAI8 waren er een aantal workshops, en de workshop die ik zelf heb bijgewoond ging over het nieuwe protocol ResourceSync. Het initiatief voor de ontwikkeling van deze techniek is genomen door de mensen van OAI (onder meer Herbert Van de Sompel, Simeon Warner en Carl Lagoze). Zij waren eerder ook verantwoordelijk voor belangrijke standaarden en protocollen zoals OAI-PMH, OAI-ORE en Memento. Aan de ontwikkeling van ResourceSync hebben inmiddels ook partijen als NISO, OCLC, de Library of Congress, Cottage Labs, Ex Libris en JISC bijgedragen.

ResourceSync is, simpel gezegd, een protocol waarmee de inhoud van verschillende repositories kan worden gesynchroniseerd. De site ArXiv.org, waarop veel publicaties in open access worden gepubliceerd, heeft een aantal mirror sites opgericht, onder meer vanuit de LOCKSS-gedachte (“Lots of copies keep stuff safe”). Arxiv ondervindt momenteel veel problemen bij het kopiëren van die bestanden naar de andere servers. Ook vanuit Europeana is interesse getoond voor ResourceSync. Voor de Europeana-portal worden op dit moment alleen nog de metadata van de verschillende aangesloten instellingen geharvest. Europeana wil op termijn ook graag de digitale objecten zelf gaan harvesten. ResourceSync probeert in dit soort situaties een oplossing te bieden.

Zoals bij de meeste standaarden is ResourceSync gebaseerd op een data model. Dit model is in eigenlijk heel simpel. Op de eerste plaats is er een “Destination” server. Deze server wil graag documenten of gegevens overnemen van een “Source”. Er wordt onderscheid gemaakt tussen een “baseline synchronisation” en een “incremental synchronisation”. Het eerste geval is in feite het begin van het synchronisatieproces. Alle aangemerkte bestanden worden daarbij direct overgebracht van de “Source” naar de “Destination”. Na deze initiële synchronsatie ontstaat er een situatie waarin de ontvangende server goed op de hoogte moet blijven van toevoegingen of wijzigingen op de bron-server. Hierbij kan gebruik worden gemaakt van een pull-mechanisme, waarbij de Destination server een verzoek om informatie verstuurt, of van een push-mechanisme, waarbij de Source een bericht naar de Destination stuurt op het moment dat er nieuwe of gewijzigde bestanden zijn. Wanneer een server met ResourceSync wil werken moet deze server er voor zorgen dat er altijd een actuele siteMap is waarop een volledige inventaris te vinden is van de bronnen op de site, samen met de datum van de laatste wijziging.

ResourceSync is op dit moment nog in de ontwikkelfase. Het theoretische model is al heel goed uitgedacht, maar de onderliggende techniek is nog niet volledig uitgewerkt. Er zijn ook nog geen concrete implementaties van ResourceSync. Er is op dit moment nog onduidelijkheid over hoe bestanden concreet moeten worden overgeheveld. Bestanden kunnen individueel worden gedownload, maar door de “Source” server kunnen er eventueel ook zip-mappen met gewijzigde files worden klaargezet.

Wat tijdens de workshop wel duidelijk werd benadrukt is dat met ResourceSync een aantal van de huidige nadelen van OAI-PMH kunnen worden opgelost. OAI-PMH gaat op de eerste plaats alleen over metadata. Er zijn wel pogingen geweest om ook digitale objecten over te dragen via OAI-PMH, maar dat bleek technisch heel complex. Bij OAI-PMH moeten alle metadata worden opgenomen als onderdeel van de response, en zijn er beperkingen aan het aantal records dat per response kan worden verstuurd. Hierdoor onstaan er vaak vertragingen. Belangrijk is ook dat er bij OAI-PMH geen push-mechanisme bestaat. Instellingen die willen harvesten moeten dus periodiek polsen of er nieuwe of aangepaste metadata zijn. OAI-PMH is al meer dan tien jaar oud en de web-technologie is inmiddels natuurlijk verder geëvolueerd. Gezien de huidige problemen rond OAI-PMH is het niet ondenkbaar dat instellingen die nu harvesten via dit protocol (een voorbeeld hiervan is natuurlijk de KNAW, die ons repository harvesten voor de NARCIS-portal) op termijn zullen overstappen naar ResourceSync. Het is daarom zeker een ontwikkeling om goed in de gaten te houden!

De presentatie die tijdens OAI8 is gegeven door Herbert Van de Sompel, Robert Sanderson en Stuart Lewis is hier te bekijken.