Factored out paging and sorting into separate spec LDP-Paging
authorsspeiche
Tue, 18 Feb 2014 15:28:39 -0500
changeset 497 67f04abb73e6
parent 496 94420c5678ae
child 498 9ab1339e0013
Factored out paging and sorting into separate spec LDP-Paging
ldp-paging.html
ldp-paging.ttl
ldp.html
ldp.ttl
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-paging.html	Tue Feb 18 15:28:39 2014 -0500
@@ -0,0 +1,972 @@
+
+<!DOCTYPE html>
+<!-- 
+	TODO: Missing link header for equivalent of ldp:pageOf? Need to verify.
+	TODO: Example 11 is missing ldp:contains, true?  Omit due to GET on page resource, should make it more clear.
+	TODO: Paging intro: add 3rd example showing header link	age amongst pages and (HEAD on) the base resource.
+     Maybe also insert HEAD on base as new first example instead of relying on text alone.
+    TODO: Missing namespace definition clause?
+ -->
+<html>
+  <head>
+    <title>Linked Data Platform Paging 1.0</title>
+    <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
+    <!-- 
+      === NOTA BENE ===
+      For the three scripts below, if your spec resides on dev.w3 you can check them
+      out in the same tree and use relative links so that they'll work offline,
+     -->
+    <script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script> 
+    <script class='remove'>
+      var respecConfig = {
+          // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+          specStatus:           "ED",
+          
+          // the specification's short name, as in http://www.w3.org/TR/short-name/
+          shortName:            "ldp-paging",
+
+          // if your specification has a subtitle that goes below the main
+          // formal title, define it here
+          // subtitle   :  "an excellent document",
+
+          // if you wish the publication date to be other than today, set this
+          publishDate:  "",
+
+          // if the specification's copyright date is a range of years, specify
+          // the start date here:
+          // copyrightStart: "2005"
+
+          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+          // and its maturity status
+          previousPublishDate:  "2013-07-30",
+          previousMaturity:  	"LC",
+          previousURI: 			"http://www.w3.org/TR/2013/WD-ldp-20130730/",
+
+          // if there a publicly available Editor's Draft, this is the link
+          edDraftURI:           "http://www.w3.org/2012/ldp/hg/ldp-paging.html",
+
+          // if this is a LCWD, uncomment and set the end of its review period
+          lcEnd: "2013-09-02",
+          
+          // Only include h1 and h2 level
+          maxTocLevel: 2,
+
+          // if you want to have extra CSS, append them to this list
+          // it is recommended that the respec.css stylesheet be kept
+          //extraCSS:             ["https://dvcs.w3.org/hg/ldpwg/css/respec.css"],
+
+          // editors, add as many as you like
+          // only "name" is required
+          editors:  [
+              { name: "Steve Speicher", url: "http://stevespeicher.blogspot.com",
+                company: "IBM Corporation", companyURL: "http://ibm.com/" },
+              { name: "John Arwe", url: "https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?userid=120000CAW7",
+                company: "IBM Corporation", companyURL: "http://ibm.com/" },
+			  {name: "Ashok Malhotra", url: "mailto:[email protected]",
+			    company: "Oracle Corporation", companyURL: "http://www.oracle.com" },
+          ],
+
+          // authors, add as many as you like. 
+          // This is optional, uncomment if you have authors as well as editors.
+          // only "name" is required. Same format as editors.
+
+          //authors:  [
+          //    { name: "Your Name", url: "http://example.org/",
+          //      company: "Your Company", companyURL: "http://example.com/" },
+          //],
+          
+          // name of the WG
+          wg:           "Linked Data Platform Working Group",
+          
+          // URI of the public WG page
+          wgURI:        "http://www.w3.org/2012/ldp",
+          
+          // name (without the @w3c.org) of the public mailing to which comments are due
+          wgPublicList: "public-ldp-comments",
+          
+          // URI of the patent status for this WG, for Rec-track documents
+          // !!!! IMPORTANT !!!!
+          // This is important for Rec-track documents, do not copy a patent URI from a random
+          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+          // Team Contact.
+          wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/55082/status",
+          doRDFa: "1.1",
+			localBiblio:  {
+				"HTTPBIS-SEMANTICS": {
+					title:    "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"
+				,   href:     "http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics/"
+				,   authors:  [
+						"R. Fielding"
+					,   "J. Reschke"
+					]
+				,   status:   "In Last Call"
+				,   publisher:  "IETF"
+				},
+				"RFC2817": {
+					title:    "Upgrading to TLS Within HTTP/1.1"
+				,   href:     "http://tools.ietf.org/html/rfc2817"
+				,   authors:  [
+						"R. Khare"
+					,   "S. Lawrence"
+					]
+				,   status:   "Proposed Standard"
+				,   publisher:  "IETF"
+				},
+				"RFC5005": {
+					title:    "Feed Paging and Archiving"
+				,   href:     "http://tools.ietf.org/html/rfc5005"
+				,   authors:  [
+						"M. Nottingham"
+					]
+				,   status:   "Proposed Standard"
+				,   publisher:  "IETF"
+				}
+			},
+      };
+    </script>
+    <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>
+  </head>
+<body>
+<section id='abstract'>
+This document describes a model for clients and servers to be able to efficiently retrieve large Linked Data Platform
+Resources representations by splitting up the responses into separate URL-addressable page resources.
+</section>
+ 
+<section class="informative" id="intro">
+<h1>Introduction</h1> 
+	<p>This specification provides a widely re-usable pattern to deal with large resources.  
+	Depending on the server’s capabilities, a GET request on a <a title="Paged resource">resource</a> can
+	be redirected to a <a title="Single-page resource">subset of the resource (one page)</a>, that provides access to subsequent pages 
+	(see <a href="#ldpr-Paging" class="sectionRef"></a>). 
+	</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> [[LDP-UCR]] 
+	and <a href="#base-specs" class="sectionRef"></a>.</p>
+</section>
+	
+<section id="terms">
+<h1>Terminology</h1>
+
+<p>Terminology is based on W3C's Architecture of the World Wide Web [[WEBARCH]] and Hyper-text Transfer Protocol [[HTTP11]].
+</p>
+  <dl class="glossary">	
+	<dt><dfn>Paged resource</dfn></dt>
+	<dd>A LDP-RS whose representation may be too large to fit in a single HTTP response, for which an
+	LDP server offers a sequence of single-page <a title="Linked Data Platform RDF Source">LDP-RSs</a>.  
+	When the representations of the sequence's resources
+	are combined by a client, the client has a (potentially incomplete or incoherent) copy of the paged resource's
+	state.  If a paged resource <var>P</var> is a LDP-RS and is broken into a sequence of pages
+	(single-page resources) <var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>,
+	the representation of each <var>P<sub>i</sub></var> contains
+	a subset of the triples in <var>P</var>.
+	LDP allows paging of resources other than <a title="Linked Data Platform RDF Source">LDP-RSs</a>, 
+	but does not specify how clients combine
+	their representations.  See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.  For readers
+	familiar with paged feeds [[RFC5005]], 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></dd>
+	
+	<dt><dfn>Single-page resource</dfn></dt>
+	<dd>One of a sequence of related <a title="Linked Data Platform RDF Source">LDP-RSs</a>
+	<var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>, 
+	each of which contains a subset of the state
+	of another resource <var>P</var>.  <var>P</var> is called the paged resource.
+	For readers
+	familiar with paged feeds [[RFC5005]], a single-page resource is similar to a feed document and the same
+	coherency/completeness considerations apply.
+	<a href="#ldpr-pagingGET-sequences-change">LDP provides no guarantees that the sequence is stable</a>.
+	<p>
+	Note: the choice of terms was designed to help authors and readers clearly differentiate between
+	the <a title="Paged resource"><em>resource being paged</em></a>, and the 
+	<a title="Single-page resource"><em>individual page resources</em></a>, 
+	in cases where both are mentioned in
+	close proximity.  
+	<p></p></dd>
+	
+	<dt><dfn>first page link</dfn></dt>
+	<dd>A link to the first <a title="Single-page resource">single-page resource</a>
+	of a <a title="Paged resource">paged resource</a> <var>P</var>.  Syntactically, a
+	HTTP <code>Link &lt;<var>P<sub>1</sub></var>&gt;; rel='first'</code>
+	header [[!RFC5988]].
+	<p></p></dd>
+	
+	<dt><dfn>next page link</dfn></dt>
+	<dd>A link to the next <a title="Single-page resource">single-page resource</a> 
+	of a <a title="Paged resource">paged resource</a> <var>P</var>.  Syntactically, a
+	HTTP <code>Link &lt;<var>P<sub>i</sub></var>&gt;; rel='next'</code>
+	header [[!RFC5988]] where the target URI is <var>P<sub>i=2...n</sub></var>.
+	<p></p></dd>
+	
+	<dt><dfn>last page link</dfn></dt>
+	<dd>A link to the last <a title="Single-page resource">single-page resource</a>
+	of a <a title="Paged resource">paged resource</a> <var>P</var>.  Syntactically, a
+	HTTP <code>Link &lt;<var>P<sub>n</sub></var>&gt;; rel='last'</code>
+	header [[!RFC5988]].
+	<p></p></dd>
+	
+	<dt><dfn>previous page link</dfn></dt>
+	<dd>A link to the previous <a title="Single-page resource">single-page resource</a> 
+	of a <a title="Paged resource">paged resource</a> <var>P</var>.  Syntactically, a
+	HTTP <code>Link &lt;<var>P<sub>i</sub></var>&gt;; rel='prev'</code>
+	header [[!RFC5988]] where the target URI is <var>P<sub>i=1...n-1</sub></var>.
+	<p></p></dd>
+	
+  </dl>
+
+<section id="conventions">
+<h2>Conventions Used in This Document</h2>
+
+	<p>Sample resource representations are provided in <code>text/turtle</code>
+		format [[turtle]].</p>
+	<p>Commonly used namespace prefixes:</p>
+	<pre style="word-wrap: break-word; white-space: pre-wrap;">	@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
+	@prefix foaf:     &lt;http://xmlns.com/foaf/0.1/&gt;.
+	@prefix rdf:     &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
+	@prefix ldp:     &lt;http://www.w3.org/ns/ldp#&gt;.
+	@prefix ldp-paging:     &lt;http://www.w3.org/ns/ldp-paging#&gt;.
+	@prefix xsd:     &lt;http://www.w3.org/2001/XMLSchema#&gt;.</pre>
+</section>
+</section>
+    
+<section id='conformance'>
+
+<p>The status of the sections of Linked Data Platform Paging 1.0 (this document) is as follows:</p>
+<p><em>TODO</em>: Update this section list</p>
+<ul>
+  <li>1. Introduction: <b>non-normative</b></li>
+  <li>2. Terminology: <b>normative</b></li>
+  <li>3. Conformance: <b>normative</b></li>
+  <li>4. Linked Data Platform Resources: <b>normative</b></li>
+  <li>5. Linked Data Platform Containers: <b>normative</b></li>
+  <li>6. HTTP Header Definitions: <b>normative</b></li>
+  <li>A. Acknowledgements: <b>non-normative</b></li> 
+  <li>B.1 Normative references: <b>normative</b></li>
+  <li>B.2 Non-normative references: <b>non-normative</b></li>
+</ul>
+
+<p>A conforming <b><dfn>LDP Paging client</dfn></b> is a conforming LDP client [[!LDP]] that follows the rules defined by LDP.
+</p>
+
+<p>A conforming <b><dfn>LDP Paging server</dfn></b> is a conforming LDP server [[!LDP]] that follows the rules defined by LDP.</p>
+</section>
+
+<section id="ldppclient">
+<h1>Linked Data Platform Paging Clients</h1>
+<p>All of the following are conformance rules for <a title="LDP Paging client">LDP Paging Clients</a>.
+</p>
+<section><h2>General</h2>
+
+	<section id="ldpp-server-initiated"><h2 class="normal"><a title="LDP Paging client">LDP Paging clients</a> MUST
+	be paging-aware in cases where LDP Paging servers initiate paging.
+	</h2>
+	<p><em>TODO</em>: Confirm this client MUST for server-initiated paging</p>
+	</section>
+	
+</section>
+</section> <!-- Client constraints -->
+
+<section id="ldpr">
+<h1>Linked Data Platform Resources</h1>
+
+<section class="informative" id="ldpr-informative">
+<h2>Introduction</h2>
+	<p>Linked Data Platform Resources (<dfn><abbr title="Linked Data Platform Resources">LDPRs</abbr></dfn>) are HTTP resources
+		that conform to the simple patterns and conventions in this section.
+		HTTP requests to access, modify, create or delete LDPRs are accepted
+		and processed by <a title="LDP server">LDP servers</a>. Most LDPRs are domain-specific resources
+		that contain data for an entity in some domain, which could be
+		commercial, governmental, scientific, religious, or other.</p>
+	<p>Some of the rules defined in this document provide
+		clarification and refinement of the base Linked Data rules [[LINKED-DATA]];
+		others address additional needs.</p>
+	<p>The following sections define the conformance rules for LDP servers when serving LDPRs.
+		This document also explains <a href="#ldpr-Paging">how a server paginates an LDP-RS's representation</a> if it gets too big.
+		Companion non-normative documents describe additional guidelines for use when interacting with LDPRs. 
+	</p>
+</section>
+
+<section id="ldpr-Paging">
+<h2>Paging</h2>
+
+<section class="informative" id="ldpr-PagingIntro">
+
+<h3>Introduction</h3>
+	<p>It sometimes happens that a
+		resource is too large to reasonably transmit its representation in a
+		single HTTP response.  
+		To address this problem, servers should support a technique called Paging.  
+		When a client retrieves such a resource, the server redirects the client to a "first page" resource, and includes in its response
+		a link to the next part of the resource's state, all at a URLs of the server's choosing.
+		The triples in the representation of the <a title="Single-page resource">each page of an LDPR</a>
+		are typically a subset of the triples from the <a title="Paged resource">paged resource</a>.
+	</p>
+	<p><a title="LDP server">LDP servers</a> may respond to requests for a
+		resource by redirecting to the first page of the resource and, with that, returning 
+		a <code>Link &lt;next-page-URL&gt;;type='next'</code> header containing the URL for the next page.
+		Clients inspect each response for the link header to see if additional pages
+		are available; paging does not affect the choice of HTTP status code.
+		Note that paging is lossy, as described in [[RFC5005]], and so (as stated there)
+		clients should not make any assumptions about a set of pages being a complete or 
+		coherent snapshot of a resource's state.</p>
+	<p>
+		Looking at an example resource representing Example Co.'s customer
+		relationship data, identified by the URI <code>http://example.org/customer-relations</code>,
+		we’ll split the response across two pages.  
+		The client 
+		retrieves <code>http://example.org/customer-relations</code>, and
+		the server responds with <a href="#atrisk-333">status code <code>333 (Returning Related)</code></a>, 
+		a <code>Location: http://example.org/customer-relations?page1</code> HTTP response header,
+		and the following representation:
+	</p>
+
+<pre class="example" id="ldpc-ex-page1"># The following is the representation of
+#    http://example.org/customer-relations?page1
+#    Requests on the URI will result in responses that include the following HTTP header
+#       Link: &lt;http://example.org/customer-relations?p=2&gt;; rel='next'
+#    This Link header is how clients discover the URI of the next page in sequence,
+#    and that the resource supports paging.
[email protected] rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
[email protected] &lt;http://example.org/customer-relations&gt;.
+
+&lt;&gt;
+   a o:CustomerRelations;
+   dcterms:title "The customer information for Example Co.";
+   o:client &lt;#JohnZSmith&gt;, &lt;#BettyASmith&gt;, &lt;#JoanRSmith&gt;. 
+
+&lt;#JohnZSmith&gt;
+   a foaf:Person;
+   o:status o:ActiveCustomer;
+   foaf:name "John Z. Smith".
+&lt;#BettyASmith&gt;
+   a foaf:Person;
+   o:status o:PreviousCustomer;
+   foaf:name "Betty A. Smith".
+ &lt;#JoanRSmith&gt;
+   a foaf:Person;
+   o:status o:PotentialCustomer;
+   foaf:name "Joan R. Smith".</pre>
+
+	<p>
+		Because the server includes a <code>Link: &lt;http://example.org/customer-relations?p=2&gt;; rel='next'</code>
+		response header, and the status code is 3xx (<code>333 (Returning Related)</code> in this case), 
+		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 specificiation. The next page link's target URI is also
+		defined by the server and not this specification.
+	</p>
+	<p>
+		The following example is the result of retrieving
+		the next page; 
+		the server responds with status code <code>200 (OK)</code> and the following representation:
+	</p>
+
+<pre class="example" id="ldpc-ex-page2"># The following is the representation of
+#  http://example.org/customer-relations?p=2
+#
+#  There is no "next" Link in the server's response, so this is the final page.
+#
[email protected] rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
[email protected] &lt;http://example.org/customer-relations&gt;.
+
+&lt;&gt;
+   o:client &lt;#GlenWSmith&gt;, &lt;#AlfredESmith&gt;. 
+ 
+&lt;#GlenWSmith&gt;
+   a foaf:Person;
+   o:status o:ActiveCustomer, o:GoldCustomer;
+   foaf:name "Glen W. Smith".
+
+&lt;#AlfredESmith&gt;
+   a foaf:Person;
+   o:status o:ActiveCustomer, o:BronzeCustomer;
+   foaf:name "Alfred E. Smith".
+ </pre>
+	<p>
+		In this example, there are only two customers provided in the
+		final page.  To indicate this is the last page, the server omits the <code>Link: rel='next'</code> 
+		header in its response.
+	</p>
+	<p>
+		As mentioned above, retrieving all the pages offered by a server gives no guarantee to a client
+		that it knows the entire state of the server.  For example, after the server constructs the
+		the first page representation, another
+		actor could delete <code>client#BettyASmith</code> from the server.  
+	</p>
+</section>
+
+<section id="ldpr-PagingGET">
+<h3>HTTP GET</h3>
+	<p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef"></a> on HTTP <code>GET</code>, 
+		<a title="LDP server">LDP servers</a> that support paging must 
+		also follow the requirements in this section for all <a title="Paged resource">paged resources</a>
+		and their associated <a title="Single-page resource">single-page resources</a>.
+	</p>
+		
+	<section id="ldpr-page-large"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDP-RSs in
+		pages.
+		See <a href="#ldpr-Paging" class="sectionRef"></a> for additional requirements associated with <a title="Paged resource">paged resources</a>.
+	</h2></section><!-- Was 4.2.14 / #ldpr-4_2_14 -->
+	
+	<section id="ldpr-split-any"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY 
+		treat any resource (LDP-RS or not) as a <a title="Paged resource">paged resource</a>. 
+		See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
+	</h2></section><!-- Was 4.2.15 / #ldpr-4_2_15 -->
+
+	<section id="ldpr-pagingGET-sequences-change"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
+		add <a title="Single-page resource">single-page resources</a> to a 
+		<a title="Paged resource">paged resource's</a> sequence over time,
+		but SHOULD only add pages to the end of a sequence.
+		</h2><!-- Was 4.10.2.1 / #ldpr-pagingGET-sequences-change -->
+		<blockquote>Non-normative note: 
+		As a result, clients retrieving any <a title="Single-page resource">single-page resource</a> several times can observe its place in the sequence
+		change as the state of the <a title="Paged resource">paged resource</a> changes.
+		For example, a nominally last page's server might provide a
+		<a>next page link</a> when the page is retrieved.  Similar situations arise when the page sequence 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.
+		</blockquote>
+
+		<section id="ldpr-pagingGET-first-allowed-onpages"><h2 class="normal">
+			<a title="LDP server">LDP servers</a> MAY provide 
+			a <a>first page link</a> when responding to 
+			requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
+		</h2></section><!-- Was 4.10.2.1.1 / #ldpr-pagingGET-sequences-change -->
+	
+		<section id="ldpr-pagingGET-last-allowed-onpages"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
+			provide a <a>last page link</a>
+			in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
+		</h2></section><!-- Was 4.10.2.1.3 / #ldpr-pagingGET-last-allowed-onpages -->
+	</section>
+	
+	<section id="ldpr-pagingGET-next-reqd"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
+		provide a <a>next page link</a>
+		in responses to <code>GET</code> requests with any <a title="Single-page resource">single-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. 
+	</h2><!-- Was 4.10.2.2 / #ldpr-pagingGET-next-reqd-change -->
+	
+		<section id="ldpr-pagingGET-lastnext-prohibited"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST NOT
+			provide a <a>next page link</a>
+			in responses to <code>GET</code> requests with the final <a title="Single-page resource">single-page resource</a> 
+			as the <code>Request-URI</code>.
+			This is the mechanism by which clients can discover the end of the page sequence
+			as currently known by the server.  
+		</h2></section><!-- Was 4.10.2.2.1 / #ldpr-pagingGET-lastnext-prohibited -->
+		
+		<section id="ldpr-pagingGET-prev-allowed"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
+			provide a <a>previous page link</a>
+			in responses to <code>GET</code> requests with any <a title="Single-page resource">single-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.  
+		</h2></section><!-- Was 4.10.2.2.2 / #ldpr-pagingGET-prev-allowed -->
+		
+		<section id="ldpr-pagingGET-firstprev-prohibited"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST NOT
+			provide a <a>previous page link</a>
+			in responses to <code>GET</code> requests with the <em>first</em> <a title="Single-page resource">single-page resource</a> 
+			as the <code>Request-URI</code>.
+			This is one mechanism by which clients can discover the beginning of the page sequence
+			as currently known by the server.  
+		</h2></section><!-- Was 4.10.2.2.3 / #ldpr-pagingGET-firstprev-prohibited -->
+	</section>
+
+	<section id="ldpr-pagingGET-page-type-reqd"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
+		provide an HTTP <code>Link</code>
+		header whose target URI is <code>http://www.w3.org/ns/ldp-paging#Page</code>, and whose link relation type is <code>type</code> [[!RFC5988]]
+		in responses to <code>GET</code> requests with any <a title="Single-page resource">single-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.  
+	</h2></section><!-- Was 4.10.2.4 / #ldpr-pagingGET-page-type-reqd -->
+
+	<div class="atrisk" id="atrisk-333"><p class="atrisktext">Feature At Risk</p>
+		<p>The LDP Working Group proposes incorporation of the features described in the next compliance clause.</p>
+		<ul>
+		<li><p>
+		A <a href="http://lists.w3.org/Archives/Public/www-tag/2013Dec/0041.html">TAG discussion</a> has started,
+		whose goal is to reduce the need for two request-response round trips down to one when retrieving what 
+		turns out to be the first page of a paged resource, by defining a new
+		HTTP response code in the <code>2xx</code> or <code>3xx</code> class that would allow a server to
+		respond to <code>GET request-uri</code> requests with the representation of the first page 
+		(whose URI is <code>first-page-uri</code>, not <code>request-uri</code>) of a multi-page response.
+		</p></li>
+		<li><p>
+		For the purposes of drafting this section, we assume that the 
+		new code's value is <code>333 (Returning Related)</code>,
+		<a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0023.html">an LDP extrapolation from TAG discussions,</a>
+		and its definition is given by 
+		<a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0015.html">Henry Thompson's strawman</a>, with the substitution of 333 for 2xx.
+		Note: nothing prevents servers or clients from using <code>303 See Other</code> responses to 
+		requests for <a title="Paged resource">paged resources</a>.  The only significant difference between 303 and 333 responses
+		is the extra round trip required for the client to retrieve the representation of the first page when using 303.
+		</p></li>
+		<li><p>
+		Once LDP-Paging is a
+		Candidate Recommendation, the LDP WG will make an assessment based on the status at IETF,
+		working with the W3C Director, to either use the newly defined response code 
+		as documented in this section or to revert to a classic 
+		<code>303</code> response pattern.
+		</p></li>
+		</ul>
+	</div>
+		
+	<section id="ldpr-status-code"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD respond 
+		with HTTP status code <code>333 (Returning Related)</code> 
+		to successful <code>GET</code> requests with any <a title="Paged resource">paged resource</a> 
+		as the <code>Request-URI</code>, although any appropriate code MAY be used.
+	</h2></section>
+</section>
+
+</section> <!-- h2 -->
+
+</section> <!-- h1 -->
+
+<section id="ldpc">
+<h1>Linked Data Platform Containers</h1>
+
+<section class="informative" id="ldpc-informative">		
+<h2>Introduction</h2>
+	<p>Many HTTP applications and sites have organizing
+		concepts that partition the overall space of resources into smaller
+		containers. Blog posts are grouped into blogs, wiki pages are grouped
+		into wikis, and products are grouped into catalogs. Each resource
+		created in the application or site is created within an instance of
+		one of these container-like entities, and users can list the existing
+		artifacts within one. LDP Paging Containers answer some basic questions, which
+		are:</p>
+	<ol>
+		<li>How	is the order of the container entries expressed?</li>
+	</ol>
+
+	<section id="ldpc-ordering"><h2 class="normal">Ordering</h2>
+	<p>
+		There are many cases where an ordering of the members of the
+		container is important. LDPC 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:value</code> predicate is present for each
+		member, so the client can easily order the members according to the
+		value of that property. In this way, LDPC avoids the use of RDF
+		constructs like Seq and List for expressing order.
+	</p>
+	<p>
+		Order becomes more important for <a title="LDP server">LDP servers</a> when containers are
+		paginated. If the server does not respect ordering when constructing
+		pages, the client would be forced to retrieve all pages before
+		sorting the members, which would defeat the purpose of pagination. 
+		In cases where ordering is important, an LDPC server exposes all the
+		members on a page with the proper sort order with relation to all 
+		members on the next and previous pages.
+		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 LDPC specification allows servers to assert the ordered list
+		of sort criteria used to sort the members, using the 
+		<code>ldp-paging:containerSortCriteria</code> relation.
+		Each member of the ordered list exposes one <code>ldp-paging:containerSortCriterion</code>, 
+		consisting of a <code>ldp-paging:containerSortOrder</code>, 
+		<code>ldp-paging:containerSortPredicate</code>, and 
+		optionally a <code>ldp-paging:containerSortCollation</code>.
+	</p>
+	<p>Here is an example container described
+		previously, with representation for ordering of the assets:</p>
+<pre class="example" id="ldpc-ex-ordering">
+# 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 &lt;http://example.org/netWorth/nw1/assetContainer/&gt;
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] ldp-paging: &lt;http://www.w3.org/ns/ldp-paging#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
+
+&lt;&gt;
+   a ldp:DirectContainer;
+   dcterms:title "The assets of JohnZSmith";
+   ldp:membershipResource &lt;http://example.org/netWorth/nw1&gt;;
+   ldp:hasMemberRelation o:asset;
+   ldp:insertedContentRelation ldp:MemberSubject.
+
+&lt;?firstPage&gt;
+   a ldp-paging:Page;
+   ldp-paging:pageOf &lt;&gt;;
+   ldp-paging:containerSortCriteria (&lt;#SortValueAscending&gt;).
+
+&lt;#SortValueAscending&gt;
+   a ldp-paging:ContainerSortCriterion;
+   ldp-paging:containerSortOrder ldp-paging:Ascending;
+   ldp-paging:containerSortPredicate o:value.
+
+&lt;http://example.org/netWorth/nw1&gt;
+   a o:NetWorth;
+   o:asset &lt;a1&gt;, &lt;a3&gt;, &lt;a2&gt;.
+
+&lt;a1&gt;
+   a o:Stock;
+   o:value 100.00 .
+&lt;a2&gt;
+   a o:Cash;
+   o:value 50.00 .
+&lt;a3&gt;
+   a o:RealEstateHolding;
+   o:value 300000 .
+</pre>
+		<p>
+			As you can see by the addition of the <code>ldp-paging:ContainerSortCriteria</code> 
+			predicate, the <code>o:value</code> predicate is used
+			to order the page members in ascending order.  It is up to the domain model
+			and server to determine the appropriate predicate to indicate the
+			resource’s order within a page, and up to the client receiving this 
+			representation to use that order in whatever way is appropriate, for 
+			example to sort the data prior to presentation on a user interface. Also
+			as it is possible for a container to have as its members other containers,
+			the ordering approach doesn't change as containers themselves are LDPRs and the
+			properties from the domain model can be leveraged for the sort criteria.
+		</p>
+	</section><!-- Was 5.1.2 / #ldpc-ordering -->
+</section>
+
+<section id="ldpc-general">
+<h2>General</h2>
+	<p>The Linked Data Platform does not define how clients
+		discover <dfn><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>
+
+	<section id="ldpc-isldpr"><h2 class="normal">Each Linked Data Platform Paging Container MUST also be 
+		a conforming Linked Data Platform Container.
+	</h2></section>
+	
+	<section id="ldpp-prefer"><h2 class="normal">(From [[!LDP]])<a title="LDP server">LDP servers</a>
+		SHOULD respect all of a client's LDP-defined hints, for example 
+		<a href="#prefer-parameters">which subsets of LDP-defined state</a>
+		the client is interested in processing,
+		to influence the set of triples returned in representations of an LDPC, 
+		particularly for large LDPCs [[!LDP]].  
+		Non-normative note: the LDPC might be paged; <a title="Paged resource">paged resources</a> provide 
+		no guarantee that all triples of a given subset, for example 
+		<a title="Containment triples">containment triples</a>, 
+		are grouped together on one page or on a sequence of consecutive 
+		<a title="Single-page resource">pages</a>
+		(see <a href="#ldpr-Paging" class="sectionRef"></a>).
+	</h2></section>
+	<!-- TODO: Need to rework this^  -->
+	
+</section>
+
+<section id="ldpc-HTTP_GET">	
+<h2>HTTP GET</h2>
+
+	<section id="ldpc-sortcriteriaobj"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY 
+		represent the members of a paged LDPC in a sequential
+		order.  If the server does so, it MUST specify the order using a triple 
+		whose subject is the page URI, 
+		whose predicate is <code>ldp-paging:containerSortCriteria</code>, 
+		and whose object is a <code>rdf:List</code> of
+		<code>ldp-paging:containerSortCriterion</code> resources.  
+		The resulting order MUST be as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause 
+		[[!sparql11-query]].
+		Sorting criteria MUST be the same for all pages of a representation; if
+		the criteria were allowed to vary, the ordering among members of a container
+		across pages would be undefined. 
+		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.
+		See <a href="#ldpc-ordering" class="sectionRef"></a> for
+		an example.
+	</h2></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
+	
+	<section id="ldpc-sortliteraltype"><h2 class="normal">LDPC page representations 
+		ordered using <code>ldp-paging:containerSortCriteria</code> MUST contain, 
+		in every <code>ldp-paging:containerSortCriterion</code> list entry, 
+		a triple
+		whose subject is the sort criterion identifier, 
+		whose predicate is <code>ldp-paging:containerSortPredicate</code> 
+		and whose object is 
+		the predicate whose value is used to order members between pages (the <dfn>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 [[!sparql11-query]].  Other data types
+		can be used, but LDP
+		assigns no meaning to them and interoperability will be limited.
+	</h2></section><!-- Was 5.3.3 / #ldpc-5_3_3 -->
+	
+	<section id="ldpc-sortorder"><h2 class="normal">LDPC page representations 
+		ordered using <code>ldp-paging:containerSortCriteria</code> MUST contain, 
+		in every <code>ldp-paging:containerSortCriterion</code> list entry, 
+		a triple
+		whose subject is the sort criterion identifier, 
+		whose predicate is <code>ldp-paging:containerSortOrder</code> 
+		and whose object describes the order used.
+		LDP defines two values,
+		<code>ldp-paging:Ascending</code> and <code>ldp-paging: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.
+	 </h2></section><!-- Was 5.3.4 / #ldpc-5_3_4 -->
+	
+	<section id="ldpc-sortcollation"><h2 class="normal">LDPC page representations 
+		ordered using <code>ldp-paging:containerSortCriteria</code> MAY contain, 
+		in any <code>ldp-paging:containerSortCriterion</code> list entry,
+		a triple
+		whose subject is the sort criterion identifier, 
+		whose predicate is <code>ldp-paging:containerSortCollation</code> 
+		and whose object identifies the collation used.
+		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.
+		When the <code>ldp-paging:containerSortCollation</code> triple is absent and the 
+		<a title="page-ordering values">page-ordering values</a> are strings or simple literals [[!sparql11-query]], the
+		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
+		[[!sparql11-query]] 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.
+		When the <code>ldp-paging:containerSortCollation</code> triple is present and the 
+		<a title="page-ordering values">page-ordering values</a> are strings or simple literals 
+		[[!sparql11-query]], the
+		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
+		[[!sparql11-query]] using three-argument <code>fn:compare</code>, that is, the 
+		specified collation.
+		The <code>ldp-paging:containerSortCollation</code> triple MUST be omitted for comparisons
+		involving <a title="page-ordering values">page-ordering values</a> for which [[!sparql11-query]] does not use collations.
+	</h2></section><!-- Was 5.3.5 / #ldpc-5_3_5 -->
+
+</section> <!-- h2 -->
+
+</section> <!-- h1 LDPC -->
+
+
+<section id="base-specs" class="informative">
+<h1>Notable information from normative references</h1>
+<p>
+While readers, and especially implementers, of LDP are assumed to understand the information in its normative 
+references, the working group has found that certain points are particularly important to understand.
+For those thoroughly familiar with the referenced specifications, these points might seem obvious, yet
+experience has shown that few non-experts find all of them obvious.  This section enumerates these topics; 
+it is simply re-stating (non-normatively) information locatable via the normative references.
+</p>
+
+<section id="specs-paging" class="informative">
+<h2>Feed paging and archiving</h2>
+Reference: [[RFC5005]]
+
+	<section id="ldp-paging-incomplete"><h2 class="normal">A <a title="LDP client">LDP client</a>  
+		SHOULD NOT present <a title="paged resource">paged resources</a> as coherent or
+		complete, or make assumptions to that effect.
+		[[RFC5005]].
+	</h2></section>
+
+</section> 
+
+</section> <!-- Base specs -->
+
+<section>
+<h1>HTTP Header Definitions</h1>
+
+<p><em>TBD</em></p>     
+
+</section> <!-- Header defns -->
+    
+<!-- Removed for action-113
+<section>
+<h1>HTTP Status Code Definitions</h1>
+     
+<section id="status-code-related-content">
+<h2>209 Related Content</h2>
+
+	<div class="atrisk"><p class="atrisktext">Feature At Risk</p>
+		<p>The LDP Working Group proposes incorporation of the features described in this section.</p>
+		<ul>
+		<li>The addition of <a>209 Related Content</a> in this specification is pending 
+		advancement of an <a href="https://datatracker.ietf.org/doc/draft-wilde-related-content/">IETF draft</a>
+		that would fully include it, patterned after the codes defined by [[RFC6585]].  Once LDP is in
+		Candidate Recommendation status, the LDP WG will make an assessment based on the status at IETF
+		working with the W3C Director.</li>
+		</ul>
+	</div>
+		
+	<p>The <code>209 Related Content</code> status code indicates that the origin server 
+		is supplying the representation of a different resource than the target resource,
+		and the origin server believes that the supplied representation 
+		is likely to satisfy the user agent's original request.
+		The resource whose representation is supplied is descriptive of the target resource, in
+		the same way that the <code>Location</code> header in a <code>303 See Other</code>
+		response is descriptive of the target resource.
+	</p>
+	<p><code>209 Related Content</code> is intended to be used in situations where 
+		<code>303 See Other</code> could have been used and would most likely result in a
+		user agent retrieving the other resource, but saves the user agent from
+		the latency penalty of having to perform a separate retrieval request.
+	</p>
+   
+	<p>	LDP uses <code>209 Related Content</code> to provide clients with the 
+		<a href="#ldpr-Paging">first page of a large resource</a>, but it can also be used in
+		other common situations.  Linked Data clients could benefit by avoiding the latency
+		of additional requests when the target resource is a concept resource (one without any
+		representation capable of transmission over HTTP), and general HTTP clients would
+		benefit in many of the more general cases where <code>303 See Other</code> responses
+		are currently used.
+	</p>
+   
+	<div id="status-code-related-content-1" class="rule">7.1.1 A <code>209</code> response to a
+		<code>GET</code> request MUST contain a <code>Location</code> header with the same
+		<code>Location</code> field value as a <code>303 See Other</code> response would use [[!HTTP11]].
+	</div>
+
+	<div id="status-code-related-content-2" class="rule">7.1.2 A <code>209</code> response to a
+		<code>GET</code> request MUST contain a representation of the resource identified
+		by the response's <code>Location</code> header.
+	</div>
+
+	<div id="status-code-related-content-iana" class="rule">7.1.3 IANA Considerations</div>
+	<div>
+	<blockquote>
+	<p>
+	The <code>209 Related Content</code> must be added to the permanent status code registry 
+	maintained at <a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>
+	(see [[HTTPBIS-SEMANTICS]], [[!RFC2817]]).
+	</p>
+	<p>
+	Value:  209
+	</p>
+	<p>
+	Description:  Related Content
+	</p>
+	<p>
+	Reference:  this specification
+	</p>
+	</blockquote>
+	</div>
+
+</section>
+</section> <!-- status code defns -->
+
+
+<section class='informative' id='security'>
+<h1>Security Considerations</h1>
+As with any protocol that is implemented leveraging HTTP, implementations should take advantage of the many 
+security-related facilities associated with it and are not required to carry out LDP operations 
+that may be in contradistinction to a particular security policy in place. For example, when faced with an 
+unauthenticated request to replace system critical RDF statements in a graph through the PUT method, applications may
+consider responding with the 401 status code (Unauthorized), indicating that the appropriate authorization 
+is required. In cases where authentication is provided fails to meet the requirements of a particular access control 
+policy, the 403 status code (Forbidden) can be sent back to the client to indicate this failure to meet the
+access control policy.
+</section>
+
+
+<section class='appendix informative'>
+<h2>Acknowledgements</h2>
+     
+  <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 Malhota, Bart van Leeuwen, Cody Burleson, David Wood, Eric Prud'hommeaux, Erik Wilde, Henry Story, John Arwe, Kevin Page, Kingsley Idehen, Mark Baker, Martin P. Nally, Miel Vander Sande, Miguel Esteban Gutiérrez, Nandana Mihindukulasooriya, Olivier Berger, Pierre-Antoine Champin, Raúl García Castro, Reza B'Far, Richard Cyganiak, Roger Menday, Ruben Verborgh, Sandro Hawke, Serena Villata, Sergio Fernandez, Steve Battle, Steve Speicher, Ted Thibodeau, Tim Berners-Lee, Yves Lafon
+  </p>
+
+</section>
+
+<section class='appendix informative' id="history">
+<h1>Change History</h1>
+<p>The change history is up to the editors to insert a brief summary of
+changes, ordered by most recent changes first and with heading from which
+public draft it has been changed from.
+</p>
+
+<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
+<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140730/">Last Call Draft</a></em></blockquote> -->
+<ul>
+	<li>2014-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>
+    
+  </body>
+</html>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-paging.ttl	Tue Feb 18 15:28:39 2014 -0500
@@ -0,0 +1,86 @@
+# See details within this document for linkage to specification and purpose.
+# This ontology file is a non-normative supporting document.
[email protected] rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
[email protected] owl: <http://www.w3.org/2002/07/owl#>.
[email protected] rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
[email protected] dcterms: <http://purl.org/dc/terms/>.
[email protected] vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .
[email protected] ldp: <http://www.w3.org/ns/ldp#>.
[email protected] : <http://www.w3.org/ns/ldp-paging#>.
+
+:
+	a owl:Ontology;
+    dcterms:description "Vocabulary URIs defined in the Linked Data Platform Paging (LDP-Paging) namespace.";
+	dcterms:title "The W3C Linked Data Platform Paging (LDP-Paging) Vocabulary";
+	rdfs:label "W3C Linked Data Platform Paging (LDP-Paging)";
+	rdfs:comment "This ontology provides an informal representation of the concepts and terms
+	as defined in the LDP specification.  Consult the LDP specification for normative reference.";
+	rdfs:seeAlso <http://www.w3.org/2012/ldp>,
+		<http://www.w3.org/TR/ldp-ucr/>,
+		<http://www.w3.org/TR/ldp/>,
+		<http://www.w3.org/TR/ldp-paging/>,
+		<http://www.w3.org/2011/09/LinkedData/>.
+			
+:containerSortCriteria
+ 	a rdf:Property;
+	rdfs:comment "Link to the list of sorting criteria used by the server in a representation.";
+	vs:term_status "unstable";
+	rdfs:domain :Page;
+	rdfs:isDefinedBy :;
+	rdfs:label "containerSortCriteria";
+	rdfs:range rdf:List.
+	
+:ContainerSortCriterion
+ 	a rdf:Class;
+	rdfs:comment "Element in the list of container sorting criteria used by the server in a representation.";
+	vs:term_status "unstable";
+	rdfs:label "ContainerSortCriterion";
+	rdfs:isDefinedBy :.
+	
+:containerSortPredicate
+ 	a rdf:Property;
+	rdfs:comment "Predicate used to determine the order of the members in a page.";
+	vs:term_status "unstable";
+	rdfs:domain :ContainerSortCriterion;
+	rdfs:isDefinedBy :;
+	rdfs:label "containerSortPredicate";
+	rdfs:range rdf:Property.
+	
+:containerSortOrder
+ 	a rdf:Property;
+	rdfs:comment "The ascending/descending/etc order used to order the members in a page.";
+	vs:term_status "unstable";
+	rdfs:domain :ContainerSortCriterion;
+	rdfs:isDefinedBy :;
+	rdfs:label "containerSortOrder";
+	rdfs:range rdf:Resource.
+	
+:containerSortCollation
+ 	a rdf:Property;
+	rdfs:comment "The collation used to order the members in a page when comparing strings.";
+	vs:term_status "unstable";
+	rdfs:domain :ContainerSortCriterion;
+	rdfs:isDefinedBy :;
+	rdfs:label "containerSortCollation";
+	rdfs:range rdf:Property.
+	
+:Ascending
+ 	a rdf:Description;		# individual
+	rdfs:comment "Ascending order.";
+	vs:term_status "unstable";
+	rdfs:isDefinedBy :;
+	rdfs:label "Ascending".
+	
+:Descending
+ 	a rdf:Description;		# individual
+	rdfs:comment "Descending order.";
+	vs:term_status "unstable";
+	rdfs:isDefinedBy :;
+	rdfs:label "Descending".
+	
+:Page
+	a rdfs:Class;
+	rdfs:comment "A resource that represents a limited set of members of a LDP Container.";
+	vs:term_status "unstable";
+	rdfs:isDefinedBy :;
+	rdfs:label "Page".
\ No newline at end of file
--- a/ldp.html	Tue Feb 18 13:33:42 2014 -0500
+++ b/ldp.html	Tue Feb 18 15:28:39 2014 -0500
@@ -8,13 +8,7 @@
     TODO: Consider how to not have to explicitly list parent classes.
     TODO: Improve LDPC intro by explaining simply that LDP-DC restricts LDPC and LDP-BC restricts LDP-DC.
 	TODO: Add new "discovery of server capabilities" non-norm section
-
-Paging related:
-	TODO: Missing link header for equivalent of ldp:pageOf? Need to verify.
-	TODO: Example 11 is missing ldp:contains, true?  Omit due to GET on page resource, should make it more clear.
-	TODO: Paging intro: add 3rd example showing header link	age amongst pages and (HEAD on) the base resource.
-     Maybe also insert HEAD on base as new first example instead of relying on text alone.
-
+    TODO: Missing namespace definition clause?
  -->
 <html>
   <head>
@@ -129,7 +123,16 @@
 					]
 				,   status:   "Proposed Standard"
 				,   publisher:  "IETF"
-				}
+				},
+				"LDP-PAGING": {
+					title:    "Linked Data Platform Paging"
+				,   href:     "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html"
+				,   authors:  [
+						"S. Speicher", "J. Arwe", "A. Malhotra"
+					]
+				,   status:   "Editor's Working Draft"
+				,   publisher:  "W3C"
+				},
 			},
       };
     </script>
