Metamodel voor waardelijsten is nodig

[PalmJanssen]

ander andere om ook voor waarden een temporeel model toe te passen ivm beheer van de inhoud van lijsten

[FrankKooij]

Bij de totstandkoming van NEN 3610:2022 is ontdekt dat MIM toestaat dat waarden in een waardelijst ongemerkt een andere definitie krijgen. Wanneer dat gebeurt, geven de gegevens die die waarden gebruiken, met terugwerkende kracht een andere voorstelling van de historie.

[lennartvanbergen]

Met MIM kan je ook definities intypen die niet kloppen. Sterker nog, dingen modelleren die niet kloppen kan met elke modelleertaal.

Elk modelelement met een definitie kan je een andere definitie geven waardoor het model en de data niet meer overeen komen.

Een waardelijst is een beperking op de data, net zoals een reguliere expressie dat is of de lengte van een attribuut.

Als je de specificaties aanpast moet je ook je data migreren naar de nieuwe specificatie.

Dit geldt inderdaad ook voor als je de definitie aanpast. Dit geldt voor alle definities die bij gegevens horen, niet alleen bij waardelijsten.

Of als je de oude data niet migreert dan heb je de oude versie van een model voor de oude data en de nieuwe versie van het model voor de nieuwe data.

Deze vraag heeft derhalve te maken met data migratie en niet met modelleren.

Historie van definities bijhouden zit in mim bij het versiebeheer van een model.

Historie bijhouden van data zit in de database zelf en niet in het model.

Het is inderdaad zo dat als je de definities aanpast dat je dan ook je data moet migreren.

Het is in het verlengde hiervan inderdaad zo dat als je de data in een waardelijst los beheert van de rest van de data vsn 1 object dat je dan 2 ontkoppelde databronnen in samenhang te beheren hebt.

Het is dan verstandig om de waardelijst ook geschikt te maken voor tijdreizen. Dit kan met de referentielijst. Maar historie van definities is geen historie van data.

Historie van definities is een andere tak van sport dan historie van data. Het zijn echt twee aparte onderwerpen. Het lijkt mij dan ook niet verstandig om de definitie (metadata) die in een veldje in een fysieke waardelijst staat te beheren als 'gewoon een veldje die je gewoon kan wijzigen net alsof de definitie gewone data is'.

Kortom, als je de definitie aanpast dan pas je het model aan en dan kan er sprake zijn van een benodigde datamigratie.

Bv. als je een waarde uit een waardelijst splitst in twee waarden met elk een eigen definitie dan moet je in de werkelijkheid als bronhouder gaan kijken bij deze objecten om te bepalen welke van de twee waardes de juiste is. En of dat altijd al zo was of pas sinds recent. Dan kan je de gegevens van je object aanpassen.

(en als je niet bereid bent om deze bepaling voor de hele historie te doen, oftewel de datamigratie alleen wilt uitvoeren op de actuele data, dan geldt de oude versie van de definities voor de oude data en de nieuwe voor de nieuwe. In feit creëer je bij halve datamigraties twee aparte datasets. Erg onhandig voor afnemers. Beter dus om geen halve datamigraties uit te voeren. Goed, dit voorbeeld ontspoort een beetje, dit is vast niet aan de orde, daarom tussen haakjes gezet).

Heb je een voorbeeldje wat je wilt specificeren? Dan kunnen we aangeven hoe je dat doet met mim, of als het niet kan dan komen we er zelf achter.

[FrankKooij]

Soms past een andere waarde bij nader inzien toch beter bij de aard van sommige geo-objecten of verdient deze een eigen waarde. Ook kan in de praktijk blijken dat de definities van waarden overlappen. Dit kan allemaal resulteren in het ontstaan van nieuwe waarden of het veranderen of eindigen van bestaande. Tijdreizen moet daarna nog steeds een representatief beeld geven van hoe en wanneer de werkelijkheid is veranderd en wat wanneer daarover bekend was (en dus ook welke waarde met welke definitie op welk moment op een geo-object van toepassing was).

Bv. als je een waarde uit een waardelijst splitst in twee waarden met elk een eigen definitie dan moet je in de werkelijkheid als bronhouder gaan kijken bij deze objecten om te bepalen welke van de twee waardes de juiste is. En of dat altijd al zo was of pas sinds recent. Dan kan je de gegevens van je object aanpassen.

@lennartvanbergen beschrijft waar ik hierboven al voor waarschuwde, namelijk "met terugwerkende kracht een andere voorstelling van de historie" geven. Bestaande gegevens achteraf veranderen is niet de bedoeling als beslissingen zijn gebaseerd op wat men toen wist, omdat tijdreizen daarna een verkeerd beeld zal gaan geven.

Bij de Aquo-standaard kun je al wel gewoon tijdreizen in de waardelijsten. Ik begrijp van @koosboersma dat Aquo hiertoe een begin- en einddatumgeldigheid opneemt in de waarde van de waardelijst. Dit zowel op de lijst in totaal als bij elke waarde. Misschien kunnen de beheerders van MIM hier eens naar kijken.

[WijnandIHW]

Bij Aquo (IHW) proberen we in onze modellering gebruik te maken van begrippen/concepten uit Beschouwingsniveau 1 – Model van begrippen. Daar bevindt zich ook een groot deel van onze domeinwaarden. Deze domeinwaarden kunnen in de tijd veranderen: definities, codes, labels/namen kunnen wijzigen. Bij wijzigingen ontstaat een nieuwe versie van een domeinwaarden en de vorige krijgt een Eind geldigheid. Maar uiteindelijk wil ik wel kunnen weten van welke domeinwaarde of welke versie van een domeinwaarde ik destijds gebruik maakte. Ik wil kunnen tijdreizen. Eigenlijk vind ik geen bevredigend antwoord hoe dit temporele aspect van domeinwaarden opgenomen is of wordt in MIM.