--- a/ldp-bp/ldp-bp.html Mon Aug 26 23:08:12 2013 +0200
+++ b/ldp-bp/ldp-bp.html Mon Aug 26 23:41:51 2013 +0200
@@ -425,21 +425,25 @@
</p>
<p>
- In the RDF expressing Linked Data Platform Resources, fragments are useful because they can be expressed as relative URIs on the document describing them. This is particularly handy for
- describing a handful of resources that are frequently used together.
+ When expressing Linked Data Platform Resources in RDF, fragments are useful because they can be expressed as
+ relative URIs on the document describing them. This is particularly handy for describing multiple LDPRs whose
+ representations are contained within a single document.
</p>
<p>
- First, it provides the convenience and efficiency of brevity. Suppose, for example that you want to describe the resources foo, bar and baz.
- Since serving all of the descriptions in a single document is a acceptable, we can mint relative URIs within the document using the fragment
- identifier (<code><#foo></code>, <code><#bar></code> and <code><#baz></code>). The full URI is assumed to be the base URI, plus the
- hash mark, and the fragment identifier.
+ First, it provides the convenience and efficiency of brevity. Suppose, for example that you want to describe
+ the resources foo, bar and baz, which are contained in the same document. Since serving all of the descriptions
+ in a single document is a acceptable, we can mint relative URIs within the document using the fragment identifier
+ (<code><#foo></code>, <code><#bar></code> and <code><#baz></code>). The full URI is assumed to
+ be the base URI, plus the hash mark, and the fragment identifier.
</p>
+
<p>
- Second, it can help avoid certain complexities inherent with other approaches. Achieving the same result (three dereferenceable URIs) could be more involved, because you'd need to create and publish
- multiple documents, perhaps also having to setup 303 redirects.
- </p>
+ Second, it can help avoid certain complexities inherent with other approaches. Achieving the same result using
+ three independent dereferenceable URIs could be more involved because you'd need to create and publish multiple
+ documents, perhaps also having to setup 303 redirects.
+ </p>
<p><strong>See also:</strong></p>
@@ -537,7 +541,7 @@
<h4>Common Properties</h4>
- <strong>From Dublin Core URI: <a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a></strong>
+ <p><strong>From Dublin Core URI: <a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a></strong></p>
<table class="simple">
<thead>
@@ -605,7 +609,7 @@
<p>The predicate <code>dcterms:type</code> should not be used, instead use <code>rdf:type</code>. [[DC-RDF]].</p>
- <strong>From RDF URI: <a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a></strong>
+ <p><strong>From RDF URI: <a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a></strong></p>
<table class="simple">
<thead>
@@ -624,7 +628,7 @@
</tbody>
</table>
- <strong>From RDF Schema URI: <a href="http://www.w3.org/2000/01/rdf-schema#">http://www.w3.org/2000/01/rdf-schema#</a></strong>
+ <p><strong>From RDF Schema URI: <a href="http://www.w3.org/2000/01/rdf-schema#">http://www.w3.org/2000/01/rdf-schema#</a></strong></p>
<table class="simple">
<thead>
@@ -652,65 +656,47 @@
<section>
- <h3>Properly use q values</h3>
- <p>Not properly handling q values is a major problem in implementations of content negotiation.</p>
+ <h3>Use qvalues properly</h3>
+
+ <p>Quality factors allow the user or user agent to indicate the relative degree of preference for a media-range,
+ using the qvalue scale from 0 to 1. The default value is q=1. Take the following for example:</p>
+
+ <p><code>Accept: text/turtle; q=0.5, application/json</code></p>
+
+ <p>This should be interpreted as "I prefer application/json, but send me text/turtle if it is the best available
+ after a 50% mark-down in quality."</p>
+
+ <p>Improper handling of qvalues is a common problem in implementations of content negotiation.
+
+ <p>Refer to Section 14, Header Field Definitions, in the [[HTTP11]] specification to understand the proper use and evaluation
+ of qvalues for both client and server implementations.</p>
+
</section>
<section>
- <h3>Use canonical URIs for identity comparison</h3>
- <ul>
-
- <li>Location and/or Content-Location header contains canonical
- URI</li>
- <li>Clients should use canonical URI when comparing resources
- for "same-ness" (identity), even if the resources are accessed via
- distinct URLs.</li>
- <li>Most common case is URLs that vary by protocol, one HTTP
- and one HTTPS, but are otherwise identical. In most cases those
- two URLs refer to the same resource, and the server should respond
- to requests to either URL with a single (canonical) URL.</li>
- </ul>
- </section>
-
-
- <section>
- <h3>Servers should serve up canonical URLs</h3>
- <p>This was removed from the spec:</p>
- <blockquote>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.</blockquote>
-
- <p>
- As part of the discussion around <a
- href="http://www.w3.org/2012/ldp/track/issues/49">ISSUE-49</a> it
- was seen as most likely this should be implementation guidance.
- </p>
+ <h3>Respond with canonical URLs and use them for identity comparison</h3>
+
+ <p>Clients can access an LDPR using multiple URLs. An LDPR server should respond to each of those requests
+ using a single consistent URL, a canonical URL, for the LDPR. This canonical URL may be found in the response's
+ Location and/or Content-Location headers, and potentially also in the representation of the LDPR. A common case
+ is URLs that vary by protocol, one HTTP and one HTTPS, but are otherwise identical. In most cases those two URLs
+ refer to the same resource, and the server should respond to requests to either URL with a single (canonical) URL.</p>
+
+ <p>Clients should use the canonical URL as an LDPR's identity; for example, when determining if two URLs refer to the same resource clients should compare the canonical URLs, not the URLs used to access the resources.</p>
+
</section>
<section>
<h3>Representing relationships between resources</h3>
- <p>This was removed from the spec:</p>
- <blockquote>4.1.9 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 does not require the creation
- of an intermediate link resource to describe the relationship.</blockquote>
- <p>This addresses a misconception that the editors observed.
- Readers with certain background assume that one always needs a
- “link resource” to express a relationship.</p>
-
+ <p>
+ LDPRs can use one RDF triple to represent a link (relationship) to another resource.
+ Having the source resource’s URI as the subject and the target resource’s URI as the object of
+ the triple is enough. Contrary to a misconception that readers with certain backgrounds may assume,
+ the creation of an "intermediate link" resource is not required to express the relationship.
+ </p>
</section>
-
-
- </section>
+ </section><!-- End Best Practices Section -->
<section>
@@ -742,19 +728,13 @@
</section>
- <!--
- <section>
- <h3>Guideline 2</h3>
- <p>Eplurbis unum...</p>
- </section>
- -->
- </section>
+ </section><!-- End Guidelines Section -->
<section class='appendix'>
- <h2>Acknowledgements</h2>
- <p>Many thanks to Robin Berjon for making our lives so much
- easier with his cool tool.</p>
- </section>
+ <h2>Acknowledgements</h2>
+ <p>Many thanks to Robin Berjon for making our lives so much easier with his cool tool.</p>
+ <p>To Ashok Malhotra, Melvin Carvalho, Richard Cyganiak, and Steve Speicher for providing recommendations for improvement to the editors.</p>
+ </section>
</body>