HIM - Handreiking Informatie Modelleren

1.1 Achtergrond

De komende jaren wordt de Omgevingswet- en regelgeving geschreven en geïmplementeerd. Deze wet zet in op een aantal verbeterdoelen, zoals meer gebruiksgemak, snellere en betere besluitvorming en minder onderzoekslasten. Om deze doelen te kunnen realiseren is een verbeterslag nodig in de digitale ondersteuning van de wet.

Uit Doelarchitectuur DSO.

Binnen het digitaal stelsel maken veel verschillende partijen meervoudig gebruik van gegevens. Het is daarbij van belang dat de onderlinge samenhang en betekenis van de gegevens binnen een bepaalde context wordt beschreven. Dit gebeurt met behulp van informatiemodellen. Het doel van een informatiemodel is een beschrijving van (de informatie over) de werkelijkheid, los van implementatieaspecten. Voor het digitaal stelsel is het van groot belang dat alle informatiemodellen op dezelfde manier beschreven worden, volgens een nog vast te stellen standaard.

Dit document gaat specifiek in op regels voor het opstellen van dataspecificaties en de daarin voorkomende informatiemodellen.

1.2 Toepassingsdomein

Deze handreiking voor informatiemodellering richt zich specifiek op informatiemodellen voor het beschrijven van informatieproducten of datasets die gedeeld c.q. uitgewisseld, of geraadpleegd worden in de context van het DSO. Het zijn informatieproducten waarvan standaardisatie nodig is in het kader van interoperabiliteit. Voor producten die niet gedeeld worden speelt het interoperabiliteitsvraagstuk niet en is deze handreiking niet van toepassing.

Specifiek is de handreiking voor informatiehuizen binnen het DSO en de vanuit die huizen ontsloten informatieproducten. In een bredere context is de handreiking van toepassing voor alle informatieproducten binnen het DSO waarbij informatiemodellen worden gebruikt voor de beschrijving daarvan.

Het in deze handreiking gebruikte metamodel voor informatiemodellering is gebaseerd op de principes van de objectoriëntatie. Het technisch-conceptuele toepassingsdomein is daarmee bepaald tot deze omgeving.

1.3 Normatieve referenties

Deze methode maakt gebruik van verschillende normatieve documenten. Dit zijn zowel nationale als internationale standaarden. In dit hoofdstuk zijn deze normatieve referenties opgenomen. Voor een goede toepassing van dit document is kennis nodig van de opgenomen referenties.

Metamodel voor informatiemodellering; KING, Kadaster, Geonovum.

NEN 3610:2011/A1:2016 Basismodel Geo-informatie – Termen, definities relaties en algemene regels voor de uitwisseling van informatie over aan de aarde gerelateerde ruimtelijke objecten.

NEN-EN-ISO 19105:2005 Geographic information – Conformance and testing

NEN-EN-ISO 19131:2008 Geographic Information – Data product specifications.

NEN-EN-ISO 19135:2007 Geo-informatie - Procedures for registration of geographical information items.

2.1 Rol van dataspecificaties, informatiemodellen en relatie met stelselscatalogus.

Het DSO is een infrastructuur voor gegevensuitwisseling, aanbod en gebruik, rond het thema leefomgeving/omgevingswet. Voor het ontwerp van een infrastructuur spelen standaarden een belangrijke rol. Een onderdeel van die standaarden betreft het vastleggen en beschrijven van de semantiek van de registraties beheerd door de informatiehuizen. Het DSO omvat informatiehuizen; informatiehuizen bevatten gegevens waarmee informatie wordt gegenereerd en middels berichten wordt gecommuniceerd. Dataspecificaties beschrijven in detail de data inhoud van de informatiehuizen en de dataproducten die worden geleverd. Dataspecificaties ondersteunen de volgende functies:

• Inwinning van gegevens: definitie van domein, welke gegevens moeten worden ingewonnen (of geleverd);

• Definitie van aanbod: definitie van gegevens die in een dataset of data service zitten. Definitie is tot op hoogste detail niveau (kenmerk, waardetype, multipliciteit);

• Genereren van metadata: deel van informatie is input voor metadata;

• Evaluatie van geschiktheid voor gebruik (door gebruikers);

• Harmonisatie binnen en tussen data aanbod per informatiehuis; informatiedetail maakt inhoudelijke afstemming mogelijk;

• Integrale informatievragen over de domeinen van informatiehuizen heen;

• Specificaties voor applicatie-ontwikkeling. Gedetailleerde beschrijving geldt als specificatie voor informatiehuishouding en berichtenspecificatie, validatie.

In onderstaand figuur wordt de rol van dataspecificaties, of in beperktere zin, informatiemodellen, gepositioneerd. Voor dit document betreft het dataspecificaties voor informatiehuizen.

In figuur 2 is er een centrale rol voor de stelselcatalogus en de toepassing daarvan in registers. In het rapport Globaal functioneel ontwerp stelselcatalogus wordt die nader toegelicht. In de stelselcatalogus worden begrippen opgenomen die betekenis hebben binnen het DSO, hetzij vanuit een juridisch perspectief van beleid en wetgeving, hetzij van uit een administratief perspectief van gegevensregistraties. De stelselcatalogus brengt die begrippen in relatie tot elkaar. Zoekingangen vanuit beide perspectieven leiden daarmee tot dezelfde gegevens. Tevens zijn in de stelselcatalogus de metadata van de informatiemodellen opgenomen.

