Categorie archieven: Repository

Islandora Online: Islandora as an Institutional Repository

Geplaatst op door
Beantwoorden

Dit jaar wordt er vanwege de corona crisis ook door Islandora een Online event gehouden. Of eigenlijk zijn het 4 events van elk 5 uur.
Hieronder het verslag van het vierde en laatste event, gehouden op 11 augustus. Eerdere verslagen zijn hier te vinden: Islandora 8, Islandora & Metadata, en Migration.

Islandora as an IR

Eerst wordt er een overzicht gegeven van de huidige stand van zaken. Er is een aantal modules in Islandora 7 die het mogelijk maken om Islandora als een IR te gebruiken. PDF solution pack, Usage Stats, Entities solution pack, Scholar, IP Embargo zijn voorbeelden. Het LASIR project heeft ook veel gedaan voor IR in Islandora 7. Drupal 8 biedt zelf al een groot deel van de functionaliteit die deze modules verschaffen. Een ander deel zit nu al in Islandora 8. Wat vooral nog ontbreekt, zijn embargo’s en importeren van DOIs, PubMed, en dergelijke. Wat er al wel is, is LDAP for institutional login, Orcid login, OAI-PMH, Simple XML Sitemap, MetaTag (for Google Scholar), Entity Browser, Linked Data Lookup Field, PDF.js (embedded PDF viewer)* en meer.

Momenteel wordt er al hard gewerkt aan het implementeren van Embargoes. Hierbij wordt gewerkt met restricties op zowel IP als tijdsgebonden. Dit kan op “object” (node) niveau en op “bestanden” (media) niveau. Permissions by term maakt het nu al mogelijk in Drupal 8 om restricties via metadata terms te regelen. In Persistent Identifiers wordt Handles en DataCite DOIs geïmplementeerd. CrossRef DOIs wordt aan gewerkt. Er zijn plannen voor andere identifiers via een generiek framework. Over “dynamic citaties display” wordt momenteel veel nagedacht, maar er is nog geen implementatie van.

Open Access Kent State (OAKS) heeft een IR in de lucht in Islandora 8. OAKS bevat 3500 artikelen, 12 tijdschriften en 1600 conference proceedings. Discovery Garden heeft een IR oplossing gemaakt voor Islandora 8. Hier zijn speciale content types en open standaard taxonomieën voor ontwikkeld. Ook bieden ze een invoer-workflow, access control, embargo’s, rights and license management, versioning, SSO, OAI-PMH en een speciale IR presentatie laag.

Islandora as an Data Repository

UPEI (University of Prince Edward Island, de geboorteplek van Islandora) deed een project van 18 maanden om Islandora 8 als Data Repository in te richten. Dit is goed gedocumenteerd op https://islandora-rdm.researchspaces.ca/. Een onderzoeker kan hiermee de data van een onderzoek plannen, bewaren, mee (samen)werken, publiceren onafhankelijk van formaat of grootte van de dataset. De dataset krijgt een DOI, is doorzoekbaar, krijgt metadata, verwijst via ORCID en FundRef en is veilig.

Standaard node-media-files relatie

Het project bevat zowel code als veel documentatie en manieren waarop een Data Repository ingericht kan worden. Een van de grote verschillen met Islandora 8 (en standaard Drupal 8) is hoe bestanden gerelateerd worden. Normaal gesproken wordt elk bestand in Drupal 8 vertegenwoordigd door een Media type. Een media type bevat velden (voor metadata), heeft versie beheer en kan bijna alles wat een Content node ook kan. Een media type heeft ook een source type. Een source type bepaalt of het om een plaatje, video, geluid of iets anders gaat. Content node is het eigenlijke item in Drupal. Dit content node kan een of meerdere media types bevatten.

Het project heeft de relatie tussen nodes, media en bestanden aangepast zodat een media type meerdere bestanden kan bevatten. Dit maakt het beheer van een dataset eenvoudiger omdat er eigenlijk een laag minder is. In de normale situatie bevat een dataset bijvoorbeeld 3 delen. Elk deel bevat een media entity voor het oorspronkelijke bestand en 2 media entities voor elke afgeleiden. Er zijn dus 9 media entities nodig.

