Samenvatting

MIM (Metamodel voor Informatiemodellen) beschrijft een methodiek voor het vastleggen van de structuur van informatie. Het MIM kan bijvoorbeeld worden gebruikt om een model voor Fietswinkels vast te leggen. Dit document beschrijft hoe je zo’n model kunt opstellen.

Over dit document

Dit document is geschreven door Armatiek BV en geaccordeerd door leden van de MIM community. Het geeft een redelijk compleet beeld van het MIM, met voorbeelden uit de UML realisatie.

Dit document behandelt het MIM vanuit de structuur van een informatiemodel: we starten met de grove opbouw van het informatiemodel, dalen af naar de concepten en hun relaties, en gaan als laatste in op de eigenschappen van deze constructies. We raden aan het document dan ook in deze opeenvolging te lezen. In een apart hoofdstuk werken we allerlei detailaspecten uit zoals naamgevingseisen, identificatie van onderdelen, en historie.

We plaatsen veel verwijzingen in de tekst, in de verwachting dat de lezer daarmee gemakkelijker de complexe structuur “onder de knie” kan krijgen. De verwijzingen hebben de volgende vorm:

We hopen dat deze Primer de lezer op deze manier voldoende basis geeft voor het begrijpen en toepassen van de MIM standaard.

Inleiding

Dit document is in ontwikkeling.

Het is mogelijk mee te werken aan dit document, en/of op de inhoud van dit document te reageren. Hiervoor is de Primer gekoppeld met Hypothesis . Om met behulp van Hypothesis te reageren moet je een account hebben , en toegelaten worden tot de groep van betrokkenen. Hiervoor kun je deze uitnodiging gebruiken.

Náást dit document is een Demonstrator beschikbaar. Geïnteresseerden kunnen deze software gebruiken in combinatie met deze Primer. Lees hier meer over de Demonstrator.

Een MIM informatiemodel beschrijft een deel van de werkelijkheid waarover we op een voorspelbare manier informatie willen inwinnen, registreren of uitwisselen. Dat kan in taal, op papier, of natuurlijk via ICT systemen. Onderdelen van een informatiemodel keren terug in elektronische berichten, databases, schermcomponenten et cetera. Een helder en geaccepteerd informatiemodel staat mogelijk aan de basis van een scala aan toepassingen, die daarmee de “echte” wereld en de technische ondersteuning daarvan verbindt.

In deze Primer gebruiken we een fictieve fietsenwinkel als onderwerp om de elementen van het MIM en hun toepassing in een informatiemodel te tonen. Terwijl fietsen worden gemaakt, verhandeld en bereden (de echte wereld) is er een technische, administratieve wereld die dit ondersteunt. In de techniek komen concepten voor die in de echte wereld zijn benoemd: Fiets, Klant, Framenummer, Verkoop. Het informatiemodel brengt deze met elkaar in verband.

In MIM zijn deze concepten getypeerd: een “Fiets” is een Objecttype; een “Framenummer” is een Attribuutsoort; “verkocht aan” is een Relatiesoort.

Deze concepten zouden we, als we met elkaar samenzitten om samen het interessedomein in kaart te brengen, waarschijnlijk tekenen met bolletjes, vakjes en pijltjes, of in een tabel opnemen, of anderszins een concrete vorm geven waar we met elkaar naar kunnen kijken. Die vorm is echter niet waar we in eerste instantie over spreken in het MIM. In MIM beperken we ons tot wat voor soort modelelementen er zijn. Daarnaast wordt een visuele representatie daarvan besproken. En een mogelijke technische serialisatie daarvan.

In deze Primer gebruiken we een weergave die het meest dicht bij de MIM specificatie zit. We volgende Demonstrator weergave.

Daarnaast tonen we hoe deze modelelementen getekend kunnen worden in UML klasse-diagrammen.

Het voorbeeld model, de Fietsenwinkel, wordt volledig gedocumenteerd als bijlage opgenomen in deze Primer.

Globale opzet van de standaard

TODO Hoe is de standaard opgezet? Conceptuele, logische en andere modellen

De MIM standaard bestaat uit 3 delen, die op zich los van elkaar kunnen worden gelezen. Het eerste deel is de uitwerking van de modelelementen en hun metagegevens. Bijvoorbeeld: een Objecttype (modelelement) heeft een definitie (metagegeven). Het tweede deel is de realisatie daarvan in de vorm van een UML klasse diagram. Bijvoorbeeld: Een objecttype wordt een UML klasse, de definitie een tekst in het notitieveld. Het derde deel is de Linked data serialisatie van deze constructies. Bijvoorbeeld: Een objecttype is een klasse in RDF Schema, een definitie is een eigenschap van deze klasse.

Daarnaast zijn allerlei afspraken en regels opgenomen die MIM zelf beperken. Zo wordt vastgelegd welke primitieve datatypen MIM zelf al kent, en hoe je zelf nieuwe datatypen kunt afleiden van deze primitieve datatypen.

Naast de standaard zelf is een Handreiking Informatie Modelleren en een beheerplan beschikbaar. De Handreiking Informatie Modelleren is geschreven in de context van de DSO, en betreft het gebruik van UML voor logische informatiemodellen. Het document stelt vast welke keuzes binnen DSO worden gemaakt in de vrijheden die MIM biedt en de software die beschikbaar is. Het beheerplan stelt vast op basis waarvan het beheer van het MIM wordt uitgevoerd. Dit plan geeft inzicht in de inhoud en omvang van de relevante beheerprocessen en welke middelen en functieprofielen hiervoor nodig zijn.

Deze Primer is een aanvulling op deze documentatie, en is niet normatief.

Voorbeeld informatiemodel: Fietsenwinkel

In deze Primer werken we met een voorbeeld informatiemodel, waarvan we de opbouw in aspecten beschrijven. In de MIM standaard wordt een voorschot genomen op hoe de MIM constructies moeten worden gerealiseerd (getekend in UML, omgezet in Linked Data RDF), maar op zich vormen het metamodel en de afspraken en regels voldoende basis voor consensus over wat we willen kunnen registreren voor een willekeurig informatiemodel. Het is dan ook belangrijk om deze opbouw onafhankelijk van de uitwerking in UML of Linked data of welke (beeld)taal dan ook te begrijpen.

We hanteren in deze Primer daarom voorbeelden (ter illustratie) uit de Demonstrator die speciaal is ontwikkeld om deze aanpak duidelijk te maken. Deze voorbeelden zijn schermafbeeldingen van de editor omgeving, die de MIM 1.1 standaard op de voet volgt. Deze editor is bedoeld om MIM 1.1 toegankelijk te maken. Zie ook bijlage Demonstrator.

Fietsenwinkel in tekst

Wanneer we een informatiemodel willen maken van onze Fietswinkel kunnen we het domein beschrijven als tekst. Daarin treffen we de belangrijkste concepten aan die rol gaan spelen in toepassingen van het model. De details volgen in een latere fase.

Citaat:

Fietsenwinkels zijn Winkels waarin Fietsen worden verhandeld. Deze Fietsen worden geleverd door Leveranciers, en verkocht aan Klanten. Dit zijn Contacten waarvan informatie wordt bijgehouden, waaronder de naam en het adres. Ook wordt een Betaalmiddel voor klanten en leveranciers vastgelegd. Klanten zijn Personen, Leveranciers zijn instellingen. Betaalmiddelen zijn Creditcard of Bankrekening; er wordt niet contant afgerekend.

Fietsen zijn onderdeel van de Inventaris. Er zijn allerlei soorten fietsen waaronder Sportfietsen en Stadsfietsen. Sommige fietsen hebben een hulpmotor met Batterij (e-bikes). De batterij is een apart te verhandelen item in de Inventaris, met een eigen garantienummer.

Als een Fiets wordt verkocht wordt dat als een Verkoop geregistreerd. De Verkoop heeft een Verkoopdatum en een Garantienummer.

Fietsenwinkel als plaatje

Wanneer we een informatiemodel willen maken van onze Fietswinkel kunnen we het domein ook meteen al als plaatje uitwerken. Dat kan op veel manieren (in gedachten, bierviltje, papier, elektronisch) maar grofweg zal het plaatje er na enig denkwerk er zo uit zien. Zoals je ziet komen de woorden terug uit de beschrijving die we eerder gaven. Wat er eerder was, de tekst of het plaatje, is niet relevant.

