Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

7.3 URN-tunnuksen rakenne

URN-tunnuksessa on oltava kolme osaa, jotka erotetaan toisistaan kaksoispisteellä:

...

Namespace Specific String (NSS), resurssin tunnus. Esimerkiksi ISBN-numero.

ISBN-tunnuksesta 978-951-895951-477661-1 5 saadaan näin URN URN-tunnus URN:ISBN:978-951-51-7661-5, joka voidaan esittää hyperlinkkinä https://urn.fi/URN:ISBN:978-951-895951-477661-15. Koska tunnuksen alkuun lisättävät tiedot ovat aina vakioitalisättävä merkkijono on kunkin nimialueen sisällä aina sama, URN-tunnukset voidaan luoda ohjelmallisesti olemassa olevasta perinteisestä tunnuksesta. Mutta jos olevista perinteisistä tunnuksista. Jos URN ei ole toiminnallinen, URN-tunnuksen sen tarjoama lisäarvo rajoittuu on tunnuksen globaaliin ainutkertaisuuteen ja siihen, että tunnus on tunnistettavissa jopa tekstin keskeltäglobaali ainutkertaisuus ja sovellettavuus tiedonhaussa.

URN-tunnukseen voidaan lisätä vapaavalintaisia komponentteja. Ne ovat URI-syntaksin Fragment-ominaisuutta vastaava F-komponentti, URI Query -ominaisuutta vastaava Q-komponentti sekä R-komponentti, josta lisää tuonnempana tässä luvussa.

