ldp.html
changeset 37 3e92cccfe6a3
parent 33 3c8c101f3f97
child 38 8b8bcfc801c7
--- a/ldp.html	Thu Jan 03 16:54:22 2013 -0500
+++ b/ldp.html	Mon Jan 07 16:15:24 2013 -0500
@@ -239,14 +239,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>
 		
@@ -256,8 +264,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
@@ -268,7 +276,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
@@ -278,11 +288,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
@@ -388,6 +394,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
@@ -411,7 +420,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
@@ -442,6 +451,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
@@ -467,8 +480,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
@@ -575,7 +592,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>
 	
@@ -1005,7 +1022,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.
@@ -1075,12 +1092,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>&lt;containerURL&gt;?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>&lt;containerURL&gt;?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>&lt;containerURL&gt;</code>”,
-		the Request-URI of “<code>&lt;containerURL&gt;?firstPage</code>”, MUST return a HTTP status code 404 (Not
+		page resource representation from a known LDPC whose URL is “<code>&lt;containerURL&gt;</code>” by using
+		the Request-URI “<code>&lt;containerURL&gt;?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>&lt;containerURL&gt;?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>”
@@ -1144,6 +1165,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>
@@ -1198,6 +1223,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.
@@ -1210,6 +1239,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>
@@ -1229,6 +1262,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>