Syteen tai saveen: linkkien luonti semanttisessa Webissä

Juha Hakala
Kansalliskirjasto

Tämän artikkelin pysyvä osoite on: http://urn.fi/URN:NBN:fi-fe2015092113659
Sekä Web että erityisesti semanttinen Web perustuvat verkossa olevien dokumenttien linkittämiseen. Kun RDA-kuvailusääntöjen myötä linkkien luonnista ja ylläpidosta tulee kirjastoillekin entistä tärkeämpää, on syytä luoda lyhyt katsaus linkityksen vaihtoehtoihin ja niiden seurannaisvaikutuksiin. Tässä yhteydessä on käsiteltävä myös pysyviä tunnisteita ja niiden käyttöä kuvailussa.

URL-osoitteet ja PID-tunnukset

Webissä dokumenttien väliset hyperlinkit perustuvat yleensä HTTP-protokollaan. Siitä on toukokuussa 2015 ilmestynyt useiden vuosien kehitystyön vaatinut versio 2.0[1], joka on alaspäin yhteensopiva version 1.1 kanssa. Palvelin- ja asiakasohjelmat voivat yhteydenoton jälkeen sopia keskenään siitä mitä protokollaa käytetään; se voi olla http 1.1, http 2.0 tai jokin muu.

Onko linkki, vaikkapa http://www.kansalliskirjasto.fi/, pelkästään dokumentin osoite vaiko myös sen tunnus? Tähän on kaksi erilaista vastausta.

Alun perin Internet-standardeja kehittävä Internet Engineering Task Force erotti toisistaan dokumentin pysyvän tunnuksen (Uniform Resource Name, URN) ja sijaintitiedon (Uniform Resource Location, URL[2]). Vuonna 1994 julkaistu RFC 1737[3] erottaa nämä kaksi selvästi toisistaan:

A URN identifies a resource or unit of information. It may identify, for example, intellectual content, a particular presentation of intellectual content, or whatever a name assignment authority determines is a distinctly namable entity. A URL identifies the location or a container for an instance of a resource identified by a URN. The resource identified by a URN may reside in one or more locations at any given time, may move, or may not be available at all. Of course, not all resources will move during their lifetimes, and not all resources, although identifiable and identified by a URN will be instantiated at any given time. As such a URL is identifying a place where a resource may reside, or a container, as distinct from the resource itself identified by the URN.

Koska URN-tunnuksen lisäksi Internetissä sovelletaan muitakin vastaavia järjestelmiä, käytetään nykyään usein yleistermiä pysyvä tunnus (Persistent Identifier eli PID). Se kattaa myös esimerkiksi Handle-, DOI- ja ARK-tunnuksen. RFC 1737:n linjaukset soveltuvat kaikkiin PID-järjestelmiin.

URN – URL -jako vastaa kirjastojen perinteistä tunnuksien ja signumien erottelua ja on sen vuoksi kirjaston näkökulmasta luonteva. Samaa ei voi sanoa Uniform Resource Identifier – eli URI-konseptista, joka sisältyy vuonna 2005 julkaistuun URI Syntax (RFC 3986[4]) -standardiin. URI pyrkii parhaansa mukaan häivyttämään URN-tunnuksen ja URL-osoitteen eron:

A URI can be further classified as a locator, a name, or both. The term ”Uniform Resource Locator” (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network ”location”). The term ”Uniform Resource Name” (URN) has been used historically to refer to both URIs under the ”urn” scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name.

An individual scheme does not have to be classified as being just one of ”name” or ”locator”. Instances of URIs from any given scheme may have the characteristics of names or locators or both, often depending on the persistence and care in the assignment of identifiers by the naming authority, rather than on any quality of the scheme. Future specifications and related documentation should use the general term ”URI” rather than the more restrictive terms ”URL” and ”URN” [alleviivaus tekijän]

RFC 3986:n laadinnassa mukana olleet ovat kertoneet, että URI-linjausta ajoi erityisesti World Wide Web Consortium. W3C on nähnyt paljon vaivaa osoittaakseen että Webissä sijaintitiedot voivat olla tunnuksia; se on mm. julkaissut ohjeita siitä miten URL:t voidaan laatia niin, ettei niitä tarvitse muuttaa[5]. Uskonkappaleeksi on muodostunut Tim Berners-Leen lause ”URIs don’t change, people change them[6]. Tämä on tietysti aivan yhtä totta kuin lause ”Signumit eivät muutu, ihmiset muuttavat niitä”. Ja signumeitahan ei muuteta huvin vuoksi ja muuten vain, vaan siksi että ei ole järkevää edes yrittää pitää niitä samana. Pitkäaikaiseen kokemukseen perustuen toimivin ratkaisu on erottaa tunnukset sijaintitiedoista, jolloin sijaintitietoja voidaan muuttaa aina tarpeen mukaan.

On erikoista että IETF hyväksyi RFC 3986:n, koska RFC 1737:n mukaan sijaintitieto ei todellakaan sovellu tunnukseksi. URN-tunnusten pitää täyttää joukko tiukkoja vaatimuksia, joista kaksi ensimmäistä ovat:

  • Global scope: A URN is a name with global scope which does not imply a location. It has the same meaning everywhere.[alleviivaus tekijän]
  • Global uniqueness: The same URN will never be assigned to two different resources.

