TOOI - Ontologie 1.4.1

De ontologie beschrijft bedrijfsregels die onder meer de kardinaliteit van properties bepalen. Een instantie van tooiont:Gemeente heeft bijvoorbeeld precies één waarde voor de property tooiont:ligtInProvincie. Deze bedrijfsregels worden uitgedrukt in SHACL, meer in het bijzonder in de vorm van propertyshapes.

Een propertyshape is een resource die (syntactische) regels stelt aan het gebruik van een property. Binnen de TOOI-Ontologie worden deze gebruikt om properties te beschrijven in de context van een subjectklasse. Voorbeeld:

  tooiont:Gemeente-ligtInProvincie

Deze propertyshape geeft een context-gevoelige definitie van het gebruik van de property tooiont:ligtInProvincie bij een instantie van tooiont:Gemeente, en stelt eisen aan de kardinaliteit.

De relatie tussen een klasse en de bijbehorende propertyshape kan volgens SHACL op een aantal manieren worden vastgelegd. Binnen TOOI wordt elke klasse expliciet gedefinieerd als een instantie van zowel rdfs:Class als sh:NodeShape. Voor de relatie naar de propertyshape gebruikt TOOI sh:property.

Voor optimaal gebruik ten behoeve van validatiedoeleinden kunnen de propertyshapes desgewenst afgesplitst worden in aparte grafen. Deze grafen kunnen dan gebruikt worden om bepaalde datasets te valideren. De kardinaliteit van tooiont:ligtInProvincie eist dat een gemeente een waarde kent voor deze property. In het gemeenteregister moet deze eis worden afgedwongen. In een dataset met metadata over een document dat gepubliceerd is door een bepaalde gemeente is het juist niet de bedoeling dat er een waarde wordt gespecificeerd voor deze property (hier geldt de zogenaamde Open World Assumption voor dit aspect van de data).

De TOOI-ontologie kan ook in zijn huidige vorm toegepast worden in deze verschillende gebruikscontexten, dus zonder de propertyshapes af te scheiden. Dan is het wel noodzakelijk om shapes die buiten beschouwing dienen te blijven te deactiveren met sh:deactivated. Stel, de gebruiker wil documentmetadata valideren, en de propertyshape voor tooiont:Gemeente-ligtInProvincie dient buiten beschouwing te blijven. De gebruiker kan dan de volgende graaf aanmaken, en deze importeren bij het validatieproces. Het volgende fragment is in TRIG-format, zie [trig]. (Dit format lijkt in alles op Turtle, behalve dat graafnamen buiten accolades staan, en de inhoud van de graaf daarbinnen.)

    <https://voorbeeld.nl/grafen/deactivatie> {

        <https://voorbeeld.nl/grafen/deactivatie> 
            a owl:Ontology ;
            rdfs:comment "Hierin wordt een shape gedeactiveerd. Importeer bij validatie." ;
        .
        tooiont:Gemeente-ligtInProvincie 
            sh:deactivated true ;
        .
    }

Propertyshapes krijgen een URI die bestaat uit het prefix tooiont:, gevolgd door een local name die bestaat uit de klassenaam en de propertynaam, gescheiden door een min-teken. Een voorbeeld is tooiont:Gemeente-ligtInProvincie. Het prefix tooiont: wordt ook gebruikt voor propertyshapes waarbij zowel de klasse als de property met een ander namespaceprefix gedefinieerd zijn.

Informatieobjecten zijn — samen met organisaties — de meest centrale objecten in het TOOI-kennismodel. TOOI hanteert een brede definitie van de notie informatieobject, voortbouwend op de notie information resource zoals beschreven in de W3C-recommendation “Architecture of the World Wide Web, Volume One”, zie [webarch]. Deze beschrijving luidt (boldface toegevoegd):

It is conventional on the hypertext Web to describe Web pages, images, product catalogs, etc. as “resources”. The distinguishing characteristic of these resources is that all of their essential characteristics can be conveyed in a message. We identify this set as “information resources.”

This document is an example of an information resource. It consists of words and punctuation symbols and graphics and other artifacts that can be encoded, with varying degrees of fidelity, into a sequence of bits. There is nothing about the essential information content of this document that cannot in principle be transfered in a message. In the case of this document, the message payload is the representation of this document.

However, our use of the term resource is intentionally more broad. Other things, such as cars and dogs (and, if you’ve printed this document on physical sheets of paper, the artifact that you are holding in your hand), are resources too. They are not information resources, however, because their essence is not information. Although it is possible to describe a great many things about a car or a dog in a sequence of bits, the sum of those things will invariably be an approximation of the essential character of the resource.

We define the term “information resource” because we observe that it is useful in discussions of Web technology and may be useful in constructing specifications for facilities built for use on the Web.

De W3C-definitie van information resource richt zich de facto op webresources. Daarbij onderscheidt het de eigenlijke informatieresource van de representatie van die resource . We definieren tooiont:Informatieobject als de klasse van resources waarvan de essentiële karakteristieken overgebracht kunnen worden middels een bericht. Daarmee willen we zeker stellen dat ook informatieobjecten die buiten het web bestaan (zoals Max Havelaar, of De Koffij-veilingen der Nederlandsche Handel-Maatschappij en de Auteurswet) binnen de definitie vallen. De klasse tooiont:Informatieobject is een subklasse van prov:Entity en heeft zelf ook subklassen.

Het gemaakte onderscheid tussen informatieresource en representatie is subtiel maar belangrijk. De URL of URI https://wetten.overheid.nl/BWBR0001854 identificeert het Wetboek van Strafrecht. Daarnaast is het zo dat je, wanneer de URL “opent” in een browser, je in je browser een representatie van het Wetboek te zien krijgt. Semantisch gezien verwijst de genoemde URI naar het Wetboek: het wetboek is de referent (ook: de denotatie) ervan. Het feit dat de webserver een representatie van het Wetboek als inhoud van het antwoordbericht terugstuurt — en niet een 404 of een paar metadata uitgedrukt in tekst of iets anders — is praktisch en handig, maar heeft semantisch gezien geen relevantie. Elke URL is een URI, en wel een URI waarmee content opgehaald kan worden. De W3C-recommendation [webarch] formuleert een aantal principes waaraan de semantiek en werking van URIs en URLs aan zouden moeten voldoen, speciaal in de context van informatieobjecten. Het TOOI-kennismodel voldoet waar mogelijk aan deze principes. In de volgende paragraaf gaan we in op diverse aspecten van URLs en URIs voor informatieobjecten.

Twee verschillende URIs kunnen naar dezelfde resource verwijzen. In dat geval zijn dit aliassen. Aliassen moeten indien mogelijk vermeden worden — dat lukt niet altijd. Een informatieobject kan statisch en onveranderlijk zijn, maar er zijn ook informatieobjecten die voortdurend veranderen. Dat betekent dat het informatieobject op verschillende momenten verschillende representaties heeft. Het kan daardoor voorkomen dat twee verschillende informatieobjecten tijdelijk dezelfde representatie hebben. De URIs van deze informatieobjecten zijn dan nadrukkelijk geen aliassen. Een voorbeeld: de URI http://weather.example.com/oaxaca verwijst naar de weersverwachtingen voor Oaxaca. Dit informatieobject verandert elke dag. De weersverwachting voor Oaxaca op 1 augustus 2004 wordt beschikbaar gemaakt als een afzonderlijke, statische resource met een eigen URI. De twee URIs zijn geen aliassen, ook al hadden de resources waarnaar ze verwijzen op de genoemde datum tijdelijk dezelfde representatie. Zie [webarch], paragraaf 2.3.2.

In [frbr] wordt hetzelfde onderscheid gemaakt. Daar gaan we later in dit document nader op in. Binnen de TOOI-ontologie worden zowel veranderlijke informatieobjecten als hun statische representaties als instanties gezien van tooiont:Informatieobject. Informatieobjecten kunnen complexe relaties met elkaar hebben. Van een informatieobject kunnen verschillende inhoudelijke versies bestaan, het kan vertaald zijn of door een redacteur bewerkt of geanonimiseerd, het kan geleverd worden in diverse vormen. Dit zijn allemaal informatieobjecten.

Wanneer we binnen de huidige context over informatieobjecten spreken hebben we het uit de aard van de zaak primair over overheidsinformatie.

De klasse tooiont:Informatieobject is breed gedefinieerd en omvat ook niet-officiële informatieobjecten. Binnen TOOI ligt de focus vooral op informatieobjecten van Nederlandse (en andere) overheden die kunnen fungeren als rechtsgrond voor bijvoorbeeld een besluit. In dat geval ontleent het besluit zijn rechtsgeldigheid aan de rechtsgrond. Op dit moment definieert TOOI geen subklasse die precies deze informatieobjecten omvat. Ze worden vastgelegd en beschikbaar gemaakt in een aantal specifieke registers. De volgende opsomming is niet-limitatief:

• wetten.overheid.nl
• officielebekendmakingen.nl
• verdragenbank.overheid.nl
• lokaleregelgeving.overheid.nl
• eur-lex.europa.eu

Deze informatieobjecten hebben een rijke mereologische structuur: een wet kan bestaan uit artikelen, en een artikel uit leden. Elk van deze onderdelen vormt op zich weer een informatieobject. De informatieobjecten hebben een persistente identifier in de vorm van een URI. De vormgeving van deze URI volgt complexe regels die voor elk register anders zijn. De regels zijn veelal vastgelegd in applicatieprofielen van meer generieke, vaak internationale standaarden, zoals [akn], [elitg] en [juriconnect].

In de praktijk betekent dat dat de URI van een dergelijk informatieobject uiteenvalt in onderdelen die, bij elkaar genomen, informatie geven over de aard het informatieobject. Volgens de principes van FAIR zou het de voorkeur hebben om deze informatie (daarnaast) expliciet als metadata bij het informatieobject te voegen, in plaats van deze alleen te versleutelen in de identifier.

