DRC: nieuwe statusvelden

[johannesbattjes]

Zie discussie in [https://github.com/VNG-Realisatie/gemma-zaken/issues/2056]

Er zijn verschillende vormen van status die onafhankelijk van elkaar van waarde kunnen veranderen en elkaar niet, zoals bij het huidige veld status, uitsluiten. Wij stellen voor het huidige veld status op informatieobject te laten vervallen en te vervangen door vier nieuwe statussen met ieder een duidelijk toepassingsgebied:

Archiefstatus Waardes • nog_te_archiveren • gearchiveerd

Bewerkstatus Waardes • ontvangen • in bewerking • concept • vastgesteld • definitief

Geldigheidsstatus Toegestane waardes • actief • vervallen

RedenVervallen (behorend bij geldigheidsstatus vervallen) Toegestane waardes • ingetrokken • nieuwe versie

Anonimiseringsstatus Toegestane waardes • niet_anoniem • onbekend • anoniem

Dit voorstel is gezamenlijk voorbereid door de volgende organisaties: Gemeente Tilburg ODMH Gemeente Maastricht Avolve Software Visma Roxit

[hdksi]

Mooi! Ik ben het eens met de achter dit voorstel liggende constatering dat niet alle 'statusvormen' op dezelfde as passen. Een paar vragen en overwegingen die ik eigenlijk het liefst eens live zou willen bespreken:

1) Ik zou graag een korte toelichting zien waarin de grond voor precies deze vier 'statusvormen' wordt beschreven en de gekozen beperkingen ten aanzien van daarbij toegestane waarden worden verklaard. Sluiten die aan bij wet- en regelgeving of andere standaarden, en zo ja, op welke manier?

2) Ik vraag me af of, en zo ja welke bedrijfsregels (moeten) gaan ontstaan om af te dwingen dat alleen toegestane combinaties van statussen en andere kenmerken worden toegekend. Mag een document met bewerkstatus "in bewerking" bijvoorbeeld een geldigheidsstatus "actief" krijgen of archiefstatus "gearchiveerd"? En moet een document met een 'is vervangen door'-relatie naar een ander document altijd de geldigheidsstatus "vervallen" krijgen? Hierbij is ook te kijken naar afhankelijkheden met 'gebruiksrechten' (kan een niet-anoniem document bestaan zonder voorwaarden ten aanzien van gebruiksrechten?). Achter deze vraag ligt de constatering dat het navolgen van dit soort regels door consumeren en valideren en afdwingen hiervan door providers uitdagingen oplevert, waardoor we aanwezigheid daarvan zoveel mogelijk willen beperken. Aan de andere kant zijn documenten met kenmerken die elkaar tegenspreken natuurlijk ook niet gewenst.

3) Wat is de semantiek achter het 'vervallen' van een document? Hebben we het hier in generieke zin over geldigheid van documentinhoud? Nu ben ik geen documentbeheer-crack, dus misschien zit ik hier helemaal mis, maar het concept 'vervallen' lijkt mij eerder te horen bij iets specifieks (bijvoorbeeld een beschikking) dat 'toevallig' in documentvorm is vastgelegd.

4) Eerder constateerden we al dat beperkingen die openbaar publiceren een andere grond kunnen hebben dan de aanwezigheid van persoonsgegevens. Nu we niet kunnen stellen dat een document met anonimiseringsstatus "anoniem" openbaar publiceerbaar is, noch kunnen stellen dat de inhoud hiervan in voorbereiding daarop 'voldoende gelakt' is ontstaat als expliciet vervolg bij punt 1 de vraag welk doel met het opnemen van deze statusvorm gediend is.

[Jinze82]

Toevoeging zoals besproken: Praatprent documenten flow versie 1.pdf

[MNIJ]

Zoals afgesproken in een meeting op 17-10-2023 hebben @johannesbattjes en ik de voorgestelde velden en waarden van definities voorzien. Hierin zijn ook een aantal kleine aanscherpingen van de veldnamen doorgevoerd en is rekening gehouden met backwards compatibility voor consumers. Het veld redenVervallen hebben we laten vervallen omdat dit door het voorstel voor documentrelaties #2240 waarschijnlijk overbodig gemaakt kan worden en dus dubbelop zou zijn.

Statusvelden van informatieobjecten.pdf

[michielverhoef]

Zoals afgesproken op de meeting van 17-10-2023 hebben we enkele vragen verzameld naar aanleiding van de discussies en de gedane voorstellen. NB. disclaimer: Een aantal vragen is heel kort na de meeting opgeschreven ivm een naderende vakantie. Eventuele uitleg en aanscherpingen die later nog gedaan zijn maken die vragen wellicht overbodig. Voor de zekerheid laat ik ze toch staan, dan weten we zeker dat ze niet onbeantwoord blijven. De vragen zijn gebundeld maar afkomstig van verschillende personen. Daarom kunnen er dubbelingen ontstaan en zijn er stijlverschillen. Voor de zuiverheid heb ik de teksten niet aangepast zodat de vragen zo direct mogelijk overkomen.

Vragen en opmerkingen: De concepten ‘documentversies’ en ‘documentstatussen’ (of netter: ‘informatieobjectversies’ en ‘informatieobjectstatussen’) gaan beschreven worden, zo is afgesproken. Vragen en aandachtspunten hierbij zijn o.a.:

