ldp.html
author sspeiche
Tue, 23 Jul 2013 10:13:09 -0400
changeset 221 bce45a75f980
parent 220 ff8b1635f35a
child 222 1db581afd1ec
permissions -rw-r--r--
Changed section 6.1 to at risk as possibly moving to IETF
<!DOCTYPE html>
<!-- 
 Editor TODO:
   - The word "canonical" is used twice in the document. Since we do not deal with URI 
     canonicalization in the specification, I would remove the word and the meaning of 
     the sentences is the same.
   - section 4.6...respec is adding extra spaces to the sectionRefs
	  carefully read section 4.2 .
	  ->
	  carefully read section 4.2.
	
	  defined in section 4.8 .
	  ->
	  defined in section 4.8.
 Various pre-LC comments:
    - John A's comments http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0054.html
                        http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0056.html
    - Ted T's comments http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0062.html
    - Raul's comments http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0069.html
      (handled most of Raul's comments)
    - P-A's comments http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0071.html
    - Sergio's comments http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0072.html
 -->
<html>
  <head>
    <title>Linked Data Platform 1.0</title>
    <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
    <!-- 
      === NOTA BENE ===
      For the three scripts below, if your spec resides on dev.w3 you can check them
      out in the same tree and use relative links so that they'll work offline,
     -->
    <script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script> 
    <script class='remove'>
      var respecConfig = {
          // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
          specStatus:           "ED",
          
          // the specification's short name, as in http://www.w3.org/TR/short-name/
          shortName:            "ldp",

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

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

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

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

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

          // if this is a LCWD, uncomment and set the end of its review period
          // lcEnd: "2009-08-05",

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

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

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

          //authors:  [
          //    { name: "Your Name", url: "http://example.org/",
          //      company: "Your Company", companyURL: "http://example.com/" },
          //],
          
          // name of the WG
          wg:           "Linked Data Platform Working Group",
          
          // URI of the public WG page
          wgURI:        "http://www.w3.org/2012/ldp",
          
          // name (without the @w3c.org) of the public mailing to which comments are due
          wgPublicList: "public-ldp-wg",
          
          // URI of the patent status for this WG, for Rec-track documents
          // !!!! IMPORTANT !!!!
          // This is important for Rec-track documents, do not copy a patent URI from a random
          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
          // Team Contact.
          wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/55082/status",
          doRDFa: "1.1",
      };
    </script>
    <style type="text/css">
    	div.rule {padding-top: 1em;}
    	div.ldp-issue-open {
	    	border-color: #E05252;
			background: #FBE9E9;
			padding: 0.5em;
			margin: 1em 0;
			position: relative;
			clear: both;
			border-left-width: .5em;
			border-left-style: solid;
    	}
    	div.ldp-issue-pending {
	    	border-color: #FAF602;
			background: #F7F6BC;
			padding: 0.5em;
			margin: 1em 0;
			position: relative;
			clear: both;
			border-left-width: .5em;
			border-left-style: solid;
    	}
    	div.ldp-issue-closed {
	    	border-color: #009900;
			background: #BCF7CF;
			padding: 0.5em;
			margin: 1em 0;
			position: relative;
			clear: both;
			border-left-width: .5em;
			border-left-style: solid;
    	}
    	div.ldp-issue-title {
    	    color: #E05252;
    	    padding-right: 1em;
            min-width: 7.5em;
    	}
		.atrisk {
			padding:    1em;
			margin: 1em 0em 0em;
			border: 1px solid #f00;
			background: #ffc;
		}
		.atrisktext {
			/* content:    "Feature At Risk"; */
			display:    block;
			width:  150px;
			margin: -1.5em 0 0.5em 0;
			font-weight:    bold;
			border: 1px solid #f00;
			background: #fff;
			padding:    3px 1em;
		}

    </style>
    <style type="text/css" media="all">
    	code {
    	    font-weight:bold;
			font-size:larger;
    	}
		 /* ReSpec uses color ff4500 for code elements, which does not print well on some black & white printers
		    and is a little hard to read for some folks even on-line. 
			The default code font size was also somewhat too small/hard to read.
		*/
    </style>
  </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>
<h1 id="intro">Introduction</h1>
	<p>This document 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 four rules of Linked Data [[LINKED-DATA]]:</p>
	<p>1. Use URIs as names for things</p>
	<p>2. Use HTTP URIs so that people can look up those
		names</p>
	<p>3. When someone looks up a URI, provide useful
		information, using the standards (RDF*, <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr>)</p>
	<p>4. Include links to other URIs, so that they can
		discover more things</p>
	<p>This specification discusses standard HTTP and RDF techniques and best practices that you 
	should use, and anti-patterns you should avoid, when constructing clients and servers that 
	read and write Linked Data resources.</p> 
	<p>A special type of <a title="Linked Data Platform Resource">Linked Data Platform Resource</a> is a 
	<a title="Linked Data Platform Container">Container</a>.  Containers are very useful 
	in building application models.  For example, universities offer a collection of classes 
	and have a collection of faculty members, each faculty member teaches a collection of courses, etc.  
	This specification discusses how to work with containers.  Resources can be added to containers in 
	several ways. As a special case, members can both be created and added to a container by overloading 
	the POST operation (see <a href="#ldpc-HTTP_POST" class="sectionRef"></a>).</p>
	<p>Another contribution of this specification is how to deal with large amounts of data.  
	Depending on the server’s capabilities, a GET request on a Linked Data Platform Resource 
	returns a set of pages and uses a convention to access any subsequent page (see <a href="#ldpr-Paging" class="sectionRef"></a>). </p>
	<p>The intention of this document is to enable additional rules and layered groupings of rules as 
	additional specifications.  The scope is intentionally narrow to provide a set of key rules for 
	reading and writing Linked Data that most, if not all, other specifications will depend upon and 
	implementations will support.</p>
</section>
	
<section>
<h1 id="terms">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><dfn>Linked Data Platform Resource</dfn> (<dfn><abbr title="Linked Data Platform Resource">LDPR</abbr></dfn>)</dt>
	<dd>HTTP resource whose state is represented in RDF that conforms to the simple lifecycle
		patterns and conventions in <a href="#ldpr" class="sectionRef"></a>.<p></p></dd>
		
	<dt><dfn>Linked Data Platform Container</dfn> (<dfn><abbr title="Linked Data Platform Container">LDPC</abbr></dfn>)</dt>
	<dd>An LDPR representing a collection of same-subject, same-predicate triples which is uniquely identified by a URI
	that responds to client requests for creation, modification, and enumeration of its members.
	<p></p></dd>
		
	<dt>Client</dt>
	<dd>A program that establishes connections for the purpose of sending requests [[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>Membership triples</dfn></dt>
	<dd>A set of triples in an LDPC's state that lists its members.
		The membership triples of a container all have the same
		subject and predicate, and the objects of the membership triples define
		the container's members. 
	<p></p></dd>
	
	<dt><dfn>Membership subject</dfn></dt>
	<dd>The subject of all a LDPC's <a title="Membership triples">membership triples</a>.
	<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 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>Resource inlining</dfn></dt>
	<dd>
		The practice of responding to a HTTP GET request made to a request URI <var>R<sub>0</sub></var> with
		a representation that includes the state of <var>R<sub>0</sub></var>, the <em>entire</em> state of resources accessed through
		<em>other</em> request URI(s) <var>R<sub>1</sub></var>...<var>R<sub>n</sub></var>, <em>and assertions</em> from the server 
		identifying the additional resources whose
		entire state has been provided.
		<var>R<sub>1</sub></var>...<var>R<sub>n</sub></var> identify the inlined resource(s).
		See <a href="#ldpr-inlining" class="sectionRef"></a> for details.
	<p></p></dd>
	
	<dt><dfn>Member inlining</dfn></dt>
	<dd>A special case of <a title="Resource inlining">resource inlining</a>, where all members of a container on a given
		page are inlined.  The response page may or may not include all of the container's members.
		See <a href="#ldpc-inlining" class="sectionRef"></a> for details.
	<p></p></dd>
	
  </dl>

<section>
<h2 id="conventions">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 rdf:     &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
	@prefix rdfs:    &lt;http://www.w3.org/2000/01/rdf-schema#&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>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>informative</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. Change History: <b>informative</b></li>
  <li>C.1 Normative references: <b>normative</b></li>
  <li>C.2 Informative references: <b>informative</b></li>
</ul>

<p>A conforming <b>LDP server</b> is an application program that processes HTTP 
requests and generates HTTP responses that conform to the rules defined in <a href="#linked-data-platform-resources" class="sectionRef"></a>
and <a href="#linked-data-platform-containers" class="sectionRef"></a>.</p>

<p>A conforming <b>LDP client</b> is an application program that generates HTTP 
requests and processes HTTP responses that conform to the rules defined in <a href="#linked-data-platform-resources" class="sectionRef"></a>
and <a href="#linked-data-platform-containers" class="sectionRef"></a>.</p>

</section>


<section>
<h1 id="ldpr">Linked Data Platform Resources</h1>
	<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 LDPR servers. 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 formats should be used?</li>
		<li>How is optimistic collision detection handled for updates?</li>
		<li>What should client expectations be for changes to linked-to resources,
				such as type changes?</li>
		<li>What can servers do to ease the burden of constraints for resource
				creation?</li>
		<li>How	do I GET the entries of a large resources broken up into pages?</li>
	</ul>
	<p>Additional informative guidance is available on the <a
			href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide"
			class="external "
			title="Deployment Guide"
			rel="nofollow">working group's wiki</a> that addresses deployment
		questions such as:</p>
	<ul>
		<li>What literal value types should be used?</li>
		<li>Are there some typical vocabularies that should be reused?</li>
	</ul>
	<p>The following sections define the rules and
		guidelines for use of LDPRs. This document also explains how to include
		information about each member in the resource’s own representation
		and how to paginate the resource representation if it gets too big.</p>
	
<section>
<h2 id="ldpr-general">General</h2>
		
	<div id="ldpr-4_1_1" class="rule">4.1.1 LDPR servers MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].</div>
	<div id="ldpr-4_1_2" class="rule">4.1.2 LDPR servers MUST provide an RDF representation for LDPRs. 
	The HTTP <code>Request-URI</code> of the LDPR is typically the subject of most triples in the response.
	</div>
	<div id="ldpr-4_1_3" class="rule">4.1.3 LDPR servers MAY host a mixture of LDPRs and non-LDPRs. For example, it
		is common for LDPR servers to need to host binary or text resources
		that do not have useful RDF representations.
	</div>

	<div id="ldpr-4_1_4" class="rule">4.1.4 LDPRs 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.
	</div>
	<div id="ldpr-4_1_4_1" class="rule">4.1.4.1 LDPR predicates SHOULD use standard vocabularies such as Dublin Core
		[[!DC-TERMS]], RDF [[!RDF-CONCEPTS]] and RDF Schema [[!RDF-SCHEMA]], whenever
		possible.
	</div>
	<div id="ldpr-4_1_5" class="rule">4.1.5 LDPR 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.
	</div>
	<div id="ldpr-4_1_6" class="rule">4.1.6 LDPR servers MAY support standard 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.
	</div>
		
	<div id="ldpr-4_1_7" class="rule">4.1.7 LDPRs MAY 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.
	</div>
	<div id="ldpr-4_1_8" class="rule">4.1.8 LDPR server responses MUST use entity tags (either weak or strong 
ones) as response <code>ETag</code> header values.
	</div>
	
	<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/32">ISSUE-32</a></div>
	How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
	</div>

	<div id="ldpr-4_1_9" class="rule">4.1.9 LDPR
		servers SHOULD enable simple creation and modification of LDPRs.
		It is
		common for LDPR servers to put restrictions on representations – for
		example, the range of <code>rdf:type</code> predicates, datatypes of
		the objects of predicates, and the number of occurrences of predicates in an LDPR, but
		servers SHOULD minimize those restrictions.  Enforcement of
		more complex constraints will greatly restrict the set of clients
		that can modify resources. For some server applications, excessive
		constraints on modification of resources may be required.
	</div>

<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/57">ISSUE-57</a></div>
	How can a client determine that it is in communication with an LDP server?
	</div>

	<div id="ldpr-4_1_10" class="rule">4.1.10 LDPR servers
		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 resource's HTTP <code>Request-URI</code>. This is notionally equivalent to the
		presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in the resource.
		The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP specification in a way
		that clients can introspect dynamically at run-time.  Conservative clients should note that 
		<a href="#ldpr-4_1_3">a 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 introspected by a conservative client, in the absence of outside information.
	</div>
<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/78">ISSUE-78</a></div>
	inferencing levels
	</div>

	<div id="ldpr-4_1_11" class="rule">4.1.11 LDPR servers
		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. 
	</div>

</section>

<section>
<h2 id="ldpr-HTTP_GET">HTTP GET</h2>
	<div id="ldpr-4_2_1" class="rule">4.2.1 LDPR servers MUST support the HTTP <code>GET</code> Method for LDPRs.
	</div>
	<div id="ldpr-4_2_2" class="rule">4.2.2 LDPR servers SHOULD provide a <code>text/turtle</code>
		representation of the requested LDPR [[!TURTLE]].
	</div>
	<div id="ldpr-4_2_3" class="rule">4.2.3 LDPR servers MAY provide 
		representations of the requested LDPR beyond those
		necessary to conform to this specification, using standard HTTP content negotiation. 
		If the client does not indicate a preference, <code>text/turtle</code> SHOULD be returned.
	</div>
	<div id="ldpr-4_2_4" class="rule">4.2.4 In the absence of special knowledge of the application or domain, LDPR
		clients MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
	</div>
	<div id="ldpr-4_2_5" class="rule">4.2.5 In the absence of special knowledge of the application or domain, LDPR
		clients MUST assume that the <code>rdf:type</code> values
		of a given LDPR can change over time.
	</div>
</section>

<section>
<h2 id="ldpr-HTTP_POST">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>Creation of LDPRs can be done 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.</p>
</section>

<section>
<h2 id="ldpr-HTTP_PUT">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.</p>
		
	<div id="ldpr-4_4_1" class="rule">4.4.1 If HTTP <code>PUT</code> is performed on an existing resource, LDPR servers MUST
		replace the entire persistent state of the identified resource with
		the entity representation in the body of the request. 
		LDPR servers MAY ignore server managed properties such as <code>dcterms:modified</code> 
		and <code>dcterms:creator</code> if they are not under
		client control. Any LDPR servers that wish
		to support a more sophisticated merge of data provided by the client
		with existing state stored on the server for a resource MUST use HTTP
		<code>PATCH</code>, not HTTP <code>PUT</code>.
	</div>
		
	<div id="ldpr-4_4_2" class="rule">4.4.2 LDPR clients 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. LDPR servers SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
		to detect collisions. LDPR servers 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]].  LDPR servers 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]].
	</div>
	<div id="ldpr-4_4_3" class="rule">4.4.3 LDPR clients 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.
	</div>
	<div id="ldpr-4_4_4" class="rule">4.4.4 LDPR clients SHOULD assume that an LDPR server could discard triples
		whose predicates the server does not recognize or otherwise chooses
		not to persist. In other words, LDPR servers MAY restrict themselves
		to a known set of predicates, but LDPR clients MUST NOT restrict themselves to a known set of predicates 
		when their intent is to perform a later HTTP <code>PUT</code> to update the resource.
	</div>
	<div id="ldpr-4_4_5" class="rule">4.4.5 An LDPR client 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]].
	</div>
	<div id="ldpr-4_4_6" class="rule">4.4.6 LDPR servers MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
	</div>
	<div id="ldpr-4_4_7" class="rule">4.4.7 LDPR servers SHOULD allow clients to update resources without
		requiring detailed knowledge of server-specific constraints.  
		This is a consequence of the requirement to <a href="#ldpr-4_1_9">enable simple creation and modification</a> of LPDRs.
	</div>		