Vrije impressie van het model voor Fietsenwinkels

Tekst of plaatje?

De tekst noch het plaatje volgt een standaard methode voor het beschrijven van aspecten van het model. Het helpt ons wel om na te denken over de opbouw daarvan.

Hoe ver we ook gaan in het uitwerken van het voorgaande plaatje, of de tekst die daar bij hoort, we houden hoe dan ook de volgende beperkingen:

  1. De “beeldtaal” is niet breed bekend en ondersteund, en daarmee bron van verwarring.

  2. Het model is niet gegarandeerd compleet dus informatie kan gemakkelijk weggelaten worden. Er is geen goede manier om je analyse te valideren.

  3. Er is geen software die iets verstandigs kan doen met het model.

Door MIM te gebruiken als modelleertaal worden deze beperkingen ondervangen. Door het gebruik van MIM zijn er strakke definities voor de betekenis van de bouwstenen van het model, zoals Informatiemodel (Fietswinkel), Domein (Inventaris), Objecttype (Stadsfiets), Relatiesoort (Leverancier – Fiets) en dergelijke. Daarmee zijn die concepten ondersteund door toegankelijke en sluitende beschrijvingen in de standaard zelf, kan het model worden gevalideerd (klopt het? is het compleet?) en kan software worden gemaakt voor het omzetten van het model in bruikbare ICT componenten.

Naast vastgestelde definities van de concepten adviseert MIM om UML als tekentechniek te gebruiken, in de vorm van UML Klasse-diagrammen. De standaard geeft een compleet beeld van alle UML constructies die conform het MIM metamodel kunnen worden gebruikt. Ook stelt MIM vast op welke manier een MIM model moet worden uitgedrukt in RDF constructies. Dit laatste heeft niet de focus van deze Primer.

MIM introduceert daarmee de constructies die wel gestandaardiseerd kunnen worden opgenomen en gedeeld met anderen. Als we dit relateren aan het getekende plaatje:

  1. Het informatiemodel is “het plaatje”.

  2. Domeinen zijn in het plaatje apart gekleurd opgenomen: Winkel (geel), Inventaris (blauw), Contacten en Verkoop (wit).

  3. De Objecttypen die een rol spelen zijn als rechthoek ingetekend (Sportfiets).

  4. Allerlei relaties zoals met Adres, en type-relaties (generalisatie) zoals Fiets-Stadsfiets zijn als pijlen getekend. De relatie met Batterij (fysiek onderdeel van fiets) is als lijntje getekend.

  5. Andere eigenschappen hebben nog geen plek gekregen.

Bij het omzetten van de tekst/het plaatje in een MIM informatiemodel is het verstandig om te werken vanuit Informatiemodel naar domein naar constructies in het domein naar eigenschappen van die constructies en de eigenschappen dáárvan. Een soort top-down benadering: we modelleren een informatiemodel, identificeren de domeinen, plaatsen er objecttypen in, geven het attributen, en geven die modelelementen metagegevens, bijvoorbeeld:

Voorbeeld:

Informatiemodel Fietsenwinkel > Domein Inventaris > Objecttype Fiets > Attribuutsoort Naam > Metagegeven identificerend

Het metagegeven “identificerend” zoals getoond in de Demonstrator.

We werken in deze Primer vanuit het informatiemodel naar de details.

Opbouwen van het informatiemodel

Het MIM introduceert nogal wat termen en constructies. Deze constructies vallen veelal onder een andere constructie. Het informatiemodel bestaat uit één of meer domeinen, nul of meer views, en vaak wel enkele externe packages. Binnen deze “packages” krijgen de andere modelelementen van MIM een plek. Deze “hiërarchie” van modelelementen tonen we hieronder. De linkjes zijn referenties naar de uitwerking van die constructies in deze Primer, dus naar aparte hoofdstukken die daarover gaan.

Informatiemodel

Een Informatiemodel is een Package: een benoemde en begrensde verzameling/groepering van modelelementen. Het informatiemodel Fietswinkels tracht dus een model te vormen voor de administratie van winkels waarin fietsen worden verkocht. We nemen hierbij aan dat er een begrippenkader bestaat waarin de woorden/termen die we hanteren zijn beschreven. Zo’n begrippenkader heeft bij voorkeur een elektronische vorm. We kunnen naar begrippen verwijzen, bijv. http://www.fietswinkels.nl/begrippenkader/Fiets of door gewoon “Fiets” op te voeren. De lijn tussen begrippen in dat begrippenkader, en die welke worden gebruikt in informatiemodellen is vaak dun. De definitie van een begrip in een begrippenkader is vaak (bijna) gelijk aan die van het objecttype in het informatiemodel. Hoe dichter beide vocabulaires bij elkaar blijven, hoe beter het is.

We stellen eerst ons informatiemodel vast. Behalve de naam van het informatiemodel (Fietsenwinkel) moeten we ook een aantal andere kenmerken opgeven. Deze worden hieronder beschreven. We tonen meteen een voorbeeld waarde die voor ons voorbeeld informatiemodel Fietsenwinkel geldt.

Metagegeven

Uitleg

Naam

Deze naam is uniek binnen de lijst van alle informatiemodellen. MIM stelt geen speciale eisen voor welke karakters hierin mogen voorkomen.

Voorbeeld:

“Fietsenwinkel”

Vrijwel alle modelelementen in het MIM hebben een naam. Uitgangspunt is steeds dat de naam in haar context uniek is. Die context verschilt per modelelement.

Zie ook: .

Definitie

Dit is een beschrijving die voldoende onderscheidend is van andere definities om te begrijpen waar het over gaat. De definitie is een vrij tekstveld, en daarin kunnen dus speciale karakters en enige opmaak ik opgenomen worden. MIM zegt er niets over, je mogelijkheden worden bepaald door de tooling die je hanteert.

Voorbeeld:

“Dit is een model voor registratie van inventaris en betrokken producenten en klanten van fietsenwinkels.

Dit model heeft alleen tot doel de aard en toepassing van constructies te illustreren, en is opgezet als een UML realisatie van de in MIM besproken modelelementen.

Dit model is opgezet conform MIM 1.1

Het is bijna een filosofische vraag wat een modelelement “definieert”. Over het algemeen zal een definitie bondig zijn, en aangeven waarin het modelelement zich onderscheid van andere modelelementen. Het is dus niet zinvol een Mountainbike te definiëren als “Een soort fiets”, want dat kun je ook van en stadfiets zeggen. MIM zegt niet hoe je moet definiëren. Maar neem nooit informatie daarin op die al via andere metagegevens beschikbaar zijn (begrip, toelichting e.d.).

Zie ook: .

Herkomst

Dit is een aanduiding van de instelling waar het informatiemodel vandaan komt en/of het informatiemodel waar het op gebaseerd is.

Voorbeeld:

TODO

Zie ook: .

Domein

Een aanduiding van het “functionele domein” van het model. Deze aanduiding kan gebruikt worden om formele referenties naar constructies te onderscheiden van gelijknamige constructies in andere modellen. Veelal wordt hier een afkorting gekozen.

Voorbeeld:

TODO

Zie ook: .

Informatiemodel type

Beschrijf het type van dit model , d.w.z. Is het conceptueel of logisch van aard? Feitelijk dekt MIM alleen deze twee typen modellen af.

Conceptuele modellen richten zich met name op de constructies die niet technisch van aard zijn. Deze constructies keren terug in documentatie, gesprekken, en (dus) ook in begrippenkaders. Het informatiemodel slaat op deze manier een brug tussen de praktijk (“de business”) en de technische systemen.

De techniek kan zich baseren op een eigen logisch model, waarin keuzes zijn gemaakt op basis van praktische beperkingen of mogelijkheden. Zo kunnen personen, in het conceptueel model nog uitgesplitst in ingeschreven en niet-ingeschreven personen, worden samengevoegd in een logisch model tot “persoon”, dat de basis vorm voor technische modellen en –realisatie.

Voorbeeld:

“Conceptueel”

Relatiemodelleringstype

Is in dit model de rol van een relatie leidend, of de relatie zelf? Als de rol leidend is worden rollen benoemd, en metagegevens aan de rol gekoppeld.

