要約

このドキュメントは、URLのアドレスで指定可能な別個のページ資源にレスポンスを分割することにより、クライアントとサーバーが大きなリンクト・データ・プラットフォーム資源表現を効率的に検索可能となるHTTPベースのプロトコルについて記述しています。

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

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

ワーキンググループは、提起されたすべての問題に対応し、リンクト・データ・プラットフォーム[LDP]からLDPページングを分離するという決定を含む、その他の本質的な変更が行われました。テストスイートの開始も利用可能となりました[LDP-PAGING-TESTSUITE]。

この仕様は、以前に勧告候補（CR）として公表されました。現在の憲章のもとで残された時間内にCRの終了基準を満たすには実装が不十分であったため、ワーキンググループは、W3C勧告トラックから外し、将来の参照のためのW3Cノートとして公表することにしました。このドキュメントは、部分的または全体的に、将来別のWGが再利用できるかもしれませんし、できないかもしれません。

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

Please see the Working Group's implementation report.

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

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

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

目次

1. はじめに

この項は非規範的です。

この仕様では、大きなページ付きHTTP資源の状態を、より小さな負荷でサーバーが表現できるように、小さなサブセット資源（ページ）のリストとして利用できるように広く再利用可能なパターンを提供します。ページ付き資源は、LDP資源（LDPRs）[LDP]でなければなりません。任意のLDPRにページングを行えますが、順序付けなどのページングに関するある側面が明確に定義されているのは、LDP-RSsやLDPCsなどの、LDPRsの特定のサブクラスに対してのみです。

クライアントがページ付き資源を検索しようとした時には、 サーバーは、「先頭ページ」資源にクライアントをリダイレクトするか、クライアントのリクエストのプレファレンスやサーバー性能に応じて、そのレスポンス内で「先頭ページ」資源の表現を提供します。レスポンスには、他のページへのリンクがシーケンスとして含まれ、 その後のページでも同様です。ページングに対応しているクライアントは、LDP-RSのページの結合方法や、場合によっては他のLDPRsの結合方法について（他の仕様により）知っています。LDPページングは、例えば、クライアントがページのトラバースをできる限り早く断念できるように、ページ付き資源の変更をクライアントが知ることができるメカニズムを定義します。ページングの詳細な例は、4項 メッセージ交換のページングの例で示しています。

ページ付き資源がLDPCでもある場合には、サーバーが想定通りにページにメンバーを割り当てて、その割り当てアルゴリズムをクライアントに伝達できれば、何らかの効率の向上が望めます。7項 リンクト・データ・プラットフォーム・コンテナは、この一般的な実装アルゴリズムを扱うために、ページへのメンバー割り当てのソート順序を伝達する機能を定義しています。

前後関係や背景に関しては、リンクト・データ・プラットフォーム・ユース・ケースおよび要件[LDP-UCR]を読むと有用かもしれません。

2. 用語

2.1 リンクト・データ・プラットフォームから再利用した用語

この項は非規範的です。これは、読者の利便性のために、[LDP]で形式的に定義されている用語のサブセットをまとめたものです。

LDPサーバー
LDPRsとLDPCsの提供時に、[LDP]で定義されている規則に従った適合HTTPサーバー[RFC7230]

LDPクライアント
LDPサーバーとの相互作用時に、[LDP]で定義されている規則に従った適合HTTPクライアント[RFC7230]

リンクト・データ・プラットフォーム資源 (LDPR)
[LDP]のパターンと規定に準拠した方法で状態を表すHTTP資源

リンクト・データ・プラットフォームRDF情報源 (LDP-RS)
状態をすべてRDFで表すLDPR [LDP]

リンクト・データ・プラットフォーム・コンテナ (LDPC)
メンバーシップ・トリプルと包含トリプルでリンクされたLDPRsの集合を表すLDP-RS [LDP]

メンバーシップ・トリプル
LDPCのメンバーを列挙するトリプル[LDP]

包含トリプル
LDPCにより作成されたけれども未削除であるドキュメントを列挙している（LDPCにより維持されている）トリプルの集合[LDP]

2.2 この仕様で規範的に定義している用語

以下の用語は、W3Cのウェブ・アーキテクチャ[WEBARCH]、ハイパーテキスト転送プロトコル（[RFC7230]、[RFC7231]）、およびリンクト・データ・プラットフォーム[LDP]に基づいています。

ページ付き資源
（例えば、メモリーが枯渇せずに）サーバーが1つのHTTPレスポンスで構築するには表現が大きすぎるかもしれないLDPR。そのため、LDPページング・サーバーは、複数のHTTPリクエストを実行し、クライアントが、時間をかけてその状態のサブセットを取得可能なページ・シーケンスを提供します。

ページ付き資源は、ページ付きフィード[RFC5005]に詳しい読者にとっては、論理的フィードと似ています。任意の資源は、きっかり1ページから成るページ付き資源であるとみなされます（そうすることの利便性は明らかではありませんが）。

ページ・シーケンス
P1 (first)、P2、…、Pn (last)という一連の関連するLDPRsで、それぞれにページ付き資源の状態のサブセットが含まれています。

クライアントがシーケンスの資源の表現を結合する場合には、クライアントはページ付き資源の状態のコピーを持っています。クライアントがシーケンスの資源を検索している間にページ付き資源が変更された場合には、クライアントが持っているそのページ付き資源の状態のコピーは不完全だったり、ページ付き資源の任意の時点の状態と一致しない可能性があります。したがって、この検索と結合プロセスの結果が、クライアントが1回のリクエストで得る状態（それが可能であったならば）と同じであることを強く保証することはできませんが、LDPは、検索プロセス中にページ付き資源の状態がいつ変更されたかをクライアントが検出する方法を提供します。検索プロセス中に、ページ付き資源の状態が変わらない限り、クライアントが持っているページ付き資源の状態のコピーは、サーバーの実装によって得られるものと同じくらい正確です。

ページ付き資源PがLDP-RSであれば、個々のシーケンス内ページ資源の表現にはPのトリプルのサブセットが含まれ、クライアントは、それらのグラフを統合することでそれらを結合できます。LDPでは、LDP-RSs以外の資源のページングを行うことはできますが、クライアントがそれらの表現を結合する方法は規定されていません。さらなる詳細については、6項 リンクト・データ・プラットフォーム資源を参照してください。

ページ・シーケンスは、ページ付きフィード[RFC5005]に詳しい読者にとっては、ページ付きフィードと似ており、同じ留意点（上記と同じ）の多くが当てはまります。

シーケンス内ページ資源
ページ・シーケンス内の1つのLDPRで、ページ付き資源と呼ばれる別の資源Pの状態のサブセットが含まれています。シーケンス内ページ資源は、ページ付きフィード[RFC5005]に詳しい読者にとっては、フィード・ドキュメントにと似ています。

注：ページ付き資源と個々のページ資源が同じような文脈で言及される場合に、作者や読者が両者を明確に区別できるようにする目的で用語の選定を行いました。

