diff --git a/snapshot.html b/snapshot.html index 49707c07..5f710712 100644 --- a/snapshot.html +++ b/snapshot.html @@ -355,7 +355,7 @@ display: none; } } -
- +

MIM - Metamodel Informatie Modellering

Geonovum Standaard
- Versie ter vaststelling

+ Vastgestelde versie
-
Deze versie:
https://docs.geostandaarden.nl/mim/vv-st-mim-20200225/
Laatst gepubliceerde versie:
https://docs.geostandaarden.nl/mim/mim/
+
Deze versie:
https://docs.geostandaarden.nl/mim/def-st-mim-20201023/
Laatst gepubliceerde versie:
https://docs.geostandaarden.nl/mim/mim/
-
Vorige versie:
https://docs.geostandaarden.nl/mim/wv-st-mim11-20191029/
+
Vorige versie:
https://docs.geostandaarden.nl/mim/vv-st-mim-20200225/
Laatste werkversie:
https://geonovum.github.io/MIM-Werkomgeving/
Redacteurs:
Dick Krijtenburg, Geonovum
Jan van Gelder, Geonovum
@@ -956,7 +956,7 @@

Geonovum Standaard
- Creative Commons Attribution 4.0 International Public License + Creative Commons Attribution 4.0 International Public License

Creative Commons Attribution 4.0 International Public License
(CC-BY)

@@ -965,19 +965,19 @@

Geonovum Standaard

-

Samenvatting

Metamodel voor het beschrijven van informatiemodellen (MIM), versie 1.1.

Met deze specificatie kan een informatiemodel gemaakt worden, in deze versie is dit uitgewerkt met UML en met Linked Data. +

Samenvatting

Metamodel voor het beschrijven van informatiemodellen (MIM), versie 1.1.

Met deze specificatie kan een informatiemodel gemaakt worden, in deze versie is dit uitgewerkt met UML en met Linked Data. De beschrijving van MIM kent sinds versie 1.1 een algemeen deel, een deel in UML en nieuw toegevoegd in versie 1.1 is het Hoofdstuk Metamodel in Linked Data (LD). Verder zijn er een aantal nieuwe mogelijkheden toegevoegd die voorzien in gebruikerswensen.

Status van dit document

Deze paragraaf beschrijft de status van dit document ten tijde van publicatie. Het is mogelijk dat er actuelere versies van dit document bestaan. Een lijst van Geonovum publicaties en de laatste gepubliceerde versie van dit document zijn te vinden op https://www.geonovum.nl/geo-standaarden/alle-standaarden.

+ Dit is de definitieve versie van de standaard. Wijzigingen naar aanleiding van consultaties zijn doorgevoerd. - Dit is een definitief concept van de nieuwe versie van de standaard. Wijzigingen naar aanleiding van consultaties zijn doorgevoerd. + De programmaraad van Geonovum heeft deze standaard goedgekeurd. - De programmaraad van Geonovum beoordeelt dit definitief concept. Keurt zij het goed, dan is er een nieuwe standaard.

Colofon en Voorwoord

Colofon

@@ -1118,7 +1118,7 @@

Voorwoord

komen Jan en Katrien zelf niet zelf voor. Zij worden in het informatiemodel gemodelleerd als een Persoon. Ook hun gegevens, zoals het feit dat 10-10-1970 de geboortedatum van Jan is, komen niet voor. In het informatiemodel is alleen het kenmerk geboortedatum gemodelleerd, als een kenmerk van een Persoon.

-

De Persoon in het informatiemodel is ene beschrijving vanuit het perspectief van het informatiedomein van waaruit we Jan en Katrien beschouwen. We bekijken Jan en Katrien dan ook wel als een van de objecten binnen een domein.

In het informatiemodel is hiervoor het objecttype Persoon gedefinieerd en Jan en Katrien zijn dus objecten van het objecttype Persoon. De objecten Domtoren en Paleis Het Loo typeren we tot het objecttype Gebouw. Objecttypen in een informatiemodel representeren dus de dingen in de werkelijkheid.

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 geven relaties tussen obiecten weer, zoals het gegeven dat Jan in Paleis Het Loo woont. Deze modelleren we door middel van een relatiesoort, tussen objecttypen, in dit geval tussen Persoon en Gebouw.

