MIM Extern - alternatieve oplossingen?

[pmaria]

We zien steeds meer de wens om federatief informatie te ontsluiten over verschillende datasets en domeinen heen. Daarbij komt ook de wens om meer naar verschillende informatiemodellen te kunnen verwijzen en semantische relaties te kunnen leggen tussen modelelementen uit die verschillende informatiemodellen.

Momenteel kun je modelelementen buiten jouw informatiemodel in een MIM-informatiemodel hergebruiken door deze in een apart package met stereotype <<Extern>> te plaatsen en er vervolgens naar te verwijzen.

Echter, dit <<Extern>> package zul je vrijwel altijd zelf moeten maken, omdat:

• informatiemodellen gemaakt wordt vanuit het perspectief van een domein, en de relevante modelelementen in een <<Domein>> package zullen worden gemodelleerd en beschikbaar worden gesteld.
• het extra werk is om een kopie te maken van de <<Domein>> packages en deze ook als <<Extern>> te publiceren voor hergebruik in andere modellen. Daarnaast levert dit ook nog dubbel beheerwerk op en is het foutgevoelig.

Zouden we een andere oplossing kunnen bedenken voor het kunnen verwijzen naar (modelelementen van) een extern model, waarbij het niet nodig is om deze te kopieren of aan te passen?

[PalmJanssen]

Bedoel je een systematiek dat je vanuit EA naar een extern (gepubliceerd) model (package) kan linken en importeren onder bijvoorbeeld SVN? Zonder dat je rechten hebt om het geimporteerde model aan te passen?

Wij publiceren nu de EAP.xmi van onze modellen voor import voor hergebruik. Maar een link zou inderdaad mooier zijn.

[pmaria]

Dat zou een deel van een oplossing voor werken in EA kunnen zijn inderdaad.

Maar ik bedoel eigenlijk dat we afstappen van het gebruik van packages van het type <<Extern>> en dat we op een andere manier externe modelelementen uit een ander informatiemodel kunnen verwijzen, zonder dat dat informatiemodel daarvoor iets hoeft te doen, of zonder dat er een (deel)kopieslag moet plaatsvinden van die externe modelelementen naar een andere structuur.

[ArjanLoeffen]

In Imvertor context worden informatiemodellen zo nodig bij elkaar onderbracht in één EA bestand, waarbij dan vanuit een willekeurig IM (ook een MIM model) verwezen kan worden naar een willekeurig ander IM (waaronder ook andere MIM modellen). Die verwijzing moet wel worden herkend door een achterliggende "mapping" van een naam (+ mogelijk identifier) naar een modelelement in een informatiemodel.

Voorbeeld is BRO dat verwijst naar Inspire, GML, OM, NEN2610, ..., die alle dan ook volledig zijn opgenomen in de EA files. BRO modellen verwijzen ook onderling naar elkaar. Nb. er zijn ongeveer 26 BRO informatiemodellen. Er wordt binnen BRO geen gebruik gemaakt van "Extern".

Ik vermoed dat het gebruik van "extern" dan ook niet noodzakelijk is, en een twijfelachtig deel van de standaard; beter is gewoon aan te geven dat informatiemodellen onderling naar elkaar kunnen verwijzen. De standaard zou misschien moeten spreken over een verzameling informatiemodellen ("informatielandschap"?) waarin allerlei modellen geïntegreerd kunnen worden; de standaard vertelt hoe.

[pmaria]

Bij het gebruik van de nieuwe NEN 3610 lopen we hier ook tegenaan. NEN 3610 heeft een MIM model waarin de modellen uiteraard in de eigen Domein package zijn opgenomen. We kunnen dit niet direct gebruiken in ons model. Er moet:

• of door onszelf een kopie worden gemaakt van de modelelementen en in een eigen Extern package in ons model geplaatst worden, onder ons beheer
• of door de beheerder van de standaard ook een herbruikbaar extern package worden aangeleverd.

Beiden oplossingen leveren kopieslagen, dubbelwerk, en risico's op fouten of het uit elkaar lopen van modellen.

[ArjanLoeffen]

@pmaria @PalmJanssen Ik heb een visie geschreven op deze problematiek nav. de MIM community meeting. Ik zou die visie met jullie willen delen. Kan ook in deze thread.

