要約

このドキュメントは、リンクト・データ・プラットフォーム[LDP]のサーバーとクライアントを実装するためのベスト・プラクティスとガイドラインを提供します。

このドキュメントのステータス

この項は、このドキュメントの公開時のステータスについて記述しています。他のドキュメントがこのドキュメントに取って代わることがありえます。現行のW3Cの刊行物およびこの技術報告の最新の改訂版のリストは、http://www.w3.org/TR/のW3C技術報告インデックスにあります。

このドキュメントは、リンクト・データ・プラットフォーム・ワーキンググループによってワーキンググループ・ノートとして発表されました。このドキュメントに関してコメントを行いたい場合には、public-ldp@w3.org（購読、アーカイブ）にお送りください。どのようなコメントでも歓迎します。

ワーキンググループ・ノートとしての公開は、W3Cメンバーによる承認を意味するものではありません。これは草案ドキュメントであるため、他のドキュメントによって、随時更新されたり、置き換えられたり、廃止されることもありえます。このドキュメントを「作業中」以外のものとして引用することは適当ではありません。

このドキュメントは、2004年2月5日のW3C特許方針の下で活動しているグループによって作成されました。W3Cは、このグループの成果物に関連するあらゆる特許の開示の公開リストを維持し、このページには特許の開示に関する指示も含まれています。不可欠な請求権（Essential Claim(s)）を含んでいると思われる特許に関して実際に知っている人は、W3C特許方針の6項に従って情報を開示しなければなりません。

目次

1. このドキュメントについて

1.1 きっかけ

リンクト・データ・プラットフォーム仕様の執筆中に、著者と貢献者は、共通する慣習や、得られた貴重な教訓を共有しなければならないと感じました。しかし、同時に、不必要な制限を課したり、形式的な仕様を不必要に冗長にしたくないと考えました。したがって、このドキュメントは、LDP入門[LDP-PRIMER]とともに、補足的なコンテキストを提供するために開発されました。これは、この著者と貢献者のプロフェッショナルな経験、関連技術の豊富な歴史に関する調査、一般的なコミュニティーからの継続的なフィードバックを用いて、システムの実装者が、共通の落とし穴を回避し、質を改善し、他のリンクト・データ・システムとの相互運用性を向上できるように支援することを目指します。

1.2 用語

このドキュメントの目的に合わせて、「ベスト・プラクティス」という用語と「ガイドライン」という用語の、小さいながらも重要な違いを明確にすることは有用です。このドキュメントでは、これらの用語を次の通り定義し区別します。

ベスト・プラクティス
他の手段によるよりも常に優れた結果を示し、ベンチマークとして用いられる実装上の慣習（方法または技術）。このドキュメントのベスト・プラクティスは特に、LDPサーバーとクライアントを実装する方法と、それらにおいてある資源を準備し使用する方法に適用されます。このドキュメントでは、ベスト・プラクティスは、実装者がシステムの設計とコードを直接評価できる、一種のチェック・リストとして使用できるかもしれません。しかし、特定のベスト・プラクティスを順守しないことは、必ずしも品質の欠如を意味しません。これらは、ほとんどのケースやコンテキストで「ベスト」と言える推奨ですが、すべてのケースやコンテキストに当てはまるわけではありません。ベスト・プラクティスは、ウェブに関する知識の向上や発展にしたがって、常に改善すべきです。
ガイドライン
ヒント、要領、注記、提案やFAQに対する回答。このドキュメントのガイドラインでは、実装者の知識と理解を向上させることができる情報であるものの、実装には直接適用でなかったり、「ベスト・プラクティス」であるとの合意を得られない可能性のある有用な情報も提供します。

このドキュメントで用いている用語およびリンクト・データの知識の範囲に関する様々な用語の定義に関しては、リンクト・データ・プラットフォーム1.0[LDP]の用語の項およびリンクト・データ用語集[LD-GLOSSARY]を参照してください。

1.3 条件および前提

