Archäologie der Handschrift. Erschliessung, Präsentation und Forschungim digitalen Raum

Door Saskia van Bergen

Bijna tweehonderd specialisten bestaande uit wetenschappers, bibliothecarissen en archivarissen verzamelden zich op maandag 9 oktober in Freiburg om drie dagen lang te discussiëren over het ontsluiten, presenteren en onderzoeken van handschriften in de digitale wereld. Tijdens het welkomstwoord benadrukt de organisatie het belang van een dialoog tussen bibliotheek en wetenschap. Gezien alle ontwikkelingen van de laatste jaren, met name de invloed van Handwritten Text Recognition (HTR), Artificial Intelligence (AI) en Reflective Transformation Imaging (RTI) op het onderzoek naar handschriften, is een gezamenlijke strategieontwikkeling hard nodig. Hoe weten we wat de ander nodig heeft, of juist bieden kan? Wat is ons gezamenlijke doel? Op welke vlakken kunnen we daarin samenwerken? Deze vragen komen tijdens de drie dagen telkens weer terug.

Dat blijkt ook uit de opzet. Het programma is verdeeld in thematische sessies, maar we worden na het welkomstwoord niet naar kleine kamertjes gestuurd, waar we worden vermaakt met lange en diepgravende presentaties. Alle papers zijn namelijk plenair en vooral kort. Elk thema begint met korte uiteenzettingen, waarna alle sprekers met elkaar en vooral met het publiek in discussie gaan. Dat heeft als risico dat het snel doodloopt, maar leer dan de Duitsers kennen. Die zijn dol op discussiëren! Op maandag gingen we tot negen uur door, en op dinsdag liep ik ook pas tegen achten (moe gepraat en met een rommelende maag) naar buiten.


Wat is me daarbij vooral opgevallen?

Austausch (uitwisseling) was drie dagen lang het toverwoord. Tussen bibliotheken en wetenschappers, tussen bibliotheken onderling, maar ook tussen portalen. Op dit moment is er eigenlijk nauwelijks sprake is van uitwisseling, zelfs niet op het gebied van metadata. In Nederland zijn we al in de jaren zeventig overgegaan op gezamenlijk catalogiseren in GGC, maar in Duitsland was dit lange tijd alleen per Bundesland georganiseerd. Tegenwoordig zijn er vele initiatieven binnen het Duitse taalgebied, vaak gericht op een internationaal publiek, waaronder generieke sites zoals de virtuele bibliotheek voor Zwitserland e-Codices, het portaal voor Orientaalse manuscript collecties Qalamos, en de Handschriftencensus over alle Duitstalige teksten uit de Middeleeuwen. Maar daarnaast zijn er ook Nationale, en gespecialiseerde catalogi en de initiatieven, zoals die van het Gossembrot project en het Index Librorum Civitatum over Stadsboeken. Een heel landschap aan websites dus. Vooral bij de kleinere projecten is uitwisseling van data ingewikkeld, omdat diepte van ontsluiting, scope, en functies verschillen van de grotere portalen. Maar tegelijk kunnen ze gegevens bevatten die ook voor niet specialisten interessant kunnen zijn. Alleen, welke precies, en hoe kom je hier achter?


Zou een meta-database niet prachtig zijn? Eén portaal waarin je alles kunt vinden? Met IIIF is toch alles mogelijk? Zo kom ik er al snel achter dat ook de Duitser worstelen met de belemmeringen van projectfinanciering. Je krijgt geld van NWO of DFG en zet een mooie website op, stopt tijd en energie in het vullen ervan, maar er is niet altijd nagedacht over wat er met de data gebeurt na afloop van het project. Andersom zijn weinig geldschieters bereid om langdurig geld te stoppen in iets saais als het onderhouden van een IIIF based portaal, of de interoperabiliteit tussen sites. Dit maakt dat er sneller financiering wordt gevraagd én gegeven aan kortdurende projecten.

