--- a/ldp.html Fri Feb 28 17:35:04 2014 -0500
+++ b/ldp.html Fri Feb 28 23:02:22 2014 +0000
@@ -6,12 +6,13 @@
TODO: Improve LDPC intro by explaining simply that LDP-DC restricts LDPC and LDP-BC restricts LDP-DC.
TODO: Add new "discovery of server capabilities" non-norm section
TODO: Missing namespace definition clause?
- TODO: 6.2.2 -- consider 6.2.2.1 rules LDP-DC MUST BE a LDPC, ... to deal with inferencing
+ TODO: 6.2.2 -- consider 6.2.2.1 rules LDP-DC MUST BE an LDPC, ... to deal with inferencing
TODO: Consider folding LDP Clients section, feels a bit out of place
-->
<html>
<head>
<title>Linked Data Platform 1.0</title>
+ <!-- Changed by: , 28-Feb-2014 -->
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<!--
=== NOTA BENE ===
@@ -312,7 +313,7 @@
<p></p></dd>
<dt><dfn>Linked Data Platform Basic Container</dfn> (<abbr title="Linked Data Platform Basic Container">LDP-BC</abbr>)</dt>
- <dd>A <a title="Linked Data Platform Container">LDPC</a> that defines a simple link to both
+ <dd>A <a title="Linked Data Platform Container">LDPC</a> that defines a simple link to
its <a title="Containment">contained</a> documents (information resources) [[!WEBARCH]].
<p></p></dd>
@@ -329,12 +330,12 @@
<p></p></dd>
<dt><dfn>Membership</dfn></dt>
- <dd>The relationship linking a 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.
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 a LDP-RS's state that lists its members.
- A LDP-RS's membership triples all have one of the following patterns:
+ <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:
<table class="indented">
<tr>
<td style="background:#DDDDDD"> <var>membership-constant-URI</var> </td>
@@ -361,7 +362,7 @@
<p></p></dd>
<dt><dfn>Membership predicate</dfn></dt>
- <dd>The predicate of all a LDP-RS's <a title="Membership triples">membership triples</a>.
+ <dd>The predicate of all an LDP-RS's <a title="Membership triples">membership triples</a>.
<p></p></dd>
<dt><dfn>Containment</dfn></dt>
@@ -601,7 +602,7 @@
</p>
<p>
Note:
- <a href="#ldpr-gen-binary">A LDP server can host a mixture of LDPRs and other resources</a>, and therefore there is no implication
+ <a href="#ldpr-gen-binary">An LDP 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 inspected, in the absence of outside information.
@@ -656,11 +657,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 a LDP server chooses to support this method,
+ When an 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 a LDPC,
+ <p>Clients can create LDPRs via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef"></a>) to an 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.
@@ -673,7 +674,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 a LDP server chooses to support this method,
+ When an LDP server supports this method,
this specification imposes the following new requirements for LDPRs.
</p>
@@ -747,7 +748,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 a LDP server chooses to support this method,
+ When an LDP server supports this method,
this specification imposes the following new requirements for LDPRs.
</p>
@@ -771,7 +772,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 a LDP server chooses to support this method,
+ When an LDP server supports this method,
this specification imposes the following new requirements for LDPRs.
</p>
@@ -831,7 +832,7 @@
<p>
This document defines the representation and behavior of containers
that address these issues. There are multiple types of containers defined
- to supported a variety of use cases, all that support a base set of capabilities.
+ to support a variety of use cases, all that support a base set of capabilities.
The contents of a container is
defined by a set of triples in its representation (and state) called
the <a title="Containment triples">containment triples</a> that follow a fixed pattern.
@@ -883,7 +884,7 @@
<code>ldp:contains</code> and objects indicating the URIs of the contained resources.
A POST to this container will create a new resource
and add it to the list of contained resources by adding a new containment triple
- to the container. This type of container is also refered to as
+ to the container. This type of container is also referred to as
<a title="">Linked Data Platform Basic Container</a>.</p>
<p>Sometimes it is useful to use a subject
@@ -981,7 +982,7 @@
and <code>http://example.org/netWorth/nw1/liabilityContainer/</code> container
resources allows both assets and liabilities to be created.
</p>
- <p>This type of container is refered to as an <a title="Linked Data Platform Direct Container">LDP Direct Container</a>.
+ <p>This type of container is referred to as an <a title="Linked Data Platform Direct Container">LDP Direct Container</a>.
<a title="Linked Data Platform Direct Container">LDP Direct Container</a> adds the concept of <a title="Membership">membership</a>
and flexibilty on how to specify the <a title="Membership triples">membership triples</a>.
</p>
@@ -997,7 +998,7 @@
named graph for the net worth resource and then two others for asset and liability containers. This allows for
the membership triples to be represented with the named graph for the net worth resource, while the containment triples
would be represented within the liability and asset containers [[rdf11-concepts]]. Generally, the membership triples belong
- to the representation of a LDP-RS and the containment triples belong to the representation of the LDPC.
+ to the representation of an LDP-RS and the containment triples belong to the representation of the LDPC.
</p>
<p>Additionally, we could extend our net worth example to include a container for
@@ -1146,7 +1147,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 a LDPC MAY have an <code>rdf:type</code>
+ <section id="ldpc-typecontainer"><h2 class="normal">The representation of an LDPC MAY have an <code>rdf:type</code>
of only one 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>.
@@ -1193,7 +1194,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 a LDP server chooses to support this method,
+ When an LDP server supports this method,
this specification imposes the following new requirements for LDPCs.
</p>
@@ -1210,7 +1211,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 a LDPC results in the creation of an LDPR, a
+ When a successful HTTP <code>POST</code> request to an LDPC results in the creation of an LDPR, a
<a title="Containment triple">containmemt triple</a> MUST be added to the state of LDPC. The
<a title="Containment triple">containmemt triple</a> 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).
@@ -1221,7 +1222,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 a LDPC supports this behavior.
+ details on how clients can discover whether an 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
@@ -1307,7 +1308,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 a LDP server chooses to support this method,
+ When an LDP server supports this method,
this specification imposes the following new requirements for LDPCs.
</p>
@@ -1316,7 +1317,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 a 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 an 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 -->
@@ -1333,12 +1334,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 a LDP server chooses to support this method,
+ When an LDP server supports this method,
this specification imposes the following new requirements for LDPCs.
</p>
<section id="ldpc-del-contremovesconttriple"><h2 class="normal">
- When a LDPR identified by the object of a <a title="containment triples">containment triple</a> is deleted, the LDPC server MUST also remove
+ When an 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>
@@ -1350,7 +1351,7 @@
</section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
<section id="ldpc-del-contremovescontres"><h2 class="normal">
- When a LDPR identified by the object of a <a title="containment triples">containment triple</a> is deleted, and the LDPC server
+ When an 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 -->
@@ -1371,7 +1372,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 a LDP server chooses to support this method,
+ When an LDP server supports this method,
this specification imposes the following new requirements for LDPCs.
</p>
@@ -1383,7 +1384,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 a LDPC's <a title="Empty-container triples">empty-container triples</a>.
+ updating an LDPC's <a title="Empty-container triples">empty-container triples</a>.
</h2></section><!-- Was 5.8.1 / #ldpc-5_8_1 -->
</section>
@@ -1392,7 +1393,7 @@
<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 a LDPC server creates a
+ <section id="ldpc-options-linkmetahdr"><h2 class="normal">When an LDPC server creates a
<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>
@@ -1442,10 +1443,6 @@
</section> <!-- ldpbc General -->
-<section id="ldpbc-HTTP_POST">
-<h2>HTTP POST</h2>
-</section>
-
</section> <!-- ldpbc Basic -->
@@ -1539,7 +1536,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 a LDPC results in the creation of an LDPR,
+ When a successful HTTP <code>POST</code> request to an LDPC results in the creation of an 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
@@ -1551,7 +1548,7 @@
<h2>HTTP DELETE</h2>
<section id="ldpdc-del-contremovesmbrtriple"><h2 class="normal">
- When a LDPR identified by the object of a <a title="membership triples">membership triple</a> which was
+ When an 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>
@@ -1640,7 +1637,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 a LDPC server might delete a resource and then later re-use the
+ Certain specific cases exist where an 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.
@@ -2251,7 +2248,7 @@
<li>2013-07-11 - Removed all stubbed out sections 5.1.3, 5.3.2-6 (SS)</li>
<li>2013-07-11 - Various editorial clean up items from editor todo list (SS)</li>
<li>2013-07-11 - Removed closed issues that required no new spec changes: 50, 56, 16, 19, 17 (SS)</li>
- <li>2013-07-11 - ISSUE-51 Added how a LDPR can show which LDPC is it in (SS)</li>
+ <li>2013-07-11 - ISSUE-51 Added how an LDPR can show which LDPC is it in (SS)</li>
<li>2013-07-10 - Removed closed issues that required no new spec changes: 18, 35, 20 (SS)</li>
<li>2013-07-10 - ISSUE-44 move section 4.1.7 (relationships are simple RDF links) to guidance (SS)</li>
<li>2013-07-10 - ISSUE-72 take 2 - added ldp:MemberSubject to handle default case (SS)</li>
@@ -2275,7 +2272,7 @@
<li>2013-05-21 - ISSUE-35 Re-use of URIs on create; 5.2.9, 5.4.11, 5.5.4 (JA)</li>
<li>2013-05-21 - ISSUE-43 Slug in LDPC POSTs; 5.4.8, 5.4.10 (JA)</li>
<li>2013-05-21 - ISSUE-65 Remove firstPage in favor of Link rel=first, mostly hits 5.3.3/5.3.4 (JA)</li>
- <li>2013-05-17 - ISSUE-13 Updated 5.2.3 to say any resource can be in a LDPC and inserted 5.5.3 on rejecting member data on PUT to LDPC (SS)</li>
+ <li>2013-05-17 - ISSUE-13 Updated 5.2.3 to say any resource can be in an LDPC and inserted 5.5.3 on rejecting member data on PUT to LDPC (SS)</li>
<li>2013-05-17 - Tweaks to Terminology section for LDPR and LDPC (SS)</li>
<li>2013-05-17 - ISSUE-9 Moved section 4.1.7 out of spec to the <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Servers_should_serve_up_canonical_URLs">deployment guide</a> (SS)</li>
<li>2013-05-15 - Updated wording for 5.2.2 from to be more clear (SS)</li>