この文書「セマンティック Web のためのクールな URI」は、W3C の Semantic Web Education and Outreach (SWEO) Interest Group による「Cool URIs for the Semantic Web (W3C Interest Group Note 03 December 2008)」の日本語訳です。

規範的な文書は原文のみとなっています。この日本語訳は参考情報であり、正式な文書ではないことにご注意ください。また、翻訳において生じた誤りが含まれる可能性があります。

原文の最新版 は、この日本語訳が参照した版から更新されている可能性があります。また、この日本語訳自身も更新されている可能性があります。日本語訳の最新版は、W3C 仕様書 日本語訳一覧 から参照することができます。

更新日:
2010-03-12
公開日:
2008-04-14
翻訳者:
矢倉 眞隆 <>
W3C

セマンティック Web のためのクールな URI

2008 年 12 月 3 日付 W3C 分科会ノート (Interest Group Note)

この版:
http://www.w3.org/TR/2008/NOTE-cooluris-20081203/
最新版:
http://www.w3.org/TR/cooluris/
前の版:
http://www.w3.org/TR/2008/WD-cooluris-20080331/
編集者:
Leo Sauermann (DFKI GmbH)
Richard Cyganiak (DERI, NUI Galway and Freie Universität Berlin)
貢献者:
Danny Ayers (Talis Information Ltd.)
Max Völkel (FZI Karlsruhe)

修正があるかもしれませんので、errata も参照してください。

Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

概要

Resource Description Framework (RDF) によって、ユーザーは Web 上の文書や、現実世界に存在する人や組織、また事柄や物などの概念について、コンピュータが処理可能な状態で説明することができるようになります。そして、機械処理可能な情報を Web 上に公開することで、セマンティック Web を構築することができるのです。Web と RDF をリンクし、またそのフレームワークを提供するにあたり、URI (Uniform Resource Identifier) はとても重要な概念です。この文書は、URI の効果的な利用法をガイドラインとして提示します。具体的には、303 URI と ハッシュ URI という、二つの方法について解説します。また、これらの手法を利用する Web サイトの例を取り上げ、さらに他の方法が持つ問題点についても簡単に説明します。

この文書のステータス

