You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Useimmilla verkkojulkaisuilla ei ole perinteistä tunnusta eikä myöskään PIDiä, vaan tunnuksen kaltainen verkko-osoite (Uniform Resource Identifier, URI), josta käytetään yleisesti nimitystä Cool URI. Se määriteltiin vuonna 2005 Internet-standardissa RFC 3986[i]. ”Cool” viittaa siihen, ettei URI koskaan muutu. Sen pysyvyys taataan uudelleenohjaamalla (redirect) se tarvittaessa julkaisun muuttuneeseen URL-osoitteeseen. Uudelleenohjausmahdollisuuden ansiosta on mahdollista väittää, että verkossa, toisin kuin kirjahyllyssä, sijainti ja tunnus ovat yhdistettävissä.

Internetin teknisistä standardeista vastaava Internet Engineering Task Force erotti alun perin verkko-osoitteet ja tunnisteet toisistaan. Tunnistejärjestelmä oli RFC 2141[ii] -standardissa vuonna 1997 määritelty URN (Uniform Resource Names). Functional requirements for Uniform Resource Names (RFC 1737[iii]) määritteli URN-tunnuksille joukon vaatimuksia, joita verkko-osoitteiden olisi mahdotonta tai ainakin vaikeaa täyttää. URN-tunnuksien tuli olla muun muassa pysyviä, ainutkertaisia, skaalautuvia, teknologiariippumattomia ja niiden piti olla yhteensopivia perinteisten tunnistejärjestelmien kanssa. URL-osoitteiden (Uniform Resource Locators) ei tarvinnut olla mitään näistä.

RFC 3986 yhdistää URN-tunnukset ja URL-osoitteet URI-sateenvarjon alle. Sen mukaan jokainen URI on tunniste, joten sähköpostiosoite ja puhelinnumero, joista voidaan muodostaa URI-tunnukset tel:<puhelinnumero> ja mailto:<email-osoite>, ovat toimijan tunnuksia ISNI-, ORCID- ja HETU-tunnuksen ohella. Käytännössä näin ei kuitenkaan ole, koska puhelinnumero ja sähköpostiosoite eivät ole ainutkertaisia eivätkä pysyviä. Toimijalla voi olla useita muuttuvia sähköpostiosoitteita, ja sama osoite voidaan myöhemmin antaa jollekulle toiselle.

Jotta RFC 3986 olisi vakavasti otettava tunnistestandardi, siinä olisi pitänyt rajata tunnuksiksi kelpaavien URI-tunnusten joukkoa, mutta tätä kautta olisi ennen pitkää päädytty takaisin alkuperäiseen URN–URL -jaotteluun.

World Wide Web Consortium (W3C) on antanut RFC 3986:n julkaisemisen jälkeen ohjeita siitä, miten tunnuksena käytettävät URIt tulisi muodostaa. Vuonna 2007 julkistetun Cool URIs for the Semantic Web -ohjeen[iv] mukaan niiden pitäisi olla lyhyitä sekä helposti muistettavia ja hallinnoitavia. Ohje paljastaa W3C:n käsityksen URI-tunnusten elinkaaresta:

Once you set up a URI to identify a certain resource, it should remain this way as long as possible. Think about the next ten years. Maybe twenty.

10–20 vuotta on aivan liian lyhyt ikä ikuiseksi tarkoitetulle pysyvälle tunnisteelle, mutta pitkä URL-osoitteelle. W3C-ohjeen luvussa viisi on kahdeksan Cool URI-esimerkkiä, joista seitsemän tuotti jo 2018 HTTP 404 -virheen. Niiden elinkaari on siis ollut lyhyempi kuin yllä ohjenuoraksi asetettu 10–20 vuotta. Tätä kirjoitettaessa ainoa edelleen toimiva URI antaa tulokseksi identifioidun henkilön tietojen sijaan vain hänen tuolloisen työnantajaorganisaationsa julkaisuluettelon, joten sekään ei enää toimi oikein.

Kahdeksan URIn perusteella ei voi tehdä yleisiä päätelmiä URI-tunnusten elinajanodotteesta. Mutta Herbert Van de Sompel ja hänen tutkimusryhmänsä ovat analysoineet tieteellisten julkaisujen viitteiden avulla Cool URIen pitkäikäisyyttä, ja osoittaneet että sekä sisältönyrjähdys eli viitatun dokumentin muuttuminen[v] että linkkimätä eli viitattujen dokumenttien katoaminen[vi] ovat yleisiä ongelmia. Mitä vanhempi linkki, sitä todennäköisempää on, ettei se enää toimi. Tavallisen käyttäjän kannalta Cool URI -tunnisteiden suurin puute on se, etteivät ne ole “cool”. 

