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