注：ページ・シーケンスは、前向きトラバースのみを用いた場合に、ページ付き資源から始まるトラバースがどのように行われるかという観点で記述され名付けられています。これは、それ以上のことを意味するものではなく、この選択は任意です。例えば、前向きリンクを辿ることは、シーケンスにおいてより後の資源がより新しいということを意味しません。前向きは、時間を前後に、または、その他のある次元に沿って移動することと一致している場合もありますが、そのような関係はサーバー固有のものです。後で定義しているようなLDPC表現に関する追加の具体的な言明がない限り、これは、LDPページングでは暗示されません。

先頭ページ・リンク
ページ・シーケンスの最初のシーケンス内ページ資源であるP1 (first)へのリンク。先頭ページは、ページ付き資源のURIに対する検索リクエストに応答して、LDPページング・サーバーがリダイレクトする（303レスポンス） ページです。構文的には、HTTPのLink <P1>; rel="first"ヘッダー[RFC5988]です。

次ページ・リンク
ページ・シーケンスの次のシーケンス内ページ資源へのリンク。構文的には、コンテキストURIがPi=1 (first)...n-1 (next to last)を識別し、ターゲットURIがPi+1を識別する場合のHTTPのLink <Pi>; rel="next"ヘッダー[RFC5988]です。

最終ページ・リンク
ページ・シーケンスの最後のシーケンス内ページ資源であるPn (last)へのリンク。次ページ・リンクが含まれていないため、最終ページは、前向きトラバースが完了するページです。構文的には、HTTPのLink <Pn>; rel="last"ヘッダー[RFC5988]です。

前ページ・リンク
ページ・シーケンスの前のシーケンス内ページ資源へのリンク。構文的には、コンテキストURIがPi=2...n (last)を識別し、ターゲットURIがPi-1を識別する場合のHTTPのLink <Pi>; rel="prev"ヘッダー[RFC5988]です。

ページング・リンク
LDPページングが定義している、先頭ページ・リンク、次ページ・リンク、最終ページ・リンク、前ページ・リンクのいずれか。

前向きトラバース
ある開始点から次ページ・リンクを辿るプロセス。

注：「前」は、ページ・シーケンス内の一方向に対する名前以上のものを意味すると解釈すべきではありません。例えば、前のリンクを辿るということは、ページ・シーケンス内でより後の資源がより新しいということを意味しません。前方向は、時間を前に移動することと一致している場合もありますが、後で定義しているようなLDPC表現に関する追加の具体的な言明がない限り、任意のそのような関係はサーバー固有のものであり、LDPページングでは暗示されません。

後ろ向きトラバース
ある開始点から前ページ・リンクを辿るプロセス。

注：「後ろ」は、ページ・シーケンス内の一方向に対する名前以上のものを意味すると解釈すべきではありません。

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

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

3. 適合性

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

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

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

適合LDPページング・クライアントは、LDPページングで定義されている規則に従った適合LDPクライアント[LDP]です。

適合LDPページング・サーバーは、LDPページページングで定義されている規則に従った適合LDPサーバー[LDP]です。

4. メッセージ交換のページングの例

この項は非規範的です。

Example Co.の顧客関係データはhttp://example.org/customer-relationsというURIで識別され、同じURIを用いて検索可能です。

4.1 ページングのない従来のフロー

LDPページングを理解しない標準的なHTTPクライアントは、通常の方法で資源の表現を取得します。

リクエスト
例1
GET /customer-relations HTTP/1.1
Host: example.org
Accept: text/turtle

サーバーのレスポンスは次のとおりです。

レスポンス:
例2
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ce291112"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: GET,OPTIONS,HEAD

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology/>.
@base <http://example.org/customer-relations>.

<>
   a o:CustomerRelations;
   dcterms:title "The customer information for Example Co.";
   o:client <#JohnZSmith>, <#BettyASmith>, <#JoanRSmith>,
            <#GlenWSmith>, <#AlfredESmith>. 

<#JohnZSmith>
   a foaf:Person;
   o:status o:ActiveCustomer;
   foaf:name "John Z. Smith".
   
<#BettyASmith>
   a foaf:Person;
   o:status o:PreviousCustomer;
   foaf:name "Betty A. Smith".
 
 <#JoanRSmith>
   a foaf:Person;
   o:status o:PotentialCustomer;
   foaf:name "Joan R. Smith".
 
<#GlenWSmith>
   a foaf:Person;
   o:status o:ActiveCustomer, o:GoldCustomer;
   foaf:name "Glen W. Smith".

<#AlfredESmith>
   a foaf:Person;
   o:status o:ActiveCustomer, o:BronzeCustomer;
   foaf:name "Alfred E. Smith".

メモリーなどの実装上の限界に達することなくサーバーがその表現を作成できる程度に検索中の資源が小さく、クライアントがその表現を利用できる限り、このパターンはうまく機能します。実際のところ、これは間違いなくウェブにおける最も一般的なパターンです。

しかし、サーバーおよび／またはクライアントの制約や利用のプレファレンスが関わってきた時点で、他の何かが必要となります。LDPページングは、表現をより小さな断片に分割する性能をクライアントとサーバーに提供することでこのニーズに対応し、クライアントが必要な分だけ（資源の完全な状態の小さなサブセットの可能性がある）転送を行い、クライアントが断片を再構成したければできる（またはしない）ようにします。一般的な例としては、このパターンは、ページ検索の結果などの文脈でみられます。

4.2 リダイレクトを用いたシンプルなページングのフロー

可能性のある最もシンプルなソリューションは、既存のURIであるhttp://example.org/customer-relationsの意味を、「すべての顧客関係情報」から「すべての顧客関係情報の最初のサブセット」に定義しなおすことです。しかし、その場合には、元の定義を用いてコードを構築した既存のクライアントを変更する必要があるため、Example Co.が「最初のサブセット」のURIを新たに作成したうえで、その後のサブセットを発見する方法を定義し、この新しい「最初のサブセット」のURIをクライアントに使わせるという方法のほうが可能性が高いでしょう。

「最初のサブセット」のURIという方法では、既存のクライエントを、古い「すべて」から新しい「最初のサブセット」という意味へと移行するという課題が解決されるわけではありません。HTTPに反して、303のリダイレクトに自動的に従い、リダイレクト先の資源を元の資源と等しいものとして扱うという、広く普及している従来のクライアントの慣行を前提としても、303 See Other（「303 他を参照」）が、古いURIから新しいURIにリダイレクトさせることはありません。安全な方法は、リダイレクト先のURIの「最初のサブセット」の意味をクライアントが処理可能であることを、クライアントがサーバーに明示的に伝えることです。これが、LDPページングが行う内容です。

LDPページングに対応しているクライアントは、通常の方法で資源の表現を取得したうえで、先頭ページ資源へのリダイレクションを処理できる性能があることも伝えます。

リクエスト
例3
GET /customer-relations HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; max-triple-count="500"

