Concurrent computing

Schrik niet van de titel van deze blog! Ik leg in deze blog uit wat verstaan wordt onder concurrent computing: welk problemen ermee opgelost worden? Welke nieuwe problemen erdoor ontstaan (en hoe die op te lossen zijn)? Maar waarom het toch een belangrijk onderwerp is wat veel gebruikt wordt.

Wat is concurrent computing?

In het Nederlands wordt de term ‘gedistribueerd programmeren’ gebruikt. Ik houd het in deze blog bij Concurrent computing omdat ik vind dat het de lading beter dekt. Concurrent computing is het opsplitsen van een grote taak in meerdere kleinere taken die (relatief) onafhankelijk uitgevoerd kunnen worden. Deze kleinere taken kunnen tegelijkertijd (concurrent) worden uitgevoerd. Wanneer de kleinere taken afgehandeld zijn, worden ze samengevoegd tot een enkel resultaat.

Aangezien dit vrij abstract is hierbij een voorbeeld: het bakken van een ei.
Dit bevat een aantal taken:

  • pak eieren
  • pak koekenpan
  • pak boter
  • pak zout en peper
  • zet koekenpan op gasfornuis
  • zet gasfornuis aan
  • doe boter in de koekenpan
  • wacht tot boter heet genoeg is
  • breek eieren en doe ze in de koekenpan
  • bak de eieren
  • wacht tot eieren gebakken zijn
  • voeg zout en peper toe
  • doe gasfornuis uit
  • haal koekenpan van gasfornuis
  • schep gebakken eieren uit pan

Zoals je ziet zijn er best veel taken te identificeren bij het “bakken van een ei”. Sommige taken zijn helemaal onafhankelijk van de andere taken. Maar andere taken moeten “wachten” tot een bepaalde taak is afgelopen. Bijvoorbeeld “zet koekenpan op gasfornuis” kan pas starten als “pak koekenpan” is afgehandeld. Ook zijn er taken waarin de volgorde waarin ze onderling afgehandeld worden niet zo van belang is, zoals “pak eieren”, “pak koekenpan”, “pak boter” en “pan zout en peper”. Het maakt niet veel uit of je de eieren, boter, zout en peper of koekenpan eerst pakt. Het maakt ook niet veel uit of je eerst het gasfornuis aan doet, daarna de boter in de pan en dan de pan op het gasforunuis zet, of in een andere volgorde of allemaal tegelijkertijd.

Laten we kijken of we de taken kunnen groeperen en de verbanden kunnen aanbrengen:

Schematische weergave van het bakken van eieren

Welke problemen lost het op?

Als één persoon het ei gaat bakken, dan zal het niet per se sneller of beter gaan. Maar als je meerdere personen hebt die elk een of meer taken kunnen uitvoeren, dan kan het wel efficienter. Als het het niet gaat om eieren bakken voor 1 persoon, maar eieren bakken voor 100 personen, dan wordt die efficiëntie nog belangrijker.

Een computer kan ook meer dan 1 taak tegelijkertijd uitvoeren. Eigenlijk doet een computer dat de hele tijd, maar zijn die taken meestal aparte programma’s. Bijvoorbeeld je hebt nu een web browser open en wellicht een Word document. Voor beide is de computer taken aan het uitvoeren.

Als een computerprogramma wordt uitgevoerd, dan kan je dit zien als een reeks van taken die gedaan moeten worden. Sommige taken duren relatief lang. Zo is het schrijven of lezen van data van een schijf of van het internet, een taak die qua doorlooptijd ergens tussen “meteen klaar” en “dit duurt echt veel te lang” ligt. Dit soort taken wil je eigenlijk laten uitvoeren zonder dat het de rest van het computerprogramma blokkeert. Oftewel het computerprogramma zou niet moeten hoeven wachten totdat de taak afgerond is. Het computerprogramma kan dan verder met andere taken, terwijl de langdurende taak loopt. En als die langdurende taak dan klaar is, wil je verder met de volgende gerelateerde taak.

Een voorbeeld waar je dit kan zien (maar wat je dus eigenlijk niet merkt), is als je aan het tekstverwerken bent. De tekstverwerker zal om de zoveel tijd het gewijzigde bestand automatisch bewaren, zodat mocht er iets misgaan je niet alles overnieuw hoeft te typen. Dit bewaren duurt afhankelijk van de grootte van het bestand zeer kort tot wel enkele seconden, en dit gebeurt terwijl je zit te typen. Het zou dan heel irritant zijn als de letters die je typt niet meer op het scherm verschijnen, omdat de tekstverwerker het bestand net aan het bewaren is. Omdat het bewaren en het tonen van de letters die je typt twee aparte taken zijn die gelijktijdig kunnen gebeuren, merk je hier niks van.

Een ander voorbeeld is een website. Je kan je voorstellen dat meerdere mensen tegelijktijd een pagina van die website willen bekijken. De server waar de website “op staat”, krijgt dan tegelijkertijd verschillende vragen. Zo’n vraag duurt even om af te handelen, voordat het antwoord (de pagina) teruggegeven kan worden. Er draaien dan ook meerdere taken op die server die allemaal zo’n vraag kunnen beantwoorden en deze taken kunnen dat “gelijktijdig” afhandelen.

Je zou dit kunnen vergelijken met een garderobe in de schouwburg; je geeft je jas af, de medewerker hangt het op en geeft een ontvangstbewijs terug. Als er maar 1 medewerker zou zijn en meerdere bezoekers, dan zouden veel mensen lang moeten wachten. Maar met meerdere medewerkers neemt de wachttijd af. Elke medewerker doet dezelfde taak, omdat er veel vraag is naar die taak.

Even terug naar ons voorbeeld. In geval van het eieren-bak-voorbeeld zouden de taken verdeeld kunnen worden als er meer dan een persoon zou meewerken:

Schematische weergave van het bakken van eieren verdeelt over 3 personen

Zoals je ziet zijn er in dit voorbeeld 3 personen die de taken uitvoeren. Sommige taken kunnen prima tegelijkertijd uitgevoerd worden, zoals het pakken van eieren, koekenpan, boter en zout en peper. Aangezien er 3 personen zijn maar dat stukje 4 taken heeft, zal persoon C of eerst de eieren pakken of eerst de zout en peper. Als er nog een 4e persoon was geweest, kon ook dat tegelijk. Ook zie je dat personen soms even moeten wachten totdat een taak is afgerond (die soms door een andere persoon wordt uitgevoerd), voordat ze verder kunnen met hun volgende taak.

Hoe werkt dat dan?