Alle objecten die we als gelijksoortig beschouwen typeren we in het informatiemodel tot een objecttype, de relaties tussen de objecten typeren we in het informatiemodel als een relatiesoort en de kenmerken van de de objecten typeren we in het informatiemodel als attribuutsoorten. Op deze manier ontstaat een informatiemodel. 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, en vervolgens uitgewisseld.

We visualiseren het voorgaande in onderstaande figuur, voor de situatie dat er een, van het informatiemodel afgeleide, registratie is.

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, aparte) informatiemodel anders gemodelleerd zijn. Bijvoorbeeld in het ene domein als werknemer en in het andere domein als persoon of parter. Beide objecten Jan representeren natuurlijk dezelfde ‘Jan uit +

De Persoon in het informatiemodel is ene beschrijving vanuit het perspectief van het informatiedomein van waaruit we Jan en Katrien beschouwen. We bekijken Jan en Katrien dan ook wel als een van de objecten binnen een domein.

In het informatiemodel is hiervoor het objecttype Persoon gedefinieerd en Jan en Katrien zijn dus objecten van het objecttype Persoon. De objecten Domtoren en Paleis Het Loo typeren we tot het objecttype Gebouw. Objecttypen in een informatiemodel representeren dus de dingen in de werkelijkheid.

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 geven relaties tussen obiecten weer, zoals het gegeven dat Jan in Paleis Het Loo woont. Deze modelleren we door middel van een relatiesoort, tussen objecttypen, in dit geval tussen Persoon en Gebouw.

Alle objecten die we als gelijksoortig beschouwen typeren we in het informatiemodel tot een objecttype, de relaties tussen de objecten typeren we in het informatiemodel als een relatiesoort en de kenmerken van de de objecten typeren we in het informatiemodel als attribuutsoorten. Op deze manier ontstaat een informatiemodel. 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, en vervolgens uitgewisseld.

We visualiseren het voorgaande in onderstaande figuur, voor de situatie dat er een, van het informatiemodel afgeleide, registratie is.

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, aparte) informatiemodel anders gemodelleerd zijn. Bijvoorbeeld in het ene domein als werknemer en in het andere domein als persoon of parter. Beide objecten Jan representeren natuurlijk dezelfde ‘Jan uit de werkelijkheid’, vanuit het perspectief van het eigen domein bekeken.

Belangrijke aandachtspunten
Merk op dat we hier veelal spreken over een registratie, omdat dit vaak zo is. Er zijn echter ook toepassingen van een informatiemodel waarin er alleen gegevens worden uitgewisseld, of waarbij er sprake is van gewoon de beschrijving van informatie, ongeacht of deze wel of niet in een registratie is opgenomen.

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.

Het is hierbij de bedoeling dat een informatiemodel de betekenis en definitie van de informatie zelf beschrijft, onafhankelijk van een mogelijke (technische) implementatie of toepassingsomgeving. Zodat het primair helder is wat de informatie betekent, ongeacht waar je deze informatie tegenkomt en ongeacht de gebruikte techniek. Anders gezegd, in koppelvlakken, ketens en implementaties is het vrij om de elk technisch uitwisselingsformaat of bijvoorbeeld database technologie te kiezen, door het informatiemodel daarin uit te drukken. @@ -1484,7 +1484,7 @@

Voorwoord

Relatierol doel -

De betekenis van deze modelelementen en de beschrijvingen ervan staat in Objecttypen en attribuutsoorten en in Relaties.

In diagramvorm:

Kern zonder Metagegevens

De verbindingen tussen de modelelementen geven aan welke combinaties kunnen voorkomen op metamodelniveau, oftewel welke modelelementen in een informatiemodel met elkaar gecombineerd kunnen worden. Bijvoorbeeld:

2.1.3 Overige

View 3a: constraint en keuze.

+

In diagramvorm:

Diagram: Datatypen zonder Metagegevens

2.1.3 Overige

View 3a: constraint en keuze.