@@ -239,11 +242,6 @@
 	A companion document discusses best practices that you 
 	should use, and anti-patterns you should avoid, when constructing these clients and servers.
 	</p> 
-	<p>This specification provides a widely re-usable pattern to deal with large resources.  
-	Depending on the server’s capabilities, a GET request on a <a title="Paged resource">resource</a> can
-	be redirected to a <a title="Single-page resource">subset of the resource (one page)</a>, that provides access to subsequent pages 
-	(see <a href="#ldpr-Paging" class="sectionRef"></a>). 
-	</p>
 	<p>This specification defines a special type of <a>Linked Data Platform Resource</a>: a 
 	<a title="Linked Data Platform Container">Container</a>.  Containers are very useful 
 	in building application models involving collections of resources, often homogeneous ones. 
@@ -256,6 +254,8 @@
 	additional specifications.  The scope is intentionally narrow to provide a set of key rules for 
 	reading and writing Linked Data that most, if not all, other specifications will depend upon and 
 	implementations will support.</p>
+	<p>This specification provides some approaches to deal with large resources.  An extension to this specification
+	provides the ability to break large resource representations into multiple paged responses [[LDP-PAGING]].</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> [[LDP-UCR]] 
 	and <a href="#base-specs" class="sectionRef"></a>.</p>
 </section>