Standardisiering schafft nachaltigkeit (Standaardisatie zorgt voor duurzaamheid) Ook deze stelling kwam regelmatig terug. Daar kan ik het alleen maar mee eens zijn, maar dat neemt tegelijk niet weg dat we ook oog moeten hebben voor maatwerk. Door internationale thesauri en standaarden te gebruiken kunnen we altijd een basisset aan metadata aanleveren aan grote portalen, of data uitwisselen met gespecialiseerde themasites, maar tegelijk moet er binnen de eigen systemen ruimte zijn voor gespecialiseerde informatie, zoals gegevens over band, schrift en decoratie. Claudia Fabian, het hoofd van de afdeling Handschriften en oude Drukken van de Bayerische Staatsbibliothek in München pleit daarom voor modularisering: Welke informatie is in welke context nodig? Idealiter richt je je infrastructuur zo in dat je informatie over dezelfde manuscripten aan uiteenlopende portalen kunt aanleveren, elk met een eigen scope.

Dit alles doet vermoeden dat wij wel wat voorlopen op onze oosterburen. De DFG (De Duitse NWO) mag in elk geval nog wel wat meer de regie pakken in het afdwingen van interoperabiliteit bij het toekennen van subsidies. Je realiseert je tegelijk ook dat we in Nederland best verwend zijn met nationale initiatieven die deze uitwisseling juist als doel hebben, zoals het Netwerk Digitaal Erfgoed en waar je terecht kunt voor hulp en ondersteuning. En Stichting PICA heeft een programmalijn opgezet voor het verbinden van erfgoedsites waarin we als UBL ook participeren.

Maar voordat we onszelf op de borst kloppen: wij kunnen ook nog wel een en ander leren van onze Duitstalige buurlanden. Dat blijkt vooral op de laatste dag waar aandacht wordt besteed aan innovatieve onderzoeksmethoden, zoals AI, HTR en RTI. De transcriptie software Transkribus is een van de meest gebruikte hulpmiddelen hiervoor, en is ontwikkeld onder leiding van de universiteit van Innsbruck. Er werden enkele spectaculaire voorbeelden getoond van de resultaten met automatische transcripties, niet alleen van westers schrift, maar ook van Cyrillisch, Hettitisch en diverse Aziatische schriftsoorten. De AI techniek wordt hierbij ingezet om een voorspelling te doen van welk woord op specifiek deze plek in de zin wordt verwacht, en dit komt de kwaliteit van de transcriptie ten goede. Dit is enorm belangrijk voor de toekomst van het vak: omdat er steeds minder ruimte is voor onderwijs in oud schrift kunnen steeds minder mensen het lezen. Vorige week stond er nog een interessant nieuwbericht op de universitaire website over het leesbaar maken van de tekst op kleitabletten.

In Hamburg bevindt zich het Centre for the Study of Manuscript Cultures (CSMC), waar wordt gewerkt aan innovatieve methodes voor de studie van handschriften. Samen met de universiteit van Rochester vormen ze de voorhoede voor de ontwikkeling van fotografische technieken voor erfgoed. Ze maken onder meer gebruik van RTI, een techniek waarmee onderdelen van handgeschreven zichtbaar kunnen worden gemaakt die dat met het blote oog niet zijn. In deze video wordt uitgelegd wat hiermee allemaal mogelijk is.

