Als developer wil ik zaakobjecten kunnen defineren

[rubenvdlinde]

Context
Naar aanleiding van een gesprek met @sergei-maertens op slack. Op dit moment zijn zaakobjecten de prefferd way om zaken te koppelen aan externe registers.

Probleem
Dat betekend voor de concrete casus factuuradres (begraven/hoorn) dat ik als developer zou verwachten dat ik een zaakobject van het type 'adres' moet aanmaken met verwijzing naar het BAG op een zaak van type begraven. Dat kan ook gewoon zaak object creatie ondersteund dit. En e.a. is verder uitgewerkt in (zaak gericht werken)[https://www.gemmaonline.nl/images/gemmaonline/f/f6/20190620_-_Zaakgericht_werken_in_het_Gemeentelijk_Gegevenslandschap_v101.pdf] 4.3.

Ik zou echter ook verwachten dat een zaaktype zichzelf beschrijft, met andere woorden dat ik het zaaktype "begraven" kan ophalen en daar zie dat ik een ZaakObject van het type adres genaamd "factuur adres" nodig heb om voorbij status X van de zaak begraven te komen, net zo als dat dat is ingeregeld voor InformatieObjecten (documenten) en eigenschappen.

Dat is echter niet het geval, sterker nog zaakobjecten worden überhaupt niet beschreven in de Catalogus Api. Hetgeen betekend dat ik geen plek heb om vast te leggen welke zaakobjecten ik bij een type zaak verwacht. Dit lijk een omissie te zijn gezien we het voor de overige data wel doen (informatieobjecten, eigenschappen, producten, status, besluiten, belanghebbende etc etc).

Gevolg hiervan is dat een (G)ZAC zelf een koppeltabel zou moeten bijhouden over wat er in een zaaktype thuishoort (bij Den Haag en Utrecht is dit nu opgenomen in de ruleengine) waarmee data decentraal wordt en niet meer deelbaar is tussen applicaties (bijvoorbeeld meerdere (G)ZAC's op één ZGW zaak register. Met andere woorden dit levert precies op wat we proberen te voorkomen met de ZGW apis, decentrale data, dialecten en applicaties die niet meer kunnen samenwerken.

Het maakt het inrichten van een GZAC aan de hand van ZGW op dit moment ook technisch onmogelijk, bij het aanmaken of bewerken van een zaak is immers niet bekend wel zaakobjecten worden verwacht dan wel vereist zijn. Er kan dus geen UI worden gegenereerd voor de gebruiker om deze aan te leveren.

Het leid ook tot allerlei vreemde tegenstrijdigheden, we controleren op de Zaken API hard of een bepaald document is geupload voordat we een status wijziging accepteren maar controleren niet of een begrafenis überhaupt een overledene bevat of een verhuizing een adres. Sterker nog het is technisch prima mogelijk om iemand te verhuizen naar een niet-natuurlijk persoon uit het kvk of iemand te rusten te leggen op een spoordeel of openbare ruimte (we controleren alleen maar of een object bestaat, niet wat het is). Dit opent natuurlijk de route voor afhandeling hell bij taak applicaties.

Oplossingsrichting

• ZaakObjecten opnemen in de Catalogus API
• ZaakObjectZaak opnemen in Catalogus API met daarin meta data over het ZaakObject in context tot de specifieke zaak (vanaf welke status verplicht)
• In ZaakObject op de Zaken API een verwijzing opnemen met welk zaakobject het hier betreft
• In de zaken API valdieren op ZaakObjecten en statusen (conform informatie objecten)

Note*
@michielverhoef deze user story grenst aan bug, op dit moment zien we al dat er omheen wordt gewerkt en dat het onwenselijke inrichting oplevert. zou je hem willen classificeren als PRIO Hoog

[joeribekker]

Precies voor dit is de Objecten en Objecttypen API: https://objects-and-objecttypes-api.readthedocs.io/en/latest/

Je wil het lijstje van mogelijke objecttypen niet opnemen in de Catalogi API of enige andere standaard want het is ALTIJD out-of-date en incompleet.

[michielverhoef]

Zaakobject als verwijzing naar de catalogus van de Objectenregistratie is ook wat in #1848 gevraagd is en meegenomen wordt in de nieuwe versie van de Catalogi API. Het plan is dit najaar een nieuwe versie van de API's beschikbaar te hebben.

[rubenvdlinde]

Even dingen uit elkaar trekken, wat ik niet voorstel is om objecten typen te definiëren in de catalogus. Wat is voorstel is om de koppeling met rand voorwaardelijke objecttypen op te nemen (ofwel wat verwacht ik bij een zaak).

Voor het omschrijven van een zaaktype is de Catalogi API de bron, niet Objecten en Objecttypen API. Sterker nog dat kan niet want veel van de externe registers staan niet in Objecten en Objecttypen API (voorbeeld van hier bijvoorbeeld ook niet -> BAG). Dus zou dit zeker niet daaraan ophangen.

[michielverhoef]

Het idee achter Zaakobject is: De objecttypen van objecten waarop een zaak van het ZAAKTYPE betrekking kan hebben.

Wat mij betreft is dit een koppeltabel met verwijzingen. Dus als het een object in de BAG is staat er een verwijzing naar de BAG in, is het iets in het Handelsregister dan een verwijzing naar het Handelsregister etc.

https://www.gemmaonline.nl/index.php/Imztc_2.2/doc/objecttype/zaakobjecttype

[rubenvdlinde]

@michielverhoef eens, maar dan zou ik dus verwachten dat ergens staat beschreven welke zaakobjecten ik op een zaak van een bepaald type kan verwachten.

[michielverhoef]

Zaakobjecttype zit nu nog niet in de Catalogi API maar komt daar dus wel in dit najaar :-)
Bij het opvragen van een Zaaktype komen dan de relevante Zaakobjecttypen mee.

Aan alleen een url zie je nog niet heel veel dus een omschrijving is wel handig denk ik.
Volgens ImZTC 2.2 https://www.gemmaonline.nl/index.php/Imztc_2.2/doc/objecttype/zaakobjecttype heeft een Zaakobject een relatieomschrijving, misshcien dat dat past. https://www.gemmaonline.nl/index.php/Imztc_2.2/doc/attribuutsoort/zaakobjecttype.relatieomschrijving

[CMasselink]

De wens om in een zaaktype te definiëren dat bepaalde zaakobjecten bij een zaak horen, snap ik. Lijkt me een goede toevoeging.
Vanuit Utrecht hebben we ook al gewerkt aan een voorstel om bij een zaakobject (behorende bij de zaak) ook de objectdefinitie (uit bijv. de objecttype registratie) vast te kunnen leggen.
Het implementatievoorstel hebben we al maar gingen een aantal collega's van mij nog wat verder toetsen. Het idee was om daarna een userstory met het voorstel te maken. Ik zal eens vragen hoe het daarmee staat.

[rubenvdlinde]

Oftopic, maar de vraag daar is wat mij betreft wel of je echt een objecttype api tot standaard wil slaan, daar zijn gewoon al dingen voor op internationaal vlak. (bijvoorbeeld, ik roep het nog maar eens schema.org) die je gewoon kan extenden zonder een api te ontwikkelen.

Ik zie veel liever dat we aansluiten bij bestaande internationale/industrie standaarden dan dat we zelf een API gaan ontwerpen die objecten beschrijft. Dat is echt klassiek z'n probleem waar iedereen in de wereld die wat met REST doet al eens tegen aangelopen is. En waarbij ik echt vind dat we home grown moeten bestrijden (hoe goed de huidige api ook is overigens, dit is een princiepe ding).

We hebben gewoon een relatief klein draagvlak als gemeenschap, en moeten veel meer toegaan naar standaarden (en eventuele open source oplossingen) aanwijzen dan ze zelf bouwen wat mij betreft. En als we dan al zelf iets opgooien heel strak een standaard volgens ipv van zelf gaan praten over wat er in een object huis hoort.

Dan kunnen we veel gerichter wel de dingen harder door ontwikkelen die hard aandacht, tijd en geld nodig hebben zoals ZGW en Open Zaak.

[CMasselink]

Even een update omdat ik nog terug zou komen op ons implementatievoorstel:
Wegens vakantie van een aantal collega's moet ik het antwoord over de interne afstemming nog even schuldig blijven maar in het kort komt het er op neer om zaakobject uit te breiden met: objectTypeOverigeDefinitie
In dit attribuut kan indien bij objectType de waarde 'overige' is gekozen, een URL naar het schema van het object opgenomen worden.

[CMasselink]

Het implementatie voorstel heb ik in #1871 beschreven, inclusief samenhang met deze userstory + de userstory van Rotterdam

[michielverhoef]

Zaakobjecttypen is opgenomen in de nieuwe versie van de Catalogi API: https://catalogi-api.test.vng.cloud/api/v1/schema/#tag/zaakobjecttypen

[michielverhoef]

Kan gesloten worden wanneer #1848 ook geimplementeerd is.