@@ -386,69 +386,6 @@
 	triples, but if future versions of LDP define additional classes of triples then this definition
 	would expand to subtract out those classes as well.
 	<p></p></dd>
-	
-	<dt><dfn>Paged resource</dfn></dt>
-	<dd>A LDP-RS whose representation may be too large to fit in a single HTTP response, for which an
-	LDP server offers a sequence of single-page <a title="Linked Data Platform RDF Source">LDP-RSs</a>.  
-	When the representations of the sequence's resources
-	are combined by a client, the client has a (potentially incomplete or incoherent) copy of the paged resource's
-	state.  If a paged resource <var>P</var> is a LDP-RS and is broken into a sequence of pages
-	(single-page resources) <var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>,
-	the representation of each <var>P<sub>i</sub></var> contains
-	a subset of the triples in <var>P</var>.
-	LDP allows paging of resources other than <a title="Linked Data Platform RDF Source">LDP-RSs</a>, 
-	but does not specify how clients combine
-	their representations.  See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.  For readers
-	familiar with paged feeds [[RFC5005]], 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></dd>
-	
-	<dt><dfn>Single-page resource</dfn></dt>
-	<dd>One of a sequence of related <a title="Linked Data Platform RDF Source">LDP-RSs</a>
-	<var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>, 
-	each of which contains a subset of the state
-	of another resource <var>P</var>.  <var>P</var> is called the paged resource.
-	For readers
-	familiar with paged feeds [[RFC5005]], a single-page resource is similar to a feed document and the same
-	coherency/completeness considerations apply.
-	<a href="#ldpr-pagingGET-sequences-change">LDP provides no guarantees that the sequence is stable</a>.
-	<p>
-	Note: the choice of terms was designed to help authors and readers clearly differentiate between
-	the <a title="Paged resource"><em>resource being paged</em></a>, and the 
-	<a title="Single-page resource"><em>individual page resources</em></a>, 
-	in cases where both are mentioned in
-	close proximity.  
-	<p></p></dd>
-	
-	<dt><dfn>first page link</dfn></dt>
-	<dd>A link to the first <a title="Single-page resource">single-page resource</a>
-	of a <a title="Paged resource">paged resource</a> <var>P</var>.  Syntactically, a
-	HTTP <code>Link &lt;<var>P<sub>1</sub></var>&gt;; rel='first'</code>
-	header [[!RFC5988]].
-	<p></p></dd>
-	
-	<dt><dfn>next page link</dfn></dt>
-	<dd>A link to the next <a title="Single-page resource">single-page resource</a> 
-	of a <a title="Paged resource">paged resource</a> <var>P</var>.  Syntactically, a
-	HTTP <code>Link &lt;<var>P<sub>i</sub></var>&gt;; rel='next'</code>
-	header [[!RFC5988]] where the target URI is <var>P<sub>i=2...n</sub></var>.
-	<p></p></dd>
-	
-	<dt><dfn>last page link</dfn></dt>
-	<dd>A link to the last <a title="Single-page resource">single-page resource</a>
-	of a <a title="Paged resource">paged resource</a> <var>P</var>.  Syntactically, a
-	HTTP <code>Link &lt;<var>P<sub>n</sub></var>&gt;; rel='last'</code>
-	header [[!RFC5988]].
-	<p></p></dd>
-	
-	<dt><dfn>previous page link</dfn></dt>
-	<dd>A link to the previous <a title="Single-page resource">single-page resource</a> 
-	of a <a title="Paged resource">paged resource</a> <var>P</var>.  Syntactically, a
-	HTTP <code>Link &lt;<var>P<sub>i</sub></var>&gt;; rel='prev'</code>
-	header [[!RFC5988]] where the target URI is <var>P<sub>i=1...n-1</sub></var>.
-	<p></p></dd>
-	
   </dl>
 
 <section id="conventions">
