Removing old working files
authorsspeiche
Tue, 10 Sep 2013 10:06:26 -0400
changeset 326 4e08fc8b04b2
parent 325 e0790fa85b77
child 327 fed840555dd2
Removing old working files
drafts/ldp/Overview.html
ldpbusted.html
--- a/drafts/ldp/Overview.html	Tue Sep 10 10:04:47 2013 -0400
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,2108 +0,0 @@
-<!DOCTYPE html>
-<html lang="en" dir="ltr" typeof="bibo:Document w3p:LastCall" about="" property="dcterms:language" content="en">
-<head>
-    <title>Linked Data Platform 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;
-		}
-
-    </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:  #ff4500;
-}
-
-/* --- 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;
-}
-</style><style>/* --- EXAMPLES --- */
-div.example-title {
-    min-width: 7.5em;
-    color: #b9ab2d;
-}
-div.example-title span {
-    text-transform: uppercase;   
-}
-aside.example, div.example, div.illegal-example {
-    padding: 0.5em;
-    margin: 1em 0;
-    position: relative;
-    clear: both;
-}
-div.illegal-example { color: red }
-div.illegal-example p { color: black }
-aside.example, div.example {
-    padding: .5em;
-    border-left-width: .5em;
-    border-left-style: solid;
-    border-color: #e0cb52;
-    background: #fcfaee;    
-}
-
-aside.example div.example {
-    border-left-width: .1em;
-    border-color: #999;
-    background: #fff;
-}
-aside.example div.example div.example-title {
-    color: #999;
-}
-</style><link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/W3C-WD"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
-<body class="h-entry" style="">
-<div class="head">
-  <a href="http://www.w3.org/"><img height="48" width="72" alt="W3C" src="http://www.w3.org/Icons/w3c_home"/></a>
-  <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform 1.0</h1>
-  
-  <h2 property="dcterms:issued" datatype="xsd:dateTime" content="2013-07-30T04:00:00.000Z" id="w3c-last-call-working-draft-30-july-2013"><abbr title="World Wide Web Consortium">W3C</abbr> Last Call Working Draft <time class="dt-published" datetime="2013-07-30">30 July 2013</time></h2>
-  <dl>
-    
-      <dt>This version:</dt>
-      <dd><a class="u-url" href="http://www.w3.org/TR/2013/WD-ldp-20130730/">http://www.w3.org/TR/2013/WD-ldp-20130730/</a></dd>
-      <dt>Latest published version:</dt>
-      <dd><a href="http://www.w3.org/TR/ldp/">http://www.w3.org/TR/ldp/</a></dd>
-    
-    
-      <dt>Latest editor's draft:</dt>
-      <dd><a href="http://www.w3.org/2012/ldp/hg/ldp.html">http://www.w3.org/2012/ldp/hg/ldp.html</a></dd>
-    
-    
-    
-    
-    
-      <dt>Previous version:</dt>
-      <dd><a rel="dcterms:replaces" href="http://www.w3.org/TR/2013/WD-ldp-20130307/">http://www.w3.org/TR/2013/WD-ldp-20130307/</a></dd>
-    
-    
-    <dt>Editors:</dt>
-    <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Steve Speicher" href="http://stevespeicher.blogspot.com">Steve Speicher</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://ibm.com/">IBM Corporation</a></span>
-</dd>
-<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="John Arwe" href="https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?userid=120000CAW7">John Arwe</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://ibm.com/">IBM Corporation</a></span>
-</dd>
-<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Ashok Malhotra" href="mailto:ashok.malhotra@oracle.com">Ashok Malhotra</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oracle.com">Oracle Corporation</a></span>
-</dd>
-
-    
-    
-  </dl>
-  
-  
-  
-  
-    
-      <p class="copyright">
-        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
-        2013
-        
-        <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
-        (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
-        <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
-        <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), All Rights Reserved.
-        <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
-        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
-        <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.
-      </p>
-    
-  
-  <hr>
-</div>
-<section id="abstract" class="introductory" property="dcterms:abstract" datatype="" typeof="bibo:Chapter" resource="#abstract" rel="bibo:chapter"><h2>Abstract</h2><p>
-This document describes a set of best practices and simple approach for a read-write Linked Data architecture, based on
-HTTP access to web resources that describe their state using the <abbr title="Resource Description Framework">RDF</abbr>
-data model.
-</p></section><section id="sotd" class="introductory" typeof="bibo:Chapter" resource="#sotd" rel="bibo:chapter"><h2>Status of This Document</h2>
-  
-    
-      
-        <p>
-          <em>This section describes the status of this document at the time of its publication. Other
-          documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the latest revision
-          of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports
-          index</a> at http://www.w3.org/TR/.</em>
-        </p>
-        
-        <p>
-          This document was published by the <a href="http://www.w3.org/2012/ldp">Linked Data Platform Working Group</a> as a Last Call Working Draft.
-          
-            This document is intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation.
-          
-          
-          If you wish to make comments regarding this document, please send them to 
-          <a href="mailto:public-ldp-comments@w3.org">public-ldp-comments@w3.org</a> 
-          (<a href="mailto:public-ldp-comments-request@w3.org?subject=subscribe">subscribe</a>,
-          <a href="http://lists.w3.org/Archives/Public/public-ldp-comments/">archives</a>).
-          
-          The Last Call period ends 02 September 2013.
-          
-          
-            All comments are welcome.</p>
-          
-        
-          <p>
-            Publication as a Last Call Working Draft does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr> Membership.
-            This is a draft document and may be updated, replaced or obsoleted by other documents at 
-            any time. It is inappropriate to cite this document as other than work in progress.
-          </p>
-        
-        
-          <p>
-            This is a Last Call Working Draft and thus the Working Group has determined that this document has satisfied the
-            relevant technical requirements and is sufficiently stable to advance through the Technical Recommendation process.
-          </p>
-        
-        <p>
-          
-            This document was produced by a group operating under the 
-             
-                <a id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
-            
-          
-          
-          
-            
-              <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/55082/status" rel="disclosure">public list of any patent disclosures</a> 
-            
-            made in connection with the deliverables of the group; that page also includes instructions for 
-            disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains
-            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the
-            information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
-            6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
-          
-          
-        </p>
-        
-      
-    
-  
-</section><section id="toc"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a href="#terminology" class="tocxref"><span class="secno">2. </span>Terminology</a><ul class="toc"><li class="tocline"><a href="#conventions-used-in-this-document" class="tocxref"><span class="secno">2.1 </span>Conventions Used in This Document</a></li></ul></li><li class="tocline"><a href="#conformance" class="tocxref"><span class="secno">3. </span>Conformance</a></li><li class="tocline"><a href="#linked-data-platform-resources" class="tocxref"><span class="secno">4. </span>Linked Data Platform Resources</a><ul class="toc"><li class="tocline"><a href="#informative" class="tocxref"><span class="secno">4.1 </span>Informative</a></li><li class="tocline"><a href="#general" class="tocxref"><span class="secno">4.2 </span>General</a></li><li class="tocline"><a href="#http-get" class="tocxref"><span class="secno">4.3 </span>HTTP GET</a></li><li class="tocline"><a href="#http-post" class="tocxref"><span class="secno">4.4 </span>HTTP POST</a></li><li class="tocline"><a href="#http-put" class="tocxref"><span class="secno">4.5 </span>HTTP PUT</a></li><li class="tocline"><a href="#http-delete" class="tocxref"><span class="secno">4.6 </span>HTTP DELETE</a></li><li class="tocline"><a href="#http-head" class="tocxref"><span class="secno">4.7 </span>HTTP HEAD</a></li><li class="tocline"><a href="#http-patch" class="tocxref"><span class="secno">4.8 </span>HTTP PATCH</a></li><li class="tocline"><a href="#http-options" class="tocxref"><span class="secno">4.9 </span>HTTP OPTIONS</a></li><li class="tocline"><a href="#paging" class="tocxref"><span class="secno">4.10 </span>Paging</a><ul class="toc"><li class="tocline"><a href="#introduction-1" class="tocxref"><span class="secno">4.10.1 </span>Introduction</a></li><li class="tocline"><a href="#http-get-1" class="tocxref"><span class="secno">4.10.2 </span>HTTP GET</a></li><li class="tocline"><a href="#http-options-1" class="tocxref"><span class="secno">4.10.3 </span>HTTP OPTIONS</a></li></ul></li><li class="tocline"><a href="#resource-inlining-representing-multiple-resources-in-a-response" class="tocxref"><span class="secno">4.11 </span>Resource Inlining: Representing Multiple Resources in a Response</a><ul class="toc"><li class="tocline"><a href="#introduction-2" class="tocxref"><span class="secno">4.11.1 </span>Introduction</a></li><li class="tocline"><a href="#use-with-care" class="tocxref"><span class="secno">4.11.2 </span>Use with Care</a></li><li class="tocline"><a href="#http-get-2" class="tocxref"><span class="secno">4.11.3 </span>HTTP GET</a></li></ul></li></ul></li><li class="tocline"><a href="#linked-data-platform-containers" class="tocxref"><span class="secno">5. </span>Linked Data Platform Containers</a><ul class="toc"><li class="tocline"><a href="#informative-1" class="tocxref"><span class="secno">5.1 </span>Informative</a></li><li class="tocline"><a href="#general-1" class="tocxref"><span class="secno">5.2 </span>General</a></li><li class="tocline"><a href="#http-get-3" class="tocxref"><span class="secno">5.3 </span>HTTP GET</a></li><li class="tocline"><a href="#http-post-1" class="tocxref"><span class="secno">5.4 </span>HTTP POST</a></li><li class="tocline"><a href="#http-put-1" class="tocxref"><span class="secno">5.5 </span>HTTP PUT</a></li><li class="tocline"><a href="#http-delete-1" class="tocxref"><span class="secno">5.6 </span>HTTP DELETE</a></li><li class="tocline"><a href="#http-head-1" class="tocxref"><span class="secno">5.7 </span>HTTP HEAD</a></li><li class="tocline"><a href="#http-patch-1" class="tocxref"><span class="secno">5.8 </span>HTTP PATCH</a></li><li class="tocline"><a href="#http-options-2" class="tocxref"><span class="secno">5.9 </span>HTTP OPTIONS</a></li><li class="tocline"><a href="#member-inlining-returning-all-of-a-container-page-s-members-in-a-response" class="tocxref"><span class="secno">5.10 </span>Member Inlining: Returning All of a Container Page's Members in a Response</a><ul class="toc"><li class="tocline"><a href="#introduction-3" class="tocxref"><span class="secno">5.10.1 </span>Introduction</a></li><li class="tocline"><a href="#http-get-4" class="tocxref"><span class="secno">5.10.2 </span>HTTP GET</a></li></ul></li></ul></li><li class="tocline"><a href="#http-header-definitions" class="tocxref"><span class="secno">6. </span>HTTP Header Definitions</a><ul class="toc"><li class="tocline"><a href="#the-accept-post-response-header" class="tocxref"><span class="secno">6.1 </span>The Accept-Post Response Header</a></li></ul></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">B.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">B.2 </span>Informative references</a></li></ul></li></ul></section>
- 
-<section class="informative" typeof="bibo:Chapter" resource="#intro" rel="bibo:chapter" id="introduction">
-<!--OddPage--><h2 id="intro"><span class="secno">1. </span>Introduction</h2><p><em>This section is non-normative.</em></p>
-	<p>This document describes the use
-	of HTTP for accessing, updating, creating and deleting resources from
-	servers that expose their resources as Linked Data. &nbsp;It provides clarifications
-	and extensions of the four rules of Linked Data [<cite><a class="bibref" href="#bib-LINKED-DATA">LINKED-DATA</a></cite>]:</p>
-	<p>1. Use URIs as names for things</p>
-	<p>2. Use HTTP URIs so that people can look up those
-		names</p>
-	<p>3. When someone looks up a URI, provide useful
-		information, using the standards (<abbr title="Resource Description Framework">RDF</abbr>*, <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr>)</p>
-	<p>4. Include links to other URIs, so that they can
-		discover more things</p>
-	<p>This specification discusses standard HTTP and <abbr title="Resource Description Framework">RDF</abbr> techniques and best practices that you 
-	should use, and anti-patterns you should avoid, when constructing clients and servers that 
-	read and write Linked Data resources.</p> 
-	<p>A special type of <a title="Linked Data Platform Resource" href="#dfn-linked-data-platform-resource-1" class="internalDFN">Linked Data Platform Resource</a> is a 
-	<a title="Linked Data Platform Container" href="#dfn-linked-data-platform-container-1" class="internalDFN">Container</a>.  Containers are very useful 
-	in building application models involving collections of homogeneous resources.  For example, universities offer a collection of classes 
-	and have a collection of faculty members, each faculty member teaches a collection of courses, etc.  
-	This specification discusses how to work with containers.  Resources can be added to containers in 
-	several ways. As a special case, members can both be created and added to a container by overloading 
-	the POST operation (see <a href="#ldpc-HTTP_POST" class="sectionRef">section 5.4 </a>).</p>
-	<p>Another contribution of this specification is how to deal with large amounts of data.  
-	Depending on the server’s capabilities, a GET request on a Linked Data Platform Resource 
-	returns a set of pages and uses a convention to access any subsequent page (see <a href="#ldpr-Paging" class="sectionRef">section 4.10 </a>). </p>
-	<p>The intention of this document is to enable additional rules and layered groupings of rules as 
-	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>
-</section>
-	
-<section typeof="bibo:Chapter" resource="#terms" rel="bibo:chapter" id="terminology">
-<!--OddPage--><h2 id="terms"><span class="secno">2. </span>Terminology</h2>
-
-<p>Terminology is based on <abbr title="World Wide Web Consortium">W3C</abbr>'s Architecture of the World Wide Web [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>] and Hyper-text Transfer Protocol [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>].
-</p>
-  <dl class="glossary">
-	<dt>Link</dt>
-	<dd>A relationship between two resources when one resource (representation) refers to the other resource by means
-		of a URI [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>].
-		<p></p></dd>
-							
-	<dt>Linked Data</dt>
-	<dd>As defined by Tim Berners-Lee [<cite><a class="bibref" href="#bib-LINKED-DATA">LINKED-DATA</a></cite>].<p></p></dd>
-	
-	<dt><dfn id="dfn-linked-data-platform-resource">Linked Data Platform Resource</dfn> (<dfn id="dfn-linked-data-platform-resource-1"><abbr title="Linked Data Platform Resource">LDPR</abbr></dfn>)</dt>
-	<dd>HTTP resource whose state is represented in <abbr title="Resource Description Framework">RDF</abbr> that conforms to the simple lifecycle
-		patterns and conventions in <a href="#ldpr" class="sectionRef">section 4. </a>.<p></p></dd>
-		
-	<dt><dfn id="dfn-linked-data-platform-container">Linked Data Platform Container</dfn> (<dfn id="dfn-linked-data-platform-container-1"><abbr title="Linked Data Platform Container">LDPC</abbr></dfn>)</dt>
-	<dd>An <abbr title="Linked Data Platform Resource">LDPR</abbr> representing a collection of same-subject, same-predicate triples which is uniquely identified by a URI
-	that responds to client requests for creation, modification, and enumeration of its members.
-	<p></p></dd>
-		
-	<dt>Client</dt>
-	<dd>A program that establishes connections for the purpose of sending requests [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>].<p></p></dd>
-	
-	<dt>Server</dt>
-	<dd>An application
-		program that accepts connections in order to service requests by
-		sending back responses. 
-		<p>Any given program may be capable of being
-		both a client and a server; our use of these terms refers only to
-		the role being performed by the program for a particular
-		connection, rather than to the program's capabilities in general.
-		Likewise, any server may act as an origin server, proxy, gateway,
-		or tunnel, switching behavior based on the nature of each request
-		[<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>]. </p></dd>
-
-	<dt><dfn id="dfn-membership-triples">Membership triples</dfn></dt>
-	<dd>A set of triples in an <abbr title="Linked Data Platform Container">LDPC</abbr>'s state that lists its members.
-		The membership triples of a container all have the same
-		subject and predicate, and the objects of the membership triples identify
-		the container's members. 
-	<p></p></dd>
-	
-	<dt><dfn id="dfn-membership-subject">Membership subject</dfn></dt>
-	<dd>The subject of all a <abbr title="Linked Data Platform Container">LDPC</abbr>'s <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triples</a>.
-	<p></p></dd>
-	
-	<dt><dfn id="dfn-membership-predicate">Membership predicate</dfn></dt>
-	<dd>The predicate of all a <abbr title="Linked Data Platform Container">LDPC</abbr>'s <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triples</a>.
-	<p></p></dd>
-	
-	<dt><dfn id="dfn-page-resource">Page resource</dfn></dt>
-	<dd>A type of <abbr title="Linked Data Platform Resource">LDPR</abbr> that is associated to another <abbr title="Linked Data Platform Resource">LDPR</abbr> and whose representation 
-	includes a subset of the triples in the associated <abbr title="Linked Data Platform Resource">LDPR</abbr>.
-	<p></p></dd>
-	
-	<dt><dfn id="dfn-non-member-resource">Non-member resource</dfn></dt>
-	<dd>A resource associated with a <abbr title="Linked Data Platform Container">LDPC</abbr> by a server for the purpose of enabling clients to
-	retrieve a subset of the <abbr title="Linked Data Platform Container">LDPC</abbr>'s state, namely the subset that omits the <abbr title="Linked Data Platform Container">LDPC</abbr>'s membership triples.
-	In other words, the union of the non-member resource's state and the <abbr title="Linked Data Platform Container">LDPC</abbr>'s membership triples
-	exactly equals the <abbr title="Linked Data Platform Container">LDPC</abbr>'s state.
-	<p></p></dd>
-	
-	<dt><dfn id="dfn-resource-inlining">Resource inlining</dfn></dt>
-	<dd>
-		The practice of responding to a HTTP GET request made to a request URI <var>R<sub>0</sub></var> with
-		a representation that includes the state of <var>R<sub>0</sub></var>, the <em>entire</em> state of resources accessed through
-		<em>other</em> request URI(s) <var>R<sub>1</sub></var>...<var>R<sub>n</sub></var>, <em>and assertions</em> from the server 
-		identifying the additional resources whose
-		entire state has been provided.
-		<var>R<sub>1</sub></var>...<var>R<sub>n</sub></var> identify the inlined resource(s).
-		See <a href="#ldpr-inlining" class="sectionRef">section 4.11 </a> for details.
-	<p></p></dd>
-	
-	<dt><dfn id="dfn-member-inlining">Member inlining</dfn></dt>
-	<dd>A special case of <a title="Resource inlining" href="#dfn-resource-inlining" class="internalDFN">resource inlining</a>, where all members of a container on a given
-		page are inlined.  The response page may or may not include all of the container's members.
-		See <a href="#ldpc-inlining" class="sectionRef">section 5.10 </a> for details.
-	<p></p></dd>
-	
-  </dl>
-
-<section typeof="bibo:Chapter" resource="#conventions" rel="bibo:chapter" id="conventions-used-in-this-document">
-<h3 id="conventions"><span class="secno">2.1 </span>Conventions Used in This Document</h3>
-
-	<p>Sample resource representations are provided in <code>text/turtle</code>
-		format [<cite><a class="bibref" href="#bib-TURTLE">TURTLE</a></cite>].</p>
-	<p>Commonly used namespace prefixes:</p>
-	<pre style="word-wrap: break-word; white-space: pre-wrap;">	@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
-	@prefix rdf: &nbsp;  &nbsp;&lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
-	@prefix rdfs: &nbsp; &nbsp;&lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
-	@prefix ldp: &nbsp; &nbsp; &lt;http://www.w3.org/ns/ldp#&gt;.
-	@prefix xsd: &nbsp;  &nbsp;&lt;http://www.w3.org/2001/XMLSchema#&gt;.</pre>
-</section>
-</section>
-    
-<section id="conformance" typeof="bibo:Chapter" resource="#conformance" rel="bibo:chapter"><!--OddPage--><h2><span class="secno">3. </span>Conformance</h2>
-<p>
-  As well as sections marked as non-normative, all authoring guidelines, diagrams, examples,
-  and notes in this specification are non-normative. Everything else in this specification is
-  normative.
-</p>
-<p>
-  The key words <em class="rfc2119" title="MUST">MUST</em>, <em class="rfc2119" title="MUST NOT">MUST NOT</em>, <em class="rfc2119" title="REQUIRED">REQUIRED</em>, <em class="rfc2119" title="SHOULD">SHOULD</em>, <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em>, <em class="rfc2119" title="RECOMMENDED">RECOMMENDED</em>, <em class="rfc2119" title="MAY">MAY</em>,
-  and <em class="rfc2119" title="OPTIONAL">OPTIONAL</em> in this specification are to be interpreted as described in [<cite><a class="bibref" href="#bib-RFC2119">RFC2119</a></cite>].
-</p>
-
-
-<p>The status of the sections of Linked Data Platform 1.0 (this document) is as follows:</p>
-<ul>
-  <li>1. Introduction: <b>informative</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>informative</b></li> 
-  <li>B.1 Normative references: <b>normative</b></li>
-  <li>B.2 Informative references: <b>informative</b></li>
-</ul>
-
-<p>A conforming <b>LDP server</b> is an application program that processes HTTP 
-requests and generates HTTP responses that conform to the rules defined in <a href="#linked-data-platform-resources" class="sectionRef sec-ref">section 4. Linked Data Platform Resources</a>
-and <a href="#linked-data-platform-containers" class="sectionRef sec-ref">section 5. Linked Data Platform Containers</a>.</p>
-
-<p>A conforming <b>LDP client</b> is an application program that generates HTTP 
-requests and processes HTTP responses that conform to the rules defined in <a href="#linked-data-platform-resources" class="sectionRef sec-ref">section 4. Linked Data Platform Resources</a>
-and <a href="#linked-data-platform-containers" class="sectionRef sec-ref">section 5. Linked Data Platform Containers</a>.</p>
-
-</section>
-
-
-<section typeof="bibo:Chapter" resource="#ldpr" rel="bibo:chapter" id="linked-data-platform-resources">
-<!--OddPage--><h2 id="ldpr"><span class="secno">4. </span>Linked Data Platform Resources</h2>
-
-<section class="informative" typeof="bibo:Chapter" resource="#ldpr-informative" rel="bibo:chapter" id="informative">
-<h3 id="ldpr-informative"><span class="secno">4.1 </span>Informative</h3><p><em>This section is non-normative.</em></p>
-	<p>Linked Data Platform Resources (<dfn id="dfn-linked-data-platform-resources"><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 <abbr title="Linked Data Platform Resources">LDPRs</abbr> are accepted
-		and processed by <abbr title="Linked Data Platform Resource">LDPR</abbr> servers. Most <abbr title="Linked Data Platform Resources">LDPRs</abbr> 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 [<cite><a class="bibref" href="#bib-LINKED-DATA">LINKED-DATA</a></cite>];
-		others address additional needs.</p>
-	<p>The rules for Linked Data Platform Resources address basic
-		questions such as:</p>
-	<ul>
-		<li>What resource representations should be used?</li>
-		<li>How is optimistic collision detection handled for updates?</li>
-		<li>What should client expectations be for changes to linked-to resources,
-				such as type changes?</li>
-		<li>What can servers do to ease the burden of constraints for resource
-				creation?</li>
-		<li>How	do I GET the entries of a large resources broken up into pages?</li>
-	</ul>
-	<p>Additional informative guidance is available on the <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide" class="external " title="Deployment Guide" rel="nofollow">working group's wiki</a> that addresses deployment
-		questions such as:</p>
-	<ul>
-		<li>What literal value types should be used?</li>
-		<li>Are there some typical vocabularies that should be reused?</li>
-	</ul>
-	<p>The following sections define the rules and
-		guidelines for use of <abbr title="Linked Data Platform Resources">LDPRs</abbr>. This document also explains how to include
-		information about each member in the resource’s own representation
-		and how to paginate the resource representation if it gets too big.</p>
-
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpr-general" rel="bibo:chapter" id="general">
-<h3 id="ldpr-general"><span class="secno">4.2 </span>General</h3>
-		
-	<div id="ldpr-4_2_1" class="rule">4.2.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> at least be HTTP/1.1 conformant servers [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>].</div>
-	<div id="ldpr-4_2_2" class="rule">4.2.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> provide an <abbr title="Resource Description Framework">RDF</abbr> representation for <abbr title="Linked Data Platform Resources">LDPRs</abbr>. 
-	The HTTP <code>Request-URI</code> of the <abbr title="Linked Data Platform Resource">LDPR</abbr> is typically the subject of most triples in the response.
-	</div>
-	<div id="ldpr-4_2_3" class="rule">4.2.3 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> host a mixture of <abbr title="Linked Data Platform Resources">LDPRs</abbr> and non-<abbr title="Linked Data Platform Resources">LDPRs</abbr>. For example, it
-		is common for <abbr title="Linked Data Platform Resource">LDPR</abbr> servers to need to host binary or text resources
-		that do not have useful <abbr title="Resource Description Framework">RDF</abbr> representations.
-	</div>
-
-	<div id="ldpr-4_2_4" class="rule">4.2.4 <abbr title="Linked Data Platform Resources">LDPRs</abbr> <em class="rfc2119" title="SHOULD">SHOULD</em> reuse existing vocabularies instead of creating
-		their own duplicate vocabulary terms.  In addition to this general rule, some specific cases are
-		covered by other conformance rules.
-	</div>
-	<div id="ldpr-4_2_4_1" class="rule">4.2.4.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> predicates <em class="rfc2119" title="SHOULD">SHOULD</em> use standard vocabularies such as Dublin Core
-		[<cite><a class="bibref" href="#bib-DC-TERMS">DC-TERMS</a></cite>], <abbr title="Resource Description Framework">RDF</abbr> [<cite><a class="bibref" href="#bib-RDF-CONCEPTS">RDF-CONCEPTS</a></cite>] and <abbr title="Resource Description Framework">RDF</abbr> Schema [<cite><a class="bibref" href="#bib-RDF-SCHEMA">RDF-SCHEMA</a></cite>], whenever
-		possible.
-	</div>
-	<div id="ldpr-4_2_5" class="rule">4.2.5 <abbr title="Linked Data Platform Resource">LDPR</abbr> representations <em class="rfc2119" title="SHOULD">SHOULD</em> have at least one <code>rdf:type</code>
-		set explicitly. &nbsp;This makes the representations much more useful to
-		client applications that don’t support inferencing.
-	</div>
-	<div id="ldpr-4_2_6" class="rule">4.2.6 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> support standard representations beyond those
-		necessary to conform to this specification. These
-		could be other <abbr title="Resource Description Framework">RDF</abbr> formats, like N3 or NTriples, but non-<abbr title="Resource Description Framework">RDF</abbr> formats
-		like HTML [<cite><a class="bibref" href="#bib-HTML401">HTML401</a></cite>] and JSON [<cite><a class="bibref" href="#bib-RFC4627">RFC4627</a></cite>] would likely be common.
-	</div>		
-	<div id="ldpr-4_2_7" class="rule">4.2.7 <abbr title="Linked Data Platform Resources">LDPRs</abbr> <em class="rfc2119" title="MAY">MAY</em> be created, updated and deleted using methods not defined in
-		this document, for example through application-specific means, <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr>
-		UPDATE, etc. [<cite><a class="bibref" href="#bib-SPARQL-UPDATE">SPARQL-UPDATE</a></cite>], as long as those methods do not conflict with this specification's 
-		normative requirements.
-	</div>
-	<div id="ldpr-4_2_8" class="rule">4.2.8 <abbr title="Linked Data Platform Resource">LDPR</abbr> server responses <em class="rfc2119" title="MUST">MUST</em> use entity tags (either weak or strong 
-ones) as response <code>ETag</code> header values.
-	</div>
-	<div id="ldpr-4_2_9" class="rule">4.2.9 <abbr title="Linked Data Platform Resource">LDPR</abbr>
-		servers <em class="rfc2119" title="SHOULD">SHOULD</em> enable simple creation and modification of <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
-		It is
-		common for <abbr title="Linked Data Platform Resource">LDPR</abbr> servers to put restrictions on representations – for
-		example, the range of <code>rdf:type</code> predicates, datatypes of
-		the objects of predicates, and the number of occurrences of predicates in an <abbr title="Linked Data Platform Resource">LDPR</abbr>, but
-		servers <em class="rfc2119" title="SHOULD">SHOULD</em> minimize those restrictions. &nbsp;Enforcement of
-		more complex constraints will greatly restrict the set of clients
-		that can modify resources. For some server applications, excessive
-		constraints on modification of resources may be required.
-	</div>
-	<div id="ldpr-4_2_10" class="rule">4.2.10 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers
-		<em class="rfc2119" title="MUST">MUST</em> advertise their LDP support by exposing a HTTP <code>Link</code> header
-		with a target URI of <code>http://www.w3.org/ns/ldp/Resource</code>, and
-		a link relation type of <code>type</code> (that is, <code>rel="type"</code>)
-		in all responses to requests made 
-		to the resource's HTTP <code>Request-URI</code>. This is notionally equivalent to the
-		presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in the resource.
-		The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP specification in a way
-		that clients can introspect dynamically at run-time.  Conservative clients should note that 
-		<a href="#ldpr-4_2_3">a server can host a mixture of <abbr title="Linked Data Platform Resources">LDPRs</abbr> and other resources</a>, and therefore there is no implication
-		that LDP support advertised on one HTTP <code>Request-URI</code> means that other 
-		resources on the same server are also <abbr title="Linked Data Platform Resources">LDPRs</abbr>.  Each HTTP <code>Request-URI</code> needs to be 
-		individually introspected by a conservative client, in the absence of outside information.
-	</div>
-	<div id="ldpr-4_2_11" class="rule">4.2.11 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers
-		<em class="rfc2119" title="MUST NOT">MUST NOT</em> 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 [<cite><a class="bibref" href="#bib-RDF-CONCEPTS">RDF-CONCEPTS</a></cite>].  The practical implication is that all content defined by LDP
-		must be explicitly represented. 
-	</div>
-	<div id="ldpr-4_2_12" class="rule">4.2.12 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> assign the default base-URI for [<cite><a class="bibref" href="#bib-RFC3987">RFC3987</a></cite>] relative-URI resolution to be the HTTP 
-		<code>Request-URI</code> when the resource already exists, and to the URI of the created resource when the request results 
-		in the creation of a new resource.
-	</div>
-
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpr-HTTP_GET" rel="bibo:chapter" id="http-get">
-<h3 id="ldpr-HTTP_GET"><span class="secno">4.3 </span>HTTP GET</h3>
-	<div id="ldpr-4_3_1" class="rule">4.3.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> support the HTTP <code>GET</code> Method for <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
-	</div>
-	<div id="ldpr-4_3_2" class="rule">4.3.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> support the HTTP response headers defined in 
-		<a href="#ldpr-HTTP_OPTIONS" class="sectionRef">section 4.9 </a>.
-	</div>
-	<div id="ldpr-4_3_3" class="rule">4.3.3 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> provide a <code>text/turtle</code>
-		representation of the requested <abbr title="Linked Data Platform Resource">LDPR</abbr> [<cite><a class="bibref" href="#bib-TURTLE">TURTLE</a></cite>].
-	</div>
-	<div id="ldpr-4_3_4" class="rule">4.3.4 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> provide 
-		representations of the requested <abbr title="Linked Data Platform Resource">LDPR</abbr> beyond those
-		necessary to conform to this specification, using standard HTTP content negotiation ([<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] Section 12 - Content Negotiation). 
-		If the client does not indicate a preference, <code>text/turtle</code> <em class="rfc2119" title="SHOULD">SHOULD</em> be returned.
-	</div>
-	<div id="ldpr-4_3_5" class="rule">4.3.5 In the absence of special knowledge of the application or domain, <abbr title="Linked Data Platform Resource">LDPR</abbr>
-		clients <em class="rfc2119" title="MUST">MUST</em> assume that any <abbr title="Linked Data Platform Resource">LDPR</abbr> can have multiple values for <code>rdf:type</code>.
-	</div>
-	<div id="ldpr-4_3_6" class="rule">4.3.6 In the absence of special knowledge of the application or domain, <abbr title="Linked Data Platform Resource">LDPR</abbr>
-		clients <em class="rfc2119" title="MUST">MUST</em> assume that the <code>rdf:type</code> values
-		of a given <abbr title="Linked Data Platform Resource">LDPR</abbr> can change over time.
-	</div>
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpr-HTTP_POST" rel="bibo:chapter" id="http-post">
-<h3 id="ldpr-HTTP_POST"><span class="secno">4.4 </span>HTTP POST</h3>
-	<p>This specification adds no new requirements on HTTP <code>POST</code> for <abbr title="Linked Data Platform Resources">LDPRs</abbr> 
-		even when the <abbr title="Linked Data Platform Resource">LDPR</abbr> supports that method.  This specification does not impose any
-		new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>
-	<p>Creation of <abbr title="Linked Data Platform Resources">LDPRs</abbr> can be done via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef">section 5.4 </a>) or
-		<code>PUT</code> (<a href="#ldpc-HTTP_PUT" class="sectionRef">section 5.5 </a>) to a <abbr title="Linked Data Platform Container">LDPC</abbr>, see those 
-		sections for more details.</p>
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpr-HTTP_PUT" rel="bibo:chapter" id="http-put">
-<h3 id="ldpr-HTTP_PUT"><span class="secno">4.5 </span>HTTP PUT</h3>
-	<p>This specification imposes the following new requirements on HTTP <code>PUT</code> for <abbr title="Linked Data Platform Resources">LDPRs</abbr> 
-		only when the <abbr title="Linked Data Platform Resource">LDPR</abbr> supports that method.  This specification does not impose any
-		new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>
-		
-	<div id="ldpr-4_5_1" class="rule">4.5.1 If HTTP <code>PUT</code> is performed on an existing resource, <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em>
-		replace the entire persistent state of the identified resource with
-		the entity representation in the body of the request. 
-		<abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> ignore server managed properties such as <code>dcterms:modified</code> 
-		and <code>dcterms:creator</code> if they are not under
-		client control. Any <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that wish
-		to support a more sophisticated merge of data provided by the client
-		with existing state stored on the server for a resource <em class="rfc2119" title="MUST">MUST</em> use HTTP
-		<code>PATCH</code>, not HTTP <code>PUT</code>.
-	</div>
-		
-	<div id="ldpr-4_5_2" class="rule">4.5.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> clients <em class="rfc2119" title="SHOULD">SHOULD</em> use the HTTP <code>If-Match</code>
-		header and HTTP <code>ETags</code> to ensure it isn’t
-		modifying a resource that has changed since the client last retrieved
-		its representation. <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
-		to detect collisions. <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> respond with status code 412
-		(Condition Failed) if <code>ETag</code>s fail to match when there are no other
-		errors with the request [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>].  <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that require conditional requests <em class="rfc2119" title="MUST">MUST</em> respond with status code 428
-		(Precondition Required) when the absence of a precondition is the only reason for rejecting the request [<cite><a class="bibref" href="#bib-RFC6585">RFC6585</a></cite>].
-	</div>
-	<div id="ldpr-4_5_3" class="rule">4.5.3 <abbr title="Linked Data Platform Resource">LDPR</abbr> clients <em class="rfc2119" title="SHOULD">SHOULD</em> always assume that the set of predicates for a
-		resource of a particular type at an arbitrary server is open, in the
-		sense that different resources of the same type may not all have the
-		same set of predicates in their triples, and the set of predicates that
-		are used in the state of any one resource is not limited to any pre-defined
-		set.
-	</div>
-	<div id="ldpr-4_5_4" class="rule">4.5.4 <abbr title="Linked Data Platform Resource">LDPR</abbr> clients <em class="rfc2119" title="SHOULD">SHOULD</em> assume that an <abbr title="Linked Data Platform Resource">LDPR</abbr> server could discard triples
-		whose predicates the server does not recognize or otherwise chooses
-		not to persist. In other words, <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> restrict themselves
-		to a known set of predicates, but <abbr title="Linked Data Platform Resource">LDPR</abbr> clients <em class="rfc2119" title="MUST NOT">MUST NOT</em> restrict themselves to a known set of predicates 
-		when their intent is to perform a later HTTP <code>PUT</code> to update the resource.
-	</div>
-	<div id="ldpr-4_5_5" class="rule">4.5.5 An <abbr title="Linked Data Platform Resource">LDPR</abbr> client <em class="rfc2119" title="MUST">MUST</em> preserve all triples retrieved using HTTP <code>GET</code> that
-		it doesn’t change whether it understands the predicates or not, when
-		its intent is to perform an update using HTTP <code>PUT</code>. &nbsp;The use of HTTP
-		<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
-		[<cite><a class="bibref" href="#bib-RFC5789">RFC5789</a></cite>].
-	</div>
-	<div id="ldpr-4_5_6" class="rule">4.5.6 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> choose to allow the creation of new resources using HTTP <code>PUT</code>.
-	</div>
-	<div id="ldpr-4_5_7" class="rule">4.5.7 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> allow clients to update resources without
-		requiring detailed knowledge of server-specific constraints. &nbsp;
-		This is a consequence of the requirement to <a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
-	</div>		
-</section>
-		
-<section typeof="bibo:Chapter" resource="#ldpr-HTTP_DELETE" rel="bibo:chapter" id="http-delete">
-<h3 id="ldpr-HTTP_DELETE"><span class="secno">4.6 </span>HTTP DELETE</h3>
-	<p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for <abbr title="Linked Data Platform Resources">LDPRs</abbr> 
-		only when the <abbr title="Linked Data Platform Resource">LDPR</abbr> supports that method.  This specification does not impose any
-		new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>
-	<p>Additional requirements on HTTP <code>DELETE</code> of <abbr title="Linked Data Platform Resources">LDPRs</abbr> within containers can be found in
-	<a href="#ldpc-HTTP_DELETE" class="sectionRef">section 5.6 </a>.</p>
-		
-	<div id="ldpr-4_6_1" class="rule">4.6.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> remove the resource identified by the <code>Request-URI</code>.
-		After a successful HTTP <code>DELETE</code>, a subsequent HTTP <code>GET</code> on the same
-		<code>Request-URI</code> <em class="rfc2119" title="MUST">MUST</em> result in a 404 (Not found) or 410 (Gone) status
-		code. Clients <em class="rfc2119" title="SHOULD">SHOULD</em> note that servers <em class="rfc2119" title="MAY">MAY</em> reuse a URI under some circumstances.
-	</div>
-	
-	<div id="ldpr-4_6_2" class="rule">4.6.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> alter the state of other resources as a result of an
-		HTTP <code>DELETE</code> request. For example, it is acceptable for the server to
-		remove triples from other resources whose subject or object is the
-		deleted resource. It is also acceptable and common for <abbr title="Linked Data Platform Resource">LDPR</abbr> servers to
-		not do this – behavior is server application specific.
-	</div>
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpr-HTTP_HEAD" rel="bibo:chapter" id="http-head">
-<h3 id="ldpr-HTTP_HEAD"><span class="secno">4.7 </span>HTTP HEAD</h3>
-	<p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
-		<code>HEAD</code> responses include the same headers as <code>GET</code> responses.  
-		Thus, implementers should also carefully read <a href="#ldpr-HTTP_GET" class="sectionRef">section 4.3 </a> 
-		and <a href="#ldpr-HTTP_OPTIONS" class="sectionRef">section 4.9 </a>.</p>
-	<div id="ldpr-4_7_1" class="rule">4.7.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> support the HTTP <code>HEAD</code> method.</div>
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpr-HTTP_PATCH" rel="bibo:chapter" id="http-patch">
-<h3 id="ldpr-HTTP_PATCH"><span class="secno">4.8 </span>HTTP PATCH</h3>
-	<p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for <abbr title="Linked Data Platform Resources">LDPRs</abbr> 
-		only when the <abbr title="Linked Data Platform Resource">LDPR</abbr> supports that method.  This specification does not impose any
-		new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>	
-	<div id="ldpr-4_8_1" class="rule">4.8.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> implement HTTP <code>PATCH</code> to allow modifications,
-		especially partial replacement, of their resources [<cite><a class="bibref" href="#bib-RFC5789">RFC5789</a></cite>]. No
-		minimal set of patch document formats is mandated by this document.
-	</div>
-	<div id="ldpr-4_8_2" class="rule">4.8.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> allow clients to update resources without
-		requiring detailed knowledge of server-specific constraints. &nbsp;
-		This is a consequence of the requirement to <a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
-	</div>
-	<div id="ldpr-4_8_3" class="rule">4.8.3 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> allow clients to create new resources using <code>PATCH</code>.
-		<a href="#ldpc-HTTP_POST"><code>POST</code> (to an <abbr title="Linked Data Platform Container">LDPC</abbr>)</a> and/or <a href="#ldpc-HTTP_PUT"><code>PUT</code></a> should be used as the standard way to create new <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
-	</div>
-	<div id="ldpr-4_8_4" class="rule">4.8.4 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that support <code>PATCH</code> <em class="rfc2119" title="MUST">MUST</em>
-		include an <code>Accept-Patch</code> HTTP response header [<cite><a class="bibref" href="#bib-RFC5789">RFC5789</a></cite>] on HTTP <code>OPTIONS</code>
-		requests, listing patch document media type(s) supported by the server.
-	</div>
-
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpr-HTTP_OPTIONS" rel="bibo:chapter" id="http-options">
-<h3 id="ldpr-HTTP_OPTIONS"><span class="secno">4.9 </span>HTTP OPTIONS</h3>
-	<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for <abbr title="Linked Data Platform Resources">LDPRs</abbr> 
-		beyond those in [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>].  Other sections of this specification, for example 
-		<a href="#ldpr-HTTP_PATCH">PATCH</a>,
-		<a href="#header-accept-post">Accept-Post</a>
-		and <a href="#ldpr-paging-HTTP_OPTIONS">Paging</a>,
-		add other requirements on <code>OPTIONS</code> responses.
-		</p>
-
-	<div id="ldpr-4_9_1" class="rule">4.9.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> support the HTTP <code>OPTIONS</code> method.</div>		
-	<div id="ldpr-4_9_2" class="rule">4.9.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> indicate their support for HTTP Methods by
-		responding to a HTTP <code>OPTIONS</code> request on the <abbr title="Linked Data Platform Resource">LDPR</abbr>’s URL with the HTTP
-		Method tokens in the HTTP response header <code>Allow</code>.
-	</div>
-		
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpr-Paging" rel="bibo:chapter" id="paging">
-<h3 id="ldpr-Paging"><span class="secno">4.10 </span>Paging</h3>
-
-<section class="informative" typeof="bibo:Chapter" resource="#ldpr-PagingIntro" rel="bibo:chapter" id="introduction-1">
-<h4 id="ldpr-PagingIntro"><span class="secno">4.10.1 </span>Introduction</h4><p><em>This section is non-normative.</em></p>
-	<p>It sometimes happens that a
-		resource is too large to reasonably transmit its representation in a
-		single HTTP response. This will be especially true if the resource
-		representation includes many triples both from its own representation and
-		from the representations of any <a title="Resource inlining" href="#dfn-resource-inlining" class="internalDFN">inlined resources</a>. A client could anticipate that a resource will be too large -
-		for example, a client tool that accesses defects may assume that an
-		individual defect will usually be of sufficiently constrained size
-		that it makes sense to request all of it at once, but that the
-		container of all the defects ever created will typically be too big.
-		Alternatively, a server could recognize that a resource that has been
-		requested is too big to return in a single message.</p>
-	<p>
-		To address this problem, <abbr title="Linked Data Platform Resources">LDPRs</abbr> should support a technique called Paging. &nbsp;Paging can be achieved with a
-		simple <abbr title="Resource Description Framework">RDF</abbr> pattern. For each resource, <code>&lt;resourceURL&gt;</code>, we define a new
-		'first page' resource.  In this example, its URL will be <code>&lt;resourceURL&gt;?firstPage</code>,
-		but servers are free to construct the URL as they see fit.
-		The triples in the representation of the each page
-		are typically a subset of the triples in the resource
-		- same subject, predicate and object.
-	</p>
-	<p><abbr title="Linked Data Platform Resource">LDPR</abbr> servers may respond to requests for a
-		resource by redirecting the client to the first page resource –
-		using a 303 “See Other” redirect to the actual URL for the page
-		resource.  Alternatively, clients may introspect the resource for a paged representation 
-		and use it preferentially when available.</p>
-	<p>
-		Looking at an example resource representing Example Co.'s customer
-		relationship data, we’ll split the response across two pages. &nbsp;
-		To find the URL of the first page, the client makes a <code>OPTIONS</code> request
-		to the resource's URL, and in the response looks for a HTTP <code>Link</code>
-		header with <code>rel="first"</code>; the target URI in the header is the URL
-		of the first page resource.
-		The client then 
-		requests the first page as <code>http://example.org/customer-relations?firstPage</code>:
-	</p>
-
-<div class="example"><div class="example-title"><span>Example 1</span></div><pre class="example"># The following is the representation of
-#    http://example.org/customer-relations?firstPage
-@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
-@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
-@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
-@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-@prefix o: &lt;http://example.org/ontology/&gt;.
-
-&lt;http://example.org/customer-relations&gt;
-   a o:CustomerRelations;
-&nbsp; &nbsp;dcterms:title "The customer information for Example Co.";
- &nbsp; o:client &lt;client#JohnZSmith&gt;, &lt;client#BettyASmith&gt;, &lt;client#JoanRSmith&gt;. 
-
-&lt;http://example.org/customer-relations?firstPage&gt;
-   a ldp:Page;
- &nbsp; ldp:pageOf &lt;http://example.org/customer-relations&gt;;
- &nbsp; ldp:nextPage &lt;http://example.org/customer-relations?p=2&gt;.
-
-&lt;client#JohnZSmith&gt;
-&nbsp;  a foaf:Person;
-   o:status o:ActiveCustomer;
- &nbsp; foaf:name "John Z. Smith".
-&lt;client#BettyASmith&gt;
-&nbsp;  a foaf:Person;
-   o:status o:PreviousCustomer;
- &nbsp; foaf:name "Betty A. Smith".
- &lt;client#BettyASmith&gt;
-&nbsp;  a foaf:Person;
-   o:status o:PotentialCustomer;
- &nbsp; foaf:name "Joan R. Smith".</pre></div>
-
-	<p>
-		The server determines the size of the pages using application specific methods not defined
-		within this specificiation. Note also, the actual name for the query parameter (such as ?p=2) is also
-		defined by the server and not this specification.
-	</p>
-	<p>
-		The following example is the result of retrieving the representation
-		for the next page:
-	</p>
-
-<div class="example"><div class="example-title"><span>Example 2</span></div><pre class="example"># The following is the representation of
-#  http://example.org/customer-relations?p=2
-@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
-@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
-@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
-@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-@prefix o: &lt;http://example.org/ontology/&gt;.
-
-&lt;http://example.org/customer-relations&gt;
- &nbsp; o:client &lt;client#GlenWSmith&gt;, &lt;client#AlfredESmith&gt;. 
- 
-&lt;http://example.org/customer-relations?p=2&gt;
- &nbsp; a ldp:Page;
-&nbsp; &nbsp;ldp:pageOf &lt;http://example.org/customer-relations&gt;;
-&nbsp; &nbsp;ldp:nextPage rdf:nil.
-
-&lt;client#GlenWSmith&gt;
-&nbsp;  a foaf:Person;
-   o:status o:ActiveCustomer, o:GoldCustomer;
- &nbsp; foaf:name "Glen W. Smith".
-
-&lt;client#AlfredESmith&gt;
-&nbsp;  a foaf:Person;
-   o:status o:ActiveCustomer, o:BronzeCustomer;
- &nbsp; foaf:name "Alfred E. Smith".</pre></div>
-	<p>
-		In this example, there are only two customers provided in the
-		final page. &nbsp;To indicate this is the last page, a value of <code>rdf:nil</code> is used for the <code>ldp:nextPage</code>
-		predicate of the page resource.
-	</p>
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpr-PagingGET" rel="bibo:chapter" id="http-get-1">
-<h4 id="ldpr-PagingGET"><span class="secno">4.10.2 </span>HTTP GET</h4>
-<p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef">section 4.3 </a> on HTTP <code>GET</code>, <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that support paging must also follow the requirements in this section</p>
-
-	<div id="ldpr-pagingGET-1" class="rule">4.10.2.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> allow clients to retrieve large <abbr title="Linked Data Platform Resources">LDPRs</abbr> in
-		pages. In responses to <code>GET</code> requests with an <abbr title="Linked Data Platform Resource">LDPR</abbr> as the <code>Request-URI</code>, 
-		<abbr title="Linked Data Platform Resource">LDPR</abbr> servers that support paging <em class="rfc2119" title="SHOULD">SHOULD</em> provide an HTTP <code>Link</code>
-		header whose target URI is the first page resource, and whose link relation type is <code>first</code> [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>]. 
-		This is the mechanism by which clients discover the URL of the first page.  If no such <code>Link</code>
-		header is present, then conservative clients will assume that the <abbr title="Linked Data Platform Resource">LDPR</abbr> does not support paging.
-		For example, if there is a <abbr title="Linked Data Platform Resource">LDPR</abbr> with URL <code>&lt;resourceURL&gt;</code> that supports paging and whose
-		first page URL is <code>&lt;resourceURL&gt;?theFirstPage</code>, then the corresponding link header
-		would be <code>Link: &lt;?theFirstPage&gt;;rel="first"</code>.
-		The representation for any page, including the first, will include
-		the URL for the next page.&nbsp;See <a href="#ldpr-Paging" class="sectionRef">section 4.10 </a> for additional details.
-	</div>
-	<div id="ldpr-pagingGET-2" class="rule">4.10.2.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> split the response representation of any <abbr title="Linked Data Platform Resource">LDPR</abbr>. 
-		This is known as
-		server-initiated paging. See <a href="#ldpr-Paging" class="sectionRef">section 4.10 </a> for
-		additional details.
-	</div>
-	<div id="ldpr-pagingGET-3" class="rule">4.10.2.3 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that initiate paging <em class="rfc2119" title="SHOULD">SHOULD</em> respond to requests for a <abbr title="Linked Data Platform Resource">LDPR</abbr>
-		by redirecting the client to the first page resource using a <code>303 See
-		Other</code> response with an HTTP <code>Location</code> header providing the first page resource URL.
-	</div>
-	<div id="ldpr-pagingGET-4" class="rule">4.10.2.4 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that support paging <em class="rfc2119" title="MUST">MUST</em> include a representation for the page resource.
-	</div>
-	<div id="ldpr-pagingGET-4_1" class="rule">4.10.2.4.1 The page resource representation <em class="rfc2119" title="MUST">MUST</em> have one triple with the subject
-		of the page, predicate of <code>ldp:nextPage</code> and
-		object being the URL for the subsequent page.
-<div class="example"><div class="example-title"><span>Example 3</span></div><pre class="example">&lt;http://example.org/customer-relations?firstPage&gt;
-    ldp:nextPage  &lt;http://example.org/customer-relations?p=2&gt; .</pre></div>
-	</div>
-	<div id="ldpr-pagingGET-4_2" class="rule">4.10.2.4.2 The last page resource representation <em class="rfc2119" title="MUST">MUST</em> have one triple with the subject of the 
-	    last page, predicate of <code>ldp:nextPage</code> and object being <code>rdf:nil</code>.
-<div class="example"><div class="example-title"><span>Example 4</span></div><pre class="example">&lt;http://example.org/customer-relations?p=2&gt;
-    ldp:nextPage  rdf:nil .</pre></div>	    
-	</div>
-	<div id="ldpr-pagingGET-4_3" class="rule">4.10.2.4.3 The page resource representation <em class="rfc2119" title="SHOULD">SHOULD</em> have one triple to indicate its
-		type, whose subject is the URL of the page, whose predicate is <code>rdf:type</code> and object is <code>ldp:Page</code>.
-		It also <em class="rfc2119" title="SHOULD">SHOULD</em> have 1 triple to indicate the resource it is paging,
-		whose &nbsp;subject is the URL of the page, predicate is <code>ldp:pageOf</code>,
-		and object is the URL of the <abbr title="Linked Data Platform Resource">LDPR</abbr>.
-<div class="example"><div class="example-title"><span>Example 5</span></div><pre class="example">&lt;http://example.org/customer-relations?firstPage&gt;
-    rdf:type    ldp:Page;
-    ldp:pageOf  &lt;http://example.org/customer-relations&gt;.</pre></div>
-	</div>
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpr-paging-HTTP_OPTIONS" rel="bibo:chapter" id="http-options-1">
-<h4 id="ldpr-paging-HTTP_OPTIONS"><span class="secno">4.10.3 </span>HTTP OPTIONS</h4>
-
-<div id="ldpr-4_10_3_1" class="rule">4.10.3.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> indicate their support for client-initiated paging by
-	responding to a HTTP <code>OPTIONS</code> request on the <abbr title="Linked Data Platform Resource">LDPR</abbr>’s URL with the HTTP
-	response header for link relations using the header name of <code>Link</code> and link relation type <code>first</code> [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
-</div>
-</section>
-
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpr-inlining" rel="bibo:chapter" id="resource-inlining-representing-multiple-resources-in-a-response">
-<h3 id="ldpr-inlining"><span class="secno">4.11 </span>Resource Inlining: Representing Multiple Resources in a Response</h3>
-
-	<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 href="#dfn-resource-inlining" class="internalDFN">resource inlining</a> to save application latency
-		and server/network load in controlled environments.</li>
-		</ul>
-		<p>Feedback, both positive and negative, is invited by sending email to the mailing list 
-		in <a href="#sotd">Status of This Document</a>.</p>
-	</div>
-
-<section class="informative" typeof="bibo:Chapter" resource="#ldpr-InliningIntro" rel="bibo:chapter" id="introduction-2">
-<h4 id="ldpr-InliningIntro"><span class="secno">4.11.1 </span>Introduction</h4><p><em>This section is non-normative.</em></p>
-	<p>Servers whose resources are relatively granular may wish to optimistically provide more information
-		in a response than what the client actually requested, in order to reduce the average number of client
-		application HTTP flows.  LDP provides some basic building blocks to enable
-		this, that implementations can re-use to build complete solutions, and they may serve as 
-		complete solutions in applications with sufficient controls on resource content.
-		These building blocks are <a href="#dfn-resource-inlining" class="internalDFN">resource inlining</a> and <a href="#dfn-member-inlining" class="internalDFN">member inlining</a>.
-	</p>
-	
-	<p>LDP does not provide clients with any way to detect whether or not the server is capable of 
-		inlining (all its resources or any specific resource), nor does it provide clients 
-		with any way to influence which (if any) resources are inlined in any given response.
-	</p>
-	
-	<p>
-		Servers can return extra triples on any response, but fail to meet the definition of <a href="#dfn-resource-inlining" class="internalDFN">resource inlining</a>, 
-		by either returning a subset of the other resource(s) triples or by failing to assert that
-		all triples were included (even through they were).  Clients might still find the extra
-		information useful, but the only way for clients to be sure they had all available 
-		information would be to make a HTTP <code>GET</code> request against all the other resource(s).
-		In some applications, knowing that these requests are unnecessary saves significant latency
-		and server/network load.
-	</p>
-</section> <!-- h3 -->
-
-<section class="informative" typeof="bibo:Chapter" resource="#ldpr-InliningWarnings" rel="bibo:chapter" id="use-with-care">
-<h4 id="ldpr-InliningWarnings"><span class="secno">4.11.2 </span>Use with Care</h4><p><em>This section is non-normative.</em></p>
-	<p>The building blocks LDP provides can only be safely used if certain assumptions hold.  
-	Said another way, resource inlining solves a subset of scenarios, not all scenarios in the general case —
-	so if you care about any of the following in a given application, your server should avoid returning
-	<em>any</em> triples beyond those found at the HTTP <code>Request-URI</code>.
-	</p>
-	<ul>
-	<li><p>
-		Provenance is lost: because <abbr title="Resource Description Framework">RDF</abbr> graphs from multiple HTTP resources are merged in the
-		response without attributing each statement to its originating graph (i.e. without quotation),
-		it is impossible for a client to reliably know which
-		triples came from which HTTP resource(s).  A general solution allowing quotation is
-		<abbr title="Resource Description Framework">RDF</abbr> Datasets; that is expected to be standardized independently, and can be used in these cases
-		once it is available.
-	</p></li>
-	<li><p>
-		The response may contain contradictions that are trivially obvious (or subtle), and those may or 
-		may not be a problem at the application level.  For a trivial example, two triples may have
-		identical subjects and predicates but different objects: "75F is too hot"; "75F is too cold".
-		Again, quotation via <abbr title="Resource Description Framework">RDF</abbr> Datasets (or any equivalent mechanism) is believed to provide a 
-		long term solution once standardized.
-	</p></li>
-	</ul>
-</section> <!-- h3 -->
-
-<section typeof="bibo:Chapter" resource="#ldpr-InliningGET" rel="bibo:chapter" id="http-get-2">
-<h4 id="ldpr-InliningGET"><span class="secno">4.11.3 </span>HTTP GET</h4>
-	<p>In addition to the requirements set forth in other sections, 
-		<abbr title="Linked Data Platform Resource">LDPR</abbr> servers that support <a href="#dfn-resource-inlining" class="internalDFN">resource inlining</a>
-		must also follow the requirements in this section.</p>
-
-	<div id="ldpr-4_11_3_1" class="rule">4.11.3.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that support <a href="#dfn-resource-inlining" class="internalDFN">resource inlining</a> <em class="rfc2119" title="MUST">MUST</em> 
-		include a <code>ldp:Page</code> resource in the representation describing the set of inlined resources, 
-		whether or not the representation contains subsequent pages.  The <code>ldp:Page</code> resource conceptually contains
-		metadata about the representation; it is usually not part of the HTTP resource's state, and its presence does not indicate that
-		the <abbr title="Linked Data Platform Resource">LDPR</abbr> server supports <a href="#ldpr-Paging">paging</a> in general.  
-		<abbr title="Linked Data Platform Resource">LDPR</abbr> servers that include the <code>ldp:Page</code> resource for inlining and also support 
-		paging <em class="rfc2119" title="MUST">MUST</em> use the same <code>ldp:Page</code> resource for the triples required by both,
-		in order to minimize client code complexity.
-		The <code>ldp:Page</code> resource's triples are the LDP-defined means by which the servers communicate to LDP clients 
-		the set of HTTP resources whose state is included in a representation, allowing clients to avoid HTTP <code>GET</code>
-		requests for them.
-	</div>
-
-	<div id="ldpr-4_11_3_2" class="rule">4.11.3.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that support <a href="#dfn-resource-inlining" class="internalDFN">resource inlining</a> <em class="rfc2119" title="MUST">MUST</em> 
-		include the <code>ldp:Page</code> resource described in <a href="#ldpr-4_11_3_1">section 4.11.3.1</a> 
-		one triple for each inlined resource, 
-		whose subject is the <code>ldp:Page</code> resource URI,
-		whose predicate is <code>ldp:inlinedResource</code>, and
-		whose object is the HTTP <code>Request-URI</code> of an inlined resource [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>].
-	</div>
-
-	<div id="ldpr-4_11_3_3" class="rule">4.11.3.3 <abbr title="Linked Data Platform Resource">LDPR</abbr> clients <em class="rfc2119" title="SHOULD">SHOULD</em> avoid making HTTP <code>GET</code> requests
-		against any resource whose HTTP <code>Request-URI</code> is the object of a triple of the form 
-		described in <a href="#ldpr-4_11_3_2">section 4.11.3.2</a>, unless there are application-specific
-		reasons for doing so.  Clients should note that by the time the representation is received, the actual state
-		of any inlined resource(s) may have changed due to subsequent requests.
-	</div>
-
-	<div id="ldpr-4_11_3_4" class="rule">4.11.3.4 <abbr title="Linked Data Platform Resource">LDPR</abbr> clients <em class="rfc2119" title="MUST NOT">MUST NOT</em> assume that <abbr title="Linked Data Platform Resource">LDPR</abbr> representations
-		lacking a <code>ldp:Page</code> resource or lacking the triple
-		described in <a href="#ldpr-4_11_3_2">section 4.11.3.2</a> contain all the triples for any resource(s)
-		listed in the representation whose HTTP <code>Request-URI</code> differs from 
-		the HTTP <code>Request-URI</code> used by the client.  
-		The representation might in fact contain all such triples, or some
-		subset of them, and that might or might not be completely adequate for the client's intended usage, but
-		an LDP client has no way to discern from such a representation which interpretation is accurate.
-	</div>
-
-</section>
-
-</section> <!-- h2 -->
-
-</section> <!-- h1 -->
-
-<section typeof="bibo:Chapter" resource="#ldpc" rel="bibo:chapter" id="linked-data-platform-containers">
-<!--OddPage--><h2 id="ldpc"><span class="secno">5. </span>Linked Data Platform Containers</h2>
-
-<section class="informative" typeof="bibo:Chapter" resource="#ldpc-informative" rel="bibo:chapter" id="informative-1">		
-<h3 id="ldpc-informative"><span class="secno">5.1 </span>Informative</h3><p><em>This section is non-normative.</em></p>
-	<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. Containers answer some basic questions, which
-		are:</p>
-	<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>
-	</ol>
-	<p>
-		This document defines the representation and behavior of containers
-		that address these issues. The set of members of a container is
-		defined by a set of triples in its representation (and state) called
-		the membership triples. The membership triples of a container all
-		have the same subject and predicate – the objects of the membership
-		triples define the members of the container. The subject of the
-		membership triples is called the membership subject and the predicate
-		is called the membership predicate. In the simplest cases, the
-		membership subject will be the <abbr title="Linked Data Platform Container">LDPC</abbr> resource itself, but it does not
-		have to be. The membership predicate is also variable and will often
-		be a predicate from the server application vocabulary or the <code>rdfs:member</code> predicate.
-	</p>
-	<p>This document includes a set of guidelines for
-		using POST to create new resources and add them to the list of
-		members of a container. It goes on to explain how to learn about a set of related
-		resources, they may have been created using POST or through other means.
-		It also defines behavior when POST created resources are deleted, to clean up
-		container membership, and deleting containers removes membership information and
-		possibly perform some cleanup tasks on unreferenced member resources.</p>
-
-	<p>The following illustrates a very simple
-		container with only three members and some information about the
-		container (the fact that it is a container and a brief title):</p>
-
-<div class="example"><div class="example-title"><span>Example 6</span></div><pre class="example"># The following is the representation of
-# &nbsp; &nbsp;http://example.org/container1/
-@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
-@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
-@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-
-&lt;&gt;
- &nbsp; a ldp:Container;
-   ldp:membershipSubject &lt;&gt;
-   ldp:membershipPredicate rdfs:member;
-   ldp:membershipObject ldp:MemberSubject;
- &nbsp; dcterms:title "A very simple container";
- &nbsp; rdfs:member &lt;member1&gt;, &lt;member2&gt;, &lt;member3&gt;.</pre></div>
-
-	<p>This example is very straightforward - the
-			membership predicate is <code>rdfs:member</code> and the membership subject is the container
-			itself. A POST to this container will create a new resource
-			and add it to the list of members by adding a new membership triple
-			to the container.</p>
-
-	<p>Sometimes it is useful to use a subject
-	other than the container itself as the membership subject and to use
-	a predicate other than <code>rdfs:member</code> as the membership predicate. Let's
-	start with a domain resource for a person's net worth, as illustrated below:</p>
-			
-<div class="example"><div class="example-title"><span>Example 7</span></div><pre class="example" id="ldpc-ex-membership-partial"># The following is a partial representation of
-# &nbsp; http://example.org/netWorth/nw1
-@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-@prefix o: &lt;http://example.org/ontology/&gt;.
-&lt;&gt;
-   a o:NetWorth;
-   o:netWorthOf &lt;http://example.org/users/JohnZSmith&gt;;
-   o:asset 
-      &lt;assetContainer/a1&gt;,
-      &lt;assetContainer/a2&gt;;
-   o:liability 
-      &lt;liabilityContainer/l1&gt;,
-      &lt;liabilityContainer/l2&gt;,
-      &lt;liabilityContainer/l3&gt;.</pre></div>
-	<p>From this example, there is a <code>rdf:type</code> of <code>o:NetWorth</code> indicating the
-	resource represents an instance of a person's net worth and <code>o:netWorthOf</code> predicate indicating 
-	the associated person.  There are two sets of same-subject, same-predicate pairings; one for assets and
-	one for liabilities.  It would be helpful to be able to associate these multi-valued sets using a URL
-	for them to assist with managing these, this is done by associating containers with them as 
-	illustrated below:
-	</p>
-
-<div class="example"><div class="example-title"><span>Example 8</span></div><pre class="example" id="ldpc-ex-membership-full"># The following is an elaborated representation of
-# &nbsp; http://example.org/netWorth/nw1/
-@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
-@prefix o: &lt;http://example.org/ontology/&gt;.
-&lt;&gt;
-   a o:NetWorth;
-   o:netWorthOf &lt;http://example.org/users/JohnZSmith&gt;;
-   o:asset 
-      &lt;assetContainer/a1&gt;,
-      &lt;assetContainer/a2&gt;;
-   o:liability 
-      &lt;liabilityContainer/l1&gt;,
-      &lt;liabilityContainer/l2&gt;,
-      &lt;liabilityContainer/l3&gt;.
-
-&lt;assetContainer/&gt;
-   a ldp:Container;
-   dcterms:title "The assets of JohnZSmith";
-   ldp:membershipSubject &lt;&gt;;
-   ldp:membershipPredicate o:asset;
-   ldp:membershipObject ldp:MemberSubject.
-
-&lt;liabilityContainer/&gt;
-   a ldp:Container;
-   dcterms:title "The liabilities of JohnZSmith";
-   ldp:membershipSubject &lt;&gt;;
-   ldp:membershipPredicate o:liability;
-   ldp:membershipObject ldp:MemberSubject.</pre></div>
-
-	<p>The essential structure of the container is
-	the same, but in this example, the membership subject is not the
-	container itself – it is a separate net worth resource. The
-	membership predicates are <code>o:asset</code> and <code>o:liability</code> – predicates
-	from the domain model. A POST of an asset representation to the asset container will create a new
-	asset and add it to the list of	members by adding a new membership triple
-	to the container. You might wonder why
-	<code>http://example.org/netWorth/nw1</code> isn't made a container itself and POST
-	the new asset directly there. That would be a fine design if <code>http://example.org/netWorth/nw1</code>
-	had only assets, but if it has separate predicates for assets and liabilities,
-	that design will not work because it is unspecified to which predicate the POST
-	should add a membership triple. Having separate <code>http://example.org/netWorth/nw1/assetContainer/</code> 
-	and <code>http://example.org/netWorth/nw1/liabilityContainer/</code> container
-	resources allows both assets and liabilities to be created.
-	</p>
-
-<div class="example"><div class="example-title"><span>Example 9</span></div><pre class="example" id="ldpc-ex-membership-subj"># The following is the representation of
-# &nbsp; http://example.org/netWorth/nw1/assetContainer/
-@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-@prefix o: &lt;http://example.org/ontology/&gt;.
-
-&lt;&gt;
- &nbsp; a ldp:Container;
-   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
-&nbsp; &nbsp;ldp:membershipPredicate o:asset;
-   ldp:membershipObject ldp:MemberSubject.
-
-&lt;http://example.org/netWorth/nw1&gt;
-&nbsp; &nbsp;a o:NetWorth;
-   o:asset &lt;a1&gt;, &lt;a2&gt;.</pre></div>
-
-	<p>In this example, clients cannot simply guess
-			which resource is the membership subject and which predicate is the
-			membership predicate, so the example includes this information in
-			triples whose subject is the <abbr title="Linked Data Platform Container">LDPC</abbr> resource itself.
-	</p>
-	
-	<div id="ldpc-member_data" class="rule informative">5.1.1 Container Member Information</div>
-	<p>In many – perhaps most – applications
-		involving containers, it is desirable for the client to be able to
-		get information about each container member without having to do a
-		GET on each one. <abbr title="Linked Data Platform Container">LDPC</abbr> allows servers to include this information
-		directly in the representation of the container. The server decides
-		the amount of data about each member that is provided. Some common
-		strategies include providing a fixed number of standard properties,
-		or providing the entire <abbr title="Resource Description Framework">RDF</abbr> representation of each member resource,
-		or providing nothing. The server application domain and its use-cases
-		will determine how much information is required.</p>
-
-	<p>Continuing on from the net worth
-		example, there will be additional triples for the member resources
-		(assets) in the representation:</p>
-
-<div class="example"><div class="example-title"><span>Example 10</span></div><pre class="example"># The following is the representation of
-#	&nbsp;http://example.org/netWorth/nw1/assetContainer/
-@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
-@prefix ldp:      &lt;http://www.w3.org/ns/ldp#&gt;.
-@prefix o:       &lt;http://example.org/ontology/&gt;.
-
-&lt;&gt;
-   a ldp:Container;
-   dcterms:title "The assets of JohnZSmith";
-   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
-   ldp:membershipPredicate o:asset;
-   ldp:membershipObject ldp:MemberSubject.
-
-&lt;http://example.org/netWorth/nw1&gt;
-&nbsp; &nbsp;a o:NetWorth;
-   o:asset &lt;a1&gt;, &lt;a3&gt;, &lt;a2&gt;.
-
-&lt;a1&gt;
-&nbsp; &nbsp;a o:Stock;
-&nbsp; &nbsp;o:value 10000.
-&lt;a2&gt;
-&nbsp; &nbsp;a o:Bond;
-&nbsp; &nbsp;o:value 20000.
-&lt;a3&gt;
-&nbsp; &nbsp;a o:RealEstateHolding;
-&nbsp; &nbsp;o:value 300000.</pre></div>
-	<p>In a similar manner, when the representation for the resource of asset <var>.../&lt;a1&gt;</var> is returned a 
-	server may include the membership triple of the form <var>(.../nw1, o:asset, .../a1).</var></p>
-
-	<div id="ldpc-get_non-member_props" class="rule">5.1.2&nbsp;Retrieving Only Non-member Properties
-	</div>
-	<p>The representation of a container
-		that has many members will be large. There are several important
-		cases where clients need to access only the non-member properties of
-		the container. Since retrieving the whole container representation to
-		get this information may be onerous for clients and cause unnecessary
-		overhead on servers, it is desired to define a way to retrieve only
-		the non-member property values. Defining for each <abbr title="Linked Data Platform Container">LDPC</abbr> a corresponding
-		resource, called the “<a href="#dfn-non-member-resource" class="internalDFN">non-member resource</a>”, whose state is a subset
-		of the state of the container, does this.</p>
-	<p>The example listed here only show
-		a simple case where only a few simple non-member properties are
-		retrieved. In real world situations more complex cases are likely, such as those that add other predicates to
-		containers, for example providing validation information and
-		associating <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr> endpoints. [<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-QUERY</a></cite>]</p>
-	<p>
-		Here is an example requesting the non-member properties of a
-		container identified by the URL <code>http://example.org/container1/</code>.
-		In this case, the non-member resource is identified by the URL 
-		<code>http://example.org/container1?non-member-properties</code>:
-	</p>
-<p>Request:</p>
-<div class="example"><div class="example-title"><span>Example 11</span></div><pre class="example">GET /container1?non-member-properties HTTP/1.1
-Host: example.org
-Accept: text/turtle; charset=UTF-8</pre></div>
-<p>Response:</p>
-<div class="example"><div class="example-title"><span>Example 12</span></div><pre class="example">HTTP/1.1 200 OK
-Content-Type: text/turtle; charset=UTF-8
-ETag: "_87e52ce291112"
-Content-Length: 325
-
-@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
-@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
-@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-
-&lt;http://example.org/container1/&gt;
-   a ldp:Container;
-&nbsp; &nbsp;dcterms:title "A Linked Data Platform Container of Acme Resources";
-   ldp:membershipSubject http://example.org/container1/;
- &nbsp; ldp:membershipPredicate rdfs:member;
-   ldp:membershipObject ldp:MemberSubject;
-   dcterms:publisher &lt;http://acme.com/&gt;.</pre></div>
-   
-	<p>While the same non-member resource could be used to update the non-member properties via PUT,
-		LDP recommends using PATCH for this purpose.</p>
-
-	<div id="ldpc-ordering" class="rule">5.1.3 Ordering</div>
-	<p>
-		There are many cases where an ordering of the members of the
-		container is important. <abbr title="Linked Data Platform Container">LDPC</abbr> 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, <abbr title="Linked Data Platform Container">LDPC</abbr> avoids the use of <abbr title="Resource Description Framework">RDF</abbr>
-		constructs like Seq and List for expressing order.
-	</p>
-	<p>
-		Order becomes more important for <abbr title="Linked Data Platform Container">LDPC</abbr> servers 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 <abbr title="Linked Data Platform Container">LDPC</abbr> 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 
-		higher sort order than all members on the previous page and 
-		lower sort order than all the members on the next page. 
-		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: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>
-<div class="example"><div class="example-title"><span>Example 13</span></div><pre class="example"># The following is the ordered representation of
-#   http://example.org/netWorth/nw1/assetContainer/
-@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
-@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-@prefix o: &lt;http://example.org/ontology/&gt;.
-
-&lt;&gt;
-&nbsp; &nbsp;a ldp:Container;
-&nbsp; &nbsp;dcterms:title "The assets of JohnZSmith";
- &nbsp; ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
-&nbsp; &nbsp;ldp:membershipPredicate o:asset;
-   ldp:membershipObject ldp:MemberSubject.
-
-&lt;?firstPage&gt;
-   a ldp:Page;
- &nbsp; ldp:pageOf &lt;&gt;;
-   ldp:containerSortCriteria (#SortValueAscending).
-
-&lt;#SortValueAscending&gt;
-   a ldp:ContainerSortCriterion;
- &nbsp; ldp:containerSortOrder ldp:Ascending;
-   ldp:containerSortPredicate o:value.
-
-&lt;http://example.org/netWorth/nw1&gt;
-&nbsp; &nbsp;a o:NetWorth;
-   o:asset &lt;a1&gt;, &lt;a3&gt;, &lt;a2&gt;.
-
-&lt;a1&gt;
-&nbsp;  a o:Stock;
- &nbsp; o:value 100.00.
-&lt;a2&gt;
- &nbsp; a o:Cash;
-&nbsp; &nbsp;o:value 50.00.
-&lt;a3&gt;
-&nbsp; &nbsp;a o:RealEstateHolding;
-&nbsp; &nbsp;o:value 300000.</pre></div>
-		<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. &nbsp;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.
-		</p>
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpc-general" rel="bibo:chapter" id="general-1">
-<h3 id="ldpc-general"><span class="secno">5.2 </span>General</h3>
-	<p>The Linked Data Platform does not define how clients
-		discover <dfn id="dfn-linked-data-platform-containers"><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>
-
-	<div id="ldpc-5_2_1" class="rule">5.2.1 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MUST">MUST</em> also be conformant <abbr title="Linked Data Platform Resource">LDPR</abbr> servers. A Linked Data Platform
-		Container <em class="rfc2119" title="MUST">MUST</em> also be a conformant Linked Data Platform Resource.
-	</div>
-	<div id="ldpc-5_2_2" class="rule">5.2.2 <abbr title="Linked Data Platform Container">LDPC</abbr> membership is not exclusive; this means that the same resource
-	(<abbr title="Linked Data Platform Resource">LDPR</abbr> or not) which is identified by its canonical URI, <em class="rfc2119" title="MAY">MAY</em> be a member of 
-	more than one <abbr title="Linked Data Platform Container">LDPC</abbr>.
-	</div>
-	<div id="ldpc-5_2_3" class="rule">5.2.3 The state of an <abbr title="Linked Data Platform Container">LDPC</abbr> includes information about which
-		resources are its members. In the simplest cases, the membership subject
-		will be the <abbr title="Linked Data Platform Container">LDPC</abbr> resource itself, but it does not have to be. The
-		membership predicate is also variable and will often be a predicate
-		from the server application vocabulary. If there is no obvious
-		predicate from the server application vocabulary to use, <abbr title="Linked Data Platform Container">LDPC</abbr> servers
-		<em class="rfc2119" title="SHOULD">SHOULD</em> use the <code>rdfs:member</code> predicate. Member resources can be
-		any kind of resource identified by its URI, <abbr title="Linked Data Platform Resource">LDPR</abbr> or otherwise.
-	</div>
-	<div id="ldpc-5_2_4" class="rule">5.2.4 An <abbr title="Linked Data Platform Container">LDPC</abbr> representation <em class="rfc2119" title="MUST">MUST</em> contain exactly one triple 
-		whose subject is the <abbr title="Linked Data Platform Container">LDPC</abbr> URI, 
-		whose predicate is the <code>ldp:membershipSubject</code>, 
-		and whose object is the <abbr title="Linked Data Platform Container">LDPC</abbr>'s membership subject URI.
-	</div>
-	<div id="ldpc-5_2_5" class="rule">5.2.5 An <abbr title="Linked Data Platform Container">LDPC</abbr> representation <em class="rfc2119" title="MUST">MUST</em> contain exactly one triple 
-		whose subject is the <abbr title="Linked Data Platform Container">LDPC</abbr> URI, 
-		and whose predicate is either <code>ldp:membershipPredicate</code> or <code>ldp:membershipPredicateInverse</code>. 
-		The object of the triple is constrained by other sections, such as
-		<a href="#ldpc-5_2_5_1">5.2.5.1</a> or <a href="#ldpc-5_2_5_2">5.2.5.2</a>.
-	</div>
-	<div id="ldpc-5_2_5_1" class="rule">5.2.5.1 For a given triple <var>T</var> with a subject <var>C</var>
-	of the <abbr title="Linked Data Platform Container">LDPC</abbr> and predicate of 
-	<code>ldp:membershipPredicate</code>, the object <em class="rfc2119" title="MUST">MUST</em> be the URI of the membership predicate <var>P</var> used to
-	indicate membership to the linked to <abbr title="Linked Data Platform Container">LDPC</abbr>, or simply: <var>T = ( C</var>, <code>ldp:membershipPredicate</code>, <var>P)</var>. 
-	For the membership predicate URI object used in the triple <var>T</var>, it would be found in a resource's
-	same subject <var>R</var> and same predicate <var>P</var> membership triples of the form: 
-	(<var>R</var>, <var>P</var>, <var>MR</var>), where <var>MR</var> represents URI of
-	a member resource.
-	</div>
-	<div id="ldpc-5_2_5_2" class="rule">5.2.5.2  For a given triple <var>T</var> with a subject <var>C</var>
-	of the <abbr title="Linked Data Platform Container">LDPC</abbr> and predicate of 
-	<code>ldp:membershipPredicateInverse</code>, the object <em class="rfc2119" title="MUST">MUST</em> be the URI of the membership predicate <var>P</var> used to
-	indicate membership to the linked to <abbr title="Linked Data Platform Container">LDPC</abbr>, or simply: <var>T = ( C</var>, <code>ldp:membershipPredicateInverse</code>, <var>P)</var>. 
-	For the membership predicate URI object used in the triple <var>T</var>, it would be found in a resource's
-	object subject <var>R</var> and same predicate <var>P</var> membership triples of the form: 
-	(<var>MR</var>, <var>P</var>, <var>R</var>), where <var>MR</var> represents URI of
-	a member resource.
-	</div>
-	<div id="ldpc-5_2_6" class="rule">5.2.6 The representation of a <abbr title="Linked Data Platform Container">LDPC</abbr> <em class="rfc2119" title="MAY">MAY</em> include an arbitrary number of
-		additional triples whose subjects are the members of the container,
-		or that are from the representations of the members (if they have <abbr title="Resource Description Framework">RDF</abbr>
-		representations). This allows a <abbr title="Linked Data Platform Container">LDPC</abbr> server to provide clients with
-		information about the members without the client having to do a <code>GET</code>
-		on each member individually.  See sections <a href="#ldpc-member_data">5.1.1 Container
-		Member Information</a>, <a href="#ldpr-inlining" class="sectionRef">section 4.11 </a>, and
-		<a href="#ldpc-inlining" class="sectionRef">section 5.10 </a> for additional details.
-    </div>
-	<div id="ldpc-5_2_7" class="rule">5.2.7 The representation of a <abbr title="Linked Data Platform Container">LDPC</abbr> <em class="rfc2119" title="MUST">MUST</em> have <code>rdf:type</code>
-		of <code>ldp:Container</code>, but it <em class="rfc2119" title="MAY">MAY</em> have additional
-		<code>rdf:type</code>s.
-	</div>
-	<div id="ldpc-5_2_8" class="rule">5.2.8 <abbr title="Linked Data Platform Container">LDPC</abbr> representations <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> use <abbr title="Resource Description Framework">RDF</abbr> container types <code>rdf:Bag</code>,
-		<code>rdf:Seq</code> or <code>rdf:List</code>.
-	</div>
-	<div id="ldpc-5_2_9" class="rule">5.2.9 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> re-use URIs, 
-		regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
-		Certain specific cases exist where a <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MAY">MAY</em> delete a resource and then later re-use the
-		URI when it identifies the same resource, but only when consistent with Web architecture [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>].
-		While it is difficult to provide absolute implementation guarantees of non-reuse in all failure
-		scenarios, re-using URIs creates ambiguities for clients that are best avoided.
-	</div>
-	<div id="ldpc-5_2_10" class="rule">5.2.10 Some <abbr title="Linked Data Platform Container">LDPC</abbr>s have membership objects that are not directly
-	    URIs minted upon <abbr title="Linked Data Platform Container">LDPC</abbr> member creation, for example URIs with non-empty fragment identifier [<cite><a class="bibref" href="#bib-RFC3986">RFC3986</a></cite>]. 
-	    To determine which object URI to use for the  membership triple, <abbr title="Linked Data Platform Container">LDPC</abbr>s <em class="rfc2119" title="MUST">MUST</em> contain one triple whose
-	    subject is the <abbr title="Linked Data Platform Container">LDPC</abbr> URI, predicate is <code>ldp:membershipObject</code>, with an object <var>MO</var>. 
-	    Where <var>MO</var> and the HTTP URI <var>R</var> from <code>POST</code> create (as found in HTTP response <code>Location</code> header) can be 
-	    used to locate a triple of the form: <var>(R, MO, N)</var> and 
-	    where <var>N</var> can be used to construct the membership triple of the form: <var>(membership subject, membership predicate, N)</var>.
-	    When <code>ldp:membershipPredicateInverse</code> is used instead of <code>ldp:membershipPredicate</code>, the membership triple <em class="rfc2119" title="MUST">MUST</em> be
-	    of the form: <var>(N, membership predicate, membership subject)</var>. To indicate that the member resource URI is the membership object
-	    (the default or typical case), the object <em class="rfc2119" title="MUST">MUST</em> be set to predefined URI <code>ldp:MemberSubject</code> such that it forms the triple: 
-	    <var>(<abbr title="Linked Data Platform Container">LDPC</abbr> URI, <code>ldp:membershipObject</code>, <code>ldp:MemberSubject</code>)</var>.
-	</div>
-	
-	<!-- NOTE: Saving this sample to help with future editing/understanding or possible insertion directly.
-	
-	Let's say this LDPC has a membershipSubject of </people/roger> and membershipPredicate of pets:has_pet. If I POST the following to the LDPC: 
-
-	<> foaf:primaryTopic <#this> .
-	<#this> 
-	  a animal:Cat; 
-	  foaf:name "Zaza".
-	
-	... a new resource is created and there is a new membership triple of 
-	
-	</people/roger> pets:has_pet </people/roger/zaza>.
-	
-	but the desired one is:
-	
-	</people/roger> pets:has_pet </people/roger/zaza#this>.
-		
-	To do this, you'd have to use ldp:membershipObject such as:
-	
-	pets:has_pet 
-	   a ldp:Container;
-	   ldp:membershipPredicate pets:has_pet;
-	   ldp:membershipSubject </people/roger>;
-	   ldp:membershipObject foaf:primaryTopic .
-	 -->
-	
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpc-HTTP_GET" rel="bibo:chapter" id="http-get-3">	
-<h3 id="ldpc-HTTP_GET"><span class="secno">5.3 </span>HTTP GET</h3>
-
-	<div id="ldpc-5_3_1" class="rule">5.3.1 The representation of a <abbr title="Linked Data Platform Container">LDPC</abbr> <em class="rfc2119" title="MUST">MUST</em> contain a set of triples with a
-		consistent subject and predicate whose objects indicate members of
-		the container. The subject of the triples <em class="rfc2119" title="MAY">MAY</em> be the container itself
-		or <em class="rfc2119" title="MAY">MAY</em> be another resource (as in the <a href="#ldpc-ex-membership-subj">example</a>). &nbsp;See also
-		<a href="#ldpc-5_2_3">5.2.3</a>.
-	</div>
-	<div id="ldpc-5_3_2" class="rule">5.3.2 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MAY">MAY</em> represent the members of a paged <abbr title="Linked Data Platform Container">LDPC</abbr> in a sequential
-		order. &nbsp;If the server does so, it <em class="rfc2119" title="MUST">MUST</em> be 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 <em class="rfc2119" title="MUST">MUST</em> be as defined by <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr> <code>SELECT</code>’s <code>ORDER BY</code> clause 
-		[<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-QUERY</a></cite>].
-		Sorting criteria <em class="rfc2119" title="MUST">MUST</em>&nbsp;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 section <a href="#ldpc-ordering">5.1.4 Ordering</a> for
-		an example.
-	</div>
-	<div id="ldpc-5_3_3" class="rule">5.3.3 <abbr title="Linked Data Platform Container">LDPC</abbr> page representations 
-		ordered using <code>ldp:containerSortCriteria</code> <em class="rfc2119" title="MUST">MUST</em> 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 id="dfn-page-ordering-values">page-ordering values</dfn>).
-		The only predicate data types whose behavior LDP constrains are those defined
-		by <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr> <code>SELECT</code>’s <code>ORDER BY</code> clause [<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-QUERY</a></cite>].  Other data types
-		can be used, but LDP
-		assigns no meaning to them and interoperability will be limited.
-	</div>
-	<div id="ldpc-5_3_4" class="rule">5.3.4 <abbr title="Linked Data Platform Container">LDPC</abbr> page representations 
-		ordered using <code>ldp:containerSortCriteria</code> <em class="rfc2119" title="MUST">MUST</em> 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.
-	</div>
-	<div id="ldpc-5_3_5" class="rule">5.3.5 <abbr title="Linked Data Platform Container">LDPC</abbr> page representations 
-		ordered using <code>ldp:containerSortCriteria</code> <em class="rfc2119" title="MAY">MAY</em> 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" href="#dfn-page-ordering-values" class="internalDFN">page-ordering values</a> are strings or simple literals [<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-QUERY</a></cite>], the
-		resulting order is as defined by <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr> SELECT’s ORDER BY clause 
-		[<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-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.
-		When the <code>ldp:containerSortCollation</code> triple is present and the 
-		<a title="page-ordering values" href="#dfn-page-ordering-values" class="internalDFN">page-ordering values</a> are strings or simple literals 
-		[<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-QUERY</a></cite>], the
-		resulting order is as defined by <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr> SELECT’s ORDER BY clause 
-		[<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-QUERY</a></cite>] using three-argument <code>fn:compare</code>, that is, the 
-		specified collation.
-		The <code>ldp:containerSortCollation</code> triple <em class="rfc2119" title="SHOULD">SHOULD</em> be omitted for comparisons
-		involving <a title="page-ordering values" href="#dfn-page-ordering-values" class="internalDFN">page-ordering values</a> for which [<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-QUERY</a></cite>] does not use collations.
-	</div>
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpc-HTTP_POST" rel="bibo:chapter" id="http-post-1">
-<h3 id="ldpc-HTTP_POST"><span class="secno">5.4 </span>HTTP POST</h3>
-	<p>This specification imposes the following new requirements on HTTP <code>POST</code> for <abbr title="Linked Data Platform Containers">LDPCs</abbr> 
-		only when an <abbr title="Linked Data Platform Container">LDPC</abbr> supports that method.  This specification does not impose any
-		new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>
-		
-	<div id="ldpc-5_4_1" class="rule">5.4.1 <abbr title="Linked Data Platform Container">LDPC</abbr> clients <em class="rfc2119" title="SHOULD">SHOULD</em> create member resources by submitting a representation as
-		the entity body of the HTTP <code>POST</code> to a known <abbr title="Linked Data Platform Container">LDPC</abbr>. If the resource was created successfully, <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MUST">MUST</em>
-		respond with status code 201 (Created) and the <code>Location</code>
-		header set to the new resource’s URL. Clients shall not expect any representation in the response
-		entity body on a 201 (Created) response.
-	</div>
-
-	<div id="ldpc-5_4_2" class="rule">5.4.2 After a successful HTTP <code>POST</code> request to a <abbr title="Linked Data Platform Container">LDPC</abbr>, the new resource <em class="rfc2119" title="MUST">MUST</em>
-		appear as a member of the <abbr title="Linked Data Platform Container">LDPC</abbr> until the new resource is deleted or
-		removed by other methods. An <abbr title="Linked Data Platform Container">LDPC</abbr> <em class="rfc2119" title="MAY">MAY</em> also contain resources that were
-		added through other means - for example through the user interface of
-		the site that implements the <abbr title="Linked Data Platform Container">LDPC</abbr>.
-	</div>
-	
-	<div id="ldpc-5_4_3" class="rule">5.4.3 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MAY">MAY</em> accept an HTTP <code>POST</code> of non-<abbr title="Resource Description Framework">RDF</abbr> representations for
-		creation of any kind of resource, for example binary resources.  See <a href="#ldpc-5_4_13">5.4.13</a> for introspection
-		details.
-	</div>
-	<div id="ldpc-5_4_4" class="rule">5.4.4 For servers that support create, <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MUST">MUST</em> create an <abbr title="Linked Data Platform Resource">LDPR</abbr> from a
-		<abbr title="Resource Description Framework">RDF</abbr> representation in the request entity body.  The newly created <abbr title="Linked Data Platform Resource">LDPR</abbr> could also be a <abbr title="Linked Data Platform Container">LDPC</abbr>, therefore servers <em class="rfc2119" title="MAY">MAY</em>
-		allow the creation of <abbr title="Linked Data Platform Containers">LDPCs</abbr> within a <abbr title="Linked Data Platform Container">LDPC</abbr>. 
-	</div>
-	
-	<div id="ldpc-5_4_5" class="rule">5.4.5 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MUST">MUST</em> accept a request entity body with a request header
-	    of <code>Content-Type</code> with value of <code>text/turtle</code> [<cite><a class="bibref" href="#bib-TURTLE">TURTLE</a></cite>].
-	</div>
-	<div id="ldpc-5_4_6" class="rule">5.4.6 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> use the <code>Content-Type</code> request header 
-		to determine the representation format when the request has an entity body.  When the header is absent, 
-		<abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MAY">MAY</em> infer the content type by inspecting the entity body contents [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>].
-	</div>
-	<div id="ldpc-5_4_7" class="rule">5.4.7 In <abbr title="Resource Description Framework">RDF</abbr> representations, <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MUST">MUST</em> interpret the null relative
-		URI for the subject of triples in the <abbr title="Linked Data Platform Resource">LDPR</abbr> representation in the
-		request entity body as referring to the entity in the request body.
-		Commonly, that entity is the model for the “to be created” <abbr title="Linked Data Platform Resource">LDPR</abbr>, so
-		triples whose subject is the null relative URI will usually result in
-		triples in the created resource whose subject is the created
-		resource. &nbsp;
-	</div>	
-	<div id="ldpc-5_4_8" class="rule">5.4.8 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> assign the subject URI for the resource to be
-		created using server application specific rules in the absence of a <a href="#ldpc-5_4_10">client hint</a>.
-	</div>
-	<div id="ldpc-5_4_9" class="rule">5.4.9 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> allow clients to create new resources without
-		requiring detailed knowledge of application-specific constraints.
-		This is a consequence of the requirement to 
-		<a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
-	</div>
-	<div id="ldpc-5_4_10" class="rule">5.4.10 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MAY">MAY</em> allow clients to suggest the URI for a resource
-		created through <code>POST</code>, using the HTTP <code>Slug</code> header as defined in [<cite><a class="bibref" href="#bib-RFC5023">RFC5023</a></cite>].  LDP adds
-		no new requirements to this usage, so its presence functions as a client hint to the server 
-		providing a desired string to be incorporated into the server's final choice of resource URI.
-	</div>
-	
-	<div id="ldpc-5_4_11" class="rule">5.4.11 <abbr title="Linked Data Platform Container">LDPC</abbr> servers that allow member creation via <code>POST</code> 
-		<em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> re-use URIs, per the<a href="#ldpc-5_2_9">
-		general requirements on <abbr title="Linked Data Platform Containers">LDPCs</abbr></a>.
-	</div>
-	
-	<div id="ldpc-5_4_12" class="rule">5.4.12 Upon successful creation of a non-<abbr title="Resource Description Framework">RDF</abbr> and therefore non-<abbr title="Linked Data Platform Resource">LDPR</abbr> member (HTTP status code of 
-	201-Created and URI indicated by <code>Location</code> response header), <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MAY">MAY</em> create an associated <abbr title="Linked Data Platform Resource">LDPR</abbr>
-	to contain data about the created resource.  If an <abbr title="Linked Data Platform Container">LDPC</abbr> server creates this associated <abbr title="Linked Data Platform Resource">LDPR</abbr> it <em class="rfc2119" title="MUST">MUST</em> indicate
-	its location on the HTTP response using the HTTP response header <code>Link</code> and relationship type <code>meta</code>
-	and <code>href</code> to be the URI of the meta-resource [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
-	</div>	
-	<div id="ldpc-5_4_13" class="rule">5.4.13 <abbr title="Linked Data Platform Container">LDPC</abbr> servers that support <code>POST</code> <em class="rfc2119" title="MUST">MUST</em>
-		include an <a href="#header-accept-post"><code>Accept-Post</code> response header</a> on HTTP <code>OPTIONS</code>
-		responses, listing post document media type(s) supported by the server.
-		LDP only specifies the use of <code>POST</code> for the purpose of creating new resources, but a server
-		can accept <code>POST</code> requests with other semantics.  
-		While "POST to create" is a common interaction pattern, LDP clients are not guaranteed, even when 
-		making requests to an LDP server, that every successful <code>POST</code> request will result in the 
-		creation of a new resource; they must rely on out of band information for knowledge of which <code>POST</code> requests,
-		if any, will have the "create new resource" semantics.
-		This requirement on LDP servers is intentionally stronger than the one levied in the
-		<a href="#header-accept-post">header registration</a>; it is unrealistic to expect all existing resources
-		that support <code>POST</code> to suddenly return a new header or for all new specifications constraining
-		<code>POST</code> to be aware of its existence and require it, but it is a reasonable requirement for new
-		specifications such as LDP.
-	</div>
-		
-	<div id="ldpc-5_4_14" class="rule">5.4.14 <abbr title="Linked Data Platform Containers">LDPCs</abbr> that create new member resources <em class="rfc2119" title="MAY">MAY</em> add triples to the container 
-		as part of member creation to reflect its factory role.  
-		LDP defines the <code>ldp:created</code> predicate for this purpose.  
-		An <abbr title="Linked Data Platform Container">LDPC</abbr> that tracks members created through the <abbr title="Linked Data Platform Container">LDPC</abbr> <em class="rfc2119" title="MUST">MUST</em> add a triple
-		whose subject is the container's URI, 
-		whose predicate is <code>ldp:created</code>, and
-		whose object is the newly created member resource's URI; 
-		it <em class="rfc2119" title="MAY">MAY</em> add other triples as well.
-	</div>
-	
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpc-HTTP_PUT" rel="bibo:chapter" id="http-put-1">
-<h3 id="ldpc-HTTP_PUT"><span class="secno">5.5 </span>HTTP PUT</h3>
-	<p>This specification imposes the following new requirements on HTTP <code>PUT</code> for <abbr title="Linked Data Platform Containers">LDPCs</abbr> 
-		only when an <abbr title="Linked Data Platform Container">LDPC</abbr> supports that method.  This specification does not impose any
-		new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>
-		
-	<div id="ldpc-5_5_1" class="rule">5.5.1 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> allow HTTP <code>PUT</code> to update a <abbr title="Linked Data Platform Container">LDPC</abbr>’s <a href="#dfn-membership-triples" class="internalDFN">membership triples</a>; 
-		if the server receives such a request, it <em class="rfc2119" title="SHOULD">SHOULD</em> respond with a 409
-		(Conflict) status code.
-	</div>
-	<div id="ldpc-5_5_2" class="rule">5.5.2 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MAY">MAY</em> allow updating <abbr title="Linked Data Platform Container">LDPC</abbr> non-membership properties using
-		HTTP <code>PUT</code> on a corresponding <a href="#dfn-non-member-resource" class="internalDFN">non-member resource</a>, which
-		<em class="rfc2119" title="MAY">MAY</em> exclude server-managed properties such as <code>ldp:membershipSubject</code>, <code>ldp:membershipPredicate</code>
-		and <code>ldp:membershipPredicateInverse</code>.
-		The <a href="#ldpc-HTTP_OPTIONS" class="sectionRef">section 5.9 </a> describes the process by which clients
-		use HTTP <code>OPTIONS</code> to discover whether the server offers such a resource, and if so its URL. 
-	</div>
-	    
-    <div id="ldpc-5_5_3" class="rule">5.5.3 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> allow HTTP <code>PUT</code> requests
-		with <a title="Member inlining" href="#dfn-member-inlining" class="internalDFN">inlined member</a> information in the request representation.
-		See section <a href="#ldpc-member_data">5.1.1 Container
-		Member Information</a> for additional details.
-	</div>
-	
-	<div id="ldpc-5_5_4" class="rule">5.5.4 <abbr title="Linked Data Platform Container">LDPC</abbr> servers that allow member creation via <code>PUT</code> 
-		<em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> re-use URIs, per the <a href="#ldpc-5_2_9">
-		general requirements on <abbr title="Linked Data Platform Containers">LDPCs</abbr></a>.
-	</div>
-	
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpc-HTTP_DELETE" rel="bibo:chapter" id="http-delete-1">
-<h3 id="ldpc-HTTP_DELETE"><span class="secno">5.6 </span>HTTP DELETE</h3>
-	<p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for <abbr title="Linked Data Platform Resources">LDPRs</abbr> and <abbr title="Linked Data Platform Containers">LDPCs</abbr>
-		only when a <abbr title="Linked Data Platform Container">LDPC</abbr> supports that method.  This specification does not impose any
-		new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>
-		
-	<div id="ldpc-5_6_1" class="rule">5.6.1 When a <abbr title="Linked Data Platform Container">LDPC</abbr> member resource originally created by the <abbr title="Linked Data Platform Container">LDPC</abbr> (for example, one whose representation
-	    was HTTP <code>POST</code>ed to the <abbr title="Linked Data Platform Container">LDPC</abbr> and then referenced by a membership triple) is deleted, and the <abbr title="Linked Data Platform Container">LDPC</abbr> server is aware of the member's deletion
-		(for example, the member is managed by the same server), the <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MUST">MUST</em> also remove it from
-		the <abbr title="Linked Data Platform Container">LDPC</abbr> by removing the corresponding membership triple.
-	</div>	
-	<div id="ldpc-5_6_2" class="rule">5.6.2 When the <abbr title="Linked Data Platform Container">LDPC</abbr> server successfully completes the <code>DELETE</code> request on a <abbr title="Linked Data Platform Container">LDPC</abbr>, it <em class="rfc2119" title="MUST">MUST</em> remove any
-		membership triples associated with the <abbr title="Linked Data Platform Container">LDPC</abbr> as indicated by the canonical <code>Request-URI</code>.  The <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MAY">MAY</em> perform additional removal 
-		of member resources. 
-		For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not
-		been accessed for some period of time.
-	</div>	
-	<div id="ldpc-5_6_3" class="rule">5.6.3 When the conditions in <a href="#ldpc-5_6_1">5.6.1</a> hold, and the <abbr title="Linked Data Platform Container">LDPC</abbr> tracks member 
-		resources that it created using the <code>ldp:created</code> predicate, the <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MUST">MUST</em> also remove 
-		the deleted member's <code>ldp:created</code> triple.
-	</div>	
-	
-	<div id="ldpc-5_6_4" class="rule">5.6.4 When a <abbr title="Linked Data Platform Container">LDPC</abbr> member resource originally created by the <abbr title="Linked Data Platform Container">LDPC</abbr> (for example, one whose 
-	representation was HTTP <code>POST</code>ed to the <abbr title="Linked Data Platform Container">LDPC</abbr> and then referenced by a membership triple) is deleted, and the <abbr title="Linked Data Platform Container">LDPC</abbr> server 
-	created an associated <abbr title="Linked Data Platform Resource">LDPR</abbr> (see <a href="#ldpc-5_4_12">5.4.12</a>), the <abbr title="Linked Data Platform Container">LDPC</abbr> server must also remove the associated <abbr title="Linked Data Platform Resource">LDPR</abbr> it created.
-	</div>	
-	
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpc-HTTP_HEAD" rel="bibo:chapter" id="http-head-1">
-<h3 id="ldpc-HTTP_HEAD"><span class="secno">5.7 </span>HTTP HEAD</h3>
-	<p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
-		<code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also <abbr title="Linked Data Platform Container">LDPC</abbr> servers must also include HTTP headers
-		on response to <code>OPTIONS</code>, see <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
-		Thus, implementers supporting <code>HEAD</code> should also carefully read the
-		<a href="#ldpc-HTTP_GET" class="sectionRef">section 5.3 </a> and <a href="#ldpc-HTTP_OPTIONS" class="sectionRef">section 5.9 </a>.</p>
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpc-HTTP_PATCH" rel="bibo:chapter" id="http-patch-1">
-<h3 id="ldpc-HTTP_PATCH"><span class="secno">5.8 </span>HTTP PATCH</h3>
-	<p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for <abbr title="Linked Data Platform Containers">LDPCs</abbr> 
-		only when a <abbr title="Linked Data Platform Container">LDPC</abbr> supports that method.  This specification does not impose any
-		new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>
-		
-	<div id="ldpc-5_8_1" class="rule">5.8.1 <abbr title="Linked Data Platform Container">LDPC</abbr> servers are <em class="rfc2119" title="RECOMMENDED">RECOMMENDED</em> to support HTTP <code>PATCH</code> as the preferred
-		method for updating <abbr title="Linked Data Platform Container">LDPC</abbr> non-membership properties.
-	</div>
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpc-HTTP_OPTIONS" rel="bibo:chapter" id="http-options-2">
-<h3 id="ldpc-HTTP_OPTIONS"><span class="secno">5.9 </span>HTTP OPTIONS</h3>
-	<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for <abbr title="Linked Data Platform Containers">LDPCs</abbr>.
-		</p>
-
-	<div id="ldpc-5_9_1" class="rule">5.9.1  
-		<abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> define a corresponding
-		<a href="#dfn-non-member-resource" class="internalDFN">non-member resource</a>
-		to support requests for information about a <abbr title="Linked Data Platform Container">LDPC</abbr>
-		without retrieving a full representation including all of its members; 
-		see section <a href="#ldpc-get_non-member_props">5.1.2 Retrieving Only Non-member Properties</a> for
-		examples. 
-		In responses to <code>OPTIONS</code> requests with an <abbr title="Linked Data Platform Container">LDPC</abbr> as the <code>Request-URI</code>, 
-		<abbr title="Linked Data Platform Container">LDPC</abbr> servers that define a non-member resource <em class="rfc2119" title="SHOULD">SHOULD</em> provide an HTTP <code>Link</code>
-		header whose target URI is the <a href="#dfn-non-member-resource" class="internalDFN">non-member resource</a>, and whose link relation type is 
-		<code>http://www.w3.org/ns/ldp#nonMemberResource</code> [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>]. 
-		This is the mechanism by which clients discover the URL of the non-member resource.  
-		If no such <code>Link</code>
-		header is present, then conservative clients will assume that the <abbr title="Linked Data Platform Container">LDPC</abbr> does not have a corresponding
-		non-member resource.
-		For example, if there is a <abbr title="Linked Data Platform Container">LDPC</abbr> with URL <code>&lt;containerURL&gt;</code> whose corresponding
-		non-member resource 
-		URL is <code>&lt;containerURL&gt;?nonMemberProperties</code>, then the corresponding link header
-		would be <code>Link: &lt;?nonMemberProperties&gt;;rel="http://www.w3.org/ns/ldp#nonMemberResource"</code>
-	</div>
-	
-	<div id="ldpc-5_9_2" class="rule">5.9.2 When a <abbr title="Linked Data Platform Container">LDPC</abbr> creates a non-<abbr title="Linked Data Platform Resource">LDPR</abbr> (e.g. binary) member (for example, one whose 
-	representation was HTTP <code>POST</code>ed to the <abbr title="Linked Data Platform Container">LDPC</abbr> and then referenced by a membership triple) it might create an associated <abbr title="Linked Data Platform Resource">LDPR</abbr> to contain data about the 
-	non-<abbr title="Linked Data Platform Resource">LDPR</abbr> (see <a href="#ldpc-5_4_12">5.4.12</a>).  For non-<abbr title="Linked Data Platform Resources">LDPRs</abbr> that have this associated <abbr title="Linked Data Platform Resource">LDPR</abbr>, an <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MUST">MUST</em> provide an HTTP <code>Link</code>
-	header whose target URI is the associated <abbr title="Linked Data Platform Resource">LDPR</abbr>, and whose link relation type is 
-	<code>meta</code> [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].</div>
-</section>
-
-<section typeof="bibo:Chapter" resource="#ldpc-inlining" rel="bibo:chapter" id="member-inlining-returning-all-of-a-container-page-s-members-in-a-response">
-<h3 id="ldpc-inlining"><span class="secno">5.10 </span>Member Inlining: Returning All of a Container Page's Members in a Response</h3>
-
-	<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 href="#dfn-resource-inlining" class="internalDFN">resource inlining</a> to save application latency
-		and server/network load in controlled environments.</li>
-		</ul>
-		<p>Feedback, both positive and negative, is invited by sending email to the mailing list 
-		in <a href="#sotd">Status of This Document</a>.</p>
-	</div>
-
-<section class="informative" typeof="bibo:Chapter" resource="#ldpc-InliningIntro" rel="bibo:chapter" id="introduction-3">
-<h4 id="ldpc-InliningIntro"><span class="secno">5.10.1 </span>Introduction</h4><p><em>This section is non-normative.</em></p>
-	<p>One of the most commonly cited scenarios for resource inlining is to save clients enumerating a container of 
-		<i>m</i> members from having to perform <i>m+1</i> HTTP requests (or <i>m+p</i>, if the container
-		is paged into <i>p</i> pages).  The desire is to allow the server to reduce the number of HTTP
-		round-trips by returning some (perhaps all) members' content as part of the container's representation.
-		In addition to the general <a href="#dfn-resource-inlining" class="internalDFN">resource inlining</a> mechanism useful
-		in cases where only a subset of the members' content is inlined, LDP also provides 
-		a predicate for the special case where <i>all</i> of a container's or page's members are inlined.
-		Rather than forcing the server to add a triple for each inlined member, forcing clients to
-		compare the list of inlined members against the set of members in the representation, 
-		and enlarging the representation needlessly,
-		a single triple can be used.  This is called <a href="#dfn-member-inlining" class="internalDFN">member inlining</a>.
-	</p>
-
-	<p>LDP does not provide clients with any way to detect whether or not the server is capable of 
-		resource inlining (all its resources or any specific resource), nor does it provide clients 
-		with any way to influence which (if any) resources are inlined in any given response.
-	</p>
-
-	<p>The inlining building blocks LDP provides can only be safely used if certain assumptions hold.
-		This is no less true for containers than for <abbr title="Linked Data Platform Resources">LDPRs</abbr> in general.  
-		See the general <a href="#ldpr-InliningWarnings">cautions on resource inlining</a>.
-	</p>
-</section> <!-- h3 -->
-
-<section typeof="bibo:Chapter" resource="#ldpc-InliningGET" rel="bibo:chapter" id="http-get-4">
-<h4 id="ldpc-InliningGET"><span class="secno">5.10.2 </span>HTTP GET</h4>
-	<p>In addition to the requirements set forth in other sections, 
-		<abbr title="Linked Data Platform Container">LDPC</abbr> servers that support <a href="#dfn-member-inlining" class="internalDFN">member inlining</a>,
-		and LDP clients aware of the same facility,
-		must also follow the requirements in this section.
-	</p>
-
-	<div id="ldpc-5_10_2_1" class="rule">5.10.2.1 <abbr title="Linked Data Platform Container">LDPC</abbr> representations that are <a title="member inlining" href="#dfn-member-inlining" class="internalDFN">member inlined</a> <em class="rfc2119" title="MUST">MUST</em> 
-		include a <code>ldp:Page</code> resource in the representation, whether or not the representation contains
-		multiple pages, as described in <a href="#ldpr-4_11_3_1">section 4.11.3.1</a>.  In addition to satisfying
-		those requirements, the representation <em class="rfc2119" title="MUST">MUST</em> contain a triple
-		whose subject is the <code>ldp:Page</code> resource URI,
-		whose predicate is <code>ldp:membersInlined</code>, and
-		whose object is <code>"true"^^xsd:boolean</code>.
-		This is means by which the server communicates to LDP clients that they can avoid HTTP <code>GET</code>
-		requests for the members listed on the page.
-	</div>
-
-	<div id="ldpc-5_10_2_2" class="rule">5.10.2.2 <abbr title="Linked Data Platform Container">LDPC</abbr> clients <em class="rfc2119" title="SHOULD">SHOULD</em> avoid making HTTP <code>GET</code> requests
-		against any members in a <abbr title="Linked Data Platform Container">LDPC</abbr> representation containing a <code>ldp:Page</code> resource with the triple
-		described in <a href="#ldpc-5_10_2_1">section 5.10.2.1</a>, unless there are application-specific
-		reasons for doing so.  Clients should note that by the time the representation is received, the actual state
-		of inlined members may have changed due to subsequent requests.
-	</div>
-
-	<div id="ldpc-5_10_2_3" class="rule">5.10.2.3 <abbr title="Linked Data Platform Container">LDPC</abbr> clients <em class="rfc2119" title="MUST NOT">MUST NOT</em> assume that <abbr title="Linked Data Platform Container">LDPC</abbr> representations
-		lacking a <code>ldp:Page</code> resource or lacking the triple
-		described in <a href="#ldpc-5_10_2_1">section 5.10.2.1</a> contain all the triples for all members
-		listed in the representation.  The representation might in fact contain all those triples, or some
-		subset of them, that might or might not be completely adequate for the client's intended usage, but
-		an LDP client has no way to discern from such a representation which interpretation is accurate.
-	</div>
-
-	</section>
-
-</section> <!-- h2 -->
-</section>
-
-<section id="http-header-definitions">
-<!--OddPage--><h2><span class="secno">6. </span>HTTP Header Definitions</h2>
-     
-<section typeof="bibo:Chapter" resource="#header-accept-post" rel="bibo:chapter" id="the-accept-post-response-header">
-<h3 id="header-accept-post"><span class="secno">6.1 </span>The Accept-Post Response Header</h3>
-
-	<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>Accept-Post</a> in this specification is pending 
-		advancement of an IETF draft that would fully include it, see [<cite><a class="bibref" href="#bib-RFC5789">RFC5789</a></cite>].  Once LDP is in
-		Candidate Recommendation, the LDP WG will make an assessment based on the status at IETF
-		working with the <abbr title="World Wide Web Consortium">W3C</abbr> Director.</li>
-		</ul>
-	</div>
-		
-	<p>This specification introduces a new HTTP response header <code>Accept-Post</code> used
-		to specify the document formats accepted by the server on HTTP <code>POST</code> requests.
-		It is modeled after the <code>Accept-Patch</code> header defined in [<cite><a class="bibref" href="#bib-RFC5789">RFC5789</a></cite>].
-	</p>
-   
-	<div id="header-accept-post-1" class="rule">6.1.1 The syntax for <code>Accept-Post</code>, using
-		the ABNF syntax defined in Section 2.1 of [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>], is:
-		<blockquote><code>Accept-Post = "Accept-Post" ":" 1#media-type</code>
-		<p>
-		The <code>Accept-Post</code> header specifies a comma-separated list of media-
-		types (with optional parameters) as defined by [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>], Section 3.7.
-		</p>
-		</blockquote>
-	</div>
-
-	<div id="header-accept-post-2" class="rule">6.1.2
-		The <code>Accept-Post</code> HTTP header <em class="rfc2119" title="SHOULD">SHOULD</em> appear in the <code>OPTIONS</code> response for any resource
-		that supports the use of the <code>POST</code> method.  The presence of the
-		<code>Accept-Post</code> header in response to any method is an implicit
-		indication that <code>POST</code> is allowed on the resource identified by the
-		<code>Request-URI</code>.  The presence of a specific document format in
-		this header indicates that that specific format is allowed on <code>POST</code> requests to the
-		resource identified by the <code>Request-URI</code>.
-	</div>
-	
-	<div id="header-accept-post-iana" class="rule">6.1.3 IANA Registration Template</div>
-	<div>
-	<blockquote>
-	<p>
-	The Accept-Post response header must be added to the permanent registry (see [<cite><a class="bibref" href="#bib-RFC3864">RFC3864</a></cite>]).
-	</p>
-	<p>
-	Header field name:  Accept-Post
-	</p>
-	<p>
-	Applicable Protocol:  HTTP
-	</p>
-	<p>
-	Author/Change controller:  <abbr title="World Wide Web Consortium">W3C</abbr>
-	</p>
-	<p>
-	Specification document:  this specification
-	</p>
-	</blockquote>
-	</div>
-
-</section>
-</section> <!-- Header defns -->
-    
-<section class="appendix informative" id="acknowledgements">
-<!--OddPage--><h2><span class="secno">A. </span>Acknowledgements</h2><p><em>This section is non-normative.</em></p>
-     
-  <p>The following people have been instrumental in providing thoughts, feedback,
-reviews, content, criticism and input in the creation of this specification:</p>
-
-  <p style="margin-left: 3em;">Tim Berners-Lee, Steve Battle, 
-  Olivier Berger, Alexandre Bertails, Reza B'Far, Cody Burleson, Richard Cyganiak, Raúl García Castro, 
-  Miguel Esteban Gutiérrez,
-  Sandro Hawke, Kingsley Idehen, Yves Lafon, Arnaud Le Hors, Antonis Loizou, Ashok Malhota, Roger Menday,
-  Nandana Mihindukulasooriya, Kevin Page, Eric Prud'hommeaux, Andy Seaborne, Steve Speicher,
-  Henry Story, Ted Thibodeau, Bart van Leeuwen, Miel Vander Sande, Ruben Verborgh, Serena Villata, Erik Wilde, David Wood, Martin P. Nally</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-20130701/">Third Public Working Draft</a></em></blockquote>
--->
-<!-- 
-<ul>
-	<li>2013-07-24 - Moved 4.7.2 (from HEAD) to 4.3.2 (GET), shifted rest of GET section by one (SS)</li>
-	<li>2013-07-24 - Moved 4.10.2.5->4.10.2.4.3,4.10.2.6->4.10.2.4.1,4.10.2.7->4.10.2.4.2 and added samples (SS)</li>
-	<li>2013-07-24 - Changed ldp:ascending->ldp:Ascending, ldp:descending->ldp:Descending, ldp:non-member-resource ->ldp:nonMemberResource (SS)</li>
-	<li>2013-07-24 - Added term <a title="Page resource"></a> (SS)</li>
-	<li>2013-07-24 - Removed 5.4.8.1 and added 4.2.12 to better handle base/rel URI (SS)</li>
-    <li>2013-07-23 - Added informative <a href="#ldpr-informative" class="sectionRef"></a>, therefore shifting all sections by one 4.1->4.2, etc (SS)</li>
-	<li>2013-07-23 - Changed <a href="#header-accept-post" class="sectionRef"></a> to at risk as possibly moving to IETF (SS)</li>
-	<li>2013-07-23 - ISSUE-53 4.2.3 changed MUST to SHOULD (SS)</li>
-	<li>2013-07-22 - ISSUE-53 4.2.2 changed MUST to SHOULD (SS)</li>
-	<li>2013-07-17 - Various updates from suggests from <a href="http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0067.html">Raúl</a> (SS)</li>
-	<li>2013-07-15 - Inserted ldp:membershipObject into examples (SS)</li>
-	<li>2013-07-15 - ISSUE-79 ldp:contains => ldp:created  (JA)</li>
-	<li>2013-07-11 - Improving working in <a href="#ldpr-Paging" class="sectionRef"></a> to remove container references (SS)</li>
-	<li>2013-07-11 - Removed 4.1.5, section number fixup:4.1.8-13-&gt;6-11, 4.9.2.* fixup, 5.3.7-10-&gt;>2-5 (SS)</li>
-	<li>2013-07-11 - Removed all stubbed out sections 5.1.3, 5.3.2-6 (SS)</li>
-	<li>2013-07-11 - Various editorial clean up items from editor todo list (SS)</li>
-	<li>2013-07-11 - Removed closed issues that required no new spec changes: 50, 56, 16, 19, 17 (SS)</li>
-	<li>2013-07-11 - ISSUE-51 Added how a LDPR can show which LDPC is it in (SS)</li>
-	<li>2013-07-10 - Removed closed issues that required no new spec changes: 18, 35, 20 (SS)</li>
-	<li>2013-07-10 - ISSUE-44 move section 4.1.7 (relationships are simple RDF links) to guidance (SS)</li>
-	<li>2013-07-10 - ISSUE-72 take 2 - added ldp:MemberSubject to handle default case (SS)</li>
-	<li>2013-07-10 - ISSUE-72 adding 5.2.10 for ldp:membershipObject (SS)</li>
-	<li>2013-07-09 - ISSUE-58 inlining - actions 87-89 inclusive  (JA)</li>
-	<li>2013-07-08 - Moved 5.7.* sections out of HEAD and into OPTIONS as 5.9.*, added 4.6.2 (SS)</li>
-	<li>2013-07-08 - ISSUE-15 Inserted 5.4.12, 5.6.4, 5.7.2 to describe link-relation meta usage (SS)</li>
-	<li>2013-07-08 - ISSUE-79 ldp:contains  (JA)</li>
-	<li>2013-07-08 - ISSUE-80 Accept-Post (JA)</li>
-	<li>2013-07-08 - ISSUE-32 Must support options (JA)</li>
-	<li>2013-07-08 - ISSUE-78 No client inferencing  (JA)</li>
-	<li>2013-07-08 - ISSUE-77 Move "must have rdf:type explicitly" to Best Practices  (JA)</li>
-	<li>2013-07-08 - ISSUE-57 Knowing it's an LDP server  (JA)</li>
-	<li>2013-07-01 - ISSUE-33 Moved 5.1.3 Paging (LDPC) to 4.8 (LDPR) (SS)</li>
-	<li>2013-06-18 - ISSUE-75 5.2.5 membershipxxx predicates required, per 2013-06-18 F2F resolution (JA)</li>
-	<li>2013-06-18 - ISSUE-63 End of 5.3 + example rewritten for 2013-06-18 F2F resolution (JA)</li>
-	<li>2013-06-15 - ISSUE-14 End of 5.3 + example rewritten for ascending/descending sorts with optional collation (JA)</li>
-	<li>2013-06-13 - ISSUE-54 New 5.4.8.1 to set base URI on create for relative URI resolution (SS)</li>
-	<li>2013-06-10 - ISSUE-74 4.4.2 require 428 Condition Required status code when appropriate; SS adding 6585 to biblio (JA)</li>
-	<li>2013-06-05 - ISSUE-64 Remove ?non-member-properties; 5.1.2, 5.3.2, 5.5.2 (JA)</li>
-	<li>2013-05-21 - ISSUE-35 Re-use of URIs on create; 5.2.9, 5.4.11, 5.5.4 (JA)</li>
-	<li>2013-05-21 - ISSUE-43 Slug in LDPC POSTs; 5.4.8, 5.4.10 (JA)</li>
-	<li>2013-05-21 - ISSUE-65 Remove firstPage in favor of Link rel=first, mostly hits 5.3.3/5.3.4 (JA)</li>
-	<li>2013-05-17 - ISSUE-13 Updated 5.2.3 to say any resource can be in a LDPC and inserted 5.5.3 on rejecting member data on PUT to LDPC (SS)</li>
-	<li>2013-05-17 - Tweaks to Terminology section for LDPR and LDPC (SS)</li>
-	<li>2013-05-17 - ISSUE-9 Moved section 4.1.7 out of spec to the <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Servers_should_serve_up_canonical_URLs">deployment guide</a> (SS)</li>
-	<li>2013-05-15 - Updated wording for 5.2.2 from to be more clear (SS)</li>
-	<li>2013-05-13 - ISSUE-49 Moved section 4.1.4 out of spec to the <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Predicate_URIs_SHOULD_be_HTTP_URLs">deployment guide</a>. (SS)</li>
-	<li>2013-05-08 - Removed closed issues 5, 7, 55 and 38 as the don't require edits. Added 64 and 65. (SS)</li>
-	<li>2013-05-08 - ISSUE-59 5.3.2 limited rdf:type of ldp:Container, removed 5.6.3, reworded 5.6.2, updated 1. (SS)</li>
-	<li>2013-04-15 - ISSUE-21 Added ldp:membershipPredicateInverse to 5.2.5 &amp; 5.5.2, created 5.2.5.1 &amp; 5.3.5.2 to indicate difference. (SS)</li>
-	<li>2013-04-15 - ISSUE-39 Moved informative text from 5.4.5 into 5.4.1, shifted subsections .6-.10 (SS)</li>
-	<li>2013-04-15 - Expanded on wording for 4.3 to be more consistent (SS)</li>
-	<li>2013-04-08 - Fixed two old references to BPR (SS)</li>
-	<li>2013-03-17 - Inserted examples 2&amp;3, a more complete NetWorth resource (SS)</li>
-	<li>2013-03-15 - Update LDPC glossary term based on Cody's feedback (SS)</li>
-	<li>2013-03-15 - Additional fix in 5.2.2 for ISSUE-34 (SS)</li>
-	<li>2013-03-15 - Remove reference to closed issues that don't require edits: ISSUE-27 & ISSUE-45 (SS)</li>
-	<li>2013-03-14 - General prep for 3rd draft, cleanup and a little restructure (SS)</li>
-</ul>
-
-<blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130307/">Second Public Working Draft</a></em></blockquote>
-<ul>
-	<li>2013-03-14 - Fixed up broken fragments and typos before publication (SS)</li>
-	<li>2013-03-04 - Comments received from David Wood: 5.3.7 & 5.1.3 clarity, other minor edits (part 2)  (SS)</li>
-	<li>2013-03-04 - Comments received from David Wood: abstract, paging informative (part 1)  (SS)</li>
-	<li>2013-03-04 - ISSUE-36 - Added informative text regarding creationg of containers in 5.4.4 (SS)</li>
- 	<li>2013-03-04 - ISSUE-12 - Added section 4.7.3 not to allow PATCH for create (SS)</li>
-	<li>2013-03-03 - Adjustments to language about different container behavior (SS)</li>
-	<li>2013-03-02 - Adding trailing '/' on Container URLs to help with readability based on WG suggestion (SS)</li>
-	<li>2013-02-26 - Updated Acknowledgements section (SS)</li>
-	<li>2013-02-25 - ISSUE-29 - Use relative URIs in examples (SS)</li>
-	<li>2013-02-25 - ISSUE-31 - Added a more complete conformance section, motived by SPARQL 1.1 (SS)</li>
-	<li>2013-02-25 - Updating some simple formatting, reorganizing open issues and todos. (SS) </li>
-	<li>2013-02-15 - ISSUE-34 - Aggregration: 5.6.1 and 5.6.2 updated for review. (JA) </li>
-	<li>2013-02-13 - ISSUE-42 - 4.8 Common Properties moved to 
-			<a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Re-use_established_linked_data_vocabularies_instead_of_.28re-.29inventing_duplicates">Deploment Guide</a> 
-			(JA) </li>
-	<li>2013-02-12 - Fixed up previous publication links (SS) </li>
-	<li>2013-02-12 - ISSUE-10 - 4.1.12 to be MUST use entity tags (either weak or strong ones) (SS) </li>
-	<li>2013-02-12 - ISSUE-11 - 4.4.1 Relaxed the MUST ignore dc:modified/creator to MAY (SS) </li>
-	<li>2013-01-16 - ISSUE-25 Updated introduction. 5.2.2 changed to MUST NOT be in multiple containers. Flipped 5.6.1/2 as 
-	first rule leads to 2nd. 5.6.2(was .1) Delete LDPC MUST also delete members. (SS)</li>
-	<li>2013-01-16 - Added new issues ranging from 26-43. Removed closed/deferred issues: 2 &amp; 3 (SS)</li>
-	<li>2012-12-28 - Fixed Typos.  Separated some compound rules like 4.1.5.  Rewording for clarity: 4.1.10, 
-	Text being repeated in several places centralized and cross-linked.  Made printed code output easier to read
-	on black &amp; white printers.  Exposed terms defined in-line under LDPC as Terminology (tentatively).  Removed non-normative
-	qualifer from section 5.2.  Added "several" editors' to-dos.(JA)</li>
-	<li>2012-11-05 - minor rewording from ISSUE-24</li>
-	<li>2012-11-03 - ISSUE-22, ISSUE-23: changed sections 4.2.3 and 5.4.7. Removed closed issues. (SS)</li>
-	<li>2012-11-03 - ISSUE-24 Delete the phrase in 4.5.1 that nays "until ...Request URI" 
-	and adding a sentence, "Clients should note that servers may reuse a Request-URI under some circumstances."</li>
-	<li>2012-11-03 - ISSUE-6 Removed section 4.1.9.  Shifted up sections .10 through .13.</li>
-	<li>2012-11-01 - Fixed minor typo and added some notes (SS)</li>
-</ul>
-
-<blockquote><em><a href="http://www.w3.org/TR/2012/WD-ldp-20121025/">First Public Working Draft</a></em></blockquote>
-<ul>
-	<li>2012-10-15 - ISSUE-8 Changed references from LDBP to LDP, removed definition for "profile" and new namespace (SS)</li>	
-	<li>2012-10-15 - Included additional open ISSUES from Oct 15 WG meeting: 22, 23, 24 (SS)</li>
-	<li>2012-10-14 - Added open ISSUES and formating to prep for public working draft (SS)</li>
-	<li>2012-09-20 - Sent pull request re LINKED-DATA and added suggestion for <code>ldp</code> namespace (SS)</li>
-	<li>2012-09-19 - Repairing references and forward reference to biblio.js updates (SS)</li>
-	<li>2012-09-19 - Fixed rdfs:label range to be rdfs:Literal (SS)</li>
-	<li>2012-09-19 - ISSUE-1 Define Turtle as the required serialization format for LDP (SS)</li>
-	<li>2012-09-18 - Initial ReSpec'ing of <a href="http://www.w3.org/Submission/ldbp/">Member Submission - Linked Data Basic Profile 1.0</a> (SS)</li>
-	<li>2012-09-18 - Fixed up some links and worked on references, work left to do. (SS)</li>
-</ul>
-<blockquote><em><a href="http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/">Submission</a></em></blockquote>
-</section>  
-  -->
-    
-  
-
-<section id="references" class="appendix" typeof="bibo:Chapter" resource="#references" rel="bibo:chapter"><!--OddPage--><h2><span class="secno">B. </span>References</h2><section id="normative-references" typeof="bibo:Chapter" resource="#normative-references" rel="bibo:chapter"><h3><span class="secno">B.1 </span>Normative references</h3><dl class="bibliography" about=""><dt id="bib-DC-TERMS">[DC-TERMS]</dt><dd rel="dcterms:requires">Dublin Core Metadata Initiative. <a href="http://dublincore.org/documents/2010/10/11/dcmi-terms/"><cite>Dublin Core Metadata Initiative Terms, version 1.1.</cite></a> 11 October 2010. DCMI Recommendation. URL: <a href="http://dublincore.org/documents/2010/10/11/dcmi-terms/">http://dublincore.org/documents/2010/10/11/dcmi-terms/</a>.
-</dd><dt id="bib-HTML401">[HTML401]</dt><dd rel="dcterms:requires">Dave Raggett; Arnaud Le Hors; Ian Jacobs. <a href="http://www.w3.org/TR/html401"><cite>HTML 4.01 Specification</cite></a>. 24 December 1999. W3C Recommendation. URL: <a href="http://www.w3.org/TR/html401">http://www.w3.org/TR/html401</a>
-</dd><dt id="bib-HTTP11">[HTTP11]</dt><dd rel="dcterms:requires">R. Fielding et al. <a href="http://www.ietf.org/rfc/rfc2616.txt"><cite>Hypertext Transfer Protocol - HTTP/1.1</cite></a>. June 1999. RFC. URL: <a href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a>
-</dd><dt id="bib-RDF-CONCEPTS">[RDF-CONCEPTS]</dt><dd rel="dcterms:requires">Graham Klyne; Jeremy Carroll. <a href="http://www.w3.org/TR/rdf-concepts/"><cite>Resource Description Framework (RDF): Concepts and Abstract Syntax</cite></a>. 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/rdf-concepts/">http://www.w3.org/TR/rdf-concepts/</a>
-</dd><dt id="bib-RDF-SCHEMA">[RDF-SCHEMA]</dt><dd rel="dcterms:requires">Dan Brickley; Ramanathan Guha. <a href="http://www.w3.org/TR/rdf-schema"><cite>RDF Vocabulary Description Language 1.0: RDF Schema</cite></a>. 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/rdf-schema">http://www.w3.org/TR/rdf-schema</a>
-</dd><dt id="bib-RFC2119">[RFC2119]</dt><dd rel="dcterms:requires">S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate Requirement Levels.</cite></a> March 1997. Internet RFC 2119.  URL: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a> 
-</dd><dt id="bib-RFC3864">[RFC3864]</dt><dd rel="dcterms:requires">G. Klyne; M. Nottingham; J. Mogul. <a href="http://www.ietf.org/rfc/rfc3864.txt"><cite>Registration Procedures for Message Header Fields</cite></a>. September 2004. RFC. URL: <a href="http://www.ietf.org/rfc/rfc3864.txt">http://www.ietf.org/rfc/rfc3864.txt</a>
-</dd><dt id="bib-RFC3987">[RFC3987]</dt><dd rel="dcterms:requires">M. Dürst; M. Suignard. <a href="http://www.ietf.org/rfc/rfc3987.txt"><cite>Internationalized Resource Identifiers (IRIs)</cite></a>. January 2005. RFC. URL: <a href="http://www.ietf.org/rfc/rfc3987.txt">http://www.ietf.org/rfc/rfc3987.txt</a>
-</dd><dt id="bib-RFC4627">[RFC4627]</dt><dd rel="dcterms:requires">D. Crockford. <a href="http://www.ietf.org/rfc/rfc4627.txt"><cite>The application/json Media Type for JavaScript Object Notation (JSON) (RFC 4627)</cite></a>. July 2006. RFC. URL: <a href="http://www.ietf.org/rfc/rfc4627.txt">http://www.ietf.org/rfc/rfc4627.txt</a>
-</dd><dt id="bib-RFC5023">[RFC5023]</dt><dd rel="dcterms:requires">J. Gregorio; B. de hOra. <a href="http://www.ietf.org/rfc/rfc5023.txt"><cite>The Atom Publishing Protocol</cite></a>. October 2007. RFC. URL: <a href="http://www.ietf.org/rfc/rfc5023.txt">http://www.ietf.org/rfc/rfc5023.txt</a>
-</dd><dt id="bib-RFC5789">[RFC5789]</dt><dd rel="dcterms:requires">L Dusseault; J. Snell. <a href="http://tools.ietf.org/html/rfc5789"><cite>PATCH Method for HTTP (RFC 5789)</cite></a>. March 2010. RFC. URL: <a href="http://tools.ietf.org/html/rfc5789">http://tools.ietf.org/html/rfc5789</a>
-</dd><dt id="bib-RFC5988">[RFC5988]</dt><dd rel="dcterms:requires">Mark Nottingham. <a href="http://www.ietf.org/rfc/rfc5988.txt"><cite>Web Linking (RFC 5988)</cite></a>. October 2010. RFC. URL: <a href="http://www.ietf.org/rfc/rfc5988.txt">http://www.ietf.org/rfc/rfc5988.txt</a>
-</dd><dt id="bib-RFC6585">[RFC6585]</dt><dd rel="dcterms:requires">M. Nottingham; R. Fielding. <a href="http://www.ietf.org/rfc/rfc6585.txt"><cite>Additional HTTP Status Codes</cite></a>. April 2012. RFC. URL: <a href="http://www.ietf.org/rfc/rfc6585.txt">http://www.ietf.org/rfc/rfc6585.txt</a>
-</dd><dt id="bib-SPARQL-QUERY">[SPARQL-QUERY]</dt><dd rel="dcterms:requires">Eric Prud'hommeaux; Andy Seaborne. <a href="http://www.w3.org/TR/rdf-sparql-query/"><cite>SPARQL Query Language for RDF</cite></a>. 15 January 2008. W3C Recommendation. URL: <a href="http://www.w3.org/TR/rdf-sparql-query/">http://www.w3.org/TR/rdf-sparql-query/</a>
-</dd><dt id="bib-SPARQL-UPDATE">[SPARQL-UPDATE]</dt><dd rel="dcterms:requires">Paul Gearon; Alexandre Passant; Axel Polleres. <a href="http://www.w3.org/TR/sparql11-update/"><cite>SPARQL 1.1 Update</cite></a>. 21 March 2013. W3C Recommendation. URL: <a href="http://www.w3.org/TR/sparql11-update/">http://www.w3.org/TR/sparql11-update/</a>
-</dd><dt id="bib-TURTLE">[TURTLE]</dt><dd rel="dcterms:requires">David Beckett; Tim Berners-Lee. <a href="http://www.w3.org/TeamSubmission/turtle/"><cite>Turtle: Terse RDF Triple Language</cite></a>. January 2008. W3C Team Submission. URL: <a href="http://www.w3.org/TeamSubmission/turtle/">http://www.w3.org/TeamSubmission/turtle/</a>
-</dd></dl></section><section id="informative-references" typeof="bibo:Chapter" resource="#informative-references" rel="bibo:chapter"><h3><span class="secno">B.2 </span>Informative references</h3><dl class="bibliography" about=""><dt id="bib-LINKED-DATA">[LINKED-DATA]</dt><dd rel="dcterms:references">Tim Berners-Lee. <a href="http://www.w3.org/DesignIssues/LinkedData.html"><cite>Linked Data Design Issues</cite></a>. 27 July 2006. W3C-Internal Document. URL: <a href="http://www.w3.org/DesignIssues/LinkedData.html">http://www.w3.org/DesignIssues/LinkedData.html</a>
-</dd><dt id="bib-RFC3986">[RFC3986]</dt><dd rel="dcterms:references">T. Berners-Lee; R. Fielding; L. Masinter. <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource Identifier (URI): Generic Syntax (RFC 3986)</cite></a>. January 2005. RFC. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>
-</dd><dt id="bib-WEBARCH">[WEBARCH]</dt><dd rel="dcterms:references">Ian Jacobs; Norman Walsh. <a href="http://www.w3.org/TR/webarch/"><cite>Architecture of the World Wide Web, Volume One</cite></a>. 15 December 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a>
-</dd></dl></section></section></body></html>
\ No newline at end of file
--- a/ldpbusted.html	Tue Sep 10 10:04:47 2013 -0400
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,177 +0,0 @@
-<!DOCTYPE html>
-<html>
-  <head>
-    <title>Linked Data Platform 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",
-
-          // 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:  "2009-08-06",
-
-          // 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-03-07",
-          previousMaturity:  	"FPWD",
-          previousURI: 			"http://www.w3.org/TR/2013/WD-ldp-20130307/",
-
-          // if there a publicly available Editor's Draft, this is the link
-          edDraftURI:           "http://www.w3.org/2012/ldp/hg/ldp.html",
-
-          // if this is a LCWD, uncomment and set the end of its review period
-          // lcEnd: "2009-08-05",
-
-          // 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: "ashok.malhotra@oracle.com",
-			    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-wg",
-          
-          // 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",
-      };
-    </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;
-    	}
-    </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'>
-A set of best practices and simple approach for a read-write Linked Data architecture, based on
-HTTP access to web resources that describe their state using the <abbr title="Resource Description Framework">RDF</abbr>
-data model.
-</section>
- 
-
-
-<section>
-<h1 id="ldpr">Linked Data Platform Resources</h1>
-
-<p>Some of the rules defined in this document provide
-		clarification and refinement of the base Linked Data rules [[2dcontext]]
-		others address additional needs.</p>
-		
-	
-	
-
-</section> <!-- h1 -->
-
-    
-<section class='appendix informative'>
-<h2>Acknowledgements</h2>
-     
-  <p>The y</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>
-</section>
-
-<section class='appendix informative' id="todos">
-<h1>Editor Todos and Notes</h1>
-<p>Other than LDP </p>
-</section>
-    
-  </body>
-</html>