Merge
authorJohn Arwe
Mon, 25 Aug 2014 16:47:16 -0400
changeset 772 38ea974803c6
parent 771 c348bd680dbb (current diff)
parent 770 3e1bea298f03 (diff)
child 774 a38183b294ef
Merge
AccessControl.html
AccessControlRespec.html
LDP Access ControlNoRespec.htm
LDP Access ControlNoRespec_files/W3C-WG-NOTE.css
LDP Access ControlNoRespec_files/w3c_home.png
TR/NOTE-ldp-bp-20140829/ldp-bp.html
--- a/AccessControl.html	Mon Aug 25 16:45:08 2014 -0400
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,220 +0,0 @@
-<!DOCTYPE html>
-<html>
-  <head>
-    <title>LDP Access Control</title>
-    <!-- Changed by: , 13-Aug-2014 -->
-    <meta charset='utf-8'>
-    <script src='https://www.w3.org/Tools/respec/respec-w3c-common'
-            async class='remove'></script>
-    <script class='remove'>
-      var respecConfig = {
-          // specification status (e.g. WD, LCWD, WG-NOTE, etc.). If in doubt use ED.
-          specStatus:           "WG-NOTE",
-          
-          // the specification's short name, as in http://www.w3.org/TR/short-name/
-          shortName:            "LDP-AC",
-
-          // if your specification has a subtitle that goes below the main
-          // formal title, define it here
-          subtitle   :  "Usecases and Requirements for Access Control for the Linked Data Platform",
-
-          // if you wish the publication date to be other than the last modification, 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:  "1977-03-15",
-          // previousMaturity:  "WD",
-
-          // if there a publicly available Editor's Draft, this is the link
-          // edDraftURI:           "http://berjon.com/",
-
-          // if this is a LCWD, uncomment and set the end of its review period
-          // lcEnd: "2009-08-05",
-
-          // editors, add as many as you like
-          // only "name" is required
-          editors:  [
-              {
-                  name:       "Ashok Malhotra"
-              ,   mailto:     "[email protected]"
-              ,   company:    "Oracle America, Inc."
-              ,   companyURL: "http://www.oracle.com/"
-              },
-          ],
-          
-          // name of the WG
-          wg:           "Linked Data Platform WG",
-          
-          // URI of the public WG page
-          wgURI:        "https://www.w3.org/2012/ldp/wiki/Main_Page",
-          
-          // name (without the @w3c.org) of the public mailing to which comments are due
-          wgPublicList: "[email protected]",
-          
-          // 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:  "",
-          // !!!! IMPORTANT !!!! MAKE THE ABOVE BLINK IN YOUR HEAD
-      };
-    </script>
-  </head>
-  <body>
-    <section id='abstract'>
-      <p>
-        This note discusses usecases and requirements for Access Control for the 
-		<a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a> 
-		It also outlines a charter for developing a standard for HTTP-based access control. 
-		The work delineated in the charter may be pursued in the Linked Data Platform WG or an independent, related WG. 
-      </p>
-    </section>
-    
-    <section id='sotd'>
-      <p>
-        While the <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a> did not 
-		address Access Control directly, a number of usescases and requirements were identified as part of its
-		deliberations.  These usecases and requirements are captured in this document to serve as a basis for 
-		future work.    
-      </p>
-    </section>
-    
-    <section>
-      <h2>Access Control</h2>
-      <p>
-        Access Control is a mechanism through which an agent ( an HTTP server in this case ) permits other agents -- 
-		individuals, organizations, and/or groups made up of these -- to perform certain operations on resources as 
-		specified by policies for the resources and for the agents. Within this document, the resources are LDP resources, but the access 
-		control may operate at different granularities: RDF or other documents, named graphs or individual triples.
-		The operations are typically create, read, update, and delete (CRUD) but other operations can easily be accomodated by
-		this design.
-		</p>
-		<p>
-        When an agent requests a collection of resources it gets to see only those resources or parts of resources 
-		it is authorized for.</p>
-		<p>
-		Depending on the granularity, the access control mechanisms may affect performance, but should not affect 
-		semantics.</p>
-		<p>
-		For access control to come into play, the server must restrict some operations on some resources. 
-		</p>
-		</section>
-		<section>
-	  <h2>Terminology</h2>
-	  <ul>
-	  <li>ACG: An Access Control Graph describes the permitted modes of access for particular agents to apecific resources.</li>
-	  <li>ACG Resource: A resource whose representation contains one or more ACGs which the server relies 
-	  upon to make access control decisions.</li>
-	  </ul>
-    </section>
-	<section>
-	<h2>Usecases</h2>
-	<section>
-	<h3>Access Control on manipulation of resources via HTTP</h3>
-	Adam's user agent attempts:
-	<ol>	
-    <li>To CREATE, READ, UPDATE (or PATCH), or DELETE a resource identified by a URL.  The server may immediately 
-	allow or deny the request, or it may request that he authenticate to confirm his privileges, 
-	as specified by the ACG for the Resource.</li>
-    <li>If he is denied access, an explanation of why all or part of his request was denied should be provided 
-	so that it becomes possible to detect errors, and so that he may modify the request -- 
-	potentially to include making a request for such privileges.
-	</li>
-    <li>Adam would ideally like to know whether he will be able to perform an Action on a Resource 
-	before attempting such - i.e., whether he will have to authenticate before he is able to Read or Write the Resource.
-	</li>
-	<ol>
-	</section>
-	<section>
-	<h3>Editability of Access Control Rules using HTTP</h3>
-	<ol>
-	<li>
-    Bart's user agent logs on to a server and requests
-	the capability to read a group of related resources such as all the papers presented at a conference.</li>
-    </li>
-	<li>Employees with job titles VP or SVP can sign (update) supplier contracts.</li>
-    <li>Charlie, the Webmaster, would like to grant read access to the papers presented at a conference to all the 
-	people who attended the conference.</li>
-	<ol>
-	</section>
-	<section>
-	<h3>User Interface Scenarios</h3>
-	Eddie's HTTP based user agent would like to provide a user interface to allow, where possible, Eddie to 
-	<ol>
-	<li>Know if he can edit or delete a resource.</li>
-    <li>Know what he would have to do to have access to a resource ( be someone's friend, be part of a club, have 
-	paid a fee )</li>
-	<li>Allow Eddie to edit the access control rules for a resource such as:
-	<ol>
-        <li>Allow friends of his to access a document.</li>
-        <li>Allow friends of his to POST to a container, but only read a subset of the contents of the container, 
-		those posted by that agent for example.</li>
-        <li>Allow all the members of the LDP WG to create and edit resources including LDP Containers under a 
-		specific URL pattern.</li>
-		<li>Allow all friends of friends as expressed by the foaf:knows relations in one's foaf profile to POST comments 
-		to a container related to some content, and edit their own comments.</li>
-		<li>Allow the members of the LDP WG, the RWW CG, the WebID CG, and the member of the European Ontologist Network, 
-		to work together on set of ontologies. It should be possible to drag and drop URLs for these groups, 
-		found on the web, onto the User Interface as a way of creating the union of the members of the group.</li> 
-	</ol>
-	</ol>
-	</section>
-	<section>
-	<h2>Requirements</h2>
-	<ul>
-	<li>An Agent must be able to authenticate itself to a server with an identifier or as the owner of a token. 
-	( All use cases )</li>
-    <li>Ability to specify a collection of agents, identifying agents with URIs, URI patterns, or by description. 
-	(Usecase 3.2.2, 3.2.3)</li>
-    <li>Ability to specify a collection of resources, identified by URIs or URI patterns or by description,
-	with a specified access policy. (Usecase 3.2.1, 3.2.3)</li>
-    <li>Ability to connect a collection of agents with a collection of resources with given access privileges. 
-	( All use cases )</li>
-	</ul>
-	
-	<p>The above requirements require the ability, by an authorized agent, to CREATE, EDIT, UPDATE relevant ACGs. 
-
-	<ul>
-	<li>Ability to specify access privileges at a fine-grained level. (Usecase 3.1.2, 3.2.1.2)</li>
-    <li>The server should be able to describe access control policies for a resource. (Usecase 3.1.4, 3.3.1, 3.3.2)</li>
-    <li>The server should be able explain the reasons for access being disallowed in a machine readable format.
-	(Usecase 3.1.3)
-	</li>
-    <li>A user-agent should be able to find the ACG for a given resource.(Usecase 3.1.1)</li>
-	<li>The ability by one user agent to delegate the authority to create and edit ACGs to another agent.(Usecase 3.3.3)</li>
-	</ul>
-	</section>
-	<section>
-	<h2>Outline of a Charter for a Access Control WG</h2>
-	<p>An Access Control Graph (ACG) consists of two kinds of collections: a collection of agents and a collection of 
-	resources. It then connects a collection of agents with a collection of resources with the connection identifying 
-	the privileges the agents have on the resources: CREATE, READ, UPDATE, DELETE.</p>
-	<p>ACGs are resources in their own right and can have access control priviledges specified for them just like
-	any other resource.  This permits the creation and modification of ACGs to be delegated.
-	</p>
-	<p>
-	The members of the collection of agents contain tokens that the agents obtain from some authentication service. 
-	The members of the collection of resources are URIs or URI templates.</p>
-	<p>The WG will need to decide whether it also wants to define fine-grained access control at an attribute level.</p>
-<section>
-<h2>Deliverables</h2>
-<ul>
-<li>Define the collections that are part of the ACG and define how a collection of agents is connected to a 
-connection of resources.</li>
-<li>Define how ACGs can be created and edited and how these rights can be delegated.</li>
-<li>Describe a proof-of-concept implementation of how a request for access to a resource by an agent can be processed 
-efficiently with the ACG structure defined above.</li>
-</ul> 
-</section>	
-	</section>
-	</section>
-    
-    
-  </body>
-</html>
--- a/AccessControlRespec.html	Mon Aug 25 16:45:08 2014 -0400
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,219 +0,0 @@
-<!DOCTYPE html>
-<html>
-  <head>
-    <title>LDP Access Control</title>
-    <meta charset='utf-8'>
-    <script src='https://www.w3.org/Tools/respec/respec-w3c-common'
-            async class='remove'></script>
-    <script class='remove'>
-      var respecConfig = {
-          // specification status (e.g. WD, LCWD, WG-NOTE, etc.). If in doubt use ED.
-          specStatus:           "WG-NOTE",
-          
-          // the specification's short name, as in http://www.w3.org/TR/short-name/
-          shortName:            "LDP-ACR",
-
-          // if your specification has a subtitle that goes below the main
-          // formal title, define it here
-          subtitle   :  "Usecases and Requirements for Access Control for the Linked Data Platform",
-
-          // if you wish the publication date to be other than the last modification, set this
-          publishDate:  "2014-08-22",
-
-          // 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:  "1977-03-15",
-          // previousMaturity:  "WD",
-
-          // if there a publicly available Editor's Draft, this is the link
-          // edDraftURI:           "http://berjon.com/",
-
-          // if this is a LCWD, uncomment and set the end of its review period
-          // lcEnd: "2009-08-05",
-
-          // editors, add as many as you like
-          // only "name" is required
-          editors:  [
-              {
-                  name:       "Ashok Malhotra"
-              ,   mailto:     "[email protected]"
-              ,   company:    "Oracle America, Inc."
-              ,   companyURL: "http://www.oracle.com/"
-              },
-          ],
-          
-          // name of the WG
-          wg:           "Linked Data Platform WG",
-          
-          // URI of the public WG page
-          wgURI:        "https://www.w3.org/2012/ldp/wiki/Main_Page",
-          
-          // name (without the @w3c.org) of the public mailing to which comments are due
-          wgPublicList: "[email protected]",
-          
-          // 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:  "",
-          // !!!! IMPORTANT !!!! MAKE THE ABOVE BLINK IN YOUR HEAD
-      };
-    </script>
-  </head>
-  <body>
-    <section id='abstract'>
-      <p>
-        This note discusses usecases and requirements for Access Control for the 
-		<a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a> 
-		It also outlines a charter for developing a standard for HTTP-based access control. 
-		The work delineated in the charter may be pursued in the Linked Data Platform WG or an independent, related WG. 
-      </p>
-    </section>
-    
-    <section id='sotd'>
-      <p>
-        While the <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a> did not 
-		address Access Control directly, a number of usescases and requirements were identified as part of its
-		deliberations.  These usecases and requirements are captured in this document to serve as a basis for 
-		future work.  This is a First Public Working Draft.
-      </p>
-    </section>
-    
-    <section>
-      <h2>Access Control</h2>
-      <p>
-        Access Control is a mechanism through which an agent ( an HTTP server in this case ) permits other agents -- 
-		individuals, organizations, and/or groups made up of these -- to perform certain operations on resources as 
-		specified by policies for the resources and for the agents. Within this document, the resources are LDP resources, but the access 
-		control may operate at different granularities: RDF or other documents, named graphs or individual triples.
-		The operations are typically create, read, update, and delete (CRUD) but other operations can easily be accomodated by
-		this design.
-		</p>
-		<p>
-        When an agent requests a collection of resources it gets to see only those resources or parts of resources 
-		it is authorized for.</p>
-		<p>
-		Depending on the granularity, the access control mechanisms may affect performance, but should not affect 
-		semantics.</p>
-		<p>
-		For access control to come into play, the server must restrict some operations on some resources. 
-		</p>
-		</section>
-		<section>
-	  <h2>Terminology</h2>
-	  <ul>
-	  <li>ACG: An Access Control Graph describes the permitted modes of access for particular agents to apecific resources.</li>
-	  <li>ACG Resource: A resource whose representation contains one or more ACGs which the server relies 
-	  upon to make access control decisions.</li>
-	  </ul>
-    </section>
-	<section>
-	<h2>Usecases</h2>
-	<section>
-	<h3>Access Control on manipulation of resources via HTTP</h3>
-	Adam's user agent attempts:
-	<ol>	
-    <li>To CREATE, READ, UPDATE (or PATCH), or DELETE a resource identified by a URL.  The server may immediately 
-	allow or deny the request, or it may request that he authenticate to confirm his privileges, 
-	as specified by the ACG for the Resource.</li>
-    <li>If he is denied access, an explanation of why all or part of his request was denied should be provided 
-	so that it becomes possible to detect errors, and so that he may modify the request -- 
-	potentially to include making a request for such privileges.
-	</li>
-    <li>Adam would ideally like to know whether he will be able to perform an Action on a Resource 
-	before attempting such - i.e., whether he will have to authenticate before he is able to Read or Write the Resource.
-	</li>
-	<ol>
-	</section>
-	<section>
-	<h3>Editability of Access Control Rules using HTTP</h3>
-	<ol>
-	<li>
-    Bart's user agent logs on to a server and requests
-	the capability to read a group of related resources such as all the papers presented at a conference.</li>
-    </li>
-	<li>Employees with job titles VP or SVP can sign (update) supplier contracts.</li>
-    <li>Charlie, the Webmaster, would like to grant read access to the papers presented at a conference to all the 
-	people who attended the conference.</li>
-	<ol>
-	</section>
-	<section>
-	<h3>User Interface Scenarios</h3>
-	Eddie's HTTP based user agent would like to provide a user interface to allow, where possible, Eddie to 
-	<ol>
-	<li>Know if he can edit or delete a resource.</li>
-    <li>Know what he would have to do to have access to a resource ( be someone's friend, be part of a club, have 
-	paid a fee )</li>
-	<li>Allow Eddie to edit the access control rules for a resource such as:
-	<ol>
-        <li>Allow friends of his to access a document.</li>
-        <li>Allow friends of his to POST to a container, but only read a subset of the contents of the container, 
-		those posted by that agent for example.</li>
-        <li>Allow all the members of the LDP WG to create and edit resources including LDP Containers under a 
-		specific URL pattern.</li>
-		<li>Allow all friends of friends as expressed by the foaf:knows relations in one's foaf profile to POST comments 
-		to a container related to some content, and edit their own comments.</li>
-		<li>Allow the members of the LDP WG, the RWW CG, the WebID CG, and the member of the European Ontologist Network, 
-		to work together on set of ontologies. It should be possible to drag and drop URLs for these groups, 
-		found on the web, onto the User Interface as a way of creating the union of the members of the group.</li> 
-	</ol>
-	</ol>
-	</section>
-	<section>
-	<h2>Requirements</h2>
-	<ul>
-	<li>An Agent must be able to authenticate itself to a server with an identifier or as the owner of a token. 
-	( All use cases )</li>
-    <li>Ability to specify a collection of agents, identifying agents with URIs, URI patterns, or by description. 
-	(Usecase 3.2.2, 3.2.3)</li>
-    <li>Ability to specify a collection of resources, identified by URIs or URI patterns or by description,
-	with a specified access policy. (Usecase 3.2.1, 3.2.3)</li>
-    <li>Ability to connect a collection of agents with a collection of resources with given access privileges. 
-	( All use cases )</li>
-	</ul>
-	
-	<p>The above requirements require the ability, by an authorized agent, to CREATE, EDIT, UPDATE relevant ACGs. 
-
-	<ul>
-	<li>Ability to specify access privileges at a fine-grained level. (Usecase 3.1.2, 3.2.1.2)</li>
-    <li>The server should be able to describe access control policies for a resource. (Usecase 3.1.4, 3.3.1, 3.3.2)</li>
-    <li>The server should be able explain the reasons for access being disallowed in a machine readable format.
-	(Usecase 3.1.3)
-	</li>
-    <li>A user-agent should be able to find the ACG for a given resource.(Usecase 3.1.1)</li>
-	<li>The ability by one user agent to delegate the authority to create and edit ACGs to another agent.(Usecase 3.3.3)</li>
-	</ul>
-	</section>
-	<section>
-	<h2>Outline of a Charter for a Access Control WG</h2>
-	<p>An Access Control Graph (ACG) consists of two kinds of collections: a collection of agents and a collection of 
-	resources. It then connects a collection of agents with a collection of resources with the connection identifying 
-	the privileges the agents have on the resources: CREATE, READ, UPDATE, DELETE.</p>
-	<p>ACGs are resources in their own right and can have access control priviledges specified for them just like
-	any other resource.  This permits the creation and modification of ACGs to be delegated.
-	</p>
-	<p>
-	The members of the collection of agents contain tokens that the agents obtain from some authentication service. 
-	The members of the collection of resources are URIs or URI templates.</p>
-	<p>The WG will need to decide whether it also wants to define fine-grained access control at an attribute level.</p>
-<section>
-<h2>Deliverables</h2>
-<ul>
-<li>Define the collections that are part of the ACG and define how a collection of agents is connected to a 
-connection of resources.</li>
-<li>Define how ACGs can be created and edited and how these rights can be delegated.</li>
-<li>Describe a proof-of-concept implementation of how a request for access to a resource by an agent can be processed 
-efficiently with the ACG structure defined above.</li>
-</ul> 
-</section>	
-	</section>
-	</section>
-    
-    
-  </body>
-</html>
--- a/LDP Access ControlNoRespec.htm	Mon Aug 25 16:45:08 2014 -0400
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,406 +0,0 @@
-<!DOCTYPE html>
-<html dir="ltr" typeof="bibo:Document " about="" property="dcterms:language" content="en" lang="en"><head>
-<meta http-equiv="content-type" content="text/html; charset=UTF-8">
-    <title>LDP Access Control</title>
-    <meta charset="utf-8">
-    
-    
-  <style>/*****************************************************************
- * ReSpec 3 CSS
- * Robin Berjon - http://berjon.com/
- *****************************************************************/
-
-/* --- INLINES --- */
-em.rfc2119 { 
-    text-transform:     lowercase;
-    font-variant:       small-caps;
-    font-style:         normal;
-    color:              #900;
-}
-
-h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
-h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
-    border: none;
-}
-
-dfn {
-    font-weight:    bold;
-}
-
-a.internalDFN {
-    color:  inherit;
-    border-bottom:  1px solid #99c;
-    text-decoration:    none;
-}
-
-a.externalDFN {
-    color:  inherit;
-    border-bottom:  1px dotted #ccc;
-    text-decoration:    none;
-}
-
-a.bibref {
-    text-decoration:    none;
-}
-
-cite .bibref {
-    font-style: normal;
-}
-
-code {
-    color:  #C83500;
-}
-
-/* --- TOC --- */
-.toc a, .tof a {
-    text-decoration:    none;
-}
-
-a .secno, a .figno {
-    color:  #000;
-}
-
-ul.tof, ol.tof {
-    list-style: none outside none;
-}
-
-.caption {
-    margin-top: 0.5em;
-    font-style:   italic;
-}
-
-/* --- TABLE --- */
-table.simple {
-    border-spacing: 0;
-    border-collapse:    collapse;
-    border-bottom:  3px solid #005a9c;
-}
-
-.simple th {
-    background: #005a9c;
-    color:  #fff;
-    padding:    3px 5px;
-    text-align: left;
-}
-
-.simple th[scope="row"] {
-    background: inherit;
-    color:  inherit;
-    border-top: 1px solid #ddd;
-}
-
-.simple td {
-    padding:    3px 10px;
-    border-top: 1px solid #ddd;
-}
-
-.simple tr:nth-child(even) {
-    background: #f0f6ff;
-}
-
-/* --- DL --- */
-.section dd > p:first-child {
-    margin-top: 0;
-}
-
-.section dd > p:last-child {
-    margin-bottom: 0;
-}
-
-.section dd {
-    margin-bottom:  1em;
-}
-
-.section dl.attrs dd, .section dl.eldef dd {
-    margin-bottom:  0;
-}
-
[email protected] print {
-    .removeOnSave {
-        display: none;
-    }
-}
-</style><link href="LDP%20Access%20ControlNoRespec_files/W3C-WG-NOTE.css" rel="stylesheet"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
-  <body id="respecDocument" role="document" class="h-entry"><div id="respecHeader" role="contentinfo" class="head">
-  <p>
-    
-      <a href="http://www.w3.org/"><img src="LDP%20Access%20ControlNoRespec_files/w3c_home.png" alt="W3C" height="48" width="72"></a>
-    
-  </p>
-  <h1 class="title p-name" id="title" property="dcterms:title">LDP Access Control</h1>
-  
-    <h2 property="bibo:subtitle" id="subtitle">Usecases and Requirements for Access Control for the Linked Data Platform</h2>
-  
-  <h2 id="w3c-working-group-note-22-august-2014" property="dcterms:issued" datatype="xsd:dateTime" content="2014-08-22T04:00:00.000Z"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note <time class="dt-published" datetime="2014-08-22">22 August 2014</time></h2>
-  <dl>
-    
-      <dt>This version:</dt>
-      <dd><a class="u-url" href="http://www.w3.org/TR/2014/NOTE-LDP-ACR-20140822/">http://www.w3.org/TR/2014/NOTE-LDP-ACR-20140822/</a></dd>
-      <dt>Latest published version:</dt>
-      <dd><a href="http://www.w3.org/TR/LDP-ACR/">http://www.w3.org/TR/LDP-ACR/</a></dd>
-    
-    
-    
-    
-    
-    
-    
-    
-    <dt>Editor:</dt>
-    <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><span property="foaf:name" class="p-name fn">Ashok Malhotra</span>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oracle.com/">Oracle America, Inc.</a>, <span class="ed_mailto"><a class="u-email email" rel="foaf:mbox" href="mailto:[email protected]">[email protected]</a></span></span>
-</dd>
-
-    
-    
-  </dl>
-  
-  
-  
-  
-    
-      <p class="copyright">
-        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
-        2014
-        
-        <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
-        (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
-        <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
-        <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), 
-        
-        All Rights Reserved.
-        
-        <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
-        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
-        
-          <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
-        
-        rules apply.
-      </p>
-    
-  
-  <hr>
-</div>
-    <section rel="bibo:Chapter" resource="#abstract" typeof="bibo:Chapter" datatype="" property="dcterms:abstract" class="introductory" id="abstract"><h2 id="h2_abstract" role="heading" aria-level="1">Abstract</h2>
-      <p>
-        This note discusses usecases and requirements for Access Control for the 
-		<a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a> 
-		It also outlines a charter for developing a standard for HTTP-based access control. 
-		The work delineated in the charter may be pursued in the Linked Data Platform WG or an independent, related WG. 
-      </p>
-    </section><section rel="bibo:Chapter" resource="#sotd" typeof="bibo:Chapter" id="sotd" class="introductory"><h2 id="h2_sotd" role="heading" aria-level="1">Status of This Document</h2>
-  
-    
-      
-        <p>
-          <em>This section describes the status of this document at the time of its publication.
-          Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the
-          latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
-          http://www.w3.org/TR/.</em>
-        </p>
-        
-      <p>
-        While the <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a> did not 
-		address Access Control directly, a number of usescases and requirements were identified as part of its
-		deliberations.  These usecases and requirements are captured in this document to serve as a basis for 
-		future work.  This is a First Public Working Draft.
-      </p>
-    
-        <p>
-          This document was published by the <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG</a> as a Working Group Note.
-          
-          
-            If you wish to make comments regarding this document, please send them to 
-            <a href="mailto:[email protected]@w3.org">[email protected]@w3.org</a> 
-            (<a href="mailto:[email protected]@w3.org?subject=subscribe">subscribe</a>,
-            <a href="http://lists.w3.org/Archives/Public/[email protected]/">archives</a>).
-          
-          
-          
-          
-            All comments are welcome.
-          
-        </p>
-        
-        
-          <p>
-            Publication as a Working Group Note does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr>
-            Membership. This is a draft document and may be updated, replaced or obsoleted by other
-            documents at any time. It is inappropriate to cite this document as other than work in
-            progress.
-          </p>
-        
-        
-        
-        <p>
-          
-            This document was produced by a group operating under the 
-            <a id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent
-            Policy</a>.
-          
-          
-          
-            
-              <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="" rel="disclosure">public list of any patent
-              disclosures</a> 
-            
-            made in connection with the deliverables of the group; that page also includes
-            instructions for disclosing a patent. An individual who has actual knowledge of a patent
-            which the individual believes contains
-            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
-            Claim(s)</a> must disclose the information in accordance with
-            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
-            6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
-          
-          
-        </p>
-        
-          <p>This document is governed by the <a id="w3c_process_revision" href="http://www.w3.org/2014/Process-20140801/">1 August 2014 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.
-          </p>
-        
-        
-      
-    
-  
-</section><section id="toc"><h2 id="h2_toc" role="heading" aria-level="1" class="introductory">Table of Contents</h2><ul id="respecContents" role="directory" class="toc"><li class="tocline"><a class="tocxref" href="#access-control"><span class="secno">1. </span>Access Control</a></li><li class="tocline"><a class="tocxref" href="#terminology"><span class="secno">2. </span>Terminology</a></li><li class="tocline"><a class="tocxref" href="#usecases"><span class="secno">3. </span>Usecases</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#access-control-on-manipulation-of-resources-via-http"><span class="secno">3.1 </span>Access Control on manipulation of resources via HTTP</a></li><li class="tocline"><a class="tocxref" href="#editability-of-access-control-rules-using-http"><span class="secno">3.2 </span>Editability of Access Control Rules using HTTP</a></li><li class="tocline"><a class="tocxref" href="#user-interface-scenarios"><span class="secno">3.3 </span>User Interface Scenarios</a></li><li class="tocline"><a class="tocxref" href="#requirements"><span class="secno">3.4 </span>Requirements</a></li><li class="tocline"><a class="tocxref" href="#outline-of-a-charter-for-a-access-control-wg"><span class="secno">3.5 </span>Outline of a Charter for a Access Control WG</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#deliverables"><span class="secno">3.5.1 </span>Deliverables</a></li></ul></li></ul></li></ul></section>
-    
-    
-    
-    <section id="access-control">
-      <!--OddPage--><h2 id="h2_access-control" role="heading" aria-level="1"><span class="secno">1. </span>Access Control</h2>
-      <p>
-        Access Control is a mechanism through which an agent ( an HTTP 
-server in this case ) permits other agents -- 
-		individuals, organizations, and/or groups made up of these -- to 
-perform certain operations on resources as 
-		specified by policies for the resources and for the agents. Within 
-this document, the resources are LDP resources, but the access 
-		control may operate at different granularities: RDF or other 
-documents, named graphs or individual triples.
-		The operations are typically create, read, update, and delete (CRUD) 
-but other operations can easily be accomodated by
-		this design.
-		</p>
-		<p>
-        When an agent requests a collection of resources it gets to see only those resources or parts of resources 
-		it is authorized for.</p>
-		<p>
-		Depending on the granularity, the access control mechanisms may affect performance, but should not affect 
-		semantics.</p>
-		<p>
-		For access control to come into play, the server must restrict some operations on some resources. 
-		</p>
-		</section>
-		<section id="terminology">
-	  <!--OddPage--><h2 id="h2_terminology" role="heading" aria-level="1"><span class="secno">2. </span>Terminology</h2>
-	  <ul>
-	  <li>ACG: An Access Control Graph describes the permitted modes of access for particular agents to apecific resources.</li>
-	  <li>ACG Resource: A resource whose representation contains one or more ACGs which the server relies 
-	  upon to make access control decisions.</li>
-	  </ul>
-    </section>
-	<section id="usecases">
-	<!--OddPage--><h2 id="h2_usecases" role="heading" aria-level="1"><span class="secno">3. </span>Usecases</h2>
-	<section id="access-control-on-manipulation-of-resources-via-http">
-	<h3 id="h3_access-control-on-manipulation-of-resources-via-http" role="heading" aria-level="2"><span class="secno">3.1 </span>Access Control on manipulation of resources via HTTP</h3>
-	Adam's user agent attempts:
-	<ol>	
-    <li>To CREATE, READ, UPDATE (or PATCH), or DELETE a resource identified by a URL.  The server may immediately 
-	allow or deny the request, or it may request that he authenticate to confirm his privileges, 
-	as specified by the ACG for the Resource.</li>
-    <li>If he is denied access, an explanation of why all or part of his request was denied should be provided 
-	so that it becomes possible to detect errors, and so that he may modify the request -- 
-	potentially to include making a request for such privileges.
-	</li>
-    <li>Adam would ideally like to know whether he will be able to perform an Action on a Resource 
-	before attempting such - i.e., whether he will have to authenticate before he is able to Read or Write the Resource.
-	</li>
-	<ol>
-	</ol></ol></section>
-	<section id="editability-of-access-control-rules-using-http">
-	<h3 id="h3_editability-of-access-control-rules-using-http" role="heading" aria-level="2"><span class="secno">3.2 </span>Editability of Access Control Rules using HTTP</h3>
-	<ol>
-	<li>
-    Bart's user agent logs on to a server and requests
-	the capability to read a group of related resources such as all the papers presented at a conference.</li>
-    
-	<li>Employees with job titles VP or SVP can sign (update) supplier contracts.</li>
-    <li>Charlie, the Webmaster, would like to grant read access to the papers presented at a conference to all the 
-	people who attended the conference.</li>
-	<ol>
-	</ol></ol></section>
-	<section id="user-interface-scenarios">
-	<h3 id="h3_user-interface-scenarios" role="heading" aria-level="2"><span class="secno">3.3 </span>User Interface Scenarios</h3>
-	Eddie's HTTP based user agent would like to provide a user interface to allow, where possible, Eddie to 
-	<ol>
-	<li>Know if he can edit or delete a resource.</li>
-    <li>Know what he would have to do to have access to a resource ( be someone's friend, be part of a club, have 
-	paid a fee )</li>
-	<li>Allow Eddie to edit the access control rules for a resource such as:
-	<ol>
-        <li>Allow friends of his to access a document.</li>
-        <li>Allow friends of his to POST to a container, but only read a subset of the contents of the container, 
-		those posted by that agent for example.</li>
-        <li>Allow all the members of the LDP WG to create and edit resources including LDP Containers under a 
-		specific URL pattern.</li>
-		<li>Allow all friends of friends as expressed by the foaf:knows relations in one's foaf profile to POST comments 
-		to a container related to some content, and edit their own comments.</li>
-		<li>Allow the members of the LDP WG, the RWW CG, the WebID CG, and the member of the European Ontologist Network, 
-		to work together on set of ontologies. It should be possible to drag and drop URLs for these groups, 
-		found on the web, onto the User Interface as a way of creating the union of the members of the group.</li> 
-	</ol>
-	</li></ol>
-	</section>
-	<section id="requirements">
-	<h3 id="h3_requirements" role="heading" aria-level="2"><span class="secno">3.4 </span>Requirements</h3>
-	<ul>
-	<li>An Agent must be able to authenticate itself to a server with an identifier or as the owner of a token. 
-	( All use cases )</li>
-    <li>Ability to specify a collection of agents, identifying agents with URIs, URI patterns, or by description. 
-	(Usecase 3.2.2, 3.2.3)</li>
-    <li>Ability to specify a collection of resources, identified by URIs or URI patterns or by description,
-	with a specified access policy. (Usecase 3.2.1, 3.2.3)</li>
-    <li>Ability to connect a collection of agents with a collection of resources with given access privileges. 
-	( All use cases )</li>
-	</ul>
-	
-	<p>The above requirements require the ability, by an authorized agent, to CREATE, EDIT, UPDATE relevant ACGs. 
-
-	</p><ul>
-	<li>Ability to specify access privileges at a fine-grained level. (Usecase 3.1.2, 3.2.1.2)</li>
-    <li>The server should be able to describe access control policies for a resource. (Usecase 3.1.4, 3.3.1, 3.3.2)</li>
-    <li>The server should be able explain the reasons for access being disallowed in a machine readable format.
-	(Usecase 3.1.3)
-	</li>
-    <li>A user-agent should be able to find the ACG for a given resource.(Usecase 3.1.1)</li>
-	<li>The ability by one user agent to delegate the authority to create and edit ACGs to another agent.(Usecase 3.3.3)</li>
-	</ul>
-	</section>
-	<section id="outline-of-a-charter-for-a-access-control-wg">
-	<h3 id="h3_outline-of-a-charter-for-a-access-control-wg" role="heading" aria-level="2"><span class="secno">3.5 </span>Outline of a Charter for a Access Control WG</h3>
-	<p>An Access Control Graph (ACG) consists of two kinds of collections: a collection of agents and a collection of 
-	resources. It then connects a collection of agents with a collection of resources with the connection identifying 
-	the privileges the agents have on the resources: CREATE, READ, UPDATE, DELETE.</p>
-	<p>ACGs are resources in their own right and can have access control priviledges specified for them just like
-	any other resource.  This permits the creation and modification of ACGs to be delegated.
-	</p>
-	<p>
-	The members of the collection of agents contain tokens that the agents obtain from some authentication service. 
-	The members of the collection of resources are URIs or URI templates.</p>
-	<p>The WG will need to decide whether it also wants to define fine-grained access control at an attribute level.</p>
-<section id="deliverables">
-<h4 id="h4_deliverables" role="heading" aria-level="3"><span class="secno">3.5.1 </span>Deliverables</h4>
-<ul>
-<li>Define the collections that are part of the ACG and define how a collection of agents is connected to a 
-connection of resources.</li>
-<li>Define how ACGs can be created and edited and how these rights can be delegated.</li>
-<li>Describe a proof-of-concept implementation of how a request for access to a resource by an agent can be processed 
-efficiently with the ACG structure defined above.</li>
-</ul> 
-</section>	
-	</section>
-	</section>
-    
-    
-  
-
-</body></html>
\ No newline at end of file
--- a/LDP Access ControlNoRespec_files/W3C-WG-NOTE.css	Mon Aug 25 16:45:08 2014 -0400
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,89 +0,0 @@
-
-/* Style for a "Working Group Note" */
-
-/*
-   Copyright 1997-2003 W3C (MIT, ERCIM, Keio). All Rights Reserved.
-   The following software licensing rules apply:
-   http://www.w3.org/Consortium/Legal/copyright-software */
-
-/* $Id: base.css,v 1.28 2014-04-22 03:27:49 ijacobs Exp $ */
-
-body {
-  padding: 2em 1em 2em 70px;
-  margin: 0;
-  font-family: sans-serif;
-  color: black;
-  background: white;
-  background-position: top left;
-  background-attachment: fixed;
-  background-repeat: no-repeat;
-}
-:link { color: #00C; background: transparent }
-:visited { color: #609; background: transparent }
-a:active { color: #C00; background: transparent }
-
-a:link img, a:visited img { border-style: none } /* no border on img links */
-
-a img { color: white; }        /* trick to hide the border in Netscape 4 */
[email protected] all {                   /* hide the next rule from Netscape 4 */
-  a img { color: inherit; }    /* undo the color change above */
-}
-
-th, td { /* ns 4 */
-  font-family: sans-serif;
-}
-
-h1, h2, h3, h4, h5, h6 { text-align: left }
-/* background should be transparent, but WebTV has a bug */
-h1, h2, h3 { color: #005A9C; background: white }
-h1 { font: 170% sans-serif }
-h2 { font: 140% sans-serif }
-h3 { font: 120% sans-serif }
-h4 { font: bold 100% sans-serif }
-h5 { font: italic 100% sans-serif }
-h6 { font: small-caps 100% sans-serif }
-
-.hide { display: none }
-
-div.head { margin-bottom: 1em }
-div.head h1 { margin-top: 2em; clear: both }
-div.head table { margin-left: 2em; margin-top: 2em }
-
-p.copyright { font-size: small }
-p.copyright small { font-size: small }
-
[email protected] screen {  /* hide from IE3 */
-a[href]:hover { background: #ffa }
-}
-
-pre { margin-left: 2em }
-/*
-p {
-  margin-top: 0.6em;
-  margin-bottom: 0.6em;
-}
-*/
-dt, dd { margin-top: 0; margin-bottom: 0 } /* opera 3.50 */
-dt { font-weight: bold }
-
-ul.toc, ol.toc {
-  list-style: disc;		/* Mac NS has problem with 'none' */
-  list-style: none;
-}
-
[email protected] speech {
- h1, h2, h3 { voice-stress: moderate; }
- .hide { speak: none; }
- p.copyright { voice-volume: x-soft; voice-rate: x-fast; }
- dt { pause-before: 63ms; }
-}
-
-
-/* Copyright 1997-2003 W3C (MIT, ERCIM, Keio). All Rights Reserved.
-   The following software licensing rules apply:
-   http://www.w3.org/Consortium/Legal/copyright-software */
-
-body {
-  background-image: url(//www.w3.org/StyleSheets/TR/logo-WG-Note);
-}
-
Binary file LDP Access ControlNoRespec_files/w3c_home.png has changed
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/TR/NOTE-ldp-acr-20140825/Overview.html	Mon Aug 25 16:47:16 2014 -0400
@@ -0,0 +1,402 @@
+<!DOCTYPE html>
+<html lang="en" dir="ltr" typeof="bibo:Document " about="" property="dcterms:language" content="en">
+<head>
+    <title>LDP Access Control</title>
+    <!-- Changed by: , 25-Aug-2014 -->
+    <meta charset="utf-8">
+    
+    
+  <style>/*****************************************************************
+ * ReSpec 3 CSS
+ * Robin Berjon - http://berjon.com/
+ *****************************************************************/
+
+/* --- INLINES --- */
+em.rfc2119 { 
+    text-transform:     lowercase;
+    font-variant:       small-caps;
+    font-style:         normal;
+    color:              #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+    border: none;
+}
+
+dfn {
+    font-weight:    bold;
+}
+
+a.internalDFN {
+    color:  inherit;
+    border-bottom:  1px solid #99c;
+    text-decoration:    none;
+}
+
+a.externalDFN {
+    color:  inherit;
+    border-bottom:  1px dotted #ccc;
+    text-decoration:    none;
+}
+
+a.bibref {
+    text-decoration:    none;
+}
+
+cite .bibref {
+    font-style: normal;
+}
+
+code {
+    color:  #C83500;
+}
+
+/* --- TOC --- */
+.toc a, .tof a {
+    text-decoration:    none;
+}
+
+a .secno, a .figno {
+    color:  #000;
+}
+
+ul.tof, ol.tof {
+    list-style: none outside none;
+}
+
+.caption {
+    margin-top: 0.5em;
+    font-style:   italic;
+}
+
+/* --- TABLE --- */
+table.simple {
+    border-spacing: 0;
+    border-collapse:    collapse;
+    border-bottom:  3px solid #005a9c;
+}
+
+.simple th {
+    background: #005a9c;
+    color:  #fff;
+    padding:    3px 5px;
+    text-align: left;
+}
+
+.simple th[scope="row"] {
+    background: inherit;
+    color:  inherit;
+    border-top: 1px solid #ddd;
+}
+
+.simple td {
+    padding:    3px 10px;
+    border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+    background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+    margin-top: 0;
+}
+
+.section dd > p:last-child {
+    margin-bottom: 0;
+}
+
+.section dd {
+    margin-bottom:  1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+    margin-bottom:  0;
+}
+
[email protected] print {
+    .removeOnSave {
+        display: none;
+    }
+}
+</style><link href="https://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" rel="stylesheet"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
+  <body id="respecDocument" role="document" class="h-entry"><div id="respecHeader" role="contentinfo" class="head">
+  <p>
+    
+      <a href="http://www.w3.org/"><img src="https://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"></a>
+    
+  </p>
+  <h1 class="title p-name" id="title" property="dcterms:title">LDP Access Control</h1>
+  
+    <h2 property="bibo:subtitle" id="subtitle">Usecases and Requirements for Access Control for the Linked Data Platform</h2>
+  
+  <h2 id="w3c-working-group-note-25-august-2014" property="dcterms:issued" datatype="xsd:dateTime" content="2014-08-25T19:14:30.000Z"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note <time class="dt-published" datetime="2014-08-25">25 August 2014</time></h2>
+  <dl>
+    
+      <dt>This version:</dt>
+      <dd><a class="u-url" href="http://www.w3.org/TR/2014/NOTE-ldp-acr-20140825/">http://www.w3.org/TR/2014/NOTE-ldp-acr-20140825/</a></dd>
+      <dt>Latest published version:</dt>
+      <dd><a href="http://www.w3.org/TR/ldp-acr/">http://www.w3.org/TR/ldp-acr/</a></dd>
+    
+      <dt>Latest editor's draft:</dt>
+      <dd><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-acr.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-acr.html</a></dd>
+    
+    
+    
+    
+    
+    
+    
+    <dt>Editor:</dt>
+    <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><span property="foaf:name" class="p-name fn">Ashok Malhotra</span>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oracle.com/">Oracle America, Inc.</a>, <span class="ed_mailto"><a class="u-email email" rel="foaf:mbox" href="mailto:[email protected]">[email protected]</a></span></span>
+</dd>
+
+    
+    
+  </dl>
+  
+  
+  
+  
+    
+      <p class="copyright">
+        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
+        2014
+        
+        <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
+        (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
+        <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
+        <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), 
+        
+        All Rights Reserved.
+        
+        <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
+        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
+        
+          <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
+        
+        rules apply.
+      </p>
+    
+  
+  <hr>
+</div>
+    <section rel="bibo:Chapter" resource="#abstract" typeof="bibo:Chapter" datatype="" property="dcterms:abstract" class="introductory" id="abstract"><h2 id="h2_abstract" role="heading" aria-level="1">Abstract</h2>
+      <p>
+        This note discusses usecases and requirements for Access Control for the 
+		<a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a> 
+		It also outlines a charter for developing a standard for HTTP-based access control. 
+		The work delineated in the charter may be pursued in the Linked Data Platform WG or an independent, related WG. 
+      </p>
+    </section><section rel="bibo:Chapter" resource="#sotd" typeof="bibo:Chapter" id="sotd" class="introductory"><h2 id="h2_sotd" role="heading" aria-level="1">Status of This Document</h2>
+  
+    
+      
+        <p>
+          <em>This section describes the status of this document at the time of its publication.
+          Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the
+          latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
+          http://www.w3.org/TR/.</em>
+        </p>
+        
+      <p>
+        While the <a href="http://www.w3.org/2012/ldp">Linked Data Platform WG.</a> did not 
+		address Access Control directly, a number of usescases and requirements were identified as part of its
+		deliberations.  These usecases and requirements are captured in this document to serve as a basis for 
+		future work.    
+      </p>
+    
+        <p>
+          This document was published by the <a href="http://www.w3.org/2012/ldp">Linked Data Platform WG</a> as a Working Group Note.
+          
+          
+            If you wish to make comments regarding this document, please send them to 
+            <a href="mailto:[email protected]@w3.org">[email protected]@w3.org</a> 
+            (<a href="mailto:public[email protected]@w3.org?subject=subscribe">subscribe</a>,
+            <a href="http://lists.w3.org/Archives/Public/[email protected]/">archives</a>).
+          
+          
+          
+          
+            All comments are welcome.
+          
+        </p>
+        
+        
+          <p>
+            Publication as a Working Group Note does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr>
+            Membership. This is a draft document and may be updated, replaced or obsoleted by other
+            documents at any time. It is inappropriate to cite this document as other than work in
+            progress.
+          </p>
+        
+        
+        
+        <p>
+          
+            This document was produced by a group operating under the 
+            <a id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent
+            Policy</a>.
+          
+          
+          
+            
+              <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/55082/status" rel="disclosure">public list of any patent
+              disclosures</a> 
+            
+            made in connection with the deliverables of the group; that page also includes
+            instructions for disclosing a patent. An individual who has actual knowledge of a patent
+            which the individual believes contains
+            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
+            Claim(s)</a> must disclose the information in accordance with
+            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
+            6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+          
+          
+        </p>
+        
+          <p>This document is governed by the <a id="w3c_process_revision" href="http://www.w3.org/2014/Process-20140801/">1 August 2014 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.
+          </p>
+        
+        
+      
+    
+  
+</section><section id="toc"><h2 id="h2_toc" role="heading" aria-level="1" class="introductory">Table of Contents</h2><ul id="respecContents" role="directory" class="toc"><li class="tocline"><a class="tocxref" href="#access-control"><span class="secno">1. </span>Access Control</a></li><li class="tocline"><a class="tocxref" href="#terminology"><span class="secno">2. </span>Terminology</a></li><li class="tocline"><a class="tocxref" href="#usecases"><span class="secno">3. </span>Usecases</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#access-control-on-manipulation-of-resources-via-http"><span class="secno">3.1 </span>Access Control on manipulation of resources via HTTP</a></li><li class="tocline"><a class="tocxref" href="#editability-of-access-control-rules-using-http"><span class="secno">3.2 </span>Editability of Access Control Rules using HTTP</a></li><li class="tocline"><a class="tocxref" href="#user-interface-scenarios"><span class="secno">3.3 </span>User Interface Scenarios</a></li><li class="tocline"><a class="tocxref" href="#requirements"><span class="secno">3.4 </span>Requirements</a></li><li class="tocline"><a class="tocxref" href="#outline-of-a-charter-for-a-access-control-wg"><span class="secno">3.5 </span>Outline of a Charter for a Access Control WG</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#deliverables"><span class="secno">3.5.1 </span>Deliverables</a></li></ul></li></ul></li></ul></section>
+    
+    
+    
+    <section id="access-control">
+      <!--OddPage--><h2 id="h2_access-control" role="heading" aria-level="1"><span class="secno">1. </span>Access Control</h2>
+      <p>
+        Access Control is a mechanism through which an agent ( an HTTP server in this case ) permits other agents -- 
+		individuals, organizations, and/or groups made up of these -- to perform certain operations on resources as 
+		specified by policies for the resources and for the agents. Within this document, the resources are LDP resources, but the access 
+		control may operate at different granularities: RDF or other documents, named graphs or individual triples.
+		The operations are typically create, read, update, and delete (CRUD) but other operations can easily be accomodated by
+		this design.
+		</p>
+		<p>
+        When an agent requests a collection of resources it gets to see only those resources or parts of resources 
+		it is authorized for.</p>
+		<p>
+		Depending on the granularity, the access control mechanisms may affect performance, but should not affect 
+		semantics.</p>
+		<p>
+		For access control to come into play, the server must restrict some operations on some resources. 
+		</p>
+		</section>
+		<section id="terminology">
+	  <!--OddPage--><h2 id="h2_terminology" role="heading" aria-level="1"><span class="secno">2. </span>Terminology</h2>
+	  <ul>
+	  <li>ACG: An Access Control Graph describes the permitted modes of access for particular agents to apecific resources.</li>
+	  <li>ACG Resource: A resource whose representation contains one or more ACGs which the server relies 
+	  upon to make access control decisions.</li>
+	  </ul>
+    </section>
+	<section id="usecases">
+	<!--OddPage--><h2 id="h2_usecases" role="heading" aria-level="1"><span class="secno">3. </span>Usecases</h2>
+	<section id="access-control-on-manipulation-of-resources-via-http">
+	<h3 id="h3_access-control-on-manipulation-of-resources-via-http" role="heading" aria-level="2"><span class="secno">3.1 </span>Access Control on manipulation of resources via HTTP</h3>
+	Adam's user agent attempts:
+	<ol>	
+    <li>To CREATE, READ, UPDATE (or PATCH), or DELETE a resource identified by a URL.  The server may immediately 
+	allow or deny the request, or it may request that he authenticate to confirm his privileges, 
+	as specified by the ACG for the Resource.</li>
+    <li>If he is denied access, an explanation of why all or part of his request was denied should be provided 
+	so that it becomes possible to detect errors, and so that he may modify the request -- 
+	potentially to include making a request for such privileges.
+	</li>
+    <li>Adam would ideally like to know whether he will be able to perform an Action on a Resource 
+	before attempting such - i.e., whether he will have to authenticate before he is able to Read or Write the Resource.
+	</li>
+	</ol></section>
+	<section id="editability-of-access-control-rules-using-http">
+	<h3 id="h3_editability-of-access-control-rules-using-http" role="heading" aria-level="2"><span class="secno">3.2 </span>Editability of Access Control Rules using HTTP</h3>
+	<ol>
+	<li>
+    Bart's user agent logs on to a server and requests
+	the capability to read a group of related resources such as all the papers presented at a conference.</li>
+    
+	<li>Employees with job titles VP or SVP can sign (update) supplier contracts.</li>
+    <li>Charlie, the Webmaster, would like to grant read access to the papers presented at a conference to all the 
+	people who attended the conference.</li>
+	</ol></section>
+	<section id="user-interface-scenarios">
+	<h3 id="h3_user-interface-scenarios" role="heading" aria-level="2"><span class="secno">3.3 </span>User Interface Scenarios</h3>
+	Eddie's HTTP based user agent would like to provide a user interface to allow, where possible, Eddie to 
+	<ol>
+	<li>Know if he can edit or delete a resource.</li>
+    <li>Know what he would have to do to have access to a resource ( be someone's friend, be part of a club, have 
+	paid a fee )</li>
+	<li>Allow Eddie to edit the access control rules for a resource such as:
+	<ol>
+        <li>Allow friends of his to access a document.</li>
+        <li>Allow friends of his to POST to a container, but only read a subset of the contents of the container, 
+		those posted by that agent for example.</li>
+        <li>Allow all the members of the LDP WG to create and edit resources including LDP Containers under a 
+		specific URL pattern.</li>
+		<li>Allow all friends of friends as expressed by the foaf:knows relations in one's foaf profile to POST comments 
+		to a container related to some content, and edit their own comments.</li>
+		<li>Allow the members of the LDP WG, the RWW CG, the WebID CG, and the member of the European Ontologist Network, 
+		to work together on set of ontologies. It should be possible to drag and drop URLs for these groups, 
+		found on the web, onto the User Interface as a way of creating the union of the members of the group.</li> 
+	</ol>
+	</li></ol>
+	</section>
+	<section id="requirements">
+	<h3 id="h3_requirements" role="heading" aria-level="2"><span class="secno">3.4 </span>Requirements</h3>
+	<ul>
+	<li>An Agent must be able to authenticate itself to a server with an identifier or as the owner of a token. 
+	( All use cases )</li>
+    <li>Ability to specify a collection of agents, identifying agents with URIs, URI patterns, or by description. 
+	(Usecase 3.2.2, 3.2.3)</li>
+    <li>Ability to specify a collection of resources, identified by URIs or URI patterns or by description,
+	with a specified access policy. (Usecase 3.2.1, 3.2.3)</li>
+    <li>Ability to connect a collection of agents with a collection of resources with given access privileges. 
+	( All use cases )</li>
+	</ul>
+	
+	<p>The above requirements require the ability, by an authorized agent, to CREATE, EDIT, UPDATE relevant ACGs. 
+
+	</p><ul>
+	<li>Ability to specify access privileges at a fine-grained level. (Usecase 3.1.2, 3.2.1.2)</li>
+    <li>The server should be able to describe access control policies for a resource. (Usecase 3.1.4, 3.3.1, 3.3.2)</li>
+    <li>The server should be able explain the reasons for access being disallowed in a machine readable format.
+	(Usecase 3.1.3)
+	</li>
+    <li>A user-agent should be able to find the ACG for a given resource.(Usecase 3.1.1)</li>
+	<li>The ability by one user agent to delegate the authority to create and edit ACGs to another agent.(Usecase 3.3.3)</li>
+	</ul>
+	</section>
+	<section id="outline-of-a-charter-for-a-access-control-wg">
+	<h3 id="h3_outline-of-a-charter-for-a-access-control-wg" role="heading" aria-level="2"><span class="secno">3.5 </span>Outline of a Charter for a Access Control WG</h3>
+	<p>An Access Control Graph (ACG) consists of two kinds of collections: a collection of agents and a collection of 
+	resources. It then connects a collection of agents with a collection of resources with the connection identifying 
+	the privileges the agents have on the resources: CREATE, READ, UPDATE, DELETE.</p>
+	<p>ACGs are resources in their own right and can have access control priviledges specified for them just like
+	any other resource.  This permits the creation and modification of ACGs to be delegated.
+	</p>
+	<p>
+	The members of the collection of agents contain tokens that the agents obtain from some authentication service. 
+	The members of the collection of resources are URIs or URI templates.</p>
+	<p>The WG will need to decide whether it also wants to define fine-grained access control at an attribute level.</p>
+<section id="deliverables">
+<h4 id="h4_deliverables" role="heading" aria-level="3"><span class="secno">3.5.1 </span>Deliverables</h4>
+<ul>
+<li>Define the collections that are part of the ACG and define how a collection of agents is connected to a 
+connection of resources.</li>
+<li>Define how ACGs can be created and edited and how these rights can be delegated.</li>
+<li>Describe a proof-of-concept implementation of how a request for access to a resource by an agent can be processed 
+efficiently with the ACG structure defined above.</li>
+</ul> 
+</section>	
+	</section>
+	</section>
+    
+    
+  
+
+</body></html>
\ No newline at end of file
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/TR/NOTE-ldp-bp-20140829/Overview.html	Mon Aug 25 16:47:16 2014 -0400
@@ -0,0 +1,1215 @@
+<!DOCTYPE html>
+<html lang="en" dir="ltr" typeof="bibo:Document w3p:NOTE" about="" property="dcterms:language" content="en">
+<head>
+<title>Linked Data Platform Best Practices and Guidelines</title>
+<!-- Changed by: , 25-Aug-2014 -->
+<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://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script -->
+
+
+
+
+
+<style>/*****************************************************************
+ * ReSpec 3 CSS
+ * Robin Berjon - http://berjon.com/
+ *****************************************************************/
+
+/* --- INLINES --- */
+em.rfc2119 { 
+    text-transform:     lowercase;
+    font-variant:       small-caps;
+    font-style:         normal;
+    color:              #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+    border: none;
+}
+
+dfn {
+    font-weight:    bold;
+}
+
+a.internalDFN {
+    color:  inherit;
+    border-bottom:  1px solid #99c;
+    text-decoration:    none;
+}
+
+a.externalDFN {
+    color:  inherit;
+    border-bottom:  1px dotted #ccc;
+    text-decoration:    none;
+}
+
+a.bibref {
+    text-decoration:    none;
+}
+
+cite .bibref {
+    font-style: normal;
+}
+
+code {
+    color:  #C83500;
+}
+
+/* --- TOC --- */
+.toc a, .tof a {
+    text-decoration:    none;
+}
+
+a .secno, a .figno {
+    color:  #000;
+}
+
+ul.tof, ol.tof {
+    list-style: none outside none;
+}
+
+.caption {
+    margin-top: 0.5em;
+    font-style:   italic;
+}
+
+/* --- TABLE --- */
+table.simple {
+    border-spacing: 0;
+    border-collapse:    collapse;
+    border-bottom:  3px solid #005a9c;
+}
+
+.simple th {
+    background: #005a9c;
+    color:  #fff;
+    padding:    3px 5px;
+    text-align: left;
+}
+
+.simple th[scope="row"] {
+    background: inherit;
+    color:  inherit;
+    border-top: 1px solid #ddd;
+}
+
+.simple td {
+    padding:    3px 10px;
+    border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+    background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+    margin-top: 0;
+}
+
+.section dd > p:last-child {
+    margin-bottom: 0;
+}
+
+.section dd {
+    margin-bottom:  1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+    margin-bottom:  0;
+}
+
[email protected] print {
+    .removeOnSave {
+        display: none;
+    }
+}
+</style><style>/* --- EXAMPLES --- */
+div.example-title {
+    min-width: 7.5em;
+    color: #b9ab2d;
+}
+div.example-title span {
+    text-transform: uppercase;   
+}
+aside.example, div.example, div.illegal-example {
+    padding: 0.5em;
+    margin: 1em 0;
+    position: relative;
+    clear: both;
+}
+div.illegal-example { color: red }
+div.illegal-example p { color: black }
+aside.example, div.example {
+    padding: .5em;
+    border-left-width: .5em;
+    border-left-style: solid;
+    border-color: #e0cb52;
+    background: #fcfaee;    
+}
+
+aside.example div.example {
+    border-left-width: .1em;
+    border-color: #999;
+    background: #fff;
+}
+aside.example div.example div.example-title {
+    color: #999;
+}
+</style><link href="https://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" rel="stylesheet"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
+
+
+
+<body id="respecDocument" role="document" class="h-entry"><div id="respecHeader" role="contentinfo" class="head">
+  <p>
+    
+      <a href="http://www.w3.org/"><img src="https://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"></a>
+    
+  </p>
+  <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform Best Practices and Guidelines</h1>
+  
+  <h2 id="w3c-working-group-note-29-august-2014" property="dcterms:issued" datatype="xsd:dateTime" content="2014-08-29T07:00:00.000Z"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note <time class="dt-published" datetime="2014-08-29">29 August 2014</time></h2>
+  <dl>
+    
+      <dt>This version:</dt>
+      <dd><a class="u-url" href="http://www.w3.org/TR/2014/NOTE-ldp-bp-20140829/">http://www.w3.org/TR/2014/NOTE-ldp-bp-20140829/</a></dd>
+      <dt>Latest published version:</dt>
+      <dd><a href="http://www.w3.org/TR/ldp-bp/">http://www.w3.org/TR/ldp-bp/</a></dd>
+    
+    
+      <dt>Latest editor's draft:</dt>
+      <dd><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html</a></dd>
+    
+    
+    
+    
+    
+    
+    
+    <dt>Editors:</dt>
+    <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Cody Burleson" href="http://codyburleson.com/">Cody Burleson</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://base22.com/">Base22</a></span>
+</dd>
+<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Miguel Esteban Gutiérrez" href="http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/phdstudents/27-mesteban">Miguel Esteban Gutiérrez</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oeg-upm.net/">Ontology Engineering Group, Universidad Politécnica de Madrid</a></span>
+</dd>
+<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Nandana Mihindukulasooriya" href="http://www.nandana.org/">Nandana Mihindukulasooriya</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oeg-upm.net/">Ontology Engineering Group, Universidad Politécnica de Madrid</a></span>
+</dd>
+
+    
+    
+  </dl>
+  
+  
+  
+  
+    
+      <p class="copyright">
+        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
+        2014
+        
+        <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
+        (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
+        <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
+        <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), 
+        
+        All Rights Reserved.
+        
+        <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
+        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
+        
+          <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
+        
+        rules apply.
+      </p>
+    
+  
+  <hr>
+</div>
+
+	<section rel="bibo:Chapter" resource="#abstract" typeof="bibo:Chapter" datatype="" property="dcterms:abstract" class="introductory" id="abstract"><h2 id="h2_abstract" role="heading" aria-level="1">Abstract</h2><p>This document provides best practices
+		and guidelines for implementing Linked Data Platform [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] servers
+		and clients.</p></section><section rel="bibo:Chapter" resource="#sotd" typeof="bibo:Chapter" id="sotd" class="introductory"><h2 id="h2_sotd" role="heading" aria-level="1">Status of This Document</h2>
+  
+    
+      
+        <p>
+          <em>This section describes the status of this document at the time of its publication.
+          Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the
+          latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
+          http://www.w3.org/TR/.</em>
+        </p>
+        
+		
+	
+        <p>
+          This document was published by the <a href="http://www.w3.org/2012/ldp">Linked Data Platform Working Group</a> as a Working Group Note.
+          
+          
+            If you wish to make comments regarding this document, please send them to 
+            <a href="mailto:[email protected]">[email protected]</a> 
+            (<a href="mailto:[email protected]?subject=subscribe">subscribe</a>,
+            <a href="http://lists.w3.org/Archives/Public/public-ldp/">archives</a>).
+          
+          
+          
+          
+            All comments are welcome.
+          
+        </p>
+        
+        
+          <p>
+            Publication as a Working Group Note does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr>
+            Membership. This is a draft document and may be updated, replaced or obsoleted by other
+            documents at any time. It is inappropriate to cite this document as other than work in
+            progress.
+          </p>
+        
+        
+        
+        <p>
+          
+            This document was produced by a group operating under the 
+            <a id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent
+            Policy</a>.
+          
+          
+          
+            
+              <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/55082/status" rel="disclosure">public list of any patent
+              disclosures</a> 
+            
+            made in connection with the deliverables of the group; that page also includes
+            instructions for disclosing a patent. An individual who has actual knowledge of a patent
+            which the individual believes contains
+            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
+            Claim(s)</a> must disclose the information in accordance with
+            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
+            6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+          
+          
+        </p>
+        
+          <p>This document is governed by the <a id="w3c_process_revision" href="http://www.w3.org/2014/Process-20140801/">1 August 2014 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.
+          </p>
+        
+        
+      
+    
+  
+</section><section id="toc"><h2 id="h2_toc" role="heading" aria-level="1" class="introductory">Table of Contents</h2><ul id="respecContents" role="directory" class="toc"><li class="tocline"><a class="tocxref" href="#intro"><span class="secno">1. </span>About this Document</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#impetus"><span class="secno">1.1 </span>Impetus</a></li><li class="tocline"><a class="tocxref" href="#terminology"><span class="secno">1.2 </span>Terminology</a></li><li class="tocline"><a class="tocxref" href="#prerequisites-and-assumptions"><span class="secno">1.3 </span>Prerequisites and Assumptions</a></li></ul></li><li class="tocline"><a class="tocxref" href="#best-practices"><span class="secno">2. </span>Best Practices</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#predicate-uris-should-be-http-urls"><span class="secno">2.1 </span>Predicate URIs should be HTTP URLs</a></li><li class="tocline"><a class="tocxref" href="#use-and-include-the-predicate-rdf-type-to-represent-the-concept-of-type-in-ldprs"><span class="secno">2.2 </span>Use and include the predicate rdf:type to represent the
+				concept of type in LDPRs</a></li><li class="tocline"><a class="tocxref" href="#use-relative-uris"><span class="secno">2.3 </span>Use relative URIs</a></li><li class="tocline"><a class="tocxref" href="#avoid-dot-segments-in-uris-of-posted-content-or-use-with-caution"><span class="secno">2.4 </span>Avoid dot-segments in URIs of POSTed content or use with caution</a></li><li class="tocline"><a class="tocxref" href="#represent-container-membership-with-hierarchical-uris"><span class="secno">2.5 </span>Represent container membership with hierarchical URIs</a></li><li class="tocline"><a class="tocxref" href="#include-a-trailing-slash-in-container-uris"><span class="secno">2.6 </span>Include a trailing slash in container URIs</a></li><li class="tocline"><a class="tocxref" href="#use-fragments-as-relative-identifiers"><span class="secno">2.7 </span>Use fragments as relative identifiers</a></li><li class="tocline"><a class="tocxref" href="#prefer-standard-datatypes"><span class="secno">2.8 </span>Prefer standard datatypes</a></li><li class="tocline"><a class="tocxref" href="#re-use-established-linked-data-vocabularies-instead-of-re--inventing-duplicates"><span class="secno">2.9 </span>Re-use established linked data vocabularies instead of
+				(re-)inventing duplicates</a></li><li class="tocline"><a class="tocxref" href="#use-qvalues-properly"><span class="secno">2.10 </span>Use qvalues properly</a></li><li class="tocline"><a class="tocxref" href="#respond-with-primary-urls-and-use-them-for-identity-comparison"><span class="secno">2.11 </span>Respond with primary URLs and use them for identity comparison</a></li><li class="tocline"><a class="tocxref" href="#representing-relationships-between-resources"><span class="secno">2.12 </span>Representing relationships between resources</a></li><li class="tocline"><a class="tocxref" href="#minimize-server-specific-constraints"><span class="secno">2.13 </span>Minimize server-specific constraints</a></li></ul></li><li class="tocline"><a class="tocxref" href="#guidelines"><span class="secno">3. </span>Guidelines</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#containers-are-not-limited-to-membership-and-containment-triples"><span class="secno">3.1 </span>Containers are not limited to membership and containment triples</a></li><li class="tocline"><a class="tocxref" href="#finding-established-vocabularies"><span class="secno">3.2 </span>Finding established vocabularies</a></li></ul></li><li class="tocline"><a class="tocxref" href="#acknowledgements"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a class="tocxref" href="#references"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#informative-references"><span class="secno">B.1 </span>Informative references</a></li></ul></li></ul></section>
+
+	
+
+
+	<section rel="bibo:Chapter" resource="#intro" typeof="bibo:Chapter" id="intro">
+
+		<!--OddPage--><h2 id="h2_intro" role="heading" aria-level="1"><span class="secno">1. </span>About this Document</h2>
+
+		<section id="impetus">
+
+			<h3 id="h3_impetus" role="heading" aria-level="2"><span class="secno">1.1 </span>Impetus</h3>
+
+			<p>While writing the Linked Data Platform Specification, the
+				authors and contributors felt compelled to share common conventions
+				and valuable lessons-learned. Yet, at the same time, they did not
+				wish to impose or imply unnecessary restrictions, or to make the
+				formal specification unnecessarily verbose. This document, along
+				with the LDP Primer [<cite><a href="#bib-LDP-PRIMER" class="bibref">LDP-PRIMER</a></cite>], was therefore developed to
+				provide additional context. Drawing upon the professional
+				experiences of its authors and contributors, research into the rich
+				history of related technologies, and continuous feedback from the
+				community at large, it aims to help system implementers avoid common
+				pitfalls, improve quality, and achieve greater interoperability with
+				other Linked Data systems.</p>
+
+		</section>
+
+		<section id="terminology">
+
+			<h3 id="h3_terminology" role="heading" aria-level="2"><span class="secno">1.2 </span>Terminology</h3>
+
+			<p>For the purposes of this document, it is useful to
+				make a minor, yet important distinction between the term 'best
+				practice' and the term 'guideline'. We define and differentiate 
+				the terms as follows:</p>
+
+			<dl>
+				<dt>best practice</dt>
+				<dd>An implementation practice (method or technique) that has
+					consistently shown results superior to those achieved with other
+					means and that is used as a benchmark. Best practices within this
+					document apply specifically to the ways that LDP servers and
+					clients are implemented as well as how certain resources are
+					prepared and used with them. In this document, the best practices
+					might be used as a kind of check-list against which an implementer
+					can directly evaluate a system's design and code. Lack of adherence
+					to any given best practice, however, does not necessarily imply a
+					lack of quality; they are recommendations that are said to be
+					'best' in most cases and in most contexts, but not all. A best
+					practice is always subject to improvement as we learn and evolve
+					the Web together.</dd>
+				<dt>guideline</dt>
+				<dd>A tip, a trick, a note, a suggestion, or answer to a
+					frequently asked question. Guidelines within this document provide
+					useful information that can advance an implementer's knowledge and
+					understanding, but that may not be directly applicable to an
+					implementation or recognized by consensus as a 'best practice'.</dd>
+			</dl>
+
+			<p>Please see the Terminology section in Linked Data Platform 1.0
+				[<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] as well as the Linked Data Glossary [<cite><a href="#bib-LD-GLOSSARY" class="bibref">LD-GLOSSARY</a></cite>] for
+				definitions to a variety of terms used in this document and related
+				to the Linked Data sphere of knowledge.</p>
+
+		</section>
+
+		<section id="prerequisites-and-assumptions">
+
+			<h3 id="h3_prerequisites-and-assumptions" role="heading" aria-level="2"><span class="secno">1.3 </span>Prerequisites and Assumptions</h3>
+
+			<p>
+				Implementers should have at least a general familiarity with the <a href="#informative-references">informative references</a> cited in
+				this document - especially the following:
+			</p>
+
+			<ul>
+				<li><strong>RDF Vocabulary Description Language 1.0: RDF Schema</strong> 
+					[<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>] - The Resource Description Framework
+					(RDF) is a general-purpose language for representing information in
+					the Web and it is the defacto language for expressing Linked Data.
+					This specification describes how to use RDF to describe RDF
+					vocabularies.</li>
+				<li><strong>RDF Primer 1.1</strong> [<cite><a href="#bib-RDF-PRIMER11" class="bibref">RDF-PRIMER11</a></cite>] - This Primer is designed to
+					provide the reader with the basic knowledge required to effectively
+					use RDF. It introduces the basic concepts of RDF and describes its
+					XML syntax. It describes how to define RDF vocabularies using the
+					RDF Vocabulary Description Language, and gives an overview of some
+					deployed RDF applications. It also describes the content and
+					purpose of other RDF specification documents.</li>
+				<li><strong>Turtle - Terse RDF Triple Language</strong>
+					[<cite><a href="#bib-TURTLE" class="bibref">TURTLE</a></cite>] - defines a textual syntax for RDF called Turtle that
+					allows RDF graphs to be completely written in a compact and natural
+					text form, with abbreviations for common usage patterns and
+					datatypes. RDF examples used in this document are expressed in
+					Turtle.</li>
+				<li><strong>Linked Data Glossary</strong> [<cite><a href="#bib-LD-GLOSSARY" class="bibref">LD-GLOSSARY</a></cite>] - a
+					useful glossary containing terms defined and used to describe
+					Linked Data, and its associated vocabularies and best practices for
+					publishing structured data on the Web.</li>
+				<li><strong>Linked Data Platform 1.0</strong> [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] - the
+					formal specification for the LDP read-write Linked Data
+					architecture, based on HTTP access to web resources that describe
+					their state using the RDF data model.
+				</li><li><strong>Linked Data Platform 1.0 Test Cases</strong>
+					[<cite><a href="#bib-LDP-TESTS" class="bibref">LDP-TESTS</a></cite>] - a standard set of tests provided by the <abbr title="World Wide Web Consortium">W3C</abbr>, which
+					can be use to verify an implementation's conformance to the LDP
+					specification.</li>
+				<li><strong>Linked Data Platform Primer</strong> [<cite><a href="#bib-LDP-PRIMER" class="bibref">LDP-PRIMER</a></cite>]
+					- an introduction to LDP, which describes the basic concepts of LDP
+					such as Linked Data Platform Resources (LDPRs), Linked Data
+					Platform Containers (LDPCs), and their affordances. The Primer
+					provides a running example illustrating how an LDP client can
+					interact with an LDP server in the context of a read-write Linked
+					Data application (i.e. how to use HTTP for accessing, updating,
+					creating and deleting resources from servers that expose their
+					resources as Linked Data).</li>
+				<li><strong>Linked Data Platform Use Cases and
+						Requirements</strong> [<cite><a href="#bib-LDP-UCR" class="bibref">LDP-UCR</a></cite>] - a set of user stories, use cases,
+					scenarios and requirements that motivate a simple read-write Linked
+					Data architecture, based on HTTP access to web resources that
+					describe their state using RDF.</li>
+			</ul>
+
+		</section>
+
+	</section>
+
+	<section id="best-practices">
+
+		<!--OddPage--><h2 id="h2_best-practices" role="heading" aria-level="1"><span class="secno">2. </span>Best Practices</h2>
+
+		<section id="predicate-uris-should-be-http-urls">
+
+			<h3 id="h3_predicate-uris-should-be-http-urls" role="heading" aria-level="2"><span class="secno">2.1 </span>Predicate URIs should be HTTP URLs</h3>
+
+			<p>URIs are used to uniquely identify resources and URLs are used
+				to locate resources on the Web. That is to say that a URL is
+				expected to resolve to an actual resource, which can be retrieved
+				from the host. A URI, on the other hand, may also be a URL, but it
+				does not have to be; it may refer to something that has no
+				retrievable representation.</p>
+
+			<p>One of the fundamental ideas behind Linked Data is that the
+				things referred to by HTTP URIs can actually be looked up
+				("dereferenced"). This important principle was originally
+				outlined by Tim Berners-Lee as rule #2 of "the four rules"
+				for linking data [<cite><a href="#bib-LD-DI" class="bibref">LD-DI</a></cite>]. It is therefore ideal that predicate
+				URIs identify resources with representations that are retrievable. LDP
+				servers should at least provide [<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>] representations of
+				these predicates where possible.</p>
+
+			<p>Of course, it is also a common practice to reuse properties
+				from open vocabularies that are publicly available. In this case,
+				implementers have no control over the result when attempting to
+				dereference the URI. For this reason, publishers who wish to make
+				their vocabularies useful for linking data should strive to provide
+				a retrievable representation of the properties their vocabularies
+				define. Consequently, implementers are also expected to use this
+				practice as a benchmark for which to judge the efficacy of a
+				vocabulary's use for linking data.</p>
+
+		</section>
+
+		<section id="use-and-include-the-predicate-rdf-type-to-represent-the-concept-of-type-in-ldprs">
+
+			<h3 id="h3_use-and-include-the-predicate-rdf-type-to-represent-the-concept-of-type-in-ldprs" role="heading" aria-level="2"><span class="secno">2.2 </span>Use and include the predicate rdf:type to represent the
+				concept of type in LDPRs</h3>
+
+			<p>
+				It is often very useful to know the type (class) of an LDPR, though
+				it is not essential to work with the interaction capabilities that
+				LDP offers. Still, to make data more useful in the broadest context,
+				type should be explicitly defined using the <code>rdf:type</code>
+				predicate defined by [<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>].
+			</p>
+
+			<p>This provides a way for clients to easily determine the type(s)
+				of a resource without having to perform additional processing or
+				make additional HTTP requests. For example, clients that cannot
+				infer the type because they do not support inferencing can benefit
+				from this explicit declaration.</p>
+
+			<div class="example"><div class="example-title"><span>Example 1</span>: Representation of an LDPR with explicit declaration of rdf:type</div><pre class="example">@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
[email protected] contact: &lt;http://www.w3.org/2000/10/swap/pim/contact#&gt;.
+
+&lt;http://www.w3.org/People/EM/contact#me&gt; 
+  a contact:Person;
+  contact:fullName "Eric Miller";
+  contact:mailbox &lt;mailto:[email protected]&gt;;
+  contact:personalTitle "Dr.".</pre></div>
+
+			<p>The token 'a' in the predicate position of a Turtle triple represents the IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#type. 
+			In the example above, therefore, <code>a contact:Person</code> is the same as <code>rdf:type contact:Person</code> or the fully-qualified form, <code>&lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#type&gt; contact:Person</code>.</p>
+
+		</section>
+
+		<section id="use-relative-uris">
+
+			<h3 id="h3_use-relative-uris" role="heading" aria-level="2"><span class="secno">2.3 </span>Use relative URIs</h3>
+
+			<!-- http://www.w3.org/2012/ldp/track/issues/29 -->
+
+			<p>Relative URIs are useful to the Linked Data Platform in much
+				the same ways that relative URLs [<cite><a href="#bib-RFC3986" class="bibref">RFC3986</a></cite>] have been useful to
+				traditional web systems. Since the things referred to by Linked Data
+				URIs should provide a retrievable representation [<cite><a href="#bib-LD-DI" class="bibref">LD-DI</a></cite>], Linked
+				Data URIs are usually also URLs; they locate rather than just
+				identify. As such, the utilitarian value of relative URLs still
+				applies; especially since the LDP Container model promotes
+				hierarchical representations.</p>
+
+			<p>Implementers should therefore align the function of relative
+				URIs in LDP with those of traditional relative URLs where possible
+				and appropriate. Aside from giving developers the comfort and
+				convenience of familiarity, they provide many of the same
+				advantages.</p>
+
+			<dl>
+				<dt>Relative URIs are shorter than absolute URIs.</dt>
+				<dd>
+					<p>In many cases, this can aid development by making code and
+						RDF easier for humans to read. It can also reduce the size of
+						payloads, which in turn, can reduce network traffic and stress on
+						servers, while improving response times for end-users.</p>
+
+					<div class="example"><div class="example-title"><span>Example 2</span>: Representation of http://example.org/container1/ with absolute URIs</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+
+&lt;http://example.org/container1/&gt;
+   a a ldp:Container, ldp:BasicContainer;
+   dcterms:title "A very simple container";
+   ldp:contains
+      &lt;http://example.org/container1/member1&gt;,
+      &lt;http://example.org/container1/member2&gt;,
+      &lt;http://example.org/container1/member3&gt;.</pre></div>
+
+
+					<div class="example"><div class="example-title"><span>Example 3</span>: Representation of http://example.org/container1/ with relative URIs</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+
+&lt;&gt; a a ldp:Container, ldp:BasicContainer;
+   dcterms:title "A very simple container";
+   ldp:contains &lt;member1&gt;, &lt;member2&gt;, &lt;member3&gt; .</pre></div>
+
+				</dd>
+
+				<dt>Relative URIs can make resources more portable.</dt>
+				<dd>When information which is already known from the context of
+					the base resource's retrieval is omitted, there can be less
+					information to modify when its location changes. This can make
+					copying resources to new servers or to a new position in a
+					containment hierarchy easier; in the preceding example, 
+					a process that clones just the container need not adjust any of
+					its member URIs.
+					</dd>
+
+				<dt>Relative URIs are convenient during development.</dt>
+				<dd>During development the scheme and network location
+					information in a URI may either be unknown or likely to change. The
+					commonly used 'localhost' for example, is better expressed by the
+					server name or a domain name. Developers often experience less
+					hassle by omitting this information. Additionally, the hierarchy
+					implied by a relative URI may be mimicked in a server file system,
+					which can help developers find and work with information, even when
+					the server isn't running.</dd>
+
+				<dt>Relative URIs support arbitrary, machine-generated URIs.</dt>
+				<dd>
+					RESTful URLs are often defined by a pattern of hierarchical
+					'collections', which clients interact with in very logical ways.
+					For example, when creating a new resource the client does not
+					typically know the name of the resource until after a successful
+					POST to a collection's URL. A POST to
+					<code>/people/</code>
+					for example, may create the resource
+					<code>/people/1</code>
+					. LDP Containers are such collections whose URIs can benefit from
+					the same model, which in some implementations, may actually be
+					crucial.
+				</dd>
+			</dl>
+		</section>
+
+		<section id="avoid-dot-segments-in-uris-of-posted-content-or-use-with-caution">
+			<h3 id="h3_avoid-dot-segments-in-uris-of-posted-content-or-use-with-caution" role="heading" aria-level="2"><span class="secno">2.4 </span>Avoid dot-segments in URIs of POSTed content or use with caution</h3>
+
+			<p>The semantics of dot-segments (eg. <code>../</code>) within relative URIs may be implied by other 
+			specifications and by common historical use, but in the case of LDP, additional consideration is required.</p>
+
+			<p>The LDP specification states that... </p><blockquote>LDP servers <em title="MUST" class="rfc2119">MUST</em> assign the default base-URI for [<cite><a href="#bib-RFC3987" class="bibref">RFC3987</a></cite>] relative-URI resolution 
+			to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation 
+			of a new resource.</blockquote> It follows from this definition that use of <code>../</code> and other non-null relative URI constructs during 
+			POST can cause the posted content to be referring to resources in a manner the client might not be able to predict. 
+			Dot-segments should therefore be avoided unless the client knows specifically what can be expected of the given implementation 
+			and/or deployment.<p></p>
+		</section>
+
+
+		<section id="represent-container-membership-with-hierarchical-uris">
+
+			<h3 id="h3_represent-container-membership-with-hierarchical-uris" role="heading" aria-level="2"><span class="secno">2.5 </span>Represent container membership with hierarchical URIs</h3>
+
+			<p>Hierarchical URIs are good for containers because they enable
+				the use of relative URIs. They also promote easy interaction with
+				resources that are modeled to represent parent-child relationships
+				where the child logically belongs to the parent.</p>
+
+			<p>
+				One example of such a model can be found in the case of the
+				<code>oslc_cm:attachment</code>
+				container from the vocabularies defined by the <a href="http://open-services.net/">Open Service for Lifecycle
+					Management (OSLC)</a> community. The OSLC defines specifications and
+				vocabularies that are well-aligned to LDP. A resource in an OSLC
+				compliant change management system such as an issue or bug tracker
+				may have attachments represented by the
+				<code>oslc_cm:attachment</code>
+				container. The URI for such a container might be represented as
+				follows:
+			</p>
+
+			<p>
+				<code>http://example.org/bugs/2314/attachments/</code>
+			</p>
+
+			<p>From this URI, the URI of the parent resource which holds the
+				attachments is easily discerned. The base container for other
+				sibling resources can be discerned by moving up the hierarchy, which
+				is implied by the URI. Meta-data or binary content might be fetched
+				further down the hierarchy by using a URI such as the following:</p>
+
+			<p>
+				<code>http://example.org/bugs/2314/attachments/1</code>
+			</p>
+
+			<p>In addition to making the use of relative URIs possible,
+				hierarchical URIs make interacting with resources easier for users because
+				they represent the actual structure of the underlying graph.
+				Software agents (code acting on behalf of users [<cite><a href="#bib-WEBARCH" class="bibref">WEBARCH</a></cite>]) must be careful
+				before exploiting the structure of URIs, considering historical problems
+				when doing so ([<cite><a href="#bib-WEBARCH" class="bibref">WEBARCH</a></cite>], [<cite><a href="#bib-metaDataInURI" class="bibref">metaDataInURI</a></cite>]).
+				</p>
+
+		</section>
+
+
+		<section id="include-a-trailing-slash-in-container-uris">
+
+			<!-- http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0071.html -->
+
+			<h3 id="h3_include-a-trailing-slash-in-container-uris" role="heading" aria-level="2"><span class="secno">2.6 </span>Include a trailing slash in container URIs</h3>
+
+			<p>When representing container membership with hierarchical URLs,
+				including the trailing slash in a container's URI makes it 
+				easier to use relative URIs.
+				Take the following container URI for example:</p>
+
+			<p>
+				<code>http://example.org/container1</code>
+			</p>
+
+			<p>It is more advantageous to use the following instead:</p>
+
+			<p>
+				<code>http://example.org/container1/</code>
+			</p>
+
+			<p>To illustrate the advantage, let's start with the following
+				container using absolute URIs:</p>
+
+			<div class="example"><div class="example-title"><span>Example 4</span>: A simple container</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+
+&lt;http://example.org/container1&gt;
+   a a ldp:Container, ldp:BasicContainer;
+   dcterms:title "A very simple container";
+   ldp:contains
+      &lt;http://example.org/container1/member1&gt;,
+      &lt;http://example.org/container1/member2&gt;,
+      &lt;http://example.org/container1/member3&gt;.</pre></div>
+
+			<p>Suppose now that we wish to reflect the same resource using
+				relative URIs. If the URI of the container includes the trailing
+				slash, we end up with a very elegant representation, as shown below.</p>
+
+			<div class="example"><div class="example-title"><span>Example 5</span>: Container URI is http://example.org/container1/</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+
+&lt;&gt; a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains &lt;member1&gt;, &lt;member2&gt;, &lt;member3&gt; .</pre></div>
+
+			<p>But suppose that we omit the trailing slash, issued an HTTP
+				GET, and the container returned the representation shown above. This
+				could produce a graph that is equivalent to the following:</p>
+
+			<div class="example"><div class="example-title"><span>Example 6</span>: Container URI is http://example.org/container1</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+
+&lt;http://example.org/container1&gt;
+   a a ldp:Container, ldp:BasicContainer;
+   dcterms:title "A very simple container";
+   ldp:contains
+      &lt;http://example.org/member1&gt;,
+      &lt;http://example.org/member2&gt;,
+      &lt;http://example.org/member3&gt;.</pre></div>
+
+			<p>That is not what was intended; the member URLs lack the 
+				<code>container</code> path segment.
+				The returned document would
+				have to be more verbose in order to be correct:</p>
+
+			<div class="example"><div class="example-title"><span>Example 7</span>: Container URI is http://example.org/container1</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+
+&lt;&gt; a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains &lt;container1/member1&gt;, &lt;container1/member2&gt;, &lt;container1/member3&gt; .</pre></div>
+
+			<p>So, clearly, the better solution is to ensure that container
+				URIs end with a trailing slash.</p>
+
+		</section>
+
+
+		<section id="use-fragments-as-relative-identifiers">
+
+			<h3 id="h3_use-fragments-as-relative-identifiers" role="heading" aria-level="2"><span class="secno">2.7 </span>Use fragments as relative identifiers</h3>
+
+			<p>
+				Resource URIs are permitted to end with a fragment; the fragment
+				component is delimited from the rest of the URI because it is
+				introduced by a hash mark (<b><code>#</code></b>).
+				For this reason, URIs with non-empty fragments are often called hash URIs;
+				a hash URI identifies a subordinate or related resource [<cite><a href="#bib-RFC3986" class="bibref">RFC3986</a></cite>].
+			</p>
+
+			<p>
+				Take the URI,
+				<code>http://www.example.org/products#item10245</code>
+				, for example. The non-fragment portion of the URI is the part preceding the hash mark,
+				<code>http://www.example.org/products</code>
+				, and the fragment identifier is the part that follows,
+				<code>item10245</code>
+				.
+			</p>
+
+			<p>When expressing Linked Data Platform Resources in RDF,
+				fragments are useful because they can be expressed as relative URIs
+				on the document describing them. This is particularly handy for
+				describing multiple LDPRs whose representations are contained within
+				a single document.</p>
+
+			<p>
+				First, it provides the convenience and efficiency of brevity.
+				Suppose, for example, the resources foo, bar, and baz are
+				contained in the same document. Since serving all of the
+				descriptions in a single document is acceptable, we can mint
+				relative URIs within the document using the fragment identifier (
+				<code>&lt;#foo&gt;</code>
+				,
+				<code>&lt;#bar&gt;</code>
+				and
+				<code>&lt;#baz&gt;</code>
+				).  [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] ensures that the default base URI is the document
+				URI (
+				<code>http://www.example.org/products</code>
+				), so the absolute URI for each is 
+				the base URI, plus the hash mark,
+				plus the fragment identifier.
+			</p>
+
+
+			<p>Second, it can help avoid certain complexities inherent with
+				other approaches. Achieving the same result using three independent
+				dereferenceable URIs could be more involved because multiple
+				documents would have to be published, perhaps also including the
+				setup of 303 redirects.</p>
+
+			<p>
+				<strong>See also:</strong>
+			</p>
+
+			<p>
+				<a href="http://www.w3.org/TR/cooluris">Cool URIs for the
+					Semantic Web</a>
+			</p><ul>
+				<li><a href="http://www.w3.org/TR/cooluris/#hashuri">http://www.w3.org/TR/cooluris/#hashuri</a></li>
+				<li><a href="http://www.w3.org/TR/cooluris/#choosing">http://www.w3.org/TR/cooluris/#choosing</a></li>
+			</ul>
+			<p></p>
+
+			<p>
+				<a href="http://www.w3.org/DesignIssues/Fragment.html">Axioms of
+					Web Architecture, URI References: Fragment Identifiers on URIs</a><br>
+				http://www.w3.org/DesignIssues/Fragment.html
+			</p>
+
+			<p>
+				<a href="http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14">Dereferencing
+					HTTP URIs</a><br>
+				http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14
+			</p>
+
+		</section>
+
+
+		<section id="prefer-standard-datatypes">
+			<h3 id="h3_prefer-standard-datatypes" role="heading" aria-level="2"><span class="secno">2.8 </span>Prefer standard datatypes</h3>
+
+			<p>LDPR representations should 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 [<cite><a href="#bib-XMLSCHEMA11-2" class="bibref">XMLSCHEMA11-2</a></cite>] and [<cite><a href="#bib-RDF-PRIMER11" class="bibref">RDF-PRIMER11</a></cite>] should be used:</p>
+
+			<table class="simple">
+				<thead>
+					<tr>
+						<th>URI</th>
+						<th>Description</th>
+					</tr>
+				</thead>
+				<tbody>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#boolean">http://www.w3.org/2001/XMLSchema#boolean</a></td>
+						<td>Boolean type as specified by XSD Boolean</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#date">http://www.w3.org/2001/XMLSchema#date</a></td>
+						<td>Date type as specified by XSD date</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#dateTime">http://www.w3.org/2001/XMLSchema#dateTime</a></td>
+						<td>Date and Time type as specified by XSD dateTime</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#decimal">http://www.w3.org/2001/XMLSchema#decimal</a></td>
+						<td>Decimal number type as specified by XSD Decimal</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#double">http://www.w3.org/2001/XMLSchema#double</a></td>
+						<td>Double floating-point number type as specified by XSD
+							Double</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#float">http://www.w3.org/2001/XMLSchema#float</a></td>
+						<td>Floating-point number type as specified by XSD Float</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#hexBinary">http://www.w3.org/2001/XMLSchema#hexBinary</a></td>
+						<td>Arbitrary hex-encoded binary data as specified by XSD hexBinary</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#integer">http://www.w3.org/2001/XMLSchema#integer</a></td>
+						<td>Integer number type as specified by XSD Integer</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#string">http://www.w3.org/2001/XMLSchema#string</a></td>
+						<td>String type as specified by XSD String</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#base64Binary">http://www.w3.org/2001/XMLSchema#base64Binary</a></td>
+						<td>Binary type as specified by XSD Base64Binary</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral</a></td>
+						<td>Literal XML value as specified by RDF</td>
+					</tr>
+				</tbody>
+			</table>
+
+		</section>
+
+
+		<section id="re-use-established-linked-data-vocabularies-instead-of-re--inventing-duplicates">
+
+			<h3 id="h3_re-use-established-linked-data-vocabularies-instead-of-re--inventing-duplicates" role="heading" aria-level="2"><span class="secno">2.9 </span>Re-use established linked data vocabularies instead of
+				(re-)inventing duplicates</h3>
+
+			<p>
+				This section summarizes some well-known RDF vocabularies that should
+				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 resource has a description, and the application semantics of
+				that description is compatible with
+				<code>dcterms:description</code>
+				, then
+				<code>dcterms:description</code>
+				should be used. If needed, additional application-specific
+				predicates may be used. A specification for a domain may require one
+				or more of these properties for a particular resource type. The
+				Range column in the tables below identifies the defined
+				<code>rdfs:range</code>
+				for the properties.
+			</p>
+
+			<h3 id="common-properties">Common Properties</h3>
+
+			<p>
+				<strong>From Dublin Core URI: <a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a></strong>
+			</p>
+
+			<table class="simple">
+				<thead>
+					<tr>
+						<th>Property</th>
+						<th>Range/DataType</th>
+						<th>Comment</th>
+					</tr>
+				</thead>
+				<tbody>
+					<tr>
+						<td>dcterms:contributor</td>
+						<td>dcterms:Agent</td>
+						<td></td>
+					</tr>
+					<tr>
+						<td>dcterms:creator</td>
+						<td>dcterms:Agent</td>
+						<td></td>
+					</tr>
+					<tr>
+						<td>dcterms:created</td>
+						<td>xsd:dateTime</td>
+						<td></td>
+					</tr>
+					<tr>
+						<td>dcterms:description</td>
+						<td>rdf:XMLLiteral</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 element.</td>
+					</tr>
+					<tr>
+						<td>dcterms:identifier</td>
+						<td>rdfs:Literal</td>
+						<td></td>
+					</tr>
+					<tr>
+						<td>dcterms:modified</td>
+						<td>xsd:dateTime</td>
+						<td></td>
+					</tr>
+					<tr>
+						<td>dcterms:relation</td>
+						<td>rdfs:Resource</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>dcterms:subject</td>
+						<td>rdfs:Resource</td>
+						<td></td>
+					</tr>
+					<tr>
+						<td>dcterms:title</td>
+						<td>rdf:XMLLiteral</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 element.</td>
+					</tr>
+				</tbody>
+			</table>
+
+			<p>
+				The predicate
+				<code>dcterms:type</code>
+				should not be used, instead use
+				<code>rdf:type</code>
+				. [<cite><a href="#bib-DC-RDF" class="bibref">DC-RDF</a></cite>].
+			</p>
+
+			<p>
+				<strong>From RDF URI: <a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a></strong>
+			</p>
+
+			<table class="simple">
+				<thead>
+					<tr>
+						<th>Property</th>
+						<th>Range/DataType</th>
+						<th>Comment</th>
+					</tr>
+				</thead>
+				<tbody>
+					<tr>
+						<td>rdf:type</td>
+						<td>rdfs:Class</td>
+						<td>The type or types of the resource</td>
+					</tr>
+				</tbody>
+			</table>
+
+			<p>
+				<strong>From RDF Schema URI: <a href="http://www.w3.org/2000/01/rdf-schema#">http://www.w3.org/2000/01/rdf-schema#</a></strong>
+			</p>
+
+			<table class="simple">
+				<thead>
+					<tr>
+						<th>Property</th>
+						<th>Range/DataType</th>
+						<th>Comment</th>
+					</tr>
+				</thead>
+				<tbody>
+					<tr>
+						<td>rdfs:member</td>
+						<td>rdfs:Resource</td>
+						<td>&nbsp;</td>
+					</tr>
+					<tr>
+						<td>rdfs:label</td>
+						<td>rdfs:Literal</td>
+						<td>Only use this in vocabulary documents, to define the name
+							of the vocabulary term.</td>
+					</tr>
+				</tbody>
+			</table>
+
+
+
+		</section>
+
+
+		<section id="use-qvalues-properly">
+			<h3 id="h3_use-qvalues-properly" role="heading" aria-level="2"><span class="secno">2.10 </span>Use qvalues properly</h3>
+
+			<p>Quality factors allow the user or user agent to indicate the
+				relative degree of preference for a media-range, using the qvalue
+				scale from 0 to 1. The default value is q=1. Take the following for
+				example:</p>
+
+			<p>
+				<code>Accept: text/turtle; q=0.5, application/json</code>
+			</p>
+
+			<p>This should be interpreted as "I prefer application/json, but
+				send me text/turtle if it is the best available after a 50%
+				mark-down in quality."</p>
+
+			<p>Improper handling of qvalues is a common problem in
+				implementations of content negotiation.
+			</p><p>Refer to Section 14, Header Field Definitions, in the
+				[<cite><a href="#bib-HTTP11" class="bibref">HTTP11</a></cite>] specification to understand the proper use and evaluation
+				of qvalues for both client and server implementations.</p>
+
+		</section>
+
+		<section id="respond-with-primary-urls-and-use-them-for-identity-comparison">
+			<h3 id="h3_respond-with-primary-urls-and-use-them-for-identity-comparison" role="heading" aria-level="2"><span class="secno">2.11 </span>Respond with primary URLs and use them for identity comparison</h3>
+
+			<p>Clients can access an LDPR using multiple URLs. An LDP server
+				should respond to each of those requests using a single consistent
+				URL, a primary URL, for the LDPR. This primary URL may be found
+				in the response's Location and/or Content-Location headers, and
+				potentially also in the representation of the LDPR. A common case is
+				URLs that vary by protocol, one HTTP and one HTTPS, but are
+				otherwise identical. In most cases those two URLs refer to the same
+				resource, and the server should respond to requests on either URL
+				with a single (primary) URL.</p>
+
+			<p>Clients should use the primary URL as an LDPR's identity;
+				for example, when determining if two URLs refer to the same resource
+				clients should compare the primary URLs, not the URLs used to
+				access the resources.  Note that this usage <em>does</em> imply that the
+				client has sufficient reason to trust the headers and/or content
+				by which the primary URL is communicated to the client, which is 
+				beyond what HTTP alone can guarantee [<cite><a href="#bib-RFC7231" class="bibref">RFC7231</a></cite>].
+				</p>
+
+		</section>
+
+		<section id="representing-relationships-between-resources">
+			<h3 id="h3_representing-relationships-between-resources" role="heading" aria-level="2"><span class="secno">2.12 </span>Representing relationships between resources</h3>
+			<p>LDPRs can use one RDF triple to represent a link
+				(relationship) to another resource. Having the source resource’s URI
+				as the subject and the target resource’s URI as the object of the
+				triple is enough. Contrary to a misconception that readers with
+				certain backgrounds may assume, the creation of an
+				"intermediate link" resource is not required to express
+				the relationship.</p>
+		</section>
+
+		<section id="minimize-server-specific-constraints">
+			<h3 id="h3_minimize-server-specific-constraints" role="heading" aria-level="2"><span class="secno">2.13 </span>Minimize server-specific constraints</h3>
+			<p>LDP servers should enable simple creation and modification of
+				LDPRs.</p>
+
+			<p>It may be common for LDP servers to put restrictions on
+				representations – for example, the range of rdf:type predicates,
+				datatypes of the objects of predicates, and the number of
+				occurrences of predicates in an LDPR, but servers should minimize
+				such restrictions.</p>
+
+			<p>For some server applications, excessive constraints on
+				modification of resources may be required. However, enforcement of
+				more complex constraints will greatly restrict the set of clients
+				that can modify resources. For interoperability with a wider range
+				of clients, implementers are therefore encouraged to minimize
+				server-specific constraints.</p>
+		</section>
+
+	</section>
+	<!-- End Best Practices Section -->
+
+	<section id="guidelines">
+
+		<!--OddPage--><h2 id="h2_guidelines" role="heading" aria-level="1"><span class="secno">3. </span>Guidelines</h2>
+
+		<section id="containers-are-not-limited-to-membership-and-containment-triples">
+
+			<h3 id="h3_containers-are-not-limited-to-membership-and-containment-triples" role="heading" aria-level="2"><span class="secno">3.1 </span>Containers are not limited to membership and containment triples</h3>
+
+			<p>It is important to remember that a Linked Data Platform
+				Container (LDPC) is also a Linked Data Platform RDF Source (LDP-RS) and
+				though it might exist as a membership controller, it may also represent 
+				additional data that is valuable to the agents that access
+				it.</p>
+
+		</section>
+
+		<section id="finding-established-vocabularies">
+			<h3 id="h3_finding-established-vocabularies" role="heading" aria-level="2"><span class="secno">3.2 </span>Finding established vocabularies</h3>
+
+			<p>Following are some useful resources for finding and leveraging
+				pre-existing, common, and well-established vocabularies.</p>
+
+
+			<ul>
+				<li><strong>Linked Open Vocabularies (LOV)</strong> 
+					[<cite><a href="#bib-LOV" class="bibref">LOV</a></cite>] - an entry point to the growing
+				ecosystem of linked open vocabularies (RDFS or OWL ontologies) used
+				in the Linked Data Cloud. Users can find vocabularies listed and
+				individually described by metadata, classified by vocabulary spaces,
+				and interlinked using the dedicated vocabulary VOAF. The site allows
+				users to query the LOV dataset either at vocabulary level or at
+				element level, exploring the vocabulary content using full-text
+				faceted search, and finding metrics about the use of vocabularies in
+				the Semantic Web. Users can also suggest a new vocabulary to add to
+				LOV. [<cite><a href="#bib-LOV" class="bibref">LOV</a></cite>]</li>
+				<li><strong>Common Vocabularies / Ontologies / Micromodels</strong> [<cite><a href="#bib-LOD-COMMON-VOCABS" class="bibref">LOD-COMMON-VOCABS</a></cite>] - a wiki list maintained by the Linked Data LOD community project.</li>
+			</ul>
+
+			<div style="clear: both"></div>
+
+		</section>
+
+	</section>
+	<!-- End Guidelines Section -->
+
+	<section id="acknowledgements" class="appendix">
+		<!--OddPage--><h2 id="h2_acknowledgements" role="heading" aria-level="1"><span class="secno">A. </span>Acknowledgements</h2>
+		<p>Many thanks to Robin Berjon and all contributors to the <a href="http://www.w3.org/respec/">ReSpec</a> tool, which makes writing these kinds of documents much easier.
+		</p>
+		<p>To the following individuals who, in addition to the editors, have contributed either directly or indirectly to the ongoing improvement of this document: 
+			</p><ul>
+				<li><a href="http://lehors.wordpress.com/">Arnaud Le Hors</a>, IBM</li>
+				<li><a href="http://www.linkedin.com/pub/ashok-malhotra/4/675/6a2">Ashok Malhotra</a>, Oracle</li>
+				<li>Bart van Leeuwen</li>
+				<li>David Wood</li>
+				<li><a href="http://www.w3.org/People/Eric/">Eric Prud'hommeaux</a>, <abbr title="World Wide Web Consortium">W3C</abbr></li>
+				<li>Henry Story</li>
+				<li>John Arwe, IBM</li>
+				<li>Kevin Page</li>
+				<li>Miel Vander Sande</li>
+				<li><a href="http://melvincarvalho.com/">Melvin Carvalho</a></li>
+				<li>Raúl García Castro</li>
+				<li><a href="http://richard.cyganiak.de/">Richard Cyganiak</a></li>
+				<li><a href="http://www.linkedin.com/in/yadnem">Roger Menday</a>, Fujitsu Laboratories of Europe</li>
+				<li><a href="http://www.w3.org/People/Sandro/">Sandro Hawke</a>, <abbr title="World Wide Web Consortium">W3C</abbr></li>
+				<li><a href="http://stevebattle.me">Steve Battle</a></li>
+				<li><a href="http://stevespeicher.blogspot.com/">Steve Speicher</a>, IBM</li>
+				<li>Ted Thibodeau</li>
+			</ul>
+	</section>
+
+
+
+
+
+<section rel="bibo:Chapter" resource="#references" typeof="bibo:Chapter" id="references" class="appendix"><!--OddPage--><h2 id="h2_references" role="heading" aria-level="1"><span class="secno">B. </span>References</h2><section rel="bibo:Chapter" resource="#informative-references" typeof="bibo:Chapter" id="informative-references"><h3 id="h3_informative-references" role="heading" aria-level="2"><span class="secno">B.1 </span>Informative references</h3><dl about="" class="bibliography"><dt id="bib-DC-RDF">[DC-RDF]</dt><dd rel="dcterms:references">M. Nilsson et al. <a href="http://dublincore.org/documents/dc-rdf/"><cite>Expressing Dublin Core metadata using the Resource Description Framework (RDF)</cite></a>. 14 January 2008. DCMI Recommendation. URL: <a href="http://dublincore.org/documents/dc-rdf/">http://dublincore.org/documents/dc-rdf/</a>
+</dd><dt id="bib-HTTP11">[HTTP11]</dt><dd rel="dcterms:references">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7230.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7230.txt">http://www.ietf.org/rfc/rfc7230.txt</a>
+</dd><dt id="bib-LD-DI">[LD-DI]</dt><dd rel="dcterms:references">Tim Berners-Lee. <a href="http://www.w3.org/DesignIssues/LinkedData.html"><cite>Linked Data - Design Issues</cite></a>. URL: <a href="http://www.w3.org/DesignIssues/LinkedData.html">http://www.w3.org/DesignIssues/LinkedData.html</a>
+</dd><dt id="bib-LD-GLOSSARY">[LD-GLOSSARY]</dt><dd rel="dcterms:references">B Hyland; G Atemezing; M Pendleton; B Srivastava. <a href="http://www.w3.org/TR/ld-glossary/"><cite>Linked Data Glossary</cite></a>. URL: <a href="http://www.w3.org/TR/ld-glossary/">http://www.w3.org/TR/ld-glossary/</a>
+</dd><dt id="bib-LDP">[LDP]</dt><dd rel="dcterms:references">Steve Speicher; John Arwe; Ashok Malhotra. <a href="http://www.w3.org/TR/ldp/"><cite>Linked Data Platform 1.0</cite></a>. 19 June 2014. W3C Candidate Recommendation. URL: <a href="http://www.w3.org/TR/ldp/">http://www.w3.org/TR/ldp/</a>
+</dd><dt id="bib-LDP-PRIMER">[LDP-PRIMER]</dt><dd rel="dcterms:references">Nandana Mihindukulasooriya; Roger Menday. <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html"><cite>Linked Data Platforn Primer</cite></a>. W3C Working Draft. URL: <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html</a>
+</dd><dt id="bib-LDP-TESTS">[LDP-TESTS]</dt><dd rel="dcterms:references">Raúl García-Castro. <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html"><cite>Linked Data Platform 1.0 Test Cases</cite></a>. W3C Working Draft. URL: <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html</a>
+</dd><dt id="bib-LDP-UCR">[LDP-UCR]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/TR/ldp-ucr/"><cite>Linked Data Platform Use Cases and Requirements</cite></a>. W3C Working Group Note. URL: <a href="http://www.w3.org/TR/ldp-ucr/">http://www.w3.org/TR/ldp-ucr/</a>
+</dd><dt id="bib-LOD-COMMON-VOCABS">[LOD-COMMON-VOCABS]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies"><cite>Common Vocabularies / Ontologies / Micromodels </cite></a>. URL: <a href="http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies">http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies</a>
+</dd><dt id="bib-LOV">[LOV]</dt><dd rel="dcterms:references"><a href="http://lov.okfn.org/dataset/lov/"><cite>Linked Open Vocabularies (LOV)</cite></a>. URL: <a href="http://lov.okfn.org/dataset/lov/">http://lov.okfn.org/dataset/lov/</a>
+</dd><dt id="bib-RDF-PRIMER11">[RDF-PRIMER11]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/"><cite>RDF 1.1 Primer</cite></a>. W3C Working Group Note. URL: <a href="http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/">http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/</a>
+</dd><dt id="bib-RDF-SCHEMA">[RDF-SCHEMA]</dt><dd rel="dcterms:references">Dan Brickley; Ramanathan Guha. <a href="http://www.w3.org/TR/rdf-schema/"><cite>RDF Schema 1.1</cite></a>. 25 February 2014. W3C Recommendation. URL: <a href="http://www.w3.org/TR/rdf-schema/">http://www.w3.org/TR/rdf-schema/</a>
+</dd><dt id="bib-RFC3986">[RFC3986]</dt><dd rel="dcterms:references">T. Berners-Lee; R. Fielding; L. Masinter. <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource Identifier (URI): Generic Syntax</cite></a>. January 2005. Internet Standard. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>
+</dd><dt id="bib-RFC3987">[RFC3987]</dt><dd rel="dcterms:references">M. Duerst; M. Suignard. <a href="http://www.ietf.org/rfc/rfc3987.txt"><cite>Internationalized Resource Identifiers (IRIs)</cite></a>. January 2005. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc3987.txt">http://www.ietf.org/rfc/rfc3987.txt</a>
+</dd><dt id="bib-RFC7231">[RFC7231]</dt><dd rel="dcterms:references">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7231.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7231.txt">http://www.ietf.org/rfc/rfc7231.txt</a>
+</dd><dt id="bib-TURTLE">[TURTLE]</dt><dd rel="dcterms:references">Eric Prud'hommeaux; Gavin Carothers. <a href="http://www.w3.org/TR/turtle/"><cite>RDF 1.1 Turtle</cite></a>. 25 February 2014. W3C Recommendation. URL: <a href="http://www.w3.org/TR/turtle/">http://www.w3.org/TR/turtle/</a>
+</dd><dt id="bib-WEBARCH">[WEBARCH]</dt><dd rel="dcterms:references">Ian Jacobs; Norman Walsh. <a href="http://www.w3.org/TR/webarch/"><cite>Architecture of the World Wide Web, Volume One</cite></a>. 15 December 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a>
+</dd><dt id="bib-XMLSCHEMA11-2">[XMLSCHEMA11-2]</dt><dd rel="dcterms:references">David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. <a href="http://www.w3.org/TR/xmlschema11-2/"><cite>W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes</cite></a>. 5 April 2012. W3C Recommendation. URL: <a href="http://www.w3.org/TR/xmlschema11-2/">http://www.w3.org/TR/xmlschema11-2/</a>
+</dd><dt id="bib-metaDataInURI">[metaDataInURI]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/2001/tag/doc/metaDataInURI-31"><cite>The use of Metadata in URIs</cite></a>. finding. URL: <a href="http://www.w3.org/2001/tag/doc/metaDataInURI-31">http://www.w3.org/2001/tag/doc/metaDataInURI-31</a>
+</dd></dl></section></section></body></html>
\ No newline at end of file
--- a/TR/NOTE-ldp-bp-20140829/ldp-bp.html	Mon Aug 25 16:45:08 2014 -0400
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,1209 +0,0 @@
-<!DOCTYPE html>
-<html prefix="bibo: http://purl.org/ontology/bibo/ w3p: http://www.w3.org/2001/02pd/rec54#" content="en" property="dcterms:language" about="" typeof="bibo:Document w3p:NOTE" dir="ltr" lang="en"><head>
-<title>Linked Data Platform Best Practices and Guidelines</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://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script -->
-
-
-<style>/*****************************************************************
- * ReSpec 3 CSS
- * Robin Berjon - http://berjon.com/
- *****************************************************************/
-
-/* --- INLINES --- */
-em.rfc2119 { 
-    text-transform:     lowercase;
-    font-variant:       small-caps;
-    font-style:         normal;
-    color:              #900;
-}
-
-h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
-h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
-    border: none;
-}
-
-dfn {
-    font-weight:    bold;
-}
-
-a.internalDFN {
-    color:  inherit;
-    border-bottom:  1px solid #99c;
-    text-decoration:    none;
-}
-
-a.externalDFN {
-    color:  inherit;
-    border-bottom:  1px dotted #ccc;
-    text-decoration:    none;
-}
-
-a.bibref {
-    text-decoration:    none;
-}
-
-cite .bibref {
-    font-style: normal;
-}
-
-code {
-    color:  #C83500;
-}
-
-/* --- TOC --- */
-.toc a, .tof a {
-    text-decoration:    none;
-}
-
-a .secno, a .figno {
-    color:  #000;
-}
-
-ul.tof, ol.tof {
-    list-style: none outside none;
-}
-
-.caption {
-    margin-top: 0.5em;
-    font-style:   italic;
-}
-
-/* --- TABLE --- */
-table.simple {
-    border-spacing: 0;
-    border-collapse:    collapse;
-    border-bottom:  3px solid #005a9c;
-}
-
-.simple th {
-    background: #005a9c;
-    color:  #fff;
-    padding:    3px 5px;
-    text-align: left;
-}
-
-.simple th[scope="row"] {
-    background: inherit;
-    color:  inherit;
-    border-top: 1px solid #ddd;
-}
-
-.simple td {
-    padding:    3px 10px;
-    border-top: 1px solid #ddd;
-}
-
-.simple tr:nth-child(even) {
-    background: #f0f6ff;
-}
-
-/* --- DL --- */
-.section dd > p:first-child {
-    margin-top: 0;
-}
-
-.section dd > p:last-child {
-    margin-bottom: 0;
-}
-
-.section dd {
-    margin-bottom:  1em;
-}
-
-.section dl.attrs dd, .section dl.eldef dd {
-    margin-bottom:  0;
-}
-
[email protected] print {
-    .removeOnSave {
-        display: none;
-    }
-}
-</style><style>/* --- EXAMPLES --- */
-div.example-title {
-    min-width: 7.5em;
-    color: #b9ab2d;
-}
-div.example-title span {
-    text-transform: uppercase;   
-}
-aside.example, div.example, div.illegal-example {
-    padding: 0.5em;
-    margin: 1em 0;
-    position: relative;
-    clear: both;
-}
-div.illegal-example { color: red }
-div.illegal-example p { color: black }
-aside.example, div.example {
-    padding: .5em;
-    border-left-width: .5em;
-    border-left-style: solid;
-    border-color: #e0cb52;
-    background: #fcfaee;    
-}
-
-aside.example div.example {
-    border-left-width: .1em;
-    border-color: #999;
-    background: #fff;
-}
-aside.example div.example div.example-title {
-    color: #999;
-}
-
-</style>
-
-<link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/W3C-NOTE" />
-
-<!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
-
-
-
-<body id="respecDocument" role="document" class="h-entry"><div id="respecHeader" role="contentinfo" class="head">
-  
-  <p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p>
-
-  <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform Best Practices and Guidelines</h1>
-  
-  <h2 id="w3c-working-group-note-29-august-2014" property="dcterms:issued" datatype="xsd:dateTime" content="2014-08-29T05:00:00.000Z"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note <time class="dt-published" datetime="2014-08-29">29 August 2014</time></h2>
-  <dl>
-    
-      <dt>This version:</dt>
-      <dd><a class="u-url" href="http://www.w3.org/TR/2014/NOTE-ldp-bp-20140829/">http://www.w3.org/TR/2014/NOTE-ldp-bp-20140829/</a></dd>
-      <dt>Latest published version:</dt>
-      <dd><a href="http://www.w3.org/TR/ldp-bp/">http://www.w3.org/TR/ldp-bp/</a></dd>
-    
-    
-      <dt>Latest editor's draft:</dt>
-      <dd><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html</a></dd>
-    
-    <dt>Editors:</dt>
-    <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Cody Burleson" href="http://codyburleson.com/">Cody Burleson</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://base22.com/">Base22</a></span>
-</dd>
-<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Miguel Esteban Gutiérrez" href="http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/phdstudents/27-mesteban">Miguel Esteban Gutiérrez</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oeg-upm.net/">Ontology Engineering Group, Universidad Politécnica de Madrid</a></span>
-</dd>
-<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Nandana Mihindukulasooriya" href="http://www.nandana.org/">Nandana Mihindukulasooriya</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oeg-upm.net/">Ontology Engineering Group, Universidad Politécnica de Madrid</a></span>
-</dd>
-    
-  </dl>
-    
-      <p class="copyright">
-        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
-        2014
-        
-        <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
-        (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
-        <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
-        <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), 
-        
-        All Rights Reserved.
-        
-        <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
-        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
-        
-          <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
-        
-        rules apply.
-      </p>
-    
-  
-  <hr>
-</div>
-
-	<section rel="bibo:Chapter" resource="#abstract" typeof="bibo:Chapter" datatype="" property="dcterms:abstract" class="introductory" id="abstract"><h2 id="h2_abstract" role="heading" aria-level="1">Abstract</h2><p>This document provides best practices
-		and guidelines for implementing Linked Data Platform [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] servers
-		and clients.</p></section><section rel="bibo:Chapter" resource="#sotd" typeof="bibo:Chapter" id="sotd" class="introductory"><h2 id="h2_sotd" role="heading" aria-level="1">Status of This Document</h2>
-  
-    
-      
-        <p>
-          <em>This section describes the status of this document at the time of its publication.
-          Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the
-          latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
-          http://www.w3.org/TR/.</em>
-        </p>
-        
-		
-	
-        <p>
-          This document was published by the <a href="http://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform Working Group</a> as a Working Group Note.
-          
-          
-            If you wish to make comments regarding this document, please send them to 
-            <a href="mailto:[email protected]">[email protected]</a> 
-            (<a href="mailto:[email protected]?subject=subscribe">subscribe</a>,
-            <a href="http://lists.w3.org/Archives/Public/public-ldp/">archives</a>).
-          
-          
-          
-          
-            All comments are welcome.
-          
-        </p>
-        
-        
-          <p>
-            Publication as a Working Group Note does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr>
-            Membership. This is a draft document and may be updated, replaced or obsoleted by other
-            documents at any time. It is inappropriate to cite this document as other than work in
-            progress.
-          </p>
-        
-        
-        
-        <p>
-          
-            This document was produced by a group operating under the 
-            <a id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent
-            Policy</a>.
-          
-          
-          
-            
-              <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/55082/status" rel="disclosure">public list of any patent
-              disclosures</a> 
-            
-            made in connection with the deliverables of the group; that page also includes
-            instructions for disclosing a patent. An individual who has actual knowledge of a patent
-            which the individual believes contains
-            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
-            Claim(s)</a> must disclose the information in accordance with
-            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
-            6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
-          
-          
-        </p>
-        
-          <p>This document is governed by the <a id="w3c_process_revision" href="http://www.w3.org/2014/Process-20140801/">1 August 2014 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.
-          </p>
-        
-        
-      
-    
-  
-</section><section id="toc"><h2 id="h2_toc" role="heading" aria-level="1" class="introductory">Table of Contents</h2><ul id="respecContents" role="directory" class="toc"><li class="tocline"><a class="tocxref" href="#intro"><span class="secno">1. </span>About this Document</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#impetus"><span class="secno">1.1 </span>Impetus</a></li><li class="tocline"><a class="tocxref" href="#terminology"><span class="secno">1.2 </span>Terminology</a></li><li class="tocline"><a class="tocxref" href="#prerequisites-and-assumptions"><span class="secno">1.3 </span>Prerequisites and Assumptions</a></li></ul></li><li class="tocline"><a class="tocxref" href="#best-practices"><span class="secno">2. </span>Best Practices</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#predicate-uris-should-be-http-urls"><span class="secno">2.1 </span>Predicate URIs should be HTTP URLs</a></li><li class="tocline"><a class="tocxref" href="#use-and-include-the-predicate-rdf-type-to-represent-the-concept-of-type-in-ldprs"><span class="secno">2.2 </span>Use and include the predicate rdf:type to represent the
-				concept of type in LDPRs</a></li><li class="tocline"><a class="tocxref" href="#use-relative-uris"><span class="secno">2.3 </span>Use relative URIs</a></li><li class="tocline"><a class="tocxref" href="#avoid-dot-segments-in-uris-of-posted-content-or-use-with-caution"><span class="secno">2.4 </span>Avoid dot-segments in URIs of POSTed content or use with caution</a></li><li class="tocline"><a class="tocxref" href="#represent-container-membership-with-hierarchical-uris"><span class="secno">2.5 </span>Represent container membership with hierarchical URIs</a></li><li class="tocline"><a class="tocxref" href="#include-a-trailing-slash-in-container-uris"><span class="secno">2.6 </span>Include a trailing slash in container URIs</a></li><li class="tocline"><a class="tocxref" href="#use-fragments-as-relative-identifiers"><span class="secno">2.7 </span>Use fragments as relative identifiers</a></li><li class="tocline"><a class="tocxref" href="#prefer-standard-datatypes"><span class="secno">2.8 </span>Prefer standard datatypes</a></li><li class="tocline"><a class="tocxref" href="#re-use-established-linked-data-vocabularies-instead-of-re--inventing-duplicates"><span class="secno">2.9 </span>Re-use established linked data vocabularies instead of
-				(re-)inventing duplicates</a></li><li class="tocline"><a class="tocxref" href="#use-qvalues-properly"><span class="secno">2.10 </span>Use qvalues properly</a></li><li class="tocline"><a class="tocxref" href="#respond-with-primary-urls-and-use-them-for-identity-comparison"><span class="secno">2.11 </span>Respond with primary URLs and use them for identity comparison</a></li><li class="tocline"><a class="tocxref" href="#representing-relationships-between-resources"><span class="secno">2.12 </span>Representing relationships between resources</a></li><li class="tocline"><a class="tocxref" href="#minimize-server-specific-constraints"><span class="secno">2.13 </span>Minimize server-specific constraints</a></li></ul></li><li class="tocline"><a class="tocxref" href="#guidelines"><span class="secno">3. </span>Guidelines</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#containers-are-not-limited-to-membership-and-containment-triples"><span class="secno">3.1 </span>Containers are not limited to membership and containment triples</a></li><li class="tocline"><a class="tocxref" href="#finding-established-vocabularies"><span class="secno">3.2 </span>Finding established vocabularies</a></li></ul></li><li class="tocline"><a class="tocxref" href="#acknowledgements"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a class="tocxref" href="#references"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#informative-references"><span class="secno">B.1 </span>Informative references</a></li></ul></li></ul></section>
-
-	
-
-
-	<section rel="bibo:Chapter" resource="#intro" typeof="bibo:Chapter" id="intro">
-
-		<!--OddPage--><h2 id="h2_intro" role="heading" aria-level="1"><span class="secno">1. </span>About this Document</h2>
-
-		<section id="impetus">
-
-			<h3 id="h3_impetus" role="heading" aria-level="2"><span class="secno">1.1 </span>Impetus</h3>
-
-			<p>While writing the Linked Data Platform Specification, the
-				authors and contributors felt compelled to share common conventions
-				and valuable lessons-learned. Yet, at the same time, they did not
-				wish to impose or imply unnecessary restrictions, or to make the
-				formal specification unnecessarily verbose. This document, along
-				with the LDP Primer [<cite><a href="#bib-LDP-PRIMER" class="bibref">LDP-PRIMER</a></cite>], was therefore developed to
-				provide additional context. Drawing upon the professional
-				experiences of its authors and contributors, research into the rich
-				history of related technologies, and continuous feedback from the
-				community at large, it aims to help system implementers avoid common
-				pitfalls, improve quality, and achieve greater interoperability with
-				other Linked Data systems.</p>
-
-		</section>
-
-		<section id="terminology">
-
-			<h3 id="h3_terminology" role="heading" aria-level="2"><span class="secno">1.2 </span>Terminology</h3>
-
-			<p>For the purposes of this document, it is useful to
-				make a minor, yet important distinction between the term 'best
-				practice' and the term 'guideline'. We define and differentiate 
-				the terms as follows:</p>
-
-			<dl>
-				<dt>best practice</dt>
-				<dd>An implementation practice (method or technique) that has
-					consistently shown results superior to those achieved with other
-					means and that is used as a benchmark. Best practices within this
-					document apply specifically to the ways that LDP servers and
-					clients are implemented as well as how certain resources are
-					prepared and used with them. In this document, the best practices
-					might be used as a kind of check-list against which an implementer
-					can directly evaluate a system's design and code. Lack of adherence
-					to any given best practice, however, does not necessarily imply a
-					lack of quality; they are recommendations that are said to be
-					'best' in most cases and in most contexts, but not all. A best
-					practice is always subject to improvement as we learn and evolve
-					the Web together.</dd>
-				<dt>guideline</dt>
-				<dd>A tip, a trick, a note, a suggestion, or answer to a
-					frequently asked question. Guidelines within this document provide
-					useful information that can advance an implementer's knowledge and
-					understanding, but that may not be directly applicable to an
-					implementation or recognized by consensus as a 'best practice'.</dd>
-			</dl>
-
-			<p>Please see the Terminology section in Linked Data Platform 1.0
-				[<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] as well as the Linked Data Glossary [<cite><a href="#bib-LD-GLOSSARY" class="bibref">LD-GLOSSARY</a></cite>] for
-				definitions to a variety of terms used in this document and related
-				to the Linked Data sphere of knowledge.</p>
-
-		</section>
-
-		<section id="prerequisites-and-assumptions">
-
-			<h3 id="h3_prerequisites-and-assumptions" role="heading" aria-level="2"><span class="secno">1.3 </span>Prerequisites and Assumptions</h3>
-
-			<p>
-				Implementers should have at least a general familiarity with the <a href="#informative-references">informative references</a> cited in
-				this document - especially the following:
-			</p>
-
-			<ul>
-				<li><strong>RDF Vocabulary Description Language 1.0: RDF Schema</strong> 
-					[<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>] - The Resource Description Framework
-					(RDF) is a general-purpose language for representing information in
-					the Web and it is the defacto language for expressing Linked Data.
-					This specification describes how to use RDF to describe RDF
-					vocabularies.</li>
-				<li><strong>RDF Primer 1.1</strong> [<cite><a href="#bib-RDF-PRIMER11" class="bibref">RDF-PRIMER11</a></cite>] - This Primer is designed to
-					provide the reader with the basic knowledge required to effectively
-					use RDF. It introduces the basic concepts of RDF and describes its
-					XML syntax. It describes how to define RDF vocabularies using the
-					RDF Vocabulary Description Language, and gives an overview of some
-					deployed RDF applications. It also describes the content and
-					purpose of other RDF specification documents.</li>
-				<li><strong>Turtle - Terse RDF Triple Language</strong>
-					[<cite><a href="#bib-TURTLE" class="bibref">TURTLE</a></cite>] - defines a textual syntax for RDF called Turtle that
-					allows RDF graphs to be completely written in a compact and natural
-					text form, with abbreviations for common usage patterns and
-					datatypes. RDF examples used in this document are expressed in
-					Turtle.</li>
-				<li><strong>Linked Data Glossary</strong> [<cite><a href="#bib-LD-GLOSSARY" class="bibref">LD-GLOSSARY</a></cite>] - a
-					useful glossary containing terms defined and used to describe
-					Linked Data, and its associated vocabularies and best practices for
-					publishing structured data on the Web.</li>
-				<li><strong>Linked Data Platform 1.0</strong> [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] - the
-					formal specification for the LDP read-write Linked Data
-					architecture, based on HTTP access to web resources that describe
-					their state using the RDF data model.
-				</li><li><strong>Linked Data Platform 1.0 Test Cases</strong>
-					[<cite><a href="#bib-LDP-TESTS" class="bibref">LDP-TESTS</a></cite>] - a standard set of tests provided by the <abbr title="World Wide Web Consortium">W3C</abbr>, which
-					can be use to verify an implementation's conformance to the LDP
-					specification.</li>
-				<li><strong>Linked Data Platform Primer</strong> [<cite><a href="#bib-LDP-PRIMER" class="bibref">LDP-PRIMER</a></cite>]
-					- an introduction to LDP, which describes the basic concepts of LDP
-					such as Linked Data Platform Resources (LDPRs), Linked Data
-					Platform Containers (LDPCs), and their affordances. The Primer
-					provides a running example illustrating how an LDP client can
-					interact with an LDP server in the context of a read-write Linked
-					Data application (i.e. how to use HTTP for accessing, updating,
-					creating and deleting resources from servers that expose their
-					resources as Linked Data).</li>
-				<li><strong>Linked Data Platform Use Cases and
-						Requirements</strong> [<cite><a href="#bib-LDP-UCR" class="bibref">LDP-UCR</a></cite>] - a set of user stories, use cases,
-					scenarios and requirements that motivate a simple read-write Linked
-					Data architecture, based on HTTP access to web resources that
-					describe their state using RDF.</li>
-			</ul>
-
-		</section>
-
-	</section>
-
-	<section id="best-practices">
-
-		<!--OddPage--><h2 id="h2_best-practices" role="heading" aria-level="1"><span class="secno">2. </span>Best Practices</h2>
-
-		<section id="predicate-uris-should-be-http-urls">
-
-			<h3 id="h3_predicate-uris-should-be-http-urls" role="heading" aria-level="2"><span class="secno">2.1 </span>Predicate URIs should be HTTP URLs</h3>
-
-			<p>URIs are used to uniquely identify resources and URLs are used
-				to locate resources on the Web. That is to say that a URL is
-				expected to resolve to an actual resource, which can be retrieved
-				from the host. A URI, on the other hand, may also be a URL, but it
-				does not have to be; it may refer to something that has no
-				retrievable representation.</p>
-
-			<p>One of the fundamental ideas behind Linked Data is that the
-				things referred to by HTTP URIs can actually be looked up
-				("dereferenced"). This important principle was originally
-				outlined by Tim Berners-Lee as rule #2 of "the four rules"
-				for linking data [<cite><a href="#bib-LD-DI" class="bibref">LD-DI</a></cite>]. It is therefore ideal that predicate
-				URIs identify resources with representations that are retrievable. LDP
-				servers should at least provide [<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>] representations of
-				these predicates where possible.</p>
-
-			<p>Of course, it is also a common practice to reuse properties
-				from open vocabularies that are publicly available. In this case,
-				implementers have no control over the result when attempting to
-				dereference the URI. For this reason, publishers who wish to make
-				their vocabularies useful for linking data should strive to provide
-				a retrievable representation of the properties their vocabularies
-				define. Consequently, implementers are also expected to use this
-				practice as a benchmark for which to judge the efficacy of a
-				vocabulary's use for linking data.</p>
-
-		</section>
-
-		<section id="use-and-include-the-predicate-rdf-type-to-represent-the-concept-of-type-in-ldprs">
-
-			<h3 id="h3_use-and-include-the-predicate-rdf-type-to-represent-the-concept-of-type-in-ldprs" role="heading" aria-level="2"><span class="secno">2.2 </span>Use and include the predicate rdf:type to represent the
-				concept of type in LDPRs</h3>
-
-			<p>
-				It is often very useful to know the type (class) of an LDPR, though
-				it is not essential to work with the interaction capabilities that
-				LDP offers. Still, to make data more useful in the broadest context,
-				type should be explicitly defined using the <code>rdf:type</code>
-				predicate defined by [<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>].
-			</p>
-
-			<p>This provides a way for clients to easily determine the type(s)
-				of a resource without having to perform additional processing or
-				make additional HTTP requests. For example, clients that cannot
-				infer the type because they do not support inferencing can benefit
-				from this explicit declaration.</p>
-
-			<div class="example"><div class="example-title"><span>Example 1</span>: Representation of an LDPR with explicit declaration of rdf:type</div><pre class="example">@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
[email protected] contact: &lt;http://www.w3.org/2000/10/swap/pim/contact#&gt;.
-
-&lt;http://www.w3.org/People/EM/contact#me&gt; 
-  a contact:Person;
-  contact:fullName "Eric Miller";
-  contact:mailbox &lt;mailto:[email protected]&gt;;
-  contact:personalTitle "Dr.".</pre></div>
-
-			<p>The token 'a' in the predicate position of a Turtle triple represents the IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#type. 
-			In the example above, therefore, <code>a contact:Person</code> is the same as <code>rdf:type contact:Person</code> or the fully-qualified form, <code>&lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#type&gt; contact:Person</code>.</p>
-
-		</section>
-
-		<section id="use-relative-uris">
-
-			<h3 id="h3_use-relative-uris" role="heading" aria-level="2"><span class="secno">2.3 </span>Use relative URIs</h3>
-
-			<!-- http://www.w3.org/2012/ldp/track/issues/29 -->
-
-			<p>Relative URIs are useful to the Linked Data Platform in much
-				the same ways that relative URLs [<cite><a href="#bib-RFC3986" class="bibref">RFC3986</a></cite>] have been useful to
-				traditional web systems. Since the things referred to by Linked Data
-				URIs should provide a retrievable representation [<cite><a href="#bib-LD-DI" class="bibref">LD-DI</a></cite>], Linked
-				Data URIs are usually also URLs; they locate rather than just
-				identify. As such, the utilitarian value of relative URLs still
-				applies; especially since the LDP Container model promotes
-				hierarchical representations.</p>
-
-			<p>Implementers should therefore align the function of relative
-				URIs in LDP with those of traditional relative URLs where possible
-				and appropriate. Aside from giving developers the comfort and
-				convenience of familiarity, they provide many of the same
-				advantages.</p>
-
-			<dl>
-				<dt>Relative URIs are shorter than absolute URIs.</dt>
-				<dd>
-					<p>In many cases, this can aid development by making code and
-						RDF easier for humans to read. It can also reduce the size of
-						payloads, which in turn, can reduce network traffic and stress on
-						servers, while improving response times for end-users.</p>
-
-					<div class="example"><div class="example-title"><span>Example 2</span>: Representation of http://example.org/container1/ with absolute URIs</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-
-&lt;http://example.org/container1/&gt;
-   a a ldp:Container, ldp:BasicContainer;
-   dcterms:title "A very simple container";
-   ldp:contains
-      &lt;http://example.org/container1/member1&gt;,
-      &lt;http://example.org/container1/member2&gt;,
-      &lt;http://example.org/container1/member3&gt;.</pre></div>
-
-
-					<div class="example"><div class="example-title"><span>Example 3</span>: Representation of http://example.org/container1/ with relative URIs</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-
-&lt;&gt; a a ldp:Container, ldp:BasicContainer;
-   dcterms:title "A very simple container";
-   ldp:contains &lt;member1&gt;, &lt;member2&gt;, &lt;member3&gt; .</pre></div>
-
-				</dd>
-
-				<dt>Relative URIs can make resources more portable.</dt>
-				<dd>When information which is already known from the context of
-					the base resource's retrieval is omitted, there can be less
-					information to modify when its location changes. This can make
-					copying resources to new servers or to a new position in a
-					containment hierarchy easier; in the preceding example, 
-					a process that clones just the container need not adjust any of
-					its member URIs.
-					</dd>
-
-				<dt>Relative URIs are convenient during development.</dt>
-				<dd>During development the scheme and network location
-					information in a URI may either be unknown or likely to change. The
-					commonly used 'localhost' for example, is better expressed by the
-					server name or a domain name. Developers often experience less
-					hassle by omitting this information. Additionally, the hierarchy
-					implied by a relative URI may be mimicked in a server file system,
-					which can help developers find and work with information, even when
-					the server isn't running.</dd>
-
-				<dt>Relative URIs support arbitrary, machine-generated URIs.</dt>
-				<dd>
-					RESTful URLs are often defined by a pattern of hierarchical
-					'collections', which clients interact with in very logical ways.
-					For example, when creating a new resource the client does not
-					typically know the name of the resource until after a successful
-					POST to a collection's URL. A POST to
-					<code>/people/</code>
-					for example, may create the resource
-					<code>/people/1</code>
-					. LDP Containers are such collections whose URIs can benefit from
-					the same model, which in some implementations, may actually be
-					crucial.
-				</dd>
-			</dl>
-		</section>
-
-		<section id="avoid-dot-segments-in-uris-of-posted-content-or-use-with-caution">
-			<h3 id="h3_avoid-dot-segments-in-uris-of-posted-content-or-use-with-caution" role="heading" aria-level="2"><span class="secno">2.4 </span>Avoid dot-segments in URIs of POSTed content or use with caution</h3>
-
-			<p>The semantics of dot-segments (eg. <code>../</code>) within relative URIs may be implied by other 
-			specifications and by common historical use, but in the case of LDP, additional consideration is required.</p>
-
-			<p>The LDP specification states that... </p><blockquote>LDP servers <em title="MUST" class="rfc2119">MUST</em> assign the default base-URI for [<cite><a href="#bib-RFC3987" class="bibref">RFC3987</a></cite>]
- relative-URI resolution 
-			to be the HTTP Request-URI when the resource already exists, and to 
-the URI of the created resource when the request results in the creation
- 
-			of a new resource.</blockquote> It follows from this definition that use of <code>../</code>
- and other non-null relative URI constructs during 
-			POST can cause the posted content to be referring to resources in a 
-manner the client might not be able to predict. 
-			Dot-segments should therefore be avoided unless the client knows 
-specifically what can be expected of the given implementation 
-			and/or deployment.<p></p>
-		</section>
-
-
-		<section id="represent-container-membership-with-hierarchical-uris">
-
-			<h3 id="h3_represent-container-membership-with-hierarchical-uris" role="heading" aria-level="2"><span class="secno">2.5 </span>Represent container membership with hierarchical URIs</h3>
-
-			<p>Hierarchical URIs are good for containers because they enable
-				the use of relative URIs. They also promote easy interaction with
-				resources that are modeled to represent parent-child relationships
-				where the child logically belongs to the parent.</p>
-
-			<p>
-				One example of such a model can be found in the case of the
-				<code>oslc_cm:attachment</code>
-				container from the vocabularies defined by the <a href="http://open-services.net/">Open Service for Lifecycle
-					Management (OSLC)</a> community. The OSLC defines specifications and
-				vocabularies that are well-aligned to LDP. A resource in an OSLC
-				compliant change management system such as an issue or bug tracker
-				may have attachments represented by the
-				<code>oslc_cm:attachment</code>
-				container. The URI for such a container might be represented as
-				follows:
-			</p>
-
-			<p>
-				<code>http://example.org/bugs/2314/attachments/</code>
-			</p>
-
-			<p>From this URI, the URI of the parent resource which holds the
-				attachments is easily discerned. The base container for other
-				sibling resources can be discerned by moving up the hierarchy, which
-				is implied by the URI. Meta-data or binary content might be fetched
-				further down the hierarchy by using a URI such as the following:</p>
-
-			<p>
-				<code>http://example.org/bugs/2314/attachments/1</code>
-			</p>
-
-			<p>In addition to making the use of relative URIs possible,
-				hierarchical URIs make interacting with resources easier for users because
-				they represent the actual structure of the underlying graph.
-				Software agents (code acting on behalf of users [<cite><a href="#bib-WEBARCH" class="bibref">WEBARCH</a></cite>]) must be careful
-				before exploiting the structure of URIs, considering historical problems
-				when doing so ([<cite><a href="#bib-WEBARCH" class="bibref">WEBARCH</a></cite>], [<cite><a href="#bib-metaDataInURI" class="bibref">metaDataInURI</a></cite>]).
-				</p>
-
-		</section>
-
-
-		<section id="include-a-trailing-slash-in-container-uris">
-
-			<!-- http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0071.html -->
-
-			<h3 id="h3_include-a-trailing-slash-in-container-uris" role="heading" aria-level="2"><span class="secno">2.6 </span>Include a trailing slash in container URIs</h3>
-
-			<p>When representing container membership with hierarchical URLs,
-				including the trailing slash in a container's URI makes it 
-				easier to use relative URIs.
-				Take the following container URI for example:</p>
-
-			<p>
-				<code>http://example.org/container1</code>
-			</p>
-
-			<p>It is more advantageous to use the following instead:</p>
-
-			<p>
-				<code>http://example.org/container1/</code>
-			</p>
-
-			<p>To illustrate the advantage, let's start with the following
-				container using absolute URIs:</p>
-
-			<div class="example"><div class="example-title"><span>Example 4</span>: A simple container</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-
-&lt;http://example.org/container1&gt;
-   a a ldp:Container, ldp:BasicContainer;
-   dcterms:title "A very simple container";
-   ldp:contains
-      &lt;http://example.org/container1/member1&gt;,
-      &lt;http://example.org/container1/member2&gt;,
-      &lt;http://example.org/container1/member3&gt;.</pre></div>
-
-			<p>Suppose now that we wish to reflect the same resource using
-				relative URIs. If the URI of the container includes the trailing
-				slash, we end up with a very elegant representation, as shown below.</p>
-
-			<div class="example"><div class="example-title"><span>Example 5</span>: Container URI is http://example.org/container1/</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-
-&lt;&gt; a a ldp:Container, ldp:BasicContainer;
- dcterms:title "A very simple container";
- ldp:contains &lt;member1&gt;, &lt;member2&gt;, &lt;member3&gt; .</pre></div>
-
-			<p>But suppose that we omit the trailing slash, issued an HTTP
-				GET, and the container returned the representation shown above. This
-				could produce a graph that is equivalent to the following:</p>
-
-			<div class="example"><div class="example-title"><span>Example 6</span>: Container URI is http://example.org/container1</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-
-&lt;http://example.org/container1&gt;
-   a a ldp:Container, ldp:BasicContainer;
-   dcterms:title "A very simple container";
-   ldp:contains
-      &lt;http://example.org/member1&gt;,
-      &lt;http://example.org/member2&gt;,
-      &lt;http://example.org/member3&gt;.</pre></div>
-
-			<p>That is not what was intended; the member URLs lack the 
-				<code>container</code> path segment.
-				The returned document would
-				have to be more verbose in order to be correct:</p>
-
-			<div class="example"><div class="example-title"><span>Example 7</span>: Container URI is http://example.org/container1</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
[email protected] rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
[email protected] ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
-
-&lt;&gt; a a ldp:Container, ldp:BasicContainer;
- dcterms:title "A very simple container";
- ldp:contains &lt;container1/member1&gt;, &lt;container1/member2&gt;, &lt;container1/member3&gt; .</pre></div>
-
-			<p>So, clearly, the better solution is to ensure that container
-				URIs end with a trailing slash.</p>
-
-		</section>
-
-
-		<section id="use-fragments-as-relative-identifiers">
-
-			<h3 id="h3_use-fragments-as-relative-identifiers" role="heading" aria-level="2"><span class="secno">2.7 </span>Use fragments as relative identifiers</h3>
-
-			<p>
-				Resource URIs are permitted to end with a fragment; the fragment
-				component is delimited from the rest of the URI because it is
-				introduced by a hash mark (<b><code>#</code></b>).
-				For this reason, URIs with non-empty fragments are often called hash URIs;
-				a hash URI identifies a subordinate or related resource [<cite><a href="#bib-RFC3986" class="bibref">RFC3986</a></cite>].
-			</p>
-
-			<p>
-				Take the URI,
-				<code>http://www.example.org/products#item10245</code>
-				, for example. The non-fragment portion of the URI is the part preceding the hash mark,
-				<code>http://www.example.org/products</code>
-				, and the fragment identifier is the part that follows,
-				<code>item10245</code>
-				.
-			</p>
-
-			<p>When expressing Linked Data Platform Resources in RDF,
-				fragments are useful because they can be expressed as relative URIs
-				on the document describing them. This is particularly handy for
-				describing multiple LDPRs whose representations are contained within
-				a single document.</p>
-
-			<p>
-				First, it provides the convenience and efficiency of brevity.
-				Suppose, for example, the resources foo, bar, and baz are
-				contained in the same document. Since serving all of the
-				descriptions in a single document is acceptable, we can mint
-				relative URIs within the document using the fragment identifier (
-				<code>&lt;#foo&gt;</code>
-				,
-				<code>&lt;#bar&gt;</code>
-				and
-				<code>&lt;#baz&gt;</code>
-				).  [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] ensures that the default base URI is the document
-				URI (
-				<code>http://www.example.org/products</code>
-				), so the absolute URI for each is 
-				the base URI, plus the hash mark,
-				plus the fragment identifier.
-			</p>
-
-
-			<p>Second, it can help avoid certain complexities inherent with
-				other approaches. Achieving the same result using three independent
-				dereferenceable URIs could be more involved because multiple
-				documents would have to be published, perhaps also including the
-				setup of 303 redirects.</p>
-
-			<p>
-				<strong>See also:</strong>
-			</p>
-
-			<p>
-				<a href="http://www.w3.org/TR/cooluris">Cool URIs for the
-					Semantic Web</a>
-			</p><ul>
-				<li><a href="http://www.w3.org/TR/cooluris/#hashuri">http://www.w3.org/TR/cooluris/#hashuri</a></li>
-				<li><a href="http://www.w3.org/TR/cooluris/#choosing">http://www.w3.org/TR/cooluris/#choosing</a></li>
-			</ul>
-			<p></p>
-
-			<p>
-				<a href="http://www.w3.org/DesignIssues/Fragment.html">Axioms of
-					Web Architecture, URI References: Fragment Identifiers on URIs</a><br>
-				http://www.w3.org/DesignIssues/Fragment.html
-			</p>
-
-			<p>
-				<a href="http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14">Dereferencing
-					HTTP URIs</a><br>
-				http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14
-			</p>
-
-		</section>
-
-
-		<section id="prefer-standard-datatypes">
-			<h3 id="h3_prefer-standard-datatypes" role="heading" aria-level="2"><span class="secno">2.8 </span>Prefer standard datatypes</h3>
-
-			<p>LDPR representations should 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 [<cite><a href="#bib-XMLSCHEMA11-2" class="bibref">XMLSCHEMA11-2</a></cite>] and [<cite><a href="#bib-RDF-PRIMER11" class="bibref">RDF-PRIMER11</a></cite>] should be used:</p>
-
-			<table class="simple">
-				<thead>
-					<tr>
-						<th>URI</th>
-						<th>Description</th>
-					</tr>
-				</thead>
-				<tbody>
-					<tr>
-						<td><a href="http://www.w3.org/2001/XMLSchema#boolean">http://www.w3.org/2001/XMLSchema#boolean</a></td>
-						<td>Boolean type as specified by XSD Boolean</td>
-					</tr>
-					<tr>
-						<td><a href="http://www.w3.org/2001/XMLSchema#date">http://www.w3.org/2001/XMLSchema#date</a></td>
-						<td>Date type as specified by XSD date</td>
-					</tr>
-					<tr>
-						<td><a href="http://www.w3.org/2001/XMLSchema#dateTime">http://www.w3.org/2001/XMLSchema#dateTime</a></td>
-						<td>Date and Time type as specified by XSD dateTime</td>
-					</tr>
-					<tr>
-						<td><a href="http://www.w3.org/2001/XMLSchema#decimal">http://www.w3.org/2001/XMLSchema#decimal</a></td>
-						<td>Decimal number type as specified by XSD Decimal</td>
-					</tr>
-					<tr>
-						<td><a href="http://www.w3.org/2001/XMLSchema#double">http://www.w3.org/2001/XMLSchema#double</a></td>
-						<td>Double floating-point number type as specified by XSD
-							Double</td>
-					</tr>
-					<tr>
-						<td><a href="http://www.w3.org/2001/XMLSchema#float">http://www.w3.org/2001/XMLSchema#float</a></td>
-						<td>Floating-point number type as specified by XSD Float</td>
-					</tr>
-					<tr>
-						<td><a href="http://www.w3.org/2001/XMLSchema#hexBinary">http://www.w3.org/2001/XMLSchema#hexBinary</a></td>
-						<td>Arbitrary hex-encoded binary data as specified by XSD hexBinary</td>
-					</tr>
-					<tr>
-						<td><a href="http://www.w3.org/2001/XMLSchema#integer">http://www.w3.org/2001/XMLSchema#integer</a></td>
-						<td>Integer number type as specified by XSD Integer</td>
-					</tr>
-					<tr>
-						<td><a href="http://www.w3.org/2001/XMLSchema#string">http://www.w3.org/2001/XMLSchema#string</a></td>
-						<td>String type as specified by XSD String</td>
-					</tr>
-					<tr>
-						<td><a href="http://www.w3.org/2001/XMLSchema#base64Binary">http://www.w3.org/2001/XMLSchema#base64Binary</a></td>
-						<td>Binary type as specified by XSD Base64Binary</td>
-					</tr>
-					<tr>
-						<td><a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral</a></td>
-						<td>Literal XML value as specified by RDF</td>
-					</tr>
-				</tbody>
-			</table>
-
-		</section>
-
-
-		<section id="re-use-established-linked-data-vocabularies-instead-of-re--inventing-duplicates">
-
-			<h3 id="h3_re-use-established-linked-data-vocabularies-instead-of-re--inventing-duplicates" role="heading" aria-level="2"><span class="secno">2.9 </span>Re-use established linked data vocabularies instead of
-				(re-)inventing duplicates</h3>
-
-			<p>
-				This section summarizes some well-known RDF vocabularies that should
-				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 resource has a description, and the application semantics of
-				that description is compatible with
-				<code>dcterms:description</code>
-				, then
-				<code>dcterms:description</code>
-				should be used. If needed, additional application-specific
-				predicates may be used. A specification for a domain may require one
-				or more of these properties for a particular resource type. The
-				Range column in the tables below identifies the defined
-				<code>rdfs:range</code>
-				for the properties.
-			</p>
-
-			<h3 id="common-properties">Common Properties</h3>
-
-			<p>
-				<strong>From Dublin Core URI: <a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a></strong>
-			</p>
-
-			<table class="simple">
-				<thead>
-					<tr>
-						<th>Property</th>
-						<th>Range/DataType</th>
-						<th>Comment</th>
-					</tr>
-				</thead>
-				<tbody>
-					<tr>
-						<td>dcterms:contributor</td>
-						<td>dcterms:Agent</td>
-						<td></td>
-					</tr>
-					<tr>
-						<td>dcterms:creator</td>
-						<td>dcterms:Agent</td>
-						<td></td>
-					</tr>
-					<tr>
-						<td>dcterms:created</td>
-						<td>xsd:dateTime</td>
-						<td></td>
-					</tr>
-					<tr>
-						<td>dcterms:description</td>
-						<td>rdf:XMLLiteral</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 element.</td>
-					</tr>
-					<tr>
-						<td>dcterms:identifier</td>
-						<td>rdfs:Literal</td>
-						<td></td>
-					</tr>
-					<tr>
-						<td>dcterms:modified</td>
-						<td>xsd:dateTime</td>
-						<td></td>
-					</tr>
-					<tr>
-						<td>dcterms:relation</td>
-						<td>rdfs:Resource</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>dcterms:subject</td>
-						<td>rdfs:Resource</td>
-						<td></td>
-					</tr>
-					<tr>
-						<td>dcterms:title</td>
-						<td>rdf:XMLLiteral</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 element.</td>
-					</tr>
-				</tbody>
-			</table>
-
-			<p>
-				The predicate
-				<code>dcterms:type</code>
-				should not be used, instead use
-				<code>rdf:type</code>
-				. [<cite><a href="#bib-DC-RDF" class="bibref">DC-RDF</a></cite>].
-			</p>
-
-			<p>
-				<strong>From RDF URI: <a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a></strong>
-			</p>
-
-			<table class="simple">
-				<thead>
-					<tr>
-						<th>Property</th>
-						<th>Range/DataType</th>
-						<th>Comment</th>
-					</tr>
-				</thead>
-				<tbody>
-					<tr>
-						<td>rdf:type</td>
-						<td>rdfs:Class</td>
-						<td>The type or types of the resource</td>
-					</tr>
-				</tbody>
-			</table>
-
-			<p>
-				<strong>From RDF Schema URI: <a href="http://www.w3.org/2000/01/rdf-schema#">http://www.w3.org/2000/01/rdf-schema#</a></strong>
-			</p>
-
-			<table class="simple">
-				<thead>
-					<tr>
-						<th>Property</th>
-						<th>Range/DataType</th>
-						<th>Comment</th>
-					</tr>
-				</thead>
-				<tbody>
-					<tr>
-						<td>rdfs:member</td>
-						<td>rdfs:Resource</td>
-						<td>&nbsp;</td>
-					</tr>
-					<tr>
-						<td>rdfs:label</td>
-						<td>rdfs:Literal</td>
-						<td>Only use this in vocabulary documents, to define the name
-							of the vocabulary term.</td>
-					</tr>
-				</tbody>
-			</table>
-
-
-
-		</section>
-
-
-		<section id="use-qvalues-properly">
-			<h3 id="h3_use-qvalues-properly" role="heading" aria-level="2"><span class="secno">2.10 </span>Use qvalues properly</h3>
-
-			<p>Quality factors allow the user or user agent to indicate the
-				relative degree of preference for a media-range, using the qvalue
-				scale from 0 to 1. The default value is q=1. Take the following for
-				example:</p>
-
-			<p>
-				<code>Accept: text/turtle; q=0.5, application/json</code>
-			</p>
-
-			<p>This should be interpreted as "I prefer application/json, but
-				send me text/turtle if it is the best available after a 50%
-				mark-down in quality."</p>
-
-			<p>Improper handling of qvalues is a common problem in
-				implementations of content negotiation.
-			</p><p>Refer to Section 14, Header Field Definitions, in the
-				[<cite><a href="#bib-HTTP11" class="bibref">HTTP11</a></cite>] specification to understand the proper use and evaluation
-				of qvalues for both client and server implementations.</p>
-
-		</section>
-
-		<section id="respond-with-primary-urls-and-use-them-for-identity-comparison">
-			<h3 id="h3_respond-with-primary-urls-and-use-them-for-identity-comparison" role="heading" aria-level="2"><span class="secno">2.11 </span>Respond with primary URLs and use them for identity comparison</h3>
-
-			<p>Clients can access an LDPR using multiple URLs. An LDP server
-				should respond to each of those requests using a single consistent
-				URL, a primary URL, for the LDPR. This primary URL may be found
-				in the response's Location and/or Content-Location headers, and
-				potentially also in the representation of the LDPR. A common case is
-				URLs that vary by protocol, one HTTP and one HTTPS, but are
-				otherwise identical. In most cases those two URLs refer to the same
-				resource, and the server should respond to requests on either URL
-				with a single (primary) URL.</p>
-
-			<p>Clients should use the primary URL as an LDPR's identity;
-				for example, when determining if two URLs refer to the same resource
-				clients should compare the primary URLs, not the URLs used to
-				access the resources.  Note that this usage <em>does</em> imply that the
-				client has sufficient reason to trust the headers and/or content
-				by which the primary URL is communicated to the client, which is 
-				beyond what HTTP alone can guarantee [<cite><a href="#bib-RFC7231" class="bibref">RFC7231</a></cite>].
-				</p>
-
-		</section>
-
-		<section id="representing-relationships-between-resources">
-			<h3 id="h3_representing-relationships-between-resources" role="heading" aria-level="2"><span class="secno">2.12 </span>Representing relationships between resources</h3>
-			<p>LDPRs can use one RDF triple to represent a link
-				(relationship) to another resource. Having the source resource’s URI
-				as the subject and the target resource’s URI as the object of the
-				triple is enough. Contrary to a misconception that readers with
-				certain backgrounds may assume, the creation of an
-				"intermediate link" resource is not required to express
-				the relationship.</p>
-		</section>
-
-		<section id="minimize-server-specific-constraints">
-			<h3 id="h3_minimize-server-specific-constraints" role="heading" aria-level="2"><span class="secno">2.13 </span>Minimize server-specific constraints</h3>
-			<p>LDP servers should enable simple creation and modification of
-				LDPRs.</p>
-
-			<p>It may be common for LDP servers to put restrictions on
-				representations – for example, the range of rdf:type predicates,
-				datatypes of the objects of predicates, and the number of
-				occurrences of predicates in an LDPR, but servers should minimize
-				such restrictions.</p>
-
-			<p>For some server applications, excessive constraints on
-				modification of resources may be required. However, enforcement of
-				more complex constraints will greatly restrict the set of clients
-				that can modify resources. For interoperability with a wider range
-				of clients, implementers are therefore encouraged to minimize
-				server-specific constraints.</p>
-		</section>
-
-	</section>
-	<!-- End Best Practices Section -->
-
-	<section id="guidelines">
-
-		<!--OddPage--><h2 id="h2_guidelines" role="heading" aria-level="1"><span class="secno">3. </span>Guidelines</h2>
-
-		<section id="containers-are-not-limited-to-membership-and-containment-triples">
-
-			<h3 id="h3_containers-are-not-limited-to-membership-and-containment-triples" role="heading" aria-level="2"><span class="secno">3.1 </span>Containers are not limited to membership and containment triples</h3>
-
-			<p>It is important to remember that a Linked Data Platform
-				Container (LDPC) is also a Linked Data Platform RDF Source (LDP-RS) and
-				though it might exist as a membership controller, it may also represent 
-				additional data that is valuable to the agents that access
-				it.</p>
-
-		</section>
-
-		<section id="finding-established-vocabularies">
-			<h3 id="h3_finding-established-vocabularies" role="heading" aria-level="2"><span class="secno">3.2 </span>Finding established vocabularies</h3>
-
-			<p>Following are some useful resources for finding and leveraging
-				pre-existing, common, and well-established vocabularies.</p>
-
-
-			<ul>
-				<li><strong>Linked Open Vocabularies (LOV)</strong> 
-					[<cite><a href="#bib-LOV" class="bibref">LOV</a></cite>] - an entry point to the growing
-				ecosystem of linked open vocabularies (RDFS or OWL ontologies) used
-				in the Linked Data Cloud. Users can find vocabularies listed and
-				individually described by metadata, classified by vocabulary spaces,
-				and interlinked using the dedicated vocabulary VOAF. The site allows
-				users to query the LOV dataset either at vocabulary level or at
-				element level, exploring the vocabulary content using full-text
-				faceted search, and finding metrics about the use of vocabularies in
-				the Semantic Web. Users can also suggest a new vocabulary to add to
-				LOV. [<cite><a href="#bib-LOV" class="bibref">LOV</a></cite>]</li>
-				<li><strong>Common Vocabularies / Ontologies / Micromodels</strong> [<cite><a href="#bib-LOD-COMMON-VOCABS" class="bibref">LOD-COMMON-VOCABS</a></cite>] - a wiki list maintained by the Linked Data LOD community project.</li>
-			</ul>
-
-			<div style="clear: both"></div>
-
-		</section>
-
-	</section>
-	<!-- End Guidelines Section -->
-
-	<section id="acknowledgements" class="appendix">
-		<!--OddPage--><h2 id="h2_acknowledgements" role="heading" aria-level="1"><span class="secno">A. </span>Acknowledgements</h2>
-		<p>Many thanks to Robin Berjon and all contributors to the <a href="http://www.w3.org/respec/">ReSpec</a> tool, which makes writing these kinds of documents much easier.
-		</p>
-		<p>To the following individuals who, in addition to the editors, have 
-contributed either directly or indirectly to the ongoing improvement of 
-this document: 
-			</p><ul>
-				<li><a href="http://lehors.wordpress.com/">Arnaud Le Hors</a>, IBM</li>
-				<li><a href="http://www.linkedin.com/pub/ashok-malhotra/4/675/6a2">Ashok Malhotra</a>, Oracle</li>
-				<li>Bart van Leeuwen</li>
-				<li>David Wood</li>
-				<li><a href="http://www.w3.org/People/Eric/">Eric Prud'hommeaux</a>, <abbr title="World Wide Web Consortium">W3C</abbr></li>
-				<li>Henry Story</li>
-				<li>John Arwe, IBM</li>
-				<li>Kevin Page</li>
-				<li>Miel Vander Sande</li>
-				<li><a href="http://melvincarvalho.com/">Melvin Carvalho</a></li>
-				<li>Raúl García Castro</li>
-				<li><a href="http://richard.cyganiak.de/">Richard Cyganiak</a></li>
-				<li><a href="http://www.linkedin.com/in/yadnem">Roger Menday</a>, Fujitsu Laboratories of Europe</li>
-				<li><a href="http://www.w3.org/People/Sandro/">Sandro Hawke</a>, <abbr title="World Wide Web Consortium">W3C</abbr></li>
-				<li><a href="http://stevebattle.me/">Steve Battle</a></li>
-				<li><a href="http://stevespeicher.blogspot.com/">Steve Speicher</a>, IBM</li>
-				<li>Ted Thibodeau</li>
-			</ul>
-	</section>
-
-
-
-
-
-<div style="position: fixed; top: 20px; right: 20px; width: 202px; text-align: right;" id="respec-ui" class="removeOnSave"><button style="background: none repeat scroll 0% 0% rgb(255, 255, 255); font-weight: bold; border: 1px solid rgb(204, 204, 204); border-radius: 5px;">ReSpec</button><div style="background: none repeat scroll 0% 0% rgb(255, 255, 255); border: 1px solid rgb(0, 0, 0); width: 200px; display: none; text-align: left; margin-top: 5px; margin-right: 5px;"><button style="background: none repeat scroll 0% 0% rgb(255, 255, 255); border-width: medium medium 1px; border-style: none none solid; border-color: -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); -moz-border-top-colors: none; -moz-border-right-colors: none; -moz-border-bottom-colors: none; -moz-border-left-colors: none; border-image: none; width: 100%; text-align: left; font-size: inherit;">Save Snapshot</button><button style="background: none repeat scroll 0% 0% rgb(255, 255, 255); border-width: medium medium 1px; border-style: none none solid; border-color: -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); -moz-border-top-colors: none; -moz-border-right-colors: none; -moz-border-bottom-colors: none; -moz-border-left-colors: none; border-image: none; width: 100%; text-align: left; font-size: inherit;">About ReSpec</button><button style="background: none repeat scroll 0% 0% rgb(255, 255, 255); border-width: medium medium 1px; border-style: none none solid; border-color: -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); -moz-border-top-colors: none; -moz-border-right-colors: none; -moz-border-bottom-colors: none; -moz-border-left-colors: none; border-image: none; width: 100%; text-align: left; font-size: inherit;">Search Specref DB</button></div></div><section rel="bibo:Chapter" resource="#references" typeof="bibo:Chapter" id="references" class="appendix"><!--OddPage--><h2 id="h2_references" role="heading" aria-level="1"><span class="secno">B. </span>References</h2><section rel="bibo:Chapter" resource="#informative-references" typeof="bibo:Chapter" id="informative-references"><h3 id="h3_informative-references" role="heading" aria-level="2"><span class="secno">B.1 </span>Informative references</h3><dl about="" class="bibliography"><dt id="bib-DC-RDF">[DC-RDF]</dt><dd rel="dcterms:references">M. Nilsson et al. <a href="http://dublincore.org/documents/dc-rdf/"><cite>Expressing Dublin Core metadata using the Resource Description Framework (RDF)</cite></a>. 14 January 2008. DCMI Recommendation. URL: <a href="http://dublincore.org/documents/dc-rdf/">http://dublincore.org/documents/dc-rdf/</a>
-</dd><dt id="bib-HTTP11">[HTTP11]</dt><dd rel="dcterms:references">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7230.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7230.txt">http://www.ietf.org/rfc/rfc7230.txt</a>
-</dd><dt id="bib-LD-DI">[LD-DI]</dt><dd rel="dcterms:references">Tim Berners-Lee. <a href="http://www.w3.org/DesignIssues/LinkedData.html"><cite>Linked Data - Design Issues</cite></a>. URL: <a href="http://www.w3.org/DesignIssues/LinkedData.html">http://www.w3.org/DesignIssues/LinkedData.html</a>
-</dd><dt id="bib-LD-GLOSSARY">[LD-GLOSSARY]</dt><dd rel="dcterms:references">B Hyland; G Atemezing; M Pendleton; B Srivastava. <a href="http://www.w3.org/TR/ld-glossary/"><cite>Linked Data Glossary</cite></a>. URL: <a href="http://www.w3.org/TR/ld-glossary/">http://www.w3.org/TR/ld-glossary/</a>
-</dd><dt id="bib-LDP">[LDP]</dt><dd rel="dcterms:references">Steve Speicher; John Arwe; Ashok Malhotra. <a href="http://www.w3.org/TR/ldp/"><cite>Linked Data Platform 1.0</cite></a>. 19 June 2014. W3C Candidate Recommendation. URL: <a href="http://www.w3.org/TR/ldp/">http://www.w3.org/TR/ldp/</a>
-</dd><dt id="bib-LDP-PRIMER">[LDP-PRIMER]</dt><dd rel="dcterms:references">Nandana Mihindukulasooriya; Roger Menday. <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html"><cite>Linked Data Platforn Primer</cite></a>. W3C Working Draft. URL: <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html</a>
-</dd><dt id="bib-LDP-TESTS">[LDP-TESTS]</dt><dd rel="dcterms:references">Raúl García-Castro. <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html"><cite>Linked Data Platform 1.0 Test Cases</cite></a>. W3C Working Draft. URL: <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html</a>
-</dd><dt id="bib-LDP-UCR">[LDP-UCR]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/TR/ldp-ucr/"><cite>Linked Data Platform Use Cases and Requirements</cite></a>. W3C Working Group Note. URL: <a href="http://www.w3.org/TR/ldp-ucr/">http://www.w3.org/TR/ldp-ucr/</a>
-</dd><dt id="bib-LOD-COMMON-VOCABS">[LOD-COMMON-VOCABS]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies"><cite>Common Vocabularies / Ontologies / Micromodels </cite></a>. URL: <a href="http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies">http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies</a>
-</dd><dt id="bib-LOV">[LOV]</dt><dd rel="dcterms:references"><a href="http://lov.okfn.org/dataset/lov/"><cite>Linked Open Vocabularies (LOV)</cite></a>. URL: <a href="http://lov.okfn.org/dataset/lov/">http://lov.okfn.org/dataset/lov/</a>
-</dd><dt id="bib-RDF-PRIMER11">[RDF-PRIMER11]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/"><cite>RDF 1.1 Primer</cite></a>. W3C Working Group Note. URL: <a href="http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/">http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/</a>
-</dd><dt id="bib-RDF-SCHEMA">[RDF-SCHEMA]</dt><dd rel="dcterms:references">Dan Brickley; Ramanathan Guha. <a href="http://www.w3.org/TR/rdf-schema/"><cite>RDF Schema 1.1</cite></a>. 25 February 2014. W3C Recommendation. URL: <a href="http://www.w3.org/TR/rdf-schema/">http://www.w3.org/TR/rdf-schema/</a>
-</dd><dt id="bib-RFC3986">[RFC3986]</dt><dd rel="dcterms:references">T. Berners-Lee; R. Fielding; L. Masinter. <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource Identifier (URI): Generic Syntax</cite></a>. January 2005. Internet Standard. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>
-</dd><dt id="bib-RFC3987">[RFC3987]</dt><dd rel="dcterms:references">M. Duerst; M. Suignard. <a href="http://www.ietf.org/rfc/rfc3987.txt"><cite>Internationalized Resource Identifiers (IRIs)</cite></a>. January 2005. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc3987.txt">http://www.ietf.org/rfc/rfc3987.txt</a>
-</dd><dt id="bib-RFC7231">[RFC7231]</dt><dd rel="dcterms:references">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7231.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7231.txt">http://www.ietf.org/rfc/rfc7231.txt</a>
-</dd><dt id="bib-TURTLE">[TURTLE]</dt><dd rel="dcterms:references">Eric Prud'hommeaux; Gavin Carothers. <a href="http://www.w3.org/TR/turtle/"><cite>RDF 1.1 Turtle</cite></a>. 25 February 2014. W3C Recommendation. URL: <a href="http://www.w3.org/TR/turtle/">http://www.w3.org/TR/turtle/</a>
-</dd><dt id="bib-WEBARCH">[WEBARCH]</dt><dd rel="dcterms:references">Ian Jacobs; Norman Walsh. <a href="http://www.w3.org/TR/webarch/"><cite>Architecture of the World Wide Web, Volume One</cite></a>. 15 December 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a>
-</dd><dt id="bib-XMLSCHEMA11-2">[XMLSCHEMA11-2]</dt><dd rel="dcterms:references">David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. <a href="http://www.w3.org/TR/xmlschema11-2/"><cite>W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes</cite></a>. 5 April 2012. W3C Recommendation. URL: <a href="http://www.w3.org/TR/xmlschema11-2/">http://www.w3.org/TR/xmlschema11-2/</a>
-</dd><dt id="bib-metaDataInURI">[metaDataInURI]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/2001/tag/doc/metaDataInURI-31"><cite>The use of Metadata in URIs</cite></a>. finding. URL: <a href="http://www.w3.org/2001/tag/doc/metaDataInURI-31">http://www.w3.org/2001/tag/doc/metaDataInURI-31</a>
-</dd></dl></section></section></body></html>
\ No newline at end of file
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-acr.html	Mon Aug 25 16:47:16 2014 -0400
@@ -0,0 +1,220 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>LDP Access Control</title>
+    <!-- Changed by: , 25-Aug-2014 -->
+    <meta charset='utf-8'>
+    <script src='https://www.w3.org/Tools/respec/respec-w3c-common'
+            async class='remove'></script>
+    <script class='remove'>
+      var respecConfig = {
+          // specification status (e.g. WD, LCWD, WG-NOTE, etc.). If in doubt use ED.
+          specStatus:           "WG-NOTE",
+          
+          // the specification's short name, as in http://www.w3.org/TR/short-name/
+          shortName:            "ldp-acr",
+
+          // if your specification has a subtitle that goes below the main
+          // formal title, define it here
+          subtitle   :  "Usecases and Requirements for Access Control for the Linked Data Platform",
+
+          // if you wish the publication date to be other than the last modification, 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:  "1977-03-15",
+          // previousMaturity:  "WD",
+
+          // if there a publicly available Editor's Draft, this is the link
+          edDraftURI:           "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-acr.html",
+
+          // if this is a LCWD, uncomment and set the end of its review period
+          // lcEnd: "2009-08-05",
+
+          // editors, add as many as you like
+          // only "name" is required
+          editors:  [
+              {
+                  name:       "Ashok Malhotra"
+              ,   mailto:     "[email protected]"
+              ,   company:    "Oracle America, Inc."
+              ,   companyURL: "http://www.oracle.com/"
+              },
+          ],
+          
+          // name of the WG
+          wg:           "Linked Data Platform WG",
+          
+          // 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: "[email protected]",
+          
+          // 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",
+          // !!!! IMPORTANT !!!! MAKE THE ABOVE BLINK IN YOUR HEAD
+      };
+    </script>
+  </head>
+  <body>
+    <section id='abstract'>
+      <p>
+        This note discusses usecases and requirements for Access Control for the 
+		<a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a> 
+		It also outlines a charter for developing a standard for HTTP-based access control. 
+		The work delineated in the charter may be pursued in the Linked Data Platform WG or an independent, related WG. 
+      </p>
+    </section>
+    
+    <section id='sotd'>
+      <p>
+        While the <a href="https://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform WG.</a> did not 
+		address Access Control directly, a number of usescases and requirements were identified as part of its
+		deliberations.  These usecases and requirements are captured in this document to serve as a basis for 
+		future work.    
+      </p>
+    </section>
+    
+    <section>
+      <h2>Access Control</h2>
+      <p>
+        Access Control is a mechanism through which an agent ( an HTTP server in this case ) permits other agents -- 
+		individuals, organizations, and/or groups made up of these -- to perform certain operations on resources as 
+		specified by policies for the resources and for the agents. Within this document, the resources are LDP resources, but the access 
+		control may operate at different granularities: RDF or other documents, named graphs or individual triples.
+		The operations are typically create, read, update, and delete (CRUD) but other operations can easily be accomodated by
+		this design.
+		</p>
+		<p>
+        When an agent requests a collection of resources it gets to see only those resources or parts of resources 
+		it is authorized for.</p>
+		<p>
+		Depending on the granularity, the access control mechanisms may affect performance, but should not affect 
+		semantics.</p>
+		<p>
+		For access control to come into play, the server must restrict some operations on some resources. 
+		</p>
+		</section>
+		<section>
+	  <h2>Terminology</h2>
+	  <ul>
+	  <li>ACG: An Access Control Graph describes the permitted modes of access for particular agents to apecific resources.</li>
+	  <li>ACG Resource: A resource whose representation contains one or more ACGs which the server relies 
+	  upon to make access control decisions.</li>
+	  </ul>
+    </section>
+	<section>
+	<h2>Usecases</h2>
+	<section>
+	<h3>Access Control on manipulation of resources via HTTP</h3>
+	Adam's user agent attempts:
+	<ol>	
+    <li>To CREATE, READ, UPDATE (or PATCH), or DELETE a resource identified by a URL.  The server may immediately 
+	allow or deny the request, or it may request that he authenticate to confirm his privileges, 
+	as specified by the ACG for the Resource.</li>
+    <li>If he is denied access, an explanation of why all or part of his request was denied should be provided 
+	so that it becomes possible to detect errors, and so that he may modify the request -- 
+	potentially to include making a request for such privileges.
+	</li>
+    <li>Adam would ideally like to know whether he will be able to perform an Action on a Resource 
+	before attempting such - i.e., whether he will have to authenticate before he is able to Read or Write the Resource.
+	</li>
+	</ol>
+	</section>
+	<section>
+	<h3>Editability of Access Control Rules using HTTP</h3>
+	<ol>
+	<li>
+    Bart's user agent logs on to a server and requests
+	the capability to read a group of related resources such as all the papers presented at a conference.</li>
+    </li>
+	<li>Employees with job titles VP or SVP can sign (update) supplier contracts.</li>
+    <li>Charlie, the Webmaster, would like to grant read access to the papers presented at a conference to all the 
+	people who attended the conference.</li>
+	</ol>
+	</section>
+	<section>
+	<h3>User Interface Scenarios</h3>
+	Eddie's HTTP based user agent would like to provide a user interface to allow, where possible, Eddie to 
+	<ol>
+	<li>Know if he can edit or delete a resource.</li>
+    <li>Know what he would have to do to have access to a resource ( be someone's friend, be part of a club, have 
+	paid a fee )</li>
+	<li>Allow Eddie to edit the access control rules for a resource such as:
+	<ol>
+        <li>Allow friends of his to access a document.</li>
+        <li>Allow friends of his to POST to a container, but only read a subset of the contents of the container, 
+		those posted by that agent for example.</li>
+        <li>Allow all the members of the LDP WG to create and edit resources including LDP Containers under a 
+		specific URL pattern.</li>
+		<li>Allow all friends of friends as expressed by the foaf:knows relations in one's foaf profile to POST comments 
+		to a container related to some content, and edit their own comments.</li>
+		<li>Allow the members of the LDP WG, the RWW CG, the WebID CG, and the member of the European Ontologist Network, 
+		to work together on set of ontologies. It should be possible to drag and drop URLs for these groups, 
+		found on the web, onto the User Interface as a way of creating the union of the members of the group.</li> 
+	</ol>
+	</ol>
+	</section>
+	<section>
+	<h2>Requirements</h2>
+	<ul>
+	<li>An Agent must be able to authenticate itself to a server with an identifier or as the owner of a token. 
+	( All use cases )</li>
+    <li>Ability to specify a collection of agents, identifying agents with URIs, URI patterns, or by description. 
+	(Usecase 3.2.2, 3.2.3)</li>
+    <li>Ability to specify a collection of resources, identified by URIs or URI patterns or by description,
+	with a specified access policy. (Usecase 3.2.1, 3.2.3)</li>
+    <li>Ability to connect a collection of agents with a collection of resources with given access privileges. 
+	( All use cases )</li>
+	</ul>
+	
+	<p>The above requirements require the ability, by an authorized agent, to CREATE, EDIT, UPDATE relevant ACGs. 
+
+	<ul>
+	<li>Ability to specify access privileges at a fine-grained level. (Usecase 3.1.2, 3.2.1.2)</li>
+    <li>The server should be able to describe access control policies for a resource. (Usecase 3.1.4, 3.3.1, 3.3.2)</li>
+    <li>The server should be able explain the reasons for access being disallowed in a machine readable format.
+	(Usecase 3.1.3)
+	</li>
+    <li>A user-agent should be able to find the ACG for a given resource.(Usecase 3.1.1)</li>
+	<li>The ability by one user agent to delegate the authority to create and edit ACGs to another agent.(Usecase 3.3.3)</li>
+	</ul>
+	</section>
+	<section>
+	<h2>Outline of a Charter for a Access Control WG</h2>
+	<p>An Access Control Graph (ACG) consists of two kinds of collections: a collection of agents and a collection of 
+	resources. It then connects a collection of agents with a collection of resources with the connection identifying 
+	the privileges the agents have on the resources: CREATE, READ, UPDATE, DELETE.</p>
+	<p>ACGs are resources in their own right and can have access control priviledges specified for them just like
+	any other resource.  This permits the creation and modification of ACGs to be delegated.
+	</p>
+	<p>
+	The members of the collection of agents contain tokens that the agents obtain from some authentication service. 
+	The members of the collection of resources are URIs or URI templates.</p>
+	<p>The WG will need to decide whether it also wants to define fine-grained access control at an attribute level.</p>
+<section>
+<h2>Deliverables</h2>
+<ul>
+<li>Define the collections that are part of the ACG and define how a collection of agents is connected to a 
+connection of resources.</li>
+<li>Define how ACGs can be created and edited and how these rights can be delegated.</li>
+<li>Describe a proof-of-concept implementation of how a request for access to a resource by an agent can be processed 
+efficiently with the ACG structure defined above.</li>
+</ul> 
+</section>	
+	</section>
+	</section>
+    
+    
+  </body>
+</html>
--- a/tests/ldp-testsuite.html	Mon Aug 25 16:45:08 2014 -0400
+++ b/tests/ldp-testsuite.html	Mon Aug 25 16:47:16 2014 -0400
@@ -1,3 +1,3 @@
 <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
	prefix="td: http://www.w3.org/2006/03/test-description# ldpt: http://www.w3.org/ns/ldp/test#">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<!--    rgarcia: Had to uncomment it so it can read the local image
<base href="http://www.w3.org/TR/ldp/TestCases">-->
<title>Linked Data Platform 1.0 Test Cases</title>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common'
	class='remove' async></script>
<script class='remove'>
	var respecConfig = {
		// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
		specStatus : "unofficial",

		// the specification's short name, as in http://www.w3.org/TR/short-name/
		shortName : "ldp-testsuite",
		// 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:  "2013-03-07",
		//previousMaturity:  	"FPWD",
		//previousURI: 			"http://www.w3.org/TR/2013/WD-ldp-20130307/",

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

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

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

		// editors, add as many as you like
		// only "name" is required
		editors : [
				{
					name : "Raúl García-Castro",
					url : "http://www.garcia-castro.com/",
					company : "Ontology Engineering Group, Universidad Politécnica de Madrid",
					companyURL : "http://www.oeg-upm.net/"
				},
				{
					name : "Fernando Serena",
					company : "Ontology Engineering Group, Universidad Politécnica de Madrid",
					companyURL : "http://www.oeg-upm.net/"
				},
	            {	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",
		doRDFa : "1.1",
-		localBiblio:  {
		    "LDP-PRIMER": {
			        title:    "Linked Data Platform 1.0 Primer",
			        href:     "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html",
			        authors:  [
			            "Nandana Mihindukulasooriya",
-			            "Roger Menday"
			        ],
			        status:   "WD",
			        deliveredBy: [
                        "http://www.w3.org/2012/ldp/"
                    ],
			        publisher:  "W3C"
		    },
		    "LDP-TESTCASES": {
		        title:    "Linked Data Platform Test Cases",
		        href:     "http://w3c.github.io/ldp-testsuite/",
		        deliveredBy: [
                    "http://www.w3.org/2012/ldp/"
                ]
		    },
		    "LDP-TESTSUITE-COVERAGE": {
		        title:    "Linked Data Platform Test Suite Coverage",
		        href:     "http://w3c.github.io/ldp-testsuite/report/ldp-testsuite-coverage-report.html",
		        deliveredBy: [
                    "http://www.w3.org/2012/ldp/"
                ]
		    },
		    "LDP-IMPL": {
		        title:    "Linked Data Platform Implementation Reports",
		        href:     "https://dvcs.w3.org/hg/ldpwg/raw-file/default/tests/reports/ldp.html",
		        deliveredBy: [
                    "http://www.w3.org/2012/ldp/"
                ]
		    },
		    
    }
	};
</script>
</head>
<body>

	<section id='abstract'>
	<p>The Linked Data Platform specification, informally LDP,
		describes the use of HTTP for accessing, updating, creating and
		deleting resources from servers that expose their resources as Linked
		Data. This document introduces the conditions that LDP servers must
		satisfy in order to be conformant with the specification and presents
		a common format for describing LDP test results.
		These test cases both illustrate the features of the specification and
		can be used for testing conformance. [[LINKED-DATA-PLATFORM]]</p>
	</section>

	<section id='sotd'>
      <p>
      <!--Empty. Nothing else to add.-->
      </p>
    </section>

	<section>
	<h2>Introduction</h2>
	<p>
		This document introduces a test suite that can be used to evaluate the
		conformance of LDP servers to the LDP specification
		[[LINKED-DATA-PLATFORM]]. The document also presents the design
		principles that guided the development of the test suite, a testing
		process, and a common format for describing test results.</p> 
	<p>The purpose of the test cases is to illustrate the
		specification features and to help in testing conformance. The
		provided set of test cases is "incomplete" in the sense that passing
		all the tests does not prove that a given system conforms to the LDP
		specification; failing a test does, however, prove that the system
		does not conform to the specification.</p>
	<p>The presented format is intended to facilitate the use of
		tests by LDP server developers, e.g., in a test harness, as well as
		the extension of the test suite with new tests. Developers can check
		the LDP Primer [[LDP-PRIMER]] for concrete examples of inputs and
		expected outputs that can be used for testing.
	</p>
	</section>

	<section>
	<h2>Design principles</h2>

	<section>
	<h3>Generic vs domain-specific servers</h3>
	<p>There will be two types of servers implementing the LDP
		specification:</p>
	<ul>
		<li>Generic storage systems that allow interacting with their
			resources by means of the LDP specification. These servers do not
			impose any restriction on LDPRs.</li>
		<li>Servers exposing their data using the LDP specification.
			These servers impose restrictions on LDPRs since they have an
			underlying business logic and data model.</li>
	</ul>
	<p>In order to cover both types of servers, there are some basic input 
		data and a way to  provide
		specific input data in the test suite. It is up to the evaluator to
		define specific input data for a certain server. Evaluators must
		include these input data along with the results when reporting the
		results of a certain server.</p>
	</section> 
	
	<section>
	<h3>Protocol evaluation vs data evaluation</h3>
	<p>The LDP specification includes restrictions on LDP servers at
		the protocol level and at the data level. Currently, the restrictions
		at the data level are minimal and servers are not forced to have a
		certain behavior when processing LDPR representations. Therefore, the
		test suite evaluates LDP servers mostly at a protocol level; the only
		exception is in the case of LDPCs, since they are required to include
		a <code>rdf:type</code>, containment and membership statements in their 
		representation.</p>
	<p>It is out of the scope of the test suite to test LDP servers in
		terms of the restrictions imposed by their underlying data models.</p>
	</section> 
	
	<section>
	<h3>Test suite coverage</h3>
	<p>
		The test suite covers those requirements present in the
		LDP specification of any compliance level: MUST, SHOULD and MAY. This
		set of absolute requirements identifies the core subset of the LDP
		specification,
		<dfn>LDP Core</dfn>
		from now on, and any LDP server that satisfies these absolute
		requirements will be an LDP Core conformant server.
	</p>
	<p>It is out of the scope of the test suite to test other levels
		of conformance in terms of optional capabilities (e.g., paging, patch formats).</p>
	<p>
		Furthermore, the LDP specification [[LINKED-DATA-PLATFORM]] contains
		a number of requirements that can not validated by automated means,
		these are identified in a coverage report for the [[LINKED-DATA-PLATFORM]].
		These requirements will need to be validated by some non-automatic method 
		and results evaluated.
	</p>
	</section>
	
	<section>
	<h3>Separation of results and assertions</h3>
	<p>Instead of defining expected results for tests, which will be
		dependent on specific implementations, we have defined the assertions
		to be made over test results. In order to successfully pass a test,
		all of the assertions must be satisfied.</p>
	<p>Separating test outputs and assertions has other benefits: it
		makes simpler to report tool results and assertions can be made by a
		third party.</p>
	</section>
	
	<section>
	<h3>Traceability of test cases</h3>
	<p>Any test case and its produced results and assertions should be
		related to those documents that are relevant for it (e.g.,
		specifications, uses cases, etc.).</p>
	</section>
	</section>

	<section>
	<h2>Testing process</h2>
	<p>The LDP Test Cases are defined in a location, within Java source code. [[LDP-TESTCASES]]
		Details about each individual test case, such as information about
		whether it can be executed by automated means, manual or client only,
		will be found in the Java source code annotations.
		Also in the Java source code annotations the status of each test case, such as approved by the LDP 
		Working Group, awaiting approval or not yet implemented.[[LDP-TESTSUITE-COVERAGE]]</p>
	<ol>
		<li>The person or agent in charge of executing the test cases in
			a specific LDP server will take the test case definitions and run
			every test case on the LDP server.  The execution of test
			cases must produce a test execution report for the LDP server, in RDF
			format, that contains for every test case: the specific inputs used
			during its execution, the produced outputs, and the assertion of
			whether the test case is passed. The test execution report must be
			supplied as defined in the document on implementation reports. [[LDP-IMPL]]</li>
		<li>A report generator software will take all the LDP server
			execution reports and will generate an implementation report that
			includes the results of all the LDP servers. [[LDP-IMPL]]</li>
	</ol>
	<p><object data="TestingProcess.svg" type="image/svg+xml">Your
			browser does not support SVG.</object>
	</p>
	</section>

	<section>
	<h2>Describing testing artifacts in RDF</h2>

	<section>
	<h3>Namespaces used</h3>
	<p>
		The following vocabularies are reused for describing the testing
		artifacts: DOAP (
		<code>doap</code>
		), Dublin Core (
		<code>dcterms</code>
		) [[DC11]], FOAF (
		<code>foaf</code>
		) [[FOAF]], and W3C Test Metadata (
		<code>td</code>
		) [[TEST-METADATA]].
	</p>
	<p>
		All the new required entities that are not covered by those
		vocabularies have been defined under a new namespace (
		<code>ldpt</code>
		), as well as the LDP test cases.
	</p>
	<p>Next we present the definition of these namespaces and of all
		the namespaces used in the examples.</p>
	<pre>dcterms: &lt;http://purl.org/dc/terms/&gt;
doap: &lt;http://usefulinc.com/ns/doap#&gt;
earl: &lt;http://www.w3.org/ns/earl#&gt;
foaf: &lt;http://xmlns.com/foaf/0.1/&gt;
mf: &lt;http://www.w3.org/2001/sw/DataAccess/tests/test-manifest#&gt;
rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;
rdft: &lt;http://www.w3.org/ns/rdftest#&gt;
td: &lt;http://www.w3.org/2006/03/test-description#&gt;
ldpt: &lt;http://www.w3.org/ns/ldp/test#&gt;</pre> </section> 
   
   <section>
	<h3>Test case description</h3>
	<p>
		A
		<dfn id="dfn-test-case" title="test case">test case</dfn>
		is defined as an instance of the
		<code>td:TestCase</code>
		class and it can be further described using the following properties:
	</p>
	<ul>
		<li><code>rdfs:label</code>. The human-readable label of the
			test.</li>
		<li><code>mf:name</code>. Like <code>rdfs:label</code> but less human
		focus.</li>
		<li><code>dcterms:title</code>. The name of the test.</li>
		<li><code>dcterms:description</code>. The description of the test.</li>
		<li><code>dcterms:contributor</code>. The person (<code>foaf:Person</code>)
			contributing the test.</li>
		<li><code>dcterms:subject</code>. The grouping of test or compliance level.</li>
		<li><code>td:reviewStatus</code>. The status of the test;
			possible status are: <code>td:unreviewed</code>, <code>td:approved</code>
			or <code>td:rejected</code>.</li>
		<li><code>rdfs:seeAlso</code>. A link to the specification it
			refers to.</li>
		<li><code>td:specificationReference</code>. An <a href="#dfn-excerpt">excerpt</a> (<code>tn:Excerpt</code>)
			of the specification that is relevant to the test.</li>
	</ul>

	<p>
		An
		<dfn id="dfn-excerpt" title="excerpt">excerpt</dfn>
		is defined as an instance of the
		<code>tn:Excerpt</code>
		class and it can be further described using the following properties:
	</p>
	<ul>
		<li><code>rdfs:seeAlso</code>: The document where the excerpt is
			included.</li>
		<li><code>tn:includesText</code>. The excerpt from the document.</li>
	</ul>

	<p>The following example contains the description of one of the LDP
		test cases.</p>
	<pre class="example" id="test-case-example">ldpt:CommonResource-GetResource a td:TestCase;
         rdfs:label "CommonResource-GetResource";
         mf:name "CommonResource-GetResource";
         dcterms:title "GET on an LDPR";
         dcterms:description "Tests making a GET request on an existing LDPR";
         dcterms:contributor :RaulGarciaCastro;
         td:reviewStatus td:approved;
         rdfs:seeAlso &lt;http://www.w3.org/TR/ldp#ldpr-get-must&gt;;
         dcterms:subject "MUST" ;
         td:specificationReference [
             a tn:Excerpt;
             rdfs:seeAlso &lt;http://www.w3.org/TR/ldp#ldpr-get-must&gt;;
             tn:includesText "LDP servers MUST support the HTTP GET Method for LDPRs".
           ].

:RaulGarciaCastro a foaf:Person;
                    rdfs:label "Raúl García-Castro";
                    owl:sameAs &lt;http://www.garcia-castro.com/#me&gt;.</pre> 
    </section>
    
 
	<section>
	<h3>
		Test case assertion description
	</h3>
	<p>
		An
		<dfn id="dfn-assertion" title="assertion">assertion</dfn>
		is defined as an instance of the
		<code>earl:Assertion</code>
		class and it can be further described using the following properties:
	</p>
	<ul>
		<li><code>earl:subject</code>.The subject (<code>doap:Project</code>)
			asserted.</li>
		<li><code>earl:test</code>. The <a href="#dfn-test-case">test
				case</a> (<code>td:TestCase</code>) to which the assertion refers to.</li>
		<li><code>dcterms:date</code>. The date when the assertion was
			performed.</li>
		<li><code>earl:assertedBy</code>. The validator (<code>doap:Project</code>)
			that makes the assertion.</li>
		<li><code>earl:mode</code>. The execution mode of the validator. In this case it will always be
			<code>earl:automatic</code>.</li>
		<li><code>earl:result</code>. The outcome value (<code>earl:OutcomeValue</code>)
			of the assertion.</li>
	</ul>
	<p>The following example contains the description of one test
		assertion.</p>
	<pre class="example" id="test-assertion-example">:TCR1-Assertion-SomeServer a earl:Assertion;
	earl:subject :AwesomeLDP;
	earl:test ldpt:CommonResource-GetResource;
	earl:assertedBy :AwesomeLDP;
	earl:mode:  earl:automatic;
	earl:result [
		a earl:OutcomeValue ;
		dcterms:date "2014-07-06T09:30:10";
		earl:outcome earl:passed
    ].

:AwesomeLDP a doap:Project, earl:TestSubject, earl:Software, earl:Assertor;
	doap:name "Awesome LDP";
	doap:description "Awesome LDP implementation";
	doap:developer    [ a	foaf:Person ;
						foaf:mbox  "[email protected]" ;
						foaf:name  "Dope Developer"
                      ];
	doap:homepage	&lt;http://example.org/AwesomeLDP&gt;;
	doap:programming-language "JavaScript".</pre> 
            
    </section>
    </section>
	</section>
	</section>

	<section class="appendix">
	<h2>Change history</h2>
	<ul>
		<li>2014-07-08 Various grammar fixes and removed todos (SS)</li>
		<li>2014-07-07 Further alignment with current testing approach and namespaces (SS)</li>
		<li>2014-06-22 Brought inline with separate automated testsuite hosted on GitHub (SS)</li>
		<li>2014-04-09 Updated according to Last Call Working Draft from 11 March 2014 (FS and RGC)</li>
		<li>2013-08-27 Updated according to Last Call Working Draft from 30 July 2013 (RGC)</li>
		<li>2013-06-03 Updated to use ReSpec (RGC)</li>
		<li>2013-06-03 Implemented <a
			href="http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0153.html">changes
				suggested by Eric Prud'hommeaux</a> (RGC)
		</li>
	</ul>
	</section>

</body>
</html>
\ No newline at end of file
+		localBiblio:  {
		    "LDP-PRIMER": {
			        title:    "Linked Data Platform 1.0 Primer",
			        href:     "http://www.w3.org/TR/ldp-primer/",
			        authors:  [
			            "Nandana Mihindukulasooriya",
+			            "Roger Menday"
			        ],
			        status:   "NOTE",
			        deliveredBy: [
                        "http://www.w3.org/2012/ldp/"
                    ],
			        publisher:  "W3C"
		    },
		    "LDP-TESTCASES": {
		        title:    "Linked Data Platform Test Cases",
		        href:     "http://w3c.github.io/ldp-testsuite/",
		        deliveredBy: [
                    "http://www.w3.org/2012/ldp/"
                ]
		    },
		    "LDP-TESTSUITE-COVERAGE": {
		        title:    "Linked Data Platform Test Suite Coverage",
		        href:     "http://w3c.github.io/ldp-testsuite/report/ldp-testsuite-coverage-report.html",
		        deliveredBy: [
                    "http://www.w3.org/2012/ldp/"
                ]
		    },
		    "LDP-CONFORM": {
		        title:    "Linked Data Platform Implementation Conformance Report",
		        href:     "https://dvcs.w3.org/hg/ldpwg/raw-file/default/tests/reports/ldp.html",
		        deliveredBy: [
                    "http://www.w3.org/2012/ldp/"
                ]
		    },
		    
    }
	};
</script>
</head>
<body>

	<section id='abstract'>
	<p>The Linked Data Platform specification, informally LDP,
		describes the use of HTTP for accessing, updating, creating and
		deleting resources from servers that expose their resources as Linked
		Data. This document introduces the conditions that LDP servers must
		satisfy in order to be conformant with the specification and presents
		a common format for describing LDP test results.
		These test cases both illustrate the features of the specification and
		can be used for testing conformance. [[LINKED-DATA-PLATFORM]]</p>
	</section>

	<section id='sotd'>
      <p>
      <!--Empty. Nothing else to add.-->
      </p>
    </section>

	<section>
	<h2>Introduction</h2>
	<p>
		This document introduces a test suite that can be used to evaluate the
		conformance of LDP servers to the LDP specification
		[[LINKED-DATA-PLATFORM]]. The document also presents the design
		principles that guided the development of the test suite, a testing
		process, and a common format for describing test results.</p> 
	<p>The purpose of the test cases is to illustrate the
		specification features and to help in testing conformance. The
		provided set of test cases is "incomplete" in the sense that passing
		all the tests does not prove that a given system conforms to the LDP
		specification; failing a test does, however, prove that the system
		does not conform to the specification.</p>
	<p>The presented format is intended to facilitate the use of
		tests by LDP server developers, e.g., in a test harness, as well as
		the extension of the test suite with new tests. Developers can check
		the LDP Primer [[LDP-PRIMER]] for concrete examples of inputs and
		expected outputs that can be used for testing.
	</p>
	</section>

	<section>
	<h2>Design principles</h2>

	<section>
	<h3>Generic vs domain-specific servers</h3>
	<p>There will be two types of servers implementing the LDP
		specification:</p>
	<ul>
		<li>Generic storage systems that allow interacting with their
			resources by means of the LDP specification. These servers do not
			impose any restriction on LDPRs.</li>
		<li>Servers exposing their data using the LDP specification.
			These servers impose restrictions on LDPRs since they have an
			underlying business logic and data model.</li>
	</ul>
	<p>In order to cover both types of servers, there are some basic input 
		data and a way to  provide
		specific input data in the test suite. It is up to the evaluator to
		define specific input data for a certain server. Evaluators must
		include these input data along with the results when reporting the
		results of a certain server.</p>
	</section> 
	
	<section>
	<h3>Protocol evaluation vs data evaluation</h3>
	<p>The LDP specification includes restrictions on LDP servers at
		the protocol level and at the data level. Currently, the restrictions
		at the data level are minimal and servers are not forced to have a
		certain behavior when processing LDPR representations. Therefore, the
		test suite evaluates LDP servers mostly at a protocol level; the only
		exception is in the case of LDPCs, since they are required to include
		a <code>rdf:type</code>, containment and membership statements in their 
		representation.</p>
	<p>It is out of the scope of the test suite to test LDP servers in
		terms of the restrictions imposed by their underlying data models.</p>
	</section> 
	
	<section>
	<h3>Test suite coverage</h3>
	<p>
		The test suite covers those requirements present in the
		LDP specification of any compliance level: MUST, SHOULD and MAY. This
		set of absolute requirements identifies the core subset of the LDP
		specification,
		<dfn>LDP Core</dfn>
		from now on, and any LDP server that satisfies these absolute
		requirements will be an LDP Core conformant server.
	</p>
	<p>It is out of the scope of the test suite to test other levels
		of conformance in terms of optional capabilities (e.g., paging, patch formats).</p>
	<p>
		Furthermore, the LDP specification [[LINKED-DATA-PLATFORM]] contains
		a number of requirements that can not validated by automated means,
		these are identified in a coverage report for the [[LINKED-DATA-PLATFORM]].
		These requirements will need to be validated by some non-automatic method 
		and results evaluated.
	</p>
	</section>
	
	<section>
	<h3>Separation of results and assertions</h3>
	<p>Instead of defining expected results for tests, which will be
		dependent on specific implementations, we have defined the assertions
		to be made over test results. In order to successfully pass a test,
		all of the assertions must be satisfied.</p>
	<p>Separating test outputs and assertions has other benefits: it
		makes simpler to report tool results and assertions can be made by a
		third party.</p>
	</section>
	
	<section>
	<h3>Traceability of test cases</h3>
	<p>Any test case and its produced results and assertions should be
		related to those documents that are relevant for it (e.g.,
		specifications, uses cases, etc.).</p>
	</section>
	</section>

	<section>
	<h2>Testing process</h2>
	<p>The LDP Test Cases are defined in a location, within Java source code. [[LDP-TESTCASES]]
		Details about each individual test case, such as information about
		whether it can be executed by automated means, manual or client only,
		will be found in the Java source code annotations.
		Also in the Java source code annotations the status of each test case, such as approved by the LDP 
		Working Group, awaiting approval or not yet implemented.[[LDP-TESTSUITE-COVERAGE]]</p>
	<ol>
		<li>The person or agent in charge of executing the test cases in
			a specific LDP server will take the test case definitions and run
			every test case on the LDP server.  The execution of test
			cases must produce a test execution report for the LDP server, in RDF
			format, that contains for every test case: the specific inputs used
			during its execution, the produced outputs, and the assertion of
			whether the test case is passed. The test execution report must be
			supplied as defined in the document on implementation conformance reports. [[LDP-CONFORM]]</li>
		<li>A report generator software will take all the LDP server
			execution reports and will generate an implementation report that
			includes the results of all the LDP servers. [[LDP-CONFORM]]</li>
	</ol>
	<p><object data="TestingProcess.svg" type="image/svg+xml">Your
			browser does not support SVG.</object>
	</p>
	
	<section>
	<h2>Submitting results</h2>
	<p>Here is a summary of the steps needed for an assertor to submit the compliance results for an implementation.</p>
	<ul>
		<li>Run the automated test suite [[LDP-TESTCASES]]</li>
		<li>Run the manual tests and update the results within the same EARL results file</li>
		<li>Email results file (at minimum) EARL file (Turtle preferred) to <a href="mailto:[email protected]">[email protected]</a>.  Be sure to indicate if this is intended to
		replace any previously submitted results.  It is also helpful to indicate if these are preliminary results and that plans are to submit additional progress in the future.</li>
	</ul>
	</section>
	
	</section>

	<section>
	<h2>Describing testing artifacts in RDF</h2>

	<section>
	<h3>Namespaces used</h3>
	<p>
		The following vocabularies are reused for describing the testing
		artifacts: DOAP (
		<code>doap</code>
		), Dublin Core (
		<code>dcterms</code>
		) [[DC11]], FOAF (
		<code>foaf</code>
		) [[FOAF]], and W3C Test Metadata (
		<code>td</code>
		) [[TEST-METADATA]].
	</p>
	<p>
		All the new required entities that are not covered by those
		vocabularies have been defined under a new namespace (
		<code>ldpt</code>
		), as well as the LDP test cases.
	</p>
	<p>Next we present the definition of these namespaces and of all
		the namespaces used in the examples.</p>
	<pre>dcterms: &lt;http://purl.org/dc/terms/&gt;
doap: &lt;http://usefulinc.com/ns/doap#&gt;
earl: &lt;http://www.w3.org/ns/earl#&gt;
foaf: &lt;http://xmlns.com/foaf/0.1/&gt;
mf: &lt;http://www.w3.org/2001/sw/DataAccess/tests/test-manifest#&gt;
rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;
rdft: &lt;http://www.w3.org/ns/rdftest#&gt;
td: &lt;http://www.w3.org/2006/03/test-description#&gt;
ldpt: &lt;http://www.w3.org/ns/ldp/test#&gt;</pre> </section> 
   
   <section>
	<h3>Test case description</h3>
	<p>
		A
		<dfn id="dfn-test-case" title="test case">test case</dfn>
		is defined as an instance of the
		<code>td:TestCase</code>
		class and it can be further described using the following properties:
	</p>
	<ul>
		<li><code>rdfs:label</code>. The human-readable label of the
			test.</li>
		<li><code>mf:name</code>. Like <code>rdfs:label</code> but less human
		focus.</li>
		<li><code>dcterms:title</code>. The name of the test.</li>
		<li><code>dcterms:description</code>. The description of the test.</li>
		<li><code>dcterms:contributor</code>. The person (<code>foaf:Person</code>)
			contributing the test.</li>
		<li><code>dcterms:subject</code>. The grouping of test or compliance level.</li>
		<li><code>td:reviewStatus</code>. The status of the test;
			possible status are: <code>td:unreviewed</code>, <code>td:approved</code>
			or <code>td:rejected</code>.</li>
		<li><code>rdfs:seeAlso</code>. A link to the specification it
			refers to.</li>
		<li><code>td:specificationReference</code>. An <a href="#dfn-excerpt">excerpt</a> (<code>tn:Excerpt</code>)
			of the specification that is relevant to the test.</li>
	</ul>

	<p>
		An
		<dfn id="dfn-excerpt" title="excerpt">excerpt</dfn>
		is defined as an instance of the
		<code>tn:Excerpt</code>
		class and it can be further described using the following properties:
	</p>
	<ul>
		<li><code>rdfs:seeAlso</code>: The document where the excerpt is
			included.</li>
		<li><code>tn:includesText</code>. The excerpt from the document.</li>
	</ul>

	<p>The following example contains the description of one of the LDP
		test cases.</p>
	<pre class="example" id="test-case-example">ldpt:CommonResource-GetResource a td:TestCase;
         rdfs:label "CommonResource-GetResource";
         mf:name "CommonResource-GetResource";
         dcterms:title "GET on an LDPR";
         dcterms:description "Tests making a GET request on an existing LDPR";
         dcterms:contributor :RaulGarciaCastro;
         td:reviewStatus td:approved;
         rdfs:seeAlso &lt;http://www.w3.org/TR/ldp#ldpr-get-must&gt;;
         dcterms:subject "MUST" ;
         td:specificationReference [
             a tn:Excerpt;
             rdfs:seeAlso &lt;http://www.w3.org/TR/ldp#ldpr-get-must&gt;;
             tn:includesText "LDP servers MUST support the HTTP GET Method for LDPRs".
           ].

:RaulGarciaCastro a foaf:Person;
                    rdfs:label "Raúl García-Castro";
                    owl:sameAs &lt;http://www.garcia-castro.com/#me&gt;.</pre> 
    </section>
    
 
	<section>
	<h3>
		Test case assertion description
	</h3>
	<p>
		An
		<dfn id="dfn-assertion" title="assertion">assertion</dfn>
		is defined as an instance of the
		<code>earl:Assertion</code>
		class and it can be further described using the following properties:
	</p>
	<ul>
		<li><code>earl:subject</code>.The subject (<code>doap:Project</code>)
			asserted.</li>
		<li><code>earl:test</code>. The <a href="#dfn-test-case">test
				case</a> (<code>td:TestCase</code>) to which the assertion refers to.</li>
		<li><code>dcterms:date</code>. The date when the assertion was
			performed.</li>
		<li><code>earl:assertedBy</code>. The validator (<code>doap:Project</code>)
			that makes the assertion.</li>
		<li><code>earl:mode</code>. The execution mode of the validator. In this case it will always be
			<code>earl:automatic</code>.</li>
		<li><code>earl:result</code>. The outcome value (<code>earl:OutcomeValue</code>)
			of the assertion.</li>
	</ul>
	<p>The following example contains the description of one test
		assertion.</p>
	<pre class="example" id="test-assertion-example">:TCR1-Assertion-SomeServer a earl:Assertion;
	earl:subject :AwesomeLDP;
	earl:test ldpt:CommonResource-GetResource;
	earl:assertedBy :AwesomeLDP;
	earl:mode:  earl:automatic;
	earl:result [
		a earl:OutcomeValue ;
		dcterms:date "2014-07-06T09:30:10";
		earl:outcome earl:passed
    ].

:AwesomeLDP a doap:Project, earl:TestSubject, earl:Software, earl:Assertor;
	doap:name "Awesome LDP";
	doap:description "Awesome LDP implementation";
	doap:developer    [ a	foaf:Person ;
						foaf:mbox  "[email protected]" ;
						foaf:name  "Dope Developer"
                      ];
	doap:homepage	&lt;http://example.org/AwesomeLDP&gt;;
	doap:programming-language "JavaScript".</pre> 
            
    </section>
    </section>
	</section>
	</section>

	<section class="appendix">
	<h2>Change history</h2>
	<ul>
		<li>2014-08-25 Added section on submitting results and fixed references (SS)</li>	
		<li>2014-07-08 Various grammar fixes and removed todos (SS)</li>
		<li>2014-07-07 Further alignment with current testing approach and namespaces (SS)</li>
		<li>2014-06-22 Brought inline with separate automated testsuite hosted on GitHub (SS)</li>
		<li>2014-04-09 Updated according to Last Call Working Draft from 11 March 2014 (FS and RGC)</li>
		<li>2013-08-27 Updated according to Last Call Working Draft from 30 July 2013 (RGC)</li>
		<li>2013-06-03 Updated to use ReSpec (RGC)</li>
		<li>2013-06-03 Implemented <a
			href="http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0153.html">changes
				suggested by Eric Prud'hommeaux</a> (RGC)
		</li>
	</ul>
	</section>

</body>
</html>
\ No newline at end of file
--- a/tests/reports/ldp-earl-manifest.jsonld	Mon Aug 25 16:45:08 2014 -0400
+++ b/tests/reports/ldp-earl-manifest.jsonld	Mon Aug 25 16:47:16 2014 -0400
@@ -4,174 +4,209 @@
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-acceptposthdr",
-    "td:includesText" : "LDP servers that support POST MUST include an Accept-Post response header on HTTP OPTIONS responses, listing post document media type(s) supported by the server."
-  }, {
-    "@id" : "_:t100",
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-get-jsonld",
+    "td:includesText" : "LDP servers SHOULD offer a application/ld+json representation of the requested LDP-RS [JSON-LD]. "
+  }, {
+    "@id" : "_:t102",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-failed",
     "td:includesText" : "LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP. LDP servers expose these application-specific constraints as described in section 4.2.1 General."
   }, {
-    "@id" : "_:t103",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-get-options",
-    "td:includesText" : "LDP servers MUST support the HTTP response headers defined in section 4.2.8 HTTP OPTIONS. "
-  }, {
-    "@id" : "_:t107",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-pubclireqs",
-    "td:includesText" : "LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with rel='describedby' [RFC5988] to all responses to requests which fail due to violation of those constraints."
-  }, {
-    "@id" : "_:t108",
+    "@id" : "_:t105",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-nordfcontainertypes",
+    "td:includesText" : "LDPC representations SHOULD NOT use RDF container types rdf:Bag, rdf:Seq or rdf:List."
+  }, {
+    "@id" : "_:t106",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-head-must",
+    "td:includesText" : "LDP servers MUST support the HTTP HEAD method. "
+  }, {
+    "@id" : "_:t112",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-reusevocab",
+    "td:includesText" : "LDP-RSs SHOULD reuse existing vocabularies instead of creating their own duplicate vocabulary terms. In addition to this general rule, some specific cases are covered by other conformance rules."
+  }, {
+    "@id" : "_:t113",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-failed",
+    "td:includesText" : "LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP. LDP servers expose these application-specific constraints as described in section 4.2.1 General."
+  }, {
+    "@id" : "_:t114",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
+  }, {
+    "@id" : "_:t115",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-created201",
+    "td:includesText" : "If the resource was created successfully, LDP servers MUST respond with status code 201 (Created) and the Location header set to the new resource’s URL. Clients shall not expect any representation in the response entity body on a 201 (Created) response."
+  }, {
+    "@id" : "_:t116",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-options-linkmetahdr",
     "td:includesText" : "When responding to requests whose request-URI is a LDP-NR with anassociated LDP-RS, a LDPC server must provide the same HTTP Link responseheader as is required in the create response"
   }, {
-    "@id" : "_:t111",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-simpleupdate",
-    "td:includesText" : "LDP servers SHOULD allow clients to update resources without requiring detailed knowledge of server-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs."
-  }, {
-    "@id" : "_:t114",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-binary",
-    "td:includesText" : "LDP servers may host a mixture of LDP-RSs and LDP-NRs. For example, it is common for LDP servers to need to host binary or text resources that do not have useful RDF representations."
-  }, {
     "@id" : "_:t117",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpic-indirectmbr",
-    "td:includesText" : "LDP Indirect Containers MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is ldp:insertedContentRelation, and whose object ICR describes how the member-derived-URI in the container's membership triples is chosen."
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-patch-req",
+    "td:includesText" : "LDP servers are RECOMMENDED to support HTTP PATCH as the preferred method for updating an LDPC's empty-container triples. "
   }, {
     "@id" : "_:t118",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP clients SHOULD use the HTTP If-Match header and HTTP ETags to ensure it isn’t modifying a resource that has changed since the client last retrieved its representation. LDP servers SHOULD require the HTTP If-Match header and HTTP ETags to detect collisions."
-  }, {
-    "@id" : "_:t119",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createrdf",
-    "td:includesText" : "LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource can be thought of as an RDF named graph [rdf11-concepts]. If any model cannot be honored, the server MUST fail the request."
+    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
   }, {
     "@id" : "_:t12",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-created201",
-    "td:includesText" : "If the resource was created successfully, LDP servers MUST respond with status code 201 (Created) and the Location header set to the new resource’s URL. Clients shall not expect any representation in the response entity body on a 201 (Created) response."
-  }, {
-    "@id" : "_:t126",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-dontreuseuris",
-    "td:includesText" : "LDP servers that allow member creation via POST SHOULD NOT re-use URIs."
-  }, {
-    "@id" : "_:t128",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-failed",
-    "td:includesText" : "LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP. LDP servers expose these application-specific constraints as described in section 4.2.1 General."
-  }, {
-    "@id" : "_:t13",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-linktypehdr",
-    "td:includesText" : "LDP servers exposing LDPRs MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#Resource, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPR's HTTP Request-URI."
-  }, {
-    "@id" : "_:t133",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-get-turtle",
-    "td:includesText" : "LDP servers must provide a text/turtle representation of the requested LDP-RS whenever HTTP content negotiation does not force another outcome [turtle]. In other words, if the server receives a GET request whose Request-URI identifies a LDP-RS, and either text/turtle has the highest relative quality factor (q= value) in the Accept request header or that header is absent, then an LDP server has to respond with Turtle."
-  }, {
-    "@id" : "_:t134",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-acceptposthdr",
     "td:includesText" : "LDP servers that support POST MUST include an Accept-Post response header on HTTP OPTIONS responses, listing post document media type(s) supported by the server."
   }, {
+    "@id" : "_:t121",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
+    "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
+  }, {
+    "@id" : "_:t128",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-binary",
+    "td:includesText" : "LDP servers may host a mixture of LDP-RSs and LDP-NRs. For example, it is common for LDP servers to need to host binary or text resources that do not have useful RDF representations."
+  }, {
+    "@id" : "_:t129",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-rdf",
+    "td:includesText" : "LDP servers MUST provide an RDF representation for LDP-RSs. The HTTP Request-URI of the LDP-RS is typically the subject of most triples in the response."
+  }, {
+    "@id" : "_:t13",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-put-mbrprops",
+    "td:includesText" : "LDP servers SHOULD NOT allow HTTP PUT to update an LDPC’s containment triples; if the server receives such a request, it SHOULD respond with a 409 (Conflict) status code."
+  }, {
+    "@id" : "_:t130",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-http",
+    "td:includesText" : "LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]."
+  }, {
+    "@id" : "_:t131",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP clients SHOULD use the HTTP If-Match header and HTTP ETags to ensure it isn’t modifying a resource that has changed since the client last retrieved its representation. LDP servers SHOULD require the HTTP If-Match header and HTTP ETags to detect collisions."
+  }, {
+    "@id" : "_:t132",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createrdf",
+    "td:includesText" : "LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource can be thought of as an RDF named graph [rdf11-concepts]. If any model cannot be honored, the server MUST fail the request."
+  }, {
+    "@id" : "_:t133",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-isldpr",
+    "td:includesText" : "Each Linked Data Platform Container MUST also be a conforming Linked Data Platform RDF Source."
+  }, {
+    "@id" : "_:t134",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createrdf",
+    "td:includesText" : "LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource can be thought of as an RDF named graph [rdf11-concepts]. If any model cannot be honored, the server MUST fail the request."
+  }, {
+    "@id" : "_:t137",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
+    "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
+  }, {
+    "@id" : "_:t138",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-failed",
+    "td:includesText" : "LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP. LDP servers expose these application-specific constraints as described in section 4.2.1 General."
+  }, {
     "@id" : "_:t139",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-head-must",
+    "td:includesText" : "LDP servers MUST support the HTTP HEAD method. "
+  }, {
+    "@id" : "_:t140",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-servermanagedprops",
+    "td:includesText" : "If an otherwise valid HTTP PUT request is received that attempts to change properties the server does not allow clients to modify, LDP servers MUST respond with a 4xx range status code (typically 409 Conflict)"
+  }, {
+    "@id" : "_:t141",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-acceptposthdr",
+    "td:includesText" : "LDP servers that support POST MUST include an Accept-Post response header on HTTP OPTIONS responses, listing post document media type(s) supported by the server."
+  }, {
+    "@id" : "_:t144",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP clients SHOULD use the HTTP If-Match header and HTTP ETags to ensure it isn’t modifying a resource that has changed since the client last retrieved its representation. LDP servers SHOULD require the HTTP If-Match header and HTTP ETags to detect collisions."
+  }, {
+    "@id" : "_:t147",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-dontreuseuris",
     "td:includesText" : "LDP servers that allow member creation via POST SHOULD NOT re-use URIs."
   }, {
-    "@id" : "_:t14",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
-  }, {
-    "@id" : "_:t140",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-get-options",
-    "td:includesText" : "LDP servers MUST support the HTTP response headers defined in section 4.2.8 HTTP OPTIONS. "
-  }, {
-    "@id" : "_:t141",
+    "@id" : "_:t148",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
     "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
   }, {
-    "@id" : "_:t142",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createbins",
-    "td:includesText" : "LDP servers may accept an HTTP POST of non-RDF representations (LDP-NRs) for creation of any kind of resource, for example binary resources."
-  }, {
-    "@id" : "_:t147",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-mincontraints",
-    "td:includesText" : "LDP servers SHOULD allow clients to create new resources without requiring detailed knowledge of application-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs. LDP servers expose these application-specific constraints as described in section 4.2.1 General."
-  }, {
-    "@id" : "_:t148",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-slug",
-    "td:includesText" : "LDP servers MAY allow clients to suggest the URI for a resource created through POST, using the HTTP Slug header as defined in [RFC5023]. LDP adds no new requirements to this usage, so its presence functions as a client hint to the server providing a desired string to be incorporated into the server's final choice of resource URI."
-  }, {
     "@id" : "_:t149",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-http",
-    "td:includesText" : "LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]."
-  }, {
-    "@id" : "_:t15",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-get-options",
     "td:includesText" : "LDP servers MUST support the HTTP response headers defined in section 4.2.8 HTTP OPTIONS. "
   }, {
@@ -179,260 +214,211 @@
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-head-must",
-    "td:includesText" : "LDP servers MUST support the HTTP HEAD method. "
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-defbaseuri",
+    "td:includesText" : "LDP servers MUST assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource."
   }, {
     "@id" : "_:t151",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createrdf",
-    "td:includesText" : "LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource can be thought of as an RDF named graph [rdf11-concepts]. If any model cannot be honored, the server MUST fail the request."
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
+  }, {
+    "@id" : "_:t152",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createbins",
+    "td:includesText" : "LDP servers may accept an HTTP POST of non-RDF representations (LDP-NRs) for creation of any kind of resource, for example binary resources."
+  }, {
+    "@id" : "_:t153",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-linktypehdr",
+    "td:includesText" : "LDP servers exposing LDPRs MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#Resource, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPR's HTTP Request-URI."
+  }, {
+    "@id" : "_:t154",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-mincontraints",
+    "td:includesText" : "LDP servers SHOULD allow clients to create new resources without requiring detailed knowledge of application-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs. LDP servers expose these application-specific constraints as described in section 4.2.1 General."
+  }, {
+    "@id" : "_:t155",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-rdftype",
+    "td:includesText" : "The representation of a LDP-RS MAY have an rdf:type of ldp:RDFSource for Linked Data Platform RDF Source."
   }, {
     "@id" : "_:t156",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-contenttype",
-    "td:includesText" : "LDP servers SHOULD use the Content-Type request header to determine the representation format when the request has an entity body."
-  }, {
-    "@id" : "_:t161",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-jsonld",
-    "td:includesText" : "LDP servers SHOULD accept a request entity body with a request header of Content-Type with value of application/ld+json [JSON-LD]."
-  }, {
-    "@id" : "_:t162",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpnr-type",
-    "td:includesText" : "LDP servers exposing an LDP Non-RDF Source may advertise this by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#NonRDFSource, and a link relation type of type (that is, rel='type') in responses to requests made to the LDP-NR's HTTP Request-URI."
-  }, {
-    "@id" : "_:t163",
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-create",
+    "td:includesText" : "LDP servers MAY choose to allow the creation of new resources using HTTP PUT."
+  }, {
+    "@id" : "_:t159",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-head-must",
+    "td:includesText" : "LDP servers MUST support the HTTP HEAD method. "
+  }, {
+    "@id" : "_:t167",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-turtle",
+    "td:includesText" : "LDP servers MUST accept a request entity body with a request header of Content-Type with value of text/turtle [turtle]."
+  }, {
+    "@id" : "_:t168",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createdmbr-contains",
+    "td:includesText" : "When a successful HTTP POST request to an LDPC results in the creation of an LDPR, a containment triple MUST be added to the state of LDPC."
+  }, {
+    "@id" : "_:t169",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-patch-acceptpatch",
+    "td:includesText" : "LDP servers that support PATCH MUST include an Accept-Patch HTTP response header [RFC5789] on HTTP OPTIONS requests, listing patch document media type(s) supported by the server. "
+  }, {
+    "@id" : "_:t17",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-get-options",
+    "td:includesText" : "LDP servers MUST support the HTTP response headers defined in section 4.2.8 HTTP OPTIONS. "
+  }, {
+    "@id" : "_:t172",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-failed",
+    "td:includesText" : "If an otherwise valid HTTP PUT request is received that contains properties the server chooses not to persist, e.g. unknown content, LDP servers MUST respond with an appropriate 4xx range status code [HTTP11]."
+  }, {
+    "@id" : "_:t173",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-defbaseuri",
+    "td:includesText" : "LDP servers MUST assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource."
+  }, {
+    "@id" : "_:t18",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-dontreuseuris",
     "td:includesText" : "LDP servers that allow member creation via POST SHOULD NOT re-use URIs."
   }, {
-    "@id" : "_:t164",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-failed",
-    "td:includesText" : "LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP. LDP servers expose these application-specific constraints as described in section 4.2.1 General."
-  }, {
-    "@id" : "_:t171",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-patch-req",
-    "td:includesText" : "LDP servers are RECOMMENDED to support HTTP PATCH as the preferred method for updating an LDPC's empty-container triples. "
-  }, {
-    "@id" : "_:t175",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP clients SHOULD use the HTTP If-Match header and HTTP ETags to ensure it isn’t modifying a resource that has changed since the client last retrieved its representation. LDP servers SHOULD require the HTTP If-Match header and HTTP ETags to detect collisions."
-  }, {
-    "@id" : "_:t176",
+    "@id" : "_:t180",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-mincontraints",
+    "td:includesText" : "LDP servers SHOULD allow clients to create new resources without requiring detailed knowledge of application-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs. LDP servers expose these application-specific constraints as described in section 4.2.1 General."
+  }, {
+    "@id" : "_:t181",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpbc-are-ldpcs",
+    "td:includesText" : "Each LDP Basic Container MUST also be a conforming LDP Container in section 5.2 Container along with the following restrictions in this section."
+  }, {
+    "@id" : "_:t184",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-reusevocab",
+    "td:includesText" : "LDP-RSs SHOULD reuse existing vocabularies instead of creating their own duplicate vocabulary terms. In addition to this general rule, some specific cases are covered by other conformance rules."
+  }, {
+    "@id" : "_:t189",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-pubclireqs",
     "td:includesText" : "LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with rel='describedby' [RFC5988] to all responses to requests which fail due to violation of those constraints."
   }, {
-    "@id" : "_:t179",
+    "@id" : "_:t190",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
+  }, {
+    "@id" : "_:t195",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-contenttype",
+    "td:includesText" : "LDP servers SHOULD use the Content-Type request header to determine the representation format when the request has an entity body."
+  }, {
+    "@id" : "_:t197",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createdmbr-contains",
+    "td:includesText" : "When a successful HTTP POST request to an LDPC results in the creation of an LDPR, a containment triple MUST be added to the state of LDPC."
+  }, {
+    "@id" : "_:t198",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-rdf",
     "td:includesText" : "LDP servers MUST provide an RDF representation for LDP-RSs. The HTTP Request-URI of the LDP-RS is typically the subject of most triples in the response."
   }, {
-    "@id" : "_:t18",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-rdftype",
-    "td:includesText" : "The representation of a LDP-RS MAY have an rdf:type of ldp:RDFSource for Linked Data Platform RDF Source."
-  }, {
-    "@id" : "_:t180",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-http",
-    "td:includesText" : "LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]."
-  }, {
-    "@id" : "_:t183",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-noinferencing",
-    "td:includesText" : "LDP servers MUST NOT require LDP clients to implement inferencing in order to recognize the subset of content defined by LDP. Other specifications built on top of LDP may require clients to implement inferencing [rdf11-concepts]. The practical implication is that all content defined by LDP must be explicitly represented, unless noted otherwise within this document."
-  }, {
-    "@id" : "_:t19",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
-    "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
-  }, {
-    "@id" : "_:t190",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-rdf",
-    "td:includesText" : "LDP servers MUST provide an RDF representation for LDP-RSs. The HTTP Request-URI of the LDP-RS is typically the subject of most triples in the response."
-  }, {
-    "@id" : "_:t191",
+    "@id" : "_:t199",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpdc-del-contremovesmbrtriple",
     "td:includesText" : "When an LDPR identified by the object of a membership triple which was originally created by the LDP-DC is deleted, the LDPC server MUST also remove the corresponding membership triple."
   }, {
-    "@id" : "_:t192",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-serverassignuri",
-    "td:includesText" : "LDP servers SHOULD assign the URI for the resource to be created using server application specific rules in the absence of a client hint."
-  }, {
-    "@id" : "_:t193",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-dontreuseuris",
-    "td:includesText" : "LDP servers that allow member creation via POST SHOULD NOT re-use URIs."
-  }, {
-    "@id" : "_:t194",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-rdf",
-    "td:includesText" : "LDP servers MUST provide an RDF representation for LDP-RSs. The HTTP Request-URI of the LDP-RS is typically the subject of most triples in the response."
-  }, {
-    "@id" : "_:t195",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
-  }, {
-    "@id" : "_:t198",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-linktypehdr",
-    "td:includesText" : "LDP servers exposing LDPRs MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#Resource, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPR's HTTP Request-URI."
-  }, {
     "@id" : "_:t2",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-http",
-    "td:includesText" : "LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]."
-  }, {
-    "@id" : "_:t20",
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-simpleupdate",
+    "td:includesText" : "LDP servers SHOULD allow clients to update resources without requiring detailed knowledge of server-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs."
+  }, {
+    "@id" : "_:t200",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-get-turtle",
+    "td:includesText" : "LDP servers must provide a text/turtle representation of the requested LDP-RS whenever HTTP content negotiation does not force another outcome [turtle]. In other words, if the server receives a GET request whose Request-URI identifies a LDP-RS, and either text/turtle has the highest relative quality factor (q= value) in the Accept request header or that header is absent, then an LDP server has to respond with Turtle."
+  }, {
+    "@id" : "_:t21",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
     "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
   }, {
-    "@id" : "_:t201",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-create",
-    "td:includesText" : "LDP servers MAY choose to allow the creation of new resources using HTTP PUT."
-  }, {
-    "@id" : "_:t204",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-http",
-    "td:includesText" : "LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]."
-  }, {
-    "@id" : "_:t205",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-del-contremovesconttriple",
-    "td:includesText" : "When an LDPR identified by the object of a containment triple is deleted, the LDPC server MUST also remove the LDPR from the containing LDPC by removing the corresponding containment triple."
-  }, {
-    "@id" : "_:t206",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-linktypehdr",
-    "td:includesText" : "LDP servers exposing LDPRs MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#Resource, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPR's HTTP Request-URI."
-  }, {
-    "@id" : "_:t207",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createdmbr-contains",
-    "td:includesText" : "When a successful HTTP POST request to an LDPC results in the creation of an LDPR, a containment triple MUST be added to the state of LDPC."
-  }, {
-    "@id" : "_:t208",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-atleast1rdftype",
-    "td:includesText" : "LDP-RSs representations SHOULD have at least one rdf:type set explicitly. This makes the representations much more useful to client applications that don’t support inferencing."
-  }, {
-    "@id" : "_:t209",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-put-create",
-    "td:includesText" : "LDP servers that allow LDPR creation via PUT SHOULD NOT re-use URIs. For RDF representations (LDP-RSs),the created resource can be thought of as an RDF named graph [rdf11-concepts]."
-  }, {
-    "@id" : "_:t21",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-linktypehdr",
-    "td:includesText" : "LDP servers exposing LDPCs MUST advertise their LDP support by exposing a HTTP Link header with a target URI matching the type of container (see below) the server supports, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPC's HTTP Request-URI."
-  }, {
     "@id" : "_:t210",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-put-mbrprops",
-    "td:includesText" : "LDP servers SHOULD NOT allow HTTP PUT to update an LDPC’s containment triples; if the server receives such a request, it SHOULD respond with a 409 (Conflict) status code."
-  }, {
-    "@id" : "_:t211",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-patch-acceptpatch",
-    "td:includesText" : "LDP servers that support PATCH MUST include an Accept-Patch HTTP response header [RFC5789] on HTTP OPTIONS requests, listing patch document media type(s) supported by the server. "
-  }, {
-    "@id" : "_:t214",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createrdf",
-    "td:includesText" : "LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource can be thought of as an RDF named graph [rdf11-concepts]. If any model cannot be honored, the server MUST fail the request."
-  }, {
-    "@id" : "_:t217",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
-  }, {
-    "@id" : "_:t218",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpnr-are-ldpr",
-    "td:includesText" : "Each LDP Non-RDF Source must also be a conforming LDP Resource. LDP Non-RDF Sources may not be able to fully express their state using RDF."
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpdc-mbrpred",
+    "td:includesText" : "LDP Direct Containers SHOULD use the ldp:member predicate as an LDPC's membership predicate if there is no obvious predicate from an application vocabulary to use."
+  }, {
+    "@id" : "_:t215",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-dontreuseuris",
+    "td:includesText" : "LDP servers that allow member creation via POST SHOULD NOT re-use URIs."
+  }, {
+    "@id" : "_:t216",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-servermanagedprops",
+    "td:includesText" : "If an otherwise valid HTTP PUT request is received that attempts to change properties the server does not allow clients to modify, LDP servers MUST respond with a 4xx range status code (typically 409 Conflict)"
   }, {
     "@id" : "_:t22",
     "rdf:type" : {
@@ -441,776 +427,762 @@
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-pubclireqs",
     "td:includesText" : "LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with rel='describedby' [RFC5988] to all responses to requests which fail due to violation of those constraints."
   }, {
-    "@id" : "_:t221",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-patch-acceptpatch",
-    "td:includesText" : "LDP servers that support PATCH MUST include an Accept-Patch HTTP response header [RFC5789] on HTTP OPTIONS requests, listing patch document media type(s) supported by the server. "
-  }, {
-    "@id" : "_:t222",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpdc-containtriples",
-    "td:includesText" : "Each LDP Direct Container representation must contain exactly one triple whose subject is the LDPC URI, and whose predicate is either ldp:hasMemberRelation or ldp:isMemberOfRelation. The object of the triple is constrained by other sections, such as ldp:hasMemberRelation or ldp:isMemberOfRelation, based on the membership triple pattern used by the container."
-  }, {
-    "@id" : "_:t223",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-servermanagedprops",
-    "td:includesText" : "If an otherwise valid HTTP PUT request is received that attempts to change properties the server does not allow clients to modify, LDP servers MUST respond with a 4xx range status code (typically 409 Conflict)"
-  }, {
-    "@id" : "_:t224",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-reusevocabsuchas",
-    "td:includesText" : "LDP-RSs predicates SHOULD use standard vocabularies such as Dublin Core [DC-TERMS], RDF [rdf11-concepts] and RDF Schema [rdf-schema], whenever possible."
-  }, {
-    "@id" : "_:t227",
+    "@id" : "_:t225",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-put-create",
+    "td:includesText" : "LDP servers that allow LDPR creation via PUT SHOULD NOT re-use URIs. For RDF representations (LDP-RSs),the created resource can be thought of as an RDF named graph [rdf11-concepts]."
+  }, {
+    "@id" : "_:t226",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-put-mbrprops",
+    "td:includesText" : "LDP servers SHOULD NOT allow HTTP PUT to update an LDPC’s containment triples; if the server receives such a request, it SHOULD respond with a 409 (Conflict) status code."
+  }, {
+    "@id" : "_:t228",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
+  }, {
+    "@id" : "_:t23",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
+  }, {
+    "@id" : "_:t231",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-pubclireqs",
+    "td:includesText" : "LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with rel='describedby' [RFC5988] to all responses to requests which fail due to violation of those constraints."
+  }, {
+    "@id" : "_:t232",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-put-create",
+    "td:includesText" : "LDP servers that allow LDPR creation via PUT SHOULD NOT re-use URIs. For RDF representations (LDP-RSs),the created resource can be thought of as an RDF named graph [rdf11-concepts]."
+  }, {
+    "@id" : "_:t24",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpnr-are-ldpr",
+    "td:includesText" : "Each LDP Non-RDF Source must also be a conforming LDP Resource. LDP Non-RDF Sources may not be able to fully express their state using RDF."
+  }, {
+    "@id" : "_:t243",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-rdftype",
     "td:includesText" : "The representation of a LDP-RS MAY have an rdf:type of ldp:RDFSource for Linked Data Platform RDF Source."
   }, {
-    "@id" : "_:t228",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-reusevocab",
-    "td:includesText" : "LDP-RSs SHOULD reuse existing vocabularies instead of creating their own duplicate vocabulary terms. In addition to this general rule, some specific cases are covered by other conformance rules."
-  }, {
-    "@id" : "_:t23",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-contenttype",
-    "td:includesText" : "LDP servers SHOULD use the Content-Type request header to determine the representation format when the request has an entity body."
-  }, {
-    "@id" : "_:t234",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-linktypehdr",
-    "td:includesText" : "LDP servers exposing LDPCs MUST advertise their LDP support by exposing a HTTP Link header with a target URI matching the type of container (see below) the server supports, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPC's HTTP Request-URI."
-  }, {
-    "@id" : "_:t235",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-reusevocab",
-    "td:includesText" : "LDP-RSs SHOULD reuse existing vocabularies instead of creating their own duplicate vocabulary terms. In addition to this general rule, some specific cases are covered by other conformance rules."
-  }, {
-    "@id" : "_:t236",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-replaceall",
-    "td:includesText" : "If a HTTP PUT is accepted on an existing resource, LDP servers MUST replace the entire persistent state of the identified resource with the entity representation in the body of the request."
-  }, {
-    "@id" : "_:t237",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createbins",
-    "td:includesText" : "LDP servers may accept an HTTP POST of non-RDF representations (LDP-NRs) for creation of any kind of resource, for example binary resources."
-  }, {
-    "@id" : "_:t238",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
-    "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
-  }, {
-    "@id" : "_:t24",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-get-jsonld",
-    "td:includesText" : "LDP servers SHOULD offer a application/ld+json representation of the requested LDP-RS [JSON-LD]. "
-  }, {
-    "@id" : "_:t241",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-del-contremovesconttriple",
-    "td:includesText" : "When an LDPR identified by the object of a containment triple is deleted, the LDPC server MUST also remove the LDPR from the containing LDPC by removing the corresponding containment triple."
-  }, {
-    "@id" : "_:t243",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-must",
-    "td:includesText" : "LDP servers MUST support the HTTP OPTIONS method. "
-  }, {
-    "@id" : "_:t244",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-failed",
-    "td:includesText" : "LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP. LDP servers expose these application-specific constraints as described in section 4.2.1 General."
-  }, {
-    "@id" : "_:t245",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-get-turtle",
-    "td:includesText" : "LDP servers must provide a text/turtle representation of the requested LDP-RS whenever HTTP content negotiation does not force another outcome [turtle]. In other words, if the server receives a GET request whose Request-URI identifies a LDP-RS, and either text/turtle has the highest relative quality factor (q= value) in the Accept request header or that header is absent, then an LDP server has to respond with Turtle."
-  }, {
-    "@id" : "_:t251",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
-  }, {
-    "@id" : "_:t252",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-get-turtle",
-    "td:includesText" : "LDP servers must provide a text/turtle representation of the requested LDP-RS whenever HTTP content negotiation does not force another outcome [turtle]. In other words, if the server receives a GET request whose Request-URI identifies a LDP-RS, and either text/turtle has the highest relative quality factor (q= value) in the Accept request header or that header is absent, then an LDP server has to respond with Turtle."
-  }, {
-    "@id" : "_:t259",
+    "@id" : "_:t246",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-del-contremovescontres",
+    "td:includesText" : "When a contained LDPR is deleted, and the LDPC server created anassociated LDP-RS (see the LDPC POST section), the LDPC server must alsodelete the associated LDP-RS it created."
+  }, {
+    "@id" : "_:t247",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-defbaseuri",
     "td:includesText" : "LDP servers MUST assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource."
   }, {
-    "@id" : "_:t262",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-turtle",
-    "td:includesText" : "LDP servers MUST accept a request entity body with a request header of Content-Type with value of text/turtle [turtle]."
-  }, {
-    "@id" : "_:t263",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-prefer",
-    "td:includesText" : "LDP servers SHOULD respect all of a client's LDP-defined hints, for example which subsets of LDP-defined state the client is interested in processing, to influence the set of triples returned in representations of an LDPC, particularly for large LDPCs. See also [LDP-PAGING]."
-  }, {
-    "@id" : "_:t266",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-get-jsonld",
-    "td:includesText" : "LDP servers SHOULD offer a application/ld+json representation of the requested LDP-RS [JSON-LD]. "
-  }, {
-    "@id" : "_:t267",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-must",
-    "td:includesText" : "LDP servers MUST support the HTTP OPTIONS method. "
-  }, {
-    "@id" : "_:t273",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
-  }, {
-    "@id" : "_:t278",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createrdf",
-    "td:includesText" : "LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource can be thought of as an RDF named graph [rdf11-concepts]. If any model cannot be honored, the server MUST fail the request."
-  }, {
-    "@id" : "_:t283",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-created201",
-    "td:includesText" : "If the resource was created successfully, LDP servers MUST respond with status code 201 (Created) and the Location header set to the new resource’s URL. Clients shall not expect any representation in the response entity body on a 201 (Created) response."
-  }, {
-    "@id" : "_:t284",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-servermanagedprops",
-    "td:includesText" : "LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP."
-  }, {
-    "@id" : "_:t289",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
-  }, {
-    "@id" : "_:t291",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-atleast1rdftype",
-    "td:includesText" : "LDP-RSs representations SHOULD have at least one rdf:type set explicitly. This makes the representations much more useful to client applications that don’t support inferencing."
-  }, {
-    "@id" : "_:t294",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-typecontainer",
-    "td:includesText" : "The representation of a LDPC MAY have an rdf:type of ldp:Container for Linked Data Platform Container. Non-normative note: LDPCs might have additional types, like any LDP-RS. "
-  }, {
-    "@id" : "_:t295",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createdmbr-contains",
-    "td:includesText" : "When a successful HTTP POST request to an LDPC results in the creation of an LDPR, a containment triple MUST be added to the state of LDPC."
-  }, {
-    "@id" : "_:t296",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-simpleupdate",
-    "td:includesText" : "LDP servers SHOULD allow clients to update resources without requiring detailed knowledge of server-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs."
-  }, {
-    "@id" : "_:t297",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-servermanagedprops",
-    "td:includesText" : "LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP."
-  }, {
-    "@id" : "_:t3",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-must",
-    "td:includesText" : "LDP servers MUST support the HTTP OPTIONS method. "
-  }, {
-    "@id" : "_:t30",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-patch-acceptpatch",
-    "td:includesText" : "LDP servers that support PATCH MUST include an Accept-Patch HTTP response header [RFC5789] on HTTP OPTIONS requests, listing patch document media type(s) supported by the server. "
-  }, {
-    "@id" : "_:t300",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-servermanagedprops",
-    "td:includesText" : "If an otherwise valid HTTP PUT request is received that attempts to change properties the server does not allow clients to modify, LDP servers MUST respond with a 4xx range status code (typically 409 Conflict)"
-  }, {
-    "@id" : "_:t303",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-failed",
-    "td:includesText" : "If an otherwise valid HTTP PUT request is received that contains properties the server chooses not to persist, e.g. unknown content, LDP servers MUST respond with an appropriate 4xx range status code [HTTP11]."
-  }, {
-    "@id" : "_:t309",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-servermanagedprops",
-    "td:includesText" : "LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP."
-  }, {
-    "@id" : "_:t318",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-get-options",
-    "td:includesText" : "LDP servers MUST support the HTTP response headers defined in section 4.2.8 HTTP OPTIONS. "
-  }, {
-    "@id" : "_:t319",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-turtle",
-    "td:includesText" : "LDP servers MUST accept a request entity body with a request header of Content-Type with value of text/turtle [turtle]."
-  }, {
-    "@id" : "_:t320",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-head-must",
-    "td:includesText" : "LDP servers MUST support the HTTP HEAD method. "
-  }, {
-    "@id" : "_:t321",
+    "@id" : "_:t248",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-rdfnullrel",
+    "td:includesText" : "In RDF representations, LDP 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."
+  }, {
+    "@id" : "_:t249",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-replaceall",
     "td:includesText" : "If a HTTP PUT is accepted on an existing resource, LDP servers MUST replace the entire persistent state of the identified resource with the entity representation in the body of the request."
   }, {
-    "@id" : "_:t322",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-get-options",
-    "td:includesText" : "LDP servers MUST support the HTTP response headers defined in section 4.2.8 HTTP OPTIONS. "
-  }, {
-    "@id" : "_:t323",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-http",
-    "td:includesText" : "LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]."
-  }, {
-    "@id" : "_:t33",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-linktypehdr",
-    "td:includesText" : "LDP servers exposing LDPCs MUST advertise their LDP support by exposing a HTTP Link header with a target URI matching the type of container (see below) the server supports, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPC's HTTP Request-URI."
-  }, {
-    "@id" : "_:t331",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-replaceall",
-    "td:includesText" : "If a HTTP PUT is accepted on an existing resource, LDP servers MUST replace the entire persistent state of the identified resource with the entity representation in the body of the request."
-  }, {
-    "@id" : "_:t334",
+    "@id" : "_:t25",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-contenttype",
     "td:includesText" : "LDP servers SHOULD use the Content-Type request header to determine the representation format when the request has an entity body."
   }, {
-    "@id" : "_:t335",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-mincontraints",
-    "td:includesText" : "LDP servers SHOULD allow clients to create new resources without requiring detailed knowledge of application-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs. LDP servers expose these application-specific constraints as described in section 4.2.1 General."
-  }, {
-    "@id" : "_:t336",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
-  }, {
-    "@id" : "_:t337",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-allow",
-    "td:includesText" : "LDP servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow. "
-  }, {
-    "@id" : "_:t34",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-rdftype",
-    "td:includesText" : "The representation of a LDP-RS MAY have an rdf:type of ldp:RDFSource for Linked Data Platform RDF Source."
-  }, {
-    "@id" : "_:t343",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-simpleupdate",
-    "td:includesText" : "LDP servers SHOULD allow clients to update resources without requiring detailed knowledge of server-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs."
-  }, {
-    "@id" : "_:t344",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
-    "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
-  }, {
-    "@id" : "_:t345",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-http",
-    "td:includesText" : "LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]."
-  }, {
-    "@id" : "_:t348",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-head-must",
-    "td:includesText" : "LDP servers MUST support the HTTP HEAD method. "
-  }, {
-    "@id" : "_:t349",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-get-jsonld",
-    "td:includesText" : "LDP servers SHOULD offer a application/ld+json representation of the requested LDP-RS [JSON-LD]. "
-  }, {
-    "@id" : "_:t35",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
-  }, {
-    "@id" : "_:t350",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
-  }, {
-    "@id" : "_:t352",
+    "@id" : "_:t250",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createbins",
+    "td:includesText" : "LDP servers may accept an HTTP POST of non-RDF representations (LDP-NRs) for creation of any kind of resource, for example binary resources."
+  }, {
+    "@id" : "_:t253",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-servermanagedprops",
+    "td:includesText" : "LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP."
+  }, {
+    "@id" : "_:t256",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-del-contremovesconttriple",
+    "td:includesText" : "When an LDPR identified by the object of a containment triple is deleted, the LDPC server MUST also remove the LDPR from the containing LDPC by removing the corresponding containment triple."
+  }, {
+    "@id" : "_:t264",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-del-contremovesconttriple",
+    "td:includesText" : "When an LDPR identified by the object of a containment triple is deleted, the LDPC server MUST also remove the LDPR from the containing LDPC by removing the corresponding containment triple."
+  }, {
+    "@id" : "_:t265",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-failed",
+    "td:includesText" : "LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP. LDP servers expose these application-specific constraints as described in section 4.2.1 General."
+  }, {
+    "@id" : "_:t266",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-get-turtle",
+    "td:includesText" : "LDP servers must provide a text/turtle representation of the requested LDP-RS whenever HTTP content negotiation does not force another outcome [turtle]. In other words, if the server receives a GET request whose Request-URI identifies a LDP-RS, and either text/turtle has the highest relative quality factor (q= value) in the Accept request header or that header is absent, then an LDP server has to respond with Turtle."
+  }, {
+    "@id" : "_:t269",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
     "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
   }, {
-    "@id" : "_:t353",
+    "@id" : "_:t270",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpdc-are-ldpcs",
+    "td:includesText" : "Each LDP Direct Container MUST also be a conforming LDP Container in section 5.2 Container along the following restrictions."
+  }, {
+    "@id" : "_:t271",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-put-create",
+    "td:includesText" : "LDP servers that allow LDPR creation via PUT SHOULD NOT re-use URIs. For RDF representations (LDP-RSs),the created resource can be thought of as an RDF named graph [rdf11-concepts]."
+  }, {
+    "@id" : "_:t274",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-http",
+    "td:includesText" : "LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]."
+  }, {
+    "@id" : "_:t275",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createrdf",
+    "td:includesText" : "LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource can be thought of as an RDF named graph [rdf11-concepts]. If any model cannot be honored, the server MUST fail the request."
+  }, {
+    "@id" : "_:t280",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-jsonld",
+    "td:includesText" : "LDP servers SHOULD accept a request entity body with a request header of Content-Type with value of application/ld+json [JSON-LD]."
+  }, {
+    "@id" : "_:t281",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-turtle",
+    "td:includesText" : "LDP servers MUST accept a request entity body with a request header of Content-Type with value of text/turtle [turtle]."
+  }, {
+    "@id" : "_:t282",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-replaceall",
+    "td:includesText" : "If a HTTP PUT is accepted on an existing resource, LDP servers MUST replace the entire persistent state of the identified resource with the entity representation in the body of the request."
+  }, {
+    "@id" : "_:t283",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-prefer",
+    "td:includesText" : "LDP servers SHOULD respect all of a client's LDP-defined hints, for example which subsets of LDP-defined state the client is interested in processing, to influence the set of triples returned in representations of an LDPC, particularly for large LDPCs. See also [LDP-PAGING]."
+  }, {
+    "@id" : "_:t286",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-rdf",
+    "td:includesText" : "LDP servers MUST provide an RDF representation for LDP-RSs. The HTTP Request-URI of the LDP-RS is typically the subject of most triples in the response."
+  }, {
+    "@id" : "_:t288",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
+  }, {
+    "@id" : "_:t289",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-pubclireqs",
+    "td:includesText" : "LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with rel='describedby' [RFC5988] to all responses to requests which fail due to violation of those constraints."
+  }, {
+    "@id" : "_:t292",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-linktypehdr",
+    "td:includesText" : "LDP servers exposing LDPRs MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#Resource, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPR's HTTP Request-URI."
+  }, {
+    "@id" : "_:t293",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP clients SHOULD use the HTTP If-Match header and HTTP ETags to ensure it isn’t modifying a resource that has changed since the client last retrieved its representation. LDP servers SHOULD require the HTTP If-Match header and HTTP ETags to detect collisions."
+  }, {
+    "@id" : "_:t294",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
     "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
   }, {
-    "@id" : "_:t354",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpdc-mbrpred",
-    "td:includesText" : "LDP Direct Containers SHOULD use the ldp:member predicate as an LDPC's membership predicate if there is no obvious predicate from an application vocabulary to use."
-  }, {
-    "@id" : "_:t355",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createrdf",
-    "td:includesText" : "LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource can be thought of as an RDF named graph [rdf11-concepts]. If any model cannot be honored, the server MUST fail the request."
-  }, {
-    "@id" : "_:t356",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-pubclireqs",
-    "td:includesText" : "LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with rel='describedby' [RFC5988] to all responses to requests which fail due to violation of those constraints."
-  }, {
-    "@id" : "_:t358",
+    "@id" : "_:t299",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-linktypehdr",
+    "td:includesText" : "LDP servers exposing LDPCs MUST advertise their LDP support by exposing a HTTP Link header with a target URI matching the type of container (see below) the server supports, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPC's HTTP Request-URI."
+  }, {
+    "@id" : "_:t30",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-isldpr",
+    "td:includesText" : "Each Linked Data Platform Container MUST also be a conforming Linked Data Platform RDF Source."
+  }, {
+    "@id" : "_:t305",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-reusevocabsuchas",
+    "td:includesText" : "LDP-RSs predicates SHOULD use standard vocabularies such as Dublin Core [DC-TERMS], RDF [rdf11-concepts] and RDF Schema [rdf-schema], whenever possible."
+  }, {
+    "@id" : "_:t306",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-atleast1rdftype",
     "td:includesText" : "LDP-RSs representations SHOULD have at least one rdf:type set explicitly. This makes the representations much more useful to client applications that don’t support inferencing."
   }, {
-    "@id" : "_:t36",
+    "@id" : "_:t309",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP clients SHOULD use the HTTP If-Match header and HTTP ETags to ensure it isn’t modifying a resource that has changed since the client last retrieved its representation. LDP servers SHOULD require the HTTP If-Match header and HTTP ETags to detect collisions."
+  }, {
+    "@id" : "_:t313",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createdmbr-contains",
+    "td:includesText" : "When a successful HTTP POST request to an LDPC results in the creation of an LDPR, a containment triple MUST be added to the state of LDPC."
+  }, {
+    "@id" : "_:t314",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-simpleupdate",
+    "td:includesText" : "LDP servers SHOULD allow clients to update resources without requiring detailed knowledge of server-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs."
+  }, {
+    "@id" : "_:t315",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-jsonld",
+    "td:includesText" : "LDP servers SHOULD accept a request entity body with a request header of Content-Type with value of application/ld+json [JSON-LD]."
+  }, {
+    "@id" : "_:t316",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-servermanagedprops",
+    "td:includesText" : "LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP."
+  }, {
+    "@id" : "_:t320",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-rdfnullrel",
+    "td:includesText" : "In RDF representations, LDP 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."
+  }, {
+    "@id" : "_:t323",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-get-options",
+    "td:includesText" : "LDP servers MUST support the HTTP response headers defined in section 4.2.8 HTTP OPTIONS. "
+  }, {
+    "@id" : "_:t328",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-allow",
+    "td:includesText" : "LDP servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow. "
+  }, {
+    "@id" : "_:t329",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-get-options",
+    "td:includesText" : "LDP servers MUST support the HTTP response headers defined in section 4.2.8 HTTP OPTIONS. "
+  }, {
+    "@id" : "_:t330",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-replaceall",
+    "td:includesText" : "If a HTTP PUT is accepted on an existing resource, LDP servers MUST replace the entire persistent state of the identified resource with the entity representation in the body of the request."
+  }, {
+    "@id" : "_:t333",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP clients SHOULD use the HTTP If-Match header and HTTP ETags to ensure it isn’t modifying a resource that has changed since the client last retrieved its representation. LDP servers SHOULD require the HTTP If-Match header and HTTP ETags to detect collisions."
+  }, {
+    "@id" : "_:t334",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-head-must",
+    "td:includesText" : "LDP servers MUST support the HTTP HEAD method. "
+  }, {
+    "@id" : "_:t335",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-get-options",
+    "td:includesText" : "LDP servers MUST support the HTTP response headers defined in section 4.2.8 HTTP OPTIONS. "
+  }, {
+    "@id" : "_:t339",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-prefer",
+    "td:includesText" : "LDP servers SHOULD respect all of a client's LDP-defined hints, for example which subsets of LDP-defined state the client is interested in processing, to influence the set of triples returned in representations of an LDPC, particularly for large LDPCs. See also [LDP-PAGING]."
+  }, {
+    "@id" : "_:t340",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-patch-acceptpatch",
     "td:includesText" : "LDP servers that support PATCH MUST include an Accept-Patch HTTP response header [RFC5789] on HTTP OPTIONS requests, listing patch document media type(s) supported by the server. "
   }, {
-    "@id" : "_:t364",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-put-create",
-    "td:includesText" : "LDP servers that allow LDPR creation via PUT SHOULD NOT re-use URIs. For RDF representations (LDP-RSs),the created resource can be thought of as an RDF named graph [rdf11-concepts]."
+    "@id" : "_:t350",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-serverassignuri",
+    "td:includesText" : "LDP servers SHOULD assign the URI for the resource to be created using server application specific rules in the absence of a client hint."
+  }, {
+    "@id" : "_:t351",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-reusevocab",
+    "td:includesText" : "LDP-RSs SHOULD reuse existing vocabularies instead of creating their own duplicate vocabulary terms. In addition to this general rule, some specific cases are covered by other conformance rules."
+  }, {
+    "@id" : "_:t352",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpdc-containtriples",
+    "td:includesText" : "Each LDP Direct Container representation must contain exactly one triple whose subject is the LDPC URI, and whose predicate is either ldp:hasMemberRelation or ldp:isMemberOfRelation. The object of the triple is constrained by other sections, such as ldp:hasMemberRelation or ldp:isMemberOfRelation, based on the membership triple pattern used by the container."
+  }, {
+    "@id" : "_:t355",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-pubclireqs",
+    "td:includesText" : "LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with rel='describedby' [RFC5988] to all responses to requests which fail due to violation of those constraints."
+  }, {
+    "@id" : "_:t356",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-http",
+    "td:includesText" : "LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]."
+  }, {
+    "@id" : "_:t360",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-head-must",
+    "td:includesText" : "LDP servers MUST support the HTTP HEAD method. "
+  }, {
+    "@id" : "_:t361",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-get-turtle",
+    "td:includesText" : "LDP servers must provide a text/turtle representation of the requested LDP-RS whenever HTTP content negotiation does not force another outcome [turtle]. In other words, if the server receives a GET request whose Request-URI identifies a LDP-RS, and either text/turtle has the highest relative quality factor (q= value) in the Accept request header or that header is absent, then an LDP server has to respond with Turtle."
+  }, {
+    "@id" : "_:t363",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
+    "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
+  }, {
+    "@id" : "_:t365",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
   }, {
     "@id" : "_:t366",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-get-jsonld",
+    "td:includesText" : "LDP servers SHOULD offer a application/ld+json representation of the requested LDP-RS [JSON-LD]. "
+  }, {
+    "@id" : "_:t37",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-patch-acceptpatch",
+    "td:includesText" : "LDP servers that support PATCH MUST include an Accept-Patch HTTP response header [RFC5789] on HTTP OPTIONS requests, listing patch document media type(s) supported by the server. "
+  }, {
+    "@id" : "_:t370",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
+  }, {
+    "@id" : "_:t373",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-atleast1rdftype",
+    "td:includesText" : "LDP-RSs representations SHOULD have at least one rdf:type set explicitly. This makes the representations much more useful to client applications that don’t support inferencing."
+  }, {
+    "@id" : "_:t377",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-patch-req",
+    "td:includesText" : "LDP servers are RECOMMENDED to support HTTP PATCH as the preferred method for updating an LDPC's empty-container triples. "
+  }, {
+    "@id" : "_:t379",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpnr-type",
+    "td:includesText" : "LDP servers exposing an LDP Non-RDF Source may advertise this by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#NonRDFSource, and a link relation type of type (that is, rel='type') in responses to requests made to the LDP-NR's HTTP Request-URI."
+  }, {
+    "@id" : "_:t38",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-pubclireqs",
+    "td:includesText" : "LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with rel='describedby' [RFC5988] to all responses to requests which fail due to violation of those constraints."
+  }, {
+    "@id" : "_:t380",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpic-post-indirectmbrrel",
     "td:includesText" : "LDPCs whose ldp:insertedContentRelation triple has an object other than ldp:MemberSubject and that create new resources MUST add a triple to the container whose subject is the container's URI, whose predicate is ldp:contains, and whose object is the newly created resource's URI (which will be different from the member-derived URI in this case). This ldp:contains triple can be the only link from the container to the newly created resource in certain cases."
   }, {
-    "@id" : "_:t370",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-mincontraints",
-    "td:includesText" : "LDP servers SHOULD allow clients to create new resources without requiring detailed knowledge of application-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs. LDP servers expose these application-specific constraints as described in section 4.2.1 General."
-  }, {
-    "@id" : "_:t373",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-rdfnullrel",
-    "td:includesText" : "In RDF representations, LDP 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."
-  }, {
-    "@id" : "_:t374",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-prefer",
-    "td:includesText" : "LDP servers SHOULD respect all of a client's LDP-defined hints, for example which subsets of LDP-defined state the client is interested in processing, to influence the set of triples returned in representations of an LDPC, particularly for large LDPCs. See also [LDP-PAGING]."
-  }, {
-    "@id" : "_:t376",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-head-must",
-    "td:includesText" : "LDP servers MUST support the HTTP HEAD method. "
-  }, {
-    "@id" : "_:t377",
+    "@id" : "_:t381",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-turtle",
+    "td:includesText" : "LDP servers MUST accept a request entity body with a request header of Content-Type with value of text/turtle [turtle]."
+  }, {
+    "@id" : "_:t388",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpdc-post-createdmbr-member",
+    "td:includesText" : "When a successful HTTP POST request to an LDPC results in the creation of an LDPR, the LDPC MUST update its membership triples to reflect that addition, and the resulting membership triple MUST be consistent with any LDP-defined predicates it exposes."
+  }, {
+    "@id" : "_:t39",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-noinferencing",
+    "td:includesText" : "LDP servers MUST NOT require LDP clients to implement inferencing in order to recognize the subset of content defined by LDP. Other specifications built on top of LDP may require clients to implement inferencing [rdf11-concepts]. The practical implication is that all content defined by LDP must be explicitly represented, unless noted otherwise within this document."
+  }, {
+    "@id" : "_:t391",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-put-mbrprops",
+    "td:includesText" : "LDP servers SHOULD NOT allow HTTP PUT to update an LDPC’s containment triples; if the server receives such a request, it SHOULD respond with a 409 (Conflict) status code."
+  }, {
+    "@id" : "_:t393",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createbinlinkmetahdr",
     "td:includesText" : "Upon successful creation of an LDP-NR (HTTP status code of 201-Created and URI indicated by Location response header), LDP servers may create an associated LDP-RS to contain data about the newly created LDP-NR. If a LDP server creates this associated LDP-RS it must indicate its location on the HTTP response using the HTTP Link response header with link relation describedby and href to be the URI of the associated LDP-RS resource."
   }, {
-    "@id" : "_:t380",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-http",
-    "td:includesText" : "LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]."
-  }, {
-    "@id" : "_:t381",
+    "@id" : "_:t394",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-get-jsonld",
+    "td:includesText" : "LDP servers SHOULD offer a application/ld+json representation of the requested LDP-RS [JSON-LD]. "
+  }, {
+    "@id" : "_:t396",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-are-ldpr",
+    "td:includesText" : "Each LDP RDF Source MUST also be a conforming LDP Resource as defined in section 4.2 Resource, along with the restrictions in this section."
+  }, {
+    "@id" : "_:t401",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-servermanagedprops",
+    "td:includesText" : "LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP."
+  }, {
+    "@id" : "_:t402",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-typecontainer",
+    "td:includesText" : "The representation of a LDPC MAY have an rdf:type of ldp:Container for Linked Data Platform Container. Non-normative note: LDPCs might have additional types, like any LDP-RS. "
+  }, {
+    "@id" : "_:t406",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-allow",
+    "td:includesText" : "LDP servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow. "
+  }, {
+    "@id" : "_:t407",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-atleast1rdftype",
+    "td:includesText" : "LDP-RSs representations SHOULD have at least one rdf:type set explicitly. This makes the representations much more useful to client applications that don’t support inferencing."
+  }, {
+    "@id" : "_:t408",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-get-turtle",
+    "td:includesText" : "LDP servers must provide a text/turtle representation of the requested LDP-RS whenever HTTP content negotiation does not force another outcome [turtle]. In other words, if the server receives a GET request whose Request-URI identifies a LDP-RS, and either text/turtle has the highest relative quality factor (q= value) in the Accept request header or that header is absent, then an LDP server has to respond with Turtle."
+  }, {
+    "@id" : "_:t409",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
+    "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
+  }, {
+    "@id" : "_:t410",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-linktypehdr",
+    "td:includesText" : "LDP servers exposing LDPRs MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#Resource, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPR's HTTP Request-URI."
+  }, {
+    "@id" : "_:t411",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-rdf",
+    "td:includesText" : "LDP servers MUST provide an RDF representation for LDP-RSs. The HTTP Request-URI of the LDP-RS is typically the subject of most triples in the response."
+  }, {
+    "@id" : "_:t412",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-dontreuseuris",
+    "td:includesText" : "LDP servers that allow member creation via POST SHOULD NOT re-use URIs."
+  }, {
+    "@id" : "_:t414",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
     "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
   }, {
-    "@id" : "_:t386",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-create",
-    "td:includesText" : "LDP servers MAY choose to allow the creation of new resources using HTTP PUT."
-  }, {
-    "@id" : "_:t389",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-turtle",
-    "td:includesText" : "LDP servers MUST accept a request entity body with a request header of Content-Type with value of text/turtle [turtle]."
-  }, {
-    "@id" : "_:t39",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-http",
-    "td:includesText" : "LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]."
-  }, {
-    "@id" : "_:t390",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-rdfnullrel",
-    "td:includesText" : "In RDF representations, LDP 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."
-  }, {
-    "@id" : "_:t391",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-noinferencing",
-    "td:includesText" : "LDP servers MUST NOT require LDP clients to implement inferencing in order to recognize the subset of content defined by LDP. Other specifications built on top of LDP may require clients to implement inferencing [rdf11-concepts]. The practical implication is that all content defined by LDP must be explicitly represented, unless noted otherwise within this document."
-  }, {
-    "@id" : "_:t392",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-patch-req",
-    "td:includesText" : "LDP servers are RECOMMENDED to support HTTP PATCH as the preferred method for updating an LDPC's empty-container triples. "
-  }, {
-    "@id" : "_:t395",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-reusevocabsuchas",
-    "td:includesText" : "LDP-RSs predicates SHOULD use standard vocabularies such as Dublin Core [DC-TERMS], RDF [rdf11-concepts] and RDF Schema [rdf-schema], whenever possible."
-  }, {
-    "@id" : "_:t397",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-serverassignuri",
-    "td:includesText" : "LDP servers SHOULD assign the URI for the resource to be created using server application specific rules in the absence of a client hint."
-  }, {
-    "@id" : "_:t40",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP clients SHOULD use the HTTP If-Match header and HTTP ETags to ensure it isn’t modifying a resource that has changed since the client last retrieved its representation. LDP servers SHOULD require the HTTP If-Match header and HTTP ETags to detect collisions."
-  }, {
-    "@id" : "_:t401",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-del-contremovesconttriple",
-    "td:includesText" : "When an LDPR identified by the object of a containment triple is deleted, the LDPC server MUST also remove the LDPR from the containing LDPC by removing the corresponding containment triple."
-  }, {
-    "@id" : "_:t402",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP clients SHOULD use the HTTP If-Match header and HTTP ETags to ensure it isn’t modifying a resource that has changed since the client last retrieved its representation. LDP servers SHOULD require the HTTP If-Match header and HTTP ETags to detect collisions."
-  }, {
-    "@id" : "_:t403",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-nordfcontainertypes",
-    "td:includesText" : "LDPC representations SHOULD NOT use RDF container types rdf:Bag, rdf:Seq or rdf:List."
-  }, {
-    "@id" : "_:t404",
+    "@id" : "_:t415",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-slug",
+    "td:includesText" : "LDP servers MAY allow clients to suggest the URI for a resource created through POST, using the HTTP Slug header as defined in [RFC5023]. LDP adds no new requirements to this usage, so its presence functions as a client hint to the server providing a desired string to be incorporated into the server's final choice of resource URI."
+  }, {
+    "@id" : "_:t418",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-replaceall",
+    "td:includesText" : "If a HTTP PUT is accepted on an existing resource, LDP servers MUST replace the entire persistent state of the identified resource with the entity representation in the body of the request."
+  }, {
+    "@id" : "_:t419",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-defbaseuri",
     "td:includesText" : "LDP servers MUST assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource."
   }, {
-    "@id" : "_:t405",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-pubclireqs",
-    "td:includesText" : "LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with rel='describedby' [RFC5988] to all responses to requests which fail due to violation of those constraints."
-  }, {
-    "@id" : "_:t406",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-jsonld",
-    "td:includesText" : "LDP servers SHOULD accept a request entity body with a request header of Content-Type with value of application/ld+json [JSON-LD]."
-  }, {
-    "@id" : "_:t41",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-nordfcontainertypes",
-    "td:includesText" : "LDPC representations SHOULD NOT use RDF container types rdf:Bag, rdf:Seq or rdf:List."
-  }, {
-    "@id" : "_:t413",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpdc-indirectmbr-basic",
-    "td:includesText" : "LDP Direct Containers MUST behave as if they have a (LDPC URI, ldp:insertedContentRelation , ldp:MemberSubject) triple, but LDP imposes no requirement to materialize such a triple in the LDP-DC representation."
-  }, {
-    "@id" : "_:t418",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-acceptposthdr",
-    "td:includesText" : "LDP servers that support POST MUST include an Accept-Post response header on HTTP OPTIONS responses, listing post document media type(s) supported by the server."
-  }, {
     "@id" : "_:t42",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-create",
-    "td:includesText" : "LDP servers MAY choose to allow the creation of new resources using HTTP PUT."
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-linktypehdr",
+    "td:includesText" : "LDP servers exposing LDPCs MUST advertise their LDP support by exposing a HTTP Link header with a target URI matching the type of container (see below) the server supports, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPC's HTTP Request-URI."
+  }, {
+    "@id" : "_:t420",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-typecontainer",
+    "td:includesText" : "The representation of a LDPC MAY have an rdf:type of ldp:Container for Linked Data Platform Container. Non-normative note: LDPCs might have additional types, like any LDP-RS. "
   }, {
     "@id" : "_:t422",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-rdfnullrel",
-    "td:includesText" : "In RDF representations, LDP 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."
-  }, {
-    "@id" : "_:t423",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-linktypehdr",
     "td:includesText" : "LDP servers exposing LDPRs MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#Resource, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPR's HTTP Request-URI."
   }, {
-    "@id" : "_:t428",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-dontreuseuris",
-    "td:includesText" : "LDP servers that allow member creation via POST SHOULD NOT re-use URIs."
-  }, {
-    "@id" : "_:t429",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-http",
-    "td:includesText" : "LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]."
+    "@id" : "_:t426",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-are-ldpr",
+    "td:includesText" : "Each LDP RDF Source MUST also be a conforming LDP Resource as defined in section 4.2 Resource, along with the restrictions in this section."
+  }, {
+    "@id" : "_:t43",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createrdf",
+    "td:includesText" : "LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource can be thought of as an RDF named graph [rdf11-concepts]. If any model cannot be honored, the server MUST fail the request."
   }, {
     "@id" : "_:t430",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-failed",
-    "td:includesText" : "If an otherwise valid HTTP PUT request is received that contains properties the server chooses not to persist, e.g. unknown content, LDP servers MUST respond with an appropriate 4xx range status code [HTTP11]."
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-atleast1rdftype",
+    "td:includesText" : "LDP-RSs representations SHOULD have at least one rdf:type set explicitly. This makes the representations much more useful to client applications that don’t support inferencing."
+  }, {
+    "@id" : "_:t431",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-patch-acceptpatch",
+    "td:includesText" : "LDP servers that support PATCH MUST include an Accept-Patch HTTP response header [RFC5789] on HTTP OPTIONS requests, listing patch document media type(s) supported by the server. "
   }, {
     "@id" : "_:t432",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-servermanagedprops",
-    "td:includesText" : "If an otherwise valid HTTP PUT request is received that attempts to change properties the server does not allow clients to modify, LDP servers MUST respond with a 4xx range status code (typically 409 Conflict)"
+    "td:includesText" : "LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP."
   }, {
     "@id" : "_:t433",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-patch-acceptpatch",
-    "td:includesText" : "LDP servers that support PATCH MUST include an Accept-Patch HTTP response header [RFC5789] on HTTP OPTIONS requests, listing patch document media type(s) supported by the server. "
-  }, {
-    "@id" : "_:t435",
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-nordfcontainertypes",
+    "td:includesText" : "LDPC representations SHOULD NOT use RDF container types rdf:Bag, rdf:Seq or rdf:List."
+  }, {
+    "@id" : "_:t436",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-nordfcontainertypes",
+    "td:includesText" : "LDPC representations SHOULD NOT use RDF container types rdf:Bag, rdf:Seq or rdf:List."
+  }, {
+    "@id" : "_:t437",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-linktypehdr",
+    "td:includesText" : "LDP servers exposing LDPRs MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#Resource, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPR's HTTP Request-URI."
+  }, {
+    "@id" : "_:t438",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-defbaseuri",
     "td:includesText" : "LDP servers MUST assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource."
   }, {
-    "@id" : "_:t437",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createdmbr-contains",
-    "td:includesText" : "When a successful HTTP POST request to an LDPC results in the creation of an LDPR, a containment triple MUST be added to the state of LDPC."
-  }, {
-    "@id" : "_:t438",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
-    "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
-  }, {
     "@id" : "_:t439",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-get-turtle",
-    "td:includesText" : "LDP servers must provide a text/turtle representation of the requested LDP-RS whenever HTTP content negotiation does not force another outcome [turtle]. In other words, if the server receives a GET request whose Request-URI identifies a LDP-RS, and either text/turtle has the highest relative quality factor (q= value) in the Accept request header or that header is absent, then an LDP server has to respond with Turtle."
-  }, {
-    "@id" : "_:t440",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpic-are-ldpcs",
-    "td:includesText" : "Each LDP Indirect Container MUST also be a conforming LDP Direct Container in section 5.4 Direct along the following restrictions."
-  }, {
-    "@id" : "_:t441",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-atleast1rdftype",
-    "td:includesText" : "LDP-RSs representations SHOULD have at least one rdf:type set explicitly. This makes the representations much more useful to client applications that don’t support inferencing."
-  }, {
-    "@id" : "_:t443",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
-    "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
-  }, {
-    "@id" : "_:t444",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-patch-req",
-    "td:includesText" : "LDP servers are RECOMMENDED to support HTTP PATCH as the preferred method for updating an LDPC's empty-container triples. "
-  }, {
-    "@id" : "_:t447",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-reusevocab",
     "td:includesText" : "LDP-RSs SHOULD reuse existing vocabularies instead of creating their own duplicate vocabulary terms. In addition to this general rule, some specific cases are covered by other conformance rules."
   }, {
+    "@id" : "_:t44",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-patch-acceptpatch",
+    "td:includesText" : "LDP servers that support PATCH MUST include an Accept-Patch HTTP response header [RFC5789] on HTTP OPTIONS requests, listing patch document media type(s) supported by the server. "
+  }, {
+    "@id" : "_:t442",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-dontreuseuris",
+    "td:includesText" : "LDP servers that allow member creation via POST SHOULD NOT re-use URIs."
+  }, {
+    "@id" : "_:t444",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
+  }, {
+    "@id" : "_:t446",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-are-ldpr",
+    "td:includesText" : "Each LDP RDF Source MUST also be a conforming LDP Resource as defined in section 4.2 Resource, along with the restrictions in this section."
+  }, {
+    "@id" : "_:t447",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-failed",
+    "td:includesText" : "If an otherwise valid HTTP PUT request is received that contains properties the server chooses not to persist, e.g. unknown content, LDP servers MUST respond with an appropriate 4xx range status code [HTTP11]."
+  }, {
     "@id" : "_:t448",
     "rdf:type" : {
       "@id" : "td:Excerpt"
@@ -1218,194 +1190,166 @@
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-must",
     "td:includesText" : "LDP servers MUST support the HTTP OPTIONS method. "
   }, {
-    "@id" : "_:t449",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
-  }, {
-    "@id" : "_:t45",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
-    "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
-  }, {
     "@id" : "_:t450",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-servermanagedprops",
-    "td:includesText" : "LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP."
-  }, {
-    "@id" : "_:t452",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-must",
-    "td:includesText" : "LDP servers MUST support the HTTP OPTIONS method. "
-  }, {
-    "@id" : "_:t455",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-allow",
-    "td:includesText" : "LDP servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow. "
-  }, {
-    "@id" : "_:t456",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-jsonld",
-    "td:includesText" : "LDP servers SHOULD accept a request entity body with a request header of Content-Type with value of application/ld+json [JSON-LD]."
-  }, {
-    "@id" : "_:t457",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-defbaseuri",
-    "td:includesText" : "LDP servers MUST assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource."
-  }, {
-    "@id" : "_:t459",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-dontreuseuris",
-    "td:includesText" : "LDP servers that allow member creation via POST SHOULD NOT re-use URIs."
-  }, {
-    "@id" : "_:t46",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createrdf",
-    "td:includesText" : "LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource can be thought of as an RDF named graph [rdf11-concepts]. If any model cannot be honored, the server MUST fail the request."
-  }, {
-    "@id" : "_:t460",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-noinferencing",
-    "td:includesText" : "LDP servers MUST NOT require LDP clients to implement inferencing in order to recognize the subset of content defined by LDP. Other specifications built on top of LDP may require clients to implement inferencing [rdf11-concepts]. The practical implication is that all content defined by LDP must be explicitly represented, unless noted otherwise within this document."
-  }, {
-    "@id" : "_:t461",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP clients SHOULD use the HTTP If-Match header and HTTP ETags to ensure it isn’t modifying a resource that has changed since the client last retrieved its representation. LDP servers SHOULD require the HTTP If-Match header and HTTP ETags to detect collisions."
-  }, {
-    "@id" : "_:t462",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-failed",
-    "td:includesText" : "If an otherwise valid HTTP PUT request is received that contains properties the server chooses not to persist, e.g. unknown content, LDP servers MUST respond with an appropriate 4xx range status code [HTTP11]."
-  }, {
-    "@id" : "_:t463",
+    "td:includesText" : "If an otherwise valid HTTP PUT request is received that attempts to change properties the server does not allow clients to modify, LDP servers MUST respond with a 4xx range status code (typically 409 Conflict)"
+  }, {
+    "@id" : "_:t451",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-get-must",
     "td:includesText" : "LDP servers MUST support the HTTP GET Method for LDPRs"
   }, {
-    "@id" : "_:t464",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-slug",
-    "td:includesText" : "LDP servers MAY allow clients to suggest the URI for a resource created through POST, using the HTTP Slug header as defined in [RFC5023]. LDP adds no new requirements to this usage, so its presence functions as a client hint to the server providing a desired string to be incorporated into the server's final choice of resource URI."
-  }, {
-    "@id" : "_:t465",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-linktypehdr",
-    "td:includesText" : "LDP servers exposing LDPRs MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#Resource, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPR's HTTP Request-URI."
-  }, {
-    "@id" : "_:t466",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-rdf",
-    "td:includesText" : "LDP servers MUST provide an RDF representation for LDP-RSs. The HTTP Request-URI of the LDP-RS is typically the subject of most triples in the response."
-  }, {
-    "@id" : "_:t467",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-http",
-    "td:includesText" : "LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]."
-  }, {
-    "@id" : "_:t468",
+    "@id" : "_:t452",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-linktypehdr",
+    "td:includesText" : "LDP servers exposing LDPCs MUST advertise their LDP support by exposing a HTTP Link header with a target URI matching the type of container (see below) the server supports, and a link relation type of type (that is, rel='type') in all responses to requests made to the LDPC's HTTP Request-URI."
+  }, {
+    "@id" : "_:t453",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
     "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
   }, {
-    "@id" : "_:t469",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-servermanagedprops",
-    "td:includesText" : "If an otherwise valid HTTP PUT request is received that attempts to change properties the server does not allow clients to modify, LDP servers MUST respond with a 4xx range status code (typically 409 Conflict)"
-  }, {
-    "@id" : "_:t47",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-created201",
-    "td:includesText" : "If the resource was created successfully, LDP servers MUST respond with status code 201 (Created) and the Location header set to the new resource’s URL. Clients shall not expect any representation in the response entity body on a 201 (Created) response."
-  }, {
-    "@id" : "_:t471",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-noinferencing",
-    "td:includesText" : "LDP servers MUST NOT require LDP clients to implement inferencing in order to recognize the subset of content defined by LDP. Other specifications built on top of LDP may require clients to implement inferencing [rdf11-concepts]. The practical implication is that all content defined by LDP must be explicitly represented, unless noted otherwise within this document."
-  }, {
-    "@id" : "_:t472",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-put-create",
-    "td:includesText" : "LDP servers that allow LDPR creation via PUT SHOULD NOT re-use URIs. For RDF representations (LDP-RSs),the created resource can be thought of as an RDF named graph [rdf11-concepts]."
-  }, {
-    "@id" : "_:t473",
+    "@id" : "_:t454",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
+  }, {
+    "@id" : "_:t456",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpic-are-ldpcs",
+    "td:includesText" : "Each LDP Indirect Container MUST also be a conforming LDP Direct Container in section 5.4 Direct along the following restrictions."
+  }, {
+    "@id" : "_:t457",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-prefer",
+    "td:includesText" : "LDP servers SHOULD respect all of a client's LDP-defined hints, for example which subsets of LDP-defined state the client is interested in processing, to influence the set of triples returned in representations of an LDPC, particularly for large LDPCs. See also [LDP-PAGING]."
+  }, {
+    "@id" : "_:t458",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createrdf",
+    "td:includesText" : "LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource can be thought of as an RDF named graph [rdf11-concepts]. If any model cannot be honored, the server MUST fail the request."
+  }, {
+    "@id" : "_:t459",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpdc-containres",
     "td:includesText" : "Each LDP Direct Container representation MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is the ldp:membershipResource, and whose object is the LDPC's membership-constant-URI. Commonly the LDPC's URI is the membership-constant-URI, but LDP does not require this."
   }, {
-    "@id" : "_:t474",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-defbaseuri",
-    "td:includesText" : "LDP servers MUST assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource."
-  }, {
-    "@id" : "_:t475",
+    "@id" : "_:t460",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-http",
+    "td:includesText" : "LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]."
+  }, {
+    "@id" : "_:t461",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-are-ldpr",
+    "td:includesText" : "Each LDP RDF Source MUST also be a conforming LDP Resource as defined in section 4.2 Resource, along with the restrictions in this section."
+  }, {
+    "@id" : "_:t462",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-dontreuseuris",
+    "td:includesText" : "LDP servers that allow member creation via POST SHOULD NOT re-use URIs."
+  }, {
+    "@id" : "_:t463",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-reusevocabsuchas",
+    "td:includesText" : "LDP-RSs predicates SHOULD use standard vocabularies such as Dublin Core [DC-TERMS], RDF [rdf11-concepts] and RDF Schema [rdf-schema], whenever possible."
+  }, {
+    "@id" : "_:t466",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-contenttype",
+    "td:includesText" : "LDP servers SHOULD use the Content-Type request header to determine the representation format when the request has an entity body."
+  }, {
+    "@id" : "_:t467",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-serverassignuri",
+    "td:includesText" : "LDP servers SHOULD assign the URI for the resource to be created using server application specific rules in the absence of a client hint."
+  }, {
+    "@id" : "_:t468",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
+    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
+  }, {
+    "@id" : "_:t469",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-del-contremovesconttriple",
+    "td:includesText" : "When an LDPR identified by the object of a containment triple is deleted, the LDPC server MUST also remove the LDPR from the containing LDPC by removing the corresponding containment triple."
+  }, {
+    "@id" : "_:t472",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-must",
+    "td:includesText" : "LDP servers MUST support the HTTP OPTIONS method. "
+  }, {
+    "@id" : "_:t473",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-pubclireqs",
     "td:includesText" : "LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with rel='describedby' [RFC5988] to all responses to requests which fail due to violation of those constraints."
   }, {
+    "@id" : "_:t474",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-create",
+    "td:includesText" : "LDP servers MAY choose to allow the creation of new resources using HTTP PUT."
+  }, {
+    "@id" : "_:t475",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
+    "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
+  }, {
     "@id" : "_:t476",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-must",
+    "td:includesText" : "LDP servers MUST support the HTTP OPTIONS method. "
   }, {
     "@id" : "_:t477",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-reusevocabsuchas",
-    "td:includesText" : "LDP-RSs predicates SHOULD use standard vocabularies such as Dublin Core [DC-TERMS], RDF [rdf11-concepts] and RDF Schema [rdf-schema], whenever possible."
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
+    "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
   }, {
     "@id" : "_:t478",
     "rdf:type" : {
@@ -1418,195 +1362,279 @@
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-del-contremovescontres",
-    "td:includesText" : "When a contained LDPR is deleted, and the LDPC server created anassociated LDP-RS (see the LDPC POST section), the LDPC server must alsodelete the associated LDP-RS it created."
-  }, {
-    "@id" : "_:t48",
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-slug",
+    "td:includesText" : "LDP servers MAY allow clients to suggest the URI for a resource created through POST, using the HTTP Slug header as defined in [RFC5023]. LDP adds no new requirements to this usage, so its presence functions as a client hint to the server providing a desired string to be incorporated into the server's final choice of resource URI."
+  }, {
+    "@id" : "_:t481",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-created201",
+    "td:includesText" : "If the resource was created successfully, LDP servers MUST respond with status code 201 (Created) and the Location header set to the new resource’s URL. Clients shall not expect any representation in the response entity body on a 201 (Created) response."
+  }, {
+    "@id" : "_:t482",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-must",
+    "td:includesText" : "LDP servers MUST support the HTTP OPTIONS method. "
+  }, {
+    "@id" : "_:t483",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-noinferencing",
+    "td:includesText" : "LDP servers MUST NOT require LDP clients to implement inferencing in order to recognize the subset of content defined by LDP. Other specifications built on top of LDP may require clients to implement inferencing [rdf11-concepts]. The practical implication is that all content defined by LDP must be explicitly represented, unless noted otherwise within this document."
+  }, {
+    "@id" : "_:t484",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-rdftype",
     "td:includesText" : "The representation of a LDP-RS MAY have an rdf:type of ldp:RDFSource for Linked Data Platform RDF Source."
   }, {
-    "@id" : "_:t481",
+    "@id" : "_:t486",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-rdfnullrel",
+    "td:includesText" : "In RDF representations, LDP 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."
+  }, {
+    "@id" : "_:t487",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-reusevocabsuchas",
+    "td:includesText" : "LDP-RSs predicates SHOULD use standard vocabularies such as Dublin Core [DC-TERMS], RDF [rdf11-concepts] and RDF Schema [rdf-schema], whenever possible."
+  }, {
+    "@id" : "_:t488",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-defbaseuri",
+    "td:includesText" : "LDP servers MUST assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource."
+  }, {
+    "@id" : "_:t489",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-failed",
+    "td:includesText" : "If an otherwise valid HTTP PUT request is received that contains properties the server chooses not to persist, e.g. unknown content, LDP servers MUST respond with an appropriate 4xx range status code [HTTP11]."
+  }, {
+    "@id" : "_:t5",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-must",
+    "td:includesText" : "LDP servers MUST support the HTTP OPTIONS method. "
+  }, {
+    "@id" : "_:t50",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-create",
+    "td:includesText" : "LDP servers MAY choose to allow the creation of new resources using HTTP PUT."
+  }, {
+    "@id" : "_:t51",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpdc-indirectmbr-basic",
+    "td:includesText" : "LDP Direct Containers MUST behave as if they have a (LDPC URI, ldp:insertedContentRelation , ldp:MemberSubject) triple, but LDP imposes no requirement to materialize such a triple in the LDP-DC representation."
+  }, {
+    "@id" : "_:t54",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-createrdf",
+    "td:includesText" : "LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource can be thought of as an RDF named graph [rdf11-concepts]. If any model cannot be honored, the server MUST fail the request."
+  }, {
+    "@id" : "_:t57",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-acceptposthdr",
+    "td:includesText" : "LDP servers that support POST MUST include an Accept-Post response header on HTTP OPTIONS responses, listing post document media type(s) supported by the server."
+  }, {
+    "@id" : "_:t58",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-created201",
+    "td:includesText" : "If the resource was created successfully, LDP servers MUST respond with status code 201 (Created) and the Location header set to the new resource’s URL. Clients shall not expect any representation in the response entity body on a 201 (Created) response."
+  }, {
+    "@id" : "_:t6",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-allow",
+    "td:includesText" : "LDP servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow. "
+  }, {
+    "@id" : "_:t60",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-rdftype",
+    "td:includesText" : "The representation of a LDP-RS MAY have an rdf:type of ldp:RDFSource for Linked Data Platform RDF Source."
+  }, {
+    "@id" : "_:t61",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-reusevocabsuchas",
+    "td:includesText" : "LDP-RSs predicates SHOULD use standard vocabularies such as Dublin Core [DC-TERMS], RDF [rdf11-concepts] and RDF Schema [rdf-schema], whenever possible."
+  }, {
+    "@id" : "_:t65",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-prefer",
     "td:includesText" : "LDP servers SHOULD respect all of a client's LDP-defined hints, for example which subsets of LDP-defined state the client is interested in processing, to influence the set of triples returned in representations of an LDPC, particularly for large LDPCs. See also [LDP-PAGING]."
   }, {
-    "@id" : "_:t482",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-put-mbrprops",
-    "td:includesText" : "LDP servers SHOULD NOT allow HTTP PUT to update an LDPC’s containment triples; if the server receives such a request, it SHOULD respond with a 409 (Conflict) status code."
-  }, {
-    "@id" : "_:t49",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-reusevocabsuchas",
-    "td:includesText" : "LDP-RSs predicates SHOULD use standard vocabularies such as Dublin Core [DC-TERMS], RDF [rdf11-concepts] and RDF Schema [rdf-schema], whenever possible."
-  }, {
-    "@id" : "_:t53",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-prefer",
-    "td:includesText" : "LDP servers SHOULD respect all of a client's LDP-defined hints, for example which subsets of LDP-defined state the client is interested in processing, to influence the set of triples returned in representations of an LDPC, particularly for large LDPCs. See also [LDP-PAGING]."
-  }, {
-    "@id" : "_:t58",
+    "@id" : "_:t69",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-failed",
+    "td:includesText" : "If an otherwise valid HTTP PUT request is received that contains properties the server chooses not to persist, e.g. unknown content, LDP servers MUST respond with an appropriate 4xx range status code [HTTP11]."
+  }, {
+    "@id" : "_:t74",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-typecontainer",
     "td:includesText" : "The representation of a LDPC MAY have an rdf:type of ldp:Container for Linked Data Platform Container. Non-normative note: LDPCs might have additional types, like any LDP-RS. "
   }, {
-    "@id" : "_:t59",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-allow",
-    "td:includesText" : "LDP servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow. "
-  }, {
-    "@id" : "_:t64",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-typecontainer",
-    "td:includesText" : "The representation of a LDPC MAY have an rdf:type of ldp:Container for Linked Data Platform Container. Non-normative note: LDPCs might have additional types, like any LDP-RS. "
-  }, {
-    "@id" : "_:t65",
+    "@id" : "_:t75",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-defbaseuri",
     "td:includesText" : "LDP servers MUST assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource."
   }, {
-    "@id" : "_:t66",
+    "@id" : "_:t76",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-servermanagedprops",
+    "td:includesText" : "If an otherwise valid HTTP PUT request is received that attempts to change properties the server does not allow clients to modify, LDP servers MUST respond with a 4xx range status code (typically 409 Conflict)"
+  }, {
+    "@id" : "_:t77",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-simpleupdate",
     "td:includesText" : "LDP servers SHOULD allow clients to update resources without requiring detailed knowledge of server-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs."
   }, {
-    "@id" : "_:t69",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpdc-post-createdmbr-member",
-    "td:includesText" : "When a successful HTTP POST request to an LDPC results in the creation of an LDPR, the LDPC MUST update its membership triples to reflect that addition, and the resulting membership triple MUST be consistent with any LDP-defined predicates it exposes."
-  }, {
-    "@id" : "_:t70",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-put-failed",
-    "td:includesText" : "If an otherwise valid HTTP PUT request is received that contains properties the server chooses not to persist, e.g. unknown content, LDP servers MUST respond with an appropriate 4xx range status code [HTTP11]."
-  }, {
-    "@id" : "_:t71",
+    "@id" : "_:t78",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-jsonld",
+    "td:includesText" : "LDP servers SHOULD accept a request entity body with a request header of Content-Type with value of application/ld+json [JSON-LD]."
+  }, {
+    "@id" : "_:t79",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-patch-req",
+    "td:includesText" : "LDP servers are RECOMMENDED to support HTTP PATCH as the preferred method for updating an LDPC's empty-container triples. "
+  }, {
+    "@id" : "_:t88",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-pubclireqs",
     "td:includesText" : "LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with rel='describedby' [RFC5988] to all responses to requests which fail due to violation of those constraints."
   }, {
-    "@id" : "_:t73",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-precond",
-    "td:includesText" : "LDP servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request [HTTP11]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [RFC6585]."
-  }, {
-    "@id" : "_:t74",
+    "@id" : "_:t89",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-slug",
+    "td:includesText" : "LDP servers MAY allow clients to suggest the URI for a resource created through POST, using the HTTP Slug header as defined in [RFC5023]. LDP adds no new requirements to this usage, so its presence functions as a client hint to the server providing a desired string to be incorporated into the server's final choice of resource URI."
+  }, {
+    "@id" : "_:t9",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-noinferencing",
+    "td:includesText" : "LDP servers MUST NOT require LDP clients to implement inferencing in order to recognize the subset of content defined by LDP. Other specifications built on top of LDP may require clients to implement inferencing [rdf11-concepts]. The practical implication is that all content defined by LDP must be explicitly represented, unless noted otherwise within this document."
+  }, {
+    "@id" : "_:t90",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-noinferencing",
+    "td:includesText" : "LDP servers MUST NOT require LDP clients to implement inferencing in order to recognize the subset of content defined by LDP. Other specifications built on top of LDP may require clients to implement inferencing [rdf11-concepts]. The practical implication is that all content defined by LDP must be explicitly represented, unless noted otherwise within this document."
+  }, {
+    "@id" : "_:t91",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-allow",
     "td:includesText" : "LDP servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow. "
   }, {
-    "@id" : "_:t78",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-slug",
-    "td:includesText" : "LDP servers MAY allow clients to suggest the URI for a resource created through POST, using the HTTP Slug header as defined in [RFC5023]. LDP adds no new requirements to this usage, so its presence functions as a client hint to the server providing a desired string to be incorporated into the server's final choice of resource URI."
-  }, {
-    "@id" : "_:t79",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-allow",
-    "td:includesText" : "LDP servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow. "
-  }, {
-    "@id" : "_:t8",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-replaceall",
-    "td:includesText" : "If a HTTP PUT is accepted on an existing resource, LDP servers MUST replace the entire persistent state of the identified resource with the entity representation in the body of the request."
-  }, {
-    "@id" : "_:t84",
+    "@id" : "_:t92",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-http",
+    "td:includesText" : "LDP servers MUST at least be HTTP/1.1 conformant servers [HTTP11]."
+  }, {
+    "@id" : "_:t93",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-isldpr",
+    "td:includesText" : "Each Linked Data Platform Container MUST also be a conforming Linked Data Platform RDF Source."
+  }, {
+    "@id" : "_:t94",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-etags",
     "td:includesText" : "LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values."
   }, {
-    "@id" : "_:t87",
+    "@id" : "_:t95",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
     "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-get-jsonld",
     "td:includesText" : "LDP servers SHOULD offer a application/ld+json representation of the requested LDP-RS [JSON-LD]. "
   }, {
-    "@id" : "_:t88",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-defbaseuri",
-    "td:includesText" : "LDP servers MUST assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource."
-  }, {
-    "@id" : "_:t9",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-put-mbrprops",
-    "td:includesText" : "LDP servers SHOULD NOT allow HTTP PUT to update an LDPC’s containment triples; if the server receives such a request, it SHOULD respond with a 409 (Conflict) status code."
-  }, {
-    "@id" : "_:t93",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-nordfcontainertypes",
-    "td:includesText" : "LDPC representations SHOULD NOT use RDF container types rdf:Bag, rdf:Seq or rdf:List."
-  }, {
-    "@id" : "_:t94",
-    "rdf:type" : {
-      "@id" : "td:Excerpt"
-    },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-head-must",
-    "td:includesText" : "LDP servers MUST support the HTTP HEAD method. "
-  }, {
     "@id" : "_:t96",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-gen-reusevocab",
-    "td:includesText" : "LDP-RSs SHOULD reuse existing vocabularies instead of creating their own duplicate vocabulary terms. In addition to this general rule, some specific cases are covered by other conformance rules."
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpic-indirectmbr",
+    "td:includesText" : "LDP Indirect Containers MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is ldp:insertedContentRelation, and whose object ICR describes how the member-derived-URI in the container's membership triples is chosen."
   }, {
     "@id" : "_:t97",
     "rdf:type" : {
       "@id" : "td:Excerpt"
     },
-    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-gen-pubclireqs",
-    "td:includesText" : "LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with rel='describedby' [RFC5988] to all responses to requests which fail due to violation of those constraints."
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-put-simpleupdate",
+    "td:includesText" : "LDP servers SHOULD allow clients to update resources without requiring detailed knowledge of server-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs."
+  }, {
+    "@id" : "_:t98",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-post-mincontraints",
+    "td:includesText" : "LDP servers SHOULD allow clients to create new resources without requiring detailed knowledge of application-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs. LDP servers expose these application-specific constraints as described in section 4.2.1 General."
+  }, {
+    "@id" : "_:t99",
+    "rdf:type" : {
+      "@id" : "td:Excerpt"
+    },
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpr-options-allow",
+    "td:includesText" : "LDP servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow. "
   }, {
     "@id" : "ldpt:BasicContainer-4xxErrorHasResponseBody",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.375Z"
+      "@value" : "2014-08-25T13:17:51.747Z"
     },
     "dcterms:subject" : "SHOULD",
     "rdf:type" : {
@@ -1618,17 +1646,17 @@
     "mf:action" : "",
     "mf:name" : "BasicContainer-4xxErrorHasResponseBody",
     "reviewStatus" : "td:unreviewed",
-    "specificationReference" : "_:t450",
+    "specificationReference" : "_:t432",
     "conformanceLevel" : "ldpt:SHOULD",
     "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
     "declaredTestCase" : "ldpt:RdfSource-4xxErrorHasResponseBody",
-    "documentation" : "http://w3c.github.io/ldp-testsuite/api/java/org/w3/ldp/testsuite/test/RdfSourceTest.html#test4xxErrorHasResponseBody()",
+    "documentation" : "http://w3c.github.io/ldp-testsuite/api/java/org/w3/ldp/testsuite/test/RdfSourceTest.html#test4xxErrorHasResponseBody(java.lang.String)",
     "testMethod" : "ldpt:automated"
   }, {
     "@id" : "ldpt:BasicContainer-AcceptPatchHeader",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.384Z"
+      "@value" : "2014-08-25T13:17:51.756Z"
     },
     "dcterms:subject" : "MUST",
     "rdf:type" : {
@@ -1640,7 +1668,7 @@
     "mf:action" : "",
     "mf:name" : "BasicContainer-AcceptPatchHeader",
     "reviewStatus" : "td:approved",
-    "specificationReference" : "_:t30",
+    "specificationReference" : "_:t37",
     "conformanceLevel" : "ldpt:MUST",
     "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
     "declaredTestCase" : "ldpt:CommonResource-AcceptPatchHeader",
@@ -1650,7 +1678,7 @@
     "@id" : "ldpt:BasicContainer-AcceptPostResponseHeader",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.359Z"
+      "@value" : "2014-08-25T13:17:51.732Z"
     },
     "dcterms:subject" : "MUST",
     "rdf:type" : {
@@ -1662,7 +1690,7 @@
     "mf:action" : "",
     "mf:name" : "BasicContainer-AcceptPostResponseHeader",
     "reviewStatus" : "td:approved",
-    "specificationReference" : "_:t1",
+    "specificationReference" : "_:t12",
     "conformanceLevel" : "ldpt:MUST",
     "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
     "declaredTestCase" : "ldpt:CommonContainer-AcceptPostResponseHeader",
@@ -1672,7 +1700,7 @@
     "@id" : "ldpt:BasicContainer-AcceptTurtle",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.355Z"
+      "@value" : "2014-08-25T13:17:51.728Z"
     },
     "dcterms:subject" : "MUST",
     "rdf:type" : {
@@ -1684,7 +1712,7 @@
     "mf:action" : "",
     "mf:name" : "BasicContainer-AcceptTurtle",
     "reviewStatus" : "td:approved",
-    "specificationReference" : "_:t389",
+    "specificationReference" : "_:t381",
     "conformanceLevel" : "ldpt:MUST",
     "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
     "declaredTestCase" : "ldpt:CommonContainer-AcceptTurtle",
@@ -1694,7 +1722,7 @@
     "@id" : "ldpt:BasicContainer-ConditionFailedStatusCode",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.382Z"
+      "@value" : "2014-08-25T13:17:51.754Z"
     },
     "dcterms:subject" : "MUST",
     "rdf:type" : {
@@ -1706,17 +1734,86 @@
     "mf:action" : "",
     "mf:name" : "BasicContainer-ConditionFailedStatusCode",
     "reviewStatus" : "td:approved",
-    "specificationReference" : "_:t273",
+    "specificationReference" : "_:t190",
     "conformanceLevel" : "ldpt:MUST",
     "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
     "declaredTestCase" : "ldpt:CommonResource-ConditionFailedStatusCode",
     "documentation" : "http://w3c.github.io/ldp-testsuite/api/java/org/w3/ldp/testsuite/test/CommonResourceTest.html#testConditionFailedStatusCode()",
     "testMethod" : "ldpt:automated"
   }, {
+    "@id" : "ldpt:BasicContainer-ConformsBcLdpContainer",
+    "dcterms:date" : {
+      "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
+      "@value" : "2014-08-25T13:17:51.719Z"
+    },
+    "dcterms:hasPart" : [ "http://www.w3c.org/ns/ldp/test#CommonContainer-PostResponseStatusAndLocation", "http://www.w3c.org/ns/ldp/test#CommonContainer-RequestedInteractionModelCreateNotAllowed", "http://www.w3c.org/ns/ldp/test#CommonContainer-DeleteRemovesContainmentTriple", "http://www.w3c.org/ns/ldp/test#CommonContainer-NullRelativeUriPost", "http://www.w3c.org/ns/ldp/test#CommonContainer-PostContainer", "http://www.w3c.org/ns/ldp/test#CommonContainer-AcceptPostResponseHeader", "http://www.w3c.org/ns/ldp/test#CommonContainer-RequestedInteractionModelHeaders", "http://www.w3c.org/ns/ldp/test#CommonContainer-AcceptTurtle", "http://www.w3c.org/ns/ldp/test#CommonContainer-RelativeUriResolutionPost", "http://www.w3c.org/ns/ldp/test#CommonContainer-ConformsContainerRdfResource" ],
+    "dcterms:subject" : "MUST",
+    "rdf:type" : {
+      "@id" : "earl:TestRequirement"
+    },
+    "rdfs:comment" : "Each LDP Basic Container MUST also be a conforming LDP Container in section 5.2 Container along with the following restrictions in this section.",
+    "rdfs:label" : "BasicContainer-ConformsBcLdpContainer",
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpbc-are-ldpcs",
+    "mf:action" : "",
+    "mf:name" : "BasicContainer-ConformsBcLdpContainer",
+    "reviewStatus" : "td:unreviewed",
+    "specificationReference" : "_:t181",
+    "conformanceLevel" : "ldpt:MUST",
+    "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
+    "declaredTestCase" : "ldpt:BasicContainer-ConformsBcLdpContainer",
+    "documentation" : "http://w3c.github.io/ldp-testsuite/api/java/org/w3/ldp/testsuite/test/BasicContainerTest.html#testConformsBcLdpContainer()",
+    "testMethod" : "ldpt:indirect"
+  }, {
+    "@id" : "ldpt:BasicContainer-ConformsContainerRdfResource",
+    "dcterms:date" : {
+      "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
+      "@value" : "2014-08-25T13:17:51.736Z"
+    },
+    "dcterms:hasPart" : [ "http://www.w3c.org/ns/ldp/test#RdfSource-PutReadOnlyProperties4xxStatus", "http://www.w3c.org/ns/ldp/test#RdfSource-GetResourceAcceptTurtle", "http://www.w3c.org/ns/ldp/test#RdfSource-PutSimpleUpdate", "http://www.w3c.org/ns/ldp/test#RdfSource-PublishConstraintsReadOnlyProp", "http://www.w3c.org/ns/ldp/test#RdfSource-RelativeUriResolutionPut", "http://www.w3c.org/ns/ldp/test#RdfSource-PublishConstraintsUnknownProp", "http://www.w3c.org/ns/ldp/test#RdfSource-PutPropertiesNotPersisted", "http://www.w3c.org/ns/ldp/test#RdfSource-RestrictClientInference", "http://www.w3c.org/ns/ldp/test#RdfSource-PutReplacesResource", "http://www.w3c.org/ns/ldp/test#RdfSource-ConformsRdfSourceLdpResource", "http://www.w3c.org/ns/ldp/test#RdfSource-GetResource" ],
+    "dcterms:subject" : "MUST",
+    "rdf:type" : {
+      "@id" : "earl:TestRequirement"
+    },
+    "rdfs:comment" : "Each Linked Data Platform Container MUST also be a conforming Linked Data Platform RDF Source.",
+    "rdfs:label" : "BasicContainer-ConformsContainerRdfResource",
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldpc-isldpr",
+    "mf:action" : "",
+    "mf:name" : "BasicContainer-ConformsContainerRdfResource",
+    "reviewStatus" : "td:unreviewed",
+    "specificationReference" : "_:t133",
+    "conformanceLevel" : "ldpt:MUST",
+    "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
+    "declaredTestCase" : "ldpt:CommonContainer-ConformsContainerRdfResource",
+    "documentation" : "http://w3c.github.io/ldp-testsuite/api/java/org/w3/ldp/testsuite/test/CommonContainerTest.html#testConformsContainerRdfResource()",
+    "testMethod" : "ldpt:indirect"
+  }, {
+    "@id" : "ldpt:BasicContainer-ConformsRdfSourceLdpResource",
+    "dcterms:date" : {
+      "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
+      "@value" : "2014-08-25T13:17:51.748Z"
+    },
+    "dcterms:hasPart" : [ "http://www.w3c.org/ns/ldp/test#CommonResource-Head", "http://www.w3c.org/ns/ldp/test#CommonResource-Options", "http://www.w3c.org/ns/ldp/test#CommonResource-PreconditionRequiredStatusCode", "http://www.w3c.org/ns/ldp/test#CommonResource-IsHttp11Manual", "http://www.w3c.org/ns/ldp/test#CommonResource-LdpLinkHeader", "http://www.w3c.org/ns/ldp/test#CommonResource-AcceptPatchHeader", "http://www.w3c.org/ns/ldp/test#CommonResource-ConditionFailedStatusCode", "http://www.w3c.org/ns/ldp/test#CommonResource-PutBadETag", "http://www.w3c.org/ns/ldp/test#CommonResource-OptionsAllowHeader", "http://www.w3c.org/ns/ldp/test#CommonResource-GetResource", "http://www.w3c.org/ns/ldp/test#CommonResource-ETagHeadersHead", "http://www.w3c.org/ns/ldp/test#CommonResource-ETagHeadersGet", "http://www.w3c.org/ns/ldp/test#CommonResource-GetResponseHeaders" ],
+    "dcterms:subject" : "MUST",
+    "rdf:type" : {
+      "@id" : "earl:TestRequirement"
+    },
+    "rdfs:comment" : "Each LDP RDF Source MUST also be a conforming LDP Resource as defined in section 4.2 Resource, along with the restrictions in this section.",
+    "rdfs:label" : "BasicContainer-ConformsRdfSourceLdpResource",
+    "seeAlso" : "http://www.w3.org/TR/ldp#ldprs-are-ldpr",
+    "mf:action" : "",
+    "mf:name" : "BasicContainer-ConformsRdfSourceLdpResource",
+    "reviewStatus" : "td:unreviewed",
+    "specificationReference" : "_:t446",
+    "conformanceLevel" : "ldpt:MUST",
+    "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
+    "declaredTestCase" : "ldpt:RdfSource-ConformsRdfSourceLdpResource",
+    "documentation" : "http://w3c.github.io/ldp-testsuite/api/java/org/w3/ldp/testsuite/test/RdfSourceTest.html#testConformsRdfSourceLdpResource()",
+    "testMethod" : "ldpt:indirect"
+  }, {
     "@id" : "ldpt:BasicContainer-ContainerSupportsHttpLinkHeader",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.348Z"
+      "@value" : "2014-08-25T13:17:51.723Z"
     },
     "dcterms:subject" : "MUST",
     "rdf:type" : {
@@ -1728,7 +1825,7 @@
     "mf:action" : "",
     "mf:name" : "BasicContainer-ContainerSupportsHttpLinkHeader",
     "reviewStatus" : "td:approved",
-    "specificationReference" : "_:t234",
+    "specificationReference" : "_:t452",
     "conformanceLevel" : "ldpt:MUST",
     "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
     "declaredTestCase" : "ldpt:BasicContainer-ContainerSupportsHttpLinkHeader",
@@ -1738,7 +1835,7 @@
     "@id" : "ldpt:BasicContainer-ContainsRdfType",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.368Z"
+      "@value" : "2014-08-25T13:17:51.741Z"
     },
     "dcterms:subject" : "SHOULD",
     "rdf:type" : {
@@ -1750,7 +1847,7 @@
     "mf:action" : "",
     "mf:name" : "BasicContainer-ContainsRdfType",
     "reviewStatus" : "td:approved",
-    "specificationReference" : "_:t291",
+    "specificationReference" : "_:t306",
     "conformanceLevel" : "ldpt:SHOULD",
     "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
     "declaredTestCase" : "ldpt:RdfSource-ContainsRdfType",
@@ -1760,7 +1857,7 @@
     "@id" : "ldpt:BasicContainer-ContentTypeHeader",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.356Z"
+      "@value" : "2014-08-25T13:17:51.729Z"
     },
     "dcterms:subject" : "SHOULD",
     "rdf:type" : {
@@ -1772,7 +1869,7 @@
     "mf:action" : "",
     "mf:name" : "BasicContainer-ContentTypeHeader",
     "reviewStatus" : "td:unreviewed",
-    "specificationReference" : "_:t334",
+    "specificationReference" : "_:t466",
     "conformanceLevel" : "ldpt:SHOULD",
     "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
     "declaredTestCase" : "ldpt:CommonContainer-ContentTypeHeader",
@@ -1782,7 +1879,7 @@
     "@id" : "ldpt:BasicContainer-CreateWithoutConstraints",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.358Z"
+      "@value" : "2014-08-25T13:17:51.73Z"
     },
     "dcterms:subject" : "SHOULD",
     "rdf:type" : {
@@ -1794,7 +1891,7 @@
     "mf:action" : "",
     "mf:name" : "BasicContainer-CreateWithoutConstraints",
     "reviewStatus" : "td:approved",
-    "specificationReference" : "_:t370",
+    "specificationReference" : "_:t98",
     "conformanceLevel" : "ldpt:SHOULD",
     "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
     "declaredTestCase" : "ldpt:CommonContainer-CreateWithoutConstraints",
@@ -1804,7 +1901,7 @@
     "@id" : "ldpt:BasicContainer-DeleteRemovesContainmentTriple",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.361Z"
+      "@value" : "2014-08-25T13:17:51.733Z"
     },
     "dcterms:subject" : "MUST",
     "rdf:type" : {
@@ -1816,7 +1913,7 @@
     "mf:action" : "",
     "mf:name" : "BasicContainer-DeleteRemovesContainmentTriple",
     "reviewStatus" : "td:approved",
-    "specificationReference" : "_:t205",
+    "specificationReference" : "_:t469",
     "conformanceLevel" : "ldpt:MUST",
     "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
     "declaredTestCase" : "ldpt:CommonContainer-DeleteRemovesContainmentTriple",
@@ -1826,7 +1923,7 @@
     "@id" : "ldpt:BasicContainer-ETagHeadersGet",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.379Z"
+      "@value" : "2014-08-25T13:17:51.752Z"
     },
     "dcterms:subject" : "MUST",
     "rdf:type" : {
@@ -1838,7 +1935,7 @@
     "mf:action" : "",
     "mf:name" : "BasicContainer-ETagHeadersGet",
     "reviewStatus" : "td:unreviewed",
-    "specificationReference" : "_:t443",
+    "specificationReference" : "_:t137",
     "conformanceLevel" : "ldpt:MUST",
     "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
     "declaredTestCase" : "ldpt:CommonResource-ETagHeadersGet",
@@ -1848,7 +1945,7 @@
     "@id" : "ldpt:BasicContainer-ETagHeadersHead",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.379Z"
+      "@value" : "2014-08-25T13:17:51.752Z"
     },
     "dcterms:subject" : "MUST",
     "rdf:type" : {
@@ -1860,7 +1957,7 @@
     "mf:action" : "",
     "mf:name" : "BasicContainer-ETagHeadersHead",
     "reviewStatus" : "td:approved",
-    "specificationReference" : "_:t238",
+    "specificationReference" : "_:t363",
     "conformanceLevel" : "ldpt:MUST",
     "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
     "declaredTestCase" : "ldpt:CommonResource-ETagHeadersHead",
@@ -1870,7 +1967,7 @@
     "@id" : "ldpt:BasicContainer-GetResource",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.367Z"
+      "@value" : "2014-08-25T13:17:51.741Z"
     },
     "dcterms:subject" : "MUST",
     "rdf:type" : {
@@ -1882,7 +1979,7 @@
     "mf:action" : "",
     "mf:name" : "BasicContainer-GetResource",
     "reviewStatus" : "td:approved",
-    "specificationReference" : "_:t190",
+    "specificationReference" : "_:t198",
     "conformanceLevel" : "ldpt:MUST",
     "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
     "declaredTestCase" : "ldpt:RdfSource-GetResource",
@@ -1892,7 +1989,7 @@
     "@id" : "ldpt:BasicContainer-GetResourceAcceptTurtle",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.372Z"
+      "@value" : "2014-08-25T13:17:51.744Z"
     },
     "dcterms:subject" : "MUST",
     "rdf:type" : {
@@ -1904,7 +2001,7 @@
     "mf:action" : "",
     "mf:name" : "BasicContainer-GetResourceAcceptTurtle",
     "reviewStatus" : "td:approved",
-    "specificationReference" : "_:t439",
+    "specificationReference" : "_:t408",
     "conformanceLevel" : "ldpt:MUST",
     "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
     "declaredTestCase" : "ldpt:RdfSource-GetResourceAcceptTurtle",
@@ -1914,7 +2011,7 @@
     "@id" : "ldpt:BasicContainer-GetResponseHeaders",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.381Z"
+      "@value" : "2014-08-25T13:17:51.753Z"
     },
     "dcterms:subject" : "MUST",
     "rdf:type" : {
@@ -1926,7 +2023,7 @@
     "mf:action" : "",
     "mf:name" : "BasicContainer-GetResponseHeaders",
     "reviewStatus" : "td:approved",
-    "specificationReference" : "_:t103",
+    "specificationReference" : "_:t323",
     "conformanceLevel" : "ldpt:MUST",
     "ldpt:declaredInClass" : "org.w3.ldp.testsuite.test.BasicContainerTest",
     "declaredTestCase" : "ldpt:CommonResource-GetResponseHeaders",
@@ -1936,7 +2033,7 @@
     "@id" : "ldpt:BasicContainer-Head",
     "dcterms:date" : {
       "@type" : "http://www.w3.org/2001/XMLSchema#dateTime",
-      "@value" : "2014-07-21T01:25:01.384Z"
+      "@value" : "2014-08-25T13:17:51.756Z"
     },
     "dcterms:subject" : "MUST",
     &q