@@ -493,7 +430,7 @@
 
 <section id="ldpclient">
 <h1>Linked Data Platform Clients</h1>
-<p>All of the following are conformance rules for <a title="LDP server">LDP Clients</a>.
+<p>All of the following are conformance rules for <a title="LDP client">LDP Clients</a>.
 </p>
 <section><h2>General</h2>
 
@@ -534,6 +471,18 @@
 		be capable of processing responses formed by an LDP server that ignores hints,
 		including LDP-defined hints.
 	</h2></section> 
+
+	
+	<section id="ldpr-cli-paging"><h2 class="normal">
+		
+	<div class="atrisk" id="atrisk-paging"><p class="atrisktext">Feature At Risk</p>
+	<p>The LDP Working Group proposes incorporation of the following clause to make LDP clients paging aware:</p>
+		<a title="LDP client">LDP clients</a> SHOULD 
+		be capable of processing successful HTTP <code>GET</code> responses formed by an LDP server
+		that independently initiated paged responses [[!LDP-PAGING]]
+	</div></h2>
+	</section> 
+
 	
 </section>
 </section> <!-- Client constraints -->
@@ -574,8 +523,11 @@
 		<li>Are there some typical vocabularies that should be reused?</li>
 	</ul>
 	<p>The following sections define the conformance rules for LDP servers when serving LDPRs.
