MIM - Metamodel Informatie Modellering

Geonovum Standaard
Versie ter vaststelling

Deze versie:
https://docs.geostandaarden.nl/mim/vv-st-mim-20200225/
Laatst gepubliceerde versie:
https://docs.geostandaarden.nl/mim/mim10/
Vorige versie:
https://docs.geostandaarden.nl/mim/def-st-mim10-20190619/
Laatste werkversie:
https://geonovum.github.io/MIM-Werkomgeving/
Redacteurs:
Dick Krijtenburg, Geonovum
Jan van Gelder, Geonovum
Auteurs:
Lennart van Bergen, Kadaster
Thies Mesdag, Kadaster
Marco Brattinga, Kadaster
Paul Janssen, Geonovum
Aan eerdere versies van MIM werkten mee:
Ellen Debats, KING
Arjan C. Kloosterboer, KING
Wilko Quak, TU Delft
Peter Lentjens, Kadaster
Linda van den Brink, Geonovum
Doe mee:
GitHub Geonovum/MIM-Werkomgeving
Dien een melding in
Revisiehistorie
Pull requests
Rechtenbeleid:

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 een definitief concept van de nieuwe versie van de standaard. Wijzigingen naar aanleiding van consultaties zijn doorgevoerd. De programmaraad van Geonovum beoordeelt dit definitief concept. Keurt zij het goed, dan is er een nieuwe standaard.

Colofon en Voorwoord

Colofon

Aan de totstandkoming van deze versie van dit metamodel hebben de volgende inhoudelijke experts op het gebied van informatiemodellering meegewerkt:

Naam Organisatie Rol en achtergrond
Lennart van Bergen Kadaster MIM kerngroep. Expert informatiemodellering. Modellenbureau Kadaster
Thies Mesdag Kadaster MIM kerngroep. Expert informatiemodellering. Modellenbureau Kadaster
Paul Janssen Geonovum MIM kerngroep. Expert informatiemodellering. Geostandaarden
Marco Brattinga Kadaster Expert semantisch modelleren
Dick Krijtenburg Geonovum Coördinator beheer MIM.
Jan van Gelder Geonovum Redactie MIM.

Voorwoord

Informatie is een belangrijke motor voor het functioneren van de overheid in Nederland. Steeds meer wordt er samengewerkt en uitgewisseld tussen verschillende overheidslagen en instanties. Daarom is het van groot belang dat we hetzelfde verstaan onder de gegevens die we gebruiken en gemeenschappelijke afspraken maken over de wijze van beschrijven van gegevens en de manier waarop we deze uitwisselen.

Bij huidige ontwikkelingen als het Digitaal Stelsel Omgevingswet (DSO) en de Basisregistratie Ondergrond (BRO) komt duidelijk naar voren dat veel gegevensverzamelingen uit verschillende domeinen bij elkaar komen in informatievraagstukken. Daarbij komen ook de wereld van de geografische gegevens en de wereld van de meer administratieve registraties bij elkaar. Dit geeft niet alleen extra mogelijkheden om informatie slim te combineren maar maakt ook een aantal verschillende uitgangspunten zichtbaar in de werkwijze binnen de overheid als het gaat om het modelleren van informatie.

Met het voorliggende MIM-metamodel hebben we een gemeenschappelijk vertrekpunt voor het opstellen van informatiemodellen. Het voorziet enerzijds in duidelijke afspraken die over meerdere bestuurslagen heen gaan over het vastleggen van gegevensspecificaties en biedt anderzijds ruimte aan de verschillende niveaus van modellering.

Versie 1.1 van MIM biedt naast het al bestaande uitdrukken van het metamodel in UML ook de mogelijkheid om het metamodel uit te drukken in Linked Data. Hierbij wordt voorzien in en breed geuite behoefte. We hebben de afgelopen tijd gezien dat MIM breed wordt omarmd binnen de overheid en een plek heeft veroverd binnen de NORA. Met de uitbreidingen en aanpassingen in deze versie wordt het toepassingsbereik van MIM aanzienlijk verbreed.

Dick Krijtenburg, Geonovum

Februari 2020

1. Inleiding

Voor u ligt het metamodel voor het beschrijven van informatiemodellen. Met het metamodel voor informatiemodellering (MIM) hebben we een gemeenschappelijk vertrekpunt opgesteld voor het maken van informatiemodellen. Het model bevat duidelijke afspraken over het vastleggen van gegevensspecificaties en biedt tegelijkertijd ruimte aan de verschillende niveaus van modellering. Bijzonder aan het model is dat de afspraken over meerdere bestuurslagen heen gaan.

Dit document is opgesteld met kennis die is aangedragen door de MIM-community. Kadaster, Geonovum, VNG Realisatie, DUO en andere partijen hebben hun bijdrage geleverd.

1.1 Toepassingsgebied

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

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

1.2 Doelgroep

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

1.3 Leeswijzer

Het metamodel beschrijven we in vijf hoofdstukken en een bijlage.

Lees de Inleiding verder voor inzicht in wat we onder een informatiemodel en onder een metamodel verstaan, hoe deze de modellen zich verhouden tot UML en de vier lagen metamodel architectuur van de Object Management Group [OMG], Linked Data en de internetstandaarden van de W3c en welke overige standaarden worden toegepast.

Het hoofdstuk Metamodel Algemeen bevat de beschrijving van alle bouwstenen c.q. de modelelementen van het metamodel, in de vorm van definities en specificaties. De betekenis en toelichting van de modelelementen van het metamodel vormt het materiaal waarmee een uitputtende modelspecificatie kan worden opgesteld. De afbeeldingen in dit algemene hoofdstuk zijn weliswaar gemaakt in UML, maar het metamodel beperkt zich zeker niet tot UML. Er zijn aparte hoofdstukken voor de implementatie van MIM in UML en Linked Data.

Het hoofdstuk Metamodel in UML beschrijft hoe de implementatie van MIM in [UML] er uit ziet. In dit hoofdstuk wordt beschreven hoe het metamodel zich verhoudt tot het UML metamodel, welke uitbreidingen c.q. verbijzonderingen van het UML metamodel zijn aangebracht.

Het hoofdstuk Metamodel in Linked Data (LD) beschrijft hoe de implementatie van MIM in [Linked-Data] er uit ziet. In dit hoofdstuk wordt beschreven hoe het metamodel zich verhoudt tot het Linked Data metamodel. Daarbij is een strikte vertaling gemaakt. Dit betekent dat het betreffende Linked Data model alleen als MIM model te gebruiken is. Voor een model dat gebruikt kan worden om daadwerkelijk Linked Data in uit te drukken, is een vertaalslag nodig die beschreven is in de bijlage Transformatie MIM - RDFS/OWL/SHACL. Op deze wijze kan een dergelijk RDFS/OWL/SHACL model ook gezien worden als een MIM model.

In het hoofdstuk Afspraken & Regels gaan we in detail in op een aantal aspecten. Het is een uitgebreidere toelichting, in aanvulling op het hoofdstuk Metamodel Algemeen, bestaande uit nadere afspraken, regels, richtlijnen en aanbevelingen bij het toepassen van het metamodel.

Er zijn een aantal bijlages, dit zijn hulpmiddelen of aanvullingen op MIM.

1.4 Gebruikswijzer

Met de bouwstenen oftewel de modelelementen die in dit metamodel beschreven zijn is een informatiemodel te maken. Om zo'n informatiemodel te maken volstaat het veelal om van het hoofdstuk [Metamodel Algemeen] door te nemen, te kiezen voor modellering met ofwel UML ofwel linked data, en het bijbehorende hoofdstuk te lezen. De andere hoofdstukken kan je behandelen als naslagwerk, voor als er tijdens het modelleren vragen ontstaan. Neem vervolgens uw favoriete modelleertool en ga aan de slag. Voor bepaalde modelleertools zijn er hulpmiddelen gemaakt, zodat je met deze hulpmiddelen de modelelementen kan aanmaken door erop te klikken en bijvoorbeeld naar een diagram kan slepen en ook kan valideren of je model correct het MIM volgt (wat automatisch gaat als je de hulpmiddelen gebruikt). Tot slot is het mogelijk om naar informatiemodellen te kijken van organisaties die al een MIM informatiemodel hebben gepubliceerd. Voor specifieke modelleringen en vragen zullen er ook uitgewerkte voorbeelden worden gemaakt.

1.5 Wat is een informatiemodel

Wanneer we informatie over bepaalde onderwerpen willen inwinnen, registreren of uitwisselen, dan is het van belang om deze informatie eerst goed te beschrijven. We doen dit zodat het voor eenieder die met de informatie aan de slag gaat helder en eenduidig is:

We doen dit door een model te maken van de informatie. Een informatiemodel beschrijft daarom de structuur, semantiek en de eigenschappen van informatie over dingen in de werkelijkheid. De beschrijving van de informatie heeft de vorm van een model dat een gestructureerde weergave is van die werkelijkheid. Een dergelijk model is noodzakelijk om deze informatie te kunnen beheren en gebruiken (door mensen en machines) bij het communiceren over deze werkelijkheid, in registraties of anderszins, zoals het specificeren van de tussen registraties uit te wisselen gegevens of van de te bevragen informatie uit een registratie.

Het beschrijven vindt plaats door de informatie van de objecten die we beschouwden te modelleren, met hun kenmerken en hun onderlinge relaties.

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. Er worden geen regels toegepast die gerelateerd zijn aan de manier waarop de gegevens ingewonnen, opgeslagen, beheerd en uitgewisseld worden.

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

1.6 Typen informatiemodellen

Zoals hiervoor uiteengezet beschrijft een informatiemodel de werkelijkheid. In de praktijk blijken hier niveaus in te bestaan, variërend van een zo getrouw mogelijke beschrijving van die werkelijkheid tot een specificatie van de wijze van vastlegging van die werkelijkheid in een database of uitwisselformaat. Veelal worden vier niveaus onderscheiden, waarbij niveau 1 niet als een informatiemodel wordt gezien en waarbij MIM zich primair richt op niveau 2 en 3 (Het uitdrukken in UML richt zich op niveau 2 en 3, het uitdrukken in Linked Data richt zich op alle niveaus)[MDA]

1.6.1 Niveau 1: Model van begrippen

Beschrijft de werkelijkheid binnen het beschouwde domein (de ‘universe of discourse’) d.m.v. de daarin gehanteerde begrippen en hun relaties tot elkaar. Doel is dat de actoren daarbinnen elkaar begrijpen en één taal spreken. Een model van begrippen wordt opgesteld voor gebruik door mensen, met name ‘de business’. De begrippen worden beschreven in een formele taal, een vocabulaire. Een vocabulaire is geen informatiemodel. Begrippen kunnen in meerdere informatiemodellen gebruikt worden.

Ten aanzien van begrippen en informatiemodellen:

  • Van een aantal begrippen wordt informatie bijgehouden, niet van alle.
  • Voor het bijhouden van informatie wordt een gedetailleerde eenduidige structuur aangebracht.
  • De samenhang tussen informatie is vaak (bewust) beperkter dan de samenhang tussen begrippen.

1.6.2 Niveau 2: Conceptueel informatiemodel

Modellering van de werkelijkheid binnen het beschouwde domein, v.w.b. informatie daarvan, en is onafhankelijk van ontwerp van en implementatie in systemen. Het geeft een zo getrouw mogelijke beschrijving van die werkelijkheid en is in natuurlijke taal geformuleerd. Een dergelijk model definieert het ‘wat’: welke ‘concepten’ (‘dingen’) worden onderscheiden (in de beschouwde werkelijkheid), wat betekenen zij, hoe verhouden ze zich tot elkaar en welke informatie (eigenschappen) is daarvan relevant. Het dient als taal waarmee domeinexperts kunnen communiceren met informatie-analisten en verschaft een eenduidige interpretatie van die werkelijkheid ten behoeve van deze communicatie.
Een conceptueel informatiemodel wordt dan ook opgesteld voor gebruik door mensen, zodat ‘de business’ en de ICT-specialisten elkaar gaan begrijpen.

Ten aanzien van logische informatiemodellen:

  • Een conceptueel informatiemodel is onafhankelijk van standaarden voor gegevensuitwisseling. Een logisch informatiemodel past deze wel toe (denk aan identificaties, geometrie versies, tijdslijnen van historie)
  • Een conceptueel informatiemodel is onafhankelijk van een koppelvlak of keten, oftewel is keten overstijgend.
    Een logisch informatiemodel is specifiek voor een koppelvlak of keten.

1.6.3 Niveau 3: Logisch informatie- of gegevensmodel

Beschrijft hoe de, in het conceptuele model onderscheiden, concepten gebruikt worden bij de interactie tussen systemen en hun gebruikers en tussen systemen onderling. Anders gezegd, een model van de representatie van informatie over de werkelijkheid in digitale registraties en in de uitwisseling daartussen. Het gaat hierbij, in tegenstelling tot een conceptueel model, dus veel meer om het ‘hoe’. Het slaat de brug tussen werkelijkheid en systemen maar beschrijft nog niet de implementatie in die systemen. Een dergelijk model wordt in een formele taal beschreven en wordt waar mogelijk gegenereerd vanuit het conceptueel model.
Het logisch model wordt opgesteld voor ICT-interoperabiliteit, voor gebruik door met name de ontwerpers, bouwers en beheerders van ICT-voorzieningen.

Ten aanzien van fysieke of technische datamodellen:

  • Een logisch informatiemodel is implementatie onafhankelijk en kan in naar meerdere technische modellen worden geimplementeerd. Een fysiek of technisch datamodel is afhankelijk van de gekozen techniek of tooling die wordt gebruikt.

1.6.4 Niveau 4: Fysiek of technisch gegevens- of datamodel

Specificeert de structuur en eigenschappen van de technologie waarin de informatie wordt vastgelegd of uitgewisseld. Dit is sterk afhankelijk van de gebruikte opslagtechnologie zoals een specifieke database of de servicetechnologie zoals [xml], [gml], [SOAP], REST, [GeoJSON], [Linked-Data] e.d. Het kan tevens informatie bevatten over de manier waarop berichten ‘verpakt’ worden, het (internet)protocol en de logistiek van het berichtenverkeer. De technische specificaties worden over het algemeen zoveel als mogelijk gegenereerd uit het logisch informatiemodel.
Deze specificaties worden opgesteld voor ‘machines’, te gebruiken door software-ontwikkelaars.

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

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

1.7 Wat is het metamodel voor informatiemodellering

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

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

1.8 Uitdrukken in UML

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

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

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

Metaniveau Omschrijving Elementen
M3 MOF, verzameling van constructies voor definiëren van metamodellen MOF klasse, MOF attribuut, MOF Associatie, MOF operatie, etc.
M2 Metamodellen (UML, CWM, etc.), bestaande uit instanties van MOF constructies UML klasse, UML associatie, UML attribuut, etc.
M1 Modellen, bestaande uit instanties van M2 metamodel constructies Klasse “Order”, klasse “Klant”, attribuut “naam” etc
M0 Objecten en data, de instanties van M1 model constructies Order 43123, Artikel 8RB31, etc.

Tabel 1 Vier lagen metamodel OMG

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

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

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

Nadrukkelijk moet daarbij worden vermeld dat het MIM metamodel geen semantiek overneemt van UML. Met het uitdrukken van het MIM metamodel in een UML profiel wordt het alleen mogelijk gemaakt om, zonder verlies van de originele semantiek van het MIM, een MIM model uit te drukken in UML. Met dit gebruik van een UML profiel volgen wij het gebruik van een UML profiel zoals de OMG zelf heeft op gesteld voor het Ontology Definition Metamodel [ODM]: "The goal of a UML profile from the ODM perspective is to provide a bridge between the UML and knowledge representation communities on a well-grounded, semantic basis, with a broader goal of relating software and logical approaches to representing information. Profiles facilitate implementation using common notation on existing UML tools. They support renaming and specializing UML model elements in consistent ways, so that an instance of a UML model can be seen as an extended metamodel. Profiles allow a developer to leverage UML experience and tools while moving to integrating with an ontology represented in another metamodel." (sectie 8.4.2).

1.9 Uitdrukken in Linked Data

Zowel het metamodel als informatiemodellen kan worden uitgedrukt in Linked Data. Registraties en afnemers hiervan kunnen deze gebruiken voor de inrichting van hun situatiespecifieke gegevenshuishouding. Belangrijk is dat de lezer eerst begrijpt wat we onder een informatiemodel en een metamodel verstaan en verder is het van belang de modellen in de juiste context te plaatsen. Dit laatste doen we aan de hand van de W3c open standaarden voor het specificeren van een ontologie.

Ook geeft Linked Data een specifieke invulling aan de niveau's waarin we informatiemodellen beschrijven:

  1. Niveau 1: model van begrippen wordt in Linked Data uitgedrukt met behulp van vooral de SKOS vocabulaire.
  2. Niveau 2: conceptueel informatiemodel wordt in Linked Data uitgedrukt met behulp van een metamodel vocabulaire. Deze vocabulaire, het metamodel van het informatiemodel, kan een eigen vocabulaire zijn (zoals de MIM-vocabulaire) of uitgaan van de bestaande vocabularies. In deze laatste situatie, is het conceptueel informatiemodel ook direct een logisch informatiemodel.
  3. Niveau 3: logisch informatiemodel wordt in Linked Data uitgedrukt met behulp van de standaard vocabulaires RDF/RDFS ([RDF11-PRIMER]), OWL ([OWL2-PRIMER]) en [SHACL]. Daarbij geldt dat dit logisch informatiemodel OOK een conceptueel informatiemodel is. Doordat in Linked Data de representatie van informatie is gestandaardiseerd op basis van het RDF model, is er feitelijk geen of nauwelijks verschil tussen het conceptueel of logisch informatiemodel.

Indien een MIM model wordt getypeerd als "logisch informatiemodel" dan kan dit model slechts zinvol in Linked Data worden uitgedrukt indien bij de opzet van dit model rekening gehouden is met de betekenis die dergelijke modelelementen in de standaard Linked Data vocabularies hebben. Zie hiervoor de bijlage Transformatie van MIM modellen. Voor modellen die zowel een UML als een Linked Data implementatie vereisen, dan kan beter gekozen worden voor het type "conceptueel informatiemodel".

Een ontologie voor het metamodel Met een ontologie bedoelen we een model waarin we betekenis geven aan de termen die in een specifiek domein worden gebruikt. In geval van het MIM metamodel betreft dit het MIM-domein zelf.

We geven betekenis aan de termen door enerzijds een voor mensen leesbare definitie te koppelen aan een term (de "zachte semantiek") en anderzijds door relaties te leggen naar eerder gedefinieerde termen of relaties tussen termen in onze ontologie (de "harde semantiek"). We maken hierbij vooral gebruik van de bestaande wereldwijd geaccepteerde internetstandaarden RDF, RDFS, SKOS en OWL. Daarnaast beschrijven we ook welke constructies we wel en niet willen toestaan op het moment dat een modelleur een MIM model in Linked Data opstelt. Hiervoor maken we gebruik van de wereldwijd geaccepteerde internetstandaard SHACL.

Een informatiemodel Het (conceptueel) informatiemodel zien we als een invulling van de MIM ontologie. Dit betekent dat de elementen in het informatiemodel exemplaren zijn van de klassen die in de MIM ontologie zijn gedefinieerd. Zo is onderstaand voorbeeld een voorbeeld waarin het modelelement vb:Schip wordt gedefinieerd als exemplaar van de klasse mim:Objecttype. Een vb:Schip is dus een mim:Objecttype.

vb:Schip a mim:Objecttype;
  rdfs:label "Schip"@nl;
.

Een ontologie voor een informatiemodel Omdat een informatiemodel als invulling van de MIM ontologie zelf al exemplaren betreft, is het niet direct mogelijk om op basis van dit informatiemodel ook daadwerkelijk Linked Data in uit te drukken. Hiervoor is het nodig om de exemplaren uit het MIM informatiemodel zelf te transformeren, te "promoveren", naar klassen. Zo is onderstaand voorbeeld een voorbeeld van de transformatie van het exemplaar vb:Schip naar de klasse vbo:Schip. Vervolgens is het mogelijk om exemplaren van deze klasse te specificeren, zoals bijvoorbeeld de pakjesboot van Sinterklaas.

vbo:Schip a rdfs:Class;
  rdfs:seeAlso vb:Schip;
.



vb:Pakjesboot12 a vbo:Schip.

Een informatiemodel uitgedrukt in Linked Data wordt geacht te voldoen aan het MIM als sprake is van één of beide van onderstaande criteria:

  1. Het informatiemodel is uitgedrukt in de MIM vocabulaire, zoals beschreven in het hoofdstuk Metamodel in Linked Data (LD);
  2. Het informatiemodel is uitgedrukt in RDF, RDFS, OWL en SHACL en is te transformeren naar de MIM vocabulaire op basis van de transformatieregels beschreven in de bijlage, Transformatie MIM - RDFS/OWL/SHACL.

1.10 Een eigen extensie op het metamodel

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

De spelregel bij een extensie is dat deze geen onderwerpen vervangt die in dit metamodel beschreven zijn, maar alleen echte uitbreidingen behelst. Indien meerdere organisaties hierin geïnteresseerd zijn, kan zo’n extensie ook toegevoegd worden aan dit metamodel.

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

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

Noot

1.11 Alternatieven

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

Dit betreft: Relatiesoort en relatierol, beide te gebruiken, maar welke is verplicht/leidend (zie Specificatie metagegevens voor relaties).

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

1.12 Beheer

Het beheer van dit metamodel vindt plaats door Geonovum met ondersteuning van het Kadaster. Voor vragen, suggesties of opmerkingen kunt u contact opnemen met de MIM helpdesk van Geonovum: mim@geonovum.nl

1.13 Normreferenties

# Naam Referentie
1. Unified Modeling Language (UML) [UML]
2. OMG Unified Modeling Language TM versie 2.5 [OMG]
3. RDF Concepts and abstract syntax [RDF11-CONCEPTS]
4. Shape Constraint Language [SHACL]
5. Stelselcatalogus [SCAT]
6. GAB [GAB]
7. Handreiking gegevensbeschrijving (NORA) [NORA]
8. ISO 11404 [iso-11404]
9. ISO 8601 [iso-8601]
10. Formeel patroon (Reguliere Expressies) [REGEXP]
11. OCL [OCL]
12. NEN 3610 Basismodel Geo-informatie (vanaf /A1:2016) [NEN3610]

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

Noot

2. Metamodel Algemeen

Dit hoofdstuk beschrijft het metamodel in diagramvorm en in tekst.

Het metamodel beschrijft de modelelementen die worden gebruikt bij het maken van een informatiemodel. Voorbeelden van modelelementen zijn: objecttype, attribuutsoort, relatiesoort, maar denk ook datatypen of aan metagegevens. In de paragrafen hierna worden alle modelelementen beschreven en toegelicht.

Bijvoorbeeld: in de basisregistatie Kadaster wordt een perceel gemodelleerd als een objecttype. De grens van een perceel wordt gemodelleerd als een attribuutsoort. Objecttype en attribuutsoort zijn de modelelementen op metamodel niveau, het perceel en de grens zijn de modelelemenenten van het informatiemodel niveau.

Uitgangspunten voor het metamodel

Toelichting metaclass
Alle modelelementen zijn een metaklasse in het metamodel. Hiermee wordt aangegeven dat het niet een klasse betreft in een informatiemodel, zoals de klasse Persoon, maar dat het om de classificatie gaat dat de Persoon een Objecttype is, oftewel dat de klasse Persoon van de metaklasse Objecttype is. Vandaar de term metaclass.

De metaklassen worden ook gebruikt om aan te geven hoe deze zich verhouden tot de metaklassen van UML en W3C, in de volgende hoofdstukken.

Bij het maken van een informatiemodel modelleer je in feite gewoon met de modelelementen, en geef je aan dat een Persoon een Objecttype is en een geboortedatum een attribuutsoort.

Hierna volgen eerst diagrammen met de modelelementen, als overzicht. In de paragrafen erna wordt de betekenis van elk van deze modelelementen beschreven, met een definitie en een toelichting en een voorbeeld. Tot slot volgt een paragraaf met metadata die bijgehouden wordt, of kan worden, bij een modelelement.

2.1 Structuur metamodel

Deze paragraaf bevat een overzicht van het metamodel voor informatiemodellen, kortweg MIM, en geeft alle modelelementen weer. De beschrijving van de modelelementen staat in de volgende paragraaf.

De modelelementen zijn verdeeld over een aantal diagrammen, die elk een eigen view op een deel van het metamodel tonen. Elk view toont een aantal van de modelelementen, inclusief hun onderlinge samenhang.

Alle views samen vormen het metamodel als geheel:

Elk modelelement heeft een MIM metaclass met een naam. Hieraan is elk modelelement te herkennen in alle diagrammen en in de tekst en in elke specificatietaal die een uitdrukking is van dit metamodel.

Bij de modelelementen zijn in deze diagrammen geen beschrijvende kenmerken opgenomen, de metagegevens zoals naam, definitie enzovoorts. In de diagrammen in de bijlage zijn deze wel opgenomen.

2.1.1 Kern

View 1: De kern van een informatiemodel. Deze bestaat uit de volgende modelelementen:

MIM metaclass
Objecttype
Attribuutsoort
Gegevensgroep
Gegevensgroeptype
Generalisatie
Relatiesoort
Relatieklasse
Relatierol
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:

  • Een objecttype kan verbonden worden met een attribuutsoort. In een informatiemodel kan je attribuutsoorten dus aan een objecttype toekennen. Een attribuutsoort kan in het informatiemodel vervolgens weer als type een datatype krijgen.
  • Een objecttype kan verbonden worden met een relatiesoort en deze relatiesoort kan weer verbonden worden met een objecttype. Dit geeft aan dat de relatiesoort een modelelement is dat twee objecttypen met elkaar verbindt. Een objecttype kan dus niet rechtstreeks verbonden worden met een ander objecttype.
  • Een objecttype kan verbonden worden met een gegevensgroep en deze gegevensgroep kan weer verbonden worden met een gegevensgroeptype. Een objecttype kan dus niet rechtstreeks verbonden worden met een gegevensgroeptype. In een informatiemodel is een gegevensgroep een eigenschap van het objecttype en kan je aangeven dat deze gegevensgroep als type een gegevensgroeptype heeft.

2.1.2 Datatypen

View 2: Datatypen. Deze bestaat uit de volgende modelelementen:

MIM metaclass
Primitief datatype
Gestructureerd datatype
Data element
Enumeratie
Enumeratiewaarde
Referentielijst
Referentie element
Codelijst

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

In diagramvorm:

Diagram: Datatypen zonder Metagegevens

