Forfatter — Sir Tim Berners-Lee, opfinder af URI, URL, HTTP, HTML og World Wide Web, nuværende leder af W3C. Artiklen blev skrevet i 1998.

Hvilken URI kan betragtes som "cool"?
En, der ikke ændres.
Hvordan ændres URIs?
URIs ændres ikke: det er mennesker, der ændrer dem.

Teoretisk set har folk ingen grund til at ændre URIs (eller stoppe med at understøtte dokumenter), men i praksis er der millioner.

Teoretisk set ejer den nominelle ejer af domæneområdet faktisk domæneområdet og dermed alle URIs i det. Udover insolvens er der intet, der forhindrer domæneejeren i at beholde dette navn. Og teoretisk set er URI-rummet under dit domænenavn helt under din kontrol, så du kan gøre det så stabilt, som du ønsker. I høj grad er den eneste gyldige grund til, at et dokument forsvinder fra internettet, at virksomheden, der ejer domænenavnet, er gået ud af drift eller ikke længere kan betale for serverdriften. Så hvorfor er der så mange døde links i verden? Dels er det bare et spørgsmål om mangel på forudseenhed. Her er nogle grunde, man kan høre:

Vi har bare reorganiseret hjemmesiden for at gøre den bedre.

Tror du virkelig, at gamle URIs ikke længere kan fungere? Hvis ja, så har du valgt dem meget dårligt. Tænk på, hvordan de nye kan bevares efter næste redesign.

Vi har så meget materiale, at vi ikke kan holde styr på, hvad der er forældet, hvad der er fortroligt, og hvad der stadig er relevant, og dermed mente vi, at det var bedre bare at slukke for det hele.

Jeg kan kun sympatisere. W3C har oplevet en periode, hvor vi måtte grundigt gennemgå arkivmateriale for fortrolighed, før vi gjorde det offentligt tilgængeligt. Beslutningen bør tænkes igennem på forhånd — sørg for, at du registrerer en acceptabel læserkreds, oprettelsesdato og ideelt set udløbsdato for hvert dokument. Behold disse metadata.

Nå, vi fandt ud af, at vi skulle flytte filerne...

Det er en af de mest ynkelige undskyldninger. Mange ved ikke, at webservere giver dig mulighed for at styre forbindelsen mellem en objekts URI og dets faktiske placering i filsystemet. Forestil dig det URI-område som et abstrakt rum, perfekt organiseret. Så lav en mapping til enhver virkelighed, som du rent faktisk bruger til at implementere det. Derefter informerer du webserveren om dette. Du kan endda skrive en del af din server for at gøre alt korrekt.

John understøtter ikke denne fil længere, det gør Jane nu.

Var Johns navn i URI'en? Nej, filen lå bare i hans mappe? Nå ja.

Tidligere brugte vi CGI-scripts til dette, men nu bruger vi et binært program.

Der er en skør idé om, at sider, der genereres af scripts, skal placeres i "cgibin" eller "cgi". Dette afslører mekanismen for, hvordan du kører din webserver. Skifter du mekanismen (selv når du bevarer indholdet), så ups - alle dine URI'er ændrer sig.

Lad os tage National Science Foundation (NSF) som et eksempel:

NSF's online dokumenter

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

Den første side til at begynde at gennemse dokumenter vil tydeligvis ikke forblive sådan om nogle år. cgi-bin, oldbrowse og pl — alt dette giver fragmenter af information om, hvordan-vi-gør-det-nu. Hvis du dog bruger en side til at søge efter et dokument, får du først et lige så dårligt resultat:

Rapport fra arbejdsgruppen om kryptografi og kodeteori

http://www.nsf.gov/cgi-bin/getpub?nsf9814

for indeks-siden til dokumentet, selvom selve html-dokumentet ser meget bedre ud:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

Her giver overskriften pubs/1998 enhver fremtidig arkivservice en god nøgle til at forstå, hvad den gamle klassifikationsordning for dokumenter fra 1998 handler om. Selvom dokumentnumrene i 2098 muligvis ser anderledes ud, kan jeg forestille mig, at denne URI stadig vil være gyldig, og at den ikke vil genere NSF eller nogen anden organisation, der vil opretholde arkivet.

Jeg troede ikke, at URL'er skulle være permanente - der har jo været URN.

Dette er sandsynligvis en af de værste bivirkninger ved diskussionen om URN. Nogle mener, at på grund af forskningen om et mere permanent navnerum kan de negligere hængende links, fordi "URN vil løse alt dette". Hvis du er en af disse mennesker, så lad mig skuffe dig.