-		This document also explains <a href="#ldpr-Paging">how a server paginates an LDP-RS's representation</a> if it gets too big.
-		Companion non-normative documents describe additional guidelines for use when interacting with LDPRs. 
+	Companion non-normative documents describe additional guidelines for use when interacting with LDPRs. 
+	</p>
+	<p>LDP-RS's representations may be too big, one strategy is to break up the response representation
+	into client consumable chunks called pages. A separate LDP specification outlines the conformance
+	rules around pagination [[LDP-PAGING]].
 	</p>
 	<p>An LDP server manages two kinds of <a title="Linked Data Platform Resources">LDPRs</a>, those resources who whose state 
 	is represented using RDF (LDP-RS) and those using other formats (LDP-NR).  LDP-RSs have the unique
@@ -617,7 +569,7 @@
 	</h2></section><!-- Was 4.2.4 / #ldpr-4_2_4 -->
 	
 	<section id="ldpr-gen-reusevocabsuchas"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> predicates SHOULD use standard vocabularies such as Dublin Core
-		[[!DC-TERMS]], RDF [[!RDF11-CONCEPTS]] and RDF Schema [[!rdf-schema]], whenever
+		[[!DC-TERMS]], RDF [[!rdf11-concepts]] and RDF Schema [[!rdf-schema]], whenever
 		possible.
 	</h2></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->
 	
