--- a/ldp.html Sat Jan 12 14:11:24 2013 -0500
+++ b/ldp.html Sat Jan 12 14:14:14 2013 -0500
@@ -237,14 +237,22 @@
questions such as:</p>
<ul>
<li>What resource formats should be used?</li>
- <li>What literal value types should be used?</li>
- <li>Are there some typical vocabularies that should be reused?</li>
<li>How is optimistic collision detection handled for updates?</li>
<li>What should client expectations be for changes to linked-to resources,
such as type changes?</li>
<li>What can servers do to ease the burden of constraints for resource
creation?</li>
</ul>
+ <p>Additional informative guidance is available on the <a
+ href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide"
+ class="external "
+ title="Deployment Guide"
+ rel="nofollow">working group's wiki</a> that addresses deployment
+ questions such as:</p>
+ <ul>
+ <li>What literal value types should be used?</li>
+ <li>Are there some typical vocabularies that should be reused?</li>
+ </ul>
<p>The following sections define the rules and
guidelines for use of LDPRs.</p>
@@ -254,8 +262,8 @@
<h2 id="ldpr-general">General</h2>
<div id="ldpr-4_1_1" class="rule">4.1.1 LDPR servers MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].</div>
- <div id="ldpr-4_1_2" class="rule">4.1.2 LDPR servers MUST provide an RDF representation for LDPRs. The subject
- is typically the LDPR itself.
+ <div id="ldpr-4_1_2" class="rule">4.1.2 LDPR servers MUST provide an RDF representation for LDPRs.
+ The HTTP Request-URI of the LDPR is typically the subject of most triples in the response.
</div>
<div id="ldpr-4_1_3" class="rule">4.1.3 LDPR servers MAY host a mixture of LDPRs and non-LDPRs. For example, it
is common for LDPR servers to need to host binary or text resources
@@ -266,7 +274,9 @@
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
- LDPR. Clients SHOULD use that canonical URL to identify the LDPR.
+ LDPR. Clients SHOULD use the canonical URL as an LDPR's identity;
+ for example, when determining if two URLs refer to the same resource clients
+ need to compare the canonical URLs not the URLs used to access the resources.
</div>
<div id="ldpr-4_1_5" class="rule">4.1.5 LDPRs SHOULD reuse existing vocabularies instead of creating
their own duplicate vocabulary terms. In addition to this general rule, some specific cases are
@@ -276,11 +286,7 @@
[[!DC-TERMS]], RDF [[!RDF-PRIMER]] and RDF Schema [[!RDF-SCHEMA]], whenever
possible.
</div>
- <div id="ldpr-4_1_6" class="rule">4.1.6 LDPR predicates MUST use well-known RDF vocabularies as defined in
- section <a href="#ldpr-prop">4.8 Common Properties</a> wherever a predicate’s meaning matches
- one of them.
- </div>
- <div id="ldpr-4_1_6_1" class="rule">4.1.6.1 LDPRs MUST use the predicate <code>rdf:type</code> to
+ <div id="ldpr-4_1_6" class="rule">4.1.6 LDPRs MUST use the predicate <code>rdf:type</code> to
represent the concept of type. The use of non-standard type
predicates, as well as <code>dcterms:type</code>, is
discouraged (see <a href="#ldpr-prop">4.8 Common Properties</a>), as it is not recommended
@@ -386,6 +392,9 @@
<section>
<h2 id="ldpr-HTTP_PUT">HTTP PUT</h2>
+ <p>This specification imposes the following new requirements on HTTP PUT for LDPRs
+ only when the LDPR supports that method. This specification does not impose any
+ new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
<div id="ldpr-4_4_1" class="rule">4.4.1 If HTTP PUT is performed on an existing resource, LDPR servers MUST
replace the entire persistent state of the identified resource with
@@ -409,7 +418,7 @@
its representation. LDPR servers SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
to detect collisions. LDPR servers MUST respond with status code 412
(Condition Failed) if <code>ETag</code>s fail to match if there are no other
- errors with the request. [[!HTTP11]]
+ errors with the request [[!HTTP11]].
</div>
<div id="ldpr-4_4_3" class="rule">4.4.3 LDPR clients SHOULD always assume that the set of predicates for a
resource of a particular type at an arbitrary server is open, in the
@@ -440,6 +449,10 @@
<section>
<h2 id="ldpr-HTTP_DELETE">HTTP DELETE</h2>
+ <p>This specification imposes the following new requirements on HTTP DELETE for LDPRs
+ only when the LDPR supports that method. This specification does not impose any
+ new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
+
<div id="ldpr-4_5_1" class="rule">4.5.1 LDPR servers MUST remove the resource identified by the Request-URI.
After a successful HTTP DELETE, a subsequent HTTP GET on the same
Request-URI MUST result in a 404 (Not found) or 410 (Gone) status
@@ -465,8 +478,12 @@
<section>
<h2 id="ldpr-HTTP_PATCH">HTTP PATCH</h2>
+ <p>This specification imposes the following new requirements on HTTP PATCH for LDPRs
+ only when the LDPR supports that method. This specification does not impose any
+ new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
+
<div id="ldpr-4_7_1" class="rule">4.7.1 LDPR servers MAY implement HTTP PATCH to allow modifications,
- especially partial replacement, of their resources. [[!RFC5789]] No
+ especially partial replacement, of their resources [[!RFC5789]]. No
minimal set of patch document formats is mandated by this document.
</div>
<div id="ldpr-4_7_2" class="rule">4.7.2 LDPR servers SHOULD allow clients to update resources without
@@ -573,7 +590,7 @@
<p>
The predicate <code>dcterms:type</code> SHOULD NOT be
used in LDPRs, instead use <code>rdf:type</code> [[!DC-RDF]].
- See also <a href="#ldpr-4_1_6_1">4.1.6.1 LDPRs MUST use <code>rdf:type</code></a>.
+ See also <a href="#ldpr-4_1_6">4.1.6 LDPRs MUST use <code>rdf:type</code></a>.
</p>
</div>
@@ -1003,7 +1020,7 @@
discover <dfn><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>
<div id="ldpc-5_2_1" class="rule">5.2.1 LDPC servers MUST also be conformant LDPR servers. A Linked Data Platform
- Container is a resource that is a Linked Data Platform Resource.
+ Container MUST also be a conformant Linked Data Platform Resource.
</div>
<div id="ldpc-5_2_2" class="rule">5.2.2 The same resource MAY be a member of multiple LDPCs. This happens
commonly if one container is a view onto a larger container.
@@ -1073,12 +1090,16 @@
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
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).
+ MUST return a HTTP status code 404 (Not Found). A 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
- page resource representation via a known LDPC as “<code><containerURL></code>”,
- the Request-URI of “<code><containerURL>?firstPage</code>”, MUST return a HTTP status code 404 (Not
+ 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>”,
+ 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
pages indicated by a client supplying the token “<code>firstPage</code>”
@@ -1142,6 +1163,10 @@
<section>
<h2 id="ldpc-HTTP_POST">HTTP POST</h2>
+ <p>This specification imposes the following new requirements on HTTP POST for LDPCs
+ only when an LDPC supports that method. This specification does not impose any
+ new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
+
<div id="ldpc-5_4_1" class="rule">5.4.1 LDPC clients SHOULD create member resources by submitting a representation as
the entity body of the HTTP POST to a known LDPC. LDPC servers MUST
respond with status code 201 (Created) and the <code>Location</code>
@@ -1196,6 +1221,10 @@
<section>
<h2 id="ldpc-HTTP_PUT">HTTP PUT</h2>
+ <p>This specification imposes the following new requirements on HTTP PUT for LDPCs
+ only when an LDPC supports that method. This specification does not impose any
+ new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
+
<div id="ldpc-5_5_1" class="rule">5.5.1 LDPC servers SHOULD NOT allow HTTP PUT to update a LDPC’s members and
if the server receives such a request, it SHOULD respond with a 409
(Conflict) status code.
@@ -1208,6 +1237,10 @@
<section>
<h2 id="ldpc-HTTP_DELETE">HTTP DELETE</h2>
+ <p>This specification imposes the following new requirements on HTTP DELETE for LDPRs
+ only when a LDPC supports that method. This specification does not impose any
+ new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
+
<div id="ldpc-5_6_1" class="rule">5.6.1 If a LDPC server supports deletion of the LDPC, the server MAY also
delete the resources that are referenced as its contents.
</div>
@@ -1227,6 +1260,10 @@
<section>
<h2 id="ldpc-HTTP_PATCH">HTTP PATCH</h2>
+ <p>This specification imposes the following new requirements on HTTP PATCH for LDPCs
+ only when a LDPC supports that method. This specification does not impose any
+ new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
+
<div id="ldpc-5_8_1" class="rule">5.8.1 LDPC servers are RECOMMENDED to support HTTP PATCH as the preferred
method for updating LDPC non-membership properties.
</div>