Dat het identificeren van officiële informatieobjecten een complexe aangelegenheid kan zijn illustreren we hier aan de hand van BWB (het platform dat wetten.overheid.nl serveert).

BWB ondersteunt het gebruik van URIs met een ingebedde query. Dit zijn de URIs van [juriconnect], kortweg de JCI-URIs. Deze zijn primair bedoeld voor zoeken en vinden maar worden ook gebruikt als naam, dus als URIs ter identificatie van resources. Op die manier gebruikt voldoen deze minder goed aan de principes van FAIR. BWB hanteert intern andere URIs. Ook deze kunnen gebruikt worden om een wetsartikel op te halen, maar zijn daarnaast ook goed bruikbaar als identifier en unieke naam. Dan zijn er nog tal van andere URIs die ook nog gebruikt kunnen worden om informatieobjecten geregistreerd in BWB te identificeren, maar die we hier verder buiten beschouwing laten. Beschouw het voorbeeld van artikel 2 van de Schepenwet. De lange verwijzing luidt “Artikel 2, Schepenwet”. Enkele bijbehorende identifiers zijn:

Het voordeel van de http-JCI-URIs in de eerste rij is dat deze voldoen aan een Nederlandse standaard, namelijk [juriconnect]. Bovendien kunnen deze gebruikt worden om het geïdentificeerde informatieobject op te halen en zijn ze persistent. Nadeel is dat de de variant met datums veel synoniemen kent en daarom minder goed voldoet aan de principes van FAIR. Daarover straks meer.

Dit alles geldt ook voor de JCI-URIs in de tweede rij, behalve dat deze niet resolvable zijn.

De http-URIs in BWB (derde rij) zijn resolvable en ook persistent, maar voldoen aan geen enkele standaard: ze worden intern binnen BWB gebruikt. De betekenis van een BWB-URI zal constant blijven, maar ze zijn niet gegarandeerd persistent: er is geen garantie dat ze in de wat verdere toekomst nog steeds resolvable zullen zijn.

Voor wat betreft het probleem met de JCI-URIs gaan we dieper in op het verschil tussen de twee kolommen. De URI van de meest recente versie verwijst naar een dynamische resource: het artikel verandert van vorm (toestand) in tijd. Op verschillende momenten in de tijd kan het artikel dus een andere inhoud hebben. In FRBR-termen (zie inleiding) is dit het ‘work’.

De URI met zicht- en geldigheidsdatum verwijst naar een statisch resource: de toestand van het artikel op een gegeven zichtdatum en geldigheidsdatum, rekening houdend met terugwerkende kracht. In FRBR-termen (zie inleiding) is dit een ‘expression’. Het probleem hierbij is dat de JCI-URIs niet voldoen aan de uniciteitseis. Als we in bovenstaand voorbeeld de zicht- en geldigheidsdatum veranderen naar willekeurige datums in 2023, dan “verwijzen” (denoteren) de nieuwe URIs nog steeds naar dezelfde versie van hetzelfde artikel (er is namelijk geen wijziging geweest). Kortom, het aantal synonieme URIs explodeert, en dat bemoeilijkt hergebruik en combinatie. De BWB-URI met versiedatum kent dat probleem niet: als we in de URI het jaartal 2020 vervangen door 2023, dan heeft het resultaat geen betekenis (en kan ook niet geresolved worden). De URI voldoet aan uniciteit en heeft geen aliassen.

Deze punten worden niet door TOOI geadresseerd. TOOI staat expliciet toe om bestaande URIs te gebruiken als resource-URIs als waarde van de property tooiont:heeftJuridischeGrondslag, waarbij (in lijn met de FAIR-principes) URIs die persistent, resolvable en uniek zijn sterk de voorkeur hebben.

Noot. De FAIR-principes noemen de uniciteitseigenschap niet direct. In de toelichting bij principe F1 wordt verwezen naar een publicatie waar uniciteit wel genoemd wordt als belangrijke eis. Zie [gofair] en [uri21].

Het onderstaande klassediagram toont de belangrijkste klassen en relaties met betrekking tot informatieobjecten. In het diagram is ook te zien dat we twee manieren hanteren om informatieobjecten te classificeren: met subklassen en met concepten. Voor het overkoepelende klassediagram dat informatieobjecten, overheidsorganisaties en wijzigingshistorie omvat, zie 1. Inleiding.

In het hiernavolgende bespreken we de diverse onderdelen van het model in detail. Daarbij gaan we in op de diverse properties en illustreren we een en ander aan de hand van voorbeelden.

Een algemeen probleem met informatieobjecten is dat er zoveel verschillende soorten zijn. Dat maakt het moeilijk om de eigenschappen van een informatieobject in algemene, uniforme termen te beschrijven. Een rechterlijke uitspraak heeft een uitspraakdatum, een wetswijziging niet — die heeft wel weer een datum inwerkingtreding. We munten daarom een beperkt aantal algemene eigenschappen die een min of meer uniforme betekenis hebben binnen het domein van officiële overheidsinformatie, aangevuld met eigenschappen die specifiek zijn voor een subklasse.

Dit is een verschil met OWMS, waar negen generieke eigenschappen uit de Dublin Core-standaard verplicht worden gesteld als metadatadata-elementen. De ervaring heeft geleerd dat het lastig is om een eigenschap als dcterms:creator voor elk willekeurig informatieobject op een consistente en eenduidige manier van een waarde te voorzien. Daarom is het advies bij OWMS ook om applicatieprofielen te maken voor specifieke documenttypen. In TOOI verschuift de nadruk van Dublin Core [DC11] naar PROV-O [prov-o], wordt het aantal generiek toe te passen eigenschappen beperkt, en worden er meer eigenschappen gedefinieerd die specifiek zijn voor een subklasse. Daarbij is geldende regelgeving een belangrijk uitgangspunt.

Ook zijn we terughoudend met het gebruik van FRBR, een veelgebruikt conceptueel model om informatieobjecten in te delen in werk, expressie, manifestatie of item (zie [frbr]). De exacte criteria die bepalen welke informatieobjecten als werk of juist als expressie getypeerd moeten worden zijn afhankelijk van het type informatieobject en van het soort processen die de levensloop van informatieobjecten van dat type bepalen. ELI, de Europese RDF-ontologie voor de representatie van nationale wetgeving, onderscheid ‘LegalResource’ en ‘LegalExpression’, maar laat het aan de gebruiker van de standaard om te kiezen of het van toepassing is en zo ja, hoe dit onderscheid uitvalt voor de betreffende wetgeving. Zie [elitg], p. 34. Daarmee kunnen verschillende gebruikers in dezelfde omstandigheden verschillende keuzes maken.

Binnen STOP [stop] wordt eveneens uitvoerig gebruik gemaakt van FRBR. Het toepassingsgebied van STOP is nauw omschreven en de informatieobjecten in het domein zijn in hoge mate uniform. Daarom is het onderscheid dat STOP maakt tussen de verschillende FRBR-typen helder en eenduidig.

Een potentiële bron van verwarring is het verschil in de definitie van ‘informatieobject’. In de TOOI-ontologie zijn dit, zoals hierboven uiteengezet, documenten, bestanden, afbeeldingen en dergelijke. STOP gebruikt deze term uitsluitend om te verwijzen naar niet-tekstuele resources die bij een officiële publicatie horen maar daar geen deel van uitmaken, zoals een geometrie-object of een gehyperlinkte video. Een ander belangrijk verschil is dat STOP een gedetailleerd en fijnmazig model hanteert voor het beschrijven van de levensloop van omgevingsbesluiten. De TOOI-ontologie volgt in deze context de Regeling Elektronische Publicaties (zie verderop), en ziet daarom primair op het besluit of regeling als gepubliceerde resource. STOP en TOOI kunnen zonder problemen in combinatie met elkaar gebruikt worden. Oog voor de terminologische verschillen is daarbij uiteraard van belang.

TOOI definieert de klasse tooiont:Informatieobject als volgt. In de beschrijving van deze klasse en de bijbehorende properties wordt soms de term ‘document’ gebruikt. Dit is een meer restrictieve term dan ‘informatieobject’, want een dataset is wel een informatieobject maar niet een document (althans niet in het dagelijks taalgebruik).

Voor zover KOOP verantwoordelijk is voor de registratie van een informatieobject zal KOOP een URI munten en aan het informatieobject toekennen. Dat geldt ook voor documenten die door andere partijen aangeleverd worden. De door KOOP toegekende URI voldoet aan alle eisen om te kunnen fungeren als een persistent identifier (PID) conform de FAIR-principes.

Noot. We zeggen URI en niet URL, ondanks het feit dat we http-URIs bedoelen die normaliter dereferenceable zijn. Op dat laatste bestaan uitzonderingen. Een document kan rechtsgeldig teruggetrokken of vernietigd worden, waarna het dus niet meer beschikbaar is voor download. We kunnen nog steeds naar het document verwijzen, als in ”Het document <https://.../id12314> is rechtsgeldig vernietigd op 21 juni 2083”. In geval van vernietiging zal KOOP waarschijnlijk nog wel een beschrijving van het document handhaven in termen van metadatabundel, zodat bijvoorbeeld de datum van vernietiging opgezocht kan worden. In deze metadatabeschrijving gebruiken we de PID om naar het vernietigde document te verwijzen.

De URI van het informatieobject wordt tevens vastgelegd als waarde van tooiont:pid, een subproperty van dcterms:identifier. Het kan nuttig of noodzakelijk zijn naast de pid ook andere identifiers vast te leggen. Dat gebeurt dan altijd met behulp van de property adms:identifier en een instantie van adms:Identifier. Bij deze laatste resource kunnen behalve de identificerende string met schema-aanduiding ook de identiteit dan wel de naam van de toekenner, alsmede andere gegevens vastgelegd worden.

