Wij (PinkRoccade) zitten met een issue betreffende het uniek zijn van BAG-id’s in relatie tot het Sectormodel WOZ.
Uitgangspunt:
Wij gaan er vanuit, dat het BAG-id van een adres (ADR) uniek is. Dat wil zeggen, dat indien wij met behulp van een BAG-id een (StUF bg0204) adresvraag stellen aan een Gegevensmagazijn, we maximaal één adres retour krijgen.
Sectormodel WOZ:
In het Sectormodel WOZ kan voor de aanduiding van het WOZ-object verwezen worden naar een BAG-adres. Aanvullend op deze verwijzing kan middels locatie-omschrijving de ligging van het WOZ-object t.o.v. het BAG-adres gespecificeerd worden.
RSGB (bg0310):
In het RSGB is deze modellering van de aanduiding van het WOZ-object overgenomen. Daarnaast kent het RSGB voor OGO’s een vergelijkbare aanduiding middels verwijzing naar BAG-adres, eventueel gespecificeerd met een locatie-omschrijving.
GFO Basisgegevens (bg0204):
In de mapping van bg0310 naar bg0204 en vv is geen mapping voor WOZ opgenomen, maar wel voor TGO (OGO’s). De WOZ-mapping is voor berichtenverkeer niet interessant, omdat geen enkele leverancier WOZ in bg0204 geïmplementeerd heeft. Voor de interne werking van de systemen is deze WOZ-mapping wel relevant, omdat intern wel mapping plaatsvindt tussen WOZ-systemen en bg0204-systemen. Voor deze interne WOZ-mapping volgen we daarom de analogie van de OGO-mapping.
Situatie:
We hebben twee OGO/WOZ-objecten. Object 1 verwijst naar BAG-adres 23 (Appelweg 2). Object 2 verwijst ook naar BAG-adres 23, maar de ligging is gespecificeerd met locatie-omschrijving “achter het woonhuis”.
Beide objecten uit ons Sectormodel WOZ systeem (bg0310) voegen we toe aan ons Gegevensmagazijn (bg0204)
Via de mapping bg0310->bg0204 ontstaan de volgende gegevens in ons Gegevensmagazijn:
- ADR1 met BAG-adres 23 (Appelweg 2), VBO1 met verwijzing naar ADR1
- ADR2 met BAG-adres 23 (Appelweg 2, locatie-omschrijving “achter het woonhuis”), VBO2 met verwijzing naar ADR2
Het issue:
Door de mapping van de locatie-omschrijving van OGO/WOZ naar ADR ontstaan er in het Gegevensmagazijn 2 adressen met hetzelfde BAG-id, nl. BAG-id 23. Stel ik mijn adresvraag met BAG-id 23 aan het gegevensmagazijn, dan krijg ik niet één, maar twee adressen retour. Dit botst met ons uitgangspunt, dat het BAG-id van een adres uniek is.
Onze vragen aan KING en overige belanghebbenden:
Is ons uitgangspunt (uniek BAG-id) terecht?
Is de uitgevoerde mapping correct?
Is dit issue voor jullienieuw?
Hoe kijken jullie tegen dit issue aan?
Met vriendelijke groet,
Marcel Brons en John Rooijakkers
Jullie uitgangspunt dat een BAG-id uniek is komt mij logisch voor (maar geen garantie, want deze vraag moet je feitelijk stellen aan de BAG).
De uitgevoerde mapping lijkt mij correct.
Het issue is nieuw voor mij. Het is logisch dat je twee adressen in het gegevensmagazijn krijgt met hetzelfde BAG-id. Het probleem lijkt me te zitten in de wijze van het stellen van de vraag. Als je een echt BAG-adres wilt terughebben, dan zal je in de vraag moeten opnemen locatieOmschrijving = GEENWAARDE, dan krijg je precies één adres terug. Als je dit weglaat, dan krijg je het BAG-adres plus de van dat BAG-adres afgeleide adressen.
Maarten
Bij het tweede adres in het voorbeeld (“ADR2 met BAG-adres 23 (Appelweg 2, locatie-omschrijving “achter het woonhuis”)”) is sprake van een ADR-entiteit die in het RSGB en in StUF-BG 03.10 niet bestaat. De locatieomschrijving kan dan ook alleen maar zijn ontstaan uit een TGO-bericht. Een attribuut van het TGO (de locatieomschrijving) wordt toegevoegd aan de gegevens van een AOA om er een StUF2 ADR-entiteit van te maken.
Het ontstane ADR heeft dus geen rechtstreekse tegenhanger binnen het RSGB en kan daarbinnen dus eigenlijk ook geen unieke ID hebben. De meest in de buurt komende identificatie is die van het TGO waaruit het ADR is ontstaan. Dit TGO bevat immers (samen met de gerelateerde AOA) alle gegevens die uiteindelijk in het ADR zijn terechtgekomen.
Mijn insteek is dus dat de aanname onjuist is: er bestaat binnen het RSGB geen unieke identificatie voor het ADR uit StUF2.
Je ziet dit ook in de mapping (Stuf2 -> Stuf3) waarin staat dat een ADR met locatieomschrijving niet vertaald kan worden naar een AOA. Je kunt dus een ADR in het algemeen niet uniek identificeren met een identificatie uit het RSGB (en daarmee StUF-BG 3.10) omdat daarbinnen geen entiteittype bestaat voor dat gegeven. Het is verdeeld over twee entiteittypes die elk zelf ook al een tegenhanger hebben in het nieuwe model (RSGB/Stuf3): TGO en AOA.
Hetzelfde zul je terug gaan zien bij natuurlijke personen met een buitenlands adres. Ook voor deze adressen is geen entiteittype beschikbaar in RSGB/StUF3. Het gaat hierbij om attributen van een persoon die in StUF2 nog waren ondergebracht in een eigen entiteit (ADR).
Zelf zijn we binnen Centric tegen een vergelijkbaar issue aangelopen. Omdat wij binnen onze systemen graag adresseerbare objecten en subjecten altijd willen voorzien van een aanwijsbaar adres-object, moeten wij voor de buitenlandse en postadressen en voor de locatieadressen (met een locatieaanduiding) aparte adresobjecten maken. Zolang wij werken met interne object-id’s is dit nog prima mogelijk, maar op het moment dat we dit willen vertalen naar sleutels uit het RSGB, lopen we tegen problemen aan met de identificatie van die objecten (geen unieke sleutel beschikbaar).
Met vriendelijke groet,
Sid
In aanvulling op de voorgaande reacties.
Is ons uitgangspunt (uniek BAG-id) terecht?
> In de BAG en het RSGB is er inderdaad sprake van een unieke ID van ´adres´. Zoals hiervoor al vermeld is er in StUF 2.04 op basis van de'RSGB-adres-id' geen sprake meer van een unieke id omdat er adressen toegevoegd worden tov. het RSGB: adressen met een lokatie-omschrijving.
Is de uitgevoerde mapping correct?
> Lijkt me wel. Maar wil je in StUF 2.04 een unieke ID van adres dan moet je de combinatie van BAG-id met locatieomschrijving nemen. Andere optie is om bij zoeken op BAG-id alleen het adres terug te geven met een niet-gevulde locatie-omschrijving. Andere adressen, die met een locatie-omschjrijving, hebben geen BAG-id. Dergelijke adressen bestaan in het RSGB niet, de locatie-omschrijving maakt deel uit van het OGO. Je kunt ze dus ook niet zoeken op ID.
Is dit issue voor jullienieuw?
>Jazeker.
Hoe kijken jullie tegen dit issue aan?
>Zie hiervoor. Wellicht moet de oplossing meer gezocht worden in de zoekalgoritmes (wat krijg je als je ergens op zoekt).