Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://www.asahi-net.or.jp/~ax2s-kmtn/internet/lod/REC-ldp-20150226.html below:

リンクト・データ・プラットフォーム1.0

リンクト・データ・プラットフォーム（LDP）は、RDFなどに基づく、ウェブ資源に対するHTTPオペレーションの規則を定義し、ウェブの読み書き用リンクト・データのアーキテクチャを提供します。

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

このドキュメントは、W3Cメンバー、ソフトウェア開発者、他のW3Cグループ、および他の利害関係者によりレビューされ、W3C勧告として管理者の協賛を得ました。これは確定済みドキュメントであり、参考資料として用いたり、別のドキュメントで引用することができます。勧告の作成におけるW3Cの役割は、仕様に注意を引き付け、広範囲な開発を促進することです。これによってウェブの機能性および相互運用性が増強されます。

ワーキンググループの実装報告書を参照してください。

このW3C勧告はリンクト・データ・プラットフォーム・ワーキンググループにより公表されました。このドキュメントに関する議論は、public-ldp-comments@w3.orgにあります（購読、アーカイブ）。

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

このドキュメントは、2005年10月14日のW3Cプロセス・ドキュメントによって管理されています。

この項は非規範的です。

この仕様では、資源をリンクト・データとして提供するサーバーの資源にアクセス、更新、作成、削除するためにHTTPを用いる方法について述べています。これは、次のリンクト・データ[LINKED-DATA]の規則を明確化し拡張するものです。

1. 事物の名前としてURIを用いること
2. その名前を参照できるように、HTTP URIを用いること
3. 標準的な技術（RDF*、SPARQL）を用いて、URIを参照したときに、有用な情報を提供すること
4. さらに多くの事物を発見できるように、他のURIへのリンクを含むこと

この仕様では、リンクト・データ・プラットフォーム資源を作成、読み書きするクライアントとサーバーを構築する際に用いる標準的なHTTPとRDF技術について論じています。LDP入門は、架空のアプリケーションに基づく多くの事例により、初心者レベルの入門情報を提供します。LDPベスト・プラクティスおよびガイドラインは、クライアントとサーバーの構築時に用いるべきベスト・プラクティスと、避けるべきアンチパターンについて論じています。

この仕様では、コンテナという特殊なリンクド・データ・プラットフォーム資源を定義しています。コンテナは、資源のコレクション（集合）（同じものであることが多い）を扱うアプリケーション・モデルの構築に非常に有用です。例えば、大学は、授業の集合や教職員の集合を提供し、個々の教職員はコースの集合で授業を行うなどの例が挙げられます。この仕様は、コンテナの利用方法について論じています。POSTなどの標準的なHTTPオペレーションを用いて資源をコンテナに追加できます（5.2.3項 HTTP POSTを参照）。

この仕様は、規則の追加や階層化した規則のグループを、追加の仕様として実現することを目指しています。すべてでなくともほとんどの他の仕様が依拠したり実装がサポートするような、リンクト・データを読み書きするためのキーとなる規則を提供するために意図的にスコープを狭くしてあります。

この仕様は、大きな資源を扱うためのいくつかのアプローチを提供します。この仕様への拡張により、大きな資源表現をページに分割された複数のレスポンス[LDP-PAGING]に分割する性能が得られます。

前後関係や背景を理解するために、リンクド・データ・プラットフォーム・ユースケースと要件[LDP-UCR]と6項 規範的な参考文献の重要情報を読むと有益かもしれません。

用語は、W3Cのウェブ・アーキテクチャ[WEBARCH]とハイパーテキスト転送プロトコル（[RFC7230]、[RFC7231]、[RFC7232]）に基づいています。

リンク／Link

1つの資源（表現）がURIで別の資源を参照する場合の2つの資源の関係[WEBARCH]

リンクト・データ／Linked Data

ティム・バーナーズ=リーによる定義のとおり[LINKED-DATA]

クライエント／Client

1つ以上のHTTPリクエストを送信する目的で接続を確立するプログラム[RFC7230]

サーバー／Server

HTTPレスポンスの送信によりHTTPリクエストに情報提供を行うために接続を受け入れるプログラム

「クライアント」および「サーバー」という用語は、これらのプログラムが特定の接続に対して実行する役割のみを意味します。同じプログラムが、ある接続においてはクライアントとして、その他の接続においてはサーバーとして動作することがありえます。

HTTPにより、中継プログラムを用いて、一連の接続によってクエストを満たすことが可能となります。HTTPの中継プログラムには、プロキシ、ゲートウェイ、トンネルという3つの一般的な形式があります。場合によっては、一つの中継プログラムは、各リクエストの性質に基づいて動作を切り替え、起源サーバー、プロキシ、ゲートウェイまたはトンネルとして動作するかもしれません。[RFC7230]。

リンクト・データ・プラットフォーム資源／Linked Data Platform Resource (LDPR)

4項 リンクト・データ・プラットフォーム資源のシンプルなライフサイクル・パターンと規定に準拠した方法で状態を表すHTTP資源

リンクト・データ・プラットフォームRDF情報源／Linked Data Platform RDF Source (LDP-RS)

状態を全てRDFで表し、RDFグラフに対応しているLDPR。[rdf11-concepts]のRDF情報源という用語も参照してください。

リンクト・データ・プラットフォーム非RDF情報源／Linked Data Platform Non-RDF Source (LDP-NR)

状態をRDFで表さないLDPR。例えば、有用なRDF表現を持たないバイナリやテキストのドキュメントでありえます。

リンクト・データ・プラットフォーム・コンテナ／Linked Data Platform Container (LDPC)

作成、変更および／またはリンク付けされたメンバーやドキュメントの列挙に関するクライアントのリクエストに応答するリンクされたドキュメント（RDFドキュメント[rdf11-concepts]または情報資源[WEBARCH]）の集合を表すLDP-RSで、5項 リンクト・データ・プラットフォーム・コンテナのシンプルなライフサイクル・パターンと規定に準拠しています。

リンクト・データ・プラットフォーム基本コンテナ／Linked Data Platform Basic Container (LDP-BC)

含まれているドキュメント（情報資源）に対してシンプルなリンクを定義しているLDPC[WEBARCH]。

リンクト・データ・プラットフォーム直接コンテナ／Linked Data Platform Direct Container (LDP-DC)

