Dit document valt onder de volgende licentie:
Creative Commons Attribution 4.0 International Public License
Dit is de definitieve versie van dit document. Wijzigingen naar aanleiding van consultaties zijn doorgevoerd.
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.
Dit beheerplan beschrijft hoe de specificaties van TOOI worden beheerd. Het beschrijft zowel de beheerorganisatie, de beheerprocessen en het 'huishoudelijk reglement'. Het beheerplan TOOI is opgezet volgens de aanwijzingen en structuur van BOMOS.
Dit document maakt deel uit van de familie van TOOI-documenten die gepubliceerd wordt op standaarden.overheid.nl/tooi.
tooiont, de ontologie van overheidsinformatie en overheidsorganisaties conform TOOI tooiwl, de ontologie voor het beschrijven van waardelijsten in termen van specifieke metadata tooikern (algemene concepten) tooixtrn (formats, talen) tooitop (thema-indeling overheidspublicaties) tooiwep (wet elektronische publicaties) tooibwb (taxonomieën basis wettenbestand) Bovenstaande documenten vormen samen de normatieve specificatie van de TOOI-standaard. De TOOI-standaard wordt beheerd zoals beschreven in het niet-normatieve TOOI-beheerplan.
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.
"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.
TOOI is een referentiemodel waarin authentieke informatie over overheidsorganisaties en open overheidsinformatie op een gestructureerde wijze en in machineleesbaar formaat beschikbaar wordt gesteld ten behoeve van samenhang en vindbaarheid van overheidsinformatie uit verschillende informatiecollecties.
TOOI is:
TOOI is ontwikkeld en wordt beheerd door KOOP, het Kennis- en Exploitatiecentrum officiële Overheidspublicaties. KOOP faciliteert overheidsbreed officiële en andere openbare publicaties van overheidsinformatie zoals bedoeld in:
TOOI legt dan ook de focus op overheidsinformatie die in het kader van deze wetten wordt gepubliceerd.
Probleemschets
Bij complexe vraagstukken, zoals bijvoorbeeld de toeslagenaffaire of de stikstofcrisis, hebben juristen, journalisten en belanghebbenden, maar ook overheden zelf, steeds meer behoefte aan samenhangende overheidsinformatie uit verschillende bronnen. Bij gebrek aan uniforme ontsluiting van die informatie is dat echter niet, of slechts tegen hoge kosten mogelijk.
Hierbij doen zich de volgende problemen voor:
Overheidsinformatie die in het kader van de onderstaande regelgeving door de overheid wordt gepubliceerd, moet in verschillende toepassingen in samenhang vindbaar gemaakt worden.
TOOI als oplossing
Een uniform, samenhangend beeld van alle informatie van de hele overheid is alleen mogelijk met een semantische standaard; een gestandaardiseerde taal, waarin zowel voor de mens als voor software eenduidig is vastgelegd welke woorden of codes je gebruikt voor welke dingen en begrippen, een Thesaurus en Ontologie van OverheidsInformatie (TOOI). TOOI is een kennismodel van de organisatie van de hele Nederlandse overheid, zowel de rijksoverheid als de lokale overheden, en de structuur van de officiële, openbare informatie van die overheid. Partijen die metadata nodig hebben om overheidsinformatie te beschrijven kunnen gebruik maken van het model en de bijbehorende referentiegegevens van TOOI.
Een aantal centrale voorzieningen voor de uitvoering van de Woo, de Wep en de Ow worden door KOOP onderhouden en vrijwel elke overheidsorganisatie levert content aan, voorzien van metadata, aan een of meer van deze systemen. Verschillen in (de kwaliteit van) de metadata verlagen de kwaliteit en verhogen de kosten voor het aanbrengen van die samenhang. Om aan de eisen van de Woo te kunnen voldoen moet de uniformiteit en kwaliteit van de gestructureerde informatie over publieke overheidsinformatie zo snel mogelijk verbeterd worden.
KOOP verzorgt de volgende centrale voorzieningen waar alle overheidsorganisaties in Nederland gebruik van maken:
Het kennismodel dat met TOOI wordt opgebouwd bestaat dus uit (waar mogelijk authentieke) informatie die wordt toegepast op een aantal belangrijke centrale voorzieningen in het domein van officiële en openbare overheidsinformatie voor de gehele Nederlandse overheid. Alle overheidsorganisaties hebben wettelijke verplichtingen om informatie via deze centrale voorzieningen aan te leveren en moeten dus al metadata aanleveren die door die voorzieningen worden gevraagd. Door TOOI op de Pas-toe-of-leg-uit-lijst van het Forum Standaardisatie te plaatsen raken het metadatamodel en de referentiegegevens van TOOI overheidsbreed in gebruik, wat ten goede komt aan de interoperabiliteit van overheidsinformatie.
TOOI is modulair opgezet. Er zijn vier soorten modules:
De ontologieën en de thesauri zullen op een zeker moment uitkristalliseren tot een stabiele vocabulaire voor overheidsinformatie. De registers worden op dagelijkse basis actueel gehouden met de werkelijkheid en we zullen naar behoefte nieuwe versies van de waardelijsten publiceren.
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:
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:
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.
TOOI is opgezet met inachtneming van de FAIR-principes. Onder meer indachtig het feit dat er ook in de toekomst voortschrijdend inzicht zal zijn en een van de FAIR-principes - 'meer metadata altijd beter dan minder metadata' - volgend, is TOOI nadrukkelijk als een open model ontwikkeld: er wordt rekening gehouden met doorontwikkeling.
TOOI is [modulair opgebouwd] (https://standaarden.overheid.nl/tooi/doc/tooi-inleiding/#de-opbouw-van-tooi) en bestaat uit verschillende onderdelen. Elk van deze onderdelen vormt een eenheid van beheer, onderhoud en publicatie. Ze kennen onderling afhankelijkheden maar zijn intern sterk coherent. Daarom noemen we een dergelijk onderdeel ook wel module. Binnen TOOI onderscheiden we de volgende modules:
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.
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.
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.
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.
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.
De TOOI-thesaurus-bwb bevat concepten die van belang zijn voor het metadateren van geconsolideerde wet- en regelgeving in het Basis wettenbestand (Bwb).
De TOOI-registers bevatten authentieke informatie over overheidsorganisaties uit het Register van overheidsorganisaties (Roo).
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.
Met het oog op de interoperabiliteit van TOOI met andere standaarden is de principiële keuze gemaakt om de normatieve specificatie van TOOI vast te leggen in RDF en maximaal gebruik te maken van de gangbare W3C-standaarden voor het semantisch web, waaronder RDF(S), OWL, SKOS, PROV-O en SHACL. RDF biedt voor kennisrepresentatie ruime mogelijkheden om verschillende modellen te combineren en dat op 'metaniveau' expliciet te maken op een manier die computers in staat stelt daarop te acteren. De aansluiting op de semantische W3C-standaarden is in onze visie de juiste aanpak om een grote mate van interoperabiliteit met andere semantische standaarden te bereiken. De keuze voor RDF is bovendien de beste manier om invulling te geven aan FAIR-principe I1:
"(Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation."
De TOOI-ontologie maakt gebruik van een aantal upper ontologies:
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.
De inhoud van de TOOI-thesauri en de TOOI-registers is beschikbaar in de vorm van waardelijsten in gangbare RDF-formaten (TTL, XML/RDF, JSON-LD) en in een specifiek XML-formaat.
TOOI is een levende standaard die uit de aard der zaak voortdurend evolueert. Wijzigingen zijn nodig om de inhoud van TOOI synchroon te houden met de voortdurend veranderende werkelijkheid en om te voldoen aan voortschrijdend inzicht en de behoefte aan nieuwe functionaliteit bij partijen die TOOI willen toepassen. Die voortdurende behoefte aan wijzigingen kan op gespannen voet staan met de behoefte aan persistentie die nodig is voor interoperabiliteit van applicaties die TOOI gebruiken. De oplossing hiervoor is het hanteren van een zorgvuldig wijzigingsproces en transparant versiebeheer op alle TOOI-modules. Van elke module kunnen nieuwe versies worden uitgebracht. Elke uitgebrachte versie is persistent, dus is onveranderlijk beschikbaar, zolang TOOI wordt ondersteund. Op dit moment wordt alleen de laatste versie van de TOOI-specificaties gepubliceerd. KOOP is bezig met de inrichting van een versiebeheersysteem waarin ook historische versies en ontwikkelversies beschikbaar zijn. Ook komt er een ontwikkelagenda waarin toekomstige versies van TOOI-modules zullen worden ingepland, zodat eenieder inzicht heeft in welke functionaliteit voorzien wordt in toekomstige versies.
TOOI wordt agile en op iteratieve wijze ontwikkeld volgens de SAFe-methodiek. Op basis van de behoefte van de community wordt de specificatie van TOOI voortdurend uitgebreid en verbeterd. Deze wijzigingen worden als nieuwe versies van TOOI gepubliceerd. De eerste versie van TOOI die met het publiek gedeeld is, is TOOI versie 1.0.
De versionering van TOOI volgt de principes van semantic versioning (versie 2.0.0). Uitbreidingen van TOOI die backward compatible zijn met eerder gepubliceerde versies krijgen een minor release na de punt (bijvoorbeeld TOOI versie 1.1). Er zijn maximaal twee minor releases per kalenderjaar. Bugfixes kunnen vaker voorkomen. Deze krijgen een sub-nummer (bijv TOOI versie 1.1.1). Wijzigingen in de TOOI-specificatie die niet backward compatible zijn met eerder uitgebrachte versies krijgen een major versienummer (bijvoorbeeld TOOI versie 2.0).
Eenmaal gepubliceerde versies blijven gepubliceerd. Een versie wordt maximaal 2 jaar onderhouden en er zijn maximaal 3 versies in onderhoud. In onderhoud wil zeggen dat op een versie bugfixes kunnen worden gepubliceerd.
Het hoofdstuk Versiebeheer geeft een uitgebreidere beschrijving van de werkwijze.
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.
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.
De versionering van TOOI-modules volgt de principes van semantic versioning (versie 2.0.0). We beschrijven hier de algemene werkwijze voor alle TOOI-modules. Per module kunnen er specifieke afwijkingen zijn, bijvoorbeeld in het toetsingsproces of de partijen die betrokken zijn bij de besluitvorming.
Volgens de principes van semantic versioning bestaat de aanduiding van een versie van een module uit drie versieaanduidingen, gescheiden door een punt: MAJOR.MINOR.PATCH.
Proces voor MAJOR (X) en MINOR (Y) wijzigingen
Deze vergen volledige afstemming en het doorlopen van alle fasen: Inhoud, Toetsing, Besluitvorming en Implementatie. Indien nodig kan voor de inhoudelijke fase een werkgroep worden gestart met daarin vertegenwoordiging van belangrijke stakeholders.
Proces voor PATCH (Z) wijzigingen
Deze dienen zo snel als mogelijk uitgevoerd te worden. De inhoudelijke fase wordt door een medewerker van KOOP gedaan. Toetsing vindt plaats d.m.v. een (beperkte) consultatie met stakeholders. Besluitvorming vindt plaats door het Team Contentmodellering van KOOP. Implementatie vindt plaats door het publiceren van de wijziging (met toelichting) op gitlab.
Alle vastgestelde versies van een module blijven beschikbaar op standaarden.overheid.nl/tooi. Een nieuwe versie dwingt daarmee geen directe overstap af bij de gebruikers, tenzij anders (bijvoorbeeld wettelijk) bepaald.
Voor het onderhoud en de ondersteuning van een vastgestelde versie van een module gelden de volgende uitgangspunten:
De opdrachtgever TOOI stelt in overleg met de gebruikersraad vast hoe lang een oude versie wordt ondersteund en wanneer hij komt te vervallen (obsolete wordt). Dit betekent dat vragen over het gebruik van de niet-actuele module worden beantwoord (helpdesk). De maximale ondersteuningstermijn voor niet-actuele modules is twee jaar, tenzij de opdrachtgever anders bepaalt. Daarna blijft de versie van de module wel beschikbaar, maar biedt KOOP geen ondersteuning meer. Bij modules die niet meer worden ondersteund, wordt duidelijk vermeld of zichtbaar gemaakt dat deze zijn vervallen.
In het algemeen zal de opdrachtgever alleen besluiten om een versie te laten vervallen en de ondersteuning te staken, als het de verwachting en/of de intentie is dat gebruikers alleen nog actief de nieuwe versie toepassen en daarbij ondersteuning behoeven.
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 - Publicatie: Het vindbaar/kenbaar maken van de standaard en de actuele stand van zaken, bij voorkeur op Internet.
Op standaarden.overheid.nl/tooi worden de specificaties van TOOI gepubliceerd. Via dat kanaal wordt ook nieuws en de actuele stand van zaken over TOOI kenbaar gemaakt.
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:
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.
| Module | TOOI-Ontologie en TOOI-Waardelijstontologie |
|---|---|
| Eigenaar | Opdrachtgever TOOI |
| Soort wijzigingen | Modelwijzigingen |
| Impact | Potentieel grote impact, ook op andere modulen en op toepassingen. Moet door alle stakeholders van TOOI worden beoordeeld d.m.v. publieke consultatie. |
| Frequentie | Maximeren op bijvoorbeeld 2 keer per jaar |
| Beheerproces | Huidige praktijk: Inhoudelijke voorbereiding door TOOI-redactie → Publicatie → release-versie (zonder '-rc'). Toekomst: Inhoudelijke voorbereiding door TOOI-redactie → Publieke toetsing/consultatie 'rc'-release → Goedkeuring besluitvormend orgaan → Publicatie release-versie (zonder '-rc'). ('rc'= release candidate). |
| Versionering | - Major en minor versie: Na goedkeuring door het besluitvormend orgaan volgt een nieuwe versie. - Patch versie: consultatie en goedkeuring niet nodig. |
| Module | TOOI-thesaurus voor kernbegrippen |
|---|---|
| Eigenaar | Opdrachtgever TOOI |
| Soort wijzigingen | Begripsdefinities. Nieuwe concept-schema's |
| Impact | Impact op gebruikers van de geraakte waardelijsten. Mogelijk impact op andere modules. |
| Frequentie | Verschilt per schema. |
| Beheerproces | Maatwerkoverleg met belanghebbenden door de TOOI-redactie → Publicatie |
| Versionering | Wijzigingen kunnen met spoed nodig zijn. Deze kunnen worden gepubliceerd als waardelijst. Er hoeft niet voor elke wijziging een nieuwe versie van tooikern te worden vastgesteld. Wel is het goed om periodiek een versie van tooikern vast te stellen, zodat partijen ijkpunten hebben. Deze werkwijze heeft consequenties voor het resolven van URIs die uitgegeven worden in een waardelijst, maar nog niet geconsolideerd zijn in een nieuwe versie van tooikern. |
| Module | TOOI-thesaurus voor TOOI-externe begrippen |
|---|---|
| Eigenaar | Opdrachtgever TOOI |
| Soort wijzigingen | Volgt thesauri die elders gedefinieerd zijn. |
| Impact | Zelden impact. Betreft doorgaans enkel (kleine) uitbreidingen. |
| Frequentie | Minder dan 1 x per jaar |
| Beheerproces | Maatwerk |
| Versionering | Aangezien de wijzigingsfrequentie zeer laag is kan bij elke wijziging een nieuwe versie van de thesaurus worden vastgesteld en gepubliceerd. |
| Vaststelling | De selectie van de concepten in TOOI-Xtrn die worden overgenomen uit de AT-EU wordt bepaald door de OG TOOI. |
| Module | TOOI-thesaurus voor de TOP-lijst |
|---|---|
| Eigenaar | Redactieraad OP/BWB |
| Soort wijzigingen | Wijziging van de thema-indeling |
| Impact | Aanzienlijke impact bij toepassers, met name wanneer thema's worden opgeheven |
| Frequentie | Gemaximeerd op 2 x per jaar, in de praktijk minder dan 1x per jaar |
| Beheerproces | Inhoudelijke voorbereiding door TOOI-redactie en werkgroep TOP-lijst van de redactieraad OP/BWB → besluitvorming door de redactieraad OP/BWB → Publicatie |
| Versionering | Aangezien de wijzigingsfrequentie zeer laag is kan bij elke wijziging een nieuwe versie van de thesaurus worden vastgesteld en gepubliceerd. |
| Module | TOOI-thesaurus voor de Wep |
|---|---|
| Eigenaar | Opdrachtgever Wep bij KOOP |
| Soort wijzigingen | Wijziging van concepten ihkv de Wep, waaronder de rubrieksindeling |
| Impact | Potentieel grote impact in de KOOP-keten, moet door alle stakeholders worden beoordeeld. |
| Frequentie | Maximeren op bijvoorbeeld 2 keer per jaar |
| Beheerproces | Inhoudelijke voorbereiding door TOOI-redactie → Publieke consultatie → Goedkeuring besluitvormend orgaan → Publicatie |
| Versionering | Aangezien de wijzigingsfrequentie zeer laag is kan bij elke wijziging een nieuwe versie van de thesaurus worden vastgesteld en gepubliceerd. |
| Module | TOOI-thesaurus voor Bwb |
|---|---|
| Eigenaar | Opdrachtgever Bwb bij KOOP |
| Soort wijzigingen | Wijziging van concepten ihkv BWB, waaronder de themaindeling verdragen |
| Impact | BWB en STOP(voor Rijksregelgeving) |
| Frequentie | Maximeren op bijvoorbeeld 2 x per jaar, in de praktijk minder dan 1x per jaar |
| Beheerproces | Maatwerkoverleg met belanghebbenden door de TOOI-redactie → Publicatie |
| Versionering | Aangezien de wijzigingsfrequentie zeer laag is kan bij elke wijziging een nieuwe versie van de thesaurus worden vastgesteld en gepubliceerd. |
| Module | Registers |
|---|---|
| Eigenaar | Opdrachtgever Register voor Overheidsorganisaties |
| Soort wijzigingen | Herindelingen en wijzigingen van beschrijvende eigenschappen |
| Impact | Existentiële wijzigingen, zoals bijvoorbeeld herindelingen van gemeenten en ministeries, hebben potentieel veel impact omdat daarbij organisaties ontstaan of worden opgeheven. Toestandswijzigingen, zoals naamswijzigingen, hebben doorgaans minder impact. |
| Frequentie | Herindelingen zijn goed voorspelbaar, de andere wijzigingen niet. |
| Beheerproces | ROO is leidend en bepaalt. Dus direct publicatie, zonder publieke consultatie. |
| Versionering | De inhoud van de registers reflecteert de wijzigingen in ROO en kan dus voortdurend wijzigen en wordt daarom niet geversioneerd. Eventueel zouden dagelijkse exports gemaakt en gepubliceerd kunnen worden en als statische versies te beschouwen, zoals ook bij ROO al het geval is. |
| Module | Registerwaardelijsten |
|---|---|
| Eigenaar | Opdrachtgever TOOI |
| Soort wijzigingen | Volgt de registers, dus de inhoud wordt geheel bepaald door de redactie van het Roo. |
| Impact | idem als de registers |
| Frequentie | Publicatie inplannen. Gemeenten: twee maanden voor herindeling; ministeries: zsm na formatie en kabinetsbesluit over portefeuilleverdeling; andere registers: naar behoefte |
| Beheerproces | idem als registers |
| Versionering | Registerwaardelijsten worden gewijzigd als er sprake is van existentiële wijzigingen in het register. Die leiden immers potentieel tot nieuwe inhoud van de waardelijsten. Waardelijsten hebben nog geen semantic versioning. Op dit moment wordt onderzocht of het mogelijk is om dat wel te gaan doen. |
| Module | Schemagebaseerde Conceptwaardelijsten |
|---|---|
| Eigenaar | Opdrachtgever TOOI |
| Soort wijzigingen | idem als betreffende thesaurus (inhoud wordt vastgesteld door de eigenaar van de thesaurus). |
| Impact | idem als betreffende thesaurus |
| Frequentie | idem als betreffende thesaurus |
| Beheerproces | idem als betreffende thesaurus |
| Versionering | Nieuwe versies van de waardelijst kunnen met spoed nodig zijn en kunnen worden uitgegeven zonder dat een nieuwe versie van de thesaurus hoeft te worden vastgesteld. Waardelijsten hebben nog geen semantic versioning. Op dit moment wordt onderzocht of het mogelijk is om dat wel te gaan doen. |
| Module | Collectiegebaseerde conceptwaardelijsten |
|---|---|
| Eigenaar | Verschilt per waardelijst: worden op aanvraag voor een specifieke toepassing worden opgezet en zijn derhalve eigendom van de toepassing. |
| Soort wijzigingen | Wijzigingen in schema met automatische gevolgen voor conceptwaardelijst. Wijzigingen in specificatie van de conceptwaardelijst ingegeven door behoeften van ontvangende systemen. |
| Impact | idem als betreffende thesaurus |
| Frequentie | idem als betreffende thesaurus |
| Beheerproces | idem als betreffende thesaurus |
| Versionering | Nieuwe versies van de waardelijst kunnen met spoed nodig zijn en kunnen worden uitgegeven zonder dat een nieuwe versie van de thesaurus hoeft te worden vastgesteld. Met persistente versies kunnen ontvangende systemen desgewenst een oudere versie blijven gebruiken. Waardelijsten hebben nog geen semantic versioning. Op dit moment wordt onderzocht of het mogelijk is om dat wel te gaan doen. LET OP: Technisch zijn de definities van de collecties, op basis waarvan de collectiegebaseerde waardelijsten worden gegenereerd, onderdeel van de thesaurus waaruit de concepten worden gekozen. Dus de collectiegebaseerde conceptwaardelijsten kunnen ook deelcollecties bevatten die eigendom zijn van een andere eigenaar dan de opdrachtgever voor de betreffende TOOI-thesaurus. |
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:
- 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.
- 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:
| Formaat | Media type | Opmerking |
|---|---|---|
| HTML | [text/html] | Het default responseformaat is HTML, gericht op de menselijke lezer. De meeste URIs zijn voorkomen in de TOOI waardelijsten en de meeste gebruikers zullen TOOI kennen van de waardelijsten. Deze URIs worden doorgezet naar Tardis. |
| RDF/XML | application/rdf+xml | |
| JSON | application/json | |
| Turtle | [text/turtle] | In ontwikkeling |
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.
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:
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.