De gemeente Deventer in de persoon van Geert Wester heeft EGEM een probleem gemeld in de koppeling tussen Civision Basisregistratie van PinkRoccade en BAGTotaal van Vicrea.
Het probleem is dat BAGTotaal van Vicrea de elementen ADR.locatieadresnummer en VBO.verblijfsobjectnummer vult met waarden afgeleid van de BAG-identificatie. Deze elementen worden ook gebruikt door applicaties van PinkRoccade, waardoor er twee of meer applicaties hetzelfde gegeven onderhouden. Dit kan in de praktijk tot problemen leiden als het onbedoeld vervangen van aanwezige waarden door nieuwe waarden.
Bij het toevoegen van een nieuwe applicatie in het applicatielandschap doet een gemeente er goed aan om na te gaan of dit soort problemen kan optreden, te beslissen welke applicatie de eigenaar dient te zijn van dergelijke gegevens en ervoor te laten zorgen dat brokers zo worden ingesteld dat ze het door de gemeente gewenste gedrag vertonen.
Applicatieleveranciers doen er bij het installeren van een nieuwe applicatie goed aan om met elkaar en de gemeente na te gaan of bovengenoemde problemen kunnen optreden en zonodig in overleg met de gemeente als opdrachtgever te zoeken naar oplossingen.
Het leveren van genoemde identificaties met BAG-waarden door de BAG-applicatie gaat alleen dan goed als vooraf alle andere applicaties/registraties waarin deze identificaties worden gebruikt, aangepast zijn op de nieuwe (BAG)waarden van de identificaties. Een forse conversieslag dus. Haalbaarheid twijfelachtig.
Een andere oplossing zou kunnen zijn het opnemen van de BAG-identificaties als extra-elements. Daarbij worden genoemde identificaties niet verstoord. In de StUF-expertgroep is dit onderhanden onder de noemer 'mapping'.
Ik heb hierover destijds ook met Geert Wester gesproken. Ik heb hem uitgelegd wat er gebeurt indien twee bronnen feitelijk een afwijkende definitie (en daarmee waarde) hanteren voor hetzelfde element.
In dit geval worden de genoemde elementen die sinds jaar en dag een unieke (maar niet authentieke) waarde hebben, vanuit een andere bron ineens aangeleverd met als waarde de authentieke identificatie.
Voor de authentieke identificatie van verblijfsobjecten en nummeraanduidingen zijn binnen StUF BG 03.10 echter nieuwe elementen gedefinieerd, die binnen StUF BG 02.04 niet als standaard element zijn opgenomen (overigens wel als extraElementen binnen de PR applicaties). Het uitwisselen van (alle) authentieke BAG gegevens met behulp van StUF BG 02.04 (zonder extra elementen) is daarom ook niet mogelijk.
De kritiek van Geert richtte vervolgens met name op het feit dat dit blijkbaar tussen beide leveranciers niet eerder onderling is afgestemd. Hoewel we over dit punt reeds diverse malen binnen de StUF community gesproken hebben, is dit toch nog steeds een prangend issue. Ik stel voor dat we dit binnenkort nog eens op de agenda plaatsen.
Locatieadresnummer en Verblijfobjectnummers zijn unieke nummers die door de gemeente worden toegekend. De gemeente moet zelf afdwingen dat alle partijen dezelfde unieke nummers gebruiken. Deze problematiek staat mijns inziens buiten StUF en zelfs ook buiten het gegevensmodel GFO-BG.
Beste Henri,
Het punt dat ik graag in de community zou willen bespreken is hoe wij met StUF BG 02.04 de actuele ontwikkelingen rondom het stelsel van basisregistraties kunnen volgen. Het betreft dan met name de koppeling tussen BAG en GBA en WOZ en het verplichte binnengemeentelijke gebruik van GBA (inclusief BAG) gegevens. Dit punt kunnen we als StUF community niet negeren.
Groet, John.