Hakala: Metahaun metadata - Tietolinja 02/2005

Tietolinja
02/2005

Metahaun metadata

Juha Hakala
Helsingin yliopiston kirjasto

URN:NBN:fi-fe20051951

NISO (National Information Standards Organization) Metasearch Initiative on kuluneen kahden vuoden aikana valmistellut joukon standardeja ja muita ohjeistoja portaaleille ja muille metahakusovelluksille, eli sovelluksille joiden avulla voi tehdä hakuja yhdestä tai useammasta etätietokannasta samanaikaisesti.

Marraskuun ensimmäisenä päivänä 2005 julkistettiin kaksi portaalien kannalta tärkeää metadataformaattiluonnosta, Collection Description Specification (Z39.91-200X) ja Information Retrieval Service Description Specification (Z39.92-200X). Yhdessä nämä dokumentit määrittelevät sen, miten tiedonhakupalveluita ja kokoelmia kuvaillaan, ja sen, miten nämä kuvaukset linkittyvät toisiinsa. Näin ne luovat pohjan sille, että voimme siirtää metadataa portaalisovelluksesta toiseen, tai vaikkapa portaalista kirjastojärjestelmän näyttöluetteloon ja päinvastoin.

Minulla oli ilo ja etuoikeus toimia portaalin metadataformaatit kehittäneen NISO:n komitean puheenjohtajana. En osaa sanoa miksi tuo vastuu uskottiin minulle, mutta oletan että taustalla on muun muassa muutaman vuoden takainen bussimatka NISO:n pitkäaikaisen johtajan Pat Harrisin ja Kongressin kirjaston Sally McCallumin kanssa Pariisin keskustasta Charles de Gaullen lentokentälle. Sattumalla oli tässä merkittävä rooli; vaikka olimme olleet samassa kokouksessa, emme olleet sopineet palaavamme lentokentälle yhdessä.

Tuon bussimatkan aikana tulin sanoneeksi että portaaleille on ehdottomasti saatava metadatastandardit, koska muuten metatietojen vaihto näiden sovellusten välillä on vaikeaa, ellei mahdotonta. Väitin lisäksi että näiden standardien kehittäminen olisi aika helppoa, koska pohjatyötä oli tehty jo vuosien ajan. Hakupalvelujen kuvauksen osalta paras asiantuntemus oli Z39.50-standardin kehittäjien joukossa, ja kokoelmien kuvaamiseen oli perehdytty ensin erinäisissä kansallisissa hankkeissa ja myöhemmin Dublin Core –yhteisössä, missä konsensus tarvittavista ydinkentistä oli vähittäin alkanut syntyä.

Nyt julkaistut standardiluonnokset perustuvat edellä mainittujen ryhmien tekemälle pohjatyölle, mikä oli alusta lähtien tavoitteeni. Pyöräähän ei kannata keksiä uudestaan, jos alkuperäiset pyörät ovat edes kohtuullisessa kunnossa. Oli hyvin mielenkiintoista seurata näiden tekstien valmistumista, ja jossakin määrin tätä prosessia ohjatakin niiden kahden vuoden aikana mitä työhön meni. Kyse ei ollut aivan pienestä urakasta, mutta en ole silti alkanut kirota kohtaloa joka oli heittänyt minut samaan bussiin Patin ja Sallyn kanssa.

Standardointia pidetään tylsänä puuhana, ja voi olla että se sitä joskus onkin, vaan ei tässä tapauksessa, koska panokset olivat suuret. Jos portaalistandardeja ei olisi kehitetty (ja jos niitä ei oteta käyttöön) olemme jatkossakin riippuvaisia portaalitoimittajien tuottamista ja ylläpitämistä palveluiden ja kokoelmien kuvauksista. Tämä on vähän sama tilanne kuin jos kirjastojärjestelmän luettelointitiedot pitäisi ostaa järjestelmätoimittajalta. Nyt meillä on mahdollisuus ottaa portaalijärjestelmien kehittäminen tältä osin omiin käsiimme, kunhan järjestelmätoimittajat saadaan implementoimaan tarvittavat piirteet ohjelmiinsa. Tämän jälkeen tarvitaan enää laajaa kansainvälistä yhteistyötä tiedonhakupalveluiden ja kokoelmien kuvailussa, mutta uskon että onnistumme yhteistyöverkon ja sen toimintaperiaatteiden kehittämisessä. Olemmehan onnistuneet tässä jo perinteisen luetteloinninkin osalta.