De fleste URN-ordninger, jeg har set, ligner en autoritetsidentifikator efterfulgt af enten en dato og en streng, du vælger, eller blot en streng, du vælger. Det minder meget om en HTTP-URI. Med andre ord, hvis du mener, at din organisation vil være i stand til at oprette langtidsholdbare URN'er, så bevis det nu ved at bruge dem til dine HTTP-URI'er. I selve HTTP er der intet, der gør din URI ustabil. Kun din organisation. Opret en database, der matcher dokumentets URN med det aktuelle filnavn, og lad webserveren bruge den til faktisk at hente filer.

Hvis du er kommet til dette punkt, så hvis du ikke har tid, penge og forbindelser til at udvikle noget software, kan du komme med denne undskyldning:

Vi ville gerne, men vi har bare ikke de nødvendige værktøjer.

Og det kan man have medfølelse med. Jeg er helt enig. Hvad du skal gøre, er at få webserveren til øjeblikkeligt at håndtere den permanente URI og returnere filen, uanset hvor den i øjeblikket er gemt i dit nuværende skøre filsystem. Du vil gerne gemme alle URI'er i en fil som en tjek, og konstant holde databasen opdateret. Du vil gerne bevare relationerne mellem forskellige versioner og oversættelser af det samme dokument, samt opbevare en uafhængig checksum for at sikre beskyttelse mod filskader ved en tilfældig fejl. Og webservere kommer simpelthen ikke med disse funktioner. Når du vil oprette et nyt dokument, beder din editor dig om at angive en URI.

Du har brug for muligheden for at ændre ejerskab, adgang til dokumentet, sikkerhedsniveauer for arkivniveau og andre i URI-rummet uden at ændre URI'en.

Det er alt for skidt. Men vi vil rette op på det. I W3C bruger vi funktionaliteten fra Jigedit (Jigsaw-serveren til redigering), som sporer versioner, og vi eksperimenterer med scripts til at oprette dokumenter. Hvis du udvikler værktøjer, servere og klienter, så vær opmærksom på dette problem!

Denne undskyldning gælder også for mange W3C-sider, inklusive denne: så gør det, jeg siger, og ikke det, jeg gør.

Hvorfor skulle jeg bekymre mig om det?

Når du ændrer URI på din server, kan du aldrig helt sige, hvem der har links til den gamle URI. Det kan være links fra almindelige web-sider. Bogmærker til din side. URI'en kan være ridset ind på kanten af et brev til en ven.

Når nogen klikker på et link og det er brudt, mister de typisk tilliden til ejer af serveren. De bliver også skuffede — både følelsesmæssigt og reelt, da de ikke kan nå deres mål.

Mange mennesker klager konstant over døde links, og jeg håber, at skaden er åbenlys. Jeg håber, at den omdømme skade, der rammer serverens vedligeholder, hvor dokumentet er forsvundet, også er indlysende.

Hvad skal jeg gøre? Design URI

Det er webmasterens pligt at skabe URI'er, der kan bruges om 2 år, om 20 år, om 200 år. Det kræver omtanke, organisering og fokus.

URI'er ændres, når der sker ændringer i deres information. Det er meget vigtigt, hvordan du designer dem. (Hvad, designe URI? Skal jeg designe URI? Ja, du skal tænke over det). Design handler primært om at udelade enhver information i URI.

En dokumentoprettelsesdato — datoen for udstedelse af URI — er noget, der aldrig vil ændre sig. Det er meget nyttigt til at adskille anmodninger, der bruger det nye system, fra dem der bruger det gamle system. Det er en god start for URI. Hvis dokumentet har en dato angivet, selvom dokumentet vil være relevant i fremtiden, er det en god begyndelse.

Den eneste undtagelse er en side, der bevidst er den "sidste" version, for eksempel for hele organisationen eller en stor del af den.

http://www.pathfinder.com/money/moneydaily/latest/

