CROW | Versiebeheer in LinkedData

Binnen CROW hebben we ook te maken met versieproblematiek. Zijn we nu bijvoorbeeld CROW2.0 of CROW3.0!? En ja, ook onze documenten hebben namen zoals de titel van deze blog. Nu is dit bij documenten al lastig, maar moet je nagaan als dit op data van toepassing is. Daar wil je niet alleen de dataset zelf beheren, maar ook de data in die sets. Nu zou je denken dat iemand daar toch wel iets op gevonden heeft… en dat klopt! Alleen hebben meerdere (en veel meerdere) partijen daar wat op gevonden en dat maakt het geheel wederom onoverzichtelijk. Afijn, wij liepen hier dus ook tegenaan toen we onze (IMBOR) Linked Data-sets moesten gaan beheren. Hier ging het dus alleen maar om Linked Data (LD) en niet alle vormen van data. How hard can it be… Je voelt hem al aankomen: zo hard als Lonsdaliet #nerdjoke.

Het bleek dus niet zo eenvoudig om antwoord te geven op de vraag hoe we versiebeheer moesten gaan voeren op onze Linked Data-sets. Vandaar dat we hebben getracht om eerst maar eens een overzicht te maken van de complexiteit, en het speelveld uiteen te zetten. Het doel was een situatieschets van de uitdagingen met betrekking tot versiebeheer binnen Linked Data (LD). We wilden de verschillende mogelijkheden beschrijven, op basis waarvan per situatie een inschatting gemaakt kan worden voor de best mogelijke optie. We hebben geen waardeoordeel gegeven omdat er in de sector al genoeg mensen zijn die hun mening als de absolute waarheid verkondigen. Uiteindelijk is het objectieve stuk dus een beetje uit de hand gelopen. In deze blog een sneak-peak, maar voor de echte liefhebber hebben we het complete overzicht op de CROW-GitHub geplaatst.

We ontdekken meer en meer de LD-technieken (RDF en SPARQL). Dit gaat leiden tot gegevens uit verschillende domeinen die online worden gepubliceerd en beschikbaar komen voor gebruikers. Het dynamische karakter is een belangrijk onderdeel van LD. De gegevens én het schema (a.k.a. het model, a.k.a. het datamodel, a.k.a. het metamodel, a.k.a. de vormenstoof) van de datasets zijn voortdurend in ontwikkeling. Vaak volstaat de laatste versie, maar toch is er nuttige informatie aanwezig in, tussen of over eerdere versies.

Versiebeheer voor RDF en ontologieën, is … lastig… klaarblijkelijk. Op de W3C (de eindbazen) site hierover wordt als eerste zin gezegd: “Version management for RDF vocabularies, and ontology evolution in particular is an ongoing research problem” . There you have it… we zijn er nog niet uit! Desondanks zijn er wel andere wannabe-eindbazen die het zogenaamd precies weten. ¿¡Qué!? #hoedan. Ondanks deze uitdaging, wordt er wel gedeeld dat het beheren van meerdere versies van datasets essentieel is. Als belangrijkste is men het er ook over eens dat niet één enkele aanpak in alle situaties geschikt is. “Doet iemand die open deur ff dicht?” Dit gezegd hebbende, kan eenvoudige versie-identificatie voldoen aan de behoeften van veel gebruikers. Voor veel gebruikers kan “menselijk leesbare” versie-informatie minstens zo waardevol zijn als “machine leesbare” versie-informatie. Vanuit de W3C wordt aangedrongen om de menselijke bruikbaarheid dan ook maar eens eerst te beschouwen als een kritische factor bij het kiezen van een versiebeheerstrategie.

In essentie (en voor degene die niet de uitgebreide analyse willen lezen waar bloed, zweet en tranen inzitten op GitHub) komt het neer op het volgende: er zijn drie basisstrategieën:

Full Materialization / Independent Copies

Deze wordt het meest toegepast en is simpel uit te leggen als: gewoon iedere versie in zijn geheel opslaan met een opgehoogd nummertje.

Deltabenadering / Change-Based

Met deze strategie sla je alleen de wijzigingen op t.o.v. een vastgestelde (vaak de eerste) versie.