実装者は、少なくともこのドキュメントで引用している参考情報の参考文献（特に次のもの）に関する一般的な知識を有しているべきです。

2. ベスト・プラクティス

2.1 述語URIはHTTP URLにすべき

URIは資源を一意に識別するために用い、URLはウェブ上の資源の位置を示すために用います。つまり、URLは実際の資源に対して解決され、それをホストから検索できると予想されます。他方で、URIはURLでもありえますが、そうでなければならないわけではなく、検索可能な表現を持たないものを参照することもできます。

リンクト・データの背後にある基本的な考えの1つは、HTTP URIで参照される事物は実際に検索（「逆参照」）できるというものです。この重要な原理は、リンク用データ[LD-DI]の「4原則」の2番目の法則としてTim Berners-Leeが最初に概要を示しました。したがって、述語URIが資源を検索可能な表現で識別することが理想的です。LDPサーバーは、可能なときには、少なくともこの述語の[RDF-SCHEMA]表現を提供すべきです。

もちろん、公表されているオープンな語彙のプロパティーを再使用することも一般的な慣習です。このケースでは、実装者は、URIの逆参照を試みる際に、結果をコントロールできません。そのため、自身の語彙をデータのリンクに役立てたいと考える公開者は、その語彙が規定するプロパティーを検索可能な表現で提供するよう努めるべきです。その結果、リンク用データに対する語彙使用の有効性を判断するためのベンチマークとして実装者がこの慣習を用いることも期待できます。

2.2 概念の型をLDPRで表現するために述語rdf:typeを使用・導入すること

LDPが提供する相互作用機能の使用は必須ではありませんが、LDPRの型（クラス）を知っていることはとても有用な場合が多いです。さらに、最も大きな文脈でデータをより役立つようにするためには、[RDF-SCHEMA]で定義されているrdf:typeという述語を用いて、型を明示的に定義すべきです。

これにより、クライアントは、追加処理を行なったり、HTTP要求を追加する必要なく、資源の型を容易に決定できます。例えば、推論をサポートしていないために型の推論を行えないクライアントにとって、この明示的な宣言は有用です。

例1: rdf:typeの明示的な宣言によるLDPRの表現
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix contact: <http://www.w3.org/2000/10/swap/pim/contact#>.

<http://www.w3.org/People/EM/contact#me> 
  a contact:Person;
  contact:fullName "Eric Miller";
  contact:mailbox <mailto:em@w3.org>;
  contact:personalTitle "Dr.".

Turtleトリプルの述語の位置にある「a」というトークンは、http://www.w3.org/1999/02/22-rdf-syntax-ns#typeというIRIを表します。したがって、上記の例では、a contact:Personはrdf:type contact:Personや、<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> contact:Personという完全修飾形式と同じです。

2.3 相対URIを用いること

相対URIは、従来のウェブ・システムにおいて相対URL[RFC3986]が有用であったのとほぼ同じく、リンクト・データ・プラットフォームでも有用です。リンクト・データURIで参照する事物は、検索可能な表現[LD-DI]を提供すべきであるため、リンクト・データのURIも通常はURLです。つまり、識別するだけではなく、位置を示します。そのため、相対URLの実用的な価値はここにも当てはまります（特に、LDPコンテナ・モデルでは階層表現が奨励されるため）。

したがって、可能かつ適切な場合には、実装者は、LDPの相対URIの機能を、従来の相対URLのものに合わせるべきです。それによって、開発者にとって親しみやすいという快適性や利便性のみでなく、同じ利点の多くを得ることができます。

相対URIは、絶対URIより短い。

多くの場合、これにより、人間がコードとRDFを読むことが容易になるため、開発に役立ちます。さらに、これは、ペイロードの大きさも縮小できます。そして、それにより、エンドユーザに対する応答時間を改善しつつ、サーバーのネットワーク・トラフィックとストレスを縮小できます。

例2: 絶対URIによるhttp://example.org/container1/の表現
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.

