ldp.html
changeset 415 12864dde579d
parent 414 a5d0c19a9474
child 416 166375df8bf8
--- a/ldp.html	Tue Nov 12 13:27:44 2013 -0500
+++ b/ldp.html	Tue Nov 12 17:18:32 2013 -0500
@@ -1,6 +1,7 @@
 <!DOCTYPE html>
 <!-- 
  Editor TODO:
+	- Convert cases like 5.4.3 to a sectionRef ... search on sectionRef in case numbers change
    - Once companion documents have URLs, link to them.  Search on "companion".
    - In #ldpr-HTTP_POST, move "Clients can create LDPRs via" content into an intro/overview section and add PATCH.
    - Once the membership* names stabilize, take a pass through for "membership consistent value", membership-constant-URI
@@ -21,8 +22,8 @@
     - 	The ReSpec SPARQL QUERY link is http://www.w3.org/TR/rdf-sparql-query/ , which has highlighted text
 	referring readers to SPARQL 1.1.  Which normative reference do we want?
  Various pre-LC comments:
-    - 5.2.5.1 For a given triple T with a subject C of the LDPC and predicate of ldp:membershipPredicate, 
-	  5.2.5.2 For a given triple T with a subject C of the LDPC and predicate of ldp:membershipPredicateInverse, 
+    - 5.2.5.1 For a given triple T with a subject C of the LDPC and predicate of ldp:containsRelation, 
+	  5.2.5.2 For a given triple T with a subject C of the LDPC and predicate of ldp:containedByRelation, 
 	  5.2.10 Some LDPC's have membership object's that are not directly URIs minted upon LDPC member creation, 
 	  (JohnA) I found these particularly hard to read.  And I perpetrated the SortCollation paragraphs.  
 	  Links to examples might be an 80-20 solution. 
@@ -233,8 +234,8 @@
 		</li>
 		<li>Include links to other URIs, so that they can discover more things</li>
 	</ol>
-	<p>This specification discusses standard HTTP and RDF techniques that you 
-	should use when constructing clients and servers that 
+	<p>This specification discusses standard HTTP and RDF techniques  
+	used when constructing clients and servers that 
 	create, read, and write <a title="Linked Data Platform Resource">Linked Data Platform Resources</a>.
 	A companion document discusses best practices that you 
 	should use, and anti-patterns you should avoid, when constructing these clients and servers.
@@ -242,7 +243,8 @@
 	<p>This specification provides a widely re-usable pattern to deal with large resources.  
 	Depending on the server’s capabilities, a GET request on a <a title="Paged resource">resource</a> can
 	return a <a title="Single-page resource">subset of the resource (one page)</a>, that provides access to subsequent pages 
-	(see <a href="#ldpr-Paging" class="sectionRef"></a>). </p>
+	(see <a href="#ldpr-Paging" class="sectionRef"></a>). 
+	</p>
 	<p>This specification defines a special type of <a>Linked Data Platform Resource</a>: a 
 	<a title="Linked Data Platform Container">Container</a>.  Containers are very useful 
 	in building application models involving collections of resources, often homogeneous ones. 
@@ -302,23 +304,24 @@
 		<tr>
 		<td style="padding:0 0 0 +2ex"> <var style="background:#DDDDDD">membership-constant-URI</var> </td>
 		<td style="padding:0 0 0 +2ex"> <var>membership-predicate</var> </td>
-		<td style="padding:0 0 0 +2ex"> <var style="background:#CCFFFF">member-URI</var> </td>
+		<td style="padding:0 0 0 +2ex"> <var style="background:#CCFFFF">member-derived-URI</var> </td>
 		</tr>
 		<tr>
-		<td style="padding:0 0 0 +2ex"> <var style="background:#CCFFFF">member-URI</var> </td>
+		<td style="padding:0 0 0 +2ex"> <var style="background:#CCFFFF">member-derived-URI</var> </td>
 		<td style="padding:0 0 0 +2ex"> <var>membership-predicate</var> </td>
 		<td style="padding:0 0 0 +2ex"> <var style="background:#DDDDDD">membership-constant-URI</var> </td>
 		</tr>
 		</table>