</section>
		
<section>
<h2 id="ldpr-HTTP_DELETE">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
	<a href="ldpc-HTTP_DELETE">section 5.6</a>.</p>
		
	<div id="ldpr-4_5_1" class="rule">4.5.1 LDPR servers MUST remove the resource identified by the <code>Request-URI</code>.
		After a successful HTTP <code>DELETE</code>, a subsequent HTTP <code>GET</code> on the same
		<code>Request-URI</code> MUST result in a 404 (Not found) or 410 (Gone) status
		code. Clients SHOULD note that servers MAY reuse a URI under some circumstances.
	</div>
	
	<div id="ldpr-4_5_2" class="rule">4.5.2 LDPR servers MAY alter the state of other resources as a result of an
		HTTP <code>DELETE</code> request. For example, it is acceptable for the server to
		remove triples from other resources whose subject or object is the
		deleted resource. It is also acceptable and common for LDPR servers to
		not do this – behavior is server application specific.
	</div>
</section>

<section>
<h2 id="ldpr-HTTP_HEAD">HTTP HEAD</h2>
	<p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
		<code>HEAD</code> responses include the same headers as <code>GET</code> responses.  
		Thus, implementers should also carefully read <a href="#ldpr-HTTP_GET" class="sectionRef"></a>.</p>
	<div id="ldpr-4_6_1" class="rule">4.6.1 LDPR servers MUST support the HTTP <code>HEAD</code> method.</div>
	<div id="ldpr-4_6_2" class="rule">4.6.2 LDPR servers MUST support the HTTP response headers defined in <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
	</div>
</section>

<section>
<h2 id="ldpr-HTTP_PATCH">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.</p>
		
	<div id="ldpr-4_7_1" class="rule">4.7.1 LDPR servers MAY implement HTTP <code>PATCH</code> to allow modifications,
		especially partial replacement, of their resources [[!RFC5789]]. No
		minimal set of patch document formats is mandated by this document.
	</div>

	<div id="ldpr-4_7_2" class="rule">4.7.2 LDPR servers SHOULD allow clients to update resources without
		requiring detailed knowledge of server-specific constraints.  
		This is a consequence of the requirement to <a href="#ldpr-4_1_9">enable simple creation and modification</a> of LPDRs.
	</div>

	<div id="ldpr-4_7_3" class="rule">4.7.3 LDPR servers 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="#ldpc-HTTP_PUT"><code>PUT</code></a> should be used as the standard way to create new LDPRs.
	</div>
	
	<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/32">ISSUE-32</a></div>
	How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
	</div>

	<div id="ldpr-4_7_4" class="rule">4.7.4 LDPR servers 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.
	</div>

