TOOI - Waardelijsten 1.0.1

KOOP Standaard
Vastgestelde versie

Deze versie:
https://standaarden.overheid.nl/tooi/doc/def-st-tooi-waardelijsten-20240129
Laatst gepubliceerde versie:
https://standaarden.overheid.nl/tooi/doc/tooi-waardelijsten
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. De TOOI-waardelijsten bevatten een selectie van informatie in het kennismodel in de toestand waar het kennismodel zich op zeker moment bevindt. Deze selectie kan specifiek gemaakt zijn voor een bepaalde toepassing.

De familie van TOOI-documenten

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

Documentatie

Dit document is gepubliceerd door KOOP, het Kennis- en exploitatiecentrum voor Officiële Overheidspublicaties. Zie het beheerplan voor nadere informatie.

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

Een waardelijst is een selectie van informatie in het kennismodel in de toestand waar het kennismodel zich op zeker moment bevindt. Deze selectie kan specifiek gemaakt zijn voor een bepaalde toepassing.

Het kennismodel verandert in de tijd, en waardelijsten hebben versies. Voor een gedetailleerde beschrijving van de informatiestructuur van waardelijsten — welke typen waardelijst we onderkennen, hoe we omgaan met temporaliteit, welke varianten van elke soort we onderscheiden, welke metadata deze hebben — zie TOOI-waardelijstontologie en het hoofdstuk over wijzigingshistorie in TOOI-ontologie.

1.1 Structuur en onderhoud

1.1.1 Structuur

Elke waardelijst wordt aangeboden in meerdere formats. De RDF-variant van een waardelijst (geserialiseerd als TTL, XML-RDF of JSON-LD) geldt als basisvariant. De inhoud ervan kent dezelfde informatiestructuren als de onderliggende onderdelen van het kennismodel.

Zoals gezegd onderscheidt TOOI verschillende soorten waardelijsten, in verschillende varianten. Elke soort en variant heeft een primair resourcetype.

Type waardelijst Primair resourcetype Beschrijving informatiestructuur
Schemagebaseerde conceptwaardelijst skos:Concept Zie TOOI-thesauri
Collectiegebaseerde conceptwaardelijst skos:Concept idem
Registerwaardelijst op peildatum tooiont:Overheidsorganisatie (of subklasse) Zie TOOI-ontologie, specifiek het hoofdstuk over overheidsorganisaties
Registerwaardelijst compleet tooiont:Overheidsorganisatie (of subklasse) idem

1.1.2 Onderhoud

Afhankelijk van het type waardelijst zijn er verschillende richtlijnen die we hanteren om te bepalen wanneer een nieuwe versie van een waardelijst wordt gegenereerd en gepubliceerd. Een indicatie hiervan is opgenomen in de volgende tabel.

Op aanvraag van afnemers kunnen er nieuwe versies worden gepubliceerd om bijzondere redenen, bijvoorbeeld een ministeriewaardelijst met een peildatum in het verleden. Hoewel dit niet vaak zal voorkomen, houden we in de systematiek rekening met dergelijke situaties. Oplopende versienummers (volgnummers) van een waardelijst kunnen de hieronder beschreven systematiek dus doorkruisen. De metadata van de waardelijst beschrijft de inhoud van de waardelijst, uit het versienummer valt in principe niets af te leiden.

Doorgaans geldt bij registerwaardelijsten dat een nieuwe versie van zowel de peildatumvariant als de compleetvariant tegelijk wordt gepubliceerd. In de volgende tabel worden deze dus niet apart behandeld.

Type waardelijst Publicatieregime
Conceptwaardelijst Een typisch moment om een nieuwe versie van de waardelijst te genereren is als er wijzigingen zijn in het onderliggende schema (bij een schemagebaseerde conceptwaardelijst) of in de onderliggende collectie (bij een collectiegebaseerde conceptwaardelijst). Dat wil zeggen: als er concepten zijn bijgekomen of zijn verwijderd, of de informatie over de concepten in het schema of collectie is gewijzigd (bijvoorbeeld een nieuw altLabel). Veel thesauri binnen TOOI hebben meerdere conceptschema's of meerdere collecties. Als de thesaurus waar het schema of de collectie in gedefinieerd is een nieuwe versie krijgt, kan het zijn dat bepaalde schema's en collecties niet geraakt worden. De van die schema's en collecties afgeleide waardelijsten krijgen dan geen nieuwe versie.
Registerwaardelijst Ministeries Het kabinet kan de indeling van ministeries bij wet wijzigen. Dit gebeurt incidenteel en niet frequent. Wijzigingen in het register leiden tot nieuwe versies van de waardelijsten.
Registerwaardelijst Provincies Geen wijzigingen voorzien
Registerwaardelijst Waterschappen Waterschappen worden gewijzigd bij wet. Dit gebeurt incidenteel en niet frequent. Wijzigingen in het register leiden tot nieuwe versies van de waardelijsten.
Registerwaardelijst Gemeenten Wijzigingen worden bij wet geregeld. Dit gebeurt meestal één keer per jaar met ingang van 1 januari. Wijzigingen in het register vinden ruim daarvoor plaats en leiden tot nieuwe versies van de waardelijsten.
Registerwaardelijst Samenwerkingsorganisaties Wijzigingen worden bij bekendmaking geregeld. Dit gebeurt tamelijk frequent. Wijzigingen in het register vinden plaats met vooruitwerkende of terugwerkende kracht en leiden tot nieuwe versies van de waardelijsten.
Registerwaardelijst Zbo's idem
Registerwaardelijst Caribisch openbaar lichamen Geen wijzigingen voorzien
Registerwaardelijst Overige overheidsorganisaties Wijzigingen worden bij bekendmaking geregeld. Dit gebeurt frequent. Waardelijsten worden periodiek afgeleid en gepubliceerd.

2. Inhoud en opbouw

TOOI onderscheidt vier soorten waardelijsten:

In TOOI-waardelijstontologie wordt per soort gedetailleerd beschreven hoe de informatie die opgenomen wordt in een waardelijst geselecteerd wordt uit de TOOI-kennisgraaf. Op deze plaats wordt nader ingegaan op de uiteindelijke inhoud van de waardelijsten.

2.1 Algemeen

2.1.1 Registerwaardelijsten

Een registerwaardelijst bevat uitspraken over organisaties. Welke uitspraken dat precies zijn is deels hetzelfde voor alle organisaties, maar hangt ook af van de organisatiesoort. Een waardelijst over gemeenten zal per gemeente een uitspraak bevatten die vaststelt in welke provincie de gemeente ligt: dat is specifiek voor instanties van de klasse tooiont:Gemeente. Registerwaardelijsten compleet bevatten naast uitspraken over organisaties ook informatie over historie: wanneer is een organisatie opgericht en weer opgeheven, en in welke toestanden is de organisatie geweest. In de XML-varianten ontbreekt een deel van de historische informatie, zie verderop. In TOOI - Ontologie wordt in detail beschreven welke eigenschappen van toepassing zijn bij welke organisatieklasse, en hoe historische informatie gestructureerd is.

