MIM - Metamodel Informatie Modellering

1.1 Toepassingsgebied

Het metamodel biedt de modelleringstaal waarmee een informatiemodel gemaakt, gelezen en begrepen kan worden. Het doel hiervan is:

• de leesbaarheid en eenduidigheid van informatiemodellen te vergroten;
• informatiemodellen op zowel conceptueel als op logisch niveau te kunnen opstellen (zie par. 1.4);
• informatiemodellen goed aan elkaar te kunnen koppelen op conceptueel en logisch niveau;
• tooling te kunnen ontwikkelen en (her)gebruiken voor resp. door alle partijen die kiezen voor dit metamodel;
• kennis uit verschillende organisaties te bundelen;
• en in het verlengde hiervan, om op een meer geautomatiseerde werkwijze sneller en beter voorspelbaar uitwisselingsstandaarden op kunnen stellen. en
• om interoperabiliteit tussen registraties te bevorderen.

Voor informatiemodellen die op basis van dit metamodel zijn beschreven geldt:

• ze zijn eenduidig te interpreteren en goed te vergelijken;
• er kan documentatie mee opgesteld of gegenereerd worden welke geschikt is voor publicatie;
• ze kunnen als basis gebruikt worden voor (bij voorkeur model-driven generatie van) afgeleide modellen en producten voor een specifiek toepassingsgebied/domein zoals bijvoorbeeld NEN3610 of het gemeentelijke domein;
• ze kunnen als basis gebruikt worden voor (bij voorkeur model-driven generatie van) afgeleide modellen voor specifieke services en informatieproducten (implementatieschema’s, registers, validatieservices e.d.).

1.2 Doelgroep

Dit document is primair bestemd voor informatiearchitecten die deze informatiemodellen maken; informatieanalisten die willen weten wat de betekenis en definitie van informatieobjecten is, en mensen die model-driven verder werken op basis van het informatiemodel en er implementaties van maken. Kennis van informatiemodellering is een vereiste. Enige kennis van UML is een pré maar niet noodzakelijk. Dit metamodel richt zich in het bijzonder op de informatievoorziening binnen het overheidsdomein, al is het ook in bredere context inzetbaar.

1.3 Leeswijzer

Het metamodel beschrijven we in drie hoofdstukken en een bijlage.

Lees dit hoofdstuk (1 – Inleiding) verder voor inzicht in wat we onder een informatiemodel en onder een metamodel verstaan, hoe deze de modellen zich verhouden tot UML en de vier lagen metamodel architectuur van de Object Management Group (OMG), en welke standaarden worden toegepast.

Hoofstuk 2 – Metamodel bevat de beschrijving van alle bouwstenen c.q. de modelelementen van het metamodel, in de vorm van definities en specificaties. Ook beschrijft dit hoofdstuk hoe het metamodel zich verhoudt tot het UML metamodel, welke uitbreidingen c.q. verbijzonderingen van het UML metamodel zijn aangebracht. De betekenis en toelichting van de modelelementen van het metamodel vormt het materiaal waarmee een uitputtende modelspecificatie kan worden opgesteld.

In hoofdstuk 3 – ‘Overige afspraken en regels’ gaan we in detail in op een aantal aspecten. Het is een uitgebreidere toelichting, in aanvulling op hoofdstuk 2, bestaande uit nadere afspraken, regels, richtlijnen en aanbevelingen bij het toepassen van het metamodel.

Bijlage 3 verschaft een overzicht van alle bouwstenen en metadata-elementen en het al dan niet van toepassing zijn daarvan in een conceptueel dan wel een logisch informatiemodel.

1.4 Wat is een informatiemodel

Een informatiemodel beschrijft de structuur, semantiek en de eigenschappen van informatie over dingen in de werkelijkheid. Met semantiek wordt de betekenis en definitie van de informatie over ‘het ding’ bedoeld, onafhankelijk van een mogelijke implementatie of toepassingsomgeving. Er worden dus geen regels toegepast die gerelateerd zijn aan de manier waarop de gegevens ingewonnen, opgeslagen, beheerd en uitgewisseld worden. Die beschrijving heeft de vorm van een model dat een gestructureerde weergave is van die werkelijkheid. Een dergelijk model is noodzakelijk om deze informatie te kunnen beheren en gebruiken (door mensen en machines) bij het communiceren over deze werkelijkheid, in registraties^1-1of anderszins, zoals het specificeren van de tussen registraties uit te wisselen gegevens of van de te bevragen informatie uit een registratie.

Het beschrijven vindt plaats door de informatie te modelleren naar objecttypen en de kenmerken daarvan naar attribuutsoorten van die objecttypen en relaties tussen die objecttypen. Alleen dingen en kenmerken die relevant zijn voor een bepaald domein worden in het informatiemodel beschreven, zoals gebouwen binnen het domein Basisregistratie Topografie en personen binnen het domein Basisregistratie Personen. Een domein kan van alles zijn maar in het kader van dit metamodel gaat het om (beleids)sectoren die omwille van bestuurlijke en beheersmatige redenen geïdentificeerd en georganiseerd zijn. Voorbeelden: ruimtelijke ordening, grootschalige topografie, kadastrale informatie of gemeentelijk domein.

Objecttypen in een informatiemodel representeren dingen in de werkelijkheid. De volgende tekst beschrijft hoe dingen in de werkelijkheid zich verhouden tot het informatiemodel. We visualiseren dat in onderstaande figuur voor de situatie dat er een, van het informatiemodel afgeleide, registratie is.

Jan en Katrien zijn bijvoorbeeld ‘dingen in de werkelijkheid’. Zij hebben bepaalde kenmerken, zoals een naam en een geboortedatum. In een informatiemodel komen Jan en Piet niet voor. Ook hun gegevens, zoals het feit dat 10-10-1970 de geboortedatum van Jan is, komt niet voor.

In de context van het informatiemodel worden Jan en Katrien gezien als objecten binnen een domein. In het informatiemodel is het objecttype Persoon gedefinieerd en Jan en Piet zijn dus objecten van het objecttype Persoon.

De kenmerken zoals de naam en geboortedatum maar bijvoorbeeld ook identificatie en registratietijdstip worden gezien als attributen van dit objecttype. We noemen een dergelijk kenmerk een attribuutsoort. Sommige kenmerken, zoals het gegeven dat Jan getrouwd is met Katrien, modelleren we door middel van een relatiesoort tussen objecttypen, in dit geval van Persoon met zichzelf.

In de van het informatiemodel afgeleide registratie kunnen vervolgens de objecten Jan en Katrien en de gegevens ervan, zoals de geboortedatum 10-10-1970, worden vastgelegd.

Als een andere registratie op haar eigen manier tegen dezelfde ‘Jan uit de werkelijkheid’ aankijkt, dan is ook in die registratie een (eigen, apart) object voor Jan aanwezig en Jan kan in dit (eigen, apart) informatiemodel anders gemodelleerd zijn. Beide objecten Jan representeren natuurlijk dezelfde ‘Jan uit de werkelijkheid’, vanuit het perspectief van het eigen domein bekeken.

1.5 Typen informatiemodellen

Zoals hiervoor uiteengezet beschrijft een informatiemodel de werkelijkheid. In de praktijk blijken hier niveaus in te bestaan, variërend van een zo getrouw mogelijke beschrijving van die werkelijkheid tot een specificatie van de wijze van vastlegging van die werkelijkheid in een database of uitwisselformaat. Veelal worden vier niveaus onderscheiden^1-2:

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.

Het voorliggende metamodel kan toegepast worden op twee niveaus, niveau 2 en niveau 3: t.b.v. een zuiver conceptueel informatiemodel (2) en t.b.v. een logisch informatiemodel (3). Het moge duidelijk zijn dat het altijd het één of het ander is. Een combinatie van beide in één model leidt tot verwarring. Voor eenzelfde domein verschilt de structuur van het informatiemodel naar gelang het type en bevat het logisch informatiemodel meer, vooral formele, specificaties dan een conceptueel model. Het is voor de hand liggend maar niet persé noodzakelijk om voor een domein eerst een conceptueel en daarna een logisch informatiemodel op te stellen. Een organisatie kan er voor kiezen om alleen een logisch informatiemodel op te stellen. Een begrippenmodel is in dat geval dringend aanbevolen. Bijlage 3 verschaft een overzicht van de metadata-constructen en -elementen die per type model van toepassing zijn.

