TOOI - Ontologie 1.4.1

KOOP Standaard
Vastgestelde versie

Deze versie:
https://standaarden.overheid.nl/tooi/doc/tooi-ontologie-1.4.1/
Laatst gepubliceerde versie:
https://standaarden.overheid.nl/tooi/doc/tooi-ontologie/
Vorige versie:
https://standaarden.overheid.nl/tooi/doc/tooi-ontologie-1.4.0/
Redacteur:
TOOI-beheerteam (KOOP)
Auteur:
Kennis- en Exploitatiecentrum voor Officiële Overheidspublicaties (KOOP)

Status van dit document

Dit is de definitieve versie van dit document. Wijzigingen naar aanleiding van consultaties zijn doorgevoerd.

Samenvatting

Het doel van TOOI is het definiëren van een gemeenschappelijke taal waarmee data en metadata uitgedrukt kunnen worden, zodat overheidsinformatie beter vindbaar, toegankelijk, interoperabel en herbruikbaar wordt. Binnen dit geheel is de TOOI-ontologie het (primaire) conceptueel model. Het definieert de klassen, properties, bedrijfsregels en andere resources voor het vastleggen van data en metadata conform TOOI. De centrale begrippen in dit conceptueel model zijn informatieobjecten en overheidsorganisaties.

De familie van TOOI-documenten

Dit document maakt deel uit van de familie van TOOI-documenten die gepubliceerd wordt op standaarden.overheid.nl/tooi.

Bovenstaande documenten vormen samen de normatieve specificatie van de TOOI-standaard. De TOOI-standaard wordt beheerd zoals beschreven in het niet-normatieve TOOI-beheerplan.

Feedback is welkom

Indien u vragen heeft, of op- of aanmerkingen wilt maken op dit document, dan vindt u hier hoe u dat publiekelijk of anoniem kunt doen.

Alle commentaar is welkom.

1. Inleiding

1.1 Overzicht

De TOOI-ontologie is het conceptueel model binnen TOOI. Het definieert de klassen, properties, bedrijfsregels en andere resources voor het vastleggen van data en metadata conform TOOI. De centrale begrippen in dit model zijn informatieobjecten en overheidsorganisaties.

1.2 Klassediagram

Het volgende klassediagram toont de klassen die gebruikt worden om informatieobjecten en overheidsorganisaties te beschrijven.

Klassediagram TOOI
Figuur 1 Klassediagram TOOI

1.3 Structuur

De TOOI-ontologie heeft de vorm van een RDF-graaf: tooiont. De belangrijkste vocabulaires die de ontologie gebruikt zijn RDF [rdf11-concepts], RDFS [rdf-schema] en SHACL [shacl]. Sommige resources zijn gedefinieerd in termen van Dublin Core Terms [DC11], ORG [vocab-org], PROV-O [prov-o], PAV [pav] en SKOS [skos-reference]. Zie TOOI-URI-strategie, met name de paragraaf over afhankelijkheden.

1.4 Het gebruik van SHACL

1.4.1 Algemeen

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.

1.4.2 SHACL en vaildatie

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 ;
        .
    }

1.4.3 Naamgevingsconventies

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.

1.5 Documentatie van nodeshapes en propertyshapes

In dit document worden de technische beschrijvingen van de TOOI-resources gegenereerd uit de ontologie zelf. Een klassedefinitie ziet er als volgt uit:

Klassebeschrijving TOOI
Figuur 2 Klassebeschrijving TOOI

De volgende eigenschappen worden beschreven:

De definitie van een propertyshape heeft de volgende vorm:

Beschrijving propertyshape TOOI
Figuur 3 Beschrijving propertyshape TOOI

De volgende eigenschappen worden beschreven:

1.6 Onderhoudscyclus

De TOOI-ontologie zal met enige regelmaat worden uitgebreid met nieuwe resources, resourcedefinities en bedrijfsregels. We onderkennen de actuele ongeversioneerde ontologie en geversioneerde afslagen. De geversioneerde afslagen hebben een graphURI met daarin een versie-aanduiding. Telkens als een nieuwe release van (een van de twee grafen van) de ontologie beschikbaar komt, wordt er naast de nieuwe actuele ongeversioneerde ontologie een geversioneerde afslag gepubliceerd.

De graphURI tooiont is de graphURI van de actuele ongeversioneerde ontologie. Het nut hiervan is dat gebruikers vaak in meerdere grafen (of toolspecifieke projecten) naar een ontologie verwijzen. Door te verwijzen naar de ongeversioneerde ontologie kan een nieuwe versie uitgerold worden in de lokale omgeving zonder dat alle verwijzingen geüpdate moeten worden. Aan de andere kant zijn er gebruikers die werken met de geversioneerde afslagen. Beide groepen worden ondersteund.

Om de relatie tussen de actuele versie en de geversioneerde afslag vast te leggen gebruiken we pav:hasCurrentVersion. De string die de versie aanduidt wordt vastgelegd als waarde van pav:version. Zie [pav]. De relatie met andere versies wordt voor ontologie-grafen nog niet vastgelegd.

Het volgende codeblok illustreert dit in TRIG-format. Regel 3 t/m 14 (vanaf ## 1) vormen de actuele ongeversioneerde ontologie tooiont. Het gaat om versie 7.3, maar dit is niet te zien aan de graphURI. De graphURI (ontology URI) van de geversioneerde afslag heeft wèl een versie-aanduiding. Deze graaf omvat regels 18 t/m 28 (vanaf ## 2). Resourcedefinities, prefixdefinities enzovoorts zijn weggelaten.

    <https://identifier.overheid.nl/tooi/def/ont> {

        <https://identifier.overheid.nl/tooi/def/ont> ## 1 ongeversioneerde variant
            a owl:Ontology ;
            owl:versionInfo "v7.3 - Hier staat in het echt informatieve tekst" ;
            rdfs:comment "Ongeversioneerde variant" ;
            rdfs:label "tooiont"@nl ;
            pav:version "7.3" ;
            pav:hasCurrentVersion <https://identifier.overheid.nl/tooi/def/ont-v7.3> ;
        .
        ### resourcedefinities volgen hier
    }
    <https://identifier.overheid.nl/tooi/def/ont-v7.3> {

        <https://identifier.overheid.nl/tooi/def/ont-v7.3> ## 2 geversioneerde variant
            a owl:Ontology ;
            owl:versionInfo "v7.3 - Hier staat in het echt informatieve tekst" ;
            rdfs:comment "Geversioneerde variant" ;
            rdfs:label "tooiont-v7.3"@nl ;
            pav:version "7.3" ;
        .
        ### resourcedefinities volgen hier
    }

1.7 Leeswijzer

Dit document beschrijft de ontologie volgens een thematische structuur:

2. Informatieobjecten

2.1 Informatieobjecten: inleiding en overzicht

2.1.1 Informatieobjecten: definitie en afbakening

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.

2.1.2 Informatieobjecten en rechtsgronden

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:

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:

meest recente versie zonder geldigheidsdatum met zichtdatum en/of geldigheidsdatum (voorbeeld)
http-JCI-URI https://wetten.overheid.nl/jci1.3:c:BWBR0001876&hoofdstuk=I&artikel=2 https://wetten.overheid.nl/jci1.3:c:BWBR0001876&hoofdstuk=I&artikel=2&z=2020-01-01&g=2020-01-01
JCI-URI jci1.3:c:BWBR0001876&hoofdstuk=I&artikel=2 jci1.3:c:BWBR0001876&hoofdstuk=I&artikel=2&z=2020-01-01&g=2020-01-01
http-URI in bwb https://wetten.overheid.nl/BWBR0001876/#HoofdstukI_Artikel2 https://wetten.overheid.nl/BWBR0001876/2020-01-01/#HoofdstukI_Artikel2

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].

2.1.3 Informatieobjecten: klassediagram

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.

Informatieobjecten
Figuur 4 Informatieobjecten

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.

2.1.4 Relatie tot OWMS, FRBR, STOP en andere modellen

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.

2.2 Informatieobjecten en hun properties

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).

Klasse: Informatieobject
URI tooiont:Informatieobject
Label Informatieobject
Definitie Een resource waarvan de essentiële karakteristieken medegedeeld kunnen worden in een bericht
Subklasse van prov:Entity
Toelichting Informatieobject is een subklasse van de categorie prov:Entitity ‘An entity is a physical, digital, conceptual, or other kind of thing with some fixed aspects; entities may be real or imaginary’ en van de categorie dcat:Resource ‘Resource published or curated by a single agent’ — deze klasse ‘…carries properties common to all cataloged resources’.

De Regeling elektronische publicaties [Rep] schrijft voor welke metadata moeten worden opgenomen bij informatieobjecten gepubliceerd in de publicatiebladen, dus instanties van de subklasse OfficielePublicatie. Een aantal van de betreffende properties zijn echter niet specifiek voor deze subklasse. Zo is bijvoorbeeld de property tooiont:titel ook van toepassing op andere informatieobjecten. We kiezen ervoor om in zulke gevallen een generieke TOOI-property te definitiëren die indien toegepast op een officiële publicatie de implementatie vormt van de REP-specificatie. Het gevolg daarvan is dat de definitie die we in TOOI hanteren soms afwijkt van de definitie die REP geeft.

In de tabellen komt de aanduiding REP voor. Dat geeft aan dat de definitie van de property — al dan niet in een enigszins gewijzigde of veralgemeniseerde vorm — overgenomen is uit REP.

2.2.1 URIs en identificatie

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.

2.2.1.1 Property Shape: Informatieobject-pid
URI tooiont:Informatieobject-pid
Subjectklasse tooiont:Informatieobject
Property tooiont:pid
Label PID
Definitie De door KOOP toegekende persistente URI die het informatieobject denoteert
Bereik xsd:string
Kardinaliteit 1..1
Toelichting

De URI is globally unique en persistent.

Merk op dat dit een relatie is van informatieobjecten naar URIs, waarbij je dus uitspraken krijgt als {<uri-x> tooiont:pid <uri-x>}. Dit is analoog aan “Cindy heet ‘Cindy’”, met het tweede voorkomen van “Cindy” tussen aanhalingstekens.
2.2.1.2 Property Shape: Informatieobject-identifier
URI tooiont:Informatieobject-identifier
Subjectklasse tooiont:Informatieobject
Property adms:identifier
Label Identifier
Definitie Een alternatieve identifier
Bereik adms:Identifier
Kardinaliteit 0..*
2.2.1.3 Klasse: adms:Identifier
URI adms:Identifier
Label adms:Identifier
Definitie Een resource waarvan de stringwaarde, zoals uitgedrukt met behulp van skos:notation, gebruikt wordt om een object te identificeren
2.2.1.4 Property Shape: Identifier-notation
URI tooiont:Identifier-notation
Subjectklasse adms:Identifier
Property skos:notation
Label Code
Definitie De literal die de resource uniek identificeert (uniciteit is gegarandeerd binnen het identificatieschema)
Bereik
Kardinaliteit 0..*
Toelichting

De waarde van deze property is een literal. Deze is bij voorkeur getypeerd. Dat kan in termen van een standaard RDF datatype, zoals in zoals in “231/mvo/24-9919”^^xsd:string en “https://doi.org/10.5281/zenodo.1486279”^^xsd:anyURI, of in termen van een “custom datatype”.

De identificerende literal hoeft niet globally unique te zijn, maar is wel uniek binnen het identificatieschema.
2.2.1.5 Property Shape: Identifier-creator
URI tooiont:Identifier-creator
Subjectklasse adms:Identifier
Property dcterms:creator
Label Toegekend door
Definitie De partij die de identifier heeft toegekend
Bereik foaf:Agent
Kardinaliteit 0..*
2.2.1.6 Property Shape: Identifier-schemeAgency
URI tooiont:Identifier-schemeAgency
Subjectklasse adms:Identifier
Property adms:schemeAgency
Label Naam toekenner
Definitie De naam van de partij die de identifier heeft toegekend
Bereik xsd:string
Kardinaliteit 0..*
Toelichting De naam van de toekenner kan vastgelegd worden als de identiteit van de toekenner niet uit te drukken valt in termen van een in een relevant dan wel bruikbaar register gemunte URI.

2.2.2 Classificatie naar vorm, functie en inhoud

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.

2.2.2.1 Property Shape: Informatieobject-documentsoort
URI tooiont:Informatieobject-documentsoort
Subjectklasse tooiont:Informatieobject
Property tooiont:documentsoort
Label Documentsoort
Definitie Het soort document waar het informatieobject toe behoort
Bereik skos:Concept
Kardinaliteit 0..*
Toelichting

Deze property voorziet in de behoefte aan een fijnmazige maar eenvoudig toe te passen categorisering die voor meerdere doeleinden kan worden gebruikt. Daarom is de indeling niet volledig consistent. Er wordern meerdere categorisatiecriteria toegepast. Documentsoort kan bepaald zijn naar functie binnen een proces (bezwaarschrift, adviesdocument), naar de aard van de opsteller (document van burger, rechterlijk document), naar de aard van de gebruiker van het document (parlementair document), naar de manier van publicatie (gemeenteblad, staatscourant) — enzovoorts. Het scheiden van de verschillende indelingscriteria in verschillende properties levert te veel complexiteit op in het redactionele proces.

Door de diversiteit in documentsoorten varieert het gebruik van dit metadata-element. Omdat we de mogelijke gebruikscontext van concepten binnen TOOI zoveel mogelijk buiten beschouwing laten maken we voor specifieke afnemers doorsneden van het conceptschema, waarbij de concepten desgewenst afnemer-specifieke labels kunnen krijgen en in een afnemerspecifieke hiërachie uitgeleverd kunnen worden.
2.2.2.2 Property Shape: Informatieobject-onderwerp
URI tooiont:Informatieobject-onderwerp
Subjectklasse tooiont:Informatieobject
Property tooiont:onderwerp
Label Onderwerp
Definitie Een tekstuele beschrijving in één of enkele woorden van datgene waar het informatieobject over gaat
Bereik xsd:string
Kardinaliteit 0..*
Toelichting Het doel van deze property is om bij het presenteren van grotere hoeveelheden informatieobjecten duidelijk en overzichtelijk aan te kunnen geven waar elk informatieobject in hoofdlijnen over gaat. De beschrijving van het onderwerp is specifiek en dus, in principe, voor elk informatieobject anders. Het gaat dus nadrukkelijk niet om een waarde uit een gesloten begrippenlijst (concept). Voor dat doel kan de property dcat:theme worden gebruikt.
2.2.2.3 Property Shape: Informatieobject-theme
URI tooiont:Informatieobject-theme
Subjectklasse tooiont:Informatieobject
Property dcat:theme
Label Thema
Definitie Het thema waaronder het informatieobject valt, uit een voorgedefinieerde verzameling thema’s
Bereik skos:Concept
Kardinaliteit 0..*
Toelichting

Het doel van deze property is om informatieobjecten in te delen volgens een voorgedefinieerd classificatieschema. De concepten in het bereik kunnen uit verschillende conceptschema’s komen. Dit zal per documentcollectie verschillen. Voor instanties van de subklasse tooiont:OfficielePublicatie is de waarde beperkt tot thema’s in de TOP-thesaurus: zie aldaar.