Dit riep bij mij de vraag op over de rol van de bibliotheek. Want is het wel onze taak om deze technieken aan te bieden binnen de bibliotheek? En moet dit dan zijn in de rol van actieve partner binnen een onderzoekproject? Of moet het zelfs als standaard dienstverlening worden aangeboden? In sommige bibliotheken zoals Edinburgh UL wordt dit al gedaan. Katharina Kaska van de Österreichische Nationalbibliothek maakten al snel duidelijk dat de aanschaf van apparatuur niet genoeg is. Het maken van een foto is namelijk slechts één stap in het proces. Wanneer je niet over geschikt personeel beschikt om de afbeeldingen na te bewerken en te interpreteren kun je er beter helemaal niet aan beginnen. Betekent dit dat wij alleen toeleveranciers zijn van bronmateriaal? Dat is misschien ook weer al te negatief. Na afloop van de sessie werd ik aangesproken door een medewerker van de UB in Göttingen. Daar hebben ze gekozen voor camera-apparatuur die in staat is om eenvoudige RTI uit te voeren. Dus niet het high end materiaal, maar ook geen scanner die alleen platte scans maakt. Ik was van harte welkom om eens te komen kijken. Dat was ook het belangrijkste advies van de Damianos Kasotakis van de Early Manuscripts Electronic Library: If you can, avoid “ONE BUTTON – TURN KEY” systems! Met andere woorden: koop geen scanner maar investeer in apparatuur waarmee je flexibel bent en kunt inspelen op technologische ontwikkelingen.

De eerdergenoemde ‘Austausch’ is ook van toepassing op de uitwisseling van kennis en met name van technische expertise. Een goed voorbeeld van innovatieve samenwerking is het competentiecentrum voor OCR en HTR dat de universiteitsbibliotheken van Tübingen en Mannheim hebben opgezet en dat zeer actief is in de ondersteuning van onderwijs en onderzoek in de regio. Het competentiecentrum is dus niet ondergebracht bij de universiteit, maar bij de UB. Ook bij ons zou het geen slecht idee zijn om binnen het UKB of Leiden-Delft-Erasmus de kennis die al bij de diverse universiteitsbibliotheken aanwezig is, bijvoorbeeld binnen een Centre for Digital Scholarship, te bundelen.

En voor iedereen die zich zorgen maakt dat ik drie dagen lang geen daglicht heb gezien: gelukkig was ik al in het weekend in Freiburg aangekomen en heb ik uitgebreid kunnen genieten van zonnig weer, volle terrassen en natuurlijk ook de onvermijdelijke Biergarten 🙂

Peoplemens

We zaten het restaurant van een sauna en luisterden het gesprek van onze buren af. Niet luisteren was overigens geen optie, want ze spraken nogal hard. Het waren twee in keurige badjassen gestoken jongeheren. Ze hadden het over hun werk, maar eigenlijk wilden ze vooral de ander ervan overtuigen hoe interessant ze waren. De zinnen waren doorspekt met Engelse woorden en uitdrukkingen. Dat is op zich niet bijzonder bij snelle jongens, maar toch was er iets vreemds aan. Ik begreep het ineens toen de ene jongeman zei: ‘Ja, maar Dick is een echt peoplemens.’

Begrijp me goed, ik ben echt niet tegen het gebruik van Engels in het Nederlands. Ik zeg gewoon camping in plaats van kampeerterrein, en ik wil zelfs nog wel eens mensen shamen (bijvoorbeeld deze twee heren). Woorden uit andere talen komen al sinds mensenheugenis onze taal binnen, en zelfs de meest radicale taalpuriteinen zeggen ok en bureau. Sommige vreemde woorden schoppen het tot de Van Dale, andere verdwijnen via de achterdeur, maar wat hier gebeurde is dat on the spot nieuwe woorden werden gemaakt gewoon for the sake of interessantdoenerij. Je zou kunnen denken dat het schattige nieuwlichterij is, maar niets is minder waar: het is pure taalanarchie. Want als peoplemens kan, dan is mensenperson ook goed.

