Consequente en duidelijke oplossing voor historie about haal-centraal-brp-bevragen HOT 11 CLOSED

N.a.v. de discussie van vorige week (12-10) is besloten om bij het opvragen van een ingeschreven persoon alleen zijn actuele gegevens te retoureneren en historie in aparte gedefinieerde sub-resources onder te brengen.
Melvin gaf aan dat het wel belangrijk is om die subresources te kunnen "discoveren, dus deze subresources zijn nu wel in de _links van de ingeschreven persoon opgenomen, maar worden niet embedded aangeboden.
Dat laatste is weer in tegenspraak met een uitspraak van jeroen dat de gehele resource ontsloten moet worden en dat de afnemer zelf moet bepalen of gegevens embedded moeten worden opgenomen.

Een mogelijke oplossing is om vanuit de ingeschreven persoon naar de collectie van (bv) verblijfsplaatshistorie te verwijzen. Dus niet de Uri's van historische voorkomens onemen in de links..

Vraag is of dat conform de API_stratiegie is. Nader onderzoek volgt.

from haal-centraal-brp-bevragen.

In deze discussie lijkt alleen de materiële historie beschouwd te worden. Deze beschrijft de geldigheid in de werkelijkheid (begindatum en einddatum). In diverse situaties is ook de formele historie van belang. Deze beschrijft de opname van gegevens in de (authentieke) registratie (tijdstipregistratie). Ik stel voor om in deze discussie beide dimensies van de historie te beschouwen.

from haal-centraal-brp-bevragen.

De functionaliteit die destijds voor RSGB bevragingen 1.0 is geïnventariseerd raakt alleen materiële historie. Ik kan me ook herinneren dat in een bijeenkomst over de vervanging van StUF BG geconcludeerd werd dat formele historie nooit wordt gecommuniceerd/bevraagd.
Wanneer er wel concrete vraag is naar bepaalde formele historie hoor ik dat graag. Dat zou dan een user story moeten worden (feel free om die in te dienen!).

from haal-centraal-brp-bevragen.

Eens om formele historie pas te gaan beschouwen als hiervoor concrete vraag ontstaat. Hier zijn namelijk heel wat bomen over op te zetten (...).

Vanuit Operatie BRP bestond deze behoefte er alleen vanuit de rol 'gemeente als bijhouder'; niet vanuit de afnemers en ook niet vanuit de rol van 'gemeente als afnemer'.

Mogelijk in de toekomst wel vanuit burger-perspectief (inzagerecht), maar ondersteuning hiervan zou ik niet via deze bevraging-API laten verlopen; temeer daar er dan ook andere gegevens en/of bescheiden moeten worden verzameld om hier als gemeente invulling aan te geven.

from haal-centraal-brp-bevragen.

Graag aandacht voor het volgende:

1. Qua naamgeving vind ik 'GeldigVanaf' de lading beter dekken dan 'GeldigVan'

2. Aan de provider-zijde bij de invulling van 'GeldigTotEnMet' rekening houden met de definities in de BRP. Zo is de toelichting van 'Datum einde verblijfstitel': De datum waarop de verblijfstitel zijn geldigheid verliest' Oftewel de invulling van 'GeldigTotEnMet' is dan de inhoud van deze datum minus één dag. Tenzij ... tenzij deze datum (deels) onbekend is; dan is die dag aftrek niet nodig! Iets soortgelijks speelt bij ontbinding van huwelijk/geregistreerd partnerschap (Datum ontbinding is een 'tot'-datum).

Voor adreshistorie geldt dat voor het vullen van de 'GeldigTotEnMet' de volgende categorie moet worden bijgelezen om hiervan de Datum aanvang adreshouding (Datum aanvang adres buitenland) minus één dag te vullen (behalve bij (deels) onbekende datum).

