Op welke model elementen zit historie

[lennartvanbergen]

Op de een of andere manier is het aangeven van historie opgenomen op een gegevensgroep.

Terwijl dit geen betekenis heeft, althans niet in de definitie, omdat historie alleen vastgelegd kan worden wanneer er sprake is van data/gegevens. Dat is zo voor attribuutsoort en relatiesoort.

Een gegevensgroep is geen kenmerk waar gegevens voor gedefinieerd kunnen worden. De gegevens zitten immers in een attribuutsoort, die zit het gegevensgroeptype, die het type is van een gegevensgroep. Nogal ver verwijderd dus van de echte gegevens.

We hebben eerder afgesproken om niet voor convenience metadata "naar boven te schuiven" naar een plek waar het niets betekent, alleen maar omdat dit slechts enkele minuten invulwerk zou besparen per modelelement. Het schept meer verwarring dan het oplevert en model-gedreven tools moeten het weer specifiek gaan interpreteren en er rekening mee houden en dat is het niet waard.

[PalmJanssen]

In mim 1.1 heeft gegevensgroep wel de metagegevens voor historie. Ik zie voor 1.2 geen reden om dit te veranderen.
Als voorbeeld de gegevensgroep 'adresgegevens' met het gegevensgroeptype 'adres'. Waarom zou je geen historie willen bijhouden op adresgegevens (het complete adres) als op de individuele onderdelen daarvan (een huisnummer)?

[lennartvanbergen]

Nou, in een registratie moet je kiezen waar je historie op bijhoudt. Doorgaans is dat a) op data en b) op elke functionele eigenschap van een object. Historie bijhouden op iets wat geen data bevat is betekenisloos.

De kern van het punt is dat dit metagegeven over data gaat. Dat is dan alleen voor plekken waar data zit. Dit vind ik een helder uitgangspunt.

Data zit niet in een gegevensgroep en ook niet in een objecttype. Data zit in attribuutsoorten en relaties.

Op de aggregatie zou dan kunnen, maar dan geldt dit alsnog voor alle plekken waar data zit binnen die aggregatie. Het is echter niet fijn om flexibel op verschillende niveaus wat te moeten implementeren, soms hier, soms daar, soms transitief, soms niet. Je zou ook best bepaalde metagegevens op objecttype kunnen zetten als het geldt voor alle data in het objecttype. Maar ik ben geen fan van die insteek vanwege eerder genoemde redenen. Hier geldt voor mij dus niet: waarom niet, kan soms handig zijn, maar: waarom wel want het is extra werk en eerder onhandig dan handig (en zonder betekenis, dus lastiger te volgen).

[PalmJanssen]

Bedenk wel dat wat voor de een handig is, voor een ander niet zo hoeft te zijn. Ik wil me daarom niet te snel verplaatsen in specifieke use cases.

Voor wat betreft data. Ik zie eerder de case dat juist de Gegevensgroep data is en daarmee het element is dat historie opbouwt als er iets in het Gegevensgroeptype verandert. In mijn herinnering was dat ook een vroeger uitgangspunt van het Gegevensgroeptype: het bouwt een 'gezamelijke' historie op.

In het algemeen: Bedenk ook dat MIM niet alleen voor registraties is maar ook voor het specificeren van gegevens (en gegevens delen) in algemene zin. Ik ben daarom voor flexibiliteit waar dat nodig is of nodig kan zijn.

[lennartvanbergen]

Uhm, nee. De gegevensgroep bevat geen data. De attributen in het gegevensgroeptype bevatten data. Als gesteld wordt dat een gegevensgroep data bevat dan bevat een objecttype ook data en daar stellen we dat niet, die heeft (als modelelement) ook geen historie.

Het lijkt mij al helemaal niet de bedoeling dat de gegevensgroep zelf historie opbouwt. Het is immers geen objecttype, en overerft ook geen historie tijdslijnen, die zitten er niet in. Bij Kadaster heeft een gegevensgroep nooit historie - ik ken geen enkele casus bij BAG, BRT, BGT, BRK, WOZ, Omgevingswet enz. waar een gegevensgroep historie heeft en dat is bewust. Als dit historie kunnen krijgen een essentieel punt is, dan zou ik zeggen laten we eerst een gebruiker vinden die daadwerkelijk historie op een gegevensgroep toepast. Is die er?

