Skip to main content
Skip table of contents

Handreiking aanleveren BRO-gegevens

Dit is versie 1.1 van deze handreiking. Ons doel is hiermee om de informatie mbt technische aanlevering van BRO gegevens in 1 document weer te geven. We streven met deze handreiking naar het weergeven van generieke informatie uit de diverse berichtencatalogi. Mocht u een fout aantreffen of een tekortkoming constateren, of anderszins feedback willen geven, neem dan contact op met de BRO Servicedesk via een mail naar support@broservicedesk.nl.

1. Inleiding

1.1. Voorwoord

Betrouwbare en toegankelijke informatie over de samenstelling en opbouw van de ondergrond is van groot belang voor een dichtbevolkt land als Nederland. Het helpt overheden, bedrijven en burgers om op feiten gebaseerde beslissingen te nemen over het gebruik van de ondergrond, bijvoorbeeld in verband met bereikbaarheid, waterveiligheid, warmte- en koudeopslag, aardgasproductie en de winning van aardwarmte. Centrale registratie van gegevens voorkomt dat informatie dubbel moet worden ingewonnen.

Het verzamelen, beschikbaar stellen, en gebruiken van al deze informatie is sinds september 2015 wettelijk vastgelegd in de Basisregistratie Ondergrond (BRO). Op 1 januari 2018 is het eerste deel van de Wet BRO in werking getreden, op 1 januari 2020 het tweede deel en op 1 januari c.q. 1 juli 2021 het derde deel. 

Omdat de BRO een onderdeel is van het Stelsel van Basisregistraties, zijn verplichtingen met betrekking tot aanlevering, gebruik, terugmelding en onderzoek in de werkprocessen van overheidsorganisaties opgenomen in de Wet BRO. De BRO-gegevens worden centraal geregistreerd in de Landelijke Voorziening BRO (LV-BRO).

In het document Handreiking Afname BRO Gegevens wordt beschreven via welke uitgiftekanalen BRO-gegevens geraadpleegd of gedownload kunnen worden en welke functionele en technische mogelijkheden deze kanalen bieden.

Blijft over de vraag hoe een bronhouder of dataleverancier gegevens aan kan leveren.

1.2. Doelstelling

Veel partijen worstelen met het op gang brengen van (de ontwikkeling van software voor) het aanleveren van BRO-gegevens. De weg naar een Gegevenscatalogus weet men over het algemeen wel te vinden. Ook het bestaan van het bronhouderportaal is meestal wel bekend. Maar hoe moet men een BRO-verzoek in de vorm van een XML-bestand opstellen? Hoe ziet zo'n XML-bestand er uit? Hoe moet je te werk gaan als de gegevens niet in één keer beschikbaar komen maar beetje bij beetje in de loop der tijd? Of veranderen in de loop der tijd? En hoe kun je een fout corrigeren, die is geslopen in de geregistreerde gegevens?

Op deze vragen probeert deze handreiking een antwoord in algemene zin te geven.

Dit document bevat geen informatie, die specifiek is voor een bepaald registratieobject. Daarvoor wordt doorverwezen naar de Berichtencatalogus innamewebservice en de Gegevenscatalogus, in die volgorde, van het betreffende registratieobject. Dit document beschrijft ook niet hoe een bronhouder of dataleverancier met het bronhouderportaal een BRO-verzoek kan aanleveren. Dat staat beschreven in de handleiding van het bronhouderportaal. Zie paragraaf Samenhang met andere documentatie voor nadere informatie over deze 2 onderwerpen.

1.3. Doelgroep

Doelgroep voor dit document zijn organisaties en personen, waaronder bestuursorganen en bedrijven, die opereren als bronhouder, gegevensleverancier of softwareleverancier en die betrokken zijn bij het opstellen van BRO-verzoeken. En waarvoor het opstellen van een BRO-verzoek en het aanleveren daarvan via het bronhouderportaal een nieuwe aangelegenheid is. Voor hen kan de hier aangereikte algemene informatie een waardevolle tussenstap zijn, voordat men verder gaat met de Berichtencatalogus of Gegevenscatalogus van een bepaald type registratieobject.

1.4. Samenhang met andere documentatie

De informatievoorziening over het aanleveren aan de BRO vindt plaats op 3 niveaus. Zie onderstaande figuur.


  1. Het startpunt met algemene informatie over de BRO is de website www.basisregistratieondergrond.nl. Een stappenplan voor het verkrijgen van toegang tot het Bronhouderportaal is te vinden op https://basisregistratieondergrond.nl/inhoud-bro/aanleveren-opvragen/tools-tips/bronhouderportaal

  2. Het tweede niveau is het Bronhouderportaal, met rechtsonderaan een link naar de gebruikshandleiding, zie BRO bronhouderportaal-handleiding

  3. Het derde niveau is de BRO Productomgeving. Hier vindt u onder meer algemene informatie en specifieke informatie per domein/registratieobjecttype, zie https://www.bro-productomgeving.nl/bpo/latest

Het verdient aanbeveling dat u zich eerst bekend maakt met de aangeven informatie uit de eerste 2 niveau's en daarna met de inhoud van dit document, de 'Handreiking aanleveren BRO-gegevens'. Deze algemene informatie kan een waardevolle tussenstap zijn, voordat u verder gaat met de Berichtencatalogus of Gegevenscatalogus van een bepaald type registratieobject (zie paragraaf BRO Productomgeving).

In de BRO Productomgeving vindt u zowel algemene informatie als specifieke informatie per domein/registratieobjecttype. Toegang tot specifieke informatie per domein en vervolgens registratieobjecttype is samengevat op landingspagina's. Zie de onderstaande tabel.

De specifieke informatie per domein en vervolgens per registratieobjecttype in de BRO Productomgeving is toegankelijk via landingspagina's. Zie de links in onderstaande tabel.


Op iedere landingspagina vindt u links naar:

  • Het Scope document.

  • De Gegevenscatalogus, met daarin de definities van de gegevens, en ook links naar de gemaakte werkafspraken.

  • De betreffende Berichtencatalogus innamewebservice, met daarin de definities van de beschikbare brondocumenten.

  • Een pagina met integrale voorbeeldberichten.

  • De website waar de WSDL-bestanden en de XSD-bestanden gevonden kunnen worden.

Voor het aanleveren van Modellen gelden andere regels. Neem in voorkomende gevallen contact op met de BRO Servicedesk (zie Contactinformatie).

1.5. Leeswijzer

Hoofdstuk 2 beschrijft de rol van het bronhouderportaal in het aanleverproces.

Hoofdstuk 3 bevat de beschrijving van een aantal Algemene concepten.

Hoofdstuk 4 bevat de beschrijving van de opbouw van een BRO-verzoek.

Hoofdstuk 5 bevat de definities van requests en hun transactiegegevens

Hoofdstuk 6 bevat enkele Scenario's voor het aanleveren van registratieverzoeken en correctieverzoeken.

Hoofdstuk 7 bevat enkele specifieke XML Code snippets uit de XML-bestanden van een BRO-verzoek.

Hoofdstuk 8 bevat een overzicht van Enumeraties (niet beheerde codelijsten) met hun toegestane waarden.

Hoofdstuk 9 bevat een doorkijkje naar de specifieke berichtencatalogi.

1.6. Versiehistorie

Versie

Datum

Omschrijving

1.0

30-06-2021

Eerste versie; afgeleid van de registratieobjecttype specifieke berichtencatalogi innameservice uit tranche 2 en 3.

1.1

03-09-2021

Redactionele aanpassingen, met name hoofdstuk1 (ten dele afgesplitst in wat nu hoofdstuk 2 is).

1.1.1

17 juni 2022

Toevoegen van 4 registratieobjecten: Grondwatergebruiksysteem, Grondwaterproductiedossier, Mijnbouwwetvergunning en Mijnbouwconstructie.

1.1.2

05-12-2022

Nadere uitleg Lijngeometrie.

1.1.3

09-01-2023

Nadere uitleg over gegevensgroeptype en property type (met name over inline vs by-reference opnemen van gerelateerd object).

1.7. Contactinformatie

Algemene informatie en documentatie over de BRO kunt u vinden op https://basisregistratieondergrond.nl/.

Heeft u een vraag over de BRO? Wij staan voor u klaar om u te helpen. Voor vragen, suggesties of opmerkingen kunt contact opnemen met de BRO Servicedesk via een mail naar support@broservicedesk.nl.

Of bel ons op telefoonnummer 088 - 8664 999. Wij zijn bereikbaar op werkdagen van 8.00 tot 17.00 uur.

2. Bronhouderportaal nodig om gegevens aan te leveren

Om het werk voor de bronhouders en gegevensleveranciers te vergemakkelijken, is het bronhouderportaal ontwikkeld. Het bronhouderportaal is een voorportaal voor het leveren aan de LV-BRO. Bronhouders van de BRO zijn wettelijk verantwoordelijk voor het aanleveren van gegevens en de kwaliteit daarvan. 

Vaak besteden bronhouders het inwinnen en aanleveren van gegevens uit aan een gegevensleverancier (bijvoorbeeld een ingenieursbureau voor sonderingen en boringen). Het is aan te raden contractueel vast te leggen dat een gegevensleveranciers de gegevens moet aanleveren bij de BRO. Let wel: de bronhouder blijft eindverantwoordelijk voor, onder andere, de kwaliteit van de aangeleverde gegevens.

Het bronhouderportaal is een webapplicatie voor de aanlevering van ondergrondgegevens aan de Basisregistratie Ondergrond (BRO). Met het bronhouderportaal kunnen de betrokken partijen zaakgericht de gegevens aanbieden, valideren, controleren, vaststellen en aanleveren bij de LV-BRO.

2.1. Gegevens aanleveren

Het bronhouderportaal is te vinden op webpagina https://www.bronhouderportaal-bro.nl/login. Rechtsonderaan op deze webpagina is een link is te vinden naar de gebruikshandleiding (zie BRO Bronhouderportaal handleiding).

Aanleveren van gegevens bij de LV-BRO kan alleen via het Bronhouderportaal. Zie Bronhouderportaal voor een inleiding en een link naar de handleiding. Bronhouders én gegevensleveranciers zijn verplicht te werken met het Bronhouderportaal. 

Het Bronhouderportaal is een zelfstandige webapplicatie met een automatische koppeling naar de LV-BRO. Hier kan een bronhouder de betrokken partijen en personen opvoeren en hun taken/autorisaties inrichten. Vervolgens kunnen nieuwe gegevens in vijf stappen worden aangeleverd, gevalideerd, gecontroleerd, vastgesteld en doorgeleverd aan de LV-BRO (zie onderstaande screenshots als toelichting).

Leveringsoverzicht


Naast de webpagina's beschikt het Bronhouderportaal ook over een REST API, waarmee u BRO-verzoeken geautomatiseerd kunt (laten) aanleveren. Volg hiervoor de online instructie REST API . De zendende software heeft voor dit proces een token nodig. De handleiding van het Bronhouderportaal beschrijft hoe een dataleverancier zo'n token kan aanmaken.

De demo-omgeving van de LV-BRO beschikt over een validatieservice. Volg hiervoor de online instructie validatiesevice. Met de validatieservice kunt u testen of een levering verwerkt kan worden door het Bronhouderportaal. U kunt op die manier fouten eruit halen voordat u de gegevens aanlevert bij het Bronhouderportaal. De validatieservice is alleen beschikbaar in de demo-omgeving. Op die manier wordt voorkomen dat een testbestand per ongeluk terecht komt in de productie-omgeving. In de demo-omgeving kunt u de validatieservice dus veilig gebruiken om uw bestanden te testen.

Elke levering bevat één of meer BRO-verzoeken om ondergrondgegevens in de BRO te registreren of te corrigeren (in het Bronhouderportaal worden de BRO-verzoeken abusievelijk omschreven als brondocumenten) . Elk BRO-verzoek is vastgelegd in een apart bestand in XML-formaat. De rest van dit document gaat over hoe zo'n BRO-verzoek opgesteld kan worden.

2.2. Wat gebeurt er met uw aangeleverde gegevens?

Nadat u de aangeleverde gegevens in het bronhouderportaal hebt gecontroleerd en vastgesteld, worden deze doorgeleverd naar de LV-BRO. Als een levering meerdere BRO-verzoeken bevat, dan worden deze een voor een verstuurd naar de innameservice van de LV-BRO. Helaas kan hierbij de onderlinge volgorde niet worden gegarandeerd. Dit kan ernstige nadelige gevolgen hebben als een BRO-verzoek voortborduurt op een ander BRO-verzoek in dezelfde levering. Plaats in voorkomende gevallen BRO-verzoeken in aparte leveringen, zodat u door het achtereenvolgens vaststellen van de leveringen controle behoudt over de volgorde waarin onderling afhankelijke BRO-verzoeken worden verwerkt.