</section>

<section>
<h2 id="ldpr-HTTP_OPTIONS">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>

	<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/32">ISSUE-32</a></div>
	How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
	</div>

	<div id="ldpr-4_8_1" class="rule">4.8.1 LDPR servers MUST support the HTTP <code>OPTIONS</code> method.</div>
		
	<div id="ldpr-4_8_2" class="rule">4.8.2 LDPR servers 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>.
	</div>
		
</section>

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

<section class="informative">
<h3 id="ldpr-PagingIntro">Introduction</h3>
	<p>It sometimes happens that a
		resource is too large to reasonably transmit its representation in a
		single HTTP response. This will be especially true if the resource
		representation includes many triples both from its own representation and
		from the representations of any of its members. A client could anticipate that a resource will be too large -
		for example, a client tool that accesses defects may assume that an
		individual defect will usually be of sufficiently constrained size
		that it makes sense to request all of it at once, but that the
		container of all the defects ever created will typically be too big.
		Alternatively, a server could recognize that a resource that has been
		requested is too big to return in a single message.</p>
	<p>
		To address this problem, LDPRs should support a technique called Paging.  Paging can be achieved with a
		simple RDF pattern. For each resource, <code>&lt;resourceURL&gt;</code>, we define a new
		'first page' resource.  In this example, its URL will be <code>&lt;resourceURL&gt;?firstPage</code>,
		but servers are free to construct the URL as they see fit.
		The triples in the representation of the each page
		are typically a subset of the triples in the resource
		- same subject, predicate and object.
	</p>
	<p>LDPR servers may respond to requests for a
		resource by redirecting the client to the first page resource –
		using a 303 “See Other” redirect to the actual URL for the page
		resource.  Alternatively, clients may introspect the resource for a paged representation 
		and use it preferentially when available.</p>
	<p>
		Looking at an example resource representing Example Co.'s customer
		relationship data, we’ll split the response across two pages.  
		To find the URL of the first page, the client makes a <code>OPTIONS</code> request
		to the resource's URL, and in the response looks for a HTTP <code>Link</code>
		header with <code>rel="first"</code>; the target URI in the header is the URL
		of the first page resource.
		The client then 
		requests the first page as <code>http://example.org/customer-relations?firstPage</code>:
	</p>

<pre class="example"># The following is the representation of
#    http://example.org/customer-relations?firstPage
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.

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

&lt;http://example.org/customer-relations?firstPage&gt;
   a ldp:Page;
   ldp:pageOf &lt;http://example.org/customer-relations&gt;;
   ldp:nextPage &lt;http://example.org/customer-relations?p=2&gt;.

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

	<p>
		The following example is the result of retrieving the representation
		for the next page:
	</p>

<pre class="example"># The following is the representation of
#  http://example.org/customer-relations?p=2
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.

&lt;http://example.org/customer-relations&gt;
   o:client &lt;client#GlenWSmith&gt;, &lt;client#AlfredESmith&gt;. 
 
&lt;http://example.org/customer-relations?p=2&gt;
   a ldp:Page;
   ldp:pageOf &lt;http://example.org/customer-relations&gt;;
   ldp:nextPage rdf:nil.

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

&lt;client#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, a value of <code>rdf:nil</code> is used for the <code>ldp:nextPage</code>
		predicate of the page resource.
	</p>
</section>

<section>
<h3 id="ldpr-PagingGET">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>, LDPR servers that support paging must also follow the requirements in this section</p>

	<div id="ldpr-pagingGET-1" class="rule">4.9.2.1 LDPR servers SHOULD allow clients to retrieve large LDPRs in
		pages. In responses to <code>GET</code> requests with an LDPR as the <code>Request-URI</code>, 
		LDPR servers that support paging SHOULD provide an HTTP <code>Link</code>
		header whose target URI is the first page resource, and whose link relation type is <code>first</code> [[!RFC5988]]. 
		This is the mechanism by which clients discover the URL of the first page.  If no such <code>Link</code>
		header is present, then conservative clients will assume that the LDPR does not support paging.
		For example, if there is a LDPR with URL <code>&lt;resourceURL&gt;</code> that supports paging and whose
		first page URL is <code>&lt;resourceURL&gt;?theFirstPage</code>, then the corresponding link header
		would be <code>Link: &lt;?theFirstPage&gt;;rel="first"</code>.
		The representation for any page, including the first, will include
		the URL for the next page. See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
	</div>
	<div id="ldpr-pagingGET-2" class="rule">4.9.2.2 LDPR servers MAY split the response representation of any LDPR. 
		This is known as
		server-initiated paging. See <a href="#ldpr-Paging" class="sectionRef"></a> for
		additional details.
	</div>
	<div id="ldpr-pagingGET-3" class="rule">4.9.2.3 LDPR servers that initiate paging SHOULD respond to requests for a LDPR
		by redirecting the client to the first page resource using a <code>303 See
		Other</code> response with an HTTP <code>Location</code> header providing the first page resource URL.
	</div>
	<div id="ldpr-pagingGET-4" class="rule">4.9.2.4 LDPR servers that support paging MUST include in the page
		representation a representation for the LDPR.
	</div>
	<div id="ldpr-pagingGET-5" class="rule">4.9.2.5 The page resource representation SHOULD have one triple to indicate its
		type, whose subject is the URL of the page, whose predicate is <code>rdf:type</code> and object is <code>ldp:Page</code>.
		It also SHOULD have 1 triple to indicate the resource it is paging,
		whose  subject is the URL of the page, predicate is <code>ldp:pageOf</code>,
		and object is the URL of the LDPR.
	</div>
	<div id="ldpr-pagingGET-6" class="rule">4.9.2.6 The page resource representation MUST have one triple with the subject
		of the page, predicate of <code>ldp:nextPage</code> and
		object being the URL for the subsequent page.
	</div>
	<div id="ldpr-pagingGET-7" class="rule">4.9.2.7 The last page resource representation MUST have one triple with the subject of the 
	    last page, predicate of <code>ldp:nextPage</code> and object being <code>rdf:nil</code>.
	</div>
</section>

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

	<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/32">ISSUE-32</a></div>
	How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
	</div>

<div id="ldpr-4_9_3_1" class="rule">4.9.3.1 LDPR servers MUST indicate their support for client-initiated paging by
	responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
	response header for link relations using the header name of <code>Link</code> and link relation type <code>first</code> [[!RFC5988]].
</div>
</section>

</section>

<section>
<h2 id="ldpr-inlining">Resource Inlining: Representing Multiple Resources in a Response</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>resource inlining</a> to save application latency
		and server/network load in controlled environments.</li>
		</ul>
		<p>Feedback, both positive and negative, is invited by sending email to the mailing list 
		in <a href="#sotd">Status of This Document</a>.</p>
	</div>

<section class="informative">
<h3 id="ldpr-InliningIntro">Introduction</h3>
	<p>Servers whose resources are relatively granular may wish to optimistically provide more information
		in a response than what the client actually requested, in order to reduce the average number of client
		application HTTP flows.  LDP provides some basic building blocks to enable
		this, that implementations can re-use to build complete solutions, and they may serve as 
		complete solutions in applications with sufficient controls on resource content.
		These building blocks are <a>resource inlining</a> and <a>member inlining</a>.
	</p>
	
	<p>LDP does not provide clients with any way to detect whether or not the server is capable of 
		inlining (all its resources or any specific resource), nor does it provide clients 
		with any way to influence which (if any) resources are inlined in any given response.
	</p>
	
	<p>
		Servers can return extra triples on any response, but fail to meet the definition of <a>resource inlining</a>, 
		by either returning a subset of the other resource(s) triples or by failing to assert that
		all triples were included (even through they were).  Clients might still find the extra
		information useful, but the only way for clients to be sure they had all available 
		information would be to make a HTTP <code>GET</code> request against all the other resource(s).
		In some applications, knowing that these requests are unnecessary saves significant latency
		and server/network load.
	</p>
</section> <!-- h3 -->

<section class="informative">
<h3 id="ldpr-InliningWarnings">Use with Care</h3>
	<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/58">ISSUE-58</a></div>
	Action 87: Add an informative section on the possible dangers of inlining resources
	</div>

	<p>The building blocks LDP provides can only be safely used if certain assumptions hold.  
	Said another way, resource inlining solves a subset of scenarios, not all scenarios in the general case &mdash;
	so if you care about any of the following in a given application, your server should avoid returning
	<em>any</em> triples beyond those found at the HTTP <code>Request-URI</code>.
	</p>
	<ul>
	<li><p>
		Provenance is lost: because RDF graphs from multiple HTTP resources are merged in the
		response without attributing each statement to its originating graph (i.e. without quotation),
		it is impossible for a client to reliably know which
		triples came from which HTTP resource(s).  A general solution allowing quotation is
		RDF Datasets; that is expected to be standardized independently, and can be used in these cases
		once it is available.
	</p></li>
	<li><p>
		The response may contain contradictions that are trivially obvious (or subtle), and those may or 
		may not be a problem at the application level.  For a trivial example, two triples may have
		identical subjects and predicates but different objects: "75F is too hot"; "75F is too cold".
		Again, quotation via RDF Datasets (or any equivalent mechanism) is believed to provide a 
		long term solution once standardized.
	</p></li>
	</ul>