<http://example.org/container1/>
   a a ldp:Container, ldp:BasicContainer;
   dcterms:title "A very simple container";
   ldp:contains
      <http://example.org/container1/member1>,
      <http://example.org/container1/member2>,
      <http://example.org/container1/member3>.
例3: 相対URIによるhttp://example.org/container1/の表現
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.

<> a a ldp:Container, ldp:BasicContainer;
   dcterms:title "A very simple container";
   ldp:contains <member1>, <member2>, <member3> .
相対URIは資源をよりポータブルにできる。
基底資源の検索の文脈から既に分かっている情報が省かれていれば、その位置が変わっても、修正すべき情報は少ない可能性があります。これにより、新しいサーバーや包含階層内の新しい位置に資源をコピーすることが容易になります。前の例の場合、コンテナのみをコピーするプロセスにおいて、そのメンバーのURIを調節する必要はありません。
相対URIは開発中に便利です。
開発中には、URIのスキームやネットワークの位置情報は不明かもしれないし、変更される可能性もあります。例えば、よく使用される「localhost」は、サーバー名やドメイン名のほうがうまく表現できます。多くの場合、開発者は、この情報を省略するほうがトラブルが少ないでしょう。さらに、相対URIが暗示する階層は、サーバーのファイル・システム内で模倣でき、それにより、サーバーが稼働していないときでも、開発者が情報を入手して利用できるようになります。
相対URIは任意の機械生成されたURIをサポートする。
RESTfulなURLは、階層的な「コレクション」（collection）のパターンで定義されることが多く、クライアントは非常に論理的な方法でそれと相互作用を行います。例えば、新しい資源を作成する際には、一般的に、クライアントはコレクションのURLに対してPOSTが成功するまで資源の名前を知りません。例えば、/people/に対するPOSTにより、/people/1という資源が作成されるかもしれません。LDPコンテナは、そのURIが同じモデルの恩恵を受けることができるようなコレクションで、これは、一部の実装では実際に極めて重要でありえます。

2.4 POSTedコンテンツのURIではドット・セグメントを避けるか注意して用いること

相対URI内のドット・セグメント（例えば、../）のセマンティクスは、他の仕様や過去の一般的な使い方によって暗示されているかもしれませんが、LDPの場合には、さらに考慮が必要です。

LDPの仕様では、次のとおりに記述されています。

LDPサーバーは、[RFC3987]の相対URI解決に対するデフォルトの基底URIを、資源が既に存在する場合にはHTTPリクエストURIとなるようにしなければならず、リクエストによって新しい資源が作成される場合には作成された資源のURIに割り当てなければなりません（MUST）。
この定義に基づくと、POST中に../やその他の空でない相対URI構成子を用いると、クライアントが予測できないような方法で、ポストされたコンテンツが資源を参照するようになります。したがって、実装および（または）展開に何が期待されるのかをクライアントが明確に分かっていない場合には、ドット・セグメントは避けるべきです。

2.5 階層的URIでコンテナ・メンバーシップを表すこと

階層的URIは、相対URIが使用可能となるため、コンテナに適しています。さらに、論理上子が親に属する親子関係を表すためにモデル化された資源との相互作用が容易になります。

そのようなモデルの1つの例は、OSLC（Open Service for Lifecycle Collaboration）コミュニティーが定義している語彙に含まれているoslc_cm:attachmentのケースに見ることができます。OSLCは、LDPと一致する仕様と語彙を定義しています。問題やバグの追跡システムなどのOSLCに準拠した変更管理システムの資源には、oslc_cm:attachmentコンテナで表現される付属物が含まれているかもしれません。このコンテナのURIは、次のように表されるかもしれません。

http://example.org/bugs/2314/attachments/

このURIから、付属物が含まれている親資源のURIを容易に見つけられます。他の兄弟資源用の基本コンテナは、上の階層に移動することで見つけられますが、そのことはURIで暗示されています。メタデータやバイナリ―のコンテンツは、次のようなURIを用いて、階層を下ると取得できるかもしれません。

