RDF語彙公開のためのベストプラクティスのレシピ

W3Cワーキンググループノート2008年8月28日

このバージョン：

http://www.w3.org/TR/2008/NOTE-swbp-vocab-pub-20080828/

最新バージョン：

http://www.w3.org/TR/swbp-vocab-pub/

前のバージョン：

http://www.w3.org/TR/2008/WD-swbp-vocab-pub-20080123/

編集者：

Diego Berrueta, Fundación CTIC

Jon Phipps, Cornell University Library

前の編集者：

Alistair Miles, STFC Rutherford Appleton Laboratory

Thomas Baker, Goettingen State and University Library

Ralph Swick, W3C

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

---

要旨

この文書では（RDFスキーマやOWLで）ウェブ上の語彙やオントロジーを公開するためのベストプラクティスのレシピを説明します。語彙デザイナーが自分のニーズに最も適したレシピを選択することができるよう、各レシピの特徴を詳細に記載しています。各レシピでは、一般的な原則とApache HTTPサーバーで使用するための設定例（他の環境にも適合させることができます）を紹介しています。各レシピに関連する設定例は意図的に単純にしていますが、レシピはすべて現在仕様化されているウェブアーキテクチャと一致するように設計されています。

本文書のステータス

このセクションでは、公開時点での本文書のステータスを説明します。他の文書が本文書を上書きしている可能性があります。現行のW3Cの刊行物および技術報告の最新の改訂版のリストはW3C technical reports index（http://www.w3.org/TR/）で見つけることができます。

本文書は、Semantic Web Best Practices and Deployment Working Group (SWBPD)における以前の作業の基づき、Semantic Web Deployment Working Group (SWD)により作成されたものです。本作業はW3C Semantic Web Activityの一部です。

本文書はいくつかのベストプラクティスを記述するノートです。公開時点で、本文書に対するSemantic Web Deployment Working Groupにおける今後の作業予定はありません。このバージョンは、以前のバージョンで行われたいくつかのコメントに対応しています。しかし、コンテントネゴシエーションで「q」値がつけられたものに関する既知の問題を解決しようとしたものではなく、また、いくつかの語彙に有用な技術として知られているRDFa[RDFa]とGRDDL [GRDDL]を用いた語彙公開のためのレシピを提供することもしません。

コメントを歓迎します。件名にテキスト「comment」を含めてpublic-swd-wg@w3.org宛に送付してください。このアドレスで受信したすべてのメッセージは公開アーカイブにて閲覧可能です。ワーキンググループは、適宜コメントに回答することもあります。私たちは、Semantic Web Interest Groupのメーリングリストで、このノートの解釈を議論するためのコミュニティを奨励します（公開アーカイブ）。

本文書は、2004年2月5日W3C特許方針の下で活動するグループにより作成されました。W3Cは、グループの成果物に関連して作成されたあらゆる特許の開示の公開リストを維持します。そのページには、特許開示にあたっての指示も含まれています。エッセンシャルクレームを含むと信じる特許について具体的な知識を持つ個人は、W3C特許方針のセクション6に従ってそれを公開しなくてはなりません。

ワーキンググループノートとしての公開は、W3C会員による承認を意味するものではありません。本文書はドラフトであり、いつでも他の文書によって更新、置換または廃止される可能性があります。進行中の作業を除き、本文書の引用は不適切です。

目次

• はじめに
• レシピの選択
• コンテントネゴシエーション
• レシピ1．「ハッシュ名前空間」の最小設定
• レシピ2．「スラッシュ名前空間」の最小設定
• レシピ3．「ハッシュ名前空間」の拡張設定
• レシピ4．単一のHTML文書を使用した「スラッシュ名前空間」の拡張設定
• レシピ5．複数のHTML文書を使用した「スラッシュ名前空間」の拡張設定
• レシピ6．複数のHTML文書とクエリサービスを使用した「スラッシュ名前空間」の拡張設定
• 必要条件

• 謝辞
• 参考文献
• 付録A：命名のためにPURLを使用した語彙
  • PURL適用レシピ： レシピ1a | レシピ2a | レシピ3a | レシピ4a | レシピ5a
• 付録B：URI名前空間
• 付録C：303-リダイレクトサービスに基づく語彙のURI
• 付録D：Apacheの設定

はじめに

本文書はRDFSとOWLで表現された語彙のクリエイターやメンテナのために書かれています。なお、本文書においては語彙とオントロジーは同義として使います。本文書では、最も一般的なケースがカバーされるように設計された設定例を与えて、ウェブ上で語彙を公開するための手順を説明します。RDFSとOWLについて詳しくは次の文書を参照してください[RDFS、RDFPrimer、OWLGuide、OWLFeatures]。

この「クックブック」は、ウェブサーバー上に語彙を公開すること、およびセマンティックウェブアプリケーションをサポートするウェブサーバーを設定するために必要な手順を記述した「レシピ」を提供します。「レシピを選択する」では状況や要件に応じて最適なレシピを選択するための助言を提供します。レシピを選択したら、記述されている例を特定の語彙に適応させながら、手順に従って設定できます。

レシピはすべて、ApacheのHTTPサーバー[APACHE20]向けの設定例となっています。Apacheの設定に慣れていない方のために、付録Apacheの設定では、例の中で使われる設定の仕組みについて、問題が生じた際の対応に関する基本的な情報とともに簡単に紹介しています。

設定例はApache HTTPサーバー向けですが、一般的な原理は、非Apacheの環境にも適用できます。ワーキンググループでは、非Apacheサーバー向けの情報が追加されることを望みます。W3Cは、Apache以外のバインディングと提言を集めるためのWikiページを提供しています。

本文書は主に語彙をウェブ上で最良な形で公開する方法について助言を求めている、既存語彙のクリエイターとメンテナのために意図されています。そして本文書は、新しい語彙やその構成用語を命名するための適切なURI名前空間を選択することについての詳細かつ網羅的な助言を提供するものではありません。しかし、語彙のURI名前空間を選択するさいの検討事項を含む、基本的なURIの名前空間に関する技術情報は、URI名前空間セクションに書かれています。

レシピはすべて、「ワールド・ワイド・ウェブのアーキテクチャ[AWWW04]」で現在規定されているワールド・ワイド・ウェブのアーキテクチャ原則に一致するよう作られています。このことを確認するために、本文書の最後に一連の最小要件が記載されています。これらの最小要件は、セマンティックウェブアプリケーションの基本的な要件を明確にすることを意図しています。すべてのレシピが適切に実装されれば、この最小要件を満たすはずです。さらに、一連の拡張要件をも記載しています。拡張要件は、ある語彙に関する資料をウェブページ上でHTMLを用いて提供するなど、セマンティックウェブアプリケーション開発者の更なる実用的なニーズを明確にすることを意図しています。レシピ3、4、5、6が適切に実装されれば、この拡張された要件を満たすはずです。

拡張要件を満たすために、レシピ3、4、5、6ではサーバーがコンテントネゴシエーションを行うよう設定します。このプロセスについては、コンテントネゴシエーションセクションにて簡単に説明しています。そこでは併せて様々なクライアントの動作の違いに対処するためのオプションについても説明しています。

付録Aでは、http://purl.org/[PURL]のようなPURLサービスを用いた解決を行う「永続的な（Persistent）URL」、あるいはPURLを利用して特定される語彙向けに、本文中で説明がなされている6つのレシピの適用方法を説明しています。

簡単のためレシピの論拠は記載していません。より詳しく知りたい場合は次の文書を参照してください。
1. 「ワールド・ワイド・ウェブのアーキテクチャ」[AWWW04]中のURI /リソースの関係、
2. HTTPのURI[RFC3986] [RFC2616]におけるフラグメント識別子、
3. W3Cインタレストグループノート：「セマンティックウェブのためのクールなURI」[COOLURI]、
4. W3Cテクニカルアーキテクチャグループ決議のうちの、HTTP参照解決に関する範囲（別名「httpRange-14」）[HTTPRANGE14]。

最後に、このクックブックで説明するレシピは、セマンティックウェブアプリケーションで使用するための語彙やオントロジーを公開するための唯一の方法ではないことにご留意ください。RDFaやGRDDLは近い将来、人と機械の双方で使われる文書を公開するための効果的な方法を提供するでしょう。しかし、RDFaのとGRDDLに関する有益な議論をすることは本文書の範囲外です。

レシピを選択します

レシピの選択は、語彙URIで提供したいコンテントタイプと、語彙で定義されるクラスやプロパティのURIにより決まります。URIの名前空間については付録Bで詳細を記載していますが、本文書全体を通して、「語彙URI」は、「語彙の名前空間URI」と解釈することとします。

選択早見表

簡単な設定

最も簡単なレシピは、語彙URIに対して機械処理可能（RDF）コンテンツだけを提供するようサーバーを構成するものです。

ハッシュ名前空間を使用している場合はレシピ1を参照してください。ただしPURLを使用している場合にはレシピ1aを参照してください。

スラッシュ名前空間を使用している場合はレシピ2を参照してください。ただしPURLを使用している場合はレシピ2aを参照してください。

拡張設定

拡張レシピでは、機械処理可能（RDF）と人可読（HTML）の双方のコンテンツを提供するようサーバーを設定します（コンテントネゴシエーションセクションも参照ください）。これらのレシピは別のコンテントタイプも提供できるよう簡単に拡張できます。