Maar ik denk dat het goed is daarvoor eens bij elkaar te komen en spijkers met koppen te slaan. Want het is een steeds belangrijker dingetje: vrij kunnen koppelen/verwijzen van model naar model, óver de modelgrenzen heen.

[ArjanLoeffen]

Notitie nav. presentatie Waarderingskamer: 20221002 Overwegingen bij het.pdf

Hier de kern.

Modellen en views

Informatiemodellen worden opgesteld om een specifiek domein af te dekken, en de informatiestructuren daarvan zo volledig mogelijk in kaart te brengen. Het domein moet voldoen aan praktische eisen. Analisten en ICTers die met dat informatiemodel aan de gang moeten, willen niets meer en niet minder dan dat wat relevant is voor hun eigen werkgebied terugvinden. Zo is er een domein Kadastrale registraties (volgens een Kadastraal model) en een domein Adressen en gebouwen (volgens een Adressenmodel). Voor bijvoorbeeld gemeenten is het Adressenmodel belangrijk en moet vrij gedetailleerd de lading dekken. Voor kadastrale toepassingen zijn niet al deze gegevens relevant. Het Kadastrale model wil “adressen” conform het Adressenmodel vastleggen: de analisten die dat domein hebben gemodelleerd weten er tenslotte het meeste vanaf. De Kadaster analist wil niet zelf het wiel uitvinden. Maar ook niet die hele complexe adressenwereld “naar binnen trekken”.
Het MIM introduceert daarom een View: een selectie die het Kadastrale model binnen het Adressenmodel maakt. Alle eisen die gelden voor het Adressenmodel zijn nog steeds van toepassing, maar er wordt een filter overheen gelegd, met name een selectie van objecttypen en kenmerken daarvan. Interessant daarbij is dat het Kadaster ook (alleen) de gemodelleerde informatie registreert. Dus van een adres wordt een specifiek deel vastgelegd in het kadasterproces. Dat deel is uitgedrukt in de view. Die informatie hoeft zelfs (nog) niet in lijn te zijn met bijv. de BAG registratie. Maar is het bij voorkeur wel.

Samengesteld model

Het kan ook zijn dat een model feitelijk een combinatie is van meerdere modellen, met mogelijk ook weer eigen sub-domeinen. In dat geval hebben we het eigenlijk over een “samengesteld model”. Misschien kunnen we de basisregistraties van Nederland alle tezamen wel als een samengesteld model van alle centrale gegevens opvatten. De gedachte is dat een samengesteld model alle informatie beschrijft die relevant kan zijn in gegevensregistratie en -uitwisseling. De Kadastrale registratie zoals beschreven kan ook worden opgevat als een onderdeel van dat samengestelde model. Dat het een View bevat op adressen is het resultaat van de focus die de kadastrale registratie heeft op percelen, en minder op adressen. Vanuit het perspectief van het samengestelde, nationale model is de view binnen het Kadastrale model niet relevant; een koppeling met het Adressenmodel is voldoende.

Nota bene: Een koppeling met een adres conform het Adressenmodel wordt op modelniveau gemaakt in de view, en op gegevensniveau middels een nationaal uniek adres-ID.

Rol van Imvertor

De software die deze MIM vormen moet ondersteunen heeft dus een uitdaging.

• (A) Zorg ervoor dat een view wordt ondersteund. Feitelijk is dat een MIM representatie van het model binnen het verwijzende model. Het is een “kopie” daarvan, maar daarbinnen is alles verwijderd dat geen rol speelt voor het werkdomein, en het bevat mogelijk extra restricties.
• (B) Zorg ervoor dat een samenstelling van modellen wordt ondersteund. Het moet dus mogelijk zijn meerdere complete modellen op te stellen, en onderlinge relaties te trekken. Voorbeeld: een pand op een perceel heeft een adres. Sta toe dat vanuit Kadastrale model (perceel) naar Adresmodel (adresseerbaar object) wordt verwezen.
• (C) Accepteer dat de samenstelling van modellen niet vereist dat alle modellen in dezelfde beheeromgeving beschikbaar zijn. Voorbeeld is het model voor geometrie: GML. Dat is nog niet beschikbaar als MIM model. Software moet dus toestaan te verwijzen naar deze modellen zonder deze integraal over te nemen.

