let ip: in deze mail staan een serie issues vermeld die als feedback van de consultatie van 1.2 in behandeling worden genomen.
hier gaar het om de hoofdlijn van de mail inzake de oproep om naar een versie 2.X te gaan.
Beste Dick,
De reviewperiode van MIM 1.2 is afgerond. Als schrijver van een deel van het MIM vond ik het zelf niet zo passend om zelf een review van MIM 1.2 op te sturen, wel heb ik meegeholpen aan de review vanuit de Politie.
Vandaar ook even deze email. Als ik kijk naar MIM 1.2 dan zijn er goede verbeteringen doorgevoerd die laten zien dat MIM een volwassen standaard is waarbij zorgvuldig aan optimalisaties wordt gewerkt.
Ik merk echter dat MIM toe is aan een 2.x. Het originele gebruik van MIM, door met name de Geo-community, heeft inmiddels een veel bredere gebruikersgroep gekregen die elk op hun eigen manier naar het MIM kijkt.
Zo gebruikt de Politie vooral de opdeling in lagen (MIM 1 t/m 4) en past zij direct de vertaling naar LInked Data toe (sectie 6.4, dwz: zij gebruiken niet mim:Objecttype, maar direct sh:Nodeshape en owl:Class).
Ook zie ik behoeften van andere organisaties om MIM toe te passen voor conceptueel informatiemodelleren en logisch gegevensmodelleren, maar kennen deze organisaties het gebruik van andere afbeeldingsvormen (Entiteit-Relatie (ER) diagrammen of Fact-based-modelling (FBM) om de belangrijkste twee te noemen). MIM wordt door deze organisaties vooral gezien als een manier van logisch modelleren (MIM-3), en zij stellen (goede) vragen hoe je MIM moet interpreteren als sprake is van een conceptueel model (MIM-2).
Met Jesse heb ik meegewerkt aan enkele verbeteringen van MIM 1.2 die impact hadden op het MIM-in-LD hoofdstuk (hoofdstuk 4), die direct bij mij vragen oproepen. Dit heeft eigenlijk altijd te maken met het feit dat het metamodel van MIM 1.x, hoewel abstract beschreven in hoofdstuk 2, nog is gestoeld op een eerste verkenning door KING/Kadaster/KvK/Geonovum en eigenlijk alleen aangevuld, zonder echt goed naar de kern van dit metamodel te kijken. Het gevolg is dat er vrijheid (en daardoor onduidelijkheid) bestaat bij het toepassen van het metamodel en daarmee met het toepassen van MIM. Het is denkbaar dat er twee partijen hetzelfde MIM model maken, maar er iets anders mee bedoelen.
Dit is allemaal niet heel erg, zolang MIM een aanbevolen standaard is en MIM vooral binnen één organisatie wordt ingezet. Maar juist het MIM biedt meerwaarde als veel organisaties er gebruik van gaan maken en organisaties ook gebruik kunnen maken van elkaars modellen (zo is de Belastingdienst nu veel tijd kwijt met het modelleren van de BAG, de BRK en de WOZ, terwijl hier al goede MIM modellen voor beschikbaar zijn (!)).
Open issues
Ik heb hier in het verleden ook al bevindingen voor opgevoerd. Deze zijn voor MIM 1.2 niet opgepakt voor zover ik kan zien (op de issue log staan ze nog op open, en in de documentatie kan ik geen wijzigingen zien die hier betrekking op hebben). Het betreft de volgende issues:
348 MIM Respec documenten zijn niet leesbaar bij diverse organisaties
289 De betekenis van mim:locatie is niet consistent doorgevoerd
288 Transformatie indicatie abstract object te strikt
286 Inconsistente naamgeving keuzeattribuut, keuzerelatiedoel (sectie 2.8.4.12 en 2.8.4.13)
285 Foutieve verkorte naam voor "heeft enumeratiewaarde" (sectie 2.8.4.9)
284 Onduidelijkheid over de betekenis van "heeft relatiesoort" (sectie 2.8.4.6)
283 Onduidelijkheid over de betekenis van "heeft datatype" (sectie 2.8.4.5)
282 Incorrecte spelling: "Informatiemodel type"
231 Metamodel: de betekenis van "eigenaarschap" zit niet heel lekker in het model
230 Transformatie "Keuze" is niet compleet y-issue
39 Aspecten beschrijven per objecttype, of overerving toepassen
(Merk op dat de meeste van deze issues zijn gemaakt toen versie 1.2 nog niet beschikbaar was, de referenties naar de sectie-nrs kunnen in 1.2 net wat anders zijn)
Voorstel
Ik denk dat het belangrijk wordt om te gaan werken aan MIM 2.x, of ten minste aan een versie van het MIM waarin gewerkt wordt aan een stevig metamodel. Dit als actie om van MIM een PToLU standaard te maken. Daarvoor zijn m.i. de volgende acties nodig:
Een stevig formeel metamodel dat als formele basis dient voor zowel de UML notatiewijze (hfdst 3), de LD notatiewijze (hfdst 4), de transformatie naar LD (sectie 6.4, en daarmee ook de uitwisselstandaard voor MIM in LD) en de uitwisselstandaard in platte-XML zoals door het Kadaster ontwikkelt.
De uitwerking van een voorbeeld aan de hand van dit stevig formeel metamodel dat vervolgens gebruikt kan worden als validatie-instrument voor de elementen genoemd in punt (1), en de basis is voor een MIM-primer;
Het beschikbaar stellen van open source programmatuur, gekeurmerkt door Geonovum, waarmee de validatie van het metamodel genoemd in punt (1) gedaan kan worden, alsmede de transformaties tussen de onderdelen van punt (1);
Optioneel: het voorbeeld dat in (2) genoemd is, uitbreiden met een MIM-1 model, op basis van de standaard voor het beschrijven van begrippen (https://profielstelselcatalogus.pldn.nl/), zodat de link tussen MIM-1 en MIM-2/3 goed uitgebeeld kan worden;
Optioneel: MIM uitbreiden met notatiewijzen voor ER en FBM, zodat ook partijen die deze twee notatiewijzen gebruiken voor conceptueel en logisch modelleren, MIM-conform kunnen werken.
Punt (4) en (5) zijn optioneel, want strikt geen onderdeel van MIM. Wel denk ik dat het goed is om deze onderdelen uit te (laten) voeren, liefst vanzelfsprekend door auteurs die hier zelf het meeste verstand van hebben. Op die manier laat je de gehele samenhang van MIM zien, zoals deze ook wordt toegepast bij de diverse overheidsorganisaties.
Met betrekking tot punt (3): De meeste open source programmatuur is al beschikbaar, de belangrijkste stap is het gekeurmerkt krijgen door Geonovum (dwz: opnemen in de Geonovum-repo, voorzien van een kwaliteitslabel, laten gebruiken en uittesten door gebruikers). Pano, Jesse en ik weten hier meer van, mocht je vragen hebben.
Ik zou graag meehelpen aan bovenstaande punten. Ik merk dat ik hier ook steeds meer last van krijg in het toepassen van MIM, dus ook belanghebbende 😊
Voor punt (5) heb ik wel twee partijen in beeld die mogelijk mee zouden kunnen werken aan resp. een ER dan wel een FBM invulling.
mail Marco Bratttinga
let ip: in deze mail staan een serie issues vermeld die als feedback van de consultatie van 1.2 in behandeling worden genomen.
hier gaar het om de hoofdlijn van de mail inzake de oproep om naar een versie 2.X te gaan.
Beste Dick,
De reviewperiode van MIM 1.2 is afgerond. Als schrijver van een deel van het MIM vond ik het zelf niet zo passend om zelf een review van MIM 1.2 op te sturen, wel heb ik meegeholpen aan de review vanuit de Politie.
Vandaar ook even deze email. Als ik kijk naar MIM 1.2 dan zijn er goede verbeteringen doorgevoerd die laten zien dat MIM een volwassen standaard is waarbij zorgvuldig aan optimalisaties wordt gewerkt.
Ik merk echter dat MIM toe is aan een 2.x. Het originele gebruik van MIM, door met name de Geo-community, heeft inmiddels een veel bredere gebruikersgroep gekregen die elk op hun eigen manier naar het MIM kijkt.
Zo gebruikt de Politie vooral de opdeling in lagen (MIM 1 t/m 4) en past zij direct de vertaling naar LInked Data toe (sectie 6.4, dwz: zij gebruiken niet mim:Objecttype, maar direct sh:Nodeshape en owl:Class).
Ook zie ik behoeften van andere organisaties om MIM toe te passen voor conceptueel informatiemodelleren en logisch gegevensmodelleren, maar kennen deze organisaties het gebruik van andere afbeeldingsvormen (Entiteit-Relatie (ER) diagrammen of Fact-based-modelling (FBM) om de belangrijkste twee te noemen). MIM wordt door deze organisaties vooral gezien als een manier van logisch modelleren (MIM-3), en zij stellen (goede) vragen hoe je MIM moet interpreteren als sprake is van een conceptueel model (MIM-2).
Met Jesse heb ik meegewerkt aan enkele verbeteringen van MIM 1.2 die impact hadden op het MIM-in-LD hoofdstuk (hoofdstuk 4), die direct bij mij vragen oproepen. Dit heeft eigenlijk altijd te maken met het feit dat het metamodel van MIM 1.x, hoewel abstract beschreven in hoofdstuk 2, nog is gestoeld op een eerste verkenning door KING/Kadaster/KvK/Geonovum en eigenlijk alleen aangevuld, zonder echt goed naar de kern van dit metamodel te kijken. Het gevolg is dat er vrijheid (en daardoor onduidelijkheid) bestaat bij het toepassen van het metamodel en daarmee met het toepassen van MIM. Het is denkbaar dat er twee partijen hetzelfde MIM model maken, maar er iets anders mee bedoelen.
Dit is allemaal niet heel erg, zolang MIM een aanbevolen standaard is en MIM vooral binnen één organisatie wordt ingezet. Maar juist het MIM biedt meerwaarde als veel organisaties er gebruik van gaan maken en organisaties ook gebruik kunnen maken van elkaars modellen (zo is de Belastingdienst nu veel tijd kwijt met het modelleren van de BAG, de BRK en de WOZ, terwijl hier al goede MIM modellen voor beschikbaar zijn (!)).
Open issues Ik heb hier in het verleden ook al bevindingen voor opgevoerd. Deze zijn voor MIM 1.2 niet opgepakt voor zover ik kan zien (op de issue log staan ze nog op open, en in de documentatie kan ik geen wijzigingen zien die hier betrekking op hebben). Het betreft de volgende issues:
348 MIM Respec documenten zijn niet leesbaar bij diverse organisaties
289 De betekenis van mim:locatie is niet consistent doorgevoerd
288 Transformatie indicatie abstract object te strikt
286 Inconsistente naamgeving keuzeattribuut, keuzerelatiedoel (sectie 2.8.4.12 en 2.8.4.13)
285 Foutieve verkorte naam voor "heeft enumeratiewaarde" (sectie 2.8.4.9)
284 Onduidelijkheid over de betekenis van "heeft relatiesoort" (sectie 2.8.4.6)
283 Onduidelijkheid over de betekenis van "heeft datatype" (sectie 2.8.4.5)
282 Incorrecte spelling: "Informatiemodel type"
231 Metamodel: de betekenis van "eigenaarschap" zit niet heel lekker in het model
230 Transformatie "Keuze" is niet compleet y-issue
39 Aspecten beschrijven per objecttype, of overerving toepassen
(Merk op dat de meeste van deze issues zijn gemaakt toen versie 1.2 nog niet beschikbaar was, de referenties naar de sectie-nrs kunnen in 1.2 net wat anders zijn)
Voorstel Ik denk dat het belangrijk wordt om te gaan werken aan MIM 2.x, of ten minste aan een versie van het MIM waarin gewerkt wordt aan een stevig metamodel. Dit als actie om van MIM een PToLU standaard te maken. Daarvoor zijn m.i. de volgende acties nodig:
Punt (4) en (5) zijn optioneel, want strikt geen onderdeel van MIM. Wel denk ik dat het goed is om deze onderdelen uit te (laten) voeren, liefst vanzelfsprekend door auteurs die hier zelf het meeste verstand van hebben. Op die manier laat je de gehele samenhang van MIM zien, zoals deze ook wordt toegepast bij de diverse overheidsorganisaties.
Met betrekking tot punt (3): De meeste open source programmatuur is al beschikbaar, de belangrijkste stap is het gekeurmerkt krijgen door Geonovum (dwz: opnemen in de Geonovum-repo, voorzien van een kwaliteitslabel, laten gebruiken en uittesten door gebruikers). Pano, Jesse en ik weten hier meer van, mocht je vragen hebben.
Ik zou graag meehelpen aan bovenstaande punten. Ik merk dat ik hier ook steeds meer last van krijg in het toepassen van MIM, dus ook belanghebbende 😊
Voor punt (5) heb ik wel twee partijen in beeld die mogelijk mee zouden kunnen werken aan resp. een ER dan wel een FBM invulling.
Marco