Nyt seuraa jatkoa edelliselle merkinnälle Planetsista. Kerron lopuista palveluista ja vielä Planetsin tuotoksista kokonaisuutena.

Palvelut migraatioon ja emulaatioon

Aiemmassa merkinnässä suoritin muunnokset JPG:n ja JPEG2000:n ja PNG:n välillä. Plato ei sisällä muunnostoiminnallisuutta, varsinainen työ suoritettiin taustalla Planetsin Testbed-palvelussa.

Testbedin ideana on tarjota kontrolloitu ympäristö eri säilytysmenetelmien eli migraation tai emulaation työkalujen testaamiseen. Työkaluja Planetsissa nimitetään Planets Action Toolseiksi. Omasta kokoelmasta voi kopioida palveluun aineistoja, selvittää mitä työkaluja on saatavilla ja testata työkalujen suoriutumista omalla aineistolla. Kokoelman migraation voi testaamisen jälkeen suorittaa rauhallisin omassa järjestelmässään. Toiminta on sikäli suoraviivaista, että järjestelmä tunnistaa automaattisesti lähetetyn tiedoston ja tarjoaa sille tunnistamisen perusteella työkaluvalikoimaa.

Testbedin tarkoitettu nimenomaan testaamiseen, mutta ihmettelen jos sitä ei jatkossa tarjottaisi myös varsinaiseksi migraatioympäristöksi. Migraation lisäksi Testbed tarjoaa mahdollisuuden emulaation. Kuten muut Testbedin käyttämät työkalut, myös eri emulaatiotyökalut on paketoitu palveluksi. Palvelu sisältää muun muassa Dioscuri– ja Hatari-emulaattoriohjelmistot, joista ensimmäisellä voidaan jäljitellä 1990-luvun alun PC:tä ja toisella Atari ST:tä ja STE:tä.

Yleisesti ottaen emulaattorin voi tulla kyseeseen, kun halutaan käyttää aineistoa joka on tehty teknologialla, joka ei ole enää yleisesti käytössä eikä aineistoa voida muuntaa uuteen muotoon. Näin käy tyypillisesti vanhoille peleille, multimediarompuille yms. Erikoisempia käyttötapauksia voivat olla esimerkiksi vanhat tietokannat ja miksei myös tulevaisuudessa verkkosivustot, joiden pitkäaikaissäilytys on hyvin haasteellista.

Emulaattorien tarjoaminen palveluna on Planetsilta erinomainen idea. Emulaattorien asentaminen käyttökuntoon itse ja sopivan emulaattorin valinta vaatii teknistä tietämystä, jota keskivertoarkistonhoitajalla, museotyöntekijällä tai kirjaston suunnittelijalla harvemmin on. Se kuinka onnistunut emulaatiopalvelu on, jää nähtäväksi. Testbed avataan testikäyttöön kiinnostuneille syyskuussa, joten en pääse tutustumaan siihen saati esittelemään sitä nyt.

XCL eli digitaalisten objektien kuvauskielet

En mene tässäkään asiassa pintaa syvemmälle, koska aihe vaatisi muuten kattavaa esitystä ja itseltäni syvällistä paneutumista asiaan – ja pitkää pinnaa tietysti. Toisekseen saatavilla ei ole kaikkea tarvittavaa materiaalia, mutta tämä aihe on ehdottomasti pikaisen esittelyn tarpeessa.

XCL eli eXtensible Characterisation Language jakautuu kahteen osaan XCEL-kieleen, jolla kuvataan tietty tiedostomuoto formaalissa, tietokoneen ymmärtämässä muodossa (E tulee sanasta Extraction). XCEL tarjoaa abstraktin datamallin, jolla eri tiedostomuotojen tiedostorakenteet voidaan kuvata. Toinen kieli on XCDL, jota käytetään halutun digitaalisen objektin sisällön kuvaamiseen. XCDL:llä voidaan kuvata minkä hyvänsä tiedoston koko sisältö normalisoidussa muodossa. XCDL:llä saavutetaan se etu, että muunnoksien tuloksia voidaan helposti vertailla keskenään myös raa’an sisältönsä osalta.

Kuvassa a ja b viittaavat kahteen erilliseen tiedostoon, jotka ovat eri tiedostomuotoa. Tiedosto b syntyy muunnoksen A2B-seurauksena lähdetiedostosta a. A:n ja b:n tiedostomuodoista on laadittu etukäteen XCEL-kuvaukset A ja B, jotka syötetään Extractorille tiedostojen a ja b lisäksi. Extractorilla laaditaan sitten tiedostoista a ja b normalisoidut XCDL-kuvaukset, joita verrataan Comparatorilla keskenään. Comparator ilmoittaa, onko muunnoksen tulos (b) identtinen lähdetiedoston (a:n) kanssa ja kertoo mahdollisista eroista.

