著者: ティム バーナーズ リー卿、URI、URL、HTTP、HTML、World Wide Web の発明者であり、W3C の現責任者。 1998 年に書かれた記事

どの URI が「クール」と考えられますか?
変わらないもの。
URIはどのように変更されるのでしょうか?
URI は変更されません。ユーザーが変更します。

理論的には、ユーザーが URI を変更する (またはドキュメントのサポートを停止する) 理由はありませんが、実際には URI が何百万も存在します。

理論的には、ドメイン名前空間の名目上の所有者は実際にドメイン名前空間を所有し、したがってそのドメイン名前空間内のすべての URI を所有します。 破産を除けば、ドメイン名の所有者がその名前を保持することを妨げるものはありません。 そして理論的には、ドメイン名の下の URI 空間は完全に制御下にあるため、好きなだけ安定させることができます。 ドキュメントがインターネットから消える唯一の正当な理由は、ドメイン名を所有していた会社が廃業したか、サーバーを稼働し続ける余裕がなくなったということです。 では、なぜ世界にはこれほど多くのミッシングリンクが存在するのでしょうか? このうちいくつかは、単純に先見性が欠如しているだけです。 以下のような理由が聞かれるかもしれません。

サイトをより良くするためにサイトを再編成しました。

古い URI はもう機能しないと本当に思いますか? もしそうなら、あなたはその選択が非常に間違っていたことになります。 次回の再設計のために新しいものを保持することを検討してください。

私たちには、何が古いのか、何が機密で、何がまだ関連しているのかを追跡できないほど多くのものがあるため、すべてをオフにするのが最善であると考えました。

同情するしかない。 W3C では、公開する前に機密保持のためにアーカイブ資料を注意深く選別する必要がある時期を経験しました。 決定は事前に検討する必要があります。各文書には、許容される読者層、作成日、そしてできれば有効期限を記録してください。 このメタデータを保存します。

さて、ファイルを移動する必要があることがわかりました...

これは最も情けない言い訳の一つです。 多くの人は、Web サーバーを使用すると、オブジェクトの URI とファイル システム内の実際の場所との関係を制御できることを知りません。 URI 空間は、完全に構成された抽象的な空間であると考えてください。 次に、それを実現するために実際に使用する現実へのマッピングを作成します。 次に、これを Web サーバーに報告します。 独自のサーバー スニペットを作成して適切に処理することもできます。

John はこのファイルを管理しなくなり、Jane が管理するようになりました。

ジョンの名前は URI にありましたか? いいえ、ファイルはちょうど彼のディレクトリにありましたか? まあいいよ。

以前はこれに CGI スクリプトを使用していましたが、現在はバイナリ プログラムを使用しています。

スクリプトで作成されたページは「cgibin」または「cgi」領域に配置する必要があるというおかしな考えがあります。 これにより、Web サーバーを実行する仕組みが明らかになります。 (コンテンツの保存中であっても) メカニズムを変更すると、おっと、すべての URI が変更されます。

国立科学財団 (NSF) を例に挙げてみましょう。

NSFオンライン文書

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 議論の最悪の副作用の XNUMX つです。 より永続的な名前空間が研究されているため、「URN がすべて解決してくれる」ため、ダングリング リンクについては無頓着になるのではないかと考える人もいます。 もしあなたがこれらの人々の一人であるなら、私はあなたを失望させてください。

私がこれまでに見たほとんどの URN スキームは、機関識別子の後に日付と選択した文字列、または選択した文字列のみが続くように見えます。 これは HTTP URI に非常に似ています。 言い換えれば、組織が有効期間の長い URN を作成できると思われる場合は、それを HTTP URI に使用して今すぐ証明してください。 HTTP 自体には、URI を不安定にする要素は何もありません。 あなたの組織だけです。 ドキュメント URN を現在のファイル名にマップするデータベースを作成し、Web サーバーがそれを使用して実際にファイルを取得できるようにします。

ここまで来て、ソフトウェアを開発するための時間、お金、人脈がない場合は、次のような言い訳をすることができます。

そうしたかったのですが、適切なツールがありません。