@@ -662,7 +614,7 @@
 	<section id="ldpr-gen-noinferencing"><h2 class="normal"><a title="LDP server">LDP servers</a>
 		MUST NOT require LDP clients to implement inferencing in order to recognize the subset
 		of content defined by LDP.  Other specifications built on top of LDP may require clients
-		to implement inferencing [[!RDF11-CONCEPTS]].  The practical implication is that all content defined by LDP
+		to implement inferencing [[!rdf11-concepts]].  The practical implication is that all content defined by LDP
 		must be explicitly represented. 
 	</h2></section><!-- Was 4.2.11 / #ldpr-4_2_11 -->
 	
@@ -685,16 +637,6 @@
 		document.  Natural language constraint documents are therefore permitted, 
 		although machine-readable ones facilitate better client interactions.
 	</h2></section><!-- Was 4.2.13 / #ldpr-4_2_13 -->
-	
-	<section id="ldpr-page-large"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDP-RSs in
-		pages.
-		See <a href="#ldpr-Paging" class="sectionRef"></a> for additional requirements associated with <a title="Paged resource">paged resources</a>.
-	</h2></section><!-- Was 4.2.14 / #ldpr-4_2_14 -->
-	
-	<section id="ldpr-split-any"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY 
-		treat any resource (LDP-RS or not) as a <a title="Paged resource">paged resource</a>. 
-		See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
-	</h2></section><!-- Was 4.2.15 / #ldpr-4_2_15 -->
 
 </section>
 
@@ -869,238 +811,6 @@
 		responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
 		Method tokens in the HTTP response header <code>Allow</code>.
 	</h2></section><!-- Was 4.9.2 / #ldpr-4_9_2 -->
