Misforstått: URI

URIer er en av hjørnestenene i webbens arkitektur. Alle websider har en adresse, en oppskrift for å hente en spesifik webside. Opprinnelig het disse URLer fordi de lokaliserte websider på nettet.

F.eks. denne sonen har URI’en http://web-arkitektur.origo.no/ Det er sonens kanoniske identifikator. Jeg kan gi URIen til andre og de vil kjenne den igjen som en URL og skjønne at den peker på noe: URIen er også sonens URL—man kan skrive det inn i en nettlos, og så forsøker den å hente innholdet. Voilá.

Men arkitekturen bygger også på at man kan identifisere hva som helst - ikke bare websider.

En vanlig misforståelse er at URIer angir nettopp websider. Det gjør de ikke. De fleste URIer på webben i dag gjør det (stort sett websider, bilder, CSS og javascript), men noen URIer gjør det ikke.

Min oppfattning av URIer er at de kan identifisere hva som helst: For eksempel bygger XML Namespaces på URIer. Et XML Namespace er ikke en webside eller en skjemadefinisjon, men et abstrakt konsept om et unikt navneområde for XML tagger. Det er ingen forventning om at man skal kunne putte inn en namespace URI i en braoser og få f.eks. et skjemadokument. Namespace URIen er primært for å identifisere namespacet fra andre namespaces. Det er en identifikator.

JSP Taglib URIer har samme funksjon. De er der kun for å identifisere et tag library fra et annet tag library. Her forventes det heller ikke (strengt tatt) at man må eller kan hente noe hvis man går til et taglib URI. Taglib URIer er ikke nødvendigvis URLer.

På denne måten kan URIer brukes til å identifisere ting uten at man må sette opp ett nettsted for å servere innhold. Ting som ikke kan servere innhold. For eksempel mennesker, bygninger, produkter, lyspærer, og stoler kan i teorien gis egne URIer og refereres til.

Andre som kjenner til de samme tingene kjenner også disse tingenes URIer og kan dermed kjenne igjen URIen hvis vi ser den. XML prosessorer som kjenner igjen et xml namespace URIer. JSP prosessorer som kjenner igjen taglib URIer.

RDF er et språk som har tatt dette til sitt hjerte. RDF er et språk som lar deg uttrykke kunnskap om relasjoner mellom ressurser. URIer brukes her for å identifisere personer, firmaer, blogger og blogginnlegg, og attributter på disse: navn, overskrifter, forfattere osv. Man kan uttrykke at en person er forfatter til en bloggentry, at personen har navnet sånn og sånn, og at han kjenner disse andre personene, og at de har disse navnene. Her og der kommer det også “rdfs:seeAlso” som sier at her er en URI som forteller deg mer om denne ressursen.

Hva er poenget med URIer som ikke lar seg “hente”? For en webutvikler kan det være meningsløst. Det skjønner jeg. Men i softwareutvikling kan det brukes som en generisk måte å referere til ting. Primærnøkler? Hvorfor ikke? Sannsynligvis vil alle dataene leve med samme scheme (http har grei semantikk…) og et hostnavn hvor dataene “lever” (i kanonisk forstand) Det som gjenstår er “path” til dataene. På samme måte som på en web server er pathene dine en uendelig stor tomt som skal deles opp.

Poenget er at det gir universell adresserbarhet. Hvemsomhelst i verden kan referere til tingene dine, presist og nøyaktig.

Hvorfor velge en annen identifikator enn URIer?

Kommentarer

Hei, bra innlegg! Er helt enig i at URI må sees på som en identifikator, ikke som nettadresse. Jobber selv med utvikling av en søkemotor hvor vi bruker URI til å identifisere hvert enkelt dokument som puttes inn. På den annen side er en URI rimelig lang, og tar en del plass i minnet, så når man driver med ytelseskritiske systemer (som f.eks en søkemotor) må man unngå overhead med slike identifikatorer, og sitter stort sett igjen med et heltall som beste alternativ.

Vi gjør dette slik at URI’er lagres på utsiden av søkemotoren, og så har vi en mapping mellom disse og søkemotorens interne id’er. På denne måten får vi mulighet til å slå opp ved hjelp av URI (som er lesbart og kan gi mye mer mening og kontekst enn et tall), mens vi begrenser minnebruken i selve søkemotoren ved å bruke heltall. For å spare ytterligere minne gjør vi en MD5 hash av URI’en og lagrer kun denne i minne. Dette blir nødvendig når man skal forsøke å ha en liste over mange millioner ressurser i en effektiv (oppslag på O(1)) datastruktur. Ulempen med en hash er da naturlig nok at oppslaget kun fungerer én vei, men det er ikke noe problem i vårt tilfelle.

Så det å ha flotte beskrivene URI’er, gir alltså ikke poeng hos dere? ;)

Jo, det var en litt forenklet beskrivelse, vi har mulighet til å liste ut alle items og uri’en deres… Vi lagrer hash’en i minnet, og hele uri’en samt andre data på disk. Hvis ikke kunne vi jo bare holdt oss til gode, gamle heltall…

Det er fornuftig å tenke på URI’er som abstrakte identifikatorer som ikke nødvendigvis refererer til en nettverksressurs – men i rdf-sammenheng der det ofte gror igjen en skog av uri’er, synes jeg de er med på å gjøre filene tungleste.

Jeg skulle ønke det fantes en uri-notasjon som var speilvendt slik at vi fikk det mest spesifikke elementet først. For mennesker vil jo en artikkeltittel eller personnavn være mer enn tilstrekkelig informasjon. Det ville gjøre urier mer scanbare i filer som inneholder svært mange identifikatorer – slik som f.eks. rdf.

http://peoples.tv/user/show/erik_monsen http://en.wikipedia.org/wiki/Rete_algorithm

kunne blitt

erik_monsen:show:user:peoples.tv/http Rete_algorithm:wiki:en.wikipedia.org/http

Kanskje det er bare meg – men jeg sliter alltid bittelitt med å scanne meg fram til hvilket element som faktisk er referert. Det har aldri vært noe problem når jeg stort sett møter dem enkeltvis i adresselinja mi – men snart, i den semantiske web-framtiden …

Alexander, bra kommentar. Det er akkurat slik jeg ser for meg det bør være. Internt i et system har man numeriske ID’er. Men hver gang man skal ut av systemet bør man eksponere URI’er og ikke ens interne ID’er. Dette henger sammen med kule URI’er, fordi det gir utviklere en mulighet til å frikoble et eksternt API (som URI’ene er) fra de interne numeriske ID’ene, slik som dere gjør. Det tillater (til en viss grad) omstrukturering av de interne strukturene uten at man må forandre på alle URIene.

Angående reverse URI’er ser jeg ikke helt poenget… Få deg en syntax highlighter eller noe som leser ting baklengs! :-P

URI-skogen du nevner er jeg kjent med ja. Jeg fant forleden en liste over de mest populære URI’er i bruk i semantic web.

Og så må jeg jo nevne dbpedia for å oppdage kule URI’er (annen betydning av ordet “kul”)

Annonse