Digital Preservation - The Planets Way (2)

Een van de doelstellingen van de bijeenkomst in Kopenhagen was om belanghebbenden en geïnteresseerden te informeren over de dingen die binnen PLANETS ontwikkeld worden. Vandaag een overzicht van een paar kleine dingen. Later volgen nog het Testbed en het Interoperability Framework waar alles uiteindelijk in samen moet komen.

Migratie van relationele databases

Voor het bewaren van relationele databases ontwikkelt het Schweizeris Bundesarchiv het SIARD-formaat.

Het probleem bij relationele databases zit hem in de relaties. Als je een database migreert moet je die relaties in stand zien te houden, want anders is de 'inhoud' van de database bijna waardeloos. Om dit te bewerkstelligen is SIARD ontwikkeld: Software-Independent Archiving of Relational Databases, waarmee Oracle, MS SQL en MS Access databases duurzaam bewaard kunnen worden.

Een SIARD-bestand is een container (zip64) met verschillende xml-bestanden. Voor iedere tabel in de database wordt een apart xml-bestand gemaakt, waarin de inhoud van de tabellen is opgenomen. Daarnaast wordt een metadata.xml gemaakt waarin de metadata (gebaseerd op SQL 1999) zijn opgenomen.

Uit de presentatie van Jean Marc Comment van juli 2008 maak ik op dat er drie applicaties ontwikkeld worden:

SiardFromDb extraheert en conveert de inhoud van een relationele database naar het SIARD-formaat.

SiardEdit is bedoeld voor het toevoegen en wijzigen van metadata

SiardToDb plaatst een SIARD bestand weer in een database instance en maakt het zoeken en navigeren in de database mogelijk.

Emulatie

Ik heb het hier al eerder gehad over emulatie en mijn bedenkingen bij deze techniek. In PLANETS is Dioscuri, de modulaire emulator van KB en NA waarop MS-DOS, FreeDos, LINUX 16-bits (ELKS) en MS Windows 3.0 kunnen draaien, verder ontwikkeld. Hier staat een uitgebreid verslag van vijf case studies met Dioscuri.

Een van mijn bezwaren tegen Dioscuri (en tot nu toe tegen emulatie in het algemeen), is dat het nogal wat technische kennis vergt om een emulator werkend te krijgen. En voor ieder hardware-platform moet je een aparte emulator bouwen. Daar hopen ze in PLANETS door middel van GRATE een oplossing voor te vinden. GRATE (Global Remote Access To Emulation) biedt "Emulation as a Service". Het zou als volgt moeten gaan werken en dit is de simpele uitleg, technisch zitten er nog wat haken en ogen aan:

Stel je hebt een Ami Pro bestand en je wil dit in de 'orgininele configuratie' bekijken. Dan upload je het bestand naar de GRATE-website, waar met behulp van PRONOM en de Planets Core Registry (zie beneden) bekeken wordt welk bestandsformaat het is en op wat de beste manier is om het bestand te tonen. GRATE levert dan een URL en door daar op te klikken, verschijnt in je browser Ami Pro in Windows 98!

 

Natuurlijk heb je dan nog altijd het probleem dat je moet weten hoe Ami Pro werkt, maar, vroeg Maureen Pennock zich tijdens de presentatie af, is dat niet vergelijkbaar met het kunnen ontcijferen van oud-schrift?

Planets Core Registry

Het laatste wat ik hier wil noemen is eigenlijk geen 'klein ding' maar het hart van PLANETS: de Core Registry.

Bij The National Archives in Londen hebben ze enige tijd geleden PRONOM ontwikkeld. Dit is een (online) register waarin allerlei gegevens over bestandsformaten worden bij gehouden, bijvoorbeeld over Word 6.0. 

De Core Registry wordt een uitbreiding van PRONOM, doordat het niet alleen informatie bevat over bestandstypen, maar ook over software(applicaties), hardware en media en 'preservation pathways'. Dit zijn een soort stappenplannen voor het bewaren van bepaalde bestandsformaten. In de Core Registry wordt bijvoorbeeld opgenomen met welke emulator Ami-pro bestanden het beste geraadpleegd kunnen worden, waardoor GRATE deze kan opstarten. Of in de Registry wordt bijvoorbeeld (op basis van Testbed-resultaten) opgenomen dat gif-bestanden het beste via jpg naar png gemigreerd kunnen worden, inclusief welke applicatie daar het meest geschikt voor is. Op basis hiervan kan dan in PLATO de juiste bewaarstrategie gekozen worden.

Wordt nog één keer vervolgd...

Digital Preservation - The Planets Way (1)

Hoe beschrijf je drie zeer volle, zeer interessante en leerzame dagen in de prachtige KB in Kopenhagen? 

De makkelijke oplossing is: kijk hier. Dit zijn de tweets die drie van de aanwezigen de afgelopen dagen verzonden hebben. 

Een andere oplossing is: kijk hier. Dit is de weblog van Audun, die drie dagen live geblogd heeft.
Maar dat zou te gemakkelijk zijn. Laat ik zelf dus maar proberen een samenvatting te geven van de (in mijn ogen) belangrijkste dingen die ik gehoord en geleerd heb.

