ldp.html
changeset 466 7b840138bdf1
parent 465 26eb1d6d4fd6
child 467 0eed67a3db4e
--- a/ldp.html	Thu Feb 06 15:36:17 2014 -0500
+++ b/ldp.html	Thu Feb 06 17:12:36 2014 -0500
@@ -309,18 +309,18 @@
 	<p></p></dd>
 	
 	<dt><dfn>Linked Data Platform Basic Container</dfn> (<abbr title="Linked Data Platform Basic Container">LDP-BC</abbr>)</dt>
-	<dd>An <a title="Linked Data Platform Container">LDPC</a> that uses a single pre-defined predicate to link to both
+	<dd>A <a title="Linked Data Platform Container">LDPC</a> that uses a single pre-defined predicate to link to both
 	its <a title="Containment">contained</a> and <a title="Membership">member</a> documents (information resources) [[!WEBARCH]].
 	<p></p></dd>
 	
 	<dt><dfn>Linked Data Platform Direct Container</dfn> (<abbr title="Linked Data Platform Direct Container">LDP-DC</abbr>)</dt>
-	<dd>An <a title="Linked Data Platform Container">LDPC</a> that has the flexibility of choosing what form its 
+	<dd>A <a title="Linked Data Platform Container">LDPC</a> that has the flexibility of choosing what form its 
 	<a title="Membership triples">membership triples</a> take, and allows <a title="Membership">members</a> to be 
 	any resources [[!WEBARCH]], not only documents.
 	<p></p></dd>
 	
 	<dt><dfn>Linked Data Platform Indirect Container</dfn> (<abbr title="Linked Data Platform Indirect Container">LDP-IC</abbr>)</dt>
-	<dd>An <a title="Linked Data Platform Container">LDPC</a> that is similar to a <a title="Linked Data Platform Direct Container">LDP-DC</a>
+	<dd>A <a title="Linked Data Platform Container">LDPC</a> that is similar to a <a title="Linked Data Platform Direct Container">LDP-DC</a>
 	and is capable of accepting creation requests that result in <a title="Membership">members</a> being added based
 	on the content of its <a title="Containment">contained</a> documents rather than the URIs assigned to those documents.
 	<p></p></dd>
@@ -491,23 +491,24 @@
 </p>
 <section><h2>General</h2>
 	<section id="ldp-cli-multitype"><h2 class="normal">In the absence of special knowledge of the application or domain, 
-		<a title="LDP client">LDP clients</a> MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
+		<a title="LDP client">LDP clients</a> MUST assume that any LDP-RR can have multiple values for <code>rdf:type</code>.
 	</h2></section> <!-- Was 4.3.5 / #ldpr-4_3_5 -->
 	
 	<section id="ldpr-cli-typeschange"><h2 class="normal">In the absence of special knowledge of the application or domain, 
 		<a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
-		of a given LDPR can change over time.
+		of a given LDP-RR can change over time.
 	</h2></section> <!-- Was 4.3.6 / #ldpr-4_3_6 -->
 	
 	<section id="ldpr-cli-openpreds"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
-		resource of a particular type at an arbitrary server is open, in the
+		LDP-RR of a particular type at an arbitrary server is open, in the
 		sense that different resources of the same type may not all have the
 		same set of predicates in their triples, and the set of predicates that
-		are used in the state of any one resource is not limited to any pre-defined
+		are used in the state of any one LDP-RR is not limited to any pre-defined
 		set.
 	</h2></section> <!-- Was 4.5.3 / #ldpr-ldpr-4_5_3 -->
 	
-	<section id="ldpr-cli-preservetriples"><h2 class="normal">A <a title="LDP client">LDP client</a> MUST preserve all triples retrieved using HTTP <code>GET</code> that
+	<section id="ldpr-cli-preservetriples"><h2 class="normal">
+		A <a title="LDP client">LDP client</a> MUST preserve all triples retrieved from an LDP-RR using HTTP <code>GET</code> that
 		it doesn’t change whether it understands the predicates or not, when
 		its intent is to perform an update using HTTP <code>PUT</code>.  The use of HTTP
 		<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
@@ -520,7 +521,7 @@
 <h1>Linked Data Platform Resources</h1>
 
 <section class="informative" id="ldpr-informative">