De properties in deze paragraaf worden gebruikt om informatieobjecten te beschrijven en in te delen naar vorm, functie en inhoud. Veel van deze properties hebben een skos:Concept als waarde.

Noot. In OWMS 4.0 hebben classificatie-properties niet een concept maar een klasse als waarde (bijvoorbeeld subklassen van Documenttype). De keuze voor concepten gaat ervan uit dat metadatabeheerders de thesaurus eenvoudig kunnen aanpassen, terwijl een ontologiewijziging meer voeten in de aarde heeft.

Om aan te geven wat de taal is van een informatieobject gebruiken we de algemeen bekende dcterms-properties. Voor de waarden gebruiken we voor zover mogelijk de daarvoor gemunte concepten zoals deze gedefinieerd zijn in de AT-tabellen van de Europese Commissie, met een enkele uitzondering. Zie TOOI-thes-xtrn. Hetzelfde geldt ook voor het format van een informatieobject, zie paragraaf 2.2.6 Manifestaties (bestanden).

Voor het beschrijven van informatieobjecten op (uitsluitend) inhoudelijke gronden kent TOOI de noties thema, onderwerp en trefwoord. Thema’s zijn voorgedefinieerd en hebben de vorm van een concept. Trefwoorden zijn strings en kunnen vrij gekozen worden. Een onderwerp is een korte omschrijving die het doel heeft om bij het presenteren van grotere hoeveelheden informatieobjecten duidelijk aan te kunnen geven waar elk informatieobject in hoofdlijnen over gaat. Het onderwerp is dus meer een beschrijving dan een indelingscriterium, maar er is potentieel enige overlap met trefwoord. De doelstellingen zoals gedefinieerd in onderstaande tabel geven aan welke notie van toepassing is.

We onderscheiden een aantal varianten van het begrip ‘titel’. In principe is de titel een eigenschap van een werk. Expressies van een werk kunnen echter een afwijkende titel hebben (Die Dunkelkammer des Damokles is — onder een bepaalde interpretatie van FRBR — de titel van een expressie van het werk De donkere kamer van Damokles).

Elke titelproperty in de tooiont-namespace is gedefinieerd als een subproperty van dcterms:title.

Provenance-metadata van een informatieobject zeggen iets over de processen die van invloed zijn geweest de levensloop ervan, zoals totstandkoming, publicatie en aanpassing. Wie was bij het proces betrokken, wanneer vond het plaats, enzovoorts. De aard van de gebeurtenissen die de levensloop van een informatieobject bepalen varieert sterk en hangt af van de aard van het informatieobject zelf. Een rechterlijke uitspraak bestaat formeel vanaf het moment dat de rechter deze uitspreekt. Een wetswijziging bestaat officieel vanaf het moment dat deze officieel bekend wordt gemaakt, en is van kracht vanaf het moment dat deze in werking treedt. Het is niet mogelijk om voor alle soorten informatieobjecten binnen de overheid gedetailleerde levensloopinformatie in generieke, uniforme termen vast te leggen. We munten daarom een beperkt aantal generieke eigenschappen. Ook zijn we terughoudend met het gebruik van prov:generated, prov:invalidated en prov:used: de interpretatie van deze properties zal per type document sterk verschillen. Voor een wetswijziging is de waarde van prov:generated gelijk zijn aan de publicatiedatum, maar voor een rapport dat in de Tweede Kamer behandeld is zal de interpretatie anders zijn.

Ook zijn we terughoudend met het gebruik van dcterms:creator ‘An entity responsible for making the resource’. Voor instanties van tooiont:Informatieobject wordt deze property in principe niet gebruikt. TOOI definieert twee subproperties, tooiont:verantwoordelijke en tooiont:opsteller. Deze twee rollen zijn cruciaal verschillend. Ze kunnen door dezelfde partij ingevuld worden, in welk geval het advies is om alleen de verantwoordelijke vast te leggen. De property tooiont:creatiedatum (subproperty van dcterms:created) correspondeert met opsteller, niet met verantwoordelijke. Verantwoordelijkheid voor de inhoud start wanneer het informatieobject gemaakt (en geaccepteerd of vastgesteld) is, maar het bestaan van het document is niet causaal gerelateerd aan deze verantwoordelijkheid.

Wanneer een toestand in het verleden beschouwd wordt, zijn er verschillende perspectieven mogelijk. Het gekozen perspectief hangt af van de datum waarop de toestand beschouwd wordt. TOOI maakt daarom onderscheid tussen peildatum en zichtdatum. De peildatum is de datum waarop de toestand zich voordoet (het geval is). De zichtdatum is de datum van waaruit de toestand beschouwd wordt. In veel gevallen maakt de keuze van zichtdatum geen verschil. In sommige contexten is de zichtdatum daarentegen van groot belang. Een voorbeeld is de context van, bijvoorbeeld, rechtsfeiten die met terugwerkende kracht ingesteld worden. Stel, het salaris van een bepaalde persoon bedraagt op 1 januari 2014 precies 3000 Euro. Op 30 juni 2014 bepaalt de rechter met terugwerkende kracht dat vanaf 1 januari 2014 het salaris 3100 Euro bedraagt. Wat was nu het salaris op peildatum 1-1-2014? Dat hangt af van de zichtdatum. Ligt de zichtdatum op of na de datum dat de rechter zijn uitspraak deed, dan was het salaris op de peildatum 3100 Euro. Als de zichtdatum tussen 1-1-2014 en de datum van uitspraak ligt, dan is het salaris op de peildatum 3000 Euro.

Een andere context waarin de keuze van de zichtdatum significant is, is de waardelijst. Een waardelijst binnen TOOI kan bijvoorbeeld de organisaties benoemen die op de peildatum bestaan. Het is denkbaar dat een organisatie pas enige tijd na oprichting geregistreerd wordt in de lijst. Het antwoord op de vraag welke organisaties op de peildatum van de lijst zijn opgenomen in deze lijst hangt in dit geval af van de zichtdatum. Het document TOOI - Waardelijstontologie beschrijft in detail hoe peildatum en zichtdatum in TOOI-waardelijsten toegepast worden.

Het begrip ‘peildatum’ is niet hetzelfde als geldigheidsdatum. Geldigheid is een relatie tussen een object en een doelstelling met de daarbij horende normen. Neem de lijst met landen op peildatum 1 mei 1975. Daarin komt het land DDR voor. Neem nu de situatie dat iemand die op genoemde datum geboren is vandaag (de zichtdatum) op een formulier haar geboorteland moet invullen, en het land waar zij woont. De landen in de lijst zijn “geldige” waarden voor het eerstgenoemde veld, maar niet voor het laatstgenoemde.

De properties tooiont:peildatum en tooiont:zichtdatum worden binnen TOOI op dit moment alleen toegepast op waardelijsten.

Het kan nodig zijn een document in meerdere formats beschikbaar te maken, bijvoorbeeld XML en PDF. Er is dan sprake van drie informatieobjecten: het meer algemene informatieobject, en de twee meer specifieke vormen van dat informatieobject, elk in een eigen format. In de FRBR-terminologie worden deze laatste twee informatieobjecten aangeduid als manifestaties, ook wel bestanden genoemd. TOOI definieert geen aparte subklassen van tooiont:Informatieobject om onderscheid te kunnen maken tussen de diverse FRBR-begrippen. In de paragraaf 2.2.8 Versies van informatieobjecten gaan we nader in op de modellering van deze informatieobjecten en hun relaties, ook in relatie tot FRBR. In deze paragraaf bespreken we de properties die specifiek zijn voor ‘manifestaties’.

Informatieobjecten kunnen een versie zijn van een ander informatieobject. We onderscheiden daarbij drie hoofdvarianten. De meeste gebruikscontexten zijn onder te brengen bij één van deze varianten.

2.2.8.1 Variant: revisie

De eerste variant is dat een metadaterende partij kan aangeven dat een nieuw document een versie is van een eerder gemetadateerd document. Hiervoor wordt de property prov:wasRevisionOf gebruikt. Beide informatieobjecten krijgen een eigen PID en dus een eigen URI.

2.2.8.2 Variant: specialisatie

Het is daarnaast ook mogelijk dat om aan te geven dat het ene informatieobject een meer specifieke vorm is van het andere. Een bekend conceptueel model dat hier meer specifieke inhoud aan geeft is FRBR, zo ook PROV. Dit kan bijvoorbeeld het geval zijn als het informatieobject in de meer algemene vorm veranderlijk is, en het informatieobject in de meer specifieke vorm een statische momentopname ervan is. Zie het Oaxaca-voorbeeld in 2.1 Informatieobjecten: inleiding en overzicht. We krijgen dan de volgende relaties:

Meestal zullen er afspraken gemaakt worden over hoe er in deze gevallen omgegaan dient te worden met metadata. Vaak zal gelden dat de metadata van de twee specialisaties (doc_165 en doc_231 in het schema) een superset zijn van de metadata van het document in meer algemene vorm. Een typisch voorbeeld zou zijn dat elk van de drie documenten dezelfde waarden heeft voor tooiont:titel en tooiont:verantwoordelijke, maar dat alleen de twee specialisaties een waarde hebben voor tooiont:publicatiedatum (elk een andere) of, bijvoorbeeld, voor dcterms:language (elk een andere).

Uiteraard is het mogelijk en vaak wenselijk aan te geven in welke relatie de twee specialisaties zich tot elkaar verhouden, zoals in het volgende schema.

2.2.8.3 Variant: vervanging