http://example.org/bugs/2314/attachments/1

相対URIが使用可なことに加え、階層的URIは、基礎となるグラフの実際の構造を表すため、ユーザが資源を用いた相互作用をより容易に行えるようになります。ソフトウェア・エージェント（ユーザの代わりに動作するコード[WEBARCH]）は、URIの構造を利用する前に、実施時の過去の問題を考慮し、注意を払わなければなりません（[WEBARCH], [metaDataInURI]）。

2.6 コンテナURIにトレイリング・スラッシュを含むこと

階層的URLでコンテナ・メンバーシップを表す場合、コンテナのURIにトレイリング・スラッシュ（trailing slash）を含むことで、相対URIの使用がより簡単になります。例えば、次のコンテナURIについて考えてみましょう。

http://example.org/container1

この代わりに、次のURIを用いるほうが良いでしょう。

http://example.org/container1/

これの利点を説明するために、絶対URIを用いた次のコンテナから始めてみましょう。

例4: シンプルなコンテナ
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.

<http://example.org/container1>
   a a ldp:Container, ldp:BasicContainer;
   dcterms:title "A very simple container";
   ldp:contains
      <http://example.org/container1/member1>,
      <http://example.org/container1/member2>,
      <http://example.org/container1/member3>.

ここで、相対URIを用いて同じ資源を表したいとします。コンテナのURIにトレイリング・スラッシュが含まれていれば、次に示すとおり、非常に洗練された表現となります。

例5: コンテナURIがhttp://example.org/container1/
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.

<> a a ldp:Container, ldp:BasicContainer;
 dcterms:title "A very simple container";
 ldp:contains <member1>, <member2>, <member3> .

しかし、トレイリング・スラッシュを省略したと仮定した場合、HTTP GETが行われると、コンテナは上で示した表現を返します。これは、下記と同等のグラフを作成できるでしょう。

例6: コンテナURIはhttp://example.org/container1
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.

<http://example.org/container1>
   a a ldp:Container, ldp:BasicContainer;
   dcterms:title "A very simple container";
   ldp:contains
      <http://example.org/member1>,
      <http://example.org/member2>,
      <http://example.org/member3>.

これは意図したものではありません。メンバーのURLには、containerパスのセグメントが欠けています。返されたドキュメントは、正確であるために、冗長にならざるをえないでしょう。

例7: コンテナURIはhttp://example.org/container1
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.

<> a a ldp:Container, ldp:BasicContainer;
 dcterms:title "A very simple container";
 ldp:contains <container1/member1>, <container1/member2>, <container1/member3> .

したがって、明らかに、よりよい解決策は、コンテナURIを確実にトレイリング・スラッシュで終了することです。

2.7 フラグメントを相対識別子として用いること

資源のURIの末尾にフラグメントを置くことができます。フラグメント要素は、ハッシュ記号（#）で始まるため、残りのURIと区切られます。そのため、空でないフラグメントを持つURIは、しばしばハッシュURIと呼ばれます。ハッシュURIは従属または関連する資源を識別します[RFC3986]。

例えば、http://www.example.org/products#item10245というURIについて考えてみましょう。URIのフラグメントではない部分は、ハッシュ記号より前のhttp://www.example.org/productsの部分で、フラグメント識別子は、その後のitem10245の部分です。

リンクト・データ・プラットフォーム資源をRDFで表す場合、フラグメントは、それを記述したドキュメント上で相対URIとして表すことができるため、有用です。これは特に、複数のLDPRの表現が1つのドキュメント内に含まれているような記述に便利です。

まずはじめに、これは、簡潔さという利便性と効率性を提供します。例えば、foo、bar、bazという資源が同じドキュメントに含まれているとします。1つのドキュメントですべての記述を提供することが認められているため、フラグメント識別子（<#foo>、<#bar>および<#baz>）を用いて、ドキュメント内で相対URIを作成できます。[LDP]では、デフォルトの基底URIがドキュメントのURI（http://www.example.org/products）であることが保証されているため、個々の絶対URIは、基底URIにハッシュ記号とフラグメント識別子を加えたものです。

