Tijdens een bijeenkomst van de expertgroep is eens naar voren gekomen dat er verschillende inzichten bestaan over de manier waarop historie wordt bijgehouden/doorgegeven. Tijdens een discussie poneerde Maarten de stelling dat een gegeven van een object mag worden gewijzigd met een ingangsdatum die ligt voor een ingangsdatum van een eerdere wijziging op een ander attribuut van hetzelfde object. Het werd toen duidelijk dat niet iedereen dit beeld deelde.
Deze discussie is nooit voortgezet (naar mijn weten), maar speelt wel weer een rol in een andere discussie.
In de BAG is sprake van historie op het gehele object/record (in RSGB is dit opgepakt door alle BAG-attributen in één groep te plaatsen). Daardoor is het in de BAG niet mogelijk wat Maarten stelt. Mede daardoor, én door het feit dat er maar één tijdvakGeldigheid is binnen elke entiteit, denk ik dat bij velen het idee is ontstaan dat dit voor alle entiteittypen het geval is.
Strikt genomen kun je volgens mij uit het RSGB en StUF afleiden dat de stelling van Maarten zou moeten kloppen. Het staat er echter niet duidelijk in en, zoals gezegd; de schijn wordt gewekt dat het anders is. Ik denk ook dat de mogelijkheid die Maarten schetst er een is die systemen nog veel complexer maakt (of bijna verplicht tot een geheel andere wijze van datamodellering door name value pairs ipv objectrecords). Ook denk ik dat het er voor de gemiddelde gebruiker absoluut niet duidelijker op wordt (en het ook niet duidelijk te krijgen is in schermen van applicaties). We zullen ons dus misschien dringen moeten afvragen in hoeverre de mogelijkheden die Maarten schetst niet te veel aansluiten bij een perfecte theorie en te weinig bij reële en acceptabele werkelijkheid.
Ik zou deze discussie dus graag nog eens voortgezet zien.
Deze discussie betreft ERR248 en ERR249:
Ik heb aan Maarten gevraagd de verwarring rondom het vullen van beginGeldigheid bij wijzigingen en correcties weg te nemen door middel van een aantal voorbeelden (zie bijlage). Als iedereen het eens is met deze interpretatie is dit meteen het antwoord op ERR248 en ERR249.
Bijlage
In de bijlage heb ik een nieuwe versie van het document toegevoegd (versie 03) waarin ik in geel gemarkeerd een nieuwe sectie heb toegevoegd. Dit beschrijft precies de situatie waarin de ingansdatum van een attribuut voor een ingansdatum ligt van een eerdere wijziging van een ander attribuut van hetzelfde object.
Bijlage
Beste Henri,
Volgens mij zit er een belangrijke fout in het door jou toegevoegde voorbeeld. Het geel gearceerde gedeelte eindigt met de stelling: "Omdat de eind geldigheid van woonplaats in het oude voorkomen geen waarde heeft ziet StUF deze mutatie als een gewone wijziging (mutatiesoort W) op een actueel gegeven.".
Je gaat hiermee, volgens mij, volledig voorbij aan tabel 5.3 op pagina 55 van de StUF 03.01-standaard (patch 15) waarin staat dat in een wijzigingsbericht voor het oude voorkomen de datum einde geldigheid altijd (als ondersteund) een waarde moet hebben.
Ik ben er nog niet helemaal uit wat dit betekent voor het grote geheel, maar misschien kun je daarbij helpen...
Op het StUF forum worden discussies gevoerd over de vraag onder welke voorwaarden wijzigingen in attributen van een object via een StUF kennisgeving mogen worden verstrekt.
De eerste aanleiding voor deze discussies was de stelling tijdens een bijeenkomst van de StUF expertgroep dat een attribuut van een object door middel van een kennisgeving mag worden gewijzigd met een ingangsdatum die ligt vóór de ingangsdatum van de laatste wijziging van een ander attribuut van hetzelfde object. In deze notitie wordt dit de “attribuutniveau benadering” genoemd. Tijdens deze expertgroep werd direct duidelijk dat deze benadering door diverse partijen wordt bestreden.
De tegenstanders voeren aan dat een attribuut van een object alleen door middel van een kennisgeving mag worden gewijzigd indien de ingangsdatum ligt op of ná de ingangsdatum van de laatste wijziging van enig attribuut van hetzelfde object. In deze notitie wordt dit de “objectniveau benadering” genoemd.
Het vaststellen van de juiste benadering is urgent geworden omdat het toepassen van de “attribuutniveau benadering” momenteel wordt vereist door de Waarderingskamer binnen onderdelen van de conformiteitstoets die WOZ applicaties moeten doorlopen om gebruikt te mogen worden door gemeenten die willen aansluiten op de LV WOZ.
PinkRoccade is van mening dat binnen de StUF standaard de “objectniveau benadering” wordt voorgeschreven en bestrijdt dat de “attribuutniveau benadering” wordt voorgeschreven of ook wordt toegestaan. Daarmee wordt dus tevens bezwaar gemaakt tegens het toepassen van de “attribuutniveau benadering” binnen de conformiteitstoets voor de LV WOZ.
In de bijgevoegde notitie worden de beide benaderingen getoetst op basis van de inhoud van de StUF 03.01 standaard. Op basis hiervan wordt geconcludeerd welke benadering correct is. Vervolgens wordt nog gereageerd op de notitie “Voorbeelden Kennisgeving en Historie” (versie 03) die op het StUF forum is geplaatst als toelichting op het gebruik van de “attribuutniveau benadering”.
Bijlage
Hallo John,
Het lijkt lastig om elkaar te overtuigen. Ik blijf van mening dat de StUF-standaard altijd is uitgegaan van de attribuutniveau benadering. De citaten uit de StUF-standaard zijn ook niet in strijd met de attribuutniveau benadering.
Een wat mij betreft belangrijk argument voor de attribuutniveau benadering is dat de StUF-standaard steeds uitgaat van meerdere systemen die onafhankelijk van elkaar waarden van een objecttype kunnen wijzigen. Als Systeem A gegeven A met historie wijzigt, maar een gegeven B met historie niet kent dat door systeem B kan worden gewijzigd, dan zullen beide systemen bij het doorgeven van wijzigingen in A resp. B zonder het te weten een beginGeldigheid kunnen doorgeven die voor de beginGeldigheid van het object in het ontvangende systeem ligt.
De objectniveau benadering voor historie is daarmee niet robuust terwijl de attribuutniveau benadering dit wel is.
Maarten
Met Maarten eens. Even terug naar wat we ook al weer doen: feiten over een object registreren, niet het object zelf. Een wijziging (in de werkelijkheid) van een gegeven (attribuut) kan best later worden geregistreerd dan de wijziging (in de werkelijkheid) van een later gewijzigd gegeven. Daarmee ligt de ingangsdatum van het (in de werkelijkheid) eerder gewijzigde maar later geregistreerde gegeven vóór die van dat (in de werkelijkheid) later gewijzigde maar eerder geregistreerde gegeven.
Dat er registraties zijn die werken met een begin- en einddatum geldigheid voor de totale entiteit is dan ook erg jammer en maakt het nodeloos ingewikkeld.
Je zult dus moeten specificeren op welk object de begin-geldigheid betrekking heeft. Dat object kan een totale entiteit zijn inclusief alle kenmerken van die entiteit, of het object kan één kenmerk of een groep van kenmerken van de entiteit zijn. Maar wanneer je het niet specificeert, dan laat je het aan de lezer die een eigen invulling geeft.
Het is eigenlijk net zo vreemd te vinden dat het huisnummer elf in de ene straat hetzelfde is als het huisnummer elf in de andere straat.
En ik denk dat ook het meenemen van een begin-geldigheid voor elk aparte kenmerk de zaak ingewikkeld kan maken.
Ik weet niet waarom maar ik kreeg via een e-mail deze discussie.
Het is curieus hoe hier wordt omgegaan met datamodellering, en het verschil wat het maakt wanneer je denkt in termen van een RDBMS of XML. Altijd al gedacht dat het verschilde en nooit geweten dat het verschil me zo duidelijk zo op een presenteerblaadje zou worden aangeboden.
Wat klopt er niet: in de Voorbeelden v.03 wordt gedaan alsof er een gegevensgroep Persoon is, waar het adres deel van uitmaakt. En van dat adres maken kennelijk zowel de straatnaam als het huisnummer deel uit.
Er vinden een paar verhuizingen plaats en de resulterende mutatieberichten worden getoond. Maar tussentijds wordt nog even gezegd dat bij de eerste verhuizing er geen sprake is van wijziging van het huisnummer en deze dus dezelfde begin-geldigheid behoudt. Dat dat NIET zo is, daar wordt geheel aan voorbijgegaan. We zijn dan immers de hele samenhang met de in de inleiding genoemde gegevensgroep Persoon kwijt!
Dat het XML-mutatiebericht alleen melding maakt van de ene oude attribuutwaarde en daarvan de nieuwe waarde, lijkt mij in tegenspraak met de kennelijke modellering waarin alle attributen/kenmerken van de gegevensgroep Persoon als samenhangend worden gezien en met een eenmalige begin-geldigheid. Volgens mij moet je dan niet meer de vrijheid hebben om los attribuutjes eruit te plukken.
Of je hebt het natuurlijk over een model waarin elk attribuut los kan worden gemuteerd met een eigen begin-geldigheid. Maar dan moet je dat in de aanhef ook duidelijk stellen en dan moet dat ook nog maar blijken uit de publicaties die ik van het RSGB heb gezien.
Sid Brouwer refereert aan de BAG. De BAG voldoet in het geheel niet aan het uitgangspunt van de twee tijdlijnen (formele en materiële historie). Correcties van fouten in het verleden kunnen niet adequaat worden vastgelegd. De BAG kan daarom nooit model staan voor een goede aanpak van het principe van de twee tijdlijnen.
Zodra geldigheidstermijnen zuiver moeten worden vastgelegd - en de correctie van een gegeven mogelijk dient te zijn zonder ‘overschrijven’ - is het logisch de normalisatie van gegevens veel verder door te voeren. Ik ben het met Sid eens dat het vastleggen van de geldigheidstermijnen per attribuut dan veel handiger werkt bij een modellering m.b.v. value pairs dan met het ‘stapelen’ van records, zoals nu veelal gebeurd. Het bespaart ook op de opslag van null-waarden en het vastleggen van multiple waarden wordt veel eenvoudiger.
Het vormen van een XML-bericht met de bijbehorende XSD vormt geen enkel probleem. Ook qua implementatie van de persistente opslag zie je de laatste jaren een opkomst van de column-based databases, waarbij de opslag in het belang van de performance anders is georganiseerd en optimaal aansluit bij bovengenoemde modellering.
Beste mede forum-leden,
Ik stel voor om in deze discussie de focus te houden op de (correcte) interpretatie van de huidige versie van de StUF 03.01 standaard en het gewenste of beoogde gebruik geredeneerd vanuit het stelsel voort te zetten in een andere forum discussie.
In de hoop op begrip en met groeten, John.
Het lijkt mij dat de specificatie van de semantiek van objecten, attributen en relaties leidend is voor onder andere het omgaan met historie. StUF is 'slechts' een middel om gegevenswaarden conform deze semantiek over te dragen. Deze semantiek is beschreven in onze informatiemodellen (RSGB, RGBZ). In dit geval gaat het dan om de historie-metagegevens materiele en formele historie. Deze zijn in onze informatiemodellen gespecificeerd per attribuut (of per groep van attributen) en per relatie. Niet per object. Dit impliceeert m.i. de eerder genoemde attribuutniveaubenadering in StUF. Dat er in StUF voor gekozen is om historie-elementen per entiteit op te nemen, is een implementatievorm om de semantiek van een informatiemodel in een bericht te verwerken. Dit doet niets af aan die semantiek.
Ik meen me te herinneren dat hier al 's eerder over gepraat is. En dat we toen vastgesteld hebben dat door het vergelijken van de oude met de nieuwe elementwaarden in een kennisgevingsbericht achterhaald kan worden welke elementen daadwerkelijk gewijzigd zijn waarop de historiekenmerken van toepassing zijn. De ontvangende applicatie dient met deze kennis zijn registratie correct bij te werken, zodanig dat recht wordt gedaan aan de historie per attribuut, attribuutgroep en relatie en daarmee aan het desbetreffende informatiemodel.
Het is mij inmiddels wel duidelijk geworden dat de beschrijving van StUF op dit punt niet duidelijk genoeg is en aanscherping behoeft: wat volgens de een is uitgesloten, zou dat volgens de ander niet zijn. Ik stel voor dat we hierover duidelijkheid verschaffen. Inmiddels ben ik wel in gaan zien dat voor sommige registraties historie op attibuut(groep)niveau wenselijk is. Ik ben het met Arjan eens dat hiervoor moet worden gekeken naar het semantisch model: hierin ligt vast op welk niveau historie ligt. Voor StUF zou de huidige structuur kunnen worden gehandhaafd, maar ik ben wel van mening dat daarbij moet gelden dat een wijziging binnen een attribuutgroep (zoals vastgesteld in het RSGB) niet eerder in mag gaan dan een andere wijziging in diezelfde attribuutgroep. Als voorbeeld: wanneer de geslachtsnaam is gewijzigd per 1-1-2013 mag niet later een mutatie van de voornamen per 1-1-2012 worden doorgevoerd (anders dan via een correctie). Deze gegevens horen immers bij één groep. De nationaliteit (andere attribuutgroep) mag wél per 1-1-2012 worden gewijzigd. Daarnaast is het m.i. belangrijk om een duidelijke specificatie te geven voor de vulling van de begin geldigheid in de oude situatie van een kennisgeving. Deze kan immers voor verschillende elementen in dat object verschillende waarden hebben. Daarmee is de daadwerkelijke betekenis van het element te willekeurig geworden en dus is het element daarmee overbodig. In dat kader ben ik ook niet erg gelukkig met de definitie van de geldigheidsgegevens in antwoordberichten met historie: de gegevens slaan niet op de elementen in datzelfde 'voorkomen', maar soms juist op een eerder historisch voorkomen. Zeker voor een volgende versie van StUF lijkt mij dit een aandachtspunt (lees: RFC).
In de bijlage van deze post heb ik een notitie bijgevoegd met de twee volgende conclusies: 1) StUF ondersteunt historie op attribuutniveau. Voor een efficiënte representatie van historie op attribuutniveau wordt het element gedefinieerd op alle wijzigende elementen van een object zoals in deze notitie beschreven. Deze representatie is misschien niet voor iedereen intuïtief, maar het is een bewuste keuze die leidt tot een compacte definitie van historie. 2) Het ondersteunen van historie op attribuutniveau zorgt ervoor dat reële situaties zoals het later doorgeven van een wijziging in de werkelijkheid op een natuurlijke wijze kan worden gecommuniceerd via StUF-kennisgevingen.
Bijlage
Ik heb twee opmerkingen bij het document: 1. Uitspraken over implementatie Pagina 4 begint met "Uit het bericht is dus heel eenvoudig de database inhoud te reconstrueren.". Ik ben van mening dat we voorzichtig moeten zijn met dergelijke subjectieve opmerkingen. Ze zijn vaak afhankelijk van implementaties en dus ook niet in alle gevallen waar. De laatste alinea voor de conclusie doet ook een uitspraak over opslag in databases (implementatie dus). het gaat erom dat duidelijk moet zijn wat de betekenis is van berichten en niet of, hoe en hoe gemakkelijk het in een database kan worden gestopt. Het probleem zit het misschien niet zozeer in de opslag, maar in de manier waarop van daaruit berichten moeten worden opgebouwd... 2. Daadwerkelijk gebruik van de mogelijkheden Ik zie geen antwoord op mijn eerdere reactie in deze discussie over het wenselijk zijn van de toepassing van deze mogelijkheid in StUF. Een voorbeeld: in de huidige standaard kan ik een naam van een persoon wijzigen en later, met een eerdere ingangsdatum de geboortedatum van die persoon. Als je echter in het RSGB kijkt op pagina 321 en verder, dan is de conclusie dat historie alleen is gedefinieerd op het niveau van het groepsattribuut Persoonsgegevens en niet op de onderliggende elementen. Dat betekent dus dat alle elementen binnen deze groep dezelfde datum begin geldigheid moeten hebben. Afwijkingen kunnen we, volgens het informatiemodel, niet bevatten/opslaan. Doorgeven van dergelijke historie is in mijn ogen net zoiets als het toevoegen van een willekeurig nieuw element. Als je dat doet buiten het model om, is de semantiek van het gegeven niet gedefinieerd en kun je niet verwachten dat systemen dat ook kunnen verwerken. Het tweede punt behoeft volgens mij nog steeds afstemming en verduidelijking in de documentatie.
Het opleven van deze discussie verbaast mij. In augustus 2013 hebben wij met alle leveranciers betrokken bij de LV WOZ een diepgaande discussie gehad over dit onderwerp. De conclusie daaruit was dat uiteindelijk "historie op attribuutniveau" de enig wenselijke werkwijze kan zijn, wanneer je het benadert vanuit het perspectief van de ontvanger van berichten. Bij historie op objectniveau zal immers de zender kijken naar de laatste mutatie van enig attribuut in het betreffende object. Deze laatste beginGeldigheid zal worden meegestuurd. Een ontvanger zal in veel gevallen die datum niet herkennen, omdat deze ontvanger het toen gemuteerde attribuut niet bijhoudt. De laatste mutatie die de zender heeft vastgelegd, is dus nooit naar deze ontvanger gestuurd en dat blijft lastig communiceren, omdat "was" en "wordt" bij de ontvanger niet meer op elkaar aansluiten. De ontvanger veronderstelt dan dat mutaties zijn gemist en zal weer synchronisatieverzoeken doen etc. Bij de conformiteitstoets van de LV WOZ is duidelijk naar voren gekomen dat mutaties met een beginGeldigheid gelegen vóór de meest recente mutatie van dit object wel veelvuldig zullen voorkomen, namelijk bij systematisch gebruik van inOnderzoek. Immers bij een object zal het attribuut inOnderzoek op een bepaald moment wijzigen op basis van een terugmelding. Na afronding van het onderzoek wordt het attribuut inOnderzoek wederom gewijzigd, maar zullen ook de resultaten van dit onderzoek moeten worden vastgelegd. De beginGeldigheid van deze resultaten zal meestal eerder zijn dan de inOnderzoek stelling. Bij de LV WOZ levert dat duidelijk extra problemen op en vaak de noodzaak om een extra synchronisatie uit te voeren. Daarom was volgens mij de unanieme conclusie van alle partijen rondom de LV WOZ in augustus 2013 dat bij de uitwisseling van berichten uiteindelijk historie op attribuutniveau de enige werkwijze kan zijn (wat betreft de modellering in de database, mag natuurlijk iedereen de eigen weergave kiezen). De overstap naar berichtuitwisseling met historie op attribuutniveau zal voor sommige leveranciers veel impact hebben, Daarom is gekozen voor een ruime overgangsperiode waarin historie op objectniveau wel wordt toegestaan. De ervaring met de conformiteitstoets LV WOZ leert dat deze historie op objectniveau leidt tot vele "dialecten" van aanlevering van inhoudelijk dezelfde mutatie. Dat is zeker vanuit het perspectief van afnemers niet wenselijk en de uniformiteit die we mogen verwachten van een standaard als StUF zal uiteindelijk pas bereikt kunnen worden wanneer iedereen uitwisselt op basis van historie op attribuutniveau. Daarom denk ik dat in de documentatie zeer eenduidig vastgelegd moet worden dat bij de berichtuitwisseling met StUF uitsluitend gewerkt wordt op basis van historie op attribuutniveau. Wanneer de documentatie de suggestie wekt dat StUF ook dwingt om in de database de vastlegging op attribuutniveau te realiseren, moet de documentatie worden aangepast. De database moet alleen de mogelijkheid bieden om bij de vervaardiging of verwerking van berichten de historie op attribuutniveau af te leiden.