2.1.3 Overige

View 3a: constraint en keuze.

MIM metaclass
Constraint
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:

  • Use case 1: een keuze tussen datatypen
  • Use case 2: een keuze tussen attribuutsoorten
  • Use case 3: een keuze tussen attribuutsoorten, als nadere invulling van 1 betekenisvol attribuutsoort
  • Use case 4: een keuze tussen relatiedoelen, als nadere invulling van 1 betekenisvolle relatiesoort

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.

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 relatiedoelen

Relatierol

View 3b: Relatiesoort en relatierol

MIM metaclass
Relatierol (abstract)
Relatierol bron
Relatierol doel

In diagramvorm:

Diagram: Relatierol

Externe koppeling

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

MIM metaclass
Externe koppeling

In diagramvorm:

Groepering

View 3d: Groepering. Deze bestaat uit de volgende modelelementen:

MIM metaclass
Informatiemodel
Domein
Extern
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 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 behulp van het modelelement Objecttype.

Diagram: Kern

Om duidelijk(er) te maken wat wordt bedoeld kijken we eerst naar het begrip ‘object’.

Definitie Object
Een ding, een tastbaar iets, in de werkelijkheid, zoals daarnaar gekeken wordt vanuit een bepaald domein.

Toelichting: Met in de werkelijkheid wordt bedoeld dat het om de daadwerkelijke onderwerpen van gesprek gaat, de verzameling van de concrete tastbare dingen waarover we het hebben. Bijvoorbeeld, de persoon Jan, Paleis 't Loo. Het wordt veelal als niet politiek correct beschouwd mensen als objecten te zien. In dit kader, de informatievoorziening, beschouwen we evenwel natuurlijke en niet-natuurlijke personen wel als objecten. ‘Tastbaar’ moet hierbij ruim geïnterpreteerd worden. Het gaat niet alleen om fysiek herkenbare objecten zoals auto’s, gebouwen en mensen, ook om zogenaamde virtuele objecten waarover binnen het domein door betrokkenen gecommuniceerd wordt zoals kadastrale percelen, (maatschappelijke) activiteiten en processen. Hoe een ‘tastbaar iets’ als een object beschouwd wordt, hangt af van het domein waarvoor dat ‘tastbaar iets’ relevant is. Zo wordt de gebouwde omgeving in het ene domein beschouwd als een verzameling gebouwen terwijl een ander domein daarin panden onderscheidt. Een object is voor een domein relevant als eigenschappen (kenmerken) daarvan van belang zijn voor het functioneren van dat domein.

Definitie Objecttype
De typering van een groep objecten die binnen een domein relevant zijn en als gelijksoortig worden beschouwd.

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

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

2.2.2 Attribuutsoort en een groepering ervan

Een attribuutsoort is de metaklasse waarmee kenmerken van een objecttype worden vastgelegd. Het zijn de kenmerken waarvoor gegevens worden bijgehouden.
Voordat we attribuutsoort definieren kijken we eerst naar het begrip ‘gegeven’.

Definitie Gegeven
De betekenisvolle formulering van een waargenomen feit, waaraan een waarde kan worden toegekend.

Toelichting: Gegevens zijn de objectief waarneembare neerslag of registratie van feiten op een bepaald medium, zodanig dat deze gegevens uitgewisseld en voor langere tijd bewaard kunnen worden. Dat kan op papier, in digitale vorm, et cetera. Met deze gegevens wordt een model (een selectief deel dus) van de werkelijkheid vastgelegd in de tijd. Ofschoon de werkelijkheid nooit stilstaat, kan deze door het vastleggen van de gegevens toch worden bevroren.

Voorbeelden van gegevens zijn de waardes ‘Jan’ en ‘1-1-1970’ betreffende de naam en de geboortedatum van een object van het type Persoon. Merk op dat een gegeven zonder duidelijkheid over het soort gegeven c.q. de attribuutsoort 'naam' geen informatie biedt.

Een informatiemodel specificeert niet de gegevens zelf. Een gegeven zoals '1-1-1970' noemen we een attribuut van Jan. In het informatiemodel wordt dit het attribuutsoort 'naam' van een objecttype Persoon.

Definitie Attribuutsoort
De typering van gelijksoortige gegevens die voor een objecttype van toepassing is.

Toelichting De gegevens Jan en Katrien worden als gelijksoortig gezien en worden daarom ondergebracht in attribuutsoort 'naam'. Je kan ook zeggen, het objecttype Persoon heeft een attribuutsoort 'naam' en deze is geschikt om gegevens in te plaatsen.

Aan elk objecttype worden nul, één of meer «Attribuutsoort**en toegekend. In een informatiemodel worden alleen voor het domein relevante attribuutsoorten opgenomen bij een objecttype.

Attribuutsoorten worden ook wel kenmerken of eigenschappen genoemd. Dit zijn het ook, maar er zijn andere kenmerken, zo is een relatiesoort ook een kenmerk of eigenschap.

2.2.3 Gegevensgroep

Definitie Gegevensgroep
Een typering van een groep van gelijksoortige gegevens die voor een objecttype van toepassing is.

Toelichting: Dit modelelement verzorgt de modelmatige aankoppeling van een gegevensgroeptype aan het objecttype waartoe een gegevensgroeptype onlosmakelijk behoort.

De groep van gegevens is een kenmerk van een object. De gegevensgroep is een betekenisvol kenmerk van een objecttype. De gegevensgroep heeft altijd als type een gegevensgroeptype.

2.2.4 Gegevensgroeptype

Definitie Gegevensgroeptype
Een groep van met elkaar samenhangende attribuutsoorten. Een gegevensgroeptype is altijd een type van een gegevensgroep.

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

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

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

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

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

2.3 Relaties

Verbanden met betekenis, die gelegd zijn tussen modelelementen van het type objecttype naar het type objecttype, of van een gegevensgroeptype naar een objecttype.

Diagram: Kern

2.3.1 Generalisatie

Definitie Generalisatie tussen objecttypes
De typering van het hiërarchische verband tussen een meer generiek en een meer specifiek modelelement van hetzelfde soort, waarbij het meer specifieke modelelement eigenschappen van het meer generieke modelelement overerft. Dit verband is alleen gedefinieerd voor objecttypen en datatypen.

Toelichting: Deze toelichting is tweeledig.

Generalisatie tussen objecttypes:

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

Generalisatie tussen datatypes:

Het meer specifieke datatype brengt een verbijzondering aan in de vorm van een meer restrictieve definitie, of een meer restrictief patroon/formeel patroon.

Het andere datatype is bijvoorbeeld een CharacterString, Integer, GM Surface of DMO en dient als basis voor een zelf te definiëren datatype (zie Datatype zelf definiëren), zoals een CharacterString Postcode, of een NietNegatiefGetal.

Deze generalisatie is van toepassing op de volgende datatypes: «Primitief datatype», «Gestructureerd datatype», «Referentielijst», «Codelijst», «Enumeratie».

2.3.2 Relatiesoort

Definitie Relatiesoort
De typering van het structurele verband tussen een object van een objecttype en een (ander) object van een ander (of hetzelfde) objecttype.

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

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

2.3.3 Relatieklasse

Definitie Relatieklasse
Een relatiesoort met eigenschappen.

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

Opmerking: de gegevens van de relatie worden voor één relatie vastgelegd en niet voor meerdere relaties tegelijk. Als dit laatste het geval is, dan worden de gegevens vastgelegd in een «Objecttype». Een CONTRACT kan bijvoorbeeld ook een afspraak zijn tussen twee óf méér SUBJECTen, waarbij de gegevens van de relatie voor alle betrokken objecten hetzelfde zijn. CONTRACT wordt dan gemodelleerd als objecttype, waarbij beschreven wordt wat er moet gebeuren wanneer één van de SUBJECTen niet meer bestaat.

2.3.4 Externe Koppeling

Definitie Externe koppeling
Een associatie waarmee vanuit het perspectief van het eigen informatiemodel een objecttype uit het ‘eigen’ informatiemodel gekoppeld wordt aan een objecttype van een extern informatiemodel. De relatie zelf hoort bij het ‘eigen’ objecttype.

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

Zie Koppelen met een ander informatiemodel.

2.3.5 Relatierol

Definitie Relatierol
De benaming van de manier waarop een object deelneemt aan een relatie met een ander object.

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

Definitie Relatierol bron
De relatierol die de rol beschrijft van de bron van de relatie.

Definitie Relatierol doel
De relatierol die de rol beschrijft van het doel van de relatie.

2.4 Waardelijsten

Een datatype waarvan de mogelijke waarden zijn opgesomd in een lijst. De waarde van een attribuutsoort moet één van de waarden zijn uit de gespecificeerde waardenlijst.

2.4.1 Referentielijst

Definitie Referentielijst
De representatie van een lijst met een opsomming van de mogelijke domeinwaarden van een attribuutsoort, die buiten het model in een externe waardenlijst worden beheerd. De domeinwaarden in de lijst kunnen in de loop van de tijd aangepast, uitgebreid, of verwijderd worden, zonder dat het informatiemodel aangepast wordt (in tegenstelling tot bij een enumeratie). De representatie bevat een aantal kenmerken, die overgenomen zijn van de specificatie van de externe waardelijst.

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

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

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

2.4.2 Referentie element

Definitie Referentie element
Een eigenschap van een object in een referentielijst in de vorm van een gegeven.

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

2.4.3 Enumeratie

Definitie Enumeratie
Een datatype waarvan de mogelijke waarden limitatief zijn opgesomd in een statische lijst.

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

2.4.4 Enumeratiewaarde

Definitie Enumeratiewaarde
Een gedefinieerde waarde, in de vorm van een eenmalig vastgesteld constant gegeven.

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

2.4.5 Codelijst

Definitie Codelijst
De representatie van een lijst met een opsomming van de mogelijke domeinwaarden van een attribuutsoort, die buiten het model in een externe waardenlijst worden beheerd. De domeinwaarden in de lijst kunnen in de loop van de tijd aangepast, uitgebreid, of verwijderd worden, zonder dat het informatiemodel aangepast wordt (in tegenstelling tot bij een enumeratie). De representatie bevat geen kenmerken, voor alle kenmerken wordt verwezen naar de specificatie van de externe waardelijst.

Toelichting: Zowel referentielijsten als codelijsten zijn in feite waardenlijsten. In tegenstelling echter tot de referentielijst wordt een codelijst niet in het informatiemodel beschreven, omdat de definitie en semantiek geheel in de externe waardenlijst staat en niet (nader) geduid hoeft te worden in het informatiemodel zelf. Een codelijst heeft in het informatiemodel daarom geen attributen (en zou voor de definitie alleen hoeven te refereren naar de definitie bij de extern gepubliceerde waardenlijst, maar voor het gemak is de definitie wel opgenomen als metagegeven in dit metamodel). De extern gepubliceerde waardenlijst bevat, naast gewone attributen, ook altijd één specifiek attribuut, met daarin de domeinwaarden die gebruikt mogen/moeten worden in de registratie. In het gebruik is een Codelijst daarom analoog aan een Enumeratie. Welk specifiek attribuut dit is en wat de betekenis daarvan is staat in de codelijst zelf gedefinieerd.

2.5 Datatypen

Definitie Datatype
Een beschrijving van de structuur waaraan een waarde, oftewel de data zelf, aan moet voldoen.

Toelichting: Zie ook Objecttypen en attribuutsoorten. Bij elke «Attribuutsoort» wordt gespecificeerd aan welk datatype de data c.q. de waarde die hiervoor vastgelegd wordt moet voldoen. Het datatype wordt gebruikt als type van een attribuutsoort.

Datatypes zijn veelal op vele plekken (her)bruikbaar en kunnen daarom gespecificeerd worden bij diverse «Attribuutsoort»-en.

Diagram: Datatypen

2.5.1 Primitief datatype

Een standaard datatype, zoals bekend in vele specificatietalen, dat de structuur van een gegeven beschrijft. Het metamodel volgt waar mogelijk de definities zoals beschreven in ISO standaarden (zie §3.1). Deze datatypes hebben altijd al een naam en definitie gekregen vanuit deze standaarden en deze worden gebruikt. Deze worden niet door de modelleur gecreëerd en hebben daarom geen MIM metaclass.

Definitie Primitief datatype
Een in het eigen model gedefinieerd datatype die gebaseerd is op een PrimitiveType, met een eigen naam en definitie.

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

Toelichting: Een primitief datatype is een datatype zonder verdere specificatie over de structuur. Dit datatype is enkelvoudig, oftewel niet samengesteld, en wordt ook wel simpel datatype genoemd. Dit datatype kent daarom zelf geen eigen modelelementen zoals een «Data element».

Wanneer een Primitief datatype wordt gespecificeerd, dan heeft deze standaard als primitive datatype een CharacterString.

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

2.5.2 Gestructureerd datatype

Definitie Gestructureerd datatype
Specifiek benoemd datatype dat de structuur van een gegeven beschrijft, samengesteld uit minimaal twee elementen die in samenhang betekenisvol zijn.

Toelichting:

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

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

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

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

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

2.5.3 Data element

Definitie Data element
Een onderdeel/element van een Gestructureerd datatype die als type een datatype heeft.

Toelichting: Het data element is een eigenschap van een Gestructureerd datatype en beschrijft de structuur van een gegeven. Het is niet een eigenschap van een object en niet hetzelfde als een attribuutsoort.

Het data element beschrijft in combinatie met andere data-elementen de structuur van een gegeven en heeft zelf een datatype. Dit datatype is meestal een primitief datatype.

2.6 Packages

Definitie Package
Een package is een benoemde en begrensde verzameling/groepering van modelelementen.

Er zijn verschillende modelelementen die een package zijn:

2.6.1 Informatiemodel

Definitie Informatiemodel
De groepering van alle modelelementen waaruit het informatiemodel is opgebouwd. Het informatiemodel als geheel.

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

2.6.2 Domein

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

Definitie Domein
Een groepering van constructies die een semantisch samenhangend gedeelte van een informatiemodel beschrijven.

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

2.6.3 Extern

Definitie Extern
Een groepering van constructies die een externe instantie beheert en beschikbaar stelt aan een informatiemodel en die in het informatiemodel ongewijzigd gebruikt worden.

2.6.4 View

Definitie View
Een groepering van objecttypen die gespecificeerd zijn in een extern informatiemodel en vanuit het perspectief van het eigen informatiemodel inzicht geeft welke gegevens van deze objecttypen relevant zijn binnen het eigen informatiemodel.

2.7 Overige modelelementen

Diagram: Overige

2.7.1 Constraint

Definitie Constraint
Een constraint is een conditie of een beperking, die over een of meerdere modelelementen uit het informatiemodel geldt.

Toelichting: Een constraint kan vastgelegd worden bij alle modelelementen. Echter, meestal komt een constraint voor bij een objecttype, om te aan te geven dat de constraint geldt voor 2 (of meer) eigenschappen van een objecttype, of om een bijzondere specificatie toe te voegen die niet via de bestaande modelelementen gelegd kan worden zoals een 11-proef.

Een constraint wordt altijd in gewone tekst omschreven en kan optioneel als formele specificatie worden aangegeven.

2.7.2 Keuze

Een Keuze is een opsomming van meerdere modelelementen, waarbij er maar van één tegelijkertijd sprake kan zijn.

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

Een Keuze kan op meerdere plekken gebruikt worden, en maakt het mogelijk waar in het metamodel normaal gesproken maar één mogelijkheid bestaat, een opsomming te geven van meerdere mogelijkheden, waarbij in een concreet geval altijd precies één van deze mogelijkheden wordt gebruikt.

Een belangrijk voordeel van deze modellering is dat de kardinaliteiten zuiver gehouden kunnen worden. Anders gezegd, er kan mee voorkomen worden dat een kardinaliteit van bijvoorbeeld twee kenmerken eerst optioneel gemaakt moet worden en dat hierna via een constraint deze toch weer verplicht gemaakt moeten worden, voor precies één van de mogelijkheden. Het is aan de modelleur om te kiezen voor een constraint of een Keuze.

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

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

Use case 1: een keuze tussen datatypen

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

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

Het is niet de bedoeling om twee attribuutsoorten te modelleren met elk een datatype en de attribuutsoorten optioneel te maken.

Zonder de mogelijkheid van keuze, zou je te maken krijgen met twee attribuutsoorten met bijbehorend datatype. Echter, in dat geval mogen de attribuutsoorten niet dezelfde naam hebben, aangezien deze bij hetzelfde objecttype horen. Ook zou de kardinaliteit niet kloppen: die zou dan [0..1] moeten worden, maar dat doet geen recht aan het feit dat er één verplicht aanwezig moet zijn, en er ook geen twee naast elkaar mogen zijn. De werkelijke kardinaliteit is [1..1].

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

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

Het is bij deze use case niet de bedoeling om een derde attribuutsoort, zoals BetalingskenmerkOfOmschrijving, te introduceren als attribuutsoort van het objecttype. De aanhaking van de Keuze 'BetalingskenmerkOfOmschrijving' is daarom aan het objecttype.

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

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

Use case 3: een keuze tussen attribuutsoorten, als nadere invulling van een betekenisvol attribuutsoort van een objecttype Er is sprake van ofwel attribuutsoort A0 en aanvullend hierbij een keuze tussen ofwel attribuutsoort A1 ofwel attribuutsoort A2. In MIM modelleren we daarom voor A1 en A2 een keuze tussen de 2 attribuutsoorten. Het maken van deze keuze is verplicht.

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

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

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

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

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

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

2.8 Specificatie metagegevens

Bij de modelelementen in een informatiemodel kunnen metagegevens, zoals 'naam' van het modelelement, of 'datum opname' van het modelelement, worden bijgehouden. Dit zijn geen eigenschappen van een object en worden daarom niet als bijvoorbeeld een attribuutsoort van een objecttype gemodelleerd.

2.8.1 Specificatie metagegevens informatiemodel

We onderkennen een aantal specifieke metagegevens op het niveau van het informatiemodel zelf. Deze staan beschreven in deze paragaaf.

2.8.1.1 Metagegeven: Domein

Definitie Informatiedomein
Aanduiding van het functionele domein waartoe het informatiemodel behoort.

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

Toepassing: informatiemodel (verplicht)

2.8.1.2 Metagegeven: Informatiemodel type

Definitie Informatiemodel type
De beschrijving van de aard van het informatiemodel, hoe het geinterpreteerd moet worden.

Toelichting Bijvoorbeeld: conceptueel, logisch, technisch. Zoals bedoeld in: Typen Informatiemodellen

Toepassing: informatiemodel (verplicht)

2.8.1.3 Metagegeven: Relatiemodelleringstype

Definitie Relatiemodelleringstype
Aanduiding van een in MIM gedefinieerd alternatief voor een modelleringswijze, en welke keuze hierbij is gemaakt.

Toelichting Bijvoorbeeld: "Relatiesoort leidend" of "Relatierol leidend". Dit betreft de keuze die je maakt voor het in paragraaf Alternatieven gekozen alternatief. Er moet een keuze gemaakt worden.

Toepassing: informatiemodel (verplicht)

2.8.1.4 Metagegeven: MIM versie

Definitie MIM versie
De versie van de MIM specificatie die gebruikt is om het informatiemodel in uit te drukken.

Toelichting Bijvoorbeeld: 1.0.1 of 1.1

Toepassing: informatiemodel (verplicht)

2.8.1.5 Metagegeven: MIM extensie

Definitie MIM extensie
De aanduiding van een extensie op MIM.

Toelichting Bijvoorbeeld: Kadaster of NEN3610:2020

Toepassing: informatiemodel (optioneel)

2.8.1.6 Metagegeven: MIM taal

Definitie MIM taal
De aanduiding van de taal die gebruikt is voor de modelelementen.

Toelichting Bijvoorbeeld: NL, EN

Toepassing: informatiemodel (optioneel)

2.8.2 Specificatie metagegevens modelelementen

We onderkennen een aantal specifieke metagegevens op het niveau van de modelelementen waarmee een informatiemodel wordt samengesteld. Deze staan beschreven in deze paragaaf.

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

Merk op dat een aantal van deze metagegevens al meegenomen worden in een specificatietaal. Bijvoorbeeld het objecttype met de naam Pand wordt in UML gemodelleerd als ‘Named element’ met als ‘Name’ Pand (in UML 1.4 heette dit nog UML-Class, met een propery ‘Name’).

Een aantal andere metagegevens, zoals de eerder genoemde Datum opname met waarde 1-1-2012. worden als aparte data vastgelegd, in UML gebeurd dit in een ‘Tagged value’. In Linked data gebeurd dit met een ‘owl:DatatypeProperty’.

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

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

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

2.8.2.1 Metagegeven: Naam

Definitie Naam
De naam van een modelelement.

Toelichting

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

Toepassing: alle modelelementen.

2.8.2.2 Metagegeven: Definitie

Definitie Definitie
De beschrijving van de betekenis van dit modelelement.

Toelichting

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

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

Toepassing: alle modelelementen.

2.8.2.3 Metagegeven: Alias

Definitie Alias
De alternatieve weergave van de naam.

Toelichting

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

Bijvoorbeeld: OnroerendeZaak heeft als alias Onroerende zaak.

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

2.8.2.4 Metagegeven: Toelichting

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

Toelichting

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

Toepassing: alle modelelementen met een definitie.

2.8.2.5 Metagegeven: Begrip

Definitie Begrip
Verwijzing naar een begrip, vanuit een modelelement, waarmee wordt aangegeven op welk begrip, of begrippen, het informatiemodel element is gebaseerd. De verwijzing heeft de vorm van een term of een URI.

Toelichting

Hiermee wordt aangegeven hoe een informatiemodel element zich verhoudt tot de begrippen uit het begrippenkader, zoals genoemd in paragraaf Typen Informatiemodellen. Dit is niet een 1 op 1 relatie. Voor meer informatie hierover, zie hoofdstuk Afspraken & Regels.

Bijvoorbeeld: Perceel of http://brk.basisregistraties.overheid.nl/id/begrip/Perceel

Toepassing: alle modelelementen met een naam, met uitzondering van packages en constraint.

2.8.2.6 Metagegeven: Herkomst

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

Toelichting

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

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

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

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

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

2.8.2.7 Metagegeven: Herkomst definitie

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

Toelichting

Meestal staat in dit metagegeven aangegeven 'mijn IM', bijvoorbeeld BRK als het om het informatiemodel van de BRK gaat.

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

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

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

Toepassing: alle modelelementen die het metagegeven definitie kennen.

2.8.2.8 Metagegeven: Datum opname

Definitie Datum opname
De datum waarop het modelelement is opgenomen in het informatiemodel.

Toelichting

Bijvoorbeeld: 1-1-2012.

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

2.8.2.9 Metagegeven: Identificerend

Definitie Identificerend
Een kenmerk van een objecttype die aangeeft of deze eigenschap uniek identificerend is voor alle objecten in de populatie van objecten van dit objecttype.

Toelichting: objecten hebben, of krijgen, in een administatie of gegevensvoorziening vaak één identificerend kenmerk. Het kan ook zijn dat een aantal kenmerken in combinatie identificerend zijn, zoals twee attibuutsoorten of een attribuutsoort en een relatiesoort. De combinatie met een relatiesoort wordt alleen gedaan voor objecttypes die zelf geen unieke aanduiding hebben en daarom deze moeten samenstellen met de unieke aanduiding van een gerelateerde objecttype.

2.8.2.10 Metagegeven: Indicatie materiële historie

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

Toelichting

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

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

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

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

2.8.2.11 Metagegeven: Indicatie formele historie

Definitie Indicatie formele historie
Indicatie of de formele historie van het kenmerk van het object bijgehouden wordt en te bevragen is.

Toelichting

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

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

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

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

2.8.2.12 Metagegeven: Kardinaliteit

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

Toelichting

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

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

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

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

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

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

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

2.8.2.13 Metagegeven: Authentiek

Definitie Authentiek
Aanduiding of het kenmerk een authentiek gegeven betreft.

Toelichting

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

Authentiek is van toepassing voor bijvoorbeeld het burger service nummer van een natuurlijk persoon. In de wet van bijvoorbeeld een basisregistratie ligt vast welke gegevens authentiek zijn. Een kenmerk is authentiek indien de juistheid (hoogwaardige kwaliteit) van het gegeven gewaarborgd wordt via formele inwinningsprocessen en wettelijk regelingen. Authentieke gegevens moeten door alle overheidsinstellingen verplicht en zonder nader onderzoek, worden gebruikt bij de uitvoering van publiekrechtelijke taken.

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

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

2.8.2.14 Metagegeven: Indicatie afleidbaar

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

Toelichting

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

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

2.8.2.15 Metagegeven: Indicatie classificerend

Definitie Indicatie classificerend
Indicatie dat een attribuutsoort het objecttype waar het bijhoort classificeert in (sub)typen.

Toelichting

Een objecttype kan middels een attribuutsoort geclassificeerd worden in subtypen. Bijvoorbeeld: type gebouw. Een toren, kerk, bunker, zwembad zijn allemaal typen gebouwen. In een model op niveau 2 kunnen dergelijke typen als objecttypen en specialisaties van het objecttype gebouw zijn gemodelleerd. Met name op niveau 3 kan het relevant zijn om deze informatie daadwerkelijk te structureren door expliciet een aspect op te nemen waarmee direct het type gebouw kan worden vastgelegd, los van de modellering van objecttypen.

Praktisch gezien kan vervolgens gekozen worden om de onderliggende objecttypen niet meer in het model op te nemen, en slechts dit aspect op te nemen. Ook kan, in combinatie met indicatie afleidbaar dit aspect afgeleid worden uit het meest concrete objecttype, indien dergelijke objecttypen wel zijn gemodelleerd.

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

Toepassing: attribuutsoort.

2.8.2.16 Metagegeven: mogelijk geen waarde

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

Toelichting

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

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

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

2.8.2.17 Metagegeven: bron

Definitie bron
Aanduiding van het bronobject in een relatie tussen objecten. Een bronobject heeft middels een relatiesoort een relatie met een doelobject.

Toelichting

Bijvoorbeeld: een persoon heeft een postadres. Het postadres is een kenmerk van een persoon. De persoon is in deze het bronobject van de relatie. Het postadres is de naam van het kenmerk c.q. de relatie tussen een persoon en een adres en geeft betekenis aan deze relatie. Het adres is er gewoon en wie hem allemaal gebruikt als adres en of dit als postadres is of als woonadres of nog iets anders is voor het adres niet van belang.

Toepassing: relaties, oftewel de modelelementen Relatiesoort en Externe koppeling.

2.8.2.18 Metagegeven: doel

Definitie doel
Aanduiding van het gerelateerde objecttype die het eindpunt van de relatie aangeeft. Naar objecten van dit objecttype wordt verwezen.

