Hoe leggen we relatie tussen zaak en objecten?

[jeffreygortmaker1]

Acceptatiecriteria

• moet getest kunnen worden via testsuite
• goede documentatie

Vraag uit architectuurdocument.

Omschrijving:
Objecten worden in het RGBZ aan een zaak gerelateerd dmv. “Zaakobject”: “een Object waarop de zaak betrekking heeft”. In theorie kun je hier veel kanten mee op. In de praktijk zal het gebruik hiervan beperkt zijn tot voornamelijk basisregistratieobjecten. In een gegevenslandschap moeten veel meer soorten objecten aan een zaak gerelateerd kunnen worden. De zaak vormt immers de sleutel om deze bij elkaar te kunnen houden. Denk bijvoorbeeld aan verleende subsidies, uitgegeven marktplaatsen, grafrechten, etc. Vroeger werden deze objectenregistraties bijgehouden in het processysteem en lag daar impliciet de relatie tussen de zaak en deze objecten. Het Gegevenslandschap vraagt om een andere, meer integrale benadering. Het is daarom de vraag of de relatie zaak – object zoals gedefinieerd in het RGBZ (zaak heeft betrekking op object) hiervoor voldoende is genoeg is. Afgeleide vraag hiervan is het in operationele zin aan elkaar relateren van objecten in diverse bakjes aan een zak in een ZRC.

dit is een uitbreiding van #166.
naar andersoortige objecten

[ArjanKloosterboer]

In theorie kun je hier veel kanten mee op. In de praktijk zal het gebruik hiervan beperkt zijn tot voornamelijk basisregistratieobjecten. In een gegevenslandschap moeten veel meer soorten objecten aan een zaak gerelateerd kunnen worden.

De tweede zin is m.i. in tegenspraak met de derde. Essentie is m.i. dat er allerlei soorten objecten aan een zaak gekoppeld moeten kunnen worden. Het RGBZ onderkent dit reeds: (Zaak)Objecten v.w.b. in het RSGB onderkende objecttypen en Overig zaakobject voor andersoortige objecttypen. Interessant is in de Gegevenslandschaparchitectuur of we met een implementatie van (Zaak)Objecten beide kunnen realiseren. Het lijkt mij van wel.

In een gegevenslandschap moeten veel meer soorten objecten aan een zaak gerelateerd kunnen worden. De zaak vormt immers de sleutel om deze bij elkaar te kunnen houden.

De zaak is één van de sleutels om iets bij elkaar te houden: alles wat met de behandeling van een aanleiding te maken heeft (insteek: uitvoering van een bedrijfsproces). Minstens even belangrijke sleutels zijn al die diverse objecten: wat is er allemaal gebeurd (cq. welke bedrijfsprocessen zijn er uitgevoerd) rondom een persoon, een pand, een brug etcetera (insteek: levensloop van het object).

Het is daarom de vraag of de relatie zaak – object zoals gedefinieerd in het RGBZ (zaak heeft betrekking op object) hiervoor voldoende is genoeg is. Afgeleide vraag hiervan is het in operationele zin aan elkaar relateren van objecten in diverse bakjes aan een zak in een ZRC.

Mijn voorstel is om de relatie Zaak - Object te benutten voor alle soorten objecttypen, mits een dergelijk object(type) in een registratie zit waar een API op zit. Dit strookt volledig met de bedoeling van deze relatie in het RGBZ. Aangezien een dergelijk Object een stabiele factor is (een persoon leeft 80 jaar, een gebouw gaat soms honderden jaren mee), een zaak slechts een tijdelijke relevantie heeft en - vooral - een zaak een verandering of gebruik van een object beschrijft, verwijst Zaak naar Object en niet omgekeerd.

[sergei-maertens]

Deze generieke relatievorm leidde ook tot onze designkeuze van hoe om te gaan met polymorfisme, omdat zaken naar andere objecten kunnen wijzen. Dit is ook al in de API spec opgenomen in de eerste of tweede sprint. Ik denk dat daarmee dit issue meteen gesloten kan worden als 'opgelost'.

Zie API spec en dan vooral de key type.

[sergei-maertens]

Besluit is genomen in #166, wat een vergelijkbaar M2M model is.

Concreet: er wijzigt niets ten opzichte van huidige API spec.

[ArjanKloosterboer]

@sergei-maertens, wil je dat van dat polymorfisme ook opnemen in de design-choices.

[sergei-maertens]

@ArjanKloosterboer staat er al een aantal weken, zie Omgang met polymorfe resources

[jeffreygortmaker1]

ik heropen deze. is nog een vraag die ik heb in het architectuurdocument. Moeten we bespreken.
Omgaan met polymorfe resources is één aspect van de vraag. Vraag is echter breder.

Stel we hebben een willekeurig domeinmodel, zeg een informatiemodel subsidies. Daarin zitten X objecten. Relateer je die dan allemaal aan een zaak? Of sommige objecten wel en anderen niet?

