Als gebruiker wil ik zaakobjecten kunnen koppelen conform het zaaktype plus zaakobjecttypen

[MarcoKlerks]

… zodat de aan de zaak gekoppelde (zaak-)objecten overeenkomen met wat op het zaaktype geconfigureerd is. Dit helpt om ervoor te zorgen dat alleen relevante en alle relevante (zaak-)objecten worden gekoppeld.

Let op! User story #1846 is voorwaardelijk voor deze!

Bij het aanmaken van een ‘zaak’ moet de gebruiker een ‘zaaktype’ koppelen. Als de gebruiker een ‘zaakobject’ wil aanmaken, dan moet de gebruiker:

• deze aan een ‘zaak’ koppelen, én
• deze aan een ‘zaakobjecttype’ koppelen die op het ‘zaaktype’ geconfigureerd is.,
• deze aan een ‘object’ koppelen dat gekoppeld is aan een ‘objecttype’ dat aan het ‘zaakobjecttype’ gekoppeld is.

Dit vraagt om een volledig redesign en rework van de huidige zaakobject-services. Er zal dus goed nagedacht moeten worden over backward compatibility of migratie. De nieuwe zaakobject-services zijn wel flexibeler en minder onderhoudsgevoelig, doordat de enumeratie (‘objectType’) vervangen wordt door een verwijzing en er niet op grond van de gekozen optie in de enumeratie andere velden (onder ‘objectIdentificatie’) ondersteund hoeven te worden.

[hdksi]

Dit vraagt om een volledig redesign en rework van de huidige zaakobject-services. Er zal dus goed nagedacht moeten worden over backward compatibility of migratie. De nieuwe zaakobject-services zijn wel flexibeler en minder onderhoudsgevoelig, doordat de enumeratie (‘objectType’) vervangen wordt door een verwijzing en er niet op grond van de gekozen optie in de enumeratie andere velden (onder ‘objectIdentificatie’) ondersteund hoeven te worden.