下記のとおり、サーバーのレスポンスには303 See Otherのステータス・コードと、ターゲット資源を識別するLocation: http://example.org/customer-relations?page1というHTTPレスポンス・ヘッダーが含まれています。

レスポンス:
例4
HTTP/1.1 303 See Other
Location: <http://example.org/customer-relations?page1>

この時点では、クライアントは、ターゲット資源が「すべて」なのか「最初のサブセット」なのかを知りません。それを知るためには、資源を検索する必要があります。

リクエスト
例5
GET /customer-relations?page1 HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; max-triple-count="500"

サーバーのレスポンスは下記のとおりです。

レスポンス:
例6
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ce291112"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type",
      <http://www.w3.org/ns/ldp#Page>; rel="type"
Link: <http://example.org/customer-relations?p=2>; rel="next"
Link: <http://example.org/customer-relations>; rel="canonical"; etag="customer-relations-v1"
Allow: GET,OPTIONS,HEAD

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology/>.
@base <http://example.org/customer-relations>.

<>
   a o:CustomerRelations;
   dcterms:title "The customer information for Example Co.";
   o:client <#JohnZSmith>, <#BettyASmith>, <#JoanRSmith>. 

<#JohnZSmith>
   a foaf:Person;
   o:status o:ActiveCustomer;
   foaf:name "John Z. Smith".
<#BettyASmith>
   a foaf:Person;
   o:status o:PreviousCustomer;
   foaf:name "Betty A. Smith".
 <#JoanRSmith>
   a foaf:Person;
   o:status o:PotentialCustomer;
   foaf:name "Joan R. Smith".

このレスポンスから、クライアントは、もっと多くのデータが存在しており、それがどこにあるかを知ることになります。サーバーは、クライアントのmax-triple-countというプレファレンスを1つのインプットとして用いて、この仕様では定義していないアプリケーション固有の方法でページのサイズを決定します。最もシンプルな方法は、サーバーのページ・サイズをクライアントのプレファレンスと同じにすることです。この例では、2ページ目が存在するように、サーバーは、より小さい値を選択しています。

以下の例は、次ページを検索するためのメッセージ交換を示しています。

リクエスト
例7
GET /customer-relations?p=2 HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; max-triple-count="500"

サーバーのレスポンスは下記のとおりです。

レスポンス:
例8
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "8_7e52ce291112"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type",
      <http://www.w3.org/ns/ldp#Page>; rel="type"
Link: <http://example.org/customer-relations>; rel="canonical"; etag="customer-relations-v1"
Allow: GET,OPTIONS,HEAD

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology/>.
@base <http://example.org/customer-relations>.

<>
   o:client <#GlenWSmith>, <#AlfredESmith>. 
 
<#GlenWSmith>
   a foaf:Person;
   o:status o:ActiveCustomer, o:GoldCustomer;
   foaf:name "Glen W. Smith".

<#AlfredESmith>
   a foaf:Person;
   o:status o:ActiveCustomer, o:BronzeCustomer;
   foaf:name "Alfred E. Smith".

この例では、2ページ目で提供された顧客は2人だけしかいませんでした。

5. リンクト・データ・プラットフォーム・ページング・クライアント

以下のすべては、LDPページング・クライアントの適合規則です。

5.1 一般的な要件

5.1.1 LDPページング・クライアントは、通常は表現を含んだレスポンスが返されるすべての検索リクエストにおいて、LDPページングをサポートしているという自身の性能を公言しなければなりません（MUST）。

5.1.2 LDPページング・クライアントは、前向きトラバースおよび／または後ろ向きトラバースのうちの少なくとも1つを実行できなければなりません（MUST）。

5.1.3 LDPページング・クライアントは、任意のシーケンス内ページ資源のページング・リンクが、そのシーケンス内ページ資源を複数回検索しても変更されないままであると想定しなければなりません（MUST NOT）。この想定は、例えば、ページ付き資源に変更が生じた時に、サーバーがシーケンスにページを追加する性能と衝突します。

5.1.4 LDPページング・クライアントは、任意のシーケンス内ページ資源のページング・リンクに常にアクセス可能であると想定してはなりません（MUST NOT）。

非規範的な注: この想定は、例えば、ページ付き資源に変更が生じた時に、サーバーがシーケンスからページを削除する性能と衝突します。この1つの結果として、ページのリンクを辿った時に、単にタイミングの問題で、クライアントやサーバー側にまったくエラーが生じていないのに、クライアントが4xxのステータス・コードのレスポンスを受け取ることがありえます。このようなレスポンスは異常であり、クライアントがそのページをトラバースしている間にページ付き資源の状態が変更されていないということもレスポンスが示していれば、おそらくエラーが発せられるでしょう。サーバーは特定のページ・シーケンスの有効期限を設定することもでき、サーバーがそのシーケンスを捨てた後にクライアントがリクエストを行えば、410 Gone（「410 消滅」）やその他の4xxのステータス・コードが発生する可能性が高いです。

5.1.5 ページ・シーケンスの検索中にページ付き資源が変更された場合には、LDPページング・クライアントは、ページ・シーケンスをページ付き資源と同等のものとして扱うべきではありません（SHOULD NOT）。

5.1.6 LDPページング・クライアントは、303 See Other（「303 他を参照」）のリダイレクト先を、元の資源の代替として扱ってはなりません（MUST NOT）。つまり、[RFC7231]で明確化されているとおり、303ステータス・コードを、307 Temporary Redirect（「307 一時的リダイレクト」）[RFC7231]や308 Permanent Redirect（「308 恒久的リダイレクト」）[RFC7238]であるかのように扱うことはできません。LDPページング・サーバーがページングを開始する方法としてリダイレクションを用いる場合には、1つのシーケンス内ページ資源の表現とページ付き資源の表現とを区別するクライアントの性能にとってこれはクリティカルです。

5.2 クライアントのプレファレンス

LDPページング・クライアントは、LDPページング・サーバーの選択に影響を及ぼすページングに関するヒントを提供しなければなりません。

この仕様では、HTTP Preferリクエスト・ヘッダーのreturn=representationプレファレンス[RFC7240]に新しいパラメータを導入しており、これをクライアントが用いて、クライアントのニーズに最も適したレスポンスをサーバーが作成できるようなプレファレンスを提供できます。この項で定義しているパラメータがあると、いくつかの目的に役に立ちます。

5.2.1 LDPクライアントは、完全な資源表現[LDP]ではなく、1ページの表現を返して独自にページングを開始したLDPサーバーが作成する成功したHTTP GETレスポンスを処理できるべきです（SHOULD）。

LDPページングは、既存のHTTP Preferリクエスト・ヘッダーのreturn=representationプレファレンス[RFC7240]に新しいパラメータとしてmax-triple-count、max-member-count、max-kbyte-countを定義しています。プレファレンス単独ではなく、これらのパラメータのいずれかがプレファレンスに存在していれば、クライアントがLDPページングをサポートしていることをサーバーに示していることになります。クライアントは、以下のプレファレンスのパラメータのいずれかを含んだreturn=representationプレファレンスを持つリクエスト・ヘッダーを追加してそのヒントをサーバーに伝えます。

