ldp.html
changeset 465 26eb1d6d4fd6
parent 464 77fd28c9eb94
child 466 7b840138bdf1
--- a/ldp.html	Thu Feb 06 13:14:15 2014 -0500
+++ b/ldp.html	Thu Feb 06 15:36:17 2014 -0500
@@ -329,13 +329,6 @@
 	<dd>The relationship linking an LDP-RR (LDPCs are also LDP-RRs) and its member LDPRs.  
 	There often is a linked LDPC that assists with managing the member LDPRs.<p></p></dd>
 
-	<dt><dfn>Containment</dfn></dt>
-	<dd>The relationship binding an LDPC to its contained LDPRs.  The
-	lifecycle of the contained LDPR is limited by the lifecycle of the containing LDPC;
-	that is, a contained LDPR cannot be created before its containing LDPC exists, nor
-	does a contained LDPR continue to exist after its containing LDPC is deleted.
-	<p></p></dd>
-
 	<dt><dfn>Membership triples</dfn></dt>
 	<dd>A set of triples in an LDPC's state that lists its members.
 		A container's membership triples all have one of the following patterns:
@@ -368,6 +361,18 @@
 	<dd>The predicate of all a LDPC's <a title="Membership triples">membership triples</a>.
 	<p></p></dd>
 	
+	<dt><dfn>Containment</dfn></dt>
+	<dd>The relationship binding an LDPC to LDPRs whose lifecycle it controls and is aware of.  The
+	lifecycle of the contained LDPR is limited by the lifecycle of the containing LDPC;
+	that is, a contained LDPR cannot be created (through LDP-defined means) before its containing LDPC exists.
+	<p></p></dd>
+
+	<dt><dfn>Containment triples</dfn></dt>
+	<dd>
+	A set of triples in an LDPC's state, maintained by the LDPC, that lists documents created by the LDPC but not yet deleted.
+	These triples <strong>always</strong> have the form: <var>( LDPC URI, ldp:contains , document-URI )</var>.
+	<p></p></dd>
+
 	<dt><dfn>Non-member resource</dfn></dt>
 	<dd>A HTTP resource associated with a LDPC by a server for the purpose of enabling clients to
 	retrieve a subset of the LDPC's state, namely the subset that omits the LDPC's membership triples.
@@ -1298,9 +1303,9 @@
    	 
 &lt;advisorContainer/&gt;
    a ldp:Container, ldp:IndirectContainer;
-   dcterms:title "The assets of JohnZSmith";
+   dcterms:title "The asset advisors of JohnZSmith";
    ldp:containerResource &lt;&gt;;
-   ldp:containsRelation o:asset;
+   ldp:containsRelation o:advisor;
    ldp:insertedContentRelation foaf:primaryTopic;
    ldp:contains
    	 &lt;advisorContainer/bob&gt;,
@@ -1540,20 +1545,23 @@
 	<!-- TODO: Leaving this as-is, refining others as-needed.  Do we need an explicit clause for "ldp:contains"?
 	  -->
 	
-	<section id="ldpc-containres"><h2 class="normal">An LDPC representation MUST contain exactly one triple 
+	<section id="ldpc-containres"><h2 class="normal">Each <a title="Linked Data Platform Direct Container">LDP Direct Container</a>
+		and <a title="Linked Data Platform Indirect Container">LDP Indirect Container</a> representation MUST contain exactly one triple 
 		whose subject is the LDPC URI, 
 		whose predicate is the <code>ldp:containerResource</code>, 
-		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 except for <a title="Linked Data Platform Basic Container">LDP-BCs</a>.
+		and whose object is the LDPC's <var>membership-constant-URI</var>.
+		Commonly the LDPC's URI is the <var>membership-constant-URI</var>, but LDP does not require this.
 	</h2>
-		<section id="ldpc-containres-basic"><h2 class="normal">For <a title="Linked Data Platform Basic Container">LDP-BCs</a>, the triple MUST be
-			where the subject is the LDPC URI,
-			whose predicate is the <code>ldp:containerResource</code>, 
-			and whose object is the LDPC URI itself.
+		<section id="ldpc-containres-basic"><h2 class="normal"><a title="Linked Data Platform Basic Container">LDP-BCs</a> MUST
+			behave as if their state contains the triple 
+			whose subject is the LDPC URI, 
+			whose predicate is <code>ldp:containerResource</code>, 
+			and whose object is the LDPC URI (subject and object are the same URI), 
+			but there is no requirement to materialize this triple in LDP-BC representations.
 		</h2></section>
 	</section><!-- Was 5.2.4 / #ldpc-5_2_4 -->
 	
-	<section id="ldpc-containtriples"><h2 class="normal">An <a title="Linked Data Platform Direct Container">LDP Direct Container</a>
+	<section id="ldpc-containtriples"><h2 class="normal">Each <a title="Linked Data Platform Direct Container">LDP Direct Container</a>
 		and <a title="Linked Data Platform Indirect Container">LDP Indirect Container</a> representation MUST contain exactly one triple 
 		whose subject is the LDPC URI, 
 		and whose predicate is either <code>ldp:containsRelation</code> or <code>ldp:containedByRelation</code>. 
@@ -1570,9 +1578,17 @@
 		pattern is <var>( membership-constant-URI , membership-predicate , member-derived-URI )</var> MUST
 		contain exactly one triple
 		whose subject is the LDPC URI, 
