Onlangs heb ik begrepen dat het veld Formaat bij een Document gebruikt gaat worden om een MIME-type van een document uit te wisselen in RGBZ 2.0. Hiermee wordt een functioneel veld in RGBZ 1.0 vervangen voor een technisch veld. De bedoeling van RGBZ was m.i. om hier een menselijk interpreteerbare string in te kunnen doen welke aangeeft of een document een Word-document is, Excel, bouwtekening, afbeelding, etc. De definitie van dit veld in RGBZ 1.0 gaf als voorbeeld invulling hiervoor de extensie van een document (.doc, .xls, etc), maar sloot andere beschrijvingen niet uit. Omdat sommige leveranciers dit veld gebruikten om de uitwisseling te regelen van technische eigenschappen van een document, zoals MIME-type en bestandsextensie, bij gebrek aan een ander veld in StUF berichten, is hierover discussie ontstaan. Mijn voorstel is om de beschrijving zoals die nu is voorgesteld in RGBZ 2.0: de uitwisseling van MIME-type, te vervangen voor een beschrijving die de functie van dit veld beschijft zoals ik zojuist heb gedaan. De technische eigenschappen van een document moduleren in RGBZ 2.0, zoals bestandsnaam (met OS-specifieke restricties in karakters), extensie (met . of zonder .) en MIME-type, is iets wat m.i. het beste vermeden kan worden en pas bij de verStUF-ing moet worden opgepakt.
do, 6-11-2014 - 08.51u
#1
Gebruik van veld Formaat bij een document (InformatieObject)
In het RGBZ 1.0 is bij de attribuutsoort Documentformaat aangegeven dat dit de XML-tag 'formaat' betreft oftewel het StUF-ZKN-element 'formaat'. Bij de verStUFfing is het element 'formaat' gecreeerd en het subelement 'mimeType' toegevoegd. Verzuimd is aan te geven op welk RGBZ-attribuutsoort dit 'mapt'. Dat heeft tot verwarring geleid.
Ik ben het dan ook niet eens met de stelling dat het mimeType slechts een technische eigenschap is die je niet zou hoeven opnemen in een informatiemodel. M.i. beschrijft een informatiemodel alle van de desbetreffende objecten vast te leggen gegevens, voor zover relevant voor het betreffende domein. Of een dergelijk gegeven nou technisch of iets anders is, maakt niet uit. Van belang is dat de semantiek van (de kenmerken van) het object uitputtend beschreven wordt. Om duidelijkheid en eenduidigheid te scheppen.
In het RGBZ 2.0 is de attribuutsoort Bestandsnaam.Extensie toegevoegd met als XML-tag 'bestandsnaam.extensie'. Het laatstgenoemde attribuutsoort heeft als waardenverzameling "... een aanduiding van het bestandsformaat. Bij Windows-bestanden is dit de, meestal drieletterige, code na de meest rechtse punt." Oftewel vermeldingen als "doc" en "pdf". Het attribuutsoort Formaat heeft als definitie "De code voor de wijze waarop de inhoud van het ENKELVOUDIG INFORMATIEOBJECT is vastgelegd in een computerbestand." en als waardenverzameling "MIME-types en –subtypes conform IANA". Dit komt m.i. overeen met het subelement MimeType in StUF maar heeft als XML-tag nog 'formaat'. Maar dat element (formaat) heeft m.i. geen nut meer (i.t.t. de attribuutsoort Formaat) nu er al een subelement MimeType is en een element 'extensie'.
Voor de hand liggend is m.i. om het RGBZ-2.0-attribuut Formaat de XML-tag 'inhoud/@contentType' te geven oftewel te 'mappen' op het gelijknamige StUF-element en het StUF-element 'formaat' te laten vervallen (in StUF-ZKN 3.20). Daarmee zijn RGBZ (2.0) en StUF-ZKN (3,20) weer in evenwicht (voor de huidige versies geldt dit helaas niet).