次に、これは、他のアプローチに内在する複雑さを回避するために役立ちます。3つの独立した逆参照可能なURIを用いて同じ結果を得るためには、恐らく303のリダイレクト設定も組み込んで、複数のドキュメントを作成しなければならないため、より複雑でありえます。

次のもドキュメントも参照してください。

セマンティック・ウェブのためのクールなURI（Cool URIs for the Semantic Web）

ウェブ・アーキテクチャの原理、URI参照: URIのフラグメント識別子（Axioms of Web Architecture, URI References: Fragment Identifiers on URIs）
http://www.w3.org/DesignIssues/Fragment.html

HTTP URIの逆参照（Dereferencing HTTP URIs）
http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14

2.8 標準的なデータ型を選択すること

LDPRの表現には、次の標準的なデータ型のみを使用すべきです。RDF自身にはリテラルのプロパティー値に用いるデータ型は定義されていません。したがって、[XMLSCHEMA11-2]と[RDF-PRIMER11]に基づく次の標準的なデータ型を用いるべきです。

URI 説明
http://www.w3.org/2001/XMLSchema#boolean XSD Booleanで規定されているブール値型
http://www.w3.org/2001/XMLSchema#date XSD dateで規定されている日付型
http://www.w3.org/2001/XMLSchema#dateTime XSD dateTimeで規定されている日時型
http://www.w3.org/2001/XMLSchema#decimal XSD Decimalで規定されている10進数型
http://www.w3.org/2001/XMLSchema#double XSD Doubleで規定されている倍精度浮動小数点数型
http://www.w3.org/2001/XMLSchema#float XSD Floatで規定されている浮動小数点数型
http://www.w3.org/2001/XMLSchema#hexBinary XSD hexBinaryで規定されている任意の16進エンコードされたバイナリ・データ
http://www.w3.org/2001/XMLSchema#integer XSD Integerで規定されている整数型
http://www.w3.org/2001/XMLSchema#string XSD Stringで規定されている文字列型
http://www.w3.org/2001/XMLSchema#base64Binary XSD Base64Binaryで規定されているバイナリ型
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral RDFで規定されているリテラルXML値

2.9 複製を（再）開発するのではなく、確立済みのリンクト・データ語彙を再使用すること

この項では、RDF語彙と意味が一致する述語を資源が用いる必要のある場合に、リンクト・データ・プラットフォーム資源で必ず使用すべきいくつかの有名なRDF語彙について要約します。例えば、資源に内容記述（description）があり、その内容記述のアプリケーションのセメンティクスがdcterms:descriptionと互換性がある場合には、dcterms:descriptionを使用すべきです。必要であれば、追加のアプリケーション固有の述語を使用できます。定義域の仕様では、特定の資源の型に対しこれらのプロパティーのうちの1つ以上が必要でありえます。下記表の値域の列は、プロパティーに対する定義済みのrdfs:rangeを識別します。

共通プロパティー

ダブリン・コアのURIから: http://purl.org/dc/terms/

プロパティー 値域/データ型 解説
dcterms:contributor dcterms:Agent
dcterms:creator dcterms:Agent
dcterms:created xsd:dateTime
dcterms:description rdf:XMLLiteral XHTMLフォーマットのリッチ・テキストで表される、資源に関する説明文。XHTML要素の内部で有効かつ適切なコンテンツのみが含まれるべきです。
dcterms:identifier rdfs:Literal
dcterms:modified xsd:dateTime
dcterms:relation rdfs:Resource 関連する資源のHTTP URI。これは他に何を使用すべきか分からない場合に使用する述語です。どんな種類の関係かがより明確に分かっているときには、より特定的な述語を用いてください。
dcterms:subject rdfs:Resource
dcterms:title rdf:XMLLiteral 資源に与えられた名前。XHTMLフォーマットのリッチ・テキストで表されます。 XHTML要素の内部で有効なコンテンツが含まれるべきです。