De REP spreekt over onderwerp. Het is duidelijk dat het hier om een thematische aanduiding gaat waarbij de waarde van de property een voorgedefinieerd concept is. We houden hier vast aan de terminologie van Thema-indeling Overheidspublicaties (TOP) en gebruiken de termen thema (dcat:theme) en onderwerp (tooiont:onderwerp) overeenkomstig.

(REP, onderwerp)
2.2.2.4 Property Shape: Informatieobject-keyword
URI tooiont:Informatieobject-keyword
Subjectklasse tooiont:Informatieobject
Property dcat:keyword
Label Trefwoord
Definitie Een term die kan fungeren als criterium voor groeperen van informatieobjecten, of als zoekterm voor indexeren
Bereik xsd:string
Kardinaliteit 0..*
Toelichting Het doel van deze property is om informatieobjecten met maximale flexibiliteit in te delen volgens een vrij, informeel en onbeheerd classificatieschema.
2.2.2.5 Property Shape: Informatieobject-omschrijving
URI tooiont:Informatieobject-omschrijving
Subjectklasse tooiont:Informatieobject
Property tooiont:omschrijving
Label Omschrijving
Definitie Een tekstuele beschrijving in enkele zinnen van het onderwerp van het informatieobject
Bereik xsd:string
Kardinaliteit 0..*
Toelichting Het doel van deze property is om bij het presenteren van een beperkte selectie van informatieobjecten in meer detail aan te kunnen geven waar elk informatieobject over gaat, in de vorm van een samenvatting.
2.2.2.6 Property Shape: Informatieobject-language
URI tooiont:Informatieobject-language
Subjectklasse tooiont:Informatieobject
Property dcterms:language
Label Taal
Definitie De taal waarin het informatieobject is opgesteld (REP, taal)
Bereik skos:Concept
Kardinaliteit 0..*
Toelichting De waarde van deze property is een concept uit het schema tooixtrn:taal

2.2.3 Naamgeving

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.

2.2.3.1 Property Shape: Informatieobject-titel
URI tooiont:Informatieobject-titel
Subjectklasse tooiont:Informatieobject
Property tooiont:titel
Label Titel
Definitie De titel van het informatieobject
Bereik xsd:string
Kardinaliteit 0..*
2.2.3.2 Property Shape: Informatieobject-officieleTitel
URI tooiont:Informatieobject-officieleTitel
Subjectklasse tooiont:Informatieobject
Property tooiont:officieleTitel
Label Officiële titel
Definitie De officiële titel van het informatieobject (REP, officiële titel)
Bereik xsd:string
Kardinaliteit 1..1
2.2.3.3 Property Shape: Informatieobject-verkorteTitel
URI tooiont:Informatieobject-verkorteTitel
Subjectklasse tooiont:Informatieobject
Property tooiont:verkorteTitel
Label Verkorte titel
Definitie De verkorte titel van het informatieobject
Bereik xsd:string
Kardinaliteit 0..*
2.2.3.4 Property Shape: Informatieobject-citeertitel
URI tooiont:Informatieobject-citeertitel
Subjectklasse tooiont:Informatieobject
Property tooiont:citeertitel
Label Citeertitel
Definitie De citeertitel is de wijze waarop een informatieobject, blijkens een bepaling in dat informatieobject zelf, wordt aangeduid (REP, citeertitel)
Bereik xsd:string
Kardinaliteit 0..*
2.2.3.5 Property Shape: Informatieobject-alternatieveTitel
URI tooiont:Informatieobject-alternatieveTitel
Subjectklasse tooiont:Informatieobject
Property tooiont:alternatieveTitel
Label Alternatieve titel
Definitie De alternatieve titel van het informatieobject
Bereik xsd:string
Kardinaliteit 0..*
2.2.3.6 Property Shape: Informatieobject-afkorting
URI tooiont:Informatieobject-afkorting
Subjectklasse tooiont:Informatieobject
Property tooiont:afkorting
Label Afkorting
Definitie De afkorting van de titel van het informatieobject
Bereik xsd:string
Kardinaliteit 0..*
2.2.3.7 Property Shape: Informatieobject-verwijzingKort
URI tooiont:Informatieobject-verwijzingKort
Subjectklasse tooiont:Informatieobject
Property tooiont:verwijzingKort
Label Verwijzing kort
Definitie De verkorte aanduiding waarmee naar het informatieobject verwezen dient te worden
Bereik xsd:string
Kardinaliteit 0..1
Toelichting Bijvoorbeeld: “art 257b Sv”
2.2.3.8 Property Shape: Informatieobject-verwijzingLang
URI tooiont:Informatieobject-verwijzingLang
Subjectklasse tooiont:Informatieobject
Property tooiont:verwijzingLang
Label Verwijzing lang
Definitie De lange aanduiding waarmee naar het informatieobject verwezen dient te worden
Bereik xsd:string
Kardinaliteit 0..1
Toelichting Bijvoorbeeld: “artikel 257b van het Wetboek van Strafrecht”

2.2.4 Provenance

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.

2.2.4.1 Property Shape: Informatieobject-verantwoordelijke
URI tooiont:Informatieobject-verantwoordelijke
Subjectklasse tooiont:Informatieobject
Property tooiont:verantwoordelijke
Label Verantwoordelijke
Definitie Overheidsorganisatie die de wettelijke verantwoordelijkheid draagt voor de inhoud (strekking) van het informatieobject
Bereik tooiont:Overheidsorganisatie
Kardinaliteit 0..1
Toelichting

Zie ook tooiont:opsteller en tooiont:creatiedatum.

Over het algemeen geldt dat als een derde partij geïnteresseerd is in de dcterms:creator van een informatieobject in een KOOP-collectie, het meestal de verantwoordelijke betreft: deze partij is in de context van overheidsinformatie voor de meeste doeleinden relevanter dan de opsteller van de informatie.

(REP, verantwoordelijke)
2.2.4.2 Property Shape: Informatieobject-soortBesluitendOrgaan
URI tooiont:Informatieobject-soortBesluitendOrgaan
Subjectklasse tooiont:Informatieobject
Property tooiont:soortBesluitendOrgaan
Label Soort besluitend orgaan
Definitie Het soort orgaan dat verantwoordelijk is voor het besluit dat de strekking is van het informatieobject (indien van toepassing).
Bereik skos:Concept
Kardinaliteit 0..*
Toelichting De concepten voor deze property zijn gedefinieerd in het conceptschema tooikern:bestuursorgaan. Voorbeelden zijn B&W en de gemeenteraad. (REP, vastgesteld door)
2.2.4.3 Property Shape: Informatieobject-publicatiedatum
URI tooiont:Informatieobject-publicatiedatum
Subjectklasse tooiont:Informatieobject
Property tooiont:publicatiedatum
Label Publicatiedatum
Definitie Datum van publicatie
Bereik xsd:date or xsd:gYearMonth or xsd:gYear
Kardinaliteit 0..1
Toelichting REP, publicatiedatum
2.2.4.4 Property Shape: Informatieobject-publisher
URI tooiont:Informatieobject-publisher
Subjectklasse tooiont:Informatieobject
Property dcterms:publisher
Label Openbaar gemaakt door
Definitie De entiteit die verantwoordelijk is voor het publiceren van het informatieobject, meer in het bijzonder de partij die de plicht heeft tot actieve openbaarmaking ervan
Bereik tooiont:Overheidsorganisatie
Kardinaliteit 0..1
Toelichting Het gaat hier dus om de organisatie die verantwoordelijk is voor het publiceren. BZK (waar KOOP een afdeling van is) verzorgt voor veel publicaties de technische aspecten van het publiceren, maar doet dit vaak namens andere partijen. De gemeente die een officiële bekendmaking ter publicatie aan KOOP aanbiedt is de dcterms:publisher en ook de tooiont:verantwoordelijke. Deze twee properties kunnen ook verschillende waarden hebben, bijvoorbeeld als een gemeente een dossier publiceert met daarin een brief van de minister. In dat geval is de gemeente de dcterms:publisher terwijl de minister de tooiont:verantwoordelijke is. Beide properties zijn optioneel.
2.2.4.5 Property Shape: Informatieobject-opsteller
URI tooiont:Informatieobject-opsteller
Subjectklasse tooiont:Informatieobject
Property tooiont:opsteller
Label Opsteller
Definitie De actor die het informatieobject opgesteld heeft
Bereik foaf:Agent
Kardinaliteit 0..1
Toelichting

Er is geen algemene regel te geven voor welke actor als opsteller van een informatieobject beschouwd moet worden. Dit kan per collectie worden vastgesteld. Een vuistregel is dat als de verantwoordelijke voor de inhoud (tooiont:verantwoordelijke) en de opsteller dezelfde organisatie is, alleen de verantwoordelijke wordt vastgelegd.

Voorbeelden:

  • Een gemeente publiceert een bouwvergunningsaanvraag, die is ingediend door een particulier. De gemeente is de verantwoordelijke; de particulier is de opsteller. Besloten wordt om alleen de verantwoordelijke vast te leggen

  • Een ministerie geeft een adviesbureau of universiteit opdracht een onderzoek uit te voeren en daarvan een rapport op te stellen. Het ministerie is de eindverantwoordelijke van het rapport en het bureau of universiteit de opsteller. Besloten wordt om zowel verantwoordelijke als maker apart vast te leggen

  • Een kenniscentrum publiceert op haar website documenten die door gemeenten zijn opgesteld. De gemeente is verantwoordelijke en maker van de documenten; besloten wordt om de gemeente alleen als verantwoordelijke vast te leggen.

2.2.4.6 Property Shape: Informatieobject-naamOpsteller
URI tooiont:Informatieobject-naamOpsteller
Subjectklasse tooiont:Informatieobject
Property tooiont:naamOpsteller
Label Naam opsteller
Definitie De naam van de actor die het informatieobject opgesteld heeft
Bereik xsd:string
Kardinaliteit 0..1
Toelichting De naam van de opsteller kan vastgelegd worden als de identiteit van de opsteller niet uit te drukken valt in termen van een in een relevant dan wel bruikbaar register gemunte URI.
2.2.4.7 Property Shape: Informatieobject-creatiedatum
URI tooiont:Informatieobject-creatiedatum
Subjectklasse tooiont:Informatieobject
Property tooiont:creatiedatum
Label Creatiedatum
Definitie Datum waarop het informatieobject gemaakt is
Bereik xsd:date or xsd:gYearMonth or xsd:gYear
Kardinaliteit 0..1
2.2.4.8 Property Shape: Informatieobject-generatedAtTime
URI tooiont:Informatieobject-generatedAtTime
Subjectklasse tooiont:Informatieobject
Property prov:generatedAtTime
Label Tijdstip aangemaakt
Definitie Het tijdstip waarop het informatieobject is gegenereerd, waarna het bestaat.
Bereik xsd:dateTime
Kardinaliteit 0..*
Toelichting Als dcterms:created gespecificeerd is en prov:generatedAtTime ook, dan moet het datumgedeelte van de laatstgenoemde waarde gelijk zijn aan de creatiedatum.

2.2.5 Historie, zichtdatum, peildatum

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.

2.2.5.1 Property Shape: Informatieobject-peildatum
URI tooiont:Informatieobject-peildatum
Subjectklasse tooiont:Informatieobject
Property tooiont:peildatum
Label peildatum
Definitie De datum waarop een toestand zich voordeed
Bereik xsd:date
Kardinaliteit 0..1
Toelichting In de context van een TOOI-waardelijst betreft dit de datum waarop de beschreven toestand zich voordeed voor zover die op de zichtdatum bekend was
2.2.5.2 Property Shape: Informatieobject-zichtdatum
URI tooiont:Informatieobject-zichtdatum
Subjectklasse tooiont:Informatieobject
Property tooiont:zichtdatum
Label Zichtdatum
Definitie De datum van waaruit een toestand beschouwd wordt
Bereik xsd:date
Kardinaliteit 0..1
Toelichting In de context van een TOOI-waardelijst betreft dit de datum die bepaalt welke toestandsbeschrijving van toepassing was op de peildatum

2.2.6 Manifestaties (bestanden)

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’.

2.2.6.1 Property Shape: Informatieobject-format
URI tooiont:Informatieobject-format
Subjectklasse tooiont:Informatieobject
Property dcterms:format
Label Format
Definitie Het format (bijvoorbeeld XML, PDF, CSV) waarin het informatieobject zich manifesteert
Bereik skos:Concept
Kardinaliteit 0..*
Toelichting De waarde van deze property is een concept uit het schema tooixtrn:file-type
2.2.6.2 Property Shape: Informatieobject-heeftRealisatie
URI tooiont:Informatieobject-heeftRealisatie
Subjectklasse tooiont:Informatieobject
Property tooiont:heeftRealisatie
Label Heeft realisatie
Definitie Een realisatie van het informatieobject in de vorm van een fysiek bestand
Bereik xsd:anyURI
Kardinaliteit 0..1
Toelichting Telkens als de URL die de waarde is van deze property wordt meegegeven in een http-request wordt er een realisatie geretourneerd. Met ‘realisatie’ wordt hetzelfde bedoeld als het FRBR-begrip ‘Item’. Het is een fysiek exemplaar van het beschreven informatieobject (een manifestatie)

2.2.7 Aggregatie

2.2.7.1 Drie manieren om aggregatie vast te leggen

Een informatieobject kan deel uitmaken van een aggregatie, dat wil zeggen een verzameling informatieobjecten, zoals een dossier of een collectie. TOOI biedt drie manieren waarop dat kan worden vastgelegd.

2.2.7.1.1 Aggregatiekenmerk

De eerste manier om aggregatie vast te leggen is door een waarde te specificeren voor de property tooiont:aggregatiekenmerk. Als verschillende informatieobjecten dezelfde waarde voor deze property hebben, dan worden deze beschouwd als een documentaggregatie. Applicaties kunnen dit dan gebruiken om documenten als groep te presenteren.

Het is aan de metadaterende partij om te zorgen dat de aangeleverde aggregatiekenmerken “globally unique” zijn. Een kenmerk als “2021-135” wordt daarom afgeraden: als een andere partij per ongeluk hetzelde kenmerk gebruikt, zal een applicatie de informatieobjecten van beide partijen samenvoegen in dezelfde aggregatie. Binnen de context van een applicatie of collectie kunnen met betrekking tot de toegestane waarden nadere afspraken gemaakt worden.

De aggregatie als zodanig (een dossier, een zaak of een andere verzameling) wordt hierbij niet gemodelleerd en krijgt dan ook geen URI. Er kan alleen indirect naar verwezen worden. Het volgende plaatje illustreert dit: de informatieobjecten A en B delen een aggregatiekenmerk en horen dus bij een aggregatie, maar deze is in TOOI-termen niet zichtbaar, zoals de stippellijn aangeeft.

Aggregatiekenmerk
Figuur 5 Aggregatiekenmerk
2.2.7.1.2 Gecomprimeerd bestand