• Wat bedoelen we met een versie van een document? Leidt elke wijziging tot een nieuwe versie? Bij wijziging van zowel inhoud als van metagegevens? Wanneer ontstaat een nieuwe versie
• Of zijn er ook varianten van een document? De gestempelde variant? De geanonimiseerde variant? Zo ja, wat is dat dan, een variant? Wat is het verschil met een versie? Wanneer is sprake van een versie en wanneer van een variant? Heeft dat iets te maken met geldigheid oid (actueel?), dat er slechts één versie geldig kan zijn maar dat zowel een versie als een variant geldig kunnen zijn?
• Is een variant een zelfstandig informatieobject, of een variant van een informatieobject die ook versies heeft?
• Willen we weten (en dus kunnen registreren) van welke versie een variant is afgeleid? Statussen markeren mijlpalen op een tijdlijn (toch)?
• Welke tijdlijnen willen we onderscheiden, waarom en wat behelzen die?
• Welke statussen willen we per tijdlijn onderscheiden en waarom?
• Hoe verhouden tijdlijnen cq. statussen zich tot elkaar? Zitten er businessrules achter?
• Hoe verhouden tijdlijnen en statussen zich tot versies en varianten?

De volgende twee vragen zijn over de definities in issue #2240 In het normale gebruik is alleen de meest recente versie relevant.

• Is dit altijd zo? Kan een versie niet doorontwikkeld worden terwijl voor de burger/buitenwacht een eerdere versie (waar bijvoorbeeld een publiceerbare variant van beschikbaar is) relevant is?

Elke variant is daarom een opzichzelfstaand informatieobject.

• Kan het voorkomen dat een geldige (actuele) variant van een andere versie is dan de geldige/actuele versie?
• Zijn varianten van versies altijd aparte informatieobjecten? Of is er bijvoorbeeld één publiceerbare variant van een informatieobject en zijn daar versies van, gekoppeld aan versies van het oorspronkelijke informatieobject? Bijvoorbeeld wanneer van een IO van verschillende versies een publiceerbare variant gemaakt wordt, zijn die publiceerbare varianten dan versies van een gerelateerd Informatieobject?

Ik zie naar aanleiding van het voorstel vier redelijk duidelijk te onderscheiden tijdlijnen die helaas waarschijnlijk onderling (nu niet onderzochte) afhankelijkheden vertonen:

1. Een ‘bewerkingstijdlijn’ die opeenvolgende aanpassingen aan een document beschrijft: ('versie 0.1', '0.6', '0.9', '1.0', '1.5')
2. Een ‘besluitvormingstijdlijn’ die beschrijft hoe ver het document is in een formeel besluitvormingsproces ('in voorbereiding', 'vastgesteld', '...') . Deze tijdlijn is alleen relevant voor documenten die zo’n proces doorlopen.
3. Een ‘geldigheidstijdlijn’ die bepaalt of aan een document bepaalde rechten kunnen worden ontleend: ('nog niet geldig', 'geldig', 'vervallen', '...'). Deze tijdlijn is alleen relevant voor documenten die ooit ‘geldig’ worden.
4. Een ‘archieftijdlijn’ die bepaalt of een document gearchiveerd is en (dus) nog bewerkt mag worden: ('niet gearchiveerd', 'gearchiveerd', '...'). Deze tijdlijn is alleen relevant voor documenten die gearchiveerd moeten worden.

Een ‘persoonsgegevenstijdlijn’ zie ik niet echt. Aanwezigheid daarvan of al dan niet anonimiseren van een document hebben mijn inziens maar heel beperkt te maken met temporele aspecten. In plaats van een ‘anonimiseringsstatus’ bij te houden, zou ik daarom eerder kiezen voor een aanduiding waarmee kan worden aangegeven of een document persoonsgegevens omvat of niet.

De in het document van Michiel en Johannes onder het ‘algemene’ label ‘status’ gegroepeerde waarden kunnen over verschillende van deze tijdlijnen verdeeld worden, terwijl individuele waarden soms op meerdere tijdslijnen tegelijk passen. De vraag is of dat erg is; het erkennen en ondersteunen van vier tijdslijnen brengt de immers nodige, liefst vermeden complexiteit met zich mee. Om dat bepalen is het volgens mij in ieder geval nodig te weten of het ‘dwingend bundelen’ van deze waarden op één as:

1. een eenduidige interpretatie betekenis van de voorgestelde waarden in de weg zit, en
2. of hierdoor betekenis verloren gaat – ik kan van een gearchiveerd document immers niet meer eenvoudig vaststellen of dit was vastgesteld of niet.

[MNIJ]

Op basis van een bijeenkomst op 14-11-2023 met @ArjanKloosterboer, @Jinze82, @hdksi en @HenriKorver hebben @johannesbattjes en ik een aangepaste versie van het voorstel voor statusvelden en waarden opgesteld.

We hebben daarbij de definities bewust kort en to-the-point gehouden, omdat langere definities het gevaar hebben teveel toegespitst te zijn op een beperkte casus. Mochten jullie nog aanvullingen of verbeteringen hier op hebben, dan is het het meest efficiënt om dit in de vorm te doen van een concreet verbetervoorstel van de voorgestelde termen en definities.

Statusvelden van informatieobjecten.pdf

[ArjanKloosterboer]

Goed voorstel, bedankt. Enkele kleine tekstuele opmerkingen en eentje over het toepassen er van.

