ISSUE-9 Moved section 4.1.7 out of spec to the Deployment_Guide
authorsspeiche
Fri, 17 May 2013 14:19:23 -0400
changeset 111 7b5387b10b06
parent 110 576fb5164fb6
child 112 41e5e59c1e26
ISSUE-9 Moved section 4.1.7 out of spec to the Deployment_Guide
ldp.html
--- a/ldp.html	Fri May 17 13:15:07 2013 -0400
+++ b/ldp.html	Fri May 17 14:19:23 2013 -0400
@@ -318,18 +318,7 @@
 		set explicitly.  This makes the representations much more useful to
 		client applications that don’t support inferencing.
 	</div>
-	<div id="ldpr-4_1_7" class="rule">4.1.7 Predicate URIs used in LDPR representations SHOULD be HTTP URLs.
-		 These predicate URIs MUST identify LDPRs whose representations are
-		retrievable. LDPR servers SHOULD provide an RDF Schema [[!RDF-SCHEMA]]
-		representation of these predicates.
-		
-	<div class="ldp-issue">
-	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/9">ISSUE-9</a></div>
-	Should properties used in LDPR representations be LDPRs?
-	</div>
-	</div>
-
-	<div id="ldpr-4_1_8" class="rule">4.1.8 LDPRs MUST use at least one RDF triple to represent a link
+	<div id="ldpr-4_1_7" class="rule">4.1.7 LDPRs MUST use at least one RDF triple to represent a link
 		(relationship) to another resource. In other words, having the source
 		resource’s URI as the subject and the target resource’s URI as the
 		object of the triple representing the link (relationship) is enough and
@@ -338,21 +327,21 @@
 		
 	<div class="ldp-issue">
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/44">ISSUE-44</a></div>
-	4.1.9.(now 4.1.8) is obscure or too restrictive
+	4.1.9.(now 4.1.7) is obscure or too restrictive
 	</div>
 	</div>
-	<div id="ldpr-4_1_9" class="rule">4.1.9 LDPR servers MAY support standard representations beyond those
+	<div id="ldpr-4_1_8" class="rule">4.1.8 LDPR servers MAY support standard representations beyond those
 		necessary to conform to this specification. These
 		could be other RDF formats, like N3 or NTriples, but non-RDF formats
 		like HTML [[!HTML401]] and JSON [[!RFC4627]] would be likely be common.
 	</div>
 		
-	<div id="ldpr-4_1_10" class="rule">4.1.10 LDPRs MAY be created, updated and deleted using methods not defined in
+	<div id="ldpr-4_1_9" class="rule">4.1.9 LDPRs MAY be created, updated and deleted using methods not defined in
 		this document, for example through application-specific means, SPARQL
 		UPDATE, etc. [[!SPARQL-UPDATE]], as long as those methods do not conflict with this specification's 
 		normative requirements.
 	</div>
-	<div id="ldpr-4_1_11" class="rule">4.1.11 LDPR server responses MUST use entity tags (either weak or strong 
+	<div id="ldpr-4_1_10" class="rule">4.1.10 LDPR server responses MUST use entity tags (either weak or strong 
 ones) as response <code>ETag</code> header values.
 	</div>
 	
@@ -377,7 +366,7 @@
 	Pagination for non-container resources
 	</div>
 
-	<div id="ldpr-4_1_12" class="rule">4.1.12 LDPR
+	<div id="ldpr-4_1_11" class="rule">4.1.11 LDPR
 		servers SHOULD enable simple creation and modification of LDPRs.
 		It is
 		common for LDPR servers to put restrictions on representations – for
@@ -466,7 +455,7 @@
 	</div>
 	<div id="ldpr-4_4_7" class="rule">4.4.7 LDPR servers SHOULD allow clients to update resources without
 		requiring detailed knowledge of server-specific constraints.  
-		This is a consequence of the requirement to <a href="#ldpr-4_1_12">enable simple creation and modification</a> of LPDRs.
+		This is a consequence of the requirement to <a href="#ldpr-4_1_11">enable simple creation and modification</a> of LPDRs.
 	</div>		
 </section>
 		
@@ -511,7 +500,7 @@
 	</div>
 	<div id="ldpr-4_7_2" class="rule">4.7.2 LDPR servers SHOULD allow clients to update resources without
 		requiring detailed knowledge of server-specific constraints.  
-		This is a consequence of the requirement to <a href="#ldpr-4_1_12">enable simple creation and modification</a> of LPDRs.
+		This is a consequence of the requirement to <a href="#ldpr-4_1_11">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-post-1">POST (to an LDPC)</a> and/or <a href="#ldpr-put">PUT</a> should be used as the standard way to create new LDPRs.
@@ -1200,7 +1189,7 @@
 	<div id="ldpc-5_4_9" class="rule">5.4.9 LDPC servers SHOULD allow clients to create new resources without
 		requiring detailed knowledge of application-specific constraints.
 		This is a consequence of the requirement to 
-		<a href="#ldpr-4_1_12">enable simple creation and modification</a> of LPDRs.
+		<a href="#ldpr-4_1_11">enable simple creation and modification</a> of LPDRs.
 	</div>
 </section>
 
@@ -1285,8 +1274,9 @@
 </p>
 <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130307/">Second Public Working Draft</a></em></blockquote>
 <ul>
+	<li>2013-05-15 - 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>
-	<li>2013-05-13 - ISSUE-49 Moved section 4.1.4 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-13 - ISSUE-49 Moved section 4.1.4 out of spec to the <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Predicate_URIs_SHOULD_be_HTTP_URLs">deployment guide</a>. (SS)</li>
 	<li>2013-05-08 - Removed closed issues 5, 7, 55 and 38 as the don't require edits. Added 64 and 65. (SS)</li>
 	<li>2013-05-08 - ISSUE-59 5.3.2 limited rdf:type of ldp:Container, removed 5.6.3, reworded 5.6.2, updated 1. (SS)</li>
 	<li>2013-04-15 - ISSUE-21 Added ldp:membershipPredicateInverse to 5.2.5 &amp; 5.5.2, created 5.2.5.1 &amp; 5.3.5.2 to indicate difference. (SS)</li>