@@ -1535,18 +1535,18 @@

Voorwoord

MIM metaclass Keuze

De betekenis van deze modelelementen en de beschrijvingen ervan staan in Overige modelelementen

In diagram vorm: - +

Diagram: Constraint

Keuze

Er zijn vier situaties/use cases waarin een keuze toegepast wordt:

Beschrijving: Keuze

Keuze tussen:

Voor elk geldt een eigen subset van het metamodel.

In diagramvorm: -

Use case 1: Keuze tussen datatypen

1 attribuutsoort heeft normaal 1 datatype. Als er sprake is van een keuze, dan is het attribuutsoort gekoppeld met een keuze en de keuze geeft 2 of meer datatypen aan.

+

Use case 1: Keuze tussen datatypen

1 attribuutsoort heeft normaal 1 datatype. Als er sprake is van een keuze, dan is het attribuutsoort gekoppeld met een keuze en de keuze geeft 2 of meer datatypen aan.

Diagram: Keuze tussen datatypen

Use case 2: Keuze tussen attribuutsoorten

Een objecttype of gegevensgroep kan normaal een attribuutsoort hebben met een datatype (de lijn links onder). Als er sprake is van een objecttype met een keuze tussen attribuutsoorten, dan is het objecttype gekopppeld met een keuze (de lijn links boven) en de keuze geeft 2 of meer attribuutsoorten aan (met elk een eigen datatype). -

Diagram: Keuze tussen attribuutsoorten

Use case 3: Keuze tussen attribuutsoorten als nadere invulling van 1 betekenisvol attribuutsoort

Een objecttype of gegevensgroep kan normaal een attribuutsoort hebben met een datatype (de lijn links). Als er sprake is van een attribuutsoort met een keuze, dan is het attribuutsoort niet gekoppeld met een datatype, maar dan is het attribuutsoort gekoppeld met een keuze en de keuze geeft 2 of meer attribuutsoorten aan (met elk een eigen datatype). -

Diagram: Keuze tussen attribuutsoorten binnen een attribuutsoort

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

Een objecttype of gegevensgroep kan normaal een relatiesoort hebben, die gekoppeld is aan een objecttype. Als er sprake is van een relatiesoort met een keuze, dan is het relatiedoel van de relatiesoort niet gekoppeld aan 1 objecttype, maar dan is het objecttype gekoppeld aan een keuze en deze keuze geeft 2 of meer relatiedoelen aan. -

+

Diagram: Keuze tussen attribuutsoorten

Use case 3: Keuze tussen attribuutsoorten als nadere invulling van 1 betekenisvol attribuutsoort

Een objecttype of gegevensgroep kan normaal een attribuutsoort hebben met een datatype (de lijn links). Als er sprake is van een attribuutsoort met een keuze, dan is het attribuutsoort niet gekoppeld met een datatype, maar dan is het attribuutsoort gekoppeld met een keuze en de keuze geeft 2 of meer attribuutsoorten aan (met elk een eigen datatype). +

Diagram: Keuze tussen attribuutsoorten binnen een attribuutsoort

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

Een objecttype of gegevensgroep kan normaal een relatiesoort hebben, die gekoppeld is aan een objecttype. Als er sprake is van een relatiesoort met een keuze, dan is het relatiedoel van de relatiesoort niet gekoppeld aan 1 objecttype, maar dan is het objecttype gekoppeld aan een keuze en deze keuze geeft 2 of meer relatiedoelen aan. +

Diagram: Keuze tussen relatiedoelen

Relatierol

View 3b: Relatiesoort en relatierol

@@ -1563,7 +1563,7 @@

Voorwoord

Relatierol doel

In diagramvorm: -

Diagram: Relatierol

Externe koppeling

View 3c: Externe koppelingen. Deze bestaat uit de volgende modelelementen:

+

Diagram: Relatierol

Externe koppeling

View 3c: Externe koppelingen. Deze bestaat uit de volgende modelelementen:

@@ -1592,7 +1592,7 @@

Voorwoord

MIM metaclass View

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

In diagramvorm: -

Diagram: groepering

2.2 Objecttypen en attribuutsoorten

