Dit erratum is ontstaan naar aanleiding van discussies met het programma Modernisering GBA over de omgang met historie binnen de Basisregistratie Personen en binnen StUF. Deze discussies hebben tot de conclusie geleid dat de beschrijving van formele en materiële historie binnen de StUF-standaard niet helemaal correct is. We willen de deskundigen van de BRP hartelijk danken voor hun inbreng van kennis op het lastige domein van materiële en formele historie.
Dit erratum bestaat uit aanpassing van secties 5.4.2 en 6.4.6 van de stuf0301 standaard. De aanpassingen zijn in geel zichtbaar gemaakt in de bestanden Erratum5.4.2.pdf en Erratum6.4.6.pdf.
Erratum6.4.6.pdf
Bijlage
De bovengenoemde bestanden verwijzen naar de bijlage 'Representatie materiële en formele historie' dat te vinden is via TheorieHistorie2.pdf
Bijlage
Ik zie een tegenstrijdigheid in de aangepaste secties. Misschien kan iemand dat bevestigen of ontkennen.
In 5.4.2 in genummerd item 1 staat namelijk:
Het mag niet voorkomen dat verschillende registraties van het object of verschillende registraties van een relatie hetzelfde tijdstipRegistratie (of vervangende beginGeldigheid of beginRelatie) hebben. Wanneer dit toch het geval is, dan kan het synchronisatiebericht historisch niet worden aangemaakt en dient een en ander eerst gecorrigeerd te worden in de registratie.
Terwijl iets verderop in genummerd item 3 staat (zonder renvoooi):
Er gelden speciale regels gecorrigeerdals er op één tijdstipRegistratie verschillende wijzigingen zijn doorgevoerd (er zijn in de standaard of linked list representatie meerdere blokken met dezelfde beginRegistratie (=tijdstipRegistratie).
Han, je hebt helemaal gelijk. In het genummerd item 1 zullen de laatste vijf regels (vanaf '... Het is mogelijk' ook geschrapt moeten worden om een consistente spec te hebben.
Bedankt voor je opmerkzaamheid.
Als ik het goed begrijp is er vanuit BPR behoefte om geen waarde of gelijke waarden voor tijdstipregistratie toe te staan bij opeenvolgende mutaties van een en hetzelfde object.
Op het terrein van materiele historie heb ik ook al een post geplaatst, daar over het toestaan van gelijke waarden voor beginGeldigheid van een en hetzelfde object. Ik herhaal hier kort mijn bezwaar tegen dat voorstel: StUF 03.01 veronderstelt voor de correcte verwerking van wijzigingen en correcties dat ieder voorkomen van een object in de materiele histore uniek kan worden aangeduid door de combinatie van semantische sleutel en begingeldigheid.
In dit voorstel wordt het huidige uitgangspunt van formele historie ondergraven: ieder voorkomen van een object in de formele histore kan worden kan uniek worden aangeduid door de combinatie van semantische sleutel en tijdstipregistratie.
Los van alle goede bedoelingen en pogingen voorzie ik fundamentele problemen als de uitgangspunten voor de opbouw van materiele en/of formele historie worden los gelaten.
Na wat heen en weer overleg tussen Maarten vd Broek en mijzelf is duidelijk geworden dat de tekst in de STUF standaard nog niet strak genoeg is gedefinieerd, ik had deze anders geïnterpreteerd dan Maarten had bedoeld. Hij zal hier nog een aanpassing op doorvoeren en opnemen op het forum.
Ik heb tijdens dit overleg van Maarten een Excel-sheet gebruikt om de verschillende situaties visueel eenvoudig te kunnen bespreken. Deze excel sheet heb ik bijgevoegd (zie bijlage).
Bijlage
Beste “historians”,
Ik ben vandaag gestart om de bijlage “materiële en formele historie'” door te nemen, maar na het lezen van paragraaf 3 heb ik de sterke behoefte om mijn bevindingen ten aanzien van deze paragraaf te posten en te toetsen.
EindeRegistratie
Gedurende het eerste deel van paragraaf 3 (pagina 3) lijkt het erop dat de standaard representatie en de linked list representatie zich onderscheiden doordat in de linked list representatie geen gebruik gemaakt wordt van het metagegeven eindRegistratie. Dit wordt bevestigd door de mutaties en correcties op pagina 3. Op pagina 4 wordt echter ineens wel gebruik gemaakt van het metagegeven eindRegistratie. Het is niet duidelijk welke deel van paragraaf 3 hierin correct is.
Meer informatie
In de eerste paragraaf van paragraaf 3 wordt gesteld dat het blokkendiagram in figuur 1 “meer informatie bevat dan strikt noodzakelijk is” (door het splitsen van Spui in twee periodes van registratie). Bij de linked list wordt inderdaad niet vastgelegd op welk tijdstip het record Spui een eindGeldigheid heeft gekregen. Ik kan echter niet vaststellen of dit informatie is die niet strikt noodzakelijk is. Daartegenover bestaat bij de standaard representatie geen noodzaak tot het (niet evident) linken van records, wat bij de linked list representatie wel vereist is.
Verschillende Algoritmen
In paragraaf 3 worden verschillende algoritmen gebruikt om te bepalen wat de waarde is op een tijdstipMaterieel groter dan Tmx en een tijdstipFormeel tussen Tfi en Tfj. Onder Figuur 5 wordt een ander algoritme (algoritme A) gebruikt dan boven figuur 7 en boven figuur 8 (algoritme B). Indien we algoritme B toepassen op de situatie onder figuur 5 dan leidt dit niet tot Spui maar tot de conclusie dat Korte Poten geen link heeft die gevolgd zou moeten worden.
Ook de algoritmes voor het opbouwen van de formele historie bij figuur 6 en figuur7 lijken van elkaar af te wijken, maar wellicht komt dit doordat in de eerste situatie geen gebruik gemaakt wordt van het metagegeven eindRegistratie en in de tweede situatie wel (zie eerdere opmerking).
Expressies
Op diverse plaatsen in de tekst staan “expressies” die op het oog eenvoudig zijn uit te voeren door het kijken naar de bijgaande figuur, maar waarvan het niet duidelijk is hoe deze als formele expressie geautomatiseerd kunnen en moeten worden. Het gaat hierbij om de volgende “expressies”:
- “… en een link naar het record voor Korte Poten.” (naast figuur 6)
- “… het (er)onderliggende record …” (diverse plaatsen op pagina 4)
- “… alle formeel historische records waar Lange poten direct op ligt.” (pagina 4 bovenaan)
Daarnaast is het doel en de implementatie van de laatste zin van de paragraaf onder figuur 8 (“Een link … wordt overgenomen in het nieuwe record, als …”) voor mij niet duidelijk.
Complexiteit
Los van de juistheid van de toe te passen expressies, vind ik de expressies om een waarde binnen de materiele en formele historie te vinden (onder figuur 5, boven figuur 7 en boven figuur 8) complex. Tevens verwacht ik dat het zoeken in een database van “het record met de grootste waarde van beginRegistratie kleiner dan het gevraagde tijdstipMaterieel en de grootste waarde van eindGeldigheid kleiner dan het gevraagde tijdstipmaterieel” tot performance problemen kan leiden.
Paragraaf 3 eindigt met de constatering dat correcties in de praktijk minder vaak voorkomen dan normale wijzigingen en dat daarom de linked list representatie de voorkeur verdient omdat hierbij minder records worden geschreven.
Ik kom op basis van een aantal argumenten echter tot de conclusie dat de standaard representatie de voorkeur verdient:
- Het bestuderen en begrijpen van de standaard representatie kostte me ongeveer een kwartier en bij de linked list representatie duurde dit ruim anderhalf uur. Dit maakt deze laatste representatie (voor mij) “een factor 6” complexer en daardoor (naar mijn mening) veel te complex en alleen daarom al ongewenst.
- Het aantal registraties dat belang heeft bij formele (en materiële) historie is vele malen kleiner dan het aantal registraties dat belang heeft bij alleen materiele historie (of überhaupt geen historie).
- Het verwerken van mijn eerder gemaakte opmerkingen zal de complexiteit van het geheel zeker niet doen afnemen en wellicht dat bepaalde algoritmes zelfs niet (eenduidig) implementeerbaar blijken op basis van de te automatiseren formele expressies.
Ik ben er tenslotte niet aan begonnen om uitgaande van figuur 9 te ontdekken wat er bij de linked list implementatie moet gebeuren indien op dat moment het verblijf gedurende de periode Tm1 tot Tm3 gecorrigeerd moet worden in Lange poten J.
Met vriendelijke groeten,
John Rooijakkers.
PS: Na het herlezen van bovenstaande concludeerde ik dat deze post wellicht als “erg negatief” kan overkomen. Degenen die mij kennen weten dat dit absoluut niet zo bedoeld is en dat ik slechts duidelijkheid en een goede, eenduidige en liefst niet te complexe standaard wil bereiken. Voor degenen die mij niet kennen wilde ik dit toch even expliciet vermelden.
Ik bleek het erratum van het antwoordbericht per ongeluk overschreven te hebben met het erratum voor de synchronisatie. Beide documenten bevatten dezelfde tekst. Ik heb inmiddels Henri verbeterde versies van beide paragrafen uit de StUF-standaard gemaild. Ik hoop dat hij de verbeterde document zo snel mogelijk post, zodat iedereen er kennis van kan nemen
Het document over de synchronisatie is licht gewijzigd naar aanleiding van het commentaar van Mark Paanakker.
Ik heb in de paragraaf over de La09 en La10 antwoordberichten het voorbeeld uit het begin van de StUF-standaard vertaald naar een blokdiagram voor de linked list representatie en van daaruit het voorbeeldbericht verbeterd. Ik hoop dat dit complexe voorbeeld wat meer inzicht geeft hoe een en ander nu geacht wordt te werken in de standaard. De blokrepresentatie maakt het redeneren erover veel eenvoudiger.
@John,
Zo negatief vond ik je reactie niet. Ik heb zelf ook behoorlijk geworsteld met het probleem en ben helemaal met je eens dat de standaard representatie eenvoudiger te doorgronden is. Ik hoop dat je nog wat hebt aan het voorbeeld in paragraaf 6.4.6.
Ik heb de foute bestanden vervangen door de goede.
Deze kunt u in het bijgevoegde zip bestand vinden (vervang de extensie 'txt' door 'zip').
Bijlage
Ik heb het document 'TheorieHistorie2.pdf' doorgenomen tot paragraaf 5.2 en net als John de conclusie getrokken dat het behoorlijk complex is en lastig om tot je te nemen. Op enkele plaatsen zag ik echter mogelijkheden om het document te verbeteren door enkele teksten net even iets anders te formuleren.
Voorstellen daartoe doe ik in het bijgevoegde bestand.
Op pagina 4 onderaan ben ik nog even ingegaan op een situatie waarin de voorgestelde methode mogelijk nog niet helemaal voldoet. Ik ben er alleen niet zeker van of de geschetste situatie in de realiteit ook voor kan komen.
Bijlage
Bij deze de laatste versie van de 'TheorieHistorie' document: TheorieHistorie4.pdf.
Bijlage
Deze discussie is als RFC en erratum opgevoerd in de onderhoudsverzoeken, resp. als RFC0141 en ERR265.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Hierbij een zip met de laatste door Maarten van den Broek bewerkte versie van de StUF standaard (zowel met renvooi als zonder renvooi). Deze versie bevat diverse verbeteringen en correcties o.a. naar aanleiding van de errata ERR242, ERR248, ERR249, ERR252, ERR265 en ERR303.
Bijlage
Het erratum ERR265 is doorgevoerd in patch 20 (1 juli 2014).
De laatste inzichten zijn nu verwerkt in de StUF standaard en daarmee is op een wat andere manier dan oorspronkelijk beoogd invulling gegeven aan dit erratum.
Tijdens de StUF Expertgroep van 16 september 2015 is besloten RFC0141 af te voeren.