この章は、この文書の公開時におけるステータスについて説明しています。このため、他の仕様がこの文書を上書きしている可能性があります。W3C による他の出版物およびこの技術レポートの最新版は W3C 技術レポートインデックス (http://www.w3.org/TR/) で探すことができます。

この文書は、セマンティック Web 技術への新参者のために、TAG の決定を説明する W3C 分科会ノート (Interest Group Note) です。この文書は DFKI Technical Memo TM-07-01, Cool URIs for the Semantic Web を基とし、W3C 草案 (Working Draft) として 2007 年 12 月、そして 2008 年 3 月 に公開されました。このノートは W3C Semantic Web Activity の W3C Semantic Web Education and Outreach (SWEO) Interest Group による活動の成果報告です。草案は公開され、特に Technical Architecture Group (TAG) と Semantic Web Deployment Group (SWD) によるレビューが行われました。前のバージョンからの変更点はひとつだけで、それは errata へのリンクを追加したことです。

Semantic Web Education and Outreach (SWEO) Interest Group の憲章は 2008 年 3 月に失効しました。しかし、この文書は別のグループにより改訂されるかもしれません。よって、この文書に対するフィードバックがあれば是非行ってください。コメントは public-sweo-ig@w3.org (公開アーカイブ) までお願いします。changelog も存在しています。

分科会ノートとしての仕様書公開は、W3C メンバーによる支持を意味するものではありません。この文書は更新されたり他の文書と置き換えられたり、また破棄される可能性もある草稿段階の仕様書です。策定中ということを明記せずに、この文書を引用することは適当でありません。

この文書は 5 February 2004 W3C Patent Policy の下で活動するグループにより作成されました。W3C は 特許情報の開示に関する公開リスト を関連する団体と共に、その成果物とあわせて管理しています。リストには情報開示に関する説明もありますので、ご参照ください。特許について十分に知識のある人物が、当該仕様に関し Essential Claim(s) が認められると判断した場合は、W3C 特許方針の第 6 章 に従い情報を開示する必要があります。

対象読者

この文書は、RDF 仕様を実装する方のために書かれた実践的ガイドです。タイトルは Tim Berners-Lee による "クールな URI は変わらない (Cool URIs don't change)" [Cool] にインスパイアされたものです。このガイドでは、HTTP サーバーにて RDF データをホストする、二つの方法について解説しています。想定する読者として、RDF URI を HTTP にてモデリングしたいと考えている、Web 開発者やオントロジー開発者が挙げられます。このため HTTP ではない URI を利用するアプリケーションについては触れていません。この文書は、また既に公開されている技術仕様の内容を補足する、参考文書という位置づけです。303 URI は Technical Architecture Group (TAG) による httpRange-14 resolution [httpRange] を基としています。想定読者は、RDF データモデルの基本 [RDFPrimer] についてよく知っており、また HTTP プロトコル [RFC2616] についてもある程度の知識を持っている人としています。HTTP については Wikipedia の記事 [WP-HTTP] に良い解説があるので、参照してください。

目次

1. はじめに

セマンティック Web とは、統合にかかるコストを最小限に抑えたうえで、機械処理可能なデータを共有できる、分散的でワールドワイドな情報システムのことです。セマンティック Web への課題として、共有されたデータモデルによる分散的な世界のモデル作りと、データやスキーマの公開・発見・利用が可能なインフラの構築が挙げられています。ユーザーにとって、"そのままの状態で今すぐ (raw and now)" [Give]、またポータブルなデータフォーマット [DP] で情報を入手することが利益となります。しかし、情報発信者は多くの場合、固定されたユーザーインターフェースや、HTML によりデータを公開しています。つまり、「どのようにすれば、リソースに関する情報をその情報に興味を持っているユーザーやアプリケーションに対して公開できるのか。」という疑問がこの問題の根幹なのです。

セマンティック Web では、すべての情報が リソース (resources) に関する ステートメント (statements) として表されます。たとえば、「Example.com という会社のメンバーは Alice と Bob です。」や「Bob の電話番号は "+1 555 262" です。」、「この Web ページは Alice が製作しました。」などです。リソースは Uniform Resource Identifier (URI) [RFC3986] で識別されます。このモデリングによるアプローチが、Resource Description Framework (RDF) [RDFPrimer] の真髄なのです。より詳しい説明は、N3 入門にまとめられています [N3Primer]。

RDF を用いることで、このようなステートメントを企業の Web サイトから発信することができます。他の人はそのデータを読み、また既存の情報にリンクさせ、独自に情報を公開することもできます。結果として、世界の分散的なモデルを構築することができるのです。このモデルによって、ユーザーはデータを処理するアプリケーションを自由に選ぶことができるようになります。たとえば、Alice の公開したアドレスを、あなたのアドレス帳で読むときなどに、その利便性が活かされます。

さて、Web 上にある文書は常に URI (一般的に Uniform Resource Locators や URL と呼ばれています) によりアドレスされます。URI は、Web ページに関する RDF ステートメント (RDF statements) を作成する時にとても便利ですが、危険なものでもあります。なぜなら、その Web ページと、そのページで説明されている物やリソースとの区別がつきにくいからです。

では、どんな URI を RDF で用いればよいのでしょうか。たとえば、Example Inc. という会社なら、その Web サイトのトップページは http://www.example.com/ で識別させることができるでしょう。しかし、どの URI が Web サイトではなく、その会社や組織自体を識別するものになるのでしょうか。HTML 文書や RDF ファイルを含めたすべてのコンテンツを、その URI から抽出しなければならないのでしょうか。この文書はそのような疑問に対し、関連する使用に基づいて解説をおこなう文書です。私たちは人や製品、場所、アイデア、オントロジーにおけるクラスなどの概念といった Web ページではないものに、どう URI を使えばいいのかを説明します。また、セマンティック Web が Web の一部として理解されるために、いくつかの例を挙げ解説します。

2. Web 文書の URI

では、例から始めましょう。Example Inc. という、"エクストリームなギターアンプ (Extreme Guitar Amplifiers)" を生産している会社があり、その Web サイトは http://www.example.com/ だとします。サイトには各従業員について書かれたページがあり、名前とその他の情報が掲載されています。Example Inc. には Alice と Bob というふたりの従業員がいるので、Web サイトは次のような構造になっています。

http://www.example.com/
Example Inc. のホームページ
http://www.example.com/people/alice
Alice のホームページ
http://www.example.com/people/bob
Bob のホームページ

今までの Web と同じように、これらのページは Web 文書 (Web documents) です。すべての Web 文書は URI を持ちます。しかし、Web 文書はファイルそのものではありません。一つの Web 文書は、異なる言語やフォーマットで表すことができるのです。しかし、一つのファイル、たとえば PHP スクリプトは、それぞれ異なる URI を持つ、膨大な数の Web 文書を生成することがあるかもしれません。Web 文書とは URI を持ち、HTTP リクエストに応じて識別されたリソース 表現 (representations) (HTML や JPEG、RDF のようなフォーマットによるレスポンス) を返すことができるものとして定義されています。 Architecture of the World Wide Web, Volume One [AWWW] などの技術的な文書では、情報リソース (Information Resource) という言葉が Web 文書 の代わりに使われています。

今までの Web では、URI は 優先的に、Web 文書に対し使われていました。たとえば、リンクを張ったり、ブラウザからアクセスするときなどです。しかし、リソースの 識別子 (identity) としての側面はあまり重要ではありませんでした。URL はただ、私たちがブラウザにタイプしたときに現れるものを識別していただけなのです。

2.1. HTTP と コンテントネゴシエーション

Web クライアントとサーバーは、HTTP プロトコル [RFC2616] を介して Web 文書の各種表現をリクエストし、そのレスポンスを受け取ります。HTTP は異なるフォーマットや言語を持つ一つの Web 文書を提供するために、コンテントネゴシエーション (content negotiation) という強力なメカニズムを備えています。

ブラウザなどのユーザーエージェントが HTTP リクエストを行うとき、ユーザーエージェントはいくつかの HTTP ヘッダを送信し、どのデータフォーマットや言語を希望しているのかを伝えます。サーバーはそのリクエストに対し、一番適したものを選ぶ、または要求されたコンテンツを動的に生成し、クライアントに返信します。たとえば、ブラウザが http://www.example.com/people/alice に関して、英語またはドイツ語で書かれた HTML 文書または XHTML 文書を要求するとします。このとき、ブラウザが送信する HTTP リクエストは次のようなものとなります。

GET /people/alice HTTP/1.1
Host: www.example.com
Accept: text/html, application/xhtml+xml
Accept-Language: en, de

サーバーは次のように応答するでしょう。

HTTP/1.1 200 OK
Content-Type: text/html
Content-Language: en
Content-Location: http://www.example.com/people.en.html

そして、レスポンスにあるとおり英語版の HTML 文書が返ってきます。コンテントネゴシエーション はこの流れのなかで行われています [TAG-Alt]。サーバーはリクエスト内の Accept-Language ヘッダを解釈し、該当するリソースの英語版を返すと決定します。さて、英語版リソースの URI はここで Content-Location ヘッダに戻されます。これは必須事項ではありませんが、推奨されている挙動です ([CHIPS] 7.2 をご覧ください)。こうすることで、クライアントはこの URI が特定の表現 (この場合は英語版の文書) に結びついていると理解し、また検索エンジンは異なる URI から別のリソースを参照することができます。つまり、同じリソースに複数の表現を持たせることが可能となるのです。

コンテントネゴシエーションは多くの場合、ちょっとした仕掛けつきで実装されています。サーバーは直接リクエストした結果を返すのではなく、適当なリソース表現が見つかった URL に リダイレクトする のです。

HTTP/1.1 302 Found
Location: http://www.example.com/people/alice.en.html

リダイレクトは 302 Found という、特別な ステータスコード (Status Code) で表されます。クライアントはこれを受け、新しい HTTP リクエストをリダイレクト先の URL に送信します。表現ごとに異なる URL を設けることで、Web 製作者は特定の表現にリンクすることができるのです。

RDF の標準構文である RDF/XML は、application/rdf+xml という、独自の content type を持っています。よって、コンテントネゴシエーションにより、旧来の Web ブラウザには HTML 版の Web 文書を、そしてセマンティック Web ユーザーエージェントには RDF 版を提供することができるのです。また、サーバーに Notation3 [N3] 版や TriX [TriX] 版など、別の構文で RDF を提供させることも可能となります。

3. 実世界のオブジェクトにつける URI

セマンティック Web において、URI は Web 文書のみを識別するわけではありません。人や車など、実世界にあるものも識別します。さらには、抽象的な概念や、ユニコーンなど架空の生き物まで識別します。私たちはこれらすべてを 実世界のオブジェクト (real-world objects)、または単に 「もの」 と呼んでいます。

さて、実世界のオブジェクトにつけられた URI から、私たちはどのようにして URI が識別するオブジェクトを見つけることができるのでしょうか。それぞれ独立している情報システムの相互運用性を確保するためにも、何らかの回答を見つける必要があります。検索エンジンのように、識別されたリソースを探すようなサービスがあればよいのかもしれません。しかし、このような単一のやりかたは Web の分散的な性質に反してしまいます。

リソースの説明 (resource descriptions) を検索するサービスには、Web 自身を活用するべきなのです。なぜなら、Web はとても堅牢でスケーラブルな情報公開システムだからです。URI が言及されるたびに、私たちは関連する情報の説明や、関連するデータへのリンクを検索して見つけだします。これはとても重要なことであるため、これを クールな URI における一番大きな要件とします。

1. Web にあること (Be on the Web.)
URI のみが与えられた状態において、機械や人間はその URI により識別されたリソースの説明を Web から得られるようにするべきです。このような検索メカニズムは、URI が何を識別するのかを理解し、その理解を共有する際にとても重要です。また、機械は RDF データを受け取り、人間は HTML など読むことのできる表現を受け取るべきです。また、その際には Web の標準通信プロトコルである、HTTP が利用されるべきです。

Example Inc. が、従業員のコンタクト情報をセマンティック Web 上に公開し、彼らのビジネスパートナーがそのデータをアドレス帳に登録できるようにしたいと考えているとします。たとえば、Alice に関する次のようなステートメントが、N3 構文 [N3] により公開されているとします。

<URI-of-alice> a foaf:Person;
    foaf:name "Alice";
    foaf:mbox <mailto:alice@example.com>;
    foaf:homepage <http://www.example.com/people/alice> .

さて、<URI-of-alice> というプレースホルダの代わりに、どのような URI を用いればよいのでしょうか。まず、http://www.example.com/people/alice を使うことはできません。なぜなら、この URI はさまざまな誤解を生じるおそれがあるからです。「Alice のホームページは“Alice”というタイトルなの?」、「ホームページが e メールアドレスを持っているの?」」、「ホームページがホームページを持つことなんてできるの?」など、数々の疑問が生まれてしまいます。ですから、他の URI が必要となります。(この問題に関するより深い考察が What HTTP URIs Identify? [HTTP-URI2] と Four Uses of a URL: Name, Concept, Web Location and Document Instance [Booth] という記事にまとめられています。)

したがって、二つ目の要件は次のようになります。

2. 曖昧でないこと (Be unambiguous.)
識別子は、それが文書に対するものなのか、または他のリソースに対するものなのか、混乱がないようにはかるべきです。URI が識別するのは一つのものだけとされているため、一つの URI が Web から取得可能な文書と、実世界のオブジェクトの両方を示すことはできないのです。

しかしこの二つの要件は、互いに矛盾しているように感じます。もし文書の URI を実世界のオブジェクトを識別するために用いることができないのならば、それらが持つ URI からどのように表現を取得することができるのでしょうか。したがって、リソースの URI のみを与えられたとき、それを説明する文書をどのように見つけるのか、また標準の Web 技術を用いてどう実装するのかが課題となってきます。

次に示す画像は、リソースとそれを表現する文書の理想的な関係を表しています。

リソースとその説明をする文書

3.1 Web 文書と実世界のオブジェクトの識別

重要なのは、URI を利用することで、(Web の外に存在しうる)「もの」と、「もの」を説明する Web 文書のどちらをも識別することが可能だということです。たとえば、人物である Alice が彼女のホームページで説明されているとします。Bob はその ホームページの 見た目が好きではありませんが、Alice という人は魅力的だと思っています。この違いを説明するには、Alice に一つ、そして Alice について説明するホームページや RDF 文書に一つ、計二つの URI が必要となります。問題は、「もの」と文書のどちらも存在している場合と、文書のみが存在している場合について、どこで線引きを行うかということです。

W3C のガイドライン ([AWWW], section 2.2.) によれば、リソースがすべての重要な性質をメッセージとして伝達できる場合において、それは Web 文書 (ガイドラインでは 情報リソース と表記) になるとされています。例として Web ページや画像、製品カタログといったものが挙げられます。

HTTP では、Web 文書にアクセスがあったとき、200 レスポンスコードが送られます。このため Web 文書ではなく、実体を識別する URI を公開するときには、異なる設定が必要となります。

次のセクションでは、「もの」に対する URI を作成する方法について、またクライアントが標準的な Web 技術を利用して「もの」の説明を取得するための方法について解説します。

4. 二つの解決策

実世界のオブジェクトを識別するための要件を満たす解決策は、二つ存在します。303 URI と呼ばれる手法と、ハッシュ URI と呼ばれる手法です。それぞれに長所と短所があるため、状況によりこれらを使い分けることになります。

次に解説する二つの解決策は、HTML 文書とともに配信されるスタンドアロンな RDF/XML 文書というように、RDF データと HTML データが分けられて配信されるというシナリオに対応するものです。メタデータは RDFa [RDFa Primer] や microformats、また GRDDL [GRDDL] のメカニズムなどによって、HTML に埋め込むことができます。このような場合において、RDF データは返される HTML 文書から抽出されることとなります。

4.1. ハッシュ URI

最初の解決策は、非文書リソースに“ハッシュ URI”を用いるというものです。URI は フラグメント (fragment) という、ハッシュ記号 (“#”) により区分けされた特別な部分をもつことができます。

クライアントが ハッシュ URI からリソースを取得するとき、HTTP プロトコルはその URI につけられたフラグメントを、サーバーからリクエストする前に取り除くことが必須とされています。これは、ハッシュを持つ URI は直接取得することができないということであり、つまりハッシュ付き URI は Web 文書を識別するものに必ずしもならないということなのです。この特徴を利用し、私たちはハッシュ付き URI を、曖昧さを残すことなく、非文書リソースを識別するために利用することができます。

Example Inc. がハッシュ URI を使う場合、会社、Alice、Bob を表す URI は次のようなものになります。

http://www.example.com/about#exampleinc
Example Inc. という会社
http://www.example.com/about#bob
Bob という人物
http://www.example.com/about#alice
Alice という人物

クライアントはこれらの URI をリクエストする前に、そのフラグメントを取り除きます。結果として、次の URI をリクエストすることになります。

http://www.example.com/about
Example Inc. や Bob、Alice を説明する RDF 文書

Example Inc. はこの URI から、各リソースを説明する RDF 文書を提供することができます。各リソースは先ほどのハッシュ付きの URI を用いて説明されます。

次の図では、コンテントネゴシエーションを用いない、ハッシュ URI の利用法を説明しています。

コンテントネゴシエーションを用いないハッシュ URI による解決策

コンテントネゴシエーション (Section 2.1. を参照) を用い、about という URI から HTML または RDF 表現にリダイレクトを行うという方法もあります。このときどちらにリダイレクトされるかは、Section 4.7 にある通り、クライアントとサーバーの設定によります。ハッシュ URI が HTML 文書の一部、または RDF 文書を表すときは、Content-Location ヘッダを設定すべきです。

次の図は、コンテントネゴシエーションを用いるハッシュ URI の使い方を解説しています。

コンテントネゴシエーションを用いたハッシュ URI による解決策

4.2. 303 URI で一つの包括的な文書に転送する

二番目の解決策は、特別な HTTP ステータスコード 303 See Other を利用し、リクエストしたリソースが通常の Web 文書ではないということを示す方法です。Web アーキテクチャでは、「もの」を表すリソース (URI) が 200 を返すのは適切ではないとしています。なぜなら、そのリソースに関する適切な表現は Web 上に存在することがないからです。しかしながら、リソースに関する情報を提供することはとても有用であり、また便利です。このため、W3C の Technical Architecture Group は、httpRange-14 resolution [httpRange] というメッセージにおいて、リクエストした「もの」に関する情報をまとめた文書へ誘導するという解決策を提示しています。303 ステータスコードを利用することで、リソースが実世界に存在するオブジェクトそのものを表すのか、またはリソースを表現する情報なのかをはっきり区別することができます。

303 はリダイレクトを行うステータスコードです。サーバーはこのステータスコードにより、リソースを表現する文書の場所を伝えることができます。もし、リクエストが 200 OK といった一般的な 2XX ステータスコードで返された場合、クライアントはその URI が Web 文書だと知ることができます。

Example Inc. がこの解決策をとる場合、次の URI により、会社自身と、Alice、Bob を表すことができます。

http://www.example.com/id/exampleinc
Example Inc. という会社
http://www.example.com/id/bob
Bob という人物
http://www.example.com/id/alice
Alice という人物

Web サーバーは、303 ステータスコードと Location HTTP ヘッダのついた URI へのリクエストすべてに答えるよう設定される必要があります。Location ヘッダにより提供される URL はリソースを表現する文書のものとなります。例としては、http://www.example.com/id/alice という人物そのものの URI から、http://www.example.com/doc/alice という文書の URI へリダイレクトするなどが考えられます。

コンテントネゴシエーションは、文書の URI から HTTP リクエストによって表現を取得するときに利用されます。サーバーは HTML または RDF (またはその他の形式) のどれを返すかを決定し (Section 4.7 を参照) 、Content-Location ヘッダにより表現の URI を指定します。

この設定は RDF と HTML (またはその他の形式) が 同じ内容を違う形式で 伝えているときに用いられるべきです。もし取得できる情報に内容の大きなばらつきがある場合、次に記す 別の 303 による解決策を利用すべきです。

一つの文書を用意し、そこにリダイレクトさせるというこの方法を図で表すと次のようになります。

一つの包括的な文書による解決策

この設定では、サーバーは識別子の URI から文書の URI へ転送しています。こうすることで、クライアントは文書をブックマークしたり、その他の処理を行うことができるという利点があります。ユーザーが RDF を理解するクライアントを利用している場合、文書をブックマークし、別のユーザー (またはデバイス) に送信し、そのユーザーは送信された文書から HTML 版 または RDF 版を取得するということも可能です。また、サーバーは新しい言語の表現をあとから追加することもできます。これは「もの」自身の URI が基点となっているためで、表現を増やしても、「もの」自身の URI に影響があるわけではないのです。包括的な文書リソースの背景は [GenRes] で解説されています。

4.3. 303 URI で異なる文書に転送する

RDF と HTML のリソース表現は大きく異なる場合、包括的な文書に転送する方法は使うべきでありません。それらは同じ文書の異なるバージョンという意味ではなく、別々の文書だからです。Web サーバーは 303 ステータスコードと Location HTTP ヘッダを利用し、リソースを表現する文書の URL を提供するように設定されるべきです。

次の図は、包括的な文書の URI を利用しない、303 URI によるリダイレクトについて説明しています。

303 URI による解決策

サーバーはコンテントネゴシエーション (Section 2.1. を参照) を用い、HTML 文書の URL か RDF を送信することができます。HTML コンテンツへの HTTP リクエストは Section 2 で解説した、HTML 文書への URL にリダイレクトされます。RDF データへのリクエストは、次のような RDF 文書へとリダイレクトされます。

http://www.example.com/data/exampleinc
Example Inc. という会社を説明する RDF 文書
http://www.example.com/data/bob
Bob という人物を説明する RDF 文書
http://www.example.com/data/alice
Alice という人物を説明する RDF 文書

各 RDF 文書は、説明されたリソースを識別するため、適切なリソースについて説明したステートメントを含むでしょう。ステートメントにはもとの URI である http://www.example.com/id/alice などを利用します。

4.4. 303 とハッシュの選択

ハッシュ URI と 303 URI、一体どちらのアプローチが良いのでしょうか。ハッシュ URI は HTTP の往復を減らすことができるため、待ち時間を節約することができます。ハッシュ URI では、URI にハッシュを含まない共通部分を持ちます。たとえば、三つのリソース http://www.example.com/about#exampleinc、http://www.example.com/about#alice、http://www.example.com/about#bob は、http://www.example.com/about へのリクエストを一回行うだけで取得することができます。しかし、このアプローチには欠点もあります。たとえ #product123 のみに興味があるクライアントでも、他のリソースが同じファイルにあるため、すべてを取得する必要があるのです。この点において 303 URI はフレキシブルであり、各リソースに対してそのリダイレクト先を個別に設定することができます。たとえば、リソースごとに解説文書を用意する、すべてのリソースを解説する一つの文書を用意する、またはこれらを組み合わせて利用することもできます。この場合、リダイレクトのポリシーを後で変更することもできます。

FOAF など、303 URI をオントロジーの定義に利用する場合があります。このとき、ネットワークの遅滞によりクライアントのパフォーマンスが低下する可能性があります。リダイレクト数が多くなるにつれ、待ち時間が長くなってしまうのです。これは、リダイレクトから語彙を検索するクライアントは、たとえ最初のリクエストで必要な情報すべてを得たとしても、なお多くのリクエストを投げてしまうことがあるからです。

303 URI に解決策では大量のデータセットをホストする場合、クライアントはすべてのデータを、多くのリクエストを用いて取得しようとします。SPARQL エンドポイントや類似する複雑なクエリーをサーバー側で直接解釈するサービスを提供することを推奨します。大きなデータを HTTP によって取得させるよりも効率が良いからです。

また、303 とハッシュは組み合わせて利用できることにも注目してください。組み合わせることにより、大きなデータセットを複数のパーツに分散させ、非文書リソースに識別子を設けることができるようになります。次に示すのは、303 とハッシュを組み合わせた例です。

http://www.example.com/bob#this
組み合わせた URI により表現される Bob という人物。

どのようなフラグメント識別子も妥当なものとなります。上記の this も、おすすめする一つの例です。

結論
ハッシュ URI は、すべてのリソースが共に発展する、小さなリソースセットにおいておすすめです。理想的なケースとして、定義が共に利用され、また将来的に管理できない規模になることのない RDF スキーマや OWL オントロジーなどが挙げられます。

コンテントネゴシエーションを用いないハッシュ URI は、静的な RDF ファイルを Web サーバーにアップロードするだけで実現できます。特別なサーバーの設定も必要ありません。このシンプルさが、やっつけ仕事的な RDF の公開において人気となっている理由です。

bob#this のような URI は、単一文書で管理できないほどデータ量が増える、またはその可能性がある大きなデータセットに対し用いられるべきです。この場合、303 URI を利用し、見栄えの良い URI でデータを提供することができるでしょう。しかしながら、実行時のパフォーマンスとサーバーの負荷に影響をあたえます。

これらにあまり納得できない場合は、直感に従ってください。

4.5. クールな URI

ベストなリソース識別子とは、人や機械のためにその説明を提供するだけではなく、シンプルかつ持続的で管理しやすいようにデザインされたものです。これは Tim Berners-Lee による Cool URIs don't change や、Common HTTP Implementation Problems のセクション 1 と 3 にて解説されています。

シンプルさ (Simplicity.)
短い URI は基本的に覚えやすいものです。セマンティック Web サーバーをデバッグするときにも楽ですし、またメールのなかで改行されることもありません。
持続性 (Stability.)
あるリソースを識別する URI を決定したとき、その URI は可能な限り長く残るようにすべきです。10 年、もしくは 20 年先のことを考えましょう。.php や .asp など実装固有の情報は、将来採用する技術が変更されることを考え、URI から省きましょう。
管理のしやすさ (Manageability.)
管理できるようなかたちで URI を発行しましょう。一つよい方法として、URI のパスに現在の年を含めるというものがあります。こうすることで URI スキーマを毎年変更できるため、古い URI を壊すことはありません。また、すべての 303 URI をたとえば http://id.example.com/alice という、専用のサブドメインから発行するようにしましょう。これにより、URI を処理するサブシステムとの統合が容易になります。

4.6. リンクする

リソース識別子や RDF 文書の URL、また HTML 文書の URL など、一つの実世界オブジェクトに関わる URI は、互いの関係を情報の消費者が理解できるように、すべて明示的にリンクすべきです。たとえば、303 URI を用いた Example Inc. の場合、Alice に関係している URI は三つ存在しています。

http://www.example.com/id/alice
Alice という人物の識別子
http://www.example.com/people/alice
Alice のホームページ
http://www.example.com/data/alice
Alice を説明する RDF 文書

このうち二つは Web 文書の URL です。http://www.example.com/data/alice に配置されている RDF 文書は、次のようなステートメントを含めることができます (文は N3 で表しています)。

<http://www.example.com/id/alice>
    foaf:page <http://www.example.com/people/alice>;
    rdfs:isDefinedBy <http://www.example.com/data/alice>;

    a foaf:Person;
    foaf:name "Alice";
    foaf:mbox <mailto:alice@example.com>;
    ...

この文書は Alice という人物についてのステートメントを、リソース識別子を用いて作成しています。最初に出てくる二つのプロパティにより、リソース識別子と二つの文書 URI を関連づけています。foaf:page というステートメントは、HTML 文書へのリンクを結んでいます。これにより、RDF を理解できるクライアントは、人が読みやすい形でリソースを提供することができます。また、ページとそのトピックを結びつけるため、有用な HTML 文書のメタデータを公開することにもなります。rdfs:isDefinedBy というステートメントは、人物からその人物を説明している、RDF 付きの文書へリンクしています。RDF ブラウザはメインとなるリソースと、たまたまその文書で言及されている、その他の補助的なリソースを区別することができます。弱いつながりを示すスーパープロパティである rdfs:seeAlso ではなく rdfs:isDefinedBy を用いたのは、/data/alice の内容が信頼できるものだからです。その他のステートメントは実際の従業員リストのデータです。

http://www.example.com/people/alice に配置された HTML 文書は、ヘッダに <link> 要素を設け、関連する RDF 文書へリンクすることが推奨されます。

<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
  <head>
    <title>Alice's Homepage</title>
    <link rel="alternate" type="application/rdf+xml"
          title="RDF Representation"
          href="http://www.example.com/data/alice" />
  </head> ...

これにより、RDF を理解できる Web クライアントは、RDF による情報を発見することができるようになります。このアプローチはRDF/XML 仕様書にて推奨されています ([RDFXML] のセクション 9)。RDF データが情報についての表現ではなく、ページについての情報である場合は、rel="alternate" の代わりに rel="meta" を使用することを推奨します。

クライアントはまた、HTTP ヘッダから同様のリンク情報を推測することができます。たとえば、「『もの』は 303 リダイレクトにより導かれた Web 文書で説明されている」や「Content-Location リソースは、包括的な文書のうち、内容固有のバージョンを指す」などです。なお、オントロジーとこれらの関係については触れません。

次の画像は、RDF と HTML 文書がそれぞれの URI をどのように関係させるかを示すものです。

RDF と HTML 文書は、URI とそれぞれの情報を関係づけることが推奨されています

4.7. 実装とコンテントネゴシエーション

W3C の Semantic Web Best Practices and Deployment Working Group は、Apache Web Server 上で、この文書で提示した解決策をどのように実装するかを説明した文書を公開しています。Best Practice Recipes for Publishing RDF Vocabularies [Recipes] では、RDF 語彙 の公開について多く触れていますが、基となる考えは、静的なファイルから公開される他の RDF データセットにも適用できるものとなっています。

しかし、特にコンテントネゴシエーション関し、Recipes は重要な詳細について触れていません。Tabulator extension をインストールした Firefox のように HTML と RDF のどちらをも理解するクライアントにおいて、コンテントネゴシエーションはもうすこし難しいものなのです。

Tabulator をインストールした Firefox は、Accept ヘッダの q (quality) 値を利用し、RDF と HTML のどちらをも解釈できると宣言します。

Accept: application/rdf+xml;q=0.7, text/html

この場合、RDF の q 値は 0.7、HTML の q 値は 1.0 (規定値) となります。これは、HTML の方が RDF よりわずかに優先されるということです。

さて、HTML を優先するクライアントがあるからとはいえ、サーバーは必ずしも HTML を送信するべきというわけではありません。サーバーはクライアントの設定をまず見て、それからどの variant を返すのか、その quality を基準とし、次のように決定する必要があります。

クライアントの設定とサーバー設定を比べるアルゴリズムがいくつかあります。たとえば、Apache サーバーはサーバーサイドの qs 値を用い、相対的な quality を指定することができます。

application/rdf+xml の qs 値が 1.0、text/html が 0.5 である場合、HTML 版は RDF 版のおよそ半分の quality を持ち、先述したリストの最初の例が当てはまるでしょう。もし HTML がニュース記事で、RDF にはタイトル、日付、著者など最低限の情報しか持たない場合、HTML の qs 値には 1.0 を、RDF には 0.1 を指定するのが適当でしょう。

どの variant がベストなのかを決定する際、Apache はクライアントの各 variant に設定された q 値と qs 値の咳を求め、それらを比較します。Apache のドキュメンテーションにはコンテントネゴシエーションに関する詳細な セクション があります [ApCN]。HTTP の Accept ヘッダについての詳細は HTTP 仕様の section 14.1 で解説されています [HTTP-SPEC]。

これらの詳細を含めて、コンテントネゴシエーションはとても複雑です。しかし、HTML と RDF どちらにも対応するようなクライアントに対しベストな variant を選択する場面において、コンテントネゴシエーションはとても強力に機能します。

5. Web における例

セマンティック Web 技術を利用したプロジェクトのすべてが、Web にデータを公開しているわけではありません。しかし、この文書で解説している手法を用いたプロジェクトの数は増えています。ここでは、その中からいくつかを紹介します。

ECS Southampton ― University of Southampton の School of Electronics and Computer Science は、303 URI を利用した、すばらしいセマンティック Web サイトを構築しています。システムの仕様は ECS URI System Specification [ECS] で公開されています。HTML 文書と RDF 文書、そしてリソース識別子はそれぞれ異なるサブドメインで管理されています。次の例をご覧ください。

http://id.ecs.soton.ac.uk/person/1650
Wendy Hall という人物の URI
http://www.ecs.soton.ac.uk/people/wh
Wendy Hall の HTML ページ
http://rdf.ecs.soton.ac.uk/person/1650
Wendy Hall の RDF

最初の URI を一般的な Web ブラウザに入力すると、Wendy Hall の HTML 版ページにリダイレクトされます。このページには、彼女について Web に公開されているデータのすべてを表示しています。また、このページから彼女自身の URI や、彼女についての RDF 文書へのリンクが張られています。

D2R Server は、リレーショナルデータベースのデータをガイドラインに従い、セマンティック Web 上に公開するオープンソースのアプリケーションです。このアプリケーションは、303 URI とコンテントネゴシエーションを採用しています。たとえば、DBLP Bibliography Database の D2R Server では、数千の目録データと、その著者についての情報を公開しています。303 リダイレクトからつながる URI の例は、次の通りです。

http://www4.wiwiss.fu-berlin.de/dblp/resource/person/315759
Chris Bizer という人物の URI
http://www4.wiwiss.fu-berlin.de/dblp/page/person/315759
Chris Bizer の HTML ページ

Chris Bizer の RDF 文書は、このサーバーにある SPARQL エンドポイントに SPARQL クエリーを送信することで取得できます。

http://www4.wiwiss.fu-berlin.de/dblp/sparql?query=
DESCRIBE+\%3Chttp\%3A\%2F\%2Fwww4.wiwiss.fu-berlin.de
\%2Fdblp\%2Fresource\%2Fperson\%2F315759\%3E

この URI 中にエンコードされた SPARQL クエリーは次のようになっています。

DESCRIBE <http://www4.wiwiss.fu-berlin.de/dblp/resource/person/315759>

SPARQL エンドポイントはこの例の様に、リソースの説明を提供する簡易な手段として利用できます。

Semantic MediaWiki は、オープンソースのセマンティック Wiki エンジンです。ページ作成者は特殊な wiki 構文を利用し、wiki 記事にセマンティックな属性や関係を付加することができます。ソフトウェアは、各記事にそのトピックを識別する 303 URI を生成し、また属性や関係から RDF による説明を提供します。Semantic MediaWiki の利用例として OntoWorld wiki があります。カールスルーエ市の記事を見てみましょう。

http://ontoworld.org/wiki/Karlsruhe
記事の HTML 文書
http://ontoworld.org/wiki/_Karlsruhe
カールスルーエ市を識別する URI
http://ontoworld.org/wiki/Special:ExportRDF/Karlsruhe
カールスルーエ市の RDF 文書

RDF 文書の URI は理想的なものではあまりありません。実装固有の情報 (php) や、クエリー部分とパスのどちらにもある、「RDF を出力する」という情報です。もっとクールな URI はたとえば http://ontoworld.org/rdf/Karlsruhe でしょう。この URI であればコンテントネゴシエーションを用いて、RDF や RIF (Rule Interchange Format) などでデータを配信できるからです。

6. 他のリソース命名案

これまでリソースの命名に関し、さまざまな提案がなされてきました。しかし、多くの提案は特定の状況下における解決策であり、Section 3 で解説した「Web上にあること」と、「曖昧でないこと」という二つの指針に沿わないと感じました。つまり、標準技術ベースで、分断されていない、分散的なセマンティック Web を構築するために利用できる、一般的な解決法ではないのです。ここではそのような二つの案について解説します。

6.1. 新たな URI スキーム

HTTP URI は既に Web リソースと Web 文書を識別していますが、他の種類のリソースについては識別していません。では、それら他のリソースを識別するため、新しい URI スキームを作ればよいのではないでしょうか。新しい URI スキームを利用することにより、Web 文書とその他のリソースを、URI の先頭を見るだけで判別することができるのです。たとえば、info スキームを用い、本を識別することができます。LCCN 番号に基づいて本を識別する場合は、info:lccn/2002022641 のようになります。

このような新しい URI スキームはいくつかあり、Thompson と Orchard によって URNs, Namespaces and Registries [TAG-URNs] という文書にまとめられています。いくつか例を挙げてみましょう。

真に実用的になるために、新しい URI スキームは、識別されるリソースに関する情報にアクセスするためのプロトコルも定義されている必要があります。たとえば、ftp::// URI スキームはリソース (FTP サーバー上のファイル) と、リソースにアクセスするためのプロトコル (FTP プロトコル) を識別しています。

新しい URI スキーマのいくつかは、このようなプロトコルを提供していません。他のスキームについては、HTTP プロトコルを用いてリソースの説明を取得できるような Web サービスを提供しています。識別子がサービスに渡されると、情報を中央データベースや連合データベースから検索するのです。この方法の問題は、サービスの欠陥によりシステムが利用できなくなることです。

他の欠点として、標準化団体への依存が挙げられます。新しいパートを info: 空間に登録するには、標準化団体にコンタクトを必要があります。このことや、また URI の作成ライセンス料を払う必要が出てきた場合、その URI の普及が遅くなってしまいます。たとえば ISBN など、すべての URI が一意であることを保証したい場合には、標準化団体の存在は望ましいでしょう。しかし、これは標準化組織により保持・管理される HTTP 名前空間内の URI によって実現することができるのです。

標準化団体への依存や、検索可能性 (retrievability) のなさ、また特許や法的な事項が明らかにされていない場合、新しい URI スキームの普及に影響があるでしょう。もし特許のある技術を利用している場合、実装者は Royalty-Free なライセンスがあるかどうかを確認すべきです。

新しい URI スキームの問題点については、URNs, Namespaces and Registries で詳しく述べられています。

6.2. 説明による参照

"説明による参照 (Reference by Description)" というアプローチは、URI から離れることにより問題を根本的に解決するというものです。どのようなことかというと、URI をリソースの名前付け に用いる代わりに 匿名ノード を用い、正しいものを見つけられるようにする情報により 説明 するのです。たとえば、人物はその人の名前や誕生日、社会保障番号を利用して説明することができます。これらは部分的ではありますが、人物を特定するのに充分な情報でしょう。

人物を特定するためによく用いられる情報が、メールアドレスです。たとえば、Friend of a Friend (FOAF) で使用されている foaf:mbox プロパティはメールアドレスを利用したものです。OWL では、このようなプロパティを Inverse Functional Property (IFP) と呼んでいます。エージェントは同じメールアドレスを持つ二つのリソースに出会ったとき、それらがどちらも同じ人物を参照していると推測することができ、二つのリソースを一つとしてとらえることができるようになります。

しかし、このアプローチをどのように Web 上で表現 できるのでしょうか。言及したリソースについて、エージェントはどのようにより多くの情報をダウンロードすることができるのでしょうか。実は、これにはベストプラクティスがあります。リソースの IFP (人物のメールアドレスなど) だけではなく、より詳しい情報を記述した RDF 文書の Web アドレスを rdfs:seeAlso プロパティで含めるのです。しかし、この方法でも詳細情報の場所を識別するものに依然として HTTP URI が使われているのです。

さらには、リソースを参照するために IFP の値や RDF 文書など、複数の場所から情報を得る必要がでてきます。URI をリンクさせて利用するという行為は、いくつかのパートを経るプロセスとなります。そしてそれは、リンク切れを生み出したり、実装を厄介にするという危険性を高めてしまうのです。

人に URI をつけるのを避けるという FOAF のプラクティスに対して、私たちは Tim Berners-Lee のアドバイス である “Go ahead and give yourself a URI. You deserve it!” に賛同します。

7. 結論

セマンティック Web において、リソースの名前は二つの要件を満たすことが推奨されます。ひとつは、識別されるリソースの説明が、標準的な Web 技術によって取得可能であること。そしてもうひとつは、命名スキームが「もの」とそれを説明する文書を混同しないようなものであることです。

私たちは、これらの要件を満たす二つの解決策について説明しました。どちらも、HTTP スキームとプロトコルを利用しています。ひとつは 303 HTTP ステータスコードを利用し、リソース識別子から解説文書へリダイレクトするものです。もうひとつは “ハッシュ URI” を利用しリソースを識別し、URI がハッシュ以降の部分をリソースの取得時に使用しないという仕様を利用するというものです。

リソースとその説明を分けてとらえるという要件により、複数の URI を調整することが必要となってきます。このような場合に利用できる便利なテクニックとして、HTML 文書から RDF データへのリンクを埋め込む、RDF ステートメントを利用し URI の関係を説明する、コンテントネゴシエーションを利用して適切な説明をもつリソースへリダイレクトするなどがあります。

8. 謝辞

まず、Tim Berners-Lee 大変感謝しています。彼は私たちが TAG の解決策を理解するにあたり、チャットでのリクエスト に答え、またメールにて詳しい説明を提供するなど、多くの時間を割いてくれました。また特に、この文書のレビューを行い、TAG の考えと異なる多くの論拠について本質的なフィードバックを 2007 年 6 月 と 2007 年 9 月 に提供してくれた、Stuart Williams と Norman Walsh、そして他の TAG メンバーにも感謝しています。また、Semantic Web Deployment Group のメンバー Michael Hausenblas、Vit Novacek、Ed Summers らが 2007 年 10 月 に行ったレビューとそのまとめにも感謝しています。最後に、草稿段階にあったこの文書をレビューしてくれた皆さん、特に Chris Bizer、Gunnar AAstrand Grimnes、Harry Halpin、Xiaoshu Wang、Henry S. Thompson、Jonathan Rees、Christoph Päper に感謝しています。また Susie Stephens は SWEO のマネジメントを行い、この文書をレビューするなど、私たちの活動を下支えしてくれました。Ivan Herman は W3C の要件に適合しているかを確認し、この note を提出してくれました。

この文書の作成は German Federal Ministry of Education, Science, Research and Technology (BMBF)、(Grants 01 IW C01, Project EPOS: Evolving Personal to Organizational Memories; and 01 AK 702B, Project InterVal: Internet and Value Chains) および European Union IST fund (Grant FP6-027705, Project Nepomuk) のサポートにより実現しました。

9. 参考文献

[AWWW]
Architecture of the World Wide Web, Volume One, Ian Jacobs, Norman Walsh, Editors. World Wide Web Consortium, 15 December 2004. This edition is http://www.w3.org/TR/2004/REC-webarch-20041215/. The latest edition is available at http://www.w3.org/TR/webarch/.
[ApCN]
Apache HTTP Server Version 2.0 Documentation, Chapter Content Negotiation. This document is available at http://httpd.apache.org/docs/2.0/content-negotiation.html.
[Booth]
Four Uses of a URL: Name, Concept, Web Location and Document Instance, David Booth. 28 January 2003. This document is available at http://www.w3.org/2002/11/dbooth-names/dbooth-names_clean.htm.
[CHIPS]
Common HTTP Implementation Problems, Olivier Théreaux, Editor. World Wide Web Consortium, 28 January 2003. This edition is http://www.w3.org/TR/2003/NOTE-chips-20030128/. The latest edition is available at http://www.w3.org/TR/chips/.
[Cool]
Cool URIs don't change, Tim Berners-Lee, 1998. This document is available at http://www.w3.org/Provider/Style/URI.
[DP]
The DataPortability Project. http://dataportability.org/
[ECS]
ECS URI System Specification, Colin Williams, Nick Gibbins. ECS Southampton, 2006. This document is available at http://id.ecs.soton.ac.uk/docs/.
[FOAF]
FOAF Vocabulary Specification 0.9, Dan Brickley, Libby Miller. 24 May 2007. This edition is http://xmlns.com/foaf/spec/20070524.html. The latest edition is available at http://xmlns.com/foaf/spec/.
[Give]
Give Us the Data Raw, and Give it to Us Now. Rufus Pollock. 7th November 2007.
[GenRes]
Generic Resources, Tim Berners-Lee. This document is available at http://www.w3.org/DesignIssues/Generic.html.
[GRDDL]
Gleaning Resource Descriptions from Dialects of Languages (GRDDL), Dan Connolly, Editor, W3C Recommendation 11 September 2007. This edition is http://www.w3.org/TR/2007/REC-grddl-20070911/. The latest edition is available at http://www.w3.org/TR/grddl/.
[HTTP-URI2]
What HTTP URIs Identify, Tim Berners-Lee. 9 June 2005. This document is available at http://www.w3.org/DesignIssues/HTTP-URI2.html.
[httpRange]
[httpRange-14] Resolved, Roy Fielding. 18 June 2005. This archived www-tag email message is available at http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html.
[HTTP-SPEC]
RFC2616, Hypertext Transfer Protocol -- HTTP/1.1, http://www.rfc.net/rfc2616.html#s14.1
[N3]
Notation 3, Tim Berners-Lee, Dan Connolly, 2008. This document is available at http://www.w3.org/TeamSubmission/n3/.
[N3Primer]
Primer: Getting into RDF & Semantic Web using N3. Tim Berners-Lee, 2005. http://www.w3.org/2000/10/swap/Primer
[RDFa Primer]
RDFa Primer 1.0 - Embedding Structured Data in Web Pages (see http://www.w3.org/2006/07/SWD/RDFa/primer/.)
[RDFPrimer]
RDF Primer, Frank Manola, Eric Miller, Editors. World Wide Web Consortium, 10 February 2004. This edition is http://www.w3.org/TR/2004/REC-rdf-primer-20040210/. The latest edition is available at http://www.w3.org/TR/rdf-primer/.
[RDFXML]
RDF/XML Syntax Specification (Revised), Dave Beckett, Editor. World Wide Web Consortium, 10 February 2004. This edition is http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/. The latest edition is available at http://www.w3.org/TR/rdf-syntax-grammar/.
[Recipes]
Best Practice Recipes for Publishing RDF Vocabularies, Alistair Miles, Thomas Baker, Ralph Swick, Editors. World Wide Web Consortium, 23 January 2008. This edition is http://www.w3.org/TR/2008/WD-swbp-vocab-pub-20080123/. It is a work in progress. The latest edition is available at http://www.w3.org/TR/swbp-vocab-pub/.
[RFC2616]
RFC 2616: Hypertext Transfer Protocol - HTTP/1.1, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. IETF, 1999. This document is available at http://www.ietf.org/rfc/rfc2616.txt.
[RFC3986]
RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter. IETF, 2005. This document is available at http://www.ietf.org/rfc/rfc3986.txt.
[SMW]
Semantic Wikipedia, Max Völkel, Markus Krötzsch, Denny Vrandecic, Heiko Haller, Rudi Studer. University of Karlsruhe, 2006. This document is available at http://www.aifb.uni-karlsruhe.de/WBS/hha/papers/SemanticWikipedia.pdf.
[TAG-Alt]
On Linking Alternative Representations To Enable Discovery And Publishing, T.V. Raman. World Wide Web Consortium, 1 November 2006. This edition is http://www.w3.org/2001/tag/doc/alternatives-discovery-20061101.html. The latest edition is available at http://www.w3.org/2001/tag/doc/alternatives-discovery.html.
[TAG-URNs]
URNs, Namespaces and Registries, Henry S. Thompson, David Orchard. World Wide Web Consortium, 17 August 2006. This edition is http://www.w3.org/2001/tag/doc/URNsAndRegistries-50-2006-08-17.html. It is a work in progress. The latest edition is available at http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html.
[TriX]
RDF Triples in XML, Jeremy J. Carroll, Patrick Stickler, 2004. This document is available at http://www.mulberrytech.com/Extreme/Proceedings/html/2004/Stickler01/EML2004Stickler01.html.
[WP-HTTP]
Hypertext Transfer Protocol, Wikipedia contributors. Wikipedia, 8 October 2007. The latest version of this document is available at http://en.wikipedia.org/wiki/HTTP.

10. Change log

29 November 2006
1.0 Initial Version.
9 August 2007
1.1 Revised Version. Changes based on TAG review.
28 November 2007
Leo Sauermann included more feedback from reviews contributed by TAG, SWD, and Tim Berners-Lee.
8 December 2007
Danny Ayers did proofreading, minor grammar/idiomatic/editorial changes (I've tried not to make any changes that substantively modify the content, though some come close...). XHMTL validated with nxml-mode emacs
12 December 2007
Leo Sauermann included link to GRDDL as suggested by Danny Ayers, minor changes of todo notes. Document was remodelled to Working Draft status - all feedback by SWD, TAG, and Tim Berners Lee either has been addressed or is listed in this document as todos using @@-symbols and the css class "todo".
17 December 2007
Document published as Working Draft at http://www.w3.org/TR/2007/WD-cooluris-20071217/
23 Februar 2008
All feedback received on Working Draft.
20 March 2008
All feedback incorporated, issues are listed and addressed in this document.
21 March 2008
Document published as Last Call Working Draft at http://www.w3.org/TR/2008/WD-cooluris-20080321/
31 March 2008
Document published as Interest Group Note. Feedback to previous version and changes are listed here.