ldp.html
author sspeiche
Wed, 05 Feb 2014 07:03:41 -0500
changeset 456 6130538abdf0
parent 454 4a28a15ee8fd
child 458 241a71502265
permissions -rw-r--r--
ACTION-124 LDPR-RR as named graphs
<!DOCTYPE html>
<!-- 
 Editor TODO:
   - Search "TODO" within this document.
   - Once companion documents (best practices, primer) have URLs, link to them.  Search on "companion".
   - Once the membership* names stabilize, take a pass through for "membership consistent value", membership-constant-URI
     and see if there is a friendlier way to phrase it.
   - Paging intro: add 3rd example showing header linkage amongst pages and (HEAD on) the base resource.
     Maybe also insert HEAD on base as new first example instead of relying on text alone.
   - The ReSpec SPARQL QUERY link is http://www.w3.org/TR/rdf-sparql-query/ , which has highlighted text
	referring readers to SPARQL 1.1.  Which normative reference do we want?
 Various pre-LC comments:
    - 5.2.5.1 For a given triple T with a subject C of the LDPC and predicate of ldp:containsRelation, 
	  5.2.5.2 For a given triple T with a subject C of the LDPC and predicate of ldp:containedByRelation, 
	  5.2.10 Some LDPC's have membership object's that are not directly URIs minted upon LDPC member creation, 
	  (JohnA) I found these particularly hard to read.  And I perpetrated the SortCollation paragraphs.  
	  Links to examples might be an 80-20 solution. 
	- 5.3.1: I'd change the link to the example ("as in the example") to refer the concrete example #, I think example 9. 
	  Currently does not work when printing.
 Misc during LC comments:
    - http://lists.w3.org/Archives/Public/public-ldp/2013Aug/0002.html
      #1 Should update example in 5.1.3 to be more clear on what the request vs base URI is.  Also example is missing ldp:nextPage.
 -->
<html>
  <head>
    <title>Linked Data Platform 1.0</title>
    <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
    <!-- 
      === NOTA BENE ===
      For the three scripts below, if your spec resides on dev.w3 you can check them
      out in the same tree and use relative links so that they'll work offline,
     -->
    <script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script> 
    <script class='remove'>
      var respecConfig = {
          // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
          specStatus:           "ED",
          
          // the specification's short name, as in http://www.w3.org/TR/short-name/
          shortName:            "ldp",

          // if your specification has a subtitle that goes below the main
          // formal title, define it here
          // subtitle   :  "an excellent document",

          // if you wish the publication date to be other than today, set this
          publishDate:  "",

          // if the specification's copyright date is a range of years, specify
          // the start date here:
          // copyrightStart: "2005"

          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
          // and its maturity status
          previousPublishDate:  "2013-07-30",
          previousMaturity:  	"LC",
          previousURI: 			"http://www.w3.org/TR/2013/WD-ldp-20130730/",

          // if there a publicly available Editor's Draft, this is the link
          edDraftURI:           "http://www.w3.org/2012/ldp/hg/ldp.html",

          // if this is a LCWD, uncomment and set the end of its review period
          lcEnd: "2013-09-02",
          
          // Only include h1 and h2 level
          maxTocLevel: 2,

          // if you want to have extra CSS, append them to this list
          // it is recommended that the respec.css stylesheet be kept
          //extraCSS:             ["https://dvcs.w3.org/hg/ldpwg/css/respec.css"],

          // editors, add as many as you like
          // only "name" is required
          editors:  [
              { name: "Steve Speicher", url: "http://stevespeicher.blogspot.com",
                company: "IBM Corporation", companyURL: "http://ibm.com/" },
              { name: "John Arwe", url: "https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?userid=120000CAW7",
                company: "IBM Corporation", companyURL: "http://ibm.com/" },
			  {name: "Ashok Malhotra", url: "mailto:ashok.malhotra@oracle.com",
			    company: "Oracle Corporation", companyURL: "http://www.oracle.com" },
          ],

          // authors, add as many as you like. 
          // This is optional, uncomment if you have authors as well as editors.
          // only "name" is required. Same format as editors.

          //authors:  [
          //    { name: "Your Name", url: "http://example.org/",
          //      company: "Your Company", companyURL: "http://example.com/" },
          //],
          
          // name of the WG
          wg:           "Linked Data Platform Working Group",
          
          // URI of the public WG page
          wgURI:        "http://www.w3.org/2012/ldp",
          
          // name (without the @w3c.org) of the public mailing to which comments are due
          wgPublicList: "public-ldp-comments",
          
          // URI of the patent status for this WG, for Rec-track documents
          // !!!! IMPORTANT !!!!
          // This is important for Rec-track documents, do not copy a patent URI from a random
          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
          // Team Contact.
          wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/55082/status",
          doRDFa: "1.1",
			localBiblio:  {
				"HTTPBIS-SEMANTICS": {
					title:    "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"
				,   href:     "http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics/"
				,   authors:  [
						"R. Fielding"
					,   "J. Reschke"
					]
				,   status:   "In Last Call"
				,   publisher:  "IETF"
				},
				"RFC2817": {
					title:    "Upgrading to TLS Within HTTP/1.1"
				,   href:     "http://tools.ietf.org/html/rfc2817"
				,   authors:  [
						"R. Khare"
					,   "S. Lawrence"
					]
				,   status:   "Proposed Standard"
				,   publisher:  "IETF"
				},
				"RFC5005": {
					title:    "Feed Paging and Archiving"
				,   href:     "http://tools.ietf.org/html/rfc5005"
				,   authors:  [
						"M. Nottingham"
					]
				,   status:   "Proposed Standard"
				,   publisher:  "IETF"
				}
			},
      };
    </script>
    <style type="text/css">
    	div.rule {padding-top: 1em;}
    	div.ldp-issue-open {
	    	border-color: #E05252;
			background: #FBE9E9;
			padding: 0.5em;
			margin: 1em 0;
			position: relative;
			clear: both;
			border-left-width: .5em;
			border-left-style: solid;
    	}
    	div.ldp-issue-pending {
	    	border-color: #FAF602;
			background: #F7F6BC;
			padding: 0.5em;
			margin: 1em 0;
			position: relative;
			clear: both;
			border-left-width: .5em;
			border-left-style: solid;
    	}
    	div.ldp-issue-closed {
	    	border-color: #009900;
			background: #BCF7CF;
			padding: 0.5em;
			margin: 1em 0;
			position: relative;
			clear: both;
			border-left-width: .5em;
			border-left-style: solid;
    	}
    	div.ldp-issue-title {
    	    color: #E05252;
    	    padding-right: 1em;
            min-width: 7.5em;
    	}
		.atrisk {
			padding:    1em;
			margin: 1em 0em 0em;
			border: 1px solid #f00;
			background: #ffc;
		}
		.atrisktext {
			/* content:    "Feature At Risk"; */
			display:    block;
			width:  150px;
			margin: -1.5em 0 0.5em 0;
			font-weight:    bold;
			border: 1px solid #f00;
			background: #fff;
			padding:    3px 1em;
		}
		.normal { 
			font-weight: normal;
			font: normal 100% sans-serif;
		}
		
    </style>
    <style type="text/css" media="all">
    	code {
    	    font-weight:bold;
			font-size:larger;
    	}
		 /* ReSpec uses color ff4500 for code elements, which does not print well on some black & white printers
		    and is a little hard to read for some folks even on-line. 
			The default code font size was also somewhat too small/hard to read.
		*/
    </style>
  </head>
<body>
<section id='abstract'>
This document describes a set of best practices and simple approach for a read-write Linked Data architecture, based on
HTTP access to web resources that describe their state using the <abbr title="Resource Description Framework">RDF</abbr>
data model.
</section>
 
<section class="informative" id="intro">
<h1>Introduction</h1>
	<p>This specification describes the use
	of HTTP for accessing, updating, creating and deleting resources from
	servers that expose their resources as Linked Data.  It provides clarifications
	and extensions of the rules of Linked Data [[LINKED-DATA]]:</p>
	<ol>
		<li>Use URIs as names for things</li>
		<li>Use HTTP URIs so that people can look up those names</li>
		<li>When someone looks up a URI, provide useful information, using the standards
			(RDF*, <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr>)
		</li>
		<li>Include links to other URIs, so that they can discover more things</li>
	</ol>
	<p>This specification discusses standard HTTP and RDF techniques  
	used when constructing clients and servers that 
	create, read, and write <a title="Linked Data Platform Resource">Linked Data Platform Resources</a>.
	A companion document discusses best practices that you 
	should use, and anti-patterns you should avoid, when constructing these clients and servers.
	</p> 
	<p>This specification provides a widely re-usable pattern to deal with large resources.  
	Depending on the server’s capabilities, a GET request on a <a title="Paged resource">resource</a> can
	return a <a title="Single-page resource">subset of the resource (one page)</a>, that provides access to subsequent pages 
	(see <a href="#ldpr-Paging" class="sectionRef"></a>). 
	</p>
	<p>This specification defines a special type of <a>Linked Data Platform Resource</a>: a 
	<a title="Linked Data Platform Container">Container</a>.  Containers are very useful 
	in building application models involving collections of resources, often homogeneous ones. 
	For example, universities offer a collection of classes 
	and have a collection of faculty members, each faculty member teaches a collection of courses, and so on. 
	This specification discusses how to work with containers.  Resources can be added to containers  
	using standard HTTP operations like 
	POST (see <a href="#ldpc-HTTP_POST" class="sectionRef"></a>).</p>
	<p>The intention of this specification 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>
	<p>For context and background, it could be useful to read <a href="#bib-LDP-UCR">Linked Data Platform Use Case and Requirements</a> [[LDP-UCR]] 
	and <a href="#base-specs" class="sectionRef"></a>.</p>
</section>
	
<section id="terms">
<h1>Terminology</h1>

