'eindGeldigheid' moet groter zijn dan 'beginGeldigheid' van 'tijdvakGeldigheid'

Doordat er in de BAG geen echt tijdsdeel aan de begin geldigheid zit en er meerdere gebeurtenissen op 1 dag kunnen plaatsvinden, is het voor een BAG applicatie niet zomaar mogelijk om hieraan te voldoen.

Ben het eens met Robin dat het voor een BAG applicatie niet eenvoudig is om hieraan te voldoen. Maar het is ons, GeoTax, naar mijn bescheiden mening, wel gelukt. Zie ook de post "platgeslagen elementen en tijdvakgeldigheid" elders op dit forum. Maar dat is niet het onderwerp van deze post, nog een reden niet na te denken over dit onderwerp.

Bijvoorbeeld: corrigeren van historische gegevens. Zie item 2 op pagina 68 van "stuf0301 zonder renvooi.pdf" in de map bg0310zkn0310_20120912_patch13.zip. Stel we hebben drie opeenvolgende voorkomens van een en hetzelfde object. Ik geef alleen waarden voor de elementen beginGeldigheid en eindGeldigheid van TijdvakGeldigheid en een willekeurig attribuut waarover formele historie moet worden opgebouwd:
A B x
B C y
C - z

Vervolgens wordt er een correctiekennisgeving gestuurd:
was
 A B x
wordt
 A B q

Scenario 1: A, B en C zijn opeenvolgende ongelijke waarden.
resultaat voor en na verwerken van het bericht, lijkt me triviaal:
A B x   A B q
B C y   B C y
C - z   C - z

Scenario 2: A=B en B<C.
resultaat voor en na verwerken van het bericht. Lijkt simpel, maar, zoals later zal blijken, er rijst de vraag op basis van welke velden het te corrigeren voorkomen geselecteerd moet worden, naast de samentische sleutel beginGeldigheid of ook eindGeldigheid:
A A x   A A q   A A x   A A q
A C y   A C y   A C q   A C q
C - z   C - z   C - z   C - z

Scenario 3: A=B=C
Nu wordt het lastiger: welk voorkomen moet gecorrigeerd worden, immers de database in de ontvangende applicatie bevat:
A A x
A A y
A - z

Moet het de eerste zijn, of de tweede of beide:
A A x   A A q   A A x   A A q
A A y   A A y   A A q   A A q
A - z   A - z   A - z   A - z


Stel, we selecteren het voorkomen niet alleen op basis van semantische sleutel en tijdvakgeldigheid, maar ook basis van de waarde van het te wijzigen element:lijkt geen probleem:
A A x   A A q
A A y   A A y
A - z   A - z

Maar dan moet naar mijn mening het identificeren van een voorkomen van een object ook in algemene zin worden uitgebreid, zodat er geen "kerngegevens" meer zijn maar altijd alle elementen moeten worden opgenomen in een bericht. Dit geldt dan in het bijzonder ook voor een object dat optreedt als gerelateerde in een relatie. Deze oplossing lijkt me dus vergaande gevolgen te hebben.

Daarnaast is het geen sluitende oplossing: welk voorkomen moet gecorrigeerd worden in onderstaande situatie, het eerste, het derde, beiden of allen behalve de laatste?
A A x
A A y
A A x
A A y
A - z

Neen. Dan kom ik terug op het voorstel: van ieder voorkomen van een object moet eindGeldigheid een null waarde hebben (laatste voorkomen) of groter zijn dan beginGeldigheid van hetzelfde voorkomen. Dan zijn de scenario's 2 en 3 niet toegestaan en is het eenduidig bekend welk voorkomen gecorrigeerd moet worden.

Een soortgelijk verhaal gaat op voor item 1 op dezelfde pagina (Correctie van de historie door het wijzigen van een tijdvakGeldigheid), maar dat laat ik over aan de liefhebbers.

Ik ben het met Han eens als het zou gaan over algemene objecten. Alleen gaat het verhaal niet op voor BAG gegevens omdat je daar geen historische gegevens corrigeert.

Daar komt nog een semantisch probleem bij (in geval van BAG): wat als er twee wijzigingen op één dag zijn en je vraagt de situatie op die datum (dus zonder tijd). je zou dan altijd de laatst geldige situatie moeten hebben en niet de situatie met timestamp 00:00:00.

