Initial ReSpec'ing of <a href=http://www.w3.org/Submission/ldbp/>Member Submission - Linked Data Basic Profile 1.0
authorsspeiche
Tue, 18 Sep 2012 13:35:33 -0400
changeset 0 4cfc0550d48a
child 1 e85114c63951
Initial ReSpec'ing of <a href=http://www.w3.org/Submission/ldbp/>Member Submission - Linked Data Basic Profile 1.0
ldp.html
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp.html	Tue Sep 18 13:35:33 2012 -0400
@@ -0,0 +1,1359 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>Linked Data Basic Profile 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:            "ldbp",
+          // 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:  "SUBM",
+
+          // if there a publicly available Editor's Draft, this is the link
+          edDraftURI:           "https://dvcs.w3.org/hg/ldpwg/ldbp.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/" },
+          ],
+
+          // 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",
+      };
+    </script>
+    <style type="text/css">
+    div.rule {padding-top: 1em;}
+    </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 [4Rules]</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 profiles.  The scope is intentionally
+	narrow to provide a set of key rules for reading and writing Linked
+	Data that most, if not all, other profiles 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 [RFC2616] 
+</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. [4Rules]</dd>
+	
+	<dt>Profile</dt>
+	<dd>A specification that defines the needed components from other specifications as
+		well as providing additional clarifications as needed.</dd>
+	
+	<dt>Basic Profile Resource	(BPR)</dt>
+	<dd>HTTP resource that conforms to the simple lifecycle
+		patterns and conventions in this document.</dd>
+		
+	<dt>Basic Profile Container (BPC)</dt>
+	<dd>BPR	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. [RFC2616]</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.
+		[RFC2616]</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 bp:      &lt;http://open-services.net/ns/basicProfile#&gt;.
+	@prefix xsd:     &lt;http://www.w3.org/2001/XMLSchema#&gt;.</pre>
+</section>
+</section>
+    
+<section id='conformance'></section>
+
+<section>
+<h1 id="bpr">Basic Profile Resource</h1>
+	<p>Basic Profile Resources (BPRs) are HTTP resources
+		that conform to the simple patterns and conventions in this section.
+		HTTP requests to access, modify, create or delete BPRs are accepted
+		and processed by BPR servers. Most BPRs 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 [4Rules],
+		others address additional needs.</p>
+	<p>The rules for Basic Profile 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 BPRs.</p>
+
+<section>
+<h2 id="bpr-general">General</h2>
+		
+	<div id="bpr-4_1_1" class="rule">4.1.1 BPR servers MUST at least be HTTP/1.1 conformant servers [RFC2616].</div>
+	<div id="bpr-4_1_2" class="rule">4.1.2 BPR servers MUST provide an RDF representation for BPRs. The subject
+		is typically the BPR itself.
+	</div>
+	<div id="bpr-4_1_3" class="rule">4.1.3 BPR servers MAY host a mixture of BPRs and non-BPRs. For example, it
+		is common for BPR servers to need to host binary or text resources
+		that do not have useful RDF representations.
+	</div>
+	<div id="bpr-4_1_4" class="rule">4.1.4 Clients can access a BPR using multiple
+			URLs, for example when DNS aliasing is used. A BPR server MUST
+			respond to each of those requests using a single consistent URL, a
+			canonical URL, for the BPR which may be found in the response's
+			Location header and potentially also in the representation of the
+			BPR. Clients SHOULD use that canonical URL to identify the BPR.
+	</div>
+	<div id="bpr-4_1_5" class="rule">4.1.5 BPR predicates SHOULD use standard vocabularies such as Dublin Core
+		[Dublin Core], RDF [RDF] and RDF Schema [RDF Schema], whenever
+		possible. BPRs SHOULD reuse existing vocabularies instead of creating
+		their own duplicate vocabulary terms.
+	</div>
+	<div id="bpr-4_1_6" class="rule">4.1.6 BPR predicates MUST use well-known RDF vocabularies as defined in
+		section <a href="#bpr-prop">4.8 Common Properties</a> wherever a predicate’s meaning matches
+		one of them.
+	</div>
+	<div id="bpr-4_1_6_1" class="rule">4.1.6.1 BPRs 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="bpr-4_1_7" class="rule">4.1.7 BPR 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="bpr-4_1_8" class="rule">4.1.8 Predicate URIs used in BPR representations SHOULD be HTTP URLs.
+		 These predicate URIs MUST identify BPRs whose representations are
+		retrievable. BPR servers SHOULD provide an RDF Schema [RDF Schema]
+		representation of these predicates.
+	</div>
+	<div id="bpr-4_1_9" class="rule">4.1.9 BPR 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 [XSD
+		Datatypes] and [RDF] 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>
+	<div id="bpr-4_1_10" class="rule">4.1.10 BPRs 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="bpr-4_1_11" class="rule">4.1.11 BPR servers MAY support additional standard representations. These
+		could be other RDF formats, like N3 or NTriples, but non-RDF formats
+		like HTML and JSON would be likely be common.
+	</div>
+	<div id="bpr-4_1_12" class="rule">4.1.12 BPRs 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="bpr-4_1_13" class="rule">4.1.13 BPR server responses MUST contain accurate response <code>ETag</code>
+		header values.
+	</div>
+</section>
+
+<section>
+<h2 id="bpr-HTTP_GET">HTTP GET</h2>
+	<div id="bpr-4_2_1" class="rule">4.2.1 BPR servers MUST support the HTTP GET Method for BPRs.
+	</div>
+	<div id="bpr-4_2_2" class="rule">4.2.2 BPR servers MUST provide an <code>application/rdf+xml</code>
+		representation of the requested BPR.
+	</div>
+	<div id="bpr-4_2_3" class="rule">4.2.3 BPR servers SHOULD provide a <code>text/turtle</code>
+		representation of the requested BPR.
+	</div>
+	<div id="bpr-4_2_4" class="rule">4.2.4 In the absence of special knowledge of the application or domain, BPR
+		clients MUST assume that any BPR may have multiple values for <code>rdf:type</code>.
+	</div>
+	<div id="bpr-4_2_5" class="rule">4.2.5 In the absence of special knowledge of the application or domain, BPR
+		clients MUST assume that the <code>rdf:type</code> values
+		of a given BPR may change over time.
+	</div>
+</section>
+
+<section>
+<h2 id="bpr-HTTP_POST">HTTP POST</h2>
+	<p>There are no additional requirements on HTTP POST for BPRs.</p>
+</section>
+
+<section>
+<h2 id="bpr-HTTP_PUT">HTTP PUT</h2>
+		
+	<div id="bpr-4_4_1" class="rule">4.4.1 If HTTP PUT is performed on an existing resource, BPR 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 - BPR servers MUST ignore any values of these
+		properties that are provided by the client. Any BPR 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>
+	<div id="bpr-4_4_2" class="rule">4.4.2 BPR 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. BPR servers SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
+		to detect collisions. BPR 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. [RFC2616]
+	</div>
+	<div id="bpr-4_4_3" class="rule">4.4.3 BPR 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="bpr-4_4_4" class="rule">4.4.4 BPR clients SHOULD assume that a BPR server could discard triples
+		whose predicates the server does not recognize or otherwise chooses
+		not to persist. In other words, BPR servers MAY restrict themselves
+		to a known set of predicates, but BPR 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="bpr-4_4_5" class="rule">4.4.5 A BPR 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="bpr-4_4_6" class="rule">4.4.6 BPR servers MAY choose to allow the creation of new resources using HTTP PUT.
+	</div>
+	<div id="bpr-4_4_7" class="rule">4.4.7 BPR servers SHOULD allow clients to update resources without
+		requiring detailed knowledge of server-specific constraints.  It is
+		common for BPR 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, BPR
+		servers need to enable simple modification of BPRs. 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="bpr-HTTP_DELETE">HTTP DELETE</h2>
+	<div id="bpr-4_5_1" class="rule">4.5.1 BPR 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="bpr-4_5_2" class="rule">4.5.2 BPR 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 BPR servers to
+		not do this – behavior is server application specific.
+	</div>
+</section>
+
+<section>
+<h2 id="bpr-HTTP_HEAD">HTTP HEAD</h2>
+	<div id="bpr-4_6_1" class="rule">4.6.1 BPR servers MUST support the HTTP HEAD method.</div>
+	<div id="bpr-4_6_2" class="rule">4.6.2 BPR servers MUST indicate their support for HTTP Methods by
+		responding to a HTTP HEAD request on the BPR’s URL with the HTTP
+		Method tokens in the HTTP response header “<code>Allow</code>”.
+	</div>
+</section>
+
+<section>
+<h2 id="bpr-HTTP_PATCH">HTTP PATCH</h2>
+	<div id="bpr-4_7_1" class="rule">4.7.1 BPR 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="bpr-4_7_2" class="rule">4.7.2 BPR servers SHOULD allow clients to update resources without
+		requiring detailed knowledge of server-specific constraints.  It is
+		common for BPR 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>
+</section>
+
+<section>
+<h2 id="bpr-prop">Common Properties</h2>
+	<p>
+		This section summarizes some well-known RDF vocabularies that MUST be
+		used in Basic Profile 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="bpr-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</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="bpr-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="bpr-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:Resource</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="bpc">Basic Profile Container</h1>
+
+<section class="informative">		
+<h2 id="bpc-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 BPC 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
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] bp: &lt;http://open-services.net/ns/basicProfile#&gt;.
+
+&lt;http://example.org/container1&gt;
+   a bp: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
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] bp: &lt;http://open-services.net/ns/basicProfile#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
+
+&lt;http://example.org/netWorth/nw1/assetContainer&gt;
+   a bp:Container;
+   bp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
+   bp: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 BPC resource itself.
+	</p>
+	
+	<div id="bpc-member_data" class="rule">5.1.1 Container Member Information</div>
+	<em>This section is informative</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. BPC 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
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs:    &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] bp:      &lt;http://open-services.net/ns/basicProfile#&gt;.
[email protected] o:       &lt;http://example.org/ontology/&gt;.
+
+&lt;http://example.org/netWorth/nw1/assetContainer&gt;
+   a bp:Container;
+   dcterms:title "The assets of JohnZSmith";
+   bp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
+   bp: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="bpc-get_non-member_props" class="rule">5.1.2 Retrieving Only Non-member Properties
+	</div>
+	<em>This section is informative</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 BPC 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.</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
+
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] bp: &lt;http://open-services.net/ns/basicProfile#&gt;.
+
+&lt;http://example.org/container1&gt;
+   a bp:Container;
+   dcterms:title "A Basic Profile Container of Acme Resources";
+   bp:membershipPredicate rdfs:member;
+   dcterms:publisher &lt;http://acme.com/&gt;.</pre>
+
+	<div id="bpc-paging" class="rule">5.1.3 Paging</div>
+	<em>This section is informative</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, BPCs 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>BPC 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
[email protected] rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] bp: &lt;http://open-services.net/ns/basicProfile#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
+
+&lt;http://example.org/netWorth/nw1/assetContainer&gt;
+   a bp:Container;
+   dcterms:title "The assets of JohnZSmith";
+   bp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
+   bp:membershipPredicate o:asset.
+
+&lt;http://example.org/netWorth/nw1/assetContainer?firstPage&gt;
+   a bp:Page;
+   bp:pageOf &lt;http://example.org/netWorth/nw1/assetContainer&gt;;
+   bp: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
[email protected] rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] bp: &lt;http://open-services.net/ns/basicProfile#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
+
+&lt;http://example.org/netWorth/nw1/assetContainer&gt;
+   a bp:Container;
+   dcterms:title "The assets of JohnZSmith";
+   bp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
+   bp:membershipPredicate o:asset.
+
+&lt;http://example.org/netWorth/nw1/assetContainer?p=2&gt;
+   a bp:Page;
+   bp:pageOf &lt;http://example.org/netWorth/nw1/assetContainer&gt;;
+   bp: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>bp:nextPage</code>
+		predicate of the page resource.
+	</p>
+	<p>BPC 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="bpc-ordering" class="rule">5.1.4 Ordering</div>
+	<em>This section is informative</em>
+	<p>
+		There are many cases where an ordering of the members of the
+		container is important. BPC 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, BPC avoids the use of RDF
+		constructs like Seq and List for expressing order.
+	</p>
+	<p>
+		Order only becomes important for BPC 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 BPC 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 BPC specification provides a predicate - <code>bp: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
[email protected] rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
[email protected] dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] bp: &lt;http://open-services.net/ns/basicProfile#&gt;.
[email protected] o: &lt;http://example.org/ontology/&gt;.
+
+&lt;http://example.org/netWorth/nw1/assetContainer&gt;
+   a bp:Container;
+   dcterms:title "The assets of JohnZSmith";
+   bp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
+   bp:membershipPredicate o:asset.
+
+&lt;http://example.org/netWorth/nw1/assetContainer?firstPage&gt;
+   a bp:Page;
+   bp:pageOf &lt;http://example.org/netWorth/nw1/assetContainer&gt;;
+   bp: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></div>
+		<p>
+			As you can see by the addition of the <code>bp: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="bpc-general">General</h2>
+	<div id="bpc-5_2_1" class="rule">5.2.1 BPC servers MUST also be conformant BPR servers. A Basic Profile
+		Container is a resource that is a Basic Profile Resource.
+	</div>
+	<div id="bpc-5_2_2" class="rule">5.2.2 The same resource MAY be a member of multiple BPCs. This happens
+		commonly if one container is a view onto a larger container.
+	</div>
+	<div id="bpc-5_2_3" class="rule">5.2.3 The representation of a BPC 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 BPC 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, BPC servers
+		SHOULD use the <code>rdfs:member</code> predicate.
+	</div>
+	<div id="bpc-5_2_4" class="rule">5.2.4 A BPC MUST contain one triple for the <code>bp:membershipSubject</code>
+		predicate that indicates the subject of the membership triples when container subject is not the BPC itself.
+	</div>
+	<div id="bpc-5_2_5" class="rule">5.2.5 A BPC MUST contain one triple for the <code>bp:membershipPredicate</code>
+		predicate that indicates the predicate of the membership triple when
+		the container predicate is not <code>rdfs:member</code>.
+	</div>
+	<div id="bpc-5_2_6" class="rule">5.2.6 The representation of a BPC 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 BPC 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="#bpc-member_data">5.1.1 Container
+		Member Information</a> for additional details.
+	</div>
+	<div id="bpc-5_2_7" class="rule">5.2.7 The representation of a BPC MUST have <code>rdf:type</code>
+		of <code>bp:Container</code>, but it MAY have additional
+		<code>rdf:type</code>s.
+	</div>
+	<div id="bpc-5_2_8" class="rule">5.2.8 BPCs SHOULD NOT use RDF container types <code>rdf:Bag</code>,
+		<code>rdf:Seq</code> and <code>rdf:List</code>.
+	</div>
+</section>
+
+<section>	
+<h2 id="bpc-HTTP_GET">HTTP GET</h2>
+	<div id="bpc-5_3_1" class="rule">5.3.1 The representation of a BPC 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="#bpc-5_2_3">5.2.3</a>.
+	</div>
+	<div id="bpc-5_3_2" class="rule">5.3.2 BPC servers SHOULD support requests for information about a known BPC
+		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 BPC URL.  For example, if there is a BPC 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="#bpc-get_non_member_props">5.1.2 Retrieving Non-member Properties</a> for
+		additional details. A BPC 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="bpc-5_3_3" class="rule">5.3.3 A BPC server that does not support a request to retrieve the first
+		page resource representation via a known BPC 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="bpc-5_3_4" class="rule">5.3.4 BPC servers SHOULD support requests for splitting large BPCs into
+		pages indicated by a client supplying the token “<code>firstPage</code>”
+		on the query component of the BPC URL. For example, if there is a BPC
+		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="#bpc-paging">5.1.3 titled “Paging”</a> for additional details.
+	</div>
+	<div id="bpc-5_3_5" class="rule">5.3.5 BPC servers MAY split the response representation of a BPC 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="#bpc-paging">5.1.3 Paging</a> for
+		additional details.
+	</div>
+	<div id="bpc-5_3_5_1" class="rule">5.3.5.1 BPC servers that initiate paging SHOULD respond to requests for a BPC
+		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="bpc-5_3_6" class="rule">5.3.6 BPC servers that support paging MUST include in the page
+		representation a representation for the BPC, such that:
+	</div>
+	<div id="bpc-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>bp: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>bp:pageOf,</code>
+		and object is the URL of the BPC.
+	</div>
+	<div id="bpc-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>bp:nextPage</code> and
+		object being the URL for the subsequent page.
+	</div>
+	<div id="bpc-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>bp:nextPage</code> and object being <code>rdf:nil</code>.
+	</div>
+	<div id="bpc-5_3_7" class="rule">5.3.7 BPC servers MAY represent the members of a paged BPC in a sequential
+		order.  The order MUST be specified using the <code>bp:containerSortPredicates</code>
+		predicate whose subject is that of the page and object is a list of
+		BPC 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].
+	</div>
+	<div id="bpc-5_3_7_1" class="rule">5.3.7.1 The object of <code>bp: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="#bpc-ordering">5.1.4 Ordering</a> for
+		additional details.
+	</div>
+	<p>The Basic Profile does not define how clients
+		discover BPCs.</p>
+</section>
+
+<section>
+<h2 id="bpc-HTTP_POST">HTTP POST</h2>
+	<div id="bpc-5_4_1" class="rule">5.4.1 BPC clients SHOULD create resources by submitting a representation as
+		the entity body of the HTTP POST to a known BPC. BPC servers MUST
+		respond with status code 201 (Created) and the <code>Location</code>
+		header set to the new resource’s URL.
+	</div>
+	<div id="bpc-5_4_2" class="rule">5.4.2 After a successful HTTP POST request to a BPC, the new resource MUST
+		appear as a member of the BPC until the new resource is deleted or
+		removed by other methods. A BPC MAY also contain resources that were
+		added through other means - for example through the user interface of
+		the site that implements the BPC.
+	</div>
+	<div id="bpc-5_4_3" class="rule">5.4.3 BPC servers MAY accept an HTTP POST of non-RDF representations for
+		creation of any kind of resource, for example binary resources.
+	</div>
+	<div id="bpc-5_4_4" class="rule">5.4.4 For servers that support create, BPC servers MUST create a BPR from a
+		RDF representation in the request entity body.
+	</div>
+	<div id="bpc-5_4_5" class="rule">5.4.5 BPC 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="bpc-5_4_6" class="rule">5.4.6 For BPCs, servers MUST accept a request entity body with a content
+		type of <code>application/rdf+xml</code>.
+	</div>
+	<div id="bpc-5_4_7" class="rule">5.4.7 For BPCs, BPR servers SHOULD accept a request with an entity body
+		content type of <code>text/turtle</code>.
+	</div>
+	<div id="bpc-5_4_8" class="rule">5.4.8 For RDF representations, BPC servers MUST interpret the null relative
+		URI for the subject of triples in the BPR 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” BPR, 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="bpc-5_4_9" class="rule">5.4.9 BPC servers SHOULD assign the subject URI for the resource to be
+		created using server application specific rules.
+	</div>
+	<div id="bpc-5_4_10" class="rule">5.4.10 BPC servers SHOULD allow clients to create new resources without
+		requiring detailed knowledge of application-specific constraints.
+		 Some BPC 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="bpc-HTTP_PUT">HTTP PUT</h2>
+	<div id="bpc-5_5_1" class="rule">5.5.1 BPC servers SHOULD NOT allow HTTP PUT to update a BPC’s members and
+		if the server receives such a request, it SHOULD respond with a 409
+		(Conflict) status code.
+	</div>
+	<div id="bpc-5_5_2" class="rule">5.5.2 BPC servers MAY allow updating BPC non-membership properties using
+		HTTP PUT on <code>&lt;containerURL&gt;?non-member-properties</code>, which
+		MAY exclude server managed properties such as <code>bp:membershipSubject</code> and <code>bp:membershipPredicate</code>.
+	</div>
+</section>
+
+<section>
+<h2 id="bpc-HTTP_DELETE">5.6 HTTP DELETE</h2>
+	<div id="bpc-5_6_1" class="rule">5.6.1 If a BPC server supports deletion of the BPC, the server MAY also
+		delete the resources that are referenced as its contents.
+	</div>
+	<div id="bpc-5_6_2" class="rule">5.6.2 When a resource that is contained in a BPC (for example referenced by
+		a membership triple) is deleted, the server MUST also remove it from
+		the BPC 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="bpc-HTTP_HEAD">HTTP HEAD</h2>
+	<p>There are no additional requirements on HTTP
+		HEAD.</p>
+</section>
+
+<section>
+<h2 id="bpc-HTTP_PATCH">HTTP PATCH</h2>
+	<div id="bpc-5_8_1" class="rule">5.8.1 BPC servers are RECOMMENDED to support HTTP PATCH as the preferred
+		method for updating BPC non-membership properties.
+	</div>
+</section>
+</section>
+
+
+<section class='appendix'>
+<h2 id="normative_refs">Normative References</h2>
+		<div><dl>
+		<dt>Dublin Core</dt>
+		<dd><cite>
+			<a href="http://dublincore.org/documents/2010/10/11/dcmi-terms/">Dublin Core
+						Metadata Initiative</a></cite>
+			<a href="http://dublincore.org/documents/2010/10/11/dcmi-terms/"> Terms
+			</a>, DCMI Recommendation, 11 October 2010. This version is
+			http://dublincore.org/documents/2010/10/11/dcmi-terms/.  The latest
+			version is http://dublincore.org/documents/dcmi-terms/.
+		</dd>
+		
+		<dt>RDF</dt>
+        <dd><cite><a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/">Resource Description Framework (RDF): Concepts and Abstract Syntax</a></cite>, Klyne G., 
+        Carroll J. (Editors), W3C Recommendation, 10 February 2004. 
+        This version is http://www.w3.org/TR/2004/REC-rdf-primer-20040210/. 
+        The <a href="http://www.w3.org/TR/rdf-concepts/">latest version</a> is http://www.w3.org/TR/rdf-concepts/.</dd>
+		
+		<dt>RFC2119</dt>
+		<dd><cite>
+			<a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119:
+						Key words for use in RFCs to Indicate Requirement Levels
+			</a></cite>, Scott Bradner, 1997. (See
+				http://www.ietf.org/rfc/rfc2119.txt)
+		</dd>
+		
+		<dt>RFC2616</dt>
+		<dd><cite>
+			<a href="http://www.ietf.org/rfc/rfc2616.txt">Hypertext
+						Transfer Protocol - HTTP/1.1
+			</a></cite>. J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.
+			Berners-Lee, June 1999. Available at
+			http://www.ietf.org/rfc/rfc2616.txt.
+		</dd>
+		
+		<dt>RFC3986</dt>
+		<dd><cite>
+			<a href="http://www.apps.ietf.org/rfc/rfc3986.html">Uniform
+						Resource Identifier (URI): Generic Syntax
+			</a></cite>, Berners-Lee, Fielding, Masinter, January 2005.
+		</dd>
+		
+		<dt>RFC5789</dt>
+		<dd><cite>
+			<a href="http://tools.ietf.org/html/rfc5789">PATCH Method for HTTP
+			</a></cite>, L Dusseault, J. Snell, March 2010. Available at
+			http://tools.ietf.org/html/rfc5789
+		</dd>
+		
+		<dt>RFC3987</dt>
+		<dd><cite>
+			<a href="http://www.ietf.org/rfc/rfc3987.txt">Internationalized
+						Resource Identifiers (IRIs)
+			</a></cite>, Duerst, Suignard, January 2005.
+		</dd>
+		
+		<dt>SPARQL-UPDATE</dt>
+		<dd><cite>
+			<a href="http://www.w3.org/TR/2010/WD-sparql11-update-20100126/">
+			SPARQL 1.1 Update</a></cite>, S. Schenk, P. Gearon, Editor,
+			W3C Working Draft, 26 January 2010,
+			http://www.w3.org/TR/2010/WD-sparql11-update-20100126/. <a
+				href="http://www.w3.org/TR/sparql11-update/">Latest version
+			</a> available at http://www.w3.org/TR/sparql11-update/.
+		</dd>
+	 </dl>
+</section>
+
+<section class='appendix'>
+<h2 id="informative_refs">Informative References</h2>
+	   <dl>
+		<dt>4Rules</dt>
+		<dd><cite>
+			<a href="http://www.w3.org/DesignIssues/LinkedData.html">Linked Data
+						Design Issues</a></cite>, Tim Berners-Lee, 27 July 2006, <a
+				href="http://www.w3.org/DesignIssues/LinkedData.html">http://www.w3.org/DesignIssues/LinkedData.html
+			</a>
+		</dd>
+		
+		<dt>DC-RDF</dt>
+		<dd><cite>
+			<a href="http://dublincore.org/documents/dc-rdf/">Expressing
+						Dublin Core metadata using the Resource Description Framework
+						(RDF)</a></cite>, M. Nilsson and all, 14 January 2008,
+			http://dublincore.org/documents/2008/01/14/dc-rdf/. Latest available
+			at: http://dublincore.org/documents/dc-rdf/.
+		</dd>
+		
+		<dt>HTML 4.01</dt>
+		<dd><cite>
+			<a href="http://www.w3.org/TR/html4/">HTML 4.01
+						Specification</a></cite>, D. Raggett, A. Le Hors, and I.
+				Jacobs, 1999. (See http://www.w3.org/TR/html4/)
+		</dd>
+		
+<dt>IANA</dt>
+<dd><cite><a href="http://www.iana.org/assignments/media-types/index.html">Internet Assigned Numbers Authority
+(IANA)</a></cite> MIME Media Types, http://www.iana.org/assignments/media-types/index.html</dd>
+			
+		<dt>LinkedData</dt>
+		<dd><cite><a
+				href="http://www.w3.org/standards/semanticweb/data">Linked Data at W3C</a></cite>, 
+				http://www.w3.org/standards/semanticweb/data</a>
+		</dd>
+
+		<dt>OSLC</dt>
+		<dd><cite><a href="http://open-services.net/">Open Services for Lifecycle Collaboration (OSLC)</a></cite>, http://open-services.net</dd>
+		
+		<dt>RDF Primer</dt>
+		<dd><cite>
+			<a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210">Resource
+						Description Framework (RDF): Concepts and Abstract Syntax
+			</a></cite>, Klyne G., Carroll J. (Editors), W3C Recommendation, 10 February
+			2004. This version is
+			http://www.w3.org/TR/2004/REC-rdf-primer-20040210/. The <a href="http://www.w3.org/TR/rdf-primer/">latest
+			version</a> is http://www.w3.org/TR/rdf-primer/.
+		</dd>
+				
+		<dt>RDF-MT</dt>
+		<dd><cite>
+			<a href="http://www.w3.org/TR/2004/REC-rdf-mt-20040210/">RDF
+						Semantics</a></cite>, P. Hayes, Editor, W3C
+			Recommendation, 10 February 2004,
+			http://www.w3.org/TR/2004/REC-rdf-mt-20040210/. <a
+				href="http://www.w3.org/TR/rdf-mt/">Latest version
+			</a> available at http://www.w3.org/TR/rdf-mt/.
+		</dd>
+		
+		<dt>RDF-REST</dt>
+		<dd><cite><a href="http://www.w3.org/2001/sw/wiki/index.php?title=REST">RDF Simple Data Interface Protocol – Level Zero</a></cite>,
+			Latest version available at:
+			http://www.w3.org/2001/sw/wiki/index.php?title=REST</dd>
+			
+		<dt>REST</dt>
+		<dd><cite>
+			<a
+				href="http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm">Representational
+						State Transfer (REST)</a></cite>, R. Fielding, Ph.D. dissertation,
+			2000, <a
+				href="http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm">Latest version
+			</a> available at
+			http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
+			.
+		</dd>
+		
+		<dt>RW LinkedData</dt>
+		<dd><cite><a href="http://www.w3.org/DesignIssues/ReadWriteLinkedData.html">Read-Write Linked Data</a></cite>, 
+		Berners-Lee, August 2009, http://www.w3.org/DesignIssues/ReadWriteLinkedData.html</dd>
+		
+		<dt>SPARQL</dt>
+		<dd><cite>
+			<a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/">SPARQL Query
+						Language for RDF</a></cite>, E. Prud'hommeaux, A. Seaborne,
+			Editor, W3C Recommendation, 15 January 2008,
+			http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/. <a
+				href="http://www.w3.org/TR/rdf-sparql-query/">Latest version
+			</a> available at http://www.w3.org/TR/rdf-sparql-query/.
+		</dd>
+		
+		<dt>SPARQL-HTTP</dt>
+		<dd>
+			SPARQL 1.1 Graph Store HTTP Protocol, Latest version available at <a
+				href="http://www.w3.org/2009/sparql/docs/http-rdf-update/">http://www.w3.org/2009/sparql/docs/http-rdf-update/
+			</a>
+		</dd>
+		
+		<dt>TURTLE</dt>
+		<dd><cite>
+			<a href="http://www.w3.org/TeamSubmission/2011/SUBM-turtle-20110328/">Turtle -
+						Terse RDF Triple Language
+			</a></cite>, D. Beckett, T. Berners-Lee, Team Submission, 28 March 2011,
+			http://www.w3.org/TeamSubmission/2011/SUBM-turtle-20110328/. Latest
+			version available at http://www.w3.org/TeamSubmission/turtle/.
+		</dd>
+
+		<dt>WEBARCH</dt>
+		<dd><cite>
+			<a href="http://www.w3.org/TR/2004/REC-webarch-20041215/">Architecture
+			of the World Wide Web, Volume One</a></cite>
+			, N. Walsh, I. Jacobs, Editors,
+			W3C Recommendation, 15 December 2004,
+			http://www.w3.org/TR/2004/REC-webarch-20041215/. <a
+				href="http://www.w3.org/TR/webarch/">Latest version
+			</a> available at http://www.w3.org/TR/webarch/.
+		</dd>
+     </dl>
+</section>
+
+<section class='appendix informative' id="history">
+<h1>Change History</h1>
+<p>2012-09-18 
+Initial ReSpec'ing of <a href="http://www.w3.org/Submission/ldbp/">Member Submission - Linked Data Basic Profile 1.0</a>
+</p>
+</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>Fix up h3 references which are hacked div's at the moment</li>
+	<li>References don't follow ReSpec's handy format</li>
+	<li>What URIs should be used for editor's and PWD?  Currently we 'borrow' open-services.net</li>
+</ul>
+</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 (IBM)</li>
+		<li>John Arwe (IBM)</li>
+		<li>Arnaud le Hors (IBM)</li>
+    </ul>
+    </section>
+  </body>
+</html>