Een van de adagia bij het verstuffen van een sectormodel is dat de berichtinhoud voldoet aan een informatiebehoefte. Dat lijkt me zinvol. Een bericht moet een doel hebben en de inhoud van het bericht moet daarop zijn afgestemd.
Zo bevatten de AOA, TGO, NPS en WOZ berichten enkele adreselementen die zijn platgeslagen uit de AOA, OPR, GOR en WPL.
In de BAG berichtencatalogus is een waterval voorgeschreven, wat kort gezicht inhoud dat bij wijzigen van bijvoorbeeld een WPL de BAG applicatie niet alleen een wijzigkennisgeving van de WPL moet versturen, maar ook een waterval van OPR, AOA en TGO berichten met gewijzigde adresgegevens.
Kort samengevat: in dit opzicht gebruikt BG 03.10 geen genormaliseerd gegevensmodel.
Tijdens de implementatie van de BAG berichtencatalogus in onze BAG applicatie zijn wij tegen het probleem gelopen dat dit uitgangspunt moeilijk verenigbaar is met het genormaliseerde gegevensmodel van de BRA/BGR. Voor dat koppelvlak hoeft in het beschreven voorbeeld alleen een WPL wijzigkennisgeving worden verstuurd. Het probleem zit hem niet zozeer in het wel/niet versturen van de waterval. Het wezenlijke probleem is dat er verschillende voorkomens ontstaan voor OPR, AOA en TGO bij binnengemeentelijke afnemers in vergelijking tot de voorkomens van OPR, NUM en VBO/LIG/STA in de LV-BAG. En dat de BAG applicatie deze voorkomens moet maken, onthouden en desgewenst kunnen reproduceren (synchronisatie).
Onze conclusie is dat een BAG applicatie er een dubbele of een complexe administatie op na met houden met voorkomens die zijn verstuurd naar de LV-BAG dan wel aan binnengemeentelijke afnemers.
Wij stellen dan ook indringend de vraag of de voordelen van de platgeslagen gegevens en/of de waterval wel opwegen tegen de daaruit voortvloeiende nadelen?
Hallo Han,
Ik snap niet waarom je in de BAG applicatie een dubbele of complexe administratie moet bijhouden met voorkomens die zijn verstuurd naar de LV BAG dan wel binnengemeentelijke afnemers.
Bij het afhandelen in de applicatie van een gebeurtenis zoals gedefinieerd in het processenhandboek BAG wordt bij het bevestigen hiervan (bij voorkeur in één transactie, maar strikt noodzakelijk is dit niet) de twee berichten aangemaakt die voortvloeien uit deze gebeurtenis. Dit is in geval van een wijziging van een woonplaatsnaam één klein bericht voor de LV BAG en het bericht braHWP_Lk03 conform de berichtencatalogus BAG met daarin kennisgevingen voor alle geraakte BAG(+) objecten.
In een gemeente als Amsterdam gaat het om ruwweg een miljoen berichten en kan het braHWP_Lk03 bericht circa 1 gigabyte groot worden. Het aanmaken lijkt me zelfs voor Amsterdam geen onmogelijke opgave, maar de verwerking vergt nogal wat resources. Het verwerken van een tiende van deze omvang lijkt mij praktisch haalbaar, zo lang je het maar niet in één transactie doet. Hoe je een dergelijk bericht verwerkt is overigens niet de zorg van de BAG applicatie, want die hoeft het alleen maar aan te maken.
Ik kan me voorstellen dat het handig is om een alternatief te bedenken voor de vernaming van een woonplaats. Overigens blijft dan het probleem bestaan dat heel veel applicaties in hun database de woonplaatsnaam niet uit het adres hebben genormaliseerd en bij een wijziging in de woonplaatsnaam dus heel veel records moeten aanpassen. Dit gaat natuurlijk gemakkelijker met een speciaal SQL update statement.
Synchronisatieberichten moeten vanuit de genormaliseerde BAG database in mijn ogen zonder probleem geproduceerd kunnen worden voor een willekeurig object. Of er verschillende voorkomens ontstaan van OPR, AOA en TGO bij binnengemeentelijke afnemers en de LV BAG is een implementatie issue waar het berichtenverkeer heel bewust van abstraheert. Een BAG applicatie hoeft slechts vanuit haar eigen database de situatie in de LV BAG te kunnen reproduceren in de vorm voorgeschreven vanuit de berichtencatalogus BAG en bg0310.
Maarten
Maak maar eens berichten voor de LV-BAG en de BAG berichtencatalogus voor de volgende gebeurtenissen:
en ga na wat de waarden voor tijdvakgeldigheidBAG, materiele historie en formele historie zijn van het NUM/AOA object.
Met name de laatste zin uit de bovenstaande reactie van Han is inderdaad een lastig punt: je moet als BAG-registratie voor nummeraanduidingen een tijdlijn opnemen voor de binnengemeentelijke verzending van StUF-berichten. De datum geldigheid kan namelijk gelijk zijn aan de datum van de eraan gekoppelde openbare ruimte of woonplaats.
Dit betekent dat de verzendende partij zich in wat bochten moet wringen om die datum te reproduceren: het is niet afleidbaar uit één attribuut binnen het gegevensmodel, maar van drie (gelijknamige) atributen van drie verschillende objecten.
Deze discussie is overigens al eerder gevoerd...
In aanvulling op mijn vorige post: de discussie staat nog op het oude forum:
tijdvakGeldigheid in geval van platgeslagen relaties
Als ik het goed zie dan zitten Sid en ik op één lijn:
Volgens mij stellen wij beiden de vraag of deze extra belasting voor het zendende systeem wel opweegt tegen de vermeende maar niet onderbouwde informatiebehoefte.
Mijns inziens zijn er voldoende alternatieven, met mogelijkerwijs minder overlast, om een nader onderzoek te rechtvaardigen. Maar dan moet die veronderstelde informatiebehoefte wel expliciet gemaakt worden, zodat de nadelen voor de (afnemende, disttribuerende of) andere systemen in kaart kunnen worden gebracht.
Ik wil hierop graag reageren vanuit de GBA-hoek. Vanuit het Logisch ontwerp GBA is het essentieel dat er altijd een nieuwe datum geldigheid is bij wijziging van de openbare ruimte- en woonplaatsnaam. Deze moet worden opgenomen als datum aanvang adreshouding en -geldigheid van de nieuw aan te leggen categorie 08 (Verblijfplaats). Voor GBA-systemen is het dus een must dat de nieuwe datum geldigheid aangeleverd wordt.
Bij deze discussie speelt ook het feit dat de meeste afnemerssystemen helemaal geen adres-entiteit kennen. Die registreren bij een subject vaak alleen losse gegevenselementen zoals naam openbare ruimte, huisnummer en woonplaatsnaam. We kunnen we niet al deze systemen opleggen om zowel adressen als openbare ruimten als woonplaatsen te gaan registreren, wat wel nodig is als we in StUF geen platgeslagen entiteiten ondersteunen.
Gezien de voorschriften in de BAG-GBA-koppelvlakspecificaties en voor de afnemerssystemen zou ik er dan ook voor willen pleiten om dit soort infrastructurele wijzigingen op adresnivo door te blijven geven. Bij wijzigingen lijkt me dit voor de nieuwe datum geldigheid geen probleem, maar voor de oude kan dit inderdaad wel ingewikkeld worden. Om dit voor zendende systemen (ic. BAG) te vereenvoudigen zou het wellicht een optie zijn om in de oude datum geldigheid in voorkomende gevallen de waarde "Onbekend" op te nemen, de datum geldigheid is in de regel immers geen identificerend gegeven.
Ook voor antwoordberichten is in overleg tussen de diverse partijen wellicht een praktische oplossing denkbaar. Een oplossing waarbij misschien geen 100%-score gehaald wordt, maar waarbij wel de "verhuisbewegingen" van subjecten goed in beeld blijven. Voor andere platgeslagen entiteiten (m.n. TGO/NNP) heb ik een minder scherp beeld, maar er zal dan beoordeeld/geinventariseerd moeten worden wat de exacte informatiebehoeften op dit gebied zijn, m.n. vanuit ontvangende afnemerssystemen.
Er is op 16 november hier ook over gediscussieerd in de StUF expertgroep. Daar kwam naar voren dat er ooit is besproken om voor platgeslagen gegevens in de entiteit waarin ze zijn platgeslagen geen historie te definiëren. Een vernaming van een straatnaam wordt dan dus in een AOA-bericht doorgegeven zonder beginGeldigheid en eindGeldigheid, want in de AOA als BAG-object is helemaal niets veranderd. Als je de historie van vernamen en vernummeren in een adres wilt weten, dan zul je deze moeten nazoeken in OPR.
Bij een check in de schema's bleek dit daar niet te zijn geïmplementeerd. Deze discussie wordt voortgezet in de volgende expertgroep.
Ik begrijp de informatiebehoefte zoals beschreven door Frans. Maar ik ben het niet eens met zijn conclusie dat als een AOA geen platgeslagen straatnaam etc heeft dat dan de GBA applicaties adressen, straten en woonplaatsen moeten gaan implementeren.
Zoals ik het zie zal een GBA applicatie in het geval van een AOA was/wordt bericht met daarin huisnummer, straatnaam, woonplaatsnaam, etc de PL-records aanpassen waarvan de huidige adresvelden overeenkomen met de was-situatie in het AOA bericht.
Mijns inziens kan een GBA applicatie in het geval van een AOA bericht zonder platgeslagen adresgevevens (dus alleen huisnummer en OPR idientificatie maar geen straatnaam, woonplaatsnaam, etc vrij eenvoudig naast de AOA berichten ook de afhandeling van WPL en OPR berichten implementeren. De adresvelden in een PL record moeten in dat geval bij een aansluiting op de BAG worden uitgebreid met identifcatiecodes voor AOA, OPR en WPL. Bij ontvangst van een AOA bericht worden die PL-records gemuteerd waarvan de OPR identficatie, huisnummer etc overeenkomen met de was-situatie van het AOA bericht. Mutatis mutandis voor de OPR en WPL berichten: bij ontvangst van een OPR bericht worden die PL-records gemuteerd waarvan de WPL identficatie, straatnaam etc overeenkomen met de was-situatie van het OPR bericht; bij ontvangs van een WPL bericht worden die PL-records gemuteerd waarvan de WPL identficatie overeenkomt met de was-situatie van het WPL bericht.
Kortom: ik zie geen technische reden waarom platgeslagen gegevens nodig zijn. Ik constateer (!) wel allerlei technische obstakels als we vasthouden aan platgeslagen gegevens.
Het is ondertussen 14 maart. En er is nog steeds geen uitsluitsel op dit isseu. Deze vertraging belemmerd de uitlevering van onze RSGB conforme BAG applicaties aanzienlijk.
Deze discussie heeft geleid tot een erratum waarin platgeslagen gegevens in de complex types van "...historieMaterieel" en "...historieFormeel" in vraag- en antwoordberichten worden verwijderd. Dit erratum wordt meegenomen in de aankomende patch van 1 april.
Echter jouw vraag om uberhaupt geen platgeslagen meer te gebruiken gaat veel verder en is een behoorlijk ingrijpende RFC. We hebben hier al een aantal keer in de expertgroep over gesproken en hierover helaas geen consensus bereikt.
Bij het uitwerken van bovengenoemd erratum voor de patch van 1 april waren we er achter gekomen dat het probleem toch complexer was dan we aanvankelijk dachten. Dit hebben we in de afgelopen expertgroep van april besproken. Inmiddels is er een nieuw voorstel hoe om te gaan met historie van platgeslagen gegevens, zie de bijlage.
Ben benieuwd naar jullie reactie (natuurlijk liefst via een post naar deze forumdiscussie)!
Bijlage
Het voorstel van Henri is op zich een logisch voorstel dat aansluit bij de principes die zijn gesteld.
In de praktijk zien we (Centric) toch nog wel een belangrijk risico:
Afnemers die alleen de platgeslagen gegevens krijgen en geen interesse hebben in de onderliggende entiteiten, kunnen aan de berichten niet zien welke ingangsdatum moet worden toegepast.
Een voorbeeld: een GBA-systeem dat geen afnemer is van straat-berichten weet bij een hernoeming van een openbare ruimte welke personen moeten worden 'verhuisd', maar kan aan de AOA-berichten zelf niet zien per wanneer deze wijziging moet worden doorgevoerd. Voor historie op de adresgegevens van de persoon is dit wel wenselijk.
Een vraag die we onszelf misschien nog eens moeten stellen is welk probleem we nu aan het oplossen zijn. Aanvankelijk waren er twee problemen aan de orde:
het grote aantal berichten bij een wijziging zoals een hernoeming van een straat of woonplaats;
het niet één op één kunnen vertalen van de ingangsdatum van een AOA (zeker in het oude voorkomen in een kennisgevingsbericht) naar één attribuut uit het RSGB.
Van het eerste probleem is gesteld dat we dat niet aan gaan pakken en het voorstel doet dit ook niet.
Het tweede probleem wordt opgelost door het voorstel echter met mogelijk nadelige gevolgen voor afnemers.
Onze indruk is dat de meeste BAG-leveranciers inmiddels een datum meesturen die is afgeleid van verschillende andere datums begin geldigheid (in een AOA kan deze afhangen van nummeraanduiding, openbare ruimte of woonplaats). Hiermee is het probleem feitelijk al uit de wereld geholpen en lijkt het ons verstandig vooral (eenduidig) vast te leggen wat er in de huidige praktijk wordt gedaan.
In discussie met Maarten en de Waarderingskamer is een verduidelijking naar voren gekomen die kan helpen de gekozen manier van werken beter te motiveren. Deze verduidelijking is gerenvooieerd toegevoegd aan een nieuwe versie van het document (zie bijlage).
Bijlage
De beschrijving van de oplossing in het document 'Verwerkte onderhoudsverzoeken-2012-09-12.doc verspreid als voorbereiding op de expertgroep van 19-9-2012 voor ERR200 lijkt me niet correct. Het is aan de ontwerper van het sectormodel welke gegevens'van de 'gerelateerde' getoond dienen te worden in een historisch voorkomen na verandering van een 'relatie'. In het voorbeeld van adresaanduidingGrp is het niet wenselijk om van historische adressen alleen de identificatie, de postcode en de locatieaanduiding te tonen.
In de nieuwe versie van de standaard lijkt dit overigens ook niet opgenomen (ik heb het bij snelle inspectie in elk geval niet kunnen vinden). Het is natuurlijk wel wenselijk dat de tekst in het onderhoudsverzoeken document en de doorgevoerde wijzigingen met elkaar in overeenstemming is.
In de StUF-expert vergadering van 19 september 2012 is besloten dat:
Hoi Han,
de eerste twee besluiten die jij noemt zijn inderdaad genomen. Het derde bullet is nog geen besluit. Deze verscherping op de standaard moet nog worden goedgekeurd en kan dan worden meegenomen in de volgende patch. Voor dit erratum zullen we een nieuwe post plaatsen en we zullen het toevoegen aan de onderhoudsverzoeken.
Mvg,
Henri
In de StUF Expertgroep van 19 september 2012 is besloten het aan deze post gerelateerde erratum (ERR200) niet door te voeren. Daarmee is deze post eveneens gesloten. Deze post heeft dus geeen gevolgen voor de StUF standaard.
Het aan deze post gerelateerde erratum is alsnog, op een andere wijze, opgelost binnen patch 15.
Post gesloten.