Toelichting

Bijvoorbeeld: een persoon heeft een postadres. Het postadres is de naam van de relatie tussen een persoon en een adres. Het adres is het doel van deze relatie.

Dit metagegeven wordt vaak ook relatiedoel genoemd (Engels: target).

Toepassing: relaties, oftewel de modelelementen Relatiesoort en Externe koppeling.

2.8.2.19 Metagegeven: Unidirectioneel

Definitie Unidirectioneel
De richting van een relatie, welke betekenis geeft aan de relatie vanuit het perspectief van de eigenaar van de relatie.

Toelichting

Bijvoorbeeld: een persoon heeft een postadres. De richting van de relatie is van persoon naar adres. De eigenaar van de relatie (de bron) heeft kennis van de het gerelateerde objecttype (het doel). In een modelleertaal wordt dit vaak aangegeven met een pijl. De pijl heeft als vertrekpunt de bron en heeft als pijlpunt, waar de relatie naar wijst, het gerelateerde objecttype. Alle relaties zijn altijd gericht van het objecttype (bron) naar het gerelateerde objecttype (doel).

Het is gebruikelijk om een richting aan te geven, enerzijds omdat de betekenis van A naar B een andere is dan van B naar A, anderzijds omdat het van belang is bij welke objecttype het kenmerk wordt bijgehouden, oftewel wie de eigenaar is.

Toepassing: relaties, oftewel de modelelementen Relatiesoort en Externe koppeling.

2.8.2.20 Metagegeven: Aggregatietype

Definitie Aggregatietype
Aanduiding of het objecttype die de eigenaar is van een relatie het doel van relatie ziet als een samen te voegen onderdeel.

Toelichting Bijvoorbeeld: een auto heeft verschillende onderdelen, waaronder een motor. In het informatiemodel gaat het vooral om de auto en is de motor alleen relevant vanuit het perspectief van dat het een onderdeel is van de auto.

Standaard is er bij een relatie geen sprake van een aggregatie, (aggregatietype "Geen"). Als er wel sprake is van een aggregatie, dan geeft dit aan dat het objecttype die doel is van de relatie een onderdeel is van het objecttype die de eigenaar is van de relatie. De eigenaar geeft aan hoe de aggregatie in gezien moet worden. Dit kan zijn:

  • 'Compositie' (Engels: composite): de eigenaar is volledig verantwoordelijk voor het beheer van het onderdeel. Als de eigenaar vervalt, dan vervallen automatisch ook de onderdelen mee. Het doel kan niet bestaan zonder de bron: het doel vervalt als de bron vervalt.
  • 'Gedeeld' (Engels: shared): het onderdeel kan gebruikt en gedeeld worden door meerdere eigenaren. Bijvoorbeeld: een betaalrekening.

Toepassing: relaties, oftewel de modelelementen Relatiesoort en Externe koppeling.

2.8.2.21 Metagegeven: Locatie

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

Toelichting

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

Bijvoorbeeld: 'http://www.organisatie.nl/schemas/waardelijsten/NaamWaardelijst'

Toepassing: de modelelementen die een waardelijst zijn.

2.8.2.22 Metagegeven: Type (domein van een waarde een gegeven)

Definitie Type
Het datatype waarmee waarden van dit modelelement worden vastgelegd.

Toelichting

Bijvoorbeeld: het type van het kenmerk geometrie is het datatype VlakOfMultivlak, het type van het kenmerk achternaam is het datatype CharacterString

Een attribuutsoort heeft een datatype voor de specificatie van het toegestane waardetype. Hetzelfde geldt voor een data element, een referentie element en keuze elementen.

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

Toepassing: Alle informatie elementen die een attribuut modelleren: attribuutsoort, data element, referentie element, datatypekeuze, doelkeuze.

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

Definitie Lengte
De aanduiding van de lengte van een gegeven.

Toelichting Bijvoorbeeld: de naam van een openbare ruimte heeft minimaal lengte 1 en maximaal lengte 80.

Bijvoorbeeld: ‘1’ als de lengte exact 1 is; ‘1..2’ als de lengte 1 tot en met 2 lang kan zijn; '‘1,2’ voor Decimale getallen met 1 cijfer voor de komma en 2 erna. Dit is van -9,99 tot +9,99; Dit is nog verder toegelicht in hoofdstuk [Afspraken & Regels].

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

2.8.2.24 Metagegeven: Patroon

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

Toelichting

De structuur is in woorden beschreven.

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

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

Toepassing: de modelelementen uit de groep datatype en attribuutsoort.

2.8.2.25 Metagegeven: Formeel patroon

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

Toelichting

De structuur is in een reguliere expressie beschreven.

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

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

Toepassing: de modelelementen uit de groep datatype en attribuutsoort.

2.8.2.26 Metagegeven: code

Definitie Code
De in een registratie of informatiemodel aan de enumeratiewaarde toegekend unieke code

2.8.2.27 Metagegeven: indicatie abstract object

Definitie Indicatie abstract object
Indicatie dat het objecttype een generalisatie is, waarvan een object als specialisatie altijd voorkomt in de hoedanigheid van een (en slechts één) van de specialisaties van het betreffende objecttype.

Toelichting

Een abstract objecttype moet altijd de generalisatie zijn van één of meerdere specialisaties. Bijvoorbeeld het abstract objecttype "Voertuig", met concrete specialisaties "Auto", "Fiets" en "Bromfiets".

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

Toepassing: enumeratiewaarde

2.8.3 Specificatie metagegevens modelelement bindingen

Deze metagegevens zijn alleen nodig voor de binding van modelelementen aan elkaar.

2.8.3.1 Metagegeven: Attribuut

Definitie Attribuut
De binding van een attribuutsoort als eigenschap aan een objecttype.

Toelichting

Een objecttype gebruikt attributen voor het specificeren van eigenschappen.

Toepassing: objecttypen met attributen.

2.8.3.2 Metagegeven: Gegevensgroep

Definitie Gegevensgroep
De binding van een gegevensgroep als groep van eigenschappen aan een objecttype of gegevensgroeptype.

Toelichting

Een objecttype gebruikt gegevensgroepen voor het specificeren van groepen van eigenschappen.

Toepassing: objecttypen met gegevensgroepen. Of een gegevensgroeptype dat zelf ook weer een gegevensgroeptype bevat.

2.8.3.3 Metagegeven: Gegevensgroeptype

Definitie Gegevensgroeptype
De binding van een gegevensgroeptype als waardetype aan een gegevensgroep.

Toelichting

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

Toepassing: gegevensgroep.

2.8.3.4 Metagegeven: Data element

Definitie Data element
De binding van een data element aan een gestructureerd datatype.

Toelichting

Een gestructutreerd datatype bevat meerdere data elementen.

Toepassing: gestructereerd datatype.

2.8.3.5 Metagegeven: Waarde

Definitie Waarde
De binding van een waarde aan een enumeratie.

Toelichting

Een enumeratie bevat enumeratiewaarden.

Toepassing: enumeratie.

2.8.3.6 Metagegeven: Referentie element

Definitie Referentie element
De binding van een referentie element aan een referentielijst.

Toelichting

Een referentie lijst bevat bevat referentie elementen.

Toepassing: referentielijst.

2.8.3.7 Metagegeven: Constraint

Definitie Constraint
De binding van een constraint aan een klasse.

Toelichting

Een constraint is gekoppeld aan een klasse waarop ze van toepassing is.

Toepassing: objecttype, gegevensgroeptype, relatieklasse.

2.9 Toegestane waarden voor (bepaalde) metadata gegevens

Tagged values zijn altijd van het datatype CharacterString. Aanvullend geldt:

Tagged value Waardenbereik
Indicatie materiële historie Ja, Nee
Indicatie formele historie Ja, Nee
Indicatie classificerend Ja, Nee
Mogelijk geen waarde Ja, Nee
Aggregatietype Compositie, Gedeeld, Geen
Authentiek Authentiek, Basisgegeven, Wettelijk gegeven, Landelijk kerngegeven, Overig

NB: Geef bij overig in uw eigen informatiemodel aan wat u er onder verstaat.

3. Metamodel in UML

3.1 Structuur metamodel in UML

Dit hoofdstuk beschrijft hoe je een informatiemodel kan maken in UML, oftewel hoe de modelelementen uit het hoofdstuk Algemeen worden uitgedrukt in UML.

De eerste paragraaf bevat diagrammen, in UML. Elk diagram geeft een aantal modelelementen weer. Het geheel van diagrammen, in samenhang, is opgenomen in de bijlage Template naamgeving conventies.

Uitgangspunten voor het metamodel in UML zijn:

Elk modelelement heeft een MIM metaclass. Deze wordt in UML in een informatiemodel gemodelleerd als een extensie van een Metaclass van UML 2.5 en een bijbehorende stereotype.

MIM metaclass Stereotype Metaclass UML 2.5 In Sparx EA
Objecttype «Objecttype» (UML) Class Class

De links kolom bevat het MIM modelelement, zoals bedoeld in het hoofdstuk [Metamodel Algemeen]. 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

MIM metaclass Stereotype Metaclass UML 2.5 In Sparx EA
Objecttype «Objecttype» (UML) Class Class
Attribuutsoort «Attribuutsoort» (UML) Property Attribute
Gegevensgroep «Gegevensgroep» (UML) Property Attribute
Gegevensgroeptype «Gegevensgroeptype» (UML) Class Class
Generalisatie «Generalisatie» (UML) Generalization Generalization
Relatiesoort «Relatiesoort» (UML) Association Association
Relatieklasse «Relatieklasse» (UML) Association én (UML) Class Associationclass

3.1.2 Datatypen

Datatypen zonder Metagegevens

View 2: Datatypen

MIM metaclass Stereotype Metaclass UML 2.5 In Sparx EA
Primitief datatype «Primitief datatype» (UML) Primitive Type Datatype
Gestructureerd datatype «Gestructuurd datatype» (UML) Datatype Datatype
Data element «Data element» (UML) Property Attribute
Enumeratie - (UML) Enumeration Enumeration
Enumeratiewaarde - (UML) EnumerationLiteral EnumerationLiteral
Referentielijst «Referentielijst» (UML) Datatype Datatype
Referentie element «Referentie element» (UML) Property Attribute
Codelijst «Codelijst» (UML) Datatype Datatype

Nadere specificaties voor datatypen

Voor enumeraties is geen stereotype gespecificeerd. In het metamodel maken we 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 Stereotype Metaclass UML 2.5 In Sparx EA
Constraint - (UML) Constraint Constraint

Keuze Er zijn vier situaties waarin een keuze toegepast wordt: Keuze tussen:

  • datatypen
  • attribuutsoorten binnen een objecttype
  • 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 Stereotype Metaclass UML 2.5 In Sparx EA
Keuze Keuze (UML) Datatype Datatype
Keuze Keuze (UML) Property Attribute
Keuze Keuze (UML) Association Association
Datatype Datatype (UML) Property Attribute

Relatierol

Relatierol

View 3b: Relatiesoort en relatierol

MIM metaclass Stereotype Metaclass UML 2.5 In Sparx EA
Relatierol (abstract) «Relatierol» Property AssociationEnd
Relatierol source «Relatierol» Property AssociationEnd
Relatierol target «Relatierol» Property AssociationEnd

Externe koppeling

MIM metaclass Stereotype Metaclass UML 2.5 In Sparx EA
Externe koppeling «Externe koppeling» (UML) Association Association

View 3c: Groepering

Packages

MIM metaclass Stereotype Metaclass UML 2.5 In Sparx EA
Informatiemodel «Informatiemodel» (UML) Package Package
Domein (het eigen IM) «Domein» (UML) Package Package
Extern «Extern» (UML) Package Package
View «View» (UML) Package Package

3.2 Nadere specificatie metagegevens in UML

Deze paragraaf is een aanvulling op de paragraaf 'Specificatie metagegevens' in het hoofdstuk Metamodel Algemeen.

Alias

De alternatieve weergave van de naam.

Toelichting

Verdere toelichting voor UML modellen:

In Enterprise Architect is de alternatieve weergave aan te zetten in de properties van een Diagram, via: use alias if available.

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.

3.2.1 Modellering metagegevens voor objecten en attributen in UML

Specificatie voor «Objecttype»

De objecttypen worden naar de volgende aspecten gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam√ 1 Algemeen metagegeven . name van de metaclass Named element Name
Begrip 0..* Algemeen metagegeven. Tagged value
Alias 0..1 Algemeen metagegeven. Alias
Herkomst 1 Algemeen metagegeven. Tagged value
Definitie√ 1 Algemeen metagegeven. Body van de metaclass Comment Notes
Herkomst definitie√ 1 Algemeen metagegeven. Tagged value
Datum opname 1 Algemeen metagegeven. Tagged value
Unieke aanduiding√ 1 Voor objecttypen die deel uitmaken van een (basis)registratie of informatiemodel betreft dit de wijze waarop daarin voorkomende objecten (van dit type) uniek in de registratie worden aangeduid. - isId bij attribuutsoort, --- of --- stereotype «isId» bij target role relatiesoort --- of --- een combinatie van deze twee, elk hiervan meer keren toepasbaar
Populatie√ 0..1 Voor objecttypen die deel uitmaken van een (basis)registratie betreft dit de beschrijving van de exemplaren van het gedefinieerde objecttype die in de desbetreffende (basis)­registratie voorhanden zijn. Tagged value
Kwaliteit√ 0..1 Beschrijving van de mate waarin in de registratie opgenomen objecten van het desbetreffende type volledig, juist, actueel, nauwkeurig en betrouwbaar zijn. Tagged value
Toelichting√ 0..1 Algemeen metagegeven. Tagged value
Indicatie abstract object 1 Conceptueel model: indicatie dat het objecttype een generalisatie is, waarvan een object als specialisatie altijd voorkomt in de hoedanigheid van een (en slechts één) van de specialisaties van het betreffende objecttype. Logisch model: Indicatie dat er geen instanties (objecten) voor het betreffende objecttype mogen voorkomen. isAbstract bij de metaclass Classifier Abstract

Specificatie voor «Attribuutsoort»

De attribuutsoorten worden naar de volgende aspecten gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam √ 1 Algemeen metagegeven. name van de metaclass Named element Name
Begrip 0..* Algemeen metagegeven. Tagged value
Alias 0..1 Algemeen metagegeven. Alias
Herkomst 1 Algemeen metagegeven. Tagged value
Definitie √ 1 Algemeen metagegeven. Body van de metaclass Comment Notes
Herkomst definitie √ 1 Algemeen metagegeven. Tagged value
Datum opname 1 Algemeen metagegeven. Tagged value
Domein (aspecten van een waarde/data) Domein is zelf geen metadata aspect. Onder het kopje ‘domein’ vallen een aantal metadata aspecten die gelden voor een waarde, oftewel de eisen waaraan een waarde van een attribuutsoort moet voldoen.
- Type 1 Algemeen metagegeven. Tagged value
- Lengte 0..1 Algemeen metagegeven. Tagged value
- Patroon 0..1 Algemeen metagegeven. Tagged value
- Formeel Patroon 0..1 Algemeen metagegeven. Tagged value
Indicatie materiële historie √ 1 Algemeen metagegeven. Tagged value
Indicatie formele historie √ 1 Algemeen metagegeven. Tagged value
Kardinaliteit √ 1 Algemeen metagegeven. lowerValue en upperValue van de metaclass Multiplicity Element Multiplicity
Authentiek √ 1 Algemeen metagegeven. Tagged value
Toelichting √ 0..1 Algemeen metagegeven. Tagged value
Indicatie afleidbaar 1 Algemeen metagegeven. isDerived bij metaclass Property Tagged value
Indicatie classificerend 1 Algemeen metagegeven. isDerived bij metaclass Property isDerived
Mogelijk geen waarde 1 Algemeen metagegeven. Tagged value
Identificerend 0..1 Algemeen metagegeven. isID bij de metaclass Property isID

Specificatie voor «Gegevensgroep»

De gegevensgroepen worden naar de volgende aspecten gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 1 Algemeen metagegeven. name van de metaclass Named element Name
Begrip 0..* Algemeen metagegeven. Tagged value
Alias 0..1 Algemeen metagegeven. Alias
Definitie 1 Algemeen metagegeven. Body van de metaclass Comment Notes
Toelichting 0..1 Algemeen metagegeven. Tagged value
Gegevensgroeptype 1 De verwijzing naar het bijbehorende gegevensgroeptype. Type
Herkomst 1 Algemeen metagegeven. Tagged value
Herkomst definitie 1 Algemeen metagegeven. Tagged value
Datum opname 1 Algemeen metagegeven. Tagged value
Indicatie materiële historie 1 Algemeen metagegeven. Tagged value
Indicatie formele historie 1 Algemeen metagegeven. Tagged value
Kardinaliteit 1 Algemeen metagegeven. lowerValue en upperValue van de metaclass Multiplicity Element Multiplicity van de source role van de bijbehorende composite relatie
Authentiek 1 Algemeen metagegeven. Tagged value

Specificatie voor «Gegevensgroeptype»

De gegevensgroeptypen worden naar de volgende aspecten gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 1 Algemeen metagegeven. name van de metaclass Named element Name
Begrip 0..* Algemeen metagegeven. Tagged value
Alias 0..1 Algemeen metagegeven. Alias
Definitie 0..1 Algemeen metagegeven. Body van de metaclass Comment Notes
Herkomst definitie 0..1 Algemeen metagegeven. Tagged value
Toelichting 0..1 Algemeen metagegeven. Tagged value
Datum opname 1 Algemeen metagegeven. Tagged value

3.2.2 Specificatie metagegevens voor relaties

Relatiesoort en relatierol

Het metamodel heeft twee manieren om een relatie tussen twee objecttypen te beschrijven. Deze keuze wordt aangegeven in de eigen extensie, zoals beschreven in paragraaf alternatieven. Alleen het gekozen alternatief is relevant voor de modellering in uw informatiemodel. - Alternatief 1: Verplichte benoeming van de naam van de relatie met de bijbehorende metagegevens** - Alternatief 2: Verplichte benoeming van de rol van de target in een relatie met de bijbehorende metagegevens en optioneel de benoeming van de naam van de relatie.

Beide alternatieven gebruiken relatiesoort en relatierol, maar met andere regels voor gebruik.

3.2.2.1 Relatiesoort leidend (alternatief 1)

Relatiesoort is verplicht, met een naam en met een definitie en deze is leidend. Metadata aspecten worden hierbij altijd vastgelegd. Het gebruik van relatierol is optioneel (zowel bij source en target). Áls er een relatierol target wordt vastgelegd, dan is de metadata hierbij wel verplicht.

Specificatie voor «Relatiesoort»

De relatiesoorten worden naar de volgende aspecten gespecificeerd.

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam√ 1 Algemeen metagegeven. name van metaclass Named element Name
Begrip 0..* Algemeen metagegeven. Tagged value
Alias 0..1 Algemeen metagegeven. Alias
Unidirectioneel 1 Algemeen metagegeven. Direction van de betreffende assiciation (van source naar target)
Relatie eigenaar 1 Algemeen metagegeven. /source: related Element bij Relationship Element Source
Relatie doel 1 Algemeen metagegeven. /target: related Element bij Relationship Element Target
Aggregatietype 1 Algemeen metagegeven. AggregationKind bij metaclass Property Aggregation van de source role met waarde composite of shared
Kardinaliteit√ 1 Algemeen metagegeven. lowerValue en upperValue van de metaclass MultiplicityElement Multiplicity van de target role
Herkomst 1 Algemeen metagegeven. Tagged value
Definitie√ 1 Algemeen metagegeven. Body van de metaclass Comment Notes
Toelichting√ 0..1 Algemeen metagegeven. Tagged value
Herkomst definitie√ 1 Algemeen metagegeven. Tagged value
Datum opname 1 Algemeen metagegeven. Tagged value
Indicatie materiële historie√ 1 Algemeen metagegeven. Tagged value
Indicatie formele historie√ 1 Algemeen metagegeven. Tagged value
Authentiek√ 1 Algemeen metagegeven. Tagged value
Indicatie afleidbaar 1 Algemeen metagegeven. isDerived bij UML metaclass Assocation isDerived
Mogelijk geen waarde 1 Algemeen metagegeven. Tagged value

Specificatie voor «Relatierol»

Voor relatierollen worden naar de volgende aspecten gespecificeerd.

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 0..1 Algemeen metagegeven. name van de metaclass Namedelement Name
Begrip 0..* Algemeen metagegeven. Tagged value
Alias 0..1 Algemeen metagegeven. Alias
Definitie 0..1 Algemeen metagegeven. Body van de metaclass Comment Notes
3.2.2.2 Relatierol is leidend (alternatief 2)

Verplichte benoeming van de rol van de target in een relatie met de bijbehoren de metagegevens en optioneel de benoeming van de naam van de relatie.

Specificatie voor «Relatiesoort»

De relatiesoorten worden naar de volgende aspecten gespecificeerd.

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 0..1 Algemeen metagegeven. name van de metaclass NamedElement Name
Begrip 0..* Algemeen metagegeven. Tagged value
Alias 0..1 Algemeen metagegeven. Alias
Definitie 0..1 Algemeen metagegeven. Body van de metaclass Comment Notes

Specificatie voor «Relatierol»

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

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 1 Algemeen metagegeven. name van de metaclass Name
Begrip 0..* Algemeen metagegeven. Tagged value
Alias 0..1 Algemeen metagegeven. Alias
Herkomst 1 Algemeen metagegeven. Tagged value
Definitie√ * 1 Algemeen metagegeven. Body van de metaclass Comment Notes
Herkomst definitie√ 1 Algemeen metagegeven. Tagged value
Datum opname 1 Algemeen metagegeven. Tagged value
Kardinaliteit√ 1 Algemeen metagegeven. lowerValue en upperValue van de metaclass Multiplicity Element Multiplicity
Indicatie materiële historie√ 1 Algemeen metagegeven. Tagged value
Indicatie formele historie√ 1 Algemeen metagegeven. Tagged value
Authentiek√ * 1 Algemeen metagegeven. Tagged value
Mogelijk geen waarde 1 Algemeen metagegeven. Tagged value
Toelichting√ * 0..1 Algemeen metagegeven. Tagged value

Specificatie voor «Generalisatie» tussen objecttypes

De generalisaties worden naar het volgende aspect gespecificeerd:

Aspect Kardina liteit Toelichting In UML 2.5 In EA
Subtype 1 Het objecttype dat een specialisatie is van een (ander) objecttype. /source: related Element bij Relationship Element Source
Supertype 1 Het objecttype dat de generalisatie is van een (ander) objecttype. /target: related Element bij Relationship Element Target

Specificatie voor «Generalisatie» tussen datatypes

De generalisaties worden naar het volgende aspect gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 0..1 Algemeen metagegeven. name van de metaclass Named element Name
Begrip 0..* Algemeen metagegeven. Tagged value
Alias 0..1 Algemeen metagegeven. Alias
Subtype 1 Het datatype dat een specialisatie is van een (ander) datatype. /source: related Element bij Relationship Element Source
Supertype 1 Het datatype dat de generalisatie is van een (ander) datatype. /target: related Element bij Relationship Element Target

Specificatie voor «Relatieklasse»

De relatieklassen worden naar de volgende aspecten gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 1 Algemeen metagegeven. name van de metaclass Named element Name
Begrip 0..* Algemeen metagegeven. Tagged value
Alias 0..1 Algemeen metagegeven. Alias
Definitie 1 Algemeen metagegeven. Body van de metaclass Comment Notes

Specificatie voor «Externe koppeling»

Externe koppelingen worden naar de volgende aspecten gespecificeerd.

Aspect Kardi naliteit Toelichting In UML 2.5 In EA
Naam 0..1 Algemeen metagegeven. Standaard ‘betreft’. name van de metaclass Named element Name
Begrip 0..* Algemeen metagegeven. Tagged value
Alias 0..1 Algemeen metagegeven. UML-Property Alias
Datum opname 1 Algemeen metagegeven. Tagged value
Unidirectioneel 1 Algemeen metagegeven. Direction van de betreffende assiciation (van source naar target)
Relatie eigenaar 1 Algemeen metagegeven. /source: related Element bij Relationship Element Source
Relatie doel 1 Algemeen metagegeven. /target: related Element bij Relationship Element Target
Aggregatietype 1 Algemeen metagegeven. AggregationKind bij metaclass Property Aggregation van de source role met waarde composite of shared

3.2.3 Specificatie metagegevens voor waardenlijsten

Specificatie voor «Referentielijst»

Voor referentielijsten worden de volgende aspecten gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 1 Algemeen metagegeven. name van de metaclass Namedelement Name
Begrip 0..* Algemeen metagegeven. Tagged value
Alias 0..1 Algemeen metagegeven. Alias
Herkomst 1 Algemeen metagegeven. Tagged value
Definitie 1 Algemeen metagegeven. Body van de metaclass Comment Notes
Datum opname 1 Algemeen metagegeven. Tagged value
Toelichting 0..1 Algemeen metagegeven. Tagged value
Locatie 1..1 Algemeen metagegeven. Tagged value

Specificatie voor «Referentie element»

De referentie-elementen worden naar de volgende aspecten gespecificeerd:

Aspect Kardi naliteit Toelichting In UML 2.5 In EA
Naam 1 Algemeen metagegeven. name van de metaclass Named element Name
Begrip 0..* Algemeen metagegeven. Tagged value
Alias 0..1 Algemeen metagegeven. Alias
Definitie 1 Algemeen metagegeven. Body van de metaclass Comment Notes
Datum opname 1 Algemeen metagegeven. Tagged value
Domein (aspecten van een waarde/data)
- Type 1 Algemeen metagegeven. Type
- Lengte 0..1 Algemeen metagegeven. Tagged value
- Patroon 0..1 Algemeen metagegeven. Tagged value
- Formeel patroon 0..1 Algemeen metagegeven. Tagged value
Kardinaliteit 1 Algemeen metagegeven. lowerValue en upperValue van de metaclass Multiplicity Element Multiplicity van de de target role
Identificerend 0..1 Algemeen metagegeven. isID van de metaclass Property isID bij de betreffende class
Toelichting 0..1 Algemeen metagegeven. Tagged value

Specificatie voor «codeList»

Voor codelijst worden de volgende aspecten gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 1 Algemeen metagegeven. De naam van de lijst zoals gespecificeerd in de catalogus van de desbetreffende registratie dan wel, indien het een door de eigen organisatie toegevoegde lijst betreft, de door de eigen organisatie vastgestelde naam. name van de metaclass Named element Name
Begrip 0..* Algemeen metagegeven. Tagged value
Alias 0..1 Algemeen metagegeven. Alias
Herkomst 1 Algemeen metagegeven. 11 tagged value
Definitie 1 Algemeen metagegeven. Body van de metaclass Comment Notes
Datum opname 1 Algemeen metagegeven. tagged value
Toelichting 0..1 Algemeen metagegeven. tagged value
Locatie 1..1 Algemeen metagegeven. tagged value

