Kaiken pahan alku ja URI: IETF ja URN-uudistus

Juha Hakala
Kansalliskirjasto

Tämän artikkelin pysyvä osoite on http://urn.fi/URN:NBN:fi-fe2014120552177

 

Internet Engineering Task Force perusti 2010 URNBIS-työryhmän, jonka tavoitteena oli modernisoida URN (Uniform Resource Name) –tunnusjärjestelmän keskeiset standardit kuten URN-tunnuksen rakenteen määrittelevä RFC2141 (URN Syntax, https://www.ietf.org/rfc/rfc2141.txt). Työryhmän tehtävät pyrittiin rajaamaan tarkoin ns. periaatteellisten ongelmien välttämiseksi.

Valitettavasti rajaus ei auttanut tarpeeksi. Prosessi on aika ajoin näyttänyt olevan täysin jäissä. Vasta viimeisin työryhmän julkistama, järjestyksessä yhdeksäs ehdotus URN-syntaksiksi (https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-08) näyttäisi kelpaavan kaikille, vaikka sekin on vielä ainakin pienen viilauksen tarpeessa.

Jotta ymmärtäisi miksi asiat ovat olleet näin vaikeita, on tarvis kerrata historiaa.

Alussa (90-luvulla) IETF erotti toisistaan verkkoaineistojen nimen/tunnisteen eli URN:n sekä sijainnin eli URL:n (https://www.ietf.org/rfc/rfc1738.txt). Ratkaisu toimi oivallisesti myös käytännössä – koskaan ei ollut epäselvyyttä siitä, oliko jokin merkkijono tunniste vai ei, koska URL:t eivät a priori voineet koskaan olla tunnisteita. Myös perinteiset (julkaisujen) tunnisteet olivat vaivattomasti sovitettavissa tähän järjestelmään omilla ehdoillaan URN-järjestelmän joustavuuden ansiosta. Kullakin URN-nimialueella toimitaan sen tunnisteen pelisäännöillä, joille tuo nimialue on rekisteröity.

W3C:ssä oli kuitenkin epäilyksiä URN-tunnuksia kohtaan. Katsottiin, että resoluutio – tunnuksen linkittäminen yhteen tai useampaan URL:ään – on ylimääräinen operaatio, josta ei ole vastaavaa hyötyä vaan pikemminkin haittaa. Lisäksi asetettiin kyseenalaiseksi se, ovatko URN:t URL:eja merkittävästi pitkäikäisempiä ja sekin, onko sijaintitiedon ja tunnuksen välillä Internetissä ylipäätään mitään ratkaisevaa eroa. Lainaus eräältä URI-arkkitehdilta saamastani sähköpostiviestistä kuvaa tätä asennetta hyvin:

Ultimately, all authorities will likely eventually fail, it’s only a matter of when. Trying to assert that “urn:” URLs are intrinsically cooler than ones that have a different way of associating strings with resources is just wishful thinking.

Tästä lähtökohdasta on luonnollista korvata URN ja URL yhdellä järjestelmällä. Ja edellä olevan kaltainen näkemys on myös pitkälle uskon asia, eli sitä on vaikea kumota fakta-argumentein. Voidaan tietysti sanoa että perinteisen aineiston osalta kirjaston ISBN:n ja signumin välillä on periaatteellinen ero, ja että se mikä pätee painettuun kirjaan, pätee oleellisilta osiltaan myös elektroniseen kirjaan. Mutta tämän väitteen todistaminen epäileville Tuomaille ei ole helppoa, ei vaikka kertoisi esim. että elektronista kirjaa voi olla useita kopioita eri osoitteissa, eivätkä kaikki nuo osoitteet voi olla tasaveroisia tunnisteita.

Kaiken pahan alku ja URI

Vuonna 2005 IETF määritteli Internet-standardissa RFC 3986 URI:n  eli Uniform Resource Identifier –tunnuksen (https://www.ietf.org/rfc/rfc3986.txt). Sen oli tarkoitus korvata sekä URL että URN (alleviivaus kirjoittajan):

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”.

Tämän peruslinjauksen vuoksi jotkut tekniset asiantuntijat ovat suhtautuneet URN-järjestelmän modernisointiin varauksellisesti. Mutta miten hyvä ajatus sijaintitiedon ja tunnisteen niputtaminen yhteen on?

URI-pohjalta  linkitetyssä datassa jokainen tietoelementti on a priori tunniste. Email-osoite, kotisivun osoite, jopa puhelinnumero – toisiaan täydentäviä tunnisteita kaikki. Mutta minkä tunnisteita – email-osoite voi olla joko henkilön tai hänen postilaatikkonsa tunniste, kotisivun osoite voi olla paitsi henkilön itsensä, myös tuon kotisivun tunniste, ja niin edelleen.  Ja jos esimerkiksi samalle henkilölle on tarjolla useita tunnisteita, ovatko jotkin URI:t parempia kuin toiset? W3C Technical Architecture Group (http://www.w3.org/2001/tag/) perustettiin muun muassa pohtimaan näitä ongelmia, joita ironista kyllä ei olisi ilman URI:n keksimistä koskaan syntynytkään.

URI-tunnuksilla on haasteita myös pysyvyyden ja ainutkertaisuuden suhteen. Sama dokumentti voi olla saatavilla useasta osoitteesta samaan aikaan, se voi muuttaa osoitteesta toiseen, ja samassa osoitteessa voi eri aikoina olla tarjolla eri dokumentti. Tähän kaikkeen W3C:llä on yksinkertainen lääke: ”URI:s don’t change: people change them” (http://www.w3.org/Provider/Style/URI.html).  Eli kaikki on hyvin jos vain valitsemme dokumenttien verkko-osoitteet alun perin fiksusti ja lakkaamme siirtelemästä tiedostoja paikasta toiseen.

Valitettavasti URL:in nimeäminen uudestaan URI:ksi ei ole muuttanut Internetin sijaintitietoja aiempaa pysyvämmäksi. Hiberlink-hankkeen (http://hiberlink.org/index.html) mukaan viiden amerikkalaisen yliopiston vuosina 2003-2010 julkaistujen opinnäytteiden 46.000 elektronisiin aineistoihin tehdyistä viittauksesta 36.7 % eli lähes 18.000 viitettä oli  ”kuollut” jo lokakuuhun 2014 mennessä (ks. http://www.slideshare.net/edinadocumentationofficer/prelida-burnhill-presented). Tässä laskelmassa on otettu huomioon vain perinteiset URL:t, ei DOI-tunnuksiin perustuvia linkkejä. iPRES 2014 –konferenssissa pitämässään esitelmässä Herbert Van de Sompel kertoi, että PubMed-palvelun (http://www.ncbi.nlm.nih.gov/pubmed)  vuonna 2013 julkaistujen dokumenttien linkeistä  10 % on lakannut toimimasta jo yhden vuoden jälkeen, ja vanhimpien, 90-luvun lopun aineistojen lähdeluetteloissa olevista URL-linkeistä vain noin 10 % on ”elossa”.  Kun tieteellisten julkaisujen ja väitöskirjojen lähteistä kasvava osa on elektronisia, meillä on ratkaistavanamme vakava ongelma: miten voimme luoda säilytyksen saarekkeita Internetin hyllyvälle suolle?

Palaan tähän kysymykseen myöhemmin luetteloinnin näkökulmasta erillisessä artikkelissa. Palataksemme tämän tekstin teemaan, URN:n ja muiden pysyvien tunnisteiden kannalta URI on myös periaatteellinen ongelma, koska se hämärtää tunnisteen ja sijaintitiedon eron ja luo sen mielikuvan, että kuka tahansa voi luoda hyväksyttäviä tunnisteita mille tahansa. Mutta tunniste on sitä luotettavampi, mitä paremmin se on hallinnoitu. Hallinnoinnin eli ”huolenpidon” taso on ainoa merkitsevä ero esimerkiksi DOI- ja Handle-tunnusten välillä; teknisestihän ne ovat yhteneviä.

URI:sta on ollut URN-standardin jatkokehittämiselle monenlaista haittaa. Koska tunnistamisen käsite on hämärtynyt, URNBIS-ryhmän keskustelut ovat usein olleet kovin teoreettisia kun eri osapuolet ovat selittäneet mitä kyseinen termi heidän mielestään tarkoittaa.Tilanteen selkeyttämiseksi on yritetty mm. erottaa URI:lla tapahtuva tunnistaminen (identification) ”oikeasta”, hyvin hallinnoidusta tunnistamisesta (naming). Tämä semanttinen viilaus ei tietenkään poista ongelmia vaan siirtää ne vain maton alle.  Mutta kun tämän tasoista keskustelua on käyty muutama vuosi, on kyynikon vaikea välttää sitä tunnetta, että jotkut URNBIS-ryhmän jäsenet sabotoivat työskentelyä. En usko että kyse on tästä, vaan pikemminkin siitä että eri osapuolilla on ristiriitaisia käsityksiä siitä mitä tunnistaminen tarkoittaa.

URI Query ja Fragment

Varsinainen kompastuskivi URNBIS-ryhmässä on viime vaiheessa ollut se, että RFC 3986:n mukaan myös URI:n fragment- ja query-osat toimivat tunnisteina. URN-järjestelmän näkökulmasta tämä on mahdotonta.

URI-syntaksin mukaan esimerkiksi URI http://www.w3.org/2009/08/skos-reference/skos.html#broader voidaan tulkita seuraavasti:

In RDF vocabularies, such as RDFS, OWL, or SKOS, fragment identifiers are used to identify resources in the same XML Namespace, but are not necessarily corresponding to a specific part of a document. For example http://www.w3.org/2004/02/skos/core#broader identifies the concept ”broader” in SKOS Core vocabulary, but it does not refer to a specific part of the resource identified by http://www.w3.org/2004/02/skos/core, a complete RDF file in which semantics of this specific concept is declared.

(http://en.wikipedia.org/wiki/Fragment_identifier)

Samalla logiikalla voitaisiin sanoa , että jos kirjan URN on http://urn.fi/URN:ISBN:978-951-51-0337-6, niin http://urn.fi/URN:ISBN:978-951-51-0337-6#chapter5  ei suinkaan viittaa kyseisen kirjan luvun 5 alkuun, vaan identifioi kyseisen luvun. Eli URI-syntaksin soveltaminen sellaisenaan URN-järjestelmässä merkitsisi useiden perinteisten tunnistejärjestelmien katteen perustavaa laatua olevaa laajentamista sekä tunnuksen rakenteen muuttamista. ISBN:llä voitaisiin tunnistaa myös kirjan kaikki osakohteet – tosin vain silloin, kun dokumentin tiedostomuoto sallii fragmentin käytön.

URN-järjestelmän kannalta fragment voidaan saada ongelmattomaksi kahdella tapaa. Helpompi tapa on todeta, että URN-järjestelmässä fragment ei ole osa tunnistetta eikä siis identifioi mitään. Tällöin edellä olevan esimerkin ”#chapter5” osoittaisi URN-järjestelmässä vain sen, mistä luku 5 alkaa. Tätä näkemystä ei kuitenkaan haluttu hyväksyä, koska se on URI-syntaksin vastainen. Vaihtoehdoksi esitetään, että URN-tunnuksissa ei käytettäisi fragmenttia, vaan f-koodia, joka näyttäisi samalta kuin URI fragment, mutta jonka soveltamisesta ja merkityksestä sovittaisiin erikseen jokaisella URN-nimialueella. Niinpä esimerkiksi ISO:n julkaisujen tunnistestandardeista ISBN voisi tukea f-koodin käyttöä, toisin kuin ne tunnisteet jotka eivät koske manifestaatioita, kuten ISSN ja teosten tunnisteet.

Tätä kirjoitettaessa vaikuttaa siltä, että f-koodiin perustuva kompromissi kelpaa kaikille.

URI query on vielä fragmenttiakin ongelmallisempi tapaus.  Queryn avulla voidaan lähettää palvelimelle erilaisia pyyntöjä. Esimerkiksi Kongressin kirjaston SRU-palvelimelta voidaan tehdä haku

http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=dinosaur

Tulosjoukossa oli 17.11.2014 2068 viitettä. Mutta onko tuo yllä oleva URI tämän tulosjoukon tunniste, ja jos on, mitä se tarkoittaa? Miten otetaan huomioon se että tulosjoukko muuttuu aina kun kirjastoon tulee uusi dinosauruksia käsittelevä julkaisu tai kun jokin teos poistetaan? Ja miten pitkäikäinen on URL jossa on mukana mm. ohjelmiston nimi ja standardin versio? Voidaan tietenkin sanoa että tietokantahakuihin ei ole järkevää soveltaa URI syntaksia, mutta tämäntyyppiset rajaukset eivät ainakaan helpota sen ymmärtämistä, mikä queryn rooli tunnisteena ylipäätään on.

URN-järjestelmässä URI queryn avulla on tarkoitus siirtää resoluutiota koskevia tarkempia ohjeita resoluutiopalvelimelle. Esimerkiksi URN-tunnusta seuraava query ”?s=I2C&p=DC” voisi kertoa palvelimelle asiakkaan haluavan identifioitua julkaisua koskevat kuvailevat metatiedot Dublin Core –formaatissa, jolloin palvelin generoisi URN:n pohjalta sopivan SRU-haun. Olisi absurdia sanoa että kun ISBN:n perään lisätään tuo yllä oleva merkkijono, olemme luoneet tunnisteen ko. julkaisun Dublin Core –tietueelle. Mutta juuri näin RFC 3986:n eli URI syntaksin mukaan tapahtuu. Sen vuoksi URN-syntaksin uusin versio linjaa, että URN-tunnuksissa ei käytetä queryä vaan q-koodia, joka ei ole tunniste. Q-koodin soveltamisesta tulee sopia URN-nimialuekohtaisesti, mikä on kömpelöä, mutta toisaalta esimerkiksi kaikki ISO:n tunnistestandardit voisivat soveltaa samoja periaatteita. Tämäkin kompromissiratkaisu vaikuttaa hyväksyttävältä.

Samaan aikaan toisaalla…

Tätä kirjoitettaessa ei ole vielä täysin varmaa, pystyykö IETF uusimaan URN-syntaksin. Pidän sitä kuitenkin todennäköisenä. Mutta jos IETF hukkaa etsikkoaikansa, URN-järjestelmä mitä todennäköisimmin modernisoidaan jossakin muualla. Tämä ei olisi ensimmäinen kerta kun pysyvän tunnisteen vastuuorganisaatio vaihtuu: alun perin IETF:ssä kehitetty Handle system siirtyi hiljan International Telecommunications Unionin (ITU, www.itu.int/) vastuulle. Handleen perustuvaa DOI:ta (http://www.doi.org/) hallinnoi puolestaan International DOI Foundation. ITU on perustanut IDF:n ja joidenkin muiden toimijoiden kanssa (mutta ilman IETF:n myötävaikutusta) Digital Object Numbering Authority (DONA) –organisaation edistämään pysyvien tunnusten ja erityisesti Handle-järjestelmään käyttöä.

On ironista että IETF syntyi aikanaan mm. sen vuoksi että ITU ei pystynyt kehittämään Internet-standardeja riittävän nopeasti. Pysyvien tunnisteiden osalta roolit näyttävät vaihtuneen, ja URI:t ovat vaikuttaneet tähän merkittävästi. Uskon kuitenkin että URN-järjestelmää kyetään jatkossa modernisoimaan käyttäjien tarpeiden mukaisesti. Muuta vaihtoehtoa ei oikein ole, koska URN-järjestelmää ja muita pysyviä tunnisteita käytetään laajalti. Ne auttavat esimerkiksi kansalliskirjastoja ja muita digitaalisia arkistoja ylläpitäviä tahoja hallinnoimaan tehokkaasti elektronisia aineistoja. EPIC (European Persistent Identifier Consortium) toteaa:

Resolution systems enable client software to go from an identifier to current state information about the identified object, such as where and how to access the object. Such identifiers can persist over changes to the identified object, such as changes in its location(s), ownership, and other attributes, persistence that is vital for maintaining data integrity over time.

(http://www.pidconsortium.eu/?page_id=74)

Kun pysyvillä tunnisteilla saavutetaan kannattajien mukaan näin merkittäviä eroja, vastustajien leirissä niistä ei nähdä olevan juuri mitään hyötyä. Tämän kuilun ylittäminen vaikuttaa URNBIS-kokemusteni mukaan lähes mahdottomalta. Mutta URL-osoitteiden lyhytikäisyydestä kertovat tutkimukset vahvistavat sitä käsitystä, että aika on – kirjaimellisesti – meidän puolellamme.

 

Kirjoittajan yhteystiedot

Juha Hakala, erityisasiantuntija
Kansalliskirjasto
PL 26, 00014 HELSINGIN YLIOPISTO
Sähköposti: juha.hakala[at]helsinki.fi

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.