Bij het element 'status' is in de definitie sprake van 'het proces van bewerking en formele vaststelling'. Onder die terminologie lijkt een ontvangen document niet te vallen (wordt niet bewerkt en niet vastgesteld). En 'proces' is ook een twijfelachtige term aangezien een zaak de uitvoering van een proces betreft waarbij een document een rol speelt in die uitvoering cq. in dat proces. Maar er is geen 'documentproces'. Voorstel: Legt vast waar het document zich bevindt in haar levenscyclus.
Bij het element 'vervallen' gaat het er volgens de definitie blijkbaar om of het document 'een rol speelt in het huidige of toekomstige proces'. Dit kan verkeerd gelezen worden: het één (huidig proces) dan wel het ander (toekomstig proces). Maar zo is het niet bedoeld. En 'proces' is wellicht wat te beperkend. Ik zou spreken van 'de bedrijfsvoering'. Voorstel: Legt vast of het document relevant blijft voor de bedrijfsvoering. V.w.b. het element 'bevatPersoonsgegevens', de definitie van de waarde "nee" bevat een dubbele ontkenning en dat leest altijd lastig. Voorstel: Bevat geen persoonsgegevens of alleen persoonsgegevens die vrijelijk openbaar gemaakt mogen worden.
V.w.b. het element 'ontvangen', gaat het er hier wel om of het al dan niet ontvangen is? M.i. gaat het er erover wat de bron is van het document: opgesteld door de eigen organisatie dan wel ontvangen van een andere organisatie. Verder, is het duidelijk wat met 'externe partij' bedoeld wordt? Is bijvoorbeeld een Omgevingsdienst die een vergunningaanvraag behandelt een externe partij (ja!)? Ik stel voor om hier te spreken van 'een partij buiten de eigen organisatie'. Al met al stel ik de volgende definitie voor: Legt vast wat de bron is van het document. En het is m.i. een verplicht element. En in de definitie van 'true' zit een typefoutje.

Het lijkt me zinvol om enkele voorbeelden uit te werken van toepassing in de praktijk, waarin inzicht wordt geboden in welke waarden wanneer van toepassing zijn. Zoals:

• een ontvangen en daarna gestempelde brief,
• een intern opgestelde brief die na goedkeuring door de verantwoordelijke (gestempeld en) verzonden wordt,
• een opgesteld en vastgesteld besluit,
• een vergunning,
• een intern adviesstuk dat geen formele vaststelling ondergaat.

[ArjanKloosterboer]

We hebben nu duidelijkheid over de verschillende statusvelden, hun waarden en hun definities. Het aanpalende onderwerp was 'versies'. Hebben we nu voldoende duidelijkheid en eenduidigheid over wat we onder een versie van een document verstaan en wanneer een nieuwe versie dan wel een nieuw document ontstaat (bijvoorbeeld bij het stempelen van een document en bij het anonimiseren van een document)? Zo ja, waar is dat gedocumenteerd en eenvoudig terug te vinden?

[michielverhoef]

Het attribuut ontvangen is denk ik overbodig. Immers, bij een ontvangen document wordt een Verzending vastgelegd. Eventueel zou het als convenience attribuut gevuld kunnen worden door de provider wanneer een Verzending bestaat met een aardrelatie met de waarde afzender.

Wat doen we dan met een document wat wel ontvangen is maar waarvan de afzender niet bekend is? Dat wil je wel kunnen registreren. Maar dat zou ook een wijziging in Verzending betekenen zodat een afzender onbekend ook vastgelegd kan worden.

[MNIJ]

Mee eens, @michielverhoef. Ik zou ook liever met een "onbekende afzender" werken dan met een los attribuut. Lijkt mij prima om dit attribuut te laten vervallen.

[hdksi]

Aanvullend bij de suggesties van Arjan, die ik onderschrijf, nog een aantal nieuwe opmerkingen:

• De volledige definitie van status concept is "het document is inhoudelijk klaar om voorgelegd te worden aan anderen en zo nodig aangepast te worden op basis van commentaar." Dit - voorleggen en commentaar krijgen op de inhoud - is iets wat óók in een besluitvormingsproces kan gebeuren. Toch gaan we ervan uit dat documenten die een besluitvormingsproces ingaan eerst de status 'definitief' bereikt hebben. Misschien is dit muggenziften, maar wellicht heeft iemand goede/eenvoudige suggesties om deze definitie te verscherpen zodat duidelijker is hoe we dit voorleggen en eventuele aanpassingen als gevolg daarvan moeten zien?
• In vervolg op het voorgaande: de definitie van status concept begint met "het document is inhoudelijk klaar [...]". De volledige definitie van definitief leest "het document is inhoudelijk gereed". Dit is een synoniem van de eerste woorden van de vorige status. Dat vind ik verwarrend. Deze verwarring kan worden verholpen door duidelijk te maken waarvoor een definitief document dan klaar of gereed (ik zou één van deze woorden voor beide definities kiezen) is.
• Ik heb wat moeite met een aantal optionaliteiten. Ik snap dat we deze kenmerken in databases omwille van 'oude/bestaande' documenten niet verplicht kunnen stellen, maar is het voor nieuwe registraties, gemaakt met een naar aanleiding van deze wijzigingen bijgewerkte API, niet (eventueel op termijn) mogelijk te werken met verplichte vastlegging en defaultwaarden (persoonsgegevens: onbekend / ontvangen: neen / vervallen: neen) in plaats van standaard verwarrende - want wat betekenen ze nu eigenlijk? - nullwaarden?
• Meer specifiek: hoewel ik weet en snap dat ze soms moeten mogen vind ik nullable booleans (het datatype waarop de bij vervallen en ontvangen toegestane waarden lijken te hinten) conceptueel vreemd.
• En sowieso vraag ik me af of we door introductie van waarden als true en false in conceptuele beschrijvingen niet onnodig datamodellen met conceptuele modellen aan het vermengen zijn. Waarom op dit niveau niet gewoon ja en nee(n) hanteren (zie ook voorbeelden hierboven)?

[hdksi]

Het attribuut ontvangen is denk ik overbodig. Immers, bij een ontvangen document wordt een Verzending vastgelegd. Eventueel zou het als convenience attribuut gevuld kunnen worden door de provider wanneer een Verzending bestaat met een aardrelatie met de waarde afzender.

