Asiakirjojen yksilöinti, löytäminen ja siirrettävyys

Asiakirjojen yksilöinti, löytäminen ja siirrettävyys 17.3.2006 Esa Paakkanen Esa.Paakkanen@uku.fi Kuopion Yliopisto

SISÄLLYSLUETTELO 1 Johdanto...3 2 Erityyppiset tunnisteet...4 2.1 Nimipalvelu...4 3 URI...5 3.1 Asiakirjan siirtäminen...5 4 URL...6 4.1 Yksilöinti...6 4.2 Asiakirjan löytäminen...6 4.3 Asiakirjan siirtäminen...6 5 URN...7 5.1 Yksilöinti...7 5.2 Asiakirjan löytäminen...7 5.3 Asiakirjan siirtäminen...8 5.4 Miten nimipalvelut voidaan hoitaa?...8 6 OID...10 6.1 Yksilöinti...10 6.2 Asiakirjan löytäminen...10 6.3 Asiakirjan siirtäminen...10 7 Tunnisteiden tallennuksesta...11 7.1 RDF...11 8 Loppusanat...12 2

1 Johdanto Terveydenhuollon organisaatioiden käyttöön tarvitaan järjestelmä, jolla asiakirjat (ja muiden objektien) yksilöivät tunnisteet voidaan luoda. Lisäksi tarvitaan järjestelmä, jossa tunnisteen perusteella voidaan hakea (lisää) tietoa tunnisteella yksilöitävästä objektista. Terveydenhuollon tuottamien asiakirjojen yksilöinnissä on otettava huomioon seuraavat seikat: Asiakirjoja tuotetaan n. 500.000.000 /vuosi Asiakirjojen säilytysaika on 10 100 vuotta Asiakirjat siirtyvät elinkaaren aikana Muuttumattomuus ja alkuperäisyys on pystyttävä todentamaan Asiakirjoihin on päästävä aina käsiksi Käytettävien koodistojen versioita on kyettävä hallitsemaan Tässä selvityksessä käydään läpi neljän eri tekniikan hyviä ja huonoja puolia. Kustakin tekniikasta on eritelty omiksi alaluvuikseen yksilöinti, asiakirjan löytäminen ja asiakirjan siirtäminen. Yksilöinti alaluku käsittelee sitä, miten ko. tekniikan avulla saadaan yksilöityä asiakirja. Asiakirjan löytäminen alaluvussa pohditaan millaiset välineet ko. tekniikka tarjoaa asiakirjan löytämiseksi. Asiakirjan siirtäminen alaluku käsittelee asiakirjan siirtämisestä (omistaja/sijainti) aiheutuvien ongelmien ratkaisua ko. tekniikalla. Sisältö tiivistettynä: OID yksilöi, mutta kattavia/toimivia OID tunnusten resoluutiopalveluita ei ole. URL tunnisteena ei ole kestävä ratkaisu: sen viittaama dokumentti voi vaihtua. URN yksilöi dokumentin, mutta URN resoluutiopalvelut ovat vielä kehitysvaiheessa. 3