Samassa URL-osoitteessa voi eri aikoina olla erilainen resurssi, ja sama resurssi voi löytyä useista eri URL-osoitteista. On hurskastelua väittää, että kunnollinen URL-hallinnointi eliminoi nämä ongelmat, varsinkin kun otetaan huomioon ettei domain-nimiä voi ostaa, vaan vain vuokrata. Tunnuksena URL on niin kehno, ettei tunnusjärjestelmien ISO-standardoinnista vastaava ISO TC 46/SC 9 ole edes harkinnut URL:n ottamista käsiteltäväksi. Merkittävin ongelma on minusta kuitenkin se, ettei verkon käyttäjillä ole mitään mahdollisuutta tietää, onko jonkin URL-osoitteen edes tarkoitus toimia tunnuksena vai ei. Järjestelmää jossa tunnuksiin ei voi luottaa edes lyhyellä aikavälillä saati sitten pidemmän päälle, ei olisi koskaan pitänyt luoda. Mutta IETF-konkareiden mukaan RFC 3986:tta ei hyväksyttykään sen poikkeuksellisten teknisten ansioiden vuoksi, vaan sen tähden ettei välejä W3C:n kanssa ei haluttu rikkoa.

URI:n lanseeraamisen jälkeen on luotu satoja miljoonia PID-tunnuksia. Ihmiset puhuvat edelleen URL-osoitteista eivätkä URI-tunnuksista. ”Ideologisesti” W3C:n URI-linjaus ei siis ole ollut mikään erityinen menestys. Käytännön tasoa, eli sitä, miten pysyviä URL-osoitteet nykyään ovat, käsitellään tuonnempana.

Keskeinen käytännön ero pysyviin tunnuksiin perustuvan lähestymistavan ja W3C:n URI-politiikan välillä on se, että PID-tunnus ei suoraan ilmaise dokumentin sijaintipaikkaa tai -paikkoja. Tarvitaan resoluutioksi kutsuttu toimenpide, jolla PID muunnetaan yhdeksi tai useammaksi URL:ksi. URI-koulukunnan mukaan PID-resoluutio on ylimääräinen askel, josta ei ole mitään hyötyä ja jota tulisi sen vuoksi välttää. Vastaavasti PID-koulukunnan mukaan URL-osoitteen pitäminen toimivana edes nimipalvelun avulla on riittävän pitkällä aikavälillä vaivalloista tai mahdotonta. Ja vaikka linkki toimisi, käyttäjän on usein vaikeaa arvioida, onko URL- osoitteesta löytyvä dokumentti pysynyt samana vai ei.

Onko linkeillä luonnetta?

W3C ja IETF ovat panostaneet myös linkkien luonteen määrittelyyn. 2010 ilmestyi Internet-standardi Web linking (RFC 5988)[7], ja siihen nojautuen IANA eli Internet Assigned Names Authority ylläpitää rekisteriä[8], jossa määritellään millaisia suhteita verkon resurssien välillä voi olla. Esimerkiksi kahden identtisen dokumentin (tiedoston) välillä vallitsee duplicate-suhde, dokumentin ja sen metatietojen välillä describes-suhde, dokumentin ja sen käyttöoikeuksia kuvaavan dokumentin välillä license-suhde, osakohteen ja emon välillä up-suhde, ja niin edelleen. Vaikka suhteiden lista on pitkä, FRBR-linkit siitä puuttuvat, ja kirjastoalan ammattilaisen näkökulmasta koko suhderakennelma näyttääkin varsin satunnaisesti kasatulta.

RFC 5988:n mukaan linkit ovat osa linkitettävää dokumenttia. Esimerkiksi HTML:n tapauksessa voidaan käyttää <link>-elementtiä ja erityisesti sen rel-attribuuttia. Linkkejä analysoimalla selaimet voisivat siirtyä käyttäjän toiveiden mukaan esimerkiksi dokumentin kuvailusta itse dokumenttiin tai käyttöoikeudet selvittävään lisenssisopimukseen. Lisäksi olisi mahdollista paikallistaa dokumentin alkuperäinen, viimeisin tai ns. kanoninen versio. Tuo viimeksi mainittu on minusta ajatuksena mielenkiintoinen, koska kanoninen linkki viittaa dokumentin suositeltavaan versioon, jonka ei tarvitse olla uusin (sitä varten on current- ja last version -attribuutit) eikä vihoviimeinen (attribuutti last).

En tiedä miten laajasti Web linking -standardin määrittelemä ratkaisu dokumenttien suhteiden määrittelyyn on tuotannossa. Kirjastoilla on tämäntyyppisestä linkityksestä vuosikymmenien mittainen, joskin tiettyihin erikoissuhteisiin rajattu kokemus. Kirjastot eivät myöskään tallenna suhdetietoja linkkeihin, vaan ne ilmaistaan metatiedoissa. Esimerkiksi linkki lisenssin kuvaukseen tallennetaan eri MARC- tai Dublin Core -kenttään kuin linkki kuvailtuun dokumenttiin, samoin linkit emojulkaisuun tai osakohteisiin.