In deze paragraaf staan alle modelelementen opgesomd, die gebruikt worden bij +

Diagram: groepering

2.2 Objecttypen en attribuutsoorten

In deze paragraaf staan alle modelelementen opgesomd, die gebruikt worden bij het maken van een informatiemodel.

2.2.1 Objecten en objecttype

Een objecttype is een groep van gelijksoortige objecten. Zo zijn Jan en Katrien allebei objecten die gelijksoortig zijn. Het zijn allebei personen, oftewel het objecttype van beiden is Persoon. In het informatiemodel nemen we Persoon op met @@ -2356,7 +2356,7 @@

Voorwoord

De 2e en 3e kolom bevatten de uitdrukking van het MIM in UML, versie 2.5. De 2e en 4e kolom bevatten de uitdrukking van het MIM in Sparx Enterprise Architect. Deze gebruikt Class (i.p.v. UML-Class). Deze UML tool is (uiteraard) geen onderdeel van de MIM specificatie. Het is zeker niet verplicht om deze te gebruiken, u kunt uw eigen tool gebruiken. Deze kolom staat erbij om illustratief aan te geven dat het soms nodig kan zijn om, afhankelijk van de tool, net iets specifieker aan te geven hoe het MIM in de tool exact uitgedrukt wordt.

Bijna alle hebben een UML-metaclass (UML 2.5) als basis, deze is dan aangegeven als ‘blauw gekleurde’ metaclasse. Dit is ook opgenomen in diagramvorm, in de bijlage Template naamgeving -conventies.

De ten opzichte van MIM versie 1.0.1 gewijzigde modelelementen zijn in rood aangegeven.

3.1.1 Kern

Kern zonder Metagegevens

+conventies.

De ten opzichte van MIM versie 1.0.1 gewijzigde modelelementen zijn in rood aangegeven.

3.1.1 Kern

Kern zonder Metagegevens

@@ -2407,7 +2407,7 @@

Voorwoord

-
MIM metaclass (UML) Association én (UML) Class Associationclass

3.1.2 Datatypen

Datatypen zonder Metagegevens

View 2: Datatypen

+

3.1.2 Datatypen

Datatypen zonder Metagegevens

View 2: Datatypen

@@ -2468,7 +2468,7 @@

Voorwoord

gebruik van de bestaande UML-enumeration (metaclass) voor de specificaties van een enumeratie.

Voor enumeratiewaarde is geen stereotype gespecificeerd. In het metamodel maken we gebruik van de bestaande UML-enumerationLiteral (metaclass) voor de -specificaties van een enumeratiewaarde.

3.1.3 Overige

Constraint

Constraint

View 3a: Constraint

MIM metaclass
+specificaties van een enumeratiewaarde.

3.1.3 Overige

Constraint

Constraint

View 3a: Constraint

@@ -2491,10 +2491,10 @@

Voorwoord

  • attribuutsoorten binnen een attribuutsoort
  • relatiedoelen

    • Voor elk geldt een eigens subset van het metamodel.

    Keuze tussen datatypen -

    Keuze tussen attribuutsoorten -

    Keuze tussen attribuutsoorten binnen een attribuutsoort -

    Keuze tussen relatiedoelen -

    De 'keuze constructie' maakt een keuze mogelijk tussen meerdere attribuutsoorten, datatypen en relatiedoelen. Er zijn drie metaklassen met de naam Keuze maar elke keer als extensie van een andere UML metaklasse. Ook is er de metaklasse datatype als extensie van de uml metaklasse property. Een attribuut kan hiermee als keuze attribuut getypeerd worden.

    MIM metaclass
    +

    Keuze tussen attribuutsoorten +

    Keuze tussen attribuutsoorten binnen een attribuutsoort +

    Keuze tussen relatiedoelen +

    De 'keuze constructie' maakt een keuze mogelijk tussen meerdere attribuutsoorten, datatypen en relatiedoelen. Er zijn drie metaklassen met de naam Keuze maar elke keer als extensie van een andere UML metaklasse. Ook is er de metaklasse datatype als extensie van de uml metaklasse property. Een attribuut kan hiermee als keuze attribuut getypeerd worden.

    @@ -2527,7 +2527,7 @@

    Voorwoord

    -
    MIM metaclass (UML) Property Attribute

    Relatierol

    Relatierol

    View 3b: Relatiesoort en relatierol

    +

    Relatierol

    Relatierol

    View 3b: Relatiesoort en relatierol

    @@ -2569,7 +2569,7 @@

    Voorwoord

    -
    MIM metaclass (UML) Association Association

    View 3c: Groepering

    Packages

    +

    View 3c: Groepering

    Packages

    @@ -2618,20 +2618,20 @@

    Voorwoord

    Identificerend

    Als een attribuutsoort identificerend is, dan krijgt dit kenmerk in UML isId = true.

    Als een relatiesoort identificerend is, dan krijgt dit kenmerk in UML een -stereotype «id»

    Noot
    In de hierna volgende paragrafen worden de metagegevens per modelelement gespecificeerd