Stel, een gebruiker wil op een publicatieplatform een foutief document vervangen door een verbeterd document. Het oude document mag niet beschikbaar blijven, bijvoorbeeld omdat er per abuis privacy-gevoelige informatie in blijkt voor te komen. De nieuwe versie moet onder dezelfde identifier (URI en pid) beschikbaar gemaakt worden als de vorige, foutieve versie, om te zorgen dat eventueel bestaande verwijzingen blijven wijzen naar het document (alleen dan met de aangebrachte verbeteringen). De oude versie mag niet meer beschikbaar zijn voor het publiek, maar komt wel in aanmerking om gearchiveerd te worden conform de archiefwet. In het archief moeten (later) beide versies herkenbaar gemetadateerd beschikbaar zijn.

Merk op dat het aanleveren van een nieuw document (of nieuwe documentversie) met metadata alleen nooit voldoende kan zijn om het publicatieplatform tot het gewenste gedrag te brengen: de aanleverende partij moet laten weten dat het platform een handeling dient uit te voeren, met als gevolg dat het nieuwe document onder de bestaande identifier (URI en pid) beschikbaar komt, en het oude document intern beschikbaar blijft onder een andere URI en pid. Het publicatieplatform zou daarvoor bijvoorbeeld een API-functie kunnen aanbieden.

TOOI gebruikt dcterms:replaces om de relatie tussen de verbeterde en de oude versie weer te geven, en de properties tooiont:redenVervanging en tooiont:datumVervanging om aan te geven waarom en per wanneer de nieuwe versie de oude vervangt. Het volgende schema illustreert dit aan de hand van een voorbeeld.

In dit voorbeeld is het document met de URI doc_231 op 25 juni 2045 vervangen door een nieuwe versie. De oude is nog beschikbaar onder de URI doc_231_oud1. TOOI kent op dit moment nog geen middelen om aan te geven dat de inhoud van doc_231_oud1 niet publiek gemaakt mag worden maar wel moet worden gearchiveerd —  daar moet het publicatieplatform voor zorgen. De nieuwe versie heeft metadata die aangeven waarom en per wanneer deze de oude vervangt. Het kan voorkomen dat de nieuwe versie op zijn beurt ook weer moet worden vervangen, zoals in het volgende voorbeeld:

De modellering in dit voorbeeld kan desgewenst uitgebreid worden met de variant ‘specialisatie’. Daar gaan we in de volgende voorbeelden nader op in.

Voorbeeld: een nieuwe versie, de oude versie blijft beschikbaar

Indien een nieuwe versie van een document gepubliceerd moet worden terwijl de oude versie gewoon beschikbaar blijft, dan moet er minimaal gebruik gemaakt worden van de variant ‘revisie’. Het oude document blijft bestaan onder zijn eigen identifier (URI en pid), inclusief alle bijbehorende metadata. Het nieuwe document wordt onder een nieuwe identifier (URI en pid) geüpload. Met behulp van de property prov:wasRevisionOf wordt de relatie met het oude document aangegeven. Het is ook een optie om hierbij gebruik te maken van de variant ‘specialisatie’. Dat brengt meer complexiteit met zich mee, maar ook meer mogelijkheden tot gedetailleerde metadatabeschrijvingen. Daarbij zullen dan uiteraard meer afspraken over de metadata gemaakt moeten worden. Zie de volgende paragrafen

Voorbeeld: een document heeft een PDF-manifestatie en een XML-manifestatie

Het kan voorkomen dat hetzelfde document in verschillende formats beschikbaar gemaakt dient te worden. In FRBR-termen heten dit geen versies maar ‘manifestaties’. Hierbij moet minimaal gebruik gemaakt worden van de variant ‘specialisatie’.

Afhankelijk van de toepassing zal gelden dat de metadata van de twee specialisaties (doc_231_pdf en doc_231_xml in het schema) een superset zijn van de metadata van het document in meer algemene vorm (doc_231). De toepassing zou kunnen eisen dat elk van de drie informatieobjecten dezelfde waarden hebben voor tooiont:titel en tooiont:publicatiedatum, en dat alleen de twee specialisaties een waarde hebben voor dcterms:format en tooiont:heeftRealisatie (elk een andere).

Complex voorbeeld: versies en manifestaties gecombineerd

Wanneer het nodig is om specifieke versies (FRBR-expressie) te onderscheiden van een enkel document in meer algemene vorm (FRBR-werk) in combinatie met verschillende manifestaties van deze versies, dan kan dat ook. Dit levert uiteraard de nodige complexiteit op. Het volgende voorbeeld geeft aan hoe een aantal metadata verdeeld zouden kunnen zijn over de diverse informatieobjecten. In het voorbeeld wordt ervan uitgegaan dat metadata van een informatieobject herhaald worden in de metadata van zijn specialisaties. Dat heeft als voordeel dat gebruikers die bijvoorbeeld de metadata van doc_231_pdf direct een compleet metadatabeeld hebben. Als de metadata niet herhaald worden, maar uniek zijn voor elk niveau in de specialisatiestructuur, dan moet de gebruiker het complete metadatabeeld samenstellen uit de metadata van verschillende informatieobjecten. TOOI doet geen uitspraken over welke strategieën in welke omstandigheden de voorkeur verdienen.

De relaties prov:specializationOf en prov:wasRevisionOf kunnen uiteraard gecombineerd worden met dcterms:replaces. Het volgende schema combineert het bovenstaande voorbeeld met het voorbeeld uit de paragraaf over de variant ‘vervanging’.

TOOI is ontworpen om zowel eenvoudige als meer expressieve en dus complexere metadatastructuren uit te drukken. Het doet geen uitspraken over hoeveel complexiteit toegestaan dan wel geëist moet worden. Dat zal afhangen van de specifieke gebruikscontext.

Onder de noemer documentrelaties vallen alle relaties tussen een document en een document en tussen een document en een organisatie of persoon. Een aantal van dergelijke relaties zijn al ter sprake gekomen: tooiont:verantwoordelijke, tooiont:opsteller en dcterms:publisher (document-organisatie/persoon) en prov:wasRevisionOf, prov:specializationOf, dcterms:replaces en dcterms:partOf (document-document). Dit worden binnen TOOI L1-relaties genoemd: er is sprake van een property die beide te relateren resources direct verbindt. Deze L1-relaties zijn in de voorgaande paragrafen aan bod gekomen. In de praktijk kan het nodig zijn om meer onderscheidingen te maken. Om dat te ondersteunen definieert TOOI ook L2-relaties. Dat zijn relaties die uitgedrukt worden met behulp van een zogenoemde relatieresource die met behulp van properties de beide te relateren resources verbindt. Over de relatieresource kan vervolgens nadere informatie worden vastgelegd. In het onderhavige geval betreft dat classificatie van de relatie in termen van een skos:Concept. PROV-O [prov-o] past dit patroon uitgebreid toe, met bijbehorende naamgevingsconventies. Evenals DCAT2 [vocab-dcat-2] volgt TOOI deze conventies. Voor document-documentrelaties past TOOI de klasse dcat:Relationship toe. Voor document-organisatie/persoon-relaties definieert TOOI een eigen klasse, tooiont:Betrokkenheid. Beide relatieklassen zijn (direct dan wel indirect) subklassen van prov:Influence. Zie het volgende klassediagram:

Noot. PROV definieert de relatieklasse prov:Attribution voor relaties tussen entiteiten en agents. Deze klasse omvat alleen relaties waarin de organisatie of persoon verantwoordelijkheid draagt voor het bestaan van de entiteit. Dat is niet het geval voor relaties als “ontvangen door” of “geadresseerd aan”. De klasse tooiont:Betrokkenheid omvat ook deze relaties.

Noot. Om volledig accuraat te zijn zou het bereik van tooiont:betrokkene gedefinieerd moeten worden als de vereniging (union) van twee doorsnedes: de doorsnede van foaf:Agent en prov:Agent (zodat alleen instanties van prov:Agent die niet ook een activiteit zijn geselecteerd worden) en de doorsnede van foaf:Agent en prov:Entity (zodat alleen entiteiten geselecteerd worden die verantwoordelijkheid kunnen dragen). Voor toelichting, zie [prov-dm]. In TOOI is dat niet geformaliseerd.

Hierna volgen enige voorbeelden van concepten (instanties van dcat:Role) die betrokkenheid classificeren:

• opdrachtgever
• ontvanger
• geadresseerde

Voorbeelden van concepten die document-documentrelaties classificeren zijn:

• bijlage
• verwijzing

Zie ook de volgende schema’s (de concept-URIs zijn fictief):

Naast tooiont:Informatieobject en tooiont:Overheidsorganisatie spelen de volgende klassen en properties hierbij een rol

2.2.9.2 Documentrelatie: grondslag en juridische grondslag

Een informatieobject kan zijn validiteit aan een ander informatieobject ontlenen: zijn grondslag. De validiteit van een informatieobject kan vele aspecten hebben. Er kunnen dan ook verschillende soorten grondslag onderscheiden worden: financiële grondslag, feitelijke grondslag, enz. TOOI definieert hiervoor tooiont:heeftGrondslag en tooiont:heeftGrondslagString.

Om bij een informatieobject vast te kunnen leggen wat de juridische grondslag is (als onderscheiden van bijvoorbeeld de feitelijke grondslag) dient gebruikt gemaakt te worden van de property tooiont:heeftJuridischeGrondslag. Deze property kan ook gebruikt worden om in het informatieobject zelf kenbaar te maken wat de juridische grondslag is en hoe deze in lopende tekst getoond dient te worden. Een voorbeeld is het Vuurwerkbesluit dat als juridische grondslag onder meer Artikel 257b, Wetboek van Strafvordering heeft. In RDF ziet dat er als volgt uit:

