De unieke aanduiding van alle objecttypen in de BAG wordt in IMBAG aangepast, dus voor PAND, VERBLIJFSOBJECT, LIGPLAATS, NUMMERAANDUIDING etc etc. Dit heeft grote consequenties niet alleen voor BAG applicaties zelf maar ook voor alle andere applicaties die verwijzen naar een object uit de BAG. Geonovum en Kadaster die het nieuwe IMBAG opstellen vinden dit geen probleem. Graag wil ik van gemeenten en leveranciers weten hoe zij hier in zitten. Ook voor de basisregistraties zoals de BRWOZ en NHR e.d. zullen de nodige aanpassingen vereist zijn.
ma, 14-11-2016 - 08.39u
#1
Aanpassing unieke aanduiding van alle objecttypen in de BAG als gevolg van het nieuwe IMBAG
Op https://github.com/Geonovum/IMBAG/ is een conceptversie van het IMBAG te vinden. Daar kun je ook commentaar leveren op het model.
Het Gegevenswoordenboek BAG is wettelijk vastgesteld. Hoe kunnen Geonovum en Kadaster dit wijzigen?
Er is een programma ' Op weg naar BAG2.0' . De BAG wordt aangepast vanaf 2018. Maar behalve de wet en het besluit gaat het daarbij ook om de catalogus, waarin het informatiemodel en de objectafbakening worden opgenomen. Nu zijn de regels nog over veel documenten verspreid en daarbij zijn ze niet altijd even duidelijk. Een belangrijk doel is dat alle regels voortaan bij elkaar staan en dat de wettelijke definities nog meer als uitgangspunt worden genomen. Bij de objectafbakening is het de bedoeling enkele aanpassingen door te voeren. Ook in het informatiemodel worden enkele aanpassingen voorgesteld. Bij deze aanpassingen van de gegevenscatalogus BAG zijn Geonovum, Kadaster en I&M betrokken
Het IMBAG model is geen semantisch model. In een semantisch model ga je niet gegevenstypen die op elkaar lijken in een verzonnen objecttype plaatsen. Je modelleert wat je wilt communiceren over de werkelijkheid en dat doe je inrichtingsonafhankelijk. Normaliseren en optimaliseren doe je in een logisch of technisch model.
Het objecttype BAG-Object is geen objecttype. Dat blijkt al uit de definitie: de gemeenschappelijke eigenschappen van een BAG-object. Dat is geen (definitie van een) objecttype.
Een Woonplaats is geen specialisatie van een BAG-Object. Dan zou de definitie ongeveer moeten luiden: een Woonplaats is een BAG-object die...... Een Woonplaats is ook geen feature zijnde een punt, lijn of vlak. Wat een vreselijke degradatie zou dat zijn. De BAG-catalogus definieert de Woonplaats als Een WOONPLAATS is een door het bevoegde gemeentelijke orgaan als zodanig aangewezen en van een naam voorzien gedeelte van het grondgebied van de gemeente.
Iets dergelijks geldt voor een PAND. Een Pand is ook geen vlak. En een PAND is ook geen specialisatie van een BAG-object. Een PAND-identificatie en een Woonplaats identificatie zijn niet hetzelfde gegevenstype.
Een MAN is een specialisatie van een NATUURLIJK PERSOON, een VROUW is een specialisatie van een NATUURLIJK PERSOON, ik identificeer ze allebei met het BSN.
Het zal duidelijk zijn. Ik vind de voorgestelde modellering niet acceptabel, laat staan de aanpassing van de wijze van identificeren.
@Rindert: Helemaal mee eens met je reactie. Kan je je reactie ook op de GitHub plaatsen? Ik heb daar ook al allerlei opmerkingen geplaatsts o.a. over het BAG-object.
In het IMBAG zijn allerlei aanpassingen doorgevoerd waarvan je je kunt afvragen wat de toegevoegde waarde van die aanpassingen zijn zoals:
Inhoudelijke, functionele aanpassingen waaraan behoefte is, zijn niet opgepakt.
M.a.w. de gemeenten en leveranciers worden opgezadeld met een nieuw IMBAG dat 'technisch' is vernieuwd en voldoet aan NEN3610. Helaas is daarbij geen rekening gehouden dat deze 'technische' vernieuwing zo minimaal mogelijk effect zou moeten hebben op de bestaande situatie.
Graag ook vanuit gemeenten en leveranciers reacties op het IMBAG. Dat kan via https://github.com/Geonovum/IMBAG/
Volgens ons hoort deze discussie inderdaad meer bij BAG 2.0 thuis dan hier bij het RSGB. Het huidige RSGB is gebaseerd op de huidige BAG-specificatie uitmondend in het StUF 2.05 koppelvlak van de LV BAG.
Wanneer de BAG nieuwe specificaties heeft, zullen we die binnen RSGB op passende wijze moeten overnemen. Maar gezien de huidige planning zal dat niet eerder zijn dan 1-1-2018. Tegen die tijd moeten we dan denken aan een RSGB 3.1.
Overigens denken we dat het ook wel tijd wordt voor enige actualisering van de BAG-specificaties. Dus we moeten ook niet teveel gaan remmen met deze discussie.
De inhoudelijke voor en nadelen van de huidige plannen rond BAG 2.0 moeten we inderdaad bij BAG (op github) voeren.
Wij hebben overigens begrepen dat bij het IMBAG ontwerp verder gewerkt is op basis van het metamodel zoals dat tussen KING en Geonovum is afgestemd. Op basis daarvan zou toch uiteindelijk overname van het IMBAG model binnen RSGB en uiteindelijk het genereren van StUF berichtenspecificaties geen groot probleem mogen zijn.
Ruud, IMBAG bevat geen enkele conceptuele verandering zoals ik al eerder heb aangegeven. Het betreft zuiver een technische omzetting met behoorlijk wat impact voor de afnemers door de aanpassing van de unieke aanduiding, namen van attributen en (lijkt het) een paar nieuwe 'technische' attributen. Laat het duidelijk wezen we zijn absoluut niet tegen actualisering van de BAG, juichen dit zelfs toe maar dan moet dit wel een inhoudelijke zijn. Nu levert het niets op.
IMBAG voldoet aan het metamodel van KING, Kadaster en Geonovum? Ik heb dat ook in een van hun documenten gelezen. Helaas is dat nu niet het geval. Misschien hebben ze wel de intentie om dit te gaan doen.
Verder wil het nog niet zeggen dat als we gebruik maken van een en hetzelfde metamodel dat het makkelijker wordt modellen te integreren. Hoewel er wordt gezegd dat het IMBAG een semantisch model is, is het duidelijk een uitwisselingsmodel. De discussie wat een semantisch model is, is een heet hangijzer en voeren we al geruime tijd bij het tot standkomen van het gezamenlijk metamodel.