Als gemeente wil ik dat de archiveringsfunctionaliteit van de GEMMA ZDS-API's aansluit bij het voorstel voor herziening van de GEMMA-architectuur voor duurzame toegankelijkheid

[hdksi]

...zodat ik ook in de toekomst de duurzame toegankelijk van zaken kan waarborgen 20181216_Voorstel_GEMMA_Architectuur_Duurzame_Toegankelijkheid.pdf.

Ingebracht namens André Plat.

Bepaling prioriteit door PO

• [ ] verbreding of verdieping API's
• [ ] stimuleert gebruik door gemeenten
• [ ] stimuleert gebruik door leveranciers

... eventueel nog toelichting door PO

Definition of ready

• [ ] Iedereen in het team begrijpt de user story
• [ ] de gewenste (aanvulling op de) functionaliteit van de API's duidelijk en beschreven is.
• [ ] Is klein genoeg (maximaal 1/5 van sprint)
• [ ] Product Owner akkoord en voorzien van prioriteit (mag alleen afgevinkt worden door PO)
• [ ] Idee hebben van hoe deze user story kan worden gedemonstreerd.
• [ ] Userstory is voorzien van een analyse (met daarin architectuur, IM, technische beslissingen afgestemd met team)
• [ ] Vastgelegd in Github en geplaatst in kolom ready

Definition of done

• [ ] Er is een OAS 3.0 specificatie
• [ ] Er is een referentieimplementatie
• [ ] Er zijn tests aanwezig die de wijziging aantonen
• [ ] De technische specificatie (standaard.md) is gepubliceerd leesbaar

Acceptatiecriteria

• [ ] De DSO URI- en API-strategie worden gevolgd of afwijkingen zijn vastgelegd als ontwerp keuze
• [ ] Eventueel gemaakte ontwerp keuzes zijn gedocumenteerd
• [ ] Er zijn geen bekende GEMMA tegenstrijdigheden of afwijkingen zijn vastgelegd.

Taken

• [ ] Implementeren in referentie-implementatie [verantwoordelijke]
• [ ] Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
• [ ] Genereren/opstellen van OAS 3.0 [verantwoordelijke]
• [ ] Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]

[TCIMEddy]

@Hugo-ter-Doest prio toekennen

[michielverhoef]

Wanneer informatieobjecten conform het RGBZ 2 opgeslagen worden zou alle informatie voor het vullen van een TMLO bericht aanwezig moeten zijn. Dat was het uitgangspunt voor een eventueel addemdum op ZDs 1.n waarbij de ontbrekende gegevens beschreven zouden worden zodat deze als extraElementen toegevoegd kunnen worden. Achteraf bleek dat niet nodig te zijn omdat het om gegevens ging die eigenlijk in het DMS (GEMMA 1 referentiecomponent) vastgelegd moeten worden en voor het afhandelen van zaken niet van toepassing zijn. NB. archiveringsfunctionaliteit is volgens mij geen onderdeel van het referentiecomponent DRC (https://www.gemmaonline.nl/index.php/GEMMA2/0.9/id-0e99ec6c-283a-4ec9-8efa-e11468e6b878) maar de gegevens (informatieobjecten en bijbehorende metadata) moeten zodanig opgeslagen worden dat archivering kan plaats vinden door een archiefbeheercomponent (https://www.gemmaonline.nl/index.php/GEMMA2/0.9/id-b209fee8-d39a-4699-b0b4-02273c35c8c1)

Dan komt bij mij gelijk de vraag boven: wordt archivering onderdeel van de zaakgericht werken standaard of een aanpalende standaard? Dit ook om de scope van het project een beetje hanteerbaar te houden. ;-)

[Hugo-ter-Doest]

@michielverhoef Het gebruik van het woord archivering is problematisch hier. Archivering is in die zin onderdeel van de ZGW API's dat archivering start met het creëren van een zaak. Vanaf dat moment moet je ervoor zorgen dat metadata voldoet aan een aantal metadata-standaarden (RGBZ, imZTC, TMLO). Als je dat tijdens de gehele levenscyclus van een zaak volhoudt (handhaaft, valideert) is overdracht naar een andere registratie (zoals een eDepot) gemakkelijk(er), in die zin dat alle benodigde metadata aanwezig is. De mapping/conversie is dan eenvoudig.

[Hugo-ter-Doest]

In de notitie wordt ervan uitgegaan dat er na 20 jaar een overdracht zal plaatsvinden naar een eDepot, naar een ander(e) registratie/systeem dus. Vooralsnog volgen wij deze gedachte. Dat betekent dat we bij de ZGW API's voornamelijk moeten zorgen dat voldaan wordt aan eisen m.b.t. metadata zodat de overdracht mogelijk is. Het duurzaam toegankelijk houden van bestandsformaten lijkt me daarmee een taak voor het eDepot, en niet een taak van de ZGW API's.

[hdksi]

Eens met beiden: volgens mij kan aan de belangrijkste uitgangspunten in dit document worden voldaan door zorgvuldig en volgens standaarden te metadateren.

Overigens vraag ik me af of de opmerking over het e-Depot ook stond in de versie die ik gereviewd heb: die lijkt namelijk in tegenspraak met de in het rest van het document genoemde uitgangspunten. Waarom zou je immers nog overdragen als je bij de bron reeds aan alle requirements voor duurzame toegankelijkheid hebt voldaan?

[MarcoKlerks]

Waarom zou je immers nog overdragen als je bij de bron reeds aan alle requirements voor duurzame toegankelijkheid hebt voldaan?

Als we te bewaren stukken in CommonGround willen laten staan, dan moeten college's B&W conform de Archiefwet deze aanwijzen als archiefbewaarplaats. De VNG zou dit dan aan hen moeten adviseren. Het NA zal daar het e.e.a. van vinden (o.a. kritische vragen stellen over de duurzaamheid van CommonGround) en zal haar zorgen uiten naar de minister. Vergeet niet dat zij samen met alle RHC's (regionale archiefiensten) op dit moment veel investeren in e-depots!

Politiek gedoe kost tijd. Met CommonGround willen we juist de vaart erin houden. Vooralsnog zorgen we er dus voor dat er klassiek overgebracht kan worden. Wanneer daar landelijk draagvlak voor is, kan dat gewijzigd worden.

[hdksi]

@MarcoKlerks mijn opmerking moet gezien worden in relatie tot het in de story genoemde document en de daarin beschreven uitgangspunten. Ik ben het helemaal met je eens dat een bruikbare standaard moet aansluiten op de (hedendaagse) werkpraktijk en dat dus functionaliteit voor overdragen (naar een e-depot of anders) nodig is.

[michielverhoef]

@hdksi is dit issue nog van toepassing of moet hier met de nieuwste ontwikkelingen in het achterhoofd nog eens goed naar gekeken worden?