Het is van belang om voorafgaand aan het opstellen van een informatiemodel expliciet te bepalen welk van beide typen beoogd is en de modellering conform het gekozen type te doen plaatsvinden. In de beschrijving van het informatiemodel moet vermeld worden om welk van beide typen het gaat. Aan te bevelen is om eerst een conceptueel model op te stellen en dit vervolgens uit te werken naar een logisch model.

1.6 Wat is het metamodel voor informatiemodellen

Een metamodel is een model van een model. Het definieert een verzameling van modelleerconstructies in de vorm van bouwstenen oftewel modelelementen, met bijbehorende betekenis en bijbehorende afspraken omtrent hoe deze toe te passen. Een informatiemodel kan vervolgens hiermee gemaakt worden. Het metamodel is daarmee de modelleertaal waarin een informatiemodel is uitgedrukt. Deze metataal beschrijft als het ware de grammatica en de syntax van de modelleertaal.

Vaak zie je dat het metamodel niet expliciet beschreven is en dat het metamodel een onderdeel van de domeinkennis is geworden. Bij domeinoverstijgende harmonisatie wordt het dan moeilijk om modellen met elkaar te vergelijken en op basis daarvan gegevens uit te wisselen. Beschrijving van het metamodel is daarom een randvoorwaarde indien er sprake is van een stelsel van samenhangende informatiemodellen. Anders gezegd, met (alleen) de in het metamodel opgenomen set van modelleerconstructies worden informatiemodellen gemaakt. Door het schrijven van modelleertalen (zoals UML) in een metataal (zoals MOF) wordt gegarandeerd dat alle toepassingen van die talen op een standaard manier zijn opgebouwd en daardoor alom te begrijpen zijn. De metataal beschrijft als het ware de grammatica van de modelleertaal. Het metamodel in dit document is gebaseerd op UML.

1.7 UML

Voor zowel het metamodel als informatiemodellen wordt uitgegaan van UML. Registraties en afnemers hiervan kunnen deze gebruiken voor de inrichting van hun situatiespecifieke gegevenshuishouding. Belangrijk is dat de lezer eerst begrijpt wat we onder een informatiemodel en een metamodel verstaan en verder is het van belang de modellen in de juiste context te plaatsen. Dit laatste doen we aan de hand van de vier lagen metamodel architectuur van de Object Management Group (OMG). In deze paragaaf gaan we op deze concepten in.

Vier lagen metamodel architectuur OMG Voor de specificatie van het metamodel is gebruik gemaakt van dezelfde formele taal waarin de informatiemodellen zijn beschreven, namelijk UML. Het metamodel van deze informatiemodellen is een uitbreiding op het basale UML-metamodel.

Het basale UML-metamodel is een metamodel dat onderdeel uitmaakt van de vier lagen metamodel architectuur van OMG namelijk M0, M1, M2 en M3. Daarbij is elke laag een instantie van de laag daarboven (met uitzondering van de 1e laag) en maakt de laag gebruik van een in de naast hoger gelegen laag gespecificeerde uitdrukkingsmogelijkheden teneinde een specificatie in een andere context te vormen. De toplaag is de metamodellaag oftewel M3 laag en definieert de basisconstructies, m.a.w. de taal waarin de onderliggende laag is uitgedrukt. Metamodel Meta Object Facility (MOF) is een voorbeeld van deze laag. MOF is de basislaag voor de UML laag. De metamodel laag (M2) is een instantie van de M3 laag. Op deze laag bevindt zich onder meer het metamodel UML. M.a.w. UML is een instantie van MOF. Deze laag is taaltechnisch rijker dan de M3 laag. De M2 laag definieert de semantiek en syntax van de modelconstructies in de M1 laag. De M1 laag is de laag waarop zich het informatiemodel bevindt om een bedrijfscontext modelmatig te beschrijven. Deze M1 laag is een instantie van de M2 laag. Tenslotte is er nog de M0 laag waarop zich de objecten en data bevinden, de instanties van de M1 modelconstructies die een representatie van de concrete werkelijkheid op een specifiek tijdsmoment vormen.

Tabel 1 Vier lagen metamodel OMG

De informatiemodellen waarover we het hier in dit document hebben bevinden zich op de M1-laag.

Dit metamodel is een uitbreiding op het UML metamodel (M2). Het UML metamodel is daarbij uitgebreid met speciale elementen, die geen onderdeel uitmaken van het basale UML-metamodel (M2). Deze nieuwe elementen zijn noodzakelijk voor het definiëren van de semantiek en syntax van de modelconstructies zoals we die in onze informatiemodellen hanteren.

Het UML metamodel (M2) is een ‘read only’ model. Dat wil zeggen dat we geen bestaande metaclass mogen aanpassen en we dus geen nieuw basis metaclass voor een bestaande UML metaclass mogen specificeren. Maar via Profiles (van de InfrastructureLibrary) kunnen bestaande metaclasses uitgebreid worden zonder dat er nieuwe metaclasses gedefinieerd hoeven te worden en dus zonder aanpassing van het basale UML-metamodel (M2). De extensiemechanismen hiervoor zijn stereotypes, tagged values en constraints.

1.8 Een eigen extensie op het metamodel

Indien er extra metamodelconstructies nodig zijn voor een informatiemodel, dan kan dit metamodel uitgebreid worden met een aanvulling oftewel extensie (in de vorm van een extra bijlage) die door de betreffende organisatie toegevoegd wordt aan het onderhavige document.

De spelregel bij een extensie is dat deze geen onderwerpen vervangt die in dit metamodel beschreven zijn, maar alleen echte uitbreidingen behelst. Indien meerdere organisaties hierin geïnteresseerd zijn, kan zo’n extensie ook toegevoegd worden aan dit metamodel. Neem dan contact op met de beheerders (zie voorwoord).

Het is ook mogelijk om in de extensie aan te geven welke elementen uit dit metamodel niet ingezet (mogen) worden in uw informatiemodellen. Denk hierbij bijvoorbeeld aan een bepaald modelelement. Of aan bepaalde metadata aspecten die niet ingewonnen worden in uw informatiemodellen en daarom buiten scope worden geplaatst (ongeacht of deze optioneel of verplicht zijn).

Voor meer informatie over een specifieke extensie kan contact opgenomen worden met de beheerder van deze extensie.

Nota bene: een metamodel extensie is expliciet niet bedoeld voor aanvullende constructies die alleen spelen op het niveau van implementatie, of op het niveau van afgeleide modellen t.b.v. specifieke koppelvlakken en interfaces. Deze vallen buiten scope van dit metamodel en ook buiten scope van extensies hierop. Wel is het mogelijk en toegestaan om het metamodel, of delen ervan, hiervoor te gebruiken.

1.9 Alternatieven

In dit metamodel is op één punt sprake van een keuze tussen twee alternatieven, waarvan de modelleur van een informatiemodel één van beide alternatieven kiest. Welke je kiest geef je aan bij je eigen informatiemodel, in je eigen extensie (zoals bedoeld in de vorige paragraaf).

Dit betreft: Relatiesoort en relatierol, beide te gebruiken, maar welke is verplicht/leidend (paragraaf 2.3.2.1 en 2.3.2.2).

Indien gewenst kunt u hier vragen over stellen aan de beheerders van dit metamodel voordat u een keuze maakt.

1.10 Beheer

Het beheer van dit metamodel vindt plaats als samenwerking tussen KING, het Kadaster modellenbureau en Geonovum. Voor vragen, suggesties of opmerkingen kunt u contact opnemen met:

1.11 Normreferenties

