Kirjoittaja: Sir Tim Berners-Lee, URI:iden, URL-osoitteiden, HTTP:n, HTML:n ja World Wide Webin keksijä ja nykyinen W3C:n johtaja. Artikkeli kirjoitettu vuonna 1998

Mitä URI:tä pidetään "viileänä"?
Sellainen, joka ei muutu.
Miten URI:t muuttuvat?
URI:t eivät muutu: ihmiset muuttavat niitä.

Teoriassa ihmisillä ei ole mitään syytä muuttaa URI-tunnuksia (tai lopettaa asiakirjatodistuksia), mutta käytännössä niitä on miljoonia.

Teoriassa verkkotunnuksen nimitilan nimellinen omistaja todella omistaa verkkotunnuksen nimitilan ja siten kaikki sen sisällä olevat URI:t. Maksukyvyttömyyttä lukuun ottamatta mikään ei estä verkkotunnuksen omistajaa pitämästä nimeä. Ja teoriassa verkkotunnuksesi alla oleva URI-tila on täysin sinun hallinnassasi, joten voit tehdä siitä niin vakaan kuin haluat. Melkein ainoa hyvä syy asiakirjan katoamiseen Internetistä on se, että verkkotunnuksen omistanut yritys on lopettanut toimintansa tai sillä ei ole enää varaa pitää palvelinta käynnissä. Miksi sitten maailmassa on niin paljon puuttuvia linkkejä? Osa tästä on yksinkertaisesti ennakoinnin puutetta. Tässä on joitain syitä, joita saatat kuulla:

Järjestimme juuri sivuston uudelleen parantaaksemme sitä.

Luuletko todella, että vanhat URI:t eivät enää toimi? Jos näin on, valitsit ne erittäin huonosti. Harkitse uusien säilyttämistä seuraavaa uudelleensuunnittelua varten.

Meillä on niin paljon tavaraa, ettemme pysty pitämään kirjaa siitä, mikä on vanhentunutta, mikä on luottamuksellista ja mikä on edelleen ajankohtainen, joten ajattelimme, että on parasta vain sammuttaa se.

Voin vain tuntea myötätuntoa. W3C kävi läpi ajanjakson, jolloin meidän oli seulottava huolellisesti arkistomateriaalit luottamuksellisuuden varmistamiseksi ennen niiden julkistamista. Päätös tulee harkita etukäteen - varmista, että jokaiseen asiakirjaan kirjataan hyväksyttävä lukijakunta, luomispäivä ja mieluiten viimeinen voimassaolopäivä. Tallenna nämä metatiedot.

No, huomasimme, että meidän on siirrettävä tiedostoja...

Tämä on yksi säälittävimmistä tekosyistä. Monet ihmiset eivät tiedä, että verkkopalvelimien avulla voit hallita objektin URI:n ja sen todellisen sijainnin välistä suhdetta tiedostojärjestelmässä. Ajattele URI-tilaa abstraktina tilana, joka on täydellisesti järjestetty. Tee sitten kartoitus siitä todellisuudesta, jota käytät sen toteuttamiseen. Ilmoita sitten tästä verkkopalvelimelle. Voit jopa kirjoittaa oman palvelinkatkelman saadaksesi sen oikein.

John ei enää ylläpidä tätä tiedostoa, Jane nyt ylläpitää tätä tiedostoa.

Oliko Johnin nimi URI:ssa? Ei, oliko tiedosto vain hänen hakemistossaan? No okei.

Aiemmin käytimme tähän CGI-skriptiä, mutta nyt käytämme binaariohjelmaa.

On hullu ajatus, että skripteillä luotujen sivujen tulisi sijaita "cgibin"- tai "cgi"-alueella. Tämä paljastaa verkkopalvelimesi käytön mekaniikan. Muutat mekanismia (jopa sisällön tallennuksen aikana), ja hups - kaikki URI:si muuttuvat.

Otetaan esimerkiksi National Science Foundation (NSF):

NSF Online-asiakirjat

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

Ensimmäinen sivu asiakirjojen katseluun ei selvästikään pysy samana muutaman vuoden kuluttua. cgi-bin, oldbrowse и pl - kaikki tämä antaa tietoa siitä, kuinka-me-te-se-nyt. Jos käytät sivua asiakirjan etsimiseen, ensimmäinen saamasi tulos on yhtä huono:

Kryptologiaa ja koodausteoriaa käsittelevän työryhmän raportti

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