Een dataspecificatie richt zich op de overdracht of levering van gegevens. Het is de ‘view’ op de registraties die geheel gericht is op het leveren van gegevens. Een dataspecificatie is ook een informatiebron voor de stelselcatalogus. De gegevenselementen uit een dataspecificatie worden in een stelselcatalogus gepubliceerd. De stelselcatalogus en dataspecificatie zijn daarmee complementair. De dataspecificatie puur gericht op de beschrijving van de registratie, data vanuit het berichtenperspectief en de catalogus gericht op de semantiek van begrippen en koppeling naar de informatiebronnen.

Onderstaand figuur schets de afhankelijkheden tussen een dataspecificatie en gerelateerde producten.

Figuur 3 - Relaties tussen een dataspecificatie en gerelateerde producten. Een Dataspecificatie is een product van een informatiehuis en specificeert structuur en inhoud van datasets of data berichten. De stelselcatalogus is de voorziening waarin semantiek wordt geïntegreerd over het hele DSO.

Figuur 3 heeft twee grote blokken, een gedeelte binnen de structuur van een informatiehuis en een gedeelte als algemene DSO-voorziening. Informatiehuizen beschrijven hun producten, data, datasets en berichten door middel van een dataspecificatie met daarin een informatiemodel. Het informatiemodel publiceert de semantiek middels termen en definities in de stelselcatalogus. De stelselcatalogus is een algemene DSO-voorziening die vocabulaire koppelt aan de termen in een informatiemodel. De stelselcatalogus integreert daarmee de semantiek van de informatiehuizen/modellen over het hele DSO. Vanuit het gebruikersperspectief is de stelselcatalogus het meest zichtbaar en vormt de ingang tot de semantiek en gerelateerde informatiehuizen, data en datasets. Van belang is om de relatie tussen catalogus en dataspecificatie duidelijk te hebben zodat er geen overlap optreedt. Daarom wordt de relatie nog iets verder uitgewerkt.

Dataspecificatie/informatiemodel: Beschrijft de inhoud en structuur van de data binnen de context (is domein) van een informatiehuis. De beschrijving is gericht op het verklaren van de data, datasets en databerichten die een informatiehuis als producten kan leveren. De beschrijving omvat termen, kenmerken en relaties tussen termen van toepassing binnen het domein.

Stelselcatalogus: Bevat het totaal aan begrippen binnen het DSO: het vocabulaire. Dit vocabulaire is gekoppeld aan de informatiemodellen en verwijst o.a. naar toepassing daarvan in termen van de informatiemodellen.

Een belangrijk verschil is dat de dataspecificatie/informatiemodel opgesteld is binnen de context van het domein van het informatiehuis en de catalogus de hele wereld als context heeft. De zogenaamde ‘closed world’ versus een ‘open world’. In een ‘closed world’ zou een informatiemodel en de catalogus gelijk zijn. Omdat er meerdere huizen zijn en het DSO in een open wereld opereert (algemene begrippen, juridische begrippen, administratieve begrippen, vaktaal enz) is een algemeen vocabulaire of koppeling van vocabulaires nodig. De stelselcatalogus levert die voorziening. Dat wil niet zeggen dat de semantiek van informatiehuizen en de gerelateerde informatiemodellen geen harmonisatiedoel hebben. Dat hebben ze wel.

Twee belangrijke relaties tussen catalogus en informatiemodel zijn dat termen uit een informatiemodel verwijzen naar de begrippen in het vocabulaire van de catalogus en andersom. Om dit mogelijk te maken is het nodig dat inhoud van een informatiemodel gepubliceerd wordt in de stelselcatalogus.

De stelselcatalogus specificeert hiervoor de volgende toepassingseis:

Voor de opname van metadata in de stelselcatalogus is de volgende eis opgenomen:

Beide bovenstaande eisen waaraan de stelselcatalogus moet voldoen stellen ook voorwaarden aan de informatiemodellen.

2.2 Principes.

Het basisprincipe achter een dataspecificatie is dat een dataset in voldoende mate beschreven moet zijn wil data betekenisvol gebruikt kunnen worden. Uit laan infrastructuur - globaal ontwerp: Voor zowel de informatiehuizen als ICT-voorzieningen geldt dat hun standaarden voor uitwisseling altijd gebaseerd zijn op een informatiemodel, waarin de semantiek vastligt. Ieder informatiehuis kent zijn eigen model, maar ook ieder ketenproces (bijvoorbeeld vergunningaanvraag) kent een informatiemodel, waarin de betekenis van informatie is vastgelegd. Deze informatiemodellen worden voor de Laaninfrastructuur op elkaar afgestemd.

Informatiehuizen hebben daarin een eigen verantwoordelijkheid voor het beschrijven van de betekenis van hun datasets en ook een gezamenlijke verantwoordelijkheid voor afstemming van betekenis tussen informatiehuizen.

2.3 Het proces.

Het DSO is niet een infrastructuur waarvan alle onderdelen vanuit niets opgebouwd hoeven te worden. Hetzelfde geldt voor de dataspecificaties van de informatiehuizen. Sommige datasets moeten nog gedefinieerd worden als een afgeleide van een beschreven toepassingsdomein terwijl andere sets al toepassing vinden maar nog niet op de juiste manier of nog onvolledig beschreven zijn. Er is daarom geen algemeen proces te beschrijven. Voor de één zal het een proces met use-case met requirements en stakeholders zijn terwijl voor anderen een revers-enginering aan de hand van bestaande uitwisseling en services mogelijk is. Beide methoden zullen worden toegelicht. Voor beide processen is de doelspecificatie wel duidelijk. Ongeacht de gevolgde methode is het eindproduct conform deze beschrijving.

