Repository navigation
Federatief stelsel met gecentraliseerde componenten/functies #46
Description
Als er gewerkt wordt aan een federatief stelsel van overheidsdata, maar ook van autorisaties en logging t.b.v. traceerbaarheid is een afbeelding en toelichting waarom gecentraliseerde componenten in een dergelijk stelsel noodzakelijk zijn.
Neem bijvoorbeeld het toestemmingenregister en portaal of het ASI-component.
Daarmee zou GBO als data-aanbieder (data provider) gepositioneerd kunnen worden met de verantwoordelijkheid over de dataset (beschrijving, juistheid, volledigheid en tijdigheid). Hierbij zou m.i. de verantwoordelijkheid bij de 'echte' data eigenaar behouden blijven.
Dit is mijns inziens nog onvoldoende toegelicht in het huidige stuk.
Het wordt anders als gesteld wordt dat data aanbieders gebruik kunnen maken van referentiecomponenten die vanuit het project worden ontwikkeld en beschikbaar worden gesteld. Dan heeft GBO de verantwoordelijkheid voor de ontwikkeling hiervan en het beleggen bij een te bepalen beheerorganisatie.
Als dit echter wel wordt bedoeld dan zou ik het zo ook opschrijven zodat het voor iedereen duidelijk is en voorkomt een mismatch in verantwoordelijkheid.
Als dit niet zo wordt bedoeld dan wordt er vanuit het project gewerkt aan een oplossing waarmee GBO een data aanbieder is en heb je de verantwoordelijkheid voor:
- Datakwaliteit
- Dataset
- Het kunnen terugmelden op de dataset en datakwaliteit
- Het verstrekken van metadata
- Etc.
Activity
Govert-Claus commentedon Sep 2, 2026
Het idee van GBO is dat de data eigenaar altijd de verantwoordelijke blijft voor datakwaliteit, dataset, etc. van de gegevens die hij aanbiedt. Voor de ontsluiting schrijft GBO richtlijnen en standaarden voor en biedt GBO een referentie implementatie, maar de kwaliteit, inhoud, metadatering, etc. van de gegevens die daar aangeboden worden blijven de verantwoordelijkheid van de bronhouder.
Voor efficiency en kostenbesparing biedt GBO verder een aantal centrale voorzieningen om het de data eigenaar makkelijker te maken. De data eigenaar hoeft die componenten niet te gebruiken. Als hij dat wel doet blijft hij verantwoordelijk voor de gegevens en alle aspecten die daaraan verbonden zijn. Alleen de "infrastructurele" aspecten van de centrale component (beschikbaarheid, vindbaarheid, performance) komen bij de beheerder van de voorziening (in eerste instantie GBO) te liggen.
Enige component die hier van afwijkt is de toestemmingsvoorziening. Daar stelt GBO een centrale voorziening voor die private dienstverleners moeten gebruiken om gegevens van overheidsbronnen te bevragen. Dat wordt voorgesteld om het voor de burger eenvoudiger en duidelijker te maken: die heeft dan met 1 interface te maken in plaats van een interface voor iedere bron. En ook de private dienstverlener hoeft hiermee geen koppelingen te maken met diverse toestemmingsvoorzieningen.
Voor deze voorziening zal de beheerder van de voorziening (in eerste instantie GBO) inderdaad verantwoordelijk zijn voor alle gegevens die de toestemming nodig heeft.
Ik probeer dit wat duidelijker in het ontwerp te beschrijven.
Govert-Claus commentedon Oct 20, 2026
Verwerkt in v0.9.5, o.a. met het "decentrale configuratiecomponent" en vermelding dat bronhouder verantwoordelijk blijft voor ontsluiting van gegevens en de kwaliteit hiervan.