Een computer kan meerdere taken tegelijkertijd uitvoeren, bijvoorbeeld omdat de computer meerdere processoren heeft en/of de processor meerdere “cores” heeft. Dit heet parallel computing. Maar meerdere processoren of “cores” is niet per se een voorwaarde om concurrent computing te ondersteunen. Een computer doet sowieso meerdere taken “tegelijkertijd”, vaak meer taken dan het aantal processoren of cores. Dit werkt zo: de tijd dat 1 taak op de processor mag draaien, is beperkt, vaak tot niet langer dan 10 tot 100 millisecondes. Als de taak binnen die tijd niet is afgerond, dan wordt de taak gepauzeerd en mag een andere taak op de processor. Dit wordt ook wel time slicing genoemd en wordt gebruikt ongeacht het aantal processoren.

In het plaatje hiernaast zie je hoe het werkt. Twee taken worden “tegelijkertijd” afgehandeld. Tegelijkertijd staat tussen aanhalingstekens, omdat steeds eerst de ene daarna de andere wordt gedaan.

Bij 2 processoren kan het er zo uitzien.

Merk op dat de taken niet per definitie aan 1 processor gebonden zijn en dat er nog steeds gebruik gemaakt wordt van time slicing.

Zoals je ziet is de totale tijd die nodig is om taak A en taak B af te ronden kleiner als er 2 processoren gebruikt worden, namelijk 3 time slices bij 2 processoren en 5 time slices bij gebruik van 1 processor.

Welke nieuwe problemen ontstaan?

Concurrent computing kan ervoor zorgen dat taken efficienter uitgevoerd worden en dat het voor de gebruiker lijkt of de computer niet door een bepaalde taak geblokkeerd wordt.

Als taken tegelijkertijd worden uitgevoerd is het wel belangrijk dat iets ervoor zorgt dat de verschillende taken even veel tijd krijgen, dat ze gestart en gepauzeerd worden op het juiste moment en in de juiste volgorde, dat de taken soms onderling moeten kunnen communiceren en dat als ze dezelfde data gebruiken, dat dat geen problemen oplevert. Dit samen wordt concurrency control genoemd.

Een veel gebruikt voorbeeld om te illustreren welke problemen zich kunnen voordoen bij concurrent computing is die van het opnemen van een bankrekening. Je kan je voorstellen dat dit de volgende stappen heeft:

1) controleer of er genoeg op de rekening staat om x bedrag op te nemen

2a) zo ja, haal x bedrag van de rekening

2b) zo nee, laat weten dat het niet kan.

Als op exact hetzelfde moment 2 keer een bedrag van dezelfde rekening wordt gehaald, en er time slicing wordt gebruikt, kan het zijn dat het volgende gebeurt:

Bovenstaande wordt een race condition genoemd.

Om een race condition op te lossen, kan gebruik worden gemaakt van een blokkade; in het voorbeeld hierboven zorg je ervoor dat er maar 1 taak tegelijk iets met de bankrekening kan doen, andere taken moeten even wachten. Dit wordt ook wel een lock genoemd.

Maar hierdoor kan weer een deadlock ontstaan; een vergelijkbaar voorbeeld als hierboven zou zijn geld overschrijven van rekening A naar rekening B. Als twee taken dat willen doen en de eerste zet een lock op rekening A en wil daarna een lock zetten op rekening B, maar de tweede is net iets eerder en heeft al een lock op rekening B gezet en wil een lock op rekening A, dan zijn beide taken op elkaar aan het wachten.

Een ander probleem kan hier weer uit ontstaan: resource starvation. Dit is als een taak iets (een resource) nodig heeft om te beginnen, maar deze resource nooit beschikbaar komt (bijvoorbeeld omdat een andere taak de resource steeds gelockt heeft).

Een voorbeeld van resource starvation is het Filosofenprobleem.

Bovenstaande problemen zijn allemaal op te lossen, maar de programmeur moet zich hiervan wel bewust zijn. Sommige programmeertalen hebben hulpmiddelen zodat bovenstaande problemen zoveel mogelijk voorkomen worden.

Hoe werkt concurrent computing in programmeertalen?

De meeste programmeertalen bieden (op verschillende niveaus) ondersteuning voor concurrent computing.  Bij sommige programmeertalen wordt concurrent computing op een vrij laag niveau ondersteund, wat betekent dat de programmeur veel zelf moet doen. Gelukkig zijn er ook programmeertalen en frameworks die concurrent computing ondersteunen op een hoger niveau, waardoor veel van bovenstaande problemen al opgelost zijn of simpel zijn te voorkomen.

Om het niet onnodig ingewikkeld te maken (en deze blog ook niet te lang), focus ik alleen op een bepaalde manier (op een hoger niveau) van het gebruik van concurrent computing die je in veel talen (onder verschillende namen) terug ziet komen:

Beloftes

Als je aan het programmeren bent, werk je veel met waardes. Bijvoorbeeld een getal, de naam van het bestand wat je op dat moment aan het inlezen bent of de inhoud van datzelfde bestand. Sommige waardes kosten relatief veel tijd om te achterhalen, zoals bijvoorbeeld de inhoud van een bestand, omdat het bestand ingelezen moet worden vanaf schijf of het internet. Het zou dus handig zijn als je dat tegelijkertijd met andere taken kan uitvoeren, zodat het programma er niet op hoeft te wachten. Je doet eigenlijk een belofte dat de waarde achterhaald is op het moment dat je er echt iets mee wilt doen, en in de tussentijd kan je in je programma net doen of je de waarde al hebt.

Een belofte wordt in programmeertalen Promise, Future (een toekomstige waarde), delay (uitstel) of deferred (uitgesteld) genoemd, maar aangezien meestal Promise of Future gebruikt wordt, houd ik het bij “belofte”. Overigens is er een verschil tussen promises en futures die per programmeertaal anders uitgelegd wordt.

Een belofte (Promise / Future) kan dus gebruikt worden alsof het de waarde is die het belooft te zijn. De belofte kan op een gegeven moment vervuld worden (Promise fulfilled of future resolved). Ook kan het zijn dat de belofte gebroken wordt (promise rejected). Als een belofte vervuld wordt, kan het programma iets met de beloofde waarde doen. Maar wanneer een belofte gebroken wordt, kan het programma daar op een andere manier op reageren. Als je bijvoorbeeld in je programma een tekst wil ophalen van een website en een andere tekst van een heel andere website, dan kan je dat zien als twee beloftes voor toekomstige waardes. Deze beloftes kunnen tegelijkertijd vervuld worden, of als het internet “stuk” is, dan worden de beloftes gebroken. Als je een belofte net gedaan hebt, dan is die nog niet vervuld maar ook nog niet gebroken; de belofte staat nog uit (promise pending).

Wat heb je hier nu aan hoor ik je denken? Als we teruggaan naar het eieren-bak-voorbeeld dan zou je de taak “pak eieren” als een belofte kunnen zien dat je op een zeker moment in de toekomst eieren hebt. Als je die belofte kan vervullen, dan kan je doorgaan naar de volgende taak (“breek eieren en doe ze in de koekenpan”), tenzij je de eieren laat vallen, want dan breek je de belofte (en de eieren).

