SLD 1.0 Berichtencatalogus innamewebservice

Dit document beschrijft het aanleveren van gegevens van een overheidsbesluit bodemverontreiniging (SLD). De inhoud zal definitief gemaakt worden nadat de SLD innameservices zijn gerealiseerd. De releasedatum volgt.

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). De datum van inwerkingtreding van BRO fase 2, en daarmee van het overheidsbesluit bodemverontreiniging (SLD), staat gepland voor 1-7-2025.

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.

In het document Handreiking aanleveren BRO-gegevens kan men algemene informatie inwinnen over:

• 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?

Blijft over de vraag: met welke brondocumenten kunnen gegevens over een overheidsbesluit bodemverontreiniging (SLD) aangeleverd of gecorrigeerd worden en welke andere SLD-specifieke informatie is er beschikbaar naast de algemene informatie in de Handreiking aanleveren BRO-gegevens?

1.2. Doelstelling

Dit document bevat SLD-specifieke informatie voor het aanleveren en corrigeren van gegevens over een overheidsbesluit bodemverontreiniging. Hierbij gaat het met name over:

• Welke SLD-specifieke brondocumenten zijn er als eenheid voor het aanleveren of corrigeren van gegevens?

• Welke combinaties van brondocument en type correctieverzoek zijn toegestaan?

• Welke SLD-specifieke aanvullende regels zijn er, naast de bedrijfsregels in de SLD-gegevenscatalogus en de algemene aanvullende regels in de Handreiking aanleveren BRO-gegevens?

• Welke SLD-specifieke codelijsten zijn er en waar kunnen hun toegestane waarden geraadpleegd worden?

• Welke rol speelt het SIKB0101 uitwisselformaat bij het aanleveren van SLD gegevens?

• Hoe wordt een SLD-brondocument met daarin een SIKB0101.xml omgezet naar een SLD-brondocument van het interne interface (mapping SIKB0101 naar SLD Catalogus)?

• Is er een tabel waarmee een Engelstalige naam in de XML-bestanden kan worden omgezet naar de Nederlandstalige naam in de gegevenscatalogus?

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 die gegevens over een overheidsbesluit bodemverontreiniging moeten aanleveren of hierover geregistreerde gegevens moeten corrigeren.

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 https://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 (https://www.bronhouderportaal-bro.nl/login), met rechtsonderaan een link naar de gebruikshandleiding (zie Handleiding bronhouderportaal).

3. Het derde niveau is de https://www.bro-productomgeving.nl/bpo/latest. Hier vindt u onder meer algemene informatie over het aanlever- en afnameproces, wijzigings- en versiebeheer en Q&A voor softwareleveranciers, maar ook specifieke informatie van de beschikbare types registratieobjecten zoals scopedocument, gegevenscatalogus en werkafspraken, storymap, berichtencatalogi voor inname en uitgifte, voorbeeldberichten voor inname en uitgifte.

Het verdient aanbeveling dat u zich eerst bekend maakt met de aangeven informatie uit de eerste 2 niveau's en het document Handreiking aanleveren BRO-gegevens in de BRO productomgeving.

Daarna kunt u zich verdiepen in de SLD-specifieke informatie in de BRO productomgeving, waaronder de SLD gegevenscatalogus en eventuele werkafspraken en in het bijzonder dit document, de SLD berichtencatalogus innamewebservice.

1.5. Leeswijzer

Hoofdstuk 2 bevat een beschrijving van de Brondocumenten, inclusief een overzicht met welke combinaties van brondocument en type correctieverzoek zijn toegestaan en de bijbehorende aanvullende regels.

Hoofdstuk 3 bevat toelichting over het gebruik van SIKB0101 voor aanlevering.

Hoofdstuk 4 beschrijft enkele integrale Voorbeeldberichten (XML-bestanden).

Hoofdstuk 5 bevat een Mappingtabel, die aangeeft hoe een attribuut met de Nederlandse naam in de SLD-gegevenscatalogus wordt gevuld met een Engelstalig element uit een IMSIKB0101 XSD- of XML-bestand.

Hoofdstuk 6 bevat een overzicht van de SLD-specifieke Codelijsten (beheerde waardelijsten) met de URN, zoals die in de SIKB0101 XML-bestanden gebruikt moeten worden, en een link naar de webpagina waar de lijst met toegestane waarden geraadpleegd kan worden.

Hoofdstuk 7 bevat een toelichting over de aanvullende regels bij aanleveren en hoe deze te valideren zijn met meegeleverde XSD en controle XSLT.

De bijlage in hoofdstuk 8 bevat een vertaaltabel, waarmee de Engelstalige naam van een onderdeel in de XSD- en XML-bestanden van het interne SLD-interface, dus na SIKB conversie, kan worden omgezet in de Nederlandstalige naam in de SLD-gegevenscatalogus.

De bijlage in Hoofdstuk 9 bevat een overzicht van de SLD-specifieke codelijsten (beheerde waardelijsten), zoals die worden gebruikt in de XSD- en XML-bestanden van het interne SLD interface, dus na SIKB Conversie., en een link naar de webpagina waar de lijst met toegestane waarden geraadpleegd kan worden.

1.6. Versiehistorie

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. Brondocumenten

Dit hoofdstuk definieert de brondocumenten voor het aanleveren van de registratie van een SLD. Dezelfde brondocumenten kunnen ook gebruikt worden om geregistreerde gegevens te corrigeren.

De entiteiten en attributen in dit document worden aangeduid met de Engelstalige namen, zoals die voorkomen in de XSD-bestanden (de formele berichtdefinities) en de XML-bestanden (met de BRO-verzoeken). Met behulp van de SLD Vertaaltabel kunnen deze worden omgezet in de Nederlandstalige namen in de SLD-gegevenscatalogus.

2.1. Scope

SLD betreft een Bodemlocatie onder de Wbb of een Aangepakt gebied onder de Ow.

2.2. Levensloop, materiële geschiedenis en tijdlijn.

Het registratieobjecttype overheidsbesluit bodemverontreiniging (SLD) kent zowel een levensloop als materiële geschiedenis, maar hanteert geen tijdlijn (zie Handreiking aanleveren BRO-gegevens):

