Onduidelijkheid m.b.t. extraElements begindatumTijdvakGeldigheidBAG en einddatumTijdvakGeldigheidBAG

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

12 reacties / 0 nieuw
Robert Melskens
Onduidelijkheid m.b.t. extraElements begindatumTijdvakGeldigheidBAG en einddatumTijdvakGeldigheidBAG

In het StUF Testplatform is de testregel 'BGWZ000003' gedefinieerd op basis van de volgende alinea uit de koppelvlakspecificatie van het koppelvlak BAG (pagina 5 net boven hoofdstuk 5):

'Een BAG (BAG+) applicatie is niet verplicht om het tijdvakGeldigheid conform StUF te registreren. Zo niet, dan worden beginGeldigheid en eindGeldigheid conform StUF gevuld met dezelfde waarden als de extraElements begindatumTijdvakGeldigheidBAG en einddatumTijdvakGeldigheidBAG.'

De eerste zin is wat mij betreft duidelijk maar voor de volgende zin geldt dat niet. Alleen al de woordjes 'Zo niet' geven reden tot verwarring.

  • Wordt hier bedoeld dat als het niet verplicht is de elementen beginGeldigheid en eindGeldigheid conform StUF gevuld moeten worden met dezelfde waarden als de extraElements begindatumTijdvakGeldigheidBAG en einddatumTijdvakGeldigheidBAG?
  • Of wordt hier juist bedoeld dat als het wel verplicht is de elementen beginGeldigheid en eindGeldigheid conform StUF gevuld moeten worden met dezelfde waarden als de extraElements begindatumTijdvakGeldigheidBAG en einddatumTijdvakGeldigheidBAG?

De testregel 'BGWZ000003' waar ik het aan het begin van deze discussie over had is nu in ieder geval zo ingericht dat:

  • het element beginGeldigheid dezelfde waarde moet hebben als het extraElement begindatumTijdvakGeldigheidBAG.
  • en het element eindGeldigheid dezelfde waarde moet hebben als het extraElement einddatumTijdvakGeldigheidBAG.

Of dat correct is vraag ik me echter af. Juist om de eerste zin van de alinea van de koppelvlakspecificatie waarin gesteld wordt dat dit niet verplicht is!

De toelichting van beide extraElementen in de documentatie behorende bij de berichtencatalogus BAG kan mogelijk ook wat duidelijker. Ik vermoed dat het de bedoeling is om de extraElementen begindatumTijdvakGeldigheidBAG en einddatumTijdvakGeldigheidBAG te gebruiken voor het doorgeven van de tijdvakGeldigheid van alle attributen van belang voor de Basisregistratie adressen en gebouwen (BAG) en dat de elementen beginGeldigheid en eindGeldigheid moeten worden gebruikt voor het doorgeven van de tijdvakGeldigheid van de andere attributen. Dit mag wat mij betreft expliciet vermeldt worden.

Ik heb dus 3 verzoeken:

  1. Verwoord de betreffende alinea in de koppelvlakspecificatie BAG zo dat het niet tot verwarring leidt;
  2. Geef aan of in de bewuste testregel 'BGWZ000003' de standaard goed geinterpreteerd is;
  3. Bekijk of de toelichting van beide extraElementen in de documentatie behorende bij de berichtencatalogus BAG beter kan.
Robert Melskens

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

Sid Brouwer

Volgens mij is bedoeld:

Als de BAG-applicatie geen tijdvak geldigheid registreerd conform RSGB/StUF (maar alleen die conform de BAG-specificaties), dan worden de elementen beginGeldigheid en eindGeldigheid  gevuld met dezelfde waarden als resp. de extraElement-en begindatumTijdvakGeldigheidBAG en einddatumTijdvakGeldigheidBAG.

De regels op het STP zijn dan incorrect, aangezien deze datums dus weldegelijk mogen verschillen, als de BAG-applicatie beide tijdlijnen ondersteunt. Alleen als de BAG enkel de BAG-tijdlijn ondersteunt, moeten beide combinaties gelijk zijn.

Robert Melskens

In het bijgaande voorstel heb ik op basis van het antwoord van Sid de betreffende alinea uit de koppelvlakspecificatie van het koppelvlak BAG (pagina 5 net boven hoofdstuk 5) aangepast.

Indien dit door de StUF Expertgroep wordt goedgekeurd dient testregel 'BGWZ000003' ook te worden aangepast.

Bijlage

Koppelvlak BAG - ONV0360.pdf
Robert Melskens

Tijdens de StUF Expertgroep van 17 februari 2016 is het voorstel voor de oplossing van dit probleem goedgekeurd. De oplossing zal meegenomen worden in de patch (24) van april 2016. Het onderhoudsverzoek is omgezet naar een erratum (ERR0360).

Tevens is een verzoek ingediend om testregel 'BGWZ000003' aan te passen.

Robert Melskens