-in tabellen. Per metagegeven zijn de volgdende onderdelen gespecificeerd:
-- Aspect: Het benoemde metagegeven. Met aanduiding √ is conform stelselafspraken voor
-basisregistraties. Een \* is conform de stelselcatalogus. Zie ook de paragraaf in H3
-hierover.  
-- Kardinaliteit: Aantal maal dat een metagegeven opgenomen kan worden bij dit
-modelelement.
-- Toelichting:*Nadere uitleg over het metagegeven.
-- In UML 2.5: De naam waarmee het het metagegeven in UML2.5 is benoemd. Het betreft
-veelal overerving van een metagegeven van een UML metaclass die niet in dit document
-is benoemd.
-- In EA: Aanduiding hoe het metagegeven in Sparx Enterprise Architect (EA) is aangegeven.
-Rode tekst betreft een standaardelement binnen EA. Zwarte tekst in de kolom betreft
-een uitbreiding op het UML Metamodel, via tagged values of aanvullende stereotypes.
+stereotype «id»
    Noot
    In de hierna volgende paragrafen worden de metagegevens per modelelement gespecificeerd
+in tabellen. Per metagegeven zijn de volgdende onderdelen gespecificeerd:
+- Aspect: Het benoemde metagegeven. Met aanduiding √ is conform stelselafspraken voor
+basisregistraties. Een \* is conform de stelselcatalogus. Zie ook de paragraaf in H3
+hierover.  
+- Kardinaliteit: Aantal maal dat een metagegeven opgenomen kan worden bij dit
+modelelement.
+- Toelichting:*Nadere uitleg over het metagegeven.
+- In UML 2.5: De naam waarmee het het metagegeven in UML2.5 is benoemd. Het betreft
+veelal overerving van een metagegeven van een UML metaclass die niet in dit document
+is benoemd.
+- In EA: Aanduiding hoe het metagegeven in Sparx Enterprise Architect (EA) is aangegeven.
+Rode tekst betreft een standaardelement binnen EA. Zwarte tekst in de kolom betreft
+een uitbreiding op het UML Metamodel, via tagged values of aanvullende stereotypes.
 
    3.2.1 Modellering metagegevens voor objecten en attributen in UML
    Specificatie voor «Objecttype»
    De objecttypen worden naar de volgende aspecten gespecificeerd:
    MIM metaclass
    @@ -4340,7 +4340,7 @@

    Voorwoord

    Voor de omzetting van de gegevensconstraints (zoals cardinaliteiten, datatypen en properties per klasse), is op de volgende manier een SHACL shape graph gemaakt:

    1. Elk voorkomen van een MIM «metaclass» kent ook een sh:NodeShape met een sh:name die overeen komt de originele technische naam (UpperCamelCase);
    2. Voor elk voorkomen van een MIM «metaclass» zijn sh:PropertyShapes aangemaakt om aan te geven welke metagegevens zijn toegestaan voor een MIM «metaclass», de kardinaliteiten en het datatype c.q. de geassocieerde MIM «metaclass».
      3. -

    4.2.1 Kern

    Als prefix wordt voor de vocabulaire gebruik gemaakt van mim, met de namespace http://bp4mc2.org/def/mim#. Voor de shapes wordt als prefix gebruik gemaakt van shape, met als namespace http://bp4mc2.org/def/mim-shapes#.

    +

    4.2.1 Kern

    Als prefix wordt voor de vocabulaire gebruik gemaakt van mim, met de namespace http://bp4mc2.org/def/mim#. Voor de shapes wordt als prefix gebruik gemaakt van shape, met als namespace http://bp4mc2.org/def/mim-shapes#.

    @@ -4391,7 +4391,7 @@

    Voorwoord

     -
    MIM metaclassshape:Relatieklasse grondslag

    4.2.2 Datatypen

    +

    4.2.2 Datatypen

    @@ -4454,7 +4454,7 @@

    Voorwoord

     -
    MIM metaclassshape:Codelijst grondslag

    4.2.3 Overige

    4.2.3.1 Constraint

    +

    4.2.3 Overige

    4.2.3.1 Constraint

    @@ -4512,7 +4512,7 @@

    Voorwoord

     -
    MIM metaclassshape:Attribuutsoort grondslag

    Datatypekeuze

    Aangezien een mim:Keuze een specialisatie is van een mim:Datatype, mag een attribuutsoort via een mim:type een verwijzen naar een Keuze. Een dergelijk keuze heeft in dit geval zelf minimaal twee mim:type verwijzingen naar de 2 (of meer) datatypen waaruit gekozen wordt.

    Attribuutkeuze

    Indien een mim:Keuze wordt gebruikt voor een keuze tussen attribuutsoorten, dan wordt vanuit een objecttype via een mim:attribuut niet verwezen naar een attribuutsoort, maar naar de keuze. De keuze zelf verwijst op zijn beurt naar de attribuutsoorten waartussen gekozen wordt.

    Relatiedoelkeuze

    Indien een mim:Keuze wordt gebruikt voor een keuze tussen objecttypen die de relatiedoelen zijn voor een relatiesoort, dan wordt vanuit een relatiesoort via een mim:doel niet verwezen naar een objecttype, maar naar de keuze. De keuze zelf verwijst op zijn beurt naar de objecttypen waartussen gekozen wordt.

    Relatiesoortkeuze

    Een keuze tussen relatiesoorten wordt gedaan op basis van een keuzeconstraint. Een keuzeconstraint is geen datatype, maar juist een constraint die in dit geval aangeeft dat er een keuze gemaakt moet worden tussen twee relatiesoorten.

    4.2.3.3 Relatierol

    +

    Datatypekeuze

    Aangezien een mim:Keuze een specialisatie is van een mim:Datatype, mag een attribuutsoort via een mim:type een verwijzen naar een Keuze. Een dergelijk keuze heeft in dit geval zelf minimaal twee mim:type verwijzingen naar de 2 (of meer) datatypen waaruit gekozen wordt.

    Attribuutkeuze

    Indien een mim:Keuze wordt gebruikt voor een keuze tussen attribuutsoorten, dan wordt vanuit een objecttype via een mim:attribuut niet verwezen naar een attribuutsoort, maar naar de keuze. De keuze zelf verwijst op zijn beurt naar de attribuutsoorten waartussen gekozen wordt.

    Relatiedoelkeuze

    Indien een mim:Keuze wordt gebruikt voor een keuze tussen objecttypen die de relatiedoelen zijn voor een relatiesoort, dan wordt vanuit een relatiesoort via een mim:doel niet verwezen naar een objecttype, maar naar de keuze. De keuze zelf verwijst op zijn beurt naar de objecttypen waartussen gekozen wordt.

    Relatiesoortkeuze

    Een keuze tussen relatiesoorten wordt gedaan op basis van een keuzeconstraint. Een keuzeconstraint is geen datatype, maar juist een constraint die in dit geval aangeeft dat er een keuze gemaakt moet worden tussen twee relatiesoorten.

    4.2.3.3 Relatierol

    @@ -4554,7 +4554,7 @@

    Voorwoord

     -
    MIM metaclassshape:ExterneKoppeling grondslag
    4.2.3.5 Packages

    +
    4.2.3.5 Packages

    @@ -6701,7 +6701,7 @@

    Voorwoord

    mag géén spatie bevatten.
  • Een Vlak: een verbijzondering van een GM Surface, met een eigen definitie, die bijvoorbeeld
    aangeeft dat het om een 2 dimensionale geometrie gaat.
    • -

    Datatypen Generalisatie

    Datatypen Generalisatie

    De gele datatypes zijn extern aan het model.

    Het type modelelement (stereotype) verandert niet door de generalisatie. Een +

    Datatypen Generalisatie

    Datatypen Generalisatie

    De gele datatypes zijn extern aan het model.

    Het type modelelement (stereotype) verandert niet door de generalisatie. Een zelf gedefinieerd primitief datatype zal een generalisatie hebben met een ander primitief datatype. Een zelf gedefinieerd gestructureerd datatype zal een generalisatie hebben met een ander gestructureerd datatype.

    Het komt voor dat het zelf gedefinieerde datatype een generalisatie heeft naar @@ -6886,7 +6886,7 @@

    Voorwoord

    Voorbeeld 14
    - 
    *Specialisatie / generalisatie*