Tiedonhakupalvelujen kuvaaminen

Tiedonhakupalveluiden kuvailussa pyritään keräämään kirjaston näyttöluettelosta, kustantajan artikkelitietopankista tai muusta verkossa olevasta tiedonhakupalvelusta sellaiset tiedot, joiden avulla järjestelmästä voidaan tehdä tehokkaasti hakuja. Kuvailun luonne riippuu oleellisesti järjestelmän teknisestä toteutuksesta; Googlen ja Fennican kuvaukset ovat aivan erilaisia. Yleisesti ottaen mitä standardoidumpi ja monipuolisempi järjestelmä, sen tehokkaampi kuvaus siitä voidaan tehdä, ja sitä monipuolisemmin portaali voi hyödyntää kyseistä sovellusta.

Standardointi on tärkeää myös siksi, että asiakaskäyttöliittymän muuttaminen esimerkiksi ulkoasun osalta ei vaikuta standarditason (esimerkiksi Z39.50-protokollan toteutus) ohjelmisto-ohjelmisto -liittymiin. Toki jotkut muutokset, kuten uusien hakutermien lisäys, heijastuvat kaikille tasoille. Kuten portaalien ylläpitäjät ovat kantapään kautta huomanneet, hakupalvelut muuttuvat usein.

Kolmas standardoinnin etu, ja merkittävä peruste palveluiden ja kokoelmien kuvailun erottamiselle, on se että tiedonhakupalvelun kuvauksen luonnin voi automatisoida; sitä helpommin mitä standardoidummasta järjestelmästä on kyse. Ironista kyllä, sopivilla välineillä Fennicasta on paljon helpompi luoda palvelukuvaus kuin Googlesta, vaikka jälkimmäisen hakuliittymä on oleellisesti köyhempi kuin Fennica-tietokannan.

Kansallisbibliografian osalta tarvitsee vain tietää palvelun osoite, tietokannan nimi sekä se, että järjestelmä tukee (muun muassa) Z39.50-standardia. Tämän jälkeen palvelun kuvaus voidaan generoida lähes automaattisesti ohjelmalla, joka tutkii mitä standardin määrittelemiä palveluita tietokannan Z39.50-palvelin tukee, ja selvittää mitkä hakutermit ja hakutermikombinaatiot ovat sallittuja. Informaatikko joutuisi tekemään useita päiviä töitä koostaessaan vastaavia tietoja; robotti selviää hommasta muutamassa kymmenessä minuutissa riippuen kohdetietokannan vasteajoista, eikä tee yhtään virhettä.

Palveluiden kuvailussa ei tarvita kovin suurta joukkoa elementtejä. Tarvitaan vain tietoa palvelimesta (serverInfo), tietokannasta (databaseInfo), itse palvelun kuvauksesta (metaInfo), tietokannan hakuominaisuuksista (indexInfo), palvelimen teknisistä ominaisuuksista (configInfo) ja tietueiden siirrosta (recordInfo) ja kas: meillä on hakuohjelmistolle riittävä kuvaus palvelusta. Hakuprotokollasta riippuen tarvittavat tiedot voivat olla joko yksinkertaisia tai suhteellisen monimutkaisia, mutta portaalin ylläpitäjän kannalta oleellisinta ei ole tietojen rakenne vaan se, voidaanko ne generoida ja ylläpitää automaattisesti.

Palvelukuvauksen tarvittavan formaatin määrittely ei ollut helppoa, vaikka lopputulos näyttääkin yksinkertaiselta. Sulavan näköisen lopputuloksen aikaansaaminen vaati lähes 15 vuoden työn. Ensimmäinen yritys palvelukuvauksen standardointiin oli Z39.50-standardin Explain-palvelu. Se oli teoriassa aivan loistava määritys, mutta käytännössä sen implementointi oli liian vaikeaa. Merkittävä askel kohti reaalimaailmaa otettiin ONE-2 –projektissa, jossa määriteltiin Explain Lite –palvelu. Se ei enää edellyttänyt erillisen Explain-tietokannan rakentamista, vaan tarvittiin vain määrämuotoinen XML-tiedosto, joka asetettiin verkkoon tarjolle haravoitavaksi. Saman lähtökohdan omaksui Kongressin kirjaston ZING (Z39.50 International Next Generation) –hankkeen osana toteutettu ZeeRex-määritys, jonka varaan palvelujen kuvauksen NISO-standardiluonnos on rakennettu.