Goed voorstel. Ik zie echter niet meteen de noodzaak voor een volledig redesign en rework. Volgens mij kan dit prima opgelost worden door in de Catalogi API de uit het RGBZ-bekende resource zaakobjecttype toe te voegen (zie ook #1846) en de enumeratie objecttype binnen brondatumArchiefprocedure te vervangen door een vrij tekstveld of een attribuut toe te voegen om te verwijzen naar een willekeurig objecttype.

[michielverhoef]

de enumeratie objecttype binnen brondatumArchiefprocedure te vervangen door een vrij tekstveld of een attribuut toe te voegen om te verwijzen naar een willekeurig objecttype.

Zaakobjecttype staat al op de nominatie meegenomen te worden in de nieuwe versie van de Catalogi API en deze aanpassing neem ik ook gelijk mee.

[CMasselink]

@MarcoKlerks @hdksi bij deze de userstory naar aanleiding van ons gesprek van vrijdag: #1871

[michielverhoef]

De resource Zaakobjecttype isopgenomen in het ontwerp van de Catalogi API: https://app.swaggerhub.com/apis/michielverhoef/Catalogussen_API/1.2.0-alpha#/

[MarcoKlerks]

De resource Zaakobjecttype isopgenomen in het ontwerp van de Catalogi API: https://app.swaggerhub.com/apis/michielverhoef/Catalogussen_API/1.2.0-alpha#/

Top! Maar hiermee heb je in feite niet deze user story opgelost, maar #1846 . Deze user story vergt een aanpassing van de Zaken API, zodat jouw wijzigingen in de Catalogi API ook juist gebruikt worden bij het creëren / updaten van zaken en zaakobjecten.

Ik denk dus dat je in de backlog #1846 op Done wil zetten en deze user story weer terug op In Progress.

[michielverhoef]

Je hebt gelijk, ik had al zo'n idee dat ik het verkeerde issue te pakken had.

[ArjanKloosterboer]

Als gebruiker wil ik zaakobjecten kunnen koppelen ...

M.i. koppel je geen zaakobjecten maar koppel je objecten waarbij zaakobjecten de 'koppeltabel' is oftewel de manier waarmee je de koppeling legt. M.i. verstandig om dit goed uit elkaar te houden.
Zie verder mijn opmerking over het gegevensmodel en over te koppelen soorten objecten bij issue #1846

[michielverhoef]

In de resource Zaakobjecten (Zaken API) moet een verwijzing naar het Zaakobjecttype (Catalogi API) worden opgenomen.

Zaakobjecttype is opgenomen in de Catalogi API 1.2-alpha https://catalogi-api.test.vng.cloud/api/v1/schema/#operation/zaakobjecttype_read

[CMasselink]

@michielverhoef Welke URL verwijzing moet er gemaakt worden als het objecttype wel uit RGBZ/RSGB komt, bijvoorbeeld een pand? Gezien het een verplicht veld is...

[michielverhoef]

Hmm, het vervelende is dat objecttype een soort van zaakobjecttype is, alleen met beperkingen.

Het doel van Zaakobjecttype in de Catalogi API was de volledigheid van zaakregistraties beter te kunnen garanderen (zie #1846). Met alleen een veld kan dat niet afgedwongen worden, zelfs al is dat veld verplicht. Want als het zaakobject niet aangemaakt wordt is er geen controle mogelijk.

Als we zaakobjecttype in de Catalogi API gaan regelen worden de velden objectype en objecttypeOverige overbodig volgens mij.
Want uit het Zaakobjecttype blijkt dan wel om welk Objecttype het gaat.

[CMasselink]

Ja volgens mij zouden de attributen Objecttype, ObjecttypeOverige en ObjectTypeOverigeDefinitie uit de zaken api verplaatst moeten worden naar zaakobjecttype in de Catalogi API.
Als daar dan dezelfde methodiek gebruikt wordt als nu in de Zaken-API, loop je niet tegen de beperking aan dat je eigenlijk niet goed kan verwijzen naar RSGB objecttypen (in ieder geval niet naar een schema).

[michielverhoef]

Dit moet in ieder geval:

• In de Zaakobject resource (Zaken API) moet een url verwijzing naar Zaakobjecttype (Catalogi API) komen

Om de nieuwe versie van de Zaken API toch backwards compatible te houden stel ik voor:

• Objecttype, ObjecttypeOverige en ObjectTypeOverigeDefinitie worden optioneel en deprecated.

https://catalogi-api.test.vng.cloud/api/v1/schema/#operation/zaakobjecttype_read
@CMasselink Objecttype staat al in de resource Zaakobjecttype. Is het dan nog nodig om ObjecttypeOverige en ObjectTypeOverigeDefinitie op te nemen?

[CMasselink]

Dit moet in ieder geval:

In de Zaakobject resource (Zaken API) moet een url verwijzing naar Zaakobjecttype (Catalogi API) komen

Eens.

https://catalogi-api.test.vng.cloud/api/v1/schema/#operation/zaakobjecttype_read
@CMasselink Objecttype staat al in de resource Zaakobjecttype. Is het dan nog nodig om ObjecttypeOverige en ObjectTypeOverigeDefinitie op te nemen?

Eerst even zorgen dat we geen dingen door elkaar halen:
Objecttype in de catalogi API == een URI -> verwijzing naar het objecttype (vermoedelijk dus naar de definitie)
ObjecttypeOverige in de zaken API == string -> beschrijving in tekst van het objecttype overige (lantaarnpaal bijvoorbeeld)

Gegeven onderstaande afbeelding:
Objecttype uit de catalogi API zou dubbel zijn met ObjectTypeOverigeDefinitie.url
De vraag is: wat doe je met ObjectTypeOverigeDefinitie.schema en ObjectTypeOverigeDefinitie.Objectdata? Als die nodig zijn om op een goede manier de schema definitie te kunnen ophalen, zullen die attributen waarschijnlijk wel verplaatst moeten worden naar de catalogi API.

Objecttype (de URL) in de catalogi API zou denk ik zoals eerder vermeld niet verplicht mogen zijn zolang we niet naar een schema kunnen verwijzen voor de RSGB objecttypen.

Mijn voorstel zou eigenlijk zijn om objecttype, ObjecttypeOverige en ObjectTypeOverigeDefinitie zoals ze nu in de zaken-API gebruikt worden, 1 op 1 over te zetten naar de catalogi API waarbij in de zaken API alleen een attribuut over blijft om de verwijzing naar de objecttype resource in de catalogi te kunnen maken (URI).

[ArjanKloosterboer]

De bedoeling is, vanuit het RGBZ geredeneerd, om in de Zaken-API een zaak aan nul of meer objecten te kunnen relateren. Aangezien een dergelijk object aan meerdere zaken gerelateerd zou kunnen zijn, ontstaat een n:m-relatie tussen zaak en object. En aangezien die relatie eigenschappen heeft, is er een relatieklasse Zaakobject. Maar daar draait het dus niet om, het gaat om de relatie van een zaak naar objecten. En die objecten zijn van bepaalde objecttypen (Pand, Persoon, Wegdeel, Kadastraal object etc.). Van welke objecttypen er objecten aan een zaak gekoppeld kunnen worden, zou geregeld moeten zijn in de Catalogus-API, zie mijn opmerking van vandaag bij issue #1846 Of een dergelijk object al dan niet een RSGB-object betreft, is m.i. in een CG-gegevenslandschap niet relevant.

[michielverhoef]

Je bedoelt dus dat de relatieklasse Zaakobjecttype in de Catalogi API wel moet bestaan maar dat de zaak een attribuut objecten kent met daarin één of meer verwijzingen naar relevante objecten (RSGB of anderszins)?

[ArjanKloosterboer]

Wat het qua API's betekent, kan ik niet helemaal overzien. Hoe dan ook, voor de Catalogus-API is vooral de resource Objecttype van belang. Deze heeft een n:m-relatie met Zaaktype. Deze relatie heeft eigenschappen: de Relatieomschrijving, de relaties naar Resultaattype en Statustype en de materiele historie. Dus dat neigt naar een relatieklasse, zou ik zeggen. I.i.g. modelmatig.
Vanuit een zaak moeten (met de Zaken-API) relaties naar objecten gelegd kunnen worden, van de objecttypen die (met de Catalogus-API) aan het desbetreffende zaaktype gerelateerd zijn. Ook hier is modelmatig weer sprake van een n:m-relatie met als eigenschap (in de relatieklasse Zaakobject) de Relatie-omschrijving. Dat object bestaat al als resource in een andere API. Het lijkt me dan dat je, in de Zaken-API bij de resource Zaak, daarnaar kunt verwijzen dmv een 'repeterend groepattribuut' bestaande uit de Id daarvan (welke versie cq. url van dat object relevant is hangt er van af voor welke datum informatie opgevraagd wordt) en de Relatie-omschrijving. Feitelijk de implementatie van de relatieklasse Zaakobject).

[michielverhoef]

@ArjanKloosterboer dat is feitelijk wat er ook gedaan gaat worden in de resource Zaakobject.
https://zaken-api.test.vng.cloud/api/v1/schema/#operation/zaakobject_read

Momenteel staan daar nog attributen in om het soort object te omschrijven. Dit omdat er in de Catalogi API nog geen Zaakobjecttype bestond.

Het groepsattribuut objectidentificatie is analoog aan de StUF matchinggegevens bedoeld om een (BAG?) object te identificeren waarvoor nog geen API beschikbaar is. Tzt. komt dit attribuut te vervallen.

De attributen objecttype, objecttypeOverige en objecttypeOverigeDefinitie worden verplaatst naar Zaakobjecttype uit de Catalogi API. OLm backwards compatible te blijven laten we deze attributen nog in de huidige Zaakobject resource maar worden deze deprercated gemaakt.