Als ontwikkelaar wil ik duidelijkheid over "documenten" in het DRC

[joeribekker]

...zodat ik het DRC kan gebruiken waar het daadwerkelijk voor bedoeld is: Documenten en niet InformatieObjecten.

Bij de laatste leveranciersdag van VNG heb ik gesproken met Jan Koers over archivering. Hier bleek dat een Document een InformatieObject is, maar een InformatieObject is niet altijd een Document. Een InformatieObject kan net zo goed een Zaak zijn.

Hier ligt een probleem in het DRC (en het huidige RGBZ) waar InformatieObject eigenlijk als synoniem voor Document wordt gebruikt (ja, het kan ook een e-mail zijn, is dus ook een document). Het DRC bevat documenten. We stoppen er geen Zaak in.

Mijn voorstel is om InformatieObject daarom te hernoemen naar Document. Laten we tegelijkertijd EnkelvoudigInformatieObject schrappen aangezien dat alleen maar nut heeft in combinatie met zijn tegenhanger: SamengesteldInformatieObject die we helemaal niet hebben of gebruiken.

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.
• Globale oplossingsrichting bekend
• 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 en waarmee de user story getest kan worden.
• De technische specificatie (standaard.md) is gepubliceerd leesbaar
• Gebruikte gegevensmodel is na iedere iedere sprint bijgewerkt.

Acceptatiecriteria

• De DSO URI- en API-strategie worden gevolgd of afwijkingen zijn vastgelegd als ontwerp keuze
• Er zijn geen bekende GEMMA tegenstrijdigheden of afwijkingen zijn vastgelegd.

Taken

• Hernoemen EnkelvoudigInformatieObject naar Document in DRC en andere componenten
• Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
• Genereren/opstellen van OAS 3.0 [verantwoordelijke]
• Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]
• Documentatie bijwerken
• Gegevensmodel bijwerken

[TCIMEddy]

@Hugo-ter-Doest Prio?

[Hugo-ter-Doest]

Uit het RGBZ:

?Informatieobject? is een generiekere term voor het veelgebruikte begrip ?document? dat beperkter van reikwijdte is. Een informatieobject kan van alles zijn, ongeacht aard en vorm: een tekstverwerkingsdocument, een papieren brief, een webpagina, een landkaart, een foto, een geluidsopname, een dataset, een blog, etcetera. En ook een digitaal ontvangen of gecreeerd informatieobject dat bestaat uit meerdere fysieke informatieobjecten, zoals een aanvraag (als tekstdocument) met bijbehorende tekening (CAD-formaat) en berekening (spreadsheet) of een email met bijlage(n). Net zoals dezelfde aanvraag op papier met bijlagen als één informatieobject beschouwd kan worden. De fysieke vorm van hetgeen ontvangen of gecreeerd is, is dus niet (alleen) bepalend voor de afbakening van dat wat als informatieobject beschouwd wordt. Voor de leesbaarheid hanteren we in toelichtingen in dit informatiemodel hier en daar wel de term ?document? waarmee we formeel ?informatieobject? bedoelen. Het INFORMATIEOBJECTTYPE betreft de typering van informatieobjecten naar hun aard zoals gehanteerd door de zaakbehandelende organisatie. Elk informatieobjecttype komt overeen met of valt binnen de generieke typering van informatieobjecten zoals landelijk gehanteerd, de informatieobjecttype-omschrijving generiek . Het informatieobjecttype stelt organisatie in staat hun eigen typering aan te houden en, d.m.v. de relatie naar Informatieobjecttype-omschrijving generiek, toch aan te kunnen sluiten op de landelijk gehanteerde typering generiek.

Ik zie wel degelijk meerwaarde van het begrip informatieobject. Document is te beperkt. En ik lees hier niet dat een informatieobject ook een zaak kan zijn. Dat moet je ook niet mogelijk maken; daarvoor heb je deelzaken, vervolgzaken, etc.

Wel ben ik met je eens dat we het onderscheid enkelvoudig/meervoudig moeten loslaten en gewoon van informatieobjecten moeten spreken.

[TCIMEddy]

@Hugo-ter-Doest prio?

[michielverhoef]

Als een Informatieobject ook een zaak kan zijn zouden van die zaak ook dezelfde gegevens vastgelegd moeten kunnen worden als nu in de ZRC gebeurt.

Als ik het zo lees is gaat het niet over een Informatieobject (zoals beschreven in het RGBZ) maar over een Object-met-informatie. Dat laatste kan heel goed een zaak zijn maar dat is niet hetzelfde als een Informatieobject zoals beschreven in het RGBZ.

Ik zie toch wel verschil tussen een enkelvoudig en een samengesteld informatieobject. In het RGBZ staat:
"Een INFORMATIEOBJECT waarbinnen twee of meer ENKELVOUDIGe INFORMATIEOBJECTen onderscheiden worden die vanwege gezamenlijke vervaardiging en/of ontvangst en/of vanwege aard en/of omvang als één geheel beschouwd moeten worden dan wel behandeld worden.,"

(https://www.gemmaonline.nl/index.php/Rgbz_2.0/doc/objecttype/samengesteld_informatieobject)

Het verschil is dat er twee of meer Informatieobjecten zijn die bij elkaar horen en als één geheel verwerkt moeten worden. Bijvoorbeeld een specificatie, een OAS 3 bestand en functionele documentatie van een standaard.

Die drie delen horen bij elkaar maar kennen hun eigen inhoud (de binary blob in de database) en ook hun eigen versionering en metadata. Om de juiste versies van de onderdelen bij elkaar te houden is het samengesteld informatieobject bedoeld. Een Samengesteld Informatieobject heeft zelf geen inhoud maar bestaat uit verwijzingen naar Enkelvoudige Informatieobjecten met elk hun eigen inhoud.

Je zou kunnen zeggen dat een Samengesteld Informatieobject een folder/map is maar het is zeker niet hetzelfde als een Enkelvoudig Informatieobject.

[michielverhoef]

Wel ben ik met je eens dat we het onderscheid enkelvoudig/meervoudig moeten loslaten en gewoon van informatieobjecten moeten spreken.

In #1695 wordt juist expliciet gevraagd naar het toevoegen van samengestelde documenten.

Gezien de meerwaarde van de term informatieobject en de vraag naar samengestelde documenten en dat in combinatie met backwards compatibility sluit ik dit issue. Mochten er echt problemen ontstaan door het begrip informatieobject kijken we wel hoe we dat goed uit kunnen leggen.