• De levensloop van een object is een periode die wordt gemarkeerd door een begin en een eind. De registratie van gegevens over zo'n object is dus een proces dat zo lang duurt als het object bestaat.

• Tijdens deze periode kunnen gebeurtenissen optreden, naar aanleiding waarvan de in de LV-BRO geregistreerde gegevens moeten worden aangevuld (bijvoorbeeld een extra Besluit bij een Bodemlocatie) of naar aanleiding waarvan een geregistreerd gegeven een andere waarde krijgt (bijvoorbeeld de begrenzing van een Bodemlocatie, de vervolgactie Wbb van een Bodemlocatie of de einddatum van een Nazorggebied). Hierbij wordt dus materiële geschiedenis opgebouwd, oftewel het ontstaan van nieuwe gegevens of andere waarden voor gegevens naar aanleiding een gebeurtenis in de werkelijkheid.

• Bij het successievelijk aanbieden van gegevens wordt bij een SLD registratieobject geen tijdlijn gehanteerd. Dat wil zeggen, voor zover nieuwe gegevens of andere waarden van geregistreerde gegevens onstaan gekoppeld aan een bepaalde datum of een bepaald tijdstip, vindt er geen controle plaats dat deze in chronologische volgorde zijn aangeleverd.

2.3. Gebeurtenissen

Het registratieobjecttype overheidsbesluit bodemverontreiniging (SLD) kent diverse gebeurtenissen, die in de werkelijkheid kunnen optreden en die bij de registratie worden vastgelegd. De namen van de gebeurtenissen zijn gedefinieerd in de SLD gegevenscatalogus.

2.4. Overzicht brondocumenten

Naar aanleiding van een in de werkelijkheid opgetreden gebeurtenis worden de relevante gegevens aangeboden aan de BRO in de vorm van een brondocument verpakt in een registratieverzoek. Deze berichtencatalogus definieert de verzameling brondocumenten en beschrijft hun inhoud. De gegevens in het brondocument worden gedefinieerd in de SLD gegevenscatalogus.

Voor het aanbieden van (nieuwe of gecorrigeerde) gegevens kent de SLD-innameservice 4 types brondocumenten:

2.5. Operaties

Onderstaande tabel geeft per type brondocument weer in welke registratieverzoeken en correctieverzoeken (zie Handreiking aanleveren BRO-gegevens voor nadere details) het brondocument kan worden aangeboden.

Door een SLD_CompleteReport of SLD_StartReport brondocument aan te bieden in een registrationRequest (registratieverzoek) worden de aangeboden gegevens opgenomen in een nieuwe registratieobject. Met een SLD_NewDecision brondocument wordt de registratie van een bestaand registratieobject aangevuld met de aangeboden gegevens. Met een SLD_SoilLocationFinalisation brondocument wordt de registratie van een bestaand registratieobject afgesloten.

Fouten in de geregistreerde gegevens kunnen worden gecorrigeerd door hetzelfde brondocument na correctie aan te bieden in een replaceRequest (vervangverzoek), moveRequest (verplaatsverzoek) of deleteRequest (verwijderverzoek). Binnen SLD is het insertRequest (invoegverzoek) niet van toepassing; bij de registratie van opeenvolgende gebeurtenissen vindt er geen controle plaats dat deze in chronologische volgorde zijn aangeleverd.

Nadere details over de inhoud van de het registratieverzoek en de correctieverzoeken en wanneer welk type gebruikt mag worden staan nader toegelicht in de Handreiking aanleveren BRO-gegevens.

Een bestaand registratieobject kan niet worden verwijderd. Het kan alleen ‘uit registratie worden genomen’. Neem hiervoor contact op met de BRO Servicedesk via een mail naar support@broservicedesk.nl.

2.6. Inhoud brondocumenten

2.6.1. SLD_CompleteReport

Het brondocument SLD_CompleteReport (SLD-VolledigRapport) wordt gebruikt om een SLD in één keer volledig te registreren. Er is daarbij geen sprake van een gebeurtenis. Er wordt geen geschiedenis opgebouwd.

• Dit is altijd het geval bij een SLD onder het regime van de OW (gegevens die zijn ontstaan na 1-1-2024).

• Dit is tevens het geval bij SLD onder het regime van de Wbb als de gegevens zijn ontstaan voor 1-1-2024 en het dossier is afgerond en daarmee statisch is. In de regel is het dossier in dit geval in het kader van ‘warme overdracht’ overgedragen aan een nieuw bevoegd gezag.

Na verwerking van dit brondocument is de registratiestatus voltooid; het registratieobject kan niet worden aangevuld.

2.6.1.1. Inhoud

Onderstaande figuur geeft een overzicht van de inhoud van het brondocument SLD_CompleteReport.

De gegevens in de FeatureCollectionIMSIKB0101 zijn volledig gedefinieerd in de open datastandaard SIKB0101, te lezen in het Protocol-document en de Uitwisselmodel-documenten. De overige gegevens zijn volledig gedefinieerd in de SLD gegevenscatalogus.

De volgende gegevens staan niet in het brondocument maar worden als transactiegegeven aangeleverd in het BRO-verzoek:

• De deliveryAccountableParty (bronhouder) alleen als de bronhouder een ander is dan de dataleverancier;

• De deliveryResponsibleParty (dataleverancier);

• Het qualityRegime (kwaliteitsregime).

• De broId (BRO-ID). Bij een SLD_CompleteReport of SLD_StartReport brondocument in een registrationRequest (registratieverzoek) wordt de broId (BRO-ID) niet aangeleverd; de LV-BRO genereert een unieke waarde voor dit gegeven. Bij aanleveren van de andere SLD brondocumenten wordt de broId (BRO-ID) wel aangeleverd; het identificeert het registratieobject dat moet worden aangevuld of voltooid. Bij aanleveren van een brondocument in een correctieverzoek wordt de broId (BRO-ID) wel aangeleverd in het BRO-verzoek; het identificeert het registratieobject dat moet worden gecorrigeerd.

Het brondocument SLD_CompleteReport bevat daarnaast alle gegevens uit de SLD catalogus met uitzondering van de volgende gegevens:

2.6.1.2. Aanvullende regels