Minusta kirjastojen ratkaisu suhteiden ilmaisemiseen on RFC 5988 -standardia parempi. Jos linkit tallennetaan metatietoihin, keskinäisessä suhteessa olevien entiteettien olomuoto voi olla mitä tahansa, samoin kuin nuo entiteetit itsekin. RFC 5988:n mukainen suhteiden ilmaiseminen hypertekstilinkein on mahdollista vain kun dokumentit ovat verkossa ja sopivassa tiedostomuodossa. Tästä ei ole paljon iloa silloin, kun halutaan kuvata esimerkiksi englanninkielisen romaanin ja sen suomennoksen suhdetta, jos molemmat kirjat ovat painettuja.

Metatietopohjaisen linkityksen ongelmana on se, että ymmärtääkseen linkin luonteen, sovellusten on kyettävä tulkitsemaan metatietoformaattia. Jos MARC-formaatista halutaan poimia linkki kuvailtuun dokumenttiin, on tiedettävä että se löytyy 856-kentästä sillä edellytyksellä että toinen indikaattori on 0. Haasteena on esittää erilaisiin formaatteihin upotetut linkkitiedot niin, että kaikki verkon sovellukset voivat käyttää niitä hyväksi.

URL-osoitteiden ja pysyvien tunnisteiden luotettavuudesta

URI-strategia ei ole ideologisesti ollut mikään täydellinen menestys, mutta käytännön tasolla se on epäonnistunut vielä pahemmin. Kaikilla meistä on karvaita kokemuksia linkkien toimimattomuudesta, joskin näistä yksittäistapauksista ei pidä vetää yleisiä johtopäätöksiä. Valitettavasti tutkimustuloksetkin viittaavat siihen, että URI:t eivät ole ”cool”. Miljooniin dokumentteihin perustuneen tutkimuksen [Klein] mukaan e-aineistoja lähteenään käyttäneistä tieteellisistä artikkeleista jo 70 %:lla on kadonneita elektronisia lähteitä, toisin sanoen niitä ei löydetty edes verkkoarkistoista, saati sitten alkuperäisestä osoitteesta. Jo vuoden vanhojen artikkeleiden e-lähteistä oli lakannut toimimasta noin joka kymmenes, ja artikkeleiden vanhetessa kasvoi myös kadonneiden lähteiden osuus.

Jatkuessaan tämä kehityskulku vaikuttaa merkittävästi tieteen tekemiseen: miten arvioida julkaisun luotettavuutta, jos sen lähteitä ei löydy? Huijarit ovat ennenkin keksineet aineistoja – tunnettu kotimainen esimerkki on Carl Öhman, joka käytti lähteenä omatekemiä Strindbergin kirjeitä ja muistiinpanoja[9]. Öhman jäi kiinni, koska Strindberg-aineistot on arkistoitu ja huijaus voitiin todistaa. Mutta keksittyjä verkkoaineistoja käyttänyt tutkija voi aina väittää, että kyseiset dokumentit ovat valitettavasti kadonneet Öhmanin kuvitteellisen tohtorindiplomin tapaan.

Tutkimustulosten perusteella ei ole syytä uskoa että Web olisi erilainen kuin perinteiset kokoelmat: verkossakin dokumenttien sijaintipaikat muuttuvat ja aineistoa poistetaan. Ja vaikka nimipalvelun avulla käyttäjä voidaan periaatteessa ohjata uuteen osoitteeseen, käytännössä järjestelmä ei aina toimi. URL-osoitteiden pysyvyyteen voi luottaa vain joissakin erikoistapauksissa (verkkoarkistojen osoitteet ovat tästä esimerkkejä), eivätkä nekään toimi kyseistä verkkoarkistoa pidempään. Linkkien hajoaminen on vakava ongelma, koska semanttinen Web on riippuvainen linkkien toiminnasta.

Meillä ei toistaiseksi ole käytettävissämme luotettavia tutkimustuloksia siitä, miten luotettavia PID-tunnuksiin perustuvat linkit ovat. Kleinin ja kumppaneiden tutkimusaineistossa oli toki paljon artikkeleita joilla oli DOI-tunnus, mutta ne piti tietenkin poistaa URL-osoitteiden luotettavuutta tutkittaessa. Ja valitettavasti näiden DOI-linkkien luotettavuutta ei ole sittemmin analysoitu erikseen.

Tutkimusaineistoa PID-ratkaisun toimivuudesta on saatavissa runsaasti, koska pysyviä tunnisteita on annettu satoja miljoonia. Tieteelliset artikkelit ja tutkimusdata ovat esimerkkejä aineistoryhmistä, joilla PID-tunnuksia käytetään hyvin yleisesti. Suurimpia käyttäjäryhmiä ovat tieteelliset kustantajat ja tieteelliset kirjastot, erityisesti kansalliskirjastot. Nämä ovat niitä organisaatioita, joilla on eniten kokemusta perinteisistä tunnisteista ja niiden soveltamisesta.

