TOOI - Beheerplan 1.0.4

"TOOI" staat voor Thesauri en Ontologieën voor OverheidsInformatie. TOOI is een kennismodel van de organisatie van de Nederlandse overheid en de officiële informatie die die overheid op internet publiceert. Het model kan in uiteenlopende toepassingen gebruikt worden om informatie uit verschillende bronnen te combineren en in samenhang doorzoekbaar te maken. Het model is eenvoudig toepasbaar in alle informatiesystemen die officiële overheidsinformatie op internet publiceren en in alle informatiesystemen die deze informatie uit verschillende bronnen verzamelen of hergebruiken.

BOMOS2 - Governance: beleid uitzetten over de eigen bestuurlijke organisatie (zoals de rechtsvorm); het huishoudelijke reglement (de charter), maar ook allianties vormen met andere organisaties. Het regelen van besluitvorming is cruciaal.

TOOI is ontwikkeld en wordt beheerd door KOOP, het Kennis- en Exploitatiecentrum officiële Overheidspublicaties.

Eigenaar van TOOI is de afdeling Basisinfrastructuur van de Digitale Overheid onder DG Digitalisering en Overheidsorganisatie (DGDOO/DO/BI) van het ministerie van BZK.

KOOP bouwt aan een community van stakeholders die actief wordt betrokken bij de doorontwikkeling van TOOI. Tot de stakeholders behoren:

• Overheidsorganisaties (bestuursorganen) die content aanleveren aan centrale voorzieningen voor officiële publicatie, zoals:
  • de centrale voorzieningen voor officiële elektronische publicaties (OEP) en Decentrale regelgeving officiële publicaties (DROP),
  • de voorzieningen voor geconsolideerde wet- en regelgeving op wetten.overheid.nl en de centrale voorziening voor decentrale regelgeving (CVDR),
  • de Digitale infrastructuur voor de Wet open overheid (DiWoo)
  • het Digitaal Stelsel Omgevingswet (DSO),
  • het Register voor overheidsorganisaties (ROO),
  • het Dataregister van de Nederlandse overheid (data.overheid.nl);
• Beheerders van deze centrale voorzieningen;
• Publieke en private partijen die content afnemen van bedoelde overheidsorganisaties of van deze centrale voorzieningen;
• Leveranciers van software in de publicatieketens.

In Bijlage 1: Sturing doorontwikkeling wordt beschreven hoe de sturing op (modulaire) doorontwikkeling van TOOI is ingericht.

BOMOS2 - Financiën: een financieel model voor de lange termijn hebben die opbrengsten garandeert in overeenstemming met de behoeftes.

TOOI wordt ontwikkeld en onderhouden door KOOP in het kader van de opdracht voor het inrichten van de OfficiëleElektronischePublicatie-keten (de OEP-keten). De kosten voor het beschikbaar stellen van de specificaties, het beheer van de registraties en beantwoording van vragen en wijzigingsverzoeken zijn structureel gefinancierd.

Aan het gebruik van de TOOI-specificaties, de informatie in de registers en het stellen van vragen of het indienen van wijzigingsverzoeken zijn geen kosten verbonden.

BOMOS2 - Community: Het is essentieel dat de juiste stakeholders participeren in de community, en dat er niet een onevenwichtige community ontstaat waar slechts een bepaald type stakeholder (bv. leverancier) in de community actief participeert. Deze taak behelst het bewaken en bevorderen van een goede samenstelling van de community.

De belangrijkste doelstelling van TOOI is de interoperabiliteit van informatiesystemen voor publicatie van officiële overheidspublicaties voor de gehele samenleving, rekening houdend met relaties tussen deze publicaties onderling en tussen deze publicaties en andere (Nederlandse of internationale) overheidsinformatie. Het functioneel toepassingsgebied is in het algemeen alle officiële overheidsinformatie op internet en in het bijzonder de actief openbaar te maken informatie zoals bedoeld in artikel 3.3 van de Wet open overheid.

Aangezien de scope van TOOI de hele Nederlandse overheid omvat en overheidsinformatie de hele Nederlandse samenleving kan raken is de community niet anders beperkt dan tot Nederland. Eenieder die vindt dat hij of zij daar belang bij heeft kan bijdragen aan de specificaties van TOOI. In de praktijk wordt het actieve deel van de community gevormd door personen die betrokken zijn bij de publicatie van overheidsinformatie of bij de verwerking van gepubliceerde overheidsinformatie.

De volgende partijen spelen in ieder geval al een concrete rol in de totstandkoming van TOOI:

• Opdrachtgevers van verschillende KOOP-producten zijn verantwoordelijk voor het bestaan van de TOOI standaard
• Het Team Contentmodellering van KOOP is verantwoordelijk voor beheer en doorontwikkeling van TOOI
• Het redactieteam van het Register van Overheidsorganisaties (ROO) bij KOOP levert de authentieke informatie over overheidsorganisaties voor de TOOI-registers
• Het ontwikkelteam van DiWoo gebruikt de TOOI-standaard
• De ontwikkelteams in de OP-keten behoren tot de eerste groep die overschakelt van OWMS naar TOOI
• Leveranciers van informatiesystemen die content aanleveren aan de OP-keten en in het Digitaal Stelsel Omgevingswet (DSO) passen waarden uit de TOOI-waardelijsten toe
• Overheidsorganisaties die informatie publiceren op overheid.nl

BOMOS2 - Adoptie en erkenning: Het opstellen van een adoptiestrategie om ervoor te zorgen dat de markt de standaarden adopteert. Onderdeel van een adoptie-strategie kan zijn het nastreven van erkenning door externe 'statusverleners' bijvoorbeeld de 'pas toe of leg uit' lijst, of om de standaard uit te brengen als NEN-document (NTA, NPR of norm).

TOOI wordt ontwikkeld als standaard die zal worden toegepast in de publicatieketen voor officiële bekendmakingen. TOOI wordt daarmee in de praktijk getoetst op bruikbaarheid en vrijwel alle overheidsorganisaties zullen TOOI metadata gaan aanleveren. Veel informatie wordt aangeboden vanuit informatiesystemen die door leveranciers als pakket worden aangeboden. De TOOI-URIs zullen naar verwachting in veel van deze pakketsoftware worden geïmplementeerd, zodat overheden kunnen aansluiten op de voorzieningen van KOOP. Verwacht wordt dat dat een grote stimulans betekent voor de adoptie van TOOI.

TOOI omvat alle functionaliteit die eerder al door OWMS werd geboden. OWMS was een standaard op de Pas-toe-of-leg-uit-lijst van het Forum Standaardisatie. Ook TOOI zal worden aangemeld voor vermelding op een van de lijsten met open standaarden van het Forum.

BOMOS2 - Rechtenbeleid: Het voeren van beleid op het gebied van het intellectueel eigendom en copyright rondom de inhoudelijke producten van de community en de rechten (en plichten) van de deelnemers in de community.

De TOOI-ontologieën en de TOOI-thesauri met bijbehorende documentatie en specificaties zijn met publieke middelen tot stand gekomen en vrij beschikbaar voor eenieder. Hergebruik is toegestaan, mits onder naamsvermelding (BY). Een CC-BY-licentie dus. De naamsvermelding moet luiden: "TOOI (Thesauri en Ontologieën voor Overheidsinformatie) is ontwikkeld door het ministerie van Binnenlandse Zaken en Koninkrijksrelaties.".

De inhoud van de TOOI-registers en de TOOI-waardelijsten is vrij beschikbare overheidsinformatie die zonder beperkingen door eenieder gebruikt mag worden.

BOMOS2 - Architectuur en roadmapping: Het uitzetten en toetsen van de inhoudelijke lijnen en het op hoofdlijnen bewaken van de samenhang tussen de inhoudelijke producten van de community, maar ook met producten van buiten de community zoals aangrenzende standaarden zodat overlap voorkomen wordt.

Met roadmapping wordt bedoeld de inhoudelijke lijn uit te zetten; bijvoorbeeld het uitstippelen van de standaardisatie-agenda voor de komende jaren. Ook het versiebeheer-beleid is een belangrijk onderdeel van roadmapping.

2.4.2 TOOI-modules

2.4.2.1 TOOI-Ontologie

De TOOI-ontologie is het semantisch model voor alle informatie in de andere onderdelen en de basis onder TOOI en onder TOOI-toepassingen. Bij wijzigingen van de TOOI-Ontologie moet de impact op alle andere modulen en op de toepassingen worden geanalyseerd en meegewogen.

2.4.2.2 TOOI-Kern

De TOOI-thesaurus-kern is een stelsel van aan elkaar gerelateerde begrippen waarmee we overheidsorganisatie en overheidsinformatie kunnen ordenen en categoriseren. Ook wijzigingen in de TOOI-Kernthesaurus kunnen impact hebben op andere modules die moet worden geanalyseerd en meegewogen.

2.4.2.3 TOOI-Xtrn