3.2.4 Specificatie metagegevens voor datatypen

Het betreft metagegevens voor in het informatiemodel gedefinieerde datatypen, oftewel exclusief datatypen die al buiten het model bestaan, zoals Integer, DateTime, Surface.

Specificatie voor «Primitief datatype»

De datatypen worden naar de volgende aspecten gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 1 Algemeen metagegeven. name van de metaclass Named element Name
Begrip 0..* Algemeen metagegeven. Tagged value
Definitie 0..1 Algemeen metagegeven. Body van de metaclass Comment Notes
Domein (aspecten van een waarde/data)
- Lengte 0..1 Algemeen metagegeven. Tagged value
- Patroon 0..1 Algemeen metagegeven. Tagged value
- Formeel patroon 0..1 Algemeen metagegeven. Tagged value
Herkomst 1 Algemeen metagegeven. Tagged value
Datum opname 1 Algemeen metagegeven. Tagged value

Specificatie voor «Gestructureerd datatype»

Voor Gestructureerde datatypen worden de volgende aspecten gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 1 Algemeen metagegeven. name van de metaclass Named element Name
Begrip 0..* Algemeen metagegeven. Tagged value
Herkomst 1 Algemeen metagegeven. Tagged value
Definitie 1 Algemeen metagegeven. Body van de metaclass Comment Notes
Patroon 0..1 Algemeen metagegeven. Tagged value
Formeel patroon 0..1 Algemeen metagegeven. Tagged value
Datum opname 1 Algemeen metagegeven. Tagged value

Specificatie voor «Data element»

De data-elementen worden naar de volgende aspecten gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 1 Algemeen metagegeven. name van de metaclass Named element Name
Begrip 0..* Algemeen metagegeven. Tagged value
Definitie 0..1 Algemeen metagegeven. Body van de metaclass Comment Notes
Domein (aspecten van een waarde/data)
- Type 1 Algemeen metagegeven. Type
- Lengte 0..1 Algemeen metagegeven. Tagged value
- Patroon 0..1 Algemeen metagegeven. Tagged value
- Formeel patroon 0..1 Algemeen metagegeven. Tagged value
Kardinaliteit 1 Algemeen metagegeven. lowerValue en upperValue van de metaclass MultiplicityElement Multiplicity

Specificatie voor «Keuze»

Een Keuze worden naar de volgende aspecten gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 InEA
Naam 1 Algemeen metagegeven. name van de metaclass Namedelement Name
Begrip 0..* Algemeen metagegeven. Tagged value
Herkomst 1 Algemeen metagegeven. Tagged value
Definitie 1 Algemeen metagegeven. Body van de metaclass Comment Notes
Datum opname 1 Algemeen metagegeven. Tagged value

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

3.2.5 Specificatie metagegevens voor packages

Specificatie voor «Informatiemodel»

Informatiemodel packages worden naar de volgende aspecten gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 1 Algemeen metagegeven. De naam van het informatiemodel package. name van de metaclass Namedelement Name
Definitie 1 Algemeen metagegeven. De beschrijving van betekenis en inhoud van het informatiemodel. Bijvoorbeeld: informatiemodel van het geografisch domein luchtkwaliteit. Body van de metaclass Comment Notes
Herkomst * 1 Algemeen metagegeven. De beheerorganisatie, registratie of andere referentie die herleidt tot de bron van het informatiemodel. Tagged value
Informatiemodel type 1 Algemeen metagegeven. De beschrijving van de aard van het informatiemodel: conceptueel, logisch, technisch. Tagged value
Informatiedomein 1 Algemeen metagegeven. Aanduiding van het functionele domein waartoe het informatiemodel behoort. Tagged value
MIM versie 1 De versie van de MIM specificatie die gebruikt is om het informatiemodel in uit te drukken. Tagged value
Bijvoorbeeld: 1.0.1 of 1.1
MIM extensie 0..1 De aanduiding van een extensie op MIM. Tagged value
Bijvoorbeeld: Kadaster of NEN3610:2020
MIM taal 0..1 De aanduiding van de taal die gebruikt is voor de modelelementen. Tagged value
Bijvoorbeeld: EN of NL Relatiemodelleringtype 1

Toelichting Type informatiemodel: zoals bedoeld in paragraaf 1.5. Alle packages, oftewel «Domein» en «View», binnen het informatiemodel hebben hetzelfde type als het informatiemodel zelf.

Specificatie voor «Domein»

Domein packages worden naar de volgende aspecten gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 1 Algemeen metagegeven. De naam van het domein package. name van de metaclass Namedelement Name

Specificatie voor «Extern»

Externe packages worden naar de volgende aspecten gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 1 Algemeen metagegeven. De naam van het externe package zoals gespecificeerd door de externe instantie. name van de metaclass Namedelement Name
Locatie 1 Algemeen metagegeven. Tagged value
Definitie 1 Algemeen metagegeven. De beschrijving van de betekenis van het package, gezien vanuit het eigen informatiemodel. Bijvoorbeeld: bron van definities. Body van de metaclass Comment Notes
Herkomst * 1 Algemeen metagegeven. De registratie of het informatiemodel waaraan het package ontleend is. Bij een view is de herkomst nooit de eigen organisatie. Tagged value

Specificatie voor «View»

View packages worden naar de volgende aspecten gespecificeerd, analoog aan «Extern»:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA?
Naam 1 Algemeen metagegeven. Deze is, indien mogelijk, analoog aan de naamgeving in het externe schema waar de view over gaat, eventueel met een prefix. name van de metaclass Named element Name
Locatie 1 Algemeen metagegeven. Tagged value
Definitie 1 Algemeen metagegeven. Body van de metaclass Comment Notes
Herkomst * 1 Algemeen metagegeven. De registratie of het informatiemodel waaraan het package ontleend is. Bij een view is de herkomst nooit de eigen organisatie. Tagged value

3.2.6 Specificatie metagegevens - overig

3.2.6.1 Specificatie voor Enumeratie

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

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 1 Algemeen metagegeven. name van de metaclass Named element Name
Begrip 0..* Algemeen metagegeven. Tagged value
Definitie 1 Algemeen metagegeven. Body van de metaclass Comment Notes
3.2.6.2 Specificatie voor Enumeratiewaarde

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

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam 1 Algemeen metagegeven. name van de metaclass Named element Name
Definitie 0..1 Algemeen metagegeven. De beschrijving van de betekenis van de enumeratiewaarde zoals gespecificeerd in de catalogus van de desbetreffende registratie. Body van de metaclass Comment Notes
Code 0..1 De in een registratie of informatiemodel aan de enumeratiewaarde toegekend unieke code (niet te verwarren met alias, zoals bedoeld in 2.6.1). Alias van de metaclass Element Import Alias
3.2.6.3 Specificatie voor een Constraint

Constraint betreft de metaclass UML Constraint en wordt naar de volgende aspecten gespecificeerd:

Aspect Kardinaliteit Toelichting In UML 2.5 In EA
Naam√ 1 Algemeen metagegeven. name van de metaclass Named element Name
Specificatie tekst 0..1 De specificatie van de constraint in normale tekst. Notes (type = invariant)
Specificatie formeel 0..1 De beschrijving van de constraint in een formele specificatietaal, in OCL Notes (type =OCL)

3.3 UML Tooling

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

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

4. Metamodel in Linked Data (LD)

4.1 Ontologisch metamodel in LD

Het MIM uitgedrukt in LD houdt onder ander een ontologisch metamodel in. Dit betekent dat er voor elk van de modelelementen van het MIM een klasse en/of eigenschap gedefinieerd is in termen van RDF, RDFS en OWL. In de hierop volgende paragrafen wordt deze uitwerking geven.

Het MIM is een metamodel. Dit betekent dat in termen van het MIM een concreet informatiemodel kan worden uitgewerkt, bijvoorbeeld het informatiemodel Basisregistratie Adressen en Gebouwen. Het MIM is niet bedoeld om vervolgens in termen van dit informatiemodel een concrete dataset te vormen. Zie ook Typen informatiemodellen: het MIM is niet beoogd voor een informatiemodel op niveau 4. Hiervoor is een transformatie nodig naar een (technisch) uitwisselings- of opslagmodel nodig.

Op diezelfde manier levert het toepassen van het MIM in RDF geen ontologie of vocabulaire waarin RDF kan worden uitgedrukt: slechts het informatiemodel zelf is op deze manier in RDF uitgedrukt. Voor de vertaalslag naar een ontologie is een afzonderlijke transformatie nodig.

Vanuit een Linked Data perspectief is dit bijzonder. Een kernmerk van Linked Data is namelijk dat een informatiemodel op niveau 3 ook direct, zonder aanpassingen, bruikbaar is als informatiemodel op niveau 4. Sterker nog: Linked Data modellen zijn ook bruikbaar op niveau 1 en 2. Dit is vanuit het MIM zelf niet mogelijk. Hiervoor is een vertaalslag nodig naar een "echte" Linked Data ontologie.

Zo leidt een MIM objecttype "Schip" tot de volgende weergave in RDF:

@prefix vb: <http://bp4mc2.org/voorbeeld/> .
@prefix mim: <http://bp4mc2.org/def/mim#> .



vb:Schip a mim:Objecttype;
  rdfs:label "Schip"@nl;
.

vb:Schip is in dit voorbeeld een voorkomen van de klasse mim:Objecttype. dit voorkomen kent zelf geen voorkomens. Hiervoor is een vertaling nodig naar een rdfs:Class, bijvoorbeeld door:

@prefix vbo: <http://bp4mc2.org/voorbeeld/def#>.



vbo:Schip a rdfs:Class;
  mim:equivalent vb:Schip;
.
vb:Pakjesboot12 a vbo:Schip.

De transformatie van het MIM model naar deze RDF ontologie is opgenomen in sectie 6.4.

4.2 Structuur metamodel in LD

Het RDF model is opgesplitst in twee delen. Zoals gebruikelijk in RDF zijn deze modeldelen via hun URL op het internet te benaderen:

  1. de RDF vocabulaire, met de (meta)klassen en (meta)eigenschappen;
  2. de RDF Shapesgraph, met "shapes", de structuur die gelden op het gebruik van de klassen en eigenschappen.

In onderstaande paragrafen wordt zowel de vocabulaire als de structuur gezamenlijk per modelelement besproken. Een RDF representatie in turtle wordt gegeven en daarnaast ook een grafische representatie. Hiervoor wordt de verbeelding gebruikt zoals beschreven op https://bp4mc2.org/20181107/#grafische-representatie.

Bij het opstellen van het MIM in RDF is gebruik gemaakt van de algemene, tekstuele beschrijving van het MIM uit het hoofdstukMetamodel Algemeen. Er is een 1-op-1 omzetting gedaan, zonder enige aanpassing van de beschrijvingen. Dit maakt het mogelijk om een MIM informatiemodel om te zetten van de ene representatie (bijvoorbeeld in UML) naar de andere en weer terug, zonder verlies van informatie.

De volgende regels zijn gebruikt bij de omzetting van de MIM tekst naar RDF:

  1. Elk voorkomen van een MIM «metaclass» is omgezet naar een voorkomen van een owl:Class;
  2. Elk metagegeven van een MIM «metaclass» is omgezet naar een voorkomen van een owl:DatatypeProperty, voor zover sprake is van een metagegeven dat een waarde heeft die met een datatype is uit te drukken (zoals tekstuele, nummerieke of boolean metagegevens);
  3. Elk metagegeven van een MIM «metaclass» is omgezet naar een voorkomen van een owl:ObjectProperty, voor zover sprake is van een metagegeven waarbij de waarde verwijst naar een voorkomen van een andere MIM «metaclass»;
  4. Een rdfs:label is opgenomen met de naam van de MIM «metaclass» c.q. het metagegeven;
  5. Een rdfs:comment is opgenomen met de definitie van de MIM «metaclass» c.q. het metagegeven.

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

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

MIM metaclass Metaclass in RDF Shape in RDF Grondslag
Objecttype mim:Objecttype shape:Objecttype grondslag
Attribuutsoort mim:Attribuutsoort shape:Attribuutsoort grondslag
Gegevensgroep mim:Gegevensgroep shape:Gegevensgroep grondslag
Gegevensgroeptype mim:Gegevensgroeptype shape:Gegevensgroeptype grondslag
Generalisatie mim:Generalisatie shape:Generalisatie grondslag
Relatiesoort mim:Relatiesoort shape:Relatiesoort grondslag
Relatieklasse mim:Relatieklasse shape:Relatieklasse grondslag

4.2.2 Datatypen

MIM metaclass Metaclass in RDF Shape in RDF Grondslag
Datatype mim:Datatype shape:Datatype grondslag
Primitief datatype mim:PrimitiefDatatype shape:PrimitiefDatatype grondslag
Gestructureerd datatype mim:GestructuurdDatatype shape:GestructuurdDatatype grondslag
Data element mim:DataElement shape:DataElement grondslag
Enumeratie mim:Enumeratie shape:Enumeratie grondslag
Enumeratiewaarde mim:Enumeratiewaarde shape:Enumeratiewaarde grondslag
Referentielijst mim:Referentielijst shape:Referentielijst grondslag
Referentie element mim:ReferentieElement shape:ReferentieElement grondslag
Codelijst mim:Codelijst shape:Codelijst grondslag

4.2.3 Overige

4.2.3.1 Constraint

MIM metaclass Metaclass in RDF Shape in RDF Grondslag
Constraint mim:Constraint shape:Constraint grondslag
Keuzeconstraint mim:Keuzeconstraint shape:Keuze grondslag
4.2.3.2 Keuze

De "keuze constructie" maakt een keuze mogelijk tussen meerdere attribuutsoorten, datatypen en relatiedoelen (objecttypen). Er mag aan één specifieke keuze maar één soort van deze drie worden verbonden. Indien dit datatype gekozen wordt voor een attribuutsoort of relatiedoel, dan heeft dit de volgende betekenis, afhankelijk van de verbonden soort:

  • Attribuutsoort: een keuze tussen attribuutsoorten in plaats van de attribuutsoort die deze keuze als datatype heeft;
  • Datatype: een keuze tussen datatypen in plaats van dit keuze datatype;
  • Relatiedoel: een keuze tussen objecttypen als relatiedoel in plaats van het doel van de relatieroldoel
MIM metaclass Metaclass in RDF Shape in RDF Grondslag
Keuze mim:Keuze shape:Keuze grondslag
Datatype mim:Datatype shape:Datatype grondslag
Objecttype mim:Objecttype shape:Objecttype grondslag
Attribuutsoort mim:Attribuutsoort shape: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

MIM metaclass Metaclass in RDF Shape in RDF Grondslag
Relatierol (abstract) Relatierol shape:Relatierol grondslag
Relatierol bron RelatierolBron shape:RelatierolBron grondslag
Relatierol doel RelatierolDoel shape:RelatierolDoel grondslag
4.2.3.4 Externe koppeling
MIM metaclass Metaclass in RDF Shape in RDF Grondslag
Externe koppeling mim:ExterneKoppeling shape:ExterneKoppeling grondslag
4.2.3.5 Packages

MIM metaclass Metaclass in RDF Shape in RDF Grondslag
Package mim:Package shape:Package grondslag
Informatiemodel mim:Informatiemodel shape:Informatiemodel grondslag
Domein (het eigen IM) mim:Domein shape:Domein grondslag
Extern mim:Extern shape:Extern grondslag
View mim:View shape:View grondslag

4.3 Nadere specificatie metagegevens in LD

Deze paragraaf is een aanvulling op de paragraaf 'Specificatie metagegevens' in het hoofdstuk Metamodel Algemeen.

De betekenis van de metagegevens worden in LD gespecificeerd los van de klasse waartoe deze metagegevens behoren. Hieronder is een opsomming gegeven van alle metagegevens en de overeenkomstige meta-eigenschap in RDF.

De gegevensregels (structuur) voor de metagegevens zijn wel specifiek per klasse, en worden in de betreffende paragraaf behandeld.

MIM metagegeven Meta-eigenschap in RDF RDF type Grondslag
aggregatietype mim:aggregatietype owl:ObjectProperty grondslag
alias mim:naam owl:DatatypeProperty grondslag
attribuut mim:attribuut owl:ObjectProperty grondslag
authentiek mim:authentiek owl:ObjectProperty grondslag
begrip mim:begrip owl:ObjectProperty grondslag
begripsterm mim:begripsterm owl:DatatypeProperty grondslag
bron mim:bron owl:ObjectProperty grondslag
code mim:code owl:DatatypeProperty grondslag
constraint mim:constraint owl:ObjectProperty grondslag
data element mim:dataElement owl:ObjectProperty grondslag
datum opname mim:datumOpname owl:DatatypeProperty grondslag
definitie mim:definitie owl:DatatypeProperty grondslag
doel mim:doel owl:ObjectProperty grondslag
formeel patroon mim:formeelPatroon owl:DatatypeProperty grondslag
gegevensgroep mim:gegevensgroep owl:ObjectProperty grondslag
groeptype mim:groeptype owl:ObjectProperty grondslag
herkomst mim:herkomst owl:DatatypeProperty grondslag
herkomst definitie mim:herkomstDefinitie owl:DatatypeProperty grondslag
identificerend mim:identificerend owl:DatatypeProperty grondslag
indicatie abstract object mim:indicatieAbstractObject owl:DatatypeProperty grondslag
indicatie afleidbaar mim:indicatieAfleidbaar owl:DatatypeProperty grondslag
indicatie classificerend mim:indicatieClassificerend owl:DatatypeProperty grondslag
indicatie formele historie mim:indicatieFormeleHistorie owl:DatatypeProperty grondslag
indicatie materiële historie mim:indicatieMaterieleHistorie owl:DatatypeProperty grondslag
informatiedomein mim:informatiedomein owl:DatatypeProperty grondslag
informatiemodeltype mim:informatiemodeltype owl:ObjectProperty grondslag
kardinaliteit mim:kardinaliteit owl:DatatypeProperty grondslag
kwaliteit mim:kwaliteit owl:DatatypeProperty
lengte mim:lengte owl:DatatypeProperty grondslag
locatie mim:locatie owl:DatatypeProperty grondslag
mim extensie mim:extensie owl:DatatypeProperty grondslag
mim taal mim:taal owl:DatatypeProperty grondslag
mim versie mim:versie owl:DatatypeProperty grondslag
mogelijk geen waarde mim:mogelijkGeenWaarde owl:DatatypeProperty grondslag
naam mim:naam owl:DatatypeProperty grondslag
patroon mim:patroon owl:DatatypeProperty grondslag
populatie mim:populatie owl:DatatypeProperty
referentie element mim:referentieElement owl:ObjectProperty grondslag
relatiemodelleringstype mim:relatiemodelleringstype owl:ObjectProperty grondslag
relatierol mim:relatierol owl:ObjectProperty
specificatie formeel mim:specificatieFormeel owl:DatatypeProperty
specificatie tekst mim:specificatieTekst owl:DatatypeProperty
subtype mim:subtype owl:ObjectProperty
supertype mim:supertype owl:ObjectProperty
toelichting mim:toelichting owl:DatatypeProperty grondslag
type mim:type owl:ObjectProperty grondslag
unidirectioneel mim:unidirectioneel owl:DatatypeProperty grondslag
waarde mim:waarde owl:ObjectProperty grondslag

4.3.1 Modellering metagegevens voor objecten en attributen in LD

Specificatie voor mim:Objecttype

De objecttypen worden naar de volgende aspecten gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Herkomst mim:herkomst 1 tekst
Definitie mim:definitie 1 tekst
Herkomst definitie mim:herkomstDefinitie 1 tekst
Datum opname mim:datumOpname 1 datum
Populatie mim:populatie 0..1 tekst
Kwaliteit mim:kwaliteit 0..1 tekst
Toelichting mim:toelichting 0..1 tekst
Indicatie abstract object mim:indicatieAbstractObject 1 boolean
Attribuut mim:attribuut 0..n mim:Attribuutsoort
Gegevensgroep mim:gegevensgroep 0..n mim:Gegevensgroep
Constraint mim:constraint 0..n mim:Constraint

Specificatie voor mim:Attribuutsoort

De attribuutsoorten worden naar de volgende aspecten gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Herkomst mim:herkomst 1 tekst
Definitie mim:definitie 1 tekst
Herkomst definitie mim:herkomstDefinitie 1 tekst
Datum opname mim:datumOpname 1 datum
Type mim:type 1 mim:Datatype
Lengte mim:lengte 0..1 tekst
Patroon mim:patroon 0..1 tekst
Formeel patroon mim:formeelPatroon 0..1 tekst
Indicatie materiële historie mim:indicatieMaterieleHistorie 1 boolean
Indicatie formele historie mim:indicatieFormeleHistorie 1 boolean
Kardinaliteit mim:kardinaliteit 1 tekst
Authentiek mim:authentiek 1 Authenticiteit
Toelichting mim:toelichting 0..1 tekst
Indicatie afleidbaar mim:indicatieAfleidbaar 1 boolean
Indicatie classificerend mim:indicatieAfleidbaar 1 boolean
Mogelijk geen waarde mim:mogelijkGeenWaarde 1 boolean
Identificerend mim:identificerend 0..1 tekst

Het veld mim:authentiek verwijst naar één van de volgende mogelijke waarden:

Authenticiteit Definitie
mim:Authentiek In een basisregistratie opgenomen gegeven dat bij wettelijk voorschrift als authentiek is aangemerkt.
mim:Basisgegeven Een in een basisregistratie opgenomen gegeven.
mim:WettelijkGegeven Gegeven behorende bij een wettelijke registratie, niet zijnde een basisregistratie
mim:LandelijkKerngegeven 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 is.
mim:OverigeAuthenticiteit Indien het géén van de voorgaande categorieën betreft. Veelal gaat het dan om proces-, taakveld- of domeinspecifieke gegevens.

Specificatie voor mim:Gegevensgroep

De gegevensgroepen worden naar de volgende aspecten gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Definitie mim:definitie 1 tekst
Toelichting mim:toelichting 0..1 tekst
Gegevensgroeptype mim:gegevensgroeptype 1 mim:Gegevensgroeptype
Herkomst mim:herkomst 1 tekst
Herkomst definitie mim:herkomstDefinitie 1 tekst
Datum opname mim:datumOpname 1 datum
Indicatie materiële historie mim:indicatieMaterieleHistorie 1 boolean
Indicatie formele historie mim:indicatieFormeleHistorie 1 boolean
Kardinaliteit mim:kardinaliteit 1 tekst
Authentiek mim:authentiek 1 Authenticiteit

Specificatie voor mim:Gegevensgroeptype

De gegevensgroeptypen worden naar de volgende aspecten gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Definitie mim:definitie 0..1 tekst
Herkomst definitie mim:herkomstDefinitie 0..1 tekst
Toelichting mim:toelichting 0..1 tekst
Datum opname mim:datumOpname 1 datum
Attribuut mim:attribuut 0..n mim:Attribuutsoort
Gegevensgroep mim:gegevensgroep 0..n mim:Gegevensgroep
Constraint mim:constraint 0..n mim:Constraint

4.3.2 Specificatie metagegevens voor relaties

Relatiesoort en relatierol

Het metamodel heeft twee manieren om een relatie tussen twee objecttypen te beschrijven. Deze keuze wordt aangegeven in de eigen extensie, zoals beschreven in paragraaf 1.8. Alleen het gekozen alternatief is relevant voor de modellering in uw informatiemodel.

  • Alternatief 1: Verplichte benoeming van de naam van de relatie met de bijbehorende metagegevens
  • Alternatief 2: Verplichte benoeming van de rol van het doel in een relatie met de bijbehorende metagegevens en optioneel de benoeming van de naam van de relatie.

Beide alternatieven gebruiken relatiesoort en relatierol, maar met andere regels voor gebruik.

4.3.2.1 Relatiesoort leidend (alternatief 1)

Relatiesoort is verplicht, met een naam en met een definitie en deze is leidend. Metadata aspecten worden hierbij altijd vastgelegd. Het gebruik van relatierol is optioneel (zowel bij bron en doel). Áls er een relatierol doel wordt vastgelegd, dan is de metadata hierbij wel verplicht.

Merk op dat bij het modelleren op deze wijze, alleen de kardinaliteit voor het doel aangegeven kan worden. De kardinaliteit aan de bron kant wordt open gelaten.

Specificatie voor «Relatiesoort»

De relatiesoorten worden naar de volgende aspecten gespecificeerd.

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Unidirectioneel mim:unidirectioneel 1 boolean
Bron mim:bron 1 mim:Objecttype
Doel mim:doel 1 mim:Objecttype
Aggregatietype mim:aggregatietype 1 Aggregatietype
Kardinaliteit mim:kardinaliteit 1 tekst
Herkomst mim:herkomst 1 tekst
Definitie mim:definitie 1 tekst
Toelichting mim:toelichting 0..1 tekst
Herkomst definitie mim:herkomstDefinitie 1 tekst
Datum opname mim:datumOpname 1 datum
Indicatie materiële historie mim:indicatieMaterieleHistorie 1 boolean
Indicatie formele historie mim:indicatieFormeleHistorie 1 boolean
Authentiek mim:authentiek 1 Authenticiteit
Indicatie afleidbaar mim:indicatieAfleidbaar 1 boolean
Mogelijk geen waarde mim:mogelijkGeenWaarde 1 boolean

Het veld mim:aggregatietype verwijst naar één van de volgende mogelijke waarden:

Aggregatietype Definitie
mim:Geen Er is geen sprake van een aggregatie
mim:Compositie Compositie (gesloten wiebertje)
mim:Gedeeld Gedeelde aggregatie (open wiebertje)

Specificatie voor mim:Relatierol

Voor relatierollen worden naar de volgende aspecten gespecificeerd.

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 0..1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Definitie mim:definitie 0..1 tekst
4.3.2.2 Relatierol is leidend (alternatief 2)

Verplichte benoeming van de rol van het doel in een relatie met de bijbehorende metagegevens en optioneel de benoeming van de naam van de relatie.

Specificatie voor «Relatiesoort»

De relatiesoorten worden naar de volgende aspecten gespecificeerd.

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 0..1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Definitie mim:definitie 0..1 tekst
Relatierol mim:relatierol 1..2 Relatierol