Regel: Een dataspecificatie binnen het DSO is conform de in deze handreiking opgenomen specificaties.

2.4 Rollen in het proces

Een informatiehuis is verantwoordelijk voor de kwaliteit van de gegevens binnen het huis en het aanbod daarvan aan het DSO. Van uit die rol is het informatiehuis verantwoordelijk voor aanwezigheid en inhoud van een dataspecificatie. In feite is het de inhoudelijke specificatie van het informatieproduct dat het huis levert of kan leveren.

In het proces van de opstelling van een dataspecificatie zijn de volgende kennisvelden van belang:

• Domeinkennis: inhoudelijke kennis over het domein, data gebruik en toepassing in werkprocessen;

• DSO kennis: kennis over architectuur van het DSO en algemene regels en afspraken. Inclusief relaties, afstemming tussen informatiehuizen;

• Modelleerkennis: Algemene modelleerkennis en informatie analyse, en specifiek voor toepassing binnen het DSO;

• Softwarekennis: De relatie tussen specificaties en de haalbaarheid in softwaretoepassing moet worden bewaakt.

De bovengenoemde kennis hoeft niet altijd en tegelijk aanwezig te zijn binnen een opdracht voor het opstellen van een dataspecificatie. Het is wel zaak dat het proces zo ingericht is dat alle aspecten aan de orde komen. Voor wat betreft de rollen zijn de volgende profielen van belang:

• Domeinexpert: levert de ervaring en kennis van het domein en de te gebruiken data;

• Procesleider: leidt het proces en zorgt ervoor dat de methode wordt gevolgd;

• Informatie-analist, UML modelleur: zorgt voor de documentatie van de dataspecificaties inclusief de UML modellering.

Details over verantwoordelijkheden en gedetailleerde afspraken zijn specifiek voor elk informatiehuis en kunnen hier niet worden opgenomen.

2.5 Validatie, vaststelling en beheer

Na het volgen van de methode ligt er een dataspecificatie. Voor het bewaken van de kwaliteit van de toepassing van de methode is een conformiteittoets en procedure daarvoor een bruikbaar middel. Een conformiteittoets is een meet- en controle-instrument maar ook een methode voor review van kandidaat-specificaties. In bijlage 2 is een abstracte versie van een conformiteittoets opgenomen. Voor een operationele toepassing moet die uitgewerkt worden tot concrete testregels en procedure.

Een volgende stap is de formele vaststelling. Hieraan vooraf gaat meestal een consultatie. Afhankelijk van het informatiehuis zal dit verschillend ingevuld worden. Een werkveldconsultatie, een nationale consultatie, een beperkte expert consultatie zijn voorbeelden. Centraal staat dat na consultatie en verwerking daarvan een dataspecificatie wordt vastgesteld en bekrachtigd. Bekrachtiging is in drie stappen: binnen de context van een informatiehuis, binnen de context van het DSO en op nationaal niveau.

Als dat doorlopen is, is de dataspecificatie een semantische standaard. De standaard voor de inhoudelijke beschrijving van een domein.

Beheer.

Een standaard die niet in beheer is, is geen standaard. Beheerverantwoordelijkheid omvat velerlei facetten die vaak ook situationeel afhankelijk zijn, in dit geval ook van de afzonderlijke informatiehuizen. Binnen de context van de individuele informatiehuizen is het verstandig te kiezen voor een zelfde algemeen uitgangspunt voor het inrichten van een ontwikkel- en beheeromgeving zoals beschreven in de BOMOS^1 standaard (Beheer en Ontwikkelmodel Open Standaarden) en het BOMOS2i stappenplan. Uit deze standaard worden een aantal operationele facetten opgenoemd.

<https: www.forumstandaardisatie.nl="" open-standaarden="" voor-beheerders="" beheer-van-standaarden="">

Communicatie: Promotie en publicatie.

Implementatie ondersteuning: Helpdesk, Validatie en certificatie.

Wijzigingsprotocol: Indienen, beoordeling, verwerking.

Versiebeheer: Visie op operationele toepassing versies en termijnen voor opvolgende versies.

Of er een gemeenschappelijke governance komt van dataspecificaties over de informatiehuizen heen is hier niet te bepalen. Het rapport Globaal ontwerp en prototype stelselcatalogus adviseert om het beheer van semantiek over de informatiehuizen heen bij de stelselcatalogus te leggen. Deze beheerder organiseert het beheer aan de stelselcatalogus in een beheeroverleg met de betrokkenen zoals de modelleurs van de informatiehuizen. Hierdoor kan de stelselcatalogus beheerder vanuit een neutrale rol komen tot harmonisatie-, verbeter- en afstemmingsvoorstellen tussen de dataspecificaties.[^2]

[^2]: Globaal ontwerp en prototype stelselcatalogus

3.1 Overzicht.