<p>Terminology is based on W3C's Architecture of the World Wide Web [[WEBARCH]] and Hyper-text Transfer Protocol [[HTTP11]].
</p>
  <dl class="glossary">
	<dt>Link</dt>
	<dd>A relationship between two resources when one resource (representation) refers to the other resource by means
		of a URI [[WEBARCH]].
		<p></p></dd>
							
	<dt>Linked Data</dt>
	<dd>As defined by Tim Berners-Lee [[LINKED-DATA]].<p></p></dd>
	
	<dt>Client</dt>
	<dd>A program that establishes connections for the purpose of sending requests [[HTTP11]].<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
		[[HTTP11]]. </p></dd>
	
	<dt><dfn>Linked Data Platform Resource</dfn> (<abbr title="Linked Data Platform Resource">LDPR</abbr>)</dt>
	<dd>HTTP resource whose state is represented in any representation that conforms to the simple lifecycle
		patterns and conventions in <a href="#ldpr" class="sectionRef"></a>.<p></p></dd>
		
	<dt><dfn>Linked Data Platform RDF Resource</dfn> (<abbr title="Linked Data Platform RDF Resource">LDP-RR</abbr>)</dt>
	<dd>An <a title="Linked Data Platform Resource">LDP-R</a> whose state is represented in an RDF representation, specifically
	an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[rdf11-concepts]].
	<p></p></dd>	

	<dt><dfn>Linked Data Platform Binary Resource</dfn> (<abbr title="Linked Data Platform Binary Resource">LDP-BR</abbr>)</dt>
	<dd>An <a title="Linked Data Platform Resource">LDPR</a> whose state is <em>not</em> represented in an RDF representation.
	These are binary or text resources that do not have useful RDF representations.
	<p></p></dd>
		
	<dt><dfn>Linked Data Platform Container</dfn> (<abbr title="Linked Data Platform Container">LDPC</abbr>)</dt>
	<dd>An LDPR representing a collection of <a title="Membership triples">membership triples</a> which is uniquely identified by a URI
	that responds to client requests for creation, modification, and enumeration of its members that conforms to the simple lifecycle
	patterns and conventions in <a href="#ldpc" class="sectionRef"></a>
	<p></p></dd>
	
	<dt><dfn>Linked Data Platform Basic Container</dfn> (<abbr title="Linked Data Platform Basic Container">LDP-BC</abbr>)</dt>
	<dd>An <a title="Linked Data Platform Container">LDPC</a> that uses a predefined predicate to simply link to 
	its <a title="Containment">contained</a> resources.
	<p></p></dd>
	
	<dt><dfn>Linked Data Platform Direct Container</dfn> (<abbr title="Linked Data Platform Direct Container">LDP-DC</abbr>)</dt>
	<dd>An <a title="Linked Data Platform Container">LDPC</a> that has the flexibility of choosing what form the 
	<a title="Membership triples">membership triples</a> take.
	<p></p></dd>
	
	<dt><dfn>Linked Data Platform Indirect Container</dfn> (<abbr title="Linked Data Platform Indirect Container">LDP-IC</abbr>)</dt>
	<dd>An <a title="Linked Data Platform Container">LDPC</a> that is similar to a <a title="Linked Data Platform Direct Container">LDP-DC</a> 
	but it allows an indirection with the ability to list as member a resource, such as a URI representing a real-world object,
	that is different from the resource that is created.
	<p></p></dd>
		
	<dt><dfn>Membership</dfn></dt>
	<dd>The relationship linking an LDP-RR (LDPCs are also LDP-RRs) and its members LDPRs.  
	There often is a linked LDPCs that assists with managing the member LDPRs.<p></p></dd>

	<dt><dfn>Containment</dfn></dt>
	<dd>The relationship binding an LDPC to its contained LDPRs.  The
	lifecycle of the contained LDPR, depends on the containing LDPC.<p></p></dd>

	<dt><dfn>Membership triples</dfn></dt>
	<dd>A set of triples in an LDPC's state that lists its members.
		A container's membership triples all have one of the following patterns:
		<table style="margin-left: +3em">
		<tr>
		<td style="padding:0 0 0 +2ex"> <var style="background:#DDDDDD">membership-constant-URI</var> </td>
		<td style="padding:0 0 0 +2ex"> <var>membership-predicate</var> </td>
		<td style="padding:0 0 0 +2ex"> <var style="background:#CCFFFF">member-derived-URI</var> </td>
		</tr>
		<tr>
		<td style="padding:0 0 0 +2ex"> <var style="background:#CCFFFF">member-derived-URI</var> </td>
		<td style="padding:0 0 0 +2ex"> <var>membership-predicate</var> </td>
		<td style="padding:0 0 0 +2ex"> <var style="background:#DDDDDD">membership-constant-URI</var> </td>
		</tr>
		</table>
		The difference between the two is simply which position member-derived-URI occupies, which is usually
		driven by the choice of <var>membership-predicate</var>.  Most predicates have a natural forward direction
		inherent in their name, and existing vocabularies contain useful examples that read naturally in
		each direction.  <code>ldp:member</code> and <code>dcterms:isPartOf</code> are representative examples.
		<p>
		Each container exposes properties (see <a href="#ldpc-general" class="sectionRef"></a>)
		that allow clients to determine which pattern it
		uses, what the actual <var>membership-predicate</var> and <var>membership-constant-URI</var> values are, 
		and (for containers that allow the creation of new members) what value is used
		for the <var>member-derived-URI</var> based on the client's input to the 
		creation process.</p>
	<p></p></dd>
	
	<dt><dfn>Membership predicate</dfn></dt>
	<dd>The predicate of all a LDPC's <a title="Membership triples">membership triples</a>.
	<p></p></dd>
	
	<dt><dfn>Non-member resource</dfn></dt>
	<dd>A HTTP resource associated with a LDPC by a server for the purpose of enabling clients to
	retrieve a subset of the LDPC's state, namely the subset that omits the LDPC's membership triples.
	In other words, the union of the non-member resource's state and the LDPC's membership triples
	exactly equals the LDPC's state.
	<p></p></dd>
	
	<dt><dfn>Paged resource</dfn></dt>
	<dd>A resource whose representation may be too large to fit in a single HTTP response, for which an
	LDP server offers a sequence of single-page resources.  When the representations of the sequence's resources
	are combined by a client, the client has a (potentially incomplete or incoherent) copy of the paged resource's
	state.  If a paged resource <var>P</var> is an LDPR and is broken into a sequence of pages
	(single-page resources) <var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>,
	the representation of each <var>P<sub>i</sub></var> contains
	a subset of the triples in <var>P</var>.
	LDP allows paging of resources other than LDPRs, but does not specify how clients combine
	their representations.  See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.  For readers
	familiar with paged feeds [[RFC5005]], a paged resource is similar to a logical feed.
	Any resource could be considered to be a paged resource consisting of exactly one page, 
	although there is no known advantage in doing so.
	<p></p></dd>
	
	<dt><dfn>Single-page resource</dfn></dt>
	<dd>One of a sequence of related resources <var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>, 
	each of which contains a subset of the state
	of another resource <var>P</var>.  <var>P</var> is called the paged resource.
	For readers
	familiar with paged feeds [[RFC5005]], a single-page resource is similar to a feed document and the same
	coherency/completeness considerations apply.
	<a href="#ldpr-pagingGET-sequences-change">LDP provides no guarantees that the sequence is stable</a>.
	<p>
	Note: the choice of terms was designed to help authors and readers clearly differentiate between
	the <a title="Paged resource"><em>resource being paged</em></a>, and the 
	<a title="Single-page resource"><em>individual page resources</em></a>, 
	in cases where both are mentioned in
	close proximity.  
	<p></p></dd>
	
	<dt><dfn>first page link</dfn></dt>
	<dd>A link to the first <a title="Single-page resource">single-page resource</a>
	of a <a title="Paged resource">paged resource</a> <var>P</var>.  Syntactically, a
	HTTP <code>Link &lt;<var>P<sub>1</sub></var>&gt;; rel='first'</code>
	header [[!RFC5988]].
	<p></p></dd>
	
	<dt><dfn>next page link</dfn></dt>
	<dd>A link to the next <a title="Single-page resource">single-page resource</a> 
	of a <a title="Paged resource">paged resource</a> <var>P</var>.  Syntactically, a
	HTTP <code>Link &lt;<var>P<sub>i</sub></var>&gt;; rel='next'</code>
	header [[!RFC5988]] where the target URI is <var>P<sub>i=2...n</sub></var>.
	<p></p></dd>
	
	<dt><dfn>last page link</dfn></dt>
	<dd>A link to the last <a title="Single-page resource">single-page resource</a>
	of a <a title="Paged resource">paged resource</a> <var>P</var>.  Syntactically, a
	HTTP <code>Link &lt;<var>P<sub>n</sub></var>&gt;; rel='last'</code>
	header [[!RFC5988]].
	<p></p></dd>
	
	<dt><dfn>previous page link</dfn></dt>
	<dd>A link to the previous <a title="Single-page resource">single-page resource</a> 
	of a <a title="Paged resource">paged resource</a> <var>P</var>.  Syntactically, a
	HTTP <code>Link &lt;<var>P<sub>i</sub></var>&gt;; rel='prev'</code>
	header [[!RFC5988]] where the target URI is <var>P<sub>i=1...n-1</sub></var>.
	<p></p></dd>
	
  </dl>

<section id="conventions">
<h2>Conventions Used in This Document</h2>

	<p>Sample resource representations are provided in <code>text/turtle</code>
		format [[TURTLE]].</p>
	<p>Commonly used namespace prefixes:</p>
	<pre style="word-wrap: break-word; white-space: pre-wrap;">	@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
	@prefix foaf:     &lt;http://xmlns.com/foaf/0.1/&gt;.
	@prefix rdf:     &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
	@prefix ldp:     &lt;http://www.w3.org/ns/ldp#&gt;.
	@prefix xsd:     &lt;http://www.w3.org/2001/XMLSchema#&gt;.</pre>
</section>
</section>
    
<section id='conformance'>

<p>LDP uses the term <b><dfn>informative</dfn></b> as a synonym for non-normative.</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><dfn>LDP client</dfn></b> is a conforming HTTP client [[!HTTP11]] that follows the rules defined by LDP in
<a href="#ldpclient" class="sectionRef"></a>.
</p>

<p>A conforming <b><dfn>LDP server</dfn></b> is a conforming HTTP server [[!HTTP11]] that follows the rules defined by LDP in 
<a href="#ldpr" class="sectionRef"></a> when it is serving LDPRs, and also
<a href="#ldpc" class="sectionRef"></a> when it is serving LDPCs.
LDP does not constrain its behavior when serving other HTTP resources.
</p>
</section>

<section id="ldpclient">
<h1>Linked Data Platform Clients</h1>
<p>All of the following are conformance rules for <a title="LDP server">LDP Clients</a>.
</p>
<section><h2>General</h2>
	<section id="ldp-cli-multitype"><h2 class="normal">In the absence of special knowledge of the application or domain, 
		<a title="LDP client">LDP clients</a> MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
	</h2></section> <!-- Was 4.3.5 / #ldpr-4_3_5 -->
	
	<section id="ldpr-cli-typeschange"><h2 class="normal">In the absence of special knowledge of the application or domain, 
		<a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
		of a given LDPR can change over time.
	</h2></section> <!-- Was 4.3.6 / #ldpr-4_3_6 -->
	
	<section id="ldpr-cli-openpreds"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD 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.
	</h2></section> <!-- Was 4.5.3 / #ldpr-ldpr-4_5_3 -->
	
	<section id="ldpr-cli-preservetriples"><h2 class="normal">A <a title="LDP client">LDP client</a> MUST 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>.  The use of HTTP
		<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
		[[RFC5789]].
	</h2></section> <!-- Was 4.5.5 / #ldpr-ldpr-4_5_5 -->
</section>
</section> <!-- Client constraints -->

<section id="ldpr">
<h1>Linked Data Platform Resources</h1>

<section class="informative" id="ldpr-informative">
<h2>Informative</h2>
	<p>Linked Data Platform Resources (<dfn><abbr title="Linked Data Platform Resources">LDPRs</abbr></dfn>) are HTTP resources
		that conform to the simple patterns and conventions in this section.
		HTTP requests to access, modify, create or delete LDPRs are accepted
		and processed by <a title="LDP server">LDP servers</a>. Most LDPRs are domain-specific resources
		that contain data for an entity in some domain, which could be
		commercial, governmental, scientific, religious, or other.</p>
	<p>Some of the rules defined in this document provide
		clarification and refinement of the base Linked Data rules [[LINKED-DATA]];
		others address additional needs.</p>
	<p>The 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 in the <a
			href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html"
			class="external"
			title="LDP Best Practices and Guidelines"
			rel="nofollow">LDP Best Practices and Guidelines editor's draft</a> that addresses
		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 conformance rules for LDP servers when serving LDPRs.
		This document also explains <a href="#ldpr-Paging">how a server paginates an LDPR's representation</a> if it gets too big.
		Companion informative documents describe additional guidelines for use when interacting with LDPRs. 
	</p>
	<p>An LDP server manages two kinds of <a title="Linked Data Platform Resources">LDPRs</a>, those resources who whose state 
	is represented using an RDF representation (LDP-RR) and those using other representations (LDP-BR).  LDP-RRs have the unique
	quality in that their representation is based on the RDF which provides for a number of use cases from web metadata, open data 
	models, machine processable information and automated processing by software agents [[!RDF-CONCEPTS]].  LDP-BRs are almost anything
	on the Web today: images, html pages, word processing documents, spreadsheets, etc and LDP-RRs often serve a purpose to manage the 
	metadata associated with LDP-BRs.
	</p>
    <figure id="fig-ldpr-types">
        <img src="images/ldpr1.png" alt="Sample separation of Linked Data Platform Resource" />
        <figcaption>Samples of different types of LDPRs</figcaption>
    </figure>
    <p>The LDP-BRs and LDP-RRs are simply sub-types of LDPRs, as illustrated in <a href="#fig-ldpr-class"></a>.</p>  
    <figure id="fig-ldpr-class">
       <img src="images/ldpr2.png" alt="Class Diagram of Linked Data Platform Resource" />
       <figcaption>Class relationship of types of LDPRs</figcaption>
     </figure>
	
</section>

