Het huidige koppelvlak tussen de BAG en de GBA is gebaseerd StUF BG 02.04. Hierin wordt gebruik gemaakt van berichten over Nummeraanduidingen (ADR) en optioneel over Openbare ruimten (R02) en Woonplaatsen (R03). Omdat de GBA inschrijvingen op nevenadressen ondersteunt, zijn zowel de identificatie van het verblijfsobject als de identificatie van de Nummeraanduiding in het koppelvlak opgenomen als elementen van de Nummeraanduiding. Wijzigingen in Verblijfsobjecten (VBO) worden door het huidige koppelvlak niet ondersteund.
Bij het ontwerp van StUF BG 03.10 is in het document “keuzenVerStUFfing RSGB” expliciet opgenomen dat: “ADRESSEERBAAR OBJECTAANDUIDING.is officieel adres van.OVERIG TERREIN worden geïmplementeerd als één relatie ADRESSEERBAAR OBJECTAANDUIDING.is van.BENOEMD OBJECT naar BENOEMDe OBJECT waar de ADRESSEERBARE OBJECTAANDUIDING bijhoort. Deze relatie wordt in bg0310 opgenomen in verband met de mapping van bg0310 naar bg0204 en het daar gewenste opnemen van de ADRESSEERBAAR OBJECT identificatie binnen ADR in bg0204”.
In de BAG berichten catalogus is dit laatstgenoemde uitgangspunt echter (en blijkbaar niet gedocumenteerd) losgelaten. In de restrictions op de AOA-kennisgeving is de relatie AOA.isVan.TGO weggelaten. Binnen de TGO-kennisgeving is het hoofdadres platgeslagen als groepselement adresAanduidingGrp en zijn de nevenadressen opgenomen als relatie heeftNevenadressen. Om de GBA te informeren over de relatie tussen een adresseerbaar object en de (hoofd en neven) nummeraanduidingen, zijn dus berichten over adresseerbare objecten vereist.
Omdat het BAG-GBA koppelvlak binnen StUF 3.01 wordt gebaseerd op de BAG berichtencatalogus, zal het naast berichten over nummeraanduidingen, openbare ruimten en woonplaatsen, ook berichten over adresseerbare objecten (TGO) moeten bevatten.
Dit roept de volgende vraag op of binnen de BAG berichtencatalogus bewust is afgeweken van de genoemde ontwerpbeslissing in het document “keuzenVerStUFfing RSGB”? En indien dit het geval is, wat waren hiervoor dan de redenen? Daarnaast lijkt deze keuze de uitwisselbaarheid van berichten conform het BAG-GBA koppelvlak op basis van StUF BG 02.04 met berichten conform de BAG berichtencatalogus op basis van StUF BG 03.10 minimaal te compliceren en wellicht onmogelijk te maken. Ik ben benieuwd naar de mening van de overige community leden.
Ik ben bang dat deze keuze het gevolg is van het gebeurtenis georiënteerd zijn van de BAG-berichtencatalogus. In één transactie wordt eerst een aoa zonder relatie naar een adresseerbaar object opgevoerd en daarna aan het adresseerbaar object gekoppeld dat gelijktijdig wordt opgevoerd of dat al bestaat (nevenadressen). Zeker bij het opvoeren van een adresseerbaar object zit je met een kip-ei probleem en er is voor gekozen om eerst de AOA op te voeren en deze daarna te linken naar het adresseerbaar object.
De BAG-berichtencatalogus definieert uitsluitend gebeurtenis georiënteerde berichten en de bedoeling was dat systemen hieruit de gebeurtenissen oppikken die voor hen relevant zijn. Een eenduidige vertaling van BAG-berichtencatalogus naar het 0204 BAG-GBA koppelvlak is dus lastig.