Als basis voor een stappenplan voor het realiseren van een dataspecificatie wordt de INSPIRE methode genomen. Hierin wordt sterk gefocust op een use-case georiënteerde benadering. In principe is dat ook juist, een registratie heeft immers altijd een doel, een use-case of een werkproces. Deze stelt eisen aan de semantiek, eisen die leidend zijn voor de ontwikkeling van een dataspecificatie. Moeilijkheid is vaak dat registraties een zeer algemene use-case hebben zoals bijvoorbeeld ‘voorzien in basisinformatie binnen een domein die voldoet aan meervoudig gebruik’, zonder dat het meervoudig gebruik getypeerd kan worden. Een andere situatie is dat er veelal registraties zijn die al operationeel gepubliceerd worden maar nog geen of nog geen volledige dataspecificaties hebben. In dat geval is het maken van een dataspecificatie nog steeds zinvol maar ziet het proces er anders en korter uit. Onderstaand zijn grofweg de processtappen beschreven. Enkele stappen worden toegelicht.

Figuur 4 - Processtappen in het opstellen van een dataspecificatie. (aangepast van INSPIRE D2.6)

dataspecificatie nog steeds zinvol maar ziet het proces er anders en korter uit.
Onderstaand zijn grofweg de processtappen beschreven. Enkele stappen worden toegelicht.

3.2 Use-case beschrijving.

De use-case of werkproces is een beschrijving van het doel waarvoor een dataspecificatie wordt gemaakt. Het is van belang om de eisen die de aan data gesteld worden te bepalen aan de hand van de werkprocessen waar ze voor gebruikt gaan worden. Een use-case onderscheidt typen gebruikers en gebruik en activiteiten of doelen die worden ondersteund of gerealiseerd. Er kunnen ook meerdere use-cases van toepassing zijn. Meestal zijn de beschrijvingen van use-cases voor registraties heel algemeen of kan er met enkele specifieke voorbeelden een typisch gebruik worden aangegeven. De beschrijving is meestal in een beschrijvende taal met de termen zoals die in het toepassingsdomein worden gebruikt.

3.3 Gebruikseisen (User requirements)

De volgende stap is het identificeren van eisen die aan de gegevensset worden gesteld. Het is een eerste inventarisatie van uitgangspunten waaraan de gegevens moeten voldoen. Op basis van de use-case(s) worden aspecten bepaald zoals detail, taal, terminologie, afstemmingsdomein, harmonisatie met domeinen, hergebruik van gegevens maar ook modelleerprincipes. De lijst met gebruikseisen is hierna de richtlijn die gebruikt wordt om objecttypen en hun eigenschappen te bepalen. De gebruikseisen kunnen ook weer leiden tot het aanpassen van de use-case.

3.4 Objecttypen

Dit is de fase waar een eerste grove vorm van het informatiemodel wordt gemaakt. De use-case en de gebruikseisen hebben al een beeld geschetst wat het toepassingsdomein is en de informatie die een rol speelt. Een aantal objecttypen kunnen al bepaald worden en een eerste contour van een model worden geschetst. Dit is de eerste presentatie van het toepassingsverhaal in een informatiemodel in de vorm van een conceptuele taal (in dit geval UML). Het is hierbij van belang dat domeinexperts meegenomen worden in dit verhaal. De domeinexperts zijn immers degene die de input leveren voor uitwerken van het model.

3.5 Ontwikkeling dataspecificatie

Voor de documentatie van een dataspecificatie voor geo-informatie is er een internationale standaard ISO 19131. Op basis van die standaard en de toepassing daarvan in INSPIRE en in het DSO is een template ontwikkeld (bijlage 4). Dat template wordt gebruikt om de verschillende onderwerpen in te vullen. Centraal in dit proces is in deze fase nog het informatiemodel. Het startmodel wordt in verschillende iteraties met sessies met domeinexperts verder ontwikkeld tot het niveau waarop het beantwoordt aan alle aspecten van de use-case en de gebruikseisen. Daarna worden de andere hoofdstukken ingevuld.

3.6 Testen en validatie

De dataspecificatie is in eerste instantie nog een theoretisch verhaal. Het beschrijft de kennis die door de domeinexperts is aangeleverd. Afhankelijk van de complexiteit van de use-case is er een meer of minder complex model ontstaan en is er meer of minder zicht op de werkelijke implementatie. In deze fase worden de specificaties getest door het maken van voorbeelddata. De toepassing in voorbeelddata is een controle op technische haalbaarheid maar leidt meestal ook tot nieuw inzicht over inhoudelijke beslissingen.

Afhankelijk van het ingerichte proces en de concreetheid van de use-case kan de test ook een proof of concept omvatten waarbij de voorbeelddata in een applicatie worden gebruikt die specifiek aan de use-case beantwoord.

In deze fase wordt er ook een consultatie van het werkveld uitgevoerd. Afhankelijk van de organisatie van het werkveld worden de stakeholders op verschillende manieren betrokken bij de consultatie. Dit kan éénmaal aan het einde van de oplevering gebeuren of ook meerdere malen in het proces. Een proof of concept en ook het maken van de voorbeelddatasets kan eerst door een externe consultatie worden voorafgegaan. De resultaten van de consultatie kunnen dan al voorafgaand aan de proof of concept worden verwerkt.

3.7 Harmonisatie