<section id="ldpr-general">
<h2>General</h2>
		
	<section id="ldpr-gen-http"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].
	</h2></section><!-- Was 4.2.1 / #ldpr-4_2_1 -->
	
	<section id="ldpr-gen-rdf"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide an RDF representation for <a title="Linked Data Platform RDF Resource">LDP-RRs</a>. 
	The HTTP <code>Request-URI</code> of the LDP-RR is typically the subject of most triples in the response.
	</h2></section><!-- Was 4.2.2 / #ldpr-4_2_2 -->
	
	<section id="ldpr-gen-binary"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY host a mixture of LDPRs, <a title="Linked Data Platform RDF Resource">LDP-RRs</a>
	and <a title="Linked Data Platform Binary Resource">LDP-BRs</a>. For example, it
		is common for <a title="LDP server">LDP servers</a> to need to host binary or text resources
		that do not have useful RDF representations.</h2></section><!-- Was 4.2.3 / #ldpr-4_2_3 -->

	<section id="ldpr-gen-reusevocab"><h2 class="normal"><a title="Linked Data Platform RDF Resource">LDP-RRs</a> SHOULD 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.
	</h2></section><!-- Was 4.2.4 / #ldpr-4_2_4 -->
	
	<section id="ldpr-gen-reusevocabsuchas"><h2 class="normal"><a title="Linked Data Platform RDF Resource">LDP-RRs</a> predicates SHOULD use standard vocabularies such as Dublin Core
		[[!DC-TERMS]], RDF [[!RDF-CONCEPTS]] and RDF Schema [[!RDF-SCHEMA]], whenever
		possible.
	</h2></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->
	
	<section id="ldpr-gen-atleast1rdftype"><h2 class="normal"><a title="Linked Data Platform RDF Resource">LDP-RRs</a> representations SHOULD have at least one <code>rdf:type</code>
		set explicitly.  This makes the representations much more useful to
		client applications that don’t support inferencing.
	</h2></section><!-- Was 4.2.5 / #ldpr-4_2_5 -->
	
	<section id="ldpr-gen-etags"><h2 class="normal"><a title="LDP server">LDP server</a> responses MUST use entity tags (either 
		weak or strong ones) as response <code>ETag</code> header values.
	</h2></section><!-- Was 4.2.8 / #ldpr-4_2_8 -->
	
	<section id="ldpr-gen-linktypehdr"><h2 class="normal"><a title="LDP server">LDP servers</a>
		exposing LDPRs 
		MUST 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 LDPR's HTTP <code>Request-URI</code>. 
	</h2></section><!-- Was 4.2.10 / #ldpr-4_2_10 -->
	
	<!-- TODO: Is this RDFResource or just Resource?  Language gets odd in section #ldpc-post-createrdf , where it says "then the server MUST create
	an LDPR".  If client sent a JPEG and type=#RDFResource, what should the server do?  If the more generic #Resource, seems to catch
	what is intended -->
	<blockquote>
		<p>
		Note: 
		The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP specification 
		on a specific resource in a way that clients can inspect dynamically at run-time.   
		This is <strong>not</strong> equivalent to the
		presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in an RDF resource.
		The presence of this header asserts that the server complies with the LDP specification's constraints on 
		HTTP interactions with LDPRs, that is
		it asserts that the resource <a href="#ldpr-gen-tags">has Etags</a>, <a href="#ldpr-gen-rdf">has an RDF representation</a>, and so on,
		which is not true of all Web resources served as RDF media types.
		</p>
		<p>
		Note: 
		<a href="#ldpr-gen-binary">A LDP server can host a mixture of LDPRs 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 LDPRs.  Each HTTP <code>Request-URI</code> needs to be 
		individually inspected, in the absence of outside information.
		</p>
	</blockquote>
	
	<section id="ldpr-gen-noinferencing"><h2 class="normal"><a title="LDP server">LDP servers</a>
		MUST NOT require LDP clients to implement inferencing in order to recognize the subset
		of content defined by LDP.  Other specifications built on top of LDP may require clients
		to implement inferencing [[!RDF-CONCEPTS]].  The practical implication is that all content defined by LDP
		must be explicitly represented. 
	</h2></section><!-- Was 4.2.11 / #ldpr-4_2_11 -->
	
	<section id="ldpr-gen-defbaseuri"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST assign the default 
		base-URI for [[!RFC3987]] 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.
	</h2></section><!-- Was 4.2.12 / #ldpr-4_2_12 -->
	
	<section id="ldpr-gen-pubclireqs"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST 
		publish any constraints on <a title="LDP client">LDP clients’</a> ability to 
		create or update LDPRs, by adding a Link header with <code>rel='describedby'</code> 
		[[!POWDER-DR]] to all responses to requests which fail due to violation of 
		those constraints.  For example, a server that refuses resource creation 
		requests via HTTP PUT, POST, or PATCH would return this <code>Link</code> header on its 
		4xx responses to such requests.
		The same <code>Link</code> header MAY be provided on other responses.  LDP neither 
		defines nor constrains the representation of the link's target resource; 
		as stated in [[POWDER-DR]], the target might (or might not) be a POWDER 
		document.  Natural language constraint documents are therefore permitted, 
		although machine-readable ones facilitate better client interactions.
	</h2></section><!-- Was 4.2.13 / #ldpr-4_2_13 -->
	
	<section id="ldpr-page-large"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDPRs in
		pages.
		See <a href="#ldpr-Paging" class="sectionRef"></a> for additional requirements associated with <a title="Paged resource">paged resources</a>.
	</h2></section><!-- Was 4.2.14 / #ldpr-4_2_14 -->
	
	<section id="ldpr-split-any"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY 
		treat any resource (LDPR or not) as a <a title="Paged resource">paged resource</a>. 
		See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
	</h2></section><!-- Was 4.2.15 / #ldpr-4_2_15 -->

</section>

<section id="ldpr-HTTP_GET">
<h2>HTTP GET</h2>
	<section id="ldpr-get-must"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP <code>GET</code> Method for LDPRs.
	</h2></section><!-- Was 4.3.1 / #ldpr-4_3_1 -->
	
	<section id="ldpr-get-options"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP response headers defined in 
		<a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
	</h2></section><!-- Was 4.3.2 / #ldpr-4_3_2 -->
	
	<section id="ldpr-get-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide a <code>text/turtle</code>
		representation of the requested <a title="Linked Data Platform RDF Resource">LDP-RR</a> [[!TURTLE]].
	</h2></section><!-- Was 4.3.3 / #ldpr-4_3_3 -->

</section>

<section id="ldpr-HTTP_POST">
<h2>HTTP POST</h2>
	<p>This specification adds no new requirements on HTTP <code>POST</code> for LDPRs 
		even when the LDPR supports that method.  This specification does not impose any
		new requirement to support that method, and [[!HTTP11]] makes it optional.
	</p>
	<p>Clients can create LDPRs via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef"></a>) or
		<code>PUT</code> (<a href="#ldpc-HTTP_PUT" class="sectionRef"></a>) to a LDPC, see those 
		sections for more details.  Any server-imposed constraints on LDPR creation or update  
		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
	<!-- TODO: movethis content into an intro/overview section and add PATCH. -->
	</p>
</section>

<section id="ldpr-HTTP_PUT">
<h2>HTTP PUT</h2>
	<p>This specification imposes the following new requirements on HTTP <code>PUT</code> for LDPRs 
		only when the LDPR supports that method.  This specification does not impose any
		new requirement to support that method, and [[!HTTP11]] makes it optional.
		Any server-imposed constraints on LDPR creation or update  
		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
	</p>
		
	<section id="ldpr-put-replaceall"><h2 class="normal">If a HTTP <code>PUT</code> is accepted on an existing resource, 
		<a title="LDP server">LDP servers</a> MUST
		replace the entire persistent state of the identified resource with
		the entity representation in the body of the request. 
		<a title="LDP server">LDP servers</a> MAY ignore server managed properties such as <code>dcterms:modified</code> 
		and <code>dcterms:creator</code> if they are not under
		client control. Any <a title="LDP server">LDP servers</a> that wish
		to support a more sophisticated merge of data provided by the client
		with existing state stored on the server for a resource MUST use HTTP
		<code>PATCH</code>, not HTTP <code>PUT</code>.
	</h2></section><!-- Was 4.5.1 / #ldpr-4_5_1 -->
		
	<section id="ldpr-put-servermanagedprops"><h2 class="normal">
		If an otherwise valid HTTP <code>PUT</code> request is received 
		that attempts to change triples the server does not allow clients to modify, 
		<a title="LDP server">LDP servers</a> MUST 
		respond with a 4xx range status code (typically
		409 Conflict). 
		<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
		information about which triples could not be
		persisted.
		The format of the 4xx response body is not constrained by LDP.
	</h2></section><!-- Was 4.5.1.1 / #ldpr-4_5_1_1 -->
	<blockquote>
		Informative note: Clients might provide triples equivalent to those already in the resource's state,
		e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the 
		server-controlled triples are identical on the GET response and the subsequent PUT request.
	</blockquote>
		
	<section id="ldpr-put-precond"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD 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. <a title="LDP server">LDP servers</a> SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
		to detect collisions. <a title="LDP server">LDP servers</a> MUST respond with status code 412
		(Condition Failed) if <code>ETag</code>s fail to match when there are no other
		errors with the request [[!HTTP11]].  <a title="LDP server">LDP servers</a> that require conditional requests MUST respond with status code 428
		(Precondition Required) when the absence of a precondition is the only reason for rejecting the request [[!RFC6585]].
	</h2></section><!-- Was 4.5.2 / #ldpr-4_5_2 -->
	
	<section id="ldpr-put-failed"><h2 class="normal">
		If an otherwise valid HTTP <code>PUT</code> request is received that contains triples the server 
		chooses not to persist, e.g. unknown content,
		<a title="LDP server">LDP servers</a> MUST respond with an appropriate 4xx range status code
		[[HTTP11]].  
		<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
		information about which triples could not be
		persisted.
		The format of the 4xx response body is not constrained by LDP.
		<!-- TODO: MUST respond with Link rel='describedBy' as in 4.2.13 -->
	</h2></section><!-- Was 4.5.4 / #ldpr-4_5_4 -->
	
	<section id="ldpr-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
	</h2></section><!-- Was 4.5.6 / #ldpr-4_5_6 -->
	
	<section id="ldpr-put-simpleupdate"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to update resources without
		requiring detailed knowledge of server-specific constraints.  
		This is a consequence of the requirement to enable simple creation and modification of LDPRs.
	</h2></section><!-- Was 4.5.7 / #ldpr-4_5_7 -->	
</section>
		
<section id="ldpr-HTTP_DELETE">
<h2>HTTP DELETE</h2>
	<p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for LDPRs 
		only when the LDPR supports that method.  This specification does not impose any
		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
	<p>Additional requirements on HTTP <code>DELETE</code> of LDPRs within containers can be found in
</section>

<section id="ldpr-HTTP_HEAD">
<h2>HTTP HEAD</h2>
	<p>Note that certain LDP mechanisms, such as <a href="#ldpr-Paging">paging</a>, 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 sections <a href="#ldpr-HTTP_GET"></a> 
		and <a href="#ldpr-HTTP_OPTIONS"></a>.</p>
	<section id="ldpr-head-must"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP <code>HEAD</code> method.
	</h2></section><!-- Was 4.7.1 / #ldpr-4_7_1 -->
</section>

<section id="ldpr-HTTP_PATCH">
<h2>HTTP PATCH</h2>
	<p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for LDPRs 
		only when the LDPR supports that method.  This specification does not impose any
		new requirement to support that method, and [[!HTTP11]] makes it optional.
		Any server-imposed constraints on LDPR creation or update  
		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
	</p>	

	<section id="ldpr-patch-create"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD NOT allow clients to create new resources using <code>PATCH</code>.
		<a href="#ldpc-HTTP_POST"><code>POST</code> (to an LDPC)</a> and/or <a href="#ldpr-HTTP_PUT"><code>PUT</code></a> should be used as the standard way to create new LDPRs.
	</h2></section><!-- Was 4.8.3 / #ldpr-4_8_3 -->
	
	<section id="ldpr-patch-acceptpatch"><h2 class="normal"><a title="LDP server">LDP servers</a> that support <code>PATCH</code> MUST
		include an <code>Accept-Patch</code> HTTP response header [[!RFC5789]] on HTTP <code>OPTIONS</code>
		requests, listing patch document media type(s) supported by the server.
	</h2></section><!-- Was 4.8.4 / #ldpr-4_8_4 -->

</section>

<section id="ldpr-HTTP_OPTIONS">
<h2>HTTP OPTIONS</h2>
	<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPRs 
		beyond those in [[!HTTP11]].  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>

	<section id="ldpr-options-must"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP <code>OPTIONS</code> method.
	</h2></section><!-- Was 4.9.1 / #ldpr-4_9_1 -->
		
	<section id="ldpr-options-allow"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST indicate their support for HTTP Methods by
		responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
		Method tokens in the HTTP response header <code>Allow</code>.
	</h2></section><!-- Was 4.9.2 / #ldpr-4_9_2 -->
		
</section>

<section id="ldpr-Paging">
<h2>Paging</h2>

<section class="informative" id="ldpr-PagingIntro">
<h3>Introduction</h3>
	<p>It sometimes happens that a
		resource is too large to reasonably transmit its representation in a
		single HTTP response.  
		To address this problem, servers should support a technique called Paging.  
		When a client retrieves such a resource, the server includes in its response
		a link to the next part of the resource's state, at a URL of the server's choosing.
		The triples in the representation of the <a title="Single-page resource">each page of an LDPR</a>
		are typically a subset of the triples from the <a title="Paged resource">paged resource</a>.
	</p>
	<p><a title="LDP server">LDP servers</a> may respond to requests for a
		resource by returning the first page of the resource
		with a <code>Link &lt;next-page-URL&gt;;type='next'</code> header containing the URL for the next page.
		Clients inspect each response for the link header to see if additional pages
		are available; paging does not affect the choice of HTTP status code.
		Note that paging is lossy, as described in [[RFC5005]], and so (as stated there)
		clients should not make any assumptions about a set of pages being a complete or 
		coherent snapshot of a resource's state.</p>
	<p>
		Looking at an example resource representing Example Co.'s customer
		relationship data, identified by the URI <code>http://example.org/customer-relations</code>,
		we’ll split the response across two pages.  
		The client 
		retrieves <code>http://example.org/customer-relations</code>, and
		the server responds with status code 200 (OK) and the following representation:
	</p>

<pre class="example" id="ldpc-ex-page1"># The following is the representation of
#    http://example.org/customer-relations
#    Requests on the URI will result in responses that include the following HTTP header
#       Link: &lt;http://example.org/customer-relations?p=2&gt;; rel='next'
#    This Link header is how clients discover the URI of the next page in sequence,
#    and that the resource supports paging.
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
@base &lt;http://example.org/customer-relations&gt;.

