In de StUF-expertgroep-bijeenkomst op 17 juni is een discussie ontstaan over de wijze van modelleren van documenten in het RGBZ. We hebben besloten die discussie op dit forum voort te zetten. Hiermee open ik de discussie.
In bijgaande notitie heb ik de alternatieven op een rijtje gezet. Dit is een bewerkte versie van een eerdere notitie die in de RGBZ-werkgroep bediscussieerd is. Daarin kwamen we uit op de vigerende modellering (versie 0.9.1), overigens niet met algemene stemmen. En van variant 3 was toen nog geen sprake.
Voor de vigerende modellering is gekozen om een aantal redenen:
- het moet mogelijk zijn om zowel individuele documenten als een groep van bij elkaar behorende documenten te kunnen onderscheiden;
- het moet geen verplichting zijn om een document altijd in een groep op te nemen;
- zowel een individueel document als een groep moeten aan een zaak gerelateerd kunnen worden;
- een document in een groep moet aan andere zaken gerelateerd kunnen worden dan de zaak waaraan de groep gerelateerd is;
- het gegevensmodel moet zo eenvoudig mogelijk blijven.
De vigerende variant voldoet hieraan m.i. Varianten 1 en 2 voldoen aan meerdere criteria niet. Variant 3 voldoet m.i. niet aan het laatste cirterium, het maakt het model complexer.
Waarom is in versie 0.9.1 toegestaan DOCUMENT ook te gebruiken voor een set documenten en daarmee de relatie van DOCUMENT naar DOCUMENT te wijzigen in maakt deel uit van? Wat is een set documenten: een verzameling documenten die in één envelop binnenkomen, een verzameling documenten die bij elkaar horen (zoals alle onderdelen van een aanvraag bouwvergunning, maar wat dan als ze gescheiden worden opgestuurd) of ? Graag ook uitleg over het gebruik van het gegeven dat documenten in één set zitten.
Verder is te verwachten dat een set documenten andere attributen heeft dan een document. Voorbeeld: in het DMS krijgen de gescande documenten een documentidentificatie, een documentset kan zoiets niet krijgen. Een documentset is nu eenmaal geen document.
Zie voor de motivering van het onderscheiden van DOCUMENT en DOCUMENTSET en de modellering daarvan de eerste post, het daarbij gevoegde document en de toelichting in het RGBZ bij het objecttype DOCUMENT.
Goede vraag: wat is een set documenten? Andere vraag: wat is een document? Oftewel, plat gezegd, wanneer is een stapel A4tjes een document en wanneer zijn het meerdere documenten? De overweging is dat dit nog wel 's van de beschouwer kan afhangen. Waar bij een vergunningaanvraag de postmedewerker de complete aanvraag als een document beschouwd, beschouwt de bouwtechnisch adviseur de bouwtekening als een document. 't is maar hoe je er tegenaan kijkt. Vandaar het onderscheid. Hoe dat in de praktjk uitpakt zal van de daarbij betrokken beschouwers afhangen.
Het lijkt mij te ver gaan om te stellen dat het identificeren van documenten 1 op 1 verbonden is met het scannen daarvan. Als de 'scanmedewerker' beslist om een aanvraag in evenveel documenten te scannen als dat er bijlagen zijn, dan zal 'ie toch ook iets moeten doen om aan te geven dat al die gescande documenten gezamenlijk de aanvraag vormen. Aangezien andere beschouwers dan die scanmedewerker de totale aanvraag als document beschouwen, is het niet meer dan logisch om ook aan dat document (die documentenset) een identificatie te geven.
Al met al geeft dit onderscheid een grote flexibiliteit in het afbakenen van datgene dat als document beschouwd wordt.
Uit de reacties op deze post en via andere kanalen komt een duidelijke voorkeur naar voren om de DOCUMENTENSET als apart objecttype te onderscheiden waarbij zowel DOCUMENT als DOCUMENTENSET als een zaakdocument te beschouwen zijn. Dit neigt naar variant 3. Het nadeel daarvan is m.i. dat deze twee objecttypen een geheel 'eigen leven gaan leiden'. Terwijl ze in de praktijk beide als 'document' beschouwd zullen worden. Het is maar net wie er naar kijkt en of die een (enkelvoudig) DOCUMENT als document ziet dan wel een DOCUMENTENSET. Nadeel is ook dat beide hun eigen identificaties kennen en we dus te maken krijgen met twee groepen identificaties. M.i. sluit dit alles niet aan bij de praktijk. Vandaar in bijgaand document naast variant 3 een vierde variant die deze nadelen ondervangt maar waarin wel (ENKELVOUDIG) DOCUMENT en DOCUMENTENSET aparte objecttypen zijn. Beide zijn hierin verschijningsvormen van het algemene begrip 'document'.
Ik ben het helemaal met Arjan eens dat dit puur een discussie is over cosmetische verschillen. Die kan nog heel lang gaan duren omdat over smaak niet te twisten valt. Met alle vier varianten kunnen we uiteindelijk precies dezelfde dingen bewerkstelligen. Dus laten we ajb niet moeilijk doen en de huidige variant nemen.
Ik stel voor dat als er voor woensdag a.s. geen echte fouten in de huidige variant worden aangetoond dat we alles bij het oude laten.
De opmerking van Henri dat dit zou gaan om een cosmetische discussie is er eentje van het type dooddoener. Net zoals dat stukje over "moeilijk doen". Als je geen commentaar (m.a.w. geen wijzigingen) wilt, zeg dat dan gewoon. Overigens, Arjan zegt m.i helemaal niet dat dit een cosmetische discussie is.
Een Document is geen Documentenset, net zo als een voetballer geen voetbalteam is.
Van mij mag je een documentenset toevoegen, ik ben in dat geval voor variant 4, waarbij je nog wel even goed over de relatie-entiteit Zaakdocument moet nadenken (splitsen?).
Mee eens dat dit een fundamentele keuze is: hoe documenten te modelleren?
Ik heb alle reactie en ideeen nog s overdacht, wat literatuurstudie gedaan en kom tot de conclusie dat de laatste modellering (variant 4) m.i. de beste is. Het sluit aan bij de MoReq, die spreekt over document, record en component, en bij de NEN-norm waarin een samengesteld archiefstuk genoemd wordt, bestaande uit archiefstukken waarvoor ook documenten gelezen mag worden. En het houdt het uiteindelijk bij één objecttype: Document, met twee specialisaties (subtypen): Enkelvoudig document en Samengesteld document.
De laatstgenoemde objecttypen hebben deels verschillende kenmerken maar dees ook dezelfde. Dat zijn de kenmerken van de genera;isatie (supertype) Document. Gezien de aard hiervan heeft deze de relatie naar Zaakdocument wat betekent dat zowel een Enkelvoudig document als een Samengesteld document via Zaakdocument aan een Zaak gerelateerd kan zijn.
Zie verder de specificaties in het RGBZ-document.