Specificatie voor «Relatierol»

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

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Kardinaliteit mim:kardinaliteit 1 tekst
Herkomst mim:herkomst 1 tekst
Definitie mim:definitie 1 tekst
Toelichting mim:toelichting 0..1 tekst
Herkomst definitie mim:herkomstDefinitie 1 tekst
Datum opname mim:datumOpname 1 datum
Indicatie materiële historie mim:indicatieMaterieleHistorie 1 boolean
Indicatie formele historie mim:indicatieFormeleHistorie 1 boolean
Authentiek mim:authentiek 1 Authenticiteit
Mogelijk geen waarde mim:mogelijkGeenWaarde 1 boolean

4.3.3 Specificatie metagegevens voor overige relaties

Specificatie voor mim:Generalisatie bij objecttypen

De generalisaties worden naar het volgende aspect gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Subtype mim:definitie 1 mim:Objecttype
Supertype mim:definitie 1 mim:Objecttype

Specificatie voor mim:Generalisatie bij datatypen

De generalisaties worden naar het volgende aspect gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Subtype mim:definitie 1 mim:Datatype
Supertype mim:definitie 1 mim:Datatype

Specificatie voor mim:Relatieklasse

De relatieklassen worden naar de volgende aspecten gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 0..1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Definitie mim:definitie 0..1 tekst
Constraint mim:constraint 0..n mim:Constraint

Specificatie voor mim:ExterneKoppeling

Externe koppelingen worden naar de volgende aspecten gespecificeerd.

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Datum opname mim:datumOpname 1 datum
Bron mim:bron 1 mim:Objecttype
Doel mim:doel 1 mim:Objecttype
Aggregatietype mim:aggregatietype 1 Aggregatietype
Unidirectioneel mim:unidirectioneel 1 boolean

4.3.4 Specificatie metagegevens voor waardenlijsten

Waar in onderstaande specificaties sprake is van een locatie, wordt in Linked Data termen veronderstelt dat op deze locatie de waardenlijst te vinden is. Concreet betekent dit dat via content negotiation de waardenlijst in een specifieke serialisatie van Linked Data is op te halen (zoals: JSON-LD, RDF/XML, Turtle). Vervolgens wordt verondersteld dat de resources in dit bestand de afzonderlijke waarden van de waardenlijst zijn, of andere metagegevens van de waardenlijst. Zo ligt voor de hand dat het bestand een resource bevat met dezelfde URL als opgegeven in de locatie, waarmee nadere informatie kan worden aangegeven.

Specificatie voor mim:Referentielijst

Voor referentielijsten worden de volgende aspecten gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Herkomst mim:herkomst 1 tekst
Definitie mim:definitie 1 tekst
Herkomst definitie mim:herkomstDefinitie 1 tekst
Datum opname mim:datumOpname 1 datum
Toelichting mim:toelichting 0..1 tekst
Locatie mim:locatie 1 tekst
Referentie-element mim:referentieElement 1..* mim:ReferentieElement

Specificatie voor mim:ReferentieElement

De referentie-elementen worden naar de volgende aspecten gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Definitie mim:definitie 1 tekst
Datum opname mim:datumOpname 1 datum
Type mim:type 1 mim:Datatype
Lengte mim:lengte 0..1 tekst
Patroon mim:patroon 0..1 tekst
Formeel patroon mim:formeelPatroon 0..1 tekst
Kardinaliteit mim:kardinaliteit 1 tekst
Identificerend mim:identificerend 0..1 tekst
Toelichting mim:toelichting 0..1 tekst

Specificatie voor mim:Codelijst

Voor codelijst worden de volgende aspecten gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Herkomst mim:herkomst 1 tekst
Definitie mim:definitie 1 tekst
Datum opname mim:datumOpname 1 datum
Toelichting mim:toelichting 0..1 tekst
Locatie mim:locatie 1 tekst

4.3.5 Specificatie metagegevens voor datatypen

Het betreft metagegevens voor in het informatiemodel gedefinieerde datatypen, oftewel exclusief datatypen die al buiten het model bestaan, zoals Integer, DateTime, Surface.

Specificatie voor mim:PrimitiefDatatype

De datatypen worden naar de volgende aspecten gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Definitie mim:definitie 1 tekst
Type mim:type 1 mim:Datatype
Lengte mim:lengte 0..1 tekst
Patroon mim:patroon 0..1 tekst
Formeel patroon mim:formeelPatroon 0..1 tekst
Herkomst mim:herkomst 1 tekst
Datum opname mim:datumOpname 1 datum

Specificatie voor mim:GestructureerdDatatype

Voor Gestructureerde datatypen worden de volgende aspecten gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Herkomst mim:herkomst 1 tekst
Definitie mim:definitie 1 tekst
Patroon mim:patroon 0..1 tekst
Formeel patroon mim:formeelPatroon 0..1 tekst
Datum opname mim:datumOpname 1 datum
Data-element mim:dataElement 0..* mim:DataElement

Specificatie voor mim:DataElement

De data-elementen worden naar de volgende aspecten gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Definitie mim:definitie 1 tekst
Type mim:type 1 mim:Datatype
Lengte mim:lengte 0..1 tekst
Patroon mim:patroon 0..1 tekst
Formeel patroon mim:formeelPatroon 0..1 tekst
Kardinaliteit mim:kardinaliteit 1 tekst

4.3.6 Specificatie metagegevens voor packages

Specificatie voor mim:Informatiemodel

Informatiemodel packages worden naar de volgende aspecten gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Definitie mim:definitie 1 tekst
Herkomst mim:herkomst 1 tekst
MIM versie mim:mimversie 1 tekst
MIM extensie mim:mimextensie 0..1 tekst
MIM taal mim:mimtaal 0..1 tekst
Informatiedomein mim:informatiedomein 1..1 tekst
Informatiemodel type mim:informatiemodeltype 1..1 Informatiemodeltypen
Relatiemodelleringtype mim:relatiemodelleringtype 1..1 Relatiemodelleringtypen

Het veld mim:informatiemodeltype verwijst naar één van de volgende mogelijke waarden:

Informatiemodeltype Definitie
mim:ConceptueelInformatiemodel Niveau-2 model, conform deze sectie
mim:LogischInformatiemodel Niveau-3 model, conform deze sectie
mim:TechnischInformatiemodel Niveau-4 model, conform deze sectie

Het veld mim:relatiemodelleringtype verwijst naar één van de volgende mogelijke waarden:

Relatiemodelleringtype Definitie
mim:RelatiesoortLeidend Relatiesoort leidend, conform deze sectie
mim:RelatierolLeidend Relatierol leidend, conform deze sectie

Specificatie voor mim:Domein

Domein packages worden naar de volgende aspecten gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst

Specificatie voor mim:Extern

Externe packages worden naar de volgende aspecten gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Locatie mim:locatie 1 tekst
Definitie mim:definitie 1 tekst
Herkomst mim:herkomst 1 tekst

Specificatie voor mim:View

Externe packages worden naar de volgende aspecten gespecificeerd:

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Locatie mim:locatie 1 tekst
Definitie mim:definitie 1 tekst
Herkomst mim:herkomst 1 tekst

4.3.7 Specificatie metagegevens - overig

4.3.7.1 Specificatie voor Enumeratie

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

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Alias mim:alias 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst
Definitie mim:definitie 1 tekst
Waarde mim:waarde 1..* mim:Waarde
4.3.7.2 Specificatie voor Enumeratiewaarde

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

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Definitie mim:definitie 0..1 tekst
Code mim:code 0..1 tekst
Begrip mim:begrip 0..* skos:Concept
Begripsterm mim:begripsterm 0..* tekst

Een enumeratiewaarde mag geen alias hebben, omdat in UML het alias-veld wordt gebruikt voor de mim:code. Mocht toch een mim:alias zijn opgegeven voor een enumeratiewaarde, dan dient deze gelezen te worden als een mim:code. In het RDF model is mim:code een subproperty van een mim:alias.

4.3.7.3 Specificatie voor een Constraint

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

Aspect Eigenschap Kardinaliteit Datatype of klasse
Naam mim:naam 1 tekst
Specificatie-tekst mim:specificatieTekst 0..1 tekst
Specificatie-formeel mim:specificatieFormeel 0..1 tekst

4.4 Linked Data Tooling

Het metamodel van MIM is specifiek voor het MIM opgesteld. Hiervoor zijn niet direct tools beschikbaar. Wel zijn er twee alternatieve opties die modelleurs kunnen volgen:

  1. Modelleurs kunnen een MIM model met behulp van Enterprise Architect opstellen. Er is een tool Imvertor, waarmee het mogelijk is om een MIM Model opgesteld in Enterprise Architect te transformeren naar een Linked Data model. Deze tool is open source en is te vinden op www.imvertor.org.

  2. Modelleurs kunnen ook direct in een Linked Data model (in OWL en SHACL) opstellen. Een dergelijk model kan, indien het voldoet aan de transformatieregels, gezien worden als een MIM informatiemodel. Om expliciet de link naar het MIM duidelijk te maken, kan gebruik worden gemaakt van deze SPARQL constructieregels, die een RDF/RDFS/OWL/SHACL model "terugvertalen" naar een MIM model. De terugvertaalregels zijn beschreven in sectie 6.4.9. Er zijn diverse tools beschikbaar om een dergelijk model op te stellen. De meest bekende tools zijn Protege (open source), Topbraid Composer en Poolparty (de laatste twee zijn commerciële producten). Daarnaast zijn er ook veel modelleurs die gebruik maken van generieke IDE's voor het maken van Linked Data modellen, vaak op basis van de voor mensen leesbare Turtle syntax.

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

5.1 Datatype(n)

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

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

  1. Datatypen, primitief: data zoals “Amersfoort” of “10” worden vastgelegd als CharacterString en Integer. Dit volgt de internationale standaarden voor datatypen.

  2. Datatypen (met een naam), landelijk volgens het GAB: datatypen zoals

  3. Gestructureerde datatypen: een combinatie van data, zoals een bedrag “5 euro”, of een GM_Surface. Deze volgen ook internationale of nationale standaarden.

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

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

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

5.1.1 Primitive datatypes

Dit metamodel onderkend (momenteel) de volgende extern gedefinieerde primitive datatypes. 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 datatypes 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}.

5.1.2 Datatype zelf definiëren

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 datatypes hebben altijd een eigen definitie en optioneel een eigen patroon of formeel patroon.

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

  • 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).
  • Een beperking op een Real te specificeren door 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 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 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.

5.1.3 Datatypen landelijk

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

5.2 Gestructureerd datatype

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

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

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

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

Gestructureerd datatype representeren als één gegevenselement  

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

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

5.3 Gegevensgroeptype

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

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

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

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.

5.3.2 Gegevensgroep versus Gestructureerd datatype

Een gegevensgroep is niet hetzelfde als een Gestructureerd datatype.

  • Eendatatype beschrijft de structuur van data, een gegevensgroep beschrijft de semantiek van een kenmerk van een object.
  • Als één kenmerk van een object uitverschillende stukjes data bestaat, dan wordt een Gestructureerd datatypegebruikt. 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.

5.4 Keuze tussen datatypes (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.

Attribuutsoort geometrie met als type de Keuze PuntOfVlak.
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.

Attribuutsoort hoogte met als type de Keuze BereikOfWaarde.
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.

5.5 Domeinwaarden of lijsten

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

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

Als sprake is van dynamiek in de domeinwaarden wordt een Referentielijst of 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
( http://www.kadaster.nl/schemas/waardelijsten/CultuurcodeOnbebouwd ).

De referentielijst is hiermee een bijzondere vorm van datatype.

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

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

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

CodeList Gebruik een 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.

5.6 Abstracte objecttypes en concrete objecten

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

Conceptueel informatiemodel

*Specialisatie / generalisatie*
Bovenstaande vragen beantwoorden we aan de hand van 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.




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

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

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

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

5.7 Relatieklasse (uitzonderingen)

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

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

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

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.

5.8 Constraint

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

Een Constraint wordt beschreven met een:

en optioneel:

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

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

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

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

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

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

5.9 Historie

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

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

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

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

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

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

Historie op conceptueel niveau Op conceptueel niveau is het wel altijd mogelijk om aan te geven dát het bijhouden van historie aan de orde is voor een (elk) gegeven, dat wil zeggen een attribuut of relatie van een object, te weten via een metagegeven. Deze metagegevens specificeren we als volgt: - Indicatie materiële historie: indicatie of de materiële historie van de attribuutsoort te bevragen is. Materiële historie geeft aan wanneer een verandering is opgetreden in de werkelijkheid die heeft geleid tot verandering van de attribuutwaarde. Materiële historie impliceert dat actuele, historische en eventuele toekomstige attribuutwaarden te bevragen zijn. - Indicatie formele historie: indicatie of de formele historie van de attribuutsoort te bevragen is. Formele historie geeft aan wanneer in de administratie een verandering is verwerkt van de attribuutwaarde (wanneer was de verandering bekend en is deze verwerkt).

‘bouwjaar pand’ heeft al materiële historie in zich: het bouwjaar is het moment 
waarop de wijziging in de werkelijkheid zich voordeed en wijzigt niet. 
De ‘indicatie materiële historie’ ervan is daarom Nee. 



BSN van een Persoon geldt voor de persoon vanaf het moment dat de persoon in de 
BRP is opgenomen en wijzigt niet: ‘indicatie materiële historie’ Nee. 




De Achternaam van een persoon kan wijzigen: ‘indicatie materiële historie’ Ja. 




Als je niet toeziet op het daadwerkelijk kappen van een boom maar het gekapt zijn 
wel in een registratie wil opnemen: ‘indicatie materiële historie’ Nee en 
‘indicatie formele historie’ Ja.

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

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

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

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

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

5.10 Afleidbare gegevens

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

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

5.11 Authentieke gegevens

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

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

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.

5.12 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 is dit 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:

Verder, wanneer er sprake is van mogelijk geen waarde dan kan het waardevol zijn om de reden waarom de waarde ontbreekt aan te geven. Ie 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.

5.13 Externe schema’s (her) gebruiken

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

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

Voor het uitwisselen van geografische informatie op basis van NEN3610 is een 
tweetal externe packages onderkend waarnaar vanuit deeigeninformatiemodellen 
kan worden verwezen: [[!NEN3610]], of GML3.2

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

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

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

5.15 Stelselcatalogus en stelselafspraken voor basisregistraties

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

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

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

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.

Waardenbereik afspraken - Authentiek: als in dit metamodel ‘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).

5.16 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).

5.16.1 Uniekheid van namen van modelelementen

  • Objecttypes hebben een unieke naam binnen het hele informatiemodel
  • Datatypes 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.

5.16.2 Dezelfde naam en/of definitie gebruiken voor meerdere modelelementen

Er kan sprake zijn van 1 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 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.

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

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

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

In de bijlage is een template opgenomen om de naamgevingsconventies in te specificeren. Dit is een hulptabel, die u over kunt nemen naar uw eigen extensie (zoals bedoeld in paragraaf 1.8) en in kunt vullen voor uw eigen informatiemodel (of organisatie).

5.17 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 paragraaf Typen Informatiemodellen) 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 modellement 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.

5.17.1 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: http://brk.basisregistraties.overheid.nl/id/begrip/Perceel

5.17.2 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 Decimaalm). 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’.

5.17.3 Definitie van een modelelement en de definitie van een begrip

De definitie van het modelement 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 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

Modelelement Naamgevingsconventie Voorbeeld
Objecttype
Naam objecttype
Attribuutsoort
Naam attribuutsoort
Relatiesoort
Naam relatie
Gegevensgroeptype
Naam gegevensgroeptype
Gegevensgroep
Naam gegevensgroep
Externe koppeling
Naam externe koppeling
Relatieklasse
Naam relatieklasse
Referentielijst
Naam referentielijst
Referentie element
Naam referentie element
Gestructureerd datatype
Naam Gestructureerd datatype
Data element
Naam data element
Datatype
Naam datatype
Union
Naam Union
Union element
Naam union element
Enumeratie
Naam enumeratie
Enumeratiewaarde
Code enumeratiewaarde
Naam enumeratiewaarde

6.3 Vertaling naar engels

MIM is een specificatie die is ontstaan vanuit de behoeften van enkele basisregistraties en afnemers daarvan. Daarbij is de aansluiting bij internationale (geo)normen gewaarborgd. Echter de precieze aansluiting bij die normen is niet altijd expliciet gemaakt in MIM. Met name de relatie met de modelleertechnieken van de ISO 19100 serie is van belang. Deze ISO standaarden vormen de ondergrond voor o.a. Inspire en NEN3610.

In het volgende overzicht geldt het volgende

Kolom Aard waarden:

Kolom MIM benaming ISO waarden:

Kolom Reden waarden:

Aard MIM 1.1 MIM benaming ISO Reden
ST Objecttype FeatureType (ISO 19109) GF_FeatureType Vertaling
ST Attribuutsoort AttributeType (ISO 19109) GF_AttributeType Vertaling
ST Gegevensgroeptype AttributeGroupType Vertaling en precisering
ST Gegevensgroep AttributeGroup Vertaling en precisering
ST Relatiesoort AssociationType (ISO 19109) GF_AssociationType Vertaling
ST Relatieklasse AssociationClass Vertaling
ST Externe koppeling ExternalLink Vertaling
ST Relatierol AssociationRole (ISO 19109) GF_AssociationRole Vertaling
ST Referentielijst ReferenceList Vertaling
ST Referentie element ReferenceElement Vertaling
ST Enumeratie Enumeration Vertaling
ST Enumeratiewaarde Enum Vertaling
ST CodeLijst CodeList (ISO 19103) -
ST Datatype SimpleType Vertaling en precisering
ST Complex datatype ComplexType Vertaling
ST Data element DataElement Vertaling
ST Keuze Union Defines a union data type. -
ST Keuze element UnionElement Vertaling
ST Extern External Vertaling
ST View View Vertaling
TV Beheerder Administrator Vertaling
TV Data locatie Data location Vertaling
TV Datum opname Date recorded Vertaling
TV Eigenaar Owned by Vertaling
TV Formeel patroon Formal pattern Vertaling
TV Herkomst Source Vertaling
TV Herkomst definitie Origin of definition Vertaling
TV Indicatie authentiek Indication authentic Vertaling
TV Indicatie formele historie Indication formal history Vertaling
TV Indicatie materiële historie Indication material history Vertaling
TV Kwaliteit Quality Vertaling
TV Lengte Length Vertaling
TV Locatie Location Vertaling
TV Mogelijk geen waarde Voidable Vertaling
TV Patroon Pattern Vertaling
TV Populatie Population Vertaling
TV Regels Rules Vertaling
TV Toelichting Description Vertaling
VAL Ja Yes Vertaling
VAL Nee No Vertaling
VAL Zie groep See group Vertaling
VAL Authentiek Authentic Vertaling
VAL Basisgegeven Base data Vertaling
VAL Landelijk kerngegeven National base data Vertaling
VAL Gemeentelijk kerngegeven Municipal base data Vertaling
VAL Overig Other Vertaling

6.4 Transformatie MIM - RDFS/OWL/SHACL

6.4.1 Inleiding

Het MIM is een metamodel. Dit betekent dat in termen van het MIM een concreet informatiemodel kan worden uitgewerkt, bijvoorbeeld het informatiemodel Basisregistratie Adressen en Gebouwen. Het MIM is niet bedoeld om vervolgens in termen van dit informatiemodel een concrete dataset te vormen. Hiervoor is een transformatie nodig naar een (technisch) uitwisselings- of opslagmodel, bijvoorbeeld een XSD schema of een RDMS database definitie.

Op diezelfde manier levert het toepassen van het MIM in RDF geen ontologie of vocabulaire waarin RDF kan worden uitgedrukt in een concrete Linked Data dataset. Slechts het informatiemodel zelf is op deze manier in RDF uitgedrukt. Een afzonderlijke transformatie is nodig voor de vertaalslag naar een ontologie voor een concrete Linked Data.

Zo leidt een MIM objecttype "Schip" tot de volgende weergave in RDF:

@prefix vb: <http://bp4mc2.org/voorbeeld/>.
@prefix mim: <http://bp4mc2.org/def/mim#>.



vb:Schip a mim:Objecttype;
  rdfs:label "Schip"@nl;
.

vb:Schip is in dit voorbeeld een voorkomen van de klasse mim:Objecttype. Dit voorkomen, vb:Schip, kent zelf geen voorkomens. Het is dan ook niet mogelijk om te stellen:

vb:Pakjesboot12 a vb:Schip.

vb:Schip is immers geen klasse maar zelf een voorkomen! Om te kunnen uitdrukken dat de pakjesboot een voorkomen van de klasse Schip is, is een vertaling nodig naar een rdfs:Class of owl:Class, bijvoorbeeld door:

@prefix vbo: <http://bp4mc2.org/voorbeeld/def#>.



vbo:Schip a rdfs:Class;
  mim:equivalent vb:Schip;
.
vb:Pakjesboot12 a vbo:Schip.

Dit document beschrijft hoe deze vertaling van het MIM model in RDF naar een RDFS-gebaseerde ontologie plaatsvindt. Daarbij zal niet alleen gebruik worden gemaakt van RDFS, maar ook van de OWL, SHACL en SKOS vocabulaires. De vertaling wordt zo veel mogelijk als SPARQL rules beschreven, zodat een machinale vertaling mogelijk is.

De vertaling is omkeerbaar. Op deze wijze kan een regulier Linked Data model in RDF/RDFS/OWL/SHACL worden gezien als een MIM compliant model. De SPARQL rules die vanuit een RDFS-gebaseerde ontologie de vertaling maken naar een MIM model in RDF, zijn daarom ook beschreven en opgenomen in paragraaf Transformatie vanuit RDFS/OWL/SHACL.

6.4.2 Gebruikte functies

In de SPARQL rules wordt gebruik gemaakt van een aantal SPARQL functies. In onderstaande tabel staan deze opgesomd met de specificatie van de werking.

Functie Specificatie
t:CamelCase Codeert een tekstveld naar een URI-vorm op basis van (upper) CamelCase regels
t:camelCase Codeert een tekstveld naar een URI-vorm op basis van (lower) camelCase regels
t:kebabcase Codeert een tekstveld naar een URI-vorm op basis van kebabcase regels (een - voor spaties)
t:classuri Formuleert de uri voor een klasse op basis van de naam van een MIM resource. De class URI is opgebouwd als {namespace}#{t:CamelCase(naam)}. De {namespace} is een vooraf vastgestelde waarde die gelijk is aan de te maken ontologie.
t:nodeshapeuri Formuleert de uri voor een nodeshape op basis van de naam van een MIM resource. De nodeshape URI is opgebouwd als {shape-namespace}#{t:CamelCase(term)}. De {shape-namespace} is een vooraf vastgestelde waarde die gelijk is aan de te maken shapesgraph.
t:propertyuri Formuleert de uri voor een property op basis van de naam van een MIM resource. De property URI is opgebouwd als {namespace}#{t:camelCase(naam)}. Zie ook t:classuri.
t:propertyshapeuri Formuleert de uri voor een propertyshape op basis van de naam van een MIM resource en de naam van de MIM resource die hiervan de "bezitter" is. De propertyshape URI is opgebouwd als {shape-namespace}#{t:CamelCase(bezittersnaam)}-{t:camelCase(naam)}. Zie ook t:nodeshapeuri.
t:nodepropertyuri Formuleert de uri voor een property op basis van de naam van een MIM resource en de naam van de MIM resource die hiervan de "bezitter" is. De property URI is opgebouwd als {namespace}#{t:CamelCase(bezittersnaam)}-{t:camelCase(naam)}. Zie ook t:classuri.
t:statementuri Formuleert de uri voor een rdf:Statement op basis van zijn afzonderlijke elementen. Mogelijke invulling kan het maken van een hash zijn op basis van de aaneenschakeling van subject, predicate en object.
t:schemeuri Formuleert de uri voor een concept-scheme op basis van de naam van een MIM resource. De concept-scheme URI is opgebouwd als {namespace}/id/scheme/{t:CamelCase(naam)}. De {namespace} is een vooraf vastgestelde waarde die gelijk is aan de locatie van de package.
t:concepturi Formuleert de uri voor een concept op basis van de naam van een MIM resource. De concept URI is opgebouwd als {namespace}/id/concept/{t:CamelCase(naam)}. De {namespace} is een vooraf vastgestelde waarde die gelijk is aan de locatie van de package.
t:mincount Formuleert de minimum kardinaliteit op basis van een kardinaliteitsaanduiding (zie bij mim:kardinaliteit). De waarde kan ook unbound zijn, in dat geval wordt ook de variable niet gebound en daardoor de betreffende triple niet opgevoerd.
t:maxcount Formuleert de maximum kardinaliteit op basis van een kardinaliteitsaanduiding (zie bij mim:kardinaliteit). De waarde kan ook unbound zijn, in dat geval wordt ook de variable niet gebound en daardoor de betreffende triple niet opgevoerd.
Noot
Noot

6.4.3 URI-munting

Een belangrijk gegeven in Linked Data is het munten van URI's. Bij de vertaling van een MIM modelelement naar een overeenkomstige resource in Linked Data vocabulaires zullen ook nieuwe URI's gemunt moeten worden. Enerzijds omdat er (soms) sprake is van meer dan één resource voor één modelelement, maar ook omdat een Linked Data resource wel equivalent is met een MIM modelelement, maar niet exact gelijk: we willen niet dat de formele semantiek van de Linked Data vocabulaires vermengt wordt met de formele semantiek van het MIM metamodel.

Daarnaast geldt dat het in Linked Data gebruikelijk is om URI's over te nemen van andere (externe) vocabulaires c.q. modellen. Ook het MIM ondersteund dit, in de vorm van de mim metamodelklassen mim:Extern en mim:View. Echter, anders dan bij UML, behoren de modelementen uit deze externe modellen ook de URI's te krijgen die horen bij deze externe modellen.

Het metamodelelement mim:locatie heeft een belangrijke rol bij het bepalen van de URI. De waarde van dit metamodelelement wordt gezien als de namespace-prefix van de URI. Dit betekent dan ook dat alle modelelementen binnen één package normaal gesproken dezelfde namespace krijgen. Gebruikelijk is dan ook dat externe packages de namespace krijgen die behoren bij het externe vocabulaire en de eigen domein-packages de namespace krijgen die behoort bij de eigen vocabulaire. Hierop zijn een aantal uitzonderingen:

  1. Indien sprake is van het hergebruiken van een attribuutsoort die ook gedefinieerd is in een externe of view package, dan wordt de mim:locatie gebruikt van deze externe of view package. Hierdoor is het mogelijk om een attribuutsoort "label" op te nemen die gemunt wordt met de URI http://www.w3.org/2000/01/rdf-schema# (rdfs:label).
  2. Indien sprake is van een view package, dan wordt de mim:locatie van deze view package alleen gebruikt voor de vocabulaire URI's (voorkomens van owl:Class, owl:DatatypeProperty en owl:ObjectProperty). Voor de voorkomens van shapes (sh:NodeShape en sh:PropertyShape) wordt juist gebruik gemaakt van de mim:locatie zoals deze bij de eigen domein-package is opgegeven. Rationale hierachter is dat bij view-packages de "view" lokaal gedefinieerd is, maar de elementen wel afkomstig zijn uit een externe vocabulaire.

