要約

リンクト・データ・プラットフォーム(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プロセス・ドキュメントによって管理されています。

目次

1. はじめに

この項は非規範的です。

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

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

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

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

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

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

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

2. 用語

用語は、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:memberdcterms:isPartOfは、その代表的な例です。

リンクされている個々のコンテナは、どのパターンを用いるか、実際のmembership-predicatemembership-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以外で課される制約は含まれません

2.1 このドキュメントで用いる規定

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#>.

3. 適合性

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

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

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

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

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

4. リンクト・データ・プラットフォーム資源

4.1 はじめに

この項は非規範的です。

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

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

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

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

以下の項では、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に関するメタデータを保持している場合があります。

リンクト・データ・プラットフォーム資源の分類の例
1 異なる種類のLDPRsの例

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

リンクト・データ・プラットフォーム資源のクラスの図
2 リンクト・データ・プラットフォーム資源の種類のクラス関係

4.2 資源

4.2.1 概要

4.2.1.1 LDPサーバーは、少なくともHTTP/1.1適合サーバー[RFC7230]でなければなりません(MUST)。
4.2.1.2 LDPサーバーは、LDP-RSsLDP-NRsを混ぜて提供できます(MAY)。例えば、一般的に、LDPサーバーは、有用なRDF表現を持たないバイナリやテキストの資源を提供する必要があります。
4.2.1.3 LDPサーバーのレスポンスは、資源表現が含まれているレスポンスやHTTP HEADリクエストに対する成功のレスポンスに対して、エンティティー・タグ(弱いタグ、または、強いタグ)をレスポンスのETagヘッダー値として用いなければなりません(MUST)。
4.2.1.4 LDPRsを提供するLDPサーバーは、http://www.w3.org/ns/ldp#ResourceというターゲットURIを持つHTTP Linkヘッダーと、LDPRのHTTP Request-URI[RFC5988]に対して行われたリクエストのすべてのレスポンスにtypeというリンク関係の型(つまり、rel="type")を提供することによりLDPのサポートを公言しなければなりません(MUST)。

注: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は、個々に検査する必要があります。

4.2.1.5 LDPサーバーは、すでに資源が存在している場合にはHTTP Request-URIとなる[RFC3987]相対URI解決に対して、リクエストの結果として新しい資源が作成される場合にはその作成される資源のURIに対して、デフォルトの基底URIを割り当てなければなりません(MUST)。
4.2.1.6 LDPサーバーは、制約違反により不成功となったリクエストに対するすべてのレスポンスに、適切なコンテキストのURIを持つリンク・ヘッダー、http://www.w3.org/ns/ldp#constrainedByのリンク関係、および、制約[RFC5988]の集合を識別するターゲットURIを追加することにより、LDPRsを作成または更新するLDPクライアントの性能に何らかの制約を発行しなければなりません(MUST)。例えば、HTTP PUT、POSTまたはPATCHによる資源作成リクエストを拒否するサーバーは、そのようなリクエストに対し、このLinkヘッダーを4xxレスポンスで返すでしょう。同じLinkヘッダーを他のレスポンスに提供してもかまいません(MAY)。LDPは、リンクのターゲット資源の表現を定義もしないし、制約もしません。したがって、機械可読ドキュメントの方がクライアントのインタラクションをよりうまく実現できますが、自然言語の制約ドキュメントも認められています。適切なコンテキストのURIは、リクエストのセマンティクスとメソッドによって様々でありえます。レスポンスに別段の制約がなければ、デフォルト(実効リクエストURI)を用いるべきです(SHOULD)。

4.2.2 HTTP GET

4.2.2.1 LDPサーバーは、LDPRsに対してHTTP GETメソッドをサポートしなければなりません(MUST
4.2.2.2 LDPサーバーは、HTTP GETメソッドに対して、4.2.8HTTP OPTIONSで定義されているHTTPレスポンス・ヘッダーをサポートしなければなりません(MUST)。

4.2.3 HTTP POST

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

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

4.2.4 HTTP PUT

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

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

4.2.4.1 既存の資源においてHTTP PUTが受け入れられていれば、LDPサーバーは、識別された資源の全ての永続的な状態を、リクエスト本文のエンティティー表現に置き換えなければなりません(MUST)。LDPサーバーは、LDPサーバー管理プロパティーを無視でき(MAY)、サーバーで特別な処理を行った場合(例えば、サーバーが値を上書きしたり、デフォルト値を提供する場合)には、dcterms:modifieddcterms:creatorなどのその他のプロパティーを無視することができます(MAY)。LDPサーバーが、クライアントから提供されるデータと、資源に対してサーバーに保持されている既存の状態とのより洗練された統合をサポートしたい場合には、HTTP PUTではなく、HTTP PATCHを用いなければなりません(MUST)。
4.2.4.2 LDPサーバーは、サーバー固有の制約に関する詳細な知識がなくても、クライアントが資源を更新できるようにすべきです(SHOULD)。これは、LDPRsのシンプルな作成と更新を可能にする要件の結果です。
4.2.4.3 クライアントによる変更をサーバーが認めないプロパティーを変えようとする試みが、その他の点では有効なHTTP PUTリクエストと受け取られる場合には、LDPサーバーは、4xxのステータス・コード(一般的に、409 衝突)で応答してそのリクエストを失敗させなければなりません(MUST)。LDPサーバーは、どのプロパティーを持続できなかったかの情報が含まれている、対応するレスポンスの本文を提供すべきです(SHOULD)。4xxのレスポンス本文の形式は、LDPにより制約されません。
非規範的な注: クライアントは、例えば、GET/表現の更新/PUTというシーケンスの一部として、すでに資源の状態にあるプロパティーと同等のプロパティーを提供するかもしれず、そのPUTリクエストは、GETレスポンスと後のPUTリクエストとのLDPサーバー管理プロパティーが同じである限り機能することが意図されています。これは、一度設定されればクライアントに更新することをサーバーが認めないライトワンスのプロパティーのようなその他のケースとは対照的です。このようなプロパティーはクライアントおよび/またはサーバーの管理下にありますが、LDPよって制約されていないため、LDPサーバー管理トリプルではありません。
4.2.4.4 その他の点では有効なHTTP PUTリクエストに、未知のコンテンツのような、サーバーが持続しないことを選択したプロパティーが含まれていると受け取られる場合には、LDPサーバーは、適切な4xxのステータス・コード[RFC7231]で応答しなければなりません(MUST)。LDPサーバーは、どのプロパティーを持続できなかったかの情報が含まれている、対応するレスポンスの本文を提供すべきです(SHOULD)。4xxのレスポンス本文の形式は、LDPにより制約されません。LDPサーバーは、このアプリケーション固有の制約を4.2.1概要で記述しているとおりに提供します。
4.2.4.5 LDPクライアントは、クライアントがその表現を最後に検索したときから変更済み資源が更新されていないことを保証するために、HTTP If-MatchヘッダーとETagsを用いるべきです(SHOULD)。LDPサーバーは、衝突検出のためにHTTP If-MatchヘッダーとHTTP ETagsを要求すべきです(SHOULD)。LDPサーバーは、そのリクエスト[RFC7232]に他のエラーがないときにETagsがマッチングに失敗すれば、412(条件失敗)のステータス・コードで応答しなければなりません(MUST)。条件付きリクエストを要求するLDPサーバーは、前提条件の欠如が要求拒絶[RFC6585]の唯一の理由であるときには、428(前提条件要求)のステータス・コードで応答しなければなりません(MUST)。
4.2.4.6 LDPサーバーは、HTTP PUTを用いて、新しい資源の作成を認めることを選択できます(MAY)。

4.2.5 HTTP DELETE

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

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

4.2.6 HTTP HEAD

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

4.2.6.1 LDPサーバーは、HTTP HEADメソッドをサポートしなければなりません(MUST)。

4.2.7 HTTP PATCH

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

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

4.2.7.1 PATCHをサポートしているLDPサーバーは、サーバーがサポートしているパッチ・ドキュメント・メディア・タイプを列挙し、Accept-Patch HTTPレスポンス・ヘッダー[RFC5789]をHTTP OPTIONSリクエストに含まなければなりません(MUST)。

4.2.8 HTTP OPTIONS

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

4.2.8.1 LDPサーバーは、HTTP OPTIONSメソッドをサポートしなければなりません(MUST)。
4.2.8.2 LDPサーバーは、HTTPレスポンス・ヘッダーのAllowにおけるHTTPメソッドのトークンでLDPRのURLのHTTP OPTIONSリクエストに応答することにより、HTTPメソッドに対するサポートを示さなければなりません(MUST)。

4.3 RDF情報源

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

4.3.1 概要

4.3.1.1 個々のLDPのRDF情報源は、この項の制限に加え、4.2資源で定義されているとおり、適合LDP資源でもなければなりません(MUST)。LDPクライアントは、主語がLDP-RS、述語がrdf:type、目的語がldp:Resourceであるトリプルを推論できます(MAY)が、LDP-RS表現でこのトリプルを実現する必要はありません。
4.3.1.2 LDP-RSs表現には、明示的に設定されているrdf:typeが少なくとも1つあるべきです(SHOULD)。これによって、表現は、推論をサポートしていないクライアント・アプリケーションにとってずっと役立つものになります。
4.3.1.3 LDP-RSの表現は、リンクト・データ・プラットフォームRDF情報源に対して、ldp:RDFSourceというrdf:typeを持つことができます(MAY)。
4.3.1.4 LDPサーバーは、LDP-RSsRDF表現を提供しなければなりません(MUST)。LDP-RSのHTTP Request-URIは一般的に、レスポンス内のほとんどのトリプルの主語です。
4.3.1.5 LDP-RSsは、複製した語彙用語を独自に作成するのではなく、既存の語彙を再利用すべきです(SHOULD)。この一般的な規則に加えて、一部の個別のケースは、他の適合性規則でカバーされています。
4.3.1.6 LDP-RSsの述語は、できる限りダブリン・コア[DC-TERMS]、RDF[rdf11-concepts]、RDFスキーマ[rdf-schema]などの標準的な語彙を使用すべきです(SHOULD)。
4.3.1.7 アプリケーションや領域に関する特別な知識が不足している場合、LDPクライアントは、LDP-RSが、様々な目的語を持つ複数のrdf:typeトリプルを持つことができると想定しなければなりません(MUST)。
4.3.1.8 アプリケーションや領域に関する特別な知識が不足している場合、LDPクライアントは、与えられたLDP-RSrdf:typeの値は時間とともに変化する可能性があると想定しなければなりません(MUST)。
4.3.1.9 LDPクライアントは、すべての同じ型の異なる資源が、そのトリプルにおいて同じ述語の集合を持つわけではないという意味において、任意のサーバーの特定の型のLDP-RSに対する述語の集合がオープンであり、1つのLDP-RSの状態で用いられている述語の集合は定義済みの集合に制限されないと常に想定すべきです(SHOULD)。
4.3.1.10 LDPサーバーは、LDPが定義したコンテンツのサブセットを認識するためにLDPクライアントが推論を実装することを要求してはなりません(MUST NOT)。LDPをベースに構築されたその他の仕様は、クライアントが推論[rdf11-concepts]を実装することを要求できます。これは実質的に、このドキュメント内で特に記述されていなければ、LDPが定義したすべてのコンテンツが明示的に表わされていなければならないということを意味します。
4.3.1.11 LDPクライアントは、HTTP PUTを用いた更新の実行が目的である場合には、HTTP GETLDP-RSから検索したすべてのトリプルが述語を理解するかどうかが変わらないようにしなければなりません(MUST)。更新のためにHTTP PUTではなくHTTP PATCHを用いれば、クライアント[RFC5789]に対するこの負荷を回避できます。
4.3.1.12 LDPクライアントは、LDP定義のヒントを提供して、サーバーがレスポンスのコンテンツを最適化できるようにすることができます(MAY)。7.2望ましいリクエスト・ヘッダーのプリファレンスは、LDP-RSsに適用するヒントを定義しています。
4.3.1.13 LDPクライアントは、LDP定義のヒントなどのヒントを無視するLDPサーバーが生成したレスポンスを処理できなければなりません(MUST)。

4.3.2 HTTP GET

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

4.4 RDF情報源

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

4.4.1 概要

4.4.1.1 個々のLDP非RDF情報源は、4.2資源の適合LDP資源でもなければなりません(MUST)。LDP非RDF情報源は、RDF[rdf11-concepts]を用いてその状態を完全に表現できなくてもかまいません。
4.4.1.2 LDP非RDF情報源を提供するLDPサーバーは、http://www.w3.org/ns/ldp#NonRDFSourceというターゲットURIを持つHTTP Linkヘッダーと、LDP-NRのHTTP Request-URI[RFC5988]に対して行われたリクエストのレスポンスにtypeというリンク関係型(つまり、rel="type")を提供することによりそれを公言できます(MAY)。

5. リンクト・データ・プラットフォーム・コンテナ

5.1 はじめに

この項は非規範的です。

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

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

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

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

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

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

http://example.org/c1/に対するリクエスト:
例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直接コンテナがこの種のニーズを満たします。直接コンテナにより、メンバーシップ・トリプルが、コンテナ自身以外の主語を、一貫性のあるメンバーシップの値として用いること、および/または、アプリケーションの領域モデルの述語をメンバーシップの述語として用いることが可能になります。

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

http://example.org/netWorth/nw1/に対するリクエスト:
例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つの例を用いて、関連する例で示しています。

http://example.org/netWorth/nw1/に対するリクエスト:
例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直接コンテナです。直接コンテナは、メンバーシップ・トリプルを指定する方法に、メンバーシップと柔軟性の概念を追加します。

http://example.org/netWorth/nw1/assets/に対するリクエスト:
例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直接コンテナです。

http://example.org/netWorth/nw1/liabilities/に対するリクエスト:
例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を行うでしょう。

http://example.org/netWorth/nw1/liabilities/に対するリクエスト:
例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:asseto:liabilityのトリプルを追加すべきかどうかを特定できず、曖昧さが生じます。http://example.org/netWorth/nw1/assets/http://example.org/netWorth/nw1/liabilities/の別々のコンテナがあると、財産と債務の両方が作成され、適切な述語を用いてネット自己資本の資源にリンクできるようになります。クライアントが、メンバーおよび/または含まれている資源を列挙したい場合にも、同じような曖昧さが生じます。

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

http://example.org/netWorth/nw1/に対するリクエスト:
例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を行うでしょう。

http://example.org/netWorth/nw1/advisors/に対するリクエスト:
例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定義のコンテナの型を示します。

リンクト・データ・プラットフォーム・コンテナの型
3 リンクト・データ・プラットフォーム・コンテナの型のクラス関係

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

完了したリクエスト 結果
メンバーシップ 包含
LDPRLDP-BCで作成される 新しいトリプル: (LDPC, ldp:contains, LDPR) 同じ
LDPRLDP-DCで作成される 新しいトリプルは、作成されたLDPRLDP-RSをリンクする。LDP-RS URIはLDP-DCと同じでありえる 新しいトリプル: (LDPC, ldp:contains, LDPR)
LDPRLDP-ICで作成される 新しいトリプルは、コンテンツ指示されたURIにLDP-RSをリンクする 新しいトリプル: (LDPC, ldp:contains, LDPR)
LDPRが削除される メンバーシップ・トリプルが削除されうる (LDPC, ldp:contains, LDPR)というトリプルが削除される
LDPCが削除される トリプルとメンバー資源が削除されうる (LDPC, ldp:contains, LDPR)という形式のトリプルと含まれているLDPRsが削除されうる

5.1.1 最小コンテナ・トリプルのみの検索

多くのメンバーを有するコンテナの表現は大きいでしょう。例えば、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では、コンテナ全体の状態を置き換えずにそれらを更新する便利さは得られません。

5.2 コンテナ

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

5.2.1 概要

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

5.2.1.1 個々のリンクト・データ・プラットフォーム・コンテナは、適合リンクデータプラットフォームRDFソースでもなければなりません(MUST)。LDPクライアントは、主語がLDPC、述語がrdf:type、目的語がldp:RDFSourceであるトリプルを推論できます(MAY)が、LDPC表現でこのトリプルを実現する必要はありません。
5.2.1.2 LDPCの表現は、リンクト・データ・プラットフォーム・コンテナに対して、ldp:Containerというrdf:typeを持つことができます(MAY)。非規範的な注: LDP-RSのように、LDPCsは追加のタイプを持っている可能性があります
5.2.1.3 LDPC表現は、rdf:Bagrdf:Seqまたはrdf:ListRDFコンテナ型を使用すべきではありません(SHOULD NOT)。
5.2.1.4 LDPCsを提供するLDPサーバーは、サーバーがサポートするコンテナの型(下記を参照) と一致するターゲットURIを持つHTTP Linkヘッダーと、LDPCのHTTP Request-URIに対して行われたリクエストのすべてのレスポンスにtypeというリンク関係の型(つまり、rel="type")を提供することによりLDPのサポートを公言しなければなりません(MUST)。LDPサーバーは、追加のHTTP Link: rel="type"ヘッダーを提供できます(MAY)。対応するLDPR制約に関する注は、LDPCsに等しく適用されます。

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

5.2.1.5 例えば、特に大きなLDPCsに関しては、LDPCの表現で返されるトリプルに影響を与えるために、LDPサーバーは、どのLDP定義の状態のサブセットをクライアントが処理したいのかなどの、クライアントのLDP定義のヒントを尊重すべきです(SHOULD)。[LDP-PAGING]も参照してください。

5.2.2 HTTP GET

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

5.2.3 HTTP POST

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

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

5.2.3.1 LDPクライアントは、HTTP POSTのエンティティー本文として表現を既知のLDPCに送ることにより、メンバー資源を作成すべきです(SHOULD)。資源がうまく作成されれば、LDPサーバーは、201(作成)のステータス・コードと新しい資源のURLに設定されたLocationヘッダーで応答しなければなりません(MUST)。クライアントは、201(生成)の応答におけるレスポンスのエンティティー本文で表現を期待してはなりません。
5.2.3.2 LDPCに対するHTTP POSTリクエストが成功し、LDPRが作成された場合には、包含トリプルは、主語がLDPC URI、述語がldp:contains、目的語が新しく作成されたドキュメント(LDPR)に対するURIであるLDPCの状態に追加されなければなりません(MUST)。他のトリプルも追加できます。新しく作成されたLDPRは、新しく作成されたドキュメントが他のメソッドにより削除されるまでは、LDPCの含まれている資源の形で現れます。
5.2.3.3 LDPサーバーは、バイナリ資源などの、何らかの種類の資源の作成に対する非RDF表現(LDP-NRs)のHTTP POSTを受け入れることができます(MAY)。LDPCがこの動作をサポートしているかどうかをクライアントが発見できる方法の詳細については、Accept-Postの項を参照してください。
5.2.3.4 リクエストのエンティティー本文のRDF表現から資源をうまく作成できるLDPサーバーは、クライアントのリクエストされたインタラクション・モデルを尊重しなければなりません(MUST)。リクエストされたインタラクション・モデルを尊重できなければ、サーバーはリクエストを失敗させなければなりません(MUST)。
  • リクエスト・ヘッダーでLDPRインタラクション・モデルが指定されている場合には、サーバーは新しく作成される資源のURIに対するその後のリクエストを、それがLDPRであるかのように処理しなければなりません(MUST)。サーバーが資源をLDPRとみなしたときには、LDPCの型を示すrdf:typeトリプルがコンテンツに含まれていても、クライアントは、LDPRsが定義している動作に依存することしかできません。つまり、サーバーのステートメントがコンテンツのものと矛盾している場合には、サーバーのステートメントの方が勝ります。
  • リクエスト・ヘッダーでLDPCインタラクション・モデルが指定されている場合には、サーバーは新しく作成される資源のURIに対するその後のリクエストを、それがLDPCであるかのように処理しなければなりません(MUST)。
  • この仕様では、その他のケースではサーバーの動作を制約しません。

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

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

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

5.2.3.5 POSTによるLDP-RSsの作成を認めるLDPサーバーは、text/turtle[turtle]という値のContent-Typeリクエスト・ヘッダーでリクエストのエンティティー本文を囲むことで、クライアントによる新しいメンバーの作成を認めなければなりません(MUST)。
5.2.3.6 LDPサーバーは、リクエストにエンティティー本文がある場合には、リクエスト表現のフォーマットを決定するためにContent-Typeリクエスト・ヘッダーを用いるべきです(SHOULD)。
5.2.3.7 POSTによりLDP-RSを作成するLDPサーバーは、リクエストのエンティティー本文のLDP-RS表現内のトリプルの主語に対する空値の相対URIを、リクエスト本文のエンティティーを識別していると解釈しなければなりません(MUST)。一般的に、そのエンティティーは「作成される」LDPRに対するモデルであるため、主語が空値の相対URIであるトリプルは、主語が作成された資源である、作成された資源のトリプルになります。
5.2.3.8 LDPサーバーは、クライアントのヒントがない場合には、サーバー・アプリケーション固有の規則を用いて、作成された資源にURIを割り当てるべきです(SHOULD)。
5.2.3.9 LDPサーバーは、アプリケーション固有の制約に関する詳細な知識がなくても、クライアントが新しい資源を作成できるようにすべきです(SHOULD)。これは、LDPRsのシンプルな作成と更新を可能にする要件の結果です。LDPサーバーは、これらのアプリケーション固有の制約を4.2.1概要で記述しているとおりに提供します。
5.2.3.10 LDPサーバーは、[RFC5023]で定義されているとおりにHTTP Slugヘッダーを用いて、POSTで作成された資源のURIをクライアントが提案することを認めることができます(MAY)。LDPはこの方法に新しい要件を追加しないため、それが存在していれば、資源URIに関するサーバーの最終的な選択に取り入れる望ましい文字列を提供する、サーバーに対するクライアントのヒントとして機能します。
5.2.3.11 POSTによるメンバー作成を認めるLDPサーバーは、URIを再利用すべきではありません(SHOULD NOT)。
5.2.3.12 LDP-NRがうまく作成されたときに(201(作成)のHTTPステータス・コード、Locationレスポンス・ヘッダーでのURI表示)、LDPサーバーは、関連するLDP-RSを作成し、新しく作成されたLDP-NRに関するデータを含むことができます(MAY)。LDPサーバーは、この関連するLDP-RSを作成した場合には、新しく作成されたLDP-NRを識別するターゲットURIを識別するコンテキストURIを持つHTTP Linkヘッダー(効果的なリクエストURIではなく)、describedbyのリンク関係の値、および、関連するLDP-RS資源[RFC5988]を追加して、レスポンス内の自身の位置を示さなければなりません(MUST)。
5.2.3.13 POSTをサポートしているLDPサーバーは、サーバーがサポートするPOSTリクエスト・メディア・タイプを列挙して、HTTP OPTIONSレスポンスにAccept-Postレスポンス・ヘッダーを含まなければなりません(MUST)。LDPは、新しい資源を作成するためにPOSTの使用を指定するだけですが、サーバーは他のセマンティクスを持つPOSTリクエストを受け入れることができます。「作成のためのPOST」は一般的なインタラクション・パターンですが、LDPサーバーにリクエストを行うときであっても、LDPクライアントは、すべての成功したPOSTリクエストの結果として新しい資源が作成されることが保証されません。クライアントは、どのPOSTリクエスト(もしあれば)が「新しい資源を作成する」というセマンティクスを持っているかの知識に関し、外部の情報に依存しなければなりません。LDPサーバーのこの要件は、ヘッダー登録で課されるものよりも意図的に強くなっています。POSTをサポートするすべての既存の資源が突然新しいヘッダーを返すことを期待したり、POSTを制約しているすべての新しい仕様がその存在に気づき、それを要求することは現実的ではありませんが、LDPなどの新しい仕様では妥当な要件です。
5.2.3.14 POSTによるLDP-RSsの作成を認めるLDPサーバーは、application/ld+json[JSON-LD]という値のContent-Typeリクエスト・ヘッダーでリクエストのエンティティー本文を囲んでクライアントが新しいメンバーを作成することを認めなければなりません(MUST)。

5.2.4 HTTP PUT

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

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

5.2.4.1 LDPサーバーは、HTTP PUTによりLDPC包含トリプルが更新されることを認めるべきではありません(SHOULD NOT)。サーバーがそのようなリクエストを受け取った場合には、409(衝突)のステータス・コードで応答すべきです(SHOULD)。
5.2.4.2 PUTによるLDPR作成を認めるLDPサーバーは、URIs再利用すべきではありません(SHOULD NOT)。

5.2.5 HTTP DELETE

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

5.2.5.1 含まれているLDPRが削除されれば、LDPCサーバーは、対応する包含トリプルも削除しなければならず(MUST)、これには、含んでいるLDPCから削除されたLDPRを削除する効果があります。
非規範的な注: LDPサーバーは、[RFC7231]などの規範的な参考文献で記述しているとおり、追加の動作を実行できます。例えば、サーバーは、削除されたLDPRを参照しているメンバーシップ・トリプルを削除したり、参照されなくなったり、ある期間アクセスされないでいるなどの既知の資源に対して追加の掃除作業を行うことができます。
5.2.5.2 含まれているLDPRが削除され、LDPCサーバーが関連するLDP-RSを作成した場合(LDPC POSTの項を参照)、LDPCサーバーは、それが作成した関連するLDP-RSも削除しなければなりません(MUST)。

5.2.6 HTTP HEAD

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

5.2.7 HTTP PATCH

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

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

5.2.7.1 LDPサーバーは、LDPC最小コンテナ・トリプルを更新するための望ましいメソッドとしてHTTP PATCHをサポートすることが推奨されます(RECOMMENDED)。

5.2.8 HTTP OPTIONS

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

5.2.8.1 request-URI関連するLDP-RSを伴ったLDP-NRであるリクエストに応答する場合には、LDPCサーバーは、作成レスポンスで必要とされるものと同じHTTP Linkレスポンス・ヘッダーを提供しなければなりません(MUST)。

5.3 基本

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

5.3.1 概要

5.3.1.1 個々のLDP基本コンテナは、この項の以下の制限に加え、5.2コンテナの適合LDPコンテナでもなければなりません(MUST)。LDPクライアントは、主語がLDP基本コンテナ、述語がrdf:type、目的語がldp:Containerであるトリプルを推定できます(MAY)が、LDP-BC表現でこのトリプルを実現する必要はありません。

5.4 直接

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

5.4.1 概要

5.4.1.1 個々のLDP直接コンテナは、 次の制限に加え、5.2コンテナの適合LDPコンテナでもなければなりません(MUST)。LDPクライアントは、主語がLDP直接コンテナ、述語がrdf:type、目的語がldp:Containerであるトリプルを推定できます(MAY)が、LDP-DC表現でこのトリプルを実現する必要はありません。
5.4.1.2 LDP直接コンテナは、アプリケーション語彙に使用すべき明確な述語がない場合には、ldp:member述語をLDPCメンバーシップ述語として用いるべきです(SHOULD)。LDPCの状態には、どの資源がそのメンバーであるかの情報が、一貫性のあるパターンに従ったメンバーシップ・トリプルの形式で含まれています。LDPCの状態には、メンバーシップ述語、コンテナ・メンバーシップ・トリプル(membership-constant-URI)で用いられるその他の一貫性のあるメンバーシップ値、URIがメンバーシップ・トリプルに出現する位置(主語または目的語)をクライアントが識別するのに十分な情報が含まれています。メンバー資源は、LDPRやその他の、URIで識別されるあらゆる種類の資源でありえます。
5.4.1.3 個々のLDP直接コンテナ表現には、主語がLDPC URI、述語がldp:membershipResource、目的語がLDPCmembership-constant-URIであるきっかり1つのトリプルを含まなければなりません(MUST)。一般的に、LDPCのURIはmembership-constant-URIですが、LDPではこれは必須ではありません。
5.4.1.4 個々のLDP直接コンテナ表現には、主語がLDPC URI、述語がldp:hasMemberRelationまたはldp:isMemberOfRelationであるきっかり1つのトリプルが含まれていなければなりません(MUST)。トリプルの目的語は、コンテナが用いるメンバーシップ・トリプルのパターンに基づいて、ldp:hasMemberRelationldp:isMemberOfRelationなどの他の項により制約されます。
5.4.1.4.1 メンバーシップ・トリプルのパターンが( membership-constant-URI , membership-predicate , member-derived-URI )であるLDP直接コンテナには、主語がLDPC URI、述語がldp:hasMemberRelation、目的語がmembership-predicateのURIであるきっかり1つのトリプルが含まれていなければなりません(MUST)。
5.4.1.4.2 メンバーシップ・トリプルのパターンが( member-derived-URI , membership-predicate , membership-constant-URI )であるLDP直接コンテナには、主語がLDPC URI、述語がldp:isMemberOfRelation、目的語がmembership-predicateのURIであるきっかり1つのトリプルが含まれていなければなりません(MUST)。
5.4.1.5 LDP直接コンテナは、( LDPC URI, ldp:insertedContentRelation , ldp:MemberSubject )というトリプルを持っているかのように動作を行わなければなりません(MUST)が、LDPはLDP-DC表現でこのトリプルを実現するための要件を課しません。ldp:MemberSubjectという値は、member-derived-URIが、それが作成するドキュメントにサーバーが割り当てたURIであることを意味します。例えば、クライアントが、コンテナにコンテンツをPOSTして、そのコンテナに新しいLDPRを作成させた場合、ldp:MemberSubjectは、member-derived-URIが、新しく作成されたLDPRに割り当てられたURIであるということを示します。

5.4.2 HTTP POST

5.4.2.1 LDPCに対するHTTP POSTリクエストが成功し、LDPRが作成された場合には、LDPCは、その追加を反映するために、そのメンバーシップ・トリプルを更新しなければならず(MUST)、結果として作成されたメンバーシップ・トリプルは、それが提供するLDP定義の述語と整合性がなければなりません(MUST)。LDP直接コンテナのメンバーシップ・トリプルは、他の方法で更新することもできます(MAY)。

5.4.3 HTTP DELETE

5.4.3.1 元々LDP-DCにより作成されたメンバーシップ・トリプルの目的語で識別されていたLDPRが削除された場合、LDPCサーバーは、対応するメンバーシップ・トリプルも削除しなければなりません(MUST) 。

5.5 間接

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

5.5.1 概要

5.5.1.1 個々のLDP間接コンテナは、次の制限に加え、5.4直接で記述しているとおり、適合LDP直接コンテナでもなければなりません(MUST)。LDPクライアントは、主語がLDP間接コンテナ、述語がrdf:type、目的語がldp:Containerであるトリプルを推定できます(MAY)が、LDP-IC表現でこのトリプルを実現する必要はありません。
5.5.1.2 LDP間接コンテナは、主語がLDPC URI、述語がldp:insertedContentRelation、目的語のICRがコンテナ内のメンバーシップ・トリプルmember-derived-URIの選択方法を記述したきっかり1つのトリプルを含まなければなりません(MUST)。member-derived-URIは、作成リクエストに対するインプットとしてクライアントから提供されたドキュメントのトリプル( S, P, O )から得られます。ICRの値がPであれば、member-derived-URIはOです。LDPは、述語Pが含まれている2つ以上のトリプルがクライアントのインプットに存在するときの動作を定義していません。例えば、クライアントが、コンテナにRDFコンテンツをPOSTして、コンテナに新しいLDP-RSを作成させ、そのコンテンツに( <> , foaf:primaryTopic , bob#me )というトリプルが含まれている場合、foaf:primaryTopicは、member-derived-URIbob#meであることを示します。この定義の1つの結論は、作成リクエストへのインプットとしてクライアントから提供されたドキュメントがRDFメディア・タイプを持っている場合にのみ、間接コンテナ・メンバーの作成はLDPによって明確に定義されているということです。

5.5.2 HTTP POST

5.5.2.1 ldp:insertedContentRelationトリプルにldp:MemberSubject以外の目的語があり、新しい資源を作成するLDPCsは、主語がコンテナのURI、述語がldp:contains、目的語が新しく作成された資源のURI(この場合、member-derived URIとは異なる)であるコンテナにトリプルを追加しなければなりません(MUST)。このldp:containsトリプルは、コンテナから新しく作成された資源への唯一のリンクとなりえる場合があります。

6. 規範的な参考文献の重要情報

この項は非規範的です。

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

6.1 World Wide Webのアーキテクチャ

この項は非規範的です。

参考文献: [WEBARCH]

6.1.1 LDPCメンバーシップは排他的ではありません。これは、同じ資源(LDPRであろうとなかろうと)が2つ以上のLDPCのメンバーでありえるということを意味します。

6.1.2 メンバーが作成されるメカニズム(POSTPUTなど)に関わらず、LDPサーバーはURIを再利用すべきではありません。LDPCサーバーが資源を削除した後に、URIが同じ資源を識別していれば(ただし、ウェブ・アーキテクチャと整合性があるときにのみ)、そのURIを再利用するようなケースはあります。すべての失敗したシナリオにおいて、再利用しないことで実装を完全に保証することは困難ですが、URIを再利用すると、クライアントにとってあいまいな表現が作成されるため、最も避けるべきです。

6.2 HTTP 1.1

この項は非規範的です。

参考文献: [RFC7230], [RFC7231], [RFC7232]

6.2.1 LDPサーバーは、この仕様に準拠する必要がある表現を越える表現をサポートできます。それは、N3やNTriplesなどの他のRDFフォーマットでありえますが、HTML[HTML401]やJSON[RFC4627]などの非RDFフォーマットもおそらく一般的でしょう。フォーマットを選択するためには、HTTP内容交渉([RFC7231]3.4項 - 内容交渉)を用います。

6.2.2 メソッドがこの仕様の規範的な要件と矛盾しない限り、例えば、アプリケーション固有の方法、SPARQL UPDATEなど[SPARQL-UPDATE]などのこのドキュメントで定義していないメソッドを用いてLDPRsを作成、更新、削除できます。

6.2.3 LDPサーバーは、成功したHTTP DELETEリクエストに対するレスポンス内のRequest-URIで識別される資源を削除します。このリクエストの後には、同じRequest-URIのHTTP GETの結果として、通常、404(存在不明)か410(消滅)のステータスコードが生じます(HTTPでは、その他も認められていますが)。

6.2.4 特に、安全ではないメソッドが用いられたときには、LDPサーバーは、HTTPリクエストの結果として他の資源の状態を変更できます([RFC7231]4.2.1項)。例えば、成功したHTTP DELETEリクエストの結果として主語や目的語が削除された資源であるような他の資源のトリプルをサーバーが削除することは認められます。LDPサーバーがこれをしないことも認められており、それが一般的です – サーバーの動作は様々である可能性があり、したがって、LDPクライアントはそれに依存できません。

6.2.5 LDPサーバーは、自身の資源の更新(特に部分的な置換)を認めるために、HTTP PATCHを実装できます。このドキュメントやPATCH[RFC5789]の定義には必須のPATCHドキュメント形式はありません。

6.2.6 Content-Typeリクエスト・ヘッダーがリクエストにない場合には、LDPサーバーは、エンティティー本文の内容を調査してコンテンツ・タイプを推測する可能性があります([RFC7231]3.1.1.5項)。

6.3 RDF

この項は非規範的です。

参考文献: [rdf11-concepts]

6.3.1 LDPRの状態は、任意の主語を持つトリプルを持つことができます。LDPRの表現を検索するために用いられるURLがそのトリプルの主語である必要はありません。

6.3.2 LDPCの表現には、主語がコンテナのメンバーである、または、(メンバーがRDF表現を持っている場合には)メンバーの表現に由来する任意の数の追加のトリプルを含むことができます。これにより、クライアントがメンバーに個々にGETを行う必要がなくなり、LDPサーバーがクライアントにメンバーに関する情報を提供できるようになります。

6.3.3 LDPRの状態には、rdf:type述語を持つ2つ以上のトリプルを含むことができます。

7. HTTPヘッダー定義

7.1 Accept-Postレスポンス・ヘッダー

LDPワーキンググループは、この項で記述している機能の組み込みを提案します。

Accept-Postヘッダーには、このIETF草案[Accept-Post]で概説しているとおり、LDPを越える適応性があります。

この仕様では、HTTP POSTリクエストでサーバーが受け入れるドキュメント・フォーマットを指定するために用いるAccept-Postという新しいHTTPレスポンス・ヘッダーを導入しています。これは、[RFC5789]で定義されているAccept-Patchヘッダーをまねて作られています。

7.1.1 [RFC7231]の1.2項で定義されているABNF構文を用いたAccept-Postの構文は次のとおりです。

Accept-Post = "Accept-Post" ":" # media-range

Accept-Postヘッダーは、[RFC7231]の5.3.2項で定義されているとおり、メディア・レンジ(オプションのパラメータ付き)のコンマ区切りのリストを規定します。Accept-Postヘッダーは、実際には、Accept-Postaccept-params BNF生成規則があてはまらないため、HTTP Acceptヘッダーからオプションのaccept-params BNF生成規則を除いたものと同じ構文を用います。

7.1.2 Accept-Post HTTPヘッダーは、POSTメソッドの使用をサポートする資源のOPTIONSレスポンスに出現すべきです(SHOULD)。任意のメソッドのレスポンスにAccept-Postヘッダーが存在していれば、それは、Request-URIで識別される資源でPOSTが認められていることを示暗します。このヘッダーに特定のドキュメント・フォーマットが存在していれば、それは、その特定のフォーマットがRequest-URIで識別される資源に対するPOSTリクエストで認められていることを示します。

7.1.3 IANA登録テンプレート

Accept-Postレスポンス・ヘッダーは、永久レジストリーに追加されなければなりません([RFC3864]を参照)。

ヘッダー・フィールド名: Accept-Post

適用可能なプロトコル: HTTP

執筆/変更管理者: W3C

仕様ドキュメント: この仕様

7.2 望ましいリクエスト・ヘッダーのプリファレンス

7.2.1 要約

この仕様では、HTTP Preferリクエスト・ヘッダーのreturn=representationプリファレンス[RFC7240]に新しいパラメータを導入しており、それは、クライアントのニーズに最も適したレスポンスをサーバーが生成するために役立つヒントを提供するためにクライアントがオプションで用います。LDP定義のパラメータは、クライアント・アプリケーションが興味を持ち、受け入れられれば処理されそうな資源の状態の部分を提案します。多くの関連するドキュメントおよび/またはメンバーを持つLDPコンテナは大きな表現を有しており、クライアント・アプリケーションの多くは、LDPCの情報のサブセットのみ(例えば、メンバーシップ・トリプルのみ、または、包含トリプルのみ)を処理することに興味があるかもしれず、その結果、サーバー、クライアント、ネットワークの処理が大きく節約される可能性があります。

非規範的な注: LDPサーバーの実装者は、[RFC7240]の2項で記述されているとおり、キャッシュに対するこれらのプリファレンスの効果を慎重に検討すべきです。

非規範的な注: [RFC7240]は、レスポンスのコンテンツのヒントの尊重に関して、他の方法ではサーバーの動作をクライアントが決定できないときには、サーバー実装者がPreference-Appliedレスポンス・ヘッダーを含むことを推奨しています。では、ヘッダーが不要ないくつかのケースについて説明しています。

7.2.2 仕様

7.2.2.1 includeヒントは、クライアントが表現に含めたいLDPRのコンテンツのサブセットを定義します。HTTP Preferリクエスト・ヘッダーのreturn=representationプリファレンス[RFC7240]のincludeパラメータの構文は次のとおりです。
include-parameter = "include" *WSP "=" *WSP ldp-uri-list

このとき、WSPは空白[RFC5234]、ldp-uri-listはダブル引用符で囲まれた空白で区切られた順序不同のURIの集合で、そのABNFについては下記で示しています。一般的なプリファレンスであるBNF[RFC7240]では、引用符付きの文字列かトークンのいずれかが、プリファレンス・パラメータの値として認められています。LDPは、下記の形式の引用符付き文字列であるときにのみ、値に意味を割り当てます。

ldp-uri-list = DQUOTE *WSP URI *[ 1*WSP URI ] *WSP DQUOTE

このとき、DQUOTEはダブル引用符[RFC5234]、URIはオプションのフラグメント構成要素[RFC3986]を持つ絶対URIです。

7.2.2.2 omitヒントは、クライアントが表現から省略したいLDPRのコンテンツのサブセットを定義します。HTTP Preferリクエスト・ヘッダーのreturn=representationプリファレンス[RFC7240]のomitパラメータの構文は次のとおりです。
omit-parameter = "omit" *WSP "=" *WSP ldp-uri-list

このとき、WSPldp-uri-listは、上記のincludeで定義されているとおりです。

7.2.2.3 LDPサーバーが矛盾するヒントを持つリクエストを受け取ったときには、この仕様ではその動作に要件を課していません。リクエストを拒絶したり、ヒントのサブセットを適用して処理したり、サーバーにとって適切なその他の対応をしたりするのは自由です。[RFC7240]は、類似するリクエストを、矛盾するプリファレンスが全く指定されてないかのように扱うことを推奨しています。
7.2.2.4 この仕様では、クライアントがincludeomitのパラメータと用いるために、次のURIを定義しています。これは、他のURIには意味を割り当てませんが、他の仕様では割り当てるかもしれません(MAY)。
包含トリプル http://www.w3.org/ns/ldp#PreferContainment
メンバーシップ・トリプル http://www.w3.org/ns/ldp#PreferMembership
最小コンテナ・トリプル http://www.w3.org/ns/ldp#PreferMinimalContainer
    または、同等だれども廃止された用語
http://www.w3.org/ns/ldp#PreferEmptyContainer

非規範的な注: 現在定義されているすべてのURIは、LDP-RSsのみと(実際には、LDPCsのみと)整合がありますが、将来的には、他のスコープの適応性を持つ追加のURIを定義できる可能性があります。

7.2.3

この項は非規範的です。

次のようなコンテナを想定する場合

例19
# The following is the representation of
#   http://example.org/netWorth/nw1/assets/

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

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

<http://example.org/netWorth/nw1/>
   a o:NetWorth;
   o:asset <a1>, <a3>, <a2>.

<a1>
   a o:Stock;
   o:marketValue 100.00 .
<a2>
   a o:Cash;
   o:marketValue 50.00 .
<a3>
   a o:RealEstateHolding;
   o:marketValue 300000 .

コンテナに関する情報(例えば、どのメンバーシップ述語を使いるか)にのみ興味があるクライアントは、Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"というGETリクエストに関するヒントを用いるかもしれません。

このヒントを尊重するサーバーは、Preference-Applied: return=representationというHTTPヘッダーが含まれている次のレスポンス、および、この表現を返します。

http://example.org/netWorth/nw1/assets/に対するリクエスト:
例20
GET /netWorth/nw1/assets/ HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"
レスポンス:
例21
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#>.
@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:insertedContentRelation ldp:MemberSubject.

コンテナに関する情報にのみ興味があるクライアント(前述と同じ)は、代わりに、Prefer: return=representation; omit="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferContainment"というヒントを用いるかもしれません。注: この2つを同等のものとして扱うことは推奨されません。現在はこのomitパラメータ値は前述のincludeパラメータ値と同等ですが、最小コンテナ・トリプルの定義のせいで、将来的には同等でなくなるかもしれません。クライアントはincludeパラメータを優先的に用いるべきです。なぜならば、その方がより正確にニーズが伝えられるからです。

このヒントを尊重するLDP 1.0サーバーは、次のレスポンスを返します。LDPのより新しいバージョンを実装しているサーバーは、実質的に違うレスポンスを返すかもしれません。

http://example.org/netWorth/nw1/assets/に対するリクエスト:
例22
GET /netWorth/nw1/assets/ HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; omit="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferContainment"
レスポンス:
例23
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#>.
@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:insertedContentRelation ldp:MemberSubject.

コンテナとそのメンバーシップに関する情報にのみ興味があるクライアント(例えば、どのメンバーシップ述語を用いるか)は、Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferMinimalContainer"というGETリクエストに関するヒントを用いるかもしれません。

このヒントを尊重するサーバーは、(少なくとも)次のレスポンスを返し、おそらくこれのみでしょう(特にリクエストされていない場合には、包含トリプルは省略されるでしょう)。クライアントが、ヒントが尊重されていることをコンテンツから検出できるこの例のようなケースでは(下記の表現では、dcterms:titleo:assetの述語の存在がこれを示す)、サーバーは、200(OK)レスポンスなどの多くの一般的なケースではPreference-Appliedレスポンス・ヘッダーを含む必要はありません。ステータス・コード303のような、その他のケースでは、303レスポンス・エンティティーが、短いハイパーテキストの注記(Locationヘッダー・フィールド[RFC7231]で提供されている同じURI参照に対するハイパーリンクを持つもの)ではなく、Location URIで識別される資源の表現であることをクライアントが知るために、依然としてヘッダーは必要です。

http://example.org/netWorth/nw1/assets/に対するリクエスト:
例24
GET /netWorth/nw1/assets/ HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferMinimalContainer"
レスポンス:
例25
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#>.
@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:insertedContentRelation ldp:MemberSubject.

<http://example.org/netWorth/nw1/>
   a o:NetWorth;
   o:asset <a1>, <a3>, <a2>.

9. セキュリティに関する留意点

この項は非規範的です。

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

A. 謝辞

この項は非規範的です。

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

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

B. 更新履歴

この項は非規範的です。

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

要約

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

C. 参考文献

C.1 規範的な参考文献

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

C.2 参考情報の参考文献

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