Wat doen we dan met een document wat wel ontvangen is maar waarvan de afzender niet bekend is? Dat wil je wel kunnen registreren. Maar dat zou ook een wijziging in Verzending betekenen zodat een afzender onbekend ook vastgelegd kan worden.

Hergebruik > nieuwbouw, dus goede suggestie. De vraag is alleen of verzending niet eigenlijk een specifieke vorm is van een klantcontact, wat de vervolgvraag oproept of deze resource op termijn niet zou kunnen vervallen of aanpassingen vraagt. Nu is dat wellicht erg prematuur geconcludeerd, maar maar aanleiding daarvan ontstaat weer de vraag of je aan verzending nog nieuwe functionaliteit moet willen ophangen. Ik wil die niet solitair beantwoorden, maar neig naar een 'nee'.

@MNIJ of @ArjanKloosterboer volgens mij hebben we het in relatie tot de 'ontvangststatus' over verzending gehad; was er, behalve een nu verplichte relatie naar een betrokkene, niet een andere reden om expliciet een losse 'status' te willen?

[ArjanKloosterboer]

volgens mij hebben we het in relatie tot de 'ontvangststatus' over verzending gehad; was er, behalve een nu verplichte relatie naar een betrokkene, niet een andere reden om expliciet een losse 'status' te willen?

De status-waarde 'ontvangen' was één van de waarden in het oorspronkelijke voorstel voor de waardenlijst van 'Status'. Die hebben we daaruit gehaald en apart gezet. Zonder door te redeneren dat het al dan niet ontvangen zijn al af te leiden is uit 'Verzending'. Ik kan me geen ander bestaansrecht voor 'ontvangen' heugen.

[hdksi]

• Ik heb wat moeite met een aantal optionaliteiten. Ik snap dat we deze kenmerken in databases omwille van 'oude/bestaande' documenten niet verplicht kunnen stellen, maar is het voor nieuwe registraties, gemaakt met een naar aanleiding van deze wijzigingen bijgewerkte API, niet (eventueel op termijn) mogelijk te werken met verplichte vastlegging en defaultwaarden (persoonsgegevens: onbekend / ontvangen: neen / vervallen: neen) in plaats van standaard verwarrende - want wat betekenen ze nu eigenlijk? - nullwaarden?
• Meer specifiek: hoewel ik weet en snap dat ze soms moeten mogen vind ik nullable booleans (het datatype waarop de bij vervallen en ontvangen toegestane waarden lijken te hinten) conceptueel vreemd.

Deze opmerkingen laat ik even zitten; hoor graag van belanghebbenden in hoeverre zij eventueel 'last' hebben van een onduidelijke betekenis ("attribuut bestond bij eerste vastlegging nog niet dus ik kon het niet invullen", "consumer heeft dit attribuut niet geïmplementeerd", "geen", "ik weet het niet", "het is in dit geval niet relevant", "...") van nullwaarden.

Dit betekent dat ik bij de 'toegestane waarden' in de voorstellen hieronder geen rekening heb gehouden met waarden als Onbekend, Niet van toepassing etc.

Wel heb ik naar aanleiding van

En sowieso vraag ik me af of we door introductie van waarden als true en false in conceptuele beschrijvingen niet onnodig datamodellen met conceptuele modellen aan het vermengen zijn. Waarom op dit niveau niet gewoon ja en nee(n) hanteren (zie ook voorbeelden hierboven)?

de als booleans gemodelleerde indicatoren omgezet naar varianten waarop ja en nee kan worden geantwoord. Maar ik wil daarmee geen uitspraken doen over hoe daarmee na omzetting naar een API-spec moet worden omgegaan.

[hdksi]

Het attribuut ontvangen is denk ik overbodig. Immers, bij een ontvangen document wordt een Verzending vastgelegd. Eventueel zou het als convenience attribuut gevuld kunnen worden door de provider wanneer een Verzending bestaat met een aardrelatie met de waarde afzender.

Wat doen we dan met een document wat wel ontvangen is maar waarvan de afzender niet bekend is? Dat wil je wel kunnen registreren. Maar dat zou ook een wijziging in Verzending betekenen zodat een afzender onbekend ook vastgelegd kan worden.

Hergebruik > nieuwbouw, dus goede suggestie. De vraag is alleen of verzending niet eigenlijk een specifieke vorm is van een klantcontact, wat de vervolgvraag oproept of deze resource op termijn niet zou kunnen vervallen of aanpassingen vraagt. Nu is dat wellicht erg prematuur geconcludeerd, maar maar aanleiding daarvan ontstaat weer de vraag of je aan verzending nog nieuwe functionaliteit moet willen ophangen. Ik wil die niet solitair beantwoorden, maar neig naar een 'nee'.

@MNIJ of @ArjanKloosterboer volgens mij hebben we het in relatie tot de 'ontvangststatus' over verzending gehad; was er, behalve een nu verplichte relatie naar een betrokkene, niet een andere reden om expliciet een losse 'status' te willen?

De status-waarde 'ontvangen' was één van de waarden in het oorspronkelijke voorstel voor de waardenlijst van 'Status'. Die hebben we daaruit gehaald en apart gezet. Zonder door te redeneren dat het al dan niet ontvangen zijn al af te leiden is uit 'Verzending'. Ik kan me geen ander bestaansrecht voor 'ontvangen' heugen.

Ik heb achter een link naar de klantinteracties-ontwikkelrepo een stukje proza over een mogelijke mapping van klantinteractiesconcepten op 'verzending' gepubliceerd.