メンバーシップの概念を追加したLDPCで、これにより、そのメンバーシップ・トリプルがどのような形式をとるかを柔軟に選択でき、メンバーが、ドキュメントのみではなく、任意の資源[WEBARCH]となることができるようになります。

リンクト・データ・プラットフォーム間接コンテナ／Linked Data Platform Indirect Container (LDP-IC)

LDP-DCに似ているLDPCで、同じくドキュメントに割り当てられたURLではなく、含まれているドキュメントの内容に基づくURLを持つメンバーを持つことができます。

メンバーシップ／Membership

LDPCとそのメンバーのLDPRsを関連付ける関係で、含まれているドキュメントとは異なる資源でありえます。LDPCのURIがその中に存在するかどうかにかかわらず、LDPCは、しばしば、メンバーシップ・トリプルの管理に役立ちます。

メンバーシップ・トリプル／Membership triples

LDPCのメンバーを列挙するトリプル。LDPCのメンバーシップ・トリプルはすべて次のパターンのうちの1つを持っています。 membership-constant-URI membership-predicate member-derived-URI member-derived-URI membership-predicate membership-constant-URI これらの2つの違いは、単にmember-derived-URがどの位置にあるかという点にあり、それは通常、membership-predicateの選択により導かれます。ほとんどの述語には、自然な進行方向がその名前に内在しており、既存の語彙には、それぞれの方向性で自然に読める有用な例が含まれています。ldp:memberとdcterms:isPartOfは、その代表的な例です。

リンクされている個々のコンテナは、どのパターンを用いるか、実際のmembership-predicateとmembership-constant-URIの値が何なのか、そして、（新しいメンバーの作成が可能なコンテナの場合は）作成プロセスに対するクライアントのインプットに基づいて、member-derived-URIにどのような値を用いるか、をクライアントが決定できるようなプロパティー（5.2.1項 概要）を提供します。

メンバーシップ述語／Membership predicate

すべてのLDPCのメンバーシップ・トリプルの述語

包含／Containment

LDPCを、それがライフサイクルを管理し、意識しているLDPRsにバインディングする関係です。含まれているLDPRのライフサイクルは、それを含んでいるLDPCのライフサイクルにより制限されます。つまり、含まれているLDPRは、含んでいるLDPCが存在するまで（LDP定義による方法で）作成できません。

包含トリプル／Containment triples

LDPCにより作成されたけれども未削除であるドキュメントを列挙している（LDPCにより維持されている）トリプルの集合。これらのトリプルは常に( LDPC URI, ldp:contains , document-URI )の形式を持っています。

最小コンテナ・トリプル／Minimal-container triples

コンテナが空のときに存在するLDPCのトリプルの部分。現在、この定義は、すべてのLDPCのトリプルからその包含トリプルを除き、さらに、（どちらかがその状態の一部と考えられる場合には）そのメンバーシップ・トリプルを除いたものに等しいですが、将来的なLDPのバージョンがトリプルのクラスを追加定義する場合には、この定義は、それらのクラスも除外するように拡張されるでしょう。

LDPサーバー管理トリプル／LDP-server-managed triples

メンバーシップ・トリプルや包含トリプルなどの、この仕様が動作を直接制約するLDPのトリプルの部分。資源のコンテンツのこの部分には、例えば、サーバーがたまたまサポートしている他の仕様や、サーバーの実装上の決定によるものなどのLDP以外で課される制約は含まれません。

LDPの名前空間は、http://www.w3.org/ns/ldp#です。

例の資源表現は、text/turtleの形式[turtle]で提供します。

一般的に用いられる名前空間接頭辞は次のとおりです。

	@prefix dcterms: <http://purl.org/dc/terms/>.
	@prefix foaf:    <http://xmlns.com/foaf/0.1/>.
	@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
	@prefix ldp:     <http://www.w3.org/ns/ldp#>.
	@prefix xsd:     <http://www.w3.org/2001/XMLSchema#>.

非規範的と記している項と同じく、この仕様のすべての作成ガイドライン、図、例、注は、非規範的です。この仕様のその他の部分はすべて規範的です。

「することができる／してもよい（MAY）」、「しなければならない（MUST）」、「してはならない（MUST NOT）」、「推奨される（RECOMMENDED）」、「すべきである／する必要がある（SHOULD）」、「すべきでない／する必要がない（SHOULD NOT）」というキーワードは、[RFC2119]で記述されているように解釈されるべきです。

リンクト・データ・プラットフォーム1.0（このドキュメント）の各項のステータスは次のとおりです。

• 1. はじめに: 非規範的
• 2. 用語: 規範的
• 3. 適合性: 規範的
• 4. リンクト・データ・プラットフォーム資源: 規範的
• 5. リンクト・データ・プラットフォーム・コンテナ: 規範的
• 6. 規範的な参考文献の重要情報: 非規範的
• 7. HTTPヘッダー定義: 規範的
• 8. セキュリティに関する留意点: 非規範的
• A. 謝辞: 非規範的
• B. 変更履歴: 非規範的
• C.1 規範的な参考文献: 規範的
• C.2 非規範的な参考文献: 非規範的

適合LDPクライアントは、4項 リンクト・データ・プラットフォーム資源および5項 リンクト・データ・プラットフォーム・コンテナのLDPにより定義された規則に従った適合HTTPクライアント[RFC7230]です。

適合LDPサーバーは、それがLDPRsを提供するときには4項 リンクト・データ・プラットフォーム資源、それがLDPCsを提供するときには5項 リンクト・データ・プラットフォーム・コンテナのLDPにより定義された規則に従った適合HTTPサーバー[RFC7230]です。LDPは、他のHTTP資源を提供する際にはその動作を制約しません。

この項は非規範的です。

リンクト・データ・プラットフォーム資源（LDPRs）は、この項のシンプルなパターンと規定に適合したHTTP資源です。LDPRsにアクセス、更新、作成、削除するためのHTTPリクエストは、LDPサーバーが受け入れて処理します。ほとんどのLDPRsは、ある領域のエンティティーのデータを含んでいる領域固有の資源で、商業、政府、科学、宗教などに関するものでありえます。

このドキュメントで定義している一部の規則は、ベースとなるリンクト・データ規則[LINKED-DATA]を明確化し精緻化するもので、その他は追加的なニーズに対応するものです。

リンクト・データ・プラットフォーム資源の規則は、次のような基本的な問題に対応します。