</section> <!-- h3 -->

<section>
<h3 id="ldpr-InliningGET">HTTP GET</h3>
	<p>In addition to the requirements set forth in other sections, 
		LDPR servers that support <a>resource inlining</a>
		must also follow the requirements in this section.</p>

	<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/58">ISSUE-58</a></div>
	Action 89: Add a predicate ldp:inlinedResource the object of which is a URI of a linked resource that is fully inlined, 
	marked as AT RISK.
	</div>

	<div id="ldpr-4_10_3_1" class="rule">4.10.3.1 LDPR servers that support <a>resource inlining</a> MUST 
		include a <code>ldp:Page</code> resource in the representation describing the set of inlined resources, 
		whether or not the representation contains subsequent pages.  The <code>ldp:Page</code> resource conceptually contains
		metadata about the representation; it is usually not part of the HTTP resource's state, and its presence does not indicate that
		the LDPR server supports <a href="#ldpr-Paging">paging</a> in general.  
		LDPR servers that include the <code>ldp:Page</code> resource for inlining and also support 
		paging MUST use the same <code>ldp:Page</code> resource for the triples required by both,
		in order to minimize client code complexity.
		The <code>ldp:Page</code> resource's triples are the LDP-defined means by which the servers communicate to LDP clients 
		the set of HTTP resources whose state is included in a representation, allowing clients to avoid HTTP <code>GET</code>
		requests for them.
	</div>

	<div id="ldpr-4_10_3_2" class="rule">4.10.3.2 LDPR servers that support <a>resource inlining</a> MUST 
		include the <code>ldp:Page</code> resource described in <a href="#ldpr-4_10_3_1">section 4.10.3.1</a> 
		one triple for each inlined resource, 
		whose subject is the <code>ldp:Page</code> resource URI,
		whose predicate is <code>ldp:inlinedResource</code>, and
		whose object is the HTTP <code>Request-URI</code> of an inlined resource [[!HTTP11]].
	</div>

	<div id="ldpc-4_10_3_3" class="rule">4.10.3.3 LDPR clients SHOULD avoid making HTTP <code>GET</code> requests
		against any resource whose HTTP <code>Request-URI</code> is the object of a triple of the form 
		described in <a href="#ldpc-4_10_3_2">section 4.10.3.2</a>, unless there are application-specific
		reasons for doing so.  Clients should note that by the time the representation is received, the actual state
		of any inlined resource(s) may have changed due to subsequent requests.
	</div>

	<div id="ldpc-4_10_3_4" class="rule">4.10.3.4 LDPR clients MUST NOT assume that LDPR representations
		lacking a <code>ldp:Page</code> resource or lacking the triple
		described in <a href="#ldpc-4_10_3_2">section 4.10.3.2</a> contain all the triples for any resource(s)
		listed in the representation whose HTTP <code>Request-URI</code> differs from 
		the HTTP <code>Request-URI</code> used by the client.  
		The representation might in fact contain all such triples, or some
		subset of them, and that might or might not be completely adequate for the client's intended usage, but
		an LDP client has no way to discern from such a representation which interpretation is accurate.
	</div>

</section>

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

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

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

<section class="informative">		
<h2 id="ldpc-informative">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 membership triples. The membership triples of a container all
		have the same subject and predicate – the objects of the membership
		triples define the members of the container. The subject of the
		membership triples is called the membership subject and the predicate
		is called the membership predicate. In the simplest cases, the
		membership subject will be the LDPC resource itself, but it does not
		have to be. The membership predicate is also variable and will often
		be a predicate from the server application vocabulary or the <code>rdfs:member</code> predicate.
	</p>
	<p>This document includes a set of guidelines for
		using POST to create new resources and add them to the list of
		members of a container. It goes on to explain how to learn about a set of related
		resources, they may have been created using POST or through other means.
		It also defines behavior when POST created resources are deleted, to clean up
		container membership, and deleting containers removes membership information and
		possibly perform some cleanup tasks on unreferenced member resoruces.</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"># The following is the representation of
#    http://example.org/container1/
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.

&lt;&gt;
   a ldp:Container;
   ldp:membershipSubject &lt;&gt;
   ldp:membershipPredicate rdfs:member;
   ldp:membershipObject ldp:MemberSubject;
   dcterms:title "A very simple container";
   rdfs:member &lt;member1&gt;, &lt;member2&gt;, &lt;member3&gt;.</pre>

	<p>This example is very straightforward - the
			membership predicate is <code>rdfs:member</code> and the membership subject is the container
			itself. A POST to this container will create a new resource
			and add it to the list of members by adding a new membership triple
			to the container.</p>

	<p>Sometimes it is useful to use a subject
	other than the container itself as the membership subject and to use
	a predicate other than <code>rdfs:member</code> as the membership predicate. Let's
	start with a domain resource for a person's net worth, as illustrated below:</p>
			
<pre class="example" id="ldpc-ex-membership-full"># The following is a partial representation of
#   http://example.org/netWorth/nw1
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;&gt;
   a o:NetWorth;
   o:netWorthOf &lt;http://example.org/users/JohnZSmith&gt;;
   o:asset 
      &lt;assetContainer/a1&gt;,
      &lt;assetContainer/a2&gt;;
   o:liability 
      &lt;liabilityContainer/l1&gt;,
      &lt;liabilityContainer/l2&gt;,
      &lt;liabilityContainer/l3&gt;.
</pre>
	<p>From this example, there is a <code>rdf:type</code> of <code>o:NetWorth</code> indicating the
	resource represents an instance of a person's net worth and <code>o:netWorthOf</code> predicate indicating 
	the associated person.  There are two sets of same-subject, same-predicate pairings; one for assets and
	one for liabilities.  It would be helpful to be able to associate these multi-valued sets using a URL
	for them to assist with managing these, this is done by associating containers with them as 
	illustrated below:
	</p>

<pre class="example" id="ldpc-ex-membership-full"># The following is an elaborated representation of
#   http://example.org/netWorth/nw1
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;&gt;
   a o:NetWorth;
   o:netWorthOf &lt;http://example.org/users/JohnZSmith&gt;;
   o:asset 
      &lt;assetContainer/a1&gt;,
      &lt;assetContainer/a2&gt;;
   o:liability 
      &lt;liabilityContainer/l1&gt;,
      &lt;liabilityContainer/l2&gt;,
      &lt;liabilityContainer/l3&gt;.

&lt;assetContainer/&gt;
   a ldp:Container;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipSubject &lt;.&gt;;
   ldp:membershipPredicate o:asset;
   ldp:membershipObject ldp:MemberSubject.

&lt;liabilityContainer/&gt;
   a ldp:Container;
   dcterms:title "The liabilities of JohnZSmith";
   ldp:membershipSubject &lt;.&gt;;
   ldp:membershipPredicate o:liability;
   ldp:membershipObject ldp:MemberSubject.
</pre>

	<p>The essential structure of the container is
	the same, but in this example, the membership subject is not the
	container itself – it is a separate net worth resource. The
	membership predicates are <code>o:asset</code> and <code>o:liability</code> – predicates
	from the domain model. A POST of an asset representation to the asset container will create a new
	asset and add it to the list of	members by adding a new membership triple
	to the container. You might wonder why
	<code>http://example.org/netWorth/nw1</code> isn't made a container itself and POST
	the new asset directly there. That would be a fine design if <code>http://example.org/netWorth/nw1</code>
	had only assets, but if it has separate predicates for assets and liabilities,
	that design will not work because it is unspecified to which predicate the POST
	should add a membership triple. Having separate <code>http://example.org/netWorth/nw1/assetContainer/</code> 
	and <code>http://example.org/netWorth/nw1/liabilityContainer/</code> container
	resources allows both assets and liabilities to be created.
	</p>

<pre class="example" id="ldpc-ex-membership-subj">
# The following is the representation of
#   http://example.org/netWorth/nw1/assetContainer/
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.

&lt;&gt;
   a ldp:Container;
   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   ldp:membershipPredicate o:asset;
   ldp:membershipObject ldp:MemberSubject.

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

	<p>In this example, clients cannot simply guess
			which resource is the membership subject and which predicate is the
			membership predicate, so the example includes this information in
			triples whose subject is the LDPC resource itself.
	</p>
	
	<div id="ldpc-member_data" class="rule informative">5.1.1 Container Member Information</div>
	<p>In many – perhaps most – applications
		involving containers, it is desirable for the client to be able to
		get information about each container member without having to do a
		GET on each one. LDPC allows servers to include this information
		directly in the representation of the container. The server decides
		the amount of data about each member that is provided. Some common
		strategies include providing a fixed number of standard properties,
		or providing the entire RDF representation of each member resource,
		or providing nothing. The server application domain and its use-cases
		will determine how much information is required.</p>

	<p>Continuing on from the net worth
		example, there will be additional triples for the member resources
		(assets) in the representation:</p>