-		whose predicate is either <code>ldp:containsRelation</code>, 
+		whose predicate is <code>ldp:containsRelation</code>, 
 		and whose object is the URI of <var>membership-predicate</var>.
-	</h2></section><!-- Was 5.2.5.1 / #ldpc-5_2_5_1 -->
+	</h2>
+			<section id="ldpc-containtriple-basic"><h2 class="normal"><a title="Linked Data Platform Basic Container">LDP-BCs</a> MUST
+			behave as if their state contains the triple 
+			whose subject is the LDPC URI, 
+			whose predicate is <code>ldp:containsRelation</code>, 
+			and whose object is <code>ldp:member</code>,
+			but there is no requirement to materialize this triple in LDP-BC representations.
+		</h2></section>
+	</section><!-- Was 5.2.5.1 / #ldpc-5_2_5_1 -->
 	
 	<section id="ldpc-containtriple-byrelation"><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) 
@@ -1593,13 +1609,13 @@
 		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>, the URI <code>ldp:MemberSubject</code> the
-		<var>member-derived-URI</var> is simply the URI assigned by the server to a 
-		document it creates; for example, if the client POSTs RDF content to a container
+		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.
-		LDPCs MUST use the URI <code>ldp:MemberSubject</code> when the <var>member-derived-URI</var>
-		is chosen in this way.
 		</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 
@@ -1614,6 +1630,12 @@
 		that the <var>member-derived-URI</var> is <var>bob#me</var>.  
 		</li>
 		</ul>
+
+		<section id="ldpc-indirectmbr-basic"><h2 class="normal">
+			<a title="Linked Data Platform Basic Container">Basic</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.
+		</h2></section>
 	</section><!-- Was 5.2.10 / #ldpc-5_2_10 -->
 	
 	<section id="ldpc-linktypehdr"><h2 class="normal"><a title="LDP server">LDP servers</a>
@@ -1732,12 +1754,20 @@
 		entity body on a 201 (Created) response.
 	</h2></section><!-- Was 5.4.1 / #ldpc-5_4_1 -->
 
-	<section id="ldpc-post-createdmbr"><h2 class="normal">After a successful HTTP <code>POST</code> request to a LDPC, 
+	<section id="ldpc-post-createdmbr-contains"><h2 class="normal">
+		When a successful HTTP <code>POST</code> request to a LDPC
+		results in the creation of an LDPR, 
 		the newly created document MUST
 		appear as a contained resource of the LDPC until the newly created document is deleted or
-		removed by other methods. An LDPC's membership MAY also include resources that were
-		added through other means - for example through the user interface of
-		the site that implements the LDPC.
+		removed by other methods. 
+	</h2></section>
+	
+	<section id="ldpc-post-createdmbr-member"><h2 class="normal">
+		When a successful HTTP <code>POST</code> request to a 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.
+		A Direct or Indirect container's membership triples MAY also be modified via 
+		through other means. 
 	</h2></section><!-- Was 5.4.2 / #ldpc-5_4_2 -->
 	
 	<!-- TODO: "contained resource" is not the right term here, an example of where ldp:containedResource would be better
@@ -1746,13 +1776,13 @@
 	
 	<section id="ldpc-post-createbins"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY accept an HTTP <code>POST</code> of non-RDF representations 
 	<a title="Linked Data Platform Binary Resource">(LDP-BRs)</a> for
-		creation of any kind of resource, for example binary resources.  See <a href="#ldpc-post-acceptposthdr">AcceptPost section</a> for 
+		creation of any kind of resource, for example binary resources.  See <a href="#ldpc-post-acceptposthdr">the Accept-Post section</a> for 
 		details on how clients can discover whether a LDPC supports this behavior.
 	</h2></section><!-- Was 5.4.3 / #ldpc-5_4_3 -->
 	
 	<section id="ldpc-post-createrdf"><h2 class="normal"><a title="LDP server">LDP servers</a> 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
-		MUST be an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[rdf11-concepts]].
+		can be thought of as an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[rdf11-concepts]].
 		If any model cannot be honored, the server MUST fail the request.
 	</h2><!-- Was 5.4.4 / #ldpc-5_4_4 -->
 	<ul>
@@ -1876,7 +1906,7 @@
 	    
 	<section id="ldpc-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> that allow member creation via <code>PUT</code> 
 		SHOULD NOT re-use URIs.  For RDF representations (LDP-RRs),the created resource
-		MUST be an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[rdf11-concepts]].
+		can be thought of as a RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[rdf11-concepts]].
 	</h2></section><!-- Was 5.5.4 / #ldpc-5_5_4 -->
 	
 </section>
@@ -1905,6 +1935,9 @@
 	</blockquote>
 	</section><!-- Was 5.6.2 / #ldpc-5_6_2 -->
 	
+	<!-- TODO: No net diff between previous 2 clauses (old-5.6.1 and old-5.6.2), so combine -->
+	<!-- 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 
 		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.
@@ -2279,6 +2312,10 @@
 <!-- <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 - 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>
+	<li>2014-02-06 - editorial fixes (JA)</li>
 	<li>2014-02-06 - ACTION-127 (complete) use the TAG's new [23]xx code; if that code is not sufficiently through IETF process by CR, we will use a 303 (JA)</li>
 	<li>2014-02-05 - ACTION-133 Get rid of ldp:created which is subsumed by ldp:contains (SS)</li>
 	<li>2014-02-04 - ACTION-124 LDPR-RR as named graphs  (SS)</li>