De TOOI-thesaurus-xtrn bevat hoofdzakelijk concepten die gemunt zijn in de Authority Tables (AT) van het Publication Office of the EU. De inhoud van de thesaurus wordt vrijwel geheel extern bepaald.

2.4.2.4 TOOI-Top

De TOOI-thesaurus-top, kortweg de TOP-lijst genoemd, is een indeling van beleidsthema's en is vastgesteld door de Redactieraad officiële Publicaties en Basis Wettenbestand. Het is bedoeld als een overkoepelende indeling voor collecties van officiële overheidsinformatie van zowel landelijke als decentrale overheidsorganisaties.

2.4.2.5 TOOI-Wep

De TOOI-thesaurus-wep is opgezet naar aanleiding van de Wet elektronische publicaties (Wep) en bevat concepten die van belang zijn voor het metadateren van bekendmakingen in de officiële publicatiebladen.

2.4.2.6 TOOI-Bwb

De TOOI-thesaurus-bwb bevat concepten die van belang zijn voor het metadateren van geconsolideerde wet- en regelgeving in het Basis wettenbestand (Bwb).

2.4.2.7 TOOI-Registers

De TOOI-registers bevatten authentieke informatie over overheidsorganisaties uit het Register van overheidsorganisaties (Roo).

2.4.2.8 TOOI-waardelijsten

Een TOOI-waardelijst is een selectie van informatie uit andere TOOI-modules. Ze worden gepubliceerd op standaarden.overheid.nl/tooi/waardelijsten/. Registerwaardelijsten bevatten alle informatie uit een TOOI-register (de zogenaamde registerwaardelijstencompleet (rwc)), of een selectie van de informatie die van toepassing is op een bepaalde datum (de zogenaamde registerwaardelijsten op peildatum (rwp)). De inhoud van de registerwaardelijsten wordt geheel bepaald door de inhoud van de registers en dus door de redactie van het Roo.

Conceptwaardelijsten bevatten concepten uit een thesaurus. Conceptwaardelijsten kunnen gebaseerd zijn op een conceptschema (de zogenaamde schemagebaseerde conceptwaardelijsten (scw)) of op een collectie (de zogenaamde collectiegebaseerde conceptwaardelijsten (ccw)). De schemagebaseerde waardelijsten worden geheel bepaald door de conceptschema's en daardoor vastgesteld door de eigenaar van de thesaurus. De collectiegebaseerde conceptwaardelijsten kunnen op aanvraag voor een specifieke toepassing worden opgezet en zijn derhalve eigendom van de toepassing.

Voor een uitgebreide beschrijving van de opzet van de waardelijsten, zie TOOI-waardelijsten.

BOMOS2 - Kwaliteitsbeleid en benchmarken: Belangrijk is om aandacht te hebben voor de kwaliteit van de standaarden door middel van een kwaliteitsbeleid. Dit kan resulteren in bijvoorbeeld het introduceren van een kwaliteitscheck voordat een standaard wordt gepubliceerd. Benchmarken is de activiteit om de eigen activiteiten te spiegelen aan vergelijkbare organisaties om mogelijke verbeteringen te identificeren.

Een verantwoorde informatiehuishouding kent vier pijlers: vindbaarheid, toegankelijkheid, interoperabiliteit en herbruikbaarheid. Deze pijlers zijn uitgewerkt in de FAIR-principes (FAIR is een afkorting van findable, accessible, interoperable, reusable). Zie het Kwaliteitsplan (Bijlage 2) dat de leidraard vormt voor de (door-)ontwikkeling van TOOI en dat volledig gebaseerd is op deze principes.

BOMOS2 - Initiatie: identificatie van nieuwe ideeën (voor bijvoorbeeld een nieuwe specificatie en nieuwe werkgroep) en alle activiteiten die horen bij het succesvol optuigen daarvan (bv. belangenanalyse, business case, agendering).

BOMOS2 - Wensen en eisen: opstellen van de wensen en eisen aan de te ontwikkelen en te beheren specificatie, ook wel bekend onder de naam Maintenance Requests (MRs).

Wijzigingen of nieuwe functionaliteit voor TOOI kan door eenieder worden geïnitieerd door het indienen van issues in een van de TOOI-modules in gitlab, of anoniem via tooi@koop.overheid.nl. De redactie neemt het verzoek in behandeling en houdt de indiener op de hoogte van de voortgang van verwerking. De issues op gitlab worden publiek afgehandeld.

