--- a/TR/WD-ldp-paging-20140828/Overview.html Mon Sep 08 12:33:46 2014 -0400
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,2408 +0,0 @@
-<!DOCTYPE html>
-<html lang="en" dir="ltr" typeof="bibo:Document w3p:LastCall" about="" property="dcterms:language" content="en">
-<head>
- <title>Linked Data Platform Paging 1.0</title>
- <!-- Changed by: , 27-Aug-2014 -->
- <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
- <!--
- === NOTA BENE ===
- For the three scripts below, if your spec resides on dev.w3 you can check them
- out in the same tree and use relative links so that they'll work offline,
- -->
-
-
- <style type="text/css">
- div.rule {padding-top: 1em;}
- div.ldp-issue-open {
- border-color: #E05252;
- background: #FBE9E9;
- padding: 0.5em;
- margin: 1em 0;
- position: relative;
- clear: both;
- border-left-width: .5em;
- border-left-style: solid;
- }
- div.ldp-issue-pending {
- border-color: #FAF602;
- background: #F7F6BC;
- padding: 0.5em;
- margin: 1em 0;
- position: relative;
- clear: both;
- border-left-width: .5em;
- border-left-style: solid;
- }
- div.ldp-issue-closed {
- border-color: #009900;
- background: #BCF7CF;
- padding: 0.5em;
- margin: 1em 0;
- position: relative;
- clear: both;
- border-left-width: .5em;
- border-left-style: solid;
- }
- div.ldp-issue-title {
- color: #E05252;
- padding-right: 1em;
- min-width: 7.5em;
- }
- .atrisk {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #f00;
- background: #ffc;
- }
- .atrisktext {
- /* content: "Feature At Risk"; */
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #f00;
- background: #fff;
- padding: 3px 1em;
- }
- .normal {
- font-weight: normal;
- font: normal 100% sans-serif;
- }
- .indented {
- margin-left: +3em;
- }
- tr:nth-of-type(odd),.oddrow {
- background:#F2F2F2; /* light grey, just enough to differentiate from white */
- }
- td {
- padding:0 +1ex 0 +1ex; /* add a bit of space from rule/edge to text */
- }
-
- </style>
- <style type="text/css" media="all">
- code {
- font-weight:bold;
- font-size:larger;
- }
- /* ReSpec uses color ff4500 for code elements, which does not print well on some black & white printers
- and is a little hard to read for some folks even on-line.
- The default code font size was also somewhat too small/hard to read.
- */
- </style>
- <style>/*****************************************************************
- * ReSpec 3 CSS
- * Robin Berjon - http://berjon.com/
- *****************************************************************/
-
-/* --- INLINES --- */
-em.rfc2119 {
- text-transform: lowercase;
- font-variant: small-caps;
- font-style: normal;
- color: #900;
-}
-
-h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
-h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
- border: none;
-}
-
-dfn {
- font-weight: bold;
-}
-
-a.internalDFN {
- color: inherit;
- border-bottom: 1px solid #99c;
- text-decoration: none;
-}
-
-a.externalDFN {
- color: inherit;
- border-bottom: 1px dotted #ccc;
- text-decoration: none;
-}
-
-a.bibref {
- text-decoration: none;
-}
-
-cite .bibref {
- font-style: normal;
-}
-
-code {
- color: #C83500;
-}
-
-/* --- TOC --- */
-.toc a, .tof a {
- text-decoration: none;
-}
-
-a .secno, a .figno {
- color: #000;
-}
-
-ul.tof, ol.tof {
- list-style: none outside none;
-}
-
-.caption {
- margin-top: 0.5em;
- font-style: italic;
-}
-
-/* --- TABLE --- */
-table.simple {
- border-spacing: 0;
- border-collapse: collapse;
- border-bottom: 3px solid #005a9c;
-}
-
-.simple th {
- background: #005a9c;
- color: #fff;
- padding: 3px 5px;
- text-align: left;
-}
-
-.simple th[scope="row"] {
- background: inherit;
- color: inherit;
- border-top: 1px solid #ddd;
-}
-
-.simple td {
- padding: 3px 10px;
- border-top: 1px solid #ddd;
-}
-
-.simple tr:nth-child(even) {
- background: #f0f6ff;
-}
-
-/* --- DL --- */
-.section dd > p:first-child {
- margin-top: 0;
-}
-
-.section dd > p:last-child {
- margin-bottom: 0;
-}
-
-.section dd {
- margin-bottom: 1em;
-}
-
-.section dl.attrs dd, .section dl.eldef dd {
- margin-bottom: 0;
-}
-
-@media print {
- .removeOnSave {
- display: none;
- }
-}
-</style><style>/* --- EXAMPLES --- */
-div.example-title {
- min-width: 7.5em;
- color: #b9ab2d;
-}
-div.example-title span {
- text-transform: uppercase;
-}
-aside.example, div.example, div.illegal-example {
- padding: 0.5em;
- margin: 1em 0;
- position: relative;
- clear: both;
-}
-div.illegal-example { color: red }
-div.illegal-example p { color: black }
-aside.example, div.example {
- padding: .5em;
- border-left-width: .5em;
- border-left-style: solid;
- border-color: #e0cb52;
- background: #fcfaee;
-}
-
-aside.example div.example {
- border-left-width: .1em;
- border-color: #999;
- background: #fff;
-}
-aside.example div.example div.example-title {
- color: #999;
-}
-</style><link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/W3C-WD"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
-<body class="h-entry" role="document" id="respecDocument"><div class="head" role="contentinfo" id="respecHeader">
- <p>
-
- <a href="http://www.w3.org/"><img width="72" height="48" src="https://www.w3.org/Icons/w3c_home" alt="W3C"></a>
-
- </p>
- <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform Paging 1.0</h1>
-
- <h2 property="dcterms:issued" datatype="xsd:dateTime" content="2014-08-28T04:00:00.000Z" id="w3c-last-call-working-draft-28-august-2014"><abbr title="World Wide Web Consortium">W3C</abbr> Last Call Working Draft <time class="dt-published" datetime="2014-08-28">28 August 2014</time></h2>
- <dl>
-
- <dt>This version:</dt>
- <dd><a class="u-url" href="http://www.w3.org/TR/2014/WD-ldp-paging-20140828/">http://www.w3.org/TR/2014/WD-ldp-paging-20140828/</a></dd>
- <dt>Latest published version:</dt>
- <dd><a href="http://www.w3.org/TR/ldp-paging/">http://www.w3.org/TR/ldp-paging/</a></dd>
-
-
- <dt>Latest editor's draft:</dt>
- <dd><a href="http://www.w3.org/2012/ldp/hg/ldp-paging.html">http://www.w3.org/2012/ldp/hg/ldp-paging.html</a></dd>
-
-
-
-
-
-
- <dt>Previous version:</dt>
- <dd><a rel="dcterms:replaces" href="http://www.w3.org/TR/2013/WD-ldp-20130730/">http://www.w3.org/TR/2013/WD-ldp-20130730/</a></dd>
-
-
- <dt>Editors:</dt>
- <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Steve Speicher" href="http://stevespeicher.blogspot.com">Steve Speicher</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://ibm.com/">IBM Corporation</a></span>
-</dd>
-<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="John Arwe" href="https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?userid=120000CAW7">John Arwe</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://ibm.com/">IBM Corporation</a></span>
-</dd>
-<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Ashok Malhotra" href="mailto:ashok.malhotra@oracle.com">Ashok Malhotra</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oracle.com">Oracle Corporation</a></span>
-</dd>
-
-
-
- </dl>
-
-
-
-
-
- <p class="copyright">
- <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
- 2012
-
- <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
- (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
- <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
- <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>),
-
- All Rights Reserved.
-
- <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
- <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
-
- <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
-
- rules apply.
- </p>
-
-
- <hr>
-</div>
-<section id="abstract" class="introductory" property="dcterms:abstract" datatype="" typeof="bibo:Chapter" resource="#abstract" rel="bibo:Chapter"><h2 aria-level="1" role="heading" id="h2_abstract">Abstract</h2><p>
-This document describes a HTTP-based protocol for clients and servers to be able to efficiently retrieve large Linked Data Platform
-Resource representations by splitting up the responses into separate URL-addressable page resources.
-</p></section><section id="sotd" class="introductory" typeof="bibo:Chapter" resource="#sotd" rel="bibo:Chapter"><h2 aria-level="1" role="heading" id="h2_sotd">Status of This Document</h2>
-
-
-
- <p>
- <em>This section describes the status of this document at the time of its publication.
- Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the
- latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
- http://www.w3.org/TR/.</em>
- </p>
-
- <p>
- This is the second Last Call Working Draft document for LDP Paging. The Working Group has addressed all
- raised issues, and other substantive changes have been made, including the decision to separate LDP Paging
- from the Linked Data Platform [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>]. Public working drafts of LDP issued prior to March 2014
- included sections that covered the content now in this document.
- For changes since its last publication, see <a href="#history" class="sectionRef sec-ref">section <span class="secno">C.</span> <span class="sec-title">Change History</span></a>.
- </p>
- <p>The following features are At Risk:</p>
- <ol>
- <li>The requirement to make LDP clients <a href="#atrisk-paging">paging-aware</a>.
- </li>
- <li>The <a href="#atrisk-units"><code>max-member-count</code> and <code>max-kbyte-count</code> preference parameters</a>,
- that allows clients to hint at acceptable page sizes. Based on feedback, either or both might be removed or
- changed to optional prior to the PR draft.
- </li>
- <li>The behavior of LDP Paging servers when <a href="#atrisk-paging-multiple-units">multiple page size hints are provided</a>.
- </li>
- </ol>
-
- <p>
- This document was published by the <a href="http://www.w3.org/2012/ldp">Linked Data Platform Working Group</a> as a Last Call Working Draft.
-
- This document is intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation.
-
-
- If you wish to make comments regarding this document, please send them to
- <a href="mailto:public-ldp-comments@w3.org">public-ldp-comments@w3.org</a>
- (<a href="mailto:public-ldp-comments-request@w3.org?subject=subscribe">subscribe</a>,
- <a href="http://lists.w3.org/Archives/Public/public-ldp-comments/">archives</a>).
-
- The Last Call period ends 18 September 2014.
-
-
- All comments are welcome.
-
- </p>
-
-
- <p>
- Publication as a Last Call Working Draft does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr>
- Membership. This is a draft document and may be updated, replaced or obsoleted by other
- documents at any time. It is inappropriate to cite this document as other than work in
- progress.
- </p>
-
-
-
- <p>
- This is a Last Call Working Draft and thus the Working Group has determined that this
- document has satisfied the relevant technical requirements and is sufficiently stable to
- advance through the Technical Recommendation process.
- </p>
-
- <p>
-
- This document was produced by a group operating under the
- <a id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent
- Policy</a>.
-
-
-
-
- <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/55082/status" rel="disclosure">public list of any patent
- disclosures</a>
-
- made in connection with the deliverables of the group; that page also includes
- instructions for disclosing a patent. An individual who has actual knowledge of a patent
- which the individual believes contains
- <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
- Claim(s)</a> must disclose the information in accordance with
- <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
- 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
-
-
- </p>
-
-
-</section><section id="toc"><h2 class="introductory" aria-level="1" role="heading" id="h2_toc">Table of Contents</h2><ul class="toc" role="directory" id="respecContents"><li class="tocline"><a href="#intro" class="tocxref"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a href="#terms" class="tocxref"><span class="secno">2. </span>Terminology</a><ul class="toc"><li class="tocline"><a href="#terms-from-ldp" class="tocxref"><span class="secno">2.1 </span>Terms re-used from the Linked Data Platform</a></li><li class="tocline"><a href="#terms-from-paging" class="tocxref"><span class="secno">2.2 </span>Terms normatively defined by this specification</a></li><li class="tocline"><a href="#conventions" class="tocxref"><span class="secno">2.3 </span>Conventions Used in This Document</a></li></ul></li><li class="tocline"><a href="#conformance" class="tocxref"><span class="secno">3. </span>Conformance</a></li><li class="tocline"><a href="#ldpp-ex-mx" class="tocxref"><span class="secno">4. </span>Example paging message exchanges</a><ul class="toc"><li class="tocline"><a href="#ldpp-ex-no-paging" class="tocxref"><span class="secno">4.1 </span>Traditional flow without paging</a></li><li class="tocline"><a href="#ldpp-ex-paging-303" class="tocxref"><span class="secno">4.2 </span>Simple paging flow using redirects</a></li><li class="tocline"><a href="#ldpp-ex-paging-2nn" class="tocxref"><span class="secno">4.3 </span>Removing redirection latency when paging</a></li><li class="tocline"><a href="#ldpp-ex-paging-other-links" class="tocxref"><span class="secno">4.4 </span>Optional paging links</a></li></ul></li><li class="tocline"><a href="#ldppclient" class="tocxref"><span class="secno">5. </span>Linked Data Platform Paging Clients</a><ul class="toc"><li class="tocline"><a href="#general-requirements" class="tocxref"><span class="secno">5.1 </span>General requirements</a><ul class="toc"></ul></li><li class="tocline"><a href="#ldpp-hints" class="tocxref"><span class="secno">5.2 </span>Client preferences</a></li></ul></li><li class="tocline"><a href="#ldpr" class="tocxref"><span class="secno">6. </span>Linked Data Platform Resources</a><ul class="toc"><li class="tocline"><a href="#ldpr-PagingIntro" class="tocxref"><span class="secno">6.1 </span>Paging considerations</a></li><li class="tocline"><a href="#ldpr-PagingGET" class="tocxref"><span class="secno">6.2 </span>HTTP GET</a><ul class="toc"></ul></li></ul></li><li class="tocline"><a href="#ldpc" class="tocxref"><span class="secno">7. </span>Linked Data Platform Containers</a><ul class="toc"><li class="tocline"><a href="#ldpc-general" class="tocxref"><span class="secno">7.1 </span>Requirements when paging LDP Containers</a><ul class="toc"></ul></li><li class="tocline"><a href="#ldpc-informative" class="tocxref"><span class="secno">7.2 </span>Ordering of container members across pages</a><ul class="toc"></ul></li><li class="tocline"><a href="#ldpc-HTTP_GET" class="tocxref"><span class="secno">7.3 </span>HTTP GET requirements for member ordering across pages</a><ul class="toc"></ul></li></ul></li><li class="tocline"><a href="#security" class="tocxref"><span class="secno">8. </span>Security Considerations</a></li><li class="tocline"><a href="#ldpr-impl" class="tocxref"><span class="secno">A. </span>Paging LDPRs without maintaining server-side session state</a></li><li class="tocline"><a href="#acks" class="tocxref"><span class="secno">B. </span>Acknowledgements</a></li><li class="tocline"><a href="#history" class="tocxref"><span class="secno">C. </span>Change History</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">D. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">D.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">D.2 </span>Informative references</a></li></ul></li></ul></section>
-
-
-
-<section class="informative" id="intro" typeof="bibo:Chapter" resource="#intro" rel="bibo:Chapter">
-
-<!--OddPage--><h2 aria-level="1" role="heading" id="h2_intro"><span class="secno">1. </span>Introduction</h2><p><em>This section is non-normative.</em></p>
- <p>
- This specification provides a widely re-usable pattern to make the state of a large <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged HTTP resource</a>
- available as a list of smaller subset resources (<a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">pages</a>) whose
- representations are less burdensome for servers to form.
- <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">Paged resources</a> must be LDP Resources (LDPRs) [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>].
- Any <abbr title="Linked Data Platform Resource">LDPR</abbr> can be paged, but certain aspects of paging like ordering are only well-defined for
- particular sub-classes of LDPRs, like
- LDP-RSs or LDPCs.
- </p>
- <p>
- When a client attempts to retrieve a <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>, the server either redirects the client to
- a "first page" <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">resource</a> or provides the
- representation of the "first page" <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">resource</a> in its response,
- depending on the client's request preferences and the server's capabilities.
- The response
- includes links to other page(s) in the sequence, as do subsequent pages.
- <a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">Paging-aware clients</a>
- know how to combine pages of an <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>, and possibly (via other specifications) other LDPRs.
- LDP Paging defines a mechanism by which clients can learn that the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> has been changed
- so that they can, for example, abandon a page traversal as early as possible.
- A detailed example of paging is provided in <a href="#ldpp-ex-mx" class="sectionRef sec-ref">section <span class="secno">4.</span> <span class="sec-title">Example paging message exchanges</span></a>.
- </p>
- <p>
- When a <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> is also an <abbr title="Linked Data Platform Container">LDPC</abbr>, some additional efficiencies become possible in cases
- where the server predictably assigns members to pages and is able to communicate its assignment
- algorithm to clients. The <a href="#ldpc" class="sectionRef sec-ref">section <span class="secno">7.</span> <span class="sec-title">Linked Data Platform Containers</span></a> defines a facility to communicate
- the sort order of member-to-page assignments, to handle that common implementation algorithm.
- </p>
- <p>
- For context and background, it could be useful to read <a href="#bib-LDP-UCR">Linked Data Platform Use Case and Requirements</a> [<cite><a class="bibref" href="#bib-LDP-UCR">LDP-UCR</a></cite>].
- </p>
-</section>
-
-<section id="terms" typeof="bibo:Chapter" resource="#terms" rel="bibo:Chapter">
-<!--OddPage--><h2 aria-level="1" role="heading" id="h2_terms"><span class="secno">2. </span>Terminology</h2>
-
-<section id="terms-from-ldp" typeof="bibo:Chapter" resource="#terms-from-ldp" rel="bibo:Chapter">
-<h3 aria-level="2" role="heading" id="h3_terms-from-ldp"><span class="secno">2.1 </span>Terms re-used from the Linked Data Platform</h3>
-
-<p>This section is non-normative. It summarizes a subset of terms formally defined in [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>] for the reader's convenience.
-</p>
- <dl class="glossary">
-
- <dt><dfn id="dfn-ldp-server">LDP server</dfn></dt>
- <dd>A conforming HTTP server [<cite><a class="bibref" href="#bib-RFC7230">RFC7230</a></cite>] that follows the rules defined by [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>]
- when it is serving LDPRs and LDPCs.
- <p></p></dd>
-
- <dt><dfn id="dfn-ldp-client">LDP client</dfn></dt>
- <dd>A conforming HTTP client [<cite><a class="bibref" href="#bib-RFC7230">RFC7230</a></cite>] that follows the rules defined by [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>] when
- interacting with a <a href="#dfn-ldp-server" class="internalDFN">LDP server</a>.
- <p></p></dd>
-
- <dt><dfn id="dfn-linked-data-platform-resource">Linked Data Platform Resource</dfn> (<abbr title="Linked Data Platform Resource">LDPR</abbr>)</dt>
- <dd>A HTTP resource whose state is represented in any way that conforms to the
- patterns and conventions in [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>].<p></p></dd>
-
- <dt><dfn id="dfn-linked-data-platform-rdf-source">Linked Data Platform RDF Source</dfn> (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>)</dt>
- <dd>An <a title="Linked Data Platform Resource" href="#dfn-linked-data-platform-resource" class="internalDFN"><abbr title="Linked Data Platform Resource">LDPR</abbr></a> whose state is fully represented in RDF.
- <p></p></dd>
-
- <dt><dfn id="dfn-linked-data-platform-container">Linked Data Platform Container</dfn> (<abbr title="Linked Data Platform Container">LDPC</abbr>)</dt>
- <dd>A <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> representing a collection of <a title="Linked Data Platform Resource" href="#dfn-linked-data-platform-resource" class="internalDFN">LDPRs</a> linked by
- <a href="#dfn-membership-triples" class="internalDFN">membership triples</a> and <a href="#dfn-containment-triples" class="internalDFN">containment triples</a>.
- <p></p></dd>
-
- <dt><dfn id="dfn-membership-triples">Membership triples</dfn></dt>
- <dd>A set of triples that lists an <a title="Linked Data Platform Container" href="#dfn-linked-data-platform-container" class="internalDFN"><abbr title="Linked Data Platform Container">LDPC</abbr>'s</a> members.
- <p></p></dd>
-
- <dt><dfn id="dfn-containment-triples">Containment triples</dfn></dt>
- <dd>
- A set of triples, maintained by an <abbr title="Linked Data Platform Container">LDPC</abbr>, that lists documents created by the <abbr title="Linked Data Platform Container">LDPC</abbr> but not yet deleted.
- <p></p></dd>
-
- </dl>
-
-</section>
-
-<section id="terms-from-paging" typeof="bibo:Chapter" resource="#terms-from-paging" rel="bibo:Chapter">
-<h3 aria-level="2" role="heading" id="h3_terms-from-paging"><span class="secno">2.2 </span>Terms normatively defined by this specification</h3>
-
-<p>The following terminology is based on <abbr title="World Wide Web Consortium">W3C</abbr>'s Architecture of the World Wide Web [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>],
- Hyper-text Transfer Protocol ([<cite><a class="bibref" href="#bib-RFC7230">RFC7230</a></cite>], [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>]) and Linked Data Platform [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>].
-</p>
- <dl class="glossary">
- <dt><dfn id="dfn-paged-resource">Paged resource</dfn></dt>
- <dd>A <abbr title="Linked Data Platform Resource">LDPR</abbr> whose representation may be too large for a server to construct in a single HTTP response
- (e.g. without running out of memory), for which an
- <a href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging server</a> offers a <a href="#dfn-page-sequence" class="internalDFN">page sequence</a> that allows clients to obtain subsets of its state
- over some period of time by making multiple HTTP requests.
- <p>
- For readers
- familiar with paged feeds [<cite><a class="bibref" href="#bib-RFC5005">RFC5005</a></cite>], a paged resource is similar to a logical feed.
- Any resource could be considered to be a paged resource consisting of exactly one page,
- although there is no known advantage in doing so.
- </p>
- <p></p></dd>
-
- <dt><dfn id="dfn-page-sequence">Page sequence</dfn></dt>
- <dd>A sequence of related <a title="Linked Data Platform Resource" href="#dfn-linked-data-platform-resource" class="internalDFN">LDPRs</a>
- <var>P<sub>1 (first)</sub>, P<sub>2</sub>, ...,P<sub>n (last)</sub></var>,
- each of which contains a subset of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>'s state.
- <p>
- When the representations of the sequence's <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">resources</a>
- are combined by a client, the client has a copy of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>'s
- state; if the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> changed while the client was retrieving the sequence's resources,
- then the client's copy of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>'s state can be incomplete or inconsistent
- with the state of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> at any single instant in time.
- Thus, it is impossible to strongly guarantee that the result of this retrieval and combination process is the same state that
- the client would obtain using a single request (if that were possible), but LDP does provide
- a way for <a href="#ldpr-notify-changes">clients to detect when the paged resource's state changed</a> during the retrieval process.
- As long as the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>'s state did not change during the retrieval process, the
- client's copy of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>'s state will be as accurate as the server implementation
- allows it to be.
- </p>
- <p>
- If a paged resource <var>P</var> is a <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>,
- the representation of each <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> contains
- a subset of the triples in <var>P</var>, and a client can merge those graphs to combine them.
- LDP allows paging of resources other than <a title="Linked Data Platform RDF Source" href="#dfn-linked-data-platform-rdf-source" class="internalDFN">LDP-RSs</a>,
- but does not specify how clients combine
- their representations. See <a href="#ldpr" class="sectionRef sec-ref">section <span class="secno">6.</span> <span class="sec-title">Linked Data Platform Resources</span></a> for additional details.
- </p>
- For readers
- familiar with paged feeds [<cite><a class="bibref" href="#bib-RFC5005">RFC5005</a></cite>], a <a href="#dfn-page-sequence" class="internalDFN">page sequence</a> is similar to a paged feed
- and many of the same consideration (echoed above) apply.
- <p></p></dd>
-
- <dt><dfn id="dfn-in-sequence-page-resource">In-sequence page resource</dfn></dt>
- <dd>One <abbr title="Linked Data Platform Resource">LDPR</abbr> in a <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>,
- which contains a subset of the state
- of another resource <var>P</var>, called the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>.
- For readers
- familiar with paged feeds [<cite><a class="bibref" href="#bib-RFC5005">RFC5005</a></cite>], an in-sequence page resource is similar to a feed document.
- <p>
- Note: the choice of terms was designed to help authors and readers clearly differentiate between
- the <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN"><em>resource being paged</em></a>, and the
- <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN"><em>individual page resources</em></a>,
- in cases where both are mentioned in
- close proximity.
- </p>
- <p>
- Note: page sequences are described and named with respect to how they are traversed starting from the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>,
- using only <a href="#dfn-forward-traversal" class="internalDFN">forward traversal</a>.
- This <em>does not</em> imply anything more; the choice is arbitrary.
- For example, following forward links does not imply that resources later in the sequence are newer; the forward direction might
- correspond to moving forward or backward in time or along some other dimension, but any such relationship is server-specific.
- It is not implied by LDP Paging,
- absent additional concrete assertions like those <a href="#ldpc-HTTP_GET">defined later</a> for <abbr title="Linked Data Platform Container">LDPC</abbr> representations.
- </p>
- <p></p></dd>
-
- <dt><dfn id="dfn-first-page-link">first page link</dfn></dt>
- <dd>A link to the first <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> <var>P<sub>1 (first)</sub></var>
- of a <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>. The first page is the one that a LDP paging server
- redirects to (<code>303</code> response) or provides the representation of (<code>2NN</code> response) in response
- to a retrieval request for the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>'s URI.
- Syntactically, a
- HTTP <code>Link <<var>P<sub>1</sub></var>>; rel='first'</code>
- header [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
- <p></p></dd>
-
- <dt><dfn id="dfn-next-page-link">next page link</dfn></dt>
- <dd>A link to the next <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
- of a <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>. Syntactically, a
- HTTP <code>Link <<var>P<sub>i</sub></var>>; rel='next'</code>
- header [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>] where
- the context URI identifies some <var>P<sub>i=1 (first)...n-1 (next to last)</sub></var> and
- the target URI identifies <var>P<sub>i+1</sub></var>.
- <p></p></dd>
-
- <dt><dfn id="dfn-last-page-link">last page link</dfn></dt>
- <dd>A link to the last <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> <var>P<sub>n (last)</sub></var>
- of a <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>.
- The last page is the page that terminates a <a href="#dfn-forward-traversal" class="internalDFN">forward traversal</a>, because it contains no <a href="#dfn-next-page-link" class="internalDFN">next page link</a>.
- Syntactically, a
- HTTP <code>Link <<var>P<sub>n</sub></var>>; rel='last'</code>
- header [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
- <p></p></dd>
-
- <dt><dfn id="dfn-previous-page-link">previous page link</dfn></dt>
- <dd>A link to the previous <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
- of a <a href="#dfn-page-sequence" class="internalDFN">page sequence</a> Syntactically, a
- HTTP <code>Link <<var>P<sub>i</sub></var>>; rel='prev'</code>
- header [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>] where
- the context URI identifies some <var>P<sub>i=2...n (last)</sub></var> and
- the target URI identifies <var>P<sub>i-1</sub></var>.
- <p></p></dd>
-
- <dt><dfn id="dfn-paging-link">paging link</dfn></dt>
- <dd>Any of the links defined by LDP Paging:
- <a title="first page link" href="#dfn-first-page-link" class="internalDFN">first page links</a>,
- <a title="next page link" href="#dfn-next-page-link" class="internalDFN">next page links</a>,
- <a title="last page link" href="#dfn-last-page-link" class="internalDFN">last page links</a>,
- <a title="previous page link" href="#dfn-previous-page-link" class="internalDFN">previous page links</a>.
- <p></p></dd>
-
- <dt><dfn id="dfn-forward-traversal">forward traversal</dfn></dt>
- <dd>The process of following <a title="next page link" href="#dfn-next-page-link" class="internalDFN">next page links</a> from
- some starting point.
- <p>
- Note: "forward" should <i>not</i> be read to mean anything more than a name for one direction through the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>.
- For example, following forward links does not imply that resources later in the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a> are newer; the forward direction might
- correspond to moving forward in time, but any such relationship is server-specific not implied by LDP Paging
- absent additional concrete assertions like those <a href="#ldpc-HTTP_GET">defined later</a> for <abbr title="Linked Data Platform Container">LDPC</abbr> representations.
- </p>
- <p></p></dd>
-
- <dt><dfn id="dfn-backward-traversal">backward traversal</dfn></dt>
- <dd>The process of following <a title="previous page link" href="#dfn-previous-page-link" class="internalDFN">previous page links</a> from
- some starting point.
- <p>
- Note: "backward" should <i>not</i> be read to mean anything more than a name for one direction through the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>.
- </p>
- <p></p></dd>
-
- </dl>
-</section>
-
-<section id="conventions" typeof="bibo:Chapter" resource="#conventions" rel="bibo:Chapter">
-<h3 aria-level="2" role="heading" id="h3_conventions"><span class="secno">2.3 </span>Conventions Used in This Document</h3>
-
- <p>The namespace for LDP Paging is <code>http://www.w3.org/ns/ldp#</code>.</p>
- <p>Sample resource representations are provided in <code>text/turtle</code>
- format [<cite><a class="bibref" href="#bib-turtle">turtle</a></cite>].</p>
- <p>Commonly used namespace prefixes:</p>
- <pre style="word-wrap: break-word; white-space: pre-wrap;">
- @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#>.
- </pre>
-</section>
-</section>
-
-<section id="conformance" typeof="bibo:Chapter" resource="#conformance" rel="bibo:Chapter"><!--OddPage--><h2 aria-level="1" role="heading" id="h2_conformance"><span class="secno">3. </span>Conformance</h2>
-<p>
- As well as sections marked as non-normative, all authoring guidelines, diagrams, examples,
- and notes in this specification are non-normative. Everything else in this specification is
- normative.
-</p>
-<p>
- The key words <em class="rfc2119" title="MUST">MUST</em>, <em class="rfc2119" title="MUST NOT">MUST NOT</em>, <em class="rfc2119" title="REQUIRED">REQUIRED</em>, <em class="rfc2119" title="SHOULD">SHOULD</em>, <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em>, <em class="rfc2119" title="RECOMMENDED">RECOMMENDED</em>, <em class="rfc2119" title="MAY">MAY</em>,
- and <em class="rfc2119" title="OPTIONAL">OPTIONAL</em> in this specification are to be interpreted as described in [<cite><a class="bibref" href="#bib-RFC2119">RFC2119</a></cite>].
-</p>
-
-
-<p>The status of the sections of Linked Data Platform Paging 1.0 (this document) is as follows:</p>
-
-<ul>
- <li><a href="#intro" class="sectionRef sec-ref">section <span class="secno">1.</span> <span class="sec-title">Introduction</span></a>: <b>non-normative</b></li>
- <li><a href="#terms" class="sectionRef sec-ref">section <span class="secno">2.</span> <span class="sec-title">Terminology</span></a>
- <ul>
- <li><a href="#terms-from-ldp" class="sectionRef sec-ref">section <span class="secno">2.1</span> <span class="sec-title">Terms re-used from the Linked Data Platform</span></a>: <b>non-normative</b></li>
- <li><a href="#terms-from-paging" class="sectionRef sec-ref">section <span class="secno">2.2</span> <span class="sec-title">Terms normatively defined by this specification</span></a>: <b>normative</b></li>
- <li><a href="#conventions" class="sectionRef sec-ref">section <span class="secno">2.3</span> <span class="sec-title">Conventions Used in This Document</span></a>: <b>normative</b></li>
- </ul>
- </li>
- <li><a href="#conformance" class="sectionRef sec-ref">section <span class="secno">3.</span> <span class="sec-title">Conformance</span></a>: <b>normative</b></li>
- <li><a href="#ldpp-ex-mx" class="sectionRef sec-ref">section <span class="secno">4.</span> <span class="sec-title">Example paging message exchanges</span></a>: <b>non-normative</b></li>
- <li><a href="#ldppclient" class="sectionRef sec-ref">section <span class="secno">5.</span> <span class="sec-title">Linked Data Platform Paging Clients</span></a>: <b>normative</b></li>
- <li><a href="#ldpr" class="sectionRef sec-ref">section <span class="secno">6.</span> <span class="sec-title">Linked Data Platform Resources</span></a>: <b>normative</b></li>
- <li><a href="#ldpc" class="sectionRef sec-ref">section <span class="secno">7.</span> <span class="sec-title">Linked Data Platform Containers</span></a>: <b>normative</b></li>
- <li><a href="#security" class="sectionRef sec-ref">section <span class="secno">8.</span> <span class="sec-title">Security Considerations</span></a>: <b>non-normative</b></li>
- <li><a href="#ldpr-impl" class="sectionRef sec-ref">section <span class="secno">A.</span> <span class="sec-title">Paging LDPRs without maintaining server-side session state</span></a>: <b>non-normative</b></li>
- <li><a href="#acks" class="sectionRef sec-ref">section <span class="secno">B.</span> <span class="sec-title">Acknowledgements</span></a>: <b>non-normative</b></li>
- <li><a href="#history" class="sectionRef sec-ref">section <span class="secno">C.</span> <span class="sec-title">Change History</span></a>: <b>non-normative</b></li>
- <li><a href="#normative-references" class="sectionRef sec-ref">section <span class="secno">D.1</span> <span class="sec-title">Normative references</span></a>: <b>normative</b></li>
- <li><a href="#informative-references" class="sectionRef sec-ref">section <span class="secno">D.2</span> <span class="sec-title">Informative references</span></a>: <b>non-normative</b></li>
-</ul>
-
-<p>A conforming <b><dfn id="dfn-ldp-paging-client">LDP Paging client</dfn></b> is a conforming LDP client [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>] that follows the rules defined by LDP Paging.
-</p>
-
-<p>A conforming <b><dfn id="dfn-ldp-paging-server">LDP Paging server</dfn></b> is a conforming LDP server [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>] that follows the rules defined by LDP Paging.</p>
-</section>
-
-<section class="informative" id="ldpp-ex-mx" typeof="bibo:Chapter" resource="#ldpp-ex-mx" rel="bibo:Chapter">
-<!--OddPage--><h2 aria-level="1" role="heading" id="h2_ldpp-ex-mx"><span class="secno">4. </span>Example paging message exchanges</h2><p><em>This section is non-normative.</em></p>
-
- <p>
- Example Co.'s customer
- relationship data is identified by the URI <code>http://example.org/customer-relations</code>,
- and is retrievable using the same URI.
- </p>
-
-<section id="ldpp-ex-no-paging" typeof="bibo:Chapter" resource="#ldpp-ex-no-paging" rel="bibo:Chapter">
-<h3 aria-level="2" role="heading" id="h3_ldpp-ex-no-paging"><span class="secno">4.1 </span>Traditional flow without paging</h3>
-
- <p>
- A standard HTTP client that knows nothing about LDP paging obtains a representation of the
- resource in the usual way.
- </p>
-
- <em>Request</em>
-<div class="example"><div class="example-title"><span>Example 1</span></div><pre class="example">GET /customer-relations HTTP/1.1
-Host: example.org
-Accept: text/turtle</pre></div>
-
- <p>
- The server response is:
- </p>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 2</span></div><pre class="example" id="ldpp-ex-no-paging-resp">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".</pre></div>
-
- <p>
- As long as the resource being retrieved is small enough that the server can form its
- representation without running into implementation limits on memory etc., and as long
- as the client is likewise able to consume these representations, this pattern works
- fine. Indeed, it's by far the most common pattern on the Web.
- </p>
- <p>
- At the point where server and/or client constraints or consumption preferences come into play, however,
- something else is needed. LDP Paging addresses this need by giving clients and
- servers the ability to partition representations into smaller pieces, transfer
- as many as the client needs (potentially a small subset of the resource's full
- state), and allows the client to reassemble the pieces (or not) as it prefers.
- One sees this pattern in contexts such as search page results, as one common
- example.
- </p>
-
-</section>
-
-<section id="ldpp-ex-paging-303" typeof="bibo:Chapter" resource="#ldpp-ex-paging-303" rel="bibo:Chapter">
-<h3 aria-level="2" role="heading" id="h3_ldpp-ex-paging-303"><span class="secno">4.2 </span>Simple paging flow using redirects</h3>
-
- <p>
- The simplest possible solution would be to redefine the meaning of the existing
- URI <code>http://example.org/customer-relations</code> from "all customer relations information"
- to "the first subset of all customer relations information". This would require changes to
- any existing clients whose code was built using the original definition however, so it's
- more likely that Example Co. would mint a new URI for "the first subset", define a way to
- find subsequent subsets, and have clients use this new protocol.
- </p>
- <p>
- The new protocol does not solve the problem of migrating existing clients from the old
- "all" to the new "first subset" semantic; neither would a <code>303 See Other</code> redirect
- from the old to the new URI, given the
- <a href="http://www.w3.org/2001/tag/issues.html#httpRange-14">widespread historical client practice</a> of automatically
- following <code>303</code> redirects and treating the redirected-to resource as equivalent
- to the original. The safe route is to have clients explicitly tell the server that they
- are capable of handling the "first subset" semantic on the redirected-to URI; this is what
- LDP Paging does.
- </p>
- <p>
- A client aware of LDP paging obtains a representation of the
- resource in the usual way, and also signals its ability to handle redirection to a first-page resource:
- </p>
-
-<em>Request</em>
-<div class="example"><div class="example-title"><span>Example 3</span></div><pre class="example">GET /customer-relations HTTP/1.1
-Host: example.org
-Accept: text/turtle
-Prefer: return=representation; max-triple-count="500"</pre></div>
-
- <p>
- The server's response contains a <code>303 See Other</code> status code and
- a <code>Location: http://example.org/customer-relations?page1</code> HTTP response header
- identifying the target resource, as shown below:
- </p>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 4</span></div><pre class="example" id="ldpp-ex-paging-303-resp1">HTTP/1.1 303 See Other
-Location: <http://example.org/customer-relations?page1></pre></div>
-
- <p>
- At this point the client does not know if the target
- resource is "all" or "the first subset"; it has to retrieve the resource to know.
- </p>
-
-<em>Request</em>
-<div class="example"><div class="example-title"><span>Example 5</span></div><pre class="example">GET /customer-relations?page1 HTTP/1.1
-Host: example.org
-Accept: text/turtle
-Prefer: return=representation; max-triple-count="500"</pre></div>
- <p>
- The server's response is shown below:
- </p>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 6</span></div><pre class="example" id="ldpp-ex-paging-303-resp2">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".</pre></div>
-
- <p>
- From this response, the client knows that more data exists and where to find it.
- The server determines the size of the pages using application-specific methods not defined
- within this specification, with the client's <code>max-triple-count</code> preference as one
- input; the simplest method is to make the server's page size equal
- to the client's preference. In this example, the server chooses a smaller value so
- there is a second page.
- </p>
- <ul>
- <li>
- The <code>Link: <http://example.org/customer-relations>; rel='canonical'</code>
- response header tells the client which resource <code><http://example.org/customer-relations?page1></code>
- is a page of. The <code>etag="customer-relations-v1"</code> parameter value gives the client a way to know,
- during its page traversal, whether or not the canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> has changed; not all
- clients will use this information, but it is there for those that can make use of it.
- </li>
- <li>
- The <code>Link: <http://www.w3.org/ns/ldp#Page>; rel="type"</code>
- response header tells the client that this is one <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>, and therefore it
- needs to examine the other response headers to see if more data existed in the
- canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> when the response
- was generated by the server.
- </li>
- <li>
- The <code>Link: <http://example.org/customer-relations?p=2>; rel='next'</code>
- response header tells the client that at least one more <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> exists,
- and how to retrieve its representation. The next page link's target URI is
- defined by the server and is not constrained by this specification.
- </li>
- </ul>
- <p>
- The following example shows the message exchange for retrieving
- the next page:
- </p>
-
-<em>Request</em>
-<div class="example"><div class="example-title"><span>Example 7</span></div><pre class="example">GET /customer-relations?p=2 HTTP/1.1
-Host: example.org
-Accept: text/turtle
-Prefer: return=representation; max-triple-count="500"</pre></div>
- <p>
- The server's response is shown below:
- </p>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 8</span></div><pre class="example" id="ldpp-ex-paging-303-resp3">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".</pre></div>
-
- <p>
- In this example, there are only two customers provided in the
- second page.
- </p>
- <!-- DONE: show it both ways; if a competing change hit the container, or not.
- 6.2.2.7's non-normative note covers this case.
- -->
- <ul>
- <li>
- The <code>Link: <http://www.w3.org/ns/ldp#Page>; rel="type"</code>
- response header tells the client that this is one <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>, and therefore it
- needs to examine the other response headers to see if more data existed in the
- canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> when the response
- was generated by the server.
- </li>
- <li>
- The absence of a <code>Link: <http://example.org/customer-relations?p=2>; rel='next'</code>
- response header tells the client that no more <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>s existed in this <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>
- at the time the response was generated; repeating the request might result in a representation with links to more pages,
- if other processes are updating the customer relations data.
- </li>
- <li>
- Since the <code>etag="customer-relations-v1"</code> parameter value of the canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>
- did not change across the client's process of retrieving the entire <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>, it is assured that
- the merged response representations are equivalent to what it would have received had the server
- provided the entire representation of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> in a single <code>200 OK</code> response.
- The client has <em>no assurance</em> that the current state of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> remains unchanged
- since the final page's representation was generated. For example, after the server constructs the final page representation, another
- actor could delete <code>client#BettyASmith</code> from the server.
- </li>
- </ul>
-
-</section>
-
-<section id="ldpp-ex-paging-2nn" typeof="bibo:Chapter" resource="#ldpp-ex-paging-2nn" rel="bibo:Chapter">
-<h3 aria-level="2" role="heading" id="h3_ldpp-ex-paging-2nn"><span class="secno">4.3 </span>Removing redirection latency when paging</h3>
-
- <p>
- It is inconvenient that the <a href="#ldpp-ex-paging-303"><code>303 See Other</code> approach</a>
- requires three message exchanges to transfer two representations. Fortunately, it is possible to
- remove the extra message exchange, saving the latency and the server plus network overhead of
- servicing the <code>303</code> messages.
- </p>
- <p>
- If a client signals that it is capable of understanding the HTTP
- <a href="#atrisk-2NN">status code <code>2NN Contents of Related</code></a>, then the server can
- respond with <code>2NN Contents of Related</code> instead of <code>303 See Other</code> on the
- initial retrieval request, and it can also enclose the representation of the first page in the
- corresponding response.
- </p>
-
-<em>Request</em>
-<div class="example"><div class="example-title"><span>Example 9</span></div><pre class="example">GET /customer-relations HTTP/1.1
-Host: example.org
-Accept: text/turtle
-Prefer: return=representation; max-triple-count="500"
-Prefer: contents-of-related</pre></div>
-
- <p>
- The server's response is shown below; it includes a
- <a href="#atrisk-2NN">status code <code>2NN Contents of Related</code></a>,
- and a representation payload.
- </p>
- <p>
- As was true in the <a href="#ldpp-ex-paging-303"><code>303 See Other</code> approach</a>,
- the server includes
- a <code>Location: http://example.org/customer-relations?page1</code> HTTP response header
- identifying the first page as the resource whose representation is enclosed in the response.
- </p>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 10</span></div><pre class="example" id="ldpp-ex-paging-2nn-resp1">HTTP/1.1 2NN Contents of Related
-Content-Type: text/turtle
-ETag: "_87e52ce291112"
-Location: <http://example.org/customer-relations?page1>
-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".</pre></div>
-
- <p>
- From this response, the client knows that it received the representation of an
- <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> instead of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>,
- that at least one more page exists, and where to find the next page.
- The server determines the size of the pages using application-specific methods not defined
- within this specification, with the client's <code>max-triple-count</code> preference as one
- input; the simplest method is to make the server's page size equal
- to the client's preference. In this example, the server chooses a smaller value so
- there is a second page.
- </p>
- <ul>
- <li>
- The <code>2NN Contents of Related</code> status code
- tells the client that the response contains a representation of some resource <em>other than</em>
- the one identified by its effective request URI.
- </li>
- <li>
- The <code>Location: <http://example.org/customer-relations?page1></code>
- response header tells the client the identifier of the response representation's resource.
- In the context of a response with a <code>2NN Contents of Related</code> status code,
- it tells the client the "related" resource's identifier.
- </li>
- <li>
- The <code>Link: <http://example.org/customer-relations>; rel='canonical'</code>
- response header tells the client which resource <code><http://example.org/customer-relations?page1></code>
- is a page of, providing more specificity about the nature of the relationship between the
- resource identified by the effective
- request URI and the resource identified in the <code>Location</code> header.
- The <code>etag="customer-relations-v1"</code> parameter value gives the client a way to know,
- during its page traversal, whether or not the canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> has changed; not all
- clients will use this information, but it is there for those that can make use of it.
- </li>
- <li>
- The <code>Link: <http://www.w3.org/ns/ldp#Page>; rel="type"</code>
- response header tells the client that this is one <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>, and therefore it
- needs to examine the other response headers to see if more data existed in the
- canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> when the response
- was generated by the server.
- </li>
- <li>
- The <code>Link: <http://example.org/customer-relations?p=2>; rel='next'</code>
- response header tells the client that at least one more <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> exists,
- and how to retrieve its representation. The next page link's target URI is
- defined by the server and is not constrained by this specification.
- </li>
- </ul>
- <p>
- The following example shows the message exchange for retrieving
- the next page:
- </p>
-
-<em>Request</em>
-<div class="example"><div class="example-title"><span>Example 11</span></div><pre class="example">GET /customer-relations?p=2 HTTP/1.1
-Host: example.org
-Accept: text/turtle
-Prefer: return=representation; max-triple-count="500"
-Prefer: contents-of-related</pre></div>
- <p>
- The server's response is shown below:
- </p>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 12</span></div><pre class="example" id="ldpp-ex-paging-2nn-resp2">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".</pre></div>
-
- <p>
- In this example, there are only two customers provided in the
- second page.
- </p>
- <ul>
- <li>
- The <code>Link: <http://www.w3.org/ns/ldp#Page>; rel="type"</code>
- response header tells the client that this is one <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>, and therefore it
- needs to examine the other response headers to see if more data existed in the
- canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> when the response
- was generated by the server.
- </li>
- <li>
- The absence of a <code>Link: <http://example.org/customer-relations?p=2>; rel='next'</code>
- response header tells the client that no more <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>s existed in this <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>
- at the time the response was generated; repeating the request might result in a representation with links to more pages,
- if other processes are updating the customer relations data.
- </li>
- <li>
- Since the <code>etag="customer-relations-v1"</code> parameter value of the canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>
- did not change across the client's process of retrieving the entire <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>, it is assured that
- the merged response representations are equivalent to what it would have received had the server
- provided the entire representation of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> in a single <code>200 OK</code> response.
- The client has <em>no assurance</em> that the current state of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> remains unchanged
- since the final page's representation was generated. For example, after the server constructs the final page representation, another
- actor could delete <code>client#BettyASmith</code> from the server.
- </li>
- </ul>
-
-</section>
-
-<section id="ldpp-ex-paging-other-links" typeof="bibo:Chapter" resource="#ldpp-ex-paging-other-links" rel="bibo:Chapter">
-<h3 aria-level="2" role="heading" id="h3_ldpp-ex-paging-other-links"><span class="secno">4.4 </span>Optional paging links</h3>
-
- <p>
- The preceding paging examples in this section have all assumed that only <a href="#dfn-forward-traversal" class="internalDFN">forward traversal</a>
- is supported by the server, to reduce complexity.
- A server might also support <a href="#dfn-backward-traversal" class="internalDFN">backward traversal</a> through its pages, and/or direct access to the
- <a title="first page link" href="#dfn-first-page-link" class="internalDFN">first page</a> and/or <a title="last page link" href="#dfn-last-page-link" class="internalDFN">last page</a> from any <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>.
- Those options would be reflected by adding some combination of the links below,
- or equivalent semantically equivalent syntactic variations of them, to the response messages.
- </p>
-
- <ul>
- <li>
- The <a title="first page link" href="#dfn-first-page-link" class="internalDFN">first page</a>'s <a href="#ldpp-ex-paging-2nn-resp1">response message</a> might also have the following links:
-<div class="example"><div class="example-title"><span>Example 13</span></div><pre class="example">Link: <>; rel='first'
-Link: <http://example.org/customer-relations?p=2>; rel='last'</pre></div>
- </li>
- <li>
- Any <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>'s response message, including the <a title="first page link" href="#dfn-first-page-link" class="internalDFN">first page</a> and the <a title="last page link" href="#dfn-last-page-link" class="internalDFN">last page</a>,
- might also have the following links:
-<div class="example"><div class="example-title"><span>Example 14</span></div><pre class="example">Link: <http://example.org/customer-relations?page1>; rel='first'
-Link: <http://example.org/customer-relations?p=2>; rel='last'</pre></div>
- </li>
- <li>
- The <a title="last page link" href="#dfn-last-page-link" class="internalDFN">last page</a>'s <a href="#ldpp-ex-paging-2nn-resp2">response message</a> might also have the following links:
-<div class="example"><div class="example-title"><span>Example 15</span></div><pre class="example">Link: <http://example.org/customer-relations?page1>; rel='first'
-Link: <http://example.org/customer-relations?page1>; rel='prev'
-Link: <>; rel='last'</pre></div>
- </li>
- </ul>
-
-</section>
-
-</section> <!-- Example message exchanges -->
-
-<section id="ldppclient" typeof="bibo:Chapter" resource="#ldppclient" rel="bibo:Chapter">
-<!--OddPage--><h2 aria-level="1" role="heading" id="h2_ldppclient"><span class="secno">5. </span>Linked Data Platform Paging Clients</h2>
-<p>All of the following are conformance rules for <a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging Clients</a>.
-</p>
-<section id="general-requirements"><h3 aria-level="2" role="heading" id="h3_general-requirements"><span class="secno">5.1 </span>General requirements</h3>
-
- <section id="ldpp-client-advertise" typeof="bibo:Chapter" resource="#ldpp-client-advertise" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-client-advertise"><span class="secno">5.1.1 </span><a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging clients</a> <em class="rfc2119" title="MUST">MUST</em>
- <a href="#ldpp-hints">advertise their ability to support LDP Paging</a> on all retrieval requests that normally result in
- a response containing a representation.
- </h4>
- </section>
-
- <section id="ldpp-client-traversal" typeof="bibo:Chapter" resource="#ldpp-client-traversal" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-client-traversal"><span class="secno">5.1.2 </span><a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging clients</a> <em class="rfc2119" title="MUST">MUST</em>
- be capable of at least one of <a href="#dfn-forward-traversal" class="internalDFN">forward traversal</a> and/or <a href="#dfn-backward-traversal" class="internalDFN">backward traversal</a>.
- </h4>
- </section>
-
- <section id="ldpp-client-linkschg" typeof="bibo:Chapter" resource="#ldpp-client-linkschg" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-client-linkschg"><span class="secno">5.1.3 </span><a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging clients</a> <em class="rfc2119" title="MUST NOT">MUST NOT</em>
- assume that any <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource's</a> <a title="paging link" href="#dfn-paging-link" class="internalDFN">paging links</a>
- will remain unchanged when the <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
- is retrieved more than once. Such an assumption would
- conflict with a server's ability to
- <a href="#ldpr-pagingGET-sequences-change">add pages to a sequence</a> as the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> changes, for example.
- </h4>
- </section>
-
- <section id="ldpp-client-4xxok" typeof="bibo:Chapter" resource="#ldpp-client-4xxok" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-client-4xxok"><span class="secno">5.1.4 </span><a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging clients</a> <em class="rfc2119" title="MUST NOT">MUST NOT</em>
- assume that any <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource's</a> <a title="paging link" href="#dfn-paging-link" class="internalDFN">paging links</a>
- will always be accessible.</h4>
- <blockquote><em>Non-normative note:</em>
- Such an assumption would
- conflict with a server's ability to <a href="#ldpr-pagingGET-sequences-change">remove pages from a sequence</a>
- as the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> changes, for example.
- One consequence of this is that clients can receive responses with <code>4xx</code> status codes
- when following page links, purely due to timing issues and without any error on the part of the client
- or the server. Such a response would be unusual, and would likely signal an error,
- if the response also indicates that the <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged resource's</a>
- <a href="#ldpr-notify-changes">state has <i>not</i> changed</a>
- while the client was traversing its <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">pages</a>.
- Servers might also limit the lifetime of a particular <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>, and client requests after the server has
- abandoned that sequence are likely to result in <code>410 Gone</code> or other <code>4xx</code> status codes.
- </blockquote>
-
- </section>
-
- <section id="ldpp-client-paging-incomplete" typeof="bibo:Chapter" resource="#ldpp-client-paging-incomplete" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-client-paging-incomplete"><span class="secno">5.1.5 </span><a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging clients</a>
- <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> treat a page sequence as equivalent to the <a title="paged resource" href="#dfn-paged-resource" class="internalDFN">paged resource</a>
- when the <a href="#ldpr-notify-changes">paged resource changed</a>
- <a href="#ldpr-guarantee-show-unchanged">during retrieval of the page sequence</a>.
- </h4></section>
-
- <section id="ldpp-client-nofollow-303" typeof="bibo:Chapter" resource="#ldpp-client-nofollow-303" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-client-nofollow-303"><span class="secno">5.1.6 </span><a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging clients</a>
- <em class="rfc2119" title="MUST NOT">MUST NOT</em> treat the target of a <code>303 See Other</code> redirection as a replacement for the original resource.
- That is, they cannot treat a <code>303</code> status code as if it was a
- <code>307 Temporary Redirect</code> [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>] or <code>308 Permanent Redirect</code> [<cite><a class="bibref" href="#bib-RFC7238">RFC7238</a></cite>],
- as [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>] makes clear. This is critical to a client's ability to distinguish between the representation
- of a single <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> and that of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> when a <a href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging server</a>
- uses <a href="#ldpr-status-code">redirection</a> as a way to initiate paging.
- </h4></section>
-
-</section>
-
-<section id="ldpp-hints" typeof="bibo:Chapter" resource="#ldpp-hints" rel="bibo:Chapter">
-<h3 aria-level="2" role="heading" id="h3_ldpp-hints"><span class="secno">5.2 </span>Client preferences</h3>
- <p>
- LDP Paging clients <a href="#ldpp-client-advertise">must provide paging-related hints</a>
- in order to influence an LDP Paging server's choices.
- </p>
-
- <p>
- This specification introduces new
- parameters on the HTTP <code>Prefer</code> request header's
- <code>return=representation</code> preference [<cite><a class="bibref" href="#bib-RFC7240">RFC7240</a></cite>], <a href="#ldpp-client-advertise">used by clients</a> to
- supply a preference that helps the server form a response that is most appropriate to
- the client's needs. The presence of any parameter defined in this section serves several purposes:
- </p><ul>
- <li>It signals the client's support for LDP Paging to the request server</li>
- <li>It communicates the client's maximum desired size for a response representation</li>
- </ul>
- <p></p>
-
- <div class="atrisk" id="atrisk-paging"><p class="atrisktext">Feature At Risk</p>
- <p>The LDP Working Group proposes incorporation of the following clause to make LDP clients paging aware:</p>
- <section id="ldpr-cli-paging" typeof="bibo:Chapter" resource="#ldpr-cli-paging" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-cli-paging">
- <a title="LDP client" href="#dfn-ldp-client" class="internalDFN">LDP clients</a> <em class="rfc2119" title="SHOULD">SHOULD</em>
- be capable of processing successful HTTP <code>GET</code> responses formed by a LDP server
- that independently initiated paging, returning a page of representation instead of full resource
- representation [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>].
- </h4>
- </section>
- </div>
-
- <div class="atrisk" id="atrisk-units"><p class="atrisktext">Feature At Risk</p>
- <p>The LDP Working Group proposes incorporation of the preference parameters
- <code>max-member-count</code> and <code>max-kbyte-count</code>, along with
- corresponding requirements on servers of <a href="#ldpr-units-triple-count">LDPRs</a>
- and <a href="#atrisk-paging-record-count">LDPCs</a> to support them.
- </p>
- </div>
-
- <p>
- LDP Paging defines <code>max-triple-count</code>, <code>max-member-count</code>, and <code>max-kbyte-count</code>
- as new parameters on the existing
- HTTP <code>Prefer</code> request header's
- <code>return=representation</code> preference [<cite><a class="bibref" href="#bib-RFC7240">RFC7240</a></cite>]; the presence of any of these parameters
- on the preference, not the preference alone, is what indicates to a server that the client
- supports LDP Paging.
- A client communicates its hint(s) to the server by adding the
- request header with a
- <code>return=representation</code> preference that includes any of the following preference parameters
- </p><table class="indented">
- <tbody><tr>
- <td> <code>max-triple-count</code> </td>
- <td> The maximum decimal number of triples the client wishes to appear on each page. </td>
- </tr>
- <tr>
- <td> <code>max-kbyte-count</code> </td>
- <td> The maximum decimal number of kilobytes (1024 byte units) the client wishes to receive as the page's representation. </td>
- </tr>
- <tr>
- <td> <code>max-member-count</code> </td>
- <td> The maximum decimal number of members the client wishes to appear on each page.
- This parameter is only meaningful for paged containers.
- </td>
- </tr>
- </tbody></table>
- <blockquote>
- <p>
- The generic preference BNF [<cite><a class="bibref" href="#bib-RFC7240">RFC7240</a></cite>] allows either a quoted string or a token as the value of a
- preference parameter.
- </p>
- </blockquote>
- <p></p>
-
- <p id="prefer-examples-500-triples">
- Clients interested in receiving at most 500 RDF triples per <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">page</a>
- would use add this HTTP header on a <code>GET</code> request, as shown in <a href="#ldpp-ex-paging-303" class="sectionRef sec-ref">section <span class="secno">4.2</span> <span class="sec-title">Simple paging flow using redirects</span></a>:
- <code>Prefer: return=representation; max-triple-count="500"</code>
- </p>
-
-</section> <!-- Paging hints -->
-
-</section> <!-- Client constraints -->
-
-<section id="ldpr" typeof="bibo:Chapter" resource="#ldpr" rel="bibo:Chapter">
-<!--OddPage--><h2 aria-level="1" role="heading" id="h2_ldpr"><span class="secno">6. </span>Linked Data Platform Resources</h2>
-
-<section class="informative" id="ldpr-PagingIntro" typeof="bibo:Chapter" resource="#ldpr-PagingIntro" rel="bibo:Chapter">
-
-<h3 aria-level="2" role="heading" id="h3_ldpr-PagingIntro"><span class="secno">6.1 </span>Paging considerations</h3><p><em>This section is non-normative.</em></p>
-
- <p>
- As <a href="#intro">described</a> <a href="#ldpp-ex-mx">previously</a>,
- paging logically breaks up a <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>
- into a list of <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resources</a> (pages) whose representations the client can retrieve, and serves each
- page with links to other <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">pages in the sequence</a>.
- Clients inspect each response to see if additional pages
- are available; paging does not affect the choice of HTTP status code.
- Clients generally have no insight into the allocation of information to pages,
- although in <a href="#ldpc">some cases currently defined only for LDPCs</a> the server can expose its
- algorithm.
- </p>
- <p>
- Some clients will be interested in knowing whether or not competing requests altered the
- <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> while the client was retrieving pages, since LDP paging does not guarantee
- that those alterations were reflected in any <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> received by the client.
- Regardless of the server implementation, LDP only guarantees that while traversing a series of pages that
- the client observes data that is equivalent to a database that uses
- read committed isolation [<cite><a class="bibref" href="#bib-READ-COMMITTED">READ-COMMITTED</a></cite>];
- specifically, clients can observe
- non-repeatable reads [<cite><a class="bibref" href="#bib-NON-REPEATABLE-READS">NON-REPEATABLE-READS</a></cite>] while traversing pages served by
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a>.
- LDP Paging does <a href="#ldpr-guarantee-show-unchanged">guarantee</a>, however, that any information in the <abbr title="Linked Data Platform Resource">LDPR</abbr> continuously present (neither added nor deleted) in the
- <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged resource</a> across the entire period of time when the client is retrieving pages will
- be present in at least one <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>.
- </p>
- <p>
- LDP Paging defines a mechanism by which <a href="#ldpr-notify-changes">clients can detect that the paged resource has been changed</a> so that they can, for example,
- abandon a page traversal as early as possible.
- This provides a stronger guarantee in certain cases
- than the one described for paged feeds [<cite><a class="bibref" href="#bib-RFC5005">RFC5005</a></cite>], but it does require the client
- to detect when the condition holds.
- Paging <i>does not guarantee</i> that it will ever be possible to successfully
- retrieve all the <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>s without the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>
- being added to or changed, so clients requiring such a guarantee
- may not find all <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>s usable in practice.
- A detailed example was provided in <a href="#ldpp-ex-mx" class="sectionRef sec-ref">section <span class="secno">4.</span> <span class="sec-title">Example paging message exchanges</span></a>.
- See <a href="#ldpr-impl" class="sectionRef sec-ref">section <span class="secno">A.</span> <span class="sec-title">Paging LDPRs without maintaining server-side session state</span></a> for server implementation considerations.
- </p>
-</section>
-
-<section id="ldpr-PagingGET" typeof="bibo:Chapter" resource="#ldpr-PagingGET" rel="bibo:Chapter">
-<h3 aria-level="2" role="heading" id="h3_ldpr-PagingGET"><span class="secno">6.2 </span>HTTP GET</h3>
- <p>In addition to the requirements on HTTP <code>GET</code> for LDPRs [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>],
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> must
- also follow the requirements in this section for all <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged resources</a>
- and their associated <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resources</a>.
- </p>
-
- <section id="ldpr-page-large" typeof="bibo:Chapter" resource="#ldpr-page-large" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-page-large"><span class="secno">6.2.1 </span>
- <!-- Remove this clause? No, it was MOVED here from LDP, and as a Must we'd need to define 'large' to test compliance. -->
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em> allow clients to retrieve large LDP-RSs in
- pages.
- </h4></section><!-- Was 4.2.14 / #ldpr-4_2_14 -->
-
- <section id="ldpr-split-any-resource" typeof="bibo:Chapter" resource="#ldpr-split-any-resource" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-split-any-resource"><span class="secno">6.2.2 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em>
- treat any resource (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> or not) as a <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>.
- </h4></section><!-- Was 4.2.15 / #ldpr-4_2_15 -->
-
- <section id="ldpr-split-any-time" typeof="bibo:Chapter" resource="#ldpr-split-any-time" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-split-any-time"><span class="secno">6.2.3 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em>
- vary their treatment of any resource (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> or not) as a <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> over time.
- In other words, given two attempts to retrieve the same resource at different points
- in time, the server can choose to return a representation of the first page at one time and
- of the entire resource at a different time. Clients distinguish between these cases based
- on the <a href="#ldpr-status-code">status code</a>
- and <a href="#ldpr-pagingGET-page-type-reqd">response headers</a>.
- </h4></section>
-
- <section id="ldpp-prefer" typeof="bibo:Chapter" resource="#ldpp-prefer" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-prefer"><span class="secno">6.2.4 </span><a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a>
- <em class="rfc2119" title="SHOULD">SHOULD</em> respect all of a client's <a href="#ldpp-hints">LDP Paging defined hints</a>, for example
- <a href="#ldpp-hints">the largest page size</a>
- the client is interested in processing,
- to influence the amount of data returned in representations.</h4>
- <blockquote>
- <em>Non-normative note</em>: LDP server implementers should be careful not to interpret a
- <code>Prefer return=representation</code> request header that <em>lacks</em> any
- parameters defined here as a client's request for a <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>.
- <a href="#ldpp-hints">A client's hints</a> indicate LDP Paging support <em>only</em>
- when at least one of the preference parameters defined by this specification is present.
- </blockquote>
- <blockquote>
- <em>Non-normative note</em>: LDP server implementers should carefully consider the effects of these
- preferences on caching, as described in section 2 of [<cite><a class="bibref" href="#bib-RFC7240">RFC7240</a></cite>].
- </blockquote>
- <blockquote>
- <em>Non-normative note</em>: [<cite><a class="bibref" href="#bib-RFC7240">RFC7240</a></cite>] recommends that server implementers include a
- <code>Preference-Applied</code> response header when the client cannot otherwise determine the server's
- behavior with respect to honoring hints from the response content.
- </blockquote>
- </section>
-
- <section id="ldpp-prefer-unrecognized" typeof="bibo:Chapter" resource="#ldpp-prefer-unrecognized" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-prefer-unrecognized"><span class="secno">6.2.5 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em>
- ignore a <a href="#ldpp-hints">page size hints</a> whose value is zero,
- and process the request as if no maximum desired size was specified; in the latter case the server
- can select whatever page size it deems appropriate, or choose not to page the resource at all.
- </h4></section>
-
- <div class="atrisk" id="atrisk-2NN"><p class="atrisktext">Feature At Risk</p>
- <p>The LDP Working Group proposes incorporation of the features described in the next compliance clause.</p>
- <ul>
- <li><p>
- A <a href="http://lists.w3.org/Archives/Public/www-tag/2013Dec/0041.html">December 2013 TAG discussion</a> started,
- whose goal is to reduce the need for two request-response round trips down to one when retrieving what
- turns out to be the first page of a paged resource, by defining a new
- HTTP response code in the <code>2xx</code> or <code>3xx</code> class that would allow a server to
- respond to <code>GET request-uri</code> requests with the representation of the first page
- (whose URI is <code>first-page-uri</code>, not <code>request-uri</code>) of a multi-page response.
- </p></li>
- <li><p>
- For the purposes of drafting this section, we assume that the
- new code's value is <code>2NN Contents of Related</code>,
- and its definition is given by the
- IETF draft [<cite><a class="bibref" href="#bib-2NN">2NN</a></cite>], whose content evolved from
- <a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0023.html">an LDP extrapolation from TAG discussions</a>,
- <a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0015.html">Henry Thompson's strawman</a>,
- with the substitution of 2NN for 2xx as suggested in
- <a href="https://github.com/w3ctag/spec-reviews/blob/master/2014/04/http-209.md">the TAG's draft comments, item 2</a>.
- Note: nothing prevents servers or clients from using <code>303 See Other</code> responses to
- requests for <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged resources</a>. The only significant differences between 303 and 2NN responses
- are the extra round trip required for the client to retrieve the representation of the first page when using 303,
- and the non-cacheable nature of 303 responses.
- </p></li>
- <li><p>
- Once LDP-Paging is a
- Candidate Recommendation, the LDP WG will make an assessment based on the status at IETF,
- working with the <abbr title="World Wide Web Consortium">W3C</abbr> Director, to either use the newly defined response code 2NN
- as documented in this section or to revert to a classic
- <code>303</code> response pattern.
- </p></li>
- </ul>
- </div>
-
- <section id="ldpr-status-code" typeof="bibo:Chapter" resource="#ldpr-status-code" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-status-code"><span class="secno">6.2.6 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em>
- initiate paging unless the client has indicated it understands LDP Paging or that it is prepared to
- process <code>2NN Contents of Related</code> responses [<cite><a class="bibref" href="#bib-2NN">2NN</a></cite>].
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> initiating paging <em class="rfc2119" title="SHOULD">SHOULD</em> respond
- to successful <code>GET</code> requests with any <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged resource</a>
- as the <code>Request-URI</code> in one of the following ways:</h4>
- <ul>
- <li>
- If the client supports <code>2NN</code> responses, respond
- with HTTP status code <code>2NN Contents of Related</code> and the first
- <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>'s representation.
- </li>
- <li>
- If the client supports paging but not <code>2NN</code> responses,
- respond with
- status code <code>303 See Other</code> and a <code>Location</code> response header that identifies
- the first <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>.
- The only standard means defined by LDP paging for a client to signal a server that the client
- understands paging is via the <a href="#ldpp-hints">client preference</a> defined for this purpose;
- other implementation-specific means could also be used.
- </li>
- <li>
- If the server is willing to provide a non-paged representation, respond
- with an appropriate status code (likely <code>200 OK</code>) and the potentially large
- non-paged representation.
- </li>
- <li>
- Either reject the request, most likely with a <code>4xx</code> status code,
- or (keeping in mind the note below)
- initiate paging as described above with a <code>303</code> status code, or
- choose another status code appropriate to the specific situation.
- </li>
- </ul>
-
- <blockquote>
- <em>Non-normative note:</em>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> could choose to make any resource
- available <em>only</em> as a paged resource.
- In so doing, when interacting with clients <em>unaware</em> of LDP Paging,
- if the server initiates paging anyway then it runs the risk
- that an ill-behaved client will automatically follow a
- <code>303 See Other</code> redirect and believe via the subsequent
- <code>200 OK</code> that it has obtained a complete representation of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>
- rather than of a single <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>.
- <a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging clients</a> <a href="#ldpp-client-nofollow-303">will not follow redirects in this way</a>,
- but some existing HTTP clients are known to treat <code>303 See Other</code> redirects as if they were
- equivalent to the original request-URI, despite this being explicitly disclaimed in [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>].
- </blockquote>
- </section>
-
- <section id="ldpr-guarantee-show-unchanged" typeof="bibo:Chapter" resource="#ldpr-guarantee-show-unchanged" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-guarantee-show-unchanged"><span class="secno">6.2.7 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST">MUST</em>
- ensure that all state present in the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> throughout a client's <em>entire</em> traversal operation
- is represented in at least one <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>. In other words, whatever subset of the
- <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> that is <em>not added, updated, or removed during the client's traversal</em>
- of its pages has to be present in one of the pages.
- </h4>
- <blockquote><em>Non-normative note:</em>
- As a consequence, if the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> does not change <em>at all</em> during the traversal,
- then the client has a complete view of its state as given by the negotiated response media type
- <em>at the point in time when the final page was retrieved</em>.
- If the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> <em>does</em> change during the traversal, then only the portions that
- were actually updated will differ; the client has no LDP Paging provided means for knowing in what
- way(s) its view differs from that of the server in this case.
- </blockquote>
- <blockquote><em>Non-normative note:</em>
- When the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> is an <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>,
- the expectation is that all triples untouched by changes to the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> have been
- given to the client during the traversal; it is possible that some subset of the changed triples, including all or none of them,
- have been provided to the client, but the client has no way to know which.
- </blockquote>
- </section>
-
- <!--
- <div class="ldp-issue-pending" id="question-link-relation"><p class="ldp-issue-title">Feedback requested on the link relation type used below</p>
- <p>Background: likely suspects from the <a href="http://www.iana.org/assignments/link-relations/link-relations.xml">IANA link relation registry</a> that the editors examined:</p>
- <ul>
- <li><p>
- <a href="http://tools.ietf.org/html/rfc6596">canonical</a> (see section 3, source has no TOC/anchors) may be
- close enough; the content at the context URI can explicitly be a subset of that at the target (canoncial) URI.
- Certain cited functions like link consolidation are completely appropriate; if we believe the authors about its
- usage by crawlers/indexers however, we may be working at cross purposes.
- </p></li>
- <li><p>
- <a href="http://tools.ietf.org/html/rfc6573">collection</a> has muddy semantics in the case where
- the paged resource is an LDPC (i.e. the case we care most about, in terms of LDP's use cases). We could
- probably get away with using collection, but its "inverse" item (defined in the same RFC) would definitely
- have a <em>different</em> semantic than what we want for paging (the RFC thinks an item is a member of the
- collection, but a page of an LDPC might have multiple LDP members on it, if we consider inlining in any form).
- It would have the net effect of looking at the LDPC as a generic RDF source, and "forgetting" within the paging
- spec that LDPCs have members - something that I'm sure we could all do, but pity the adopters using both
- together and trying to keep the different collection/item "models" untangled.
- </p></li>
- <li><p>
- <a href="http://tools.ietf.org/html/rfc4287#page-21">enclosure</a> has "good match" semantics,
- but a name that's awkward for our case.
- </p></li>
- <li><p>
- <a href="http://tools.ietf.org/html/rfc5005">Atom Feed Paging and Archiving</a> has no analog for the logical feed.
- </p></li>
- <li><p>
- We also have the choice of defining-new, either an extension link relation (we just mint our own URI, done)
- or as a short name (requiring a small-but-not-zero registration template).
- </p></li>
- </ul>
- </div>
- -->
-
- <section id="ldpr-notify-changes" typeof="bibo:Chapter" resource="#ldpr-notify-changes" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-notify-changes"><span class="secno">6.2.8 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST">MUST</em>
- enable a client to detect any change to the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> that occurs while the client is retrieving pages
- by
- including a HTTP <code>Link</code> header on all successful
- HTTP <code>GET</code> responses, and <em class="rfc2119" title="SHOULD">SHOULD</em> include the same header on all <code>4xx</code>
- status code responses.
- The link's
- context URI identifies the <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> being retrieved,
- target URI identifies the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>,
- link relation type is <code>canonical</code> [<cite><a class="bibref" href="#bib-REL-CANONICAL">REL-CANONICAL</a></cite>],
- and
- link extension parameters include the parameter name <code>etag</code>
- and a corresponding parameter value identical to the ETag [<cite><a class="bibref" href="#bib-RFC7232">RFC7232</a></cite>]
- of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>.
- For example: <code>Link: <http://example.org/customer-relations>; rel='canonical'; etag="customer-relations-v1"</code>
- </h4>
- <blockquote><em>Non-normative note:</em>
- If the <code>rel='canonical'; etag="..."</code> value changes as the client retrieves pages,
- for example the value accompanying the first page's representation is <code>rel='canonical'; etag="v1"</code>
- and the value accompanying the second page's representation is <code>rel='canonical'; etag="v2"</code>,
- the client can detect that the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>'s state has changed.
- Some clients will ignore such changes, but others may choose to react to them, for example by restarting the traversal.
- </blockquote>
- </section>
-
- <section id="ldpr-pagingGET-sequences-change" typeof="bibo:Chapter" resource="#ldpr-pagingGET-sequences-change" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-sequences-change"><span class="secno">6.2.9 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em>
- add or remove <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resources</a> to a
- <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged resource's</a> sequence over time.
- If the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a> is <a href="#ldpc-HTTP_GET">ordered</a>, then the ordering communicated by the server <em class="rfc2119" title="MUST">MUST</em> be maintained;
- the server <em class="rfc2119" title="SHOULD">SHOULD</em> only add pages to the end of an unordered sequence.
- </h4><!-- Was 4.10.2.1 / #ldpr-pagingGET-sequences-change -->
- <blockquote><em>Non-normative note:</em>
- Servers might abandon an ordered <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>, resulting in <code>4xx</code> status codes to subsequent requests,
- although it will be less disruptive to clients if the server either adds content to the appropriate existing page or
- adds new pages at the proper point in the sequence. Clients have no more efficient means than a conditional retrieval
- request on existing pages to detect the changed/added pages.
- </blockquote>
- <blockquote><em>Non-normative note:</em>
- As a result, clients retrieving any <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> several times can observe its place in the sequence
- change as the state of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> changes.
- For example, a nominally last page's server might provide a
- <a href="#dfn-next-page-link" class="internalDFN">next page link</a> when the page is retrieved again later.
- Similar situations arise when the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a> crosses server boundaries;
- server A might host the initial portion of a sequence that links to the last page server A is aware of,
- hosted on server B, and server B might extend the sequence of pages.
- A nominally middle page <var>M</var> can become the last (or a non-existent) page if a competing request deletes
- part of the <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged resource's</a> content after the client retrieves <var>M</var>.
- </blockquote>
- </section>
-
- <section id="ldpr-pagingGET-first-allowed-onpages" typeof="bibo:Chapter" resource="#ldpr-pagingGET-first-allowed-onpages" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-first-allowed-onpages"><span class="secno">6.2.10 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em> provide
- a <a href="#dfn-first-page-link" class="internalDFN">first page link</a> when responding to
- requests with any <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> as the <code>Request-URI</code>.
- </h4></section><!-- Was 4.10.2.1.1 / #ldpr-pagingGET-sequences-change -->
-
- <section id="ldpr-pagingGET-last-allowed-onpages" typeof="bibo:Chapter" resource="#ldpr-pagingGET-last-allowed-onpages" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-last-allowed-onpages"><span class="secno">6.2.11 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em>
- provide a <a href="#dfn-last-page-link" class="internalDFN">last page link</a>
- in responses to <code>GET</code> requests with any <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> as the <code>Request-URI</code>.
- </h4></section><!-- Was 4.10.2.1.3 / #ldpr-pagingGET-last-allowed-onpages -->
-
- <section id="ldpr-pagingGET-next-reqd" typeof="bibo:Chapter" resource="#ldpr-pagingGET-next-reqd" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-next-reqd"><span class="secno">6.2.12 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST">MUST</em>
- provide a <a href="#dfn-next-page-link" class="internalDFN">next page link</a>
- in responses to <code>GET</code> requests with any <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
- <em>other than the final page</em>
- as the <code>Request-URI</code>.
- This is the mechanism by which clients can discover the URL of the next page.
- </h4><!-- Was 4.10.2.2 / #ldpr-pagingGET-next-reqd-change -->
- </section>
-
- <section id="ldpr-pagingGET-lastnext-prohibited" typeof="bibo:Chapter" resource="#ldpr-pagingGET-lastnext-prohibited" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-lastnext-prohibited"><span class="secno">6.2.13 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST NOT">MUST NOT</em>
- provide a <a href="#dfn-next-page-link" class="internalDFN">next page link</a>
- in responses to <code>GET</code> requests with the final <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
- as the <code>Request-URI</code>.
- This is the mechanism by which clients can discover the end of the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>
- as currently known by the server.
- </h4></section><!-- Was 4.10.2.2.1 / #ldpr-pagingGET-lastnext-prohibited -->
-
- <section id="ldpr-pagingGET-prev-allowed" typeof="bibo:Chapter" resource="#ldpr-pagingGET-prev-allowed" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-prev-allowed"><span class="secno">6.2.14 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em>
- provide a <a href="#dfn-previous-page-link" class="internalDFN">previous page link</a>
- in responses to <code>GET</code> requests with any <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
- <em>other than the first page</em>
- as the <code>Request-URI</code>.
- This is one mechanism by which clients can discover the URL of the previous page.
- </h4></section><!-- Was 4.10.2.2.2 / #ldpr-pagingGET-prev-allowed -->
-
- <section id="ldpr-pagingGET-firstprev-prohibited" typeof="bibo:Chapter" resource="#ldpr-pagingGET-firstprev-prohibited" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-firstprev-prohibited"><span class="secno">6.2.15 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST NOT">MUST NOT</em>
- provide a <a href="#dfn-previous-page-link" class="internalDFN">previous page link</a>
- in responses to <code>GET</code> requests with the <em>first</em> <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
- as the <code>Request-URI</code>.
- This is one mechanism by which clients can discover the beginning of the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>
- as currently known by the server.
- </h4></section><!-- Was 4.10.2.2.3 / #ldpr-pagingGET-firstprev-prohibited -->
-
- <section id="ldpr-pagingGET-page-type-reqd" typeof="bibo:Chapter" resource="#ldpr-pagingGET-page-type-reqd" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-page-type-reqd"><span class="secno">6.2.16 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST">MUST</em>
- provide an HTTP <code>Link</code>
- header whose target URI is <code>http://www.w3.org/ns/ldp#Page</code>, and whose link relation type is <code>type</code> [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>]
- in responses to <code>GET</code> requests with any <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
- as the <code>Request-URI</code>.
- This is one mechanism by which clients know that the resource is one of a sequence of pages.
- </h4></section><!-- Was 4.10.2.4 / #ldpr-pagingGET-page-type-reqd -->
-
- <section id="ldpr-pagingGET-abandon-pageseq" typeof="bibo:Chapter" resource="#ldpr-pagingGET-abandon-pageseq" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-abandon-pageseq"><span class="secno">6.2.17 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em>
- indicate that they have abandoned a
- sequence by responding with at <code>410 Gone</code> to HTTP requests to any of the
- <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resources</a> with appropriate
- paging link response headers, for example, rel='first'.
- </h4></section><!-- #ldpr-pagingGET-abandon-pageseq -->
-
- <!--
- <div class="atrisk" id="atrisk-paging-triple-count"><p class="atrisktext">Feature At Risk</p>
- <p>The LDP Working Group proposes incorporation of the following clause:</p>
- -->
- <section id="ldpr-units-triple-count" typeof="bibo:Chapter" resource="#ldpr-units-triple-count" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-units-triple-count"><span class="secno">6.2.18 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em>
- support the <code>max-triple-count</code> <a href="#ldpp-hints">client preference parameter</a>,
- which expresses a page size limiting the number of RDF triples represented on a page.
- For example, <code>max-triple-count="500"</code> expresses a limit of 500 RDF triples per page.
- </h4>
- </section>
- <!--
- </div>
- -->
-
- <div class="atrisk" id="atrisk-paging-kbyte-count"><p class="atrisktext">Feature At Risk</p>
- <p>The LDP Working Group proposes incorporation of the following clause:</p>
- <section id="ldpr-units-kbyte-count" typeof="bibo:Chapter" resource="#ldpr-units-kbyte-count" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-units-kbyte-count">
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em>
- support the <code>max-kbyte-count</code> <a href="#ldpp-hints">client preference parameter</a>,
- which expresses a page size limit as kilobytes of representation size.
- For example, <code>max-kbyte-count="1"</code> expresses a limit of 1024 bytes per page.
- </h4>
- </section>
- </div>
-
- <div class="atrisk" id="atrisk-paging-multiple-units"><p class="atrisktext">Feature At Risk</p>
- <p>The LDP Working Group proposes incorporation of the following clause:</p>
- <section id="ldpr-pagesize-multiple-units" typeof="bibo:Chapter" resource="#ldpr-pagesize-multiple-units" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagesize-multiple-units">
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST">MUST</em>, if provided with multiple
- <a href="#ldpp-hints">client preference parameters</a> limiting page size,
- honor all hints that it recognizes. This has the net effect that the most restrictive
- hint for any given response governs the resulting page size.
- For example, <code>max-kbyte-count="1"</code> and <code>max-triple-count="500"</code>
- usually would result in pages whose size hits the 1 kilobyte limit first, since each triple very likely
- requires more than two bytes (500 triples/1024 bytes).
- </h4>
- </section>
- </div>
-
- <!-- combined into ldpr-status-code
- <section id="ldpr-pagingGET-only-paging-clients"><h2 class="normal">
- <a title="LDP Paging server">LDP Paging servers</a> SHOULD NOT
- initiate paging unless the client has indicated it understands LDP Paging or that it is prepared to
- process <code>2NN Contents of Related</code> responses [[!2NN]].
- If the client supports paging but not <code>2NN</code> responses, a server initiating paging SHOULD respond with
- status code <code>303 See Other</code> and a <code>Location</code> response header that identifies
- the URI of the first <a>in-sequence page resource</a> of the <a>paged resource</a>.
- The only standard means defined by LDP paging for a client to signal a server that the client
- understands paging is via the <a href="#ldpp-hints">client preference</a> defined for this purpose;
- other implementation-specific means could also be used.</h2>
- <blockquote>
- <em>Non-normative note:</em>
- <a title="LDP Paging server">LDP Paging servers</a> could choose to make any resource
- available <em>only</em> as a paged resource.
- In so doing, when interacting with clients <em>unaware</em> of LDP Paging,
- if the server initiates paging anyway then it runs the risk
- that an ill-behaved client will automatically follow a
- <code>303 See Other</code> redirect and believe via the subsequent
- <code>200 OK</code> that it has obtained a complete representation of the <a>paged resource</a>
- rather than of what may be a single <a>in-sequence page resource</a>.
- The alternative is for the server to reject the request, most likely
- with a <code>4xx</code> status code.
- <a title="LDP Paging client">LDP Paging clients</a> <a href="#ldpp-client-nofollow-303">will not follow redirects in this way</a>,
- but some existing HTTP clients are known to treat <code>303 See Other</code> redirects as if they were
- equivalent to the original request-URI, despite this being explicitly disclaimed in [[RFC7231]].
- </blockquote>
- </section>
- -->
-
-</section>
-
-</section> <!-- h1 -->
-
-<section id="ldpc" typeof="bibo:Chapter" resource="#ldpc" rel="bibo:Chapter">
-<!--OddPage--><h2 aria-level="1" role="heading" id="h2_ldpc"><span class="secno">7. </span>Linked Data Platform Containers</h2>
-
-<section id="ldpc-general" typeof="bibo:Chapter" resource="#ldpc-general" rel="bibo:Chapter">
-<h3 aria-level="2" role="heading" id="h3_ldpc-general"><span class="secno">7.1 </span>Requirements when paging LDP Containers</h3>
-
- <section id="ldpc-onsamepage" typeof="bibo:Chapter" resource="#ldpc-onsamepage" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-onsamepage"><span class="secno">7.1.1 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST">MUST</em>
- ensure that the <a title="membership triples" href="#dfn-membership-triples" class="internalDFN">membership triple</a> and
- <a title="containment triples" href="#dfn-containment-triples" class="internalDFN">containment triple</a> for each member are part of the
- same <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>, whenever both triples are present in the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>
- for a <a title="paged resource" href="#dfn-paged-resource" class="internalDFN">paged <abbr title="Linked Data Platform Container">LDPC</abbr></a>.
- </h4></section>
-
- <div class="atrisk" id="atrisk-paging-record-count"><p class="atrisktext">Feature At Risk</p>
- <p>The LDP Working Group proposes incorporation of the following clause:</p>
- <section id="ldpr-units-record-count" typeof="bibo:Chapter" resource="#ldpr-units-record-count" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-units-record-count">
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em>
- support the <code>max-member-count</code> <a href="#ldpp-hints">client preference parameter</a>,
- which expresses a page size limiting the number of members returned on each page of a <a title="paged resource" href="#dfn-paged-resource" class="internalDFN">paged <abbr title="Linked Data Platform Container">LDPC</abbr></a>.
- For example, <code>max-member-count="10"</code> expresses a limit of 10 members per page.
- </h4>
- </section>
- </div>
-
-</section>
-
-<section class="informative" id="ldpc-informative" typeof="bibo:Chapter" resource="#ldpc-informative" rel="bibo:Chapter">
-<h3 aria-level="2" role="heading" id="h3_ldpc-informative"><span class="secno">7.2 </span>Ordering of container members across pages</h3><p><em>This section is non-normative.</em></p>
-
- <section id="ldpc-ordering" typeof="bibo:Chapter" resource="#ldpc-ordering" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-ordering"><span class="secno">7.2.1 </span>Ordering</h4>
- <p>
- There are many cases where an ordering of the members of a
- container is important. [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>] does not provide any particular support
- for server ordering of members in containers, because any client can
- order the members in any way it chooses based on the value of any
- available property of the members. In the example below, the value of
- the <code>o:marketValue</code> predicate is present for each
- member, so the client can easily order the members according to the
- value of that property.
- </p>
- <p>
- Order becomes more important when containers are
- paginated. If the server respects ordering when constructing
- pages, clients needing a globally sorted set of members
- can reduce the effort required to merge pages.
- In cases where ordering is important, an <a href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging server</a> ensures that all the
- members on any single page have the proper sort order with relation to all
- members on any next and previous pages.
- <em>This says nothing about the ordering of members <strong>within</strong> any
- <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">single page</a>.</em>
- When the sort is ascending, all the members on a current page have a
- sort order no lower than all members on the previous page and
- sort order no higher than all the members on the next page;
- that is, it proceeds from low to high, but keep in mind that several
- consecutive pages might have members whose sort criteria are equal.
- When the sort is descending, the opposite order is used.
- Since more than one value may be used to sort members,
- the <abbr title="Linked Data Platform Container">LDPC</abbr> specification allows servers to assert the ordered list
- of sort criteria used to sort the members, using the
- <code>ldp:pageSequence</code> HTTP link relation and its
- <code>ldp:pageSortCriteria</code> predicate.
- Each member of the ordered list exposes one <code>ldp:pageSortCriterion</code>,
- consisting of a <code>ldp:pageSortOrder</code>,
- <code>ldp:pageSortPredicate</code>, and
- optionally a <code>ldp:pageSortCollation</code>.
- </p>
- <p>
- Here is an example asset container described in [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>] section 5.1:
- </p>
-
-<em>Request</em>
-<div class="example"><div class="example-title"><span>Example 16</span></div><pre class="example">GET /netWorth/nw1/assetContainer/ HTTP/1.1
-Host: example.org
-Accept: text/turtle
-Prefer: return=representation; max-triple-count="500"</pre></div>
- <p>
- The server might respond with status code <code>200 OK</code>,
- and the following representation:
- </p>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 17</span></div><pre class="example" id="ldpc-ex-ordering-nopaging">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 is here only so it's easier to paste into validators for checking -->
-# @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 .</pre></div>
- <p>
- The client knows that LDP Paging was not used to form the response, because the HTTP status code is <code>200 OK</code>;
- the absence of a <code>Link: <http://www.w3.org/ns/ldp#Page>; rel="type"</code> response header provides redundant
- confirmation of this.
- Since paging was not used, the server provides no information related to page sorting;
- providing page sorting information would have no value to the client, it would only waste resources.
- </p>
-
- <p>
- Had the server responded instead with a redirect to a first page <code>http://example.org/netWorth/nw1/assetContainer/?p=1</code>,
- whose representation was (after following the redirect):
- </p>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 18</span></div><pre class="example" id="ldpc-ex-ordering-page1">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 is required here because the page URI != container URI; any use for paste into validators for checking is free bonus -->
-@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#>.
-<!-- (#Sort-o.marketValue-Ascending) does not work, because the subject uri would be a blank node -->
-<> ldp:pageSortCriteria ( <#Sort-o.marketValue-Ascending> ).
-
-<#Sort-o.marketValue-Ascending>
- a ldp:pageSortCriterion;
- ldp:pageSortOrder ldp:Ascending;
- ldp:pageSortPredicate o:marketValue.</pre></div>
-
- <p>
- In this case the server does provide information on the assignment of members to pages.
- </p>
- <ul>
- <li>
- A <code>Link rel='http://www.w3.org/ns/ldp#pageSequence'</code> response header has been
- added, allowing the client to where to find information about the page sequence;
- its content includes a <code>ldp:pageSortCriteria</code> triple,
- allowing the client to know what sort criteria the server used when allocating members
- to pages.
- </li>
- <li>
- The server also chose to include assertions about the sort criteria in the content for the
- first page, namely the triples occurring after the second <code>@base</code> directive.
- This is an optional exemplary optimization, and the client must decide for itself using means outside of
- LDP and HTTP whether or not to trust those assertions.
- If the client trusts those assertions, it need not retrieve them; retrieving them would in this case
- result in another <code>HTTP GET</code> request. For the purposes of this example, assume that
- the assertions match what the client would obtain by retrieving them itself.
- </li>
- <li>
- The contents of the sort criteria resource
- asserts that the <code>o:marketValue</code> predicate will be used
- to assign sets of members to pages in ascending order.
- The server is telling the client that the values of <code>o:marketValue</code> of all assets
- on the first page are no lower than the values on subsequent pages.
- Since only one such value happens to fall on the first page, this is trivially satisfied.
- </li>
- </ul>
-
- <p>
- When the client retrieves the second page by following the <code>rel='next'</code> link,
- its representation might be:
- </p>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 19</span></div><pre class="example" id="ldpc-ex-ordering-page2">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 is required here because the page URI != container URI; any use for paste into validators for checking is free bonus -->
-@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 .</pre></div>
-
- <ul>
- <li>
- The same <code>Link rel='http://www.w3.org/ns/ldp#pageSequence'</code> response header is present,
- allowing the client to know what page sequence, and hence what sort criteria, the server used.
- </li>
- <li>
- The server chose not to include assertions about the sort criteria in the content for the
- second page. Since LDP Paging <a href="#ldpc-sort-consistent">requires that the page sequence is sorted consistently</a>,
- any client that already retrieved the first page has already seen the sorting criteria. If a client is given
- the URI of an <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> through means other than following links, it always has the option
- to retrieve the sort criteria.
- </li>
- <li>
- As the example shows, the values of <code>o:marketValue</code> all assets
- on the second page are greater than or equal to the values on earlier pages.
- <em>The values within this page are not ordered according to the
- sort criterion</em>, illustrating that this criterion applies only to the
- sorting of "assigning members to pages", not
- to the ordering within any single page's representation.
- Typically those representations have not guarantee of ordering and are generated by libraries,
- whose serializers do not provide a way to control how the order is conveyed.
- </li>
- </ul>
- <p>
- It is up to the domain model
- and server to determine the appropriate predicate to indicate the
- resource’s order within a page (or globally), and up to the client receiving this
- representation to use that order in whatever way is appropriate to meet its needs, for
- example to sort the data prior to presentation on a user interface. Also,
- as it is possible for a container to have as its members other containers,
- the ordering approach doesn't change as containers themselves are LDPRs and the
- properties from the domain model can be leveraged for the sort criteria.
- </p>
- </section><!-- Was 5.1.2 / #ldpc-ordering -->
-</section> <!-- containers . intro -->
-
-<section id="ldpc-HTTP_GET" typeof="bibo:Chapter" resource="#ldpc-HTTP_GET" rel="bibo:Chapter">
-<h3 aria-level="2" role="heading" id="h3_ldpc-HTTP_GET"><span class="secno">7.3 </span>HTTP GET requirements for member ordering across pages</h3>
-
- <p>
- If a <a href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging server</a> chooses to use LDP Paging-defined mechanisms to
- tell clients the order it uses to assign <abbr title="Linked Data Platform Container">LDPC</abbr> members to pages,
- which is optional, then it does so as described in this section.
- LDP Paging does not specify ordering for <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">pages</a> in other cases.
- See <a href="#ldpc-ordering" class="sectionRef sec-ref">section <span class="secno">7.2.1</span> <span class="sec-title">Ordering</span></a> for
- exemplary message exchanges.
- </p>
-
- <section id="ldpc-sort-criteria-consistent" typeof="bibo:Chapter" resource="#ldpc-sort-criteria-consistent" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-sort-criteria-consistent"><span class="secno">7.3.1 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em>
- communicate the order used to allocate <abbr title="Linked Data Platform Container">LDPC</abbr> members to <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">pages</a>.
- If they choose to communicate the order, they <em class="rfc2119" title="MUST">MUST</em> respond
- consistently to retrieval requests for each <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">page</a> in the same sequence.
- That is, they must communicate the same criteria (or absence of it) for all pages in the same sequence; if
- the criteria were allowed to vary, the ordering among members of a container
- across <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">pages</a> would be undefined.
- </h4></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
-
- <blockquote>
- <em>Non-normative note:</em> A server can offer different sequences for the same <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>,
- for example, sequences that have differing sort criteria, and they can be offered serially or concurrently.
- </blockquote>
-
- <section id="ldpc-sort-criteria-link" typeof="bibo:Chapter" resource="#ldpc-sort-criteria-link" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-sort-criteria-link"><span class="secno">7.3.2 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em class="rfc2119" title="MUST">MUST</em>
- specify the order using a <code>HTTP Link</code> header
- whose context URI is the page URI,
- whose link relation is <code>http://www.w3.org/ns/ldp#pageSequence</code>,
- and whose target IRI identifies a <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> whose content includes the
- sort criteria.
- The resource identified by the <code>Link</code> header's target IRI <em class="rfc2119" title="MUST">MUST</em> contain a triple
- whose subject is the <code>Link</code> header's target IRI,
- whose predicate is <code>ldp:pageSortCriteria</code>
- and whose object is a
- page sort criteria resource compliant with this section's requirements on its content.
- </h4></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
-
- <section id="ldpc-sort-criteria-content" typeof="bibo:Chapter" resource="#ldpc-sort-criteria-content" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-sort-criteria-content"><span class="secno">7.3.3 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em class="rfc2119" title="MUST">MUST</em>
- expose page sort criteria resources that describe the allocation of members to pages; each resource consists of a <code>rdf:List</code> of
- <code>ldp:pageSortCriterion</code> resources.
- The first list entry provides the primary
- sorting criterion, any second entry provides a secondary criterion used to order members considered
- equal according to the primary criterion, and so on.
- The resulting page sort order <em class="rfc2119" title="MUST">MUST</em> be as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause
- [<cite><a class="bibref" href="#bib-sparql11-query">sparql11-query</a></cite>].
- </h4></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
-
- <section id="ldpc-sortliteraltype" typeof="bibo:Chapter" resource="#ldpc-sortliteraltype" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-sortliteraltype"><span class="secno">7.3.4 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em class="rfc2119" title="MUST">MUST</em>
- expose page sort criteria resources that contain,
- in every <code>ldp:pageSortCriterion</code> list entry,
- a triple
- whose subject is the sort criterion identifier,
- whose predicate is <code>ldp:pageSortPredicate</code>
- and whose object is
- the predicate whose value is used to order members between pages (the <dfn id="dfn-page-ordering-values">page-ordering values</dfn>).
- The only literal data types whose behavior LDP constrains are those defined
- by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause [<cite><a class="bibref" href="#bib-sparql11-query">sparql11-query</a></cite>]. Other data types
- can be used, but LDP
- assigns no meaning to them and interoperability will be limited.
- </h4></section><!-- Was 5.3.3 / #ldpc-5_3_3 -->
-
- <section id="ldpc-sortorder" typeof="bibo:Chapter" resource="#ldpc-sortorder" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-sortorder"><span class="secno">7.3.5 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em class="rfc2119" title="MUST">MUST</em>
- expose page sort criteria resources that contain,
- in every <code>ldp:pageSortCriterion</code> list entry,
- a triple
- whose subject is the sort criterion identifier,
- whose predicate is <code>ldp:pageSortOrder</code>
- and whose object describes the order used.</h4>
- <blockquote>
- <p>
- LDP defines two values,
- <code>ldp:Ascending</code> and <code>ldp:Descending</code>, for use
- as the object of this triple. Other values can be used, but LDP
- assigns no meaning to them and interoperability will be limited.
- </p>
- </blockquote>
- </section><!-- Was 5.3.4 / #ldpc-5_3_4 -->
-
- <section id="ldpc-sortcollation" typeof="bibo:Chapter" resource="#ldpc-sortcollation" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-sortcollation"><span class="secno">7.3.6 </span>
- <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em class="rfc2119" title="MAY">MAY</em>
- expose page sort criteria resources that contain,
- in any <code>ldp:pageSortCriterion</code> list entry,
- a triple
- whose subject is the sort criterion identifier,
- whose predicate is <code>ldp:pageSortCollation</code>
- and whose object identifies the collation used.
- The <code>ldp:pageSortCollation</code> triple <em class="rfc2119" title="MUST">MUST</em> be omitted for comparisons
- involving <a title="page-ordering values" href="#dfn-page-ordering-values" class="internalDFN">page-ordering values</a> for which [<cite><a class="bibref" href="#bib-sparql11-query">sparql11-query</a></cite>] does not use collations.</h4>
- <blockquote>
- <p>
- LDP defines no values for use
- as the object of this triple. While it is better for interoperability to use
- open standardized values, any value can be used.
- </p>
- <p>
- When the <code>ldp:pageSortCollation</code> triple is absent and the
- <a title="page-ordering values" href="#dfn-page-ordering-values" class="internalDFN">page-ordering values</a> are strings or simple literals [<cite><a class="bibref" href="#bib-sparql11-query">sparql11-query</a></cite>], the
- resulting order is as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause
- [<cite><a class="bibref" href="#bib-sparql11-query">sparql11-query</a></cite>] using two-argument <code>fn:compare</code>, that is,
- it behaves as if <code>http://www.w3.org/2005/xpath-functions/collation/codepoint</code>
- was the specified collation.
- </p>
- <p>
- When the <code>ldp:pageSortCollation</code> triple is present and the
- <a title="page-ordering values" href="#dfn-page-ordering-values" class="internalDFN">page-ordering values</a> are strings or simple literals
- [<cite><a class="bibref" href="#bib-sparql11-query">sparql11-query</a></cite>], the
- resulting order is as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause
- [<cite><a class="bibref" href="#bib-sparql11-query">sparql11-query</a></cite>] using three-argument <code>fn:compare</code>, that is, the
- specified collation.
- </p>
- </blockquote>
- </section><!-- Was 5.3.5 / #ldpc-5_3_5 -->
-
-</section> <!-- h2 -->
-
-</section> <!-- h1 LDPC -->
-
-<!-- Removed for action-113
-<section>
-<h1>HTTP Status Code Definitions</h1>
-
-<section id="status-code-related-content">
-<h2>209 Related Content</h2>
-
- <div class="atrisk"><p class="atrisktext">Feature At Risk</p>
- <p>The LDP Working Group proposes incorporation of the features described in this section.</p>
- <ul>
- <li>The addition of <a>209 Related Content</a> in this specification is pending
- advancement of an <a href="https://datatracker.ietf.org/doc/draft-wilde-related-content/">IETF draft</a>
- that would fully include it, patterned after the codes defined by [[RFC6585]]. Once LDP is in
- Candidate Recommendation status, the LDP WG will make an assessment based on the status at IETF
- working with the W3C Director.</li>
- </ul>
- </div>
-
- <p>The <code>209 Related Content</code> status code indicates that the origin server
- is supplying the representation of a different resource than the target resource,
- and the origin server believes that the supplied representation
- is likely to satisfy the user agent's original request.
- The resource whose representation is supplied is descriptive of the target resource, in
- the same way that the <code>Location</code> header in a <code>303 See Other</code>
- response is descriptive of the target resource.
- </p>
- <p><code>209 Related Content</code> is intended to be used in situations where
- <code>303 See Other</code> could have been used and would most likely result in a
- user agent retrieving the other resource, but saves the user agent from
- the latency penalty of having to perform a separate retrieval request.
- </p>
-
- <p> LDP uses <code>209 Related Content</code> to provide clients with the
- <a href="#ldpr">first page of a large resource</a>, but it can also be used in
- other common situations. Linked Data clients could benefit by avoiding the latency
- of additional requests when the target resource is a concept resource (one without any
- representation capable of transmission over HTTP), and general HTTP clients would
- benefit in many of the more general cases where <code>303 See Other</code> responses
- are currently used.
- </p>
-
- <div id="status-code-related-content-1" class="rule">7.1.1 A <code>209</code> response to a
- <code>GET</code> request MUST contain a <code>Location</code> header with the same
- <code>Location</code> field value as a <code>303 See Other</code> response would use [[!HTTP11]].
- </div>
-
- <div id="status-code-related-content-2" class="rule">7.1.2 A <code>209</code> response to a
- <code>GET</code> request MUST contain a representation of the resource identified
- by the response's <code>Location</code> header.
- </div>
-
- <div id="status-code-related-content-iana" class="rule">7.1.3 IANA Considerations</div>
- <div>
- <blockquote>
- <p>
- The <code>209 Related Content</code> must be added to the permanent status code registry
- maintained at <a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>
- (see [[RFC7231]], [[!RFC2817]]).
- </p>
- <p>
- Value: 209
- </p>
- <p>
- Description: Related Content
- </p>
- <p>
- Reference: this specification
- </p>
- </blockquote>
- </div>
-
-</section>
-</section> -->
-
-
-<section class="informative" id="security" typeof="bibo:Chapter" resource="#security" rel="bibo:Chapter">
-<!--OddPage--><h2 aria-level="1" role="heading" id="h2_security"><span class="secno">8. </span>Security Considerations</h2><p><em>This section is non-normative.</em></p>
-As with any protocol that is implemented leveraging HTTP, implementations should take advantage of the many
-security-related facilities associated with it and are not required to carry out LDP operations
-that may be in contradistinction to a particular security policy in place. For example, when faced with an
-unauthenticated request to replace system critical RDF statements in a graph through the PUT method, applications may
-consider responding with the 401 status code (Unauthorized), indicating that the appropriate authorization
-is required. In cases where authentication is provided fails to meet the requirements of a particular access control
-policy, the 403 status code (Forbidden) can be sent back to the client to indicate this failure to meet the
-access control policy.
-</section>
-
-<section class="appendix informative" id="ldpr-impl" typeof="bibo:Chapter" resource="#ldpr-impl" rel="bibo:Chapter">
-
-<!--OddPage--><h2 aria-level="1" role="heading" id="h2_ldpr-impl"><span class="secno">A. </span>Paging LDPRs without maintaining server-side session state</h2><p><em>This section is non-normative.</em></p>
- <p>
- Server implementers naturally have concerns when they are expected to maintain per-client state
- because of the scalability limitations that per-client state implies.
- LDP Paging carries no such requirement, although this may not be obvious at first glance.
- Since URLs are opaque to clients [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>], a server
- is free to encode the information required for it to know where to start the next page inside
- its next page links, for example.
- </p>
- <p>
- Observe that in the <a href="#ldpp-ex-mx" class="sectionRef">preceding examples</a>,
- the <var>page n</var> URIs are all of the form
- <code>http://example.org/customer-relations?p=<var>n</var></code>,
- where <var>n</var> is <var>2..n</var>. This is likely true in general practice.
- If the server allocates <code>o:client</code> representations to pages randomly, it's not obvious how to avoid
- keeping per-client state of one kind or another on the server while still sending all the representations on
- at least one page. In the common case where the list has an
- ordering (either a natural one or one imposed by the implementation) however, it is easy to avoid
- keeping per-client state on the server.
- </p>
- <p>
- One trivial case is "fixed order"; if the server always sends
- <code>o:client</code> representations in the order
- <code>#JohnZSmith, #BettyASmith, #JoanRSmith, #GlenWSmith, #AlfredESmith</code> (or indeed,
- in <i>any</i> predictable order), then it can put the "last seen" identifier in the <a href="#dfn-next-page-link" class="internalDFN">next page link</a>
- of each <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> as it is retrieved <em>by each client</em>. The "session state"
- is, in effect, kept by the client.
- In this case, the <a href="#dfn-next-page-link" class="internalDFN">next page link</a> in the first page might be:
- </p>
- <div class="example"><div class="example-title"><span>Example 20</span></div><pre class="example" id="paging-no-session-state1">Link: <http://example.org/customer-relations?resumeafter=JoanRSmith>; rel='next'</pre></div>
- <p>
- If the server also supports <a href="#dfn-backward-traversal" class="internalDFN">backward traversal</a>, then the second page's
- <a href="#dfn-previous-page-link" class="internalDFN">previous page link</a> might be:
- </p>
- <div class="example"><div class="example-title"><span>Example 21</span></div><pre class="example" id="paging-no-session-state2">Link: <http://example.org/customer-relations?resumebefore=GlenWSmith>; rel='next'</pre></div>
- <p>
- Keep in mind that this is an exemplary server implementation decision; it is not prescribed by
- LDP Paging, and other choices are certainly possible. As long as the URIs used in links
- are opaque to clients, any choice within the constraints of all normative references is permissible.
- </p>
-</section>
-
-
-<section class="appendix informative" id="acks" typeof="bibo:Chapter" resource="#acks" rel="bibo:Chapter">
-<!--OddPage--><h2 aria-level="1" role="heading" id="h2_acks"><span class="secno">B. </span>Acknowledgements</h2><p><em>This section is non-normative.</em></p>
-
- <p>The following people have been instrumental in providing thoughts, feedback,
-reviews, content, criticism and input in the creation of this specification:</p>
-
- <p style="margin-left: 3em;">
- Alexandre Bertails, Andrei Sambra, Andy Seaborne, Antonis Loizou, Arnaud Le Hors, 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 Gutiérrez, Nandana Mihindukulasooriya, Olivier Berger, Pierre-Antoine Champin, Raúl García 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
- </p>
-
-</section>
-
-<section class="appendix informative" id="history" typeof="bibo:Chapter" resource="#history" rel="bibo:Chapter">
-<!--OddPage--><h2 aria-level="1" role="heading" id="h2_history"><span class="secno">C. </span>Change History</h2><p><em>This section is non-normative.</em></p>
-<p>The change history is up to the editors to insert a brief summary of
-changes, ordered by most recent changes first and with heading from which
-public draft it has been changed from.
-</p>
-<em>Summary</em>
-<ul>
- <li>Split paging out from core LDP 1.0 specification into this document</li>
- <li>Updated detection of paged resources based on link relations</li>
- <li>Added rule to keep containment and membership triples for same resource on same page</li>
- <li>Use of link header to location sort criteria</li>
- <li>Added additional ways to request paging based kilobyte and membership count</li>
-</ul>
-
-<!-- <p>The change history is up to the editors to insert a brief summary of
-changes, ordered by most recent changes first and with heading from which
-public draft it has been changed from.
-</p> -->
-
-<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
-<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140730/">Last Call Draft</a></em></blockquote> -->
-<!-- <ul>
- <li>2014-08-25 - max-triple-count, max-member-count, max-kbyte-count support must > should per Aug 25 mtg (JA) </li>
- <li>2014-08-25 - Clarify example (JA) </li>
- <li>2014-08-22 - AT RISK the three limits, first reached per Aug 18 mtg (JA) </li>
- <li>2014-08-21 - max-triple-count, max-member-count, max-kbyte-count with parms being integers per Aug 18 mtg (JA) </li>
- <li>2014-08-05 - Re-cast sort criteria as rdf:List compatible with syntactic sugar for those (JA) </li>
- <li>2014-08-05 - Fuss SOTD for Arnaud (JA) </li>
- <li>2014-08-04 - Fuss with SortValueAscending value for Sandro (JA) </li>
- <li>2014-08-04 - Incorporating resolutions from today's WG meeting (JA) </li>
- <li>2014-07-30 - Rewording based on SS's 7/17 email comments (JA) </li>
- <li>2014-07-29 - Fully specify 303+location's URI (JA) </li>
- <li>2014-07-29 - Fuss with SortValueAscending value for Sandro (JA) </li>
- <li>2014-07-29 - Update 6.2.9 to resolve the "add only at the end"/sorted container conflict (JA) </li>
- <li>2014-07-29 - Remove chunked transfer encoding, which readers were conflating with paging (chunking) (JA) </li>
- <li>2014-07-29 - Finish Turtle updates for change to Link header to locate sort criteria (JA) </li>
- <li>2014-07-28 - Updates based on Sandro's email, excluding those on public comments list (JA) </li>
- <li>2014-07-28 - Updates to address public review comment on must-not initiate paging (JA) </li>
- <li>2014-07-28 - Updates to address public review comment on Prefer (JA) </li>
- <li>2014-07-17 - Fixed minor spelling/grammar and validation problems (SS)</li>
- <li>2014-07-15 - Final updates hopefully before LC2 draft issued (JA) </li>
- <li>2014-07-09 - Fix Ashok's emailed comments (JA) </li>
- <li>2014-07-09 - Clean up clients chapter, references, non/normative section listing in conformance, kitchen sink (JA) </li>
- <li>2014-07-09 - Move paging example into "intro" chapter 4 (JA) </li>
- <li>2014-07-08 - Resolve a set of editorial to-dos (JA) </li>
- <li>2014-07-07 - Clients must consent to/invite paging per 20140630 resolution 2 (JA) </li>
- <li>2014-07-07 - Rename single-page resource to in-sequence page resource per 20140630 resolution 3 (JA) </li>
- <li>2014-06-10 - Use http-bis and Prefer RFC numbers, adjust BNF to match bis changes (JA) </li>
- <li>2014-05-22 - Spec membership & containment triples on same page (JA) </li>
- <li>2014-05-22 - Spec syntax for page size hint; still need to wrap more text and examples around it (JA) </li>
- <li>2014-05-20 - Spec Sandro's proposal, choose link relation for detection of paged resource changes (JA) </li>
- <li>2014-05-19 - Rewrote non-normative parts, cleaned up terminology, ordering undefined when paging non-LDPC LDPRs (JA) </li>
- <li>2014-05-15 - Fixed Respec messages by adding "terminology from LDP" section (JA) </li>
- <li>2014-03-10 - Fixed namespaces (SS) </li>
- <li>2014-02-18 - Split off LDP-Paging from LDP (SS) </li>
-</ul>
-<blockquote><em><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/94420c5678ae/ldp.html">February 18, 2014 Editor's Draft</a></em></blockquote> -->
-</section>
-
-
-
-<section id="references" class="appendix" typeof="bibo:Chapter" resource="#references" rel="bibo:Chapter"><!--OddPage--><h2 aria-level="1" role="heading" id="h2_references"><span class="secno">D. </span>References</h2><section id="normative-references" typeof="bibo:Chapter" resource="#normative-references" rel="bibo:Chapter"><h3 aria-level="2" role="heading" id="h3_normative-references"><span class="secno">D.1 </span>Normative references</h3><dl class="bibliography" about=""><dt id="bib-2NN">[2NN]</dt><dd rel="dcterms:requires">E. Prud'hommeaux. <a href="http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-2NN.xml"><cite>The Hypertext Transfer Protocol (HTTP) Status Code 2NN (Contents of Related)</cite></a>. Internet-Draft. URL: <a href="http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-2NN.xml">http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-2NN.xml</a>
-</dd><dt id="bib-LDP">[LDP]</dt><dd rel="dcterms:requires">Steve Speicher; John Arwe; Ashok Malhotra. <a href="http://www.w3.org/TR/ldp/"><cite>Linked Data Platform 1.0</cite></a>. 19 June 2014. W3C Candidate Recommendation. URL: <a href="http://www.w3.org/TR/ldp/">http://www.w3.org/TR/ldp/</a>
-</dd><dt id="bib-REL-CANONICAL">[REL-CANONICAL]</dt><dd rel="dcterms:requires">M. Ohye; J. Kupke. <a href="http://tools.ietf.org/html/rfc6596"><cite>The Canonical Link Relation</cite></a>. Informational. URL: <a href="http://tools.ietf.org/html/rfc6596">http://tools.ietf.org/html/rfc6596</a>
-</dd><dt id="bib-RFC2119">[RFC2119]</dt><dd rel="dcterms:requires">S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate Requirement Levels</cite></a>. March 1997. Best Current Practice. URL: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>
-</dd><dt id="bib-RFC5988">[RFC5988]</dt><dd rel="dcterms:requires">M. Nottingham. <a href="http://www.ietf.org/rfc/rfc5988.txt"><cite>Web Linking</cite></a>. October 2010. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc5988.txt">http://www.ietf.org/rfc/rfc5988.txt</a>
-</dd><dt id="bib-RFC7230">[RFC7230]</dt><dd rel="dcterms:requires">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7230.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7230.txt">http://www.ietf.org/rfc/rfc7230.txt</a>
-</dd><dt id="bib-RFC7231">[RFC7231]</dt><dd rel="dcterms:requires">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7231.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7231.txt">http://www.ietf.org/rfc/rfc7231.txt</a>
-</dd><dt id="bib-RFC7232">[RFC7232]</dt><dd rel="dcterms:requires">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7232.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7232.txt">http://www.ietf.org/rfc/rfc7232.txt</a>
-</dd><dt id="bib-RFC7238">[RFC7238]</dt><dd rel="dcterms:requires">J. Reschke. <a href="http://www.ietf.org/rfc/rfc7238.txt"><cite>The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)</cite></a>. June 2014. Experimental. URL: <a href="http://www.ietf.org/rfc/rfc7238.txt">http://www.ietf.org/rfc/rfc7238.txt</a>
-</dd><dt id="bib-RFC7240">[RFC7240]</dt><dd rel="dcterms:requires">J. Snell. <a href="http://www.ietf.org/rfc/rfc7240.txt"><cite>Prefer Header for HTTP</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7240.txt">http://www.ietf.org/rfc/rfc7240.txt</a>
-</dd><dt id="bib-WEBARCH">[WEBARCH]</dt><dd rel="dcterms:requires">Ian Jacobs; Norman Walsh. <a href="http://www.w3.org/TR/webarch/"><cite>Architecture of the World Wide Web, Volume One</cite></a>. 15 December 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a>
-</dd><dt id="bib-sparql11-query">[sparql11-query]</dt><dd rel="dcterms:requires">Steven Harris; Andy Seaborne. <a href="http://www.w3.org/TR/sparql11-query/"><cite>SPARQL 1.1 Query Language</cite></a>. 21 March 2013. W3C Recommendation. URL: <a href="http://www.w3.org/TR/sparql11-query/">http://www.w3.org/TR/sparql11-query/</a>
-</dd></dl></section><section id="informative-references" typeof="bibo:Chapter" resource="#informative-references" rel="bibo:Chapter"><h3 aria-level="2" role="heading" id="h3_informative-references"><span class="secno">D.2 </span>Informative references</h3><dl class="bibliography" about=""><dt id="bib-LDP-UCR">[LDP-UCR]</dt><dd rel="dcterms:references">Steve Battle; Steve Speicher. <a href="http://www.w3.org/TR/ldp-ucr/"><cite>Linked Data Platform Use Cases and Requirements</cite></a>. 13 March 2014. W3C Note. URL: <a href="http://www.w3.org/TR/ldp-ucr/">http://www.w3.org/TR/ldp-ucr/</a>
-</dd><dt id="bib-NON-REPEATABLE-READS">[NON-REPEATABLE-READS]</dt><dd rel="dcterms:references">Various. <a href="http://en.wikipedia.org/wiki/Isolation_(database_systems)#Non-repeatable_reads"><cite>Wikipedia: Isolation (database systems)</cite></a>. N/A. URL: <a href="http://en.wikipedia.org/wiki/Isolation_(database_systems)#Non-repeatable_reads">http://en.wikipedia.org/wiki/Isolation_(database_systems)#Non-repeatable_reads</a>
-</dd><dt id="bib-READ-COMMITTED">[READ-COMMITTED]</dt><dd rel="dcterms:references">Various. <a href="http://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed"><cite>Wikipedia: Isolation (database systems)</cite></a>. N/A. URL: <a href="http://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed">http://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed</a>
-</dd><dt id="bib-RFC5005">[RFC5005]</dt><dd rel="dcterms:references">M. Nottingham. <a href="http://www.ietf.org/rfc/rfc5005.txt"><cite>Feed Paging and Archiving</cite></a>. September 2007. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc5005.txt">http://www.ietf.org/rfc/rfc5005.txt</a>
-</dd><dt id="bib-turtle">[turtle]</dt><dd rel="dcterms:references">Eric Prud'hommeaux; Gavin Carothers. <a href="http://www.w3.org/TR/turtle/"><cite>RDF 1.1 Turtle</cite></a>. 25 February 2014. W3C Recommendation. URL: <a href="http://www.w3.org/TR/turtle/">http://www.w3.org/TR/turtle/</a>
-</dd></dl></section></section></body></html>
\ No newline at end of file
--- a/TR/WD-ldp-paging-20140828/ldp-paging.ttl Mon Sep 08 12:33:46 2014 -0400
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,93 +0,0 @@
-# See details within this document for linkage to specification and purpose.
-# This ontology file is a non-normative supporting document.
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
-@prefix owl: <http://www.w3.org/2002/07/owl#>.
-@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
-@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .
-@prefix : <http://www.w3.org/ns/ldp#>.
-
-:
- a owl:Ontology;
- dcterms:description "Vocabulary URIs defined in the Linked Data Platform Paging (LDP-Paging) namespace.";
- dcterms:title "The W3C Linked Data Platform Paging (LDP-Paging) Vocabulary";
- rdfs:label "W3C Linked Data Platform Paging (LDP-Paging)";
- rdfs:comment "This ontology provides an informal representation of the concepts and terms
- as defined in the LDP specification. Consult the LDP specification for normative reference.";
- rdfs:seeAlso <http://www.w3.org/2012/ldp>,
- <http://www.w3.org/TR/ldp-ucr/>,
- <http://www.w3.org/TR/ldp/>,
- <http://www.w3.org/TR/ldp-paging/>,
- <http://www.w3.org/2011/09/LinkedData/>.
-
-:pageSortCriteria
- a rdf:Property;
- rdfs:comment "Link to the list of sorting criteria used by the server in a representation. Typically used on Link response headers as an extension link relation URI in the rel= parameter.";
- vs:term_status "unstable";
- rdfs:domain :Page;
- rdfs:isDefinedBy :;
- rdfs:label "pageSortCriteria";
- rdfs:range rdf:List.
-
-:pageSortCriterion
- a rdf:Class;
- rdfs:comment "Element in the list of sorting criteria used by the server to assign container members to pages.";
- vs:term_status "unstable";
- rdfs:label "pageSortCriterion";
- rdfs:isDefinedBy :.
-
-:pageSortPredicate
- a rdf:Property;
- rdfs:comment "Predicate used to specify the order of the members across a page sequence's in-sequence page resources; it asserts nothing about the order of members in the representation of a single page.";
- vs:term_status "unstable";
- rdfs:domain :pageSortCriterion;
- rdfs:isDefinedBy :;
- rdfs:label "pageSortPredicate";
- rdfs:range rdf:Property.
-
-:pageSortOrder
- a rdf:Property;
- rdfs:comment "The ascending/descending/etc order used to order the members across pages in a page sequence.";
- vs:term_status "unstable";
- rdfs:domain :pageSortCriterion;
- rdfs:isDefinedBy :;
- rdfs:label "pageSortOrder";
- rdfs:range rdf:Resource.
-
-:pageSortCollation
- a rdf:Property;
- rdfs:comment "The collation used to order the members across pages in a page sequence when comparing strings.";
- vs:term_status "unstable";
- rdfs:domain :pageSortCriterion;
- rdfs:isDefinedBy :;
- rdfs:label "pageSortCollation";
- rdfs:range rdf:Property.
-
-:Ascending
- a rdf:Description; # individual
- rdfs:comment "Ascending order.";
- vs:term_status "unstable";
- rdfs:isDefinedBy :;
- rdfs:label "Ascending".
-
-:Descending
- a rdf:Description; # individual
- rdfs:comment "Descending order.";
- vs:term_status "unstable";
- rdfs:isDefinedBy :;
- rdfs:label "Descending".
-
-:Page
- a rdfs:Class;
- rdfs:comment "URI signifying that the resource is an in-sequence page resource, as defined by LDP Paging. Typically used on Link rel='type' response headers.";
- vs:term_status "unstable";
- rdfs:isDefinedBy :;
- rdfs:label "Page".
-
-:pageSequence
- a rdfs:Class;
- rdfs:comment "Link to a page sequence resource, as defined by LDP Paging. Typically used to communicate the sorting criteria used to allocate LDPC members to pages.";
- vs:term_status "unstable";
- rdfs:isDefinedBy :;
- rdfs:label "Page".
-
\ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/TR/WD-ldp-paging-20140909/Overview.html Mon Sep 08 12:44:59 2014 -0400
@@ -0,0 +1,2413 @@
+<!DOCTYPE html>
+<html lang="en" dir="ltr" typeof="bibo:Document w3p:LastCall" about="" property="dcterms:language" content="en">
+<head>
+ <title>Linked Data Platform Paging 1.0</title>
+ <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+ <!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+
+
+ <style type="text/css">
+ div.rule {padding-top: 1em;}
+ div.ldp-issue-open {
+ border-color: #E05252;
+ background: #FBE9E9;
+ padding: 0.5em;
+ margin: 1em 0;
+ position: relative;
+ clear: both;
+ border-left-width: .5em;
+ border-left-style: solid;
+ }
+ div.ldp-issue-pending {
+ border-color: #FAF602;
+ background: #F7F6BC;
+ padding: 0.5em;
+ margin: 1em 0;
+ position: relative;
+ clear: both;
+ border-left-width: .5em;
+ border-left-style: solid;
+ }
+ div.ldp-issue-closed {
+ border-color: #009900;
+ background: #BCF7CF;
+ padding: 0.5em;
+ margin: 1em 0;
+ position: relative;
+ clear: both;
+ border-left-width: .5em;
+ border-left-style: solid;
+ }
+ div.ldp-issue-title {
+ color: #E05252;
+ padding-right: 1em;
+ min-width: 7.5em;
+ }
+ .atrisk {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #ffc;
+ }
+ .atrisktext {
+ /* content: "Feature At Risk"; */
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+ }
+ .normal {
+ font-weight: normal;
+ font: normal 100% sans-serif;
+ }
+ .indented {
+ margin-left: +3em;
+ }
+ tr:nth-of-type(odd),.oddrow {
+ background:#F2F2F2; /* light grey, just enough to differentiate from white */
+ }
+ td {
+ padding:0 +1ex 0 +1ex; /* add a bit of space from rule/edge to text */
+ }
+
+ </style>
+ <style type="text/css" media="all">
+ code {
+ font-weight:bold;
+ font-size:larger;
+ }
+ /* ReSpec uses color ff4500 for code elements, which does not print well on some black & white printers
+ and is a little hard to read for some folks even on-line.
+ The default code font size was also somewhat too small/hard to read.
+ */
+ </style>
+ <style>/*****************************************************************
+ * ReSpec 3 CSS
+ * Robin Berjon - http://berjon.com/
+ *****************************************************************/
+
+/* --- INLINES --- */
+em.rfc2119 {
+ text-transform: lowercase;
+ font-variant: small-caps;
+ font-style: normal;
+ color: #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+ border: none;
+}
+
+dfn {
+ font-weight: bold;
+}
+
+a.internalDFN {
+ color: inherit;
+ border-bottom: 1px solid #99c;
+ text-decoration: none;
+}
+
+a.externalDFN {
+ color: inherit;
+ border-bottom: 1px dotted #ccc;
+ text-decoration: none;
+}
+
+a.bibref {
+ text-decoration: none;
+}
+
+cite .bibref {
+ font-style: normal;
+}
+
+code {
+ color: #C83500;
+}
+
+/* --- TOC --- */
+.toc a, .tof a {
+ text-decoration: none;
+}
+
+a .secno, a .figno {
+ color: #000;
+}
+
+ul.tof, ol.tof {
+ list-style: none outside none;
+}
+
+.caption {
+ margin-top: 0.5em;
+ font-style: italic;
+}
+
+/* --- TABLE --- */
+table.simple {
+ border-spacing: 0;
+ border-collapse: collapse;
+ border-bottom: 3px solid #005a9c;
+}
+
+.simple th {
+ background: #005a9c;
+ color: #fff;
+ padding: 3px 5px;
+ text-align: left;
+}
+
+.simple th[scope="row"] {
+ background: inherit;
+ color: inherit;
+ border-top: 1px solid #ddd;
+}
+
+.simple td {
+ padding: 3px 10px;
+ border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+ background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+ margin-top: 0;
+}
+
+.section dd > p:last-child {
+ margin-bottom: 0;
+}
+
+.section dd {
+ margin-bottom: 1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+ margin-bottom: 0;
+}
+
+@media print {
+ .removeOnSave {
+ display: none;
+ }
+}
+</style><style>/* --- EXAMPLES --- */
+div.example-title {
+ min-width: 7.5em;
+ color: #b9ab2d;
+}
+div.example-title span {
+ text-transform: uppercase;
+}
+aside.example, div.example, div.illegal-example {
+ padding: 0.5em;
+ margin: 1em 0;
+ position: relative;
+ clear: both;
+}
+div.illegal-example { color: red }
+div.illegal-example p { color: black }
+aside.example, div.example {
+ padding: .5em;
+ border-left-width: .5em;
+ border-left-style: solid;
+ border-color: #e0cb52;
+ background: #fcfaee;
+}
+
+aside.example div.example {
+ border-left-width: .1em;
+ border-color: #999;
+ background: #fff;
+}
+aside.example div.example div.example-title {
+ color: #999;
+}
+</style><link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/W3C-WD"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
+<body class="h-entry" role="document" id="respecDocument"><div class="head" role="contentinfo" id="respecHeader">
+ <p>
+
+ <a href="http://www.w3.org/"><img width="72" height="48" src="https://www.w3.org/Icons/w3c_home" alt="W3C"></a>
+
+ </p>
+ <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform Paging 1.0</h1>
+
+ <h2 property="dcterms:issued" datatype="xsd:dateTime" content="2014-09-09T04:00:00.000Z" id="w3c-last-call-working-draft-09-september-2014"><abbr title="World Wide Web Consortium">W3C</abbr> Last Call Working Draft <time class="dt-published" datetime="2014-09-09">09 September 2014</time></h2>
+ <dl>
+
+ <dt>This version:</dt>
+ <dd><a class="u-url" href="http://www.w3.org/TR/2014/WD-ldp-paging-20140909/">http://www.w3.org/TR/2014/WD-ldp-paging-20140909/</a></dd>
+ <dt>Latest published version:</dt>
+ <dd><a href="http://www.w3.org/TR/ldp-paging/">http://www.w3.org/TR/ldp-paging/</a></dd>
+
+
+ <dt>Latest editor's draft:</dt>
+ <dd><a href="http://www.w3.org/2012/ldp/hg/ldp-paging.html">http://www.w3.org/2012/ldp/hg/ldp-paging.html</a></dd>
+
+
+
+
+
+
+ <dt>Previous version:</dt>
+ <dd><a rel="dcterms:replaces" href="http://www.w3.org/TR/2013/WD-ldp-paging-20130730/">http://www.w3.org/TR/2013/WD-ldp-paging-20130730/</a></dd>
+
+
+ <dt>Editors:</dt>
+ <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Steve Speicher" href="http://stevespeicher.blogspot.com">Steve Speicher</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://ibm.com/">IBM Corporation</a></span>
+</dd>
+<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="John Arwe" href="https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?userid=120000CAW7">John Arwe</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://ibm.com/">IBM Corporation</a></span>
+</dd>
+<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Ashok Malhotra" href="mailto:ashok.malhotra@oracle.com">Ashok Malhotra</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oracle.com">Oracle Corporation</a></span>
+</dd>
+
+
+
+ </dl>
+
+
+
+
+
+ <p class="copyright">
+ <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
+ 2014
+
+ <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
+ (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
+ <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
+ <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>),
+
+ All Rights Reserved.
+
+ <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
+ <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
+
+ <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
+
+ rules apply.
+ </p>
+
+
+ <hr>
+</div>
+<section id="abstract" class="introductory" property="dcterms:abstract" datatype="" typeof="bibo:Chapter" resource="#abstract" rel="bibo:Chapter"><h2 aria-level="1" role="heading" id="h2_abstract">Abstract</h2><p>
+This document describes a HTTP-based protocol for clients and servers to be able to efficiently retrieve large Linked Data Platform
+Resource representations by splitting up the responses into separate URL-addressable page resources.
+</p></section><section id="sotd" class="introductory" typeof="bibo:Chapter" resource="#sotd" rel="bibo:Chapter"><h2 aria-level="1" role="heading" id="h2_sotd">Status of This Document</h2>
+
+
+
+ <p>
+ <em>This section describes the status of this document at the time of its publication.
+ Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the
+ latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
+ http://www.w3.org/TR/.</em>
+ </p>
+
+ <p>
+ This is the second Last Call Working Draft document for LDP Paging. The Working Group has addressed all
+ raised issues, and other substantive changes have been made, including the decision to separate LDP Paging
+ from the Linked Data Platform [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>]. Public working drafts of LDP issued prior to March 2014
+ included sections that covered the content now in this document.
+ For changes since its last publication, see <a href="#history" class="sectionRef sec-ref">section <span class="secno">C.</span> <span class="sec-title">Change History</span></a>.
+ </p>
+ <p>The following features are At Risk:</p>
+ <ol>
+ <li>The requirement to make LDP clients <a href="#atrisk-paging">paging-aware</a>.
+ </li>
+ <li>The <a href="#atrisk-units"><code>max-member-count</code> and <code>max-kbyte-count</code> preference parameters</a>,
+ that allows clients to hint at acceptable page sizes. Based on feedback, either or both might be removed or
+ changed to optional prior to the PR draft.
+ </li>
+ <li>The behavior of LDP Paging servers when <a href="#atrisk-paging-multiple-units">multiple page size hints are provided</a>.
+ </li>
+ </ol>
+
+ <p>
+ This document was published by the <a href="http://www.w3.org/2012/ldp">Linked Data Platform Working Group</a> as a Last Call Working Draft.
+
+ This document is intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation.
+
+
+ If you wish to make comments regarding this document, please send them to
+ <a href="mailto:public-ldp-comments@w3.org">public-ldp-comments@w3.org</a>
+ (<a href="mailto:public-ldp-comments-request@w3.org?subject=subscribe">subscribe</a>,
+ <a href="http://lists.w3.org/Archives/Public/public-ldp-comments/">archives</a>).
+
+ The Last Call period ends 30 September 2014.
+
+
+ All comments are welcome.
+
+ </p>
+
+
+ <p>
+ Publication as a Last Call Working Draft does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr>
+ Membership. This is a draft document and may be updated, replaced or obsoleted by other
+ documents at any time. It is inappropriate to cite this document as other than work in
+ progress.
+ </p>
+
+
+
+ <p>
+ This is a Last Call Working Draft and thus the Working Group has determined that this
+ document has satisfied the relevant technical requirements and is sufficiently stable to
+ advance through the Technical Recommendation process.
+ </p>
+
+ <p>
+
+ This document was produced by a group operating under the
+ <a id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent
+ Policy</a>.
+
+
+
+
+ <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/55082/status" rel="disclosure">public list of any patent
+ disclosures</a>
+
+ made in connection with the deliverables of the group; that page also includes
+ instructions for disclosing a patent. An individual who has actual knowledge of a patent
+ which the individual believes contains
+ <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
+ Claim(s)</a> must disclose the information in accordance with
+ <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
+ 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+
+
+ </p>
+
+ <p>This document is governed by the <a id="w3c_process_revision" href="http://www.w3.org/2014/Process-20140801/">1 August 2014 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.
+ </p>
+
+
+
+
+
+</section><section id="toc"><h2 class="introductory" aria-level="1" role="heading" id="h2_toc">Table of Contents</h2><ul class="toc" role="directory" id="respecContents"><li class="tocline"><a href="#intro" class="tocxref"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a href="#terms" class="tocxref"><span class="secno">2. </span>Terminology</a><ul class="toc"><li class="tocline"><a href="#terms-from-ldp" class="tocxref"><span class="secno">2.1 </span>Terms re-used from the Linked Data Platform</a></li><li class="tocline"><a href="#terms-from-paging" class="tocxref"><span class="secno">2.2 </span>Terms normatively defined by this specification</a></li><li class="tocline"><a href="#conventions" class="tocxref"><span class="secno">2.3 </span>Conventions Used in This Document</a></li></ul></li><li class="tocline"><a href="#conformance" class="tocxref"><span class="secno">3. </span>Conformance</a></li><li class="tocline"><a href="#ldpp-ex-mx" class="tocxref"><span class="secno">4. </span>Example paging message exchanges</a><ul class="toc"><li class="tocline"><a href="#ldpp-ex-no-paging" class="tocxref"><span class="secno">4.1 </span>Traditional flow without paging</a></li><li class="tocline"><a href="#ldpp-ex-paging-303" class="tocxref"><span class="secno">4.2 </span>Simple paging flow using redirects</a></li><li class="tocline"><a href="#ldpp-ex-paging-2nn" class="tocxref"><span class="secno">4.3 </span>Removing redirection latency when paging</a></li><li class="tocline"><a href="#ldpp-ex-paging-other-links" class="tocxref"><span class="secno">4.4 </span>Optional paging links</a></li></ul></li><li class="tocline"><a href="#ldppclient" class="tocxref"><span class="secno">5. </span>Linked Data Platform Paging Clients</a><ul class="toc"><li class="tocline"><a href="#general-requirements" class="tocxref"><span class="secno">5.1 </span>General requirements</a><ul class="toc"></ul></li><li class="tocline"><a href="#ldpp-hints" class="tocxref"><span class="secno">5.2 </span>Client preferences</a></li></ul></li><li class="tocline"><a href="#ldpr" class="tocxref"><span class="secno">6. </span>Linked Data Platform Resources</a><ul class="toc"><li class="tocline"><a href="#ldpr-PagingIntro" class="tocxref"><span class="secno">6.1 </span>Paging considerations</a></li><li class="tocline"><a href="#ldpr-PagingGET" class="tocxref"><span class="secno">6.2 </span>HTTP GET</a><ul class="toc"></ul></li></ul></li><li class="tocline"><a href="#ldpc" class="tocxref"><span class="secno">7. </span>Linked Data Platform Containers</a><ul class="toc"><li class="tocline"><a href="#ldpc-general" class="tocxref"><span class="secno">7.1 </span>Requirements when paging LDP Containers</a><ul class="toc"></ul></li><li class="tocline"><a href="#ldpc-informative" class="tocxref"><span class="secno">7.2 </span>Ordering of container members across pages</a><ul class="toc"></ul></li><li class="tocline"><a href="#ldpc-HTTP_GET" class="tocxref"><span class="secno">7.3 </span>HTTP GET requirements for member ordering across pages</a><ul class="toc"></ul></li></ul></li><li class="tocline"><a href="#security" class="tocxref"><span class="secno">8. </span>Security Considerations</a></li><li class="tocline"><a href="#ldpr-impl" class="tocxref"><span class="secno">A. </span>Paging LDPRs without maintaining server-side session state</a></li><li class="tocline"><a href="#acks" class="tocxref"><span class="secno">B. </span>Acknowledgements</a></li><li class="tocline"><a href="#history" class="tocxref"><span class="secno">C. </span>Change History</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">D. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">D.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">D.2 </span>Informative references</a></li></ul></li></ul></section>
+
+
+
+<section class="informative" id="intro" typeof="bibo:Chapter" resource="#intro" rel="bibo:Chapter">
+
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_intro"><span class="secno">1. </span>Introduction</h2><p><em>This section is non-normative.</em></p>
+ <p>
+ This specification provides a widely re-usable pattern to make the state of a large <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged HTTP resource</a>
+ available as a list of smaller subset resources (<a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">pages</a>) whose
+ representations are less burdensome for servers to form.
+ <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">Paged resources</a> must be LDP Resources (LDPRs) [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>].
+ Any <abbr title="Linked Data Platform Resource">LDPR</abbr> can be paged, but certain aspects of paging like ordering are only well-defined for
+ particular sub-classes of LDPRs, like
+ LDP-RSs or LDPCs.
+ </p>
+ <p>
+ When a client attempts to retrieve a <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>, the server either redirects the client to
+ a "first page" <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">resource</a> or provides the
+ representation of the "first page" <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">resource</a> in its response,
+ depending on the client's request preferences and the server's capabilities.
+ The response
+ includes links to other page(s) in the sequence, as do subsequent pages.
+ <a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">Paging-aware clients</a>
+ know how to combine pages of an <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>, and possibly (via other specifications) other LDPRs.
+ LDP Paging defines a mechanism by which clients can learn that the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> has been changed
+ so that they can, for example, abandon a page traversal as early as possible.
+ A detailed example of paging is provided in <a href="#ldpp-ex-mx" class="sectionRef sec-ref">section <span class="secno">4.</span> <span class="sec-title">Example paging message exchanges</span></a>.
+ </p>
+ <p>
+ When a <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> is also an <abbr title="Linked Data Platform Container">LDPC</abbr>, some additional efficiencies become possible in cases
+ where the server predictably assigns members to pages and is able to communicate its assignment
+ algorithm to clients. The <a href="#ldpc" class="sectionRef sec-ref">section <span class="secno">7.</span> <span class="sec-title">Linked Data Platform Containers</span></a> defines a facility to communicate
+ the sort order of member-to-page assignments, to handle that common implementation algorithm.
+ </p>
+ <p>
+ For context and background, it could be useful to read <a href="#bib-LDP-UCR">Linked Data Platform Use Case and Requirements</a> [<cite><a class="bibref" href="#bib-LDP-UCR">LDP-UCR</a></cite>].
+ </p>
+</section>
+
+<section id="terms" typeof="bibo:Chapter" resource="#terms" rel="bibo:Chapter">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_terms"><span class="secno">2. </span>Terminology</h2>
+
+<section id="terms-from-ldp" typeof="bibo:Chapter" resource="#terms-from-ldp" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_terms-from-ldp"><span class="secno">2.1 </span>Terms re-used from the Linked Data Platform</h3>
+
+<p>This section is non-normative. It summarizes a subset of terms formally defined in [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>] for the reader's convenience.
+</p>
+ <dl class="glossary">
+
+ <dt><dfn id="dfn-ldp-server">LDP server</dfn></dt>
+ <dd>A conforming HTTP server [<cite><a class="bibref" href="#bib-RFC7230">RFC7230</a></cite>] that follows the rules defined by [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>]
+ when it is serving LDPRs and LDPCs.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-ldp-client">LDP client</dfn></dt>
+ <dd>A conforming HTTP client [<cite><a class="bibref" href="#bib-RFC7230">RFC7230</a></cite>] that follows the rules defined by [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>] when
+ interacting with a <a href="#dfn-ldp-server" class="internalDFN">LDP server</a>.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-linked-data-platform-resource">Linked Data Platform Resource</dfn> (<abbr title="Linked Data Platform Resource">LDPR</abbr>)</dt>
+ <dd>A HTTP resource whose state is represented in any way that conforms to the
+ patterns and conventions in [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>].<p></p></dd>
+
+ <dt><dfn id="dfn-linked-data-platform-rdf-source">Linked Data Platform RDF Source</dfn> (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>)</dt>
+ <dd>An <a title="Linked Data Platform Resource" href="#dfn-linked-data-platform-resource" class="internalDFN"><abbr title="Linked Data Platform Resource">LDPR</abbr></a> whose state is fully represented in RDF.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-linked-data-platform-container">Linked Data Platform Container</dfn> (<abbr title="Linked Data Platform Container">LDPC</abbr>)</dt>
+ <dd>A <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> representing a collection of <a title="Linked Data Platform Resource" href="#dfn-linked-data-platform-resource" class="internalDFN">LDPRs</a> linked by
+ <a href="#dfn-membership-triples" class="internalDFN">membership triples</a> and <a href="#dfn-containment-triples" class="internalDFN">containment triples</a>.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-membership-triples">Membership triples</dfn></dt>
+ <dd>A set of triples that lists an <a title="Linked Data Platform Container" href="#dfn-linked-data-platform-container" class="internalDFN"><abbr title="Linked Data Platform Container">LDPC</abbr>'s</a> members.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-containment-triples">Containment triples</dfn></dt>
+ <dd>
+ A set of triples, maintained by an <abbr title="Linked Data Platform Container">LDPC</abbr>, that lists documents created by the <abbr title="Linked Data Platform Container">LDPC</abbr> but not yet deleted.
+ <p></p></dd>
+
+ </dl>
+
+</section>
+
+<section id="terms-from-paging" typeof="bibo:Chapter" resource="#terms-from-paging" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_terms-from-paging"><span class="secno">2.2 </span>Terms normatively defined by this specification</h3>
+
+<p>The following terminology is based on <abbr title="World Wide Web Consortium">W3C</abbr>'s Architecture of the World Wide Web [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>],
+ Hyper-text Transfer Protocol ([<cite><a class="bibref" href="#bib-RFC7230">RFC7230</a></cite>], [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>]) and Linked Data Platform [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>].
+</p>
+ <dl class="glossary">
+ <dt><dfn id="dfn-paged-resource">Paged resource</dfn></dt>
+ <dd>A <abbr title="Linked Data Platform Resource">LDPR</abbr> whose representation may be too large for a server to construct in a single HTTP response
+ (e.g. without running out of memory), for which an
+ <a href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging server</a> offers a <a href="#dfn-page-sequence" class="internalDFN">page sequence</a> that allows clients to obtain subsets of its state
+ over some period of time by making multiple HTTP requests.
+ <p>
+ For readers
+ familiar with paged feeds [<cite><a class="bibref" href="#bib-RFC5005">RFC5005</a></cite>], a paged resource is similar to a logical feed.
+ Any resource could be considered to be a paged resource consisting of exactly one page,
+ although there is no known advantage in doing so.
+ </p>
+ <p></p></dd>
+
+ <dt><dfn id="dfn-page-sequence">Page sequence</dfn></dt>
+ <dd>A sequence of related <a title="Linked Data Platform Resource" href="#dfn-linked-data-platform-resource" class="internalDFN">LDPRs</a>
+ <var>P<sub>1 (first)</sub>, P<sub>2</sub>, ...,P<sub>n (last)</sub></var>,
+ each of which contains a subset of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>'s state.
+ <p>
+ When the representations of the sequence's <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">resources</a>
+ are combined by a client, the client has a copy of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>'s
+ state; if the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> changed while the client was retrieving the sequence's resources,
+ then the client's copy of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>'s state can be incomplete or inconsistent
+ with the state of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> at any single instant in time.
+ Thus, it is impossible to strongly guarantee that the result of this retrieval and combination process is the same state that
+ the client would obtain using a single request (if that were possible), but LDP does provide
+ a way for <a href="#ldpr-notify-changes">clients to detect when the paged resource's state changed</a> during the retrieval process.
+ As long as the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>'s state did not change during the retrieval process, the
+ client's copy of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>'s state will be as accurate as the server implementation
+ allows it to be.
+ </p>
+ <p>
+ If a paged resource <var>P</var> is a <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>,
+ the representation of each <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> contains
+ a subset of the triples in <var>P</var>, and a client can merge those graphs to combine them.
+ LDP allows paging of resources other than <a title="Linked Data Platform RDF Source" href="#dfn-linked-data-platform-rdf-source" class="internalDFN">LDP-RSs</a>,
+ but does not specify how clients combine
+ their representations. See <a href="#ldpr" class="sectionRef sec-ref">section <span class="secno">6.</span> <span class="sec-title">Linked Data Platform Resources</span></a> for additional details.
+ </p>
+ For readers
+ familiar with paged feeds [<cite><a class="bibref" href="#bib-RFC5005">RFC5005</a></cite>], a <a href="#dfn-page-sequence" class="internalDFN">page sequence</a> is similar to a paged feed
+ and many of the same consideration (echoed above) apply.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-in-sequence-page-resource">In-sequence page resource</dfn></dt>
+ <dd>One <abbr title="Linked Data Platform Resource">LDPR</abbr> in a <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>,
+ which contains a subset of the state
+ of another resource <var>P</var>, called the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>.
+ For readers
+ familiar with paged feeds [<cite><a class="bibref" href="#bib-RFC5005">RFC5005</a></cite>], an in-sequence page resource is similar to a feed document.
+ <p>
+ Note: the choice of terms was designed to help authors and readers clearly differentiate between
+ the <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN"><em>resource being paged</em></a>, and the
+ <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN"><em>individual page resources</em></a>,
+ in cases where both are mentioned in
+ close proximity.
+ </p>
+ <p>
+ Note: page sequences are described and named with respect to how they are traversed starting from the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>,
+ using only <a href="#dfn-forward-traversal" class="internalDFN">forward traversal</a>.
+ This <em>does not</em> imply anything more; the choice is arbitrary.
+ For example, following forward links does not imply that resources later in the sequence are newer; the forward direction might
+ correspond to moving forward or backward in time or along some other dimension, but any such relationship is server-specific.
+ It is not implied by LDP Paging,
+ absent additional concrete assertions like those <a href="#ldpc-HTTP_GET">defined later</a> for <abbr title="Linked Data Platform Container">LDPC</abbr> representations.
+ </p>
+ <p></p></dd>
+
+ <dt><dfn id="dfn-first-page-link">first page link</dfn></dt>
+ <dd>A link to the first <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> <var>P<sub>1 (first)</sub></var>
+ of a <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>. The first page is the one that a LDP paging server
+ redirects to (<code>303</code> response) or provides the representation of (<code>2NN</code> response) in response
+ to a retrieval request for the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>'s URI.
+ Syntactically, a
+ HTTP <code>Link <<var>P<sub>1</sub></var>>; rel='first'</code>
+ header [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
+ <p></p></dd>
+
+ <dt><dfn id="dfn-next-page-link">next page link</dfn></dt>
+ <dd>A link to the next <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
+ of a <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>. Syntactically, a
+ HTTP <code>Link <<var>P<sub>i</sub></var>>; rel='next'</code>
+ header [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>] where
+ the context URI identifies some <var>P<sub>i=1 (first)...n-1 (next to last)</sub></var> and
+ the target URI identifies <var>P<sub>i+1</sub></var>.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-last-page-link">last page link</dfn></dt>
+ <dd>A link to the last <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> <var>P<sub>n (last)</sub></var>
+ of a <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>.
+ The last page is the page that terminates a <a href="#dfn-forward-traversal" class="internalDFN">forward traversal</a>, because it contains no <a href="#dfn-next-page-link" class="internalDFN">next page link</a>.
+ Syntactically, a
+ HTTP <code>Link <<var>P<sub>n</sub></var>>; rel='last'</code>
+ header [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
+ <p></p></dd>
+
+ <dt><dfn id="dfn-previous-page-link">previous page link</dfn></dt>
+ <dd>A link to the previous <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
+ of a <a href="#dfn-page-sequence" class="internalDFN">page sequence</a> Syntactically, a
+ HTTP <code>Link <<var>P<sub>i</sub></var>>; rel='prev'</code>
+ header [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>] where
+ the context URI identifies some <var>P<sub>i=2...n (last)</sub></var> and
+ the target URI identifies <var>P<sub>i-1</sub></var>.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-paging-link">paging link</dfn></dt>
+ <dd>Any of the links defined by LDP Paging:
+ <a title="first page link" href="#dfn-first-page-link" class="internalDFN">first page links</a>,
+ <a title="next page link" href="#dfn-next-page-link" class="internalDFN">next page links</a>,
+ <a title="last page link" href="#dfn-last-page-link" class="internalDFN">last page links</a>,
+ <a title="previous page link" href="#dfn-previous-page-link" class="internalDFN">previous page links</a>.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-forward-traversal">forward traversal</dfn></dt>
+ <dd>The process of following <a title="next page link" href="#dfn-next-page-link" class="internalDFN">next page links</a> from
+ some starting point.
+ <p>
+ Note: "forward" should <i>not</i> be read to mean anything more than a name for one direction through the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>.
+ For example, following forward links does not imply that resources later in the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a> are newer; the forward direction might
+ correspond to moving forward in time, but any such relationship is server-specific not implied by LDP Paging
+ absent additional concrete assertions like those <a href="#ldpc-HTTP_GET">defined later</a> for <abbr title="Linked Data Platform Container">LDPC</abbr> representations.
+ </p>
+ <p></p></dd>
+
+ <dt><dfn id="dfn-backward-traversal">backward traversal</dfn></dt>
+ <dd>The process of following <a title="previous page link" href="#dfn-previous-page-link" class="internalDFN">previous page links</a> from
+ some starting point.
+ <p>
+ Note: "backward" should <i>not</i> be read to mean anything more than a name for one direction through the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>.
+ </p>
+ <p></p></dd>
+
+ </dl>
+</section>
+
+<section id="conventions" typeof="bibo:Chapter" resource="#conventions" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_conventions"><span class="secno">2.3 </span>Conventions Used in This Document</h3>
+
+ <p>The namespace for LDP Paging is <code>http://www.w3.org/ns/ldp#</code>.</p>
+ <p>Sample resource representations are provided in <code>text/turtle</code>
+ format [<cite><a class="bibref" href="#bib-turtle">turtle</a></cite>].</p>
+ <p>Commonly used namespace prefixes:</p>
+ <pre style="word-wrap: break-word; white-space: pre-wrap;">
+ @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#>.
+ </pre>
+</section>
+</section>
+
+<section id="conformance" typeof="bibo:Chapter" resource="#conformance" rel="bibo:Chapter"><!--OddPage--><h2 aria-level="1" role="heading" id="h2_conformance"><span class="secno">3. </span>Conformance</h2>
+<p>
+ As well as sections marked as non-normative, all authoring guidelines, diagrams, examples,
+ and notes in this specification are non-normative. Everything else in this specification is
+ normative.
+</p>
+<p>
+ The key words <em class="rfc2119" title="MUST">MUST</em>, <em class="rfc2119" title="MUST NOT">MUST NOT</em>, <em class="rfc2119" title="REQUIRED">REQUIRED</em>, <em class="rfc2119" title="SHOULD">SHOULD</em>, <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em>, <em class="rfc2119" title="RECOMMENDED">RECOMMENDED</em>, <em class="rfc2119" title="MAY">MAY</em>,
+ and <em class="rfc2119" title="OPTIONAL">OPTIONAL</em> in this specification are to be interpreted as described in [<cite><a class="bibref" href="#bib-RFC2119">RFC2119</a></cite>].
+</p>
+
+
+<p>The status of the sections of Linked Data Platform Paging 1.0 (this document) is as follows:</p>
+
+<ul>
+ <li><a href="#intro" class="sectionRef sec-ref">section <span class="secno">1.</span> <span class="sec-title">Introduction</span></a>: <b>non-normative</b></li>
+ <li><a href="#terms" class="sectionRef sec-ref">section <span class="secno">2.</span> <span class="sec-title">Terminology</span></a>
+ <ul>
+ <li><a href="#terms-from-ldp" class="sectionRef sec-ref">section <span class="secno">2.1</span> <span class="sec-title">Terms re-used from the Linked Data Platform</span></a>: <b>non-normative</b></li>
+ <li><a href="#terms-from-paging" class="sectionRef sec-ref">section <span class="secno">2.2</span> <span class="sec-title">Terms normatively defined by this specification</span></a>: <b>normative</b></li>
+ <li><a href="#conventions" class="sectionRef sec-ref">section <span class="secno">2.3</span> <span class="sec-title">Conventions Used in This Document</span></a>: <b>normative</b></li>
+ </ul>
+ </li>
+ <li><a href="#conformance" class="sectionRef sec-ref">section <span class="secno">3.</span> <span class="sec-title">Conformance</span></a>: <b>normative</b></li>
+ <li><a href="#ldpp-ex-mx" class="sectionRef sec-ref">section <span class="secno">4.</span> <span class="sec-title">Example paging message exchanges</span></a>: <b>non-normative</b></li>
+ <li><a href="#ldppclient" class="sectionRef sec-ref">section <span class="secno">5.</span> <span class="sec-title">Linked Data Platform Paging Clients</span></a>: <b>normative</b></li>
+ <li><a href="#ldpr" class="sectionRef sec-ref">section <span class="secno">6.</span> <span class="sec-title">Linked Data Platform Resources</span></a>: <b>normative</b></li>
+ <li><a href="#ldpc" class="sectionRef sec-ref">section <span class="secno">7.</span> <span class="sec-title">Linked Data Platform Containers</span></a>: <b>normative</b></li>
+ <li><a href="#security" class="sectionRef sec-ref">section <span class="secno">8.</span> <span class="sec-title">Security Considerations</span></a>: <b>non-normative</b></li>
+ <li><a href="#ldpr-impl" class="sectionRef sec-ref">section <span class="secno">A.</span> <span class="sec-title">Paging LDPRs without maintaining server-side session state</span></a>: <b>non-normative</b></li>
+ <li><a href="#acks" class="sectionRef sec-ref">section <span class="secno">B.</span> <span class="sec-title">Acknowledgements</span></a>: <b>non-normative</b></li>
+ <li><a href="#history" class="sectionRef sec-ref">section <span class="secno">C.</span> <span class="sec-title">Change History</span></a>: <b>non-normative</b></li>
+ <li><a href="#normative-references" class="sectionRef sec-ref">section <span class="secno">D.1</span> <span class="sec-title">Normative references</span></a>: <b>normative</b></li>
+ <li><a href="#informative-references" class="sectionRef sec-ref">section <span class="secno">D.2</span> <span class="sec-title">Informative references</span></a>: <b>non-normative</b></li>
+</ul>
+
+<p>A conforming <b><dfn id="dfn-ldp-paging-client">LDP Paging client</dfn></b> is a conforming LDP client [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>] that follows the rules defined by LDP Paging.
+</p>
+
+<p>A conforming <b><dfn id="dfn-ldp-paging-server">LDP Paging server</dfn></b> is a conforming LDP server [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>] that follows the rules defined by LDP Paging.</p>
+</section>
+
+<section class="informative" id="ldpp-ex-mx" typeof="bibo:Chapter" resource="#ldpp-ex-mx" rel="bibo:Chapter">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_ldpp-ex-mx"><span class="secno">4. </span>Example paging message exchanges</h2><p><em>This section is non-normative.</em></p>
+
+ <p>
+ Example Co.'s customer
+ relationship data is identified by the URI <code>http://example.org/customer-relations</code>,
+ and is retrievable using the same URI.
+ </p>
+
+<section id="ldpp-ex-no-paging" typeof="bibo:Chapter" resource="#ldpp-ex-no-paging" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpp-ex-no-paging"><span class="secno">4.1 </span>Traditional flow without paging</h3>
+
+ <p>
+ A standard HTTP client that knows nothing about LDP paging obtains a representation of the
+ resource in the usual way.
+ </p>
+
+ <em>Request</em>
+<div class="example"><div class="example-title"><span>Example 1</span></div><pre class="example">GET /customer-relations HTTP/1.1
+Host: example.org
+Accept: text/turtle</pre></div>
+
+ <p>
+ The server response is:
+ </p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 2</span></div><pre class="example" id="ldpp-ex-no-paging-resp">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".</pre></div>
+
+ <p>
+ As long as the resource being retrieved is small enough that the server can form its
+ representation without running into implementation limits on memory etc., and as long
+ as the client is likewise able to consume these representations, this pattern works
+ fine. Indeed, it's by far the most common pattern on the Web.
+ </p>
+ <p>
+ At the point where server and/or client constraints or consumption preferences come into play, however,
+ something else is needed. LDP Paging addresses this need by giving clients and
+ servers the ability to partition representations into smaller pieces, transfer
+ as many as the client needs (potentially a small subset of the resource's full
+ state), and allows the client to reassemble the pieces (or not) as it prefers.
+ One sees this pattern in contexts such as search page results, as one common
+ example.
+ </p>
+
+</section>
+
+<section id="ldpp-ex-paging-303" typeof="bibo:Chapter" resource="#ldpp-ex-paging-303" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpp-ex-paging-303"><span class="secno">4.2 </span>Simple paging flow using redirects</h3>
+
+ <p>
+ The simplest possible solution would be to redefine the meaning of the existing
+ URI <code>http://example.org/customer-relations</code> from "all customer relations information"
+ to "the first subset of all customer relations information". This would require changes to
+ any existing clients whose code was built using the original definition however, so it's
+ more likely that Example Co. would mint a new URI for "the first subset", define a way to
+ find subsequent subsets, and have clients use this new protocol.
+ </p>
+ <p>
+ The new protocol does not solve the problem of migrating existing clients from the old
+ "all" to the new "first subset" semantic; neither would a <code>303 See Other</code> redirect
+ from the old to the new URI, given the
+ <a href="http://www.w3.org/2001/tag/issues.html#httpRange-14">widespread historical client practice</a> of automatically
+ following <code>303</code> redirects and treating the redirected-to resource as equivalent
+ to the original. The safe route is to have clients explicitly tell the server that they
+ are capable of handling the "first subset" semantic on the redirected-to URI; this is what
+ LDP Paging does.
+ </p>
+ <p>
+ A client aware of LDP paging obtains a representation of the
+ resource in the usual way, and also signals its ability to handle redirection to a first-page resource:
+ </p>
+
+<em>Request</em>
+<div class="example"><div class="example-title"><span>Example 3</span></div><pre class="example">GET /customer-relations HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Prefer: return=representation; max-triple-count="500"</pre></div>
+
+ <p>
+ The server's response contains a <code>303 See Other</code> status code and
+ a <code>Location: http://example.org/customer-relations?page1</code> HTTP response header
+ identifying the target resource, as shown below:
+ </p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 4</span></div><pre class="example" id="ldpp-ex-paging-303-resp1">HTTP/1.1 303 See Other
+Location: <http://example.org/customer-relations?page1></pre></div>
+
+ <p>
+ At this point the client does not know if the target
+ resource is "all" or "the first subset"; it has to retrieve the resource to know.
+ </p>
+
+<em>Request</em>
+<div class="example"><div class="example-title"><span>Example 5</span></div><pre class="example">GET /customer-relations?page1 HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Prefer: return=representation; max-triple-count="500"</pre></div>
+ <p>
+ The server's response is shown below:
+ </p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 6</span></div><pre class="example" id="ldpp-ex-paging-303-resp2">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".</pre></div>
+
+ <p>
+ From this response, the client knows that more data exists and where to find it.
+ The server determines the size of the pages using application-specific methods not defined
+ within this specification, with the client's <code>max-triple-count</code> preference as one
+ input; the simplest method is to make the server's page size equal
+ to the client's preference. In this example, the server chooses a smaller value so
+ there is a second page.
+ </p>
+ <ul>
+ <li>
+ The <code>Link: <http://example.org/customer-relations>; rel='canonical'</code>
+ response header tells the client which resource <code><http://example.org/customer-relations?page1></code>
+ is a page of. The <code>etag="customer-relations-v1"</code> parameter value gives the client a way to know,
+ during its page traversal, whether or not the canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> has changed; not all
+ clients will use this information, but it is there for those that can make use of it.
+ </li>
+ <li>
+ The <code>Link: <http://www.w3.org/ns/ldp#Page>; rel="type"</code>
+ response header tells the client that this is one <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>, and therefore it
+ needs to examine the other response headers to see if more data existed in the
+ canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> when the response
+ was generated by the server.
+ </li>
+ <li>
+ The <code>Link: <http://example.org/customer-relations?p=2>; rel='next'</code>
+ response header tells the client that at least one more <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> exists,
+ and how to retrieve its representation. The next page link's target URI is
+ defined by the server and is not constrained by this specification.
+ </li>
+ </ul>
+ <p>
+ The following example shows the message exchange for retrieving
+ the next page:
+ </p>
+
+<em>Request</em>
+<div class="example"><div class="example-title"><span>Example 7</span></div><pre class="example">GET /customer-relations?p=2 HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Prefer: return=representation; max-triple-count="500"</pre></div>
+ <p>
+ The server's response is shown below:
+ </p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 8</span></div><pre class="example" id="ldpp-ex-paging-303-resp3">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".</pre></div>
+
+ <p>
+ In this example, there are only two customers provided in the
+ second page.
+ </p>
+ <!-- DONE: show it both ways; if a competing change hit the container, or not.
+ 6.2.2.7's non-normative note covers this case.
+ -->
+ <ul>
+ <li>
+ The <code>Link: <http://www.w3.org/ns/ldp#Page>; rel="type"</code>
+ response header tells the client that this is one <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>, and therefore it
+ needs to examine the other response headers to see if more data existed in the
+ canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> when the response
+ was generated by the server.
+ </li>
+ <li>
+ The absence of a <code>Link: <http://example.org/customer-relations?p=2>; rel='next'</code>
+ response header tells the client that no more <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>s existed in this <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>
+ at the time the response was generated; repeating the request might result in a representation with links to more pages,
+ if other processes are updating the customer relations data.
+ </li>
+ <li>
+ Since the <code>etag="customer-relations-v1"</code> parameter value of the canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>
+ did not change across the client's process of retrieving the entire <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>, it is assured that
+ the merged response representations are equivalent to what it would have received had the server
+ provided the entire representation of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> in a single <code>200 OK</code> response.
+ The client has <em>no assurance</em> that the current state of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> remains unchanged
+ since the final page's representation was generated. For example, after the server constructs the final page representation, another
+ actor could delete <code>client#BettyASmith</code> from the server.
+ </li>
+ </ul>
+
+</section>
+
+<section id="ldpp-ex-paging-2nn" typeof="bibo:Chapter" resource="#ldpp-ex-paging-2nn" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpp-ex-paging-2nn"><span class="secno">4.3 </span>Removing redirection latency when paging</h3>
+
+ <p>
+ It is inconvenient that the <a href="#ldpp-ex-paging-303"><code>303 See Other</code> approach</a>
+ requires three message exchanges to transfer two representations. Fortunately, it is possible to
+ remove the extra message exchange, saving the latency and the server plus network overhead of
+ servicing the <code>303</code> messages.
+ </p>
+ <p>
+ If a client signals that it is capable of understanding the HTTP
+ <a href="#atrisk-2NN">status code <code>2NN Contents of Related</code></a>, then the server can
+ respond with <code>2NN Contents of Related</code> instead of <code>303 See Other</code> on the
+ initial retrieval request, and it can also enclose the representation of the first page in the
+ corresponding response.
+ </p>
+
+<em>Request</em>
+<div class="example"><div class="example-title"><span>Example 9</span></div><pre class="example">GET /customer-relations HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Prefer: return=representation; max-triple-count="500"
+Prefer: contents-of-related</pre></div>
+
+ <p>
+ The server's response is shown below; it includes a
+ <a href="#atrisk-2NN">status code <code>2NN Contents of Related</code></a>,
+ and a representation payload.
+ </p>
+ <p>
+ As was true in the <a href="#ldpp-ex-paging-303"><code>303 See Other</code> approach</a>,
+ the server includes
+ a <code>Location: http://example.org/customer-relations?page1</code> HTTP response header
+ identifying the first page as the resource whose representation is enclosed in the response.
+ </p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 10</span></div><pre class="example" id="ldpp-ex-paging-2nn-resp1">HTTP/1.1 2NN Contents of Related
+Content-Type: text/turtle
+ETag: "_87e52ce291112"
+Location: <http://example.org/customer-relations?page1>
+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".</pre></div>
+
+ <p>
+ From this response, the client knows that it received the representation of an
+ <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> instead of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>,
+ that at least one more page exists, and where to find the next page.
+ The server determines the size of the pages using application-specific methods not defined
+ within this specification, with the client's <code>max-triple-count</code> preference as one
+ input; the simplest method is to make the server's page size equal
+ to the client's preference. In this example, the server chooses a smaller value so
+ there is a second page.
+ </p>
+ <ul>
+ <li>
+ The <code>2NN Contents of Related</code> status code
+ tells the client that the response contains a representation of some resource <em>other than</em>
+ the one identified by its effective request URI.
+ </li>
+ <li>
+ The <code>Location: <http://example.org/customer-relations?page1></code>
+ response header tells the client the identifier of the response representation's resource.
+ In the context of a response with a <code>2NN Contents of Related</code> status code,
+ it tells the client the "related" resource's identifier.
+ </li>
+ <li>
+ The <code>Link: <http://example.org/customer-relations>; rel='canonical'</code>
+ response header tells the client which resource <code><http://example.org/customer-relations?page1></code>
+ is a page of, providing more specificity about the nature of the relationship between the
+ resource identified by the effective
+ request URI and the resource identified in the <code>Location</code> header.
+ The <code>etag="customer-relations-v1"</code> parameter value gives the client a way to know,
+ during its page traversal, whether or not the canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> has changed; not all
+ clients will use this information, but it is there for those that can make use of it.
+ </li>
+ <li>
+ The <code>Link: <http://www.w3.org/ns/ldp#Page>; rel="type"</code>
+ response header tells the client that this is one <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>, and therefore it
+ needs to examine the other response headers to see if more data existed in the
+ canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> when the response
+ was generated by the server.
+ </li>
+ <li>
+ The <code>Link: <http://example.org/customer-relations?p=2>; rel='next'</code>
+ response header tells the client that at least one more <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> exists,
+ and how to retrieve its representation. The next page link's target URI is
+ defined by the server and is not constrained by this specification.
+ </li>
+ </ul>
+ <p>
+ The following example shows the message exchange for retrieving
+ the next page:
+ </p>
+
+<em>Request</em>
+<div class="example"><div class="example-title"><span>Example 11</span></div><pre class="example">GET /customer-relations?p=2 HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Prefer: return=representation; max-triple-count="500"
+Prefer: contents-of-related</pre></div>
+ <p>
+ The server's response is shown below:
+ </p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 12</span></div><pre class="example" id="ldpp-ex-paging-2nn-resp2">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".</pre></div>
+
+ <p>
+ In this example, there are only two customers provided in the
+ second page.
+ </p>
+ <ul>
+ <li>
+ The <code>Link: <http://www.w3.org/ns/ldp#Page>; rel="type"</code>
+ response header tells the client that this is one <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>, and therefore it
+ needs to examine the other response headers to see if more data existed in the
+ canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> when the response
+ was generated by the server.
+ </li>
+ <li>
+ The absence of a <code>Link: <http://example.org/customer-relations?p=2>; rel='next'</code>
+ response header tells the client that no more <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>s existed in this <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>
+ at the time the response was generated; repeating the request might result in a representation with links to more pages,
+ if other processes are updating the customer relations data.
+ </li>
+ <li>
+ Since the <code>etag="customer-relations-v1"</code> parameter value of the canonical <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>
+ did not change across the client's process of retrieving the entire <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>, it is assured that
+ the merged response representations are equivalent to what it would have received had the server
+ provided the entire representation of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> in a single <code>200 OK</code> response.
+ The client has <em>no assurance</em> that the current state of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> remains unchanged
+ since the final page's representation was generated. For example, after the server constructs the final page representation, another
+ actor could delete <code>client#BettyASmith</code> from the server.
+ </li>
+ </ul>
+
+</section>
+
+<section id="ldpp-ex-paging-other-links" typeof="bibo:Chapter" resource="#ldpp-ex-paging-other-links" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpp-ex-paging-other-links"><span class="secno">4.4 </span>Optional paging links</h3>
+
+ <p>
+ The preceding paging examples in this section have all assumed that only <a href="#dfn-forward-traversal" class="internalDFN">forward traversal</a>
+ is supported by the server, to reduce complexity.
+ A server might also support <a href="#dfn-backward-traversal" class="internalDFN">backward traversal</a> through its pages, and/or direct access to the
+ <a title="first page link" href="#dfn-first-page-link" class="internalDFN">first page</a> and/or <a title="last page link" href="#dfn-last-page-link" class="internalDFN">last page</a> from any <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>.
+ Those options would be reflected by adding some combination of the links below,
+ or equivalent semantically equivalent syntactic variations of them, to the response messages.
+ </p>
+
+ <ul>
+ <li>
+ The <a title="first page link" href="#dfn-first-page-link" class="internalDFN">first page</a>'s <a href="#ldpp-ex-paging-2nn-resp1">response message</a> might also have the following links:
+<div class="example"><div class="example-title"><span>Example 13</span></div><pre class="example">Link: <>; rel='first'
+Link: <http://example.org/customer-relations?p=2>; rel='last'</pre></div>
+ </li>
+ <li>
+ Any <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>'s response message, including the <a title="first page link" href="#dfn-first-page-link" class="internalDFN">first page</a> and the <a title="last page link" href="#dfn-last-page-link" class="internalDFN">last page</a>,
+ might also have the following links:
+<div class="example"><div class="example-title"><span>Example 14</span></div><pre class="example">Link: <http://example.org/customer-relations?page1>; rel='first'
+Link: <http://example.org/customer-relations?p=2>; rel='last'</pre></div>
+ </li>
+ <li>
+ The <a title="last page link" href="#dfn-last-page-link" class="internalDFN">last page</a>'s <a href="#ldpp-ex-paging-2nn-resp2">response message</a> might also have the following links:
+<div class="example"><div class="example-title"><span>Example 15</span></div><pre class="example">Link: <http://example.org/customer-relations?page1>; rel='first'
+Link: <http://example.org/customer-relations?page1>; rel='prev'
+Link: <>; rel='last'</pre></div>
+ </li>
+ </ul>
+
+</section>
+
+</section> <!-- Example message exchanges -->
+
+<section id="ldppclient" typeof="bibo:Chapter" resource="#ldppclient" rel="bibo:Chapter">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_ldppclient"><span class="secno">5. </span>Linked Data Platform Paging Clients</h2>
+<p>All of the following are conformance rules for <a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging Clients</a>.
+</p>
+<section id="general-requirements"><h3 aria-level="2" role="heading" id="h3_general-requirements"><span class="secno">5.1 </span>General requirements</h3>
+
+ <section id="ldpp-client-advertise" typeof="bibo:Chapter" resource="#ldpp-client-advertise" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-client-advertise"><span class="secno">5.1.1 </span><a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging clients</a> <em class="rfc2119" title="MUST">MUST</em>
+ <a href="#ldpp-hints">advertise their ability to support LDP Paging</a> on all retrieval requests that normally result in
+ a response containing a representation.
+ </h4>
+ </section>
+
+ <section id="ldpp-client-traversal" typeof="bibo:Chapter" resource="#ldpp-client-traversal" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-client-traversal"><span class="secno">5.1.2 </span><a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging clients</a> <em class="rfc2119" title="MUST">MUST</em>
+ be capable of at least one of <a href="#dfn-forward-traversal" class="internalDFN">forward traversal</a> and/or <a href="#dfn-backward-traversal" class="internalDFN">backward traversal</a>.
+ </h4>
+ </section>
+
+ <section id="ldpp-client-linkschg" typeof="bibo:Chapter" resource="#ldpp-client-linkschg" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-client-linkschg"><span class="secno">5.1.3 </span><a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging clients</a> <em class="rfc2119" title="MUST NOT">MUST NOT</em>
+ assume that any <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource's</a> <a title="paging link" href="#dfn-paging-link" class="internalDFN">paging links</a>
+ will remain unchanged when the <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
+ is retrieved more than once. Such an assumption would
+ conflict with a server's ability to
+ <a href="#ldpr-pagingGET-sequences-change">add pages to a sequence</a> as the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> changes, for example.
+ </h4>
+ </section>
+
+ <section id="ldpp-client-4xxok" typeof="bibo:Chapter" resource="#ldpp-client-4xxok" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-client-4xxok"><span class="secno">5.1.4 </span><a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging clients</a> <em class="rfc2119" title="MUST NOT">MUST NOT</em>
+ assume that any <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource's</a> <a title="paging link" href="#dfn-paging-link" class="internalDFN">paging links</a>
+ will always be accessible.</h4>
+ <blockquote><em>Non-normative note:</em>
+ Such an assumption would
+ conflict with a server's ability to <a href="#ldpr-pagingGET-sequences-change">remove pages from a sequence</a>
+ as the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> changes, for example.
+ One consequence of this is that clients can receive responses with <code>4xx</code> status codes
+ when following page links, purely due to timing issues and without any error on the part of the client
+ or the server. Such a response would be unusual, and would likely signal an error,
+ if the response also indicates that the <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged resource's</a>
+ <a href="#ldpr-notify-changes">state has <i>not</i> changed</a>
+ while the client was traversing its <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">pages</a>.
+ Servers might also limit the lifetime of a particular <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>, and client requests after the server has
+ abandoned that sequence are likely to result in <code>410 Gone</code> or other <code>4xx</code> status codes.
+ </blockquote>
+
+ </section>
+
+ <section id="ldpp-client-paging-incomplete" typeof="bibo:Chapter" resource="#ldpp-client-paging-incomplete" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-client-paging-incomplete"><span class="secno">5.1.5 </span><a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging clients</a>
+ <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> treat a page sequence as equivalent to the <a title="paged resource" href="#dfn-paged-resource" class="internalDFN">paged resource</a>
+ when the <a href="#ldpr-notify-changes">paged resource changed</a>
+ <a href="#ldpr-guarantee-show-unchanged">during retrieval of the page sequence</a>.
+ </h4></section>
+
+ <section id="ldpp-client-nofollow-303" typeof="bibo:Chapter" resource="#ldpp-client-nofollow-303" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-client-nofollow-303"><span class="secno">5.1.6 </span><a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging clients</a>
+ <em class="rfc2119" title="MUST NOT">MUST NOT</em> treat the target of a <code>303 See Other</code> redirection as a replacement for the original resource.
+ That is, they cannot treat a <code>303</code> status code as if it was a
+ <code>307 Temporary Redirect</code> [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>] or <code>308 Permanent Redirect</code> [<cite><a class="bibref" href="#bib-RFC7238">RFC7238</a></cite>],
+ as [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>] makes clear. This is critical to a client's ability to distinguish between the representation
+ of a single <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> and that of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> when a <a href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging server</a>
+ uses <a href="#ldpr-status-code">redirection</a> as a way to initiate paging.
+ </h4></section>
+
+</section>
+
+<section id="ldpp-hints" typeof="bibo:Chapter" resource="#ldpp-hints" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpp-hints"><span class="secno">5.2 </span>Client preferences</h3>
+ <p>
+ LDP Paging clients <a href="#ldpp-client-advertise">must provide paging-related hints</a>
+ in order to influence an LDP Paging server's choices.
+ </p>
+
+ <p>
+ This specification introduces new
+ parameters on the HTTP <code>Prefer</code> request header's
+ <code>return=representation</code> preference [<cite><a class="bibref" href="#bib-RFC7240">RFC7240</a></cite>], <a href="#ldpp-client-advertise">used by clients</a> to
+ supply a preference that helps the server form a response that is most appropriate to
+ the client's needs. The presence of any parameter defined in this section serves several purposes:
+ </p><ul>
+ <li>It signals the client's support for LDP Paging to the request server</li>
+ <li>It communicates the client's maximum desired size for a response representation</li>
+ </ul>
+ <p></p>
+
+ <div class="atrisk" id="atrisk-paging"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the following clause to make LDP clients paging aware:</p>
+ <section id="ldpr-cli-paging" typeof="bibo:Chapter" resource="#ldpr-cli-paging" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-cli-paging">
+ <a title="LDP client" href="#dfn-ldp-client" class="internalDFN">LDP clients</a> <em class="rfc2119" title="SHOULD">SHOULD</em>
+ be capable of processing successful HTTP <code>GET</code> responses formed by a LDP server
+ that independently initiated paging, returning a page of representation instead of full resource
+ representation [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>].
+ </h4>
+ </section>
+ </div>
+
+ <div class="atrisk" id="atrisk-units"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the preference parameters
+ <code>max-member-count</code> and <code>max-kbyte-count</code>, along with
+ corresponding requirements on servers of <a href="#ldpr-units-triple-count">LDPRs</a>
+ and <a href="#atrisk-paging-record-count">LDPCs</a> to support them.
+ </p>
+ </div>
+
+ <p>
+ LDP Paging defines <code>max-triple-count</code>, <code>max-member-count</code>, and <code>max-kbyte-count</code>
+ as new parameters on the existing
+ HTTP <code>Prefer</code> request header's
+ <code>return=representation</code> preference [<cite><a class="bibref" href="#bib-RFC7240">RFC7240</a></cite>]; the presence of any of these parameters
+ on the preference, not the preference alone, is what indicates to a server that the client
+ supports LDP Paging.
+ A client communicates its hint(s) to the server by adding the
+ request header with a
+ <code>return=representation</code> preference that includes any of the following preference parameters
+ </p><table class="indented">
+ <tbody><tr>
+ <td> <code>max-triple-count</code> </td>
+ <td> The maximum decimal number of triples the client wishes to appear on each page. </td>
+ </tr>
+ <tr>
+ <td> <code>max-kbyte-count</code> </td>
+ <td> The maximum decimal number of kilobytes (1024 byte units) the client wishes to receive as the page's representation. </td>
+ </tr>
+ <tr>
+ <td> <code>max-member-count</code> </td>
+ <td> The maximum decimal number of members the client wishes to appear on each page.
+ This parameter is only meaningful for paged containers.
+ </td>
+ </tr>
+ </tbody></table>
+ <blockquote>
+ <p>
+ The generic preference BNF [<cite><a class="bibref" href="#bib-RFC7240">RFC7240</a></cite>] allows either a quoted string or a token as the value of a
+ preference parameter.
+ </p>
+ </blockquote>
+ <p></p>
+
+ <p id="prefer-examples-500-triples">
+ Clients interested in receiving at most 500 RDF triples per <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">page</a>
+ would use add this HTTP header on a <code>GET</code> request, as shown in <a href="#ldpp-ex-paging-303" class="sectionRef sec-ref">section <span class="secno">4.2</span> <span class="sec-title">Simple paging flow using redirects</span></a>:
+ <code>Prefer: return=representation; max-triple-count="500"</code>
+ </p>
+
+</section> <!-- Paging hints -->
+
+</section> <!-- Client constraints -->
+
+<section id="ldpr" typeof="bibo:Chapter" resource="#ldpr" rel="bibo:Chapter">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_ldpr"><span class="secno">6. </span>Linked Data Platform Resources</h2>
+
+<section class="informative" id="ldpr-PagingIntro" typeof="bibo:Chapter" resource="#ldpr-PagingIntro" rel="bibo:Chapter">
+
+<h3 aria-level="2" role="heading" id="h3_ldpr-PagingIntro"><span class="secno">6.1 </span>Paging considerations</h3><p><em>This section is non-normative.</em></p>
+
+ <p>
+ As <a href="#intro">described</a> <a href="#ldpp-ex-mx">previously</a>,
+ paging logically breaks up a <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>
+ into a list of <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resources</a> (pages) whose representations the client can retrieve, and serves each
+ page with links to other <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">pages in the sequence</a>.
+ Clients inspect each response to see if additional pages
+ are available; paging does not affect the choice of HTTP status code.
+ Clients generally have no insight into the allocation of information to pages,
+ although in <a href="#ldpc">some cases currently defined only for LDPCs</a> the server can expose its
+ algorithm.
+ </p>
+ <p>
+ Some clients will be interested in knowing whether or not competing requests altered the
+ <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> while the client was retrieving pages, since LDP paging does not guarantee
+ that those alterations were reflected in any <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> received by the client.
+ Regardless of the server implementation, LDP only guarantees that while traversing a series of pages that
+ the client observes data that is equivalent to a database that uses
+ read committed isolation [<cite><a class="bibref" href="#bib-READ-COMMITTED">READ-COMMITTED</a></cite>];
+ specifically, clients can observe
+ non-repeatable reads [<cite><a class="bibref" href="#bib-NON-REPEATABLE-READS">NON-REPEATABLE-READS</a></cite>] while traversing pages served by
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a>.
+ LDP Paging does <a href="#ldpr-guarantee-show-unchanged">guarantee</a>, however, that any information in the <abbr title="Linked Data Platform Resource">LDPR</abbr> continuously present (neither added nor deleted) in the
+ <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged resource</a> across the entire period of time when the client is retrieving pages will
+ be present in at least one <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>.
+ </p>
+ <p>
+ LDP Paging defines a mechanism by which <a href="#ldpr-notify-changes">clients can detect that the paged resource has been changed</a> so that they can, for example,
+ abandon a page traversal as early as possible.
+ This provides a stronger guarantee in certain cases
+ than the one described for paged feeds [<cite><a class="bibref" href="#bib-RFC5005">RFC5005</a></cite>], but it does require the client
+ to detect when the condition holds.
+ Paging <i>does not guarantee</i> that it will ever be possible to successfully
+ retrieve all the <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>s without the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>
+ being added to or changed, so clients requiring such a guarantee
+ may not find all <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>s usable in practice.
+ A detailed example was provided in <a href="#ldpp-ex-mx" class="sectionRef sec-ref">section <span class="secno">4.</span> <span class="sec-title">Example paging message exchanges</span></a>.
+ See <a href="#ldpr-impl" class="sectionRef sec-ref">section <span class="secno">A.</span> <span class="sec-title">Paging LDPRs without maintaining server-side session state</span></a> for server implementation considerations.
+ </p>
+</section>
+
+<section id="ldpr-PagingGET" typeof="bibo:Chapter" resource="#ldpr-PagingGET" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpr-PagingGET"><span class="secno">6.2 </span>HTTP GET</h3>
+ <p>In addition to the requirements on HTTP <code>GET</code> for LDPRs [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>],
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> must
+ also follow the requirements in this section for all <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged resources</a>
+ and their associated <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resources</a>.
+ </p>
+
+ <section id="ldpr-page-large" typeof="bibo:Chapter" resource="#ldpr-page-large" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-page-large"><span class="secno">6.2.1 </span>
+ <!-- Remove this clause? No, it was MOVED here from LDP, and as a Must we'd need to define 'large' to test compliance. -->
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em> allow clients to retrieve large LDP-RSs in
+ pages.
+ </h4></section><!-- Was 4.2.14 / #ldpr-4_2_14 -->
+
+ <section id="ldpr-split-any-resource" typeof="bibo:Chapter" resource="#ldpr-split-any-resource" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-split-any-resource"><span class="secno">6.2.2 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em>
+ treat any resource (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> or not) as a <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>.
+ </h4></section><!-- Was 4.2.15 / #ldpr-4_2_15 -->
+
+ <section id="ldpr-split-any-time" typeof="bibo:Chapter" resource="#ldpr-split-any-time" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-split-any-time"><span class="secno">6.2.3 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em>
+ vary their treatment of any resource (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> or not) as a <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> over time.
+ In other words, given two attempts to retrieve the same resource at different points
+ in time, the server can choose to return a representation of the first page at one time and
+ of the entire resource at a different time. Clients distinguish between these cases based
+ on the <a href="#ldpr-status-code">status code</a>
+ and <a href="#ldpr-pagingGET-page-type-reqd">response headers</a>.
+ </h4></section>
+
+ <section id="ldpp-prefer" typeof="bibo:Chapter" resource="#ldpp-prefer" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-prefer"><span class="secno">6.2.4 </span><a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a>
+ <em class="rfc2119" title="SHOULD">SHOULD</em> respect all of a client's <a href="#ldpp-hints">LDP Paging defined hints</a>, for example
+ <a href="#ldpp-hints">the largest page size</a>
+ the client is interested in processing,
+ to influence the amount of data returned in representations.</h4>
+ <blockquote>
+ <em>Non-normative note</em>: LDP server implementers should be careful not to interpret a
+ <code>Prefer return=representation</code> request header that <em>lacks</em> any
+ parameters defined here as a client's request for a <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>.
+ <a href="#ldpp-hints">A client's hints</a> indicate LDP Paging support <em>only</em>
+ when at least one of the preference parameters defined by this specification is present.
+ </blockquote>
+ <blockquote>
+ <em>Non-normative note</em>: LDP server implementers should carefully consider the effects of these
+ preferences on caching, as described in section 2 of [<cite><a class="bibref" href="#bib-RFC7240">RFC7240</a></cite>].
+ </blockquote>
+ <blockquote>
+ <em>Non-normative note</em>: [<cite><a class="bibref" href="#bib-RFC7240">RFC7240</a></cite>] recommends that server implementers include a
+ <code>Preference-Applied</code> response header when the client cannot otherwise determine the server's
+ behavior with respect to honoring hints from the response content.
+ </blockquote>
+ </section>
+
+ <section id="ldpp-prefer-unrecognized" typeof="bibo:Chapter" resource="#ldpp-prefer-unrecognized" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpp-prefer-unrecognized"><span class="secno">6.2.5 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em>
+ ignore a <a href="#ldpp-hints">page size hints</a> whose value is zero,
+ and process the request as if no maximum desired size was specified; in the latter case the server
+ can select whatever page size it deems appropriate, or choose not to page the resource at all.
+ </h4></section>
+
+ <div class="atrisk" id="atrisk-2NN"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the features described in the next compliance clause.</p>
+ <ul>
+ <li><p>
+ A <a href="http://lists.w3.org/Archives/Public/www-tag/2013Dec/0041.html">December 2013 TAG discussion</a> started,
+ whose goal is to reduce the need for two request-response round trips down to one when retrieving what
+ turns out to be the first page of a paged resource, by defining a new
+ HTTP response code in the <code>2xx</code> or <code>3xx</code> class that would allow a server to
+ respond to <code>GET request-uri</code> requests with the representation of the first page
+ (whose URI is <code>first-page-uri</code>, not <code>request-uri</code>) of a multi-page response.
+ </p></li>
+ <li><p>
+ For the purposes of drafting this section, we assume that the
+ new code's value is <code>2NN Contents of Related</code>,
+ and its definition is given by the
+ IETF draft [<cite><a class="bibref" href="#bib-2NN">2NN</a></cite>], whose content evolved from
+ <a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0023.html">an LDP extrapolation from TAG discussions</a>,
+ <a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0015.html">Henry Thompson's strawman</a>,
+ with the substitution of 2NN for 2xx as suggested in
+ <a href="https://github.com/w3ctag/spec-reviews/blob/master/2014/04/http-209.md">the TAG's draft comments, item 2</a>.
+ Note: nothing prevents servers or clients from using <code>303 See Other</code> responses to
+ requests for <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged resources</a>. The only significant differences between 303 and 2NN responses
+ are the extra round trip required for the client to retrieve the representation of the first page when using 303,
+ and the non-cacheable nature of 303 responses.
+ </p></li>
+ <li><p>
+ Once LDP-Paging is a
+ Candidate Recommendation, the LDP WG will make an assessment based on the status at IETF,
+ working with the <abbr title="World Wide Web Consortium">W3C</abbr> Director, to either use the newly defined response code 2NN
+ as documented in this section or to revert to a classic
+ <code>303</code> response pattern.
+ </p></li>
+ </ul>
+ </div>
+
+ <section id="ldpr-status-code" typeof="bibo:Chapter" resource="#ldpr-status-code" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-status-code"><span class="secno">6.2.6 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em>
+ initiate paging unless the client has indicated it understands LDP Paging or that it is prepared to
+ process <code>2NN Contents of Related</code> responses [<cite><a class="bibref" href="#bib-2NN">2NN</a></cite>].
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> initiating paging <em class="rfc2119" title="SHOULD">SHOULD</em> respond
+ to successful <code>GET</code> requests with any <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged resource</a>
+ as the <code>Request-URI</code> in one of the following ways:</h4>
+ <ul>
+ <li>
+ If the client supports <code>2NN</code> responses, respond
+ with HTTP status code <code>2NN Contents of Related</code> and the first
+ <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>'s representation.
+ </li>
+ <li>
+ If the client supports paging but not <code>2NN</code> responses,
+ respond with
+ status code <code>303 See Other</code> and a <code>Location</code> response header that identifies
+ the first <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>.
+ The only standard means defined by LDP paging for a client to signal a server that the client
+ understands paging is via the <a href="#ldpp-hints">client preference</a> defined for this purpose;
+ other implementation-specific means could also be used.
+ </li>
+ <li>
+ If the server is willing to provide a non-paged representation, respond
+ with an appropriate status code (likely <code>200 OK</code>) and the potentially large
+ non-paged representation.
+ </li>
+ <li>
+ Either reject the request, most likely with a <code>4xx</code> status code,
+ or (keeping in mind the note below)
+ initiate paging as described above with a <code>303</code> status code, or
+ choose another status code appropriate to the specific situation.
+ </li>
+ </ul>
+
+ <blockquote>
+ <em>Non-normative note:</em>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> could choose to make any resource
+ available <em>only</em> as a paged resource.
+ In so doing, when interacting with clients <em>unaware</em> of LDP Paging,
+ if the server initiates paging anyway then it runs the risk
+ that an ill-behaved client will automatically follow a
+ <code>303 See Other</code> redirect and believe via the subsequent
+ <code>200 OK</code> that it has obtained a complete representation of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>
+ rather than of a single <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>.
+ <a title="LDP Paging client" href="#dfn-ldp-paging-client" class="internalDFN">LDP Paging clients</a> <a href="#ldpp-client-nofollow-303">will not follow redirects in this way</a>,
+ but some existing HTTP clients are known to treat <code>303 See Other</code> redirects as if they were
+ equivalent to the original request-URI, despite this being explicitly disclaimed in [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>].
+ </blockquote>
+ </section>
+
+ <section id="ldpr-guarantee-show-unchanged" typeof="bibo:Chapter" resource="#ldpr-guarantee-show-unchanged" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-guarantee-show-unchanged"><span class="secno">6.2.7 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST">MUST</em>
+ ensure that all state present in the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> throughout a client's <em>entire</em> traversal operation
+ is represented in at least one <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>. In other words, whatever subset of the
+ <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> that is <em>not added, updated, or removed during the client's traversal</em>
+ of its pages has to be present in one of the pages.
+ </h4>
+ <blockquote><em>Non-normative note:</em>
+ As a consequence, if the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> does not change <em>at all</em> during the traversal,
+ then the client has a complete view of its state as given by the negotiated response media type
+ <em>at the point in time when the final page was retrieved</em>.
+ If the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> <em>does</em> change during the traversal, then only the portions that
+ were actually updated will differ; the client has no LDP Paging provided means for knowing in what
+ way(s) its view differs from that of the server in this case.
+ </blockquote>
+ <blockquote><em>Non-normative note:</em>
+ When the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> is an <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>,
+ the expectation is that all triples untouched by changes to the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> have been
+ given to the client during the traversal; it is possible that some subset of the changed triples, including all or none of them,
+ have been provided to the client, but the client has no way to know which.
+ </blockquote>
+ </section>
+
+ <!--
+ <div class="ldp-issue-pending" id="question-link-relation"><p class="ldp-issue-title">Feedback requested on the link relation type used below</p>
+ <p>Background: likely suspects from the <a href="http://www.iana.org/assignments/link-relations/link-relations.xml">IANA link relation registry</a> that the editors examined:</p>
+ <ul>
+ <li><p>
+ <a href="http://tools.ietf.org/html/rfc6596">canonical</a> (see section 3, source has no TOC/anchors) may be
+ close enough; the content at the context URI can explicitly be a subset of that at the target (canoncial) URI.
+ Certain cited functions like link consolidation are completely appropriate; if we believe the authors about its
+ usage by crawlers/indexers however, we may be working at cross purposes.
+ </p></li>
+ <li><p>
+ <a href="http://tools.ietf.org/html/rfc6573">collection</a> has muddy semantics in the case where
+ the paged resource is an LDPC (i.e. the case we care most about, in terms of LDP's use cases). We could
+ probably get away with using collection, but its "inverse" item (defined in the same RFC) would definitely
+ have a <em>different</em> semantic than what we want for paging (the RFC thinks an item is a member of the
+ collection, but a page of an LDPC might have multiple LDP members on it, if we consider inlining in any form).
+ It would have the net effect of looking at the LDPC as a generic RDF source, and "forgetting" within the paging
+ spec that LDPCs have members - something that I'm sure we could all do, but pity the adopters using both
+ together and trying to keep the different collection/item "models" untangled.
+ </p></li>
+ <li><p>
+ <a href="http://tools.ietf.org/html/rfc4287#page-21">enclosure</a> has "good match" semantics,
+ but a name that's awkward for our case.
+ </p></li>
+ <li><p>
+ <a href="http://tools.ietf.org/html/rfc5005">Atom Feed Paging and Archiving</a> has no analog for the logical feed.
+ </p></li>
+ <li><p>
+ We also have the choice of defining-new, either an extension link relation (we just mint our own URI, done)
+ or as a short name (requiring a small-but-not-zero registration template).
+ </p></li>
+ </ul>
+ </div>
+ -->
+
+ <section id="ldpr-notify-changes" typeof="bibo:Chapter" resource="#ldpr-notify-changes" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-notify-changes"><span class="secno">6.2.8 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST">MUST</em>
+ enable a client to detect any change to the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> that occurs while the client is retrieving pages
+ by
+ including a HTTP <code>Link</code> header on all successful
+ HTTP <code>GET</code> responses, and <em class="rfc2119" title="SHOULD">SHOULD</em> include the same header on all <code>4xx</code>
+ status code responses.
+ The link's
+ context URI identifies the <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> being retrieved,
+ target URI identifies the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>,
+ link relation type is <code>canonical</code> [<cite><a class="bibref" href="#bib-REL-CANONICAL">REL-CANONICAL</a></cite>],
+ and
+ link extension parameters include the parameter name <code>etag</code>
+ and a corresponding parameter value identical to the ETag [<cite><a class="bibref" href="#bib-RFC7232">RFC7232</a></cite>]
+ of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>.
+ For example: <code>Link: <http://example.org/customer-relations>; rel='canonical'; etag="customer-relations-v1"</code>
+ </h4>
+ <blockquote><em>Non-normative note:</em>
+ If the <code>rel='canonical'; etag="..."</code> value changes as the client retrieves pages,
+ for example the value accompanying the first page's representation is <code>rel='canonical'; etag="v1"</code>
+ and the value accompanying the second page's representation is <code>rel='canonical'; etag="v2"</code>,
+ the client can detect that the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>'s state has changed.
+ Some clients will ignore such changes, but others may choose to react to them, for example by restarting the traversal.
+ </blockquote>
+ </section>
+
+ <section id="ldpr-pagingGET-sequences-change" typeof="bibo:Chapter" resource="#ldpr-pagingGET-sequences-change" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-sequences-change"><span class="secno">6.2.9 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em>
+ add or remove <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resources</a> to a
+ <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged resource's</a> sequence over time.
+ If the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a> is <a href="#ldpc-HTTP_GET">ordered</a>, then the ordering communicated by the server <em class="rfc2119" title="MUST">MUST</em> be maintained;
+ the server <em class="rfc2119" title="SHOULD">SHOULD</em> only add pages to the end of an unordered sequence.
+ </h4><!-- Was 4.10.2.1 / #ldpr-pagingGET-sequences-change -->
+ <blockquote><em>Non-normative note:</em>
+ Servers might abandon an ordered <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>, resulting in <code>4xx</code> status codes to subsequent requests,
+ although it will be less disruptive to clients if the server either adds content to the appropriate existing page or
+ adds new pages at the proper point in the sequence. Clients have no more efficient means than a conditional retrieval
+ request on existing pages to detect the changed/added pages.
+ </blockquote>
+ <blockquote><em>Non-normative note:</em>
+ As a result, clients retrieving any <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> several times can observe its place in the sequence
+ change as the state of the <a href="#dfn-paged-resource" class="internalDFN">paged resource</a> changes.
+ For example, a nominally last page's server might provide a
+ <a href="#dfn-next-page-link" class="internalDFN">next page link</a> when the page is retrieved again later.
+ Similar situations arise when the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a> crosses server boundaries;
+ server A might host the initial portion of a sequence that links to the last page server A is aware of,
+ hosted on server B, and server B might extend the sequence of pages.
+ A nominally middle page <var>M</var> can become the last (or a non-existent) page if a competing request deletes
+ part of the <a title="Paged resource" href="#dfn-paged-resource" class="internalDFN">paged resource's</a> content after the client retrieves <var>M</var>.
+ </blockquote>
+ </section>
+
+ <section id="ldpr-pagingGET-first-allowed-onpages" typeof="bibo:Chapter" resource="#ldpr-pagingGET-first-allowed-onpages" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-first-allowed-onpages"><span class="secno">6.2.10 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em> provide
+ a <a href="#dfn-first-page-link" class="internalDFN">first page link</a> when responding to
+ requests with any <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> as the <code>Request-URI</code>.
+ </h4></section><!-- Was 4.10.2.1.1 / #ldpr-pagingGET-sequences-change -->
+
+ <section id="ldpr-pagingGET-last-allowed-onpages" typeof="bibo:Chapter" resource="#ldpr-pagingGET-last-allowed-onpages" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-last-allowed-onpages"><span class="secno">6.2.11 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em>
+ provide a <a href="#dfn-last-page-link" class="internalDFN">last page link</a>
+ in responses to <code>GET</code> requests with any <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> as the <code>Request-URI</code>.
+ </h4></section><!-- Was 4.10.2.1.3 / #ldpr-pagingGET-last-allowed-onpages -->
+
+ <section id="ldpr-pagingGET-next-reqd" typeof="bibo:Chapter" resource="#ldpr-pagingGET-next-reqd" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-next-reqd"><span class="secno">6.2.12 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST">MUST</em>
+ provide a <a href="#dfn-next-page-link" class="internalDFN">next page link</a>
+ in responses to <code>GET</code> requests with any <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
+ <em>other than the final page</em>
+ as the <code>Request-URI</code>.
+ This is the mechanism by which clients can discover the URL of the next page.
+ </h4><!-- Was 4.10.2.2 / #ldpr-pagingGET-next-reqd-change -->
+ </section>
+
+ <section id="ldpr-pagingGET-lastnext-prohibited" typeof="bibo:Chapter" resource="#ldpr-pagingGET-lastnext-prohibited" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-lastnext-prohibited"><span class="secno">6.2.13 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST NOT">MUST NOT</em>
+ provide a <a href="#dfn-next-page-link" class="internalDFN">next page link</a>
+ in responses to <code>GET</code> requests with the final <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
+ as the <code>Request-URI</code>.
+ This is the mechanism by which clients can discover the end of the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>
+ as currently known by the server.
+ </h4></section><!-- Was 4.10.2.2.1 / #ldpr-pagingGET-lastnext-prohibited -->
+
+ <section id="ldpr-pagingGET-prev-allowed" typeof="bibo:Chapter" resource="#ldpr-pagingGET-prev-allowed" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-prev-allowed"><span class="secno">6.2.14 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em>
+ provide a <a href="#dfn-previous-page-link" class="internalDFN">previous page link</a>
+ in responses to <code>GET</code> requests with any <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
+ <em>other than the first page</em>
+ as the <code>Request-URI</code>.
+ This is one mechanism by which clients can discover the URL of the previous page.
+ </h4></section><!-- Was 4.10.2.2.2 / #ldpr-pagingGET-prev-allowed -->
+
+ <section id="ldpr-pagingGET-firstprev-prohibited" typeof="bibo:Chapter" resource="#ldpr-pagingGET-firstprev-prohibited" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-firstprev-prohibited"><span class="secno">6.2.15 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST NOT">MUST NOT</em>
+ provide a <a href="#dfn-previous-page-link" class="internalDFN">previous page link</a>
+ in responses to <code>GET</code> requests with the <em>first</em> <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
+ as the <code>Request-URI</code>.
+ This is one mechanism by which clients can discover the beginning of the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>
+ as currently known by the server.
+ </h4></section><!-- Was 4.10.2.2.3 / #ldpr-pagingGET-firstprev-prohibited -->
+
+ <section id="ldpr-pagingGET-page-type-reqd" typeof="bibo:Chapter" resource="#ldpr-pagingGET-page-type-reqd" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-page-type-reqd"><span class="secno">6.2.16 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST">MUST</em>
+ provide an HTTP <code>Link</code>
+ header whose target URI is <code>http://www.w3.org/ns/ldp#Page</code>, and whose link relation type is <code>type</code> [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>]
+ in responses to <code>GET</code> requests with any <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>
+ as the <code>Request-URI</code>.
+ This is one mechanism by which clients know that the resource is one of a sequence of pages.
+ </h4></section><!-- Was 4.10.2.4 / #ldpr-pagingGET-page-type-reqd -->
+
+ <section id="ldpr-pagingGET-abandon-pageseq" typeof="bibo:Chapter" resource="#ldpr-pagingGET-abandon-pageseq" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagingGET-abandon-pageseq"><span class="secno">6.2.17 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em>
+ indicate that they have abandoned a
+ sequence by responding with at <code>410 Gone</code> to HTTP requests to any of the
+ <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resources</a> with appropriate
+ paging link response headers, for example, rel='first'.
+ </h4></section><!-- #ldpr-pagingGET-abandon-pageseq -->
+
+ <!--
+ <div class="atrisk" id="atrisk-paging-triple-count"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the following clause:</p>
+ -->
+ <section id="ldpr-units-triple-count" typeof="bibo:Chapter" resource="#ldpr-units-triple-count" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-units-triple-count"><span class="secno">6.2.18 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em>
+ support the <code>max-triple-count</code> <a href="#ldpp-hints">client preference parameter</a>,
+ which expresses a page size limiting the number of RDF triples represented on a page.
+ For example, <code>max-triple-count="500"</code> expresses a limit of 500 RDF triples per page.
+ </h4>
+ </section>
+ <!--
+ </div>
+ -->
+
+ <div class="atrisk" id="atrisk-paging-kbyte-count"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the following clause:</p>
+ <section id="ldpr-units-kbyte-count" typeof="bibo:Chapter" resource="#ldpr-units-kbyte-count" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-units-kbyte-count">
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em>
+ support the <code>max-kbyte-count</code> <a href="#ldpp-hints">client preference parameter</a>,
+ which expresses a page size limit as kilobytes of representation size.
+ For example, <code>max-kbyte-count="1"</code> expresses a limit of 1024 bytes per page.
+ </h4>
+ </section>
+ </div>
+
+ <div class="atrisk" id="atrisk-paging-multiple-units"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the following clause:</p>
+ <section id="ldpr-pagesize-multiple-units" typeof="bibo:Chapter" resource="#ldpr-pagesize-multiple-units" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-pagesize-multiple-units">
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST">MUST</em>, if provided with multiple
+ <a href="#ldpp-hints">client preference parameters</a> limiting page size,
+ honor all hints that it recognizes. This has the net effect that the most restrictive
+ hint for any given response governs the resulting page size.
+ For example, <code>max-kbyte-count="1"</code> and <code>max-triple-count="500"</code>
+ usually would result in pages whose size hits the 1 kilobyte limit first, since each triple very likely
+ requires more than two bytes (500 triples/1024 bytes).
+ </h4>
+ </section>
+ </div>
+
+ <!-- combined into ldpr-status-code
+ <section id="ldpr-pagingGET-only-paging-clients"><h2 class="normal">
+ <a title="LDP Paging server">LDP Paging servers</a> SHOULD NOT
+ initiate paging unless the client has indicated it understands LDP Paging or that it is prepared to
+ process <code>2NN Contents of Related</code> responses [[!2NN]].
+ If the client supports paging but not <code>2NN</code> responses, a server initiating paging SHOULD respond with
+ status code <code>303 See Other</code> and a <code>Location</code> response header that identifies
+ the URI of the first <a>in-sequence page resource</a> of the <a>paged resource</a>.
+ The only standard means defined by LDP paging for a client to signal a server that the client
+ understands paging is via the <a href="#ldpp-hints">client preference</a> defined for this purpose;
+ other implementation-specific means could also be used.</h2>
+ <blockquote>
+ <em>Non-normative note:</em>
+ <a title="LDP Paging server">LDP Paging servers</a> could choose to make any resource
+ available <em>only</em> as a paged resource.
+ In so doing, when interacting with clients <em>unaware</em> of LDP Paging,
+ if the server initiates paging anyway then it runs the risk
+ that an ill-behaved client will automatically follow a
+ <code>303 See Other</code> redirect and believe via the subsequent
+ <code>200 OK</code> that it has obtained a complete representation of the <a>paged resource</a>
+ rather than of what may be a single <a>in-sequence page resource</a>.
+ The alternative is for the server to reject the request, most likely
+ with a <code>4xx</code> status code.
+ <a title="LDP Paging client">LDP Paging clients</a> <a href="#ldpp-client-nofollow-303">will not follow redirects in this way</a>,
+ but some existing HTTP clients are known to treat <code>303 See Other</code> redirects as if they were
+ equivalent to the original request-URI, despite this being explicitly disclaimed in [[RFC7231]].
+ </blockquote>
+ </section>
+ -->
+
+</section>
+
+</section> <!-- h1 -->
+
+<section id="ldpc" typeof="bibo:Chapter" resource="#ldpc" rel="bibo:Chapter">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_ldpc"><span class="secno">7. </span>Linked Data Platform Containers</h2>
+
+<section id="ldpc-general" typeof="bibo:Chapter" resource="#ldpc-general" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpc-general"><span class="secno">7.1 </span>Requirements when paging LDP Containers</h3>
+
+ <section id="ldpc-onsamepage" typeof="bibo:Chapter" resource="#ldpc-onsamepage" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-onsamepage"><span class="secno">7.1.1 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MUST">MUST</em>
+ ensure that the <a title="membership triples" href="#dfn-membership-triples" class="internalDFN">membership triple</a> and
+ <a title="containment triples" href="#dfn-containment-triples" class="internalDFN">containment triple</a> for each member are part of the
+ same <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a>, whenever both triples are present in the <a href="#dfn-page-sequence" class="internalDFN">page sequence</a>
+ for a <a title="paged resource" href="#dfn-paged-resource" class="internalDFN">paged <abbr title="Linked Data Platform Container">LDPC</abbr></a>.
+ </h4></section>
+
+ <div class="atrisk" id="atrisk-paging-record-count"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the following clause:</p>
+ <section id="ldpr-units-record-count" typeof="bibo:Chapter" resource="#ldpr-units-record-count" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpr-units-record-count">
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em>
+ support the <code>max-member-count</code> <a href="#ldpp-hints">client preference parameter</a>,
+ which expresses a page size limiting the number of members returned on each page of a <a title="paged resource" href="#dfn-paged-resource" class="internalDFN">paged <abbr title="Linked Data Platform Container">LDPC</abbr></a>.
+ For example, <code>max-member-count="10"</code> expresses a limit of 10 members per page.
+ </h4>
+ </section>
+ </div>
+
+</section>
+
+<section class="informative" id="ldpc-informative" typeof="bibo:Chapter" resource="#ldpc-informative" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpc-informative"><span class="secno">7.2 </span>Ordering of container members across pages</h3><p><em>This section is non-normative.</em></p>
+
+ <section id="ldpc-ordering" typeof="bibo:Chapter" resource="#ldpc-ordering" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-ordering"><span class="secno">7.2.1 </span>Ordering</h4>
+ <p>
+ There are many cases where an ordering of the members of a
+ container is important. [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>] does not provide any particular support
+ for server ordering of members in containers, because any client can
+ order the members in any way it chooses based on the value of any
+ available property of the members. In the example below, the value of
+ the <code>o:marketValue</code> predicate is present for each
+ member, so the client can easily order the members according to the
+ value of that property.
+ </p>
+ <p>
+ Order becomes more important when containers are
+ paginated. If the server respects ordering when constructing
+ pages, clients needing a globally sorted set of members
+ can reduce the effort required to merge pages.
+ In cases where ordering is important, an <a href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging server</a> ensures that all the
+ members on any single page have the proper sort order with relation to all
+ members on any next and previous pages.
+ <em>This says nothing about the ordering of members <strong>within</strong> any
+ <a title="In-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">single page</a>.</em>
+ When the sort is ascending, all the members on a current page have a
+ sort order no lower than all members on the previous page and
+ sort order no higher than all the members on the next page;
+ that is, it proceeds from low to high, but keep in mind that several
+ consecutive pages might have members whose sort criteria are equal.
+ When the sort is descending, the opposite order is used.
+ Since more than one value may be used to sort members,
+ the <abbr title="Linked Data Platform Container">LDPC</abbr> specification allows servers to assert the ordered list
+ of sort criteria used to sort the members, using the
+ <code>ldp:pageSequence</code> HTTP link relation and its
+ <code>ldp:pageSortCriteria</code> predicate.
+ Each member of the ordered list exposes one <code>ldp:pageSortCriterion</code>,
+ consisting of a <code>ldp:pageSortOrder</code>,
+ <code>ldp:pageSortPredicate</code>, and
+ optionally a <code>ldp:pageSortCollation</code>.
+ </p>
+ <p>
+ Here is an example asset container described in [<cite><a class="bibref" href="#bib-LDP">LDP</a></cite>] section 5.1:
+ </p>
+
+<em>Request</em>
+<div class="example"><div class="example-title"><span>Example 16</span></div><pre class="example">GET /netWorth/nw1/assetContainer/ HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Prefer: return=representation; max-triple-count="500"</pre></div>
+ <p>
+ The server might respond with status code <code>200 OK</code>,
+ and the following representation:
+ </p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 17</span></div><pre class="example" id="ldpc-ex-ordering-nopaging">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 is here only so it's easier to paste into validators for checking -->
+# @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 .</pre></div>
+ <p>
+ The client knows that LDP Paging was not used to form the response, because the HTTP status code is <code>200 OK</code>;
+ the absence of a <code>Link: <http://www.w3.org/ns/ldp#Page>; rel="type"</code> response header provides redundant
+ confirmation of this.
+ Since paging was not used, the server provides no information related to page sorting;
+ providing page sorting information would have no value to the client, it would only waste resources.
+ </p>
+
+ <p>
+ Had the server responded instead with a redirect to a first page <code>http://example.org/netWorth/nw1/assetContainer/?p=1</code>,
+ whose representation was (after following the redirect):
+ </p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 18</span></div><pre class="example" id="ldpc-ex-ordering-page1">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 is required here because the page URI != container URI; any use for paste into validators for checking is free bonus -->
+@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#>.
+<!-- (#Sort-o.marketValue-Ascending) does not work, because the subject uri would be a blank node -->
+<> ldp:pageSortCriteria ( <#Sort-o.marketValue-Ascending> ).
+
+<#Sort-o.marketValue-Ascending>
+ a ldp:pageSortCriterion;
+ ldp:pageSortOrder ldp:Ascending;
+ ldp:pageSortPredicate o:marketValue.</pre></div>
+
+ <p>
+ In this case the server does provide information on the assignment of members to pages.
+ </p>
+ <ul>
+ <li>
+ A <code>Link rel='http://www.w3.org/ns/ldp#pageSequence'</code> response header has been
+ added, allowing the client to where to find information about the page sequence;
+ its content includes a <code>ldp:pageSortCriteria</code> triple,
+ allowing the client to know what sort criteria the server used when allocating members
+ to pages.
+ </li>
+ <li>
+ The server also chose to include assertions about the sort criteria in the content for the
+ first page, namely the triples occurring after the second <code>@base</code> directive.
+ This is an optional exemplary optimization, and the client must decide for itself using means outside of
+ LDP and HTTP whether or not to trust those assertions.
+ If the client trusts those assertions, it need not retrieve them; retrieving them would in this case
+ result in another <code>HTTP GET</code> request. For the purposes of this example, assume that
+ the assertions match what the client would obtain by retrieving them itself.
+ </li>
+ <li>
+ The contents of the sort criteria resource
+ asserts that the <code>o:marketValue</code> predicate will be used
+ to assign sets of members to pages in ascending order.
+ The server is telling the client that the values of <code>o:marketValue</code> of all assets
+ on the first page are no lower than the values on subsequent pages.
+ Since only one such value happens to fall on the first page, this is trivially satisfied.
+ </li>
+ </ul>
+
+ <p>
+ When the client retrieves the second page by following the <code>rel='next'</code> link,
+ its representation might be:
+ </p>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 19</span></div><pre class="example" id="ldpc-ex-ordering-page2">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 is required here because the page URI != container URI; any use for paste into validators for checking is free bonus -->
+@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 .</pre></div>
+
+ <ul>
+ <li>
+ The same <code>Link rel='http://www.w3.org/ns/ldp#pageSequence'</code> response header is present,
+ allowing the client to know what page sequence, and hence what sort criteria, the server used.
+ </li>
+ <li>
+ The server chose not to include assertions about the sort criteria in the content for the
+ second page. Since LDP Paging <a href="#ldpc-sort-consistent">requires that the page sequence is sorted consistently</a>,
+ any client that already retrieved the first page has already seen the sorting criteria. If a client is given
+ the URI of an <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> through means other than following links, it always has the option
+ to retrieve the sort criteria.
+ </li>
+ <li>
+ As the example shows, the values of <code>o:marketValue</code> all assets
+ on the second page are greater than or equal to the values on earlier pages.
+ <em>The values within this page are not ordered according to the
+ sort criterion</em>, illustrating that this criterion applies only to the
+ sorting of "assigning members to pages", not
+ to the ordering within any single page's representation.
+ Typically those representations have not guarantee of ordering and are generated by libraries,
+ whose serializers do not provide a way to control how the order is conveyed.
+ </li>
+ </ul>
+ <p>
+ It is up to the domain model
+ and server to determine the appropriate predicate to indicate the
+ resource’s order within a page (or globally), and up to the client receiving this
+ representation to use that order in whatever way is appropriate to meet its needs, for
+ example to sort the data prior to presentation on a user interface. Also,
+ as it is possible for a container to have as its members other containers,
+ the ordering approach doesn't change as containers themselves are LDPRs and the
+ properties from the domain model can be leveraged for the sort criteria.
+ </p>
+ </section><!-- Was 5.1.2 / #ldpc-ordering -->
+</section> <!-- containers . intro -->
+
+<section id="ldpc-HTTP_GET" typeof="bibo:Chapter" resource="#ldpc-HTTP_GET" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpc-HTTP_GET"><span class="secno">7.3 </span>HTTP GET requirements for member ordering across pages</h3>
+
+ <p>
+ If a <a href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging server</a> chooses to use LDP Paging-defined mechanisms to
+ tell clients the order it uses to assign <abbr title="Linked Data Platform Container">LDPC</abbr> members to pages,
+ which is optional, then it does so as described in this section.
+ LDP Paging does not specify ordering for <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">pages</a> in other cases.
+ See <a href="#ldpc-ordering" class="sectionRef sec-ref">section <span class="secno">7.2.1</span> <span class="sec-title">Ordering</span></a> for
+ exemplary message exchanges.
+ </p>
+
+ <section id="ldpc-sort-criteria-consistent" typeof="bibo:Chapter" resource="#ldpc-sort-criteria-consistent" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-sort-criteria-consistent"><span class="secno">7.3.1 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <em class="rfc2119" title="MAY">MAY</em>
+ communicate the order used to allocate <abbr title="Linked Data Platform Container">LDPC</abbr> members to <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">pages</a>.
+ If they choose to communicate the order, they <em class="rfc2119" title="MUST">MUST</em> respond
+ consistently to retrieval requests for each <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">page</a> in the same sequence.
+ That is, they must communicate the same criteria (or absence of it) for all pages in the same sequence; if
+ the criteria were allowed to vary, the ordering among members of a container
+ across <a title="in-sequence page resource" href="#dfn-in-sequence-page-resource" class="internalDFN">pages</a> would be undefined.
+ </h4></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
+
+ <blockquote>
+ <em>Non-normative note:</em> A server can offer different sequences for the same <a href="#dfn-paged-resource" class="internalDFN">paged resource</a>,
+ for example, sequences that have differing sort criteria, and they can be offered serially or concurrently.
+ </blockquote>
+
+ <section id="ldpc-sort-criteria-link" typeof="bibo:Chapter" resource="#ldpc-sort-criteria-link" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-sort-criteria-link"><span class="secno">7.3.2 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em class="rfc2119" title="MUST">MUST</em>
+ specify the order using a <code>HTTP Link</code> header
+ whose context URI is the page URI,
+ whose link relation is <code>http://www.w3.org/ns/ldp#pageSequence</code>,
+ and whose target IRI identifies a <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> whose content includes the
+ sort criteria.
+ The resource identified by the <code>Link</code> header's target IRI <em class="rfc2119" title="MUST">MUST</em> contain a triple
+ whose subject is the <code>Link</code> header's target IRI,
+ whose predicate is <code>ldp:pageSortCriteria</code>
+ and whose object is a
+ page sort criteria resource compliant with this section's requirements on its content.
+ </h4></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
+
+ <section id="ldpc-sort-criteria-content" typeof="bibo:Chapter" resource="#ldpc-sort-criteria-content" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-sort-criteria-content"><span class="secno">7.3.3 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em class="rfc2119" title="MUST">MUST</em>
+ expose page sort criteria resources that describe the allocation of members to pages; each resource consists of a <code>rdf:List</code> of
+ <code>ldp:pageSortCriterion</code> resources.
+ The first list entry provides the primary
+ sorting criterion, any second entry provides a secondary criterion used to order members considered
+ equal according to the primary criterion, and so on.
+ The resulting page sort order <em class="rfc2119" title="MUST">MUST</em> be as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause
+ [<cite><a class="bibref" href="#bib-sparql11-query">sparql11-query</a></cite>].
+ </h4></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
+
+ <section id="ldpc-sortliteraltype" typeof="bibo:Chapter" resource="#ldpc-sortliteraltype" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-sortliteraltype"><span class="secno">7.3.4 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em class="rfc2119" title="MUST">MUST</em>
+ expose page sort criteria resources that contain,
+ in every <code>ldp:pageSortCriterion</code> list entry,
+ a triple
+ whose subject is the sort criterion identifier,
+ whose predicate is <code>ldp:pageSortPredicate</code>
+ and whose object is
+ the predicate whose value is used to order members between pages (the <dfn id="dfn-page-ordering-values">page-ordering values</dfn>).
+ The only literal data types whose behavior LDP constrains are those defined
+ by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause [<cite><a class="bibref" href="#bib-sparql11-query">sparql11-query</a></cite>]. Other data types
+ can be used, but LDP
+ assigns no meaning to them and interoperability will be limited.
+ </h4></section><!-- Was 5.3.3 / #ldpc-5_3_3 -->
+
+ <section id="ldpc-sortorder" typeof="bibo:Chapter" resource="#ldpc-sortorder" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-sortorder"><span class="secno">7.3.5 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em class="rfc2119" title="MUST">MUST</em>
+ expose page sort criteria resources that contain,
+ in every <code>ldp:pageSortCriterion</code> list entry,
+ a triple
+ whose subject is the sort criterion identifier,
+ whose predicate is <code>ldp:pageSortOrder</code>
+ and whose object describes the order used.</h4>
+ <blockquote>
+ <p>
+ LDP defines two values,
+ <code>ldp:Ascending</code> and <code>ldp:Descending</code>, for use
+ as the object of this triple. Other values can be used, but LDP
+ assigns no meaning to them and interoperability will be limited.
+ </p>
+ </blockquote>
+ </section><!-- Was 5.3.4 / #ldpc-5_3_4 -->
+
+ <section id="ldpc-sortcollation" typeof="bibo:Chapter" resource="#ldpc-sortcollation" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-sortcollation"><span class="secno">7.3.6 </span>
+ <a title="LDP Paging server" href="#dfn-ldp-paging-server" class="internalDFN">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em class="rfc2119" title="MAY">MAY</em>
+ expose page sort criteria resources that contain,
+ in any <code>ldp:pageSortCriterion</code> list entry,
+ a triple
+ whose subject is the sort criterion identifier,
+ whose predicate is <code>ldp:pageSortCollation</code>
+ and whose object identifies the collation used.
+ The <code>ldp:pageSortCollation</code> triple <em class="rfc2119" title="MUST">MUST</em> be omitted for comparisons
+ involving <a title="page-ordering values" href="#dfn-page-ordering-values" class="internalDFN">page-ordering values</a> for which [<cite><a class="bibref" href="#bib-sparql11-query">sparql11-query</a></cite>] does not use collations.</h4>
+ <blockquote>
+ <p>
+ LDP defines no values for use
+ as the object of this triple. While it is better for interoperability to use
+ open standardized values, any value can be used.
+ </p>
+ <p>
+ When the <code>ldp:pageSortCollation</code> triple is absent and the
+ <a title="page-ordering values" href="#dfn-page-ordering-values" class="internalDFN">page-ordering values</a> are strings or simple literals [<cite><a class="bibref" href="#bib-sparql11-query">sparql11-query</a></cite>], the
+ resulting order is as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause
+ [<cite><a class="bibref" href="#bib-sparql11-query">sparql11-query</a></cite>] using two-argument <code>fn:compare</code>, that is,
+ it behaves as if <code>http://www.w3.org/2005/xpath-functions/collation/codepoint</code>
+ was the specified collation.
+ </p>
+ <p>
+ When the <code>ldp:pageSortCollation</code> triple is present and the
+ <a title="page-ordering values" href="#dfn-page-ordering-values" class="internalDFN">page-ordering values</a> are strings or simple literals
+ [<cite><a class="bibref" href="#bib-sparql11-query">sparql11-query</a></cite>], the
+ resulting order is as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause
+ [<cite><a class="bibref" href="#bib-sparql11-query">sparql11-query</a></cite>] using three-argument <code>fn:compare</code>, that is, the
+ specified collation.
+ </p>
+ </blockquote>
+ </section><!-- Was 5.3.5 / #ldpc-5_3_5 -->
+
+</section> <!-- h2 -->
+
+</section> <!-- h1 LDPC -->
+
+<!-- Removed for action-113
+<section>
+<h1>HTTP Status Code Definitions</h1>
+
+<section id="status-code-related-content">
+<h2>209 Related Content</h2>
+
+ <div class="atrisk"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the features described in this section.</p>
+ <ul>
+ <li>The addition of <a>209 Related Content</a> in this specification is pending
+ advancement of an <a href="https://datatracker.ietf.org/doc/draft-wilde-related-content/">IETF draft</a>
+ that would fully include it, patterned after the codes defined by [[RFC6585]]. Once LDP is in
+ Candidate Recommendation status, the LDP WG will make an assessment based on the status at IETF
+ working with the W3C Director.</li>
+ </ul>
+ </div>
+
+ <p>The <code>209 Related Content</code> status code indicates that the origin server
+ is supplying the representation of a different resource than the target resource,
+ and the origin server believes that the supplied representation
+ is likely to satisfy the user agent's original request.
+ The resource whose representation is supplied is descriptive of the target resource, in
+ the same way that the <code>Location</code> header in a <code>303 See Other</code>
+ response is descriptive of the target resource.
+ </p>
+ <p><code>209 Related Content</code> is intended to be used in situations where
+ <code>303 See Other</code> could have been used and would most likely result in a
+ user agent retrieving the other resource, but saves the user agent from
+ the latency penalty of having to perform a separate retrieval request.
+ </p>
+
+ <p> LDP uses <code>209 Related Content</code> to provide clients with the
+ <a href="#ldpr">first page of a large resource</a>, but it can also be used in
+ other common situations. Linked Data clients could benefit by avoiding the latency
+ of additional requests when the target resource is a concept resource (one without any
+ representation capable of transmission over HTTP), and general HTTP clients would
+ benefit in many of the more general cases where <code>303 See Other</code> responses
+ are currently used.
+ </p>
+
+ <div id="status-code-related-content-1" class="rule">7.1.1 A <code>209</code> response to a
+ <code>GET</code> request MUST contain a <code>Location</code> header with the same
+ <code>Location</code> field value as a <code>303 See Other</code> response would use [[!HTTP11]].
+ </div>
+
+ <div id="status-code-related-content-2" class="rule">7.1.2 A <code>209</code> response to a
+ <code>GET</code> request MUST contain a representation of the resource identified
+ by the response's <code>Location</code> header.
+ </div>
+
+ <div id="status-code-related-content-iana" class="rule">7.1.3 IANA Considerations</div>
+ <div>
+ <blockquote>
+ <p>
+ The <code>209 Related Content</code> must be added to the permanent status code registry
+ maintained at <a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>
+ (see [[RFC7231]], [[!RFC2817]]).
+ </p>
+ <p>
+ Value: 209
+ </p>
+ <p>
+ Description: Related Content
+ </p>
+ <p>
+ Reference: this specification
+ </p>
+ </blockquote>
+ </div>
+
+</section>
+</section> -->
+
+
+<section class="informative" id="security" typeof="bibo:Chapter" resource="#security" rel="bibo:Chapter">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_security"><span class="secno">8. </span>Security Considerations</h2><p><em>This section is non-normative.</em></p>
+As with any protocol that is implemented leveraging HTTP, implementations should take advantage of the many
+security-related facilities associated with it and are not required to carry out LDP operations
+that may be in contradistinction to a particular security policy in place. For example, when faced with an
+unauthenticated request to replace system critical RDF statements in a graph through the PUT method, applications may
+consider responding with the 401 status code (Unauthorized), indicating that the appropriate authorization
+is required. In cases where authentication is provided fails to meet the requirements of a particular access control
+policy, the 403 status code (Forbidden) can be sent back to the client to indicate this failure to meet the
+access control policy.
+</section>
+
+<section class="appendix informative" id="ldpr-impl" typeof="bibo:Chapter" resource="#ldpr-impl" rel="bibo:Chapter">
+
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_ldpr-impl"><span class="secno">A. </span>Paging LDPRs without maintaining server-side session state</h2><p><em>This section is non-normative.</em></p>
+ <p>
+ Server implementers naturally have concerns when they are expected to maintain per-client state
+ because of the scalability limitations that per-client state implies.
+ LDP Paging carries no such requirement, although this may not be obvious at first glance.
+ Since URLs are opaque to clients [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>], a server
+ is free to encode the information required for it to know where to start the next page inside
+ its next page links, for example.
+ </p>
+ <p>
+ Observe that in the <a href="#ldpp-ex-mx" class="sectionRef">preceding examples</a>,
+ the <var>page n</var> URIs are all of the form
+ <code>http://example.org/customer-relations?p=<var>n</var></code>,
+ where <var>n</var> is <var>2..n</var>. This is likely true in general practice.
+ If the server allocates <code>o:client</code> representations to pages randomly, it's not obvious how to avoid
+ keeping per-client state of one kind or another on the server while still sending all the representations on
+ at least one page. In the common case where the list has an
+ ordering (either a natural one or one imposed by the implementation) however, it is easy to avoid
+ keeping per-client state on the server.
+ </p>
+ <p>
+ One trivial case is "fixed order"; if the server always sends
+ <code>o:client</code> representations in the order
+ <code>#JohnZSmith, #BettyASmith, #JoanRSmith, #GlenWSmith, #AlfredESmith</code> (or indeed,
+ in <i>any</i> predictable order), then it can put the "last seen" identifier in the <a href="#dfn-next-page-link" class="internalDFN">next page link</a>
+ of each <a href="#dfn-in-sequence-page-resource" class="internalDFN">in-sequence page resource</a> as it is retrieved <em>by each client</em>. The "session state"
+ is, in effect, kept by the client.
+ In this case, the <a href="#dfn-next-page-link" class="internalDFN">next page link</a> in the first page might be:
+ </p>
+ <div class="example"><div class="example-title"><span>Example 20</span></div><pre class="example" id="paging-no-session-state1">Link: <http://example.org/customer-relations?resumeafter=JoanRSmith>; rel='next'</pre></div>
+ <p>
+ If the server also supports <a href="#dfn-backward-traversal" class="internalDFN">backward traversal</a>, then the second page's
+ <a href="#dfn-previous-page-link" class="internalDFN">previous page link</a> might be:
+ </p>
+ <div class="example"><div class="example-title"><span>Example 21</span></div><pre class="example" id="paging-no-session-state2">Link: <http://example.org/customer-relations?resumebefore=GlenWSmith>; rel='next'</pre></div>
+ <p>
+ Keep in mind that this is an exemplary server implementation decision; it is not prescribed by
+ LDP Paging, and other choices are certainly possible. As long as the URIs used in links
+ are opaque to clients, any choice within the constraints of all normative references is permissible.
+ </p>
+</section>
+
+
+<section class="appendix informative" id="acks" typeof="bibo:Chapter" resource="#acks" rel="bibo:Chapter">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_acks"><span class="secno">B. </span>Acknowledgements</h2><p><em>This section is non-normative.</em></p>
+
+ <p>The following people have been instrumental in providing thoughts, feedback,
+reviews, content, criticism and input in the creation of this specification:</p>
+
+ <p style="margin-left: 3em;">
+ Alexandre Bertails, Andrei Sambra, Andy Seaborne, Antonis Loizou, Arnaud Le Hors, 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 Gutiérrez, Nandana Mihindukulasooriya, Olivier Berger, Pierre-Antoine Champin, Raúl García 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
+ </p>
+
+</section>
+
+<section class="appendix informative" id="history" typeof="bibo:Chapter" resource="#history" rel="bibo:Chapter">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_history"><span class="secno">C. </span>Change History</h2><p><em>This section is non-normative.</em></p>
+<p>The change history is up to the editors to insert a brief summary of
+changes, ordered by most recent changes first and with heading from which
+public draft it has been changed from.
+</p>
+<em>Summary</em>
+<ul>
+ <li>Split paging out from core LDP 1.0 specification into this document</li>
+ <li>Updated detection of paged resources based on link relations</li>
+ <li>Added rule to keep containment and membership triples for same resource on same page</li>
+ <li>Use of link header to location sort criteria</li>
+ <li>Added additional ways to request paging based kilobyte and membership count</li>
+</ul>
+
+<!-- <p>The change history is up to the editors to insert a brief summary of
+changes, ordered by most recent changes first and with heading from which
+public draft it has been changed from.
+</p> -->
+
+<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
+<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140730/">Last Call Draft</a></em></blockquote> -->
+<!-- <ul>
+ <li>2014-08-25 - max-triple-count, max-member-count, max-kbyte-count support must > should per Aug 25 mtg (JA) </li>
+ <li>2014-08-25 - Clarify example (JA) </li>
+ <li>2014-08-22 - AT RISK the three limits, first reached per Aug 18 mtg (JA) </li>
+ <li>2014-08-21 - max-triple-count, max-member-count, max-kbyte-count with parms being integers per Aug 18 mtg (JA) </li>
+ <li>2014-08-05 - Re-cast sort criteria as rdf:List compatible with syntactic sugar for those (JA) </li>
+ <li>2014-08-05 - Fuss SOTD for Arnaud (JA) </li>
+ <li>2014-08-04 - Fuss with SortValueAscending value for Sandro (JA) </li>
+ <li>2014-08-04 - Incorporating resolutions from today's WG meeting (JA) </li>
+ <li>2014-07-30 - Rewording based on SS's 7/17 email comments (JA) </li>
+ <li>2014-07-29 - Fully specify 303+location's URI (JA) </li>
+ <li>2014-07-29 - Fuss with SortValueAscending value for Sandro (JA) </li>
+ <li>2014-07-29 - Update 6.2.9 to resolve the "add only at the end"/sorted container conflict (JA) </li>
+ <li>2014-07-29 - Remove chunked transfer encoding, which readers were conflating with paging (chunking) (JA) </li>
+ <li>2014-07-29 - Finish Turtle updates for change to Link header to locate sort criteria (JA) </li>
+ <li>2014-07-28 - Updates based on Sandro's email, excluding those on public comments list (JA) </li>
+ <li>2014-07-28 - Updates to address public review comment on must-not initiate paging (JA) </li>
+ <li>2014-07-28 - Updates to address public review comment on Prefer (JA) </li>
+ <li>2014-07-17 - Fixed minor spelling/grammar and validation problems (SS)</li>
+ <li>2014-07-15 - Final updates hopefully before LC2 draft issued (JA) </li>
+ <li>2014-07-09 - Fix Ashok's emailed comments (JA) </li>
+ <li>2014-07-09 - Clean up clients chapter, references, non/normative section listing in conformance, kitchen sink (JA) </li>
+ <li>2014-07-09 - Move paging example into "intro" chapter 4 (JA) </li>
+ <li>2014-07-08 - Resolve a set of editorial to-dos (JA) </li>
+ <li>2014-07-07 - Clients must consent to/invite paging per 20140630 resolution 2 (JA) </li>
+ <li>2014-07-07 - Rename single-page resource to in-sequence page resource per 20140630 resolution 3 (JA) </li>
+ <li>2014-06-10 - Use http-bis and Prefer RFC numbers, adjust BNF to match bis changes (JA) </li>
+ <li>2014-05-22 - Spec membership & containment triples on same page (JA) </li>
+ <li>2014-05-22 - Spec syntax for page size hint; still need to wrap more text and examples around it (JA) </li>
+ <li>2014-05-20 - Spec Sandro's proposal, choose link relation for detection of paged resource changes (JA) </li>
+ <li>2014-05-19 - Rewrote non-normative parts, cleaned up terminology, ordering undefined when paging non-LDPC LDPRs (JA) </li>
+ <li>2014-05-15 - Fixed Respec messages by adding "terminology from LDP" section (JA) </li>
+ <li>2014-03-10 - Fixed namespaces (SS) </li>
+ <li>2014-02-18 - Split off LDP-Paging from LDP (SS) </li>
+</ul>
+<blockquote><em><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/94420c5678ae/ldp.html">February 18, 2014 Editor's Draft</a></em></blockquote> -->
+</section>
+
+
+
+<section id="references" class="appendix" typeof="bibo:Chapter" resource="#references" rel="bibo:Chapter"><!--OddPage--><h2 aria-level="1" role="heading" id="h2_references"><span class="secno">D. </span>References</h2><section id="normative-references" typeof="bibo:Chapter" resource="#normative-references" rel="bibo:Chapter"><h3 aria-level="2" role="heading" id="h3_normative-references"><span class="secno">D.1 </span>Normative references</h3><dl class="bibliography" about=""><dt id="bib-2NN">[2NN]</dt><dd rel="dcterms:requires">E. Prud'hommeaux. <a href="http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-2NN.xml"><cite>The Hypertext Transfer Protocol (HTTP) Status Code 2NN (Contents of Related)</cite></a>. Internet-Draft. URL: <a href="http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-2NN.xml">http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-2NN.xml</a>
+</dd><dt id="bib-LDP">[LDP]</dt><dd rel="dcterms:requires">Steve Speicher; John Arwe; Ashok Malhotra. <a href="http://www.w3.org/TR/ldp/"><cite>Linked Data Platform 1.0</cite></a>. 19 June 2014. W3C Candidate Recommendation. URL: <a href="http://www.w3.org/TR/ldp/">http://www.w3.org/TR/ldp/</a>
+</dd><dt id="bib-REL-CANONICAL">[REL-CANONICAL]</dt><dd rel="dcterms:requires">M. Ohye; J. Kupke. <a href="http://tools.ietf.org/html/rfc6596"><cite>The Canonical Link Relation</cite></a>. Informational. URL: <a href="http://tools.ietf.org/html/rfc6596">http://tools.ietf.org/html/rfc6596</a>
+</dd><dt id="bib-RFC2119">[RFC2119]</dt><dd rel="dcterms:requires">S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate Requirement Levels</cite></a>. March 1997. Best Current Practice. URL: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>
+</dd><dt id="bib-RFC5988">[RFC5988]</dt><dd rel="dcterms:requires">M. Nottingham. <a href="http://www.ietf.org/rfc/rfc5988.txt"><cite>Web Linking</cite></a>. October 2010. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc5988.txt">http://www.ietf.org/rfc/rfc5988.txt</a>
+</dd><dt id="bib-RFC7230">[RFC7230]</dt><dd rel="dcterms:requires">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7230.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7230.txt">http://www.ietf.org/rfc/rfc7230.txt</a>
+</dd><dt id="bib-RFC7231">[RFC7231]</dt><dd rel="dcterms:requires">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7231.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7231.txt">http://www.ietf.org/rfc/rfc7231.txt</a>
+</dd><dt id="bib-RFC7232">[RFC7232]</dt><dd rel="dcterms:requires">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7232.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7232.txt">http://www.ietf.org/rfc/rfc7232.txt</a>
+</dd><dt id="bib-RFC7238">[RFC7238]</dt><dd rel="dcterms:requires">J. Reschke. <a href="http://www.ietf.org/rfc/rfc7238.txt"><cite>The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)</cite></a>. June 2014. Experimental. URL: <a href="http://www.ietf.org/rfc/rfc7238.txt">http://www.ietf.org/rfc/rfc7238.txt</a>
+</dd><dt id="bib-RFC7240">[RFC7240]</dt><dd rel="dcterms:requires">J. Snell. <a href="http://www.ietf.org/rfc/rfc7240.txt"><cite>Prefer Header for HTTP</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7240.txt">http://www.ietf.org/rfc/rfc7240.txt</a>
+</dd><dt id="bib-WEBARCH">[WEBARCH]</dt><dd rel="dcterms:requires">Ian Jacobs; Norman Walsh. <a href="http://www.w3.org/TR/webarch/"><cite>Architecture of the World Wide Web, Volume One</cite></a>. 15 December 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a>
+</dd><dt id="bib-sparql11-query">[sparql11-query]</dt><dd rel="dcterms:requires">Steven Harris; Andy Seaborne. <a href="http://www.w3.org/TR/sparql11-query/"><cite>SPARQL 1.1 Query Language</cite></a>. 21 March 2013. W3C Recommendation. URL: <a href="http://www.w3.org/TR/sparql11-query/">http://www.w3.org/TR/sparql11-query/</a>
+</dd></dl></section><section id="informative-references" typeof="bibo:Chapter" resource="#informative-references" rel="bibo:Chapter"><h3 aria-level="2" role="heading" id="h3_informative-references"><span class="secno">D.2 </span>Informative references</h3><dl class="bibliography" about=""><dt id="bib-LDP-UCR">[LDP-UCR]</dt><dd rel="dcterms:references">Steve Battle; Steve Speicher. <a href="http://www.w3.org/TR/ldp-ucr/"><cite>Linked Data Platform Use Cases and Requirements</cite></a>. 13 March 2014. W3C Note. URL: <a href="http://www.w3.org/TR/ldp-ucr/">http://www.w3.org/TR/ldp-ucr/</a>
+</dd><dt id="bib-NON-REPEATABLE-READS">[NON-REPEATABLE-READS]</dt><dd rel="dcterms:references">Various. <a href="http://en.wikipedia.org/wiki/Isolation_(database_systems)#Non-repeatable_reads"><cite>Wikipedia: Isolation (database systems)</cite></a>. N/A. URL: <a href="http://en.wikipedia.org/wiki/Isolation_(database_systems)#Non-repeatable_reads">http://en.wikipedia.org/wiki/Isolation_(database_systems)#Non-repeatable_reads</a>
+</dd><dt id="bib-READ-COMMITTED">[READ-COMMITTED]</dt><dd rel="dcterms:references">Various. <a href="http://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed"><cite>Wikipedia: Isolation (database systems)</cite></a>. N/A. URL: <a href="http://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed">http://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed</a>
+</dd><dt id="bib-RFC5005">[RFC5005]</dt><dd rel="dcterms:references">M. Nottingham. <a href="http://www.ietf.org/rfc/rfc5005.txt"><cite>Feed Paging and Archiving</cite></a>. September 2007. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc5005.txt">http://www.ietf.org/rfc/rfc5005.txt</a>
+</dd><dt id="bib-turtle">[turtle]</dt><dd rel="dcterms:references">Eric Prud'hommeaux; Gavin Carothers. <a href="http://www.w3.org/TR/turtle/"><cite>RDF 1.1 Turtle</cite></a>. 25 February 2014. W3C Recommendation. URL: <a href="http://www.w3.org/TR/turtle/">http://www.w3.org/TR/turtle/</a>
+</dd></dl></section></section></body></html>
\ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/TR/WD-ldp-paging-20140909/ldp-paging.ttl Mon Sep 08 12:44:59 2014 -0400
@@ -0,0 +1,93 @@
+# See details within this document for linkage to specification and purpose.
+# This ontology file is a non-normative supporting document.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix owl: <http://www.w3.org/2002/07/owl#>.
+@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .
+@prefix : <http://www.w3.org/ns/ldp#>.
+
+:
+ a owl:Ontology;
+ dcterms:description "Vocabulary URIs defined in the Linked Data Platform Paging (LDP-Paging) namespace.";
+ dcterms:title "The W3C Linked Data Platform Paging (LDP-Paging) Vocabulary";
+ rdfs:label "W3C Linked Data Platform Paging (LDP-Paging)";
+ rdfs:comment "This ontology provides an informal representation of the concepts and terms
+ as defined in the LDP specification. Consult the LDP specification for normative reference.";
+ rdfs:seeAlso <http://www.w3.org/2012/ldp>,
+ <http://www.w3.org/TR/ldp-ucr/>,
+ <http://www.w3.org/TR/ldp/>,
+ <http://www.w3.org/TR/ldp-paging/>,
+ <http://www.w3.org/2011/09/LinkedData/>.
+
+:pageSortCriteria
+ a rdf:Property;
+ rdfs:comment "Link to the list of sorting criteria used by the server in a representation. Typically used on Link response headers as an extension link relation URI in the rel= parameter.";
+ vs:term_status "unstable";
+ rdfs:domain :Page;
+ rdfs:isDefinedBy :;
+ rdfs:label "pageSortCriteria";
+ rdfs:range rdf:List.
+
+:pageSortCriterion
+ a rdf:Class;
+ rdfs:comment "Element in the list of sorting criteria used by the server to assign container members to pages.";
+ vs:term_status "unstable";
+ rdfs:label "pageSortCriterion";
+ rdfs:isDefinedBy :.
+
+:pageSortPredicate
+ a rdf:Property;
+ rdfs:comment "Predicate used to specify the order of the members across a page sequence's in-sequence page resources; it asserts nothing about the order of members in the representation of a single page.";
+ vs:term_status "unstable";
+ rdfs:domain :pageSortCriterion;
+ rdfs:isDefinedBy :;
+ rdfs:label "pageSortPredicate";
+ rdfs:range rdf:Property.
+
+:pageSortOrder
+ a rdf:Property;
+ rdfs:comment "The ascending/descending/etc order used to order the members across pages in a page sequence.";
+ vs:term_status "unstable";
+ rdfs:domain :pageSortCriterion;
+ rdfs:isDefinedBy :;
+ rdfs:label "pageSortOrder";
+ rdfs:range rdf:Resource.
+
+:pageSortCollation
+ a rdf:Property;
+ rdfs:comment "The collation used to order the members across pages in a page sequence when comparing strings.";
+ vs:term_status "unstable";
+ rdfs:domain :pageSortCriterion;
+ rdfs:isDefinedBy :;
+ rdfs:label "pageSortCollation";
+ rdfs:range rdf:Property.
+
+:Ascending
+ a rdf:Description; # individual
+ rdfs:comment "Ascending order.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "Ascending".
+
+:Descending
+ a rdf:Description; # individual
+ rdfs:comment "Descending order.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "Descending".
+
+:Page
+ a rdfs:Class;
+ rdfs:comment "URI signifying that the resource is an in-sequence page resource, as defined by LDP Paging. Typically used on Link rel='type' response headers.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "Page".
+
+:pageSequence
+ a rdfs:Class;
+ rdfs:comment "Link to a page sequence resource, as defined by LDP Paging. Typically used to communicate the sorting criteria used to allocate LDPC members to pages.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "Page".
+
\ No newline at end of file
--- a/ldp-paging.html Mon Sep 08 12:33:46 2014 -0400
+++ b/ldp-paging.html Mon Sep 08 12:44:59 2014 -0400
@@ -41,7 +41,7 @@
// subtitle : "an excellent document",
// if you wish the publication date to be other than today, set this
- publishDate: "2014-08-28",
+ publishDate: "2014-09-09",
// if the specification's copyright date is a range of years, specify
// the start date here:
@@ -57,7 +57,7 @@
edDraftURI: "http://www.w3.org/2012/ldp/hg/ldp-paging.html",
// if this is a LCWD, uncomment and set the end of its review period
- lcEnd: "2014-09-18",
+ lcEnd: "2014-09-30",
// Only include h1 and h2 level
maxTocLevel: 2,