• Het brondocument mag worden aangeboden in een registrationRequest (registratieverzoek) of replaceRequest (vervangverzoek). Het brondocument mag niet worden aangeboden in een moveRequest (verplaatsverzoek), deleteRequest (verwijderverzoek) of insertRequest (invoegverzoek).

• De FeatureCollectionIMSIKB0101 moet een valide SIKB0101 versie 14.9.0 xml (of nieuwere versie 14.x) bevatten.

  • Zie de beschrijving van het SIKB0101 formaat voor meer informatië: https://www.sikb.nl/datastandaarden/sikb0101-bodembeheer  

  • Er is een Controle XSLT beschikbaar gesteld om de SIKB0101 versie 14.9.0 xml te kunnen valideren op de juiste aanwezigheid van de BRO SLD Subset in het SIKB0101 formaat.

• Iedere identification (SIKB0101-identificatie) mag slechts één keer in het brondocument voorkomen.

• Een RegistrationObject met de opgegeven broId moet aanwezig zijn in de registratie ondergrond als het brondocument wordt aangeboden in een correctieverzoek.

• Verder gelden de aanvullende regels zoals beschreven in de Handreiking aanleveren BRO-gegevens.

• Verder gelden de regels zoals beschreven in de SLD gegevenscatalogus. 

2.6.1.3. Af te leiden gegevens

De volgende gegevens worden afgeleid:

• Gegevensgroep RegistrationHistory (Registratiegeschiedenis).

  • De waarde van het attribuut registrationStatus (registratiestatus) krijgt de waarde voltooid als het brondocument wordt aangeboden in een registrationRequest (registrativerzoek). De waarde blijft ongewijzigd in alle andere gevallen.

• Gegevensgroep StandardizedLocation (Gestandaardiseerde locatie).

• Er wordt geen gegevensgroep LocationHistory (Locatie geschiedenis) afgeleid.

  • Het attribuut finalisationDate (afrondingsdatum) blijft afwezig.

  • Er wordt geen gegevensgroep Event (Gebeurtenis) afgeleid.

2.6.2. SLD_StartReport

Het brondocument SLD_StartReport (SLD-StartRapport) wordt gebruikt om de registratie van een nieuw SLD te starten. Dit kan alleen het geval zijn bij een SLD onder de Wbb.

Na verwerking van dit brondocument is de registratiestatus geregistreerd; het registratieobject kan niet worden aangevuld.

De status van dit registratieobject kan eigenlijk nooit voltooid worden, omdat de actuele status van de bodem altijd nog kan veranderen.

2.6.2.1. Inhoud

Onderstaande figuur geeft een overzicht van de inhoud van het brondocument SLD_StartReport.

De gegevens in de FeatureCollectionIMSIKB0101 zijn volledig gedefinieerd in de open datastandaard SIKB0101, te lezen in het Protocol-document en de Uitwisselmodel-documenten. De overige gegevens zijn volledig gedefinieerd in de SLD gegevenscatalogus.

De volgende gegevens staan niet in het brondocument maar worden als transactiegegeven aangeleverd in het BRO-verzoek:

• De deliveryAccountableParty (bronhouder) alleen als de bronhouder een ander is dan de dataleverancier;

• De deliveryResponsibleParty (dataleverancier);

• Het qualityRegime (kwaliteitsregime).

• De broId (BRO-ID). Bij een SLD_CompleteReport of SLD_StartReport brondocument in een registrationRequest (registratieverzoek) wordt de broId (BRO-ID) niet aangeleverd; de LV-BRO genereert een unieke waarde voor dit gegeven. Bij aanleveren van de andere SLD brondocumenten wordt de broId (BRO-ID) wel aangeleverd; het identificeert het registratieobject dat moet worden aangevuld of voltooid. Bij aanleveren van een brondocument in een correctieverzoek wordt de broId (BRO-ID) wel aangeleverd in het BRO-verzoek; het identificeert het registratieobject dat moet worden gecorrigeerd.

Het brondocument SLD_StartReport bevat alle gegevens uit de catalogus met uitzondering van de volgende gegevens:

N.B.: De keuze SoilLocationOrHandledArea (Bodemlocatie of Aangepakt gebied) is in het brondocument opgenomen, ondanks dat vooralsnog in dit brondocument SoilLocation (Bodemlocatie) de enige toegestane keuze is. Redenen hiervoor zijn: 1) consistentie met brondocument SLD_CompleteReport (SLD-VolledigRapport) en 2) de verwachting dat in de toekomst voor het opnemen van nazorg de keuze daadwerkelijk van toepassing zal worden.

2.6.2.2. Aanvullende regels

• Het brondocument mag worden aangeboden in een registrationRequest (registratieverzoek), replaceRequest (vervangverzoek) of moveRequest (verplaatsverzoek). Het brondocument mag niet worden aangeboden in een deleteRequest (verwijderverzoek) of insertRequest (invoegverzoek).

• De FeatureCollectionIMSIKB0101 moet een valide SIKB0101 versie 14.9.0 xml bevatten.

  • Zie de beschrijving van het SIKB0101 formaat voor meer informatië: https://www.sikb.nl/datastandaarden/sikb0101-bodembeheer  

  • Er is een Controle XSLT beschikbaar gesteld om de SIKB0101 versie 14.9.0 xml te kunnen valideren op de juiste aanwezigheid van de BRO SLD Subset in het SIKB0101 formaat.

• Iedere identification (SIKB0101-identificatie) mag slechts één keer in het brondocument voorkomen.

• Een RegistrationObject met de opgegeven broId moet aanwezig zijn in de registratie ondergrond als het brondocument wordt aangeboden in een correctieverzoek.

• De waarde van het attribuut deliveryContext (kader aanlevering) moet gelijk zijn aan WetBodembescherming. Met andere woorden, het overheidsbesluit bodemverontreiniging betreft altijd een Bodemlocatie.

• Verder gelden de aanvullende regels zoals beschreven in de Handreiking aanleveren BRO-gegevens.

• Verder gelden de regels zoals beschreven in de SLD gegevenscatalogus.

2.6.2.3. Af te leiden gegevens

De volgende gegevens worden afgeleid:

• Gegevensgroep RegistrationHistory (Registratiegeschiedenis).

  • De waarde van het attribuut registrationStatus (registratiestatus) krijgt de waarde geregistreerd als het brondocument wordt aangeboden in een registrationRequest (registrativerzoek). De waarde blijft ongewijzigd in alle andere gevallen.

• Gegevensgroep StandardizedLocation (Gestandaardiseerde locatie).

• Gegevensgroep LocationHistory (Locatie geschiedenis).

  • Het attribuut finalisationDate (afrondingsdatum) blijft afwezig.

  • Er wordt een eerste gegevensgroep Event (Gebeurtenis) toegevoegd als het brondocument wordt aangeboden in een registrationRequest (registratieverzoek).

    • De waarde van het attribuut name (naam) krijgt de waarde bodemlocatieGeregistreerd.

    • De waarde van het attribuut date (datum) krijgt als waarde de datum van het objectRegistrationTime (tijdstip registratie object) uit de gegevensgroep RegistrationHistory (Registratiegeschiedenis).

    • Het attribuut identificationDecision (identificatie besluit) blijft afwezig.

  • De gegevensgroep Event (Gebeurtenis) blijft ongewijzigd als het brondocument wordt aangeboden in een replaceRequest (vervangverzoek).

2.6.3. SLD_NewDecision

Het brondocument SLD_NewDecision (SLD-NieuwBesluit) wordt gebruikt om een nieuw besluit toe te voegen aan een bodemlocatie. Dit kan alleen het geval zijn bij een SLD onder de Wbb.

Na verwerking van dit brondocument is de registratiestatus aangevuld.

2.6.3.1. Inhoud

Wanneer na de eerste registratie (start registratie) een nieuw besluit is genomen in de aanpak van de bodemlocatie onder de Wbb, wordt met dit brondocument dat nieuwe besluit, met verwerking van bijbehorende gegevens, aan de bodemlocatie toegevoegd in de BRO. De bijbehorende gegevens betreffen één of meer van de volgende:

• wijziging van de begrenzing van de bodemlocatie;

• wijziging van de vervolgactie bij de bodemlocatie;

• toevoeging van één of meer nieuwe gebieden aan de bodemlocatie;

• invullen van de einddatum van één of meer verontreinigde gebieden bij de bodemlocatie;

• invullen van de einddatum van één of meer nazorggebieden bij de bodemlocatie.

N.B.: Indien een besluit is genomen op basis waarvan de bodemlocatie is afgerond en de registratie in de BRO voltooid moet worden, dan is aanvullend op dit brondocument de aanlevering van het brondocument SLD-AfrondingBodemlocatie vereist. Dit is een verantwoordelijkheid van de bronhouder - er is niets iets als een regel aan de kant van de BRO die bijv. o.b.v. de vervolgactie vaststelt dat er een vervolgbericht ontvangen moet worden.

Onderstaande figuur geeft een overzicht van de inhoud van het brondocument SLD_NewDecision.

De gegevens in de FeatureCollectionIMSIKB0101 zijn volledig gedefinieerd in de open datastandaard SIKB0101, te lezen in het Protocol-document en de Uitwisselmodel-documenten. De overige gegevens zijn volledig gedefinieerd in de SLD gegevenscatalogus. De FeatureCollectionIMSIKB0101 moet een valide SIKB0101 versie 14.9.0 xml (of nieuwere versie 14.x) bevatten. Zie de beschrijving van het SIKB0101 formaat voor meer informatië: https://www.sikb.nl/datastandaarden/sikb0101-bodembeheer. Er is een Controle XSLT beschikbaar gesteld om de SIKB0101 versie 14.9.0 xml te kunnen valideren op de juiste aanwezigheid van de BRO SLD Subset in het SIKB0101 formaat.

Op basis van het aangeleverde brondocument transformeert de convertor de gegevens naar de volgende structuur:

De volgende gegevens staan niet in het brondocument maar worden als transactiegegeven aangeleverd in het BRO-verzoek:

• De deliveryAccountableParty (bronhouder) alleen als de bronhouder een ander is dan de dataleverancier;

• De deliveryResponsibleParty (dataleverancier);

• Het qualityRegime (kwaliteitsregime).

• De broId (BRO-ID). Bij aanleveren van een SLD_NewDecision brondocument in een registrationRequest (registratieverzoek) wordt de broId (BRO-ID) wel aangeleverd in het BRO-verzoek; het identificeert het registratieobject dat moet worden aangevuld. Bij aanleveren van het brondocument in een correctieverzoek wordt de broId (BRO-ID) wel aangeleverd in het BRO-verzoek; het identificeert het registratieobject waarvan het brondocument moet worden gecorrigeerd.

De overige gegevens zijn volledig gedefinieerd in de SLD gegevenscatalogus.

Uit bovenstaande UML diagram moge duidelijkl zijn dat dit brondocumenten strengere eisen stelt met betrekking tot de aanwezigheid van attributen en relaties dan de gegevenscatalogus.

1. DecisionNewDecision (Besluit):

   1. De waarde van het attribuut identification (SIKB0101-identificatie) dient uniek te zijn.

   2. Attribuut decisionReference (besluitkenmerk) is verplicht.

   3. Attribuut decisionDate (datum besluit) is verplicht.

2. HandledAreaNewDecision (Aangepakt gebied):

   1. De waarde van het attribuut identification (SIKB0101-identificatie) dient uniek te zijn.

   2. Precies één attribuut referencedByDecision (relatie naar Besluit) is verplicht.

3. ContaminatedAreaNewDecision (Verontreinigd gebied):

   1. De waarde van het attribuut identification (SIKB0101-identificatie) dient uniek te zijn.

   2. Precies één attribuut referencedByDecision (relatie naar Besluit) is verplicht.

   3. Attribuut exceededClass (overschreden toetsingswaarde) is verplicht.

   4. Attribuut dateDecreed (datum vastgesteld) is verplicht.

4. AftercareAreaNewDecision (Nazorggebied):

   1. De waarde van het attribuut identification (SIKB0101-identificatie) dient uniek te zijn.

   2. Precies één attribuut referencedByDecision (relatie naar Besluit) is verplicht.

   3. Attribuut effectiveDate (datum inwerking) is verplicht.

2.6.3.2. Aanvullende regels

