Kansallinen kirjastoverkko 2000-luvulle

Juha Hakala

Tämän artikkelin tarkoituksena on kuvata kansallisen kirjastoverkon tekniset perusteet niin epäteknisesti kuin asioiden ja kirjoittajan luonteen huomioon ottaen on mahdollista. Tekijä pyytää anteeksi tekstiin mahdollisesti jääneitä vaikealukuisia kohtia: taito ei ole riittänyt niiden eliminoimiseen.

Taustaa

Uuden vuosituhannen alku on kirjastojen verkottumisen kannalta hyvin mielenkiintoinen. Yliopistokirjastojen Linnea2-hanke etenee suunnitelmien mukaan kohti toteutusvaihetta, ja kotimaiset järjestelmätoimittajat ovat omalla tahollaan tehneet työtä sovellustensa verkko-ominaisuuksien kehittämiseksi. Vuoden parin päästä tekniset edellytykset kirjastojen yhteistyölle yli organisaatiorajojen esimerkiksi luetteloinnissa ovat oleellisesti paremmat kuin tätä kirjoitettaessa.

Linnea2-projektissa on pidetty mielessä paitsi kirjastojen paikalliset tarpeet, myös Linnea-verkon ja sen rinnalla myös kansallisen kirjastoverkon tarpeet. Endeavor Information Systems'in Voyager on järjestelmä, joka soveltuu hyvin sekä paikallisjärjestelmäksi että verkkoa hyödyntäville konsortiolle. Voyagerista saamme paitsi hyvän työvälineen Linnea-kirjastoille, myös sovelluksen jonka kanssa muiden kirjastojen käyttämien ohjelmistojen on helppo kommunikoida, tietenkin sillä edellytyksellä että ne noudattavat samoja kansainvälisiä standardeja kuin Voyager.

Helsingin yliopiston eräänä tavoitteena on tehdä nämä standardit ja niiden kansalliset soveltamisohjeet tutuiksi sekä kirjastojärjestelmien toimittajille että kirjastoille itselleen. Lokakuussa 1998 perustimme suomalaisten Z39.50-käyttäjien ryhmän eli FINZIGin, joka on tarkoitettu ennen kaikkea kirjastojärjestelmien toimittajille. Tiedotusta Z39.50-käyttäjäkirjastoille tehdään muin keinoin.

Aloitan tulevaisuuden hahmottamisen perusasioista: FINMARC-formaatista ja sen merkkivalikoimasta. Tämän jälkeen kerron siitä miten järjestelmät tulevaisuudessa kommunikoivat toistensa kanssa tiedonhakustandardi Z39.50:n välityksellä. Lopuksi otan kantaa siihen, mitä merkitystä tällä kaikella on Helsingin yliopiston kirjaston ylläpitämien yhteisluettelotietokantojen ja muiden kansallisten resurssien kannalta.

FINMARC

VTLS-järjestelmän hankkiminen tarjosi 80-luvun lopulla hyvän mahdollisuuden pohtia sitä, miten FINMARC-formaattia voitaisiin kehittää. Toki formaattia oli paranneltu ennen VTLS-hankintaa, ja formaatin ylläpito jatkui koko 90-luvun. Mutta VTLS-ohjelmaan siirryttäessä oli mahdollista tehdä formaattimuutoksia, joiden toteuttaminen vaati datan konvertointia. Esimerkiksi raporttisarjakoodi siirrettiin kentästä 035 kenttään 027. Nämä muutokset oli helppo tehdä samalla kun kirjastojen perusrekisterit siirrettiin LSP-sovelluksesta VTLS:ään.

Linnea2-hankkeessa formaattikysymyksestä keskusteltiin avoimesti. Etukäteen ei ollut päätetty edes sitä, että uusi formaatti olisi FINMARC; myös USMARCia tukevia näkemyksiä esitettiin. Lopputulos oli kuitenkin se, että sovellamme jatkossakin kansallista formaattia. Tähän on erinäisiä hyviä syitä:

USMARC-formaattiin - tai pikemminkin MARC21:een - siirtyminen olisi edellyttänyt Linnea-kirjastojen ja myöhemmin muidenkin kirjastojen luetteloijien laajaa uudelleenkouluttamista. MARC21 ei sellaisenaan olisi riittänyt, vaan siihen olisi pitänyt lisätä koko joukko suomalaisia koodeja ja kenttiä. Kansallista formaattia olisi siis edelleen pitänyt ylläpitää. Lisäksi MARC21 olisi pitänyt kääntää suomeksi ja samalla tarkistaa, ovatko Suomalaiset luettelointisäännöt ja MARC21 sopusoinnussa keskenään. MARC21:n käyttö sisäisenä formaattina ei olisi helpottanut ulkomaisten tietueiden käyttöä kopioluetteloinnissa. Suomessa olisi syntynyt pitkä siirtymävaihe, jonka aikana kirjastot olisivat luetteloineet kahdella formaatilla; tämä olisi vaikeuttanut luetteloijien - mutta ei kuitenkaan tietueiden - liikkumista Linnea-kirjastoista muihin kirjastoihin ja päinvastoin.

Perustelen kohtia 3 ja 4 tarkemmin.

Yleisin MARC21:n käyttöä tukeva argumentti oli se, että kopioluettelointi ulkomailta helpottuisi oleellisesti jos meillä olisi sama formaatti kuin USA:ssa. Kopioluettelointia voidaan kuitenkin harrastaa vaikka formaatit eroaisivatkin; modernit kirjastojärjestelmät pystyvät konvertoimaan tietueet lennossa formaatista toiseen. Endeavorin kanssa solmittu sopimus edellyttää, että Voyager pystyy muuntamaan muista tietokannoista kopioitavat MARC21-tietueet FINMARC-tietueiksi ennen kuin tietue esitetään luetteloijan työasemassa. Helsingin yliopiston kirjaston on pystyttävä itse ylläpitämään MARC21-FINMARC -konversiotaulukkoa ja jatkossa muitakin muunnostaulukoita ilman ohjelmistotoimittajan apua. Endeavorin osaksi jää kehittää "musta laatikko", joka taulukon ohjaamana hoitaa muunnoksen.

Voidaan kysyä, miten muiden järjestelmien käyttäjät selviävät kopioluetteloinnin formaattimuunnoksista. Oulun yliopiston kirjasto rakentaa osana Helsingin yliopiston kirjaston koordinoimaa KAKS-projektia USEMARCON-formaattikonvertterista versiota, joka voidaan liittää kirjastojärjestelmien Z39.50-sovellusten yhteyteen. Kotimaiset - ja halutessaan muutkin - järjestelmätoimittajat saavat tämän sovelluksen vapaasti käyttöönsä. Nykyistä PC-ympäristössä toimivaa USEMARCONia käytetään yli 200 kirjastossa ympäri maailmaa; esimerkiksi HYK on rakentanut sillä muunnokset FINMARCista UNIMARCiin ja USMARCiin sekä KATI-tietokannan artikkeliformaatista FINMARCiin.

Tavallinen MARC21:een siirtymistä vastustava näkemys oli, että kansallisten rekistereiden kuten Fennican ja Lindan käyttö Linnea-verkon ulkopuolelta estyisi, jos FINMARC hylättäisiin. Tämä ei pidä paikkaansa: tietuepoimintojen yhteydessä ajettava tai Z39.50-palvelimeen liitetty konversio-ohjelma voi muuntaa tietueet "vanhaan" FINMARCiin ennen lähetystä vastaanottajalle.

Uusi FINMARC - kutsukaamme sitä selvyyden vuoksi FINMARC2:ksi - tulee sisältämään kenttiä, joista nykyinen formaattimme ei tiedä mitään. "Varmoja tapauksia" ovat esimerkiksi kentät 005 ja 880. Edelliseen tallennetaan aika, jolloin tietuetta on viimeksi muokattu, jälkimmäiseen kaikki se tieto, joka ei ole ISO Latin-1 -muodossa. Kaikki kyrillisin merkein tallennettu data viedään Voyager-järjestelmässä 880-kenttään, ja muihin kenttiin jää datan ISO Latin-1 -muoto. Lienee hyvä ajatus poistaa 880-kentät ennen tietueen lähetystä "perinteiseen" FINMARCiin perustuvaan järjestelmään, vaikka vastaanottaja voisikin suodattaa 880:n ja mahdolliset muut uudet kentät pois.