De Stelselcatalogus, het GAB en de Handreiking gegevensbeschrijving raken elkaar op een aantal vlakken maar er kunnen op deze raakvlaken verschillen zijn in de gemaakte afspraken. Voor het metamodel hanteren we daarom de volgende spelregel: de Stelselcatalogus is zoveel als mogelijk leidend, vervolgens het GAB en als laatste de handreiking.

Voetnoten

^1-1:De opname in een registratie kent vaak een inwinningsproces, om gegevenswaarden over de feitelijke dingen in de werkelijkheid conform het informatiemodel in de registratie op te nemen. Dit is een belangrijk proces, maar valt buiten scope van het informatiemodel.

^1-2: Ontleend aan: Model Driven Architecture (MDA) Guide; Object Management Group, rev. 2.0, 1-6-2014

2.1 Structuur metamodel

Deze paragraaf bevat een overzicht van het metamodel en geeft alle modelelementen weer in diagram vorm. De beschrijving van de modelelementen in tekst vorm staan in de volgende paragraaf.

De modelelementen zijn verdeeld over een diagrammen, die elk een eigen view op een deel van het metamodel tonen. Elk view toont een aantal van de modelelementen, inclusief hun onderlinge samenhang. Alle views samen vormen het metamodel als geheel:

• KERN, met de belangrijkste modelelementen in onderlinge samenhang.
• DATATYPEN, met de in het model te onderkennen soorten datatypen.
• OVERIGE modelelementen, die niet altijd aan de orde zijn.

Elk modelelement heeft een KKG metaclass. Deze wordt in UML in een informatiemodel gemodelleerd als een Metaclass van UML 2.5 en een bijbehorende stereotype. Bijvoorbeeld: de KKG metaclass Objecttype wordt gemodelleerd als een UML-Class met stereotype «Objecttype». In Sparx EA wordt dit gemodelleerd met een Class. Niet alle KKG metaclasses hebben een stereotype (nodig). In de kolom staat dan ‘-‘.

In de diagrammen zijn de UML metaclasses conform UML 2.5 aangeduid als UML metaclass. Deze in opgenomen in het diagram als ‘blauw gekleurde’ metaclasses.

2.2 Betekenis modelelementen

In deze paragraaf staan alle modelelementen opgesomd, die gebruikt worden bij het maken van een informatiemodel. Bijna alle hebben een UML-metaclass als basis, deze is dan aangegeven. Dit is ook opgenomen in diagram vorm, in bijlage 3.

2.3 Specificatie metagegevens

Elk modelelement kent een aantal metagegevens, die bepaalde aspecten van het modelelement specificeren. Een aantal daarvan worden gemodelleerd in UML. Deze zijn herkenbaar aan de rode tekst (hiervan worden geen waardes vastgelegd). Een aantal worden als waarde vastgelegd, in tagged value vastgelegd. Deze zijn herkenbaar aan Tagged value. Deze tagged values zijn specifiek voor elk modelelement (als er in H2.2 sprake is van een generalisatie, dan worden deze tagged values niet overerft. De KKG metaclass Union erft geen metagegevens, zoals patroon, van KKG metaclass Datatype).

2.4 Metamodel Tooling

Er is een metamodel profiel gemaakt in Sparx Enterprise Architect, dat gebruikt kan worden bij het modelleren van een informatiemodel. Dit profiel kan je inladen en daarna kan je kiezen uit de metamodel elementen. Het profiel is faciliterend en zorgt dat (de meeste) modelelementen van het informatiemodel automatisch voldoen aan dit metamodel. Het is niet vereist om dit profiel te gebruiken. Het is niet toegestaan om het profiel te wijzigen. Het is wel toegestaan om het profiel uit te breiden, naar de behoefte van de eigen organisatie.

Er is een tool Imvertor, die kan controleren of een informatiemodel voldoet aan dit metamodel en zo niet, wat de reden daarvan is. Deze tool is open source en is te vinden op www.imvertor.org.

Voetnoten

^2-1: In versies voor UML 2.5 heette deze nog UML-attribute.

^2-2: In versies voor UML 2.5 werd de rol nog op UML-associationEnd gedefinieerd.

^2-3: Opmerking: wanneer het datatype Postcode landelijk zodanig beschikbaar is gemaakt zodat hier gebruik van gemaakt kan worden in het model, dan hoeft Postcode niet meer in het eigen model opgenomen te worden.

^2-4: In UML 2.5 heeft een target role een UML-Property waarop isID kan worden gespecificeerd. In Enterprise Architect nog niet. Daarom wordt er tijdelijk gewerkt met dit stereotype. Op termijn komt deze te vervallen.

^2-5: In deze kolom is opgenomen hoe het element in UML2.5 is benoemd. Het betreft veelal overerving van een gegeven van een UML metaclass die niet in dit document is benoemd.

^2-6: Aspect met aanduiding √ is conform stelselafspraken voor basisregistraties. Een * is conform de stelselcatalogus. Die ook de paragraaf in H3 hierover.

^2-7: Rode tekst in de kolom ‘In EA’ betreft een standaard element binnen Sparx EA. Zwarte tekst in de kolom ‘in EA’ betreft uitbreiding op UML Metamodel, via tagged values of aanvullende stereotypes.

^2-8: In (basis) registraties is dit meestal gespecificeerd in een catalogus van objecten en begrippen. Deze opmerking geldt voor elk metadata aspect naam van de andere modelelementen. Indien het modelelement niet voorkomt in een dergelijke catalogus is dan kiest u uiteraard een eigen naam.

^2-9: Deze specificatie is toegevoegd t.o.v. de registratiecatalogus aangezien het hier niet om een registratie gaat maar wel duidelijk moet zijn in welke registratie de (verwijzing naar de) lijst voorkomt (indien van toepassing).

^2-10: Element import wordt in UML ingezet voor het importeren van een NamedElement uit een ander package. In dit metamodel wordt de alias (nog) niet zo gebruikt.

^2-11: Voor toelichting, zie paragraaf 3.11

^2-12: Geef bij overig in uw eigen informatiemodel aan wat u er onder verstaat.

3.1 Datatype(n)

Een datatype is een typering van een eigenschap. Datatypen in een informatiemodel beschrijven de structuur waaraan de data van objecten moet voldoen. De essentie van datatypen is dat ze gaan over de waarden die attribuutsoorten kunnen hebben. Het specificeert de waarden die de attribuutsoort kan aannemen en de vorm waarin deze beschikbaar zijn.

We onderscheiden de volgende soorten gedefinieerde categorieën voor datatypen:

1. Datatypen, primitief: data zoals “Amersfoort” of “10” worden vastgelegd als CharacterString en Integer. Dit volgt de internationale standaarden voor datatypen.
2. Datatypen (met een naam), landelijk volgens het GAB: datatypen zoals Postcode “1234AB”.
3. Gestructureerde datatypen: een combinatie van data, zoals een bedrag “5 euro”, of een GM_Surface. Deze volgen ook internationale of nationale standaarden.

De primitieve datatypen uit onderstaande lijst moeten gebruikt worden. De landelijke en de Gestructureerde datatypen hoeven niet per sé gebruikt te worden, maar het gebruik hiervan wordt wel aanbevolen. Dit metamodel voorziet er vooral in dat dit soort datatypen gedefinieerd kunnen worden, conform de modellering zoals het metamodel aangeeft, maar dus zonder de specifieke datatypen voor te schrijven.

Datatypen die niet in deze paragraaf (sub paragrafen) voor-gedefinieerd zijn worden in het eigen informatiemodel toegevoegd. Dit kan een organisatie zelf doen, door deze expliciet te beschrijven in de eigen extensie en daarna te gebruiken in het eigen informatiemodel. Deze gelden dan alleen voor het eigen informatiemodel.

Het is mogelijk om specifieke(re) restricties, zoals de lengte, toe te voegen. Dit wordt gedaan in een metagegeven lengte. De data van het attribuut moet dan voldoen aan het datatype én aan het metagegeven lengte. De lengte wordt dus niet in het datatype zelf vastgelegd.

3.2 Gestructureerd datatype

