<p>In dit deel van de architectuur wordt een verdieping gegeven aan het thema metagegevens. Het start met een korte inleiding van het onderwerp en een overzicht van de belangrijkste objecten en de standaarden die daarbij van toepassing zijn. Vervolgens gaat het dieper in op specifieke vormen van metagegevens die extra aandacht vragen in de context van gegevensuitwisseling: modellen, metagegevens over gegevenskwaliteit, voorwaarden, overeenkomsten en de herkomst van gegevens.</p> <h3>Inleiding</h3> <p>Metagegevens zijn gegevens over gegevens en helpen je om bepaalde aspecten van de gegevens beter te begrijpen. Praktisch gezien kun je metagegevens zien als bijsluiter bij gegevens. Het onderscheid tussen gegevens en metagegevens is niet altijd zwart-wit; het is afhankelijk van de context en de rol die de gegevens spelen. Zo kunnen bijvoorbeeld gegevens over een persoon gebruikt worden om aan te geven wie de auteur is van een informatie-object en daarmee worden ze metagegevens. Er zijn allerlei vormen van metagegevens. De DAMA Data Management Body of Knowlegde (DMBoK) maakt onderscheid tussen business metagegevens, technische metagegevens en operationele metagegevens. Business metagegevens zijn bijvoorbeeld begrippen, bedrijfsregels, informatie- en gegevensmodellen, kwaliteitsregels, datasetdefinities en gegevens over de herkomst van gegevens. Technische metagegevens zijn bijvoorbeeld technische gegevensmodellen, gegevens over databases, bestandsformaten en ETL scripts. Operationele metagegevens zijn bijvoorbeeld audit- en errorlogs, omvang- en gebruiksgegevens en uitwisselafspraken. Dit onderscheid wordt vooral gebruikt in de context van gestructureerde gegevens. In de context van archivering wordt ook wel het onderscheid gemaakt tussen beschrijvende metagegevens, structurele metagegevens en administratieve metagegevens. Er is eerder door een NORA werkgroep een <a href="https://www.noraonline.nl/wiki/Visie_metadatamanagement">visie op metagegevens</a> opgesteld waarin meer algemene informatie over het onderwerp te lezen is. Onderdeel daarvan is ook een volwassenheidsmodel voor het omgaan met metagegevens.</p> <p>In de context van gegevensuitwisseling is vooral interessant welke metagegevens worden uitgewisseld met andere organisaties. Daarbij spelen standaarden een cruciale rol. Ze zorgen ervoor dat afnemers eenvoudiger kunnen begrijpen welke gegevens het betreft. Er is een grote diversiteit aan standaarden die iets zeggen over metagegevens. De volgende figuur geeft een overzicht van gangbare standaarden, geplot op het <a href="https://minbzk.github.io/gdi-gegevensuitwisseling/?view=id-efc531031d114860a309f6eeacdad289">bedrijfsobjectenmodel</a>. Het geeft aan welke standaarden, voor het beschrijven van welke soort metagegevens relevant zijn. Per standaard is met een kleur aangegeven of deze door Forum Standaardisatie verplicht of aanbevolen is, of dat deze in deze architectuur wordt aanbevolen. De figuur maakt direct het belang van metagegevens in de context van gegevensuitwisseling duidelijk. Er is een grote diversiteit aan soorten metagegevens en standaarden belangrijk om ervoor te zorgen dat gegevensuitwisseling op een goede manier kan verlopen. Om dit goed te laten werken zijn ook de relaties tussen deze standaarden belangrijk. Op het eerste gezicht lijkt het alsof er wel erg veel standaarden zijn, maar veel van deze standaarden zijn complementair of hebben een duidelijk eigen bestaansrecht en toepassingsgebied. Op hoofdlijnen is het bedrijfsobjectenmodel een metadatamodel en het kan door organisaties ook als startpunt voor een eigen metadatamodel dienen. Een dergelijk model is belangrijk bij het inrichten van het beheer van metagegevens.</p> <p><img src="https://minbzk.github.io/gdi-gegevensuitwisseling/images/metadatastandaarden.svg"></p> <p> <h3>Begrippen, informatie- en gegevensmodellen</h3> <p> Als het gaat over de uitwisseling van gestructureerde gegevens, dan is het belangrijk om met modellen duidelijk te maken wat de betekenis en structuur van deze gegevens is. Er zijn allerlei modellen die daarbij relevant zijn. Er is een onderscheid tussen modellen die het (probleem)domein beschrijven en modellen die het oplossingsdomein beschrijven. De modellen voor het probleemdomein zijn primair analysemodellen. Ze zijn een representatie van het domein zelf, zonder dat de modelleur hier een ontwerpkeuze bij maakt. Ze hebben tot doel om het domein goed te begrijpen zodat misinterpretaties worden voorkomen. Door het opstellen van dit soort modellen wordt kennis over het domein vastgelegd, wat een belangrijke basis is voor automatisering. Modellen voor de oplossingsruimte zijn primair bedoeld als ontwerp. Ze zijn bijvoorbeeld nodig om te specificeren welke gegevens gegevensdiensten moeten leveren.</p> <p>Een begrippenkader beschrijft de betekenis van termen en is de basis om ervoor te zorgen dat mensen elkaar begrijpen. Een conceptueel model is een formele beschrijving van een (probleem)domein, los van hoe dat in gegevens wordt vastgelegd. Logische modellen leggen de nadruk op het gebruik van gegevens in informatiesystemen door het structureren van gegevens. Fysieke (technische) modellen leggen de nadruk op de vertaling naar implementatie. De Nederlandse Standaard voor het Beschrijven van Begrippen (NL-SBB) biedt een standaard taal, structuur en set aan metagegevens voor begrippenkaders, gebaseerd op de SKOS standaard. Het Metamodel Informatie Modellering (MIM) biedt een standaard taal, structuur en set aan metagegevens voor informatie- en logische gegevensmodellen. Hierdoor zijn ze meer gestandaardiseerd en kunnen ze eenvoudiger worden begrepen en uitgewisseld. Het beschrijft ook hoe ze in UML, XML en als Linked Data gerepresenteerd kunnen worden. Het is ook mogelijk om informatie- en logische gegevensmodellen direct conform Linked Data standaarden zoals RDFS, OWL en SHACL vast te leggen.</p> <p>Door de community die hoort bij de MIM standaard is gewerkt aan een <a href="https://www.mim-community.nl/index.php/Manifest_voor_het_belang_van_De_Kunde_van_Kennisrepresentatie_voor_Informatiediensten">manifest</a> dat het belang van kennisrepresentatie onder de aandacht brengt. Onderdeel daarvan is ook een uitwerking van de soorten modellen die daarbij relevant zijn en die is weergegeven in de volgende tabel. De overtuiging die ten grondslag ligt aan het manifest is dat de kunde van kennisrepresentatie een noodzakelijke voorwaarde is om te komen tot goede informatiediensten. Het beschrijft onder meer het belang van een expliciet begrip van het domein en de daarin gebruikte taal en geeft aan dat een gezamenlijk begrip alleen tot stand kan komen via een gestructureerde dialoog. Het manifest is bedoeld om richting te geven aan de doorontwikkeling van de MIM standaard, omdat de huidige versie van de standaard het onderscheid tussen het conceptuele en logische niveau niet duidelijk uitwerkt. Merk op dat de werkgroep en het resultaat geen formele status hebben en de informatie slechts ter inspiratie in dit document is opgenomen. </p> <p> <table class="table table-striped"> <tr><td valign="top"></td><td valign="top"><b>Beschouwingsniveau I</b></td><td valign="top"><b>Beschouwingsniveau II</b></td><td valign="top"><b>Beschouwingsniveau III</b></td><td valign="top"><b>beschouwingsniveau IV</b></td></tr> <tr><td valign="top"><b>Naam</b></td><td valign="top">Semantisch</td><td valign="top">Conceptueel</td><td valign="top">Logisch</td><td valign="top">Implementatie</td></tr> <tr><td valign="top"><b>Doel</b></td><td valign="top">Analyseren</td><td valign="top">Analyseren</td><td valign="top">Ontwerpen</td><td valign="top">Ontwerpen</td></tr> <tr><td valign="top"><b>Functie</b></td><td valign="top">Elkaar begrijpen</td><td valign="top">Begrip van het domein expliciteren</td><td valign="top">Gegevensgebruik specificeren</td><td valign="top">Gegevensgebruik realiseren</td></tr> <tr><td valign="top"><b>Voorbeeldtermen</b></td><td valign="top">Begrippenmodel, Begrippenkader, Conceptmodel, Thesaurus, Taxonomie, Business glossary</td><td valign="top">Conceptueel informatiemodel, Ontologie, Kennismodel, Bedrijfsobjectenmodel, Domeinmodel</td><td valign="top">Logisch gegevensmodel, Logisch informatiemodel, Logisch datamodel</td><td valign="top">Technisch gegevensmodel, Technisch datamodel, Fysiek datamodel, Schema</td></tr> <tr><td valign="top"><b>Doelgroep</b></td><td valign="top">Iedereen</td><td valign="top">Expertgebruikers van informatiediensten</td><td valign="top">Ontwerpers van informatiediensten</td><td valign="top">Ontwikkelaars van informatiediensten</td></tr> <tr><td valign="top"><b>Modelleertalen</b></td><td valign="top">SKOS, SBVR</td><td valign="top">OWL, RDFS, UML (OO), OntoUML, ORM, CogNIAM, FCO-IM, ERD (conceptueel), ArchiMate</td><td valign="top">SHACL, UML (OO), ERD (logisch)</td><td valign="top">SQL DDL, JSON Schema, XML Schema, ER (fysiek/implementatie), programmeertaal</td></tr> <tr><td valign="top"><b>Inhoud</b></td><td valign="top"><ul><li>Begrippen die worden gebruikt en herkenbaar zijn in het domein</li><li>Definities en toelichtingen van de termen die worden gebruikt voor de begrippen</li><li>Synoniemen/homoniemen en alternatieve schrijfwijzen van de begrippen zoals afkortingen</li><li>Relatie naar wet- en regelgeving en beleid</li>Hiërarchische en associatieve relaties tussen de begrippen</li><li>Classificaties van de begrippen</li><li>Regels over het domein in natuurlijke taal in termen van de begrippen (bedrijfsregels)</li></ul></td><td valign="top"><ul><li>Een formalisatie van dingen die bestaan in het domein</li><li>Feiten en uitspraken over de dingen in het domein</li><li>Eigenschappen van de dingen in het domein</li><li>Eigenschappen die (mogelijk in combinatie) dingen uniek identificeren</li><li>Naamgeving gericht op exactheid</li><li>Formele definities van de dingen en hun eigenschappen</li><li>Mogelijke waarden van eigenschappen</li><li>Exacte relaties tussen de dingen</li><li>Regels over de dingen en hun eigenschappen in een formele taal</li><li>Verbalisaties over eigenschappen van dingen</li></ul></td><td valign="top"><ul><li>Een representatie van dingen in het domein als gegevens</li><li>Clusters van gegevens die relevant zijn vanuit logistiek perspectief</li><li>Individuele data-elementen binnen de gegevensclusters</li><li>Identificaties van gegevensclusters, die geen identificatie op conceptueel niveau kennen</li><li>Naamgeving gericht op gebruik in ontwerpen (bijv. CamelCase)</li><li>Datatypes van de gegevens</li><li>Relaties tussen de gegevens</li><li>Regels over de gegevens en hun onderlinge relatie, mede op basis van kennis over hoe ze tot stand komen en worden gebruikt</li><li>Vastlegging van historie van gegevens</li><li>Vastlegging van gegevens t.b.v. herleidbaarheid en auditlogging</li></ul></td><td valign="top"><ul><li>Technologie-specifieke representatie van gegevens als data</li><li>Technologie-specifieke datatypen</li><li>Technologie-specifieke naamgeving van gegevens</li><li>Technologie-specifieke representatie van identificaties (bijv. als URI’s)</li></ul></td></tr> </table> </p> <p> Het opstellen van dit soort modellen is essentieel om op een professionele manier met gegevens om te gaan en is daarmee ook een basis voor gegevensuitwisseling. Het zorgt ervoor dat expliciet wordt geredeneerd vanuit begrippen. Deze begrippen worden deels beschreven in wet- en regelgeving, en vormen de basis voor de inrichting van informatievoorziening. Middels <a href="https://regels.overheid.nl/publicaties/wetsanalyse">wetsanalyse</a> kunnen de juridische kwalificaties van formuleringen in wet- en regelgeving geannoteerd worden. Dezelfde aanpak kan ook worden gebruikt voor het analyseren van beleidsteksten, procesdocumenten en instructies. Dit is de basis voor het definiëren van begrippen en bedrijfsregels, die niet in de teksten zelf expliciet zijn gedocumenteerd. Dit maakt vooral kennis expliciet en verkleint de kans op interpretatieverschillen. Een verdere uitwerking daarvan in meer formele conceptuele modellen zorgt ervoor dat er duidelijkheid is over de dingen en eigenschappen die onderdeel zijn van het domein. Een conceptueel model zegt strikt genomen nog niets over hoe gegevens eruit zien, beschrijft alleen het (probleem)domein. </p> <p>Op het moment dat de informatievoorziening wordt ingericht, moet worden nagedacht over de structuren die nodig zijn bij het opslaan, uitwisselen en gebruiken van gegevens. Er moet ook worden nagedacht over de eenheden waarin gegevens worden verwerkt (de groeperingen van gegevens die als geheel worden uitgewisseld). Als de eenheden te groot of te klein zijn dan ontstaan er mogelijk performanceproblemen bij het gebruik van een informatiesysteem of gegevensdiensten. Als de eenheden verkeerd worden gekozen dan wordt mogelijk onvoldoende invulling gegeven aan de informatiebehoefte van gebruikers, of sluiten ze mogelijk onvoldoende aan bij mogelijke wijzigingen in de toekomst. Bij deze structuur horen ook regels die aangeven welke beperkingen worden gesteld aan de gegevens en regels die aangeven hoe bepaalde soorten gegevens kunnen worden afgeleid van andere gegevens. Deze aspecten worden beschreven in logische modellen, waarvan er meerdere soorten bestaan. Zo zal er een logisch model nodig zijn voor het inrichten van de database waarin de gegevens worden opgeslagen, van de berichten of bestanden die worden uitgewisseld en van de informatieproducten die aan gebruikers worden verstrekt.</p> <p>Uiteindelijk moeten deze modellen vertaald worden naar technische gegevensmodellen en schema's die bepalen hoe de gegevens in een bepaalde technologie worden gerepresenteerd. Dat gaat bijvoorbeeld over het formaat van de gegevens, over de precieze datatypes die gebruikt worden en over de technische implementatie van de regels. Schema's worden bijvoorbeeld gebruikt om een validatie uit te voeren, zodat gegevens een bepaalde basiskwaliteit bezitten.</p> <p>In deze hele keten van modellen is het streven om te zorgen voor traceerbaarheid. Dat zorgt ervoor dat van individuele gegevens duidelijk is aan welk schema ze voldoen, welke structuur wordt gehanteerd, wat de gegevens precies betekenen en hoe dat zich verhoudt tot de woorden die worden gebruikt. Dit heet ook wel "verticale data lineage". Het vraagt dat elementen in modellen verwijzen naar elementen in modellen eerder in de keten. Het zorgt ervoor dat snel inzicht kan worden gegeven in de impact van wijzigingen in wet- en regelgeving, omdat alles daar (direct of indirect) aan verbonden is.</p> <p>Naast genoemde modellen zou er ook aandacht moeten zijn voor het expliciet maken en waar mogelijk hergebruiken van waardelijsten. Denk bijvoorbeeld aan lijsten van landen of talen. De Europese Unie heeft een <a href="https://op.europa.eu/en/web/eu-vocabularies/authority-tables">lijst van waardelijsten</a> beschikbaar die binnen Europa relevant zijn. In Nederland is bijvoorbeeld de standaard <a href="https://standaarden.overheid.nl/tooi">Thesauri en Ontologieën voor Overheidsinformatie</a> (TOOI) een interessante bron voor waardelijsten rondom overheidsorganisaties en publicaties.</p> <h3>Gegevenskwaliteit</h3> <p>Het is belangrijk dat in de metagegevens ook informatie aanwezig is over de kwaliteit van gegevens. Dit zorgt ervoor dat gebruikers kunnen bepalen in hoeverre de kwaliteit van de gegevens voldoende is voor hun specifieke gebruik. Dat is in eerste instantie met name relevant op het niveau van een dataset zoals een informatieproduct. Er zou op dataset niveau minimaal een vriendelijke beschrijving aanwezig moeten zijn waarin alle voor de gebruiker relevante aspecten van de kwaliteit. Dat is zowel een beschrijving van de eisen die worden gesteld aan de kwaliteit als de feitelijke kwaliteit zoals die is gebleken uit metingen. Die laatste is meer dynamisch van aard en zal daardoor in catalogi minder actueel zijn. Het resultaat van een meting op een specifiek moment in tijd geeft gebruikers al wel meer gevoel.</p> <p>Er zijn allerlei raamwerken en standaarden die gebruikt kunnen worden om meer gestructureerd en gericht uitdrukking te geven aan de kwaliteit van gegevens. Het resultaat is echter dat er allerlei verschillende termen en indicatoren worden gebruikt om uitdrukking te geven aan kwaliteit. Dit maakt het voor gebruikers lastig om dit goed te begrijpen. Om te komen tot meer consistentie is het belangrijk om met elkaar tot een gemeenschappelijke taal te komen in de vorm van een standaard raamwerk voor gegevenskwaliteit. Er is inmiddels een dergelijk raamwerk beschikbaar: het <a href="https://www.noraonline.nl/wiki/Raamwerk_gegevenskwaliteit">NORA raamwerk gegevenskwaliteit</a> (zie ook onderstaand figuur). Dit raamwerk is gebaseerd op een brede set van standaarden en op allerlei kennis en ervaringen van overheidsorganisaties. De basis ervan is ontstaan in de context van de Omgevingswet. Het raamwerk is inmiddels ook omarmd door het federatief datastelsel. Het streven is daarmee om alle registraties die daar deel van uit gaan maken conform dit raamwerk te beschrijven. Dit streven is ook overgenomen in deze domeinarchitectuur.</p> <p><img src="https://minbzk.github.io/gdi-gegevensuitwisseling/images/raamwerkgegevenskwaliteit.svg"></p> <p>De praktische implicaties van het gebruik van het raamwerk zijn ook besproken in een werkgroep binnen het programma federatief datastelsel. Het blijkt dat de diversiteit aan soorten gegevens, soorten contexten en gebruik het lastig maakt om tot een volledig gestandaardiseerde beschrijving te komen. Het meest waardevol en realistisch is om de kwaliteitsdimensies en attributen in het raamwerk vooral als categorie-indeling te gebruiken, zodat op dat niveau er in ieder geval een gestandaardiseerde taal is. Daarbinnen is het streven om zoveel mogelijk standaard zinstructuren te gebruiken, zodat de beschrijvingen zelf ook meer gestandaardiseerd kunnen zijn. Hiervoor zijn inmiddels zinsjablonen beschreven en beschikbaar. Idealiter zijn metagegevens over de kwaliteit van gegevens ook beschikbaar in machineleesbare vorm. Daarvoor bestaat de <a href="https://minbzk.github.io/gdi-gegevensuitwisseling/content/elements/id-293860e793c24752a4184737c13d802b.html">DQV standaard</a>, die gebaseerd is op Linked Data standaarden. Het NORA raamwerk kan hierin als taal worden gehanteerd. Vooralsnog is dit waarschijnlijk voor veel organisaties te ver gegrepen.</p> <p>Los van de beschrijving van de huidige of gewenste kwaliteit aan de hand van een kwaliteitsraamwerk zouden ook de kwaliteitsregels zelf beschikbaar moeten zijn via de metagegevens. Kwaliteitsregels zijn een specifieke vorm van beperkingsregels en drukken uit binnen welke grenzen gegevens zich zouden moeten begeven. Het kwaliteitsattribuut "logische consistentie" verwijst naar de mate waarin aan dit soort regels wordt voldaan en heeft dan ook alleen betekenis als de regels zelf beschikbaar zijn. Het kwaliteitsattribuut "waarschijnlijkheid" zegt iets over de mate waarin de gegevens waarschijnlijk zijn voor de situatie en verwijst naar de mate waarin signaalregels worden overschreden. Signaalregels zijn een specifieke vorm van kwaliteitsregels die aangeven dat gegevens mogelijk foute waarden bevatten. Ze leiden tot een waarschuwing. Er is op dit moment geen eenvoudige technologie-onafhankelijke standaard voor het beschrijven van beperkingsregels, waardoor moet worden gekozen tussen natuurlijke taal, een zelfbedachte taal, een leverancierspecifieke taal of modelleertaalspecifieke talen zoals OCL of SHACL. <h3>Voorwaarden en afspraken</h3> <p>Een andere belangrijke categorie van metagegevens heeft betrekking op de voorwaarden die gelden bij het gebruik van de gegevens. Dat zijn rechten, plichten en beperkingen die bijvoorbeeld kunnen voortvloeien uit wet- en regelgeving of auteursrechten. Het expliciet maken hiervan zorgt ervoor dat afnemers en gebruikers weten binnen welke grenzen gebruik van de gegevens mogelijk is. Het daadwerkelijk gebruik van de gegevens kan daarmee beschouwd worden als het impliciet akkoord gaan met deze gegevens. Het is ook mogelijk om rechten, plichten en beperkingen als afspraken in een overeenkomst op te nemen. De volgende tabel beschrijft een aantal voorbeelden van metagegevens met betrekking tot voorwaarden en de standaarden waar ze uit afkomstig zijn. Dublin Core (ISO 15836) is een algemene standaard voor metagegevens, die initieel voor web content is ontworpen. DCAT is gericht op metagegevens voor datasets. NL ISO 19115 is het Nederlandse metadata profiel op de ISO 19115 standaard voor geografische datasets. ODRL is een standaard voor het beschrijven van rechten, plichten en beperkingen. </p> <p> <table class="table table-striped"> <tr><td valign="top"><b>Naam</b></td><td valign="top"><b>Omschrijving</b></td><td valign="top"><b>Standaard</b></td></tr> <tr><td valign="top"><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#http://purl.org/dc/terms/license">license</a></td><td>Een verwijziging naar een juridisch document dat toestemming geeft om iets te doen met de resource.</td><td>Dublin Core / DCAT</td></tr> <tr><td valign="top"><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#accessRights">accessRights</a></td><td>Informatie over wie toegang heeft tot de resource of een indicatie van de beveiligingsstatus.</td><td>Dublin Core / DCAT</td></tr> <tr><td valign="top"><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/terms/rights/">rights</a></td><td>Een uitspraak of verwijzing naar eigendomsrechten, voor zover deze niet beschreven worden door license of accessRights.</td><td>Dublin Core / DCAT</td></tr> <tr><td valign="top"><a href="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#http://purl.org/dc/terms/rightsHolder">rightsHolder</a></td><td>Een persoon of organisatie die eigenaar is of de rechten beheert over de resource.</td><td>Dublin Core / DCAT</td></tr> <tr><td valign="top"><a href="https://www.w3.org/TR/odrl-vocab/#term-hasPolicy">hasPolicy</a></td><td>Machineleesbare autorisatieregels die rechten, plichten en/of beperkingen uitdrukken die van toepassing zijn op de resource.</td><td>ODRL / DCAT</td></tr> <tr><td valign="top"><a href="https://docs.geostandaarden.nl/md/mdprofiel-iso19115/#juridische-toegangsrestricties">accessConstraints</a></td><td>Juridische toegangsbeperkingen zoals copyrights, patenten, patentaanvragen, handelsmerken, licenties, intellectuele eigendomsrechten, verboden op gebruik of overige beperkingen. </td><td>NL ISO 19115</td></tr> <tr><td valign="top"><a href="https://docs.geostandaarden.nl/md/mdprofiel-iso19115/#overige-beperkingen">otherConstraints</a></td><td>Een verwijzing en beschrijving van de creative commons beperkingen die van toepassing zijn.</td><td>NL ISO 19115</td></tr> <tr><td valign="top"><a href="https://docs.geostandaarden.nl/md/mdprofiel-iso19115/#gebruiksbeperkingen">useLimitation</a></td><td>Een beschrijving van de toepassingen waarvoor de dataset niet geschikt is.</td><td>NL ISO 19115</td></tr> <tr><td valign="top"><a href="https://docs.geostandaarden.nl/md/mdprofiel-iso19115/#optionele-set-metadata">classification</a></td><td>Een classificatie van het vertrouwelijkheidsniveau en een omschrijving van de beperkingen als informatie vertrouwelijk is.</td><td>NL ISO 19115</td></tr> </table> </p> <p> Voor het uitwisselen van gevoelige gegevens zoals persoonsgegevens is het niet voldoende om relevante metagegevens te publiceren. Er zullen aanvraagprocessen nodig zijn (toetsing op privacy en ethiek ligt bij de afnemer). Op het moment dat aanvragen worden goedgekeurd, dan zullen mogelijk specifieke overeenkomsten moeten worden opgesteld. Denk daarbij bijvoorbeeld aan verwerkersovereenkomsten, maar ook aan gegevensleveringsovereenkomsten waarin de specifieke afspraken over bijvoorbeeld verantwoordelijkheden, de betrokken gegevens en de specifieke eisen zijn beschreven. Generieke voorwaarden zouden al op een hoger niveau moeten zijn geborgd, zoals in de vorm van algemene voorwaarden en service level agreements.</p> <p>In de huidige praktijk zijn er al allerlei aanvraagprocessen, maar kunnen deze best een lange doorlooptijd kennen en allerlei menselijke interpretatie en beoordeling vragen. Het streven is daarom om dit soort aanvraagprocessen te stroomlijnen en delen die zich daarvoor lenen te automatiseren. Dit vraagt dat bepaalde voorwaarden en afspraken ook worden vastgelegd in machineleesbare vorm, bijvoorbeeld conform de ODRL standaard. Onderdeel daarvan is ook dat controles die bij een aanvraag relevant zijn, alsook autorisatiescontroles die worden uitgevoerd bij het daadwerkelijk gebruik van de gegevens in machineleesbare regels zijn beschreven. Dit wordt “Policy Based Access Control” genoemd en wordt in meer detail beschreven <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-7af4783895fc4fb6b4cb8e96e8708e85.html">in de domeinarchitectuur toegang</a>. Het inrichten van de controleprocessen en bijbehorende systemen vraagt echter een behoorlijke inspanning en wordt dus liefst generiek ingericht. Er zijn hiervoor standaard afsprakenstelsels beschikbaar waarvan gebruik kan worden gemaakt, zoals iShare en de technologie van de International Data Spaces Association.</p> <h3>Herkomst van gegevens</h3> <p>Het is belangrijk om te kunnen begrijpen wat de herkomst is van gegevens. Het geeft een belangrijke indicatie van de kwaliteit van gegevens en bepaalt daarmee voor een belangrijk deel het vertrouwen dat gebruikers in de gegevens hebben. De herkomst van gegevens kan op allerlei niveaus in metagegevens zijn vastgelegd. De basis is dat in de metagegevens van een dataset duidelijk is welke organisatie de gegevens gecreëerd heeft. Voor individuele gegevens kan bijvoorbeeld relevante context zijn welke persoon ze heeft gecreëerd, op welk moment, naar aanleiding van welke gebeurtenis en als onderdeel van welke activiteit (zie ook onderstaand figuur). </p> <p><img src="https://minbzk.github.io/gdi-gegevensuitwisseling/images/context.svg"></p> <p> Voor informatieproducten geldt dat zij zijn afgeleid van brongegevens middels een transformatie. Gebruikers willen weten welke bronnen en afleidingsregels gebruikt zijn. De gebruikte bronnen moeten dan zijn beschreven in de metagegevens van het informatieproduct en de afleidingsregels moeten op te vragen zijn door gebruikers. Het liefst hebben gebruikers ook inzicht in de gebruikte brongegevens. Ze willen dat inzichtelijk hebben bij individuele gegevens in een rapport of dashboard waar ze naar kijken. In de door Kadaster en Geonovum ontwikkelde <a href="https://www.geonovum.nl/geo-standaarden/imx-geo-semantisch-model-basis-en-kernregistraties">IMX standaard</a> voor het samenstellen van gegevens is per individueel gegeven vastgelegd op basis van welke brongegevens en afleidingsregels deze tot stand is gekomen. Idealiter is de volledige keten inzichtelijk, van inwinning, via bewerkingen en transformaties tot op wat op een scherm zichtbaar is. Of dat ook echt noodzakelijk en haalbaar is zal in een individuele context moeten worden bepaald.</p> <p> De volgende tabel laat zien hoe bepaalde soorten metagegevens zoals weergegeven in de voorgaande figuur zich verhouden tot een aantal standaarden voor metagegevens. De cellen geven de soorten metagegevens weer in de standaarden PROV, Dublin Core en MDTO geredeneerd vanuit de gegevens zelf. De PROV standaard is specifiek gericht op het beschrijven van herkomst (provenance). De eerder genoemde IMX standaard is ook gebaseerd op de PROV standaard. De MDTO standaard is gericht op metagegevens voor duurzame toegankelijkheid. Niet weergegeven in de tabel is bijvoorbeeld de DCAT standaard, aangezien deze vooral gebruik maakt van de Dublin Core en PROV standaarden. In het applicatieprofiel voor DCAT (DCAT-AP 3.0) is ook een metagegeven beschikbaar voor het beschrijven van de wettelijke grondslag voor een dataset (applicableLegislation). Genoemde standaarden kennen allemaal een Linked Data representatie. Als de gegevens zelf beschikbaar zijn als Linked Data, dan zijn deze ook direct verbonden aan de bijbehorende ontologie (informatie/gegevensmodel). </p> <p> <table class="table table-striped"> <tr><td valign="top"><b></b></td><td valign="top"><b>PROV</b></td><td valign="top"><b>Dublin Core</b></td><td valign="top"><b>MDTO</b></td></tr> <tr><td valign="top"><i>Gebeurtenis</i></td><td valign="top">wasGeneratedBy.qualifiedStart</td><td valign="top"></td><td valign="top">event</td></tr> <tr><td valign="top"><i>Betrokkene</i></td><td valign="top">wasAttributedTo</td><td valign="top">creator, contributor, publisher, rightsHolder</td><td valign="top">betrokkene, event.eventVerantwoordelijkActor</td></tr> <tr><td valign="top"><i>Activiteit</i></td><td valign="top">wasGeneratedBy</td><td valign="top"></td><td valign="top">activiteit</td></tr> <tr><td valign="top"><i>Locatie</i></td><td valign="top">wasGeneratedBy.atLocation</td><td valign="top">coverage</td><td valign="top">dekkingInRuimte</td></tr> <tr><td valign="top"><i>Gebeurtenismoment</i></td><td valign="top">generatedAtTime</td><td valign="top">created, modified</td><td valign="top">event.eventTijd</td></tr> <tr><td valign="top"><i>Object</i></td><td valign="top">Entity</td><td valign="top">BibliographicResource</td><td valign="top">Informatieobject</td></tr> <tr><td valign="top"><i>Registratiemoment</i></td><td valign="top"></td><td valign="top">issued</td><td valign="top">event.eventTijd</td></tr> <tr><td valign="top"><i>Vermoedelijke fout</i></td><td valign="top"></td><td valign="top"></td><td valign="top">event.eventResultaat</td></tr> <tr><td valign="top"><i>Begrip</i></td><td valign="top"></td><td valign="top"></td><td valign="top">classificatie</td></tr> <tr><td valign="top"><i>Brongegevens</i></td><td valign="top">wasDerivedFrom</td><td valign="top">source</td><td valign="top">gerelateerdInformatieobject</td></tr> <tr><td valign="top"><i>Afleidingsregels</i></td><td valign="top">qualifiedDerivation</td><td valign="top"></td><td valign="top"></td></tr> </table> </p> <p>In de context van de hernieuwde eIDAS verordening zal er een European Digital Identity Wallet beschikbaar komen. Hierin kunnen gebruikers verifieerbare verklaringen plaatsen van allerlei partijen, die ze vervolgens kunnen verstrekken aan dienstverleners. Een verifieerbare verklaring is eigenlijk een bewijs dat gegevens afkomstig zijn van een bepaalde partij. Het zegt daarmee dus ook iets over de herkomst van gegevens. Ook in de context van de Single Digital Gateway zullen allerlei organisaties verifieerbare verklaringen moeten gaan leveren. Daarbij gaat het vooral over grensoverschrijdende procedures die ondersteund moeten worden, zoals het opvragen van een diploma van iemand. Bij elkaar zorgt dit ervoor dat het toenemend belangrijk wordt voor organisaties om verifieerbare verklaringen te kunnen leveren, om voorbereid te zijn op dit soort ontwikkelingen. Ook los van deze ontwikkelingen is het leveren van een meer formeel bewijs van de herkomst van gegevens mogelijk waardevol. Het geeft afnemers een bepaald vertrouwen in het gegeven en de herkomst. Op technisch niveau kan er ook gekozen worden voor het ondertekenen van een bericht om een vorm van onweerlegbaarheid te realiseren.</p>