Een apart en belangrijk punt van aandacht is harmonisatie van semantiek over de informatiehuizen heen. Uitgangspunt is dat informatiemodellen voortbouwen op semantiek die al geformaliseerd is. Waar informatiemodellen nog vaak binnen de context van het informatiehuis blijven zal middels de toepassing van de stelselcatalogus relaties met de semantiek van andere huizen eenduidig gelegd worden. Er ontstaat daarmee een groeiende verzameling van op elkaar afgestemde begrippen. In de ontwikkelfase van een informatiemodel is inventarisatie van wat er al is en potentieel hergebruik een belangrijk punt. Voor het leggen van relaties, het beoordelen van begrippen voor geschiktheid voor hergebruik of het doen van harmonisatievoorstellen wil een informatiemodelleur graag begrippen met elkaar kunnen vergelijken[^1]. De stelselcatalogus is daarvoor het middel.

[^1]: Globaal ontwerp en prototype stelselcatalogus

Het rapport Globaal ontwerp en prototype stelselcatalogus adviseert om het beheer van semantiek over de informatiehuizen heen bij de stelselcatalogus te leggen. Deze beheerder organiseert het beheer aan de stelselcatalogus in een beheeroverleg met de betrokkenen zoals de wetgevingsjuristen, regelbeheerders en modelleurs van de informatiehuizen. Hierdoor kan de stelselcatalogus beheerder vanuit een neutrale rol komen tot harmonisatie-, verbeter- en afstemmingsvoorstellen.

3.8 Extensies op bestaande modellen.

Al genoemd is dat een informatiemodel zoveel als mogelijk hergebruik maakt van bestaande semantiek en bestaande informatiemodellen. Het kan voorkomen dat het uitbreiden van bestaande informatiemodellen met extra semantiek een wenselijke methode is. O.a. bij het toepassen van INSPIRE dataspecificaties voor Nederlandse werkprocessen kan die methode toegepast worden. Een methode daarvoor is uitgewerkt op: <http: inspire-extensions.wetransform.to="">

4.1 Metamodel – Toepassing van KKG

Een metamodel beschrijft de informatie-elementen op het metaniveau. Het is in feite het informatiemodel van het informatiemodel. Het beschrijft de typen en eigenschappen van de informatie-elementen die kunnen voorkomen in een informatiemodel.

UML (Unified Modelling Language) is de modelleertaal die voorgeschreven wordt voor het maken van een informatiemodel. UML bepaalt voor een deel de structuur en informatie-elementen van het informatiemodel. Maar UML laat nog teveel vrijheden om als algemene afspraak richtinggevend te zijn. Binnen UML kunnen en moeten nog extra regels vastgelegd worden om de betekenis van de informatie-elementen eenduidig vast te leggen. Dit wordt in het metamodel beschreven. Een registratie kan in de toepassing van het metamodel nog behoefte hebben aan nadere afspraken of uitbreidingen op het metamodel. Deze extensies zijn mogelijk maar mogen niet in tegenspraak zijn met het metamodel.

Regel: Een informatiemodel wordt beschreven door middel van UML.

Regel: Het in dit document beschreven metamodel geldt als uitgangspunt voor de nadere specificering van de toepassing van UML.

Regel: Extensies op het metamodel zijn mogelijk maar mogen niet in tegenspraak zijn met het metamodel.

Het document Metamodel voor informatiemodellen, opgesteld door KING, Kadaster en Geonovum wordt overgenomen voor toepassing binnen het DSO. Het genoemde metamodel wordt aangeduid als metamodel KKG.

Regel: DSO gebruikt KKG metamodel voor informatiemodellen.

Het KKG onderscheidt een aantal niveaus van informatiemodellering, van begrippenmodel, conceptueel informatiemodel, logisch informatiemodel tot technisch gegevensmodel. Voor het metamodel in deze handreiking is het niveau van het logisch informatiemodel van toepassing. Ter begrip hiervan is de volgens tekst uit KKG overgenomen:

1. Model van begrippen
   Beschrijft de werkelijkheid binnen het beschouwde domein (de ‘universe of discourse’) d.m.v. de daarin gehanteerde begrippen en hun relaties tot elkaar. Doel is dat de actoren daarbinnen elkaar begrijpen en één taal spreken. Een model van begrippen wordt opgesteld voor gebruik door mensen, met name ‘de business’. De begrippen worden beschreven in een formele taal, een vocabulaire. Een vocabulaire is geen informatiemodel. Begrippen kunnen in meerdere informatiemodellen gebruikt worden.

2. Conceptueel informatiemodel
   Modellering van de werkelijkheid binnen het beschouwde domein, v.w.b. informatie daarvan, onafhankelijk van ontwerp van en implementatie in systemen. Het geeft een zo getrouw mogelijke beschrijving van die werkelijkheid en is in natuurlijke taal geformuleerd. Een dergelijk model definieert het ‘wat’: welke ‘concepten’ (‘dingen’) worden onderscheiden (in de beschouwde werkelijkheid), wat betekenen zij, hoe verhouden ze zich tot elkaar en welke informatie (eigenschappen) is daarvan relevant. Het dient als taal waarmee domeinexperts kunnen communiceren met informatie-analisten en verschaft een eenduidige interpretatie van die werkelijkheid ten behoeve van deze communicatie. Een conceptueel informatiemodel wordt dan ook opgesteld voor gebruik door mensen, zodat ‘de business’ en de ICT-specialisten elkaar gaan begrijpen.