Naar aanleiding van het verzoek om testregel 'BGWZ000003' in het StUF testplatform aan te passen is mij de vraag gesteld of het vullen van de elementen 'tijdvakGeldigheid/beginGeldigheid' en 'tijdvakgeldigheid/eindGeldigheid' met de waarde van 'begindatumTijdvakGeldigheidBAG' resp. 'einddatumTijdvakGeldigheidBAG' kan leiden tot situaties die niet geldig zijn volgens StUF, zoals:

  • tijdvakGeldigheid/beginGeldigheid is leeg waar een waarde verwacht wordt (bijv. in Lk01 met verwerkingssoort T of W)
  • tijdvakGeldigheid/eindGeldigheid object1 <> beginGeldigheid object2 (Is dit toegestaan voor BAG berichten? In STP gaat regel STV0000051 dan af)
  • tijdvakGeldigheid/eindgeldigheid heeft een waarde waar dat niet verwacht wordt (bijv. Lk01 verwerkingssoort W in object2. Is dit dan toegestaan voor BAG berichten? In STP gaat regel STV0000021 dan af)

Dit is van belang omdat in dat geval niet alleen regel BGWZ000003 moet worden aangepast, maar ook algemene StUF regels die hierover gaan.

Robert Melskens

Tijdens de StUF Expertgroep van 18 mei 2016 heeft Sid aangegeven dat hij denkt dat de twee extraelementen elementen voldoen aan de StUF regels. Hierop zou je de BAG nog na kunnen lopen. Maarten heeft het echter geïmplementeerd en is nog geen problemen tegen gekomen.

Frank Samwel

In komende release 1.11.1 van het StUF Testplatform zal regel BGWZ000003 geen fout meer geven wanneer tijdvakGeldigheid afwijkt van extraElement-en begindatumTijdvakGeldigheidBAG en einddatumTijdvakGeldigheidBAG. Het geeft dan slechts een waarschuwing.

Sid Brouwer

Helaas ben ik nu toch tegen een situatie aangekomen waarin er problemen ontstaan met begin- en einddatum:

De BAG berichtencatalogus/koppelvlak heeft een gebeurtenis voor het corrigeren van gegevens. Hiervoor worden, binnen de Lk03, correcties met formele historie verzonden (mutatiesoort F). Binnen de BAG zelf (uitgaande van alleen registratie van de tijdlijn conform BAG) is dit echter een 'gewone' mutatie waarbij een nieuwe beginGeldigheid ontstaat en de oude situatie wordt afgesloten met een eindGeldigheid.

StUF verbiedt in een correctie om waarden op te geven voor de eindGeldigheid (zie tabel 5.3 en 5.4 op pagina's 59 en 60). Daarnaast zou een afwijkende beginGeldigheid (oud heeft een lagere waarde dan nieuw) betekenen dat de te corrigeren gegevens ook pas geldig zijn vanaf die nieuwe datum. De situatie voor de te corrigeren situatie zou daarmee (materieel historisch gezien) opeens helemaal over de te corrigeren situatie komen te liggen (in de BAG is de beginGeldigheid immers de datum waarop de fout is geconstateerd).

Conclusie: we moeten hier nog eens goed naar kijken en er zal een uitspraak moeten komen over hoe in correctieberichten (bagCOR) moet worden omgegaan met de beginGeldigheid en eindGeldigheid.

Robert Melskens

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

Maarten van den...

Gegeven deze discussie lijkt de zinssnede 'Zo niet, dan worden beginGeldigheid en eindGeldigheid conform StUF gevuld met dezelfde waarden als de extraElements begindatumTijdvakGeldigheidBAG en einddatumTijdvakGeldigheidBAG.' uit de BAG berichtencatalogus (zie post #1) me niet correct te zijn. Hetzelfde geldt dan overigens voor de definitie van de historieMaterieel elementen voor de BAG-objecten in vraag/antwoord catalogus van bg0310, want hierin zijn allerlei elementen opgenomen waarvan de BAG bronhouder is. Deze elementen kunnen niet vallen onder het door StUF gedefinieerde regime voor materiële historie.

Het lijkt beter om te specificeren dat alleen elementen waarvan de BAG geen bronhouder is materiële historie kunnen hebben binnen een BAG-object, bijvoorbeeld het aantal kamers in een verblijfsobject. Wijzigingen in gegevens waarvan de BAG bronhouder is krijgen dan uitsluitend formele historie en de tijdslijn gedefinieerd door de BAG wordt meegenomen in wat nu de extraElementen begindatumTijdvakGeldigheidBAG en einddatumTijdvakGeldigheidBAG. Het door Sid in post #9 genoemde probleem is dan ook opgelost, want de berichten vanuit de BAG bevatten dan geen tijdvakGeldigheid meer.

Het doorvoeren van deze wijzigingen als erratum heeft naar alle waarschijnlijkheid te veel impact. Een correcte specificatie van de historie is dan pas mogelijk in de opvolger van bg0310.

Robert Melskens

Tijdens de StUF Expertgroep van 15 maart is besloten dit onderhoudsverzoek om te zetten naar een RFC (RFC0455).