<pre class="example"># The following is the representation of
#	 http://example.org/netWorth/nw1/assetContainer/
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp:      &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o:       &lt;http://example.org/ontology/&gt;.

&lt;&gt;
   a ldp:Container;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   ldp:membershipPredicate o:asset;
   ldp:membershipObject ldp:MemberSubject.

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

&lt;a1&gt;
   a o:Stock;
   o:value 10000.
&lt;a2&gt;
   a o:Bond;
   o:value 20000.
&lt;a3&gt;
   a o:RealEstateHolding;
   o:value 300000.</pre>
	<p>In a similar manner, when the representation for the resource of asset <var>.../&lt;a1&gt;</var> is returned a 
	server may include the membership triple of the form <var>(.../assetContainer/, o:asset, .../a1).</var></p>

	<div id="ldpc-get_non-member_props" class="rule">5.1.2 Retrieving Only Non-member Properties
	</div>
	<p>The representation of a container
		that has many members will be large. There are several important
		cases where clients need to access only the non-member properties of
		the container. Since retrieving the whole container representation to
		get this information may be onerous for clients and cause unnecessary
		overhead on servers, it is desired to define a way to retrieve only
		the non-member property values. Defining for each 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>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

@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.

&lt;http://example.org/container1/&gt;
   a ldp:Container;
   dcterms:title "A Linked Data Platform Container of Acme Resources";
   ldp:membershipSubject http://example.org/container1/;
   ldp:membershipPredicate rdfs:member;
   ldp:membershipObject 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>

	<div id="ldpc-ordering" class="rule">5.1.3 Ordering</div>
	<p>
		There are many cases where an ordering of the members of the
		container is important. 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 LDPC servers when containers are
		paginated. If the server does not respect ordering when constructing
		pages, the client would be forced to retrieve all pages before
		sorting the members, which would defeat the purpose of pagination. 
		In cases where ordering is important, an 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 
		higher sort order than all members on the previous page and 
		lower sort order than all the members on the next page. 
		When the sort is descending, the opposite order is used. 
		Since more than one value may be used to sort members, 
		the 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"># The following is the ordered representation of
#   http://example.org/netWorth/nw1/assetContainer/
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.

&lt;&gt;
   a ldp:Container;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   ldp:membershipPredicate o:asset;
   ldp:membershipObject ldp:MemberSubject.

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

&lt;#SortValueAscending&gt;
   a ldp:ContainerSortCriterion;
   ldp:containerSortOrder ldp:ascendingOrder;
   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.
		</p>
</section>

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

	<div id="ldpc-5_2_1" class="rule">5.2.1 LDPC servers MUST also be conformant LDPR servers. A Linked Data Platform
		Container MUST also be a conformant Linked Data Platform Resource.
	</div>
	<div id="ldpc-5_2_2" class="rule">5.2.2 For an LDPC,
	the same resource (LDPR or not) which is identified by its canonical URI, MAY be a member of 
	more than one LDPC.
	</div>
	<div id="ldpc-5_2_3" class="rule">5.2.3 The state of an LDPC includes information about which
		resources are its members. In the simplest cases, the membership subject
		will be the LDPC resource itself, but it does not have to be. The
		membership predicate is also variable and will often be a predicate
		from the server application vocabulary. If there is no obvious
		predicate from the server application vocabulary to use, LDPC servers
		SHOULD use the <code>rdfs:member</code> predicate. Member resources can be
		any kind of resource identified by its URI, LDPR or otherwise.
	</div>
	
	<div id="ldpc-5_2_4" class="rule">5.2.4 An LDPC representation MUST contain one triple 
		whose subject is the LDPC URI, 
		whose predicate is the <code>ldp:membershipSubject</code>, 
		and whose object is the LDPC's membership subject URI.
	</div>
	
	<div id="ldpc-5_2_5" class="rule">5.2.5 An LDPC representation MUST contain one triple 
		whose subject is the LDPC URI, 
		and whose predicate is either <code>ldp:membershipPredicate</code> or <code>ldp:membershipPredicateInverse</code>. 
		The object of the triple is constrained by other sections, such as
		<a href="ldpc-5_2_5_1">5.2.5.1</a> or <a href="ldpc-5_2_5_2">5.2.5.2</a>.
	</div>
	
	<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/75">ISSUE-75</a></div>
	non-monotonic ldp:membershipXXX relations.  Drafted per 2013-06-18 F2F resolution.
	</div>
	
	<div id="ldpc-5_2_5_1" class="rule">5.2.5.1 For a given triple <var>T</var> with a subject <var>C</var>
	of the LDPC and predicate of 
	<code>ldp:membershipPredicate</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
	indicate membership to the linked to LDPC, or simply: <var>T = ( C</var>, <code>ldp:membershipPredicate</code>, <var>P)</var>. 
	For the membership predicate URI object used in the triple <var>T</var>, it would be found in a resource's
	same subject <var>R</var> and same predicate <var>P</var> membership triples of the form: 
	(<var>R</var>, <var>P</var>, <var>MR</var>), where <var>MR</var> represents URI of
	a member resource.
	</div>
	
	<div id="ldpc-5_2_5_2" class="rule">5.2.5.2  For a given triple <var>T</var> with a subject <var>C</var>
	of the LDPC and predicate of 
	<code>ldp:membershipPredicateInverse</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
	indicate membership to the linked to LDPC, or simply: <var>T = ( C</var>, <code>ldp:membershipPredicateInverse</code>, <var>P)</var>. 
	For the membership predicate URI object used in the triple <var>T</var>, it would be found in a resource's
	object subject <var>R</var> and same predicate <var>P</var> membership triples of the form: 
	(<var>MR</var>, <var>P</var>, <var>R</var>), where <var>MR</var> represents URI of
	a member resource.
	</div>
	
	<div id="ldpc-5_2_6" class="rule">5.2.6 The representation of a LDPC MAY 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 LDPC server to provide clients with
		information about the members without the client having to do a <code>GET</code>
		on each member individually.  See sections <a href="#ldpc-member_data">5.1.1 Container
		Member Information</a>, <a href="#ldpr-inlining" class="sectionRef"></a>, and
		<a href="#ldpc-inlining" class="sectionRef"></a> for additional details.
    </div>
		
	<div id="ldpc-5_2_7" class="rule">5.2.7 The representation of a LDPC MUST have <code>rdf:type</code>
		of <code>ldp:Container</code>, but it MAY have additional
		<code>rdf:type</code>s.
	</div>
	<div id="ldpc-5_2_8" class="rule">5.2.8 LDPC representations SHOULD NOT use RDF container types <code>rdf:Bag</code>,
		<code>rdf:Seq</code> or <code>rdf:List</code>.
	</div>

	<div id="ldpc-5_2_9" class="rule">5.2.9 LDPC servers 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 MAY delete a resource and then later re-use the
		URI when it identifies the same resource, but only when consistent with Web architecture [[WEBARCH]].
		While it is difficult to provide absolute implementation guarantees of non-reuse in all failure
		scenarios, re-using URIs creates ambiguities for clients that are best avoided.
	</div>
	

	<div id="ldpc-5_2_10" class="rule">5.2.10 Some LDPC's have membership object's that are not directly
	    URIs minted upon LDPC member creation, for example URIs with non-empty fragment identifier [[RFC3986]]. 
	    To determine which object URI to use for the  membership triple, LDPC's MUST contain one triple whose
	    subject is the LDPC URI, predicate is <code>ldp:membershipObject</code>, with an object <var>MO</var>. 
	    Where <var>MO</var> and the HTTP URI <var>R</var> from <code>POST</code> create (as found in HTTP response <code>Location</code> header) can be 
	    used to locate a triple of the form: <var>(R, MO, N)</var> and 
	    where <var>N</var> can be used to construct the membership triple of the form: <var>(membership subject, membership predicate, N)</var>.
	    When <code>ldp:membershipPredicateInverse</code> is used instead of <code>ldp:membershipPredicate</code>, the membership triple MUST be
	    of the form: <var>(N, membership predicate, membership subject)</var>. To indicate that the member resource URI is the membership object
	    (the default or typical case), the object MUST be set to predefined URI <code>ldp:MemberSubject</code> such that it forms the triple: 
	    <var>(LDPC URI, <code>ldp:membershipObject</code>, <code>ldp:MemberSubject</code>)</var>.
	</div>
	<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/72">ISSUE-72</a></div>
	edited in ldp:membershipObject in new previous section
	</div>	
	
	
	<!-- NOTE: Saving this sample to help with future editing/understanding or possible insertion directly.
	
	Let's say this LDPC has a membershipSubject of </people/roger> and membershipPredicate of pets:has_pet. If I POST the following to the LDPC: 

	<> foaf:primaryTopic <#this> .
	<#this> 
	  a animal:Cat; 
	  foaf:name "Zaza".
	
	... a new resource is created and there is a new membership triple of 
	
	</people/roger> pets:has_pet </people/roger/zaza>.
	
	but the desired one is:
	
	</people/roger> pets:has_pet </people/roger/zaza#this>.
		
	To do this, you'd have to use ldp:membershipObject such as:
	
	pets:has_pet 
	   a ldp:Container;
	   ldp:membershipPredicate pets:has_pet;
	   ldp:membershipSubject </people/roger>;
	   ldp:membershipObject foaf:primaryTopic .
	 -->
	
