ldp.html
changeset 513 2df2933649d4
parent 512 28fb37e65361
child 514 7e329a35960e
--- a/ldp.html	Sat Mar 01 13:50:02 2014 -0500
+++ b/ldp.html	Sat Mar 01 14:51:42 2014 -0500
@@ -5,6 +5,7 @@
 	TODO: Add new "discovery of server capabilities" non-norm section
     TODO: Consider folding LDP Clients section, feels a bit out of place
     TODO: Consider creating LDPR sub sections R, RS, NR like LDPCs
+    TODO: Consider adding Venn diagram for differences of LDPCs
  -->
 <html>
   <head>
@@ -543,36 +544,20 @@
 	
 </section>
 
+<section id="ldpr-resource">
+<h2>Resource</h2>
+
 <section id="ldpr-general">
 <h2>General</h2>
 		
 	<section id="ldpr-gen-http"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].
 	</h2></section><!-- Was 4.2.1 / #ldpr-4_2_1 -->
 	
-	<section id="ldpr-gen-rdf"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide an RDF representation for <a title="Linked Data Platform RDF Source">LDP-RSs</a>. 
-	The HTTP <code>Request-URI</code> of the LDP-RS is typically the subject of most triples in the response.
-	</h2></section><!-- Was 4.2.2 / #ldpr-4_2_2 -->
-	
 	<section id="ldpr-gen-binary"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY host a mixture of LDPRs, <a title="Linked Data Platform RDF Source">LDP-RSs</a>
 	and <a title="Linked Data Platform Non-RDF Source">LDP-NRs</a>. For example, it
 		is common for <a title="LDP server">LDP servers</a> to need to host binary or text resources
 		that do not have useful RDF representations.</h2></section><!-- Was 4.2.3 / #ldpr-4_2_3 -->
 
-	<section id="ldpr-gen-reusevocab"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> SHOULD reuse existing vocabularies instead of creating
-		their own duplicate vocabulary terms.  In addition to this general rule, some specific cases are
-		covered by other conformance rules.
-	</h2></section><!-- Was 4.2.4 / #ldpr-4_2_4 -->
-	
-	<section id="ldpr-gen-reusevocabsuchas"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> predicates SHOULD use standard vocabularies such as Dublin Core
-		[[!DC-TERMS]], RDF [[!rdf11-concepts]] and RDF Schema [[!rdf-schema]], whenever
-		possible.
-	</h2></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->
-	
-	<section id="ldpr-gen-atleast1rdftype"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> representations SHOULD have at least one <code>rdf:type</code>
-		set explicitly.  This makes the representations much more useful to
-		client applications that don’t support inferencing.
-	</h2></section><!-- Was 4.2.5 / #ldpr-4_2_5 -->
-	
 	<section id="ldpr-gen-etags"><h2 class="normal"><a title="LDP server">LDP server</a> responses MUST use entity tags (either 
 		weak or strong ones) as response <code>ETag</code> header values.
 	</h2></section><!-- Was 4.2.8 / #ldpr-4_2_8 -->
@@ -605,14 +590,7 @@
 		individually inspected, in the absence of outside information.
 		</p>
 	</blockquote>
-	
-	<section id="ldpr-gen-noinferencing"><h2 class="normal"><a title="LDP server">LDP servers</a>
-		MUST NOT require LDP clients to implement inferencing in order to recognize the subset
-		of content defined by LDP.  Other specifications built on top of LDP may require clients
-		to implement inferencing [[!rdf11-concepts]].  The practical implication is that all content defined by LDP
-		must be explicitly represented, unless noted otherwise within this document.
-	</h2></section><!-- Was 4.2.11 / #ldpr-4_2_11 -->
-	
+
 	<section id="ldpr-gen-defbaseuri"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST assign the default 
 		base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP 
 		<code>Request-URI</code> when the resource already exists, and to the URI of the created resource when the request results 
@@ -643,10 +621,6 @@
 		<a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
 	</h2></section><!-- Was 4.3.2 / #ldpr-4_3_2 -->
 	
-	<section id="ldpr-get-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide a <code>text/turtle</code>
-		representation of the requested <a title="Linked Data Platform RDF Source">LDP-RS</a> [[!turtle]].
-	</h2></section><!-- Was 4.3.3 / #ldpr-4_3_3 -->
-
 </section>
 
 <section id="ldpr-HTTP_POST">
@@ -680,6 +654,7 @@
 		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
 	</p>
 		
+	<!-- TODO: Should we move these to LDP-RS section?  They are generic enough. -->
 	<section id="ldpr-put-replaceall"><h2 class="normal">If a HTTP <code>PUT</code> is accepted on an existing resource, 
 		<a title="LDP server">LDP servers</a> MUST
 		replace the entire persistent state of the identified resource with