Ons voorbeeld zou er in pseudocode als volgt uit kunnen zien:

eieren = pakEieren()		// de belofte om eieren te pakken
koekenpan = pakKoekenpan()	// de belofte om een koekenpan te pakken
boter = pakBoter()		// de belofte om boter te pakken
zoutEnPeper = pakZoutEnPeper()	// de belofte om zout en peper te pakken
gasfornuis = zetGasFornuisAan()	// de belofte om gasfornuis aan te zetten


BeloftesSamen( [ koekenpan, boter ] )	// als de beloftes beide
 .vervuld( koekenpanMetBoter => { 	// vervult zijn
   BeloftesSamen( [			// doe nieuwe beloftes:
     zetOpGasFornuis(gasfornuis, koekenpan)
     doeBoterInKoekenpan(koekenpan, boter)
     gasfornuis
   ] )
 } )
 .vervuld( heteKoekenpan => {		// als bovenstaande 3 beloftes 
					// vervuld zijn, doe een nieuwe
					// belofte:
   wachtTotBoterHeetGenoegIs(koekenpanMetBoter)
 } )
 .vervuld( koekenpanMetEieren => {	// als bovenstaande belofte 
					// vervuld is, doe nieuwe belofte
   breekEierenInKoekenpan(eieren, heteKoekenpan)
 } )
 .vervuld( bakkendeEieren => {
   BeloftesSamen( [
     bakEieren(koekenpanMetEieren)
     naEnigeTijd {			// terwijl de eieren aan het 
					// bakken zijn, voeg zout en 
					// peper toe na enige tijd
       voegZoetEnPeperToe (koekenpanMetEieren, zoutEnPeper);
     }
   ] )
 } )
 .vervuld( gebakkenEieren => {		// als bovenstaande twee beloftes
					// vervuld zijn:
    wachtTotEierenGebakkenZijn(bakkendeEieren)
 } )
 .vervuld( eierenKlaar => {		// als de bovenstaande belofte 
					// vervuld is,
    BeloftesSamen( [			// doe 3 nieuwe beloftes:
      schepEierenUitPan(gebakkenEieren)
      haalKoekenpanVanFornuis()
      doeGasFornuisUit()
    ] )
  } )
  .vervuld( {		// als bovenstaande beloftes vervuld zijn, dan
    eetEieren()		// zijn de eieren klaar om opgegeten te worden
  } )
  .gebroken( {		// als een van bovenstaande beloftes gebroken 
			// wordt, doe dan dit:
    geefRedenWaaromErGeenEierenZijn()
  } )	

Zoals je ziet kunnen beloftes geschakeld worden in een rij van beloftes (promise chaining), waarbij als een belofte vervuld is een nieuwe belofte gemaakt kan worden. Ook kunnen beloftes samen een nieuwe belofte vormen. Deze nieuwe belofte zal alleen dan vervuld zijn, als alle beloftes waar die uit gestaat, ook vervuld zijn. De volgorde waarin deze beloftes vervuld worden, is dan niet van belang. Ook kunnen ze tegelijkertijd afgehandeld worden.

Ik hoop dat ik de beloftes die ik aan het begin van deze blog deed, heb kunnen vervullen en dat duidelijk is wat concurrent computing is.

Islandora Online: Islandora as an Institutional Repository

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.

Islandora Online: Islandora and Migration

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 derde event, gehouden op 4 augustus. Het verslag van het eerste event is hier te vinden. Het verslag van het tweede event is hier te vinden.

Helaas kon ik niet “live” aanwezig zijn bij dit event vanwege vakantie, maar gelukkig is het hele event opgenomen. Hierbij een verslag gebaseerd op het opgenomen event.

Uitdagingen

Het onderwerp van dit event is het migreren van content naar Islandora 8 vanaf Islandora 7 of een ander systeem. Migreren levert altijd vragen en problemen op, tenzij de data die gemigreerd wordt al perfect is. En dat is eigenlijk nooit het geval. Migreren levert altijd uitdagingen op: Omdat de metadata niet perfect is. Omdat lastige keuzes gemaakt moeten worden. Omdat bepaalde delen van de data niet passen in het nieuwe systeem. Omdat het nieuwe systeem (een nieuw soort) data verwacht of kan bieden die nog niet in het oude systeem zat. Omdat de metadata op een ander precisie niveau ingevoerd moet worden.

Soms moeten er lastige keuzes gemaakt worden tijdens de migratie, die er later voor zorgen dat er meer mogelijk wordt. Zo heeft in de metadata een persoon vaak een rol. Ook kan een persoon identifiers hebben en/of een of meerdere namen. De manier waarop deze data gemigreerd wordt, bepaalt voor een groot deel wat er daarna in Drupal (mee) gedaan kan worden.

Drupal Migrate

Drupal Migrate is de manier om veel migraties te doen. Natuurlijk zijn ook andere manieren mogelijk, maar bij alle zijn twee technieken te onderscheiden: ETL en ELT. ETL staat voor Extract data, Transform data en Load data. Dus eigenlijk haal je de data eerst uit het oorspronkelijke systeem, daarna vorm je de data zo dat het ingelezen kan worden in het nieuwe systeem en dan lees je het in. De letters van ELT staan ook voor Extract, Transform en Load. Alleen wordt de data nu eerst ingelezen waarna het wordt omgevormd.

Drupal Migrate gebruikt ETL, waarbij deze fases duidelijk te onderkennen zijn binnen het proces. Een migratie wordt uitgedrukt als een YAML document. Drupal Migrate maakt ook gebruik van de Drupal Plugin API waardoor het mogelijk is om eigen acties tijdens de migratie te definiëren. Natuurlijk bestaan er al veel van dit soort plugins in de Drupal community en worden ze ook gebruikt binnen Islandora 8. Zo is er een plugin om data te “extracten” uit Islandora 7, maar ook data van bestanden of data via een web API kan gebruikt worden. Maar ook zelf een plugin ontwikkelen is relatief simpel.

Drupal Migrate ondersteunt ook high water marks, wat betekent dat bij een migratie die niet helemaal goed gaat alleen het stuk wat misgaat opnieuw gedaan hoeft te worden. Mocht het helemaal misgaan, dan kan ook een rollback (terug naar een punt waar het nog wel goed was) gedaan worden.

Hulpmiddelen en tutorials

migrate_islandora_csv is een online begeleiding (tutorial) over hoe men Drupal Migrate kan gebruiken. Als bron gebruikt men een CSV bestand, maar er wordt uitgebreid stilgestaan bij het opschonen en vormen van de data (de T van ETL) en hoe men relaties tussen data aanlegt tijdens de migratie. Bovendien wordt dit alles stap-voor-stap uitgelegd.