Via de Facebookpagina Onnodig Engels taalgebruik zag ik dat deze ontwikkeling al een tijdje gaande is. Wat dacht je van peanutbuttereitjes, herfstfeeling en travelhanddoek. Stuk voor stuk lelijke en onnodige samenstellingen waar moeiteloos een Nederlands alternatief voor te vinden is. Deze ontwikkeling kan leiden tot een tsunami aan nieuwe woorden. Als appeltaartcookie mag, en ze werden vier jaar geleden al verkocht, dan kun je wachten op applepiekoekje, appeltaartcookje, appeltaartkoekie, appelpiekoekje, appelpiecookje, appelpiekoekie, appletaartcookie, appletaartcookje, appletaartkoekie, applepiecookje en applepiekoekie – om maar eens wat te noemen. En dan laat ik maar buiten beschouwing dat het ook nog eens ging om oma’s appeltaartcookie. Lunchafspraak en winkelmanager kunnen weer wel, want hier is het Engelse deel volledig geaccepteerd in het Nederlands. Maar voor alle andere hierboven genoemde combinaties is maar een kwalificatie mogelijk: cockkoek.

Eerder verschenen in IP – vakblad voor informatieprofessionals 8/2022

Overlijdensbeleid

Door Rob Feenstra

Wmpearl, CC0, via Wikimedia Commons

Ik geef het toe, overlijdensbeleid is geen vrolijk stemmend woord. Ik kwam het tegen bij het lezen van een artikel in het Nederlands Juristenblad over de status van digitale data na het overlijden van de eigenaar. Er zijn op dat gebied veel vragen en onduidelijkheden. Wie ‘erft’ die data, of anders gezegd, wie moet er toegang toe krijgen? Moet de eigenaar daar bij leven expliciet iets over vastleggen of hebben nabestaanden er zonder meer recht op? Wat gebeurt er met je accounts wanneer je overlijdt? 

Wie antwoord wil krijgen op dit soort vragen, belandt al snel in een wirwar aan gebruiksvoorwaarden en juridische regels, die per land vaak ook nog verschillen. Er zijn allerlei oorzaken voor aan te wijzen, maar het heeft ook zeker te maken met een vrij algemeen gevoel van tegenzin om ons hiermee bezig te houden. Je kent misschien de onaangename ervaring wanneer je op Facebook ziet dat een overleden vriend wordt gefeliciteerd met zijn verjaardag, soms vergezeld van een pijnlijke toevoeging als ‘tijd niet gezien’ of ‘we moeten weer eens afspreken’. Zoiets wil je je nabestaanden toch niet aandoen? Je kunt heel eenvoudig instellen dat je account na je dood wordt verwijderd of dat het een herdenkingsstatus krijgt. Toch heb ik het niet gedaan, en een kleine rondgang langs een aantal familieleden en collega’s leerde me dat ik lang niet de enige ben. 

En wat moet er bijvoorbeeld met je mailbox gebeuren als je er niet meer bent? Het is misschien een vervelend idee dat al die content voor eeuwig ongelezen blijft, maar het is ook heel goed mogelijk dat je het onprettig vindt wanneer nabestaanden in je privémail struinen. Alles is eenvoudig te regelen, bijvoorbeeld via een notaris of, nog veel eenvoudiger, via tal van digitale diensten (ik vond er een met het lugubere lokkertje ‘probeer 30 dagen GRATIS’). Toch doen maar weinig mensen het.

Er is, kortom, niet alleen voor wetgevers en grote bedrijven nog werk aan de winkel op het gebied van overlijdensbeleid, maar ook voor ieder van ons.


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

Deze bijdrage komt uit de papieren IP #4-2022.

#BoekTok

Ik weet dat TikTok bestaat en ook wat je er zo ongeveer mee kunt doen, maar dat was het wel zo’n beetje, want niet alleen ik maar ook mijn kinderen zijn er eigenlijk te oud voor. Tot ik links en rechts hoorde over het succes van #BookTok en de Nederlandse versie #BoekTok. Via deze hashtags vind je op TikTok filmpjes van jongeren, en van Kluun, die elkaar boeken en schrijvers aanraden. Meestal gaat het daarbij om young adult-boeken, maar ik heb toch ook een meisje met roze haar voorbij zien komen dat Hersenschimmen van Bernlef aanprees.

