Omeka-S en de wondere wereld van Linked Data

Ter aanvulling op mijn posts over Omeka-S en IIIFZie: https://cannedit.org/projects/code-tinkering, bedacht ik onlangs een nieuw projectje: zou het niet mooi zijn om de wrijfsels van boekband stempels, die ik zo'n 40 jaar geleden verzamelde in het kader van mijn onderzoek naar boekbanden in de Librije van de Walburgiskerk in Zutphen, online te zetten via een Omeka-S website met IIIF functionaliteit?

Echt: hoe moeilijk kan dat zijn: alle data daarvoor staat op deze website in mijn artikel over de boekbanden van de LibrijeZie: https://cannedit.org/projects/bookbindings/boekbanden-uit-de-librije-te-zutphen, dit shared hosting account staat het toe om een Omeka-S website in te richten en Omeka-S heeft modules om IIIF te ondersteunen. Mooie bijvangst zou dan zijn dat te zijner tijd alle data ook als linked data kunnen worden aangeboden, immers: Omeka-S slaat data op met behulp van ontologiën. Een ontologie is een gestructureerde manier om begrippen, eigenschappen en relaties binnen een bepaald domein te definiëren, het is het woordenboek én de grammatica voor je data en als zodanig een fundament voor linked data. Het gebruik van een ontologie heeft als resultaat: geen losse lijst met feiten, maar een netwerk van betekenisvol verbonden informatie.

Standaard heeft Omeka-S al een aantal ontologiën aan boord - in Omeka-S ook wel "vocabularies" genoemd - namelijk: Bibliographic Ontology, Dublin Core en Friend of a Friend. Als je vervolgens de extra module "LinkedDataSets" aan de Omeka-S installatie toevoegt, die je in staat stelt om je data als linked dataset te publiceren, komt daar ook nog eens het uitgebreide Schema.org bij. In totaal heb je dan in Omeka-S de beschikking over 998 "classes"Een "class" is een categorie of een type object, bijvoorbeeld: een boekband, een boekband stempel, een persoon of een plaats en deze kunnen algemeen of specifiek zijn in een soort hierarchische verhouding, bijvoorbeeld: een boekband behoort tot de algemene categorie "door een mens gemaakt objecten" en een boekband stempel behoort tot de algemene categorie "gereedschap". en 1636 "properties"Een "property" beschrijft een kenmerk van een type object en hoe objecten zich tot elkaar verhouden en daarbij kunnen twee typen "properties" worden onderscheiden: "datatype properties" (attributen), eigenschappen die een waarde toekennen aan een "class", zoals: een datum, een tekst of term, een getal, en "object properties" (relaties), eigenschappen die een link leggen tussen twee "classes", zoals: een boekband is gemaakt door een persoon, in een bepaalde (werk)plaats, met behulp van bepaald materiaal (leer, perkament, boekband stempels, etc.)., dus je zou denken dat dit wel een goede basis is om je "Resource Templates" - een soort invulformulieren voor data invoer per "item" in Omeka-S - in te richten.

Nou, op het eerste gezicht is dat ook zo, in ieder geval voor het beschrijven van personen, zoals bijvoorbeeld: auteurs, boekbinders, drukkers, etc., maar ook voor algemene beschrijvingen van objecten, zoals bijvoorbeeld: boeken, handschriften, etc., maar als je voor speciale objecten, zoals boekbanden of boekband stempels, hele specifieke aspecten zou willen beschrijven, dan heb je aan bovengenoemde ontologiën niet genoeg. Natuurlijk zou je bepaalde "properties" daarvan 'oneigenlijk' kunnen gebruiken, maar dat is zondigen tegen het linked data principe dat data betekenisvol moet zijn (voor mens en machine) om zo verbanden te kunnen leggen tussen verschillende datasets wereldwijd.