Stel dat we hiervan uitgaan dan zijn wel een paar stappen te zetten om van informatieobject te komen naar informatie over de verzendrichting (informatieobject > bijlage bij klantcontact > (initiatiefnemer van) klantcontact). Ik kan me voorstellen dat het, gezien deze afstand handig is om toch een indicatie op te nemen. Hoe kijken jullie daarnaar?

[hdksi]

Dan mijn meer opmerkingen van semantische aard. Ik kom naar aanleiding van opmerkingen van Arjan, mijzelf en overleg hierover tot de volgende voorgestelde aanpassingen. Te beginnen met:

Bewerkings- en vaststellingsstatus

Beschrijving: Geeft aan waar het informatieobject zich bevindt in de cyclus van bewerking en vaststelling.

Toegestane waarden:

Waarde	Betekenis
In voorbereiding	De inhoud van het informatieobject kan op ieder moment en onaangekondigd veranderen.
Concept	De inhoud van het informatieobject heeft een mate van bestendigheid bereikt waardoor die aan derden ter beoordeling kan worden voorgelegd. Deze beoordeling kan leiden tot verandering van de inhoud van het informatieobject.
Definitief	De inhoud van het informatieobject heeft een mate van bestendigheid bereikt waardoor die niet (langer) zomaar veranderd kan worden.
Ter vaststelling	De inhoud van het informatieobject is betrokken bij een lopend besluitvormingsproces.
Vastgesteld	De inhoud van het informatieobject is tijdens een besluitvormingsproces bekrachtigd.

Toelichting: Deze set statussen is feite een samenstelling van twee verzamelingen 'statustypen'. De waarden In voorbereiding, Concept en Definitief representeren punten op de 'bewerkingstijdslijn' die helpen te bepalen hoe de 'volwassenheid' van de inhoud van het informatieobject moet worden beoordeeld.

Ter vaststelling en Vastgesteld liggen op de 'besluitvormingstijdslijn' en geven aan hoe ver het besluitvormingsproces waarin het informatieobject een rol speelt, gevorderd is.

Besluitvorming gaat vrijwel altijd over 'definitieve' inhoud van informatieobjecten. Dit betekent dat sprake is van een 'opvolgende' reeks statussen. Hierdoor konden de statussen die horen bij de twee verschillende tijdslijnen in één verzameling worden opgenomen.

Een informatieobject hoeft zeker niet altijd alle statussen te doorlopen. Al terwijl een informatieobject nog In voorbereiding is kan bijvoorbeeld duidelijk worden dat de dienst waaraan de inhoud daarvan bijdroeg niet geleverd hoeft te worden. Bovendien wordt de inhoud van veel informatieobjecten niet in een besluitvormingsproces bekrachtigd. En ontvangen informatieobjecten worden (door de gemeente) niet bewerkt en krijgen dus direct na ontvangst de status Definitief.

De Bewerkings- en vaststellingsstatus Definitief moet niet verward worden met de Archiefstatus Onmuteerbaar. Die laatste betekent in feite "geen enkele wijziging toegestaan". Voor zover het gaat om door de gemeente gecreëerde informatieobjecten betekent 'Definitief' daarentegen dat naar aanleiding van overleg, reviews en afspraken een 'overeengekomen' of 'afgestemde' versie van informatieobjectinhoud is ontstaan. Wijzigingen hierin zijn niet verboden, maar zullen in veel gevallen vragen om verantwoording bij doorgevoerde wijzigingen op basis van nieuwe reviews en afspraken.

Rationale bij wijzigingen voorgesteld ten opzichte van voorstel van 17 november:

• Wijziging naam van 'Status' naar 'Bewerkings- en vaststellingstatus': we splitsen wat nu eenvoudigweg 'Status' heet in twee delen. Het is vreemd als het ene deel de naam 'Status' erft, terwijl sommige 'statussen' schuilgaan achter een andere, meer specifiek beschreven naam ('Archiefstatus'). Het gevolg is dat we om migratie te ondersteunen nu bij 'Status' nu een depricated waarde ('gearchiveerd') moeten opnemen terwijl we die in andere vorm óók als waarde bij 'Archiefstatus' kennen. Ik zou voorstellen het hele bestaande attribuut 'Status' depricated te verklaren en verder te gaan in de nieuwe statusattributen 'Bewerkings- en vaststellingsstatus' en 'Archiefstatus'.
• Wijziging naam waarde van In bewerking naar In voorbereiding: een concept is in feite ook nog in bewerking. 'In voorbereiding' drukt wat mij betreft iets (maar dit marginaal) beter uit dat sprake is van een fase vóórdat sprake is van concept- of definitieve inhoud.
• Consequent informatieobjectperspectief in beschrijving van betekenis: die gaat nu voor iedere waarde uit van de inhoud van het informatieobject:
  • bij de betekenis van de eerste drie waarden (In voorbereiding, Concept en Definitief) heb ik als uitgangspunt de mate van verandering (of omgekeerd de 'volwassenheid') genomen die van de inhoud van het informatieobject bij het bereiken van een status verwacht mag worden.
  • bij de betekenis van de laatste twee waarden (Ter vaststelling en Vastgesteld) heb ik het besluitvormingsproces als uitgangspunt genomen maar ook geprobeerd (met name bij Vastgesteld) geprobeerd te beschrijven wat het doorlopen van dit proces betekent voor de inhoud van het informatieobject ("het is bekrachtigd").

[hdksi]

Archiefstatus

Beschrijving:

Geeft aan in hoeverre het informatieobject duurzaam toegankelijk is en op het voorgeschreven moment vernietigd of overgebracht kan worden.

Toegestane waarden:

Waarde	Betekenis
Mutabel	Vorm en inhoud van het informatieobject kunnen vrijelijk veranderen.
Onveranderlijk	Vorm en inhoud van het informatieobject zijn onveranderlijk geworden zodat authenticiteit en integriteit gewaarborgd zijn.
Duurzaam toegankelijk	Het informatieobject voldoet aan de eisen van duurzame toegankelijkheid en kan op het voorgeschreven moment vernietigd of overgebracht worden.

Toelichting:

Deze set statussen geeft aan in hoeverre het informatieobject voldoet aan de eisen voor 'duurzaam toegankelijk overheidsinformatie'. Of in andere woorden: in hoeverre het informatieobject als 'gearchiveerd' kan worden beschouwd.

De waarde Mutabel geeft aan dat het informatieobject nog vrijelijk bewerkt kan worden. Het informatieobject bevindt zich in wat ook wel de 'dynamische fase' genoemd werd.

De waarde Onveranderlijk geeft aan dat het informatieobject is 'bevroren'. Inhoud en vorm liggen nu vast. Hiermee zijn authenticiteit en integriteit van het informatieobject gewaarborgd. Door het uitvoeren van informatiebeheershandelingen kan nog wel de duurzame toegankelijkheid van het informatieobject worden verbeterd. Voor het verkrijgen van deze status is het echter geen eis dat het informatieobject aan alle relevante bijbehorende eisen voldoet.

De waarde Duurzaam toegankelijk geeft aan dat informatiebeheershandelingen ertoe hebben geleid dat het informatieobject voldoet aan relevante eisen voor duurzame toegankelijkheid. Het is vindbaar, beschikbaar, leesbaar, interpreteerbaar, betrouwbaar en toekomstbestendig. Bovendien kan het informatieobject op het voorgeschreven moment vernietigd of overgebracht worden. Informatiebeheeractiviteiten houden niet op bij het bereiken van deze status. Het duurzaam toegankelijk houden van informatieobjecten vereist, zeker bij lange bewaartermijnen, immers voortdurend aandacht.

Een informatieobject hoeft niet altijd alle archiefstatussen te doorlopen. Ontvangen informatieobjecten worden (door de gemeente) niet bewerkt en krijgen dus direct na ontvangst de status Onveranderlijk of - als aan de bijbehorende eisen is voldaan - Duurzaam toegankelijk. En als de daarvoor benodigde informatiebeheeractiviteiten worden uitgevoerd als onderdeel van het primaire proces waarin een informatieobject ontstaat ('archiveren by design') kan een informatieobject van Mutabel ineens Duurzaam toegankelijk worden.

Rationale bij wijzigingen voorgesteld ten opzichte van voorstel van 17 november:

• Opname extra waarde Onveranderlijk: de Standaarden voor Zaakgericht werken dwingen middels (veelbesproken ;) business rules af dat informatieobjecten een bepaalde (archief)status bereikt hebben bij het afsluiten van een zaak. Wat ze echter functioneel niet kunnen is garanderen dat het informatieobject daadwerkelijk is 'gearchiveerd' (dat wil zeggen volledig 'duurzaam toegankelijk'). Wat ze wel kunnen is in sommige gevallen enige archiveringsparameters afleiden en autorisaties intrekken. Dit zijn belangrijke stappen op wég naar archivering, maar het is niet (of in ieder geval niet altijd) de héle archivering. Dit leidt tot een keuze:
  1. ofwel we verwijderen de bedrijfsregels;
  2. ofwel we wachten met het afsluiten van een zaak totdat de bij het dossier horende informatieobjecten volledig zijn gearchiveerd;
  3. ofwel we sluiten de zaak gewoon af waarna informatiebeheerders zonder eenvoudig onderscheid te kunnen maken mogen uitzoeken welke informatieobjecten met statuswaarde gearchiveerd nu wel of niet 'volledig' gearchiveerd zijn;
  4. ofwel we voegen een statuswaarde toe die het mogelijk maakt onderscheid te maken tussen het 'onveranderlijk maken van vorm en inhoud van het informatieobject' en volledige 'duurzame toegankelijkheid'. Mijn voorstel behelst deze laatste optie.
• Wijziging naamgeving Nog te archiveren en Gearchiveerd in Mutabel en Duurzaam toegankelijk: beide zijn in zekere zin het gevolg van het openen van de extra statuswaarde en de daaruit ontstane noodzaak meer precies te zijn in de betekenis van de overige waarden. Mutabel is een discutabele (maar de beste die ik kon vinden) term om aan te geven dat een informatieobject nog niet Onveranderlijk is. Duurzaam toegankelijk is een meer precieze, want beter beschreven en ondersteund begrip om aan te duiden wat 'gearchiveerd' nu eigenlijk betekent.

[hdksi]

Indicatie 'inhoud is vervallen'

Beschrijving:

Geeft aan of de inhoud van het informatieobject vervallen (dus niet langer geldig) is.

Toegestane waarden:

Waarde	Beschrijving
Ja	De inhoud van het informatieobject is vervallen
Nee	De inhoud van het informatieobject is niet vervallen.

Toelichting:

Het begrip 'vervallen' in deze indicatie moet gelezen worden als 'ongeldig geworden'. Geldigheid moet in deze context zowel 'breed' als 'eng' gelezen worden.

• Breed in de zin dat verlies van geldigheid van de inhoud van een informatieobject zowel het gevolg kan zijn van een formele procedure, zoals de herroeping van een besluit, als van informele handelingen, zoals een bouwtekening waarvan de inhoud door het verschijnen van een meer actuele illustratie achterhaald is. Hoewel we in het dagelijks taalgebruik in het laatste geval waarschijnlijk zouden zeggen dat de bouwtekening "niet meer actueel is", benoemen we die in de context van deze indicatie als "niet meer geldig, dus vervallen".