Tarjolla olevien resoluutiopalvelujen niukkuus on kaikkien PID-järjestelmien yhteinen ongelma. Kun esimerkiksi Kansalliskirjaston URN-sovellus kykenee vain linkittämään URN-tunnuksen yhteen ja vain yhteen URL-osoitteeseen kerrallaan, lisäarvo jää kirjaston asiakkaan näkökulmasta pieneksi. PID-sovelluksia tuleekin kehittää, ensi alkuun mahdollistamalla yhden PID-tunnuksen linkitys useisiin URL-osoitteisiin (jota Handle system jo tukee). Tämän pitäisi olla vasta alkua; resoluutiopalveluja tulee kehittää vielä paljon pidemmälle, ja tämä edellyttää myös PID-standardien uusimista.

URN-uudistusprosessin nykytila

IETF käynnisti jo vuonna 2010 URN-standardin uudistamistyön, mutta se osoittautui paljon luultua vaikeammaksi, eikä vähiten URI Syntax -standardin ongelmien vuoksi. RFC 3986:n uudistamista ei ole edes suunnitteilla, mikä lienee viisasta – sen linjauksia koskevat erimielisyydet ovat niin syviä, ettei niiden ratkaiseminen tule olemaan helppoa jos ja kun sitä aikanaan yritetään. Mutta tämä tarkoittaa sitä, että URN-standardin modernisoinnissa URI-syntaksin ongelmat pitää jollakin tavoin kiertää.

IETF:n URNBIS-työryhmä on tätä kirjoittaessa paiskinut töitä jo yli viisi vuotta. Paljon aikaa on käytetty käytännön kannalta perin teoreettiselta vaikuttavien ongelmien ratkomiseen. Vasta kesäkuussa 2015 oltiin niin pitkällä, että elo-syyskuussa valmistuva seuraava versio URN-syntaksimäärityksestä tultaneen alistamaan Working Group Last Call eli WGLC-äänestykseen. Niissä Internet Engineering Steering Group (IESG)[10] päättää, onko määritys valmis julkaistavaksi Internet-standardina. Ratkaisun WGLC-äänestykseen siirtymisestä tekivät normaaliin tapaan työryhmän puheenjohtajat, ja kriteerinä oli ensi sijassa URNBIS-työryhmässä saavutettu konsensus, joka on tätä kirjoitettaessa jo varsin hyvä.

URNBIS-työryhmän tuottamat standardiluonnokset[11] sekä työryhmän listalle lähetetyt sähköpostit[12] ovat IETF:n normaalin linjan mukaan vapaasti käytettävissä. Tämä maksimoi standardointiprosessin avoimuuden tavalla, josta muut merkittävät standardointijärjestöt voisivat ottaa oppia. Ero esimerkiksi ISO:n toimintamalliin on huomattava, mutta linjassa sen kanssa että IETF:n standarditkin ovat vapaasti käytettävissä, ISO:n ei.

Avoimuuden yksi etu on se, että kun kaikki informaatio on vapaasti kaikkien käytettävissä, on jälkeenpäin helppo selvittää, ketkä ovat osallistuneet standardin kehittämiseen ja millä tavoin, ja miksi ryhmät ovat päättyneet tekemiinsä ratkaisuihin. URN-kehitystyö yleensä, ja eritoten keskustelu URI-syntaksin ongelmista on ollut monessa suhteessa opettavaista. Toivottavasti URNBIS-arkistoa käytetään hyväksi, jos ja kun URI-syntaksi eli joskus uusitaan.

URN-määrittelytyössä kompastuskiviä ovat olleet erityisesti URI:n query- ja fragment-osat, jotka ovat URI-syntaksin mukaan tunnisteita. URNBIS-ryhmässä ongelma kierrettiin siten, että URN-tunnusten kanssa voi käyttää q-komponenttia ja f-komponenttia, jotka näyttävät samalta kuin query- ja fragment, mutta eivät ole tunnisteita. Syntaksi on siis sama, mutta semantiikka ei.

Kertauksen vuoksi: edellä kerrottu tarkoittaa käytännössä sitä, että URI-syntaksin mukaan URN

urn:isbn:978-3-598-24287-8#chapter_2

on ISBN:n identifioiman kirjan toisen luvun tunnus, mutta URN-syntaksin mukaan tämä URN on edelleen vain kirjan tunnus. Toisin kuin URI-fragmentti, ISBN:n perään lisätty f-komponentti #chapter_2 ei ole osa tunnusta vaan osoittaa vain sen, mistä kirjan toinen luku alkaa. Tämä ero voi kuulostaa hiuksen halkomiselta, mutta jos URN-tunnuksen soveltaminen laajentaisi ISBN:n katteen kirjojen osakohteisiin, kansainvälinen ISBN-yhteisö ei olisi mielissään, varsinkin kun sillä on jo omat periaatteet osakohteiden identifiointiin.