Om te zorgen dat de specificaties van TOOI toepasbaar zijn voor partijen die TOOI gebruiken in hun informatiesystemen, vindt afstemming over de specificaties plaats in het nog te vormen gebruikersoverleg TOOI. In het gebruikersoverleg kunnen wijzigingsverzoeken worden ingediend en/of bij de gebruikers geconsulteerd. Het gebruikersoverleg is toegankelijk voor eenieder. Via een mailinglist blijven de leden van het gebruikersoverleg op de hoogte van de stand van zaken.

BOMOS2 - Ontwikkeling: op conceptueel niveau de inhoudelijke uitwerking van oplossingen voor de ideeën, wensen en eisen opgesteld in voorafgaande fasen. Deze oplossingen zijn zoveel mogelijk los van technologieën bedoeld voor nadere uitwerking in een (nieuwe versie van) de specificatie.

KOOP geeft via GitLab inzicht in de geplande doorontwikkeling van de TOOI-modulen. De ontwikkelagenda is een vertaling van requirements die KOOP ontvangt uit de TOOI-community.

Het wijzigingsbeheer van TOOI is in handen van de TOOI-redactie. De TOOI-redactie werkt wijzigingsverzoeken uit tot wijzigingsvoorstellen die het wijzigingsprotocol doorlopen. De product owner van TOOI (PO-TOOI) beslist, in afstemming met opdrachtgever en eventuele overige stakeholders, over toekenning, afwijzing en prioritering van de wijzigingsverzoeken.

3.2.1 Wijzigingsbeheer

Belanghebbenden kunnen issues aanmelden op de TOOI-modules in gitlab.com/koop/tooi. Elke TOOI-module heeft op gitlab een CONTRIBUTING.md waarin beschreven wordt hoe deze feedback kan worden aangeleverd. KOOP geeft via gitlab inzicht in de ontvangen meldingen en de afhandeling daarvan.

Meldingen worden ingedeeld naar vragen en wijzigingsverzoeken. Vragen worden beantwoord in gitlab en als het een vraag betreft die mogelijk vaker zal voorkomen publiceren we die ook op standaarden.overheid.nl/faq.

Meldingen waarin om een aanpassing van een TOOI-module wordt gevraagd worden erkend als wijzigingsverzoek. Wijzigingsverzoeken beschrijven een probleem, niet hoe dat probleem moet worden opgelost. Dat gebeurt in een wijzigingsvoorstel, op te stellen door de TOOI-redactie. In een wijzigingsvoorstel kunnen meerdere wijzigingsverzoeken worden gebundeld. Wijzigingsvoorstellen worden gekoppeld aan toekomstige versies van de TOOI-module die volgens een ontwikkelagenda per module op gitlab worden geïmplementeerd.

Een wijzigingsvoorstel doorloopt in het wijzigingsproces de fasen Inhoud, Toetsing, Besluitvorming en Implementatie, zoals weergegeven in bovenstaande figuur. Iedere fase kent vaste stappen. De fase Toetsing vormt een brug tussen de inhoud, besluitvorming en de implementatie. In deze fase wordt de inhoudelijke correctheid, de technische haalbaarheid en impact van de voorgestelde wijzigingen getoetst, als de aard van de wijziging dit noodzakelijk maakt. Er is een wezenlijk verschil met besluitvorming. Bij het toetsen wordt de inhoudelijke correctheid vastgesteld, bij besluitvorming de wenselijkheid om de voorgestelde wijzigingen door te voeren. Het resultaat van de fase Toetsing is een (mogelijk aangepast) volledig wijzigingsvoorstel voor de module, dat is gevrijwaard van fouten en waarvan de technische haalbaarheid en impact is getoetst. De stabiliteit en continuïteit van de module maken wij inzichtelijk met de ontwikkelagenda. Hierdoor is voor een ieder inzichtelijk of de module op korte termijn wel of niet wordt gewijzigd.

Op gitlab.com/koop/tooi komt per module een overzicht van de ingediende meldingen, met daarbij per melding de status. Zo is te volgen of een melding onderzocht wordt of meegenomen in het wijzigingsvoorstel. De meldingen worden op basis van onderstaand model via de website voor eenieder beschikbaar gesteld.

Status voorstel	Beschrijving activiteiten
Nieuw	Als een gebruiker een melding indient krijgt deze de status "nieuw".
Triage en terugkoppeling	De actiehouder van de melding controleert of de melding volledig en helder is. Betreft de melding een vraag, dan beantwoordt de actiehouder deze. Is het een geschikte vraag om als FAQ op te nemen, dan voegt de actiehouder deze toe op de FAQ-pagina. Betreft een melding een fout, dan gaat de actiehouder na of dit inderdaad het geval is. Zo ja, dan stelt de actiehouder een wijzigingsverzoek op. Betreft de melding een verzoek om nieuwe of gewijzigde functionaliteit, dan stelt de actiehouder een wijzigingsverzoek op. Wordt de melding door de TOOI-redactie beschouwd als onjuist of onterecht, dan wordt dit toegelicht (aan de melder en op de issuelijst) en wordt de melding gesloten.
In analyse	Deze melding is helder beschreven en is of een wens voor het aanpassen van de module, dan wel een gevonden fout. Ook is de melding geen duplicaat van een reeds ingevoerde melding. Er wordt een wijzigingsverzoek opgesteld en gepubliceerd. KOOP verzamelt alle informatie die nodig is om tot een concreet wijzigingsvoorstel te komen en stelt dat voorstel op. Eventueel worden meerdere wijzigingsverzoeken gecombineerd tot één voorstel. Als het voorstel is geaccepteerd wordt de melding en gekoppeld aan een nieuwe versie van de module.
Besluitvorming	Wijzigings- of correctievoorstel ligt voor ter besluitvorming. Afhankelijk van besluitvorming gaat het voorstel ofwel naar "In uitvoering" ofwel direct naar "Afgesloten"
In uitvoering	Realisatie wordt in gang gezet of opgenomen op de backlog voor latere realisatie.
Afgesloten	De melding wordt afgesloten in de volgende situaties: Wanneer de melding is opgenomen in de nieuwe versie van de module; Wanneer de wens niet wordt gehonoreerd; Wanneer de fout niet meer relevant wordt geacht voor de module.

BOMOS2 - Uitvoeren: de daadwerkelijk aanpassingen op basis van de conceptuele oplossingen doorvoeren in de specificatie en eventuele technische invulling.

Het dagelijks beheer van TOOI wordt uitgevoerd in opdracht van de eigenaren en is in handen van de TOOI-redactie, die is belegd bij het Team Contentmodellering van KOOP. De TOOI-redactie implementeert eenmaal uitgewerkte wijzigingsvoorstellen in de TOOI-specificaties. TOOI-documentatie, de TOOI-ontologie en de eventueel geraakte andere componenten (registers, waardelijsten) worden aangepast en in één release gepubliceerd als samenhangende versie.

Bij de uitvoering wordt het hieronder beschreven versiebeheer toegepast.

BOMOS2 - Documentatie: verzorgen van passende neerslag van de resultaten van het primair beheerproces. Niet alleen de beschikbaarheid van de specificaties, maar bijvoorbeeld ook de mogelijkheid bieden tot een historisch overzicht van verzoeken tot wijzigingen (maintenance requests) en de actuele status daarvan.

De specificaties van TOOI zijn beschikbaar op standaarden.overheid.nl/tooi. De actuele versie van TOOI is prominent aanwezig en eerdere versies van de specificatie in RDF en in natuurlijke taal zijn ook integraal beschikbaar. Feedback op TOOI, wijzigingsverzoeken en toekomstige ontwikkelingen in TOOI zijn te volgen op gitlab.com/koop/tooi.

BOMOS2 - Opleiding: Het bieden van opleidingsmogelijkheden aan verschillende gebruikersgroepen variërend van een informatiebijeenkomst tot aan een (online) cursus.

Er is nog geen ervaring met het toepassen van TOOI buiten KOOP. Als partijen buiten KOOP daarin geïnteresseerd zijn zullen we bepalen welke ondersteuning we kunnen leveren. Voorlopig wordt eerst ervaring met TOOI opgedaan op KOOP-interne toepassingen.

BOMOS2 - Pilot: Proeven met de implementatie van de specificaties. Bij sommige standaardisatieorganisaties is het verplicht dat er 1 of meerdere pilots zijn geweest voordat de standaard officieel vrijgegeven wordt.

TOOI zal geleidelijk worden ingevoerd in de keten voor officiële elektronische publicaties (OEP-keten), die bestaat uit verschillende aanlevermodules voor officiële bekendmakingen, opslag van de publicaties, het raadpleegsysteem, de collecties met geconsolideerde regelgeving en de attenderingsdiensten.

Ook in het Digitaal Stelsel Omgevingswet (DSO) en de Digitale infrastructuur voor de Wet open overheid (DiWoo) worden TOOI-waardelijsten en de TOOI-ontologie toegepast.

Bevindingen uit deze implementaties kunnen leiden tot wijzigingsverzoeken en nieuwe versies van TOOI.

BOMOS2 - Helpdesk: Het bieden van ondersteuning aan verschillende gebruikersgroepen, bijvoorbeeld telefonisch of per e-mail volgens een service level agreement .... Een frequently asked questions kan ook een helpdesk activiteit zijn.

