search

Geonovum / MIM-Werkomgeving

Werkomgeving van MIM. Bevat werk en alle pre-publicatieversies.
https://geonovum.github.io/MIM-Werkomgeving/
8 stars 15 forks source link

Inverse relaties - modelleerrichtlijnen? #223

Open lennartvanbergen opened 2 years ago

lennartvanbergen commented 2 years ago

Wat is het subtiele verschil tussen een relatie met een source rol en een target rol en een kardinaliteit aan beide kanten en twee gerichte relaties met alleen de target gespecificeerd.

@architolk @PalmJanssen @lennartvanbergen-kadaster @ThiesMesdag

kad-mesdat commented 2 years ago

In het eerste geval geef je een dominante/hoofd/voorkeurs richting aan, waarbij de inverse impliciet is. Met twee losse relaties is dat niet het geval dan zijn het beiden 'first class citizens.

lennartvanbergen commented 2 years ago

We hebben in de SOR bij IM Gebouw ook dergelijke uitdagingen. 1 vs 2 relaties o.a. ook te maken met in welk object je de eigenschap onder historie bijhoudt, dan wel welk object functioneel anders is (wijzigt) als de relatie verlegt wordt.

Vaak is het zo dat je dan niet beide objecten wilt muteren, maar alleen degene die 'aware' is van de ander - en degene die unaware kunnen blijven pas je dan niet aan. Bv. een perceel is een stuk grond op de aarde, als we daar een eigendomsrecht op vastleggen, dan verandert het perceel niet. De relatie gaat daarom van het eigendomsrecht naar het perceel en niet andersom.

In de IT is het leggen van relaties van A naar B en andersom ook van B naar A voor databases en data helemaal niet fijn.

Terwijl in een API juist weer erg fijn is als je beide kanten op kan navigeren. Natuurlijk kan dat ook door bij een relatie van A naar B - en je hebt een B - dan de resource A op te vragen met een query 'where relatie naar B = 1234' maar als je een API link wilt maken dan moet dat kunnen. Dan is het handig als de naam van die relatie of rol voorhanden is.

De wens om beide kanten op te navigeren en dit ook in een informatiemodel te specificeren, hoe de relatie deze richting op heet en met een definitie, is er.

Wat zijn dan de bijbehorende modelleerrichtlijnen. Als ik Thies zo hoor is een optie: leg 1 relatie, met een source rol en een target rol, en gebruik die rolnamen.

lennartvanbergen commented 2 years ago

@pmaria deze vind jij denk ik ook interessant.

kad-mesdat commented 2 years ago

image In zorgeloos vastgoed hebben we het voor LD zo opgelost. Een rolnaam met een richting voor de inverse relatie.

PalmJanssen commented 2 years ago

In NEN 3610 hebben we in 2011 afgesproken om associaties verplicht één kant op navigeerbaar te maken. De source (A) kent dan de target (B) en niet andersom. Dit maakt het expliciet. Als je wilt dat B ook A kent dan wordt het een andere (extra) navigeerbare associatie.

Dit is een versimpeling van wat in UML mag, maar dat was ook de bedoeling. Juist om het expliciet te maken zodat MDA weet wat het moet doen.

Ik maak er ook even gebruik van om op te merken dat in UML de property die de relatie implementeert de rolnaam is. Zeker bij twee kanten op navigeerbare relaties weet MDA dan waar ze aan toe is.

architolk commented 2 years ago

Dit was in MIM 1.1 ook al beschreven rondom de transformatie van unidirectioneel: https://docs.geostandaarden.nl/mim/mim/#transformatie-unidirectioneel Met andere woorden: als unidirectioneel = "true", dan moet de relatie 1 kant uitgelezen worden. De "bronkant" wordt dan feitelijk genegeerd, en afhankelijk van de keuze "relatiesoort leidend" versus "relatierol leidend" wordt de naam van de relatiesoort dan wel de relatierol aan de doelkant genomen voor de feitelijke transformatie. Als unidirectioneel = "false", dan moet de relatie 2 kanten uitgelezen worden. Dat vereist dan wel dat aan zowel de bron als de doelkant een naam staat, anders weet je niet wat de "teruggaande" relatie is. Omdat deze twee relaties feitelijk elkaar inverse zijn (omdat er maar sprake is van 1 relatiesoort), wordt in de LD transformatie de eigenschap owl:inverseOf toegevoegd. Dit is een bijzonder handig en nuttig instrument, zoals Ties ook al heeft aangegeven. NB: het is nuttig voor zowel de functionele kant (je kunt dan "spreken" over dergelijke relaties), maar voorkomt ook dat in de functionele uitwerking "last" heeft van de technische uitwerking: hierdoor is makkelijker om in de technische uitwerking een keuze te maken welke van de twee relatierollen daadwerkelijk geïnstantieerd worden, bij het gebruik van een hiërarchisch bestandsformaat (zoals XML).