6.4.4 Overzicht

Onderstaande tabellen geven een overzicht van alle transformaties en een referentie naar de betreffende transformatieregel

6.4.4.1 Klassen
MIM-klasse Vertaling Referentie
mim:Objecttype owl:Class, sh:NodeShape Objecttype
mim:Attribuutsoort owl:ObjectProperty, owl:DatatypeProperty, sh:PropertyShape Attribuutsoort
mim:Gegevensgroep sh:PropertyShape, owl:ObjectProperty Gegevensgroep
mim:Gegevensgroeptype owl:Class, sh:NodeShape Gegevensgroeptype
mim:Generalisatie rdfs:subClassOf rdf:Statement Generalisatie
mim:Relatiesoort sh:PropertyShape, owl:ObjectProperty Relatiesoort
mim:Relatieklasse rdf:Statement Relatieklasse
mim:ExterneKoppeling sh:PropertyShape, owl:ObjectProperty Externe koppeling
mim:Relatierol sh:PropertyShape, owl:ObjectProperty Relatierol
mim:Referentielijst owl:Class, sh:NodeShape Referentielijst
mim:ReferentieElement owl:Class, sh:NodeShape Referentie-element
mim:Enumeratie owl:Class, sh:NodeShape, skos:ConceptScheme Enumeratie
mim:Enumeratiewaarde Enumeratie-klasse Enumeratiewaarde
mim:Codelijst owl:Class, sh:NodeShape Codelijst
mim:Datatype n.v.t. Abstracte klasse
mim:PrimitiefDatatype rdfs:Datatype Primitief datatype
mim:GestructureerdDatatype sh:NodeShape Gestructureerd datatype
mim:DataElement owl:ObjectProperty, owl:DatatypeProperty, sh:PropertyShape Data element
mim:Keuze sh:xone, rdf:List Keuze
mim:Keuzeconstraint sh:xone, rdf:List Keuze
mim:Package n.v.t. Abstracte klasse
mim:Domein owl:Ontology Domein
mim:Extern owl:imports Extern
mim:View owl:imports View
mim:Constraint mim:Constraint Constraint
mim:RelatierolBron sh:PropertyShape, owl:ObjectProperty Relatierol
mim:RelatierolDoel sh:PropertyShape, owl:ObjectProperty Relatierol
6.4.4.2 Eigenschappen
MIM-eigenschap Vertaling Referentie
mim:naam rdfs:label naam
mim:alias skos:altLabel alias
mim:begrip dct:subject begrip
mim:begripsterm mim:begripsterm begripsterm
mim:definitie rdfs:comment definitie
mim:toelichting mim:toelichting toelichting
mim:herkomst mim:herkomst herkomst
mim:herkomstDefinitie mim:herkomstDefinitie herkomst definitie
mim:datumOpname mim:datumOpname datum opname
mim:indicatieMaterieleHistorie mim:indicatieMaterieleHistorie indicatie materiële historie
mim:indicatieFormeleHistorie mim:indicatieFormeleHistorie indicatie formele historie
mim:kardinaliteit sh:minCount, sh:maxCount kardinaliteit
mim:authentiek mim:authentiek authentiek
mim:indicatieAfleidbaar mim:indicatieAfleidbaar indicatie afleidbaar
mim:mogelijkGeenWaarde mim:mogelijkGeenWaarde, sh:minCount mogelijk geen waarde
mim:locatie mim:locatie locatie
mim:type sh:datatype, sh:node type
mim:lengte sh:maxLength lengte
mim:patroon mim:patroon patroon
mim:formeelPatroon sh:pattern formeel patroon
mim:uniekeAanduiding mim:uniekeAanduiding unieke aanduiding
mim:populatie mim:populatie populatie
mim:kwaliteit mim:kwaliteit kwaliteit
mim:indicatieAbstractObject sh:propertyShape en mim:indicatieAbstractObject indicatie abstract object
mim:identificerend mim:identificerend identificerend
mim:gegevensgroeptype sh:node gegevensgroeptype
mim:unidirectioneel (bij false) owl:inverseOf unidirectioneel
mim:bron sh:property bron
mim:doel sh:class doel
mim:aggregatietype mim:aggregatietype aggregatietype
mim:subtype rdfs:subClassOf Generalisatie
mim:supertype rdfs:subClassOf Generalisatie
mim:code skos:notation code
mim:specificatieTekst mim:specificatieTekst specificatie-tekst
mim:specificatieFormeel mim:specificatieFormeel specificatie-formeel
mim:attribuut sh:property attribuut
mim:gegevensgroep sh:property gegevensgroep
mim:waarde rdf:type, skos:inScheme Enumeratie
mim:constraint mim:constraint Constraint
mim:element sh:property Data element
mim:indicatieClassificerend rdfs:subClassOf (onder meer) indicatie classificerend
6.4.4.3 Instanties (datatypen)
MIM datatype Vertaling Referentie
mim:CharacterString xsd:string Primitief datatype - standaard datatypen
mim:Integer xsd:integer Primitief datatype - standaard datatypen
mim:Real xsd:float Primitief datatype - standaard datatypen
mim:Decimal xsd:decimal Primitief datatype - standaard datatypen
mim:Boolean xsd:boolean Primitief datatype - standaard datatypen
mim:Date xsd:date Primitief datatype - standaard datatypen
mim:DateTime xsd:dateTime Primitief datatype - standaard datatypen
mim:Year xsd:gYear Primitief datatype - standaard datatypen
mim:Day xsd:gDay Primitief datatype - standaard datatypen
mim:Month xsd:gMonth Primitief datatype - standaard datatypen
mim:URI xsd:anyURI Primitief datatype - standaard datatypen

6.4.5 Klassen

Omdat het getransformeerde model daadwerkelijk een nieuw model is, zullen de elementen in het getransformeerde model ook eigen URI's krijgen. Om de relatie tussen het originele MIM-model het het getransformeerde model op basis van RDFS te behouden, wordt de eigenschap mim:equivalent gebruikt.

6.4.5.1 Transformatie: Objecttype

De typering van een groep objecten die binnen een domein relevant zijn en als gelijksoortig worden beschouwd.

Een mim:Objecttype wordt vertaald naar een owl:Class in combinatie met een sh:NodeShape.

Noot
CONSTRUCT {
  ?class a owl:Class.
  ?class mim:equivalent ?objecttype.
  ?nodeshape a sh:NodeShape.
  ?nodeshape mim:equivalent ?objecttype.
  ?nodeshape sh:targetClass ?class.
}
WHERE {
  ?objecttype a mim:Objecttype.
  ?objecttype mim:naam ?objecttypenaam.
  BIND (t:classuri(?objecttypenaam) as ?class)
  BIND (t:nodeshapeuri(?objecttypenaam) as ?nodeshape)
}
6.4.5.2 Transformatie: Attribuutsoort

De typering van gelijksoortige gegevens die voor een objecttype van toepassing is.

Een mim:Attribuutsoort wordt vertaald naar een sh:PropertyShape in combinatie met een owl:DatatypeProperty.

In OWL is een property anders dan in het MIM een first class citizen. Dit betekent dat als in twee objecttypen gebruik wordt gemaakt van een attribuutsoort die dezelfde naam heeft, dit leidt tot twee verschillende attribuutsoorten. In OWL zou dit echter leiden tot maar één attribuutsoort, tenzij daadwerkelijk sprake is van verschil in betekenis.

Noot
Noot
Noot

Indien het datatype van een attribuutsoort gelijk is aan PrimitiefDatatype (of een daarvan afgeleid datatype), dan is sprake van een owl:DatatypeProperty en een sh:nodeKind sh:Literal. In alle andere gevallen is sprake van een owl:Objecttype en een sh:nodeKind sh:Iri. Zie ook de transformatie van de eigenschapen mim:type.

De URI van de propertyshape wordt afgeleid van de naam van het modelelement dat de attribuutsoort "bezit" en de naam van de attribuutsoort. De URI van de datatypeproperty wordt afgeleid van de naam van de attribuutsoort.