@@ -691,24 +666,7 @@
 		with existing state stored on the server for a resource MUST use HTTP
 		<code>PATCH</code>, not HTTP <code>PUT</code>.
 	</h2></section><!-- Was 4.5.1 / #ldpr-4_5_1 -->
-		
-	<section id="ldpr-put-servermanagedprops"><h2 class="normal">
-		If an otherwise valid HTTP <code>PUT</code> request is received 
-		that attempts to change triples the server does not allow clients to modify, 
-		<a title="LDP server">LDP servers</a> MUST 
-		respond with a 4xx range status code (typically
-		409 Conflict). 
-		<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
-		information about which triples could not be
-		persisted.
-		The format of the 4xx response body is not constrained by LDP.
-	</h2></section><!-- Was 4.5.1.1 / #ldpr-4_5_1_1 -->
-	<blockquote>
-		Non-normative note: Clients might provide triples equivalent to those already in the resource's state,
-		e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the 
-		server-controlled triples are identical on the GET response and the subsequent PUT request.
-	</blockquote>
-		
+
 	<section id="ldpr-put-precond"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD use the HTTP <code>If-Match</code>
 		header and HTTP <code>ETags</code> to ensure it isn’t
 		modifying a resource that has changed since the client last retrieved
@@ -719,18 +677,6 @@
 		(Precondition Required) when the absence of a precondition is the only reason for rejecting the request [[!RFC6585]].
 	</h2></section><!-- Was 4.5.2 / #ldpr-4_5_2 -->
 	
-	<section id="ldpr-put-failed"><h2 class="normal">
-		If an otherwise valid HTTP <code>PUT</code> request is received that contains triples the server 
-		chooses not to persist, e.g. unknown content,
-		<a title="LDP server">LDP servers</a> MUST respond with an appropriate 4xx range status code
-		[[HTTP11]].  
-		<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
-		information about which triples could not be
-		persisted.
-		The format of the 4xx response body is not constrained by LDP. LDP servers
-		expose these application-specific constraints as described in <a href="#ldpr-general" class="sectionRef"></a>.
-	</h2></section><!-- Was 4.5.4 / #ldpr-4_5_4 -->
-	
 	<section id="ldpr-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
 	</h2></section><!-- Was 4.5.6 / #ldpr-4_5_6 -->
 	
@@ -804,7 +750,121 @@
 
 </section> <!-- h2 -->
 