Een «Gestructureerd datatype» is veelal specifiek binnen een informatiemodel. Indien mogelijk wordt zoveel mogelijk hergebruik gemaakt van elders gedefinieerde «Gestructureerd datatype»n, denk bijvoorbeeld aan de Gestructureerd datatypen: NEN3610 identificatie (NEN3610), Kadastrale aanduiding (BRK), Objectnummering (BAG) of Labelpositie.

Gewone datatypen staan op zichzelf en worden niet beschreven in termen van een ander datatype. Bij een «Gestructureerd datatype» is dit wel het geval. Het is een gestructureerd datatype dat is samengesteld uit meerdere eigenschappen. Hiermee kunnen meerdere data-elementen, die onlosmakelijk bij elkaar horen, ook bij elkaar gedefinieerd worden.

Bijvoorbeeld een Bedrag, dat bestaat uit een hoeveelheid en een muntsoort. Het aantal zelf is nietszeggend, tenzij ook aangegeven wordt welke muntsoort het betreft.

Elk data-element in een Gestructureerd datatype heeft zelf ook weer een datatype (in zeer bijzondere gevallen kan een data-element zelf ook weer een Gestructureerd datatype zijn).

Gestructureerd datatype representeren als één gegevenselement  

Soms is er de behoefte om een combinatie van gegevens samengesteld te representeren, in één gegevenselement. Dit speelt specifiek bij gestructureerde datatypes, omdat de data-elementen hiervan uniek identificerend zijn voor een object. De samengestelde representatie verandert niets aan de semantische definitie. Om een uniforme samenstelling te waarborgen, wordt er bij het gestructureerde datatype een patroon of een formeel patroon gedefinieerd (dat consistent is met de definities van de data-elementen uit het Gestructureerd datatype). Als een patroon of formeel patroon gedefinieerd is op het gestructureerde datatype (als geheel), dan worden de data-elementen van het gestructureerde datatype altijd als één gegevenselement uitgewisseld. Als dit patroon niet gedefinieerd is, dan worden de data-elementen als losse gegevenselementen uitgewisseld (de standaardwijze voor een Gestructureerd datatype).

Een uitgewerkt voorbeeld van een Gestructureerd datatype met patroon is Objectnummering. Dit Gestructureerd datatype bestaat uit de data elementen:

• Gemeentecode (AN, lengte 4)
• Objecttypecode (AN, lengte 2)
• Nummer (AN, lengte 10) met daarbij een formeel patroon: [0-9]{4}\.[0-9]{2}\.[ 0-9]{10} of een (tekst) patroon Gemeentecode.Objecttypecode.Nummer

3.3 Gegevensgroeptype

Bij het modelleren van een objecttype worden attribuutsoorten toegekend aan een objecttype. Wanneer er geconstateerd wordt dat een aantal attribuutsoorten logisch gezien bij elkaar horen, dan kan er gekozen worden om deze onder te brengen in een gegevensgroeptype. Het blijven dan attributen van het objecttype. De definitie van elk afzonderlijk attribuutsoort verandert niet door de groepering.

Richtlijn: een gegevensgroeptype bevat alleen «Attribuutsoort»en en geen «Relatiesoort»en. Als er wel een relatie aan de orde is, dan wordt de gegevensgroep gezien als een apart te beheren object. Er wordt dan een apart «Objecttype» gemaakt. Het is wel mogelijk, hoewel uitzonderlijk, om binnen een gegevensgroeptype nog een ander gegevensgroeptype te modelleren.

3.4 Keuze tussen datatypes (Union)

Wanneer het datatype van een attribuutsoort een keuze uit twee of meer datatypen is, dan wordt dit gemodelleerd met het datatype Union. Elk union element van de union heeft dan één datatype, de waarde van de attribuutsoort moet aan één van deze datatypen voldoen.

Voorbeeld: Attribuutsoort geometrie met als type de Union PuntOfVlak. PuntOfVlak is daarbij een Union met union element: punt, met als type het datatype GM_Point en union element vlak met als type het datatype GM_Surface.

In dit voorbeeld is er enkel een keuze tussen verschillende union elementen die zelf geen betekenisvolle context geven aan het te kiezen datatype. Er wordt in dit geval geen definitie gespecificeerd bij het union element (de definitie is optioneel).

In onderstaande voorbeelden is er wel sprake van een keuze tussen union elementen die een betekenisvolle context geven aan het te kiezen datatype. Er wordt in dit geval wel een definitie gespecificeerd bij het union element.

Voorbeeld: Attribuutsoort hoogte met als type de Union BereikOfWaarde. BereikOfWaarde is daarbij een Union met union element ‘bereik’, met als type het datatype Interval en union element ‘waarde’ met als type het datatype Real.

Regel: het is niet toegestaan dat union elementen binnen één en dezelfde union identiek zijn. De naam van elk union element moet verschillend zijn én de datatypen moeten op zijn minst verschillend zijn. Dus ofwel een ander datatype, ofwel hetzelfde datatype met een verschil in het metadata aspect patroon en/of formeel patroon hebben. Bijvoorbeeld: een keuze tussen een datatype CharacterString en een datatype CharacterString is alleen toegestaan als er een verschillend (formeel) patroon is gespecificeerd.

Merk op dat het mogelijk is om een eigen datatype te maken met een eigen naam en deze te gebruiken in een union element.

Wanneer een beoogd datatype uit een extern model komt en daar geen metamodel stereotype heeft, zoals bijvoorbeeld het geval is bij het GM package waarin een datatype als «interface» GM_Point is opgenomen, dan heeft dit datatype niet een KKG stereotype en mogelijk ook niet de UML-metaclass dataType. Het is dan aan de modelleur van het informatiemodel om te beoordelen of het type dan als datatype gebruikt kan worden. Het is niet gewenst om aan het externe model een stereotype toe te voegen, noch om in het externe model de UML-metaclass aan te passen.

3.5 Domeinwaarden of lijsten

In veel registraties wordt gewerkt met codetabellen om de mogelijke waarden van een attribuutsoort te specificeren. Deze mogelijke waarden kunnen op verschillende manieren worden opgenomen, afhankelijk van de gewenste stabiliteit:

Enumeraties. Dit zijn statische lijsten, waaruit één waarde gekozen kan worden. De registratie en bijbehorende koppelvlakken kunnen erop vertrouwen dat er geen nieuwe waardes worden toegevoegd. Als er een nieuwe waarde bij komt wordt dit via een modelwijziging doorgevoerd. Dit wordt vooral toegepast bij lijsten die niet of weinig veranderen. Zo is bij het attribuutsoort Naamgebruik een enumeratie naamgebruik opgenomen met als waarden onder meer ‘eigen’ en ‘eigen, partner’.

Als sprake is van dynamiek in de domeinwaarden wordt een Referentielijst of Codelist gebruikt. Dit betreft de situaties waarin domeinwaarden kunnen veranderen en/of het aantal domeinwaarden kan toe- of afnemen. De registratie en bijbehorende koppelvlakken worden dan ingericht om hier mee om te gaan. Dit wordt vooral toegepast bij lijsten die vaker aan verandering onderhevig zijn.