max-triple-count クライアントが個々のページに表示したい最大トリプル数（10進数）。
max-kbyte-count クライアントがページの表現として受け取りたい最大キロバイト数（1024バイト単位）（10進数）。
max-member-count クライアントが個々のページに表示したい最大メンバー数（10進数）。このパラメータはページ付きLDPCsにのみ意味がある。

汎用プレファレンスであるBNF[RFC7240]では、プレファレンスのパラメータ値として引用符で囲まれた文字列やトークンが認められています。

1ページあたり最大500件のRDFトリプルを受け取ることに関心があるクライアントは、4.2項 リダイレクトを用いたシンプルなページングのフローで示しているとおり、GETリクエストにこのHTTPヘッダー（Prefer: return=representation; max-triple-count="500"）を追加するでしょう。

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

6.1 ページングに関する留意点

この項は非規範的です。

以前に説明したとおり、ページングは、ページ付き資源を、クライアントが検索可能なシーケンス内ページ資源（ページ）のリストに論理的に分割し、他のシーケンス内のページへのリンクを含んだ個々のページを提供します。クライアントは、他のページがあるかどうかを知るために、個々のレスポンスの調査を行います。ページングはHTTPステータス・コードの選択には影響しません。LDPCsのみに現在定義されている一部のケースでは、サーバーはそのアルゴリズムを示すことができますが、一般的にクライアントにはページへの情報の割り当てを見抜く力はありません。

クライアントが受け取った任意のシーケンス内ページ資源に変更が反映されたことをLDPページングは保証しないため、一部のクライアントは、ページの検索中に、競合するリクエストによってページ付き資源が変更されたかどうかを知ることに関心があるでしょう。サーバーの実装に関わらず、LDPは、一連のページをトラバースしている間に、リード・コミッテッド分離（read committed isolation）[READ-COMMITTED]を用いているデータベースと同等のデータをクライアントが観察することを保証するだけです。具体的に言うと、クライアントは、 LDPページング・サーバーが提供するページをトラバースしている間に、非再現リード（non-repeatable read）[NON-REPEATABLE-READS]を観察できます。しかし、LDPページングは、クライアントがページを検索しているすべての期間にわたってページ付き資源に（追加も削除されず）継続的に存在しているLDPRの情報が、少なくとも1つのシーケンス内ページ資源に存在していることは保証します。

LDPページングは、例えば、クライアントがページのトラバースをできる限り早く断念できるように、クライアントがページ付き資源の変更を検知できるメカニズムを定義しています。これは、場合によっては、ページ付きフィード[RFC5005]に対して記述されているものよりも強い保証を提供しますが、どのような時にその条件に当てはまるのかをクライアントが検出する必要があります。ページングは、ページ付き資源が追加または変更されることなく、すべてのシーケンス内ページ資源をうまく検索できることを決して保証しません。そのため、そのような保証を必要とするクライアントは、実際にはすべてのページ付き資源を使用できるわけではないことに気づくかもしれません。4.項 メッセージ交換のページングの例で詳細な例を提供しています。サーバー実装に関する留意点に関しては、A項 サーバー・サイド・セッションの状態を維持せずにLDPRsをページングを参照してください。

6.2 HTTP GET

LDPRs[LDP]に対するHTTP GETの要件に加え、LDPページング・サーバーは、すべてのページ付き資源および関連するシーケンス内ページ資源に関して、この項の要件にも従わなければなりません。

6.2.1 LDPページング・サーバーは、大きなページのLDP-RSsをクライアントが検索できるようにすべきです（SHOULD）

6.2.2 LDPページング・サーバーは、任意の資源（LDP-RSであろうとなかろうと）を、ページ付き資源とみなすことができます（MAY）。

6.2.3 LDPページング・サーバーは、任意の資源（LDP-RSであろうとなかろうと）のページ付き資源としての扱いを徐々に変えることができます（MAY）。言い換えれば、同じ資源の検索を異なる時点で2回行った場合、サーバーは、1回目には先頭ページの表現を返し、別のタイミングでは全体の資源の表現を返すことを選択できます。クライアントは、ステータス・コードやレスポンス・ヘッダーに基づいてこれらのケースを区別します。

6.2.4 LDPページング・サーバーは、表現として返されるデータ量に反映させるために、クライアントが処理したいと考えている最大ページのサイズなどの、クライアントのLDPページングの定義済みヒントのすべてを尊重すべきです（SHOULD）。

非規範的な注: LDPサーバーの実装者は、ここで定義しているパラメータがないPrefer return=representationリクエスト・ヘッダーを、ページ付き資源に対するクライアントのリクエストであると解釈しないように注意すべきです。この仕様で定義しているプレファレンスのパラメータが少なくとも1つ存在する時にのみ、クライアントのヒントは、LDPページングのサポートを示します。
非規範的な注: LDPサーバーの実装者は、[RFC7240]の2項で記述しているとおり、これらのプレファレンスのキャッシュへの影響を慎重に考慮すべきです。
非規範的な注: [RFC7240]は、レスポンスの内容に基づくヒントの尊重に関して、クライアントが、サーバーの挙動を別の方法では決定できない時に、サーバー実装者がPreference-Appliedレスポンス・ヘッダーを含むことを推奨しています。

6.2.5 LDPページング・サーバーは、値が0であるページ・サイズのヒントを無視し、さらに、希望する最大サイズが指定されていないかのように処理できます（MAY）。後者の場合、サーバーは、適切と思われるどのようなページ・サイズでも選択でき、または、資源にページ付けを行わないことを選択できます。

6.2.6 クライアントがLDPページングを理解できることを示していなければ、LDPページング・サーバーは、ページンンクを開始すべきではありません（SHOULD NOT）。LDPページング・サーバーがページングを開始する場合には、以下の方法のうちの1つにより、ページ付き資源をRequest-URIとして用いて、成功したGETリクエストに応答すべきです（SHOULD）。

  • クライアントがページングをサポートしている場合には、303 See Other（「303 他を参照」）のステータス・コードと、最初のシーケンス内ページ資源を識別するLocationレスポンス・ヘッダーで応答します。クライアントがページングを理解できることをクライアントがサーバーに伝えるためにLDPページングが定義している標準的な方法は、この目的のために定義されているクライアントのプレファレンスを用いるというもののみですが、その他の実装固有の方法も使用できるかもしれません。
  • サーバーがページ付けのない表現を提供することを厭わない場合には、適切なステータ・スコード（おそらく200 OK）と、サイズが大きいかもしれないページ付けのない表現で応答します。
  • リクエストを拒絶する（4xxのステータス・コードの可能性が最も高い）か、（下記の注に留意しつつ）上記のとおりに303のステータ・スコードでページングを開始するか、特定の状況に適した別のステータス・コードを選択するかのいずれかを行います。