• Het brondocument mag worden aangeboden in een registrationRequest (registratieverzoek), replaceRequest (vervangverzoek), moveRequest (verplaatsverzoek) of deleteRequest (verwijderverzoek). Het brondocument mag niet worden aangeboden in een insertRequest (invoegverzoek).

• De eventDate (datum gebeurtenis) mag niet liggen voor de date (datum) van de meest recente Event (Gebeurtenis) in de LocationHistory (Locatiegeschiedenis) van het registratieobject.

• Iedere identification (SIKB0101-identificatie) mag slechts één keer voorkomen in de combinatie van het brondocument en het registratieobject.

• In het registratieobject moet een ContaminatedArea (Verontreinigd gebied) aanwezig zijn waarvan de waarde van het attribuut identification (SIKB0101-identificatie) gelijk is aan de waarde van het attribuut identification (SIKB0101-identificatie) van een FinishedContaminatedArea (Beeindigd verontreinigd gebied) in het brondocument.

• Het attribuut endDate (einddatum) mag niet aanwezig zijn bij het ContaminatedArea (Verontreinigd gebied) in het registratieobject waarvan de waarde van het attribuut identification (SIKB0101-identificatie) gelijk is aan de waarde van het attribuut identification (SIKB0101-identificatie) van een FinishedContaminatedArea (Beeindigd verontreinigd gebied) in het brondocument.

• In het registratieobject moet een AftercareArea (Nazorggebied) aanwezig zijn waarvan de waarde van het attribuut identification (SIKB0101-identificatie) gelijk is aan de waarde van het attribuut identification (SIKB0101-identificatie) van een FinishedAftercareArea (Beeindigd nazorggebied) in het brondocument.

• Het attribuut endDate (einddatum) mag niet aanwezig zijn bij het AftercareArea (Nazorggebied) in het registratieobject waarvan de waarde van het attribuut identification (SIKB0101-identificatie) gelijk is aan de waarde van het attribuut identification (SIKB0101-identificatie) van een FinishedAftercareArea (Beeindigd nazorggebied) in het brondocument.

• Verder gelden de aanvullende regels zoals beschreven in de Handreiking aanleveren BRO-gegevens.

• Verder gelden de regels zoals beschreven in de SLD gegevenscatalogus.

2.6.3.3. Af te leiden gegevens

De volgende gegevens worden afgeleid:

• De gegevens in het brondocument worden één op één overgenomen in de registratie ondergrond, uitgezonderd de attributen SoilLocation (Bodemlocatie) en followUp (vervolgactie) van de entiteit SoilLocationNewDecision (Bodemlocatie nieuw besluit), FinishedContaminatedArea (Beeindigd verontreinigd gebied) en FinishedAftercareArea (Beeindigd nazorggebied); zie hieronder.

  • Bij de entiteit SoilLocation (Bodemlocatie) wordt de geregistreerde waarde van het attribuut boundary (begrenzing) vervangen door de waarde van het attribuut in het brondocument indien het attribuut aanwezig is in het brondocument. Als het attribuut niet aanwezig is in het brondocument blijft de geregistreerde waarde ongewijzigd.

  • Bij de entiteit SoilLocation (Bodemlocatie) wordt de geregistreerde waarde van het attribuut followUp (vervolgactie) vervangen door de waarde van het attribuut in het brondocument indien het attribuut aanwezig is in het brondocument. Als het attribuut niet aanwezig is in het brondocument blijft de geregistreerde waarde ongewijzigd.

  • Bij de entiteit ContaminatedArea (Verontreinigd gebied) waarvan de waarde van het attribuut identification (SIKB0101-identificatie) overeenkomt met de waarde van het attribuut identification (SIKB0101-identificatie) van een FinishedContaminatedArea (Beeindigd verontreinigd gebied) in het brondocument:

    • krijgt het attribuut endDate (einddatum) de waarde van het attribuut endDate (einddatum) in het brondocument.

    • wordt een relatie referencedByDecision (is vermeld in Besluit) toegevoegd overeenkomstig het attribuut referencedByDecision (is vermeld in Besluit) in het brondocument.

  • Bij de entiteit AftercareArea (Nazorggebied) waarvan de waarde van het attribuut identification (SIKB0101-identificatie) overeenkomt met de waarde van het attribuut identification (SIKB0101-identificatie) van een FinishedAftercareArea (Beeindigd nazorggebied) in het brondocument:

    • krijgt het attribuut endDate (einddatum) de waarde van het attribuut endDate (einddatum) in het brondocument.

    • wordt een relatie referencedByDecision (is vermeld in Besluit) toegevoegd overeenkomstig het attribuut referencedByDecision (is vermeld in Besluit) in het brondocument.

• Gegevensgroep RegistrationHistory (Registratiegeschiedenis).

  • De waarde van het attribuut registrationStatus (registratiestatus) krijgt de waarde aangevuld als het brondocument wordt aangeboden in een registrationRequest (registrativerzoek). De waarde blijft ongewijzigd in alle andere gevallen.

• Gegevensgroep StandardizedLocation (Gestandaardiseerde locatie) wordt opnieuw afgeleid als het attribuut boundary (begrenzing) aanwezig is in de SoilLocationNewDecision (Bodemlocatie) in het brondocument.

• Gegevensgroep LocationHistory (Locatie geschiedenis).

  • Het attribuut finalisationDate (afrondingsdatum) blijft afwezig.

  • Er wordt een nieuwe gegevensgroep Event (Gebeurtenis) toegevoegd als het brondocument wordt aangeboden in een registrationRequest (registrativerzoek):

    • De waarde van het attribuut name (naam) krijgt de waarde nieuwBesluitBekendgemaakt.

    • De waarde van het attribuut date (datum) wordt afgeleid van het attribuut eventDate (datum gebeurtenis) in het brondocument.

    • De waarde van het attribuut identificationDecision (identificatie besluit) wordt afgeleid van het attribuut identification (SIKB0101-identificatie) van het DecisionNewDecision (Besluit) in het brondocument.

  • De gegevensgroep Event (Gebeurtenis) blijft ongewijzigd als het brondocument wordt aangeboden in een replaceRequest (vervangverzoek).

  • Het attribuut date (datum) wordt opnieuw afgeleid als het brondocument wordt aangeboden in een moveRequest (verplaatsverzoek).

  • De gegevensgroep Event (Gebeurtenis) in de registratie wordt verwijderd als het brondocument wordt aangeboden in een deleteRequest (verwjiderverzoek).

