4.2.1.1 LDPサーバーは、少なくともHTTP/1.1適合サーバー[RFC7230]でなければなりません（MUST）。

4.2.1.2 LDPサーバーは、LDP-RSsとLDP-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）。

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.1 LDPサーバーは、LDPRsに対してHTTP GETメソッドをサポートしなければなりません（MUST）

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

4.2.4.1 既存の資源においてHTTP PUTが受け入れられていれば、LDPサーバーは、識別された資源の全ての永続的な状態を、リクエスト本文のエンティティー表現に置き換えなければなりません（MUST）。LDPサーバーは、LDPサーバー管理プロパティーを無視でき（MAY）、サーバーで特別な処理を行った場合（例えば、サーバーが値を上書きしたり、デフォルト値を提供する場合）には、dcterms:modifiedやdcterms: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により制約されません。

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.6.1 LDPサーバーは、HTTP HEADメソッドをサポートしなければなりません（MUST）。

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

4.2.8.1 LDPサーバーは、HTTP OPTIONSメソッドをサポートしなければなりません（MUST）。

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

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-RSsにRDF表現を提供しなければなりません（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-RSのrdf: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 GETでLDP-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.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-RSのapplication/ld+json表現で応答しなければなりません（MUST）[JSON-LD]。

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.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:Bag、rdf:Seqまたはrdf:ListのRDFコンテナ型を使用すべきではありません（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は次のとおりです。

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

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

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.1 LDPサーバーは、HTTP PUTによりLDPCの包含トリプルが更新されることを認めるべきではありません（SHOULD NOT）。サーバーがそのようなリクエストを受け取った場合には、409（衝突）のステータス・コードで応答すべきです（SHOULD）。

5.2.4.2 PUTによるLDPR作成を認めるLDPサーバーは、URIs再利用すべきではありません（SHOULD NOT）。

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.7.1 LDPサーバーは、LDPCの最小コンテナ・トリプルを更新するための望ましいメソッドとしてHTTP PATCHをサポートすることが推奨されます（RECOMMENDED）。

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

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

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、目的語がLDPCのmembership-constant-URIであるきっかり1つのトリプルを含まなければなりません（MUST）。一般的に、LDPCのURIはmembership-constant-URIですが、LDPではこれは必須ではありません。

5.4.1.4 個々のLDP直接コンテナ表現には、主語がLDPC URI、述語がldp:hasMemberRelationまたはldp:isMemberOfRelationであるきっかり1つのトリプルが含まれていなければなりません（MUST）。トリプルの目的語は、コンテナが用いるメンバーシップ・トリプルのパターンに基づいて、ldp:hasMemberRelationやldp:isMemberOfRelationなどの他の項により制約されます。

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

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

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-URIがbob#meであることを示します。この定義の1つの結論は、作成リクエストへのインプットとしてクライアントから提供されたドキュメントがRDFメディア・タイプを持っている場合にのみ、間接コンテナ・メンバーの作成はLDPによって明確に定義されているということです。

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

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

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

7.2.2.3 LDPサーバーが矛盾するヒントを持つリクエストを受け取ったときには、この仕様ではその動作に要件を課していません。リクエストを拒絶したり、ヒントのサブセットを適用して処理したり、サーバーにとって適切なその他の対応をしたりするのは自由です。[RFC7240]は、類似するリクエストを、矛盾するプリファレンスが全く指定されてないかのように扱うことを推奨しています。

7.2.2.4 この仕様では、クライアントがincludeとomitのパラメータと用いるために、次のURIを定義しています。これは、他のURIには意味を割り当てませんが、他の仕様では割り当てるかもしれません（MAY）。

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