In het afgelopen jaar is het 'keuzenVerStUFfing RSGB3' versie 0.3 document behandeld in de StUF Expertgroep. Inmiddels zijn alle relatiegrafieken goedgekeurd en aanpassingen verwerkt in versie 0.4 (zie bijlage).
Het is de bedoeling dat dit document in de aankomende vergadering van 21 september als hamerstuk wordt goedgekeurd. Dus opmerkingen en reacties graag ruim voor deze datum via dit forum indienen.
Bijgaand ook de versie met revisie. Door een bug in OpenOffice Writer wordt in revisie-modus sectie 5 per abuis aangezien als sectie 6. Let op: OpenOffice Writer laat de aanpassingen in de diagrammen niet zien. Gelukkig zijn die wel goed beschreven in de versiehistorie vlak na de inhoudsopgave.
Bijlage
In aanvulling op een discussie in de Regiegroep ben ik in het VerStUFfingsdocument erg op zoek naar de samenhang tussen "het genereren van berichten/berichtcomponenten uit een uml" en de detaillering van relatieschema's in het verStUFfingsdocument.. Ik verwacht minimaal een beschrijving van hoe deze samenhang werkt, maar verwacht eigenlijk ook dat een aantal van de details uit het VerStUFfingsdocument (zoals de heel gedetailleerde relatiegrafieken) "verhuisd" zouden moeten worden naar het uml van waaruit de berichten/berichtcomponenten gegenereerd worden.
Eerder hebben wij afgesproken (verslag expertgroep 20 april 2016) dat wij geen wijzigingen in Mnemonics zouden toepassen. Toch staan er in deze versie van het VerStUFfingsdocument nog allerlei Mnemonics die niet overeen komen met StUF 3.10. De afgesproken correctie in het document is dus nog niet doorgevoerd.
In 2.6 wordt de problematiek aangehaald die voortkomt uit de richting die in RSGB wordt meegegeven aan een relatie.
Er wordt gemeld dat de gemaakte keuzes tot gevolg kunnen hebben dat er functioneel dingen binnen StUF 3.20 niet meer kunnen. Met name op genoemde voorbeeld van NNP lijkt dat zorgelijk. In de praktijk worden RSIN, Handelsregisternummer en vestigingsnummer gebruik om niet-natuurlijke personen aan te duiden. De waarschuwing lijkt erop te duiden dat dat in de toekomst erg beperkt zal zijn. Het lijkt wenselijk om de "wegvallende functionaliteiten" expliciet te benoemen, zodat eventueel het RSGB op dit terrein heroverwogen kan worden.
Het gebruik van hoofdletters in namen van attributen gebeurt in het document nog niet consequent. Hierbij is sprake van inconsistentie in toepassing van de regels, maar we zien dat er ook diverse attributen twee verschillende namen hebben gekregen: gem.gemeentecode naast gem.gemeenteCode en gem.gemeentenaam naast gem.gemeenteNaam.
3.6 relatiegrafieken WOZ
Tot onze verbazing worden hier wijzigingen doorgevoerd, waardoor RSGB gaat afwijken van het Sectormodel WOZ. Wij zien geen reden voor deze wijzigingen. Dus bijvoorbeeld de WRDWOZ relatie moet gewoon "is voor" blijven heten en niet worden gewijzigd in "hoort bij". Idem voor WOZWDO blijft "heeft deelobject" in plaats van "heeft als onderdeel".
Verder valt op de relatie "ontleent aanduiding aan". Dat is in het Sectormodel WOZ een relatie naar een object (AOT) en dat wordt hier een relatie naar een objectaanduiding (AOA). Dit is een ongewenste inhoudelijke wijziging.
Op basis van praktijkervaringen hebben wij de WOZOPR relatie geschrapt uit Sectormodel WOZ. Wellicht verstandig om dat in StUF bg 3.20 dan ook te doen.
De Mnemonic SOC staat niet in tabel 4.1.
Nu SOC en WDC als fundamentele entiteit worden aangemerkt, betekent dit volgens ook dat deze in de relatiegrafieken van 3.6 een plaats moeten krijgen.
@ post #3 van Ruud Kathman. Het verstuffingsdocument bevat de belangrijkste ontwerpbeslissingen die genomen zijn bij het definiëren van de basis-entiteiten voor het sectormodel bg0320 gebaseerd op het RSGB 3.0. Het gaat hierbij bijvoorbeeld om het samenvoegen van meerdere RSGB objecttypen in één StUF entiteittype, om het al dan niet opnemen van relatietypen uit het RSGB in een StUF entiteittype of om het niet opnemen van een relatietype in het RSGB als een relatie-entiteittype binnen een StUF entiteittype, maar als een 'platgeslagen' verzameling elementen in het StUF entiteittype.
Het verstuffingsdocument is niet normatief. Het geeft een toelichting en motivatie bij een groot aantal gemaakte keuzen. De formele specificatie van de basis-entiteiten van het sectormodel bg0320 ligt vast in de basisschema's bg0320_ent_basis.xsd, bg0320_simpleTypes.xsd, bg0320_stuf_simpleTypes.xsd.
Voorheen werden na de goedkeuring van het verstuffingsdocument de relatiegrafieken in één keer (handmatig) omgezet naar de bovengenoemde basisschema's. In de nieuwe aanpak zetten we de relatiegrafieken eerst om naar UML-diagrammen, ook wel het Uitwisselings Gegevens Model (UGM) genoemd, en daarna worden vanuit het UGM de basisschema's automatisch gegenereerd. Ook kan het UGM gebruikt worden als basis van het BSM (Bericht Structuur Model). Het BSM is een UML model waarmee berichtdefinities in Enterprise Architect kunnen worden opgesteld. Vanuit het BSM kunnen dan de berichtdefinities voor koppelvlakken direct gegenereerd worden.
Vooralsnog is de nieuwe aanpak een intern proces van KING om op een betere/snellere manier schema's te maken / genereren. In het verstuffingsdocument hoeft daar geen verantwoording over te worden afgelegd.
Op basis van het verstuffingsdocument ben ik reeds begonnen RSGB 3 om te zetten naar het UGM (het BAG gedeelte is al bijna klaar). Daarom is het zo belangrijk dat het verstuffingsdocument asap goedgekeurd wordt want het is erg vervelend als de Expertgroep over bepaalde gemaakte keuzes weer van gedachte veranderd. Dan kan ik al mijn werk weer opnieuw doen.
@post #4 van Ruud Kathman. Kun jij een lijstje geven van mnemonics die veranderd zijn t.o.v. bg0310? Dan zal ik in de EG van volgende week vragen aan de leden of ze weer teruggezet mogen worden naar de oude naam. Ik ben het volledig met je eens dat het beter is om de oude namen te handhaven.
@post 5 van Ruud Kathman. Goede observatie want sectie 2.6 klopt niet. Ik zal deze sectie herschrijven of misschien zelfs in zijn geheel weglaten. Want de EG mag tijdens de verstuffing van een informatiemodel zelf inverse relaties toevoegen indien nodig. Als je goed kijkt naar de relatiegrafieken zie je dat we dat op meerdere plekken hebben gedaan zodat er geen functionaliteit is weggevallen. Indien er toch functionaliteit t.o.v. de vorige versie is verdwenen dan was dat een bewuste keuze van de EG.
@post 6 van Ruud Kathman. Bedankt voor de observatie, ik zal de inconsistenties aanpassen. Trouwens bij het omzetten van het RSGB 3 naar het UGM in EA zullen dit soort inconsistenties niet optreden omdat de elementnamen dan automatisch uit het informatiemodel worden gegenereerd, tenzij de namen niet goed zijn in het RSGB.
@post #7 van Ruud Kathman. Vreemd, dan wijkt het RSGB af van het IM-WOZ. Dat is dan een wijzigingsverzoek op het RSGB. Dus ik zal aan Ellen vragen om "hoort bij" te veranderen in "is voor" m.b.t. de relatie WRDWOZ (WOZ-WAARDE -> WOZ-OBJECT).
De aanpassing "heeft als onderdeel" in "heeft deelobject" zou ik zelf kunnen doorvoeren in de verstuffing omdat het hier om een inverse relatie gaat die niet in het RSGB gedefinieerd is. Echter qua naamgeving is het niet erg consistent met de orginele relatie 'WDO.is onderdeel van.WOZ'.
Het RSGB 3 bevat geen AOT (Adresseerbaar Object: generalisatie van LIG, STA en VBO). Zelfs het huidige bg0310 bevat geen AOT. Is dit een nieuwe RFC op het RSGB?
Het schrappen van WOZOPR is een nieuwe RFC op het RSGB. Bg0320 volgt het RSGB 3.
Bedankt voor de observatie, ik zal SOC toevoegen aan zowel tabel 4.1 als tabel 5.1 (in de een na laatste rij).
In ieder geval heb ik zojuist zowel SOC als WDC toegevoegd in de WOZ-rij van tabel 5.1. Op zich een goed idee om sectie 3.8 te laten vervallen en alle mappings van referentielijsten naar entiteittypen te benoemen in de bijbehorende sectie. Ik weet niet of het veel zin heeft om van deze entiteittypen ook echt een grafiek te tekenen omdat ze geen relaties hebben. Zelfde verhaal eigenlijk als voor de entiteittypen van de BGT.
Drie kleinigheden:
De NPSPES is in de relatiegrafiek in beide richtingen een doorgetrokken streep. De tekst is correct.
De relatie NPSRSD is in de relatiegrafiek een doorgetrokken streep. Dit zou een stippellijn moeten zijn.
De relatie KOZ.is overgegaan in.KOZ zou een stippellijn moeten zijn.
@post #7 en #12. Ruud, vandaag heb ik contact gehad met Ellen. Zij zal in het RSGB "hoort bij" veranderen in "is voor". Ik zal dat ook doen in het verstuffingsdocument en het UGM. Voor het herintroduceren van AOT of het schrappen van WOZOPR kun je een RFC indienen op het RSGB.
@post #13. Maarten, bedankt voor je observaties. De relaties NPSPESISV (is functionaris van) en KOZKOZNAR (is overgegaan in) heb ik alvast in de relatiegrafieken aangepast. De relatie NPSRSD heb ik nog niet aangepast. In de EG van 15 juni j.l. is namelijk besloten voor een doorgetrokken streep. Zie het volgende citaat uit het verslag:
Er wordt besloten om RSD toch zonder stippellijn aan NPS te hangen. Mark zegt dat de consequentie is dat in een koppelvlak dan gekozen kan worden voor beide varianten. RSD blijft in ieder geval ook zo bestaan. Met de opmerking over herkomst daargelaten wordt NPS goedgekeurd.
De afgelopen jaren zijn in kennisgevingen relaties altijd vanuit maar één richting geïmplementeerd. Deze regel bestaat om de volgende twee redenen:
Op grond van welke argumenten is in de expertgroep van 15 juni besloten om van deze regel af te wijken?
Henri,
Dank voor de toelichting.
Het UGM is daarmee duidelijke stap op weg naar de xsd-schema's. Uiteindelijk zijn alleen de xsd-schema's normatief. Maar ik zou me kunnen voorstellen dat we in deze nieuwe werkwijze toch het UGM ook door de expertgroep laten vaststellen en de afzonderlijke handmatige relatiegrafieken in het verStUFfingsdocument achterweg laten. Volgens mij zijn bij de informatiemodellen van NEN3610 ook juist deze "UGM-modellen" een belangrijk deel van de publicatie.
Wellicht is het een goed idee om in ieder geval voor de vaststelling van dit VerStUFfingsdocument de huidige versie van het UGM toch ook even aan de expertgroep te laten zien, zodat iedereen een gevoel krijgt bij deze werkwijze.
Henri #post4
We hebben geen volledige lijst. Er vielen ons er gewoon een paar op. In VerStUFfingsdocument staat nu MACPES en dat was MACRPS voor de heeftAlsEigenaar relatie. En NRA was in 3.10 NUM. Maar er zijn er denk ik nog wel meer.
Maarten #post 16. Ton Timmermans hechtte in die vergadering veel waarde om RSD ook in een NPS-kennisgeving op te kunnen nemen. Om uit de impasse te komen stelde ik voor om een RSD dan maar van twee kanten te relateren in een kennisgeving. Immers in de nieuwe gedachte kun je uiteindelijk op koppelvlakniveau altijd nog kiezen vanuit welke kant je een RSD wilt opnemen in een kennisgeving. Echter in de vergadering van juli 2016 is dit besluit overruled zonder dat we het zelf in de gaten hadden: https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/stuf-bg-310/ishoudervan-reisdocument-niet-een-nps-stuf310-kennisgeving
Dus ik stel voor om de streep in NPSRSD weer om te zetten in een stippellijn, tenzij Ton hele goede argumenten heeft om dat niet te doen.
@Ton Timmermans: kun je even reageren op deze post?
Ruud #post 17. Inderdaad zullen op termijn de relatiegrafieken vervangen worden door de formelere UGM-diagrammen (UML) die semi-automatisch worden afgeleid uit het SIM (Semantisch Informatie Model, bijv. RSGB). Voor nu lijkt het mij zeer onverstandig om de goedkeuring van het verstuffingsdocument RSGB 3 daar afhankelijk van te maken. Dat zal de oplevering van de uiteindelijke schema's vertragen. Wel kan ik ervoor zorgen dat de StUF Expertgroep (EG) inzage krijgt in de totstandkoming van het UGM door middel van een EA-reader of iets dergelijks.
Ruud post #18. PES i.p.v. RPS is volgens mij een bewuste keuze omdat het objecttype RECHTSPERSOON niet meer bestaat in het RSGB en Handelsregister. Dat is PERSOON (PES) geworden. Prima om NRA weer terug te zetten naar NUM.
@Allen: mochten er nog meer mnemonics ten onrechte veranderd zijn. Geef het even door, dan pas ik het aan!