&lt;&gt;
   a o:CustomerRelations;
   dcterms:title "The customer information for Example Co.";
   o:client &lt;#JohnZSmith&gt;, &lt;#BettyASmith&gt;, &lt;#JoanRSmith&gt;. 

&lt;#JohnZSmith&gt;
   a foaf:Person;
   o:status o:ActiveCustomer;
   foaf:name "John Z. Smith".
&lt;#BettyASmith&gt;
   a foaf:Person;
   o:status o:PreviousCustomer;
   foaf:name "Betty A. Smith".
 &lt;#JoanRSmith&gt;
   a foaf:Person;
   o:status o:PotentialCustomer;
   foaf:name "Joan R. Smith".</pre>

	<p>
		Because the server includes a <code>Link: &lt;http://example.org/customer-relations?p=2&gt;; rel='next'</code>
		response header, the client knows that more data exists and where to find it.
		The server determines the size of the pages using application specific methods not defined
		within this specificiation. The next page link's target URI is also
		defined by the server and not this specification.
	</p>
	<p>
		The following example is the result of retrieving
		the next page; 
		the server responds with status code 200 (OK) and the following representation:
	</p>

<pre class="example" id="ldpc-ex-page2"># The following is the representation of
#  http://example.org/customer-relations?p=2
#
#  There is no "next" Link in the server's response, so this is the final page.
#
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
@base &lt;http://example.org/customer-relations&gt;.

&lt;&gt;
   o:client &lt;#GlenWSmith&gt;, &lt;#AlfredESmith&gt;. 
 
&lt;#GlenWSmith&gt;
   a foaf:Person;
   o:status o:ActiveCustomer, o:GoldCustomer;
   foaf:name "Glen W. Smith".

&lt;#AlfredESmith&gt;
   a foaf:Person;
   o:status o:ActiveCustomer, o:BronzeCustomer;
   foaf:name "Alfred E. Smith".
 </pre>
	<p>
		In this example, there are only two customers provided in the
		final page.  To indicate this is the last page, the server omits the <code>Link: rel='next'</code> 
		header in its response.
	</p>
	<p>
		As mentioned above, retrieving all the pages offered by a server gives no guarantee to a client
		that it knows the entire state of the server.  For example, after the server constructs the
		the first page representation, another
		actor could delete <code>client#BettyASmith</code> from the server.  
	</p>
</section>

<section id="ldpr-PagingGET">
<h3>HTTP GET</h3>
	<p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef"></a> on HTTP <code>GET</code>, 
		<a title="LDP server">LDP servers</a> that support paging must 
		also follow the requirements in this section for all <a title="Paged resource">paged resources</a>
		and their associated <a title="Single-page resource">single-page resources</a>.
	</p>

	<section id="ldpr-pagingGET-sequences-change"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
		add <a title="Single-page resource">single-page resources</a> to a 
		<a title="Paged resource">paged resource's</a> sequence over time,
		but SHOULD only add pages to the end of a sequence.
		</h2><!-- Was 4.10.2.1 / #ldpr-pagingGET-sequences-change -->
		<blockquote>Informative note: 
		As a result, clients retrieving any <a title="Single-page resource">single-page resource</a> several times can observe its place in the sequence
		change as the state of the <a title="Paged resource">paged resource</a> changes.
		For example, a nominally last page's server might provide a
		<a>next page link</a> when the page is retrieved.  Similar situations arise when the page sequence crosses server boundaries; 
		server A might host the initial portion of a sequence that links to the last page server A is aware of,  
		hosted on server B, and server B might extend the sequence of pages.
		</blockquote>

		<section id="ldpr-pagingGET-first-allowed-onpages"><h2 class="normal">
			<a title="LDP server">LDP servers</a> MAY provide 
			a <a>first page link</a> when responding to 
			requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
		</h2></section><!-- Was 4.10.2.1.1 / #ldpr-pagingGET-sequences-change -->
	
		<section id="ldpr-pagingGET-last-allowed-onpages"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
			provide a <a>last page link</a>
			in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
		</h2></section><!-- Was 4.10.2.1.3 / #ldpr-pagingGET-last-allowed-onpages -->
	</section>
	
	<section id="ldpr-pagingGET-next-reqd"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
		provide a <a>next page link</a>
		in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> 
		<em>other than the final page</em>
		as the <code>Request-URI</code>.
		This is the mechanism by which clients can discover the URL of the next page. 
	</h2><!-- Was 4.10.2.2 / #ldpr-pagingGET-next-reqd-change -->
	
		<section id="ldpr-pagingGET-lastnext-prohibited"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST NOT
			provide a <a>next page link</a>
			in responses to <code>GET</code> requests with the final <a title="Single-page resource">single-page resource</a> 
			as the <code>Request-URI</code>.
			This is the mechanism by which clients can discover the end of the page sequence
			as currently known by the server.  
		</h2></section><!-- Was 4.10.2.2.1 / #ldpr-pagingGET-lastnext-prohibited -->
		
		<section id="ldpr-pagingGET-prev-allowed"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
			provide a <a>previous page link</a>
			in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
			<em>other than the first page</em>
			as the <code>Request-URI</code>.
			This is one mechanism by which clients can discover the URL of the previous page.  
		</h2></section><!-- Was 4.10.2.2.2 / #ldpr-pagingGET-prev-allowed -->
		
		<section id="ldpr-pagingGET-firstprev-prohibited"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST NOT
			provide a <a>previous page link</a>
			in responses to <code>GET</code> requests with the <em>first</em> <a title="Single-page resource">single-page resource</a> 
			as the <code>Request-URI</code>.
			This is one mechanism by which clients can discover the beginning of the page sequence
			as currently known by the server.  
		</h2></section><!-- Was 4.10.2.2.3 / #ldpr-pagingGET-firstprev-prohibited -->
	</section>

	<section id="ldpr-pagingGET-page-type-reqd"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
		provide an HTTP <code>Link</code>
		header whose target URI is <code>http://www.w3.org/ns/ldp#Page</code>, and whose link relation type is <code>type</code> [[!RFC5988]]
		in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> 
		as the <code>Request-URI</code>.
		This is one mechanism by which clients know that the resource is one of a sequence of pages.  
	</h2></section><!-- Was 4.10.2.4 / #ldpr-pagingGET-page-type-reqd -->
</section>

<section id="ldpr-paging-HTTP_OPTIONS">
<h3>HTTP OPTIONS</h3>

	<p>In addition to the requirements set forth in 
		<a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a> on HTTP <code>OPTIONS</code>, 
		<a title="LDP server">LDP servers</a> that support paging must also 
		follow the requirements in this section for all <a title="Paged resource">paged resources</a>.
		Note that LDP only requires enough from <code>OPTIONS</code> 
		for discovery of paging support on a resource, which is considerably
		less than is required for HTTP <code>GET</code>.  
		This lowers server implementation effort.
	</p>

</section> <!-- h3 -->

</section> <!-- h2 -->

</section> <!-- h1 -->

<section id="ldpc">
<h1>Linked Data Platform Containers</h1>

<section class="informative" id="ldpc-informative">		
<h2>Informative</h2>
	<p>Many HTTP applications and sites have organizing
		concepts that partition the overall space of resources into smaller
		containers. Blog posts are grouped into blogs, wiki pages are grouped
		into wikis, and products are grouped into catalogs. Each resource
		created in the application or site is created within an instance of
		one of these container-like entities, and users can list the existing
		artifacts within one. 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 <a title="Membership triples">membership triples</a> that follow a consistent pattern
		(see the linked-to definition for the possible patterns). 
		The membership triples of a container all
		have the same predicate, called the membership predicate, 
		and either the subject or the object is also a consistent value
		– the remaining position of the membership
		triples (the one that varies) define the members of the container. 
		In the simplest cases, the
		consistent value will be the LDPC resource's URI, 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>ldp:member</code> predicate.
	</p>
	<p>This document includes a set of guidelines for
		creating new resources and adding them to the list of
		members of a container. It goes on to explain how to learn about a set of related
		resources, regardless of how they were created or added to the container's membership.
		It also defines behavior when resources created using a container are later deleted;
		deleting containers removes membership information and
		possibly performs 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>

<pre class="example" id="ldpc-ex-simple"># The following is the representation of
#    http://example.org/c1/
<!-- @base is here only so it's easier to paste into validators for checking -->
# @base &lt;http://example.org/c1/&gt;
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.

&lt;&gt;
   a ldp:Container, ldp:BasicContainer;
   ldp:containerResource &lt;&gt; ;
   ldp:containsRelation ldp:member;
   ldp:insertedContentRelation ldp:MemberSubject;
   dcterms:title "A very simple container";
   ldp:member &lt;r1&gt;, &lt;r2&gt;, &lt;r3&gt;.</pre>
 
   	<figure id="fig-ldpc-basic">
        <img src="images/ldpc-basic.png" alt="Sample Linked Data Platform Basic Container" />
        <figcaption>Sample of Linked Data Platform Basic Container</figcaption>
    </figure>

	<p>This example is very straightforward - the
	membership predicate is <code>ldp:member</code> and the other
	consistent membership value is the container's
	URI, occurring in the subject position of the triples. 
	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.  This type of container is also refered to as
	<a title="Linked Data Platform Basic Container">LDP Basic Container</a>.</p>

	<p>Sometimes it is useful to use a subject
	other than the container itself as the consistent membership value, and/or to use
	a predicate other than <code>ldp:member</code> as the membership predicate. Let's
	start with a domain resource for a person's net worth, as illustrated below:</p>
			
<pre class="example" id="ldpc-ex-membership-partial"># The following is a partial representation of
#   http://example.org/netWorth/nw1
<!-- @base is here only so it's easier to paste into validators for checking -->
# @base &lt;http://example.org/netWorth/nw1/&gt;
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;&gt;
   a o:NetWorth;
   o:netWorthOf &lt;http://example.org/users/JohnZSmith&gt;;
   o:asset 
      &lt;assetContainer/a1&gt;,
      &lt;assetContainer/a2&gt;;
   o:liability 
      &lt;liabilityContainer/l1&gt;,
      &lt;liabilityContainer/l2&gt;,
      &lt;liabilityContainer/l3&gt;.
</pre>
	<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 in the 3 examples below:
	</p>

<pre class="example" id="ldpc-ex-membership-full"># The following is an elaborated representation of LDPR
#   http://example.org/netWorth/nw1
<!-- @base is here only so it's easier to paste into validators for checking -->
# @base &lt;http://example.org/netWorth/nw1/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;&gt;
   a o:NetWorth;
   o:netWorthOf &lt;http://example.org/users/JohnZSmith&gt;;
   o:asset 
      &lt;assetContainer/a1&gt;,
      &lt;assetContainer/a2&gt;;
   o:liability 
      &lt;liabilityContainer/l1&gt;,
      &lt;liabilityContainer/l2&gt;,
      &lt;liabilityContainer/l3&gt;.
</pre>

<pre class="example" id="ldpc-ex-membership-subj"># The following is an elaborated representation of LDPC
#   http://example.org/netWorth/nw1/assetContainer/
<!-- @base is here only so it's easier to paste into validators for checking -->
# @base &lt;http://example.org/netWorth/nw1/assetContainer/&gt;
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;&gt;
   a ldp:Container, ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:containerResource &lt;&gt;;
   ldp:containsRelation o:asset;
   ldp:insertedContentRelation ldp:MemberSubject;
   ldp:contains &lt;a1&gt;, &lt;a2&gt;.
</pre>

<pre class="example" id="ldpc-ex-membership-full-liabcont"># The following is an elaborated representation of LDPC
#   http://example.org/netWorth/nw1/liabilityContainer/
<!-- @base is here only so it's easier to paste into validators for checking -->
# @base &lt;http://example.org/netWorth/nw1/liabilityContainer/&gt;
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;&gt;
   a ldp:Container, ldp:DirectContainer;
   dcterms:title "The liabilities of JohnZSmith";
   ldp:containerResource &lt;&gt;;
   ldp:containsRelation o:liability;
   ldp:insertedContentRelation ldp:MemberSubject;
   ldp:contains l1&gt;, l2&gt;, l3&gt;.
</pre>

	<p>The essential structure of the container is
	the same, but in this example, the consistent membership value (still in the subject position) 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 resource and containment 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>
	<p>This type of container is refered to as an <a title="Linked Data Platform Direct Container">LDP Direct Container</a>.  An
	 <a title="Linked Data Platform Basic Container">LDP Basic Container</a> is a constrained form of 
	 <a title="Linked Data Platform Direct Container">LDP Direct Container</a> where the 
	 membership predicate is <code>ldp:contains</code> and the container resource is the container itself.
	</p>

	<p>As seen in the <a href="#ldpc-ex-membership-subj"><code>assetContainer/</code> example</a>, 
	clients cannot correctly guess
	at the membership triples, so the example includes this information in
	triples whose subject is the LDPC resource itself.
	</p>
	
	<p>Alternatively, servers may provide the net worth resource and supporting containers in a single response
	representations.  When doing this, a preference would be for RDF formats that support multiple named graphs, one
	named graph for the net worth resource and then two others for asset and liability containers.  This allows for
	the membership triples to be represented with the named graph for the net worth resource, while the containment triples
	would be represented within the liability and asset containers [[rdf11-concepts]].  Generally, the membership triples belong
	to the representation of a LDP-RR and the containment triples belong to the representation of the LDPC.
	</p>
	
	<p>Additionally, we could extend our net worth example to include a container for
	advisors (people) that have managed the assets and liabilities.  We have decided
	to identify these advisors with URLs that contain a fragment (hash) to represent
	these real-world resources, not the documents that decribe them.</p>
	