[PalmJanssen]

Over historie bij Gegevensgroep.

Zie hier een toepassing van historie bij IMWOZ.

Hier staat dat veranderingen aan AdresBagPlusLocatieOmschrijving een signaal is om historie op te bouwen voor de data van het WOZObject. Dus andere versies induceert van het WOZObject. Dat lijkt mij correct.

[pmaria]

aanduidingWOZobject bestaat volgens MIM niet als onderdeel van een gegeven.

Het is een modelconstructie die verwijst naar een Gegevensgroeptype. De gegevensstructuren die in het Gegevensgroeptype worden gedefinieerd worden via aanduidingWOZobject direct onderdeel van WOZObject.

Anders gezegd: het onderwerp van alle gegevens gedefinieerd middels het gegevensgroeptype AdresBagPlusLocatieOmschrijving hebben als onderwerp het WOZObject.
Ditzelfde had ook gemodelleerd kunnen worden zonder gebruik van de gegevensgroep door de gegevens uit AdresBagPlusLocatieOmschrijving direct te modelleren op WOZObject.

Nu wordt gegevensgroep vaak toegepast als zwak objecttype. Dit is mijns inziens geen correct gebruik van gegevensgroep. Zie ook #170.

[lennartvanbergen]

Eens met Pano dat je zwakke objecttypes niet moet modelleren als gegevensgroep (en al helemaal niet moet zeggen dat alles in dat zwakke objecttype dan historie opbouwt).

[lennartvanbergen]

@PalmJanssen tsja, ik vermoed dus dat dit gedaan is omdat het kon, en omdat het wel handig lijkt, maar dat de bedoeling ervan is: voor alle attribuutsoorten en relatiesoorten die genoemd worden in deze gegevensgroep moet historie worden bijgehouden.

En niet, naast dat de attribuutsoorten en relatiesoorten in de gegevensgroep historie kennen, kent de gegevensgroep als geheel ook nog zelfstandig historie.

Zie bv.
Naam attribuutsoort Naam openbare ruimte
Code attribuutsoort 11.10
XML-tag attribuutsoort aanduidingWOZobject.gor.openbareRuimte
Naam
Definitie attribuutsoort Een door het bevoegde gemeentelijke
orgaan aan een openbare ruimte toegekende
benaming.
Herkomst definitie attribuut�soort
Catalogus basisregistraties adressen en
gebouwen, versie 2009
Datum registratie vanaf 1 januari 2009
Datum ingang geldigheid vanaf 1 januari 2009
Datum authentiek vanaf niet van toepassing
Toelichting attribuutsoort -
Domein attribuutsoort NaamgevingObject
Indicatie materiële historie op niveau groep
Indicatie formele historie op niveau groep
Indicatie "in onderzoek" op niveau groep

te vinden op:
https://www.waarderingskamer.nl/fileadmin/publieksportaal/documents/public/lv-woz/Catalogus_Basisregistratie_WOZ_versie_1.7.pdf

Dat doen meer partijen, dan modelleren ze op een algemener niveau een metagegeven, en zetten bij het het attribuut zelf: zie groep.

Maar MIM kent geen: zie groep. Daar ben ik ook geen fan van, want dan wordt het lastiger te volgen en lastiger te implementeren (leuk voor documentatie, maar niet voor implementatie) of de gegevensgroep historie heeft, of dat er bedoeld wordt: alle kenmerken in de gegevensgroep - terwijl hetzelfde bedoeld wordt: attribuutsoort A bevat data en van deze data moet historie worden bijgehouden.

Wat staat er in dat EA model bij een attribuutsoort dit in het gegevensgroeptype zit?

[PalmJanssen]

Interessante discussie maar ik denk dat we er voor deze update niet uitkomen. Indien relevant dan voor volgende versie lijkt me.

Maar toch een reactie:

Nu wordt gegevensgroep vaak toegepast als zwak objecttype. Dit is mijns inziens geen correct gebruik van gegevensgroep. Zie ook #170.

zie beneden