Dit is feitelijk een keuze voor een modelleringsstijl. Bij de keuze voor "Relatiesoort leidend" is de naam van de relatie leidend, bij de keuze voor "Relatierol leidend" zijn de namen van de bron en het doel van de relatie leidend. Bijvoorbeeld in de relatie tussen een organisatie en een persoon kan de relatiesoort "is werkgever van" zijn of de bron naam is "werkgever" en de source naam is "medewerker".

Voorbeeld:

“Relatiesoort leidend”

Zie ook: .

MIM versie

De MIM specificatie die gebruikt is om het informatiemodel in uit te drukken. Nu alleen 1.1, maar in de toekomst kunnen er meerdere versies ondersteund worden.

Voorbeeld:

“1.1”

MIM extensie

Je geeft hier aan of meer constructies of metagegevens zijn gebruikt dan die van MIM11. Zo ja, dan kan deze aanduiding een lezer leiden naar relevante documentatie of aan software worden meegegeven dat een andere verwerking vereist is.

Voorbeeld:

(We gebruiken geen extensie in het Fietsenwinkel voorbeeld)

MIM taal

Dit is de aanduiding van de taal die gebruikt is voor de modelelementen. Kies voor een waarde uit ISO 639-1 .

Voorbeeld:

“NL”

Misschien verwacht je op dit niveau, bij het opgeven van informatie over je informatiemodel als geheel, dat hier ook de versie, bewerker, en andere metadata van het model zelf kan worden aangegeven. Zoals je ziet, en ook in andere packages en constructies bemerkt, is geen versie-informatie of informatie over de status van de ontwikkeling van de constructies opgenomen in MIM. MIM modelleert dus echt één “snapshot” van het model, onafhankelijk van de status daarvan, of de plek in het werkproces. In extensies is het gebruikelijk daarvoor metagegevens toe te voegen.

Domein package

Het Informatiemodel bestaat vooral uit Domeinen. Dit zijn aandachtsgebieden die een zekere interne consistentie hebben: zaken die bij elkaar horen (feitelijk dus ook een Package). Dat is vaak een subjectieve groepering. Het kan betekenen dat ze als groep een versiegeschiedenis hebben, en/of dat ze bij elkaar gedocumenteerd worden. Zeker als het om complexe modellen gaat is het zinvol domeinen te benoemen.

Voorbeeld:

Het kadaster hanteert o.a. de volgende domeinen voor haar IMKAD model:

- Onroerende zaak (w.o. Perceel)

- Teboekgestelde zaak (w.o. Schip)

- Zakelijk recht (w.o. Ondersplitsing)

- Persoon (w.o. Niet-natuurlijk persoon)

- Stuk en stukdeel (w.o. Ter inschrijving aangeboden stuk)

Op basis van onze analyse van Fietsenwinkel bepalen we dat er twee domeinen een rol spelen:

Sommige modelelementen worden in meerdere domeinen gebruikt. Het kan voor het overzicht handig zijn om deze gemeenschappelijke modelelementen samen in een apart domein onder te brengen. We hebben in ons voorbeeld het Gemeenschappelijke typen domein opgenomen, wat feitelijk geen domein is maar een verzamelbak.

Van ieder Domein package leggen we het volgende vast:

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek binnen het informatiemodel.

Voorbeeld:

“Inventaris”

Zie ook: .

Er is dus maar één domein metagegeven.

View package

Naast domeinen kunnen Views zijn opgenomen. Het betreft dan een domein dat eigenlijk gebaseerd is op een ander informatiemodel, maar met eigen beperkingen en uitbreidingen. Deze Views geven inzicht in welke gegevens van het externe model relevant zijn binnen het eigen informatiemodel.

Het introduceren van een view heeft veelal tot gevolg dat je in overleg treedt met de eigenaar van dat externe model.

We gebruiken in het fietsenwinkel voorbeeld een domein dat gebaseerd is op een extern model voor persoonsregistratie. Dit is de View Persoon, en deze is gebaseerd op Persoonsmodel detailhandel, dat door de brancheorganisatie is opgesteld. Voor de Fietsenwinkel hanteren we daarvan een variant.

Van de View package leggen we het volgende vast:

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek binnen het informatiemodel.

Voorbeeld:

“Persoon”

Zie ook: .

Locatie

Dit is de plek waar meer informatie te vinden over het informatiemodel waar deze view op gebaseerd is.

Voorbeeld:

https://www.detailhandel.nl/modellen/Personen/ ” (dit is een fictief model)

Andere eerder besproken metagegevens van View zijn: Definitie en Herkomst.

Extern package

Als laatste kunnen Externe packages in het informatiemodel voorkomen. Deze packages bevatten verwijzingen naar modellen in de buitenwereld, zonder dat er een bepaalde interpretatie (zoals bij views) aan wordt gegeven. Een goed voorbeeld is een GML package, waar we naar willen kunnen verwijzen (“Point zoals bedoeld in GML 3.2”).

In het fietsenwinkel voorbeeld zijn twee externe packages opgenomen voor MIM11 zelf, en voor GML Geometrie. MIM11 Primitieve typen zijn de typen zoals opgenomen in de standaard . Attribuutsoorten kunnen verwijzen naar deze typen, en we kunnen nieuwe typen introduceren die subtype zijn van deze typen. Bijvoorbeeld een Garantienummer is subtype van MIM CharacterString. GML (Geography Markup Language, d.i. ISO 19136) introduceert typen voor geometrische constructies, zoals oppervlak en lijn. Zo is de geolocatie van een Adres een GML Point. De manier waarop deze constructies moeten worden geïnterpreteerd ligt vast in de genoemde documenten.

Van het Extern package leggen we het volgende vast:

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek binnen het informatiemodel.

Voorbeeld:

“GML”

Zie ook: .

Locatie

Dit is de plek waar meer informatie te vinden over dit informatiemodel. Is moet een URI of URL zijn.

Voorbeeld:

https://www.ogc.org/ ” (GML is een OGC standaard)

Andere eerder besproken metagegevens van Extern package zijn: Definitie, Herkomst.

Modelleren van concepten en hun relaties

Domeinen bevatten de modelelementen van het informatiemodel. De modellering draait met name om Objectypen met attribuutsoorten en relatiesoorten. We behandelen deze hieronder.

Objecttype

Een “object” is een ding, een tastbaar iets, in de werkelijkheid, zoals daarnaar gekeken wordt vanuit een bepaald domein. Voorbeeld is een specifieke Cube fiets, die onlangs aan mevrouw Jansen is verkocht. Ook mevrouw Jansen is een “object” in de wereld van de fietsenwinkel (het “domein”).

Een Objecttype is een typering van een groep objecten die binnen een domein relevant zijn en als gelijksoortig worden beschouwd. Mevrouw Jansen is van het objecttype Klant. De Cube fiets is van het objecttype Sportfiets.

Een objecttype is voor een domein relevant als eigenschappen (kenmerken) daarvan van belang zijn voor het functioneren van dat domein. Bijvoorbeeld: als je het adres van een klant niet vastlegt kun je geen factuur opsturen.

Objecttypen kunnen abstract zijn, zoals Fiets. In dat geval zijn er concrete subtypen die als zodanig worden opgenomen in een administratie: de Sportfiets.

Een object heeft altijd een unieke aanduiding, die het onderscheid van alle andere objecten. Voorbeeld: het Burgerservicenummer van een Persoon. Die unieke aanduiding is opgenomen als metagegeven van een of meerdere attributen van het Objecttype. Het is dus geen metagegeven van het object zelf.

Wanneer we een Domein of View hebben geïntroduceerd kunnen we daarin deze Objecttypen opnemen.

Van een Objecttype leggen we het volgende vast:

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek binnen het informatiemodel.

Voorbeeld:

“Fiets”

Zie ook: .

Alias

Dit is een naam die ook kan worden gehanteerd en die exact hetzelfde betekent als de naam van het Objecttype. Gekozen kan worden voor een technische, meer natuurlijke, of vertaalde naam.

Voorbeeld:

“Bike”

Zie ook: .

Begrip

Achter het modelelement in het informatiemodel kunnen meerdere begrippen zitten die zijn vastgesteld in het begrippenkader, d.w.z. een ontologie, thesaurus of andere taxonomie, of een geheel andere min of meer formele lijst van begrippen. Wanneer je kiest voor een URI, of voor een term, moet deze herleid kunnen worden tot een eenduidige specificatie. Beste is een URL, maar soms kan dat niet. Er kunnen meerdere begrippen van toepassing zijn.

