RGBZ 1 en 2 kennen de objecttypen samengesteld en enkelvoudig document resp. informatieobject. Het samengesteld informatieobject wordt echter in de door het RGBZ gedefinieerde vorm niet ondersteund door CMIS, want CMIS kent als objecttypen Document en Folder, waarbij een folder meerdere documenten kan bevatten en een document eventueel kan voorkomen in meerdere folders. Daarnaast kan een folder in tegenstelling tot een samengesteld document ook zelf weer folders bevatten.
Het niet aansluiten van RGBZ op het informatiemodel van CMIS zal in de praktijk van de implementatie gaan leiden tot allerlei issues. Het lijkt me daarom goed dat er nog een eens wordt nagedacht over de vraag of RGBZ niet domweg moet aansluiten op het informatiemodel van CMIS en dus Samengesteld informatieobject vervangt door folder en daarbij natuurlijk wel aangeeft dat folders in CMIS de functie kunnen hebben van samengesteld document.
Deze discussie maakt ook duidelijk dat het verstandig zou kunnen zijn om een apart informatiemodel te maken voor het omgaan met informatiedocumenten voor de referentiecomponent DMS. Deze component zou een subset van de services gedefinieerd door CMIS moeten bieden. Deze subset moet bij de referentiecomponent gedefinieerd worden.
Aansluiten bij CMIS, dat lijkt me verstandig. De vraag is evenwel, in welk informatiemodel? Niet in een conceptueel model (semantisch model, SIM). Dat geeft immers implementatie-onafhankelijk de werkelijkheid weer. En CMIS is een implementatie van die werkelijkheid. Het is dan ook voor de hand liggend om in een logisch informatiemodel (UGM) aan te sluiten bij CMIS, indien dat het gewenste implementatiekader is. Een logisch model is immers niet implementatie-vrij. Dat is juist de kracht er van en onderscheidt het van een conceptueel model.
Dus, CMIS-aspecten niet opnemen in het RGBZ, wel in StUF-ZKN.
Voor leveranciers en eenvoudige gebruikers van de technische modellen is het buitengewoon ongemakkelijk als het leesbare semantische model sterk afwijkt van wat in de systemen wordt geïmplementeerd. Het verschil tussen een Folder in CMIS en een samengesteld informatie-object is een voorbeeld van zo'n sterke afwijking. Je moet dan telkens uitleggen wat de achtergrond van die afwijking is. Het is voor iedereen veel eenvoudiger als bij het ontwerp van de semantische modellen al rekening wordt gehouden met wat implementietechnisch handig/mogelijk is.
Wat is er tegen om in RGBZ 2 het samengestelde informatie-object te vervangen door het objecttype Folder uit CMIS. In de toelichting kan je dan aangeven dat een folder ook gebruikt kan worden om de losse A4-tjes uit een scanstraat of foto-tjes van delen van een document weer samen te voegen tot een eenheid. Het lijkt me daarbij ook zinnig om aandacht te schenken aan de plek waar je dan de metadatering vastlegt: bij elk afzonderlijk gescand A4-tje of eenmalig op het niveau van het folder-object. Is dit issue helder beschreven in RGBZ2 waar het gaat om de verhouding tussen SIB en EIB?
Is er overigens in de huidige modellering wel rekening gehouden met feit dat een samengesteld informatieobject in sommige gevallen misschien toch ook weer bevat, bijvoorbeeld omdat de scanstraat een document opsplitst in losse pagina's.
Maarten's betoog lijkt een pleidooi om al wat ontworpen wordt in technische, implementatie-gebonden zin te specificeren. Dat doet geen recht aan wat we bereiken willen: een ontwerp in termen van de werkelijkheid, dat begrijpelijk is voor degenen die gebruik (gaan) maken van die ontworpen verandering of ontwikkeling van die werkelijkheid. En het zou te sterk focussen op één technische implementatie. Terwijl er meer implementatie-varianten mogelijk zijn. En er in de toekomst zelfs betere implementatie-varianten bij kunnen komen.
Dus nee, laten we het RGBZ als conceptueel model niet vervuilen met technische implementatiekeuzes. In dit geval, keuzes voor berichtenverkeer. Niet voor de wijze waarop informatie getoond wordt in gebruikersinterfaces, aan gebruikers. Niet in het spraakgebruik tussen gebruikers. Daar spreken we (ook) over samengestelde informatieobjecten. En niet over folders, mappen of wat voor implementatietermen dan ook. Dus, voor wie zou dit een probleem zijn? Voor de ontwikkelaars van software? Hen valt in adequate documentatie van het logisch informatiemodel goed uit te leggen hoe de semantiek vertaald is naar techniek.
En dan nog even die scanstraat die pagina's als bestanden produceert i.p.v. documenten. Een pagina is in deze context geen 'onderwerp van gesprek'. Op het laatste is een conceptueel informatiemodel gericht. De organisatie cq. software zal er dus voor moeten zorgen dat die losse pagina-bestanden aaneengesmeed worden tot een informatieobject. Al zou ik zo'n scanstraat nooit aanschaffen ...
Technisch gesproken is een directory (folder) ook een samengesteld informatieobject. Tenminste, in de UNIX wereld wel.
Zie ook: https://www.tutorialspoint.com/unix/unix-directories.htm
A directory is a file the solo job of which is to store the file names and the related information. All the files, whether ordinary, special, or directory, are contained in directories.
CMIS lijkt dit model te volgen, als we een document (enkelvoudig informatieobject) als het equivalent van een file beschouwen (ook niet zo'n gekke gedachte volgens mij). Zo gezien past een informatiemodel wat de obtjecttypen enkelvoudig informatieobject en samengesteld informatieobject kent dan naadloos op het CMIS model.