In de nieuwe situatie hebben ze aan het media type een aantal velden toegevoegd voor deze afgeleiden, waardoor een media entity het oorspronkelijke bestand en de afgeleiden bestanden kan bevatten.

Complexe workflows

Drupal 8 bevat support voor complexe workflows om publicaties in te voeren en te wijzigen. Formulieren kunnen op diverse manieren gemaakt worden. Hier zijn veel mogelijkheden voor. Maar een ingevoerde publicatie moet nog door diverse mensen gecontroleerd kunnen worden. Die publicatie moet op dat moment nog niet zichtbaar zijn voor het publiek. De publicatie moet echter wel zichtbaar en bewerkbaar zijn voor een selecte groep mensen. Een publicatie moet eigenlijk een bepaalde status hebben waarbij een bepaalde groep mensen toegang heeft. Tussen deze statussen moet een overgang zitten van de ene status naar een andere status. Content moderation biedt deze functionaliteit. Ook kan de Rules module reageren op status overgangen. Bijvoorbeeld kan een mailtje gestuurd worden als de status wordt aangepast van een publicatie. Alle bouwblokken voor complexe workflows zijn dus in principe beschikbaar in Drupal 8. Alleen moeten deze bouwblokken nog wel “gestapeld” worden en geconfigureerd.

Dit was het laatste verslag van Islandora Online. Natuurlijk heb ik niet alle onderwerpen die voorbij kwamen behandeld, dus hierbij ook een link naar de event pagina met daarop de dagprogramma’s en een link naar de video’s die gemaakt zijn van de presentaties.

Islandoracon 2019

Geplaatst op door
Beantwoorden

IslandoraCon is de Islandora Conferentie die eens in de 2 jaar wordt gehouden. Islandora is het open source digitaal repository systeem dat door de Universiteit Leiden gebruikt wordt voor haar Digitale collecties en binnenkort ook voor het Scholarly Repository en het Student Repository.
IslandoraCon werd na Charlottetown (2015) en Hamilton (2017) dit jaar in Vancouver gehouden. Het was een vooral Canadees/Amerikaanse aangelegenheid want van de 110+ bezoekers kwamen er 3 van buiten Canada en Amerika; een uit Afrika, een uit Nieuw-Zeeland en een uit Europa (ik). Het congres zelf duurde 3 dagen maar werd voorafgegaan door een dag met workshops en afgesloten door een Use-a-Thon/unconference.
Hieronder een verslag van de 5 dagen.

De eerste workshop waar ik aan deelnam ging over ISLE. De afkorting staat voor Islandora Enterprise en wordt ontwikkeld door de Islandora Collaboration Group (ICG). Eigenlijk is dit Islandora als een Docker container, waardoor naar eigen zeggen het minder werk is om Islandora te installeren en onderhouden, makkelijker overgegaan kan worden naar nieuwe versies (dus ook de overstap van Islandora 7 naar Islandora 8) en het betere security en reliability biedt omdat het vaker geüpdatet wordt. Natuurlijk staat daar tegenover dat er minder mogelijk is wat betreft eigen invulling van hoe de componenten samenwerken en waar ze geïnstalleerd zijn (meerdere servers). We hebben zelf ISLE geïnstalleerd op onze lokale laptop met behulp van Docker, dit was redelijk eenvoudig maar vereiste dan wel weer kennis van Docker en andere componenten zoals Traefik.

De tweede workshop ging over plugins maken voor Drupal 8. Dit was erg interessant maar drukte me meteen met de neus op de feiten: er is nog een heleboel te leren, alleen al over Drupal 8.
Een plugin is een nieuwe API in Drupal 8. Het is de bedoeling dat een plugin precies 1 ding doet, zodat het goed herbruikbaar en snel is. Plugins zijn configureerbaar, ze kunnen verschillend gedrag/functionaliteit implementeren via een zelfde interface. In Drupal 8 zijn er ook services. Services zijn uitwisselbaar met elkaar en bieden hetzelfde gedrag/functionaliteit maar met verschillende interne implementaties. Een voorbeeld van een service is bijvoorbeeld caching; er zijn verschillende services die caching binnen Drupal kunnen verzorgen, en deze zijn uitwisselbaar al naar gelang de wensen en eisen. Een voorbeeld van een plugin is bijvoorbeeld het maken van afgeleide plaatjes wanneer er een TIF plaatje wordt ingeladen binnen Islandora 8 (wat dus eigenlijk Drupal 8 is aan de voorkant).
Het plugin systeem vervangt het hook systeem van Drupal 7 en is net zo krachtig, maar duidelijker gedefinieerd en meer toekomst bestendig.

