gemma-zaken icon indicating copy to clipboard operation
gemma-zaken copied to clipboard

Als gemeente wil ik alle RSGB objecten als objecttype kunnen aangeven bij het objectinformatieobject in het DRC

Open CMasselink opened this issue 4 years ago • 5 comments

zodat het DRC ook te gebruiken is voor documenten die niet aan een zaak of besluit gerelateerd zijn.

Toelichting Wij willen het DRC graag als centraal documentregistratiecomponent kunnen positioneren binnen de gemeente. In dit centrale component worden dan ook documenten opgeslagen die niet direct bij een zaak of besluit horen. Bijvoorbeeld het kunnen koppelen van documenten aan panden. Op dit moment kan er bij het objectinformatieobject.objecytType alleen voor zaak of besluit gekozen worden. Wij willen graag kunnen verwijzen naar andere objecttypes. Als startpunt voor objecttypes lijkt het ons verstandig om de RSGB objecten te gebruiken. Ik kan me ook een oplossing voorstellen waarbij je naast de RSGB objecttypes het objecttype "overig" kan selecteren waarbij na het objecttype vrij in te vullen is voor objecten die niet in de RSGB staan.

CMasselink avatar Dec 17 '20 09:12 CMasselink

Dit is een lastige, zeker omdat het RSGB in de architectuur van het gegevenslandschap een heel andere rol gaat krijgen. In die zin dat het RSGB zoals we dat kennen niet meer zal bestaan. Het hele idee is om de bronhouder het eigen informatiemodel te laten beheren en niet meer (alleen) de meervoudig hergebruikte gegevens op te nemen in een gemeenschappelijk informatiemodel.

De vraag is dus of we klakkeloos alle objecttypen zoals we die nu kennen in de DRC mogelijk moeten maken of beter kunnen beginnen met "overig" en de exacte invulling later kunnen bepalen?

michielverhoef avatar Dec 17 '20 09:12 michielverhoef

Het gaat er meer om dat je naar objecttypes uit basisregistraties kan verwijzen. Dan houd je het wat gestructureerder dan wanneer alles vrije invul is (wegdeel, Weg-deel, Wegdeel, dat soort dingen). Ik heb RSGB genoemd omdat daar de objecten uit de basisregistraties in beschreven staan.

Beginnen met overig, maakt het wel in 1 klap mogelijk om naar elk willekeurig object te kunnen verwijzen dus is misschien een goed startpunt maar dus wel met risico op 'vervuiling'.

Ik kan me ook voorstellen dat objecttype geen enum meer wordt maar een URL verwijzing naar een objecttype definitie uit bijvoorbeeld een objecttype registratie.

CMasselink avatar Dec 17 '20 09:12 CMasselink

Ik kan me ook voorstellen dat objecttype geen enum meer wordt maar een URL verwijzing naar een objecttype definitie uit bijvoorbeeld een objecttype registratie.

Dit vind ik een hele mooie oplossingsrichting. Ook omdat een document aan een verzoek, contactmoment etc. gekoppeld kan zijn. Daar hoeft nog geen zaak of besluit bij te horen maar dat wil je wel vast kunnen leggen.

Edit: dit zou dan een lijst in de Referentielijsten API kunnen zijn https://github.com/VNG-Realisatie/VNG-referentielijsten

michielverhoef avatar Jan 14 '21 13:01 michielverhoef

Relaties naar (RSGB-)objecten liggen nu vanuit de zaak. De logica hierachter is dat de zaak de hoeveelheid werk, het proces is waarin die objecten een rol spelen. Een document kan wel betrekking hebben op een object maar dat wordt veroorzaakt doordat die hoeveelheid werk op dat object betrekking heeft. En waarschijnlijk geldt dat voor meer documenten bij die zaak.
Wat nu voor documenten zonder zaak? Ik vraag me dan af, in welke context is dat document ontvangen of gecreëerd? De behandeling van een zaak is er één, de uitvoering van een project een ander. En zo zullen er meer zijn. Die context uit zich in een samenhangende verzameling van documenten, ook wel dossier genoemd. Het RGBZ kent alleen zaakdossiers. Wat al eens verkend is, is het opsplitsen van het RGBZ in afzonderlijke modellen, zoals een informatiemodel documenten. Daar hoort een dossier als objecttype in thuis. Met daaraan onder meer relaties naar (RGBZ-)objecten. En een optionele relatie naar ZAAK: een dossier kan een zaakdossier zijn maar ook een andersoortig dossier.
Ik zou de oplossing in deze richting zoeken. Dat vult tevens de lacune in van het ontbreken van modellering en ondersteuning van niet-zaak-dossiers. Het heet niet voor niets de Documenten-API ...

In de Documenten API kennen we alleen relaties naar objecten. Dit gaat via de resource ObjectInformatieobject. In de Zaken API kennen we de resource ZaakInformatieobject, in de Besluiten API kennen we de resource BesluitInformatieobject. Eigenlijk is ObjectInformatieobject een vrij generieke resource met verwijzingen naar de betreffende andere resources die in een andere API leven.

Volgens mij is dat het dossier mechanisme waar @ArjanKloosterboer-Telengy naar verwijst.

Het enige waar nu een beperking in zit is de waarde van het attribuut objectType. Dat is nu een enumeratie met de waarden "Zaak" en "Besluit".

Het mooiste zou zijn wanneer dit geen enum meer zou zijn maar een verwijzing naar referentielijst waar de objecttypen in bij gehouden worden. Eventueel kan een gemeente dan besluiten een eigen lijst bij te houden voor de eigen objecttypen. Analoog aan zaaktypen. Dan hoeft er ook geen nieuwe versie van de API uitgebracht te worden wanneer een nieuw objecttype toegevoegd wordt.

ObjectInformatieobject heeft de volgende structuur: `{

"url": "http://example.com",
"informatieobject": "http://example.com",
"object": "http://example.com",
"objectType": "besluit"

}`

Tot het zover is is "overig" met een vrij te definieren omschrijving een oplossing, al is die minder mooi en wel fout gevoelig.

michielverhoef avatar Mar 11 '21 15:03 michielverhoef