In versie 1.0 van de bg0310-BAG worden ten opzichte van de oorspronkelijke BAG-gebeurtenissen uit het processenhandboek van VROM een aantal gebeurteniscodes toegevoegd. Hierbij uitbreekt mijn inziens nog een gebeurtenis namelijk het 'benoemen van een verblijfsobject.'
Enkele voorbeelden uit de praktijk: Een losstaande garage bij een woonhuis wil men gaan gebruiken voor commerciele doeleinden waarvoor een eigen adres noodzakelijk is. Er vinden geen aanpassingen plaats waarvoor een omgevingsvergunning noodzakelijk is. BAG-technisch wordt verzocht om het benoemen van een verblijfsobject binnen een bestaand pand dat voorheen dienstbaar was aan de woning. Een ander voorbeeld: bij het afsplitsen van een bedrijfspand dat dienstbaar is aan een bedrijf dat beschik over meerdere panden en waar het verblijfsobject is gevestigd in een ander pand. In het afgespiltste bedrijfspand wil de nieuwe eigenaar een bedrijf beginnen. Ook hier moet dan een verblijfsobject worden benoemd in een reeds bestaand pand.
Op zich ziet dit eruit als een gebeurtenis die inderdaad niet beschreven is in het processenhandboek en evenmin in de berichtencatalogus, maar weldegelijk relevant is in de werkelijkheid.
Voor mij is dit een teken dat het gebruik van een limitatieve lijst met gebeurtenissen het risico met zich mee draagt dat de lijst wellicht toch nooit compleet is.
Een ander voorbeeld waar ik laatst van hoorde was een nieuwbouwpand waarin op de benedenverdieping de winkels al in gebruik werden genomen (melding gebruiksgereed), maar waarin de woningen erboven nog niet gereed waren.
Dit levert twee gebeurtenissen die (net) niet overeenstemmen met de bestaande gebeurtenissen: melding gebruiksgereed van een pand zonder dat alle verblijfsobjecten daarin gebruiksgereed zijn en op een later moment melding gebruiksgereed van verblijfsobjecten waarvan het pand wel al gebruiksgereed is.
In het processenhandboek van de BAG is al te lezen:"Het processenhandboek beschrijft de veelvoorkomende gebeurtenissen in een gemeente, maar is niet uitputtend in het beschrijven van alle mogelijke gebeurtenissen.". Het zal niet eenvoudig worden om een lijst te maken die wél uitputtend is. Wat doen we met de situaties waarin de lijst niet voorziet?
Grotendeels is dit een discussie die gevoerd zou moeten worden op een meer functioneel/semantisch niveau, maar door de berichtencatalogus op de manier te beperken zoals nu is gedaan, komt het vraagstuk hier naar voren...
Ten eerste, het lijkt me onverstandig om tekortkomingen in de BAG op te lossen in het RSGB.
Ten tweede, de door Alex genoemde voorbeelden lijken me niet een aanleiding om een gebeurteniscode "Benoemen Verblijfsobject" in het leven te roepen. Nog in het RSGB, nog in de BAG. Want de BAG voorziet in deze scenarios met de gebeurtenissen:
Mijns inziens doet het er hierbij niet toe of er sprake is van:
@Han: ik vraag me af wat je in je eerste zin bedoelt met tekortkomingen in de BAG die opgelost zouden worden in het RSGB. Ik zie geen tekortkomingen in de BAG, alleen zie ik dat de berichtencatalogus BAG in het RSGB een beperking introduceert door een limitatieve reeks gebeurtenissen te introduceren.
Met betrekking tot de gebeurtenissen zoals beschreven door Alex, moet ik Han inderdaad gelijk geven dat verlenen bouwvergunning voldoende is om al deze gebeurtenissen door te geven. Strikt genomen is dan de naam wat dubieus, maar omdat er geen pand hoeft te ontstaan bij deze gebeurtenis, kan hij prima gebruikt worden om de voorbeelden af te handelen. Het was mij even ontgaan dat bij verlenen bouwvergunning geen pand hoeft te ontstaan.
Volgens mij blijft het feit dat er gebeurtenissen denkbaar zijn waarvoor geen StUF-gebeurtenissen zijn gedefinieerd. Mijn voorbeeld is er daar één van (denk ik nog steeds).
Mijn inziens ben je met het toevoegen van een Gebeurteniscode in een binnengemeentelijke StUF specificatie niet de tekortkomingen van de BAG aan het repareren. Zoals door Sid Brouwer al wordt aangehaald is het processenhandboek niet uitputtend. Dit is ook ooit de bedoeling geweest. Vanuit de wet BAG wordt geen enkel verplichting opgelegd om het processenhandboek te volgen. Voor zower ik weet zit er ook geen beheer op (ik heb hiervan nooit iets van vernomen).
De Gebeurteniscode is pas in een standaard opgenomen bij de het BAG-GBA koppelvlak, een binnengemeentelijk StUF standaard. Bij het ontwerp van deze uitwisselstandaard is er vanuit gegaan dat het wel handig is dat de ontvangende applicatie kan achterhalen wat de aanleiding is van van de mutatie. Deze kan namelijk worden gebruikt om specifieke processen op te starten.
Het bevreemd me dan ook dat Han stelt dat het niet van belang is of er sprake is van een formele aanvraag van een bouwvergunning etc. Als dit niet van belang is dan hadden we ook kunnen volstaan met de drie standaard gebeurtenissen toevoegen, bewerken en verwijderen (of welke benaming je er dan ook aan toe wilt kennen).
Verder vind ik dat het benoemen van een verblijfsobject zoals ik in eerste instantie heb geschetst niet onder de door Han genoemende gebeurtenissen valt. Er is dan namelijk geen spraken van een omgevingsvergunning, splitsing/samenvoeging of constatering. Verder bevreemd het me dat voor alle overige adresseerbare objecten wel een generieke gebeurtenis is opgenomen namelijk het benoemen van een ligplaats en staanplaats.
@Sid, wat ik bedoel met "tekortkomingen in de BAG op te lossen in het RSGB" is dat de BAG een limitatieve lijst met gebeurteniscodes kent, dat geconstateerd wordt dat er in de praktijk scenario's zijn die niet een op een overeenkomen met een gebeurtenis en dat vervolgens het voorstel wordt gedaan de lijst met gebeurteniscodes in bg0310-BAG uit te breiden.
Het doen van een limitatieve lijst met gebeurteniscodes is niet om scenario's in de werkelijkheid te beperken. Mijns inziens is het doel omgekeerd, namelijk de in de werkelijkheid mogelijke scenario's modelleren in een beperkt aantal gebeurtenissen.
De uitdagingen liggen dus op twee niveaus:
@Alex: en @Sid: Ik pleit ervoor eerst de tweede uitdagingen aan te gaan alvorens over te gaan tot het uitbreiden van een reeds limitatieve lijst.
@Han; je stelt dat de BAG een limitatieve lijst met gebeurteniscodes kent. Dat spreek ik tegen. Het koppelvlak BAG-GBA en de berichtencatalogus BAG kennen een limitatieve lijst. De BAG kent alleen een lijst met gebeurtenissen waarvan is aangegeven dat deze NIET limitatief is.
Het probleem zit hem dus weldegelijk in StUF.
Systeemtechnisch gezien is het inderdaad handig om de in de werkelijkheid mogelijke scenario's te modelleren in een beperkt aantal gebeurtenissen. Blijkbaar hebben we dat nu dus niet goed gedaan en ik betwijfel een beetje of we dat wel kunnen zonder beperkingen te leggen in de wekelijkheid (door bijvoorbeeld wet-/regelgeving). Zolang we niet zeker weten dat we alle mogelijke gebeurtenissen hebben gevangen in het model, lopen we dus het risico dat we de werkelijkheid niet meer kunnen vastleggen.
Het pragmatisch zoeken naar een gebeurteniscode waarbinnen een gebeurtenis kan worden gevangen (zo interpreteer ik jouw tweede uitdaging) doet m.i. afbreuk aan de betekenis die gekoppeld is aan de codes die er nu zijn. Daarmee weten we dus eigenlijk nog steeds niet wat er nu eigenlijk is gebeurd en dat is toch juist waarom we die codes hebben geintroduceerd?
Ik ben dus van mening dat we óf een limitatieve lijst maken waarvan we zeker zijn dat alle gebeurtenissen zijn afgedekt, óf dat er een mogelijkheid is om bijzondere gebeurtenissen als een soort 'buitencategorie' te behandelen. In dat geval wordt het ook aan de ontvangende kant duidelijk dat automatische verwerking niet vanzelfsprekend is.
Naar aanleiding van de discussie in de expertgroep StUF van afgelopen week voor het toevoegen van nieuwe BAG gebeurtenissen in StUF bg 3.10 heb ik contact gezocht met de beheerder van het processenhandboek. Zij zijn bezig met een nieuwe versie van het processenhandboek waarin vooralsnog de volgende gebeurtenissen zijn toegevoegd:
In het inleidende hoofdstuk zijn vooralsnog de volgende extra paragrafen opgenomen:
Eén en ander moet nog intern en extern gereviewed worden en kan dus nog wijzigen. We kunnen nu nog suggesties voor andere toevoegingen doen. Ik heb in ieder geval de volgende tien gebeurtenissen doorgegeven die al in StUF BG 3.10 zijn opgenomen:
In hoeverre deze overlap hebben met de nieuwe gebeurtenissen in het processenhandboek weet ik niet. Verder heb ik verwezen naar deze discussie waarin ook nog een aantal mogelijk nieuwe gebeurtenissen staan.