CultURIze-workshop met OKBE

  • Verslag

Op 26 november 2019 stelden meemoo en Open Knowledge Belgium (OKBE) CultURIze voor, een tool waarmee collectiebeheerders zelf persistente URI’s kunnen beheren voor de ontsluiting van hun collectie op het web. CultURIze is een volledig herwerkte versie van de resolver, die meemoo ontwikkelde samen met de Vlaamse Kunstcollectie.

Persistente URI’s

De voorgeschiedenis van CultURIze gaat terug tot 2014, toen meemoo het idee opvatte om een oplossing te zoeken waarmee collectiebeheerders zelf persistente URI’s kunnen beheren. Het gebruik van persistente URI's en een resolver tool, zoals CultURIze, lost het probleem van linkrot op. Dit probleem ontstaat wanneer online koppelingen (bv. tussen verschillende webpagina's en/of data) worden verbroken doordat webadressen wijzigen.

Een persistente URI (Uniform Resource Identifier) is een webadres dat een eenvoudige en leesbare vorm heeft, stabiel of onveranderlijk is en een beeld of metadatarecord op lange termijn toegankelijk maakt. Op die manier kunnen ze content en metadata op een duurzame manier ter beschikking stellen van erfgoedplatformen zoals Europeana, Erfgoedplus of Erfgoedinzicht.

Persistente URI’s zijn een belangrijk technisch instrument om collectiedata en content dynamisch te verwerken in websites en mobiele toepassingen. Ze zijn dus heel nuttig voor publiekstoepassingen, maar ook om collectiedata en content op een efficiënte manier bruikbaar te maken in interne museumprocessen.

Resolvers

In de onderzoeks- en bibliotheekwereld bestaat er een traditie om persistente URI’s van publicaties te beheren in centrale resolverservices. Dit zijn centrale databanken waarin auteurs voor hun publicatie een persistente URI aanvragen en deze koppelen aan de locatie waar de publicatie toegankelijk is. Publicaties zitten verspreid over verschillende bibliotheekcollecties. Daarom zijn persistente URI’s voor bibliotheken een evidente oplossing om hun publicaties op een efficiënte manier op verschillende webplatformen toegankelijk te maken. Handle.net is in dit domein een referentie.

Voor musea zijn persistente URI’s pas relevant geworden bij het ontstaan van grote aggregators zoals Europeana. Een centrale resolverservice opzetten in een versplinterde sector als de museumsector, leek ons niet haalbaar. Daarom zijn we vanaf het begin op zoek gegaan naar een decentrale oplossing en een tool die ook door kleine musea makkelijk te gebruiken is. Initieel onderzochten we enkele jaren het spoor van een eenvoudige webapp, maar in de zomer van 2018 zijn we terug naar de tekentafel gegaan. In samenwerking met vier studenten die deelnamen aan de Open Summer of Code 2018 van Open Knowledge Belgium hebben we dan een nieuwe oplossing uitgedacht.

Voor die oplossing behielden we een aantal principes die we in de resolver toepasten, zijnde een voorkeur voor ‘cool URI’s’ en de ‘EU Guidelines on persistent URI’s’. Daarbij hadden we onszelf de volgende randvoorwaarden opgelegd die we uit het voortraject hadden geleerd:

  • De tool gebruikt generieke technologie/componenten die ook buiten de erfgoedsector gebruikt worden.

  • De tool moet zo weinig mogelijk zelfgeschreven code bevatten, waardoor het beheer van die code eenvoudig en goedkoop blijft.

  • De tool is grondig getest en gedocumenteerd, vooraleer we hem ter beschikking stellen.

  • Gebruikers kunnen het eigenlijke beheer van de koppelingen tussen content en persistente URI’s in hun vertrouwde rekenblad doen.

  • Het beheer van de tool zelf is niet afhankelijk van meemoo, maar wordt gedragen door de gebruikers van de tool.

De demonstratie

De oplossing was uiteindelijk niet één gesloten applicatie, maar een toolchain waarbij vier stappen doorlopen worden:

Eerst maak je een rekenblad waarin je de URL’s (Uniform Resource Locators) voor de content die je toegankelijk wil maken, koppelt aan een persistente URI. Dat rekenblad, in CSV-formaat, moet een aantal verplichte velden (kolomnamen) hebben, om verderop in de toolchain correct verwerkt te kunnen worden. Collectiebeheerders hebben daarnaast de mogelijkheid om eigen velden toe te voegen die niet verwerkt worden door de CultURIze-app.

Met behulp van de CultURIze-desktopapplicatie zet je dat rekenblad vervolgens om in een configuratiebestand voor je website. CultURIze ondersteunt Apache- en Nginx-webservers. De koppelingen tussen URI's worden beheerd in een webserverconfiguratiebestand (.htaccess voor Apache, .conf bestand voor Nginx).

De CultURIze-desktopapplicatie laadt dit configuratiebestand op naar je Github-repository die gekoppeld is aan je webserver.

Je moet je server zo configureren dat iedere wijziging automatisch opgehaald wordt uit de GitHub-repository. De webserver haalt vervolgens periodiek het configuratiebestand op en activeert de nieuwe persistente URI’s.

Implementatie

Naargelang je eigen noden en middelen kan je deze vier stappen op verschillende manieren implementeren. Ben je zelf vertrouwd met Github en hebben webservers geen geheimen voor je? Dan is het eenvoudig om zelf die vier stappen te implementeren.

Werk je voor je IT-infrastructuur samen met een technische partner of je interne IT-dienst? Dan kan je het beheer van je Github-repository en server uitbesteden en de kost eventueel delen met andere musea.

Beheersmodel

Een laatste randvoorwaarde voor de CultURIze-tool was om ook het beheer van de tool zelf ‘persistent’ te maken. Daarvoor zochten we naar een oplossing waarbij het beheer van de tool niet afhankelijk was van meemoo, maar gedragen wordt door de gebruikers van de tool.

Om te onderzoeken wat dan wel een duurzaam model zou kunnen zijn, hebben we een project opgezet met Open Knowledge Belgium, waarin we beheersmodellen van (opensource) ontwikkelprojecten vergeleken en analyseerden. Het project ontving als innovatief partnerproject een subsidie van de Vlaamse overheid. De resultaten van het onderzoek deelden we in het voorjaar van 2020 met de cultureelerfgoedsector.

De documentatie van de tool vind je hier. De volledige presentatie van 26 november bekijk je hieronder. Ben je geïnteresseerd in een demo? Stuur dan een mail naar Bert Lemmens.

We halen de pagina op, even geduld...