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 VNG Realisatie, 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 MIM metaclass. Deze wordt in UML in een informatiemodel gemodelleerd als een Metaclass van UML 2.5 en een bijbehorende stereotype. Bijvoorbeeld: de MIM metaclass Objecttype wordt gemodelleerd als een UML-Class met stereotype «Objecttype». In Sparx EA wordt dit gemodelleerd met een Class. Niet alle MIM 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.

Er zijn verschillende modelelementen die gebaseerd zijn op UML-Class, zoals
aangegeven in §2.1. Wanneer een UML-Class in het informatiemodel gelezen
moet worden als een objecttype, dan krijgt deze het stereotype «Objecttype».

Een objecttype is een groep van gelijksoortige objecten. Om duidelijk te
maken wat wordt bedoeld kijken we eerst naar het begrip ‘object’.

2.3 Specificatie metagegevens

Elk modelelement kent een aantal metagegevens, die bepaalde aspecten van het modelelement specificeren. Zo is er de naam van het modelelement, bijvoorbeeld het objecttype met als naam Pan den een bijbehorende definitie, of de Datum opname van het modelelement in het informatiemodel, bijvoorbeeld Datum opname 1-1-2012.

Een aantal van deze metagegevens worden gemodelleerd in de modelleertaal UML. Deze zijn in onderstaande tabellen herkenbaar aan de rode tekst en worden met de modelleerconstructies de die de modelleertaal biedt vastgelegd. Bijvoorbeeld het objecttype met de naam Pand wordt gemodelleerd als ‘Named element’ met als ‘Name’ Pand (in UML 1.4 heette dit nog UML-Class). Het metagegeven definitie wordt gemodelleerd door tekst op te nemen in de UML-‘Notes’ van het betrokken UML-‘Named element’.

Een aantal andere metagegevens, zoals de eerder genoemde Datum opname met waarde 1-1-2012. worden als aparte data vastgelegd, in een ‘Tagged value’.

Merk op, deze tagged values zijn specifiek voor elk modelelement apart. Dus als er in H2.2 sprake is van een generalisatie, dan worden deze tagged values niet overerft (en de ingevulde waardes worden uiteraard zeker niet overerft). De MIM metaclass Union erft dus geen metagegevens, zoals patroon, van MIM metaclass Datatype.

Voor de duidelijkheid zijn een aantal metagegevens verplicht gemaakt, om te voorkomen dat een niet ingevulde waarde verschillende betekenissen heeft, zoals: niet aan de orde (wat zo is bij optionele gegevens), nog niet ingevuld, leeg betekent zie default waarde, of dat het onbekend is welk van deze voorgaande betekenissen het is.

Hieronder volgen eerst de algemene metagegevens. Dit zijn metagegevens zoals Naam, Definitie en Datum opname, en deze komen bij meerdere modelelementen voor. De definitie en toelichting van deze metagegevens worden in deze paragraaf gespecificeerd. In de paragrafen hierna wordt vervolgens naar deze paragraaf verwezen. Specifieke metagegevens die maar één keer voorkomen zijn bij het modelelement zelf beschreven.

Metagegeven: Naam

Definitie Naam

De naam van een modelelement.

Toelichting

Bijvoorbeeld: Pand is de naam van het modelelement objecttype, bouwjaar is de naam van het modelelement attribuutsoort. De modelelementen zijn limitatief opgesomd in H2.2.
(en eventueel zijn in een uitbreiding extra modelelementen limitatief opgesomd).

Toepassing: alle modelelementen.

Metagegeven: Definitie

Definitie Definitie

De beschrijving van de betekenis van dit modelelement.

Toelichting

Bijvoorbeeld: Een Pand is de kleinste, bij de totstandkoming functioneel en bouwkundig-constructief zelfstandige eenheid die direct en duurzaam met de aarde is verbonden en betreedbaar en afsluitbaar is.

De definitie volgt, indien aanwezig, de catalogus van de desbetreffende (basis)registratie of informatiemodel, mits deze het modelelement definieert vanuit een informatie en informatiemodel perspectief (er zijn ook andere definities mogelijk vanuit andere perspectieven, zoals vanuit een juridisch perspectief, of vanuit het perspectief van een model van begrippen, zoals genoemd in paragraaf 1.5. Dergelijke definities kunnen hetzelfde zijn, of op het moment hetzelfde, of verschillend, of aanvullend op elkaar. Het is aan de beheerder van het informatiemodel om hier zorgvuldig mee om te gaan).