• どのような資源表現を用いるべきか?
• 更新に対するオプティミスティック衝突の検出をどのように扱うか?
• 型の変更などの、linked-to資源の変更に対するクライアントの期待はどのようなものであるべきか?
• サーバーは、どのようにクライアントによる資源作成を容易にできるか?
• GETにより、大きな資源の表現をどのようにページに分割することができるか?

次のような問題に対応しているLDPベスト・プラクティスおよびガイドラインで追加の非規範的ガイダンスを入手できます。

• どのようなリテラル値方を用いるべきか?
• 再利用すべき標準的な語彙があるか?
• 一般的であるけれども、規範的に指定できるほど一般的ではないLDPRsと相互作用する場合に、どのようなガイドラインが存在するか？

以下の項では、LDPRsを提供する際のLDPサーバーの適合規則を定義します。

LDP-RSの表現は大きすぎる場合があり、1つの対応策は、レスポンス表現を、ページと呼ばれるクライアントが利用できる量に分割することです。別のLDP仕様で、ページ分割[LDP-PAGING]に関する適合規則について概説しています。

LDPサーバーは、状態をRDFを用いて表す資源（LDP-RS）と、その他のフォーマットを用いて表す資源（LDP-NR）の2種類のLDPRsを扱うことができます。LDP-RSsは、その表現がRDFに基づくというユニークな性質を持っており、ウェブ・メタデータ、オープン・データ・モデル、機械処理可能な情報、およびソフトウェア・エージェント[rdf11-concepts]による自動処理の多くのユースケースに対応しています。LDP-NRsは、画像、HTMLページ、ワードプロ・ドキュメント、表計算などの、今日のWeb上のほとんどあらゆるものであり、LDP-RSsは、LDP-NRsに関するメタデータを保持している場合があります。

図2 リンクト・データ・プラットフォーム資源の型のクラス関係で説明しているとおり、LDP-NRsとLDP-RSsは、LDPRsのサブタイプにすぎません。

注：HTTP Linkヘッダーは、実行時にクライアントが動的に検査できるような方法で、サーバーが特定の資源対するLDP仕様のサポートを言明する方法です。これは、LDP-RSにおけるトリプル(subject-URI, rdf:type, ldp:Resource)の存在と同等ではありません。ヘッダーの存在は、サーバーがLDPRsとのHTTP相互作用においてLDP仕様の制約に従うということを言明します。つまり、資源がEtagsを持ち、OPTIONSをサポートするということを言明します。これは、すべてのウェブ資源に当てはまるわけではありません。

注：LDPサーバーは、LDP-RSsとLDP-NRsを混ぜて提供できるため、あるHTTP Request-URIでLDPのサポートが公言されていても、それは、同じサーバー上の別の資源もLDPRsであることを意味するとい示唆を含んでいるわけではありません。外部情報がなければ、個々のRequest-URIは、個々に検査する必要があります。

[RFC7231]ではこのHTTPメソッドはオプションであり、この仕様では、LDPサーバーがこれをサポートする必要はありません。LDPサーバーがこのメソッドをサポートしている場合には、この仕様はLDPRsに新しい要件を課しません。

クライアントは、LDPCに対するPOST（5.2.3項 HTTP POST）、PUT（4.2.4項 HTTP PUT）、またはHTTP資源で認められているその他のメソッドによって、LDPRsを作成できます。LDPRの作成や更新に対してサーバーが制約を課す場合には、そのことをクライアントに公言しなければなりません。

[RFC7231]ではこのHTTPメソッドはオプションであり、この仕様では、LDPサーバーがこれをサポートする必要はありません。LDPサーバーがこのメソッドをサポートしている場合には、この仕様はLDPRsに次の新しい要件を課します。

LDPRの作成や更新に対してサーバーが制約を課す場合には、そのことをクライアントに公言しなければなりません。

非規範的な注: クライアントは、例えば、GET／表現の更新／PUTというシーケンスの一部として、すでに資源の状態にあるプロパティーと同等のプロパティーを提供するかもしれず、そのPUTリクエストは、GETレスポンスと後のPUTリクエストとのLDPサーバー管理プロパティーが同じである限り機能することが意図されています。これは、一度設定されればクライアントに更新することをサーバーが認めないライトワンスのプロパティーのようなその他のケースとは対照的です。このようなプロパティーはクライアントおよび／またはサーバーの管理下にありますが、LDPよって制約されていないため、LDPサーバー管理トリプルではありません。

[RFC7231]ではこのHTTPメソッドはオプションであり、この仕様では、LDPサーバーがこれをサポートする必要はありません。LDPサーバーがこのメソッドをサポートしている場合には、この仕様はLDPRsに新しい包括的な要件を課しません。

コンテナ内のLDPRsに対するHTTP DELETEの追加要件は、5.2.5項 HTTP DELETEにあります。

あるLDPメカニズムはHTTPヘッダーに依存しており、HTTPは一般的に、GETレスポンスと同じヘッダーがHEADレスポンスに含まれていることを要求することに注意してください。したがって、実装者は、4.2.2項 HTTP GETと4.2.8項 HTTP OPTIONSも注意して読むべきです。

[RFC5789]ではこのHTTPメソッドはオプションであり、この仕様では、LDPサーバーがこれをサポートする必要はありません。LDPサーバーがこのメソッドをサポートしている場合には、この仕様はLDPRsに次の新しい要件を課します。

LDPRの作成や更新に対してサーバーが制約を課す場合には、そのことをクライアントに公言しなければなりません。

この仕様は、[RFC7231]のものの他に、LDPRsのHTTP OPTIONSに次の新しい要件を課します。PATCH、Accept-Postなどのこの仕様の他の項では、OPTIONSレスポンスに他の要件を追加しています。

以下の項には、リンクト・データ・プラットフォームRDF情報源の規範的な条項が含まれています。

非規範的な注: つまり、クライアントが予期する（クライアントがそれをリクエストする）ような通常のケースであっても、クライアントがTurtleやその他のメディア・タイプをリクエストし、内容交渉の結果が互角になり、Turtleが互角であるメディア・タイプの一方であるケースであっても、LDPサーバーはTurtleを返さなければなりません。例えば、Acceptヘッダーに、相対的な品質係数が最も高い（q=値）いくつかのメディア・タイプのうちの1つとしてtext/turtleが記述されていれば、LDPサーバーはTurtleで応答しなければなりません。一般的なHTTPサーバーは、このような方法で互角の状況を解決する必要も、Turtleをサポートする必要も全くありませんが、LDPサーバはその必要があります。一方で、Turtleはリクエストされたメディア・タイプのうちの一つであったとしても、サーバーがサポートする他のメディア・タイプの相対的な品質係数がより高い場合には、標準的なHTTP内容交渉規則が適用され、サーバー（LDPであろうとなかろうと）はTurtleで応答しないでしょう。

