--- a/ldp.html Fri May 10 14:39:52 2013 +0200
+++ b/ldp.html Mon May 13 09:27:54 2013 -0400
@@ -299,40 +299,26 @@
is common for LDPR servers to need to host binary or text resources
that do not have useful RDF representations.
</div>
- <div id="ldpr-4_1_4" class="rule">4.1.4 Clients can access an LDPR using multiple
- URLs, for example when DNS aliasing is used. An LDPR server MUST
- 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 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 class="ldp-issue">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/49">ISSUE-49</a></div>
- Canonical URL - how to communicate its value to clients
- </div>
- </div>
-
- <div id="ldpr-4_1_5" class="rule">4.1.5 LDPRs SHOULD reuse existing vocabularies instead of creating
+ <div id="ldpr-4_1_4" class="rule">4.1.4 LDPRs SHOULD reuse existing vocabularies instead of creating
their own duplicate vocabulary terms. In addition to this general rule, some specific cases are
covered by other conformance rules.
</div>
- <div id="ldpr-4_1_5_1" class="rule">4.1.5.1 LDPR predicates SHOULD use standard vocabularies such as Dublin Core
+ <div id="ldpr-4_1_4_1" class="rule">4.1.4.1 LDPR predicates SHOULD use standard vocabularies such as Dublin Core
[[!DC-TERMS]], RDF [[!RDF-PRIMER]] and RDF Schema [[!RDF-SCHEMA]], whenever
possible.
</div>
- <div id="ldpr-4_1_6" class="rule">4.1.6 LDPRs MUST use the predicate <code>rdf:type</code> to
+ <div id="ldpr-4_1_5" class="rule">4.1.5 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, as it is not recommended
by the Dublin Core Metadata Initiative for use with RDF resources [[!DC-RDF]].
</div>
- <div id="ldpr-4_1_7" class="rule">4.1.7 LDPR representations SHOULD have at least one <code>rdf:type</code>
+ <div id="ldpr-4_1_6" class="rule">4.1.6 LDPR representations SHOULD have at least one <code>rdf:type</code>
set explicitly. This makes the representations much more useful to
client applications that don’t support inferencing.
</div>
- <div id="ldpr-4_1_8" class="rule">4.1.8 Predicate URIs used in LDPR representations SHOULD be HTTP URLs.
+ <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.
@@ -343,7 +329,7 @@
</div>
</div>
- <div id="ldpr-4_1_9" class="rule">4.1.9 LDPRs MUST use at least one RDF triple to represent a link
+ <div id="ldpr-4_1_8" class="rule">4.1.8 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
@@ -352,21 +338,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. is obscure or too restrictive
+ 4.1.9.(now 4.1.8) is obscure or too restrictive
</div>
</div>
- <div id="ldpr-4_1_10" class="rule">4.1.10 LDPR servers MAY support standard representations beyond those
+ <div id="ldpr-4_1_9" class="rule">4.1.9 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_11" class="rule">4.1.11 LDPRs MAY be created, updated and deleted using methods not defined in
+ <div id="ldpr-4_1_10" class="rule">4.1.10 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_12" class="rule">4.1.12 LDPR server responses MUST use entity tags (either weak or strong
+ <div id="ldpr-4_1_11" class="rule">4.1.11 LDPR server responses MUST use entity tags (either weak or strong
ones) as response <code>ETag</code> header values.
</div>
@@ -391,7 +377,7 @@
Pagination for non-container resources
</div>
- <div id="ldpr-4_1_13" class="rule">4.1.13 LDPR
+ <div id="ldpr-4_1_12" class="rule">4.1.12 LDPR
servers SHOULD enable simple creation and modification of LDPRs.
It is
common for LDPR servers to put restrictions on representations – for
@@ -1306,6 +1292,7 @@
</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-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-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 & 5.5.2, created 5.2.5.1 & 5.3.5.2 to indicate difference. (SS)</li>