NISO:n standardiluonnoksen myötä meillä on nyt väline, jolla kuvailla tiedonhakupalveluita. Mutta valitettavasti tiedonhakustandardien tilanne on tätä kirjoitettaessa hyvin sekava.

Merkittävä osa kaupallisten kustantajien järjestelmistä on epästandardeja, mikä tekee portaalin hakuliittymän ylläpidon hyvin vaikeaksi. Siinä missä Z39.50-tietokannan kuvaus vie minimissään muutamia kymmeniä rivejä, screen scraping –tekniikalla toteutettu kustantajan ikioman liittymän kuvaus vie tuhansia rivejä. Ja pienikin muutos tietokannan käyttöliittymässä voi estää tietokannan käytön portaalista kokonaan. Ja ellei muutoskohta ja sitä vastaava kohta ohjelmakoodissa ole tiedossa, portaalin paikkaamiseen voi mennä runsaasti aikaa.

Jos kustantaja haluaa noudattaa standardeja, hänellä on runsaudenpula. Kirjastojen perinteinen Z39.50 ja sen seuraajiksi kehitetyt SRU ja SRW eivät ole ainoat vaihtoehdot. Niille on tullut kilpailijoita, kuten Amazonin lanseeraama OpenSearch (http://opensearch.a9.com/). Tässä tilanteessa oikean hevosen veikkaaminen on vaikeaa, ja houkutus madaltaa rimaa kasvaa. Näin on käynyt SRU/SRW:n osalta; NISO Metasearch Initiativessa on lievennetty standardin implementoinnin minimivaatimuksia. Ohjelmistokehittäjän kannalta tämä voi olla tervetullutta kehitystä, mutta tiedonhakupalveluiden kuvailun kannalta suunta ei ole oikea. Mitä yksinkertaisempi hakuliittymä, sitä niukempi on sen kuvaus, ja sitä tehottomampi on portaalin kautta tehtävä haku.

Jos hakuprotokolla ei esimerkiksi määrittele hakutermejä, järjestelmä toimii Googlen tapaan. Kirjastoalan ammattilaisten on syytä olla sitä mieltä että tämä ei ole riittävä taso; jos Googlen kaltainen roiskinta tyydyttäisi meitä, miksi ihmeessä käyttäisimme aikaa MARC-luettelointiin?

Tiedonhakupalveluiden kuvailun osalta "vihollinen" ei siis ole NISO:n formaattiluonnoksen mahdollinen puutteellisuus, vaan se että kohdejärjestelmät voivat köyhtyä nykyisestä, siirryttäessä menestyksen toivossa Z39.50:n kaltaisista tehokkaista hakuprotokollista yksinkertaisempiin ratkaisuihin. En tiedä, onko tällä Googleen johtavalla tiellä pikavoittojen mahdollisuutta, pikemmin epäilen että mitä enemmän tiedonhaku on haulikkoammuntaa a’la Google, sitä vaikeammaksi menee portaalien mahdollistama monihaku.

Kokoelmien kuvailu

Edellisen luvun alussa hahmotellun kaltaista tiedonhakupalvelujen kuvauksia rakentavaa ohjelmistoa ei vielä ole olemassa, mutta sellaisen rakentaminen ei olisi kovin vaikeaa. Kokoelmien automaattiseen kuvailuun ei valitettavasti ole edes teoriassa mahdollista rakentaa tehokkaita välineitä, ainakaan Suomessa. Yhdysvalloissa Dewey ja LCSH ovat kattavasti ja systemaattisesti käytössä, ja kaikkien kirjastojen tiedot WorldCatissa. Siksi OCLC voi rakentaa kirjastoille varsin kohtuullisia arvioita niiden kokoelmien laadusta, sikäli kuin kokoelmat sidotaan suoraan luokituksiin ja sanastoihin.

Suomessa sisällönkuvailu ei ole yhtä kattavaa ja johdonmukaista, minkä vuoksi Kokoelmakartta-hankkeessa ei saatu Lindasta johdonmukaisia tietoja kirjastojen kokoelmista. Hankkeen aloitteesta käynnistetty kokoelmaluokitus tulee muuttamaan tilannetta, mutta vain uuden aineiston osalta. Kokoelmien kuvailu tulee pääosin olemaan käsityötä, jota ei koneellisesti pystytä tukemaan.

NISO:n standardin kokoelman määritelmä on väljä: any aggregation of items. Käytännössä jokainen kirjasto, museo tai arkisto määrittelee viime kädessä itse, miten se kokoelmansa rajaa. Aiheen ohella on monia muitakin relevantteja valintakriteerejä, kuten kokoelman rakentaja.

NISO:n kokoelmien kuvailuformaatti perustuu Dublin Core Metadata Initiativen rakentamaan Collection Description Application Profile –määritykseen, joka puolestaan on alun perin englantilaiselle RSLP-hankkeelle laaditun kokoelmien kuvailuformaatin osajoukko. Kaikkien näiden formaattien taustalla ovat Dublin Coren 15 kenttää; NISO:n standardiluonnos määrittelee niiden lisäksi 13 erityisesti kokoelmien kuvailuun tarvittavaa metadataelementtiä. Näiden avulla pitäisi päästä ainakin alkuun, mutta on selvää että kenttien määrä tulee lisääntymään. Näin on käynyt muillekin formaateille; esimerkiksi MARC-formaatin kenttien määrä on kymmenkertaistunut kirjastojen tarpeiden kasvaessa.

Semantiikan eli metadataelementtien lisäksi molemmat NISO-standardit määrittelevät myös XML-pohjaisen syntaksin eli tavan esittää dataa laitteisto- ja ohjelmistoriippumattomassa muodossa. Siinä missä MARC-formaatin ISO2709-standardiksi sementoitu syntaksi on nykykatsannossa perin eksoottinen, XML-pohjaiset ratkaisut ovat nykyisin suosituin, vaan ei aina ongelmaton vaihtoehto. Pelkkä XML:n käyttö ei vielä takaa mitään, vaan datan käsittely edellyttää sen DTD:n tai skeeman ymmärtämistä. Datan tulkinnan helpottamiseksi termien määrittelyt ovat saatavilla verkossa, ja standardista on niihin linkit asianomaisista kohdista. Esimerkiksi termin Owner määritys löytyy osoitteesta http://www.loc.gov/loc.terms/relators/OWN.

Tietomalli

Eeva Murtomaa kertoo toisaalla tässä Tietolinjan numerossa FRBR-tietomallista, joka irrottaa bibliografisen datan korttiluettelon henkisestä perinnöstä. FRBR- ja FRANAR-pohjainen näyttöluettelo tulee olemaan jotakin enemmän kuin nykyiset tietokantamme; järjestelmä jonka avulla kirjastojen asiakkaat ja henkilökunta pystyvät navigoimaan bibliografisessa universumissa paljon nykyistä tehokkaammin.

Mutta mikä on portaalin metadatan tietomalli? Miten kokoelmat ja tiedonhakupalvelut linkittyvät toisiinsa?

Teknisesti vastaus on helppo: kokoelmien kuvaukseen tallennetaan linkki, joka yhdistää sen tiedonhakupalvelun kuvaukseen, ja päinvastoin. Sama kokoelma voi olla haettavissa usean palvelun kautta; esimerkiksi HYK:n Slaavilaisen kokoelman Helkassa olevat viitteet voi löytää sekä Helkan Z39.50- että SRU/SRW-liittymän kautta. Toisaalta kaikki Helkaan määriteltävät kokoelmat ovat haettavissa näiden samojen liittymien kautta. On helppo nähdä, että kokoelmien ja tiedonhakupalveluiden pitäminen erillään helpottaa tietojen päivitystä. Jos jokaiseen palvelukuvaukseen pitäisi yhdistää tiedot kaikista relevanteista tiedonhakupalveluista, syntyvä tietue olisi paitsi erittäin iso, myös vaivalloinen päivitettävä.

Portaalin tietomalli ei siis ole lainkaan samanlainen kuin bibliografisella datalla, mutta ihmekö tuo – onhan kuvailun kohteillakin eroa. Merkittävämpi ero on se, että bibliografisen datan tuotantoa ohjaavat yksityiskohtaiset luettelointisäännöt, mutta portaalin metadatalle ei ole luettelointisääntöjä, eikä niitä ole edes kehitteillä. Tällä erää ei ole yksimielisyyttä siitäkään, tarvitaanko näitä sääntöjä ylipäätään, vaan selviämmekö yksinkertaisilla käyttöoppailla. Oma käsitykseni on, että alkuun päästään vähäisellä ohjauksella, mutta mitä enemmän dataa on, ja mitä enemmän sitä vaihdetaan, sitä akuutimmaksi nousee sääntöjen tarve. NISO ei tule niitä laatimaan, koska kuvailusääntöjen laatimisen mandaatti on IFLA:lla. Jäämme odottamaan, milloin IFLA päättää, että sen on ryhdyttävä aktiiviseksi tälläkin saralla.

Priorisoinnista

Portaalisovellusten ja kirjastojärjestelmien kannalta tiedonhakupalveluiden kuvailut ovat välttämättömiä. Portaali ei toimi ilman kohdetietokantojen kuvauksia lainkaan, ja jos nämä kuvailut eivät ole riittävän laadukkaita tai jos tiedoissa on virheitä, portaalin teho ei riitä ainakaan taitavalle käyttäjälle.

Kohdetietokantojen kuvauksia siis tarvitaan, mutta miten paljon? Sopivan keruuohjelman avulla voisimme helposti koota Nelliin tiedot ainakin niistä järjestelmistä, jotka perustuvat Z39.50:een tai muuhun tiedonhakustandardiin, kuten SRU/SRW:hen. Ja lisäksi voisimme päivittää näitä tietoja riittävän usein pitääksemme ne ajan tasalla.

Mutta tarvitsevatko asiakkaamme kollektiivisesti tuhansia, mahdollisesti kymmeniä tuhansia kohdetietokantoja? Onko parempi että valikoimme heille joukon hyvänä pitämiämme järjestelmiä, ja toivoa että tästä joukosta löytyy se, mitä he tarvitsevat?

Minulla ei ole tähän kysymykseen valmista vastausta, mutta asiaa ratkottaessa kannattaa pitää mielessä, että portaali on syvän webin kalastaja, järjestelmä joka auttaa käyttäjiään pääsemään sinne minne Google ei yllä. Tässä mielessä se on uniikki verkon hakupalvelu. Toisaalta kansalliskirjastot toimivat usein varmuuden vuoksi, tallentavat vapaakappalelain nojalla aineistoa jota kukaan muu ei tallenna. Pitäisikö Nelli-portaalin toimia samoin periaattein, koska mikään muu kirjasto ei tule keräämään tiedonhakupalveluiden tietoja laajasti? Ja jos ryhdymme rajaamaan kohdetietokantoja, mistä me tiedämme mistä asiakkaat ovat kiinnostuneita?

Jos kohdetietokantoja on kovin paljon, relevanttien järjestelmien paikallistaminen alkaa muistuttaa neulan etsimistä heinäsuovasta. Viimeistään tässä vaiheessa kokoelmien kuvausten merkitys alkaa nopeasti kasvaa. Minun mielestäni kunnon portaalissa näitä kahta, siis palvelujen ja kokoelmien kuvauksia, pitäisi kehittää rinnan, jotta palvelu rakentuisi tasapainoisesti.

Suomessa portaalin metadataa on kehitetty kahtaalla: toisaalta Nelli-portaalissa tiedonhakupalvelujen kuvauksia, toisaalta palvelujen kuvauksia Kokoelmakartassa, jonka tietokanta menee alkajaisiksi ENCompass-järjestelmään. Mutta kun Ex Libris saa valmiiksi portaalin metadataformaattien tuen, kaikki tarvittava data päätynee MetaLibiin.

Palvelujen ja kokoelmien kuvailut on määritelty kansalliskirjaston ydinpalveluihin kuuluviksi tietokannoiksi, joita me ylläpidämme ja kehitämme muiden kansallisten yhteistietokantojen tavoin. Toistaiseksi nämä palvelut eivät ole vielä tuttuja kaikille, mutta aikaa myöten portaali ja sen tietokannat vakiintuvat kirjastojärjestelmän ja näyttöluetteloiden rinnalle. Ja viimeistään tässä vaiheessa nämä uudet palvelut ovat korvanneet virtuaalikirjastot, joiden avulla olemme pyrkineet organisoimaan verkon tiedonlähteitä.

Tämän artikkelin voi hyvin päättää kysymykseen: mikä on näiden uusien palveluiden suhde kansallisbibliografiaan? Jos luetteloimme Fennicaan kotimaisia verkkolehtiä, miksi emme laskisi tiedonhakupalveluiden kuuluvan samaan joukkoon? Ja mikä on kotimaisen kokoelman status Fennicaan nähden? Näitä ja varmasti monia muitakin rajauskysymyksiä joudumme pohtimaan jatkossa, osana siirtymistä perinteisestä kirjastojärjestelmästä triangelisovellusten kauteen. Kyse ei ole vain teknisestä muutoksesta, vaan se vaikuttaa myös palveluihimme ja tapaan joilla niitä ylläpidetään.

Tietolinja 02/2005