次の項にはリンクト・データ・プラットフォーム非RDF情報源の規範的な条項が含まれています。

この項は非規範的です。

多くのHTTPアプリケーションやサイトは、資源空間全体をより小さなコンテナに分割する組織化の概念を持っています。ブログ投稿はブログにグルーピングされ、wikiページはwikiにグルーピングされ、製品はカタログにグルーピングされます。アプリケーションやサイトで作成された各資源は、これらのコンテナに似たエンティティーのうちの1つのインスタンス内で作成され、ユーザはその中の既存のアーティファクトを列挙できます。コンテナは、次のいくつかの基本的な問いに対する答えとなります。

1. 新しい資源を作成するためにどのURLにPOSTできるか。
2. どこで既存の資源のリストをGETできるか。
3. どうすればコンテナとともにメンバーの情報を得られるか。
4. どうすれば資源データのクエリの実行しやすさを保証できるか。
5. コンテナ・エントリーの順序はどのように表現されるか[LDP-PAGING]。

このドキュメントでは、これらの課題に対応したコンテナの表現と動作を定義しています。様々なユースケースをサポートするために複数種類のコンテナが定義されており、そのすべてが基本的な性能をサポートしています。コンテナの内容の定義は、その表現（そして状態）内のトリプルによって行われ、それは、包含トリプルと呼ばれ、固定パターンに従います。別の種類コンテナでは、その表現内のトリプルによってコンテナのメンバーの集合を定義でき、それはメンバーシップ・トリプルと呼ばれ、一貫性のあるパターン（可能なパターンに関しては、linked-toの定義を参照）に従います。すべてのコンテナのメンバーシップ・トリプルには、メンバーシップ述語と呼ばれる同一の述語があり、主語か目的語のどちらかは、一貫性のある値でもあります – メンバーシップ・トリプル（変化するもの）の残りの位置は、コンテナのメンバーを定義します。最もシンプルなケースでは、一貫性のある値はLDPC資源のURIですが、そうでなければならないわけではありません。メンバーシップ述語も変数であり、しばしばサーバー・アプリケーション語彙の述語またはldp:member述語です。

LDP 1.0には、クライアントが、コンテナの部分的な表現のみを含んだレスポンスをリクエストする方法があります。アプリケーションは、レスポンス表現にフィルタリングされたデータを含み、追加の詳細情報を含む（または除く）方法を追加定義できます。この方法は、アプリケーション固有であり、このドキュメントでは定義していません。

このドキュメントには、新しい資源を作成し、それをコンテナにリンクされた資源のリストに追加するためのガイドラインが含まれています。さらに、どのように作成されたかや、どのようにコンテナのメンバーシップに追加されたかにかかわらず、関連する資源について知る方法を説明しています。また、コンテナを使って作成された資源を後で削除したときの挙動も定義しています。コンテナの削除によりメンバーシップ情報が削除され、参照されていないメンバー資源に対して何らかのクリーンアップ作業が行なわれる可能性があります。

以下は、3つのメンバーのみと、コンテナに関する何らかの情報（それがコンテナであるという事実と、短いタイトル）が含まれる非常にシンプルなコンテナを示しています。

例1

GET /c1/ HTTP/1.1
Host: example.org
Accept: text/turtle

例2

HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "8caab0784220148bfe98b738d5bb6d13"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD,PUT
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Transfer-Encoding: chunked

@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.

<http://example.org/c1/>
   a ldp:BasicContainer;
   dcterms:title "A very simple container";
   ldp:contains <r1>, <r2>, <r3>.

上記の例は、非常に単純なものです。包含トリプルがあり、その主語はコンテナ、述語はldp:contains、目的語は含まれている資源のURIで、メンバー資源と含まれている資源との区別はありません。このコンテナにPOSTを行うと新しい資源が作成され、そのコンテナに新しい包含トリプルを追加することで、それは、含まれている資源のリストに追加されます。この種のコンテナは、リンクト・データ・プラットフォーム基本コンテナと呼ばれます。

既存モデル上に徐々に構築する必要があるため、資源モデルに自由度がほとんどない場合もあります。そのような状況では、クライアントが既存の語彙にLDPパターンをマッピングできるようにしたり、コンテナで作成されなかったメンバーを含むとよいかもしれません。LDP直接コンテナがこの種のニーズを満たします。直接コンテナにより、メンバーシップ・トリプルが、コンテナ自身以外の主語を、一貫性のあるメンバーシップの値として用いること、および／または、アプリケーションの領域モデルの述語をメンバーシップの述語として用いることが可能になります。

すぐ下の例で示しているとおり、人の自己資本に関する既存の領域資源から始め、その後で、どのようにコンテナ資源をその後の例に応用できるかを見ましょう。

例3

GET /netWorth/nw1/ HTTP/1.1
Host: example.org
Accept: text/turtle

例4

HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "0f6b5bd8dc1f754a1238a53b1da34f6b"
Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: GET,OPTIONS,HEAD,PUT,DELETE
Transfer-Encoding: chunked

@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology#>.

<http://example.org/netWorth/nw1/>
   a o:NetWorth;
   o:netWorthOf <http://example.org/users/JohnZSmith>;
   o:asset 
      <assets/a1>,
      <assets/a2>;
   o:liability 
      <liabilities/l1>,
      <liabilities/l2>,
      <liabilities/l3>.

上記の例には、人の自己資本のインスタンスを表す資源を示しているo:NetWorthというrdf:typeと、関連付けられている人を示しているo:netWorthOf述語があります。同じ主語、同じ述語の2つのトリプルがあり、1つは財産に関するもので、1つは債務に関するものです。これらの型と述語に依存している既存の領域固有のアプリケーションが存在しているため、互換性なくそれらを変更するとひんしゅくを買うことになります。

