StUF-BG 03.10 - Gebeurteniscode BAG-COR vs. BAG-MUT en effect op (Lk03) berichten

[ProcessPatrick]

Graag doen wij een beroep op jullie inzichten en overwegingen over het volgende:

De gebeurteniscode BAG-MUT (Mutatie naar aanleiding van signalering) is volgens Berichtcatalogus bg0310-BAG.pdf (patch 30) ten behoeve van ‘Compatibiliteit met BAG 2018’ overgegaan naar BAG-COR (Correctie naar aanleiding van signalering). Opmerking uit ‘Bijlage 1: Verschillen in gebeurtenissen tussen versies van processenhandboeken’:

• BAG-COR: In 2013 toegevoegd; in 2018 naam gewijzigd en samengevoegd met BAG-MUT
• BAG-MUT: In 2013 toegevoegd; in 2018 samengevoegd met BAG-COR

Binnen het Lk03-berichtenverkeer is de gebeurteniscode leidend voor het samenstellen van het samengestelde bericht. Dus werkend met de BAG-COR komen we bij de volgende definitie uit:

<element name="bagCOR_Lk03">
    <annotation>
        <documentation>Correctie object</documentation>
    </annotation>
    <complexType>
        <sequence>
            <element name="stuurgegevens" type="StUF:bagCOR-Lk03-Stuurgegevens"/>
            <choice maxOccurs="unbounded">
                <element name="aoaLk01" type="BG:AOA-Lk01-bag-corrigeren"/>

> <complexType name="AOA-Lk01-bag-corrigeren">
> …
>     <element name="parameters" type="StUF:ParametersLk01F"/>

> <complexType name="ParametersLk01F">
> …
> <element name="mutatiesoort" type="StUF:MutatiesoortF"/>

> <simpleType name="MutatiesoortF">
>     <annotation>
>         <documentation>Mutatiesoort = F</documentation>
>     </annotation>
>     <restriction base="StUF:Mutatiesoort">
>         <enumeration value="F"/>
>     </restriction>
> </simpleType>

                <element name="gemLk01" type="BG:GEM-Lk01-bag-corrigeren"/>
                <element name="oprLk01" type="BG:OPR-Lk01-bag-corrigeren"/>
                <element name="pndLk01" type="BG:PND-Lk01-bag-corrigeren"/>
                <choice>
                    <element name="ligStaLk01" type="BG:TGO-Lk01-bag-AOTnietVBO-corrigeren"/>
                    <element name="ogoLk01" type="BG:TGO-Lk01-bag-OGO-corrigeren"/>
                    <element name="otrLk01" type="BG:TGO-Lk01-bag-OTR-corrigeren"/>
                    <element name="vboLk01" type="BG:TGO-Lk01-bag-VBO-corrigeren"/>
                </choice>
                <element name="wplLk01" type="BG:WPL-Lk01-bag-corrigeren"/>
            </choice>
        </sequence>
    </complexType>
</element>

Samengevat: bagCOR_Lk03 berichten hebben mutatiesoort F.

Als we dan doorgaan naar ‘Standaard Uitwisseling Formaat StUF 03.01: In Gebruik (versie 27)’ lezen we op pagina 61 de volgende functionele eis:

“3. Mutatiesoort 'C' of 'F' en verwerkingssoort 'W': een correctie zonder respectievelijk met formele historie Een kennisgeving met mutatiesoort 'C' (correctie zonder formele historie) of 'F' (correctie met formele historie) vervangt een foutief geregistreerde huidige waarde door de juiste waarde. In geval van mutatiesoort 'C' zonder dat door de zender van deze correctie formele historie is opgebouwd en in geval van mutatiesoort 'F' met opbouw van formele historie door de zender. Een ontvanger mag zelf beslissen of hij al dan niet formele historie opbouwt ongeacht wat de zender doet. Als de kennisgeving met mutatiesoort 'C' of 'F' en verwerkingssoort 'W' een tijdvakGeldigheid bevat, dan gelden de volgende regels (zie voor de gebruikte notatie paragraaf 5.2.1): • tijdvakGeldigheid moet aanwezig zijn in zowel oud als huidig • t_eo = t_en = ∞ Deze twee eisen kunnen worden gecontroleerd zonder de registratie te raadplegen. Indien de ontvanger het tijdvakGeldigheid nodig heeft voor zijn verwerking, dan kan foutmelding StUF062 (zie Tabel 5.8 op pagina 71) worden teruggegeven, als het tijdvakGeldigheid ontbreekt of als aan één van de bovenstaande eisen niet wordt voldaan. Het tijdvakGeldigheid is niet verplicht, omdat er registraties zijn (bijv. de Basisregistratie Grootschalige Topografie) die uitsluitend formele historie opbouwen en geen materiële historie.”

Let op! Functionele eis, omdat de .xsd hier niet deze beperking op tijdvlakGeldigheid valideert. Dus StUF-testplatform en xsd-toetsen geven hier geen fout of waarschuwing op.

Als t_eo = t_en = ∞ geïnterpreteerd moet worden als eindGeldigheid oud en nieuw zijn gelijk en gelijk aan oneindig (leeg…?), dan spreken we over het herschrijven van een voorkomen. Wat potentieel door eerder mutaties/gebeurtenissen heen informatie kan wijzigen. Dit lijkt een zeer ingrijpende verandering van gedrag. Zo communiceren we niet naar Kadaster, daar zijn alle wijzigingen nieuwe voorkomens waardoor de historie gewaarborgd blijft.

Klopt het dat deze samenvoeging van gebeurteniscodes het herschrijven van een voorkomen, in plaats van het toevoegen van een wijziging aan de historie, tot het gewenste resultaat heeft? Logischer lijkt het gebruik van BAG-MUT, wanneer er geen passende gebeurtenis is, om een mutatie naar (Kadaster en) andere gemeentelijke applicaties te sturen en daarmee alle bestaande ketens van voorkomens van desbetreffende entiteit in stand te houden. _Zie ook de opmerking in bg0310_msgbag.xsd:

“ - De gebeurtenissen volgen de definitie in de BAG. In een aantal gevallen zal een wijziging in BAG+ gegevens doorgevoerd moeten worden via de BAG+ gebeurtenis BAG-MUT en niet in de logischer BAG-gebeurtenis, omdat er geen brondocument of verplichte statuswijziging mee samenhangt, bijv de geometrie op maaiveld in PND of de puntGeometrie in VBO, indien deze onafhankelijk van de geometrie c.q. de vlakgeometrie wordt gewijzigd.”

Alternatief is het opheffen van de restrictie voor mutatiesoort binnen bagCOR_Lk03 berichten.