-		The difference between the two is simply which position member-URI occupies, which is usually
+		The difference between the two is simply which position member-derived-URI occupies, which is usually
 		driven by the choice of <var>membership-predicate</var>.  Most predicates have a natural forward direction
 		inherent in their name, and existing vocabularies contain useful examples that read naturally in
 		each direction.  <code>rdfs:member</code> and <code>dcterms:isPartOf</code> are representative examples.
 		<p>
-		Each container exposes properties that allow clients to determine which pattern it
+		Each container exposes properties (see <a href="#ldpc-general" class="sectionRef"></a>)
+		that allow clients to determine which pattern it
 		uses, what the actual <var>membership-predicate</var> and <var>membership-constant-URI</var> values are, 
 		and (for containers that allow the creation of new members) what value is used
-		for the <var>member-URI</var> based on the client's input to the 
+		for the <var>member-derived-URI</var> based on the client's input to the 
 		creation process.</p>
 	<p></p></dd>
 	
@@ -327,7 +330,7 @@
 	<p></p></dd>
 	
 	<dt><dfn>Non-member resource</dfn></dt>
-	<dd>A resource associated with a LDPC by a server for the purpose of enabling clients to
+	<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.
 	In other words, the union of the non-member resource's state and the LDPC's membership triples
 	exactly equals the LDPC's state.
@@ -343,7 +346,7 @@
 	a subset of the triples in <var>P</var>.
 	LDP allows paging of resources other than LDPRs, but does not specify how clients combine
 	their representations.  See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.  For readers
-	familiar with paged feeds [[!RFC5005]], a paged resource is similar to a logical feed.
+	familiar with paged feeds [[RFC5005]], a paged resource is similar to a logical feed.
 	Any resource could be considered to be a paged resource consisting of exactly one page, 
 	although there is no known advantage in doing so.
 	<p></p></dd>
@@ -353,7 +356,7 @@
 	each of which contains a subset of the state
 	of another resource <var>P</var>.  <var>P</var> is called the paged resource.
 	For readers
-	familiar with paged feeds [[!RFC5005]], a single-page resource is similar to a feed document and the same
+	familiar with paged feeds [[RFC5005]], a single-page resource is similar to a feed document and the same
 	coherency/completeness considerations apply.
 	<a href="#ldpr-pagingGET-sequences-change">LDP provides no guarantees that the sequence is stable</a>.
 	</p><p>
@@ -375,7 +378,7 @@
 	<dd>A link to the next <a title="Single-page resource">single-page resource</a> 
 	of a <a title="Paged resource">paged resource</a> <var>P</var>.  Syntactically, a
 	HTTP <code>Link &lt;<var>P<sub>i</sub></var>&gt;; rel='next'</code>
-	header [[!RFC5988]] where <var>i=2...n</var>.
+	header [[!RFC5988]] where the target URI is <var>P<sub>i=2...n</sub></var>.
 	<p></p></dd>
 	
 	<dt><dfn>last page link</dfn></dt>
@@ -389,7 +392,7 @@
 	<dd>A link to the previous <a title="Single-page resource">single-page resource</a> 
 	of a <a title="Paged resource">paged resource</a> <var>P</var>.  Syntactically, a
 	HTTP <code>Link &lt;<var>P<sub>i</sub></var>&gt;; rel='prev'</code>
-	header [[!RFC5988]] where <var>i=1...n-1</var>.
+	header [[!RFC5988]] where the target URI is <var>P<sub>i=1...n-1</sub></var>.
 	<p></p></dd>
 	
   </dl>
@@ -447,56 +450,6 @@
 LDP does not constrain its behavior when serving other HTTP resources.
 </p>
 