財産と債務関連のトリプルを管理するために、LDPパターンを使用できると便利でしょう。基本コンテナを用いてこれを行うためには、様々な型と述語を持つ情報の多くをコピーする必要があり、大きな資源の場合には面倒なものとなるでしょう。直接コンテナは、既存の領域固有の資源をLDPの型と相互作用モデルにマッピングする方法をLDPクライアントに提供することで、一つの落としどころとなります。この具体的な例では、例えばLDPコンテナを用いて、財産と債務のトリプルを矛盾なく管理できれば便利でしょう。これを行うための一つの方法は、1つは財産を管理するため、もう1つは債務を管理するためと、別々のHTTP資源として、2つのコンテナを作成することです。LDPに対応しているクライアントは相互作用を行えるコンテナURLを持つようになりましたが、既存のクライアントは、それらのコンテナと相互作用を行う必要はありません。既存のクライアントが正常に機能し続けられるように、既存の資源は元のままであり続けます。これは、以前のLDP-RS例に始まり、HTTP資源ごとに1つの例を用いて、関連する例で示しています。

例5

GET /netWorth/nw1/ HTTP/1.1
Host: example.org
Accept: text/turtle

例6

HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "0f6b5bd8dc1f754a1238a53b1da34f6b"
Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: GET,OPTIONS,HEAD,PUT,DELETE
Transfer-Encoding: chunked

@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology#>.

<http://example.org/netWorth/nw1/>
   a o:NetWorth;
   o:netWorthOf <http://example.org/users/JohnZSmith>;
   o:asset 
      <assets/a1>,
      <assets/a2>;
   o:liability 
      <liabilities/l1>,
      <liabilities/l2>,
      <liabilities/l3>.

自己資本の資源の構造は全く変わらないため、既存の領域固有のアプリケーションは影響を受けずに動作し続けます。一方で、LDPクライアントには、財産と債務のトリプルが何らかの方法でLDPコンテナに対応していると理解する方法がありません。そのため、次の2つの資源が必要です。

最初のコンテナは、財産を管理するためのLDP直接コンテナです。直接コンテナは、メンバーシップ・トリプルを指定する方法に、メンバーシップと柔軟性の概念を追加します。

例7

GET /netWorth/nw1/assets/ HTTP/1.1
Host: example.org
Accept: text/turtle

例8

HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "6df36eef2631a1795bfe9ab76760ea75"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Transfer-Encoding: chunked
      
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix o: <http://example.org/ontology#>.

<http://example.org/netWorth/nw1/assets/>
   a ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipResource <http://example.org/netWorth/nw1/>;
   ldp:hasMemberRelation o:asset;
   ldp:contains <a1>, <a2>.

上記の財産のコンテナでは、一貫性のあるメンバーシップ値（membership-constant-URI、主語の位置のまま）は、コンテナ自身ではなく – （別の）自己資本の資源です。メンバーシップの述語は、領域モデルのo:assetです。財産コンテナに対する財産表現のPOSTにより、新しい財産が作成されます。そして、新しいメンバーシップ・トリプルを資源に追加し、包含トリプルをコンテナに追加することにより、それは財産の自己資本の値のリストに追加されます。

2番目のコンテナは、債務を管理するためのLDP直接コンテナです。

例9

GET /netWorth/nw1/liabilities/ HTTP/1.1
Host: example.org
Accept: text/turtle

例10

HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "9f50da01f792281ddcfebe9788372d07"
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD
Transfer-Encoding: chunked

@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix o: <http://example.org/ontology#>.

<http://example.org/netWorth/nw1/liabilities/>
   a ldp:DirectContainer;
   dcterms:title "The liabilities of JohnZSmith";
   ldp:membershipResource <http://example.org/netWorth/nw1/>;
   ldp:hasMemberRelation o:liability;
   ldp:contains <l1>, <l2>, <l3>.

上記の債務のコンテナは、上記の財産コンテナと全く似ており、財産ではなく債務を管理し、o:liability述語を用いているだけです。

別の債務を追加するために、クライアントは、債務に対して次のようなPOSTを行うでしょう。

例11

POST /netWorth/nw1/liabilities/ HTTP/1.1
Host: example.org
Accept: text/turtle
Content-Type: text/turtle
Content-Length: 63

@prefix o: <http://example.org/ontology#>.

<>
   a o:Liability.
   # plus any other properties that the domain says liabilities have

例12

HTTP/1.1 201 CreatedLocation: http://example.org/netWorth/nw1/liabilities/l4
Date: Thu, 12 Jun 2014 19:56:13 GMT
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"

サーバーがこのリクエストをうまく処理し、新しく作成された債務の資源に<http://example.org/netWorth/nw1/liabilities/l4>というURIを割り当てたと仮定すると、最低2つの新しいトリプルが追加されます。

1. 自己資本の資源では、<http://example.org/netWorth/nw1/> o:liability <liabilities/l4>
2. 債務のコンテナでは、<http://example.org/netWorth/nw1/liabilities/> ldp:contains <l4>

なぜ、http://example.org/netWorth/nw1/自身をコンテナにするのではなく、2つの新しいコンテナを作成することにしたのだろうと思われるかもしれません。一つの自己資本のコンテナは、http://example.org/netWorth/nw1/に財産のみ、または、債務のみが含まれていれば（基本的に、管理するのは1つの述語のみ）うまく設計されていると言えますが、財産と債務に別々の述語があるため、クライアントの作成リクエスト（POST）が新しいo:assetやo:liabilityのトリプルを追加すべきかどうかを特定できず、曖昧さが生じます。http://example.org/netWorth/nw1/assets/とhttp://example.org/netWorth/nw1/liabilities/の別々のコンテナがあると、財産と債務の両方が作成され、適切な述語を用いてネット自己資本の資源にリンクできるようになります。クライアントが、メンバーおよび／または含まれている資源を列挙したい場合にも、同じような曖昧さが生じます。

複数のコンテナの方向性を保ちながら、財産と債務を管理してきたアドバイザー（人）に対してコンテナを追加するために、ここで、自己資本の例を拡張します。我々は、このアドバイザーを、フラグメント（ハッシュ）を含んだURLで識別し、それを記述したドキュメントではなく、実世界の資源を表すことにしました。

例13

GET /netWorth/nw1/ HTTP/1.1
Host: example.org
Accept: text/turtle

例14

HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "e8d129f45ca31848fb56213844a32b49"
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: GET,OPTIONS,HEAD,PUT,DELETE
Transfer-Encoding: chunked

