Henri Sivonen, korkeakouluharjoittelija, Kansallisarkisto
Henri Sivonen on laatinut tämän dokumentin Kansallisarkistossa kesällä 2002. Dokumentti sisältää Sivosen Kansallisarkistolle esittämän näkemyksen. Dokumentti ei välttämättä edusta Kansallisarkiston kantaa (eikä välttämättä edes Sivosen nykyistä kantaa).
Tämä on esitykseni siitä, minkä tyyppisissä formaateissa erilaisia dokumentteja kannattaa arkistoida, jotta ne voitaisiin myöhemmin migratoida muihin formaatteihin, tai vielä mieluummin: jotta formaattimigraation tarpeen todennäköisyys voitaisiin minimoida.
Pelkkänä tekstinä syntynyt dokumentti on kirjoitettu jollain tekstieditorilla (Emacs, BBEdit, NotePad jne.) eikä siinä ole koskaan ollutkaan minkäänlaista tägitettyä rakennetta tai merkkeihin liitettyjä tyylityksiä (lihavointeja yms.). Jos tekstinkäsittelyohjelmaa on käytetty tekstieditorin tavoin, voidaan myös tekstinkäsittelyohjelmalla tuotettu tekstidokumenttia pitää pelkkänä tekstinä syntyneenä.
Ehdotan, että tällaiset dokumentit arkistoitaisiin yksinkertaisesti pelkkänä tekstinä. Jos pelkän tekstin rivinvaihtojen käytöstä tiedetään jotain (hard wrap vs. soft wrap jne.) tallennetaan tämä tieto metadataan.
Ehdotan, että pelkkä teksi koodataan poikkeuksetta UTF-8:na. Jo esim. saamenkielisten dokumenttien arkistointi edellyttää tukea muillekin kuin tavallisille ISO-8859-1 -valikoiman merkeille. Lisäksi valmius eri kielillä laadittujen diplomaattisten dokumenttien arkistointiin edellyttää kykyä ilmaista muitakin kuin yleisiä länsieurooppalaisia merkkejä. Unicoden transformaatioformaateista UTF-8 on levytilan käytön kannalta suomenkielisen tekstin (ja yleensä latinalaisia merkkejä käyttävän tekstin) tallentamiseen edullisin.
Rakenteisella muodolla tarkoitan jotain XML-sanastoa (”tägijoukkoa”), joka koodaa dokumentin eri osien merkityksellisen roolin ja on suunniteltu sopivaksi jollekin dokumenttiluokalle. Viranomaiset tuottavat erilaisia määrämuotoisia dokumentteja. Rakenteisessa muodossa olevassa dokumentissa määrämuotoisuus on viety tiedostoformaattitasolle asti. Tiedostossa siis ilmaistaan tekstin kappaleet, otsikot, päätöksen osat kuten päätöksen tehnyt viranomainen, päätösteksti, viittaus hakemukseen tms. eksplisiittisesti sen sijaan, että koodattaisiin dokumentin ulkonäkö, jonka perusteella dokumenttilajin tunnistava ihminen voisi päätellä eri osien merkityksen.
Hyväksytyllä rakenteisella muodolla tarkoitan sellaista rakenteista muotoa, jonka arkisto on hyväksynyt kelvolliseksi vastaanotettavaksi ja säilytettäväksi.
Hyväksytyssä rakenteisessa muodossa syntyneet dokumentit on luotu alunperin jollain editorilla, joka on viritetty tuottamaan juuri haluttua muotoa suoraan ja laadukkaasti siten, että käyttöliittymä tukee formaatin oikeaa käyttöä.
Ehdotan, että hyväksytyssä rakenteisessa muodossa syntyneet dokumentit arkistoidaan ko. rakenteisessa muodossa. Erillistä tekstidumppia ei tarvita, koska sisältöhakuja voidaan tehdä suoraan XML-dokumentista. Itse asiassa rakenteiset muodot parantavat haettavuutta, koska sanan löytyminen otsikosta voidaan pitää olennaisempana kuin löytymistä tavallisesta tekstikappaleesta. Koska dokumentista tiedetään, ettei sen tarkka layout ole tärkeä, vaan ollennaisena pidetään tiettyjä loogisia rakenteita, dokumentista ei tarvitse säilyttää tilaa haaskaavaa bittikartaksi renderoitua versioita tai PDF-esitystä.
Rakenteisten formaattien käyttö voi olla myös hyödyksi virastojen sisäisillä työnkuluissa. Erityisesti ne auttavat paperin rajoituksista irti pääsemisessä, koska rakenteinen dokumentti voidaan renderoida järkevästi erilaisille esityslaitteille. Niinpä rakenteinen dokumentti voidaan esittää käyttäjän näytölle ja tarpeille sopivalla tavalla, esittää erityistarpeita omaaville kansalaisille sopivalla tavalla (esim. puhegeneraattorilla). Tämän lisäksi rakenteiset dokumentit voidaan tulostaa järkevästi. Pitkällä aikavälin tavoitteena olisikin sekä arkistoitavuuden että muunkin työnkulun kannalta hyvä markkinoida virastoille käyttötarkoitukseen sopivia rakenteisia formaatteja perinteisten toimistosovellusformaattien sijaan.
Ehdotan, että XML-dokumenttien merkkikoodauksena suositaan UTF-8:a mutta UTF-16 sallitaan, koska kaikkien XML-jäsentimien on joka tapauksessa pakko tukea kumpaakin. Esitän, että XML-dokumentit tallennettaisiin vakioidussa Unicode-normalisointimuodossa ja että tämä muoto olisi se, minkä W3C valitsee WWW:n merkkimallissa normalisointimuodoksi. Nykyisessä luonnoksessa valittu normalisointimuoto on normalisointimuoto C.[CharMod]
Mielivaltaista tiedostoa ei yleensä voida muuttaa ilman ihmisen apua järkevästi ja laadukkaasti rakenteiseen muotoon. Silti joissain tapauksissa muunnos voidaan tehdä onnistuneesti. Koska huonot konversiot johtavat rakenteisten formaattien hyötyjen menettämiseen, konversiotyönkulut olisi tarpeen arvioida tapauskohtaisesti.
Ehdotan, että konversiotyönkulkujen tuotteita otettaisiin arkistoon hyväksytyissä rakenteisissa muodoissa (kuten yllä), jos (ja vain jos) arkiston henkilökunta on ensin todennut konversiotyönkulun päteväksi. Näin siis siksi, ettei arkistoon pääsisi huonolaatuisia tiedostoja, joita ei voidakaan käsitellä siten kuin olisi ollut tarkoitus.
Jos dokumentti on onnistuttu muuntamaan kunnolla hyväksyttyyn rakenteiseen muotoon, esitän, että dokumentti arkistoidaan ko. rakenteisessa muodossa.
Jos dokumentista ei ole saatavana digitaalista originaalia mutta se on paperilla, ei jäljelle oikeastaan jää muuta vaihtoehtoa kuin paperin käyttäminen lähtökohtana. Koska laadukkaan digitaalisen vastineen teettäminen ihmistyönä olisi liian työllästä tai kallista, päädytään todennäköisesti paperidokumenttien digitoimiseen skannerilla.
Ehdotan, että dokumentti skannataan paperilta 300 ppi (pixels / inch) tarkkuudella kaksiväriseksi (musta/valko) bittikartaksi. 300 ppi on suositeltu tarkkuus OCR-ohjelmia ajatellen.[Scansoft] Työnkulun alussa skannerin operaattorin tulisi säätää kynnys valkoiselle ja mustalle silmämääräisesti siten, ettei valkoiselle alueelle jää kirjaimiin kuulumattomia OCR:ää ja pakkausta häiritseviä mustia pisteitä mutta kuitenkin siten, että kirjaimet pysyvät hyvin näkyvissä.
Ehdotan, että dokumentista arkistoitaisiin sekä häviöttömästi pakattu musta/valko bittikartta että siitä OCR-ohjelmalla tuotettu pelkkää tekstiä sisältävä dumppi tekstihakua varten. Tekstin metadatasta tulisi käydä ilmi, että se on OCR:llä tehty. Tämä on olennaista siksi, ettei tekstitiedoston sisältöä pidetä liian pätevänä todisteena alkuperäisen dokumentin sisällöstä. Jos OCR-dumpin avulla halutaan löytää tiettyjä sivuja, voidaan yhten tekstitiedoston sijaan tallentaa jokaisen sivun OCR-dumppi omaksi sivunumeroiduksi tiedostokseen.
Ehdotan, että tiedostoformaattina käytettäisiin CCITT Group 4 -pakattua TIFF 6.0:aa siten, että jokainen sivu on tallennettu omaan tiedostoonsa ja ryhmittely hoidetaan AIP-tasolla. (Lisäksi AIP-tasolla kannattaa käyttää deflate-pakkausta.) Jos TIFF:iä ei haluta tukea vain tätä tarkoitusta varten, ehdotan toissijaisesti PNG-muodon käyttöä.
Jos dokumentissa on väridiagrammeja, joiden ymmärrettävyys edellyttää värien säilymistä, skannataan dokumentti RGB-värillisenä. OCR-dumppi tuotetaan kuten yllä. Esitän, että mahdollisuuksien rajoissa arkistoitava bittikartta suodatetaan (esim. yksinkertaisella kynnyssuotimella) siten, että paperin taustaväri saadaan täysin tasavärisiksi pikseleiksi (tyypillisesti siis täysvalkoiseksi). Tämä edistää tiedoston pakkaamista.
Ehdotan, että eri värien määrästä riippuen bittikartta tallennetaan häviöttömästi joko adaptiivisella paletilla varustettuna indeksoituja värejä käyttävänä bittikarttana tai 8 bitti / kanava RGB-bittikarttana.
Jos dokumentin ainoa väri on dokumentin pohjassa (esim. värillinen logo tai vaikka sininen ala- tai ylätekstin erotinviiva), ei yleensä ole tarkoituksenmukaista käsitellä dokumenttia värillisenä, vaan on taloudellisempaa käsitellä dokumenttia mustavalkoisena.
Ehdotan, että tiedostoformaattina käytettäisiin PNG:tä.
Ehdotan, että jatkuvasävyiset paperilta skannatut dokumentit tallennetaan häviöllisenä bittikarttana (ks. Valokuva). (OCR-tekstidumpin kera, jos mahdollista.) Jatkuvasävyiset kuvat eivät pakkaudu kunnolla häviöttömillä menetelmillä. Oletan, ettei virastoissa juuri tuoteta tällaisia dokumentteja.
Jos faksivastaanottimesta saadaan faksibittikartat ulos digitaalisena, esitän että nämä bittikartat arkistoidaan alkuperäiset pikselit säilyttäen häviöttömästi pakattuna OCR-dumpin kera.
Jos faksista saadaan ulos vain kuvia paperilla, näitä papereita voidaan käsitellä skannattavina paperidokumentteina. Jos skannauksessa pidetään kirjaa originaalin laadusta, merkitään originaalin laatu huonoksi. Jos vastaanotettujen faksien arkistointia pidetään olennaisena, olisi toivottavaa, että viraston faksijärjestelmä olisi sellainen, että vastaanotetut faksit saataisiin talteen digitaalisina.
Käytännössä virastoissa luodaan paljon dokumentteja paperiorientoituneesti silloinkin, kun dokumentin rakenteen koodaava papeririippumaton formaatti olisi eGovernment-pyrkimysten kannalta soveltuvampi valinta. Yleensä paperiorientoituneella WYSIWYG-asenteella luoduista dokumenteista ei päästä tavanomaisilla ohjelmilla laadukkaasti rakenteiseen muotoon. Muunnos pitäisi teettää ihmisellä (tai monimutkaisella tekoälyllä). Niinpä nämä dokumentit on luontevampaa arkistoida digitaalisena paperina.
Koska monista tekstinkäsittelyohjelmista ei käytännössä saada ulos laadukkaita rakenteisia dokumentteja (ei ainakaan ilman käyttäjien uudelleenkoulutusta), joudutaan tekstikäsittelydokumentteja monissa tapauksissa käsitetelemään paperiorientoituneina myös silloin, kun sivujaolla ei oikeastaan ole mitään merkitystä.
Paperille tarkoitetun tulosteen digitaaliesityksistä PDF on ominaisuuksiltaan ylivoimainen niin kauan, kun se toimii. (Ks. erillinen dokumentti PDF.ään liittyvistä ongelmista.) Siksi esitän, että digitaalisena syntyneet paperiorientoituneet dokumentit pyrittäisiin taltioimaan PDF:nä, ellei se ole tietyssä työnkulussa erityisen epäsopiva ratkaisu.
Koska tekstin etsittävyys PDF-tiedostoista on vaihteleva ja välillä erittäin huono, PDF:n lisäksi pitäisi tallentaa tekstidumppi hakuja varten.
Valokuvia voidaan pakata siten, että kuvasta hävitetään tietoa, jota ihminen ei tavallisesti huomaa. Tätä mahdollisuutta kannattaa käyttää, koska häviöllisellä pakkauksella saadaan aikaa säästöjä tallennusmedian tarpeessa. Esitän, että valokuvat taltioidaan häviöllistä pakkausta käyttäen sellaisilla parametreillä, etteivät pakkauksesta johtuvat ilmiöt ole havaittavissa häiritsevästi.
Esitän, että tarkoitukseen käytettäisiin JPEG Baseline -pakkausta JFIF-tiedostoformaatissa. Formaatti on erittäin yleinen eikä JPEG 2000:n käytöllä saavuteta etuja arkistokäytössä silloin, kun halutaan, että häviöllisyys pysyy huomaamattomana.
Pakkaamattomalla äänellä on kaksi olennaista laatuparametriä, jotka ovat tiedoston ominaisuuksia eikä niitä siksi tarvitse erikseen mitata dataa tutkimalla. Nämä ominaisuudet ovat näytetaajuus ja näytteen koko. Näiden ominaisuuksien lisäksi signaalilla voi toki olla muita laatuominaisuuksia, kuten koodausta edeltäneiden analogisten vaiheiden aiheuttama kohina.
Näytetaajuus vaikuttaa siihen, kuinka korkeita taajuuksia voidaan tallentaa. Näytteen koko taas vaikuttaa siihen, kuinka hienojakoisesti signaalin voimakkuus voidaan ilmaista. Kun näitä parametrejä käytetään laatukriteereinä, oletetaan yleensä, että äänen koodauksena on lineaarinen PCM, jossa näytteen lukuarvo on lineaarisesti verrannollinen signaalin voimakkuuteen. Näytteen koon vaikutus äänen havaittavaan laatuun on erilainen, jos näyteluvun ja voimakkuuden riippuvuus on logaritminen (m-law -koodaus). Yleensä pakkaamaton digitaaliääni on lineaarisesti koodattua, joten jätän tässä logaritmisen koodauksen vähemmälle huomiolle.
Tyypillisiä näytetaajuuksia ovat nykyään 44,1 kHz (CD, monien tietokoneiden oletus) ja 48 kHz (DAT, radiotuotanto, DV-videokamerat). Tavallinen näyteen koko on 16 bittiä (CD, tavalliset tietokoneet). Tämän lisäksi high-end -editointijärjestelmissä käytetään isompia näytteitä 24-bittisiin asti.
EBU suosittaa 48 kHz:n näytetaajuutta arkistointiin[EBU-achives], mutta jos lähtömateriaali on tallennettu 44,1 kHz:n näytetaajuudella, ei konversiosta ole mitään hyötyä (siitä voi olla jopa haittaa, jos konversio joudutaan kuitenkin tekemään takaisin toisinpäin soittotilanteessa). Vastaavasti äänen tallentaminen digitointinäytteen kokoa suuremmalla näytekoolla on hyödytöntä.
Pakkaamaton lineaarinen PCM vie paljon tilaa. Arkistointia varten ääni kannattaa pakata, jotta mediakustannuksissa voitaisiin säästää. Nykyään tehokkaat pakkaumenetelmät kuuluvat kahteen luokkaan:
Näistä ensimmäisen kaltaiset pakkaukset ovat arkistointimielessä yleispäteviä, mutta jälkimmäisen tyypin menetelmiä voidaan käyttää onnistuneesti vain siinä tapauksessa, että arkistoitava ääni on puhetta ja pakkaus saa huonontaa sen laatua hieman.
Ehdotan, että äänen pakkaukseen valitaan ainakin jokin psykoakustinen koodausmenetelmä ja että näytetaajuutena käytetään lähtötiedoston näytetaajuutta (mielellään 44,1 kHz tai 48 KHz).
(ks. [Mayer-Patel])
[CharMod] Character Model for the World Wide Web 1.0. (W3C Working Draft 30 April 2002.) Dürst et al. (toim.). The World Wide Web Consortium. 2002. URL: http://www.w3.org/TR/2002/WD-charmod-20020220/ (uusin versio: http://www.w3.org/TR/charmod/)
[Mayer-Patel] Audio Coding. (Luentokalvoja University of North Carolinan Multimedia Networking -kurssilta) Ketan Mayer-Patel. 2002. URL: http://www.cs.unc.edu/Courses/comp249-s02/lectures/comp249_s02_6/
[Scansoft] What are the differences between OCR and scanning a document and saving it in an image file format? Scansoft. 2002. URL: http://knowledgebase.scansoft.com/view.asp?tnID=1994
[EBU-achives] EBU Technical Recommendation R105-2001 – Digitisation of programme material in Radio Archives. European Broadcasting Union. 2001. URL: http://www.ebu.ch/tech_text_r105-2001.pdf