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:
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.
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:
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:
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:
Bovenstaande URI’s verwijzen naar “de documentatie op tijdstip {tijdsaanduiding}” voor respectievelijk de “id” resources en de “def” resources.
De activiteiten van Platform Linked Data Nederland (PLDN) worden mede mogelijk gemaakt dankzij het Kadaster, TNO, Big Data Value Center (BDVC), ECP, Forum Standaardisatie, Kennisnet, SLO, Waternet, Taxonic, MarkLogic, Triply, Franz Inc., SemmTech, Rijksdienst voor het Cultureel Erfgoed (RCE), Beeld en Geluid, EuroSDR, de KVK en ArchiXL
Wilt u op de hoogte gehouden worden van nieuws en ontwikkelingen binnen PLDN?
Schrijf u dan in voor de nieuwsbrief