原文の最新版 が公開されたため、この日本語訳は古いものとなっています。原文の最新版に対応した日本語訳は、W3C 仕様書 日本語訳一覧 よりアクセスできます。
この文書「セマンティック Web のためのクールな URI」は、W3C の Semantic Web Education and Outreach (SWEO) Interest Group による「Cool URIs for the Semantic Web (W3C Working Draft 17 December 2007)」の日本語訳です。
規範的な文書は原文のみとなっています。この日本語訳は参考情報であり、正式な文書ではないことにご注意ください。また、翻訳において生じた誤りが含まれる可能性があります。
原文が勧告 (Recommendation) ではなく、策定途中の草案 (Working Draft) であることにご注意ください。
原文の最新版 は、この日本語訳が参照した版から更新されている可能性があります。また、この日本語訳自身も更新されている可能性があります。日本語訳の最新版は、W3C 仕様書 日本語訳一覧 から参照することができます。
Copyright © 2007 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 という、2 種類の方法について解説します。また、これらの手法を利用する Web サイトについて触れたり、これら以外の方法が持ちうる問題点についても簡単に説明します。
この章は、この文書の公開時におけるステータスについて説明しています。このため、他の仕様がこの文書を上書きしている可能性があります。W3C による他の出版物およびこの技術レポートの最新版は W3C 技術レポートインデックス (http://www.w3.org/TR/) で探すことができます。
この文書は、セマンティック Web 技術への新参者のために、TAG の決定を説明するチュートリアルの最初の公開草案 (First Public Working Draft) です。また、W3C Interest Group Note としての公開を考えています。この文書は DFKI Technical Memo TM-07-01, Cool URIs for the Semantic Web を基とし、その後 Technical Architecture Group (TAG) および Semantic Web Deployment Group (SWD) がレビューを行いました。現在、この文書は Semantic Web Education and Outreach (SWEO) Interest Group により策定されています。
この文書に対するコメントは、public-sweo-ig@w3.org (公開アーカイブ) までお願いします。Interest Group Noteとしての公開は、2008 年 2 月 1 日を予定しているため、コメントは出来る限り 2008 年 1 月 21 日までに送信するようお願いします。
TAG および SWD のレビューにて見つかった問題に対しては、すでに解決にむけた取り組みが行われています。残りの問題のうち、判明しているものは changelog で取り上げられています。
草案としての仕様書公開は、W3C メンバーによる支持を意味するものではありません。この文書は更新されたり他の文書と置き換えられたり、また破棄される可能性もある草稿段階の仕様書です。策定中ということを明記せずに、この文書を引用することは適当でありません。
この文書は 5 February 2004 W3C Patent Policy の下で活動するグループにより作成されました。W3C は 特許情報の開示に関する公開リスト を関連する団体と共に、その成果物とあわせて管理しています。リストには情報開示に関する説明もありますので、ご参照ください。特許について十分に知識のある人物が、当該仕様に関し Essential Claim(s) が認められると判断した場合は、W3C 特許方針の第 6 章 に従い情報を開示する必要があります。
この文書は、RDF 仕様の実装者のために書かれた実践的ガイドです。HTTP サーバーにて RDF データをホストする、2 つの方法について解説しています。想定する読者として、RDF URI を HTTP にてモデリングしたいと考えている、Web 開発者やオントロジー開発者が挙げられます。このため HTTP ではない URI を利用するアプリケーションについては触れていません。この文書は、詳しくまとめられ、また既に公開されている技術仕様の内容を補足する、参考文書という位置づけです。想定読者は、RDF データモデルの基本 [RDFPrimer] についてよく知っており、また HTTP プロトコル [RFC2616] についても、ある程度の知識を持っている人としています。HTTP については Wikipedia の記事 [WP-HTTP] に良い解説があるので、参照してください。
セマンティック Web とは、インテグレーションにかかるコストを最小限に抑えたうえで、機械処理可能なデータを共有できる、分散的でワールドワイドな情報システムと想像されています。セマンティック Web へのチャレンジとして、共有されたデータモデルによる分散的な世界のモデル作りと、データやスキーマの公開・発見・利用が可能なインフラストラクチャーの構築が挙げられています。つまり、「どのようにすれば、リソースに関する情報をその情報に興味を持っているユーザーやアプリケーションに対して公開できるのか。」という疑問が基になっているのです。
セマンティック Web では、すべての情報が リソース (resources) に関する 文 (statements) として表されます。たとえば、「Example.com という会社のメンバーは Alice と Bob です。」や「Bob の電話番号は "+1 555 262 です。」、「この Web ページは Alice が製作しました。」などです。リソースは Uniform Resource Identifier (URI) [RFC3986] で識別されます。このモデリングによるアプローチが、Resource Description Framework (RDF) [RDFPrimer] の真髄なのです。
@@ check if this explains the semantic web for the intended audience or if more is needed@@
RDF を用いることで、このような文を企業の Web サイトから発信することができます。他の人はそのデータを読み、また既存の情報にリンクさせ、独自に情報を公開することもできます。結果として、世界の分散的なモデルを構築することができるのです。
さて、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 の一部として理解されるために、いくつかの例を挙げ解説します。
では、例から始めましょう。Example Inc. という、"エクストリームなギターアンプ (Extreme Guitar Amplifiers)" を生産している会社があり、その Web サイトは http://www.example.com/ だとします。サイトには各従業員について書かれたページがあり、名前とその他の情報が掲載されています。Example Inc. には Alice と Bob というふたりの従業員がいるので、Web サイトは次のような構造になっています。
今までの Web と同じように、これらのページは Web 文書 (Web documents) です。すべての Web 文書は URI を持ちます。しかし、Web 文書はファイルとは同じではありません。ひとつの Web 文書は異なる言語やフォーマットで表現することができます。しかし、ひとつのファイル、たとえば PHP スクリプトは、それぞれ異なる URI を持つ、膨大な数の Web 文書を生成することがあるかもしれません。Web 文書とは URI を持ち、HTTP リクエストに応じて識別されたリソース 表現 (representations) (HTML や JPEG、RDF のようなフォーマットによるレスポンス) を返すことができるものとして定義されています。 Architecture of the World Wide Veb, Volume One [AWWW] などの技術的な文書では、情報リソース (Information Resource) という言葉が Web 文書 の代わりに使われています。
今までの Web では、URI は Web 文書に対し優先的に使われていました。たとえば、リンクを張ったり、ブラウザからアクセスしたりなどです。つまり、URL (Uniform Resource Locator) という言葉が示すとおり、Web 文書の場所を示すためのものでした。リソースのアイデンティティという概念は、元来の Web ではあまり重要ではありませんでした。URL はただ、私たちがブラウザにタイプしたときに現れるものを識別していただけなのです。
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
そして、レスポンスにあるとおり英語版の HTML 文書が返ってきます。さて、コンテントネゴシエーション [TAG-Alt] は多くの場合、ちょっとした仕掛けつきで実装されています。サーバーは直接リクエストした結果を返すのではなく、そのバージョンが見つかった URL にリダイレクトするのです。
HTTP/1.1 302 Found Location: http://www.example.com/people/alice.en.html
リダイレクトは 302 Found という、特別な ステータスコード (Status Code) で表されます。クライアントはこれを受け、新しい HTTP リクエストをリダイレクト先の URL に送信します。バージョンごとに異なる URL を設けることで、Web 製作者は特定のバージョンにリンクすることができるのです。
@@DannyAyers: ...and treat them as independent resources? @@Leo: they may be several representions of the same resource, the term "independent" may be misleading.
RDF の標準構文である RDF/XML は、application/rdf+xml という、独自の content type を持っています。よって、コンテントネゴシエーションにより、元来の Web ブラウザには HTML 版の Web 文書を、そしてセマンティック Web ユーザーエージェントには RDF 版を提供することができるのです。また、サーバーに Notation3 [N3] 版や TriX [TriX] 版など、別の RDF 構文を提供させることも可能となります。
@@ TAG suggest to rephrase the next sentence to "With the advent of semantic web technologies, the web is extended so that (http:?) URIs can identify not just web documents but also ..
@@ Danny Ayers: It's long been possible to identify things, and
RDF etc aren't strictly necessary
@@ LeoSauermann: hesitate to change the document based on this general comment.
セマンティック Web において、URI は Web 文書のみを識別するわけではありません。人や車など、実世界にあるものも識別するのです。さらには、抽象的な概念や、ユニコーンなどの架空の生き物まで識別します。私たちはこれらすべてを 実世界のオブジェクト (real-world objects)、または WWW-Arch に従い、非情報リソース (non-information resources) と呼んでいます。
@@Danny Ayers: I believe it came in a recent thread on semantic-web@w3.org
that "non-information resource" wasn't defined in WebArch, though I
haven't checked. If so, should be reworded. My suggestion for rewording is to delete that last sentence
@@ Leo Sauermann: there is no other term offered. Suggestion: remove "(according to WWW.Arch)"
さて、実世界のオブジェクトにつけられた URI から、私たちはどのようにして URI が識別するオブジェクトを見つけることができるのでしょうか。それぞれ独立している情報システムの相互運用性を確保するためにも、何らかの回答を見つける必要があります。検索エンジンのように、識別されたリソースを探すようなサービスがあればよいのかもしれません。しかし、このような単一のやりかたは Web の分散的な性質に反してしまいます。
リソースの説明 (resource descriptions) を検索するサービスには、Web 自身を活用するべきなのです。なぜなら、Web はとても堅牢でスケーラブルな情報公開システムだからです。URI が言及されるたびに、私たちは関連する情報の説明や、関連するデータへのリンクを検索して見つけだします。これはとても重要なことであるため、これを良い URI における一番大きなな要件とします。
Example Inc. が、従業員のコンタクト情報をセマンティック Web 上に公開し、彼らのビジネスパートナーがそのデータをアドレス帳に登録できるようにしたいと考えているとします。たとえば、N3 構文 [N3] により公開されているデータが、Alice に関する次のようなステートメントを含んでいるとします。
<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] という記事にまとめられています。)
したがって、二つ目の要件は次のようになります。
しかしこの二つの要件は、互いに矛盾しているように感じます。もし文書の URI を実世界のオブジェクトを識別するために用いることができないのならば、それらが持つ URI からどのようにその説明を取得することができるのでしょうか。したがって、リソースの URI のみを与えられたとき、それを説明する文書をどのように見つけるのか、また標準の Web 技術を用いてどう実装するのかが課題となってきます。
次に示す画像は、リソースとその説明をする文書の理想的な関係を表しています。
@@ The next paragraphs address a recommendation by TAG to weaken our "err on the side of caution" recommendation by explaning the problem better. TAG members may verify if their recommendation was met by our explanation.
ここまで、Web 文書 (情報リソース) と 文書ではない実世界のオブジェクト (非情報リソース) の間には違いがあると考えてきました。さてここで、どこでその線引きを行うのかという疑問が生じます。
W3C のガイドライン ([AWWW], section 2.2.) によると、リソースがすべての重要な性質をメッセージとして伝達できる場合において、それは情報リソースとなるとされています。例として Web ページや画像、製品カタログといった、私たちが Web 文書と呼ぶものが挙げられます。この URI は実体を識別し、またその性質を伝達するメッセージをも間接的に識別します。したがって、実世界のオブジェクト (非情報リソース) とは、性質がメッセージとして伝達されない、実体そのもののことです。二つのリソースの違いを理解する鍵は、情報リソースが多くの場合、非情報リソースを説明するものであるということです。たとえば Alice という人が、Alice のホームページという情報リソースで説明されていたとします。私たちはホームページの見た目が好きではありませんが、それは彼女自身についていっているわけではありません。
問題は、Web 文書が私たちの世界の一部として取り入れられ、実世界のオブジェクトになってしまったことです。たとえば、今あなたが読んでいる文書も、あなたがいる世界に存在する、ひとつの実体なのです。
これに対し私たちが推奨するのは、慎重過ぎるぐらい慎重になることです。何を言いたいかというと、対象となるオブジェクトがはっきりと、また明確に文書ではない場合 (すべての重要な性質がメッセージによって伝達できない場合)、リソース用とそれを説明する文書用という、二つの異なる URI をあてがうということです。
実世界のオブジェクトを識別するための要件を満たす解決策は、二つ存在します。303 URI と呼ばれる手法と、ハッシュ URI と呼ばれる手法です。それぞれに長所と短所があるため、状況によりこれらを使い分けることになります。
次に解説する二つの解決策は、HTML 文書とともに配信されるスタンドアロンな RDF/XML 文書というように、RDF データと HTML データが分けられて配信されるというシナリオに対応するものです。メタデータは RDFa [RDFa Primer] や microformats、また GRDDL [GRDDL] のメカニズムなどによって、HTML に埋め込むことができます。このような場合において、RDF データは返される HTML 文書から抽出されることとなります。
最初の解決策は、非文書リソースに“ハッシュ URI”を用いるというものです。URI は フラグメント (fragment) という、ハッシュ記号 (“#”) により区分けされた特別な部分をもつことができます。
クライアントが ハッシュ URI からリソースを取得するとき、HTTP プロトコルはその URI につけられたフラグメントを、サーバーからリクエストする前に取り除くことが必須とされています。これは、ハッシュを持つ URI は直接取得することができないということであり、つまりハッシュ付き URI は Web 文書を識別するものになれないということなのです。この特徴を利用し、私たちはハッシュ付き URI を、曖昧さを残すことなく非文書リソースを識別するために利用することができます。
Example Inc. がこの解決策をとる場合、彼らは次の URI により、会社、Alice、Bob を表すことができます。
クライアントはこれらの URI をリクエストする前に、そのフラグメントを取り除きます。結果として、次の URI をリクエストすることになります。
この URI では、Example Inc. がリソースを識別するもとのハッシュURIを用いてこれらすべてのリソースに対する説明を持つRDF文書を提供する Example Inc. はこの URI から、各リソースを説明する RDF 文書を提供することができます。各リソースは先ほどのハッシュ付きの URI を用いて説明されます。
次の図では、コンテントネゴシエーションを用いないハッシュ URI の利用法を説明しています。
コンテントネゴシエーション (Section 2.1. を参照) を用い、about という URI から HTML や RDF 文書にリダイレクトを行うという方法もあります。この場合、303 See Other ステータスコードを用いる必要があります。(そうでなければ、クライアントはハッシュ URI を HTML 文書の一部として解釈してしまうからです。)
次の図は、コンテントネゴシエーションを用いるハッシュ URI の使い方を解説しています。
二つ目の解決策は、特別な HTTP ステータスコード “303 See Other”を用い、リクエストしたリソースが通常の Web 文書ではないということを示す方法です。Web アーキテクチャでは、非情報リソースが 200 を返すのは適切ではないと記しています。なぜなら、そのリソースに対し適切な表現は Web 上に存在しないからです。しかしながら、リソースに関する情報を提供することはとても便利です。W3C の Technical Architecture Group は、httpRange-14 resolution [httpRange] という文書において、異なる (情報) リソースに誘導させるという解決策を提示しています。誘導先の情報リソースを文書とすることで、求めている情報を提供することができるのです。303 ステータスコードを用いることにより、もともとの非情報リソースと、それを説明するリソースが生み出す曖昧さを解決することができます。
303 はリダイレクトを行うステータスコードであるため、サーバーはリソースを説明する文書の場所を伝えることができます。もし、リクエストが 200 OK といった一般的な 2XX ステータスコードで返された場合、クライアントはその URI が Web 文書だと知ることができます。
Example Inc. がこの解決策をとる場合、次の URI により、会社、Alice、Bob を表すことができます。
Web サーバーは、303 ステータスコードおよび Location HTTP ヘッダのついたこれらの URI リクエストすべてに答えるように設定されるでしょう。Location ヘッダにより提供される URL は、リソースを説明する文書を識別するものです。
次の図は、考えられる 303 URI を利用したリダイレクトについて説明しています。
サーバーはコンテントネゴシエーション (Section 2.1. を参照) を用い、HTML 文書の URL か RDF を送信することができます。HTML コンテンツへの HTTP リクエストは Section 2 で解説した、HTML 文書への URL にリダイレクトされます。RDF データへのリクエストは、次のような RDF 文書へとリダイレクトされます。
各 RDF 文書は、説明されたリソースを識別するため、適切なリソースについて説明したステートメントを含むでしょう。ステートメントにはもとの URI である http://www.example.com/id/alice などを利用します。
ハッシュ URI と 303 URI、一体どちらのアプローチが良いのでしょうか。ハッシュ URI は HTTP の往復を減らすことができるため、待ち時間を節約することができます。ハッシュ URI では、URI にハッシュを含まない共通部分を持ちます。3 つのリソース http://www.example.com/about#exampleinc、http://www.example.com/about#product123、http://www.example.com/about#product456 はそれぞれ、http://www.example.com/about へのリクエストを一回行うことで取得することができます。しかし、このアプローチには欠点もあります。たとえ #product123 のみに興味があるクライアントでも、他のリソースが同じファイルにあるためそれらすべてを取得する必要があるのです。この点において、303 URI はフレキシブルであり、各リソースに対してそのリダイレクト先を個別に設定することができます。たとえば、リソースごとに解説文書を用意する、すべてのリソースを解説する一つの文書を用意する、またはこれらを組み合わせて利用することもできます。この場合、リダイレクトのポリシーを後で変更することもできます。しかし、リダイレクト数が多くなるにつれ、待ち時間が長くなってしまう懸念があります。
303 URI による解決策では大量の URI を管理するため、スケーラビリティの問題が生じます。この問題に対処するために、SPARQL エンドポイントやそれに類似したサービスの利用が推奨されます。また、303 とハッシュは組み合わせて利用できることにも注目してください。組み合わせることにより、大きなデータセットを複数のパーツに分散させ、非文書リソースに識別子を設けることができるようになります。次に示すのは、303 とハッシュを組み合わせた例です。
どのようなフラグメント識別子も妥当なものとなります。上記の this も、おすすめする一つの例です。
コンテントネゴシエーションを用いないハッシュ URI は、静的な RDF ファイルを Web サーバーにアップロードするだけで実現できます。特別なサーバーの設定も必要ありません。このシンプルさが、やっつけ仕事的な RDF の公開において、人気となっている理由です。
303 URI は、単一文書で管理できないほどデータ量が増える、またはその可能性がある大きなデータセットに対し用いられるべきです。
どのようなケースなのか迷ったときには、フレキシブルな 303 URI を利用すると良いでしょう。
ベストなリソース識別子とは、人や機械のためにその説明を提供するだけではなく、シンプルかつ持続的で管理しやすいようにデザインされたものです。これは Tim Berners-Lee による Cool URIs don't change や、Common HTTP Implementation Problems のセクション 1 と 3 にて解説されています。
リソース識別子や RDF 文書の URL、また HTML 文書の URL など、ひとつの実世界オブジェクトに関わる URI は、互いの関係を情報の消費者が理解できるように、すべて明示的にリンクすべきです。たとえば、303 URI を用いた Example Inc. の場合、Alice に関係している URI は三つ存在しています。
このうち二つは 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 Version"
href="http://www.example.com/data/alice" />
</head> ...
これにより、RDF を理解できる Web クライアントは、RDF による情報を発見することができるようになります。このアプローチはRDF/XML 仕様書にて推奨されています ([RDFXML] のセクション 9)。Web ページの情報が大幅に RDF 版の情報と異なる場合、rel="alternate" の代わりに rel="meta" を使用することを推奨します。
次の画像は、RDF と HTML 文書がそれぞれの URI をどのように関係させるかを示すものです。
W3C の Semantic Web Best Practices and Deployment Working Group は、Apache Web Server 上で、この文書で提示した解決策をどのように実装するかを説明した文書を公開しています。Best Practice Recipes for Publishing RDF Vocabularies [Recipes] では、RDF 語彙 の公開について多く触れていますが、基となる考えは、静的なファイルから公開される他の RDF データセットにも適用できるものとなっています。
セマンティック Web 技術を利用したプロジェクトのすべてが、Web にデータを公開しているわけではありません。しかし、この文書で解説している手法を用いたプロジェクトの数は増えています。ここでは、その中からいくつかを紹介します。
ECS Southampton ― University of Southampton の School of Electronics and Computer Science は、303 URI を利用した、すばらしいセマンティック Web サイトを構築しています。システムの仕様は ECS URI System Specification [ECS] で公開されています。HTML 文書と RDF 文書、そしてリソース識別子はそれぞれ異なるサブドメインで管理されています。次の例をご覧ください。
最初の URI を一般的な Web ブラウザに入力すると、Wendy Hall の HTML 版ページにリダイレクトされます。このページには、彼女について Web に公開されているデータのすべてを表示しています。また、このページから彼女自身の URI や、彼女についての RDF 文書へのリンクが張られています。
D2R Server は、リレーショナルデータベースのデータをガイドラインに従い、セマンティック Web 上に公開するオープンソースのアプリケーションです。このアプリケーションは、303 URI とコンテントネゴシエーションを採用しています。たとえば、DBLP Bibliography Database の D2R Server では、数十万の目録データと、その著者についての情報を公開しています。303 リダイレクトからつながる URI の例は、次の通りです。
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 があります。カールスルーエ市の記事を見てみましょう。
RDF 文書の URI は理想的なものではあまりありません。実装固有の情報 (php) や、クエリ－部分とパスのどちらにもある、「RDF を出力する」という情報です。よい URI を与えるとしたら http://ontoworld.org/rdf/Karlsruhe の様になるでしょう。
これまでリソースの命名に関し、さまざまな提案がなされてきました。しかし、多くの提案は特定の状況下における解決策であり、Section 3 で解説した「Web上にあること」と、「曖昧でないこと」という二つの指針に沿わないと感じました。つまり、標準技術ベースで、分断されていない、分散的なセマンティック Web を構築するために利用できる、一般的な解決法ではないのです。ここではそのような二つの案について解説します。
HTTP URI は既に Web リソースと Web 文書を識別していますが、他の種類のリソースについては識別していません。では、それら他のリソースを識別するため、新しい URI スキームを作ればよいのではないでしょうか。新しい URI スキームを利用することにより、Web 文書とその他のリソースを、URI の先頭を見るだけで判別することができるのです。たとえば、info スキームを用い、本を識別することができます。LCCN 番号に基づいて本を識別する場合は、info:lccn/2002022641 のようになります。
このような新しい URI スキームはいくつかあり、Thompson と Orchard によって URNs, Namespaces and Registries [TAG-URNs] という文書にまとめられています。いくつか例を挙げてみましょう。
info:lccn/2002022641) やデューイ十進分類法 (info:ddc/22/eng//004.678) が挙げられます。tag:hawke.org,2001-06-05:Taiko@Jones.and.Company/(+phone.number) や xri://northgate.library.example.com/(urn:isbn:0-395-36341-1) といったものが挙げられます。真に実用的になるために、新しい URI スキームは、識別されるリソースについての情報にアクセスするためのプロトコルを定義する必要があります。たとえば、ftp::// URI スキームはリソース (FTP サーバー上のファイル) と、リソースにアクセスするためのプロトコル (FTP プロトコル) を識別しています。
新しい URI スキーマのいくつかは、このようなプロトコルを提供していません。他のスキームについては、HTTP プロトコルを用いてリソースの説明を取得できるような Web サービスを提供しています。識別子がサービスに渡されると、情報を中央データベースや連合データベースから検索するのです。この方法の問題は、サービスの欠陥によりシステムが利用できなくなることです。
他の欠点として、標準化団体への依存が挙げられます。新しいパートを info: 空間に登録するには、標準化団体にコンタクトを必要があります。このことや、また URI の作成ライセンス料を払う必要が出てきた場合、その URI の普及が遅くなってしまいます。たとえば ISBN など、すべての URI が一意であることを保証したい場合には、標準化団体の存在は望ましいでしょう。しかし、これは標準化組織により保持・管理される HTTP 名前空間内の URI によって実現することができるのです。
新しい URI スキームの問題点については、URNs, Namespaces and Registries で詳しく述べられています。
このアプローチは、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! ”に賛同します。
セマンティック Web において、リソースの名前は二つの要件を満たすことが推奨されます。一つは、識別されるリソースの説明が、標準的な Web 技術によって取得可能であること。そしてもう一つは、命名スキームが文書と文書が説明するものとを混同しないようなものであることです。
私たちは、これらの要件を満たす二つの解決策について説明しました。どちらも、HTTP スキームとプロトコルを利用しています。ひとつは 303 HTTP ステータスコードを利用し、リソース識別子から解説文書へリダイレクトするものです。もう一つは“ハッシュ URI”を利用しリソースを識別し、URI がハッシュ以降の部分をリソースの取得時に使用しないという仕様を利用するというものです。
リソースとその説明を分けてとらえるという要件により、複数の URI を調整することが必要となってきます。このような場合に利用できる便利なテクニックとして、HTML 文書から RDF データへのリンクを埋め込む、RDF ステートメントを利用し URI の関係を説明する、コンテントネゴシエーションを利用して適切な説明をもつリソースへリダイレクトするなどがあります。
まず、Tim Berners-Lee 大変感謝しています。彼は私たちが TAG の解決策を理解する際、チャットでのリクエスト に答え、またメールによる詳しい説明を提供してくれました。また特に、この文書のレビューを行い、TAG の考えと異なる多くの論拠について本質的なフィードバックを 2007 年 6 月 と 2007 年 9 月 に提供してくれた、Stuart Williams (HP Labs) と TAG の Norman Walsh にも感謝しています。また、Semantic Web Deployment Group のメンバー Michael Hausenblas、Vit Novacek、Ed Summers らが 2007 年 10 月 に行ったレビューとそのまとめにも感謝しています。最後に、草稿段階にあったこの文書をレビューしてくれた皆さん、特に Chris Bizer と Gunnar AAstrand Grimnes に感謝しています。
この文書の作成は German Federal Ministry of Education, Science, Research and Technology (bmb+f)、(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) のサポートにより実現しました。
Non-addressed issues and general handling of issues
The editors collected all recognized feedback in a SVN folder, with more notes on the editing status.
Some issues found by reviewers were intentionally not addressed by the editors. They are marked with red-colored backgrounds in these documents:
TODO
@@ pubrules were checked on 12.12.2007 by Leo Sauermann, repeated checking is good once the document is on the /TR location.
@@ TAG suggested a replacement for the first graphic in their review. Not done yet (12.12.2007)
@@ issue of using the terms "non-informationresource", "information resource" or "web document".
Leo Sauermann: The term "web document" is not common in W3Cs standardization language.
Nevertheless it is understandable by the target audience, web developers.
Tim Berners lee indicated positive feedback (link needed) towards the term "web document",
both the SWD and TAG are critisising "web document" and required better explanations or dropping the term. As this is W3C note, we
should think about dropping the term "web document".
Richard Cyganiak, Thu, 29 Nov 2007: I'm strongly opposed to changing
this terminology. "Non-information resource" is possibly the most
unfortunate term ever used in discussions of web architecture, and we should
quickly forget that it ever existed. ... Information
resource" is an official engineering term, but inappropriate for an
introductory document. The terms we currently use, "thing"/"other resource"
and "web document" are appropriate, sufficiently well-explained and correct.
The terminology has support from key TAG members, including Tim Berners Lee. I don't
think that anything needs to be changed with regard to these terms.
@@ Reviewers asked for example rules of thumb how to distinguish between document identifiers and concept identifiers (information and non-information resources). Write some wget examples that do that? Leo Sauermann agrees that we did not cover the crucial point yet: what is the definitive test to verify that a URI identifies a non-information resource? Range-14 says: "If an "http" resource responds to a GET request with a 303 (See Other) response, then the resource identified by that URI could be any resource;" Or is this such a problem at all? At the end the RDF:type indicates the nature of a resource. If we find a script example, I would put that into the 4.6. implementation section.
@@ Danny Ayers: style - Abstract and much of the content uses 1st person plural "we..." - is that ok? Leo Sauermann: Its typical for scientists (the authors) to use this wording, and acceptable outside scientific publications.
@@ Danny Ayers: style - Web/web, web site/website - consistency needed
@@ Danny Ayers: Status will probably need editing for W3C-conformance
@@ Danny Ayers: "follow-your-nose" might be a useful phrase to include somewhere