In eerste instantie dacht ik dat het ging om het zoveelste geval van door de media opgeklopte gebakken internetlucht, maar navraag bij een paar boekenwinkels leerde me dat de boeken nauwelijks aan te slepen zijn wanneer ze via #BoekTok goed besproken zijn. We somberen, terecht, vaak over ontlezing, maar is het ooit gebeurd dat jongeren op zo’n grote schaal boeken kochten?

Verwacht bij #BoekTok overigens geen uitgebreide besprekingen. De filmpjes zijn maar kort en soms zie je alleen de kaft anderhalve seconde in beeld, maar het mooie van #BoekTok is dat het een platform voor en door jongeren is (al zijn de eerste leraren Nederlands, uitgeverijmedewerkers en Kluun dus, ook al gesignaleerd).

Deze column komt uit IP #7/2021

Fieldlabber

Fieldlabber. Spreek het woord hardop 5 keer achter elkaar uit en ga eens na op welke manier het zich in je hoofd nestelt. In mijn geval werd de ‘a’ gevoelsmatig een ‘e’. Dat heeft te maken met de betekenis van fieldlabber: iemand die meedoet aan een fieldlab-evenement. Bij een aantal van die evenementen namen de fieldlabbers flink wat drank tot zich. Associatief dacht ik aarbij aan fieldlebberen, een nog niet bestaand woord dat zeker een kans verdient. Fieldlabber bestaat pas een paar maanden en toch heeft het opmerkelijk genoeg al meerdere betekenissen. Een fieldlabber kan namelijk ook de organisator van een fieldlab zijn.

Voor fieldlab bestaat een goede Nederlandse vertaling, namelijk proeftuin. Daarop voortbordurend zou je een fieldlabber een proeftuinier kunnen noemen. Maar eigenlijk is een vertaling helemaal niet nodig, want ondanks de Engelse klank komt fieldlabber alleen voor in het Nederlands en vrijwel steeds in verband met corona-gerelateerde experimenten. Het past in een rijtje Engels klinkende uitdrukkingen die alleen in het Nederlands bestaan, zoals reality soap, non-food en touringcar.

Ook wanneer je op fieldlab zoekt, kom je vooral Nederlandse websites tegen. Dat komt door de typisch Nederlandse gewoonte om woorden aan elkaar te plakken. Op Google Trends is te zien dat in de rest van de wereld vrijwel iedereen field lab schrijft (zie afbeelding). De uithaal naar boven aan het einde van de grafiek is dan ook volledig te danken aan Nederlandse webpagina’s.

Ik zocht op de website van de rijksoverheid naar een goede omschrijving van fieldlab en vond dat er in ieder geval een duidelijk onderscheid is tussen fieldlabs en pilots voor testevenementen. Toen ik vervolgens keek wat de overheid beschouwt als een pilot voor een testevenement zag ik dat dat daar fieldlab-evenementen toe gerekend worden. De overheid is er dus nog niet helemaal over uit.

Het is hoe dan ook te hopen dat iedereen binnenkort gevaccineerd is en dat de lelijke fieldlab-samenstellingen (ook het werkwoord fieldlabben is al gesignaleerd)  net zo snel uit het Nederlands verdwijnen als ze gekomen zijn.

Eerder verschenen in IP #5/2021

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.

Doembladeren

Uitgelicht

Deze column verscheen eerder in de rubriek IP Lingo van het blad IP

In mijn pogingen om deze rubriek zo actueel mogelijk te laten zijn, introduceer ik deze maand een woord dat tot vandaag nog niet bestond. Ok, ik geef toe dat doembladeren een letterlijke vertaling is van het Engelse doomscrolling, maar ook dat woord staat nog in de kinderschoenen.