+          
    *Specialisatie / generalisatie*
 Bovenstaande vragen beantwoorden we aan de hand van het voorbeeld van een het 
 opleidingsinstituut.  In de beschouwde werkelijkheid onderscheiden we onder 
 meer als gespreksonderwerp personen. Deze personen kunnen docenten en 
@@ -6914,7 +6914,7 @@ 
    Voorwoord
    
 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.
+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
@@ -6974,8 +6974,8 @@ 
    Voorwoord
    
           
    
       Voorbeeld 15
     
    
-          
    Een Perceel kan vanwege een Perceel splitsing overgaan in twee of meerdere
-andere Percelen. De ‘overgegaan in’ relatie wordt bijgehouden in een
+          
    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
@@ -7078,13 +7078,13 @@ 
    Voorwoord
    
           
    
       Voorbeeld 16
     
    
-          
    ‘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. 
+          
    ‘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 
+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. 
 
 
@@ -7096,7 +7096,7 @@ 
    Voorwoord
    
 
 
 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 
+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
@@ -7251,18 +7251,18 @@ 
    Voorwoord
    
           
    
       Voorbeeld 19
     
    
-          
    In IMKAD zit het objecttype: «Objecttype» Persoon. Hierin zitten de attributen
+          
    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
+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
+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.
@@ -7271,7 +7271,7 @@ 
    Voorwoord
    
 
 
 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
