ldp.html
changeset 231 38d1a7faf1c4
parent 230 b0111e4397ab
child 232 c38de2977a87
--- a/ldp.html	Wed Jul 24 09:34:52 2013 -0400
+++ b/ldp.html	Wed Jul 24 10:30:22 2013 -0400
@@ -20,9 +20,6 @@
 	  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. 
-    - John A's comments http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0054.html
-                        http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0056.html
-    - P-A's comments http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0071.html
     - Sergio's comments http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0072.html
  -->
 <html>
@@ -199,7 +196,7 @@
 	read and write Linked Data resources.</p> 
 	<p>A special type of <a title="Linked Data Platform Resource">Linked Data Platform Resource</a> is a 
 	<a title="Linked Data Platform Container">Container</a>.  Containers are very useful 
-	in building application models.  For example, universities offer a collection of classes 
+	in building application models involving collections of homogeneous resources.  For example, universities offer a collection of classes 
 	and have a collection of faculty members, each faculty member teaches a collection of courses, etc.  
 	This specification discusses how to work with containers.  Resources can be added to containers in 
 	several ways. As a special case, members can both be created and added to a container by overloading 
@@ -254,7 +251,7 @@
 	<dt><dfn>Membership triples</dfn></dt>
 	<dd>A set of triples in an LDPC's state that lists its members.
 		The membership triples of a container all have the same
-		subject and predicate, and the objects of the membership triples define
+		subject and predicate, and the objects of the membership triples identify
 		the container's members. 
 	<p></p></dd>
 	
@@ -355,7 +352,7 @@
 	<p>The rules for Linked Data Platform Resources address basic
 		questions such as:</p>
 	<ul>
-		<li>What resource formats should be used?</li>
+		<li>What resource representations should be used?</li>
 		<li>How is optimistic collision detection handled for updates?</li>
 		<li>What should client expectations be for changes to linked-to resources,
 				such as type changes?</li>
@@ -623,7 +620,7 @@
 		resource is too large to reasonably transmit its representation in a
 		single HTTP response. This will be especially true if the resource
 		representation includes many triples both from its own representation and
-		from the representations of any of its members. A client could anticipate that a resource will be too large -
+		from the representations of any <a title="Resource inlining">inlined resources</a>. A client could anticipate that a resource will be too large -
 		for example, a client tool that accesses defects may assume that an
 		individual defect will usually be of sufficiently constrained size
 		that it makes sense to request all of it at once, but that the
@@ -938,7 +935,7 @@
 		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 resoruces.</p>
+		possibly perform 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
@@ -993,8 +990,9 @@
 	</p>
 
 <pre class="example" id="ldpc-ex-membership-full"># The following is an elaborated representation of
-#   http://example.org/netWorth/nw1
+#   http://example.org/netWorth/nw1/
 @prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
 @prefix o: &lt;http://example.org/ontology/&gt;.
 &lt;&gt;
    a o:NetWorth;
@@ -1010,14 +1008,14 @@
 &lt;assetContainer/&gt;
    a ldp:Container;
    dcterms:title "The assets of JohnZSmith";
-   ldp:membershipSubject &lt;.&gt;;
+   ldp:membershipSubject &lt;&gt;;
    ldp:membershipPredicate o:asset;
    ldp:membershipObject ldp:MemberSubject.
 
 &lt;liabilityContainer/&gt;
    a ldp:Container;
    dcterms:title "The liabilities of JohnZSmith";
-   ldp:membershipSubject &lt;.&gt;;
+   ldp:membershipSubject &lt;&gt;;
    ldp:membershipPredicate o:liability;
    ldp:membershipObject ldp:MemberSubject.
 </pre>
@@ -1038,8 +1036,7 @@
 	resources allows both assets and liabilities to be created.
 	</p>
 
-<pre class="example" id="ldpc-ex-membership-subj">
-# The following is the representation of
+<pre class="example" id="ldpc-ex-membership-subj"># The following is the representation of
 #   http://example.org/netWorth/nw1/assetContainer/
 @prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
 @prefix o: &lt;http://example.org/ontology/&gt;.
@@ -1103,7 +1100,7 @@
    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>(.../assetContainer/, o:asset, .../a1).</var></p>
+	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>
@@ -1243,8 +1240,8 @@
 	<div id="ldpc-5_2_1" class="rule">5.2.1 LDPC servers MUST also be conformant LDPR servers. A Linked Data Platform
 		Container MUST also be a conformant Linked Data Platform Resource.
 	</div>
-	<div id="ldpc-5_2_2" class="rule">5.2.2 For an LDPC,
-	the same resource (LDPR or not) which is identified by its canonical URI, MAY be a member of 
+	<div id="ldpc-5_2_2" class="rule">5.2.2 LDPC membership is not exclusive; this means that the same resource
+	(LDPR or not) which is identified by its canonical URI, MAY be a member of 
 	more than one LDPC.
 	</div>
 	<div id="ldpc-5_2_3" class="rule">5.2.3 The state of an LDPC includes information about which
@@ -1256,12 +1253,12 @@
 		SHOULD use the <code>rdfs:member</code> predicate. Member resources can be
 		any kind of resource identified by its URI, LDPR or otherwise.
 	</div>
-	<div id="ldpc-5_2_4" class="rule">5.2.4 An LDPC representation MUST contain one triple 
+	<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.
 	</div>
-	<div id="ldpc-5_2_5" class="rule">5.2.5 An LDPC representation MUST contain one triple 
+	<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>. 
 		The object of the triple is constrained by other sections, such as
@@ -1502,7 +1499,7 @@
 		While "POST to create" is a common interaction pattern, LDP clients are not guaranteed, even when 
 		making requests to an LDP server, that every successful <code>POST</code> request will result in the 
 		creation of a new resource; they must rely on out of band information for knowledge of which <code>POST</code> requests,
-		if any, will have the "create new resource" semantic.
+		if any, will have the "create new resource" semantics.
 		This requirement on LDP servers is intentionally stronger than the one levied in the
 		<a href="#header-accept-post">header registration</a>; it is unrealistic to expect all existing resources
 		that support <code>POST</code> to suddenly return a new header or for all new specifications constraining