De tweede manier om vast te leggen dat er sprake is van documentaggregatie is van toepassing wanneer een informatieobject een gecomprimeerd bestand is, dat bijvoorbeeld een Wob-dossier representeert. De aanleverende partij kan er voor kiezen om het dossier en de dossierstukken apart aan te leveren en te metadateren — dat is de derde optie die verderop wordt beschreven. Bij deze tweede optie levert de aanleverende partij simpelweg een gecomprimeerd bestand aan. Het is noodzakelijk om aan te geven wat het bestandstype is door middel van dcterms:format. Een eindgebruiker kan het gecomprimeerde bestand uitpakken en de resulterende bestanden inzien en gebruiken, maar deze zijn in dit patroon verder niet gemetadateerd. Het volgende plaatje illustreert dit: de informatieobjecten A en B maken deel uit van het gecomprimeerde bestand C, maar deze zijn niet beschreven in termen van TOOI-metadata, evenmin als de relatie “maakt deel uit van” — vandaar de stippellijnen.

Gecomprimeerd bestand
Figuur 6 Gecomprimeerd bestand
2.2.7.1.3 De aggregatierelatie

De derde optie om aggregatie vast te leggen is door de relatie tussen een informatieobject en de aggregatie waar deze bijhoort expliciet te maken. De klasse tooiont:SamengesteldInformatieobject is gedefinieerd als de subklasse van tooiont:Informatieobject waarvoor geldt dat het informatieobject nul of meerdere informatieobjecten bevat. De relatie waar het daarbij om gaat is dcterms:isPartOf. Ontologische gezien kunnen diverse part-of-relaties worden onderscheiden. TOOI beperkt het gebruik van dcterms:isPartOf om een relatie aan te duiden met de volgende karakteristieken:

  • De relatie is transitief. Als een document deel uitmaakt van de documentlevering, en de documentlevering maakt samen met de aanvraag en de beschikking deel uit van een Wob-dossier, dan maakt het document ook deel uit van het Wob-dossier. (Dit is niet geformaliseerd in de zin van owl:TransitiveProperty, maar mag wel afgeleid worden als dcterms:isPartOf gebruikt wordt bij het beschrijven van instanties van tooiont:Informatieobject.)
  • De relatie van het deel met het geheel is niet exclusief. Een document kan deel uit maken van meerdere Wob-dossiers
  • De relatie is contingent, dat wil zeggen dat de identiteit van de delen en de identiteit van het geheel onafhankelijk van elkaar zijn

TOOI beperkt het bereik van dcterms:isPartOf tot tooiont:SamengesteldInformatieobject. Een instantie van tooiont:SamengesteldInformatieobject kan uiteraard alle properties hebben die gedefinieerd zijn voor tooiont:Informatieobject. Ook een samengesteld informatieobject kan een een realisatie in de vorm van een bestand hebben (tooiont:heeftRealisatie); in dat geval dient een waarde voor dcterms:format gespecificeerd te zijn die staat voor een gecomprimeerde bestandsvorm, zoals file-type:ZIP. Een samengesteld informatieobject heeft optioneel een waarde voor tooiont:soortSamengesteldInformatieobject. Dit is een concept uit het conceptschema tooikern:samengesteldInformatieobject. Het volgende schema (met labels in plaats van URIs) illustreert dit:

UML Klassediagram samengesteld informatieobject
Figuur 7 UML-Klassediagram voor Samengesteld informatieobject

Noot. De property dcterms:isPartOf wordt ook wel opgevat als een compositie- in plaats van aggregatierelatie. Binnen TOOI geldt dat deze noties niet in formele zin gebruikt worden omdat ze ontologisch gezien onvoldoende helder zijn. PROV-O kent de property prov:hasMember, met als domein prov:Collection. PROV-O definieert deze property als volgt: “A collection is an entity that provides a structure to some constituents, which are themselves entities. These constituents are said to be member of the collections.” In het document dat de mapping van DCMI[DC11] naar PROV beschrijft wordt de DCMI-property van mapping uitgesloten (“Since entity composition is out of the scope of PROV, this property has been excluded from the mapping”). De DCMI- en PROV-O-properties kunnen dus zonder bezwaar naast elkaar gebruikt worden. In het voorbeeld dat PROV-O gebruikt (leden van het Amerikaanse Supreme Court) blijkt dat het hier gaat om een niet-transitieve part-of-relatie.

Voorbeeld: een Wob-Dossier

Het volgende schema illustreert de drie opties om aggregatie te beschrijven met het TOOI-vocabulaire. Dit aan de hand van een dossier getiteld “Wob-Dossier X” dat drie informatieobjecten bevat: een aanvraag, een beschikking, en de bestandslevering — een gecomprimeerd bestand met daarin de vrijgegeven bestanden. Stippellijntjes geven aan dat het betreffende element (object of relatie) niet expliciet uitgedrukt kan worden met het TOOI-vocabulaire. Samengestelde informatieobjecten zijn oranje, andere informatieobjecten zijn grijs.

Aggregatieopties: voorbeelden
Figuur 8 Aggregatieopties: voorbeelden

De Bestandslevering in Optie 3 kan, inclusief de bestanden die het bevat, desgewenst ook weer beschreven worden als een samengesteld informatieobject met de (al dan niet enkelvoudige) informatieobjecten die er deel van uitmaken. De relatie is immers recursief gedefinieerd.

2.2.7.1.4 Property Shape: Informatieobject-aggregatiekenmerk
URI tooiont:Informatieobject-aggregatiekenmerk
Subjectklasse tooiont:Informatieobject
Property tooiont:aggregatiekenmerk
Label Aggregatiekenmerk
Definitie Het kenmerk op basis waarvan verschillende informatieobjecten gemarkeerd zijn als horende bij een dossier, zaak of andersoortige aggregatie
Bereik xsd:string
Kardinaliteit 0..*
Toelichting Het is aan de metadaterende partij om te zorgen dat de aangeleverde aggregatiekenmerken “globally unique” zijn. Een kenmerk als “2021-135” wordt afgeraden. De aggregatie als zodanig (een dossier, een zaak of een andere verzameling) wordt hierbij niet gemodelleerd en krijgt dan ook geen URI.
2.2.7.1.5 Property Shape: Informatieobject-isPartOf
URI tooiont:Informatieobject-isPartOf
Subjectklasse tooiont:Informatieobject
Property dcterms:isPartOf
Label Maakt deel uit van
Definitie Het samengesteld informatieobject (bijvoorbeeld dossier) waar het beschreven informatieobject deel van uitmaakt
Bereik tooiont:SamengesteldInformatieobject
Kardinaliteit 0..1
2.2.7.1.6 Klasse: Samengesteld informatieobject
URI tooiont:SamengesteldInformatieobject
Label Samengesteld informatieobject
Definitie Een informatieobject dat andere informatieobjecten bevat
Subklasse van tooiont:Informatieobject

Een instantie van tooiont:SamengesteldInformatieobject kan de volgende property hebben:

2.2.7.1.7 Property Shape: SamengesteldInformatieobject-soortSamengesteldInformatieobject
URI tooiont:SamengesteldInformatieobject-soortSamengesteldInformatieobject
Subjectklasse tooiont:SamengesteldInformatieobject
Property tooiont:soortSamengesteldInformatieobject
Label Soort samengesteld informatieobject
Definitie De soort aggregatie, zoals aangeduid door het concept
Bereik skos:Concept
Kardinaliteit 0..*

2.2.8 Versies van informatieobjecten

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.

Revisie
Figuur 9 Revisie
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:

Specialisatie
Figuur 10 Revisie

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.

Specialisatie
Figuur 11 Specialisatie
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.

Vervanging
Figuur 12 Vervanging

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:

Dubbele vervanging
Figuur 13 Dubbele vervanging

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’.

Manifestatie
Figuur 14 Manifestatie

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.

Manifestatie, versie, werk
Figuur 15 Manifestatie, versie, werk

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’.

Manifestatie, versie, werk, vervanging
Figuur 16 Manifestatie, versie, werk, 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.

2.2.8.4 Klassen en properties
2.2.8.4.1 Property Shape: Informatieobject-specializationOf
URI tooiont:Informatieobject-specializationOf
Subjectklasse tooiont:Informatieobject
Property prov:specializationOf
Label Versie van
Definitie Het informatieobject waar dit informatieobject een meer specifieke vorm van van vertegenwoordigt
Bereik tooiont:Informatieobject
Kardinaliteit 0..*
Toelichting Voorbeelden zijn de relaties tussen een versie (expressie) en een werk, en tussen een manifestatie en een versie (expressie). Dit valt onder de meer algemene definitie in PROV-O. Die luidt als volgt (vertaald naar het Nederlands): “Een prov:Entity die een specialisatie is van een andere deelt alle aspecten van de laatstgenoemde, en heeft daarenboven meer specifieke aspecten van hetzelfde ding als laatstgenoemde. Meer in het bijzonder, de levensloop van de entiteit waarvan een specialisatie wordt afgeleid omvat de levensloop van iedere specialisatie van deze entiteit. Voorbeelden zijn een tijdsperiode, een abstractie en een context gerelateerd aan de entiteit.”
2.2.8.4.2 Property Shape: Informatieobject-wasRevisionOf
URI tooiont:Informatieobject-wasRevisionOf
Subjectklasse tooiont:Informatieobject
Property prov:wasRevisionOf
Label Revisie van
Definitie Het informatieobject waar dit informatieobject een nieuwe, aangepaste versie van vertegenwoordigt
Bereik tooiont:Informatieobject
Kardinaliteit 0..*
Toelichting De meer algemene definitie in PROV-O luidt als volgt. Een revisie is een derivatie waarbij het de resulterende entiteit (in de zin van prov:Entity) een gereviseerde versie is van een origineel. De implicatie hierbij is dat de resulterende entiteit substantieel inhoud bevat van het origineel
2.2.8.4.3 Property Shape: Informatieobject-replaces
URI tooiont:Informatieobject-replaces
Subjectklasse tooiont:Informatieobject
Property dcterms:replaces
Label Vervangt
Definitie Het informatieobject dat wordt vervangen door het beschreven informatieobject
Bereik tooiont:Informatieobject
Kardinaliteit 0..*
2.2.8.4.4 Property Shape: Informatieobject-redenVervanging
URI tooiont:Informatieobject-redenVervanging
Subjectklasse tooiont:Informatieobject
Property tooiont:redenVervanging
Label Reden vervanging
Definitie De reden dat het beschreven informatieobject een ander vervangen heeft
Bereik skos:Concept
Kardinaliteit 0..1
Toelichting De concepten voor deze property zijn gedefinieerd in het conceptschema tooikern:redenIntrekkingOfVervanging
2.2.8.4.5 Property Shape: Informatieobject-datumVervanging
URI tooiont:Informatieobject-datumVervanging
Subjectklasse tooiont:Informatieobject
Property tooiont:datumVervanging
Label Datum vervanging
Definitie De datum waarop de vervanging ingegaan is
Bereik xsd:date
Kardinaliteit 0..1

2.2.9 Documentrelaties

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:

Overzicht documentrelaties
Figuur 17 Overzicht documentrelaties

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):

Voorbeelden documentrelaties
Figuur 18 Voorbeelden documentrelaties

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

2.2.9.1 Betrokkenheid

De betrokkenheid van een persoon of organisatie bij een document wordt gemedieerd door een instantie van de klasse tooiont:Betrokkenheid.

2.2.9.1.1 Klasse: Betrokkenheid
URI tooiont:Betrokkenheid
Label Betrokkenheid
Definitie Betrokkenheid is een relatie tussen een informatieobject en een organisatie of persoon die invloed heeft gehad op het informatieobject, of die invloed van het informatieobject ondervonden heeft.
2.2.9.1.2 Property Shape: Informatieobject-gekwalificeerdeBetrokkenheid
URI tooiont:Informatieobject-gekwalificeerdeBetrokkenheid
Subjectklasse tooiont:Informatieobject
Property tooiont:gekwalificeerdeBetrokkenheid
Label Gekwalificeerde betrokkenheid
Definitie De nader gespecificeerde betrokkenheid horende bij het informatieobject
Bereik tooiont:Betrokkenheid
Kardinaliteit 0..*

Een instantie van tooiont:Betrokkenheid kan de volgende properties hebben:

2.2.9.1.3 Property Shape: Betrokkenheid-betrokkene
URI tooiont:Betrokkenheid-betrokkene
Subjectklasse tooiont:Betrokkenheid
Property tooiont:betrokkene
Label Betrokkene
Definitie De betrokken persoon of organisatie
Bereik foaf:Agent
Kardinaliteit 0..1
Toelichting Deze property is verplicht als tooiont:naamBetrokkene niet gespecificeerd is en dient anders niet gebruikt te worden
2.2.9.1.4 Property Shape: Betrokkenheid-naamBetrokkene
URI tooiont:Betrokkenheid-naamBetrokkene
Subjectklasse tooiont:Betrokkenheid
Property tooiont:naamBetrokkene
Label Naam betrokkene
Definitie De naam van de betrokken persoon of organisatie
Bereik xsd:string
Kardinaliteit 0..1
Toelichting Deze property kan gebruikt worden voor gevallen waarin er geen URI gemunt kan worden voor de persoon of organisatie. Dit kan ook de naam zijn van bijvoorbeeld een café of een actiegroep. Deze property is verplicht als tooiont:betrokkene niet gespecificeerd is en dient anders niet gebruikt te worden
2.2.9.1.5 Property Shape: Betrokkenheid-soortBetrokkenheid
URI tooiont:Betrokkenheid-soortBetrokkenheid
Subjectklasse tooiont:Betrokkenheid
Property tooiont:soortBetrokkenheid
Label Soort betrokkenheid
Definitie De rol die de betrokkene had ten opzichte van het informatieobject.
Bereik dcat:Role
Kardinaliteit 1..1
Toelichting

De properties dcat:hadRole en prov:hadRole zijn niet bruikbaar wegens de betreffende domeindefinities.

De concepten voor deze property zijn gedefinieerd in het conceptschema tooikern:betrokkenheid.
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:

Voorbeeld juridische grondslag
Figuur 19 Voorbeeld juridische grondslag

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.
2.2.9.3 Document-documentrelatie

Een relatie tussen een document en een document, niet zijnde een van de reeds besproken relaties, wordt gemedieerd door een instantie van dcat:Relationship. Zie [vocab-dcat-2] voor nadere informatie. De relatie van een informatieobject naar een instantie van dcat:Relationship wordt uitgedrukt met de property dcat:qualifiedRelation:

2.2.9.3.1 Property Shape: Informatieobject-qualifiedRelation
URI tooiont:Informatieobject-qualifiedRelation
Subjectklasse tooiont:Informatieobject
Property dcat:qualifiedRelation
Label Relatie
Definitie De relatie tussen een informatieobject en een nader gespecificeerde document-documentrelatie
Bereik dcat:Relationship
Kardinaliteit 0..*

Dit levert een uitbreidbare verzameling relaties, waarbij nieuwe relaties toegevoegd kunnen worden door middel van een concept in een taxonomie.

2.2.10 Documenthandeling

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:

2.2.10.1 Klasse: Documenthandeling
URI tooiont:Documenthandeling
Label Documenthandeling
Definitie Een handeling die een bestaand informatieobject van toestand doet veranderen, dan wel een nieuw informatieobject doet ontstaan
Subklasse van prov:Activity
Toelichting Voorbeeld van een toestandswijziging: het document is ter inzage gelegd. Voorbeeld van een nieuw informatieobject doen ontstaan: het document is gewijzigd en er ontstaat een nieuwe versie van het document