+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.
@@ -7511,11 +7511,11 @@ 
    Voorwoord
    
 de definitie veranderd, en de informatievoorziening hier niet mee in
 overeensteming is. De aanbeveliging is daarom een goede definitie voor het
 modelelement te kiezen, en in de metadata een verwijzing op te nemen naar het
-begrip en hierna handmatig de overeenstemming tussen de definities te beheren.
    5.18 Overig
    5.18.1 Volgorde van kenmerken
    De volgorde van kenmerken in een objecttype, gegevensgroeptype, gestructureerd datatype in een visueel diagram van een informatiemodel kan voor de leesbaarheid van het diagram worden aangebracht, maar heeft in principe, buiten het diagram, geen betekenis.
    6. Bijlagen
    6.1 Diagrammen
    6.1.1 Overzicht toegepaste UML metaclasses
    6.1.2 Modelelementen en metagegevens als diagram
    Deze bijlage bevat alle modelelementen en metagegevens in één diagram.
    Kern - Relatiesoort is leidend
    Kern - Relatierol is leidend
    Datatypen
    Constraints
    Keuze
    Keuze tussen datatypen
-
    Keuze tussen attribuutsoorten
-
    Keuze tussen attribuutsoorten binnen de context van een attribuutsoort
-
    Keuze tussen relatiedoelen
