Versiebeheer met behulp van PROV

== Conceptual Friday 26 februari: Versiebeheer met behulp van PROV ==
*Gerard Kuijs heeft een gegeven over het gebruik van PROV. (Deze presentatie zal t.z.t. opgenomen worden op deze site).
*Marco Brattinga brengt een stukje tekst in met betrekking tot het omgaan met versies bij de opslag van triples en een URI-strategie, zoals dit nu wordt gebruikt voor de begrippen op brk.kadaster.nl.
*Ook komt de versie-strategie van UK government aan bod: versioning-uk-government.
===Aandachtspunten en voorstellen===
# Wat zijn precies de functionele requirements, de use-cases die we willen bedienen? Dit vereist verdere uitwerking;
# We hebben een vocabulaire nodig voor herkomstinformatie. PROV-O lijkt hiervoor de geschikte kandidaat. We zullen verder moeten uitwerken hoe we precies gebruik maken van PROV-O. Daarbij lijkt het gebruik van prov:Bundles interessant. Daarbij is de link met named graphs (zie volgende punt) snel gemaakt;
# We hebben een werkwijze nodig hoe we versies opslaan, oftwel: verzamelingen van triples. Hiervoor zijn grofweg twee methoden beschikbaar: reification en named graphs. Deze methoden zijn ook benoemd in de versie-strategie van de UK government. Het gebruik van named graphs heeft ook onze voorkeur;
# We hebben een URI-strategie nodig voor versies. Daarbij lijkt in ieder geval formele historie onderdeel te worden van (bepaalde) URI's, te weten de "doc"-URI's. Materiele historie zou je ook kunnen opnemen, maar dan in de "id"-URI's. Aangezien je echter meerdere perspectieven kunt hebben op materiele historie, ligt het meer voor de hand om materiele historie "gewoon" op te nemen in de ontologie, en via URI-parameters deze uit te vragen.
===Inbreng brk.kadaster.nl===
====Graphs en versiebeheer====
De gegevenscatalogus levert beschrijvingen in de vorm van RDF datasets. Conform Linked Data concepten, bestaan deze datasets uit triples. In de loop van de tijd kunnen de beschrijvingen echter wijzigingen, en het is ook denkbaar dat meerdere bronnen beschrijvingen geven van dezelfde gegevens. Het is dan ook van belang dat van elke triple zelf ook duidelijk is wat de herkomst van deze triple is. Met herkomst bedoelen we hier: de volledige context van de triple, dus zowel auteur, maar ook tijdstip van geldigheid, tijdstip van registratie, etc). Hiervoor zijn grofweg twee mechanismen voor handen:
* Reification, waarbij elke triple zelf als “uitspraak” wordt vastgelegd, waarna vervolgens aan deze “uitspraak” herkomstinformatie gekoppeld kan worden.
* Named graphs, waarbij een verzameling triples met dezelfde herkomstinformatie bij elkaar wordt geplaatst in één named graph. De herkomstinformatie wordt vervolgens aan de named graph gekoppeld.
Beide varianten kennen voor- en nadelen. Hoewel de best-practices niet eensluidend zijn, lijkt de consensus te zijn om gebruik te maken van named graphs. Nadeel bij deze aanpak is wel, dat de performance bij het benaderen van een zeer groot aantal named graphs kan tegenvallen. Een bekend probleem is het achterhalen of een gegeven nog actueel is: hiervoor is het nodig om alle triples, zowel actuele als historische triples door te nemen. Een oplossing hiervoor is het bijhouden van een actuele graph, waarin verwezen wordt naar de graph waarin het actuele gegeven nog aanwezig is. Als een gegeven NIET meer actueel is, dan wordt het ook niet meegenomen in de actualiteitsgraph. Dit is weergegeven in onderstaand figuur.
Elke laag betreft een named graph met triples (subject-predicate-object). Deze triples zijn gegroepeerd naar het subject van de triple. Zo kent het voorbeeld vier subjecten en bijbehorende groepen van triples A t/m D. Er is sprake van het “verwijderen” van een groep triples indien geen van de uitspraken van het subject er meer toe doen (conceptueel: het “subject” is geen onderdeel meer van de UoD). Er is sprake van een “wijziging” als er minimaal nog één triple over is, en de verzameling van overgebleven triples is een andere dan de oorspronkelijke verzameling. In onderstaand figuur is een “verwijdering” weergegeven met een rood kruis (bij triplegroep C), en een wijziging met een accent (A naar A’). Het voorbeeld kent drie named graphs, afgebeeld als laag. De onderste (en oudste) laag kent drie triplegroepen A, B en D. In de laag hier direct boven is de triplegroep B geregistreerd, en is aangegeven dat de triplegroep C niet meer actueel is. De bovenste laag kent een wijziging van triplegroep A. 
Zonder laag met actuele verwijzingen, zullen alle lagen doorgelopen moeten worden om een actuele stand van zaken te construeren. Dit kan nogal uit de hand lopen als er miljoenen wijzigingen op de gegevenscatalogus zijn doorgevoerd. De rechterkant van het figuur laat zien hoe een laag met actuele verwijzingen er uit kan zien. In deze laag (= named graph) zijn niet alleen de wijzigingen opgenomen, maar ook verwijzingen naar triplegroepen die nog actueel zijn. Zo’n verwijzing bestaat uit één triple met als subject het betreffende subject, als predicate rdfs:isDefinedBy en als object de URI van de named graph met de meest actuele triplegroep. Hierdoor is het slechts nodig om twee lagen te doorlopen: eerst de actuele laag, en vervolgens de laag waarin de triples zich daadwerkelijk bevinden. Overigens veronderstelt dit wel dat een wijziging van een triplegroep betekent dat de gehele triplegroep opgenomen wordt in de nieuwe laag.
Voor de herkomstinformatie van de named graph zelf ligt het gebruik van dublin core en de PROV Ontology voor de hand, zie onderstaand figuur. De prov:Entity komt overeen met de named graph. De named graph als verzameling van triples zal dus enkele triples bevatten die diezelfde named graph als subject hebben.
====Graphs en versiebeheer====
De URI-strategie geeft geen richtlijnen hoe omgegaan moet worden met historie, en daarmee met versies van informatie over een resource. Binnen brk.kadaster.nl wordt hiervoor de volgende standaard gehanteerd:
* http://brk.kadaster.nl/{type}/{tijdsaanduiding}/{concept}/{reference}
Deze tijdsaanduiding heeft te maken met de formele historie van de beschikbare informatie, dat wil zeggen: de documentatie die op dat moment beschikbaar is. Deze tijdsaanduiding zegt niets over de geldigheid van de betreffend documentatie. De tijdsaanduiding kent de volgende opbouw:
* {JJJJ}/{MM}/{DD}/{hh}/{mm}/{dd}/{ss}
Een “id” URI kent geen historie, immers: de “id” URI verwijst slechts naar een resource, en niet naar de informatie over de resource. De redirect van een “id” URI naar een “doc” URI bevat daardoor geen tijdsaanduiding. In een dergelijk geval worde de laatst beschikbare documentatie teruggegeven.
Bij het opgeven van een tijdsaanduiding is het mogelijk om alleen heel specifiek te zijn (dus zowel een datum als een tijdstip), of minder nauwkeurig (bijvoorbeeld alleen het jaar). In alle gevallen zal de meest recente documentatie worden teruggeven die aanwezig is tot en met het aangegeven tijdstip.
Om te kunnen weten welke versie van de documentatie teruggegeven wordt, wordt voor elke resource ook teruggegeven in welk tijdsversie deze resource is gedefinieerd. Hiervoor wordt het predicataat rdfs:isDefinedBy gebruikt. Dit maakt dat ook delen van de documentatie als resource aanwezig zijn, en dat ook hiervoor een URI-strategie nodig is. Deze is als volgt:
* http://brk.kadaster.nl/doc/{tijdsaanduiding}
* http://brk.kadaster.nl/def/{tijdsaanduiding}
Bovenstaande URI’s verwijzen naar “de documentatie op tijdstip {tijdsaanduiding}” voor respectievelijk de “id” resources en de “def” resources.