しかし、これには共感できます。 同意します。 あなたがしなければならないことは、Web サーバーに永続的な URI を瞬時に解析させ、現在のクレイジーなファイル システム上のどこにファイルが保存されているかにファイルを返すように強制することです。 すべての URI をチェックとしてファイルに保存し、データベースを常に最新の状態に保ちたいと考えています。 同じ文書の異なるバージョンと翻訳間の関係を保持し、また、偶発的なエラーによってファイルが破損しないように独立したチェックサム レコードを維持したいと考えています。 また、Web サーバーには、これらの機能が最初から備わっているわけではありません。 新しいドキュメントを作成する場合、エディターは URI を指定するように求めます。

URI を変更せずに、URI 空間内の所有権、ドキュメント アクセス、アーカイブ レベルのセキュリティなどを変更できる必要があります。

とても残念です。 しかし、私たちは状況を修正します。 W3C では、バージョンを追跡する Jigedit (ジグソー編集サーバー) 機能を使用し、ドキュメント作成スクリプトを実験しています。 ツール、サーバー、クライアントを開発する場合は、この問題に注意してください。

この言い訳は、このページを含む多くの W3C ページにも当てはまります。つまり、私が行うことではなく、私の言うとおりにしなさい。

なぜ気にする必要があるのでしょうか?

サーバー上の URI を変更する場合、誰が古い URI へのリンクを持つことになるのかを完全に知ることはできません。 これらは通常の Web ページからのリンクにすることができます。 ページをブックマークします。 URI は友人への手紙の余白に走り書きされた可能性があります。

誰かがリンクをたどってリンクが切れると、通常はサーバー所有者に対する信頼を失います。 彼はまた、目標を達成できないことで、精神的にも肉体的にもイライラしています。

多くの人がリンク切れについて常に苦情を言っていますが、被害が明らかであることを願っています。 文書が消失したサーバーの管理者に対する風評被害も明らかであることを望みます。

それで、どうすればいいでしょうか？ URIの設計

2 年後、20 年後、200 年後に使用できる URI を割り当てるのは Web マスターの責任です。 これには思慮深さ、組織力、決意が必要です。

URI 内の情報が変更されると、URI も変更されます。 どのようにデザインするかが非常に重要です。 (何、URI 設計ですか? URI を設計する必要がありますか? はい、それについて考えるべきです)。 デザインとは基本的に、URI 内の情報を省略することを意味します。

ドキュメントが作成された日付、つまり URI が発行された日付は、決して変更されません。 これは、新しいシステムを使用するクエリと古いシステムを使用するクエリを分離するのに非常に役立ちます。 ここは URI から始めるのに適しています。 文書に日​​付が付いている場合、たとえその文書が将来関連するとしても、これは良いスタートです。

唯一の例外は、たとえば組織全体またはその大部分に対して、意図的に「最新」バージョンであるページです。

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

『Money』誌の最新コラム「Money Daily」です。 この URI に日付が必要ない主な理由は、ログよりも存続する URI を保存する理由がないためです。 Money が消滅すると、Money Daily の概念も消滅します。 コンテンツにリンクしたい場合は、アーカイブ内で個別にリンクする必要があります。

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