-		
-</section>
-
-<section id="ldpr-Paging">
-<h2>Paging</h2>
-
-<section class="informative" id="ldpr-PagingIntro">
-
-<h3>Introduction</h3>
-	<p>It sometimes happens that a
-		resource is too large to reasonably transmit its representation in a
-		single HTTP response.  
-		To address this problem, servers should support a technique called Paging.  
-		When a client retrieves such a resource, the server redirects the client to a "first page" resource, and includes in its response
-		a link to the next part of the resource's state, all at a URLs of the server's choosing.
-		The triples in the representation of the <a title="Single-page resource">each page of an LDPR</a>
-		are typically a subset of the triples from the <a title="Paged resource">paged resource</a>.
-	</p>
-	<p><a title="LDP server">LDP servers</a> may respond to requests for a
-		resource by redirecting to the first page of the resource and, with that, returning 
-		a <code>Link &lt;next-page-URL&gt;;type='next'</code> header containing the URL for the next page.
-		Clients inspect each response for the link header to see if additional pages
-		are available; paging does not affect the choice of HTTP status code.
-		Note that paging is lossy, as described in [[RFC5005]], and so (as stated there)
-		clients should not make any assumptions about a set of pages being a complete or 
-		coherent snapshot of a resource's state.</p>
-	<p>
-		Looking at an example resource representing Example Co.'s customer
-		relationship data, identified by the URI <code>http://example.org/customer-relations</code>,
-		we’ll split the response across two pages.  
-		The client 
-		retrieves <code>http://example.org/customer-relations</code>, and
-		the server responds with <a href="#atrisk-333">status code <code>333 (Returning Related)</code></a>, 
-		a <code>Location: http://example.org/customer-relations?page1</code> HTTP response header,
-		and the following representation:
-	</p>
-
-<pre class="example" id="ldpc-ex-page1"># The following is the representation of
-#    http://example.org/customer-relations?page1
-#    Requests on the URI will result in responses that include the following HTTP header
-#       Link: &lt;http://example.org/customer-relations?p=2&gt;; rel='next'
-#    This Link header is how clients discover the URI of the next page in sequence,
-#    and that the resource supports paging.
[email protected] rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
[email protected] &lt;http://example.org/customer-relations&gt;.
-
-&lt;&gt;
-   a o:CustomerRelations;
-   dcterms:title "The customer information for Example Co.";
-   o:client &lt;#JohnZSmith&gt;, &lt;#BettyASmith&gt;, &lt;#JoanRSmith&gt;. 
-
-&lt;#JohnZSmith&gt;
-   a foaf:Person;
-   o:status o:ActiveCustomer;
-   foaf:name "John Z. Smith".
-&lt;#BettyASmith&gt;
-   a foaf:Person;
-   o:status o:PreviousCustomer;
-   foaf:name "Betty A. Smith".
- &lt;#JoanRSmith&gt;
-   a foaf:Person;
-   o:status o:PotentialCustomer;
-   foaf:name "Joan R. Smith".</pre>
-
-	<p>
-		Because the server includes a <code>Link: &lt;http://example.org/customer-relations?p=2&gt;; rel='next'</code>
-		response header, and the status code is 3xx (<code>333 (Returning Related)</code> in this case), 
-		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 specificiation. The next page link's target URI is also
-		defined by the server and not this specification.
-	</p>
-	<p>
-		The following example is the result of retrieving
-		the next page; 
-		the server responds with status code <code>200 (OK)</code> and the following representation:
-	</p>
-
-<pre class="example" id="ldpc-ex-page2"># The following is the representation of
-#  http://example.org/customer-relations?p=2
-#
-#  There is no "next" Link in the server's response, so this is the final page.
-#
[email protected] rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
[email protected] &lt;http://example.org/customer-relations&gt;.
-
-&lt;&gt;
-   o:client &lt;#GlenWSmith&gt;, &lt;#AlfredESmith&gt;. 
- 
-&lt;#GlenWSmith&gt;
-   a foaf:Person;
-   o:status o:ActiveCustomer, o:GoldCustomer;
-   foaf:name "Glen W. Smith".
-
-&lt;#AlfredESmith&gt;
-   a foaf:Person;
-   o:status o:ActiveCustomer, o:BronzeCustomer;
-   foaf:name "Alfred E. Smith".
- </pre>
-	<p>
-		In this example, there are only two customers provided in the
-		final page.  To indicate this is the last page, the server omits the <code>Link: rel='next'</code> 
-		header in its response.
-	</p>
-	<p>
-		As mentioned above, retrieving all the pages offered by a server gives no guarantee to a client
-		that it knows the entire state of the server.  For example, after the server constructs the
-		the first page representation, another
-		actor could delete <code>client#BettyASmith</code> from the server.  
-	</p>
-</section>
-
-<section id="ldpr-PagingGET">
-<h3>HTTP GET</h3>
-	<p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef"></a> on HTTP <code>GET</code>, 
-		<a title="LDP server">LDP servers</a> that support paging must 
-		also follow the requirements in this section for all <a title="Paged resource">paged resources</a>
-		and their associated <a title="Single-page resource">single-page resources</a>.
-	</p>
-
-	<section id="ldpr-pagingGET-sequences-change"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
-		add <a title="Single-page resource">single-page resources</a> to a 
-		<a title="Paged resource">paged resource's</a> sequence over time,
-		but SHOULD only add pages to the end of a sequence.
-		</h2><!-- Was 4.10.2.1 / #ldpr-pagingGET-sequences-change -->
-		<blockquote>Non-normative note: 
-		As a result, clients retrieving any <a title="Single-page resource">single-page resource</a> several times can observe its place in the sequence
-		change as the state of the <a title="Paged resource">paged resource</a> changes.
-		For example, a nominally last page's server might provide a
-		<a>next page link</a> when the page is retrieved.  Similar situations arise when the page sequence 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.
-		</blockquote>
-
-		<section id="ldpr-pagingGET-first-allowed-onpages"><h2 class="normal">
-			<a title="LDP server">LDP servers</a> MAY provide 
-			a <a>first page link</a> when responding to 
-			requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
-		</h2></section><!-- Was 4.10.2.1.1 / #ldpr-pagingGET-sequences-change -->
-	
-		<section id="ldpr-pagingGET-last-allowed-onpages"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
-			provide a <a>last page link</a>
-			in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
-		</h2></section><!-- Was 4.10.2.1.3 / #ldpr-pagingGET-last-allowed-onpages -->
-	</section>
-	
-	<section id="ldpr-pagingGET-next-reqd"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
-		provide a <a>next page link</a>
-		in responses to <code>GET</code> requests with any <a title="Single-page resource">single-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. 
-	</h2><!-- Was 4.10.2.2 / #ldpr-pagingGET-next-reqd-change -->
-	
-		<section id="ldpr-pagingGET-lastnext-prohibited"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST NOT
-			provide a <a>next page link</a>
-			in responses to <code>GET</code> requests with the final <a title="Single-page resource">single-page resource</a> 
-			as the <code>Request-URI</code>.
-			This is the mechanism by which clients can discover the end of the page sequence
-			as currently known by the server.  
-		</h2></section><!-- Was 4.10.2.2.1 / #ldpr-pagingGET-lastnext-prohibited -->
-		
-		<section id="ldpr-pagingGET-prev-allowed"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
-			provide a <a>previous page link</a>
-			in responses to <code>GET</code> requests with any <a title="Single-page resource">single-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.  
-		</h2></section><!-- Was 4.10.2.2.2 / #ldpr-pagingGET-prev-allowed -->
-		
-		<section id="ldpr-pagingGET-firstprev-prohibited"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST NOT
-			provide a <a>previous page link</a>
-			in responses to <code>GET</code> requests with the <em>first</em> <a title="Single-page resource">single-page resource</a> 
-			as the <code>Request-URI</code>.
-			This is one mechanism by which clients can discover the beginning of the page sequence
-			as currently known by the server.  
-		</h2></section><!-- Was 4.10.2.2.3 / #ldpr-pagingGET-firstprev-prohibited -->
-	</section>
-
-	<section id="ldpr-pagingGET-page-type-reqd"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
-		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> [[!RFC5988]]
-		in responses to <code>GET</code> requests with any <a title="Single-page resource">single-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.  
-	</h2></section><!-- Was 4.10.2.4 / #ldpr-pagingGET-page-type-reqd -->
-
-	<div class="atrisk" id="atrisk-333"><p class="atrisktext">Feature At Risk</p>
-		<p>The LDP Working Group proposes incorporation of the features described in the next compliance clause.</p>
-		<ul>
-		<li><p>
-		A <a href="http://lists.w3.org/Archives/Public/www-tag/2013Dec/0041.html">TAG discussion</a> has started,
-		whose goal is to reduce the need for two request-response round trips down to one when retrieving what 
-		turns out to be the first page of a paged resource, by defining a new
-		HTTP response code in the <code>2xx</code> or <code>3xx</code> class that would allow a server to
-		respond to <code>GET request-uri</code> requests with the representation of the first page 
-		(whose URI is <code>first-page-uri</code>, not <code>request-uri</code>) of a multi-page response.
-		</p></li>
-		<li><p>
-		For the purposes of drafting this section, we assume that the 
-		new code's value is <code>333 (Returning Related)</code>,
-		<a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0023.html">an LDP extrapolation from TAG discussions,</a>
-		and its definition is given by 
-		<a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0015.html">Henry Thompson's strawman</a>, with the substitution of 333 for 2xx.
-		Note: nothing prevents servers or clients from using <code>303 See Other</code> responses to 
-		requests for <a title="Paged resource">paged resources</a>.  The only significant difference between 303 and 333 responses
-		is the extra round trip required for the client to retrieve the representation of the first page when using 303.
-		</p></li>
-		<li><p>
-		Once LDP is a
-		Candidate Recommendation, the LDP WG will make an assessment based on the status at IETF,
-		working with the W3C Director, to either use the newly defined response code 
-		as documented in this section or to revert to a classic 
-		<code>303</code> response pattern.
-		</p></li>
-		</ul>
-	</div>
-		
-	<section id="ldpr-status-code"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD respond 
-		with HTTP status code <code>333 (Returning Related)</code> 
-		to successful <code>GET</code> requests with any <a title="Paged resource">paged resource</a> 
-		as the <code>Request-URI</code>, although any appropriate code MAY be used.
-	</h2></section>
-</section>
 
 </section> <!-- h2 -->
 
@@ -1122,9 +832,9 @@
 	<ol>
 		<li>To which URLs can I POST to create new resources?</li>
 		<li>Where can I GET a list of existing resources?</li>
-		<li>How	is the order of the container entries expressed?</li>
 		<li>How do I get information about the members along with the container?</li>
 		<li>How	can I ensure the resource data is easy to query?</li>
+		<li>How	is the order of the container entries expressed? [[LDP-PAGING]]</li>
 	</ol>
 	<p>
 		This document defines the representation and behavior of containers
@@ -1423,99 +1133,8 @@
 		LDP recommends using PATCH to update these properties, if necessary.  It provides no facility
 		for updating them via PUT without replacing the entire container's state.
 	</p>
-		
 	</section><!-- ldpc-get_empty-container_props -->
 
