Getriggerd door deze vraag in het forum over de Zaak- Documentservices is mij de volgende tekst in het verStUFfingsdocument RGBZ opgevallen (pagina 7, onderaan):
De relatiesoorten MEDEWERKER.hoort bij.ORGANISATORISCHE EENHEID en ORGANISATORISCHE EENHEID.is gehuisvest in.VESTIGING ZAAKBEHANDELENDE ORGANISATIE worden in kennisgevingen geïmplementeerd vanuit MEDEWERKER respectievelijk ORGANISATORISCHE EENHEID, omdat deze relaties identificerend zijn. De gerelateerde ORGANISATORISCHE EENHEID en VESTIGING ZAAKBEHANDELENDE ORGANISATIE hoeven nog niet te bestaan en mogen samen met de medewerker of de organisatorische eenheid worden toegevoegd. Voor deze gerelateerde zijn de verwerkingsoorten 'T' en 'I' toegestaan met uitsluitend de kerngegevens. In de kennisgevingberichten voor ORGANISATORISCHE EENHEID en VESTIGING ZAAKBEHANDELENDE ORGANISATIE komen de corresponderende inverse relaties niet voor.
De match/kerngegevens zijn identificerende gegevens, niet alle verplichte gegevens voor een OEH of VES. Wanneer een applicatie een datamodel heeft wat gebaseerd is op en voldoet aan het RSGB en RGBZ zou dit fouten moeten geven. Er ontbreken immers verplichte gegevens om het object op te kunnen slaan.
Mijn vraag is dus: voldoet StUF ZKN met bovenstaande vetgedrukte regels wel aan het RGBZ? Zo ja, hoe dan? Zo nee dan zou mijns inziens die regel geschrapt moeten worden of de match-/kerngegevens zouden uitgebreid moeten worden tot de minimale set gegevens die nodig zijn om het object aan te maken.
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0502.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 21 februari 2018 is het onderhoudsverzoek afgewezen. Duidelijk werd dat je niet alle in het bericht verplichtte gegevens ook nodig hebt om het object op te kunnen slaan.
Volgens mij sluit de laatste zin in de post van Robert niet aan bij wat er in het overleg is gesteld. Hierbij mijn conclusie uit het overleg van de StUF Expertgroep van 21 februari:
Niet alle attributen die in RSGB en RGBZ kardinaliteit 1 hebben zijn in het informatiesysteem ook altijd beschikbaar. De betekenis van de kardinaliteit in deze semantische modellen is dat in de werkelijkheid het kenmerk een waarde heeft, niet dat die ook zonder meer bekend moet zijn in het informatiesysteem.
Verplicht stellen van deze attributen in de database zou dus problemen kunnen opleveren. Bovendien zou de ontvanger op basis van de kerngegevens bij de bron van de gerelateerde de overige (al dan niet benodigde) gegevens kunnen ophalen, waarmee de kerngegevens voldoende zijn.
Een ander belangrijk argument is dat (een aantal van) de genoemde gerelateerden eigenlijk min of meer referentietabellen zijn waarvan je waarschijnlijk niet wil of zou moeten willen dat elke client er 'zomaar' regels aan toe kan voegen. Het lijkt dan toch wenselijker dat nog niet bekende gerelateerden worden opgemerkt, omdat dat wijst op een mogelijke fout in het beheerproces.
Niet alle attributen die in RSGB en RGBZ kardinaliteit 1 hebben zijn in het informatiesysteem ook altijd beschikbaar. De betekenis van de kardinaliteit in deze semantische modellen is dat in de werkelijkheid het kenmerk een waarde heeft, niet dat die ook zonder meer bekend moet zijn in het informatiesysteem.
Verplicht stellen van deze attributen in de database zou dus problemen kunnen opleveren. Bovendien zou de ontvanger op basis van de kerngegevens bij de bron van de gerelateerde de overige (al dan niet benodigde) gegevens kunnen ophalen, waarmee de kerngegevens voldoende zijn.
Deze paragraaf moet ergens rood en dik gedrukt staan in ALLE verstuffingsdocumenten en informatiemodellen documenten...
Een ander belangrijk argument is dat (een aantal van) de genoemde gerelateerden eigenlijk min of meer referentietabellen zijn
Hoe worden deze "referentietabellen" eigenlijk gevuld volgens VNG als dat niet kan met de ZDS services?
Het voorstel van Joeri om de door Sid geschreven alinea's dik gedrukt op te nemen in ALLE verStUFfingsdocumenten is als onderhoudsverzoek opgevoerd in de onderhoudsverzoeken als ONV0514.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten