Welke waarde(n) teruggeven bij een vraag op peiltijdstip materieel en formeel?

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

13 reacties / 0 nieuw
Robert Melskens
Welke waarde(n) teruggeven bij een vraag op peiltijdstip materieel en formeel?

Het is niet duidelijk welke waarde(n) teruggeven moeten worden bij een vraag op peiltijdstip materieel en formeel bij een niet nauwkeurige tijdvakGeldigheid of tijdstipRegistratie in de database of bij een niet nauwkeurige specificatie van het peiltijdstip.

(Deze post komt voort uit post 'eindGeldigheid' moet groter zijn dan 'beginGeldigheid' van 'tijdvakGeldigheid').

Bart van der Zwet

Ik heb de aanpassingen in het concept document StUF 03.01 voor patch 14 eens bekeken en er viel mij iets op waar mogelijk rekening mee moet worden gehouden.

Bij het bepalen van de grootste waarde voor een tijdstip binnen de onnauwkeurigheid wordt een tijdstip genomen met 999 milliseconden. Nu is het zo dat er binnen het stelsel van basisregistraties in ieder geval bij de BAG wordt gewerkt met een domein DatumTijd van 16 tekens (het tijdstip gaat dus niet verder dan honderdsten van seconden).

Wanneer in dergelijke gevallen het tijdstip met 999 milliseconden (17 tekens) voor gebruik wordt afgerond krijg je een waarde die net iets hoger is dan bedoeld.

Ik heb me hier verder niet helemaal in verdiept, maar moet met dit soort zaken geen rekening worden gehouden? Als het van belang is voor de werking, is het wellicht goed om dit te documenteren.

Han Welmer

Wat is het toch leuk als je de tekst in paragraaf 6.4.5 leest met een wiskundige blik. Hoe moet je de uitspraak duiden “het kleinere element in een kleiner dan relatie”? Of wat wordt er bedoeld met “tijdstipregistratie overlapt met peiltijdstipFormeel”?

Als ik de theoriën over relationele expressies, Boolean algebra en bitemporal databases toepas op StUF, dan kom ik tot de volgende vijf opmerkingen:

  1. Alle genoemde variabelen zijn onderhevig aan een beperkte nauwkeurigheid. De tijd is continue, maar de waarde in de database, bericht en peiltijdstip zijn discreet. Daarenboven wellicht met een verschil in onnauwkeurigheid. Het voorstel geeft aan hoe om te gaan met onnauwkeurigheid in beginRelatie, eindRelatie en peiltijdstipFormeel. Maar hoe zit het met een onnauwkeurigheid in beginGeldigheid, eindGeldigheid en tijdstipRegistratie dan peiltijdstipMaterieel?
  2. ​tijdstipRegistratie is een tijdstip en geen periode, zodat er wiskundig gezien geen sprake kan zijn van overlap.
  3. De teksten zoals “het kleinere element in een kleiner dan relatie” vind ik onduidelijk
  4. Naar mijn mening leidt de gegeven oplossing tot verkeerde resultaten
  5. Naar mijn mening kunnen de aanvullende regels (“Als meer …”) gecombineerd worden met de voorgaande
  6. Regels tot 1 regel voor het selecteren van het juiste voorkomen van een object.
Han Welmer

Bij het zoeken in de materiële historie moet het voorkomen (of de voorkomens) van een object van een fundamentele entiteit voldoen aan: beginGeldigheid <= peiltijdstipMaterieel EN peiltijdstipMaterieel < eindGeldigheid.

Idem dito voor een relatie entiteit: beginRelatie <= peiltijdstipMaterieel EN peiltijdstipMaterieel < eindRelatie EN beginGeldigheid <= peiltijdstipMaterieel EN peiltijdstipMaterieel < eindGeldigheid.

Han Welmer

Bij een relationele expressie wordt gesproken over twee expressies die met elkaar worden vergeleken met een operator, bijvoorbeeld beginGeldigheid <= peiltijdstipMaterieel, met als uitkomst waar of niet-waar (true/false). Het gebruik van “het kleinere element” en “het grotere element” is voorbarig, want dat is pas bekend nadat de expressies met elkaar vergeleken zijn (was beginGeldigheid inderdaad kleiner of gelijk aan peiltijdstipMaterieel?). Gebruikelijk is om te spreken van een linker expressie en een rechter expressie.

Han Welmer

Het zoeken naar het juiste voorkomen in de formele historie op een peiltijdstipFormeel levert een lastigere beschrijving op, omdat in het berichtenverkeer uitsluitend sprake is van tijdstipRegistratie, en niet van een combinaties startTijdstipRegistratie en stopTijdstipRegistratie: het voorkomen met de hoogste waarde voor tijdstipRegistratie waarvoor geldt dat tijdstipRegistratie <= peiltijdstipFormeel.