migrate_7x_claw is een module bedoeld om te migreren vanaf Islandora 7 naar Islandora 8. Alle datastreams worden hiermee gemigreerd, inclusief “audit trail“. De metadata wordt gemigreerd vanuit Solr of een willekeurige XML datastream. Maar migrate_7x_claw is vooral een startpunt voor de migratie en nog geen volledige oplossing. Het is iets wat nog verder ingevuld en ontwikkeld moet worden voor de specifieke situatie. Om migrate_7x_claw goed te kunnen gebruiken en begrijpen, is migrate_islandora_csv een goed startpunt. Ook is het belangrijk om de Drupal Migrate API goed te begrijpen, maar ook Drupal config synchronization en Drupal features.

Andere migratie methodes

Migratie kan natuurlijk ook op een andere manier. Islandora 7 content wordt opgeslagen in Fedora 3.x. Islandora 8 content wordt (deels) opgeslagen in Fedora 5. Fedora 5 en 6 verschillen niet veel van elkaar, in elk geval veel minder dan Fedora 3 verschilt van Fedora 5. Islandora 8 of 9 gaat op een gegeven moment ook draaien op Fedora 6. Vanuit de Fedora community is er een project om de overgang van Fedora 3 naar Fedora 6 wat betreft migratie zo simpel mogelijk te houden. Ze zijn hier ook druk mee bezig dus het is interessant om te kijken of dit ook een manier is om van Islandora 7 naar Islandora 8 over te gaan.

Zowel Islandora 7 als Fedora 3 hebben een REST API. Ook Islandora 8 bevat een REST API. Dus in principe is het mogelijk om data uit het oude systeem te halen via de REST API. Daarna deze data omzetten in een ander formaat met welke methode/programmeertaal dan ook. Vervolgens de data inlezen via de Islandora 8 REST API. Voordeel is dat je volledige controle hebt over de data en het proces, maar dat is ook meteen het nadeel. Dit betekent namelijk dat je alles zelf moet doen.

Islandora Workbench is een ander hulpmiddel om te gebruiken bij migraties. Het gebruikt de REST API en gebruikt als bron een CSV bestand. Dit bestand moet al wel het juiste formaat hebben. De export en transform moet dus eigenlijk buiten Workbench om gedaan worden. Hierdoor is de configuratie en gebruik van Workbench vrij simpel, maar het werk ervoor kan complex(er) zijn. Workbench heeft allerlei manieren om de data voor ingesten te checken, zodat bij ingest er geen verrassingen zijn.

Migratie naar Islandora 8 kan dus op veel manieren, maar zal altijd (in meer of mindere mate) werk en hoofdbrekers opleveren. Al met al een erg interessant event, waarbij ik veel geleerd heb. Migratie naar Islandora 8 is veel verder dan ik gedacht had. Het verslag van het vierde en laatste event is hier te vinden.

Islandora Online: Islandora & Metadata

Dit jaar wordt vanwege de corona crisis ook door Islandora een Online event gehouden. Eigenlijk zijn het 4 events van elk 5 uur. Hieronder het verslag van het tweede event, gehouden op 28 juli. Het verslag van het eerste event is hier te vinden.

Metadata anders

Het tweede event had als onderwerp metadata. Islandora 8 behandelt metadata anders dan Islandora 7. In Islandora 7 wordt de metadata in een XML bestand ingeladen. MODS, Dublin Core, METS en MADS (voor personen) zijn opties, waarbij meestal MODS gekozen wordt. Islandora 7 genereert dan Dublin Core metadata uit de MODS omdat Dublin Core in Fedora verplicht is. Islandora 8 slaat de metadata op in Drupal fields die aan een “Repository item” hangen. Deze velden kunnen bepaalde beperkingen hebben, zoals lengte of inhoud. Zo kan je instellen dat bijvoorbeeld een datum veld ook echt alleen datums kan bevatten.

Beperkter met meer mogelijkheden

Islandora 8 levert standaard al veel metadata velden mee. Er is een mapping van MODS naar deze velden. Maar MODS (en andere metadata schema’s) bieden veel meer mogelijkheden om de metadata precies te typeren/classificeren. Er werd dus gediscussieerd over deze mapping en of het gebruik van velden niet te beperkend is. Hier werd geen concensus over bereikt.

Nu is het wel zo dat hoewel wij in Islandora 7 MODS gebruiken met een groot aantal velden, we lang niet alle velden van deze MODS ook echt afbeelden of op andere manieren gebruiken. Deel van de discussie was ook of Islandora nu echt de plek is om al je metadata te managen. Of zijn er systemen die daar beter geschikt voor zijn. Ik denk dat het laatste het geval is.

Taxonomie en Linked Data

Drupal 8 maakt voor de velden (indien gewenst) wel gebruik van een taxonomie. Deze kan zowel open (gebruikers kunnen eigen termen toevoegen) als gesloten (gebruiker kan alleen kiezen uit een vastgestelde lijst) zijn.
Er was ook een praatje over hoe je een autocomplete veld maakt die via Linked Data de data ophaalt. Hierbij werd zowel de tekst als een URI opgeslagen, zodat de relatie gehouden blijft.
De metadata bij een Repository item wordt in Fedora als Linked Data opgeslagen. Wanneer de metadata wijzigt van een item, dan wordt deze geserialiseerd in RDF en vanuit Drupal naar Fedora gestuurd, zodat de metadata ook duurzaam bewaard blijft.

Gebruik en tools

Er werd natuurlijk ook gesproken over het gebruik van metadata; welke velden missen in welke situaties en hoe wordt metadata opgeruimd in Islandora 7 zodat de migratie naar Islandora 8 beter en soepeler verloopt. Dat de metadata in Islandora 7 opgeruimd moet worden voordat aan de migratie naar Islandora 8 begonnen wordt, staat als een paal boven water.
Islandora Workbench is een tool om metadata (maar ook objecten) te kunnen wijzigen of inladen. Er zijn verschillende andere manieren om dit te doen voor zowel Islandora 7 als 8. Maar het is goed te zien dat verschillende tools worden ontwikkeld want dan is er iets te kiezen.

De dagen zijn wel lang als je een online event “bezoekt” wat in Canada gehost wordt. Ze hielden wel een beetje rekening met andere landen door het begin uur steeds te verschuiven, maar dit event was pas om 10 uur ’s avonds afgelopen. Hier is het verslag van het derde event te lezen.

Islandora Online: Islandora 8

Dit jaar wordt vanwege de corona crisis ook door Islandora een Online event gehouden. Eigenlijk zijn het 4 events van elk 5 uur. Hieronder een verslag van het eerste event, gehouden op 21 juli en alleen online (dus geen mooie plaatjes van exotische oorden).
De events hebben allemaal een soortgelijke opbouw: steeds ongeveer 1 uur praatjes en daarna korte pauze, met in het midden een langere pauze van een uur waarvan een half uur “social” is: je kan praten met de anderen (business or pleasure) of een spelletje spelen (vooral kruiswoordraadsels in het Engels zijn een uitdaging).

