Respec generated LC document
authorsspeiche
Wed, 24 Jul 2013 16:10:19 -0400
changeset 236 add97cfc2550
parent 235 b93936428fcd
child 237 6871b9ac5339
Respec generated LC document
drafts/ldp/Overview.html
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/drafts/ldp/Overview.html	Wed Jul 24 16:10:19 2013 -0400
@@ -0,0 +1,2111 @@
+<!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">
+  <p>
+    
+      <a href="http://www.w3.org/"><img width="72" height="48" src="https://www.w3.org/Icons/w3c_home" alt="W3C"></a>
+    
+  </p>
+  <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform 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="[email protected]">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:[email protected]">[email protected]</a> 
+          (<a href="mailto:[email protected]?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
[email protected] rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
+
+&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
[email protected] rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
+
+&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="ldpc-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="#ldpc-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="ldpc-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="#ldpc-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/
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] 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
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] 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/
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] 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/
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] 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/
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] ldp:      &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] o:       &lt;http://example.org/ontology/&gt;.
+
+&lt;&gt;
+   a ldp:Container;
+   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
+
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] 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/
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
+
+&lt;&gt;
+&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 object's 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>'d 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>'d 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-4_7_2">4.7.2</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>'d 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