Zie ook: .

Herkomst definitie

De definitie is onttrokken aan een informatiemodel dat al dan niet het huidige model is. In alle gevallen geef je aan waar de definitie voor het eerst is opgenomen. De definitie mag wel zijn veranderd of opgesplist. De bron blijft relevant.

De waarde die je hier opgeeft is niet formeel, en je moet een eigen keuze maken.

Voorbeeld:

“FW” (Fietswinkel informatiemodel, dus dit is de bron)

Datum opname

De datum waarop dit objecttype is opgenomen in het informatiemodel. Er is geen formaat afgesproken voor deze datum, dus bijv. een ISO datum, een jaartal, of een korte omschrijving van een moment is acceptabel.

Voorbeeld:

“20210901”

Zie ook: .

Populatie

De beschrijving van de exemplaren van het gedefinieerde objecttype in de registratie die centraal staat in dit model. Het betreft dan met name objecttypen die deel uitmaken van een (basis)registratie. In andere modellen zal dit veelal niet worden ingevuld.

Voorbeeld:

“In de landelijke keten Fietsenhandel zijn 25 winkels opgenomen (peildatum 1 januari 2021).” (voor Winkel)

Of:

“De fietsen die verkrijgbaar zijn via de landelijke keten fietsenhandel” (voor Fiets).

Zie ook: .

Kwaliteit

Hoe volledig, juist, actueel, nauwkeurig en betrouwbaar worden de objecten geregistreerd in de registratie die centraal staat in dit model?

Voorbeeld:

“De winkels worden elk jaar in kaart gebracht middels enquêteformulieren.” (voor Winkel)

Zie ook: .

Toelichting

Dit is een verheldering of nadere duiding van de definitie. Denk aan uitleg, voorbeelden, referenties aan beschrijvingen op het web etc.

Voorbeeld:

“Hierbij worden groothandels uitgesloten. Ook webwinkels zijn geen onderdeel van dit informatiemodel.”

Zie ook: .

Supertype(n)

Een Objectype kan meerdere supertypen hebben. De relatie met die supertypen is een vorm van generalisatie. In principe geldt dan dat het subtype altijd de plek kan innemen van het supertype (substitution ). Bovendien heeft het minimaal dezelfde verzameling kenmerken als het supertype. Bijvoorbeeld: als een Fiets verkoopbaar is, is ook een Stadsfiets verkoopbaar. En als een Fiets een batterij kan hebben, kan ook de Stadsfiets een batterij hebben.

Er is wel discussie geweest of een objecttype, of een ander modelelement meerdere supertypen mag hebben. Daar is weinig tegen, al kan het wel verwarrend werken, zeker als beide typen overlappen of elkaar op aspecten tegenspreken. Zulke problemen worden in tekst en/of in techniek (logische / technische modellen) opgelost.

Voorbeeld:

Stadsfiets is subtype van Fiets (supertype)

Keuze attribuutsoorten

Objecttypen hebben veelal attributen, zgn. Attribuutsoorten. Het kan zijn dat er een keuze tussen zulke attributen kan zijn bedoeld. Men neemt in een object het ene of het andere attribuut op. Bijvoorbeeld: een Fiets heeft als attribuut ketting (met een type ketting als waarde) of als attribuut snaaraandrijving (met een type snaar als waarde).

Het feit dat beide typen fiets een andere aandrijving hebben heeft dan dus niet tot gevolg dat we over andere typen fietsen (andere Objecttypen) willen spreken in ons model. Introductie van nieuwe Objecttypen voor zulke situaties kan tot nogal onoverzichtelijke modellen leiden.

Voorbeeld:

Aandrijving van Fiets (Fiets.aandrijving)

Indicatie abstract object

TODO

Andere eerder besproken metagegevens van objecttype zijn: Definitie en Herkomst.

Attribuutsoort

Een Attribuutsoort is een eigenschap van een Objecttype, welke per object wordt vastgelegd. Naam, omvang, prijs, straat zijn voorbeelden van Attribuutsoorten. Sommige Attribuutsoorten hebben een identificerend karakter, sommige Attribuutsoorten zijn optioneel of kunnen meermaals voorkomen. Dit is de kardinaliteit van het attribuutsoort.

Van een Attribuutsoort leggen we het volgende vast:

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek binnen het objecttype waar het deel van uitmaakt.

Voorbeeld:

“verkoopdatum” (Verkoop.verkoopdatum)

Zie ook: .

Type

Het datatype is een tekenreeks of een combinatie van tekenreeksen. Voorbeelden zijn “Amsterdam” (Primitief datatype CharacterString), 9.5 (Primitief datatype Decimal) of 10 meter (een Gestruktureerd datatype).

Als een waarde aan een lijst wordt ontleend kan het ook een waarde zijn uit een Enumeratie, een Codelijst of een Referentielijst. Welke keuze ook wordt gemaakt, de waarde is een echt een “waarde”, niet een constructie waar je naar kunt verwijzen.

Voorbeeld:

Datatype van verkoopdatum is een “Date (Primitief datatype uit MIM).

Datatype van garantienummer is een “Garantienummer”, dat een subtype is van MIM CharacterString.

Zie ook: .

Keuze datatypen

Wanneer het datatype van een Attribuutsoort ofwel het ene, of wel het andere datatype is, kan een Keuze worden geïntroduceerd. Zo kan de geo-locatie van een winkel aangeduid worden als een punt op de kaart, of een vlak, of zelf een polygoon. Hiervoor kunnen we een keuze introduceren. De keuze is een een UML datatype omdat het effectief altijd een waarde betreft van het attribuut.

Voorbeeld:

“Geografische locatie” staat keuze tussen GM_Point of GM_Polygon toe.

Keuze attribuutsoorten

TODO

Lengte

De lengte van de waarde van een attribuutsoort kan worden uitgedrukt in een geheel getal (exacte lengte) of een reeks zoals 1…8 (één tot 8 posities). Wat er exact in deze waarde wordt ingevuld blijft nog open. Dat kan door middel van een Patroon en/of Formeel patroon nader worden bepaald. De lengte heeft betrekking op tekenreeken en hele getallen; wanneer gebroken getallen bedoeld zijn wordt het aantal posities voor en achter de komma aangegeven als “3,2” (een eventueel plus- of minteken wordt niet meegerekend).

Voorbeeld:

“16” (de exacte lengte van kaartnummer van Creditcard)

Zie ook: .

Patroon

Een patroon is een beschrijving van de mogelijke karakters in een tekenreeks. Hier gebruiken we natuurlijke taal. Wanneer een Formeel patroon wordt opgegeven moet dat formele patroon in lijn zijn met het opgegeven Patroon.

Voorbeeld:

Bijvoorbeeld: “vier cijfers, en dan twee letters in kapitaal, opgenomen in de post-nl postcodelijst (voor Adres.postcode).

Zie ook: .

Formeel patroon

Het formele patroon is een beschrijving van het patroon als een reguliere expressie, en volgt de Perl conventies . Een formeel patroon kan worden gespecificeerd voor alle datatypen die een tekenreeks representeren. Sommige aspecten kun je niet goed kwijt in een reguliere expressie, zoals minimum en maximum waarde. Daarvoor val je terug op patroon.

Voorbeeld:

“[A-Z]{4}[0-9]{2}” is een expressie die een postcode beschrijft (Adres.postcode).

Zie ook: .

Indicatie materiële historie

Bekend moet zijn wat de waarde van een attribuut op een bepaald moment is. Wanneer is iets gebeurd, in de werkelijkheid of volgens opgave? Dit noemen we materiële historie. We geven aan of van een attribuut deze historie wordt bijgehouden.

Materiële historie is een van de historie aspecten van het informatiemodel. Historie wordt in MIM 1.1 uitgewerkt in een apart hoofdstuk .

Voorbeeld:

“Nee” (Contact.adres, Indicatie materiële historie) De verhuizing van de klant wanneer deze in werkelijkheid plaatsvindt wordt niet geregistreerd. Een Fietsenwinkelier weet dat doorgaans niet.

Zie ook: .

Indicatie formele historie

Net als materiële historie registreert formele historie veranderingen door de tijd heen. Ook hier wordt bepaald of deze verandering wordt geregistreerd. Vanaf wanneer waren de gegevens bekend bij de instelling? Dit is de formele historie. Dit wordt elders beschreven.

