Bij de stukken voor de StUF expertgroep (EG) op 20 oktober 2010 trof ik het document Koppelvlak specificatie BAG-WOZ aan waarin de samengestelde kennisgevingen zijn opgenomen in de nieuwe namespace bgbag in plaats van de eerder beschreven namespace bg.
Dit verbaast me om twee redenen. Ten eerste waren op één na alle deelnemers van de EG op 15 september voorstander van het gebruik van de namespace bg en ten tweede is afgesproken dat binnen KING besproken zou worden onder welke voorwaarden de bg namespace gebruikt mag worden. Het lijkt me dus niet correct dat nu blijkbaar zonder verdere afstemming en communicatie besloten is dat het koppelvlak BAG-WOZ niet geïmplementeerd wordt binnen de namespace bg.
In deze discussie wil ik verder inhoudelijk ingaan op een tweetal zaken:
- Het doel en de implementatie van de koppelvlakken BAG-WOZ en BAG-GBA.
- Het gebruik van samengestelde kennisgevingen binnen sectormodel bg0310.
Het doel en de implementatie van de koppelvlakken BAG-WOZ en BAG-GBA
De koppelvlakken BAG-WOZ en BAG-GBA hebben als doel om op basis van het standaard uitwisselformaat van basisgegevens (StUF BG), op een zodanige wijze informatie uit te kunnen wisselen dat gebeurtenissen bij de bronhouder BAG op de juiste wijze worden verwerkt door de afnemers WOZ en GBA. Omdat de StUF standaard en het sectormodel BG hiervoor onvoldoende semantiek en gegevens bevatten, beschrijft het koppelvlak aanvullende regels en gegevens (in de vorm van extraElements) waardoor de beschreven doelstelling gerealiseerd kan worden.
Op basis van bovenstaande kom ik tot de volgende conclusie: De koppelvlakken BAG-WOZ en BAG-GBA zijn geen aparte sectormodellen maar specificaties die aanvullend zijn op de StUF standaard en het sectormodel BG. Deze specificaties beschrijven in welke situatie (bij welke gebeurtenis) bepaalde StUF BG berichten verstuurd moeten worden, welke gegevens (inclusief extraElements) hierin minimaal opgenomen moeten worden en hoe deze door de afnemers verwerkt moeten worden. Berichten die voldoen aan de koppelvlak specificaties zijn dus reguliere StUF BG berichten. Andersom hoeft niet ieder StUF BG bericht aan de koppelvlak specificaties te voldoen.
Het is daarnaast in het belang van gemeenten en leveranciers om voor de binnengemeentelijke uitwisseling van basisgegevens altijd hetzelfde sectormodel (StUF BG) te gebruiken. Indien ieder koppelvlak geïmplementeerd wordt met behulp van een ander sectormodel, dan betekent dit dat iedere binnengemeentelijke bron en afnemer ook alle relevante sectormodellen moeten ondersteunen (nog los van de consequenties voor orkestratie en synchronisatie applicaties). Daarnaast moet een bron (bv BAG) een gebeurtenis per koppelvlak in een apart bericht per sectormodel verstrekken, terwijl er slechts één bericht vereist is indien de koppelvlakken geïmplementeerd worden met behulp van het sectormodel BG.
Tenslotte is het onlogisch indien het koppelvalk BAG-WOZ wordt geïmplementeerd binnen het sectormodel bgbag (obv StUF 03.01) terwijl het koppelvalk BAG-GBA is geïmplementeerd binnen het sectormodel bg (obv StUF 02.04). Dit betekent dat een BAG applicatie niet alleen geconfronteerd wordt met verschillende versies van de StUF standaard, maar ook nog eens met verschillende sectormodellen die behoren bij deze StUF versies.
Het gebruik van samengestelde kennisgevingen binnen sectormodel bg0310
In mijn voorgaande beschrijving van het doel en de implementatie van koppelvlakken ben ik bewust voorbij gegaan aan de vastgestelde behoefte om binnen het koppelvlak BAG-WOZ gebruik te kunnen maken van samengestelde kennisgevingen om op die wijze complexere transacties te kunnen implementeren. Ik ben namelijk van mening dat we deze samengestelde kennisgevingberichten simpelweg moeten opnemen in de eerstvolgende patch van het sectormodel bg0310. Onderstaand zal ik deze mening verder toelichten.
Binnen versie 03.01 van de StUF standaard zijn de samengestelde kennisgevingberichten (Lk03 en Lk04) reeds gedefinieerd met exact de doelstelling zoals die momenteel wordt gewenst binnen het BAG-WOZ koppelvlak. Bij het initiële ontwerp van het sectormodel BG versie 03.10, zijn deze samengestelde kennisgevingen hierin echter helaas niet opgenomen. Voor zover ik nu nog kan achterhalen is dit destijds gebeurd omdat er geen directe aanleiding bestond of bedacht kon worden om de samengestelde kennisgevingen wel in bg0310 op te nemen en de uitbreiding van bg0310 ten opzichte van bg0204 al behoorlijk groot was. Dit overigens in tegenstelling tot de kennisgevingen met toekomstmutaties (Lk05 en Lk05) waarvoor er concrete functionele aanleidingen waren om deze niet op te nemen in bg0310. Op basis hiervan en met de huidige inzichten is het verdedigbaar om het ontbreken van samengestelde kennisgevingen binnen bg0310 als een onbedoelde en ongewenste tekortkoming te beschouwen en ze in de volgende patch alsnog op te nemen.
In de vertaling van StUF 2 berichten naar StUF 3 berichten en vice versa is reeds opgenomen hoe met samengestelde kennisgevingen omgegaan moet worden (zie StUF 3.01 patch 5):
De samengestelde kennisgevingberichten en de synchronisatieberichten komen niet voor StUF0204. Toch kunnen ze wel gemapt worden naar een groep kennisgevingberichten in StUF0204. Een Lk03-kennisgeving wordt gemapt door de afzonderlijke kennisgevingen binnen de Lk03-kennisgeving te mappen naar StUF0204 Lk01-berichten en als losse berichten aan te bieden. In deze mapping gaat verloren dat de kennisgevingen binnen de samengestelde kennisgeving als een transactie verwerkt moeten worden.
Daarnaast stelt StUF dat niet dat iedere applicatie verplicht is om alle berichten te ondersteunen die binnen een sectormodel gedefinieerd zijn. Binnen de wsdl wordt voor een applicatie beschreven welke berichten daadwerkelijk worden ondersteund. In de praktijk blijkt ook dat nagenoeg geen enkele applicatie in de praktijk ieder bericht ondersteunt. De continuïteit van de berichtverwerking tussen applicaties komt dus ook niet in gevaar omdat in de bestaande (in de wsdls vastgelegde) berichten geen wijzigingen worden doorgevoerd. Applicaties die sectormodel bg0310 wel, maar het gewenste transactiemechanisme niet kunnen ondersteunen, kunnen deze berichten op dezelfde wijze verwerken als dat een applicatie zou doen die sectormodel bg0204 ondersteunt.
Zoals eerder reeds aangegeven, is het in het belang van gemeenten en leveranciers om voor de binnengemeentelijke uitwisseling van basisgegevens altijd hetzelfde sectormodel (StUF BG) te gebruiken. Het is niet wenselijk om als gevolg van een bepaalde gebeurtenis aan de ene afnemer (WOZ) een samengestelde kennisgeving binnen het sectormodel bgbag te verstrekken en aan de andere afnemers enkelvoudige kennisgevingen in de vorm van het sectormodel bg.
Besluitvorming
Ik zie graag de mening van alle betrokkenen en belanghebbenden aangaande dit onderwerp. Los daarvan heb ik inmiddels naar KING de verwachting uitgesproken dat deze post als input wordt meegenomen bij de behandeling van agendapunt 3 (Goedkeuring StUF-compliancy BAG-WOZ-koppelvlak) tijdens de komende expertgroep op 20 oktober.
John,
Met jouw weergave van de relatie tussen StUF bg en de koppelvlakken en met jouw weergave van de wijze waarop de discussie over het koppelvlak BAG-WOZ is verlopen kan ik volledig instemmen.
Wij hebben dan ook in eerste instantie het koppelvlak BAG-WOZ in de namespace bg gedefinieerd. Wij kunnen ons daarbij overigens prima voorstellen dat mede uit beheersbaarheidsoverwegingen, de koppelvlakken juist niet volledig in de schema's van StUF bg worden opgenomen. Denk bijvoorbeeld aan het koppelvlak voor de Landelijke Voorziening BAG. Dat zal volgend jaar ook volledig binnen StUF bg 03.10 worden gedefinieerd. Toch kan ik mij voorstellen dat deze definitie afzonderlijk gepresenteerd wordt in afzonderlijke schema's.
Wel hadden (en hebben) wij er een voorkeur voor om bij al deze eventuele aanvullende schema's voor koppelvlakken steeds de namespace bg te gebruiken. Daarom hadden we ook op die basis het koppelvlak BAG-WOZ gedefinieerd.
Vanuit KING is daarbij duidelijk aangegeven dat het dan zeer moeilijk zou zijn om het predicaat "StUF-conform" te krijgen. Het definiëren binnen de namespace bg zou volgens KING de consequentie hebben dat we het koppelvlak als RFC op StUF bg zouden moeten indienen. Deze weg zou betekenen dat we moeten wachten op een volgend releasemoment tot er sprake zou kunnen zijn van een vastgesteld koppelvlak. Het eerstvolgende releasemoment ligt na de datum dat verplicht gebruik van BAG-gegevens moet plaatsvinden, dus dat achtten wij geen reële optie.
Wij blijven van mening dat er afzonderlijke koppelvlakspecificaties mogelijk moeten zijn binnen de namespace van bg (of bijvoorbeeld ook in de namespace zkn of de namespace woz). Juist op deze manier kan gebruik van StUF worden gestimuleerd en kan met de nodige flexibliteit worden ingespeeld op nieuwe koppelvlakken. Wij hebben begrepen dat de komende periode een meer principiële discussie plaats zal vinden over de positie van koppelvlakken ten opzichte van de standaard en ten opzichte van het beheermodel.
Wij achtten het ook geen juiste weg om te wachten tot deze discussie is afgerond. Ook dan zou het vaststellen van het koppelvlak naar verwachting pas kunnen plaatsvinden, nadat verplicht gebruik al van kracht is.
Daarom hebben wij gekozen voor de weg die het snelst tot vaststelling van het koppelvlak zou kunnen leiden. Henri Korver heeft daarbij voorgesteld om de namespace WOZ of BAGWOZ te gebruiken. Dat vonden wij niet wenselijk, omdat het nu gedefinieerde koppelvlak BAG-WOZ naar verwachting ook voor veel andere BAG-koppelvlakken gebruikt kan worden. Vandaar het "compromis" bgbag.
Samengevat: wij zijn en blijven voorstander van het gebruik van de namespace bg, maar als dat tot (verdere) vertraging leidt in het toekennen van het predicaat "StUF-conform" voor het koppelvlak BAG-WOZ, dan kiezen wij nadrukkelijk voor deze aparte namespace bgbag.
Op dit moment heeft de discussie over het vaststellen van het koppelvlak BAG-WOZ al meer tijd gekost dan er nog beschikbaar is voor het realiseren en implementeren van dit koppelvlak bij gemeenten. Deze trage procedure is, merken wij, zeer schadelijk voor het draagvlak voor de StUF standaard.
Ik hoop dan ook zeer dat in de expertgroep van 20 oktober nu eindelijk groen licht wordt gegeven. Welke namespace dan wordt toegekend, achten wij van secundair belang.
Ruud,
Mijn woorden worden hier niet goed geciteerd. Ik heb nooit voorgesteld om woz of bagwoz als namespace voor het BAG-deel van het BAG-WOZ koppelvlak te gebruiken. Ik heb wel bag als namespace voorgesteld en dat vind ik nog steeds de mooiste naam, echter als compromis zijn we gekomen tot bgbag.
Als de vaststelling van het BAG-WOZ koppelvlak haast heeft dan is het inderdaad handig om het koppelvlak in een eigen namespace te definieeren en niet in de namespace van bg0310. Misschien is dat laatste uiteindelijk wel mooier maar we kunnen dat nog niet op korte termijn regelen omdat zo'n operatie zowel een RFC op het sectormodel bg0310 vereist als ook op het beheermodel. Immers het begrip sectormodel zal dan moeten worden geherdefinieerd.
Mvg,
Henri
Beste Ruud,
Allereerst dank voor de snelle reactie op deze discussie.
Ik begrijp het standpunt van de Waarderingskamer dat zij niet veel langer kunnen wachten op de vaststelling van het koppelvlak BAG-WOZ. Ik heb daarentegen toch gemeend een ultieme poging te moeten doen om een (mijn inziens voor het oprapen) win-win situatie te bereiken.
Ik zie op dit moment nog steeds geen enkele reden om woensdag aanstaande niet een erratum te accepteren waarin de samengestelde kennisgevingen worden opgenomen in het sectormodel bg0310. Ik begrijp ook niet waarom hiervoor een aanpassing van het beheermodel of een andere definitie van sectormodellen vereist is. In mijn post heb ik geprobeerd dit zo helder mogelijk te beargumenteren. Mochten delen hiervan toch niet helder zijn, dan ben ik graag bereid om dit (ook buiten het forum om) nader toe te lichten.
Ik hoop tenslotte dat iedereen net als jij met een open blik naar het voorstel wil kijken. Indien iemand hiertegen bezwaren heeft, plaats deze dan svp beargumenteerd op het StUF forum.
Groeten en prettig weekeinde,
John Rooijakkers
Beste Henri,
Zou je svp in een reactie willen aangeven waarom:
Verder wil ik je vragen of je jezelf kunt vinden in mijn definitie van een koppelvlak en de relatie daarvan met een sectormodel. Indien dit niet het geval is, waarom niet en hoe definieer jij een koppelvlak en de relatie hiervan met een sectormodel.
Indien er ook nog andere zaken in mijn post staan die in jouw ogen onjuist of onvoldoelde duidelijk zijn, wil je die dan svp ook voorafgaande aan de expertgroep vergadering posten?
Alvast bedankt en groeten,
John Rooijakkers
Beste John,
Bedankt voor je proactiviteit. Dit biedt ons een uitstekende voorbereiding op de bijeenkomst van woensdag. Hieronder alvast een aantal antwoorden op je vragen.
Ad 1) Begrijp me niet verkeerd. Vanuit technisch en praktisch oogpunt ben ik het misschien wel met je eens dat het beter is om koppelvlakken zoals BAG-WOZ te definiëren in de namespace http://www.egem.nl/StUF/sector/bg/0310. Echter als je dat wilt doen moet eerst worden gecheckt of het koppelvlak niet in tegenspraak is met sectormodel bg0310. Dat is nu wel het geval omdat bg0310 geen samengestelde kennisgevingberichten toestaat hoewel BAG-WOZ daar juist rijkelijk gebruik van maakt. Vandaar dat KING op de rem heeft getrapt. Iedereen moet erop kunnen vertrouwen dat eerder gemaakte afspraken worden nageleefd en alleen kunnen worden veranderd door middel van een bugfix-verzoek of een RFC. Als een partij zoals de Waarderingskamer veel haast heeft biedt KING de mogelijkheid om deze procedure te omzeilen door een eigen namespace (bgbag) te hanteren en zo toch StUF-conform te zijn.
Ad 2) Als de expertgroep unaniem van mening is dat de samengestelde kennisgeving een erratum is op bg0310 dan zou dit wat mij betreft een prima opening kunnen bieden in deze discussie. Ik heb er in ieder geval geen bezwaar tegen.
Ad 3) Het begrip sectormodel is zowel in de StUF-standaard als in het beheermodel van StUF niet scherp gedefinieerd. Het begrip koppelvlak(specificatie) is überhaupt nog niet gedefinieerd. Het invoeren van nieuwe en betere definities zal mijns inziens leiden tot RFCs op het beheermodel. Wellicht komen we er met een erratum van af maar dat kan ik nu nog niet overzien.
Ad 4) Zie ad 3)
Mvg,
Henri
John (en andere),
Centric is het helmaal eens met jouw betoog. Ook wij zijn voorstander om voor de verschillende koppelvlakspecificaties zoals BAG-WOZ gebruik te maken van het sectormodel StUF-bg 03.10. Zoals Ruud aangeeft was dat ook de bedoeling voor het BAG WOZ koppelvlak. Er is toen een voorstel gekomen om een aantal extra elements op te nemen. Dit is door de expertgroep afgewezen. Alternatief is het ondersteunen van samengestelde kennisgevingen in het sectormodel StUF-bg 03.10. Centric is van mening dat de samengestelde kennisgevingen moeten worden opgenomen in het sectormodel StUF-bg.
John schets ook nog dat afnemers niet gelijk samengestelde kennisgevingen hoeven te ondersteunen. Deze worden op maat bediend met normale kennisgeveingen. Dat klopt wel maar dan zal de afnemer "distributiesysteem" toch de mapping van Lk03 naar Lk01 moeten ondersteunen.
Ruud geeft aan dat het moment dat de WOZ de gegevens uit de BAG verplicht moeten gaan gebruiken steeds dichter bij komt. Er is geen tijd meer voor discussie maar er moet nu iets gebeuren.
Wij zijn het daar niet mee eens. Met het huidig sectormodel StUF-bg 03.10 kan je ook aan de verplichting voldoen om adresgegevens uit de BAG te halen. Je zit dan wel met wat extra handwerk bij de complexe gebeurtenissen zoals splitsingen en samenvoegingen. Maar daar heeft de GBA nu ook last van.
Op dit moment maakt nog geen enkele, of heel weinig, gemeente gebruik van de StUF-bg 03.10 koppeling. We zijn al ongeveer 4 jaar bezig om onze klanten te migreren van StUF-bg 01.02 naar StUf-bg 03.10. Op welke manier we ook omgaan met het BAG-WOZ koppelvlak. Dat het snel geimplementeerd is bij veel gemeenten is een illusie.
Ben benieuw naar de discussie in de expertgroep en ben benieuwd waar we op uitkomen.