ldp.html
changeset 238 59bacb9c7b5b
parent 237 6871b9ac5339
child 274 8db905ebe0ba
--- a/ldp.html	Thu Jul 25 08:23:01 2013 -0400
+++ b/ldp.html	Thu Jul 25 13:01:31 2013 -0400
@@ -1309,9 +1309,9 @@
 		While it is difficult to provide absolute implementation guarantees of non-reuse in all failure
 		scenarios, re-using URIs creates ambiguities for clients that are best avoided.
 	</div>
-	<div id="ldpc-5_2_10" class="rule">5.2.10 Some LDPC's have membership object's that are not directly
+	<div id="ldpc-5_2_10" class="rule">5.2.10 Some LDPCs have membership objects that are not directly
 	    URIs minted upon LDPC member creation, for example URIs with non-empty fragment identifier [[RFC3986]]. 
-	    To determine which object URI to use for the  membership triple, LDPC's MUST contain one triple whose
+	    To determine which object URI to use for the  membership triple, LDPCs MUST contain one triple whose
 	    subject is the LDPC URI, predicate is <code>ldp:membershipObject</code>, with an object <var>MO</var>. 
 	    Where <var>MO</var> and the HTTP URI <var>R</var> from <code>POST</code> create (as found in HTTP response <code>Location</code> header) can be 
 	    used to locate a triple of the form: <var>(R, MO, N)</var> and 
@@ -1561,7 +1561,7 @@
 		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
 		
 	<div id="ldpc-5_6_1" class="rule">5.6.1 When a LDPC member resource originally created by the LDPC (for example, one whose representation
-	    was HTTP <code>POST</code>'d to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server is aware of the member's deletion
+	    was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server is aware of the member's deletion
 		(for example, the member is managed by the same server), the LDPC server MUST also remove it from
 		the LDPC by removing the corresponding membership triple.
 	</div>	
@@ -1577,7 +1577,7 @@
 	</div>	
 	
 	<div id="ldpc-5_6_4" class="rule">5.6.4 When a LDPC member resource originally created by the LDPC (for example, one whose 
-	representation was HTTP <code>POST</code>'d to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server 
+	representation was HTTP <code>POST</code>dd to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server 
 	created an associated LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>), the LDPC server must also remove the associated LDPR it created.
 	</div>	
 	
@@ -1630,7 +1630,7 @@
 	</div>
 	
 	<div id="ldpc-5_9_2" class="rule">5.9.2 When a LDPC creates a non-LDPR (e.g. binary) member (for example, one whose 
-	representation was HTTP <code>POST</code>'d to the LDPC and then referenced by a membership triple) it might create an associated LDPR to contain data about the 
+	representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) it might create an associated LDPR to contain data about the 
 	non-LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>).  For non-LDPRs that have this associated LDPR, an LDPC server MUST provide an HTTP <code>Link</code>
 	header whose target URI is the associated LDPR, and whose link relation type is 
 	<code>meta</code> [[!RFC5988]].</div>