Voorbeeld:

“Ja” (Contact.adres, Indicatie formele historie) De verhuizing van de klant wanneer deze wordt doorgegeven wordt wel geregistreerd. De adressen van de klant door de jaren heen worden dus wel bijgehouden.

Zie ook: .

Kardinaliteit

We moeten aangeven of bepaalde kenmerken optioneel of verplicht zijn, en misschien zelf meermaals kunnen worden gespecificeerd. Dit geven we aan als 0..1 (optioneel), 1..5 (1 tot 5 keer), 2..* (2 of meer keer) en zo voorts. De standaard kardinaliteit is 1. Kardinaliteit geven we op bij attribuutsoorten en relatiesoorten.

Voorbeeld:

“Adres.locatie = 0.1 Geografische locatie” - De locatie van een Adres kan een optionele geografische locatie bevatten. Het niet opnemen van een locatie is dus modelmatig niet nodig. Vergelijk dit met metagegeven Mogelijk geen waarde, zie elders.

Zie ook: .

Authentiek

In overheidsland worden allerlei gegevens opgenomen en uitgewisseld. Van een deel hiervan is vastgesteld dat de instelling die de gegevens registreert de “authentieke bron” is dan die gegevens. Kadaster registreert Percelen, BRP registreert personen, et cetera. De essentie is dat een instelling “de waarheid in pacht heeft” en dat deze instelling er dus op aangesproken kan worden. Andere instellingen nemen deze info mogelijk over in hun registratie en/of uitwisselingen. Deze info is dan niet authentiek .

Mogelijke waarden voor dit metagegeven zijn aan de Stelselcatalogus ontleend: Authentiek (authentiek voor de instelling die het model opstelt), Basisgegeven (komt uit een basisregistratie), Wettelijk gegeven (komt uit een andere wettelijke registratie), Landelijk kerngegeven (komt uit een sector- en domein-overstijgend informatiemodel), of Overig (geen van voorgaande).

Voorbeeld:

“Overig” (Contact.naam Authentiek = “Overig”) - In het model voor de fietsenwinkels modelleren we binnen het detailhandel domein.

Indicatie afleidbaar

Soms neem je in het model “voor het gemak” constructies op die feitelijk afleidbaar zijn uit modelelementen die je op een andere plek al hebt opgenomen. Daarvoor moeten deze modelelementen op een specifieke manier worden begrepen, bij elkaar geplaatst en mogelijk omgezet. De waarde van een afleidbaar attribuutsoort zal daardoor ook veranderen als deze andere modelelementen veranderen van waarde in de registratie.

Voorbeeld:

“Ja” (Fiets.id afleidbaar = “Ja”) – De ID is afgeleid van Naam en typenummer.

Zie ook: .

Indicatie classificerend

De normale manier om classificatie aan te geven in informatiemodellen is via generalisatie: “een stadsfiets is een soort fiets”. Veelal is deze generalisatie bedoeld om eigenschappen en relaties uit te breiden: een racefiets heeft extra kenmerken die relevant zijn voor het informatiemodel.

Dit kan voor bepaalde toepassingen vrij overdreven uitpakken; er is eigenlijk niks extra te melden over de subtypen. Een methode is dan om een lijstje van namen van subtypen op te stellen en het “super-Objecttype” een attribuut te geven dat verwijst naar dat lijstje. In dat geval is dat attribuut classificerend bedoeld.

Voorbeeld:

“Cube” (Sportfiets.type, onttrokken aan lijst Sportfiets typen)

Mogelijk geen waarde

Van sommige modelelementen wordt vooraf al bepaald dat deze mogelijk geen waarde krijgen in registratie of uitwisseling. Reden kan zijn dat de informatie nog niet beschikbaar is, dat deze niet bekend mag worden gemaakt of wegens iets anders niet wordt opgenomen. Als dat op modelniveau al bekend is, wordt dat gesignaleerd door dit metagegeven op “Ja” te zetten.

Voorbeeld:

“Ja” (Adres.huisnummer) - Van een Contact kan het huisnummer wegelaten worden als deze informatie niet wordt gegeven door de klant, of in uitwisseling met derden. De informatie hoort er wel te zijn maar is niet beschikbaar.

Zie ook: .

Identificerend

Om te kunnen verwijzen naar een objecttype heb je iets nodig dat voldoende onderscheidend en stabiel is: een identificerende eigenschap. Soms betreft het zelfs een combinatie van eigenschappen, en in extreme gevallen kan zelfs een relatiesoort (mede-) identificerend zijn. Als een attribuutsoort of relatiesoort een rol speelt in de identificatie krijgt het dit metagegeven.

Voorbeeld:

Contact.naam identificerend = “Ja”

Zie ook: .

Al eerder besproken metagegevens van attribuutsoort zijn: Alias, Begrip, Herkomst, Definitie, Herkomst definitie, Datum opname, Toelichting.

Gegevensgroeptype

Wanneer we een aantal samenhangende Attribuutsoorten als groepje willen gebruiken (bijvoorbeeld het groepje is optioneel, of voor het groepje houden we een gemeenschappelijke historie bij) kunnen we het als Gegevensgroeptype opnemen. Het betreft dan niet een Objecttype: het is geen constructie waar we over praten als zelfstandig concept (het is dus ook typisch niet identificeerbaar), en we kunnen er ook geen relaties (Relatiesoort) naar toe leggen. Het betreft dus écht alleen maar een groepje attributen.

Voorbeeld is het Gegevensgroeptype Adres. Een adres is vanuit het perspectief van de fietsenwinkel geen “concept” waarover wordt gecommuniceerd; het is wel een groepje attributen: postcode, huisnummer, locatie. Als het adres verandert veranderen deze gegevens als groepje.

Het is mogelijk dat meerdere objecttypen een Gegevensgroeptype delen. Het is dus niet voorbehouden aan één Objecttype.

Van een Gegevensgroeptype leggen we het volgende vast:

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek binnen het model waar het deel van uitmaakt.

Voorbeeld:

“Adres” (een Contact.postadres is een Adres).

Zie ook: .

Al eerder besproken metagegevens van attribuutsoort zijn: Alias, Begrip, Herkomst, Definitie, Herkomst definitie, Datum opname, Toelichting.

Gegevensgroep

Een Gegevensgroep is een modelelement naast de Attribuutsoort, die kan worden toegekend aan een Objecttype. Het type is altijd een Gegevensgroeptype.

Van een Gegevensgroep leggen we het volgende vast:

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek binnen het Objecttype of Gegevensgroeptype waar het deel van uitmaakt. De naam van de gegevensgroep geeft aan welke “rol” de attributen hebben die als groep worden aangekoppeld.

Voorbeeld:

“postadres” (een Contact.postadres is een Gegevensgroep, en is van type Gegevensgroeptype)

Zie ook: .

Gegevensgroeptype

Het type van de groep.

Voorbeeld:

Contact.postadres is een Adres

Al eerder besproken metagegevens van gegevensgroep zijn: Alias, Begrip, Herkomst, Definitie, Herkomst definitie, Datum opname, Toelichting, Indicatie materiële historie, Indicatie formele historie, Kardinaliteit, Authentiek

Relatiesoort

Een relatie tussen twee objecttypen wordt een relatiesoort genoemd. Die relatie kan direct bestaan (een fiets wordt verkocht aan een klant) of via een keuze worden gerealiseerd (een contact kan betalen met Creditcard of Bankrekening). Het is niet mogelijk een relatie te leggen met een datatype, en het is ook niet mogelijk een objecttype te relateren met een ander objecttype middels een attribuutsoort. In deze zin vullen beide modelelementen elkaar aan.

Relaties kunnen exclusief zijn, maar ook gedeeld. In de UML wereld zijn dit compositie, aggregatie of gewone relaties. MIM legt hierin geen beperkingen op.

Voorbeeld:

In het Fietswinkel voorbeeld is een gewone relatie getrokken van Fiets naar Klant, en een compositie relatie van Fiets naar Batterij.

Van een Relatiesoort leggen we het volgende vast:

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek voor het objecttype welke als bron van de relatie is opgenomen.

Voorbeeld:

“verkocht aan” (Fiets.verkocht_aan Klant)

Zie ook: .

Unidirectioneel