Willen we in geval van Overleden personen ook een 'GeldigTotEnMet' bij adreshistorie vullen, dan deze ophalen uit de categorie Overlijden (in dit geval niet minus één dag; de persoon stond t/m z'n overlijden ingeschreven op dat adres).

NB. Deze semantiek te volgen; of de bron nu de BRP is of het Gegevensmagazijn. De provider-implementatie zal wezenlijk anders zijn. In een RSGB-magazijn zijn al regels toegepast om de BRP-inhoud om te zetten naar StUF BG.

from haal-centraal-brp-bevragen.

Ik ben het met je eens dat 'GeldigVanaf' duidelijker is dan 'GeldigVan'.

from haal-centraal-brp-bevragen.

De tot attributen in het model versus een generieke geldigTotEnMet is inderdaad een issue. Beide naast elkaar opnemen lijkt me niet handig.
Is het een werkbare oplossing te stellen dat we geldigTotEnMet gebruiken BEHALVE wanneer er een in het LO gedefinieerde einddatum is?

from haal-centraal-brp-bevragen.

Is het een werkbare oplossing te stellen dat we geldigTotEnMet gebruiken BEHALVE wanneer er een in het LO gedefinieerde einddatum is?

Ik begrijp niet goed wat je voorstel dan is in geval van 'BEHALVE wanneer ...'?

Een keuze maken voor geldigheidsperiodes; 'Vanaf - Tot' of 'Vanaf - TotEnMet'. Als het 'TotEnMet' is, dan in voorkomende gevallen rekening te houden met de betekenis van datum-velden in de GBA en zonodig één dag aftrek. Nader afstemmen met Gemeente-vertegenwoordigers.

from haal-centraal-brp-bevragen.

Ik begrijp niet goed wat je voorstel dan is in geval van 'BEHALVE wanneer ...'?
Ik bedoel in het voorstel dat wanneer een einddatum is opgenomen in het Lo GBA model (bijvoorbeeld 'Datum einde verblijfstitel' zou er niet (ook) een datum geldigTotEnMet worden opgenomen.

Is het niet erg risicovol om datums om te rekenen naar een geldigTotEnMet?
De beschrijving 'De datum waarop de verblijfstitel zijn geldigheid verliest' vind ik nog niet erg expliciet duiden op tot i.p.v. tot en met. Weten we dan zeker dat elk proces deze datum op dezelfde manier interpreteert en gebruikt?
Dus wanneer de consumer de omgerekende datum vervolgens weer mapt op de oorspronkelijke (interpretatie van de) LoGBA einddatum kan een fout ontstaan.

from haal-centraal-brp-bevragen.

Ben ik wel met je eens, dus moeten we niet doen.

Binnen Operatie BRP onderkenden we ook gegevensgroepen waarin gegevenselementen waren opgenomen met een materieel aspect (bv. de specifieke datumaanvang/einde velden binnen Huwelijk/GeregistreerdPartnerschap, Reisdocument, Verblijfstitel ). In dat geval zou je dan deze specifieke datums moeten opnemen en het gebruik van de elementen GeldigVanaf en GeldigTotEnMet vermijden.

Kijkend naar bv. categorie 04 - Nationaliteit wordt in de GBA alleen de GeldigVanaf (85.10 Ingangsdatum geldigheid) vastgelegd. De GeldigTotEnMet zou in ide gevallen afgeleid moeten worden van de IngangsdatumGeldigheid van de opvolgende categorie 04 van dezelfde Nationaliteit.

Idem voor de categorie Verblijfsplaats (08) als het gaat om de adreshistorie; zie eerdere opmerking. In die zin legt de GBA niet expliciet een GeldigTotEnMet vast.

from haal-centraal-brp-bevragen.

Uitgangspunt voor deze API is dat eenduidig en consequent gebruik over alle basisregistraties heen wordt nagestreefd. Daardoor komt de ontwikkelaar van een afnemer sneller tot een beter resultaat.
Soms zal een provider een mapping moet maken om dit voor elkaar te krijgen. Als de genoemde "specifieke datums" niet te mappen zijn op GeldigVanaf en GeldigTotEnMet, of als dit gevaarlijk wordt geacht, betekent dit dan niet dat dat de provider eigenlijk ook niet precies weet wat de datums betekenen en dat aan de consumer overgelaten hoe deze datums dan wel te interpreteren?
Dan gaat mijn voorkeur uit naar een interpretatie van de provider met kennis van het domein, en duidelijkheid over de betekenis voor de consumer/gebruiker, eenduidig voor alle basisgegevens. M.a.w. mappen naar GeldigVanaf en GeldigTotEnMet.

from haal-centraal-brp-bevragen.