Na de workshops van dag 1 werd de conferentie echt geopend met een overzicht van Islandora nu en in de toekomst. Natuurlijk ligt de focus nu op Islandora 8, wat voorheen Islandora CLAW genoemd werd. Maar Islandora 7 wordt zeker niet vergeten. Er wordt voor Islandora 7 overgegaan naar een jaarlijkse release (dit was 2 keer per jaar), maar aangezien er nog steeds veel instellingen gebruikmaken van Islandora 7, wordt het voorlopig nog ondersteund: na november 2020 wordt er geen nieuwe functionaliteit meer toegevoegd, na november 2021 worden er geen bug fixes meer gedaan en na april 2022 worden er geen security fixes meer gedaan. Dit hangt ook samen met Drupal 7 dat vanaf november 2021 niet meer ondersteund wordt.
Verschillende aspecten van Islandora worden behartigd door verschillende groepen: de Coordinating Committee (voorheen de Roadmap Committee) bepaalt de richting van Islandora op de langere termijn en bevordert de Islandora community, de Technical Advisory Group doet aanbevelingen met betrekking tot de architectuur en technische roadmap van Islandora, de Multi-tenancy Interest Group houdt zich bezig met multi-site support in Islandora 8 (één Islandora installatie met meerdere websites) en de Metadata Interest Group focust op metadata (vooral in Islandora 8 aangezien het hier heel anders werkt). Andere interest groups zijn hier te vinden: https://github.com/islandora-interest-groups

Er werd deze dag veel over Islandora 8 verteld. Versie 1.0.0 is op 5 juni 2019 officieel uitgekomen. Waar Islandora 7 nog als een hamburger werd gerepresenteerd, wordt Islandora 8 als een bento box gezien, namelijk verschillende onderdelen die goed met elkaar samengaan (samenwerken) maar uitwisselbaar zijn. Islandora 8 is veel meer verweven met Drupal 8. Waar Islandora 7 het mogelijk maakte om Islandora objecten binnen Drupal te gebruiken, is het bij Islandora 8 zo dat die objecten volledige Drupal nodes zijn. Islandora 8 maakt gebruik van nodes (waar islandora 7 een object gebruikt), files (vergelijkbaar met de datastreams in 7) en media (deze koppelt de nodes aan de files en hier wordt de technische metadata bewaard). Islandora objecten zijn dus “first-class citizens“. Dit betekent dat alle modules die voor Drupal 8 geschreven zijn, ook meteen toepasbaar zijn voor Islandora 8. Eigenlijk is Islandora 8 zelf onder andere een Drupal 8 module die de functionaliteit van een digital repository aan Drupal toevoegt. Veel functionaliteit waarvoor in Islandora 7 veel code nodig was, is in Islandora 8 al beschikbaar via Drupal 8 en door configureren beschikbaar te maken. Islandora 8 voegt aan Drupal 8 onder andere het volgende toe: JSON-LD (een manier om Linked Data over te dragen als JSON), een koppeling met Fedora Commons (met behulp van Flysystem worden bepaalde bestanden in Fedora bewaard) en het genereren van afgeleiden.
Er wordt al hard gewerkt aan de volgende versies van Islandora 8: er worden onder andere breadcrumbs, paged content (wat boeken en kranten mogelijk maakt), IIIF manifesten, text extraction en versioning toegevoegd. Dit zou voor het eind van dit jaar gereed moeten zijn. Ook wordt er gekeken naar de migratie naar Drupal 9 en Fedora Commons 6, aangezien Drupal 9 eind 2020 uitkomt. Dit betreft een kleine update en is zeker geen migratie zoals van Islandora 7 naar 8. Wel biedt Fedora Commons 6 het Oxford Common File Format. Dit is een standaard manier voor opslaan van digitale informatie waardoor deze data compleet (de hele repository kan opnieuw opgebouwd worden met deze data), leesbaar (voor mens en machine, ook zonder de originele software), robuust (fouten in bestanden kunnen ontdekt worden, migratie is makkelijker) en versiebeheerd (wijzigingen zijn herleidbaar en kunnen teruggedraaid worden) opgeslagen kan worden op verschillende storage mogelijkheden (filesystem, cloud, etc.).
Migratie van data naar Islandora 8 werd ook uitvoerig besproken. Ook dit gaat op een standaard Drupal 8 manier. Er is een Migrate API in Drupal 8 ingebouwd die werkt volgens het ETL principe; Extract – Transform – Load. Hier zijn al meerdere plugins voor beschikbaar en migratie is dus vooral een kwestie van veel configuratie bestanden maken of aanpassen, testen en migreren. Er wordt druk gewerkt aan standaard manieren om Islandora 7 data te migreren naar Islandora 8, maar aangezien er altijd “eigen wensen” zijn zal geen enkele migratie dit zonder aanpassingen kunnen gebruiken.

