Ik heb een vraag over hoe om te gaan met de sleutel verzendend systeem bij een mutatie in de BAG.
Als in de BAG een nummeraanduiding wordt ingetrokken. Bijvoorbeeld bij een splitsing. Gaat er een StUF-BG 02.04 bericht uit waarin oa de status wijzigt. In de BAG wordt een nieuw actueel voorkomen aangemaakt en een nieuw historisch voorkomen.
De vraag is of in de LK01 wijziging ook de "sleutel zendend systeem" gewijzigd mag worden? Of moet dat met een aparte sleutelwijziging?
Of is het niet StUF conform dat in zo'n geval de sleutel zendend systeem wijzigt?
Mijns inziens is het antwoord afhankelijk van een aantal zaken in het zendende systeem en de keuze of het zendende systeem überhaupt sleutels kan en wil uitwisselen. Lees rustig even verder als je wilt weten hoe ik er tegenaan kijk.
In Standaard Uitwisseling Formaat voor applicaties: StUF 02.04: EGEM Aanbeveling staat:
"5.1.4 Systeemsleutels
Systemen identificeren de occurrences van een entiteittype met een al dan niet betekenisloze unieke sleutel."
In de tabel in paragraaf 5.2.2 staat:
"sleutelVerzendend: Verplicht in kennisgevingberichten en asynchrone
antwoordberichten, wanneer de sleutel beschikbaar is. Mag worden weggelaten als het zendende systeem de sleutel niet heeft; sleutelOntvangend: Optioneel; sleutelGegevensbeheer: Optioneel."
Als een zendend systeem naast het actuele/huidige voorkomen ook historische/voormalige voorkomens bijhoudt, dan zal meestal ieder voorkomen een eigen technische sleutel (ID) hebben. Ik zeg meestal, omdat het gebruik van een betekenisloze technische sleutel een goede ontwerpregel is voor databases, maar niet door iedereen gehanteerd wordt.
Een tweede database ontwerpkeuze is of bij het opbouwen van historie het acctuele een constante ID heeft of dat het nieuwe voorkomen een nieuwe waarde krijgt. Een constante waarde voor het actuele voorkomen heeft voordelen bij ORM (object-relational mapping).
Als een zendend systeem geen ID heeft, dan bevat de kennisgeving geen sleutelVerzendend.
Als een zendend systeem een ID heeft en het actuele voorkomen krijgt een nieuwe ID, dan lijkt het mij voldoende als er één kennisgeving wordt gebruikt, waarbij het was-voorkomen de sleutelVerzendend de ID heeft van het voorkomen dat gemuteerd wordt en het wordt-voorkomen de sleutelVerzendend de ID heeft van het gewijzigde voorkomen. Het lijkt me dat voor het ontvangende systeem (afnemer of distributiesysteem) daarmee voldoende duidelijk is dat het gewijzigde voorkomen een nieuwe sleutelVerzendend heeft gekregen.
Schets van de database in het zendende systeem:
Originele situatie:
ID=1 ADR=X
Gewijzigde situatie:
ID=1 ADR=X
ID=2 ADR=Y
adrLk01: verwerkingssoort=W
was: sleutelverzendend=1, ADR=X
wordt: sleutelverzendend=2, ADR=Y
Als een zendend systeem een ID heeft en het actuele voorkomen behoudt de oorspronkelijke ID, dan moeten er mijns inziens twee kennisgevingen worden gebruikt. De eerste om een sleutelwijziging dooor te geven dat het originele voorkomen een nieuwe ID heeft gebreken en een tweede om de daadwerkekelijke wijziging door te geven.
Schets van de database in het zendende systeem:
Originele situatie:
ID=1 ADR=X
Gewijzigde situatie:
ID=1 ADR=Y
ID=2 ADR=X
adrLk01: verwerkingssoort=S
was: sleutelverzendend=1, ADR=X
wordt: sleutelverzendend=2, ADR=X
adrLk01: verwerkingssoort=W
was: sleutelverzendend=2, ADR=X
wordt: sleutelverzendend=1, ADR=Y
Ik heb een wat andere interpretatie van de bedoeling die StUF heeft met de sleutelVerzendend dan Han. Het lijkt me daarom goed om dit punt te bespreken in de expertgroep.
StUF legt veel nadruk op het feit dat in kennisgevingberichten gegevens over de werkelijkheid worden uitgewisseld. In dit kader lijkt het mij een randvoorwaarde aan een wijziging van de sleutelVerzendend dat het record in de database een nieuwe sleutel heeft, maar nog steeds verwijst naar hetzelfde object in het domein waarover de registratie gegevens vastlegt. Er mag in de registratie geen actueel record meer voorkomen met de 'oude' sleutelVerzendend. Voor het doorvoeren van een sleutelwijziging horen goede redenen te zijn, omdat sleutels in systemen een belangrijke rol spelen bij het leggen foreign keys, maar StUF doet hier geen uitspraken over. StUF staat in 0204 en 0301 het doorgeven van een sleutelwijziging alleen toe in objecten met verwerkingssoort 'S'. Het is niet toegestaan om een sleutelwijziging door te geven samen met andere wijzigingen.
Het processenhandboek BAG stelt dat bij een hernummering de identificatiecode van de nummeraanduiding niet wijzigt. Er moet wel een historisch voorkomen worden aangemaakt. Het lijkt mij derhalve onnodig en ongewenst dat een systeem bij een hernummering de sleutel van het object wijzigt. Worden dan in alle adresseerbare objecten de verwijzingen naar de hernummerde nummeraanduiding ook gewijzigd? Het probleem wordt mogelijk veroorzaakt doordat de BAG regelmatig spreekt over een nieuw voorkomen bij een wijziging van gegevens naast het oude 'historische' voorkomen.
Ik wil zo weinig mogelijk woorden gebruiken om mijn inzichten duidelijk te maken. Dus: 5.1.4 Systeemsleutels zegt dat SleutelVerzendend een voorkomen van een object aanduidt. Als ADR X wordt gewijzigd in Y dan is er dus sprake van een nieuw voorkomen. Twee verschillende voorkomens van het zelfde object hebben dezelfde kerngegevens (bv BAG identificatiecode van een nummeraanduiding en nog wat andere elementen) maar in de database twee verschillende waarden voor "betekenisloze unieke sleutel" oftewel Primary Key of ID of SleutelVerzendend. Het lijkt me dus logisch en noodzakelijk dat in een was/wordt bericht de twee voorkomens verschillende sleutelsverzendend hebben als de zendende applicatie beide voorkomens onthoudt. Voor de rest, lees mijn vorige post nog maar eens door.
StUF-berichten gaan over objecten in de werkelijkheid en niet over records in de database. De sleutelVerzendend en de sleutelOntvangend in StUF zijn daarom de unieke identificatie van een object in de werkelijkheid. Als een object historie heeft en daardoor meerdere records in de database: te weten het record met de actuele waarden en records met toekomstige of historische waarden, dan kunnen deze records verschillende sleutels hebben. Bij het bevragen op een peiltijdstip in het verleden dient de object moet de sleutelVerzendend onafhankelijk zijn van het peiltijdstip. Het is binnen StUF derhalve niet de bedoeling dat bij het wijzigen van een object de sleutel van dat object verschilt in het oude en het nieuwe voorkomen.
Zoals Han al heeft aangegeven identificeren systeemsleutels de occurrences van een entiteittype.
Aangezien 'occurrence' in die definitie staat, ben ik net als Han geneigd te concluderen dat daar een database id bedoeld wordt. Het is redundant om de identificatiecode van een BAG object hier te gebruiken, aangezien dat in een ander element al gecommuniceerd wordt.
Overigens staat in paragraaf 2.1.9 van de BAG GBA Koppelvlak beschrijving dat berichten voor fundamentele entiteiten systeemsleutels mogen bevatten.
In hoeverre kunnen ontvangende partijen ermee overweg als de systeemsleutel wordt weggelaten?
Blijkbaar ben ik niet de enige die het verkeerd had begrepen.
Maar goed. ik begrijp ondertussen dat SleutelVerzendend niets te maken heeft met een database, laat staan met technische sleutels of een primary key.
De SleutelVerzendend geeft daarentegen alleen een unieke aanduiding van een object in de werkelijkheid. Waarbij dan een database, zeker bij een bronhoudende applicatie die historie bijhoudt, meerdere records kan bevatten met dezelfde SleutelVerzendend: het huidige voorkomen, historische voorkomens en toekomstige voorkomens en dat langs ten minste de beide assen van materiële historie en formele historie.
Kortom, de SleutelVerzendend is geen unieke aanduiding van een voorkomen van een object in de historie. Om in een database met huidige, historische en toekomstige voorkomens een record uniek te duiden moet ten minste de combinatie van SleutelVerzendend, ingangsdatum materiële historie en tijdstipregistratie worden gebruikt.
Verder ben ik het met Robin eens: Sleutelverzendend is redundant binnen het BAG domein.
Maar als iedereen er mee eens is dat de spec enige verduidelijking behoeft en kan leven met de definitie en beperkingen, dan is het wat mij betreft best: vanuit BAG geven we als Sleutelverzendend gewoon de BAG ObjectIdentificatie dan wel woonplaatsidentificatie of gemeentecode mee. Die waarden en betekenis voldoen volgens mij aan de intentionele definitie van SleutelVerzendend.
Wellicht interpreteer ik een en ander verkeerd, maar ik krijg de indruk dat een splitsing van een adres A1 in de adressen A2 en A3 door enkele leveranciers wordt gecommuniceerd via twee wijzigkennisgevingen (oude waarde A1 en nieuwe waarde A2 respectievelijk oude waarde A1 en nieuwe waarde A3).
Dit is mijns inzien geheel incorrect !
Er moeten een wijziging (opname einddatum) van A1 en toevoegingen van A2 en A3 worden verstrekt. Hierbij wordt de splitsing (filiatie) gecommuniceerd door bij de adressen A2 en A3 relaties (ADRADROSU) op te nemen met adres A1.
John,
Misschien heb je een punt. Maar deze post gaat over sleutelverzendend. De BAG gebeurtenis Splitsing is slechts een voorbeeld. Ik stel voor dat als je gerede twijfel hebt over de berichten bij deze gebeurtenis daar een aparte post voor aan te maken.
Onder "nieuwste documenten" op deze site zag ik het document "Rapportage harmonisatie StUF en NEN 3610". Het lijkt er op dat de wijze van omgaan met sleutelVerzendend waarop in deze discussie is aangestuurd in tegenspraak is met een van de harmonisatievoorstellen (B01). Als ik een en ander goed begrepen heb, denk ik dat ofwel de conclusie van de discussie in dit onderwerp moet worden herzien, ofwel het voorstel voor harmonisatie.
Hieronder de fragmenten uit genoemd document die deze vragen bij mij hebben opgeroepen.
In paragraaf "3.2.2 Plateau 2 – Harmonisatie van modelleertechniek en semantiek" in tabel "3. Afstemmen berichten" staat een rij:
B01 - Neem in GML structuren zowel het gml:id attribuut als het StUF:sleutelVerzendend attribuut op met beide dezelfde waarde. (Geonovum)
Verderop in paragraaf "5.2.1 StUF" staat:
StUF kent hier meer semantiek dan GML met het XML attribuut gml:id. Het XML attribuut gml:id dient in StUF gemapt te worden op het XML attribuut StUF:sleutelVerzendend. In de praktijk lijkt het verstandig om in GML-structuren zowel het XML attribuut gml:id als het XML attribuut StUF:sleutelVerzendend op te nemen en ze vanuit elkaar te vullen.
Even verderop wordt ook weer de hiervoor aangehaalde rij met betrekking tot harmonisatievoorstel B01 vermeld.
In "4.2.6 Identificatie van objecten" staat onder "De object-identificatie 'NEN 3610id' bestaat uit drie elementen:"
3. Versie wordt alleen gebruikt indien er versie (levensloop) informatie aanwezig is en heeft een unieke waarde voor elke versie van het object. Versie is weliswaar onderdeel van het NEN 3610id, maar geen onderdeel van de unieke object-identificatie. Alle versies van een object moeten dezelfde object-identificatie hebben bestaande uit namespace en lokaalID. Het element Versie is van belang voor het vullen van het door GML voorgeschreven gml:id, indien meerdere versies van een object in één bestand opgenomen moeten worden.
Dit fragment geeft zoals ik het lees nog eens aan dat verschillende versieaanduidingen expliciet onderdeel zijn van het gml:id als er meer voorkomens in een bericht opgenomen zijn. Aangezien het gml:id eerder is gekoppeld aan de StUF-sleutelVerzendend, zou dat daar dan ook moeten gelden, ofwel zou de koppeling tussen gml:id en sleutelVerzenden anders beschreven moeten worden.
Even kort door de bocht: SleutelVerzendend in StUF is een unieke aanduiding van een object, niet de unieke aanduiding van een voorkomen van een object
Als ik het me goed herinner dan is gml:id (niet alleen in NEN 3610 maar vooral in GML) een unieke identificatie van een geometrie en moet deze bij verschillende (voorkomens van een) geometrie een andere waarde hebben.
Daarmee komt volgens mij komt SleutelVerzendend uit StUF overeen met object-identificatie (dwz namespace en lokaalID maar niet versie) van NEN 3610id.
Als bovenstaande klopt, dan kan SleutelVerzendenduit StUF dus niet gemapped worden op gml:id.