De TOOI-specificatie en -documentatie is te vinden op standaarden.overheid.nl/tooi. Veelgestelde vragen zullen ook daar beantwoord worden. Wie toch nog vragen heeft over TOOI kan deze stellen aan de TOOI-redactie via tooi@koop.overheid.nl.

BOMOS2 - Module-ontwikkeling: (stimuleren van) ontwikkeling van breed te verspreiden softwaremodules die de standaard implementeren. Module-ontwikkeling en Certificatie zijn riskante activiteiten, waarmee er actief ingegrepen wordt in de markt. De uitvoering daarvan dient zorgvuldig te gebeuren en zoveel mogelijk buiten de eigen organisatie.

Er is geen intentie om vanuit de beheerorganisatie van KOOP ontwikkeling te stimuleren van softwaremodules die TOOI implementeren. Naar verwachting zullen leveranciers van software waarmee overheidsinformatie (actief) openbaar gemaakt wordt deze aanpassen op aanlevering aan DiWoo en officiële Elektronische Bekendmaking waar TOOI zal worden gevraagd.

BOMOS2 - Validatie & Certificatie: Het bieden van mogelijkheden bieden om de correctheid van de implementaties te testen (validatie). Daaraan kan een officieel traject verbonden worden wat leidt tot certificatie van een organisatie of product. ...

TOOI is een semantische standaard en schrijft geen serialisatie voor. Daardoor is het ook niet mogelijk om een generieke validator voor TOOI-compliancy te maken. Er zijn ook nog geen plannen voor TOOI-certificering van organisaties of producten.

BOMOS2 - Promotie: Het uitdragen van nut/noodzaak/voordelen van de standaard.

KOOP promoot TOOI door middel van een nieuwsbrief, presentaties, gebruikersbijeenkomsten, etc.

BOMOS2 - Klachtenafhandeling: Het garanderen van het serieus nemen van klachten door deze volgens een zorgvuldige procedure te behandelen.

Klachten over het beheer van TOOI en afhandeling van de wijzigingsverzoeken kunnen worden ingediend via <tooi@koop.overheid.nl.> Deze klachten worden afgehandeld door de TOOI-redactie. Er is nog geen escalatiemogelijkheid.

Door middel van een flexibel sturingsmodel kan de community invloed uitoefenen op deze ontwikkelagenda. De sturing kan per TOOI-module verschillen. De generieke structuur kan als volgt getekend worden:

• Eigenaar van en opdrachtgever voor TOOI (OG TOOI) is de afdeling Basisinfrastructuur van de directie Digitale Overheid onder DG Digitalisering en Overheidsorganisatie (DGDOO/DO/BI). Zij zorgen voor continuïteit en financiering.
• De business owner (BO TOOI KOOP) en product owner contentmodellering (PO TOOI KOOP) zijn verantwoordelijk voor de implementatie en doorontwikkeling van TOOI.
• Team Contentmodellering vormt de redactie van de TOOI-modulen.
• De redactieraad voor OEP en BWB is betrokken bij een aantal TOOI-modulen die worden toegepast in de KOOP-voorzieningen voor officiële elektronische bekendmakingen (OEP) en het Basiswettenbestand (BWB).

TOOI is modulair opgebouwd. Binnen TOOI onderscheiden we vier typen van modules: Ontologieën, Thesauri, Registers en Waardelijsten. Doordat de modules sterk verschillen in soort en inhoud verschilt ook hun beheerproces. Daarom vormt elke module een zelfstandige eenheid van beheer, onderhoud en publicatie. Ook de verantwoordelijkheid voor de inhoudelijke vaststellingkan per module verschillen.

De modules worden beschreven in de paragraaf TOOI-modules in de beschrijving van de architectuur.

Hieronder wordt per module of groep van modulen beschreven hoe we omgaan met wijzigingen en versiebeheer. Met eigenaar bedoelen we de partij die de features en inhoud van de betreffende module vaststelt.

Het TOOI-kwaliteitsbeleid is volldig gebaseerd op de FAIR-principes. Hieronder wordt voor ieder FAIR-principe toegelicht hoe dat in TOOI gestalte krijgt.

F1: (Meta) data are assigned globally unique and persistent identifiers