3. Logisch informatie- of gegevensmodel
   Beschrijft hoe de, in het conceptuele model onderscheiden, concepten gebruikt worden bij de interactie tussen systemen en hun gebruikers en tussen systemen onderling. Anders gezegd, een model van de representatie van informatie over de werkelijkheid in digitale registraties en in de uitwisseling daartussen. Het gaat hierbij, in tegenstelling tot een conceptueel model, dus veel meer om het ‘hoe’. Het slaat de brug tussen werkelijkheid en systemen maar beschrijft nog niet de implementatie in die systemen. Een dergelijk model wordt in een formele taal beschreven en wordt waar mogelijk gegenereerd vanuit het conceptueel model. Het logisch model wordt opgesteld voor ICT-interoperabiliteit, voor gebruik door met name de ontwerpers, bouwers en beheerders van ICT-voorzieningen.

4. Fysiek of technisch gegevens- of datamodel

Specificeert de structuur en eigenschappen van de technologie waarin de informatie wordt vastgelegd of uitgewisseld. Dit is sterk afhankelijk van de gebruikte opslagtechnologie zoals een specifieke database of de servicetechnologie zoals XML, GML, SOAP, REST, (Geo)JSON, LinkedData e.d. Het kan tevens informatie bevatten over de manier waarop berichten ‘verpakt’ worden, het (internet)protocol en de logistiek van het berichtenverkeer. De technische specificaties worden over het algemeen zoveel als mogelijk gegenereerd uit het logisch informatiemodel. Deze specificaties worden opgesteld voor ‘machines’, te gebruiken door software-ontwikkelaars

Binnen de context van deze handreiking geldt het logisch informatiemodel als het operationele niveau waarop informatiemodellen zijn beschreven. De keuze hiervoor is ingegeven door de overweging dat dit niveau geschikt is voor model driven omzetting naar afgeleide producten die een digitale gegevensuitwisseling ondersteunen.

Regel: Dit document gebruikt het logisch informatiemodel als het niveau waarop informatiemodellen worden beschreven.

4.2 Objectidentificatie

De objectidentificatie zorgt voor het identificeren van instanties van objecttypen. In feite dus de identificatie van de objecten in een registratie. Dit is niet hetzelfde als de identificatie van objecten in de werkelijkheid. Voor dat laatste zijn er andere mechanismen die voor elke registratie specifiek kunnen zijn. De objectidentificatie is eigenlijk de elektronische pointer of sleutel naar de objecten in de registratie. Omdat die sleutel een bruikbare waarde moet hebben over alle registraties heen, binnen Nederland en ook wereldwijd, is het van belang om een systematiek voor wereldwijde unieke identificatie van objecten toe te passen.

Om dit te realiseren wordt er binnen het DSO een URI strategie ontwikkeld voor unieke objectidentificatie. Voor de toepassing hiervan wordt verwezen naar dat document[^2].

[^2]: Kaderstellende notitie, URI-strategie.

4.3 Temporeel model

Het bijhouden van historie en toekomst in relatie tot geldigheid van gegevens valt onder het temporele model. KKG heeft op meta niveau een mechanisme om aan te geven of attributen historie op bouwen. In KKG is op het logisch niveau daarvoor geen implementatie beschreven. Binnen deze handreiking is dat ook niet opgenomen. Voor de DSO moet worden bezien hiervoor een gestandaardiseerde oplossing wordt ontwikkeld.

4.4 Standaard datatypen

Regel:

Informatiemodellen maken voor basis datatypen (of waardetypen) daar waar van toepassing gebruik van internationale standaarden.

Eén van de onderdelen waarop relatief eenvoudig gestandaardiseerd kan worden is de semantiek en syntax van datatypen en specifiek de basis waardetypen. Voorbeelden hiervan zijn ‘numerieke waarde’, ‘alfanumerieke waarde’, ‘geheel getal’, ‘datum’. Internationaal zijn de equivalenten hiervan gestandaardiseerd. Hiermee wordt geharmoniseerd over de informatiemodellen van de leefomgeving doormiddel van het aansluiten op internationale standaarden.

Voorbeelden van standaarddatatypen zijn: characterString, integer, real en ook date, dataTime, Surface, Point

Referentie voor standaard typen is:

• ISO/IEC 19501:2005 Information technology – Open distributed Processing Modelling Language (UML) Version 1.4.2

• ISO/IEC 11404: Information technology – General Purpose Datatypes (GPD)

• ISO 19107: Geographic information – Spatial schema

4.5 Geen waarde

ISO/IEC 11404 definieert void (geen waarde) als een object waarvan de aanwezigheid syntactisch of semantisch nodig is maar in bepaalde voorkomens (instanties) geen waarde heeft.

Een element in de inhoud van een bericht heeft in de regel een waarde. Het XML principe is ook dat een element zonder waarde niet wordt uitgewisseld. Toch is het zinvol om de reden dat iets geen waarde heeft kenbaar te kunnen maken. Het kan bijvoorbeeld zijn dat de waarde er wel is maar de aanvrager niet geautoriseerd is, of dat de waarde er niet is omdat ze niet wordt ondersteund door de registratie. Zo zijn verschillende redenen die mogelijk van belang kunnen zijn om aan te geven. Voor het specificeren van het informatiemodel kan het van belang zijn om de ‘geen waarde’ constructie expliciet bij informatie-elementen aan te geven. In overeenstemming met ISO/IEC 11404 wordt daarmee aangegeven dat het informatie-element semantisch nodig is maar in bepaalde gevallen niet kan worden opgenomen of uitgewisseld. Het is dan duidelijk voor welke elementen de constructie wel of niet gebruikt mag worden. KKG geeft dit aan door bij die elementen een ‘indicatie mogelijk geen waarde’ op te nemen. Het kan toegepast worden bij attributen en associatierollen.