非規範的な注: LDPページング・サーバーは、任意の資源をページ付き資源としてしか利用できないようにすることを選択できます。これを行った場合には、LDPページングを理解できないクライアントとの相互作用において、とりあえずサーバーがページングを開始すれば、不正な挙動を取るクライアントは、303 See Other（「303 他を参照」）リダイレクトに自動的に従ってしまい、その後の200 OKにより、1つのシーケンス内ページ資源の表現ではなく、完全なページ付き資源を得たと信じてしまうリスクがあります。LDPページング・クライアントは、このような方法でリダイレクトに従うことはありませんが、一部の既存のHTTPクライアントは、[RFC7231]で明示的に否定されているにもかかわらず、303 See Other（「303 他を参照」）リダイレクトを元のrequest-URIと同じであるかのように扱うことが知られています。

6.2.7 LDPページング・サーバーは、クライアントのトラバース操作全体を通してページ付き資源に存在していたすべての状態が少なくとも1つのシーケンス内ページ資源で表されていることを保証しなければなりません（MUST）。言い換えれば、そのページをクライアントがトラバースしている間に追加、更新、削除されていないページ付き資源のサブセットは、いかなるものであろうと、ページのうちの1つに存在していなければなりません。

非規範的な注: 結果として、ページ付き資源がトラバース中にまったく変更されなければ、クライアントは、最後のページが検索された時点で交渉を行ったレスポンス・メディア・タイプが提供する状態を完全に把握していることになります。トラバース中にページ付き資源に変更が行われれば、実際に更新された部分のみが異なるでしょう。この場合に、サーバーのものとどのように異なっているのかを知る（LDPページングに規定されている）手段はクライアントにはありません。
非規範的な注: ページ付き資源がLDP-RSである場合には、ページ付き資源への変更が反映されていないすべてのトリプルが、トラバース中にクライアントに提供されたと推測されます。変更されたトリプルのサブセットの一部（すべての場合も、まったくない場合もある）がクライアントに提供された可能性もありますが、クライアントには、それがどれなのかを知る術はありません。

6.2.8 LDPページング・サーバーは、すべての成功したHTTP GETレスポンスにHTTP Linkヘッダーを含むことにより、クライアントがページを検索している間に発生するページ付き資源に対するあらゆる変更をクライアントが検出できるようにしなければならず（MUST）、すべての4xxステータ・スコード・レスポンスに同じヘッダーを含むべきです（SHOULD）。リンクのコンテキストURIは、検索されているシーケンス内ページ資源を識別し、ターゲットURIは、ページ付き資源を識別し、リンク関係型は、canonical[REL-CANONICAL]であり、リンク拡張パラメータには、パラメータ名etagと、ページ付き資源のETag[RFC7232]と全く同じ対応するパラメータ値が含まれます。例：Link: <http://example.org/customer-relations>; rel="canonical"; etag="customer-relations-v1"

非規範的な注: 例えば、先頭ページの表現に伴う値がrel="canonical"; etag="v1"、2ページ目の表現に伴う値がrel="canonical"; etag="v2"というように、クライアントがページを検索するにつれてrel="canonical"; etag="..."の値が変更されれば、クライアントは、ページ付き資源の状態が変更されたことを検出できます。このような変更を無視するクライアントもありますが、トラバースを再開するなどの方法でそれらに対応することを選択することもできます。

6.2.9 LDPページング・サーバーは、ページ付き資源のシーケンスにシーケンス内ページ資源を徐々に追加または削除できます（MAY）。ページ・シーケンスが順序付けさている場合には、サーバーが伝える順序を維持しなければなりません（MUST）。サーバーは、順序付けされていないシーケンスの後にのみページを追加すべきです（SHOULD）。

非規範的な注: サーバーが適切な既存のページにコンテンツを追加するか、シーケンス内の適切な場所に新しいページを追加するかのどちらかを行えば、クライアントにとってはそれほど破壊的ではありませんが、サーバーが順序付けされたページ・シーケンスを捨てるかもしれず、その場合には結果として、その後のリクエストに4xxのステータス・コードが生じます。クライアントが変更／追加されたページを検出するためには、既存ページに条件付き検索リクエストを行う以外に有効な方法はありません。
非規範的な注: 結果として、クライアントがシーケンス内ページ資源の検索を何度か行えば、ページ付き資源の状態が変わるとシーケンス内のその場所も変わることに気づくかもしれません。例えば、形式的には、後でページが再検索されたときに、最終ページのサーバーは、次ページ・リンクを提供するかもしれません。ページ・シーケンスが、複数のサーバーにまたがる時にも、同じような状況が発生します。サーバーAは、シーケンスの最初の部分を提供し、それはサーバーAが知っている最終ページ（サーバーBで提供される）にリンクされていて、サーバーBがページのシーケンスを拡張するかもしれません。Mという中間ページは、クライアントがMを検索した後に、競合するリクエストが、ページ付き資源の内容の一部を削除すれば、形式的には、最終（または、存在しない）ページになることがありえます。

6.2.10 LDPページング・サーバーは、任意のシーケンス内ページ資源をRequest-URIとして持つリクエストに応答する時に、先頭ページ・リンクを提供できます（MAY）。

6.2.11 LDPページング・サーバーは、任意のシーケンス内ページ資源をRequest-URIとして持つGETリクエストに応答し、最終ページ・リンクを提供できます（MAY）。

6.2.12 LDPページング・サーバーは、最後のページ以外の任意のシーケンス内ページ資源をRequest-URIとして持つGETリクエストに応答し、次ページ・リンクを提供しなければなりません（MUST）。これは、クライアントが次ページのURLを発見できるメカニズムです。

6.2.13 LDPページング・サーバーは、最後のシーケンス内ページ資源をRequest-URIとして持つGETリクエストに応答し、次ページ・リンクを提供してはなりません（MUST NOT）。これは、サーバーが現在認識しているページ・シーケンスの終わりをクライアントが発見できるメカニズムです。

6.2.14 LDPページング・サーバーは、先頭ページ以外の任意のシーケンス内ページ資源をRequest-URIとして持つGETリクエストに応答し、前ページ・リンクを提供できます（MAY）。これは、クライアントが前ページのURLを発見できる1つのメカニズムです。

6.2.15 LDPページング・サーバーは、最初のシーケンス内ページ資源をRequest-URIとして持つGETリクエストに応答し、前ページ・リンクを提供してはなりません（MUST NOT）。これは、サーバーが現在認識しているページ・シーケンスの始まりをクライアントが発見できる1つのメカニズムです。

6.2.16 LDPページング・サーバーは、任意のシーケンス内ページ資源をRequest-URIとして持つGETリクエストに応答し、ターゲットURIがhttp://www.w3.org/ns/ldp#Pageで、リンク関係型がtype[RFC5988]であるHTTP Linkヘッダーを提供しなければなりません（MUST）。これは、資源がページのシーケンスの1つであることをクライアントが知る1つのメカニズムです。