Een instantie van tooiont:Documenthandeling kan de volgende properties hebben:

2.2.10.2 Property Shape: Documenthandeling-used
URI tooiont:Documenthandeling-used
Subjectklasse tooiont:Documenthandeling
Property prov:used
Label Informatieobject
Definitie Het informatieobject of de informatieobjecten waar de handeling op uitgevoerd wordt
Bereik tooiont:Informatieobject
Kardinaliteit 1..*
2.2.10.3 Property Shape: Documenthandeling-date
URI tooiont:Documenthandeling-date
Subjectklasse tooiont:Documenthandeling
Property dcterms:date
Label Datum handeling
Definitie De datum waarop handeling plaatsvond
Bereik xsd:date or xsd:gYearMonth or xsd:gYear
Kardinaliteit 0..1
2.2.10.4 Property Shape: Documenthandeling-atTime
URI tooiont:Documenthandeling-atTime
Subjectklasse tooiont:Documenthandeling
Property prov:atTime
Label Tijdstip handeling
Definitie Het tijdstip van handeling. Wanneer zowel dcterms:date als prov:atTime zijn gespecificeerd, dan moet het datumgedeelte in de een overeenkomen met de ander
Bereik xsd:dateTime
Kardinaliteit 0..1
2.2.10.5 Property Shape: Documenthandeling-wasAssociatedWith
URI tooiont:Documenthandeling-wasAssociatedWith
Subjectklasse tooiont:Documenthandeling
Property prov:wasAssociatedWith
Label Uitgevoerd door
Definitie De entiteit die de handeling heeft uitgevoerd of namens wie de handeling is uitgevoerd
Bereik tooiont:Overheidsorganisatie
Kardinaliteit 0..1
2.2.10.6 Property Shape: Documenthandeling-soortHandeling
URI tooiont:Documenthandeling-soortHandeling
Subjectklasse tooiont:Documenthandeling
Property tooiont:soortHandeling
Label Soort handeling
Definitie De soort documenthandeling
Bereik skos:Concept
Kardinaliteit 1..1

2.2.11 Informatieobjecten en geometrie

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.

2.2.11.1 Property Shape: Informatieobject-heeftWerkingsgebied
URI tooiont:Informatieobject-heeftWerkingsgebied
Subjectklasse tooiont:Informatieobject
Property tooiont:heeftWerkingsgebied
Label Heeft werkingsgebied
Definitie Het gebied waar een juridisch instrument of onderdeel daarvan van toepassing is
Bereik tooiont:JuridischeRuimte
Kardinaliteit 0..*
2.2.11.2 Property Shape: Informatieobject-heeftEffectgebied
URI tooiont:Informatieobject-heeftEffectgebied
Subjectklasse tooiont:Informatieobject
Property tooiont:heeftEffectgebied
Label Heeft effectgebied
Definitie Het gebied waar een effect optreedt en dat als zodanig in een overheidsinformatieobject benoemd wordt
Bereik tooiont:JuridischeRuimte
Kardinaliteit 0..*
Toelichting Een voorbeeld is het effectgebied waar aardbevingsschade in Groningen toegeschreven kan worden aan door gasonttrekking veroorzaakte seismische activiteit

2.3 Subklassen van Informatieobject en hun specifieke properties

TOOI onderscheidt de volgende subklassen van tooiont:Informatieobject:

2.3.1 Officiële publicatie

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.

2.3.1.1 Klasse: Officiële publicatie
URI tooiont:OfficielePublicatie
Label Officiële publicatie
Definitie Een document waarvan wettelijk is bepaald dat deze moet worden gepubliceerd in een van de publicatiebladen
Subklasse van tooiont:Informatieobject

De properties die horen bij instanties van tooiont:OfficielePublicatie:

2.3.1.2 Property Shape: OfficielePublicatie-rubriek
URI tooiont:OfficielePublicatie-rubriek
Subjectklasse tooiont:OfficielePublicatie
Property tooiont:rubriek
Label Rubriek
Definitie De soort publicatie, bijvoorbeeld algemeen verbindend voorschrift of beleidsregel. Dit veld bepaalt (onder meer) de rubrieksindeling op https://www.officielebekendmakingen.nl.
Bereik skos:Concept
Kardinaliteit 0..*
Toelichting Het bereik is beperkt tot concepten in het conceptschema tooiwep:rubriek. Noot: In OWMS 4.0 heette het begrip rubriek nog “informatietype”. De naam “rubriek” drukt de betekenis van de property beter uit.
2.3.1.3 Property Shape: OfficielePublicatie-publicatieblad
URI tooiont:OfficielePublicatie-publicatieblad
Subjectklasse tooiont:OfficielePublicatie
Property tooiont:publicatieblad
Label Publicatieblad
Definitie Het blad, gerepresenteerd door een concept uit het conceptschema tooikern:publicatieblad
Bereik skos:Concept
Kardinaliteit 0..1
Toelichting In de metadata op officielebekendmakingen.nl heet deze “overheidop.publicationName”. In STOP is dit data:publicatieblad
2.3.1.4 Property Shape: OfficielePublicatie-publicatiejaargang
URI tooiont:OfficielePublicatie-publicatiejaargang
Subjectklasse tooiont:OfficielePublicatie
Property tooiont:publicatiejaargang
Label Publicatiejaargang
Definitie De jaargang van het blad
Bereik xsd:gYear
Kardinaliteit 0..1
Toelichting In de metadata op officielebekendmakingen.nl heet deze “overheidop.jaargang”. In STOP is dit data:jaargang
2.3.1.5 Property Shape: OfficielePublicatie-publicatienummer
URI tooiont:OfficielePublicatie-publicatienummer
Subjectklasse tooiont:OfficielePublicatie
Property tooiont:publicatienummer
Label Publicatienummer
Definitie Het volgnummer binnen de jaargang van het blad
Bereik xsd:integer
Kardinaliteit 0..1
Toelichting In de metadata op officielebekendmakingen.nl heet deze “overheidop.publicationIssue”. In STOP is dit data:publicatienummer
2.3.1.6 Property Shape: OfficielePublicatie-opcode
URI tooiont:OfficielePublicatie-opcode
Subjectklasse tooiont:OfficielePublicatie
Property tooiont:opcode
Label opcode
Definitie De code waarmee volgens de gangbare coderingssystematiek een officiële publicatie uniek wordt aangeduid. Deze bestaat uit de afkorting voor het publicatieblad, de jaargang en het volgnummer, gescheiden door ‘-’. Bijvoorbeeld “gmb-2020-25”
Bereik xsd:string
Kardinaliteit 0..1
Toelichting Nota bene: REP heeft daarnaast “Bij elektronische bekendmaking wordt ook een URL opgenomen.” In de huidige context fungeert de URI van de bekendmaking tevens als URL. In de metadata op officielebekendmakingen.nl heet deze overheidop.publicationIdentifier. In STOP is dit data:publicatieIdentifier

2.3.2 De officiële publicatiebladen

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.

2.3.2.1 Afkondigingsblad
URI tooikern:c_852da199
prefLabel Afkondigingsblad
altLabel AB
Omschrijving Het blad waarin bekendmakingen worden gepubliceerd van Caribische Openbare Lichamen. Dit blad gaat thans nog niet mee in de digitale systematiek van de overige bladen
Voorbeeld-URI van bekendmaking nvt
2.3.2.2 Blad gemeenschappelijke regeling
URI tooikern:c_12cd7b9b
prefLabel Blad gemeenschappelijke regeling
altLabel Bgr
Omschrijving Het blad waarin bekendmakingen van organisaties die gevormd zijn op basis van een gemeenschappelijke regeling worden gepubliceerd
Voorbeeld-URI van bekendmaking https://officielebekendmakingen.nl/bgr-2020-424
2.3.2.3 Gemeenteblad
URI tooikern:c_81cc2eb5
prefLabel Gemeenteblad
altLabel Gmb
Omschrijving Het blad waarin bekendmakingen van gemeenten worden gepubliceerd
Voorbeeld-URI van bekendmaking https://officielebekendmakingen.nl/gmb-2020-25
2.3.2.4 Provinciaal blad
URI tooikern:c_bdc265d5
prefLabel Provinciaal blad
altLabel Prb
Omschrijving Het blad waarin bekendmakingen van provincies worden gepubliceerd
Voorbeeld-URI van bekendmaking https://officielebekendmakingen.nl/prb-2020-2507
2.3.2.5 Staatsblad
URI tooikern:c_61e3099a
prefLabel Staatsblad
altLabel Stb
Omschrijving Het Staatsblad van het Koninkrijk der Nederlanden is een blad waarin de Nederlandse regering wetten (in formele zin), algemene maatregelen van bestuur en andere koninklijke besluiten waarbij algemeen verbindende voorschriften worden vastgesteld, bekendmaakt
Voorbeeld-URI van bekendmaking https://officielebekendmakingen.nl/stb-2020-119
2.3.2.6 Staatsourant
URI tooikern:c_0670bae1
prefLabel Staatscourant
altLabel Stcrt
Omschrijving De Nederlandse Staatscourant is een digitale uitgave van de Nederlandse regering waarin, onder meer, algemeen verbindende voorschriften worden gepubliceerd die bij ministeriële regeling zijn vastgesteld, of vanwege het Rijk zijn vastgesteld maar niet in het Staatsblad gepubliceerd worden.
Voorbeeld-URI van bekendmaking https://officielebekendmakingen.nl/stcrt-2020-9
2.3.2.7 Tractatenblad
URI tooikern:c_b3179555
prefLabel Tractatenblad
altLabel Trb
Omschrijving Het Tractatenblad van het Koninkrijk der Nederlanden bestaat sinds 1951 en bevat de tekst van en de gegevens over verdragen die het Koninkrijk der Nederlanden met andere staten of volkenrechtelijke organisaties heeft gesloten, alsmede daaraan gerelateerde besluiten.
Voorbeeld-URI van bekendmaking https://officielebekendmakingen.nl/trb-2020-4
2.3.2.8 Waterschapblad
URI tooikern:c_c97b118a
prefLabel Waterschapsblad
altLabel Wsb
Omschrijving Het blad waarin bekendmakingen van waterschappen worden gepubliceerd
Voorbeeld-URI van bekendmaking https://officielebekendmakingen.nl/wsb-2020-3

2.3.3 Gemeenschappelijke regeling

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.

Gemeenschappelijke regelingen en samenwerkingsorganisaties
Figuur 20 Gemeenschappelijke regelingen en samenwerkingsorganisaties
2.3.3.1 Klasse: Gemeenschappelijke regeling
URI tooiont:GemeenschappelijkeRegeling
Label Gemeenschappelijke regeling
Definitie Een regeling uit hoofde van de Wgr of een internationaal verdrag, door middel waarvan twee of meer overheidsorganisaties bevoegdheden overdragen om krachten te bundelen
Subklasse van tooiont:Informatieobject

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

2.3.3.2 Property Shape: GemeenschappelijkeRegeling-soortGemeenschappelijkeRegeling
URI tooiont:GemeenschappelijkeRegeling-soortGemeenschappelijkeRegeling
Subjectklasse tooiont:GemeenschappelijkeRegeling
Property tooiont:soortGemeenschappelijkeRegeling
Label Soort gemeenschappelijke regeling
Definitie De soort regeling (regionaal, landelijk, grensoverschrijdend)
Bereik skos:Concept
Kardinaliteit 0..*
Toelichting De concepten voor deze indeling zijn gedefinieerd in het conceptschema tooikern:SoortGemeenschappelijkeRegeling
2.3.3.3 DeelnameGR
2.3.3.4 Klasse: Deelname gemeenschappelijke regeling
URI tooiont:DeelnameGR
Label Deelname gemeenschappelijke regeling
Definitie Een deelname van een overheidsorganisatie aan een gemeenschappelijke regeling
Subklasse van prov:Entity

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

2.3.3.5 Property Shape: DeelnameGR-begindatum
URI tooiont:DeelnameGR-begindatum
Subjectklasse tooiont:DeelnameGR
Property tooiont:begindatum
Label Begindatum
Definitie De eerste dag waarop de deelname van kracht was, inclusief
Bereik xsd:date
Kardinaliteit 0..1
2.3.3.6 Property Shape: DeelnameGR-einddatum
URI tooiont:DeelnameGR-einddatum
Subjectklasse tooiont:DeelnameGR
Property tooiont:einddatum
Label Einddatum
Definitie De laatste kalenderdag (inclusief) waarop de deelname van kracht was
Bereik xsd:date
Kardinaliteit 0..1
2.3.3.7 Property Shape: DeelnameGR-deelnameAan
URI tooiont:DeelnameGR-deelnameAan
Subjectklasse tooiont:DeelnameGR
Property tooiont:deelnameAan
Label Deelname aan
Definitie De gemeenschappelijke regeling waaraan deelgenomen wordt
Bereik tooiont:GemeenschappelijkeRegeling
Kardinaliteit 0..1
2.3.3.8 Property Shape: DeelnameGR-deelnemer
URI tooiont:DeelnameGR-deelnemer
Subjectklasse tooiont:DeelnameGR
Property tooiont:deelnemer
Label Deelnemer
Definitie De deelnemende overheidsorganisatie
Bereik tooiont:Overheidsorganisatie
Kardinaliteit 0..1
2.3.3.9 Property Shape: DeelnameGR-heeftJuridischeGrondslag
URI tooiont:DeelnameGR-heeftJuridischeGrondslag
Subjectklasse tooiont:DeelnameGR
Property tooiont:heeftJuridischeGrondslag
Label Juridische grondslag
Definitie Wet, regeling of besluit waaraan de deelname zijn rechtsgeldigheid ontleent
Bereik tooiont:Informatieobject
Kardinaliteit 0..*
2.3.3.10 Bronhouderschap
2.3.3.11 Klasse: Bronhouderschap
URI tooiont:Bronhouderschap
Label Bronhouderschap
Definitie De relatie tussen een bronhouder en een gemeenschappelijke regeling
Subklasse van prov:Entity

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

2.3.3.12 Property Shape: Bronhouderschap-begindatum
URI tooiont:Bronhouderschap-begindatum
Subjectklasse tooiont:Bronhouderschap
Property tooiont:begindatum
Label Begindatum
Definitie De eerste dag waarop het bronhouderschap van kracht was.
Bereik xsd:date
Kardinaliteit 0..1
2.3.3.13 Property Shape: Bronhouderschap-einddatum
URI tooiont:Bronhouderschap-einddatum
Subjectklasse tooiont:Bronhouderschap
Property tooiont:einddatum
Label Einddatum
Definitie De laatste kalenderdag (inclusief) waarop het bronhouderschap van kracht was
Bereik xsd:date
Kardinaliteit 0..1
2.3.3.14 Property Shape: Bronhouderschap-regeling
URI tooiont:Bronhouderschap-regeling
Subjectklasse tooiont:Bronhouderschap
Property tooiont:regeling
Label Regeling
Definitie De gemeenschappelijke regeling waar de overheidsorganisatie de bronhouder is
Bereik tooiont:GemeenschappelijkeRegeling
Kardinaliteit 0..1
2.3.3.15 Property Shape: Bronhouderschap-bronhouder
URI tooiont:Bronhouderschap-bronhouder
Subjectklasse tooiont:Bronhouderschap
Property tooiont:bronhouder
Label Bronhouder
Definitie De bronhoudende overheidsorganisatie
Bereik tooiont:Overheidsorganisatie
Kardinaliteit 0..1

