Datatype van Indicatie materiele/formele historie irt groepen

[architolk]

Het datatype van indicatie materiele/formele historie lijkt een boolean (aangezien het een indicatie is...), maar in de tekst staat dat hier "Ja", "Nee" of "Zie groep" ingevuld mag worden. Dit lijkt bijzonder, ook omdat voor mogelijk andere velden ook de "Zie groep" denkbaar is, maar niet gekozen kan worden.

Voorstel is om dit veld weer boolean te maken, met een optionaliteit, waarbij in het geval van niet aanwezig gekeken wordt naar de groep (en dit ook voor de andere aspecten mogelijk maken).

[dkrijtenburg-GNM]

lennart doet een voorstel

[GeraldGrootRoessink]

Mijn opmerking gaat vermoedelijk buiten de scope van MIM 1.1 (een Linked Data koppeling). Ik ga het toch aandragen:

Bij DUO verbazen we ons over de keuze in het MIM-model om mat/form historie te modelleren bij een attribuutsoort en niet bij een objecttype. Bij DUO zijn dit namelijk zogenaamde UML klasse-attributen die gelijk zijn voor alle instanties van het objecttype (a.k.a. klasse). Alle historie is in beginsel beschikbaar voor raadpleging. Het zijn "patronen". Stel je daarbij door dat wel als gevolg daarvan in het technisch model twee onafhankelijke datumparen opnemen.

[lennartvanbergen]

Dit komt omdat individuele kenmerken wel of niet onderhavig kunnen zijn aanwijzigingen.

Bv. identificatie
Bv. geboortedatum
Bv. bouwjaarPand
Bv. een afgeleid gegeven zoals leeftijd.

De eerste paar kunnen niet wijzigen, de twee wijzigt de hele tijd maar wordt niet historisch bijgehouden.

Er zijn historiemodellen die uitgaan van historie per attribuut, en die uitgaan van historie per objecttype.

Ik zou verwachten bij linked data dat historie per eigenschap is.

Dit gezegd hebbende, veelal is het inderdaad zo dat je historie per object bijhoudt. Dat is een good practise. Doen we bij Kadaster ook in ons historiemodel.

MIM maakt beide mogelijk.

Overigens, de modellering van je historie is een implementatie, dit kan per registratie verschillen. Hier in MIM gaat het om het metagegeven hoe het zit met het wel of niet hoeven bij te houden van de historie van een eigenschap. In een extreem geval staan alle kenmerken op NEE en hoef je voor het hele object geen historie bij te houden, terwijl een ander object wel historie kent via bv. een Voorkomen. IMKAD kent daarom wel Voorkomen, met daarin de tijdslijnen die bijgehouden worden, zoals datum begin geldigheid en datum einde geldigheid en tijdstip registratie etc.

[lennartvanbergen]

In navolging van zie groep, zou je inderdaad ook zie Object verwachten. Of zelfs: zie informatiemodel,

Ik vind eigenlijk dat dit soort convenience aspecten meer ruis veroorzaken dan dat het fijn is. Want als je bij objecttype invult nee, en bij een kenmerk ja, wat betekent dit dan? Beter lijkt me om het alleen bij te houden op het niveau van kenmerk.

Goed ... dit item gaat ergens anders over. Misschien wil je een nieuw issue opvoeren om 'per objecttype' aangeven mogelijk te maken?

[lennartvanbergen]

De intentie is Ja of Nee. Dus dat is de basis van de oplossing.

Verder, voor beheer kan het handig zijn om convenience afspraken te maken. Al is het helemaal niet moeilijk om bij het aanmaken van een kenmerk ook even deze in te vullen. Dus ik neig er sterk naar om naar Ja en Nee over te stappen, en niet zie groep, zie object, zie package, of zie informatiemodel.

Ja/Nee is een Indicatie. Of een Enum. Niet helemaal hetzelfde als een boolean (True/False of 0 | 1), boolean is te technisch en zorgt weer voor vertalingen naar Ja of Nee of aanpassingen van X informatiemodellen op 1000-en kenmerken en gepubliceerde documentatie en dat gaat me iets te ver, zelfs als boolean beter zou zijn. Sommige mensen laten deze metadata ook eerst, of per ongeluk, leeg. De betekenis mag dan niet automatisch terechtkomen op 'elders gedefinieerd'.

--

Voorstel: Ja | Nee.

Convenience afspraken voor beheer mag eenieder zelf bedenken en opnemen als afspraak in de extensie en zo doorvoeren in het informatiemodel. Zo blijft deze aanpassing ook backwards compatible. Default convenience kan zijn: zie bovenliggend type modelelement, in deze volgorde: gegevensgroep (als aan de orde), objecttype, generalisatie objecttype (en verdere generalisaties), package, informatiemodel.

@architolk @PalmJanssen @ThiesMesdag werkbaar?

[ThiesMesdag]

Zeker met de convenience afspraak erbij lijkt mij heel werkbaar.

[lennartvanbergen]

Ok, ik voer deze door. Als iemand issues heeft kan ie altijd Zie groep toevoegen aan zijn extensie, het heeft dan geen invloed op het informatiemodel of de publicatie daarvan.

[lennartvanbergen]

Verwerkt in Algemeen, bij waarden bereik metagegevens.
Verwerkt in Afspraken en regels, bij historie, kopje beheer.