<pre class="example" id="ldpc-ex-membership-full"># The following is an elaborated representation of
#   http://example.org/netWorth/nw1
# Adding o:advisor but eaving off o:asset and o:liability for brevity.
<!-- @base is here only so it's easier to paste into validators for checking -->
# @base &lt;http://example.org/netWorth/nw1/&gt;
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;&gt;
   a o:NetWorth;
   o:netWorthOf &lt;http://example.org/users/JohnZSmith&gt;;
   o:advisor
   	 &lt;advisorContainer/bob#me&gt;,
   	 &lt;advisorContainer/marsha#me&gt;.
   	 
&lt;advisorContainer/&gt;
   a ldp:Container, ldp:IndirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:containerResource &lt;&gt;;
   ldp:containsRelation o:asset;
   ldp:insertedContentRelation foaf:primaryTopic;
   ldp:contains
   	 &lt;advisorContainer/bob&gt;,
   	 &lt;advisorContainer/marsha&gt;.
</pre>	
	
	<p>To handle this type of indirection, the triple with predicate of <code>ldp:insertedContentRelation</code> and object of 
	<code>foaf:primaryTopic</code> informs clients that when POSTing to this container, they will include a triple of the
	form (LDPR, foaf:primaryTopic, LDPR#me) to inform the server which URI to use for the membership triple.</p>
	
	<p>This type of container is also refered to as an <a title="Linked Data Platform Indirect Container">LDP Indirect Container</a>. 
	It is similar to a an <a title="Linked Data Platform Direct Container">LDP Direct Container</a> 
	but it allows an indirection with the ability to list as member a resource, such as a URI representing a real-world object,
	that is different from the resource that is created.</p>

	<p><a href="#fig-ldpc-types"></a> illustrates the 3 types: Basic, Direct and Indirect, along
	with their relationship to types of LDPRs.  It is not expected that there will be a container
	with a <code>rdf:type</code> solely of <code>ldp:Container</code>.</p>
	
	 <figure id="fig-ldpc-types">
        <img src="images/ldpc1.png" alt="Types of Linked Data Platform Containers" />
        <figcaption>Types of Linked Data Platform Containers</figcaption>
    </figure>

<div class="ldp-issue-pending">
<p>Still editing for ACTION-120 -- table work in progress, fate unknown</p>
	
	<p>The following table illustrates some differences between <a title="membership">membership</a> and 
	<a title="containment">containment</a> triples.  For details on the normative behavior, see appropriate sections
	below.
	</p>
	<table border="1" id="ldpc-mbrcntdiff">
		<thead><tr><th rowspan="2">Completed Request</th><th colspan="2">Effects</th></tr>
		       <tr><th>Membership</th><th>Containment</th></tr></thead>
		<tr><td>LDPR created in LDPC</td><td>New triple based on type of container (see following rows)</td><td>New triple: 
			(LDPC, ldp:contains, LDPR)</td></tr>
		<tr><td>LDPR created in LDP-BC</td><td>New triple: (LDPC, ldp:contains, LDPR)</td><td>Same</td></tr>
		<tr><td>LDPR created in LDP-DC</td><td>New triple links LDP-RR to created LDPR. LDP-RR URI may be same as LDP-DC</td>
			<td>New triple: (LDPC, ldp:contains, LDPR)</td></tr>
		<tr><td>LDPR created in LDP-IC</td><td>New triple links LDP-RR to content indicated URI</td>
			<td>New triple: (LDPC, ldp:contains, LDPR)</td></tr>
		<tr><td>LDPR is deleted</td><td>Triples may be removed</td><td>Triples are removed
			</td></tr>
		<tr><td>LDPC is deleted</td><td>Triples and member resources may be removed</td><td>Triples of form 
			(LDPC, ldp:contains, LDPR) and contained LDPRs are removed</td></tr>

	</table>
</div>	
	<section id="ldpc-get_non-member_props"><h2 class="normal">Retrieving Only Non-member Properties
	</h2><!-- Was 5.1.1 / #ldpc-get_non-member_props -->
	<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 LDPC a corresponding
		resource, called the “<a>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 SPARQL endpoints. [[SPARQL-QUERY]]</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 id="ldpc-ex-non-member">Request:</p>
<pre class="example">GET /container1?non-member-properties HTTP/1.1
Host: example.org
Accept: text/turtle; charset=UTF-8
</pre>
<p>Response:</p>
<pre class="example">HTTP/1.1 200 OK
Content-Type: text/turtle; charset=UTF-8
ETag: "_87e52ce291112"
Content-Length: 325
Link: &lt;http://www.w3.org/ns/ldp/Container&gt;; rel="type"

@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.

&lt;http://example.org/container1/&gt;
   a ldp:Container, ldp:DirectContainer;
   dcterms:title "A Linked Data Platform Container of Acme Resources";
   ldp:containerResource &lt;http://example.org/container1/&gt;;
   ldp:containsRelation ldp:member;
   ldp:insertedContentRelation ldp:MemberSubject;
   dcterms:publisher &lt;http://acme.com/&gt;.</pre>
   
	<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>
		
	</section><!-- ldpc-get_non-member_props -->

	<section id="ldpc-ordering"><h2 class="normal">Ordering</h2>
	<p>
		There are many cases where an ordering of the members of the
		container is important. LDPC does not provide any particular support
		for server ordering of members in containers, because any client can
		order the members in any way it chooses based on the value of any
		available property of the members. In the example below, the value of
		the <code>o:value</code> predicate is present for each
		member, so the client can easily order the members according to the
		value of that property. In this way, LDPC avoids the use of RDF
		constructs like Seq and List for expressing order.
	</p>
	<p>
		Order becomes more important for <a title="LDP server">LDP servers</a> when containers are
		paginated. If the server does not respect ordering when constructing
		pages, the client would be forced to retrieve all pages before
		sorting the members, which would defeat the purpose of pagination. 
		In cases where ordering is important, an LDPC server exposes all the
		members on a page with the proper sort order with relation to all 
		members on the next and previous pages.
		When the sort is ascending, all the members on a current page have a 
		sort order no lower than all members on the previous page and 
		sort order no higher than all the members on the next page; 
		that is, it proceeds from low to high, but keep in mind that several 
		consecutive pages might have members whose sort criteria are equal. 
		When the sort is descending, the opposite order is used. 
		Since more than one value may be used to sort members, 
		the LDPC specification allows servers to assert the ordered list
		of sort criteria used to sort the members, using the 
		<code>ldp:containerSortCriteria</code> relation.
		Each member of the ordered list exposes one <code>ldp:containerSortCriterion</code>, 
		consisting of a <code>ldp:containerSortOrder</code>, 
		<code>ldp:containerSortPredicate</code>, and 
		optionally a <code>ldp:containerSortCollation</code>.
	</p>
	<p>Here is an example container described
		previously, with representation for ordering of the assets:</p>
<pre class="example" id="ldpc-ex-ordering"># The following is the ordered representation of
#   http://example.org/netWorth/nw1/assetContainer/
<!-- @base is here only so it's easier to paste into validators for checking -->
# @base &lt;http://example.org/netWorth/nw1/assetContainer/&gt;
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.

&lt;&gt;
   a ldp:Container, ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:containerResource &lt;http://example.org/netWorth/nw1&gt;;
   ldp:containsRelation o:asset;
   ldp:insertedContentRelation ldp:MemberSubject.

&lt;?firstPage&gt;
   a ldp:Page;
   ldp:pageOf &lt;&gt;;
   ldp:containerSortCriteria (&lt;#SortValueAscending&gt;).

&lt;#SortValueAscending&gt;
   a ldp:ContainerSortCriterion;
   ldp:containerSortOrder ldp:Ascending;
   ldp:containerSortPredicate o:value.

&lt;http://example.org/netWorth/nw1&gt;
   a o:NetWorth;
   o:asset &lt;a1&gt;, &lt;a3&gt;, &lt;a2&gt;.

&lt;a1&gt;
   a o:Stock;
   o:value 100.00 .
&lt;a2&gt;
   a o:Cash;
   o:value 50.00 .
&lt;a3&gt;
   a o:RealEstateHolding;
   o:value 300000 .</pre>
		<p>
			As you can see by the addition of the <code>ldp:ContainerSortCriteria</code> 
			predicate, the <code>o:value</code> predicate is used
			to order the page members in ascending order.  It is up to the domain model
			and server to determine the appropriate predicate to indicate the
			resource’s order within a page, and up to the client receiving this 
			representation to use that order in whatever way is appropriate, for 
			example to sort the data prior to presentation on a user interface. Also
			as it is possible for a container to have as its members other containers,
			the ordering approach doesn't change as containers themselves are LDPRs and the
			properties from the domain model can be leveraged for the sort criteria.
		</p>
	</section><!-- Was 5.1.2 / #ldpc-ordering -->
</section>

<div class="ldp-issue-pending">
This section is current "under construction" while editors are trying to thoroughly complete edits for 
<a href="https://www.w3.org/2012/ldp/track/actions/120">ACTION-120</a>.
</div>


<section id="ldpc-general">
<h2>General</h2>
	<p>The Linked Data Platform does not define how clients
		discover <dfn><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>

	<section id="ldpc-isldpr"><h2 class="normal">Each Linked Data Platform Container MUST also be 
		a conforming <a title="">Linked Data Platform RDF Resource</a>.
	</h2></section><!-- Was 5.2.1 / #ldpc-5_2_1 -->
		
	<section id="ldpc-typecontainer"><h2 class="normal">The representation of a LDPC MUST have an <code>rdf:type</code>
		of only one of:
		<ul>
		<li><code>ldp:BasicContainer</code> for <a title="">Linked Data Platform Basic Container</a></li>
		<li><code>ldp:DirectContainer</code> for <a title="">Linked Data Platform Direct Container</a></li>
		<li><code>ldp:IndirectContainer</code> for <a title="">Linked Data Platform Indirect Container</a></li>
		</ul>
		Informative note: <a href="#ldp-rdfconcepts-extra-triples-types">LDPCs
		might have additional types</a>, like any RDF resource.
	</h2></section><!-- Was 5.2.7 / #ldpc-5_2_7 -->
	
	<!-- TODO: For LDP-BC, are the non-member props still needed or infered? -->
	
	<section id="ldpc-nordfcontainertypes"><h2 class="normal">LDPC representations SHOULD NOT use RDF container types <code>rdf:Bag</code>,
		<code>rdf:Seq</code> or <code>rdf:List</code>.
	</h2></section><!-- Was 5.2.8 / #ldpc-5_2_8 -->
	
	<section id="ldpc-mbrpred"><h2 class="normal"><a title="LDP server">LDP servers</a>
		SHOULD use the <code>ldp:member</code> predicate as an LDPC's <a title="Membership predicate">membership predicate</a>
		if there is no obvious predicate from an application vocabulary to use.
		The state of an LDPC includes information about which
		resources are its members, in the form of <a title="Membership triples">membership triples</a> that
		follow a consistent pattern.  The LDPC's state contains enough information for clients to discern
		the <a title="Membership predicate">membership predicate</a>, the other consistent membership
		value used in the container's membership triples (<var>membership-constant-URI</var>), 
		and the position (subject or object) where those URIs
		occurs in the <a title="Membership triples">membership triples</a>.
		Member resources can be
		any kind of resource identified by a URI, LDPR or otherwise.
	</h2></section><!-- Was 5.2.3 / #ldpc-5_2_3 -->
	
	<!-- TODO: Leaving this as-is, refining others as-needed.  Do we need an explicit clause for "ldp:contains"?
	I'm in favor of just leaving and adjust ldp:contains where we currently have ldp:created. -->
	
	<section id="ldpc-containres"><h2 class="normal">An LDPC representation MUST contain exactly one triple 
		whose subject is the LDPC URI, 
		whose predicate is the <code>ldp:containerResource</code>, 
		and whose object is the LDPC's membership-constant-URI.
		Commonly the LDPC's URI is the membership-constant-URI, but LDP does not require this except for <a title="Linked Data Platform Basic Container">LDP-BCs</a>.
	</h2>
		<section id="ldpc-containres-basic"><h2 class="normal">For <a title="Linked Data Platform Basic Container">LDP-BCs</a>, the triple MUST be
			where the subject is the LDPC URI,
			whose predicate is the <code>ldp:containerResource</code>, 
			and whose object is the LDPC URI itself.
		</h2></section>
	</section><!-- Was 5.2.4 / #ldpc-5_2_4 -->
	
	<section id="ldpc-containtriples"><h2 class="normal">An <a title="Linked Data Platform Direct Container">LDP Direct Container</a>
		and <a title="Linked Data Platform Indirect Container">LDP Indirect Container</a> representation MUST contain exactly one triple 
		whose subject is the LDPC URI, 
		and whose predicate is either <code>ldp:containsRelation</code> or <code>ldp:containedByRelation</code>. 
		The object of the triple is constrained by other sections, such as
		<a href="#ldpc-containtriple-relation" class="sectionRef">ldp:containsRelation</a> or 
		<a href="#ldpc-containtriple-byrelation" class="sectionRef">ldp:containedByRelation</a>, based on the 
		<a title="Membership triples">membership triple</a> 
		pattern used by the container.
	</h2><!-- Was 5.2.5 / #ldpc-5_2_5 -->
	
	<section id="ldpc-containtriple-relation"><h2 class="normal">LDPCs (<a title="Linked Data Platform Direct Container">Direct</a>
		and <a title="Linked Data Platform Indirect Container">Indirect</a> Containers only) 
		whose <a title="Membership triples">membership triple</a> 
		pattern is <var>( membership-constant-URI , membership-predicate , member-derived-URI )</var> MUST
		contain exactly one triple
		whose subject is the LDPC URI, 
		whose predicate is either <code>ldp:containsRelation</code>, 
		and whose object is the URI of <var>membership-predicate</var>.
	</h2></section><!-- Was 5.2.5.1 / #ldpc-5_2_5_1 -->
	
	<section id="ldpc-containtriple-byrelation"><h2 class="normal">LDPCs (<a title="Linked Data Platform Direct Container">Direct</a>
		and <a title="Linked Data Platform Indirect Container">Indirect</a> Containers only) 
		whose <a title="Membership triples">membership triple</a> 
		pattern is <var>( member-derived-URI , membership-predicate , membership-constant-URI )</var> MUST
		contain exactly one triple
		whose subject is the LDPC URI, 
		whose predicate is either <code>ldp:containedByRelation</code>, 
		and whose object is the URI of <var>membership-predicate</var>.
	</h2></section><!-- Was 5.2.5.2 / #ldpc-5_2_5_2 -->
	</section>

	<section id="ldpc-indirectmbr"><h2 class="normal">LDPCs (<a title="Linked Data Platform Direct Container">Direct</a>
		and <a title="Linked Data Platform Indirect Container">Indirect</a> Containers only) MUST contain one triple whose
	    subject is the LDPC URI, 
		whose predicate is <code>ldp:insertedContentRelation</code>, and 
		whose object <var>ICR</var> describes how the <var>member-derived-URI</var> in 
		the container's <a title="Membership triples">membership triples</a> is chosen.</h2>
		<ul>
		<li>
		For <a title="Linked Data Platform Direct Container">LDP Direct Containers</a>, the URI <code>ldp:MemberSubject</code> the
		<var>member-derived-URI</var> is simply the URI assigned by the server to a 
		document it creates; for example, if the client POSTs RDF content to a container
		that causes the container to create a new LDPR, <code>ldp:MemberSubject</code> says
		that the <var>member-derived-URI</var> is the URI assigned to the newly created LDPR.
		LDPCs MUST use the URI <code>ldp:MemberSubject</code> when the <var>member-derived-URI</var>
		is chosen in this way.
		</li>
		<li>
		For <a title="Linked Data Platform Direct Container">LDP Indirect Containers</a>, the <var>member-derived-URI</var> is taken from some triple 
		<var>( S, P, O )</var> in the document supplied by the client as input to the create request;
		if <var>ICR</var>'s value is <var>P</var>, then the <var>member-derived-URI</var> is
		<var>O</var>.  LDP does not define the behavior when more than one triple containing 
		the predicate <var>P</var> is present in the client's input.
		For example, if the client POSTs RDF content to a container
		that causes the container to create a new LDPR, and that content contains the triple 
		<var>( &lt;&gt; , foaf:primaryTopic , bob#me )</var>
		<code>foaf:primaryTopic</code> says
		that the <var>member-derived-URI</var> is <var>bob#me</var>.  
		</li>
		</ul>
	</section><!-- Was 5.2.10 / #ldpc-5_2_10 -->
	
	<section id="ldpc-linktypehdr"><h2 class="normal"><a title="LDP server">LDP servers</a>
		exposing LDPCs
		MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
		with a target URI of <code>http://www.w3.org/ns/ldp#Container</code>, and
		a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
		in all responses to requests made 
		to the LDPC's HTTP <code>Request-URI</code>. 
		<a title="LDP server">LDP servers</a> MAY provide additional HTTP <code>Link: rel='type'</code> headers
		to advertise their support for <a href="#ldpc-typecontainer">specific LDPC types</a>.
		The <a href="#ldpr-gen_linktypehdr">notes on the corresponding LDPR constraint</a> apply
		equally to LDPCs.
	</h2></section><!-- Was 5.2.11 / #ldpc-5_2_11 -->
	
</section>

<section id="ldpc-HTTP_GET">	
<h2>HTTP GET</h2>

	<section id="ldpc-get-mbrtriples"><h2 class="normal">The representation of a LDPC MUST contain a set of 
		<a title="Membership triples">membership triples</a> following one of the consistent 
		patterns from that definition.
		The membership-constant-URI of the triples MAY be the container itself
		or MAY be another resource (as in the <a href="#ldpc-ex-membership-subj">example</a>).  See also
		section on <a href="#ldpc-mbrpred">LDPC membership predicates</a>.
	</h2></section><!-- Was 5.3.1 / #ldpc-5_3_1 -->
	
	<section id="ldpc-sortcriteriaobj"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY 
		represent the members of a paged LDPC in a sequential
		order.  If the server does so, it MUST specify the order using a triple 
		whose subject is the page URI, 
		whose predicate is <code>ldp:containerSortCriteria</code>, 
		and whose object is a <code>rdf:List</code> of
		<code>ldp:containerSortCriterion</code> resources.  
		The resulting order MUST be as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause 
		[[!SPARQL-QUERY]].
		Sorting criteria MUST be the same for all pages of a representation; if
		the criteria were allowed to vary, the ordering among members of a container
		across pages would be undefined. 
		The first list entry provides the primary
		sorting criterion, any second entry provides a secondary criterion used to order members considered
		equal according to the primary criterion, and so on.
		<!-- Convert cases like this to a sectionRef -->
		See section <a href="#ldpc-ordering" class="sectionRef"></a> for
		an example.
	</h2></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
	
	<section id="ldpc-sortliteraltype"><h2 class="normal">LDPC page representations 
		ordered using <code>ldp:containerSortCriteria</code> MUST contain, 
		in every <code>ldp:containerSortCriterion</code> list entry, 
		a triple
		whose subject is the sort criterion identifier, 
		whose predicate is <code>ldp:containerSortPredicate</code> 
		and whose object is 
		the predicate whose value is used to order members between pages (the <dfn>page-ordering values</dfn>).
		The only literal data types whose behavior LDP constrains are those defined
		by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause [[!SPARQL-QUERY]].  Other data types
		can be used, but LDP
		assigns no meaning to them and interoperability will be limited.
	</h2></section><!-- Was 5.3.3 / #ldpc-5_3_3 -->
	
	<section id="ldpc-sortorder"><h2 class="normal">LDPC page representations 
		ordered using <code>ldp:containerSortCriteria</code> MUST contain, 
		in every <code>ldp:containerSortCriterion</code> list entry, 
		a triple
		whose subject is the sort criterion identifier, 
		whose predicate is <code>ldp:containerSortOrder</code> 
		and whose object describes the order used.
		LDP defines two values,
		<code>ldp:Ascending</code> and <code>ldp:Descending</code>, for use
		as the object of this triple.  Other values can be used, but LDP
		assigns no meaning to them and interoperability will be limited.
	 </h2></section><!-- Was 5.3.4 / #ldpc-5_3_4 -->
	
	<section id="ldpc-sortcollation"><h2 class="normal">LDPC page representations 
		ordered using <code>ldp:containerSortCriteria</code> MAY contain, 
		in any <code>ldp:containerSortCriterion</code> list entry,
		a triple
		whose subject is the sort criterion identifier, 
		whose predicate is <code>ldp:containerSortCollation</code> 
		and whose object identifies the collation used.
		LDP defines no values for use
		as the object of this triple.  While it is better for interoperability to use
		open standardized values, any value can be used.
		When the <code>ldp:containerSortCollation</code> triple is absent and the 
		<a title="page-ordering values">page-ordering values</a> are strings or simple literals [[!SPARQL-QUERY]], the
		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
		[[!SPARQL-QUERY]] using two-argument <code>fn:compare</code>, that is, 
		it behaves as if <code>http://www.w3.org/2005/xpath-functions/collation/codepoint</code> 
		was the specified collation.
		When the <code>ldp:containerSortCollation</code> triple is present and the 
		<a title="page-ordering values">page-ordering values</a> are strings or simple literals 
		[[!SPARQL-QUERY]], the
		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
		[[!SPARQL-QUERY]] using three-argument <code>fn:compare</code>, that is, the 
		specified collation.
		The <code>ldp:containerSortCollation</code> triple MUST be omitted for comparisons
		involving <a title="page-ordering values">page-ordering values</a> for which [[!SPARQL-QUERY]] does not use collations.
	</h2></section><!-- Was 5.3.5 / #ldpc-5_3_5 -->
</section>

<section id="ldpc-HTTP_POST">
<h2>HTTP POST</h2>
	<p>This specification imposes the following new requirements on HTTP <code>POST</code> for LDPCs 
		only when an LDPC supports that method.  This specification does not impose any
		new requirement to support that method, and [[!HTTP11]] makes it optional.
		Any server-imposed constraints on creation or update  
		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
	</p>
		
	<section id="ldpc-post-created201"><h2 class="normal">LDPC clients SHOULD create member resources by submitting a representation as
		the entity body of the HTTP <code>POST</code> to a known LDPC. If the resource was created successfully, <a title="LDP server">LDP servers</a> MUST
		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.
	</h2></section><!-- Was 5.4.1 / #ldpc-5_4_1 -->

	<section id="ldpc-post-createdmbr"><h2 class="normal">After a successful HTTP <code>POST</code> request to a LDPC, the new resource MUST
		appear as a member of the contained resource until the new resource is deleted or
		removed by other methods. An LDPC MAY also contain resources that were
		added through other means - for example through the user interface of
		the site that implements the LDPC.
	</h2></section><!-- Was 5.4.2 / #ldpc-5_4_2 -->
	
	<!-- TODO: "contained resource" is not the right term here, an example of where ldp:containedResource would be better
	labeled ldp:membershipResource (maybe)-->
	<!-- TODO: Do we need a rule for creation of ldp:contians here?  Steve's answer, no...leave to ldp:created rule. -->
	
	<section id="ldpc-post-createbins"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY accept an HTTP <code>POST</code> of non-RDF representations 
	<a title="Linked Data Platform Binary Resource">(LDP-BR)</a> for
		creation of any kind of resource, for example binary resources.  See <a href="#ldpc-post-acceptposthdr">AcceptPost section</a> for 
		details on how clients can discover whether a LDPC supports this behavior.
	</h2></section><!-- Was 5.4.3 / #ldpc-5_4_3 -->
	
	<section id="ldpc-post-createrdf"><h2 class="normal"><a title="LDP server">LDP servers</a> that successfully create a resource from a
		RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource
		MUST be an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[rdf11-concepts]].
		If any model cannot be honored, the server MUST fail the request.
	</h2><!-- Was 5.4.4 / #ldpc-5_4_4 -->
	<ul>
	<li>If the request header <a href="#ldpr-gen-linktypehdr">specifies an LDPR interaction model</a>, then the server MUST create an LDPR.</li>
	<li>If the request header <a href="#ldpc-linktypehdr">specifies an LDPC interaction model</a>, then the server MUST create an LDPC.
	</li>
	<li>This specification does not constrain the server's behavior in other cases.</li>
	<p>Note: A consequence of this is that LDPCs can be used to create LDPCs, if the server supports doing so.</p>
	</ul>
	</section>
	
	<section id="ldpc-post-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST accept a request entity body with a request header
	    of <code>Content-Type</code> with value of <code>text/turtle</code> [[!TURTLE]].
	</h2></section><!-- Was 5.4.5 / #ldpc-5_4_5 -->
	
	<section id="ldpc-post-contenttype"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD use the <code>Content-Type</code> request header 
		to determine the representation format when the request has an entity body. 
	</h2></section><!-- Was 5.4.6 / #ldpc-5_4_6 -->
	
	<section id="ldpc-post-rdfnullrel"><h2 class="normal">In RDF representations, <a title="LDP server">LDP servers</a> MUST interpret the null relative
		URI for the subject of triples in the LDPR 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” LDPR, so
		triples whose subject is the null relative URI will usually result in
		triples in the created resource whose subject is the created
		resource.  
	</h2></section><!-- Was 5.4.7 / #ldpc-5_4_7 -->	
	
	<section id="ldpc-post-serverassignuri"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD assign the URI for the resource to be
		created using server application specific rules in the absence of a <a href="#ldpc-post-slug">client hint</a>.
	</h2></section><!-- Was 5.4.8 / #ldpc-5_4_8 -->
	
	<section id="ldpc-post-mincontraints"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to create new resources without
		requiring detailed knowledge of application-specific constraints.
		This is a consequence of the requirement to enable simple creation and modification of LDPRs.
		<!-- TODO: Consider reference to 4.2.13 to include Link rel='desribedBy' header for such constraints.  
		           Also, should this call out LDPRs explicity?  Would think we could just have "resources" statement. -->
	</h2></section><!-- Was 5.4.9 / #ldpc-5_4_9 -->
	
	<section id="ldpc-post-slug"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY allow clients to suggest the URI for a resource
		created through <code>POST</code>, using the HTTP <code>Slug</code> header as defined in [[!RFC5023]].  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.
	</h2></section><!-- Was 5.4.10 / #ldpc-5_4_10 -->
	
	<section id="ldpc-post-dontreuseuris"><h2 class="normal"><a title="LDP server">LDP servers</a> that allow member creation via <code>POST</code> 
		SHOULD NOT re-use URIs.
	</h2></section><!-- Was 5.4.11 / #ldpc-5_4_11 -->
	
	<section id="ldpc-post-createbinlinkmetahdr"><h2 class="normal">Upon successful creation of a non-RDF 
	<a title="Linked Data Platform Binary Resource">(LDP-BR)</a> and therefore non-LDPR member (HTTP status code of 
	201-Created and URI indicated by <code>Location</code> response header), <a title="LDP server">LDP servers</a> MAY create an associated 
	<a title="Linked Data Platform RDF Resource">LDP-RR</a>
	to contain data about the created resource.  If an LDPC server creates this associated <a title="Linked Data Platform RDF Resource">LDP-RR</a> it MUST 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 [[!RFC5988]].
	</h2></section><!-- Was 5.4.12 / #ldpc-5_4_12 -->
	
	<section id="ldpc-post-acceptposthdr"><h2 class="normal"><a title="LDP server">LDP servers</a> that support <code>POST</code> MUST
		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.
	</h2></section><!-- Was 5.4.13 / #ldpc-5_4_13 -->
		
	<section id="ldpc-post-ldpcreated"><h2 class="normal">LDPCs that create new member resources MAY 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 LDPC that tracks members created through the LDPC MUST add a triple to the container
		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 MAY add other triples as well.
	</h2></section><!-- Was 5.4.14 / #ldpc-5_4_14 -->

	<section id="ldpc-post-indirectmbrrel"><h2 class="normal">LDPCs 
		whose <code>ldp:insertedContentRelation</code> triple has an object
		<strong>other than</strong> <code>ldp:MemberSubject</code> 
		and that create new resources 
		MUST add a triple to the container
		whose subject is the container's URI, 
		whose predicate is <code>ldp:created</code>, and
		whose object is the newly created resource's URI (which will be different from
		the <var><a href="#ldpc-indirectmbr">member-derived URI</a></var> in this case).
		This <code>ldp:created</code> triple can be the only link from the container to the newly created
		resource in certain cases.
	</h2></section><!-- Was 5.4.15 / #ldpc-5_4_15 -->
	
</section>

<section id="ldpc-HTTP_PUT">
<h2>HTTP PUT</h2>
	<p>This specification imposes the following new requirements on HTTP <code>PUT</code> for LDPCs 
		only when an LDPC supports that method.  This specification does not impose any
		new requirement to support that method, and [[!HTTP11]] makes it optional.
		Any server-imposed constraints on creation or update  
		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
	</p>
		
	<section id="ldpc-put-mbrprops"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> to update a LDPC’s <a>membership triples</a>; 
		if the server receives such a request, it SHOULD respond with a 409
		(Conflict) status code.
	</h2></section><!-- Was 5.5.1 / #ldpc-5_5_1 -->
	
	<section id="ldpc-put-nonmbrprops"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY allow updating LDPC non-membership properties using
		HTTP <code>PUT</code> on a corresponding <a>non-member resource</a>, which
		MAY exclude server-managed properties such as <code>ldp:containerResource</code>, <code>ldp:containsRelation</code>
		and <code>ldp:containedByRelation</code>.
		The <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></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. 
	</h2></section><!-- Was 5.5.2 / #ldpc-5_5_2 -->
	    
	<section id="ldpc-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> that allow member creation via <code>PUT</code> 
		SHOULD NOT re-use URIs.  For RDF representations (LDP-RRs),the created resource
		MUST be an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[rdf11-concepts]].
	</h2></section><!-- Was 5.5.4 / #ldpc-5_5_4 -->
	