2.3.4 Waardelijst

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.

3. Overheidsorganisaties

3.1 Overheidsorganisaties: overzicht

3.1.1 Overheidsorganisaties: Definitie en afbakening

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.

3.1.2 Overheidsorganisaties: Klassediagram

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.

Overzicht overheidsorganisaties
Figuur 21 Overzicht overheidsorganisaties

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

3.1.3 Classificatie van overheidsorganisaties met subklassen van tooiont:Overheidsorganisatie

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.

3.1.4 Classificatie van overheidsorganisaties met tooiont:organisatiesoort

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.

3.2 Overheidsorganisaties en hun properties

3.2.1 De klasse Overheidsorganisatie

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.

3.2.1.1 Klasse: Overheidsorganisatie
URI tooiont:Overheidsorganisatie
Label Overheidsorganisatie
Definitie Een organisatie die namens de overheid taken uitvoert en onder het gezag en toezicht van de overheid valt
Subklasse van prov:Entity , prov:Organization , prov:Agent

3.2.2 Properties van de klasse Overheidsorganisatie

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

3.2.2.1 Property Shape: Overheidsorganisatie-label
URI tooiont:Overheidsorganisatie-label
Subjectklasse tooiont:Overheidsorganisatie
Property rdfs:label
Label Label
Definitie De voorkeursnaam van de organisatie
Bereik xsd:string
Kardinaliteit 1..1
3.2.2.2 Property Shape: Overheidsorganisatie-afkorting
URI tooiont:Overheidsorganisatie-afkorting
Subjectklasse tooiont:Overheidsorganisatie
Property tooiont:afkorting
Label Afkorting
Definitie De afkorting van de naam van de resource
Bereik xsd:string
Kardinaliteit 0..1
3.2.2.3 Property Shape: Overheidsorganisatie-officieleNaamExclSoort
URI tooiont:Overheidsorganisatie-officieleNaamExclSoort
Subjectklasse tooiont:Overheidsorganisatie
Property tooiont:officieleNaamExclSoort
Label Officiële naam exclusief soort
Definitie De officiële naam van de organisatie zonder soortaanduiding, bijvoorbeeld ‘’s-Gravenhage’
Bereik xsd:string
Kardinaliteit 0..1
3.2.2.4 Property Shape: Overheidsorganisatie-officieleNaamInclSoort
URI tooiont:Overheidsorganisatie-officieleNaamInclSoort
Subjectklasse tooiont:Overheidsorganisatie
Property tooiont:officieleNaamInclSoort
Label Officiële naam inclusief soort
Definitie De officiële naam van de organisatie met soortaanduiding, bijvoorbeeld ‘gemeente ’s-Gravenhage’
Bereik xsd:string
Kardinaliteit 0..1
3.2.2.5 Property Shape: Overheidsorganisatie-officieleNaamSorteer
URI tooiont:Overheidsorganisatie-officieleNaamSorteer
Subjectklasse tooiont:Overheidsorganisatie
Property tooiont:officieleNaamSorteer
Label Officiële naam sorteer
Definitie De officiële naam van de organisatie zoals te gebruiken voor het sorteren op alfabetische volgorde, bijvoorbeeld ‘Gravenhage’
Bereik xsd:string
Kardinaliteit 0..1
3.2.2.6 Property Shape: Overheidsorganisatie-voorkeursnaamExclSoort
URI tooiont:Overheidsorganisatie-voorkeursnaamExclSoort
Subjectklasse tooiont:Overheidsorganisatie
Property tooiont:voorkeursnaamExclSoort
Label Voorkeursnaam exclusief soort
Definitie De voorkeursnaam van de organisatie zonder soortaanduiding, bijvoorbeeld ‘Den Haag’
Bereik xsd:string
Kardinaliteit 0..1
3.2.2.7 Property Shape: Overheidsorganisatie-voorkeursnaamInclSoort
URI tooiont:Overheidsorganisatie-voorkeursnaamInclSoort
Subjectklasse tooiont:Overheidsorganisatie
Property tooiont:voorkeursnaamInclSoort
Label Voorkeursnaam inclusief soort
Definitie De voorkeursnaam van de organisatie met soortaanduiding, bijvoorbeeld ‘gemeente Den Haag’
Bereik xsd:string
Kardinaliteit 0..1
3.2.2.8 Property Shape: Overheidsorganisatie-voorkeursnaamSorteer
URI tooiont:Overheidsorganisatie-voorkeursnaamSorteer
Subjectklasse tooiont:Overheidsorganisatie
Property tooiont:voorkeursnaamSorteer
Label Voorkeursnaam sorteer
Definitie De voorkeursnaam van de organisatie zoals te gebruiken voor het sorteren op alfabetische volgorde, bijvoorbeeld ‘Haag’
Bereik xsd:string
Kardinaliteit 0..1
3.2.2.9 Property Shape: Overheidsorganisatie-alternatieveNaam
URI tooiont:Overheidsorganisatie-alternatieveNaam
Subjectklasse tooiont:Overheidsorganisatie
Property tooiont:alternatieveNaam
Label Alternatieve naam
Definitie Een alternatieve naam waarmee de organisatie aangeduid is geworden in een officiële publicatie, niet zijnde de voorkeursnaam of officiële naam
Bereik xsd:string
Kardinaliteit 0..*
3.2.2.10 Property Shape: Overheidsorganisatie-owmsId
URI tooiont:Overheidsorganisatie-owmsId
Subjectklasse tooiont:Overheidsorganisatie
Property tooiont:owmsId
Label Owms ID
Definitie De URI van de corresponderende resource in OWMS 4.0
Bereik xsd:anyURI
Kardinaliteit 0..1
Toelichting Organisaties hebben in TOOI nieuwe URIs gekregen, die verschillen van de OWMS-URIs.
3.2.2.11 Property Shape: Overheidsorganisatie-organisatiecode
URI tooiont:Overheidsorganisatie-organisatiecode
Subjectklasse tooiont:Overheidsorganisatie
Property tooiont:organisatiecode
Label Organisatiecode
Definitie De organisatiecode
Bereik xsd:string
Kardinaliteit 1..1
Toelichting Deze is uniek voor elke organisatie en fungeert bovendien als local name (gegeven de namespace-conventies binnen de registers)
3.2.2.12 Property Shape: Overheidsorganisatie-organisatiesoort
URI tooiont:Overheidsorganisatie-organisatiesoort
Subjectklasse tooiont:Overheidsorganisatie
Property tooiont:organisatiesoort
Label Organisatiesoort
Definitie Het concept in tooikern dat staat voor de organisatiesoort
Bereik skos:Concept
Kardinaliteit 1..*
3.2.2.13 Property Shape: Overheidsorganisatie-generatedAtTime
URI tooiont:Overheidsorganisatie-generatedAtTime
Subjectklasse tooiont:Overheidsorganisatie
Property prov:generatedAtTime
Label Tijdstip oprichting
Definitie Het tijdstip waarop het formele bestaan van de organisatie begon
Bereik xsd:dateTime
Kardinaliteit 0..*
Toelichting

Indien de waarde van deze property gespecificeerd is én de existentiële wijziging waarbij de organisatie ophield te bestaan is geregistreerd, dan is deze waarde gelijk aan de waarde van tooiont:tijdstipWijziging van de betreffende instantie van tooiont:ExistentieleWijziging

Wanneer toegepast op tooiont:HistorischeVersie heeft deze property een andere betekenis, zie aldaar.

Indien niet gespecificeerd betekent dat dat de organisatie nog bestaat. De waarde kan op het moment van beschouwen nog in de toekomst liggen omdat organisatiewijzigingen ook voordat ze formeel ingaan in een register kunnen worden opgenomen.
3.2.2.14 Property Shape: Overheidsorganisatie-invalidatedAtTime
URI tooiont:Overheidsorganisatie-invalidatedAtTime
Subjectklasse tooiont:Overheidsorganisatie
Property prov:invalidatedAtTime
Label Tijdstip opheffing
Definitie Het tijdstip dat het formele bestaan van de organisatie eindigde
Bereik xsd:dateTime
Kardinaliteit 0..*
Toelichting

Indien de waarde van deze property gespecificeerd is én de existentiële wijziging waarbij de organisatie ophield te bestaan is geregistreerd, dan is deze waarde gelijk aan de waarde van tooiont:tijdstipWijziging van de betreffende instantie van tooiont:ExistentieleWijziging.

Wanneer toegepast op tooiont:HistorischeVersie (zie ook verderop) heeft deze property een andere betekenis, zie aldaar.

Indien niet gespecificeerd betekent dat dat de organisatie nog bestaat. De waarde kan op het moment van beschouwen nog in de toekomst liggen omdat organisatiewijzigingen ook voordat ze formeel ingaan in het register kunnen worden opgenomen
3.2.2.15 Property Shape: Overheidsorganisatie-begindatum
URI tooiont:Overheidsorganisatie-begindatum
Subjectklasse tooiont:Overheidsorganisatie
Property tooiont:begindatum
Label Begindatum
Definitie De eerste kalenderdag waarop de organisatie bestond, inclusief
Bereik xsd:date
Kardinaliteit 0..1
Toelichting De waarde van deze property is gelijk aan de datum-component van prov:generatedAtTime van de organisatie.
3.2.2.16 Property Shape: Overheidsorganisatie-einddatum
URI tooiont:Overheidsorganisatie-einddatum
Subjectklasse tooiont:Overheidsorganisatie
Property tooiont:einddatum
Label Einddatum
Definitie De laatste kalenderdag (inclusief) waarop de overheidsorganisatie nog bestond.
Bereik xsd:date
Kardinaliteit 0..1
Toelichting De laatste kalenderdag (inclusief) waarop de organisatie nog bestond. De waarde is afleidbaar uit de waarde van prov:invalidatedAtTime

3.3 Subklassen van Overheidsorganisatie en hun specifieke properties

De subklassen van tooiont:Overheidsorganisatie zijn schematisch weergegeven in het volgende UML-klassediagram.

Overzicht overheidsorganisaties
Figuur 22 Overzicht overheidsorganisaties

De subklassen van tooiont:Overheidsorganisatie zijn onderscheiden langs twee onafhankelijke assen: de as van verschillende soorten regionale openbare lichamen, en de as van ministeries, samenwerkingsorganisaties en ZBO’s (en ZBO-clusters). Regionale openbare lichamen hebben met elkaar gemeen dat ze een bestuursgebied hebben — andere overheidsorganisaties hebben dat niet.

De klasse van openbare lichamen, inclusief niet-regionale, is niet opgenomen in de ontologie. De restcategorie is klein, onsamenhangend en het resultaat van complexe historie. De betreffende organisaties worden getypeerd als tooiont:Overheidsorganisatie en geclassificeerd naar soort.

Veel samenwerkingsorganisaties zijn regionale openbare lichamen, maar lang niet alle.

Binnen elke as zijn de subklassen disjunct, maar er zijn organisaties die zowel regionaal openbaar lichaam zijn als samenwerkingsorganisatie. Deze klasseintersecties zijn in de ontologie expliciet gemaakt.

3.3.1 Regionaal openbaar lichaam

3.3.1.1 Klasse: Regionaal openbaar lichaam
URI tooiont:RegionaalOpenbaarLichaam
Label Regionaal openbaar lichaam
Definitie Een regionaal openbaar lichaam is, in de bestuurlijke indeling van het Koninkrijk der Nederlanden, een overheid die wettelijk bepaalde taken uitvoert binnen een bepaald ruimtelijk gebied
Subklasse van tooiont:Overheidsorganisatie
3.3.1.2 Property Shape: RegionaalOpenbaarLichaam-heeftBestuursgebied
URI tooiont:RegionaalOpenbaarLichaam-heeftBestuursgebied
Subjectklasse tooiont:RegionaalOpenbaarLichaam
Property tooiont:heeftBestuursgebied
Label Heeft bestuursgebied
Definitie Het gebied waarbinnen het regionaal openbaar lichaam taken uitvoert
Bereik tooiont:BestuurlijkeRuimte
Kardinaliteit 1..*
3.3.1.3 Caribisch Openbaar Lichaam (COL)
3.3.1.4 Klasse: Caribisch openbaar lichaam
URI tooiont:CaribischOpenbaarLichaam
Label Caribisch openbaar lichaam
Definitie Een Caribisch openbaar lichaam is een territoriaal openbaar lichaam in het Caribische deel van Nederland
Subklasse van tooiont:RegionaalOpenbaarLichaam
3.3.1.5 Property Shape: CaribischOpenbaarLichaam-colcode
URI tooiont:CaribischOpenbaarLichaam-colcode
Subjectklasse tooiont:CaribischOpenbaarLichaam
Property tooiont:colcode
Label COL-code
Definitie De col-code (van een Caribisch openbaar lichaam). Dit is een nummer met twee cijfers, bijvoorbeeld ‘02’
Bereik xsd:string
Kardinaliteit 1..1
3.3.1.6 Gemeente
3.3.1.7 Klasse: Gemeente
URI tooiont:Gemeente
Label Gemeente
Definitie Een gemeente is het kleinste territoriaal openbaar lichaam met algemene bevoegdheden
Subklasse van tooiont:RegionaalOpenbaarLichaam
3.3.1.8 Property Shape: Gemeente-gemeentecode
URI tooiont:Gemeente-gemeentecode
Subjectklasse tooiont:Gemeente
Property tooiont:gemeentecode
Label Gemeente code
Definitie De gemeentecode. Dit is een nummer met vier cijfers, bijvoorbeeld “0023”.
Bereik xsd:string
Kardinaliteit 1..1
3.3.1.9 Property Shape: Gemeente-ligtInProvincie
URI tooiont:Gemeente-ligtInProvincie
Subjectklasse tooiont:Gemeente
Property tooiont:ligtInProvincie
Label Ligt in provincie
Definitie De provincie waarin het bestuursgebied van de gemeente ligt
Bereik tooiont:Provincie
Kardinaliteit 1..1
3.3.1.10 Grensoverschrijdend regionaal openbaar lichaam
3.3.1.11 Klasse: Grensoverschrijdend regionaal openbaar lichaam
URI tooiont:GrensoverschrijdendRegionaalOpenbaarLichaam
Label Grensoverschrijdend regionaal openbaar lichaam
Definitie Een organisatie die in het leven is geroepen om een gemeenschappelijke regeling uit te voeren uit hoofde van een internationaal verdrag
Subklasse van tooiont:Samenwerkingsorganisatie , tooiont:RegionaalOpenbaarLichaam
Toelichting Een voorbeeld is Eurode, gevormd door de Nederlandse gemeente Kerkrade en Duitse gemeente ’s-Hertogenrade (Herzogenrath). Grensoverschrijdende regionale openbare lichamen worden op dit moment nog niet vastgelegd in de organisatieregisters van KOOP
3.3.1.12 Openbaar lichaam uit gemeenschappelijke regeling
3.3.1.13 Klasse: Openbaar lichaam uit gemeenschappelijke regeling
URI tooiont:OpenbaarLichaamUitGemeenschappelijkeRegeling
Label Openbaar lichaam uit gemeenschappelijke regeling
Definitie Een organisatie die in het leven is geroepen om een gemeenschappelijke regeling uit te voeren uit hoofde van de Wet gemeenschappelijke regelingen (Wgr)
Subklasse van tooiont:Samenwerkingsorganisatie , tooiont:RegionaalOpenbaarLichaam
3.3.1.14 Provincie
3.3.1.15 Klasse: Provincie
URI tooiont:Provincie
Label Provincie
Definitie Een provincie is een territoriaal openbaar lichaam met algemene bevoegdheden tussen gemeente en Rijk
Subklasse van tooiont:RegionaalOpenbaarLichaam
3.3.1.16 Property Shape: Provincie-provinciecode
URI tooiont:Provincie-provinciecode
Subjectklasse tooiont:Provincie
Property tooiont:provinciecode
Label Provincie-code
Definitie De provinciecode. Dit is een nummer met twee cijfers, bijvoorbeeld “31”.
Bereik xsd:string
Kardinaliteit 1..1
3.3.1.17 Rijk
3.3.1.18 Klasse: Rijk
URI tooiont:Rijk
Label Rijk
Definitie De klasse Rijk is de (singleton-) klasse van onderdelen van de Nederlandse overheid die wettelijke taken hebben op landelijk niveau: de ‘centrale overheid’
Subklasse van tooiont:RegionaalOpenbaarLichaam
Toelichting Van deze (singleton-) klasse bestaat slechts een enkele instantie, te weten oorg:oorg12345, met het label ‘Rijksoverheid’
3.3.1.19 Waterschap
3.3.1.20 Klasse: Waterschap
URI tooiont:Waterschap
Label Waterschap
Definitie Een waterschap is een territoriaal openbaar lichaam dat uitsluitend bevoegd is met betrekking tot de waterhuishouding
Subklasse van tooiont:RegionaalOpenbaarLichaam
3.3.1.21 Property Shape: Waterschap-waterschapscode
URI tooiont:Waterschap-waterschapscode
Subjectklasse tooiont:Waterschap
Property tooiont:waterschapscode
Label Waterschaps-code
Definitie De code van het waterschap. Dit is een nummer met vier cijfers, bijvoorbeeld ‘0636’
Bereik xsd:string
Kardinaliteit 1..1