@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix o: <http://example.org/ontology#>.

<http://example.org/netWorth/nw1/>
   a o:NetWorth;
   o:netWorthOf <http://example.org/users/JohnZSmith>;
   o:advisor
   	 <advisors/bob#me>,     # URI of a person
   	 <advisors/marsha#me>.
   	 
<advisors/>
   a ldp:IndirectContainer;
   dcterms:title "The asset advisors of JohnZSmith";
   ldp:membershipResource <>;
   ldp:hasMemberRelation o:advisor;
   ldp:insertedContentRelation foaf:primaryTopic;
   ldp:contains
   	 <advisors/bob>,     # URI of a document a.k.a. an information resource
   	 <advisors/marsha>.  # describing a person

この種の間接性を扱うために、ldp:insertedContentRelationという述語とfoaf:primaryTopicという目的語を持つトリプルは、このコンテナにPOSTを行うときには、新しいメンバーシップ・トリプルでどのURIを用いるか（topic-URI）をサーバーに知らせるために、(<>, foaf:primaryTopic, topic-URI)という形式のトリプルを含む必要があるということをクライアントに知らせます。

この種のコンテナは、LDP間接コンテナと呼ばれます。これはLDP直接コンテナに似ていますが、実世界の事物を表しているURIなどの、資源をメンバーとして追加する（作成リクエストにより）ために間接性を提供します。LDP直接コンテナに対する作成リクエストは、情報資源[WEBARCH] - それが作成する文書 - をメンバーとして追加できるだけです。

別のアドバイザーを追加するために、クライアントは、アドバイザーのコンテナに対して次のようなPOSTを行うでしょう。

例15

POST /netWorth/nw1/advisors/ HTTP/1.1
Host: example.org
Accept: text/turtle
Content-Type: text/turtle
Slug: george
Content-Length: 72

@prefix foaf: <http://xmlns.com/foaf/0.1/>.@prefix o: <http://example.org/ontology#>.
<>
   a o:Advisor;
   foaf:primaryTopic <#me>.
   # plus any other properties that the domain says advisors have

例16

HTTP/1.1 201 Created
Location: http://example.org/netWorth/nw1/advisors/george
Date: Thu, 12 Jun 2014 19:56:13 GMT
Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"

サーバーがこのリクエストをうまく処理し、新しく作成されたアドバイザーの資源に<http://example.org/netWorth/nw1/advisors/george>というURIを割り当てたと仮定すると、最低2つの新しいトリプルが追加されます。

1. 自己資本の資源では、<http://example.org/netWorth/nw1/> o:advisor <advisors/george#me>
2. アドバイザーのコンテナでは、<http://example.org/netWorth/nw1/advisors/> ldp:contains <george>

要約すると、図3 リンクト・データ・プラットフォーム・コンテナの型のクラス関係は、LDPRsの型のクラス関係に加え、基本、直接、間接という、LDP定義のコンテナの型を示します。

次の表はメンバーシップと包含のトリプルのいくつかの相違点を示しています。規範的な挙動に関する詳細については、以下の適切な項を参照してください。

多くのメンバーを有するコンテナの表現は大きいでしょう。例えば、LDP-DCのメンバーシップ・トリプルのパターンとメンバーシップ述語を決定するために、メンバー資源とも含まれているドキュメントとも関連付けられていないコンテナのプロパティーのサブセットにのみクライアントがアクセスする必要がある重要なケースもあります。これは、コンテナが0のメンバーと0の含まれている資源になったときの状態であるため、LDPはこれを最小コンテナ・トリプルと呼びます。この情報を得るために、コンテナ全体の表現を検索すると、クライアントにとって面倒で、サーバーにとって不要なオーバーヘッドが生じるため、このプロパティー値のみを検索する方法（そして、より一般的には、他の主要なユースケースの集合体に対応するために用いられるプロパティーのサブセットのみを検索すための方法）を定義しました。このために、LDPは、HTTP Preferヘッダーのreturn=representationプリファレンスにパラメータを追加しています（詳細については、7.2項 望ましいリクエスト・ヘッダーのプリファレンスを参照）。

ここに挙げている例は、最小コンテナ・トリプルがほとんど検索されないシンプルなケースのみを示しています。現実の世界のより複雑ケースとしては、認証情報を提供してSPARQLエンドポイントに関連付けるなど、他の述語をコンテナに追加するようなものなどがあるでしょう。[sparql11-query]

以下に、http://example.org/container1/というURLで識別されるコンテナの最小コンテナ・トリプルをリクエストする例を示します。

http://example.org/container1/に対するリクエスト:

例17

GET /container1/ HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"

レスポンス:

例18

HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ce291112"
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD
Preference-Applied: return=representation
Transfer-Encoding: chunked

@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.

<http://example.org/container1/>
   a ldp:DirectContainer;
   dcterms:title "A Linked Data Platform Container of Acme Resources";
   ldp:membershipResource <http://example.org/container1/>;
   ldp:hasMemberRelation ldp:member;
   ldp:insertedContentRelation ldp:MemberSubject;
   dcterms:publisher <http://acme.com/>.

LDPでは、これらのプロパティーを更新するために、必要に応じてPATCHを用いることを推奨しています。PUTでは、コンテナ全体の状態を置き換えずにそれらを更新する便利さは得られません。

以下の項には、リンクト・データ・プラットフォーム・コンテナの規範的な条項が含まれています。

リンクト・データ・プラットフォームは、クライアントがLDPCsを発見する方法を定義しません。

このドキュメントが定義しているrel="type"に対する有効なコンテナ型URIは次のとおりです。

• http://www.w3.org/ns/ldp#BasicContainer - LDP基本コンテナの場合
• http://www.w3.org/ns/ldp#DirectContainer - LDP直接コンテナの場合
• http://www.w3.org/ns/ldp#IndirectContainer - LDP間接コンテナの場合

4.2.2項 HTTP GETにより、HTTP GETメソッドは必須であり、さらなる要件が5.2.1項 概要にあります。

[RFC7231]ではこのHTTPメソッドはオプションであり、この仕様では、LDPサーバーがこれをサポートする必要はありません。LDPサーバーがこのメソッドをサポートしている場合には、この仕様は、LDPCsに次の新しい要件を課します。

作成または更新にサーバーが課した制約は、クライアントに公言されなければなりません。

