URI, URN, URL

W3C innleder sine filosoferinger over temaet med å peke på at Internettet består av eller inneholder et (stort) sett med punkter med innhold. Dette innholdet er vanligvis filer av en eller annen sort. Disse punktene identifiserer vi ved hjelp av stringer som vi generelt kaller URI'er.

Disse punktene kan vi tenke oss å identifisere ved å angi deres nøyaktige adresse eller ved å angi et entydig navn. Det siste forutsetter at vi har en mekanisme for å oversette navn til adresse, akkurat som vi slår opp i en indekstabell, en adressebok. Vi kan sammenligne URN med et navn og URL med absolutte adresser. Hvis vi forutsetter at det finnes en oversettelse fra navn til adresse så ser vi at det er en fordel å bruke navn (URN) fordi ressursen kan flyttes eller dupliseres uten at navnet må endres. Vi kan referere ressursen uten å vite nøyaktig hvor den er til en hver tid.

Tradisjonelt har vi benyttet begrepet URL for å angi en slik adresse, sammen med metoden for å få tilgang til adressen. Vi er vant til å skrive:

  http://www.it.hiof.no/a/b/index.html

Vi har da angitt at fila a/b/index.html på maskinen med adresse www.it.hiof.no kan nås via protokollen http (Hyper Text Transfer Protocol).

Begrepet URL er fjernet fra W3C's definisjonsapparat. Det vil si at det brukes ikke lenger for å definere andre mekanismer. URL'er oppfattes som et spesialtilfelle av samlebegrepet URI.

URN er en annen form for URI. En URN er altså et navn på en ressurs i internettrommet som ikke trenger være identifiserbart ved sin adresse, men det skal alltid være mulig å finne den ved hjelp av navnet og et eller annet program eller adressebok.

W3C har følgende figur for å forklare forholdet mellom begrepene

En URN kan inkludere en adresse (og blir da en URL), men den trenger ikke gjøre det.

Vi kan tenke oss en URN slik:

  urn:bigcatalog:borres_UR_side

Der vi altså har sagt at vi har en urn, at vi bruker en oppslagsmekanisme bigcatalog og leter etter en ressurs som heter borres_UR_side. Kanskje den ligger på denne adressen:

  http://www.it.hiof.no/~borres/dw/ur/p-ur.html

Formalia

En URI beskriver både lokale filstier og adresser på internettet. Det vil si at følgende er eksempler på lovlige URI'er:

   http://www.it.hiof.no/~borres/dw/ur/p-ur.html
   a/b.txt
   ftp://a.b/c/d.htm
   ../../a/b/c.html#slutten

Det grunnleggende oppsettet for en URI er slik:

Det som står i hakeparenteser, [], er valgfritt. De svart tegnene, :#, er nødvendige dersom den aktuelle delen skal være med.

En absolutt URI har en skjema-del. Andre er relative. URI'er sorteres også etter hvorvidt de er lukkede(opaque), eller hierarkiske.

Opaque

En lukket, opaque, URI er absolutt og har en skjemaspesifikk del som ikke begynner på /. Eksempel:

   mailto:ole.brumm@100mskogen.no

Hierarkiske

URI'er som ikke er lukkede er altså hierarkiske. En hierarkisk URI er derfor enten en absolutt URI med en skjemaspesifikk del som begynner på /, eller en relative URI. Hierarkiske URI'er er nærmere beskrevet slik:

"authority"-delen er enten registerbasert eller serverbasert.

Serverbaserte

Vi står da tilbake med den gruppen vi forholder oss oftest til, hierarkiske, serverbaserte URI'er. De er beskrevet slik:

Vi ser at

er ekspandert til

En path er enten relativ eller absolutt. Den er absolutt dersom den begynner med /.

La oss se på de enkelte delene:

scheme

Schemes er navngitt etter forskjellige protokoller. Den vanligste i det vi gjør på Internettet er: http. Andre er: ftp, mail, news, gopher, mailto, telnet.

Det er opptil de programmene som skal tolke en URI hvordan de vil behandle URI'en, men sammenhengen mellom scheme og overføringsprotokoll er ganske fast.

user-info

Vi kan oppgi et brukernavn, og eventuelt et passord, når vi skal sette opp tilgang til en fil.

host

Dette er navnet til den tjeneren vi vil bruke. Navnet oversettes til en absolutt IP-adresse av en navnetjener.

port

Portnummerete er en angivelse av hvilken port tjenerprogramvaren skal bruke til å betjene oss.

path

Dette er filstien på den aktuelle tjeneren.

query

Her kan vi formulere en parameterliste som skal behandles.

fragment

Et internt anker på den siden, filen, vi får tak i.

Eksempler

Hvis vi betrakter beskrivelsen ovenfor så passer den med måten vi behandler filer og stier i Unix/Linux. Vi vet imidlertid at når vi arbeider med MSWindows stiller det seg litt annerledes. For det første er tegnet som skiller elementene i en sti \ og ikke /. For det andre er absolutte filstier angitt som f.eks. c:\a\b.txt og ikke /a/b.txt.

Den web-siden du ser på nå kan jeg nå på følgende måter fra MSIE. Når jeg jobber mot en harddisk som er tilgjengelig via filebrowseren:

   f:\html\dw\ur\p-ur.html
   file:\\f:\html\dw\ur\p-ur.html
   file:///f:/html/dw/ur/p-ur.html

Når jeg aksesserer siden vi http-protokollen:

   http://www.it.hiof.no/~borres/dw/ur/p-ur.html
   http://www.it.hiof.no/~borres\dw\ur\p-ur.html

Mozilla liker ikke de variantene som bruker \.

Det er ingen grunn til å bruke \ i hverken relative eller absolutte URI'er, enten du arbeider på din egen harddisk eller du lager linker til nettressurser.

En komplett form er slik:

   http://www.it.hiof.no:80/~borres/dw/ur/p-ur.html

Vi kan kutte ut portnummeret fordi vi stoler på at tjeneren forholder seg til den konvensjonen at http betjenes over port 80.

   http://www.it.hiof.no/~borres/dw/ur/p-ur.html

Vi kan også kutte ut http:// siden den vanligste protokollen er http, og denne forutsettes av de fleste nettlesere dersom ingen protokoll er angitt.

   www.it.hiof.no/~borres/dw/ur/p-ur.html

Dersom vi vil bruke GET-protokollen og legge til en query til en URI:

   http://www.it.hiof.no/~borres/cgi-bin/ajaxtest/shakereturn.py?sonette_num=12