|
Integroitu kirjastojärjestelmä ennen, nyt ja tulevaisuudessaPääkirjoitusURN:NBN:fi-fe20061269 |
|
Pääkirjoitus Artikkelit Uutisia, ajankohtaista |
Jyrki Ilva kirjoittaa tässä Tietolinjan numerossa kirjastoatk:n varhaisvaiheista Suomessa. Omat muistikuvani aiheesta yltävät vain 80-luvun puoliväliin, jolloin luetteloin Säteilyturvakeskuksen kirjastossa aineistoa, joka tallennettiin VTKK:lla Tieteellisten kirjastojen atk-yksikön LSP-ohjelmistolla ylläpitämään rekisteriin. TKAY:öön pääsin sitten minäkin, tammikuussa 1987, Liisa Stenin, Arne Hedmanin ja Riitta Lehtisen prepattavaksi. Heitä kaikkia voin kiittää sekä opista että pitkämielisyydestä, jota oppimisprosessin eri vaiheissa varmasti vaadittiin. Ensimmäisen integroidun kirjastojärjestelmän valinta yliopistokirjastoille oli tuolloin käynnissä. VTLS ja muut tarjokkaat olivat varsin erilaisia kuin ne järjestelmät, joita nyt käytämme. Toki jotakin samaakin on – jo tuolloin sovellukset kykenevät käsittelemään ja tuottamaan MARC-tietueita, ja aineiston lainaus sujui pitkälti nykyiseen malliin. Mutta 80-luvun kirjastojärjestelmille ja niiden palvelimille Internet oli vielä uutta, eikä ohjelmistoja vielä ollut rakennettu relaatiotietokantojen varaan. VTLS-järjestelmä palveli kirjastoja hyvin monia vuosia, emmekä tuolloin osanneet edes kaivata parempaa. Mutta nykymittapuulla VTLS:n verkko-ominaisuudet olivat alkeelliset. Kaukopalvelustandardi ISO ILL:n tukea ei siihen koskaan edes rakennettu. Z39.50-serveriohjelmisto saatiin ja ostettiin, mutta se kuormitti HP3000-palvelinta niin paljon, ettemme voineet käynnistää Z39.50-pohjaista avointa tietuekopiointia. Kopiointi oli mahdollista vain VTLS-tietokantojen välillä soveltaen HP:n omaa tiedonsiirtoprotokollaa. Internet-standardeista oli HP3000:lla tuettu vain pääteprotokolla Telnet, jonka ansiosta saatoimme avata Fennican vapaaseen käyttöön ensimmäisenä kansallisbibliografiana 90-luvun alkupuolella, jo ennen Webin tuloa. Toisin kuin joskus luullaan, World Wide Webin läpimurto vei useita vuosia. Tim Berners-Lee itse kävi esittelemässä WWW:tä Nordunet-kokouksessa Helsingissä tammikuussa 1993, mutta allekirjoittaneen ohella moni muukaan läsnä ollut ei tuosta esityksestä liene ymmärtänyt, miten mullistavasta asiasta oli kysymys. Asiaa vaikeutti Berners-Leen skottiaksentin ja nopean puhetavan ohella se, ettei tuolloin ollut vielä graafista käyttöliittymää, jolla demota Webiä. 5 minuuttia Mosaicin käyttöä olisi saanut minut vakuuttuneeksi tehokkaammin kuin puolen tunnin kuivakka kalvosulkeinen komentopohjaisesta Web-käyttöliittymästä. Valitettavasti Mosaic saatiin käyttöön vasta pari vuotta tuon Nordunet-kokouksen jälkeen; muuten sali olisi voinut olla esityksen jälkeen täynnä valaistunutta väkeä, ja olisimme voineet ojentaa Timille hänen tulevan Millenium-palkintonsa ja miljoona euroa saman tien. Kirjastojärjestelmätoimittajille WWW ja sitä varten rakennetut graafiset käyttöliittymät olivat vaiva ja monen taudin parannus. Omatekoiset asiakkaille tarkoitetut graafiset käyttöliittymät voitiin viskata romukoppaan, ja korvata Netscapella. Mutta henkilökunnalle tarkoitetut client-sovellukset ovat edelleen erillisiä ohjelmia. On vaikea sanoa, onko tähän muitakin kuin puhtaasti liiketaloudellisia syitä. Järjestelmäkehittäjän kannalta Webin, tai tarkemmin http-protokollan, haasteellisin piirre on se ettei mitään istuntoa synny. HTTP-palvelimen rakentamisen tämä yhteydettömyys tekee helpoksi, koska jokainen käyttökerta on ainutlaatuinen: sen jälkeen kun sivu on lähetetty, serveri unohtaa käyttäjän nopeammin kuin kaupunkiin palannut mökkiläinen hylkäämänsä kesäkissan. Niinpä istunnon illuusion ylläpitäminen vaatii työtä. Tieto siitä, mitä käyttäjä on tehnyt, on tallennettava hakusovellukseen. Näin toimivat esimerkiksi järkevästi rakennetut portaalit, sen sijaan että yrittäisivät avata istuntoja silloinkaan kun palvelin siihen kykenisi. Vastaavasti tiedonhakusovelluksen joka olettaa käyttäjien luovan istuntoja – esimerkkinä Z39.50-palvelin - on oltava valmis siihen, että jokainen kysely tehdään pitkän kaavan mukaan: luodaan palvelimelle istunto, tehdään yksi haku, ja katkaistaan istunto. Ja niin edelleen aina istunnon loppuun asti. Voidaankin sanoa että Web tekee asiat helpoiksi käyttäjille ja matalan tason infrastruktuurille, mutta sovelluksiimme pitää lisätä älyä ja palvelimiimme tehoa, jotta palvelutaso säilyisi entisellään tai paranisi. Miten nykyiset kirjastojärjestelmämme eroavat 15 vuoden takaisista? Pinnalta katsoen verkkovalmiudet ovat oleellisesti muuttuneet. Internet- ja Web-standardien tuki on itsestäänselvyys, ja sovellukset toimintavarmoja ja luotettavia. Enää meidän ei tarvitse toimia jonkin keskeisen Internet-protokollan osalta testiympäristönä, kuten HP3000:n ja Telnetin osalta kävi. Myös kirjastoille spesifejä standardeja tuetaan. Z39.50-palvelin ja asiakasohjelma löytyvät jokaisesta kirjastojärjestelmästä, ja ISO ILL –standardiakin tuetaan yleisesti. OAI-PMH ja OpenURL ovat nekin lisänneet suosiotaan nopeasti. Z39.50:n seuraajaa, SRU/SRW-protokollaakin jo tuetaan muutamissa järjestelmissä. Mutta tässä kohden alkavat ongelmat. On nimittäin kiusallisen tavallista, etteivät kirjastojärjestelmien erilaiset clientit ja serverit toimi niin kuin pitäisi. Pahimmillaan koko sovellus on käyttökelvoton. Toinen vaihtoehto on, että vaikka sovellus toimisikin, siinä voi olla toiminnallisia puutteita, joiden vuoksi se pitää korvata jollakin muulla sovelluksella tai sitä on ”paikkailtava”. Esimerkiksi asiakasohjelma, joka pystyy tekemään hakuja vain yhdestä kohdetietokannasta kerrallaan, on sopimaton kopioluettelointiin, kuten sellainenkin Z39.50-client, jolla on tapana kaatuilla yllättävissä tilanteissa. Nämä ongelmat ovat yleisiä markkinoilla olevissa kirjastojärjestelmissä. Ainakin oma vaikutelmani on se, että vaikka kirjastojärjestelmiin on rakennettu erilaisia client- ja server-sovelluksia jo toistakymmentä vuotta, ne eivät edelleenkään ole laadultaan riittävän hyviä. Miksi? Yksi selitys on, että perinteinen kirjastojärjestelmä on tapahtumankäsittelyjärjestelmä. Lainausmodulin rakentaminen edellyttää paitsi sen ymmärtämistä, miten kirjastot lainaavat, tietyntyyppistä atk-osaamista. Z39.50-palvelimen rakentaminen puolestaan edellyttää aivan erityyppisiä taitoja, ja tietenkin Z39.50-protokollan tuntemista. Kirjastojärjestelmätoimittajilla ei ilmeisesti ole ainakaan liikaa ohjelmoijia, joilla on kokemusta verkkosovellusten tekemisestä ja riittävä ymmärrys alamme sovelluksissa käytettävistä protokollista. On myös myönnettävä, että 90-luvulla rakennetut protokollamme ovat liian monimutkaisia. Hyvän Z39.50-palvelimen rakentaminen on todella vaikeaa; tiedossani on vain yksi yritys, jolle tämä on onnistunut, ja Index Data ei sitten teekään mitään muuta kuin Z39.50-sovelluksia. ISO ILL -standardin implementointi ei ole onnistunut juuri paremmin, koska urakkaan ei ole uskaltautunut kuin parikymmentä yritystä, ja on epätodennäköistä, että niitä tulisi enää kovin paljoa lisää. Z39.50:stä on jo rakennettu uusi, implementoijan kannalta helpompi versio. SRU/SRW on pitkälti yhteensopiva Webin kanssa, ja on tehnyt selkeän pesäeron Z39.50:n 80-lukulaiseen taustaan. Tiedonhaussa SRU/SRW tullee korvaamaan edeltäjänsä muutamassa vuodessa, ja toivon mukaan leviämään kirjastojärjestelmistä muihinkin sovelluksiin. Kopioluetteloinnin kaltaisissa erityistehtävissä Z39.50 tulee sinnittelemään pidempään, mutta perinteisen vaihtomuodon korvautuminen XML-vetoisella ratkaisulla on merkki siitä, ettei Z39.50:llä välttämättä ole pitkä tulevaisuus edessään tälläkään saralla. Varsinainen haaste SRU/SRW:lle ei ole vanha Z39.50, vaan OpenSearchin (http://opensearch.a9.com/) kaltaiset uudet hakuprotokollat, joilla ei ole kirjastotaustaa (OpenSearch on Amazonin aloite). Tätä kirjoitettaessa vaikuttaa siltä, että SRU/SRW ja OpenSearch saadaan jatkossa yhteismitallisiksi; tämä helpottaisi oleellisesti kirjastojärjestelmien ja muiden bibliografisten hakujärjestelmien yhteensovittamista. Kaukopalvelustandardin osalta tilanne on mutkikkaampi. Vanhaa ISO ILL –standardia ei ole enää kyetty modernisoimaan – luonnos sen uudeksi versioksi hylättiin vuonna 2004 – ja täysin uuden kaukopalvelustandardin kehittäminen on vasta alkutekijöissään. Niinpä paras vaihtoehto ILL-sovelluksen rakentajille on nykyisen standardin kevyt, niin kutsuttuun IPIG-profiiliin perustuva toteutus. Edellä kuvatun sekamelskan jälkeen ei liene yllätys, että kirjastoilla on vaikeuksia kuvata järjestelmätoimittajille, mitä ne oikein tarvitsevat. Sanotaan, että järjestelmän on tuettava Z39.50-standardia, mikä on vähän samaa kuin vaadittaisiin että autolla pitää voida ajaa. RFP-dokumenteissa tulisi kertoa mahdollisimman eksaktisti, miten verkkokäytön kannalta keskeisiä standardeja tulisi tukea. Ja kaikkien näiden vaatimusten pitäisi olla verifioitavissa, toisin sanoen jos SRU/SRW-protokollaan tai ISO ILL –standardiin perustuva yhteys ei toimi, pitäisi olla helppoa selvittää, missä vika on. Nykyisten kirjastojärjestelmien puutteita korvaamaan on syntynyt koko joukko erilaisia lisäsovelluksia. Z39.50-clientin tai ISO ILL –sovelluksen voi hankkia erikseen, ja istuttaa sen integroidun kirjastojärjestelmän kylkeen. Toistaiseksi varsin harvat kirjastot tai kirjastoverkot ovat vaivautuneet tämäntyyppiseen järjestelmien virittämiseen, mikä selittänee sitä, etteivät integroitujen kirjastojärjestelmien toimittajat ole ryhtyneet omien tuotteidensa verkko-ominaisuuksien määrätietoiseen paranteluun. Pidemmän päälle markkinoilla tulevat menestymään ne yritykset, jotka kykenevät rakentamaan järjestelmiinsä toimivat verkko-ominaisuudet, ja lisäksi piirteitä jotka tukevat konsortioiden toimintaa. Tällä hetkellä markkinoilla ei ole integroitua järjestelmää, joka olisi tässä suhteessa tyydyttävä. Yritys, joka saa sellaisen ensimmäisenä aikaiseksi, on vahvoilla. Jos integroitujen järjestelmien kehitys hyytyy nykytasolle, kirjastot joutuvat rakentelemaan perinteiset kirjastopalvelunsa pienistä osista. Kun samaan aikaan joudumme joka tapauksessa luomaan aivan uusia palveluita uusilla sovelluksilla, kokonaisuuden hallinnasta tulee mielenkiintoista puuhaa. Englantilainen kollegamme Paul Miller on loikannut julkisen sektorin palveluksesta Talis-yritykseen, mielenkiintoisella tittelillä ”Technology evangelist”. D-Lib –lehdessä huhtikuussa 2006 julkaistussa artikkelissaan Coming Together around Library 2.0 (http://www.dlib.org/dlib/april06/miller/04miller.html) hän pohtii integroidun kirjastojärjestelmän tulevaisuutta. Millerin mielestä Kirjasto 2.0 edellyttää järjestelmiä, jotka kykenevät kommunikoimaan tehokkaasti paitsi muiden kirjastojärjestelmien, myös aivan toisentyyppisten sovellusten kanssa, mikä tulee muuttamaan myös työtapojamme:
Ei liene yllätys, että Talis (http://www.talis.com/home/) on yksi niistä harvoista kirjastojärjestelmätoimittajista, jotka ovat ryhtyneet rakentamaan Millerin hahmottelemia uudentyyppisiä järjestelmiä. Suomalaisten kannalta mielenkiintoinen uutinen on, että Endeavor ja Talis ovat huhtikuussa 2006 solmineet avoimien järjestelmien käyttöä ja kehitystä koskevan strategisen yhteistyösopimuksen.
Juha Hakala
|
|
Tietolinja 01/2006 |
|