ハッシュ名前空間を使用していて、RDFとHTMLコンテンツの双方を提供したい場合はレシピ3を参照してください。ただしPURLを使用している場合はレシピ3aを参照してください。

スラッシュ名前空間を使用していて、RDFとHTMLコンテンツの双方を提供したい、そして、HTMLコンテンツが単一の文書に含まれている場合はレシピ4を参照してください。ただしPURLを使用している場合はレシピ4aを参照してください。

スラッシュ名前空間を使用していて、RDFとHTMLコンテンツの双方を提供したい、そしてHTMLコンテンツについては、語彙URIにおいて目次や索引などの概要とともに、各クラスやプロパティはそれぞれハイパーリンクでリンクした個々の文書として提供したい場合はレシピ5を参照してください。ただしPURLを使用している場合はレシピ5aを参照してください。

スラッシュ名前空間を使用していて、RDFとHTMLコンテンツの双方を提供したい、そしてHTMLコンテンツについては個々のクラスやプロパティに対してそれぞれハイパーリンクでリンクした文書として提供したい、さらにRDFについては各クラスやプロパティの記述の一部を提供したい場合はレシピ6を参照してください。

コンテントネゴシエーション

HTTPクライアントが、あるURIを参照解決しようとするとき、返されるコンテンツについて希望のタイプを指定できます。これはリクエストメッセージのヘッダに「Accept:」フィールドを含めることで実現でき、その値として希望するMIMEタイプを与えます。例えば、RDF/XMLコンテンツを望むHTTPクライアントは各リクエストのヘッダに次のフィールドを含めることでしょう。

Accept: application/rdf+xml

同様に、ウェブブラウザなど、HTMLコンテンツを望むHTTPクライアントは、各リクエストのヘッダに次のようなフィールドを含めることでしょう。

Accept: application/xhtml+xml,text/html

HTTPクライアントは、リクエストヘッダ中に、処理可能なコンテントタイプを「Accept:」フィールドで陽に指定すべきということは、ベストプラクティスとして受け入れられています。

サーバーはリクエストを受け取る際に、クライアントの希望を最大限満たすよう、最も適切なレスポンスを対応可能なものの中から選ぶために「Accept:」フィールドの値を利用できます。このプロセスはコンテントネゴシエーション[AWWW04] の一例です。

レシピ1および2は、サーバーがコンテントネゴシエーションをしない設定です。RDF/XMLが唯一の表現タイプであり、クライアントから送られる「Accept:」ヘッダの値に左右されません。

レシピ3、4、5、6はクライアントから送信されたヘッダフィールド「Acdept:」の値に基づいて、コンテントネゴシエーションを行うようにサーバーを設定します。しかし、提案された設定例は、コンテントネゴシエーションに関するHTTPの仕様のすべてに対応するものではありません。事実、設定例ではコンテントネゴシエーションにおけるクライアントの希望順にある程度は対応するものの、「q」指標を扱うことはできません。したがって、「Accept:」ヘッダーにq値を使用するHTTPクライアントは、予期しない結果を得るかもしれません。

編集者注：できるだけレシピの容易性を維持しながら、HTTP仕様に完全準拠する代替案をワーキンググループは検討しています。これはワーキンググループのイシュープロセスにおけるISSUE-58として記録されています。この問題に関するコメントは歓迎です。「Comment: ISSUE-58」から始まる件名でSWDワーキンググループ宛てにEメールをお寄せください。

デフォルトの動作

サーバーがコンテントネゴシエーションを行うよう設定されている場合、「デフォルトの動作」を定めなければなりません。すなわち、次のような場合におけるレスポンスを決定できなくてはなりません。

1. クライアントが「Accept:」フィールドをメッセージヘッダに含めていない。すなわち、クライアントは所望のタイプを指定していない。
2. 「Accept:」フィールドの値がが使用可能なコンテントタイプのいずれにも一致しない。つまり、クライアントはRDF/XMLやHTML以外を要求している。

レシピ3、4、5、6では、RDF/XMLがデフォルトのレスポンスとして設定されています。これは、RDFコンテンツに対する適切な「Accept:」ヘッダフィールド値を要求しないセマンティックウェブアプリケーションへの影響を最小化するために選ばれたものです。もしもHTMLがデフォルトのレスポンスタイプとして設定されていると、RDFコンテンツを受け取るように作られている既存のセマンティックウェブアプリケーションがHTML文書を受け取ることになり、不具合を起こすということを心に留めておいてください。

「Accept:」ヘッダの提供

RDFコンテンツを処理することが期待されるセマンティックウェブアプリケーションを開発したり維持したりしていて、現在この「Accept:」ヘッダフィールドをHTTPリクエストに含めていない場合は、早々に提供する計画を立てるべきです。

「Accept:」フィールドにおける適切な値は次の通りです。

Accept: application/rdf+xml,application/xml;q=0.5

HTTP 1.1プロトコル[RFC2616]のセクション14で規定されているとおり、この例中の「q=0.5」は、相対的な品質値を示します。何も指定されていない場合のデフォルトの「q」値は1.0です。この例は次のように読むことができます。すなわち、「application/rdf+xml」にデフォルトの相対品質値である1.0を与えてこれを希望しますが、その半分（50%）だけのq値で「application/xml」も受け入れます。

Internet Explorer用の特別なデフォルト動作