Uitdaging A wordt door Imvertor geïmplementeerd. De verantwoordelijkheid voor de juistheid van de view ligt bij de analist, d.w.z. de samensteller van het model. Het is tot op zekere hoogte mogelijk dit in Imvertor te laten doorrekenen, wellicht via “afleiding” dat Imvertor nu reeds ondersteunt. Dat is echter nog niet als een eis geformuleerd.

Uitdaging B wordt nog niet door Imvertor geïmplementeerd. Het zou als effect kunnen hebben dat men twee modellen aanbiedt, en Imvertor vraagt daarvan één documentatie, één schema, etc. op te leveren. Met als uiterste consequentie dat er één documentatie komt van het domein van alle Nederlandse basisregistraties. Dit verzoek is nog nooit geformuleerd.

Uitdaging C wordt door Imvertor geïmplementeerd. Dat heeft de vorm van zgn. conceptual maps. Van een model (zoals GML) wordt aangegeven welke onderdelen relevant zijn voor een model. Voorbeeld is een Surface in GML dat wordt gebruikt in Kadastraal model (oppervlakte van een Perceel). In alle uitingen (documentatie, schema’s etc.) wordt een koppeling gelegd naar het GML Surface, waarmee een werkelijk complete weergave van het Kadastraal model gerealiseerd wordt.

Geen data

Wellicht ten overvloede wijzen wij erop dat deze hele benadering spreekt over modellen, en niet over data. Data is een geheel andere wereld -- die zich echter wél dient te richten naar wat in de modellen is uitgedrukt. Als het model niet stelt dat er een link is met een ander model, kan dit ook niet worden gerealiseerd in de data. Er kan geen adres worden gekoppeld aan een perceel als die relatie niet is beschreven in het model. Ook wijzen we erop dat de techniek waarmee e.e.a. wordt vastgelegd niet essentieel is voor de hierboven beschreven model- en data-eigenschappen. De keuze voor UML, RDF, JSON, XML in welke variant dan ook speelt dus geen rol. Zonder twijfel bestaan er voor bepaalde van deze genoemde “talen” in de dagelijkse praktijk beperkingen. Dat verandert niets aan deze fundamentele aanpak. De MIM standaard kent dan ook twee gelijkwaardige representaties van het metamodel: Linked data en UML. Voor beiden is software die het kan verwerken beschikbaar.

[PalmJanssen]

Mooi overzicht. Ik noem het Informatiemodellen onder architectuur. Dat is ook de NEN 3610 uitdaging voor de komende tijd.

[wilkoquak]

Hi all, interessant allemaal, vooral omdat ik er momenteel net mee te maken heb in het kader van de omgevingswet. We hebben daar 6 conceptuele modellen waar onderling wel relaties tussen zitten maar waar toch per model een catalogus gemaakt moet worden. Ik denk dat dit een samengesteld model is zoals hierboven beschreven door Arjan. Daarnaast wordt er misschien nog wel naar IMxxx modellen verwezen. Twee vormen van extern dus, die zich bij het maken van een catalogus of schema weer verschillend gedragen. Ik neig nu naar het beschrijven van verschillende smaken en beschrijven wat in die gevallen de gewenste functionaliteit zou zijn.

[ArjanLoeffen]

@wilkoquak welke conceptuele modellen zijn dat? Zijn deze conform MIM gemodelleerd? (En voor Imvertor-UG ook interessant: Worden deze met Imvertor verwerkt?)

[wilkoquak]

Onder de omgevingswet ligt een conceptueel model, maar dat bestaat eigenlijk uit een aantal modellen die naar elkaar verwijzen. Zo zijn er bijvoorbeeld CIM-OP (hoe officiële publicaties eruitzien), CIM-TR (model voor toepasbare regels) en nog een lijstje. Deze zijn conform het MIM gemodelleerd. Ik ben nu bezig ze allemaal in 1 EAP bestand te stoppen. Daarna wil ik via Imvertor 6 catalogi genereren die in 6 verschillende documenten terechtkomen.