Iedereen kent het wel: je hebt een raar kuchje, je gaat zoeken op internet en een half uur later ben je ervan overtuigd dat je aan het begin staat van een pijnlijk en slepend ziekbed met fatale afloop. Doembladeren is het langdurig tot je nemen van slecht nieuws via sociale media, zodanig dat het een negatieve invloed heeft op je gemoedstoestand. Of, zoals ik ergens las, “obsessively reading social media posts about how utterly fucked we are”. Langdurig van bericht naar bericht surfen is natuurlijk niets nieuws en zolang het gaat over de laatste ontwikkelingen rond Wie is de Mol of het liefdeleven van Marco Borsato is er weinig aan de hand.  Maar wanneer we berichten met een negatieve inhoud tot ons nemen (waarbij ik ervan uitga dat u de amoureuze strapatsen van Marco Borsato niet als zodanig beoordeelt), treedt er een mechanisme in werking dat te vergelijken is met het  mean world syndrome. Dit is het fenomeen dat mensen door het veelvuldig kijken naar gewelddadige televisie-uitzendingen de wereld als gevaarlijker beoordelen dan hij in werkelijkheid is. Door langdurig berichten te lezen over de coronacrisis, het meest gegoogelde woord van 2020, krijgen de doembladeraars zoveel slecht nieuws te zien dat er in hun belevingswereld nauwelijks plaats meer is voor iets anders.

De oplossingen zijn even talrijk als eenvoudig: een timer op je smartphone zetten of een leuk boek lezen bijvoorbeeld. Maar de meest efficiënte oplossing is de app Mind Leak. Wanneer je te lang bezig bent op een sociaal medium, toont de app op het beeldscherm je eigen starende gezicht. Ik heb het voor u geprobeerd: dat nooit meer.

Eerder verschenen in IP2021-1

Fleet

Onderstaande column verscheen eerder in de rubriek IP Lingo van het blad IP.

Deze rubriek gaat over nieuwe woorden en begrippen in de informatiewereld. Tussen het moment van schrijven en de publicatiedatum zitten een paar weken. Dat is in onze snelle wereld een hele tijd.  Een begrip kan in die periode oud nieuws geworden zijn, of een algemeen ingeburgerd begrip. Of dat ook opgaat voor fleet is voor mij een vraag en voor u als lezer een weet. Toen ik vanochtend (half november) een rondje maakte langs een aantal bekenden kon niemand me in ieder geval vertellen wat fleets zijn. Ze bestaan op het moment dat ik dit schrijf dan ook nog niet in Nederland. Het is aan u om te zien hoe snel een ontwikkeling kan gaan (of niet).

Natuurlijk bestaat het woord fleet al wel. Er zijn een paar plaatsen in Engeland met de naam Fleet. Het betekent vloot in het Engels en is tevens de naam van een Belgische keten van autodealers, een Australisch motorfietsmerk én een firma die handelt in klysma’s. De Urban Dictionary spreekt bij fleet dan ook van ‘a term to describe when someone is cleaning out their ass/vagina’.

Maar de fleet die ik bedoel is de nieuwste  functie van Twitter. Het gaat om een bericht dat na 24 uur automatisch verdwijnt. Hiermee sluit Twitter aan bij een richting die bedrijven als Snapchat, Instagram en Facebook al veel eerder insloegen. “Omdat ze na een dag verdwijnen, helpen fleets de mensen om zich niet geremd te voelen om hun persoonlijke en terloopse gedachten, meningen en gevoelens te delen”, blogden Joshua Harris en Sam Haveson, respectievelijk design director en product manager bij Twitter.  Mijn optimistische ik is blij omdat een hoop vuilspuiterij daarmee automatisch verdwijnt, maar aan de andere kant kan het betekenen dat reaguurders en andere gekkies zich bevrijd voelen van hun laatste remmingen en helemaal los gaan. Wie zal het zeggen? U misschien/niet/waarschijnlijk/uiteraard?

Eerder verschenen in IP #9/2020

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.