他のほとんどのブラウザと異なり、Internet Explorerは、すべてを受け取ることを示す*/*を「q」値無しで「Accept:」ヘッダに含めて送信します。これとは対照的に、FirefoxとSafariは双方とも*/*;q=0.5とし、Operaは*/*;q=0.1とします。これらを考慮したデフォルトの振る舞いを確立するためには、「User-agent:」ヘッダフィールドの値に基づく書き換え条件を設定に挿入する必要があります。

RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*

さらに、IEの「クリック可能な」URIをそのままにしたいなら、​​デフォルトレスポンスとしてHTMLを設定する必要があります。

サーバー設定のテスト

いくつかのレシピについては、コンテントネゴシエーションの結果を効果的にテストすることがかなり複雑になり得ます。単一のURIにおけるコンテントネゴシエーションの結果の試験を容易にするために、コンテントネゴシエーション試験サービスが提供されています。

このサービスでは、サーバーから提供されたURIをリクエストし、レシピの仕様に対するサーバーのレスポンスをテストするために設計されたテストスイートを実行し、そして各テストの成否レポートが、調査結果の詳細な説明とともに表示されます。

テストサービスのためのソースコードも利用可能です。

レシピ1．「ハッシュ名前空間」の最小設定

設定例 | 設定のテスト

このレシピは、ハッシュ名前空間を使う語彙のための最も簡単な設定例になります。語彙URIから機械処理可能な（RDF）コンテンツを提供するようサーバーを設定して最小要件を満たします。以下の図のようなやりとりになります：

設定例

語彙...

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example1

クラス定義...

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example1#ClassA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example1#ClassB

プロパティ...

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example1#propA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example1#propB

ステップ1

RDF/XML形式にした語彙全体を含むexample1.rdfというファイルを作ります。すなわち当該語彙で定義されているすべてのリソースは、このファイルに記述されています。

ステップ2

ファイルexample1.rdfをサーバー上のディレクトリ/apachedocumentroot/examples/にコピーします。

ステップ3

下記のディレクティブをサーバー上のディレクトリ /apachedocumentroot/examples/にある、ファイル.htaccessに追記します。

# Directive to ensure *.rdf files served as appropriate content type,
# if not present in main apache config
AddType application/rdf+xml .rdf

# Rewrite engine setup
RewriteEngine On
RewriteBase /examples

# Rewrite rule to serve RDF/XML content from the vocabulary URI
RewriteRule ^example1$ example1.rdf

（注：.htaccessファイルが無い場合は作成します。）

設定のテスト

この設定がうまく機能している場合には次のようなやり取りがなされるはずです。

GET /examples/example1 HTTP/1.1
Host: example.com

HTTP/1.x 200 OK
Content-Type: application/rdf+xml

レシピ2．「スラッシュ名前空間」の最小設定

設定例 | 構成のテスト

このレシピは、スラッシュ名前空間を使用する語彙のための最も簡単な設定例になります。語彙URIから機械処理可能な（RDF）コンテンツを提供し、クラスとプロパティのURIから語彙URIにクライアントをリダイレクトするようにサーバー設定することで最小要件を満たします。以下の図のようなやりとりになります：

設定例

語彙...

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example2/

クラス定義...

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example2/ClassA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example2/ClassB

プロパティ...

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example2/propA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example2/propB

ステップ1

RDF/XML形式にした語彙全体を含むexample2.rdfというファイルを作ります。すなわち、語彙で定義されている全てのリソースがこのファイルに記述されています。

ステップ2

サーバー上の/apachedocumentroot/examples/ディレクトリにファイルexample2.rdfをコピーします。

ステップ3

サーバー上のディレクトリ/apachedocumentroot/examples/にあるファイル.htaccessに次のディレクティブを追記します。

# Turn off MultiViews
Options -MultiViews

# Directive to ensure *.rdf files served as appropriate content type,
# if not present in main apache config
AddType application/rdf+xml .rdf

# Rewrite engine setup
RewriteEngine On
RewriteBase /examples

# Rewrite rule to redirect 303 from any class or prop URI
RewriteRule ^example2/.+ example2/ [R=303]

# Rewrite rule to serve RDF/XML content from the vocabulary URI
RewriteRule ^example2/$ example2.rdf

（注：.htaccessファイルが無い場合は作成します。）

ディレクトリオプションの「MultiViews」は、この設定が機能するために無効にする必要があります。さらに、ディレクトリ/apachedocumentroot/examples/example2/は実際にはサーバーのファイルシステム上に存在してはなりません。

設定のテスト

この設定がうまく機能している場合には次のようなやり取りがなされるはずです。

GET /examples/example2/ HTTP/1.1
Host: example.com

HTTP/1.x 200 OK
Content-Type: application/rdf+xml

GET /examples/example2/ClassA HTTP/1.1
Host: example.com

HTTP/1.x 303 See Other
Location: http://example.com/examples/example2/

レシピ3．「ハッシュ名前空間」の拡張設定

設定例 | 設定のテスト | 注意事項

このレシピは、ハッシュ名前空間をもつ語彙の拡張構成例になります。語彙URIから人可読（HTML）もしくは機械処理可能（RDF）コンテンツのいずれかを要求に応じて提供するようにサーバーを設定し、拡張要件を満たします。以下の図のようなやりとりになります：

設定例

語彙...

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example3

クラス定義...

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example3#ClassA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example3#ClassB

プロパティ...

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example3#propA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example3#propB

ステップ1

2005年10月31日時点の（または現在の日付であれば何でも）、RDF/XML形式にした語彙全体を含む2005-10-31.rdfというファイルを作成します。すなわち当該語彙で定義されているすべてのリソースは、このファイルに記述されており、このファイルは当該語彙の「スナップショット」や「バージョン」を表しています。

ステップ2

2005年10月31日時点の（または現在の日付であれば何でも）語彙で定義されたすべてのクラスとプロパティに関するHTMLコンテンツ文書が含まれる、2005-10-31.htmlというファイルを作成します。この文書には、各クラスやプロパティについて説明するセクションを含められますが、その際には、各セクション冒頭に、これらのクラスやプロパティのフラグメント識別子と同一であるHTMLアンカーを埋め込みます。

ステップ3

2005-10-31.rdfと2005-10-31.htmlをサーバー上のディレクトリ/apachedocumentroot/examples/example3-content/にコピーします。

ステップ4

/apachedocumentroot/exmples/ディレクトリにある.htaccessファイルに次のディレクティブを追加します。

# Turn off MultiViews
Options -MultiViews

# Directive to ensure *.rdf files served as appropriate content type,
# if not present in main apache config
AddType application/rdf+xml .rdf

# Rewrite engine setup
RewriteEngine On
RewriteBase /examples

# Rewrite rule to serve HTML content from the vocabulary URI if requested
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example3$ example3-content/2005-10-31.html [R=303]

# Rewrite rule to serve RDF/XML content from the vocabulary URI if requested
RewriteCond %{HTTP_ACCEPT} application/rdf\+xml
RewriteRule ^example3$ example3-content/2005-10-31.rdf [R=303]

# Choose the default response
# ---------------------------

# Rewrite rule to serve the RDF/XML content from the vocabulary URI by default
RewriteRule ^example3$ example3-content/2005-10-31.rdf [R=303]

# Rewrite rule to serve HTML content from the vocabulary URI by default (disabled)
# (To enable this option, uncomment the rewrite rule below, and comment
# out the rewrite rule directly above)
# RewriteRule ^example3$ example3-content/2005-10-31.html [R=303]

（注：.htaccessファイルが無い場合は作成します。）

設定のテスト

この設定がうまく機能している場合には次のようなやり取りがなされるはずです：

GET /examples/example3 HTTP/1.1
Host: example.com
Accept: text/html

HTTP/1.x 303 See Other
Location: http://example.com/examples/example3-content/2005-10-31.html

GET /examples/example3 HTTP/1.1
Host: example.com
Accept: application/rdf+xml

HTTP/1.x 303 See Other
Location: http://example.com/examples/example3-content/2005-10-31.rdf

GET /examples/example3 HTTP/1.1
Host: example.com

HTTP/1.x 303 See Other
Location: http://example.com/examples/example3-content/2005-10-31.rdf

注意点

この例ではファイル名を語彙バージョンの変更日としています。また、日付の代わりにバージョン番号（例えば「1.01」）を使うこともできますし、さらには語彙のバージョンを区別し、来歴を保持するためのどんな命名法を使用しても問題ありません。

また、コンテントネゴシエーションも参照してください。

レシピ4．単一のHTML文書を使用した「スラッシュ名前空間」の拡張設定

設定例 | 設定のテスト | 注意事項

スラッシュ名前空間をもつ語彙向けの拡張設定例を示します。語彙URIから人可読（HTML）もしくは機械処理可能（RDF）コンテンツのいずれかを要求に応じて提供するようにサーバーを設定し、さらに要求に応じてクラスまたはプロパティURIから適切なコンテンツを取得できるようクライアントをリダイレクトすることで拡張要件を満たします。HTML文書は、単一のファイルとして提供されています。以下の図のようなやりとりになります：

設定例

語彙...

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example4/

クラス定義...

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example4/ClassA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example4/ClassB

プロパティ...

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example4/propA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example4/propB

ステップ1

2005年10月31日時点の（または現在の日付であれば何でも）、RDF/XML形式にした語彙全体を含む2005-10-31.rdfというファイルを作成します。すなわち語彙で定義されているすべてのリソースは、このファイルに記述されており、このファイルは語彙の「スナップショット」や「バージョン」を表しています。

ステップ2

2005年10月31日時点の（または現在の日付が何であれ）語彙で定義されたすべてのクラスとプロパティに関するHTMLコンテンツ文書が含まれる2005-10-31.htmlというファイルを作成します。この文書には、各クラスやプロパティについて説明するセクションを含められますが、その際には、各セクション冒頭に、これらのクラスやプロパティのフラグメント識別子と同一であるHTMLアンカーを埋め込みます。

ステップ3

2005-10-31.rdfと2005-10-31.htmlをサーバー上のディレクトリ/apachedocumentroot/examples/example4-content/にコピーします。

ステップ4

/apachedocumentroot/examples/ディレクトリにある.htaccessファイルに次のディレクティブを追加します。

# Turn off MultiViews
Options -MultiViews

# Directive to ensure *.rdf files served as appropriate content type,
# if not present in main apache config
AddType application/rdf+xml .rdf

# Rewrite engine setup
RewriteEngine On
RewriteBase /examples

# Rewrite rule to serve HTML content from the vocabulary URI if requested
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example4/$ example4-content/2005-10-31.html [R=303]

# Rewrite rule to serve directed HTML content from class/prop URIs
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example4/(.+) example4-content/2005-10-31.html#$1 [R=303,NE]

# Rewrite rule to serve RDF/XML content if requested
RewriteCond %{HTTP_ACCEPT} application/rdf\+xml
RewriteRule ^example4/ example4-content/2005-10-31.rdf [R=303]

# Choose the default response
# ---------------------------

# Rewrite rule to serve RDF/XML content by default
RewriteRule ^example4/ example4-content/2005-10-31.rdf [R=303]

# Rewrite rules to serve HTML content by default (disabled)
# (To enable this option, uncomment the two rewrite rules below,
# and comment out the rewrite rule directly above)
# RewriteRule ^example4/$ example4-content/2005-10-31.html [R=303]
# RewriteRule ^example4/(.+) example4-content/2005-10-31.html#$1 [R=303,NE]
 

（注：.htaccessファイルが無い場合は作成します。）

この設定が機能するためには、ディレクトリオプションの「MultiViews」を無効にする必要があり、さらに、/apachedocumentroot/examples/example4/というディレクトリは、実際にはサーバーのファイルシステム上に存在してはなりません。

設定のテスト

この設定がうまく機能している場合には次のようなやり取りがなされるはずです：

GET /examples/example4/ HTTP/1.1
Host: example.com
Accept: text/html

HTTP/1.x 303 See Other
Location: http://example.com/examples/example4-content/2005-10-31.html

GET /examples/example4/ HTTP/1.1
Host: example.com
Accept: application/rdf+xml

HTTP/1.x 303 See Other
Location: http://example.com/examples/example4-content/2005-10-31.rdf

GET /examples/example4/ HTTP/1.1
Host: example.com

HTTP/1.x 303 See Other
Location: http://example.com/examples/example4-content/2005-10-31.rdf

GET /examples/example4/ClassA HTTP/1.1
Host: example.com
Accept: text/html

HTTP/1.x 303 See Other
Location: http://example.com/examples/example4-content/2005-10-31.html#ClassA

GET /examples/example4/ClassA HTTP/1.1
Host: example.com
Accept: application/rdf+xml

HTTP/1.x 303 See Other
Location: http://example.com/examples/example4-content/2005-10-31.rdf

GET /examples/example4/ClassA HTTP/1.1
Host: example.com

HTTP/1.x 303 See Other
Location: http://example.com/examples/example4-content/2005-10-31.rdf

注意点

レシピ3と同様に、この例では語彙バージョンの変更日をファイル名にしています。また、日付の代わりにバージョン番号（例えば「1.01」）を使うこともできますし、さらには語彙のバージョンを区別し、来歴を保持するためのどんな命名法を使用しても問題ありません。

また、コンテントネゴシエーションも参照してください。

レシピ5．複数のHTML文書を使用した「スラッシュ名前空間」の拡張設定

設定例 | 設定のテスト | 注意事項

このレシピではスラッシュ名前空間をもつ語彙向けの拡張設定例を示します。要求内容に応じて、機械可読（RDF）と人間可読（HTML）の双方のコンテンツを提供するサーバーを設定します。HTML文書については概要と、ハイパーリンクで結ばれた複数の文書になります。以下の図のようなやりとりになります：

設定例

語彙...

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example5/

クラス定義...

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example5/ClassA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example5/ClassB

プロパティ...

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example5/propA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example5/propB

ステップ1

2005年10月31日時点の（または現在の日付であれば何でも）、RDF/XML形式にした語彙全体を含む2005-10-31.rdfというファイルを作成します。すなわち語彙で定義されているすべてのリソースは、このファイルに記述されており、このファイルは語彙の「スナップショット」や「バージョン」を表します。

ステップ2

2005-10-31.rdfをサーバー上のディレクトリ/apachedocumentroot/examples/example5-content/にコピーします。

ステップ3

2005年10月31日時点（または現在の日付であれば何でも）の、対応するローカル名と一致する名を持つ、クラスまたはプロパティに関連度の高いHTML文書が含まれる以下のファイルを作ります。すなわち、ClassA.html ClassB.html propA.html propB.htmlになります。すべてのクラスやプロパティのドキュメントへのハイパーリンクを含む、語彙自体に関するHTML文書が含まれるindex.htmlファイルを作成します。

ステップ4

ClassA.html ClassB.html propA.html propB.htmlおよびindex.htmlを、サーバー上の/apachedocumentroot/examples/example5-content/2005-10-31-docs/ディレクトリにコピーします。

ステップ5

/apachedocumentroot/examples/ディレクトリにある.htaccessファイルに次のディレクティブを追加します。

# Turn off MultiViews
Options -MultiViews

# Directive to ensure *.rdf files served as appropriate content type,
# if not present in main apache config
AddType application/rdf+xml .rdf

# Rewrite engine setup
RewriteEngine On
RewriteBase /examples

# Rewrite rule 1: to serve HTML content from the namespace URI if requested
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example5/$ example5-content/2005-10-31-docs/index.html [R=303]

# Rewrite rule 2: to serve HTML content from class or prop URIs if requested
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example5/(.+) example5-content/2005-10-31-docs/$1.html [R=303]

# Rewrite rule 3: to serve RDF content is requested
RewriteCond %{HTTP_ACCEPT} application/rdf\+xml
RewriteRule ^example5/ example5-content/2005-10-31.rdf [R=303]

# Choose the default response
# ---------------------------

# Rewrite rule 4: to serve RDF/XML content by default
RewriteRule ^example5/ example5-content/2005-10-31.rdf [R=303]

# Rewrite rules to serve HTML content by default (disabled)
# (To enable this option, uncomment the two rewrite rules below,
# and comment out the rewrite rule directly above)
# RewriteRule ^example5/$ example5-content/2005-10-31-docs/index.html [R=303]
# RewriteRule ^example5/(.+) example5-content/2005-10-31-docs/$1.html [R=303]

（注：.htaccessファイルが無い場合は作成します。）

設定のテスト

この設定がうまく機能している場合には次のようなやり取りがなされるはずです：

GET /examples/example5/ HTTP/1.1
Host: example.com
Accept: text/html

HTTP/1.x 303 See Other
Location: http://example.com/examples/example5-content/2005-10-31-docs/index.html

GET /examples/example5/ClassA HTTP/1.1
Host: example.com
Accept: text/html

HTTP/1.x 303 See Other
Location: http://example.com/examples/example5-content/2005-10-31-docs/ClassA.html

注意点

コンテントネゴシエーションも参照してください。

レシピ3と同様に 、この例では語彙バージョンの変更日をファイル名にしています。また、日付の代わりにバージョン番号（例えば「1.01」）を使うこともできますし、さらには語彙のバージョンを区別し、来歴を保持するためのどんな命名法を使用しても問題ありません。

なお、ディレクトリ/apachedocumentroot/examples/example5-content/2005-10-31-docs/においてIndexesとMultiViewsオプションが有効の場合は、書き換え規則1と2を下記のような単一の規則で置き換えることが出来ます。

RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example5/(.*) example5-content/2005-10-31-docs/$1 [R=303]

この設定は、Protege向けのOWLDocプラグインによって生成された文書を扱うのに特に適しています。

レシピ6．複数のHTML文書とクエリサービスを使用した「スラッシュ名前空間」の拡張設定

このレシピでは、スラッシュ名前空間をもつ語彙の拡張構成の一例を示します。要求内容に応じて、機械処理可能（RDF）と人可読（HTML）の双方のコンテンツを提供するサーバーを設定します。HTML文書については概要と、ハイパーリンクで結ばれた複数の文書になります。また、RDFコンテンツについては、クライアントが語彙に関するRDFでの記述の一部を適宜取得できるクエリサービスにより利用可能となるものです。

このレシピは、レシピ5のほぼすべての機能を共有しているものの、RDFのコンテンツを取得するクエリサービスまたはスクリプトを使用すると、最も複雑な拡張構成とならざるを得ず、直接使用可能なレシピを提供するのに最大の課題となります。このため、ただ番号に従うようなレシピではなく、推奨される実装パターンのセットとして提示することにしました。また、他のレシピで採用しているのと同様の詳細さでは特定の実装パターンを記述していません。したがって、このレシピを実施するためにはいくつかのウェブプログラミングの知識が必要になります。

パターン1：アプリケーションロジックの使用

このパターンは、ウェブサーバーに配備されている幾つかのアプリケーションロジックに依存しています。このロジックは、単純にリクエストをサードパーティのウェブサーバーにリダイレクト（またはプロキシとして機能）するシンレイヤー（薄い層、以下のDBpediaの例を参照）か、RDFデータソースをロードし、クエリを処理するためにHTTPリクエストをAPI呼び出しに変換するシックレイヤー（厚い層）になります。

サーバー側のロジックを導入するにあたり、2つの選択肢があります。

1. サーバー側のスクリプト
   一般的なサーバーサイドスクリプト言語（PHPやPython、Perl、Ruby）はRDF APIを持ち、RDFトリプルストアとバインドできます。ですから、RDFファイルまたはRDFトリプルストアを照会し、該当部分を返す単純なスクリプトを記述するために使用することができます。
   • 長所：デプロイがしやすい（多くのウェブホスティングサーバーは、これらの言語のいずれかをサポートしています）
   • 短所：ウェブマスターは恐らくアドホックなスクリプトを記述することになります
2. Javaサーブレット（または同等のもの）
   • 長所：Javaの、RDFおよびSPARQL、そしてRDFトリプルストアに対するサポートが良い
   • 短所：ヘビー級ソリューション、デプロイが困難（サーブレットコンテナが必要）

実装例（選択肢1と2の双方に有効）

DBpediaのサーバーは、コンテンツプロバイダーとして、次の例で使用されます。

RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml
RewriteRule ^example6/(.+) http://dbpedia.org/page/$1 [R=303]

RewriteCond %{HTTP_ACCEPT} application/rdf\+xml
RewriteRule ^example6/(.+) http://dbpedia.org/data/$1 [R=303]

RewriteRule ^example6/(.+) http://dbpedia.org/data/$1 [R=303]

これは「薄い」実装層の一例で、書き換えルールは簡単です：

1. HTMLデータを要求した場合は、DBpediaのサーブレットが出力するHTML版のURLに転送されます。
2. RDFデータを要求した場合は、RDFデータのURLに転送されます。なお、RDFを返すことはデフォルトの動作であるため、「Acccept:」ヘッダの無い場合も同様です。

HTTPコンテントネゴシエーションをスクラッチで正しく実装することがアプリケーションロジックを使用してレシピ6を実装する最も難しい部分になります。ほとんどのウェブスクリプト言語（PHPやPython等）およびフレームワークは、HTTPヘッダ値へのアクセス方法がある一方で、「Accept:」ヘッダに対する適切な戻り値の型を選択することは自明とはほど遠いものです。「Accept:」ヘッダーには、ワイルドカードとq値が含まれる場合があるので、正規表現や単純な文字列比較関数では十分ではないのです。なお、さまざまなプログラミング言語用のコンテントネゴシエーションライブラリに対するリンクを含むwikiページがあります。ワーキンググループは、コンテントネゴシエーションをサポートする、追加のライブラリやフレームワークの貢献を求めています。

パターン2：Apacheを使用したSPARQLエンドポイントへのリダイレクト

このパターンはアプリケーションロジックを記述する必要はありませんが、その代わりに、リクエストはApacheのmod_rewriteを使用して、HTTPリダイレクトされます。この方法は、既存のSPARQLエンドポイントをラップするのに特に適しています。多くのSPARQLエンドポイントがHTTPバインディングを持つということを利用します。

• 長所：軽量、全くプログラミングを必要としません
• 短所：公開対象とする語彙向けのSPARQLエンドポイントが使用可能でなければなりません

実装例 ：

RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml
RewriteRule ^example6/(.+) http://dbpedia.org/$1 [R=303]

RewriteCond %{HTTP_ACCEPT} application/rdf\+xml
RewriteRule ^example6/(.+) http://dbpedia.org/sparql?query=DESCRIBE+<http://dbpedia.org/$1> [R=303]

RewriteRule ^example6/(.+) http://dbpedia.org/sparql?query=DESCRIBE+<http://dbpedia.org/$1> [R=303]

クライアントがHTMLコンテンツを要求すると外部のウェブサーバーに転送されますが、RDFを要求した場合は異なる方法で処理されます。http://example.org/example6/property/birthplaceのようなURIに対するリクエストは、 DBpediaのSPARQLエンドポイントに対してDESCRIBE <http://dbpedia.org/property/birthplace>文を実行した結果にリダイレクトされます。結果はリソースを記述するRDFグラフです。この例の場合は、人々と生誕地をリンクするプロパティになります。

ケーススタディ

• Joshua Taubererは米国国勢調査からの膨大なRDFデータセットを公開したと発表しました。SPARQLエンドポイントが利用可能で、URL書き換え方法を利用してURIは参照可能です。（例：http://www.rdfabout.com/rdf/usgov/geo/us）
• D2R Serverは関係データベースをラップし、それに対するSPARQLとリンクトデータのインタフェースを提供します。後者については、リソースに対するHTMLとRDF記述の双方を提供するための303リダイレクトを伴うコンテントネゴシエーションの例になります。一方、Pubbyは、既存のSPARQLエンドポイントにリンクトデータのインタフェースを提供します。詳細は「セマンティックウェブのためのクールなURI」[COOLURI]の5章にあります。

必要条件

このセクションでは、HTTPのURI（すなわちhttp:から始まるURI空間）で表される語彙、クラス、およびプロパティのHTTPの挙動に関してセマンティックウェブアプリケーションとアプリケーション開発者の要件と期待を明確にしようとします。これは、上記のレシピで指定された構成例を確認できるベンチマークとして意図されています。

最小要件

M1．HTTP URIで示される語彙、クラス、またはプロパティの「正式な」RDF記述は、その語彙、クラス、またはプロパティのURIを参照解決することで取得できます。

HTTPクライアントは、語彙、クラスまたはプロパティのURIに対してHTTP GETリクエストを実行することによって、当該語彙、クラス、またはプロパティの「正式な」RDF記述を取得することができます。RDFの記述は、RDFコンテンツに対して登録されたMIMEタイプのHTTPレスポンスとして返されます。

これは、コンテントネゴシエーションがURIに対して実装されている場合のデフォルトの動作です。すなわち「Accept:」ヘッダフィールドの無いHTTP GETリクエストに対して、対象リソースの「正式な」RDF記述を構成するRDFトリプル群のシリアライゼーション（application/rdf+xmlなど）を返します。

注：RDFプロパティやクラスのURIを参照解決しようとしたさいに、それらプロパティやクラスだけでなく、RDF記述を返すことは合理的と言えます。

M2．RDFS/OWL語彙やクラス、プロパティを表すHTTP URIの振る舞い​​は、示されたリソースの性質を解釈するさいに矛盾を生じません。

現在、ウェブのアーキテクチャにおいてアプリケーションは、HTTP URIで示されるリソースの性質について次の事項に基づき推論できます：

（ⅰ）URIを参照解決したときに得られるHTTPレスポンスコード（TAG問題「httpRange-14」についての解決を参照してください[HTTPRANGE14]）

そして、

（ii）URIがフラグメント識別子を含む場合、利用可能な表現のコンテントタイプ[AWWW04]。

これらの制約が与えられたときには、RDFS/OWLの語彙やクラス、プロパティを表す各HTTP URIへのHTTPリクエストに対して、アプリケーションが矛盾を含む結論を導き出すことのないようなレスポンスが得られます。

拡張要件

これらの要件は最小要件に対する拡張要件です。

E1．HTTP URIで示されるRDF語彙やクラス、プロパティに関する「人可読な」文書は、それらのURIを参照解決することで得られます。

ウェブブラウザなどのHTTPクライアントは、RDFS/OWL語彙やクラス、プロパティのURIに対してHTTP GETリクエストすることで、それに関する「人可読な」文書を取得できます。そのさい、「Accept:」ヘッダに所望のコンテントタイプを指定します。

E2．アプリケーションは、語彙の「バージョン」を区別できます。

時とともに語彙は変化します。なぜならプロパティやクラスが追加されたり、それらの記述が編集されたりするからです。このため、アプリケーションは語彙について一連の「スナップショット」を区別する方法が必要です。より正確には、「バージョン管理されるもの」はプロパティの説明です。つまり、当該プロパティに関する一連のRDFトリプル群であり、対応するURIが不変のプロパティそのものではありません。

一連の記述を区別するため、ファイル名やパス名にバージョン番号を示す文字列や日付文字列を使うことが一般的に行われています。例えば、1.01.rdfや2005-10-31.rdf、http://dublincore.org/2008/01/14/dcelements.rdf#titleです。ただ、現時点では、日付やバージョン番号の文字列をこのように使う一般的に受け入れられた慣例はありません。

謝辞

ここで扱う例の数々は、現在デプロイされているセマンティックウェブの語彙、特に、Dublin Core Metadata Terms、Friend of a Friend Ontology、そしてSKOS Core Vocabularyにおけるグッドプラクティスの要素を抽出した試みです。これらのプラクティスの開発に貢献したす​​べての人に深く感謝します。

参考文献

BibTeX | BibTeXML | RDF

APACHE20

Apache HTTP Server Version 2.0 Documentation , The Apache Software Foundation.
Available at http://httpd.apache.org/docs/2.0/

AWWW04

Architecture of the World Wide Web, Volume One , Ian Jacobs and Norman Walsh, World Wide Web Consortium, W3C Recommendation, December 2004.
Available at http://www.w3.org/TR/2004/REC-webarch-20041215/

COOLURI

Cool URIs for the Semantic Web , Leo Sauermann, DFKI GmbH; Richard Cyganiak, Freie Universität Berlin. W3C Interest Group Note March 2008
Available at http://www.w3.org/TR/cooluris/

FOAF

FOAF Vocabulary Specification , Dan Brickley and Libby Miller.
Available at http://xmlns.com/foaf/0.1/

GRDDL

Gleaning Resource Descriptions from Dialects of Languages (GRDDL) , Dan Connolly, World Wide Web Consortium, W3C Recommendation September 2007
Available at http://www.w3.org/TR/grddl/

HTTPRANGE14

Dereferencing HTTP URIs , Rhys Lewis, Volantis Systems Ltd.
Available at http://www.w3.org/2001/tag/doc/httpRange-14/2007-10-04/HttpRange-14.html

W3C Technical Architecture Group's resolution on the range of HTTP dereferencing (aka "httpRange-14").
Available at http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html

OWLFeatures

OWL Web Ontology Language Overview , Deborah L. McGuinness and Frank van Harmelen, World Wide Web Consortium, W3C Recommendation, February 2004.
Available at http://www.w3.org/TR/2004/REC-owl-features-20040210/

OWLGuide

OWL Web Ontology Language Guide , Michael K. Smith, Chris Welty and Deborah L. McGuinness, World Wide Web Consortium, W3C Recommendation, February 2004.
Available at http://www.w3.org/TR/2004/REC-owl-guide-20040210/

PURL

Introduction to Persistent Uniform Resource Locators , Keith Shafer, Stuart Weibel, Erik Jul and Jon Fausey, 6565 Frantz Road, Dublin, Ohio 43017-3395: OCLC Online Computer Library Center, Inc., 1996.
Available at http://purl.oclc.org/docs/inet96.html

RDFa

RDFa in XHTML: Syntax and Processing , B. Adida, M. Birbeck, S. McCarron, S. Pemberton, World Wide Web Consortium, W3C Candidate Recommendation June 2008
Available at http://www.w3.org/TR/2008/CR-rdfa-syntax-20080620/

RDFPrimer

RDF Primer , Frank Manola and Eric Miller, World Wide Web Consortium, W3C Recommendation, February 2004.
Available at http://www.w3.org/TR/2004/REC-rdf-primer-20040210/

RDFS

RDF Vocabulary Description Language 1.0: RDF Schema , Dan Brickley and R. V. Guha, World Wide Web Consortium, W3C Recommendation, February 2004.
Available at http://www.w3.org/TR/2004/REC-rdf-schema-20040210/

RFC2616

Hypertext Transfer Protocol - HTTP/1.1 , R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee, Internet Engineering Task Force, RFC (2616), June 1999.
Available at http://www.ietf.org/rfc/rfc2616.txt

RFC3986

Uniform Resource Identifier (URI): Generic Syntax , T. Berners-Lee, R. Fielding and L. Masinter, Internet Engineering Task Force, RFC (3986), January 2005.
Available at http://www.ietf.org/rfc/rfc3986.txt

SKOS

SKOS Core Vocabulary Specification , Alistair Miles and Dan Brickley, World Wide Web Consortium, W3C Working Draft, November 2005.
Available at http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20051102/

XMLNAMES

Namespaces in XML , Tim Bray, Dave Hollander and Andrew Layman, World Wide Web Consortium, W3C Recommendation, January 1999.
Available at http://www.w3.org/TR/1999/REC-xml-names-19990114/

付録A：命名用にPURLを使う語彙

PURL（Persistent URL）はhttp://purl.org/ URI空間のURIです。PURLは、PURL解決サービスによってサポートされており、これによりPURLドメインの登録所有者はPURLに対するHTTPリクエストを任意のリソースURLにリダイレクトさせることができます。PURLの登録所有者は、各PURLのリダイレクトURLを指定することは出来ますが、PURLサーバーを設定することは出来ません。

PURLの中央サーバーが1990年代に開発されたときには、PURLへのリクエストに対するHTTPサーバーの標準的な応答は302コード（「一時的な移動」）を返すことでした。その後ウェブアーキテクチャは進化し、W3Cの技術アーキテクチャグループ（TAG）は、RDFクラスとプロパティ名に対するリダイレクトのために、応答コードとして303（「他を参照」）を返すべきであると決めました。 詳細はhttpRange-14[HTTPRANGE14]についてのTAG決議を参照してください。

PURLサーバーが302応答コードを使用しているため、303応答コードを返すような設定が出来ず、http://purl.orgスラッシュ名前空間サーバーを持つ既存語彙は現在のTAG勧告に厳密には準拠していません。これらの例は、以下のレシピで取り上げています。

注：本ワーキングドラフトの執筆時点である2008年1月において、PURLサービスのアップデートが進行中です。我々は、このアップデートがhttpRange-14と303リダイレクトについてのTAG判断に対応すると予想しています。 （http://www.oclc.org/news/releases/200669.htmを参照）。

レシピ1a | レシピ2a | レシピ3a | レシピ4a | レシピ5a

レシピ1a．PURL「ハッシュ名前空間」の最小設定

このレシピはhttp://purl.org/URIスペース内のハッシュ名前空間をもつ語彙に対する最小要件を満たす設定例です。機械処理可能（RDF）コンテンツのみが当該名前空間URIで提供されています。

語彙...

http://purl.oclc.org/NET/SWD/recipes/examples-A/example1a

クラス定義...

http://purl.oclc.org/NET/SWD/recipes/examples-A/example1a#ClassA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example1a#ClassB

プロパティ...

http://purl.oclc.org/NET/SWD/recipes/examples-A/example1a#propA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example1a#propB

ステップ1

RDF/XML形式にした語彙全体を含むexample1a.rdfというファイルを作成します。すなわち語彙で定義されるすべてのリソースは、このファイルに記述されています。

ステップ2

example1a.rdfをサーバー上のディレクトリ/apachedocumentroot/examples/にコピーします。サーバーはコンテンツを提供するもので、この例ではwww.w3.orgになります。

ステップ3

次のPURLを設定します。

PURL: http://purl.org/NET/SWD/recipes/examples-A/example1a
URL:  http://www.w3.org/2006/07/SWD/recipes/examples/example1a.rdf 

注意点

サーバーが既にコンテントタイプapplication/rdf+xmlとして.rdf拡張子を持つファイルを処理するように設定されているなら何もする必要はありません。そうではない場合は、次のディレクティブを追加する必要があります。

AddType application/rdf+xml .rdf

Apacheのメインの設定ファイルか、あるいはそれへのアクセスが認められていない場合は、サーバー上のディレクトリ /apachedocumentroot/examples/を対象としたディレクトリ単位の設定ファイルである(.htaccess)に追加します。

レシピ2a．PURL「スラッシュ名前空間」の最小設定

このレシピは、http://purl.org/URI空間にあるスラッシュ名前空間をもつ語彙に対する最小要件を満たす設定例になります。機械処理可能（RDF）コンテンツのみが当該名前空間URIで提供されています。

注：本ワーキングドラフトの執筆時点で、この例は、httpRange-14[HTTPRANGE-14]についてのTAG決議に厳密には従いません。なぜなら、purl.orgサーバーは、303リダイレクトコードではなく、302を使用しているためです。

語彙...

http://purl.oclc.org/NET/SWD/recipes/examples-A/example2a/

クラス定義...

http://purl.oclc.org/NET/SWD/recipes/examples-A/example2a/ClassA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example2a/ClassB

プロパティ...

http://purl.oclc.org/NET/SWD/recipes/examples-A/example2a/propA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example2a/propB

ステップ1

RDF/XML形式にした語彙全体を含むexample2a.rdfというファイルを生成します。すなわち語彙で定義されるすべてのリソースは、このファイルに記述されています。

ステップ2

example2a.rdfをサーバー上のディレクトリ/apachedocumentroot/examples/にコピーします。サーバーはコンテンツを提供するもので、この例ではwww.w3.orgになります。

ステップ3

以下のような部分​​リダイレクトPURLを設定します。

PR PURL: http://purl.oclc.org/NET/SWD/recipes/examples-A/example2a/
Root URL:  http://www.w3.org/2006/07/SWD/recipes/examples/example2a/ 

ステップ4

サーバー上の/apachedocumentroot/examples/ディレクトリにある.htaccessファイルに次のディレクティブを追加します。

# Turn off MultiViews
Options -MultiViews

# Directive to ensure *.rdf files served as appropriate content type,
# if not present in main apache config
AddType application/rdf+xml .rdf

# Rewrite engine setup
RewriteEngine On
RewriteBase /examples

# Rewrite rule to serve RDF/XML content from all partially redirected URIs
RewriteRule ^example2a/ example2a.rdf

（注：.htaccessファイルが無い場合は作成します。）

注意点

上記のレシピにおいて、単一の書き換えルールは内部リダイレクトです。これは参照解決時に行われる外部（つまり、HTTP）リダイレクトの数を最小限に抑えます。しかし、次のように上記のルールを置き換えることにより、外部リダイレクトとしてこの書き換えルールを実装することも出来ます。

# Rewrite rule to serve RDF/XML content from all partially redirected URIs
RewriteRule ^example2a/ example2a.rdf [R=303]

このルールでは参照解決時に更なるHTTPリダイレクトを伴いますが、クライアントには、語彙やクラス、プロパティのURIが全て同じ場所であることが恐らく明白であり、現在のPURL実装をTAG httpRange-14決議[HTTPRANGE14]に従うように仕向けます。

また、語彙の各クラスやプロパティに対する個々のPURLを生成し、部分リダイレクトPURLではなく、それら全て同一のURLを参照することでサーバーの設定を回避することもできます。しかし、コンテンツがその後に移動するなら、個々のPURLは更新が必要になります。これは、つまり中規模から大規模なオントロジーに対しては煩雑で非実用的な作業となります。

レシピ3a．PURL「ハッシュ名前空間」の拡張設定

このレシピは、http://purl.org/URI空間内のハッシュ名前空間をもつ語彙に対する拡張要件を満たす設定例になります。機械処理可能（RDF）および人可読（HTML）双方のコンテンツが当該名前空間URIで提供されます。

語彙...

http://purl.oclc.org/NET/SWD/recipes/examples-A/example3a

クラス定義...

http://purl.oclc.org/NET/SWD/recipes/examples-A/example3a#ClassA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example3a#ClassB

プロパティ...

http://purl.oclc.org/NET/SWD/recipes/examples-A/example3a#propA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example3a#propB

ステップ1

2005年10月31日時点の（または現在の日付であれば何でも）、RDF/XML形式にした語彙全体を含む2005-10-31.rdfというファイルを作成します。すなわち語彙で定義されるすべてのリソースは、このファイルに記述されており、このファイルは語彙の「スナップショット」や「バージョン」を表します。

ステップ2

2005年10月31日時点の（または現在の日付であれば何でも）語彙で定義されたすべてのクラスとプロパティについてHTMLコンテンツ文書を含む2005-10-31.htmlというファイルを作成します。このHTML文書には、個々のクラスやプロパティに関する文書が記述されたセクションを含めることができ、各セクションは、当該クラスやプロパティのフラグメント識別子と同一の名前のHTMLアンカーで始まります。

ステップ3

2005-10-31.rdfと2005-10-31.htmlをサーバー上のディレクトリ /apachedocumentroot/examples/example3a-content/にコピーします。サーバーはコンテンツを提供するもので、この例ではwww.w3.orgになります。

ステップ4

/apachedocumentroot/examples/ディレクトリにある.htaccessファイルに次のディレクティブを追加します。

# Turn off MultiViews
Options -MultiViews

# Directive to ensure *.rdf files served as appropriate content type,
# if not present in main apache config
AddType application/rdf+xml .rdf

# Rewrite engine setup
RewriteEngine On
RewriteBase /examples

# Rewrite rule to make sure we serve HTML content from the namespace URI if requested
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example3a$ example3a-content/2005-10-31.html [R=303]

# Rewrite rule to make sure we serve the RDF/XML content from the namespace URI by default
RewriteRule ^example3a$ example3a-content/2005-10-31.rdf [R=303]

ステップ5

以下のPURLをセットアップします：

PURL: http://purl.oclc.org/NET/SWD/recipes/examples-A/example3a
URL:  http://www.w3.org/2006/07/SWD/recipes/examples/example3a

注意点

コンテントネゴシエーションのためにPURLサーバーを設定することは出来ないので、この例ではPURLサーバーから302リダイレクトが行われた後にコンテンツサーバーがネゴシエーションを行うように設定しています。

レシピ4a．単一HTMLドキュメントのPURL「スラッシュ名前空間」の拡張設定

このレシピは、http://purl.org/URI空間内のスラッシュ名前空間をもつ語彙に対する拡張要件を満たす設定例になります。機械処理可能（RDF）および人可読（HTML）双方のコンテンツが、当該名前空間URIで提供されます。 HTML文書は単一のファイルとして提供されます。

注：この例は、httpRange-14[HTTPRANGE-14]についてのTAG決議に厳密には従いません。なぜなら、purl.orgサーバーは、303リダイレクトコードではなく、302を使用しているためです。

語彙...

http://purl.oclc.org/NET/SWD/recipes/examples-A/example4a/

クラス定義...

http://purl.oclc.org/NET/SWD/recipes/examples-A/example4a/ClassA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example4a/ClassB

プロパティ...

http://purl.oclc.org/NET/SWD/recipes/examples-A/example4a/propA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example4a/propB

ステップ1

2005年10月31日時点の（または現在の日付であれば何でも）、RDF/XML形式にした語彙全体を含む2005-10-31.rdfというファイルを作成します。すなわち語彙で定義されるすべてのリソースは、このファイルに記述されており、このファイルは語彙の「スナップショット」や「バージョン」を表しています。

ステップ2

2005年10月31日時点の（または現在の日付であれば何でも）語彙で定義されたすべてのクラスとプロパティに関するHTMLコンテンツ文書が含まれる2005-10-31.htmlというファイルを作成します。このHTML文書には、個々のクラスやプロパティに関する文書が記述されたセクションを含めることができ、各セクションは、当該クラスやプロパティのフラグメント識別子と同一の名前のHTMLアンカーで始まります。

ステップ3

2005-10-31.rdfと2005-10-31.htmlをサーバー上のディレクトリ/apachedocumentroot/examples/example4a-content/にコピーします。サーバーはコンテンツを提供するもので、この例ではwww.w3.orgになります。

ステップ4

/apachedocumentroot/examples/ディレクトリにある.htaccessファイルに次のディレクティブを追加します。

# Turn off MultiViews
Options -MultiViews

# Directive to ensure *.rdf files served as appropriate content type,
# if not present in main apache config
AddType application/rdf+xml .rdf

# Rewrite engine setup
RewriteEngine On
RewriteBase /examples

# Rewrite rule to serve HTML content from the namespace URI if requested
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example4a/$ example4a-content/2005-10-31.html [R=303]

# Rewrite rule to serve directed HTML content from class/prop URIs
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example4a/(.+) example4a-content/2005-10-31.html#$1 [R=303,NE]

# Rewrite rule to serve RDF/XML content from the namespace URI by default
RewriteRule ^example4a/ example4a-content/2005-10-31.rdf [R=303]

（注：.htaccessファイルが無い場合は作成します。）

ステップ5

以下のような部分​​リダイレクトPURLを設定します。

PR PURL: http://purl.oclc.org/NET/SWD/recipes/examples-A/example4a/
URL Root:  http://www.w3.org/2006/07/SWD/recipes/examples/example4a/

注意点

この設定は、ダブリンコアメタデータ規約向けに最も適しているでしょう。

レシピ5a．複数のHTML文書を使用したPURL「スラッシュ名前空間」の拡張設定

本レシピは、http://purl.org/URI空間にある、スラッシュ名前空間をもつ語彙に対する拡張設定を満たす設定例になります。機械処理可能（RDF）と人可読（HTML）コンテンツの双方を当該名前空間URIで提供するもので、HTML文書については複数のリンクで結ばれた文書と一つの概要文書からなります。

注：この例は、httpRange-14[HTTPRANGE14]についてのTAG決議に厳密には従いません。なぜなら、purl.orgサーバーは、303リダイレクトコードではなく、302を使用しているためです。

語彙...

http://purl.oclc.org/NET/SWD/recipes/examples-A/example5a/

クラス定義...

http://purl.oclc.org/NET/SWD/recipes/examples-A/example5a/ClassA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example5a/ClassB

プロパティ...

http://purl.oclc.org/NET/SWD/recipes/examples-A/example5a/propA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example5a/propB

ステップ1

2005年10月31日時点の（または現在の日付であれば何でも）、RDF/XML形式にした語彙全体を含む2005-10-31.rdfというファイルを作成します。すなわち語彙で定義されるすべてのリソースは、このファイルに記述されており、このファイルは語彙の「スナップショット」や「バージョン」を表します。

ステップ2

2005-10-31.rdfをサーバー上のディレクトリ/apachedocumentroot/examples/example5a-content/にコピーします。 サーバーはコンテンツを提供するもので、この例ではwww.w3.orgになります。

ステップ3

ClassA.html、ClassB.html、propA.html、propB.htmlを生成します。それぞれ、2005年10月31日時点（あるいは現在の日付であれば何でも）の対応するローカル名を持つクラスまたはプロパティに関連するHTMLコンテンツ文書が含まれています。すべてのクラスやプロパティのドキュメントへのハイパーリンクを含む、語彙自体に関するHTMLコンテンツを含むindex.htmlファイルを作成します。

ステップ4

ClassA.html、ClassB.html、propA.html、propB.html、およびindex.htmlをサーバー上のディレクトリ/apachedocumentroot/examples/example5a-content/2005-10-31-docs/にコピーします。サーバーはコンテンツを提供するもので、この例ではwww.w3.orgです。

ステップ5

/apachedocumentroot/examples/ディレクトリにある.htaccessファイルに次のディレクティブを追加します。

# Turn off MultiViews
Options -MultiViews

# Directive to ensure *.rdf files served as appropriate content type,
# if not present in main apache config
AddType application/rdf+xml .rdf

# Rewrite engine setup
RewriteEngine On
RewriteBase /examples

# Rewrite rule to serve HTML content from the namespace URI if requested
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example5a/$ example5a-content/2005-10-31-docs/index.html [R=303]

# Rewrite rule to serve HTML content from class or prop URIs if requested
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example5a/(.+) example5a-content/2005-10-31-docs/$1.html [R=303]

# Rewrite rule to serve RDF/XML content from the namespace URI by default
RewriteRule ^example5a/ example5a-content/2005-10-31.rdf [R=303]

（注：.htaccessファイルが無い場合は作成します。）

ステップ6

以下のような部分​​リダイレクトPURLを設定します。

PR PURL: http://purl.oclc.org/NET/SWD/recipes/examples-A/example5a/
Root URL:  http://www.w3.org/2006/07/SWD/recipes/examples/example5a/

付録B：URI名前空間

ある語彙を特定するURIをここでは語彙名前空間URIもしくは単に語彙URI（ここでは語彙とオントロジーは同義なので、オントロジーURIとも）と呼びます。たとえば、次のURIは、SKOSコア語彙を特定します。

http://www.w3.org/2004/02/skos/core

...そして次のURIはFOAFオントロジーを特定します。

http://xmlns.com/foaf/0.1/

「ハッシュ名前空間」を使う語彙

SKOSコア[SKOS]はハッシュ名前空間を利用する語彙の例です。これは、非公式な表現で、語彙のクラスとプロパティのURIがどのように構築されるかを示しています。この場合、クラスやプロパティのためのURIは、語彙URIの後にハッシュ文字（'＃'）が続き、そして「ローカル名」を付加することによって構築されています。「ローカル名」は語彙のスコープ内で一意にクラスやプロパティを特定する文字列であり、「フラグメント識別子」としても知られています。[AWWW04]（ローカル名は[XML-NS]トークンNCNameでなくてはなりません）。

たとえば、次のURIはSKOSコア語彙のクラスとプロパティを特定します。

http://www.w3.org/2004/02/skos/core#Concept
http://www.w3.org/2004/02/skos/core#prefLabel

「スラッシュ名前空間」を使う語彙

FOAF[FOAF]はスラッシュ名前空間を使用する語彙の例です。ハッシュ名前空間と同じく、これは語彙で定義されたクラスやプロパティのURIが構築される方法を参照する非公式の表現です。この場合、語彙URIはスラッシュ文字（'/'）で終わり、クラスやプロパティのURIは語彙URIにクラスまたはプロパティの「ローカル名」を直接付加することにより構築されています。ここでも、「ローカル名」は語彙のスコープ内でそのクラスやプロパティを一意に特定し、そして[XML-NS]トークンNCNameでなくてはなりません。

たとえば、次のURIは、FOAFの語彙のクラスやプロパティを特定します。

http://xmlns.com/foaf/0.1/Person
http://xmlns.com/foaf/0.1/maker

URIがスラッシュで終わる語彙が必ずしもスラッシュ名前空間を使うとは限らないことに注意してください。そしてハッシュ名前空間の場合もあり得ます。例えば、語彙http://example.org/myvocabulary/はクラスhttp://example.org/myvocabulary/#Fooやhttp://example.org/myvocabulary/#Barを定義できます。

ハッシュ名前空間とスラッシュ名前空間の双方ともウェブアーキテクチャでサポートされていますが、これらの選択肢の違いに応じた特定の振舞いがウェブサーバーには要求されます。サーバーが受信するリクエストおよびサーバーが返すレスポンスの双方がそれぞれの名前空間の場合で異なるので、上記の要件の一部または全てを満たすために必要なHTTPサーバーの構築方法も異なります。従って両者はそれぞれ別々に扱われます。

他のタイプの名前空間の使う語彙

執筆時点で検討中の第三のタイプの語彙URI、すなわち、http://thing-described-by.orgのような303リダイレクトサービスに基づいたURIについて留意してください。303リダイレクトのアプローチは本文書で説明しているアプローチよりも簡単に実装できるものの、まだ安定して公開されているRDF語彙がないため、本文書のレシピでは利用していません。付録Cでこのアプローチをより詳しく説明しています。

URI名前空間を選択する際の検討事項

この文書は、既存語彙の作成者とメンテナのために意図されています。従い、いかなる場面においても最良のURI名前空間を選択するための適切な助言を行うということは本文書の範囲を超えています。とはいえ、本文書のレシピは、機能性に関する想定をしたうえで特質評価を行っているので、URI名前空間の選択における検討事項の幾つかは本セクションで扱っています。なお、既にURI名前空間の選択をしている場合には、レシピの選択に進んでください。

自身の管理する語彙のために選択しようとしているURI名前空間は書き込み権限のあるウェブアドレス（URI）である必要があり、語彙の利用者は当該語彙のURIそのものと、当該語彙で定義されているプロパティやクラスのURIの双方について参照解決可能であると期待しています。ですから、URI名前空間を選択することは、語彙設計の早期における大切な決定事項になります。

RDFの仕様としては妥当なURIスキームであればどれでも名前空間の冒頭部分に使うことができますが、セマンティックウェブのベストプラクティスとしては、プラグインの追加や追加設定をすることなく、いかなるクライアントでも解決可能なURIスキームを使います。そのなかで、http URIスキームが最もよく知られた存在であり、かつ、全てのウェブクライアントに解決されます。このことから、本文書ではhttp:から始まる名前空間を持つ語彙のみに焦点を当てています。

ベストプラクティスでは、すべてのRDF語彙がハッシュ名前空間またはスラッシュ名前空間を使うこととしています（上記参照）。どちらを選択するかは次の3点にある程度依存します。すなわち、どの程度対象語彙が大きくなるか、どの程度頻繁に新規語（すなわち、プロパティやクラス）を追加するか、そして、どの程度利用者が語彙中の個々の語に関する情報にアクセスするか、になります。

小規模な語彙であれば語彙全体を一度のウェブアクセスで提供するのが最も都合が良いでしょう。このような語彙はハッシュ名前空間を利用するのが一般的で、当該語彙中のいかなる語に対するウェブアクセス（すなわち、HTTP GETリクエスト）も、当該語彙の全ての語を記述する単一の情報リソースを返します。

追加が頻繁に行われると想定されたり、一般的なユーザーアプリケーションが一度のアクセスで取得可能なサイズよりも大きなデータを含んでいたりする語彙については、ウェブアクセスを繰り返すことで徐々に語彙中の語に関する詳細を得られるように調整するのが良いでしょう。全ての語に関する完全な記述は複数の情報リソースに分割するか、あるいは、クエリサービスを経由するのが良いかもしれません（例えば[SPARQL] -- レシピ6を参照）。このような語彙はスラッシュ名前空間を利用するのが一般的で、それは当該語彙中のどの語へのウェブアクセスも原則当該語についての情報のみを返すことが可能だからです。（HTTPプロトコルの仕組みから、ハッシュ名前空間を使うとこのような設定は出来ません。）

セマンティックウェブのためのURI設計に関する問題について詳細な議論は次の文書で行われています。

• 「セマンティックウェブのためのクールなURI」[COOLURI]
• TAG調査結果：「リソースに名前空間を関連づける」

付録C：303-リダイレクトサービスに基づく語彙のURI

このタイプのURIは、http://thing-described-by.orgのような303リダイレクトサービスのベースURIにクエリ文字列として記述リソースのURIを追加することによって形成されます。thing-described-by.orgドメインは、クエリ文字列（すなわち、疑問符に続く部分）に引用されたドメインに対して、それらのクエリURIの意味を定義する権限を委譲しています。

原理的には、Foo語彙向けの識別子として、URIhttp://thing-described-by.org?http://example.org/fooを生成できます。Foo語彙のためのURIまたはFoo語彙のプロパティやクラスに対するURIへのHTTP GETリクエストは303応答コードを返すので、本文書で記述しているRDF語彙の公開のための二件の最小要件の二件目に従うことになります。さらに、http://example.org/fooというURIが当該語彙に対する正式なRDF記述を識別するためにあり、そして当該記述を提供するサーバーがそれを適切に識別するMIMEタイプを返すならば、http://thing-described-by.org?http://example.org/fooを使うことで最小要件の一件目に従うことになります。

付録D：Apacheの設定

Apache HTTPサーバー[APACHE20]は、メインのApacheの設定ファイル（通常は「httpd.conf」など）内、またはディレクトリ単位の設定ファイル（通常は「.htaccess」）内のいずれかに書かれたディレクティブで設定されています。本文書に書かれているレシピは、読者がメインのApache設定ファイルへのアクセス権を持たないことを想定しており、必要なティレクティブをサーバーに与えるために、.htaccessファイルを使用し、ディレクトリ単位の設定を行わなくてはならない場面を想定しています。.htaccessファイルを利用するためのより詳しい情報はApache Tutorial: .htaccess filesで得られます。

もしもメインのApache設定ファイルへの書き込み権限がある場合は、直接そこに記述することを検討するのが良いでしょう。ディレクトリ単位の設定はサーバーのパフォーマンスに悪影響を及ぼしかねず、また、ディレクトリレベルでのセキュリティ設定により気を使う必要があるからです。Apache Tutorial: When (not) to use .htaccess filesを参照してください。なお、AllowOverrideはディレクトリレベルのディレクティブであり、そのパフォーマンスとセキュリティに関する副作用は通常、それが有効であるディレクトリツリーを越えないことに留意すべきです。

注意：ここでの設定では、Apache HTTPサーバーのバージョン2.0.46でのみテストされています。

サーバー設定

ディレクトリ毎の設定ファイルを利用できるように、サーバーは、使用しているディレクトリに対するoverrideを許可するよう設定する必要があります。必要なoverrideは次のとおりです。

AllowOverride FileInfo Options

また、利用しているApacheがmod_rewriteモジュールを含めてコンパイルされているか、またはmod_rewrite動的共有オブジェクト（DSO）がインストールされていることを確認してください。そして、次の2行がApacheの設定ファイルに含まれます。

AddModule mod_rewrite.c
LoadModule rewrite_module modules/mod_rewrite.so

レシピの動作に問題がある場合、必要なoverrideディレクティブがメインのApacheの設定ファイルで指定されていないか、mod_rewriteを利用できないことが原因の可能性があります。

.htaccessが妥当であることをテストします

サーバーが指定されたディレクトリにある.htaccessファイルを正しく解析するかテストするには、ウェブブラウザにテストしたいディレクトリ内のファイルにアクセスするURLを与え、正しく配信されていることを確認します。続いて、次に示す行を含むように当該ディレクトリ内の.htaccessファイルを生成または編集します。

InvalidDirective Here

ウェブブラウザで当該URLをリロードします。サーバーが当該ディレクトリの.htaccessファイルを解析している場合、サーバーは解析できないInvalidDirectiveにより生成された「内部サーバーエラー」ページを返すはずです。通常通りにページが再表示された場合はレシピで使うことになるディレクトリで.htaccessファイルが有効になるようシステム管理者に依頼する必要があります。サーバーが.htaccessファイルを解析していると確認がとれたときには、当該.htaccessファイルからInvalidDirective行を削除するのを忘れないでください。

mod_rewriteがインストールされていることをテストします

mod_rewriteがインストールされていることをテストするには、最初のテストにおけるInvalidDirective行を次のものに置き換えます。

RewriteEngine On

そしてウェブブラウザで当該URLをリロードします。mod_rewriteがインストールされていないか、または.htaccessのあるディレクトリにおいて、それを有効にするのに十分なoverride権限を持っていない場合、サーバは「内部サーバーエラー」ページを返すはずです。.htaccessファイルにおいてmod_rewriteを有効にするには、AllowOverrideディレクティブがFileInfo（もしくはAll）と設定されていなければなりません。

RDF/XMLコンテントタイプを設定します

RFC3870で定義されているように、RDF/XMLコンテンツを提供するための適切なコンテントタイプは、「application/rdf+xml」です。ファイルの拡張子「.rdf」を認識し、適切なコンテントタイプで提供できるようにApacheサーバーを設定可能で、.htaccessファイルに以下の様に記述します。

AddType application/rdf+xml .rdf

このディレクティブは、サーバー設定ファイルにおいてサーバーレベルでグローバルに適用できます。その場合は問題なくレシピから除去することができます。

書き換えルールに対する代替手段

本文書で説明されている設定例では書き換え規則（mod_rewrite）を用いて、コンテントネゴシエーションを、クライアントからのリクエストを最も適した表現が返されるURLにリダイレクトする方法で実装しています。この仕組みは簡単でありながらHTMLおよびRDF/XML文書の所在について大きな柔軟性を持たせることが出来ます。それらの文書は異なるサーバー上にあっても良いのです。

ここでの設定例ではコンテントネゴシエーションを適切に処理出来ない場合があります。特に、q値を含む「Accept:」ヘッダーのあるリクエストは書き換え規則で解析できず、サーバーが想定外の表現方法を返すかもしれません。このような要求を処理できるようにApacheサーバーを設定することは恐らく可能ですが、.htaccessファイルの制限内ではこの設定がうまく働きません。これらのリクエストを処理する完全なサーバー設定例を提供することは本文書の範囲を逸脱しています。興味をお持ちの方はApacheの型マップとコンテントネゴシエーションを参照してください。