--- 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>