Referentielijst. Een lijst waarin we de betekenis en structuur van de lijst expliciet willen specificeren. Een voorbeeld is de referentielijst LAND of CultuurcodeOnbebouwd
( http://www.kadaster.nl/schemas/waardelijsten/CultuurcodeOnbebouwd ).

De referentielijst is hiermee een bijzondere vorm van datatype.

De naamgeving Referentielijst kan verwarring oproepen maar in principe wordt altijd gerefereerd naar gegevens m.b.t. één rij uit de referentielijst. In het geval van de referentielijst LAND wordt altijd gerefereerd naar gegevens over Nederland (NL) of gegevens over Duitsland.

Let op, wanneer er voor een bepaald attribuut in een informatiemodel of koppelvlak van een andere organisatie gekozen is voor een referentielijst, en uw organisatie koppelt hiermee, dan is het (meestal) onverstandig om in het eigen informatiemodel dit te behandelen als enumeratie.

Modelleerrichtlijn: elk attribuut van een object heeft een specifieke lijst met toegestane waarden. Modelleer daarom elke waardelijst bij voorkeur specifiek, met een eigen naam en locatie. Het is mogelijk dat de structuur van de data gelijk is voor een aantal lijsten. Er kan dan een generieke structuur gemodelleerd worden, bv. een abstracte referentielijst met naam _Waardelijst, waarvan de specifieke waardelijsten overerven. Het metagegeven locatie is immers specifiek voor één waardelijst en moet per individuele waardelijst vastgelegd worden.

CodeList Gebruik een codelist als in het informatiemodel de attributen, zoals bij een referentielijst, niet relevant zijn en je voor de definitie alleen wilt verwijzen naar de externe waardelijst.

Waardenbereik en patroon In plaats van een opsomming van alle mogelijke waarden via een enumeratie of referentielijst leggen we soms voor een attribuut (attribuutsoort, referentie element, data element of union element) alleen het waardenbereik vast door middel van een patroon. Bijvoorbeeld bij een postcode, of een gemeentecode die moet bestaan uit precies 4 getallen, waarbij het eerste getal een 0 mag zijn. Er wordt met een patroon expliciet niet een Enumeratie bedoeld. Het betreft een andersoortige, meer open beschrijving van welke waarden toegestaan zijn voor een attribuutsoort.

We onderkennen twee soorten patronen:

• Patroon: het metagegeven (de tagged value) ‘Patroon’ in tekst vorm. Deze wordt als aanvulling op het datatype (bijvoorbeeld Integer ) van het attribuut gespecificeerd. Het patroon bevat een specificatie waaraan een waarde moet voldoen. Bijvoorbeeld een postcode, met als aanduiding van het patroon: Postcode. De toegestane waarden voor deze patroon aanduiding worden dan vastgelegd in documentatie behorende bij het type: alle postcodes van 1000AA tot en met 9999ZZ.
• Formeel patroon: het metagegeven (de tagged value) ‘Formeel patroon’ in formele specificatie vorm [H1.11, referentie 6], te weten in een reguliere expressie. Bijvoorbeeld een postcode, met de expressie: \d{4}[A-Z]{2}

Een voorbeeld waar een patroon nodig is, is een attribuut waarvan het waardenbereik altijd een getal is met precies de lengte 4, zoals bijvoorbeeld 0001 tot en met 9999, en dus voorloopnullen heeft. Een datatype zoals Integer kan hiervoor niet gebruikt worden, omdat 0001 geen getal is. Het type van het attribuut wordt in dat geval een CharacterString, met lengte (exact) =4 en het patroon voor het attribuut specificeert dat alleen numerieke getallen zijn toegestaan: [0-9]{4}.

3.6 Abstracte objecttypes en concrete objecten

Een objecttype kan aangeduid worden als een abstract objecttype (zie paragraaf 2.3.1. door middel van indAbstract = J). Het betreft dan altijd een generalisatie waarbij de specialisaties van dit objecttype op het laagste niveau concrete objecttypen worden genoemd. Het is belangrijk te weten wanneer een objecttype als abstract objecttype in een informatiemodel is te onderkennen. Omdat een abstract objecttype altijd een generalisatie is, beantwoorden we in deze paragraaf ook de vraag wanneer we specialisaties / generalisaties onderkennen in een conceptueel informatiemodel en in een logisch informatiemodel

Conceptueel informatiemodel

Specialisatie / generalisatie Bovenstaande vragen beantwoorden we aan de hand van een voorbeeld: het opleidingsinstituut.  In de beschouwde werkelijkheid onderscheiden we onder meer als gespreksonderwerp personen. Deze personen kunnen docenten en leerlingen zijn. Over al deze gespreksonderwerpen willen we gegevens communiceren. Een docent heeft als kenmerk dat deze een arbeidscontract met het opleidingsinstituut heeft afgesloten en een lesbevoegdheid heeft, terwijl een leerling kenbaar heeft gemaakt lessen te willen gaan volgen bij het instituut en dus geen arbeidscontract heeft afgesloten. Docenten en leerlingen zijn personen die rechten en plichten hebben.

Docent is een specialisatie (‘subtype’) van het objecttype Persoon en Leerling is een specialisatie van het objecttype Persoon. Een specialisatie ontstaat derhalve doordat aan een object van een bepaald type speciale eisen wordt gesteld. Vice versa spreken we er van dat Persoon een generalisatie is van Docent en Leerling. Op onderdelen vertonen de onderscheiden objecttypen Docent en Leerling hetzelfde gedrag waarbij dat gedrag essentieel van belang is voor het te beschouwen domein en daarmee het conceptuele informatiemodel.

Abstract / concreet Wanneer er vanuit wordt gegaan dat binnen het te beschouwen gebied een persoon altijd ofwel een docent ofwel leerling kan zijn (en nooit beide tegelijk) dan definiëren we een Persoon als een abstract objecttype. Docent en Leerling zijn dan concrete objecttypen in het conceptueel informatiemodel.

Een concreet object kan zich alleen in de hoedanigheid als één van de specialisaties van het abstracte objecttype op het laagste niveau voordoen. En daarmee dus ook in de hoedanigheid van de generalisatie(s) van het concrete objecttype.

Richtlijnen

• Een abstract object is een onderwerp van gesprek binnen het beschouwde gebied. Het heeft dus echt een betekenis ^3-1 in het beschouwde gebied. Net als een concreet object, specialisatie of generalisatie.
• De definitie van elk objecttype (dus ook een abstract objecttype) is zodanig dat ondubbelzinnig bepaald kan worden dat een object wel of niet tot het gedefinieerde type behoort. Dus niet een objecttype met een definitie als ‘De gemeenschappelijke eigenschappen van een object…’ Deze definitie is op elk objecttype van toepassing.
• Houd er rekening mee dat afhankelijk van het te beschouwen gebied een object uit de werkelijkheid in het ene informatiemodel een concreet objecttype kan zijn en in het andere informatiemodel een abstract objecttype.

Logisch informatiemodel In een logisch model gelden in principe dezelfde regels voor abstracte of concrete objecttypen. De abstracte objecten worden daarom in principe overgenomen. In een logisch model wordt het digitale model van de werkelijkheid beschreven. Vanuit dit oogpunt kunnen er ook andere redenen zijn om abstracte objecttypen te creëren, bijvoorbeeld omdat een abstract object positieve effecten heeft voor de implementatie. Denk hierbij aan het aanbrengen van (extra) hiërarchie,zowel in semantiek als in ordening van eigenschappen. De enige regel die geldt is dat een abstract objecttype niet geïnstantieerd kan worden. Elk object is altijd een instantie van een concreet objecttype.

Algemeen

• In UML wordt een abstract objecttype aangeduid door indAbstract met waarde “J” en wordt de naam van het abstracte objecttype cursief geschreven (voorbeeld: Persoon).
• Een objecttype dat een generalisatie-relatie heeft naar een al dan niet abstract objecttype noemen we een specialisatie (van dat objecttype). Wanneer de generalisatie een abstract objecttype is, kan de specialisatie zelf ook abstract zijn en specialisaties hebben. De ‘onderste’ specialisaties zijn dan altijd concreet (niet abstract)
• Modelleer een abstract objecttype pas wanneer er sprake is van twee of meer specialisaties
• De unieke aanduiding kan opgenomen worden in het abstracte objecttype. De unieke aanduiding geldt dan voor elke specialisatie van het abstract objecttype. Dit betekent dat de unieke aanduiding uniek is binnen de verzameling van alle objecten die als specialisatie onder het abstracte objecttype vallen. Anders gezegd, de unieke aanduiding geldt voor alle concrete objecten die als objecttype de unieke aanduiding erven van het abstracte objecttype. Bijvoorbeeld: als de unieke aanduiding van _Kadastraal object het attribuutsoort Identificatie is en _Kadastraal Object als specialisatie een Perceel kent en een Leidingnetwerk, dan kan het niet zo zijn dat er een perceel object is met identificatie ‘1’ en een leidingnetwerk met identificatie ‘1’. Als dat wel het geval is, dan moet op beide concrete objecttypes een eigen unieke aanduiding gedefinieerd worden.

3.7 Relatieklasse (uitzonderingen)

De gegevens van de relatiesoort worden altijd voor één relatiesoort vastgelegd. Het is echter mogelijk dat dezelfde gegevens voor meerdere relaties tegelijk gelden. Het is dan niet mogelijk om het te modelleren als relatieklasse. Wel gewenst, maar het kan niet als UML-associationClass. Als deze uitzondering het geval is, dan worden de relatieklasses gemodelleerd als «Objecttype», met één inkomende relatie en één uitgaande relatie. De oorspronkelijke kardinaliteit van de beoogde relatieklasse wordt hierbij behouden.

Een Perceel kan vanwege een Perceel splitsing overgaan in twee of meerdere andere Percelen. De ‘overgegaan in’ relatie wordt bijgehouden in een relatieklasse. Gegevens over de splitsing zijn voor al deze relaties gelijk.

Het metamodel ondersteunt (nog) geen relatieklassen tussen drie of meer objecttypen. Dit kan in uw eigen extensie toegevoegd worden.

Bijvoorbeeld: een CONTRACT kan bijvoorbeeld ook een afspraak zijn tussen twee óf méér SUBJECTen, waarbij de gegevens van de relatie voor alle betrokken objecten hetzelfde zijn. CONTRACT wordt dan gemodelleerd als objecttype, waarbij beschreven wordt wat er moet gebeuren wanneer één van de SUBJECTen niet meer bestaat.

3.8 Constraint

Deze paragraaf gaat dieper in op hoe een Constraint toegepast wordt.

Een Constraint wordt beschreven met een:

• Naam (UML-constraint name): een naam c.q. label, vaak in steekwoorden.
• Specificatie in tekst (UML-Constraint Notes, type invariant): een uitgebreide heldere beschrijving van de constraint in gewone tekst.

en optioneel:

• Specificatie formeel (UML-Constraint Notes, type OCL): formele specificatie in de Object Constraint Language. De formele specificatie bevat dus de uitgebreide heldere beschrijving van de constraint in gewone tekst EN de formele specificatie in OCL.

Twee constraints die gedefinieerd zijn op hetzelfde modelelement mogen niet dezelfde naam hebben.

In Enterprise architect 12.x lijkt het helaas (nog) niet mogelijk om constraints zoals bedoeld in UML op te nemen, te weten als OpaqueExpression met een constraint string en een aanduiding van de taal: natuurlijke taal, of OCL (of een andere zoals Java, maar deze wordt niet toegepast in dit metamodel). EA werkt met UML Notes en een constraint type. Het is daarnaast niet mogelijk om de tekst en de OCL in dezelfde constraint op te nemen. Het worden dan twee aparte constraints, 1 met tekst en 1 met OCL, met verplicht ook een andere naam. Vandaar onderstaande aanpak:

Als de modelleur kiest om de constraint alleen in gewone taal te beschrijven, dan als volgt:

• Naam (UML-constraint name): een naam c.q. label, vaak in steekwoorden.
• Specificatie in tekst (UML-Constraint Notes, type invariant): een uitgebreide heldere beschrijving van de constraint in gewone tekst.

Als de modelleur kiest om de constraint niet alleen in gewone taal te beschrijven, maar ook in een formele taal (OCL), dan als volgt:

• Naam (UML-constraint name): een naam c.q. label, vaak in steekwoorden.
• Specificatie formeel (UML-Constraint Notes, type OCL): formele specificatie in de object constraint language (OCL). De uitgebreide heldere beschrijving van de constraint in gewone tekst wordt opgenomen als commentaar, tussen /* */.

Aanbeveling: als een eigenschap van één UML-attribute, of één UML-association met een patroon (zie patroon) of een lengte (zie metadata aspect) of een kardinaliteit van een relatiesoort vastgelegd kan worden, gebruik dan deze en geen UML-constraint. Als er sprake is van een eigenschap die over meerdere informatiemodelelementen heen gaat, dan is er altijd sprake van een regel die we modelleren met een UML-constraint.

Aanbeveling: wees terughoudend met het gebruik van constraints in het informatiemodel wanneer de kans reëel is dat het model hierdoor gaat wijzigen of als het niet direct over de semantiek, structuur of syntax van de te registreren gegevens gaat. Dit is bijvoorbeeld het geval wanneer er regels bestaan rondom informatie die elke paar jaar kan wijzigen, of die per toepassingsgebied (net) anders toegepast moet worden. Bijvoorbeeld: wanneer een persoon 65 jaar of ouder is, mag deze geen uitkering aanvragen. Wanneer er veel van zulke constraints in het informatiemodel worden opgenomen, zal dit leiden tot een ongewenste dynamiek waardoor er (te) vaak nieuwe versies moeten worden uitgebracht. De aanbeveling is om de specificatie van dergelijke constraints buiten het informatiemodel te specificeren, bijvoorbeeld als validatieregel.

3.9 Historie

Deze paragraaf geeft in meer detail aan wat we onder de metagegevens Indicatie materiële historie en Indicatie formele historie verstaan.

Aanvullend beschrijft deze paragaaf een aantal aspecten waar rekening mee gehouden kan worden bij de uitwerking van historie in een informatiemodel op logisch niveau. Let wel, historie is niet gestandaardiseerd over logische informatiemodellen van registraties heen. Hoe historie in een logisch informatiemodel wordt gemodelleerd is aan de opsteller van het logisch informatiemodel zelf. In deze paragraaf wordt wel iets verteld over historie op logisch niveau maar dat is niet bindend!

Algemeen Het aspect tijd speelt een belangrijke rol in (basis)registraties. Daarnaast speelt tijd ook een belangrijke rol in het gebruik van de informatie uit (basis)registraties. Afnemers hebben eigen rechtsprocedures en moeten kunnen herleiden wanneer een gegeven als bekend mocht worden verondersteld. Als bijvoorbeeld besluiten ter discussie worden gesteld, is het juridisch van belang te achterhalen op basis van welke gegevens zo’n besluit is genomen. Als onjuiste gegevens zijn gebruikt, is het relevant te weten of het juiste gegeven tijdens de besluitvorming al bekend waren.

Dit betekent dus dat bekend moet zijn wat de waarde van een attribuut op een bepaald moment is.

Tijdslijnen Er spelen twee tijdslijnen een rol bij het herleiden van attribuutwaarden:

• Wanneer is iets gebeurd, in de werkelijkheid of volgens opgave (wanneer zijn de opgenomen gegevens geldig)? Dit valt binnen de tijdlijn van de aangehouden werkelijkheid.
• Vanaf wanneer wist de overheid (als collectief van organisaties) dat de gegevens bekend waren? Dit valt binnen de tijdlijn van het administratieproces of de administratieve werkelijkheid.

In de rapportage 'Architectuur van het stelsel' (Stroomlijning BasisGegevens, 2006) wordt geadviseerd om beide tijdslijnen te registreren, om de attribuutwaarden van een bepaald moment te kunnen reconstrueren. In de diverse registraties wordt hieraan op verschillende wijzen invulling gegeven. Dit metamodel schrijft derhalve niet voor welke bij de tijdslijnen behorende attributen gebruikt moeten worden voor het vastleggen van historie.

Historie op conceptueel niveau Op conceptueel niveau is het wel altijd mogelijk om aan te geven dát het bijhouden van historie aan de orde is voor een (elk) gegeven, dat wil zeggen een attribuut of relatie van een object, te weten via een metagegeven. Deze metagegevens specificeren we als volgt:

• Indicatie materiële historie: indicatie of de materiële historie van de attribuutsoort te bevragen is. Materiële historie geeft aan wanneer een verandering is opgetreden in de werkelijkheid die heeft geleid tot verandering van de attribuutwaarde. Materiële historie impliceert dat actuele, historische en eventuele toekomstige attribuutwaarden te bevragen zijn.
• Indicatie formele historie: indicatie of de formele historie van de attribuutsoort te bevragen is. Formele historie geeft aan wanneer in de administratie een verandering is verwerkt van de attribuutwaarde (wanneer was de verandering bekend en is deze verwerkt).

Voorbeelden: ‘bouwjaar pand’ heeft al materiële historie in zich: het bouwjaar is het moment waarop de wijziging in de werkelijkheid zich voordeed en wijzigt niet. De ‘indicatie materiële historie’ ervan is daarom Nee. BSN van een Persoon geldt voor de persoon vanaf het moment dat de persoon in de BRP is opgenomen en wijzigt niet: ‘indicatie materiële historie’ Nee. De Achternaam van een persoon kan wijzigen: ‘indicatie materiële historie’ Ja. Als je niet toeziet op het daadwerkelijk kappen van een boom maar het gekapt zijn wel in een registratie wil opnemen: ‘indicatie materiële historie’ Nee en ‘indicatie formele historie’ Ja.

Richtlijn: op conceptueel niveau worden voor historie alléén indicatie materiële historie en indicatie formele historie bij een attribuut of relatie vastgelegd, en dus géén bij de tijdslijnen behorende attributen die gebruikt moeten worden voor het vastleggen van historie. Deze bij de tijdslijn behorende attributen worden op het logische niveau vastgelegd.

Historie op logisch niveau KKG schrijft^3-2 geen implementatie van het conceptuele niveau voor. Wel worden er aandachtspunten gegeven om rekening mee te houden. Denk bij de uitwerking o.a. aan de volgende aspecten:

• Het bijhouden van historie met specifieke attributen per objecttype, zoals bijvoorbeeld: bouwjaar pand, of met generieke tijdslijnattributen attributen die gelden voor alle objecttypes, zoals begindatum geldigheid. Denk aan de attribuutsoort en/of gegevensgroeptype (herbruikbaar);
• historie bijhouden per attribuut (en relatie) of per versie van een object. Bij deze laatste kan de gegevensgroep gekoppeld worden aan bijvoorbeeld elk objecttype;
• de status transities die een object in zijn levenscyclus doorloopt. Er kan ook gekozen worden om deze in een conceptueel informatiemodel op te nemen, als ze op dat niveau al van belang zijn;
• status attributen, die iets zeggen over gegevens, zoals attributen die aangeven wel of niet beschouwd moet worden als onderdeel van de geldige gegevens van een object. Er kan ook gekozen worden om deze in een conceptueel informatiemodel op te nemen, als ze op dat niveau al van belang zijn. Voorbeeld: BAG inactief. Het kan ook van belang zijn om aan te geven dat een gegeven niet terug te vinden is in een brondocument (omdat er fouten zijn gemaakt bij de verwerking), maar niet verwijderd kan worden omdat alle gegevens, ook foutieve, bestendig moeten worden bewaard. Voorbeeld: BAG indicatieNietBAG.

Aanbeveling: het komt voor dat er binnen één domein, van één conceptueel informatiemodel, meerdere logische informatiemodellen worden uitgewerkt. Het is dan aan te beleven om centrale implementatie afspraken op te stellen, welke gelden voor elk logisch informatiemodel. Dit speelt met name rondom historie, omdat het vaak ongewenst (en erg Gestructureerdof zelfs onmogelijk) is om verschillende implementaties naast elkaar in stand te houden en naar elkaar te vertalen.

Opmerking: de metagegevens Indicatie materiële historie en Indicatie formele mogen worden opgenomen in een logisch model (of worden overgenomen van het conceptuele naar het logische informatiemodel).

3.10 Afleidbare gegevens

In een informatiemodel kan de behoefte bestaan om afgeleide gegevens op te nemen: dit zijn gegevens die afleidbaar zijn uit andere attribuut- en/of relatiesoorten binnen het informatiemodel. Dit lijkt op redundantie. Toch hebben we deze gegevens daar opgenomen waar er ten eerste vraag is naar het afgeleide gegeven en ten tweede het gegeven niet eenvoudig af te leiden is (er moet sprake zijn van enige mate van complexiteit). Dit wordt in UML weergegeven via isDerived. Zie ook Attribuutsoort, §2.4.2 – is afleidbaar.

Voorbeeld is de 'Datum vestiging in Nederland' van een Ingeschreven persoon. De afleiding van dit gegeven is niet triviaal. Door het als afleidbaar gegeven op te nemen kan het opgevraagd worden zonder dat de historie of andere gegevens van het object opgevraagd hoeven te worden om daaruit dit gegeven af te leiden.

3.11 Authentieke gegevens

Bij een attribuutsoort of relatiesoort wordt als metagegeven ‘Authentiek’ opgenomen. Het is een aanduiding of een attribuutsoort of een als relatiesoort gemodelleerd landelijk basisgegeven in de catalogus van de desbetreffende registratie een authentiek gegeven betreft. Een authentiek gegeven is van hoogwaardige kwaliteit en kan zonder nader onderzoek bij de uitvoering van publiekrechtelijke taken worden gebruikt.

De specificatie van de waarde van het metagegeven is gebaseerd op het onderscheid in de volgende groepen van gegevens:

• Landelijke registraties met authentieke en niet-authentieke basisgegevens (BAG, BRK, BRP, BGT e.d.);
• Landelijke sector- en domein-overstijgende informatiemodellen (IMGeo e.d.);
• Gemeentelijke sector- en domein-overstijgende informatiemodellen (RSGB, RGBZ, ZTC);
• Sector- en domein-specifieke informatiemodellen (LV-WOZ, IMRO e.d.).

3.12 Mogelijk geen waarde

Een attribuut kan geen waarde hebben, omdat de waarde optioneel is en er niet is. Bijvoorbeeld bij een tussenvoegsel van een achternaam. Maar een attribuut kan ook mogelijk geen waarde hebben, omdat de waarde niet bekend is. Dat er geen waarde bij een attribuut geregistreerd is, wil dus niet zeggen dat er geen betekenis aan gehecht kan worden. Zo kan het niet hebben van een waarde van de overlijdensdatum van een persoon betekenen dat deze persoon nog leeft. Maar het kan ook betekenen dat de persoon overleden is maar de datum waarop deze persoon overleden is, niet bekend is.

Dit verschil is niet vast te leggen zonder onderscheid te maken en vaak is het ook van belang om de reden waarom de waarde niet bekend is vast te leggen. Een verplicht veld optioneel maken is daarom niet de juiste oplossing. In die situaties waarin het hebben van geen waarde van een attribuut een betekenis kan hebben maken we gebruik van het metagegeven ‘Mogelijk geen waarde’. Dit metagegeven geeft op informatiemodelniveau aan dat het attribuut een gangbare waarde kan hebben, maar dat deze waarde ook niet bekend kan zijn.

Bij de daadwerkelijke registratie kan het zo zijn dat:

• De waarde van het attribuut bekend is, te weten een waarde bij een verplicht attribuut, of geen waarde bij een optioneel attribuut.
• De waarde van het attribuut onbekend is, en niet meer kan worden achterhaald.
• De waarde van het attribuut onbekend is, en mogelijk wel nog kan worden achterhaald.

Wat de toegestane redenen zijn voor een specifiek attribuut, is aan de beheerder van het informatiemodel. Het is nuttig om de redenen te beperken op informatiemodelniveau. Dit kan dan vastgelegd worden bij de attribuutsoort of bij relatiesoort zelf, bijvoorbeeld in de UML notes. In de registratie mogen dan alleen deze redenen worden geregistreerd.

Een attribuut dat in de werkelijkheid gewoon geen waarde kan hebben en waar bovenstaand onderscheid niet van toepassing is duiden we niet aan met dit metagegeven. Het betreft dan gewoon een optioneel attribuut dat niet is gevuld. Anders gezegd, het is bekend dat het attribuut niet gevuld is en het hebben van geen waarde heeft dan geen verdere betekenis .

Ook een relatiesoort of compositie relatie kan mogelijk geen waarde hebben waaraan betekenis gehecht kan worden en ook daar maken we gebruik van het metagegeven ‘Mogelijk geen waarde’.

In de registraties komen we hier en daar enumeraties tegen waarin de waarde ‘onbekend’ is opgenomen. Bijvoorbeeld de geslachtsaanduiding van een natuurlijk persoon. De enumeratie bestaat uit de waarden man, vrouw en onbekend. In dit metamodel stellen we dat dit niet mag c.q. niet de bedoeling is bij de modellering van eigen gegevens in een eigen informatiemodel. Uitzondering is wanneer het een situatie betreft waarin gegevens worden overgenomen uit een registratie die wel de waarde ‘onbekend’ gebruikt. Dan kan er ook gekozen worden voor het 1:1 overgenomen van de gegevensdefinitie uit deze andere registratie.

3.13 Externe schema’s (her) gebruiken

In bepaalde situaties is het mogelijk dat een ander informatiemodel al één op één de specificaties in UML bevat die relevant zijn voor het eigen informatiemodel. Dit is in het bijzonder het geval als het andere informatiemodel ook dit metamodel volgt, maar kan ook het geval zijn bij gestandaardiseerde datatypes.
Het is dan wenselijk om hiernaar te kunnen verwijzen. Dit kan door deze packages over te nemen naar de eigen UML tool en het stereotype «extern» toe te kennen. Deze packages worden dan wel buiten het eigen informatiemodel gehouden. Ze zijn extern aan het eigen model. Het beheer en de definitie vindt dan ook buiten het eigen model plaats.

In deze externe packages die aangeduid worden met het stereotype «extern» zijn de relevante specificaties opgenomen die binnen het informatiemodel hergebruikt worden. Deze specificaties zijn opgesteld door een externe partij die de UML (of ook de XML) schema’s beheert en beschikbaar stelt waarnaar vanuit deze specificaties wordt gerefereerd. De packages bevatten alleen de constructies die ook daadwerkelijk binnen het ‘eigen’ informatiemodel wordt gebruikt.

Voorbeeld: voor het uitwisselen van geografische informatie op basis van NEN3610 is een tweetal externe packages onderkend waarnaar vanuit de ‘eigen’ informatiemodellen kan worden verwezen: NEN3610, of GML3.2

Het is ook mogelijk om binnen een domein of binnen een organisatie een eigen «extern» package te definiëren voor datatypen, om over meerdere informatiemodellen heen hergebruik mogelijk te maken.

Naast het beschikbaar maken van het externe package kan het modelelement uit het externe package gebruikt worden als datatype, maar er kan ook naar verwezen worden via een relatie. Dit laatst wordt nader uitgelegd in de volgende paragraaf.

3.14 Koppelen met ander informatiemodel (externe koppeling)

Bij registraties is het regelmatig noodzakelijk om te verwijzen vanuit het eigen model naar gegevens uit een andere informatiemodel. Denk aan het opnemen van de identificatie van een object uit een andere registratie, of aan het overnemen van een subset van gegevens van een object uit een ander model. Hiervoor zijn de stereotypes «view» en «externe koppeling» bedoeld.

Deze stereotypes zijn alleen van toepassing binnen een informatiemodel in situaties waarbij het ene informatiemodel afhankelijk is van een andere informatiemodel.

Uitgangspunten hierbij zijn dat de definitie van de structuur van gegevens van het andere informatiemodel één op één overgenomen wordt, waarbij expliciet gemaakt wordt welke gegevens tot het eigen model behoren en welke tot het andere model.

Bijvoorbeeld:

In IMKAD zit het objecttype: «Objecttype» Persoon. Hierin zitten de attributen waarvan de basisregistratie Kadaster de gegevens zelf inwint. In IMKAD zit het package: «view» BRP en hierin zit het «Objecttype» GeregistreerdPersoon. Hierin zitten de attributen die de basisregistratie BRP inwint en die het Kadaster overneemt. De relatie overstijgt de registratie, máár het blijft in het eigen informatiemodel. De aard van de relatie is echter anders dan bij een «relatiesoort». Daarom kennen we deze relatie het stereotype «externe koppeling» toe.

Het betreft in de werkelijkheid dezelfde persoon. Zowel Persoon als GeregistreerdPersoon worden als «Objecttype» gezien. Beide objecten zijn sterk aan elkaar gekoppeld. Dit is altijd zo bij dit soort relaties. Daarom is het aggregatietype van deze relatie altijd Composite.

Merk op dat er ook een relatie rechtstreeks naar de BRP gelegd had kunnen worden. Er is dan geen sprake van gegevens uit de BRP die overgenomen zijn in de eigen registratie. Er kan dan volstaan worden met alleen de unieke aanduiding van GeregistreerdPersoon. Dit is de BSN. Dit wordt niet gezien als een «externe koppeling» maar als een referentie.

3.15 Stelselcatalogus en stelselafspraken voor basisregistraties

Dit metamodel ondersteunt de metadata die voorgeschreven wordt voor de stelselcatalogus [H1.11, referentie 3]. Deze paragraaf geeft aan hoe de metadata in dit metamodel zich verhoudt tot die van de stelselcatalogus, zodat deze vanuit uw informatiemodel geleverd kunnen worden aan de stelselcatalogus. Er zijn ook stelselafspraken rondom metadata. Een metadata aspect in H2.4 met aanduiding √ is conform stelselafspraken voor basisregistraties. Beide gelden.

De metadata voor de stelselcatalogus en de metadata voor de stelselafspraken zijn beide verplicht voor basisregistraties. Als het informatiemodel géén basisregistratie is, kan je als organisatie zelf kiezen om (een aantal van) deze metadata buiten scope te plaatsen. Dit doe je in de eigen extensie, zoals beschreven in paragraf 1.8. De rest van deze paragraaf gaat alleen nog in op de metadata voor de stelselcatalogus.

Het metamodel gaat als volgt met de metadata van de stelselcatalogus om:

• Dit metamodel beschrijft de stelselcatalogus metadata alleen voor de metadata die op informatiemodel niveau speelt, niet de overige metadata.
• Dit metamodel neemt stelselcatalogus metadata altijd op met dezelfde semantiek/betekenis. Als de betekenis van metadata anders is, dan wordt ook niet dezelfde naam gebruikt. Als de betekenis gelijk is, dan kan het wel zo zijn dat dit metamodel een andere naam hanteert. De vertaling wordt hieronder weergegeven.
• Als de semantiek hetzelfde is, maar het waardenbereik van het gegeven is in dit metamodel een verdere verbijzondering (niet in strijd met) dan hanteert dit metamodel dezelfde metadata en geeft aan hoe de waarde in dit metamodel te vertalen naar de waarde in de stelselcatalogus. Bij automatische verwerking naar de stelselcatalogus is het wellicht dus soms nodig deze waardes om te zetten.

Waardenbereik afspraken

• Authentiek: als in dit metamodel ‘Authentiek’ (zie 2.4.21) dan ‘Ja’ in stelselcatalogus, anders Nee.
• Herkomst: Zelf in te vullen. Afspraken hierbij:
  Als zelf ingewonnen: noem de inwinnende organisatie. Bijvoorbeeld: KING of Gemeentes.
  Als overgenomen uit andere bron, noem de directe bron. Bijvoorbeeld: BAG.
• Relatie: dit is geen metagegeven in dit metamodel, maar een stereotype. Deze is wel af te leiden uit het metagegeven van relatiesoort: gerelateerd objecttype (de target van de relatie).

3.16 Naamgevingsconventies

Naamgevingsconventies zijn belangrijk om te specificeren. Onderstaande beschrijft enkele punten die op het niveau van dit metamodel zijn afgesproken. De verdere invulling van de naamgevingsconventies is aan de opsteller van het informatiemodel zelf (zie ook bijlage 1).

4.1 Bijlage I: Overzicht toegepaste UML metaclasses

4.2 Bijlage II: Modelelementen en metagegevens als diagram

Deze bijlage bevat alle modelelementen en metagegevens in één diagram.

Kern - Relatiesoort is leidend (zie 3.2.3.1)

Kern - Relatierol is leidend (zie 2.3.2.2)

Datatypen

4.3 Bijlage III: Template naamgeving conventies