-</section> <!-- h1 -->
+</section> <!-- ldpr-resource -->
+
+<section id="ldprs">
+<h2>RDF Source</h2>
+
+<p>The following section contains normative clauses for <a title="">Linked Data Platform RDF Source</a>.</p>
+
+<section id="ldprs-general">
+<h2>General</h2>
+
+	<section id="ldprs-are-ldpr"><h2 class="normal">Each <a title="Linked Data Platform RDF Resource">LDP RDF Source</a> MUST also be 
+		a conforming <a title="Linked Data Platform Resource">LDP Resource</a> in <a href="#ldpr-resource" class="sectionRef"></a> along the
+		following restrictions in this section. <a title="">LDP client</a>s MAY infer the following triple:
+		whose subject is <code>ldp:RDFSource</code>, 
+		whose predicate is <code>rdfs:subClassOf</code>, 
+		and whose object is <code>ldp:Resource</code>, 
+		but there is no requirement to materialize this triple in the LDP-RS representation.
+	</h2></section>
+	
+	<section id="ldprs-gen-atleast1rdftype"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> representations SHOULD have at least one <code>rdf:type</code>
+		set explicitly.  This makes the representations much more useful to
+		client applications that don’t support inferencing.
+	</h2></section><!-- Was 4.2.5 / #ldpr-4_2_5 -->
+
+	<section id="ldpc-typecontainer"><h2 class="normal">The representation of an LDP-RS MAY have an <code>rdf:type</code>
+		of only one of <code>ldp:RDFSource</code> for <a title="">Linked Data Platform RDF Source</a>.
+	</h2></section><!-- Was 5.2.7 / #ldpc-5_2_7 -->
+		
+	<section id="ldprs-gen-rdf"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide an RDF representation for <a title="Linked Data Platform RDF Source">LDP-RSs</a>. 
+	The HTTP <code>Request-URI</code> of the LDP-RS is typically the subject of most triples in the response.
+	</h2></section><!-- Was 4.2.2 / #ldpr-4_2_2 -->
+	
+	<section id="ldprs-gen-reusevocab"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> SHOULD reuse existing vocabularies instead of creating
+		their own duplicate vocabulary terms.  In addition to this general rule, some specific cases are
+		covered by other conformance rules.
+	</h2></section><!-- Was 4.2.4 / #ldpr-4_2_4 -->
+	
+	<section id="ldprs-gen-reusevocabsuchas"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> predicates SHOULD use standard vocabularies such as Dublin Core
+		[[!DC-TERMS]], RDF [[!rdf11-concepts]] and RDF Schema [[!rdf-schema]], whenever
+		possible.
+	</h2></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->
+	
+	<section id="ldprs-gen-noinferencing"><h2 class="normal"><a title="LDP server">LDP servers</a>
+		MUST NOT require LDP clients to implement inferencing in order to recognize the subset
+		of content defined by LDP.  Other specifications built on top of LDP may require clients
+		to implement inferencing [[!rdf11-concepts]].  The practical implication is that all content defined by LDP
+		must be explicitly represented, unless noted otherwise within this document.
+	</h2></section><!-- Was 4.2.11 / #ldpr-4_2_11 -->
+	
+</section> <!-- ldprs-general -->
+
+<section id="ldprs-HTTP_GET">
+<h2>HTTP GET</h2>
+	<section id="ldprs-get-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide a <code>text/turtle</code>
+		representation of the requested <a title="Linked Data Platform RDF Source">LDP-RS</a> [[!turtle]].
+	</h2></section><!-- Was 4.3.3 / #ldpr-4_3_3 -->
+
+</section> <!-- ldprs-HTTP_GET -->
+
+<section id="ldprs-HTTP_PUT">
+<h2>HTTP PUT</h2>
+
+<!-- TODO: Should we make them apply to non-RDF as well? -->
+	<section id="ldprs-put-servermanagedprops"><h2 class="normal">
+		If an otherwise valid HTTP <code>PUT</code> request is received 
+		that attempts to change triples the server does not allow clients to modify, 
+		<a title="LDP server">LDP servers</a> MUST 
+		respond with a 4xx range status code (typically
+		409 Conflict). 
+		<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
+		information about which triples could not be
+		persisted.
+		The format of the 4xx response body is not constrained by LDP.
+	</h2></section><!-- Was 4.5.1.1 / #ldpr-4_5_1_1 -->
+	<blockquote>
+		Non-normative note: Clients might provide triples equivalent to those already in the resource's state,
+		e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the 
+		server-controlled triples are identical on the GET response and the subsequent PUT request.
+	</blockquote>
+	
+	<section id="ldprs-put-failed"><h2 class="normal">
+		If an otherwise valid HTTP <code>PUT</code> request is received that contains triples the server 
+		chooses not to persist, e.g. unknown content,
+		<a title="LDP server">LDP servers</a> MUST respond with an appropriate 4xx range status code
+		[[HTTP11]].  
+		<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
+		information about which triples could not be
+		persisted.
+		The format of the 4xx response body is not constrained by LDP. LDP servers
+		expose these application-specific constraints as described in <a href="#ldpr-general" class="sectionRef"></a>.
+	</h2></section><!-- Was 4.5.4 / #ldpr-4_5_4 -->
+	
+</section> <!-- ldprs-HTTP_PUT -->
+
+</section> <!-- ldprs RDF Source-->
+
+<section id="ldpnr">
+<h2>Non-RDF Source</h2>
+
+<p>The following section contains normative clauses for <a title="">Linked Data Platform Non-RDF Source</a>.</p>
+
+<section id="ldpnr-general">
+<h2>General</h2>
+
+	<section id="ldpnr-are-ldpr"><h2 class="normal">Each <a title="Linked Data Platform Non-RDF Source">LDP Non-RDF Source</a> MUST also be 
+		a conforming <a title="Linked Data Platform Resource">LDP Resource</a> in <a href="#ldpr-resource" class="sectionRef"></a>.  
+		<a title="Linked Data Platform Non-RDF Source">LDP Non-RDF Source</a> may not be able to fully express their
+		state using RDF. [[rdf11-concepts]]
+	</h2></section>
+
+</section> <!-- ldpnr Non-RDF Source-->
+
+</section>
+
+</section> <!-- ldpr h1 -->
 
 <section id="ldpc">
 <h1>Linked Data Platform Containers</h1>
@@ -2152,6 +2212,7 @@
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130730/">Last Call Draft</a></em></blockquote> -->
 <ul>
+	<li>2014-03-01 - Split out different kinds of LDPRs into their own subsection (SS)</li>
 	<li>2014-02-28 - Combined rules for container triples (SS) </li>
 	<li>2014-02-28 - Split out different kinds of LDPCs into their own subsection (SS)</li>
 	<li>2014-02-24 - Corrected rel=meta to be rel=describedby (SS) </li>