2.1.2 Conceptwaardelijsten

Een conceptwaardelijst bevat uitspraken over concepten. Dit betreft voornamelijk prefLabels en andere labels, en eventueel definities en andere zaken. Sommige conceptwaardelijsten bevatten een concepthiërarchie. Deze boomstructuren worden beschreven met behulp van skos:broader. De uitspraak <a> skos:broader <b> betekent dat concept <a> onder concept <b> geordend is. In [skos-reference] wordt dit alles in detail beschreven.

Concepten en concepthiërarchieën worden door KOOP onderhouden in een thesaurusbeheersysteem. De thesauri worden gebruikt om waardelijsten uit te genereren. De thesauri zelf zijn ook beschikbaar. Een schemagebaseerde conceptwaardelijst is feitelijk een deelverzameling van de uitspraken in de thesaurus. Bij een collectiegebaseerde waardelijst is de relatie complexer.

Voor schemagebaseerde waardelijsten geldt dat de inhoud van de waardelijst geselecteerd wordt op basis van een conceptschema. Simpel gesteld bevat de waardelijst informatie over alle concepten die tot het conceptschema behoren.

Collectiegebaseerde conceptwaardelijsten worden geselecteerd op basis van een collectie. Ze hebben daarom een aantal specifieke kenmerken:

  • Sommige concepten zijn een instantie van tooiont:Groeperingsconcept. Deze concepten mogen niet gebruikt worden in metadata. Ze kunnen gebruikt worden om bijvoorbeeld de gebruikersinterface van een publicatieplatform vorm te geven.
  • Hiërarchische relaties tussen concepten kunnen anders zijn dan in de bronthesaurus
  • Een concept kan een prefLabel hebben dat afwijkt van het prefLabel in de bronthesaurus

Zie volgende paragraaf voor nadere toelichting.

2.2 Collectiegebaseerde conceptwaardelijsten en de relatie met de bronthesaurus

SKOS kent een mechanisme om concepten in een thesaurus te groeperen en te ordenen voor specifieke toepassingen: collecties. Een collectie bevat concepten uit een of meerdere conceptschema's. Binnen een collectie kan sprake zijn van andere hiërarchische relaties dan in de thesaurus zelf. De thesaurus definieert concepthiërarchieën vanuit de algemene betekenis van deze concepten. Sommige toepassingen gebruiken een andere, afwijkende hiërarchie om invulling te geven aan de specifieke informatiebehoefte van hun gebruikers. Een voorbeeld. De volgende afbeelding toont een visuele weergave van een deel van de thesaurus, namelijk een fragment van het conceptschema "overheidsinformatie". Het concept "parlementair document" heeft zes narrowers, waarvan het concept "Kamervraag" op zijn beurt ook twee narrowers heeft.

Structuur waardelijst algemeen
Figuur 1 Structuur waardelijst algemeen

In de waardelijst OP Publicatiesoort zijn lang niet alle concepten uit het schema "overheidsinformatie" relevant. Sommige OP Publicatiesoorten komen uit andere conceptschema's. Binnen het concept "parlementair document" is het concept "motie" niet relevant. Bovendien is het concept "Kamervraag" niet relevant: de narrowers daarvan ("Kamervraag met antwoord" en "Kamervraag zonder antwoord") zijn publicatiesoorten die, voor het gebruik van de betreffende applicatie, direct onder "parlementair document" geordend worden. De structuur van de waardelijst is als volgt:

Structuur waardelijst applicatiespecifiek
Figuur 2 Structuur waardelijst applicatiespecifiek

Deze concepthiërarchie wordt gegenereerd uit een skos:Collectie.

Het volgende voorbeeld laat zien hoe een collectiegebaseerde conceptwaardelijst, in dit geval de waardelijst "Documentsoorten PLOOI-Portaal" samenhangt met de onderliggende collectie. De structuur van een collectiehiërarchie is wezenlijk anders dan een concepthiërarchie. Voor gebruikers van conceptwaardelijsten zijn deze verschillen niet van belang. Vandaar dat uit de collectiehiërchie een waardelijst wordt gegenereerd die in de basis dezelfde structuur heeft als een schemagebaseerde waardelijst.

Structuur collectiegebaseerde waardelijst en collectie
Figuur 3 Structuur collectiegebaseerde waardelijst en collectie

Collectiegebaseerde conceptwaardelijsten kennen een aantal bijzonderheden. De blauw gemarkeerde concepten zijn instanties van tooiont:Groeperingsconcept (een subklasse van skos:Concept) en mogen niet voorkomen in metadata. Ze zijn te herkennen aan de uitspraak:

<https://identifier.overheid.nl/tooi/set/ccw_plooi/k_475dff96> rdf:type tooiont:Groeperingsconcept .

Groeperingsconcepten komen niet voor in de bronthesaurus. De URI van een groeperingsconcept wordt gemunt in de waardelijst zelf. De namespace-URI van het concept is <URI van waardelijstgraaf (werk)>. De local name is "k_" gevolgd door het nummer van de corresponderende collectie in de bronthesaurus. Voorbeeld:

Concepten in een collectiegebaseerde conceptwaardelijst kunnen een prefLabel hebben dat afwijkt van het prefLabel in de bronthesaurus. In de bronthesaurus wordt dat aangegeven met een instantie van de klasse skosxl:Label in combinatie met de property tooiont:context. De waarde van deze property is de graphURI van de waardelijst (op werkniveau). Dit wordt beschreven in het laatste hoofdstuk van TOOI-ontologie.

3. Het gebruik van waardelijsten

3.1 Overzicht

Waardelijsten kunnen voor diverse doeleinden op diverse manieren gebruikt worden. Het eenvoudigst in gebruik zijn conceptwaardelijsten en registerwaardelijsten op peildatum. Registerwaardelijsten compleet bevatten aanzienlijk meer informatie dan hun tegenhangers op peildatum en vragen dus meer inzicht in de gebruikte structuur. De XML-varianten van deze vier waardelijstsoorten (zie 4. De XML-structuur van XML-waardelijsten) bevatten minder informatie dan de RDF-varianten. Voor de compleetlijsten is het verschil nog groter. In het hiernavolgende gaan we nader in op de compleetlijsten.

3.2 Het gebruik van registerwaardelijsten in de compleet-variant