</section>

<section id="ldpc-HTTP_DELETE">
<h2>HTTP DELETE</h2>
	<p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for LDPRs and LDPCs
		only when a LDPC supports that method.  This specification does not impose any
		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
		
	<section id="ldpc-del-contremovesmbrtriple"><h2 class="normal">When a LDPC member resource originally created by the LDPC (for example, one whose representation
	    was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server is aware of the member's deletion
		(for example, the member is managed by the same server), the LDPC server MUST also remove it from
		the LDPC by removing the corresponding membership triple.
	</h2></section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
	
	<section id="ldpc-del-mbrremovesmbrtriple"><h2 class="normal">When a <a>LDP server</a> successfully completes a <code>DELETE</code> request 
		on a LDPC member resource, it MUST remove any
		membership triples associated with the deleted member resource identified by the <code>Request-URI</code>.
	</h2>
	<blockquote>
		Informative note: The <a>LDP server</a> might perform additional removal 
		of member resources, as described in the <a href="#ldp-http-method-side-effects">normative references</a> like [[HTTP11]]. 
		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.
	</blockquote>
	</section><!-- Was 5.6.2 / #ldpc-5_6_2 -->
	
	<section id="ldpc-del-ldpcreated"><h2 class="normal">When the conditions in <a href="#ldpc-del-contremovesmbrtriple">previous section</a> hold, and the LDPC tracks member 
		resources that it created using the <code>ldp:created</code> predicate, the LDPC server MUST also remove 
		the deleted member's <code>ldp:created</code> triple.
	</h2></section><!-- Was 5.6.3 / #ldpc-5_6_3 -->
	
	<section id="ldpc-del-contremovesmbrres"><h2 class="normal">When a LDPC member resource originally created by the LDPC (for example, one whose 
	representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server 
	created an associated LDPR (see <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>), the LDPC server MUST also remove the associated LDPR it created.
	</h2></section><!-- Was 5.6.4 / #ldpc-5_6_4 -->
	
</section>

<section id="ldpc-HTTP_HEAD">
<h2>HTTP HEAD</h2>
	<p>Note that certain LDP mechanisms, such as <a href="#ldpr-Paging">paging</a>, 
		rely on HTTP headers, and HTTP generally requires that
		<code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also <a title="LDP server">LDP servers</a> must also include HTTP headers
		on response to <code>OPTIONS</code>, see <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
		Thus, implementers supporting <code>HEAD</code> should also carefully read the
		<a href="#ldpc-HTTP_GET" class="sectionRef"></a> and <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a>.</p>
</section>

<section id="ldpc-HTTP_PATCH">
<h2>HTTP PATCH</h2>
	<p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for LDPCs 
		only when a LDPC supports that method.  This specification does not impose any
		new requirement to support that method, and [[!HTTP11]] makes it optional.
		Any server-imposed constraints on LDPR creation or update  
		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
	</p>
		
	<section id="ldpc-patch-req"><h2 class="normal"><a title="LDP server">LDP servers</a> are RECOMMENDED to support HTTP <code>PATCH</code> as the preferred
		method for updating LDPC non-membership properties.
	</h2></section><!-- Was 5.8.1 / #ldpc-5_8_1 -->
</section>

<section id="ldpc-HTTP_OPTIONS">
<h2>HTTP OPTIONS</h2>
	<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPCs.
		</p>

	<section id="ldpc-options-nonmbrprops"><h2 class="normal">
		<a title="LDP server">LDP servers</a> SHOULD define a corresponding
		<a>non-member resource</a>
		to support requests for information about a LDPC
		without retrieving a full representation including all of its members; 
		see section <a href="#ldpc-get_non-member_props" class="secitonRef"></a> for
		examples.</h2> 
		In responses to <code>OPTIONS</code> requests with an LDPC as the <code>Request-URI</code>, 
		<a title="LDP server">LDP servers</a> that define a non-member resource SHOULD provide an HTTP <code>Link</code>
		header whose target URI is the <a>non-member resource</a>, and whose link relation type is 
		<code>http://www.w3.org/ns/ldp#nonMemberResource</code> [[!RFC5988]]. 
		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 clients will assume that the LDPC does not have a corresponding
		non-member resource.
		For example, if there is a LDPC 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>
	</section><!-- Was 5.9.1 / #ldpc-5_9_1 -->
	
	<section id="ldpc-options-linkmetahdr"><h2 class="normal">When a LDPC creates a <a title="Linked Data Platform Binary Resource">LDP-BR</a> member (for example, one whose 
	representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) it might create an associated <a title="Linked Data Platform RDF Resource">LDP-RR</a> to contain data about the 
	non-LDPR (see <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>).  For LDP-BRs that have this associated LDP-RR, an LDPC server MUST provide an HTTP <code>Link</code>
	header whose target URI is the associated LDP-RR, and whose link relation type is 
	<code>meta</code> [[!RFC5988]].
	
	<!-- TODO: Consider some improvement to this:
	
	Does a LDPC create a non-LDPR? or does and LDPC server do this?
	What is "it" in the first sentence?
	Adding a Request-URI clause to the last sentence may help clarify a couple things.
	 -->
	
	</h2></section><!-- Was 5.9.2 / #ldpc-5_9_2 -->
</section> <!-- h2 -->

</section> <!-- h1 LDPC -->


<section id="base-specs" class="informative">
<h1>Notable information from normative references</h1>
<p>
While readers, and especially implementers, of LDP are assumed to understand the information in its normative 
references, the working group has found that certain points are particularly important to understand.
For those thoroughly familiar with the referenced specifications, these points might seem obvious, yet
experience has shown that few non-experts find all of them obvious.  This section enumerates these topics; 
it is simply re-stating (informatively) information locatable via the normative references.
</p>

<section id="specs-webarch" class="informative">
<h2>Architecture of the World Wide Web</h2>
Reference: [[!WEBARCH]]

	<section id="ldp-webarch-nonexcl-membership" ><h2 class="normal">LDPC membership is not exclusive; this means that the same resource
	(LDPR or not) can be a member of more than one LDPC.
	</h2></section>
	
	<section id="ldp-webarch-uri-reuse"><h2 class="normal"><a title="LDP server">LDP servers</a> should not 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 LDPC server might delete a resource and then later re-use the
		URI when it identifies the same resource, but only when consistent with Web architecture.
		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.
	</h2></section>

</section> 

<section id="specs-http" class="informative">
<h2>HTTP 1.1</h2>
Reference: [[!HTTP11]]

	<section id="ldp-http-other-representations"><h2 class="normal"><a title="LDP server">LDP servers</a> can support representations beyond those
		necessary to conform to this specification. These
		could be other RDF formats, like N3 or NTriples, but non-RDF formats
		like HTML [[HTML401]] and JSON [[RFC4627]] would likely be common.  
		HTTP content negotiation ([[HTTP11]] Section 12 - Content Negotiation) is used to select the format.
	</h2></section>
	
	<section id="ldp-http-other-methods"><h2 class="normal">LDPRs can be created, updated and deleted using methods not defined in
		this document, for example through application-specific means, SPARQL
		UPDATE, etc. [[SPARQL-UPDATE]], as long as those methods do not conflict with this specification's 
		normative requirements.
	</h2></section>	
	
	<section id="ldp-http-delete-uri-reuse"><h2 class="normal"><a title="LDP server">LDP servers</a> 
		remove the resource identified by the <code>Request-URI</code> in response to a successful HTTP <code>DELETE</code> request.
		After such a request, a subsequent HTTP <code>GET</code> on the same
		<code>Request-URI</code> usually results in a 404 (Not found) or 410 (Gone) status
		code, although HTTP allows others.
	</h2></section>	
	
	<section id="ldp-http-method-side-effects"><h2 class="normal"><a title="LDP server">LDP servers</a> can alter the state of other resources 
		as a result of any HTTP request, especially when non-safe methods are used ([[HTTP11]] section 9.1). 
		For example, it is acceptable for the server to
		remove triples from other resources whose subject or object is the
		deleted resource as the result of a successful HTTP <code>DELETE</code> request. 
		It is also acceptable and common for <a title="LDP server">LDP servers</a> to
		not do this – the server's behavior can vary, so LDP clients cannot depend on it.
	</h2></section>
	
	<section id="ldp-http-patch-allowed"><h2 class="normal"><a title="LDP server">LDP servers</a> can implement HTTP <code>PATCH</code> 
		to allow modifications,
		especially partial replacement, of their resources. No
		minimal set of patch document formats is mandated by this document or by the definition of <code>PATCH</code> [[RFC5789]].
	</h2></section>
	
	<section id="ldp-http-content-sniffing"><h2 class="normal"> 
		When the <code>Content-Type</code> request header is absent from a request, 
		<a title="LDP server">LDP servers</a> might infer the content type by inspecting the entity body contents [[HTTP11]].
	</h2></section>

</section> 

<section id="specs-rdf" class="informative">
<h2>RDF</h2>
Reference: [[RDF-CONCEPTS]]

	<section id="ldp-rdfconcepts-extra-triples-any"><h2 class="normal">The state of an LDPR 
		can have triples with any subject(s).  The URL used to retrieve the
		representation of an LDPR need not be the subject of any of its triples.
	</h2></section>
	
	<section id="ldp-rdfconcepts-extra-triples-members"><h2 class="normal">The representation of an LDPC
		can 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 RDF
		representations). This allows a <a>LDP server</a> to provide clients with
		information about the members without the client having to do a <code>GET</code>
		on each member individually.  See <a href="#ldpc-member_data">Container
		Member Information</a> for additional details.
	</h2></section>
	
	<section id="ldp-rdfconcepts-extra-triples-types"><h2 class="normal">The state of an LDPR can have more than one
		triple with a <code>rdf:type</code> predicate.
	</h2></section>

</section> 

<section id="specs-paging" class="informative">
<h2>Feed paging and archiving</h2>
Reference: [[RFC5005]]

	<section id="ldp-paging-incomplete"><h2 class="normal">A <a title="LDP client">LDP client</a>  
		SHOULD NOT present <a title="paged resource">paged resources</a> as coherent or
		complete, or make assumptions to that effect.
		[[RFC5005]].
	</h2></section>

</section> 

</section> <!-- Base specs -->

<section>
<h1>HTTP Header Definitions</h1>
     
<section id="header-accept-post">
<h2>The Accept-Post Response Header</h2>

	<div class="atrisk"><p class="atrisktext">Feature At Risk</p>
		<p>The LDP Working Group proposes incorporation of the features described in this section.</p>
		<ul>
		<li>The addition of <code>Accept-Post</code> in this specification is pending 
		advancement of an <a href="https://datatracker.ietf.org/doc/draft-wilde-accept-post/">IETF draft</a>
		that would fully include it, based on the Accept-Patch header's design from [[!RFC5789]].  Once LDP is in
		Candidate Recommendation, the LDP WG will make an assessment based on the status at IETF
		working with the W3C 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 modelled after the <code>Accept-Patch</code> header defined in [[!RFC5789]].
	</p>
   
	<section id="header-accept-post-1"><h2 class="normal">The syntax for <code>Accept-Post</code>, using
		the ABNF syntax defined in Section 2.1 of [[!HTTP11]], is:</h2>
		<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 [[!HTTP11]], Section 3.7.
		</p>
		</blockquote>
	</section><!-- Was 6.1.1 / #header-accept-post-1 -->

	<section id="header-accept-post-2"><h2 class="normal">
		The <code>Accept-Post</code> HTTP header SHOULD 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>.
	</h2></section><!-- Was 6.1.2 / #header-accept-post-2 -->
	
	<section id="header-accept-post-iana"><h2 class="normal">IANA Registration Template</h2>
	<div>
	<blockquote>
	<p>
	The Accept-Post response header must be added to the permanent registry (see [[!RFC3864]]).
	</p>
	<p>
	Header field name:  Accept-Post
	</p>
	<p>
	Applicable Protocol:  HTTP
	</p>
	<p>
	Author/Change controller:  W3C
	</p>
	<p>
	Specification document:  this specification
	</p>
	</blockquote>
	</div>
	</section><!-- Was 6.1.3 / #header-accept-post-iana -->

</section>
</section> <!-- Header defns -->
    
<!-- Removed for action-113
<section>
<h1>HTTP Status Code Definitions</h1>
     
<section id="status-code-related-content">
<h2>209 Related Content</h2>

	<div class="atrisk"><p class="atrisktext">Feature At Risk</p>
		<p>The LDP Working Group proposes incorporation of the features described in this section.</p>
		<ul>
		<li>The addition of <a>209 Related Content</a> in this specification is pending 
		advancement of an <a href="https://datatracker.ietf.org/doc/draft-wilde-related-content/">IETF draft</a>
		that would fully include it, patterned after the codes defined by [[RFC6585]].  Once LDP is in
		Candidate Recommendation status, the LDP WG will make an assessment based on the status at IETF
		working with the W3C Director.</li>
		</ul>
	</div>
		
	<p>The <code>209 Related Content</code> status code indicates that the origin server 
		is supplying the representation of a different resource than the target resource,
		and the origin server believes that the supplied representation 
		is likely to satisfy the user agent's original request.
		The resource whose representation is supplied is descriptive of the target resource, in
		the same way that the <code>Location</code> header in a <code>303 See Other</code>
		response is descriptive of the target resource.
	</p>
	<p><code>209 Related Content</code> is intended to be used in situations where 
		<code>303 See Other</code> could have been used and would most likely result in a
		user agent retrieving the other resource, but saves the user agent from
		the latency penalty of having to perform a separate retrieval request.
	</p>
   
	<p>	LDP uses <code>209 Related Content</code> to provide clients with the 
		<a href="#ldpr-Paging">first page of a large resource</a>, but it can also be used in
		other common situations.  Linked Data clients could benefit by avoiding the latency
		of additional requests when the target resource is a concept resource (one without any
		representation capable of transmission over HTTP), and general HTTP clients would
		benefit in many of the more general cases where <code>303 See Other</code> responses
		are currently used.
	</p>
   
	<div id="status-code-related-content-1" class="rule">7.1.1 A <code>209</code> response to a
		<code>GET</code> request MUST contain a <code>Location</code> header with the same
		<code>Location</code> field value as a <code>303 See Other</code> response would use [[!HTTP11]].
	</div>

	<div id="status-code-related-content-2" class="rule">7.1.2 A <code>209</code> response to a
		<code>GET</code> request MUST contain a representation of the resource identified
		by the response's <code>Location</code> header.
	</div>

	<div id="status-code-related-content-iana" class="rule">7.1.3 IANA Considerations</div>
	<div>
	<blockquote>
	<p>
	The <code>209 Related Content</code> must be added to the permanent status code registry 
	maintained at <a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>
	(see [[HTTPBIS-SEMANTICS]], [[!RFC2817]]).
	</p>
	<p>
	Value:  209
	</p>
	<p>
	Description:  Related Content
	</p>
	<p>
	Reference:  this specification
	</p>
	</blockquote>
	</div>

</section>
</section> <!-- status code defns -->


<section class='informative' id='security'>
<h1>Security Considerations</h1>
As with any protocol that is implemented leveraging HTTP, implementations should take advantage of the many 
security-related facilities associated with it and are not required to carry out LDP operations 
that may be in contradistinction to a particular security policy in place. For example, when faced with an 
unauthenticated request to replace system critical RDF statements in a graph through the PUT method, applications may
consider responding with the 401 status code (Unauthorized), indicating that the appropriate authorization 
is required. In cases where authentication is provided fails to meet the requirements of a particular access control 
policy, the 403 status code (Forbidden) can be sent back to the client to indicate this failure to meet the
access control policy.
</section>


<section class='appendix informative'>
<h2>Acknowledgements</h2>
     
  <p>The following people have been instrumental in providing thoughts, feedback,
reviews, content, criticism and input in the creation of this specification:</p>

  <p style="margin-left: 3em;">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-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130730/">Last Call Draft</a></em></blockquote> -->
<ul>
	<li>2014-02-04 - ACTION-124 LDPR-RR as named graphs  (SS)</li>
	<li>2014-02-04 - ACTION-120 (complete) Updated LDPC general, GET and POST sections (SS)</li>
	<li>2014-02-04 - ACTION-120 (Part 3) Added ldp:member (SS)</li>
	<li>2014-02-04 - ACTION-120 (Part 2) Added concepts of containers (basic, direct and indirect) to LDPC intro (SS)</li>
	<li>2014-01-30 - ACTION-120 (Part 1) Added concepts of containers (basic, direct and indirect) (SS)</li>
	<li>2014-01-30 - ACTION-123 Added concepts of LDP-RDF-Resource and LDP-Binary-Resource (SS)</li>
	<li>2014-01-29 - Fix up conformance section to use new LDP client section (SS)</li>
	<li>2014-01-21 - Updated reference to LDP BP&amp;G editor's draft and added ref to LDP-UCR (SS)</li>
	<li>2014-01-21 - Removed redudant reqs that have been moved to <a href="#ldpclient"></a> (SS)</li>
	<li>2014-01-21 - Fixed formating with &gt;h2 formatting (SS)</li>
	<li>2014-01-21 - Put reference to <a href="#base-specs">base-specs</a> into intro section (SS)</li>
	<li>2014-01-17 - First attempt at correcting section ordering and anchors (SS)</li>
	<li>2014-01-02 - ACTION-122 Updated 4.2.10, 5.4.4, example 8 + added 5.2.11 requiring rel=type for interaction model (JA)</li>
	<li>2014-01-02 - ACTION-119 Added 5.4.15 requiring ldp:created for indirect containers (JA)</li>
	<li>2013-11-27 - ACTION-101 Added informative <a href="#security">security</a> section (SS)</li>
	<li>2013-11-27 - ACTION-100 Added informative note to Ordering section that containers can be nested (SS)</li>
	<li>2013-11-18 - Various editorial and validation fixes (SS)</li>
    <li>2013-11-12 - Clean up some remnants of inlining (JA)</li>
    <li>2013-11-12 - Clean up some overly specific language (implications that POST is the only way to create members, etc) (JA)</li>
    <li>2013-11-12 - Resolve ACTION-112 Update spec to reflect 10/28 resolution for Issue-81 part 1: new predicate names (JA)</li>
    <li>2013-11-12 - Fix respec messages that only show up on remote server, hit paging examples to remove appearance of inlining (JA)</li>
    <li>2013-11-11 - Resolve ACTION-113 Update spec to reflect 11/04 resolution to remove 303 and have client use first/next links to detect paging (JA)</li>
    <li>2013-10-25 - Resolve ACTION-105 Update spec to reflect 9/30 resolution moving Paging links to HTTP headers (JA)</li>
    <li>2013-10-25 - Resolve ACTION-110 Update spec to reflect 10/21 resolution for normative changes to align vanilla/chocolate (JA)</li>
    <li>2013-10-22 - Resolve ACTION-109 Update spec to reflect 10/21 resolution for ignoring triples on PUT (JA)</li>
    <li>2013-10-22 - Resolve ACTION-107 Update spec to reflect 10/07 resolution on 5.6.2 LDPC deletion (JA)</li>
    <li>2013-10-22 - Resolve ACTION-102 Make 4.6.2 informative, clarify that it re-states what http allows, and in fact it applies to all methods not just delete. (JA)</li>
    <li>2013-10-22 - Resolve ACTION-103 Change SHOULD to MUST in 4.10.2.3 "LDPR servers that initiate paging SHOULD respond to request ..." (JA)</li>
    <li>2013-10-22 - Resolve ACTION-108 move restatements of HTTP et al. out of normative sections (JA)</li>
    <li>2013-10-22 - Resolve ACTION-106 5.3.5 MUST -&gt; SHOULD (JA)</li>
    <li>2013-10-21 - Mock up status code 209 Related Content (JA)</li>
    <li>2013-10-01 - Mock up new section for rules declared to be non-normative restatements of info from other specs (JA)</li>
    <li>2013-10-01 - Revising terminology - membership triples and friends (JA)</li>
    <li>2013-10-01 - Revising introduction (JA)</li>
    <li>2013-10-01 - Conformance section drafting + mock up "LDP Clients" section as part of that (JA)</li>
    <li>2013-09-23 - Remove client/server-initiated paging terms (JA)</li>
    <li>2013-09-17 - Change must to MUST in <a href="#ldpc-5_6_4">5.6.4</a> (SS)</li>
	<li>2013-09-17 - Removed "at-risk" inlining feature from spec, <a href="https://www.w3.org/2012/ldp/track/actions/98">ACTION-98</a> (SS)</li>
	<li>2013-09-17 - Fixed vanishing section ref problem (SS)</li>
	<li>2013-08-19 - Basic preparation for edits unto LC draft (SS)</li>
</ul>

<blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130730/">Last Call 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-&gt;4.10.2.4.3,4.10.2.6-&gt;4.10.2.4.1,4.10.2.7-&gt;4.10.2.4.2 and added samples (SS)</li>
	<li>2013-07-24 - Changed ldp:ascending-&gt;ldp:Ascending, ldp:descending-&gt;ldp:Descending, ldp:non-member-resource -&gt;ldp:nonMemberResource (SS)</li>
	<li>2013-07-24 - Added term &quot;Page resource&quot; (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-&gt;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:insertedContentRelation into examples (SS)</li>
	<li>2013-07-15 - ISSUE-79 ldp:contains =&gt; 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:insertedContentRelation (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:containedByRelation 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 &amp; 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 &amp; 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>
    
  </body>
</html>