Of stellen we in dat geval dat vragen om de situatie op dd-mm-yy 00:00:00 moeten worden beantwoord met de situatie op dd-mm-yy 23:59:59.999?

Reactie op het concept erratum in StUF 03.01 (In gebruik) versie 1.5:

Pagina 29: 9,7,5,4,3,2,1 moet zijn 9,7,5,3,2,1 (uren, minuten, sec, tienden, honderdsten, duizendsten).

Pagina 29: volgens mij moet het tijdsinterval zo veel mogelijk opgerekt worden i.p.v. ingesnoerd. Zie ook de laatste zin van de toevoeging: "Een tijdstip met noValue=geenWaarde is de grootst mogelijke waarde", waarbij ik overigens aanneem dat deze zin geldt voor eindGeldigheid (de voorgaande zin).

Pagina 94: soortgelijk als voorgaande opmerking. Theoretisch gezien moet de beschrijving aangeven dat elke waarde voor een datum veld een zekere onnauwkeurigheid heeft en dat je dus bij het vergelijken van twee waarden rekening moet houden met de onnauwkeurigheden van beide waarden. Oftewel wat is het antwoord op de vergelijking (T1 +/- e1) == (T2 +/- e2)

Volgens mij hebben we hier te maken met een technisch probleem dat is ontstaan doordat (historische) situaties/voorkomens van objecten in de registratie niet meer uniek identificeerbaar zijn bij gebrek aan attributen hiervoor. Voor het kunnen corrigeren van specifieke situaties is dit noodzakelijk.

De meest voor de hand liggende oplossing lijkt te zijn dat de beginGeldigheid gebruikt wordt om situaties van een gegeven object uniek te kunnen identificeren. Daarvoor moeten deze waarden dan natuurlijk wel uniek zijn binnen de volledige historie van het object.

Door dit te eisen, hebben we, mijns inziens een nieuw probleem: semantiek. Door de beginGeldigheid te 'misbruiken' voor de identificatie van objectsituaties wordt een betekenis gesuggereerd die er niet is. Met name bij de BAG zien we daar nu ook al de problemen verschijnen. De beginGeldigheid binnen de BAG is semantisch gezien een datum (zonder tijd). Een benoeming van een openbare ruimte per 1-1-2013 gaat niet op een specifiek tijdstip op die dag in en daarmee impliciet om 00:00:00.000 uur.
Om hier beter mee om te kunnen gaan, wordt in het voorstel voor een patch nav dit erratum een (noodgedwongen) redelijk complexe beschrijving gegeven van hoe datums en tijden moeten worden geïnterpreteerd.

Het doorvoeren van de patch geeft de beperking dat voor het kunnen doorvoeren van meerdere situaties op een dag er een tijd moet worden toegevoegd aan de beginGeldigheid. In de praktijk van de BAG semantisch gezien dus eigenlijk niet correct (deze tijd heeft geen betekenis), maar wel noodzakelijk (meerdere mutaties op een dag zijn toegestaan).
Dit geeft weer andere semantische problemen. Een voorbeeld:

Op 1-11-2012 wordt een openbare ruimte Kerkstraat benoemd per 1-1-2013. Deze krijgt als beginGeldigheid '01012013000000000'. Op 15-11-2012 wordt echter besloten dat de naam niet kerkstraat, maar Kerkplein zou moeten zijn. Deze nieuwe situatie krijgt als beginGeldigheid '01012013000000001'. Een nummeraanduiding (nummer 9) die wordt uitgegeven per 1-1-2013 wordt opgenomen met als beginGeldigheid '01012013000000000'. Een systeem kan nu een vraag stellen hoe de AOA eruit heeft gezien op het peiltijdstip '01012013000000000' (de ingangsdatum van de nummeraanduiding). Semantisch gezien is het adres altijd Kerkplein 9 geweest. Echter op basis van de gegevens zal Kerkstraat 9 worden teruggegeven.

Naast deze semantische problemen, kunnen er binnen de gekozen oplossing ook nog steeds problemen ontstaan bij mutaties op platgeslagen gegevens. Een uitbreiding op het bovenstaand voorbeeld:
1: benoeming ORU 'Kerkstraat' per 1-1-2013: beginGeldigheid is '01012013000000000'.
2: benoeming NAA 'Kerkstraat 9' per 1-1-2013: beginGeldigheid is '01012013000000000'.
3: wijziging NAA 9 wordt 9a per 1-1-2013: beginGeldigheid is '01012013000000001'.
4: wijziging ORU Kerkstraat wordt Kerkplein per 1-1-2013: beginGeldigheid is '01012013000000001'.
Bij mutatie 4 moet er een AOA-bericht worden verstuurd voor de NAA. Deze zou als beginGeldigheid de timestamp '01012013000000001' krijgen. Dit is niet toegestaan.