</section>

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

	<div id="ldpc-5_3_1" class="rule">5.3.1 The representation of a LDPC MUST contain a set of triples with a
		consistent subject and predicate whose objects indicate members of
		the container. The subject 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
		<a href="#ldpc-5_2_3">5.2.3</a>.
	</div>
	
	<div id="ldpc-5_3_2" class="rule">5.3.2 LDPC servers MAY represent the members of a paged LDPC in a sequential
		order.  If the server does so, it MUST be specify the order using a triple 
		whose subject is the page URI, 
		whose predicate is <code>ldp:containerSortCriteria</code>, 
		and whose object is a <code>rdf:List</code> of
		<code>ldp:containerSortCriterion</code> resources.  
		The resulting order 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.
		See section <a href="#ldpc-ordering">5.1.4 Ordering</a> for
		an example.
	</div>
	
	<div id="ldpc-5_3_3" class="rule">5.3.3 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 predicate 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.
	</div>
	
	<div id="ldpc-5_3_4" class="rule">5.3.4 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.
	</div>

	<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/14">ISSUE-14</a></div>
	Include clarifications about ordering in LDPC representations.
	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?
	</div>

	<div id="ldpc-5_3_5" class="rule">5.3.5 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 SHOULD be omitted for comparisons
		involving <a title="page-ordering values">page-ordering values</a> for which [[!SPARQL-QUERY]] does not use collations.
	</div>

	<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/63">ISSUE-63</a></div>
	Need to be able to specify collation with container ordering.  Drafted per 2013-06-18 F2F resolution.
	</div>
</section>

<section>
<h2 id="ldpc-HTTP_POST">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.</p>
		
	<div id="ldpc-5_4_1" class="rule">5.4.1 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, LDPC servers 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.
	</div>

	<div id="ldpc-5_4_2" class="rule">5.4.2 After a successful HTTP <code>POST</code> request to a LDPC, the new resource MUST
		appear as a member of the LDPC 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.
	</div>
	
	<div id="ldpc-5_4_3" class="rule">5.4.3 LDPC servers MAY accept an HTTP <code>POST</code> of non-RDF representations for
		creation of any kind of resource, for example binary resources.  See <a href="#ldpr-5_4_13">5.4.13</a> for introspection
		details.
	</div>
	<div id="ldpc-5_4_4" class="rule">5.4.4 For servers that support create, LDPC servers MUST create an LDPR from a
		RDF representation in the request entity body.  The newly created LDPR could also be a LDPC, therefore servers MAY
		allow the creation of LDPCs within a LDPC. 
	</div>
	
	<div id="ldpc-5_4_5" class="rule">5.4.5 LDPC servers MUST accept a request entity body with a request header
	    of <code>Content-Type</code> with value of <code>text/turtle</code> [[!TURTLE]].
	</div>
	<div id="ldpc-5_4_6" class="rule">5.4.6 LDPC servers SHOULD use the <code>Content-Type</code> request header 
		to determine the representation format when the request has an entity body.  When the header is absent, 
		LDPC servers MAY infer the content type by inspecting the entity body contents [[!HTTP11]].
	</div>
	<div id="ldpc-5_4_7" class="rule">5.4.7 In RDF representations, LDPC servers 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.  
	</div>	
	<div id="ldpc-5_4_8" class="rule">5.4.8 LDPC servers SHOULD assign the subject URI for the resource to be
		created using server application specific rules in the absence of a <a href="#ldpc-5_4_10">client hint</a>.
	</div>
	<div id="ldpc-5_4_8_1" class="rule">5.4.8.1 For RDF representations, LDPC servers MUST assign the base-URI for
	   [[!RFC3987]] relative-URI resolution to be the URI of the created subject resource.
	</div> 
	<div id="ldpc-5_4_9" class="rule">5.4.9 LDPC servers SHOULD allow clients to create new resources without
		requiring detailed knowledge of application-specific constraints.
		This is a consequence of the requirement to 
		<a href="#ldpr-4_1_9">enable simple creation and modification</a> of LPDRs.
	</div>
	<div id="ldpc-5_4_10" class="rule">5.4.10 LDPC servers 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.
	</div>
	
	<div id="ldpc-5_4_11" class="rule">5.4.11 LDPC servers that allow member creation via <code>POST</code> 
		SHOULD NOT re-use URIs, per the<a href="#ldpc-5_2_9">
		general requirements on LDPCs</a>.
	</div>
	
	<div id="ldpc-5_4_12" class="rule">5.4.12 Upon successful creation of a non-RDF and therefore non-LDPR member (HTTP status code of 
	201-Created and URI indicated by <code>Location</code> response header), LDPC servers MAY create an associated LDPR
	to contain data about the created resource.  If an LDPC server creates this associated LDPR 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]].</div>	
	
	<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/80">ISSUE-80</a></div>
	How does a client know which <code>POST</code> requests create new resources.
	<p>
	Note from editor: the MUST here keeps this aligned with what we decided for OPTIONS on PATCH;  in both 
	cases the header registration says SHOULD, and the LDP spec says MUST.  What makes that look a bit odd is
	that in the Accept-Post case, the registration and LDP are the same document.  Thus I added informative
	text here explicitly talking to the apparent discrepancy.
	</p>
	</div>	
		
	<div id="ldpr-5_4_13" class="rule">5.4.13 LDPR servers 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" semantic.
		This requirement on LDP servers is intentionally stronger than the one levied in the
		<a href="#header-accept-post">header registration</a>; it is unrealistic to expect all existing resources
		that support <code>POST</code> to suddenly return a new header or for all new specifications constraining
		<code>POST</code> to be aware of its existence and require it, but it is a reasonable requirement for new
		specifications such as LDP.
	</div>
	
	<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/79">ISSUE-79</a></div>
	ldp:contains => created
	</div>	
		
	<div id="ldpr-5_4_14" class="rule">5.4.14 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
		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.
	</div>
	
</section>

<section>
<h2 id="ldpc-HTTP_PUT">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.</p>
		
	<div id="ldpc-5_5_1" class="rule">5.5.1 LDPC servers SHOULD NOT allow HTTP <code>PUT</code> to update a LDPC’s members; 
		if the server receives such a request, it SHOULD respond with a 409
		(Conflict) status code.
	</div>
	<div id="ldpc-5_5_2" class="rule">5.5.2 LDPC servers 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:membershipSubject</code>, <code>ldp:membershipPredicate</code>
		and <code>ldp:membershipPredicateInverse</code>.
		Section <a href="#ldpc-5_7_1">5.7.1 HTTP HEAD</a> describes the process by which clients
		discover whether the server offers such a resource, and if so its URL. 

	</div>
	    
    <div id="ldpc-5_5_3" class="rule">5.5.3 LDPC servers SHOULD NOT allow HTTP <code>PUT</code> requests
		with member information in the request representation.
		See section <a href="#ldpc-member_data">5.1.1 Container
		Member Information</a> for additional details.
	</div>
	
	<div id="ldpc-5_5_4" class="rule">5.5.4 LDPC servers that allow member creation via <code>PUT</code> 
		SHOULD NOT re-use URIs, per the <a href="#ldpc-5_2_9">
		general requirements on LDPCs</a>.
	</div>
	
</section>