3.3.2 Ministerie

3.3.2.1 Klasse: Ministerie
URI tooiont:Ministerie
Label Ministerie
Definitie Een ministerie is een onderdeel van Rijksoverheid waar, onder verantwoordelijkheid van een minister, beleid wordt voorbereid en uitgevoerd op een specifiek beleidsterrein
Subklasse van tooiont:Overheidsorganisatie
3.3.2.2 Property Shape: Ministerie-ministeriecode
URI tooiont:Ministerie-ministeriecode
Subjectklasse tooiont:Ministerie
Property tooiont:ministeriecode
Label Ministerie-code
Definitie De ministeriecode. Dit is een nummer met vier cijfers, bijvoorbeeld ‘1010’
Bereik xsd:string
Kardinaliteit 1..1

3.3.3 Samenwerkingsorganisatie

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.

Gemeenschappelijke regelingen en samenwerkingsorganisaties
Figuur 23 Gemeenschappelijke regelingen en samenwerkingsorganisaties
3.3.3.1 Klasse: Samenwerkingsorganisatie
URI tooiont:Samenwerkingsorganisatie
Label Samenwerkingsorganisatie
Definitie Een organisatie die in het leven is geroepen om een gemeenschappelijke regeling uit te voeren in een publiekrechtelijke of privaatrechtelijke constructie
Subklasse van tooiont:Overheidsorganisatie
3.3.3.2 Property Shape: Samenwerkingsorganisatie-socode
URI tooiont:Samenwerkingsorganisatie-socode
Subjectklasse tooiont:Samenwerkingsorganisatie
Property tooiont:socode
Label so-code
Definitie De code van de samenwerkingsorganisatie. Dit is een nummer met vier cijfers, bijvoorbeeld ‘0026’
Bereik xsd:string
Kardinaliteit 1..1
3.3.3.3 Grensoverschrijdend regionaal openbaar lichaam
3.3.3.4 Klasse: Grensoverschrijdend regionaal openbaar lichaam
URI tooiont:GrensoverschrijdendRegionaalOpenbaarLichaam
Label Grensoverschrijdend regionaal openbaar lichaam
Definitie Een organisatie die in het leven is geroepen om een gemeenschappelijke regeling uit te voeren uit hoofde van een internationaal verdrag
Subklasse van tooiont:Samenwerkingsorganisatie , tooiont:RegionaalOpenbaarLichaam
Toelichting Een voorbeeld is Eurode, gevormd door de Nederlandse gemeente Kerkrade en Duitse gemeente ’s-Hertogenrade (Herzogenrath). Grensoverschrijdende regionale openbare lichamen worden op dit moment nog niet vastgelegd in de organisatieregisters van KOOP
3.3.3.5 Openbaar lichaam uit gemeenschappelijke regeling
3.3.3.6 Klasse: Openbaar lichaam uit gemeenschappelijke regeling
URI tooiont:OpenbaarLichaamUitGemeenschappelijkeRegeling
Label Openbaar lichaam uit gemeenschappelijke regeling
Definitie Een organisatie die in het leven is geroepen om een gemeenschappelijke regeling uit te voeren uit hoofde van de Wet gemeenschappelijke regelingen (Wgr)
Subklasse van tooiont:Samenwerkingsorganisatie , tooiont:RegionaalOpenbaarLichaam

3.3.4 Zbo of zbo-cluster

3.3.4.1 Klasse: Zbo of zbo-cluster
URI tooiont:ZboOfZboCluster
Label Zbo of zbo-cluster
Definitie Een zelfstandig bestuursorgaan of een verzameling zelfstandige bestuursorganen die collectief wordt geregistreerd
Subklasse van tooiont:Overheidsorganisatie
3.3.4.2 Property Shape: ZboOfZboCluster-zbocode
URI tooiont:ZboOfZboCluster-zbocode
Subjectklasse tooiont:ZboOfZboCluster
Property tooiont:zbocode
Label Zbo-code
Definitie De code van de zbo of het zbo-cluster. Dit is een nummer met zes cijfers, bijvoorbeeld ‘001636’
Bereik xsd:string
Kardinaliteit 1..1
3.3.4.3 Property Shape: ZboOfZboCluster-verantwoordelijkMinisterie
URI tooiont:ZboOfZboCluster-verantwoordelijkMinisterie
Subjectklasse tooiont:ZboOfZboCluster
Property tooiont:verantwoordelijkMinisterie
Label Verantwoordelijk ministerie
Definitie Het ministerie dat verantwoordelijk is voor het beleid dat een zbo uitvoert en het toezicht daarop
Bereik tooiont:Ministerie
Kardinaliteit 1..1
3.3.4.4 Property Shape: ZboOfZboCluster-kaderwetVanToepassing
URI tooiont:ZboOfZboCluster-kaderwetVanToepassing
Subjectklasse tooiont:ZboOfZboCluster
Property tooiont:kaderwetVanToepassing
Label Kaderwet van toepassing
Definitie Het antwoord op de vraag of de kaderwet op deze zbo of cluster van zbo’s van toepassing is (‘ja’, ‘nee’, ‘onbekend’, of ‘in voorbereiding’)
Bereik xsd:string
Kardinaliteit 0..1
3.3.4.5 Zelfstandig bestuursorgaan (zbo)
3.3.4.6 Klasse: Zelfstandig bestuursorgaan
URI tooiont:Zbo
Label Zelfstandig bestuursorgaan
Definitie Een zelfstandig bestuursorgaan (zbo) is een bestuursorgaan van de centrale overheid dat niet direct onder het gezag van een minister valt
Subklasse van tooiont:ZboOfZboCluster
3.3.4.7 Property Shape: Zbo-hoortBijZboCluster
URI tooiont:Zbo-hoortBijZboCluster
Subjectklasse tooiont:Zbo
Property tooiont:hoortBijZboCluster
Label Hoort bij Zbo-cluster
Definitie Het cluster waartoe het zelfstandig bestuursorgaan behoort
Bereik tooiont:ZboCluster
Kardinaliteit 0..1
3.3.4.8 Zbo-cluster
3.3.4.9 Klasse: Zbo-cluster
URI tooiont:ZboCluster
Label Zbo-cluster
Definitie Een verzameling zelfstandige bestuursorganen die collectief wordt geregistreerd
Subklasse van tooiont:ZboOfZboCluster
Toelichting

Een zbo-cluster kan worden beschreven met vrijwel alle properties die van toepassing zijn op een zbo. Een cluster heeft bijvoorbeeld een zbo-code en een verantwoordelijk ministerie. Het kan verantwoordelijk zijn voor de inhoud van een publicatie. Ook wijzigingshistorie werkt als bij andere soorten overheidsorganisaties. Daarom definieert TOOI deze klasse als een subklasse van tooiont:ZboOfZboCluster.

Clusters verschillen van andere organisaties in een aantal opzichten. Een cluster heeft bijvoorbeeld geen bestuur. In tegenstelling tot een ‘normale’ zbo kan een cluster niet deel uitmaken van een ander cluster (en ook niet van zichzelf). Van sommige clusters zijn de leden als zodanig geregistreerd in het Zbo-Register. In andere gevallen is het cluster wel geregistreerd in het Zbo-Register, maar de leden niet. Dit betreft privaatrechtelijke organisaties die een overheidstaak vervullen en als zodanig een zelfstandig bestuursorgaan zijn. Voorbeelden zijn apk-garages en notarissen. De registratie van deze zbo’s vindt niet plaats in het Zbo-Register. In overheidsinformatie en metadata daarvan worden deze organisaties vaak collectief als cluster aangeduid.

De TOOI-ontologie definieert tooiont:ZboCluster als een subklasse van tooiont:ZboOfZboCluster (en dus van tooiont:Overheidsorganisatie). Een praktische overweging hierbij is dat hiermee de complexiteit van het model qua structuur beperkt blijft. Dat maakt het genereren en gebruiken van waardelijsten gegenereerd uit het Zbo-Register relatief eenvoudig. Ontologisch gezien is het van belang vast te stellen dat een cluster voldoet aan de definities van alle bovengelegen superklassen. In het volgende klassediagram zijn de belangrijkste superklassen en hun tekstuele definities op een rij gezet.

Klassediagram zbo-cluster
Figuur 24 Klassediagram zbo-cluster

De definitie van org:Organization (zie [vocab-org]) stelt de meeste restricties en is daarom het meest interessant in deze context:

  • Een organisatie is een verzameling mensen georganiseerd in een structuur. Aan de aard van de structuur worden geen eisen gesteld. Een zbo-cluster voldoet hieraan.
  • De groep heeft een gezamenlijk doel of bestaansreden. Dit doel dat de leden van een cluster geacht worden na te streven wordt vastgelegd in wet en regelgeving. Ook aan deze eis wordt voldaan.
  • De groep kan handelen als een ‘agent’. Dat klopt: een zbo-cluster kan verantwoordelijk zijn voor de inhoud van een publicatie. Organisaties vallen vaak uiteen in hiërarchische structuren. Ook dit is van toepassing.

De definities van org:FormalOrganization en tooiont:Overheidsorganisatie liggen in het verlengde hiervan en zijn volledig van toepassing. Een zbo-cluster heeft een andere aard dan veel andere organisaties. Genoemd is reeds het feit dat een cluster geen bestuur heeft. Dat is echter geen definiërende eigenschap voor de superklassen van tooiont:ZboCluster.

4. Wijzigingshistorie

4.1 Wijzigingshistorie: Overzicht

4.1.1 Wijzigingshistorie: Definitie en afbakening

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.

4.1.2 Wijzigingshistorie: Klassediagram

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

Klassediagram wijzigingen
Figuur 25 Klassediagram wijzigingen

4.2 Wijzigingshistorie: Klassen en properties

4.3 Wijzigingsgebeurtenis

De klasse tooiont:Wijzigingsgebeurtenis, een subklasse van prov:Activity, is de basis voor het TOOI-vocabulaire voor wijzigingshistorie.

4.3.1 Klasse: Wijzigingsgebeurtenis

URI tooiont:Wijzigingsgebeurtenis
Label Wijzigingsgebeurtenis
Definitie Een wijziging waarbij een entiteit (zoals een informatieobject of organisatie) van toestand is veranderd, dan wel begonnen of opgehouden is te bestaan.
Subklasse van prov:Activity

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

4.3.2 Property Shape: Wijzigingsgebeurtenis-tijdstipWijziging

URI tooiont:Wijzigingsgebeurtenis-tijdstipWijziging
Subjectklasse tooiont:Wijzigingsgebeurtenis
Property tooiont:tijdstipWijziging
Label Tijdstip wijziging
Definitie Datum en tijdstip waarop de wijziging formeel is ingegaan
Bereik xsd:dateTime
Kardinaliteit 0..1

4.3.3 Property Shape: Wijzigingsgebeurtenis-tijdstipRegistratie

URI tooiont:Wijzigingsgebeurtenis-tijdstipRegistratie
Subjectklasse tooiont:Wijzigingsgebeurtenis
Property tooiont:tijdstipRegistratie
Label Tijdstip registratie
Definitie Datum en tijdstip waarop de wijziging is geregistreerd in het betreffende register
Bereik xsd:dateTime
Kardinaliteit 0..1

4.3.4 Property Shape: Wijzigingsgebeurtenis-heeftJuridischeGrondslag

URI tooiont:Wijzigingsgebeurtenis-heeftJuridischeGrondslag
Subjectklasse tooiont:Wijzigingsgebeurtenis
Property tooiont:heeftJuridischeGrondslag
Label Juridische grondslag
Definitie Wet, regeling of besluit waaraan de wijziging zijn rechtsgeldigheid ontleent
Bereik tooiont:Informatieobject
Kardinaliteit 0..*

4.3.5 Property Shape: Wijzigingsgebeurtenis-redenWijziging

URI tooiont:Wijzigingsgebeurtenis-redenWijziging
Subjectklasse tooiont:Wijzigingsgebeurtenis
Property tooiont:redenWijziging
Label Reden wijziging
Definitie De reden voor de wijziging
Bereik xsd:string
Kardinaliteit 0..*

4.4 Existentiële wijziging

4.4.1 Klasse: Existentiële wijziging

URI tooiont:ExistentieleWijziging
Label Existentiële wijziging
Definitie Een wijziging waarbij één of meerdere entiteiten begonnen of opgehouden zijn te bestaan
Subklasse van tooiont:Wijzigingsgebeurtenis

4.5 Toestandswijziging

4.5.1 Klasse: Toestandswijziging

URI tooiont:Toestandswijziging
Label Toestandswijziging
Definitie Een wijziging waarbij de toestand van een entiteit veranderde, maar waarbij de identiteit de entiteit niet geraakt werd
Subklasse van tooiont:Wijzigingsgebeurtenis

De properties voor tooiont:Toestandswijziging zijn als volgt.

4.5.2 Property Shape: Toestandswijziging-invalidated