Toepassing: alle modelelementen.

Metagegeven: Alias

Definitie Alias

De alternatieve weergave van de naam.

Toelichting

Als de naam van het modelelement in het informatiemodel kan bijvoorbeeld zonder spaties is geschreven, dan kan in de alias de naam in natuurlijke taal worden opgenomen. Bijvoorbeeld: OnroerendeZaak heeft als alias Onroerende zaak. De alias is bedoeld als alternatieve schrijfwijze, en heeft verder geen andere betekenis. De alias is optioneel (zie verder ook 3.16).

Verdere toelichting voor UML modellen:

• De alias is te specificeren voor NamedElements (zoals UML-Class, UML-association, UML-UML-Datatype en UML-property). De alias is in UML gespecificeerd bij de metaclass Element Import.^2-10 In Enterprise Architect is de alternatieve weergave aan te zetten in de properties van een Diagram, via: use alias if available.

Bijvoorbeeld: OnroerendeZaak heeft als alias Onroerende zaak.

Toepassing: alle modelelementen die een naam hebben, uitgezonderd de Enumeratiewaarde.^2-13

Metagegeven: Definitie

Definitie Definitie

De beschrijving van de betekenis van dit modelelement.

Toelichting

Bijvoorbeeld: Een Pand is de kleinste, bij de totstandkoming functioneel en bouwkundig-constructief zelfstandige eenheid die direct en duurzaam met de aarde is verbonden en betreedbaar en afsluitbaar is.

De definitie volgt, indien aanwezig, de catalogus van de desbetreffende (basis)registratie of informatiemodel, mits deze het modelelement definieert vanuit een informatie en informatiemodel perspectief (er zijn ook andere definities mogelijk vanuit andere perspectieven, zoals vanuit een juridisch perspectief, of vanuit het perspectief van een model van begrippen, zoals genoemd in paragraaf 1.5. Dergelijke definities kunnen hetzelfde zijn, of op het moment hetzelfde, of verschillend, of aanvullend op elkaar. Het is aan de beheerder van het informatiemodel om hier zorgvuldig mee om te gaan).

Toepassing: alle modelelementen.

Metagegeven: Toelichting

Definitie Toelichting

Een inhoudelijke toelichting op de definitie, ter verheldering of nadere duiding.

Toelichting

Bijvoorbeeld: een aantal treffende voorbeelden (waardes) van het kenmerk van het object.

Toepassing: alle modelelementen met een definitie.

Metagegeven: Herkomst

Definitie Herkomst

De registratie of het informatiemodel waaraan het modelelement ontleend is dan wel de eigen organisatie indien het door de eigen organisatie toegevoegd is.

Toelichting

Bijvoorbeeld: de herkomst van het kenmerk begrenzing van een Perceel heeft als waarde: ‘BRK’. BRK staat dan bijvoorbeeld in de bijbehorende documentatie uitgelegd als: de basisregistratie Kadaster.

Er wordt expliciet niet bedoeld van welke informatievoorziening of registratie de data is overgenomen. Het gaat er bij dit metagegeven expliciet om uit welk domein of bron het modelelement zijn herkomst vindt. Voor basisregistraties is de herkomst altijd het eigen informatiemodel. Dit metagegeven is vooral van belang als het modelelement is overgenomen uit een ander informatiemodel.

Bijvoorbeeld: de herkomst van het kenmerk woonadres, wat bijvoorbeeld een «Relatiesoort» is van een Persoon in de basisregistratie Personen naar een Nummeraanduiding in de basisregistratie Adressen en Gebouwen (BAG), heeft als herkomst: ‘BRP’ (de basisregistratie Kadaster). Dit kenmerk woonadres wordt bijgehouden in de BRP en de source kant van de relatie zit in de BRP. De Nummeraanduiding zelf heeft in de BAG veelal als herkomst: BAG. Mochten echter de adresgegevens niet (direct of indirect) uit de BAG komen, maar bijvoorbeeld via een eigen inwinningsproces in een eigen registratie worden bijgehouden, dan de herkomst niet de BAG.