Gelukkig kun je aan Omeka-S gewoon ontologiën toevoegen en dus is het zaak op zoek te gaan naar een geschikte ontologie en een goed startpunt is dan: Linked Open Vocabularies. Maar na enig zoekwerk daar en elders is helaas de conclusie dat er voor het specifieke "domein" boekbandbeschrijvingen nog geen allesomvattende ontologie bestaat. Zelfs de zeer uitgebreide en algemene ontologie voor het cultureel erfgoed domein, CIDOC-CRM, overlapt maar voor een deel met de terminologie in gebruik voor het beschrijven van boekbanden. Natuurlijk kun je Omeka-S "Resource Templates" opbouwen bestaande uit onderdelen van verschillende ontologiën, dat is zelfs aan te bevelen, want dat is de kracht van linked data: hergebruik zoveel mogelijk elementen van ontologiën die vaak worden gebruikt, want dat verhoogt de mogelijkheid om een dataset te verbinden met andere datasets, maar als je onderdelen van een heel specifiek - welhaast niche - domein tot in detail gaat beschrijven, dan ontkom je er niet aan om daarvoor een nieuwe ontologie te ontwikkelen, al was het maar voor datgene wat daarvoor 'ontbreekt' in de bestaande ontologiën. En precies daarvoor kun je in Omeka-S een extra module installeren, genaamd: "Custom Ontology", die je op een eenvoudige wijze in staat stelt om de benodigde "classes" en "properties" te uploaden. Daar ben ik nu aan begonnen: het ontwikkelen van een specifieke ontologie voor het beschrijven van boekbanden, losjes gebaseerd op de publicaties over de terminologie te gebruiken bij het beschrijven van boekbanden van het Belgisch-Nederlands Boekbandengenootschap.Zie: https://boekbandengenootschap.nl/publicaties-van-het-boekbandengenootschap/.

Het definiëren van de ontologie is één ding, het 'vertalen' daarvan naar werkbare Resource Templates is een volgende uitdaging. Niet zo zeer als het gaat om het basale recht-toe recht-aan inrichten van zo'n formulier voor data input in Omeka-S, maar wel om dit met het oog op het einddoel - een linked data conforme dataset - zo semantisch zuiver mogelijk te houden. Dan loop je namelijk tegen wat beperkingen aan. Zo is het in Omeka-S bijvoorbeeld niet mogelijk om properties meer dan één keer te gebruiken in een Resource Template en dat is niet handig voor het bouwen aan een netwerk van "items" die op vele manieren met elkaar verbonden zijn. Dan wil je bijvoorbeeld properties als "dcterms:isPartOf" of "dcterms:hasPart" meer dan eens kunnen gebruiken binnen één Resource Template, zoals die voor een boekband. Een ander "dingetje" is dat je het gebruik van complexe waarden voor een property niet kunt definiëren in Omeka-S. Soms heeft een property namelijk zelf ook weer eigenschappen nodig. Een klassiek voorbeeld is "dcterms:date" toepassen met een kwalificatie zoals "start" en "end", of een waarde met een bepaalde nauwkeurigheid "(circa)". Maar toch zijn deze beperkingen niet per se tekortkomingen te noemen en voor sommigen kun je zelfs 'workarounds' verzinnen die een linked data purist toch geen nachtmerries bezorgt. Sterker nog: de beperkingen dwingen je tot nadenken over wat essentieel is in je datamodel en door de noodzaak om keuzes te maken, scherp je je ontologie gebruik aan.

Mijn conclusie voor nu: Omeka-S is niet hét ultieme linked data platform, maar het is wél een uitzonderlijk effectieve variant op traditionele collectie registratie en zeker een goede introductie in de wereld van het modelleren van datasets ten behoeve van het toevoegen daarvan aan het semantische web. Voor diegenen die willen beginnen met linked data zonder direct te investeren in complexe technische infrastructuren, is Omeka-S een van de meest praktische opties. Je kunt daarin je data al heel rijk structureren, met in je achterhoofd dat uitbreiding daarvan later, via een export en gebruik van gespecialiseerdere tools, altijd nog mogelijk is. Ik ga er in ieder geval verder mee experimenteren, want soms is een goed werkend compromis waardevoller dan een technisch perfect maar mogelijk onhaalbaar ideaal.