6.2.17 LDPページング・サーバーは、適切なページング・リンクのレスポンス・ヘッダー（例えば、rel="first"）を持つ任意のシーケンス内ページ資源に対するHTTPリクエストに対して410 Gone（「410 消滅」）で応答することにより、シーケンスを捨てたことを示すべきです（SHOULD）。

6.2.18 LDPページング・サーバーは、max-triple-countというクライアント・プレファレンス・パラメータをサポートすべきで（SHOULD）、これは、1ページに表示されるRDFトリプルの数を制限するページ・サイズを表します。例えば、max-triple-count="500"は、1ページあたり500のRDFのトリプルという制限を表します。

6.2.19 LDPページング・サーバーは、max-kbyte-countというクライアント・プレファレンス・パラメータをサポートすべきで（SHOULD）、これは、ページ・サイズの制限を表示サイズのキロバイトで表します。例えば、max-kbyte-count="1"は、1ページあたり1024バイトという制限を表します。

6.2.20 LDPページング・サーバーは、ページ・サイズを制限しているクライアント・プレファレンス・パラメータが複数提供された場合には、認識したすべてのヒントを尊重しなければなりません（MUST）。これには、レスポンスに対する最も制限的なヒントが、結果として生じるページ・サイズを左右するという実質的な影響があります。例えば、max-kbyte-count="1"とmax-triple-count="500"の結果は、個々のトリプルが2バイト以上を必要とする可能性が非常に高いため、通常、サイズが1キロバイトという制限とそもそも衝突するページになります（500トリプル／1024バイト）。

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

7.1 LDPコンテナのページング時の要件

7.1.1 LDPページング・サーバーは、ページ付きLDPCに対して、メンバーシップ・トリプルと包含トリプルの両方がページ・シーケンス内に存在している場合には常に、メンバーごとに両方のトリプルが同じシーケンス内ページ資源に含まれていることを保証しなければなりません（MUST）。

7.1.2 LDPページング・サーバーは、max-member-countというクライアント・プレファレンス・パラメータをサポートすべきで（SHOULD）、これは、ページ付きLDPCの個々のページで返されるメンバーの数を制限するページ・サイズを表します。例えば、max-member-count="10"は、1ページあたり10のメンバーという制限を表します。

7.2 複数ページにまたがるコンテナ・メンバーの順序付け

この項は非規範的です。

7.2.1 順序付け

コンテナのメンバーの順序が重要な場合が多くあります。あらゆるクライアントは、入手できるメンバーのプロパティー値に基づいて、好きなようにメンバーを選択して順序付けできるため、[LDP]は、コンテナ内のサーバーのメンバーの順序付けに関して特別なサポートを行いません。下の例では、メンバーごとにo:marketValueという述語の値が存在しているため、クライアントはそのプロパティー値に従ってメンバーを容易に順序付けできます。順序を指定する方法をクライアントに要求するアプリケーションは、アプリケーション固有の拡張でそれを行うことができます。

コンテナがページ付けされている場合には、順序がより重要になります。ページの構成時にサーバーが順序を尊重すれば、全体的にソートされたメンバーが必要なクライアントは、ページの統合に必要な労力を削減できます。順序が重要な場合には、LDPページング・サーバーは、任意の1ページ内のすべてのメンバーに、次ページおよび前ページのすべてのメンバーに関連付けられた適切なソート順序が含まれていることを保証します。これは、1ページ内のメンバーの順序については何も語りません。ソートが昇順の時には、現在のページのすべてのメンバーのソート順序は、前ページのすべてのメンバーよりも大きく、次ページのすべてのメンバーよりも小さいです。つまり、小さいものから大きいものへと進みますが、いくつかの連続するページには、ソートの基準が等しいメンバーがありえます。ソートが降順の時には、順序は逆になります。メンバーのソートには複数の値が用いられうるため、LDPCの仕様では、サーバーは、ldp:pageSequenceというHTTPリンク関係とそのldp:pageSortCriteria述語を用いて、メンバーのソートに用いる順序付けされたソート基準のリストを言明できます。この順序付けされたリストの個々のメンバーは、1つのldp:pageSortCriterionを提供し、これは、ldp:pageSortOrder、ldp:pageSortPredicate、オプションのldp:pageSortCollationで構成されます。

以下に、[LDP]の5.1項で説明している財産コンテナの例を示します。

リクエスト
例12
GET /netWorth/nw1/assetContainer/ HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; max-triple-count="500"

サーバーは、ステータス・コード200 OKと、次の表現で応答するかもしれません。

レスポンス:
例13
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ff291112"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type"
Allow: GET,OPTIONS,HEAD

# The following is the ordered representation of
#   http://example.org/netWorth/nw1/assetContainer/

# @base <http://example.org/netWorth/nw1/assetContainer/> .
@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;
   ldp:contains <a1>, <a2>, <a3>.

<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 505.00 .
<a3>
   a o:RealEstateHolding;
   o:marketValue 100.00 .

HTTPステータス・コードが200 OKであるため、レスポンスの作成にLDPページングが用いられなかったことをクライアントは知っています。Link: <http://www.w3.org/ns/ldp#Page>; rel="type"というレスポンス・ヘッダーリンクがなければ、この確認は冗長になります。ページングが用いられなかったため、サーバーは、ページのソートに関する情報を提供しません。ページのソートに関する情報の提供は、クライアントには価値がなく、資源の浪費にすぎません。

代わりに、サーバーが、http://example.org/netWorth/nw1/assetContainer/?p=1という先頭ページへのリダイレクトで応答すれば、（リダイレクトに従った後は）次のとおりになります。

レスポンス:
例14
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ff291112"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type",
      <http://www.w3.org/ns/ldp#Page>; rel="type"
Link: <http://example.org/netWorth/nw1/assetContainer/?p=2>; rel="next"
Link: <http://example.org/netWorth/nw1/assetContainer/>; rel="canonical"; etag="v1"
Link: <http://example.org/netWorth/nw1/assetContainer/sortedSequence/>; rel="http://www.w3.org/ns/ldp#pageSequence"Allow: GET,OPTIONS,HEAD

# The following is the ordered representation of
#   http://example.org/netWorth/nw1/assetContainer/ page 1 of 2

@base <http://example.org/netWorth/nw1/assetContainer/> .
@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;
   ldp:contains <a1>, <a2>, <a3>.

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

<a1>
   a o:Stock;
   o:marketValue 100.00 .
   
# The remainder of the content describes the sort order.
# Note that the new base URI here matches the target URI of the pageSequence Link header above.

@base <http://example.org/netWorth/nw1/assetContainer/sortedSequence/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