2.6.4. SLD_SoilLocation-Finalisation

Het brondocument SLD_SoilLocationFinalisation (SLD-Afronding-Bodemlocatie) wordt gebruikt om de bodemlocatie af te ronden. Dit kan alleen het geval zijn bij een SLD onder de Wbb.

Na verwerking van dit brondocument is de registratiestatus voltooid.

2.6.4.1. Inhoud

Onderstaande figuur geeft een overzicht van de inhoud van het brondocument SLD_SoilLocationFinalisation.

2.6.4.2. Aanvullende regels

• Het brondocument mag worden aangeboden in een registrationRequest (registratieverzoek), moveRequest (verplaatsverzoek) of deleteRequest (verwijderverzoek). Het brondocument mag niet worden aangeboden in een replaceRequest (vervangverzoek) of insertRequest (invoegverzoek).

• De eventDate (datum gebeurtenis) mag niet liggen voor de date (datum) van de meest recente Event (Gebeurtenis) in de LocationHistory (Locatiegeschiedenis) van het registratieobject.

• Verder gelden de aanvullende regels zoals beschreven in de Handreiking aanleveren BRO-gegevens.

• Verder gelden de regels zoals beschreven in de SLD gegevenscatalogus.

Voor het afronden van een bodemlocatie is géén regel gesteld m.b.t. de aanwezigheid van een einddatum bij Verontreinigde gebieden en Nazorggebieden. Noch voor gebieden die in de archiefoverdracht zijn aangeleverd, noch voor gebieden die met een SLD-NieuwBesluit zijn geregistreerd, is deze wens door bronhouders of afnemers geuit.

2.6.4.3. Af te leiden gegevens

De volgende gegevens worden afgeleid:

• Gegevensgroep RegistrationHistory (Registratiegeschiedenis).

  • De waarde van het attribuut registrationStatus (registratiestatus):

    • krijgt de waarde voltooid als het brondocument wordt aangeboden in een registrationRequest (registrativerzoek).

    • krijgt de waarde geregistreerd als het brondocument wordt aangeboden in een deleteRequest (verwijderverzoek) en de lijst met Events (Gebeurternissen) in de LocationHistory (Locatiegeschiedenis) leeg is.

    • krijgt de waarde aangevuld als het brondocument wordt aangeboden in een deleteRequest (verwijderverzoek) en de lijst met Events (Gebeurternissen) in de LocationHistory (Locatiegeschiedenis) niet leeg is.

    • blijft ongewijzigd in alle andere gevallen.

• Gegevensgroep LocationHistory (Locatie geschiedenis).

  • Het attribuut finalisationDate (afrondingsdatum) krijgt de waarde van het attribuut eventDate (datum gebeurtenis) in het brondocument.

  • Er wordt een nieuwe gegevensgroep Event (Gebeurtenis) toegevoegd als het brondocument wordt aangeboden in een registrationRequest (registrativerzoek)

    • Het attribuut name (naam) krijgt de waarde bodemlocatieAfgerond.

    • Het attribuut date (datum) krijgt de waarde van het attribuut eventDate (datum gebeurtenis) in het brondocument.

    • Het attribuut identificationDecision (identificatie besluit) blijft afwezig.

  • Het attribuut date (datum) wordt opnieuw afgeleid als het brondocument wordt aangeboden in een moveRequest (verplaatsverzoek).

  • De gegevensgroep Event (Gebeurtenis) in de registratie wordt verwijderd als het brondocument wordt aangeboden in een deleteRequest (verwjiderverzoek).

3. SIKB0101 bestand als brondocument

De aanlevering van gegevens over een overheidsbesluit bodemverontreiniging (SLD) gaat middels de 'Pas toe of leg uit standaard' SIKB0101 uitwisselprotocol: IMSIKB0101 versie 14.9.0. Deze digitale uitwisselstandaard wordt al meer dan 10 jaar succesvol toegepast in de keten voor de kwaliteitsborging bodembeheer. Voor meer informatie over dit protocol wordt verwezen website van het SIKB.

Belangrijke richtlijnen en technische documentatie van de uitwisselstandaard IMSIKB0101 zijn te vinden op deze plek: https://www.sikb.nl/datastandaarden/richtlijnen/sikb0101
In het te downloaden Protocol document ('Protocol SIKB0101 (inclusief IM Metingen)') staan aanvullende afspraken voor de technische implementatie van de standaard. Neem deze goed door. 

Zoals beschreven in het vorige hoofdstuk en toegelicht in het volgende hoofdstuk, wordt een featureCollection, die voldoet aan de IMSIKB0101 standaard, opgenomen in een BRO brondocument, wat vervolgens, zoals beschreven in het vorige hoofdstuk en de Handreiking aanleveren BRO-gegevens, wordt opgenomen in een BRO-verzoek. Het BRO verzoek kan vervolgens worden aangeboden bij het BRO bonhouderportaal.

4. Voorbeeldberichten

4.1. Scenario’s

Voor het aanbieden van gegevens is de volgende limitatieve lijst van scenario’s mogelijk. Per object (overheidsbesluit bodemverontreiniging aka dossier) moet een keuze uit een van deze scenario’s worden gemaakt. De vet gemarkeerde tekst kan dienen als richtlijnen bij het bepalen van de keuze.

1. Gegevens ontstaan onder de Ow (na 1-1-2024):

   1. Brondocument SLD_CompleteReport

   2. DeliveryContext (Kader aanlevering) = Omgevingswet

   3. QualityRegime (kwaliteitsregime) = IMBRO

2. Gegevens ontstaan onder de Wbb (voor 1-1-2024) in een op het moment van eerste aanlevering afgerond en daarmee statisch dossier:

   1. Brondocument SLD_CompleteReport

   2. DeliveryContext (Kader aanlevering) = WetBodembescherming

   3. QualityRegime (kwaliteitsregime) = IMBRO/A

