Cool URIs Don't Change (1998)

Cool URIs は変わらない クールなURIとは何か？ クールなURIとは、変わらないURIのことである。どのような種類のURIが変わるのか？ URIは変わらない：人々がそれを変えるのだ。理論上、URI（または文書の保守をやめること）を変える理由は全くないが、実際には何百万もの理由がある。理論上、ドメイン名の所有者はドメイン名空間を所有しており、したがってその中の全てのURIを所有している。破産以外に、ドメイン名の所有者がその名前を維持することを妨げるものはない。そして理論上、あなたのドメイン名下のURI空間は完全にあなたの制御下にあるため、好きなだけ安定させることができる。ウェブから文書が消える唯一のまともな理由は、ドメイン名を所有していた会社が事業をやめたか、サーバーを維持する余裕がなくなったことくらいだ。 では、なぜ世界にはこれほど多くのリンク切れがあるのか？ その一部は単なる見通しの甘さだ。ここには、世の中で聞かれるいくつかの理由がある： ウェブサイトをより良くするために再編成した。古いURIを維持できないと本当に感じているのか？ もしそうなら、あなたはそれらを非常に悪く選んだ。次の再設計の後もそれらを維持できるように、新しいURIを考えなさい。 あまりにも多くの資料があるので、何が古く、何が機密で、何が有効かを把握できず、全てを削除することにした。それは共感できる。W3Cもそのような期間を経験し、アーカイブを公開する前に機密性を注意深くふるいにかける必要があった。解決策は先見の明だ。各文書に、その許容される配布、作成日、そして理想的には有効期限を確実に記録すること。このメタデータを保持すること。 ファイルを移動する必要があった...これは最もくだらない言い訳の一つだ。多くの人が、Apacheのようなサーバーが、URIとそれが実際にファイルシステム上のどこにあるかの間の柔軟な関係を制御できることを知らない。URI空間を抽象空間として考え、完璧に整理する。次に、それを実装するために実際に使用する現実にマッピングする。そして、サーバーに伝える。それをちょうど良くするためにサーバーの一部を書くことさえできる。 ジョンはもうそのファイルを保守しておらず、ジェーンが保守している。そのURIはジョンの名前をどうして持っていたのか？ 彼のディレクトリにあったのか？ なるほど。以前はCGIスクリプトを使っていたが、今はバイナリプログラムを使っている。スクリプトによって生成されたページは "cgibin" または "cgi" エリアに配置されなければならないという奇妙な考え方がある。これは、サーバーの実行方法のメカニズムを露呈している。メカニズムを変更すると（内容を同じに保っても）、あらゆるところでURIが変わってしまう。例えば、国立科学財団を見てみよう：NSF Online Documents http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl 文書を探し始めるためのメインページは、数年後にそこにあると信頼できるものではないことは明らかだ。「cgi-bin」や「oldbrowse」や「.pl」は、現在のやり方の断片を示している。対照的に、文書を見つけるためにページを使用すると、まず同様に悪い暗号理論とコーディング理論に関するワーキンググループの報告 http://www.nsf.gov/cgi-bin/getpub?nsf9814 文書のインデックスページへのリンクが表示されるが、HTML文書自体は対照的に非常に優れている：http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm これを見ると、「pubs/1998」というヘッダーは、古い1998年の文書分類スキームが進行中であることを将来のアーカイブサービスに良い手がかりを与えるだろう。2098年になっても文書番号は異なるかもしれないが、このURIが有効であり続け、NSFまたはアーカイブを引き継ぐ組織がそれに恥じることはないだろうと想像できる。 URLは永続的である必要はないと思っていた。それはURNだった。これはURNの議論の最も悪い副作用の一つだろう。一部の人々は、より永続的な名前空間に関する研究があるので、URNが全てを修正してくれるだろうから、リンク切れについてはどんなに緩くても構わないと考えているようだ。もしあなたがこれらの人々のうちの一人なら、幻滅させてあげよう。私がこれまで見たほとんどのURNスキームは、権威IDに続いて、あなたが選んだ日付と文字列、または単にあなたが選んだ文字列のいずれかのようなものだ。これはHTTP URIに非常によく似ている。つまり、あなたの組織が永続するURNを作成できると考えるなら、今すぐそれを証明し、HTTP URIに使用することだ。HTTPには、URIを不安定にするようなものは何もない。それはあなたの組織だ。文書URNを現在のファイル名にマッピングするデータベースを作成し、ウェブサーバーがそれを使用して実際にファイルを取得できるようにする。 ここまでたどり着いたなら、ソフトウェア設計を行うための時間、お金、人脈がない限り、次の言い訳を主張するかもしれない：そうしたいのだが、適切なツールがない。これは私が共感できるものだ。全く同意する。あなたがする必要があるのは、ウェブサーバーが瞬時に永続的なURIを検索し、現在のあなたの奇妙なファイルシステムがどこに保存していてもファイルを取得できるようにすることだ。URIをファイルにチェックとして保存し、データベースを常に最新の状態に保ちたい。異なるバージョンの同じ文書や翻訳との関係を保存し、誤ったエラーによるファイル破損に対する保護としてチェックサムの独立した記録を保持したい。そして、ウェブサーバーにはこれらの機能が標準で搭載されていない。新しい文書を作成したいとき、エディタはURIを尋ねるのではなく、URIを要求する。URIを変更せずに、文書の所有権、アクセス権、アーカイブレベルのセキュリティレベルなどをURI空間で変更できる必要がある。残念だ。しかし、私たちはそこまでたどり着くだろう。W3CではJigedit機能（編集に使用されるJigsawサーバー）を使用しており、バージョンを追跡し、文書作成スクリプトを実験している。ツール、サーバー、クライアントを作成するなら、注意してください。 これは顕著な理由であり、例えばこのページを含む多くのW3Cページに適用される：だから私が言うことをやりなさい、私がやっていることではなく。なぜ気にする必要があるのか？ サーバー上のURIを変更すると、古いURIへのリンクが誰にあるかを完全に知ることは決してできない。通常のウェブページからリンクを作成したかもしれない。あなたのページをブックマークしたかもしれない。友人への手紙の余白にURIを書き留めたかもしれない。誰かがリンクをたどってそれが壊れたとき、彼らは一般的にサーバーの所有者への信頼を失う。また、目標を達成する上で感情的にも実用的にもフラストレーションを感じる。あまりにも多くの人が常にリンク切れについて不平を言うので、そのダメージは明白だと願っている。文書が消えたサーバーの保守者への評判のダメージも明白だと願っている。 では、何をすべきか？ URIの設計 Webマスターの義務は、2年後、20年後、200年後も維持できるURIを割り当てることだ。これには思考、組織、そしてコミットメントが必要だ。URIは、変更される情報が含まれている場合に変化する。それらをどのように設計するかが重要だ。（何、URIを設計する？ URIを設計しなければならないのか？ はい、考えなければならない）。設計とは、主に情報を省略することだ。文書の作成日、URIが発行された日、これは変更されないものの一つだ。新しいシステムを使用するリクエストと古いシステムを使用するリクエストを分離するのに非常に役立つ。URIを開始するのに良いものだ。文書が何らかの形で日付付けされている場合、たとえそれが世代にわたって興味深いものであっても、その日付は良い開始点となる。唯一の例外は、例えば組織全体またはその大部分の「最新」ページとして意図的に作成されたページだ。http://www.pathfinder.com/money/moneydaily/latest/ は、「Money」誌の最新の「Money daily」コラムだ。このURIに日付が必要ない主な理由は、URIの永続性が雑誌の寿命を超える理由がないことだ。「今日のマネー」という概念は、マネーが消滅すれば消滅する。