-<p>(NEW) LDP defines several classes of LDP servers, and places different conformance requirements on each of them.
-NOTE: "Basic" and "advanced" used here for drafting purposes; they correspond to 'vanilla' and 'chocolate', respectively.
-Final names TBD.
-</p>
-<ul>
-  <li><p>A conforming <b><dfn>basic LDP server</dfn></b> is a conforming LDP server that follows the rules defined by LDP
-  for basic LDP servers, as shown below.  Its content model is generally open and the server typically stores triples on behalf of clients
-  with minimal (if any) restrictions.
-  </p></li>
-  <li><p>A conforming <b><dfn>advanced LDP server</dfn></b> is a conforming LDP server that follows the rules defined by LDP
-  for advanced LDP servers, as shown below.  Its content model can be open or closed, and the server may impose non-trivial
-  restrictions on triples stored on behalf of conforming HTTP clients.
-  </p></li>
-</ul>
-
-<section>
-<h5>Example conformance rules</h5>
-
-<p>The following informative examples show how LDP assigns conformance criteria to each class of LDP servers using a single rule.</p>
-
-<section>
-<h6>Example: the same criteria apply to both basic and advanced LDP servers</h6>
-<div class="example">
-	<div class="rule">LDP servers SHOULD ...  </div>
-</div>
-
-<p>The preceding rule is equivalent to the following pair of rules:</p>
-<div class="example">
-	<div class="rule">Basic LDP servers SHOULD ...  </div>
-	<div class="rule">Advanced LDP servers SHOULD ...  </div>
-</div>
-</section>
-
-<section>
-<h6>Example: different criteria apply to basic and advanced LDP servers</h6>
-<p>Trying out different ways of covering each class while minimizing text duplication here.  Final format TBD.</p>
-<div class="example">
-	<div class="rule">(proposal 1) LDP servers MUST (basic)/SHOULD (advanced) ... </div>
-	<div class="rule">(proposal 2) Basic LDP servers MUST, and advanced LDP servers SHOULD, ... </div>
-	<div class="rule">(proposal 3) Basic LDP servers MUST ... .  Advanced LDP servers SHOULD do so. </div>
-</div>
-
-<p>Each of the preceding rules is equivalent to the following pair of rules:</p>
-<div class="example">
-	<div class="rule">4.8.2 Basic LDP servers MUST ...
-	</div>
-	<div class="rule">4.8.2 Advanced LDP servers SHOULD  ...
-	</div>
-</div>
-</section>
 
 </div>
 
@@ -1139,12 +1092,12 @@
 		be a predicate from the server application vocabulary or the <code>rdfs:member</code> predicate.
 	</p>
 	<p>This document includes a set of guidelines for
-		using POST to create new resources and add them to the list of
+		creating new resources and adding them to the list of
 		members of a container. It goes on to explain how to learn about a set of related
-		resources, they may have been created using POST or through other means.
-		It also defines behavior when POST created resources are deleted, to clean up
-		container membership, and deleting containers removes membership information and
-		possibly perform some cleanup tasks on unreferenced member resources.</p>
+		resources, regardless of how they were created or added to the container's membership.
+		It also defines behavior when resources created using a container are later deleted;
+		deleting containers removes membership information and
+		possibly performs some cleanup tasks on unreferenced member resources.</p>
 
 	<p>The following illustrates a very simple
 		container with only three members and some information about the
@@ -1160,9 +1113,9 @@
 
 &lt;&gt;
    a ldp:Container;
-   ldp:membershipSubject &lt;&gt; ;
-   ldp:membershipPredicate rdfs:member;
-   ldp:membershipObject ldp:MemberSubject;
+   ldp:containerResource &lt;&gt; ;
+   ldp:containsRelation rdfs:member;
+   ldp:insertedContentRelation ldp:MemberSubject;
    dcterms:title "A very simple container";
    rdfs:member &lt;member1&gt;, &lt;member2&gt;, &lt;member3&gt;.</pre>
 
@@ -1225,16 +1178,16 @@
 &lt;assetContainer/&gt;
    a ldp:Container;
    dcterms:title "The assets of JohnZSmith";
-   ldp:membershipSubject &lt;&gt;;
-   ldp:membershipPredicate o:asset;
-   ldp:membershipObject ldp:MemberSubject.
+   ldp:containerResource &lt;&gt;;
+   ldp:containsRelation o:asset;
+   ldp:insertedContentRelation ldp:MemberSubject.
 
 &lt;liabilityContainer/&gt;
    a ldp:Container;
    dcterms:title "The liabilities of JohnZSmith";