asiakirjan hakemistosivulle, vaikka itse html-dokumentti näyttää paljon paremmalta:

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

Tässä pubs/1998-otsikko antaa kaikille tuleville arkistopalveluille hyvän vihjeen siitä, että vanha 1998 asiakirjaluokitusjärjestelmä on voimassa. Vaikka asiakirjanumerot saattavat näyttää erilaisilta vuonna 2098, uskoisin, että tämä URI olisi edelleen voimassa eikä se häiritse NSF:ää tai muuta organisaatiota, joka ylläpitäisi arkistoa.

En uskonut, että URL-osoitteiden piti olla pysyviä – siellä oli URN:itä.

Tämä on luultavasti yksi URN-keskustelun pahimmista sivuvaikutuksista. Jotkut ihmiset ajattelevat, että pysyvämpää nimiavaruutta koskevan tutkimuksen vuoksi he saattavat olla huolimattomia roikkuvien linkkien suhteen, koska "URN:t korjaavat kaiken." Jos olet yksi näistä ihmisistä, anna minun tuottaa sinulle pettymys.

Useimmat näkemäni URN-järjestelmät näyttävät auktoriteetin tunnisteelta, jota seuraa joko päivämäärä ja valitsemasi merkkijono tai vain valitsemasi merkkijono. Tämä on hyvin samanlainen kuin HTTP URI. Toisin sanoen, jos uskot organisaatiosi pystyvän luomaan pitkäikäisiä URN:itä, todista se nyt käyttämällä niitä HTTP-URI-tunnuksillasi. HTTP:ssä itsessään ei ole mitään, mikä tekisi URI:stäsi epävakaa. Vain organisaatiosi. Luo tietokanta, joka yhdistää asiakirjan URN:n nykyiseen tiedostonimeen, ja anna verkkopalvelimen käyttää sitä tiedostojen hakemiseen.

Jos olet päässyt tähän pisteeseen, jos sinulla ei ole aikaa, rahaa ja yhteyksiä joidenkin ohjelmistojen kehittämiseen, voit esittää seuraavan tekosyyn:

Halusimme, mutta meillä ei vain ole oikeita työkaluja.

Mutta voit olla samaa mieltä tämän kanssa. Olen täysin samaa mieltä. Sinun tarvitsee vain pakottaa verkkopalvelin jäsentämään pysyvä URI välittömästi ja palauttamaan tiedosto missä tahansa nykyisessä hullussa tiedostojärjestelmässäsi. Haluat tallentaa kaikki URI:t tiedostoon varmistuksena ja pitää tietokannan aina ajan tasalla. Haluat säilyttää saman asiakirjan eri versioiden ja käännösten väliset suhteet ja ylläpitää myös riippumatonta tarkistussummatietuetta varmistaaksesi, että tiedosto ei ole vioittunut vahingossa tapahtuneen virheen vuoksi. Ja web-palvelimet eivät yksinkertaisesti tule ulos laatikosta näillä ominaisuuksilla. Kun haluat luoda uuden asiakirjan, editori pyytää sinua määrittämään URI:n.

Sinun on voitava muuttaa omistajuutta, asiakirjan käyttöoikeutta, arkistotason suojausta jne. URI-tilassa vaihtamatta URI-osoitetta.

Kaikki on liian huonoa. Mutta korjaamme tilanteen. W3C:ssä käytämme Jigedit (Jigsaw Editing Server) -toimintoa, joka seuraa versioita, ja kokeilemme dokumenttien luontiskriptejä. Jos kehität työkaluja, palvelimia ja asiakkaita, kiinnitä huomiota tähän ongelmaan!

Tämä tekosyy koskee myös monia W3C-sivuja, mukaan lukien tämä: tee niin kuin minä sanon, älä niin kuin minä teen.

Miksi minun pitäisi välittää?

Kun vaihdat palvelimesi URI:tä, et koskaan voi täysin tietää, kenellä on linkit vanhaan URI:hen. Nämä voivat olla linkkejä tavallisilta verkkosivuilta. Lisää sivusi kirjanmerkkeihin. URI on ehkä kirjoitettu ystävälle lähetetyn kirjeen reunoihin.

Kun joku seuraa linkkiä ja se on rikki, hän yleensä menettää luottamuksen palvelimen omistajaan. Hän on myös turhautunut sekä henkisesti että fyysisesti, koska hän ei pysty saavuttamaan tavoitettaan.

