クールなURIは変わらない
クールなURIとは？
クールなURIとは変わらないもののこと。
どんなURIが変わってしまう？
URIは変わらない：人がそれを変更するのだ。
理屈の上では、人々がURIを変更するべき（もしくはドキュメントのメンテナンスをやめてしまう）理由は全くありません。しかし、現実には山ほど理由があります。
理論上では、ドメイン名空間の所有者はその空間を所有しており、したがってその中に含まれるURIも所有権を持ちます。ドメイン維持料が支払えない場合を除いて、その名前を保有し続けることを妨げるものはありません。そして理論上は、あなたのドメイン名のもとにあるURIは、完全にあなたの管理下にあり、望む限りそれを安定的に保つことができるのです。 ウェブからあるドキュメントが消えてしまう唯一の納得できる理由は、そのドメイン名を保持していた会社が廃業してしまうか、サーバーを維持できなくなったという場合ぐらいでしょう。では、どうして世の中に行き先を失ってしまったリンクがこれほどまでにたくさん存在するのでしょうか？ そのひとつは、単なる将来の見通しの欠如です。いくつか、よく耳にする理由を挙げてみましょう：
ウエブサイトをよりよいものにするために、再構築しました。
本当に以前のURIをそのままにしておくことは不可能だと思いますか？ もしそうであれば、よほどまずいURIを付けていたということです。新しいURIは、次のデザイン更新後にもそのまま使えるように、よく考えてください。
あまりにたくさんのファイルがあって、どれが古くなっていて、どれが秘密文書で、どれが正しいものか把握しきれなくなってきました。だから、全部取り除いてしまった方がよいと考えました。
これは私も分かる部分があります - W3Cも、アーカイブを公開するにあたって、非公開にするべきものはどれか慎重にふるいにかけなければならなかったときは、同じような状況でした。解決策は、将来をきちんと見通しておくことです - 全てのドキュメントについて、配布しても良いもの、作成日と、できれば有効期限をきちんと把握しておきましょう。このメタデータをきちんと管理しておいてください。
つまりその、ファイルを移動しなければならないことになったので…
これはもっとも下手な言い訳の一つですね。多くの人は、URIとそれが指し示す実際のファイルの関係付けについて、Apacheなどのサーバーが多彩で柔軟なコントロール手段を提供しているということを理解していません。URI空間は抽象的な空間で、完全に整備されているものだと考えてください。そのうえで、実際に利用する実体に対応づけをおこないます。その対応関係を、サーバーに指示してください。ちょっと指示命令を書くだけで、サーバーにそれを実行させることだってできます。
ジョンはもうそのファイルを管理していなくて、今はジェーンが担当なんです。
ジョンの名前が、URIのどこかに関係があるのでしょうか？ ファイルが彼のディレクトリに入っている？ ああ、なるほど。
以前はこのためにCGIスクリプトを使っていましたが、今はバイナリのプログラムを使っています。
スクリプトによって生成されるページは"cgibin"もしくは"cgi"という領域におかなければならないと固く信じられているようです。これはあなたがサーバーを運用するメカニズムを露け出していることになります。サーバーの運用方法を変えたとすると（内容はまったく同じだとしても）おーっと、URIも全部変えなくてはなりません。
たとえばThe National Science Foundationを例にとってみましょう：
NSF Online Documents
http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl
ドキュメントを探す出発点となるメインページは、どう見てもこの先何年も同じ形でアクセスできるという保証を与えてくれそうにありません。"cgi-bin"や"oldbrowse"や".pl"といったものはみな「私たちは今こうやっています」ということを示すものです。逆に、このページでドキュメントを探すと、その結果として最初に出てくるのも同様に芳しくない
Report of Working Group on Cryptology and Coding Theory
http://www.nsf.gov/cgi-bin/getpub?nsf9814
という一覧ページです。しかしHTMLドキュメントそのものは遙かに優れた形になっています：
http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm
これを見ると、"pubs/1998"という最初の部分は、将来のアーカイブサービスがどんな形になっても、かつての1998というドキュメントの分類方法はそのまま使われると考えてよいように思えます。2098年にはドキュメント番号の付け方は違ったものになっているかもしれないけれど、このURIはそのまま有効で、NSFあるいはこのアーカイブの管理者はURIについて問題を抱えることはまずないでしょう。
URLが永続的である必要はないと思っていました - 永続的でなければならないのはURNなのだと。
これはURNについての議論の、もっとも問題のある副作用です。 より永続的な名前空間についての研究がなされているので、リンクが切れてしまっても「URNが問題を解決してくれる」から気にしなくてもいい、と考えているらしい人もいます。もしあなたがそう考えているなら、悪いけどちょっとがっかりしてもらいましょう。
私がこれまで目にしたURN手法のほとんどは、認証IDに日付と任意の文字列の組み合わせ、もしくは単なる任意の文字列といった類のものです。これは、見たところほとんどHTTPのURIと違いはありません。別の言い方をしてみましょうか。もしあなたの組織が永続的なURNをつくることができると思うなら、今すぐに実行して、それを自分たちのHTTPのURIに適用してそのことを証明してみてください。HTTPにはあなたのURIを不確実ものにするような要素はありません。原因はあなたの組織にあるのです。ドキュメントのURN [URI]と現在のファイル名を対応づけるデータベースを作り、ウェブサーバーがそれを使ってきちんとファイルを呼び出せるようにしてください。
この点に納得がいったとして、あなたがソフトを開発するための時間と資金と依頼先をもっていない限り、次の言い訳がでてくるでしょう：
そうしたいのはやまやまだけど、いいツールがないんです。
これはよく分かります。全面的に同意します。このためには、ウェブサーバーは不変のURIを直ちに理解し、あなたのやっかいなファイルシステムがその時点でどんなところにファイルを保存していようと、該当するファイルを送り返すようにしなければなりません。URIをファイルに収録して、データベースが正確であるかどうかを常にチェックできるようにしたいでしょう。同じドキュメントの異なるバージョンや翻訳の関係を管理したいでしょうし、不測のエラーによるファイルの破壊に備えて、チェックサムを独立した記録として管理したいでしょう。ウェブサーバーは、こうした機能をあらかじめ備えてはいません。新しいドキュメントを作成しようとすると、エディタソフトはURIを教えてくれず、URIを決めてくれと要求してくるでしょう。
あなたは、URI空間内のドキュメントの所有者、アクセス権、アーカイブ状態、セキュリティレベルなどを、URIを変えることなく変更できなければなりません。
うんざりですね。しかし、それは避けては通れません。 W3Cでは、"Jigedit"機能（エディタ付きのjigsawサーバー）を使っています。それはバージョン管理が可能で、ドキュメントを生成するスクリプトも試しています。もしあなたがツールやサーバーやクライアントを開発したら、ぜひ教えてください！
これは秀逸な理由で、W3Cのページの多くにも当てはまります：ですから、私のやっていることではなくて、私の言っていることを実行してください。
何でそんなこと気にしなくちゃいけないの？
あなたがサーバー上のあるURIを変更したら、それを古いURIにリンクしている人々に完全に知らせることは不可能です。利用者は通常のウェブページからリンクしているかもしれません。あるいはあなたのページをブックマークに登録しているかもしれません。友人の手紙の片隅に書かれたURIを見てサイトを探しに来るかもしれません。
もしリンクを辿ってみてそれが働かなかったら、たいていの利用者はサーバーの所有者に対する信頼感を失ってしまいます。それに、利用者は欲求不満に陥ります - 気分的にもそうだし、なんと言っても目的が達せられないのですから。
こんなにも多くの人々がいつもリンク切れに対する不満を述べているのですから、その問題ははっきりしているはずだと思いたいです。さらに、ドキュメントが無くなっているということは、そのサーバーの管理者の名誉にとっても大きなダメージであることが、みんな分かっていると思いたいです。
じゃあどうすればいいの？ URIの設計
URIが2年経っても、20年経っても、200年経ってもきちんと働くように設定することは、ウェブマスターの義務です。このためには、考察と組織と積極的な関与が必要になります。
URIが変わってしまうのは、その中に含まれる何らかの情報が変わってしまう場合です。それをどう設計（design）するかということが重要なのです（何？ URIを設計する？ 私はURIを設計しなければならないのですか？ その通り、それについてきちんと考えなければなりません）。設計とは、URIから情報を取り去ってしまうということとほとんど同義です。
ドキュメントの作成日 - URIが設定された日付 - は、まず変わることのないものの一つです。古いシステムに対する要求と新しいシステムに対する要求を分離しておくことはとても有益です。これはURIのよい出発点でもあります。もしドキュメントが何らかの形で日付を持っているなら、たとえそれが先々まで利用されるようなものであっても、日付はよい出発点になります。
唯一の例外は、そのページが意図的に、たとえば、ある組織全体の、あるいはその大部分に関する「最新情報」ページになっている場合です。
http://www.pathfinder.com/money/moneydaily/latest/
は「Money」誌のコラム"Money daily"の最新版です。このURIに日付が不要な最大の理由は、このURIが雑誌そのものよりも長続きするとは考えられないということです。"today's Money"というコンセプトはMoney誌が廃刊になったら消滅してしまいます。そのコンテンツにリンクしたければ、別のアーカイブにある
http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html
にリンクするでしょう（このURIはなかなか良さそうに見えます。"money"がpathfinder.comが続く限り同じものを意味するという前提条件付きですが。"98"が重複しているのと、".html"があることを除けば、これは強靱なURIと考えられます）。
除外すべきもの
全部！ 作成日以外は、どんな情報を名前に加えても、なんらかのトラブルの原因になります。
- 作者名 - 作者はバージョンにつれて変わることがあります。担当者が組織をやめたら誰かに引き継ぎますね。
- 件名 - これはちょっとややこしいです。最初はたいていうまく行くように見えるのに、あっという間に違ってきます。これについては、この後で議論します。
- 状態 - "old"とか"draft"、あるいは"latest"やら"cool"といったディレクトリ名は、あらゆるファイルシステムで見受けられます。ドキュメントの状態（status）は変化するものです。でなければ、草稿を作る意味がありません。ドキュメントの最新版は、その状態がどんなものであれ、永続性のある識別子[URI]を持たなければなりません。文書の状態は、名前から除外してください。
- アクセス権 - W3Cはサイトを"Team access"、"Member access"、"Public access"に区分しています。良さそうに見えますが、しかしドキュメントは最初チームの検討事項としてスタートし、メンバーで議論され、それから公開に至ります。もしディスカッションの対象が広がるごとに、古いドキュメントへのリンクが働かないとしたら、まったくもって恥ずかしいことです！ 今は、わたしたちはシンプルな日付による命名方法に変更しました。
- ファイル名の拡張子 - 非常に広く使われるものですが、 "cgi"はもとより、".html"も将来は変わるかもしれないものです。20年後は、そのページをHTMLで記述していないかもしれませんが、その文書への現在のリンクは、同じように有効であって欲しいと思うかもしれません。W3Cサイトへの正式なリンク方法は、拡張子を使わないことになっています。（どうやって？）
- ソフトウェアのメカニズム - "cgi"とか"exec"とかをはじめ、さまざまな「私たちはこんなソフトを使ってます」といった要素がURIに含まれています。一生PerlのCGIスクリプトを使い続けると確約したい人なんていますか？ いないでしょう？ ".pl"を取り除いてください。どうやったらいいのかは、サーバーのマニュアルに書いてあります。
- ディスク名 - 勘弁してほしいな。でも、実際に見かけたことがあります。
そういうわけで、わたしたちのサイトの、改善された例はシンプルです。
http://www.w3.org/1998/12/01/chairs
これはW3Cの委員長会議の議事録を示します。
トピックスと件名による分類
避けられないことなので、危険を承知で、この点について詳しく検討してみましょう。典型的なケースとして、今やっている仕事の内容に従ってドキュメントを分類すると、URIにトピックが含まれることになります。分野の名前というものは変化します。W3Cにおいて、わたしたちはセクションのコンテンツをよりきちんと反映させるために、"MarkUp"という名前を"Markup"に、そしてさらに"HTML"に変更しようと考えました。さらに、多くの場合これ[トピック]はフラットな名前空間であることに注意してください。今後100年間、何らかの名前をもう一度使いたくなることはないと断言できますか？ わたしたちは、短い歴史の間でも、たとえば"History"と"Stylesheets"を別の目的で使いたいと考えたことがありました。
これは、ウェブサイトを構成する上で誘惑的な手法です - 実際、ウェブ全体を含め、何を構成するにも誘惑的な手法です。これは、中期的には素晴らしい解決策ですが、長期的には深刻な欠点があります。
この理由は、一部には意味の哲学的法則にあります。ある言語におけるあらゆる用語は、潜在的に群生する実体（clustering subject）であり、個々人はそれが意味するところについて異なる考えを持ち得ます。実体間の関係は、ツリー状というよりはウェブ状なので、ウェブについては認識が一致する人でも、ツリー構造の表現では異なった解釈をすることがあります。これは、一般的な解決策として階層構造による分類を採用することの危険性に関する、私の（何度も繰り返している）コメントです。
実際問題として、トピック名をURIに使うということは、何らかの分類に拘束されてしまうということを意味します。将来、何か違う分類を使いたくなるかもしれません。そうなったら、URIは破綻するしかないのです。
URIの一部にトピック分野を使う理由の一つは、URI空間の一部分に関する責任権限を委譲するということでしょう。その場合、その部分空間に責任を持つ組織体の名前 - 下部組織であれグループであれ何であれ - が必要になります。これは、URIを組織構造に結びつけるということに他なりません。これが安全であるのは、その上位のURI（つまり左側）が日付によって保護されている場合に限ります："1998/pics"は、サーバー上で「1998年に我々がpicsによって意味していたもの」と解釈することができ、「我々が今picsと呼ぶものについて、我々が1998にどんなことをしていたか」を意味することにはなりません。
ドメイン名のことも忘れずに
この議論は、URIの「パス」部分だけでなく、サーバー名に関しても当てはまることを忘れないでください。あなたのコンテンツの一部を別のサーバーに分割しているとしたら、その部分の変更は、実に多くのリンクを無効にせずには実行不可能であることを思い出してください。古典的な「私たちの現在使っているソフトを見てください」というタイプのドメイン名は、"cgi.pathfinder.com", "secure", "lists.w3.org"といったものです。これらはサーバーの管理を容易にするために名付けられたものです。その名前が会社の組織、ドキュメントの状態、アクセスレベル、セキュリティレベルなどのいずれを示すものであれ、一種類のタイプのドキュメントに複数のドメイン名を使うまえに、よーく、よーく熟慮すべきです。リダイレクトとプロキシを使えば、複数のサーバーを表向き一つのウェブサーバーに隠してしまえることを思い出してください。
ああ、そして、ドメイン名についてよく考えましょう。あなたの名前がsoapでもないのに、製品ラインを別のものに切り替えた後でも"soap.com"として参照されたいなんて思いますか？ （今現在、soap.comを所有している方、失礼しました）
結論
URIを2年、20年、200年あるいは2000年にわたって有効であるように維持するのは、明らかに言うほど簡単なことではありません。しかし、ウェブ全体において、ウェブマスターたちは、将来本当に自分の首を絞めることになるような決断を日々行っているのです。多くの場合、その理由は彼らの使っているツールが今の時点においてベストと思えるようなサイトをつくる働きをするものだからであり、また状況が変わったらリンクはどうなってしまうかについて誰も検証していないからです。しかし、私がここで伝えようとしているメッセージは、非常に多くの物事が変化するものであること、そしてあなたのURIは変化しないようにできるし、そうすべきだということです。それは、URIをどう設計するのかあなたが考えることによってのみ、可能になるのです。
以下も参照してください：
脚注
どうやったら拡張子なしのURIにすることができるのですか...
...ウェブサーバーは現実にはファイルで構成されているのですが？
たとえば、もしあなたがApacheを使っているのなら、サーバーがコンテントネゴシエーションに対応するように設定することができます。ファイルの（.pngのような）拡張子はそのまま（つまりmydog.pngのまま）にしておき、しかしウェブのリソースとしては拡張子なしで参照するように設定します。Apacheは、そのディレクトリ内で、その名前を持つ全てのファイルを、拡張子を問わずにチェックし、そしてその中から一番適切なもの（すなわちGIFとPNG）を選択することができます（異なるタイプのファイルを異なるディレクトリに格納する必要はありません。実際、そのようにした場合は、コンテントネゴシエーションは機能しません）。
- サーバーをコンテントネゴシエーションに対応させる
- 常に拡張子なしのURIでリソースを参照する
拡張子付きのリソース参照も問題なく機能しますが、その場合は、現在利用できるものや将来出現するファイルフォーマットの中から、サーバーが最適なものを選択することはできなくなります。
（mydog、mygog.png、mydog.gifはみな有効なりソースです。mydogはコンテントタイプ非依存であり、mygog.png、mydog.gifは特定のコンテントタイプに結びつけられたものです）
もちろん、もし独自サーバーを構築しているのなら、永続性のある識別子を現在の具体的なフォーマットに関連づけるためにデータベースを利用するのは、とてもきれいな解決策です。ただし、そのデータベースは、際限なく膨らんでいくことに注意しておいてください。
怒りの殿堂 -- その1: Channel 7
1999年に、私は雪による学校閉鎖について記述したページhttp://www.whdh.com/stormforce/closings.shtmlを見つけました。テレビ画面の下にテロップで情報が流れるのを待っている代わりの手段として！ 私は自分のホームページにそこへのリンクを貼りました。2000年最初の大嵐が来たとき、私はそのページをチェックしました。そこにはこう書かれていたのです：
＿の閉鎖状況：現在、閉鎖はありません。もし天候が悪くなったら再び確認してください。
こんな大嵐で、それはあり得ない。おかしなことに日付が抜けています。しかし、そのサイトのホームページに行ってみると、「学校閉鎖」という大きなボタンがありました。そこは、たくさんの学校閉鎖のリストが掲載されたページ http://www.whdh.com/stormforce/ にリンクされていたのです。
おそらく、彼らは完全な学校閉鎖リストに基づくよう、システムを変更したのでしょう - けれども、だからといってURIを変更する必要はなかったのです。
怒りの殿堂 -- その2: Microsoft Netmeeting
ウェブの普及がもたらした結構なことの一つに、アプリケーションソフトが開発会社のウェブサイトへのリンクをあらかじめ備えるようになったということがあります。これは相当活用され、また濫用されてもいます。しかし、そのURLは同じものがずっと使われていなければなりません。つい先日、私はマイクロソフトのNetmeeting 2/云々の"Help/Microsoft on the Web/Free stuff"というメニューからリンクを辿ろうとして、404エラー、つまりサーバーから「見つかりません」という返事を受け取りました。もう直しているかもしれませんが....