ldp.html
changeset 200 aebd1e464817
parent 199 7394aac12bea
child 201 45d0825d4dfc
--- a/ldp.html	Mon Jul 15 09:25:06 2013 -0400
+++ b/ldp.html	Mon Jul 15 09:49:36 2013 -0400
@@ -432,9 +432,9 @@
 		in all responses to requests made 
 		to the resource's HTTP <code>Request-URI</code>. This is notionally equivalent to the
 		presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in the resource.
-		The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP spec in a way
+		The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP specification in a way
 		that clients can introspect dynamically at run-time.  Conservative clients should note that 
-		a server can host a mixture of LDPRs and other resources, and therefore there is no implication
+		<a href="#ldpr-4_1_3">a server can host a mixture of LDPRs and other resources</a>, and therefore there is no implication
 		that LDP support advertised on one HTTP <code>Request-URI</code> means that other 
 		resources on the same server are also LDPRs.  Each HTTP <code>Request-URI</code> needs to be 
 		individually introspected by a conservative client, in the absence of outside information.
@@ -477,10 +477,11 @@
 <section>
 <h2 id="ldpr-HTTP_POST">HTTP POST</h2>
 	<p>This specification adds no new requirements on HTTP <code>POST</code> for LDPRs 
-		only when the LDPR supports that method.  This specification does not impose any
+		even when the LDPR supports that method.  This specification does not impose any
 		new requirement to support that method, and [[!HTTP11]] makes it optional</p>
-	<p>Creation of LDPRs is done via HTTP <code>POST</code> to a LDPC, see the <a href="#ldpc-HTTP_POST" class="sectionRef"></a>
-	 in the LDPC parent section for more details.</p>
+	<p>Creation of LDPRs can be done via <a href="#ldpc-HTTP_POST" class="sectionRef"></a> or
+		<a href="#ldpc-HTTP_PUT" class="sectionRef"> to a LDPC, see those 
+		sections for more details.</p>
 </section>
 
 <section>
@@ -653,7 +654,8 @@
 	<p>LDPR servers may respond to requests for a
 		resource by redirecting the client to the first page resource –
 		using a 303 “See Other” redirect to the actual URL for the page
-		resource.</p>
+		resource.  Alternatively, clients may introspect the resource for a paged representation 
+		and use it preferentially when available.</p>
 	<p>
 		Looking at an example resource representing Example Co.'s customer
 		relationship data, we’ll split the response across two pages.  
@@ -1314,8 +1316,9 @@
 		or that are from the representations of the members (if they have RDF
 		representations). This allows a LDPC server to provide clients with
 		information about the members without the client having to do a <code>GET</code>
-		on each member individually.  See section <a href="#ldpc-member_data">5.1.1 Container
-		Member Information</a> for additional details.
+		on each member individually.  See sections <a href="#ldpc-member_data">5.1.1 Container
+		Member Information</a>, <a href="#ldpr-inlining" class="sectionRef"></a>, and
+		<a href="#ldpc-inlining" class="sectionRef"></a> for additional details.
     </div>
 		
 	<div id="ldpc-5_2_7" class="rule">5.2.7 The representation of a LDPC MUST have <code>rdf:type</code>
@@ -1337,7 +1340,7 @@
 
 	<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 URIs with non-empty fragment identifier [[RFC3986]]. 
-	    To determine which object URI to use for the  membership triple, LDPC's MUST contain triple whose
+	    To determine which object URI to use for the  membership triple, LDPC's 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 
@@ -1463,7 +1466,7 @@
 		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
 		[[!SPARQL-QUERY]] using three-argument <code>fn:compare</code>, that is, the 
 		specified collation.
-		When the <code>ldp:containerSortCollation</code> triple SHOULD be omitted for comparisons
+		The <code>ldp:containerSortCollation</code> triple SHOULD be omitted for comparisons
 		involving <a title="page-ordering values">page-ordering values</a> for which [[!SPARQL-QUERY]] does not use collations.
 	</div>
 
@@ -1494,7 +1497,8 @@
 	</div>
 	
 	<div id="ldpc-5_4_3" class="rule">5.4.3 LDPC servers MAY accept an HTTP <code>POST</code> of non-RDF representations for
-		creation of any kind of resource, for example binary resources.
+		creation of any kind of resource, for example binary resources.  See <a href="#ldpr-5_4_13">5.4.13</a> for introspection
+		details.
 	</div>
 	<div id="ldpc-5_4_4" class="rule">5.4.4 For servers that support create, LDPC servers MUST create an LDPR from a
 		RDF representation in the request entity body.  The newly created LDPR could also be a LDPC, therefore servers may