De LV-BRO verwerkt een voor een de binnenkomende BRO-verzoeken. Iedere poging een BRO-verzoek te verwerken leidt tot een record in het transactieregister van de LV-BRO. Vervolgens wordt het BRO-verzoek inhoudelijk gecontroleerd. Dit begint met een validatie tegen de XML schema definities (de XSD-bestanden; zie https://schema.broservices.nl/). Daarna wordt gecontroleerd of de inhoud van het BRO-verzoek voldoet aan de bedrijfsregels, zoals vastgelegd in de betreffende gegevenscatalogus, de aanvullende regels in dit document en de aanvullende regels in de betreffende berichtencatalogus. Dit kan zijn op basis van de inhoud van het BRO-verzoek 'an sich' en/of binnen de context van de voor het registratieobject in de LV-BRO reeds geregistreerde gegevens. Als het BRO-verzoek akkoord wordt bevonden, wordt het brondocument in het BRO-verzoek opgeslagen in het brondocumentenregister en wordt de inhoud van het BRO-verzoek verwerkt in het objectregister van de LV-BRO. In alle gevallen leidt de poging een BRO-verzoek te verwerken tot een antwoord (naar het bronhouderportaal). In het antwoord staat ondermeer of de verwerking is geslaagd of niet. Als het om een nieuw registratieobject gaat, dan staat in het antwoord ook welke waarde voor het BRO-ID het registratieobject heeft gekregen. Op basis daarvan kunnen de geregistreerde gegevens worden gecorrigeerd, voor het geval het aangeleverde BRO-verzoek een fout bevatte, of kan het registratieobject, indien van toepassing, worden aangevuld, of kunnen de geregistreerde gegevens worden opgevraagd. Bewaar dit BRO-ID dus zorgvuldig!

2.3. Geregistreerde gegevens raadplegen

Een afnemer van de LV-BRO heeft de beschikking over diverse uitgifteportalen, waarmee in de LV-BRO geregistreerde gegevens geraadpleegd kunnen worden (zie Handreiking Afname BRO Gegevens). Overheidsorganen zijn in het kader van het Stelsel van Basisregistraties verplicht authentieke gegevens in de LV-BRO te gebruiken.

2.4. Terugmelden van fouten

De gegevens in de LV-BRO moeten voldoen aan aan hoge kwaliteitseisen. Desondanks kan een afnemer gerede twijfel hebben over de correctheid van een bepaald authentiek gegeven. In dat geval kan de afnemer een terugmelding plaatsen. Overheidsorganen zijn in het kader van het Stelsel van Basisregistraties verplicht in voorkomende gevallen een terugmelding te plaatsen. De terugmelding bevat in ieder geval het BRO-ID van het betreffende registratieobject. Terugmelden is een belangrijk middel om de kwaliteit van de geregistreerde gegevens te verbeteren.

Op basis van de terugmelding zal de registratiebeheerder (zie BRO Servicedesk bij Contactinformatie ) het registratieobject 'in onderzoek' plaatsen. Dat geeft voor andere afnemers aan, dat er een terugmelding is geplaatst op het registratieobject. Dat laat onverlet dat overheidsorganen verplicht zijn de momenteel geregistreerde authentieke gegevens in de LV-BRO te gebruiken.

De registratiebeheerder stuurt de terugmelding door naar de bronhouder van het registratieobject. Deze start een onderzoek of de gerede twijfel correct is. Zo ja, dan zal de bronhouder een correctieverzoek indienen, nu met de juiste gegevens. Zie paragraaf Corrigeren van gegevens bij een object zonder materiele geschiedenis of paragraaf Corrigeren van gegevens bij een object met materiële geschiedenis in het algemeen en de waarde 'inOnderzoek' in de codelijst CorrectionReason in het bijzonder. Het object is dan niet langer 'in onderzoek'. Ook als de bronhouder tot de conclusie komt dat de momenteel geregistreerde gegevens correct zijn, moet het object 'uit in onderzoek' genomen worden. Dat kan geautomatiseerd met een correctieverzoek, met als correctiereden 'inOnderzoek' en als inhoud van het brondocument nogmaals de actuele gegevens, of handmatig door de registratiebeheerder te vragen het registratieobject 'uit in onderzoek' te nemen. De bronhouder moet het correctieverzoek (laten) aanleveren via het bronhouderportaal.

3. Algemene concepten

De inhoud van de diverse BRO-verzoeken volgt een simpele, vaste structuur. Om deze varianten en hun structuur te kunnen begrijpen, beschrijft dit hoofdstuk een viertal algemene concepten. Kennisnemen van deze concepten helpt bij het bepalen wanneer welk type BRO-verzoek gebruikt moet worden en welke onderdelen van de vaste structuur van deze BRO-verzoeken dan van belang zijn.

3.1. Levensloop

3.1.1. Geen levensloop

Bij sommige objecten worden alle beschikbare gegevens altijd in een keer geregistreerd. Deze objecten hebben geen levensloop. De registratie van gegevens over zo'n object is dan een eenmalige gebeurtenis. 


Bovenstaande figuur visualiseert deze situatie. Een medewerker van de dataleverancier overhandigt alle gegevens in één keer aan de bronhouder (via het bronhouderportaal). De bronhouder zorgt ervoor dat de gegevens in één brondocument worden doorgeleverd naar de LV-BRO. Twee voorbeelden van registratieobjecttypes zonder levensloop: Geotechnisch Sondeeronderzoek (CPT) en Grondwatersamenstellingsonderzoek (GAR).

3.1.2. Wel levensloop

Andere objecten kennen een levensloop. De levensloop van een object heeft een begin en een eind. In deze periode kunnen gebeurtenissen optreden, naar aanleiding waarvan veranderingen in gegevens geregistreerd moeten worden in de LV-BRO. De registratie van gegevens over zo'n object is dus een proces dat zo lang duurt als het object bestaat.


Bovenstaande figuur visualiseert deze situatie.

Een medewerker van de dataleverancier en/of de bronhouder stelt een 'start document' op, waarmee de eerste gegevens voor het registratieobject worden aangeleverd bij het bronhouderportaal. De bronhouder zorgt ervoor dat de gegevens in één brondocument worden doorgeleverd naar de LV-BRO. Het spreekt voor zich dat het starten van de registratie een eenmalige gebeurtenis is.

Dezelfde of een andere medewerker zorgt ervoor dat er een of meerdere keren 'aanvullende gegevens', bijvoorbeeld naar aanleiding van een labonderzoek of wederkerend veldwerk, worden aangeleverd bij het bronhouderportaal. De bronhouder zorgt ervoor dat ieder brok met aanvullende gegevens automatisch of handmatig in een brondocument wordt doorgeleverd naar de LV-BRO. Het aanvullen van de registratie is een gebeurtenis die meerdere keren kan plaats vinden.

Als met de laatste aanvulling de registratie niet meteen wordt voltooid, dan zorgt de bronhouder ervoor dat er een 'afsluitend document' wordt opgesteld en dat de gegevens daarin via het bronhouderportaal als brondocoment worden doorgeleverd naar de LV-BRO. Het spreekt voor zich dat het voltooien van de registratie een eenmalige gebeurtenis is. Nadat de registratie van een registratieobject is voltooid, kan de registratie niet meer worden aangevuld.

Twee voorbeelden van registratieobjecttypes met levensloop: Bodemkundig booronderzoek (BHR-P) en Grondwaterstandonderzoek (GLD).

3.1.3. Aanlevertermijn

Gegevens moeten worden aangeboden met een registratieverzoekZie hoofdstuk "Definities van requests en hun transactiegegevens". Ongeacht of dit is naar aanleiding van een eenmalige gebeurtenis of een gebeurtenis gedurende een levensloop. Een dataleverancier moet gegevens tijdig registreren (binnen 20 werkdagen, zie artikel 9 in de Wet bro) . Het uitgangspunt is dat gegevens worden aangeleverd zo kort mogelijk nadat zij zijn geproduceerd. Bij objecten met een levensloop betekent tijdig ook in de juiste chronologische volgorde, namelijk de volgorde waarin de gebeurtenissen in de werkelijkheid zijn opgetreden. Dat veronderstelt dat de processen bij de dataleverancier zo zijn ingericht dat ze aansluiten op de productie van gegevens.

3.2. Gebeurtenissen

De aard van de gebeurtenis, die in de werkelijkheid optreedt tijdens de levensloop van een object, kan verschillen. Tenzij anders vastgelegd in de berichtencatalogus houdt de LV-BRO bij een object met levensloop een lijst bij van alle gemelde gebeurtenissen, c.q. de aangeboden brondocumenten. Daarbij worden de volgende gegevens opgeslagen, zodat binnnen een registratieobject een aangeleverd brondocument uniek geïdentificeerd kan worden:


  • date (datum): de datum waarop de gebeurtenis heeft plaats gevonden in de werkelijkheid. Dat is niet noodzakelijkerwijs dezelfde datum als waarop de betreffende gegevens worden aangeboden bij de LV-BRO (tijdstip registratie).

  • name (naam): de naam van de gebeurtenis, afgeleid van het type brondocument. Deze namen zijn opgenomen in een codelijst en per registratieobject gedefinieerd in de gegevenscatalogus.

  • (indien van toepassing) identification (identificatie): de unieke identificatie van een entiteit in een lijst van entiteiten binnen het registratieobject. Bijvoorbeeld meetpuntcode bij Grondwatermonitoringnet (GMN) of observatie ID bij Grondwaterstandonderzoek (GLD).

De gebeurtenissen moeten in chronologische volgorde worden aangeboden, dat wil zeggen in oplopende waarde voor het attribuut date (datum). Een 'vergeten' gebeurtenis, waarvan de date (datum) ouder is dan de meest recente, geregistreerde gebeurtenis, moet met een insertRequest (invoegverzoek) worden ingevoegd in de tijdlijn. Zie hoofdstuk "Definities van requests en hun transactiegegevens"

In de LV-BRO moet elke geregistreerde gebeurtenis uniek zijn. In de werkelijkheid kunnen op een bepaalde datum meerdere gebeurtenissen optreden. Bij de meeste types registratieobjecten volstaat het dat de combinatie van date (datum) en name (naam) van het Event (Gebeurtenis) uniek is. Bij sommige types registratieobjecten, met name wanneer er sprake is van een lijst van gegevens die aangevuld moet kunnen worden, is dit niet voldoende. Dan heeft ieder object of iedere gegevensgroep in een lijst met gegevens een unieke aanduiding. In dat geval vormt de combinatie van date (datum), name (naam) en identification (identificatie) een unieke combinatie in de lijst met Events (Gebeurtenissen). In voorkomende gevallen is dit aangeveven in de berichtencatalogus innamewebservice van het betreffende type registratieobject. De identification (identificatie) van een entiteit mag na eerste aanlevering niet worden gewijzigd door middel van een correctieverzoek, omdat anders niet correct gerefereerd kan worden naar deze entiteit in vervolg gebeurtenissen.

Deze lijst met gebeurtenissen wordt beschikbaar gesteld via de uitgifteservice. Aan de hand van de gebeurtenisnaam weet de dataleveranciers welk brondocument opgenomen moet worden in een correctieverzoek. En, indien van toepassing, aan de hand van de identification (identificatie) weet de leverancier welke entiteit (in de lijst met entiteiten) gecorrigeerd moet worden.

3.3. Tijdlijn

Bij een object met levensloop begint het proces van registreren met het starten van de registratie, gevolgd door het aanvullen en uiteindelijk het beëindigen van de registratie.


Bij het starten van de registratie geeft de bronhouder/dataleverancier een begindatum op. Deze datum moet in het verleden liggen. In de LV-BRO krijgt het registratieobject de registratiestatus GeregistreerdTotdat de registratie is voltooid blijft het registratieobject vanuit het oogpunt van de LV-BRO actief. Ook als er gedurende enige of langere tijd geen gebeurtenissen optreden in de werkelijkheid.

Wanneer zich gedurende de levensloop een relevante verandering voordoet, worden de nieuwe gegevens aangeboden bij de LV-BRO. In de LV-BRO krijgt het registratieobject de registratiestatus Aangevuld

Bij het beëindigen van de registratie geeft de bronhouder/dataleverancier een einddatum op. In de LV-BRO krijgt het registratieobject de registratiestatus VoltooidHierna kan het registratieobject niet meer worden aangevuld. De geregistreerde gegevens blijven na het beëindigen van de registratie opvraagbaar door afnemers.

3.4. Geschiedenis

De BRO maakt een onderscheid tussen materiële geschiedenis en formele geschiedenis. Bij materiële geschiedenis gaat het om een verandering in de werkelijkheid, waardoor bestaande gegevens een andere waarde krijgen of bestaande gegevens niet langer van belang zijn of dat er nieuwe gegevens ontstaan. Bij formele geschiedenis gaat het om corrigeren van (de waarde van) een in de LV-BRO geregistreerd gegeven, omdat er een fout is gemaakt. Zie voor een inleiding op dit onderwep de paragraaf met de titel "Formele en materiële geschiedenis" in één van de gegevenscatalogi.

3.4.1. Materiële geschiedenis

Bij materiële geschiedenis is de aanleiding voor het aanleveren van gegevens het optreden van een gebeurtenis in de werkelijkheid. Daarbij kan het gaan om het aanleveren van nieuwe gegevens, of het aanleveren van een nieuwe waarde voor een geregistreerd gegeven, of het melden dat een geregisteerd gegeven niet meer van belang is. Enkele voorbeelden: de inrichting van de put is gewijzigd; er is een nieuwe grondwaterstand gemeten; de vergunning is aangepast; een meetpunt wordt buiten gebruik genomen.

Bij het opbouwen van materiële geschiedenis is van belang dat de gegevens in de juiste chronologische volgorde worden aangeboden, namelijk de volgorde waarin de gebeurtenissen in de werkelijkheid zijn opgetreden.

Bij het opbouwen van materiële geschiedenis wordt een onderscheid gemaakt tussen aanvullingen en aanpassingen:

  • Aanvulling: er worden nieuwe gegevens toegevoegd aan het in de LV-BRO geregistreerde object. Hierbij is van belang dat de aangeboden gegevens nieuw zijn, dat wil zeggen hetzelfde gegeven is niet reeds aanwezig in de registratie.

  • Aanpassing: er worden nieuwe waarden voor reeds in de LV-BRO geregistreerde gegevens gemeld. Hierbij is van belang dat ieder tweetal van opeenvolgende waarden verschillend moet zijn.

In beide gevallen is het nieuwe gegeven of de nieuwe waarde geldig vanaf de datum van de gebeurtenis (datum begin geldigheid). Een voorgaande waarde blijft behouden en is geldig tot de datum van de gebeurtenis (datum einde geldigheid).

  • Een gegeven zonder een datum einde geldigheid noemen we een actueel gegeven.

  • Een gegeven met een datum einde geldigheid noemen we een historisch gegeven.

  • De waarde van een gegeven zonder een datum einde geldigheid noemen we de actuele waarde van het gegeven.

  • Een waarde van een gegeven met een datum einde geldigheid noemen we een historische waarde voor het gegeven.

Het opbouwen van materiële geschiedenis vindt plaats met een registratieverzoekZie hoofdstuk "Definities van requests en hun transactiegegevens".

3.4.2. Formele geschiedenis

Bij formele geschiedenis gaat het om het corrigeren van een onjuiste waarde in de registratie. De correctie vindt dus niet plaats naar aanleiding van een verandering in de werkelijkheid (materiële geschiedenis).

Een dataleverancier kan zich op allerlei manieren vergissen bij het aanbieden van gegevens. De dataleverancier kan bijvoorbeeld een typefout maken, of per ongeluk een onjuiste waarde voor een gegeven aanleveren, of een optioneel gegeven vergeten.

Bij een object met levensloop, waarbij er materiële geschiedenis wordt opgebouwd, kan er daarnaast sprake zijn van bijzondere fouten. Bijvoorbeeld een fout in de datum van een gebeurtenis, of vergeten gegevens aan te bieden naar aanleiding van een gebeurtenis, of omgekeerd aanbieden van gegevens naar aanleiding van een gebeurtenis maar deze gebeurtenis is helemaal niet opgetreden of is opgetreden voor een ander registratieobject.

Voor het corrigeren van fouten ondersteunt de LV-BRO een aantal verschillende soorten correctieverzoeken.Zie hoofdstuk "Definities van requests en hun transactiegegevens".

Bij een correctie wordt het betreffende gegeven in de registratie ondergrond overschreven, toegevoegd in de tijdlijn, verplaatst in de tijdlijn of verwijderd uit de tijdlijn. De oude waarde van een gegeven is niet meer direct beschikbaar voor een afnemer. Zou een afnemer toch willen weten wat de eerdere foute waarde was, dan moet deze het register brondocumenten van de LV-BRO raadplegen.

De formele geschiedenis wordt in de registratie ondergrond globaal vastgelegd in de registrationHistory (registratiegeschiedenis) van het object. Globaal wil zeggen dat alleen het tijdstip van de meest recente correctie wordt bijgehouden.

3.5. Aanvullende regels

Tijdens het verwerken van een BRO-verzoek voert de LV-BRO diverse controles uit. Zo wordt de inhoud van het brondocument gevalideerd tegen de gegevensdefinities in de gegevenscatalogus van het betreffende type registratieobject, inclusief de regels of indien van toepassing de IMBRO/A regels.

Het verwerken van een aanvulling, een beëindiging of een correctie verloopt anders dan (het starten van) een registratie in de zin dat er aanvullende regels worden toegepast. Die aanvullende regels zijn nodig omdat beoordeeld moet worden of de (gecorrigeerde) datum van de gebeurtenis past in de chronologische volgorde van de reeds geregistreerde gebeurtenissen en of de (gecorrigeerde) gegevens in het aangeboden brondocument passen bij de reeds in de LV-BRO geregistreerde gegevens. Deze aanvullende regels staan in de berichtencatalogus innamewebservice van het betreffende type registratieobject. 

Voor alle registratieobjecten met een levensloop gelden de volgende, algemene aanvullende regels:

  • De brondocumenten moeten in chronologische volgorde van date (datum) van het Event (Gebeurtenis) worden aangeleverd.

  • De combinatie van date (datum) en name (naam) van het Event (Gebeurtenis) en indien van toepassing de identification (identificatie) moet uniek zijn.

  • De identification (identificatie) van een entiteit mag na eerste aanlevering niet worden gewijzigd door middel van een correctieverzoek, omdat anders niet correct gerefereerd kan worden naar deze entiteit in vervolg gebeurtenissen.

  • Indien het domein PartialDate (OnvolldigeDatum) van toepassing is, mogen alleen de date (datum) van de start/eind gebeurtenis de waarde 'onbekend' hebben; de date (datum) van een tussenliggende gebeurtenis mag niet de waarde 'onbekend' hebben.

  • De registratie kan niet meer aangevuld of beëindigd worden zodra de registratie is beëindigd (registrationStatus = voltooid).

  • Bij het opbouwen en corrigeren van materiële geschiedenis moet ieder tweetal van opeenvolgende waarden van een gegeven verschillend zijn.

4. BRO-verzoek

Dit hoofdstuk beschrijft de opbouw van een BRO-verzoek.

4.1. Inleiding

Om gegevens te registreren in de LV BRO moet u deze aanleveren bij het Bronhouderportaal in de vorm van een BRO-verzoek. Het BRO-verzoek is een bestand in IMBRO/XML-formaat. De eenheid van aanleveren is een brondocument. Voor ieder onderkend type gebeurtenis, dat kan optreden in de werkelijkheid, definieert de BRO een apart type brondocument, toegesneden op het aanleveren van de gegevens die beschikbaar komen bij die gebeurtenis. De onderstaande figuur schetst de algemene opbouw van een BRO-verzoek.


Een BRO-verzoek bestaat uit de naam van het type request (BRO-verzoek), de transactiegegevens en een brondocument. 

De LV-BRO kent 6 request-types. De volgende 3 paragrafen leggen uit welk type request u wanneer moet gebruiken. Hoofdstuk "Definities van requests en hun transactiegegevens" definieert in detail de request-types en de bijbehorende transactiegegevens. De definities van de mogelijke brondocumenten kunt u vinden in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

4.2. Registreren van gegevens

Zoals beschreven in het hoofdstuk Algemene concepten kan er sprake zijn van het aanbieden van nieuwe gegevens in vier omstandigheden:

  1. Bij een object zonder levensloop: alle gegevens in één keer aanbieden naar aanleiding van een eenmalige gebeurtenis.

  2. Bij een object met levensloop:

    1. Als start van de registratie bij de eerste gebeurtenis.

    2. Als aanvulling bij een daarop volgende gebeurtenissen.

    3. Als beëindiging van de registratie bij de laatste gebeurtenis.

Voor alle 4 omstandigheden kan het registrationRequest (registratieverzoek) worden gebruikt. Zie de onderstaande figuur. Hoofdstuk "Definities van requests en hun transactiegegevens" definieert in detail het registrationRequest en de bijbehorende transactiegegevens. 


De linker variant (initieel) kunt u gebruiken bij de omstandigheden 1 en 2a. In dit geval maakt de LV-BRO bij de verwerking van dit BRO-verzoek een nieuw registratieobject aan.

De rechter variant (aanvulling of beëindiging) kunt u gebruiken bij de omstandigheden 2b en 2c. In dit geval wordt de registratie van een object aangevuld of beëindigd. Het verschil met de linker variant is dat in de rechter variant het attribuut broID (BRO-ID) moet worden opgenomen, terwijl dit attribuut bij de linker variant afwezig moet zijn. Het attribuut broId (BRO-ID) geeft aan welk registratieobject in de LV-BRO u wilt aanvullen (2b) of beëindigen (2c).

Ieder registratieobject in de LV-BRO heeft een unieke identificatie, het BRO-ID. Deze bestaat uit 3 letters en 12 cijfers. De drie letters bevatten de mnemonic (afkorting) van het type registratieobject en de 12 cijfers zijn een volgnummer inclusief voorloopnullen. Bijvoorbeeld BHR000000342786. Nadat een Levering is vastgesteld en de BRO-verzoeken daarin zijn doorgeleverd aan de LV-BRO en daar succesvol zijn verwerkt, toont het bronhouderportaal in het tabblad Lijst de BRO-ID's van de aangemaakt registratieobjecten. Zie onderstaande figuur.

Dit BRO-ID hebt u nodig als u een registratieobject wilt aanvullen, de registratie ervan wilt beëindigen, de geregistreerde gegevens wilt corrigeren of wilt verwijzen naar het registratieobject vanuit een ander registratieobject.

 


4.3. Corrigeren van gegevens bij een object zonder materiële geschiedenis

Het corrigeren van gegevens, dat wil zeggen het verbeteren van onjuistheden in de geregistreerde gegevens, is eenvoudig bij een object waarbij geen materiële geschiedenis wordt opgebouwd.

De eenheid van corrigeren is een brondocument.

De LV-BRO kent 1 type correctieverzoek voor het corrigeren van gegevens bij een object zonder materiële geschiedenis:

Naam in XML-bestand

Nederlandse naam

Doel

correctionRequest

correctieverzoek

Vervangen van een eerder aangeleverd brondocument bij een registratieobject zonder materiële geschiedenis.


Bij een correctieverzoek moet het volledige brondocument nogmaals worden aangeboden, maar nu met aangepaste (gecorrigeerde) gegegevens. Tenzij anders aangegegeven (zie de toegestane waarden van de codelijst CorrectionReason (correctiereden) in de betreffende Berichtencatalogus innamewebservice) is het niet mogelijk een brondocument te vervangen door een ander type brondocument.


De inhoud van een correctionRequest lijkt veel op die van een registrationRequest. Zie de onderstaande figuur. In vergelijking met een initieel registrationRequest zijn er 2 extra transactiegegevens. Het attribuut broID (BRO-ID) geeft aan welk registratieobject in de LV-BRO u wilt corrigeren. Het attribuut correctionReason (correctiereden) geeft aan waarom u de geregistreerde gegevens wilt corrigeren. Zie het hoofdstuk "Definities van requests en hun transactiegegevens" voor nadere details.


Of dit type correctieverzoek van toepassing is voor een bepaald type registratieobject kunt u vinden in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

Een correctieverzoek wordt net als een registratieverzoek via het bronhouderportaal aangeboden bij de innamewebservice. De LV-BRO valideert de gegevens in het correctieverzoek 'op zichzelf' en in relatie tot de in de registratie aanwezige gegevens. Welke regels, als aanvulling op de regels in de gegegevenscatalogus, hierbij van toepassing zijn, is afhankelijk van het type brondocument. Deze aanvullende regels kunt u vinden in de Berichtencatalogus innamewebservice van het betreffende type registratieobject. Enkele algemene aanvullende regels staan in paragraaf Aanvullende regels van dit document.

4.4. Corrigeren van gegevens bij een object met materiële geschiedenis

Het corrigeren van gegevens, dat wil zeggen het verbeteren van onjuistheden in de geregistreerde gegevens, bij een object waarbij materiële geschiedenis wordt opgebouwd, is ingewikkelder dan bij een object waarbij dat niet het geval is. Dat komt doordat de temporele integriteit van de tijdlijn in stand moet worden gehouden. Daartoe voert de LV-BRO een aantal controles uit tijdens het verwerken van een BRO-verzoek.

De eenheid van corrigeren is een brondocument.

De LV-BRO kent 4 types correctieverzoeken voor het corrigeren van gegevens bij een object met materiële geschiedenis:

Naam in XML-bestand

Nederlandse naam

Doel

replaceRequest

vervangverzoek

Vervangen van een eerder aangeleverd brondocument.

insertRequest

invoegverzoek

Invoegen van een 'vergeten' brondocument.

moveRequest

verplaatsverzoek

Verplaatsen van een eerder aangeleverd brondocument op de tijdlijn van de materiële geschiedenis.

deleteRequest

verwijderverzoek

Verwijderen van een eerder aangeleverd brondocument.


4.4.1. Algemene schets van de inhoud van de 4 correctieverzoeken

Bij een correctieverzoek moet hetzelfde brondocument nogmaals worden aangeboden, maar nu met aangepaste (gecorrigeerde) gegegevens. Tenzij anders aangegegeven (zie de toegestane waarden van de codelijst CorrectionReason (correctiereden) in de betreffende Berichtencatalogus innamewebservice) is het niet mogelijk een brondocument te vervangen door een ander type brondocument.

Alhoewel de LV-BRO tijdens het verwerken van een BRO-verzoek een aantal controles uitvoert m.b.t. de temporele integriteit van de tijdlijn, is het aan de bronhouder erop toe te zien dat het registratieobject in zijn geheel blijft voldoen aan de regels opgesteld in de gegevenscatalogus en de aanvullende regels in de berichtencatalogus innamewebservice. Dit speelt met name een rol als er bij een registratieobject meerdere brondocumenten zijn aangeleverd en één daarvan wordt gecorrigeerd. Voorbeeld: bij een booronderzoek mag slechts één boormonsterbeschrijving en één boormonsteranalyse aanwezig zijn. Voorbeeld: bij een grondwatermonitoringput mag alleen een aanwezige monitoringbuis opgelengd worden.

De inhoud van deze 4 correctieverzoeken lijkt veel op die van een registrationRequest. Zie de onderstaande figuur. In vergelijking met een registrationRequest zijn er 2 extra transactiegegevens. Het attribuut broID (BRO-ID) geeft aan welk registratieobject in de LV-BRO u wilt corrigeren. Het attribuut correctionReason (correctiereden) geeft aan waarom u de geregistreerde gegevens wilt corrigeren. Het moveRequest (verplaatsverzoek) heeft een derde extra transactiegegeven, dateToBeCorrected (te corrigeren datum). Dit bevat de datum van de gebeurtenis waarvan het brondocument verplaatst moet worden naar een andere datum (de juiste datum is opgenomen in het brondocument van het moveRequest). Zie het hoofdstuk "Definities van requests en hun transactiegegevens" voor nadere details.

Welke types correctieverzoeken van toepassing zijn voor een bepaald type registratieobject kunt u vinden in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

Alle 4 types van een correctieverzoek worden net als een registratieverzoek via het bronhouderportaal aangeboden bij de innamewebservice. De LV-BRO valideert de gegevens in het correctieverzoek 'op zichzelf' en in relatie tot de in de registratie aanwezige gegevens. Welke regels, als aanvulling op de regels in de gegegevenscatalogus, hierbij van toepassing zijn verschilt per type correctieverzoek en de inhoud van het correctieverzoek (met name het type brondocument). Deze aanvullende regels kunt u vinden in de Berichtencatalogus innamewebservice van het betreffende type registratieobject. Enkele algemene aanvullende regels staan in paragraaf Aanvullende regels van dit document.

4.4.2. ReplaceRequest

Met dit verzoek kan een bronhouder en/of dataleverancier onjuiste gegevens in de BRO op een bepaald punt op de tijdlijn vervangen door de juiste gegevens. De juiste gegevens worden aangeboden met één van de brondocumenten, zoals gedefinieerd in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie. Het aangeboden brondocument vervangt het momenteel geregistreerde brondocument.

Het is niet mogelijk de waarde van een individueel gegeven te corrigeren. Immers, de eenheid van aanleveren is een brondocument.

Met dit verzoek is het niet mogelijk de identificerende gegevens te corrigeren. 

Met dit verzoek is niet mogelijk de datum van de gebeurtenis te corrigeren (de gebeurtenis te verplaatsen op de tijdlijn).

Vervangen is een correctie die op geen enkele wijze iets verandert in de tijdlijn van een registratieobject. De dataleverancier dient een vervangverzoek in wanneer er eerder een brondocument is aangeleverd met daarin de goede datum van de gebeurtenis, maar met fouten in een of meer van de andere gegevens. Alle gebeurtenissen zijn in de juiste volgorde en met de juiste datum geregistreerd. Bij het verwerken van een vervangverzoek wordt er formele geschiedenis opgebouwd. Zie voor nadere toelichting de inleiding in de gegevenscatalogus.

Onderstaande figuur geeft weer dat de (waarden van) gegevens op het punt T2 op de tijdlijn worden vervangen.


4.4.3. InsertRequest

Met dit verzoek kan een bronhouder en/of dataleverancier de materiële geschiedenis corrigeren door het invoegen van een gebeurtenis op de tijdlijn. Het kan daarbij gaan om het invoegen van nieuwe gegevens op een bepaalde datum, of om het invoegen van nieuwe waarden voor bestaande gegevens op een bepaalde datum. In beide gevallen ligt de bepaalde datum vóór de datum van de meest recente, geregistreerde gebeurtenis. 

Invoegen is een correctieverzoek dat ingrijpt in de materiële geschiedenis van een registratieobject. Het gaat om de eenvoudigste variant, namelijk de situatie waarin de dataleverancier vergeten was een gebeurtenis te registreren terwijl er ondertussen een andere gebeurtenis is geregistreerd.

De tussen te voegen (waarden van) gegevens worden aangeboden met één van de brondocumenten, zoals gedefinieerd in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

Het is niet mogelijk de waarde van een individueel gegeven tussen te voegen. Immers, de eenheid van aanleveren is een brondocument.

De tussen te voegen (waarden van) gegevens zijn geldig vanaf de datum gebeurtenis opgenomen in het brondocument tot en met de datum van de chronologisch eerstvolgende gebeurtenis, waarin hetzelfde feature (object) met dezelfde identificerende gegevens voorkomt. De (waarden van) gegevens van het feature (object) met dezelfde identificerende gegevens, dat voorkomt in een chronologisch voorafgaande gebeurtenis, verliezen hun geldigheid vanaf de datum gebeurtenis opgenomen in het brondocument.

Onderstaande figuur geeft weer dat nieuwe (waarden voor) gegevens worden ingevoegd op het punt T3 van de tijdlijn tussen de punten T2 en Tn.


4.4.4. MoveRequest

Met dit verzoek kunnen gegevens worden verplaatst op de tijdlijn.

Verplaatsen is een correctie die ingrijpt in de materiële geschiedenis van een registratieobject. Het gaat om de situatie waarin de dataleverancier de juiste gegevens heeft aangeleverd maar met de verkeerde datum voor de gebeurtenis. Om de fout te herstellen, levert de dataleverancier het brondocument nogmaals aan maar nu met de juiste datum erin en met het verzoek de gegevens te verplaatsen. Om aan te geven over welke gebeurtenis het precies gaat geeft hij de onjuiste datum mee in het attribuut dateToBeCorrected (te corrigeren datum) van de transactiegegevens van het moveRequest.

De te verplaatsen gegevens, inclusief de gewenste nieuwe datum van de gebeurtenis, worden aangeboden met één van de brondocumenten, zoals gedefinieerd in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

Het is niet mogelijk de begingeldigheid van een individueel gegeven te verplaatsen in de tijd. Immers, de eenheid van aanleveren is een brondocument.

Onderstaande figuur geeft weer dat de begingeldigheid van de (waarden van) gegevens op het punt T2 op de tijdlijn wordt verschoven naar T2'. Merk op dat de eindgeldigheid van de (waarden van) gegevens, die op T2 gewijzigd werden, nu een eindgeldigheid T2' hebben. De gecorrigeerde datum T2' mag niet liggen voor T0 (de datum waarmee de registratie wordt gestart). De gecorrigeerde datum T2' mag niet liggen na Te (de datum waarmee de registratie wordt beëindigd).


4.4.5. DeleteRequest

Met dit verzoek kan een bronhouder en/of dataleverancier gegevens verwijderen uit de tijdlijn, omdat de dataleverancier een gebeurtenis heeft geregistreerd die nooit heeft plaatsgevonden (voor dit registratieobject).

Verwijderen is een correctie die ingrijpt in de materiële geschiedenis van een registratieobject. Het gaat om de situatie waarin de dataleverancier ten onrechte een brondocument heeft aangeleverd. Om de fout te herstellen, levert de dataleverancier het eerder aangeleverde brondocument nogmaals aan maar nu met het verzoek de gegevens die erin staan uit de registratie te verwijderen.

Met een deleteRequest (verwijderverzoek) kan de dataleverancier de materiële geschiedenis corrigeren door een gebeurtenis te verwijderen van de tijdlijn (verwijderen van gegevens op een bepaalde datum). De te verwijderen gegevens worden aangeboden met één van de brondocumenten, zoals gedefinieerd in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie. 

Het is niet mogelijk de waarde van een individueel gegeven te verwijderen. Immers, de eenheid van aanleveren is een brondocument.

Onderstaande figuur geeft weer dat de (waarden voor) gegevens op het punt T3 op de tijdlijn worden verwijderd. Merk op dat dit complexe gevolgen heeft voor de begingeldigheid en de eindgeldigheid van de (waarden van) gegevens (hoogstwaarschijnlijk T1 en Tn, maar misschien T0 .. Te).


5. Definities van requests en hun transactiegegevens

De LV-BRO kent 6 request-types (verzoeken). Zie onderstaande tabel. 

Naam in XML-bestand

Nederlandse naam

Doel

registrationRequest

registratieverzoek

Registreren van nieuwe gegevens in de LV-BRO. Dit kan zijn het in één keer aanbieden van alle gegevens bij een object zonder levensloop. Of het starten, aanvullen of beëindigen van de registratie bij een object met levensloop.

correctionRequest

correctieverzoek

Vervangen van een eerder aangeleverd brondocument bij een registratieobject zonder materiële geschiedenis.

replaceRequest

vervangverzoek

Vervangen van een eerder aangeleverd brondocument op een bepaald punt op de tijdlijn bij een registratieobject met materiële geschiedenis.

insertRequest

invoegverzoek

Invoegen van een brondocument op de tijdlijn bij een registratieobject met materiële geschiedenis.

moveRequest

verplaatsverzoek

verplaatsen van een brondocument op de tijdlijn (wijzigen van de datum van een gebeurtenis) bij een registratieobject met materiële geschiedenis.

deleteRequest

verwijderverzoek

Verwijderen van een brondocument uit de tijdlijn bij een registratieobject met materiële geschiedenis.


Ieder van deze requests (verzoeken) bevat een aantal transactiegegevens en een brondocument. Welke transactiegegevens opgenomen mogen/moeten worden in welk type request, is geschetst in het vorige hoofdstuk. De volgende paragrafen van dit hoofdstuk bevatten de definities van de transactiegegevens. De brondocumenten zijn gedefinieerd in de Berichtencatalogus innamewebservice van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

5.1. requestReference

Naam in XML-bestand

requestReference

Nederlandse naam

verzoekkenmerk

Definitie

Een voor de dataleverancier unieke aanduiding van het innameverzoek .

Juridische status

Niet-authentiek

Kardinaliteit

1

Domein


 Type

CharacterString

 Maximale lengte

200

Materiële geschiedenis

Nee


5.2. deliveryAccountableParty 

Naam in XML-bestand

deliveryAccountableParty

Nederlandse naam

bronhouder

Definitie

Het KvK-nummer van de maatschappelijke activiteit van de publiekrechtelijke rechtspersoon die bronhouder is van de gegevens in de basisregistratie ondergrond.

Juridische status

Authentiek

Kardinaliteit

0..1

Domein


 Naam

ChamberOfCommerceNumber

 Type

Integer

 Opbouw

NNNNNNNN

Regels

Dit transactiegegeven moet aanwezig zijn als de dataleverancier niet de bronhouder is.

Dit transactiegegeven mag afwezig zijn als de dataleverancier tevens bronhouder is en zelf het verzoek indient.

Materiële geschiedenis

Nee

Toelichting

Het transactiegegeven wordt door de dataleverancier bij het aanbieden van het BRO-verzoek meegegeven in het geval de dataleverancier niet de bronhouder is.


5.3. broId

Naam in XML-bestand

broId

Nederlandse naam

BRO-ID

Definitie

De unieke identificatie van een registratieobject in de LV-BRO.

Juridische status

Authentiek

Kardinaliteit

0..1

Domein


 Naam

Registratieobjectcode

 Type

CharacterString

 Opbouw

AAANNNNNNNNNNNN

Regels

Dit transactiegegeven mag niet aanwezig zijn bij het starten van de registratie.

Dit transactiegegeven moet aanwezig zijn bij het aanvullen of beëindigen van de registratie.

In de LV-BRO moet een registratieobject met deze broId aanwezig zijn, als dit attribuut aanwezig is.

Materiële geschiedenis

Nee

Toelichting

De basisregistratie ondergrond kent bij (het starten van) de registratie automatisch een waarde toe aan het registratieobject.


5.4. qualityRegime 

Naam in XML-bestand

qualityRegime

Nederlandse naam

kwaliteitsregime

Definitie

De aanduiding van het kwaliteitsregime waaraan de gegevens in het brondocument voldoen.

Juridische status

Authentiek

Kardinaliteit

1

Domein


 Naam

QualityRegime

 Type

Waardelijst niet uitbreidbaar

Regels

Toegestane waarden zijn IMBRO en IMBRO/A.

De waarde IMBRO/A is bij het aanvullen of beëindigen van een registratie alleen toegestaan als de registratie is gestart met een kwaliteitsregime IMBRO/A.

Materiële geschiedenis

Nee

Toelichting

De gegevenscatalogus geeft aan wat bij een waarde voor het kwaliteitsregime de gevolgen zijn voor de kardinaliteit, het domein en de bedrijfsregels van de gegevensinhoud van een brondocument.


5.5. underPrivilege

Naam in XML-bestand

underPrivilege

Nederlandse naam

onder voorrecht

Definitie

De aanduiding die aangeeft dat de dataleverancier het recht heeft putten met voorgeschiedenis aan te leveren. Tijdelijk voor iedereen van toepassing.

Juridische status

Niet-authentiek

Kardinaliteit

0..1

Domein


 Naam

IndicatieJaNee

 Type

Waardelijst niet uitbreidbaar

Regels

Alleen de waarde 'ja' is toegestaan.

Dit transactiegegeven mag aanwezig zijn bij het aanbieden van een GMW (Grondwatermonitoringput) brondocument.

Dit transactiegegeven mag niet aanwezig zijn bij alle andere registratieobjecttypes.

Materiële geschiedenis

Nee

Toelichting

Bij het aanbieden van historische (archief) gegevens van een object met levensloop kan het voorkomen dat niet alle datums van de gebeurtenissen exact bekend zijn. Onder dit voorrecht mag een brondocument van een put met voorgeschiedenis een gebeurtenisdatum bevatten met een waarde uit het domein PartialDate (OnvolledigeDatum). Om de brondocumenten toch aan te kunnen leveren, moet hiervoor vanaf 3 juni 2019 dit transactiegegeven altijd worden toegevoegd, zowel bij IMBRO als IMBRO/A als kwaliteitsregime.

XML coderegel: <brocom:underPrivilege>ja</brocom:underPrivilege>


5.6. correctionReason

Naam in XML-bestand

correctionReason

Nederlandse naam

correctiereden

Definitie

Aanduiding voor de reden waarom het registratieobject wordt gecorrigeerd/vervangen/ingevoegd/verplaatst/verwijderd.

Juridische status

Niet-authentiek

Kardinaliteit

0..1

Domein


 Naam

CorrectionReason

 Type

Waardelijst uitbreidbaar

Regels

Tenzij anders vastgelegd in de Berichtencatalogus innamewebservice van het betreffende registratieobject (zie de paragraaf Samenhang met andere documentatie voor nadere informatie) is de lijst met toegestane waarden, hun betekenis en de generieke, aanvullende regels van toepassing zoals beschreven op de pagina CorrectionReason.

Materiële geschiedenis

Nee


5.7. dateToBeCorrected

Naam in XML-bestand

dateToBeCorrected

Nederlandse naam

te corrigeren datum

Definitie

De gebeurtenisdatum die moet worden verbeterd.

Juridische status

Authentiek

Kardinaliteit

0..1

Domein


 Naam

Date

 Waardebereik

De waarde mag niet in de toekomst liggen.

Domein IMBRO/A

PartialDate

Regels

Dit transactiegegeven moet aanwezig zijn in een moveRequest (verplaatsverzoek).

Dit transactiegegeven mag niet aanwezig zijn bij alle andere requesttypes.

Regels IMBRO/A

Dit transactiegegeven mag een PartialDate (Onvolledige datum) bevatten wanneer het transactiegegeven qualityRegime (kwaliteitsregime) de waarde IMBRO/A heeft.

Materiële geschiedenis

Nee


6. Scenario's

Dit hoofdstuk bevat enkele scenario's voor het aanleveren van registratieverzoeken en correctieverzoeken.

6.1. Aanleveren deelonderzoeken bij Bodem- en grondonderzoek

De registratieobjecten in het domein Bodem- en grondonderzoek, met uitzondering van Geotechnisch sondeeronderzoek (CPT), hebben de kenmerkende eigenschappen dat zij bestaan uit diverse deelonderzoeken, die ook nog eens in fasen zijn opgeleverd.

Als gevolg van de eerste eigenschap is het mogelijk de resultaten van een b odem- of grondonderzoek per deelonderzoek aan te leveren . Deze registratieobjecten kennen dus een levensloop (zie hoofdstuk Algemene concepten). 

De tweede eigenschap heeft geleid tot verschillende versies van de gegevenscatalogi, berichtencatalogi en XSD-bestanden, die door verschillende versies van de betreffende innamewebservice worden ondersteund.

Dit heeft geleid tot een aantal brondocumenten:

Brondocument

Doel

BHR_P

Het brondocument dat het bodemkundig booronderzoek in zijn volledigheid beschrijft. De registratie is met dit brondocument voltooid.

BHR_P_BSD

Het brondocument dat van een bodemkundig booronderzoek, dat zowel een bodemkundige boormonsterbeschrijving als een boormonsteronderzoek beslaat, alleen de boormonsterbeschrijving bevat. De registratie is met dit brondocument gestart.

BHR_GT_CompleteReport_V1

Het brondocument wordt aangeboden wanneer de rapportage van het geotechnisch booronderzoek in een keer volledig wordt gerapporteerd. De registratie is met dit brondocument direct voltooid.

BHR_GT_StartReport_V1

Het brondocument wordt aangeboden wanneer de rapportage van het geotechnisch booronderzoek in delen wordt gerapporteerd. De registratie is met dit brondocument gestart.

BHR_GT_EndReport_V1

Het brondocument wordt aangeboden wanneer het geotechnisch booronderzoek wordt aangevuld met de laatste rapportage en daarmee volledig is gerapporteerd. De registratie is met dit brondocument voltooid.

SFR_CompleteReport_V1

Het brondocument wordt aangeboden wanneer het bodemkundig wandonderzoek uit 1 deelonderzoek bestaat en daarmee in een keer volledig wordt gerapporteerd. De registratie is met dit brondocument voltooid.

SFR_StartReport_V1

Het brondocument wordt aangeboden wanneer het bodemkundig wandonderzoek uit meerdere deelonderzoeken bestaat en het eerste deelonderzoek wordt gerapporteerd. De registratie is met dit brondocument gestart.

SFR_EndReport_V1

Het brondocument wordt aangeboden wanneer het bodemkundig wandonderzoek wordt aangevuld met de laatste rapportage en daarmee volledig is gerapporteerd. De registratie is met dit brondocument voltooid.


Merk op dat in de naam van de brondocumenten een versienummer is opgenomen (uitgezond bij BHR-P), die overigens altijd een waarde _V1 heeft.

Merk op dat ieder deelonderzoek altijd in 1 keer compleet moet worden aangeleverd. Dus bijvoorbeeld bij het aanleveren van de boormonsteranalyse moet men alle resultaten van bepalingen op diverse dieptes als 1 geheel aanleveren.

De vragen die hier beantwoord worden zijn: in welke volgorde, met welke brondocumenten en met welke BRO-verzoeken moeten de deelonderzoeken a angeleverd worden?

6.1.1. Alle deelonderzoeken in 1 keer aanleveren

Stel dat de gegevens van de deelonderzoeken tegelijkertijd beschikbaar komen, of in ieder geval binnen 20 dagen, de wettelijke termijn waarbinnen beschikbaar gekomen gegevens aangeleverd moeten worden bij de LV-BRO. Dan kunnen deze het beste in één keer aangeleverd worden:

  • Bij BHR-P in een BHR_P brondocument, verzonden in een initieel registrationRequest.

  • Bij BHR-GT in een BHR_GT_CompleteReport_V1 brondocument, verzonden in een initieel registrationRequest.

  • Bij SFR in een SFR_CompleteReport_V1 brondocument, verzonden in een initieel registrationRequest.

Zie paragraaf Registreren van gegevens voor een beschrijving van het registrationRequest.

6.1.2. Tweede deelonderzoek aanleveren door aanvullen

Stel dat de gegevens van de deelonderzoeken enige tijd na elkaar beschikbaar komen, dan moeten deze in chronologische volgorde worden aangeboden. Stel dat eerst de beschrijving en daarna de analyse beschikbaar komt, dan kunnen deze als volgt aangeleverd worden:

  • Bij BHR-P:

    • eerst de beschrijving in een BHR_P_BSD brondocument, verzonden in een initieel registrationRequest.

    • voor het daarna aanleveren van de analyse is nog geen brondocument gedefinieerd. Neem in voorkomende gevallen contact op het de BRO (Self)Servicedesk (zie paragraaf Contactinformatie).

  • Bij BHR-GT:

    • eerst de beschrijving in een BHR_GT_StartReport_V1 brondocument, verzonden in een initieel registrationRequest.

    • daarna de analyse in een BHR_GT_EndReport_V1, verzonden in een aanvulling of beëindiging registrationRequest

  • Bij SFR:

    • eerst de beschrijving in een SFR_StartReport_V1 brondocument, verzonden in een initieel registrationRequest.

    • daarna de analyse in een SFR_EndReport_V1, verzonden in een aanvulling of beëindiging registrationRequest.

Zie paragraaf Registreren van gegevens voor een beschrijving van het registrationRequest.

Merk op dat alle deelonderzoeken van 1 bodem- of grondonderzoek uiteraard bij elkaar horen en dus vallen onder 1 BRO-ID. Levert u de gegevens per deelonderzoek aan, dan krijgt u bij het initiële registrationRequest, met het eerste deelonderzoek, het BRO-ID retour. Dit BRO-ID moet u dus gebruiken bij de aanvullende registrationRequests met de andere deelonderzoeken.

6.1.3. Tweede deelonderzoek aanleveren door corrigeren

Stel dat de gegevens van de deelonderzoeken enige tijd na elkaar beschikbaar komen, dan moeten deze in chronologische volgorde worden aangeboden. Stel dat eerst de beschrijving beschikbaar komt en dat deze is aangeleverd met een 'complete' report. Stel dat enige tijd later de analyse beschikbaar komt. Dan kan de oorspronkelijke registratie als volgt worden gecorrigeerd:

  • Bij BHR-P:

    • eerst de beschrijving in een BHR_P brondocument, verzonden in een initieel registrationRequest.

    • daarna het oorspronkelijke BHR_P brondocument met de beschrijving, aangevuld met de analyse, verzonden in een correctionRequest

  • Bij BHR-GT:

    • eerst de beschrijving in een BHR_GT_CompleteReport_V1 brondocument, verzonden in een initieel registrationRequest.

    • daarna het oorspronkelijke BHR_GT_CompleteReport_V1 brondocument met de beschrijving, aangevuld met de analyse, verzonden in een correctionRequest

  • Bij SFR:

    • eerst de beschrijving in een SFR_CompleteReport_V1 brondocument, verzonden in een initieel registrationRequest.

    • daarna het oorspronkelijke SFR_CompleteReport_V1 brondocument met de beschrijving, aangevuld met de analyse, verzonden in een correctionRequest.

Zie paragraaf Registreren van gegevens voor een beschrijving van het registrationRequest en paragraaf Corrigeren van gegevens bij een object zonder materiële geschiedenis voor een beschrijving van het correctionRequest.

Merk op dat alle deelonderzoeken van 1 bodem- of grondonderzoek uiteraard bij elkaar horen en dus vallen onder 1 BRO-ID. Levert u de gegevens per deelonderzoek aan, dan krijgt u bij het initiële registrationRequest, met het eerste deelonderzoek, het BRO-ID retour. Dit BRO-ID moet u dus gebruiken bij het correctionRequest om de geregistreerde gegevens met het ene deelonderzoek te vervangen door de gegevens van beide deeelonderzoeken.

7. XML Code snippets

Dit hoofdstuk bevat enkele specifieke, kleine stukjes code uit de XML-bestanden van een BRO-verzoek.

Integrale voorbeeldberichten zijn te vinden via de links op de landingspagina van het betreffende registratieobject; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

7.1. De kop van een request

De kop van elk type request (BRO-verzoek) heeft dezelfde structuur.

De eerste regel bevat de XML-proloog. Merk op dat de tekens volgens UTF-8 moeten worden gecodeerd. Dit is met name van belang voor speciale tekens, zoals à, á, ï.

Regel 2 bevat de opening tag van het request (BRO-verzoek). Dat moet dus zijn registrationRequest (registratieverzoek), correctionRequest (correctieverzoek), replaceRequest (vervangverzoek), insertRequest (invoegverzoek), moveRequest (verplaatsverzoek) of deleteRequest (verwijderverzoek). Zie de hoofdstukken BRO-verzoek en Scenario's voor nadere informatie welk type request u wanneer kunt/moet gebruiken.

Regel 3 t/m 8 bevatten prefixes voor de namespaces van de gebruikte XML-schemadefinities (XSD's). Welke namespaces precies nodig zijn hangt af van het registratieobject, het BRO-verzoek en de inhoud van het brondocument. Het aantal regels met namespaces kan dus variëren.

Regel 9 en 10 maken het mogelijk het BRO-verzoek te valideren tegen de XSD-bestanden van de innamewebservice. Deze twee XML-attributen mogen worden weggelaten.

Regel 12 bevat een disclaimer. Deze tekst is opgenomen als commentaar (begint met <!-- en eindigt met -->) en mag worden weggelaten. Commentaar mag meerdere regels beslaan. Commentaar binnen commentaar is niet toegestaan. Binnen een commentaar mogen geen 2 of meer mintekens (--) naast elkaar voorkomen.

Na de disclaimer volgen twee tot zeven transactiegegevens en het brondocument: requestReference (verzoekkenmerk), deliveryAccountableParty (bronhouder), broId (BRO-ID), qualityRegime (kwaliteitsregime), underPrivilege (onder voorrecht), correctionReason (correctiereden), sourceDocument (brondocument) en dateToBeCorrected (te corrigeren datum). Zie paragraaf Brondocument voor een beschrijving van dit stukje XML-code. Zie hoofdstuk "Definities van requests en hun transactiegegevens" voor een gedetailleerde specificatie van de transactiegegevens, inclusief uitleg wanneer een transactiegegeven mag of moet voorkomen. Merk op dat de transactiegegevens correctionReason (correctiereden) en dateToBeCorrected (te corrigeren datum) en het sourceDocument (brondocument) gedefinieerd zijn binnen de namespace van de betreffende innamewebservice (geen namespace prefix hebben) en dat de andere transactiegegevens gedefinieerd zijn binnen de namespace van brocommon.xsd (met de namespace prefix brocom).

Het BRO-verzoek wordt afgesloten met de closing tag van het request (BRO-verzoek).

CODE
<?xml version="1.0" encoding="UTF-8"?>
<moveRequest
    xmlns="http://www.broservices.nl/xsd/isbhr-gt/2.1"
    xmlns:bhrgtcom="http://www.broservices.nl/xsd/bhrgtcommon/2.1"
    xmlns:brocom="http://www.broservices.nl/xsd/brocommon/3.0"
    xmlns:swe="http://www.opengis.net/swe/2.0"
    xmlns:gml="http://www.opengis.net/gml/3.2"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.broservices.nl/xsd/isbhr-gt/2.1 https://schema.broservices.nl/xsd/isbhr-gt/2.1/isbhr-gt-messages.xsd"
    >
    <!-- Disclaimer: dit voorbeeldbericht valideert tegen de validatieservice van de acceptatie omgeving van het bronhouderportaal, maar de gegevens zijn fictief en waarschijnlijk niet correct.-->
    <brocom:requestReference>verzoek_2</brocom:requestReference>
    <!--Optional:-->
    <brocom:deliveryAccountableParty>27376655</brocom:deliveryAccountableParty>
    <!--Optional: alleen toegestaan bij een registrationRequest voor het aanvullen of beëindigen van de registratie of een correction/replace/insert/move/delete request.-->
    <brocom:broId>BHR000000342106</brocom:broId>
    <brocom:qualityRegime>IMBRO</brocom:qualityRegime>
    <!--Optional: alleen toegestaan bij GMW
    <brocom:underPrivilege>ja</brocom:underPrivilege>
    -->
    <!--Optional: alleen toegestaan bij een correction/replace/insert/move/delete request.-->
    <correctionReason codeSpace="urn:bro:bhrgt:CorrectionReason">eigenCorrectie</correctionReason>
    <sourceDocument>
       ...
    </sourceDocument>
    <!--Optional: alleen toegestaan bij een moveRequest.
    <dateToBeCorrected>
      <brocom:date>2015-02-08</ns1:date>
    </dateToBeCorrected>
    -->
</moveRequest>


7.2. Brondocument

Ieder BRO-verzoek bevat een brondocument. Een brondocument is de eenheid van aanleveren. Tenzij een brondocument slechts één attribuut bevat is het niet mogelijk individuele attributen aan te leveren of te corrigeren.

Voor de meeste registratieobjecten kent de betreffende innamewebservice meerdere types brondocumenten. Deze worden gedefinieerd in de betreffende berichtencatalogus; zie de paragraaf Samenhang met andere documentatie voor nadere informatie.

Ieder brondocument heeft in het UML ontwerp het stereotype FeatureType. Conform de GML XML encoding rules wordt daarom bij een brondocument het property type pattern toegepast. Zie ook de paragraaf Property type pattern. Bij de brondocumenten wordt (over het algemeen) alleen de mogelijkheid om een brondocument inline op te nemen ondersteund.

Onderstaand stukje XML van een voorbeeldbericht laat zien hoe dat uitpakt. Na de opening tag sourceDocument (brondocument) volgt een XML-element met als tag de naam van het type brondocument, bijvoorbeeld GMN_StartRegistration. Dit XML-element geeft aan welk type brondocument in dit BRO-verzoek is opgenomen. Om deze constructie mogelijk te maken zijn de brondocumenten als root element gedefinieerd in het betreffende XSD-bestand. Zo is het XML-element GMN_StartRegistration als root element gedefinieerd in het XSD-bestand isgmn-messages.xsd van de GMN innamewebservice.

De daadwerkelijke inhoud van het brondocument volgt na de opening tag van het type brondocument; hier weergegeven door 3 punten.

CODE
...
<sourceDocument>
  <GMN_StartRegistration gml:id="id_0001">
    ...
  </GMN_StartRegistration>
</sourceDocument>
...


7.3. Codelijst

Zie de pagina Codelist (Codelijst)

7.4. CorrectionReason

Zie de pagina CorrectionReason (Correctiereden)

7.5. Datum

Diverse gegevenscatalogi definieren een aantal gegevens met als domein Datum. In een XSD-bestand heeft het betreffende XML-element het type xs:Date (Datum).

De datum wordt gecodeeerd volgens de ISO-8601 standaard: yyyy-mm-dd. Bijvoorbeeld:

CODE
<bhrgtcom:analysisReportDate>2018-10-23</bhrgtcom:analysisReportDate>


7.6. DatumTijd

Diverse gegevenscatalogi definieren een aantal gegevens met als domein DatumTijd. In een XSD-bestand heeft het betreffende XML-element het type xs:DateTime (DatumTijd).

De datum en tijd worden gecodeeerd volgens de ISO-8601 standaard: yyyy-mm-ddThh:mm:ss+hh:mm.

Daarbij is de tijdzone (+hh:mm) verplicht. De tijdzone ten opzichte van UTC (aka GMT) zijn de uren en minuten na het plus teken. In theorie kan dit ook een min teken zijn (tijdzones ten westen van Greenwich), maar voor Nederland is de tijdzone + 1 uur (wintertijd) of + 2 uur (zomertijd).

Hieronder twee voorbeelden:

  • lokale tijd 08:14:38 tijdens wintertijd, terwijl het 'in Londen' 07:14:38 is (want de tijdzone van de lokale tijd is +1 uur ten opzichte van UTC aka GMT).

  • lokale tijd 13:52:44 tijdens zomertijd, terwijl het 'in Londen' 11:52:44 is (want de tijdzone van de lokale tijd is +2 uur ten opzichte van UTC aka GMT).


CODE
<wml2:time>2018-01-07T08:14:38+01:00</wml2:time>
<wml2:time>2018-07-18T13:52:44+02:00</wml2:time>


Zie ook de informatie op de pagina over het afhandelen van tijdstippen.

7.7. Dataleverancier

De diverse gegevenscatalogi definiëren het attribuut dataleverancier ( deliveryResponsibleParty). Dit attribuut wordt niet aangeleverd in een brondocument en ook niet als transactiegegeven in het omvattende request (BRO-verzoek).

Als dataleverancier hoeft u voor dit attribuut geen specifieke actie te ondernemen. Het bronhouderportaal zorgt er automatisch voor dat de waarde van dit attribuut wordt gemeld bij de LV-BRO.

Nadere informatie:
Zodra iemand een levering aanmaakt en de bijbehorende XML-bestanden uploadt, weet het bronhouderportaal op basis van de projectautorisatie of de projectmachtiging namens welke organisate deze persoon als dataleveracier optreedt. Als in een vervolgstap de levering wordt doorgeleverd, plaats de software van het bronhouderporaal het kvk-nummer van de dataleverancier in de SOAP header van het bericht dat naar de LV-BRO wordt gestuurd. Om dit mogelijk te maken bevat het WSDL-bestand van de innamewebservice van het betreffende registratieobject een message part deliveryResponsiblePartyHeader (dataleverancier), wat bij de SOAP binding is opgenomen in de header van de input messages van alle operations. Zie bijvoorbeeld https://schema.broservices.nl/isgld-v1.0.wsdl

7.8. Gegevensgroeptype

In een gegevenscatalogus wordt een onderscheid gemaakt tussen objecttypes en gegevensgroeptypes. Bij de opstellen van de berichtdefinities worden deze stereotypes vertaald naar FeatureType en AttributeGroupType. Beide kunnen in software omgezet worden naar classes. Beide hebben als onderdelen attributeTypes (attribuutsoorten), attributeGroups (gegevensgroepen) of associations (relaties) naar andere Featuretypes (objecttypes). De verschillen zijn onder meer dat een Feature uniek identificeerbaar moet zijn en dat een AttributeGroup alleen bestaat bij de gratie van het Feature waarvan het, direct of indirect, een onderdeel is.

Zie paragraaf Property type pattern voor een beschrijving van de manier waarop een Featuretype (objecttype) wordt omgezet naar XSD-elementen en een voorbeeld van de XML-encoding.

Onderstaande voorbeeld toont het objecttype Grondwatermonitoringnet. Deze entiteit heeft 4 attributen, 2 gegevensgroepen en 1 associatie relatie (naar het objecttype Meetpunt). Ter illustratie is de structuur van het gegevensgroeptype Registratiegeschiedenis opgenomen in de figuur.

Conform de GML XML encoding rules (citaat uit paragraaf F.2.3.9 van OGC® document: OGC 07-036: "If the type of a property element is a simple type or the property type of GML data type, the property shall be mapped to a UML attribute with the corresponding type as the data type") leidt in een XSD-bestand ieder AttributeGroupType (gegevensgroeptype) tot:

  • Een complex type, wat de inhoud van het AttributeGroupType (gegevensgroeptype) definieert en wat in de XSD-bestanden gebruikt wordt als het type van een element dat de betreffende AttributeGroup (gegevensgroep) realiseert.

Onderstaand voorbeeld toont een stuk XML-bericht, dat past bij bovenstaande UML diagram. Merk op dat de registrationHistory (registratiegeschiedenis) als XML-element direct zijn onderdelen als kind-elementen heeft.

CODE
  ...
  <gmn:name>Provinciaal meetnet grondwater Groningen; Delfzijl</gmn:name>
  <gmn:deliveryContext codeSpace="urn:bro:gmn:DeliveryContext">kaderrichtlijnWater</gmn:deliveryContext>
  <gmn:monitoringPurpose codeSpace="urn:bro:gmn:MonitoringPurpose">strategischBeheerKwaliteitRegionaal</gmn:monitoringPurpose>
  <gmn:groundwaterAspect codeSpace="urn:bro:gmn:GroundwaterAspect">kwantiteit</gmn:groundwaterAspect>
  <gmn:monitoringNetHistory>
    ...
  </gmn:monitoringNetHistory>
  <gmn:registrationHistory>
    <brocom:objectRegistrationTime>2021-03-07T13:11:57+01:00</brocom:objectRegistrationTime>
    <brocom:registrationStatus codeSpace="urn:bro:RegistrationStatus">voltooid</brocom:registrationStatus>
    <brocom:latestAdditionTime>2021-12-03T13:11:57+01:00</brocom:latestAdditionTime>
    <brocom:registrationCompletionTime>2021-12-30T15:42:08+01:00</brocom:registrationCompletionTime>
    <brocom:corrected>nee</brocom:corrected>
    <brocom:underReview>nee</brocom:underReview>
    <brocom:deregistered>nee</brocom:deregistered>
    <brocom:reregistered>nee</brocom:reregistered>
  </gmn:registrationHistory>
  <!-- 1 or more repetitions: -->
  <gmn:measuringPoint>
    ...
  </gmn:measuringPoint>
...


7.9. gml:id

Zie de pagina gml:id

7.10. Lijngeometrie

Diverse gegevenscatalogi definieren een geometrie in de vorm van een lijn, zoals bijvoorbeeld de geometrie van een boortraject als onderdeel van een boorgat van een EPC Mijnbouwconstructie.

De OGC standaard voor GML definieert een lijn als een 1-dimensionele geometrie in een 2-dimensioneel vlak of in een 3-dimensionele ruimte. Een lijn is continue en doorsnijdt zichzelf niet.


Een lijn bestaat uit een of meer lijnsegmenten waarbij de lijnsegmenten verschillende interpolatiemethoden kunnen gebruiken. Lijnsegmenten zijn aan elkaar verbonden waarbij het eindpunt van elk segment, behalve de laatste, verbonden is aan het beginpunt van het volgende.

In het GML profiel dat gebruikt wordt binnen de BRO kan een lijnsegment een lijnstuk of een cirkelsegment zijn. Daarbij is de interpolatie tussen de punten van een lijnstuk altijd 'linear' (rechte lijnstukken) en is de interpolatie tussen de drie punten van een cirkelsegment altijd 'circularArc3Points' (cirkelvormige boog die begint bij het eerste punt, door het tweede punt gaat en eindigt bij het derde punt).

De punten van de lijnsegmenten en/of cirkelsegmenten worden uitgedrukt in een referentiestelsel. Een punt in een 2-dimensioneel vlak heeft twee coöridnaten en een punt in een 3-dimensionele ruimte heeft drie coördinaten. De betekenis en h et bereik van de coördinaten is afhankelijk van het gebruikte referentiestelsel. Tenzij anders aangegeven in de betreffende gegevenscatalogus, kunnen de referentiestelsels in de onderstaande tabel worden gebruikt. De tabel geeft ook de betekenis, volgorde en eenheid van de coördinaten en het toepassingsgebied van het referentiestelsel.

Referentiestelsel

srsName

Betekenis

Eenheid

Toepassingsgebied

RD (Rijksdriehoek)

urn:ogc:def:crs:EPSG:28992

X, Y (, H)

Meter

Land

WGS84

urn:ogc:def:crs:EPSG:4326

Latitude, Longitude(, hoogte) (φ,λ(,h))

Graden, decimaal (meter)

Zee

ETRS89

urn:ogc:def:crs:EPSG:4258

Latitude, Longitude(, hoogte) (φ,λ(,h))

Graden, decimaal (meter)

Land en zee


Conform NEN3610 wordt op technisch niveau een lijngeometrie in UML gemodelleerd als een GM_Curve. Conform de GML XML encoding rules wordt bij een gm_Curve het property type pattern toegepast, zodat een betreffend attribuut het type gml:CurvePropertyType krijgt. Zie ook de paragraaf Property type pattern. Daardoor krijgt in een XSD-bestand het betreffende XML-element een type gml:PointPropertyType. Dit leidt in een XML-bestand tot:

  • een XML-attribuut gml:id - een unieke identificatie van de geometrie.

  • een XML-attribuut srsName - een verwijzing naar het referentiestelsel waarin de coördinaten zijn uitgedrukt.

  • een XML-element gml:pos - de coördinaten van de puntgeometrie.

Als voorbeeld de onderstaande lijn, die bestaat uit 3 lijnstukken en 1 cirkelsegment.


Hieronder volgt de XML-code bevat voor deze geometrie in RD en in ETRS89. Merk op dat de coördinaten worden gescheiden door een spatie en dat het decimale scheidingsteken een punt is.

CODE
... 
<epccom:geometry>
  <gml:Curve gml:id="id_0006" srsDimension="3" srsName="EPSG:28992">
    <gml:segments>
      <gml:LineStringSegment interpolation="linear">
        <gml:posList>
          193050 320700 86.55
          193050 320700 -14.73
          193052 320705 -264.18
          193049 320702 -516.51
        </gml:posList>
      </gml:LineStringSegment>
      <gml:ArcString interpolation="circularArc3Points" numArc="1">
        <gml:posList>
          193049 320702 -516.51
          193051 320703 -674
          193048 320701 -972
        </gml:posList>
      </gml:ArcString>
    </gml:segments>
  </gml:Curve>
</epccom:geometry>
...
<epccom:geometry>
  <gml:Curve gml:id="id_0006" srsDimension="3" srsName="EPSG:4258">
    <gml:segments>
      <gml:LineStringSegment interpolation="linear">
        <gml:posList>
          50.8748397 5.9277708 129.55
          50.8748397 5.9277708 29.73
          50.8748844 5.9277996 -221.18
          50.8748577 5.9277567 -473.51
        </gml:posList>
      </gml:LineStringSegment>
      <gml:ArcString interpolation="circularArc3Points" numArc="1">
        <gml:posList>
          50.8748577 5.9277567 -473.51
          50.8748665 5.9277852 -631
          50.8748487 5.9277424 -929
        </gml:posList>
      </gml:ArcString>
    </gml:segments>
  </gml:Curve>
</epccom:geometry>
...


7.11. Meetreeks

Zie de pagina Meetreeks

7.12. Meetwaarde

Diverse gegevenscatalogi definieren een aantal gegevens met als domein een meetwaarde. Dit domein bestaat uit een getalswaarde en een eenheid. Bijvoorbeeld 123,321 meter.

In een XSD-bestand heeft het betreffende XML-element het type gml:Measure. Conform de GML XML encoding rules wordt de eenheid opgeslagen in het XML-attribuut uom (unit of measure; eenheid) en wordt de getalswaarde opgenomen als de waarde van het XML-element.

Als een gegeven van het type meetwaarde geen waarde heeft, dan wordt er een XML-attribuut xsi:Nil="true" opgenomen en heeft het XML-element geen waarde. Het XML attribuut uom (eenheid) wordt wel opgenomen.

Zie onderstaande voorbeelden voor een XML-element met de naam offset (verschuiving) met en zonder een waarde.

CODE
...
<bhrgtcom:offset uom="m">123.321</bhrgtcom:offset>
...
<bhrgtcom:offset uom="m" xsi:nil="true"/>
...


Merk op dat in de gegevenscatalogus (in de meeste gevallen) naast de afkorting ook tussen haakjes de voluitgeschreven naam van de eenheid is opgenomen, bijvoorbeeld: Eenheid: m (meter) . Alleen de afkorting volgens de UCUM lijst moet worden opgenomen in het BRO-verzoek (zie https://ucum.org/ucum.html).

7.13. Organisatie

Diverse gegevenscatalogi definieren een aantal gegevens met als domein een Organisatie.

Het domein Organisatie biedt de keuze tussen een kamer van koophandel nummer of een Europees handelsnummer als identificatie van een organisatie. In de XSD-bestanden leidt deze keuze tot een xs:choice.

Conform de GML XML encoding rules wordt bij een xs:choice het property type pattern toegepast. Zie ook de paragraaf Property type pattern. Daardoor krijgt een XML-element, waarvan het type een Organization (Organisatie) is, een kind-element met als tag de gekozen variant. Daardoor weet de ontvangende partij wat de betekenis van de waarde is. In onderstaande voorbeelden is 09098104 een kamer van koophandel nummer en is DER2507_R2 een Europees handelsnummer.

Hieronder twee voorbeelden :

CODE
...
<bhrgtcom:descriptionOperator>
  <brocom:chamberOfCommerceNumber>09098104</brocom:chamberOfCommerceNumber>
</bhrgtcom:descriptionOperator>
...
<bhrgtcom:descriptionOperator>
  <brocom:europeanCompanyRegistrationNumber>DER2507_R2</brocom:europeanCompanyRegistrationNumber>
</bhrgtcom:descriptionOperator>
...


7.14. PartialDate

Diverse gegevenscatalogi definieren een aantal gegevens met als domein een Datum (zie ook de paragraaf Datum) onder het kwaliteitsregime IMBRO en een OnvolledigeDatum onder IMBRO/A.

In de XSD-bestanden is de OnvolledigeDatum gerealiseerd door het complexType PartialDateType, wat een xs:choice is van 4 mogelijkheden met afnemende nauwkeurigheid:

  • date (volledige datum)

  • yearMonth (datum en jaartal)

  • year (jaartal)

  • voidReason (de vaste waarde 'onbekend').

Conform de GML XML encoding rules wordt bij een xs:choice het property type pattern toegepast. Zie ook de paragraaf Property type pattern. Daardoor krijgt een XML-element met een PartialDateType (OnvolledigeDatum) als type een kind-element met als tag de gekozen variant. Daardoor weet de ontvangende partij wat de betekenis van de waarde is.

Hieronder vier voorbeelden:

CODE
<bhrgtcom:descriptionReportDate>
  <brocom:date>2018-09-23</brocom:date>
</bhrgtcom:descriptionReportDate>
...
<bhrgtcom:descriptionReportDate>
  <brocom:yearMonth>2018-09</brocom:yearMonth>
</bhrgtcom:descriptionReportDate>
...
<bhrgtcom:descriptionReportDate>
  <brocom:year>2018</brocom:year>
</bhrgtcom:descriptionReportDate>
...
<bhrgtcom:descriptionReportDate>
  <brocom:voidReason>onbekend</brocom:voidReason>
</bhrgtcom:descriptionReportDate>


Bij een PartialDate (OnvolledigeDatum) geldt dat een minder volledige datum voorafgaat aan een meer volledige datum:

  • het jaartal 2015 gaat voor de datum en jaartal juli 2015

  • de datum en jaartal juli 2015 gaat voor de volledige datum 17 juli 2015.

In het algemeen kan een datum met de waarde 'onbekend' niet worden vergeleken met een andere datum. Daarom wordt tijdens het valideren of verwerken van een BRO-verzoek een bedrijfsregel genegeerd, als er twee datums met elkaar worden vergeleken waarvan één (of beide) de waarde 'onbekend' heeft.

Uitzondering is het sorteren van gebeurtenissen op een tijdlijn. Daarbij wordt op basis van de betekenis van de gebeurtenis een begin/inrichten/start gebeurtenis altijd vooraan in de lijst met gebeurtenissen geplaatst, ook als de datum van de gebeurtenis de waarde 'onbekend' heeft. En wordt een eind/opruimen/voltooien gebeurtenis altijd achteraan in de lijst met gebeurtenissen geplaatst, ook als de datum van de gebeurtenis de waarde 'onbekend' heeft. Opdat een lijst met gebeurtenissen eenduidig kan worden gesorteerd, mag bij andere gebeurtenissen, tenzij anders aangegeven, de datum van de gebeurtenis niet de waarde 'onbekend' hebben. Dit wordt expliciet als aanvullende regel vermeld bij de brondocumenten in de berichtencatalogus van het betreffende registratieobject.

7.15. Property type pattern

In een gegevenscatalogus wordt een onderscheid gemaakt tussen objecttypes en gegevensgroeptypes. Bij de opstellen van de berichtdefinities worden deze stereotypes vertaald naar FeatureType en AttributeGroupType. Beide kunnen in software omgezet worden naar classes. Beide hebben als eigenschappen attributeTypes (attribuutsoorten), attributeGroups (gegevensgroepen) of associations (relaties) naar andere Featuretypes (objecttypes). De verschillen zijn onder meer dat een Feature uniek identificeerbaar moet zijn en dat een AttributeGroup alleen bestaat bij de gratie van het Feature waarvan het, direct of indirect, een onderdeel is.

Zie paragraaf Gegevensgroeptype voor een beschrijving van de manier waarop een AttributeGroupType (gegevensgroeptype) wordt omgezet naar XSD-elementen en een voorbeeld van de XML-encoding.

Onderstaande voorbeeld toont het objecttype Grondwatermonitoringnet. Deze entiteit heeft 4 attributen, 2 gegevensgroepen en 1 associatie relatie (naar het objecttype Meetpunt). Ter illustratie is de structuur van het gegevensgroeptype Registratiegeschiedenis opgenomen in de figuur.

Conform de GML XML encoding rules (citaat uit paragraaf F.2.3.9 van OGC® document: OGC 07-036: "If the type of a property element is a property type of a GML object type (inline and/or by-reference), the property shall be mapped to a UML association role of a UML association to the class representing the target GML object type") leidt in een XSD-bestand ieder FeatureType (objecttype) tot:

  • Een complex type, wat de inhoud van het FeatureType (objecttype) definieert en direct of indirect een specialisatie is van gml:AbstractFeatureType.

  • Een root element, zodat objecten van het ComplexType geïnstantieerd kunnen worden.

  • Een property type ComplexType, wat in de XSD-bestanden gebruikt wordt als het type van een element dat de associatie relatie naar het FeatureType (objecttype) realiseert. Het property type ComplexType biedt de opties om het gerelateerde feature (object) inline dan wel by-reference op te nemen.

Als in een XML-document de relatie naar het feature (object) inline wordt opgenomen, dan krijgt het XML-element dat de relatie realiseert:

  • een kind-element,

    • met als tag de naam van het gerelateerde FeatureType (objecttype),

    • en een XML-attribuut gml:id (zie ook de paragraaf gml:id) met daarin de unique identificatie van het gerelateerde feature (object),

  • met daarin de eigenschappen (attribuutsoorten, gegevensgroepen en/of relaties) van het gerelateerde Feature (object). 

Door deze constructie weet een ontvangend systeem eenduidig wat het objecttype van het eindpunt van de relatie is en weet het hoe de inhoud geparsed moet worden.

Als in een XML-document de relatie naar het feature (object) by-reference wordt opgenomen, dan heeft het XML-element dat de relatie realiseert geen waarde, alleen een xlink:href XML-attribuut met daarin de unique identificatie van het gerelateerde feature (object).

Onderstaand voorbeeld toont een stuk XML-bericht, dat past bij bovenstaande UML diagram. Merk op dat het eerste measuringPoint (meetpunt) inline is opgenomen, met als XML-element eerst een MeasuringPoint (Meetpunt) als kind-element heeft, met gml:id als XML-attribuut voor de unieke identificatie, met daarbinnen de onderdelen van het MeasuringPoint (Meetpunt) als kleinkind-elementen. Merk op dat het tweede measuringPoint (meetpunt) by-reference is opgenomen, met alleen een xlink:href XML-attribuut.

CODE
...
<gmn:name>Provinciaal meetnet grondwater Groningen; Delfzijl</gmn:name>
<gmn:deliveryContext codeSpace="urn:bro:gmn:DeliveryContext">kaderrichtlijnWater</gmn:deliveryContext>
<gmn:monitoringPurpose codeSpace="urn:bro:gmn:MonitoringPurpose">strategischBeheerKwaliteitRegionaal</gmn:monitoringPurpose>
<gmn:groundwaterAspect codeSpace="urn:bro:gmn:GroundwaterAspect">kwantiteit</gmn:groundwaterAspect>
<gmn:monitoringNetHistory>
  ...
</gmn:monitoringNetHistory>
<gmn:registrationHistory>
  ...
</gmn:registrationHistory>
<!-- 1 or more repetitions: -->
<gmn:measuringPoint>
  <gmn:MeasuringPoint gml:id="SEQ_0002">
    <gmn:measuringPointCode>GMW07F000001</gmn:measuringPointCode>  
  </gmn:MeasuringPoint>
</gmn:measuringPoint>
<gmn:measuringPoint xlink:href="SEQ_0003"/>
...


7.16. Puntgeometrie

Diverse gegevenscatalogi definieren een locatie of geometrie, zoals bij de DeliveredLocation (Aangeleverde locatie) of de StandardizedLocation (Gestandaardiseerde locatie).

Een puntgeometrie wordt daar gedefinieerd door de volgende twee attributen:

  • Coördinaten: de coördinaten van de puntgeometrie.

  • Referentiestelsel: het referentiestelsel van de aangeleverde coördinaten.

Conform NEN3610 wordt op technisch niveau een puntgeometrie omgezet in het UML datatype gml:Point. Conform de GML XML encoding rules wordt bij een gml:Point het property type pattern toegepast. Zie ook de paragraaf Property type pattern. Daardoor krijgt in een XSD-bestand het betreffende XML-element een type gml:PointPropertyType. Dit leidt in een XML-bestand tot:

  • een XML-attribuut gml:id - een unieke identificatie van de geometrie.

  • een XML-attribuut srsName - een verwijzing naar het referentiestelsel waarin de coördinaten zijn uitgedrukt.

  • een XML-element gml:pos - de coördinaten van de puntgeometrie.

Het bereik en de betekenis van de coördinaten is afhankelijk van het gebruikte referentiestelsel. Tenzij anders aangegeven in de betreffende gegevenscatalogus, kunnen de referentiestelsels in de onderstaande tabel worden gebruikt. De tabel geeft ook de betekenis, volgorde en eenheid van de coördinaten en het toepassingsgebied van het referentiestelsel.

Referentiestelsel

srsName

Betekenis

Eenheid

Toepassingsgebied

RD (Rijksdriehoek)

urn:ogc:def:crs:EPSG:28992

X, Y

Meter

Land

WGS94

urn:ogc:def:crs:EPSG:4326

Latitude, Longitude (φ,λ)

Graden, decimaal

Zee

ETRS89

urn:ogc:def:crs:EPSG:4258

Latitude, Longitude (φ,λ)

Graden, decimaal

Land en zee


Onderstaand voorbeeld bevat de XML-code voor dezelfde locatie in RD en in ETRS89. Merk op dat de coördinaten worden gescheiden door een spatie en dat het decimale scheidingsteken een punt is.

CODE
...
<bhrgtcom:location>
  <gml:Point gml:id="id_0003" srsName="urn:ogc:def:crs:EPSG::28992">
    <gml:pos>134750.000 477800.000</gml:pos>
  </gml:Point>
</bhrgtcom:location>
...
<bhrgtcom:location>
  <gml:Point gml:id="id_0003" srsName="urn:ogc:def:crs:EPSG::4258">
    <gml:pos>52.28782 5.09042</gml:pos>
  </gml:Point>
</bhrgtcom:location>
...


7.17. Vlakgeometrie

TODO

Diverse gegevenscatalogi definieren een locatie of geometrie, zoals bij de DeliveredLocation (Aangeleverde locatie) of de StandardizedLocation (Gestandaardiseerde locatie).

Een puntgeometrie wordt daar gedefinieerd door de volgende twee attributen:

  • Coördinaten: de coördinaten van de puntgeometrie.

  • Referentiestelsel: het referentiestelsel van de aangeleverde coördinaten.

Conform NEN3610 wordt op technisch niveau een puntgeometrie omgezet in het UML datatype gml:Point. Conform de GML XML encoding rules wordt bij een gml:Point het property type pattern toegepast. Zie ook de paragraaf Property type pattern. Daardoor krijgt in een XSD-bestand het betreffende XML-element een type gml:PointPropertyType. Dit leidt in een XML-bestand tot:

  • een XML-attribuut gml:id - een unieke identificatie van de geometrie.

  • een XML-attribuut srsName - een verwijzing naar het referentiestelsel waarin de coördinaten zijn uitgedrukt.

  • een XML-element gml:pos - de coördinaten van de puntgeometrie.

Het bereik en de betekenis van de coördinaten is afhankelijk van het gebruikte referentiestelsel. Tenzij anders aangegeven in de betreffende gegevenscatalogus, kunnen de referentiestelsels in de onderstaande tabel worden gebruikt. De tabel geeft ook de betekenis, volgorde en eenheid van de coördinaten en het toepassingsgebied van het referentiestelsel.

Referentiestelsel

srsName

Betekenis

Eenheid

Toepassingsgebied

RD (Rijksdriehoek)

urn:ogc:def:crs:EPSG:28992

X, Y

Meter

Land

WGS94

urn:ogc:def:crs:EPSG:4326

Latitude, Longitude (φ,λ)

Graden, decimaal

Zee

ETRS89

urn:ogc:def:crs:EPSG:4258

Latitude, Longitude (φ,λ)

Graden, decimaal

Land en zee


Onderstaand voorbeeld bevat de XML-code voor dezelfde locatie in RD en in ETRS89. Merk op dat de coördinaten worden gescheiden door een spatie en dat het decimale scheidingsteken een punt is.

CODE
...
<bhrgtcom:location>
  <gml:Point gml:id="id_0003" srsName="urn:ogc:def:crs:EPSG::28992">
    <gml:pos>134750.000 477800.000</gml:pos>
  </gml:Point>
</bhrgtcom:location>
...
<bhrgtcom:location>
  <gml:Point gml:id="id_0003" srsName="urn:ogc:def:crs:EPSG::4258">
    <gml:pos>52.28782 5.09042</gml:pos>
  </gml:Point>
</bhrgtcom:location>
...


8. Enumeraties

Dit hoofdstuk bevat een overzicht van enumeraties (niet beheerde waardenlijsten) met hun toegestane waarden.

In de BRO wordt een onderscheid gemaakt tussen beheerde waardenlijsten en niet-beheerde waardenlijsten:

  • In de gegevenscatalogus en de XSD-bestanden noemen we een niet-beheerde waardenlijst een enumeratie. Bij een enumeratie staat de lijst met toegestane waarden vast en kan de lijst met toegestane waarden niet veranderd worden zonder aanpassingen in de gegevenscatalogus, de berichtdefinities (XSD-bestanden) en de software (voor het maken of verwerken van een bericht).

  • In de gegevenscatalogus en de XSD-bestanden noemen we een beheerde waardenlijst een codelijst . Het domein van een codelijst is een uitbreidbare opsomming van toegestane waarden. Bij een codelijst wordt de lijst met toegestane waarden gepubliceerd, waarbij iedere codelijst een unieke identificatie heeft (de codeSpace). De lijst met toegestane waarden kan worden aangepast zonder dat aanpassingen nodig zijn in de berichtdefinities (XSD-bestanden) of de software (voor het maken of verwerken van een bericht). Om juridische redenen vormt de lijst met toegestane waarden een onderdeel van de gegevenscatalogus, zodat aanpassingen in de lijst met toegestane waarden leidt tot een nieuwe versie van de gegevenscatalogus.

De onderstaande tabel geeft een overzicht van de enumeraties die van belang kunnen zijn bij het maken van een BRO-verzoek. De eerste kolom bevat de Engelstalige naam van de enumeratie, zoals deze voorkomt in de XSD-bestanden. De tweede kolom bevat de Nederlandstalige naam, zoals die voorkomt in de gegevenscatalogus. De derde kolom bevat de toegestane waarden, die gebruikt mogen worden in een BRO-verzoek.

Type

Naam

Waarde

Omschrijving

DataToBeDelivered

Te leveren gegevens

actueel

Bij de uitgifte van gegevens van een object met materiële geschiedenis worden alleen de actuele gegevens uitgeleverd.



actueelHistorisch

Bij de uitgifte van gegevens van een object met materiële geschiedenis worden naast de actuele ook de historische gegevens uitgeleverd.

IndicationYesNo

IndicatieJaNee

ja




nee


IndicationYesNoUnknown

IndicatieJaNeeOnbekend

ja




nee




onbekend

Het is niet bekend of het gegeven de waarde ja of de waarde nee heeft.

QualityRegime

Kwaliteitsregime

IMBRO

Kwaliteitsregime waarbij de innamewebservice tijdens het verwerken van een innameverzoek de normale (strikte) regels hanteert, zoals gedefinieerd in de gegevenscatalogus.



IMBRO/A

Kwaliteitsregime waarbij de innamewebservice tijdens het verwerken van een innameverzoek andere (minder strenge) bedrijfsregels, toegestane waarden van codelijsten en/of domeinen van gegevens toepast dan onder het (normale) IMBRO kwaliteitsregime.


9. Doorkijkje naar de specifieke berichtencatalogi

Zoals het eerste hoofdstuk aangeeft, probeert deze handreiking in algemene zin een antwoord te geven op de volgende vragen:

  • Hoe kun je een BRO-verzoek als een XML-bestand opstellen?

  • Hoe ziet zo'n XML-bestand er uit?

  • Hoe moet je te werk gaan als de gegevens in één keer beschikbaar komen dan wel beetje bij beetje in de loop der tijd?

  • Hoe kunnen verandering van waarden in de loop der tijd gemeld kunnen worden?

  • Hoe kun je een fout in de geregistreerde gegevens corrigeren?

Paragraaf 1.4 bevat een tabel met links naar landingspagina's waar per registratieobjecttype specifieke informatie gevonden kan worden. De Berichtencatalogus innamewebservice van de betreffende registratieobjecttypes geven nadere informatie over de volgende onderwerpen:

  • Definitie van de brondocumenten, waarmee gegevens over het registratieobject aangeleverd of gecorrigeerd kunnen worden.

  • Scenario's waarin praktische reeksen van gebeurtenissen worden omgezet in aan te bieden brondocumenten en/of BRO-verzoeken.

  • Voorbeeldberichten en XML-code snippets die specifiek zijn voor het betreffende registratieobjecttype.

  • Indien relevant, een overzicht met enumeraties en hun toegestane waarden (niet-beheerde waardenlijsten).

  • Een overzicht met codelijsten (beheerde waardenlijsten).

  • Een vertaaltabel, waarmee de Engelstalige naam van een complextype of element, zoals gebruikt in de de XSD-bestanden, kan worden omgezet in de Nederlandse naam, zoals gebruikt in de gegevenscatalogus.

Daarmee geven deze drie documenten (Gegevenscatalogus, Handreiking aanleveren en Berichtencatalogus innamewebservice) u de noodzakelijke informatie om gegevens aan te leveren bij de BRO en indien nodig te corrigeren. Mochten er daarna nog vragen zijn, neem dan een kijke op de pagina Informatie voor softwareleveranciers of neem contacft op met de BRO servicedesk (zie paragraaf Contactinformatie).

De inhoud van dit document is met zorg opgesteld. Mocht u een fout aantreffen of een tekortkoming constateren, of anderszins feedback willen geven, neem dan contact op met de BRO servicedesk (zie paragraaf Contactinformatie).

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.