AIP-ehdotus

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).

AIP eli Archival Information Package on paketti, jossa dokumenttia pidetään arkistossa. AIP:in suunnittelua on käsitelty laajemmin Kongressin kirjaston AIP-mietinnössä[AIP].

[AIP]:ssa esitetään, että AIP olisi itsepurkautauva arkisto (self-extracting archive). (Tässä ”arkisto” tarkoittaa tiedostoa, joka kokoaa monta tiedostoa yhteen tiedostoon. Käytän jäljempänä termiä ”paketti” vakiintuneen termin sijaan, jottei AIP:in formaatti sekoittuisi AIP:in sisällä oleviin arkistokelpoisiin formaatteihin.) Itsepurkautuvan paketin käyttö on kuitenkin lyhytnäköistä pitkäaikaissäilytyksen kannalta, koska itsepurkautuava paketti on riippuvainen jostain tietystä ohjelmiensuoritusympäristöstä. Esitän, ettei AIP:in paketoinniksi valittaisi itsepurkautuvaa pakettia, vaan tunnettu ja dokumentoitu paketointiformaatti, joka voidaan purkaa yleisesti saatavilla olevilla erillisillä ohjelmilla.

Paketointiformaatteja on olemassa useita, mutta kaksi niistä ovat selvästi muita suositumpia ja laajemmin tuettuja sekä sellaisia, että niistä on vapaita toteutuksia. Nämä kaksi formaattia ovat zip ja tar. Zip tukee pakkausta suoraan. Tar-tiedostot eivät tue pakkausta suoraan, vaan ne pakataan jollain erillisellä pakkausohjelmalla (compress, gzip, bzip2). Zip-tiedosto tukee random accessia, mutta tar-arkisto ei tue. Gzipattu tai bzip2-pakattu tar-tiedosto on yleensä zip-tiedostoa pienempi. Ero on huomattava, jos paketissa on paljon pieniä tiedostoja. Zip-paketissa jokainen tiedosto pakataan erikseen. Tar-tiedostoa pakattaessa koko tar-tiedosto on pakkausalgoritmin kannalta yksi kokonaisuus.

Compress käyttää patentoitua LZW-algorithmia, eikä compressia siksi ole enää tapana käyttää. Gzip käyttää deflate/inflate algoritmia toteutettuna siten, ettei patenttiongelmia tiettävästi ole. Bzip2 pakkaa yleensä tiedoston pienemmäksi kuin gzip, mutta bzip2:n patenttistatusta ei ole tutkittu yhtä tarkasti kuin gzipin patenttistatusta. (Patenttistatus Yhdysvalloissa vaikuttaa käytännössä ohjelmien saatavuuteen myös muualla.)

Zip-paketin sisällä tiedostoja voidaan pakata useammalla kuin yhdellä algorithmilla. Näistä ainakin yksi on mahdollisesti patentoitu ja ainakin yksi voidaan toteuttaa ilman patenttiongelmia. Patenttivapaasti toteutettavissa oleva algoritmi on deflate/inflate. Random access -ominaisuuden vuoksi Sun on valinnut deflate/inflate-zip-formaatin jar-formaatin pohjaksi ja OpenOfficen dokumenttien kontaineriksi. Jar-tiedosto on zip-tiedosto, jossa on muun sisällön lisäksi määrämuotoinen manifesti ja ainoa sallittu pakkausmenetelmä on deflate.

Luonnolliset vaihtoehdot AIP-kontainereiksi ovat siis deflate-pakattu zip-tiedosto (.zip) ja gzip-pakattu tar (.tar.gz). Zip-formaattia voi lukea ja kirjoittaa mm. InfoZip-ryhmän zip- ja unzip-ohjelmilla (free software / open-source), PKWaren tuotteilla, JDK:n jar-työkalulla. Gzip-pakattuja tar-tiedostoja voi lukea ja kirjoitaa kätevimmin GNU tarilla, mutta myös gzip yhdessä jonkin toisen tar-toteutuksen kanssa toimii, ellei tiedostoon ole tallennettu erityisen pitkiä tiedostopolkuja. (Erityisen pitkiä polkuja ei pitäisi esiintyä AIP-käytössä, vaan lähinnä kokonaisia tiedostojärjestelmia paketoitaessa.)

Zip-pakettien käyttöä puoltaa se, että zip-tiedostojen random access -lukemista varten on olemassa valmiita kirjastoja ja random access -ominaisuuden vuoksi paketista voidaan lukea metadata purkamatta koko pakettia.

Tarin käyttöä taas puoltaa se, että tiedostokoko saadaan yleensä hieman pienemmäksi. Tar-formaatin variantit saattavat kuitenkin aiheuttaa ongelmia. Tar-formaatista on olemassa ISO-standardi, mutta käytännössä GNU tar -variantti on erittäin laajalti käytetty.

Kumpikaan formaatti – ei zip eikä tar – ei ole ihanteellinen, mutta käytännössä ne ovat kuitenkin ne formaatit, jotka ovat riittävän laajalti tuettuja ja joista on saatavana toteutukset lähdekoodeineen.

Random access -ominaisuuden vuoksi ehdotan käytettäväksi deflate-pakattua zipiä.

AIP:in rakenne

AIP:in sisällä eri formaattivaihtoehdot on jaoteltu kansioihinAIP sisältää paketin käytössä muuttumattoman metadatan (ei esim. paketin lukukertoja) ja dokumentin esityksen yhdessä tai useammassa formaatissa. Luonteva tapa näiden tallentamiselle on se, että AIP:in päätasolla on metadatatiedosto ja kansiot kullekin AIP:issa käytössä olevalle tiedostoformaatille. (Ks. kuva.)

Olennainen metadata kannattaa tallentaa AIP:iin itseensä siinäkin tapauksessa, että metadataa kopiotaisiin tietokantatauluihin. Tietokannan säilyttäminen toiminnallisempana on vaikeampaa kuin AIP-kokoelman säilyttäminen tiedostojärjestelmässä. Kun metadata on AIP:eissa mukana, voidaan hätätapauksessa hakemistotietokanta generoida AIP:eista uudestaan.

Jos formaatti edellyttää usean tiedoston käyttöä, tiedostot sijoitettaisiin kaikki formaatin kansioon. Myös esim. rakenteiseen versioon liittyvät kuvat sijoitettaisiin ko. rakenteisen version kansioon. Jos formaatti vaatii monta tiedostoa siksi, että sivut tallennetaan erikseen, ilmaistaan numerointi tiedostojen nimissä.

Tiedostojen nimeäminen

Olisi hyvä, että itse AIP:in nimestä kävisi ilmi vähintään AIP:in uniikki tunniste. (Jokaisella dokumentilla oletetaan olevan uniikki tunniste.) Vähimmäisnimi olisi siis uniikkitunniste.zip.

Tiedostojen nimeäminen AIP:in sisällä on lähinnä makuasia, kunhan asiasta tehdään päätös ja ollaan sitten johdonmukaisia.

Ensimmäinen tapa helpottaa tiedostojen tunnistamista, jos tiedostot jäävät jonnekin irralleen. Toinen tapa helpottaa paketointi- ja katseluohjelman kirjoittamista mutta vain minimaalisesti ensimmäiseen verrattuna. Kolmas tapa helpottaa ihmiskäyttäjiä, jotka tutkivat AIP:ia manuaalisesti, mutta vaikeuttaa katseluohjelmien kirjoittamista.

Koska nykyisin monissa järjestelmissä tiedostotyyppi tunnistetaan tiedoston nimen loppuosan perusteella, AIP:iin tallennettujen tiedostojen nimien lopussa pitäisi olla formaatin yleisesti hyväksytty tunniste. Nykyisin myös Microsoftin järjestelmät sallivat yli kolmikirjaimiset tunnisteet, joten niiden käyttö voidaan sallia (ehkä tapauskohtaisesti jopa vaatia).

Ks. myös http://www.europarl.eu.int/docman/project/TFDM-P(2000)0003EN0.htm kohta Draft Recommedation.

Pakkaaminen tehokkaasti

Deflate-algoritmin tuottaman pakatun tiedoston kokoa ja toisaalta suoritusaikaa voi säädellä jonkin verran. Lisäksi tiedostot on mahdollista sisällyttää zip-tiedostoon pakkaamattomina. Koska arkistossa pakkaus suoritetaan kerran ja levytila maksaa, kannattaa tiedostot pakata mahdollisimman pieniksi. Info-Zipin zip-ohjelmalla tämä tehdään optiolla -9. Näin vältetään samalla eräs datakorruptiobugi[ZIP-FAQ23]!

Vastaavasti gzipiä käytettäessä paras pakkaus saadaan optiolla -9.

Lähteet

[AIP] Archival Information Package (AIP) Design Study (LC-DAVRS-07). Library of Congress. 2001. URL: http://www.loc.gov/rr/mopic/avprot/AIP-Study_v19.pdf

[ZIP-FAQ23] INFO-ZIP Frequently Asked Questions (kysymys 23). Greg Roelofs. 2002. URL: http://www.info-zip.org/pub/infozip/FAQ.html#corruption