Verschil tussen Islandora 7 en Islandora 8

Het eerste event had als onderwerp Islandora 8. Islandora 8 verschilt van Islandora 7 nog meer dan Drupal 7 verschilt van Drupal 8. Maar dat is zeker niet slecht. Waar Islandora 7 Drupal 7 gebruikt om Islandora content te tonen, is in Islandora 8 deze content eigenlijk gewoon al Drupal 8 content. Dit houdt in dat Islandora 8 veel dichter bij Drupal 8 blijft en daardoor allemaal technieken maar vooral ook modules van Drupal 8 (een soort plug-ins voor extra functionaliteit) zonder enige aanpassing meteen kan gebruiken. Dit maakt Islandora 8 flexibeler en makkelijker uitbreidbaar.

Taken en microservices

Taken worden ook veel beter gescheiden van andere zaken: microservices voeren precies 1 bepaalde taak uit, los van de rest van het systeem. Bijvoorbeeld het aanmaken van afgeleiden of “optische tekenherkenning” (OCR) wordt geheel los van Drupal uitgevoerd, eventueel op hele andere servers. Een bepaalde actie start de microservice vanuit code door een en met een bepaalde context. De microservice wordt echter niet meteen gestart. De vraag en context worden in een wachtrij gezet totdat de microservice vrij is om de vraag te beantwoorden. Als de microservice klaar is, komt het antwoord (bijvoorbeeld een afgeleide of een OCR bestand) terug naar Drupal.

Digitale preservatie en opslaan

De taak van het opslaan van de data wordt uitbesteed aan Flysystem. Flysystem zorgt ervoor dat de plek waar de data opgeslagen wordt en de manier waarop opgeslagen wordt abstract is voor Drupal. Flysystem koppelt Fedora aan Drupal, waardoor de belangrijke data in een Digital Asset Management system wordt opgeslagen. Aangezien dit allemaal in te stellen is, kan gekozen worden wat nu eigenlijk belangrijke data is die dus opgeslagen wordt in Fedora, zodat Fedora de digitale preservatie kan regelen. Maar als de data naar een andere plek moet, kan dit ook. Opties hierbij zijn ondere andere local disk, (s)ftp, dropbox, AWS S3 of andere Cloud storage (via OpenStack swift).

Integraties en community

Islandora 8 heeft inmiddels een grote groep mensen die eraan werken en ook integraties met andere systemen maken. Zo is er al een integratie met ArchivesSpace. Voor statistieken wordt Matomo gebruikt, maar dit staat nog in de kinderschoenen. Islandora 8 biedt ook OAI-PMH. Zoals bij alles in Drupal 8 is ook dit een view, die helemaal is in te stellen zoals je wilt. Ook is Islandora 8 uit de box IIIF compatible. Cantaloupe implementeert de IIIF image API. Drupal 8 genereert de IIIF manifests (ook een view). Islandora 8 kan een manifest interpreteren en via een ingebouwde IIIF viewer afbeelden.

Support en updates

Drupal 7 support is uitgebreid tot november 2022. Islandora 7 houdt vast aan de eerdere datums. Dit betekent features tot november 2020, bug fixes tot november 2021 en security updates tot april 2022. Drupal 8 support loopt (gek genoeg) tot november 2021, maar de overstap naar Drupal 9 is relatief klein. Wanneer Islandora 9 uitkomt en de support voor Islandora 8 eindigt, is nu nog niet bekend.

Het was een hele interessante middag en avond. Over de andere 3 events verschijnt binnenkort ook een blog. Hier staat de blog van de tweede dag en hier die van de derde dag.

Islandoracon 2019

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

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.

Islandora Camp Delft 2017

islandora_camp_delft

Van 13 tot en met 15 juni 2017 werd het Islandora Camp in Delft gehouden. Een Islandora Camp is een bijeenkomst van gebruikers van Islandora (een digitaal repository) waar presentaties, workshops en tutorials gehouden worden door de Islandora Foundation en ook de gebruikers zelf. Ook wordt er veel gepraat en vooral kennis gedeeld tussen alle gebruikers van Islandora, wat ook dit keer weer heel zinvol was. Vanuit Leiden waren we met een (zware) delegatie van 4 personen: Wouter Kool van de faculteit Archeologie, Liesbeth van Wijk en Niels Molenaar van Digitale Diensten, en ik.
islandoraburger
De eerste dag werd uitgelegd wat Islandora nu eigenlijk is, wat je ermee kan, hoe je kan bijdragen en wat er in de (nabije) toekomst gaat gebeuren. Elk jaar wordt bij de uitleg van wat islandora is de Islandora hamburger erbij gehaald. Het ene jaar is het plaatje wat mooier dan het andere jaar maar het komt erop neer dat Islandora als hamburger tussen de broodjes “Fedora” (de DAM architectuur, waar de digitale objecten worden bewaard) en “Drupal” (het CMS, die de presentatie van de digitale objecten doet) in zit. Er zijn dan verschillende toppings op de hamburger mogelijk, waaronder Solr (een zoek platform). Aangezien Solr vaak als de kaas van de hamburger wordt afgebeeld en eigenlijk een standaard component is, wordt tegenwoordig ook wel gesproken van de “cheeseburger”.

Islandora kan uitgebreid worden op verschillende manieren, oftewel er zijn verschillende toppings mogelijk. Voor verschillende types content zijn er solution packs beschikbaar, zoals voor plaatjes, boeken, video, pdf, enzovoorts. Maar als je content van een ander type in Islandora wil zetten, dan is dat mogelijk door een eigen solution pack hiervoor te ontwikkelen. Ook kan de functionaliteit uitgebreid worden door een module te installeren of zelf te maken. Het uiterlijk kan helemaal aangepast worden door in Drupal een theme te installeren of zelf te maken.

Islandora is een erg flexibel, modulair, aanpasbaar en uitbreidbaar repositorium en biedt dus veel mogelijkheden om naar eigen wens aan te passen, uit te breiden en te verbeteren. Hiervoor is echter wel veel kennis nodig en die konden we voor een deel opdoen tijdens dit camp.

Er werd ook uitgebreid stilgestaan bij de toekomst; de broodjes (Fedora en Drupal) hebben namelijk allebei een nieuwe versie die nogal verschilt van de versie die de huidige Islandora gebruikt, en daarom wordt er hard gewerkt aan een nieuwe versie van Islandora. Deze nieuwe versie staat bekend onder de naam Islandora CLAW. Deze kan ook niet meer als een hamburger gerepresenteerd worden, aangezien de verschillende onderdelen op een andere manier met elkaar omgaan. Islandora zelf is geen laag meer hierin, maar integreert in elk onderdeel en speelt daarin verschillende rollen. Als er iets gebeurt in een onderdeel (bijvoorbeeld een nieuwe digitaal object wordt ingelezen in Fedora), dan worden andere onderdelen daarvan via events op de hoogte gebracht waarop zij kunnen handelen (bijv. Solr doet indexering). Door deze asynchrone manier van werken lijken acties veel sneller uitgevoerd te worden, omdat er niet meer op gewacht hoeft te worden. Eigenlijk wordt alleen maar gezegd dat een actie uitgevoerd moet worden en het systeem handelt dit dan af op het eerste beschikbare moment.