-   ldp:membershipSubject &lt;&gt;;
-   ldp:membershipPredicate o:liability;
-   ldp:membershipObject ldp:MemberSubject.
+   ldp:containerResource &lt;&gt;;
+   ldp:containsRelation o:liability;
+   ldp:insertedContentRelation ldp:MemberSubject.
 </pre>
 
 	<p>The essential structure of the container is
@@ -1262,9 +1215,9 @@
 
 &lt;&gt;
    a ldp:Container;
-   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
-   ldp:membershipPredicate o:asset;
-   ldp:membershipObject ldp:MemberSubject.
+   ldp:containerResource &lt;http://example.org/netWorth/nw1&gt;;
+   ldp:containsRelation o:asset;
+   ldp:insertedContentRelation ldp:MemberSubject.
 
 &lt;http://example.org/netWorth/nw1&gt;
    a o:NetWorth;
@@ -1275,54 +1228,8 @@
 			triples whose subject is the LDPC resource itself.
 	</p>
 	
-	<div id="ldpc-member_data" class="rule informative">5.1.1 Container Member Information</div>
-	<p>In many – perhaps most – applications
-		involving containers, it is desirable for the client to be able to
-		get information about each container member without having to do a
-		GET on each one. LDPC allows servers to include this information
-		directly in the representation of the container. The server decides
-		the amount of data about each member that is provided. Some common
-		strategies include providing a fixed number of standard properties,
-		or providing the entire RDF representation of each member resource,
-		or providing nothing. The server application domain and its use-cases
-		will determine how much information is required.</p>
-
-	<p>Continuing on from the net worth
-		example, there will be additional triples for the member resources
-		(assets) in the representation:</p>
-
-<pre class="example"># The following is the representation of
-#	 http://example.org/netWorth/nw1/assetContainer/
-<!-- @base is here only so it's easier to paste into validators for checking -->
-# @base &lt;http://example.org/netWorth/nw1/assetContainer/&gt;
-@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
-@prefix ldp:      &lt;http://www.w3.org/ns/ldp#&gt;.
-@prefix o:       &lt;http://example.org/ontology/&gt;.
 
-&lt;&gt;
-   a ldp:Container;
-   dcterms:title "The assets of JohnZSmith";
-   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
-   ldp:membershipPredicate o:asset;
-   ldp:membershipObject ldp:MemberSubject.
-
-&lt;http://example.org/netWorth/nw1&gt;
-   a o:NetWorth;
-   o:asset &lt;a1&gt;, &lt;a3&gt;, &lt;a2&gt;.
-
-&lt;a1&gt;
-   a o:Stock;
-   o:value 10000 .
-&lt;a2&gt;
-   a o:Bond;
-   o:value 20000 .
-&lt;a3&gt;
-   a o:RealEstateHolding;
-   o:value 300000 .</pre>
-	<p>In a similar manner, when the representation for the resource of asset <var>.../&lt;a1&gt;</var> is returned a 
-	server may include the membership triple of the form <var>(.../nw1, o:asset, .../a1).</var></p>
-
-	<div id="ldpc-get_non-member_props" class="rule">5.1.2 Retrieving Only Non-member Properties
+	<div id="ldpc-get_non-member_props" class="rule">5.1.1 Retrieving Only Non-member Properties
 	</div>
 	<p>The representation of a container
 		that has many members will be large. There are several important
@@ -1362,15 +1269,15 @@
 &lt;http://example.org/container1/&gt;
    a ldp:Container;
    dcterms:title "A Linked Data Platform Container of Acme Resources";
-   ldp:membershipSubject &lt;http://example.org/container1/&gt;;
-   ldp:membershipPredicate rdfs:member;
-   ldp:membershipObject ldp:MemberSubject;
+   ldp:containerResource &lt;http://example.org/container1/&gt;;
+   ldp:containsRelation rdfs:member;
+   ldp:insertedContentRelation ldp:MemberSubject;
    dcterms:publisher &lt;http://acme.com/&gt;.</pre>
    
 	<p>While the same non-member resource could be used to update the non-member properties via PUT,
 		LDP recommends using PATCH for this purpose.</p>
 
