ldp.html
changeset 176 60b0a09af2c4
parent 175 bcc13fba2593
child 178 0ec347702232
child 179 9d563e756b28
--- a/ldp.html	Tue Jul 09 18:13:39 2013 -0400
+++ b/ldp.html	Tue Jul 09 20:40:55 2013 -0400
@@ -1084,6 +1084,8 @@
 			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
@@ -1264,6 +1266,8 @@
 		</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
@@ -1354,6 +1358,8 @@
 		scenarios, re-using URIs creates ambiguities for clients that are best avoided.
 	</div>
 	
+	<!-- @@@ TODO: ISSUE-72 rules for membershipObject-->
+	
 </section>
 
 <section>	
@@ -1606,6 +1612,22 @@
 		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>