In Turtle kan :BWBR0013360 er als volgt uitzien:

  <https://wetten.overheid.nl/jci1.3:c:BWBR0013360>
    a tooiont:Informatieobject ;
    tooiont:titel "Vuurwerkbesluit"@nl ;
    tooiont:heeftJuridischeGrondslag <https://wetten.overheid.nl/jci1.3:c:BWBR0001903&boek=Tweede&titeldeel=IVa&afdeling=Tweede&artikel=257b> ;
    ... ## overige statements
  .
  <https://wetten.overheid.nl/jci1.3:c:BWBR0001903&boek=Tweede&titeldeel=IVa&afdeling=Tweede&artikel=257b>
    a tooiont:Informatieobject ;
    tooiont:verwijzingLang "Artikel 257b, Wetboek van Strafvordering"@nl ;
    tooiont:verwijzingKort "Art 257b, Sv"@nl ;
  .

In een afgeleide XML-vorm zou :BWBR0013360 als volgt gestructureerd kunnen zijn:

  <tooiont:heeftJuridischeGrondslag>
    <tooiont:Informatieobject>
      <tooiont:pid>https://wetten.overheid.nl/jci1.3:c:BWBR0001903&boek=Tweede&titeldeel=IVa&afdeling=Tweede&artikel=257b</tooiont:pid>
      <tooiont:verwijzingKort>Art 257b, Sv</tooiont:verwijzingKort>
    </tooiont:Informatieobject>
  </tooiont:heeftJuridischeGrondslag>

2.2.9.2.1 Property Shape: Informatieobject-heeftGrondslag

URI	tooiont:Informatieobject-heeftGrondslag
Subjectklasse	tooiont:Informatieobject
Property	tooiont:heeftGrondslag
Label	Grondslag
Definitie	De basis voor de validiteit van het informatieobject
Bereik	xsd:anyURI
Kardinaliteit	0..*
Toelichting	De validiteit van een informatieobject kan vele aspecten hebben. Er kunnen dan ook verschillende soorten grondslag onderscheiden worden: financiële grondslag, feitelijke grondslag, enz. Indien het gaat om een juridische grondslag dient de property tooiont:heeftJuridischeGrondslag gebruikt te worden.

Zie [ecli] en [juriconnect].

2.2.9.2.2 Property Shape: Informatieobject-heeftGrondslagString

URI	tooiont:Informatieobject-heeftGrondslagString
Subjectklasse	tooiont:Informatieobject
Property	tooiont:heeftGrondslagString
Label	Grondslag (tekstuele vorm)
Definitie	De basis voor de validiteit van het informatieobject, in de vorm van tekst.
Bereik	xsd:string
Kardinaliteit	0..*
Toelichting	De waarde van deze property is een tekstuele verwijzing in de vorm van een string, niet een tooiont:Informatieobject. Het gebruik van deze property dient beperkt te blijven tot gevallen waarin het gebruik van een URI niet mogelijk is.

2.2.9.2.3 Property Shape: Informatieobject-heeftJuridischeGrondslag

URI	tooiont:Informatieobject-heeftJuridischeGrondslag
Subjectklasse	tooiont:Informatieobject
Property	tooiont:heeftJuridischeGrondslag
Label	Juridische grondslag
Definitie	Wet, regeling of besluit waaraan het informatieobject zijn rechtsgeldigheid ontleent
Bereik	tooiont:Informatieobject
Kardinaliteit	0..*
Toelichting	De waarde van deze property is een rechtsgrond, geidentificeerd door een URI. De URI is bij voorkeur resolvable. Het register waarin de betreffende wet, regeling of besluit gehouden wordt geldt als de authentieke bron van metadata. Uitspraken over metadata van de rechtsgrond zullen daarom niet in het “aanroepende” document (c.q. de metadata daarvan) opgenomen worden, tenzij er om praktische redenen voor wordt gekozen om een aantal van deze uitspraken lokaal te kopiëren (“caching”). Denk hierbij aan de juiste tekstuele vorm van de verwijzing. De uitspraak dat de resource inderdaad een tooiont:Informatieobject is kan evenzo lokaal herhaald worden. Indien er in de lokale context geen aanleiding bestaat om een dergelijke uitspraak op te nemen dan zal de typering nog steeds afgeleid kunnen worden (inferencing obv SHACL). Dat geldt uiteraard niet voor niet-afleidbare uitspraken, zoals de tekstuele vorm van de verwijzing. Die zullen dan moeten worden opgehaald bij de bron.

Voor het uitdrukken van levensloopgebeurtenissen die betrekking hebben op een document definiëren we de klasse tooiont:Documenthandeling als een subklasse van prov:Activity. Het gaat om een handeling die een bestaand informatieobject van toestand doet veranderen (het document is ter inzage gelegd), dan wel een nieuw informatieobject doet ontstaan (het document is gewijzigd en er ontstaat een nieuwe (geconsolideerde) versie van het document). In de ontologie van organisatiewijzigingen hebben we een onderscheid aangebracht tussen toestandswijzigingen en existentiële wijzigingen. Op dit moment lijkt er in het geval van informatieobjecten weinig aanleiding om dat hier ook te doen. TOOI definieert daarom de volgende klasse, zonder subklassen:

Sommige informatieobjecten, zoals regelingen, hebben een werkingsgebied of een effectgebied. Op dit moment onderscheidt de TOOI-ontologie geen subklassen van tooiont:Informatieobject die per definitie een werkingsgebied of effectgebied hebben. Om de relatie tussen een informatieobject en een gebied uit te kunnen drukken definieert de TOOI-ontologie twee generieke properties, die elk een instantie van tooiont:JuridischeRuimte als waarde hebben. Deze laatstgenoemde klasse wordt nader beschreven in hoofdstuk 5.

Met de term “officiële publicaties” bedoelen we documenten waarvan wettelijk is bepaald dat deze moeten worden gepubliceerd in een van de publicatiebladen. Het kan onder meer gaan om wetten, gemeentelijke verordeningen, publicaties omtrent aangevraagde of verstrekte vergunningen of om mededelingen omtrent faillissementen. Bepalingen omtrent welke documenten in een publicatieblad moeten worden bekendgemaakt zijn opgenomen in tal van wetten.

De Nederlandse overheid kent acht publicatiebladen, die allen in de TOOI-kernthesaurus zijn opgenomen.

In een wat verder verleden bestonden alleen Staatsblad, Staatscourant en Tractatenblad als zodanig. Wettelijk was bepaald dat veel documenten (vooral van lagere overheden en rechtbanken) moesten worden gepubliceerd in landelijke of plaatselijke dagbladen. In de loop der jaren is dit geleidelijk opgeschoven naar elektronische publicatie in een specifiek publicatieblad. Sinds de inwerkingtreding van de Wet elektronische bekendmaking op 11 juni 2009 zijn Staatsblad en Staatscourant nog slechts in de elektronische versie authentiek. In de loop der jaren heeft dit proces zich ook voor andere publicaties voltrokken, vooralsnog met uitzondering van het Afkondigingsblad.

De bladen zelf bestaan eigenlijk alleen nog als kenmerk van de documenten die “in” elk van de bladen worden gepubliceerd. Elk document wordt uniek aangeduid door het publicatieblad, de jaargang, en een volgnummer. Het volgnummer begint elk jaargang opnieuw met de waarde “1”. Een hoger volgnummer betekent meestal een latere publicatiedatum, maar dat hoeft niet altijd. Op basis van deze unieke code wordt de URI van het document opgebouwd. Het document kent manifestaties in de vorm van PDF, HTML, ODT en XML.

Elk van de bladen, zoals hieronder opgesomd, heeft in het kennismodel een representatie als een instantie van skos:Concept in het conceptschema tooikern:publicatieblad. Het skos:prefLabel staat voor de volledige naam, het skos:altLabel voor de officiële afkorting.

Een gemeenschappelijke regeling is een regeling die ervoor zorgt dat twee of meer deelnemende overheidsorganisaties structureel kunnen samenwerken in een publiekrechtelijke of privaatrechtelijke constructie. De gezamenlijke werkzaamheden worden uitgevoerd onder aansturing van een samenwerkingsorganisatie die speciaal daarvoor is opgericht, of van een van de deelnemende organisaties.

In de TOOI-registers Register Samenwerkingsorganisaties en Register Gemeenschappelijke Regelingen worden de regelingen en de samenwerkingsorganisaties geregistreerd. Daarin worden alleen authentieke gegevens geregistreerd die van belang zijn bij de metadatering van overheidsinformatie. Dat is een deelverzameling van de informatie die beschikbaar is op http://organisaties.overheid.nl. De gemeenschappelijke regelingen zelf worden gepubliceerd op https://lokaleregelgeving.overheid.nl.

Binnen de TOOI-registers wordt een gemeenschappelijke regeling alleen vastgelegd als het een publiekrechtelijke constructie betreft. Dat betekent dat bijvoorbeeld bij een samenwerkingsorganisatie onder de Wet gemeenschappelijke regelingen [Wgr] (Wgr) de regeling wél wordt vastgelegd, maar bij een koepelorganisatie (zoals VNO-NCW) niet. Bij dergelijke organisaties zal er ook een regeling getroffen zijn die de samenwerking regelt, maar KOOP heeft geen mandaat om een register te voeren voor dergelijke regelingen.

TOOI onderscheidt twee soorten gemeenschappelijke regelingen, al naar gelang het wettelijke kader of soort wettelijk kader dat van toepassing is. Dat kan de Wet gemeenschappelijke regelingen [Wgr] zijn, of, in geval van grensoverschrijdende samenwerking, een internationaal kader zoals het Aarhusverdrag. De soort wordt vastgelegd als een instantie van skos:Concept als waarde van de property tooiont:soortGemeenschappelijkeRegeling. De concepten zijn gedefinieerd in het conceptschema tooikern:soortGemeenschappelijkeRegeling.

De uitvoerende organisatie van een gemeenschappelijke regeling wordt bronhouder genoemd. Bij een gemeenschappelijke regeling worden in het register bronhouderschap en deelname vastgelegd. Zowel bronhouderschap als deelname is gemodelleerd met behulp van een relatieresource (L2-modellering) omdat deze in de tijd kunnen wijzigen. Begin- en einddatum worden daarom expliciet vastgelegd. De bekendmaking waarmee een deelname of bronhouderschap start of eindigt wordt vastgelegd door middel van een wijzigingsgebeurtenis, namelijk een instantie vaan tooiont:ExistentieleWijziging. Zie 4. Wijzigingshistorie.

Omdat niet-publiekrechtelijke gemeenschappelijke regelingen niet vastgelegd worden in het register, worden bij een dergelijke regeling ook de deelnemers niet vastgelegd.

Bij gemeenschappelijke regelingen worden in het register zowel de versies als de gemeenschappelijke regeling als zodanig vastgelegd (in FRBR-termen: expressies worden vastgelegd naast het werk). Voor een uitgewerkt voorbeeld, zie paragraaf 4. Wijzigingshistorie. Relaties tussen overheidsorganisaties en een gemeenschappelijke regeling verwijst altijd naar het werk, niet naar een versie. Versies die van kracht waren bij volgtijdelijke deelnames en bronhouderschappen dienen op basis van datumvelden geselecteerd te worden.

Het volgende fragment van het klassediagram toont de belangrijkste relaties. Dit hoofdstuk beschrijft gemeenschappelijke regelingen en deelnemingen. Voor samenwerkingsorganisaties, zie het hoofdstuk over overheidsorganisaties, zie 3.2 Overheidsorganisaties en hun properties.

Een waardelijst is een (semi-)gestructureerde selectie van informatie in het kennismodel die een applicatiespecifiek doel dient. Het is een instantie van tooiwl:Waardelijst. Een waardelijst wordt gegenereerd uit één of meerdere grafen, namelijk registers en thesauri. Zie TOOI-waardelijstontologie voor verdere toelichting.

De klasse tooiont:Overheidsorganisatie bevat organisaties die namens de overheid taken uitvoeren en onder het gezag en toezicht van de overheid vallen. Welke organisaties dat zijn hangt af van wetgeving en verandert daarom met de tijd. Deze overheidsorganisaties spelen een centrale rol bij het vastleggen van de provenance van informatieobjecten binnen de overheid: zij hebben het informatieobject gepubliceerd, ze zijn wettelijk verantwoordelijk voor de inhoud ervan, ze ontlenen hun bestaan en functie aan het informatieobject, of ze zijn er op een andere manier expliciet aan gerelateerd.

KOOP is houder van een aantal registers met betrekking tot overheidsorganisaties. Een aantal daarvan geldt als bron van authentieke informatie. De registers leggen vast welke organisaties bestaan, en legt bij elke organisatie een aantal eigenschappen vast. Ook wordt historie bijgehouden. De TOOI-registers maken deel uit van het TOOI-kennismodel.

Wijzigingen van organisaties leggen we vast in wijzigingsobjecten, waarbij we uitgebreid gebruik maken van het PROV-O-vocabulaire [prov-o]. Het gaat daarbij doorgaans om wijzigingen die een rechtsgrond hebben, dat wil zeggen een officieel besluit. Zie 4. Wijzigingshistorie.

Het onderstaande klassediagram toont de genoemde klassen en hun samenhang. We onderscheiden diverse typen overheidsorganisatie. Elk type heeft een aantal specifieke eigenschappen. In het diagram is ook te zien dat we twee manieren hanteren om overheidsorganisaties te classificeren: met subklassen en met concepten.

De klassehiërarchie wordt nader toegelicht in 3.3 Subklassen van Overheidsorganisatie en hun specifieke properties.

De TOOI-ontologie definieert subklassen van tooiont:Overheidsorganisatie als aan de volgende criteria wordt voldaan:

• De subklasse is expliciet genoemd in de grondwet
• Concrete subklassen zijn disjunct doordat de aard, taak en bevoegdheden bij elke subklasse, zoals in de wet omschreven, elkaar uitsluiten. Voorbeeld: de aard, taak en bevoegdheden van een gemeente en een provincie sluiten elkaar uit
• De extensie van de subklasse is wettelijk bepaald: de wet legt met naam en toenaam vast welke organisaties onder deze subklasse vallen. Er is bijvoorbeeld een officiële lijst gemeenten die de actuele situatie weergeeft
• De instanties van deze subklassen hebben eigenschappen die we in de ontologie willen kunnen definiëren, en die uniek zijn voor subklasse. Alleen gemeenten hebben de eigenschap dat ze in een provincie liggen

Het laatstgenoemde criterium is niet zeer scherp. Een waterschap heeft in de TOOI-ontologie geen unieke eigenschappen (behalve de property tooiont:waterschapscode, die eigenlijk niet meetelt omdat dit tot een cirkelredenering leidt). Er bestaan echter wel degelijk specifieke eigenschappen, en in de toekomst is het welicht opportuun om deze alsnog vast te leggen en dus om de betreffende properties op te nemen in de ontologie.

Voor elk organisatietype dat aan de bovengenoemde criteria voldoet definiëren we een subklasse van tooiont:Overheidsorganisatie. Er zijn ook organisatiesoorten, zoals de soort adviescollege, die niet voldoen aan deze criteria.

Een organisatie kan tegelijkertijd een rechtsprekende instantie én een adviescollege zijn: de soorten zijn niet disjunct. Ten tweede, bij het bepalen van hoeveel adviescolleges exact opgenomen worden in het register en welke dat dan zijn moeten er diverse afwegingen gemaakt worden — dit is juridisch minder vast omlijnd. We onderkennen bovendien geen specifieke eigenschappen die alleen adviescolleges hebben. Voor deze classificatie definiëren we daarom de eigenschap tooiont:organisatiesoort. De waarde van deze property is een concept uit een specifiek conceptschema. Hieronder vallen bijvoorbeeld de concepten “adviescollege” en “rechtsprekende instantie”.

Soms is er sprake van overlap tussen een concept en een klasse. Instanties van de klasse tooiont:Gemeente hebben voor de property tooiont:organisatiesoort de waarde tooikern:c_49ea8180, het concept in TOOI-thes-kern dat staat voor “gemeente” — het heeft dan ook het skos:prefLabel “gemeente”. In dit geval is er dus een correspondentierelatie tussen de klasse en het concept. [FOAF] definieert een property die deze relatie min of meer uitdrukt: foaf:focus. TOOI maakt géén gebruik van deze property: de relatie tussen klasse en concept blijft vooralsnog impliciet.

Voorbeeld van een organisatie in het register van overheidsorganisaties  (het concept tooikern:c_2c4326b9 heeft prefLablel “adviescollege”):

  oorg:oorg10108
      a tooiont:Overheidsorganisatie ;
      tooiont:officieleNaamExclSoort "Onderzoeksraad voor Veiligheid" ;
      tooiont:organisatiesoort tooikern:c_2c4326b9 ; ## "adviescollege" 
      ## overige properties weggelaten
  .

Voor instanties van één van de subklassen van tooiont:Overheidsorganisatie is de waarde van deze property — hoewel voorspelbaar en dus informatietechnisch gezien redundant — expliciet geasserteerd. Voorbeeld van een instantie van tooiont:Gemeente in het gemeenteregister (tooikern:c_49ea8180 heeft prefLabel “gemeente”):

  gemeente:gm0392
      a tooiont:Gemeente ;
      tooiont:officieleNaamInclSoort "gemeente Haarlem" ;
      tooiont:gemeentecode "0392" ;
      tooiont:organisatiesoort tooikern:c_49ea8180 ; ## "gemeente" 
      ## overige properties weggelaten
  .

Een organisatie kan meerdere waarden hebben voor tooiont:organisatiesoort. Een Zbo is dus een instantie van de subklasse tooiont:Zbo (en niet ook nog van een andere subklasse), maar kan naast het concept voor “zelfstandig bestuursorgaan” ook bijvoorbeeld het concept voor “adviescollege” als waarde van tooiont:organisatiesoort hebben.

De klasse tooiont:Overheidsorganisatie is gedefinieerd als een subklasse van prov:Entity, prov:Agent en van org:FormalOrganisation. ORG (zie [vocab-org]) is een ontologie voor het modelleren van organisaties en is een W3C-recommendation. De definities die ORG hanteert worden in meer detail besproken aan het eind van dit hoofdstuk.

Instanties van de klasse tooiont:Overheidsorganisatie hebben de volgende properties.

Een samenwerkingsorganisatie is een organisatie die in het leven is geroepen om een gemeenschappelijke regeling uit te voeren, al dan niet onder de Wet gemeenschappelijke regelingen (Wgr) [Wgr]. Een gemeenschappelijke regeling is een regeling die ervoor zorgt dat twee of meer deelnemende overheidsorganisaties structureel kunnen samenwerken in een publiekrechtelijke of privaatrechtelijke constructie. De gezamenlijke werkzaamheden worden uitgevoerd onder aansturing van een samenwerkingsorganisatie die speciaal daarvoor is opgericht, of van een van de deelnemende organisaties. Gemeenschappelijke regelingen worden beschreven in 2.3 Subklassen van Informatieobject en hun specifieke properties.

Elke samenwerkingsorganisatie voert een gemeenschappelijke regeling uit, maar niet elke gemeenschappelijke regeling wordt uitgevoerd door een samenwerkingsorganisatie. De gemeenschappelijke regeling die door een samenwerkingsorganisatie wordt uitgevoerd wordt alleen vastgelegd als het een publiekrechtelijke constructie betreft. Er zijn dus samenwerkingsorganisaties, zoals koepelorganisaties, waarbij geen regeling wordt vastgelegd.