Gedurende de hele conferentie waren er interessante presentaties van andere Islandora gebruikers. Er was een presentatie over een interactieve kaart met verhalen over Vancouver, waarbij op de kaart aangegeven was waar het verhaal was verteld. De verhalen worden zo op een heel andere manier gevonden. Zoals veel bij Islandora, is de code achter de site vrij toegankelijk. Zie https://thisvancouver.vpl.ca/story-city
De mensen van Discover Okanagan Historical Resources hadden een aparte kijk op digitaliseren: het afbreken van een collectie en het opnieuw digitaal opbouwen ervan, waarbij bepaalde impliciete relaties worden verwijderd die later opgebouwd moeten worden in metadata.
Er was een sessie over performance van Islandora, waaruit bleek dat we al veel goed doen, maar Solr optimalisatie is nog wel een belangrijk punt wat nog gedaan moet worden. Optimalisatie bleek ook nu weer een zeer gespecialiseerd onderwerp te zijn waarbij er niet altijd standaard oplossingen zijn.
Een andere sessie ging over microservices. Dit zijn een of meerdere gespecialiseerde programma’s die communiceren met Drupal over (meestal) http. Deze microservices kunnen draaien op “any server, in any language and under any technology”. Islandora 8 maakt veel gebruik van microservices, onder andere voor afgeleiden maken (audio, video, images), FITS (File Information Tool Set, technische metadata uit bestanden halen), text extraction, fixity checks en BagIt integration. In Drupal kan een bepaalde actie gedaan worden als binnen een context aan bepaalde condities voldaan is. Dit is zonder veel code te configureren, zodat bijvoorbeeld als er een original file aan de media wordt toegevoegd (context en conditie), deze door Drupal aan CrayFITS (microservice) gegeven wordt, die de technische metadata uit het bestand haalt en weer binnen Drupal bewaard (action), waarna dit weer in Solr geïndexeerd wordt (dit is weer een andere microservice).
Er waren nog vele andere interessante presentaties, onder andere over content modelling in Islandora 8, diverse manieren van inlezen van content, over namen (“Falsehoods librarians believe about names”) en over headless Islandora. Helaas staan deze presentaties nog niet online, dus kan ik hier niet naar linken.

De laatste dag was gereserveerd voor een Use-a-Thon en de unconference. Tijdens de Use-a-Thon werden bepaalde usecases opgelost in groepsverband, waarbij mooie prijzen te winnen waren. De winnaars hadden een oplossing voor Oral History Transcriptions, Collection Search en multi-tenancy. Helaas viel onze groep (de “Exhibitionists”) net buiten de prijzen, maar toch een mooi resultaat.

Het was een erg zinvolle conferentie waarbij ik veel geleerd heb, maar waar het ook duidelijk werd dat er nog heel veel te leren valt, vooral over Islandora 8.

Islandora Camp Limerick 2018

Geplaatst op door
Beantwoorden

Ook dit jaar ben ik weer naar Islandora Camp geweest. Dit keer was het in Limerick in Ierland. Ik zou met Jan Jouke en Mick van DD beheer gaan, maar Mick kon wegens ziekte helaas niet mee. Aangezien dit al mijn derde Islandora Camp was (na Delft en Madrid) en we inmiddels veel ervaring hebben met Islandora, was niet alles even interessant meer, maar het was wel goed om andere Islandora gebruikers te ontmoeten en te kunnen spreken.