Yleisesti ottaen URN:n tai muiden PID-tunnusten soveltamisella ei saisi olla muuta vaikutusta kuin että perinteisistä tunnusjärjestelmistä saadaan toiminnallisia Webissä. Perinteisten tunnusten soveltamisala ja rakenne eivät saisi muuttua. Toisin kuin URN, URI rikkoo tämän vaatimuksen, joka on esitetty jo RFC 1737:ssa. Toisaalta PID-järjestelmät eivät saisi tunkeutua perinteisten tunnusten reviirille, eli niillä ei pitäisi olla mahdollista tunnistaa samoja dokumentteja kuin perinteisin järjestelmin. Tässä suhteessa kaikki muut PID-järjestelmät paitsi URN ovat jossakin määrin haasteellisia.

Q-komponentti

Query on semanttisesti vielä fragmenttiakin ongelmallisempi. RFC 3986:n mukaan esimerkiksi URN

urn:isbn:978-3-598-24287-8?version=1.1&operation=searchRetrieve&

query=9783598242878&maximumRecords=1&recordSchema=dc

pitäisi tulkita haun tuloksena saatavan tietueen tunnukseksi. Mutta ISBN:ää tai mitään muutakaan perinteistä tunnusjärjestelmää ei voi laajentaa tällä tavoin täysin uudentyyppisiin aineistoihin (ja bibliografisten tietokantojen tietueilla on jo omat tunnuksensa). Uuden URN-syntaksin mukaan esimerkki-URN identifioikin edelleen vain National Bibliographies in the Digital Age –kirjan. ISBN-tunnuksen perään on lisätty SRU-tiedonhakuprotokollan mukainen q-komponentti, jolla voidaan hakea periaatteessa mistä tahansa SRU-tiedonhakuprotokollaa tukevasta tietokannasta kirjan metatiedot Dublin Core –formaatissa. URN-resoluutiopalvelun tehtävä on valita ISBN:n perusteella oikea kohdetietokanta.

RFC 3986:n linjaus URI querystä tunnuksena on ylipäätään outo. Webistä on helppo löytää esimerkkejä, joissa Queryllä ei ole mitään tekemistä minkään objektin tunnistamisen kanssa. Esimerkiksi tässä on kyse vain tulosjoukon lajittelusta:

http://www.bookfinder4u.com/search_author/Ernest_Hemingway.html?sort=date

Yllä oleva URL ”identifioi” saman tulosjoukon kuin URL jossa queryä ei ole; vain viitteiden järjestys muuttuu. Toisaalta on helppoa laatia URI query jota palvelin ei pysty käsittelemään:

http://www.bookfinder4u.com/search_author/Ernest_Hemingway.html?sort=pvm

Epäkelpo URI query jätetään huomiotta noin vain, ilman käyttäjälle suunnattua varoitusta. Toisin sanoen verkon dokumenteille voi laatia periaatteessa rajattoman määrän URI-tunnuksia mielivaltaisia queryja lisäillen.

URN-syntaksin mukaan q-komponenttikaan ei identifioi mitään, sitä käytetään vain resoluutioon liittyvien pyyntöjen lähettämiseen. URNBIS-ryhmässä käydystä pitkästä ja monipolvisesta keskustelusta voi vetää sen johtopäätöksen, että URI queryllä ja fragmentilla ei ylipäätään pitäisi olla roolia verkkoaineistojen tunnistamisessa. Mutta jos tämä kysymys otetaan esille RFC 3986:n mahdollisessa tulevassa päivityksessä, voitaisiin päätyä keskustelemaan siitäkin, onko URI ylipäätään sopiva tunnukseksi, ja siihen keskusteluun ei esimerkiksi W3C:llä ole ollut URNBIS-kehitystyön mittaan mitään kiinnostusta.

Vapauttamalla f-komponentti ja q-komponentti tunnistamisvastuusta voidaan liberalisoida myös niiden käyttö. ISBN-tunnuksen voi antaa vain auktorisoitu taho, mutta kuka tahansa voi lisätä aiemmin luotuun URN:ISBN-tunnukseen f-komponentin esimerkiksi tehdessään lähdeviittausta. Ja kirjaston näyttöluettelosovellus voi lisätä URN:ISBN-tunnukseen q-komponentin, kun käyttäjä kertoo käyttöliittymälle haluavansa paikallistamansa kirjan hallinnolliset metatiedot julkaisuarkistosovelluksesta. Q-komponenttien ei myöskään tarvitse olla pysyviä, ne voivat muuttua sovellusten kehittyessä. F-komponentit eivät muutu, ja niitä voidaan soveltaa vain ISBN:n kaltaisissa tunnusjärjestelmissä, joissa tunnus identifioi yhden ja vain yhden dokumentin manifestaation.

R-komponentti

Pysyvien tunnusten kannalta q-komponenttiin pohjautuvassa toimintamallissa on se ongelma, että palvelupyynnöt menevät oletusarvoisesti aina URN-resoluutiopalvelulle. Pyyntöjä ei voi ”korvamerkitä” käsiteltäviksi taustajärjestelmissä, kuten pitkäaikaissäilytysjärjestelmässä tai julkaisuarkistossa. Kesäkuussa 2015 julkaistu 13. versio URN-syntaksiksi[13] ratkaisi tämän ongelman luomalla r- eli resoluutiokomponentin. Sen avulla annettavat palvelupyynnöt käsitellään aina ensin URN-resoluutiopalvelussa; q-komponentin tapauksessa palvelun tarjoaja on joko taustajärjestelmä tai identifioitu dokumentti.

