ISSUE-72 adding 5.2.10 for ldp:membershipObject
authorsspeiche
Wed, 10 Jul 2013 10:26:24 -0400
changeset 179 9d563e756b28
parent 177 584588474886
child 180 5c0da415b275
ISSUE-72 adding 5.2.10 for ldp:membershipObject
ldp.html
--- a/ldp.html	Tue Jul 09 22:30:00 2013 -0500
+++ b/ldp.html	Wed Jul 10 10:26:24 2013 -0400
@@ -286,11 +286,11 @@
 
 <p>A conforming <b>LDP Server</b> is an application program that processes HTTP 
 requests and generates HTTP responses that conform to the rules defined in sections on <a href="#linked-data-platform-resources">LDPRs</a>
-and <a href="#linked-data-platform-containers">LDPCs</a></p>.
+and <a href="#linked-data-platform-containers">LDPCs</a>.</p>
 
 <p>A conforming <b>LDP Client</b> is an application program that generates HTTP 
 requests and processes HTTP responses that conform to the rules defined in sections on <a href="#linked-data-platform-resources">LDPRs</a>
-and <a href="#linked-data-platform-containers">LDPCs</a></p>.
+and <a href="#linked-data-platform-containers">LDPCs</a>.</p>
 
 </section>
 
@@ -1084,8 +1084,6 @@
 			triples whose subject is the LDPC resource itself.
 	</p>
 	
-	<!-- @@@ TODO: ISSUE-72 sample for membershipObject-->
-	
 	<div id="ldpc-member_data" class="rule">5.1.1 Container Member Information</div>
 	<em>This section is non-normative</em>
 	<p>In many – perhaps most – applications
@@ -1266,8 +1264,6 @@
 		</p>
 </section>
 
-	<!-- @@@ TODO: ISSUE-72 new section just for membershipObject?-->
-
 <section>
 <h2 id="ldpc-general">General</h2>
 	<p>The Linked Data Platform does not define how clients
@@ -1358,7 +1354,46 @@
 		scenarios, re-using URIs creates ambiguities for clients that are best avoided.
 	</div>
 	
-	<!-- @@@ TODO: ISSUE-72 rules for membershipObject-->
+
+	<div id="ldpc-5_2_10" class="rule">5.2.10 Some LDPC's have membership object's that are not directly
+	    URIs minted upon LDPC member creation, for example hash URIs [[RFC3986]]. To determine which object URI to use for the
+	    membership triple, LDPC's MUST contain triple whose subject is the LDPC URI, predicate is <code>ldp:membershipObject</code>,
+	    with an object <var>MO</var>. Where <var>MO</var> can be used to locate a triple of the form: <var>(LDPC URI, MO, N)</var> and 
+	    where <var>N</var> can be used to construct the membership triple of the form: <var>(membership subject, membership predicate, N)</var>.
+	    When <code>ldp:membershipPredicateInverse</code> is used instead of <code>ldp:membershipPredicate</code>, the membership triple MUST be
+	    of the form: <var>(N, membership predicate, membership subject)</var>.
+	</div>
+	<div class="ldp-issue-pending">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/72">ISSUE-72</a></div>
+	edited in ldp:membershipObject in new previous section
+	</div>	
+	
+	
+	<!-- NOTE: Saving this sample to help with future editing/understanding or possible insertion directly.
+	
+	Let's say this LDPC has a membershipSubject of </people/roger> and membershipPredicate of pets:has_pet. If I POST the following to the LDPC: 
+
+	<> foaf:primaryTopic <#this> .
+	<#this> 
+	  a animal:Cat; 
+	  foaf:name "Zaza".
+	
+	... a new resource is created and there is a new membership triple of 
+	
+	</people/roger> pets:has_pet </people/roger/zaza>.
+	
+	but the desired one is:
+	
+	</people/roger> pets:has_pet </people/roger/zaza#this>.
+		
+	To do this, you'd have to use ldp:membershipObject such as:
+	
+	pets:has_pet 
+	   a ldp:Container;
+	   ldp:membershipPredicate pets:has_pet;
+	   ldp:membershipSubject </people/roger>;
+	   ldp:membershipObject foaf:primaryTopic .
+	 -->
 	
 </section>
 
@@ -1612,23 +1647,6 @@
 		it MAY add other triples as well.
 	</div>
 	
-	<!-- @@@ TODO: ISSUE-72 creation requirements with membershipObject
-	
-	- do we need to handle membershipPredicateInverse with membershipObject (my head hurts)?
-	- we don't have membershipPredicateInverse in samples/intro, treat membershipObject same?
-	- what happens when a client POSTs w/o the triple to indicate membershipObject, guess we 
-	  just default to if mO is omitted (ie server gets to pick)
-	- since we have ldp:membershipSubject and ldp:membershipPredicate which help a client know
-	  what is used to determine membership....ldp:membershipObject is *different* in that it
-	  tells clients what triple to insert of the form:
-	     <> {membershipObject} <#me>.
-	- do we need to make rules about POSTed triples like:
-	     <> {mO} <http://someotherserver.com/foo>.
-	  these seem not like intended behavior but "could" work
-	  
-	-->
-	
-	
 </section>
 
 <section>
@@ -1933,6 +1951,7 @@
 <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130701/">Third Public Working Draft</a></em></blockquote>
 -->
 <ul>
+	<li>2013-07-10 - ISSUE-72 adding 5.2.10 for ldp:membershipObject (SS)</li>
 	<li>2013-07-09 - ISSUE-58 inlining - actions 87-89 inclusive  (JA)</li>
 	<li>2013-07-08 - Moved 5.7.* sections out of HEAD and into OPTIONS as 5.9.*, added 4.6.2 (SS)</li>
 	<li>2013-07-08 - ISSUE-15 Inserted 5.4.12, 5.6.4, 5.7.2 to describe link-relation meta usage (SS)</li>