Per document wil ik een geanonimiseerde versie kunnen relateren

[johannesbattjes]

of aangeven dat het originele document al anoniem is.

Zodat bij publicatie op bijvoorbeeld officiele bekendmakingen of Plooi het systeem

• automatisch geanonimiseerde documenten kan herkennen en publiceren
• documenten zonder geanonimiseerde versie kan presenteren en aanbieden aan een anonimiseringstool.

[michielverhoef]

Uit de user story begrijp ik dat het mogelijk is dat een document anoniem is zonder dat er een niet-anonieme versie van bestaat? Er hoeft dus niet gevalideerd te worden dat een geanonimiseerd document altijd gerelateerd is aan een niet-geanonimiseerd document?

[johannesbattjes]

Ja, de verzoekpdf uit DSO en publiceerbare aanvraag uit OLO zijn voorbeelden van inkomende documenten die al anoniem zijn vanaf het begin van hun bestaan. Voorbeeld van een uitgaand document dat anoniem is: we kennen een gemeente die een beschikking produceert die direct al anoniem is.

[michielverhoef]

In dat geval denk ik dat we twee attributen nodig gaan hebben:

• geanonimiseerd (boolean)
• gerelateerdInformatieobject (url).

Over dat laatste twijfel ik nog. Moet deze relatie beperkt blijven tot wel/niet geanonimiseerde documenten of zou je ook andere relaties kunnen/willen leggen? Hoe ga je dan de betekenis van die relatie duiden?

Of is het handiger om deze relatie expliciet te leggen met twee attributen: isGeanonimiseerdeVersieVan en isGeanonimiseerdAls of zo? Er zou dan wel een regel moeten zijn dat wanneer isGeanonimiseerdeVersieVan alleen gevuld kan worden wanneer geanonimiseerd de waarde true heeft.

Eventuele andere relaties kunnen dan ook expliciet gemaakt worden wanneer deze noodzakelijk blijken.

[johannesbattjes]

Eens met de twee attributen.

Ik kan me voorstellen dat andere relaties nodig zijn (Ondertekende versie van. Gestempelde versie van). Maar of je dit meteen generiek moet opzetten - ik ga het navragen

[hdksi]

Suggestie is voor mogelijke relaties in ieder geval te kijken naar waarden die PLOOI (op dit moment, maar stabiliteit nog onduidelijk) verwacht. Wijkt wel af van wat MDTO suggereert. Hierover is KOOP volgens mij nog met het Nationaal Archief in conclaaf.

[Jinze82]

Ik wil alleen de scope zoals het is omschreven iets wat verbreden. Het doel is documenten klaar te maken voor publicatie, daarbij letten we niet alleen op “persoonsgegevens” en praten daarom over redigeren van documenten voor publicatie.

Johannes omschrijft de twee situaties. In de discussie hoe dit op te lossen lijkt mij de reden waarom documenten ontstaan relevant.

1. Om de toegankelijkheid te garanderen van documenten die we zelf creëren en willen publiceren, houden we deze zoveel mogelijk vrij van gegevens die moeten worden geredigeerd. De reden hiervoor is dus niet zo zeer om onder het redigeer werk uit te komen, maar de leesbaarheid voor iedereen hiervan te waarborgen. Tussen creatie en publicatie zit vaak een bewerkingsfase waar je geen invloed op hebt. Er kunnen na het genereren van een document alsnog gegevens in komen die moeten worden geredigeerd. Moet je daarom niet uitgaan dat alles wat bewust gepubliceerd wordt ook eerst geredigeerd wordt?
2. Op te ontvangen documenten hebben we deze invloed niet, maar daar zijn we wel voor verantwoordelijk. Om de toegankelijkheid van deze documenten te garanderen gaan wij altijd uit van pseudonimiseren in plaats van anonimiseren voor publicatie. Daarmee bedoelen we dat Tilburg of 17-11-1980 wordt weggehaald en dit door een generieke tekst als woonplaats op geboortedatum wordt vervangen.

[michielverhoef]

@Jinze82 De vraag is nu hoe we bij een geredigeerde versie (mooie term) aan kunnen geven dat het een geredigeerde versie betreft en bij welke ongeredigeerde versie van het document deze hoort.

Zo te zien dekt de PLOOI waardenlijst niet echt de lading terwijl die van MDTO in ieder geval de relaties heeft versie en is versie van kent. Die zouden wel kunnen passen, al zijn ze wel heel generiek.

[hdksi]