dcterms:typeという述語は、使用すべきではありません、その代りに、rdf:typeを用いましょう。[DC-RDF].

RDFのURIから: http://www.w3.org/1999/02/22-rdf-syntax-ns#

プロパティー 値域/データ型 解説
rdf:type rdfs:Class 資源の型（複数も可）

RDFスキーマのURIから: http://www.w3.org/2000/01/rdf-schema#

プロパティー 値域/データ型 解説
rdfs:member rdfs:Resource  
rdfs:label rdfs:Literal 語彙の用語名を定義するために、語彙ドキュメントでのみこれを使用してください。

2.10 qvalueを適切に用いること

品質係数により、ユーザやユーザ・エージェントは、0から1までのqvalueの尺度を用いて、メディア・レンジに対する相対的な優先度を示すことができるようになります。デフォルト値はq=1です。例えば下記をご覧ください。

Accept: text/turtle; q=0.5, application/json

これは「application/jsonの方が望ましいけれども、品質を50%下げても利用可能な最良のものであれば、text/turtleを送信してください」と解釈すべきです。

qvaluesの不適切な取り扱いは、内容交渉の実装でよく見られる問題です。

クライアントとサーバーの両方の実装に対するqvaluesの適切な使用方法と評価について理解するためには、[HTTP11]仕様の14項「ヘッダ・フィールドの定義」を参照してください。

2.11 プライマリURLで応答し、それをアイデンティティーの比較に用いること

クライアントは複数のURLでLDPRにアクセスできます。LDPサーバーは、LDPRに対し、1つの整合性のあるURL（プライマリURL）を用いて、それらの個々のリクエストに応答すべきです。このプライマリURLは、応答のLocationおよび（または）Content-Locationのヘッダーにあり、LDPRの表現の中にもありえます。よくあるのは、1つはHTTP、1つはHTTPSと、プロトコルによってURLが異なるけれども、その他の点は同じであるURLのケースです。ほとんどの場合、これらの2つのURLは同じ資源を参照し、サーバーは1つの（プライマリ）URLがある方のURLのリクエストに応答すべきです。

クライアントは、プライマリURLをLDPRのアイデンティティーとして使用すべきです。例えば、2つのURLが同じ資源を参照するかどうかを判断する場合、クライアントは、資源にアクセスするために用いたURLではなく、プライマリURLを比較すべきです。この使用は、プライマリURLをクライアントに伝えるヘッダーおよび（または）コンテンツを信頼する十分な理由がクライアントにあることを暗示することに注意してください。HTTP[RFC7231]は単独ではこれを保証できません[RFC7231]。

2.12 資源間の関係を表すこと

LDPRは1つのRDFトリプルで別の資源へのリンク（関係）を表します。情報源資源のURIをトリプルの主語として、また、ターゲットの資源のURIをトリプルの目的語として持っていれば十分です。ある背景を持つ読者が持っている誤解に反して、関係を表現するために「中間リンク」資源を作成する必要はありません。

2.13 サーバー固有の制約を最小化すること

LDPサーバーは、LDPRを簡単に作成・修正できるようにすべきです。

LDPサーバーが表現に制限を置くことは一般的かもしれません – 例えば、rdf:type述語の範囲、述語の目的語のデータ型、LDPRにおける述語の出現数が挙げられますが、サーバーはそのような制限を最小化すべきです。

一部のサーバ・アプリケーションでは、資源の修正に対して過度の制約を要求されるかもしれません。しかし、複雑な制約を強制すると、資源を修正できるクライアントが大きく制限されるでしょう。したがって、より広範囲のクライアントとの相互運用性のために、実装者は、サーバー固有の制約を最小化することが推奨されます。

3. ガイドライン