Het gebruik van de registerwaardelijsten in de compleet-variant wordt hierna geïllustreerd aan de hand van een aantal informatievragen met bijbehorende SPARQL. Deze queries werken evengoed op de registers zelf. We nemen hierbij steeds de waardelijst <https://identifier.overheid.nl/tooi/set/ministerie_compleet/v1.ttl> (met als bestandsnaam ministerie_compleet_v1) als basis omdat het bronregister zowel relatief klein en handzaam is, en tegelijkertijd een goed beeld geeft van enerzijds de complexiteit van de modellering, en anderzijds de rijkdom aan informatie die het beschikbaar maakt. Omdat de waardelijst een afslag is van het register, richten de vragen zich op het register.

3.2.1 Hoeveel ministerie-objecten bevat het register?

  SELECT COUNT(?s)
  WHERE {
      ?s a tooiont:Ministerie .
      FILTER NOT EXISTS {?s a tooiont:HistorischeVersie}
  }

Deze query retourneert het aantal ministerie-objecten, inclusief ministeries die ooit bestaan hebben maar inmiddels zijn opgeheven. Niet meegeteld worden de historische versies van een ministerie. Bij weglating van het filter zullen ook deze meegeteld worden. Dat is bij deze specifieke informatievraag niet de bedoeling.

3.2.2 Hoe zijn de namen van de ministeries veranderd in de tijd?

  SELECT ?oc ?org ?t ?hv
  WHERE {
      [] a tooiont:Toestandswijziging ;
          prov:used / tooiont:afkorting ?org ;
          prov:used / tooiont:organisatiecode ?oc ;
          tooiont:tijdstipWijziging ?t ;
          prov:invalidated / tooiont:afkorting ?hv .
  } ORDER BY ?org

Deze query selecteert alle toestandswijzigingen, en bij elk van deze de huidige (of laatst bekende) afgekorte naam en de organisatiecode van organisatie waar de toestandsverandering betrekking op heeft (prov:used), het tijdstip van wijziging, en de afgekorte naam die hoort bij de toestand die na de wijziging niet meer van kracht was (prov:invalidated). Het resultaat van deze query is (gegeven de (versie van de) genoemde waardelijst):

Wijziging Type wijziging Datum Beeindigd Gestart
ministerie:wzg_00926444 tooiont:Samenvoeging 14/10/2010 VROM
ministerie:wzg_00926444 tooiont:Samenvoeging 14/10/2010 VW
ministerie:wzg_00926444 tooiont:Samenvoeging 14/10/2010 IenW
ministerie:wzg_01378363 tooiont:Afsplitsing 26/10/2017 LNV
ministerie:wzg_06434036 tooiont:Samenvoeging 14/10/2010 LNV
ministerie:wzg_06434036 tooiont:Samenvoeging 14/10/2010 EZ
ministerie:wzg_06434036 tooiont:Samenvoeging 14/10/2010 EZK

Dit moet gelezen worden als: er was een samenvoeging op 14 oktober 2010, en als gevolg daarvan zijn VROM en VW (Verkeer en Waterstaat) opgeheven, en is IenW gestart. Merk op dat hierbij de afkortingen gebruikt worden die nu nog geldig zijn, of geldig waren op het moment van opheffen. Voor IenW geldt bijvoorbeeld dat op het moment van oprichting nog MinIenM heette.

3.2.3 Welke ministeries waren met welke naamgeving geldig op peildatum 2 september 2010?

Het kan nuttig zijn om organisaties die op een peildatum bestonden uit te vragen, met de naam die op die datum geldig waren. In dit specifieke voorbeeld is het nodig bij elk relevant ministerie de historische versies te vinden (voor zover aanwezig), en daaruit de versie te selecteren die op de peildatum geldig was. Bij het selecteren van de ministeries die bestonden op de peildatum moeten we rekening houden met het feit dat de properties prov:generatedAtTime en prov:invalidatedAtTime voor een gegeven ministerie in voorkomende gevallen ongespcificeerd kunnen zijn. De waarde van prov:generatedAtTime (?gt) kan eenvoudig onbekend zijn. Als de waarde van prov:invalidatedAt (?it) niet is gespecificeerd, dan betekent dat dat het ministerie nog bestaat. Er zijn dus vier mogelijkheden. Om de zaak te vereenvoudigen definiëren we twee variabelen, ?start en ?end, die we gelijk stellen aan ?gt en ?it als deze gespecificeerd zijn. Zo niet, dan geven we ze een waarde in het verre verleden of de verre toekomst (regel 9 en 10). Vervolgens filteren we alle ministeries weg die op de peildatum nog niet of niet meer bestonden (regel 11 en 12).

Wat volgt is een geneste query van twee niveaus diep om de historische versies te vinden en daaruit de juiste te selecteren. 

  SELECT ?org ?naamGeldigOpPeildatum
  WHERE {
      BIND ( ("2010-09-02T00:00:00"^^xsd:dateTime) AS ?peildatum ) .
      ?org a tooiont:Ministerie ;
              rdfs:label ?label .
      FILTER NOT EXISTS { ?org a tooiont:HistorischeVersie }
      OPTIONAL { ?org prov:generatedAtTime ?gt }
      OPTIONAL { ?org prov:invalidatedAtTime ?it }
      BIND ( (IF (bound(?gt), ?gt, "1800-01-01T00:00:00"^^xsd:dateTime)) AS ?start )
      BIND ( (IF (bound(?it), ?it, "2100-01-01T00:00:00"^^xsd:dateTime)) AS ?end )
      FILTER (?start < ?peildatum )
      FILTER (?end > ?peildatum )

      OPTIONAL { 
          SELECT ?org ?naam
          WHERE {
              {
                  SELECT ?org ( MIN( ?eindeGeldigheidVanToestand  )  AS ?e )
                  WHERE {
                      BIND ( ("2010-09-02T00:00:00"^^xsd:dateTime) AS ?peildatum ) .
                      ?tw a tooiont:Toestandswijziging ;
                          prov:used ?org ;
                          tooiont:tijdstipWijziging ?eindeGeldigheidVanToestand ;
                      .
                      FILTER (?eindeGeldigheidVanToestand > ?peildatum)
                  } GROUP BY ?org HAVING BOUND(?org)  ## Filter met HAVING nodig wegens RDF4J-bug
              }
              ?tw2 a tooiont:Toestandswijziging .
              ?tw2 prov:used ?org .
              ?tw2 tooiont:tijdstipWijziging ?e .
              ?tw2 prov:invalidated / rdfs:label ?naam .
          }
      }
      BIND ( (IF (bound(?naam), ?naam, ?label)) AS ?naamGeldigOpPeildatum )
  } 

Het resultaat van deze query is als volgt:

URI Naam geldig op 2 september 2010
ministerie:mnre0170 ministerie van Verkeer en Waterstaat
ministerie:mnre0180 ministerie van Volkshuisvesting, Ruimtelijke Ordening en Milieubeheer
ministerie:mnre1010 ministerie van Algemene Zaken
ministerie:mnre1013 ministerie van Buitenlandse Zaken
ministerie:mnre1018 ministerie van Defensie
ministerie:mnre1025 ministerie van Volksgezondheid, Welzijn en Sport
ministerie:mnre1034 ministerie van Binnenlandse Zaken en Koninkrijksrelaties
ministerie:mnre1040 ministerie van Economische Zaken
ministerie:mnre1058 ministerie van Justitie
ministerie:mnre1073 ministerie van Sociale Zaken en Werkgelegenheid
ministerie:mnre1090 ministerie van Financiën
ministerie:mnre1109 ministerie van Onderwijs, Cultuur en Wetenschap
ministerie:mnre1150 ministerie van Landbouw, Natuur en Voedselkwaliteit

Het doel van de OPTIONAL-groep is om een eventuele historische versie van een ministerie die geldig was op de peildatum te vinden. Zo ja, dan wordt de naam van die historische versie in het resultaat verwerkt. Zo niet, dan nemen we de naam van het ministerie die op het moment van uitvoering van de querie geldig is. Dat gebeurt op regel 34.

We bekijken nu een vereenvoudigde versie van de diepst geneste query. Deze vind per ministerie de bijbehorende toestandswijzigingen en het tijdstip van wijziging:

  SELECT ?org ?tw ?eindeGeldigheidVanToestand 
  WHERE {
      ?tw a tooiont:Toestandswijziging ;
          prov:used ?org ;
          tooiont:tijdstipWijziging ?eindeGeldigheidVanToestand ;
      .
  } 

Dit levert de volgende resultaten op:

Ministerie Toestandswijziging Tijdstip
ministerie:mnre1045 ministerie:wzg_80272410 2013-01-01T00:00:00
ministerie:mnre1045 ministerie:wzg_17545147 2018-01-01T00:00:00
ministerie:mnre1058 ministerie:wzg_05229330 2018-01-01T00:00:00
ministerie:mnre1058 ministerie:wzg_00821007 2010-12-01T00:00:00
ministerie:mnre1130 ministerie:wzg_08160830 2018-01-01T00:00:00

We nesten deze query om per ministerie alleen de oudst geregistreerde toestandswijziging te vinden.

  SELECT ?org ?e ?tw2 ?naam
  WHERE {
      {
          SELECT ?org ( MIN( ?eindeGeldigheidVanToestand  )  AS ?e )
          WHERE {
              ?tw a tooiont:Toestandswijziging ;
                  prov:used ?org ;
                  tooiont:tijdstipWijziging ?eindeGeldigheidVanToestand ;
              .
          } GROUP BY ?org HAVING BOUND(?org)  ## Filter met HAVING nodig wegens RDF4J-bug
      }
      ?tw2 prov:used ?org ;
          tooiont:tijdstipWijziging ?e ;
          prov:invalidated / rdfs:label ?naam ;
      .
  }

Deze geeft de volgende resultaten:

Ministerie Tijdstip wijziging Toestandswijziging Naam geldig in de toestand vóór wijziging
ministerie:mnre1045 2013-01-01T00:00:00 ministerie:wzg_80272410 ministerie van Economische Zaken, Landbouw en Innovatie
ministerie:mnre1058 2010-12-01T00:00:00 ministerie:wzg_00821007 ministerie van Justitie
ministerie:mnre1130 2018-01-01T00:00:00 ministerie:wzg_08160830 ministerie van Infrastructuur en Milieu

De binnenste query geeft de eerste twee kolommen van deze tabel. De resultaatset wordt gejoind met de resultaten van de buitenste query. Daarmee worden de laatste twee kolomen gevonden. Met een paar kleine aanpassingen kunnen we dit in de hoofdquery plakken, binnen de OPTIONAL-groep. In de binnenste query voegen we een filter op peildatum toe. Daartoe moeten we de peildatum nog een keer toekennen: SPARQL query-evaluatie werkt van binnen naar buiten. Buiten de OPTIONAL-groep, op regel 34, wordt getest of er voor het betreffende ministerie een historische naam is gevonden. Die kennen we dan toe aan het resultaat. Zo niet, dan gebruiken we de naam van het ministerie.

Wanneer we ervoor zouden kiezen bij de de historische versie-objecten een startmoment en eindmoment toe te voegen, dan zou de hoofdquery aanzienlijk eenvoudiger zijn. De OPTIONAL-groep ziet er dan als volgt uit:

  OPTIONAL { 
      ?tw a tooiont:Toestandswijziging .
      ?tw prov:used ?org .
      ?tw prov:invalidated / prov:invalidatedAtTime ?e .
      ?tw prov:invalidated / prov:generatedAtTime ?b .
      ?tw prov:invalidated / rdfs:label ?naam .
      FILTER (?b < ?peildatum)
      FILTER (?e > ?peildatum)
  }

Het voordeel van eenvoudig te begrijpen queries gaat echter ten koste van de eenvoud van de data. Het opslaan van veel redundante gegevens maakt data-entry foutgevoelig. Een klein foutje bij de bron of in de verwerkende software kan moeilijk te vinden en lastig te repareren problemen in de data opleveren. We hebben daarom gekozen voor eenvoud in de data.

4. De XML-structuur van XML-waardelijsten

4.1 Inleiding

De waardelijsten van TOOI worden geserialiseerd als TTL, JSON-LD en RDF/XML beschikbaar gesteld. Daarnaast kent TOOI een eigen XML-vocabulaire om de waardelijsten in XML te serialiseren. Omdat RDF/XML gezien wordt als een notoir complex formaat voor XML-applicaties, is besloten om een toegankelijker formaat te introduceren om relatief platte waardelijsten te introduceren; de hoop is dat het beter bruikbaar is voor XML-technologie gebaseerde systemen en toepassingen.

Het XML-serialisatieformaat is vastgelegd in een XML Schema Document (XSD) met namespace "https://standaarden.overheid.nl/tooi/xmlwaardelijst/". De namespace-URI van het XML-formaat begint niet  met de door TOOI gebruikte "namespace" voor de waardelijst-ontologie https://identifier.overheid.nl/tooi/def/wl/ . De elementen van het waardelijst-XML-formaat zijn geen resources; de XML-serialisatie valt onder door KOOP beheerde XML-definities zoals gepubliceerd op https://standaarden.overheid.nl.

De laatste versie 3.2.0 van de XSD is ook daar te vinden: https://standaarden.overheid.nl/tooi/xmlwaardelijst/3.2.0/tooi-waardelijst.xsd .

4.1.1 Soorten waardelijsten

De waardelijstontologie van TOOI kent vier soorten waardelijsten. Het type waardelijst wordt vastgelegd in de waardelijst zelf, als waarde van rdf:type 