TOOI onderscheidt diverse soorten samenwerkingsorganisaties. De soort wordt vastgelegd als een instantie van skos:Concept als waarde van de property tooiont:organisatiesoort. De van toepassing zijnde concepten zijn beschikbaar in een collectiegebaseerde conceptwaardelijst .

De relatie met het oprichtingsbesluit waarmee een samenwerkingsorganisatie in het leven wordt geroepen wordt op de standaardmanier beschreven, dus met een wijzigingsgebeurtenis, meer in het bijzonder een instantie van tooiont:Oprichting. Dat geldt ook (mutatis mutandis) voor de opheffing. Zie 4. Wijzigingshistorie

Het volgende fragment van het klassediagram toont de belangrijkste relaties.

Centraal in TOOI staan informatieobjecten en overheidsorganisaties. Deze ondergaan in de loop van de tijd veranderingen. Bij een wijziging is het soms wenselijk detailinformatie over het wijzigingsproces te kunnen vastleggen. Daarbij gaat het om het moment waarop de wijziging ingaat, indien van toepassing welke rechtsgrond de grondslag is voor de wijziging, op welk moment de wijziging geregistreerd is, en eventueel de betrokken actor en de reden voor de wijziging. PROV-O [prov-o] biedt een idioom om het procesperspectief uit te drukken en op die manier meer details te kunnen vastleggen over de procesgang.

PROV-O gaat vooral over entiteiten, waarbij de notie ‘entiteit’ gebruikt wordt voor alles waarvan de herkomst (provenance) beschreven moet kunnen worden. De drie centrale klassen in PROV-O zijn:

• Een prov:Entity is een fysiek, digitaal, conceptueel of ander soort ding met een aantal vaste aspecten; entiteiten kunnen echt of denkbeeldig zijn.
• Een prov:Activity is iets dat gedurende een bepaalde periode plaatsvindt en op entiteiten inwerkt; dit kan het consumeren, verwerken, transformeren, wijzigen, verplaatsen, gebruiken of genereren van entiteiten omvatten.
• Een prov:Agent is iets dat enige vorm van verantwoordelijkheid draagt voor een activiteit die plaatsvindt, voor het bestaan van een entiteit of voor de activiteit van een andere agent.

TOOI breidt het idioom uit met de klasse tooiont:Wijzigingsgebeurtenis, een subklasse van prov:Activity. Instanties hiervan worden beschreven in termen van onder meer de genoemde eigenschappen. Daarnaast onderscheidt TOOI twee nadere subklassen:

• tooiont:ExistentieleWijziging: Bij een existentiële wijziging begint een entiteit te bestaan, of houdt op te bestaan.
• tooiont:Toestandswijziging: Bij een toestandswijziging verandert de toestand van de entiteit. Er is dan sprake van een wijziging in de propertywaarden van de entiteit.

Zowel overheidsorganisaties als informatieobjecten zijn gedefinieerd als subklassen van prov:Entity, evenals deelname aan en bronhouderschap bij een gemeenschappelijke regeling. Dat geldt ook voor de klasse tooiont:BestuurlijkeRuimte, die in het volgende hoofdstuk nader wordt besproken.

Overheidsorganisaties zijn daarnaast ook gedefinieerd als subklasse van prov:Agent.

Dit leidt tot het volgende klassediagram. De groen gemarkeerde subklassen van tooiont:ExistentieleWijziging worden behandeld in de 4. Wijzigingshistorie op overheidsorganisaties:

Instanties van deze klasse worden beschreven in termen van de volgende properties:

De properties voor tooiont:Toestandswijziging zijn als volgt.

Een instantie van tooiont:HistorischeVersie altijd óók een instantie van een andere, meer concrete klasse. Neem een willekeurige resource die een instantie is van een klasse, bijvoorbeeld tooiont:Gemeente. Bij een toestandswijziging van deze resource wordt er een nieuwe resource aangemaakt, die zowel een instantie is van tooiont:HistorischeVersie als van de klasse van het “origineel” — in het voorbeeld is dat tooiont:Gemeente.

De waarden van alle properties die de bestaande resource heeft worden “gekopieerd” naar deze nieuwe resource, met uitzondering van prov:generatedAtTime en tooiont:begindatum. Ontologisch gezien zijn dat geen eigenschappen van de toestand, maar van de individuele entiteit. Dat onderscheid wordt nader toegelicht in de volgende subparagraaf.

Ook wordt de gerelateerde property tooiont:einddatum niet gekopieerd, maar dat is ook om andere redenen logisch. Immers, wanneer een entiteit (informatieobject of overheidsorganisatie) een einddatum heeft, dan kan er bij die entiteit geen toestandsverandering meer optreden. De einddatum wordt voor de historische versie wel gespecificeerd, maar betekent: de laatste datum waarop de toestand nog van kracht was.

Daarnaast wordt de historische versie aan de entiteit gerelateerd door middel van prov:specializationOf.

Als laatste wordt de waarde van prov:invalidatedAtTime gespecificeerd. Deze is gelijk aan de waarde van tooiont:tijdstipWijziging van het bijbehorende wijzigingsobject. De semantiek van prov:invalidatedAtTime vraagt hier speciale aandacht. In deze context verwijst dit naar het moment waarop de toestand overging in een andere: de individuele entiteit blijf gewoon bestaan. Afgeleid van prov:invalidatedAtTime is de waarde van tooiont:einddatumHV, de einddatum van de historische versie.

Een historische versie wordt beschreven met de volgende properties. Naast deze properties heeft een historische versie alle properties en hun waarden die van toepassing waren op de entiteit voordat de wijziging plaatsvond.

Het begrip “historische versie van een entiteit” verwijst naar een toestand waar de entiteit zich in bevond. De entiteit bestaat langdurig en verandert tijdens zijn bestaan van toestand. Een historische versie van de entiteit bestaat korter (in ieder geval, per definitie, niet langer) en is onveranderlijk. De historische versie kan gezien worden als een “momentopname”, “snapshot”, “timeslice” of “temporal part” van de entiteit. De entiteit zelf geldt ontologisch als een individual: de essentiële eigenschappen en identeit van deze indviduele entiteit blijven constant in de tijd, terwijl niet-essentiële eigenschappen kunnen veranderen. Een snapshot specificeert een tijdelijke toestand in termen van niet-essentiële eigenschappen. Het snapshot is statisch en is niet onderhevig aan verandering. Voor een formeel-ontologische uitwerking van de relatie tussen “snapshots” en “individuals”, zie [offscm].

De historische versie is, in PROV-O-termen, een prov:specializationOf van de individuele entiteit. De definitie hiervan is als volgt (in vertaling):

Een entiteit die een specialisatie van een ander is, deelt alle aspecten van de laatste en presenteert bovendien meer specifieke aspecten van hetzelfde ding als de laatste. Meer in het bijzonder omvat de levensduur van de entiteit die wordt gespecialiseerd, de levensduur van elke specialisatie. Voorbeelden van aspecten zijn een tijdsperiode, een abstractie en een context die verband houdt met de entiteit.

Het verschil tussen “snapshot” en “individual” correspondeert met het verschil tussen zogenaamde stage-level predicates en individual-level predicates. Dit verschil is vooral bekend uit de algemene taalwetenschap, zie bijvoorbeeld [slilp]. Stage-level predicates (zoals ‘beschikbaar’) zeggen iets over een tijdelijke toestand waarin een individuele entiteit zich bevindt, terwijl individual-level predicates (zoals ‘altruïstisch’) iets zeggen over (een essentiële eigenschap van) de individuele entiteit zelf.

De klasse tooiont:HistorischeVersie is ontologisch gezien een “dispersive universal”, ook wel category genoemd. Dat betekent dat iets nooit alleen maar een historische versie kan zijn: het moet ook een instantie zijn van een klasse die identiteitsregels en regels voor individuatie inhoudt. Dat zijn “meer concrete” klassen zoals tooiont:Gemeente en tooiont:OfficielePublicatie. Een ontwerpoptie was geweest om voor elke mogelijke combinatie van “concrete klasse” en historische versie een subklasse van beide te definieren. Dat zou een combinatorische explosie van het aantal expliciet gedefinieerde klassen opleveren. Vandaar de eis dat resources getypeerd als tooiont:HistorischeVersie ook een ander type dienen te hebben.

Deze conceptualisatie heeft tot gevolg dat historische versies logischerwijze pas vastgelegd kunnen worden wanneer ze niet meer van kracht zijn. Dat komt overeen met het dagelijks taalgebruik. In Wikipedia is te vinden dat de persoon die algemeen bekend staat als “Caesar Augustus” (de eerste keizer van het Romeinse rijk) geboren werd als “Gaius Octavius”, en vanaf 44 v.Chr. officieel “Gaius Julius Caesar” heette. De naam “Caesar Augustus” kreeg hij pas later. In de diverse taalvarianten van Wikipedia is steeds een lemma voor “Caesar Augustus” te vinden: de overige namen zijn geen ingang. Blijkbaar valt de laatst bekende “toestand”, dus die met de persoonsnaam “Augustus”, intuïtief samen met de individu.

Een ander, meer praktisch gevolg is het feit dat de begindatum van een gegeven toestand, dat wil zeggen een instantie van tooiont:HistorischeVersie, als volgt afgeleid moet worden.

Begintijdstip van een historische versie h met prov:invalidatedAtTime t van een entiteit e:

• Als er n historische versies h bestaan van e, en van een of meerdere is de waarde van prov:invalidatedAtTime iat_j (1 <= j <= n) kleiner dan t, dan is de iat_j die het dichtst bij t ligt het begintijdstip.
• Als een dergelijke historische versie niet bestaat, dan is de toestand ingegaan op het begintijdstip van e.