Dette er den sidste kolonne i Money Daily i tidsskriftet Money. Den primære grund til, at der ikke er brug for en dato i denne URI, er, at der ikke er nogen grund til at bevare en URI, der vil overleve tidsskriftet. Konceptet Money Daily vil forsvinde, når Money forsvinder. Hvis du ønsker at henvise til indholdet, skal du henvise til det separat i arkiverne:

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(Ser godt ud. Antager, at "money" vil betyde det samme gennem hele pathfinder.coms eksistens. Der er en duplikering af "98" og unødvendig ".html", men ellers ser det ud som en stærk URI.

Hvad der skal udelades

Alt! Udover dokumentets oprettelsesdato, hvis du placerer nogen information i URI, inviterer du på en eller anden måde til problemer.

Forfatterens navn. Forfatterskaber kan ændre sig, når nye versioner kommer frem. Folk forlader organisationer og overdrager ting til andre.
Emne. Det er meget kompliceret. Det ser altid godt ud i starten, men ændrer sig overraskende hurtigt. Jeg vil uddybe dette nærmere nedenfor.
Status. Kataloger som 'gammel', 'kladde' og så videre, for ikke at nævne 'sidste' og 'cool', dukker op i alle filsystemer. Dokumenter ændrer status - ellers ville der ikke være nogen grund til at oprette kladder. Den seneste version af et dokument har brug for en konstant identifikator, uanset dets status. Hold status væk fra navnet.
Adgang. Hos W3C har vi opdelt hjemmesiden i sektioner for medarbejdere, medlemmer og offentligheden. Det lyder godt, men selvfølgelig starter dokumenter som teamideer fra medarbejdere, diskuteres med medlemmer og bliver derefter offentlige. Faktisk er det frustrerende, hvis gamle links til et dokument går i stykker, hver gang det åbnes for bredere diskussion! Nu bevæger vi os hen imod en simpel datokode.
Filtype. En meget almindelig ting. "cgi", selv ".html" vil ændre sig i fremtiden. Måske om 20 år vil du ikke bruge HTML til denne side, men de nuværende links til den skal stadig fungere. Kanoniske links på W3C's websted bruger ikke en filtype (hvordan man gør det).
Programmekanismer. I URI'en skal du lede efter "cgi", "exec" og andre termer, der råber 'se, hvilken software vi bruger'. Er der nogen, der ønsker at vie sit liv til Perl CGI-scripts? Nej? Så fjern .pl filtypen. Tjek serverens vejledning i, hvordan man gør det.
Drevnavn. Kom nu! Men jeg har set sådan noget.

Så det bedste eksempel fra vores websted er bare

http://www.w3.org/1998/12/01/chairs

… rapporten om referaterne fra W3C's formandsmøder.

Emner og emnekategorisering

Jeg vil uddybe denne fare, da det er en af de ting, der er sværest at undgå. Som regel kommer emner ind i URI, når du klassificerer dine dokumenter efter den udførte opgave. Men denne opdeling vil ændre sig over tid. Navnene på områderne vil ændre sig. I W3C ønskede vi at ændre MarkUP til Markup, og derefter til HTML, for at afspejle det faktiske indhold i sektionen. Derudover er der ofte et fladt navnerum her. Om 100 år er du sikker på, at du ikke vil genbruge noget? I vores korte liv har vi allerede ønsket at genbruge "Historie" og "Stylesheets", for eksempel.

Det er en indbydende måde at organisere et websted på - og virkelig en fristende måde at organisere alt, inklusive hele nettet. Det er en god mellemlang løsning, men har alvorlige ulemper på lang sigt.

Delvis skyldes årsagerne filosofi om mening. Hvert begreb i et sprog er et potentielt klusterobjekt, og enhver person kan have forskellige opfattelser af, hvad det betyder. Da relationer mellem emner ligner mere et netværk end et træ, kan selv dem der er enige om nettet, vælge en anden trærepræsentation. Dette er mine (ofte gentagne) generelle bemærkninger om farerne ved hierarkisk klassifikation som en generel løsning.

Faktisk, når du bruger et emnenavn i URI, binder du dig til en vis klassifikation. Du kan muligvis foretrække en anden mulighed i fremtiden. Så vil URI'en være udsat for brud.

Årsagen til at bruge emneområdet som en del af URI'en, er at ansvaret for underafdelinger i URI-rummet normalt delegeres, og så har du brug for navnet på det organisatoriske organ — afdeling, gruppe eller noget andet, der er ansvarligt for dette underområde. Dette er bindende for URI til den organisatoriske struktur. Det er normalt kun sikkert, når URI'en beskyttes af en dato længere fremme (til venstre): 1998/pics kan betyde for din server "det, vi mente med pics i 1998", og ikke "det, vi gjorde med det, vi nu kalder pics, i 1998".

Glem ikke domænenavnet

Husk, at dette ikke kun gælder stien i URI'en, men også servernavnet. Hvis du har separate servere til forskellige formål, skal du huske, at denne opdeling ikke kan ændres uden at ødelægge mange, mange links. Nogle klassiske fejl som "se hvilket software vi bruger i dag" – domænenavne "cgi.pathfinder.com", "secure", "lists.w3.org". De er skabt for at lette serveradministrationen. Uanset om domænet repræsenterer en afdelings i din virksomhed, dokumentstatus, adgangsniveau eller sikkerhedsniveau, vær meget, meget forsigtig, før du bruger mere end ét domænenavn til flere typer dokumenter. Husk, at du kan skjule mange webservere bag én synlig webserver ved hjælp af omdirigering og proxiering.

Ja, og tænk også over dit domænenavn. Du ønsker ikke, at folk henviser til dig som soap.com, efter du har skiftet produktlinje og stoppet med at producere sæbe (Undskyld til den, der ejer soap.com i øjeblikket).

Konklusion

At bevare URI'en i 2, 20, 200 eller endda 2000 år er åbenbart ikke så enkelt, som det ser ud. Ikke desto mindre træffer webmastere på internettet beslutninger, der virkelig komplicerer denne opgave i fremtiden. Det sker ofte, fordi de bruger værktøjer, hvis opgave er at præsentere den bedste side lige nu – og ingen har tænkt på, hvad der vil ske med links, når alt ændrer sig. Men pointen her er, at meget, meget kan ændre sig, og dine URI'er kan og bør forblive de samme. Dette er kun muligt, hvis du tænker over, hvordan du opretter dem.

Se også:

Jakob Nielsens tirade om det samme emne

Tilføjelser

Sådan fjerner du filendelser…

…fra URI'en i den aktuelle webserver baseret på filer?

Hvis du for eksempel bruger Apache, kan du konfigurere det til at matche indhold. Bevarer filendelsen (for eksempel .png) i filen (for eksempel, mydog.png), men du kan også henvise til webressourcen uden det. Derefter tjekker Apache kataloget for at finde alle filer med dette navn og enhver udvidelse, og kan også vælge den bedste fra et sæt (f.eks. GIF og PNG). Og du skal ikke placere forskellige filtyper i forskellige kataloger, faktisk vil indholdsaftalen ikke fungere, hvis du gør det.

Konfigurer din server til indholdsforhandling
Lav altid links til URI uden udvidelse

Links med udvidelser vil stadig fungere, men de vil ikke lade din server vælge den bedste af de nuværende og fremtidige formater.

(Faktisk, mydog, mydog.png og mydog.gif — gyldige webressourcer, mydog — dette er en ressource af universel indholdstype, og mydog.png og mydog.gif — ressourcer af specifik indholdstype).

Selvfølgelig, hvis du skriver din egen webserver, er det en god idé at bruge en database til at knytte permanente id'er til deres nuværende form, men vær opmærksom på ikke at lade databasen vokse ubegribelig.

Skamliste — Historie 1: Channel 7

I løbet af 1999 fulgte jeg lukningen af skoler på grund af sne via siden http://www.whdh.com/stormforce/closings.shtml. Skal man vente, indtil informationen vises nederst på TV-skærmen! Jeg satte et link til det fra min startside. Den første store snevejr i 2000 kommer, og jeg tjekker siden. Der står:

— På nuværende tidspunkt.
I øjeblikket er der ikke lukket noget. Venligst kom tilbage i tilfælde af vejrmeldinger.

Det kan ikke være, så stærk en storm. Sjovt, at datoen mangler. Men hvis man går til forsiden af hjemmesiden, vil der være en stor knap med teksten 'Lukkede skoler', som fører til en side http://www.whdh.com/stormforce/ med en lang liste over lukkede skoler.

Måske har de ændret systemet for at få listen — men de skulle ikke have ændret URI'en.

Skamliste — Historie 2: Microsoft Netmeeting

Med den voksende afhængighed af internettet kom den smarte idé, at man kunne indlejre links til producentens hjemmeside i applikationer. Dette blev ofte brugt og misbrugt, men — man kan ikke ændre URL. Faktisk for nylig prøvede jeg et link fra Microsoft Netmeeting 2/something i menuen Help/Microsoft on the Web/Free stuff og fik en fejl 404 — serveren kunne ikke finde svaret. Måske er det allerede blevet rettet…

Historisk bemærkning: I slutningen af det 20. århundrede, da dette blev skrevet, var "cool" et godkendende epitet, især blandt unge, der indikerede stil, kvalitet eller relevans. I hast valgte man ofte URI-stien ud fra "coolness" i stedet for nytte eller holdbarhed. Denne bemærkning er et forsøg på at omdirigere den energi, der ligger bag stræben efter coolness.

Kilde: habr.com