Monet ihmiset valittavat rikkinäisistä linkeistä koko ajan, ja toivon, että vahinko on ilmeinen. Toivon, että myös sen palvelimen ylläpitäjän mainevaurio, jolta dokumentti katosi, on ilmeinen.

Eli mitä minun pitäisi tehdä? URI-suunnittelu

Verkkovastaavan vastuulla on allokoida URI:t, joita voidaan käyttää 2 vuodessa, 20 vuodessa, 200 vuodessa. Tämä vaatii ajattelua, organisointia ja päättäväisyyttä.

URI:t muuttuvat, jos niiden sisältämät tiedot muuttuvat. Kuinka suunnittelet ne, on erittäin tärkeää. (Mitä, URI-suunnittelu? Pitääkö minun suunnitella URI? Kyllä, sinun pitäisi ajatella sitä). Suunnittelu tarkoittaa periaatteessa kaiken tiedon jättämistä pois URI:sta.

Asiakirjan luontipäivämäärä - URI:n myöntämispäivä - ei muutu koskaan. Se on erittäin hyödyllinen uutta järjestelmää käyttävien kyselyjen erottamisessa vanhaa järjestelmää käyttävistä kyselyistä. Tämä on hyvä paikka aloittaa URI:lla. Jos asiakirja on päivätty, vaikka asiakirja olisikin merkityksellinen tulevaisuudessa, tämä on hyvä alku.

Ainoa poikkeus on sivu, joka on tarkoituksella "uusin" versio esimerkiksi koko organisaatiolle tai suurelle osalle sitä.

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

Tämä on Money-lehden uusin Money Daily -kolumni. Pääasiallinen syy siihen, ettei tähän URI:hen tarvita päivämäärää, on se, ettei ole syytä tallentaa URI:ta, joka kestää lokin. Money Daily -käsite katoaa, kun raha katoaa. Jos haluat linkittää sisältöön, linkitä se erikseen arkistossa:

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

