Skrevet af Tobias Hinnerup den 15. september 2006. Sidst redigeret den 27. juni 2003. © Alle rettigheder forbeholdt.
Altså har ejeren af den pågældende ressource enten besluttet at flytte den, eller slette den - det sidste kan muligvis retfærdiggøres, mens det første er en erkendelse af utilstrækkkelige overvejelser før ressourcens oprindelige oprettelse.
Rent teoretisk er der absolut ingen rimelige grunde overhovedet, til at ændre en eksisterende URI. I praksis er undskyldningerne endeløse - rækkende fra fysisk omplacering af filer til omfordeling af ansvar og arbejdsområder. Inden undskyldningerne forkastes, er det en god idé at undersøge de grundlæggende begreber der danner fundamentet for at væve et solidt net af links - det, vi i daglig tale og brug kender som World Wide Web.
Enkelte kender stadig begrebet under det tidligere, uformelle navn "Uniform Ressource Locator" (URL), på trods af at det har været udfaset siden 1998, og for de fleste er der ingen mystik i dét emne: URI er navnet for en henvisning fra en side på nettet, til en anden.
Arbejder man imidlertid professionelt med disse ting - altså, konstruerer og opretter URI'er, er det nødvendigt at dykke lidt dybere i tingene end som så: Det er i høj grad formålstjenstligt at vide hvad en URI er, samt hvordan og hvorfor den fungerer og er opbygget på en given måde.
Som det første ord, angives at en URI er universel. Det betyder, at en URI kan henvise til enhver ønskelig type ressource - det være sig et billede, en artikel, en film, et program eller noget helt tredie.
Betydningen af det er, at det ved konstruktion af en URI er nødvendigt at overveje om henvisningen til ressourcen skal angive dennes type - afhængigt af situationen, kan der tales for begge fremgangsmåder. Som hovedregel gælder, at ressoucens type kun skal indgå, såfremt denne kan forventes at have betydning for brugerens anvendelse af ressourcen.
http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl http://soeg.jubii.dk/res.asp?loc=dk&soegeord=Tobias+Hinnerup&submit.x=33&submit.y=14
Som eksempler på skidt gennemtænkt opbygning af en URI kan disse to fremhæves.
Det første der springer i øjnene er, at søge-ressourcen på NSF refereres med en angivelse af "cgi-bin" som en del af URI'en - men reelt har denne information ingen betydning hverken for en vilkårlig bruger eller ressourcen i sig selv. Umiddelbart indlysende er det også, at det i høj grad er tvivlsomt at teknologien CGI vil danne baggrund for NSF's søgefunktionalitet i al fremtid (hvorimod søgefunktionaliteten i sig selv efter al sandsynlighed vil have en enddog meget lang levetid) - og hvad betyder det for URI'en, at teknologien bliver skiftet?
Alene på baggrund af dette, vil de fleste kunne forudse at denne URI uvægerligt vil ændre sig - og enhver webmaster eller redaktør vil derfor naturligvis gøre sit bedste for at undgå at linke til denne ressource, og dermed undgå "linkrot" på sit eget site.
På det punkt er link nummer to meget mere pålideligt - det er ligeledes et link til en søge-ressource (mere specifikt et søge-resultat), men her uden angivelse af hvilken teknologi der driver søgningen. Til gengæld går en anden brøler igen i begge links:
Forkortelsens andet ord, angiver at der henvises til en ressource - men langt de fleste URI'er på nettet i dag, henviser rent faktisk til en fil, frem for en ressource. Det gør sig netop også gældende for de i eksemplet viste URI'er: Den ene refererer til filen odbrowse.pl og den anden til res.asp.
At ressourcen fysisk oprinder eller udspringer fra indholdet i en given fil er nærmest en selvfølge - men at referencen inkluderer filtypen er mildest talt en kapitalbrøler. En lynhurtig sammenligning vil komme til konklusionen, at den ene søgning er baseret på et Perl-script, og den anden på et ASP-script. Hvorvidt den ene løsning er bedre end den anden har utvivlsomt været årsag til megen diskussion i begge organisationer - og i høj grad er det tvivlsomt, at resultatet af denne diskussion har været endegyldigt: Med andre ord et der god chance for, at diskussionen senere vil blive taget op igen, og føre til et andet resultat.
Konsekvent kunne man forestille sig, at NSF en dag besidder større udvikler-kompetence i sproget PHP (der anvender filtypen .php) - hvorved URI til søge-ressourcen må ændres, og at Jubii's kommende generation af udviklere foretrækker C# under ASP.NET (der anvender filtypen .aspx) - hvorved også denne URI må ændres.
Nøjagtig samme overvejelse gør sig gældende, når der henvises til filer af typen HTML - de vil i vid udstrækning være udsat for at blive konverteret til dynamiske sider, hvorved deres filtype typisk ændres. Ønskes det at levere en ressource i et specifikt format, bør denne type-angivelse naturligvis fremgå af URI'en - men ikke som en filtype! Eksempelvis kan en dynamisk side (eksempelvis .asp) sagtens levere output i både XML, HTML og PDF format - og naturligvis ligesåvel billeder og film.
http://www.hinnerup.net/2002/articles/uri/pdf/
En format-specifik URI bør have en form der ligner denne, for at overholde det begrebsmæssige i at henvise til den mest muligt universelle ressource, samtidig med at sikre den størst mulige chance for persistens af henvisningen. Alt dette, mens ressoucen identificeres kortfattet, logisk og så entydigt som overhovedet muligt.
Sidst, og alt andet end mindst betydende, skal en URI identificere en ressource, for at give mening. Også her, er der masevis af faldgruber: såvel semantiske, syntaktiske, begrebsmæssige og kulturelle elementer har betydning for kvaliteten af en given URI.
http://www.hinnerup.net/Articles/URI/
Tag for eksempel den øverste af disse tre URI'er: For de fleste EU-borgere vil den forekomme sammenhængde og logisk konstrueret - men alligevel er den spækket med fælder. På det sproglige plan er den første kategorisering skrevet med stort begyndelsesbogstav, hvilket er i bedste fald er diskutérbart, idet der ikke er noget foranstående punktum. Den anden kategorisering, forkortelsen URI er skrevet med versaler. Logisk, hvis man kommer fra en kulturel baggrund hvor forkortelser skrives med store bogstaver, og logisk, hvis man i så fald er opmærksom på, at der er tale om en forkortelse.
Domæne-navne er i Domain Name Server (DNS) systemet ikke følsommme for versaler/minuskler - og en logisk videreførelse af dette vil være at resten en en URI overholder samme regel. Dette er imidlertid ikke altid ligetil at opnå: Webservere baserer hovedsageligt deres URI'er på det underliggende filsystem, og dermed bliver URI'ens opførsel afhængig af den pågældende servers operativsystems måde at håndtere filnavne (pt. skelner f.eks. Linuz/Unix systemer mellem store/små bogstaver, og Windows gør ikke).
For at skabe mindst mulig forvirring blandt brugere af en given URI - hvadenten disse er programmører eller regulære brugere - er det derfor rimeligt at vælge konsistent at bruge enten små eller store bogstaver i URI'er. Mest almindeligt brugt er små bogstaver, hvorfor dette er den stående anbefaling.
http://www.hinnerup.net/articles/uri/ http://www.hinnerup.net/articles/uri/2002/ http://www.hinnerup.net/articles/2002/uri/ http://www.hinnerup.net/2002/articles/uri/
I og med, at alle og enhver kan linke til en URI når denne er oprettet, bliver det absolut essentielt at den ikke ændrer sig over tid. Samtidig er det et uomtvisteligt faktum at verden i almindelighed, og herunder specielt sprogbrug og begreber, ændrer sig løbende.
Umiddelbart forekommer det som en logisk og anvendelig løsning at imødekomme denne foranderlighed med at underindele i daterede mapper, som i URI nummer 2. Løsningen er et skridt på vejen, men faktisk ikke optimal: Forklaringen på dette skal findes i lidt filosofering over betydningen af ord: URI nummer 2 kan udlæses til at betyde "det der i 2002 blev lavet med den betydning der i dag tillægges en artikel om URI'er. Tilsvarende kan URI nummer 3 tillægges betydningen "dagens betydning af en artikel, om det der i 2002 blev opfattet som URI'er". Konsekvent bliver den fjerde og sidste URI den mest holdbare, med betydningen "Det der i 2002 blev opfattet som en artikel om det der i 2002 blev opfattet som URI'er".
Kortfattet kan ovenstående sammenfattes som, at jo længere til venstre i en URI der forekommer en datering, jo længere levetid vil URI potentielt have.
Detaljeringsgraden af dateringen må være et resultat af en vurdering af den hastighed, hvormed de emner der er underliggende, ændrer sig. Er der eksempelvist tale om et månedligt nyhedsbrev, er det umiddelbart nærliggende at benytte en datering der løber månedsvist, er der tale om et dagligt tidsskrift bliver dateringen tilsvarende mere detaljeret.
http://www.hinnerup.net/2002/03/articles/uri/
Under iagttagelse af hvordan en bruger kunne finde på at "hacke" en given URI, i et forsøg på at skabe sig et større overblik, eller finde yderligere materiale, er det desuden en overvejelse at benytte detaljeringsgraden af dateringen til at begrænse mængden af underliggende emner: Er eksempelvist antallet af artikler årligt uoverskueligt, på trods af at de behandlede emner ikke kan forventes at ændre sig hyppigere end på årsbasis, kan det være hensigtsmæssigt at gruppere artiklerne efter publiceringsmåned alligevel.
Prisen for detaljeringsgraden er naturligvis, at der bør vedligeholdes et indekseringssystem for hver underkategorisering der benyttes.
Med ovenstående begreber og definitioner i hovedet, bør det være indlysende klart, hvorfor det til enhver til vil være absolut fy-fy at referere til en en URI der ender med default.asp eller default.htm eller lignende: Netop af navnet på filen, fremgår at det er den der automatisk vil blive brugt, såfremt den nærmeste mere generelle URI anvendes - og dens anvendelse mere end antyder, at dens ejer forudser at eksempelvis filtypen vil kunne ændres i fremtiden.
Generaliseringen er: Referér til den mest generelle form af en URI - det er den, der er størst sandsynlighed for er vedvarende.
Det er selvfølgelig hverken muligt at ønskeligt, at "konvertere" den samlede mængde af eksisterende URI'er på nettet - men af ved naturens gang vil de mest uhensigtmæssige uddø med tiden - og med korrekt anvendt omtanke, er der god chance for at netop de links DU opretter fremover, vil være dem der består og bliver benyttet de næste 100 år - og dermed er et solidt net vævet.
Enjoy your visit.
Tobias Hinnerup
27. juni 2003