(良さそうです。「お金」は pathfinder.com の存続期間を通じて同じ意味であると仮定します。重複した「98」と不要な「.html」がありますが、それ以外は強力な URI のように見えます。

何を残しておくべきか

全て！ 作成日以外の情報を URI に含めると、何らかのトラブルが発生します。

• 著者名。 新しいバージョンが利用可能になると、著者名が変更される可能性があります。 人々は組織を離れ、物事を他の人に引き継ぎます。
• 件名。 それはとても難しいです。 最初はいつも良く見えますが、驚くほどすぐに変化します。 これについては以下で詳しく説明します。
• ステータス。 「最新」や「クール」は言うまでもなく、「古い」、「ドラフト」などのディレクトリは、すべてのファイル システムに存在します。 ドキュメントのステータスは変更されます。そうでないと、ドラフトを作成する意味がありません。 ドキュメントの最新バージョンには、そのステータスに関係なく、永続的な識別子が必要です。 ステータスを名前に含めないでください。
• アクセス。 W3C では、サイトを従業員、メンバー、一般向けのセクションに分割しました。 これは聞こえはいいですが、当然のことながら、ドキュメントはスタッフからのチームのアイデアとして始まり、メンバー間で議論され、その後公知になります。 幅広い議論のためにドキュメントが開かれるたびに、そのドキュメントへの古いリンクがすべて壊れてしまったら、本当に残念です。 次に、単純な日付コードに進みます。
• ファイル拡張子。 非常に一般的な出来事です。 「cgi」、「.html」も将来的には変更される予定です。 このページに HTML を使用するのは 20 年後かもしれませんが、現在のページへのリンクはまだ機能するはずです。 W3C サイトの正規リンクでは拡張子 (それはどのように行われますか).
• ソフトウェアの仕組み。 URI で、「cgi」、「exec」、および「使用しているソフトウェアを見てください」と叫ぶその他の用語を探します。 Perl CGI スクリプトの作成に一生を費やしたい人はいますか? いいえ？ 次に、.pl 拡張子を削除します。 これを行う方法については、サーバーのマニュアルを参照してください。
• ディスク名。 来て！ しかし、私はこれを見たことがあります。

したがって、私たちのサイトの最良の例は単純に次のとおりです

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

... W3C議長会議の議事録を報告します。

トピックとトピック別の分類

この危険は最も避けるのが難しいものの 3 つであるため、この危険について詳しく説明します。 通常、ドキュメントを作業ごとに分類すると、トピックは URI になります。 しかし、この内訳は時間の経過とともに変化します。 エリアの名前が変わります。 W100C では、セクションの実際のコンテンツを反映するために、MarkUP を Markup に変更し、次に HTML に変更したいと考えていました。 さらに、多くの場合、フラットな名前空間が存在します。 XNUMX年後、何も再利用したくないと思いますか? 私たちの短い人生の中で、たとえば「履歴」や「スタイルシート」を再利用したいとすでに考えています。

これは Web サイトを整理するための魅力的な方法であり、Web 全体を含むあらゆるものを整理するための本当に魅力的な方法です。 これは中期的には優れた解決策ですが、長期的には重大な欠点があります。

その理由の一部は意味の哲学にあります。 言語のすべての用語はクラスタリングの対象となる可能性があり、それが何を意味するかについては人によって異なる考えがある可能性があります。 エンティティ間の関係はツリーというよりウェブに似ているため、ウェブに同意する人でも、ツリーの異なる表現を選択する可能性があります。 これらは、一般的な解決策としての階層分類の危険性についての、私の (頻繁に繰り返される) 一般的な観察です。

実際、URI でトピック名を使用すると、ある種の分類に取り組むことになります。 おそらく将来的には、別のオプションを選択することになるでしょう。 その場合、URI は違反されやすくなります。

サブジェクト領域を URI の一部として使用する理由は、通常、URI 空間のサブセクションに対する責任が委任されており、その場合、そのサブスペースを担当する組織団体 (部門、グループなど) の名前が必要になるためです。 これは、組織構造にバインドされる URI です。 通常、これは、さらに先の (左側の) URI が日付で保護されている場合にのみ安全です。 1998/pics は、サーバーにとって、「1998 年に、現在写真と呼ばれるもので何をしたか」ではなく、「1998 年に写真で何を意味したか」を意味する可能性があります。

ドメイン名を忘れないでください

これは、URI 内のパスだけでなく、サーバー名にも適用されることに注意してください。 さまざまな用途に別々のサーバーを使用している場合は、非常に多くのリンクを破棄せずにこの分割を変更することは不可能であることに注意してください。 「現在使用しているソフトウェアを見てみましょう」という典型的な間違いには、ドメイン名「cgi.pathfinder.com」、「secure」、「lists.w3.org」などがあります。 これらはサーバー管理を容易にするように設計されています。 ドメインが会社内の部門、ドキュメントのステータス、アクセス レベル、またはセキュリティ レベルを表すかどうかに関係なく、複数のドキュメント タイプに複数のドメイン名を使用する前に、十分に注意してください。 リダイレクトとプロキシを使用すると、表示される単一の Web サーバー内に複数の Web サーバーを隠すことができることに注意してください。

ああ、ドメイン名についても考えてみましょう。 製品ラインを変更して石鹸の製造をやめた後は、soap.com と呼ばれるのは望ましくありません (現在、soap.com を所有している人には申し訳ありません)。

まとめ

URI を 2 年、20 年、200 年、さらには 2000 年保存することは、思っているほど簡単ではないことは明らかです。 しかし、インターネット全体で、ウェブマスターは、将来的にこのタスクを非常に困難にするような決定を下しています。 多くの場合、これは、現時点で最適なサイトのみを表示することを目的としたツールを使用しているためであり、すべてが変化したときにリンクに何が起こるかを誰も評価していないためです。 ただし、ここで重要なのは、非常に多くのことが変更される可能性があり、URI は変更しないことが可能であり、変更する必要があるということです。 これは、どのように作成するかを考えた場合にのみ可能になります。

まあ参照してください。

• 同じテーマに関するヤコブ・ニールセンの暴言

追加

ファイル拡張子を削除する方法...

...現在のファイルベースの Web サーバーの URI から?

たとえば、Apache を使用する場合は、コンテンツをネゴシエートするように構成できます。 ファイル拡張子 (例: .png) をファイル (例: .png) に保存します。 私の犬.png) ですが、それがなくても Web リソースにリンクできます。 次に、Apache は、その名前と拡張子を持つすべてのファイルのディレクトリをチェックし、セットから最適なもの (GIF や PNG など) を選択します。 また、異なる種類のファイルを異なるディレクトリに置く必要はありません。実際、そうするとコンテンツの一致が機能しなくなります。