<> ldp:pageSortCriteria  ( <#Sort-o.marketValue-Ascending> ).

<#Sort-o.marketValue-Ascending>
   a ldp:pageSortCriterion;
   ldp:pageSortOrder ldp:Ascending;
   ldp:pageSortPredicate o:marketValue.

この場合、サーバーは、ページへのメンバーの割り当てに関する情報を提供します。

  • Link: rel="http://www.w3.org/ns/ldp#pageSequence"というレスポンス・ヘッダーが追加され、クライアントはページ・シーケンスに関する情報がどこにあるかを知ることができます。その内容にはldp:pageSortCriteriaトリプルが含まれており、クライアントは、ページにメンバーを割り当てる時にサーバーがどのようなソート基準を用いたかを知ることができます。
  • サーバーは、ソート基準に関する言明を、先頭ページの内容に含めることも選択しました（つまり、2番目の@base指示子の後に出現するトリプル）。これはオプションの模範的な最適化であり、クライアントは、LDPやHTTPではない方法を用いて、それらの言明を信用するかどうかを独自に決定しければなりません。クライアントがそれらの言明を信用する場合には、それらを検索する必要はありません。このケースでは、それらを検索すると、別のHTTP GETリクエストが生じるでしょう。この例では、言明は、クライアントがそれらを自身で検索して得るものと一致していると想定されます。
  • ソート基準の資源の内容は、昇順のページにメンバーを割り当てるために、o:marketValue述語が用いられていることを言明します。サーバーは、先頭ページのすべての財産のo:marketValueの値が、その後のページの値よりも大きいとクライアントに伝えています。偶然そのような値が1つだけ先頭ページにあるため、これが満たされていることは自明的です。

クライアントが、rel="next"のリンクを辿り、2ページ目を検索した場合には、その表現は次のとおりになるかもしれません。

レスポンス
例15
HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ff291112"
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type",
      <http://www.w3.org/ns/ldp#Page>; rel="type"
Link: <http://example.org/netWorth/nw1/assetContainer/?pageSortOrder>; rel="prev"
Link: <http://example.org/netWorth/nw1/assetContainer/>; rel="canonical"; etag="v1"
Link: <http://example.org/netWorth/nw1/assetContainer/sortedSequence/>; rel="http://www.w3.org/ns/ldp#pageSequence"
Allow: GET,OPTIONS,HEAD

# The following is the ordered representation of
#   http://example.org/netWorth/nw1/assetContainer/ page 2 of 2

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

<a2>
   a o:Cash;
   o:marketValue 505.00 .
<a3>
   a o:RealEstateHolding;
   o:marketValue 100.00 .
  • Link: rel="http://www.w3.org/ns/ldp#pageSequence"という同じレスポンス・ヘッダーが存在しており、それにより、クライアントは、サーバーが用いているページ・シーケンスが何なのか、ゆえに、ソート基準が何なのかを知ることができます。
  • サーバーは、2ページ目の内容にソート基準に関する言明を含めないことを選択しました。LDPページングでは、ページ・シーケンスが整合性をもってソートされる必要があるため、先頭ページを検索済みのクライアントはソート基準を既に見たことになります。クライアントが、リンクを辿る以外の方法でシーケンス内ページ資源のURIを得た場合には、ソート基準を検索する選択肢を常に有しています。
  • 例で示しているとおり、2ページ目のすべての財産o:marketValueの値は、以前のページの値よりも大きいか等しいです。このページ内の値は、ソート基準に従って順序付けされておらず、それは、この基準が、1ページ内の順序付けに当てはまるのではなく、「複数のページにメンバーを割り当てる」ソートにのみ当てはまることを示します。一般的に、それらの表現は、順序付けを保障せず、ライブラリにより生成され、そのシリアライザは、順序付けの伝達方法をコントロールする方法を提供しません。

1ページ内の（または、全体的な）資源の順序を示すための適切な述語の決定は、ドメイン・モデルとサーバー次第であり、例えば、ユーザ・インターフェースの表示前にデータをソートする場合などに、そのニーズを満たすために適切な方法でその順序を用いることは、この表現を受け取るクライアント次第です。また、コンテナは、他のコンテナを自身のメンバーとして持つことができるため、コンテナ自身がLDPRsであり、ドメイン・モデルのプロパティーをソート基準に利用できるので、順序付けのアプローチは変わりません。

7.3 複数ページにまたがるメンバーの順序付けに関するHTTP GETの要件

LDPページング・サーバーが、LDPCメンバーをページに割り当てるために用いる順序をクライアントに伝えるために、LDPページングで定義されているメカニズムを用いることを選択した場合（これはオプションです）、それはこの項で説明しているとおりに行われます。LDPページングは、その他のケースでは、ページに対する順序付けについて規定していません。模範的なメッセージ交換に関しては、7.2.1項 順序付けを参照してください。

7.3.1 LDPページング・サーバーは、LDPCメンバーをページに割り当てるために用いる順序を伝えることができます（MAY）。順序を伝えることを選択した場合には、同じシーケンス内のページごとの検索リクエストと整合性を持って応答しなければなりません（MUST）。つまり、同じシーケンス内のすべてのページに対する同じ基準（または、基準がないこと）を伝えなければなりません。基準が一様でないことが認められている場合には、複数ページにまがるコンテナのメンバー間の順序付けは定義されないでしょう。

非規範的な注: サーバーは、同じページ付き資源に異なるシーケンス（例えば、異なるソート基準を持つシーケンス）を提供でき、それらは、順次または同時に提供できます。

7.3.3 順序を伝えるLDPページング・サーバーは、ページへのメンバーの割り当てを記述しているページ・ソート基準の資源を提供しなければなりません（MUST）。個々の資源は、ldp:pageSortCriterion資源のrdf:Listで構成されます。最初のリストのエントリーは最初のソート基準を提供し、2番目のエントリーは最初の基準に照らして等しいと考えられるメンバーの順序付けを行うために用いられる2番目の基準を提供するなどと続きます。結果として作成されるページ・ソート順序は、SPARQL SELECTのORDER BY句[sparql11-query]で定義されているとおりでなければなりません（MUST）。

7.3.4 順序を伝えるLDPページング・サーバーは、すべてのldp:pageSortCriterionリストのエントリーにおいて、主語がソート基準の識別子、述語がldp:pageSortPredicate、目的語がページ間のメンバーを順序付けるために値が用いられる述語（ページ順序値）であるトリプルが含まれているページ・ソート基準の資源を提供しなければなりません（MUST）。LDPが挙動を制約するリテラルのデータ型は、SPARQL SELECTのORDER BY句[sparql11-query]で定義されているもののみです。その他のデータ型を用いることはできますが、LDPはそれらに意味を割り当てず、相互運用性が制限されるでしょう。

7.3.5 順序を伝えるLDPページング・サーバーは、すべてのldp:pageSortCriterionリストのエントリーにおいて、主語がソート基準の識別子、述語がldp:pageSortOrder、目的語が用いられている順序を記述しているトリプルが含まれているページ・ソート基準の資源を提供しなければなりません（MUST）。

LDPは、このトリプルの目的語として用いるためにldp:Ascendingとldp:Descendingの2つの値を定義しています。その他の値を用いることはできますが、LDPはそれらに意味を割り当てず、相互運用性が制限されるでしょう。

7.3.6 順序を伝えるLDPページング・サーバーは、任意のldp:pageSortCriterionリストのエントリーにおいて、主語がソート基準の識別子、述語がldp:pageSortCollation、目的語が用いられている照合順序（collation）を識別しているトリプルが含まれているページ・ソート基準の資源を提供できます（MAY）。[sparql11-query]が照合順序を用いないページ順序値が比較に含まれている場合は、ldp:pageSortCollationトリプルを省略しなければなりません（MUST）。

LDP は、このトリプルの目的語として用いる値を定義していません。相互運用性のためには、オープンな標準化された値を用いる方が良いですが、いかなる値でも使用できます。

ldp:pageSortCollationトリプルがなく、ページ順序値が文字列またはシンプルなリテラル[sparql11-query]である場合、結果として作成される順序は、2つの引数の（two-argument）fn:compareを用いたSPARQL SELECTのORDER BY句[sparql11-query]で定義されているとおりです。つまり、それは、http://www.w3.org/2005/xpath-functions/collation/codepointが指定された照合順序であるかのような挙動を行います。

ldp:pageSortCollationが存在し、ページ順序値が文字列またはシンプルなリテラル[sparql11-query]である場合、結果として作成される順序は、3つの引数の（three-argument）fn:compareを使いたSPARQL SELECTのORDER BY句[sparql11-query]で定義されているとおりです。つまり、それは、規定されている照合順序です。

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

この項は非規範的です。

HTTPを用いて実装されているプロトコルと同様に、実装においては、関連する多くのセキュリティ関連機能を利用すべきであり、その代わりに特定のセキュリティ方針とは対照的でありえるLDPオペレーションを実行する必要はありません。システム上重要なRDFステートメントをPUTメソッドによってグラフに置き換えるなどの、非認証要求に直面した時には、アプリケーションは、401のステータ・スコード（承認なし）で応答し、適切な承認が必要であることを示すことを検討できます。認証が特定のアクセス・コントロール方針の要件を満たすことに失敗した場合には、アクセス・コントロール方針を満たせなかったことを示すために、403のステータス・コード（アクセス拒否）をクライアントに返信できます。

A. サーバサイド・セッションの状態を維持せずにLDPRsをページング

この項は非規範的です。

クライアントごとの状態が暗示するスケーラビリティ上の制限のために、クライアントごとの状態を維持することを期待された場合には、当然ながらサーバーの実装者は懸念を持ちます。一見したところでは明白ではないかもしれませんが、LDPページングにはそのような要件はありません。クライアント[WEBARCH]にとってURLは曖昧であるため、サーバーは、例えば、その次ページ・リンク内のどこで次ページを始めるべきかを知るために必要な情報を自由にエンコードできます。

以前の例では、page n URLはすべてhttp://example.org/customer-relations?p=nという形式であることに注目してください。なお、このとき、nは2..nです。これは、一般的な慣習では真（true）である可能性が高いです。サーバーがページにo:client表現をランダムに割り当てれば、少なくとも1つのページですべての表現を送信している間に、クライアントごとの何らかの状態をサーバーに保持することを回避する方法は明確ではありません。しかし、リストが順序付けされている（自然な順序、または、実装により課された順序のどちらでも）という一般的なケースであれば、クライアントごとの状態をサーバーに保持することを回避するのは簡単です。

1つの簡単な例は「固定順序」です。サーバーが、o:client表現を常に#JohnZSmith, #BettyASmith, #JoanRSmith, #GlenWSmith, #AlfredESmithの順序（または、任意の予測可能な順序)で送信すれば、個々のクライアントが検索した時に、個々のシーケンス内ページ資源の次ページ・リンクに「last seen」という識別子を挿入できます。実際には、「セッションの状態」はクライアントにより保持されます。このケースでは、先頭ページ内の次ページ・リンクは次のようなものでありえます。

例16
Link: <http://example.org/customer-relations?resumeafter=JoanRSmith>; rel="next"

サーバーが後ろ向きトラバースもサポートしていれば、2ページ目の前ページ・リンクは次のようなものでありえます。

例17
Link: <http://example.org/customer-relations?resumebefore=GlenWSmith>; rel="next"

これが模範的なサーバーの実装決定事項であることに留意してください。これは、LDPページングでは規定されておらず、他の選択ももちろん可能です。リンクに用いられるURIがクライアントにとって曖昧である限り、規範的な参考文献の制約の範囲内で任意の選択が許されています。

B. 謝辞

この項は非規範的です。

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

Arnaud Le Hors（議長）、Alexandre Bertails、Andrei Sambra、Andy Seaborne、Antonis Loizou、Ashok Malhotra、Bart van Leeuwen、Cody Burleson、David Wood、Eric Prud'hommeaux、Erik Wilde、Gregory McFall、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、Roger Menday、Ruben Verborgh、Sandro Hawke、Serena Villata、Sergio Fernandez、Steve Battle、Steve Speicher、Ted Thibodeau、Tim Berners-Lee、Yves Lafon

C. 変更履歴

この項は非規範的です。

要約

D. 参考文献

D.1 規範的な参考文献

[LDP]
Steve Speicher; John Arwe; Ashok Malhotra. Linked Data Platform 1.0. 26 February 2015. W3C Recommendation. URL: http://www.w3.org/TR/ldp/
[REL-CANONICAL]
M. Ohye; J. Kupke. The Canonical Link Relation. Informational. URL: http://tools.ietf.org/html/rfc6596
[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
[RFC5988]
M. Nottingham. Web Linking. October 2010. Proposed Standard. URL: https://tools.ietf.org/html/rfc5988
[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
[RFC7238]
J. Reschke. The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). June 2014. Experimental. URL: https://tools.ietf.org/html/rfc7238
[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/
[sparql11-query]
Steven Harris; Andy Seaborne. SPARQL 1.1 Query Language. 21 March 2013. W3C Recommendation. URL: http://www.w3.org/TR/sparql11-query/

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

[LDP-PAGING-TESTSUITE]
R. Garcia-Castro; F. Serena. Linked Data Platform Paging 1.0 Test Cases. Editor's Draft of Working Group Note. URL: https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-paging-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/
[NON-REPEATABLE-READS]
Various. Wikipedia: Isolation (database systems). N/A. URL: http://en.wikipedia.org/wiki/Isolation_(database_systems)#Non-repeatable_reads
[READ-COMMITTED]
Various. Wikipedia: Isolation (database systems). N/A. URL: http://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed
[RFC5005]
M. Nottingham. Feed Paging and Archiving. September 2007. Proposed Standard. URL: https://tools.ietf.org/html/rfc5005
[turtle]
Eric Prud'hommeaux; Gavin Carothers. RDF 1.1 Turtle. 25 February 2014. W3C Recommendation. URL: http://www.w3.org/TR/turtle/