BREED - over de grenzen van informatie

NETWERK VOOR DE INNOVATIEVE INFORMATIEWERKER

Outlook-bestanden (MSG) in het E-depot

Vorige week kreeg ik van een vakgenoot uit een andere gemeente de vraag hoe wij omgaan met het overbrengen of uitplaatsen van MSG-bestanden naar het E-depot. Als je een e-mail uit Outlook sleept naar bijvoorbeeld een netwerkschijf of naar het DMS (drag-and-drop), dan krijg je een MSG-bestand. Het risico ten aanzien van de duurzame toegankelijkheid zit hem met name in:

Het MSG-formaat is specifiek voor Outlook. Het is geen open standaard en is (waarschijnlijk) niet te openen met andere e-mailsoftware.
In het MSG-bestand zitten ook de bijlagen van de e-mail "ingebakken". Die hebben ook een eigen bestandsformaat, die mogelijk ook niet gegarandeerd duurzaam toegankelijk zijn.

Ik heb de vakgenoot laten weten dat wij in "onze organisatie" ook nog geen oplossing in productie hebben voor de duurzame toegankelijkheid van MSG-bestanden, maar ik heb hem wel mijn eigen visie hierin gegeven. Ik plaats mijn (herschreven) antwoord ook hier op BREED, omdat het misschien aanleiding vormt voor een interessante discussie.

Om te beginnen ben ik er wel voorstander van dat e-mails als MSG-bestand in het DMS of zaaksysteem worden opgeslagen, omdat:

Het voor de eindgebruiker vaak makkelijker is: drag-and-drop in plaats van een tooltje dat de gebruiker in staat stelt om de mail en bijlagen uit elkaar te trekken, om te zetten in een duurzaam formaat en alle onderdelen te registreren.
De e-mail haar functionaliteit behoudt (gedrag). Als je de e-mail uit het DMS ophaalt (check-out) en weer opent, dan opent hij in Outlook en je ziet als gebruiker exact weer terug wat je erin heb gestopt. Je kunt zelfs weer reply-en!

Voor duurzame archivering lijkt het mij desalniettemin wel noodzakelijk om de e-mail en de bijlagen uit elkaar te trekken. De literatuur (google maar) adviseert dat de e-mail als XML wordt bewaard, waarin onder meer wordt verwezen naar de los opgeslagen bijlagen. Deze bijlagen moeten uiteraard ook - waar nodig - omgezet worden naar een duurzaam bestandsformaat.

De vraag is of dit uit-elkaar-trekken en verduurzamen door het zaaksysteem moet gebeuren of door het e-depot. Mijn mening is dat dergelijke functionaliteiten in een e-depot gerealiseerd moeten worden. Een zaaksysteem heeft als primaire functie het ondersteunen van het werkproces en het vormen van zaakdossiers. Een e-depot heeft als primaire functie het duurzaam bewaren en beheren van dossiers. Het is inefficiënt om functionaliteiten in twee systemen in te richten en dan vind ik het verduurzamen van e-mail beter bij een e-depotvoorziening passen.

Binnen het e-depot zou ik deze functie in de Ingest (zie OAIS-model) realiseren. Het zaaksysteem (of enig ander systeem) levert het MSG-bestand dan af aan de Ingest. Uit de metadata (TMLO) blijkt dat het aangeleverde bestand een MSG-bestand betreft. De Ingest herkent dit als een niet-duurzaam formaat. Hij zet het bestand om in een duurzaam alternatief en plaatst het brondbestand plús het duurzame alternatief in de Archival storage.

Om de risico’s op informatieverlies zo laag mogelijk te houden, zou ik wel adviseren om digitale archiefbescheiden zo vroeg mogelijk uit te plaatsen naar een e-depot en niet te wachten op de formele overbrenging na 20 jaar. Niemand kan immers garanderen dat de gemeente nog 20 jaar met Outlook blijft werken, laat staan of de bijlagen nog geopend kunnen worden.

Overigens zit er ook nog een uitdaging in het samenstellen van de XML. De XML-standaard biedt immers ontzettend veel vrijheid en mogelijkheden. Voor de integriteit van het document is het wel belangrijk dat er hele scherpe afspraken worden gemaakt over hoe de XML moet worden opgebouwd en hoe dit weer terugvertaald moet worden naar een mens-leesbaar beeld. Hiervoor moet o.a. een XML-schema worden opgesteld. Bij mijn weten is hier geen breed-gedragen standaard of best-practice voor.

Ik heb in mijn verhaal hierboven bewust gesproken in termen als "ik vind", "ik zou" en "mijn mening is", want volgens mij is dit vraagstuk nog geen gesneden koek. Ik ben benieuwd naar de meningen en opvattingen van anderen hierin!

Vind ik leuk

3 leden vinden dit leuk

▶ Hierop reageren

Berichten in deze discussie

Permalink Antwoord van Yvonne Welings op 8 Mei 2016 op 10.50

De vraag is ook hoe je het TMLO toepast ?

▶ Beantwoorden

Permalink Antwoord van Danielle Hag op 9 Mei 2016 op 12.51