Wat staat er in dat EA model bij een attribuutsoort dit in het gegevensgroeptype zit?

Daar staat: zie groep. Dit is inderdaad geen correcte MIM waarde. Maar geeft wel aan wat men wil.

Een paar punten:

1. De term zwak objecttype kent MIM niet, al begrijp ik wat er wordt bedoeld. Een Gegevensgroep is een groep gegevens die bij elkaar horen. Dat bij elkaar horen heeft betekenis.

2. De WOZ toepassing is wat mij betreft correct. Ik kan niet in de WOZ materie gaan duiken om precies te beoordelen of de gegevens een groep vormen. Als zij dat vinden neem ik aan dat dat zo is. Ik kan ook nog wel meegaan in het feit dat het op logisch niveau handig is om de gegevens bij elkaar te groeperen. Zeker als ze als groep meervoudig aan het objecttype gebonden zijn.

3. Deze verbinding (Gegevensgroep) kan ook heel goed een eigenschap van een objecttype zijn. Dit hangt af van de semantiek die het model wil uitdrukken. Het lijkt me niet handig om daar een regel voor af te dwingen.

4. Het metagegeven indicatie historie geeft alleen maar aan dat een verandering van de waarde van deze eigenschap historie opbouwt. Dus leidt tot nieuwe versies van het informatieobject. MIM zegt niets over hoe je dat bijhoudt in een database.

5. MIM 1.0 en 1.1 heeft nu wel de indicatie historie op gegevensgroep. Er is nu te weinig draagvlak om dat aan te passen in deze 1.2 update. Indien nodig dan wordt het een issue voor de volgende versie.

[lennartvanbergen]

In overleg met Paul laten we historie nog maar even wel zitten op gegevensgroep totdat helder is dat niemand het gebruikt (of daarmee stopt).

Let wel, in MIM kan je niet bij een attribuutsoort aangeven, voor historie: zie metagegeven gegevensgroep. Dat is geen valide waarde.

Dus om historie op een gegevensgroep werkend te maken moet je buiten MIM om nog wat extra's doen. Denk aan:

• het ondersteunen van een verwijzingen mechanisme binnen metagegevens. Bv. zie gegevensgroep. Dit kan je dan in je extensie aangeven, bv. bij de paragraaf: waardenbereik metagegevens + al je software die iets doet met historie moet met dit mechanisme rekening houden.