3.1 コンテナはメンバーシップと包含トリプルに制限されない

リンクト・データ・プラットフォーム・コンテナ（LDPC）がリンクト・データ・プラットフォームRDF情報源（LDP-RS）でもあることを覚えていることは重要です。また、それはメンバーシップ・コントローラーとして存在しているかもしれませんが、それにアクセスするエージェントにとって重要な追加データも提供してくれるかもしれません。

3.2 確立された語彙の発見

下記は、既存の語彙、共通の語彙、確立された語彙を発見・活用するためのいくつかの有用な資源です。

A. 謝辞

この種のドキュメントをとても簡単に記述できるReSpecツールに関し、Robin Berjonおよびすべての貢献者に謝意を表します。

編集者に加え、このドキュメントの継続的改善に直接的または間接的に貢献いただいた次の方々に謝意を表します。

B. 参考文献

B.1 参考情報の参考文献

[DC-RDF]
M. Nilsson et al. Expressing Dublin Core metadata using the Resource Description Framework (RDF). 14 January 2008. DCMI Recommendation. URL: http://dublincore.org/documents/dc-rdf/
[HTTP11]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. June 2014. Proposed Standard. URL: http://www.ietf.org/rfc/rfc7230.txt
[LD-DI]
Tim Berners-Lee. Linked Data - Design Issues. URL: http://www.w3.org/DesignIssues/LinkedData.html
[LD-GLOSSARY]
B Hyland; G Atemezing; M Pendleton; B Srivastava. Linked Data Glossary. URL: http://www.w3.org/TR/ld-glossary/
[LDP]
Steve Speicher; John Arwe; Ashok Malhotra. Linked Data Platform 1.0. 19 June 2014. W3C Candidate Recommendation. URL: http://www.w3.org/TR/ldp/
[LDP-PRIMER]
Nandana Mihindukulasooriya; Roger Menday. Linked Data Platforn Primer. W3C Working Draft. URL: https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html
[LDP-TESTS]
Raul Garcia-Castro. Linked Data Platform 1.0 Test Cases. W3C Working Draft. URL: https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html
[LDP-UCR]
Linked Data Platform Use Cases and Requirements. W3C Working Group Note. URL: http://www.w3.org/TR/ldp-ucr/
[LOD-COMMON-VOCABS]
Common Vocabularies / Ontologies / Micromodels . URL: http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies
[LOV]
Linked Open Vocabularies (LOV). URL: http://lov.okfn.org/dataset/lov/
[RDF-PRIMER11]
RDF 1.1 Primer. W3C Working Group Note. URL: http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/
[RDF-SCHEMA]
Dan Brickley; Ramanathan Guha. RDF Schema 1.1. 25 February 2014. W3C Recommendation. URL: http://www.w3.org/TR/rdf-schema/
[RFC3986]
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. January 2005. Internet Standard. URL: http://www.ietf.org/rfc/rfc3986.txt
[RFC3987]
M. Duerst; M. Suignard. Internationalized Resource Identifiers (IRIs). January 2005. Proposed Standard. URL: http://www.ietf.org/rfc/rfc3987.txt
[RFC7231]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. June 2014. Proposed Standard. URL: http://www.ietf.org/rfc/rfc7231.txt
[TURTLE]
Eric Prud'hommeaux; Gavin Carothers. RDF 1.1 Turtle. 25 February 2014. W3C Recommendation. URL: http://www.w3.org/TR/turtle/
[WEBARCH]
Ian Jacobs; Norman Walsh. Architecture of the World Wide Web, Volume One. 15 December 2004. W3C Recommendation. URL: http://www.w3.org/TR/webarch/
[XMLSCHEMA11-2]
David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. 5 April 2012. W3C Recommendation. URL: http://www.w3.org/TR/xmlschema11-2/
[metaDataInURI]
The use of Metadata in URIs. finding. URL: http://www.w3.org/2001/tag/doc/metaDataInURI-31