ldp.html
changeset 12 a3be44430b37
child 13 eea17080fdf2
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp.html	Mon Oct 15 20:35:14 2012 -0400
@@ -0,0 +1,1297 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>Linked Data Platform 1.0</title>
+    <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
+    <!-- 
+      === NOTA BENE ===
+      For the three scripts below, if your spec resides on dev.w3 you can check them
+      out in the same tree and use relative links so that they'll work offline,
+     -->
+    <script src='http://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",
+          // TODO: Confirm short name
+
+          // 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:  "2012-03-26",
+          previousMaturity:  	"Member-SUBM",
+          previousURI: 			"http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/",
+
+          // 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: "Michael Hausenblas", url: "http://mhausenblas.info/#i",
+	                company: "DERI, NUI Galway", companyURL: "http://deri.ie/" },
+          ],
+
+          // 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 {
+	    	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-title {
+    	    color: #E05252;
+    	    padding-right: 1em;
+            min-width: 7.5em;
+    	}
+    </style>
+  </head>
+<body>
+<section id='abstract'>
+A set of best practices and simple approach for a read-write Linked Data architecture, based on
+HTTP access to web resources that describe their state using RDF.
+</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 some
+	new rules as well as 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*, SPARQL)</p>
+	<p>4. Include links to other URIs. so that they can
+		discover more things</p>
+	<p>The best practices and
+		anti-patterns covered in this document are:</p>
+	<ul>
+		<li><p>
+			<em>Resources</em> - a summary of the
+				HTTP and RDF standard 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.
+			</p>
+		</li>
+		<li><p>
+			<em>Containers</em> - defines resources
+				that allow new resources to be created using HTTP POST and existing
+				resources to be found using HTTP GET. 
+			</p>
+		</li>
+	</ul>
+	<p>Additionally, it is the intention
+	of this document to enable additional rules and layered groupings of
+	rules, such 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 on 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]]</dd>
+							
+	<dt>Linked Data</dt>
+	<dd>As defined by Tim Berners-Lee. [[LINKED-DATA]]</dd>
+	
+	<dt>Linked Data Platform Resource (LDPR)</dt>
+	<dd>HTTP resource that conforms to the simple lifecycle
+		patterns and conventions in this document.</dd>
+		
+	<dt>Linked Data Platform Container (LDPC)</dt>
+	<dd>LDP	resource that also conforms to additional patterns and conventions in this
+		document for managing membership.</dd>
+		
+	<dt>Client</dt>
+	<dd>A program that establishes connections for the purpose of sending requests. [[HTTP11]]</dd>
+	
+	<dt>Server</dt>
+	<dd>An application
+		program that accepts connections in order to service requests by
+		sending back responses. 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]]</dd>
+  </dl>
+  
+  	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/8">ISSUE-8</a></div>
+	<em>CLOSED</em> Better define or just not use the "Basic profile" terminology
+	</div>
+  
+<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'></section>
+
+<section>
+<h1 id="ldpr">Linked Data Platform Resource</h1>
+	<p>Linked Data Platform Resources (LDPRs) 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>What literal value types should be used?</li>
+		<li>Are there some typical vocabularies that should be reused?</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>
+	</ul>
+	<p>The following sections define the rules and
+		guidelines for use of LDPRs.</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 subject
+		is typically the LDPR itself.
+	</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 Clients can access a LDPR using multiple
+			URLs, for example when DNS aliasing is used. A LDPR server MUST
+			respond to each of those requests using a single consistent URL, a
+			canonical URL, for the LDPR which may be found in the response's
+			Location header and potentially also in the representation of the
+			LDPR. Clients SHOULD use that canonical URL to identify the LDPR.
+	</div>
+	<div id="ldpr-4_1_5" class="rule">4.1.5 LDPR predicates SHOULD use standard vocabularies such as Dublin Core
+		[[!DC-TERMS]], RDF [[!RDF-PRIMER]] and RDF Schema [[!RDF-SCHEMA]], whenever
+		possible. LDPRs SHOULD reuse existing vocabularies instead of creating
+		their own duplicate vocabulary terms.
+	</div>
+	<div id="ldpr-4_1_6" class="rule">4.1.6 LDPR predicates MUST use well-known RDF vocabularies as defined in
+		section <a href="#ldpr-prop">4.8 Common Properties</a> wherever a predicate’s meaning matches
+		one of them.
+	</div>
+	<div id="ldpr-4_1_6_1" class="rule">4.1.6.1 LDPRs MUST use the predicate <code>rdf:type</code> to
+		represent the concept of type. The use of non-standard type
+		predicates, as well as <code>dcterms:type</code>, is
+		discouraged. [[!DC-RDF]]
+	</div>
+	<div id="ldpr-4_1_7" class="rule">4.1.7 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_8" class="rule">4.1.8 Predicate URIs used in LDPR representations SHOULD be HTTP URLs.
+		 These predicate URIs MUST identify LDPRs whose representations are
+		retrievable. LDPR servers SHOULD provide an RDF Schema [[!RDF-SCHEMA]]
+		representation of these predicates.
+		
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/9">ISSUE-9</a></div>
+	Should properties used in LDPR representations be LDPRs?
+	</div>
+	</div>
+
+	
+	<div id="ldpr-4_1_9" class="rule">4.1.9 LDPR representations MUST use only the following standard datatypes.
+		RDF does not by itself define datatypes to be used for literal
+		property values, therefore a set of standard datatypes based on [[!XMLSCHEMA11-2]] and [[!RDF-PRIMER]] are to be used: </div>
+		<table border="1" cellspacing="5" summary="Datatype to use with RDF literals">
+		<thead>
+		<tr><th>URI</th><th>Description</th></tr>
+		</thead>
+		<tbody>
+		<tr><td><code>http://www.w3.org/2001/XMLSchema#boolean</code></td><td>Boolean type as specified by XSD Boolean</td></tr>
+		<tr><td><code>http://www.w3.org/2001/XMLSchema#date</code></td><td>Date type as specified by XSD date</td></tr>
+		<tr><td><code>http://www.w3.org/2001/XMLSchema#dateTime</code></td><td>Date and Time type as specified
+			by XSD dateTime</td></tr>
+		<tr><td><code>http://www.w3.org/2001/XMLSchema#decimal</code></td><td>Decimal number type as specified
+			by XSD Decimal</td></tr>
+		<tr><td><code>http://www.w3.org/2001/XMLSchema#double</code></td><td>Double floating-point number type as
+		specified by XSD Double</td></tr>
+		<tr><td><code>http://www.w3.org/2001/XMLSchema#float</code></td><td>Floating-point number type as
+		specified by XSD Float</td></tr>
+		<tr><td><code>http://www.w3.org/2001/XMLSchema#integer</code></td><td>Integer number type as specified by
+		XSD Integer</td></tr>
+		<tr><td><code>http://www.w3.org/2001/XMLSchema#string</code></td><td>String type as specified by XSD String</td></tr>
+		<tr><td><code>http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral</code></td><td>Literal XML value as specified by RDF</td></tr>							
+	   </tbody>
+	  </table>
+	  
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/6">ISSUE-6</a></div>
+	Should LDBP say that any kind of user-defined simple data type is disallowed?
+	</div>
+
+	<div id="ldpr-4_1_10" class="rule">4.1.10 LDPRs MUST use at least one RDF triple to represent a link
+		(relationship) to another resource. In other words, having the source
+		resource’s URI as the subject and the target resource’s URI as the
+		object of the triple represent the link (relationship) is enough and
+		does not require the creation of an intermediate link resource to
+		describe the relationship.
+	</div>
+	<div id="ldpr-4_1_11" class="rule">4.1.11 LDPR servers MAY support additional standard representations. These
+		could be other RDF formats, like N3 or NTriples, but non-RDF formats
+		like HTML [[!HTML401]] and JSON [[!RFC4627]] would be likely be common.
+		
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/22">ISSUE-22</a></div>
+	Need to normatively reference and recommend JSON-LD
+	</div>		
+	</div>
+	<div id="ldpr-4_1_12" class="rule">4.1.12 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]]
+	</div>
+	<div id="ldpr-4_1_13" class="rule">4.1.13 LDPR server responses MUST contain accurate response <code>ETag</code>
+		header values.
+		
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/10">ISSUE-10</a></div>
+	Include clarifications and guidance around ETags
+	</div>
+	</div>
+	
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/2">ISSUE-2</a></div>
+	Do LDPR versions get managed in a systematic, discoverable way?
+	</div>
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/15">ISSUE-15</a></div>
+	sharing binary resources and metadata
+	</div>
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/16">ISSUE-16</a></div>
+	Redirection of non-information resources to LDPRs
+	</div>
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/19">ISSUE-19</a></div>
+	Adressing more error cases
+	</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 GET Method for LDPRs.
+	</div>
+	<div id="ldpr-4_2_2" class="rule">4.2.2 LDPR servers MUST provide an <code>text/turtle</code>
+		representation of the requested LDPR.[[!TURTLE]]
+	</div>
+	<div id="ldpr-4_2_3" class="rule">4.2.3 LDPR servers SHOULD provide a <code>application/rdf+xml</code>
+		representation of the requested LDPR.[[!RDF-SYNTAX]]
+		
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/23">ISSUE-23</a></div>
+	Remove application/rdf+xml as a SHOULD
+	</div>	
+	</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 may 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 may change over time.
+	</div>
+</section>
+
+<section>
+<h2 id="ldpr-HTTP_POST">HTTP POST</h2>
+	<p>There are no additional requirements on HTTP POST for LDPRs.</p>
+</section>
+
+<section>
+<h2 id="ldpr-HTTP_PUT">HTTP PUT</h2>
+		
+	<div id="ldpr-4_4_1" class="rule">4.4.1 If HTTP PUT 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. The only
+		recognized exception are the properties <code>dcterms:modified</code>
+		and <code>dcterms:creator</code> that are never under
+		client control - LDPR servers MUST ignore any values of these
+		properties that are provided by the client. 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
+		PATCH, not HTTP PUT.
+		
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/11">ISSUE-11</a></div>
+	Do we need to define server-managed properties or do we leave them to applications?
+	</div>
+	</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 if there are no other
+		errors with the request. [[!HTTP11]]
+	</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 its triples, and the set of predicates that
+		are used in the state of a 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 a 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 PUT to update the resource.
+	</div>
+	<div id="ldpr-4_4_5" class="rule">4.4.5 A LDPR client MUST preserve all triples retrieved using HTTP GET that
+		it doesn’t change whether it understands the predicates or not, when
+		its intent is to perform an update using HTTP PUT.  The use of HTTP
+		PATCH instead of HTTP PUT 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 PUT.
+	</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.  It is
+		common for LDPR servers to put restrictions on representations – for
+		example, the range of <code>rdf:type</code>, datatypes of
+		predicates and number of occurrences of predicates in triples, but
+		servers SHOULD minimize those restrictions.  In other words, LDPR
+		servers need to enable simple modification of LDPRs. Enforcement of
+		more complex constraints will greatly restrict the types of clients
+		that can modify resources. For some server applications, excessive
+		constraints on modification of resources may be required.
+	</div>		
+</section>
+		
+<section>
+<h2 id="ldpr-HTTP_DELETE">HTTP DELETE</h2>
+	<div id="ldpr-4_5_1" class="rule">4.5.1 LDPR servers MUST remove the resource identified by the Request-URI.
+		After a successful HTTP DELETE, a subsequent HTTP GET on the same
+		Request-URI MUST result in a 404 (Not found) or 410 (Gone) status
+		code, until another resource is created or associated with the same
+		Request-URI.
+	</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 DELETE 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>
+	
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/24">ISSUE-24</a></div>
+	Should DELETED resources remain deleted?
+	</div>
+</section>
+
+<section>
+<h2 id="ldpr-HTTP_HEAD">HTTP HEAD</h2>
+	<div id="ldpr-4_6_1" class="rule">4.6.1 LDPR servers MUST support the HTTP HEAD method.</div>
+	<div id="ldpr-4_6_2" class="rule">4.6.2 LDPR servers MUST indicate their support for HTTP Methods by
+		responding to a HTTP HEAD 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-HTTP_PATCH">HTTP PATCH</h2>
+	<div id="ldpr-4_7_1" class="rule">4.7.1 LDPR servers MAY implement HTTP PATCH 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.  It is
+		common for LDPR servers to put restrictions on representations – for
+		example, the range of <code>rdf:type</code>, datatypes of
+		predicates and number of occurrences of predicates in triples – but
+		server enforcement of detailed, domain-specific constraints will
+		greatly restrict the types of clients who can update resources.
+	</div>
+	
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/12">ISSUE-12</a></div>
+	Can HTTP PATCH be used for resource creation?
+	</div>
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/17">ISSUE-17</a></div>
+	changesets as a recommended PATCH format
+	</div>
+</section>
+
+<section>
+<h2 id="ldpr-prop">Common Properties</h2>
+	<p>
+		This section summarizes some well-known RDF vocabularies that MUST be
+		used in Linked Data Platform Resources wherever a resource needs to use a
+		predicate whose meaning matches one of these. For example, if a BP
+		resource has a <em>description</em>, and the application semantic of that
+		<em>description</em> is compatible with <code>dcterms:description</code>,
+		then <code>dcterms:description</code> MUST be used. If
+		needed, additional application-specific predicates MAY be used. A
+		specification for a domain that is based on BP may require one or
+		more of these properties for a particular resource type. The Range
+		column in the tables below identify the RECOMMENDED <code>rdfs:range</code>
+		for the properties.
+	</p>
+	<div id="ldpr-4_8_1" class="rule">4.8.1 From Dublin Core</div>
+	<p>
+		URI: <code>http://purl.org/dc/terms/</code>
+	</p>
+	<table border="1" cellspacing="5" summary="Dublin Core properties recommended">
+		<tr>
+			<td>Property</td>
+			<td>Range/DataType</td>
+			<td>Comment</td>
+		</tr>
+		<tr>
+			<td><code>dcterms:contributor</code></td>
+			<td><code>dcterms:Agent</code></td>
+			<td></td>
+		</tr>
+		<tr>
+			<td><code>dcterms:creator</code></td>
+			<td><code>dcterms:Agent</code></td>
+			<td></td>
+		</tr>
+		<tr>
+			<td><code>dcterms:created</code></td>
+			<td><code>xsd:dateTime</code></td>
+			<td></td>
+		</tr>
+		<tr>
+			<td><code>dcterms:description</code></td>
+			<td><code>rdf:XMLLiteral</code></td>
+			<td>
+					Descriptive text about the resource represented as rich text in
+					XHTML format. SHOULD include only content that is valid and suitable inside an XHTML
+					<code>&lt;div&gt;</code> element.
+			</td>
+		</tr>
+		<tr>
+			<td><code>dcterms:identifier</code></td>
+			<td><code>rdfs:Literal</code></td>
+			<td></td>
+		</tr>
+		<tr>
+			<td><code>dcterms:modified</code></td>
+			<td><code>xsd:dateTime</code></td>
+			<td></td>
+		</tr>
+		<tr>
+			<td><code>dcterms:relation</code></td>
+			<td><code>rdfs:Resource</code></td>
+			<td>The HTTP URI of a related resource. This is the
+					predicate to use when you don't know what else to use. If you know
+					more specifically what sort of relationship it is, use a more
+					specific predicate.</td>
+		</tr>
+		<tr>
+			<td><code>dcterms:subject</code></td>
+			<td><code>rdfs:Resource</code></td>
+			<td></td>
+		</tr>
+		<tr>
+			<td><code>dcterms:title</code></td>
+			<td><code>rdf:XMLLiteral</code></td>
+			<td>A name given to the resource. Represented as rich text in XHTML
+					format. SHOULD include only content that is valid inside an XHTML <code>&lt;span&gt;</code>
+					element.</td>
+		</tr>
+	</table>
+
+	<p>
+		The predicate <code>dcterms:type</code> SHOULD NOT be
+		used, instead use <code>rdf:type</code>. [[!DC-RDF]].
+	</p>
+	
+	<div id="ldpr-4_8_2" class="rule">4.8.2 From RDF</div>
+	<p>
+		URI: <code>http://www.w3.org/1999/02/22-rdf-syntax-ns#</code>
+	</p>
+	<table border="1" cellspacing="5" summary="RDF properties recommended">
+		<tr>
+			<td>Property</td>
+			<td>Range</td>
+			<td>Comment</td>
+		</tr>
+		<tr>
+			<td><code>rdf:type</code></td>
+			<td><code>rdfs:Class</code></td>
+			<td>The type or types of the resource</td>
+		</tr>
+	</table>
+	
+	<div id="ldpr-4_8_3" class="rule">4.8.3 From RDF Schema</div>
+	<p>
+		URI: <code>http://www.w3.org/2000/01/rdf-schema#</code>
+	</p>
+	
+	
+	<table border="1" cellspacing="5" summary="RDF Schema properties recommended">
+		<tr>
+			<td>Property</td>
+			<td>Range</td>
+			<td>Comment</td>
+		</tr>
+		<tr>
+			<td><code>rdfs:member</code></td>
+			<td><code>rdfs:Resource</code></td>
+			<td></td>
+		</tr>
+		<tr>
+			<td><code>rdfs:label</code></td>
+			<td><code>rdfs:Literal</code></td>
+			<td>Only use this in vocabulary documents, to define
+					the name of the vocabulary term.</td>
+		</tr>
+	</table>		
+</section>
+</section>
+
+<section>
+<h1 id="ldpc">Linked Data Platform Container</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	do I GET the entries of a large container broken up into pages?</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. This document also explains how to include
+		information about each member in the container’s own representation
+		and how to paginate the container representation if it gets too big.</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;http://example.org/container1&gt;
+   a ldp:Container;
+   dcterms:title "A very simple container";
+   rdfs:member
+      &lt;http://example.org/container1/member1&gt;,
+      &lt;http://example.org/container1/member2&gt;,
+      &lt;http://example.org/container1/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, as illustrated
+			below.</p>
+
+<pre class="example">
+# The following is the representation of
+#   http://example.org/netWorth/nw1/assetContainer
+@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
+@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+@prefix o: &lt;http://example.org/ontology/&gt;.
+
+&lt;http://example.org/netWorth/nw1/assetContainer&gt;
+   a ldp:Container;
+   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
+   ldp:membershipPredicate o:asset.
+
+&lt;http://example.org/netWorth/nw1&gt;
+   a o:NetWorth;
+   o:asset
+      &lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;,
+      &lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;.</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 predicate is <code>o:asset</code> – a predicate from the domain model. A POST to
+			this 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 we didn’t just make <code>http://example.org/netWorth/nw1</code> a container and POST
+			the new asset directly there. That would be a fine design if <code>http://example.org/netWorth/nw1</code> had only assets, but if it has separate
+			predicates for assets and liabilities, that design will not work
+			because it is unspecified to which predicate the POST should add a
+			membership triple. Having separate <code>http://example.org/netWorth/nw1/assetContainer</code> and <code>http://example.org/netWorth/nw1/liabilityContainer</code> container resources allows both assets and
+			liabilities to be created.
+	</p>
+	<p>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">5.1.1 Container Member Information</div>
+	<em>This section is non-normative</em>
+	<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 rdfs:    &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
+@prefix ldp:      &lt;http://www.w3.org/ns/ldp#&gt;.
+@prefix o:       &lt;http://example.org/ontology/&gt;.
+
+&lt;http://example.org/netWorth/nw1/assetContainer&gt;
+   a ldp:Container;
+   dcterms:title "The assets of JohnZSmith";
+   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
+   ldp:membershipPredicate o:asset.
+
+&lt;http://example.org/netWorth/nw1&gt;
+   a o:NetWorth;
+   o:asset
+      &lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;,
+      &lt;http://example.org/netWorth/nw1/assetContainer/a3&gt;,
+      &lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;.
+
+&lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;
+   a o:Stock;
+   o:value 10000.
+&lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;
+   a o:Bond;
+   o:value 20000.
+&lt;http://example.org/netWorth/nw1/assetContainer/a3&gt;
+   a o:RealEstateHolding;
+   o:value 300000.</pre>
+
+	<div id="ldpc-get_non-member_props" class="rule">5.1.2 Retrieving Only Non-member Properties
+	</div>
+	<em>This section is non-normative</em>
+	<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 “non-member resource”, 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>
+		and adding the query string <code>?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; chartset=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:membershipPredicate rdfs:member;
+   dcterms:publisher &lt;http://acme.com/&gt;.</pre>
+
+	<div id="ldpc-paging" class="rule">5.1.3 Paging</div>
+	<em>This section is non-normative</em>
+	<p>It sometimes happens that a
+		container is too large to reasonably transmit its representation in a
+		single HTTP response. This will be especially true if the container
+		representation includes many triples from the representations of its
+		members. A client may anticipate that a container 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 may recognize that a container that has been
+		requested is too big to return in a single message.</p>
+	<p>
+		To address this problem, LDPCs may support a technique called Paging.  Paging can be achieved with a
+		simple RDF pattern. For each container resource, <code>&lt;containerURL&gt;</code>, we define a new
+		resource <code>&lt;containerURL&gt;?firstPage</code>.
+		The triples in the representation of <code>&lt;containerURL&gt;?firstPage</code>
+		are a subset of the triples in <code>&lt;containerURL&gt;</code>
+		- same subject, predicate and object.
+	</p>
+	<p>LDPC servers may respond to requests for a
+		container by redirecting the client to the first page resource –
+		using a 303 “See Other” redirect to the actual URL for the page
+		resource.</p>
+	<p>
+		Continuing on from the member information from the JohnZSmith net
+		worth example, we’ll split the response across two pages.  The client
+		requests the first page as <code>http://example.org/netWorth/nw1/assetContainer?firstPage</code>:
+	</p>
+<pre class="example"># The following is the representation of
+#    http://example.org/netWorth/nw1/assetContainer?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 ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+@prefix o: &lt;http://example.org/ontology/&gt;.
+
+&lt;http://example.org/netWorth/nw1/assetContainer&gt;
+   a ldp:Container;
+   dcterms:title "The assets of JohnZSmith";
+   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
+   ldp:membershipPredicate o:asset.
+
+&lt;http://example.org/netWorth/nw1/assetContainer?firstPage&gt;
+   a ldp:Page;
+   ldp:pageOf &lt;http://example.org/netWorth/nw1/assetContainer&gt;;
+   ldp:nextPage &lt;http://example.org/netWorth/nw1/assetContainer?p=2&gt;.
+ 
+&lt;http://example.org/netWorth/nw1&gt;
+    a o:NetWorth;
+	o:asset
+	&lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;,
+	&lt;http://example.org/netWorth/nw1/assetContainer/a4&gt;,
+	&lt;http://example.org/netWorth/nw1/assetContainer/a3&gt;,
+	&lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;.
+
+&lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;
+   a o:Stock;
+   o:value 100.00.
+&lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;
+   a o:Cash;
+   o:value 50.00.
+# server initially supplied no data for a3 and a4 in this response</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/netWorth/nw1/assetContainer?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 ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+@prefix o: &lt;http://example.org/ontology/&gt;.
+
+&lt;http://example.org/netWorth/nw1/assetContainer&gt;
+   a ldp:Container;
+   dcterms:title "The assets of JohnZSmith";
+   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
+   ldp:membershipPredicate o:asset.
+
+&lt;http://example.org/netWorth/nw1/assetContainer?p=2&gt;
+   a ldp:Page;
+   ldp:pageOf &lt;http://example.org/netWorth/nw1/assetContainer&gt;;
+   ldp:nextPage rdf:nil.
+
+&lt;http://example.org/netWorth/nw1&gt;
+   a o:NetWorth;
+   o:asset 
+      &lt;http://example.org/netWorth/nw1/assetContainer/a5&gt;.
+
+&lt;http://example.org/netWorth/nw1/assetContainer/a5&gt;
+   a o:Stock;
+   dcterms:title "Big Co.";
+   o:value 200.02.</pre>
+
+	<p>
+		In this example, there is only one member in the container 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>
+	<p>LDPC guarantees that any and all the triples
+		about the members will be on the same page as the membership triple
+		for the member.</p>
+		
+	<div id="ldpc-ordering" class="rule">5.1.4 Ordering</div>
+	<em>This section is non-normative</em>
+	<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 only becomes important for LDPC servers when containers are
+		paginated. If the server does not respect ordering when constructing
+		pages, the client is forced to retrieve all pages before
+		sorting the members, which would defeat the purpose of pagination. In
+		cases where ordering is important, a LDPC server exposes all the
+		members on a page with a higher sort order than all members on the
+		previous page and lower sort order than all the members on the next
+		page. The LDPC specification provides a predicate - <code>ldp:containerSortPredicates</code>
+		- that the server may use to communicate to the client which
+		predicates were used for page ordering. Multiple predicate values may
+		have been used for sorting, so the value of this predicate is an
+		ordered list.
+	</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 rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
+@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
+@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+@prefix o: &lt;http://example.org/ontology/&gt;.
+
+&lt;http://example.org/netWorth/nw1/assetContainer&gt;
+   a ldp:Container;
+   dcterms:title "The assets of JohnZSmith";
+   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
+   ldp:membershipPredicate o:asset.
+
+&lt;http://example.org/netWorth/nw1/assetContainer?firstPage&gt;
+   a ldp:Page;
+   ldp:pageOf &lt;http://example.org/netWorth/nw1/assetContainer&gt;;
+   ldp:containerSortPredicates (o:value).
+
+&lt;http://example.org/netWorth/nw1&gt;
+   a o:NetWorth;
+   o:asset
+      &lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;,
+      &lt;http://example.org/netWorth/nw1/assetContainer/a3&gt;,
+      &lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;.
+
+&lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;
+   a o:Stock;
+   o:value 100.00.
+&lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;
+   a o:Cash;
+   o:value 50.00.
+&lt;http://example.org/netWorth/nw1/assetContainer/a3&gt;
+   a o:RealEstateHolding;
+   o:value 300000.</pre>
+		<p>
+			As you can see by the addition of the <code>ldp:containerSortPredicates</code> 
+			predicate, the <code>o:value</code> predicate is used
+			to define the ordering of the results.  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 class="informative">
+<h2 id="ldpc-general">General</h2>
+	<div id="ldpc-5_2_1" class="rule">5.2.1 LDPC servers MUST also be conformant LDPR servers. A Linked Data Platform
+		Container is a resource that is a Linked Data Platform Resource.
+	</div>
+	<div id="ldpc-5_2_2" class="rule">5.2.2 The same resource MAY be a member of multiple LDPCs. This happens
+		commonly if one container is a view onto a larger container.
+	</div>
+	<div id="ldpc-5_2_3" class="rule">5.2.3 The representation of a LDPC includes information about which
+		resources are its members. The set of members of a container is 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. If there is no obvious
+		predicate from the server application vocabulary to use, LDPC servers
+		SHOULD use the <code>rdfs:member</code> predicate.
+		
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/21">ISSUE-21</a></div>
+	container affordances
+	</div>	
+	</div>
+	<div id="ldpc-5_2_4" class="rule">5.2.4 A LDPC MUST contain one triple for the <code>ldp:membershipSubject</code>
+		predicate that indicates the subject of the membership triples when container subject is not the LDPC itself.
+	</div>
+	<div id="ldpc-5_2_5" class="rule">5.2.5 A LDPC MUST contain one triple for the <code>ldp:membershipPredicate</code>
+		predicate that indicates the predicate of the membership triple when
+		the container predicate is not <code>rdfs:member</code>.
+	</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 GET
+		on each member individually.  See section <a href="#ldpc-member_data">5.1.1 Container
+		Member Information</a> for additional details.
+		
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/13">ISSUE-13</a></div>
+	Include clarifications about LDPC representations that include member triples
+	</div>
+	</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 LDPCs SHOULD NOT use RDF container types <code>rdf:Bag</code>,
+		<code>rdf:Seq</code> and <code>rdf:List</code>.
+	</div>
+	
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/3">ISSUE-3</a></div>
+	Do LDPC versions get managed in a systematic, discoverable way?
+	</div>
+</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 example above).  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 SHOULD support requests for information about a known LDPC
+		without retrieving a full representation including all of its
+		members, by the existence of the token "<code>non-member-properties</code>" on the query
+		component of the LDPC URL.  For example, if there is a LDPC URL <code>&lt;containerURL&gt;,</code> the URL to request the
+		non-membership properties would be <code>&lt;containerURL&gt;?non-member-properties</code>.
+		 See section <a href="#ldpc-get_non_member_props">5.1.2 Retrieving Non-member Properties</a> for
+		additional details. A LDPC server that does not support a request to
+		retrieve non-member resource properties via a Request-URI of “<code>&lt;containerURL&gt;?non-member-properties</code>”,
+		MUST return a HTTP status code 404 (Not Found).
+	</div>
+	<div id="ldpc-5_3_3" class="rule">5.3.3 A LDPC server that does not support a request to retrieve the first
+		page resource representation via a known LDPC as “<code>&lt;containerURL&gt;</code>”,
+		the Request-URI of “<code>&lt;containerURL&gt;?firstPage</code>”, MUST return a HTTP status code 404 (Not
+		Found).
+	</div>
+	<div id="ldpc-5_3_4" class="rule">5.3.4 LDPC servers SHOULD support requests for splitting large LDPCs into
+		pages indicated by a client supplying the token “<code>firstPage</code>”
+		on the query component of the LDPC URL. For example, if there is a LDPC
+		URL <code>&lt;containerURL&gt;</code>, the URL to request
+		the first page would be <code>&lt;containerURL&gt;?firstPage</code>.
+		The representation for any page, including the first, will include
+		the URL for the next page. See section <a href="#ldpc-paging">5.1.3 titled “Paging”</a> for additional details.
+	</div>
+	<div id="ldpc-5_3_5" class="rule">5.3.5 LDPC servers MAY split the response representation of a LDPC regardless
+		of what the client requested (such as when a client omits a “<code>firstPage</code>”
+		query component of a request URL). This is also known as
+		server-initiated paging. See section  <a href="#ldpc-paging">5.1.3 Paging</a> for
+		additional details.
+	</div>
+	<div id="ldpc-5_3_5_1" class="rule">5.3.5.1 LDPC servers that initiate paging SHOULD respond to requests for a LDPC
+		by redirecting the client to the page resource – using a 303 “See
+		Other” redirect to the actual URL for the page resource.
+	</div>
+	<div id="ldpc-5_3_6" class="rule">5.3.6 LDPC servers that support paging MUST include in the page
+		representation a representation for the LDPC, such that:
+	</div>
+	<div id="ldpc-5_3_6_1" class="rule">5.3.6.1 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 container it is paging,
+		whose  subject is the URL of the page, predicate is <code>ldp:pageOf,</code>
+		and object is the URL of the LDPC.
+	</div>
+	<div id="ldpc-5_3_6_2" class="rule">5.3.6.2 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="ldpc-5_3_6_3" class="rule">5.3.6.3 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>
+	
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/18">ISSUE-18</a></div>
+	container membership and robust pagination
+	</div>	
+	
+	<div id="ldpc-5_3_7" class="rule">5.3.7 LDPC servers MAY represent the members of a paged LDPC in a sequential
+		order.  The order MUST be specified using the <code>ldp:containerSortPredicates</code>
+		predicate whose subject is that of the page and object is a list of
+		LDPC ordinal predicates.  The default ordering is ascending. The only
+		ordinal predicate literal data types supported are those as defined
+		by SPARQL SELECT’s ORDER BY clause [[!SPARQL-QUERY]].
+		
+			<div class="ldp-issue">
+	<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
+	</div>
+	</div>
+	<div id="ldpc-5_3_7_1" class="rule">5.3.7.1 The object of <code>ldp:containerSortPredicates</code>’,
+		the predicate used to indicate ordering, MUST NOT change between
+		subsequent pages. If it does, ordering among members of a container
+		across pages is undefined. See section <a href="#ldpc-ordering">5.1.4 Ordering</a> for
+		additional details.
+	</div>
+	<p>The Linked Data Platform does not define how clients
+		discover LDPCs.</p>
+</section>
+
+<section>
+<h2 id="ldpc-HTTP_POST">HTTP POST</h2>
+	<div id="ldpc-5_4_1" class="rule">5.4.1 LDPC clients SHOULD create resources by submitting a representation as
+		the entity body of the HTTP POST to a known LDPC. LDPC servers MUST
+		respond with status code 201 (Created) and the <code>Location</code>
+		header set to the new resource’s URL.
+	</div>
+	<div id="ldpc-5_4_2" class="rule">5.4.2 After a successful HTTP POST 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. A 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 POST of non-RDF representations for
+		creation of any kind of resource, for example binary resources.
+	</div>
+	<div id="ldpc-5_4_4" class="rule">5.4.4 For servers that support create, LDPC servers MUST create a LDPR from a
+		RDF representation in the request entity body.
+	</div>
+	<div id="ldpc-5_4_5" class="rule">5.4.5 LDPC servers SHOULD NOT include the representation of the created
+		resource in the entity body of a 201 (Created) response. In other
+		words, clients should not expect any representation in the response
+		entity body on a 201 (Created) response.
+	</div>
+	<div id="ldpc-5_4_6" class="rule">5.4.6 For LDPCs, servers MUST accept a request entity body with a content
+		type of <code>text/turtle</code> [[!TURTLE]].
+	</div>
+	<div id="ldpc-5_4_7" class="rule">5.4.7 For LDPCs, LDPR servers SHOULD accept a request with an entity body
+		content type of <code>application/rdf+xml</code> [[!RDF-SYNTAX]].
+	</div>
+	<div id="ldpc-5_4_8" class="rule">5.4.8 For 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 class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/20">ISSUE-20</a></div>
+	Identifying and naming POSTed resources
+	</div>	
+	</div>
+	<div id="ldpc-5_4_9" class="rule">5.4.9 LDPC servers SHOULD assign the subject URI for the resource to be
+		created using server application specific rules.
+	</div>
+	<div id="ldpc-5_4_10" class="rule">5.4.10 LDPC servers SHOULD allow clients to create new resources without
+		requiring detailed knowledge of application-specific constraints.
+		 Some LDPC servers put restrictions on representations – for example,
+		the range of <code>rdf:type</code>, datatypes of
+		predicates and number of occurrences of predicates in triples - but
+		server enforcement of detailed, domain-specific constraints will
+		greatly restrict the types of clients that can create resources and
+		therefore discouraged.
+	</div>
+</section>
+
+<section>
+<h2 id="ldpc-HTTP_PUT">HTTP PUT</h2>
+	<div id="ldpc-5_5_1" class="rule">5.5.1 LDPC servers SHOULD NOT allow HTTP PUT to update a LDPC’s members and
+		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 PUT on <code>&lt;containerURL&gt;?non-member-properties</code>, which
+		MAY exclude server managed properties such as <code>ldp:membershipSubject</code> and <code>ldp:membershipPredicate</code>.
+	</div>
+</section>
+
+<section>
+<h2 id="ldpc-HTTP_DELETE">HTTP DELETE</h2>
+	<div id="ldpc-5_6_1" class="rule">5.6.1 If a LDPC server supports deletion of the LDPC, the server MAY also
+		delete the resources that are referenced as its contents.
+	</div>
+	<div id="ldpc-5_6_2" class="rule">5.6.2 When a resource that is contained in a LDPC (for example referenced by
+		a membership triple) is deleted, the server MUST also remove it from
+		the LDPC that was used to create it and SHOULD remove it from any
+		other containers that reference it that the server manages and
+		persists.
+	</div>
+</section>
+
+<section>
+<h2 id="ldpc-HTTP_HEAD">HTTP HEAD</h2>
+	<p>There are no additional requirements on HTTP
+		HEAD.</p>
+</section>
+
+<section>
+<h2 id="ldpc-HTTP_PATCH">HTTP PATCH</h2>
+	<div id="ldpc-5_8_1" class="rule">5.8.1 LDPC servers are RECOMMENDED to support HTTP PATCH as the preferred
+		method for updating LDPC non-membership properties.
+	</div>
+</section>
+
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/7">ISSUE-7</a></div>
+	What operations are permittered on containers and how do they get invoked?
+	</div>
+</section>
+
+<section class='appendix informative'>
+<h2>Acknowledgements</h2>
+     
+  <p>The following people have been instrumental in providing thoughts, feedback,
+reviews, criticism and input in the creation of this specification:</p>
+
+  <ul>
+	<li>Martin P. Nally</li>
+	<li>John Arwe</li>
+	<li>Arnaud le Hors</li>
+   </ul>
+</section>
+    
+<section class='appendix informative' id="history">
+<h1>Change History</h1>
+<ul>
+	<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>
+	<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-20 - Sent pull request re LINKED-DATA and added suggestion for <code>ldp</code> namespace (SS)</li>
+	<li>2012-10-14 - Added open ISSUES and formating to prep for public working draft (SS)</li>
+	<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>
+</ul></section>
+
+<section class='appendix informative' id="todos">
+<h1>Editor Todos and Notes</h1>
+<p>Other than LDP <a href="http://www.w3.org/2012/ldp/track/actions">open actions</a> and <a href="http://www.w3.org/2012/ldp/track/issues">issues</a>, included here are transient tasks and notes
+editors use.  They have not meaning in final product of a published working draft and will be removed prior to publishing.</p>
+<ul>
+	<li>None</li>
+</ul>
+
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/5">ISSUE-5</a></div>
+	Add a section explaining how LDBP is related to Graph Store Protocol
+	</div>
+</section>
+    
+  </body>
+</html>