Dit klinkt mij erg prettig en gebruiksvriendelijk in de oren. De voordelen voor een behandelaar van een .msg bestand behoud je dan inderdaad. Alleen, gaat het technisch mogelijk zijn om een msg (of ander mail) bestand in het e-depot om te zetten naar een html of xml bestand?

Zijn er al organisaties bezig om dit soort ideeën uit te werken als soort proof of concept ?

▶ Beantwoorden

Permalink Antwoord van Hans Dekker op 9 Mei 2016 op 13.03

Hallo Marco,

Erg moeilijk allemaal en voor ons een niet geschikte oplossing. Wij bewaren zowel het MSG als een PDF/A versie daarvan incl. de bijlagen als aparte gerelateerde registraties. De PDF/A versie hebben we o.a. nodig voor het besloten deel van ons Bis (veelal burger mails) voor o.a. onze raadsleden op hun tablet (Goodreader app). Collega's kunnen altijd het native/originele bestand oproepen voor beantwoording, doorsturen e.d. De metadata van de email-header (tbv de TMLO) wordt ook in ons DMS opgeslagen en kan met het MSG of alleen het PDF/A bestand naar het e-Depot.

Natuurlijk zie ik de voordelen van xml, maar dan zullen de leveranciers ervoor moeten zorgen dat MSG automatisch wordt opgeslagen als xml. Los daarvan willen we een PDF/A versie voor bijv. annotatie. Deze annotaties worden als een aparte laag van dat PDF/A bestand ook in ons DMS opgeslagen.

Dat dit soort 'eenvoudige' document gerelateerde functionaliteiten niet in zaaksystemen zit verbaast mij. Er is een sterke zaaksystemen lobby, zie hun winst om niet meer op document niveau te vernietigen maar op zaakniveau, dat is m.i. in strijd met de TMLO en DUTO!

▶ Beantwoorden

Permalink Antwoord van Remco van Veenendaal op 12 Mei 2016 op 17.44

Hallo Marco,

Het (selecteren en) archiveren van e-mail is inderdaad nog geen gesneden koek. Toch deel ik graag mijn mening, ook omwille van de dialoog. Ik wil vooral een pleidooi houden voor het werken met open standaarden, juist al in zaaksystemen.

Eerst nog een detailopmerking: je geeft aan dat je functionaliteit (gedrag) wilt behouden, maar schrijft meteen daarna dat de gebruiker hetzelfde terug wil zien. Gedrag, inhoud en uiterlijk zijn verschillende aspecten van informatie, waarbij het gedrag en de inhoud van e-mail waarschijnlijk wel en het precieze uiterlijk waarschijnlijk minder essentieel is om te bewaren. Verschillende Outlook-versies in verschillende versies van Windows op verschillende apparaten tonen e-mail anders. Als je net als Hans e-mail omzet naar PDF/A ziet het er anders uit. Etc.

Terug naar de essentie: zoals je bijv. in het DPC-rapport Preserving E-mail op http://www.dpconline.org/advice/technology-watch-reports kunt lezen, neigt men steeds meer naar MBOX en, als je de e-mail in aparte bestanden wilt bewaren, EML voor transport en opslag van e-mail. De meeste e-mailservers en -clients kunnen met deze de facto standaarden overweg. Outlook kan EML lezen, maar niet altijd schrijven. Daar is dan (inderdaad) een aparte (export)tool voor nodig. Je leest in het rapport ook dat XML gebruikt kan worden voor preservation, maar dat er door gebrek aan gerelateerde applicaties wordt geadviseerd eerst maar eens te beginnen met migratie naar (MBOX of) EML.

Vervolgens kun je de argumenten voor open standaarden loslaten op e-mail, waarbij ik me hier beperk tot deze: gebruik al in je zaaksysteem en idealiter meteen bij creatie open standaarden en steun overheidsinitiatieven m.b.t. open standaarden (en zie bijv. art. 25 en 26 van de Archiefregeling), maak jezelf als organisatie minder afhankelijk van gesloten formaten en specifieke leveranciers, en stimuleer de open communicatie met burgers en bedrijven. Zelfs als dit conversie van (in het verleden opgeslagen) bestanden vereist, valt er iets voor te zeggen dat (in goed overleg met je archiefinstelling) zelf te (laten) doen, omdat je dan het resultaat van de conversie kunt controleren (gedrag, inhoud, evt. uiterlijk, etc.).

En: door de uitdaging niet voor je uit te schuiven naar e-depots cq. archiefinstelllingen, kunnen die zich met toekomstgerichte preservation bezighouden, en hoeven ze niet eerst nog alle "legacy" om te zetten :-)

Ook het argument dat niemand kan garanderen dat de gemeente over 20 jaar nog met Outlook werkt is bij uitstek een argument voor het nu al gaan werken met open standaarden, juist ook al in je zaaksysteem. Wacht niet tot iets het e-depot in gaat, neem zelf verantwoordelijkheid voor de digitale duurzaamheid van je informatie en bouw vanaf het begin van het records continuum open standaarden in.

Tot slot een geruststelling: veel e-depots kunnen bij de ingest en/of het verdere beheer van informatie zorgen voor conversie van formaten, incl. e-mail. Als het dus echt niet anders kan (en ook daar steunt de Archiefregeling je in) dan kan het e-depot je uit de brand helpen :-)