Kirjastojen kannalta RFC 3986 -standardin merkittävin periaatteellinen haaste on, että Cool URIt eivät ota perinteisiä tunnistejärjestelmiä huomioon (niiden roolia verkkoaineistojen identifioimisessa ei edes mainita RFC 3986:ssa). Verkossa julkaistun kirjan ISBN saa verkko-osoitteesta kilpailevan tunnuksen, joita on yhtä monta kuin kirjasta on verkossa kopioita. Kirjastonhoitaja, joka tallentaa e-kirjan kirjastonsa julkaisuarkistoon, tuskin ajattelee antaneensa kirjalle samalla uuden tunnuksen, jonka tulisi olla ISBN:n tavoin pysyvä ja ainutkertainen. Mutta lukija, joka viittaa kirjaan, voi käyttää viitteessä ISBN:n sijasta URL-osoitetta. Van de Sompel kumppaneineen löysi 600.000 viitettä, joissa julkaisulla oli DOI, mutta julkaisuun viitattaessa käytettiin sen URL-osoitetta. Tämä hankaloittaa sen selvittämistä, mitä julkaisua tai julkaisun versiota on käytetty lähteenä varsinkin sen jälkeen, kun URL on lakannut toimimasta linkkimädän tai sisältönyrjähdyksen vuoksi.

Kenties keskeisin kaikkia luotettavia tunnistejärjestelmiä yhdistävä kriteeri on hallinnointi. Jos kuka tahansa saa antaa tunnuksia mille tahansa, syntyy kaaos. Tutkijan ORCID-tunnuksen korvaaminen hänen sähköpostiosoitteellaan saattaa olla toimiva ratkaisu jonkin aikaa. Mutta pysyvän ja toiminnallisen tunnuksen vaatimuksia sähköpostiosoite ei täytä.

Tunnusten ja niiden toiminnallisuuden pysyvyys ei riipu vain tunnistejärjestelmästä ja sen teknisestä toteutuksesta. Myös tunnuksia jakavan ja/tai niiden toiminnallisuudesta vastuun kantavan organisaation tulee olla pitkäikäinen ja sillä pitäisi olla pysyvä, sopimukseen tai lakiin perustuva vastuu säilyttää identifioidut julkaisut. Tällöin pysyvien tunnistejärjestelmien toiminnallisuuden takuumiehiksi tulevat julkaisijoiden rinnalle erilaiset keskitettyjen palvelujen tarjoajat ja kansalliskirjastojen ja kansallisarkistojen kaltaiset vakaat organisaatiot, joilla on vankka kokemus myös perinteisistä tunnistejärjestelmistä. Kaupallisten toimijoiden antamien tunnisteiden pysyvyys ei riipu esimerkiksi kustantajan elinkaaresta, jos kustantajalla on yhteistyökumppanina kansalliskirjaston kaltainen organisaatio. Tällä tavoin on toimittu jo pitkään esimerkiksi kirjojen osalta: suomalaiset kustantajat antavat ISBN-tunnukset julkaisuilleen itse, mutta kirjojen pysyvästä säilyttämisestä vastaavat Kansalliskirjasto ja muut vapaakappalekirjastot.

Merkittävä pitkän aikavälin ongelma Cool URI -tunnusten pysyvyyden kannalta on se, että Internet-domaineja ei voi omistaa. Niitä voi ainoastaan vuokrata muutamaksi vuodeksi kerrallaan. Jos ja kun esimerkiksi nokia.com -domainin vuokrasuhde päättyy ja hallintaoikeus siirtyy toiselle toimijalle, kaikki tämän domainin Cool URI-tunnukset joko lakkaavat toimimasta tai linkittyvät vääriin dokumentteihin.

Verkkoarkistot ratkaisevat tämän ongelman vain osittain. Niiden URI-linkit vievät aina samaan dokumenttiin, mutta vain niin kauan, kun kyseinen arkisto on tuotannossa. Eikä arkistosta löytyvä verkkosivu aina vastaa alkuperäistä. Jos sivu muodostuu useista tiedostoista, ne on voitu haravoida eli noutaa arkistoon WWW-palvelimelta tai -palvelimilta eri aikoina. Tällöin arkiston tarjoama verkkosivu voi olla yhteensopimattomista palasista koottu tilkkutäkki, kuten sääennuste, jonka sääkartta ja teksti kuvaavat eri päiviä.