Een relatie tussen twee objecttypen kan alleen “zichtbaar” zijn vanuit één van beide. Een Fiets wordt verkocht aan een Klant, en van een Klant is bekend welke Fietsen zijn aangeschaft. De relatie is niet unidirectioneel. Een Klant kan ook een betaling doen met een Creditcard. Deze relatie gaat wel één richting op: Klant heeft een relatie met Creditcard. Dat in de werkelijkheid ook een andersom relatie bestaat is niet relevant voor het informatiemodel waar we naar kijken. Het is misschien mogelijk (in een technisch systeem) een bevraging te doen “welke personen horen bij deze creditcard” maar dat speelt voor het model geen rol. Om dat expliciet te maken wordt deze relatie gericht. MIM schrijft dus niet voor dat relaties gericht moeten zijn. Dat is per relatie vast te stellen.

Voorbeeld:

Unidirectioneel = “false” (Fiets “verkocht aan” Klant) - een niet-gerichte relatie

Zie ook: .

Relatie eigenaar

De relatie heeft een bron (eigenaar) en een doel. TODO

Zie ook: .

Relatie doel

De relatie heeft een bron (eigenaar) en een doel. TODO

Zie ook: .

Aggregatietype

Dit is de aanduiding of het doel een onderdeel is van de eigenaar. Aggregatietype is Geen, Gedeeld of Compositie, en dit principe volgt UML aggregatie. Standaard betreft de relatie tussen twee objecten niet deel/geheel: Een specifieke Eigenaar heeft een bepaalde Hond, beiden blijven bestaan als een van beiden wegvalt (we praten dus op data-niveau). De Hond heeft zijn Staart: dit is een compositie relatie. Als de hond wegvalt, valt de staart ook weg. Een deel kan niet exclusief voor het geheel zijn (gedeeld): meerdere Personen hebben dezelfde Betaalrekening maar als een Persoon wegvalt, vervalt niet per definitie ook de Betaalrekening.

Voorbeeld:

Fiets wordt aangestuurd door Batterij (als een Fiets type vervalt, vervalt ook de Batterij)

Zie ook: .

Kardinaliteit

Zie Kardinaliteit. De kardinaliteit van een relatie wordt geplaatst op het doel van de relatiesoort. MIM stelt (nog) niet dat ook de bron een kardinaliteit kan hebben.

Zie ook: .

Bron

TODO

Doel

TODO

Externe koppeling

TODO

Zie ook: .

Andere eerder besproken metagegevens van relatiesoort zijn: Alias, Begrip, Herkomst, Definitie, Toelichting, Herkomst definitie, Datum opname, Indicatie materiële historie, Indicatie formele historie, Authentiek, Indicatie afleidbaar, Mogelijk geen waarde.

Relatieklasse

TODO

Eigenschappen geven aan modelelementen

Objecttypen, Gegevensgroeptypen en Gestructureerde datatypen hebben eigenschappen met waarden. Voor de eerste twee krijgt dat de vorm van attribuutsoorten; voor de laatste betreft het een Data element. Deze eigenschappen hebben een datatype: het typenummer van een fiets is een tekenreeks (CharacterString), de verkoopdatum is een datum (Date).

Het type van de data die kan worden toegekend kies je uit een reeks vooraf gedefinieerde typen, een waarde uit een lijst, of een eigen datatype:

Primitief datatype

Een primitief datatype is een datatype zonder verdere specificatie over haar structuur. Zo’n type representeert een waarde, zoals een integer getal of een datum. Je kunt zelf primitieve typen maken, en een aantal primitieve typen is voor gedefinieerd door de MIM standaard.

Van een Primitief datatype leggen we het volgende vast:

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek voor het type binnen het model.

Voorbeeld:

“Garantienummer” en “IBAN” zijn subtype van CharacterString.

Zie ook: .

Eigenlijk introduceert Primitief type niks nieuws, het heeft de eerder besproken metagegevens: Begrip, Definitie, Lengte, Patroon, Formeel patroon, Herkomst, Datum opname.

Een voorbeeld van een eigen gedefinieerd primitief type is het Garantienummer: een CharacterString. We willen garantienummers als zelfstandige concepten in het model kunnen gebruiken; dat is op zich voldoende basis voor het introduceren van zo’n type. Een ander voorbeeld is IBAN, waarvoor een zeer specifiek patroon is vastgesteld. Er is dan een meer technische reden om dit type te introduceren.

De MIM standaard definieert een aantal standaard typen, altijd beschikbaar voor ieder model. De MIM standaard behandelt deze datatypen in een aparte sectie . Enkele belangrijke typen zijn:

Datatype

Uitleg

CharacterString

Een tekenreeks. Een lege CharacterString is mogelijk.

Voorbeeld:

“Cube Attain SL” - De naam van een fiets (Fiets.naam)

Integer

Een geheel getal.

Voorbeeld:

“22” (Fiets.versnellingen) – Het aantal versnellingen.

Decimal

Een gebroken getal. Dit is een exact getal, zoals de prijs van een fiets in Euro’s.

Voorbeeld:

Verkoopprijs is “899,00” (Fiets.verkoopprijs)

Real

Een gebroken getal, dat niet exact vast te stellen is. Coördinaten op een kaart zouden als Real kunnen worden getypeerd, omdat die soms berekend worden op basis van andere coordinaten.

Voorbeeld:

TODO

Boolean

Waar of niet waar. Dit zijn waarden True of 1, of False of 0. Er is besloten geen Ja of Nee te accepteren als booleaanse waarde.

Voorbeeld:

Nieuwsbrief = “True” (Klant.nieuwsbrief)

Date

Een datum. De datum heeft een vaste opbouw: yyyy-mm-dd.

Voorbeeld:

Verkoopdatum = “2020-11-07” (Verkoop.verkoopdatum) is 7 november 2020.

URI

Een standaard methode om via Internet objecten te identificeren: de URI moet zijn opgebouwd conform de URI-strategie Linked Open Data.

Voorbeeld:

TODO

Andere typen zijn DateTime, Year, Day, Month, deze behandelen we hier niet.

Gestructureerd datatype

Een Gestructureerd type heeft meerdere benoemde data elementen die samen een waarde vormen. Zo is “1 liter” opgebouwd uit “aantal” en “eenheid”. Hoe dan ook identificeert “1 liter” een waarde.

Een voorbeeld van een gestructureerd type in ons informatiemodel is de omvang van een Fiets (Fiets.omvang) als type Dimensies: lengte is 1900, breedte is 350, hoogte is 1200 (de dimensies van een fiets, in mm). Ook een Batterij kent een omvang.

MIM introduceert zelf geen gestructureerde datatypen. Deze moet je overnemen van andere modellen, of zelf maken, zoals we dat met Dimensies hebben gedaan.

Van een Gestructureerd datatype leggen we het volgende vast:

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek voor het type binnen het model.

Voorbeeld:

“Garantienummer” is subtype van CharacterString.

Zie ook: .

Eigenlijk introduceert Gestructureerd datatype niks nieuws, het heeft de eerder besproken metagegevens: Begrip, Definitie, Patroon, Formeel patroon, Herkomst, Datum opname.

Data element

Een data element is een waarde in een Gestructureerd datatype.

Van een data element leggen we het volgende vast:

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek voor het Gestructureerd datatype.

Voorbeeld:

“lengte” is een data element van Dimensies.

Zie ook: .

Eigenlijk introduceert Data element niks nieuws, het heeft de eerder besproken metagegevens: Begrip, Definitie, Type, Lengte, Patroon, Formeel patroon, Kardinaliteit.

Interface

Een interface is een modelelement dat voorkomt in een extern package. Het is een verwijzing naar een datatype, objecttype of ander modelelement dat buiten het informatiemodel zelf is gedefinieerd. Voorbeelden zijn TODO

De naam van de interface keert veelal terug op plekken waar een datatype wordt toegekend. Het representeert dan dus een extern datatype: GM_Surface (in GML package), Boolean (in MIM package), et cetera. Daarom nemen we het hier op.

Van een interface leggen we het volgende vast:

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek voor het Externe package waar het in is opgenomen.

Voorbeeld:

TODO

Zie ook: .

Lijsten van waarden

Een attribuut van een object heeft altijd een waarde. Deze kan zijn onttrokken aan een lijst van mogelijke waarden. Deze lijst kan zijn opgegeven binnen het informatiemodel, of daarbuiten ergens beschikbaar zijn, bijvoorbeeld op het web. Deze lijst kan, wanneer ze toegankelijk is voor een verwerkend systeem, worden uitgelezen, en er kan een check worden gedaan of de waarde acceptabel is. De waarde fungeert dan als “sleutelwaarde”. Aan deze sleutel kunnen andere waarden zijn gekoppeld.