-	<div id="ldpc-ordering" class="rule">5.1.3 Ordering</div>
+	<div id="ldpc-ordering" class="rule">5.1.2 Ordering</div>
 	<p>
 		There are many cases where an ordering of the members of the
 		container is important. LDPC does not provide any particular support
@@ -1418,9 +1325,9 @@
 &lt;&gt;
    a ldp:Container;
    dcterms:title "The assets of JohnZSmith";
-   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
-   ldp:membershipPredicate o:asset;
-   ldp:membershipObject ldp:MemberSubject.
+   ldp:containerResource &lt;http://example.org/netWorth/nw1&gt;;
+   ldp:containsRelation o:asset;
+   ldp:insertedContentRelation ldp:MemberSubject.
 
 &lt;?firstPage&gt;
    a ldp:Page;
@@ -1470,50 +1377,68 @@
 	</div>
 	-->
 	<div id="ldpc-5_2_3" class="rule">5.2.3 <a title="LDP server">LDP servers</a>
-		SHOULD use the <code>rdfs:member</code> predicate
-		If there is no obvious predicate from an application vocabulary to use.
+		SHOULD use the <code>rdfs:member</code> predicate as an LDPC's <a title="Membership predicate">membership predicate</a>
+		if there is no obvious predicate from an application vocabulary to use.
 		The state of an LDPC includes information about which
 		resources are its members, in the form of <a title="Membership triples">membership triples</a> that
 		follow a consistent pattern.  The LDPC's state contains enough information for clients to discern
 		the <a title="Membership predicate">membership predicate</a>, the other consistent membership
-		value used in the container's membership triples, and the position (subject or object) where the member's URI
-		occurs in those triples.
+		value used in the container's membership triples (<var>membership-constant-URI</var>), 
+		and the position (subject or object) where those URIs
+		occurs in the <a title="Membership triples">membership triples</a>.
 		Member resources can be
 		any kind of resource identified by a URI, LDPR or otherwise.
 	</div>
 	<div id="ldpc-5_2_4" class="rule">5.2.4 An LDPC representation MUST contain exactly one triple 
 		whose subject is the LDPC URI, 
-		whose predicate is the <code>ldp:membershipSubject</code>, 
-		and whose object is the LDPC's membership subject 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.
 	</div>
-<div class="ldp-issue-open">
-<div class="ldp-issue-title">Issue-81: confusing predicate names</div>
-"membership subject" has been removed too.  Remove this use of it as part of Issue-81 resolution.
-</div>
 	<div id="ldpc-5_2_5" class="rule">5.2.5 An LDPC representation MUST contain exactly one triple 
 		whose subject is the LDPC URI, 
-		and whose predicate is either <code>ldp:membershipPredicate</code> or <code>ldp:membershipPredicateInverse</code>. 
+		and whose predicate is either <code>ldp:containsRelation</code> or <code>ldp:containedByRelation</code>. 
 		The object of the triple is constrained by other sections, such as
-		<a href="#ldpc-5_2_5_1">5.2.5.1</a> or <a href="#ldpc-5_2_5_2">5.2.5.2</a>.
+		<a href="#ldpc-5_2_5_1">5.2.5.1</a> or <a href="#ldpc-5_2_5_2">5.2.5.2</a>, based on the 
+		<a title="Membership triples">membership triple</a> 
+		pattern used by the container.
 	</div>
+	<div id="ldpc-5_2_5_1" class="rule">5.2.5.1 LDPCs whose <a title="Membership triples">membership triple</a> 
+		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>, 
+		and whose object is the URI of <var>membership-predicate</var>.
+	</div>
+	<!-- Action-112 rewrote this 2013-11-12, original in this comment
 	<div id="ldpc-5_2_5_1" class="rule">5.2.5.1 For a given triple <var>T</var> with a subject <var>C</var>
 	of the LDPC and predicate of 
-	<code>ldp:membershipPredicate</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
-	indicate membership to the linked to LDPC, or simply: <var>T = ( C</var>, <code>ldp:membershipPredicate</code>, <var>P)</var>. 
+	<code>ldp:containsRelation</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
+	indicate membership to the linked to LDPC, or simply: <var>T = ( C</var>, <code>ldp:containsRelation</code>, <var>P)</var>. 
 	For the membership predicate URI object used in the triple <var>T</var>, it would be found in a resource's
 	same subject <var>R</var> and same predicate <var>P</var> membership triples of the form: 
 	(<var>R</var>, <var>P</var>, <var>MR</var>), where <var>MR</var> represents URI of
 	a member resource.
 	</div>