Internet-nimipalvelun (Domain Name System, DNS) tarjoaman perustan epäluotettavuudesta huolimatta Cool URI -tunnuksia voidaan käyttää menestyksekkäästi rajatuissa kohteissa ainakin jonkin aikaa. Esimerkiksi paikkatietojen tunnisteena sitä on käytetty jo vuosia, paikkatiedon yhteiskäyttöä tukevan INSPIRE-direktiivin[vii] nojalla ja määräyksestä. Huolellisesti suunnitellen ja tunnuksia hallinnoiden nämä Cool URI -tunnukset saadaan elämään vuosikymmeniä. Mutta nämä tunnukset ovat teknologiariippuvaisia ja toimivat enintään siihen asti, kun verkon perusteknologiat kuten HTTP-protokolla muuttuvat. Tähän voi mennä kymmeniä vuosia tai pidempäänkin, mutta tuskin satoja vuosia. Varmuutta edes HTTP:n kaltaisen perusteknologian säilymisestä ylöspäin yhteensopivana vuosikymmenien tai -satojen ajan ei ole. Julkaisulle teos- tai manifestaatiotasolla annetun tunnuksen pitäisi kuitenkin säilyä vähintään yhtä kauan ja mieluummin pitempäänkin kuin julkaisun yksittäisten manifestaatioiden –  eli periaatteessa pysyvästi.

Joissakin järjestelmissä URI-tunnuksien sijaan on lupa  tai suoranainen vaatimus käyttää Internationalized Resource Identifier – eli IRI-tunnuksia. IRI-määritys RFC 3987[viii] julkaistiin heti RFC 3986:n jälkeen, ja se laajentaa URI-tunnuksissa käytettävissä olevan suppean merkkivalikoiman Unicodeksi. Jokainen URI on siis myös IRI, mutta jos tunnuksessa käytetään RFC 3986:ssa kiellettyjä merkkejä, se on IRI.

IETF yritti päivittää RFC 3987:n ajan tasalle 2010-luvun alussa, mutta yritys epäonnistui, koska IRI-tunnuksiin liittyviä teknisiä ongelmia ei pystytty ratkaisemaan. Sen vuoksi pysyvissä tunnisteissa pitäisi käyttää vain URI-tunnuksissa hyväksyttyjä merkkejä, vaikka IRI-tunnusten käyttö olisi periaatteessa mahdollista. Esimerkiksi emojeja sisältävä IRI olisi tunnuksena ihmiskäyttäjille hankala, koska emoji-symbolien ulkonäkö vaihtelee käyttöjärjestelmästä riippuen. Vielä tärkeämpi peruste  merkkivalikoiman rajoituksille on ”Unicode confusables”, eli merkit, joiden ulkoasu on sama tai lähes sama. Jos esimerkiksi Handle-tunnuksen takaliitteessä oleva latinalainen c korvataan kyrillisellä c-kirjaimella, tunnus näyttää käyttäjälle samalta kuin ennen, mutta muokattu tunnus resolvoituu eri dokumenttiin kuin alkuperäinen[ix]. Verkko-osoitteissa näitä huijauksia torjutaan siten, että selaimet eivät hyväksy verkko-osoitteita joissa sekoitetaan eri kirjaimistoja. Handle.Net-resolveriin on teknisesti mahdollista rakentaa vastaava ominaisuus, mutta Handle-standardi ei aseta mitään rajoituksia eri merkistöjen rinnakkaiskäytölle samassa tunnuksessa. 

Cool URI -tunnukset eivät siis täytä kirjastojen tunnisteille asettamia pysyvyyden, ainutkertaisuuden ja hallinnoitavuuden vaatimuksia. Siksi niitä käsitellään tässä ohjeessa jatkossa vain kursorisesti.


[i]     https://tools.ietf.org/html/rfc3986

[ii]    https://tools.ietf.org/html/rfc2141

[iii]    https://tools.ietf.org/html/rfc1737

[iv]    http://www.w3.org//2001/sw/sweo/public/2007/cooluris/

[v]    https://doi.org/10.1371/journal.pone.0167475

[vi]    https://doi.org/10.1371/journal.pone.0115253

[vii]   INSPIRE mahdollistaa paikkatietojen yhteentoimivuuden yli organisaatioiden ja valtioiden rajojen. Esimerkiksi ilmanlaatuun ja vesistöihin liittyvät ympäristövaikutukset eivät tunne rajoja, joten tietojen tulee olla yhteentoimivia, laadukkaita ja helposti saatavilla, jotta päätöksiä voidaan perustaa niiden varaan. Kyseessä on EU-direktiivi, jonka tavoitteena on Euroopan yhteisön paikkatietoinfrastruktuuri. INSPIRE tulee sanoista Infrastructure for Spatial Information in the European Community. (Katsottu 4.1.2021, https://www.maanmittauslaitos.fi/kartat-ja-paikkatieto/paikkatietojen-yhteentoimivuus/inspire/mika-inspire)

[viii]   https://tools.ietf.org/html/rfc3987

[ix]    http://websec.github.io/unicode-security-guide/visual-spoofing/


  • No labels