De metadata van een informatieobject kunnen aangepast worden zonder dat het informatieobject inhoudelijk wijzigt. De organisatie die een document gepubliceerd heeft kan bijvoorbeeld een nieuw trefwoord toevoegen. Ook kan een dienstverlenende organisatie die het publicatieplatform levert automatische verrijking toepassen, zoals het toewijzen van het document aan een thema. Het kan belangrijk zijn dit soort wijzigingen vast te leggen zodat de historie van de metadata van een informatieobject inzichtelijk wordt.

Dat kan met behulp van instanties van de klassen tooiont:Toestandswijziging en tooiont:HistorischeVersie. Een voorbeeld op instantieniveau ziet er als volgt uit:

In dit voorbeeld is aan de metadata van doc_21 de uitspraak toegevoegd dat het document bij een bepaald thema hoort. Deze verrijking is uitgevoerd door de automatische thematoekenner. De historische versie van dit document, hv_7ad4, bevat de oude toestand, dus zonder de uitspraak over het thema. Bij de toestandswijziging wzg_24901 is vastgelegd op welk tijdstip de wijziging is doorgevoerd en wat de reden is voor de wijziging.

Existentiële wijzigingsgebeurtenissen kunnen in de context van informatieobjecten gebruikt worden om gegevens vast te leggen over versionering. De grijze bollen in het volgende voorbeeld zijn we al eerder tegengekomen in 2.2.8 Versies van informatieobjecten. In dit voorbeeld is doc_231 is de thans geldige versie; de oude versie doc_165 is op dit moment niet meer geldig. Als er een formele grondslag is voor dit feit, dan kan dat eenvoudig vastgelegd worden door middel van een existentieel wijzigingsobject — wzg24901 in het voorbeeld.

Hierna volgt een voorbeeld van een naamswijziging van een ministerie. Dit dient gelezen te worden als: het ministerie ministerie:mnre1058 heette tot 1 januari 2018 “ministerie van Veiligheid en Justitie” en heet nu “ministerie van Justitie en Veiligheid”. De oude naam, “ministerie van Veiligheid en Justitie”, is vastgelegd in de historische versie ministerie:hv_04795600. De nieuwe naam is vastgelegd in de actuele versie van ministerie ministerie:mnre1058. De juridische grondslag voor genoemde wijziging is een informatieobject, te weten <https://officielebekendmakingen.nl/stcrt-2017-62719>. Het gaat om het Besluit van 26 oktober 2017 nr. 2017001801, houdende naamswijziging van het ministerie van Veiligheid en Justitie.

    ministerie:mnre1058 ## Het ministerie
      a tooiont:Ministerie ;
      tooiont:ministeriecode “1058” ;
      tooiont:officieleNaamInclSoort "ministerie van Justitie en Veiligheid" ;
      tooiont:afkorting "JenV" ;
      ## Overige properties weggelaten
    .
    ministerie:hv_04795600 ## Historische versie, gecreëerd op het moment dat wijziging wordt vastgelegd
      a tooiont:HistorischeVersie, tooiont:Ministerie ;
      tooiont:ministeriecode "1058" ;
      tooiont:officieleNaamInclSoort "ministerie van Veiligheid en Justitie" ;
      tooiont:afkorting "VenJ" ;
      prov:invalidatedAtTime "2018-01-01T00:00:00"^^xsd:dateTime ;
      prov:specializationOf ministerie:mnre1058 ;
      tooiont:einddatum "2017-12-31"^^xsd:date ;
      ## Overige properties weggelaten
    .
    ministerie:wzg_05229330 ## De wijzigingsgebeurtenis
      a tooiont:Toestandswijziging ;
      prov:invalidated ministerie:hv_04795600 ;
      prov:used ministerie:mnre1058 ;
      tooiont:heeftJuridischeGrondslag <https://officielebekendmakingen.nl/stcrt-2017-62719> ;
      tooiont:tijdstipWijziging "2018-01-01T00:00:00"^^xsd:dateTime ;
    .

De oprichting van een organisatie en de opheffing ervan kunnen eenvoudig vastgelegd worden met een existentiële wijziging. In de context van gemeenten komen complexere gevallen voor, bijvoorbeeld de samenvoeging van vier gemeenten tot twee nieuwe.

TOOI onderscheidt een aantal subklassen van tooiont:ExistentieleWijziging die speciaal bedoeld zijn voor het inzichtelijk kunnen beschrijven van gemeentelijke herindelingen. Bij elke subklasse hoort een specifieke signatuur van de drie relaties prov:generated, prov:invalidated en prov:used. Daarmee bedoelen we dat elke subklasse specifieke kardinaliteitseisen stelt aan deze relaties. Daarbij gaat het uiteraard om het aantal betrokken organisaties (de objectzijde van de relatie) — het aantal betrokken wijzigingsobjecten is per definitie één.

De properties voor tooiont:Opheffing zijn als volgt.

De properties voor tooiont:Oprichting zijn als volgt.

De properties voor tooiont:Herschikking zijn als volgt.

De properties voor tooiont:Samenvoeging zijn als volgt.

De properties voor tooiont:Opsplitsing zijn als volgt.

De properties voor tooiont:Uitbreiding zijn als volgt.

De properties voor tooiont:Afsplitsing zijn als volgt.

De TOOI-Organisatieregisters gebruiken steeds de meest concrete subklasse die van toepassing is. Dat maakt het voor afnemers eenvoudiger om te begrijpen wat voor soort verandering er in een specifiek geval heeft plaatsgevonden.

De beschrijving van de subklassen is systematisch naar kardinaliteit. Daarbij onderscheiden we voor elk van de drie relaties twee gevallen: een kardinaliteit aan objectzijde van [0] of van [1..*]. Dat geeft acht mogelijkheden, die we in de volgende tabel nummeren. Daar bovenop komen nog twee speciale gevallen, waarbij er sprake is van een kardinaliteit van [2..*].

De tabel is een opsomming van alle mogelijke gevallen, inclusief de twee genoemde speciale gevallen. Zoals in de tabel wordt aangegeven is de opvolgingsrelatie niet altijd af te lezen. Als twee gemeenten samengevoegd worden tot een nieuwe, dan is de nieuwe gemeente duidelijk de opvolger van de twee opgeheven gemeenten. In andere gevallen is deze opvolgingsrelatie niet zo duidelijk. Een voorbeeld is een herindelingsbesluit waarin vijf gemeenten opgeheven worden en twee gemeenten opgericht. Woonkernen die voorheen deel uitmaakten van één gemeente kunnen dan bijvoorbeeld in de nieuwe situatie bij verschillende gemeenten horen. We zeggen dan dat alle vijf opgeheven gemeenten alle twee nieuwe organisaties als “opvolger” hebben, en dat betekent dus niet dat elke nieuwe gemeente grondgebied krijgt van elke opgeheven gemeente. Soortgelijke gevallen komen ook voor bij andere typen organisatie.

In zulke gevallen kan het voorkomen dat als onderdeel van hetzelfde besluit extra informatie wordt gegeven die dergelijke opvolgingsrelaties op een andere manier duidelijk maakt, bijvoorbeeld met behulp van polygonen in een kaartbeeld in het geval van gemeenten. Dergelijke extra informatie wordt niet vastgelegd in de TOOI-Organisatieregisters.

De subklasse tooiont:Herschikking heeft een signatuur van ([0..*], [1..*], [1..*]) en komt dus twee keer voor in de tabel. De ervaring leert dat verreweg de meeste existentiële wijzigingen opheffingen en oprichtingen betreffen. Bij gemeenten komen samenvoegingen, opsplitsingen, uitbreidingen en afsplitsingen ook veel voor. Herschikking is een restcategorie en komt veel minder vaak voor. Ook bij herschikkingen is de opvolgingsrelatie vaak niet afleidbaar. Zelfs wanneer alle drie relaties kardinaliteit [1] hebben is niet af te lezen wat de rol van de “used” organisatie is. Een deel van de opgeheven organisatie kan bij de bestaande zijn gevoegd, of een deel van de bestaande organisatie wordt afgesplitst en bij de nieuwe gevoegd. Beide mogelijkheden kunnen tegelijk van toepassing zijn, en er zijn nog meer mogelijkheden te bedenken.

p:u

Kardinaliteit prov:used

p:g

Kardinaliteit prov:generated

p:i

Kardinaliteit prov:invalidated

Het volgende schema illustreert een tooiont:Samenvoeging:

In Turtle ziet dat er als volgt uit:

    gemeente:gm1950
      a tooiont:Gemeente ;
      tooiont:officieleNaamInclSoort "gemeente Westerwolde" ;
      prov:generatedAtTime "2018-01-01T00:00:00" ;
      tooiont:begindatum "2018-01-01" ;
    .
    gemeente:gm0007
      a tooiont:Gemeente ;  
      tooiont:officieleNaamInclSoort "gemeente Bellingwedde" ;
      prov:invalidatedAtTime "2018-01-01T00:00:00" ;
      tooiont:einddatum "2017-12-31" ;
    .
    gemeente:gm0048
      a tooiont:Gemeente ;
      tooiont:officieleNaamInclSoort "gemeente Vlagtwedde" ;
      prov:invalidatedAtTime "2018-01-01T00:00:00" ;
      tooiont:einddatum "2017-12-31" ;
    .
    gemeente:wzg_0a8c098dd1
      a tooiont:Samenvoeging ;
      tooiont:tijdstipWijziging "2018-01-01T00:00:00" ;
      tooiont:heeftJuridischeGrondslag <https://officielebekendmakingen.nl/stb-2017-105> ;
      prov:invalidated gemeente:gm0007 ;
      prov:invalidated gemeente:gm0048 ;
      prov:generated gemeente:gm1950 ;
    .