3. Gegevens ontstaan onder de Wbb (voor 1-1-2024) in een lopend dossier waarbij in het kader van het overgangsrecht onder het regime Wbb aanvullende besluiten zijn of kunnen worden genomen:

   1. Gegevens die beschikbaar zijn op het moment van eerste aanlevering:

      1. Brondocument SLD_StartReport

      2. DeliveryContext (Kader aanlevering) = WetBodembescherming

      3. QualityRegime (kwaliteitsregime) = IMBRO/A

   2. Gegevens ontstaan naar aanleiding van een besluit genomen in het kader van het overgangsrecht onder het regime Wbb na aanlevering van het SLD_StartReport :

      1. Brondocument SLD_NewDecision

      2. QualityRegime (kwaliteitsregime) = IMBRO/A

   3. Afronden van de registratie van een dossier:

      1. Brondocument SLD_SoilLocationFinalisation

      2. QualityRegime (kwaliteitsregime) = IMBRO/A

Onderstaande figuur geeft een grafische weergave van bovenstaande scenario's.

Het is onvermijdelijk dat er fouten in de gegevens worden geconstateerd nadat deze zijn aangeleverd bij de LV-BRO. Omdat SLD een registratieobject is dat materiële geschiedenis kent (zie paragraaf 2.2. van hoofdstuk 2), zijn er verschillende operaties nodig voor het corrigeren van gegevens. Welke dat zijn is samengevat in paragraaf 2.5 van hoofdstuk 2 en welke operatie wanneer gebruikt moet worden staat beschreven in de Handreiking aanleveren BRO-gegevens.

4.2. Integrale XML-voorbeeldberichten

Integrale voorbeeldberichten, die aansluiten op de in de voorgaande paragraaf beschreven scenario’s, zijn te vinden via de link op de pagina Overheidsbesluit bodemverontreiniging (SLD) van de BRO productomgeving.

• Scenario 1:

  • 01_registrationRequest_SLD_CompleteReport_IMBRO_OW.xml

    • Registreren van gegevens ontstaan onder de Ow (na 1-1-2024).

  • 01_replaceRequest_SLD_CompleteReport_IMBRO_OW.xml

    • Corrigeren van gegevens in het voorgaande bericht.

• Scenario 2:

  • 02_registrationRequest_SLD_CompleteReport_IMBROA_WBB.xml

    • Registreren van gegevens ontstaan onder de Wbb (voor 1-1-2024) in een op het moment van eerste aanlevering afgerond en daarmee statisch dossier.

  • 02_replaceRequest_SLD_CompleteReport_IMBROA_WBB.xml

    • Corrigeren van gegevens in het voorgaande bericht.

• Scenario 3:

  • 03a_registrationRequest_SLD_StartReport_IMBROA_WBB.xml

    • Registreren van gegevens ontstaan onder de Wbb (voor 1-1-2024) in een lopend dossier die beschikbaar zijn op het moment van eerste aanlevering..

  • 03b_registrationRequest_SLD_NewDecision_IMBROA_WBB.xml

    • Aanvullen van de in het voorgaande bericht gestarte registratie met gegevens die zijn ontstaan naar aanleiding van een besluit genomen in het kader van het overgangsrecht onder het regime Wbb na aanlevering van het SLD_StartReport

  • 03c_registrationRequest_SLD_SoillLocationClosure_IMBROA_WBB.xml

    • Afronden van de in stap 3a gestarte en eventueel een of meerdere keren met stap 3b aangevulde registratie, omdat het dossier is gesloten.

  • 03d_replaceRequest_SLD_StartReport_IMBROA_WBB.xml

    • Corrigeren van gegevens die met stap 3a zijn aangeleverd.

  • 03e_replaceRequest_SLD_NewDecision_IMBROA_WBB.xml

    • Corrigeren van gegevens die met stap 3b zijn aangeleverd.

  • 03f_replaceRequest_SLD_SoillLocationClosure_IMBROA_WBB.xml

    • Corrigeren van gegevens die met stap 3c zijn aangeleverd.

4.3. XML-code snippets

Voorbeelden van een aantal algemene stukken XML-code (code snippets) zijn te vinden in het document Handreiking aanleveren BRO-gegevens

De volgende paragrafen bevatten enkele stukken XML-code die specifiek zijn voor SLD.

4.3.1. FeatureCollectionIMSIKB0101

In de brondocumenten SLD_CompleteReport, SLD_StartReport en SLD_NewDecision is een featureCollection aanwezig van het type FeatureCollectionIMSIKB0101PropertyType uit de IMSIKB0101 standaard. Deze featureCollection zal een volledige SIKB XML structuur moeten bevatten, te beginnen met het root-element FeatureCollectionIMSIKB0101.

Onderstaande XML-code bevat een voorbeeld van een FeatureCollectionIMSIKB0101, opgenomen in een SLD brondocument SLD_StartReport, verpakt in in een BRO registrationRequest (registratieverzoek).

