Henri Sivonen, korkeakouluharjoittelija, Kansallisarkiston Tietotekniikkayksikkö
Tarkoituksenani on esittää näkemykseni siitä, millaista metadataa digitaaliseen dokumenttiin tulisi liittää, jotta tunnettaisiin dokumentin tekninen historia ja nykyinen olomuoto sekä ymmärrettäisiin, mitä tietoa on menetetty.
Näkökulmani on lähtökohtaisesti sellainen, ettei metadatalla yritetä dokumentoida mielivaltaisten formaattien natiiviympäristöjä luontiympäristön replikointia varten, vaan oletan arkiston asettavan rajoituksia vastaanotettaville formaateille, jotta formaatit voitaisiin valita pitkäaikaissäilytyksen kannalta järkevästi. Tämä lähtökohta johtuu siitä, ettei arkistolla mitenkään voi olla resursseja mielivaltaisten dokumentinluontiympäristöjen säilyttämiseen tai emulointiin.
Näkemyksen muodostamisen pohjaksi luin joukon aihetta koskevia vaatimus-, viitemalli- ja standardidokumentteja. (Ks. lähdeluettelo.) Missään työn alussa lukemistani lähteistä ei esitetty valmista konkreettista pitkäaikaissäilytykseen soveltuvaa metadatakentästöä. Vaatimukset ja viitemallit käsittelivät asiaa joko yksityiskohtiin menemättä tai sitten pitkäaikaissäilytykseen (alkuperäisten ympäristöjen replikoinnin epäkäytännöllisyyden vuoksi) soveltumattomasta näkökulmasta. Niinpä monet yksityiskohdat täytyi muotoilla tältä pohjalta omin päin.
Kesken työn löysin tietoa METS-projektista ja siihen liittyvästä MODS-projectistä.[METS][MODS] Sen jälkeen rupesin käyttämään myös näitä lähteenä. MODS laajennusanakirjoineen[METS-Dict] on konkreettinen metadatakentästö toisin kuin abstrakteina pysyvät viitemallit ja vaatimusdokumentit.
Valitettavasti monet dokumentin luonteeseen ja formaattiin liittyvät tiedot ovat vain työläästi koodattavissa metadataan, vaikka tiedot olisivatkin teoriassa tiedettävissä. Liian metadatan vaatiminen voi olla liian kallista tai työnkulkuja hidastavaa. Toisaalta oletusarvoista tai muuten vain hatusta vedetyt metadata-arvot huonontavat kaiken metadatan uskottavuutta (todennäköisyyttä, että tieto on oikein). Tämän vuoksi pidän väärää metadataa puuttuvaa metadataa vahingollisempana. Siksi olen yrittänyt rajata kenttien määrää ja esitän monien kenttien kohdalla, että kentän arvo voidaan jättää tuntemattomaksi.
Olen myös pyrkinyt erottelemaan metadataa sen mukaan, milloin se muuttuu. Perusteena on se, ettei AIP:in tavujonoa tarvitsisi muuttaa kuin formaattimigraation yhteydessä. Tällöin API:in tavuesitykseen ei tarvitsisi koskea mediamigraation yhteydessä. Tavuesityksen kannalta ei ole olennaista, millä medialla se on. AIP:in muuttumattomuus arkiston käytön aikana puolestaan mahdollistaa AIP:in säilyttämisen medialla, jolle voi kirjoittaa vain kerran.
Tässä kappaleessa kuvatut kentät liittyvät tiettyyn AIP:in sisällä olevaan tiedostoon. Jos AIP:issa on useita tiedostoja, jokaisella niistä on omat kenttänsä. Lisäksi nämä kentät on tarkoitettu talteen otettaviksi migraation yhteydessä siten, että jokaiseen migraatiossa tuotettuun tiedostoon liittyisi kaikkien niiden tiedostojen, joiden pohjalta migraatiotuotetiedosto on luotu, tiedostokohtainen metadata (kumulatiivisesti, jos migraatioita on monta peräkkäistä).
Ainakin teoreettisesti arkiston pitää olla valmistautunut siihen, että koko arkiston kaikki tiedostot pitää migratoida uusiin formaatteihin [MoReq 11.7.3]. Jos arkistoon on päästetty mitä tahansa tiedostoformaatteja eikä listaa hyväksytyistä formaateista ole, pitäisi migraatiovaiheessa käydä koko arkisto läpi ja kartoittaa, mitä kaikkea siellä on. Jos formaattinimet olisivat vielä ainoastaan ihmisen ymmärrettäviä merkkijonoja, tarvittaisiin ihmisiä selvittämään, mitkä formaatit ovat samoja ja mitkä ovat eri formaatteja. (Esim. koneellisesti on vaikea selvittää, voidaanko "Illustrator 5 (Windows)" ja "Adobe Illustrator 4" katsoa samaksi formaatiksi.) Kun arkistoitujen dokumenttien määrä on suuri, tällainen jälkikäteiskartoitus voisi olla niin kallis ja aikaa vievä, ettei migraatiota voitaisikaan toteuttaa.
Tästä syystä arkistolla tulisi olla rajallinen lista hyväksytyistä arkistointiformaateista. Kullakin formaatilla tulisi olla arkiston puitteissa yksiselitteinen tunniste, ja kustakin formaatista tulisi olla hyvä formaattia lukevan ohjelman toteuttamiseen riittävä dokumentaatio (Arkistolaitoksen itsensä hallussa [MoReq 11.7.6]) vähintään paperilla ja mielellään myös digitaalisena. Periaatteessa samojen formaattien olennaisesti erilaista käsittelyä vaativat variantit (esim. TIFF eri pakkausalgoritmeilla) laskettaisiin erillisiksi formaateiksi. Pelkkä XML ei riitä formaatiksi, vaan XML-pohjaisen formaatin pitää olla jokin konkreettinen XML-pohjainen formaatti kuten DocBook. Tällöin formaattitieto siis sisältäisi tiedon tarvittavista oheistiedostoista kuten DTDeistä (required templates [ISO/TR 15489-2:2001(E)]).
Lisäksi formaattitietueessa olisi hyvä olla viite ohjelmaan, jolla formaattia voidaan lukea. Tämän ohjelman käyttöön tarvittavia tietoja voitaisiin dokumentoida [OCLC/RLG]:n viitoittamalla tavalla, vaikka kyseessä olisi formaattikohtaisen yleislukuohjelma dokumentaatio eikä tietyn dokumentin natiiviympäristön dokumentaatio. Käytännöksi olisi hyvä ottaa se, että jokaista arkistoformaattia varten pitäisi olla säilössä lukuohjelma lähdekoodeineen ja dokumentaatioineen ja vaikka puolentoista vuoden välein tarkistettaisiin, osataanko ohjelma vielä järjestää käyttökuntoon, voidaanko ohjelma päivittää jne. Käytännössä lähdekoodin saanti säilytettäväksi, käytettäväksi ja tarpeen vaatiessa uusille järjestelmäalustoille siirrettäväksi edellyttää sitä, että lähdekoodi on saatavissa open source / free software -lisenssillä.
Tiedoston metadataan tulisi siis liittää tiedoston formaatin ilmaiseva hyväksytyn formaatin tunniste.
Vaikka tiedostomuoto olisikin periaatteessa määritelty, muoto voi poiketa toivotusta. Ohjelmissa on vikoja ja joitain formaatteja voidaan kirjoittaa hyvin erilaatuisesti. Erityisesti HTML sopii esimerkiksi tästä. HTML:stä on olemassa aika selvä (vaikkei täysin yksiselitteinen ja tarkka) formaattimääritys. Kuitenkin monien ohjelmien HTML-eksportterit eivät saa aikaiseksi edes syntaktisesti validia HTML:ää – semanttisesta järkevyydestä puhumattakaan. Hyvissäkin eksporttereissa voi olla bugeja, jotka eivät ole heti ilmeisiä.
Tiedostoja kirjoittavia ohjelmia on tarpeen tarkkailla siis kahdesta syystä. Toisaalta on tarpeen estää tiedostomuodon kirjoituksen huonosti toteteuttavilla ohjelmilla kirjoitettujen tiedostojen pääsy arkistoon. Toisaalta bugien kiertämisen varalta tarvitaan tieto siitä, mikä ohjelma tiedoston kirjoitti, jotta bugin tultua ilmi myöhemmin tiedetään, minkä kaikkien tiedostojen jatkokäsittely saattaa edellyttää erityistoimia.
Jälleen olisi myöhempää luokittelua varten toivottavaa, että sama ohjelma merkittäisiin metadataan aina samalla tavalla. Tämä ei kuitenkaan ole aivan helppoa, sillä ohjelmista on eri versioita eikä etukäteen tiedetä, mitkä ohjelmaversiot ovat arkiston ylläpidon näkökulmasta samastettavissa.
Ohjelmantunniste voitaisiin ilmaista esim siten, että metadataan merkittäisiin ohjelman nimi, ohjelman versionumero, ohjelman järjestelmäalustaversio, ohjelman toimittaja sekä mahdollinen ohjelman toimittajan oma alaversio. Esim.: AbiWord, 1.0.0, Linux (Intel), Red Hat, 1.0.0-5. (Perinteisesti järjestelmäalustaa on pidetty hierarkiassa ylempänä olevana, mutta käytännössä ohjelma ja sen versio ovat olennaisempia, koska monien ohjelmien ydinosa on sama eri alustoilla.) Luokittelun kannalta olisi hyvä, että arkistoon jo talletettujen tiedostojen ohjelmatunnistekenttien arvot olisivat tiedon syöttäjien selattavissa, jotta saman ohjelman nimestä valittaisiin aina sama kirjoitusmuoto kuin tietokannassa jo olevien tiedostojen metadatassa. Menettely vastaa jossain määrin suositeltujen avainsanatermien thesaurusta [ISO/TR 15489-2:2001(E)].
Joidenkin tiedostomuotojen kohdalla saattaa olla tarpeen vaatia, että arkistoon saa viedä ko. tiedostomuodon tiedostoja vain silloin, kun kirjoittanut ohjelma on arkiston ylläpidon hyväksymä. Erityisesti tällaisissa tilanteissa ohjelmaluettelon ylläpito on tärkeää, jotta luettelosta voidaan tarkistaa, onko jokin ohjelma jo hyväksytty. Luettelo on tarpeen myös siksi, että luettelon yhteyteen voidaan tarvittaessa liittää tietoa eri ohjelmien sellaisista bugeista, joilla on merkitystä tiedostojen jatkokäsittelyn kannalta.
Ohjelma saattaa olla arkiston oma migraatio-ohjelma.
Tiedoston kirjoittanutta ohjelmaa ei dokumentoida siksi, että tiedostoja yritettäisiin lukea juuri niillä ohjelmilla, joilla ne on kirjoitettu. On tarkoituksenmukaista varmistaa, että tallennetut tiedostot ovat luettavissa yleispätevillä lukuohjelmilla sen sijaan, että pyrittäisiin ylläpitämään kirjoittaneita ohjelmia käyttökunnossa. Joissain tapauksissa lukuohjelma ja kirjoittanut ohjelma voi olla sattumalta sama. (Tämä lähestymistapa poikkeaa olennaisesti [OCLC/RLG]:n pyrkimyksestä dokumentoida tapauskohtaisesti, millaisella laite- ja ohjelmakonfiguraatiolla mikäkin tiedosto voidaan lukea.)
Kirjoittanutta ohjelmaa vastaavasti on myöhempien mahdollisten ongelmien selvittämisen kannalta hyödyllistä merkitä metadataan, minkä työnkulun kautta tiedosto on tuotettu. Tunnisteeksi ei riitä pelkästään muusta metadatasta löytyvä dokumentin tuottaneen viraston nimi, koska työnkulku saattaa muuttua vuosien varrella.
Kun dokumenttien tuottajalle perustetaan toimintatapa, joka toistuu samana useiden dokumenttien tuotannossa, perustetaan uusi työnkulku. Esitän, että ainakin vakituisille työnkuluille annettaisiin tunniste, jonka perusteella voidaan löytää seloste työnkulusta. Jos arkistoiduissa dokumenteissa havaitaan teknisiä ongelmia, voidaan tunnisteen perusteella etsiä muita dokumentteja, jotka todennäköisesti kärsivät samasta ongelmasta.
Lisäksi metadataan voitaisiin sisällyttää hyvin lyhyt (vähän tilaa vievä) ihmisen luettava kommentti työnkulun pääpiirteistä, jotta työnkulusta saa jonkin käsityksen tutustumatta työnkulkutunnisteen avulla löytyvään työnkulkuselosteeseen.
Migraation yhteydessä työnkulkutunniste olisi pakollinen ja olisi migraatioajon tunniste. Tunnisteen avulla voitaisiin sitten löytää selostus migraatiosta.
Samasta dokumentista voi olla monta versiota samassa AIP:issa. Esimerkiksi AIP:issa voisi olla ensisijaisena esityksenä PDF, varalla CCITT G4 -pakattu TIFF ja vielä tekstidumppi hakuja [MoReq 8.1.5] varten. Vaihtoehtoisuusrooli ilmaisee tiedoston roolin suhteessa muihin versioihin vaihtoehtoisuusakselilla.
Dokumenteissa saattaa olla salaisiksi määrättyjä osia, vaikka dokumentin muut osat ovat julkisia. Näitä dokumentteja ei voida käsitellä kokonaan salaisina, jos arkistolla on velvollisuus tuottaa julkinen osa saataville. Arkistolla pitää siis olla valmius salaisten osien piilottamiseen [IU Funtional Req, MoReq 9.3.10].
Osittain salaisten dokumenttien salaisten osien piilottamiseen on kolme päämenetelmää:
Ensimmäinen vaihtoehto on toivottavin, sillä se mahdollistaa dokumenttien käsittelyn ohjelmallisesti ja minimoi taltiotilantarpeen.
Kunkin tiedoston metadataan on tarpeen merkitä, millaisesta versiosta on kyse.
Tiedoston nykyversioon liittyvä metadata on AIP:in sisällä tiedostokohtaista ja luonteeltaan sellaista, että se menettää merkityksensä, jos tiedosto migratoidaan ja vanha versio heitetään pois.
Yleensä halutaan tietää, onko objektin tavujono korruptoitunut tallennusmedian vian tai muun virheen vuoksi. Tavujonon integriteetti voidaan varmentaa liittämällä tallennetun objektin metadataan tarkistussumma tai tiiviste (message digest). Tarkoitukseen sopii esim. 128-bittinen MD5-tiiviste.
Bitti-integriteetin varmenne auttaa ainoastaan dataan kohdistuneiden vahinkojen ja onnettomuuksien toteamisessa. Se ei auta niiden korjaamisessa eikä se todista, ettei tiedostoa ole tahallisesti väärennetty. Virheiden korjaamiseen ja väärennösten toteamiseen tarvitaan monimutkaisempia menetelmiä. Virheiden korjaamista voidaan pitää tallennusmediatasolle kuuluvana toimenpiteenä.
Seuraavat kentät liittyvät koko dokumenttiin tai koko pakettiin.
Tyypillisesti on tarkoituksenmukaista, että jokaisella AIP:illa on oma tunniste arkistossa. Jos sisältödatalle pitää tehdä transformaatio toiseen formaattiin tulevaisuudessa, metadatasta pitäisi käydä ilmi, mikä versio on kyseessä. Versiosukupolvi voidaan kyllä päätellä esim. transformaatiohistoriasta, joten versiotunnisteelle ei ole aivan välttämätöntä varata omaa kenttää metadatassa.
Vaikka tiedostoformaatti sinänsä pystyttäisiin lukemaan, ei esim. taulukossa olevien numeroarvojen merkitys ole välttämättä ilmeinen. Dokumentin luontikonteksti ei varsinaisesti kuulu säilytysmetadataan, mutta kontekstimetadata [ISO 15489-1:2001(E)] on kuitenkin olennaista järkevän tulkinnan kannalta.
Jos luontikonteksti yleisellä tasolla (minkä viranomaisen minkä tyyppinen asiakirja) ja sisältö itse (taulukon sarakeotsikot tms.) eivät riitä sisällön ymärtämiseen, pitäisi metadataan liittää lyhyt sanallinen selitys esim. taulukon arvojen tulkinnasta.
On syytä olettaa, että arkistoitaviin asiakirjoihin liittyy tekijänoikeuksia tai jotain muita oikeuksia tai vaatimuksia, jotka ainakin ilman erillistä sopimusta rajoittaisivat arkiston vapautta muokata arkistoituja kohteita muuttuvan teknisen ympäristön vaatimalla tavalla.
Jotta migraatiotilanteessa vältyttäisiin juridisilta ongelmilta, tiedoston tekniseen metadataan on tarpeen liittää tieto siitä, mitä dokumentille saa tehdä. Dokumenteille saatetaan joutua tekemään transformaatioita myös silloin, kun dokumenttikopio toimitetaan arkiston asiakkaalle.
Eräs helposti dokumentoitava ja laatuarvioiden kannalta olennainen tieto on se, onko dokumentti skannattu vai digitaalisena syntynyt.
Jotta salaisiin dokumentteihin voidaan suhtautua varovaisemmin ja jotta voidaan tarkistaa, onko salaisuusstatus säilynyt dokumentin koodauksessa, on tarpeen ilmoittaa, sisälsikö dokumentti arkistoontuontiaikana salaisia osia. Tiedoston arkistoon tuonnin yhteydessä ei voida tietää varmasti, miten julkisuusstatus tulee muuttumaan, joten ajankohtaisen statuksen löytämiseen tarvitaan jotain muuta logiikkaa.
Hävikin ymmärtämisen kannalta olisi eduksi tietää, millä työkaluilla dokumentti on alunperin luotu. Valitettavasti tätä ei monesti osata sanoa tarkasti. Arkistoversio voi olla Wordistä tulostettu PDF, mutta silti dokumentti voikin olla alunperin Word Perfectillä tehty ja siinä on voinut olla vaikka Illustratorilla piirrettyjä kuvia. Dokumentin luontiprosessin dokumentointi voisi olla vaikeaa eikä kaikkea edes muisteta, joten ehdotan, että dokumentin luomiseen käytetyille ohjelmille jätetään vain valinnainen ja vapaamuotoinen tekstikenttä.
Vaikka kentän ilmaisema asia olisi sinänsä hyvä tietää, en usko, että kenttä täytettäisiin käytännössä systemaattisesti ja pätevästi. Kentästä olisi siis käytännön hyötyä lähinnä silloin, kun arkiston käyttäjä vaivautuu tutkimaan yhsittäistä dokumenttia tarkemmin. Realistisesti ajatellen kenttä ei kelpaa automaattisten analyysien tekemiseen suurista dokumenttijoukoista.
Eri dokumenteissa pidetään tärkeinä eri asioita. Lisäksi tärkeät asiat eivät välttämättä määräydy kiinteästi dokumentista vaan myös arkiston käyttäjän tavoitteista.
Esimerkiksi valtionlaitoksen sisäisessä muistiossa tekijän kirjoittama merkkien virta on ensiarvoisen tärkeä muistion viestin ymmärtämisen kannalta. Lisäksi muistiossa on tiettyjä loogisia rakenteita, joiden tunnistaminen edistää dokumentin ymmärtämistä. Rakenteet esitetään ihmisille tyypillisesti asettelulla ja kirjasintyyleillä. Sen sijaan ohjelmallisen käsittelyn (esim. haku vain muistioiden otsikoista) kannalta on tarkoituksenmukaista, että rakenne on koodattu eksplisiittisesti ohjelmallisesti luettavaan muotoon eikä sen ymmärtäminen ole ihmisen visuaalisen hahmotuksen varassa. Muistioiden asiasisällöstä kiinnostuneiden kannalta on siis olennaista arkistoida muistion teksti ja rakenne. Toisaalta joku tyyliseikkojen tutkija voisikin olla kiinnostunut siitä, minkä näköisenä muistio tulostettiin silloin, kun se luotiin.
Dokumenteissa ei esiinny pelkästään sellaista asioita, jonka dokumentin tekijä olisi tietoisesti sisällyttänyt dokumenttiin. Joukossa voi olla myös dokumentin tekemiseen käytetyn ohjelman lisäämiä ”artifaktoja” [PDF1.4], joiden säilyttäminen ei ole olennaista. Lisäksi tulostetuissa dokumenteissa voi olla työpohjasta tulevia logoja tai yhteystietoja, jotka eivät varsinaisesti kuulu asiasisältöön.
Alunperin epäolennaisina pidetyistä asioista mahdollisesti kiinnostuneet arkiston käyttäjät eivät ole ainoa syy siihen, miksi tärkeän määrittely on vaikeaa. Kirjoittajat saattavat teksteissään viitata johonkin sellaiseen heille näkyvään dokumentin ominaisuuteen, jonka ei teoriassa pitäisi kuulua dokumentin tärkeimpään olemukseen. Esimerkiksi pitkän tekstin sivujakoa voidaan pitää vain sivuihin jaetun jakelumedian aiheuttamana artifaktana. Silti kirjoittaja saattaa viitata ”kovakoodatusti” johonkin sivunumeroon sen sijaan, että dokumenttiin olisi sijoitettu looginen linkki kahden sisältökohdan välille.
Ei ole selvää, että kaikki tärkeinä pidetyt asiat olisivat alkuperäisessä tiedostossa ihmisen koodaamina. Hyvin usein dokumentin laatija ei koodaa esim. loogista rakennetta, rivinjakoa ja sivujakoa eksplisiittisesti.
Dokumentin tuottajan itsensä tekemä konversio voidaan ajatella jossain mielessä dokumentin laatijan mielestä riittävän kelvolliseksi asian välittymisen kannalta.
Tämä voidaan joissain tapauksissa päätellä formaatista. Hävikkiä voidaan arvioida vertaamalla näitä attribuutteja aiempiin vaiheisiin liittyviin attribuutteihin.
Virastossa luodaan määrämuotoinen lausunto Microsoft Wordillä. Dokumentin laatimisessa käytetään Wordin työkalupalkin merkkityylipainikkeita (lihavointi, kursivointi jne.) muttei loogisia tyylejä (Heading 1 jne.). Dokumentin tekstissä viitataan sivulle 2, mutta sivunvaihtoja ei ole tehty manuaalisti. Fonttina on Times New Roman. Dokumenttiin liittyy viivadiagrammi. Dokumentin laatija tekee dokumentista PDF:n ja toteaa sen kelvollisen näköiseksi. Arkistossa PDF:stä tehdään TIFF.
Olennaiset asiat: looginen rakenne (lausunto on määrämuotoinen), sivujako.
Alkuperäiseen tiedostoon koodatut asiat: kirjasin, asettelu lohkotasolla, merkkeihin liitetty tyyli, paperiesityksen fyysiset ulottuvuudet, viivapiirrosten koodaus vektorigrafiikkana, visuaalisia viitteitä loogisesta rakenteesta.
Arkistoon toimitettuu tiedostoon koodatut asiat: sivujako, rivijako, kirjasin, tiettyihin merkkeihin liitetyt tyylit, paperiesityksen fyysiset ulottuvuudet, viivapiirrosten koodaus vektorigrafiikkana, visuaalisia viitteitä loogisesta rakenteesta.
Arkistoituun muotoon koodatut asiat: sivujako ja visuaalisia viitteitä muista asioista.
Huomioita: Olennaisia asioita ei ollut koodattu alkuperäiseen tiedostoon eksplisiittisesti. Lopputuloksessa ei ole tietokoneen luettavassa muodossa koodattuna mitään alkuperäiseen tiedostoon tietokoneen luettavassa muodossa koodatuista asioita. Kuitenkin lopputulos on riittävästi ihmisen havainnoitavissa.
Jos olennaiset asiat olisi systemaattisesti tiedostettu ja asiaan reagoitu, tiedostoformaatit ja dokumenttienlaatimistyönkulut tukisivat juuri olennaisten asioiden koodaamista tiedostoihin. Kun ollaan tekemisissä olennaisten asioiden suoraa koodaamista tukemattomien formaattien kanssa, olennaisuuden koodaaminen vaatisi erillistä ihmistyötä. Olennaisuuden arviointi edellyttää sitä, että arvioija tuntee aihepiirin ja on lukenut dokumentin läpi ajatuksella. Käytännössä siis olennaisten asioiden merkitseminen metadataan pätevästi vaatisi huomattavaa lisätyöpanosta, jos se pitäisi teettää jollakulla, jonka tehtäviin dokumentin lukeminen ei jo muutenkin kuulu. Niinpä ei ole kovin realistista odottaa, että näitä asioita koodattaisiin metadataan dokumenttikohtaisesti.
Yllä mainittuja asioita voitaisiin kyllä merkitä metadataan siten, että arvot säädettäisiin kerran kutakin dokumentintuottajakanavaa varten sillä oletuksella, että kukin dokumentintuottajaviranomainen tuottaa paljon saman lajityypin dokumentteja, joilla on samat ominaisuudet.
Pelkkää tekstiä voidaan tallentaa ja muotoilla muutamalla yleisellä tavalla. Unicodessa olisi kyllä yksiselitteiset merkit kovan rivinvaihdon ja kappalerajan ilmaisemiseen, mutta käytännössä ohjelmat käyttävät Unicode-tekstissäkin line feediä (LF), carriage returnia (CR) tai carriage returnia ja line feediä peräkkäin (CRLF) tarkoittamaan erityyppisiä rivinvaihtoja ja kappalejakoja.[Unicode-XML]
Niinpä tavallisen tekstin metadataan on syytä merkitä, miten rivinvaihdot ja kappalejako on ilmaistu.
Perinteiset rivinvaihtomerkit voidaan normalisoida helpommin käsiteltäviksi seuraavasti: korvataan jokainen CRLF-yhdistelmä LF:llä ja sen jälkeen korvataan jokainen CR LF:llä.
Joissain pelkkää tekstiä sisältävissä tiedostoissa on käytetty merkkipohjaisia muotoiluja sillä oletuksella, että kaikki merkit ovat yhtä leveitä. Tällaisia tekstejä ei voida jouksuttaa riveille uudestaan vapaasti tai esittää vaihtelevan levyisellä fontilla rikkomatta muotoilua. Siksi metadataan tarvitaan tieto siitä, onko tiedostoissa merkkipohjaisia muotoiluja kuten esim. välilyöntien avulla muodostettuja taulukoita.
Tekstitiedoston metadataan kuuluu hyvin olennaisena tietona merkkikoodaus, koska ilman tätä tietoa tiedoston sisältöä ei voida kuvata oikeiksi merkeiksi. Voitaisiin toki ajatella, että eri tavoilla koodatut tekstitiedostot laskettaisiin eri tiedostomuodoiksi siinä mielessä kuin esim. eri menetelmillä koodattuja TIFF:ejä pitää käsitellä eri tavoin. Jos päätetään, että kaikki tekstitiedostot arkistossa ovat UTF-8 -koodattuja, olisi merkkikoodauksen tallentaminen redundanttia, vaikkei paljon tilaa vievää tai haitallista. Joka tapauksessa merkkikoodaus täytyy tietää joko eksplisiittisen metadatakentän perusteella tai sitten implisiittisesti sillä perusteella, ettei arkistossa ole muita kuin UTF-8- ja mahdollisesti UTF-16 -koodattuja tekstitiedostoja.
Unicodessa jotkin merkit voidaan esittää monella eri tavalla. Merkkijonojen vertailtavuuden ja esitysohjelmatoteutusten kannalta on tarkoituksenmukaista valita jokin neljästä Unicode-normalisaatiomuodosta.[Unicode-norm] Tekstihakujen kannalta olisi edullista käyttää samaa normalisaatiomuotoa koko arkistossa. Saattaa kuitenkin olla, että syystä tai toisesta halutaan tukea useampaa kuin yhtä normalisaatiomuotoa. Joka tapauksessa eksplisiittinen tieto normalisaatiomuodosta auttaa sikäli, ettei esim. hakuohjelman tarvitse varmistaa, onko tiedosto normalisoitu tietyllä tavalla.
Alkuperäisen merkkikoodauksen perusteella voidaan arvioida sitä, millaisia merkkejä alkuperäisessä tiedostossa on voinut olla koodattuna. Tämän perusteella voidaan taas arvioida sitä, ovatko tiedoston laatijan merkkivalinnat johtuneet koodauksen rajoituksista.
Jotta voitaisiin arvioida normalisaation aiheuttamia muutoksia, on hyvä koodata metadataan myös alkuperäinen normalisaatiomuoto, jos tiedosto oli jo alunperin koodattu johonkin Unicode-transformaatioformaattiin (UTF-8, UTF-16, UTF-32).
Esitän, ettei XML:ää pidettäisi tiedostoformaattina arkiston näkökulmasta, vaan jokaista arkistoon hyväksyttyä XML-sanastoa käsiteltäisiin omannimisenä formaattinaan. Tästä huolimatta XML-pohjaisille dokumenteille voidaan määritellä yhteisiä metadataominaisuuksia.
XML-tiedostojen metadataan ei tarvitse merkitä merkkikoodausta, kunhan vaaditaan, että arkistoon saa viedä vain sellaisia merkkikoodauksia, joita kaikkien XML-määrityksen mukaisten XML-jäsentimien on pakko tukea. Nämä koodaukset ovat UTF-8 ja UTF-16 (sekä little-endian että big-endian).[XML 1.0]
[CharMod]:in nykyinen luonnos edellyttää Unicode normalisaatiomuoto C:n käyttöä. Lisäksi tiedostojen pitäisi olla sisällytysnormalisoituja (include-normalized), eli tiedoston on Unicode-mielessä normalisoitu vielä senkin jälkeen, kun ulkoisista tiedostoista on tuotu merkkijonoja ja merkkiviittaukset on avattu (ks. [CharMod]).
Kuten tavallisessa tekstissä.
Bittikarttoihin liittyy tärkeitä kuvan leveyteen, korkeuteen ja värisyvyyteen liittyviä tietoja. Yleensä nämä tiedot on kirjotettu kuvatiedostoon joka tapauksessa. Jos arkistoston dokumenteista halutaan tehdä laatuarvioita lukematta taltiossa olevia tiedostoja, saattaa olla tarkoituksenmukaista kopioida bittikarttojen mitat myös hakemistotietokannassa pidetyn metadatan mukaan. Viimesitään migraatiotilanteessa vanhat tiedot pitäisi kerätä mukaan migraation metadataan.
Tyypillisesti videoon liittyy enemmän tai vähemmän kiinteästi ääniraita, jolloin pitää ottaa huomioon myös ääntä koskevat näkökohdat. Lisäksi pakkauksen parametrit tai kodekin käyttämä MPEG-4 -profiili ovat olennaisia asioita, mutta ne ovat tiedostoformaattikohtaisia. Lisäksi arkiston tarpeiden kannalta MPEG-4 -profiili (tai vastaava) voidaan ajatella formaatinmäärittelytasolla kuuluvaksi (vrt. eri tavoilla pakattujen TIFF:ien käsittely eri formaatteina arkiston kannalta).
Käytännössä video on tuotantovaiheessa aina jossain muussa kuin arkistoon soveltuvassa formaatissa, ellei aivan erityisesti haluta arkistoida paljon tilaa vieviä tuotantotiedostoja. Videoiden metadataan olisi hävikin ymmärtämisen kannalta olennaista sisällyttää arkistomuotoa kuvailevien metadatakenttien lisäksi vastaavat kentät lähtöversiosta, jos lähtöversion ominaisuudet tunnetaan.
Videolle pätevät still-bittikartan kentät. Tosin yleensä fyysiset mitat katsotaan määrittelemättömiksi eikä alfakanavaa yleensä ole.
Still-kuvien metadatan lisäksi videoiden metadataan tarvitaan tieto kuvataajuudesta (kuvia sekunnissa, fps). Kuvataajuuden muuttuminen konversion yhteydessä vaikuttaa video havaittuu laatuun.
Esimerkiksi datamäärä aikayksikköä kohden (data rate) on laatua arvioitaessa tärkeä parametri. Tämä parametri on myös määritettävissä (ainakin keskimääräisenä) kaikille videoformaateille. Kuitenkaan eri formaattien datanopeudet (data ratet) eivät ole yhteismitallisia. Siksi on olennaista, että tällaista kenttää pidetään formaatin ominaisuutena erikseen eikä videon yleisenä ominaisuutena.
Erilaisilla ääniformaateilla on monia näennäisesti yhteisiä ominaisuuksia, jotka eivät kuitenkaan ole laadun arvioinnin kannalta yhteismitallisia eri formaattien kesken.
Oikeastaan ainoa erilaisille ääniformaateille kutakuinkin yhteismitallinen ominaisuus on se, millainen näytetaajuus puretulla digitaaliäänellä on suoraan purkualgoritmista tulleena. Ainakin teoriassa pitäisi kuitenkin olla mahdollista määritellä pakkauksia, joilla ei olisi mitään natiivia purkunäytetaajuutta.
Äänen laatua voidaan kuvailla karkeasti subjektiivisesti. Laatuhaittoja on kaksi olennaista:
Jos halutaan pitää arvio sellaisena, että eri ihmiset antaisivat kutakuinkin samat arvioit, skaalan pitää olla hyvin karkea: esim. vain kolmiportainen. Tällöin formaattimigraation laatua arvioitaessa voidaan korvakuulolta arvoida sitä, siirtyikö laatu huonompaan luokkaan.
Ehdotan perinteiseltä kuulostavalle häiriölle seuraavia vaihtoehtoja
Ehdotan pakkausvääristymille seuraavia vaihtoehtoja
Pakkaamattomien formaattien kohdalla ilmoitetaan datanopeuden sijaan yleensä näytteen koko. Yksikkönä on tyypillisesti bitti (eikä tavu). Tämä on olennainen asia, kun kuvaillaan lähtöformaattia, joka on tyypillisesti käsitteellisellä tasolla lineaarinen PCM (ja tarkka tiedostoformaatti on yleensä vähemmän oleinnainen asia). Pakattujen formaatien kohdalla on tapana ilmoittaa datanopeus. Yksikkönä on tyypillisesti bittiä sekunnissa eikä tavua sekunnissa.
Bitti-integriteetin varmanne auttaa arkistoa päättelemään, onko arkistoitu tavujono vahingoittunut tahattomasti. Se ei todista ulkopuolisille, ettei arkisto ole muuttanut dokumenttia tahallisesti. Jos dokumentin tuottanut viranomainen allekirjoittaa dokumentin arkistomuodon digitaalisesti ennen arkistoon toimittamista, arkisto voi todistaa, ettei se ole muuttanut dokumenttia yksin (ilman alkuperäisen viranomaisen apua). Allekirjoituksilla ei voida todistaa pitävästi salaliittoteoretisoijille, etteivät viranomaiset ole yhteistyössä muuttaneet arkistoituja dokumentteja.
Allekirjoitusten pitämiseen todistusvoimaisina liittyy ongelmia. Allekirjoitus on asymmetrisellä menetelmällä kryptattu dokumentista laskettu tiiviste (message digest). Asymmetriset menetelmät edellyttävät sitä, että allekirjoittajan yksityinen avain pysyy salaisena ja julkinen avain on julkinen sekä juuri allekirjoittajan julkiseksi avaimeksi tunnettu. Autenttisuudesta kiinnostuneen tahon pitäisi voida vakuuttua siitä, että yksityinen avain on pysynyt koko ajan vain oikeissa käsissä. Lisäksi julkinen avain pitäisi olla tiedettävissä juuri allekirjoittajaksi väitetyn tahon julkiseksi avaimeksi. Jotta allekirjoituksista olisi hyötyä, pitäisi ratkaista tavalliset julkisen avaimen arkkitehtuuriin (PKI, Public Key Infrastructure) liittyvät ongelmat. Asiaan kuuluu se, että kaikki luottamus ja luotettavuus kyseenalaistetaan ja problematisoidaan paljon pidemmälle kuin perinteisten allekirjoitusten todistusvoimaa tarkasteltaessa.
Jotta dokumenttien allekirjoitusajankohta voitaisiin todistaa, tarvittaisiin myös luotettava kellon sisältävä musta laatikko, johon tiivisteet voitaisiin lähettää aikaleimattaviksi.
Lisäksi allekirjoitus ei enää päde, jos dokumentti migraation yhteydessä transformoidaan siten, että allekirjoitetut bitit muuttuvat. Niinpä allekirjoitus olisi pätevä vain ensimmäiseen migraatioon asti. Häviöttömästi pakattujen bittikarttojen kohdalla ongelmaa voisi lievittää siten, että tiiviste laskettaisiin vain puretusta pikselien väriarvot ilmaisevasta tietyllä tavalla järjestetystä tavuvirrasta eikä kokonaisesta pakatusta tiedostosta.
Käytännössä salaus joudutaan purkamaan arkistoon oton yhteydessä.[MoReq 10.6.4]
Onnistunut siirto toiselle taltiolle ei muuta tallennetun sisältöobjektin tavuja eikä siirtoa siksi tarvitse dokumentoida sisältöobjektiin välittömästi liittyvään rakennemetadataan [OAIS 5.1.4]. Silti tallennusmediasta itsestään on tarpeen olla dokumentaatiota, vaikkei sitä olekaan tarkoituksenmukaista liittää kuhunkin taltiolla olevaan AIP:iin.
Myöskään tietyn dokumentin käyttöä koskevia tilastotietoja ei kannata kirjoittaa AIP:iin itseensä, koska AIP:in muuttaminen on riskialtista.
[Unicode-XML] Unicode in XML and other Markup Languages. (Unicode Technical Report #20. W3C Note 18 February 2002.) Martin Dürst ja Asmus Freytag. The World Wide Web Consortium ja The Unicode Consortium. 2002. URL: http://www.w3.org/TR/2002/NOTE-unicode-xml-20020218 (uusin versio: http://www.w3.org/TR/unicode-xml/)
[CharMod] Character Model for the World Wide Web 1.0. (W3C Working Draft 30 April 2002.) Dürst (toim.) et al. The World Wide Web Consortium. 2002. URL: http://www.w3.org/TR/2002/WD-charmod-20020220/ (uusin versio: http://www.w3.org/TR/charmod/)
[DoD 5015.2] Design Criteria Standard for Electronic Records Management Software Applications. (DoD 5015.2-STD) United Stated of America Department of Defense. 1997.
[IU Funtional Req] Functional Requirements for Recordkeeping Systems (luonnos). IU Electoric Records Project. Indiana University. 2001.
[IU Methodology] Analyzing Functions, Identifying Transactions, and Evaluating Recordkeeping Systems – A Report on Methodology. Philip C. Bantin ja Gerald Bernholm. Archives and Museum Informatics: Cultural Heritage Informatics Quarterly, vol. 10, no 3, 1996, pp. 246-266. URL: http://www.indiana.edu/~libarch/ER/NHPRC-1/article1.html
[ISO/TR 15489-2:2001(E)] Information and documentation – Records management – Part 2: Guidelines. (ISO/TR 15489-2:2001(E)) ISO 2001.
[ISO 15489-2:2001(E)] Information and documentation – Records management – Part 2: General. (ISO 15489-1:2001(E)) ISO 2001.
[METS] Metadata Encoding & Transmission Standard Official Web Site. Library of Congress. 2002. URL: http://www.loc.gov/standards/mets/
[METS-Dict] Data Dictionary for Administrative Metadata for Audio, Image, Text, and Video Content. Library of Congress. 2002. URL: http://lcweb.loc.gov/rr/mopic/avprot/extension2.html
[MODS] Metadata Object Description Schema Official Website. Library of Congress. 2002. URL: http://www.loc.gov/standards/mods/
[MoReq] Model Requirements for the Management of Electronic Records. (”MoReq Specification”.) Marc Fresko (toim.) ja Martin Waldron (toim.). Euroopan komissio. 2001.
[NARA36CFR1234] National Archives and Records Administration Regulations: 36 CFR Part 1234. 2001-05-16 viimeksi muutettu versio.
[NHPRC req] Metadata Requirements for Evidence. David Bearman ja Ken Sochats. URL: http://www.archimuse.com/papers/nhprc/BACartic.html
[NHPRC spec] Metadata Specifications Derived from the Functional Requirements: A Reference Model for Business Acceptable Communications. 1996. URL: http://www.archimuse.com/papers/nhprc/meta96.html
[OAIS] Reference Model for an Open Archival Information System (OAIS). (CCSDS 650.0-R-2, suositusluonnos) Consultative Committee for Space Data Systems. 2001. URL: http://www.ccsds.org/documents/pdf/CCSDS-650.0-R-2.pdf
[OCLC/RLG] A Metadata Framework to Support the Preservation of Digital Objects. The OCLC/RLG Working Group on Preservation Metadata. OCLC Online Computer Library, Inc. Dublin, Ohio. 2002. URL: http://www.oclc.org/research/pmwg/documents.shtm
[PDF 1.4] PDF reference: Adobe portable document format version 1.4. 3. laitos. Adobe Systems Incorporated. Addison-Wesley. 2001. URL: http://partners.adobe.com/asn/developer/acrosdk/docs/filefmtspecs/PDFReference.pdf
[RFC 2646] The Text/Plain Format Parameter. R. Gellens (toim.). IETF. 1999.
[RKMS] Recordkeeping Metadata Standard for Commonwealth Agencies. National Archives of Australia. URL: http://www.naa.gov.au/recordkeeping/control/rkms/
[Unicode-norm] Unicode Normalization Forms. Mark Davis ja Martin Dürst. The Unicode Consortium. 2002. URL: http://www.unicode.org/unicode/reports/tr15/
[XML 1.0] Extensible Markup Language (XML) 1.0 (Second Edition). T. Bray, E. Maler, J. Paoli ja C. M. Sperberg-McQueen. W3C. 2000. URL: http://www.w3.org/TR/2000/REC-xml-20001006