Ook wordt het onderliggende data model gewijzigd. Aangezien Fedora 4 alle data opslaat als RDF en via Linked Data communiceert, is er hiervoor (dit is dus meer omvattend dan Islandora alleen) een nieuw data model ontwikkeld genaamd het Portland Common data model. Dit is een uitbreidbaar, flexibel domein model dat als basis moet dienen voor veel DAMS.

Een mooie ontwikkeling is het plan is om binnen Islandora CLAW IIIF te gaan ondersteunen. Wanneer dit ontwikkeld wordt en in welke mate, bleef echter nog even onduidelijk, maar er zijn wel concrete plannen voor.

Islandora CLAW wordt op dit moment ontwikkeld. Een eerste minimale versie staat gepland voor eind juni 2017, maar dat is zeker geen versie die al gebruikt kan gaan worden. Dit is absoluut iets om in de gaten te houden, maar niet iets waar we concreet mee aan de slag kunnen op korte termijn.

In de huidige Islandora versie zijn er ook genoeg ontwikkelingen. Hieronder een korte beschrijving van de meest interessante:

Het Oral History Solution Pack maakt het mogelijk om audio en video in Islandora in te laden. Op zich was dit al mogelijk, maar nu kunnen ondertitels en transcript er ook bij ingeladen en afgebeeld worden. Binnen de ondertitels en transcripts kan gezocht worden, zelfs op de naam van de spreker.

May Bragdon Diaries is een Islandora site die de moeite waard is om te bekijken. De site bevat 10 dagboeken die volledig doorzoekbaar en geannoteerd zijn. Via links kan men meer te weten komen over de verschillende personen en objecten, die allemaal bekend staan onder verschillende namen. Sommige bladzijdes bevatten krantenknipsels, foto’s of ansichtkaarten en deze zijn als geheel maar ook los gescand en dus te bekijken. Deze site laat goed de kracht en flexibiliteit van Islandora zien, maar ook dat zoiets veel werk is (een projectteam van 10 personen heeft hier 5 jaar aan gewerkt).

Natuurlijk werden er andere leuke Islandora sites ook getoond; katten, honden, geneeskunde, violen en St. Andrews. Ook werden er veel (nieuwe) Islandora modules getoond, allemaal te vinden via Islandora awesome. Zo is er een EAD solution pack, een Serial solution pack, een Document solution pack (waarmee Office documenten ingeladen kunnen worden), een Binary solution pack (alle bestandstypes maar zonder een manier om die te tonen), een XML solution pack (XML bestanden ingelezen in Islandora kunnen met een XSL transformatie getoond worden) en een Streaming media solution pack (kan MP4 video bestanden die ergens anders zijn opgeslagen via Islandora streamen naar de gebruiker).

Op dag 2 was er een dev track en een admin track. Ik heb de dev track gevolgd, waarin van alles werd besproken en veel vragen beantwoord werden. Zo heb ik weer wat nieuws geleerd over SOLR en XACML die beide belangrijk zijn binnen Islandora. Al deze dingen waren heel leerzaam voor mij, maar helaas niet heel geschikt om in een blog over te schrijven. Wel bleek er iemand bezig te zijn met een IIIF module voor de huidige versie van Islandora. Deze module is nog in ontwikkeling maar is wel interessant om dit te volgen en wellicht hieraan bij te dragen.

Op de derde en laatste dag werden als eerste zoals gebruikelijk de “Islandora Camp awards” uitgereikt. Dit zijn prijzen voor degene die het verst gereisd heeft, die het meest betrokken was bij het camp enzovoorts. Deze prijzen zijn een ludiek en terugkerend thema op de Islandora Camps.

De derde dag was ook de dag van de presentaties. Er werd door een aantal gebruikers van Islandora een presentatie gegeven over hoe zij Islandora gebruikten en/of hadden aangepast aan hun wensen. Een van de mensen was ik. In mijn presentatie heb ik uitgelegd hoe wij de data van onze oude systemen in ons nieuwe Islandora repositorie importeren. Het probleem is namelijk dat de data die geëxporteerd wordt uit deze oude systemen, niet in een formaat staat wat ingelezen kan worden door Islandora. En aangezien we meerdere oude systemen hebben die allemaal meerdere eigen formaten exporteren, is dit een groot probleem. Hiervoor heb ik een module (Prepare Ingest) gebouwd waarmee een workflow gemaakt kan worden waarmee de data van het ene formaat in een formaat wat Islandora in kan lezen, omgezet kan worden. Tijdens de presentatie demonstreerde ik dit met een relatief simpele export van plaatjes die meerdere boeken representeerden. Gelukkig ging dit allemaal goed.

Als de data is omgezet met deze module, kan het ingelezen worden in Islandora. Deze maakt er dan automatisch afgeleiden van. Aangezien dit niet altijd goed gaat en we een mogelijkheid wilden hebben om te controleren of een importeeractie goed was gegaan, heb ik een module (Check datastreams) gemaakt die controleert of alle objecten compleet zijn. Deze module heb ik ook gepresenteerd.

Metadata wordt bij ons in Alma geregistreerd. Natuurlijk willen we deze metadata ook binnen Islandora gebruiken. Ik heb hiervoor een module (Metadata synchronisation) gemaakt die metadata van een OAI-PMH bron kan ophalen en gebruiken binnen Islandora. Ook deze module heb ik op het Islandora Camp gepresenteerd. Mijn volledige presentatie is hier te vinden.

Na mijn presentatie was er nog een presentatie van de man die de meeste lovende woorden over mijn modules had. Hij (Diego Pino Navarro) presenteerde zijn eigen module de Multi Importer. Hiermee kunnen objecten van verschillende types tegelijkertijd ingelezen worden in Islandora. Deze module heeft voor een deel soortgelijke functionaliteit als mijn module Prepare Ingest. We hebben nog hierover gepraat en vonden het allebei een goed idee om meer naar elkaars werk te kijken en wellicht delen van elkaars werk in het eigen werk op te nemen. Dit is dus nog een van de dingen die op mijn to do lijstje staat.

