MIM - Metamodel Informatie Modellering

De Keuze en de Constraint zijn verschillende manieren om een voorwaarde of een beperking op te leggen aan een modelelement. Beide methoden hebben voor- en nadelen. Meer informatie daarover in de paragrafen constraint en keuze. In de volgende alinea's wordt verder toegelicht hoe ze toegepast worden.

Constraint in het kort

Een Constraint legt voorwaarden of beperkingen op aan een modelelement. Meer informatie daarover in de paragraaf over Constraint. Het diagram toont aan dat op alle modelelementen een Contraint kan worden toegepast.

Keuze in het kort

Het modelelement keuze bepaalt dat er meerdere opties mogelijk zijn, waarvan er één gekozen moet worden. Er zijn vijf situaties mogelijk waarin een keuze toegepast wordt. Elke situatie heeft een eigen metamodel.

1. een keuze tussen datatypen (diagram)
2. een keuze tussen twee of meer attribuutsoorten (diagram)
3. een keuze tussen meerdere manieren om één betekenisvol attribuutsoort in te vullen (diagram)
4. een keuze tussen relatiedoelen, als nadere invulling van één betekenisvolle relatiesoort (diagram)
5. een keuze tussen twee of meer relatiesoorten/relatierollen (elk afzonderlijk betekenisvol) (diagram)

Voor elke mogelijkheid is een aparte «MIM metaclass» beschikbaar in het metamodel.

1. «MIM metaclass»: Datatype(keuze)
2. «MIM metaclass»: Keuze(attribuut)
3. «MIM metaclass»: Keuze(attribuut)
4. «MIM metaclass»: Keuze(relatie)
5. «MIM metaclass»: Keuze(relatie)

Voor use case zie: (use case 1: datatypekeuze).

Voor use case zie: (use case 3: attribuutkeuze_2).

Voor use case zie: (use case 4: relatiedoel keuze).

Voor use case zie: (use case 5: relatiedoel-met betekenis).

Uitwerking van de structuur en samenhang van relatierol, bron en doel.

1. MIM metaclass: Relatierol (abstract)
2. MIM metaclass: Relatierol bron
3. MIM metaclass: Relatierol doel

In diagramvorm:

Externe koppeling bestaat uit de volgende modelelementen:

1. MIM metaclass: Externe koppeling

Zie: Figuur 2

Groepering bestaat uit de volgende modelelementen:

1. MIM metaclass: Package
2. MIM metaclass: Modelelement
3. MIM metaclass: Informatiemodel
4. MIM metaclass: Domein
5. MIM metaclass: Extern
6. MIM metaclass: View

De betekenis van deze modelelementen en de beschrijvingen ervan staan in Packages.

In diagramvorm:

Toelichting:

Met 'het beschouwde domein' wordt bedoeld dat het om onderwerpen (een ding, een iets) van gesprek gaat binnen een discipline of domein. Een object is daarbij niet altijd fysiek het kunnen ook digitale, virtuele en conceptuele dingen zijn zoals kadastrale percelen, (maatschappelijke) activiteiten en processen. Hoe een 'onderscheidbaar iets' als een object beschouwd wordt, hangt af van het domein waarvoor het relevant is. Zo wordt de gebouwde omgeving in het ene domein beschouwd als een verzameling gebouwen terwijl een ander domein daarin panden onderscheidt. Een object is voor een domein relevant als eigenschappen (kenmerken) daarvan van belang zijn voor het functioneren van dat domein.

Een object wordt ook wel een exemplaar of instantie van een objecttype genoemd (vele soortgelijke exemplaren samen zijn getypeerd naar een objecttype).

Een object heeft eigenschappen (ook wel kenmerken genoemd) waarover gegevens bekend zijn.

Toelichting:

Voorbeelden van gegevens zijn: de naam van een persoon is 'Jan', de geboortedatum van Jan is ‘1-1-1970’.

Eigenschappen van een object kun je waarnemen of beweren en vervolgens vastleggen als gegeven. Aan alleen de waarde '1-1-1970' heb je niet zo veel als je niet weet dat het om de geboortedatum van een persoon gaat (de eigenschap) en om welke persoon het precies gaat (het onderwerp van gesprek). De waarde '1-1-1970' wordt vastgelegd als de geboortedatum van een specifiek persoon. Het is dus van belang om welke eigenschap van welke specifieke persoon het gaat. Verder is het uiteraard van belang om te weten wat de betekenis is die bij het gegeven hoort.

Waarneming: een observatie die wordt waargenomen voor een eigenschap van een object. Bijvoorbeeld: de sensor waarneming dat de auto met kenteken 'AA 1234' met een snelheid van 120 kilometer per uur rijdt. Een foto dat een brug op een bepaalde plek op aarde staat, of een meting van een geluid van 50 decibel.

Bewering: een uitspraak, die meestal als waar bedoeld is maar niet per definitie waar is. Mijn geboortedatum is '1-1-1970', de waarde van dit huis is 200.000 euro (in het jaar 2018). Wie de bewering gedaan heeft is vaak relevant. Denk bij een bewering aan hetgeen waarover besloten wordt door een bevoegd gezag, of aan een persoon die een gegeven opgeeft voor een bepaald doel. Een bewering kan gedaan worden over iets dat in de werkelijkheid is waargenomen, zoals bij de aangifte van een geboortedatum van een baby. Maar een bewering hoeft niet te zijn waargenomen in de werkelijkheid, zoals wanneer er een bouwvergunning is verleend.

Vastgelegd: een gegeven kan in principe al bekend zijn zodra deze wordt waargenomen of beweerd, maar de waarneming moet eerst vastgelegd worden om bruikbaar te zijn in een informatievoorziening. De vastlegging kan op papier, in digitale vorm, op een foto, in een bericht, in een database et cetera.

Getypeerd: een model specificeert niet de gegevens zelf. Een gegeven zoals '1-1-1970' noemen we een waarde voor een attribuut van Jan. In het informatiemodel wordt dit bv. het attribuutsoort 'geboortedatum' of attribuutype 'overlijdensdatum' van een objecttype Persoon genoemd. Dat twee objecten een relatie hebben, gemodelleerd in het model als relatietype, wordt ook gezien als een eigenschap waarvoor een gegeven bekend kan zijn. De modelelementen waarmee een getypeerde eigenschap van een object gemodelleerd kan worden zijn: attribuutsoort, relatiesoort en externe koppeling. Hier kunnen gegevens over bekend zijn. Het datatype is hierbij van belang voor de waarde, en het objecttype is van belang omdat het helder moet zijn om welk object het gaat.

Waarde: de waarde '1-1-1970' is een onderdeel van het gegeven. Om zeker te zijn dat het gegeven een toegestane waarde heeft moet de waarde van het gegeven voldoen aan het opgegeven datatype en eventuele aanvullende specificaties zoals een formeel patroon of dat de waarde voorkomt in een waardelijst. Er zijn waardes die:

• een enkelvoudige structuur hebben, zoals bij de voornaam 'Jan', of het object Natuurlijk persoon met identificatie '123';
• een interne structuur kennen die nader onderverdeeld is, zoals bijvoorbeeld een geometrie die bestaat uit meerdere coördinaten, een coördinaten referentiesysteem, enzovoorts. De onderdelen, oftewel de data elementen, vormen samen de waarde (de dataelementen zijn zelf niet een gegeven, maar zijn slechts een onderdeel ervan).

Met de vastlegging van gegevens in een informatievoorziening wordt een model van de werkelijkheid bevroren in de tijd. Hoewel de werkelijkheid nooit stil staat, kan deze door het vastleggen van de gegevens toch worden bevroren. Bij een gegeven kunnen ook metagegevens worden vastgelegd, voor het bijhouden van historie, zoals de tijdslijn geldigheid en de tijdslijn registratie. Op deze manier weet een gebruiker van de informatievoorziening wanneer het gegeven geldig is (of is geweest) en wanneer het gegeven is vastgelegd op een bepaald medium. Met betrekking tot gestructureerde datatypes: het is (meestal) niet zinvol om voor een onderdeel van een gegeven, oftewel een afzonderlijk data element van een gestructureerde datatype, historie bij te houden, want een onderdeel van een gegeven representeert niet de gehele waarde.

Toelichting: Jan, Piet en Marie zijn mensen die vanuit het Burgerzaken-domein beschouwd worden als objecten van het «Objecttype» NatuurlijkPersoon. In een ander domein, ‘de volksmond’, noemen we dit Mens wat ook een «Objecttype» is. In weer een ander domein is Jan van het «Objecttype» Vergunninghouder en Piet en Marie niet, omdat aan hen (nog) nooit een vergunning verleend is. Objecttypen zijn een abstractie van de werkelijkheid oftewel we beogen hiermee de werkelijkheid zo getrouw mogelijk te beschrijven, binnen de context van het domein. Dit staat geheel los van het vastleggen van gegevens over objecten van een type in een registratie. Daartoe is veelal een interpretatie nodig (van die werkelijkheid cq. die objecttypen) naar eenheden die in een registratie vastgelegd kunnen worden (records, entiteiten e.d.) op basis van andere overwegingen.

De objecten die in het beschouwde domein onderkend worden zijn zelf nooit abstract. Ze behoren altijd tot een concreet «Objecttype», en niet tot een abstract «Objecttype». Een abstract «Objecttype» wordt wel gebruikt in de modellering, om generalisatie aan te duiden en de definitie. Zo kan bij het «Objecttype» Pand bijvoorbeeld aangegeven worden dat dit een 'Element in de fysieke leefomgeving' is, en dat deze laatste als een abstract «Objecttype» gezien moet worden (in ons domein). Meer over abstracte objecttypen is beschreven in Abstracte Objecttypen en concrete objecten.

Een «Attribuutsoort» is de metaklasse waarmee kenmerken van een «Objecttype» worden vastgelegd. Het zijn de kenmerken waarvoor gegevens worden bijgehouden.

Toelichting: De gegevens "Jan" en "Katrien" worden als gelijksoortig gezien en worden daarom ondergebracht in «Attribuutsoort» naam. Je kan ook zeggen, het «Objecttype» Persoon heeft een Attribuutsoort naam en deze is geschikt om gegevens in te plaatsen. Aan elk «Objecttype» worden nul, één, of meer attribuutsoorten toegekend. In een informatiemodel wordt alleen een voor het domein relevant «Attribuutsoort» opgenomen bij een «Objecttype». Attribuutsoorten worden ook wel kenmerken of eigenschappen genoemd. Dit zijn het ook, maar ook andere modelelementen vallen onder deze omschrijving. Zo is een «Relatiesoort» ook een kenmerk of eigenschap.