• Eng in de zin dat verlies van geldigheid niet betekent dat een informatieobject in het geheel geen waarde meer heeft. Een herroepen besluit kan immers aanleiding geven voor aantekenen van bezwaar of beroep. En de 'vervangen' bouwtekening kan vanuit cultuurhistorisch perspectief best heel interessant (blijken te) zijn.

Rationale bij wijzigingen voorgesteld ten opzichte van voorstel van 17 november:

• Verwijdering van in waardedefinities gehanteerde begrip 'relevantie', koppeling van begrip 'vervallen' aan 'geldigheid': deze wijziging is het gevolg van het gebruik van 'vervallen'. Dit wordt vrijwel altijd in tandem gebruikt met 'geldigheid'. En hoewel dat misschien niet altijd zo lijkt (zie het voorbeeld van de bouwtekening in de toelichting hierboven) is geldigheid, en niet relevantie volgens mij waar het dit attribuut uiteindelijk over gaat - de door @johannesbattjes in de eerste post genoemde voorbeelden ontkrachten dit in ieder geval niet. Relevantie heeft met waarde te maken, en waarde laat zich moeilijk beoordelen of voorspellen; het is daardoor heel moeilijk om te stellen wanneer een informatieobject niet meer van waarde of relevant is. Dat het niet meer geldig is, is daarentegen veel eenvoudiger te constateren. Immers: "iemand heeft dat verklaard" of "iets anders heeft het vervangen".

Indicatie 'persoonsgegevens aanwezig'

Beschrijving:

Geeft aan of het informatieobject persoonsgegevens aanwezig zijn die niet openbaar gemaakt mogen worden.

Toegestane waarden:

Waarde	Beschrijving
Ja	In het informatieobject zijn persoonsgegevens aanwezig die niet openbaar gemaakt mogen worden.
Nee	In het informatieobject zijn geen persoonsgegevens die niet openbaar gemaakt mogen worden.

Toelichting:

In deze indicatie wordt expliciet verwezen naar "persoonsgegevens die niet openbaar gemaakt mogen worden". Dit betekent niet dat voor ieder informatieobject waarin persoonsgegvens aanwezig zijn de waarde 'ja' gekozen moet worden. Het kan immers gerechtvaardigd zijn persoonsgegevens wél openbaar te maken.

Merk op dat de áfwezigheid van persoonsgegevens niet kan worden gezien als vrijbrief voor openbare publicatie. Er kunnen immers andere beperkingsgronden (vertrouwelijk gedeelde bedrijfs- en fabricagegegevens, schending van belangen gediend met opsporing en vervolging van strafbare feiten, ...) of auteursrechtelijke beperkingen gelden.

Rationale bij wijzigingen voorgesteld ten opzichte van voorstel van 17 november:

• Geen ingrijpende wijzigingen voorgesteld; 'vrijelijk' laten vervallen omdat 'openbaarmaking' die vrijelijkheid reeds impliceert. Verder alleen toelichting toegevoegd.

[johannesbattjes]

Commentaar bij het voorstel van @hdksi

Aanscherping van de definities: heel fijn en verhelderend. Punten waar wij tegen aan lopen:

• De null-waardes uit ons voorstel zijn vervallen in het hdski-voorstel. Is daar een reden voor? Bij veld Bewerkings- en vaststellingsstatus bijvoorbeeld: dit is nu niet verplicht. Als een waarde wel verplicht wordt moet bij miljoenen documenten een statuswaarde toegevoegd worden (en welke dan). Dit geldt ook voor de andere statussen.
• Het feit dat Bewerkings- en vaststellingsstatus naast status komt, betekent mogelijk dat we beide velden moeten gaan vullen (omdat systemen die niet op de laatste versie zitten de oude waarde hanteren). Zonder dubbele opslag moeten beide systemen tegelijk overgaan op het nieuwe veld (en moet de status in DRC tegelijk gemigreerd zijn). Handhaven van veld status lijkt ons daarom beter. Daarnaast kent ook zaak de velden status en archiefstatus dus de naamgeving is wel bekend bij ZGW-gebruikers.
• Het verschil tussen de derde waarde bij archiefstatus (duurzaam toegankelijk) en de tweede (onveranderlijk) is voor ons nog niet helder genoeg om te weten op welk moment een document van het een in het ander over gaat. Daarnaast lijken sommige aspecten van duurzaam toegankelijk (zoals vindbaarheid) meer een kenmerk van het systeem dat het document beheert dan van het document zelf. Voorstel: nu beginnen met twee waardes en eventueel later een derde toevoegen.
• Bij bevatPersoonsgegevens is de waarde onbekend niet meegekomen. Is daar een reden voor?

Johannes en Michiel

[hdksi]

De null-waardes uit ons voorstel zijn vervallen in het hdski-voorstel. Is daar een reden voor? Bij veld Bewerkings- en vaststellingsstatus bijvoorbeeld: dit is nu niet verplicht. Als een waarde wel verplicht wordt moet bij miljoenen documenten een statuswaarde toegevoegd worden (en welke dan). Dit geldt ook voor de andere statussen.

Hierboven schreef ik over nullwaarden en alternatieven voor het toestaan daarvan