Islandora Camp duurt 3 dagen en is altijd hetzelfde opgedeeld: de eerste dag gaat het om kennismaken met Islandora en met elkaar. De tweede dag wordt de diepte ingedoken met code (dev track) of beheer (admin track) en worden allerlei vragen beantwoord. De derde en laatste dag worden er presentaties gehouden door gebruikers van Islandora en wordt het camp afgesloten met zowel een prijsuitreiking als een “unconference”. Hieronder een verslag van het hele camp.

Jan Jouke en ik waren dinsdag al aangekomen en woensdag was de eerste dag van het Camp. Het werd gehouden in de Tierney building op de campus van de Universiteit van Limerick (“Ollscoil Luimnigh” in Iers). Na een korte opening en introductie kon iedereen zichzelf voorstellen. Aangezien er 22 mensen waren, was dit goed te doen. Hierna werd de architectuur van Islandora uitgelegd, inclusief hamburger. Je kan daar meer over lezen in mijn blog van vorig jaar.

De nieuwste versie van Islandora (versie 7.x-1.11) heeft de mogelijkheid om een andere Image Server te gebruiken, namelijk Cantaloupe. Dat is interessant omdat Cantaloupe de IIIF image API ondersteund. Voor wie niet bekend is met IIIF, ik heb er eerder over geschreven hier en hier. Dit betekent niet dat Islandora nu IIIF compliant is, maar het is wel een stap in de juiste richting.

Verder werd er veel gesproken over de CLAW, dit is een geheel nieuwe versie van Islandora die in ontwikkeling is. De onderliggende componenten van de huidige Islandora (zoals Fedora Commons, Drupal en SOLR) zijn inmiddels allemaal geüpgraded en zijn zodanig veranderd dat de huidige architectuur van Islandora niet meer geschikt is. Dit was de reden om aan een hele nieuwe versie van de Islandora architectuur te gaan bouwen, die dus bekend staat onder de naam CLAW (een recursief acroniem wat staat voor CLAW Linked Asset WebFramework). De architectuur can de CLAW heeft een hele andere opzet dan de huidige versie van Islandora. Nu is het zo dat Islandora tussen Fedora en Drupal staat en de communicatie tussen deze twee regelt. Fedora wordt gebruik voor de opslag van alle data en Drupal wordt gebruikt voor het afbeelden van deze data, maar binnen Drupal is eigenlijk niks bekend over een Islandora object. Dit heeft als nadeel dat veel Drupal modules (uitbreidingen op Drupal functionaliteit, waarvan er duizenden bestaan) gebruik maken van de data die in Drupal zit en dus niet gebruikmaken van Islandora data. Hier zijn vaak wel oplossingen voor te vinden, maar dat houdt in dat er een extra module geschreven moet worden om deze Drupal functionaliteit ook binnen Islandora mogelijk te maken.
Binnen de CLAW worden de objecten behandeld als Drupal objecten. De archiefkopieën worden nog steeds opgeslagen in Fedora, maar het object met de afgeleiden bestaat in zijn geheel in Drupal. Dit heeft als voordeel dat alle Drupal modules direct te gebruiken zijn, aangezien deze kunnen omgaan met Drupal objecten. Dit belooft dus een hechtere band met de grote Drupal community, waardoor het makkelijker wordt om functionaliteit aan de voorkant van het systeem toe te voegen.
Verder is de CLAW veel modulairder opgezet en is de koppeling tussen de verschillende onderdelen veel losser. Dit heeft als voordeel dat een onderdeel wat een bepaalde functionaliteit biedt, makkelijker uitgewisseld kan worden door een ander onderdeel wat dezelfde functionaliteit biedt.
De Drupal objecten kunnen relaties met elkaar hebben, bijvoorbeeld dat een object onderdeel uitmaakt van een ander object (boek-pagina of compound-child relatie) of een object wat op een andere manier aan een ander object gerelateerd is. Elk Drupal object heeft daarnaast tags, waarmee het op meerdere manieren geclassificeerd kan worden.
Alle acties die op een Drupal object uitgevoerd (kunnen) worden, worden bepaald aan de hand van de tags van het Drupal object. Acties zijn dus veel minder gebonden aan het content model van het object. Bijvoorbeeld bij het inladen van een object wordt aan de hand van de tags bepaald welke afgeleiden gemaakt gaan worden. Ook wordt aan de hand van de tags bepaald hoe het object afgebeeld gaat worden. Dit heeft als voordeel dat het geheel veel flexibeler wordt. Acties zijn zelf te definiëren binnen Drupal en te koppelen aan tags.