URI tooiont:Toestandswijziging-invalidated
Subjectklasse tooiont:Toestandswijziging
Property prov:invalidated
Label Opgeheven toestand
Definitie De historische versie van een gewijzigde entiteit, die de toestand representeert zoals die voorafgaand aan de wijziging van kracht was.
Bereik tooiont:HistorischeVersie
Kardinaliteit 0..*
Toelichting In de context van informatieobjecten gaat het hier vaak om een representatie van metadata. In de context van overheidsorganisaties gaat het om toestandswijzigingen zoals een naamswijziging, bijvoorbeeld bij een ministerie.

4.5.3 Property Shape: Toestandswijziging-used

URI tooiont:Toestandswijziging-used
Subjectklasse tooiont:Toestandswijziging
Property prov:used
Label Nieuwe toestand van
Definitie De entiteit waarvan de toestand gewijzigd is.
Bereik prov:Entity
Kardinaliteit 0..*

4.6 Historische versie

Bij een toestandswijziging van een entiteit kan het wenselijk zijn om de oude toestand van die entiteit vast te leggen en/of te bewaren. Het mechanisme dat TOOI hiervoor beschikbaar maakt heeft als kern de klasse tooiont:HistorischeVersie.

4.6.1 Klasse: Historische versie

URI tooiont:HistorischeVersie
Label Historische versie
Definitie De toestand waarin een entiteit zich in heeft bevonden voordat deze wijzigde
Subklasse van prov:Entity

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.

4.6.2 Property Shape: HistorischeVersie-specializationOf

URI tooiont:HistorischeVersie-specializationOf
Subjectklasse tooiont:HistorischeVersie
Property prov:specializationOf
Label Historische versie van
Definitie De entiteit waar de historische versie een toestand van uitdrukt.
Bereik prov:Entity
Kardinaliteit 1..1

4.6.3 Property Shape: HistorischeVersie-invalidatedAtTime

URI tooiont:HistorischeVersie-invalidatedAtTime
Subjectklasse tooiont:HistorischeVersie
Property prov:invalidatedAtTime
Label Tijdstip wijziging
Definitie Het tijdstip dat de de toestand wijzigde in een andere toestand, en de toestand dus niet meer van kracht is.
Bereik xsd:dateTime
Kardinaliteit 0..1

4.6.4 Property Shape: HistorischeVersie-einddatumHV

URI tooiont:HistorischeVersie-einddatumHV
Subjectklasse tooiont:HistorischeVersie
Property tooiont:einddatumHV
Label Einddatum van de historische versie
Definitie De laatste kalenderdag (inclusief) waarop de historische versie (dus de oude toestand van de resource) van kracht was.
Bereik xsd:date
Kardinaliteit 0..1

4.6.5 Ontologische aspecten van historische versies

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 iatj (1 <= j <= n) kleiner dan t, dan is de iatj 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.

4.7 Toepassing op informatieobjecten

4.7.1 Toestandswijziging en historie van metadata

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:

Wijzigingshistorie metadata
Figuur 26 Wijzigingshistorie metadata

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.

4.7.2 Existentiële wijziging en versionering van informatieobjecten

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.

Wijzigingshistorie documentversies
Figuur 27 Wijzigingshistorie documentversies

4.8 Toepassing op overheidsorganisaties

4.8.1 Toestandswijziging en naamswijzigingen van een organisatie

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.

Naamswijziging
Figuur 28 Naamswijziging
    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 ;
    .

4.8.2 Existentiële Wijzigingen en gemeentelijke herindeling

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.

4.9 Opheffing

4.9.1 Klasse: Opheffing

URI tooiont:Opheffing
Label Opheffing
Definitie Bij een opheffing worden één of meerdere organisaties opgeheven (geïnvalideerd)
Subklasse van tooiont:ExistentieleWijziging

De properties voor tooiont:Opheffing zijn als volgt.

4.9.2 Property Shape: Opheffing-invalidated

URI tooiont:Opheffing-invalidated
Subjectklasse tooiont:Opheffing
Property prov:invalidated
Label Opgeheven entiteit
Definitie De entiteiten die als gevolg van opheffing opgehouden zijn te bestaan.
Bereik prov:Entity
Kardinaliteit 1..*

4.10 Oprichting

4.10.1 Klasse: Oprichting

URI tooiont:Oprichting
Label Oprichting
Definitie Bij een oprichting worden één of meerdere organisaties opgericht (gegenereerd)
Subklasse van tooiont:ExistentieleWijziging

De properties voor tooiont:Oprichting zijn als volgt.

4.10.2 Property Shape: Oprichting-generated

URI tooiont:Oprichting-generated
Subjectklasse tooiont:Oprichting
Property prov:generated
Label Gegenereerde entiteit oprichting
Definitie De entiteiten waarvan het bestaan een aanvang nam als gevolg van de oprichting
Bereik prov:Entity
Kardinaliteit 1..*

4.11 Herschikking

4.11.1 Klasse: Herschikking

URI tooiont:Herschikking
Label Herschikking
Definitie Bij een herschikking worden er één of meerdere organisaties opgeheven en worden er één of meerdere organisaties opgericht, en nul of meerdere bestaande organisaties zijn daarbij betrokken
Subklasse van tooiont:ExistentieleWijziging

De properties voor tooiont:Herschikking zijn als volgt.

4.11.2 Property Shape: Herschikking-used

URI tooiont:Herschikking-used
Subjectklasse tooiont:Herschikking
Property prov:used
Label Betrokken entiteit herschikking
Definitie De entiteiten die als gevolg van de wijziging opgehouden zijn te bestaan.
Bereik prov:Entity
Kardinaliteit 0..*

4.11.3 Property Shape: Herschikking-generated

URI tooiont:Herschikking-generated
Subjectklasse tooiont:Herschikking
Property prov:generated
Label Gegenereerde entiteit herschikking
Definitie De entiteiten waarvan het bestaan een aanvang nam als gevolg van de herschikking
Bereik prov:Entity
Kardinaliteit 1..*

4.11.4 Property Shape: Herschikking-invalidated

URI tooiont:Herschikking-invalidated
Subjectklasse tooiont:Herschikking
Property prov:invalidated
Label Opgeheven entiteit herschikking
Definitie De entiteiten die een rol hebben gespeeld bij de wijziging.
Bereik prov:Entity
Kardinaliteit 1..*

4.12 Samenvoeging

4.12.1 Klasse: Samenvoeging

URI tooiont:Samenvoeging
Label Samenvoeging
Definitie Bij een samenvoeging ontstaat een nieuwe organisatie als gevolg van samenvoeging van twee of meer andere organisatie die ophouden te bestaan. De gegenereerde organisatie is de opvolger van de samengevoegde organisaties
Subklasse van tooiont:ExistentieleWijziging

De properties voor tooiont:Samenvoeging zijn als volgt.

4.12.2 Property Shape: Samenvoeging-generated

URI tooiont:Samenvoeging-generated
Subjectklasse tooiont:Samenvoeging
Property prov:generated
Label Gegenereerde entiteit
Definitie De entiteiten waarvan het bestaan een aanvang nam als gevolg van de samenvoeging
Bereik prov:Entity
Kardinaliteit 1..1

4.12.3 Property Shape: Samenvoeging-invalidated

URI tooiont:Samenvoeging-invalidated
Subjectklasse tooiont:Samenvoeging
Property prov:invalidated
Label Opgeheven entiteit
Definitie De entiteiten die als gevolg van de wijziging opgehouden zijn te bestaan.
Bereik prov:Entity
Kardinaliteit 2..*

4.13 Opsplitsing

4.13.1 Klasse: Opsplitsing

URI tooiont:Opsplitsing
Label Opsplitsing
Definitie Bij een opsplitsing worden twee of meerdere organisaties opgericht al gevolg van de opheffing van een andere organisatie
Subklasse van tooiont:ExistentieleWijziging

De properties voor tooiont:Opsplitsing zijn als volgt.

4.13.2 Property Shape: Opsplitsing-generated

URI tooiont:Opsplitsing-generated
Subjectklasse tooiont:Opsplitsing
Property prov:generated
Label Gegenereerde entiteit opsplitsing
Definitie De entiteiten waarvan het bestaan een aanvang nam als gevolg van de opsplitsing
Bereik prov:Entity
Kardinaliteit 2..*

4.13.3 Property Shape: Opsplitsing-invalidated

URI tooiont:Opsplitsing-invalidated
Subjectklasse tooiont:Opsplitsing
Property prov:invalidated
Label Opgeheven entiteit opsplitsing
Definitie De entiteiten die als gevolg van de opsplitsing opgehouden zijn te bestaan.
Bereik prov:Entity
Kardinaliteit 1..1

4.14 Uitbreiding

4.14.1 Klasse: Uitbreiding

URI tooiont:Uitbreiding
Label Uitbreiding
Definitie Bij een uitbreiding worden één of meerdere bestaande organisaties uitgebreid met één of meerdere andere organisatie, waarbij die andere organisaties ophouden zelfstandig te bestaan
Subklasse van tooiont:ExistentieleWijziging

De properties voor tooiont:Uitbreiding zijn als volgt.

4.14.2 Property Shape: Uitbreiding-used

URI tooiont:Uitbreiding-used
Subjectklasse tooiont:Uitbreiding
Property prov:used
Label Betrokken entiteit
Definitie De entiteiten die een rol hebben gespeeld bij de wijziging.
Bereik prov:Entity
Kardinaliteit 1..*

4.14.3 Property Shape: Uitbreiding-invalidated

URI tooiont:Uitbreiding-invalidated
Subjectklasse tooiont:Uitbreiding
Property prov:invalidated
Label Opgeheven entiteit
Definitie De entiteiten die als gevolg van de wijziging opgehouden zijn te bestaan.
Bereik prov:Entity
Kardinaliteit 1..*

4.15 Afsplitsing

4.15.1 Klasse: Afsplitsing

URI tooiont:Afsplitsing
Label Afsplitsing
Definitie Bij een afsplitsing worden delen van één of meerdere bestaande organisaties afgesplitst die verder gaan als één of meer nieuwe organisaties.
Subklasse van tooiont:ExistentieleWijziging

De properties voor tooiont:Afsplitsing zijn als volgt.

4.15.2 Property Shape: Afsplitsing-used

URI tooiont:Afsplitsing-used
Subjectklasse tooiont:Afsplitsing
Property prov:used
Label Betrokken entiteit afsplitsing
Definitie De entiteiten die een rol hebben gespeeld bij de afsplitsing.
Bereik prov:Entity
Kardinaliteit 1..*

4.15.3 Property Shape: Afsplitsing-generated

URI tooiont:Afsplitsing-generated
Subjectklasse tooiont:Afsplitsing
Property prov:generated
Label Gegenereerde entiteit afsplitsing
Definitie De entiteiten waarvan het bestaan een aanvang nam als gevolg van de afsplitsing
Bereik prov:Entity
Kardinaliteit 1..*

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.

Betekenis van de kolommen in de tabel
p:u
Kardinaliteit prov:used
p:g
Kardinaliteit prov:generated
p:i
Kardinaliteit prov:invalidated
nr p:U p:g p:i Subklasse Definitie en toelichting
1 0 0 0 Niet van toepassing De definitie van de superklasse vereist dat er minimaal een organisatie wordt opgericht of opgeheven.
2 0 0 1..* tooiont:Opheffing Bij een opheffing worden één of meerdere organisaties opgeheven (geïnvalideerd).
3 0 1..* 0 tooiont:Oprichting Bij een oprichting worden één of meerdere organisaties opgericht (gegenereerd).
4 0 1..* 1..* tooiont:Herschikking Bij een herschikking worden er één of meerdere organisaties opgeheven en worden er één of meerdere organisaties opgericht. De opvolgingsrelatie is alleen te traceren als kard(invalidated)=1 of kard(generated)=1. Herschikking heeft een signatuur van (0..*, 1..*, 1..*) en komt dus twee keer voor in de tabel.
4.1 0 1 2..* tooiont:Samenvoeging Bij een samenvoeging ontstaat een nieuwe organisatie als gevolg van samenvoeging van twee of meer andere organisatie die ophouden te bestaan. De gegenereerde organisatie is de opvolger van de samengevoegde organisaties.
4.2 0 2..* 1 tooiont:Opsplitsing Bij een opsplitsing worden twee of meerdere organisaties opgericht als gevolg van de opheffing van een andere organisatie. De gegenereerde organisaties zijn de opvolgers van de geïnvalideerde organisatie.
5 1..* 0 0 Niet van toepassing De definitie van de superklasse vereist dat er minimaal een organisatie wordt opgericht of opgeheven.
6 1..* 0 1..* tooiont:Uitbreiding Bij een uitbreiding worden één of meerdere bestaande organisaties uitgebreid met één of meerdere andere organisaties, waarbij die andere organisaties ophouden zelfstandig te bestaan. De opvolgingsrelatie is alleen te traceren als kard(invalidated)=1 of kard(used)=1.
7 1..* 1..* 0 tooiont:Afsplitsing Bij een afsplitsing worden delen van één of meerdere bestaande organisaties afgesplitst die verder gaan als één of meer nieuwe organisaties. De opvolgingsrelatie is alleen te traceren als kard(generated)=1 of kard(used)=1.
8 1..* 1..* 1..* tooiont:Herschikking Bij een herschikking met deze cardinaliteiten worden er een of meerdere organisaties opgeheven en worden er een of meerdere organisaties opgericht, en één of meerdere bestaande organisaties zijn daarbij betrokken. De opvolgingsrelatie is niet te traceren. Herschikking heeft een signatuur van ([0..*], [1..*], [1..*]) en komt dus twee keer voor in de tabel.

4.15.4 Voorbeeld van een samenvoeging

Het volgende schema illustreert een tooiont:Samenvoeging:

Samenvoeging van gemeenten
Figuur 29 Samenvoeging van gemeenten

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 ;
    .

5. Ruimte en geografie

5.1 Ruimte en geografie: Overzicht

Regionale openbare lichamen (zoals de provincie Groningen) en informatieobjecten (zoals een milieuvergunning) kunnen op diverse manieren gerelateerd zijn aan een ruimte. Om dat uit te kunnen drukken definieert de TOOI-ontologie een aantal klassen en properties. De TOOI-ontologie sluit daarbij zoveel modelijk aan op NEN-3610. Zie het volgende klassediagram. De klassen en relaties aangegeven met stippellijnen zijn alleen uitgedrukt in UML, de overige duiden resources aan die gedefinieerd of genoemd zijn in tooiont.

Klassediagram geometrie
Figuur 30 Klassediagram geometrie

De fysieke ruimte is extensioneel: het is een kwantiteit. Een driehoek A, B, C is gelijk aan A, B, D dan, en slechts dan, als C = D. Fysieke ruimte kent geen historie. Fysieke ruimte ontstaat niet en kan ook niet ophouden te bestaan.

De TOOI-ontologie definieert tooiont:BestuurlijkeRuimte intensioneel. Het is een subklasse van prov:Entity en van geo:Feature. De eigenschappen van een bestuurlijke ruimte, inclusief de geografische eigenschappen, kunnen veranderen in de loop van de tijd. De exacte ligging kan dus wijzigen. Een bestuurlijke ruimte kan, in tegenstelling tot een fysieke ruimte, historische versies hebben.