Planets staat voor Preservation and Long-term Access through Networked Services en is een vierjarig project, dat gedeeltelijk door de EU gesponsord wordt. Doel van het project is om praktische, toepasbare hulpmiddelen te ontwikkelen voor het langdurig toegankelijk houden van digitale objecten. De afgelopen dagen heb ik een paar heel spannende en veelbelovende ontwikkelingen gezien, die ik niet allemaal in één bericht kan beschrijven. Vandaag daarom alleen een stukje over XCL en PLATO.

XCDL en XCEL

Van de XCL-presentaties was ik echt heel erg onder de indruk. Bij de Universiteit van Keulen wordt gewerkt aan een eXtensible Characterisation Language. Doel is om te komen tot een 'taal' (eXtensible Characterisation Definition Language, XCDL) waarmee het mogelijk is de inhoud van digitale objecten te beschrijven. Tegelijkertijd werken ze aan eXtensible Characterisation Extraction Language (XCEL) waarmee het mogelijk is om geautomatiseerd XCDL-beschrijvingen van unieke bestanden te maken.

Een paar jaar geleden hoorde ik tijdens Tools & trends in de KB in Den Haag professor Thaller hier ook een presentatie over geven en ik snapte er destijds helemaal niets van. Gelukkig lieten Jan Schnasse en Volker Heydegger (medewerkers van Thaller) ons echt zien hoe het werkt en wat er mee mogelijk is. 

Met behulp van XCL kun je van een afbeelding bijvoorbeeld automatisch aspecten als het kleurenpalet, de breedte en de hoogte vastleggen. Maar dat niet alleen, op bit-niveau worden ook alle pixel-gegevens (waarde/kleur) opgeslagen. 

Wat heb je daar aan? Stel je wil een tiff-bestand converteren naar een png-bestand. Dan kun je met behulp van de Extraxctor vóór de conversie een XCDL-beschrijving van het tiff-bestand maken en na conversie een XCDL-beschrijving van het png-bestand. En nu komt de truc: deze beschrijvingen kun je geautomatiseerd laten vergelijken door een programma dat "Comparator" heet. Dat betekent dus dat je conversies niet 'handmatig' hoeft te controleren! En, wat ook interessant is, die Comparator ziet iedere pixel-afwijking, zelfs wanneer die met het menselijk oog niet te zien is!

Het beschrijven en analyseren van afbeelding zijn één ding, plaatjes zijn nog redelijk recht-toe recht-aan (al kunnen ze ook die bewegende gif-bestanden beschrijven). Teksten zijn echter een heel ander verhaal. Ze zijn nu bezig met het maken van een XCEL voor het beschrijven van tekst-bestanden. Hierin zal ook rekening gehouden worden met opmaak-verschijnselen als voetnoten, andere lettertypes en alinea's. Het is nu wel mogelijk om dit handmatig in een XCDL te beschrijven, maar ze hebben nog geen 'extractor' die dit geautomatiseerd voor grotere bestanden kan doen. Als het zo ver is, dan is het dus mogelijk om automatisch vast te stellen wat er eventueel verloren is gegaan bij een conversie van Microsoft Word naar ODF.

PLATO

Een andere ontwikkeling is de Planets Preservation Planning Tool (PLATO), waarmee bewaaracties voor een collectie gepland kunnen worden. 

Voor een organisatie is het vaak niet eenvoudig om vast te stellen wat de beste manier is om een bepaalde 'collectie' digitale objecten duurzaam toegankelijk te maken. Kunnen de bestanden het best gemigreerd worden of is emulatie de beste strategie? Naar welk nieuw bestandformaat kan het best gemigreerd worden en welke conversie-programma's zouden daar het best geschikt voor zijn? Hoe lang zal zo'n conversie-traject duren en wat gaat dat dan kosten?

Op basis van een mindmap-sjabloon kan een organisatie eerst proberen alle randvoorwaarden (zoals wettelijke bepalingen, budget, doorlooptijd, opslagruimte, eisen aan vorm, structuur en inhoud etc) zo 'meetbaar' mogelijk beschrijven. Daarna kunnen (op basis van sjablonen en beschreven 'migratiepaden' in de applicatie) de mogelijke bewaarstrategieën uitgeprobeerd worden. Dit is echt heel letterlijk, met behulp van en in PLATO kan een representatieve set bestanden bijvoorbeeld geconverteerd worden, waarna de resultaten vergeleken kunnen worden met de beschreven randvoorwaarden.  In de derde stap kan de organisatie de resultaten van de experimenten beoordelen en een aanbeveling voor een bewaarstrategie schrijven. De laatste stap is dan het vaststellen van een uitvoerbaar 'bewaarplan' en dat kan ook in PLATO.

Een van de belangrijkste doelen van PLATO is vooral vastleggen waarom welke keuzes gemaakt zijn, zodat het later altijd mogelijk is om hier verantwoording over af te leggen.

Later meer...