• het ondersteunen van overerving van metagegevens. Als het op gegevensgroep zit, dan zit het automatisch op elk kenmerk in de gegevensgroep (en aldaar geef je historie dan niet meer aan. Het MIM profiel geeft aan dat je dit wel moet vullen, dus je moet dan ofwel hetzelfde invullen - of in je extensie aangeven dat de ene de andere overruled, of aangeven dat dit dan leeggelagen wordt. Voor overerving van metagegevens heeft MIM expliciet gekozen om dit zelf niet te doen, omdat je dan impliciet gedrag kan krijgen terwijl expliciet gewenst is, dus dit wordt niet aangeraden.

[pmaria]

Een paar punten:

1. De term zwak objecttype kent MIM niet, al begrijp ik wat er wordt bedoeld. Een Gegevensgroep is een groep gegevens die bij elkaar horen. Dat bij elkaar horen heeft betekenis.

Welke betekenis heeft dit precies?

2. De WOZ toepassing is wat mij betreft correct. Ik kan niet in de WOZ materie gaan duiken om precies te beoordelen of de gegevens een groep vormen.

Zelfde vraag als hierboven: Wat betekent het als gegevens een groep vormen?

Als zij dat vinden neem ik aan dat dat zo is. Ik kan ook nog wel meegaan in het feit dat het op logisch niveau handig is om de gegevens bij elkaar te groeperen. Zeker als ze als groep meervoudig aan het objecttype gebonden zijn.

Het meervoudig voorkomen als groep gegevens ruikt naar een object. Een gegeven heeft namelijk een onderwerp, geidentificeerd of niet. Als deze meerdere keren voorkomen "op" een ander object, dan geeft dat aan dat het om verschillende onderwerpen/objecten gaat. Anders kan het nooit meerdere keren voorkomen.

3. Deze verbinding (Gegevensgroep) kan ook heel goed een eigenschap van een objecttype zijn. Dit hangt af van de semantiek die het model wil uitdrukken. Het lijkt me niet handig om daar een regel voor af te dwingen.

Het lijkt mij juist uiterst belangrijk om af te dwingen wat de betekenis is van het toepassen van een modelelement. Anders kunnen we elkaars modellen niet begrijpen. Dat is toch juist het doel van MIM?

[lennartvanbergen]

@pmaria zou je opmerkingen mbt zwakke of anonieme objecttypes willen (ver)plaatsen in (naar) #170 ?

(tenzij ze echt primair horen bij de behandeling van dit issue)

[kad-haaftr]

In het WOZ-domein wordt helemaal niet gewerkt met historie op objectniveau, historie op groepsniveau of met versies. In plaats daarvan is het uitgangspunt gekozen (jaren geleden) om historie volledig bij te houden op attribuutniveau.

Voor de gegevensgroep aanduidingWOZobject bestaat als zodanig dan ook niet direct historie. De enige interpretatie die wordt gegeven aan "historie op groepsniveau" met betrekking tot deze groep is dat wanneer één van de attributen wijzigt de volledige groep wordt gecommuniceerd, en nooit alleen het gewijzigde attribuut. Dat is geen informatiemodellering maar een procesafspraak.

[lennartvanbergen]

Voorstel: geen historie op gegevensgroep.
Rationale: alleen eigenschappen waar data voor bestaat, kan historie opbouwen.
Toelichting; dit betekent dan dat de 'state' van het objecttype vernieuwd kan worden als deze eigenschap een andere waarde voor waargenomen en /ofgeregistreerd wordt (en als de eigenschap in een groep zit, de groep an sich ook, maar in MIM heeft dit geen verdere betekenis, MIM modelleert geen mutaties).
Actie: verwijderen metagegevens voor historie bij gegevensgroep (bijlage 6).
Buiten scope gelaten: als een gegevensgroep gebruikt wordt als zwak objecttype, dit is een andere discussie, het is niet de bedoeling dat een gegevensgroep gebruikt wordt als zwak objecttype, modelleren dan een objecttype zonder identificatie.

Voorstel opgesteld door Lennart, Pano, Paul en Dick. Kan de review in voor @JohanBoer en @kad-mesdat en als anderen meedoen nog anderen (ntb door @dkrijtenburg-GNM )

[kad-mesdat]

Ik ben het eens met het voorstel geen historie op gegevensgroep. Aanvullend zou dat dan ook moeten gelden voor de relatieklasse waar nu ook nog formele- en materiële historie op zit.

Ik weet niet of ik het wel eens ben met de uitwerking van

Data zit niet in een gegevensgroep en ook niet in een objecttype. Data zit in attribuutsoorten en relaties.

In de stukken van de SOR (hier) zag ik dat voor 90% van de registraties historie op attribuutniveau niet aan de orde is. De historie gaat dan per voorkomen van een object. Dan is er dus wel historie van volledige objecten, maar niet op attribuutniveau. Wat moet ik dan in mijn model zetten?

Ja, want via inspectie en deductie zijn door de tijd heen alle attribuutwijzigingen te herleiden
of
Nee, want het wordt op object niveau bijgehouden en het is niet rechtstreeks per attribuutsoort beschikbaar.

De data zit in de attribuutsoorten en relaties, maar muteert per objecttype. Voor mij zit dan de historie op het objecttype voor alle attribuutsoorten en relaties tegelijk en niet per stuk.
Wat mij betreft zit dus de historie op het objecttype voor alle attribuutsoorten tegelijk (inclusief die binnen een gegevensgroeptype) óf op iedere attribuutsoort afzonderlijk.

Historie per objecttype kunnen we per attribuutsoort kunnen vastleggen met een extra waarde van de indicaties: "Ja, per objecttype voorkomen" (of vergelijkbaar) .

[lennartvanbergen]

Er hoort uiteraard wat betere tekst te komen mbt de metagegevens voor historie. Te weten: voor welke feiten die we onderkennen is het de bedoeling om hiervan historie bij te houden. Hier onderkennen we: geboortedatum (een persoon heeft er maar 1, en deze kan niet wijzigen), of identificaties (mogen niet wijzigen), of registraties die geen historie bijhouden. Hier gaat deze story echter niet over.

Deze story geeft aan: historie houd je alleen bij op relatiesoorten en attribuutsoorten, en niet op andere modelelementen. De modelelementen waar het onterecht op zit, daarvan moet het verwijderd worden. Dit speelt voor: gegevensgroep. De rest heeft geen historie. Lennart zoekt uit waar het onterecht te veel op zit, dit is in ieder geval zo bij gegevensgroep.

We hebben ook nog gekeken naar relatieklasse, die vanuit de objecttype gedachte , net als objecttype, geen historie zou moeten opbouwen, en vanuit de relatiesoort gedachte, wel. Lennart checkt of relatieklasse vanuit relatiesoort insteek wel historie kan opbouwen, en vanuit attribuutsoorten in de relatieklasse maar niet vanuit de relatieklasse zelf. Het kan op dit moment niet, dus verwijderen hoeft niet, er zou dan sprake zijn van dat het onterecht niet op relatieklasse zou zitten.

@lennartvanbergen actiepunt om concreet te maken waar het onterecht wel op zit en waar het onterecht niet op zit.

[oversticht]

Het valt mij op dat in diverse discussies hier het WOZ-domein als casus wordt aangehaald. Het is van belang daarbij in gedachten te houden dat in het WOZ-domein wordt gemodelleerd op basis van StUF. Daarnaast speelt de geschiedenis van het WOZ-domein mee, wat veel verder terug gaat dan het stelsel van basisregistraties. Verder is StUF sterk gekoppeld aan XML en XSD (zie bijvoorbeeld pagina 41 van die standaard).

StUF beschrijft alleen de uitwisseling van gegevens. Dat is significant anders dan modellering van gegevens. Historie op een gegevensgroep heeft in die uitwisseling uitsluitend de betekenis dat altijd de volledige groep wordt uitgewisseld wanneer tenminste één element van de groep wijzigt (zie StUF, pagina 23). Vanuit die achtergrond heeft de Waarderingskamer de indicaties formele historie en materiële historie op 'Ja' gezet.

[lennartvanbergen]

De modelleerbehoefte heeft idd niks met de WOZ te maken en we zullen de WOZ niet gebruiken als voorbeeld of aanleiding (ik had gevraagd aan WOZ om mee te kijken, omdat de WOZ voor zover ik weet erg gedetailleerd aan de slag is geweest met historie).

[lennartvanbergen]

Tekstvoorstel in H2 voor: https://docs.geostandaarden.nl/mim/mim/#metagegeven-indicatie-materiele-historie
en voor https://docs.geostandaarden.nl/mim/mim/#metagegeven-indicatie-formele-historie

Dikgedrukt de delta.

Toepassing: alle modelelementen die een kenmerk (kunnen) zijn van een objecttype, waarvoor data kan worden bijgehouden: attribuutsoort en relaties (relatiesoort of relatiedoel, relatieklasse, externe koppeling).

H3 UML: https://docs.geostandaarden.nl/mim/mim/#modellering-metagegevens-voor-objecten-en-attributen-in-uml
verwijderen van beide metagegevens bij gegevensgroep. Verder staat er niks te veel in H3.

H4 LD: https://docs.geostandaarden.nl/mim/mim/#modellering-metagegevens-voor-objecten-en-attributen-in-ld
Verwijderen van beide metagegevens bij gegevensgroep. Verder staat er niks te veel in H3.

H5 hoeft dit denk ik niet nader toe te lichten er zijn geen conventies of voorbeelden nodig, H2 is al duidelijk genoeg. Misschien als er ooit een vraag over komt waarbij het antwoord niet in H2 past ...

[lennartvanbergen]

Voorstel is al gereviewed, kan door naar Done/verwerken naar pull request

[lennartvanbergen]

verwerkt in pull request met nummer 224

[Gtrouborst]

De metagegevens voor historie kunnen niet (meer) bijgehouden worden op gegevensgroep (dit bijhouden gebeurd bij de specifieke modelelementen binnen het gegevensgroeptype dat bij de gegevensgroep hoort).