Islandora Camp eindigde met een unconference; oftewel stel alle vragen die je nog hebt en dan proberen we samen een antwoord te vinden. Dat hebben we natuurlijk gedaan en onze vragen werden ook allemaal beantwoord. Dit was echter wel een conferentie waar je vandaan komt met een heel pak huiswerk; ik moet nog veel dingen bekijken, nader uitzoeken en vooral heel veel lezen. Dus ik ga nu maar weer ’s aan mijn huiswerk!

 

 

 

IIIF 2017 Vaticaanstad

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!

 

TPDL 2016

img_1392Begin september 2016 was ik bij het TPDL 2016 in Hannover. Het TPDL is een conferentie betreffende de theorie en praktijk van Digitale bibliotheken. Deze conferentie was tot 2011 bekend onder de naam ECDL (nee, niet het European Computer Driving Licence, maar dat was wel de reden van de naamswijziging) en wordt al bijna 20 jaar gehouden. img_1390
De conferentie werd gehouden in het Hannover Congress Centrum, wat op ongeveer 25 minuten lopen vanaf mijn hotel lag, naast de Hannover ZOO en een groot park.
De conferentie was een mix van keynotes, presentaties van wetenschappelijk onderzoek en workshops (soms hands-on). Hieronder een verslag van een deel van wat ik heb gezien.

De eerste keynote was door David Bainbridge (University of Waikato, Hamilton, New Zealand) met als titel “Mozart’s laptop”, wat mij intrigeerde. Op zich was het onderwerp interessant, namelijk over muziek in de Digitale Library, maar het ging eigenlijk niet over Mozart’s laptop. Ik had verwacht te horen hoe Mozart gebruik zou maken van een laptop als die beschikbaar was in zijn tijd. In plaats daarvan ging het over een systeem (Expediteee) waarin men op een gelijksoortige manier tekst, plaatjes, vector graphics en muziek kon opgeslaan en samenvoegen. Grappig was dat in muziek gezocht kon worden door “query by humming”. Hier werd gebruik gemaakt van audio finger printing. Ook werd Online Dynamic Time Warping (OTW) getoond. Dit is een techniek waarbij de computer de muziek kan volgen die van bijv. een iPad gespeeld wordt. Hiervoor is een soort OCR voor muziekschrift nodig zodat de computer de noten kan lezen en interpreteren, de gespeelde muziek moet geanalyseerd worden en hieruit wordt bepaald welk stuk van de muziek op dat moment wordt gespeeld. Zo kan de computer de bladmuziek op het juiste moment “omslaan”, zodat de musicus dat niet hoeft te doen.
Ook werd er een manier getoond om muziekvideo’s uit te breiden met extra lagen, zoals lyrics, scores, trivia en gitaarakkoorden. Deze lagen konden dan getoond worden terwijl de muziekvideo speelt.

Er was een presentatie waarin het volgende doel werd gesteld: spotify the sciences. Door het delen van verhalen kan meer onderzoek gedaan worden, dus deel de kennis met de wereld. Dat was the bereiken door bibliotheken, archieven en musea te verbinden, data delen makkelijk te maken, primaire data persistent beschikbaar te maken, een corpus moet clickable zijn (eenvoudig downloaden/gebruiken van hele selectie) en collaborative research moet beter ondersteund worden. Allemaal zaken waar iedereen het vast over eens is, maar wat toch lastig te bereiken zijn.

Er was een heel gepassioneerde presentatie van Annika Hinze: The challenge of creating geo-location markup for digital books. Leuk om naar te luisteren omdat de presentatrice duidelijk er heel enthousiast over was. Het ging over Literacy tourism (het boek lezen op de plaats waar het over gaat) en vooral over de problemen die overkomen moeten worden om de data te verkrijgen: welke soort kaart gebruik je? Het detailniveau is niet altijd hetzelfde namelijk en moet passen bij het boek. De hiërarchie in het verhaal is ook belangrijk. Soms gaat het hele verhaal over een bepaalde plek (bijv. een tuin), dit kan je dan aangeven als een gateway. Daarna gaat het verhaal over specifieke plekken binnen die plek (De Chinese tuinen), die je aangeeft als area. Ook kan er beschreven worden hoe je van een plek naar een andere plek loopt (bijv. van de Chinese tuinen naar de waterval), dit wordt aangegeven met een path. Tenslotte kan een specifieke plek worden beschreven (bijv. onder de waterval), dit is dan een point. img_1394
Om dit allemaal goed te kunnen doen moet de markup met de hand gedaan worden. Als een specifieke plek in het verhaal genoemd wordt, gaat vaak de tekst hierna ook nog over die plek of houdt daar verband mee. Omdat het handwerk is, moeten duidelijke instructies worden gegeven aan de personen die het uitvoeren om zoveel mogelijk consistente resultaten te krijgen.
Soms is het gewoon niet duidelijk om welke locatie het gaat (te globaal aangeduid), soms is de locatie niet te vinden, soms wordt er alleen maar gepraat of gedacht over een locatie, en soms zijn het fictionele locaties (platform 9 3/4 uit Harry Potter). De beslissingen die genomen worden hierover tijdens het maken van de markup, moeten dan ook onderbouwd opgeslagen worden.

David Wilcox van DuraSpace hield een workshop over Fedora 4, wat interessant voor ons is aangezien we Fedora 3 gebruiken in onze nieuwe repository infrastructuur en de overstap naar Fedora 4 een kwestie van tijd is. Fedora staat voor Flexible Extensible Durable Object Repository Architecture en is zoals gezegd de basis van onze repository infrastructuur. Het verschil tussen Fedora 3 en 4 is dat de laatste nog meer gebruik maakt van open standaarden, het alles opslaan als een web resource waarvan alle “eigenschappen” (properties zoals metadata) opgeslagen zijn als RDF triples. Hierdoor is Fedora 4 Linked Data Platform compatible. Hiernaast gebruiken ze open standaarden zoals Memento (voor versioning) en WebAccessControl (voor authorization, XACML wordt nog wel ondersteund).
Interessant is dat Fedora 4 echt terug naar de basis gaat; het gaat vooral om het duurzaam bewaren van de objecten en gerelateerde metadata en het heeft een API om objecten en metadata toe te voegen, lezen, wijzigen en verwijderen (CRUD), inclusief transactions en versioning. Alle andere zaken (zoals zoeken en afbeelden van objecten) worden uitbesteed aan andere componenten. Dit lijkt in eerste instantie nogal een mager systeem op te leveren wat eigenlijk niet veel kan. Maar op zich is die focus goed, want wat het wel doet, doet het als de beste. Andere componenten kunnen op een standaard manier gekoppeld worden aan Fedora 4. Ten eerste via de API. Ten tweede wordt bij elke gebeurtenis (event) binnen Fedora 4 een bericht uitgezonden, waarbij ze gebruik maken van de JMS standaard. Hier kunnen andere componenten naar luisteren en actie ondernemen als er een gebeurtenis is die hen interesseert. Ook kan bijvoorbeeld Apache Camel gebruikt worden om te luisteren naar de berichten, waarbij deze SOLR aanstuurt om de indexen bij te werken. Op deze manier is er een krachtige samenwerking mogelijk tussen componenten waarbij elk component doet waarin ie het beste is.
Zowel met Islandora en Hydra wordt nauw samengewerkt zodat deze componenten goed passen binnen Fedora 4.
In de pauze heb ik even met David Wilcox gepraat over Islandora en met name de CLAW. De CLAW is het project om de volgende generatie van Islandora te maken, die samen kan werken met Fedora 4 en Drupal 8. Hij wist niet precies wanneer de CLAW klaar zou zijn, maar wist wel te vertellen dat er een script zou zijn om makkelijk over te gaan naar de nieuwe versie en dat er gewerkt werd om dit nog makkelijker te maken.
Hierna hebben we nog gekeken naar de REST API die Fedora 4 gebruikt. Hier kan je ook zelf mee spelen op https://demo.fcrepo.org:8080/fcrepo/rest. Bedenk wel dat dit een test systeem is dat elke nacht opgeschoond wordt. Met behulp van SPARQL update kunnen de RDF triples gewijzigd worden. Voor meer informatie zie introducing-fedora-4 en hands-on-with-fedora-4.

