Publicatie:Publicatie van collectiedata van het Vlaams Architectuurinstituut op Wikidata
Gevalstudie over het traject dat het Vlaams Architectuurinstituut doorliep om metadata over archieven en objecten in het archiefbeheersysteem op te laden naar Wikidata. De gevalstudie bespreekt de basisbeginselen van Wikidata en het semantisch web, de creatie van persistente URI's voor archieven en objecten en de methodes die werden toegepast om de gegevens naar Wikidata op te laden. We gaan eveneens kort in op het opladen van rechtenvrije beelden in Wikimedia Commons en sluiten af met een evaluatie van het gebruik van Wikidata als aggregatieplatform voor erfgoedinstellingen.
| Titel | Publicatie van collectiedata van het Vlaams Architectuurinstituut op Wikidata (Voorkeurstitel) VAi collectiedata op Wikidata (Afkorting) |
| Locatie | |
| Uitgever | [www.vai.be Vlaams Architectuurinstituut]
|
| Jaar van uitgave | 2021 |
| Rechten | CC-BY-SA |
| Persistent ID |
Het Vlaams Architectuurinstituut doorliep in 2019 en 2020 het project Persistente architectuur. Met dit project onderzocht het Vlaams Architectuurinstituut (VAi) hoe het zijn collecties op zo'n effectieve en open mogelijke manier kon ontsluiten, met als testcase de collectiestukken uit het archief van Engetrim en de verzameling van Jos De Beer.
Persistente architectuur bestond uit drie werkpakketten:
- De registratie van historische collecties van het Vlaams Architectuurinstituut op stukniveau, op basis van museale standaarden.
- De publicatie van de beschrijvingen op het web, voorzien van persistente identificatie.
- Het delen van de data in vier use cases.
De vier use cases van werkpakket 3 waren:
- Persistente URL’s delen via de Inventaris Onroerend Erfgoed.
- Collectiedata delen op Wikidata en beelden op Wikimedia Commons.
- Collectiedata en -beelden delen met Zenodo.
- Het uittesten van persistente URI’s in combinatie met het Resource Space DAM van MOMU.
In deze gevalstudie gaan we nader in op use case 2, die we tijdens het project ook het meest hebben uitgewerkt: Het delen van collectiedata op Wikidata.
Wikidata en Wikimedia Commons
Wikimedia Commons is het beeldbankproject van de Wikimedia Foundation, die is geïntegreerd met Wikimedia’s andere platformen, zoals Wikipedia en Wikidata.
Wikidata is de databank van de Wikimedia Foundation. Wikidata ondersteunt de verschillende Wikimediaprojecten. Eén van de toepassingen is bv. beheer van links tussen artikels in verschillende taalversies van Wikipedia over eenzelfde onderwerp. De toepassing van Wikidata gaat echter verder dan het ondersteunen van Wikimedia Platformen alleen. Het fungeert eveneens als een platform waar iedereen gegevens kan publiceren als linked open data. Het is niet bedoeld als een platform waar je de originele data in opslaat. Wikidata wil vooral gegevens samenbrengen die in andere databanken zijn gepubliceerd. Door het opnemen van referenties naar de originele data kan de bron steeds worden gecontroleerd.
Zoals alle Wikimediaplatformen hebben deze systemen enkele eigenschappen gemeen:
- Alles is gepubliceerd: Er kunnen geen gegevens of beelden ‘afgeschermd’ worden opgeladen
- Alles kan door iedereen worden gewijzigd: Beelden en gegevens zijn van de Wikimediagemeenschap
- Alles is transparant: De meest geringe wijziging wordt geregistreerd in een log en kan opnieuw ongedaan worden gemaakt
- Alles is vrij herbruikbaar: Er rusten geen auteursrechten op gegevens in Wikidata. Beelden op Wikimedia Commons behoren ofwel tot het publieke domein of wanneer er auteursrechten op rusten is vrij hergebruik toegestaan via een Creative Commons-licentie of een CC0 Public Domain Declaration.
- Alles heeft een open architectuur: Gegevens en beelden kunnen automatisch met applicaties worden aangesproken en hergebruikt.
Waarom een use case met Wikidata?
Waarom zou je als erfgoedinstelling überhaupt tijd steken in het publiceren van je collectie-informatie op Wikidata, een databank die niet specifiek gericht is op architectuur, archief of erfgoed en die vooral wordt opgebouwd en onderhouden door vrijwilligers? Deze vrijwilligers zijn bovendien anoniem en hoeven geen kwalificatie voor te leggen om data in Wikidata te bewerken. Toch beschikt Wikidata over een aantal eigenschappen die maakten dat we Wikidata toch een test waard vonden.
query.wikidata.org
Een belangrijke kracht van Wikidata is de query-interface, waarmee je via zoekopdrachten (queries) alle data in het systeem op kunt opvragen, op heel flexibele wijze, afhankelijk van wat je nodig hebt. Een spreadsheet van alle objecten in de collectie? Een overzicht van alle architecten die een tekening in jouw collectie hebben gemaakt? Een kaartweergave met de geboorteplaatsen van de architecten? Foto’s van gebouwen die met jouw collectie zijn gelinkt, in een straal van 1 km rond Brussel? Met query.wikidata.org kan het allemaal.
Dit is niet alleen interessant ter ondersteuning van het collectiebeheerder, het laat onderzoekers die geïnteresseerd zijn in datasets toe om de data op te vragen in de wijze zoals ze willen om deze vervolgens op te laden in hun analysesystemen, zoals SPSS of Nodegoat.
Tijdens de use case wilden wij onderzoeken wat voor het VAi de mogelijkheden waren van deze query-interface.
Integratie met andere informatie
Veel succesverhalen van het digitaal tijdperk (Google, Spotify, Airbnb etc.) hebben een belangrijke eigenschap gemeen: ze proberen alles aan te bieden. Alle webpagina’s, alle muziek, alle hotelkamers... Een doorsnee digitale gebruiker wil geen twintig sites afschuimen, hij/zij wil meteen op één platform zoveel mogelijk alles kunnen terugvinden. Vandaar het belang om de pagina’s van jouw website doorzoekbaar te maken door Google, de geïntegreerde portal van het internet bij uitstek.
Google biedt echter geen zoekinterface op gestructureerde data zoals Wikidata dat doet. Anders gesteld, Google focust op intuïtieve zoekopdrachten met tekststrings, maar laat niet toe om het web te bevragen als een database.
Bijvoorbeeld: Als je op zoek wilt gaan naar schilderijen die het verhaal van Artemis en Aktaion uitbeelden, dan wil je liever niet de catalogi van alle musea in de wereld opzoeken. Meestal zul je een Google Image Search doen en van daaruit verder zoeken, maar tegenwoordig kun je ook een query doen in Wikidata voor een gestructureerd overzicht: https://w.wiki/bh8
Wanneer het gaat om gestructureerde data én om een zo groot mogelijke set aan gestructureerde data, lijkt Wikidata op dit moment het platform dat hiervoor over de meeste troeven beschikt. Je kunt er niet alleen erfgoedcollecties in ontsluiten, maar eender wat. Bij wijze van voorbeeld, omdat het kan, een selectie van 500 artikels uit een wetenschappelijk tijdschrift ‘ACS Applied Materials and Interfaces’: https://w.wiki/vnr
Op termijn zijn op die manier in theorie integraties mogelijk tussen alle mogelijke domeinen, bv. alle wetenschappelijke artikels die schilderijen van ‘Artemis en Aktaion’ als onderwerp hebben.
Wereldwijd samenwerken en meertaligheid
Omdat iedereen in Wikidata kan werken hoef je niet alles zelf te doen. Termenlijsten worden wereldwijd samen opgebouwd, net als persoonsgegevens die kunnen helpen om collectiestukken te ontsluiten. Een ander belangrijk aspect hierbij is de rol die Wikidata speelt als verzamelaar van authority records. Het Wikidata-item over Léon Stynen heeft bijvoorbeeld een indrukwekkende oplijsting van externe koppelingen naar meer informatie. Je hoeft zelf deze koppelingen niet te leggen. In Wikidata gebeurt dit werk voor een groot deel voor jou, of kun je dit samen doen met vele anderen.
Je hoeft tot slot ook zelf geen vertalingen te voorzien van je data. Daar houden vrijwilligers van andere taalgemeenschappen zich mee bezig.
Geconnecteerd met Wikipedia en de Wikimedia Foundation
Wikidata is geen geïsoleerd project. De databank is geïntegreerd met Wikipedia en andere platformen van de Wikimedia Foundation. Het gebruik van data in Wikidata in Wikipedia-artikels – voor veel mensen de eerste stap naar meer informatie over een onderwerp – groeit. Ook Wikipedia past overigens in het rijtje van Google, Spotify en Airbnb: een encyclopedie over alles, zo snel mogelijk geüpdatet en meertalig. Met goede resultaten: Wikipedia is een vaste waarde in de jaarlijkse top 10 van meest bezochte websites.
De Wikimedia Foundation - de organisatie die alle Wikimediaplatformen beheert - beschikt over technologische infrastructuur, expertise en een netwerk, die het gratis aanbiedt, en die een instelling als het VAi zelf niet kan ontwikkelen. Daarom is het voor ons interessant om te onderzoeken of het nuttig is om mee aan te haken met de ontwikkelingen van de Wikimedia Foundation. Het Wikimedia mission statement volgt tot slot in grote mate dezelfde lijn als dat van het VAi en van andere visieteksten van de Vlaamse erfgoedsector. Dit maakt van de Wikimedia Foundation een erg logische partner om mee samen te werken.
Wikidata = vrije data
Wanneer je gegevens of beelden oplaadt naar Wikimediaplatformen 'geef' je deze niet aan de Wikimedia Foundation. Je geeft de data en beelden aan iedereen, inclusief jezelf.
De data in Wikidata zijn vrijgegeven in het publieke domein via een CC0-licentie. Ook afbeeldingen in zusterproject Wikimedia Commons zijn vrij te gebruiken dankzij Creative Commons licenties. Tot slot kun je als programmeur ook gemakkelijk aan de data raken via een API. Dit betekent dat iedereen applicaties of toepassingen kan bouwen die op een of andere manier gebruik maken van de data in Wikidata. Meer info over hoe je data uit Wikidata krijgt.
Dit maakt het perfect mogelijk om thematische websites te bouwen op Wikidata. Een mooi voorbeeld is Crotos, een website die een zoekinterface biedt op beelden van kunstwerken in Wikimedia Commons, op basis van metadata over de kunstwerken in Wikidata.
Initiatieven die gegevens uit Wikimediaplatformen hergebruiken bestaan dus al en wij vermoeden dat deze alleen maar zullen toenemen. Wikidata bevat veel en erg diverse data uit verschillende domeinen. Dit is een belangrijke troef voor ontwikkelaars, die geen data hoeven op te halen en matchen uit x websites. Dit maakt de kans erg groot dat meer ontwikkelaars in de toekomst naar Wikidata zullen kijken.
En kom je toch eens een fout tegen? Dan hoef je niet te mailen naar één of andere instantie. Je kunt de fout zelf meteen aanpassen. En hoe meer gebruik, hoe sneller fouten worden opgemerkt en opgelost. Het is dit versterkend proces dat de basis vormt van Wikipedia's succes. Waarom zou het niet opgaan voor Wikidata?
Open data beleid voor collectiedata van het VAi
De use case past binnen een bredere beleidslijn van het VAi waarbij we de mogelijkheden van open data willen onderzoeken. Het Vlaams Architectuurinstituut wenst haar collectiedata te ontsluiten als open data met een licentie die hergebruik toelaat en waar mogelijk in machineleesbare vorm. Daarmee willen we bereiken dat collectiedata maximaal inzetbaar worden voor andere partijen of toepassingen, dit in functie van volgende doelstellingen:
De bekendheid en het gebruik van de VAi-collectie verhogen
We gaan ervan uit dat publicatie van collectiedata als open data op termijn zal leiden tot een grote verspreiding en meer hergebruik van de data. Dit moet op zijn beurt ertoe leiden dat de informatie en objecten in onze collectie sneller zullen worden gevonden en gebruikt.
Andere spelers binnen de culturele deelsector van architectuur, vormgeving, bouwindustrie en stedenbouw ondersteunen en een effect van schaalvergroting creëren
Indien het VAi data open publiceert kunnen deze ook door andere verwante spelers worden hergebruikt. Termenlijsten of authority records kunnen bv. worden overgenomen. En indien er verwante informatie bestaat over verschillende collecties heen, kunnen koppelingen duurzaam worden gelegd. Op die manier ontstaat er een win-win situatie, niet alleen voor erfgoedspelers, maar ook voor organisaties uit andere sectoren.
Collectiedata opladen in Wikidata en Wikimedia Commons: De basics
Gevalstudies op CEST
Expertisecentrum PACKED, tegenwoordig verder gezet binnen meemoo, heeft in het verleden een aantal interessante case studies gepubliceerd op CEST. Deze zijn tijdens dit project uitvoerig geraadpleegd en bieden een goede basis om te starten met Wikidata en Wikimedia Commons:
- https://www.projectcest.be/wiki/Publicatie:Linked_Open_Data_publicatie_met_Wikidata: Algemene handleiding voor publicatie van museumgegevens op Wikidata
- https://www.projectcest.be/wiki/Publicatie:Upload_van_reproducties_van_kunstwerken_uit_het_Groeningemuseum_op_Wikimedia_Commons: Heldere case over hoe beelden op Wikimedia Commons kunnen worden gepubliceerd.
- https://www.projectcest.be/wiki/Publicatie:Eindrapport_project_ontsluiting_collecties_Koning_Boudewijnstichting_op_Wikimediaplatformen: Veruit de meest geraadpleegde bron. Bijzonder uitvoerig beschreven case waarbij gegevens van de Koning Boudewijnstichting op Wikimedia Commons werden gepubliceerd. M.u.v. Cat-a-log werden alle beschreven tools ook in dit project gebruikt.
Linked Open Data en RDF
Linked Open Data en RDF zijn kernbegrippen voor een goed begrip van Wikidata.
Open data is een manier van publiceren waarbij de data vrij herbruikbaar zijn omdat ze behoren tot het publieke domein of beschikbaar zijn gesteld onder een vrije licentie. Ze kunnen zonder toestemming worden geraadpleegd, gedownload en hergebruikt (mogelijk onder voorwaarden).
Data als open publiceren is één ding, ervoor zorgen dat ze ook worden hergebruikt is een ander. Hoe meer het hergebruik kan worden geautomatiseerd, hoe groter de kans dat externe datagebruikers of externe ontwikkelaars ermee aan de slag kunnen. De mate waarin datapublicatie hergebruik faciliteert, wordt klassiek weergegeven met het 5-star deployment scheme van Tim Berners-Lee, met linked open data als het eindstadium.
Van Linked Open Data is sprake wanneer data:
- vrij herbruikbaar zijn (dus: 'open' zijn)
- machineleesbaar zijn (gestructureerd)
- opgeslagen zijn in een open formaat
- gegevens waar mogelijk worden voorgesteld door een URI, die doorverwijst naar andere gegevens
- zijn gelinkt met andere data op het web
URI staat voor Uniform Resource Identifier. Een URL (Uniform Resource Locator) is een bepaald type van URI. Vaak worden beide termen door elkaar gebruikt. Wanneer we verder in deze gevalstudie over een URI spreken, bedoelen we steeds een URL.
Het voordeel van stap 4, gebruik van URI's, is dat complexe queries op omvangrijke datasets mogelijk worden, verspreid over verschillende databanken op het web. Bovendien bereik je een optimale interconnectiviteit omdat applicaties met behulp van de URI/URL’s meteen weten waar en hoe de data kunnen worden opgehaald. Het meest gebruikte framework waarin linked open data worden gepubliceerd is RDF. Standaarden die op dit moment voor de erfgoedsector worden ontwikkeld, zoals de OSLO-standaard en Records in Context (RiC) zijn opgebouwd volgens het RDF-framework.
RDF staat voor Resource Description Framework en betekent dat de gegevens worden gepubliceerd in verzamelingen (sets) van triples, met gegevens zoveel mogelijk in de vorm van URI’s. Iedere triple bestaat uit een combinatie van Entity - Attribute - Value (in het Nederlands: Subject - Predicaat - Object). De stelling 'Léon Stynen is een architect' wordt bv.
| Entity | Attribute | Value |
|---|---|---|
| Léon Stynen | is een | Architect |
In Wikidata wordt zo'n triple een statement genoemd.
SPARQL tot slot is de taal waarmee je in deze verzamelingen van triples kunt zoeken. Het is een querytaal, zoals SQL die is voor relationele databases. Het is SPARQL dat je gebruikt in query.wikidata.org.
Voorbeeld
Laat ons RDF illustreren met behulp van onderstaand record op de collectiewebsite van het VAi, raadpleegbaar op http://data.flandersarchitecture.be/object/obj-0002099.
De entiteit (het subject) is hier de specifieke tekening die we willen beschrijven. De triple set wordt dan:
| Entity | Attribute | Value |
|---|---|---|
| Tekening | Objectnummer | obj-0002099 |
| Tekening | Objectnaam | Bouwtekening (ontwerp) |
| Tekening | Naam | obj-0002099, Tekening betreffende het ontwerp van een neoclassicistisch ensemble van burgerhuizen met neogotisch hoekhuis te Zurenborg door Edmond Van Waeterschoodt (Adres: Dolfijnstraat 36-38 ; Tweelingenstraat 2-4) |
| Tekening | Datering van | 1897 |
| Tekening | Datering tot | 1897 |
| Tekening | Datering bijzonderheden | 1897-09-10 |
| Tekening | Vervaardiger | Van Waeterschoodt, Edmond |
| Tekening | Aantal onderdelen | 1 |
In het RDF-model wordt er zoveel mogelijk naar gestreefd om de entities, attributes en values niet met absolute waardes, maar met URI’s aan te geven. URI’s waarachter weer nieuwe informatie schuilt. In onderstaand voorbeeld is dit waar mogelijk gedaan met fictieve URI's:
| Entity | Attribute | Value |
|---|---|---|
| http://uri/naar/info/over/tekening | http://uri/naar/info/over/objectnummer | obj-0002099 |
| http://uri/naar/info/over/tekening | http://uri/naar/info/over/objectnaam | http://uri/naar/info/over/bouwtekening_(ontwerp) |
| http://uri/naar/info/over/tekening | http://uri/naar/info/over/naam | obj-0002099, Tekening betreffende het ontwerp van een neoclassicistisch ensemble van burgerhuizen met neogotisch hoekhuis te Zurenborg door Edmond Van Waeterschoodt (Adres: Dolfijnstraat 36-38 ; Tweelingenstraat 2-4) |
| http://uri/naar/info/over/tekening | http://uri/naar/info/over/datering-van | 1897 |
| http://uri/naar/info/over/tekening | http://uri/naar/info/over/datering-tot | 1897 |
| http://uri/naar/info/over/tekening | http://uri/naar/info/over/datering-bijzonderheden | 1897-09-10 |
| http://uri/naar/info/over/tekening | http://uri/naar/info/over/vervaardiger | http://uri/naar/info/over/van-Waeterschoodt_Edmond |
| http://uri/naar/info/over/tekening | http://uri/naar/info/over/aantal-onderdelen | 1 |
Wikidata is opgebouwd volgens deze RDF-principes. Hieronder vind je het voorbeeldrecord in RDF-vorm op Wikidata. Onderstaande URI's zijn niet fictief:
Bovenstaand voorbeeld is geen echt voorbeeld van de wijze waarop RDF wordt gecodeerd, maar geeft wel het principe weer. Echte RDF-code voor dit voorbeeld kan worden geraadpleegd op https://www.wikidata.org/w/index.php?title=Q77535086&action=info. Zie hiervoor 'Alternate views' en klik op 'rdf' of 'ttl'.
Voor een goed begrip: Linked open data is een manier van datapublicatie die in eerste instantie niet op menselijk gebruik is gericht, maar op gebruik door applicaties, machines en computertoepassingen.
Applicaties die op hun beurt de data wel weer kunnen weergeven in mensvriendelijke vorm. De website 5stardata.info geeft een mooi voorbeeld hiervan in de vorm van een weervoorspelling:
- De weersvoorspelling in de vorm van 'rauwe' Linked Open Data: http://graphite.ecs.soton.ac.uk/browser/?uri=http://5stardata.info/en/examples/gtd-5/
- De open data hergebruikt op een mensvriendelijke webpage: https://5stardata.info/en/examples/gtd-5/
Hoe aan de slag met Linked Open Data en RDF?
Vooraleer je collectiedata kunt publiceren als RDF (= vier sterren) moet je als erfgoedinstelling dus enkele voorbereidende werken doen::
- Collectie- of archiefobjecten identificeren met een URI, zodat ze als Entity kunnen dienen in een RDF-triple. Deze URI is idealiter ook persistent, d.w.z. onveranderlijk in de tijd (zie onder).
- De informatie over je metadatavelden identificeren met een URI, zodat ze als Attribute kunnen dienen in een RDF-triple. Dit kan door ze zelf te publiceren, maar veel gemakkelijker is om een veld dat elders onder een URI is gepubliceerd te recycleren (in deze case gebruiken we de properties van Wikidata, bv. Wikidata-property P170 voor 'vervaardiger').
- De waarden (bv. 'Van Waeterschoodt, Edmond') die je aan een metadataveld toekent moeten waar mogelijk identificeren met een URI, zodat ze kunnen dienen als Value in een RDF-triple. Ook hier is het opnieuw het handigst om URI's van andere bronnen te recycleren. Opnieuw maken we gebruik van het Wikidataconcept (bv. Q21498824 voor Van Waeterschoodt), maar je zou ook concepten van andere bronnen kunnen gebruiken, zoals VIAF (architect Joseph Schadde op VIAF: 42714746)
Het is absoluut niet nodig om een RDF-specialist te zijn om aan de slag te kunnen met Linked Open Data. Het volstaat om te leren werken met Wikidata. Wikidata heeft als linked open data platform al bijzonder veel attributes en values klaarstaan die kunnen worden hergebruikt. Wikidata biedt daarnaast ook de databankinfrastructuur om gegevens te publiceren in RDF, de tools én de manuals om ermee te leren omgaan. Het is daarenboven een platform dat focust op functionaliteit en gebruiksvriendelijkheid. Heel wat van de complexe technische zaken van RDF, die voor de eindgebruiker niet meteen essentieel zijn, worden uit het zicht gehouden. Last but not least, Wikidata linkt de gegevens intensief met andere webbronnen. Jouw collectiegegevens op Wikidata krijgen dus niet vier sterren, ze zijn meteen five star data!
RDF-kennis is niet noodzakelijk, maar het is wel nuttig om de basics van SPARQL aan te leren, omdat je dan meteen queries los kunt laten op de data. Verder in deze gevalstudie zul je enkele voorbeelden van SPARQL tegenkomen. Deze kunnen op het eerste zicht nogal specialistisch lijken, maar niets is minder waar. Basic SPARQL-queries kun je leren op één dag, door voorbeelden te kopiëren en uit te testen. Een zeer goede handleiding biedt Wikidata: https://www.wikidata.org/wiki/Wikidata:SPARQL_tutorial
In het vervolg van deze gevalstudie gaan we verder in op hoe het VAi de collectiedata heeft klaargemaakt voor publicatie op Wikidata, waarna we de publicatie op Wikidata zelf onder de loep nemen.
Collectiedata klaarmaken voor publicatie op Wikidata
Om onze collectiedata voor te bereiden doorliepen we drie stappen:
- Entities: Collectiestukken online publiceren met persistente URI's
- Attributes: Velden in ons archiefbeheersysteem mappen met Wikidata's properties
- Values: Waar van toepassing onze trefwoorden of gerelateerde actoren mappen met concepten in Wikidata
Het VAi werkt voor het beheer van de collectie met de collection management software Qi. Dit archiefbeheersysteem beschikt over enkele eigenschappen die erg nuttig waren voor het uitvoeren van de gevalstudie:
- een API die gegevens aanbiedt in JSON-formaat. Dit bleek erg handig. Met enkel Excel-exports was het wellicht ook gelukt, maar hadden we minder kunnen automatiseren.
- de databank is flexibel te configureren door het archiefteam van het VAi. Dit betekent dat we waar nodig zelf de aanpassingen in het datamodel konden doen, zonder dat dit via de leverancier moest. Dit was vooral nuttig om extra velden te creëren, zoals velden voor de opslag van Wikidata-id’s.
Stap 1: De entity van het statement / persistente identificatie van collectiestukken
Laat je gegevens over een collectiestuk op naar Wikidata, dan genereert Wikidata hier zelf een URI voor. Maar deze URI alleen is niet voldoende. Om de collectiedata van het VAi tussen de miljarden triples in Wikidata te blijven terugvinden - en om koppelingen te kunnen leggen met het eigen beheersysteem - is het essentieel om je collectiedata in je collectiebeheersysteem op voorhand uniek te hebben geïdentificeerd aan de hand van een ID dat is toegekend door het VAi zelf. Dit uniek ID moet vervolgens mee opgeladen worden naar Wikidata, bij voorkeur in de vorm van een persistente URI (zie onder). Zo blijft de band tussen de Wikidatagevens en het VAi verzekerd. Doen we dit niet, dan verliezen we op termijn het overzicht over wat we al op Wikidata hebben gepubliceerd, zodat nieuwe publicaties in de toekomst een tijdrovend ontdubbelingswerk worden.
Door ID’s mee op te laden zijn alle stukken binnen de VAi-collectie in één keer opvraagbaar via een relatief eenvoudige SPARQL-query:
SELECT ?archive_object ?archive_objectLabel ?reference_code ?top_archive_qid ?top_archive_reference_code
WHERE {
# Hier zeggen we: Geef me alles met een inventarisnummer van het VAi
?archive_object p:P217 [ ps:P217 ?reference_code; pq:P195 wd:Q77201544 ] .
# Hier zeggen we: Als het object deel uitmaakt van een archief, geef me dan dit archief en het inventarisnummer
OPTIONAL {?archive_object wdt:P361 ?top_archive_qid .
?top_archive_qid wdt:P217 ?top_archive_reference_code .}
# Dit is een standaard Wikidata SPARQL-regel. Gewoon kopiëren
SERVICE wikibase:label { bd:serviceParam wikibase:language "nl". }
}
Deze query kan uitgetest worden op query.wikidata.org. Je kunt er ook rechtstreeks naartoe via https://w.wiki/u$L.
ID's voor je collectie bepalen
De collectie van het VAi wordt beschreven m.b.v. twee entiteiten:
- Archieven: Een datamodel gebaseerd op ISAD(G), gemaakt om aggregaties van informatie (archieven, series, archiefbestanddelen) te beschrijven.
- Objecten: Een datamodel gebaseerd op Spectrum via het invulboek objecten, gemaakt om museale beschrijvingen te creëren van enkelvoudige objecten, zoals de maquettes en tekeningen in de collectie.
Voor archieven was er al een identificatiesysteem voorhanden. Voor objecten konden we dit opbouwen binnen het project Persistente Architectuur.
Archieven
Onze archief ID’s zijn in wezen de inventarisnummers. Ze volgen het Archiefbanksjabloon (Zie helppagina's van Archiefbank, blz. 8).
Ieder inventarisnummer is een combinatie van landcode ('BE'), bewaarplaatscode ('653717'), archiefcode ('0016-ENG' voor het archief van Engetrim) en een code voor een bestanddeel ('0001'), bijvoorbeeld:
BE/653717/0016-ENG/0001
Dit systeem was al lang in gebruik en werd vormgegeven voordat er werd nagedacht over persistente URI’s. Verschillende eigenschappen van dit inventarisnummer maken het minder geschikt voor persistente URI’s (zie onder). Voorbeeld van een VAi-archiefbestanddeel in Wikidata: https://www.wikidata.org/wiki/Q104092805</nowiki>
Objecten
De inventarisnummers voor objecten volgen een eenvoudiger schema, bijvoorbeeld:
obj-0002099
Voor de samenstelling van ID’s voor objecten is er rekening gehouden met gebruik in persistente URI’s. De code bestaat gewoon uit een oplopend nummer, uniek over de hele VAi-collectie. Het enige betekenisvolle element is ‘obj-‘, wat staat voor 'object'. Voorbeeld van een VAi-object in Wikidata: https://www.wikidata.org/wiki/Q77592348
Publicatie van collectiedata op een website
In principe is het mogelijk om collectiedata op Wikidata op te laden, zonder deze elders online te publiceren. Maar dit is geen best practice, want binnen Wikidata heerst een conventie dat alle statements bij voorkeur gestaafd worden door het toevoegen van een bronvermelding (reference). Een bronvermelding verhoogt de betrouwbaarheid van het statement en vermindert het risico dat het zal worden gewijzigd of verwijderd. Daarbij heeft Wikidata een voorkeur om door te verwijzen naar online bronnen, omdat deze sneller kunnen worden nagegaan.
Er zijn dus meerdere argumenten om collectiedata die je op Wikidata wilt uploaden eerst te publiceren op een eigen website. Het VAi realiseerde dit binnen het project Persistente Architectuur door een website te bouwen die archief- en objectdata online publiceert. De website kan worden geraadpleegd op https://collectie.vai.be.
Persistente URI's
Een persistente URI is een URI die niet verandert en altijd blijft doorverwijzen naar hetzelfde concept.
De belangrijkste doelstelling voor een archief om collectiedata te publiceren is om te bereiken dat archieven meer worden gevonden, opgevraagd en gebruikt. Om dit te bereiken is het aan te raden om het aantal tussenstappen en handelingen voor gebruikers zoveel mogelijk te verminderen. Persistente URI's bieden een prachtig hulpmiddel om de 'aanvraagknop' op de collectiewebsite via één klik bereikbaar te maken voor gebruikers die ergens op het web informatie gevonden hebben over een specifiek archief of archiefbestanddeel.
Een persistente URI blijft ongewijzigd, wat alles beter beheersbaar maakt. De standaard URL’s die een website genereert zijn immers afhankelijk van het specifieke systeem waarop de website draait. Wanneer we na 10 jaar de website migreren naar een ander systeem, verandert meestal ook de URI. Door met persistente URI's te werken kunnen we deze veranderingen beter beheersen.
Voor publicatie op Wikidata is een persistente URI geen vereiste, maar het is absoluut een best practice, omdat je met deze URI de statements die je maakt kunt staven met een referentie naar je eigen website. Dit leidt tot meer verkeer op de eigen website en zorgt er tevens voor dat we de URI na enkele jaren niet moeten aanpassen.
Voor het maken van persistente URI’s is er goede informatie voorhanden. Zie ondermeer https://www.projectcest.be/wiki/Publicatie:Project_Persistente_identificatie, de wiki van CultURIze en de Vlaamse URI-standaard.
Wij besloten om de persistente URI’s op te bouwen volgens het schema http://[domein]/[concept]/[identifier] en niet volgens http://[domein]/[type]/[concept]/[identifier], omdat ‘type’ optioneel is en we – op dit moment – geen onderscheid tussen types hebben. Andere erfgoedinstellingen, zoals de Inventaris Onroerend Erfgoed en ODIS werken met eenzelfde URI-schema.
- Het domein: data.flandersarchitecture.be (en niet data.vai.be, om zo mogelijke naamswijzigingen in de toekomst voor te zijn)
- Het concept: 'archive' voor archieven en 'object' voor objecten
- Identifier: de inventarisnummers voor resp. archieven en objecten
Voor 'objecten' konden we het bestaande inventarisnummer gewoon overnemen. Voor de 'archieven' moesten we het format van het inventarisnummer wijzigen: 'BE/653717/0016-ENG/0001' werd '0016-ENG_0001'.
!!! In retrospectief hadden we voor archieven waarschijnlijk beter een ander nummer gekozen i.p.v. het inventarisnummer. '0016-ENG_0001' betekent 'bestanddeel 1 van archief 0016-ENG'. Het is niet ondenkbaar dat ooit enkele bestanddelen in andere archieven zullen worden ondergebracht. We zouden dus aanraden met twee nummers te werken: één inventarisnummer en één uniek, betekenisloos, automatisch toegekend nummer voor het record over het archief in het archiefbeheersysteem. Dit laatste nummer kan dan dienen als identifier voor de persistente URI. Zie voor deze manier van werken bv. de website van het Felixarchief.
Stap 2: Het attribute van het statement / Wikidata properties
Het klaarmaken van de metadatavelden voor publicatie op Wikidata is een kwestie van data mapping en een relatief eenvoudige oefening. Niet alle metadatavelden, en in het bijzonder vrije tekstvelden, kunnen gemapt worden naar een property in Wikidata. Deze werden dan ook niet meegenomen in de oefening.
Minimale velden voor objecten
Goede voorbeelden voor het opladen van data over erfgoedobjecten zijn voorhanden, dankzij uploadprojecten van VKC en meemoo. Zie bv. https://www.wikidata.org/wiki/Wikidata:Flemish_art_collections,_Wikidata_and_Linked_Open_Data#Flemish_art_collections. Zie ook de crosswalk in het whitepaper dat voor dit project is gepubliceerd.
| Veldnaam | VAi API-naam | Wikidata property | Wikidata property ID | Opmerkingen |
|---|---|---|---|---|
| Objectnummer | object_number | Inventarisnummer | P217 | Steeds qualifier P195 ('collection') toevoegen, met als waarde 'Collectie VAi' |
| Titel | title | Nederlandse beschrijving | Dnl | |
| Titel | P1476 | |||
| Objectnaam | thesaurus_object_type_id | Is een | P31 | Mapping nodig met Wikidataconcepten |
| Hoofdarchief | archive_id | Deel van | P361 | Link me archief van herkomst (Moet al in Wikidata staan) |
| Beginjaar | start_date | Datum van oprichting of creatie | P571 | Waarde converteren naar Wikidataformaat |
Het eindjaar van een object voegden we niet toe omdat dit voor het overgrote deel van onze objecten identiek is aan het beginjaar
De upload naar Wikidata vereiste ook dat enkele aanvullende velden werden gecreëerd, die steeds op standaardwijze kunnen worden ingevuld:
| Wikidata property | Wikidata property ID | Invulling | Opmerkingen |
|---|---|---|---|
| Dutch Label | Lnl | Combinatie van archieftitel (Nederlands) + objectnummer | De Wikidatalabels zijn de eigenlijke 'titels'. De titels die wij toekennen aan collectiestukken overschrijden echter vaak de max. tekenlengte voor het Label-veld |
| English Label | Len | Combinatie van archieftitel (Engels) + objectnummer | |
| Collectie | P195 | Q77201544 (“Collectie Vlaams Architectuurinstituut”) | Om beschrijvingen van VAi-objecten te onderscheiden van beschrijvingen van objecten uit andere collecties |
Minimale velden voor archieven
Met archief hebben we ons in dit project in het bijzonder gefocust op archiefbestanddelen. Op het moment dat we met Persistente Architectuur een mapping maakten voor onze archiefbestanddelen was er als voorbeeld een grote set Amerikaanse archieven beschikbaar, wellicht opgeladen vanuit de Amerikaanse National Archives Catalogue. Deze archiefbeschrijvingen (een kleine 30.000) kunnen worden teruggevonden via volgende query: https://w.wiki/tuZ We hebben deze records vervolgens als uitgangspunt genomen voor het bepalen van een mapping voor de VAi-archieven.
| Veldnaam | VAi API-naam | Wikidata property | Wikidata property ID | Opmerkingen |
|---|---|---|---|---|
| Referentienummer | reference_code | Inventarisnummer | P217 | Steeds qualifier P195 ('collection') toevoegen, met als waarde 'Collectie VAi' |
| Titel | title | Nederlandse beschrijving | Dnl | |
| Titel | P1476 | |||
| Beschrijvingsniveau | archive_level_description_id | Beschrijvingsniveau | P6224 | Mapping nodig met Wikidataconcepten |
| Hoofdarchief | top_archive_id | Deel van | P361 | Link me archief van herkomst (Moet al in Wikidata staan) |
| Beginjaar | start_year | Begindatum | P580 | Waarde converteren naar Wikidataformaat |
| Eindjaar | end_year | Einddatum | P582 | Waarde converteren naar Wikidataformaat |
Voegen we niet toe: het bovenliggende archiefniveau, omdat dit het opladen veel complexer zou maken. Het bovenliggende archiefniveau kan worden teruggevonden via onze collectiewebsite
De upload naar Wikidata vereiste ook dat enkele aanvullende velden werden gecreëerd, die steeds op standaardwijze kunnen worden ingevuld:
| Wikidata property | Wikidata property ID | Invulling | Opmerkingen |
|---|---|---|---|
| Dutch Label | Lnl | Combinatie van archieftitel (Nederlands) + inventarisnummer | |
| English Label | Len | Combinatie van archieftitel (Engels) + objectnummer | |
| Instance of | P31 | Q56648173 (“archives”) | Het Amerikaanse voorbeeld gebruikt Q2668072 (“collection”), maar wij kiezen voor een preciezere variant. (“archives” is een ‘subclass’ van “collection”) |
| Collectie | P195 | Q77201544 (“Collectie Vlaams Architectuurinstituut”) | Om beschrijvingen van VAi-archieven te onderscheiden van beschrijvingen van archieven uit andere collecties. |
Extra beschrijvingsvelden
De minimale velden zijn essentieel, maar de bruikbaarheid en vindbaarheid van de beschrijvingen in Wikidata nemen enorm toe wanneer extra gegevens worden opgeladen die connecties leggen met de concepten van Wikidata. Onderstaande gegevens proberen we wanneer voorhanden mee op te laden.
| Veldnaam | VAi API-naam | Wikidata property | Wikidata propery ID | Opmerkingen |
|---|---|---|---|---|
| Algemeen gebouwtype | thesaurus_project_type_id, object_projecttype | Hoofdonderwerp / Beeldt af (voor 'Artwork'-objecten) | P921 / P180 | Voorlopige oplossing in afwachting van een preciezer property |
| Specifiek gebouwtpe | archive_projecttype_detail | Hoofdonderwerp / Beeldt af (voor 'Artwork'-objecten) | P921 / P180 | Voorlopige oplossing in afwachting van een preciezer property |
| Gemeente | thesaurus_place_id, object_thesaurus_place | Relevante plaats | P7153 | Wij koppelen voor fijnmazigheid eerder met fysieke ‘populated places’ dan met ‘administratieve entiteiten’ |
| Licentie | copyright_type_id | Auteursrechtenstatus | P6216 | Enkel voor 'objecten' |
| Materiaal/drager | thesaurus_material_id | Gebruikt materiaal | P186 | Enkel voor 'objecten' |
| Techniek | thesaurus_technique_id | is een | P31 | Enkel voor 'objecten'; Wikidata heeft ook een eigenschap ‘fabrication method’ (P2079). Na tests met dit property bleek het aantal beschikbare waarden voor technieken zeer laag te zijn in Wikidata. Wel ruim beschikbaar waren het aantal waarden voor objecten gebaseerd op technieken. Dus niet ‘pentekenen’ maar ‘pentekening’. Onze technieken zijn daarom gemapt naar ‘objecttypes’ en de correcte property om te gebruiken is dus P31. |
Kan (nog) niet in Wikidata: Stijl. Wij voegen ook architecturale stijlkenmerken toe aan onze objectbeschrijvingen. De aanwezige property ‘architectural style’ (P149) kan echter enkel worden toegepast op gebouwen en niet op documentatie.
Stap 3: De value van het statement / Wikidataconcepten voor trefwoorden en actoren
Een grote meerwaarde voor de vindbaarheid van collectiedata in Wikidata is het toevoegen van trefwoorden of gerelateerde actoren.
Trefwoorden
Het VAi voert verschillende architectuurgerelateerde trefwoorden toe, met als belangrijkste het gebouwtype. Het is echter onmogelijk om het trefwoord als tekstveld toe te voegen aan Wikidata, omdat dit niet in lijn is met het RDF-framework volgens hetwelk Wikidata is opgebouwd. Waar een waarde een URI naar een concept kan zijn, moet dit ook zo worden ingevuld. Dus niet ‘gemeentehuis’, maar ‘uri/met/info/over/het/concept/gemeentehuis’. Alle trefwoorden in het archiefbeheersysteem moeten dus eerst worden gemapt naar het juiste concept in Wikidata. Waar deze concepten nog niet bestonden, konden de concepten meteen door het VAi worden aangemaakt. Waar mogelijk legden wij vanuit Wikidata ook meteen de connectie naar de Art & Architecture Thesaurus. Deze oefening verliep niet altijd eenduidig. Soms moest er creatief worden omgesprongen met de mapping, zie bv. het veld techniek in stap 2.
De trefwoorden en hun Wikidata-equivalent zijn in JSON-formaat gepubliceerd in een Github repository.
Actoren
Voor informatie over actoren maakt het VAi gebruik van de ODIS-databank. Een export van 1500 personen uit de ODIS-databank (gelinkt met trefwoorden 'architectuur', 'design', 'bouw' of 'stedenbouw') werd in Wikidata ingeladen, waarna de personen, samen met hun ODIS- én Wikidata-id werden geüpdatet in het archiefbeheersysteem van het VAi. Op die manier werden ook de authorities in het eigen archiefbeheersysteem verrijkt met Wikidata-id's. Het ging hierbij niet enkel om een upload van nieuwe gegevens. Een 800-tal personen bleken zich al in Wikidata te bevinden. In dat geval hebben we waar nuttig informatie uit ODIS aan de bestaande records toegevoegd.
Alle gegevens uit Wikidata gekoppeld met ODIS die gekoppeld zijn aan trefwoorden 'architectuur', 'design', 'bouw' of 'stedenbouw' kunnen worden opgevraagd met onderstaande query via query.wikidata.org. Je kunt ook rechtstreeks de resultaten bereiken via https://w.wiki/wYo.
SELECT ?actor ?actorLabel ?ODISid ?vaitagLabel
WHERE {
# Hier zeggen we: Ik wil enkel actoren met een ODIS ID
?actor wdt:P2372 ?ODISid .
# Hier zeggen we: De actor moet als werkveld of architectuur of design of bouw of stedenbouw hebben
OPTIONAL {?actor wdt:P101 wd:Q12271 .
BIND(wd:Q12271 AS ?vaitag).}
OPTIONAL {?actor wdt:P101 wd:Q82604 .
BIND(wd:Q82604 AS ?vaitag).}
OPTIONAL {?actor wdt:P101 wd:Q385378 .
BIND(wd:Q385378 AS ?vaitag).}
OPTIONAL {?actor wdt:P101 wd:Q59950 .
BIND(wd:Q59950 AS ?vaitag).}
# Hier zeggen we: De actor moet minstens één van vier bovenstaande trefwoorden als werkveld hebben
FILTER (BOUND(?vaitag)).
# Dit is een standaard Wikidata SPARQL-regel. Gewoon kopiëren
SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
Collectiedata opladen in Wikidata met behulp van Open Refine
Eenmaal al het voorbereidende werk gebeurd, kan begonnen worden met het publiceren van de collectiedata in Wikidata. De meest gebruiksvriendelijke manier om dit te doen is de tool Open Refine (vroeger GoogleRefine), open source software waarmee men makkelijk grote hoeveelheden van data kan visualiseren, analyseren, manipuleren en corrigeren. De tool laat toe om op een relatief eenvoudige wijze je data in spreadsheetformaat om te zetten naar een formaat dat kan worden opgeladen in Wikidata.
In de verschillende CEST-gevalstudies die bovenaan dit artikel zijn opgelijst vind je daar voorbeelden van terug. Er is ook een meer algemene handleiding op Wikidata. Wij houden zelf op deze pagina een overzicht bij van handige tips & tricks voor Open Refine die we ooit nodig hadden. Een site met bijzonder veel handige how to’s is https://kb.refinepro.com/, maar als je goed weet hoe je vraag te stellen is Google je beste vriend.
Eenmaal data zijn omgezet in een formaat voor Wikidata kun je ervoor kiezen om de data rechtstreeks te importeren in Wikidata m.b.v. Open Refine, of om de data uit Open Refine te exporteren in Quickstatements, dat kan worden gebruikt om imports te doen in Wikidata. Meestal maakten we van deze laatste optie gebruik.
Quickstatements: het Wikidata-importformaat
Quickstatements is een heel eenvoudig gestructureerd tekstformaat dat je aan Wikidata kunt aanbieden via de tool Quickstatements. De werking van Quickstatements is bijzonder eenvoudig en is heel helder gedocumenteerd. Een voorbeeldbestand:
Q104662383 P7153 Q31467408 S854 "https://data.flandersarchitecture.be/archive/0008-JLS_0110"
Q104662384 P7153 Q31467408 S854 "https://data.flandersarchitecture.be/archive/0008-JLS_0111"
Q104662388 P7153 Q31467408 S854 "https://data.flandersarchitecture.be/archive/0008-JLS_0112"
Q104662390 P7153 Q31467408 S854 "https://data.flandersarchitecture.be/archive/0008-JLS_0113"
Q104662392 P7153 Q31467408 S854 "https://data.flandersarchitecture.be/archive/0008-JLS_0114"
Q104662394 P7153 Q31467408 S854 "https://data.flandersarchitecture.be/archive/0008-JLS_0115"
Q104662398 P7153 Q31467408 S854 "https://data.flandersarchitecture.be/archive/0008-JLS_0116"
Q104662400 P7153 Q31467408 S854 "https://data.flandersarchitecture.be/archive/0008-JLS_0117"
Q104662401 P7153 Q31467408 S854 "https://data.flandersarchitecture.be/archive/0008-JLS_0118"
Q104662403 P7153 Q31467408 S854 "https://data.flandersarchitecture.be/archive/0008-JLS_0119"
Q104662405 P7153 Q31467408 S854 "https://data.flandersarchitecture.be/archive/0008-JLS_0120"
Hieraan kun je zien dat een Quickstatements-tekstformaat gewoon een set van RDF-triples (Entity - Attribute - Value) is:
- De eerste kolom is het ID van het Wikidata-concept dat in deze oefening de rol van entity speelt (een archiefbestanddeel)
- De tweede kolom is het ID van het attribute of de property in Wikidata (in dit geval property P7153 ‘relevante plaats’)
- De derde kolom is het ID van het Wikidata-concept dat de rol van value vervult (in dit geval: Q31467408 ‘Antwerpen’)
Hier wordt dus steeds opnieuw gezegd: “Dit archiefbestanddeel heeft als relevante plaats Antwerpen”
Kolom 4 is iets specifieks voor Quickstatements en gebruiken we om een ‘reference’ (bronvermelding) toe te voegen aan het statement. ‘S854’ staat voor ‘reference url’. De waarde daarvan is gewoon onze persistente URI (kolom 5). Bij voorkeur heeft ieder statement zo’n ‘reference url’.
Als je een nieuw item wil aanmaken, heb je in de eerste kolom natuurlijk nog geen Wikidata-ID. Een dergelijk Quickstatements-tekstbestand:
CREATE
LAST Len "Archival file unit from the Joseph-Louis Stynen archive, ref. BE/653717/0008-JLS/0120"
LAST Lnl "Archiefbestanddeel uit het archief van Joseph-Louis Stynen, ref. BE/653717/0008-JLS/0120"
LAST Dnl "Projectdossier over de Onze-Lieve-Vrouw van Victorie kapel in Antwerpen (Borgerhout) "
LAST P1476 nl:"Projectdossier over de Onze-Lieve-Vrouw van Victorie kapel in Antwerpen (Borgerhout) " S854 "http://data.flandersarchitecture.be/archive/0008-JLS_0120"
LAST P31 Q2668072 S854 "http://data.flandersarchitecture.be/archive/0008-JLS_0120"
LAST P6224 Q59221146 S854 "http://data.flandersarchitecture.be/archive/0008-JLS_0120"
LAST P217 "BE/653717/0008-JLS/0120" P195 Q77201544 S854 "http://data.flandersarchitecture.be/archive/0008-JLS_0120"
LAST P361 Q104092046 S854 "http://data.flandersarchitecture.be/archive/0008-JLS_0120"
LAST P195 Q77201544 S854 "http://data.flandersarchitecture.be/archive/0008-JLS_0120"
CREATE
LAST Len "Archival file unit from the Joseph-Louis Stynen archive, ref. BE/653717/0008-JLS/0121"
LAST Lnl "Archiefbestanddeel uit het archief van Joseph-Louis Stynen, ref. BE/653717/0008-JLS/0121"
LAST Dnl "Projectdossier over uitbreidingen aan de Vak- en Nijverheidsschool in Antwerpen (Borgerhout) (Oudstrijdersstraat)"
LAST P1476 nl:"Projectdossier over uitbreidingen aan de Vak- en Nijverheidsschool in Antwerpen (Borgerhout) (Oudstrijdersstraat)" S854 "http://data.flandersarchitecture.be/archive/0008-JLS_0121"
LAST P31 Q2668072 S854 "http://data.flandersarchitecture.be/archive/0008-JLS_0121"
LAST P6224 Q59221146 S854 "http://data.flandersarchitecture.be/archive/0008-JLS_0121"
LAST P217 "BE/653717/0008-JLS/0121" P195 Q77201544 S854 "http://data.flandersarchitecture.be/archive/0008-JLS_0121"
LAST P361 Q104092046 S854 "http://data.flandersarchitecture.be/archive/0008-JLS_0121"
LAST P195 Q77201544 S854 "http://data.flandersarchitecture.be/archive/0008-JLS_0121"
LAST P580 +1950-00-00T00:00:00Z/9 S854 "http://data.flandersarchitecture.be/archive/0008-JLS_0121"
In plaats van een Q-nummer staat er een waarde CREATE. Wikidata overloopt vervolgens regel per regel van het Quickstatements-tekstbestand:
- Regel 1: CREATE 🡪 Quickstatements bereidt zich voor om een nieuw Subject aan te maken. Een nieuw Q-nummer voor het subject wordt gegenereerd.
- Regel 2 🡪 Quickstatements voegt “Archival file unit from the Joseph-Louis Stynen archive, ref. BE/653717/0008-JLS/0120” als Value toe van Attribuut “Engelstalig label” ('Len') aan de laatst ('LAST') aangemaakte entity.
- Dit gaat zo verder tot het volgende woordje ‘CREATE’, wanneer weer een nieuwe entity wordt aangemaakt.
Reconciliation services
In heel het Open Refine-proces vereisen twee tussenstappen een grote tijdsinvestering:
- Het matchen van jouw termen (trefwoorden, actoren) met de Wikidataconcepten.
- Het controleren op dubbels.
Beide zaken worden automatisch ondersteund dankzij de reconciliation services van Open Refine. Reconciliation services nemen een term uit jouw data en linken die via een algoritme aan het juiste Wikidata-concept. Voor tussenstap 1 worden jouw trefwoorden, actoren of andere termen dus gemapt met het Wikidata-equivalent, voor tussenstap 2 wijst een match op het feit dat de entiteit in Wikidata al bestaat en niet opnieuw mag worden aangemaakt. Uit onze ervaring tijdens het project blijkt dat een erg groot percentage van deze automatische matches niet klopt. Dubbels worden soms niet herkend, of foutief wel gemaakt. Er is ook een groot verschil tussen ‘Lille’ in Noord-Frankrijk en ‘Lille’ in de Kempen. Puur op basis van de info ‘Lille’ kan een algoritme nooit de twee van elkaar onderscheiden. Dit wil zeggen dat handmatige controle steeds nodig is en dit kan lang duren naargelang de grootte van je dataset. Bij grote datasets mag je zo goed als altijd uitgaan van veel handmatig, repetitief werk.
Wanneer Open Refine inzetten?
Open Refine vereist dus veel handmatige checks. Het is de gepaste tool om te gebruiken bij een project of activiteit, waarbij je één specifieke dataset eenmalig moet opladen naar Wikidata. Tijdens Persistente Architectuur hebben we Open Refine gebruikt om:
- Actorinformatie uit ODIS in te laden in Wikidata.
- Onze trefwoordenlijsten te matchen met Wikidata-concepten.
- Onze archiefbeschrijvingen op fondsniveau op te laden in Wikidata.
- Om actoren te koppelen aan onze beschrijvingen.
Wanneer we echter ook op langere termijn detailbeschrijvingen van onze archieven en objecten willen uploaden, zou het erg inefficiënt en omslachtig zijn om dit steeds opnieuw via Open Refine te doen. In principe kunnen we voor VAi-detailbeschrijvingen:
- via onze unieke ID’s snel te weten komen of deze zich al dan niet in Wikidata bevinden.
- de mappings tussen Wikidata-concepten en trefwoorden in ons archiefbeheersysteem hergebruiken door de Wikidata-ID’s in ons archiefbeheersysteem op te slaan.
Eenmaal dit aanwezig, is het dus mogelijk om met ‘één druk op de knop’ collectiedata naar Wikidata te publiceren, zonder telkens weer door het zware controleproces te moeten bij het gebruik van Open Refine. Binnen Persistente Architectuur hebben we hiervoor scripts ontwikkeld in Python.
Collectiedata opladen in Wikidata met behulp van Python scripts
Python is één van de meest populaire en meest gebruikte programmeertalen in de wereld. Deze Youtube-video geeft een mooie indruk van het toenemend gebruik van Python in de laatste jaren: https://youtu.be/Og847HVwRSI.
Python in het VAi
Al voor het project Persistente Architectuur maakte het VAi gebruik van Python scripts om data op te vragen en op te laden via de API van het archiefbeheersysteem. Met de scripts halen we data op via de API, bewerken ze en exporteren hen vervolgens naar een spreadsheet of JSON. De gegevens die de API biedt kunnen in Python worden ingelezen in de vorm van ‘dictionaries’ of ‘lists’, twee standaard datatypes in Python. Met een beetje kennis van de basic ‘list’- en ‘dictionary’-functies (zie resp. https://www.w3schools.com/python/python_ref_list.asp en https://www.w3schools.com/python/python_ref_dictionary.asp) kunnen we op die manier verschillende scenario’s van dataverwerking uitvoeren.
Modules die we binnen het VAi daarvoor vaak gebruiken en in iedere standaard Python 3-distributie worden meegeleverd:
- json: een module op JSON-bestanden in te lezen en te schrijven
- re: een module om met regular expressions te werken
- os: Python’s standaardmodule om te werken met folders en bestanden op de computer.
Daarnaast maken we gebruik van de Anaconda distributie van Python. Anaconda biedt heel wat voorgeïnstalleerde modules – ontwikkeld in Python - die bijzonder interessant zijn om aan de slag te gaan met metadata en digitale archieven. Enkele van de modules in Anaconda die we het meest gebruiken:
- requests: een module om data op te vragen op het web of via API’s
- bagit: een module om bags te maken, te updaten en te valideren
- pandas: een data-analysetool (een soort Open Refine in Python), met enorm veel gebruikstoepassingen, maar binnen het VAi voorlopig vooral een JSON-naar-spreadsheet converter.
Tot slot komt Anaconda ook met Jupyter Notebook. Jupyter Notebook is een simpele editor om Pythoncode te schrijven en uit te voeren. Het is een intuïtieve omgeving om te starten met basic Python code. De ‘applicatie’ waar de VAi-medewerkers die toegang hebben tot de scripts mee werken, is Jupyter Notebook. Een VAi-medewerker, zonder kennis van Python of scripting, hoeft in principe dus enkel een script te openen in Jupyter Notebook, en op de ‘run’-knop te drukken.
De scripts zijn volledig intern binnen het VAi ontwikkeld door één medewerker en zijn organisch gegroeid en verder uitgebouwd, naarmate de kennis van de medewerker-ontwikkelaar steeg. Het gebruik van de scripts wordt aangeleerd aan medewerkers die een belangrijke rol vervullen in het beheer van het archiefbeheersysteem. Ieder jaar wordt er een dag uitgetrokken om nieuwe scripts en nieuwe functionaliteiten aan te leren. Het onderhoud van de code gebeurt ondertussen op Github. Gezien de bestaande ervaring met Python, kozen we binnen VAi om de upload van collectiedata naar Wikidata te automatiseren m.b.v. Python-scripts. Deze scripts vragen data uit de API op (reeds bestaande functionaliteit) en zetten deze vervolgens om naar een Quickstatements text file, dat vervolgens handmatig kan worden ‘gevoed’ aan Wikidata via de Quickstatements tool.
Python scripts voor Wikidata
De scripts worden gebruikt met behulp van Jupyter Notebook. De code zelf zit in een Python-bestand en wordt daar centraal beheerd: ‘wikidata_op.py’. De Jupyter Notebooks lezen stukken code uit dit bestand in. Op dit moment zijn er drie Notebooks voorhanden:
- 02_wikidata_create_archives_fromAPI: een applicatie die aan de hand van parameters archiefdata ophaalt uit het archiefbeheersysteem via de API en meteen omzet naar een Quickstatements file
- 02_wikidata_create_objects_fromAPI: een applicatie die aan de hand van parameters objectdata ophaalt uit het archiefbeheersysteem via de API en meteen omzet naar een Quickstatements file
- 02_wikidata_update_items_fromAPI: een applicatie die aan de hand van parameters voor de API data ophaalt voor zowel objecten als archieven via de API en deze gebruikt om bestaande items van het VAi in Wikidata aan te passen.
Bij de twee ‘create’-notebooks gaat het steeds om het uploaden van nieuwe archieven of objecten met de minimale data. Indien de beschrijving meer metadata moet bevatten, dient dit te gebeuren met het ‘update’-notebook. In de drie gevallen is er steeds een mapping-gebeurtenis, waarbij automatisch gegevens uit de API via de inventarisnummers met het corresponderende item in Wikidata worden gemapt. Bij de twee ‘create’-notebooks wordt op die manier gecontroleerd of een archiefbeschrijving al dan niet in Wikidata aanwezig is, zodat geen dubbele items worden aangemaakt.
Om gegevens te actualiseren is er functionaliteit ingebouwd om trefwoorden in het archiefbeheersysteem te mappen met het correcte Wikidata-concept. Om snelheid te winnen, vragen we de gemapte trefwoorden niet steeds opnieuw op via de API, maar vragen we één keer de data op en slaan deze vervolgens op in Github: https://github.com/flanders-architecture-institute/vai_abs_public/tree/main/mappings/keywords
Publiceren van rechtenvrije beelden in Wikimedia Commons
Binnen Persistente Architectuur hebben we 61 rechtenvrije beelden uit de twee beschreven collecties gepubliceerd op Wikimedia Commons. Deze beelden zijn gekoppeld aan een Wikidata-item en gestructureerd terug te vinden via onderstaande SPARQL-query (De resultaten kunnen ook rechtstreeks worden bekeken op https://w.wiki/wZr):
#defaultView:ImageGrid
SELECT ?object ?objectLabel ?beeld
WHERE {
# Hier zeggen we: Het object moet behoren tot de collectie (P195) van het Vlaams Architectuurinstituut (Q77201544)
?object wdt:P195 wd:Q77201544 .
# Aan het object moet ook een beeld gekoppeld zijn.
?object wdt:P18 ?beeld .
# Dit is een standaard SPARQL-regel in Wikidata. Gewoon kopiëren.
SERVICE wikibase:label { bd:serviceParam wikibase:language "nl,en". }
}
Voor het opladen van de beelden maakten we gebruik van de tool Pattypan. Zie ook de case study die hierover is verschenen op CEST. De tool Pattypan laat toe om afbeeldingen in bulk op te laden m.b.v. een spreadsheet. Deze spreadsheet laat toe om metadata voor Wikimedia Commons mee te sturen. Aangezien wij ons concentreerden op metadateren in Wikidata, stuurden we in de spreadsheet enkel essentiële metadata mee, of metadata die we niet meteen in een goede vorm in Wikidata kregen (zoals de opschriften op het object). We maakten hiervoor gebruik van het standaard metadatasjabloon voor ‘Artwork’. De beelden werden in twee batches opgeladen. Eén voor de Jos De Beer collectie en één voor het Engetrim archief.
Jos De Beer beelden
| Veldnaam | Beschrijving | Status | Voorbeeld |
|---|---|---|---|
| path | bestandslocatie van het beeld | verplicht | C:\Users\Wim Lo\Desktop\Jos de Beer\jpgsrgb\obj-0002462_0038-JDB_img-001_B.jpg |
| name | de naam van het beeld (zelfde waarde als voor het Wikidata label) | verplicht | Item from the Jos De Beer collection, ref. obj-0002462 |
| title | = name | verplicht | = name |
| description | beschrijving van het beeld | optioneel | Tekening betreffende het ontwerp voor een volière op het kasteeldomein 'Hof ter Beke' te Antwerpen door Joseph Schadde (Adres: Terbekehofdreef 13, Boomsesteenweg) |
| date | creatiedatum | optioneel | 1859 |
| dimensions | afmetingen van het origineel | optioneel | 31 * 40,4 cm |
| inscriptions | opschriften op het origineel | optioneel | (Rechteronderhoek): Esquisse d'un Projet pour la construction d'une/ Volière à établis à la campage (sic) de Monsieur/ J. Ullans-Geelhand à Wilryck/ Anvers le 15 Mai 1859./ Jos Schadde/ Architecte |
| source | onze persistente URI | optioneel | http://data.flandersarchitecture.be/object/obj-0002462 |
| wikidata | ID van de Wikidata-entity | optioneel | Q86515764 |
Het resultaat kan bewonderd worden op https://commons.wikimedia.org/wiki/File:Item_from_the_Jos_De_Beer_collection,_ref._obj-0002462.jpg. Merk op dat verschillende velden op deze pagina op Wikimedia Commons niet zijn meegestuurd via het spreadsheet: de velden ‘Artist’, ‘Object type’, ‘Medium’, ‘Collection’ en ‘Accession number’. Ze zijn allemaal automatisch overgenomen uit Wikidata via het Wikidata ID. Zowel voor de auteur als voor de collectie krijg je bovendien nog eens extra informatie.
Engetrimbeelden
In dit geval voegden we nog een kolom toe:
| Veldnaam | Beschrijving | Status | Voorbeeld |
|---|---|---|---|
| categories | categorieën binnen Wikimedia Commons | optioneel | Architecture of Antwerp;Architectural drawings from Belgium (dus twee categorieën) |
- Een Engetrimbeeld: https://commons.wikimedia.org/wiki/File:Item_from_the_Engetrim_archive,_ref._obj-0002023.jpg
- De categorie 'Architecture of Antwerp': https://commons.wikimedia.org/wiki/Category:Architecture_of_Antwerp
Uitweiding: Problemen met licenties
In totaal hebben we 67 beelden opgeladen: 34 uit het Engetrim archief en 33 uit de collectie van Jos De Beer. De Wikidata query geeft echter slechts 61 resultaten terug. Dit komt omdat enkele beelden door Wikimedia Commons gebruikers zijn verwijderd. Dit werd als volgt gecommuniceerd door een lid van de community:
Het probleem was dat er geen copyright-tag was toegevoegd aan de beelden. Dit moest gebeuren via de kolom ‘license’ in Pattypan. Helaas konden we de tool Pattypan niet gebruiken om bestaande foto’s te updaten, dus moesten we dit manueel doen door een copyright tag (in ons geval https://commons.wikimedia.org/wiki/Template:PD-art-70). Na een week waren de beelden echter al verwijderd.
De licentie-informatie was meegegeven via Wikidata, maar dit volstaat dus niet: beelden dienen ook in Wikimedia Commons zelf getagd worden met een licentie-tag. Het verhaal heeft ook een positieve kant. De waarschuwing kwam van een Wikibot (een script dat automatisch data op Wikimedia Commons beheert) die afbeeldingen zonder licentie controleerde. Waar mogelijk, voegde deze wikibot zelf de correcte licentie-tag toe op basis van de overlijdensdatum van de auteur, zonder dat we dit zelf moesten doen. Dergelijke acties worden steeds gelogd. Op deze pagina vind je een overzicht van de wijzigingen die werden doorgevoerd aan de licentie-informatie van obj-0002023 op 15 juli 2020. In dit geval werd de licentietag '{{PD-scan|PD-old-auto|deatyear=1939}}' toegevoegd.
Evaluatie
Voordelen van collectiedata op Wikidata
Dat Wikidata voordelen heeft is duidelijk. Ook Europeana maakt ondertussen gebruik van Wikidata om zijn vocabularies te verrijken, maar gelden de voordelen ook voor informatie over collectieobjecten of archiefbestanddelen zelf? Bovenaan deze gevalstudie noteerden wij vijf argumenten om Wikidata uit te testen. Wat vinden wij daar nu van na de gevalstudie?
query.wikidata.org
De mogelijkheid van flexibele SPARQL-queries – een mogelijkheid waarover we standaard niet beschikken in ons archiefbeheersysteem – is al bijzonder nuttig gebleken. Een lijst van zaken waarvoor we queries hebben gebruikt valt na te lezen op deze pagina. Door de query-service kunnen we gebruikers nu ook overzichten aanbieden op onze collectie de kunnen worden gedownload in verschillende formaten, zoals JSON, CSV, TSV etc. Bijvoorbeeld:
- Onze archieven per archiefvormer in het Nederlands: https://w.wiki/r9K
- Onze archieven per archiefvormer in het Engels: https://w.wiki/r9H
- Onze detailbeschrijvingen van objecten: https://w.wiki/txN
- Onze detailbeschrijvingen van archiefbestanddelen: https://w.wiki/txR
Integratie met andere informatie
Af en toe kwamen we voordelen tegen van de integratie van informatie. Reasonator is bv. een zijproject van Wikidata om de gegevens op een wat meer ‘mensvriendelijke’ manier aan gebruikers te presenteren. De Reasonator-fiche van Jozef Schadde geeft een goed voorbeeld van wat integratie via Wikidata vermag. Wij voegden gegevens over zijn archiefrelict en zijn tekeningen uit onze collectie toe, maar verder is de meeste informatie door anderen toegevoegd. De foto van de architect komt niet uit het VAi, maar van het Rijksmuseum in Nederland. De verwijzingen naar de kerken die de architect maakte waren al aanwezig. Deze beschrijving is dus veel rijker dan wat het VAi momenteel aanbiedt.
De informatie die wij toevoegden is nu ook vindbaar binnen een groter geheel. Wie binnen de website van Crotos zoekt naar architectuur, zal nu tekeningen uit de VAi-collectie zien opduiken in de zoekresultaten. Of wie zoekt op graveur Jozef Linnig, zal niet langer enkel beelden vinden uit het Prentenkabinet van de Universiteit Antwerpen, maar ook diens werken uit de verzameling van Jos De Beer in het VAi, naast stukken uit bv. het Felixarchief.
De mate waarin informatie kan worden geïntegreerd zal vooral afhangen van de mate waarin de erfgoedsector in de toekomst datareeksen zal opbouwen in Wikidata. Hoe meer materiaal op Wikidata en Wikimedia Commons, hoe groter het potentieel wordt om aan verdergaande integraties te kunnen denken.
Wereldwijd samenwerken
Wij hebben gemerkt dat werk van het VAi in Wikidata ook door anderen wordt opgepikt en opgevolgd. Onderstaand screenshot toont de bewerkingsgeschiedenis voor het item ‘Gewassen pentekening’: https://www.wikidata.org/w/index.php?title=Q85620896&action=history
'Hannahtsas' en 'WimLo' zijn VAi-medewerkers. Na bewerking door 'Hannahtsas' is een extern ID toegevoegd, is de beschrijving verder geperfectioneerd door ‘Romaine’ en is er een Arabische vertaling toegevoegd door een bot. Een kort overzicht van al onze termen rond ‘productietechnieken’ die al in het Arabisch beschikbaar zijn vind je hier: https://w.wiki/tfy. Daarnaast hebben we gemerkt dat heel veel van onze uploads later ten goede zijn aangepast:
- beelden kregen licentie statements
- objecten die in plaats van een 'creatiedatum' een 'startdatum' van ons kregen (een verkeerd property dus), werden automatisch door een Wikipediaan aangepast
Geconnecteerd met Wikipedia en de Wikimedia Foundation
We hebben nog geen rechtstreekse voordelen ondervonden van deze eigenschap. In eerste instantie zal het vooral aan het VAi zijn om op de pagina’s van architecten op Wikipedia het bestaan van archieven duidelijk te maken. Daarnaast zien we een interessante ontwikkeling rond 'Wikidatadriven infoboxes' op Wikipedia. Vooral op de Franstalige Wikipedia staat men hier al redelijk ver in. Zo heeft het Franstalige Wikipedia-artikel over architect Emiel van Averbeke een infobox die datadriven is. Daar kan worden ontdekt dat archieven van de architect worden bewaard in de Archives d'architecture moderne (tegenwoordig CIVA), het Letterenhuis en het Vlaams Architectuurinstituut. Sowieso gaan we ervan vanuit dat aanwezigheid van data op Wikidata vanuit strategisch oogpunt interessant is, en ook tout court een taak is voor het Vlaams Architectuurinstituut. Het strategisch belang blijkt nu we ook op andere vlakken samenwerking met Wikimedia-tools uittesten. Zie hiervoor het project Wiki Women Design.
Wikidata = vrije data
Via de website Crotos (http://zone47.com/crotos/) zijn de afbeeldingen die wij geüpload hebben nu ook doorzoekbaar. Ondertussen heeft meemoo aangekondigd te werken aan een public domain tool, waarmee snel kan worden opgezocht of een auteur zich in het publiek domein bevindt. Deze tool zal werken op basis van Wikidata en dus ook gebruik maken van onze uploads van actoren.
Zoals gezegd kunnen we ervan uitgaan dat steeds meer tools zullen worden ontwikkeld op Wikidata, precies door de omvang en het bereik van de dataset.
En waarom niet voor een andere aggregator kiezen?
Wikidata is niet de enige data-aggregator. Waarom kiezen we bv. voor Wikidata en niet voor een aggregator als Europeana of Archives Portal Europe? Wat zijn - met deze platformen als vergelijkingspunt - argumenten om Wikidata NIET te gebruiken?
Data kunnen niet offline worden bewaard
Alles staat automatisch online, voor iedereen bereikbaar. Dit vormt op dit moment geen echt probleem, omdat het VAi data die niet publiek mogen worden gemaakt ook niet zal publiceren op een aggregatorplatform. In de toekomst zijn er mogelijk wel gebruiksscenario’s mogelijk waarbij we niet-publieke data gaan delen in afgesloten platformen. In zo’n scenario is Wikidata zeker niet het geschikte platform, maar moeten we kijken naar andere oplossingen, bv. een Wikibase, een soort van privé-Wikidata.
Het datamodel van Wikidata voldoet niet
Het datamodel is extreem flexibel en kan altijd worden uitgebreid met properties. Toch hebben we tijdens het project gemerkt dat je toch vaak creatief zult moeten omspringen om je data om te plooien naar een richting die de Wikidata community al is uitgegaan. Dit is echter nooit een heel groot probleem gebleken. De belangrijkste gegevens konden zeker worden opgeladen en voor velden waarbij dit niet kon, kunnen we op termijn nieuwe properties aanvragen. Zolang er een koppeling is met onze collectiewebsite, kunnen gebruikers bovendien altijd langs die weg de volledige gegevens opvragen.
Wanneer de structuur niet geschikt was, konden we ook zelf in één keer de aanpassingen doen. Opvallend was bv. dat er in Wikidata al lijstjes met archieftermen aanwezig waren, maar vaak niet 100% correct waren opgebouwd. In dit geval hebben we zelf de aanpassingen gedaan en de aanpassingen gestaafd door koppelingen toe te voegen naar de RiC Ontology, bv. in https://www.wikidata.org/wiki/Q59221146. Door koppelingen te leggen met RiC hopen we op die manier ook gemakkelijker de archiefdata vanuit Wikidata om te zetten naar een RiC-formaat.
Soms waren termen niet aanwezig en hebben we ze toegevoegd, bv. de term tekenlinnen. Waar mogelijk koppelden we met externe authorities.
De data in Wikidata zijn niet betrouwbaar
Het klopt dat iedereen data kan aanpassen en dat je data kunnen evolueren in een richting die jij niet wilt of hebt voorzien. Wikipedianen kunnen ook fouten maken. De filosofie is echter dat wijzigingen meestal eerder verbeteringen dan verslechteringen zijn, en voor Wikipedia lijkt dit meestal te kloppen. Je kunt je ook de vraag stellen of het niet de taak van een efgoedinstelling zou kunnen zijn om de data in Wikidata te beheren, managen en betrouwbaar te houden? Twee modellen zijn immers mogelijk: of de erfgoedinstelling deelt zijn data in een afgeschermde, beschermde omgeving, of de erfgoedinstelling beheert actief mee data in Wikidata en zorgt mee voor de kwaliteit van het datapakket in Wikidata.
Een andere afweging die je moet maken is het doel van de aggregatie:
- Is betrouwbaarheid de hoofdbetrachting en wil je dat de data blijven zoals ze zijn opgeladen? Dan bestaat het risico dat de data traag zullen evolueren, niet veel zullen worden gebruikt en op termijn niet meer up to date zijn.
- Is vindbaarheid, deelbaarheid en bruikbaarheid de hoofdbetrachting? Wil je samen met een grotere groep aan datareeksen werken? In dat geval is Wikidata het perfecte kanaal, maar zul je moeten accepteren dat je niet meer alleen de controle over de data behoudt.
Tijdens Persistente Architectuur ging het VAi uit van volgende opstelling:
- De betrouwbare data zijn te vinden op onze collectiewebsite.
- De bruikbare, geaggregeerde data zijn te vinden op Wikidata.
- Betrouwbare en bruikbare data worden gekoppeld via de persistente URI.
Is de Wikimedia Foundation wel geïnteresseerd in massale hoeveelheden collectiegegevens op Wikidata?
Dit is een belangrijk risico. Op dit moment lijkt de Wikimedia community er geen graten in te zien dat archiefdata op Wikidata worden geplaatst. Het aantal archiefbeschrijvingen wordt momenteel bv. ruimschoots overtroffen door het aantal gespecialiseerde wetenschappelijke artikels in Wikidata. Toch bestaat er zeker een kans dat Wikidata op een bepaald moment strakkere richtlijnen gaat stellen over de data die op het platform mogen komen en welke niet. De openheid van het platform laat dan in ieder geval toe dat de data in machineleesbaar formaat kunnen worden geëxporteerd.
De Wikimedia Foundation accepteert enkel vrij herbruikbaar beeldmateriaal
Een zeer belangrijk nadeel voor de VAi-collectie zijn de restricties op beeldmateriaal, dat ofwel in het publieke domein dient te zijn, ofwel gepubliceerd onder een vrije licentie. Aangezien de collectie van het VAi relatief recent is, zal het nog heel lang duren vooraleer reproducties op Wikimedia Commons zullen verschijnen. De rechtenbeperkingen van Wikimedia Commons voor beelden vormen voor het VAi ongetwijfeld één van de grootste nadelen om Wikimediaplatformen te kiezen als aggregator.
Evaluatie: Werken met Python scripts
Het ontwikkelen van de Python scripts om data uit het archiefbeheersysteem om te zetten naar quickstatements bleek meer werk dan ingeschat. De noodzaak om termen steeds weer te mappen met Wikidataconcepten maakt alles in zekere mate complex. Het is de vraag in welke mate deze scripts in de toekomst onderhouden kunnen blijven worden binnen het VAi. Op dit moment zit de ontwikkeling en de kennis ervan bij één persoon, wat een aanzienlijk risico is. Op termijn is de huidige situatie dus niet duurzaam.
Om RDF-publicatie van archiefdata duurzaam mogelijk te maken voor het VAi en bij uitbreiding de hele Vlaamse erfgoedsector (of dit nu is op Wikidata, Europeana of Archives Portal Europe) kan er dus best worden gedacht aan centrale oplossingen om data uit archiefsystemen om te zetten naar verschillende formaten (bv. RiC-RDF, Wikidata-RDF, APE-EAD enz.) Met zo'n centrale oplossing zou het in principe mogelijk moeten zijn om vanuit het archiefbeheersysteem slechts één migratie te moeten laten plaatsvinden naar een RDF-formaat. Die centrale oplossing moet niet alleen een platform bieden, maar ook dienstverlening op maat om de migratie naar het centrale platform mogelijk te maken.
Conclusie
Deze use case voor Wikidata beschouwen we als erg veelbelovend. Indien er moet gekozen worden tussen Wikidata, Archives Portal Europe of Europeana als aggregatieplatform, dan wijzen meerdere argumenten op dit moment naar Wikidata:
- Het is eenvoudiger: Wikidata biedt bijzonder rijke documentatie om je op weg te zetten. Wikidata ‘democratiseert’ als het ware moeilijke technologieën als RDF voor iedereen. De tools worden zoveel mogelijk ontwikkeld met oog op gebruiksvriendelijkheid, zie bv. het SPARQL-endpoint dat suggesties biedt.
- Het is laagdrempeliger: Er zijn geen procedures die je moet doorlopen om data te publiceren. Je kunt bij wijze van spreken meteen beginnen.
- Wikidata kan in principe alle informatie in zich opnemen. Archieven, erfgoed, maar ook personen, gebeurtenissen, gebouwen, planten, geologische tijdperken, fictieve personages, softwarepakketten, plastieksoorten enz. Het potentieel voor dataverrijking en integratie is daarmee zeer groot.
- Het heeft een internationale scope: In Europeana vind je Europees erfgoed, in Wikidata vind je potentieel al het erfgoed van de wereld.
- Wikidata heeft een erg groot bereik door de koppeling met Wikimedia Commons en Wikipedia.
- De kans dat vele nuttige applicaties worden ontwikkeld op Wikidata is heel groot.
Maar er zijn ook enkele nadelen. Voor een relatief recente erfgoedcollectie als die van het VAi is het belangrijkste nadeel de beperkte mogelijkheid om gedigitaliseerde bestanden op te laden door restricties op rechten. Ook kan info die we wel met collega’s uit de sector willen delen, maar daarom niet meteen publiek hoeft worden gemaakt (archiefwaarderingen bv.) niet op Wikidata worden gedeeld. Een ander risico is vooralsnog de beperkte adoptie van de archiefsector van Wikidata. Op een meer praktisch niveau blijft de technische expertise die nodig is om de data te delen – ondanks alle inspanningen van de Wikimedia Foundation om alles zo gebruiksvriendelijk mogelijk te houden – wellicht ook teveel gevraagd voor kleine of middelgrote archiefinstellingen. Een organisatielaag tussen de erfgoedinstelling en Wikidata is in dat geval wenselijk.
Is Wikidata iets dat blijft? ... De kans is groot! En dat is toe te juichen, want de opportuniteiten voor de erfgoedsector en de doelgroepen zijn groot. Of er komt een model waarbij erfgoedinstellingen rechtstreeks data in Wikidata uploaden, of er komt een model waarbij de info via een tussenliggende instantie op Wikidata komt. In beide gevallen heeft de erfgoedgemeenschap er belang bij om de kwaliteit van de data in Wikidata hoog te houden en er dus op aanwezig te zijn.
Een laatste afsluitende gedachte: Hoe het zich ook ontwikkelt, het is als erfgoedinstelling geen verloren energie om te starten met Wikidata. Het lijkt immers zeker dat de toekomst van aggregatieplatformen er één van Linked Open Data en RDF is. Zonder twijfel is Wikidata een uitstekend platform om RDF en zijn query-taal SPARQL onder de knie te krijgen. Heb je als erfgoedinstelling al je data in Wikidata gekregen? Dan ben je wellicht klaar voor elk RDF-platform.