Eens met @Jinze82 dat publicatie- en hergebruikbeperkingen een andere grond kunnen hebben dan alleen de aanwezigheid van persoonsgegevens. MDTO onderkent daarvoor beperkingGebruik. (Een subset hiervan) zou je kunnen gebruiken om bij documenten die niet gepubliceerd kunnen worden aan te geven welke beperkingen publicatie verhinderen. Deze informatie zou, aangevuld met een indicatie dat een document überhaupt openbaar toegankelijk gepubliceerd moet worden (want dat geldt niet voor alle documenten) gebruikt kunnen worden om documenten zonder geanonimiseerde versie te selecteren voor presenteren en aanbieden aan een anonimiseringstool.

Daarnaast kan ik me voorstellen dat het voor wél publiceerbare documenten zinnig is dit expliciet duidelijk te kunnen maken én dat het handig kan zijn een (of meerdere?) url('s) te kunnen opnemen die verwijzen naar (een) publicatieplaats(en). Deze informatie zou gebruikt kunnen worden om automatisch geanonimiseerde documenten te herkennen en publiceren.

(Digitale) toegankelijkheid is weer een andere tak van sport. Ik ken geen bestaande standaarden die conventies omvatten waarmee aangegeven kan worden of een document toegankelijk is (gemaakt). Omdat toegankelijkheid geldt als wettelijke verplichting voor te publiceren overheidsinformatie weet ik ook niet of het nodig of zinvol is daarover expliciet iets te kunnen vastleggen.

[hdksi]

Naar aanleiding van bijdrage aan #1929 het inzicht dat publicatiekenmerken en relaties naar publicatieversies mogelijk moeten kunnen worden aangelegd na afsluiten van de zaak. In het kader van dit issue dus ook kijken naar eventuele gevolgen voor het proces bij afsluiten en archiveren van de zaak en bijbehorende bedrijfsregels.

[michielverhoef]

Hoewel niet precies hetzelfde is #1695 ook afhankelijk van een vorm van relateren.
Daar zouden dan de relatie heeftNodig en isVereistDoor voor gebruikt kunnen worden?

[Jinze82]

Bij de kopie van het origineel hoort volgens mdto ook een event registratie van het type "kopie".
https://www.nationaalarchief.nl/archiveren/mdto/begrippenlijst-metagegevensschema#collapse-102680

Tenminste mijn interpetatie. Hoe zien jullie dit? Of kan dit op een andere manier eruit worden gehaald bij overdragen.

[HenriKorver]

Oeps, ik had dit issue inderdaad per ongeluk en ten onrechte afgesloten. Er waren problemen met mijn touchpad :-)

[erwinkusters]

#2079 heeft hier ook me te maken. Graag z.s.m. oppakken.

Met vriendelijke groet,

Erwin Kusters
SSC Beheer Bedrijfsinformatiesystemen | Functioneel Beheerder
T (043) 350 31 58 | M (06) 55 41 57 49 | [email protected]
Mosae Forum 10, 6211 DW | Postbus 1992, 6201 BZ Maastricht | www.gemeentemaastricht.nl

[RemcovBeelen]

Dit is ook een wens vanuit de gemeente Nieuwegein

[Nunspeet]

Dit is ook een uitdrukkelijke wens vanuit de gemeente Nunspeet

[michielverhoef]

Qua oplossingsrichting is dit probleem vergelijkbaar met #2079 . Dat issue wordt komende week opgepakt en dan zou dit ticket gelijk ook opgelost kunnen zijn.

[HenriKorver]

Zie #2079 (comment) voor een oplossing. @johannesbattjes Is dit naar wens?

[johannesbattjes]

De oplossing bij #2079 lijkt me prima, zie aldaar. Wat dan nog ontbreekt is een indicatie dat een document geanonimiseerd is.
Dat kan een origineel document zijn (bijvoorbeeld bij uitgaande doucmenten als document generatie zo is ingericht dat het document anoniem wordt gegenereerd, en bij inkomende een "publiceerbare aanvraag" (OLO)). Maar ook als een geanonimiseerde versie wordt gemaakt is het goed om dat record zelf te kunnen aangeven dat het anoniem is. Michiel Verhoef stelde hier (in dit ticket) een boolean voor voor. Wij willen voor dit veld volgende week nog een voorstel doen samen met een aantal klanten

[HenriKorver]

In #2079 is er discussie ontstaan over de voorgestelde oplossing. Dus helaas gaat het ontwerp weer even terug naar de tekentafel. Er is ook nog een openstaande vraag over hoe om moeten gaan met potentiële wildgroei in de typering van relaties tussen documenten.