Deze definitie omvat ook de definite van herkomst van de stelselcatalogus (De registratie in wiens catalogus het objecttype is gespecificeerd (oftewel de registratie waar het objecttype deel van uitmaakt). Deze specificatie is toegevoegd omdat het wel duidelijk moet zijn in welke (basis)registratie of informatiemodel het objecttype).

Toepassing: alle modelelementen die een kenmerk (kunnen) zijn van objecttype (objecttype zelf heeft een eigen definitie van herkomst) en in het informatiemodel gedefinieerde datatypes (maar niet bij elementen van datatypes).

Metagegeven: Herkomst definitie

Definitie Herkomst definitie

De registratie of het informatiemodel waaruit de definitie is overgenomen dan wel een aanduiding die aangeeft uit welke bronnen de definitie is samengesteld.

Toelichting

Meestal staat in dit metagegeven aangegeven ‘<mijn im="">’, bijvoorbeeld BRK als het om het informatiemodel van de BRK gaat.

Maar de herkomst van de definitie van het kenmerk adres kan ook als waarde hebben: ‘BAG’. Of ‘BAG en BRK’, waarbij in de documentatie verder uitgelegd wordt wat dit betekent, zoals dat de definitie is overgenomen en vervolgens binnen het eigen informatiemodel verder aangescherpt is, of nader opgesplitst is in twee aparte definities.

Dit metagegeven is niet bedoeld voor gevallen waarin een definitie alleen geïnspireerd is door een andere definitie, of de andere definitie daadwerkelijke dermate herdefinieerd dat de oorspronkelijke definitie niet meer van toepassing is.

Het gaat erom dat het voor gebruikers helder is hoe informatie die aan dit informatiemodel voldoet zich verhoudt tot informatie die aan het andere informatiemodel voldoet. Het metagegeven herkomst definitie schept hier duidelijkheid in.

Toepassing: alle modelelementen die het metagegeven definitie kennen.

Metagegeven: Datum opname

Definitie Datum opname

De datum waarop het modelelement is opgenomen in het informatiemodel.

Toelichting

Bijvoorbeeld: 1-1-2012.

Toepassing: alle modelelementen, uitgezonderd datatype elementen, packages en overig.

Metagegeven: Indicatie materiële historie

Definitie Indicatie materiele historie

Indicatie of de materiële historie van het kenmerk van het object te bevragen is.

Toelichting

Bijvoorbeeld: Ja. Met te bevragen wordt bedoeld, er wordt historie bijgehouden op enerlei wijze, welke op enerlei wijze te bevragen is.

De in te vullen waarde komt uit: zie Tagged values en waardenbereik tagged values.

Materiele historie geeft aan wanneer in de administratie een verandering bekend is, en is verwerkt. Verdere toelichting, zie hoofdstuk 3.

Toepassing: alle modelelementen die een kenmerk (kunnen) zijn van een objecttype.

Metagegeven: Indicatie formele historie

Definitie Indicatie formele historie

Indicatie of de materiële historie van het kenmerk van het object bijgehouden wordt en te bevragen is.

Toelichting

Bijvoorbeeld: Nee. Met te bevragen wordt bedoeld, er wordt historie bijgehouden op enerlei wijze, welke op enerlei wijze te bevragen is.

De in te vullen waarde komt uit: zie Tagged values en waardenbereik tagged values.

Formele historie geeft aan wanneer in de administratie een verandering bekend is, en is verwerkt. Verdere toelichting, zie hoofdstuk 3.

Zie hoofdstuk 3.

Toepassing: alle modelelementen die een kenmerk (kunnen) zijn van een objecttype.

Metagegeven: Kardinaliteit

Definitie Kardinaliteit

De kardinaliteit geeft aan hoeveel keer waarden van dit kenmerk van een object kunnen voorkomen bij een object van het betreffende objecttype.

Toelichting

1 : een object heeft altijd dit kenmerk. Bijvoorbeeld: geboortedatum persoon.

1..*: een object heeft altijd dit kenmerk, het kenmerk kan meerdere malen voorkomen. Bijvoorbeeld: aantal hoofdstukken in een boek (in dit domein is dat er altijd minimaal 1).