Tekijät esittelivät kehitysvaiheessa olevaa versiota sadoilla kuvatiedostoilla. Tulos oli hyvin vaikuttava. Mutta miten tiedoston sisällön normalisointi käytännössä onnistuu? Tiedostoista erotetaan varsinainen raakadata, esim. kuvan pikselidata tai tekstin kirjaimet, ja se esitetään yhtenäisessä muodossa, joka ei ole riippuvainen tiedostomuodosta. Binääridata esitetään XCDL:ssä heksadesimaaleina ja kirjaimet eli teksti UTF-8:na. Raakadatan ominaisuudet kuten kuvan leveys tai tekstin korostus kuvataan erikseen XCDL:ssä. Datan ja sen ominaisuuksien kattavasta kuvaamisesta seuraa, että tiedostojen XCDL-kuvauksista tulee hyvin pitkiä, varsinkin kun kyseessä on pitkä tekstidokumentti tai monimutkainen kuva. Alla on lyhyt esimerkki yksinkertaisesta kuvasta ja sen XCDL-kuvauksesta:

<?xml version=’1.0′ encoding=’UTF-8′?>

<xcdl xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”

xmlns=”http://www.planets-project.eu/xcl/schemas/xcl”

xsi:schemaLocation=”http://www.planets-project.eu/xcl/schemas/xcl

../res/xcl/xcdl/XCDLCore.xsd” id=”0″ >

<object id=”o1″ >

<normData type=”image” id=”nd1″>

00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16

…

</normData>

<property id=”p5″>

<name id=”id30″ >imageWidth</name>

<valueSet id=”i_i1_s4″ >

<labValue>

<val>32</val>

<type>int</type>

</labValue>

</valueSet>

</property>

…

Toistaiseksi XCL:n kehittäneet Kölnin yliopiston tutkijat ja työntekijät ovat laatineet XCEL-kuvauksia yleisimmille kuvatiedostomuodoille ja keskittyvät tällä hetkellä laatimaan niitä myös tekstidokumenteille. Yhden tiedostomuodon XCEL-kuvauksen laatimisessa kuluu ymmärrettävästi pitkä tovi. XCL on joka tapauksessa loistava keksintö. Sitä käyttämällä miljoonienkin tiedostojen migraatio voi helpottua huomattavasti ja virheet vähentyä. XCL:n avulla olisin voinut välttää edellisen merkinnän kömmähdyksen. Lienee sanomattakin selvää, että XCL:n kehitystä jäädään seuraamaan suurella mielenkiinnolla.

Planets kokonaisuutena

Brosyyrissä Planetsista on kaksi visuaalista hahmotelmaa:

On hienoa, että Planets-hankkeessa osataan katsoa kokonaisuutta monesta eri näkökulmasta. Itse pidän enemmän ensimmäisestä kuvasta, joka kuvastaa perinteistä laatikko-nuoli-ajattelua. Palataan nyt kuitenkin takaisin asiaan.

Planetsin eri osista käsittelinkin jo jossain määrin melkein kaikkia. Toisen kuvan Service Registries –osasta en ole vielä kertonut, mutta se ei vaadi mielestäni tarkempaa esittelyä. Se on siis eräänlainen tiedostomuotorekisteriä kattavampi teknologiarekisteri, johon kerätään tietoja ohjelmista, tiedostomuodoista, laitteistoista ja tallennusvälineistä.

Kaikki osat toimivat omina kokonaisuuksinaan ja ovat yhteydessä toisiinsa Planets-kehikossa. Palvelut ovat nykyaikaista tekniikkaa eli pääosin Javaa, ja ne tarjoavat Web Service –rajapinnan. Kun Planets päättyy, julkaistaan koko paketti eli Planets-kehikko ladattavana ohjelmistokokonaisuutena, jonka voi asentaa omille palvelimilleen. Eri osia voi myös käyttää ja ladata itsenäisinä kokonaisuuksinaan.

Kuten sanottua Planetsin tuotokset ovat avoimia, joten myös sen sisältämät kolmannen osapuolen työkalut ovat esim. GPL-lisenssillä tehtyjä. Toivotaan, että avoimen lähdekoodin työkalut ovat riittäviä jatkossa kaikkiin tarvittaviin toimintoihin. Esimerkiksi emulaatiossa tulee varmasti ongelmia vastaan silloin, kun olisi tarve käyttää vanhoja, markkinoilta poistuneita kaupallisia ohjelmistoja.

Nähtäväksi myös jää, kuinka paljon työtä vaatii Planetsin osien integroiminen organisaatioiden omiin työnkulkuihin tai järjestelmiin. Varmasti tuleviin järjestelmiin tullaan integroimaan, jos ei Planetsin työkaluja, niin ainakin vastaavanlaisia tuotoksia. Näin tulee tapahtumaan yksinkertaisesti siitä syystä, että Planetsin toteutukset ovat myös ideoiltaan ainutlaatuisia ja edistyksellisiä.