Er worden drie soorten lijsten onderscheiden door het MIM, en deze worden hieronder besproken.

Sleutelwaarde is opgenomen in model

Aan sleutelwaarde hangen andere waarden

Model stelt vast welke waarden relevant zijn

Enumeratie

Ja

Nee

n.v.t.

Referentielijst

Ja

Ja

Ja

Codelijst

Ja

Mogelijk

Nee

Enumeratie

Een enumeratie is een vaste lijst van waarden die onderdeel is van het informatiemodel: als je de lijst aanpast ontstaat een nieuwe versie van het model. Je introduceert een enumeratie dus met name als de lijst niet uitbreidbaar is, en de waarden bepalend zijn voor het verwerken van de informatie.

Voorbeeld is de lijst Sportfiets typen. Er is slechts een beperkt aantal typen fietsen, en als in dat lijstje aanpassingen worden doorgevoerd kan dat effect hebben op de rest van het model. Bijvoorbeeld doordat daardoor nieuwe attributen op Batterij een rol zouden kunnen gaan spelen.

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek voor de lijst binnen het model.

Voorbeeld:

De waarde van Sportfiets.type komt uit de lijst Sportfiets typen

Zie ook: .

Al eerder besproken metagegevens van enumeratie zijn: Begrip, Definitie.

Enumeratiewaarde

De enumeratiewaarde is de “karakterreeks” die de betreffende waarde representeert. Voorbeeld is “man” (Geslacht), “Rood” (Kleur), of “Giant” (Fiets type).

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek voor Enumeratie waar het in zit.

Voorbeeld:

De waarde van Sportfiets.type komt uit de lijst Sportfiets typen

Zie ook: .

Code

TODO

Al eerder besproken metagegevens van enumeratie zijn: Definitie. TODO zie https://github.com/Geonovum/MIM-Werkomgeving/issues/191

Referentielijst

Een waarde kan ook worden onttrokken aan een referentielijst. In dat geval heeft een verandering in die lijst geen invloed op de wijze waarop het model moet worden begrepen. De introductie van nieuwe kleuren in een kleurenstaal heeft geen effect op de wijze waarop je de kleurenstaal kunt gebruiken. In ons voorbeeld is een KvK lijst opgenomen: veranderingen in die lijst van bedrijven (toegankelijk via KvK nummer) hebben geen impact op het model.

Een referentielijst heeft Referentie elementen, die je je kunt voorstellen als kolommen in een tabel (de lijst). De kop van de kolom is het data element, de rijen beschrijven één waarde. Iedere cel is één aspect van die waarde, bijv. code, naam in het Nederlands, naam in het Engels, omschrijving.

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek voor het model waar het in zit.

Voorbeeld:

De leverancier van een fiets wordt bepaald a.d.h.v. een referentielijst KvK lijst.

Zie ook: .

Locatie

Referentielijsten worden altijd buiten het model beheerd. Veelal is er een web-toegang tot die lijst (uitlezen via http connectie), maar ook andere technische of niet-technische representaties kunnen voorkomen.

Voorbeeld:

De locatie van de Referentielijst KvK Lijst is een webadres: https://services.kvk.nl/zoeken/handelsregister/ d.w.z. door deze URL te volgen met de juiste parameters en rechten is bedrijfsinformatie op te vragen.

Al eerder besproken metagegevens van enumeratie zijn: Alias, Begrip, Definitie, Herkomst, Datum opname, Toelichting.

Referentie-element

Zoals beschreven bestaat een referentielijst uit referentie elementen. Deze leggen vast hoe de beschikbare gegevens in de lijst zijn opgedeeld.

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek voor de referentielijst waar het in zit.

Voorbeeld:

KvK lijst.bedrijfsnaam

Zie ook: .

Identificerend

Voorbeeld:

Er is altijd een kolom in de referentielijst die de sleutelwaarden bevat waaronder de gegevens op te halen zijn. Dat referentie-element kan men expliciet aanduidend d.m.v. het metagegeven “Identificerend”. Zo is in de referentielijst Kvk lijst het element Kvk lijst.nummer identificerend.

Zie ook: .

Al eerder besproken metagegevens van referentie-element zijn: Alias, Begrip, Definitie, Datum opname, Toelichting, Kardinaliteit, en domein eigenschappen: Type, Lengte, Patroon en Formeel patroon.

TODO zie https://github.com/Geonovum/MIM-Werkomgeving/issues/192

Codelijst

Een codelijst is een soort Referentielijst, maar de opbouw daarvan wordt niet nader gespecificeerd. In feite wordt van een codelijst alleen gesteld dat de waarden ergens buiten het model vastliggen, maar niet op welke manier (met “welke kolommen”, zoals bij referentielijst). De codelijst heeft, anders dan bij enumeraties, dus ook geen waarden die in het model zélf zijn opgenomen.

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek voor het model waar het in zit.

Voorbeeld:

De Ketting lijst is een externe lijst van kettingen. In uitwisseling wordt een code die aan de kettinglijst is ontleend opgenomen.

Zie ook: .

Al eerder besproken metagegevens van codelijst zijn: Alias, Begrip, Definitie, Herkomst, Datum opname, Toelichting en Locatie.

Keuzen

In de specificatie van het MIM zijn er allerlei “keuzen” opgenomen. In ons fietsenwinkel voorbeeld kan worden gekozen tussen een Klant of een Leverancier wanneer een Contact wordt bedoeld. Dit is inherent aan subtypering in MIM: een situatie waarin een supertype een rol speelt heeft ook betrekking op haar subtypen.

Een ander soort keuze is het opnemen van een betaling via een creditcard of een bankrekening. We kunnen dit modelleren door beide op te nemen als optioneel attribuutsoort van een objecttype (“betaling”). Feitelijk wordt hier dan een keuze bedoeld.

In de standaard zijn keuzen toch explicieter gemodelleerd. We introduceren daarom meerdere soorten keuzen: keuzen tussen attribuutwaarden (lees: datatypen), keuzen tussen attributen, en tussen relaties. Dit houdt andere methoden om keuzen vast te stellen niet tegen.

Metagegeven

Uitleg

Naam

Zie Naam. Deze naam is uniek voor het model waar het in zit.

Zie ook: .

Al eerder besproken metagegevens van Keuze zijn: Begrip, Definitie, Herkomst, Datum opname.

Keuze tussen datatypen

Een keuze tussen datatypen houdt in dat de waarde van een attribuutsoort (of data element) ofwel van het ene datatype is, of van het andere (of van een derde…). Een typisch voorbeeld is: de geografische locatie van een adres is een punt op de kaart (de voordeur, of een middelpunt), of de omtrek van het pand. Welke het wordt is afhankelijk van welke gegevens beschikbaar zijn.

Voorbeeld:

Geografische locatie is een keuze tussen punt en vlak. Voor Adres.locatie kan deze keuze worden gemaakt.

N.B. Uitgangpunt is wel dat het type van het attribuut wel kan worden bepaald: is een ingevoerde waarde “20” een getal of een alfanumerieke waarde? Dat valt buiten de MIM standaard maar is in uitwisseling wel essentieel.

Keuze tussen attribuutsoorten

Het kan ook zijn dat de keuze niet het datatype van een attribuutsoort betreft, maar juist wélk attribuutsoort van toepassing is. Zoals eerder gesteld kun je twee attribuutsoorten optioneel maken en erbij documenteren dat men één van beide moet kiezen. Het is dan toch duidelijker om die keuze in het model expliciet te maken door middel van een modelelement Keuze.

De namen van de attribuutsoorten moeten uniek zijn binnen alle Objecttypen waarin de keuze wordt opgenomen.

Voorbeeld:

Fiets.aandrijving is een keuze tussen een ketting- of snaaraandrijving. Dit is vervat in de keuzeklasse Aandrijving. Elk van de attribuutsoorten heeft een eigen lijst van mogelijke waarden.

Keuze tussen objecttypen