CONSTRUCT {
  ?propertyshape a sh:PropertyShape.
  ?propertyshape sh:path ?datatypeproperty.
  ?propertyshape sh:nodekind sh:Literal.
  ?propertyshape mim:equivalent ?attribuutsoort.
  ?datatypeproperty a owl:DatatypeProperty.
  ?datatypeproperty mim:equivalent ?attribuutsoort.
}
WHERE {
  ?attribuutsoort a mim:Attribuutsoort.
  ?attribuutsoort mim:naam ?attribuutsoortnaam.
  ?bezitter mim:attribuut ?attribuutsoort.
  ?bezitter mim:naam ?bezittersnaam
  BIND (t:propertyshapeuri(?bezittersnaam,?attribuutsoortnaam) as ?propertyshape)
  BIND (t:propertyuri(?attribuutsoortnaam) as ?datatypeproperty)
  {
    {
      ?attribuutsoort mim:datatype/rdfs:subClassOf* mim:PrimitiefDatatype.
      BIND (owl:DatatypeProperty as ?type)
    }
    UNION
    {
      ?attribuutsoort mim:datatype ?datatype.
      FILTER NOT EXISTS {
        ?attribuutsoort mim:datatype/rdfs:subClassOf* mim:PrimitiefDatatype.
      }
      BIND (owl:ObjectProperty as ?type)
    }
}
6.4.5.3 Transformatie: Gegevensgroep

Een typering van een groep van gelijksoortige gegevens die voor een objecttype van toepassing is.

Een mim:Gegevensgroep wordt vertaald naar een sh:PropertyShape in combinatie met een owl:ObjectProperty. De nodekind van de propertyshape is een sh:BlankNode. Gedachte hierachter is dat de gegevensgroep de verbinding is tussen een objecttype en een gegevensgroeptype. Een gegevensgroeptype is vervolgens een groep van samenhangende attribuutsoorten, wat overeen komt met een class en een nodeshape (zie ook gegevensgroeptype). Omdat een gegevensgroeptype geen eigen identiteit heeft, zal dit gemodelleerd worden als blank node.

De URI van de propertyshape wordt afgeleid van de naam van het modelelement dat de gegevensgroep "bezit" en de naam van de gegevensgroep. De URI van de objectproperty wordt afgeleid van de naam van de gegevensgroep.

CONSTRUCT {
  ?propertyshape a sh:PropertyShape.
  ?propertyshape sh:path ?objectproperty.
  ?propertyshape sh:nodekind sh:BlankNode.
  ?propertyshape mim:equivalent ?gegevensgroep.
  ?objectproperty a owl:ObjectProperty.
  ?objectproperty mim:equivalent ?gegevensgroep.
}
WHERE {
  ?gegevensgroep a mim:Gegevensgroep.
  ?gegevensgroep mim:naam ?gegevensgroepnaam.
  ?bezitter mim:gegevensgroep ?gegevensgroep.
  ?bezitter mim:naam ?bezittersnaam
  BIND (t:propertyshapeuri(?bezittersnaam,?gegevensgroepnaam) as ?propertyshape)
  BIND (t:propertyuri(?gegevensgroepnaam) as ?objectproperty)
}
6.4.5.4 Transformatie: Gegevensgroeptype

Een groep van met elkaar samenhangende attribuutsoorten. Een gegevensgroeptype is altijd een type van een gegevensgroep.

Een mim:Gegevensgroeptype wordt vertaald naar een owl:Class en een sh:NodeShape, net zoals een mim:Objecttype.

Merk op dat er in het getransformeerde Linked Data model weinig verschil meer is tussen een gegevensgroeptype en een objecttype. Het verschil is alleen zichtbaar doordat een gegevensgroeptype als blank node verbonden is (zie ook Gegevensgroep).

CONSTRUCT {
  ?class a owl:Class.
  ?class mim:equivalent ?gegevensgroeptype.
  ?nodeshape a sh:NodeShape.
  ?nodeshape mim:equivalent ?gegevensgroeptype.
  ?nodeshape sh:targetClass ?class.
}
WHERE {
  ?gegevensgroeptype a mim:Gegevensgroeptype.
  ?gegevensgroeptype mim:naam ?gegevensgroeptypenaam.
  BIND (t:classuri(?gegevensgroeptypenaam) as ?class)
  BIND (t:nodeshapeuri(?gegevensgroeptypenaam) as ?nodeshape)
}
6.4.5.5 Transformatie: Generalisatie

De typering van het hiërarchische verband tussen een meer generiek en een meer specifiek modelelement van hetzelfde soort, waarbij het meer specifieke modelelement eigenschappen van het meer generieke modelelement overerft.

Generalisatie kan gebruikt worden tussen objecttypen, maar ook tussen datatypes. Aangezien zowel objecttypen als datatypen in het RDFS gebaseerde model worden getransformeerd naar een subklasse van rdfs:Class, kan in beide gevallen gebruik worden gemaakt van dezelfde transformatie.

Een mim:Generalisatie wordt vertaald naar een rdfs:subClassOf.

Noot
6.4.5.6 Transformatie: Relatiesoort

De typering van het structurele verband tussen een object van een objecttype en een (ander) object van een ander (of hetzelfde) objecttype.

In het MIM zijn er twee specificatievormen voor relaties: op basis van mim:Relatiesoort of op basis van mim:Relatierol. Indien gekozen wordt voor mim:Relatiesoort dan geldt onderstaande uitwerking. Indien gekozen wordt voor mim:Relatierol, dan geldt de uitwerking zoals beschreven bij Relatierol. De keuze wordt bepaald door de aanwezigheid van het attribuut mim:relatierol.

Een mim:Relatiesoort wordt vertaald naar een sh:PropertyShape in combinatie met een owl:ObjectProperty. De nodekind van de propertyshape is een sh:IRI.

De URI van de propertyshape wordt afgeleid van de naam van het modelelement dat de relatiesoort "bezit" en de naam van de relatiesoort. De URI van de objectproperty wordt afgeleid van de naam van de relatiesoort.

CONSTRUCT {
  ?propertyshape a sh:PropertyShape.
  ?propertyshape sh:path ?objectproperty.
  ?propertyshape sh:nodekind sh:IRI.
  ?propertyshape mim:equivalent ?relatiesoort.
  ?objectproperty a owl:ObjectProperty.
  ?objectproperty mim:equivalent ?relatiesoort.
}
WHERE {
  ?relatiesoort a mim:Relatiesoort.
  ?relatiesoort mim:naam ?relatiesoortnaam.
  ?bezitter mim:bron ?relatiesoort.
  ?bezitter mim:naam ?bezittersnaam
  BIND (t:propertyshapeuri(?bezittersnaam,?relatiesoortnaam) as ?propertyshape)
  BIND (t:propertyuri(?relatiesoortnaam) as ?objectproperty)
  FILTER NOT EXISTS {
    ?relatiesoort mim:relatierol ?rol
  }
}
6.4.5.7 Transformatie: Relatieklasse

Een relatiesoort met eigenschappen.

Een mim:Relatieklasse wordt vertaald naar een subklasse van rdf:Statement, waarbij bovendien ook de transformatieregels voor een mim:Objecttype en een mim:Relatiesoort worden gevolgd.

CONSTRUCT {
  ?class a owl:Class.
  ?class rdfs:subClassOf rdf:Statement.
  ?class mim:equivalent ?relatieklasse.
  ?nodeshape a sh:NodeShape.
  ?nodeshape mim:equivalent ?relatieklasse.
  ?nodeshape sh:targetClass ?class.
  ?nodeshape sh:property [
    sh:path rdf:predicate;
    sh:hasValue ?objectproperty;
    sh:minCount 1;
    sh:maxCount 1;
  ];
  ?nodeshape sh:property [
    sh:path rdf:subject;
    sh:class ?subject;
  ];
  ?nodeshape sh:property [
    sh:path rdf:object;
    sh:class ?object;
  ];
  ?propertyshape a sh:PropertyShape.
  ?propertyshape sh:path ?objectproperty.
  ?propertyshape sh:nodekind sh:IRI.
  ?propertyshape mim:equivalent ?relatieklasse.
  ?objectproperty a owl:ObjectProperty.
  ?objectproperty mim:equivalent ?relatieklasse.
}
WHERE {
  ?relatieklasse a mim:Relatiesoort.
  ?relatieklasse mim:naam ?relatieklassenaam.
  ?relatieklasse mim:bron ?bezitter.
  ?bezitter mim:naam ?bezittersnaam.
  ?bezitter mim:seeAlso ?subject.
  ?relatieklasse mim:doel ?doelklasse.
  ?doelklasse mim:seeAlso ?object.
  BIND (t:classuri(?relatieklassenaam) as ?class)
  BIND (t:nodeshapeuri(?relatieklassenaam) as ?nodeshape)
  BIND (t:propertyshapeuri(?bezittersnaam,?relatieklassenaam) as ?propertyshape)
  BIND (t:propertyuri(?relatieklassenaam) as ?objectproperty)
}
6.4.5.8 Transformatie: Externe koppeling

Een associatie waarmee vanuit het perspectief van het eigen informatiemodel een objecttype uit het 'eigen' informatiemodel gekoppeld wordt aan een objecttype van een extern informatiemodel. De relatie zelf hoort bij het 'eigen' objecttype.

Een externe koppeling wordt op dezelfde wijze omgezet als een mim:Relatiesoort (zie Relatiesoort). Het verschil is zichtbaar doordat de betreffende objecttypes uit verschillende modellen komen. Anders dan bij UML is het daarbij niet gebruikelijk om het andere objecttype "in" het eigen model te plaatsen, maar juist om direct naar het andere objecttype te verwijzen. Eventueel kan daarbij ook nog gebruik worden gemaakt van een owl:imports om expliciet aan te geven dat een ander model wordt gebruikt.

Noot
6.4.5.8.1 Transformatie: Relatierol

In het MIM zijn er twee specificatievormen voor relaties: op basis van mim:Relatiesoort of op basis van mim:Relatierol. Indien gekozen wordt voor mim:Relatierol dan geldt onderstaande uitwerking. Indien gekozen wordt voor mim:Relatiesoort, dan geldt de uitwerking zoals beschreven bij Relatiesoort.

Een mim:Relatiesoort wordt vertaald naar een sh:PropertyShape in combinatie met een owl:ObjectProperty. De nodekind van de propertyshape is een sh:IRI.

De URI van de propertyshape wordt afgeleid van de naam van het modelelement dat de relatierol "bezit" en de naam van de relatierol. De URI van de objectproperty wordt afgeleid van de naam van de relatiesoort. Aangezien er twee relatierollen gedefinieerd kunnen worden, kan ook sprake zijn van twee properties. In dat geval zijn deze twee properties elkaars inverse.

CONSTRUCT {
  ?propertyshape a sh:PropertyShape.
  ?propertyshape sh:path ?objectproperty.
  ?propertyshape sh:nodekind sh:IRI.
  ?propertyshape mim:equivalent ?relatierol.
  ?objectproperty a owl:ObjectProperty.
  ?objectproperty mim:equivalent ?relatierol.
}
WHERE {
  ?relatierol a ?type.
  ?relatierol mim:naam ?relatiesoortnaam.
  ?relatiesoort mim:relatierol ?relatierol.
  ?bezitter mim:bron ?relatiesoort.
  ?bezitter mim:naam ?bezittersnaam
  BIND (t:propertyshapeuri(?bezittersnaam,?relatiesoortnaam) as ?propertyshape)
  BIND (t:propertyuri(?relatiesoortnaam) as ?objectproperty)
  FILTER (?type = mim:RelatierolBron || ?type = mim:RelatierolDoel)
}



CONSTRUCT {
  ?sourceproperty owl:inverseOf ?targetproperty
}
WHERE {
  ?sourceproperty a owl:ObjectProperty.
  ?sourceproperty mim:equivalent ?relatierolbron.
  ?relatierolbron a mim:RelatierolBron.
  ?targetproperty a owl:ObjectProperty.
  ?targetproperty mim:equivalent ?relatieroldoel.
  ?relatieroldoel a mim:RelatierolDoel.
  ?relatiesoort mim:relatierol ?relatierolbron,
                               ?relatieroldoel.
}
6.4.5.9 Transformatie: Referentielijst

Een lijst met een opsomming van de mogelijke domeinwaarden van een attribuutsoort, die buiten het model in een externe waardenlijst worden beheerd. De domeinwaarden in de lijst kunnen in de loop van de tijd aangepast, uitgebreid, of verwijderd worden, zonder dat het informatiemodel aangepast wordt (in tegenstelling tot bij een enumeratie).

Een waardelijst kan verschillende soorten dingen opsommen. Een lijst met waardes, bijv. een opsomming van nummers, maar ook een lijst met concepten, datatypes, of objecten. Het is dan ook niet triviaal om een goede automatische vertaling te bepalen die een waardelijst kan vertalen naar Linked Data.

Het MIM biedt echt aanknopingspunten hoe een waardelijst gemodelleerd dient te worden:

  1. Een enumeratie geeft een opsomming van waarden, waarbij de waarden zelf ook eigenschappen kunnen hebben. Het zijn met andere woorden geen literals, maar resources;
  2. Een referentielijst geeft een opsomming van waarden, waarbij van de waarden specifieke kenmerken worden opgenomen die gespecificeerd zijn middels referentie-elementen. Ook referentiewaarden zijn met andere woorden resources, met specifieke eigenschappen.
  3. Een codelijst is gelijk aan een referentielijst, met dit verschil dat de codelijst zelf niet gespecificeerd is, maar "direct" is overgenomen van een externe partij.

In de Inspire RDF Guidelines wordt voorgeschreven om een enumeratie te modelleren als rdfs:Datatype in plaats van als klasse. Dit leidt tot enumeratiewaardes die een literal zijn, met het datatype van de enumeratie. Bijvoorbeeld "hoog"^^imgolf:NatuurwaardeValue. De reden om hiervan af te wijken is omdat enumeraties vaker waardelijsten zijn die een object of concept modelleren, dan een lijst van letterlijke waardes. Door deze waardes als objecten te modelleren blijft het mogelijk om nieuwe uitdrukkingen te doen over de waardes.

Voor het MIM wordt een waardelijst dan ook vertaald naar een klasse gelijknamig aan de waardelijst (referentielijst, enumeratie of codelijst).

Voor een referentielijst geldt bovendien dat ook nog een sh:NodeShape wordt gedefinieerd, waar de referentie-elementen vervolgens aan gehangen kunnen worden.

CONSTRUCT {
  ?class a owl:Class.
  ?class mim:equivalent ?referentielijst.
  ?nodeshape a sh:NodeShape.
  ?nodeshape mim:equivalent ?referentielijst.
  ?nodeshape sh:targetClass ?class.
}
WHERE {
  ?referentielijst a mim:Referentielijst.
  ?referentielijst mim:naam ?referentielijstnaam.
  BIND (t:classuri(?referentielijstnaam) as ?class)
  BIND (t:nodeshapeuri(?referentielijstnaam) as ?nodeshape)
}
6.4.5.10 Transformatie: Referentie element

Een eigenschap van een object in een referentielijst in de vorm van een gegeven.

Een mim:ReferentieElement wordt op dezelfde wijze omgezet als een mim:Attribuutsoort, waarbij de referentielijst de "bezitter" is van het referentie element. De relatie tussen de referentielijst en het referentie element wordt direct meegenomen in de transformatie.

De URI van de propertyshape wordt afgeleid van de naam van de referentielijst dat het referentie element "bezit" en de naam van het referentie element. De URI van de datatypeproperty wordt ook op die manier afgeleid. Dit in afwijking van de wijze waarop dit bij een attribuutsoort gebeurt. Reden is het feit dat een referentie element echt uniek bij een gestructureerd datatype hoort, conform het metamodel (er is sprake van een compositie-aggregatie). Dit is weer vergelijkbaar met de situatie bij mim:datatElement.

CONSTRUCT {
  ?nodeshape sh:property ?propertyshape.
  ?propertyshape a sh:PropertyShape.
  ?propertyshape sh:path ?datatypeproperty.
  ?propertyshape sh:nodekind sh:Literal.
  ?propertyshape mim:equivalent ?referentielement.
  ?datatypeproperty a owl:DatatypeProperty.
  ?datatypeproperty mim:equivalent ?referentielement.
}
WHERE {
  ?referentielement a mim:ReferentieElement.
  ?referentielement mim:naam ?referentielementnaam.
  ?bezitter mim:element ?referentielement.
  ?bezitter mim:naam ?bezittersnaam
  BIND (t:nodeshapeuri(?bezittersnaam) as ?nodeshape)
  BIND (t:propertyshapeuri(?bezittersnaam,?referentieelementnaam) as ?propertyshape)
  BIND (t:nodepropertyuri(?referentieelementnaam) as ?datatypeproperty)
}
6.4.5.11 Transformatie: Enumeratie

Een datatype waarvan de mogelijke waarden limitatief zijn opgesomd in een statische lijst.

Een mim:Enumeratie wordt vertaald naar een owl:Class in combinatie met een sh:Nodeshape, skos:ConceptScheme en enkele sh:PropertyShapes, waarbij de betreffende klasse een rdfs:subClassOf skos:Concept is.

De reden om deze vertaling te maken, is dat in het MIM een enumeratie onderdeel is van het eigen model, en zeer specifieke eigenschappen kent. Het is expliciet geen "normale" klasse (daarvoor lenen mim:Objecttype of mim:Referentielijst zich meer). Maar het is ook geen enkele opsomming van enkelvoudige waarden.

De waarden van een enumeratie zijn voorkomens van deze klasse en onderdeel van het skos:ConceptScheme dat aan deze enumeratie zit.

CONSTRUCT {
  ?class a owl:Class.
  ?class rdfs:subClassOf skos:Concept.
  ?class mim:equivalent ?enumeratie.
  ?nodeshape a sh:NodeShape.
  ?nodeshape mim:equivalent ?enumeratie.
  ?nodeshape sh:targetClass ?class.
  ?nodeshape sh:property [
    sh:path rdfs:label;
  ].
  ?nodeshape sh:property [
    sh:path skos:notation;
  ].
  ?nodeshape sh:property [
    sh:path skos:definition
  ].
  ?nodeshape sh:property [
    sh:path rdf:type;
    sh:hasValue ?class
  ].
  ?nodeshape sh:property [
    sh:path skos:inScheme;
    sh:hasValue ?scheme
  ]
}
WHERE {
  ?enumeratie a mim:Enumeratie.
  ?objecttype mim:naam ?enumeratienaam.
  BIND (t:classuri(?enumeratienaam) as ?class)
  BIND (t:nodeshapeuri(?enumeratienaam) as ?nodeshape)
  BIND (t:schemeuri(?enumeratienaam) as ?scheme)
}
6.4.5.12 Transformatie: Enumeratiewaarde

Een gedefinieerde waarde, in de vorm van een eenmalig vastgesteld constant gegeven.

Enumeratiewaarden worden vertaald naar voorkomens van de klasse die bepaald wordt door de Enumeratie zelf. Voor de URI wordt het metagegeven mim:code gebruikt, tenzij deze niet aanwezig is.

CONSTRUCT {
  ?concept a ?class.
  ?concept skos:inScheme ?scheme.
  ?concept mim:equivalent ?waarde.
}
WHERE {
  ?waarde a mim:Enumeratiewaarde.
  ?enumeratie mim:waarde ?waarde.
  ?class mim:equivalent ?enumeratie.
  ?class a owl:Class.
  ?scheme mim:equivalent ?enumeratie.
  ?scheme a skos:ConceptScheme.
  {
    {
      ?waarde mim:naam ?notation
      FILTER NOT EXISTS {?waarde mim:code ?nocode}
    }
    UNION
    {
      ?waarde mim:code ?notation
    }
  }
  BIND (t:concepturi(?notation) as ?concept)
}
6.4.5.13 Transformatie: Codelijst

Een referentielijst die extern wordt beheerd, en geen onderdeel is van het informatiemodel.

Een mim:Codelijst wordt op dezelfde wijze getransformeerd als een mim:Referentielijst.

CONSTRUCT {
  ?class a owl:Class.
  ?class mim:equivalent ?codelijst.
  ?nodeshape a sh:NodeShape.
  ?nodeshape mim:equivalent ?codelijst.
  ?nodeshape sh:targetClass ?class.
}
WHERE {
  ?codelijst a mim:Codelijst.
  ?codelijst mim:naam ?codelijstnaam.
  BIND (t:classuri(?codelijstnaam) as ?class)
  BIND (t:nodeshapeuri(?codelijstnaam) as ?nodeshape)
}

6.4.6 Datatypen

6.4.6.1 Transformatie: Primitief datatype

Een in het eigen model gedefinieerd primitieve datatype. Deze worden wel door de modelleur gecreëerd, met een eigen naam en een eigen definitie (en eigen metagegevens).

Een primitief datatype wordt vertaald naar een rdfs:Datatype. Indien er geen subklasse aanwezig is naar een andere datatype, dan wordt per default een subklasse van xsd:string toegevoegd.

CONSTRUCT {
  ?datatype a rdfs:Datatype.
  ?datatype rdfs:subClassOf xsd:string.
  ?datatype mim:equivalent ?primitiefdatatype.
}
WHERE {
  ?primitiefdatatype a mim:PrimitiefDatatype.
  ?primitiefdatatype mim:naam ?primitiefdatatypenaam.
  FILTER NOT EXISTS {
    ?generalisatie mim:subtype ?primitiefdatatype
  }
  BIND (t:classuri(?primitiefdatatypenaam) as ?datatype)
}



CONSTRUCT {
  ?datatype a rdfs:Datatype.
  ?datatype mim:equivalent ?primitiefdatatype.
}
WHERE {
  ?primitiefdatatype a mim:PrimitiefDatatype.
  ?primitiefdatatype mim:naam ?primitiefdatatypenaam.
  ?generalisatie mim:subtype ?primitiefdatatype
  BIND (t:classuri(?primitiefdatatypenaam) as ?datatype)
}
6.4.6.2 Transformatie: Primitief datatype - standaard datatypen

Voor standaard datatypen maakt RDF gebruik van de XSD datatypen. Onderstaande tabel geeft de mapping weer vanuit de datatypen die in het MIM zijn gespecificeerd.

MIM datatype XSD Datatype
mim:CharacterString xsd:string
mim:Integer xsd:integer
mim:Real xsd:float
mim:Decimal xsd:decimal
mim:Boolean xsd:boolean
mim:Date xsd:date
mim:DateTime xsd:dateTime
mim:Year xsd:gYear
mim:Day xsd:gDay
mim:Month xsd:gMonth
mim:URI xsd:anyURI

Deze vertaaltabel kan worden doorgevoerd via mim:equivalent statements, aangezien deze vervolgens gebruikt wordt in de transformatieregel voor generalisatie en in de transformatieregel voor het aspect mim:type.

CONSTRUCT {
  mim:CharacterString a mim:PrimitiefDatatype.
  mim:Integer a mim:PrimitiefDatatype.
  mim:Real a mim:PrimitiefDatatype.
  mim:Decimal a mim:PrimitiefDatatype.
  mim:Boolean a mim:PrimitiefDatatype.
  mim:Date a mim:PrimitiefDatatype.
  mim:DateTime a mim:PrimitiefDatatype.
  mim:Year a mim:PrimitiefDatatype.
  mim:Day a mim:PrimitiefDatatype.
  mim:Month a mim:PrimitiefDatatype.
  mim:URI a mim:PrimitiefDatatype.
  xsd:string mim:equivalent mim:CharacterString.
  xsd:integer mim:equivalent mim:Integer.
  xsd:float mim:equivalent mim:Real.
  xsd:decimal mim:equivalent mim:Decimal.
  xsd:boolean mim:equivalent mim:Boolean.
  xsd:date mim:equivalent mim:Date.
  xsd:dateTime mim:equivalent mim:DateTime.
  xsd:gYear mim:equivalent mim:Year.
  xsd:gDay mim:equivalent mim:Day.
  xsd:gMonth mim:equivalent mim:Month.
  xsd:anyURI mim:equivalent mim:URI.
}
WHERE {}
6.4.6.3 Transformatie: Gestructureerd datatype

Specifiek benoemd gestructureerd datatype dat de structuur van een gegeven beschrijft, samengesteld uit minimaal twee elementen.

Een mim:GestructureerdDatatype wordt vertaald naar een sh:NodeShape. Er wordt geen sh:Class aangemaakt zoals bij een mim:Objecttype, aangezien conform het MIM een gestructureerd datatype slechts een structuur schetst en geen semantiek.

CONSTRUCT {
  ?nodeshape a sh:NodeShape.
  ?nodeshape mim:equivalent ?gestructureerddatatype.
}
WHERE {
  ?gestructureerddatatype a mim:GestructureerdDatatype.
  ?gestructureerddatatype mim:naam ?gestructureerddatatypenaam.
  BIND (t:nodeshapeuri(?gestructureerddatatypenaam) as ?nodeshape)
}
6.4.6.4 Transformatie: Data element

Een onderdeel/element van een Gestructureerd datatype die als type een datatype heeft.

Een mim:DataElement wordt op dezelfde wijze omgezet als een mim:Attribuutsoort, waarbij het gestructureerd datatype de "bezitter" is van het data element. De relatie tussen het gestructureerd datatype en het data element wordt direct meegenomen in de transformatie.

De URI van de propertyshape wordt afgeleid van de naam van het gestructureerde datatype dat het data element "bezit" en de naam van het data element. De URI van de datatypeproperty wordt ook op die manier afgeleid. Dit in afwijking van de wijze waarop dit bij een attribuutsoort gebeurt. Reden is het feit dat een data element echt uniek bij een gestructureerd datatype hoort, conform het metamodel (er is sprake van een compositie-aggregatie).

CONSTRUCT {
  ?nodeshape sh:property ?propertyshape.
  ?propertyshape a sh:PropertyShape.
  ?propertyshape sh:path ?datatypeproperty.
  ?propertyshape sh:nodekind sh:Literal.
  ?propertyshape mim:equivalent ?dataelement.
  ?datatypeproperty a owl:DatatypeProperty.
  ?datatypeproperty mim:equivalent ?dataelement.
}
WHERE {
  ?dataelement a mim:DataElement.
  ?dataelement mim:naam ?dataelementnaam.
  ?bezitter mim:element ?dataelement.
  ?bezitter mim:naam ?bezittersnaam
  BIND (t:nodeshapeuri(?bezittersnaam) as ?nodeshape)
  BIND (t:propertyshapeuri(?bezittersnaam,?dataelementnaam) as ?propertyshape)
  BIND (t:nodepropertyuri(?dataelementnaam) as ?datatypeproperty)
}
6.4.6.5 Transformatie: Keuze

Een opsomming van meerdere modelelementen, waarbij er maar van één tegelijkertijd sprake kan zijn.

Een keuze tussen modelelementen wordt gemodelleerd als een speciaal soort NodeShape die zelf een sh:xone eigenschap heeft. Deze eigenschap verwijst naar een rdf:List waarin de opsomming van de keuze staat uitgewerkt.

CONSTRUCT {
  ?shape a sh:NodeShape.
  ?shape sh:xone ?list.
  ?shape mim:equivalent ?keuze.
  ?list a rdf:List.
  ?list rdf:rest rdf:nil.
}
WHERE {
  ?keuze a ?type.
  FILTER (?type = mim:Keuze || ?type = mim:Keuzeconstraint)
  ?keuze mim:naam ?keuzenaam.
  ?keuze ?keuzerelatie ?keuzewaarde.
  BIND (t:nodeshapeuri(?keuzenaam) as ?shape)
}

Voor het toevoegen van de waarden in de lijst wordt, anders dan andere voorbeelden, geen CONSTRUCT query gebruikt, omdat de lijst recursief wordt opgebouwd, in combinaties van DELETE en INSERT queries. Nieuwe elementen worden aan het begin van de lijst toegevoegd (er wordt geen volgorde verondersteld, zie ook het algemene issue over volgorde bovenaan). Het union element wordt zelf als blank node toegevoegd.

Onderstaand voorbeeld geeft aan hoe de conversie uiteindelijk plaatsvindt:

ex:GeometrischObject a mim:Objecttype;
mim:naam "Geometrisch object";
mim:attribuut ex:geometrie;
.
ex:geometrie a mim:Attribuutsoort;
mim:naam "geometrie";
mim:type ex:LineOrPolygon;
.
ex:LineOrPolygon a mim:Keuze;
mim:naam "Line or polygon";
mim:type ex:Line;
mim:type ex:Polygon;
.
ex:Line a mim:PrimitiefDatatype;
mim:naam "Line";
mim:type gml:Line;
.
ex:Polygon a mim:PrimitiefDatatype;
mim:naam "Polygon";
mim:type gml:Polygon;
.

shape:GeometrischObject-geometrie a sh:PropertyShape; rdfs:label "geometrie"; mim:equivalent ex:geometrie; sh:node shape:LineOrPolygon; . shape:LineOrPolygon a sh:NodeShape; rdfs:label "Line or polygon"; mim:equivalent ex:LineOrPolygon; sh:xone ( [sh:datatype gml:Line ] [sh:datatype gml:Polygon ] ) .

De query hiervoor is als volgt:

DELETE {
  ?endoflist rdf:rest rdf:nil
}
INSERT {
  ?list rdf:first [ mim:equivalent ?keuzeelement ];
  ?list rdf:rest ?endoflist.
}
WHERE {
  ?keuze a mim:Keuze.
  ?keuze ?keuzerelatie ?keuzelement.
  ?list mim:equivalent ?keuze.
  ?list rdf:rest* ?endoflist.
  ?endoflist rdf:rest rdf:nil.
}

DELETE {
  ?endoflist rdf:rest rdf:nil.
  ?realendoflist rdf:rest ?endoflist.
}
INSERT {
  ?realendoflist rdf:rest rdf:nil
}
WHERE {
  ?list a rdf:List.
  ?list rdf:rest* ?realendoflist.
  ?realendoflist rdf:rest ?endoflist.
  ?endoflist rdf:rest rdf:nil.
}

De tweede delete-insert query is een "opruimquery": aangezien we zijn begonnen met een rdf:List in plaats van een rdf:nil, moeten we het einde van de lijst er nog weer afknippen.

6.4.7 Packages

Een package is een benoemde en begrensde verzameling/groepering van modelelementen.

6.4.7.1 Transformatie: Domein

Het eigen IM.

Een mim:Domein wordt omgezet naar een owl:Ontology, waarbij de naam en locatie eigenschappen worden gebruikt om de URI tot stand te brengen.

6.4.7.2 Transformatie: Extern

Een groepering van constructies die een externe instantie beheert en beschikbaar stelt aan een informatiemodel en die in het informatiemodel ongewijzigd gebruikt worden.

Een mim:Extern wordt omgezet naar een owl:Ontology, waarbij de naam en locatie eigenschappen worden gebruikt om de URI tot stand te brengen. Bovendien wordt een owl:imports aangelegd tussen de package van het type mim:Domein en deze externe package.

De gedachte hierachter, is dat een externe package letterlijk is overgenomen vanuit een extern model, en hier aanvullend is meegenomen. Feitelijk zal de inhoud dus identiek moeten zijn aan het model op de betreffende externe locatie.

6.4.7.3 Transformatie: View

Een groepering van objecttypen die gespecificeerd zijn in een extern informatiemodel en vanuit het perspectief van het eigen informatiemodel inzicht geeft welke gegevens van deze objecttypen relevant zijn binnen het eigen informatiemodel.

Een mim:View wordt omgezet naar een owl:Ontology, waarbij de naam wordt gebruikt om de URI tot stand te brengen. Daarbij geldt dat voor de locatie, de locatie wordt overgenomen uit de package van het type mim:Domein. Bovendien wordt een owl:imports relatie gelegd tussen de package van het type domein en deze view-package, EN er wordt een owl:imports gelegd van de view-package naar een externe locatie, op basis van de locatie bij deze view package.

De gedachte hieracter, is dat een view package deels is overgenomen vanuit een extern model. Er zijn aanpassingen gedaan aan de structuur, maar niet aan de betekenis. Dit betekent dat er een "imports" relatie loopt van de domein-package naar de view-package, en vervolgens vanuit de view-package naar de externe package (die hier verder niet is opgenomen).

Deze constructie heeft ook consequenties voor de URI's van de modelelementen in deze view package. URI's van shapes (Nodeshapes en Propertyshapes) krijgen als namespace de locatie van de domein-package (dit gaat immers om de structuur en is lokaal gedefinieerd in relatie tot de domein-package). URI's van classes en properties krijgen als namespace de locatie van de view package, waarbij -net als bij mim:Extern dit de namespace zal zijn van het externe model.

6.4.8 Overig

6.4.8.1 Transformatie: Constraint

Een constraint is een conditie of een beperking, die over een of meerdere modelelementen uit het informatiemodel geldt.

Een constraint (en bijbehorende gegevens) worden direct overgenomen in het vertaalde model als blank node. Het MIM kent voor een constraint twee aspecten: tekstueel en formeel. Het MIM doet daarbij geen uitspraak over de taal die voor het formele model moet worden gehanteerd. Daarmee is een transformatie niet op zijn plaats. Zie ook de INSPIRE RDF Guidelines waar een vergelijkbare redenatie wordt gevolgd.

CONSTRUCT {
  ?subject mim:constraint ?constraint.
  ?constraint ?prop ?obj.
}
WHERE {
  ?modelelement mim:constraint ?constraint.
  ?subject mim:equivalent ?modelelement.
  ?constraint ?prop ?obj.
}

6.4.9 Properties

6.4.9.1 transformatie: naam

De naam van een modelelement

Een mim:naam wordt vertaald naar een rdfs:label.

Noot
Noot
CONSTRUCT {
  ?subject rdfs:label ?naam
}
WHERE {
  ?modelelement mim:naam ?naam.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.2 transformatie: alias

De alternatieve weergave van de naam.

Een mim:alias wordt vertaald naar een skos:altLabel

Noot
CONSTRUCT {
  ?subject skos:altLabel ?alias
}
WHERE {
  ?modelelement mim:alias ?alias.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.3 transformatie: begrip

Verwijzing naar een begrip, vanuit een modelelement, waarmee wordt aangegeven op welk begrip, of begrippen, het informatiemodel element is gebaseerd.

Een mim:begrip wordt vertaald naar een dct:subject

CONSTRUCT {
  ?subject dct:subject ?begrip
}
WHERE {
  ?modelelement mim:begrip ?begrip.
  ?subject mim:equivalent ?modelelement
}
6.4.9.4 transformatie: begripsterm

Verwijzing naar een begrip in de vorm van de term, vanuit een modelelement, waarmee wordt aangegeven op welk begrip, of begrippen, het informatiemodel element is gebaseerd.

Een mim:begripsterm wordt één op één overgenomen. Het heeft de voorkeur om geen gebruik te maken van dit aspect, maar om gebruik te maken van het aspect mim:begrip, waarmee een directe verwijzing kan worden gemaakt naar het begrip zelf.

CONSTRUCT {
  ?subject mim:begripsterm ?begripsterm
}
WHERE {
  ?modelelement mim:begripsterm ?begripsterm.
  ?subject mim:equivalent ?modelelement
}
6.4.9.5 transformatie: definitie

De beschrijving van de betekenis van dit modelelement.

Een mim:definitie wordt vertaald naar een rdfs:comment

Rationale om niet te kiezen voor skos:definition: in de meeste Linked Data vocabulaires is het gebruikelijk om de beschrijving van een klasse op te nemen door middel van een rdfs:comment, wat ook de intentie is in het MIM. Het MIM is niet beoogd als een volledig begrippenkader. Het MIM biedt daarnaast de mogelijkheid om expliciet te verwijzen vanuit een modelelement naar een skos:Concept. Het ligt dan ook voor de hand om bij dit skos:Concept de werkelijke skos:definition op te nemen.

6.4.9.6 transformatie: toelichting

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

Een mim:toelichting wordt direct, zonder aanpassing, overgenomen in het vertaalde model.

Aanbevolen wordt om geen gebruik te maken van mim:toelichting, maar gebruik te maken van de verwijzing naar expliciet gedefinieerde begrippen, waarbij de toelichting bij het begrip zelf wordt opgenomen.

CONSTRUCT {
  ?subject mim:toelichting ?toelichting
}
WHERE {
  ?modelelement mim:toelichting ?toelichting.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.7 transformatie: herkomst

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

Een mim:herkomst wordt direct, zonder aanpassing, overgenomen in het vertaalde model.

CONSTRUCT {
  ?subject mim:herkomst ?herkomst
}
WHERE {
  ?modelelement mim:herkomst ?herkomst.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.8 transformatie: herkomst definitie

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

Een mim:herkomstDefinitie wordt direct, zonder aanpassing, overgenomen in het vertaalde model.

Aanbevolen wordt om geen gebruik te maken van mim:herkomstDefinitie, maar gebruik te maken van de verwijzing naar expliciet gedefinieerde begrippen, waarbij de herkomst van de definitie bij het begrip zelf wordt opgenomen.

CONSTRUCT {
  ?subject mim:herkomstDefinitie ?herkomstdefinitie
}
WHERE {
  ?modelelement mim:herkomstDefinitie ?herkomstdefinitie.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.9 transformatie: datum opname

De datum waarop het modelelement is opgenomen in het informatiemodel.

Een mim:datumOpname wordt direct, zonder aanpassing, overgenomen in het vertaalde model.

CONSTRUCT {
  ?subject mim:datumOpname ?datumopname
}
WHERE {
  ?modelelement mim:datumOpname ?datumopname.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.10 transformatie: indicatie materiële historie

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

Een mim:indicatieMaterieleHistorie wordt direct, zonder aanpassing, overgenomen in het vertaalde model.

CONSTRUCT {
  ?subject mim:indicatieMaterieleHistorie ?indicatiematerielehistorie
}
WHERE {
  ?modelelement mim:indicatieMaterieleHistorie ?indicatiematerielehistorie.
  ?subject mim:equivalent ?modelelement.
}
Noot
6.4.9.11 transformatie: indicatie formele historie

Indicatie of de formele historie van het kenmerk van het object bijgehouden wordt en te bevragen is.

Een mim:indicatieFormeleHistorie wordt direct, zonder aanpassing, overgenomen in het vertaalde model.

CONSTRUCT {
  ?subject mim:indicatieFormeleHistorie ?indicatieformelehistorie
}
WHERE {
  ?modelelement mim:indicatieFormeleHistorie ?indicatieformelehistorie.
  ?subject mim:equivalent ?modelelement.
}
Noot
6.4.9.12 transformatie: kardinaliteit

De mim:kardinaliteit wordt vertaald naar sh:minCount en sh:maxCount. Daarbij wordt de volgende tabel gebruikt om de string-waarde van mim:kardinaliteit om te zetten. Een - betekent dat de betreffende triple niet wordt opgenomen in het model.

Daarnaast wordt min:kardinaliteit ook direct overgenomen in het vertaalde model. De reden hiervoor is tweeledig. Enerzijds maakt het daarmee eenvoudiger om de originele kardinaliteit weer te geven. Voor niet-SHACL experts kan het verwarrend zijn dat het ontbreken van zowel sh:minCount als sh:maxCount betekent dat sprake is van een 0..* kardinaliteit. Anderzijds maakt het de terugvertaling in geval van een min:mogelijkGeenWaarde mogelijk, aangezien dit veld invloed kan hebben op de sh:minCount (zie ook mogelijk-geen-waarde).

mim:kardinaliteit sh:minCount sh:maxCount
1 1 1
* - -
0..1 - 1
0..* - -
1..1 1 1
1..* 1 -
a..z a z

In de laatste regel moet voor a en z een geheel getal vanaf 1 worden gelezen.

CONSTRUCT {
  ?propertyshape sh:minCount ?mincount.
}
WHERE {
  ?modelelement mim:kardinaliteit ?kardinaliteit.
  ?modelelement mim:mogelijkGeenWaarde ?mogelijkgeenwaarde.
  ?propertyshape mim:equivalent ?modelelement.
  BIND (t:mincount(?kardinaliteit) as ?mincount)
  FILTER(NOT(?mogelijkgeenwaarde))
}



CONSTRUCT {
  ?propertyshape sh:maxCount ?maxcount.
}
WHERE {
  ?modelelement mim:kardinaliteit ?kardinaliteit.
  ?propertyshape mim:equivalent ?modelelement.
  BIND (t:maxcount(?kardinaliteit) as ?maxcount)
}
6.4.9.13 transformatie: authentiek

Aanduiding of het kenmerk een authentiek gegeven betreft.

Een mim:authentiek wordt direct, zonder aanpassing, overgenomen in het vertaalde model.

CONSTRUCT {
  ?subject mim:authentiek ?authentiek
}
WHERE {
  ?modelelement mim:authentiek ?authentiek.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.14 transformatie: indicatie afleidbaar

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

Een mim:indicatieAfleidbaar wordt direct, zonder aanpassing, overgenomen in het vertaalde model.

CONSTRUCT {
  ?subject mim:indicatieAfleidbaar ?indicatieafleidbaar
}
WHERE {
  ?modelelement mim:indicatieAfleidbaar ?indicatieafleidbaar.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.15 transformatie: mogelijk geen waarde

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

Een mim:mogelijkGeenWaarde wordt direct, zonder aanpassing, overgenomen in het vertaalde model, waarbij in een enkel geval een aanpassing wordt gedaan aan de manier waarop mim:kardinaliteit wordt getransformeerd.

Linked Data gaat in beginsel uit van een "open word assumptie". Dit houdt onder andere in dat Linked Data er van uitgaat dat elk aspect mogelijk geen waarde kan hebben. Met SHACL kan deze assumptie worden beperkt. Zo zal bij een verplicht veld (zoals kardinaliteit 1..* of 1..1) daadwerkelijk ook een waarde aanwezig moeten zijn. Het MIM gaat in beginsel uit van een "closed world assumptie", het veld mim:mogelijkGeenWaarde is juist bedoeld om deze assumptie te verruimen. Doordat het veld mim:mogelijkGeenWaarde altijd een waarde heeft ("Ja" of "Nee"), kan het veld ook worden gelezen als als de waarde in de werkelijkheid bestaat, dan is deze ook aanwezig. Dit maakt dat het veld mim:mogelijkGeenWaarde feitelijk in de context van Linked Data het model in vele gevallen een gesloten model maakt, vandaar ook het gebruik van SHACL waarmee we deze beperkingen kunnen opleggen. Indien sprake is van een "mogelijk geen waarde" dan is het wel noodzakelijk om de transformatieregel voor mim:kardinaliteit aan te passen, conform onderstaande tabel:

mim:mogelijkGeenWaarde mim:kardinaliteit Aanpassing
Nee 0..x geen
Nee 1..x geen
Ja 0..x geen
Ja 1..x sh:minCount verwijderd
Ja n..x (met n>1) sh:minCount verwijderd

"sh:minCount verwijderd" houdt in dat de kardinaliteit 0..x wordt. Deze aanpassing is opgenomen in de transformatieregel van kardinaliteit.

Zie ook het NEN3610 Linked Data Profiel 7.3.4.2.3 Attribuut met stereotype «voidable» voor meer achtergrondinformatie.

CONSTRUCT {
  ?subject mim:mogelijkGeenWaarde ?mogelijkgeenwaarde
}
WHERE {
  ?modelelement mim:mogelijkGeenWaarde ?mogelijkgeenwaarde.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.16 transformatie: locatie

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

Een mim:locatie wordt direct, zonder aanpassing, overgenomen in het vertaalde model. Daarnaast wordt dit veld gebruikt bij het munten van de URI's van de verschillende modelelementen en het achterhalen van de inhoud van een waardenlijst.

6.4.9.17 transformatie: type

Het datatype waarmee waarden van deze attribuutsoort worden vastgelegd.

De vertaling van een mim:type hangt af van de vertaling van het datatype waar naar wordt verwezen:

  • Voor primitieve datatypes wordt vertaald naar een sh:datatype;
  • Voor gestructureerde datatypes wordt vertaald naar een sh:node;
  • Voor een enumeratie wordt vertaald naar een sh:node;
  • Voor een referentielijst wordt vertaald naar een sh:node;
  • Voor een codelijst wordt vertaald naar een sh:node;
  • Voor een union wordt de vertaling opgepakt bij de transformatieregel van union zelf (zie ook Union)
  • In geval van zelfgespecificeerde datatypen wordt vertaald conform het betreffende supertype.
CONSTRUCT {
  ?subject sh:datatype ?datatype
}
WHERE {
  ?modelelement mim:type ?type.
  ?type rdfs:subClassOf*/rdf:type mim:PrimitiefDatatype.
  ?subject mim:equivalent ?modelelement.
  ?datatype mim:equivalent ?type.
}



CONSTRUCT {
  ?subject sh:node ?datatype
}
WHERE {
  ?modelelement mim:type ?type.
  ?type rdfs:subClassOf*/rdf:type ?mimtype.
  ?subject mim:equivalent ?modelelement.
  ?subject a sh:NodeShape.
  ?datatype mim:equivalent ?type.
  FILTER (?mimtype = mim:GestructureerdDatatype
       || ?mimtype = mim:Enumeratie
       || ?mimtype = mim:Referentielijst
       || ?mimtype = mim:Codelijst
  )
}
6.4.9.18 transformatie: lengte

De aanduiding van de lengte van een gegeven.

Een mim:lengte wordt vertaald naar een sh:maxLength.

CONSTRUCT {
  ?subject sh:maxLength ?lengte
}
WHERE {
  ?modelelement mim:lengte ?lengte.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.19 transformatie: patroon

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

De structuur van mim:patroon is in woorden beschreven. Deze wordt direct, zonder aanpassing, overgenomen in het vertaalde model.

CONSTRUCT {
  ?subject mim:patroon ?patroon
}
WHERE {
  ?modelelement mim:patroon ?patroon.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.20 transformatie: formeel patroon

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

mim:formeelPatroon wordt beschreven met sh:pattern.

Noot
CONSTRUCT {
  ?subject sh:pattern ?formeelpatroon
}
WHERE {
  ?modelelement mim:formeelPatroon ?formeelpatroon.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.21 transformatie: unieke aanduiding

Voor objecttypen die deel uitmaken van een (basis)registratie of informatiemodel betreft dit de wijze waarop daarin voorkomende objecten (van dit type) uniek in de registratie worden aangeduid.

Een mim:uniekeAanduiding wordt direct, zonder aanpassing, overgenomen in het vertaalde model.

CONSTRUCT {
  ?subject mim:uniekeAanduiding ?uniekeaanduiding
}
WHERE {
  ?modelelement mim:uniekeAanduiding ?uniekeaanduiding.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.22 transformatie: populatie

Voor objecttypen die deel uitmaken van een (basis)registratie betreft dit de beschrijving van de exemplaren van het gedefinieerde objecttype die in de desbetreffende (basis)­registratie voorhanden zijn.

Een mim:populatie wordt direct, zonder aanpassing, overgenomen in het vertaalde model.

CONSTRUCT {
  ?subject mim:populatie ?populatie
}
WHERE {
  ?modelelement mim:populatie ?populatie.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.23 transformatie: kwaliteit

Beschrijving van de mate waarin in de registratie opgenomen objecten van het desbetreffende type volledig, juist, actueel, nauwkeurig en betrouwbaar zijn.

Een mim:kwaliteit wordt direct, zonder aanpassing, overgenomen in het vertaalde model.

CONSTRUCT {
  ?subject mim:kwaliteit ?kwaliteit
}
WHERE {
  ?modelelement mim:kwaliteit ?kwaliteit.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.24 transformatie: indicatie abstract object

Indicatie dat het objecttype een generalisatie is, waarvan een object als specialisatie altijd voorkomt in de hoedanigheid van een (en slechts één) van de specialisaties van het betreffende objecttype.

In een MIM conform informatiemodel kunnen zowel abstracte als concrete klassen voorkomen. In UML kun je daarvan afleiden dat je geen instanties mag hebben van abstracte klassen, maar alleen van concrete klassen. In RDF wordt geen onderscheid gemaakt tussen het abstract of concreet zijn van klassen. In RDF worden klassen beschouwd als sets van dingen. Als je een set kunt beschrijven, dan kunnen er ook dingen zijn die tot die set behoren.

Wel kun je aangeven dat indien er sprake is van een triple <subject>rdf:type <abstract-class> er minimaal óók een tweede triple moet zijn <subject>rdf:type <non-abstract-class>

Een mim:indicatieAbstractObject wordt aanvullend direct, zonder aanpassing, overgenomen in het vertaalde model.

CONSTRUCT {
  ?subject mim:indicatieAbstractObject ?indicatieabstractobject.
  ?subject sh:propertyShape [
    sh:path rdf:type;
    sh:minCount 2
  ]
}
WHERE {
  ?modelelement mim:indicatieAbstractObject ?indicatieabstractobject.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.25 transformatie: identificerend

Een kenmerk van een objecttype die aangeeft of deze eigenschap uniek identificerend is voor alle objecten in de populatie van objecten van dit objecttype.

Een mim:identificerend wordt direct, zonder aanpassing, overgenomen in het vertaalde model.

CONSTRUCT {
  ?subject mim:identificerend ?identificerend
}
WHERE {
  ?modelelement mim:identificerend ?identificerend.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.26 transformatie: gegevensgroeptype (eigenschap)

De verwijzing naar het bijbehorende gegevensgroeptype.

Een mim:gegevensgroeptype wordt vertaald naar een sh:class met als waarde de URI van de class die het bijbehorende gegevensgroeptype representeert. Zie Gegevensgroep en Gegevensgroeptype voor meer uitleg.

CONSTRUCT {
  ?subject sh:class ?object
}
WHERE {
  ?modelelement mim:gegevensgroeptype ?gegevensgroeptype.
  ?subject mim:equivalent ?modelelement.
  ?subject a sh:NodeShape.
  ?object mim:equivalent ?gegevensgroeptype.
  ?object a owl:Class.
}
6.4.9.27 transformatie: unidirectioneel

In Linked Data is een relatiesoort feitelijk automatisch unidirectioneel, tenzij aanvullende maatregelen worden genomen waardoor de relatiesoort vanuit twee kanten kan worden bekeken. Dit betekent dat de vertaling van unidirectioneel juist wordt opgepakt op het moment dat niet sprake is van unidirectioneel (de waarde van het metakenmerk is false).

Indien sprake is van geen unidirectionaliteit, dan wordt een owl:inverseOf relatie gelegd tussen de relatierol die aan de bron-kant van de relatiesoort ligt en de relatierol die aan de doel-kant van de relatiesoort ligt. Merk op dat "unidirectioneel" alleen betekenis heeft als zowel de doel als bron kant van de relatiesoort zijn beschreven als relatierollen. Anders is de relatiesoort per definitie unidirectioneel vanuit het perspectief van Linked Data.

CONSTRUCT {
  ?doel sh:inverseOf ?bron.
  ?bron sh:inverseOf ?doel.
}
WHERE {
  ?relatiesoort mim:relatierol ?relatierolbron.
  ?relatiesoort mim:relatierol ?relatieroldoel.
  ?relatiesoort mim:unidirectioneel false .
  ?relatierolbron a mim:RelatierolDoel.
  ?relatieroldoel a mim:RelatierolDoel.
  ?doel mim:equivalent ?relatieroldoel.
  ?bron mim:equivalent ?relatierolbron.
}
6.4.9.28 transformatie: bron

Aanduiding van het bronobject in een relatie tussen objecten. Een bronoject heeft middels een relatiesoort een relatie met een doelobject.

Een mim:bron wordt vertaald naar een sh:property die hoort bij de de NodeShape van het objecttype. Zie voor meer informatie over hoe relaties tussen objecttypen worden vertaald de paragrafen Relatiesoort en Externe koppeling.

CONSTRUCT {
  ?objecttype sh:property ?modelelement
}
WHERE {
  ?modelelement mim:bron ?objecttype.
  ?subject mim:equivalent ?modelelement.
  ?object mim:equivalent ?objecttype.
}
6.4.9.29 transformatie: doel

Aanduiding van het gerelateerde objecttype die het eindpunt van de relatie aangeeft. Naar objecten van dit objecttype wordt verwezen.

Een mim:doel wordt vertaald naar een sh:class met als waarde de URI van de Class die het gerelateerde objecttype representeert. Zie voor meer informatie over hoe relaties tussen objecttypen worden vertaald de paragrafen Relatiesoort en Externe koppeling.

CONSTRUCT {
  ?subject sh:class ?object
}
WHERE {
  ?modelelement mim:doel ?gerelateerdobjecttype.
  ?subject mim:equivalent ?modelelement.
  ?object mim:equivalent ?gerelateerdobjecttype.
}
6.4.9.30 transformatie: aggregatietype

Aanduiding of het objecttype die de eigenaar is van een relatie het doel van relatie ziet als een samen te voegen onderdeel.

Aggregatie- en compositie-associaties worden gemodelleerd zoals simpele relatiesoorten, gebruikmakend van de specifieke naam die de associatie in het oorspronkelijke model heeft. Een mim:aggregatietype wordt direct, zonder aanpassing, overgenomen in het vertaalde model.

CONSTRUCT {
  ?subject mim:aggregatietype ?aggregatietype
}
WHERE {
  ?modelelement mim:aggregatietype ?aggregatietype.
  ?subject mim:equivalent ?modelelement.
}
6.4.9.31 transformatie: code

De in een registratie of informatiemodel aan de enumeratiewaarde toegekend unieke code (niet te verwarren met alias, zoals bedoeld in 2.6.1).

Een mim:code wordt vertaald naar een skos:notation.

CONSTRUCT {
  ?subject skos:notation ?notation
}
WHERE {
  ?modelelement mim:code ?notation.
  ?subject mim:equivalent ?modelelement
}
6.4.9.32 transformatie: specificatie-tekst

De specificatie van de constraint in normale tekst.

Een mim:specificatieTekst wordt direct, zonder aanpassing, overgenomen in het vertaalde model, als onderdeel van de transformatieregel voor constraints.

CONSTRUCT {
  ?subject skos:specificatieTekst ?specificatietekst
}
WHERE {
  ?modelelement mim:specificatieTekst ?specificatietekst.
  ?subject mim:equivalent ?modelelement
}
6.4.9.33 transformatie: specificatie-formeel

De beschrijving van de constraint in een formele specificatietaal, in OCL.

Een mim:specificatieFormeel wordt direct, zonder aanpassing, overgenomen in het vertaalde model, als onderdeel van de transformatieregel voor constraints.

CONSTRUCT {
  ?subject skos:specificatieFormeel ?specificatieformeel
}
WHERE {
  ?modelelement mim:specificatieFormeel ?specificatieformeel.
  ?subject mim:equivalent ?modelelement
}
6.4.9.34 transformatie: attribuut

Een mim:attribuut wordt vertaald naar een sh:property die hoort bij de de NodeShape van de bezitter van het attribuut. Zie ook Attribuutsoort.

CONSTRUCT {
  ?nodeshape sh:property ?propertyshape
}
WHERE {
  ?modelelement mim:attribuut ?attribuutsoort.
  ?nodeshape mim:equivalent ?modelelement.
  ?nodeshape a sh:NodeShape.
  ?propertyshape mim:equivalent ?attribuutsoort.
  ?propertyshape a sh:PropertyShape.



}
6.4.9.35 transformatie: gegevensgroep (eigenschap)

Een mim:gegevensgroep wordt vertaald naar een sh:property die hoort bij de de NodeShape van de bezitter van het attribuut. Zie ook Gegevensgroep.

CONSTRUCT {
  ?nodeshape sh:property ?propertyshape
}
WHERE {
  ?modelelement mim:gegevensgroep ?gegevensgroep.
  ?nodeshape mim:equivalent ?modelelement.
  ?nodeshape a sh:NodeShape.
  ?propertyshape mim:equivalent ?gegevensgroep.
  ?propertyshape a sh:PropertyShape.



}
6.4.9.36 transformatie: indicatie classificerend

Een mim:indicatieClassificerend kent een complexe vertaling. De betekenis van dit veld is dat dit veld een waardelijst kent, waarbij de waarden zelf feitelijk als subklassen gezien moeten worden van het objecttype waartoe het attribuutsoort hoort die deze indicatie heeft.

De vertaling hieronder gaat er vanuit dat sprake is van een enumeratie. In geval van een referentielijst dan geldt een vergelijkbare constructie. Echter, omdat bij een referentielijst de waarden zelf niet onderdeel zijn van het model, kan niet met zekerheid wordt gesteld dat alle gegevens aanwezig zijn voor een vertaling.

Bij de vertaling worden de mim:Enumeratiewaarden omgezet naar een owl:Class, waarbij een rdfs:subClassOf relatie wordt gelegd tussen deze klasse en de owl:Class die het equivalent is van het mim:Objecttype dat bij de mim:Attribuutsoort hoort met de indicatie classificerend.

Aangezien de overige metagegevens getransformeerd worden op basis van de mim:equivalent relatie, is het van belang dat onderstaande transformatie wordt uitgevoerd vóór de transformatie van de overige metakenmerken, maar ná de transformatie van de metaklassen.

CONSTRUCT {
  ?class a owl:Class.
  ?class rdfs:subClassOf ?superclass.
  ?class mim:equivalent ?enumeratiewaarde.
}
WHERE {
  ?objecttype mim:attribuut ?attribuutsoort.
  ?objecttype mim:equivalent ?superclass.
  ?superclass a owl:Class.
  ?attribuutsoort mim:indicatieClassificerend true .
  ?attribuutsoort mim:type ?enumeratie.
  ?enumeratie mim:waarde ?enumeratiewaarde.
  {
    {
      ?enumeratiewaarde mim:naam ?notation
      FILTER NOT EXISTS {?enumeratiewaarde mim:code ?nocode}
    }
    UNION
    {
      ?enumeratiewaarde mim:code ?notation
    }
  }
  BIND (t:classeuri(?notation) as ?class)
}

6.4.10 Transformatie vanuit RDFS/OWL/SHACL

Een Linked Data model dat is uitgedrukt in RDFS/OWL/SHACL kan gelezen worden als een MIM model. Hiervoor dient het model wel eerste getransformeerd te worden naar de MIM vocabulaire. Vervolgens dient het resultaat te voldoen aan de minimale eisen die worden gesteld aan een MIM vocabulaire.

Onderstaande tabellen geeft een overzicht van de wijze waarop de vertaling plaatsvindt. Naast deze tabel is ook een set van SPARQL statement beschikbaar gesteld (zie: rdf2mim.sparql) waarmee de transformatie automatisch kan worden uitgevoerd.

RDFS term MIM-klasse Uitleg
sh:NodeShape met sh:targetClass mim:Objecttype Een nodeshape met een targetClass verwijst naar zowel de structuur als de betekenis, zoals ook bij een objecttype
sh:NodeShape zonder sh:targetClass mim:GestructureerdDatatype Een nodeshape zonder targetClass is enkel een structuur, dwz: een gestructureerd datatype
sh:PropertyShape met sh:datatype mim:Attribuutsoort Een propertyshape met een datatype betreft een attribuutsoort
sh:PropertyShape met sh:node mim:Attribuutsoort Een propertyshape met een verwijzing naar een nodeshape betreft een attribuutsoort met een enumeratie of gestructureerd datatype (maar geen relatie naar een objecttype)
sh:PropertyShape met sh:class mim:Relatiesoort Een propertyshape met een verwijzing naar een andere klasse betreft een relatiesoort
sh:NodeShape gelinkt aan skos:inScheme of skos:member mim:Referentielijst Een nodeshape die gelinkt is aan een skos:ConceptScheme of skos:Collection betreft een referentielijst
rdfs:subClassOf mim:Generalisatie De rdfs:subClassOf eigenschap betreft een generalisatie-specialisatie constructie

Aspecten:

RDFS term MIM-aspect Uitleg
rdfs:label of sh:name als rdfs:label ontbreekt mim:naam Het rdfs:label (of sh:name als het label ontbreekt) van een nodeshape of class betreft de naam
skos:altLabel of sh:name mim:alias skos:altLabel is letterlijk een alias, sh:name is ook een alias en wordt met name gebruikt voor meer technische namen, terwijl skos:altLabel vaak een meer functionele naam bevat.
dct:subject mim:begrip dct:subject geeft dezelfde relatie weer als mim:begrip
rdfs:comment mim:definitie rdfs:comment wordt in de praktijk gebruikt op de manier als de mim:definitie. Merk op dat skos:definition hier niet wordt toegepast, omdat vanuit het MIM aanbevolen wordt om hiervoor een afzonderlijk begrippenkader op te stellen (via dct:subject / mim:begrip)
sh:minCount en sh:maxCount mim:kardinaliteit De kardinaliteit wordt bepaald door sh:minCount en sh:maxCount
sh:datatype mim:type Voor eenvoudige (data)type wordt sh:datatype gebruikt
sh:node mim:type Indien het datatype een gestructureerd datatype of enumeratie betreft, dan betreft de sh:node de relatie naar het datatype
sh:maxLength mim:lengte Identieke betekenis
sh:pattern mim:formeelPatroon Identieke betekenis
sh:class mim:doel Indien een propertyshape een relatiesoort voorstelt, dan geeft sh:class het doel van de relatiesoort weer

Er zijn ook MIM aspecten die niet een overeenkomstige tegenhanger kennen in RDFS/OWL/SHACL. Indien een modelleur deze aspecten wel wil beschrijven in het originele RDFS/OWL/SHACL model, dan kan de modelleur deze direct toepassen. Het gaat daarbij om de volgende aspecten:

MIM-aspect zonder tegenhanger in RDFS/OWL/SHACL Opmerking
mim:begripsterm Het wordt afgeraden om dit element te gebruiken, en in plaats daarvan direct te verwijzen naar het begrip zelf
mim:toelichting Het wordt afgeraden om dit element te gebruiken, en dergelijke toelichtingen op te nemen bij het begrip zelf
mim:herkomst Het wordt afgeraden om dit element te gebruiken, en dergelijke toelichtingen op te nemen bij het begrip zelf
mim:herkomstDefinitie Het wordt afgeraden om dit element te gebruiken, en dergelijke toelichtingen op te nemen bij het begrip zelf
mim:datumOpname Indien de ontologie onder versiebeheer staat, dan kan dit aspect afgeleid worden uit het versiesysteem
mim:authentiek Specifiek MIM aspect, belangrijk voor stelselcatalogus
mim:identificatieAfleidbaar
mim:locatie Dit veld wordt wel gebruikt bij het opbouwen van de URI, maar verder niet vertaald
mim:patroon Dit betreft een tekstuele variant van sh:pattern / mim:formeelPatroon
mim:populatie Specifiek MIM aspect, belangrijk voor stelselcatalogus
mim:kwaliteit Specifiek MIM aspect, belangrijk voor stelselcatalogus
mim:indicatieAbstractObject Het concept van abstract object is minder scherp in LD dan in het MIM. Hoewel deze indicatie is om te zetten in een expliciete constraint, zal het in de praktijk makkelijker leesbaar zijn om dit aspect expliciet op te nemen
mim:identificerend In LD is de URI zelf de identificatie. Met dit aspect kan aangegeven worden dat specifieke propertyshapes ook identificerend zijn
mim:aggregatietype Het aggregatietype zoals beoogd in het MIM is niet direct in RDFS/OWL/SHACL uit te drukken en kan zo alsnog worden toegelicht bij een propertyshape
mim:specificatieTekst Het gebruik van dit aspect ligt niet voor de hand, zie de opmerking onder deze tabel
mim:specificatieFormeel Het gebruik van dit aspect ligt niet voor de hand, zie de opmerking onder deze tabel
mim:constraint Dit aspect verwijst, via een mim:Constraint direct terug naar de originele shape-constraint in LD

In het MIM is het mogelijk om een constraint te beschrijven als een afzonderlijk modelelement mim:Constraint. Het idee hierachter is dat voor dergelijke constraints geen metamodelelementen beschikbaar zijn, en dat dit in een afzonderlijke formele (of informele) taal opgenomen moet worden. In Linked Data is het echter gebruikelijk om in dergelijke gevallen het metamodel uit te breiden met specifieke constructies voor een dergelijke formalisatie: Linked Data modellen zijn van nature open en uitbreidbare modellen, waarbij universele identificaties (URI's) ervoor zorgen dat de verschillende (meta)modelelementen uit elkaar gehouden kunnen worden.

Het ligt dan ook meer voor de hand om gebruik te (blijven) maken van dergelijke constructies in Linked Data. Dit wordt uitgelegd aan de hand van onderstaand voorbeeld.

Voorbeeld

Van een objecttype "Persoon" leggen we de geboortedatum en de datum van overlijden vast. Daarbij geldt dat de geboortedatum vóór, of gelijk moet zijn aan de datum van overlijden.

In het MIM zou dit als volgt uitgedrukt kunnen worden:

vb:Persoon a mim:Objecttype;
  mim:naam "Persoon";
  mim:attribuut vb:geboortedatum;
  mim:attribuut vb:overlijdensdatum;
  mim:constraint [
    mim:specificatieTekst "Het is niet mogelijk dat een persoon overlijdt voordat deze is geboren.";
    mim:specificatieFormeel "geboortedatum <= overlijdensdatum";
  ]
.
vb:geboortedatum a mim:Attribuutsoort;
  mim:naam "geboortedatum";
  mim:datatype mim:Date;
  mim:kardinaliteit "1"
.
vb:overlijdensdatum a mim:Attribuutsoort;
  mim:naam "overlijdensdatum";
  mim:datatype mim:Date;
  mim:kardinaliteit "0..1"
.

In RDF/RDFS/SHACL zou je dit als volgt uitdrukken (waarbij SHACL wordt gebruikt als formele taal):

shape:Persoon a sh:NodeShape;
  sh:targetClass voc:Persoon;
  sh:property shape:geboortedatum
  sh:property shape:overlijdensdatum
  sh:property shape:geboorteVSoverlijden
.
shape:geboortedatum a sh:PropertyShape;
  sh:path voc:geboortedatum;
  sh:datatype xsd:date;
  sh:minCount 1;
  sh:maxCount 1;
.
shape:overlijdensdatum a sh:PropertyShape;
  sh:path voc:overlijdensdatum;
  sh:datatype xsd:date;
  sh:maxCount 1;
.
shape:geboorteVSoverlijden a sh:PropertyShape;
  sh:path voc:geboortedatum;
  sh:lessThanOrEquals voc:overlijdensdatum
  sh:message "Het is niet mogelijk dat een persoon overlijdt voordat deze is geboren."
.

Bij de terugvertaling naar het MIM, kan bovenstaande formalisatie `sh:lessThanOrEquals` gehandhaafd blijven, waarbij de link wordt gelegd via het metagegeven `mim:equivalent`:


vb:Meting a mim:Objecttype;
  mim:naam "Meting";
  mim:attribuut vb:temperatuur;
  min:constraint [
    a mim:Constraint;
    mim:equivalent shape:geboorteVSoverlijden.
  ];
.
shape:geboorteVSoverlijden a sh:PropertyShape;
  sh:path voc:geboortedatum;
  sh:lessThanOrEquals voc:overlijdensdatum
  sh:message "Het is niet mogelijk dat een persoon overlijdt voordat deze is geboren."
.


6.5 Versielog

In deze versie 1.1 zijn de volgende issues verwerkt:

Issue Omschrijving
Issue #3 Toevoegen Decimal aan primaire types in MIM
Issue #7 Stereotypen en aspecten toekennen aan Enumeratie en Enumeratiewaarde
Issue #12 Metadata van het informatiemodel zelf en van de packages/subgroepen hierbinnen
Issue #16 Alle constructies een nederlandstalig stereotype: MIM-ISO
Issue #17 Vertaling naar engels opnemen in een bijlage
Issue #18 Opnemen van een tagged value voor versies/varianten van metamodel
Issue #21 Verwijzen van informatiemodel naar model van begrippen
Issue #22 GegevensgroepType onderbeschreven
Issue #23 Meer begrippen met definities in Metamodel doc
Issue #24 Hoe toevoegen locatie bij/van waardelijst (bij attribuutsoort union-element en data-element)?
Issue #33 Aspect "waarde" ontbreekt in de tekst
Issue #34 Aspect "union element" ontbreekt in de tekst
Issue #35 Aspect "data element" ontbreekt in de tekst
Issue #36 Aspect "referentie element" ontbreekt in de tekst
Issue #38 Modelaspecten versus meta-aspecten
Issue #53 Aspect "naam" heeft meerdere definities
Issue #56 Aspect "gegevensgroep" ontbreekt in de tekst
Issue #57 Aspect "attribuut" ontbreekt in de tekst
Issue #59 Waarden voor typeAggregatie c.q. subklassen
Issue #61 hoe modelleer je een keuze tussen attribuutsoorten en/of relatiesoorten?
Issue #66 Herschrijven hoofdstuk 2 en 3
Issue #69 MIM document implementatie neutraal maken, met hoofdstuk voor MIM-UML
Issue #70 MIM-LD vocabulaire maken
Issue #71 MIM-LD - MIM document, hoofdstuk MIM-LD toevoegen
Issue #72 MIM-LD - bestaand informatiemodel transformeren naar een instantieerbaar LD model
Issue #74 Generalisatie heeft twee definities
Issue #75 Externe koppeling kent een verwijzing naar een andere sectie in de definitie
Issue #76 Relatierol source en relatierol target worden niet gedefinieerd
Issue #78 Definitie van Codelist is niet onderscheidend
Issue #80 De definitie van "Primitief datatype" is recursief
Issue #81 De definitie van "Gestructureerd datatype" is recursief
Issue #85 Ontbreken van de waarde "Niet authentiek"
Issue #86 Datatype van Indicatie materiele/formele historie irt groepen klein prio2 verwerkt
Issue #87 MIM document web-friendly maken document opzet
Issue #90 Meerdere definities voor aspecten "unidirectioneel", "objecttype", "gerelateerdObjecttype" en "typeAggregatie"
Issue #96 Algemeen: UML diagrammen bijwerken voor versie.
Issue #97 Herschrijven voorwoord document opzet
Issue #100 Aanduiding van een volgorde van kenmerken?
Issue #101 Namen van objectentypen of kenmerken uniek binnen IM?
Issue #102 Hoe hergebruiken van kenmerken of definities
Issue #107 Alias en naam, of naam en alias? Wat staat er in?
Issue #110 MIM metClass Generalisatie
Issue #114 Toelichting op gebruik linked data voor UML vs RDFS/OWL
Issue #115 OMG-MDA layered model comment
Issue #117 Toelichting probleemstelling voor MIM-linked data
Issue #119 Definitie past niet goed op een abstracte objecttype (mail FK punt 3)
Issue #120 In de tekst opnemen dat het gebruik van Sparx EA niet verplicht is (mail FK punt 5)
Issue #121 Niet elke normreferentie is conform MIM (Mail FK punt 6)
Issue #124 Onduidelijk voorbeeld (Mail FK punt 9)
Issue #125 Kwaliteit concreter maken in kwaliteitseisen voor specifieke kwaliteitsdimensies (Mail DG punt 11)
Issue #127 Attribuutsoort en relatiesoort versus attribuut en begrip (Mail DG punt 13)
Issue #128 Identificeren classificerende attribuutsoort
Issue #129 Codelijst vs Codelist

A. Referenties

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/