Link REV attributen en BAG attributen verduidelijken in naamgeving

[PeterFrans]

Aanleiding wijziging

In het IMEV 1.3 bestaan de volgende REV attributen met een link naar de BAG:

• adres;
• adresExploitant;
• adresseerbaarObjectIdentificatie;
• pandIdentificatie;
• gebruiksdoeleinden;
• oppervlakte;
• verwijzingBAG;
• identificatieBAG.

Vooral in het geval van 'adres' en 'adresExploitant' dekt de naam van het REV attribuut onvoldoende de inhoud. Dit leidt in de praktijk tot tot onduidelijkheid.

Voorgestelde wijziging

Ik stel hierbij daarom voor de naamgeving van deze REV attributen op een consistente manier aan te passen zodat deze de inhoud beter dekt:

• adres -> idNummeraanduidingBAG;
• adresExploitant -> idNummeraanduidingBAGExploitant;
• adresseerbaarObjectIdentificatie -> idAdresseerbaarobjectBAG;
• pandIdentificatie -> idPandBAG;
• gebruiksdoeleinden -> gebruiksdoelenVerblijfsobjectBAG (indien gehandhaafd en de definitie ongewijzigd blijft);
• oppervlakte -> oppervlakteVerblijfsobjectBAG (indien gehandhaafd);
• verwijzingBAG (ongewijzigd);
• identificatieBAG -> idBAG.

Verder:

• Is in de BAG sprake van 'gebruiksdoelen' ipv 'gebruiksdoeleinden' (REV). Hier is in het bovenstaande voorstel rekening mee gehouden;
• Wordt in de BAG alleen van 'Verblijfsobjecten' het oppervlak geregisteerd. De definitie van 'oppervlakte' in het REV ('Het oppervlakte van het gebouw zoals geregisteerd in de BAG' is dus onjuist. Dit zou moeten zijn: 'De gebruiksoppervlakte van een verblijfsobject in gehele vierkante meters zoals geregisteerd in de BAG'

Impactanalyse

Geef hier een indicatie van de impact van de wijziging:

• Wie gaat er wat van merken? Softwareleveranciers en dataproviders
• Veranderen definities van objecten in de standaard zodanig dat de wijziging impact heeft op de uit te wisselen gegevens? Nee
• Heeft het impact op het json-schema? Ja, want er veranderen attributen van naam.
• Is het een X,Y of Z-wijziging: X, want attribuutnamen veranderen

Prioriteit

midden

Toelichting

De voorgestelde naamgeving is consistent:

• Eerst wordt aangegeven welk BAG attribuut het betreft (identificatie / gebruiksdoelen / oppervlakte / verwijzing). Identificatiecode wordt hierbij consequent afgekort tot 'id' om eea kort te houden zonder dat het minder duidelijk wordt;
• Vervolgens wordt, als relevant, het overkoepelende BAG object vermeld (Nummeraanduiding / AdresseerbaarObject / Verblijfsobject);
• Daarna wordt 'BAG' genoemd, de overkoepelende basisregistratie;
• Als laatste, als relevant, wordt een 'REV specifieke' toelichting bijgevoegd.

Verder is het bovenstaande voorstel zoveel mogelijk lowerCamelCase (uitzondering: BAG. In het IMEV worden afkortingen in hoofdletters geschreven, dit heb ik in dit voorstel gehandhaafd).

[JanCasSmitGeonovum]

Expert overleg IMEV 16 MEI 2023, thema aansluiten op andere registraties

Voorgestelde wijziging inhoudelijk akkoord? Ja/ Nee/ ja, met aanpassing

1. Wat adviseren we de adviesgroep: doen
2. Wat is de prioriteit (midden)
3. Klopt de beschreven impact (Ja)

Dit is een onderwerp dat eerste met software leveranciers besproken moet worden.

gebruiksdoeleinden -> gebruiksdoelenVerblijfsobjectBAG (indien gehandhaafd en de definitie ongewijzigd blijft);
oppervlakte -> oppervlakteVerblijfsobjectBAG (indien gehandhaafd); zijn al bij #92 behandeld
verwijzingBAG (ongewijzigd);

[PB-GNM]

Tijdens het softwareleveranciersoverleg van 7 juni is het volgende besproken:

REM: deze wijziging heeft veel impact en is er geen voorstander van. Kan het eventueel ook met omschrijving worden opgelost?
VISMA en Stadsbeheer: staan nog in begin van de ontwikkeling. Dus hoe strakker het model, hoe fijner. Voor hen is de impact laag.
Afspraak: We nemen mee naar de adviesgroep dat de impact voor REM en REV groot is.
Tip: je zou een overgangsperiode kunnen gebruiken waarin je meerdere versies ondersteunt, omdat er een nieuwe API specificatie moet komen. Zo kan je tijd winnen om een aanpassing definitief te maken.

[PB-GNM]

Opgelost in versie 2.0.