Q-komponenttia käytettäessä syntaksi määräytyy taustajärjestelmän tukeman tietoliikenneprotokollan mukaan. Esimerkiksi yllä on käytetty SRU-tiedonhakustandardin versiota 1.1. Tällöin URN-resoluutiopalvelulla ei ole muuta tehtävää kuin valita sopiva kohdetietokanta ja tehdä sen URL-osoitteesta SRU-hakulauseen base URL. Jos haku lähetetään Kongressin kirjaston tietokantaan, esimerkin URN-tunnuksesta saadaan URL:

http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=9783598242878&maximumRecords=1&recordSchema=dc

R-komponentin tunnus on ”??”. Jos alkuperäisen URN-esimerkin q-komponenttiin talletettu SRU-haku korvataan vastaavalla r-komponentilla, saamme URN:n, jolla palvelimelta voidaan pyytää dokumentin kuvausta Dublin Core –muodossa:

urn:isbn:978-3-598-24287-8??s=I2C&maximumRecords=1&recordSchema=dc

Metatietoformaatti on esimerkissä määritelty yksinkertaisuuden vuoksi SRU-protokollan tapaan; toistaiseksi ei ole päätöstä siitä miten formaatit tulisi esittää, eikä myöskään linjausta sen suhteen onko tietuemäärä myös tarpeen määritellä. Mutta on luontevaa ajatella että parametrit määrittyvät kulloinkin sovellettavien rajapintastandardien mukaan.

Asiakkaiden ei pitäisi joutua URN-tunnusten eikä varsinkaan niiden mahdollisten q- tai r-komponenttien kanssa tekemisiin. Asiakkaan käyttämän client-sovelluksen on osattava rakentaa r- tai q-komponentti tarpeen mukaan, ja URN-resoluutiopalvelun vastuulla on muokata esimerkiksi r-komponentti valitun kohdejärjestelmän kuten Kongressin kirjaston SRU-palvelimen tukemaan muotoon. Kohdejärjestelmän muuttuessa myös r- ja q-komponentit voivat muuttua tarpeen mukaan, ja sen vuoksi pysyvään tunnukseen perustuvat linkit eivät enää ole staattisia eli johda aina samaan URL-osoitteeseen.

R-komponentin lisääminen ja monet muut, vähäpätöisemmät muutokset versioon 12 eivät ole kirvoittaneet paljoakaan kriittistä palautetta. Keskustelussa esitetyt muutostoiveet ovat olleet verraten pieniä, ja ne ovat ainakin minusta helpohkosti huomioon otettavissa. Version 14, joka siis hyvässä lykyssä jää viimeiseksi, on tarkoitus valmistua vielä kesän 2015 aikana.

Pysyvät tunnukset ja semanttinen Web

Pysyvät tunnukset voivat tukea semanttisen Webin rakentamista ainakin kahdella tavalla. Ensimmäinen ja ilmeinen tapa on linkkien luotettavuuden paraneminen. PID-tunnukseen perustuva linkki toimii, vaikka dokumentin URL-osoite muuttuu. Eikä linkki hajoa silloinkaan kun nimipalvelun avulla asiaa ei olisi voitu järkevästi hoitaa. Toinen pysyvien tunnusten etu on se että yhdestä tunnuksesta voidaan luoda linkki moneen osoitteeseen, vieläpä niin että linkin luonne otetaan huomioon. Toisin sanoen linkissä voidaan ilmaista että sen takaa löytyy esimerkiksi dokumentin käyttöoikeudet kuvaava lisenssi. Tätä ominaisuutta voimme kutsua linkkien rikastamiseksi.

URN-linkityksen luotettavuus ei ole ensisijaisesti teknistä laatua, vaan perustuu siihen että PID-tunnuksia hallinnoidaan; tunnuksen antanut taho vastaa tunnuksen pysyvyydestä ja mahdollisesti myös siitä, että linkki toimii. Webin käyttäjien kannalta PID-tunnuksen ja URL-osoitteen ero on selkeä – edelliset on helppo tunnistaa, ja PID-tunnukseen perustuvan linkin avulla löytyy periaatteessa aina juuri se dokumentti kuin on tarkoituskin.

Cool URI -ideologia – sellaiseksi sitä voinee kutsua – on ongelmistaan huolimatta hyväksytty laajalti. Monille riittää, että linkki verkossa olevaan dokumenttiin toimii nyt. Harva pohtii sitä, millä edellytyksin ja millä todennäköisyydellä se toimii myös 20 tai 50 vuoden päästä, kun kaikki sovellukset ja verkon protokollat ovat voineet vaihtua useampaan kertaan eikä dokumentin sijaintikaan enää ole sama. Kaukaiseen tulevaisuuteen vetoamisen sijaan PID-järjestelmien kehittäjien pitää lisätä resoluutiopalveluihin uusia toimintoja, eli rikastaa linkitystä tavoilla joita on vaikea tai mahdoton toteuttaa URL-osoitteiden avulla. Ilman selkeää näyttöä PID-järjestelmien välittömistä toiminnallisista eduista verkon sisällöntuottajia on vaikeaa vakuuttaa pysyvien tunnuksen soveltamisen tarpeellisuudesta.

