Skip to content

Latest commit

 

History

History
772 lines (572 loc) · 78.8 KB

AfsprakenRegels.md

File metadata and controls

772 lines (572 loc) · 78.8 KB
Raw

Afspraken & Regels

In deze paragraaf gaan we in op een aantal aspecten van het zojuist beschreven metamodel en afspraken en regels die van toepassing zijn voor een informatiemodel.

Datatype(n)

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

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

  1. Primitief datatype: data zoals "Amersfoort" of "10" worden vastgelegd als CharacterString en Integer. Dit volgt de internationale standaarden voor datatypen.
  2. Landelijk datatype (volgens het GAB): datatypen zoals: Postcode, DMO en DTMO (zie ook: [[[#landelijk-datatype]]]).
  3. Zelfgedefinieerd datatype: data zoals NietNegatieveInteger, AN (Alfanumerieke waarde) of een Vlak.
  4. Gestructureerd datatype: een combinatie van data, zoals een bedrag: "5 euro", opgebouwd uit waarde = "5" en munteenheid = "euro"), of een GM_Surface. Deze volgen ook internationale of nationale standaarden.

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

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

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

Primitief datatype

Dit metamodel onderkend (momenteel) de volgende extern gedefinieerde primitive datatypen. Deze zijn allemaal gebaseerd op [[!GAB]]:

Primitive type Betekenis
CharacterString Zie [[!iso-19103]]. Vrij vertaald: alle alfanumerieke tekens en speciale tekens die horen bij de gekozen characterset (standaard UTF-8), dus met diakrieten, white spaces, \-teken en newlines of HTML opmaak e.d. Mag starten met spatie. De maximale lengte is onbepaald. Opmerking: getallen (ISO Numbers) met voorloopnullen worden opgenomen als CharacterString, met een patroon of formeel patroon. Bij het metagegeven Waardenverzameling attribuutsoort wordt dit dan (ook) gespecificeerd.
Integer Zie [[!iso-19103]] (subtype van ISO Number). Vrij vertaald: geheel getal, lengte is minimaal 1 en maximale lengte is onbepaald, zonder voorloopnullen. Opmerking: t.a.v. positieve en negatieve getalen en + en – tekens: bijvoorbeeld -2,0 Het (formeel) patroon geeft aan of een + en/of - teken gebruikt mag worden in het gegeven.
Real Zie [[!iso-19103]] (subtype van ISO Number). Vrij vertaald: een real is een zwevendekommagetal, waarbij de precisie bepaald wordt door het aantal getoonde cijfers. Het getoonde getal is een schatting en geeft niet noodzakelijk de exacte waarde weer. Opmerking 1: Dit verschilt van decimal, want decimal is een exacte waarde en real is geschat. Opmerking 2: t.a.v. positieve en negatieve getalen en + en – tekens: zie Integer.
Decimal Zie [[!iso-19103]] (subtype van ISO Number). Vrij vertaald: een decimal is een gegevenstype waarin het getal een exacte waarde vertegenwoordigt, als een eindige weergave van een decimaal getal. Aangezien veel valuta's decimaal zijn, hebben deze weergaven de voorkeur bij het omgaan met dergelijke waarden. Opmerking 1: Dit verschilt van real, want real is een geschatte waarde en Decimal is exact. Opmerking 2: t.a.v. positieve en negatieve getalen en + en – tekens: zie Integer.
Boolean Indicatie met mogelijke waarden True, false, 1 of 0. True en 1 hebben een identieke betekenis: Ja. False en 0 hebben een identieke betekenis: Nee. Opmerking: t.a.v. Ja of Nee. Wanneer u de Ja of Nee wilt gebruiken, gebruik dan bv. een Enumeratie genaamd Indicatie, of gebruik AN met een lengte en een (formeel) patroon.
Date 4-cijferig jaar, 2-cijferig maand, 2-cijferig dag uitgedrukt in yyyy-mm-dd conform https://en.wikipedia.org/wiki/ISO_8601
DateTime yyyy-mm-ddThh:mm:ss conform https://en.wikipedia.org/wiki/ISO_8601
Year 4-cijferig jaar uitgedrukt in yyyy conform https://en.wikipedia.org/wiki/ISO_8601
Day 2-cijferige dag uitgedrukt in dd conform https://en.wikipedia.org/wiki/ISO_8601
Month 2-cijferige maand uitgedrukt in mm conform https://en.wikipedia.org/wiki/ISO_8601
URI Unieke identificatie op internet conform RFC3986 en de URI-strategie Linked Open Data. Gestandaardiseerde manier om op het internet dingen (pagina's met informatie, objecten, datasets) uniek te identificeren.

Het is mogelijk om in de eigen extensie extra primitive datatypen op te nemen, zodat deze ook beschikbaar komen voor het informatiemodel.

Getallen en negatieve getallen

Met een getal kan worden gerekend. Bijvoorbeeld: saldo, hoeveelheid, aantal, grootte.

Een getal kan negatief zijn. Dit is inherent aan een getal. Het - of + teken heeft geen invloed op de lengte van het getal. Als er dus een lengte wordt gespecificeerd, tel het - of + teken dan niet mee. Als een getal niet negatief mag zijn, geef dit dan aan in een patroon (zie NonNegativeInteger).

Aanbeveling: als er niet mee gerekend kan worden, zoals de bankrekening zelf (waar een saldo op staat, maar die bedoelen we hier expliciet niet), gebruik dan een CharacterString met een patroon.

Waardenbereik en patroon

Het waardenbereik van een attribuut kan vastgelegd worden middels de combinatie van een primitieve en een patroon dat als restrictie is opgenomen. Bijvoorbeeld bij een postcode, of een gemeentecode die moet bestaan uit precies 4 getallen, waarbij het eerste getal een 0 mag zijn.

We onderkennen twee soorten patronen:

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

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

Zelfgedefinieerd datatype

Het is ook mogelijk om in het eigen informatiemodel een eigen datatype te definiëren in de vorm van een «Primitief datatype», «Codelijst» of «Referentielijst». Zelf-gedefinieerde datatypen hebben altijd een eigen definitie en optioneel een eigen patroon of formeel patroon.

Ter illustratie enkele voorbeelden van zelfgedefinieerde datatypen die niet tot MIM behoren:
  • NietNegatieveInteger: een Integer die alleen de waarde ,0 of groter mag hebben. Laat de naam van het primitieve type dan wel terugkomen in de naam (dus niet NietNegatiefGetal).
  • Decimal: Een beperking op een Real te specificeren door een Decimal op te nemen (een gebroken getal, met (één of meer) cijfers voor de komma en cijfers achter de komma, conform ISO11404).
  • AN. Deze is gebruikelijk bij een aantal basisregistraties. Datatype met een eigen naam, analoog aan CharacterString, maar met alleen ‘normale’ tekens. Dit zijn alle alfanumerieke tekens (dus inclusief diakrieten), de koppeltekens – en _ en spaties. De minimale lengte is tenminste 1, de maximale lengte is onbepaald. De 1e positie mag géén spatie bevatten.
  • Een Vlak: een verbijzondering van een GM Surface, met een eigen definitie, die bijvoorbeeld aangeeft dat het om een tweedimensionale geometrie gaat.
De resolutie van onderstaande afbeelding is te laag. Daardoor zijn de teksten in de diagram onleesbaar.

Diagram: Datatypen Generalisatie

Datatypen Generalisatie

De gele datatypen 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 een extern gedefinieerd datatype, waarvan het modelelement (stereotype) niet is gespecificeerd. Maak dan zelf een inschatting. Let hierbij op bij een «Gestructureerd datatype». Deze hoort altijd twee of meer data elementen te hebben.

Landelijk Datatype

Wanneer op landelijk niveau afspraken zijn gemaakt (bijvoorbeeld in GAB), voor algemene datatypen, die niet primitief zijn, zoals Postcode, dan worden deze niet in dit MIM metamodel opgenomen. Wel geeft MIM aan hoe deze in informatiemodellen gedefinieerd en gemodelleerd worden.

Voorbeelden hiervan van landelijke datatypen, die niet tot MIM behoren, maar ter illustratie zijn opgenomen:

Datatype Beschrijving
Postcode De in Nederland gangbare postcode voor een Nederlands postadres, bestaande uit een numeriek deel en een alfabetisch deel. Het numerieke deel van de postcode bestaat uit vier cijfers, het alfabetische deel van de postcode bestaat uit twee hoofdletters. Conform [GAB Postcodes].
DMO Datum mogelijk onvolledig. De keuze («Keuze») van een periode in de Gregoriaanse kalender, al naar gelang de beschikbare datumelementen, uit de onderliggende subformaten alleen Year, Year en Month of Year, Month en Day. Dit is (nog steeds) overeenkomstig met https://en.wikipedia.org/wiki/ISO_8601 en [GAB DatumMogelijkOnvolledig].
DTMO Een volledige datum waarbij (alleen) de tijd mogelijk ontbreekt. De tijd wordt, zover bekend, ingevuld. Dus alleen de uren als de minuten onbekend zijn. DateTime, als de tijd wel volledig bekend is. Date, als alleen de Date bekend is

Gestructureerd datatype

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

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

Bijvoorbeeld een Bedrag, dat bestaat uit een hoeveelheid en een muntsoort. Het aantal zelf is nietszeggend, tenzij ook aangegeven wordt welke muntsoort het betreft. Elk data-element in een Gestructureerd datatype heeft zelf ook weer een datatype (in zeer bijzondere gevallen kan een data-element zelf ook weer een Gestructureerd datatype zijn).

Gestructureerd datatype representeren als één gegevenselement

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

Als een patroon of formeel patroon gedefinieerd is op het gestructureerde datatype (als geheel), dan worden de data-elementen van het gestructureerde datatype altijd als één gegevenselement uitgewisseld. Als dit patroon niet gedefinieerd is, dan worden de data-elementen als losse gegevenselementen uitgewisseld (de standaardwijze voor een Gestructureerd datatype).

Een uitgewerkt voorbeeld van een Gestructureerd datatype met patroon is Objectnummering. Dit Gestructureerd datatype bestaat uit de data elementen: - Gemeentecode (AN, lengte 4) - Objecttypecode (AN, lengte 2) - Nummer (AN, lengte 10) met daarbij een formeel patroon: [0-9]{4}\.[0-9]{2}\.[ 0-9]{10} of een (tekst) patroon Gemeentecode.Objecttypecode.Nummer

Gegevensgroeptype

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

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

Hergebruik

Het kan voorkomen dat meerdere objecttypes gebruik maken van dezelfde gegevensgroeptype, omdat de definitie voor alle objecttypes gelijk is of moet zijn. Het is dan modelmatig mogelijk om zo’n gegevensgroeptype te hergebruiken Op conceptueel niveau is dit ongebruikelijk, omdat kenmerken / eigenschappen exclusief bij een object horen, maar het is wel toegestaan. Het is hierbij belangrijk om goed te kijken of er echt sprake is van een gegevensgroeptype, of dat er (toch) sprake is van een objecttype. Bijvoorbeeld van een objecttype die voor zijn bestaan afhankelijk is van een ander objecttype (en daarom via een «Relatiesoort» met aggregatietype ‘composite’ (het gesloten wiebertje) gekoppeld moet worden). Het is aan de modelleur om deze beoordeling te maken.

Een voorbeeld van het hergebruik van een gegevensgroeptype door meerdere objecttypen is de specificatie voor het Brondocument in de basisregistratie BAG. Het gegevensgroeptype Brondocument is qua betekenis en structuur voor alle objecttypes gelijk. De definitie en specificatie ervan wordt daarom hergebruikt bij alle objecttypes. Het brondocument wordt binnen de BAG niet gezien als een van de typen objecten van de BAG, en daarom is het geen objecttype maar een gegevensgroeptype.

Metamodel: het gegevensgroeptype kan dus het type zijn van meer dan 1 gegevensgroep. Vanwege dit hergebruik is daarom de kardinaliteit van de relatie van gegevensgroep naar gegevensgroeptype aan de source kant 1..*. Zie Kern.

Gegevensgroep versus Gestructureerd datatype

Een gegevensgroep is niet hetzelfde als een Gestructureerd datatype.

  • Een datatype beschrijft de structuur van data, een gegevensgroep beschrijft de semantiek van een kenmerk van een object.
  • Als één kenmerk van een object uit verschillende stukjes data bestaat, dan wordt een Gestructureerd datatype gebruikt. Dit is bijvoorbeeld het geval bij het gestructureerde datatype Bedrag. Deze bestaat uit een 'hoeveelheid' en 'muntsoort'.
  • Als een object meerdere kenmerken heeft, gemodelleerd als afzonderlijke attribuutsoorten, dan heeft elk kenmerk op zichzelf betekenis. Als één kenmerk wordt weggelaten, of niet bekend of ingewonnen is, dan verandert er niets aan de betekenis van de andere attribuutsoorten.
  • Een ander goed criterium is: als het datatype wordt weggelaten uit het informatiemodel, dan verliest het informatiemodel geen semantiek. Alleen de structuur van een gegeven is dan niet meer bekend.

Regel: het is niet de bedoeling dat eenzelfde kenmerk van een object in het ene model als een gegevensgroep gemodelleerd wordt en in het andere model als een Gestructureerd datatype. Er raakt dan semantiek verloren of er ontbreekt dan semantiek.

  • Een Gestructureerd datatype in een conceptueel informatiemodel is en blijft dus altijd ook een Gestructureerd datatype in een bijbehorende logisch informatiemodel. Een gegevensgroep in een conceptueel model is en blijft dus altijd ook een gegevensgroep in een logisch informatiemodel.

Keuze tussen datatypen (Keuze)

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

PuntOfVlak is daarbij een Keuze met keuze element: punt, met als type het datatype GM_Point en keuze element vlak met als type het datatype GM_Surface.

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

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

BereikOfWaarde is daarbij een Keuze met keuze element ‘bereik’, met als type het datatype Interval en keuze element "waarde" met als type het datatype Real.

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

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

Domeinwaarden of lijsten

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

Enumeraties

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

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

Referentielijst

Een lijst waarin we de betekenis en structuur van de lijst expliciet willen specificeren. Een voorbeeld is de «Referentielijst» LAND of CultuurcodeOnbebouwd. De «Referentielijst» is hiermee een bijzondere vorm van datatype.

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

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

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

CodeList

Gebruik een «Codelijst» als in het informatiemodel de attributen, zoals bij een «Referentielijst», niet relevant zijn en je voor de definitie alleen wilt verwijzen naar de externe waardelijst.

Abstracte objecttypes en concrete objecten

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

Conceptueel informatiemodel

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 leerlingen zijn. Over al deze gespreksonderwerpen willen we gegevens communiceren. Een docent heeft als kenmerk dat deze een arbeidscontract met het opleidingsinstituut heeft afgesloten en een lesbevoegdheid heeft, terwijl een leerling kenbaar heeft gemaakt lessen te willen gaan volgen bij het instituut en dus geen arbeidscontract heeft afgesloten. Docenten en leerlingen zijn personen die rechten en plichten hebben.

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

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

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

Richtlijnen - Een abstract object is een onderwerp van gesprek binnen het beschouwde gebied. Het heeft dus echt een betekenis in het beschouwde gebied. Net als een concreet object, specialisatie of generalisatie.

  • De definitie van elk objecttype (dus ook een abstract objecttype) is zodanig dat ondubbelzinnig bepaald kan worden dat een object wel of niet tot het gedefinieerde type behoort. Dus niet een objecttype met een definitie als ‘De gemeenschappelijke eigenschappen van een object…’ Deze definitie is op elk objecttype van toepassing.
  • Houd er rekening mee dat afhankelijk van het te beschouwen gebied een object uit de werkelijkheid in het ene informatiemodel een concreet objecttype kan zijn en in het andere informatiemodel een abstract objecttype.

Logisch informatiemodel

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

Algemeen

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

Relatieklasse (uitzonderingen)

Een «Relatiesoort» met kardinaliteit 1..* van «Objecttype» A naar «Objecttype» B betekent dat er op instantie niveau * relaties liggen van een bronobject naar een doelobject. Bv. een relatie van specifiek object a1 (van «Objecttype» A) naar een specifiek object b1 (van «Objecttype» B) en een andere relatie van hetzelfde object a1 (van «Objecttype» A) naar object b2 (van «Objecttype» B).

Voor een relatieklasse geldt dit eveneens. Een «Relatieklasse» met kardinaliteit 1..* van «Objecttype» C naar «Objecttype» D betekent dat er op instantie niveau * relaties liggen van een bronobject naar een doelobject. Bv. een relatie van specifiek object c1 (van «Objecttype» C) naar een specifiek object d1 (van «Objecttype» D) en een andere relatie van hetzelfde object c1 (van «Objecttype» C) naar object d2 (van «Objecttype» D).

Voor elk van deze relaties zijn er extra gegevens aan de orde. Deze gegevens worden als kenmerken (eigenschappen) gemodelleerd in een «Relatieklasse» met een bepaalde kardinaliteit. Deze gegevens kunnen dan worden vastgesteld en vastgelegd wanneer er sprake is van een relatie tussen een object van «Objecttype» C naar een object van «Objecttype» D. Merk op dat deze gegevens, dit setje gegevens, voor elke relatie apart vastgesteld en vastgelegd wordt. Zo kunnen voor de relatie van c1 naar d1 andere gegevens worden vastgesteld en vastgelegd dan voor de relatie van c1 naar d2.

Opmerkingen:

  • een relatiesoort met kardinaliteit * van objecttype A naar objecttype B en een relatieklasse met kardinaliteit * van objecttype C naar objecttype D bestaat op instantie nivea uit * losse relaties (en niet uit 1 relatie van 1 bronobject naar * doelobjecten);
  • de gegevens over de relatie bestaan alleen zolang de relatie tussen beide objecten bestaat en zolang elk van beide objecten zelf (nog) bestaan. wanneer een van beide niet meer bestaat, bestaat de relatie niet meer en hiermee komen ook de gegevens over de relatie te vervallen.

Uitzondering situatie - dezelfde gegevens voor meerdere relaties

Het is echter mogelijk dat dezelfde gegevens voor meerdere relaties tegelijk gelden.

Het is dan niet mogelijk om het te modelleren als relatieklasse. Wel gewenst, maar het kan niet als UML-associationClass. Als deze uitzondering het geval is, dan worden de relatieklasses gemodelleerd als «Objecttype», met één inkomende relatie en één uitgaande relatie. De oorspronkelijke kardinaliteit van de beoogde relatieklasse wordt hierbij behouden.

De relatie is geobjectiveerd. Elke betrokken relatie wordt in dit geval behandeld als een object met gegevens.

Een Perceel kan vanwege een Perceel splitsing overgaan in twee of meerdere
andere Percelen. De ‘overgegaan in’ relatie wordt bijgehouden als een
relatieklasse met eigen (splitsing) gegevens. Bij een splitsing ontstaan * nieuwe percelen 
en er is daarom sprake van meerdere relaties. De gegevens over de splitsing zijn echter altijd 
voor al deze relaties gelijk. Om deze reden wordt de relatieklasse 'overgegaan in' gemodelleerd als 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.

Opmerkingen:

  • de gegevens over de relatie bestaan alleen zolang de relatie tussen beide objecten bestaat en zolang elk van beide objecten zelf (nog) bestaan. Dit is echter niet meer te zien aan de metaklasse, omdat dit «Objecttype» is geworden en niet meer «Relatieklasse» is. Geef daarom in de toelichting van het objecttype aan dat elk object van dit objecttype bestaansafhankelijk is van de beide objecttypen die verbonden zijn door deze geobjectiveerde relatie.
  • normaal gesproken bij relaties tussen objecten wordt de relatie op instantie niveau geïdentificeerd door de identificaties van beide betrokken objecten. Er zijn geen aparte regels voor de opbouw van de identificatie van een relatieklasse (en ook niet voor geobjectiveerde relatieklassen die als objecttypen zijn gemodelleerd). Anders gezegd, een regel zoals dat de identificatie van een relatieklasse (of geobjectiveerde relatieklassen die als objecttypen zijn gemodelleerd) is opgebouwd uit de samenstelling van de identificatie van bron en doel objecten is niet aanwezig in de MIM specificatie. Evenzo bestaat er in MIM geen regel of best practise dat er een nieuwe betekenisloze identificatie toegekend moet worden. Het is aan de modelleur om hierin eigen afwegingen te maken.

Uitzondering - relatieklasse tussen 3 of meer objecttypen.

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

Constraint toepassen

Deze paragraaf gaat dieper in op hoe een «Constraint» toegepast wordt. Twee constraints die gedefinieerd zijn op hetzelfde modelelement mogen niet dezelfde naam hebben.

Een «Constraint» wordt beschreven met een:

  1. Naam (UML-constraint name): een naam c.q. label, vaak in steekwoorden.
  2. Specificatie in tekst (UML-Constraint Notes, type invariant): een uitgebreide heldere beschrijving van de «Constraint» in gewone tekst.
  3. [Optioneel] Specificatie formeel (UML-Constraint Notes, type OCL): formele specificatie in de [[[OCL]]] (OCL). De formele specificatie bevat dus de uitgebreide heldere beschrijving van de constraint in (a.) gewone tekst én (b.) de formele specificatie in OCL.

In Enterprise Architect 12.x lijkt het helaas (nog) niet mogelijk om constraints zoals bedoeld in UML op te nemen, te weten als OpaqueExpression met een constraint string en een aanduiding van de taal: natuurlijke taal, of OCL (of een andere zoals Java, maar deze wordt niet toegepast in dit metamodel). EA werkt met UML Notes en een constraint type.

Het is daarnaast niet mogelijk om de tekst en de OCL in dezelfde constraint op te nemen. Het worden dan twee aparte constraints: één met tekst en één met OCL, met verplicht ook een andere naam. Vandaar onderstaande aanpak. Als de modelleur kiest om de «Constraint» alleen in gewone taal te beschrijven, dan als volgt:

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

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

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

Aanbeveling: als een eigenschap van één «UML-attribute, of één «UML-association» met een «Patroon» of een «Lengte» of een «Kardinaliteit» van een «Relatiesoort» vastgelegd kan worden, gebruik die dan en geen «UML-constraint». Als er sprake is van een eigenschap die over meerdere informatiemodelelementen heen gaat, dan is er altijd sprake van een regel die we modelleren met een «UML-constraint».

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

Naam van het constraint

idNummeraanduidingBAGEnOfLocatieomschrijving

Specificatie in tekst

/* Het adres middels idNummeraanduidingBAG en/of de locatieomschrijving moet gevuld zijn.*/

Specificatie formeel

inv. (idNummeraanduidingBAG,notEmpty() or locatieomschrijving.netEmpty()) or 
(idNummeraanduidingBAG.notEmpty() and locatieomschrijving.notEmpty())

Historie

Deze paragraaf geeft in meer detail aan wat we onder de metagegevens heeft tijdlijn geldigheid en heeft tijdlijn registratie verstaan (was in MIM 1.1.1 Indicatie materiële historie en heeft tijdlijn registratie).

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

Algemeen

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

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

Tijdlijnen Er spelen twee tijdlijnen een rol bij het herleiden van attribuutwaarden:

  • Wanneer is iets gebeurd, in de werkelijkheid of volgens opgave (wanneer zijn de opgenomen gegevens geldig)? Dit valt binnen de tijdlijn van de aangehouden werkelijkheid, zoals bepaald door een bevoegd gezag (een partij die erover gaat).
  • Vanaf wanneer wist de overheid (als collectief van organisaties) dat de gegevens bekend waren? Dit valt binnen de tijdlijn van het administratieproces of de administratieve werkelijkheid. Op welke moment zijn de gegevens registreerd.

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

Historie op conceptueel niveau

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

Deze metagegevens specificeren we als volgt:

  • heeft tijdlijn geldigheid (of 'indicatie materiele historie'): indicatie of de geldigheid (de materiële historie) van een eigenschap, waarvoor gegevens bijgehouden worden, te bevragen is (moet zijn).

Dit metagegeven impliceert dat actuele, historische en eventuele toekomstige eigenschappen te bevragen zijn op wanneer deze geldig zijn en dat het zinvol is om een tijdlijn geldigheid bij te houden voor de eigenschap, omdat deze kan veranderen. De geldigheid geeft aan wanneer een verandering is opgetreden in de werkelijkheid (materiële historie) die heeft geleid tot verandering van de eigenschap. Het komt voor dat de geldigheid van een eigenschap wordt besloten, zoals wanneer bepaalde regelgeving geldig wordt, of wanneer een vergunning wordt verleend. Veelal gebeurd dit met een geldigheid die gelegen is in de (nabije) toekomst, maar het geldig worden kan ook in het verleden liggen.

Merk op: de heeft tijdlijn geldigheid geeft op conceptueel niveau niet aan dat er voor het gegeven een tijdlijn geldigheid wordt bijgehouden in de administratie. Het geeft aan dat een eigenschap kan veranderen en er op de tijdlijn geldigheid verschillende waarden kunnen bestaan (op verschillende momenten).

  • heeft tijdlijn registratie (of 'indicatie formele historie'): indicatie dat het registratiemoment (de formele historie) van een eigenschap, waarvoor gegevens bijgehouden worden, te bevragen is (moet zijn).

Dit metagegeven impliceert dat het registratiemoment wordt bijgehouden van wanneer in de administratie een verandering van een eigenschap is verwerkt. Hiermee kan de administratie antwoord te geven op de vraag: vanaf wanneer de nieuwe waarde voor de eigenschap bekend in de administratie (het nieuwe gegeven). Als dit relevant is om te weten, geef dan de 'heeft tijdlijn registratie' = 'Ja' aan. Dit metagegeven hangt sterk samen met de vraag: wanneer had een afnemer die behoefte heeft aan deze informatie deze informatie kunnen weten, als deze dit aan de administratie had gevraagd (eerder dan het registratiemoment is niet mogelijk). Het registratiemoment hiervan is altijd een moment in de echte tijd, de 'horloge' tijd. Er kunnen vele tijdsmomenten relevant zijn, zoals een tijdstip van een besluit, een tijdstip van het ontvangen van een melding of beschreven gebeurtenis bij een organisatie, het tijdstip van de registratie in een administratie, het tijdstip dat het gegeven beschikbaar is gekomen voor afnemers en meer. Het metagegeven 'heeft registratie tijdlijn' heeft alleen betrekking op de eis dat het registratiemoment te bevragen is vanuit een administratie. De andere tijdmomenten zijn ook vaak erg relevant, maar dit zijn eigenstandige functionele momenten.

‘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. Het pand kan maar 1x initieel gebouwd zijn. Net zoals een mens maar 1 geboortedatum heeft. 
    
De ‘heeft tijdlijn geldigheid’ ervan is daarom 'Nee'. 

Het is dus in principe niet nodig om voor deze eigenschap een tijdlijn geldigheid (materiele historie) bij te houden. Althans niet op conceptueel niveau. Er kan een fout gemaakt kan zijn bij de registratie van dit gegeven maar dit doet niets af aan het feit dat het bouwjaar of de geboortedatum in de werkelijkheid niet kan veranderen. 
    
BSN van een Persoon geldt voor de persoon vanaf het moment dat de persoon in de 
BRP is opgenomen en wijzigt niet: ‘heeft tijdlijn geldigheid’ = 'Nee'. 

Het is wel mogelijk dat een persoon een tweede BSN krijgt en de eerste niet meer gebruikt wordt. 

De meeste eigenschappen kunnen wel wijzigen. De Achternaam van een persoon kan wijzigen, het woonadres van een persoon kan wijzigen. 
    
De ‘heeft tijdlijn geldigheid’ ervan is daarom 'Ja'. 

Op conceptueel niveau is ook aan te geven dat het registratiemoment in een administratie moet worden bijgehouden, via een tijdlijn registratie. Deze staat vrijwel altijd op Ja. Echter, wanneer alleen de meest actuele situatie bekend moet zijn, en historie niet bijhouden hoeft te worden, dan staat deze op Nee. Het kan zijn dat historie pas vanaf een bepaald moment bijgehouden wordt. Zet dan de 'heeft tijdslijn registratie' wel op Ja, en geef aan dat voor een bepaald moment er geen historie bekend is voor een object, of voor alle objecten in een administratie.

Richtlijn: op conceptueel niveau worden voor historie alléén heeft tijdlijn geldigheid en heeft tijdlijn registratie bij een attribuut of relatie vastgelegd. De attributen waaruit de tijdlijnen zelf bestaan (zoals bijvoorbeeld: 'begin geldigheid' en 'eind geldigheid' en 'begin registratie' en 'eind registratie') worden niet gemodelleerd in een conceptueel informatiemodel. Deze bij de tijdlijn behorende attributen worden (pas) op het logische niveau gemodelleerd.

Historie op logisch niveau

MIM schrijft geen implementatie van het logische niveau voor. De metagegevens 'heeft tijdlijn geldigheid' en 'heeft tijdlijn registratie' uit het conceptuele informatiemodel zullen waarschijnlijk uitgewerkt worden met een periode waarin de gegevens voor een eigenschap geldig zijn en een tijdsmoment wanneer deze gegevens geregistreerd zijn en mogelijk ook met een tijdsmoment waarop de geldigheid (begin en einde van de periode) zelf geregisteerd is. MIM schrijft niet voor hoe de uitwerking van de metagegevens eruit moet zien. Wel worden er aandachtspunten gegeven om rekening mee te houden. Denk bij de uitwerking o.a. aan de volgende aspecten:

  • Het bijhouden van historie met specifieke attributen per objecttype, zoals bijvoorbeeld: bouwjaar pand, of met generieke tijdlijnattributen attributen die gelden voor alle objecttypes, zoals begindatum geldigheid. Denk aan de attribuutsoort en/of gegevensgroeptype (herbruikbaar);
  • historie bijhouden per attribuut (en relatie) of per versie van een object. Bij deze laatste kan de gegevensgroep gekoppeld worden aan bijvoorbeeld elk objecttype;
  • de status transities die een object in zijn levenscyclus doorloopt. Er kan ook gekozen worden om deze in een conceptueel informatiemodel op te nemen, als ze op dat niveau al van belang zijn;
  • status attributen, die iets zeggen over gegevens, zoals attributen die aangeven wel of niet beschouwd moet worden als onderdeel van de geldige gegevens van een object. Er kan ook gekozen worden om deze in een conceptueel informatiemodel op te nemen, als ze op dat niveau al van belang zijn. Voorbeeld: BAG inactief. Het kan ook van belang zijn om aan te geven dat een gegeven niet terug te vinden is in een brondocument (omdat er fouten zijn gemaakt bij de verwerking), maar niet verwijderd kan worden omdat alle gegevens, ook foutieve, bestendig moeten worden bewaard. Voorbeeld: BAG indicatieNietBAG.
    • Hoewel het niet nodig is om in een administratie voor een eigenschap die niet kan veranderen, en 'heeft tijdlijn geldigheid' = 'Nee' heeft in een conceptueel informatiemodel, alsnog toch wel een tijdlijn geldigheid bij te houden. De eigenschap zal dan altijd dezelfde waarde hebben. Bijvoorbeeld: een eigenschap zoals een geboortedatum van een mens is een eigenschap die elk mens verplicht heeft en wel precies 1 keer. Let wel, wanneer een gegeven niet kan veranderen in de werkelijkheid, kan deze initieel wel met een foute waarde geregistreerd worden. Wanneer later alsnog de goede waarde bekend wordt en deze verwerkt wordt op een later registatiemoment (op de tijdlijn registratie), dan kan een mens in de werkelijkheid niet ineens twee verschillende geboortedatums hebben en dus ook niet op de tijdlijn geldigheid. De eerste datum was fout, en moet als fout worden aangemerkt en is daarmee ook niet meer geldig. Alleen de tweede is juist en geldig. De tweede is dan ook met terugwerkende kracht geldig, de persoon heeft in de werkelijkheid altijd al deze tweede juiste geboortedatum gehad. Dit is zo, ondanks dat we dit in de administratie pas goed hebben geregistreerd op een later registratiemoment. Eerdere besluiten die gebaseerd zijn op de foute geboortedatum behorend in principe dan ook opnieuw bekeken te worden.

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

Opmerking: de metagegevens heeft tijdlijn geldigheid en heeft tijdlijn geldigheid mogen worden opgenomen in een logisch model (mogen worden overgenomen van het conceptuele naar het logische informatiemodel).

Beheer

De enige waarden die mogelijk zijn, zijn 'Ja' of 'Nee'. Voor beheer kan het prettig zijn om in algemeenheid deze waarden aan te geven, bijvoorbeeld: voor alle eigenschappen van een modelelement, zoals van een objecttype, geldt Ja. De conventie hiervoor wordt opgenomen in de eigen extensie. Bijvoorbeeld: 'zie modelelement naam' (zie gegevensgroep, zie domein, zie view, zie informatiemodel).

Afleidbare gegevens

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

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

Authentieke gegevens

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

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

  • Landelijke registraties met authentieke en niet-authentieke basisgegevens (BAG, BRK, BRP, BGT e.d.);
  • Landelijke sector- en domein-overstijgende informatiemodellen (IMGeo e.d.);
  • Gemeentelijke sector- en domein-overstijgende informatiemodellen (RSGB, RGBZ, ZTC);
  • Sector- en domein-specifieke informatiemodellen (LV-WOZ, IMRO e.d.).
Waardebereik authentiek Betekenis
Authentiek https://www.noraonline.nl/wiki/Authentiek_gegeven.
Basisgegeven https://www.noraonline.nl/wiki/Basisgegeven
Wettelijk gegeven Gegeven behorende bij een wettelijke registratie, niet zijnde een basisregistratie
Landelijk kerngegeven Indien het een gegeven of een als relatiesoort gemodelleerd gegeven is in een landelijk sector- en domein-overstijgend informatiemodel en geen authentiek gegeven en geen basisgegeven en geen wettelijk gegeven is.
 Overig Indien het géén van de voorgaande categorieën betreft. Veelal gaat het dan om proces-, taakveld- of domeinspecifieke gegevens.

Mogelijk geen waarde

Bij het inwinnen van gegevens zal het regelmatig voorkomen dat voor een bepaald kenmerk er geen gegeven gevonden kan worden. Dit zal vaak zo zijn bij optionele gegevens. Bijvoorbeeld bij een tussenvoegsel van een achternaam. Maar het is ook mogelijk dat het gegeven er in de werkelijkheid wel is, of zou moeten zijn, maar dat waarde niet bekend is. Bijvoorbeeld omdat het gegeven niet gevonden kan worden, zoals een bouwjaar van een oud gebouw of de geboortedag van een persoon. Zo kan het niet hebben van een waarde van de overlijdensdatum van een persoon betekenen dat deze persoon nog leeft. Maar het kan ook betekenen dat de persoon is overleden, maar dat de datum waarop niet bekend is. Een ander voorbeeld is dat een registratie vroeger een bepaald gegeven niet registreerde, en tegenwoordig verplicht moet registreren. Het gegeven is dan bijvoorbeeld vanaf 1990 beschikbaar, en is daarvoor onbekend. Deze voorbeelden geven aan dat er in de werkelijkheid wel een gegeven kan zijn, maar dat deze onbekend is. Voor deze gevallen is ‘mogelijk geen waarde’ bedoeld. Mogelijk is de waarde er in de werkelijkheid wel, mogelijk is deze er niet.

In de modellering is het bij mogelijk geen waarde nodig om een modelleringconstructie te gebruiken om aan te geven wat er aan de hand is. Dit wordt in het informatiemodel gemodelleerd door een metagegeven op te nemen bij het desbetreffende modelelement. Er staat dan: mogelijk geen waarde: Ja. Dit is vrijwel altijd het geval bij een attribuutsoort, maar is ook mogelijk om het op te nemen bij een element van een datatype. Een voorbeeld bij een datatype is de geboorte datum van een persoon, als het zo kan zijn dat het jaar en de maand van geboorte wel bekend is, maar de dag niet. Dit datatype is ook gestandaardiseerd, en heet Datum Mogelijk Onvolledig.

Verder, wanneer er sprake is van mogelijk geen waarde dan het is expliciet niet de bedoeling om een verplicht veld optioneel maken. Dit is niet de juiste oplossing en kan bovendien de indruk geven dat het veld niet relevant is. De betekenis van een optioneel veld is daarom dat er inherent sprake is van dat de waarde een attribuutsoort van een objecttype mag ontbreken. Het ontbreken van een optionele waarde heeft daarom de betekenis dat het bekend is dat er in de betreffende situatie in de werkelijkheid geen waarde bestaat. Bij inherent optionele velden kan het immers ook voorkomen dat een waarde onbekend is. Het verschil tussen ‘het is bekend dat er geen waarde is’ en ‘het is onbekend of er een waarde is’ is alleen vast te leggen door onderscheid te maken. Daarom moet er expliciet worden aangegeven dat er sprake is van mogelijk geen waarde, middels het metagegeven Mogelijk geen waarde: Ja.

Het verplicht of optioneel zijn van een waarde en het wel of niet mogen ontbreken van een waarde (die in de werkelijkheid wel bestaat) zijn dus twee verschillende en van elkaar onafhankelijke eigenschappen. In combinatie beschrijven deze eigenschappen vier mogelijkheden:

  • Het attribuut heeft in de werkelijkheid altijd een waarde en die waarde moet zijn gevuld, zoals de identificatie. Waarde is verplicht, mogelijk geen waarde: Nee;
  • Het attribuut heeft in de werkelijkheid altijd een waarde, maar die waarde is mogelijk onbekend, bijvoorbeeld de geboortedatum. Waarde is verplicht, mogelijk geen waarde: Ja;
  • Het attribuut heeft in de werkelijkheid soms een waarde en die waarde moet dan zijn gevuld, bijvoorbeeld de officiële straatnaam. Waarde is optioneel, mogelijk geen waarde: Nee;
  • Het attribuut heeft in de werkelijkheid soms een waarde, maar die waarde en zelfs het bestaan ervan hoeven niet bekend te zijn, zoals de overlijdensdatum van een persoon. Waarde is optioneel, mogelijk geen waarde: ja.

Verder, wanneer er sprake is van mogelijk geen waarde dan kan het waardevol zijn om de reden waarom de waarde ontbreekt aan te geven. De beheerder van het informatiemodel bepaalt welke redenen hij of zij toestaat voor het ontbreken van waarden die in de werkelijkheid wel bestaan. Het is nuttig om deze redenen op informatiemodelniveau te beperken. Dit kan dan vastgelegd worden bij de attribuutsoort of bij relatiesoort, bijvoorbeeld in de toelichting. In de registratie mogen alleen deze redenen worden geregistreerd. Daarbij kan het zinvol zijn om te vermelden of een onbekende waarde mogelijk nog kan worden achterhaald of dat dat niet meer kan. Sommige informatiemodellen gebruiken enumeraties met daarin een waarde zoals 'onbekend'. In dit metamodel stellen we dat dit niet de bedoeling is bij de modellering van eigen gegevens in een eigen informatiemodel. Er geldt een uitzondering wanneer het gaat om gegevens die worden overgenomen uit een andere registratie die wel de waarde 'onbekend' gebruikt. Dan kan er worden gekozen voor het een-op-een overnemen van de gegevensdefinitie uit de andere registratie.

Externe schema’s (her) gebruiken

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

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

Voor het uitwisselen van geografische informatie op basis van NEN 3610 is een tweetal externe packages onderkend waarnaar vanuit de ‘eigen’ informatiemodellen kan w.orden verwezen: NEN 3610 of GML3.2.

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

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

Koppelen met een ander informatiemodel (externe koppeling)

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

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

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

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

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

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

Stelselcatalogus en stelselafspraken voor basisregistraties

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

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

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

  • Dit metamodel beschrijft de stelselcatalogus metadata alleen voor de metadata die op informatiemodel niveau speelt, niet de overige metadata.
  • Dit metamodel neemt stelselcatalogus metadata altijd op met dezelfde semantiek/betekenis. Als de betekenis van metadata anders is, dan wordt ook niet dezelfde naam gebruikt. Als de betekenis gelijk is, dan kan het wel zo zijn dat dit metamodel een andere naam hanteert. De vertaling wordt hieronder weergegeven.
  • Als de semantiek hetzelfde is, maar het waardenbereik van het gegeven is in dit metamodel een verdere verbijzondering (niet in strijd met) dan hanteert dit metamodel dezelfde metadata en geeft aan hoe de waarde in dit metamodel te vertalen naar de waarde in de stelselcatalogus. Bij automatische verwerking naar de stelselcatalogus is het wellicht dus soms nodig deze waardes om te zetten.
Metadata in stelselcatalogus Komt voor in Metamodel? Waardenbereik hetzelfde?
Naam J J
Definitie J J
Toelichting J J
Populatie J J
Herkomst J J (met aanvullende afspraken)
Authentiek J N (met vertaling)
Kwaliteit J J
Relatie N n.v.t. (kan wel via een vertaling)
Wetgeving N n.v.t.
Eigenaar N n.v.t.
Toegankelijkheid N n.v.t.
Gebruiksvoorwaarden N n.v.t.

Afspraken Waardenbereik

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

Afspraken rondom naamgeving en definities

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

Uniekheid van namen van modelelementen

  • Objecttypes hebben een unieke naam binnen het hele informatiemodel
  • Datatypen hebben een unieke naam binnen het informatiemodel
  • Kenmerken van een objecttype hebben een unieke naam binnen het objecttype (attribuutsoort, gegevensgroep, relatiesoort et cetera)
  • De naam van kenmerken van een objecttype hoeven niet uniek te zijn over objecttypen heen.
  • De naam van elementen van een datatype hoeven niet uniek te zijn over datatypen heen.

Dezelfde URI, naam en/of definitie gebruiken voor meerdere modelelementen

Er kan sprake zijn van een naam en/of definitie die voor meerdere modelelementen gelijk moeten zijn, omdat er inherent hetzelfde bedoeld wordt. Generalisatie is gedefinieerd voor Datatypen en Objecttypen en Datatypen en gegevensgroeptypen kunnen op meerdere plekken gebruikt worden.

Echter, voor bijvoorbeeld voor een relatiesoort of een attribuutsoort kan het ook nodig zijn om dezelfde naam en/of definitie te specificeren. Dit is mogelijk, maar het is dan niet geheel duidelijk of er hetzelfde bedoeld wordt, of dat de (exacte) overeenkomt in een informatiemodel (zoals bv. in een UML informatiemodel) een toevalligheid is. Daarom gelden de volgende afspraken:

  • Als de URI van twee of meer modelelementen EXACT hetzelfde is, dan wordt hiermee bedoeld dat het dezelfde modelelementen zijn. Bijvoorbeeld bij objecttype Gebied met attribuutsoort identificatie met URI "http://modellen.geostandaarden.nl/def/nen3610#identificatie" en een objecttype Boom met een attribuutsoort identificatie met URI "http://modellen.geostandaarden.nl/def/nen3610#identificatie". De modelelementen kunnen verder wel verschillend beschreven zijn (bijvoorbeeld met een nauwer waardebereik bij een van de modelelementen).

  • Als de definitie van twee of meer modelelementen EXACT hetzelfde is, dan wordt hiermee bedoeld dat het dezelfde definitie is. Bijvoorbeeld: attribuutsoort overboeking met definitie "Het bedrag in euro's" en attribuutsoort koopsom met definitie "Het bedrag in euro's".

  • Als de naam en de definitie van twee of meer modelelementen EXACT hetzelfde is, dan wordt hiermee bedoeld dat het hetzelfde kenmerk is. Bijvoorbeeld bij objecttype Huis met attribuutsoort oppervlakte: : "De oppervlakte in hele vierkante meters" en objecttype Appartement met attribuutsoort oppervlakte : "De oppervlakte in hele vierkante meters".

Dit betekent expliciet niet dat kernmerken van verschillende objecten, met dezelfde naam, ook dezelfde definitie moeten hebben. Een andere definitie of een andere naam betekent: niet hetzelfde.

Naamgeving voor Alternatief 1: natuurlijke taal, die dichtbij de gebruiker staat

Met natuurlijke taal wordt bedoeld, zoals de gebruikers erover praten, in normaal Nederlands. Veelal zijn dit alleen letters en cijfers, met spaties. Koppeltekens (- of _) kunnen gebruikt worden, indien gewenst, alsmede diakrieten.

Zo kan bijvoorbeeld gekozen worden dat de eerste letter een hoofdletter is voor namen van de modelelementen Objecttypen, Gegevensgroeptype en Datatypen en dat de eerste letter een kleine letter is voor attribuutsoorten, en data-elementen e.d. Bijvoorbeeld: ‘Natuurlijk persoon’ en ‘naam’ met type CharacterString.

Regel: voor conceptuele informatiemodellen wordt altijd alternatief 1 gehanteerd.

Naamgeving voor Alternatief 2: (ook) leesbaar door systemen

Met machine leesbare taal wordt bedoeld dat deze eenvoudig door systemen te verwerken is. Veelal zijn dit alleen letters en cijfers, zonder spaties, zonder diakrieten. Koppeltekens (- of _) kunnen gebruikt worden, maar dit wordt veelal vermeden.

Zo kan bijvoorbeeld gekozen worden voor UpperCamelCase voor namen van Objecttypen, Gegevensgroeptypen en Datatypen en lowerCamelCase voor attribuutsoorten, relatiesoorten, relatierollen, data-elementen e.d. Bijvoorbeeld: naam in een NatuurlijkPersoon. Combineer indien nodig verschillende woorden (uit bijvoorbeeld een begrippenkader of uit een conceptueel informatiemodel) om precieze en begrijpelijke namen te vormen.

Als er gekozen wordt voor CamelCase, volg hierin dan hoe deze in UML ook toegepast wordt (deze komt overeen met ISO19103): maak van de beginletter van ieder deelwoord van namen van attribuutsoorten, relatierollen een hoofdletter, behalve de beginletter van het eerste woord. Bij namen van objecttypen, gegevensattributen, keuze, datatypen, en relaties wordt ook de beginletter een hoofdletter.

Regel: voor logische informatiemodellen wordt altijd alternatief 2 gehanteerd.

Neem aanvullend een verwijzing op naar het betreffende modelelement in het conceptuele informatiemodel. Dit kan bijvoorbeeld met een trace of door opname van de naam in de alias, zodat lezers goed de overgang van conceptueel naar logisch kunnen volgen.

Naamgeving voor metamodel elementen

Voor stereotypes en metagegevens worden dezelfde naamgevingsconventies toegepast als in alternatief 1 waarbij de eerste letter een hoofdletter is voor alle stereotypes en tagged values. Echter, als een internationale standaard het anders voorschrijft, dan wordt deze gevolgd, en niet vertaald. Bijvoorbeeld: codeList. Deze conventies gelden ook als in een eigen extensie metamodelelementen worden toegevoegd.

Het is mogelijk om eigen naamgevingsconventie te hanteren. In bijlage [[[#template-naamgevingsconventies]]] is een template opgenomen om naamgevingsconventies in te specificeren. Het verschaft een invulmogelijkheid om, per in dit metamodel genoemd modelelement, eigen naamgevingsconventies te documenteren. Dit is een hulptabel, die u over kunt nemen naar uw eigen extensie (zoals bedoeld in [[[#een-eigen-extensie-op-het-metamodel]]]) en in kunt vullen voor uw eigen informatiemodel (of organisatie).

Verwijzing van een modelelement naar een begrip uit het begrippenkader

Het metadata element “begrip” uit paragraaf Datatypen is bedoeld om de traceability tussen een modelelement in een informatiemodel en een begrip uit een model van begrippen (zoals bedoeld in [[[#typering-van-modellen-gekoppeld-aan-beschouwingsniveaus]]] te borgen. Anders gezegd, om aan te geven dát een modelelement een weergave is van het betreffende begrip op IM niveau. Anders gezegd, het is niet de bedoeling om te verwijzen naar een begrip als het modelelement hier slechts een beetje mee te maken heeft. De verwijzing geeft aan dat het model element op informatiemodel niveau een invulling geeft aan het begrip. Het begrip zelf is opgenomen in een model van begrippen. Aldaar is meer informatie te vinden over het begrip zelf.

Aanbeveling: de verwijzing vanuit het eigen informatiemodel naar een begrip is altijd een verwijzing naar een begrip dat behoort tot het eigen model van begrippen. Voor begrippen die domein specifiek zijn is dit altijd zo en zal de aan URI van het begrip ook te herkennen zijn dat dit zo is. Er zijn echter situaties denkbaar waarin een begrip een URI heeft die extern is aan het eigen model van begrippen. Het begrip is dan klaarblijkelijk wel relevant voor het eigen domein, en behoort daarom dan ook tot het eigen model van begrippen, ondanks dat de URI extern is. Een externe URI kan bijvoorbeeld wel voorkomen als het eigen informatiemodel modelelementen uit een ander informatiemodel heeft overgenomen, zoals bedoeld bij het stereotype «view» of «extern». Of bijvoorbeeld omdat het begrip weliswaar in gebruik is binnen het eigen domein, maar ontleent is aan een ander domein c.q. een ander model van begrippen, met als doel om aan te geven dat de betekenis gelijk is. Dit is mogelijk en toegestaan. In de praktijk wordt een begrip dat ontleend is van een ander model van begrippen echter veelal met een eigen URI en een eigen beschrijving opgenomen in het eigen model van begrippen. Dit komt doordat in het eigen domein meestal op een eigen manier tegen het begrip wordt aangekeken, of omdat het niet de bedoeling is dat het eigen model van begrippen automatisch meebeweegt zodra de definitie uit het andere domein verandert. Merk op dat het MIM niet gaat over hoe een model van begrippen wordt gemodelleerd.

Het metadata element begrip mag achteraf toegevoegd worden. Het is immers mogelijk dat bijvoorbeeld het informatiemodel eerder opgesteld wordt dan het model van begrippen, of dat het initieel niet bekend is wat van een modelelement het bijbehorende begrip is, of dat een model van begrippen uitgebreid wordt met een extra begrip. Het criterium om een begrip op te nemen in een model van begrippen is geen onderdeel van dit metamodel. Het is zelfs mogelijk dat een modelelement initieel niet als een begrip gezien wordt, maar dat het modelelement op een gegeven moment zodanig een begrip wordt, dat deze wordt opgenomen in het model van begrippen. In alle gevallen geldt, neem de metadata op zodra dit mogelijk is. Als het metadata element begrip wordt weggelaten, of de metadata die erin op genomen kan worden wordt leeggelaten c.q. de verwijzing naar het begrip (nog) niet gemaakt kan worden, dan is de betekenis hiervan dat het niet bekend is of er sprake is van een begrip. Merk op dat het achteraf toevoegen van de verwijzing naar een begrip in principe niet iets veranderd aan het informatiemodel zelf (afgezien van deze metadata), al kan dit wel aanleiding geven tot het verbeteren of verhelderen van definities.

Term of URI

In de definitie van metadata begrip staat dat de verwijzing de vorm heeft van een term of van een URI. - Als je kiest voor een term, vul dan de naam in van het begrip. Bijvoorbeeld: Natuurlijk persoon. Geef indien mogelijk ook deze naam een goede plek in de definitie en/of toelichting van het modelelement. - Als je kiest voor een URI, kies dan voor de URI dat dit begrip identificeert. Deze zal verwijzen naar een skos:Concept . Dit houdt in dat als iemand naar deze URI gaat (bijvoorbeeld met een browser, dit wordt “het resolven van een URI” genoemd), deze persoon informatie krijgt over het betreffende begrip. Bijvoorbeeld: https://catalogus.kadaster.nl/brk/nl/page/Perceel.

Verwijzen naar 0, 1 of meer begrippen

Veelal betreft één modelelement één begrip . De verwijzing naar dit begrip wordt dan opgenomen in deze metadata.

Het is echter zeker niet zo dat elk modelelement een begrip is in het model van begrippen. Het metadata element mag daarom weggelaten worden en de metadata mag leeggelaten worden. Vaak kan bij objecttypes, gegevensgroepen en attribuutsoorten wel een verwijzing opgenomen naar een begrip en is dit niet zinvol bij datatypen, maar dit is geen harde regel. Bijvoorbeeld: een koopsom van een huis wordt uitgedrukt met een bedrag. In het domein is de koopsom wel een begrip, maar het modelelement bedrag bijvoorbeeld niet (en als bedrag al geen begrip is, dan is valuta dit vermoedelijk ook niet, evenals euro, aantal en Decimalen). In het geval dat bijvoorbeeld bedrag niet een begrip is, wordt het metadata element begrip weggelaten.

Bij het opnemen van het begrip streven we ernaar om, waar mogelijk, precies te zijn. Bijvoorbeeld: het kan zijn dat in het model van begrippen een Natuurlijk persoon en een Niet natuurlijk persoon zijn opgenomen, terwijl in het informatiemodel alleen het modelelement Persoon is opgenomen, alsmede een attribuutsoort ‘type persoon’. De verwijzing naar het begrip Natuurlijk persoon hoort in dit geval gelegd te worden vanuit het attribuutsoort 'type persoon' en niet vanuit het objecttype Persoon. Het kan ook zo zijn dat het datatype van 'type persoon' een codelijst is, met als mogelijke waarden ‘NP’ en ‘NNP’ en ‘overig’. Het is dan preciezer om de verwijzing te leggen vanuit de waarde ‘NP’.

Definitie van een modelelement en de definitie van een begrip

De definitie van het modelelement is niet hetzelfde bedoeld als de definitie van een begrip. De definitie van een begrip in het begrippenkader is buiten scope van het informatiemodel, enerzijds omdat deze definitie anders kan zijn dan de definitie van het modelelement, en anderzijds omdat de definitie van het begrip aangepast kan worden, terwijl de informatievoorziening die het informatiemodel implementeert automatisch meebeweegt met deze definitie. Dit gezegd hebbende, wanneer er sprake is van een 1 op 1 relatie tussen begrip en modelelement, dan is dit een duidelijke aanleiding om te zorgen dat deze definities goed met elkaar overeenstemmen, of zelfs hetzelfde gehouden worden, waar mogelijk.

Bij het metadata element definitie van een modelelement mag in de beschrijving gebruik gemaakt worden van een URI, om te verwijzen naar de nationaal of internationaal gepubliceerde definitie. Deze kan van een begrip zijn, maar dit hoeft niet. Let hiermee op wanneer u als beheerder van het informatiemodel deze definitie niet zelf beheert, want lezers van het informatiemodel en gebruikers van de informatie baseren zich wel op deze definitie. Het kan dan gebeuren dat de definitie veranderd, en de informatievoorziening hier niet mee in overeenstemming is. De aanbeveling 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.

Overig

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. Bij een fysiek, technisch gegevens- of datamodel (die buiten de scope van het MIM valt) heeft de attribuutvolgorde vaak invloed op de volgorde in de schema’s.