FINMARC2:n kehittäminen on tätä kirjoittaessa käynnistymässä Helsingin yliopiston kirjastossa, ja se valmistuu kevään 2000 kuluessa. Emme vielä ole varmoja siitä, mitä muutoksia tarvitaan, mutta se on selvää, että muutoksia tehdään vain toiminnallisuuden parantamiseksi, ei siksi että Voyager niitä vaatisi. Muiden modernien kirjastojärjestelmien tapaan Voyager on varsin helposti sovitettavissa erilaisille formaateille, Endeavor rakentaa ohjelmistoon piirteet, joiden avulla välimerkit ovat lisättävissä dataan väli- ja korttinäyttöjä varten; niitä ei siis tarvitse tallentaa.

On mahdollista, että merkittävin konversiotarvetta aiheuttava ero FINMARCien välillä on merkkivalikoima. Nykyinen FINMARC perustuu ISO 6937/2-merkkivalikoimaan, joka ei riitä edes yliopistokirjastojen ja muiden kirjastojen tämänhetkisille tarpeille: kyrilliikan tallentamiselle on kehitetty VTLS:n sanelema väliaikaisratkaisu, joka rajoittaa tietueiden siirtomahdollisuuksia.

Amerikkalaisissa järjestelmissä on pitkään käytetty ALA-merkkivalikoimaa. MARC21 merkitsee pesäeroa tähän perinteeseen, sillä siinä merkkivalikoima on ennen pitkää UNICODE. En näe mitään syytä siihen, miksi FINMARC2:ssa pitäisi valita jokin toinen ratkaisu kuin MARC21:ssä merkkivalikoiman osalta; suomalaisetkin kirjastot tarvitsevat UNICODE-merkistön kyetäkseen luetteloimaan kaiken sen aineiston mitä niiden kokoelmiin kuuluu. Siinä missä nykyisen FINMARCin ISO 6937/2 määrittelee reilut parisataa merkkiä mahtuu UNICODE:en yli 65.000 merkkiä; monet asiantuntijat ovatkin sitä mieltä että UNICODE:ssa on tilaa maailman kaikkien kielten kaikille merkeille. Vaikka tämä ei tarkkaan ottaen pitäisikään paikkaansa, voinee sanoa että UNICODE riittää kirjastoille varsin hyvin.

Siirtyminen FINMARC2:een tapahtuu Suomessa eri kirjastojärjestelmissä eri aikaan. Uuden Linnea-verkon kansallisten yhteistietokantojen kuten FENNICAn FINMARC2-pohjainen UNICODE-data on kyettävä muuntamaan "vanhaan" FINMARCiin konvertoitaessa "lennosta" ISO 6937/2-merkistöön. Tämä on tietenkin varsin helppoa, koska konversion edellyttämän 880-kentän poiston jälkeen tietueessa ei juuri ole jäljellä sellaisia merkkejä joita ei saataisi varsin helposti ISO 6937/2:een ahdetuksi. Ei siis ihme, että tämä merkkikonversiovaatimus oli helppoa saada mukaan Endeavorin kanssa solmittuun sopimukseen.

Voyager-järjestelmän myötä saamme siis uuden, aiempaa ilmaisuvoimaisemman FINMARC-formaatin ja merkkivalikoiman, joka tyydyttänee vaativimmatkin suomalaiset käyttäjät. Tästä on ennen pitkää hyötyä kaikille suomalaisille kirjastoille. Voyagerin mukana saamme myös Z39.50-standardin tuen sekä konversiot FINMARC2:n ja MARC21:n välille, jotka mahdollistavat sen että voimme hyödyntää muualla tehtyä luettelointityötä ja myös tarjota omia tietueitamme koti- ja ulkomaisille kirjastoille. Muualla kuin Linnea-verkossa nämä edut saavutetaan sitä mukaa kun järjestelmätoimittajat rakentavat tarvittavat piirteet, eli lähinnä Z39.50-asiakasohjelmat, ohjelmiinsa.

Tarkastelen seuraavaksi lähemmin sitä, miten kirjastojärjestelmien välinen tiedonhaku ja tietueiden siirto toteutetaan. Standardointi on tässä tietenkin hyvin tärkeässä asemassa.

Z39.50-tiedonhakustandardi

-standardista on puhuttu vuosia. On kerrottu, että sen ansiosta voi tehdä hakuja vieraista kirjastojärjestelmistä oman näyttöluettelon käyttöliittymällä, jolloin koko bibliografinen universumi tulee ulottuville.

Käytäntö on kuitenkin seurannut teoriaa hitaasti. Järjestelmien rakentajat ovat keskittyneet muihin, kirjastojen kannalta vielä tärkeämpiin asioihin. Z39.50-palvelimesta on useimmille kirjastoille vähemmän iloa kuin esimerkiksi toimivasta hankintamodulista.

Z39.50-kehitystyö on kuitenkin edennyt koko ajan, joskin hitaammin kuin innokkaimmat standardin puolestapuhujat olisivat halunneet. Käytännöllisesti ottaen kaikissa merkittävissä amerikkalaisissa järjestelmissä on sekä Z39.50-asiakasohjelma että palvelin. Ne eivät kuitenkaan sisällä kaikkia Z39.50-standardin toimintoja. Endeavor on lupautunut tässä suhteessa kehittämään Voyager-ohjelmistoa voimakkaasti: Linnea2-sopimukseen on kirjattu indeksien selaustoiminnon (Scan) ja tulosjoukon lajittelun (Sort) rakentaminen, ja HYK tulee tekemään muutenkin Endeavorin kanssa tiiviisti yhteistyötä Z39.50-jatkokehityksen hahmottamiseksi. Kirjaston asiantuntija on kutsuttu amerikkalaisten Voyager-kirjastojen Z39.50-asiantuntijaryhmän jäseneksi.

Paradoksaalista on että normaalikäyttäjät eivät tätä nykyä huomaa Z39.50-asiakasohjelmia lainkaan: ne on upotettu ohjelmistojen WWW-käyttöliittymiin. Esimerkiksi Voyagerissa vain järjestelmänhoitajan tarvitsee tietää onko etätietokanta toinen Voyager-järjestelmä, jolloin voidaan käyttää Voyagerin omaakin hakutapaa, vai muuhun sovellukseen perustuva, Z39.50-lähestymistapaa edellyttävä järjestelmä. Tiedon hakijan kannalta molemmat tapaukset näyttävät Web Voyage -käyttöliittymässä samalta.

Nykyiset Z39.50-asiakasohjelmat pystyvät avaamaan yhteyden samanaikaisesti useisiin Z-palvelimiin, avaamaan joukon tietokantoja samanaikaisesti sekä yhdistämään eri tietokannoista saapuvat tulosjoukot kokonaisuudeksi. Tämä avaa tiedonhaulle uusia mahdollisuuksia. Esimerkiksi Voyagerissa voidaan määritellä kaikki kansalliset yhteisluettelot yhdeksi virtuaaliyhteisluetteloksi. Yhtä helppoa on luoda skandinaavinen virtuaalinen yhteisluettelo Pohjoismaiden kansallisista tietokannoista. Pohjoismainen yhteisluettelo ei ole enää pelkkää teoriaa: sitä toteutetaan käytännössä NORDINFOn tukemassa Scandinavian Virtual Union Catalogue -projektissa.

Myös kirjastojen näyttöluetteloita voidaan yhdistellä yhteisluetteloiden tapaan. Voyager tarjoaa mahdollisuuden siihen, että teknillisten korkeakoulujen kirjastot lyövät virtuaalisesti hynttyyt yhteen, mahdollisesti TKK:n artikkeliaineistoa myöten. Sitä mukaa kun yleisten kirjastojen ja ammattikorkeakoulukirjastojen järjestelmiin saadaan Z39.50-palvelimet, voidaan rakentaa edustavia alueellisia yhteisluetteloita. Nämä järjestelyt eivät kuitenkaan korvaa fyysisiä yhteisluetteloita: tietokantojen yhdistelyllä on rajansa.

Jos virtuaalinen yhteisluettelo koostuu hyvin monesta tietokannasta, tulosjoukon ohjelmallinen käsittely ja inhimillinen selaaminen käy kömpelöksi. Nykyisellä tekniikalla noin 10 tietokantaa on ilmeisesti yläraja. Tämäntyyppiset suositukset ovat kuitenkin aina ohjeellisia, ja riippuvat hakutavasta ja tulosjoukon koosta. Kopioluetteloija, joka käyttää julkaisun ID-tunnusta, saa yleensä jokaisesta tietokannasta vain yhden viitteen, ja voi siksi yhdistellä tietokantoja aika surutta. Sen sijaan laajaa tiedonhakua ei kannata lähettää kymmeniin tietokantoihin samanaikaisesti, ellei tulosjoukon seulomiseen ole käytettävissä todella runsaasti aikaa.

Virtuaalinen yhteisluettelo voi joutua myös oman suosionsa uhriksi. Jos esimerkiksi Linda lakkautettaisiin ja kaikki Linda-haut tehtäisiin kaikista nykyisen verkon näyttöluetteloista erikseen, jokainen kirjasto joutuisi hankkimaan itselleen yhtä tehokkaan koneen kuin yhteisjärjestelmässä nyt on. Pienissä yliopistokirjastoissa käyttäjämäärä kasvaisi yli 20-kertaiseksi. Ja tietenkin jokaisella kirjastolla pitäisi olla Z39.50-palvelin, ellei virtuaalinen yhteisluettelo perustu muihin tekniikoihin Tiedon talon ylläpitämän Monihaun tai Nordinfon 90-luvun alussa rakentaman IANI:n tapaan. IANI on esimerkkinä sikäli hyvä, että se demonstroi vakuuttavasti myös ongelmat, joita syntyy kun järjestelmien välinen kommunikointi ei perustu standardiin. Kun kohdejärjestelmän käyttöliittymä muuttuu, pitää myös monihakusovellusta muokata. Jos kohdejärjestelmiä on useita, remonttitarve voi olla jatkuva. IANIa ei pystytty ylläpitämään kovinkaan montaa kuukautta, huolimatta sen kehittämiseen uhratuista rahoista.

Monihakusovellukset kommunikoivat suoraan kunkin kirjastojärjestelmän normaalin käyttöliittymän kanssa, ne voivat välittää käyttäjälle myös tiedon julkaisun saatavuudesta tai sen varastotiedot. Lindan ja Mandan kaltaiset yhteisluettelot kertovat toistaiseksi vain sen, mistä kirjastosta aineisto löytyy, ei sitä ovatko niteet lainassa vai ei. Tekniikan kehittyminen ratkaisee tämän ongelman Linnea-verkon sisällä jo parin vuoden kuluessa; tästä lisää seuraavassa luvussa.

Fyysisten yhteisluetteloiden ylläpitoon on kehitetty järjestelmäkohtaisia ratkaisuja, joiden avulla vältytään eräpäivitysten tekemiseltä. Esimerkiksi Innopac, Pica, VTLS ja vuonna 2001 myös Voyager tarjoavat oman muunnelmansa teemasta. Kirjastoverkot ja -konsortiot ovat yleistyneet 90-luvun aikana nopeasti etenkin Yhdysvalloissa, ja on hyviä syitä otaksua että konsortioiden tarvitsemia piirteitä rakennetaan muihinkin ohjelmiin.

Z39.50-standardin yhteisluetteloprofiili (http://www.nla.gov.au/ucp/), jota on viimeksi päivitetty kesäkuussa 1999, tarjoaa oivan ratkaisun yhteisluettelon ylläpitoon monien kirjastojärjestelmien muodostamassa verkossa. Valitettavasti profiilia tukevia ohjelmistoja ei ole vielä ilmaantunut, mutta niitä ollaan kuitenkin jo rakentamassa. EU:n tukema ONE-2 -projekti on lisäämässä tarvittavia ominaisuuksia edeltäjänsä eli ONE-hankkeen kehittämään Z39.50-sovellukseen, jota esimerkiksi Ameritech Library Systems käyttää Horizon-kirjastojärjestelmässä.

Voyageriin Z39.50-yhteisluetteloprofiilin tukea ei saada ainakaan alkuvaiheessa, vaan Endeavor kehittää sisäisen ratkaisun joka toimii vain Voyager-järjestelmien välillä. Endeavor on kuitenkin kiinnostunut Z39.50-yhteisluetteloprofiilin tukemisesta myöhemmin; Linnea2-verkon lisäksi on muitakin Voyager-konsortioita joille tästä ominaisuudesta olisi hyötyä.

Saatavuus- ja varastotietojen käsittely

Z39.50-standardin avulla on perinteisesti voinut siirtää vain bibliografisia tietueita. Niteiden saatavuus ja kausijulkaisujen varastotiedot on pitänyt tarkistaa kirjoittautumalla suoraan asianomaiseen tietokantaan sen normaalin käyttöliittymän kautta. Kopioluetteloijalle tämä ei tietenkään ole ollut ongelma, mutta esimerkiksi kaukopalvelun kannalta tiedonhaku on jäänyt puolitiehen.

Z39.50 Implementor Groupissa (ZIG) on jo pitkään työstetty määritystä sille, miten Z39.50-palvelin ja asiakasohjelma voisivat vaihtaa keskenään myös saatavuus- ja varastotiedot. OPAC/Holdings -profiilin luonnos on ollut saatavilla jo pari vuotta (http://www.nlc-bnc.ca/iso/z3950/holds6.htm), mutta sen määritteleminen, miten siirrettävät tiedot koodataan, on ollut vaikeaa. Ennustin edellisessä Z39.50-profiilia kuvanneessa artikkelissani (../0298/profiili.html) että valmista syntyisi nopeasti, mutta toisin kävi: yksityiskohdista on kiistelty tarmokkaasti koko vuosi 1999. Tästä on ollut haittaa muun muassa Linnea2-hankkeelle: emme voi vaatia sellaisia piirteitä, jotka ovat vasta kehitteillä.

Tammikuussa 2000 näytti jo hetken siltä, että sopu saatavuus- ja varastotietojen koodaustavasta on saavutettu. Kongressin kirjasto julkaisi OPAC/Holdings -skeeman version 1.0 joulukuussa 1999 ( http://lcweb.loc.gov/z3950/agency/defns/holdings.html). Tammikuussa 2000 pidetyssä ZIG-kokouksessa vanha meno kuitenkin jatkui; tekstiin vaadittiin lisää muutoksia. En osaa sanoa, olivatko nämä viimeiset, vai haluaako joku vielä jotakin muutettavaksi. Esimerkiksi Linnea2-hankkeen kannalta vahinko on kuitenkin jo tapahtunut - emme voi vaatia Endeavoria tukemaan keskeneräistä määritystä.

Kyse on isosta asiasta. OPAC/Holdings-profiilin ja -skeeman avulla on mahdollista siirtää esimerkiksi nidetietoja eri kirjastojärjestelmien välillä. Käyttäjä voi siis yhdellä haulla koota saatavuustiedot useista kirjastoista. Lopputulos vaikuttaisi käyttäjän näkökulmasta samalta kuin Tiedon talon toteuttama Monihaku, mutta ulkoasu olisi yhtenäisempi ja tuplat poistettu.

Voyager-järjestelmään ollaan rakentamassa Georgian kirjastoverkon ja muiden amerikkalaisten kirjastoverkkojen tilauksesta Universal borrowing -piirrettä, jonka avulla voidaan ensin paikallistaa fyysisestä yhteisluettelosta ne kirjastot, joissa haluttu teos on, ja sitten tarkistaa nidetiedot yhdellä haulla. Toiminnallisesti tämä vastaa yhden järjestelmän sisällä sitä, mihin Z39.50:n OPAC/Holdings -profiililla alla pyritään. On siis mahdollista, että Endeavor voi rakentaa tarvittavat Z39.50-piirteet suhteellisen helposti sitten kun määritys on valmis.

Jos ei oteta huomioon OPAC/Holdings-määritysten via dolorosaa, Z39.50-ohjeistus on edennyt juoheasti. Kesällä 1999 perustettiin Kanadan kansalliskirjaston aloitteesta työryhmä, joka otti tehtäväkseen kansainvälisen Z39.50-sovellusohjeen eli profiilin rakentamisen. Lokakuussa 1999 työryhmä julkisti ohjeen ensimmäisen version, ja aktiivisen kommenttikierroksen jälkeen laitettiin tammikuun 2000 alussa verkkoon uusi ohje, joka on haettavissa osoitteesta http://www.ukoln.ac.uk/interop-focus/activities/z3950/int_profile/bath/draft/

Tammikuun mittaan tekstiin on ehdotettu vielä pieniä muutoksia, mutta helmikuussa 2000 työryhmä, johon allekirjoittaneella on ollut ilo osallistua, on sitä mieltä että työ on valmis.

Kansainvälinen Z39.50-sovellusohje, juhlalliselta nimeltään The Bath Profile: An International Z39.50 Specification for Library Applications and Resource Discovery, tulee korvaamaan Helsingin yliopiston kirjaston ylläpitämän eurooppalaisen CENL-profiilin, koska se sisältää käytännössä kaiken sen, mitä CENL-profiilissa määriteltiin, ja paljon lisää.

Säästämme myös Suomessa työtä: kotimainen Z39.50-profiili kutistuu Bath-profiilin liitteeksi, jonka kansalliskirjasto saa valmiiksi kevään 2000 kuluessa.

Ohjeistuksen yhtenäistämisestä on useita etuja. Järjestelmätoimittajilla on yksi selkeä ohje siitä miten toimia kaikkialla maailmassa. Olemme jo Linnea2-neuvottelujen aikana hyötyneet siitä, että Z39.50-standardiin perehtyneet amerikkalaiset Voyager-kirjastot ovat omaksuneet samat, Bath-profiiliin perustuvat linjaukset kuin me. Jatkossa tätä yhteistyötä on tarkoitus tiivistää siten, että kaikilla Voyager-kirjastoilla on yhtenevät Z39.50-vaatimukset.

Voyager tulee sisältämään myös kaukopalvelustandardi ISO ILL:n tuen. Voyager-järjestelmien välillä sitä ei tarvita, koska kaukopalveluun liittyvä viestinvälitys toimii Voyagerin omien tekniikoiden varassa. Pyyntöjen lähettäminen esimerkiksi BLDSC:hen ja pohjoismaisiin yhteisluetteloihin muuttunee kuitenkin ISO ILL -perustaiseksi. Suomen osalta tilanne on riippuvainen siitä, milloin kotimaiset järjestelmätoimittajat lämpenevät ISO ILL -tuen rakentamiselle. Toistaakseni tiedossani ei ole että kehittämisprojekteja olisi käynnistetty.

Lopuksi

Viime vuosien tekninen kehitys on osoittanut oikeaksi ne tekniset perusvalinnat, joita Linnea-verkossa tehtiin jo 80-luvun lopulla. Hyvä esimerkki tästä on Georgian osavaltion kirjastoverkko. 34 yliopistoa on valinnut saman kirjastojärjestelmän, ja tämän lisäksi rakennetaan kaksi fyysistä yhteisluetteloa, toinen yliopistokirjastoille ja toinen osavaltion muille merkittäville kirjastoille, jotka käyttävät muita kirjastojärjestelmiä. Lisäksi rakennetaan toimintoja, joiden avulla yliopistokirjastojen yhteisluettelosta pääsee vaivattomasti kirjastojärjestelmiin tarkistamaan julkaisujen saatavuuden.

Georgian rakenteilla oleva verkko muistuttaa yhteisluetteloineen hätkähdyttävästi Linnea-verkkoa. Eivätkä samankaltaisuudet pääty tähän: Georgia on valinnut saman kirjastojärjestelmän kuin mekin, Voyagerin.

Ilman fyysisiä yhteisluetteloita - joita ryhdytään rapakon takana vasta nyt rakentamaan - Georgian verkko ei voisi toimia tehokkaasti. Suomessa tilanne on sama: ilman erillisiä yhteisluetteloita tiedonhaku ja kopioluettelointi vaikeutuisi, kansainvälinen yhteistyö esimerkiksi Skandinaavinen virtuaalinen yhteisluettelo -projektissa olisi vähintään hankalaa ja kirjastojen pitäisi tehdä merkittäviä laajennuksia nykyisiin palvelinkoneisiinsa.

Helsingin yliopiston kirjasto lähtee omassa strategiassaan siitä, että yhteisluetteloiden ylläpito jatkuu toistaiseksi. Mikään näköpiirissä oleva tekninen kehitys ei mahdollista sitä, että Linnea-kirjastojen kannattaisi lähivuosina luopua Lindan ylläpidosta, eikä sitä, että Manda olisi jäännöksettömästi korvattavissa Monihaulla, vaikka Monihakusovelluksen kehittäminen ja tuki olisi organisoitu pysyvästi.

Juha Hakala
Kehittämisjohtaja
Helsingin yliopiston kirjasto
email: Juha.Hakala@helsinki.fi