• リクエスト・ヘッダーでLDPR相互作用モデルが指定されている場合には、サーバーは新しく作成される資源のURIに対するその後のリクエストを、それがLDPRであるかのように処理しなければなりません（MUST）。サーバーが資源をLDPRとみなしたときには、LDPCの型を示すrdf:typeトリプルがコンテンツに含まれていても、クライアントは、LDPRsが定義している動作に依存することしかできません。つまり、サーバーのステートメントがコンテンツのものと矛盾している場合には、サーバーのステートメントの方が勝ります。
• リクエスト・ヘッダーでLDPC相互作用モデルが指定されている場合には、サーバーは新しく作成される資源のURIに対するその後のリクエストを、それがLDPCであるかのように処理しなければなりません（MUST）。
• この仕様では、その他のケースではサーバーの動作を制約しません。

クライアントは、資源の作成時に、要求された相互作用モデルを指定するために、レスポンスでサーバーが公言するために用いるものと同じ構文（つまり、HTTP Link）を用います。

注: この結果は、サーバーがサポートしている場合には、LDPCsを作成するためにLDPCsを使用できるということです。

非規範的な注: LDPは、資源が作成されたときに資源の相互作用モデルが固定されたとみなします。そのことは黒丸の言葉に反映されています。もしも実装が、作成後の相互作用モデルの変更を認めることでLDPを拡張すれば、それはLDPと互換性がある拡張とみなされ、上記のステートメントは、他の挙動は可能ではないと述べるのではなく、デフォルト相互作用モデルを制約するでしょう。

[RFC7231]ではこのHTTPメソッドはオプションであり、この仕様では、LDPサーバーがこれをサポートする必要はありません。LDPサーバーがこのメソッドをサポートしている場合には、この仕様はLDPCsに次の新しい要件を課します。

作成や更新にサーバーが制約を課す場合には、そのことをクライアントに公言しなければなりません。

[RFC7231]ではこのHTTPメソッドはオプションであり、この仕様では、LDPサーバーがこれをサポートする必要はありません。LDPサーバーがこのメソッドをサポートしている場合には、この仕様はLDPCsに次の新しい要件を課します。

非規範的な注: LDPサーバーは、[RFC7231]などの規範的な参考文献で記述しているとおり、追加の動作を実行できます。例えば、サーバーは、削除されたLDPRを参照しているメンバーシップ・トリプルを削除したり、参照されなくなったり、ある期間アクセスされないでいるなどの既知の資源に対して追加の掃除作業を行うことができます。

ある種のLDPメカニズムは、HTTPヘッダーに依存しており、HTTPでは、GETレスポンスと同じヘッダーをHEADレスポンスに含むことが推奨されることに注意してください。LDPサーバーは、OPTIONSに対するレスポンスに、HTTPヘッダーも含まなければなりません（4.2.8項 HTTP OPTIONSを参照）。したがって、HEADをサポートする実装者は、5.2.2項 HTTP GETと5.2.8項 HTTP OPTIONSも注意して読むべきです。

[RFC5789]ではこのHTTPメソッドはオプションであり、この仕様では、LDPサーバーがこれをサポートする必要はありません。LDPサーバーがこのメソッドをサポートしている場合には、この仕様はLDPCsに次の新しい要件を課します。

LDPRの作成や更新に対してサーバーが制約を課す場合には、そのことをクライアントに公言しなければなりません。

この仕様は、LDPCsに対して次の新しい要件をHTTP OPTIONSに課します。このメソッドのサポートは、LDPRsでは必須であり、LDPCsがLDP-RSの要件に準拠しているため、LDPCsでは必須であることに注意してください。

以下の項には、リンクト・データ・プラットフォーム基本コンテナの規範的な条項が含まれています。

次の項には、リンクト・データ・プラットフォーム直接コンテナの規範的な条項が含まれています。

次の項にはリンクト・データ・プラットフォーム間接コンテナの規範的な条項が含まれています。

この項は非規範的です。

LDPの読者、特に実装者は、規範的な参考文献の情報を理解していると思われますが、ワーキンググループは、あるポイントについて理解していることが特に重要であることに気付きました。参考文献として掲載している仕様に完全に精通している人にとっては、これらのポイントは明確かもしれませんが、専門家でない人がそのすべてが明確だと思うことはほとんどないことが経験から分かりました。この項では、それらについて列挙しており、これは、規範的な参考文献に書かれている情報を（非規範的に）言い直しているだけです。

この項は非規範的です。

この項は非規範的です。

この項は非規範的です。

これらのリンク関係が[RFC5988]6.2.1項によりIANAで登録されることを目的としています。

この項の内容は、元々[POWDER]の付録Dから取ってきたものを、現在の登録テンプレートに合うように変更したものです。LDPより前のdescribedbyに関するIANAリンク関係レジストリー・エントリーは[POWDER]の別の項を参照していますが、これは実質的に正誤表で更新されており、その項は実際にはリンク関係の規範的な定義ではありませんでした。[POWDER]に正誤表を取り入れたり、レジストリー・リンクを修正するなどの更新を行うことは期待できないため、登録を置き換えるというアプローチを取りました。

IANAリンク関係レジストリーにおけるレビュー、承認、収録のために、次のリンク関係をIANAに提出しています。

関係名:

describedby

説明:

A describedby Bという関係は、資源Bが資源Aの記述を提供するということを言明する。AまたはBのフォーマットや表現には制約はなく、どちらの資源にもさらなる制約はない。

参照:

W3Cリンクト・データ・プラットフォーム仕様。

注:

資源の記述は社会の影響を受けやすく、理解するためには処理が必要かもしれず、正確かどうかも分からない。記述資源の利用者は、ソースとデータ管理の継続性について知っているべきである。URI（RFC3986の7項）とIRI（RFC3987の8項）のセキュリティに関する留意点は、それらの資源の検索方法や検索するかどうかに関する利用者の判断に記述資源が影響する範囲に適用される。

この項は非規範的です。

HTTPを活用して実装されるプロトコルと同様に、実装は、関連する多くのセキュリティ関連の機能を利用すべきで、適切な特定のセキュリティ方針と矛盾するLDP操作を実行する必要はありません。例えば、システム的に危険なグラフ内のRDFステートメントをPUTメソッドで置き換えようとする未許可のリクエストに直面したときには、アプリケーションは、401（許可なし）のステータス・コードで応答して適切な認証が必要であることを示すことを検討できます。提供された認証が、特定のアクセス・コントロール方針の要件を満たさない場合には、アクセス・コントロール方針を満たさなかったことを示すために、403（アクセス拒否）のステータス・コードをクライアントに送り返すことができます。