Digitaalisen aineiston hallintasovellusten uudet versiot ja kokonaan uudet sovellukset kuten pitkäaikaissäilytysjärjestelmät luovat sekä edellytyksiä että tarpeen resoluutiopalveluiden kehittämiseen entistä monipuolisemmiksi. URL-osoitteiden ja Web linking -standardissa kuvattujen menetelmien avulla tarvittavan toiminnallisuuden luominen osoittautunee hankalaksi. PID-tunnukset tarjoavat kehitystyölle paremman lähtökohdan.

Pysyvät tunnisteet tarjoavat jo nyt pelkän linkityksen lisäksi lisäpalveluja. ARK-tunnuksen avulla on mahdollista saada ARK-resoluutiopalvelimelta sille tallennetut identifioidun dokumentin metatiedot tai selvityksen siitä, millä tavoin dokumentin omistava organisaatio on sitoutunut sen pitkäaikaissäilytykseen. Handle-järjestelmässä voi rajata esimerkiksi maakoodin avulla sen, missä tunnuksen resoluutio tehdään. ARK- ja Handle-palveluita on toistaiseksi kehitetty toisistaan riippumattomasti, mutta periaatteessa ne ovat yhteismitallistettavissa. Käytännössä tämä edellyttäisi varsin suuria ohjelmistomuutoksia.

Myös URN-tunnukselle on määritelty RFC 2483:ssa[14] joukko palveluja, joita URN-resoluutiopalvelut voisivat tarjota. Valitettavasti nykyiset URN-resoluutiopalvelimet tukevat yleensä vain URN – URL -linkitystä koska lisäpalveluiden käytännön toteutukseen ei ole ollut resursseja eikä erityistä tarvetta. Teknisenä pullonkaulana on ollut resoluutioon liittyvien palvelupyyntöjen siirtäminen palvelimelle tai suoraan kohdejärjestelmään, koska siihen ei ole ollut mitään helposti toteutettavissa olevaa menetelmää. Myös uusien palvelujen määrittely tai olemassa olevien palvelujen muokkaus on ollut kömpelöä. Palvelut määritellään Internet-standardissa RFC 2483, ja RFC-dokumenttien päivittäminen voi olla työlästä, kuten URN-syntaksin modernisoinnin pohjalta hyvin tiedetään.

Uuden URN-syntaksin q- ja r-komponentteja voidaan soveltaa palvelupyyntöjen siirtämiseen esimerkiksi kirjastojärjestelmän asiakaskäyttöliittymästä URN-resoluutiopalvelimelle tai julkaisuarkistoon. Teknisesti tämän pitäisi olla helppoa, koska samankaltaisia menetelmiä sovelletaan jo nyt ARK- ja Handle-järjestelmissä. Q-komponentin rakenne ja sisältö tulee määrittymään käytetyn protokollan kuten SRU:n mukaan; r-komponentin osalta tarvittavat määrittelyt tulee laatia erikseen. Yksi mahdollinen ratkaisu on luoda rekisteri, jossa ylläpidetään resoluutiopalvelujen ja niiden parametrien luetteloa.

URN-järjestelmän käyttöä mietittäessä on otettava huomioon myös kirjastojärjestelmien tarjoamat linkitysmahdollisuudet. Yksinkertaisimmillaan tämä onnistuu niin, että MARC-tietueeseen tallennettavat linkit tehdään URN-pohjaisiksi. Esimerkiksi linkit teoksen kuvailusta manifestaatioiden kuvailuun voidaan toteuttaa URN:NBN-tunnuksin, samoin linkki julkaisun kuvailusta sen käyttöä säätelevään lisenssiin. Merkittävä työn säästö saavutetaan, jos tietueisiin ei sisällytetä URL-linkkejä dokumentin eri kopioiden verkko-osoitteisiin, vaan tallennetaan vain yksi PID, jota vastaavat URL-osoitteet verkossa ja verkkoarkistoissa tallennetaan resoluutiopalveluun. Luetteloinnin kannalta PID-tunnusten etu on että URL-linkit pitäisi ylläpitää tietuetasolla, mutta PID-pohjalta linkitys voidaan toteuttaa resoluutiopalvelun ansiosta toteuttaa keskitetysti.

MARC-formaatissa on monenlaisia linkkejä, mikä lisää resoluutiopalvelun rakentamisen vaativuustasoa, mutta helpottaa rikkaiden linkityspalveluiden rakentamista. Kentän 856 (Elektronisen aineiston sijainti ja käyttö) osakentässä $u voi olla joko URN – jos resoluutiopalvelua käytetään jo – tai URL. URL-osoite tai –osoitteet on haravoitava resoluutiopalveluun ja korvattava URN-tunnuksella, joka tallennetaan 856 $u –osakenttään HTTP URI -muodossa. Mutta URN-resoluutiopalvelun on varauduttava myös toisenlaisiin linkkeihin.