2 Erityyppiset tunnisteet Tunnisteita on kahta eri laatua: 1. tyhmiä tunnisteita 2. älykkäitä tunnisteita Kumpaakin käytetään avaimena, jolla tunnistettavan kohteen muut tiedot voidaan löytää tietovarastosta. Tyhmä tunniste on satunnainen merkkijono. Se ei sisällä tietoa objektista, jonka se yksilöi. Esim. 56236bgq246613 voisi olla tyhmä tunniste. Pelkkä tunniste toimii yksilöivänä tunnisteena, mutta sen perusteella ei voida suoraan saada mitään tietoa objektista, joten käytännössä tyhmät tunnisteet tarvitsevat aina jonkinlaisen resoluutiopalvelun ollakseen käyttökelpoisia. Älykäs tunniste sisältää itsessään yksilöitävästä objektista merkityksellistä tietoa; tietoa, jota ei tarvitse hakea mistään. Esimerkiksi sosiaaliturvatunnus on älykäs tunniste, koska siitä käy ilmi henkilön syntymäaika. OID on myös älykäs tunniste, vaikkei pisteellä eroteltujen tunnisteen osien merkitys aivan itsestään selvä olekaan. Älykkäät tunnisteet vaikuttavat viisaalta ratkaisulta: itse tunniste sisältää jo tietoa sen yksilöimästä objektista, joten kaikkea tietoa ei tarvitse kaivella esiin erilaisten palveluiden avulla. Tunnisteen älykkyys on kuitenkin myös sen hölmöys. Jos tunnisteen sisältämissä tiedoissa tapahtuu muutoksia, tunnisteen tulisi muuttua vastaamaan uutta tilannetta. Kuitenkin vanhaa tunnistetta on voitu käyttää monessa paikassa, eikä kaikkien viittauksien päivittäminen ole aina mahdollista. Virheellisiä viittauksia ei ainakaan terveydenhuollon dokumentteja käsiteltäessä katsota hyvällä. Alkuperäisten viittauksien päivittämisen sijaan voitaisiin myös suorittaa uudelleenohjaus. Alkuperäinen tunniste toimisi vain viitteenä uuteen tunnisteeseen, jolloin useamman omistaja tai sijaintimuutoksen jälkeen tuloksena olisi viittauksien ketju. Moinen viiteketju vaatisi automatisoidun tavan luoda ja ylläpitää viitteitä. Tyhmiä tunnisteita moiset muutokset eivät muuta. Ainoastaan tunnisteen viittaamat tiedot tietovarastossa päivittyvät. Ylläpidon kannalta älykkäät tunnisteet ovat parempia, varsinkin jos käsiteltävien tunnisteiden määrä on korkea (kuten tässä tapauksessa). Tyhmät tunnisteet vaativat yleensä keskitetyn rekisterin, kun taas älykkäiden tunnisteiden ylläpito voidaan hajauttaa (esimerkiksi DNS järjestelmä). 2.1 Nimipalvelu Nimipalvelun avulla voidaan objektin yksilötunnisteen perusteella selvittää objektin sijainti. Toisille tässä esitellyille tekniikoille on jo olemassa valmiina nimipalvelu (URL, nimipalvelu DNS), toisille määritykset sellaisen luomiseksi (URN), toisille ei kumpaakaan (OID). Nimipalvelu tulee erottaa rekisteristä. Rekisterin tehtävänä on ylläpitää tietoja jostakin objektista, esimerkiksi dokumentista kirjoittajat, dokumentin luontipäivämäärä jne. 4

3 URI Elektronisten dokumenttien jakelun, haettavuuden ja löydettävyyden varmistamiseksi tarvitaan kaksi erillistä lähtökohtaa. Dokumentilla tulee olla sekä nimi että osoite. URI (Uniform Resource Identifier) on merkkijono, abstraktin tai fyysisen resurssin identifioimiseksi. Resurssi on jotakin joka on identifioitavissa (yleensä dokumentti tai sen osa). URI on joko nimi (URN) tai paikannin (URL), mahdollisesti jopa molempia. URL ja URN ovat URIn erikoistapauksia. Yleisesti URI on muotoa: <scheme>:<scheme specific part> missä <scheme> on jokin http://www.w3.org/addressing/schemes sivulla luetelluista mahdollisuuksista. Tunnetuin ja eniten käytetty skeema on HTTP (HyperText Transfer Protocol). Nimi erottaa (identifioi) asiakirjan kaikista muista asiakirjoista, joten sen tulee olla pysyvä ja ainutlaatuinen. Osoite ilmoittaa asiakirjan sijainnin. Osoite voi vaihtua, joten sitä ei voida käyttää yksilöinnissä. Tarvitaan siis menetelmä dokumentin nimeämiseksi ja sen sijainnin selvittämiseksi. Tällaisen menetelmän tarjoavat URN (Uniform Resource Name) ja URL (Uniform Resource Locator), jotka yhdessä muodostavat URI nimisen kokonaisuuden. 3.1 Asiakirjan siirtäminen Asiakirjan sijainnin vaihtuminen voidaan ilmaista myös HTTP protokollan Redirectstatuskoodilla 301 (Moved Permanently). Se ilmaisee URIn viittaaman resurssin siirtyneen pysyvästi uuteen osoitteeseen. Jatkossa resurssiin viitattaessa tulisi käyttää yhtä palvelimen palauttamista osoitteista. Tällöin resurssin siirryttyä toiseen osoitteeseen, uudelleenohjaus hoidettaisiin alkuperäisen osoitteen web palvelimen avulla. Jokaisen uuden siirron jälkeen ko. web palvelimeen tulisi ohjelmoida uudelleenohjaus uuteen osoitteeseen. 5