Geannoteerde triples / Timestamp-Based
Met deze strategie zet je bij elke triple een geldigheidsduur (begin en eind) en kan dus de versie worden gereconstrueerd.

Hybride strategieën

Het combineren van de bovenstaande strategieën om de voordelen te benutten en de nadelen te elimineren. Een voorbeeldcombinatie is het gebruik van de Deltabenadering en geannoteerde triples. Systemen slaan opeenvolgende delta's op, waarin elke triple wordt geannoteerd met een versie.

En dan moet je gaan kiezen welke de juiste keus voor jou is. Nou daarvoor moet je (ik zou zeggen: uiteraard) weten wat je er mee wilt. Wat wil je weten van de datasetversies. Hiervoor bestaan voor gedefinieerde query-categorieën. Ik zal het lijstje hieronder opnemen voor degene die middelmatig geïnteresseerd zijn:

“Moderne versie-materialisatiequery's” (MVMQ) vragen om een volledige actuele versie van de huidige versie. Voorbeeld: Geef me alle informatie over alle boeken die op dit moment in de bibliotheek staan.
“Moderne single-versiequery's” (MSVQ) worden aan de huidige versie gesteld. Voorbeeld: Hoeveel boeken staan er op dit moment in de bibliotheek.
“Historische versiematerialisatie query” (HVMQ) betreft het vragen om een volledig versie uit het verleden. Voorbeeld: Geef me alle informatie over alle boeken die gisteren in de bibliotheek stonden.

“Historische single-versiequery's” (HSVQ) bevragen binnen één versie uit het verleden. Voorbeeld: Hoeveel boeken stonden er gisteren in de bibliotheek.
“Delta-materialisatiequery’s” (DMQ) vragen om een volledige delta op te halen. Voorbeeld: Welke boeken zijn teruggebracht of uitgeleend tussen 18 januari en 26 februari?
“Single-deltaquery's” (SDQ) zijn query's die in twee opeenvolgende versies worden uitgevoerd. Voorbeeld: Welke boeken zijn teruggebracht of uitgeleend tussen gisteren en nu?
“Cross-deltaquery’s” (CDQ) gaan over vragen binnen verschillende wijzingen van de dataset. Voorbeeld: Hoe vaak is boek ‘x’ uitgeleend, dan wel teruggebracht?
“Cross-versiequery's” (CVQ) gaan over vragen op verschillende versies van de dataset, waardoor informatie in meerdere versies moet worden opgevraagd. Voorbeeld: Welke boeken waren aanwezig in de bibliotheek eergisteren, gisteren en vandaag?

“Versie-info-query’s” (VIQ) gaan over vragen naar versies in het gehele archief. Voorbeeld: Wanneer was boek ‘x’ aanwezig in de bibliotheek?
“Versie-info-change-query’s” (VICQ) gaan over vragen van verandering tussen twee verschillende opeenvolgende versies. Voorbeeld: Op welke dagen is boek ‘x’ uitgeleend of teruggebracht?

… vet hè?

Naja, dit dus en nog veel meer staat heel uitgebreid en objectief onderbouwd op onze CROW GitHub. Hiermee kan eenieder zich verdiepen en beter voorbereid zijn op discussies.

Een conclusie, hoor ik je denken. Samengevat: de keuze voor een versiebeheerstrategie is altijd maatwerk, er is geen one-size-fits-all-oplossing. Het doel van ons was het uiteenzetten van de mogelijkheden en laten zien wat het speelveld is. Alle oplossingen hebben voor- en nadelen in verschillende situaties. Er is geen oplossing die voor alle gebruiksdoeleinden geschikt is, brede consensus geniet, én voor alle LD-verwerkende systemen geschikt is. De eerste stap is het bepalen van de use-case: wat voor doel dient het versie beheer. Dit kan uitgewerkt worden in queryvragen. Deze kunnen vervolgens onder één van de categorieën geschaard worden en dan kan gecheckt worden of de categorisering klopt. Vervolgens kan een bijpassende publicatiewijze en technische implementatie afgewogen worden. Hier is geen vaste keus voor. Zelfs de literatuur geeft verschillende adviezen. Het belangrijkste hier is een onderbouwde afweging maken en deze vastleggen, zodat hier later overwogen op teruggekomen kan worden.