Hoe worden objecten geïdentificeerd in bg0204?

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

5 reacties / 0 nieuw
Login of registreer om te kunnen reageren
do, 23-04-2009 - 17.05u
#1
Anoniem
Hoe worden objecten geïdentificeerd in bg0204?

Ik kreeg via de service desk van EGEM i-teams een email binnen met de volgende vraag over bg0204:

De kerngegevens zijn niet verplicht. Zowel StUF als GFO vermelden niet de wijze van identificatie van gegevens, bijv. van een natuurlijk of niet-natuurlijk persoon.

Welke identificatie dient te worden gehanteerd voor eenduidige identificatie van gegevens uit de berichten en koppeling aan de back-office systemen?

Bovenaan
Anoniem

Het is juist andersom: alle kerngegevens moeten verplicht worden ingevuld. In de stuf0204 standaard staat het volgende op pagina 24:

Om te waarborgen dat systemen niet vervuild raken, moeten alle kerngegevens volledig in een kennisgevingbericht en een asynchroon antwoordbericht voorkomen.

Deze uitspraak overruled de optionaliteit van de kerngegevens in het schema. Om technische redenen worden niet altijd alle constraints op het niveau van het XSD-schema afgedwongen.

Maar dan rijst de vraag wat zijn bijvoorbeeld de kerngegevens van een persoon? Nou zowel het schema als het sectormodel specificeren de volgende kerngegevens:

Geslachtsnaam, voorvoegsel geslachtsnaam, voorletters, voornamen, relatie PRSADRVBL naar verblijfsadres, geboortedatum, geslachtsaanduiding, A-nummer, Sofi-nummer

Dat vind ik nogal onbevredigend. Ik zou liever de volgende groepen van identificerende gegevens gespecificeerd zien:

  • SoFi-nummer
  • A-nummer
  • Geslachtsnaam, voorvoegsels, voorletters, en relatie PRSADRVBL naar verblijfsadres
  • Geslachtsnaam, voorvoegsels, voorletters, en geboortedatum
  • Etc.

Ik zal vragen of Maarten hier verder op wil reageren.

Bovenaan
Maarten van den...

Voor het verdelen van de kerngegevens in groepen is tot nu toe niet gekozen. Er zijn hier twee redenen voor:

  1. Het maakt de verwerking complexer dan de eenvoudige verplichting dat ze allemaal in het bericht moeten zitten
  2. Als alleen a-nummer of bsn verplicht is, dan blijft een eventuele fout hierin ongemerkt. Als je alle kerngegevens moet specificeren dan is dit veel robuuster en wordt een fout in een A-nummer of bsn gemakkelijk opgemerkt.
Bovenaan
Henk Timmermans

De argumenten van Maarten lijken me hout te snijden. Maar wat is dan de reden om in StUF3 (sommige) kerngegevensgroepen wel in disjuncte keuzetakken (van een 'choice') onder te brengen ? Louter en alleen het feit dat ze zo in het RSGB voor komen?

Bovenaan
Maarten van den...

Het volgen van het domeinmodel zoals gedefinieerd in het RSGB ook in de berichten lijkt me een goede zaak. Als er goede redenen zijn, kan er afgeweken worden en dit dient dan ook gemotiveerd te gebeuren. In bg0310 zijn al deze afwijkingen gemotiveerd in het keuzenVerStUFfing RSGB document.
Dit kan er inderdaad toe leiden dat een of meer kerngegevens in een disjuncte choice takken terecht komen.

Bovenaan