<section>
<h2 id="ldpc-HTTP_DELETE">HTTP DELETE</h2>
	<p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for LDPRs 
		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>
		
	<div id="ldpc-5_6_1" class="rule">5.6.1 When a LDPC member resource originally created by the LDPC (for example, one whose representation
	    was HTTP <code>POST</code>'d 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.
	</div>	
	<div id="ldpc-5_6_2" class="rule">5.6.2 When the LDPC server successfully completes the <code>DELETE</code> request on a LDPC, it MUST remove any
		membership triples associated with the LDPC as indicated by the canonical <code>Request-URI</code>.  The LDPC server MAY perform additional removal 
		of member resources. 
		For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not
		been accessed for some period of time.
	</div>
	
	<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/79">ISSUE-79</a></div>
	ldp:contains => created
	</div>	
		
	<div id="ldpc-5_6_3" class="rule">5.6.3 When the conditions in <a href="#ldpc-5_6_1">5.6.1</a> hold, and the 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.
	</div>	
	
	<div id="ldpc-5_6_4" class="rule">5.6.4 When a LDPC member resource originally created by the LDPC (for example, one whose 
	representation was HTTP <code>POST</code>'d to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server 
	created an associated LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>), the LDPC server must also remove the associated LDPR it created.
	</div>	
	
</section>

<section>
<h2 id="ldpc-HTTP_HEAD">HTTP HEAD</h2>
	<p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
		<code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also LDPR servers must also include HTTP headers
		on response to <code>OPTIONS</code>, see <a href="#ldpr-4_6_2">4.6.2</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>
<h2 id="ldpc-HTTP_PATCH">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.</p>
		
	<div id="ldpc-5_8_1" class="rule">5.8.1 LDPC servers are RECOMMENDED to support HTTP <code>PATCH</code> as the preferred
		method for updating LDPC non-membership properties.
	</div>
</section>

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

	<div id="ldpc-5_9_1" class="rule">5.9.1  
		LDPC servers 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">5.1.2 Retrieving Only Non-member Properties</a> for
		examples. 
		In responses to <code>OPTIONS</code> requests with an LDPC as the <code>Request-URI</code>, 
		LDPC servers 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#non-member-resource</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 conservative 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#non-member-resource"</code>
	</div>
	
	<div id="ldpc-5_9_2" class="rule">5.9.2 When a LDPC creates a non-LDPR (e.g. binary) member (for example, one whose 
	representation was HTTP <code>POST</code>'d to the LDPC and then referenced by a membership triple) it might create an associated LDPR to contain data about the 
	non-LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>).  For non-LDPRs that have this associated LDPR, an LDPC server MUST provide an HTTP <code>Link</code>
	header whose target URI is the associated LDPR, and whose link relation type is 
	<code>meta</code> [[!RFC5988]].</div>
</section>

<section>
<h2 id="ldpc-inlining">Member Inlining: Returning All of a Container Page's Members in a Response</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>resource inlining</a> to save application latency
		and server/network load in controlled environments.</li>
		</ul>
		<p>Feedback, both positive and negative, is invited by sending email to the mailing list 
		in <a href="#sotd">Status of This Document</a>.</p>
	</div>

<section class="informative">
<h3 id="ldpc-InliningIntro">Introduction</h3>
	<p>One of the most commonly cited scenarios for resource inlining is to save clients enumerating a container of 
		<i>m</i> members from having to perform <i>m+1</i> HTTP requests (or <i>m+p</i>, if the container
		is paged into <i>p</i> pages).  The desire is to allow the server to reduce the number of HTTP
		round-trips by returning some (perhaps all) members' content as part of the container's representation.
		In addition to the general <a>resource inlining</a> mechanism useful
		in cases where only a subset of the members' content is inlined, LDP also provides 
		a predicate for the special case where <i>all</i> of a container's or page's members are inlined.
		Rather than forcing the server to add a triple for each inlined member, forcing clients to
		compare the list of inlined members against the set of members in the representation, 
		and enlarging the representation needlessly,
		a single triple can be used.  This is called <a>member inlining</a>.
	</p>

	<p>LDP does not provide clients with any way to detect whether or not the server is capable of 
		resource inlining (all its resources or any specific resource), nor does it provide clients 
		with any way to influence which (if any) resources are inlined in any given response.
	</p>

	<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/58">ISSUE-58</a></div>
	Action 87: Add an informative section on the possible dangers of inlining resources
	</div>

	<p>The inlining building blocks LDP provides can only be safely used if certain assumptions hold.
		This is no less true for containers than for LDPRs in general.  
		See the general <a href="#ldpr-InliningWarnings">cautions on resource inlining</a>.
	</p>
</section> <!-- h3 -->

<section>
<h3 id="ldpc-InliningGET">HTTP GET</h3>
	<p>In addition to the requirements set forth in other sections, 
		LDPC servers that support <a>member inlining</a>,
		and LDP clients aware of the same facility,
		must also follow the requirements in this section.
	</p>

	<div class="ldp-issue-pending">
	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/58">ISSUE-58</a></div>
		Action 88: Add a property ldp:membersInlined true/false. The default (if not specified) is false. 
		If true, it means that a complete description of all members [on the current page] are inlined with the container document [or page], 
		and therefore clients SHOULD NOT do <code>GET</code> on the member URIs to retrieve additional triples.
		marked as AT RISK.
	</div>

	<div id="ldpc-5_10_2_1" class="rule">5.10.2.1 LDPC representations that are <a title="member inlining">member inlined</a> MUST 
		include a <code>ldp:Page</code> resource in the representation, whether or not the representation contains
		multiple pages, as described in <a href="#ldpr-4_10_3_1">section 4.10.3.1</a>.  In addition to satisfying
		those requirements, the representation MUST contain a triple
		whose subject is the <code>ldp:Page</code> resource URI,
		whose predicate is <code>ldp:membersInlined</code>, and
		whose object is <code>true</code>.
		This is means by which the server communicates to LDP clients that they can avoid HTTP <code>GET</code>
		requests for the members listed on the page.
	</div>

	<div id="ldpc-5_10_2_2" class="rule">5.10.2.2 LDPC clients SHOULD avoid making HTTP <code>GET</code> requests
		against any members in a LDPC representation containing a <code>ldp:Page</code> resource with the triple
		described in <a href="#ldpc-5_10_2_1">section 5.10.2.1</a>, unless there are application-specific
		reasons for doing so.  Clients should note that by the time the representation is received, the actual state
		of inlined members may have changed due to subsequent requests.
	</div>

	<div id="ldpc-5_10_2_3" class="rule">5.10.2.3 LDPC clients MUST NOT assume that LDPC representations
		lacking a <code>ldp:Page</code> resource or lacking the triple
		described in <a href="#ldpc-5_10_2_1">section 5.10.2.1</a> contain all the triples for all members
		listed in the representation.  The representation might in fact contain all those triples, or some
		subset of them, that might or might not be completely adequate for the client's intended usage, but
		an LDP client has no way to discern from such a representation which interpretation is accurate.
	</div>

	</section>

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

<section>
<h1>HTTP Header Definitions</h1>
     
<section>
<h2 id="header-accept-post">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 <a>Accept-Post</a> in this specification is pending 
		advancement of an IETF draft that would fully include it, see [[!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 modeled after the <code>Accept-Patch</code> header defined in [[!RFC5789]].
	</p>
   
	<div id="header-accept-post-1" class="rule">6.1.1 The syntax for <code>Accept-Post</code>, using
		the ABNF syntax defined in Section 2.1 of [[!HTTP11]], is:
		<blockquote><code>Accept-Post = "Accept-Post" ":" 1#media-type</code>
		<p>
		The <code>Accept-Post</code> header specifies a comma-separated list of media-
		types (with optional parameters) as defined by [[!HTTP11]], Section 3.7.
		</p>
		</blockquote>
	</div>

	<div id="header-accept-post-2" class="rule">6.1.2
		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>.
	</div>
	
	<div id="header-accept-post-iana" class="rule">6.1.3 IANA Registration Template</div>
	<div>
	<blockquote>
	<p>
	The Accept-Post response header must be added to the permanent registry (see [[!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>
</section> <!-- Header defns -->
    
<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-20130701/">Third Public Working Draft</a></em></blockquote>
-->
<ul>
	<li>2013-07-23 - Changed <a href="#header-accept-post" class="sectionRef"></a> to at risk as possibly moving to IETF (SS)</li>
	<li>2013-07-23 - ISSUE-53 4.2.3 changed MUST to SHOULD (SS)</li>
	<li>2013-07-22 - ISSUE-53 4.2.2 changed MUST to SHOULD (SS)</li>
	<li>2013-07-17 - Various updates from suggests from <a href="http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0067.html">Raúl</a> (SS)</li>
	<li>2013-07-15 - Inserted ldp:membershipObject into examples (SS)</li>
	<li>2013-07-15 - ISSUE-79 ldp:contains => ldp:created  (JA)</li>
	<li>2013-07-11 - Improving working in <a href="#ldpr-Paging" class="sectionRef"></a> to remove container references (SS)</li>
	<li>2013-07-11 - Removed 4.1.5, section number fixup:4.1.8-13-&gt;6-11, 4.9.2.* fixup, 5.3.7-10-&gt;>2-5 (SS)</li>
	<li>2013-07-11 - Removed all stubbed out sections 5.1.3, 5.3.2-6 (SS)</li>
	<li>2013-07-11 - Various editorial clean up items from editor todo list (SS)</li>
	<li>2013-07-11 - Removed closed issues that required no new spec changes: 50, 56, 16, 19, 17 (SS)</li>
	<li>2013-07-11 - ISSUE-51 Added how a LDPR can show which LDPC is it in (SS)</li>
	<li>2013-07-10 - Removed closed issues that required no new spec changes: 18, 35, 20 (SS)</li>
	<li>2013-07-10 - ISSUE-44 move section 4.1.7 (relationships are simple RDF links) to guidance (SS)</li>
	<li>2013-07-10 - ISSUE-72 take 2 - added ldp:MemberSubject to handle default case (SS)</li>
	<li>2013-07-10 - ISSUE-72 adding 5.2.10 for ldp:membershipObject (SS)</li>
	<li>2013-07-09 - ISSUE-58 inlining - actions 87-89 inclusive  (JA)</li>
	<li>2013-07-08 - Moved 5.7.* sections out of HEAD and into OPTIONS as 5.9.*, added 4.6.2 (SS)</li>
	<li>2013-07-08 - ISSUE-15 Inserted 5.4.12, 5.6.4, 5.7.2 to describe link-relation meta usage (SS)</li>
	<li>2013-07-08 - ISSUE-79 ldp:contains  (JA)</li>
	<li>2013-07-08 - ISSUE-80 Accept-Post (JA)</li>
	<li>2013-07-08 - ISSUE-32 Must support options (JA)</li>
	<li>2013-07-08 - ISSUE-78 No client inferencing  (JA)</li>
	<li>2013-07-08 - ISSUE-77 Move "must have rdf:type explicitly" to Best Practices  (JA)</li>
	<li>2013-07-08 - ISSUE-57 Knowing it's an LDP server  (JA)</li>
	<li>2013-07-01 - ISSUE-33 Moved 5.1.3 Paging (LDPC) to 4.8 (LDPR) (SS)</li>
	<li>2013-06-18 - ISSUE-75 5.2.5 membershipxxx predicates required, per 2013-06-18 F2F resolution (JA)</li>
	<li>2013-06-18 - ISSUE-63 End of 5.3 + example rewritten for 2013-06-18 F2F resolution (JA)</li>
	<li>2013-06-15 - ISSUE-14 End of 5.3 + example rewritten for ascending/descending sorts with optional collation (JA)</li>
	<li>2013-06-13 - ISSUE-54 New 5.4.8.1 to set base URI on create for relative URI resolution (SS)</li>
	<li>2013-06-10 - ISSUE-74 4.4.2 require 428 Condition Required status code when appropriate; SS adding 6585 to biblio (JA)</li>
	<li>2013-06-05 - ISSUE-64 Remove ?non-member-properties; 5.1.2, 5.3.2, 5.5.2 (JA)</li>
	<li>2013-05-21 - ISSUE-35 Re-use of URIs on create; 5.2.9, 5.4.11, 5.5.4 (JA)</li>
	<li>2013-05-21 - ISSUE-43 Slug in LDPC POSTs; 5.4.8, 5.4.10 (JA)</li>
	<li>2013-05-21 - ISSUE-65 Remove firstPage in favor of Link rel=first, mostly hits 5.3.3/5.3.4 (JA)</li>
	<li>2013-05-17 - ISSUE-13 Updated 5.2.3 to say any resource can be in a LDPC and inserted 5.5.3 on rejecting member data on PUT to LDPC (SS)</li>
	<li>2013-05-17 - Tweaks to Terminology section for LDPR and LDPC (SS)</li>
	<li>2013-05-17 - ISSUE-9 Moved section 4.1.7 out of spec to the <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Servers_should_serve_up_canonical_URLs">deployment guide</a> (SS)</li>
	<li>2013-05-15 - Updated wording for 5.2.2 from to be more clear (SS)</li>
	<li>2013-05-13 - ISSUE-49 Moved section 4.1.4 out of spec to the <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Predicate_URIs_SHOULD_be_HTTP_URLs">deployment guide</a>. (SS)</li>
	<li>2013-05-08 - Removed closed issues 5, 7, 55 and 38 as the don't require edits. Added 64 and 65. (SS)</li>
	<li>2013-05-08 - ISSUE-59 5.3.2 limited rdf:type of ldp:Container, removed 5.6.3, reworded 5.6.2, updated 1. (SS)</li>
	<li>2013-04-15 - ISSUE-21 Added ldp:membershipPredicateInverse to 5.2.5 &amp; 5.5.2, created 5.2.5.1 &amp; 5.3.5.2 to indicate difference. (SS)</li>
	<li>2013-04-15 - ISSUE-39 Moved informative text from 5.4.5 into 5.4.1, shifted subsections .6-.10 (SS)</li>
	<li>2013-04-15 - Expanded on wording for 4.3 to be more consistent (SS)</li>
	<li>2013-04-08 - Fixed two old references to BPR (SS)</li>
	<li>2013-03-17 - Inserted examples 2&amp;3, a more complete NetWorth resource (SS)</li>
	<li>2013-03-15 - Update LDPC glossary term based on Cody's feedback (SS)</li>
	<li>2013-03-15 - Additional fix in 5.2.2 for ISSUE-34 (SS)</li>
	<li>2013-03-15 - Remove reference to closed issues that don't require edits: ISSUE-27 & ISSUE-45 (SS)</li>
	<li>2013-03-14 - General prep for 3rd draft, cleanup and a little restructure (SS)</li>
</ul>

<blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130307/">Second Public Working Draft</a></em></blockquote>
<ul>
	<li>2013-03-14 - Fixed up broken fragments and typos before publication (SS)</li>
	<li>2013-03-04 - Comments received from David Wood: 5.3.7 & 5.1.3 clarity, other minor edits (part 2)  (SS)</li>
	<li>2013-03-04 - Comments received from David Wood: abstract, paging informative (part 1)  (SS)</li>
	<li>2013-03-04 - ISSUE-36 - Added informative text regarding creationg of containers in 5.4.4 (SS)</li>
 	<li>2013-03-04 - ISSUE-12 - Added section 4.7.3 not to allow PATCH for create (SS)</li>
	<li>2013-03-03 - Adjustments to language about different container behavior (SS)</li>
	<li>2013-03-02 - Adding trailing '/' on Container URLs to help with readability based on WG suggestion (SS)</li>
	<li>2013-02-26 - Updated Acknowledgements section (SS)</li>
	<li>2013-02-25 - ISSUE-29 - Use relative URIs in examples (SS)</li>
	<li>2013-02-25 - ISSUE-31 - Added a more complete conformance section, motived by SPARQL 1.1 (SS)</li>
	<li>2013-02-25 - Updating some simple formatting, reorganizing open issues and todos. (SS) </li>
	<li>2013-02-15 - ISSUE-34 - Aggregration: 5.6.1 and 5.6.2 updated for review. (JA) </li>
	<li>2013-02-13 - ISSUE-42 - 4.8 Common Properties moved to 
			<a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Re-use_established_linked_data_vocabularies_instead_of_.28re-.29inventing_duplicates">Deploment Guide</a> 
			(JA) </li>
	<li>2013-02-12 - Fixed up previous publication links (SS) </li>
	<li>2013-02-12 - ISSUE-10 - 4.1.12 to be MUST use entity tags (either weak or strong ones) (SS) </li>
	<li>2013-02-12 - ISSUE-11 - 4.4.1 Relaxed the MUST ignore dc:modified/creator to MAY (SS) </li>
	<li>2013-01-16 - ISSUE-25 Updated introduction. 5.2.2 changed to MUST NOT be in multiple containers. Flipped 5.6.1/2 as 
	first rule leads to 2nd. 5.6.2(was .1) Delete LDPC MUST also delete members. (SS)</li>
	<li>2013-01-16 - Added new issues ranging from 26-43. Removed closed/deferred issues: 2 &amp; 3 (SS)</li>
	<li>2012-12-28 - Fixed Typos.  Separated some compound rules like 4.1.5.  Rewording for clarity: 4.1.10, 
	Text being repeated in several places centralized and cross-linked.  Made printed code output easier to read
	on black &amp; white printers.  Exposed terms defined in-line under LDPC as Terminology (tentatively).  Removed non-normative
	qualifer from section 5.2.  Added "several" editors' to-dos.(JA)</li>
	<li>2012-11-05 - minor rewording from ISSUE-24</li>
	<li>2012-11-03 - ISSUE-22, ISSUE-23: changed sections 4.2.3 and 5.4.7. Removed closed issues. (SS)</li>
	<li>2012-11-03 - ISSUE-24 Delete the phrase in 4.5.1 that nays "until ...Request URI" 
	and adding a sentence, "Clients should note that servers may reuse a Request-URI under some circumstances."</li>
	<li>2012-11-03 - ISSUE-6 Removed section 4.1.9.  Shifted up sections .10 through .13.</li>
	<li>2012-11-01 - Fixed minor typo and added some notes (SS)</li>
</ul>

<blockquote><em><a href="http://www.w3.org/TR/2012/WD-ldp-20121025/">First Public Working Draft</a></em></blockquote>
<ul>
	<li>2012-10-15 - ISSUE-8 Changed references from LDBP to LDP, removed definition for "profile" and new namespace (SS)</li>	
	<li>2012-10-15 - Included additional open ISSUES from Oct 15 WG meeting: 22, 23, 24 (SS)</li>
	<li>2012-10-14 - Added open ISSUES and formating to prep for public working draft (SS)</li>
	<li>2012-09-20 - Sent pull request re LINKED-DATA and added suggestion for <code>ldp</code> namespace (SS)</li>
	<li>2012-09-19 - Repairing references and forward reference to biblio.js updates (SS)</li>
	<li>2012-09-19 - Fixed rdfs:label range to be rdfs:Literal (SS)</li>
	<li>2012-09-19 - ISSUE-1 Define Turtle as the required serialization format for LDP (SS)</li>
	<li>2012-09-18 - Initial ReSpec'ing of <a href="http://www.w3.org/Submission/ldbp/">Member Submission - Linked Data Basic Profile 1.0</a> (SS)</li>
	<li>2012-09-18 - Fixed up some links and worked on references, work left to do. (SS)</li>
</ul>
<blockquote><em><a href="http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/">Submission</a></em></blockquote>
</section>
    
  </body>
</html>