Voor de redenen dat een element niet is ingevuld is een afgesproken lijst ontwikkeld. Omdat niet alle redenen van te voren zijn te bepalen is dit een open lijst.

Regel: Voor de redenen voor invullen geen waarde wordt een gestandaardiseerde lijst gehanteerd.

Deze UML constructie wordt in XML geïmplementeerd middels een ‘nillable’ type met ‘nilreason’.

5.1 Software en UML profiel

Voor de toepassing van het metamodel is een UML-profiel met stereotypen gemaakt voor toepassing in modelleersoftware.

6.1 Bijlage 1: Abstracte conformiteittoets: Dataspecificatie voor DSO.

Inleiding

De test suite voor de conformiteittoets volgt de regels van ISO 19105 Geographic information – Conformance and testing. Deze handreiking beschrijft de regels voor toepassing van dataspecificaties voor het uitwisselen van data binnen het DSO. Het onderwerp voor toetsing is daarmee bepaald tot dataspecificaties binnen die context. Met de term dataspecificatie wordt in de test bedoeld het object dat wordt getest. De conformiteittest bestaat uit testregels die testen of een dataspecificatie voldoet aan deze handreiking.

Abstracte test versus Uitvoeringstest.

Deze test suite bevat de beschrijving van de abstracte test. Toepassing hiervan in een uitvoeringsformat leidt tot een uitvoeringstest. Deze laatste bevat een referentie aan de abstracte test met een concrete uitwerking voor uitvoering. In de uitvoeringstest is een format opgenomen hoe de rapportage van de uitvoering van de test wordt weergegeven. In deze abstracte test is daarom geen format voor de rapportage opgenomen.

Voor het beschrijven van de testregels wordt het volgende format gebruikt:

X.Y Testonderwerp

1. Testreden: Achtergrond van de test.

2. Testmethode: Instructie hoe de test wordt uitgevoerd.

3. Referentie: Onderbouwing met referentie naar dit document.

4. Testtype: Er zijn twee typen: basistest (basic) en detail(capability).

5. De basistest is een eerste test om algemene regels te verifiëren, de detailtest valideert op onderdelen.

De testregel wordt gevalideerd en de uitkomst is één van de volgende conformiteitklassen

1. Conform: De dataspecificatie is volledig conform de specificatie beschreven in het testonderwerp.

2. Niet conform: De dataspecificatie is niet conform de specificatie beschreven in het testonderwerp.

3. Niet van toepassing: Het testonderwerp is niet van toepassing voor deze dataspecificatie.

Testregels: ATS dataspecificatie voor DSO.

1.1 Scope van de dataspecificatie.

1. Testreden: Bepaal of van de dataspecificatie die getest wordt het onderwerp (scope) valt binnen de scope van het DSO, of een rol gaat vervullen.

2. Testmethode: Kijk of het onderwerp van de te testen specificatie beschreven is en of het valt binnen de scope van het DSO. Het hoeft niet zo te zijn dat een gehele dataspecificatie daaronder valt. Het kan ook gelden voor delen van een dataspecificatie.

3. Referentie: geen referentie. Deze testregel is niet in alle situaties relevant omdat dit document ook voor specificaties buiten het DSO gebruikt kan worden. Toch is de testregel hier opgenomen omdat ergens bepaald moet worden of een dataspecificatie een rol heeft binnen de context van het DSO.

4. Testtype: Basistest.

1.2 Modelleringsnotatie.

1. Testreden: controle op gebruik van formele taal voor modelleren.

2. Testmethode: Verifieer gebruik van UML, specifiek het UML package- en klassediagram.

3. Referentie: 4.1

4. Testtype: Basistest.

1.3 Metamodel

1.3.1 Metamodel – KKG

1. Testreden: controle op het gebruik van het beschreven metamodel.

2. Testmethode: Verifieer het gebruikte metamodel. De dataspecificatie moet aangeven dat het KKG metamodel wordt gebruikt of een extensie hiervan.

3. Referentie: 4.1

4. Testtype: Basistest.

1.3.2 Metamodel – extensies

1. Testreden: controle of extensies op het metamodel niet in tegenspraak met het metamodel zijn.

2. Testmethode: Verifieer de extensies op het metamodel. Zijn de toegevoegde stereotypen valide niet in tegenspraak met al gedefinieerde stereotypen? Zijn uitbreidingen op stereotypen valide.

3. Referentie: 4.1

4. Testtype: Detailtest.

1.4 Perspectief van modellering.

1. Testreden: controle of model op logisch niveau is gedefinieerd

2. Testmethode: Verifieer het niveau waarop het model is gedefinieerd.

3. Referentie: 4.1

4. Testtype: Basistest.

1.5 Toepassing KKG alternatieven voor associaties in het informatiemodel

1. Testreden: controle of alternatief 2 van KKG wordt gevolgd

2. Testmethode: Zijn de targetrollen van associaties verplicht gebruikt.

3. Referentie: 4.1.1

4. Testtype: Detailtest.

1.6 Naamgeving informatie-elementen

1. Testreden: controle op naamgeving informatie-elementen conform naamgevingsconventie

2. Testmethode: Verifieer of de naamgeving van informatie-elementen, objecttype, attributen, associaties de naamgevingsconventie volgt.

3. Referentie: 4.1.1

4. Testtype: Detailtest.

1.5 Standaard datatypen