この項は非規範的です。

この仕様の作成において、次の方々に、アイデア、フィードバック、レビュー、コンテンツ、批評およびインプットの提供でご協力いただきました。

Arnaud Le Hors (chair)、Alexandre Bertails、Andrei Sambra、Andy Seaborne、Antonis Loizou、Ashok Malhotra、Bart van Leeuwen、Cody Burleson、David Wood、Eric Prud'hommeaux、Erik Wilde、Henry Story、John Arwe、Kevin Page、Kingsley Idehen、Mark Baker、Martin P. Nally、Miel Vander Sande、Miguel Esteban Gutierrez、Nandana Mihindukulasooriya、Olivier Berger、Pierre-Antoine Champin、Raul Garcia Castro、Reza B'Far、Richard Cyganiak、Rob Sanderson、Roger Menday、Ruben Verborgh、Sandro Hawke、Serena Villata、Sergio Fernandez、Steve Battle、Steve Speicher、Ted Thibodeau、Tim Berners-LeeYves Lafon

この項は非規範的です。

変更履歴は、編集者の責任により、変更に関する短い要約を挿入するもので、変更された公開草案の見出しを付けて最近の変更から順に並べてあります。

勧告案からの重要な変更の要約。

• セキュリティに関する留意点における提供された認証に関するマイナーな言い替え
• リンクト・データ・プラットフォーム・コンテナのはじめにの例3の前に文章を追加

[DC-TERMS]

Dublin Core Metadata Initiative. Dublin Core Metadata Initiative Terms, version 1.1. 11 October 2010. DCMI Recommendation. URL: http://dublincore.org/documents/2010/10/11/dcmi-terms/.

[JSON-LD]

Manu Sporny; Gregg Kellogg; Markus Lanthaler. JSON-LD 1.0. 16 January 2014. W3C Recommendation. URL: http://www.w3.org/TR/json-ld/

[RFC2119]

S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

[RFC3864]

G. Klyne; M. Nottingham; J. Mogul. Registration Procedures for Message Header Fields. September 2004. Best Current Practice. URL: https://tools.ietf.org/html/rfc3864

[RFC3986]

T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986

[RFC3987]

M. Duerst; M. Suignard. Internationalized Resource Identifiers (IRIs). January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987

[RFC5023]

J. Gregorio, Ed.; B. de hOra, Ed.. The Atom Publishing Protocol. October 2007. Proposed Standard. URL: https://tools.ietf.org/html/rfc5023

[RFC5234]

D. Crocker, Ed.; P. Overell. Augmented BNF for Syntax Specifications: ABNF. January 2008. Internet Standard. URL: https://tools.ietf.org/html/rfc5234

[RFC5789]

L. Dusseault; J. Snell. PATCH Method for HTTP. March 2010. Proposed Standard. URL: https://tools.ietf.org/html/rfc5789

[RFC5988]

M. Nottingham. Web Linking. October 2010. Proposed Standard. URL: https://tools.ietf.org/html/rfc5988

[RFC6585]

M. Nottingham; R. Fielding. Additional HTTP Status Codes. April 2012. Proposed Standard. URL: https://tools.ietf.org/html/rfc6585

[RFC7230]

R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7230

[RFC7231]

R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7231

[RFC7232]

R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7232

[RFC7240]

J. Snell. Prefer Header for HTTP. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7240

[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/

[rdf-schema]

Dan Brickley; Ramanathan Guha. RDF Schema 1.1. 25 February 2014. W3C Recommendation. URL: http://www.w3.org/TR/rdf-schema/

[rdf11-concepts]

Richard Cyganiak; David Wood; Markus Lanthaler. RDF 1.1 Concepts and Abstract Syntax. 25 February 2014. W3C Recommendation. URL: http://www.w3.org/TR/rdf11-concepts/

[turtle]

Eric Prud'hommeaux; Gavin Carothers. RDF 1.1 Turtle. 25 February 2014. W3C Recommendation. URL: http://www.w3.org/TR/turtle/

[Accept-Post]

J. Arwe; S. Speicher; E. Wilde. The Accept-Post HTTP Header. Internet Draft. URL: http://tools.ietf.org/html/draft-wilde-accept-post

[HTML401]

Dave Raggett; Arnaud Le Hors; Ian Jacobs. HTML 4.01 Specification. 24 December 1999. W3C Recommendation. URL: http://www.w3.org/TR/html401

[LDP-PAGING]

S. Speicher; J. Arwe; A. Malhotra. Linked Data Platform Paging. Candidate Recommendation. URL: http://www.w3.org/TR/ldp-paging/

[LDP-Tests]

R. Garcia-Castro; F. Serena. Linked Data Platform 1.0 Test Cases. Editor's Draft of Working Group Note. URL: https://dvcs.w3.org/hg/ldpwg/raw-file/default/tests/ldp-testsuite.html

[LDP-UCR]

Steve Battle; Steve Speicher. Linked Data Platform Use Cases and Requirements. 13 March 2014. W3C Note. URL: http://www.w3.org/TR/ldp-ucr/

[LINKED-DATA]

Tim Berners-Lee. Linked Data Design Issues. 27 July 2006. W3C-Internal Document. URL: http://www.w3.org/DesignIssues/LinkedData.html

[POWDER]

Phil Archer; Kevin Smith; Andrea Perego. Protocol for Web Description Resources (POWDER): Description Resources. W3C Recommendation. URL: http://www.w3.org/TR/2009/REC-powder-dr-20090901/

[RFC4627]

D. Crockford. The application/json Media Type for JavaScript Object Notation (JSON). July 2006. Informational. URL: https://tools.ietf.org/html/rfc4627

[SPARQL-UPDATE]

Paul Gearon; Alexandre Passant; Axel Polleres. SPARQL 1.1 Update. 21 March 2013. W3C Recommendation. URL: http://www.w3.org/TR/sparql11-update/

[sparql11-query]

Steven Harris; Andy Seaborne. SPARQL 1.1 Query Language. 21 March 2013. W3C Recommendation. URL: http://www.w3.org/TR/sparql11-query/

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3