• コンテンツをネゴシエートするためにサーバーをセットアップする
• 常に拡張子なしの URI にリンクする

拡張子付きのリンクは引き続き機能しますが、サーバーは現在および将来的に利用可能な最適な形式を選択できなくなります。

（実際には、 mydog, mydog.png и mydog.gif — 有効な Web リソース、 mydog ユニバーサルコンテンツタイプのリソースであり、 mydog.png и mydog.gif — 特定のコンテンツ タイプのリソース）。

もちろん、独自の Web サーバーを作成している場合は、データベースを使用して永続的な識別子を現在の形式にバインドすることをお勧めしますが、データベースが無制限に増大することに注意してください。

恥の掲示板 - ストーリー 1: チャンネル 7

1999 年、私は雪による学校閉鎖をページで追跡しました。 http://www.whdh.com/stormforce/closings.shtml。 テレビ画面の下部に情報が表示されるまでお待ちください。 私のホームページからリンクさせていただきました。 2000 年最初の大雪が到来し、ページを確認しました。 そこにはこう書かれています:、

- 現在。
現在閉店しているものはありません。 気象警報が出た場合はお戻りください。

そんなに強い嵐になるはずがない。 日付が抜けているのがおかしい。 ただし、サイトのメインページに移動すると、「廃校」という大きなボタンがあり、そのページに移動します http://www.whdh.com/stormforce/ 廃校の長いリストもある。

おそらくリストを取得するシステムを変更したのでしょうが、URI を変更する必要はありませんでした。

Board of Shame - ストーリー 2: Microsoft Netmeeting

インターネットへの依存が高まるにつれ、メーカーの Web サイトへのリンクをアプリケーションに埋め込むことができるという賢いアイデアが生まれました。 これはよく使用され、悪用されていますが、URL は変更できません。 つい先日、ヘルプ/Microsoft on the Web/無料のものメニューにある Microsoft Netmeeting 2/何かのクライアントからリンクを試みましたが、404 エラーが発生しました - サーバーからの応答が見つかりませんでした。 もしかしたらもう修正されているかもしれませんが…

©1998 ティム・BL

歴史的メモ: これが書かれた 20 世紀後半では、「クール」は、特に若者の間で、ファッション性、品質、または適切さを示す承認の形容詞でした。 急いでいると、URI パスは、有用性や耐久性よりも「かっこよさ」を理由に選択されることがよくありました。 この投稿は、クールの探求の背後にあるエネルギーを方向転換する試みです。

出所： habr.com