Nimialueiden tunnukset ovat ainutkertaisia ja ne identifioivat pysyvästi URN-tunnuksessa käytetyn tunnistejärjestelmän. Kullakin nimialueella noudatetaan kyseisen tunnistejärjestelmän pelisääntöjä, jotka koskevat muun muassa tunnusten rakennetta ja identifioinnin kohteita. Esimerkiksi URN:ISBN-nimialueella toimitaan ISBN-standardin ja käyttöoppaan mukaisesti. URN siis tukee olemassa olevia tunnistejärjestelmiä eikä kävele niiden yli, kuten URI. Maaliskuuhun 2023 mennessä nimialueita on rekisteröity noin 80[ii]. Vain murto-osa näistä nimialueista kuuluu perinteisille bibliografisille tunnisteille tai ylipäätään julkaisujen tunnisteille. Mutta jos Jos on tarpeen identifoida esimerkiksi mittalaitteessa oleva anturi, sen voi tehdä . Tarvittava nimialue on käyttäen IETF:n rekisteröimä kehittämää Internet of Things -standarditunnuslaitetunnistetta, jolle jonka nimialue on varattu nimialue URN:DEV (https://www.rfc-editor.org/rfc/rfc9039.html).

URN-tunnuksen NSS-osioon tallennetaan varsinainen tunnus. Niiden tarvitsee olla ainutkertaisia vain oman nimialueensa sisällä. Jos URN-tunnuksen saavalla dokumentilla on Tunnus 978-951-51-7661-5 voi siis toistua esimerkiksi DEV-nimialueella. Jos URN-tunnuksen saavalla dokumentilla on jo olemassa standarditunnus, tulee käyttää sitä . Toisin sanoen: jos on käytettävä URN-tunnuksessa. Jos kirjalla on ISBN, URN-tunnuksen NSS-osion on oltava tuo ISBN-tunnus sellaisenaan, siihen ei saa lisätä mitään eikä siitä saa ottaa pois mitään. Jotkin nimialueet tekevät paikallisista tunnuksista globaaleja ja ainutkertaisia

URN-tunnuksina paikalliset tunnukset muuttuvat globaaleiksi ja ainutkertaisiksi. Esimerkiksi kansalliskirjastojen omien sisäisten tunnistejärjestelmien vanhoista NBN-tunnuksista syntyy helposti verkossa käytettäviä saadaan URN:NBN-tunnuksia . Tämä edellyttää vain ohjelmallisesti, lisäämällä paikalliseen tunnukseen URN:NBN:-merkkijonon ja maakoodin lisäämistä paikalliseen tunnukseenmerkkijono ja maakoodi. URN:NBN-tunnuksia voidaan luoda myös ohjelmallisesti.

Esimerkiksi URN:NBN-tunnuksessa

...

NSS on Kansalliskirjaston sisäinen koneellisesti luotu digitoidun aineiston tunnus fd2010-00003245, johon on lisätty Suomen maakoodi fi.

Tunnuksissa NSS-osiossa sallitut merkit määrittyvät sovelletun tunnistestandardin mukaan nimialuekohtaisesti, mutta RFC 8141:n asettamissa rajoissa. Esimerkiksi ISBN-nimialueella sallittuja ovat vain käytetään ISBN-standardissa määritellyt merkit. Jos jokin niistä sattuisi olemaan URN-standardissa kielletty, se pitäisi määriteltyjä merkkejä, jotka ovat kaikki RFC 8141:n mukaan sallittuja. DOI-nimialueella voi käyttää Unicode-merkkivalikoimaa, mutta URN-standardin kieltämät merkit pitää koodata ns. percent encoding -menettelyn avulla. Esimerkiksi välilyönnistä tulee koodattuna %20.

Jos Kun URN-tunnus esitetään hyperlinkkinä, merkkejä pitää soveltaa merkistöä koskevat myös URI-syntaksin standardin (RFC 3986) edellyttämällä tavallarajoitukset. URNURI-tunnuksissa ei esimerkiksi saa käyttää merkkejä ”?” ja ”#” sellaisenaan, koska niillä on URI-syntaksissa erityisrooli. Merkkiä ”?” seuraa aina URI query ja merkkiä ”#” URI fragment. URI-syntaksissa määritellyn Nämä ja muut erityisroolin omaavat merkit sekä periaatteessa kaikki ASCII-merkkivalikoiman ulkopuoliset merkit on esitettävä URI- ja URN-tunnuksissa hyperlinkeissä koodattuna[iii]. Tällöin esimerkiksi kysymysmerkistä tulee %3F ja #-merkistä %23.

Toisin kuin URI-syntaksin fragmentilla ja queryllä, URN-järjestelmän F- ja Q-komponenteilla ei ole roolia identifioinnissa (mistä syystä niille on annettu RFC 8141:ssä uudet nimet). Käytännössä tämä merkitsee sitä, että kirjan lukuun viittaavan F-koodin komponentin lisääminen URN:ISBN-tunnukseen ei muuta F-koodillista URN-tunnusta kyseisen luvun tunnukseksi. Siksi URN johon on lisätty fT-komponentti, kuten

http://urn.fi/URN:NBN:fi-fd2010-00003245#Luku2

identifioi edelleen saman julkaisun kuin edellä oleva yllä olevan esimerkin URN, mutta F-koodin komponentin avulla selain siirtää käyttäjän haluttuun kohtaan identifioidussa kirjassa luvun kaksi  alkuun sen jälkeen kun selain on noutanut julkaisun. F-komponentti osoittaa siis vain tietyn paikan identifioidun julkaisun sisällä. F-komponentti toimii tarkoitetulla tavalla vain silloin, kun linkki ohjautuu suoraan identifioituun julkaisuun eikä esimerkiksi laskeutumissivulle, kuten esimerkissä.

URN-määrityksessä F-komponentilla ei saa olla roolia identifioinnissa, koska se muuttaisi URN-määrityksessä F-koodilla ei saanut olla roolia identifioinnissa sen vuoksi, että se olisi muuttanut perinteisten tunnistejärjestelmien toimintaa. Jos tavallinen Kun URI koostuu ISBN-tunnuksesta jonka perään on lisätty kirjan lukuun kaksi viittaava fragmentti, ISBN muuttuukin tuon luvun muuttuu RFC 3986:n mukaan kirjan tunnuksesta luvun kaksi tunnukseksi. Mutta jos URN:ISBN-tunnukseen lisätään F-komponentti, identifioitu kohde on edelleen koko kirja, ja F-koodi osoittaa vain tietyn kohdan kirjassa.  koska F-komponentti ei ole osa URN-tunnuksen NSS-osiota eikä siis identifioi mitään.  

Q-komponentin URI Queryn avulla voidaan lähettää komentoja suoraan haluttua palvelua tarjoavaan kohdejärjestelmään kuten vaikkapa Melinda-tietokantaan. Tunnus on tällöin muotoa

...

Q-komponentti voi olla esimerkiksi tunnukseen perustuva SRU-haku, jolla noudetaan identifioitua julkaisua kuvaava MARC-tietue. Resolverin Voidakseen toimia palvelun tuottamisen välikätenä URN-resolverin pitää tietää, minkä tietokannan SRU-palvelimelle haun voi lähettää. Jos URN:ISBN-tunnukseen sisältyy suomalainen ISBN-tunnus, Melindan SRU-palvelin on sopiva kohde. Jos ISBN ei ole suomalainen, haun voi kohdistaa johonkin kansainväliseen yhteisluetteloon. 

Yksi URI-syntaksin oudoimmista piirteistä Perinteisten tunnistestandardien kannalta RFC 3986:n oudoin piirre on, että URI johon on lisätty Query, identifioi sen objektin joka haulla saadaan. ISBN saattaa siis Queryllä rikastettuna muuttua -tunnuksen ja URI queryn yhdistelmä identifioi haun tuottaman objektin. Query-haussa käytetty ISBN voi siis yllättäen muuttua kohdetietokannasta löydetyn, identifioitua kirjaa kuvaavan MARC-tietueen tunnukseksi. Tätä perinteisten tunnisteiden tunnistejärjestelmien toimialan hallitsematonta laajennusta oli tietenkin mahdoton hyväksyä URN-tunnistestandardissa. URI-syntaksi ei ota huomioon sitä, että asiakasohjelman ja kohdejärjestelmän välissä voi olla PID-tunnisteen resolverisovellus. Koska URI-syntaksiin ei sisälly mahdollisuutta lähettää komentoja resolverille, URN-tunnukseen lisättiin R-komponentti. Sen avulla voidaan resolverilta pyytää periaatteessa mitä vain, kuten lista identifioidun julkaisun nykyisistä tai vanhoista URL-osoitteista.

Esimerkkinä käytetty URN näyttää R-komponentin kera tältä:

http://urn.fi/URN:NBN:fi-fd2010-00003245?+<R-komponentti>

R-komponentin toteutus URN-syntaksissa on yhteismitallinen RFC 3986:n linjausten kanssa. Muilla PID-järjestelmillä on omat R-komponenttia vastaavat ratkaisunsa, mutta ne voivat olla yhteensopimattomia URI-syntaksin kanssa. Kun Handle- ja DOI-tunnistejärjestelmiin lisättiin R-komponenttia vastaava ominaisuus (10320/loc Handle type), tunnuksen ja lisäosan erotinmerkiksi valittiin @, koska se oli vapaa – sitä ei ollut hyödynnetty Handle-tunnuksissa. URI-syntaksin mukainen erotinmerkki ? oli jo käytössä.

PID-järjestelmiin ei olisi tarvinnut rakentaa näitä erillisratkaisuja, jos URI-syntaksi olisi ottanut resolverisovellusten tarpeet huomioon. Ne ohitettiin RFC 3986:tta kirjoitettaessa joko vahingossa tai ­tarkoituksella.­

7.4 URN-tunnistejärjestelmän palvelut ja niiden toteuttaminen

URN:n ja muiden PID-järjestelmien edellyttämiä resolvereita voidaan pitää ylimääräisenä askelena tunnuksen ja identifioidun resurssin välissä. Mutta resolverit voidaan nähdä myös keinona irrottaa resurssien tunnisteet ja sijaintipaikka toisistaan, samalla tavalla kuin kirjastot ovat perinteisesti erottaneet tunnisteet ja paikanmerkit (signumit). Verkossa kuten myös kirjastossa on toki mahdollista pitää aineisto samassa paikassa, ja luostarikirjastoissa kirjat olivat tätä varten kettingeillä hyllyissä kiinni. Internet-ajan kettinki on URI, koska se edellyttää resurssille annetun osoitteen pysymistä toiminnallisena.

Tässä esityksessä käsitellyistä tunnistejärjestelmistä ARK, Handle ja DOI käyttävät omaa, keskitetysti ylläpidettyä avoimen lähdekoodin resolveriohjelmistoa. URN-järjestelmässä yhteistä resolverisovellusta ei ole, mikä on haitannut tunnisteen käytön yleistymistä, sillä käyttäjien on pitänyt laatia resolverisovelluksensa itse. Eri URN-käyttäjäryhmien ja URN-nimialueiden tarpeiden erilaisuuden vuoksi ei ole varmaa, voisiko yhteinen ohjelmisto edes kelvata kaikille.

Kun Kansalliskirjaston resolveriohjelmiston uudistamishanke on päättynyt, ohjelmisto annetaan muiden kirjaston kehittämien sovellusten tapaan vapaasti käyttöön. Ellei joku muu toimija ehätä ensin, resolverista tulee ensimmäinen avoimen lähdekoodin URN-resolveri.

URN-järjestelmän tarjoamat palvelut ovat olleet ”kortilla”. Mutta Q- ja R-komponenttien avulla URN-tunnus voidaan linkittää paitsi identifioituun resurssiin itseensä, myös mihin tahansa kohteeseen joka jollakin tavoin liittyy kyseiseen resurssiin. Tämä luo mielenkiintoisia mahdollisuuksia linkitetyn datan kehittäjille. URL-osoitteiden korvaaminen tietueissa URN-tunnuksilla tulee myös helpottamaan linkkien ylläpitoa, koska resolverilla linkkien ylläpito on keskitettyä ja se voidaan myös automatisoida. Tämä on mahdollista, jos identifioitujen dokumenttien URL-osoitetiedot voidaan haravoida resolverille julkaisuarkistoista ja muista tallennusjärjestelmistä.

Q-komponentin tukeminen on teknisesti yksinkertaista. Asiakasohjelmassa suomalaisen kirjan URN:ISBN-tunnukseen voidaan lisätä Q-komponenttina SRU-standardiin perustuva hakulause. Resolverin tarvitsee vain lähettää Q-komponentti sellaisenaan Melindan SRU-palvelimelle, joka toimittaa halutun kirjan metatiedot asiakkaalle.

R-komponentin tukeminen on resolverille hieman hankalampaa. Edellisen esimerkin URN:ISBN-tunnukseen voidaan lisätä pyyntö noutaa identifioidun resurssin metatiedot MARCXML-formaatissa. URN-resolverin pitää muuntaa tämä R-komponentti Melindan SRU-palvelimelle lähetettäväksi hauksi.

ja siksi URI query korvattiin URN-tunnisteen Q-komponentilla, joka ei identifioi mitään. URI query ja Q-komponentti eroavat toisistaan myös siinä, että query alkaa merkillä "?", Q-komponentti merkkiyhdistelmällä "?=". URN-syntaksi on yhteismitallinen RFC 3986:n kanssa, mutta siihen oli pakko lisätä myös ominaisuus, jota URI-määrityksessä ei ole. 

URI-syntaksi ei ota huomioon sitä, että asiakasohjelman ja kohdejärjestelmän välissä voi olla PID-tunnisteen resolverisovellus. Koska URI-syntaksiin ei sisälly mahdollisuutta lähettää komentoja resolverille, URN-tunnukseen lisättiin R-komponentti. Sen erottaa tunnuksen NSS-osiosta merkkiyhdistelmä "?+". R-komponentin avulla haku voidaan kohdistaa resolverille. Siltä voidaan pyytää periaatteessa mitä vain, kuten lista identifioidun julkaisun kopioiden URL-osoitteista. Se, pystyykö resolveri vastaamaan itse vai pitääkö sen lähettää pyyntö edelleen johonkin muuhun tietojärjestelmään, riippuu muun muassa resolverille tallennetuista metatiedoista.

Esimerkkinä käytetty URN näyttää R-komponentin kera tältä:

http://urn.fi/URN:NBN:fi-fd2010-00003245?+<R-komponentti>

R-komponentin toteutus URN-syntaksissa on yhteismitallinen RFC 3986:n linjausten kanssa. Muilla PID-järjestelmillä on omat R-komponenttia vastaavat ratkaisunsa, mutta ne voivat olla yhteensopimattomia URI-syntaksin kanssa. Kun Handle- ja DOI-tunnistejärjestelmiin lisättiin R-komponenttia vastaava ominaisuus (10320/loc Handle type), tunnuksen ja lisäosan erotinmerkiksi valittiin @, koska se oli vapaa – sitä ei ollut hyödynnetty Handle-tunnuksissa. URI-syntaksin mukainen erotinmerkki ? oli jo käytössä.

PID-järjestelmiin ei olisi tarvinnut rakentaa näitä erillisratkaisuja, jos URI-syntaksi olisi ottanut resolverisovellusten tarpeet huomioon. RFC 3986 ohittaa ne todennäköisesti ­tarkoituksella.­

7.4 URN-tunnistejärjestelmän palvelut ja niiden toteuttaminen

PID-järjestelmien vastustajat pitävät tunnuksen resoluutiota ylimääräisenä askeleena käyttäjän ja identifioidun resurssin välissä. Mutta resolverit voidaan nähdä myös palvelutarjonnan välineenä ja keinona irrottaa verkkoresurssien pysyvä tunnus ja sijaintipaikka toisistaan, samalla tavalla kuin kirjastot ovat perinteisesti erottaneet julkaisujen tunnukset ja paikanmerkit (signumit). Kirjastossa on toki mahdollista pitää aineisto pitkään samassa paikassa, ja keskiaikaisissa luostarikirjastoissa kirjat olivat tätä varten kettingeillä hyllyissä kiinni. Webissä kettingin vastine on URI, koska se edellyttää resurssin osoitteen pitämistä toiminnallisena.

Jos kirjat olivat hyllyissä kiinni, kirjastolla oli vain rajoitetut mahdollisuudet palvelujen tarjoamiseen. Sama ongelma on URI-linkityksessä, koska se voi tarjota palveluita vain HTTP-protokollan asettamissa rajoissa. PID-tunnisteilla rajat asettaa resolvereiden tarjoama toiminnallisuus.

Q- ja R-komponenttien avulla URN-tunnistejärjestelmään voidaan lisätä palveluita periaatteessa rajattomasti. Resolveri voi itse tarjota palveluita tallentamiensa metatietojen avulla, ja se voi linkittää tunnuksen paitsi identifioituun resurssiin itseensä, myös mihin tahansa kohteeseen joka jollakin tavoin liittyy kyseiseen resurssiin. Tämä luo mielenkiintoisia mahdollisuuksia linkitetyn datan kehittäjille. URL-osoitteiden korvaaminen tietueissa URN-tunnuksilla tai muilla PID-tunnuksilla helpottaa linkkien ylläpitoa, koska resolvereilla linkkien ylläpito on keskitettyä ja se voidaan myös automatisoida.

Toistaiseksi resolvereiden palveluvalikoima on niukka, ja URN-resolvereiden tilanne on heikompi kuin muiden. Toisin kuin ARK- ja Handle-järjestelmillä, ei ole olemassa yhteistä URN-resolveria, vaan pelkästään URN:NBN-resolvereita on useita, eivätkä ne ole keskenään yhteismitallisia. Uusien palvelujen kehittämistä haittaa myös se, ettei R-komponentin syntaksia ja semantiikkaa ole vielä määritelty. Tämä kehitystyö pitää käynnistää, jotta standardisoinnin puutteesta ei tule pullonkaulaa. 

Uusien palveluiden tukeminen voi olla yksinkertaista, jos tarvittavat metatiedot ovat resolverilla. Jos käyttäjä haluaa tietää esimerkiksi jonkin julkaisun kaikkien kopioiden verkko-osoitteet, asiakasliittymä voi lähettää R-komponentin avulla resolverille vastaavan pyynnön. Resolveri palauttaa asiakkaalle halutut URL-osoitteet esimerkiksi HTML-sivuna.Ja jos resolverit kykenevät vaihtamaan tietoja standardirajapinnan kautta, osoitteita ja muita metatietoja voidaan myös vaihtaa resolvereiden kesken.

Tietojen hakuun muista järjestelmistä voidaan käyttää Q-komponenttia. Jos käyttäjä haluaa kotimaisen kirjan metatiedot, resolverille lähetettävään URN:ISBN-tunnukseen lisätään Q-komponenttina SRU-standardiin perustuva hakulause, jossa hakuehtona on kirjan ISBN. Resolveri muuttaa Q-komponentin URI  queryksi ja uudelleenohjaa haun Melindan SRU-palvelimelle, joka toimittaa kirjan metatiedot asiakkaalle.

R-komponentin ja Q-komponentin perusero on se, että resolveri vastaa pyyntöön oletusarvoisesti itse. Se voi kuitenkin välittää pyynnön eteenpäinkin. Jos resolverilta pyydetään identifioidun julkaisun metatiedot eikä sillä ole niitä, se voi muuttaa R-komponentin sopivan kohdejärjestelmän ymmärtämään muotoon, kuten SRU-hauksi. Jos kohdejärjestelmän tukema rajapinta muuttuu R-komponentin tarjoama toiminnallisuus vastaa Q-komponenttia. Niiden ero on se, että jos kohdejärjestelmän tukema rajapinta muuttuu esimerkiksi SRU:sta joksikin muuksi, R-komponenttia käytettäessä vain resolverilla tehtävää muunnosta R-komponentista hakulauseeksi pitää päivittää. Mutta jos käytetään Q-komponenttia, jonka resolveri aina toimittaa sellaisenaan suoraan kohdejärjestelmään, hakulauseeen päivitys pitää tehdä jokaisessa resolveria käyttävässä asiakasohjelmassa erikseen.URN-resolverilla voidaan tukea myös

ominaisuuksia, joita HTTP tai muut laajassa käytössä olevat Internet-protokollat eivät tue. Resolveri voi tallentaa saman resurssin kaikki URL-osoitteet, ja linkittää asiakkaan sellaiseen kappaleeseen, johon hänellä on käyttöoikeus. Resolverille voidaan tallentaa myös resurssin vanhat URL-osoitteet, joilla on merkitystä silloin kun aineisto on saatavissa enää verkkoarkistoista. Ja kun resurssi häviää verkosta, resolveri voi linkittää URN-tunnuksen resurssin pitkäaikaissäilytysjärjestelmään tallennettuun kopioonOn vaikeaa ennakoida, mitä palveluita ja missä järjestyksessä URN-resoluutiopalvelimiin tullaan lisäämään. Sama ongelma koskee myös muita PID-järjestelmiä; yksikään niistä ei ole julkistanut suunnitelmiaan. Palvelutarjonnan kehittämiseen liittyy myös laajempia kysymyksiä resolvereille tallennettavista ydinmetatiedoista sekä resolvereiden välisen tiedonsiirron rajapinnoista. Näitä haasteita pitäisi mahdollisuuksien mukaan ratkoa eri PID-järjestelmien yhteistyönä.

7.5 URN julkaisujen tunnisteena

URN perustuu olemassa oleviin tunnistejärjestelmiin, ja tämä erottaa sen muista PID-tunnistejärjestelmistä. Jos kirjalla on ISBN ja kirjalle annetaan URN, sen on oltava URN:ISBN. URN-tunnuksen osana olevaa ISBN:ää ei tarvitse muokata eikä päivittää. Toisin kuin DOI-pohjaisessa 13 merkin mittaisessa ISBN-A -tunnuksessa, myös vanha 10 merkin mittainen ISBN-tunnus kelpaa.

...