waarden label rdf:type (https://identifier.overheid.nl/tooi/def/wl/)
organisaties Registerwaardelijst op peildatum RegisterwaardelijstOpPeildatum
organisaties Registerwaardelijst compleet RegisterwaardelijstCompleet
concepten Schemagebaseerde conceptwaardelijst SchemagebaseerdeConceptwaardelijst
concepten Collectiegebaseerde conceptwaardelijst CollectiegebaseerdeConceptwaardelijst

De algemene structuur van XML-waardelijsten in TOOI is zo generiek mogelijk opgezet. De tooi-waardelijst.xsd wordt voor alle soorten waardelijsten gebruikt; maar per soort waardelijst worden bepaalde delen van het schema niet of anders ingezet.

4.1.2 Leeswijzer

Onderstaande documentatie geeft na een generieke beschrijving voor alle waardelijsten eerst hoe deze vier soorten in de XML-vocabulaire worden uitgedrukt. Daarna volgt de referentiedocumentatie per XML-element.

Elementnamen staan tussen punthaken in een niet-proportioneel (monospaced) lettertype: <element>.

De voorbeelden in deze documentatie zijn zo kort mogelijk. Inhoud die niet relevante is voor het desbetreffende voorbeeld wordt weergegeven met drie puntjes (...).

Complete voorbeelden zijn te vinden op https://tardis.overheid.nl/waardelijsten.html.

4.1.2.1 Technisch

In de XSD wordt spaarzaam gebruikt gemaakt van XML-attributen; de vocabulaire gebruikt uitsluitend elementen om de waardelijsten-onderdelen uit te drukken.

Alle elementnamen zijn geschreven in onderkast; de serialisatie van een waardelijst in XML is geen informatiemodel maar slechts een uitdrukking daarvan.

De XSD definieert de elementen in de namespace https://standaarden.overheid.nl/tooi/xmlwaardelijst/ . De voorbeelden in deze documentatie maken gebruik van een default namespace. Uiteraard kan de namespace ook aan een prefix gebonden worden; zo definiëren de waardelijsten op tardis.overheid.nl de namespace-prefix-binding xmlns:tooiwl="https://standaarden.overheid.nl/tooi/xmlwaardelijst/". Deze namespace prefix is wel dezelfde als gebruikt in de TOOI-ontologie, maar de namespaces zelf verschillen.

Ook kunnen alle in TOOI gedefinieerde namespaces worden opgenomen, al is dat technisch niet relevant; de inhoud van een XML-element heeft geen "eigen" namespace. De TOOI-URIs worden daarom in de XML-serialisatie volledig uitgeschreven zonder prefix.

4.2 Generieke structuur voor alle waardelijsten

Een waardelijst heeft root-element <waardelijst>. Dit element draagt de namespace-definities en de schemalocation.

Een waardelijst heeft altijd een <naam>. De metadata die de waardelijst zelf beschrijft is opgenomen in het element <metadata>. Binnen dit element worden de eigenschappen van de waardelijst gecodeerd middels <uitspraak> -elementen met een <predicaat> en een <object>. In de metadata van de waardelijst zelf worden altijd de rdf:type en dct:identifier gegeven.

Na de <metadata> volgt de inhoud van de waardelijst, de waarden zelf, die afhankelijk van de soort waardelijst anders gestructureerd is.

Een voorbeeld van de generieke elementen van een waardelijst https://identifier.overheid.nl/tooi/set/provincie_peildatum/v1.xml  van rdf:type  "RegisterwaardelijstOpPeildatum" met naam "voorbeeld waardelijst op peildatum" en van peildatum 23 juni 2020:

<waardelijst xmlns="https://standaarden.overheid.nl/tooi/xmlwaardelijst/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="https://standaarden.overheid.nl/tooi/xmlwaardelijst/
  https://standaarden.overheid.nl/tooi/xmlwaardelijst/3.2.0/tooi-waardelijst.xsd">
  <naam>voorbeeld waardelijst op peildatum</naam>
  <metadata>
    <uitspraak>
      <predicaat>http://purl.org/dc/terms/identifier</predicaat>
      <object>https://identifier.overheid.nl/tooi/set/provincie_peildatum/v1.xml</object>
    </uitspraak>
    <uitspraak>
      <predicaat>http://www.w3.org/1999/02/22-rdf-syntax-ns#type</predicaat>
      <object>https://identifier.overheid.nl/tooi/def/wl/RegisterwaardelijstOpPeildatum</object>
    </uitspraak>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/def/ont/peildatum</predicaat>
      <object>2020-06-23T00:00:00</object>
    </uitspraak>
  </metadata>
  <!-- de inhoud van de waardelijst: de waarden -->
</waardelijst>

4.3 Registerwaardelijst op peildatum

De registerwaardelijsten op peildatum hebben een relatief eenvoudige XML-structuur. Een peildatumwaardelijst geeft geen historische informatie — alleen informatie over organisaties die op de peildatum bestonden, in de toestand waarin ze zich op dat moment bevonden. Onderstaand voorbeeld toont een dergelijke lijst van <waarde>-elementen.

Elk primair object (in dit geval de organisatie) wordt samen met de bij dat object horende gegevens gerepresenteerd als een element <waarde>. Dit element heeft twee kind-elementen die in elke waardelijst verplicht aanwezig zijn

In een registerlijst op peildatum volgt hierop alleen een lijst van nul of meer <uitspraak>-elementen. Een <uitspraak> beschrijft de extra kenmerken van het object (de organisatie) in de vorm van de elementen <predicaat>-  en <object>. Als subject van het predicaat geldt steeds de resource die in het meest direct bovenliggende <code> -element genoemd wordt.

Het volgende voorbeeld toont de provincie https://identifier.overheid.nl/tooi/id/provincie/pv30 die de organisatiecode "pv30" draagt. Hierbij figureert het element <code> als subject, het element <predicaat> als predicaat, en het element <object> als object.

Merk op dat het rdfs:label ook als <uitspraak> en daarmee redundant binnen de <waarde> kan worden gecodeerd.

<?xml version="1.0" encoding="UTF-8"?>
<waardelijst xmlns="https://standaarden.overheid.nl/tooi/xmlwaardelijst/">
  <naam>provincies op peildatum</naam>
  <metadata>
    <uitspraak>
      <predicaat>http://www.w3.org/1999/02/22-rdf-syntax-ns#type</predicaat>
      <object>https://identifier.overheid.nl/tooi/def/wl/RegisterwaardelijstOpPeildatum</object>
    </uitspraak> 
    ...
  </metadata>
  <waarde>
    <code>https://identifier.overheid.nl/tooi/id/provincie/pv30</code>
    <label>provincie Noord-Brabant</label>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/def/ont/provinciecode</predicaat>
      <object>30</object>
    </uitspraak>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/def/ont/organisatiecode</predicaat>
      <object>pv30</object>
    </uitspraak>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/def/ont/organisatiesoort</predicaat>
      <object>https://identifier.overheid.nl/tooi/def/thes/kern/c_358e6463</object>
    </uitspraak>
    <uitspraak>
      <predicaat>http://www.w3.org/2000/01/rdf-schema#label</predicaat>
      <object>provincie Noord-Brabant</object>
    </uitspraak>
    ...
  </waarde>
  <waarde>
    <code>https://identifier.overheid.nl/tooi/id/provincie/pv20</code>
    <label>provincie Groningen</label>
    <uitspraak>...</uitspraak>
    ...
  </waarde>
  ...
</waardelijst>

4.4 Registerwaardelijst compleet

Voor de registerwaardelijsten-compleet moet deze structuur verrijkt worden. Zowel de weerslag van de existentiële wijzigingen als die van de toestandswijzigingen moeten daarin een plaats krijgen. Uitgangspunt hierbij is dat de codering zo dicht mogelijk bij de XML-structuur van registers op peildatum blijft: ook hier volgt op <metadata>  van de waardelijst zelf alleen een lijst van <waarde> -elementen, voor elke organisatie één. En ook voor compleetlijsten worden de gegevens van de meest recente (en voor nog bestaande organisaties actuele) organisatie met <uitspraak> -elementen binnen de <waarde>  gegeven. De gegevens van historische versies van de organisatie worden in eigen elementen gecodeerd: <versie> . De lijst van versies wordt ná de uitspraken geplaatst.

<versie>  heeft een vergelijkbaar content model als het element <waarde>  zelf:

Deze worden gevolg door een lijst van <uitspraak> -elementen. Een waardelijst compleet heeft altijd één uitspraak met predicaat tooiont:einddatum . Op basis van deze indicatie kan de volgorde in de tijd van de verschillende historische versies worden afgeleid.

Het wijzigingsobject en de historische toestand zijn in feite impliciet gemodelleerd in het <versie> -element. Dat kan omdat elke toestandswijziging altijd bij één enkele organisatie hoort.

Het voorbeeld hieronder geeft de <waarde>  voor één ministerie met twee historische versies.

<waarde xmlns="https://standaarden.overheid.nl/tooi/xmlwaardelijst/">
  <code>https://identifier.overheid.nl/tooi/id/ministerie/mnre1058</code>
  <label>ministerie van Justitie en Veiligheid</label>
  <uitspraak>
    <predicaat>https://identifier.overheid.nl/tooi/opvolgerVan</predicaat>
    <object>https://identifier.overheid.nl/tooi/id/ministerie/hv_04793043</object>
  </uitspraak>
  <uitspraak>
    <predicaat>https://identifier.overheid.nl/tooi/opvolgerVan</predicaat>
    <object>https://identifier.overheid.nl/tooi/id/ministerie/hv_04795600</object>
  </uitspraak> 
  <uitspraak>
    <predicaat>http://www.w3.org/1999/02/22-rdf-syntax-ns#type</predicaat>
    <object>https://identifier.overheid.nl/tooi/def/ont/Ministerie</object>
  </uitspraak>
  <uitspraak>
    <predicaat>https://identifier.overheid.nl/tooi/def/ont/organisatiesoort</predicaat>
    <object>https://identifier.overheid.nl/tooi/def/thes/kern/c_97fd6a12</object>
  </uitspraak>
  ...
  <versie>
    <versiecode>https://identifier.overheid.nl/tooi/id/ministerie/hv_04793043</versiecode>
    <label>ministerie van Justitie</label>
    <uitspraak>
      <predicaat>http://www.w3.org/1999/02/22-rdf-syntax-ns#type</predicaat>
      <object>https://identifier.overheid.nl/tooi/def/ont/HistorischeVersie</object>
    </uitspraak>
    <uitspraak>
      <predicaat>http://www.w3.org/2000/01/rdf-schema#label</predicaat>
      <object>ministerie van Justitie</object>
    </uitspraak>
    <uitspraak>
      <predicaat>http://www.w3.org/ns/prov#invalidatedAtTime</predicaat>
      <object>2010-12-01T00:00:00</object>
    </uitspraak>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/def/ont/afkorting</predicaat>
      <object>MinJus</object>
    </uitspraak>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/def/ont/einddatum</predicaat>
      <object>2010-11-30</object>
    </uitspraak>
    <uitspraak>...</uitspraak> 
    ...
  </versie>
  <versie>
    <versiecode>https://identifier.overheid.nl/tooi/id/ministerie/hv_04795600</versiecode>
    <label>ministerie van Veiligheid en Justitie</label>
    ...
  </versie>
  <versie>...</versie>
  ...
</waarde>  

4.4.1 Existentiële wijzigingen

Existentiële wijzigingen worden met een vereenvoudigde representatie gecodeerd. Dat betekent dat de XML-variant van de compleetlijsten minder informatie bevat dan de RDF-varianten. De vereenvoudiging is dat de wijzigingsobjecten niet meegenomen worden in de XML. Alleen de opvolgingsrelatie zijn expliciet opgenomen, redundant in twee richtingen: bij de opgeheven organisatie staat een verwijzing naar de opvolger, bij de opvolger naar de voorganger. Hiervoor worden XML-specifieke predicaten gebruikt die niet in het kennismodel gedefinieerd zijn. Deze predicaten zijn niet opgenomen in het kennismodel, omdat dat ze daar redundant zouden zijn en daarom op gespannen voet staan met de doelstelling van interoperabiliteit. Het gaat om de volgende predicaten:

  • https://identifier.overheid.nl/tooi/opvolgerVan, het XML-specifieke predicaat dat aangeeft dat het object een voorganger is van de organisatie die het subject is
  • https://identifier.overheid.nl/tooi/opgevolgdDoor, het XML-specifieke predicaat dat aangeeft dat het object de opvolger is van de organisatie die het subject is

Deze vereenvoudiging heeft consequenties:

  • Omdat een opvolger meerdere voorgangers kan hebben kunnen er meer dan één <uitspraak>-elementen met dit <predicaat> aan een <waarde>  worden gekoppeld.
  • Het omgekeerde, een voorganger met meerdere opvolgers (zoals bij op- en afsplitsingen optreedt) , wordt niet in de XML opgenomen. Zie hieronder onder "Missende informatie".
  • De <uitspraak> -elementen die betrekking hebben op opvolgingsrelaties worden altijd opgenomen als gegeven van de meest recente organisatie, dus zonder einddatum. Dit correspondeert met het feit dat in het onderliggende semantisch model deze relaties betrekking hebben op organisaties, niet zijnde historische versies. Een <waarde> verwijst wel met tooioint:opvolgerVan  naar al zijn <versie> -elementen, maar niet andersom.

Het voorbeeld hieronder geeft een existentiële wijziging waarin drie imaginaire gemeentes zijn betrokken.

<?xml version="1.0" encoding="UTF-8"?>
<waardelijst xmlns="https://standaarden.overheid.nl/tooi/xmlwaardelijst/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="https://standaarden.overheid.nl/tooi/xmlwaardelijst/
  https://standaarden.overheid.nl/tooi/xmlwaardelijst/3.2.0/tooi-waardelijst.xsd">
  <naam>voorbeeld compleetlijst met existentiële wijzigingen</naam>
  <metadata>
    <uitspraak>
      <predicaat>http://purl.org/dc/terms/identifier</predicaat>
      <object>https://identifier.overheid.nl/tooi/set/ministeries_compleet_existentieel/v1.xml</object>
    </uitspraak>
    <uitspraak>
      <predicaat>http://www.w3.org/1999/02/22-rdf-syntax-ns#type</predicaat>
      <object>https://identifier.overheid.nl/tooi/def/wl/RegisterwaardelijstCompleet</object>
    </uitspraak>
  </metadata>
  <!-- gemeente A, opgeheven -->
  <waarde>
    <code>https://identifier.overheid.nl/tooi/id/gemeente/gm9091</code>
    <label>gemeente Waaibergen</label>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/officieleNaamInclSoort</predicaat>
      <object>gemeente Waaibergen</object>
    </uitspraak>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/einddatum</predicaat>
      <object>2017-12-31</object>
    </uitspraak>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/opgevolgdDoor</predicaat>
      <object>https://identifier.overheid.nl/tooi/id/gemeente/gm9093</object>
    </uitspraak>
  </waarde>
  <!-- gemeente B, opgeheven -->
  <waarde>
    <code>https://identifier.overheid.nl/tooi/id/gemeente/gm9092</code>
    <label>gemeente Windhoek</label>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/officieleNaamInclSoort</predicaat>
      <object>gemeente Windhoek</object>
    </uitspraak>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/einddatum</predicaat>
      <object>2017-12-31</object>
    </uitspraak>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/opgevolgdDoor</predicaat>
      <object>https://identifier.overheid.nl/tooi/id/gemeente/gm9093</object>
    </uitspraak>
  </waarde>
  <!-- gemeente C, opvolger van A en B -->
  <waarde>
    <code>https://identifier.overheid.nl/tooi/id/gemeente/gm9093</code>
    <label>gemeente Stormbeek</label>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/officieleNaamInclSoort</predicaat>
      <object>gemeente Stormbeek</object>
    </uitspraak>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/begindatum</predicaat>
      <object>2018-01-01</object>
    </uitspraak>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/opvolgerVan</predicaat>
      <object>https://identifier.overheid.nl/tooi/id/gemeente/gm9091</object>
    </uitspraak>
    <uitspraak>
      <predicaat>https://identifier.overheid.nl/tooi/opvolgerVan</predicaat>
      <object>https://identifier.overheid.nl/tooi/id/gemeente/gm9092</object>
    </uitspraak>
  </waarde>
</waardelijst>

4.4.2 Onderdelen van de waardelijstontologie die niet in de XML-formaat opgenomen zijn

De volgende informatie is wel in de waardellijstontologie opgenomen, daarmee ook in de andere drie serialisatieformaten, maar niet in deze XML-versie beschikbaar:

  • tooiont:tijdstipWijziging: het tijdstip dat de wijziging van kracht is geworden. De gebruiker kan dit afleiden uit de einddatum van de voorganger en de begindatum van de opvolger
  • tooiont:grondslag: het wijzigingsbesluit. Als deze informatie nodig is, zal deze erbij gezocht moeten worden
  • De soort wijziging (tooiont:Samenvoeging, tooiont:Uitbreiding, etc)
  • prov:used-relaties: deze relaties kunnen voorkomen bij gemeentelijke herindeling. Bij bijvoorbeeld een afsplitsing kun je daardoor weten dat gemeente A afgesplitst is van organisatie B. In dat geval is organisatie B geen voorganger maar wel betrokken. Er is dus geen opvolgingsrelatie, en de relatie wordt niet meegenomen in de XML.

4.5 Schemagebaseerde conceptwaardelijst

Waardelijsten als serialisatie van de concepten die in TOOI een conceptschema worden beheerd bevatten na de <metadata>  een serie van één of meer <waarde> -elementen met een <code>  en een <label>  en optioneel een serie <uitspraken> , net zoals de waardelijsten van organisaties. Het afwijkende is dat een <waarde> -element "genest" kan worden: waarden kunnen zelf waarden bevatten. Deze "nesting" is de XML-representatie van skos:broader : elk concept met een skos:broader wordt in de XML-waardelijst "onder" zijn bredere term geserialiseerd. Geneste <waarde>-elementen worden niet gebruikt in registergebaseerde waardelijsten.

In het voorbeeld hieronder vallen "evenementen", "media" en "cultureel erfgoed' onder de bredere term "cultuur en recreatie".

<waarde xmlns="https://standaarden.overheid.nl/tooi/xmlwaardelijst/">
  <code>https://identifier.overheid.nl/tooi/def/thes/top/c_0361ffb3</code>
  <label>cultuur en recreatie</label>
  <waarde>
    <code>https://identifier.overheid.nl/tooi/def/thes/top/c_2408fb5a</code>
    <label>cultureel erfgoed</label>
  </waarde>
  <waarde>
    <code>https://identifier.overheid.nl/tooi/def/thes/top/c_6b728132</code>
    <label>media</label>
  </waarde>
  <waarde>
    <code>https://identifier.overheid.nl/tooi/def/thes/top/c_70e03904</code>
    <label>evenementen</label>
  </waarde>
  ...
</waarde>

4.6 Collectiegebaseerde conceptwaardelijst

Collectiegebaseerde waardelijsten worden gecodeerd met het element <collectie> . Dit element komt alleen voor in CollectiegebaseerdeConceptwaardelijsten als direct kind van <waardelijst> , volgend op <metadata> . Een waardelijst kan een mix van zowel <waarde> -  als <collectie> -elementen bevatten.

Een <collectie>  heeft een vergelijkbaar model met <versie> 

De eigenschap skos:member  van de skos:Collection  wordt "geserialiseerd" in de XML-waardelijst doordat de aangewezen concepten en/of subcollecties als kind-element van <collectie>  wordt opgenomen. Een <collectie>  bevat een serie van <waarde> -elementen en/of <collectie> -elementen.  

Het voorbeeld hieronder laat het gebruik van <collectie>  zien voor de PLOOI-specifieke collectie "parlementair document".

<?xml version="1.0" encoding="UTF-8"?>
<waardelijst xmlns="https://standaarden.overheid.nl/tooi/xmlwaardelijst/">
  <naam>...</naam>
  <metadata>
    <uitspraak>
      <predicaat>http://www.w3.org/1999/02/22-rdf-syntax-ns#type</predicaat>
      <object>https://identifier.overheid.nl/tooi/def/wl/CollectiegebaseerdeConceptwaardelijst</object>
    </uitspraak> 
    ... 
  </metadata>
  <collectie xmlns="https://standaarden.overheid.nl/tooi/xmlwaardelijst/">
    <collectiecode>https://identifier.overheid.nl/tooi/def/thes/kern/skosCollection_c9747bf6</collectiecode>
    <label>parlementair document</label>
    <expandeert>https://identifier.overheid.nl/tooi/def/thes/kern/c_1986dbe5</expandeert>
    <collectie>
      <collectiecode>https://identifier.overheid.nl/tooi/def/thes/kern/skosCollection_b41918c8</collectiecode>
      <label>Kamervraag</label>
      <expandeert>https://identifier.overheid.nl/tooi/def/thes/kern/c_dc6ba2eb</expandeert>
      <waarde>
        <code>https://identifier.overheid.nl/tooi/def/thes/kern/c_03c52ba0</code>
        <label>Kamervraag zonder antwoord</label>
      </waarde>
      <waarde>
        <code>https://identifier.overheid.nl/tooi/def/thes/kern/c_6d494ab6</code>
        <label>Kamervraag met antwoord</label>
      </waarde>
    </collectie>
    <waarde>
      <code>https://identifier.overheid.nl/tooi/def/thes/kern/c_056a75e1</code>
      <label>Kamerstuk</label>
    </waarde>
    <waarde>
      <code>https://identifier.overheid.nl/tooi/def/thes/kern/c_a17ef403</code>
      <label>Handelingen</label>
    </waarde>
    ...
  </collectie>
  <waarde>...</waarde>
</waardelijst>

4.7 Referentiedocumentatie van elementen en types

In de referentiedocumentatie wordt net zoals op Tardis de namespace-binding xmlns:tooiwl = https://standaarden.overheid.nl/tooi/xmlwaardelijst/ gebruikt.

4.7.1 Element tooiwl:waardelijst

Definitie
Het root-element van de XML-waardelijst
Diagram
element naam
Figuur 4 Het contentmodel van tooiwl:waardelijst
Kinderen
tooiwl:collectie, tooiwl:metadata, tooiwl:naam, tooiwl:waarde

4.7.2 Element tooiwl:naam

Definitie
De naam van de waardelijst
Diagram
element naam
Figuur 5 Het contentmodel van tooiwl:naam
Type
xs:string
Details
Dit element wordt gevuld met de waarde van tooiont:titel  van de waardelijst in TOOI
Gebruikt door
tooiwl:waardelijst

4.7.3 Element tooiwl:metadata

Definitie
De metadata van de waardelijst zelf
Diagram
element metadata
Figuur 6 Het contentmodel van tooiwl:metadata
Gebruikt door
tooiwl:waardelijst
Kinderen
tooiwl:uitspraak

4.7.4 Element tooiwl:uitspraak

Definitie
De gegevens van de resource, beschreven als predicaat met een object
Diagram
element uitspraak
Figuur 7 Het contentmodel van element tooiwl:uitspraak
Gebruikt door
tooiwl:metadata, tooiwl:versie, tooiwl:waarde
Kinderen
tooiwl:object, tooiwl:predicaat

4.7.5 Element tooiwl:predicaat

Definitie
Het predicaat van de uitspraak
Diagram
element predicaat
Figuur 8 Het contentmodel van tooiwl:predicaat
Type
tooiwl:tooi-uri
Gebruikt door
tooiwl:uitspraak

4.7.6 Element tooiwl:object

Definitie
Het object van het predicaat van de uitspraak
Diagram
element object
Figuur 9 Het contentmodel van tooiwl:object
Type
xs:string
Gebruikt door
tooiwl:uitspraak

4.7.7 Element tooiwl:waarde

Definitie
De serialisatie van een concept of registerwaarde uit TOOI
Diagram
element waarde
Figuur 10 Het contentmodel van tooiwl:waarde
Gebruikt door
tooiwl:collectie, tooiwl:waarde, tooiwl:waardelijst
Kinderen
tooiwl:code, tooiwl:label, tooiwl:uitspraak, tooiwl:versie, tooiwl:waarde

4.7.8 Element tooiwl:code

Definitie
de TOOI-URI van de waarde
Diagram
element code
Figuur 11 Het contentmodel van tooiwl:code
Type
tooiwl:tooi-uri
Gebruikt door
tooiwl:waarde

4.7.9 Element tooiwl:label

Definitie
De serialisatie van rdf:label
Diagram
element label
Figuur 12 Het contentmodel van tooiwl:label
Type
xs:string
Gebruikt door
tooiwl:collectie, tooiwl:versie, tooiwl:waarde

4.7.10 Element tooiwl:versie

Definitie
serialisatie van een historische versie van een organisatie
Diagram
element versie
Figuur 13 Het contentmodel van tooiwl:versie

Gebruikt door
tooiwl:waarde
Kinderen
tooiwl:label, tooiwl:uitspraak, tooiwl:versiecode

4.7.11 Element tooiwl:versiecode

Definitie
De TOOI-URI van de historische versie
Diagram
element versiecode
Figuur 14 Het contentmodel van tooiwl:versiecode
Type
tooiwl:tooi-uri
Gebruikt door
tooiwl:versie

4.7.12 Element tooiwl:collectie

Definitie
De serialisatie van een skos:Collection in een collectiegebaseerde waardelijst
Diagram
element collectie
Figuur 15 Het contentmodel van tooiwl:collectie
Gebruikt door
tooiwl:collectie, tooiwl:waardelijst
Kinderen
tooiwl:collectie, tooiwl:collectiecode, tooiwl:expandeert, tooiwl:label, tooiwl:waarde

4.7.13 Element tooiwl:collectiecode

Definitie
De TOOI-URI van de skos:Collection
Diagram
element collectiecode
Figuur 16 Het contentmodel van tooiwl:collectiecode
Type
tooiwl:tooi-uri
Gebruikt door
tooiwl:collectie

4.7.14 Element tooiwl:expandeert

Definitie
Het concept waarmee de collectie correspondeert
Diagram
element expandeert
Figuur 17 Het contentmodel van tooiwl:expandeert
Type
tooiwl:tooi-uri
Gebruikt door
tooiwl:collectie

4.7.15 Simple Type tooiwl:tooi-uri

Definitie
Datatype voor TOOI-URIs
Diagram
simple type tooi-uri
Figuur 18 Het contentmodel van tooiwl:tooi-uri
Type
xs:anyURI
Gebruikt door
tooiwl:code, tooiwl:collectiecode, tooiwl:expandeert, tooiwl:predicaat, tooiwl:versiecode
KOOP Standaard - Vastgestelde versie