--- a/ldp.html Mon Mar 04 12:28:31 2013 -0500
+++ b/ldp.html Mon Mar 04 13:50:06 2013 -0500
@@ -135,7 +135,7 @@
<em>Resources</em> - a summary of the
HTTP and RDF standard techniques and best practices that you should
use, and anti-patterns you should avoid, when constructing clients
- and servers that read and write linked data.
+ and servers that read and write Linked Data.
</p>
</li>
<li><p>
@@ -149,7 +149,7 @@
of this document to enable additional rules and layered groupings of
rules, such as additional specifications. The scope is intentionally
narrow to provide a set of key rules for reading and writing Linked
- Data that most, if not all, other specifications will depend on and
+ Data that most, if not all, other specifications will depend upon and
implementations will support.</p>
</section>
@@ -190,18 +190,18 @@
or tunnel, switching behavior based on the nature of each request
[[HTTP11]]. </p></dd>
- <dt><dfn>Membership triples</dfn></dt>
+ <dt>Membership triples</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
the container's members.
<p></p></dd>
- <dt><dfn>Membership subject</dfn></dt>
+ <dt>Membership subject</dt>
<dd>The subject of all an LDPC's <a title="Membership triples">membership triples</a>.
<p></p></dd>
- <dt><dfn>Membership predicate</dfn></dt>
+ <dt>Membership predicate</dt>
<dd>The predicate of all an LDPC's <a title="Membership triples">membership triples</a>.
<p></p></dd>
</dl>
@@ -292,8 +292,8 @@
is common for LDPR servers to need to host binary or text resources
that do not have useful RDF representations.
</div>
- <div id="ldpr-4_1_4" class="rule">4.1.4 Clients can access a LDPR using multiple
- URLs, for example when DNS aliasing is used. A LDPR server MUST
+ <div id="ldpr-4_1_4" class="rule">4.1.4 Clients can access an LDPR using multiple
+ URLs, for example when DNS aliasing is used. An LDPR server MUST
respond to each of those requests using a single consistent URL, a
canonical URL, for the LDPR which may be found in the response's
Location header and potentially also in the representation of the
@@ -455,13 +455,13 @@
are used in the state of any one resource is not limited to any pre-defined
set.
</div>
- <div id="ldpr-4_4_4" class="rule">4.4.4 LDPR clients SHOULD assume that a LDPR server could discard triples
+ <div id="ldpr-4_4_4" class="rule">4.4.4 LDPR clients SHOULD assume that an LDPR server could discard triples
whose predicates the server does not recognize or otherwise chooses
not to persist. In other words, LDPR servers MAY restrict themselves
to a known set of predicates, but LDPR clients MUST NOT restrict themselves to a known set of predicates
when their intent is to perform a later HTTP PUT to update the resource.
</div>
- <div id="ldpr-4_4_5" class="rule">4.4.5 A LDPR client MUST preserve all triples retrieved using HTTP GET that
+ <div id="ldpr-4_4_5" class="rule">4.4.5 An LDPR client MUST preserve all triples retrieved using HTTP GET that
it doesn’t change whether it understands the predicates or not, when
its intent is to perform an update using HTTP PUT. The use of HTTP
PATCH instead of HTTP PUT for update avoids this burden for clients
@@ -519,7 +519,7 @@
This is a consequence of the requirement to <a href="#ldpr-4_1_13">enable simple creation and modification</a> of LPDRs.
</div>
<div id="ldpr-4_7_3" class="rule">4.7.3 LDPR servers SHOULD NOT allow clients to create new resources using PATCH.
- <a href="#ldpr-5_4">POST (to a LDPC)</a> and/or <a href="#ldpr-4_4">PUT</a> should be used as the standard way to create new LDPRs.
+ <a href="#ldpr-5_4">POST (to an LDPC)</a> and/or <a href="#ldpr-4_4">PUT</a> should be used as the standard way to create new LDPRs.
</div>
<div class="ldp-issue">
@@ -734,12 +734,12 @@
container is too large to reasonably transmit its representation in a
single HTTP response. This will be especially true if the container
representation includes many triples from the representations of its
- members. A client may anticipate that a container will be too large -
+ members. A client could anticipate that a container 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
container of all the defects ever created will typically be too big.
- Alternatively, a server may recognize that a container that has been
+ Alternatively, a server could recognize that a container that has been
requested is too big to return in a single message.</p>
<p>
To address this problem, LDPCs should support a technique called Paging. Paging can be achieved with a
@@ -852,7 +852,7 @@
paginated. If the server does not respect ordering when constructing
pages, the client is forced to retrieve all pages before
sorting the members, which would defeat the purpose of pagination. In
- cases where ordering is important, a LDPC server exposes all the
+ cases where ordering is important, an LDPC server exposes all the
members on a page with a higher sort order than all members on the
previous page and lower sort order than all the members on the next
page. The LDPC specification provides a predicate - <code>ldp:containerSortPredicates</code>
@@ -914,7 +914,7 @@
</div>
<div id="ldpc-5_2_2" class="rule">5.2.2 The same resource, identified by its canonical URI, MUST be a member of
only a single LDPC. The same resource can not be a member of mutliple LDPCs.</div>
- <div id="ldpc-5_2_3" class="rule">5.2.3 The state of a LDPC includes information about which
+ <div id="ldpc-5_2_3" class="rule">5.2.3 The state of an LDPC includes information about which
resources are its members. In the simplest cases, the membership subject
will be the LDPC resource itself, but it does not have to be. The
membership predicate is also variable and will often be a predicate
@@ -927,11 +927,11 @@
container affordances
</div>
</div>
- <div id="ldpc-5_2_4" class="rule">5.2.4 A LDPC MUST contain one triple containing the <code>ldp:membershipSubject</code>
+ <div id="ldpc-5_2_4" class="rule">5.2.4 An LDPC MUST contain one triple containing the <code>ldp:membershipSubject</code>
predicate when the membership subject is not the LDPC itself.
This triple's object provides clients with the LDPC's membership subject URI.
</div>
- <div id="ldpc-5_2_5" class="rule">5.2.5 A LDPC MUST contain one triple containing the <code>ldp:membershipPredicate</code>
+ <div id="ldpc-5_2_5" class="rule">5.2.5 An LDPC MUST contain one triple containing the <code>ldp:membershipPredicate</code>
predicate when
the container predicate is not <code>rdfs:member</code>.
This triple's object provides clients with the LDPC's membership predicate URI.
@@ -976,18 +976,18 @@
members, by the existence of the token "<code>non-member-properties</code>" on the query
component of the LDPC URL. For example, if there is a LDPC URL <code><containerURL>,</code> the URL to request the
non-membership properties would be <code><containerURL>?non-member-properties</code>.
- See section <a href="#ldpc-get_non_member_props">5.1.2 Retrieving Non-member Properties</a> for
- additional details. A LDPC server that does not support a request to
+ See section <a href="#ldpc-get_non_member_props">5.1.2 Retrieving Only Non-member Properties</a> for
+ examples. An LDPC server that does not support a request to
retrieve non-member resource properties via a Request-URI of “<code><containerURL>?non-member-properties</code>”,
- MUST return a HTTP status code 404 (Not Found). A LDPC server that supports a request to
+ MUST return a HTTP status code 404 (Not Found). An LDPC server that supports a request to
retrieve non-member resource properties via a different Request-URI than “<code><containerURL>?non-member-properties</code>”,
MUST return a HTTP Redirection 3xx status code such as 301 (Moved Permanently) or 302 (Found).
</div>
- <div id="ldpc-5_3_3" class="rule">5.3.3 A LDPC server that does not support a request to retrieve the first
+ <div id="ldpc-5_3_3" class="rule">5.3.3 An LDPC server that does not support a request to retrieve the first
page resource representation from a known LDPC whose URL is “<code><containerURL></code>” by using
the Request-URI “<code><containerURL>?firstPage</code>”, MUST return a HTTP status code 404 (Not
Found).
- A LDPC server that supports that request using a different Request-URI than “<code><containerURL>?firstPage</code>”,
+ An LDPC server that supports that request using a different Request-URI than “<code><containerURL>?firstPage</code>”,
MUST return a HTTP Redirection 3xx status code such as 301 (Moved Permanently) or 302 (Found).
</div>
<div id="ldpc-5_3_4" class="rule">5.3.4 LDPC servers SHOULD support requests for splitting large LDPCs into
@@ -996,7 +996,7 @@
URL <code><containerURL></code>, the URL to request
the first page would be <code><containerURL>?firstPage</code>.
The representation for any page, including the first, will include
- the URL for the next page. See section <a href="#ldpc-paging">5.1.3 titled “Paging”</a> for additional details.
+ the URL for the next page. See section <a href="#ldpc-paging">5.1.3 Paging</a> for additional details.
</div>
<div id="ldpc-5_3_5" class="rule">5.3.5 LDPC servers MAY split the response representation of a LDPC regardless
of what the client requested (such as when a client omits a “<code>firstPage</code>”
@@ -1012,9 +1012,9 @@
representation a representation for the LDPC, such that:
</div>
<div id="ldpc-5_3_6_1" class="rule">5.3.6.1 The page resource representation SHOULD have one triple to indicate its
- type, whose subject is the URL of the page, whose predicate is <code>rdf:type</code> and object is <code>ldp:Page;</code>
- it also SHOULD have 1 triple to indicate the container it is paging,
- whose subject is the URL of the page, predicate is <code>ldp:pageOf,</code>
+ type, whose subject is the URL of the page, whose predicate is <code>rdf:type</code> and object is <code>ldp:Page</code>.
+ It also SHOULD have 1 triple to indicate the container it is paging,
+ whose subject is the URL of the page, predicate is <code>ldp:pageOf</code>,
and object is the URL of the LDPC.
</div>
<div id="ldpc-5_3_6_2" class="rule">5.3.6.2 The page resource representation MUST have one triple with the subject
@@ -1033,7 +1033,7 @@
<div id="ldpc-5_3_7" class="rule">5.3.7 LDPC servers MAY represent the members of a paged LDPC in a sequential
order. The order MUST be specified using the <code>ldp:containerSortPredicates</code>
predicate whose subject is that of the page and object is a list of
- LDPC ordinal predicates. The default ordering is ascending. The only
+ LDPC ordinal predicates. Ordering is only ascending. The only
ordinal predicate literal data types supported are those as defined
by SPARQL SELECT’s ORDER BY clause [[!SPARQL-QUERY]].
@@ -1063,7 +1063,7 @@
</div>
<div id="ldpc-5_4_2" class="rule">5.4.2 After a successful HTTP POST request to a LDPC, the new resource MUST
appear as a member of the LDPC until the new resource is deleted or
- removed by other methods. A LDPC MAY also contain resources that were
+ removed by other methods. An LDPC MAY also contain resources that were
added through other means - for example through the user interface of
the site that implements the LDPC.
</div>
@@ -1076,7 +1076,7 @@
<div id="ldpc-5_4_3" class="rule">5.4.3 LDPC servers MAY accept an HTTP POST of non-RDF representations for
creation of any kind of resource, for example binary resources.
</div>
- <div id="ldpc-5_4_4" class="rule">5.4.4 For servers that support create, LDPC servers MUST create a LDPR from a
+ <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 LDPR could also be a LDPC, therefore servers may
allow the creations of LDPCs within a LDPC.
</div>
@@ -1215,6 +1215,7 @@
<h1>Change History</h1>
<blockquote><em>First Public Working Draft</em></blockquote>
<ul>
+ <li>2013-03-04 - Comments received from David Wood: 5.3.7 & 5.1.3 clarity, other minor edits (part 2) (SS)</li>
<li>2013-03-04 - Comments received from David Wood: abstract, paging informative (part 1) (SS)</li>
<li>2013-03-04 - ISSUE-36 - Added informative text regarding creationg of containers in 5.4.4 (SS)</li>
<li>2013-03-04 - ISSUE-12 - Added section 4.7.3 not to allow PATCH for create (SS)</li>