Toelichting: Dit modelelement verzorgt de modelmatige aankoppeling van een «Gegevensgroeptype» aan het «Objecttype» waartoe een «Gegevensgroeptype» onlosmakelijk behoort. De groep van gegevens is een kenmerk van een object. De «Gegevensgroep» is een betekenisvol kenmerk van een «Objecttype». De «Gegevensgroep» heeft altijd als type een «Gegevensgroeptype».

Toelichting: Een «Attribuutsoort» van een «Gegevensgroeptype» is semantisch gezien een eigenschap van een «Objecttype». Echter, vanwege samenhangend gedrag (ze horen semantisch bij elkaar, ze wijzigen bijvoorbeeld gelijktijdig e.d.) zijn deze ondergebracht in een apart modelelement. Het onderbrengen van attribuutsoorten in een groep c.q. in het modelelement gegevensgroeptype, is een modelleerkeuze, het is niet perse noodzakelijk. Wanneer deze ondergebracht worden in een gegevensgroeptype dan zijn/blijven het afzonderlijke kenmerken van het object en dus attribuutsoorten van het objecttype, maar dan ondergebracht in een gegevensgroeptype. De gegevensgroep als geheel wordt daarom expliciet niet gezien als zijnde één attribuutsoort van een object.

Toelichting: bijvoorbeeld: in de BRK heeft een schip een motor en de motor heeft een aantal eigenschappen. De BRK beschouwt een persoon als eigenaar van een schip, er kunnen geen afzonderlijke eigenaren zijn van elk van de motoren van een schip. In de BRK kan het eigendom van een Motor dan ook niet worden overgedragen aan een ander persoon. Een motor wordt daarom gezien als een eigenschap van het object schip, en omdat de motor meerdere eigenschappen heeft, worden deze ondergebracht in een gegevensgroeptype. In een ander informatiemodel, zoals van een motorfabriek, zou de Motor wel een objecttype kunnen zijn, omdat het daar wel hét onderwerp van gesprek is.

Een gegevensgroeptype is meestal het type van slechts één gegevensgroep, omdat de semantiek meestal exclusief is voor één objecttype. Echter, hergebruik is mogelijk (als de semantiek niet exclusief is voor één objecttype). Voorwaarde voor hergebruik is dat de definitie (de definitie en toelichting, inclusief alle metadata aspecten) dan inderdaad gelijk zijn, voor alle objecttypes die hergebruik maken van het gegevensgroeptype.

Een gegevensgroeptype kan, naast attribuutsoorten en relatiesoorten, ook zelf weer gegevensgroeptypen bevatten.

Een gegevensgroeptype is verbonden met een objecttype, via het modelelement Gegevensgroep.

Toelichting:

Generalisatie tussen objecttypes:

Een generalisatierelatie geeft aan dat bepaalde eigenschappen van een objecttype (vaak attribuutsoorten en/of relatiesoorten) ook gelden voor de gerelateerde objecttypen, én dat deze qua semantiek, structuur en syntax gelijk zijn. We spreken dan van een supertype met subtypen. De modelelementen die generiek gelden worden in een generiek objecttype, het supertype, gemodelleerd en deze worden overerfd door elk subtype dat de «Generalisatie» legt naar dit generieke «Objecttype».

Generalisatie tussen datatypen:

Het meer specifieke datatype brengt een verbijzondering aan in de vorm van een meer restrictieve definitie, of een meer restrictief patroon/formeel patroon. Het andere datatype is bijvoorbeeld een CharacterString, Integer, GM_Surface ofDMO en dient als basis voor een zelf te definiëren datatype (zie Datatype zelf definiëren), zoals een CharacterString Postcode, of een NietNegatiefGetal.Deze generalisatie is van toepassing op de volgende datatypen: «Primitief datatype», «Gestructureerd datatype», «Referentielijst», «Codelijst»,«Enumeratie».

Meervoudige overerving of multiple-inheritance:

Een subtype kan meerdere objecttypen als generalisatie hebben. In het diagram Kern is dit aangegeven door een «Objecttype» als subtype naar 0..* «Generalisaties» te laten verwijzen. Dat impliceert dat een subtype 0..* supertypen kan hebben.

Toelichting: Objecten hebben eigenschappen die gemodelleerd kunnen worden met attribuutsoorten maar ook met relatiesoorten naar andere objecttypen. Relatiesoort is de metaklasse waarmee deze eigenschappen worden beschreven. Als het voor het desbetreffende domein van belang is om die eigenschap te modelleren als onderdeel van een ander objecttype, dan maakt de relatiesoort die eigenschap beschikbaar voor het eerstgenoemde objecttype. Bijvoorbeeld, een attribuutsoort van het objecttype PERSOON zou kunnen zijn ‘Naam geregistreerd partner’ (naast de attribuutsoort ‘Naam’ van PERSOON). De naam van de geregistreerde partner komt evenwel ook beschikbaar met een relatiesoort van PERSOON naar PERSOON: “heeft geregistreerd partnerschap met”. Zie ook het eerder genoemde voorbeeld van SCHIP en MOTOR.

Wanneer een relatie gebruikt wordt om objecten aan elkaar te verbinden, zonder dat er eigenschappen over deze relatie worden vastgelegd, dan betreft dit de MIM-metaclass «Relatiesoort».

Toelichting: De relatieklasse geeft aan dat er een relatie is tussen twee objecten, waarbij er gegevens over deze relatie vastgelegd moeten worden. De relatie wordt in dit geval behandeld als een object, met gegevens. De gegevens over de relatie bestaan alleen zolang de relatie tussen beide objecten bestaat en zolang elk van beide objecten zelf (nog) bestaan.

Opmerking: de gegevens van de relatie worden voor één relatie vastgelegd en niet voor meerdere relaties tegelijk. Als dit laatste het geval is, dan worden de gegevens vastgelegd in een «Objecttype». 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.