<?xml version="1.0" encoding="UTF-8"?>
<registrationRequest
    xmlns="http://www.broservices.nl/xsd/issld/1.0" 
    xmlns:sldcom="http://www.broservices.nl/xsd/sldcommon/1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://www.broservices.nl/xsd/issld/1.0 https://schema.broservices.nl/xsd/issld/1.0/issld-messages.xsd">

    <sldcom:requestReference>verzoek_1</sldcom:requestReference>
    <!-- KVK nummer van de aanleverende partij -->
    <sldcom:deliveryAccountableParty>1234567</sldcom:deliveryAccountableParty>
    <!-- Kwaliteitsregime, voor nu alleen nog IMRBO/A -->
    <sldcom:qualityRegime>IMBRO/A</sldcom:qualityRegime>
    <sourceDocument>
        <SLD_StartReport>
            <!-- optioneel: identificatie van het Overheidsbesluit bodemverontreiniging in de eigen administratie. -->
            <objectIdAccountableParty>12345</objectIdAccountableParty>
            <!-- Kader aanlevering; WetBodembescherming of Omgevingswet -->
            <deliveryContext codeSpace="urn:bro:sld:DeliveryContext">Omgevingswet</deliveryContext>
            <featureCollection>
                <!-- Hier kan de volledige SIKB XML geplakt worden-->
                <imsikb0101:FeatureCollectionIMSIKB0101 gml:id="_9e0c2e47-5019-4846-bf80-050c79a09ff2"
                                             xmlns:imsikb0101="http://www.sikb.nl/imsikb0101"
                                             xmlns:gco="http://www.isotc211.org/2005/gco"
                                             xmlns:gmd="http://www.isotc211.org/2005/gmd"
                                             xmlns:gsr="http://www.isotc211.org/2005/gsr"
                                             xmlns:gss="http://www.isotc211.org/2005/gss"
                                             xmlns:gts="http://www.isotc211.org/2005/gts"
                                             xmlns:gml="http://www.opengis.net/gml/3.2"
                                             xmlns:om="http://www.opengis.net/om/2.0"
                                             xmlns:sam="http://www.opengis.net/sampling/2.0"
                                             xmlns:sams="http://www.opengis.net/samplingSpatial/2.0"
                                             xmlns:spec="http://www.opengis.net/samplingSpecimen/2.0"
                                             xmlns:xlink="http://www.w3.org/1999/xlink"
                                             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                             xmlns:immetingen="http://www.sikb.nl/immetingen"
                                             xsi:schemaLocation="http://www.sikb.nl/imsikb0101 ../imsikb0101_v14.7.1.xsd">
  					 <!-- Rest van SIKB xml ..., de xml kan vooraf gevalideerd worden met de bijbehorende SLD-XSLT --> 
                </imsikb0101:FeatureCollectionIMSIKB0101>
            </featureCollection>
        </SLD_StartReport>
    </sourceDocument>
</registrationRequest>

4.4. Enumeraties in de Envelop

In de BRO wordt een onderscheid gemaakt tussen beheerde waardenlijsten en niet-beheerde waardenlijsten. In de envelop welke om het SIKB0101 bestand heen gewrapped zit, worden enkele BRO specifieke velden gevraagd. Deze velden bevatten enumeratie waardes welke hier beschreven worden.

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).

De onderstaande tabel geeft een overzicht van de SLD-specifieke enumeraties.

• 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.

• De vierde kolom bevat een omschrijving van de toegestane waarde.

5. Mappingtabel van SIKB0101 naar de SLD catalogus

Dit hoofdstuk bevat een mappingtabel, die aangeeft hoe een attribuut met de Nederlandse naam in de SLD-gegevenscatalogus wordt gevuld met een Engelstalig element uit een IMSIKB0101 XSD- of XML-bestand.

De onderstaande tabel is gesorteerd op logische volgorde van de SLD-gegevenscatalogus.

6. Codelijsten mapping BRO Catalogus en SIKB0101

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

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.

De onderstaande tabel geeft een overzicht van de SLD-specifieke codelijsten.

• De eerste kolom bevat de Nederlandstalige naam, zoals die voorkomt in de gegevenscatalogus.

• De tweede kolom bevat de URN, die in de SIKB0101 xml gebruikt moet worden als de waarde van het betreffende xml attribuut. SIKB0101 verschilt hierin ten opzichte van de BRO Modellen. Zie Codelist (Codelijst), de voorbeeldberichten en de opmerking na de tabel voor nadere informatie.

• De derde kolom bevat een link naar de webpagina waar de lijst met toegestane waarden geraadpleegd kan worden, zodat deze geldig is voor de inname in BRO.

De URN regels voor de BRO zijn anders dan voor SIKB0101.

Bij de BRO wordt de URN in de codeSpace geplaats en de waarde direct in het veld.
Een voorbeeld van de BRO variant in een XML, waarbij de URN + waarde gebruikt wordt:

CODE

<sldcom:coordinateTransformation codeSpace="urn:bro:CoordinateTransformation">RDNAPTRANS2008</sldcom:coordinateTransformation>

Bij SIKB0101 wordt de hele URN als waarde opgenomen in het veld, met daarbij het SIKB0101ID.
Een voorbeeld van de SIKB0101 variant in een XML, waarbij de URN + SIKB0101ID gebruikt wordt:

CODE

<imsikb0101:investigationReason>urn:imsikb0101:OnderzoekAanleidingen:id:2</imsikb0101:investigationReason>

7. Valideren van de aanlevering o.b.v. de XSD en controle XSLT

Voor het aanleveren bij de BRO zijn specifieke controle XSLT’s gemaakt. Deze worden meegeleverd naast de XSD en de voorbeeldberichten, en staan hier op de Github. Deze controles zijn ook toegevoegd aan de BRO Validatieservice.

8. Bijlage; Vertaaltabel van interne SLD interface naar SLD gegevenscatalogus

Dit hoofdstuk bevat een vertaaltabel, aan de hand waarvan, gegeven de Engelstalige naam van een onderdeel in de XSD- en XML-bestanden van het interne SLD-interface, dus na SIKB conversie, kan worden omgezet in de Nederlandstalige naam in de SLD-gegevenscatalogus.

De onderstaande tabel is gesorteerd op alfabetische volgorde van de Engelstalige naam van het complexType/element. Tussen haakjes staat het type modelelement van de entiteit. Binnen een entiteit zijn de attributen gesorteerd op Engelstalige naam.

9. Bijlage; Codelijsten interne SLD interface

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

In de gegevenscatalogus en de BRO interne XSD-bestanden noemen we een beheerde waardenlijst een codelijst. Het domein van een codelijst is een uitbreidbare opsomming van toegestane waarden.

De onderstaande tabel geeft een overzicht van de SLD-specifieke codelijsten, zoals die worden gebruikt in de XSD- en XML-bestanden van het interne SLD interface, dus na SIKB Conversie.

• De eerste kolom bevat de Engelstalige naam van de codelijst, zoals deze voorkomt in de XSD-bestanden van het interne SLD interface.

• De tweede kolom bevat de Nederlandstalige naam, zoals deze voor komt in de gegevenscatalogus

• De derde kolom bevat de URN, zoals te gebruiken in de XML-bestanden van het interne SLD interface.

• De vierde kolom bevat een link naar de REST-service, waarmee u de inhoud van een bepaalde codelijst kunt opvragen. Als resultaat ontvangt u dan een JSON-bericht met daarin alle waarden van de codelijst met de beschrijvingen.