Principle F1 is arguably the most important because it will be hard to achieve other aspects of FAIR without globally unique and persistent identifiers. Hence, compliance with F1 will already take you a long way towards publishing FAIR data (see 10 ways identifiers can help with data integration). Globally unique and persistent identifiers remove ambiguity in the meaning of your published data by assigning a unique identifier to every element of metadata and every concept/measurement in your dataset. ... Identifiers can help other people understand exactly what you mean, and they allow computers to interpret your data in a meaningful way (i.e., computers that are searching for your data or trying to automatically integrate them). Identifiers are essential to the human-machine interoperation that is key to the vision of Open Science. In addition, identifiers will help others to properly cite your work when reusing your data. ... F1 stipulates two conditions for your identifier:

1. It must be globally unique (i.e., someone else could not reuse/reassign the same identifier without referring to your data). You can obtain globally unique identifiers from a registry service that uses algorithms guaranteeing the uniqueness of newly minted identifiers.
2. It must be persistent. It takes time and money to keep web links active, so links tend to become invalid over time. Registry services guarantee resolvability of that link into the future, at least to some degree.

Het kennismodel van TOOI is geheel vastgelegd in RDF volgens de gangbare specificaties van het W3C voor Linked Data. Alle elementen in het TOOI kennismodel, de klassen, eigenschappen, begrippen, instanties, etc., zijn geïdentificeerd door middel van een http-URI op het domein "https://identifier.overheid.nl". De opbouw van de gemunte URI's is beschreven in de TOOI-documentatie: 1.3 - URI-strategie.

F2: Data are described with rich metadata

In creating FAIR digital resources, metadata can (and should) be generous and extensive, including descriptive information about the context, quality and condition, or characteristics of the data. ... The rationale behind this principle is that someone should be able to find data based on the information provided by their metadata, even without the data's identifier. ...

Alle componenten en elementen in TOOI zijn beschreven met metadata. Deze metadata is in machineleesbare vorm beschikbaar in de RDF datasets waarin de componenten zijn vastgelegd en voor de mens leesbare vorm in de documentatie.

F3: Metadata clearly and explicitly include the identifier of the data they describe

This is a simple and obvious principle, but of critical importance to. The metadata and the dataset they describe are usually separate files. The association between a metadata file and the dataset should be made explicit by mentioning a dataset's globally unique and persistent identifier in the metadata. ...

De metadata bij de TOOI-componenten is opgenomen in de RDF van die componenten, in de vorm van triples die de component zelf als subject hebben. In de documentatie wordt de URI opgenomen van elke component die beschreven wordt.

F4: (Meta)data are registered or indexed in a searchable resource

Identifiers and rich metadata descriptions alone will not ensure 'findability' on the internet. Perfectly good data resources may go unused simply because no one knows they exist. If the availability of a digital resource such as a dataset, service or repository is not known, then nobody (and no machine) can discover it. ...

Alle componenten die beschreven worden met DCAT (zie onder F2) worden aangemeld bij data.overheid.nl.

A1: (Meta)data are retrievable by their identifier using a standardised communication protocol

Most users of the internet retrieve data by 'clicking on a link'. This is a high-level interface to a low-level protocol called tcp, that the computer executes to load data in the user's web browser. ... Principle A1 states that FAIR data retrieval should be mediated without specialised or proprietary tools or communication methods. This principle focuses on how data and metadata can be retrieved from their identifiers.

Alle elementen in TOOI (resources) hebben een http-URI die klikbaar is. De URI-resolver op https://identifier.overheid.nl/ serveert een beschrijving van de resource die door de URI wordt geïdentificeerd in het gewenste formaat, middels content negotiation.

De URI-resolver ondersteunt de volgende formaten:

A1.1: The protocol is open, free and universally implementable

To maximise data reuse, the protocol should be free (no-cost) and open (-sourced) and thus globally implementable to facilitate data retrieval. ...

Alle informatie over TOOI en de volledige specificatie en inhoud is beschikbaar via HTTPS.

A1.2: The protocol allows for an authentication and authorisation where necessary

This is a key, but often misunderstood, element of FAIR. The 'A' in FAIR does not necessarily mean 'open' or 'free'. Rather, it implies that one should provide the exact conditions under which the data are accessible. ...

Alle informatie over TOOI en de volledige specificatie en inhoud is zonder beperking beschikbaar.

A2: Metadata should be accessible even when the data is no longer available

Datasets tend to degrade or disappear over time because there is a cost to maintaining an online presence for data resources. When this happens, links become invalid and users waste time hunting for data that might no longer be there. Storing the metadata generally is much easier and cheaper. Hence, principle A2 states that metadata should persist even when the data are no longer sustained. ...

Eenmaal gemunte TOOI-URIs zijn persistent. Indien een TOOI-resource niet langer ondersteund wordt of overbodig raakt, zal dat door middel van de metadata duidelijk gemaakt worden. De resource blijft tenminste beschreven door een label en een type.