-<h2>Non-normative</h2>
+<h2>Introduction</h2>
 	<p>Linked Data Platform Resources (<dfn><abbr title="Linked Data Platform Resources">LDPRs</abbr></dfn>) are HTTP resources
 		that conform to the simple patterns and conventions in this section.
 		HTTP requests to access, modify, create or delete LDPRs are accepted
@@ -784,6 +785,8 @@
 		only when the LDPR supports that method.  This specification does not impose any
 		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
 	<p>Additional requirements on HTTP <code>DELETE</code> of LDPRs within containers can be found in
+	<a href="#ldpc-HTTP_DELETE" class="sectionRef"></a>.
+	</p>
 </section>
 
 <section id="ldpr-HTTP_HEAD">
@@ -1091,7 +1094,7 @@
 <h1>Linked Data Platform Containers</h1>
 
 <section class="informative" id="ldpc-informative">		
-<h2>Non-normative</h2>
+<h2>Introduction</h2>
 	<p>Many HTTP applications and sites have organizing
 		concepts that partition the overall space of resources into smaller
 		containers. Blog posts are grouped into blogs, wiki pages are grouped
@@ -1601,24 +1604,14 @@
 	</h2></section><!-- Was 5.2.5.2 / #ldpc-5_2_5_2 -->
 	</section>
 
-	<section id="ldpc-indirectmbr"><h2 class="normal">LDPCs (<a title="Linked Data Platform Direct Container">Direct</a>
-		and <a title="Linked Data Platform Indirect Container">Indirect</a> Containers only) MUST contain one triple whose
+	<section id="ldpc-indirectmbr"><h2 class="normal">
+		LDP <a title="Linked Data Platform Indirect Container">Indirect</a> Containers 
+		MUST contain exactly one triple whose
 	    subject is the LDPC URI, 
 		whose predicate is <code>ldp:insertedContentRelation</code>, and 
 		whose object <var>ICR</var> describes how the <var>member-derived-URI</var> in 
-		the container's <a title="Membership triples">membership triples</a> is chosen.</h2>
-		<ul>
-		<li>
-		For <a title="Linked Data Platform Direct Container">LDP Direct Containers</a>, 
-		<var>ICR</var> MUST have the value <code>ldp:MemberSubject</code>, meaning that
-		the 
-		<var>member-derived-URI</var> is the URI assigned by the server to a 
-		document it creates; for example, if the client POSTs content to a container
-		that causes the container to create a new LDPR, <code>ldp:MemberSubject</code> says
-		that the <var>member-derived-URI</var> is the URI assigned to the newly created LDPR.
-		</li>
-		<li>
-		For <a title="Linked Data Platform Direct Container">LDP Indirect Containers</a>, the <var>member-derived-URI</var> is taken from some triple 
+		the container's <a title="Membership triples">membership triples</a> is chosen.
+		The <var>member-derived-URI</var> is taken from some triple 
 		<var>( S, P, O )</var> in the document supplied by the client as input to the create request;
 		if <var>ICR</var>'s value is <var>P</var>, then the <var>member-derived-URI</var> is
 		<var>O</var>.  LDP does not define the behavior when more than one triple containing 