Aan de CLAW wordt op dit moment nog hard gewerkt en getest. Momenteel is het alleen mogelijk om plaatjes op te nemen; boeken, video, audio, compounds, tijdschriften zijn allemaal niet mogelijk. Er is een aantal kleine sites die op de CLAW draaien, maar dat is nog erg in de testfase. Er werd wel gevraagd of meer instituten interesse hadden om mee te testen en een collectie in de CLAW te zetten. Op dit moment hebben wij er geen tijd voor, maar mogelijk is dit iets voor de toekomst.

Dag 2 werd de diepte ingedoken. Na enige discussie werd besloten dat de ochtend werd gebruikt voor de huidige versie van Islandora en de middag voor de CLAW. In de ochtend ging het vooral over performance; hoe zorg je ervoor dat Islandora snel blijft aanvoelen. Verschillende performance improvements kwamen voorbij, waarvan wij er heel wat al hebben geïmplementeerd. Andere mogelijkheden zijn interessant om uit te zoeken, want wellicht is daar nog wat snelheid te halen. Helaas kost dit uitzoeken natuurlijk ook tijd (en geld), dus dat is iets voor de toekomst.
In de middag hebben we meer gehoord en gezien van de CLAW. Een groot deel van de tijd zijn we ook bezig geweest om de CLAW te installeren op onze eigen laptop, door gebruik te maken van ansible en vagrant. Hieruit bleek dat hoewel CLAW al best goed werkt, het nog bij lange na niet geschikt is als productie systeem.

De derde dag begon met de camp awards. Er worden elk jaar prijzen uitgereikt in diverse categorieën en dit jaar won Jan Jouke de “camp spirit” award.
Hierna werden diverse presentaties gehouden door gebruikers van Islandora:
Cillian Joy van NUI Galway vertelde over hun Maker Space, een ruimte met 3D printers, Raspberry pi’s, animatie software en Arduino boards. Hij vertelde ook een project over het vertellen van een verhaal met behulp van boeken. Hiervoor werd zowel Islandora, Omeka als Neatline gebruikt. Zie O’Shaughnessy Memoirs.
Ik had zelf ook een presentatie over onze module “conditional access rights”. Hiermee kan op basis van condities de toegangsrechten van objecten geregeld worden. Condities kunnen bijvoorbeeld gedefinieerd worden door bepaalde inhoud van metadata velden, locatie van de gebruiker of wel of niet ingelogd zijn. Aan de condities kan een actie gekoppeld worden, zoals toegang tot een object en/of de datastreams van het object, kunnen downloaden van deze datastreams en het zichtbaar maken van bepaalde copyright data. Ook vertelde ik iets over onze module om data te exporteren uit Islandora en over onze module om data in Islandora achteraf in batch te kunnen wijzigen.

De derde dag eindigde met de unconference, waarbij iedereen vragen kon stellen in een relaxte setting. Jan Jouke en ik hadden nog wel wat vragen en al snel waren 2 van de 3 instructeurs die het camp leidden, voor ons bezig met aanpassingen aan Islandora en het opstellen van change requests.

Zoals elk jaar heb ik weer een hoop nieuwe zaken gehoord, nieuwe ideeën gekregen, nog meer vragen die beantwoord moeten worden en vooral een berg zaken waar ik toch echt een keer nog naar moet kijken.

IIIF 2017 Vaticaanstad

Geplaatst op door
Beantwoorden

iiif2017vatican

Van 6 tot 9 juni 2017 was ik met Laurents Sesink (CDS) naar de IIIF (spreek uit als Triple-Eye-Eff) conferentie in Vaticaanstad. Natuurlijk was er veel te zien in Rome en Vaticaanstad zelf, maar de conferentie was ook erg interessant, dus hieronder een korte impressie.

