Binnen StUF 3 is het mogelijk om vraagberichten samen te stellen met daarbinnen een selectie op een supertype. Het is echter niet mogelijk om een vraag te stellen op basis van een selectie op een van de subtypen van dit supertype. Binnen StUF 2 wordt geen gebruik gemaakt van (selecties op) supertypen maar worden altijd de gerelateerde entiteiten bevraagd. Hierbij kunnen in de vraag selecties op meerdere soorten gerelateerden (bv een zakelijk gerechtigde als PRS of NNP) worden opgenomen en bij het beantwoorden van deze vraag worden die selecties dan als een logische OR behandeld.
Naast een functionele verrijking levert dit StUF 3 mechanisme ook enkele beperkingen op. Daarnaast is er een acuut probleem doordat bepaalde berichten momenteel niet getransformeerd kunnen worden van StUF 3 naar StUF 2 en vice versa. Enkele voorbeelden hiervan zijn:
- Binnen StUF 3 is het niet mogelijk om vragen samen te stellen waarbij een selectie gewenst is op slechts één van de subtypen die behoort bij het supertype. Daarnaast zijn de selectiecriteria beperkt tot de elementen die opgenomen zijn bij het supertype en kan niet geselecteerd worden op elementen van een of meerdere van de subtypen.
- Een StUF 2 vraag waarbij gevraagd wordt om zaken met als initiator een PRS met een bepaald BSN kan in StUF 3 niet gesteld worden. In StUF 3 zal een soortgelijke vraag ook resultaten met als initiator een NNP met de betreffende nummer als Fi-nummer opleveren.
Mapping
In het mappingsdocument voor BG staat in het tabblad ‘Geen mapping’ de volgende regel waarnaar verwezen wordt vanuit de KOZ mapping (hier zit zo’n supertype in onder de relatie heeftAlsVoornaamsteZakelijkGerechtigde): SUB - Supertype, vraagberichten voor het supertype worden niet gemapt. Op dit moment kan een vraag met de (bijvoorbeeld) voornaamste zakelijk gerechtigde als selectiecriterium dus niet gemapt worden tussen StUF 3 en StUF 2. Binnen het ZKN 3.10 sectormodel zijn er ook een aantal van dit soort situaties (bijv. zaak initiator).
Aangezien een gemeente niet op één moment voor alle applicaties overstapt van het gebruik van StUF 2 naar StUF 3 (sterker nog, bij veel gemeente praten we hier over een periode van jaren), kunnen gedurende die gehele periode bepaalde vraagberichten niet uitgewisseld worden tussen applicaties die verschillende StUF versies ondersteunen. Dit lijkt ons een onacceptabele situatie.
Mogelijke oplossingsrichting
Een mogelijke oplossingsrichting is om in de sectormodellen BG 3.10 en ZKN 3.10 op de plekken waar supertypen gebruikt worden, ook een mogelijkheid te bieden om op de concrete subtypes te selecteren. Dit lost niet alleen het maping issue op maar is tevens een oplossing van de huidige beperkingen binnen StUF 3.
De beperking in StUF3 lijkt mij minder ernstig dan hierboven wordt voorgesteld. Als een vraag wordt gesteld voor een bepaald bsn binnen het supertype SUB, dan is de kans niet zo groot dat er ook een NNP wordt teruggegeven en als toch een bsn wordt teruggegeven, dan is dit in het antwoordbericht zonneklaar en kan de vraagsteller hierop filteren. Hetzelfde geldt bij gebruik van de andere selectiecriteria binnen het supertype. De belangrijkste vraag lijkt mij daarom of de selectiecriteria binnen het supertype voldoende functionaliteit bieden, want deze functionaliteit is minder dan bij een selectie op een subtype.
Daarnaast speelt inderdaad de vraag of de mapping tussen bg0310 en bg0204 zou moeten worden uitgebreid met ook een mapping van supertypen naar de corresponderende subtypen binnen bg0204.
Ik ben benieuwd wat anderen hiervan vinden.
Dit issue is niet 100% compatible op te lossen.
De volgende oplossing (best effort) wordt door ons voorgesteld:
1. Ten aanzien van het verschil in functionaliteit tussen bg0310 (selecteren op supertype) en bg0204 (selecteren op subtype), wordt de voorgestelde werkwijze overgenomen:
Indien binnen StUF 3 een vraag gewenst is met een selectie op een subtype van de gerelateerde entiteit (bv: Zaken met een bepaalde persoon als initiator), dan wordt eerst een vraag gesteld met dit subtype als fundamentele entiteit (bv: persoonsvraag). Op basis van het antwoord op deze laatste (persoon) vraag, wordt dan de eigenlijke (zaak) vraag gesteld maar nu met de selectiecriteria binnen het supertype die verkregen zijn uit de eerste (persoon) vraag.
2. Ten aanzien van het niet kunnen mappen van een StUF 3 vraag met daarin een selectie op een gerelateerd supertype, wordt een erratum voorgesteld voor de mapping tussen StUF 2 en StUF 3:
Voorgesteld wordt om in de selectie in de StUF 3 (BG en ZKN) vraag het (optionele) objecttype op te nemen. Op basis van de aanwezigheid van dit objecttype, kan de StUF 3 vraag gemapt worden op een StUF 2 vraag en kan een StUF 2 vraag gemapt worden op een StUF 3 vraag. Indien in de StUF 3 vraag het objecttype niet is opgenomen, dan wordt een default waarde verondersteld (bv bij initiator relatie van een zaak wordt de default vastgesteld op NPS). Deze default moet voor iedere betreffende relatie in de mapping documentatie worden opgenomen.
Een alternatieve en nog pragmatischer oplossing is om voor iedere situatie waarbij een supertype binnen een StUF 3.01 sectormodel wordt gemapt op subtypen binnen een StUF 2.04 sectormodel, altijd een expliciete keuze te maken voor het subtype waarop gemapt wordt. Deze keuze moet dan opgenomen worden in het mappingdocument (spreadsheets).
Volgens mij is hier alleen nog sprake van een voorstel van John Rooijakkers. Eigenlijk zie ik 3 voorstellen van hem voor een oplossing. Het is niet uit het forum op te maken wat nu het voorstel is. Lijkt me verstandig om deze in de stuf expertgroep te bespreken.
De StUF Expertgroep van 20 maart 2013 heeft besloten dit erratum (ERR245) af te sluiten.
Post gesloten.