[joeribekker]

Met @ArjanKloosterboer ook deze besproken.

In principe willen we het ORC (Overige Registraties Component) gaan inzetten als shim die gebruikt kan worden als er nog geen APIs beschikbaar zijn voor deze data. Dat ziet er als volgt uit:

• Relatie naar bestaande (interne/externe) bron (API service): (ZRC) Zaak --> (BAG) Pand
• Relatie naar nog niet bestaande bron (bijv. Excel, SOAP-service of eigen database): (ZRC) Zaak --> (ORC) OverigGebouwdObject

De gemeente wordt dan verantwoordelijk om bij het aanmaken van een Zaak dat betrekking heeft op een OverigGebouwdObject, zelf dit OverigGebouwdObject aan te maken in het ORC (via de API). Als er op een later moment een "echte" API komt waar al deze OverigGebouwdObjecten in zitten, dan kan deze API gebruikt worden en dat deel van het ORC worden uitgefaseerd.

[joeribekker]

Ik haal overleg even weg omdat het mij nu wel helder is. Mocht een van de andere stakeholders nog verder willen overleggen, dan moeten ze het label er weer bij zetten.

[ArjanKloosterboer]

Wat we ook besproken hebben zijn api's cq. registratiecomponenten voor zaakbetrokkenen zijnde natuurlijke en niet-natuurlijke personen en vestigingen ('klanten'). Volgens mij hebben we besproken dat we die niet scharen onder de ORC maar onder een andere component. De ORC zou dan hernoemd kunnen worden naar de (Overige) Objectenregistratiecomponent. Oftewel de implementatie van het objecttype OBJECT in het RGBZ. Mooi!
En die 'betrokkenencomponent', daar zouden we nog even verder over nadenken, meen ik. Als aanzet tot een 'klantencomponent'.
En dan hebben we ook nog MEDEWERKER en ORGANISATORISCHE EENHEID als subtype van Betrokkene. Ook maar 'even' een apart componentje, 'shim'?
En verder hebben we nog het gegevensgroeptype 'Ander zaakobject' bij ZAAK. Dat is bedoeld voor objecten bij een zaak die niet vallen onder OBJECT. Achtergrond daarvan is dat het bedoeld is voor objecten waarvan de informatie niet in een informatiemodel is vastgelegd. M.i. hoeft dankzij de ORC dit gegevensgroeptype niet opgenomen te worden in de Zaken-API (ZRC). De kracht van die ORC is dat we daarin voor elk gewenst objecttype een resource kunnen maken. Dus ook voor objecttypen die niet expliciet genoemd zijn als subtype van OBJECT. Anders geredeneerd: genoemde gegevensgroep betreft een soort van platgeslagen relatie naar een objecttype waarvan de registratie onbekend is. Welnu, die maken we bekend in de ORC. Klus geklaard!

[jeffreygortmaker1]

OK, als we het eens zijn, hoe ziet het plaatje er dan uit voor onderstaande concrete casus ivm
subsidieaanvraag en toekenning?

aanvrager is contactpersoon Janssen van vestiging kerkplein van bedrijf grootwarenhuis.
behandelaar voor de eerste 2 statussen is pietersen, afdeling subsidies, gemeente turfbrug
behandelaar voor status 3 en 4 is willemsen, regionale uitvoeringsdienst hndhaving.

De subsidie betreft een EVENEMENT met de naam Braderie Kerkplein
De locatie is het kerkplein, maar enkel het noord-oostelijke deel daarvan, bekend als de Evenementenhoek

Er is een subsidie van €5000 toegekend uit het potje stimulering locale feestelijkheden.
De subsidie is specifiek voor de activiteiten Ganzenrijden en de Kids-run. Ganzenrijden omdat het op de lijst met lokale folkhistorische tradities staat en de Kids-run omdat het een ACTIVITEIT is die bijdraagt aan het gemeentelijke speerpunt Gezondheidsverbetering bij de jeugd.
Voor de activiteit Buurttouwtrekken was ook subsidie aangevraagd, maar die is afgekeurd omdat het subsidiepotje Buurtversterkende activiteiten uitgeput is.

Naast deze subsidie is ook één van de gemeentelijke Toiletwagens, toiletwagen A toegewezen aan dit festijn.
Er is gecontroleerd gedurende het evenement. Eénmaal om te kijken of het aantal deelnemende standhouders boven de 100 lag (voorwaarde voor toekennen subsidie) en na afloop hebben de organisatoren ter verantwoording het aantal deelnemers van de kidsrun moeten doorgeven, waarna is gekeken of dit overeenkwam met het aantal uit de subsidieaanvraag..

De vraag is nu: hoeveel objecten registreren we bij de zaak en waar?
Ik gok dat we nog wat discussiepuntjes vinden.. :-)

[jeffreygortmaker1]

iets voor jou, @ArjanKloosterboer ?
is van breder belang dan enkel ZDS..

