--- a/ldp.html Tue Apr 15 15:11:02 2014 -0400
+++ b/ldp.html Tue Apr 15 15:38:48 2014 -0400
@@ -327,7 +327,7 @@
<p></p></dd>
<dt><dfn>Linked Data Platform Container</dfn> (<abbr title="Linked Data Platform Container">LDPC</abbr>)</dt>
- <dd>An LDP-RS representing a collection of linked
+ <dd>A LDP-RS representing a collection of linked
documents (<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-document">RDF Document</a> [[!rdf11-concepts]] or information resources [[!WEBARCH]])
that responds to client requests for creation, modification, and/or enumeration of its linked members and documents,
and that conforms to the simple lifecycle
@@ -352,12 +352,13 @@
<p></p></dd>
<dt><dfn>Membership</dfn></dt>
- <dd>The relationship linking an LDP-RS (LDPCs are also LDP-RSs) and its member LDPRs.
+ <dd>The relationship linking an LDP-RS (LDPCs are also LDP-RSs) and its member LDPRs,
+ which can be different resources than its <a title="Containment">contained</a> documents.
There often is a linked LDPC that assists with managing the member LDPRs.<p></p></dd>
<dt><dfn>Membership triples</dfn></dt>
<dd>A set of triples in an LDP-RS's state that lists its members.
- An LDP-RS's membership triples all have one of the following patterns:
+ A LDP-RS's membership triples all have one of the following patterns:
<table class="indented">
<tr>
<td style="background:#DDDDDD"> <var>membership-constant-URI</var> </td>
@@ -493,7 +494,7 @@
into client consumable chunks called pages. A separate LDP specification outlines the conformance
rules around pagination [[LDP-PAGING]].
</p>
- <p>An LDP server can manage two kinds of <a title="Linked Data Platform Resources">LDPRs</a>, those resources whose state
+ <p>A LDP server can manage two kinds of <a title="Linked Data Platform Resources">LDPRs</a>, those resources whose state
is represented using RDF (LDP-RS) and those using other formats (LDP-NR). LDP-RSs have the unique
quality that their representation is based on RDF, which addresses a number of use cases from web metadata, open data
models, machine processable information, and automated processing by software agents [[!rdf11-concepts]]. LDP-NRs are almost anything
@@ -552,7 +553,7 @@
</p>
<p>
Note:
- <a href="#ldpr-gen-binary">An LDP server can host a mixture of LDP-RSs and LDP-NRs</a>, and therefore there is no implication
+ <a href="#ldpr-gen-binary">A LDP server can host a mixture of LDP-RSs and LDP-NRs</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 inspected, in the absence of outside information.
@@ -596,11 +597,11 @@
<p>
Per [[HTTP11]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
- When an LDP server supports this method,
+ When a LDP server supports this method,
this specification imposes no new requirements for LDPRs.
</p>
- <p>Clients can create LDPRs via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef"></a>) to an LDPC,
+ <p>Clients can create LDPRs via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef"></a>) to a LDPC,
via <code>PUT</code> (<a href="#ldpr-HTTP_PUT" class="sectionRef"></a>), or any other methods allowed
for HTTP resources. Any server-imposed constraints on LDPR creation or update
<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
@@ -613,7 +614,7 @@
<p>
Per [[HTTP11]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
- When an LDP server supports this method,
+ When a LDP server supports this method,
this specification imposes the following new requirements for LDPRs.
</p>
@@ -688,7 +689,7 @@
<p>
Per [[HTTP11]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
- When an LDP server supports this method,
+ When a LDP server supports this method,
this specification imposes no new blanket requirements for LDPRs.
</p>
@@ -712,7 +713,7 @@
<p>
Per [[RFC5789]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
- When an LDP server supports this method,
+ When a LDP server supports this method,
this specification imposes the following new requirements for LDPRs.
</p>
@@ -771,7 +772,7 @@
client applications that don’t support inferencing.
</h2></section><!-- Was 4.2.5 / #ldpr-4_2_5 -->
- <section id="ldprs-rdftype"><h2 class="normal">The representation of an LDP-RS MAY have an <code>rdf:type</code>
+ <section id="ldprs-rdftype"><h2 class="normal">The representation of a LDP-RS MAY have an <code>rdf:type</code>
of <code>ldp:RDFSource</code> for <a title="">Linked Data Platform RDF Source</a>.
</h2></section><!-- Was 5.2.7 / #ldpc-5_2_7 -->
@@ -814,7 +815,7 @@
</h2></section><!-- Was 4.2.11 / #ldpr-4_2_11 -->
<section id="ldpr-cli-preservetriples"><h2 class="normal">
- A <a title="LDP client">LDP client</a> MUST preserve all triples retrieved from an LDP-RS using HTTP <code>GET</code> that
+ A <a title="LDP client">LDP client</a> MUST preserve all triples retrieved from a LDP-RS using HTTP <code>GET</code> that
it doesn’t change whether it understands the predicates or not, when
its intent is to perform an update using HTTP <code>PUT</code>. The use of HTTP
<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
@@ -830,7 +831,7 @@
<section id="ldpr-cli-hints-ignorable"><h2 class="normal">
<a title="LDP client">LDP clients</a> MUST
- be capable of processing responses formed by an LDP server that ignores hints,
+ be capable of processing responses formed by a LDP server that ignores hints,
including LDP-defined hints.
</h2></section>
@@ -838,7 +839,7 @@
<p>The LDP Working Group proposes incorporation of the following clause to make LDP clients paging aware:</p>
<section id="ldpr-cli-paging"><h2 class="normal">
<a title="LDP client">LDP clients</a> SHOULD
- be capable of processing successful HTTP <code>GET</code> responses formed by an LDP server
+ be capable of processing successful HTTP <code>GET</code> responses formed by a LDP server
that independently initiated paging, returning a page of representation instead of full resource
representation [[!LDP-PAGING]].
</h2>
@@ -1209,7 +1210,7 @@
but there is no requirement to materialize this triple in the LDPC representation.
</h2></section><!-- Was 5.2.1 / #ldpc-5_2_1 -->
- <section id="ldpc-typecontainer"><h2 class="normal">The representation of an LDPC MAY have an <code>rdf:type</code>
+ <section id="ldpc-typecontainer"><h2 class="normal">The representation of a LDPC MAY have an <code>rdf:type</code>
of <code>ldp:Container</code> for <a title="">Linked Data Platform Container</a>.
Non-normative note: <a href="#ldp-rdfconcepts-extra-triples-types">LDPCs
might have additional types</a>, like any <a title="Linked Data Platform RDF Source">LDP-RS</a>.
@@ -1244,7 +1245,7 @@
SHOULD respect all of a client's LDP-defined hints, for example
<a href="#prefer-parameters">which subsets of LDP-defined state</a>
the client is interested in processing,
- to influence the set of triples returned in representations of an LDPC,
+ to influence the set of triples returned in representations of a LDPC,
particularly for large LDPCs. See also [[LDP-PAGING]].
</h2></section>
@@ -1264,7 +1265,7 @@
<p>
Per [[HTTP11]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
- When an LDP server supports this method,
+ When a LDP server supports this method,
this specification imposes the following new requirements for LDPCs.
</p>
@@ -1281,7 +1282,7 @@
</h2></section><!-- Was 5.4.1 / #ldpc-5_4_1 -->
<section id="ldpc-post-createdmbr-contains"><h2 class="normal">
- When a successful HTTP <code>POST</code> request to an LDPC results in the creation of an LDPR, a
+ When a successful HTTP <code>POST</code> request to a LDPC results in the creation of a LDPR, a
<a title="Containment triples">containment triple</a> MUST be added to the state of LDPC
whose subject is the LDPC URI,
whose predicate is <code>ldp:contains</code> and whose object is the URI for the newly created document (LDPR). Other triples may be added as well.
@@ -1292,7 +1293,7 @@
<section id="ldpc-post-createbins"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY accept an HTTP <code>POST</code> of non-RDF representations
<a title="Linked Data Platform Non-RDF Source">(LDP-NRs)</a> for
creation of any kind of resource, for example binary resources. See <a href="#ldpc-post-acceptposthdr">the Accept-Post section</a> for
- details on how clients can discover whether an LDPC supports this behavior.
+ details on how clients can discover whether a LDPC supports this behavior.
</h2></section><!-- Was 5.4.3 / #ldpc-5_4_3 -->
<section id="ldpc-post-createrdf"><h2 class="normal"><a title="LDP server">LDP servers</a> that successfully create a resource from a
@@ -1300,11 +1301,11 @@
If any requested interaction model cannot be honored, the server MUST fail the request.
</h2><!-- Was 5.4.4 / #ldpc-5_4_4 -->
<ul>
- <li>If the request header specifies <a href="#ldpr-gen-linktypehdr">an LDPR interaction model</a>, then the server MUST handle subsequent
- requests to the newly created resource's URI as if it is an LDPR.
+ <li>If the request header specifies <a href="#ldpr-gen-linktypehdr">a LDPR interaction model</a>, then the server MUST handle subsequent
+ requests to the newly created resource's URI as if it is a LDPR.
(even if the content contains an <code>rdf:type</code> triple indicating a type of LDPC).</li>
- <li>If the request header specifies <a href="#ldpc-linktypehdr">an LDPC interaction model</a>, then the server MUST handle subsequent
- requests to the newly created resource's URI as if it is an LDPC.
+ <li>If the request header specifies <a href="#ldpc-linktypehdr">a LDPC interaction model</a>, then the server MUST handle subsequent
+ requests to the newly created resource's URI as if it is a LDPC.
</li>
<li>This specification does not constrain the server's behavior in other cases.</li>
</ul>
@@ -1353,7 +1354,7 @@
<a title="Linked Data Platform Non-RDF Source">LDP-NR</a> (HTTP status code of
201-Created and URI indicated by <code>Location</code> response header), <a title="LDP server">LDP servers</a> MAY create an associated
<a title="Linked Data Platform RDF Source">LDP-RS</a>
- to contain data about the newly created LDP-NR. If an LDPC server creates this associated <a title="Linked Data Platform RDF Source">LDP-RS</a> it MUST indicate
+ to contain data about the newly created LDP-NR. If a LDP server creates this associated <a title="Linked Data Platform RDF Source">LDP-RS</a> it MUST indicate
its location on the HTTP response using the HTTP <code>Link</code> response header with link relation <code>describedby</code>
and <code>href</code> to be the URI of the associated LDP-RS resource [[!RFC5988]].
</h2></section><!-- Was 5.4.12 / #ldpc-5_4_12 -->
@@ -1364,7 +1365,7 @@
LDP only specifies the use of <code>POST</code> for the purpose of creating new resources, but a server
can accept <code>POST</code> requests with other semantics.
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
+ making requests to a 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" semantics.
This requirement on LDP servers is intentionally stronger than the one levied in the
@@ -1381,7 +1382,7 @@
<p>
Per [[HTTP11]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
- When an LDP server supports this method,
+ When a LDP server supports this method,
this specification imposes the following new requirements for LDPCs.
</p>
@@ -1390,7 +1391,7 @@
<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
</p>
- <section id="ldpc-put-mbrprops"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> to update an LDPC’s <a>containment triples</a>;
+ <section id="ldpc-put-mbrprops"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> to update a LDPC’s <a>containment triples</a>;
if the server receives such a request, it SHOULD respond with a 409
(Conflict) status code.
</h2></section><!-- Was 5.5.1 / #ldpc-5_5_1 -->
@@ -1406,12 +1407,12 @@
<p>
Per [[HTTP11]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
- When an LDP server supports this method,
+ When a LDP server supports this method,
this specification imposes the following new requirements for LDPCs.
</p>
<section id="ldpc-del-contremovesconttriple"><h2 class="normal">
- When an LDPR identified by the object of a <a title="containment triples">containment triple</a> is deleted, the LDPC server MUST also remove
+ When a LDPR identified by the object of a <a title="containment triples">containment triple</a> is deleted, the LDPC server MUST also remove
the LDPR from the containing LDPC by removing the corresponding containment triple.
</h2>
<blockquote>
@@ -1423,7 +1424,7 @@
</section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
<section id="ldpc-del-contremovescontres"><h2 class="normal">
- When an LDPR identified by the object of a <a title="containment triples">containment triple</a> is deleted, and the LDPC server
+ When a LDPR identified by the object of a <a title="containment triples">containment triple</a> is deleted, and the LDPC server
created an associated LDP-RS (see the <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>), the LDPC server MUST also remove the associated LDP-RS it created.
</h2></section><!-- Was 5.6.4 / #ldpc-5_6_4 -->
@@ -1445,7 +1446,7 @@
<p>
Per [[HTTP11]], this HTTP method is optional and
this specification does not require <a title="LDP server">LDP servers</a> to support it.
- When an LDP server supports this method,
+ When a LDP server supports this method,
this specification imposes the following new requirements for LDPCs.
</p>
@@ -1457,7 +1458,7 @@
<section id="ldpc-patch-req"><h2 class="normal">
<a title="LDP server">LDP servers</a> are RECOMMENDED
to support HTTP <code>PATCH</code> as the preferred method for
- updating an LDPC's <a title="Empty-container triples">empty-container triples</a>.
+ updating a LDPC's <a title="Empty-container triples">empty-container triples</a>.
</h2></section><!-- Was 5.8.1 / #ldpc-5_8_1 -->
</section>
@@ -1466,12 +1467,12 @@
<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPCs.
</p>
- <section id="ldpc-options-linkmetahdr"><h2 class="normal">When an LDPC server creates an
+ <section id="ldpc-options-linkmetahdr"><h2 class="normal">When a LDPC server creates an
<a title="Linked Data Platform Non-RDF Source">LDP-NR</a> (for example, one whose
representation was HTTP <code>POST</code>ed to the LDPC)
the LDP server might create an associated <a title="Linked Data Platform RDF Source">LDP-RS</a>
to contain data about the non-LDPR (see <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>).
- For LDP-NRs that have this associated LDP-RS, an LDPC server MUST provide an HTTP <code>Link</code>
+ For LDP-NRs that have this associated LDP-RS, a LDPC server MUST provide an HTTP <code>Link</code>
header whose target URI is the associated LDP-RS, and whose link relation type is
<code>describedby</code> [[!RFC5988]].
</h2></section><!-- Was 5.9.2 / #ldpc-5_9_2 -->
@@ -1520,9 +1521,9 @@
<section id="ldpdc-mbrpred"><h2 class="normal">
<a title="Linked Data Platform Direct Container">LDP Direct Containers</a>
- SHOULD use the <code>ldp:member</code> predicate as an LDPC's <a title="Membership predicate">membership predicate</a>
+ SHOULD use the <code>ldp:member</code> predicate as a LDPC's <a title="Membership predicate">membership predicate</a>
if there is no obvious predicate from an application vocabulary to use.
- The state of an LDPC includes information about which
+ The state of a LDPC includes information about which
resources are its members, in the form of <a title="Membership triples">membership triples</a> that
follow a consistent pattern. The LDPC's state contains enough information for clients to discern
the <a title="Membership predicate">membership predicate</a>, the other consistent membership
@@ -1590,7 +1591,7 @@
<section id="ldpdc-HTTP_POST">
<h2>HTTP POST</h2>
<section id="ldpdc-post-createdmbr-member"><h2 class="normal">
- When a successful HTTP <code>POST</code> request to an LDPC results in the creation of an LDPR,
+ When a successful HTTP <code>POST</code> request to a LDPC results in the creation of a LDPR,
the LDPC MUST update its membership triples to reflect that addition, and the resulting
membership triple MUST be consistent with any LDP-defined predicates it exposes.
A <a title="Linked Data Platform Direct Container">LDP Direct Container</a>'s membership triples MAY also be modified via
@@ -1602,7 +1603,7 @@
<h2>HTTP DELETE</h2>
<section id="ldpdc-del-contremovesmbrtriple"><h2 class="normal">
- When an LDPR identified by the object of a <a title="membership triples">membership triple</a> which was
+ When a LDPR identified by the object of a <a title="membership triples">membership triple</a> which was
originally created by the LDP-DC is deleted, the LDPC server MUST also remove
the corresponding membership triple.
</h2>
@@ -1691,7 +1692,7 @@
<section id="ldp-webarch-uri-reuse"><h2 class="normal"><a title="LDP server">LDP servers</a> should not re-use URIs,
regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
- Certain specific cases exist where an LDPC server might delete a resource and then later re-use the
+ Certain specific cases exist where a LDPC server might delete a resource and then later re-use the
URI when it identifies the same resource, but only when consistent with Web architecture.
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.
@@ -1749,12 +1750,12 @@
<h2>RDF</h2>
Reference: [[rdf11-concepts]]
- <section id="ldp-rdfconcepts-extra-triples-any"><h2 class="normal">The state of an LDPR
+ <section id="ldp-rdfconcepts-extra-triples-any"><h2 class="normal">The state of a LDPR
can have triples with any subject(s). The URL used to retrieve the
- representation of an LDPR need not be the subject of any of its triples.
+ representation of a LDPR need not be the subject of any of its triples.
</h2></section>
- <section id="ldp-rdfconcepts-extra-triples-members"><h2 class="normal">The representation of an LDPC
+ <section id="ldp-rdfconcepts-extra-triples-members"><h2 class="normal">The representation of a LDPC
can include an arbitrary number of
additional triples whose subjects are the members of the container,
or that are from the representations of the members (if they have RDF
@@ -1763,7 +1764,7 @@
on each member individually.
</h2></section>
- <section id="ldp-rdfconcepts-extra-triples-types"><h2 class="normal">The state of an LDPR can have more than one
+ <section id="ldp-rdfconcepts-extra-triples-types"><h2 class="normal">The state of a LDPR can have more than one
triple with an <code>rdf:type</code> predicate.
</h2></section>
@@ -1879,7 +1880,7 @@
<h3>Specification</h3>
<section id="prefer-include"><h2 class="normal">
- The <code>include</code> hint defines a subset of an LDPR's content that a client
+ The <code>include</code> hint defines a subset of a LDPR's content that a client
would like included in a representation.
The syntax for the <code>include</code> parameter of the
HTTP <code>Prefer</code> request header's
@@ -1902,7 +1903,7 @@
</section>
<section id="prefer-omit"><h2 class="normal">
- The <code>omit</code> hint defines a subset of an LDPR's content that a client
+ The <code>omit</code> hint defines a subset of a LDPR's content that a client
would like omitted from a representation.
The syntax for the <code>omit</code> parameter of the
HTTP <code>Prefer</code> request header's