4 URL URL:n (Uniform Resource Locator) käyttäminen yksilöintitunnuksena vaikuttaa hyvältä idealta: sama tunniste toimii sekä yksilöivänä että osoittaa asiakirjan sijainnin. Periaatteessa järjestelmä olisi toimiva, mutta käytännössä törmätään muutamaan ongelmaan. 4.1 Yksilöinti Dokumentti voitaisiin yksilöidä organisaation alle sille sopivan hierarkkisen rakenteen alle, esimerkiksi http://www.jokufirma.fi/jarjestelma01/dokumentit#52531 Tunniste annettaisiin kullekin uudelle dokumentille sen omistajan tai käyttötarkoituksen mukaan. 4.2 Asiakirjan löytäminen URL kertoo resurssin sijainnin. joten on mahdollista, että tietyssä osoitteessa oleva resurssi muuttuu. URL kertoo dokumentin (fyysisen) sijainnin. URL voi olla joko absoluuttinen tai suhteellinen. Luvun 5.1 esimerkki on absoluuttinen URL. Suhteellinen URL olisi (luvun 4.1 esimerkistä lainaten) dokumentit#52531 4.3 Asiakirjan siirtäminen Suurin ongelma elektronisiin dokumentteihin viittaamisessa on osoitteiden URL (Uniform Resource Locator) pysyvyys tai paremminkin pysymättömyys. Dokumentti voi elinkaarensa aikana sijaita useissa eri osoitteissa ja tietyssä osoitteessa voi olla useita eri dokumentteja. Keskeistä onkin pyrkiä käyttämään pysyviä URL:ja; jos dokumentti on kerran sijoitettu tiettyyn osoitteeseen, sen tulisi käyttää samaa osoitetta koko elinkaarensa ajan. Lisäksi useimmat palvelut on toteutettu erilaisilla tietokantaratkaisuilla ja selaimessa näkyvä URL voi olla ainutkertainen ja muuttua joka hakukerralla. Asiakirjan siirtyessä toiseen fyysiseen sijaintipaikkaan sen vanha osoite voidaan asettaa viittamaan uuteen osoitteeseen. Tästä voi kuitenkin olla seurauksena pitkäkin ketju viittauksia. Tämmöisen palvelun ylläpito tulisi ajan myötä käymään erittäin raskaaksi. URL:n puutteet viittausmekanismina on tiedostettu jo pitkään, ja IETF:n (Internet Engineering Task Force) työryhmät ovat tehneet ehdotuksia yleisemmän ja pysyvämmän viittausmekanismin luomiseksi. Erityistä huomiota on kiinnitetty sijainnista riippumattoman nimeämiskäytännön luomiseen. Siitä käytetään nimitystä URN, Uniform Resource Name. Yksinkertaistaen URNia voi verrata kirjoissa käytettyihin ISBN numeroihin. Tietoverkon resurssin URN pysyy samana vaikka sen URL muuttuisi. Lisää URNista on luvussa 5. 6