1. Testreden: controle op gebruik internationale datatypen.

2. Testmethode: Verifieer of basis datatypen of waardetypen overgenomen zijn van internationale standaarden. Voorbeelden zijn numerieke of alfanumerieke velden, datumvelden, boolean constructies, geometrietypen.

3. Referentie: 4.4

4. Testtype: Detailtest.

1.6 Waardelijst voor geen-waarde informatie is toegepast.

1. Testreden: controle op gebruik van waardelijst om de reden voor het invullen van geen waarde te typeren.

2. Testmethode: Verifieer of de toe te passen waarden conform de opgenomen waardelijst is.

3. Referentie: 4.5

4. Testtype: Detailtest.

6.2 Bijlage 2: Termen en afkortingen

Termen

6.3 Bijlage 3: Referentie implementatie KKG-alternatief 2

Voorbeeld van een UML klassediagram met fictieve informatielelementen. KKG-alternatief 2 wordt hierin gevolgd. De naamgevingsconventie voor alternatief 2 is hier niet toegepast.

6.4 Bijlage 4: Voorbeeld Dataspecificatie template

Deze bijlage beschrijft het template dat gebruikt kan worden voor het opstellen van een dataspecificatie document. Dit template is binnen deze opdracht niet gestandaardiseerd. Er is een voorbeeld template gemaakt dat als input kan dienen voor het verder afstemmen van gebruik door informatiehuizen: Dataspecificatie_Template_DSO.docx. Het voorbeeld is nog niet ontwikkeld voor toepassing van het metamodel KKG.

Bij Geonovum wordt een methode ontwikkeld om de documentatie van geo-standaarden, waaronder dataspecificaties te beheren van uit een github omgeving en op het web te publiceren in HTML.

Meer informatie hier over:

Ontwikkelomgeving: <https: github.com="" geonovum="" respec="" wiki="">

Voorbeeld 1: (hoofdstuk 5 is uit een UML gegenereerde objectcatalogus)

<https: tools.geostandaarden.nl="" respec="" test="" whitepapertest.html="">

Voorbeeld 2: <https: geonovum.github.io="" metadata-iso19115="">

6.5 Bijlage 5: Bibliografie

GIMAReader Module 5 UML.

Gemeenschappelijk Afspraken Berichten, GAB (Federatief overleg beheerorganisaties basisregistraties en standaarden).

Geonovum, iov Ministerie van Infrastructuur en Milieu, 2014. Globaal ontwerp Laaninfrastructuur.

Geonovum, iov Ministerie van Infrastructuur en Milieu, 2015. Globaal ontwerp Gegevensstromen Laaninfrastructuur.

Geonovum, iov Ministerie van Infrastructuur en Milieu, 2015. Globaal ontwerp en prototype stelselcatalogus.

INSPIRE, 2008. Drafting Team "Data Specifications" – deliverable D2.6: Methodology for the development of data specifications.

INSPIRE, 2014. Drafting Team "Data Specifications" – deliverable D2.5: General Conceptual Model.

Kaderstellende notitie, URI-strategie. Versie 1.57 Concept 15-05-2017. Deelprogramma Digitaal Stelsel Omgevingswet.

KING, 2015. Metamodel voor de Referentiemodellen Gemeentelijke Basisgegevens. Versie 0.6.

Metamodel voor informatiemodellen. 2017. KING, Kadaster, Geonovum

NEN 3610: 2011/A1:2016 Basismodel Geo-informatie – Termen, definities relaties en algemene regels voor de uitwisseling van informatie over aan de aarde gerelateerde ruimtelijke objecten.

NEN-ISO/IEC 11404:2008 Information technology – General Purpose Datatypes (GPD)

NEN-EN-ISO 19101-1:2014 Geographic information - Reference model - Part 1: Fundamentals

NEN-EN-ISO 19103:2005 Geographic Information – Conceptual schema language.

NEN-EN-ISO 19105:2005 Geographic information – Conformance and testing

NEN-EN-ISO 19107:2005 Geographic information – Spatial schema

NEN-EN-ISO 19109:2006 Geographic Information – Rules for application schema.

NEN-EN-ISO 19110:2006 Geographic information - Methodology for feature cataloguing.

NEN-EN-ISO 19115-1:2014 Geographic information - Metadata - Part 1: Fundamentals.

NEN-EN-ISO 19117:2014 Geographic information – Portrayal.

NEN-EN-ISO 19126:2009 Geographic information - Feature concept dictionaries and registers.

NEN-EN-ISO 19131:2008 Geographic Information – Data product specifications.

NEN-EN-ISO 19135:2007 Geographic information - Procedures for registration of geographical information items.

NEN-EN-ISO 19136:2009 Geographic information - Geography Markup Language (GML).

NEN-ISO/IEC 19501:2005 Information technology – Open distributed Processing Modelling Language (UML) Version 1.4.2

NPR-CEN/TR 15449-3:2012 Geographic information - Spatial data infrastructures - Part 3: Data centric view

INSPIRE Data Specification Extensions: <http: inspire-extensions.wetransform.to="">

Werkgroep URI-Strategie, 2014. Voorstel URI strategie voor de basisregistraties.
<"http://www.pilod.nl/w/images/1/16/20141009_AdviesURIStrategieBasisregistraties_0.3.pdf">

Werkgroep Best Practices, 2013. Metamodel voor structuurmodellen in (basis)registraties. Whitepaper (Geonovum).