In de StUF specificaties wordt gesproken over "sectormodel", waarbij meestal wordt aangegeven dat een (aanvullende) specificatie kan worden beschreven of ervan kan worden afgeweken in het sectormodel.
Voor de ontwikkeling van StUF 3.02 willen we "Eindproductstandaarden" publiceren. Om toch zoveel mogelijk op het niveau van gegevensstructuren te standaardiseren, definiëren we ook horizontale Uitwisselingsgegevensmodellen (UGM) voor de semantische modellen RSGB, RGBZ en imZTC.
Een eindproductstandaard kan berichten definiëren die gebaseerd zijn op een of meerdere horizontale UGM-en, en/of een eigen vertaal UGM definiëren (zoals bijvoorbeeld voor Betalen- en invorderen een verticaal sectormodel is gedefinieerd).
Naar mijn idee zou op een aantal plekken waar nu in de specificaties wordt gesproken over "sectormodel" eigenlijk "eindproductstandaard" moeten staan en op andere plekken waar wordt gesproken over "sectormodel" zou wellicht "Uitwisselingsgegevensmodel" moeten staan. Op sommige plekken staat er "sectormodel of koppelvlak", waar dit wellicht alleen "eindproductstandaard" zou moeten zijn.
Ik zou graag weten, en vervolgens in de specificaties helder hebben, welke zaken op eindproductstandaard (EPS) worden gedefinieerd, en welke zaken (alleen) op Uitwisselingsgegevensmodel (UGM) mogen worden gedefinieerd.
Ik stel voor dit te doen op basis van de volgende uitgangspunten:
- Alleen in een UGM mag worden vastgesteld welke elementen, attributen, groepen, metagegevens en relaties mogelijk zijn op een entiteit
- Alleen in een EPS worden berichten en berichtinteracties gedefinieerd (niet in een UGM)
- Alleen in een EPS wordt vastgesteld welk elementen, attributen, groepen, metagegevens en relaties feitelijk gebruikt worden in een bericht
- Alleen in een EPS wordt bepaald welke elementen, attributen, groepen, metagegevens en relaties verplicht zijn op een specifieke plek in een specifiek bericht
- Alleen in een UGM wordt bepaald of voor een entiteit formele- dan wel materiele historie relevant is
- Alleen in een EPS wordt bepaald of elementen voor formele- dan wel materiele historie opgenomen worden in een bericht
- Alleen in een EPS (én natuurlijk in de StUF standaard) wordt fouten en meldingen gedefinieerd (niet in een UGM)
- Alleen in een EPS (én natuurlijk in de StUF standaard) wordt parameters (bijvoorbeeld sortering) gedefinieerd (niet in een UGM)
- Berichten en top-level elementen (bijvoorbeeld stuurgegevens, parameters, melding, object) zitten in een bericht in de namespace van het bericht/EPS. Elementen van een entiteit uit een UGM zitten in een bericht in de namespace van het UGM.
Ter illustratie heb ik als bijlage een lijst opgesteld met (een deel van de) voorkomens van "sectormodel" en mijn voorstel voor vertaling hiervan.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0492.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Frank,
Voordat we regels op gaan stellen over wat waar gedefinieerd wordt, denk ik dat het vooraleerst belangrijk is om die mogelijke 'waar-en' duidelijk te definiëren. Je spreekt hier over UGM en EPS, maar wat is een EPS nu precies? De term EPS komt (volgens mij) voort uit het feit dat KING de sectormodellen is gaan bestempelen als halffabricaat. We kennen al een tijdje de term koppelvlak als onderdeel van sectormodellen met een meer eenduidige definitie. Is een EPS dan een koppelvlak? En hoe verhoudt zich de term berichtcatalogus tot de term EPS?
Met het gebruik van UGM in deze context heb ik ook moeite. Het UGM is (in mijn ogen) een tussenproduct dat door KING wordt gebruikt om tot een koppelvlak te komen of tot basisschema's voor een sectormodel. Het lijkt erop dat je het sectormodel vervangt door het UGM. Maar het is toch niet verplicht om als koppelvlak- of sectormodelontwerper/-beheerder gebruik te maken van een UGM? Of gaan we dat nu wel verplicht stellen? In dat laatste geval zouden we ('implementatieonafhankelijke') eisen moeten beschrijven voor een UGM, zodat duidelijk is wanneer we spreken van een UGM.
Ik denk dat het goed is de discussie hierover te voeren voordat we verder gaan met de hier door jou gestarte discussie.
Als antwoord op de vraag van Sid hier wat uitleg van de begrippen zoals ik die zie:
Semantische informatiemodellen (afgekort als SIM) definieren de gegevens en hun onderlinge relaties die relevant zijn binnen gemeenten. Voorbeelden van horizontale semantische informatiemodellen zijn RSGB, RGBZ en imZTC. Deze modellen definieren objecttypen, de attributen binnen deze objecttypen, de relaties tussen deze objecttypen. In een semantisch informatiemodel wordt bepaald wat de (semantische, functioneel inhoudelijke) definitie is van elk objecttype, attribuut en relatie.
Uitwisselingsgegevensmodellen (afgekort als UGM) benoemen de entiteittypen zoals die kunnen worden uitgewisseld in berichten. Het doel hiervan is te zorgen dat in verschillende berichten (verschillende koppelvlakken of eindproductstandaarden) dezelfde gegevens (semantisch: dezelfde objecttypen en attributen) op dezelfde manier en in dezelfde structuur kunnen worden uitgewisseld. Het UGM is dus de set afgesproken standaardstructuren voor uitwisseling van gegevens (objecttypen).
Een uitwisselingsgegevensmodel (UGM) is gebaseerd op en borduurt verder op een of meerdere semantische informatiemodellen. In het UGM kan ervoor gekozen worden aanpassingen te doen ten opzichte van het SIM. Dit gebeurt bijvoorbeeld door het samenvoegen van verschillende objecttypen tot één entiteittype. Dit proces heet "verStUFfen".
Daarnaast wordt in het UGM technische invulling gegeven aan semantische definities t.b.v uitwisseling. Bijvoorbeeld het definieren van minimale- en maximale waarde of (regex) patroon.
Voor het UGM geldt als harde eis dat elk entiteittype, elk element en elke relatie moet verwijzen naar het corresponderende objecttype, attribuut en relatie in het SIM. Dus de semantische definitie van een entiteittype of element wordt (via de verwijzing) gehaald uit het SIM. Wanneer een entiteittype een samenvoeging is van objecttypen, moet uiteraard wel een semantische definitie in het UGM worden opgenomen, maar moet nog steeds de verwijzing duidelijk zijn naar de SIM objecttypen waar het een samenvoeging van is.
Een UGM lijkt in veel opzichten op het begrip "sectormodel" zoals dat tot nu toe is gebruikt, alleen zit in een UGM geen berichtencatalogus. Ook stel ik voor een aantal andere afspraken die wel in het sectormodel werden gemaakt, niet op te nemen in een UGM. Ik denk daarbij bijvoorbeeld aan sorteringen en foutmeldingen. Het begrip "berichtencatalogus" komt in dit begrippenkader dus te vervallen. Berichten worden alleen nog gedefinieerd in een EPS (koppelvlak).
Een UGM is net als een SIM een tussenproduct, die niet op zichzelf gerealiseerd zal worden in een gemeentelijk systeem. Het dient als grondstof voor eindproductstandaarden. Dit betekent ook dat we moeten bepalen of en in welke vorm een UGM moet worden beoordeeld, vastgesteld en gepubliceerd. Tot nu toe wordt het UGM beoordeeld in de vorm van basisentiteitenschema's, terwijl eigenlijk de (UML) modellen de kern zijn van het UGM en de basisentiteitenschema's alleen een xml-schema weergave daarvan. Een aantal eigenschappen die wel zijn vastgelegd in het UGM zijn niet zichtbaar in de basisentiteitenschema's, bijvoorbeeld of een element verplicht voorkomt in de entiteit, en worden nu dus niet meegenomen in de beoordeling van het UGM.
Een eindproductstandaard (afgekort als EPS) definieert een set samenhangende koppelvlakken. Een "eindproductstandaard" is m.i. niet wezenlijk verschillend van een "koppelvlakstandaard".
Een EPS bevat ten miste de architecturele positionering en afbakening van de betreffende koppelvlakken, de met de koppelvlakken te realiseren processen en/of ketens, de daarbij betrokken referentiecomponenten, de berichtinteracties en de definitie van berichten, hoe deze moeten worden samengesteld en hoe ze moeten worden verwerkt. Alle relevante afspraken die nodig zijn voor het eenduidig beschrijven, realiseren en testen/valideren van de koppelvlakken worden in de eindproductstandaard opgenomen. Dit kan ook in de vorm van verwijzing naar relevante stukken in het SIM, het UGM, de StUF onderlaag en de StUF protocolbindingen. Ook verwijzingen naar relevantie andere standaarden worden opgenomen (bijvoorbeeld gml, cmis, soap, digikoppeling).
Een EPS wordt als geheel vastgesteld en gepubliceerd. Het EPS geldt ook als eenheid van compliancy. Om te kunnen zeggen dat een systeem voldoet aan een standaard (EPS), moet het systeem voldoen aan alle eisen voor alle interacties en berichttypen die in het EPS zijn gedefinieerd voor de betreffende referentiecomponent. Een systeem kan dus niet voldoen aan een deel van de EPS en toch zeggen de standaard te hebben geïmplementeerd (zoals nu wel gebeurt bij de sectormodellen).
Berichten in een EPS worden opgesteld door eerst een EPS-SIM op te stellen, waarin alle relevante objecttypen, attributen en relaties die worden gebruik in de verschillende berichten zijn opgenomen. Hierin kunnen objecttypen uit een of meerdere horizontale SIM-en worden gebruikt (RSGB, RGBZ, imZTC) of uit een verticaal SIM. Wanneer relevant wordt voor het EPS een eigen verticaal SIM gedefinieerd (wanneer er gegevens nodig zijn die nog niet zijn gedefinieerd in een bestaand SIM).
Vervolgens wordt er een EPS-UGM opgesteld, met alle entiteittypen, elementen en relaties zijn opgenomen, die in de verschillende berichten worden gebruikt.
Elk entiteittype, elk element en elke relatie in een EPS-UGM moet verwijzen naar (dus overgenomen zijn uit) een corresponderend item in een horizontaal UGM dan wel een EPS-SIM.
Uitgangspunt is dat elk gegeven dat al is gedefinieerd in een horizontaal UGM in die vorm en structuur moet worden opgenomen in het EPS-UGM. Wel is een inperking ervan mogelijk, door alleen een deel van de elementen en een deel van de relaties over te nemen. Wanneer daar zwaarwegende redenen voor zijn, kan hiervan worden afgeweken, mits de mapping naar betreffende UGM entiteittypen/elementen en SIM objecttypen/attributen duidelijk en gespecificeerd is. Hiervoor geldt het pas-toe-of-leg-uit principe.
Ook kan in een EPS-UGM worden afgeweken van een horizontaal UGM door de eigenschappen van elementen en relaties aan te scherpen. Bijvoorbeeld door de kardinaliteit van elementen of relaties te wijzigen (in een bepaalde plek in een bepaald bericht kan een element juist wel of juist niet verplicht zijn.
Als laatste stap worden de berichten samengesteld. Hierbij worden entiteiten die zijn gedefinieerd in het EPS-UGM gekoppeld aan berichtstructuren. Hierbij kunnen in StUF gedefinieerde standaard structuren worden gebruikt, maar kunnen ook aangepaste structuren worden gebruikt (m.n. relevant voor vrije berichten). Bijvoorbeeld specifieke parameters toepassen in een bericht.
Naar aanleiding van de bespreking van dit RFC in de Expertgroep van 18 oktober, heb ik de uitgangspunten aangepast:
We kunnen laatste punt nog scherper krijgen met deze:
10. Een UGM kan entiteiten met (een deel van) de attributen uit een ander UGM opnemen. Elementen van een entiteit uit een UGM zitten in een bericht in de namespace van het UGM waaruit ze oorspronkelijk afkomstig zijn.
Het is belangrijk dat we in deze structuur heldere begrippen gebruiken, zodat we helder hebben via welke "tussenproducten" we uiteindelijk van het SIM (RSGB) komen tot de gewenste scherpe koppelvlakken.
Inmiddels is helder dat de eerste stap na het RSGB een UGM is. Uitgangspunt daarbij is dat RSGB volledig terug te vinden is in dat UGM, zodat alle gewenste bouwstenen voor het vervolg hieruit te halen zijn.
Welke tussenstappen er dan uiteindelijk nog gedefinieerd worden om tot de gewenste scherpe koppelvlakken te komen, wordt mij uit het "tien stappen plan" nog niet helemaal helder. Een scherp koppelvlak is bijvoorbeeld "bevraging persoonsgegevens uit gegevensmagazijn" of "synchroniseren BAG(+) gegevens naar gegevensmagazijn" of "mutatiekennisgevingen WOZ-(deel)objecten". Deze scherpe koppelvlakken leggen specificaties uiteindelijk vast in bijvoorbeeld xsd-schema's voor zover gebruik gemaakt wordt van xml. Hierbij is dus ook inzicht nodig in bijvoorbeeld zaken als tot welke niveau houden we historie bij (niet, materieel, materieel en formeel).
Inderdaad is er in ieder geval nog één tussenstap nodig tussen het UGM en deze scherpe koppelvlakken. Deze tussenstap is noodzakelijk om te waarborgen dat bijvoorbeeld voor het koppelvlak "synchroniseren BAG(+) gegevens" dezelfde berichtcomponenten worden gebruikt als voor het koppelvlak "mutatiekennisgevingen BAG(+) gegevens". Mij wordt niet helemaal duidelijk of nu met het begrip "koppelvlakstandaard" deze tussenstap wordt bedoeld. Dat lijkt mij dan een ongelukkige naam. Deze tussenstap is op zich immers nog geen standaard, maar een stap op weg naar de eigenlijke standaarden: de scherpe koppelvlakken.
Ik hoop dat we een zodanige beschrijving kunnen maken dat helder is dat de uiteindelijke standaarden waarop getoetst kan worden of systemen eraan voldoen de genoemde scherpe koppelvlakken zijn en dat verder StUF als standaard waarborgt dat al die koppelvlakken wel met elkaar samenhangen, zodat wanneer één koppelvlak gerealiseerd is het relatief eenvoudig is om ook een ander koppelvlak te maken met hergebruik van (bericht)componenten.
Ruud,
Kan jij beschrijven wat je verstaat onder berichtcomponenten?
Noem eens wat voorbeelden?
In de scherpe koppelvlakken die wij gedefinieerd hebben met de LV WOZ hebben wij bijvoorbeeld voor de relatie tussen een NPS en het verblijfsobject de berichtcomponent BG:NPSTGO-lv-kennisgeving gebruikt. Een dergelijke berichtcomponent kan voorkomen in diverse dienstberichten of synchronisatieberichten en daarmee in diverse koppelvlakspecificaties.
Vergelijkbaar is BG:NPS-lv-kennisgeving waarmee we steeds op dezelfde manier persoonsgegevens in een bericht gebruik zowel in koppelvlakken voor de LV WOZ als in andere WOZ-koppelvlakken.
Tijdens de StUF Expertgroep van 15 november 2017 is besloten de werkwijze van de Nieuwe Aanpak uit te werken in een separaat document alvorens de in RFC0492 voorgestelde wijzigingen kunnen worden uitgevoerd.