Kentän 540 (Huomautus käytön ja kopioinnin ehdoista) osakentässä $u oleva URN tai URL on linkki dokumentin käyttöoikeudet määrittelevään lisenssiin tai sen tiivistelmään, kentän 542 (Huomautus tekijänoikeudesta) osakentässä $u olevat tunnus / osoite johdattaa asiakkaan dokumentin tekijänoikeudelliseen statukseen liittyvään tietoon. Nämäkin URI:t tulee tallentaa resoluutiopalveluun, jossa niitä voidaan soveltaa silloin kun asiakas haluaa dokumentin käyttöoikeustiedot / tekijänoikeustiedot tai ylipäätään kaiken dokumenttiin liittyvän metatiedon. URN-resoluutiopalvelun pitää kyetä soveltamaan tallennetuista linkeistä sitä tai niitä, jotka ovat kulloisenkin tiedontarpeen kannalta relevantteja. Palvelun pitää siis tavalla tai toisella säilyttää tieto URN- tai URL-pohjaisten linkkien luonteesta.

Lopuksi

Yhä suurempi osa tieteellisistä julkaisuista on elektronisia, ja niissä käytetään yhä enemmän elektronisia lähteitä. Myös tutkimusdatan linkittämisestä tutkimusjulkaisuihin on tulossa yleinen tapa, ja ennen pitkää sitä tullaan vaatimaan. Tämä linkkien varaan rakennettu tieteellisen informaation kokonaisuus ei pysy kasassa, elleivät tänään luodut linkit toimi vielä vuosikymmenien, kenties vuosisatojenkin päästä.

Joillakin erikoisaloilla merkittävällä osalla aineistoista on jo PID-tunniste. Niihin perustuvien luotettavien linkkien tarjoaminen URL-osoitteiden asemesta tulee omalta osaltaan parantamaan semanttista Webiä. Kirjastojen tulisi soveltaa pysyviä tunnuksia omissa julkaisuarkistoissaan mutta myös laajemmin luetteloinnissa, sekä julkaisujen & muiden aineistojen että niiden tekijöiden identifiointiin. Kirjastojen pitäisi luoda olemassa olevien metatietojen pohjalta rikkaita linkkejä, joiden avulla asiakkaat voivat löytää lisää tietoa kokoelmissa olevista aineistoista.

Pitkä kokemus perinteisten kokoelmien säilyttämisestä on osoittanut tunnuksen ja sijaintitiedon erottamisen hyväksi ajatukseksi. Käytettävissä olevan tiedon valossa ei ole mitään syytä uskoa, että elektroniset kokoelmat olisivat tässä suhteessa erilaisia kuin perinteiset kokoelmat. Myös e-kirja voi olla saatavilla monesta eri sijaintipaikasta, samassa sijaintipaikassa oleva dokumentti voi aikaa myöden muuttua, ja toisinaan kokoelmia pitää voida siirtää uuteen osoitteeseen tai toisen organisaation vastuulle. Alkuperäisen sijaintipaikan ylläpito tunnuksena voi periaatteessa onnistua lyhyen aikaa, mutta mitä enemmän aikaa kuluu, sitä vaikeampaa siitä tulee, ja sitä suuremmat ovat pysyvien tunnusten käytöstä saatavat edut.

Lähde

Klein M, Van de Sompel H, Sanderson R, Shankar H, Balakireva L, Zhou K, et al. (2014) Scholarly Context Not Found: One in Five Articles Suffers from Reference Rot. PLoS ONE 9(12): e115253. doi:10.1371/journal.pone.0115253. Elektroninen artikkeli, saatavilla osoitteesta http://dx.doi.org/10.1371/journal.pone.0115253

Viitteet

[1] https://tools.ietf.org/html/rfc7540

[2] https://www.ietf.org/rfc/rfc1738.txt

[3] https://www.ietf.org/rfc/rfc1737.txt

[4] https://www.ietf.org/rfc/rfc3986.txt

[5] http://www.w3.org/DesignIssues/

[6] http://www.w3.org/Provider/Style/URI.html

[7] http://tools.ietf.org/html/rfc5988

[8] http://www.iana.org/assignments/link-relations/link-relations.xhtml

[9] https://fi.wikipedia.org/wiki/Carl_%C3%96hman

[10] https://en.wikipedia.org/wiki/Internet_Engineering_Steering_Group

[11] https://datatracker.ietf.org/wg/urnbis/documents/

[12] https://mailarchive.ietf.org/arch/search/?email_list=urn

[13] https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-12

[14] https://tools.ietf.org/html/rfc2483

 

Kirjoittajan yhteystiedot

Juha Hakala, erityisasiantuntija
Kansalliskirjasto
PL 26 (Kaikukatu 4) 00014 HELSINGIN YLIOPISTO
sähköposti: juha.hakala [at] helsinki.fi