(Näyttää hyvältä. Oletetaan, että "raha" tarkoittaa samaa koko pathfinder.com-sivuston elinkaaren ajan. Siellä on kaksoiskappale "98" ja tarpeeton ".html", mutta muuten näyttää vahvalta URI:lta.

Mitä jättää väliin

Kaikki! Luontipäivämäärää lukuun ottamatta minkä tahansa tiedon lisääminen URI:hen aiheuttaa ongelmia tavalla tai toisella.

Tekijän nimi. Tekijä voi muuttua, kun uusia versioita tulee saataville. Ihmiset jättävät organisaatiot ja luovuttavat asioita muille.
aihe. Se on erittäin vaikeaa. Se näyttää aina aluksi hyvältä, mutta muuttuu yllättävän nopeasti. Kerron tästä lisää alla.
Tila. Hakemistot, kuten "vanha", "luonnos" ja niin edelleen, puhumattakaan "uusimmista" ja "viileistä", näkyvät kaikissa tiedostojärjestelmissä. Asiakirjojen tila muuttuu – muuten luonnosten luomisessa ei olisi mitään järkeä. Asiakirjan uusin versio tarvitsee pysyvän tunnisteen sen tilasta riippumatta. Pidä tila poissa nimestä.
Pääsy. W3C:ssä olemme jakaneet sivuston työntekijöille, jäsenille ja yleisölle tarkoitettuihin osiin. Tämä kuulostaa hyvältä, mutta tietysti asiakirjat alkavat henkilökunnan tiimiideoista, niistä keskustellaan jäsenten kanssa ja niistä tulee sitten julkisia. Olisi todella sääli, jos joka kerta kun asiakirja avataan laajempaa keskustelua varten, kaikki vanhat linkit siihen katkeavat! Nyt siirrymme yksinkertaiseen päivämääräkoodiin.
Tiedostopääte. Hyvin yleinen ilmiö. "cgi", jopa ".html" muuttuu tulevaisuudessa. Et ehkä käytä HTML-koodia tällä sivulla 20 vuoteen, mutta tämän päivän linkkien pitäisi toimia edelleen. Kanoniset linkit W3C-sivustolla eivät käytä laajennusta (miten se on tehty).
Ohjelmistomekanismit. Etsi URI:sta sanat "cgi", "exec" ja muut termit, jotka huutavat "katso, mitä ohjelmistoja käytämme". Haluaako kukaan viettää koko elämänsä Perl CGI -skriptien kirjoittamiseen? Ei? Poista sitten .pl-tunniste. Lue palvelimen käsikirja, kuinka tämä tehdään.
Levyn nimi. Älä viitsi! Mutta olen nähnyt tämän.

Joten paras esimerkki sivustoltamme on yksinkertaisesti

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

...raportti W3C-johtajien kokouksen pöytäkirjasta.

Aiheet ja luokittelu aiheittain

Käsittelen tätä vaaraa tarkemmin, koska se on yksi niistä asioista, joita on vaikein välttää. Tyypillisesti aiheet päätyvät URI:ihin, kun luokittelet asiakirjasi niiden työn perusteella. Mutta tämä jakautuminen muuttuu ajan myötä. Alueiden nimet muuttuvat. W3C:ssä halusimme muuttaa MarkUP:n Markupiksi ja sitten HTML:ksi vastaamaan osion todellista sisältöä. Lisäksi on usein tasainen nimiavaruus. Oletko varma, että 100 vuoden kuluttua et halua käyttää uudelleen mitään? Lyhyen elämämme aikana olemme jo halunneet käyttää uudelleen esimerkiksi "Historia" ja "Style Sheets".

Se on houkutteleva tapa järjestää verkkosivusto – ja todella houkutteleva tapa järjestää mitä tahansa, mukaan lukien koko verkko. Tämä on loistava keskipitkän aikavälin ratkaisu, mutta sillä on vakavia puutteita pitkällä aikavälillä.

Osa syy on merkityksen filosofiassa. Jokainen kielen termi on mahdollinen klusteroinnin kohde, ja jokaisella voi olla erilainen käsitys siitä, mitä se tarkoittaa. Koska entiteettien väliset suhteet muistuttavat enemmän verkkoa kuin puuta, jopa verkon kanssa samaa mieltä olevat voivat valita puusta erilaisen esityksen. Nämä ovat minun (usein toistuvia) yleisiä havaintojani hierarkkisen luokittelun vaaroista yleisenä ratkaisuna.

Itse asiassa, kun käytät aiheen nimeä URI:ssa, sitoudut jonkinlaiseen luokitukseen. Ehkä tulevaisuudessa pidät toisesta vaihtoehdosta. URI on tällöin alttiina rikkomiselle.

Syy aihealueen käyttämiseen URI:n osana on se, että vastuu URI-tilan alaosioista yleensä delegoidaan, ja sitten tarvitset organisaatioelimen - osaston, ryhmän tai minkä tahansa - nimen, joka vastaa kyseisestä alitilasta. Tämä on organisaatiorakenteeseen sitova URI. Se on yleensä turvallista vain, jos seuraava (vasen) URI on suojattu päivämäärällä: 1998/pics saattaa tarkoittaa palvelimellesi "mitä tarkoitimme vuonna 1998 kuvilla" eikä "mitä teimme vuonna 1998 niillä, joita nyt kutsumme kuviksi".

Älä unohda verkkotunnuksen nimeä

Muista, että tämä ei koske vain URI:n polkua, vaan myös palvelimen nimeä. Jos sinulla on erilliset palvelimet eri asioille, muista, että tätä jakoa on mahdotonta muuttaa tuhoamatta monia, monia linkkejä. Joitakin klassisia "katso käyttämämme ohjelmistoja" -virheitä ovat verkkotunnukset "cgi.pathfinder.com", "secure", "lists.w3.org". Ne on suunniteltu helpottamaan palvelimen hallintaa. Riippumatta siitä, edustaako toimialue yrityksesi osastoa, asiakirjan tilaa, käyttöoikeustasoa tai suojaustasoa, ole erittäin varovainen, ennen kuin käytät useampaa kuin yhtä verkkotunnusta useille asiakirjatyypeille. Muista, että voit piilottaa useita verkkopalvelimia yhden näkyvän verkkopalvelimen sisään käyttämällä uudelleenohjausta ja välityspalvelinta.

Ja mieti myös verkkotunnustasi. Et halua, että sinuun viitataan nimellä soap.com, kun olet vaihtanut tuotelinjaa ja lopettanut saippuan valmistuksen (Anteeksi soap.com-sivuston tällä hetkellä omistavalle).

Johtopäätös

URI:n säilyttäminen 2, 20, 200 tai jopa 2000 vuoden ajan ei tietenkään ole niin helppoa kuin miltä näyttää. Kuitenkin kaikkialla Internetissä verkkovastaavat tekevät päätöksiä, jotka tekevät tästä tehtävästä heille tulevaisuudessa todella vaikean. Usein tämä johtuu siitä, että he käyttävät työkaluja, joiden tehtävänä on esittää paras sivusto vain tällä hetkellä - eikä kukaan ole arvioinut, mitä linkeille tapahtuu, kun kaikki muuttuu. Tässä on kuitenkin se, että monet, monet asiat voivat muuttua, ja URI:si voivat ja niiden pitäisi pysyä samoina. Tämä on mahdollista vain, kun ajattelee, kuinka luot ne.

Katso. No:

Jakob Nielsenin tiradi samasta aiheesta

lisäravinteet

Kuinka poistaa tiedostopäätteet...

...URI:sta nykyisessä tiedostopohjaisessa verkkopalvelimessa?

Jos käytät esimerkiksi Apachea, voit määrittää sen neuvottelemaan sisällöstä. Tallenna tiedostotunniste (esim. .png) tiedostoon (esim. mydog.png), mutta voit linkittää verkkoresurssiin ilman sitä. Apache tarkistaa sitten hakemistosta kaikki tiedostot, joilla on sama nimi ja millä tahansa tunniste, ja voi valita joukosta parhaan (esimerkiksi GIF ja PNG). Eikä sinun tarvitse laittaa erityyppisiä tiedostoja eri hakemistoihin, itse asiassa sisällön vastaavuus ei toimi, jos teet niin.

Määritä palvelimesi sisällöstä neuvottelemaan
Linkitä aina URI:ihin ilman laajennusta

Laajennukset sisältävät linkit toimivat edelleen, mutta ne estävät palvelintasi valitsemasta parasta saatavilla olevaa muotoa tällä hetkellä ja tulevaisuudessa.

(Itse asiassa, mydog, mydog.png и mydog.gif - kelvollisia verkkoresursseja, mydog on universaali sisältötyyppinen resurssi, ja mydog.png и mydog.gif — tietyn sisältötyypin resurssit).

Tietenkin, jos kirjoitat omaa web-palvelinta, on hyvä idea käyttää tietokantaa sitomaan pysyvät tunnisteet nykyiseen muotoonsa, vaikkakin varo tietokannan rajatonta kasvua.

The Board of Shame - Story 1: Channel 7

Vuoden 1999 aikana seurasin sivulla lumen vuoksi tapahtuvia koulujen sulkemisia http://www.whdh.com/stormforce/closings.shtml. Älä odota, että tiedot näkyvät TV-ruudun alareunassa! Linkkasin siihen kotisivultani. Ensimmäinen iso 2000 lumimyrsky saapuu ja katson sivua. Siellä lukee:,

- Alkaen.
Mikään ei ole tällä hetkellä suljettu. Palaa takaisin säävaroitusten sattuessa.

Ei voi olla niin kova myrsky. Hassua, että päivämäärä puuttuu. Mutta jos menet sivuston pääsivulle, siellä on suuri painike "Suljetut koulut", joka johtaa sivulle http://www.whdh.com/stormforce/ pitkä lista suljetuista kouluista.

Ehkä he muuttivat järjestelmää luettelon saamiseksi - mutta heidän ei tarvinnut muuttaa URI:tä.

Board of Shame - Tarina 2: Microsoft Netmeeting

Internet-riippuvuuden lisääntyessä syntyi näppärä idea, että linkit valmistajan verkkosivuille voitaisiin upottaa sovelluksiin. Tätä on käytetty ja väärinkäytetty paljon, mutta et voi muuttaa URL-osoitetta. Yritin juuri toissapäivänä linkkiä Microsoft Netmeeting 2/something -asiakasohjelmasta Ohje/Microsoft on Web/Free -valikossa ja sain 404-virheilmoituksen - palvelimelta ei löytynyt vastausta. Ehkä se on jo korjattu...

Historiallinen huomautus: 20-luvun lopulla, kun tämä kirjoitettiin, "cool" oli hyväksynnän epiteetti erityisesti nuorten keskuudessa, mikä osoitti muodisuutta, laatua tai sopivuutta. Kiireessä URI-polku valittiin usein "viileyden" sijaan hyödyllisyyden tai kestävyyden vuoksi. Tämä viesti on yritys ohjata energiaa coolin etsimisen takana.

Lähde: will.com

Hienot URI:t eivät muutu