Toelichting:
Hiermee wordt aangegeven dat er een relatie ligt naar een informatiemodel van een ander domein. Dit kan rechtstreeks zijn, maar het is ook mogelijk om het objecttype van een ander domein over te nemen naar het eigen domein, en specifiek te maken voor hoe je deze informatie ziet vanuit je eigen domein (dit laatste noemen we ook wel een View.

Zie Koppelen met een ander informatiemodel.

Toelichting: Met relatie wordt in deze de volgende bedoeld: «Relatiesoort», «Relatieklasse» of «Externe koppeling». Voor «Generalisatie» speelt het niet. Een relatie heeft een bronkant, die de eigenaar is van de relatie, en is gericht naar de doelkant. De relatierol kan aan beide kanten een Naam en een Definitie krijgen.

Toelichting: De referentielijst bevat representaties van objecten, die in het informatiemodel niet als een objecttype onderwerp van gesprek zijn. De referentielijst wordt gebruikt als type van een attribuut van een object.

Het objecttype LAND uit het voorbeeld is opgenomen in een referentielijst en niet als objecttype. Maar we willen wel de structuur en betekenis van LAND vastleggen, zodat we er naar kunnen refereren. Een object dat is opgenomen in een referentielijst heeft daarom veelal meerdere attributen, zoals de naam, de ontstaansdatum, een omschrijving en de ISO code, die zijn opgenomen in de referentielijst.

Alle attributen van gerefereerde objecten uit de referentielijst gelden in de context van het informatiemodel, mits opgenomen in de «Referentielijst». In de registratie wordt vaak alleen de referentie ernaartoe opgenomen, omdat het niet de bedoeling is om alle gegevens over te nemen. De gegevens staan immers al in de referentielijst en er is bewust gekozen om een referentielijst te modelleren. Het attribuut van een objecttype dat als type een referentielijst heeft bevat in de registratie daarom (vaak) alleen een referentie naar een object uit de lijst.

Toelichting: Een referentie-element kan uniek zijn, zoals een code, en is dan op zichzelf geschikt om gebruikt te worden als referentie (zoals bedoeld in de definitie van Referentielijst). Bij het referentie-element kan een definitie en toelichting worden opgenomen, die aangeven hoe de externe waardelijst in het eigen informatiemodel gebruikt wordt.

Toelichting: In de registratie krijgt een attribuut één van deze waarden. De lijst is een statische lijst met constanten (meerdere attributen, zoals bij een referentielijst, zijn nooit aan de orde).

Toelichting: De waarde van de data zelf. Bijvoorbeeld: Plein, Brug, Spoor, M (man).
Alleen deze waarde mag gebruikt worden.

Toelichting: Zowel referentielijsten als codelijsten zijn in feite waardelijsten. In tegenstelling echter tot de referentielijst wordt de structuur van een codelijst niet in het informatiemodel beschreven, omdat die niet (nader) geduid hoeft te worden in het informatiemodel. De extern gepubliceerde waardelijst die de Codelijst representeert bevat een of meer attributen, waarvan altijd één specifiek attribuut met daarin de domeinwaarden die gebruikt mogen/moeten worden in het informatiemodel. Welk specifiek attribuut dat is staat in het metagegeven Waarde-item. In het gebruik is een Codelijst daarom analoog aan een Enumeratie.

Als het wel van belang is om de structuur van een Codelijst in het model te definieren, dan moet een «Referentielijst» worden gebruikt.

Toelichting: Zie ook Objecttypen en attribuutsoorten. Bij elke «Attribuutsoort» wordt gespecificeerd aan welk datatype de data c.q. de waarde die hiervoor vastgelegd wordt moet voldoen. Het datatype wordt gebruikt als type van een attribuutsoort. Datatypen zijn veelal op vele plekken (her)bruikbaar en kunnen daarom gespecificeerd worden bij diverse attribuutsoorten.

Diagram: Datatypen

Toelichting: Een primitief datatype is een datatype zonder verdere specificatie over de structuur. Dit datatype is enkelvoudig, oftewel niet samengesteld en wordt ook wel simpel datatype genoemd. Dit datatype kent daarom zelf geen eigen modelelementen zoals een «Data element». Ook is er geen sprake van een gelaagdheid, ook wel nesting genoemd. Een primitief datatype kan wel een patroon of formeel patroon hebben, die een nadere restrictie legt.

Een primitief datatype kan een standaard datatype zijn, zoals CharacterString, Integer enz. Het metamodel volgt hierbij de definities zoals beschreven in de ISO standaarden (zie §3.1).

• Deze datatypen hebben altijd al een naam en definitie gekregen vanuit deze standaarden en deze worden gebruikt.
• Deze datatypen hebben geen MIM metaclass.

Een primitief datatype kan ook in het eigen informatiemodel zelf-gedefinieerd zijn, zoals bijvoorbeeld een primitief datatype AN: een alfanumerieke CharacterString conform de MES-1 specificatie (oftewel zonder bijzondere karakters zoals een smiley en zonder bijzondere tekens uit niet Europese talen).

• Dit is een zelf-gedefinieerde variant die als basis een van de voorgaande standaard datatypen heeft, zoals CharacterString. Dit standaard datatype moet eenduidig aangegeven worden (zie generalisatie bij datatypen, of door in een extensie aan te geven wat de default is, bv. CharacterString).
• Hierbij hoort de MIM metaclass gespecificeerd te worden: primitief datatype.

Een informatiemodel definieert zelf datatypen als er behoefte is aan een datatype dat eenmalig gedefinieerd wordt en op meerdere plekken in het model gebruikt moet kunnen worden met altijd exact dezelfde structuur en waardenbereik (zie ook ‘patroon’ in Domeinwaarden of lijsten). Dit datatype, met een eigen naam, wordt vervolgens gebruikt als type van een attribuutsoort.

NB: Wanneer het datatype Postcode landelijk zodanig beschikbaar is gemaakt zodat hier gebruik van gemaakt kan worden in het model, middels een verwijzing, dan hoeft Postcode niet meer in het eigen model opgenomen te worden.

Toelichting:

De waarde van het attribuutsoort verkoopprijs met gestructureerd datatype bedrag is uitgedrukt in een combinatie van een som en valuta zoals 35 euro. De introductie van één datatype Bedrag, uitgedrukt in som en valuta, legt dus vast dat som en valuta onlosmakelijk met elkaar zijn verbonden.

De eigenschappen in het Gestructureerd datatype tezamen zijn identificerend (een Gestructureerd datatype “identificeert zichzelf”, zoals er maar per definitie één '1 liter' bestaat, één '35 euro' en één datum '6 april 2017', met per definitie altijd dezelfde betekenis:

• Een blik olie heeft een inhoud van "7 liter", kost "35 euro", en is verkocht op "6 april 2017".

• Piet heeft "1 liter" bloed gedoneerd, daarvoor "35 euro" vergoeding gekregen, op "6 april 2017".

Het identificerend zijn geldt bijvoorbeeld niet voor Jan Jansen. Er zijn meerdere personen met deze naam en dat zijn verschillende personen (Jan Jansen is dan ook een gegevensgroeptype Naam met voornaam Jan en achternaam Jansen en geen Gestructureerd datatype).

Toelichting: Het data-element is een eigenschap van een Gestructureerd datatype en beschrijft de structuur van een gegeven. Het is niet een eigenschap van een object en niet hetzelfde als een attribuutsoort. Het data-element beschrijft in combinatie met andere data-elementen de structuur van een gegeven en heeft zelf een datatype. Dit datatype is meestal een primitief datatype.

Toelichting: Het informatiemodel is een package, te weten het hoofdpackage van het informatiemodel, waar alle subpackages die een informatiemodel beschrijven onder vallen, zoals Domein en View en extern. Het informatiemodel wordt verder beschreven met metadata, zoals de aanduiding van het domein wat in het informatiemodel is gemodelleerd. Het is gangbaar om de naam van het informatiemodel te beginnen met IM, maar dit is niet verplicht.

Een informatiemodel kan onderverdeeld worden in meerdere packages, waarbij aangegeven wordt dat deze de modellering van de informatie van het domein bevatten.

Toelichting: Een domein package bevat de modelelementen waaruit een informatiemodel is samengesteld, zoals het objecttype Persoon en het objecttype Nummeraanduiding en de relatiesoort woonadres. Een informatiemodel is het hoofdpackage, en kent een aantal domein packages als subpackage. Er zijn meerdere soorten packages. Om onderscheid te maken tussen packages waarin het domein gemodelleerd is, en andere packages, heeft dit modelelement de naam Domein gekregen. Je zou ook kunnen zeggen, het informatiemodel bestaat uit de volgende subdomeinen.

Toelichting: Een Constraint wordt opgenomen om een constructie uit te drukken die niet via bestaande modelelementen is uit te drukken. De Constraint wordt dan toegevoegd om de extra informatie formeel vast te leggen. Meestal wordt een Constraint vastgelegd op het niveau van een modelelement met eigenschappen zoals een Objecttype, Gegevensgroeptype en Relatieklasse om specifieke condities over die eigenschappen vast te leggen. Een voorbeeld is de een 11-proef op een Datatype van een Attribuutsoort. Een Constraint wordt altijd in gewone tekst omschreven en kan optioneel als formele specificatie worden aangegeven.

Er zit bij een Constraint een belangrijk verschil tussen betrekken en vastleggen: betrekken bepaalt de modelelementen waar de Constraint op van toepassing is en vastleggen bepaalt wat de context van de Constraint is, het modelelement vanuit waar de Constraint geldt. Zo kan een constraint die van toepassing is op toegestane waarden van een attribuutsoort vastgelegd worden bij het objecttype dat de attribuutsoort gebruikt.

Toelichting: Er kan altijd maar één van de mogelijkheden gekozen worden. De Keuze is voor een aantal use cases een alternatieve manier voor het modelleren van een constraint.

Een Keuze maakt het mogelijk een opsomming te geven van meerdere mogelijkheden, waarbij in een concreet geval altijd precies één van deze mogelijkheden wordt gebruikt. Er zijn verschillende plekken waar dit gebruikt kan worden.

Een belangrijk voordeel van het gebruik van de Keuze ten opzichte van een constraint is dat de kardinaliteiten zuiver gehouden kunnen worden. Bij het gebruik van een constraint zie je vaak dat de kardinaliteit van bijvoorbeeld twee kenmerken optioneel gemaakt is en om vervolgens via de constraint toch weer verplicht gemaakt te worden, voor precies één van de mogelijkheden.

Dit document beschrijft een aantal use cases waarin het modelleren met een Keuze van toegevoegde waarde is. Zonder een dergelijke modelconstructie zou het nodig moeten zijn om met een expliciete constraint de keuze aan te geven.

Bij de use cases gaat het over meerdere kenmerken, waartussen een keuze gemaakt moet worden omdat er van precies 1 sprake is/mag zijn. Dit is in MIM een keuze tussen twee (of meer) modelelementen. In de verzamelingenleer noemen we dit een XOR situatie. Hierbij is het vooral van belang dat er als gevolg van de modellering van een keuze in plaats van constraint er geen nieuwe kenmerken mogen ontstaan en ook geen kenmerken mogen wegvallen. De kenmerken van het object blijven gelijk.

Use case 1: een keuze tussen datatypen
Een objecttype heeft een attribuutsoort en het datatype hiervan is ofwel datatype D1 ofwel datatype D2. In MIM modelleren we daarom 1 attribuutsoort met als datatype een keuze tussen het datatype D1 en het datatype D2. Het maken van deze keuze is verplicht.

In dit voorbeeld vormt LijnOfVlak de Keuze als geheel. De datatypen zelf zijn de keuzemogelijkheden, maar blijven in de modellering van de metaclass Datatype en behoren in deze zin niet tot de modellering van de metaclass Keuze.

Bij een modellering zonder Keuze zou je te maken krijgen met een attribuutsoort per datatype, maar met een verschillende naam, hoewel ze betrekking hebben op hetzelfde kenmerk. Ook zou de kardinialiteit niet kloppen: die zou dan 0..1 moeten worden, maar dat doet geen recht aan het feit dat er één verplicht aanwezig moet zijn, en er ook geen twee naast elkaar mogen zijn. De werkelijke kardinaliteit is 1..1.

Use case 2: een keuze tussen 2 of meer attribuutsoorten
Er is sprake van ofwel attribuutsoort A1 ofwel attribuutsoort A2. In MIM modelleren we daarom een keuze tussen de 2 attribuutsoorten A1 en A2. Het maken van deze keuze is verplicht.

We modelleren daarom een Keuze BetalingskenmerkOfOmschrijving met daarin een attribuutsoort betalingskenmerk en een attribuutsoort omschrijving.

Het is bij deze use case niet de bedoeling om een derde attribuutsoort, zoals kenmerkOfOmschrijving, te introduceren als attribuutsoort van het objecttype. kenmerkOfOmschrijving staat er wel maar is geen attribuutsoort maar een Keuze. De naam daarvan is arbitrair omdat het geen betekenis heeft en bij de implementatie in data niet voorkomt. De binding van de Keuze BetalingskenmerkOfOmschrijving is daarom aan het objecttype en niet aan een attribuutsoort.

In dit voorbeeld vormt BetalingskenmerkOfOmschrijving en de binding ervan aan het objecttype de Keuze als geheel. De attribuutsoorten zelf zijn de keuze mogelijkheden, maar blijven in de modellering van de metaclass attribuutsoort en behoren in deze zin niet tot de modellering van de metaclass keuze.

Zonder de mogelijkheid van Keuze zouden beide attribuutsoorten opgenomen zijn bij het objecttype als optionele velden, met een constraint dat een van beide gevuld moet zijn. Nadeel hiervan is dat de kardinaliteit dan niet erg duidelijk gemodelleerd is: die zou dan voor beide attribuutsoorten [0..1] moeten worden, maar dat doet geen recht aan het feit dat er één verplicht aanwezig moet zijn, en er ook geen twee naast elkaar mogen zijn. De werkelijke kardinaliteit voor een gekozen attribuutsoort is [1..1]. Met een constraint is dit te specificeren en derhalve ook op zich wel correct te modelleren, maar met een modellering van een keuze is dit veel duidelijker.

Use case 3: een keuze tussen meerdere manieren om invulling te geven aan 1 betekenisvol attribuutsoort van een objecttype
Er is sprake van ofwel attribuutsoort A0 en aanvullend hierbij een keuze tussen ofwel attribuutsoort A1 ofwel attribuutsoort A2. In MIM modelleren we daarom voor A1 en A2 een keuze tussen de 2 attribuutsoorten. Het maken van deze keuze is verplicht.

We modelleren daarom een Keuze BetalingskenmerkOfOmschrijving met daarin een attribuutsoort betalingskenmerk en een attribuutsoort omschrijving. Het is bij deze use case niet de bedoeling om het attribuutsoort beschrijving kwijt te raken in de modellering. De binding van de Keuze BetalingskenmerkOfOmschrijving is daarom aan het attribuutsoort. De binding van het attribuutsoort beschrijving gebeurt door aan te geven dat BetalingskenmerkOfOmschrijving het type is van beschrijving.

In dit voorbeeld vormt BetalingskenmerkOfOmschrijving de Keuze als geheel. De attribuutsoorten zelf zijn de keuze mogelijkheden, maar blijven in de modellering van de metaclass attribuutsoort en behoren in deze zin niet tot de modellering van de metaclass keuze.

Opmerking: use case 2 en 3 zijn voor een groot deel overeenkomstig. De overeenkomst is dat de keuze tussen de twee attribuutsoorten betalingskenmerk en omschrijving hetzelfde gemodelleerd wordt, als een keuze, met bijvoorbeeld de naam BetalingskemerkOfOmschrijving. Het verschil zit in de binding tussen de keuze en het objecttype.

Use case 4: een keuze tussen relatiedoelen, als nadere invulling van een betekenisvolle relatiesoort van een objecttype
Er is sprake van een relatiesoort R0 en aanvullend hierbij een keuze tussen relatiedoel D1 of relatiedoel D2. In MIM modelleren we daarom een keuze tussen de 2 relatiedoelen D1 en D2. Het maken van deze keuze is verplicht.

Het is bij deze use case niet de bedoeling om twee nieuwe relatiesoorten, eigenaar_persoon en eigenaar_bedrijf, te introduceren en al zeker niet om de relatiesoort eigenaar kwijt te raken. We modelleren daarom 1 relatiesoort met de naam eigenaar en een Keuze tussen relatiedoelen.

In het voorbeeld vormen EigenaarKeuze en de twee relatiedoelen tezamen de keuze als geheel. De relatiedoelen zelf zijn de keuze mogelijkheden. De modellering van de relatiesoort eigenaar blijft hetzelfde en behoort niet tot de modellering van de metaclass keuze.

Use case 5: een keuze tussen twee of meer relatiesoorten/relatierollen (elk afzonderlijk betekenisvol)

Er is sprake van een relatiesoort R1 en een relatiesoort R2. R1 heeft als doel een object van objecttype D1 en R2 heeft als doel een object van objecttype 2. In MIM modelleren we daarom een keuze met als uitgaande relatiesoorten R1 en R2. Het maken van deze keuze is verplicht.

In het voorbeeld heeft Vervoermiddel de verplichte keuze tussen de relatiesoorten/rollen heeft als contactpersoon/eigenaar en wordt verhuurd door/verhuurbedrijf.

Toelichting Bijvoorbeeld: BRK. Wanneer bepaalde definities of identificaties van het informatiemodel in de wereld niet uniek zijn, omdat een ander informatiemodel dezelfde naam hanteert voor een modelelement, of eenzelfde structuur voor een identificerende eigenschap, dan is het mogelijk om deze uniek te maken met behulp van deze aanduiding.

Toepassing: Informatiemodel (verplicht)

Toelichting Dit kan zijn: "Conceptueel" of "Logisch". Zoals bedoeld in: 1.6 Typering van modellen gekoppeld aan beschouwingsniveaus. Er moet een keuze gemaakt worden. Dit kan bijvoorbeeld uitgebreid worden met: "Technisch" wanneer er behoefte is om niveau 4 aan te geven.

Toepassing: Informatiemodel (verplicht)

Toelichting Dit kan zijn "Relatiesoort leidend" of "Relatierol leidend". Dit betreft de keuze die je maakt voor het in 1.11 Alternatieven gekozen alternatief. Er moet een keuze gemaakt worden. Deze keuze geldt primair voor de modelelementen «Relatiesoort» en «Relatierol» zoals bedoeld in 3.2.2 Relaties in UML. maar geldt in het verlengde hiervan voor het modelelement externe koppeling.

Toepassing: Informatiemodel (verplicht)

Toelichting Neem hiervoor een door MIM in gebruik zijnde MIM-versie. Kies bij voorkeur een zo recent mogelijke versie.

Bijvoorbeeld: "1.0.1" of "1.1" of "1.1.1"

Toepassing: Informatiemodel (verplicht)

Toelichting Dit metagegeven is optioneel en alleen van toepassing als er sprake is van een extensie zoals bedoeld in 1.10 Een eigen extensie op het metamodel. Neem hiervoor een in gebruik zijnde extensie. Bijvoorbeeld: "Kadaster" of "NEN3610:2022".

Toepassing: Informatiemodel (optioneel)

Toelichting Bijvoorbeeld: "NL", "EN"

Toepassing: Informatiemodel (optioneel)

Toelichting

Bijvoorbeeld: "rtf", "html".

De metagegevens definitie en toelichting bevatten tekst waarvan het nuttig kan zijn om deze op te maken. De opmaak zoals hier bedoeld betreft het verhogen van de leesbaarheid van de tekst, wanneer de modelleur van het model dit nuttig of nodig acht. Deze opmaak is nadrukkelijk niet bedoeld om aan te duiden in welke vorm het model gepubliceerd moet gaan worden (zoals in html, pdf, xml enz). In de MIM gedachte hoort een model vrij te zijn van deze overweging en kan een model in elk van deze, en ook in meerdere vormen tegelijk, gepubliceerd worden.

De tekst kan en mag een bepaalde opmaak bevatten, maar dit hoeft niet. Maar als ervoor gekozen wordt, dan geldt het voor alle definities en alle toelichtingen. Wellicht is opmaak ook van belang voor andere metagegevens (zoals patroon, populatie, kwaliteit en mogelijk andere) maar in deze versie van MIM is de opmaak alleen bedoeld voor definitie en toelichting. Wel kunt u deze opmaak van toepassing verklaren op metagegevens uit uw eigen extensie (zoals bedoeld in 1.10 Een eigen extensie op het metamodel).

Toepassing: Informatiemodel (optioneel)

Toelichting Een uniform resource identifier (URI) is een compacte reeks tekens die een abstracte of fysieke resource identificeert. Een Basis-URI is het gemeenschappelijke deel van deze reeks tekens die voor alle elementen in het informatiemodel geldig is. De Basis-URI bevat altijd een scheme, dit kan bijvoorbeeld http:// of urn zijn. En voldoet aan een gekozen URI-strategie. Wanneer er geen basis-URI is gespecificeerd wordt deze overgenomen van de eerst bovenliggende package met een basis-URI.

Een informatiemodel moet echter ook gebruikt kunnen worden zonder dat er vastgestelde (http-)uri's beschikbaar zijn (bijvoorbeeld tijdens de ontwikkelfase). In dit geval kan een [URN] op basis van de package alias en de naam van het modelelement bepaald worden. Wanneer er geen basis-URI is gespecificeerd wordt deze overgenomen van de eerst bovenliggende package met een basis-URI. Wanneer deze er niet is, wordt er een default waarde bepaald conform het patroon urn:modelelement: + {informatiemodel.naam}: + {package.naam}:. De defaultwaarde voor de Basis-URI van een informatiemodel is dan urn:modelelement: + informatiemodel.naam, bijvoorbeeld "urn:modelelement:imbaglv". Iedere onderliggende package krijgt ook een default Basis-URI die gelijk is aan de basis-URI van het informatiemodel gevolgd door :package.naam, bijvoorbeeld "urn:modelelement:imbaglv:objecten". Dit is noodzakelijk omdat niet alle namen binnen een informatiemodel per definitie uniek zijn (denk aan een objecttype "Locatie" in een domein "Locatie"). De URI van een attribuutsoort "huisnummer" bij een "nummeraanduiding" in domein "objecten" uit het IMBAGLV model wordt dan "urn:modelelement:imbaglv:objecten:nummeraanduiding.huisnummer".

Toepassing: informatiemodel (verplicht), domein, view, extern

De Identificatie kan bepaald worden aan de hand van de Naam van het modelelement en de Basis-URI van de package waarin het modelelement zich bevindt (op logisch niveau conform de naamgevingsconventies). Dit vormt de default waarde. In de meeste gevallen zal een modelleur dit metagegeven niet expliciet invullen maar uitgaan van de defaultwaarde.

In sommige gevallen kan de Identificatie van een modelelement niet bepaald worden aan de hand van de Basis-URI van de bijbehorende package en de Naam van een modelelement. Bijvoorbeeld als gevolg van de gekozen URI-strategie of wanneer een Attribuutsoort uit een ander informatiemodel hergebruikt wordt (e.g. nen3610-2022:identificatie). In dit geval zal de modelleur het metagegeven Identificatie wel invullen.

Toepassing: alle modelelementen

Toelichting

Bijvoorbeeld: "Pand" is de naam van het modelelement «Objecttype», "bouwjaar" is de naam van het modelelement «Attribuutsoort». De modelelementen zijn limitatief opgesomd in 2. Metamodel Algemeen (en eventueel zijn in een uitbreiding extra modelelementen limitatief opgesomd).

Toepassing: alle modelelementen.

Toelichting

Als de naam van iets wat in het informatiemodel gemodelleerd wordt spaties, diakrieten of verbindingstreepjes bevat, zoals een «Objecttype» "Onroerende zaak" of een «Attribuutsoort» "geïnspireerd op", dan kan er gekozen worden om deze naam in het informatiemodel zo op te schrijven dat hier in de techniek makkelijker mee te werken is. Denk aan: "geinspireerd op" (geen diakrieten) of "OnroerendeZaak" (notitiewijze: camelcase). Wanneer de originele schrijfwijze in natuurlijke taal van belang is kan deze worden opgenomen in het metagegeven Alias. Het is niet de bedoeling om (andersom) in de Alias de technische makkelijkere naam op te nemen.

De Alias wordt ook gebruikt voor een alternatieve weergave van een «Enumeratiewaarde». De ‘naam’ betreft hier een daadwerkelijk waarde, zoals "Nederlands", waarin de naam gelijk staat aan de waarde en dit moet zo blijven, maar als er sprake is van een voor documentatiedoeleinde bedoelde codering van deze «Enumeratiewaarde» dan kan deze code in de Alias worden opgenomen.

Toepassing: Objecttype, Attribuutsoort, Gegevensgroep, Relatiesoort, Relatierol, Relatieklasse, Externe Koppeling, Keuze, Enumeratie, Primitief datatype, Gestructureerd datatype, Data-element en expliciet niet voor Packages, Enumeratiewaarde, en Constraint.

Opmerking: 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 Alias te gebruiken. De Alias wordt hier, mede daarom, gebruikt voor (alleen) de modellering van het metagegeven aspect Code die aanvullend is op naam (niet een alternatief van naam).

Toelichting

Hiermee wordt aangegeven hoe een informatiemodel element zich verhoudt tot de begrippen uit het begrippenkader, zoals genoemd in 1.6 Typering van modellen gekoppeld aan beschouwingsniveaus. Dit is niet een 1 op 1 relatie. Voor meer informatie hierover, zie 5. Afspraken & Regels.

Bijvoorbeeld:

• "Perceel";
• "http://brk.basisregistraties.overheid.nl/id/begrip/Perceel"

Toepassing: alle modelelementen met een naam, met uitzondering van Package en Constraint.

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 bron 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 definitie 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.

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 de paragraaf Typen informatiemodellen. 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.

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.

Toelichting

Bijvoorbeeld: een aantal treffende voorbeelden (waardes) van het kenmerk van het object of een aanduiding van wat er niet onder de definitie valt.

Het is niet de bedoeling om andere metagegevens in de toelichting op te nemen, zoals populatie of begrip. De toelichting is op zichzelf helder en te begrijpen en is gericht op de betekenis van gegevens en/of de context van deze gegevens. De toelichting is niet gericht op de inwinning van de gegevens maar beschrijft de betekenis van hetgeen wat ingewonnen is, zodat het voor de gebruikers van de gegevens helder is wat de betekenis ervan is. Het is daarom niet de bedoeling om inwinregels of veelgestelde vragen zelf in de toelichting op te nemen. Uiteraard is het wel goed om kennis die in de inwinregels en antwoorden "verborgen" zit een plek te geven in de toelichting.

Toepassing: alle modelelementen die het metagegeven definitie kennen.

Toelichting

Bijvoorbeeld: "1-1-2012".

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

Toelichting: objecten hebben, of krijgen, in een administratie of gegevensvoorziening vaak één identificerend kenmerk. Het kan ook zijn dat een aantal kenmerken in combinatie identificerend zijn, zoals twee attribuutsoorten of een attribuutsoort en een relatiesoort. De combinatie met een relatiesoort wordt alleen gedaan voor objecttypes die zelf geen unieke aanduiding hebben en daarom deze moeten samenstellen met de unieke aanduiding van een gerelateerde objecttype. Het modelelement «Referentielijst» is het enige type waardelijst die dit metagegeven kan hebben, omdat de enumeratie zelf identificerend is en de uniek identificerende code van een codelijst zich buiten het informatiemodel bevindt.

Toepassing: attribuutsoort, alle relaties (relatiesoort, relatierol, relatieklasse, externe koppeling), referentie-element.

Toelichting

Bijvoorbeeld: "Ja", "Nee".

Met de tijdlijn geldigheid wordt bedoeld dat er op een tijdlijn wordt bijgehouden wanneer een verandering is opgetreden in de werkelijkheid die heeft geleid tot verandering van de waarde van een kenmerk van een object. Het gegeven is vanaf een bepaald tijdsmoment geldig en dit tijdsmoment wordt op enerlei wijze als metagegeven bijgehouden bij het gegeven.

Het komt vaak voor dat er besloten wordt of bepaald wordt dat een gegeven al geldig is of werd vanaf een bepaald tijdsmoment in het verleden en het komt voor dat het gegeven pas geldig zal worden vanaf een bepaald tijdsmoment in de (nabije) toekomst. Verdere toelichting, zie 5. Afspraken & Regels.

Met te bevragen wordt bedoeld: het tijdsmoment vanaf wanneer een gegeven als geldig wordt beschouwd (en vanaf wanneer het gegeven niet meer als geldig wordt beschouwd) wordt op enerlei wijze als historie bijgehouden, en deze wijze is te bevragen. Dit metagegeven is alleen betekenisvol voor kenmerken waarvoor een waarde wordt bijgehouden. De in te vullen waarde komt uit 2.4.5 Toegestane waarden metagegevens.

Toepassing: alle modelelementen die een kenmerk (kunnen) zijn van een Objecttype, waarvoor data kan worden bijgehouden: Attribuutsoort en relaties (Relatiesoort, Relatieklasse, Externe Koppeling).

Toelichting

Bijvoorbeeld: "Ja", "Nee".

Met te bevragen wordt bedoeld, er wordt historie bijgehouden op enerlei wijze, welke op enerlei wijze te bevragen is. Dit metagegeven is alleen betekenisvol voor kenmerken waarvoor data wordt bijgehouden. De in te vullen waarde komt uit: zie 2.4.5 Toegestane waarden metagegevens. Materiële historie geeft aan wanneer een verandering is opgetreden in de werkelijkheid die heeft geleid tot verandering van de attribuutwaarde. Verdere toelichting, zie 5. Afspraken & Regels. De in te vullen waarde komt uit: zie 2.4.5 Toegestane waarden metagegevens

Materiële historie geeft aan wanneer een verandering is opgetreden in de werkelijkheid die heeft geleid tot verandering van de attribuutwaarde. Verdere toelichting, zie het hoofdstuk Afspraken & Regels

Toepassing: alle modelelementen die een kenmerk (kunnen) zijn van een Objecttype, waarvoor data kan worden bijgehouden: Attribuutsoort en relaties (Relatiesoort, Relatieklasse, Externe Koppeling).

Toelichting

Bijvoorbeeld: "Ja", "Nee".

Met de tijdlijn registratie wordt bedoeld dat er op een tijdlijn wordt bijgehouden wanneer een bepaalde waarde voor een kenmerk van een object vastgelegd wordt, oftewel geregistreerd wordt. Dit tijdsmoment wordt op enerlei wijze als metagegeven bijgehouden bij het gegeven. De vastlegging kan zijn op een bepaald medium of in een registratie van een informatievoorziening. Het tijdsmoment van vastlegging of registratie is altijd ten tijde van vastlegging van een gegeven in de echte tijd (de horloge tijd). Elke keer dat hetzelfde gegeven op een andere plek wordt vastgelegd is een apart tijdsmoment op de tijdlijn registatie dat relevant kan zijn om bij te houden. Verdere toelichting, zie het hoofdstuk Afspraken & Regels.

Met te bevragen wordt bedoeld: het tijdsmoment wanneer een gegeven geregistreerd is wordt op enerlei wijze als historie bijgehouden, en deze wijze is te bevragen. Dit metagegeven is alleen betekenisvol voor kenmerken waarvoor een waarde wordt bijgehouden. Merk hierbij op dat het moment van registreren in de praktijk vaak, maar niet per definitie, gelijk is aan het moment van beschikbaar komen van een gegeven voor gebruikers van de informatievoorziening. De in te vullen waarde komt uit: zie 2.4.5 Toegestane waarden metagegevens

Toepassing: alle modelelementen die een kenmerk (kunnen) zijn van een Objecttype, waarvoor data kan worden bijgehouden: Attribuutsoort en relaties (Relatiesoort, Relatieklasse, Externe Koppeling).

Toelichting

Bijvoorbeeld: "Ja", "Nee".

Met te bevragen wordt bedoeld, er wordt historie bijgehouden op enerlei wijze, welke op enerlei wijze te bevragen is. Dit metagegeven is alleen betekenisvol voor kenmerken waarvoor data wordt bijgehouden. De in te vullen waarde komt uit: zie 2.4.5 Toegestane waarden metagegevens. Formele historie geeft aan wanneer in de administratie een verandering bekend is, en is verwerkt. Verdere toelichting, zie 5. Afspraken & Regels. De in te vullen waarde komt uit: zie 2.4.5 Toegestane waarden metagegevens

Formele historie geeft aan wanneer in de administratie een verandering bekend is, en is verwerkt. Verdere toelichting, zie 5. Afspraken & Regels.

Toepassing: alle modelelementen die een kenmerk (kunnen) zijn van een Objecttype, waarvoor data kan worden bijgehouden: Attribuutsoort en relaties (Relatiesoort, Relatieklasse, Externe Koppeling).

Toelichting

1. Waarde: 1..1: Een object heeft altijd dit kenmerk. Bijvoorbeeld: geboortedatum persoon.
2. Waarde: 1..*: Een object heeft altijd dit kenmerk en het kenmerk kan meerdere malen voorkomen. Bijvoorbeeld: aantal hoofdstukken in een boek (in dit domein is dat er altijd minimaal 1).
3. Waarde: 0..1: Is soms niet beschikbaar. Bijvoorbeeld: tussenvoegsel achternaam.
4. Waarde: 0..*: Is niet altijd beschikbaar maar het kenmerk kan ook meerdere malen voorkomen. Bijvoorbeeld: verblijfsobjecten die gelegen zijn in een pand (garagebox: 0, huis: 1, flat: *). Andere getallen dan 0, 1 en * zijn ook toegestaan, bijvoorbeeld 2..* of 0..2. De notatie van * verschilt per modelleertaal. Met * wordt bedoeld, veel of vele (niet nader gespecificeerd maar bijvoorbeeld 10 of 100 is toegestaan).

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 5. Afspraken & Regels.

Een «Generalisatie» is een bijzondere vorm van een relatie. De kardinaliteit van de bron en van het doel is hier altijd en per definitie 1..1. Dit hoeft daarom nooit via een aanduiding van een kardinaliteit te worden aangegeven.

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

Voorbeeld: een verblijfsobject ligt in een pand. De eigenaar van de relatie is het verblijfsobject (de bron van de relatie) en het doel van de relatie is een pand.

• De kardinaliteit van het doel van de relatie geeft aan: in hoeveel panden kan één verblijfsobject liggen. Antwoord: 1..*
• De kardinaliteit van de bron geeft aan: hoeveel verblijfsobjecten kunnen er in één pand liggen. Antwoord: 0..*

Deze kardinaliteit is vooral nuttig voor controles, deze komt op data niveau echter (meestal) niet terug omdat relaties in MIM gericht zijn.

Toelichting

De kardinaliteit van de bron van de relatie geeft aan hoeveel instanties van de bron van de relatie kunnen verwijzen naar één instantie van het doel van de relatie. Wanneer de kardinaliteit aan de bronkant van de relatie niet is gespecificeerd dan is er geen sprake van een defaultwaarde.

Toepassing: relatiesoort, externe koppeling en relatieklasse

Toelichting

Bijvoorbeeld:"Authentiek","Basisgegeven","Landelijk kerngegeven","Gemeentelijk kerngegeven","Overig".

Authentiek is van toepassing voor bijvoorbeeld het burgerservicenummer 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 2.4.5 Toegestane waarden metagegevens

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

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.

Hoewel de definitie het niet duidelijk stelt, blijkt uit het voorbeeld dat het gaat om afgeleide gegevens binnen de context van het model. Het metagegeven is dus met andere woorden bedoeld om een afhankelijkheid binnen het model aan te geven.

Toepassing: de modelelementen waarvoor een waarde ingevuld kan worden, te weten de modelelementen Attribuutsoort en Relatiesoort.

Toelichting

Een «Objecttype» kan middels een «Attribuutsoort» geclassificeerd worden in subtypen. Bijvoorbeeld: type gebouw. Een "Toren", "Kerk", "Bunker", "Zwembad" zijn allemaal typen gebouwen. In een model op niveau 2 kunnen dergelijke typen als objecttypen en specialisaties van het «Objecttype» gebouw zijn gemodelleerd. Met name op niveau 3 kan het relevant zijn om deze informatie daadwerkelijk te structureren door expliciet een aspect op te nemen waarmee direct het type gebouw kan worden vastgelegd, los van de modellering van objecttypen.

Praktisch gezien kan vervolgens gekozen worden om de onderliggende objecttypen niet meer in het model op te nemen, en slechts dit aspect op te nemen. Ook kan, in combinatie met Indicatie afleidbaar, dit aspect afgeleid worden uit het meest concrete «Objecttype», indien dergelijke objecttypen wel zijn gemodelleerd. De in te vullen waarde komt uit: zie 2.4.5 Toegestane waarden metagegevens

Toepassing: Attribuutsoort.

Toelichting

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, of 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.

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

Toepassing: de modelelementen waarvoor een waarde ingevuld kan worden, te weten de modelelementen Attribuutsoort en Relatiesoort.

Toelichting

Bijvoorbeeld: een persoon heeft een adres. Dit kun je modelleren door middel van een «Relatiesoort» tussen een «Objecttype» Persoon en een «Objecttype» Adres. Het metagegeven Bron van de «Relatiesoort» bevat dan als waarde: "Persoon".

Toepassing: Relatiesoort en Externe koppeling.

Toelichting

Bijvoorbeeld: een persoon heeft een adres. Dit kun je modelleren door middel van een «Relatiesoort» tussen een «Objecttype» Persoon en een «Objecttype» Adres. Het metagegeven Doel van de «Relatiesoort» bevat dan als waarde: "Adres".

Toepassing: Relatiesoort en Externe koppeling.

Toelichting

Het is gebruikelijk om een richting aan te geven. De betekenis van A naar B is een andere dan van B naar A. Bovendien geeft het aan bij welk «Objecttype» het kenmerk wordt bijgehouden, oftewel wie de eigenaar is.

Bijvoorbeeld: een persoon heeft een postadres. De richting van de relatie is van het «Objecttype» Persoon naar het «Objecttype» Adres. De eigenaar van de relatie (de bron, in dit voorbeeld: Persoon) heeft kennis van de het gerelateerde objecttype (het doel, in dit voorbeeld: Adres).

In een modelleertaal wordt dit vaak aangegeven met een pijl. De pijl heeft als vertrekpunt de bron en heeft als pijlpunt, waar de relatie naar wijst, het gerelateerde «Objecttype». Alle relaties zijn altijd gericht van het bronobject naar het gerelateerde doelobject.

Toepassing: Relatiesoort en Externe koppeling.

Toelichting

Een object kan samengesteld zijn uit samenstellende delen die ook individueel in het informatiemodel als objecttypen herkenbaar zijn. Dit wordt een aggregatie genoemd. Dit wordt gemodelleerd met een Attribuutsoort waarbij dit metagegeven is ingevuld met een type aggregatie. Er zijn twee typen: een compositie aggregatie en een gedeelde aggregatie. De aggregatie is in de basis een relatie en het aggregratietype geeft aanvullende informatie. Standaard is er bij een relatie geen sprake van een aggregatie, dan wordt bij dit metagegeven Geen ingevuld.

• "Compositie" (Engels: "composite"): het doel object is een integraal onderdeel van het eigenaarobject en dit onderdeel wordt niet gedeeld met anderen. De eigenaar is volledig verantwoordelijk voor het beheer van de bijhouding van informatie over het onderdeel. Als de eigenaar vervalt, dan vervallen automatisch ook de onderdelen. Het doel object kan als onderdeel niet zelfstandig bestaan: het doel vervalt als de eigenaar vervalt. Wel kan je een onderdeel vervangen met behoud van het eigenaar object.
• "Gedeeld" (Engels: "shared"): het onderdeel kan gebruikt en gedeeld worden door meerdere eigenaren. Bijvoorbeeld: een leerling maakt deel uit van verschillende klassen.

Bijvoorbeeld: een auto heeft verschillende onderdelen, waaronder een motor. In het informatiemodel gaat het vooral om de auto en is de motor alleen relevant omdat het een onderdeel is van de auto. Een motor kan in dit geval maar door één auto worden gebruikt en als een auto verdwijnt verdwijnt ook de motor. Met andere woorden een motor is een onlosmakelijk onderdeel van een auto en kan niet door een ander object worden gebruikt of zelfstandig bestaan, het is een aggregatie van het type compositie. (Aggregatietype: "Compositie").

Toepassing: Relatiesoort en Externe koppeling.

Toelichting

De plek is een gepubliceerde plek waar gebruikers bij kunnen. Indien mogelijk is dit metagegeven gevuld met (heeft als waarde) een URI of een URL (als er geen URI is, dan kan dit een URL zijn, waar de waardelijst op basis van de naam van de waardelijst te vinden is), bijvoorbeeld: Locatie: http://www.organisatie.nl/schemas/waardelijsten/NaamWaardelijst.

Toepassing: Codelijst en Referentielijst.

Toelichting

Voor de hand liggende formaten waarin een waardelijst is gepubliceerd zijn onder andere SKOS en CSV.

Toepassing: Codelijst en Referentielijst.

Toelichting

Als een «Codelijst» een structuur heeft wordt hiermee aangegeven welk item in de «Codelijst» de waarde representeert.

Toepassing: Codelijst

Toelichting

MIM zegt niets over de technische implementatie van de codelijst. Om een referentie naar informatie over de technische implementatie wel in het model op te nemen is er de mogelijkheid om met het metagegeven Profielspecificatie de specifieke technische toepassing van de codelijst te beschrijven. Bij voorkeur is de referentie door middel van een url.

Toepassing: Codelijst

Het domein van een waarde van een gegeven.

Toelichting

• Bijvoorbeeld: het Type van het kenmerk geometrie is het «Datatype» VlakOfMultivlak;
• Bijvoorbeeld: het Type van het kenmerk achternaam is het «Datatype» CharacterString.

Een «Attribuutsoort» heeft een «Datatype» voor de specificatie van het toegestane waardetype. Hetzelfde geldt voor een «Data-element», een «Referentie-element» en een «Keuze». 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 «Codelijst» 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.

Toepassing: Alle informatie elementen die een attribuut modelleren: Attribuutsoort, Data-element, Referentie-element, Datatypekeuze, Doelkeuze.

De notatiewijze en de betekenis is als volgt:

Voor karakters:

Voor getallen:

Andere getallen dan "1", "2", "3" of "9" kunnen uiteraard gebruikt worden om er de lengte mee te specificeren.

Toelichting

Het gaat bij deze lengte om hoe lang een gegeven in functionele zin mag zijn. Dus, hoeveel karakters en hoeveel getallen voor en na de komma. De lengte heeft betrekking op data waar een modelelement over gaat. Bij een «Attribuutsoort» gaat het om de lengte van de data van het attribuut. Bij een «Gestructureerd datatype» krijgt elk «Data-element» een eigen lengte en gaat het om de lengte van alleen dit «Data-element».

Bijvoorbeeld:

• Een naam van een persoon met minimale lengte 2 en onbegrensd: CharacterString, lengte: "2.."
• Een naam van een openbare ruimte met minimale lengte 2 en maximale lengte 80: CharacterString, lengte: "2..80"
• Een identificatie als getal, van maximaal lengte 16: Integer, lengte: "16"
• Een identificatie van precies lengte 16, met voorloopnullen: CharacterString, lengte: "16"
• Een percentage met 2 getallen achter de komma: Decimal, lengte: "3,2"

Voorheen vaak gebruikt:

• AN80 komt overeen met CharacterString, lengte: "1..80"
• N8 komt overeen met Integer, lengte: "8" (dus van "-99999999" tot en met "+99999999")
• N3,2 komt overeen met Decimal, lengte: "3,2"

Veel voorkomende maximumwaarden voor CharacterString zijn: "80", "200", "4000".

Een getal dat voorloopnullen mag hebben, zoals gemeentecode: "0060", wordt gespecificeerd als een CharacterString. Het getal "0001" bestaat namelijk niet, dit is het getal "1".

De lengte geldt voor gegevens indien er sprake is van een gegeven. Gegevens die optioneel zijn worden leeggelaten, het is daarom niet de bedoeling om voor optionele gegevens een lengte van minimaal "0" te specificeren. Als het gegeven ingevuld is, dan is de lengte minimaal "1".

Het "-"-teken bij een negatief heeft geen gevolgen voor de specificatie van de lengte.

Niet alle eisen aan een gegevens kunnen gespecificeerd worden met een lengte. Gebruik in dat geval Patroon of Formeel patroon of een andere specificatie van de minimale en/of maximale waarde. Bijvoorbeeld:

• Één of twee cijfers achter de komma kan niet gespecificeerd worden met lengte;
• Één of twee cijfers voor de komma kan niet gespecificeerd worden met lengte;
• Een exacte lengte voor een getal, oftewel lengte precies 16 waarbij lengte 1 of 15 niet mag;
• Het waardenbereik van een gegeven, "binnen" deze lengte;
• Of een getal negatief of positief mag zijn.

Toepassing: Attribuutsoort, Primitief datatype (alleen als dit datatype in het IM zelf-gedefinieerd is), Data-element, Referentie-element.

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.

Toepassing: De modelelementen uit de groep Datatype en Attribuutsoort.

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.

Toepassing: Enumeratiewaarde.

Toelichting

Niet-abstract wordt ook wel concreet genoemd. Bijvoorbeeld het abstracte «Objecttype» "Voertuig", met concrete specialisaties "Auto", "Fiets" en "Bromfiets". Dit betekent dat er geen voertuigen mogen bestaan die alleen maar een voertuig zijn en waarbij in het midden gelaten mag worden of het een auto, fiets, bromfiets betreft. Als het "Voertuig" daarentegen niet als abstract is gemodelleerd, dan mogen er wel voertuigen bestaan die alleen maar een voertuig zijn en niet specifiek herkenbaar als een auto, fiets of bromfiets. In beide gevallen kan er over de objecten gesproken worden als zijnde een voertuig en kunnen deze objecten in algemene zin als zodanig behandeld worden (zoals een «Generalisatie» bedoeld is).

Wanneer een «Objecttype» niet abstract is, oftewel concreet, dan kunnen er objecten bestaan die een instantie van «Objecttype» zijn.

Wanneer een «Objecttype» wel abstract is, dan kunnen er geen objecten bestaan die een instantie van dit «Objecttype» zijn. Er moet dan altijd sprake zijn van een concreet (niet abstract) «Objecttype» die het abstracte «Objecttype» als «Generalisatie» heeft. Objecten zijn dan instanties van dit concrete «Objecttype» en geen instanties van het abstracte «Objecttype». Wel voldoen deze objecten beide «Objecttype» definities en kunnen deze objecten in algemene zin als zodanig behandeld worden.

Zie ook sectie 5.5 Abstracte objecttypes en concrete objecten waar een nadere uitleg wordt gegeven van het fenomeen abstract objecttypen.

Toepassing: Objecttype

Toelichting

De definitie van een «Objecttype» geeft aan welke exemplaren in de werkelijkheid bedoeld worden, te weten die exemplaren die aan de definitie voldoen. Het metagegeven Populatie in een (basis)registratie kan in het gebruik echter beperkter zijn, omdat niet alle examplaren die aan de definitie voldoen, worden geregistreerd. Er zijn dan dus examplaren die wel aan de definitie voldoen, maar die niet worden geregistreerd en dus ook niet opgevraagd kunnen worden.

De Populatie is een nadere afbakening op de definitie, een beschrijving van de subset van de verzameling van alle exemplaren van dit «Objecttype» die:

• wel geregistreerd of uitgewisseld worden en/of
• wel aan de definitie voldoen, maar die niet geregistreerd of uitgewisseld worden. Wanneer alle exemplaren die onder de definitie vallen geregistreerd zijn en/of uitgewisseld kunnen worden, dan mag de Populatie worden leeggelaten.

De Populatie kan ook gebruikt worden om aan te geven dat niet alle exemplaren van een «Objecttype» opgenomen zijn in de registratie maar alleen die welke voldoen aan een conditie. De conditie heeft verder geen effect op de definitie.

Toepassing: Objecttype

Toelichting

Dit metagegeven kan een beschrijving bevattten over de kwaliteit van de inwinning van gegevens bij dit objecttype.

Toepassing: Objecttype

Toelichting

In essentie zijn er vier componenten die een meting of een waarneming beschrijven:

1. het onderwerp (wat wordt er gemeten)
2. de waarde (de waarde die gemeten is)
3. het datatype van die waarde (kwalitatief:Boolean, Characterstring, kwantitatief:Integer, Real of Decimal)
4. de eenheid van de waarde

De eerste drie componenten zijn uit te drukken met de modelelementen «Attribuutsoort» en «Datatype». Voor de eenheid van een waarde is een apart metagegeven gecreëerd dat gekoppeld wordt aan een «Attribuutsoort» of een «Referentie-element».

Voor de invulling van het metagegeven Eenheid, sluit het MIM aan bij het Internationale Stelsel van Eenheden [SI]. Een modelleur vult bij Eenheid de unit expression van de eenheid in, bijvoorbeeld: m voor de lengtemaat meter. Een codelijst van mogelijke waarden en bijbehorende symbolen en unit expressions is beschikbaar via SI Reference Point.

Het SI-stelsel bestaat uit zeven basiseenheden. Aanvullend staat het systeem een onbeperkt aantal afgeleide eenheden toe, die altijd kunnen worden uitgedrukt als product van machten van de basiseenheden. Hiervoor zijn SI-prefixen gedefinieerd. Naast de SI-eenheden zijn er een aantal niet-SI-eenheden die wel goedgekeurd zijn voor gebruik in samenstelling met SI-eenheden, zoals: liter, uur, minuut en graden Celsius. Imperiale eenheden, zoals: pound, inch en foot zijn niet goedgekeurde SI-eenheden.

Toepassing: Attribuutsoort, Referentie-element.

Toelichting

Bijvoorbeeld de minimale waarde voor een geldigheidsdatum.

Toepassing

Gebruik op attribuutsoorten, data elementen en referentie-elementen met een primitief datatype van het type:

• Integer
• Decimal
• Float
• Real
• DateTime
• Date

Een modelelement mag maar één voorkomen van metagegeven Minimumwaarde inclusief of Minimumwaarde exclusief hebben.

Toelichting

Bijvoorbeeld de minimale inhoud van een bouwwerk.

Toepassing

Gebruik op attribuutsoorten, data elementen en referentie-elementen met een primitief datatype van het type:

• Integer
• Decimal
• Float
• Real
• DateTime
• Date

Een modelelement mag maar één voorkomen van metagegeven Minimumwaarde inclusief of Minimumwaarde exclusief hebben.

Toelichting

Bijvoorbeeld de minimale waarde voor een geldigheidsdatum.

Toepassing

Gebruik op attribuutsoorten, data elementen en referentie-elementen met een primitief datatype van het type:

• Integer
• Decimal
• Float
• Real
• DateTime
• Date

Een modelelement mag maar één voorkomen van metagegeven Maximumwaarde inclusief of Maximumwaarde exclusief hebben.

Toelichting

Bijvoorbeeld de maximale waarde voor een geldigheidsdatum.

Toepassing

Gebruik op attribuutsoorten, data elementen en referentie-elementen met een primitief datatype van het type:

• Integer
• Decimal
• Float
• Real
• DateTime
• Date

Een modelelement mag maar één voorkomen van metagegeven Maximumwaarde inclusief of Maximumwaarde exclusief hebben.

Toelichting:

Mixin kan gebruikt worden als metagegeven bij een Generalisatie bij logische gegevensmodellen indien er sprake is van multiple inheritance, d.w.z. meerdere superklassen op een subklasse. Het is opgenomen om multiple inheritance implementatie-issues op te lossen in talen/specificaties die dit niet (of niet eenvoudig) ondersteunen. Met Mixin = Ja wordt aangegeven dat deze generalisatie en ook de gerelateerde superklasse niet in de implementatie voorkomt maar dat wel eigenschappen (attribuutsoorten en relatiesoorten/rollen) worden overgenomen door de subklasse. Mixin = Ja geeft de mogelijkheid om de multiple inheritance indien gewenst, in het MIM niveau 3 model te behouden maar er in de implementatie indien nodig rekening, mee te houden. De modelleur kan hiermee aangeven welke generalisatie op een alternatieve manier wordt geïmplementeerd. Talen die multiple inheritance wel ondersteunen negeren dit metagegeven.

Toepassing: Generalisatie en alleen bij MIM niveau 3. Niet gebruiken bij generalisaties tussen datatypen.

Verkorte schrijfwijze: attribuut

Toelichting

Objecttypen, gegevensgroeptypen of relatieklassen hebben attribuutsoorten (0,1,n) voor het specificeren van eigenschappen.

Toepassing: Objecttype, Gegevensgroeptype en Relatieklasse.

Verkorte schrijfwijze: gegevensgroep

Toelichting

Objecttypen en relatieklassen hebben gegevensgroepen (0,1,n) voor het specificeren van groepen van eigenschappen.

Toepassing: Objecttypen met Gegevensgroepen of een Gegevensgroeptype dat zelf ook weer een Gegevensgroeptype bevat.

Verkorte schrijfwijze: gegevensgroeptype

Toelichting

Een attribuut met het stereotype gegevensgroep heeft als waardetype een gegevensgroeptype.

Toepassing: Gegevensgroep.

Verkorte schrijfwijze: supertype

Toelichting

Een subtype verwijst met een generalisatie naar een supertype.

Toepassing: Objecttype en Datatype.

Verkorte schrijfwijze: type

Toelichting

Een datatype wordt onder andere toegekend aan een attribuutsoort.

Toepassing: Attribuutsoort, Keuze, Referentie-element, Data-element

Verkorte schrijfwijze: relatiesoort

Toelichting

Een objecttype kan een relatie hebben naar zichzelf of een ander objecttype.

Toepassing: Objecttype, Gegevensgroeptype.

Verkorte schrijfwijze: externe koppeling

Toelichting

Een objecttype kan een relatie hebben met en objecttype in een extern package.

Toepassing: Objecttype, Gegevensgroeptype.

Verkorte schrijfwijze: data-element

Toelichting

Een gestructureerd datatype bevat meerdere data-elementen.

Toepassing: Gestructureerd datatype.

Verkorte schrijfwijze: modelelement

Toelichting

Een package «Domein» met de naam Activiteiten bevat «Objecttype» Werken, Wonen etc.

Toepassing: Package, Informatiemodel, Domein, Extern, View.

Verkorte schrijfwijze: waarde

Toelichting

Een «Enumeratie» bevat «Enumeratiewaarden».

Toepassing: Enumeratie.

Verkorte schrijfwijze: referentie-element

Toelichting

Een referentielijst bevat referentie-elementen.

Toepassing: Referentielijst.

Verkorte schrijfwijze: datatypekeuze

Toelichting

Een attribuutsoort kan als datatype een keuze uit datatypen hebben.

Toepassing: Attribuutsoort.

Verkorte schrijfwijze: attribuutkeuze

Toelichting

Een keuze tussen attribuutsoorten kan als eigenschap aan een objecttype, gegevensgroeptype of relatieklasse worden gekoppeld.

Toepassing: Objecttype, Gegevensgroeptype, Relatieklasse, Attribuutsoort.

Verkorte schrijfwijze: keuzeattribuut

Toelichting

Een keuze tussen attribuutsoorten bindt 2 of meer attribuutsoorten.

Toepassing: Keuze.

Verkorte schrijfwijze: relatiedoelkeuze

Toelichting

Een keuze tussen relatiedoelen kan als eigenschap aan een objecttype of gegevensgroeptype worden gekoppeld.

Toepassing: Objecttype, Gegevensgroeptype, Keuze.

Verkorte schrijfwijze: relatiesoortkeuze

Toelichting

Een keuze tussen relatiesoorten kan als eigenschap aan een objecttype of gegevensgroeptype worden gekoppeld.

Toepassing: Objecttype, Gegevensgroeptype, Keuze.

Verkorte schrijfwijze: constraint

Toelichting

Een Constraint is gekoppeld aan de context van modelelement waarop ze van toepassing is. Een Constraint kan op alle typen modelelementen worden toegepast.

Een aantal metagegevens hebben als datatype CharacterString. Aanvullend geldt:

• Voor lengtes geldt dat er alleen getallen in mogen (van het datatype Integer).
• Voor datums geldt dat deze het volgende patroon volgen: jjjjmmdd
• Voor de metagegevens Definitie en Toelichting geldt dat hiervoor tekst met opmaak (zoals vet, cursief, onderstreept en opsommingen) gebruikt mag worden. Welke opmaak precies gebruikt kan worden, is afhankelijk van de mogelijkheden van de modelleeromgeving en de beoogde toepassing van het model. Gebruik hiervoor het metagegeven tekstopmaak.

Voor de volgende metagegevens geldt een specifiek waardebereik.

De metagegevens met Ja en Nee zijn semantisch bedoeld als een boolean (er zijn geen andere waarden mogelijk zoals onbekend, overig of geen waarde (leeg)). Voor technische implementatiedoeleinden is het toegestaan om Ja en Nee te interpreteren en eventueel te vervangen door een Boolean. Let wel, voor mens-leesbare functionele documentatie horen altijd de in de tabel aangegeven waarden Ja en Nee te worden gebruikt.

Er zijn metagegevens die een defaultwaarde hebben. Het is echter niet nodig om deze defaultwaarde expliciet aan te geven in het informatiemodel. De default staat hier aangegeven. Alleen wanneer er afgeweken wordt van deze default wordt dit in het informatiemodel aangegeven.

Constraint

Er zijn vijf situaties waarin een keuze toegepast wordt:

• Use case 1: een keuze tussen datatypen
• Use case 2: een keuze tussen twee of meer attribuutsoorten
• Use case 3: een keuze tussen meerdere manieren om één betekenisvol attribuutsoort in te vullen
• Use case 4: een keuze tussen relatiedoelen, als nadere invulling van één betekenisvolle relatiesoort
• Use case 5: een keuze tussen relatiesoorten/relatierollen (elk afzonderlijk betekenisvol)

Voor elke toepassing geldt een aparte subset van het metamodel. De keuzeconstructie maakt een keuze mogelijk tussen meerdere datatypen, attribuutsoorten en relatiedoelen. In UML behouden we dezelfde modellering: een datatype blijft dus een datatype, een attribuutsoort een attribuutsoort en een relatiesoort een relatiesoort. De UML-elementen die het stereotype keuze krijgen zijn zelf geen datatype, attribuutsoort of relatiedoel. Merk op dat de diagrammen op metamodelniveau zijn gemodelleerd. Hoe dit op informatiemodelniveau uitpakt is onder het diagram beschreven in tekst.

Use case 1: Keuze tussen datatypen

Dit UML is uitgewerkt voor Objecttype. Voor Gegevensgroeptype en Relatieklasse geldt hetzelfde patroon.

Modellering van deze Keuze in een informatiemodel:

• Modelleer een UML-Datatype met stereotype keuze.
• Modelleer hierin 2 of meer MIM-Datatypen: neem hiervoor eerst een UML-attribute met stereotype keuze op in de Keuze zoals gemodelleerd in punt 1, dit UML-attribute krijgt als typering het gewenste (MIM) Datatype. Merk op dat dit extra UML-attribute is zelf geen keuze mogelijkheid is, de keuze is immers tussen de datatypen.

Gebruik de Keuze voor een (MIM) Attrituutsoort:

• Kies een MIM-Attribuutsoort en koppel de hiervoor gemodelleerde Keuze hieraan via een typering, zoals gebruikelijk.

Use case 2: Keuze tussen 2 of meer attribuutsoorten

Dit UML is uitgewerkt voor Objecttype. Voor Gegevensgroeptype en Relatieklasse geldt hetzelfde patroon.

Modellering van deze Keuze in een informatiemodel:

• Modelleer in UML een UML-Class met stereotype keuze.
• Modelleer hierin 2 of meer MIM-Attribuutsoorten: elk (MIM) Attribuutsoort wordt gemodelleerd zoals gebruikelijk, door een UML-Property (attribute) met stereotype attribuutsoort (en deze UML-Property (attribute) heeft zelf weer als typering een MIM-Datatype).

Gebruik de Keuze voor het (MIM) Objecttype of het (MIM) Gegevensgroeptype:

• Modelleer in een (MIM) Objecttype of in een (MIM) Gegevensgroeptype een _UML-Property (attribute) met stereotype keuze en koppel de hiervoor gemodelleerde Keuze hieraan, via een typering, zoals gebruikelijk. Aan dit stereotype keuze is te zien dat deze UML-Property zelf geen (MIM) Attribuutsoort is van het objecttype. Immers, alleen de met stereotype Attribuutsoort aangeduide UML-properties (attributes) zijn een (MIM) Attribuutsoort.

Er is hier voor de aankoppeling gekozen voor een UML-Attribute en niet voor een UML-Association in navolging van de modellering van de gegevensgroep en het gegevensgroeptype.

Use case 3: Keuze tussen meerdere manieren om 1 betekenisvol attribuutsoort in te vullen

Dit UML is uitgewerkt voor Objecttype. Voor Gegevensgroeptype en Relatieklasse geldt hetzelfde patroon.

Modellering van deze Keuze in een informatiemodel:

• Modelleer in UML een UML-Class met stereotype keuze.
• Modelleer hierin twee of meer keuze mogelijkheden door voor elke keuze mogelijkheid een UML-Property (attribute) te modelleren met stereotype keuze (en deze UML-Property heeft als datatype een MIM-Datatype). Aan dit stereotype keuze is te zien dat deze UML-Property (attribute) zelf geen (MIM) Attribuutsoort is van het objecttype. Immers, alleen een met stereotype Attribuutsoort aangeduid UML-attribute is een (MIM) Attribuutsoort.

Gebruik de Keuze voor de (MIM) Attribuutsoort:

• Modelleer in een (MIM) Objecttype of in een (MIM) Gegevensgroeptype een MIM-Attribuutsoort zoals gebruikelijk, en koppel de hiervoor gemodelleerde Keuze hieraan, via een typering, zoals gebruikelijk.

Use case 4: Keuze tussen relatiedoelen, als nadere invulling van 1 betekenisvolle relatiesoort

Dit UML is uitgewerkt voor Objecttype. Voor Gegevensgroeptype geldt hetzelfde patroon, behalve dat een Gegevensgroeptype geen doel mag zijn van een Relatiesoort.

Modellering van deze Keuze in een informatiemodel:

• Modelleer in UML een UML-Class met stereotype Keuze.
• Modelleer hierin 2 of meer uitgaande UML-Association met stereotype Keuze die elk een (MIM) Objecttype als relatiedoel hebben. Aan dit stereotype Keuze is te zien dat deze UML-Association zelf geen relatiesoort of externe koppeling is.

Gebruik de Keuze voor het (MIM) Objecttype of het (MIM) Gegevensgroeptype:

• Modelleer in een (MIM) Objecttype of in een (MIM) Gegevensgroeptype een (MIM) Relatiesoort of (MIM) Externe koppeling. Deze worden gemodelleerd zoals gebruikelijk.

Use case 5: Keuze tussen relatiesoorten/relatierollen (elk afzonderlijk betekenisvol)

Dit UML is uitgewerkt voor Objecttype. Voor Gegevensgroeptype geldt hetzelfde patroon, behalve dat een Gegevensgroeptype geen doel mag zijn van een Relatiesoort.

Modellering van deze Keuze in een informatiemodel:

• Modelleer in UML een UML-Class met stereotype keuze.
• Modelleer hierin 2 of meer MIM-Relatiesoorten die elk een relatiedoel hebben. Elke (MIM) Relatiesoort wordt gemodelleerd zoals gebruikelijk, door een UML-Property (association) met stereotype relatiesoort of externe koppeling en met een relatiedoel (een relatierol aan de doel/target kan van de relatie).

Gebruik de Keuze voor het (MIM) Objecttype of het (MIM) Gegevensgroeptype:

• Modelleer in een (MIM) Objecttype of in een (MIM) Gegevensgroeptype een UML-Association met stereotype keuze en koppel de hiervoor gemodelleerde Keuze hieraan, als target van de UML-association, zoals gebruikelijk. Aan dit stereotype keuze is te zien dat deze UML-Association zelf geen relatiesoort of externe koppeling is.

De modellering van een Keuze in UML

Er zijn drie metaklassen met de naam Keuze maar elke keer als extensie van een andere UML metaklasse, waar ook uit blijkt om welke variant van de keuze het gaat.

• Als een UML Class met stereotype keuze is gebruikt, dan zitten hierin alleen attribuutsoorten en/of relatiedoelen, de attribuutsoorten en relatiedoelen waaruit gekozen kan worden.
• Als een UML Datatype met stereotype keuze is gebruikt, dan zitten hierin alleen datatypen, de datatypen waaruit gekozen kan worden.
• Als een UML Property met stereotype keuze is gebruikt, dan is er sprake van een hulpconstructie om het modelelement Keuze aan te koppelen aan het MIM-modelelement waarvoor de keuze geldt.

Merk op dat deze tabel niet gaat over de modelelementen waaruit een keuze gemaakt moet worden. Dat zijn immers de modelelementen datatype, attribuutsoort en relatiesoort. Deze tabel gaat over de modellering van Keuze in UML oftewel de extra hulpconstructies die in UML nodig zijn om de modelelementen waaruit een keuze gemaakt moet worden aan te koppelen aan het MIM-modelelement waarvoor de keuze geldt. Deze extra hulpconstructies krijgen als stereotype keuze en dit geeft aan dat de betekenis hiervan anders is dan de betekenis van de MIM-elementen datatype, attribuutsoort en relatiesoort.

Relatiesoort en relatierol

Externe koppeling

In de bijlage is het UML diagram met de metagegevens opgenomen.

Packages

De objecttypen worden naar de volgende aspecten gespecificeerd:

De attribuutsoorten worden naar de volgende aspecten gespecificeerd:

De gegevensgroepen worden naar de volgende aspecten gespecificeerd:

De gegevensgroeptypen worden naar de volgende aspecten gespecificeerd:

De relatiesoorten worden naar de volgende aspecten gespecificeerd.

De relatiesoorten worden naar de volgende aspecten gespecificeerd.

Relatierollen worden naar de volgende aspecten gespecificeerd.

Voor relatierol worden bij de target rol van een relatiesoort de volgende aspecten gespecificeerd.

De generalisaties worden naar het volgende aspecten gespecificeerd:

De generalisaties worden naar de volgende aspecten gespecificeerd:

De relatieklassen worden naar de volgende aspecten gespecificeerd:

Externe koppelingen worden naar de volgende aspecten gespecificeerd.

Voor codelijst worden de volgende aspecten gespecificeerd:

Enumeraties betreffen de metaclass Enumeration en worden naar de volgende aspecten gespecificeerd:

De enumeratiewaarde zelf betreft de metaclass UML-EnumerationLiteral en kent de volgende aspecten:

Voor referentielijsten worden de volgende aspecten gespecificeerd:

De referentie-elementen worden naar de volgende aspecten gespecificeerd:

De primitieve datatypen worden naar de volgende aspecten gespecificeerd:

Voor gestructureerde datatypen worden de volgende aspecten gespecificeerd:

De data-elementen worden naar de volgende aspecten gespecificeerd:

Een Keuze worden naar de volgende aspecten gespecificeerd:

Opmerking: de modelelementen waaruit gekozen kan worden heten sinds MIM 1.1 geen keuze-elementen meer. Keuze-element is komen te vervallen.

Domein packages worden naar de volgende aspecten gespecificeerd:

Externe packages worden naar de volgende aspecten gespecificeerd:

Informatiemodel packages worden naar de volgende aspecten gespecificeerd: