Tietolinja

Tietolinja
01/2003

OpenURL: rakenne ja käyttö

Juha Hakala
Helsingin yliopiston kirjasto

URN:NBN:fi-fe20031048


Pääkirjoitus
Artikkelit
Uutisia,
ajankohtaista


Tämä artikkeli pyrkii antaman kirjastoissa työskenteleville ja alaa opiskeleville perustiedot OpenURL-standardista ja sen SFX-sovelluksesta, joka otetaan Suomessa käyttöön vuonna 2003 osana kansallista tiedonhakuportaalia. Lisätietoa janoavat löytävät sitä helposti verkosta; artikkelin lopussa on valikoima relevantteja linkkejä.

Kirjastot ovat jo vuosien ajan tallentaneet verkkojulkaisun sijaintitiedon eli URL:n MARC-tietueisiin, tarkemmin ottaen niiden 856-kenttään. Tämä menettely on sallinut hyperlinkkien luomisen näyttö- ja yhteisluetteloista luetteloituihin dokumentteihin, mutta käyttökokemusten karttuessa ja Internetin kehittyessä myös ratkaisun ongelmat ovat tulleet ilmeisiksi:

  • Kun julkaisun sijaintipaikka muuttuu, URL pitää korjata jokaiseen kirjastoluetteloon johon sen tiedot on kopioitu. Suosittu julkaisu, kuten Tietolinja-lehti, voi löytyä monista kymmenistä suomalaisista tietokannoista. Käytännössä osoitetietoja ei ole kyetty pitämään riittävän hyvin ajan tasalla, ja näyttöluetteloista löytyy asiakkaiden harmiksi vanhentuneita hyperlinkkejä. 
  • Kun MARC-856-kenttään perustuva linkitys tuli käyttöön, lähes kaikki Internet-aineisto oli maksutonta ja vapaasti kaikkien käytettävissä. Mutta muutamassa vuodessa tieteelliset kustantajat ovat siirtäneet suuren osan lehdistään verkkoon. Nämä aineistot ovat yleensä luettavissa vain lisenssien turvin. Ennen kuin käyttäjälle luodaan hyperlinkki aineistoon, pitäisi tarkastaa onko asiakkaalla oikeus hyödyntää tätä aineistoa, ja jos on, mitä sen kopiota verkossa. Alamme kirjallisuudessa tämä ongelma tunnetaan nimellä appropriate copy problem, ja se pahenee sitä mukaa kun suojattua aineistoa tulee verkkoon lisää.

Näiden ongelmien ratkaisemiseen on kehitetty OpenURL-standardi sekä sen soveltamiseen perustuvat linkityspalvelut, joiden tietokannat sisältävät toistaiseksi tietoa etupäässä kaupallisten tieteellisten verkkolehtien lisensseistä. Rajoituksistaan huolimatta nämä järjestelmät ovat jo nyt hyvin hyödyllisiä, vaikka ne eivät kaikkia ongelmia ratkaisekaan.

Edes OpenURL:stä ei ole hyötyä jos aineisto katoaa verkosta kokonaan. Meidän pitäisi tallentaa pysyvästi verkon sisällöt, ja tähän pyrkivät kansalliskirjastojen tai The Internet Archiven rakentamat verkkoarkistot. Nekin voivat tietysti olla käytettävissä OpenURL-pohjaisen linkitysjärjestelmän kautta.

 

OpenURL-standardi

OpenURL:n protoversion kehitti Herbert van de Sompel väitöskirjatyössään, jonka hän kirjoitti työskennellessään Gentin yliopiston kirjastossa. Nyttemmin tämä OpenURL-variantti tunnetaan versiona 0.1, ja kaikki olemassa olevat sovellukset perustuvat siihen. ANSI/NISO laatii 0.1-version kanssa alaspäin yhteensopivaa, mutta sitä oleellisesti laajempaa versiota 1.0; toistaiseksi sen tarkkaa julkaisuajankohtaa ei vielä tiedetä, mutta standardin oletetaan valmistuvan vuonna 2003.

OpenURL-standardin tehtävä on määritellä, missä muodossa elektronisen julkaisun yksilöimiseen tarvittavat metatiedot siirretään asiakkaan käyttämästä järjestelmästä (OpenURL source) linkityspalveluun (OpenURL target), joka sisältää ajantasaiset tiedot julkaisun sijainnista ja käyttöoikeuksista. Teknisesti OpenURL on URL - tosin hieman mutkikas sellainen - jossa on kaksi osaa. Niistä toinen, niin kutsuttu perusosa, yksilöi linkityspalvelun osoitteen täysin perinteisellä tavalla, ja toinen, kuvailu, sisältää julkaisun identifiointiin tarvittavat metatiedot koodattuna tavalla joka on ohjelmistoille ymmärrettävä. Osien välissä on kysymysmerkki.

Esimerkki:

http://resolver.ukoln.ac.uk/openresolver/?sid=ukoln:ariadne&genre=article
  &atitle=Information%20gateways:%20collaboration%20on%20content
  &title=Online%20Information%20Review&issn=1468-4527&volume=24
  &spage=40&epage=45&artnum=1&aulast=Heery&aufirst=Rachel

Andy Powell selittää Ariadne-lehden artikkelissaan (Powell) tämän OpenURL:n sisältöä. Tässä tekstissä voin siis säästää lukijaa yksityiskohdilta.

OpenURL:ää on joskus virheellisesti pidetty Z39.50:n kaltaisena tiedonhakuprotokollana, tehdäänhän sen sisältämien tietojen nojalla haku linkityspalvelun bibliografisesta tietokannasta. Mutta tämä ei merkitse sitä että OpenURL:n käyttö varsinaiseen tiedonhakuun olisi järkevää tai edes mahdollista. OpenURL ei esimerkiksi salli Boolen operaattoreiden käyttöä, eikä standardi määrittele missä muodossa tulosjoukko palautetaan. Mutta Z39.50-standardista on kehitetty uusi versio ZING (Z39.50 International Next Generation) jossa OpenURL:n tapaan hakulause koodataan URL:n sisään. URL-pohjaisena ZING soveltuu hyvin Web-ympäristössä käytettäväksi; nähtäväksi jää, tuleeko siitä suositumpi kuin Z39.50:stä, joka on suosittu kirjastoalalla, mutta ei muualla.

Mitä metatietoja me sitten tarvitsemme jonkin julkaisun yksiselitteiseen identififiointiin? Periaatteessa vain ID-tunnuksen, mutta koska sitä ei aina ole käytettävissä, OpenURL:ään voidaan tallentaa myös lehden ISSN, kirjan ISBN, halutun lehden artikkelin tai kirjan luvun nimi ja tekijä(t) sekä alku- ja loppusivu. Mitä enemmän metatietoja OpenURL:ään on koodattu, sitä vaikeampaa on taata, että ketjun molemmissa päissä on riittävän yhtenevät tiedot julkaisusta, joten "matchaykseen" pitäisi tällöin käyttää enemmän tai vähemmän sumeaa logiikkaa. Lisäksi ylenpalttinen metatietojen mättäminen OpenURL:ään voi aiheuttaa sen, että OpenURL ylittää URL-tunnukselle sallitun maksimimitan, 256 merkkiä. (Teknisesti orientoituneille tiedoksi, että joissakin sovelluksissa URL-tunnuksen maksimi on käytännössä oleellisesti lyhyempi kuin 256 merkkiä.)

Esimerkiksi yllä oleva Rachel Heeryn artikkelin metatietoja sisältävä OpenURL olisi voitu korvata ao. artikkelin SICI-identifikaatiotunnuksen (tai SICI-tunnukseen perustuvan URN-tunnuksen) sisältävällä OpenURL:llä, ja lopputulos olisi ollut yhtä hyvä ellei parempi.

Yksi tärkeä sivujuonne OpenURL-sovellusten käyttöönotossa on siis lisääntyvä tarve kehittää identifiointitunnukset kaikelle elektroniselle aineistolle. Tällä saralla onkin edistytty nopeasti. Vuoden 2002 aikana useissa kansalliskirjastoissa (Saksa, Norja, Hollanti, Unkari) on otettu käyttöön kansallisbibliografian ID-tunnukseen perustuva URN-tunnus kirjaston digitaaliseen arkistoon tallennetun aineiston identifioinnissa; tämän ansiosta myös OpenURL:n soveltaminen helpottuu. NBN:n lisääntyvän käytön ohella toivoisi kustantantajien ryhtyvän soveltamaan entistä aktiivisemmin artikkelien ID-tunnusta eli SICIä ja monografioiden lukujen yms. osien ID-tunnusta BICIä, mutta ainakin jälkimmäisen osalta tämän toiveen toteutuminen ei toistaiseksi vaikuta realistiselta. Kustantajien järjestelmät on rakennettu ISBN:n varaan, joten ne haluavat käyttää ISBN-tunnuksia kaikkeen monografioihin liittyvään.

Yleisesti OpenURL:n ja URN:n - tai DOI:n - suhde on se, että OpenURL ottaa linkityksessä huomioon asiakkaan kontekstin, kun taas URN ja DOI takaavat linkkien pysyvyyden. Nämä järjestelmät ratkaisevat siis eri ongelman, ja soveltuvat sen vuoksi hyvin rinnan käytettäväksi. DOI:n osalta tämä on hoidettu jo OpenURL:n versiossa 0.1 johon on määritelty tapa jolla DOI tallennetaan OpenURL:ään; URN:n osalta vastaava määritys on tiettävästi tulossa OpenURL-versioon 1.0.

Teknisesti OpenURL ja URN voivat toimia rinnan esimerkiksi siten, että OpenURL:ssä siirretään URN-tunnus OpenURL-linkityspalveluun, joka puolestaan hyödyntää URN-resoluutiopalvelua paikallistaakseen halutun dokumentin verkosta. Tällä menetelmällä vältytään URL-tietojen ylläpidosta OpenURL-linkityspalvelun sisällä.

Kirjastojen asiakkaat ja henkilökunta eivät yleensä edes näe OpenURL-koodeja, koska sovellus - esimerkiksi kirjastojärjestelmä - rakentaa OpenURL:n automaattisesti, ja lähettää sen linkityspalvelulle "kulissien takana". Henkilökunnan on kuitenkin ongelmatilanteiden analysointia varten tiedettävä mitä tietoja OpenURL voi sisältää, ja miten linkityspalvelun toiminta on parametroitu.

 

OpenURL, kirjastojärjestelmät ja luettelointisäännöt

Kirjastojärjestelmät voivat toteuttaa OpenURL:n kahdessa osassa:

  • Sovellukseen rakennetaan OpenURL-tuki. Tämä tarkoittaa sitä, että kirjaston määrittelemien aineistotyyppien (kuten e-kirjat ja artikkelit) osalta kirjastojärjestelmä generoi väli- tai korttinäyttöä rakentaessaan julkaisun kuvailutiedoista OpenURL:n, jonka se lähettää yhteen tai useampaan OpenURL-linkityspalveluun (riippuen siitä, miten sovellus on määritelty toimimaan). Niistä saatavat linkkitiedot sovellus voi joko avata erilliseen ikkunaan (kuten MetaLibissä) tai liittää vaikkapa ikonina suoraan korttinäyttöön. 
  • Järjestelmätoimittaja rakentaa oman OpenURL-linkityspalvelun joko erillissovelluksena (kuten Ex Libris on tehnyt) tai kirjastojärjestelmäänsä.

OpenURL:ää tukevan järjestelmän rakentaminen ei tiettävästi ole vaikeaa, vaikka kirjastojärjestelmätoimittajista vasta Ex Libris ja Endeavor ovat olleet tässä asiassa aktiivisia. Sitten kun OpenURL:n versio 1.0 valmistuu, sitä tukevia järjestelmiä julkistettaneen nopeasti lisää. Linnea-verkossa OpenURL-tuki tarvitaan kaikkiin keskeisiin sovelluksiin (kirjastojärjestelmään, portaaliin ja digitaalisten aineistojen hallintasovellukseen), jotta myös portaalin ja DOMS-järjestelmän omien käyttöliittymien hyödyntäminen olisi tehokasta. Kaikilla Linnea-tietokantojen käyttäjillähän ei tule olemaan portaalin tai DOMS-sovelluksen käyttöoikeutta. Mutta sekä kirjastojärjestelmän että DOMS-sovelluksen on hyödynnettävä portaalin OpenURL-linkityspalvelua.

OpenURL-linkityspalvelun rakentaminen on vaikeampaa kuin OpenURL:n tukeminen vaikkapa kirjastojärjestelmän Web-käyttöliittymässä. Linkityspalvelu on palvelinsovellus jonka toteutuksessa on otettava huomioon suurten käyttäjämäärien tarpeet. Toiseksi, OpenURL-linkitys perustuu tietämyskantaan, johon tallennetaan tietoa julkaisuista, käyttäjistä ja heidän lisensseihin perustuvista käyttöoikeuksistaan. Erityisesti lisenssi-informaatio on työlästä hankkia ja usein myös erittäin nopeasti muuttuvaa. Koska virheellinen tieto lisensseistä yleensä estää aineiston käytön kokonaan (linkkiä ei synny ellei sovellus tiedä käyttäjällä olevan oikeutta aineiston hyödyntämiseen) mahdolliset ongelmat ja viiveet tietokannan ylläpidossa ovat fataaleja.

OCLC on rakentamassa kattavaa OpenURL-linkityspalvelua, johon pyritään kokoamaan mahdollisimman kattavasti tieto kaupallisten kustantajien tekemistä lisenssisopimuksista. On mielenkiintoista nähdä, miten tätä tietoa voidaan jatkossa käyttää. Vaihtoehtoja on kolme: 

  • Sovellustoimittajat voivat hankkia OCLC:n tiedot omiin järjestelmiinsä. Tällöin tiedot ovat heti kaikkien sovelluksen ostavien asiakkaiden käytettävissä.  
  • Kirjastot voivat ostaa lisenssitiedot omaan paikalliseen OpenURL-linkitystietokantaansa 
  • Kirjastot voivat käyttää OCLC:n tietokantaa suoraan linkityspalveluna, ja täydentää sen tietoja paikallisilla tiedoilla (esimerkiksi MetaLib voi käyttää useita SFX-tietokantoja ja ilmeisesti muitakin OpenURL:ää tukevia linkityspalveluita yhtä aikaa.

Toivottavasti ainakin yksi edellä olevista vaihtoehdoista toteutuu. On tärkeää, että lisenssitietojen tallennuksessa saadaan päällekkäistyö eliminoiduksi mahdollisimman tehokkaasti. Tietojen tallentaminen ja ylläpito kirjastoissa tekisi luetteloinnista entistä työläämpää.

Luetteloinnin kannalta suurin muutos on, ettei URL:ää saisi enää tallentaa MARC-tietueeseen. Mitä hyötyä on OpenURL-linkityspalvelun mahdollistamasta dynaamisesta linkityspalvelusta, jos tarjoamme edelleen staattisen ja ennen pitkää harhaanjohtavan URL-pohjaisen hyperlinkin MARC-tietueesta verkkojulkaisuun?

Teknisesti URL-tunnuksen poisjättö MARC-tietueesta on triviaali asia. Luettelointisäännöissä ja koti- sekä kansainvälisessä yhteistyössä vaikutus on sekä käytännössä että periaatetasolla merkittävä.

Miten meidän on muokattava luettelointisääntöjä ja niiden sovellusohjeita sekä MARC21-Fin -formaattia, jos MARC-tietueen 856-kentän asemesta ryhdymme tallentamaan URL-tunnuksia sekä julkaisujen lisenssitietoja erillisiin tietämyskantoihin, joiden tietuerakenteelle ja datan mahdolliselle vaihtomuodolle ei ole olemassa minkäänlaisia standardeja? Tämä on ensimmäinen, mutta mahdollisesti ei viimeinen kerta, jolloin julkaisujen kuvailutiedot tallennetaan yhden tietueen ja sovelluksen asemesta useampaan paikkaan. Siksi on mietittävä tarkkaan, miten luettelointisääntöjä ja MARC-formaattia uusitaan.

Kansainvälisen yhteistyön kannalta kenties suurin ongelma on ISSN-tietokannan ylläpito. Meillä on velvoite lähettää verkkolehtien URL ISSN-keskukselle näiden lehtien bibliografisen kuvailun mukana, koska muuten näitä lehtiä ei voi löytää kansainvälisen ISSN-tietokannan kautta. Mutta on ilmeistä, että a) moni muu maa on pian samassa tilanteessa kuin Suomi, ja b) ISSN-tietokannasta on sen vuoksi tehtävä OpenURL-yhteensopiva. Tällöin ISSN-tietokantasovellus voisi, tavatessaan verkkolehden jonka maakoodi on fi, ottaa yhteyden kansalliskirjaston ylläpitämään OpenURL-linkityspalveluun, ja selvittää julkaisun verkko-osoitteen ja käytettävyystiedot. Tämän palvelun myötä ISSN-tietokannasta, jonka päivittäminen moderniksi kirjastojärjestelmäksi on parhaillaan käynnissä, voi tulla entistä merkittävämpi kausijulkaisuja ja niiden käyttöoikeuksia koskevan tiedon lähde.

Suomessa kansalliskirjaston tulee tukea OpenURL-hankkeita vakuuttamalla kotimaiset kirjastojärjestelmätoimittajat siitä, että niiden on rakennettava OpenURL-tuki järjestelmiinsä. Lisensoidun elektronisen aineiston käyttö tulee lisääntymään myös yleisissä kirjastoissa, ja ne tarvitsevat järjestelmiä jotka tukevat tätä. Lisäksi kansalliskirjaston tulisi selvittää mahdollisuudet siihen, voidaanko kansalliskirjaston ylläpitämä OpenURL-linkityspalvelu antaa vapaasti tai ainakin hyvin edullisin ehdoin kaikkien kotimaisten kirjastojen käyttöön. Tämä helpottaisi kirjaston verkossa tarjoaman kaupallisen ja ei-kaupallisen aineiston käyttöä.

Järjestelmätoimittajien tulisi myös selvittää mahdollisuudet omien linkityspalvelusovellusten rakentamiseen, koska silloin kirjastot voisivat itse tai alueellisena yhteistyönä ylläpitää omia, kansallista palvelua täydentäviä OpenURL-linkityspalvelutietokantojaan, ja tällä tavoin helpottaa verkkoon tallentamansa aineiston käyttöä.

 

SFX

Väitöskirjatyössään Herbert van de Sompel kehitti OpenURL:n ohella myös sovelluksen, joka tarjosi dynaamisia linkityspalveluita käyttäjille. Tämän ohjelmiston, jonka ristittiin SFX:ksi, lisensoi Ex Libris -yritys, joka on integroinut sen MetaLib-portaaliin. Ex Libris on myös kehittänyt SFX:ää edelleen aktiivisesti.

SFX:n ydin on tietämyskanta, joka on rakennettu käyttäen MySQL-relaatiotietokantaohjelmistoa. Kantaan määritellään muun muassa:

  • Käyttäjät; vähintään kehysorganisaation IP-osoitealueiden tasolla;  
  • Lisenssitiedot, eli kenellä on oikeus käyttää mitä aineistoa: 
  • Aineistojen kuvailutiedot; 
  • Asiakkaille tarjottavat linkityspalvelut

Toistaiseksi näille tiedoille ei ole määritelty ISO2709-standardia vastaavaa kansainvälistä vaihtomuotoa eikä tallennusformaattia. Tämä vaikeuttaa tietojen vaihtoa kirjastojen ja konsortioiden kesken. Toinen yhteistyötä vaikeuttava tekijä on, että Ex Libris panostaa noin viisi henkilötyövuotta vuosittain MetaLibin ja SFX:n tietämyskantojen ylläpitoon. Vaikka MetaLib-sopimukseemme on kirjattu se periaate, että me omistamme tietämyskannoissa olevan metadatan, Ex Libris tuskin sallisi HYK:n toimittavan kaikki SFX:n metatiedot esimerkiksi jonkin muun Suomessa käytettävän sovelluksen OpenURL-linkityspalvelutietokannan pohjaksi. HYK:n itse tallentamien tietojen (esimerkiksi Elektra-artikkeleiden käyttöoikeudet) siirtämisestä sitä vastoin voidaan keskustella.

Palveluita voidaan määritellä useisiin SFX-tietokantoihin rinnakkain. Linnea-verkossa esimerkiksi FinELib-lisenssien tiedot, elektronisten vapaakappaleiden tarvitsemat määritykset ja muut kansalliset tiedot voidaan määritellä yhteen paikkaan. Paikalliset spesifikaatiot voidaan määritellä erikseen, muihin SFX-kantoihin. Asiakas näkee aina yhden palvelukokonaisuuden, riippumatta siitä miten monesta SFX-tietämyskannasta tiedot kootaan.

Huomattava osa FinELibin lisenssitiedoista löytyy SFX:stä valmiina, mikä helpottaa sovelluksen käyttöönottoa Suomessa. Ongelmia aiheuttaa kotimainen aineisto, kuten Elektra, jonka määrittely SFX:ään kannattaa tehdä vasta sitten, kun palvelun tekninen infrastruktuuri on päivitetty, eli artikkeleita on alettu tallentaa digitaalisen kirjaston sovellukseen.

Vaikka Ex Libris panostaa huomattavan määrän henkilöresursseja SFX-tietämyskannan ylläpitoon, he hankkivat merkittävän osan sen tiedoista ns. kolmansilta osapuolilta, kuten kustantajilta sekä yrityksiltä, jotka myyvät lisenssitietoja. Jatkossa voinemme tarpeen vaatiessa hankkia näitä tietoja itse, tai käyttää muita OpenURL-linkityspalveluita kuten OCLC:n tietokantaa. Lisenssitietojen kattavuus ja ajantasaisuus on kyettävä takaamaan, ja yhteistyö useiden partnereiden kanssa on yksi tapa jolla tähän tavoitteeseen voidaan päästä.

Asiakkaille tarjottavien OpenURL-pohjaisten linkityspalveluiden määrittely on mielenkiintoinen prosessi, jossa yliopistokirjastojen on tarkoin pohdittava, missä määrin palvelujen on oltava yhdenmukaisia. Kirjasto voi esimerkiksi päättää, että jos asiakkaan haun tuottama teos on englanninkielinen, vuoden 1995 jälkeen julkaistu kirja, hänelle tarjotaan mahdollisuus tehdä sama haku Amazon-verkkokaupasta. Jos muut kirjastot noudattavat samaa ratkaisua, kokonaisuus on asiakkaille looginen. Mutta jos verkoston kirjastojen toimintapolitiikka vaihtelisi suuresti, asiakkaiden olisi vaikea ymmärtää järjestelmän toimintaperusteita. Ja meidän voisi olla yhtä vaikea selittää heille, mistä on kyse. Siksi yhteisten linkitysperiaatteiden kehittämisen tulisi olla yksi osa SFX:n käyttöönottoprosessista.

 

SFX:n ja MetaLibin käyttöönotosta

Integroidun kirjastojärjestelmän implementointiin verrattuna SFX:n ja MetaLibin käyttöönotto on helppo prosessi. Koska kyseessä on ensimmäinen tiedonhakuportaalin asennus, meillä ei ole mitään vanhaa metatietoa - tietokantamäärityksiä tai lisenssien kuvauksia - jotka pitäisi siirtää uuteen sovellukseen. Toisella kierroksella, kun päivitämme MetaLibistä seuraavaan sovellukseen, joudumme toki jo painiskelemaan konversioiden kanssa, ja mahdollisesti ilman vaihtoformaattia, jos sellaisen kansainvälinen kehitystyö on tyyten epäonnistunut. Mutta silloinkin tiedonhakuportaali on toiminnallisesti rajallisempi kuin integroitu kirjastojärjestelmä, ja siksi sen vaihtaminen on helpompaa - paitsi jos järjestelmien kehitys vie siihen, että tiedonhakuportaalit integroidaan kirjastojärjestelmiin, niiden seuraavan sukupolven näyttöluetteloiksi. Esimerkkejä tästä trendistä ovat jo nyt VTLS:n Virtua ja Innovativen Millenium.

Edellä mainitun linkityspalveluiden määrittelyn ohella toinen SFX:n käyttöönoton haaste on sen päättäminen, miten monta SFX-tietokantaa tarvitsemme. Teknisistä syistä yksi tietokanta ei tule riittämään: jos yliopisto hyödyntää proxy-palvelinta lisensoidun aineiston käyttöön yliopiston verkon ulkopuolelta, se tarvitsee oman SFX-instanssin. Hankittavaan palvelimeen tällä ratkaisulla ei ole vaikutusta, koska käyttäjien määrä pysyy samana.

Vierailin joulukuussa 2002 Kristiina Hormian kanssa Amsterdamin yliopiston kirjastossa tutustumassa MetaLibin ja SFX:n implementointiin. Isäntien kokemusten mukaan MetaLibin ja erityisesti SFX:n käyttöönotto on suht' helppoa. Merkittävin SFX:ää koskeva ongelma oli se, että kirjastojärjestelmän ja SFX-linkityspalvelun sisältämien bibliografisten tietojen linkittäminen edellyttää aina ISSN-tunnusta. Tämä johtunee siitä, että Ex Libris on hankkinut kausijulkaisujen bibliografiset tiedot kansainväliseltä ISSN-keskukselta. Valitettavasti ISSN-tietokanta ei ole täysin kattava eikä ajantasainen, ja joillakin verkkolehdillä ei ole ISSN-tunnusta lainkaan. Suomessa politiikka on onneksi jo pitkään ollut se, että elektronisilla ja painetuilla lehdillä on oma ISSN. Valitettavasti tiedot siirtyvät Suomesta ISSN-keskuksen nykyiseen järjestelmään melkoisella viiveellä; jatkossa tätä viivettä on pyrittävä vähentämään niin Suomen kuin muiden kansallisten ISSN-keskusten osalta.

Näistä pulmista huolimatta uskon meidän selviävän MetaLibin ja SFX:n käyttöönotosta hyvin, muun muassa koska kansalliskirjastossa ja yliopistokirjastoissa on vahvaa HTML- ja Z39.50-asiantuntemusta. Amsterdamissa portaalin ylläpitäjä joutui opiskelemaan MetaLibin lisäksi Z39.50:n muutamassa viikossa; melkoinen urakka josta hän oli selvinnyt hienosti. Suomessa Z39.50-standardia on onneksi tutkittu jo pidempään. Portaalin myötä myös OpenURL tulee meille tutuksi, ja tämänkin standardin kansainväliseen kehitystyöhön aiomme osallistua aktiivisesti.

 

Linkkejä:

 

 


Tietolinja 01/2003

Juha Hakala
Helsingin yliopiston kirjasto
PL 26, 000140 helsingin yliopisto
Email: juha.hakala@helsinki.fi