Op 1 juli 2018 is de vernieuwde wetgeving voor de BAG ingegaan. Onder meer is een nieuwe versie van de BAG-catalogus (waarin IMBAG 2.0 is opgenomen) en van het koppelvlak met de landelijke voorziening BAG (StUF-LVBAG) uitgebracht. Zie voor meer informatie de websites van BZK en Kadaster. Een en ander heeft consequenties voor bg0310 en daarop gebaseerde koppelvlakken. De wijzigingen als gevolg van BAG 2018 worden in bg0310 verwerkt door het ‘terugvertalen’ naar BAG 2009 en extraElementen. De consequenties zijn geanalyseerd en beschreven in het bijgevoegde document ‘Consequenties BAG 2018 voor StUF-koppelvlakken VNG Realisatie’ (zie bijlage.zip). Deze zijn voor bg0310 uitgewerkt naar specificaties van extraElementen en transformatieregels, zie bijlage.zip ('keuzenVerStUFfing RSGB met revisie.pdf', 'keuzenVerStUFfing RSGB zonder revisie.pdf' en 'extra-elementen.xls').
Wij, VNG Realisatie, zijn voornemens deze wijzigingen uit te brengen in een patch op bg0310. Mochten hierover vragen of opmerkingen zijn dan zien we die graag hieronder, binnen 1,5 maand. Mocht dat tot discussie leiden over de aanpassingen dan zullen we de StUF-expertgroep vragen om een oordeel en besluitvorming.
Los van de aanpassingen in het kader van de nieuwe versie van de BAG, zie ik in het vernieuwde verStUFfingsdocument ook nog een wijziging die in april al is voorgesteld (https://vng-realisatie.github.io/StUF-Standaarden/comment/5825#comment-5825). De discussie rond deze wijziging is mijns inziens niet afgerond en de voorgestelde patch is er toen niet gekomen. Ik zou willen voorstellen om deze wijziging uit het huidige voorstel te verwijderen, zodat deze los van de wijzigingen in het kader van BAG 2018 kan worden beoordeeld.
In het document met de analyse van consequenties is in tabel 2 een foutje geslopen. Abusievelijk worden enkele extraElementen daar nog aangeduid met bag2_... terwijl dat bag18_... moet zijn. Bijgaand het gecorrigeerde document.
Bijlage
Gezien eerdere gesprekken die hierover (ook buiten dit forum) zijn gevoerd, gaat Centric akkoord met de oplossingsrichting voor de aansluiting op de nieuwe BAG. Het punt van orde rond de andere wijziging (zie post #2 hierboven) blijft daarbij onverminderd staan.
In de notitie en de excel worksheet 'extra-elementen' worden voor de nieuwe extra elementen bag18_statusPand, bag18_statusVerblijfsobject en bag18_inOnderzoekAttributen geen (enumeratie)waarden of voorbeelden gegeven.
Worden voor de (enumeratie)waarden de waarden zoals genoemd in de 'Catalogus BAG 2018' tabel 8.5.b voor status pand, tabel 8.7.b voor status verblijfsobject en tabel 4.8.a voor de onderzoekbare attributen gebruikt ?
Henri,
In het verStUFfingsdocument is het de betekenis van ANN gewijzigd van 'ANDER
BUITENLANDS NIET -NATUURLIJK PERSOON' naar 'ANDER
NIET -NATUURLIJK PERSOON'. Die wijziging is echter niet consequent doorgevoerd. Op 2 plaatsen komt nog 'ANDER
BUITENLANDS NIET -NATUURLIJK PERSOON' voor.
Verder wordt op pagina 14 verwezen naar de relatie 'NUMMERAANDUIDING.is bezoekadres van.INGESCHREVEN NIET-NATUURLIJK PERSOON'. De relatie 'INGESCHREVEN NIET-NATUURLIJK PERSOON.heeft als bezoekadres.ADRESSEERBAAR OBJECT AANDUIDING' is gewijzigd in 'NIET-NATUURLIJK PERSOON.heeft als bezoekadres.ADRESSEERBAAR OBJECT AANDUIDING' zou 'NUMMERAANDUIDING.is bezoekadres van.INGESCHREVEN NIET-NATUURLIJK PERSOON' dan niet ook moeten worden gewijzigd in 'NUMMERAANDUIDING.is bezoekadres van.NIET-NATUURLIJK PERSOON'?
Downwards compatibility is technisch correct. Een ontvangend systeem hoeft de extra elementen niet te ondersteunen.
Dat geeft geen garantie dat de ontvanger al in staat is om deze nieuwe elementen te ontvangen van een leverancier. Dit vereist dan een strakke regie op de implementatie bij alle gemeenten. Wie gaat dat doen?
Mbt dit onderwerp zijn meerdere posts geplaatst voor diverse koppelvlakken. Is het niet handiger om voor alle posts één oplossing / goedkeuring te hebben? Of kunnen de koppelvlakken los van elkaar worden geimplementeerd?
In reactie op de vraag van Oscar Dekker dd. 13-8:
De eerste twee genoemde nieuwe extraElementen betreffen inderdaad BAG2018-conforme elementen d.w.z. met enumeraties conform BAG2018 zoals gespecificeerd in de Catalogus BAG 2018.
Het extraElement bag18_inOnderzoekAttributen staat abusievelijk in de opsomming. Deze had er uit verwijderd moeten zijn.
In reactie op de vragen van Ton Timmermans dd. 28-8:
Er is inderdaad geen garantie dat de ontvanger in staat is om de nieuwe elementen te verwerken (dan neemt hij alleen het 'oude' bericht af). Je stelt dat daarop regie nodig is. Wat is het probleem als de ontvanger die elementen (nog) niet verwerkt? Waarop zou die regie zich moeten richten?
Andere vraag, er zijn inderdaad meerdere posts geplaatst. De aanpassingen op al die koppelvlakken moeten wel in één keer vastgesteld worden. En een BAG-applicatie moet ze ook alle verwerken. Maar afnemers hebben daar vrijheid in. Technisch blijft het werken.
In de spreadsheet met extraElementen stond er nog één te veel: bag18_inOnderzoekAttributen. Die zouden we niet meer doen. Inmiddels is dit element verwijderd, zie bijlage.
Bijlage
@Sid, #post2: Ik zou graag het erratum voor "Ander (Buitenlands) Niet-Natuurlijk Persoon" ook willen meenemen in de aanstaande patch. Centric is de enige partij die dat erratum vooralsnog blokkeert. Kun je meehelpen om die blokkade op te heffen?
Antwoord op: In reactie op de vragen van Ton Timmermans dd. 28-8:
Er is inderdaad geen garantie dat de ontvanger in staat is om de nieuwe elementen te verwerken (dan neemt hij alleen het 'oude' bericht af). Je stelt dat daarop regie nodig is. Wat is het probleem als de ontvanger die elementen (nog) niet verwerkt? Waarop zou die regie zich moeten richten?
Als de zender al levert en de ontvanger kan de nieuwe elementen nog niet verwerken, zal later een aanvullende levering nodig zijn om de ontbrekende gegevens alsnog te verkrijgen. Dat wil je voorkomen, misschien is de zender zelfs niet in staat om iets dergelijks te faciliteren. Daarom kan een regie op de implementatie wel zo handig zijn.
Als 'regie op de implementatie' zou betekenen dat een gemeente de upgrade van haar BAG-applicatie niet zou mogen doorvoeren zolang alle binnengemeentelijk afnemende applicaties nog niet aangepast zijn op het verwerken van de extraElementen, dan zou dit wel eens tot forse vertraging van de implementatie van BAG2018 kunnen leiden. Die vorm van regie lijkt ons derhalve niet zinvol.
Verder is het ons inziens niet nodig om met "een aanvullende levering [...] de ontbrekende gegevens alsnog te verkrijgen". Die aanvullende levering zou dan de nieuwe extraElementen betreffen. Elk dergelijk element is evenwel of geen basisgegeven (zoals bag18_versienummer) of is een alternatief voor een reeds bestaand basisgegeven (zoals bag18_statusPand). De ontvangende applicatie kon voorheen zonder dergelijke elementen resp. beschikt al over het element maar dan met BAG2009-waarden. Vanaf het moment van verwerken van de nieuwe extraElementen worden deze bij mutaties overgenomen. Overal waar geen mutatie plaats vindt is sprake van de voorheen en ook nu nog geldige waarde.
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ERR0515.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Naar aanleiding van deze post een aanpassing op het verstuffingsdocument (zie bijlage). De verschillen zijn met geel gearceerd.
Bijlage