-	<section id="ldpc-ordering"><h2 class="normal">Ordering</h2>
-	<p>
-		There are many cases where an ordering of the members of the
-		container is important. LDPC 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:value</code> predicate is present for each
-		member, so the client can easily order the members according to the
-		value of that property. In this way, LDPC avoids the use of RDF
-		constructs like Seq and List for expressing order.
-	</p>
-	<p>
-		Order becomes more important for <a title="LDP server">LDP servers</a> when containers are
-		paginated. If the server does not respect ordering when constructing
-		pages, the client would be forced to retrieve all pages before
-		sorting the members, which would defeat the purpose of pagination. 
-		In cases where ordering is important, an LDPC server exposes all the
-		members on a page with the proper sort order with relation to all 
-		members on the next and previous pages.
-		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 LDPC specification allows servers to assert the ordered list
-		of sort criteria used to sort the members, using the 
-		<code>ldp:containerSortCriteria</code> relation.
-		Each member of the ordered list exposes one <code>ldp:containerSortCriterion</code>, 
-		consisting of a <code>ldp:containerSortOrder</code>, 
-		<code>ldp:containerSortPredicate</code>, and 
-		optionally a <code>ldp:containerSortCollation</code>.
-	</p>
-	<p>Here is an example container described
-		previously, with representation for ordering of the assets:</p>
-<pre class="example" id="ldpc-ex-ordering">
-# 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 &lt;http://example.org/netWorth/nw1/assetContainer/&gt;
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
-
-&lt;&gt;
-   a ldp:Container, ldp:DirectContainer;
-   dcterms:title "The assets of JohnZSmith";
-   ldp:membershipResource &lt;http://example.org/netWorth/nw1&gt;;
-   ldp:hasMemberRelation o:asset;
-   ldp:insertedContentRelation ldp:MemberSubject.
-
-&lt;?firstPage&gt;
-   a ldp:Page;
-   ldp:pageOf &lt;&gt;;
-   ldp:containerSortCriteria (&lt;#SortValueAscending&gt;).
-
-&lt;#SortValueAscending&gt;
-   a ldp:ContainerSortCriterion;
-   ldp:containerSortOrder ldp:Ascending;
-   ldp:containerSortPredicate o:value.
-
-&lt;http://example.org/netWorth/nw1&gt;
-   a o:NetWorth;
-   o:asset &lt;a1&gt;, &lt;a3&gt;, &lt;a2&gt;.
-
-&lt;a1&gt;
-   a o:Stock;
-   o:value 100.00 .
-&lt;a2&gt;
-   a o:Cash;
-   o:value 50.00 .
-&lt;a3&gt;
-   a o:RealEstateHolding;
-   o:value 300000 .
-</pre>
-		<p>
-			As you can see by the addition of the <code>ldp:ContainerSortCriteria</code> 
-			predicate, the <code>o:value</code> predicate is used
-			to order the page members in ascending order.  It is up to the domain model
-			and server to determine the appropriate predicate to indicate the
-			resource’s order within a page, and up to the client receiving this 
-			representation to use that order in whatever way is appropriate, for 
-			example to sort the data prior to presentation on a user interface. Also
-			as it is possible for a container to have as its members other containers,
-			the ordering approach doesn't change as containers themselves are LDPRs and the
-			properties from the domain model can be leveraged for the sort criteria.
-		</p>
-	</section><!-- Was 5.1.2 / #ldpc-ordering -->
 </section>
 
 <section id="ldpc-general">
@@ -1667,13 +1286,7 @@
 		<a href="#prefer-parameters">which subsets of LDP-defined state</a>
 		the client is interested in processing,
 		to influence the set of triples returned in representations of an LDPC, 
-		particularly for large LDPCs.  
-		Non-normative note: the LDPC might be paged; <a title="Paged resource">paged resources</a> provide 
-		no guarantee that all triples of a given subset, for example 
-		<a title="Containment triples">containment triples</a>, 
-		are grouped together on one page or on a sequence of consecutive 
-		<a title="Single-page resource">pages</a>
-		(see <a href="#ldpr-Paging" class="sectionRef"></a>).
+		particularly for large LDPCs.  See also [[LDP-PAGING]].
 	</h2></section>
 	
 </section>
@@ -1689,77 +1302,6 @@
 		section on <a href="#ldpc-mbrpred">LDPC membership predicates</a>.
 	</h2></section><!-- Was 5.3.1 / #ldpc-5_3_1 -->
 	
-	<section id="ldpc-sortcriteriaobj"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY 
-		represent the members of a paged LDPC in a sequential
-		order.  If the server does so, it MUST specify the order using a triple 
-		whose subject is the page URI, 
-		whose predicate is <code>ldp:containerSortCriteria</code>, 
-		and whose object is a <code>rdf:List</code> of
-		<code>ldp:containerSortCriterion</code> resources.  
-		The resulting order MUST be as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause 
-		[[!sparql11-query]].
-		Sorting criteria MUST be the same for all pages of a representation; if
-		the criteria were allowed to vary, the ordering among members of a container
-		across pages would be undefined. 
-		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.
-		See <a href="#ldpc-ordering" class="sectionRef"></a> for
-		an example.
-	</h2></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
-	
-	<section id="ldpc-sortliteraltype"><h2 class="normal">LDPC page representations 
-		ordered using <code>ldp:containerSortCriteria</code> MUST contain, 
-		in every <code>ldp:containerSortCriterion</code> list entry, 
-		a triple
-		whose subject is the sort criterion identifier, 
-		whose predicate is <code>ldp:containerSortPredicate</code> 
-		and whose object is 
-		the predicate whose value is used to order members between pages (the <dfn>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 [[!sparql11-query]].  Other data types
-		can be used, but LDP
-		assigns no meaning to them and interoperability will be limited.
-	</h2></section><!-- Was 5.3.3 / #ldpc-5_3_3 -->
-	
-	<section id="ldpc-sortorder"><h2 class="normal">LDPC page representations 
-		ordered using <code>ldp:containerSortCriteria</code> MUST contain, 
-		in every <code>ldp:containerSortCriterion</code> list entry, 
-		a triple
-		whose subject is the sort criterion identifier, 
-		whose predicate is <code>ldp:containerSortOrder</code> 
-		and whose object describes the order used.
-		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.
-	 </h2></section><!-- Was 5.3.4 / #ldpc-5_3_4 -->
-	
-	<section id="ldpc-sortcollation"><h2 class="normal">LDPC page representations 
-		ordered using <code>ldp:containerSortCriteria</code> MAY contain, 
-		in any <code>ldp:containerSortCriterion</code> list entry,
-		a triple
-		whose subject is the sort criterion identifier, 
-		whose predicate is <code>ldp:containerSortCollation</code> 
-		and whose object identifies the collation used.
-		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.
-		When the <code>ldp:containerSortCollation</code> triple is absent and the 
-		<a title="page-ordering values">page-ordering values</a> are strings or simple literals [[!sparql11-query]], the
-		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
-		[[!sparql11-query]] 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.
-		When the <code>ldp:containerSortCollation</code> triple is present and the 
-		<a title="page-ordering values">page-ordering values</a> are strings or simple literals 
-		[[!sparql11-query]], the
-		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
-		[[!sparql11-query]] using three-argument <code>fn:compare</code>, that is, the 
-		specified collation.
-		The <code>ldp:containerSortCollation</code> triple MUST be omitted for comparisons
-		involving <a title="page-ordering values">page-ordering values</a> for which [[!sparql11-query]] does not use collations.
-	</h2></section><!-- Was 5.3.5 / #ldpc-5_3_5 -->
 </section>
 
 <section id="ldpc-HTTP_POST">
@@ -2091,7 +1633,7 @@
 
 <section id="specs-rdf" class="informative">
 <h2>RDF</h2>
-Reference: [[RDF11-CONCEPTS]]
+Reference: [[rdf11-concepts]]
 
 	<section id="ldp-rdfconcepts-extra-triples-any"><h2 class="normal">The state of an LDPR 
 		can have triples with any subject(s).  The URL used to retrieve the
@@ -2114,18 +1656,6 @@
 
 </section> 
 
-<section id="specs-paging" class="informative">
-<h2>Feed paging and archiving</h2>
-Reference: [[RFC5005]]
-
-	<section id="ldp-paging-incomplete"><h2 class="normal">A <a title="LDP client">LDP client</a>  
-		SHOULD NOT present <a title="paged resource">paged resources</a> as coherent or
-		complete, or make assumptions to that effect.
-		[[RFC5005]].
-	</h2></section>
-
-</section> 
-
 </section> <!-- Base specs -->
 
 <section>
@@ -2566,6 +2096,7 @@
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130730/">Last Call Draft</a></em></blockquote> -->
 <ul>
+	<li>2014-02-18 - Factored out paging and sorting into separate spec LDP-Paging (SS) </li>
 	<li>2014-02-18 - Reference cleanup and tweak LDP-RS term (SS) </li>
 	<li>2014-02-17 - Reference to RDF Document into terms (SS) </li>
 	<li>2014-02-17 - Adopted container hierarchy and merged Indirect Container into Container (SS) </li>
--- a/ldp.ttl	Tue Feb 18 13:33:42 2014 -0500
+++ b/ldp.ttl	Tue Feb 18 15:28:39 2014 -0500
@@ -70,64 +70,7 @@
 	vs:term_status "unstable";
 	rdfs:isDefinedBy :;
 	rdfs:label "DirectContainer".
-	
-:containerSortCriteria
- 	a rdf:Property;
-	rdfs:comment "Link to the list of sorting criteria used by the server in a representation.";
-	vs:term_status "unstable";
-	rdfs:domain :Page;
-	rdfs:isDefinedBy :;
-	rdfs:label "containerSortCriteria";
-	rdfs:range rdf:List.
-	
-:ContainerSortCriterion
- 	a rdf:Class;
-	rdfs:comment "Element in the list of container sorting criteria used by the server in a representation.";
-	vs:term_status "unstable";
-	rdfs:label "ContainerSortCriterion";
-	rdfs:isDefinedBy :.
-	
-:containerSortPredicate
- 	a rdf:Property;
-	rdfs:comment "Predicate used to determine the order of the members in a page.";
-	vs:term_status "unstable";
-	rdfs:domain :ContainerSortCriterion;
-	rdfs:isDefinedBy :;
-	rdfs:label "containerSortPredicate";
-	rdfs:range rdf:Property.
-	
-:containerSortOrder
- 	a rdf:Property;
-	rdfs:comment "The ascending/descending/etc order used to order the members in a page.";
-	vs:term_status "unstable";
-	rdfs:domain :ContainerSortCriterion;
-	rdfs:isDefinedBy :;
-	rdfs:label "containerSortOrder";
-	rdfs:range rdf:Resource.
-	
-:containerSortCollation
- 	a rdf:Property;
-	rdfs:comment "The collation used to order the members in a page when comparing strings.";
-	vs:term_status "unstable";
-	rdfs:domain :ContainerSortCriterion;
-	rdfs:isDefinedBy :;
-	rdfs:label "containerSortCollation";
-	rdfs:range rdf:Property.
-	
-:Ascending
- 	a rdf:Description;		# individual
-	rdfs:comment "Ascending order.";
-	vs:term_status "unstable";
-	rdfs:isDefinedBy :;
-	rdfs:label "Ascending".
-	
-:Descending
- 	a rdf:Description;		# individual
-	rdfs:comment "Descending order.";
-	vs:term_status "unstable";
-	rdfs:isDefinedBy :;
-	rdfs:label "Descending".
-	
+		
 :hasMemberRelation
 	a rdf:Property;
 	rdfs:comment "Indicates which predicate is used in membership triples, and that the membership triple pattern is < membership-constant-URI , object-of-hasMemberRelation, member-URI >.";
@@ -164,14 +107,6 @@
 	rdfs:label "insertedContentRelation";
 	rdfs:range rdf:Property.
 
-:Page
-	a rdfs:Class;
-	rdfs:comment "A resource that represents a limited set of members of a LDP Container.";
-	vs:term_status "unstable";
-	rdfs:isDefinedBy :;
-	rdfs:label "Page".
-	
-
 :member
 	a rdf:Property;
 	rdfs:comment "LDP servers should use this predicate as the membership predicate if there is no obvious predicate from an application vocabulary to use.";
@@ -189,7 +124,6 @@
 	rdfs:isDefinedBy :;
 	rdfs:label "contains";
 	rdfs:range rdfs:Resource.
-	
 
 :MemberSubject
 	a rdf:Description;		# individual