Teknillisen korkeakoulun kirjaston tiedotuslehti
2 / 1998

Internet ja metadata

Juha Hakala

atk-erikoistutkija

Helsingin yliopiston kirjasto

juha.hakala@helsinki.fi

Tämä artikkeli pyrkii tekemään lukijoille tutuksi käsitteen metadata, ja esittelemään tapoja, joilla metadataa voidaan tuottaa ja käyttää hyväksi Internet-tiedonhaun kehittämisessä.

Mikä ihmeen metadata?

Internet-tiedonhakua on jo vuosia sitten verrattu paloletkusta juomiseen. Kun kirjastoissa tiedon tulvaa kontrolloidaan valitsemalla ja organisoimalla kustantajien tuottama aineisto, Internetissä tätä ei tee kukaan. Ei siis ihme, että paloletkusta on hyvää vauhtia tulossa Päijännetunneli: jopa spesifi Alta Vista -haku voi tuottaa kymmeniätuhansia viitteitä. Ellei mitään tehdä, sama haku tuottaa muutaman vuoden päästä tuplaten viitteitä, edellyttäen että Alta Vistan kate pysyy samana.

Verkkohakua voidaan tietenkin tehostaa parantamalla Alta Vistan kaltaisten palvelujen hakuominaisuuksia, mutta on ilmeistä, että todella tehokas tiedonhaku onnistuu vain lisäämällä verkosta löytyvän metadatan määrää ja parantamalla sen laatua. Tehokas tarkoittaa tässä tarkkuutta; sitä että tuhansien viitteiden asemesta saadaan muutamia kymmeniä, jotka ovat kaikki relevantteja.

Metadata ei ole dataa vaan informaatiota informaatiosta, Internetistä löytyvien dokumenttien kuvailutietoja. Laadukas metadata on rakenteista; toisin sanoen kaikki kuvailutieto ei ole yhdessä kentässä, vaan se on jaettu muun muassa tekijä-, nimeke-, ja aihe-kenttiin. Hyvästä metadatatietokannasta, kuten esimerkiksi kirjaston näyttöluettelosta voit hakea Einsteiniä tekijänä tai kohdehenkilönä, tai löytää suhteellisuusteoriaa käsittelevän erikielisen aineiston suomalaisesta tietokannasta yhden asiasanan (suhteellisuusteoria) turvin.

