--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-paging-norespec 1.0.htm Mon Jun 01 12:09:45 2015 -0400
@@ -0,0 +1,2120 @@
+<!DOCTYPE html>
+<html dir="ltr" typeof="bibo:Document w3p:NOTE" prefix="bibo: http://purl.org/ontology/bibo/ w3p: http://www.w3.org/2001/02pd/rec54#" lang="en"><head><meta property="dc:language" content="en" lang="">
+ <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 href="ldp-paging-norespec%201.0_files/W3C-NOTE.css" rel="stylesheet"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
+<body id="respecDocument" role="document" class="h-entry"><div id="respecHeader" role="contentinfo" class="head">
+ <p>
+
+
+ <a href="http://www.w3.org/"><img src="ldp-paging-norespec%201.0_files/w3c_home.png" alt="W3C" height="48" width="72"></a>
+
+
+ </p>
+ <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform Paging 1.0</h1>
+
+ <h2 id="w3c-working-group-note-11-december-2014"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note <time property="dcterms:issued" class="dt-published" datetime="2014-12-11">11 December 2014</time></h2>
+ <dl>
+
+ <dt>This version:</dt>
+ <dd><a class="u-url" href="http://www.w3.org/TR/2014/NOTE-ldp-paging-20141211/">http://www.w3.org/TR/2014/NOTE-ldp-paging-20141211/</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>Implementation report:</dt>
+ <dd><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/tests/reports/paging/ldp-paging.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/tests/reports/paging/ldp-paging.html</a></dd>
+
+
+
+
+ <dt>Previous version:</dt>
+ <dd><a rel="dcterms:replaces" href="http://www.w3.org/TR/2014/WD-ldp-paging-20140909/">http://www.w3.org/TR/2014/WD-ldp-paging-20140909/</a></dd>
+
+
+ <dt>Editors:</dt>
+ <dd class="p-author h-card vcard" property="bibo:editor" resource="_:editor0"><span property="rdf:first" typeof="foaf:Person"><meta property="foaf:name" content="Steve Speicher"><a class="u-url url p-name fn" property="foaf:homepage" href="http://stevespeicher.blogspot.com/">Steve Speicher</a>, <a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://ibm.com/">IBM Corporation</a></span>
+<span property="rdf:rest" resource="_:editor1"></span>
+</dd>
+<dd class="p-author h-card vcard" resource="_:editor1"><span property="rdf:first" typeof="foaf:Person"><meta property="foaf:name" content="John Arwe"><a class="u-url url p-name fn" property="foaf:homepage" href="https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?userid=120000CAW7">John Arwe</a>, <a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://ibm.com/">IBM Corporation</a></span>
+<span property="rdf:rest" resource="_:editor2"></span>
+</dd>
+<dd class="p-author h-card vcard" resource="_:editor2"><span property="rdf:first" typeof="foaf:Person"><meta property="foaf:name" content="Ashok Malhotra"><a class="u-url url p-name fn" property="foaf:homepage" href="mailto:ashok.malhotra@oracle.com">Ashok Malhotra</a>, <a property="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oracle.com/">Oracle Corporation</a></span>
+<span property="rdf:rest" resource="rdf:nil"></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>).
+
+ <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 property="dc:abstract" class="introductory" id="abstract"><h2 resource="#h-abstract" id="h-abstract"><span property="xhv:role" resource="xhv:heading">Abstract</span></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"><h2 resource="#h-sotd" id="h-sotd"><span property="xhv:role" resource="xhv:heading">Status of This Document</span></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>
+ 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 href="#bib-LDP" class="bibref">LDP</a></cite>]. A test suite has also been made available [<cite><a href="#bib-LDP-PAGING-TESTSUITE" class="bibref">LDP-PAGING-TESTSUITE</a></cite>].
+ </p>
+ <p>
+ Due to lack of sufficient implementations, this specification is being published as a W3C NOTE.
+
+ This document was published by the <a href="http://www.w3.org/2012/ldp">Linked Data Platform Working Group</a> as a Working Group Note.
+
+
+ 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>).
+
+
+
+
+
+
+ All comments are welcome.
+
+
+ </p>
+
+ <p>
+ Please see the Working Group's <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/tests/reports/paging/ldp-paging.html">implementation
+ report</a>.
+ </p>
+
+
+
+ <p>
+ Publication as a Working Group Note 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 document was produced by a group operating under the
+ <a id="sotd_patent" property="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/2005/10/Process-20051014/">14 October 2005 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.
+ </p>
+
+
+
+
+
+</section><section id="toc"><h2 resource="#h-toc" id="h-toc" class="introductory"><span property="xhv:role" resource="xhv:heading">Table of Contents</span></h2><ul id="respecContents" role="directory" class="toc"><li class="tocline"><a class="tocxref" href="#intro"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a class="tocxref" href="#terms"><span class="secno">2. </span>Terminology</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#terms-from-ldp"><span class="secno">2.1 </span>Terms re-used from the Linked Data Platform</a></li><li class="tocline"><a class="tocxref" href="#terms-from-paging"><span class="secno">2.2 </span>Terms normatively defined by this specification</a></li><li class="tocline"><a class="tocxref" href="#conventions"><span class="secno">2.3 </span>Conventions Used in This Document</a></li></ul></li><li class="tocline"><a class="tocxref" href="#conformance"><span class="secno">3. </span>Conformance</a></li><li class="tocline"><a class="tocxref" href="#ldpp-ex-mx"><span class="secno">4. </span>Example paging message exchanges</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#ldpp-ex-no-paging"><span class="secno">4.1 </span>Traditional flow without paging</a></li><li class="tocline"><a class="tocxref" href="#ldpp-ex-paging-303"><span class="secno">4.2 </span>Simple paging flow using redirects</a></li><li class="tocline"><a class="tocxref" href="#ldpp-ex-paging-other-links"><span class="secno">4.3 </span>Optional paging links</a></li></ul></li><li class="tocline"><a class="tocxref" href="#ldppclient"><span class="secno">5. </span>Linked Data Platform Paging Clients</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#general-requirements"><span class="secno">5.1 </span>General requirements</a><ul class="toc"></ul></li><li class="tocline"><a class="tocxref" href="#ldpp-hints"><span class="secno">5.2 </span>Client preferences</a><ul class="toc"></ul></li></ul></li><li class="tocline"><a class="tocxref" href="#ldpr"><span class="secno">6. </span>Linked Data Platform Resources</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#ldpr-PagingIntro"><span class="secno">6.1 </span>Paging considerations</a></li><li class="tocline"><a class="tocxref" href="#ldpr-PagingGET"><span class="secno">6.2 </span>HTTP GET</a><ul class="toc"></ul></li></ul></li><li class="tocline"><a class="tocxref" href="#ldpc"><span class="secno">7. </span>Linked Data Platform Containers</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#ldpc-general"><span class="secno">7.1 </span>Requirements when paging LDP Containers</a><ul class="toc"></ul></li><li class="tocline"><a class="tocxref" href="#ldpc-informative"><span class="secno">7.2 </span>Ordering of container members across pages</a><ul class="toc"></ul></li><li class="tocline"><a class="tocxref" href="#ldpc-HTTP_GET"><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 class="tocxref" href="#security"><span class="secno">8. </span>Security Considerations</a></li><li class="tocline"><a class="tocxref" href="#ldpr-impl"><span class="secno">A. </span>Paging <abbr title="Linked Data Platform Resources">LDPRs</abbr> without maintaining server-side session state</a></li><li class="tocline"><a class="tocxref" href="#acks"><span class="secno">B. </span>Acknowledgements</a></li><li class="tocline"><a class="tocxref" href="#history"><span class="secno">C. </span>Change History</a></li><li class="tocline"><a class="tocxref" href="#references"><span class="secno">D. </span>References</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#normative-references"><span class="secno">D.1 </span>Normative references</a></li><li class="tocline"><a class="tocxref" href="#informative-references"><span class="secno">D.2 </span>Informative references</a></li></ul></li></ul></section>
+
+
+
+<section property="bibo:hasPart" resource="#intro" typeof="bibo:Chapter" class="informative" id="intro">
+
+<!--OddPage--><h2 resource="#h-intro" id="h-intro"><span property="xhv:role" resource="xhv:heading"><span class="secno">1. </span>Introduction</span></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 class="internalDFN" href="#dfn-paged-resource" title="Paged resource">paged HTTP resource</a>
+ available as a list of smaller subset resources (<a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">pages</a>) whose
+ representations are less burdensome for servers to form.
+ <a class="internalDFN" href="#dfn-paged-resource" title="Paged resource">Paged resources</a> must be LDP Resources (<abbr title="Linked Data Platform Resources">LDPRs</abbr>) [<cite><a href="#bib-LDP" class="bibref">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 <abbr title="Linked Data Platform Resources">LDPRs</abbr>, like
+ LDP-RSs or <abbr title="Linked Data Platform Containers">LDPCs</abbr>.
+ </p>
+ <p>
+ When a client attempts to retrieve a <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>, the server either redirects the client to
+ a "first page" <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">resource</a> or provides the
+ representation of the "first page" <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">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 class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">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 <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+ LDP Paging defines a mechanism by which clients can learn that the <a class="internalDFN" href="#dfn-paged-resource">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 class="internalDFN" href="#dfn-paged-resource">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 href="#bib-LDP-UCR" class="bibref">LDP-UCR</a></cite>].
+ </p>
+</section>
+
+<section property="bibo:hasPart" resource="#terms" typeof="bibo:Chapter" id="terms">
+<!--OddPage--><h2 resource="#h-terms" id="h-terms"><span property="xhv:role" resource="xhv:heading"><span class="secno">2. </span>Terminology</span></h2>
+
+<section property="bibo:hasPart" resource="#terms-from-ldp" typeof="bibo:Chapter" id="terms-from-ldp">
+<h3 resource="#h-terms-from-ldp" id="h-terms-from-ldp"><span property="xhv:role" resource="xhv:heading"><span class="secno">2.1 </span>Terms re-used from the Linked Data Platform</span></h3>
+
+<p>This section is non-normative. It summarizes a subset of terms formally defined in [<cite><a href="#bib-LDP" class="bibref">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 href="#bib-RFC7230" class="bibref">RFC7230</a></cite>] that follows the rules defined by [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>]
+ when it is serving <abbr title="Linked Data Platform Resources">LDPRs</abbr> and
+ <abbr title="Linked Data Platform Containers">LDPCs</abbr>.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-ldp-client">LDP client</dfn></dt>
+ <dd>A conforming HTTP client [<cite><a href="#bib-RFC7230" class="bibref">RFC7230</a></cite>] that follows the rules defined by [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] when
+ interacting with a <a class="internalDFN" href="#dfn-ldp-server">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 href="#bib-LDP" class="bibref">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 class="internalDFN" href="#dfn-linked-data-platform-resource" title="Linked Data Platform Resource"><abbr title="Linked Data Platform Resource">LDPR</abbr></a> whose state is fully represented in RDF [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>].
+ <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 class="internalDFN" href="#dfn-linked-data-platform-resource" title="Linked Data Platform Resource"><abbr title="Linked Data Platform Resources">LDPRs</abbr></a> linked by
+ <a class="internalDFN" href="#dfn-membership-triples">membership triples</a> and <a class="internalDFN" href="#dfn-containment-triples">containment triples</a> [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>].
+ <p></p></dd>
+
+ <dt><dfn id="dfn-membership-triples">Membership triples</dfn></dt>
+ <dd>A set of triples that lists an <a class="internalDFN" href="#dfn-linked-data-platform-container" title="Linked Data Platform Container"><abbr title="Linked Data Platform Container">LDPC</abbr>'s</a> members [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>].
+ <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 [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>].
+ <p></p></dd>
+
+ </dl>
+
+</section>
+
+<section property="bibo:hasPart" resource="#terms-from-paging" typeof="bibo:Chapter" id="terms-from-paging">
+<h3 resource="#h-terms-from-paging" id="h-terms-from-paging"><span property="xhv:role" resource="xhv:heading"><span class="secno">2.2 </span>Terms normatively defined by this specification</span></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 href="#bib-WEBARCH" class="bibref">WEBARCH</a></cite>],
+ Hyper-text Transfer Protocol ([<cite><a href="#bib-RFC7230" class="bibref">RFC7230</a></cite>], [<cite><a href="#bib-RFC7231" class="bibref">RFC7231</a></cite>]) and Linked Data Platform [<cite><a href="#bib-LDP" class="bibref">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 class="internalDFN" href="#dfn-ldp-paging-server">LDP Paging server</a> offers a <a class="internalDFN" href="#dfn-page-sequence">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 href="#bib-RFC5005" class="bibref">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 class="internalDFN" href="#dfn-linked-data-platform-resource" title="Linked Data Platform Resource"><abbr title="Linked Data Platform Resources">LDPRs</abbr></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 class="internalDFN" href="#dfn-paged-resource">paged resource</a>'s state.
+ <p>
+ When the representations of the sequence's <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">resources</a>
+ are combined by a client, the client has a copy of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>'s
+ state; if the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> changed while the client was retrieving the sequence's resources,
+ then the client's copy of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>'s state can be incomplete or inconsistent
+ with the state of the <a class="internalDFN" href="#dfn-paged-resource">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 class="internalDFN" href="#dfn-paged-resource">paged resource</a>'s state did not change during the retrieval process, the
+ client's copy of the <a class="internalDFN" href="#dfn-paged-resource">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 class="internalDFN" href="#dfn-in-sequence-page-resource">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 class="internalDFN" href="#dfn-linked-data-platform-rdf-source" title="Linked Data Platform RDF Source">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 href="#bib-RFC5005" class="bibref">RFC5005</a></cite>], a <a class="internalDFN" href="#dfn-page-sequence">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 class="internalDFN" href="#dfn-page-sequence">page sequence</a>,
+ which contains a subset of the state
+ of another resource <var>P</var>, called the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>.
+ For readers
+ familiar with paged feeds [<cite><a href="#bib-RFC5005" class="bibref">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 class="internalDFN" href="#dfn-paged-resource" title="Paged resource"><em>resource being paged</em></a>, and the
+ <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource"><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 class="internalDFN" href="#dfn-paged-resource">paged resource</a>,
+ using only <a class="internalDFN" href="#dfn-forward-traversal">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 class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">in-sequence page resource</a> <var>P<sub>1 (first)</sub></var>
+ of a <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>. The first page is the one that a LDP Paging server
+ redirects to (<code>303</code> response) in response
+ to a retrieval request for the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>'s URI.
+ Syntactically, a
+ HTTP <code>Link <<var>P<sub>1</sub></var>>; rel="first"</code>
+ header [<cite><a href="#bib-RFC5988" class="bibref">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 class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">in-sequence page resource</a>
+ of a <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>. Syntactically, a
+ HTTP <code>Link <<var>P<sub>i</sub></var>>; rel="next"</code>
+ header [<cite><a href="#bib-RFC5988" class="bibref">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 class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">in-sequence page resource</a> <var>P<sub>n (last)</sub></var>
+ of a <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>.
+ The last page is the page that terminates a <a class="internalDFN" href="#dfn-forward-traversal">forward traversal</a>, because it contains no <a class="internalDFN" href="#dfn-next-page-link">next page link</a>.
+ Syntactically, a
+ HTTP <code>Link <<var>P<sub>n</sub></var>>; rel="last"</code>
+ header [<cite><a href="#bib-RFC5988" class="bibref">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 class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">in-sequence page resource</a>
+ of a <a class="internalDFN" href="#dfn-page-sequence">page sequence</a> Syntactically, a
+ HTTP <code>Link <<var>P<sub>i</sub></var>>; rel="prev"</code>
+ header [<cite><a href="#bib-RFC5988" class="bibref">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 class="internalDFN" href="#dfn-first-page-link" title="first page link">first page links</a>,
+ <a class="internalDFN" href="#dfn-next-page-link" title="next page link">next page links</a>,
+ <a class="internalDFN" href="#dfn-last-page-link" title="last page link">last page links</a>,
+ <a class="internalDFN" href="#dfn-previous-page-link" title="previous page link">previous page links</a>.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-forward-traversal">forward traversal</dfn></dt>
+ <dd>The process of following <a class="internalDFN" href="#dfn-next-page-link" title="next page link">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 class="internalDFN" href="#dfn-page-sequence">page sequence</a>.
+ For example, following forward links does not imply that resources later in the <a class="internalDFN" href="#dfn-page-sequence">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 class="internalDFN" href="#dfn-previous-page-link" title="previous page link">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 class="internalDFN" href="#dfn-page-sequence">page sequence</a>.
+ </p>
+ <p></p></dd>
+
+ </dl>
+</section>
+
+<section property="bibo:hasPart" resource="#conventions" typeof="bibo:Chapter" id="conventions">
+<h3 resource="#h-conventions" id="h-conventions"><span property="xhv:role" resource="xhv:heading"><span class="secno">2.3 </span>Conventions Used in This Document</span></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 href="#bib-turtle" class="bibref">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 property="bibo:hasPart" resource="#conformance" typeof="bibo:Chapter" id="conformance"><!--OddPage--><h2 resource="#h-conformance" id="h-conformance"><span property="xhv:role" resource="xhv:heading"><span class="secno">3. </span>Conformance</span></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 id="respecRFC2119">The key words <em class="rfc2119" title="MAY">MAY</em>, <em class="rfc2119" title="MUST">MUST</em>, <em class="rfc2119" title="MUST NOT">MUST NOT</em>, <em class="rfc2119" title="SHOULD">SHOULD</em>, and <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> are
+ to be interpreted as described in [<cite><a href="#bib-RFC2119" class="bibref">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 href="#bib-LDP" class="bibref">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 href="#bib-LDP" class="bibref">LDP</a></cite>] that follows the rules defined by LDP Paging.</p>
+</section>
+
+<section property="bibo:hasPart" resource="#ldpp-ex-mx" typeof="bibo:Chapter" class="informative" id="ldpp-ex-mx">
+<!--OddPage--><h2 resource="#h-ldpp-ex-mx" id="h-ldpp-ex-mx"><span property="xhv:role" resource="xhv:heading"><span class="secno">4. </span>Example paging message exchanges</span></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 property="bibo:hasPart" resource="#ldpp-ex-no-paging" typeof="bibo:Chapter" id="ldpp-ex-no-paging">
+<h3 resource="#h-ldpp-ex-no-paging" id="h-ldpp-ex-no-paging"><span property="xhv:role" resource="xhv:heading"><span class="secno">4.1 </span>Traditional flow without paging</span></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 property="bibo:hasPart" resource="#ldpp-ex-paging-303" typeof="bibo:Chapter" id="ldpp-ex-paging-303">
+<h3 resource="#h-ldpp-ex-paging-303" id="h-ldpp-ex-paging-303"><span property="xhv:role" resource="xhv:heading"><span class="secno">4.2 </span>Simple paging flow using redirects</span></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 "first subset" URI approach.
+ </p>
+ <p>
+ The "first subset" URI approach 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, contrary to HTTP. 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 class="internalDFN" href="#dfn-paged-resource">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 class="internalDFN" href="#dfn-in-sequence-page-resource">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 class="internalDFN" href="#dfn-paged-resource">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 class="internalDFN" href="#dfn-in-sequence-page-resource">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 class="internalDFN" href="#dfn-in-sequence-page-resource">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 class="internalDFN" href="#dfn-paged-resource">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 class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>s existed in this <a class="internalDFN" href="#dfn-paged-resource">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 class="internalDFN" href="#dfn-paged-resource">paged resource</a>
+ did not change across the client's process of retrieving the entire <a class="internalDFN" href="#dfn-page-sequence">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 class="internalDFN" href="#dfn-paged-resource">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 class="internalDFN" href="#dfn-paged-resource">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 property="bibo:hasPart" resource="#ldpp-ex-paging-other-links" typeof="bibo:Chapter" id="ldpp-ex-paging-other-links">
+<h3 resource="#h-ldpp-ex-paging-other-links" id="h-ldpp-ex-paging-other-links"><span property="xhv:role" resource="xhv:heading"><span class="secno">4.3 </span>Optional paging links</span></h3>
+
+ <p>
+ The preceding paging examples in this section have all assumed that only <a class="internalDFN" href="#dfn-forward-traversal">forward traversal</a>
+ is supported by the server, to reduce complexity.
+ A server might also support <a class="internalDFN" href="#dfn-backward-traversal">backward traversal</a> through its pages, and/or direct access to the
+ <a class="internalDFN" href="#dfn-first-page-link" title="first page link">first page</a> and/or <a class="internalDFN" href="#dfn-last-page-link" title="last page link">last page</a> from any <a class="internalDFN" href="#dfn-in-sequence-page-resource">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 class="internalDFN" href="#dfn-first-page-link" title="first page link">first page</a>'s <a href="#ldpp-ex-paging-303-resp2">response message</a> might also have the following links:
+<div class="example"><div class="example-title"><span>Example 9</span></div><pre class="example">Link: <>; rel="first"
+Link: <http://example.org/customer-relations?p=2>; rel="last"</pre></div>
+ </li>
+ <li>
+ Any <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>'s response message, including the <a class="internalDFN" href="#dfn-first-page-link" title="first page link">first page</a> and the <a class="internalDFN" href="#dfn-last-page-link" title="last page link">last page</a>,
+ might also have the following links:
+<div class="example"><div class="example-title"><span>Example 10</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 class="internalDFN" href="#dfn-last-page-link" title="last page link">last page</a>'s <a href="#ldpp-ex-paging-303-resp3">response message</a> might also have the following links:
+<div class="example"><div class="example-title"><span>Example 11</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 property="bibo:hasPart" resource="#ldppclient" typeof="bibo:Chapter" id="ldppclient">
+<!--OddPage--><h2 resource="#h-ldppclient" id="h-ldppclient"><span property="xhv:role" resource="xhv:heading"><span class="secno">5. </span>Linked Data Platform Paging Clients</span></h2>
+<p>All of the following are conformance rules for <a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">LDP Paging Clients</a>.
+</p>
+<section property="bibo:hasPart" resource="#general-requirements" typeof="bibo:Chapter" id="general-requirements"><h3 resource="#h-general-requirements" id="h-general-requirements"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.1 </span>General requirements</span></h3>
+
+ <section property="bibo:hasPart" resource="#ldpp-client-advertise" typeof="bibo:Chapter" id="ldpp-client-advertise"><h4 resource="#h-ldpp-client-advertise" id="h-ldpp-client-advertise" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.1.1 </span><a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">LDP Paging clients</a> <em title="MUST" class="rfc2119">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.
+ </span></h4>
+ </section>
+
+ <section property="bibo:hasPart" resource="#ldpp-client-traversal" typeof="bibo:Chapter" id="ldpp-client-traversal"><h4 resource="#h-ldpp-client-traversal" id="h-ldpp-client-traversal" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.1.2 </span><a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">LDP Paging clients</a> <em title="MUST" class="rfc2119">MUST</em>
+ be capable of at least one of <a class="internalDFN" href="#dfn-forward-traversal">forward traversal</a> and/or <a class="internalDFN" href="#dfn-backward-traversal">backward traversal</a>.
+ </span></h4>
+ </section>
+
+ <section property="bibo:hasPart" resource="#ldpp-client-linkschg" typeof="bibo:Chapter" id="ldpp-client-linkschg"><h4 resource="#h-ldpp-client-linkschg" id="h-ldpp-client-linkschg" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.1.3 </span><a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">LDP Paging clients</a> <em title="MUST NOT" class="rfc2119">MUST NOT</em>
+ assume that any <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">in-sequence page resource's</a> <a class="internalDFN" href="#dfn-paging-link" title="paging link">paging links</a>
+ will remain unchanged when the <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">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 class="internalDFN" href="#dfn-paged-resource">paged resource</a> changes, for example.
+ </span></h4>
+ </section>
+
+ <section property="bibo:hasPart" resource="#ldpp-client-4xxok" typeof="bibo:Chapter" id="ldpp-client-4xxok"><h4 resource="#h-ldpp-client-4xxok" id="h-ldpp-client-4xxok" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.1.4 </span><a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">LDP Paging clients</a> <em title="MUST NOT" class="rfc2119">MUST NOT</em>
+ assume that any <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">in-sequence page resource's</a> <a class="internalDFN" href="#dfn-paging-link" title="paging link">paging links</a>
+ will always be accessible.</span></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 class="internalDFN" href="#dfn-paged-resource">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 class="internalDFN" href="#dfn-paged-resource" title="Paged resource">paged resource's</a>
+ <a href="#ldpr-notify-changes">state has <i>not</i> changed</a>
+ while the client was traversing its <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">pages</a>.
+ Servers might also limit the lifetime of a particular <a class="internalDFN" href="#dfn-page-sequence">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 property="bibo:hasPart" resource="#ldpp-client-paging-incomplete" typeof="bibo:Chapter" id="ldpp-client-paging-incomplete"><h4 resource="#h-ldpp-client-paging-incomplete" id="h-ldpp-client-paging-incomplete" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.1.5 </span><a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">LDP Paging clients</a>
+ <em title="SHOULD NOT" class="rfc2119">SHOULD NOT</em> treat a page sequence as equivalent to the <a class="internalDFN" href="#dfn-paged-resource" title="paged resource">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>.
+ </span></h4></section>
+
+ <section property="bibo:hasPart" resource="#ldpp-client-nofollow-303" typeof="bibo:Chapter" id="ldpp-client-nofollow-303"><h4 resource="#h-ldpp-client-nofollow-303" id="h-ldpp-client-nofollow-303" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.1.6 </span><a class="internalDFN" href="#dfn-ldp-paging-client" title="LDP Paging client">LDP Paging clients</a>
+ <em title="MUST NOT" class="rfc2119">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 href="#bib-RFC7231" class="bibref">RFC7231</a></cite>] or <code>308 Permanent Redirect</code> [<cite><a href="#bib-RFC7238" class="bibref">RFC7238</a></cite>],
+ as [<cite><a href="#bib-RFC7231" class="bibref">RFC7231</a></cite>] makes clear. This is critical to a client's ability to distinguish between the representation
+ of a single <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a> and that of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> when a <a class="internalDFN" href="#dfn-ldp-paging-server">LDP Paging server</a>
+ uses <a href="#ldpr-status-code">redirection</a> as a way to initiate paging.
+ </span></h4></section>
+
+</section>
+
+<section property="bibo:hasPart" resource="#ldpp-hints" typeof="bibo:Chapter" id="ldpp-hints">
+<h3 resource="#h-ldpp-hints" id="h-ldpp-hints"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.2 </span>Client preferences</span></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 href="#bib-RFC7240" class="bibref">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>
+
+ <section property="bibo:hasPart" resource="#ldpr-cli-paging" typeof="bibo:Chapter" id="ldpr-cli-paging"><h4 resource="#h-ldpr-cli-paging" id="h-ldpr-cli-paging" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">5.2.1 </span>
+ <a class="internalDFN" href="#dfn-ldp-client" title="LDP client">LDP clients</a> <em title="SHOULD" class="rfc2119">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 href="#bib-LDP" class="bibref">LDP</a></cite>].
+ </span></h4>
+ </section>
+
+ <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 href="#bib-RFC7240" class="bibref">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 <a class="internalDFN" href="#dfn-linked-data-platform-container" title="Linked Data Platform Container"><abbr title="Linked Data Platform Containers">LDPCs</abbr></a>.
+ </td>
+ </tr>
+ </tbody></table>
+ <blockquote>
+ <p>
+ The generic preference BNF [<cite><a href="#bib-RFC7240" class="bibref">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 class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">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 property="bibo:hasPart" resource="#ldpr" typeof="bibo:Chapter" id="ldpr">
+<!--OddPage--><h2 resource="#h-ldpr" id="h-ldpr"><span property="xhv:role" resource="xhv:heading"><span class="secno">6. </span>Linked Data Platform Resources</span></h2>
+
+<section property="bibo:hasPart" resource="#ldpr-PagingIntro" typeof="bibo:Chapter" class="informative" id="ldpr-PagingIntro">
+
+<h3 resource="#h-ldpr-pagingintro" id="h-ldpr-pagingintro"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.1 </span>Paging considerations</span></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 class="internalDFN" href="#dfn-paged-resource">paged resource</a>
+ into a list of <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">in-sequence page resources</a> (pages) whose representations the client can retrieve, and serves each
+ page with links to other <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">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 <abbr title="Linked Data Platform Containers">LDPCs</abbr></a> the server can expose its
+ algorithm.
+ </p>
+ <p>
+ Some clients will be interested in knowing whether or not competing requests altered the
+ <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> while the client was retrieving pages, since LDP paging does not guarantee
+ that those alterations were reflected in any <a class="internalDFN" href="#dfn-in-sequence-page-resource">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 href="#bib-READ-COMMITTED" class="bibref">READ-COMMITTED</a></cite>];
+ specifically, clients can observe
+ non-repeatable reads [<cite><a href="#bib-NON-REPEATABLE-READS" class="bibref">NON-REPEATABLE-READS</a></cite>] while traversing pages served by
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">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 class="internalDFN" href="#dfn-paged-resource" title="Paged resource">paged resource</a> across the entire period of time when the client is retrieving pages will
+ be present in at least one <a class="internalDFN" href="#dfn-in-sequence-page-resource">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 href="#bib-RFC5005" class="bibref">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 class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>s without the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>
+ being added to or changed, so clients requiring such a guarantee
+ may not find all <a class="internalDFN" href="#dfn-paged-resource">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 property="bibo:hasPart" resource="#ldpr-PagingGET" typeof="bibo:Chapter" id="ldpr-PagingGET">
+<h3 resource="#h-ldpr-pagingget" id="h-ldpr-pagingget"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2 </span>HTTP GET</span></h3>
+ <p>In addition to the requirements on HTTP <code>GET</code> for <abbr title="Linked Data Platform Resources">LDPRs</abbr> [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>],
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> must
+ also follow the requirements in this section for all <a class="internalDFN" href="#dfn-paged-resource" title="Paged resource">paged resources</a>
+ and their associated <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">in-sequence page resources</a>.
+ </p>
+
+ <section property="bibo:hasPart" resource="#ldpr-page-large" typeof="bibo:Chapter" id="ldpr-page-large"><h4 resource="#h-ldpr-page-large" id="h-ldpr-page-large" class="normal"><span property="xhv:role" resource="xhv:heading"><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 class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="SHOULD" class="rfc2119">SHOULD</em> allow clients to retrieve large LDP-RSs in
+ pages.
+ </span></h4></section><!-- Was 4.2.14 / #ldpr-4_2_14 -->
+
+ <section property="bibo:hasPart" resource="#ldpr-split-any-resource" typeof="bibo:Chapter" id="ldpr-split-any-resource"><h4 resource="#h-ldpr-split-any-resource" id="h-ldpr-split-any-resource" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.2 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">MAY</em>
+ treat any resource (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> or not) as a <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>.
+ </span></h4></section><!-- Was 4.2.15 / #ldpr-4_2_15 -->
+
+ <section property="bibo:hasPart" resource="#ldpr-split-any-time" typeof="bibo:Chapter" id="ldpr-split-any-time"><h4 resource="#h-ldpr-split-any-time" id="h-ldpr-split-any-time" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.3 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">MAY</em>
+ vary their treatment of any resource (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> or not) as a <a class="internalDFN" href="#dfn-paged-resource">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>.
+ </span></h4></section>
+
+ <section property="bibo:hasPart" resource="#ldpp-prefer" typeof="bibo:Chapter" id="ldpp-prefer"><h4 resource="#h-ldpp-prefer" id="h-ldpp-prefer" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.4 </span><a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a>
+ <em title="SHOULD" class="rfc2119">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.</span></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 class="internalDFN" href="#dfn-paged-resource">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 href="#bib-RFC7240" class="bibref">RFC7240</a></cite>].
+ </blockquote>
+ <blockquote>
+ <em>Non-normative note</em>: [<cite><a href="#bib-RFC7240" class="bibref">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 property="bibo:hasPart" resource="#ldpp-prefer-unrecognized" typeof="bibo:Chapter" id="ldpp-prefer-unrecognized"><h4 resource="#h-ldpp-prefer-unrecognized" id="h-ldpp-prefer-unrecognized" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.5 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">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.
+ </span></h4></section>
+
+ <section property="bibo:hasPart" resource="#ldpr-status-code" typeof="bibo:Chapter" id="ldpr-status-code"><h4 resource="#h-ldpr-status-code" id="h-ldpr-status-code" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.6 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="SHOULD NOT" class="rfc2119">SHOULD NOT</em>
+ initiate paging unless the client has indicated it understands LDP Paging.
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> initiating paging <em title="SHOULD" class="rfc2119">SHOULD</em> respond
+ to successful <code>GET</code> requests with any <a class="internalDFN" href="#dfn-paged-resource" title="Paged resource">paged resource</a>
+ as the <code>Request-URI</code> in one of the following ways:</span></h4>
+ <ul>
+ <li>
+ If the client supports paging, respond with
+ status code <code>303 See Other</code> and a <code>Location</code> response header that identifies
+ the first <a class="internalDFN" href="#dfn-in-sequence-page-resource">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 class="internalDFN" href="#dfn-ldp-paging-server" 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 class="internalDFN" href="#dfn-paged-resource">paged resource</a>
+ rather than of a single <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>.
+ <a class="internalDFN" href="#dfn-ldp-paging-client" 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 [<cite><a href="#bib-RFC7231" class="bibref">RFC7231</a></cite>].
+ </blockquote>
+ </section>
+
+ <section property="bibo:hasPart" resource="#ldpr-guarantee-show-unchanged" typeof="bibo:Chapter" id="ldpr-guarantee-show-unchanged"><h4 resource="#h-ldpr-guarantee-show-unchanged" id="h-ldpr-guarantee-show-unchanged" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.7 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST" class="rfc2119">MUST</em>
+ ensure that all state present in the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> throughout a client's <em>entire</em> traversal operation
+ is represented in at least one <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>. In other words, whatever subset of the
+ <a class="internalDFN" href="#dfn-paged-resource">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.
+ </span></h4>
+ <blockquote><em>Non-normative note:</em>
+ As a consequence, if the <a class="internalDFN" href="#dfn-paged-resource">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 class="internalDFN" href="#dfn-paged-resource">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 class="internalDFN" href="#dfn-paged-resource">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 class="internalDFN" href="#dfn-paged-resource">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 property="bibo:hasPart" resource="#ldpr-notify-changes" typeof="bibo:Chapter" id="ldpr-notify-changes"><h4 resource="#h-ldpr-notify-changes" id="h-ldpr-notify-changes" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.8 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST" class="rfc2119">MUST</em>
+ enable a client to detect any change to the <a class="internalDFN" href="#dfn-paged-resource">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 title="SHOULD" class="rfc2119">SHOULD</em> include the same header on all <code>4xx</code>
+ status code responses.
+ The link's
+ context URI identifies the <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a> being retrieved,
+ target URI identifies the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>,
+ link relation type is <code>canonical</code> [<cite><a href="#bib-REL-CANONICAL" class="bibref">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 href="#bib-RFC7232" class="bibref">RFC7232</a></cite>]
+ of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a>.
+ For example: <code>Link: <http://example.org/customer-relations>; rel="canonical"; etag="customer-relations-v1"</code>
+ </span></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 class="internalDFN" href="#dfn-paged-resource">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 property="bibo:hasPart" resource="#ldpr-pagingGET-sequences-change" typeof="bibo:Chapter" id="ldpr-pagingGET-sequences-change"><h4 resource="#h-ldpr-pagingget-sequences-change" id="h-ldpr-pagingget-sequences-change" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.9 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">MAY</em>
+ add or remove <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">in-sequence page resources</a> to a
+ <a class="internalDFN" href="#dfn-paged-resource" title="Paged resource">paged resource's</a> sequence over time.
+ If the <a class="internalDFN" href="#dfn-page-sequence">page sequence</a> is <a href="#ldpc-HTTP_GET">ordered</a>, then the ordering communicated by the server <em title="MUST" class="rfc2119">MUST</em> be maintained;
+ the server <em title="SHOULD" class="rfc2119">SHOULD</em> only add pages to the end of an unordered sequence.
+ </span></h4><!-- Was 4.10.2.1 / #ldpr-pagingGET-sequences-change -->
+ <blockquote><em>Non-normative note:</em>
+ Servers might abandon an ordered <a class="internalDFN" href="#dfn-page-sequence">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 class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a> several times can observe its place in the sequence
+ change as the state of the <a class="internalDFN" href="#dfn-paged-resource">paged resource</a> changes.
+ For example, a nominally last page's server might provide a
+ <a class="internalDFN" href="#dfn-next-page-link">next page link</a> when the page is retrieved again later.
+ Similar situations arise when the <a class="internalDFN" href="#dfn-page-sequence">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 class="internalDFN" href="#dfn-paged-resource" title="Paged resource">paged resource's</a> content after the client retrieves <var>M</var>.
+ </blockquote>
+ </section>
+
+ <section property="bibo:hasPart" resource="#ldpr-pagingGET-first-allowed-onpages" typeof="bibo:Chapter" id="ldpr-pagingGET-first-allowed-onpages"><h4 resource="#h-ldpr-pagingget-first-allowed-onpages" id="h-ldpr-pagingget-first-allowed-onpages" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.10 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">MAY</em> provide
+ a <a class="internalDFN" href="#dfn-first-page-link">first page link</a> when responding to
+ requests with any <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">in-sequence page resource</a> as the <code>Request-URI</code>.
+ </span></h4></section><!-- Was 4.10.2.1.1 / #ldpr-pagingGET-sequences-change -->
+
+ <section property="bibo:hasPart" resource="#ldpr-pagingGET-last-allowed-onpages" typeof="bibo:Chapter" id="ldpr-pagingGET-last-allowed-onpages"><h4 resource="#h-ldpr-pagingget-last-allowed-onpages" id="h-ldpr-pagingget-last-allowed-onpages" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.11 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">MAY</em>
+ provide a <a class="internalDFN" href="#dfn-last-page-link">last page link</a>
+ in responses to <code>GET</code> requests with any <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">in-sequence page resource</a> as the <code>Request-URI</code>.
+ </span></h4></section><!-- Was 4.10.2.1.3 / #ldpr-pagingGET-last-allowed-onpages -->
+
+ <section property="bibo:hasPart" resource="#ldpr-pagingGET-next-reqd" typeof="bibo:Chapter" id="ldpr-pagingGET-next-reqd"><h4 resource="#h-ldpr-pagingget-next-reqd" id="h-ldpr-pagingget-next-reqd" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.12 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST" class="rfc2119">MUST</em>
+ provide a <a class="internalDFN" href="#dfn-next-page-link">next page link</a>
+ in responses to <code>GET</code> requests with any <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">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.
+ </span></h4><!-- Was 4.10.2.2 / #ldpr-pagingGET-next-reqd-change -->
+ </section>
+
+ <section property="bibo:hasPart" resource="#ldpr-pagingGET-lastnext-prohibited" typeof="bibo:Chapter" id="ldpr-pagingGET-lastnext-prohibited"><h4 resource="#h-ldpr-pagingget-lastnext-prohibited" id="h-ldpr-pagingget-lastnext-prohibited" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.13 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST NOT" class="rfc2119">MUST NOT</em>
+ provide a <a class="internalDFN" href="#dfn-next-page-link">next page link</a>
+ in responses to <code>GET</code> requests with the final <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">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 class="internalDFN" href="#dfn-page-sequence">page sequence</a>
+ as currently known by the server.
+ </span></h4></section><!-- Was 4.10.2.2.1 / #ldpr-pagingGET-lastnext-prohibited -->
+
+ <section property="bibo:hasPart" resource="#ldpr-pagingGET-prev-allowed" typeof="bibo:Chapter" id="ldpr-pagingGET-prev-allowed"><h4 resource="#h-ldpr-pagingget-prev-allowed" id="h-ldpr-pagingget-prev-allowed" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.14 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">MAY</em>
+ provide a <a class="internalDFN" href="#dfn-previous-page-link">previous page link</a>
+ in responses to <code>GET</code> requests with any <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">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.
+ </span></h4></section><!-- Was 4.10.2.2.2 / #ldpr-pagingGET-prev-allowed -->
+
+ <section property="bibo:hasPart" resource="#ldpr-pagingGET-firstprev-prohibited" typeof="bibo:Chapter" id="ldpr-pagingGET-firstprev-prohibited"><h4 resource="#h-ldpr-pagingget-firstprev-prohibited" id="h-ldpr-pagingget-firstprev-prohibited" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.15 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST NOT" class="rfc2119">MUST NOT</em>
+ provide a <a class="internalDFN" href="#dfn-previous-page-link">previous page link</a>
+ in responses to <code>GET</code> requests with the <em>first</em> <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">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 class="internalDFN" href="#dfn-page-sequence">page sequence</a>
+ as currently known by the server.
+ </span></h4></section><!-- Was 4.10.2.2.3 / #ldpr-pagingGET-firstprev-prohibited -->
+
+ <section property="bibo:hasPart" resource="#ldpr-pagingGET-page-type-reqd" typeof="bibo:Chapter" id="ldpr-pagingGET-page-type-reqd"><h4 resource="#h-ldpr-pagingget-page-type-reqd" id="h-ldpr-pagingget-page-type-reqd" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.16 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST" class="rfc2119">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 href="#bib-RFC5988" class="bibref">RFC5988</a></cite>]
+ in responses to <code>GET</code> requests with any <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">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.
+ </span></h4></section><!-- Was 4.10.2.4 / #ldpr-pagingGET-page-type-reqd -->
+
+ <section property="bibo:hasPart" resource="#ldpr-pagingGET-abandon-pageseq" typeof="bibo:Chapter" id="ldpr-pagingGET-abandon-pageseq"><h4 resource="#h-ldpr-pagingget-abandon-pageseq" id="h-ldpr-pagingget-abandon-pageseq" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.17 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="SHOULD" class="rfc2119">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 class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">in-sequence page resources</a> with appropriate
+ paging link response headers, for example, rel="first".
+ </span></h4></section><!-- #ldpr-pagingGET-abandon-pageseq -->
+
+ <section property="bibo:hasPart" resource="#ldpr-units-triple-count" typeof="bibo:Chapter" id="ldpr-units-triple-count"><h4 resource="#h-ldpr-units-triple-count" id="h-ldpr-units-triple-count" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.18 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="SHOULD" class="rfc2119">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.
+ </span></h4>
+ </section>
+
+ <section property="bibo:hasPart" resource="#ldpr-units-kbyte-count" typeof="bibo:Chapter" id="ldpr-units-kbyte-count"><h4 resource="#h-ldpr-units-kbyte-count" id="h-ldpr-units-kbyte-count" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.19 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="SHOULD" class="rfc2119">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.
+ </span></h4>
+ </section>
+
+ <section property="bibo:hasPart" resource="#ldpr-pagesize-multiple-units" typeof="bibo:Chapter" id="ldpr-pagesize-multiple-units"><h4 resource="#h-ldpr-pagesize-multiple-units" id="h-ldpr-pagesize-multiple-units" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">6.2.20 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST" class="rfc2119">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).
+ </span></h4>
+ </section>
+
+ <!-- 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 property="bibo:hasPart" resource="#ldpc" typeof="bibo:Chapter" id="ldpc">
+<!--OddPage--><h2 resource="#h-ldpc" id="h-ldpc"><span property="xhv:role" resource="xhv:heading"><span class="secno">7. </span>Linked Data Platform Containers</span></h2>
+
+<section property="bibo:hasPart" resource="#ldpc-general" typeof="bibo:Chapter" id="ldpc-general">
+<h3 resource="#h-ldpc-general" id="h-ldpc-general"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.1 </span>Requirements when paging LDP Containers</span></h3>
+
+ <section property="bibo:hasPart" resource="#ldpc-onsamepage" typeof="bibo:Chapter" id="ldpc-onsamepage"><h4 resource="#h-ldpc-onsamepage" id="h-ldpc-onsamepage" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.1.1 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MUST" class="rfc2119">MUST</em>
+ ensure that the <a class="internalDFN" href="#dfn-membership-triples" title="membership triples">membership triple</a> and
+ <a class="internalDFN" href="#dfn-containment-triples" title="containment triples">containment triple</a> for each member are part of the
+ same <a class="internalDFN" href="#dfn-in-sequence-page-resource">in-sequence page resource</a>, whenever both triples are present in the <a class="internalDFN" href="#dfn-page-sequence">page sequence</a>
+ for a <a class="internalDFN" href="#dfn-paged-resource" title="paged resource">paged <abbr title="Linked Data Platform Container">LDPC</abbr></a>.
+ </span></h4></section>
+
+ <section property="bibo:hasPart" resource="#ldpr-units-record-count" typeof="bibo:Chapter" id="ldpr-units-record-count"><h4 resource="#h-ldpr-units-record-count" id="h-ldpr-units-record-count" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.1.2 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="SHOULD" class="rfc2119">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 class="internalDFN" href="#dfn-paged-resource" title="paged resource">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.
+ </span></h4>
+ </section>
+
+</section>
+
+<section property="bibo:hasPart" resource="#ldpc-informative" typeof="bibo:Chapter" class="informative" id="ldpc-informative">
+<h3 resource="#h-ldpc-informative" id="h-ldpc-informative"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.2 </span>Ordering of container members across pages</span></h3><p><em>This section is non-normative.</em></p>
+
+ <section property="bibo:hasPart" resource="#ldpc-ordering" typeof="bibo:Chapter" id="ldpc-ordering"><h4 resource="#h-ldpc-ordering" id="h-ldpc-ordering" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.2.1 </span>Ordering</span></h4>
+ <p>
+ There are many cases where an ordering of the members of a
+ container is important. [<cite><a href="#bib-LDP" class="bibref">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. Applications that require a way for clients to
+ specify the order, can do so with application-specific extensions.
+ </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 class="internalDFN" href="#dfn-ldp-paging-server">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 class="internalDFN" href="#dfn-in-sequence-page-resource" title="In-sequence page resource">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 href="#bib-LDP" class="bibref">LDP</a></cite>] section 5.1:
+ </p>
+
+<em>Request</em>
+<div class="example"><div class="example-title"><span>Example 12</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 13</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 14</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 15</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 class="internalDFN" href="#dfn-in-sequence-page-resource">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 <abbr title="Linked Data Platform Resources">LDPRs</abbr> 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 property="bibo:hasPart" resource="#ldpc-HTTP_GET" typeof="bibo:Chapter" id="ldpc-HTTP_GET">
+<h3 resource="#h-ldpc-http_get" id="h-ldpc-http_get"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.3 </span>HTTP GET requirements for member ordering across pages</span></h3>
+
+ <p>
+ If a <a class="internalDFN" href="#dfn-ldp-paging-server">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 class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">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 property="bibo:hasPart" resource="#ldpc-sort-criteria-consistent" typeof="bibo:Chapter" id="ldpc-sort-criteria-consistent"><h4 resource="#h-ldpc-sort-criteria-consistent" id="h-ldpc-sort-criteria-consistent" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.3.1 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <em title="MAY" class="rfc2119">MAY</em>
+ communicate the order used to allocate <abbr title="Linked Data Platform Container">LDPC</abbr> members to <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">pages</a>.
+ If they choose to communicate the order, they <em title="MUST" class="rfc2119">MUST</em> respond
+ consistently to retrieval requests for each <a class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">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 class="internalDFN" href="#dfn-in-sequence-page-resource" title="in-sequence page resource">pages</a> would be undefined.
+ </span></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 class="internalDFN" href="#dfn-paged-resource">paged resource</a>,
+ for example, sequences that have differing sort criteria, and they can be offered serially or concurrently.
+ </blockquote>
+
+ <section property="bibo:hasPart" resource="#ldpc-sort-criteria-link" typeof="bibo:Chapter" id="ldpc-sort-criteria-link"><h4 resource="#h-ldpc-sort-criteria-link" id="h-ldpc-sort-criteria-link" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.3.2 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em title="MUST" class="rfc2119">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 title="MUST" class="rfc2119">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.
+ </span></h4></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
+
+ <section property="bibo:hasPart" resource="#ldpc-sort-criteria-content" typeof="bibo:Chapter" id="ldpc-sort-criteria-content"><h4 resource="#h-ldpc-sort-criteria-content" id="h-ldpc-sort-criteria-content" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.3.3 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em title="MUST" class="rfc2119">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 title="MUST" class="rfc2119">MUST</em> be as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause
+ [<cite><a href="#bib-sparql11-query" class="bibref">sparql11-query</a></cite>].
+ </span></h4></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
+
+ <section property="bibo:hasPart" resource="#ldpc-sortliteraltype" typeof="bibo:Chapter" id="ldpc-sortliteraltype"><h4 resource="#h-ldpc-sortliteraltype" id="h-ldpc-sortliteraltype" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.3.4 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em title="MUST" class="rfc2119">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 href="#bib-sparql11-query" class="bibref">sparql11-query</a></cite>]. Other data types
+ can be used, but LDP
+ assigns no meaning to them and interoperability will be limited.
+ </span></h4></section><!-- Was 5.3.3 / #ldpc-5_3_3 -->
+
+ <section property="bibo:hasPart" resource="#ldpc-sortorder" typeof="bibo:Chapter" id="ldpc-sortorder"><h4 resource="#h-ldpc-sortorder" id="h-ldpc-sortorder" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.3.5 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em title="MUST" class="rfc2119">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.</span></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 property="bibo:hasPart" resource="#ldpc-sortcollation" typeof="bibo:Chapter" id="ldpc-sortcollation"><h4 resource="#h-ldpc-sortcollation" id="h-ldpc-sortcollation" class="normal"><span property="xhv:role" resource="xhv:heading"><span class="secno">7.3.6 </span>
+ <a class="internalDFN" href="#dfn-ldp-paging-server" title="LDP Paging server">LDP Paging servers</a> <a href="#ldpc-sort-criteria-consistent">communicating order</a> <em title="MAY" class="rfc2119">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 title="MUST" class="rfc2119">MUST</em> be omitted for comparisons
+ involving <a class="internalDFN" href="#dfn-page-ordering-values" title="page-ordering values">page-ordering values</a> for which [<cite><a href="#bib-sparql11-query" class="bibref">sparql11-query</a></cite>] does not use collations.</span></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 class="internalDFN" href="#dfn-page-ordering-values" title="page-ordering values">page-ordering values</a> are strings or simple literals [<cite><a href="#bib-sparql11-query" class="bibref">sparql11-query</a></cite>], the
+ resulting order is as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause
+ [<cite><a href="#bib-sparql11-query" class="bibref">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 class="internalDFN" href="#dfn-page-ordering-values" title="page-ordering values">page-ordering values</a> are strings or simple literals
+ [<cite><a href="#bib-sparql11-query" class="bibref">sparql11-query</a></cite>], the
+ resulting order is as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause
+ [<cite><a href="#bib-sparql11-query" class="bibref">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 -->
+
+<section property="bibo:hasPart" resource="#security" typeof="bibo:Chapter" class="informative" id="security">
+<!--OddPage--><h2 resource="#h-security" id="h-security"><span property="xhv:role" resource="xhv:heading"><span class="secno">8. </span>Security Considerations</span></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 property="bibo:hasPart" resource="#ldpr-impl" typeof="bibo:Chapter" class="appendix informative" id="ldpr-impl">
+
+<!--OddPage--><h2 resource="#h-ldpr-impl" id="h-ldpr-impl"><span property="xhv:role" resource="xhv:heading"><span class="secno">A. </span>Paging <abbr title="Linked Data Platform Resources">LDPRs</abbr> without maintaining server-side session state</span></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 href="#bib-WEBARCH" class="bibref">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 class="internalDFN" href="#dfn-next-page-link">next page link</a>
+ of each <a class="internalDFN" href="#dfn-in-sequence-page-resource">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 class="internalDFN" href="#dfn-next-page-link">next page link</a> in the first page might be:
+ </p>
+ <div class="example"><div class="example-title"><span>Example 16</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 class="internalDFN" href="#dfn-backward-traversal">backward traversal</a>, then the second page's
+ <a class="internalDFN" href="#dfn-previous-page-link">previous page link</a> might be:
+ </p>
+ <div class="example"><div class="example-title"><span>Example 17</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 property="bibo:hasPart" resource="#acks" typeof="bibo:Chapter" class="appendix informative" id="acks">
+<!--OddPage--><h2 resource="#h-acks" id="h-acks"><span property="xhv:role" resource="xhv:heading"><span class="secno">B. </span>Acknowledgements</span></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 property="bibo:hasPart" resource="#history" typeof="bibo:Chapter" class="appendix informative" id="history">
+<!--OddPage--><h2 resource="#h-history" id="h-history"><span property="xhv:role" resource="xhv:heading"><span class="secno">C. </span>Change History</span></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>Sections previously marked "at risk" are no longer marked (the content remains in this document)
+ <a href="#ldpr-cli-paging">client should be prepared for pages</a>, hint units (<a href="#ldpr-units-kbyte-count">max-kbytes-count</a>
+ and
+ <a href="#ldpr-units-record-count">max-member-count</a>) and <a href="#ldpr-pagesize-multiple-units">honor all size hints</a>.
+ </li>
+ <li>Removed "Feature at Risk" content for <code>2NN Contents of Related</code> status code and usage.</li>
+</ul>
+<!--
+<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> -->
+
+<!--
+<h2>Detailed history</h2> -->
+
+<!-- <blockquote><em><a href="http://www.w3.org/TR/2014/CR-ldp-paging-20141216/">Candidate Recommendation Draft</a></em></blockquote> wah -->
+<!--
+<ul>
+ <li>2015-01-26 - Align usage of Link: rel= to not use single quotes per RFC5988 (SS)</li>
+</ul>
+-->
+
+<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
+<!--
+<ul>
+ <li>2014-11-05 - Removed "at risk" content for "2NN Contents of Related" status code and usage (SS) </li>
+ <li>2014-11-05 - Removed "at risk" markers for max-member-count and max-kbyte-count, honor all hints and clients should expect paging (SS) </li>
+ <li>2014-10-10 - Clarified "new protocol" in 4.2, hyper-linked max-member-count to LDPCs per 10/10 public comments email (JA) </li>
+ <li>2014-09-26 - Added non-norm items about extensions to supply client requested ordering (SS) </li>
+</ul>
+
+<blockquote><em><a href="http://www.w3.org/TR/2014/WD-ldp-paging-20140909/">Last Call Draft - 9 September 2014</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 property="bibo:hasPart" resource="#references" typeof="bibo:Chapter" id="references" class="appendix"><!--OddPage--><h2 resource="#h-references" id="h-references"><span property="xhv:role" resource="xhv:heading"><span class="secno">D. </span>References</span></h2><section property="bibo:hasPart" resource="#normative-references" typeof="bibo:Chapter" id="normative-references"><h3 resource="#h-normative-references" id="h-normative-references"><span property="xhv:role" resource="xhv:heading"><span class="secno">D.1 </span>Normative references</span></h3><dl resource="" class="bibliography"><dt id="bib-LDP">[LDP]</dt><dd>Steve Speicher; John Arwe; Ashok Malhotra. <a property="dc:requires" href="http://www.w3.org/TR/ldp/"><cite>Linked Data Platform 1.0</cite></a>. 26 February 2015. W3C Recommendation. URL: <a property="dc:requires" href="http://www.w3.org/TR/ldp/">http://www.w3.org/TR/ldp/</a>
+</dd><dt id="bib-REL-CANONICAL">[REL-CANONICAL]</dt><dd>M. Ohye; J. Kupke. <a property="dc:requires" href="http://tools.ietf.org/html/rfc6596"><cite>The Canonical Link Relation</cite></a>. Informational. URL: <a property="dc:requires" href="http://tools.ietf.org/html/rfc6596">http://tools.ietf.org/html/rfc6596</a>
+</dd><dt id="bib-RFC2119">[RFC2119]</dt><dd>S. Bradner. <a property="dc:requires" href="https://tools.ietf.org/html/rfc2119"><cite>Key words for use in RFCs to Indicate Requirement Levels</cite></a>. March 1997. Best Current Practice. URL: <a property="dc:requires" href="https://tools.ietf.org/html/rfc2119">https://tools.ietf.org/html/rfc2119</a>
+</dd><dt id="bib-RFC5988">[RFC5988]</dt><dd>M. Nottingham. <a property="dc:requires" href="https://tools.ietf.org/html/rfc5988"><cite>Web Linking</cite></a>. October 2010. Proposed Standard. URL: <a property="dc:requires" href="https://tools.ietf.org/html/rfc5988">https://tools.ietf.org/html/rfc5988</a>
+</dd><dt id="bib-RFC7230">[RFC7230]</dt><dd>R. Fielding, Ed.; J. Reschke, Ed.. <a property="dc:requires" href="https://tools.ietf.org/html/rfc7230"><cite>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</cite></a>. June 2014. Proposed Standard. URL: <a property="dc:requires" href="https://tools.ietf.org/html/rfc7230">https://tools.ietf.org/html/rfc7230</a>
+</dd><dt id="bib-RFC7231">[RFC7231]</dt><dd>R. Fielding, Ed.; J. Reschke, Ed.. <a property="dc:requires" href="https://tools.ietf.org/html/rfc7231"><cite>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</cite></a>. June 2014. Proposed Standard. URL: <a property="dc:requires" href="https://tools.ietf.org/html/rfc7231">https://tools.ietf.org/html/rfc7231</a>
+</dd><dt id="bib-RFC7232">[RFC7232]</dt><dd>R. Fielding, Ed.; J. Reschke, Ed.. <a property="dc:requires" href="https://tools.ietf.org/html/rfc7232"><cite>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</cite></a>. June 2014. Proposed Standard. URL: <a property="dc:requires" href="https://tools.ietf.org/html/rfc7232">https://tools.ietf.org/html/rfc7232</a>
+</dd><dt id="bib-RFC7238">[RFC7238]</dt><dd>J. Reschke. <a property="dc:requires" href="https://tools.ietf.org/html/rfc7238"><cite>The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)</cite></a>. June 2014. Experimental. URL: <a property="dc:requires" href="https://tools.ietf.org/html/rfc7238">https://tools.ietf.org/html/rfc7238</a>
+</dd><dt id="bib-RFC7240">[RFC7240]</dt><dd>J. Snell. <a property="dc:requires" href="https://tools.ietf.org/html/rfc7240"><cite>Prefer Header for HTTP</cite></a>. June 2014. Proposed Standard. URL: <a property="dc:requires" href="https://tools.ietf.org/html/rfc7240">https://tools.ietf.org/html/rfc7240</a>
+</dd><dt id="bib-WEBARCH">[WEBARCH]</dt><dd>Ian Jacobs; Norman Walsh. <a property="dc:requires" 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 property="dc:requires" href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a>
+</dd><dt id="bib-sparql11-query">[sparql11-query]</dt><dd>Steven Harris; Andy Seaborne. <a property="dc:requires" href="http://www.w3.org/TR/sparql11-query/"><cite>SPARQL 1.1 Query Language</cite></a>. 21 March 2013. W3C Recommendation. URL: <a property="dc:requires" href="http://www.w3.org/TR/sparql11-query/">http://www.w3.org/TR/sparql11-query/</a>
+</dd></dl></section><section property="bibo:hasPart" resource="#informative-references" typeof="bibo:Chapter" id="informative-references"><h3 resource="#h-informative-references" id="h-informative-references"><span property="xhv:role" resource="xhv:heading"><span class="secno">D.2 </span>Informative references</span></h3><dl resource="" class="bibliography"><dt id="bib-LDP-PAGING-TESTSUITE">[LDP-PAGING-TESTSUITE]</dt><dd>R. Garcia-Castro; F. Serena. <a property="dc:references" href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-paging-testsuite.html"><cite>Linked Data Platform Paging 1.0 Test Cases</cite></a>. Editor's Draft of Working Group Note. URL: <a property="dc:references" href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-paging-testsuite.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-paging-testsuite.html</a>
+</dd><dt id="bib-LDP-UCR">[LDP-UCR]</dt><dd>Steve Battle; Steve Speicher. <a property="dc:references" 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 property="dc:references" 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>Various. <a property="dc:references" href="http://en.wikipedia.org/wiki/Isolation_%28database_systems%29#Non-repeatable_reads"><cite>Wikipedia: Isolation (database systems)</cite></a>. N/A. URL: <a property="dc:references" href="http://en.wikipedia.org/wiki/Isolation_%28database_systems%29#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>Various. <a property="dc:references" href="http://en.wikipedia.org/wiki/Isolation_%28database_systems%29#Read_committed"><cite>Wikipedia: Isolation (database systems)</cite></a>. N/A. URL: <a property="dc:references" href="http://en.wikipedia.org/wiki/Isolation_%28database_systems%29#Read_committed">http://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed</a>
+</dd><dt id="bib-RFC5005">[RFC5005]</dt><dd>M. Nottingham. <a property="dc:references" href="https://tools.ietf.org/html/rfc5005"><cite>Feed Paging and Archiving</cite></a>. September 2007. Proposed Standard. URL: <a property="dc:references" href="https://tools.ietf.org/html/rfc5005">https://tools.ietf.org/html/rfc5005</a>
+</dd><dt id="bib-turtle">[turtle]</dt><dd>Eric Prud'hommeaux; Gavin Carothers. <a property="dc:references" href="http://www.w3.org/TR/turtle/"><cite>RDF 1.1 Turtle</cite></a>. 25 February 2014. W3C Recommendation. URL: <a property="dc:references" 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