@@ -1628,13 +1621,20 @@
 		<var>( &lt;&gt; , foaf:primaryTopic , bob#me )</var>
 		<code>foaf:primaryTopic</code> says
 		that the <var>member-derived-URI</var> is <var>bob#me</var>.  
-		</li>
-		</ul>
+		</h2>
 
 		<section id="ldpc-indirectmbr-basic"><h2 class="normal">
-			<a title="Linked Data Platform Basic Container">Basic</a> Containers MUST behave as if they
+			LDP 
+			<a title="Linked Data Platform Basic Container">Basic</a> and 
+			<a title="Linked Data Platform Direct Container">Direct</a>Containers 
+			MUST behave as if they
 			have a <var>( LDPC URI, <code>ldp:insertedContentRelation</code> , <code>ldp:MemberSubject</code> )</var>
 			triple, but LDP imposes no requirement to materialize such a triple in representations.
+			The value <code>ldp:MemberSubject</code> means that the 
+			<var>member-derived-URI</var> is the URI assigned by the server to a 
+			document it creates; for example, if the client POSTs content to a container
+			that causes the container to create a new LDPR, <code>ldp:MemberSubject</code> says
+			that the <var>member-derived-URI</var> is the URI assigned to the newly created LDPR.
 		</h2></section>
 	</section><!-- Was 5.2.10 / #ldpc-5_2_10 -->
 	
@@ -1917,35 +1917,37 @@
 		only when a LDPC supports that method.  This specification does not impose any
 		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
 		
-	<section id="ldpc-del-contremovesmbrtriple"><h2 class="normal">When a LDPC member resource originally created by the LDPC (for example, one whose representation
-	    was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server is aware of the member's deletion
-		(for example, the member is managed by the same server), the LDPC server MUST also remove it from
-		the LDPC by removing the corresponding membership triple.
-	</h2></section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
-	
-	<section id="ldpc-del-mbrremovesmbrtriple"><h2 class="normal">When a <a>LDP server</a> successfully completes a <code>DELETE</code> request 
-		on a LDPC member resource, it MUST remove any
-		membership triples associated with the deleted member resource identified by the <code>Request-URI</code>.
+	<section id="ldpc-del-contremovesmbrtriple"><h2 class="normal">
+		When a LDPC contained resource is deleted, the LDPC server MUST also remove it from
+		the LDPC by removing the corresponding containment and membership triples.
 	</h2>
 	<blockquote>
-		Non-normative note: The <a>LDP server</a> might perform additional removal 
-		of member resources, as described in the <a href="#ldp-http-method-side-effects">normative references</a> like [[HTTP11]]. 
+		Non-normative note: The <a>LDP server</a> might perform additional actions, 
+		as described in the <a href="#ldp-http-method-side-effects">normative references</a> like [[HTTP11]]. 
 		For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not
 		been accessed for some period of time.
 	</blockquote>
-	</section><!-- Was 5.6.2 / #ldpc-5_6_2 -->
+	</section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
 	
-	<!-- TODO: No net diff between previous 2 clauses (old-5.6.1 and old-5.6.2), so combine -->
+	<!-- combined with clause above
+	<section id="ldpc-del-mbrremovesmbrtriple"><h2 class="normal">
+	When a <a>LDP server</a> successfully completes a <code>DELETE</code> request 
+		on a LDPC member resource, it MUST remove any
+		membership triples associated with the deleted member resource identified by the <code>Request-URI</code>.
+	</h2>	</section><!-- Was 5.6.2 / #ldpc-5_6_2 -->
+	
 	<!-- TODO: All these constraints apply only to LDPC contained resources being deleted, so clarify that up front of the section hey? -->
 	
-	<section id="ldpc-del-ldpcreated"><h2 class="normal">When the conditions in <a href="#ldpc-del-contremovesmbrtriple">previous section</a> hold, and the LDPC tracks member 
+	<!-- containment now required, handled in clause above
+	<section id="ldpc-del-ldpcreated"><h2 class="normal">
+		When the conditions in <a href="#ldpc-del-contremovesmbrtriple">previous section</a> hold, and the LDPC tracks member 
 		resources that it created using the <code>ldp:contains</code> predicate, the LDPC server MUST also remove 
 		the deleted member's <code>ldp:contains</code> triple.
 	</h2></section><!-- Was 5.6.3 / #ldpc-5_6_3 -->
 	
-	<section id="ldpc-del-contremovesmbrres"><h2 class="normal">When a LDPC member resource originally created by the LDPC (for example, one whose 
-	representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server 
-	created an associated LDPR (see the <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>), the LDPC server MUST also remove the associated LDPR it created.
+	<section id="ldpc-del-contremovesmbrres"><h2 class="normal">
+	When a LDPC contained resource is deleted, and the LDPC server 
+	created an associated LDP-RR (see the <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>), the LDPC server MUST also remove the associated LDP-RR it created.
 	</h2></section><!-- Was 5.6.4 / #ldpc-5_6_4 -->
 	
 </section>
@@ -2312,6 +2314,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-02-06 - partial first pass at arnaud's email comments (JA)</li>
 	<li>2014-02-06 - fixing containment def, adding containment triples to terminology (JA)</li>
 	<li>2014-02-06 - fixing POST to create containment/membership triples, which was mangled (JA)</li>
 	<li>2014-02-06 - fully aligning SS changes with http://www.w3.org/2012/ldp/wiki/Containers for basic containers, allowing them to omit the standard predicates in representations despite requiring behavior consistent with the presence of those triples (JA)</li>