+	-->
+	<div id="ldpc-5_2_5_2" class="rule">5.2.5.2 LDPCs whose <a title="Membership triples">membership triple</a> 
+		pattern is <var>( member-derived-URI , membership-predicate , membership-constant-URI )</var> MUST
+		contain exactly one triple
+		whose subject is the LDPC URI, 
+		whose predicate is either <code>ldp:containedByRelation</code>, 
+		and whose object is the URI of <var>membership-predicate</var>.
+	</div>
+	<!-- Action-112 rewrote this 2013-11-12, original in this comment
 	<div id="ldpc-5_2_5_2" class="rule">5.2.5.2  For a given triple <var>T</var> with a subject <var>C</var>
 	of the LDPC and predicate of 
-	<code>ldp:membershipPredicateInverse</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
-	indicate membership to the linked to LDPC, or simply: <var>T = ( C</var>, <code>ldp:membershipPredicateInverse</code>, <var>P)</var>. 
+	<code>ldp:containedByRelation</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
+	indicate membership to the linked to LDPC, or simply: <var>T = ( C</var>, <code>ldp:containedByRelation</code>, <var>P)</var>. 
 	For the membership predicate URI object used in the triple <var>T</var>, it would be found in a resource's
 	object subject <var>R</var> and same predicate <var>P</var> membership triples of the form: 
 	(<var>MR</var>, <var>P</var>, <var>R</var>), where <var>MR</var> represents URI of
 	a member resource.
 	</div>
+	-->
 	<!-- Action-108 removed this 2013-10-22
 	<div id="ldpc-5_2_6" class="rule">5.2.6 The representation of a LDPC MAY include an arbitrary number of
 		additional triples whose subjects are the members of the container,
@@ -1540,28 +1465,59 @@
 		scenarios, re-using URIs creates ambiguities for clients that are best avoided.
 	</div>
 	-->