Conclusie: we hebben een potentieel probleem bij het corrigeren van mutaties indien er voor één object meerdere situaties bestaan met eenzelfde beginGeldigheid. StUF-BG heeft nu niet de beschikbare elementen om situaties uniek te identificeren.
Als oplossing zou de beginGeldigheid als uniek binnen de historie van objecten kunnen worden gesteld. Dit geeft echter semantische problemen en lost ook nog steeds niet alle technische problemen op.

Ik stel voor om dit probleem te laten voor wat het is. Het betekent mogelijk dat niet alle correcties automatisch kunnen worden verwerkt en dat systemen zelf moeten zorgen voor unieke identificatie en een juiste volgorde van situaties binnen een objecthistorie. Dit is niet bepaald wenselijk, maar (ik vrees) onvermijdelijk.
Een échte oplossing zal zeer ingrijpend zijn en niet in een patch kunnen/moeten worden ondergebracht. De huidige oplossing is slechts een oplossing voor een deelprobleem die ook nog eens downwards incompatible is. Dit betekent dat doorvoeren van deze patch als gevolg heeft dat bestaande systemen die nu volgens de spec's correct communiceren opeens incorrecte berichten zouden kunnen verzenden. Dit is mijns inziens alleen verantwoord als het gaat om een sluitende oplossing voor een (overall) blokkerend probleem. Daar hebben we in dit geval niet mee te maken.

Nabrander:
Tijdens het overleg van 21-11 is gesteld dat het RSGB zou stellen dat de beginGeldigheid uniek moet zijn binnen de historie van het object. Ik heb dit niet terug kunnen vinden in de documentatie van het RSGB. Mijn (tegen-)stelling is dan ook dat een applicatie die deze uniciteit niet kent niet fout werkt/communiceert en dat berichten met gelijke nieuwe beginGeldigheid en oude eindGeldigheid nu niet incorrect zijn. Systemen die dit wel eisen hebben zelf een beperking geïntroduceerd die er in het RSGB niet is.

Het probleem wat Sid schetst is precies wat ik ook bedoelde in mijn reactie van 18 oktober.

Ik ben het dan ook eens met zijn voorstel om het probleem te laten voor wat het is.

Bij het oplossen van dit vraagstuk dient ook gekeken te worden naar de portabiliteit van StUF 02.04 berichten naar StUF 03.01 berichten. Binnen StUF 02.04 zijn een begindatum en einddatum gedefinieerd en binnen StUF 03.01 een begintijdstip en eindtijdstip. Indien het voorstel (uniciteit) wordt aangenomen, dient ook een conversievoorschrift van StUF 02.04 naar StUF 03.01 opgenomen te worden.

Ik zie dit item terugkomen in de errata met betrekking tot historie op de agenda van de StUF expertgroep van februari. Helaas wordt er dus voorbij gegaan aan de bezwaren die eerder in deze discussie zijn geuit. Opnemen van deze wijziging in een patch vind ik niet acceptabel. De wijziging is dermate ingrijpend dat er grote problemen kunnen ontstaan. Niet alleen is hier sprake van systemen die moeten worden aangepast, er geldt ook dat bestaande gegevens moeten worden geconverteerd om ze uit te kunnen blijven wisselen. Bij gegevens waarin nu een datum is opgenomen zonder tijdstip (zoals in de BAG) en waarbij meerdere mutaties op één dag zijn gedaan, moet alsnog een tijdstip worden 'verzonnen' om de gegevensuitwisseling (bijvoorbeeld in geval van een synchronisatie) in stand te kunnen blijven. Vooralsnog is besloten de wijzigingen met betrekking tot historie als errata/patch te behandelen omdat ze alleen te maken zouden hebben met aspecten die nu nog niet geimplementeerd zijn, anders dan in het kader van de LV WOZ. Voor dit punt is dat niet het geval. Daarom ben ik van mening dat we dit item niet zonder meer mee moeten nemen in de patch van april.