5 URN URN on eräänlainen "kuori", joka sallii identifiointiin käytettyjen järjestelmien, esimerkiksi tässä tapauksessa OIDin hyödyntämisen. URN tunnuksen rakenteen määrittelevän Internet standardin (RFC2141, http://www.ietf.org/rfc/rfc2141.txt). Sen mukaan URN koostuu kolmesta osasta: 1. Merkeistä "URN:". Jokainen URN tunnus alkaa näin; tarkoituksena on helpottaa URN tunnuksen löytämistä rakenteettomista dokumenteista. Täysin luotettavaksi URN tunnusten tunnistusta ei tällä keinolla kuitenkaan saada, koska dokumentti voi sisältää muita URN tunnuksia (viittauksina tekstissä tms.)urn tunnuksia ja ASCII tekstissä ei ole mitään keinoa osoittaa mikä URN kuuluu juuri asianomaiselle julkaisulle. 2. NID eli Namespace Identifier. Koodi joka identifioi URN tunnuksena käytetyn tunnistejärjestelmän. 3. NSS eli Namespace Specific String. Varsinainen ID tunnus (kuten ISBN) sijoitetaan tähän osaan. 5.1 Yksilöinti URN (Uniform Resource Name) nimeää jonkin objektin, resurssin, joka voi olla kokonainen dokumentti, kuva, dokumentin osa, mikä tahansa nimettävissä oleva asia. Dokumentille annettava URN tunnus on uniikki ja pysyvä. URN ei milloinkaan muutu, jos julkaisun sisältö ja nimi pysyvät samana. Jo kertaalleen annettua URNtunnusta ei milloinkaan anneta toiselle objektille. URN on myös yksikäsitteinen, yksi URN ei voi kuulua kuin yhdelle ainoalle resurssille. Yhdellä resurssilla voi kuitenkin olla useampikin URN. URNissa on kaksi osaa: nimityyppi ja tyyppikohtainen tarkennin. URNit ovat muotoa <URN> ::= "urn:" <NID> ":" <NSS> missä<nid> on Namespace Identifier, joka kertoo mitä koodausta URN käyttää. Arvona voi olla esimerkiksi OID. Vastaavasti NSS on Namespace Specific String, merkkijono, joka noudattaa annettua NID:tä, joka OIDin tapauksessa olisi siis OIDtunniste. URN tunnusten generointi olemassa olevista tunnuksista on tunnuksen syntaksin ansiosta erinomaisen helppoa. Esimerkki 5. URN URN:OID:1.2.237.341.11 5.2 Asiakirjan löytäminen URN ei kerro suoraan nimeämänsä resurssin sijaintia, vaan tarvitaan erillinen resoluutiopalvelu, joka sisältää tiedon URNin nimeämän resurssin sijainnista (URL). Usein sama dokumentti onkin saatavissa useista eri paikoista (URL) ja kehittynyt resoluutiopalvelin osaa valita käyttäjän kannalta sopivimman sijainnin. Luonnollisesti yhdellä resurssilla voi olla useampia URNeja, mutta URN viittaa aina vain yhteen 7

resurssiin. URN työryhmä on määritellyt paitsi URN:n syntaksin, myös menetelmät joilla URNresoluutio nykyisessä Internetissä tapahtuu. URN tunnukset sinänsä eivät oleta mitään verkon toiminnasta tai resoluutiopalvelujen sijainnista. URNin toimintaperiaate on tiivistettynä seuraavanlainen: Kun asiakasohjelma saa käsiteltäväkseen URNin, se kysyy ensin joltain lähellä olevasta palvelimesta (esimerkiksi nimipalvelimesta, jollainen on aina saatavilla), mistä se voisi löytää resoluutiopalvelimen tämäntyyppiselle URNille. Saatuaan vastauksen asiakasohjelma ottaa yhteyttä sopivaan resoluutiopalvelimeen, joka ottaa URNin ja palauttaa joko URL:n tai itse dokumentin. Nykyiset selaimet eivät osaa ilman lisäosia hakea URNien perusteella tietoa. 5.3 Asiakirjan siirtäminen Ensinnäkin dokumentin sijainti voi muuttua kuinka usein hyvänsä, kunhan resoluutiopalvelin pysyy ajan tasalla. Toiseksi, vaikka resoluutiopalvelin poistuisi käytöstä, tämä mekanismi sallii myös muiden resoluutiopalvelinten käytön. Jos resoluutiopalvelinten löytämiseen käytetään nimenomaan Internetin nimipalvelua (DNS, Domain Name Service), on kyseessä ns. NAPTR URN protokolla. Se on ensimmäinen URN toteutus, josta on jo olemassa prototyyppejä. 5.4 Miten nimipalvelut voidaan hoitaa? URNien laajamittainen käyttöönotto vaatii resoluutiopalvelinten perustamisen sekä muutoksia asiakasohjelmiin ja nimipalveluun (DNS). Etenkin nimipalvelun muuttaminen on työlästä, koska se on erittäin kriittinen osa Internetin protokollaperhettä, eikä siinä voida sallia toimintahäiriöitä. Tästä syystä URNit ovat edelleenkin prototyyppiasteella, vaikka niitä on kehitelty jo vuosia. URN työryhmät haluavat tehdä huolellista jälkeä. URN järjestelmä on pyritty rakentamaan niin, että resoluutiopalvelun rakentaminen olisi helppoa. Resoluutiopalvelu antaa dokumentin URN tunnuksella dokumentin viitetiedot, sijaintitiedot tai dokumentin itsensä. Riippuu järjestelmästä, käyttäjän oikeuksista ja myös dokumentista, voidaanko haluttu palvelu toimittaa. URN tunnusten resoluutio voidaan toteuttaa erilaisilla menetelmillä. Tämä riippumattomuus toteutustekniikoista takaa yhteensopivuuden myös tulevaisuuden tekniikoiden kanssa. Käyttäjälle tämä on yksinkertaista, mutta tarvittava tekninen infrastruktuuri on kaikkea muuta kuin yksinkertainen. Onneksi suurin osa tarvittavasta teknologiasta (DNS järjestelmä) on jo olemassa. Globaalin URN resoluutiopalvelun ylin taso on Resolution Discovery Service (RDS), palvelu jonka avulla verkosta löydetään palvelin, joka kykenee avaamaan halutun URN tunnuksen. Tarkoitus on pystyttää RDS palvelut osoitteisiin urn.net ja uri.net. Internet Assigned Names Authority (IANA) tallentaa URN resoluutiopalveluiden edellyttämät nimipalvelun osoitetiedot näihin järjestelmiin. Internet nimipalvelun (Domain Name Service, DNS) luonteen mukaisesti nämä tiedot leviävät periaatteessa kaikkialle verkkoon. Oikean URN resoluutiopalvelun paikallistaminen ei siis ole 8

riippuvainen RDS nimipalvelimesta, vaikka tarvittavat tiedot tallennetaankin Internetnimipalveluun sen kautta. Tarvittavan URN resoluutiopalvelimen/ palvelimien löytämisen menetelmät vaihtelevat paljon identifikaatiojärjestelmästä riippuen. Perusjako on tyhmien ja älykkäiden tunnisteiden välillä. Globaalin URN resoluution kannalta on haasteellista, että monet identifiointitunnukset ovat tyhmiä eivätkä kerro dokumentin julkaisupaikasta mitään. Tällöin resoluutiopalvelimen löytäminen voi olla vaikeaa, ellei ole käytettävissä globaalia tietokantaa, jonka kautta URN tunnukset voidaan muuntaa sijaintipaikoiksi. URN resoluutiopalvelua ei kannata rakentaa eikä julkaisua identifioida URNtunnuksella tai muutenkaan, ellei aineistoa ole tarkoitus säilyttää pitkään. Merkittävin aluevaltaus on se, että keväällä 2002 MPEG21 standardin kehittäjät valitsivat URNtunnusten käytön. URN standardoinnin valmistuttua kesäkuussa 2002 voidaan olettaa URN tunnusten suosion kasvavan edelleen. URN resoluutiopalvelun edellyttämät sinänsä yksinkertaiset lisäpiirteet on jo rakennettu nimipalvelinsovelluksiin; esimerkiksi BIND ohjelmassa URN resoluution edellyttämät ominaisuudet ovat olleet jo neljän vuoden ajan. Tältä osin Internetverkon infrastruktuuri on siis kunnossa. Valitettavasti IANA ei ole vielä rakentanut Resolution Discovery Service palvelimia, minkä vuoksi nimipalvelusta ei löydy URN resoluutiopalveluiden tietoja. Todennäköisesti IANA:n viivyttely johtuu siitä, että he odottavat tarvittavien standardien valmistumista. URN järjestelmä on pyritty rakentamaan niin, että resoluutiopalvelun rakentaminen olisi helppoa. Nykyisille WWW selaimille on rakennettu URN resoluutiota varten lisäohjelmia selaimiin. Suurinpana käytännön esteenä onkin ollut URN standardoinnin keskeneräisyys ja jaettujen URN tunnuksien vähäisyys. Deutsche Bibliothek soveltaa tilapäisratkaisuna HTTP Redirect lähestymistapaa, jossa WWW selaimeen ei tarvitse asentaa laajennuksia, vaan resoluutio tapahtuu palvelinpäässä. 9

6 OID ISO Object IDentifier on yleiskäyttöinen objektien yksilöintiin tarkoitettu määrittely. 6.1 Yksilöinti OID tunnisteen avulla asiakirja voidaan yksilöidä kansainvälisellä tasolla, mutta tällä hetkellä tunnisteella ei voida hakea tietoa asiakirjasta. Kahdella eri asiakirjalla ei voi olla samaa OID yksilöintitunnistetta. Asiakirjan osiin viittaaminen voidaan järjestää ko. objektin tunnisteen alla juoksevalla numeroinnilla. 6.2 Asiakirjan löytäminen OID määritys ei itsessään sisällä OID tunnisteiden resoluutioon liittyviä asioita. Periaatteessa olisi mahdollista rakentaa palvelu OID tunnusten käsittelyyn, mutta tällä hetkellä ei ole olemassa käyttökelpoista ja kattavaa järjestelmää. Verkkotunnusten resoluutioon käytettävä DNS sopisi OID tunnisteiden resoluutioon, mutta se vaatisi laajennuksia DNS määrittelyyn. Tunnisteiden selvityksen tulisi toimia ainakin niin päin, että jos tiedetään dokumentin OID tunniste, sen avulla voidaan hakea dokumentista lisää tietoa (metatietoa) sekä dokumentin sijainti, josta itse dokumentti voidaan noutaa tarkasteltavaksi. 6.3 Asiakirjan siirtäminen OID tunniste on ns. älykäs tunnus. OID tunnisteella yksilöidyn asiakirjan siirtäminen toiseen arkistoon ei periaatteessa riko tunnuksen oikeellisuutta, jos asiakirjan haltija ei vaihdu. Kuitenkin jos objektin haltija vaihtuu, tunnus pitäisi päivittää. Muutoin OIDtunnisteiden hierarkian merkitys häviää. 10

7 Tunnisteiden tallennuksesta Identifiointitunnuksia voidaan käyttää joko ulkoisessa (external) tai sisäisessä (embedded) metadatassa. Jälkimmäisessä tapauksessa identifiointitunnus on lisättävä identifioitavaan julkaisuun, edellisessä se tallennetaan osaksi tunnistetietoja. Ulkoista metadataa tallennettaessa perusvaatimus on, että tallennukseen käytetyssä formaatissa on paikka tunnisteelle. Kaikki dokumenttiformaatit eivät tarjoa yhtä hyviä mahdollisuuksia identifiointitunnuksien tallentamiseen. ASCII tekstissä on samantekevää, minne tunnus laitetaan, koska indeksointisovellus löytää sen kaikkialta yhtä huonosti. Jos artikkeli esimerkiksi kertoo URN tunnuksista ja sisältää useita esimerkkejä ja linkkejä, indeksointisovellus ei voi tietää mikä URN on "oikea". Monet dokumenttiformaatit ovat indeksointiohjelmille outoja, eikä niitä voida indeksoida lainkaan. Tällöin ainoa tallennustapa, josta on edes jotakin hyötyä, on tunnuksen tallentaminen tunnistetietoihin. Kuvaformaattien osalta tilanne voi olla vielä pahempi: identifiointitunnusta ei voi tallentaa kuvankäsittelyohjelmalla kuvan päälle, mutta ei tunnusta ei voi välttämättä tallentaa myöskään kuvan tekstimuotoiseen nimiöön. HTML ja XML ovat onneksi rakenteisina tekstiformaatteina hyvin soveltuvia metadatan tallennukseen. Jos URN on sijoitettu HTML dokumentin tekstiosaan, WWW indeksit pystyvät indeksoimaan sen samaan tapaan kuin minkä tahansa termin, ja dokumentti löytyy edellyttäen että WWW indeksi Google tai muu vastaava palvelu on dokumentin sijainnin suhteen ajan tasalla. Jos URN on tallennettu XMLtai HTML dokumentin nimiöön, eli HTML:n tapauksessa META kenttään, toistaiseksi vain harvat hakupalvelut indeksoivat sen. Teknisesti indeksointi olisi helppoa, mutta ongelmana on metadatan huono laatu. 7.1 RDF RDF (Resource Description Framework) on XML kieleen nojautuva tapa tallentaa dokumentin kuvailutiedot. Perusideana RDF:ssä on erilaisten metatietojen yhdenmukaistaminen samanlaiseen muotoon tai alustaan (framework). Tällä pyritään tekemään mahdolliseksi metadatan käsittely ohjelmallisesti. Tämän vuoksi RDF on yksi mm. W3C:ssä tapahtuvan Semantic Web kehityksen perusosista. 11

8 Loppusanat Nykymäärittelyiden mukainen OID tunniste on yksilöllinen kansainvälisellä tasolla. Yksilöllisyys säilyy, vaikka yksilöintitunnisteiden luonti hajautettaisiin OIDhierarkian alle, kullekin juuresta vastaavalle taholle. Hajauttaminen helpottaa tunnisteiden luontia, mutta vaikeuttaa yksilöintitunnisteen perusteella tapahtuvaa dokumentin löytämistä. Jos tarkastellaan tilannetta terveydenhuollon dokumenttien säilytysaikavaatimuksien kannalta, esitellyistä vaihtoehdoista URN vaikuttaa kestävimmältä ratkaisulta, mitä tulee dokumenttien löytämiseen. OID tunniste voitaisiin liittää osaksi URNtunnistetta, jolloin yksilöintitunnusten luonti tapahtuisi hajautetusti OID hierarkian mukaan, ja tunnisteen perusteella tapahtuva dokumenttien etsiminen URNresoluutiopalveluiden avulla. DNS järjestelmä taipuisi teoriassa vastaamaan OIDresoluution tarpeita, mutta vaatisi muutoksia nykyisiin DNS määrittelyihin. generaattoreilla kuten tosite(solmuluokka)sarja, aika (vuosi/päivä) ja juokseva numero. 12

Lähteet Tämän selvityksen pohjana on käytetty seuraavia lähteitä: http://herkules.oulu.fi/isbn951425242x/html/x1354.html http://herkules.oulu.fi/vili/viittaus/ http://herkules.oulu.fi/vili/viittaus/uri.html http://koti.mbnet.fi/~thales/tarkmerk.htm#q tyhma http://www.csc.fi/lehdet/atcsc/atcsc3 98/urn.html http://www.lib.helsinki.fi/julkaisuala/urn.htm http://www.lib.helsinki.fi/meta/id.html#tunnus http://www.lib.helsinki.fi/meta/id.html#urn http://www.w3.org/protocols/rfc2616/rfc2616 sec10.html#sec10.3 (HTTP Redirect) Yo. URLit osoittivat vielä 13.3.2006 oikeisiin dokumentteihin. 13