De dag voor de eigenlijke conferentie begon, was er een IIIF showcase waarin duidelijk werd gemaakt wat IIIF nu eigenlijk is en wat je ermee kan. Hieronder nog een korte uitleg over de verschillende mogelijkheden van IIIF, maar ook mijn vorige blog is interessant om (nog eens) te lezen.

IIIF is een verzameling API’s en ideeën/concepten over het tonen van, delen van en samenwerken met plaatjes. Het bestaat momenteel uit 4 verschillende API’s:

  1. Image API, waarmee op een eenduidige manier (delen van) plaatjes opgevraagd kunnen worden in o.a. verschillende groottes en formaten en waarmee informatie over het plaatje verkregen kan worden;
  2. Presentation API, waarmee de structuur en opmaak (layout) van een object bestaand uit meerdere plaatjes beschreven en getoond kan worden inclusief eventuele annotaties;
  3. Authentication API, beschrijft een aantal manieren hoe een IIIF viewer om kan gaan met bestaande authenticatie systemen;
  4. Content Search API, waarmee binnen de structuur van een object en de gerelateerde annotaties gezocht kan worden.

Tijdens de eerste dag van de conferentie werd veel aandacht aan de community gegeven. IIIF is een community-driven framework, wat inhoudt dat het bedacht, gedocumenteerd en onderhouden wordt door een groot aantal mensen van verschillende organisaties. Voor elke specialisatie is er een aparte community die elk wat voorbeelden lieten zien van waar ze mee bezig waren. Een leuk voorbeeld van de manuscript community is hier te vinden. Je kan daar zoeken in een groot aantal manifesten en deze met elkaar vergelijken. Kies rechtsboven in voor “Change Layout” en dan 1×2. Sleep een van de IIIF iconen van links naar de viewer. Je moet soms wat geduldig/vasthoudend zijn, maar het is een mooi voorbeeld van wat kan met IIIF.

De Museums community had een brief opgesteld en verstuurd waarin werd gevraagd aan de makers van bibliotheek software om IIIF te ondersteunen. Aangezien de brief  ondertekend was door meerdere musea in de VS en Europa, zou dit meer gewicht geven aan de vraag om ondersteuning voor IIIF in bibliotheek software.

Verder wordt er hard gewerkt aan Discovery, oftewel er zijn veel organisaties die IIIF gebruiken en hun plaatjes via IIIF aanbieden, maar hoe zorg je er nu voor dat deze ook te vinden zijn. Deze community was druk bezig met het uitzoeken hoe dit het best opgelost kon worden

Er waren ook veel “lightning talks” waarbij verschillende organisaties maar ook software leveranciers lieten zijn waar ze mee bezig waren. Interessant was dat het al veel en steeds meer gebruikt wordt, maar ook dat bijvoorbeeld Europeana zei dat ze IIIF zien “as key to sharing images”. Dit betekent dus dat IIIF steeds beter populairder wordt en dus ook door de grotere spelers gezien en ondersteund wordt.

Verschillende organisaties zijn druk bezig om IIIF op nieuwe en innovatieve manieren in te zetten. Zo is Getty Research bezig met het omzetten van EAD (Encoded Archival Description) naar manifesten voor het gebruik van IIIF. De Johns Hopkins University is bezig met een project om Fedora Commons (de software die wij ook gebruiken als backend van onze nieuwe repository) IIIF te laten praten. Maar helaas bleek dit nog een theoretisch verhaal.

Ook aan het gebruik van annotaties werd door verschillende partijen veel aandacht besteed. Annotaties zijn een essentieel onderdeel van de IIIF API’s maar ze worden hierin niet gespecificeerd. Hiervoor wordt namelijk de Open Annotations Data Model gebruikt. Het annotatie model is heel flexibel opgezet, eigenlijk zijn overal annotaties op te maken, er kunnen zelfs annotaties op annotaties gemaakt worden. Ook kunnen de annotaties van andere bronnen komen dan de manifesten zelf, wat weer meer vrijheid geeft.

Het was zeker een interessante conferentie waarbij heel veel te zien en horen was (en dan heb ik het niet eens gehad over de ICT monnik in habijt, met overgewicht en bloempotkapsel). En natuurlijk was er buiten de conferentie ook veel te zien en lekker te eten!

 

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

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.