+	<div id="ldpc-5_2_10" class="rule">5.2.10 LDPCs MUST contain 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.
+		<ul>
+		<li>
+		LDP defines the URI <code>ldp:MemberSubject</code> for the common case where
+		<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
+		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>
+		In other cases, 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 
+		the predicate <var>P</var> is present in the client's input.
+		For example, if the client POSTs RDF content to a container
+		that causes the container to create a new LDPR, and that content contains the triple 
+		<var>( <> , foaf:primaryTopic , mypet#Zaza )</var>
+		<code>foaf:primaryTopic</code> says
+		that the <var>member-derived-URI</var> is <var>mypet#Zaza</var>.  
+		</li>
+		</ul>
+	<!-- Action-112 rewrote this 2013-11-12, original in this comment
 	<div id="ldpc-5_2_10" class="rule">5.2.10 Some LDPCs have members whose URIs are not directly
 	    URIs minted upon LDPC member creation, for example URIs with a non-empty fragment identifier [[RFC3986]]. 
-	    To determine which member URI to use in the  membership triple, LDPCs MUST contain one triple whose
-	    subject is the LDPC URI, whose predicate is <code>ldp:membershipObject</code>, and whose object is <var>MO</var>. 
+	    To determine which member URI to use as the <var>member-derived-URI</var>
+		in the  membership triple, LDPCs MUST contain one triple whose
+	    subject is the LDPC URI, whose predicate is <code>ldp:insertedContentRelation</code>, and whose object is <var>MO</var>. 
 	    <var>MO</var> and the HTTP URI <var>R</var> from <code>POST</code> create 
 		(as found in HTTP response <code>Location</code> header) are 
 	    used to locate a triple in <var>R</var> of the form <var>(R, MO, N)</var>.
-		When the LDPC uses <code>ldp:membershipPredicate</code>, 
+		When the LDPC uses <code>ldp:containsRelation</code>, 
 	    <var>N</var> is then used to construct the membership triple of the form: 
 		<var>(membership consistent value, membership predicate, N)</var>.
-	    When the LDPC uses <code>ldp:membershipPredicateInverse</code>,
+	    When the LDPC uses <code>ldp:containedByRelation</code>,
 		the membership triple is
 	    of the form: <var>(N, membership predicate, membership consistent value)</var>. 
 		To indicate that the member resource URI is the membership object
 	    (the default or typical case), the object MUST be set to predefined URI <code>ldp:MemberSubject</code> 
 		such that it forms the triple: 
-	    <var>(LDPC URI, <code>ldp:membershipObject</code>, <code>ldp:MemberSubject</code>)</var>.
+	    <var>(LDPC URI, <code>ldp:insertedContentRelation</code>, <code>ldp:MemberSubject</code>)</var>.
 	</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: 
+	Let's say this LDPC has a containerResource of </people/roger> and containsRelation of pets:has_pet. If I POST the following to the LDPC: 
 
 	<> foaf:primaryTopic <#this> .
 	<#this> 
@@ -1576,13 +1532,13 @@
 	
 	</people/roger> pets:has_pet </people/roger/zaza#this>.
 		
-	To do this, you'd have to use ldp:membershipObject such as:
+	To do this, you'd have to use ldp:insertedContentRelation such as:
 	
 	pets:has_pet 
 	   a ldp:Container;
-	   ldp:membershipPredicate pets:has_pet;
-	   ldp:membershipSubject </people/roger>;
-	   ldp:membershipObject foaf:primaryTopic .
+	   ldp:containsRelation pets:has_pet;
+	   ldp:containerResource </people/roger>;
+	   ldp:insertedContentRelation foaf:primaryTopic .
 	 -->
 	
 </section>
@@ -1612,7 +1568,8 @@
 		The first list entry provides the primary
 		sorting criterion, any second entry provides a secondary criterion used to order members considered
 		equal according to the primary criterion, and so on.
-		See section <a href="#ldpc-ordering">5.1.4 Ordering</a> for
+		<!-- Convert cases like this to a sectionRef -->
+		See section <a href="#ldpc-ordering">5.1.3 Ordering</a> for
 		an example.
 	</div>
 	<div id="ldpc-5_3_3" class="rule">5.3.3 LDPC page representations 
@@ -1783,16 +1740,13 @@
 	</div>
 	<div id="ldpc-5_5_2" class="rule">5.5.2 <a title="LDP server">LDP servers</a> MAY allow updating LDPC non-membership properties using
 		HTTP <code>PUT</code> on a corresponding <a>non-member resource</a>, which
-		MAY exclude server-managed properties such as <code>ldp:membershipSubject</code>, <code>ldp:membershipPredicate</code>
-		and <code>ldp:membershipPredicateInverse</code>.
+		MAY exclude server-managed properties such as <code>ldp:containerResource</code>, <code>ldp:containsRelation</code>
+		and <code>ldp:containedByRelation</code>.
 		The <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a> describes the process by which clients
 		use HTTP <code>OPTIONS</code> to discover whether the server offers such a resource, and if so its URL. 
 	</div>
 	    
-    <div id="ldpc-5_5_3" class="rule">5.5.3 <a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> requests
-		with member resource information in the request representation.
-		See section <a href="#ldpc-member_data">5.1.1 Container
-		Member Information</a> for additional details.
+    <div id="ldpc-5_5_3" class="rule">5.5.3 removed - inlining
 	</div>
 	
 	<div id="ldpc-5_5_4" class="rule">5.5.4 <a title="LDP server">LDP servers</a> that allow member creation via <code>PUT</code> 
@@ -1869,7 +1823,8 @@
 		<a>non-member resource</a>
 		to support requests for information about a LDPC
 		without retrieving a full representation including all of its members; 
-		see section <a href="#ldpc-get_non-member_props">5.1.2 Retrieving Only Non-member Properties</a> for
+		<!-- sectionref this -->
+		see section <a href="#ldpc-get_non-member_props">5.1.1 Retrieving Only Non-member Properties</a> for
 		examples. 
 		In responses to <code>OPTIONS</code> requests with an LDPC as the <code>Request-URI</code>, 
 		<a title="LDP server">LDP servers</a> that define a non-member resource SHOULD provide an HTTP <code>Link</code>
@@ -2207,6 +2162,9 @@
 
 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
 <ul>
+    <li>2013-11-12 - Clean up some remnants of inlining (JA)</li>
+    <li>2013-11-12 - Clean up some overly specific language (implications that POST is the only way to create members, etc) (JA)</li>
+    <li>2013-11-12 - Resolve ACTION-112 Update spec to reflect 10/28 resolution for Issue-81 part 1: new predicate names (JA)</li>
     <li>2013-11-12 - Fix respec messages that only show up on remote server, hit paging examples to remove appearance of inlining (JA)</li>
     <li>2013-11-11 - Resolve ACTION-113 Update spec to reflect 11/04 resolution to remove 303 and have client use first/next links to detect paging (JA)</li>
     <li>2013-10-25 - Resolve ACTION-105 Update spec to reflect 9/30 resolution moving Paging links to HTTP headers (JA)</li>
@@ -2241,7 +2199,7 @@
 	<li>2013-07-23 - ISSUE-53 4.2.3 changed MUST to SHOULD (SS)</li>
 	<li>2013-07-22 - ISSUE-53 4.2.2 changed MUST to SHOULD (SS)</li>
 	<li>2013-07-17 - Various updates from suggests from <a href="http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0067.html">Raúl</a> (SS)</li>
-	<li>2013-07-15 - Inserted ldp:membershipObject into examples (SS)</li>
+	<li>2013-07-15 - Inserted ldp:insertedContentRelation into examples (SS)</li>
 	<li>2013-07-15 - ISSUE-79 ldp:contains =&gt; ldp:created  (JA)</li>
 	<li>2013-07-11 - Improving working in <a href="#ldpr-Paging" class="sectionRef"></a> to remove container references (SS)</li>
 	<li>2013-07-11 - Removed 4.1.5, section number fixup:4.1.8-13-&gt;6-11, 4.9.2.* fixup, 5.3.7-10-&gt;\2-5 (SS)</li>
@@ -2252,7 +2210,7 @@
 	<li>2013-07-10 - Removed closed issues that required no new spec changes: 18, 35, 20 (SS)</li>
 	<li>2013-07-10 - ISSUE-44 move section 4.1.7 (relationships are simple RDF links) to guidance (SS)</li>
 	<li>2013-07-10 - ISSUE-72 take 2 - added ldp:MemberSubject to handle default case (SS)</li>
-	<li>2013-07-10 - ISSUE-72 adding 5.2.10 for ldp:membershipObject (SS)</li>
+	<li>2013-07-10 - ISSUE-72 adding 5.2.10 for ldp:insertedContentRelation (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>
@@ -2279,7 +2237,7 @@
 	<li>2013-05-13 - ISSUE-49 Moved section 4.1.4 out of spec to the <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Predicate_URIs_SHOULD_be_HTTP_URLs">deployment guide</a>. (SS)</li>
 	<li>2013-05-08 - Removed closed issues 5, 7, 55 and 38 as the don't require edits. Added 64 and 65. (SS)</li>
 	<li>2013-05-08 - ISSUE-59 5.3.2 limited rdf:type of ldp:Container, removed 5.6.3, reworded 5.6.2, updated 1. (SS)</li>
-	<li>2013-04-15 - ISSUE-21 Added ldp:membershipPredicateInverse to 5.2.5 &amp; 5.5.2, created 5.2.5.1 &amp; 5.3.5.2 to indicate difference. (SS)</li>
+	<li>2013-04-15 - ISSUE-21 Added ldp:containedByRelation to 5.2.5 &amp; 5.5.2, created 5.2.5.1 &amp; 5.3.5.2 to indicate difference. (SS)</li>
 	<li>2013-04-15 - ISSUE-39 Moved informative text from 5.4.5 into 5.4.1, shifted subsections .6-.10 (SS)</li>
 	<li>2013-04-15 - Expanded on wording for 4.3 to be more consistent (SS)</li>
 	<li>2013-04-08 - Fixed two old references to BPR (SS)</li>