Een andere interessante presentatie ging over Stylometrie (Jan Rybicki: Pretty Things Done with (Electronic) Texts: Why We Need Full-Text Access). Stylometrie is het tellen van de telbare kenmerken van teksten. Dus bijvoorbeeld het tellen van woorden, maar niet alleen enkele woorden maar ook woordgroepen. Je kan stylometrie gebruiken om teksten met elkaar te vergelijken door de “afstand” (distance) tussen twee of meerdere teksten te bepalen. Hierdoor kan je achterhalen of een tekst door een bepaald persoon is geschreven, of je kan de chronologie in bepaalde werken van een auteur nagaan.
Je kan ook de wijziging van taalgebruik door de jaren heen zien van een bepaald auteur. Ook kan je zien hoe een vertaler invloed heeft op de stijl van het boek. Jan Rybicki is zelf vertaler en drukt tot zijn spijt nogal een stempel op de vertaling; zijn eigen stijl is duidelijk terug te zien.
Met stylometrie heb je veel teksten nodig. Helaas is het moeilijk om (legaal) aan de teksten te komen, vooral als het budget beperkt is. Teksten via OCR zijn niet geschikt vanwege het grote aantal fouten, al zal het verschil niet te zien zijn als tot 20% van de woorden foutief zijn. De presentator is dus erg voorstander van open access van teksten en verwees ook naar het idee van een vorige presentatie: spotify the sciences.

Hieronder nog enkele andere presentaties en workshops die ik nog kort wil noemen omdat ze apart, leuk of interessant waren.
Ten eerste was er een presentatie over een manier om muziek bij een video te suggereren door iemand van de TU Delft: From Water Music to ‘Underwater Music’: Multimedia Soundtrack Retrieval with Social Mass Media Resources (Cynthia C. S. Liem). Het bleek dat het bij een video vooral om het verhaal gaat en minder om het beeld bij de keuze van de muziek. Ze maakte gebruik van IMdb om een soortgelijke film te vinden en daarin stond dan een referentie naar de film muziek die via last.fm werd gevonden.

Een workshop over text mining was ook interessant: Text mining workflows for indexing archives with automatically extracted semantic metadata (Riza Batista-Navarro). Hierbij ging het over een manier om text mining te gebruiken om beter te kunnen zoeken. Als full-text search wordt toegepast kunnen sommige woorden een dubbele betekenis hebben (zoals bank voor geldzaken of om op te zitten) en dingen hebben vaak meerdere woorden die naar hetzelfde ding verwijzen (zoals bank en sofa). Hierdoor is full-text search minder geschikt om het juiste te vinden. Een oplossing hiervoor is om alleen de belangrijke woorden binnen een tekst te herkennen en van betekenis te voorzien: Named Entity Recognition. Er is een aantal benaderingen:
– dictionary-based: hierbij wordt een set van woorden gebruikt om de entities in de tekst te herkennen. Dit heeft als voordeel dat het simpel is en dat woordenlijsten beschikbaar zijn. Het nadeel is dat woordenlijsten groot zijn, maar niet compleet en de entiteiten overlappen elkaar soms.
– rule-based: hierbij wordt gebruik gemaakt van regular expressions. Bijv. woorden die met een hoofdletter beginnen zijn altijd namen of woorden die eindigen op land, weg of straat zijn altijd geografisch van aard. Iets ingewikkelder is contextual matching, waarbij de context van de woorden de betekenis geeft. Bijv. “Jan werkt bij de KLM”, waarbij “werkt bij” de relatie aangeeft tussen de naam van een persoon en een bedrijf. Het voordeel is dat de handmatig opgebouwde regels precies zijn, maar het nadeel is dat het domeinspecifiek is en een dure ontwikkeling.
– machine learning: hierbij is de computer geleerd hoe het entiteiten uit een tekst moet halen. Hierbij kan men onderscheid maken tussen supervised learning, waarbij veel voorbeelden (trainingsdata) nodig zijn, semi-supervised learning, beetje trainingsdata nodig, en unsupervised learning waarbij geen training data nodig is.
Hierna werd nog uitgebreid gesproken over Elasticsearch, een zoekmachine, die net als SOLR gebaseerd is op Lucene.

De conferentie werd afgesloten met een presentatie van Tony Veale: “Metaphors All the Way Down: The many practical uses of figurative language understanding”. Hij had het vooral over metaforen. Bijvoorbeeld over een bibliotheek waarin alle boeken die ooit geschreven zouden kunnen worden. Dus ook een boek wat een normaal boek lijkt, maar waarvan de laatste paar bladzijdes onzin bevatten, waardoor je eigenlijk niks aan het boek hebt. Zo’n bibliotheek, ook al zou die alle mogelijke boeken bevatten, zou niet zinvol zijn omdat je alleen met zekerheid kan zeggen of je het juiste boek hebt, als je het boek ook helemaal leest. Vandaar deze quote: “What makes a good library is not what you put into it, but what you don’t put into it.”
Verder had hij en zijn team onderzoek gedaan naar tweetbots die op basis van de inhoud van Digital Libraries, tweets schrijven op twitter. Daar kwamen soms hele verrassende uitspraken van de tweetbots uit, zoals:
“One does not simply walk hand-in-hand with violence.”
“Suspicions were once nurtured by informed investigators.”
Meer hiervan is te vinden op twitter onder @MetaphorMagnet, @MetaphorMirror@bestofbotworlds en de tweetbot die delen van ebooks tweet @horse_ebooks

De volgende TPDL conferentie is op Thessaloniki in Griekenland van 17 tot 21 september 2017, dus ik hou me zeker aanbevolen.