0..1: is soms niet beschikbaar. Bijvoorbeeld: tussenvoegsel achternaam.

0..*: is niet altijd beschikbaar, kan meerdere malen voorkomen.
Bijvoorbeeld: verblijfsobjecten die gelegen zijn in een pand (garagebox 0, huis 1, flat *).

Indien een attribuutsoort deel uit maakt van een gegevensgroeptype, dan wordt de kardinaliteit vermeld van het attribuutsoort binnen het gegevensgroeptype. Voor de uiteindelijke kardinaliteit van hoe vaak een gegeven voorkomt bij het object moet rekening gehouden worden met de kardinaliteit van de gegevensgroep en met de kardinaliteit van de attribuutsoort.

Merk op dat het zo kan zijn dat een object het kenmerk wel degelijk heeft/zou moeten hebben, maar dat het vooralsnog niet gelukt is om dit gegeven in te winnen of te achterhalen. Het is dan bekend dat het object dit kenmerk wel degelijk heeft, maar de waarde ervan is onbekend. De kardinaliteit wordt dan niet van 1 naar 0 gezet, maar er wordt aangegeven dat er sprake is van mogelijk geen waarde. Meer hierover is beschreven in hoofdstuk 3.

Toepassing: alle modelelementen die een kenmerk (kunnen) zijn van een objecttype.

Metagegeven: Authentiek

Definitie Authentiek

Aanduiding of het kenmerk een authentiek gegeven betreft.

Toelichting

Bijvoorbeeld: authentiek.

Dit is zo voor bijvoorbeeld het burger service nummer van een natuurlijk persoon. In de wet van bijvoorbeeld een basisregistratie ligt vast welke gegevens authentiek zijn.

Een kenmerk is authentiek indien de juistheid (hoogwaardige kwaliteit) van het gegeven gewaarborgd wordt via formele inwinningsprocessen en wettelijk regelingen. Authentieke gegevens moeten door alle overheidsinstellingen verplicht en zonder nader onderzoek, worden gebruikt bij de uitvoering van publiekrechtelijke taken.

De in te vullen waarde komt uit: zie Tagged values en waardenbereik tagged values.

Toepassing: alle modelelementen die een kenmerk (kunnen) zijn van een objecttype.

Metagegeven: indicatie afleidbaar

Definitie indicatie afleidbaar

Aanduiding dat gegeven afleidbaar is uit andere attribuut- en/of relatiesoorten.

Toelichting

Bijvoorbeeld: de ‘naam’ van een openbare ruimte, zoals Burgemeester Baron van Voerst van Lyndenstraat , wordt in de verkorte schrijfwijze de ‘verkorte naam’ Burg Bar v V v Lyndenstr – dit is een afgeleid gegeven. Bijvoorbeeld de ‘eigenaar’ van een huis kan worden afgeleid uit bepaalde andere gegevens die binnen het informatiemodel zijn vastgelegd. Het afgeleide gegeven is zelf geen brongegeven, en moet aangepast worden als de brongegevens aangepast worden. In de beschrijving van het kenmerk zal aangegeven zijn om welke gegevens het gaat en eventueel hoe de afleiding plaatsvindt.

Toepassing: de modelelementen waarvoor een waarde ingevuld kan worden, te weten de modelelementen attribuutsoort en relatiesoort.

Metagegeven: mogelijk geen waarde

Definitie indicatie afleidbaar

Aanduiding dat van een aspect geen waarde is geregistreerd, maar dat onduidelijk is of de waarde er werkelijk ook niet is.

Toelichting

Bijvoorbeeld: land van herkomst. Elk mens komt uit een land, maar het kan op het moment onduidelijk zijn welk land dit is. Bijvoorbeeld: RSIN van een organisatie, voor gegevens in de registratie die ingewonnen zijn voordat het RSIN bestond. Het RSIN is een verplicht veld in het actuele informatiemodel, maar voor oude gegevens is de waarde onbekend.

Het gaat er hier om dat het onduidelijk is of de waarde er is, of als het wel duidelijk is dat er een waarde is/zou moeten zijn, dat het onduidelijk is wat de waarde dan is. Dit metagegeven geeft dan aan dat het toegestaan is dat deze onduidelijkheid mag (blijven) bestaan. Veelal mag dit alleen onder bepaalde voorwaarden, met een opgaaf van reden.