• Ik heb wat moeite met een aantal optionaliteiten. Ik snap dat we deze kenmerken in databases omwille van 'oude/bestaande' documenten niet verplicht kunnen stellen, maar is het voor nieuwe registraties, gemaakt met een naar aanleiding van deze wijzigingen bijgewerkte API, niet (eventueel op termijn) mogelijk te werken met verplichte vastlegging en defaultwaarden (persoonsgegevens: onbekend / ontvangen: neen / vervallen: neen) in plaats van standaard verwarrende - want wat betekenen ze nu eigenlijk? - nullwaarden?
• Meer specifiek: hoewel ik weet en snap dat ze soms moeten mogen vind ik nullable booleans (het datatype waarop de bij vervallen en ontvangen toegestane waarden lijken te hinten) conceptueel vreemd.

Deze opmerkingen laat ik even zitten; hoor graag van belanghebbenden in hoeverre zij eventueel 'last' hebben van een onduidelijke betekenis ("attribuut bestond bij eerste vastlegging nog niet dus ik kon het niet invullen", "consumer heeft dit attribuut niet geïmplementeerd", "geen", "ik weet het niet", "het is in dit geval niet relevant", "...") van nullwaarden.

Dit betekent dat ik bij de 'toegestane waarden' in de voorstellen hieronder geen rekening heb gehouden met waarden als Onbekend, Niet van toepassing etc.

Ten overvloede: als iedereen behalve ondergetekende het eens is over het toestaan van nullwaarden in plaats van het gebruik van (meer) betekenisvolle enumeratiewaarden ga ik daar (als dat al zou kunnen) niet voorliggen.

Het feit dat Bewerkings- en vaststellingsstatus naast status komt, betekent mogelijk dat we beide velden moeten gaan vullen (omdat systemen die niet op de laatste versie zitten de oude waarde hanteren). Zonder dubbele opslag moeten beide systemen tegelijk overgaan op het nieuwe veld (en moet de status in DRC tegelijk gemigreerd zijn). Handhaven van veld status lijkt ons daarom beter. Daarnaast kent ook zaak de velden status en archiefstatus dus de naamgeving is wel bekend bij ZGW-gebruikers.

Deze opmerking hebben we intern besproken, maar niet helemaal begrepen. Is het nu gewenst dat het bestaande attribuut status met de in de huidige versie toegestane enumeratiewaarden wordt gehandhaafd of de naam van dat attribuut met nieuwe (en eventueel ook oude) waarden?

Het verschil tussen de derde waarde bij archiefstatus (duurzaam toegankelijk) en de tweede (onveranderlijk) is voor ons nog niet helder genoeg om te weten op welk moment een document van het een in het ander over gaat. Daarnaast lijken sommige aspecten van duurzaam toegankelijk (zoals vindbaarheid) meer een kenmerk van het systeem dat het document beheert dan van het document zelf. Voorstel: nu beginnen met twee waardes en eventueel later een derde toevoegen.

Door het opnemen van drie waarden maken we expliciet dat het niet langer een voorwaarde is dat documenten die onderdeel zijn van het zaakdossier bij het afsluiten van een zaak volledig gearchiveerd (=duurzaam toegankelijk) zijn. Volgens mij sluit dat aan bij de praktijk waarin daarvan lang niet altijd sprake is, terwijl omwille van een beperkte set statussen en gedragsregel zrc-022 bij afsluiten wel de waarde gearchiveerd moet worden toegekend. Wellicht kan ik dit mondeling toelichten.

Bij bevatPersoonsgegevens is de waarde onbekend niet meegekomen. Is daar een reden voor?

Hiervoor geldt hetzelfde als voor de de discussie over nullwaardes versus (meer) betekenisvolle enumeratiewaarden (en dus geldt hier de reactie bij de eerste opmerking).

[johannesbattjes]

Hoi @HenriKorver we zien dat er een nieuwe DRC 1.5 redoc is, fijn! Wanneer gaat deze de reviewronde in?

[hdksi]

Ondertussen is een consultatie begonnen waarin belanghebbenden kunnen reageren op de naar aanleiding van deze user story voorgestelde wijzigingen in de Documenten API-standaard.

Ten opzichte van de voorstellen hierboven (specifiek mijn reactie van 18 december is na overleg met de indieners de naam van de property 'bewerkingsEnVaststellingsstatus' (terug)gewijzigd naar status en die van de bijbehorende waarde in_voorbereiding naar in_bewerking. Beide om beter aan te sluiten bij de naamgeving van de bestaande property en waarde.

Op detail is verder een aantal betekenissen aangepast. Een volledig overzicht van alle voorgestelde wijzigingen plus een aantal vragen is te vinden in de toelichting.

De concept-OAS is hier gepubliceerd (Redoc).

Reageren op deze op deze wijzigingen? Dat kan tot en met maandag 26 februari in deze Github discussie.

[HenriKorver]

Vanaf ongeveer dit punt, te weten https://github.com/VNG-Realisatie/gemma-zaken/discussions/2407#discussioncomment-8665764, moeten we dit issue weer oppakken. M.a.w. het opstellen van een 2.0 versie met

• bevatNietOpenbarePersoonsgegevens (met de nu voorgestelde uitzonderingsgrond-waardes)
• uitbreiding van de waardelijst voor status zoals voorgesteld
• property 'archiefstatus'
• mogelijkheid voor het relateren 'andere versies' (dus een link tussen origineel EIO en geanonimiseerd EIO)

[Jinze82]

@HenriKorver Bij ons is de behoefte hierna nog steeds aanwezig. Bij het implementeren van de WOO is gebleken dat we nu vooral snel behoefte hebben aan de volgende items:

• bevatNietOpenbarePersoonsgegevens (met de nu voorgestelde uitzonderingsgrond-waardes)
• mogelijkheid voor het relateren 'andere versies' (dus een link tussen origineel EIO en geanonimiseerd EIO)

[HenriKorver]

@Jinze82 Ik heb je wensen neergelegd bij de product owner