Een instantie van de klasse tooiont:BestuurlijkeRuimte is existentieel afhankelijk van het bestaan van een regionaal openbaar lichaam, dan wel de werking van een (bepaald soort) informatieobject. De oprichting van een regionaal openbaar lichaam resulteert (onder andere) in het bestaan van de bestuurlijke ruimte (meer in het bijzonder, de registratieve ruimte) die bij het regionaal openbaar lichaam hoort. Dat geldt (mutatis mutandis) ook voor de inwerkingtreding van een (bepaald soort) informatieobject.

5.2 Bestuurlijke ruimte, fysieke ruimte en geometrie

De relatie tussen bestuurlijke ruimte en fysieke ruimte is helder. In [geosparql] en de onderliggende standaard ISO 19101:2014 [iso19101_2014] wordt deze relatie niet in formele termen beschreven, maar de bedoeling is duidelijk. Een feature (en dus een bestuurlijke ruimte) bestrijkt een fysieke ruimte. Een fysieke ruimte kan een aanduiding hebben in de vorm van een geo:Geometry. Een geometrie in de zin van een ruimtelijke aanduiding is een information resource zoals gedefinieerd in paragraaf 2.2.1: de volledige essentiële karakteristieken van een ruimtelijke aanduiding kunnen overgebracht worden middels een bericht. Een geometrie is een beschrijving met een eindige mate van nauwkeurigheid. Verschillende geometrieën kunnen dezelfde fysieke ruimte beschrijven met een verschillende mate van nauwkeurigheid.

De grijze stippellijnen in het klassediagram geven aan dat de klasse FysiekeRuimte en de bijbehorende properties geen resources zijn in tooiont. Hiermee wordt aangegeven aan dat een uitspraak als “een bestuurlijke ruimte heeft een ruimtelijke aanduiding” dezelfde betekenis heeft als “een bestuurlijke ruimte bestrijkt een fysieke ruimte, en die fysieke ruimte heeft een ruimtelijke aanduiding”.

Noot. De klasse tooiont:Informatieobject is eigenlijk de klasse van overheidsinformatieobjecten. De superklasse van tooiont:Informatieobject die alle informatieobjecten omvat is niet binnen de TOOI-ontologie gedefinieerd.

De klassen RegistratieveRuimte en JuridischeRuimte zijn overgenomen uit NEN 3610:2022 [nen3610_2022], inclusief hun tekstuele definities.

5.3 De rollen van een bestuurlijke ruimte

De klassen tooiont:RegistratieveRuimte en tooiont:JuridischeRuimte zijn, in termen van de UFO-methode [offscm], rollen. Een bestuurlijke ruimte behoort niet noodzakelijk maar contingent (door omstandigheden) tot een van deze subklassen, en als dat zo is, dan is dat in relatie tot een regionaal openbaar lichaam dan wel een informatieobject. Een bestuurlijke ruimte kan tegelijkertijd een registratieve ruimte zijn in relatie tot een regionaal openbaar lichaam, en een juridische ruimte in relatie tot een informatieobject. Het komt vaak voor dat het werkingsgebied van een informatieobject gelijk is aan het bestuursgebied van een provincie, een gemeente, een waterschap of ander regionaal openbaar lichaam. In de Regeling elektronische publicaties staat het als volgt geformuleerd:

… indien het informatieobject betrekking heeft op het gehele grondgebied van een of meer provincies, gemeenten, waterschappen of andere openbare lichamen, worden deze provincies, gemeenten, waterschappen of andere openbare lichamen geselecteerd

In het geval van het grondgebied van meerdere regionale openbare lichamen heeft het informatieobject evenzovele waarden voor de property tooiont:heeftWerkingsgebied. De betreffende instanties van tooiont:BestuurlijkeRuimte worden getypeerd als tooiont:RegistratieveRuimte en als tooiont:JuridischeRuimte.

In theorie kan een juridische ruimte op deze wijze gekoppeld zijn aan een historische versie van een bestuursgebied (die niet kan veranderen), of aan een bestuursgebied “op werkniveau” (dat wél kan veranderen). Hoe dit in de praktijk uitwerkt is een kwestie van de implementatie van de betreffende registers.

5.4 De samenhang van bestuurlijke, topologische en geografische aspecten

De relaties tussen bestuurlijke gebieden onderling hebben bestuurlijke, topologische, en geografische aspecten. Het volgende schema illustreert dit. De groene resources zijn klassen, de overige zijn individuals. Niet alle relaties tussen individuals en klassen zijn ingetekend.

Bestuurlijke gebieden en geometrie
Figuur 31 Bestuurlijke gebieden en geometrie

Het schema modelleert het feit dat de gemeente Maastricht in de provincie Limburg ligt. De relatie tussen de blauwe resources Maastricht en Limburg is bestuurlijk van aard. De relatie tussen de grijze resources bestuursgebied_A en bestuursgebied_B is topologisch, en de relatie tussen de gele resources geometrie_12 en geometrie_34 is geografisch.

Noot. De geosparql-relaties (topologisch en geometrisch) worden meestal gezien als afgeleide informatie en berekend op grond van de ligging van de betreffende gebieden.

5.5 Klassen en properties

5.5.1 Klasse: Bestuurlijke ruimte

URI tooiont:BestuurlijkeRuimte
Label Bestuurlijke ruimte
Definitie Een ruimte die bestuurlijke relevantie kent
Subklasse van prov:Entity

5.5.2 Property Shape: BestuurlijkeRuimte-hasGeometry

URI tooiont:BestuurlijkeRuimte-hasGeometry
Subjectklasse tooiont:BestuurlijkeRuimte
Property geosparql:hasGeometry
Label Heeft geometrie
Definitie De geometrie van de fysieke ruimte die de bestuurlijke ruimte bestrijkt
Bereik geosparql:Geometry
Kardinaliteit 1..*

5.5.3 Klasse: Registratieve ruimte

URI tooiont:RegistratieveRuimte
Label Registratieve ruimte
Definitie Een bestuurlijke ruimte die het bestuursgebied is van een regionaal openbaar lichaam
Subklasse van tooiont:BestuurlijkeRuimte
Toelichting Deze klasse is ook een subklasse van de klasse Registratieve ruimte in NEN 3610:2022. Deze laatste is gedefinieerd als een op basis van wet- of regelgeving afgebakende ruimte die als eenheid geldt van politiek-bestuurlijke verantwoordelijkheid of voor bedrijfsvoering

5.5.4 Klasse: Juridische ruimte

URI tooiont:JuridischeRuimte
Label Juridische ruimte
Definitie Een bestuurlijke ruimte die het werkingsgebied of het effectgebied is van een informatieobject
Subklasse van tooiont:BestuurlijkeRuimte
Toelichting Deze klasse is ook een subklasse van de klasse Juridische ruimte in NEN 3610:2022. Deze laatste is gedefinieerd als een ruimte waar een juridisch instrument beleid of regelgeving toepast

6. Overige klassen en properties

Dit deel behandelt modelelementen die niet onder een van de onderwerpen vallen die in de voorafgaande delen zijn besproken. Op dit moment zijn dat slechts een beperkt aantal properties.

6.1 Uitbreidingen op SKOS

Voor de beschrijving van SKOS-resources gebruiken we behalve het standaard SKOS-vocabulaire ook de volgende klassen en properties:

6.2 Klasse: Groeperingsconcept

URI tooiont:Groeperingsconcept
Label Groeperingsconcept
Definitie Een concept dat dient om andere concepten te groeperen voor een contextspecifiek doel
Subklasse van skos:Concept
Toelichting Een groeperingsconcept mag doorgaans niet voorkomen in de metadata van een informatieobject of als waarde van een classificatieproperty

6.3 Property Shape: Label-context

URI tooiont:Label-context
Subjectklasse skosxl:Label
Property tooiont:context
Label Label-context
Definitie URI van de waardelijst die de context vormt waarbinnen het label het voorkeurslabel is
Bereik xsd:anyURI
Kardinaliteit 0..*
Toelichting Deze shape moet nog verbonden worden met de target: skosxl:Label

6.4 Property Shape: Collection-expandeert

URI tooiont:Collection-expandeert
Subjectklasse skos:Collection
Property tooiont:expandeert
Label Expandeert
Definitie Wordt gebruik bij een skos:Collection om aan te geven dat de collectie correspondeert met een concept. Meer in het bijzonder, vanuit gebruiksperspectief mag je het concept dat de waarde is van deze property als de ‘broader’ zien van de concepten in de collectie (maar alleen in de context van de collectie). Dit in tegenstelling tot een skos:Collection die alleen maar een groepering is
Bereik skos:Concept
Kardinaliteit 0..*

6.5 Property Shape: Collection-prefLabelVoorGroepen

URI tooiont:Collection-prefLabelVoorGroepen
Subjectklasse skos:Collection
Property tooiont:prefLabelVoorGroepen
Label Voorkeurslabel voor groepen
Definitie Het voorkeurslabel voor groepen individuals die het concept ‘instantiëren’ of gemetadateerd zijn met het concept.
Bereik xsd:string
Kardinaliteit 0..*

6.6 Property Shape: Concept-prefLabelVoorGroepen

URI tooiont:Concept-prefLabelVoorGroepen
Subjectklasse skos:Concept
Property tooiont:prefLabelVoorGroepen
Label Voorkeurslabel voor groepen
Definitie Het voorkeurslabel voor groepen individuals die het concept ‘instantiëren’ of gemetadateerd zijn met het concept
Bereik xsd:string
Kardinaliteit 0..*

6.7 Property Shape: Concept-order

URI tooiont:Concept-order
Subjectklasse skos:Concept
Property sh:order
Label Volgorde-indicatie
Definitie Getal dat de sorteervolgorde van concepten aangeeft.
Bereik xsd:integer
Kardinaliteit 0..*
Toelichting

Hierbij gelden de volgende conventies:

  • Als concept A een lagere waarde heeft dan concept B, dan komt A vóór B
  • Als concept A geen waarde heeft en concept B wel, dan komt A vóór B
  • Als concept A geen waarde heeft en concept B ook niet, dan geldt de alfabetische volgorde van preflabels
Dit is relevant bij concepten met preflabels als “overige registermutaties”. Terwijl in de meeste applicaties de specifiek genoemde registermutaties gewoon op alfabetische volgorde van preflabel gesorteerd dienen te worden, moet het concept “overige registermutaties” onderaan de lijst staan. In dergelijke gevallen geven we dit concept bijvoorbeeld de waarde “1010”^^xsd:integer, terwijl we geen waarde specificeren voor de andere concepten.

A. Referenties

A.1 Informatieve referenties

[akn]
Akoma Ntoso. URL: https://http://www.akomantoso.org/
[DC11]
Dublin Core Metadata Element Set, Version 1.1. DCMI. 14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dces/
[ecli]
ECLI (en LJN). Rechtspraak Servicecentrum. URL: https://www.rechtspraak.nl/Uitspraken/paginas/ecli.aspx
[elitg]
ELI technical guide. Publications Office of the European Union. Publications Office. June 2018. URL: https://data.europa.eu/doi/10.2830/51169
[FOAF]
FOAF Vocabulary Specification 0.99 (Paddington Edition). Dan Brickley; Libby Miller. FOAF project. 14 January 2014. URL: http://xmlns.com/foaf/spec
[frbr]
Functional Requirements for Bibliographic Records. Wikipedia. Wikipedia. June 2018. URL: https://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records
[geosparql]
GeoSPARQL - A Geographic Query Language for RDF Data. Matthew Perry; John Herring. Open Geospatial Consortium. September 2012. URL: http://www.opengeospatial.org/standards/geosparql
[gofair]
GO FAIR Foundation. Guiding FAIR implementation. URL: https://www.gofair.foundation/
[iso19101_2014]
Geographic information. Reference model. Part 1: Fundamentals. ISO. 2014. URL: https://www.iso.org/standard/59164.html
[juriconnect]
Juriconnect-standaard voor identificatie van en verwijzing naar wet- en regelgeving. Juriconnect. URL: https://www.juriconnect.nl/downloadreg.asp?bestand=Beheerplan+Juriconnectstandaarden+0%2E4%2E2%2Epdf&type=pdf
[nen3610_2022]
Basismodel geo-informatie - Termen, definities, relaties en algemene regels voor de uitwisseling van informatie over aan de aarde gerelateerde ruimtelijke objecten. NEN. 2022. URL: https://www.nen.nl/nen-3610-2022-nl-296137
[offscm]
Ontological foundations for structural conceptual models. Giancarlo Guizzardi. University of Twente. 2005. URL: https://ris.utwente.nl/ws/portalfiles/portal/6042428/thesis_Guizzardi.pdf
[pav]
PAV - Provenance, Authoring and Versioning. Paolo Ciccarese; Stian Soiland-Reyes. URL: https://pav-ontology.github.io/pav/
[prov-dm]
PROV-DM: The PROV Data Model. Luc Moreau; Paolo Missier. W3C. 30 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/prov-dm/
[prov-o]
PROV-O: The PROV Ontology. Timothy Lebo; Satya Sahoo; Deborah McGuinness. W3C. 30 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/prov-o/
[rdf-schema]
RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
[rdf11-concepts]
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
[Rep]
Regeling elektronische publicaties. URL: https://wetten.overheid.nl/BWBR0045086
[shacl]
Shapes Constraint Language (SHACL). Holger Knublauch; Dimitris Kontokostas. W3C. 20 July 2017. W3C Recommendation. URL: https://www.w3.org/TR/shacl/
[skos-reference]
SKOS Simple Knowledge Organization System Reference. Alistair Miles; Sean Bechhofer. W3C. 18 August 2009. W3C Recommendation. URL: https://www.w3.org/TR/skos-reference/
[slilp]
Stage-Level and Individual-Level Predicates. Angelica Kratzer. In: University of Massachusetts Occasional Papers in Linguistics, Vol 10. University of Massachusetts. 1989. URL: https://scholarworks.umass.edu/cgi/viewcontent.cgi?article=1103&context=umop
[stop]
Standaard voor Officiële Publicaties. KOOP. KOOP. URL: https://standaarden.overheid.nl/stop
[trig]
RDF 1.1 TriG. Gavin Carothers; Andy Seaborne. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/trig/
[uri21]
Identifiers for the 21st century: How to design, provision, and reuse persistent identifiers to maximize utility and impact of life science data. J.A. McMurry; N.Juty; N. Blomberg; T. Burdett; T. Conlin; N. Conte; H. Parkinson. June 29, 2017. URL: https://doi.org/10.1371/journal.pbio.2001414
[vocab-dcat-2]
Data Catalog Vocabulary (DCAT) - Version 2. Riccardo Albertoni; David Browning; Simon Cox; Alejandra Gonzalez Beltran; Andrea Perego; Peter Winstanley. W3C. 4 February 2020. W3C Recommendation. URL: https://www.w3.org/TR/vocab-dcat-2/
[vocab-org]
The Organization Ontology. Dave Reynolds. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/vocab-org/
[webarch]
Architecture of the World Wide Web, Volume One. Ian Jacobs; Norman Walsh. W3C. 15 December 2004. W3C Recommendation. URL: https://www.w3.org/TR/webarch/
[Wgr]
Wet gemeenschappelijke regelingen . URL: https://wetten.overheid.nl/BWBR0003740
KOOP Standaard - Vastgestelde versie