[ArjanKloosterboer]

Leuke case. De kernvraag is m.i. deze (eerder gesteld door Jeffrey):

Stel we hebben een willekeurig domeinmodel, zeg een informatiemodel subsidies. Daarin zitten X objecten. Relateer je die dan allemaal aan een zaak? Of sommige objecten wel en anderen niet?

De relatie heet 'ZAAK betreft OBJECT' met als definitie "Het OBJECT waarop de ZAAK betrekking heeft." De vraag is dan: wat bepaalt dat een zaak betrekking heeft op een object? Iets vergelijkbaars is in de Selectielijst opgenomen: het procesobject. Daarin wordt dit omschreven als het object waarop de verandering effect heeft die met het proces teweeg gebracht wordt. Dat strookt m.i. met hoe de zaak-object-relatie bedoeld is. Ik zou daaraan toe willen voegen '... en dat van domeinoverstijgend belang is'. Een zakenregistratie is immers een kernregistratie, domeinoverstijgend. Binnen een domein weet je meer cq. wil je meer weten. Bij de behandeling van een verbouwvergunningaanvraag is het te verbouwen pand het zaakobject, er wordt immers vergunning verleend voor het veranderen van het pand. Bij een 'huwelijkszaak' (jaja, er moeten termijnen bewaakt worden) zijn de huwelijkspartners de zaakobjecten: zij krijgen een relatie.
En dan de evenementensubsidiezaak. Wat verandert er als gevolg hiervan? Het evenement! Dat heeft door de verleende subsidie meer geld tot z'n beschikking. Dat allerlei subsidiepotjes dientengevolge leger zijn, dat is een gevolg hiervan maar niet de primair beoogde verandering en is niet domeinoverstijgend. Alles draait om het evenement. En dat is ook precies de bedoeling van het object bij de zaak: de satéprikker: wat speelt er allemaal rond een evenement? Daar zal vergunning voor aangevraagd zijn, daar moeten voorzieningen getroffen worden, daar wordt toezicht op gehouden, etcetera. Die satéprikker brengt als het ware de levenscyclus van het evenement domeinoverstijgend in beeld.
Wat nu met al die andere objecten in je case? Simpel: die leven binnen het domein i.c. subsidieverstrekking. Dus informatie daarover wordt beheerd in een domeinspecifieke registratie. Het evenement is de inhoudelijke linking-pin met domeinoverstijgend inzicht. Qua proces is dat de zaak.
Tot zover mijn analyse. Reacties?

[TCIMEddy]

Naar architectuurbord

[adgerrits]

Als ik lees wat de bedoeling is zie ik steeds meer de noodzaak om te gaan werken met linked data als mechanisme om elementen te relateren. De scope is hier 'zaken' en 'zaakobjecten' maar bij veel elementen zijn er natuurlijk nog veel meer relaties. Die je ook graag, en op een vergelijkbare manier, in beeld wilt kunnen krijgen. Dit nav "Reacties?".

[AHNRoxit]

(Ik ga nu een vraag stellen bij een closed issue. Ik weet niet of dat de bedoeling is of wat daarmee gebeurt, maar dat ga ik dan wel merken :-))

Begrijp ik het goed dat het antwoord op de vraag van Jeffrey over het evenement is:
De zaak heeft 1 zaakobject. Dit zaakobject is een verwijzing naar het evenement dat is geregistreerd in een domeinspecifieke registratie.

[sergei-maertens]

@AHNRoxit beter om de volgende keer een nieuwe issue te maken, nu worden enkel eerdere participants genotificeerd hiervan (en geloof dat een aantal mensen ook e-mail notificiations uit heeft staan).

De zaak heeft 1 zaakobject. Dit zaakobject is een verwijzing naar het evenement dat is geregistreerd in een domeinspecifieke registratie.

In de API is dit nu uitgewerkt als een resource ZaakObject. Deze omvat de relatie tussen een zaak en een object, waarbij het object-attribuut dus een URL-referentie is. In dit geval zou dat een referentie zijn naar een evenement (ondanks dat deze nog niet in een API gedefinieerd is/een onbekend type is).

De bekende types staan in de enum bij ZaakObject, en nieuwe types doorlopen idealiter het volgende proces:

1. Design van de API waarin ze leven
2. Standaardisering van de API specoficitatie, zodat alle providers/clients weten hoe dit type er uitziet
3. Toevoegen van het type aan de enum, zodat het nu ook in de zaken-api bekend is.

De laatste stap is super-eenvoudig, de eerste twee stappen hebben wat meer voeten in de aarde, en dit is ook een proces wat we nog moeten gaan ondervinden. Op dit moment zijn de types uit RGBZ 2 ondersteund, en omdat ze nog geen RESTful APIs hebben, is er een mechanisme toegepast beschreven in https://zaakgerichtwerken.vng.cloud/themas/achtergronddocumentatie/zgw-api-landschap-grenzen om hier mee om te kunnen gaan.