-
    Packages
    6.2 Template naamgeving conventies
    MIM metaclass
    +begrip en hierna handmatig de overeenstemming tussen de definities te beheren.

    5.18 Overig

    5.18.1 Volgorde van kenmerken

    De volgorde van kenmerken in een objecttype, gegevensgroeptype, gestructureerd datatype in een visueel diagram van een informatiemodel kan voor de leesbaarheid van het diagram worden aangebracht, maar heeft in principe, buiten het diagram, geen betekenis.

    6. Bijlagen

    6.1 Diagrammen

    6.1.1 Overzicht toegepaste UML metaclasses

    6.1.2 Modelelementen en metagegevens als diagram

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

    Kern - Relatiesoort is leidend

    Kern - Relatierol is leidend

    Datatypen

    Constraints

    Keuze

    Keuze tussen datatypen +

    Keuze tussen attribuutsoorten +

    Keuze tussen attribuutsoorten binnen de context van een attribuutsoort +

    Keuze tussen relatiedoelen +

    Packages

    6.2 Template naamgeving conventies

    @@ -9998,4 +9998,5 @@

    Voorwoord

    A.1 Normatieve referenties

    [GAB]
    GAB. URL: https://www.noraonline.nl/wiki/Gemeenschappelijke_Afspraken_Berichten
    [GeoJSON]
    GeoJSON. URL: https://geojson.org/
    [gml]
    Geography Markup Language (GML) Encoding Standard. Open Geospatial Consortium Inc. URL: http://www.opengeospatial.org/standards/gml
    [iso-11404]
    11404:2008 Information technology – General Purpose Datatypes (GPD). URL: http://noraonline.nl/wiki/Gegevensbeschrijvingen/Handreiking
    [iso-19103]
    Geographic information -- Conceptual schema language. ISO/TC 211. ISO. 2015. International Standard. URL: https://www.iso.org/standard/56734.html
    [iso-8601]
    Representation of dates and times. ISO 8601:2004.. International Organization for Standardization (ISO). 2004. ISO 8601:2004. URL: http://www.iso.org/iso/catalogue_detail?csnumber=40874
    [Linked-Data]
    Linked Data. URL: https://www.noraonline.nl/wiki/Linked_Data
    [MDA]
    Model Driven Architecture (MDA) Guide. rev. 2.0, 1-6-2014.
    [NEN3610]
    NEN-3610 Basismodel geo-informatie. 2016. URL: https://www.nen.nl/NEN-Shop/Norm/NEN-36102011-nl.htm
    [NORA]
    Handreiking gegevensbeschrijving (NORA). URL: http://noraonline.nl/wiki/Gegevensbeschrijvingen/Handreiking
    [OCL]
    OCL. URL: http://www.omg.org/spec/OCL/2.4/
    [ODM]
    Ontology Definition Metamodel. versie 1.1, September 2014. URL: https://www.omg.org/spec/ODM/1.1
    [OMG]
    OMG Unified Modeling Language TM. versie 2.5. URL: http://www.omg.org/spec/UML/2.5
    [OWL2-PRIMER]
    OWL 2 Web Ontology Language Primer (Second Edition). Pascal Hitzler; Markus Krötzsch; Bijan Parsia; Peter Patel-Schneider; Sebastian Rudolph. W3C. 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-primer/
    [RDF11-CONCEPTS]
    RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
    [RDF11-PRIMER]
    RDF 1.1 Primer. Guus Schreiber; Yves Raimond. W3C. 24 June 2014. W3C Note. URL: https://www.w3.org/TR/rdf11-primer/
    [REGEXP]
    Formeel patroon (Reguliere Expressies). URL: http://perldoc.perl.org/perlre.html
    [SCAT]
    Stelselcatalogus. URL: http://www.stelselcatalogus.nl
    [SHACL]
    Shapes Constraint Language (SHACL). Holger Knublauch; Dimitris Kontokostas. W3C. 20 July 2017. W3C Recommendation. URL: https://www.w3.org/TR/shacl/
    [SOAP]
    SOAP Specifications. URL: https://www.w3.org/TR/SOAP/
    [UML]
    Unified Modeling Language (UML). URL: http://uml.org
    [xml]
    Extensible Markup Language (XML) 1.0 (Fifth Edition). Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau et al. W3C. 26 November 2008. W3C Recommendation. URL: https://www.w3.org/TR/xml/
    -
    \ No newline at end of file + \ No newline at end of file
    Modelelement