Ook als een relatie wordt gemodelleerd waarin een keuze uit meerdere Objecttypen als relatie-doel wordt bedoeld, wordt een Keuze modelelement opgenomen. Dit modelelement heeft keuze-relaties met alle mogelijke objecttypen. Deze relaties hebben geen kardinaliteit maar wel een naam en andere metagegevens.

Voorbeeld:

Een voorbeeld is de Contact.betaling: dit is de keuze klasse Betaalmiddel.

Betaalmiddel.credit verwijst naar Creditcard, Betaalmiddel.bank verwijst naar Bankrekening.

Metagegevens

TODO algemene introductie

Naam, alias en begrip

TODO Test voorbeeld: link naar view package | bijlage-fietsenwinkel| bijlage-informatiemodel-fietsenwinkel

De metagegevens naam, alias en begrip komen vaak terug in deze Pimer. Het zijn drie metagegevens die elkaar aanvullen. In de MIM standaard zijn een aantal afspraken en regels opgesteld over de invulling van deze metagegevens.

Een naam geeft een korte omschrijving van het modelelement. De invulling van een naam moet volgens MIM voldoen aan een aantal naamgevingsconventies . Zo moeten bijvoorbeeld Objecttypen een unieke naam hebben binnen het informatiemodel. Ook kan er een keuze worden gemaakt tussen natuurlijke taal of machine leesbare taal. Het is een gebruikelijk dat natuurlijke taal wordt gebruikt binnen een Conceptueel informatiemodel en machine leesbare taal binnen een Logisch informatiemodel . Binnen het Conceptueel informatiemodel Fietsenwinkel, wordt bijvoorbeeld natuurlijke taal gebruikt.

Voorbeeld:

Het gebruik van natuurlijke taal kun je bijvoorbeeld terug zien in informatiemodel Fietsenwinkel bij de Relatiesoort verkocht aan. In machine leesbare taak zou deze naam iets als “verkochtAan” worden.

Een alias is een alternatieve benaming voor een modelelement. In de praktijk wordt dit metagegeven op verschillende manieren gebruikt. Het kan bijvoorbeeld gebruikt worden om zowel een natuurlijke als een machine leesbare taal in het model op te nemen. Daarnaast zou het ook gebruikt kunnen worden om de naam in een andere taal op te nemen in het model. In dit laatste geval, kan er wel maar 1 extra taal worden opgenomen, aangezien het metagegeven alias maar maximaal 1 keer mag voorkomen. Het optionele metagegeven alias op veel verschillende manieren worden toegepast. Om deze reden is het goed om in de documentatie van het informatiemodel toe te lichten waarvoor het alias is gebruikt

Voorbeeld:

In het informatiemodel Fietsenwinkel zou voor de attribuutsoort met de Naam “Fiets”, in het metagegeven alias “Bike” kunnen worden ingevuld.

Wanneer buiten het informatiemodel, ook een model van begrippen (een thesaurus) wordt gehanteerd, bied MIM via het metagegeven begrip de optie om hier een relatie mee te leggen. In het begrip metagegeven wordt de URI opgenomen van 1 of meerdere begrippen waarmee het modelelement een semantische relatie heeft. Wanneer twee dingen een semantische relatie hebben, dan is er een verband tussen de betekenis van deze twee dingen. In MIM wordt het verwijzen naar begrippen nader toegelicht in deze paragraaf .

Voorbeeld:

In het informatiemodel Fietsenwinkel zou voor de attribuutsoort met de naam “Fiets”, bijvoorbeeld worden verwezen naar de URI: “https://nl.wikipedia.org/wiki/Fiets ”.

Kardinaliteit en mogelijk geen waarde

Het metagegeven kardinaliteit in MIM geeft aan hoeveel keer waarden van een kenmerk mogen voorkomen binnen een objecttype. In de praktijk zien we dit metagegeven terug bij attribuutsoorten en relatiesoorten tussen objecttypen. In de MIM standaard wordt toelichting gegeven over de notatie van een kardinaliteit. De notatie [0..*] wordt hier bijvoorbeeld gebruikt om uit te drukken dat het kenmerk 0 of meerdere keren voorkomt.

De termen kardinaliteit en multipliciteit worden in het werkveld vaak door elkaar heen gebruikt. In de UML Reference Manual wordt multipliciteit gedefinieerd als een specificatie van het toegestane bereik van kardinaliteitswaarden. Wanneer we deze definitie aanhouden, is de notatie van “[0..*]” is multipliciteit met daar daarin de kardinaliteit “0” als ondergrens en de kardinaliteit “*” (lees “meer”) als bovengrens.

Voorbeeld:

Zie domein Inventaris. In dit domein valt te zien dat het Objecttype “Winkel” een relatiesoort “verhandelt” heeft met het Objecttype “Fiets”. Het doel van deze relatiesoort “verhandelt” heeft een metagegeven kardinaliteit (multipliciteit) met de waarde “[0..*]”. Wanneer er niks wordt ingevuld is de kardinaliteit van een kenmerk 1. Bij de bron van Relatiesoort “verhandelt” is niks ingevuld, dus is de kardinaliteit “1”. Dit betekent dat 1 winkel 0 of meerdere fietsen verhandelt.

Als een kenmerk een kardinaliteit 0 heeft, is dit iets anders dan wanneer een kenmerk geen waarde heeft. De situatie dat een fietsenwinkel nog 0 fietsen verhandelt, kan bijvoorbeeld voorkomen wanneer een nieuwe winkel nog assortiment moet inkopen. Het metagegeven “mogelijk geen waarde ” geeft aan dat een kenmerk in de werkelijkheid wel moet voorkomen, maar dat deze informatie mogelijk niet beschikbaar is.

Voorbeeld:

Zie voor meer toelichting over het gebruik van mogelijk geen waarde de paragraaf hierover in het hoofdstuk Afspraken & Regels.

Herkomst en datum opname

TODO alle herkomsten en datum opname

Definitie en toelichting

TODO definitie, toelichting

Identificatie en afleidbaarheid

TODO unieke aanduiding, identificerend, classificerend, indicatie afleidbaar

Populatie en kwaliteit

TODO populatie, kwaliteit

Domeinwaarden

TODO domein kernmerk, plus type, lengte, patroon, formeel patroon etc.

Historie

TODO materiele en formele historie?

Relaties en rollen

TODO relatie unidirectioneel, aggregatietype, relatie eigenaar en doel, generalisatie

Maak een keuze uit deze alternatieven .

Uitbreiding van het metamodel

Een MIM model is een beschrijving van een snapshot van dat informatiemodel – een moment in de tijd waarop het model was vastgesteld. Maar inzichten veranderen en ook modellen veranderen. We hebben daarom in de praktijk vaak versie-informatie nodig op het informatiemodel, de domeinen en misschien zelfs op modelelementen zoals objecttypen en relaties. Dat vereist uitbreiding van het metamodel, bijvoorbeeld met een release naam, een versienummer, een fase waar deze versie in bevindt (klad, eindversie), auteursinformatie, e.d. Zulke constructies kunnen door middel van extensies worden toegevoegd. Ze vormen géén onderdeel van het MIM.

Uitbreidingen worden soms gerealiseerd door het toevoegen van kenmerken, bijvoorbeeld:

Uitbreidingen kunnen ook de vorm van nieuwe modelelementen krijgen, bijvoorbeeld:

Uitgangspunt is dat het aantal extensies beperkt blijft. Wanneer zo’n extensie wordt geïntroduceerd is het zaak dit in een breder verband aan te melden zodat nieuwere versies van MIM er hun voordeel mee kunnen doen.

Betrokken personen

TODO Primer

TODO Standard

Referenties

TODO literatuur

Bijlagen

TODO

Bijlage: Overzicht van modelelementen

TODO genereren vanuit Imvertor

Bijlage: Overzicht van metagegevens

TODO genereren vanuit Imvertor

Bijlage: Demonstrator

De Demonstrator is een software product waarmee op eenvoudige manier een MIM informatiemodel kan worden bekeken, of zelfs kan worden opgebouwd. Het geeft een intuïtieve toegang tot deze Primer en de standaard. Het is niet bedoeld als productie-software.

Demonstrator screenshot

De Demonstrator heeft nu nog de alfa status, dus is functioneel en technisch nog in ontwikkeling. De Demonstrator is benaderbaar via:

https://imvertor-tst.armatiek.nl/demonstrator

TODO meer info over hoe en wat van demonstrator

Bijlage: Informatiemodel Fietsenwinkel

TODO