Han Welmer

Stel de database bevat twee voorkomens:
nr beginGeldigheid  eindGeldigheid
1  15-07-2012 00:00 15-07-2012 00:01
2  15-07-2012 00:01 leeg
en de peiltijdstipMaterieel is 15-07-2012

Volgens voorstel, waarbij ik aanneem dat beginGeldigheid de onnauwkeurigheid bevat en dus aangepast moet worden:
beginGeldigheid <= peiltijdstipMaterieel EN peiltijdstipMaterieel < eindGeldigheid
1: 15-07-2012 23:59 <= 15-07-2012 EN 15-07-2012 < 15-07-2012 23:59
   -> niet-waar
2: 15-07-2012 23:59 <= 15-07-2012 EN 15-07-2012 < leeg
   -> niet-waar
  
Andere interpretatie: peiltijdstipMaterieel bevat de onnauwkeurigheid en dus aanpassen:
beginGeldigheid <= peiltijdstipMaterieel EN peiltijdstipMaterieel < eindGeldigheid
1: 15-07-2012 00:00 <= 15-07-2012 23:59 EN 15-07-2012 23:59 < 15-07-2012 00:01
   -> niet-waar
2: 15-07-2012 00:01 <= 15-07-2012 23:59 EN 15-07-2012 23:59 < leeg
   -> waar
  
Alternatief: vergelijken op basis van nauwkeurigheid. Bijvoorbeeld door de datum/tijd om te zetten in een string en die af te breken op de minimale lengte (de grootste onnauwkeurigheid)
nr beginGeldigheid  eindGeldigheid   peiltijdstipMaterieel
1  15-07-2012 00:00 15-07-2012 00:01 15-07-2012
2  15-07-2012 00:01 leeg             15-07-2012
Omgezet naar strings:
nr beginGeldigheid  eindGeldigheid   peiltijdstipMaterieel
1  20120715         20120705         20120705
1  20120715         leeg             20120705
Vergelijken:
1: 20120705 <= 20120705 EN 20120705 < 20120705 -> niet waar
2: 20120705 <= 20120705 EN 20120705 < leeg     -> waar

Sid Brouwer

Volgens mij heeft dit ook veel te maken met de post over het al dan niet kleiner moeten zijn van datumGeldigheid oud en nieuw:

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

Han Welmer

Sid, dat klopt.

Het probleem bij die andere post is niet de inhoud van de berichten of het verwerken van de berichten.

Maar het probleem is wat er daarna met de opgeslagen data gedaan moet worden als er een vraag wordt gesteld of als er een bestaand voorkomen gewijzigd moet worden (kortom: kun je het juiste voorkomen terugvinden in de database).

John Rooijakkers

In patch 14 is in paragraag 6.4.5. de volgende tekst opgenomen: "In geval van niet tot op de milliseconde nauwkeurig gespecificeerde tijdstippen geldt dat in een kleiner dan relatie als waarde voor het kleinere element de grootst mogelijke waarde binnen de onnauwkeurigheids range genomen moet worden en als waarde voor het grotere element de kleinst mogelijke waarde binnen de onnauwkeurigheids range. Bij een groter dan relatie is het precies andersom. Voor het grotere element wordt dan als waarde de grootst mogelijke waarde in de onnauwkeurigheids range genomen en voor het kleinere element de kleinst mogelijke waarde in de onnauwkeurigheids range."

Ik mis in het document en deze post de reden waarom soms de "grootst mogelijke waarde" en soms de "kleinst mogelijke waarde" moet worden opgenomen. Zoals Han terecht opmerkt, leidt dit soms tot het onterecht (niet) selecteren van gegevens.

?Het is mij niet duidelijk waarom niet altijd de eenduidige regel wordt toegepast om "de kleinst mogelijke waarde (00..0) binnen de onnauwkeurigheids range" te gebruiken. In dit geval zullen gegevens eenduidig worden geselecteerd en is altijd een peiltijdstip te definiëren die een bepaalde selectie oplevert.

Robert Melskens

Bovenstaand fragment waaraan wordt gerefereerd komt uit een nooit gepubliceerde concept versie van de StUF standaard.

Robert Melskens

Dit Erratum is opgevoerd in de onderhoudsverzoeken als ERR254.
De lijst met onderhoudsverzoeken vind je op: 
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten

Robert Melskens

Tijdens de StUF Expertgroep van 18 juni 2014 is besloten dit erratum voorlopig weer als een onderhoudsverzoek te definieren (ONV0341).