Toepassing: de modelelementen waarvoor een waarde ingevuld kan worden, te weten de modelelementen attribuutsoort en relatiesoort.

Metagegeven: Locatie

Definitie Locatie

Als het type van het attribuutsoort een waardenlijst is, dan wordt hier de locatie waar deze te vinden is opgegeven.

Toelichting

Indien mogelijk is de verwijzing een URI of een URL (als er geen URI is, dan kan dit een URL zijn, waar de waardenlijst op basis van de naam van de waardenlijst te vinden is).

Bijvoorbeeld: <http: www.organisatie.nl="" schemas="" waardelijsten="" naamwaardelijst="">

Toepassing: de modelelementen die een waardelijst zijn.

Metagegeven: Type (domein van een waarde een gegeven)

Definitie Type

Het datatype waarmee waarden van deze attribuutsoort worden vastgelegd.

Toelichting

Dit is altijd conform een datatype uit dit metamodel (of een extensie ervan) of een primitief datatype die extern is aan dit model. Betreft het een waarde uit een dynamische waardentabel, dan wordt de naam van de desbetreffende referentielijst of codelist als type vermeld. Indien het een waarde uit een statische opsomming van waarden betreft, dan wordt de naam van de desbetreffende enumeratie als type vermeld.

Bijvoorbeeld: VlakOfMultivlak, CharacterString

Toepassing: attribuutsoort, primitief datatype (in het IM gedefinieerd), data element, union element, referentie element.

Metagegeven: Lengte (domein van een waarde van een gegeven)

Definitie Lengte

De aanduiding van de lengte van een gegeven.

Toelichting

Getallen kunnen altijd positief of negatief zijn. Bijvoorbeeld: ‘1’ als de lengte exact 1 is; ‘1..2’ als de lengte 1 tot en met 2 lang kan zijn; '‘1,2’ voor Decimale getallen met 1 cijfer voor de komma en 2 erna. Dit is van -9,99 tot +9,99; Dit is verder toegelicht in hoofdstuk 3.

Toepassing: attribuutsoort, primitief datatype (in het IM gedefinieerd), data element, union element, referentie element.

Metagegeven: Patroon

Definitie Patroon

De verzameling van waarden die gegevens van deze attribuutsoort kunnen hebben, oftewel het waardenbereik, uitgedrukt in een specifieke structuur.

Toelichting

De structuur is in woorden beschreven.

Bijvoorbeeld: conform de Nederlandse standaard voor het beschrijven van een postcode.

Het specificeren van een patroon is alleen van toepassing wanneer de specificatie aangeeft dat de waarde (direct of indirect) een primitief datatype betreft, zoals een CharacterString.

Definitie Formeel patroon

Zoals patroon, formeel vastgelegd, uitgedrukt in een formele taal die door de computer wordt herkend.

Toelichting

De structuur is in een reguliere expressie beschreven.

Bijvoorbeeld: [1-9][0-9][0-9][0-9][A-Z][A-Z]

Het specificeren van een patroon is alleen van toepassing wanneer de specificatie aangeeft dat de waarde (direct of indirect) een primitief datatype betreft, zoals een CharacterString.

Toepassing: de modelelementen uit de groep datatype en attribuutsoort.

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.

^2-13: Een uitzondering is gemaakt voor UML modellen voor de UML-EnumerationLiteral. De ‘naam’ betreft hier een daadwerkelijk waarde, waarin de naam gelijk staat aan de waarde. Het is daarom expliciet ongewenst om hiervoor een alternatieve naamgeving te gebruiken. De alias wordt hier, mede daarom, gebruikt voor (alleen) de modellering van het metadata aspect Code, welke aanvullend is op naam (niet een alternatief van naam).

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 MIM 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.

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 MIM 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: VNG Realisatie 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 2.3.2.1)

Kern - Relatierol is leidend (zie 2.3.2.2)

Datatypen

4.3 Bijlage III: Template naamgeving conventies

4.4 Bijlage IV: Versielog

In deze versie zijn de volgende issues verwerkt: