Als ZTC-beheerder wil ik in de 'brondatumArchiefprocedure' i.v.t. verwijzen naar zaakobjecttypen

[MarcoKlerks]

... zodat in het veld 'objecttype' van de 'brondatumArchiefprocedure' alleen een objecttype kan staan dat ook daadwerkelijk aan een zaak gekoppeld kan zijn, gelet op de zaakobjecttypen die aan het zaaktype gekoppeld zijn.

Let op! User stories #1846 en #1848 zijn voorwaardelijk!

Op ieder resultaattype kan in de 'brondatumArchiefprocedure' een 'objecttype' opgenomen worden. Dit veld is volgens de API-specificatie verplicht wanneer in de 'brondatumArchiefprocedure' de 'afleidingswijze' een van de volgende waarden heeft:

• ander_datumkenmerk
• eigenschap
• zaakobject

Dat is opmerkelijk omdat bij "ander_datumkenmerk" en "eigenschap" het 'objecttype' niet gebruikt wordt bij het afleiden van de archiveringsparameters. Bij "zaakobject" wordt het 'objecttype' echter wel degelijk (en terecht) gebruikt.

In #1846 en #1848 verzoek ik om zaakobjecten aan zaken te koppelen op grond van zaakobjecttypen die aan zaaktypen zijn gekoppeld. In deze user story wil ik voorkomen dat in de 'brondatumArchiefprocedure' verwezen wordt naar een objecttype dat hierdoor niet aan de zaak gekoppeld kan worden.

Dit vraagt m.i. om:

1. wijziging van het 'objecttype' in de 'brondatumArchiefprocedure' van een enumeratie naar een string-veld.
2. validatie van het 'objecttype' in de 'brondatumArchiefprocedure'. Wanneer de 'afleidingswijze' "zaakobject" is moet het 'objecttype' overeenkomen met het objecttype-ID (URL?) op een van de zaakobjecttypen die gekoppeld is aan het zaaktype die gekoppeld is aan het resultaattype.
3. validatie van het 'datumkenmerk' in de 'brondatumArchiefprocedure'. Wanneer de 'afleidingswijze' "zaakobject" is moet het 'datumkenmerk' overeenkomen met de naam van een van de kenmerken die geconfigureerd zijn op het objecttype waarnaar 'objecttype' verwijst.
4. na te denken of de 'registratie' in de 'brondatumArchiefprocedure' nog wel verplicht gesteld moet worden wanneer de 'afleidingswijze' "zaakobject" is. Ik vermoed dat dit niet meer nodig is.

Verder stel ik voor:
5. wanneer de 'afleidingswijze' "ander_datumkenmerk" is, de velden 'registratie, 'objecttype' en 'datumkenmerk' wel verplicht te stellen, maar de waarden niet te valideren. De ingevulde waarden kunnen helpen bij het handmatig afleiden van de archiveringsparameters.
6. wanneer de 'afleidingswijze' "eigenschap" is, alleen het veld 'datumkenmerk' verplicht te stellen en deze te valideren op de eigenschappen die daadwerkelijk op het zaaktype geconfigureerd zijn.

Daarnaast wil ik de volgende aandachtspunten meegeven:
A. In een zaakobjecttype kan verwezen worden naar een 'objecttype' uit de objecttypen-API of naar een 'begrip' uit de Stelselcatalogus (zie #1846). Dit zal een uitdaging vormen voor de validatie van het 'datumkenmerk'. Overigens wordt in de Stelselcatalogus niet de term 'eigenschap' gebruikt, maar de term 'gegevenselement'.
B. In Maykin's objecttypen- en objecten-API's zitten op alle objecten een datumveld 'startdate', 'enddate' en 'registrationdate'. Verder kunnen op een objecttype in een JSON-schema additionele velden geconfigureerd worden, waaronder datum velden. Dit is vergelijkbare met de vaste datumvelden op een zaak en de additionele eigenschappen die op een zaaktype geconfigureerd kunnen worden. In de 'brondatumArchiefprocedure' geldt een afzonderlijke 'afleidingswijze' voor de vaste zaak-eigenschap 'einddatum'. Daar zal vast een reden voor zijn. Ook bij objecten zal het nooit voorkomen dat de 'startdate' of 'registrationdate' de brondatum is voor de 'archiefactiedatum'. Wellicht willen jullie daarom ook aparte afleidingswijzen voor de 'enddate' enerzijds en de additionele eigenschappen anderzijds. Vergeet echter niet dat de begrippen in de Stelselcatalogus geen 'enddate' kennen!

Ik zal een aparte user story schrijven voor het wijzigen van het afleiden van de archiveringsparameters n.a.v. de wijzigingen voorgesteld in deze user story. In de huidige businesslogica schuilen namelijk ook enkele andere fouten, die ik dan gelijk meeneem.... ;-)

[hdksi]

Marco, dank voor je uitgebreide analyse en issues!

Noot vooraf: in een gegevenslandschap kunnen we fundamenteel gezien van de verschillende afleidingswijzen (afgezien van wellicht ander_datumkenmerk) af. Er moet gewoon verwezen worden naar een datumveld bij een object dat ergens in een registratie is opgeslagen. Of dat nu bij de zaak zelf is, bij een andere zaak, een informatieobject, of een willekeurig ander object.

Hieronder mijn reactie uitgaande van de bestaande situatie.

Dat is opmerkelijk omdat bij "ander_datumkenmerk" en "eigenschap" het 'objecttype' niet gebruikt wordt bij het afleiden van de archiveringsparameters. Bij "zaakobject" wordt het 'objecttype' echter wel degelijk (en terecht) gebruikt.

Heeft niet met de hoofdvraag te maken, maar naar aanleiding van dit issue denk ik dat objecttype ook bij eigenschap gebruikt moeten worden - wat de verplichte relatie naar objecttype in de brondatumArchiefprocedure terecht maakt. De definitie van eigenschap (in het ImZTC) is als volgt: "De termijn start op de datum die vermeld is in een zaaktype-specifieke eigenschap (zijnde een ‘datumveld’)." Ik kan (wellicht onterecht!) geen voorbeelden bedenken van casussen waarin deze 'eigenschap' (in de vorm van een 'datumveld') verwijst naar zaakgegevens in de Zaken API zelf. Ergo: de afleidingswijze eigenschap kan (mag?) alleen worden gekozen als er een relatie bestaat tussen een Zaak en een Object.

ander_datumkenmerk zie ik als een 'last-resort'-optie voor onvoorziene situaties die zo min mogelijk beperkingen moet kennen. Hier zou ik de verplichte relatie naar 'objecttype' in brondatumArchiefprocedure juist verwijderen.

Dit vraagt m.i. om:

1. wijziging van het 'objecttype' in de 'brondatumArchiefprocedure' van een enumeratie naar een string-veld.

...of liever een verwijzing naar de plek waar het objecttype wordt gedefinieerd.

2. validatie van het 'objecttype' in de 'brondatumArchiefprocedure'. Wanneer de 'afleidingswijze' "zaakobject" is moet het 'objecttype' overeenkomen met het objecttype-ID (URL?) op een van de zaakobjecttypen die gekoppeld is aan het zaaktype die gekoppeld is aan het resultaattype.

Akkoord. Wellicht ook voor eigenschap (zie boven).

3. validatie van het 'datumkenmerk' in de 'brondatumArchiefprocedure'. Wanneer de 'afleidingswijze' "zaakobject" is moet het 'datumkenmerk' overeenkomen met de naam van een van de kenmerken die geconfigureerd zijn op het objecttype waarnaar 'objecttype' verwijst.

Discussiepunt. Ik begrijp het verzoek vanuit het oogpunt van goed informatiebeheer, maar neig desalniettemin naar naar 'niet mee eens'. Dit vereist namelijk:

1. Dat we in de catalogi API een catalogus van Objecttypen opnemen, inclusief alle bijbehorende attributen, óf
2. dat de Catalogi API geautoriseerd is voor alle registers waarin Objecttypen zijn beschreven, én dat al die registers hun 'datumkenmerken' op dezelfde wijze formatteren.

Beide opties staan op gespannen voet met de uitgangspunten van flexibiliteit en ontkoppeling die we met Common Ground en het Gegevenslandschap beogen.

4. na te denken of de 'registratie' in de 'brondatumArchiefprocedure' nog wel verplicht gesteld moet worden wanneer de 'afleidingswijze' "zaakobject" is. Ik vermoed dat dit niet meer nodig is.

Mee eens.

A. In een zaakobjecttype kan verwezen worden naar een 'objecttype' uit de objecttypen-API of naar een 'begrip' uit de Stelselcatalogus (zie #1846). Dit zal een uitdaging vormen voor de validatie van het 'datumkenmerk'. Overigens wordt in de Stelselcatalogus niet de term 'eigenschap' gebruikt, maar de term 'gegevenselement'.

5. wanneer de 'afleidingswijze' "ander_datumkenmerk" is, de velden 'registratie, 'objecttype' en 'datumkenmerk' wel verplicht te stellen, maar de waarden niet te valideren. De ingevulde waarden kunnen helpen bij het handmatig afleiden van de archiveringsparameters.

Het is me niet helemaal duidelijk wat je met de tweede zin bedoelt, maar met het bovenstaande in gedachten ben ik het hiermee verder eens.

6. wanneer de 'afleidingswijze' "eigenschap" is, alleen het veld 'datumkenmerk' verplicht te stellen en deze te valideren op de eigenschappen die daadwerkelijk op het zaaktype geconfigureerd zijn.

Ervan uitgaande dat een eigenschap altijd een kenmerk van een extern object is (zie wederom boven) vooralsnog niet mee eens.

Daarnaast wil ik de volgende aandachtspunten meegeven:
A. In een zaakobjecttype kan verwezen worden naar een 'objecttype' uit de objecttypen-API of naar een 'begrip' uit de Stelselcatalogus (zie #1846). Dit zal een uitdaging vormen voor de validatie van het 'datumkenmerk'. Overigens wordt in de Stelselcatalogus niet de term 'eigenschap' gebruikt, maar de term 'gegevenselement'.

Hoe ver we willen (kunnen?) gaan met valideren is een fundamentele vraag (zie ook punt 3.). Te bespreken.

B. In Maykin's objecttypen- en objecten-API's zitten op alle objecten een datumveld 'startdate', 'enddate' en 'registrationdate'. Verder kunnen op een objecttype in een JSON-schema additionele velden geconfigureerd worden, waaronder datum velden. Dit is vergelijkbare met de vaste datumvelden op een zaak en de additionele eigenschappen die op een zaaktype geconfigureerd kunnen worden. In de 'brondatumArchiefprocedure' geldt een afzonderlijke 'afleidingswijze' voor de vaste zaak-eigenschap 'einddatum'. Daar zal vast een reden voor zijn. Ook bij objecten zal het nooit voorkomen dat de 'startdate' of 'registrationdate' de brondatum is voor de 'archiefactiedatum'. Wellicht willen jullie daarom ook aparte afleidingswijzen voor de 'enddate' enerzijds en de additionele eigenschappen anderzijds. Vergeet echter niet dat de begrippen in de Stelselcatalogus geen 'enddate' kennen!

In plaats van afleidingswijzen toevoegen, zou ik eerder snoeien in het aantal beschikbare opties. Zie de 'noot vooraf'.

[MarcoKlerks]

Noot vooraf: in een gegevenslandschap kunnen we fundamenteel gezien van de verschillende afleidingswijzen (afgezien van wellicht ander_datumkenmerk) af. Er moet gewoon verwezen worden naar een datumveld bij een object dat ergens in een registratie is opgeslagen. Of dat nu bij de zaak zelf is, bij een andere zaak, een informatieobject, of een willekeurig ander object.

Ik vermoed ook dat de 'afleidingswijze' slimmer kan, maar dat laat ik graag aan jullie over. Vergeet echter niet dat op het resultaattype moet verwijzen naar datumvelden die gedefinieerd zijn op type-niveau (zaaktype, objecttype, besluittype, etc.). Op grond van de afleidingswijze wordt gezocht naar de waarde die op de registratie (bijv. object) is igevuld in het veld dat op type-niveau gedefinieerd is.

Heeft niet met de hoofdvraag te maken,

Klopt, maar als we toch bezig zijn....

maar naar aanleiding van dit issue denk ik dat objecttype ook bij eigenschap gebruikt moeten worden

Nee, in de documentatie van de Resultaaattypen-API staat (conform het ImZTC):

Het gaat dus om deze eigenschappen die op een zaaktype geconfigureerd kunnen worden en niet om eigenschappen op objecttypen.

Ik kan (wellicht onterecht!) geen voorbeelden bedenken van casussen waarin deze 'eigenschap' (in de vorm van een 'datumveld') verwijst naar zaakgegevens in de Zaken API zelf.

Niet geheel onterecht. Wanneer ik door de Selectielijst heen struin, kan ik ook geen zaaktype-specifieke velden verzinnen die je als brondatum voor de achiefactiedatum zou willen configureren. Wanneer een bewaartermijn start "na vervallen belang" wordt er voortdurend verwezen naar het proces_object_.

Van mij mag de afleidingswijze "eigenschap" er dus uit, maar ik sluit niet uit dat andere vakgenoten het hier niet mee eens zijn.

ander_datumkenmerk zie ik als een 'last-resort'-optie voor onvoorziene situaties die zo min mogelijk beperkingen moet kennen. Hier zou ik de verplichte relatie naar 'objecttype' in brondatumArchiefprocedure juist verwijderen.

Akkoord.

1. validatie van het 'datumkenmerk' in de 'brondatumArchiefprocedure'. Wanneer de 'afleidingswijze' "zaakobject" is moet het 'datumkenmerk' overeenkomen met de naam van een van de kenmerken die geconfigureerd zijn op het objecttype waarnaar 'objecttype' verwijst.

Discussiepunt. Ik begrijp het verzoek vanuit het oogpunt van goed informatiebeheer, maar neig desalniettemin naar naar 'niet mee eens'. Dit vereist namelijk:

1. Dat we in de catalogi API een catalogus van Objecttypen opnemen, inclusief alle bijbehorende attributen, óf

2. dat de Catalogi API geautoriseerd is voor alle registers waarin Objecttypen zijn beschreven, én dat al die registers hun 'datumkenmerken' op dezelfde wijze formatteren.

Ik raad aan om voorlopig slechts twee bronnen te ondersteunen:

1. De objecttypen-API van Common Ground, en
2. De Stelselcatalogus.

Dat betekent inderdaad wel dat de Catalogi API geautoriseerd moet zijn voor de Objecttypen API. De Stelselcatalogus is Open Data, dus dat is alvast geen probleem.

Een alternatief zou zijn om deze validatie op de interactielaag te doen (in de ZTC-beheerinterface van OpenZaak bijvoorbeeld), maar dat lijkt mij een minder nette oplossing.

Het format-probleem (dd-mm-yyyy etc.) gaat pas spelen als je op een zaak de archiefactiedatum wilt gaan berekenen (toch?), dus dat probleem moet opgelost worden in de Zaken-API en niet in de Catalogi-API. Wel een goed punt trouwens. Dit vraagt om slimmigheden in zrc-021.

Beide opties staan op gespannen voet met de uitgangspunten van flexibiliteit en ontkoppeling die we met Common Ground en het Gegevenslandschap beogen.

Ja, het barst van de afhankelijkheden. De API's worden los gepresenteerd, maar het barst van de verwijzingen over en weer. Ik weet echter niet in hoeverre verwijzingen gevalideerd worden....

Hoe ver we willen (kunnen?) gaan met valideren is een fundamentele vraag (zie ook punt 3.). Te bespreken.

Exact :-).

In plaats van afleidingswijzen toevoegen, zou ik eerder snoeien in het aantal beschikbare opties. Zie de 'noot vooraf'.

Als het slimmer kan, moeten we dat vooral doen. De archiefactiedatum kan afhankelijk zijn van een datumveld van de zaak zelf, een andere zaak, een object of een besluit. Zo denkende zou je dus aan 4 opties genoeg moeten kunnen hebben. Houd er wel rekening mee dat sommige datumvelden "vast" zijn (bijvoorbeeld de einddatum op een zaak), terwijl andere datumvelden geconfigureerd zijn (ze gelden alleen voor zaken/objecten van dàt zaaktype/objecttype).

[michielverhoef]

@MatthijsBekendam
Aangezien #1846 en #1848 zijn doorgevoerd moeten we dit ticket niet vergeten. Even afwachten wat er uit #1929 komt.