I1: (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation

Humans should be able to exchange and interpret each other's data (so preferably do not use dead languages). But this also applies to computers, meaning that data that should be readable for machines without the need for specialised or ad hoc algorithms, translators, or mappings. Interoperability typically means that each computer system at least has knowledge of the other system's data exchange formats. For this to happen and to ensure automatic findability and interoperability of datasets, it is critical to use (1) commonly used controlled vocabularies, ontologies, thesauri (having resolvable globally unique and persistent identifiers, see F1) and (2) a good data model (a well-defined framework to describe and structure (meta)data).

TOOI wordt gespecificeerd met behulp van de gangbare W3C standaarden voor kennis-representatie. Alle normatieve specificaties zijn vastgelegd in RDF. Het informatiemodel (de TOOI-ontologieën) is uitgedrukt in OWL, de constraints in SHACL. Het begrippenmodel is uitgedrukt in SKOS. De inhoud van de registers (de stamgegevens) is ook RDF en is gemmodelleerd volgens de TOOI-ontologie.

I2: (Meta)data use vocabularies that follow the FAIR principles

The controlled vocabulary used to describe datasets needs to be documented and resolvable using globally unique and persistent identifiers. This documentation needs to be easily findable and accessible by anyone who uses the dataset.

De gebruikte upper ontologies zijn vrijwel allemaal W3C-specificaties en volgen de FAIR principes.

I3: (Meta)data include qualified references to other (meta)data

A qualified reference is a cross-reference that explains its intent. For example, 'X is regulator of Y' is a much more qualified reference than 'X is associated with Y', or 'X see also Y'. The goal therefore is to create as many meaningful links as possible between (meta)data resources to enrich the contextual knowledge about the data, balanced against the time/energy involved in making a good data model. ....

Als een TOOI-component beschikbaar is als RDF-graph waarin een upper-ontology wordt gebruikt, dan wordt deze upper-ontology geïmporteerd, of er wordt een kopie van de definities van de gebruikte resources uit de upper-ontology in de RDF-graph opgenomen. Indien een eigenschap uit een upper-ontology op een duidelijk meer specifieke manier wordt gebruikt dan in de upper-ontology, dan wordt een nieuwe property gedefinieerd als sub-property van de eigenschap uit de upper-ontology.

R1: (Meta)data are richly described with a plurality of accurate and relevant attributes

It will be much easier to find and reuse data if there are many labels are attached to the data. Principle R1 is related to F2, but R1 focuses on the ability of a user (machine or human) to decide if the data is actually USEFUL in a particular context. To make this decision, the data publisher should provide not just metadata...We chose the term ‘plurality’ to indicate that the metadata author should be as generous as possible in providing metadata, even including information that may seem irrelevant.

Alle beschikbare informatie over een TOOI-component wordt in de metadata opgenomen.

R1.1 (Meta)data are released with a clear and accessible data usage license

R1.1 is about legal interoperability. What usage rights do you attach to your data? This should be described clearly. ... The conditions under which the data can be used should be clear to machines and humans.

Zie Rechtenbeleid: TOOI is een volledig open standaard. Hergebruik is toegestaan, mits onder naamsvermelding (BY). Een CC-BY-licentie dus.

R1.2 (Meta)data are associated with detailed provenance

For others to reuse your data, they should know where the data came from (i.e., clear story of origin/history, see R1), who to cite and/or how you wish to be acknowledged. ...

De herkomst van de informatie wordt in TOOI-ontologie uitvoerig gedocumenteerd door middel van een uitvoerige set provenance-eigenschappen.

R1.3: (Meta)data meet domain-relevant community standards

It is easier to reuse data sets if they are similar: same type of data, data organised in a standardised way, well-established and sustainable file formats, documentation (metadata) following a common template and using common vocabulary. If community standards or best practices for data archiving and sharing exist, they should be followed. ... Other community standards may be less formal, but nevertheless, publishing (meta)data in a manner that increases its use(ability) for the community is the primary objective of FAIRness. ...

Zie Relaties met andere standaarden. De TOOI-ontologie maakt gebruik van een aantal upper ontologies:

• OWL;
• Dublin Core;
• PROV-O;
• PAV en
• SKOS.

Bij de definitie van TOOI wordt zoveel mogelijk rekening gehouden met de standaarden MDTO en DCAT. Daar waar mogelijk wordt voor vergelijkbare semantiek in TOOI hetzelfde patroon gekozen als in de genoemde andere standaarden.