Metadatan rakenteen määrittelee formaatti, joka kertoo käytettävissä olevat kentät ja koodit. Formaatin ohella työskentelyyn tarvitaan säännöt, jotka kertovat miten formaattia sovelletaan. Julkaisujen kuvailuun käytetään tätä nykyä melkoista joukkoa erilaisia ohjeistoja. Ne on varsin tyhjentävästi arvioitu EU:n DESIRE-projektissa laaditussa, maaliskuussa 1997 julkaistussa arviossa (katso http://www.ukoln.ac.uk/metadata/DESIRE/overview). Sen mukaan useimmat formaatit on kehitetty alunperin jonkin erikoisalan tarpeisiin, mutta tästä huolimatta niillä on yhteinen ydin: dokumenteilla kun usein on esimerkiksi tekijä, nimeke ja aihe.

Kirjastojen käyttämä, 1970-luvun alussa kehitetty MARC eli Machine Readable Cataloguing -formaatti on esimerkki hyvin rakenteisesta, teknisesti vanhanaikaisesta mutta edelleen tehokkaasta formaatista, jonka avulla voidaan rakentaa erittäin tehokas hakujärjestelmä. Esimerkiksi yliopistokirjastojen yhteisluettelo LINDA sisältää yli kolme miljoonaa viitettä, mutta tiedon rakenteisuuden ja tallennuksen kontrolloinnin ansiosta tietokanta tuottaa yleensä hallittavan kokoisia tulosjoukkoja, ja ellei tuota, hakua voi helposti rajata. Tähän tulokseen ei tietenkään päästä pelkän formaatin avulla, vaan siihen tarvitaan myös ammattitaitoinen henkilökunta.

MARC-luetteloinnin ongelmana onkin sen vaatima korkea ammattitaito ja aika, jonka yhden tietueen tallentaminen keskimäärin vie. Vaatimukset verkkojulkaisujen kuvailujen sisällyttämisestä kirjastojen tietokantoihin voimistuvat sitä mukaa, kun kirjastojen käyttäjille käy ilmeiseksi että Internetistä on vaikeaa löytää tietoa nopeasti ja helposti, toisin kuin kirjaston tietokannasta. Siksi kirjastojen pitää kehittää muita ratkaisuja verkon dokumenttien kuvailuun. Oman henkilökunnan resurssit kun eivät riitä edes kaikkein relevanteimman verkkoaineiston käsittelyyn, kun perinteinen aineisto on hoidettava uuden rinnalla.

Dublin Core

Koska kirjastot eivät voi oleellisesti lisätä luettelointiin käytettäviä resursseja, on dokumenttien kuvailijat rekrytoitava muualta. Käytännössä ainoa ratkaisu on tällöin se, että dokumenttien tekijät tai julkaisijat luovat myös niiden kuvailut. Tähän työhön tarvitaan helposti opittava ja yksinkertainen formaatti, joka on kuitenkin joustava siten, että sillä voi tehdä myös "kunnon jälkeä" ajan ja ammattitaidon niin salliessa.

Internetissä käytetään suurta joukkoa erilaisia kuvailuformaatteja. Edellä kuvattuun tarpeeseen niistä soveltuu parhaiten Dublin Core Metadata Element Set (DC, katso http://purl.oclc.org/metadata/dublin_core/). DC on ensimmäinen yleiseen Internet-käyttöön kehitetty kuvailuformaatti. Se on alun perin rakennettu mahdollisimman yleiseksi ja joustavaksi. Käytännön kokemuksia kuvailutyön laadusta (varsinkin ei-ammattilaisten tekemänä) on toistaiseksi verraten vähän, mutta vaikuttaa siltä että myös julkaisujen tekijät oppivat käyttämään sitä verraten helposti. Kirjastojen luetteloijat toki osaavat perusammattitaitonsa ansiosta tallentaa hyvälaatuisia Dublin Core -kuvailuja vähäisen opettelun jälkeen.

DC sisältää vain 15 kenttää. Formaatin suomennos on saatavilla osoitteesta http://linnea.helsinki.fi/meta/dcref-fin.html. 15 kenttää ei vaikuta paljolta, mutta on itse asiassa aivan riittävästi johtuen DC:n edistyksellisestä (MARC-formaattiin verrattuna) rakenteesta. Jokaiselle DC-kentälle voidaan määritellä tarkenteita, jotka antavat kentälle tarkemman semanttisen sisällön. Esimerkiksi Identifikaatiotunnus-kentässä voidaan tarkenteen avulla ilmaista, mistä koodijärjestelmästä (ISBN, ISSN, etc.) dokumentin ID-tunnus on peräisin. Vastaavasti Aihe-kentässä voidaan määritellä käytetyn termin alkuperä (UDK-luokitus, Yleinen Suomalainen Asiasanasto, ja niin edelleen). DC:stä voidaan siis rakentaa MARC-formaattia monipuolisempi järjestelmä, jos tarpeen. Järjestelmän hallitsemiseksi on kuitenkin luotava DC-rekisteri, josta ilmenee mitä tarkenteita on käytössä. Tarkenteiden tunnuksien jakelussa maakoodit tulisi varata, jotta jakelua voitaisiin hajauttaa tarpeen mukaan kansalliselle tasolle.

Internet-dokumenttien kuvailu tarjoaa muutamia mielenkiintoisia haasteita verrattuna "tavallisten julkaisujen kuvailuun. Julkaisun päivämäärä on yksi esimerkki: pitäisikö esimerkiksi Kalevalan elektronisen version Päivämäärä-kenttään tallentaa alkuperäisen Kalevalan vai elektronisen version julkaisuvuosi? Oikea vastaus riippuu tietenkin tarpeesta, mutta yleensä molemmat päiväykset pitäisi vastaavassa tilanteessa antaa. MARC-formaatissa päivämäärätietojen tallentamiseen tarjottavat vaihtoehdot riittävät painetuille julkaisuille, mutta eivät elektronisille. Kaikeksi onneksi DC:n Päivämäärä-kenttään tulee joukko tarkenteita joiden avulla elektronisten julkaisujen tarpeet voidaan ottaa huomioon. Sovitut tarkenteet ovat:

• DC.Date.Created
• DC.Date.Issued
• DC.Date.Accepted
• DC.Date.DataGathered
• DC.Date.Available
• DC.Date.Acquired
• DC.Date.Valid

Date.Created on ajankohta jolloin julkaisu alunperin ilmestyi ja Date.Issued taas viittaa aikaan, jolloin julkaisun käsillä oleva elektroninen versio näki päivänvalon. Date.Accepted -tarkenteella voidaan ilmaista esimerkiksi päivä jolloin opinnäyte hyväksyttiin.

Päivämäärätiedon ohella toinen mielenkiintoinen tapaus on Identifikaatiotunnus-kenttä sen vuoksi, että monille elektronisille julkaisuille ei ole voinut antaa ISBN- tai ISSN-tunnusta. Tarve identifioida verkkojulkaisut esimerkiksi pitkäaikaissäilytystä varten on kuitenkin ilmeinen. Helsingin yliopiston kirjasto on päättänyt sen vuoksi laajentaa niin sanotun kansallisbibliografian ID-tunnuksen eli NBN-tunnuksen käyttöä kansallisbibiliografiaan luetteloitavista julkaisuista kotimaisiin verkkojulkaisuihin yleensä. NBN-tunnukset tallennetaan julkaisuihin URN-tunnuksina; syntaksista (josta esimerkki alla) on sovittu yhdessä IETF:n URN-työryhmän kanssa. URN-tunnusten jakeluohjelma on rakennettu osana Nordic metadata -hanketta (katso alla).

Siltä varalta että ennakolta sovitut DC-tarkenteet eivät riitä, on sovittu siitä, miten DC:tä voidaan tarpeen mukaan laajentaa. Menetelmä on sama kuin Internetissä laajemminkin, eli oman kentän nimi alkaa merkeillä "X-". Vastaavalla tavalla voi luoda DC-kentille omia tarkenteita. Jos haluamme Suomessa tallentaa dokumentin hinnan Dublin Core -tietueeseen, voimme käyttää esimerkiksi kenttää "X-hinta" ja rekisteröidä sen kansainvälisesti, jotta muut eivät ottaisi käyttöön samaa kenttää. "X-hinta" voidaan "opettaa" Suomessa käytettäville DC-indeksointiohjelmille, mutta ulkomaiset sovellukset osaavat ignoroida kentän sen X- -alkuisen nimen ansiosta.

Dublin Core -tallennus

Mikään Dublin Core -kenttä ei ole pakollinen, koska Internet-dokumenteilla ei ole ainuttakaan yhteistä nimittäjää. DC:lle ei ole ainakaan toistaiseksi olemassa kuvailuohjetta, joka kertoisi esimerkiksi sen, missä muodossa henkilön nimi tallennetaan Tekijä-kenttään. Vaihtoehtoja on kaksi: "sukunimi, etunimi" ja "etunimi sukunimi". Näistä esimerkiksi Nordic metadata -projekti valitsi edellisen, koska se on muun muassa indeksien selauksen ja datan konvertoinnin kannalta jälkimmäistä parempi.

Dublin Core -kuvailutiedot tallennetaan yleensä kuvailtavan dokumentin sisään. Vain siellä ne ovat WWW-indeksointiohjelmien hyödynnettävissä. Tämä merkitsee sitä, että jokaiselle teksti-, kuva-, ääni- yms. formaatille on laadittava DC-syntaksi, ja indeksointisovellusten pitäisi osata hyödyntää sitä. Tätä kirjoitettaessa syntaksi on valmis HTML-dokumenteille, seuraavaksi on tarkoitus määritellä DC-tietojen tallennustapa XML-formaatille ja sen jälkeen jollekin yleisimmistä kuvaformaateista - todennäköisin vaihtoehto on TIFF.

HTML-dokumentissa kuvailutiedot tallennetaan nimiöön, sen META- ja LINK-kenttiin. Esimerkkinä Identifikaatiotunnus -kenttä, johon on tallennettu NBN-tunnukseen perustuva URN:

<META NAME="DC.Identifier" SCHEME="URN" CONTENT="URN:NBN:fi­fe19981001">

Tallennustapa vaikuttaa monimutkaiselta ja onkin sitä, koska tiedot on koodattava siten, että WWW-indeksointiohjelmat pystyvät erottamaan eri formaatit ja niiden kentät toisistaan. Esimerkin META NAME -tieto (DC.Identifier) kertoo, että formaatti on Dublin Core (DC.), kenttä Identifier (Identifikaatiotunnus) ja sen Scheme-tarkenne URN, eli tieto antaa URN-tunnuksen. Tätä merkintätapaa voi käyttää HTML 4.0:ssa, jossa META-kentälle on annettu SCHEME-tarkenne varta vasten Dublin Core -käyttöä varten.

WWW-selaimella ei normaalisti näe sitä, onko dokumenttiin tallennettu Dublin Core -kuvailutiedot vai ei. Asian voi tarkistaa katsomalla dokumentin HTML-muodossa (Netscape 4.0:ssa komennolla Ctrl-U tai valitsemalla View + Page Source). Esimerkki DC-kuvailusta löytyy vaikkapa Nordic Metadata -hankkeen kotisivulta (http://linnea.helsinki.fi/meta).

Koodaustavan monimutkaisuuden vuoksi kenenkään ei pitäisi syöttää DC-kuvailutietoja käsin, vaan käyttäen tallennusalustaa joka generoi automaattisesti tarvittavat "kenttäkoodit". Esimerkiksi yllä olevaan esimerkkikenttään tarvitsee tallentaa vain URN-tunnus, jonka senkin saa URN-generaattorilta (katso alla).

Nordic metadata ja Dublin Core -työkalupakki

Nordic Metadata -projekti (katso http://linnea.helsinki.fi/meta) on NORDINFOn rahoittama projekti, joka käynnistyi lokakuussa 1996 ja päättyy toukokuussa 1998. Hankkeen keskeisin tavoite on luoda välineet, joiden avulla Dublin Core -kuvailujen tallennus, poiminta verkon dokumenteista sekä indeksointi ja käyttö tiedonhaussa sujuvat juoheasti. Kaikki hankkeessa luotavat työkalut ovat maksutta kaikkien kiinnostuneiden käytettävissä.

Hankkeen vetäjä on allekirjoittanut. Helsingin yliopiston kirjaston ohella projektiin osallistuvat Lundin yliopiston kirjaston NetLab-yksikkö sekä SICS (Swedish Institute of Computer Science) Ruotsista, norjalainen Bibsys, Dansk BiblioteksCenter ja sekä Islannin kansalliskirjasto. Tätä kirjoitettaessa projekti on loppuraporttia vaille valmis. Projektisuunnitelmassa asetetut tavoitteet on saavutettu; itse asiassa projekti on tehnyt enemmän kuin lupasi. Nordic metadatan jälkeen on syntynyt lukuisia muita saman alan projekteja, joissa samat organisaatiot ovat mukana. Siksi samoja perusvälineitä on voitu kehittää rinnan monissa projekteissa.

Nordic metadatassa on rakennettu seuraavat työkalut:

1. Dublin Core -tallennusalusta ja "luettelointisäännöt"

2. Dublin Core -tietojen keruu- ja indeksointiohjelma

3. Dublin Core ->MARC -konvertteri

4. URN-tunnusten generointiohjelma

Kaikki välineet ovat käytettävissä jo nyt. Valitettavasti ohjelmien palvelut eivät ole niin hyviä kuin ne voisivat olla. Pääsyy tähän on se, että Dublin Core on vielä osittain kesken. Vaikka formaatin ydin on valmis ja julkaistaan lähiaikoina RFC:nä, yksityiskohdissa on vielä hiomista, ja muutokset heijastuvat myös ainakin tallennusalustaan ja formaattikonvertteriin.

Tallennusalusta

(http://renki.lib.helsinki.fi/cgi-bin/dc.pl)

Tallennusalustan avulla DC-tallennus saadaan mahdollisimman helpoksi. Projektissa on rakennettu kaksi alustaversiota: laaja, joka sisältää kaikki DC-kentät ja vakiintuneet tarkenteet, sekä suppea, jolla voi tallentaa vain keskeisimmät tiedot. Alustoihin on linkattu joukko opastetekstejä, joissa käyttäjille annetaan ohjeita siitä, millaista tietoa ja missä muodossa pitäisi tallentaa - eräänlainen kuvailusääntöjen korvike siis.

Tallennusalusta on HTML-dokumentti, jossa on "ikkunat" eri DC-kentille. Alustan "takana" majailee Perl-skripti, joka rakentaa käyttäjän lähettämistä tiedoista HTML-dokumenttiin sopivan DC-tietueen. Kun sovellus on palauttanut tietueen käyttäjälle, hän voi leikata ja liimata tiedot HTML-dokumenttinsa nimiöön.

Koska tallennuksen päätavoite on tehostaa Internet-tiedonhakua, pyrimme parhaamme mukaan helpottamaan sisällönkuvaustyötä. Alustan Aihe-kentän opasteeseen on linkattu kaikki tiedossamme olevat, Internetistä löytyvät sisällönkuvailujärjestelmät. Kotimaisista järjestelmistä mukana on tätä kirjoitettaessa Maatalousalan asiasanasto. Toivomme että Yleinen suomalainen asiasanasto ja sen johdannaisia saataisiin verkkoon, koska näin voitaisiin tehostaa paitsi sisällönkuvailua myös tiedon hakua.

Käyttäjiltä on kerätty palautetta tallennusalustan käytöstä ja Dublin Coren hyödyntämisestä yleensä, ja saatujen tietojen pohjalta työkaluja on kehitetty edelleen, esimerkiksi tallennusalustasta on tehty projektin mittaan neljä versiota. Käyttäjätuen parantamiseksi alustasta on lisäksi tehty kansallisia versioita, Tanskassa jopa kaksi erilaista.

Dublin Core -tietojen keruu ja indeksointi

(katso http://nwi.ub2.lu.se/?lang=en)

Metatiedon hyödyntämiseksi haussa Lundin yliopiston NetLab-yksikkö on rakentanut Nordic Web Index -ohjelmaan (http://nwi.funet.fi/) lisäpiirteen, jonka avulla NWI voi koota HTML-dokumenteista paitsi Dublin Core -kuvailut, muutakin metatietoa nimiön META-kentästä. Nämä tiedot tallennetaan omaksi kannakseen. Tätä kirjoitettaessa tarjolla ovat Ruotsin ja Tanskan metadatatietokannat SWEMETA ja DANMETA. Suomen metadatatietokanta avattaneen kuluvan vuoden kesällä. Se tulee sisältämään muun muassa lähes 1000 vapaaehtoistyönä tallennettua Dublin Core -viitettä.

Keskeinen ongelma Internet-metadatatietokannan luonnissa ei ole niinkään kuvailutietojen keruu sinänsä, vaan "haitallisen metadatan" siivoaminen pois. Esimerkkeinä tämäntyyppisistä kuvailuista mainittakoon HTML-konverttereiden tuottamat tyhjänpäiväiset toteamukset sekä indeksointirobottien huijaamistarkoituksessa syötetyt kuvailutermit, joilla ei yleensä ole mitään tekemistä julkaisun aiheen kanssa. Kaikeksi onneksi siivousta voidaan automatisoida. Keruu kannattaa, sillä Internet-dokumenteistä löytyy jo varsin paljon käyttökelpoista kuvailutietoa: Lundin yliopiston kirjaston arvion mukaan noin 8 % ruotsalaisista WWW-dokumenteista (n =150.000) on järkevä kuvailu.

Dublin Core -> MARC -konvertteri

(katso http://www.bibsys.no/meta/d2m/)

Nordic metadata -projekti on rakentanut DC->MARC -konvertterin , joka muuntaa HTML-dokumentin nimiössä olevan Dublin Core -kuvailun kirjastojen käyttämään MARC-muotoon. Ohjelman avulla kirjastot voivat käyttää hyväksi julkaisuissa olevia kuvailuja omassa luettelointityössään. Konversio-ohjelman perustaksi on laaditttu muunnostaulukot DC:stä Pohjoismaissa käytettäviin kansallisiin MARC-formaatteihin. Konvertteri on ensimmäinen laatuaan maailmassa.

URN-tunnusten generointiohjelma

(http://linnea.helsinki.fi/cgi-bin/urn.pl)

URN-generaattorin avulla kuka tahansa voi hankkia verkkojulkaisuilleen pysyvän ja ainutkertaisen ID-tunnuksen. Tunnuksen pysyvyyden - joka on paitsi tekninen, myös organisatorinen kysymys - takaa Helsingin yliopiston kirjasto, joka kansalliskirjastona on erittäin pysyvä organisaatio.

URN-tunnusten jakelussa keskeinen ongelma ei ole tunnuksen jakaminen sinänsä - joka on teknisesti hyvin yksinkertainen operaatio - vaan sen selittäminen, miten tunnuksia pitäisi käyttää. Annetaanko saman julkaisun eri formaateissa julkaistuille versioille sama vai eri URN-tunnus? Jos julkaisun sisältöä muutetaan, milloin URN-tunnus pitää vaihtaa? Miten URN tulisi tallentaa julkaisuun, jotta se olisi haettavissa? Näihin kysymyksiin pyrkii vastaamaan Helsingin yliopiston kirjaston laatima URN-tallennusohje (http://renki.lib.helsinki.fi/meta/URN-opas.html), jota tullaan päivittämään sitä mukaa kun käyttäjiltä saadaan vinkkejä parannuksista.

Lopuksi

Internetin suosion kasvun myötä metadatasta on nopeasti tullut suosittu puheenaihe verkkoa työkseen käyttävien keskuudessa. Yleisesti toivotaan, että metadatan määrän kasvu ja laadun paraneminen helpottaa relevanteimman verkkoaineiston löytämistä jo lähitulevaisuudessa.

Nordic Metadata -hankkeen ansiosta Pohjoismaat ovat metadatan saralla kehityksen eturintamassa. Projekti on herättänyt runsaasti mielenkiintoa Pohjoismaissa ja myös muualla maailmassa. Osoitus tästä on että saimme järjestää viidennen Dublin Core metadata workshopin Helsingissä lokakuussa 1997 (katso http://renki.lib.helsinki.fi/meta/DC5.html)

Nordic metadatan kenties merkittävin aikaansaannos on se, että moni projekti on tehnyt päätöksen käyttää Dublin Corea dokumenttiensa kuvailuun. Kentien näyttävin yksittäinen esimerkki on Tanskan tutkimusministeriön päätös siitä, että valtionhallinnon virallisjulkaisut julkaistaan verkossa elektronisessa muodossa DC-kuvailuilla varustettuina. Suomessa ollaan päätymässä vastaavaan ratkaisuun. Teknisesti Suomen malli perustuu Word-makroon, jolla kuvailut tallennetaan ensin Word-asiakirjaan. Se muunnetaan HTML-tiedostoksi, jonka metadata on DC-muodossa.

Nordic metadata -projektin työryhmä on yksimielisesti päättänyt jatkaa työtään nykyisessä kokoonpanossa. Jos rahoittajamme NORDINFO suo, tämä realisoituu Nordic metadata II -hankkeessa. Tavoitteina on hankkeessa kehitettyjen välineiden ylläpidon ohella kokonaan uusien palvelujen kehittäminen, joista mainittakoon W3C:n Resource Description Framework -malliin (katso http://www.w3.org/RDF/) perustuvien työkalujen kehittäminen.