Page History

...

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 sähköpostiosoitteella hänen sähköpostiosoitteellaan saattaa olla toimiva ratkaisu jonkin aikaa. Mutta pysyvän ja toiminnallisen tunnuksen vaatimuksia sähköpostiosoite ei täytä.

...

Merkittävä pitkän aikavälin ongelma Cool URI :en -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.

Verkkoarkistojen Verkkoarkistot ratkaisevat tämän ongelman vain osittain. Niiden URI-linkit vievät aina samaan dokumenttiin, mutta vain niin kauan kuin , kun kyseinen arkisto on tuotannossa. Lisäksi Eikä arkistosta löytyvä verkkosivu ei välttämättä aina vastaa alkuperäistä, koska jos . 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 , kuten 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 :t -tunnukset saadaan elämään vuosikymmeniä. Mutta Cool URI:t nämä tunnukset ovat teknologiariippuvaisia ja toimivat vain kunnes enintään siihen asti, kun verkon perusteknologiat kuten HTTP-protokolla muuttuvat. Tähän voi toki mennä kymmeniä vuosia tai pidempäänkin, mutta emme voi olla varmoja säilyykö tuskin satoja vuosia. Varmuutta edes HTTP:n kaltainen ydinteknologia tuettuna satoja vuosia. Sen kuitenkin tiedämme, että julkaisulle 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 , ja mieluiten pidempäänkin, eli 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 on turvallisinta 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 tunnisteena tunnuksena ihmiskäyttäjille hankala, koska emoji-symbolin symbolien ulkonäkö voi vaihdella vaihtelee käyttöjärjestelmästä riippuen. Vastakkainen ongelma tälle Vielä tärkeämpi peruste  merkkivalikoiman rajoituksille on ”Unicode confusables”, eli merkit, joiden ulkoasu on sama tai lähes sama. Niiden avulla verkon käyttäjä voidaan huijata vääriin verkko-osoitteisiin^[ix].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.

...