--- a/ldp-bp/ldp-bp.html Tue Jul 15 08:55:37 2014 -0400
+++ b/ldp-bp/ldp-bp.html Tue Jul 15 16:43:40 2014 -0400
@@ -159,6 +159,14 @@
href : "http://lov.okfn.org/dataset/lov/",
publisher : "Open Knowledge Foundation (OKFN)"
},
+ "metaDataInURI" : {
+ title : "The use of Metadata in URIs",
+ href : "http://www.w3.org/2001/tag/doc/metaDataInURI-31",
+ editors : [ "Noah Mendelsohn", "Stuart Williams" ],
+ status : "finding",
+ deliveredBy : [ "http://www.w3.org/2001/tag/" ],
+ publisher : "W3C"
+ },
"RDF-PRIMER11" : {
title : "RDF 1.1 Primer",
href : "http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/",
@@ -349,7 +357,7 @@
things referred to by HTTP URIs can actually be looked up
("dereferenced"). This important principle was originally
outlined by Tim Berners-Lee as rule #2 of "the four rules"
- for linking data [[LD-DI]]]. It is therefore ideal that predicate
+ for linking data [[LD-DI]]. It is therefore ideal that predicate
URIs identify resources with representations that are retrievable. LDP
servers should at least provide [[RDF-SCHEMA]] representations of
these predicates where possible.</p>
@@ -361,7 +369,7 @@
their vocabularies useful for linking data should strive to provide
a retrievable representation of the properties their vocabularies
define. Consequently, implementers are also expected to use this
- standard as a benchmark for which to judge the efficacy of a
+ practice as a benchmark for which to judge the efficacy of a
vocabulary's use for linking data.</p>
</section>
@@ -379,7 +387,7 @@
predicate defined by [[RDF-SCHEMA]].
</p>
- <p>This provides a way for clients to easily determine the type
+ <p>This provides a way for clients to easily determine the type(s)
of a resource without having to perform additional processing or
make additional HTTP requests. For example, clients that cannot
infer the type because they do not support inferencing can benefit
@@ -402,9 +410,9 @@
<!-- http://www.w3.org/2012/ldp/track/issues/29 -->
<p>Relative URIs are useful to the Linked Data Platform in much
- the same ways that relative URLs [[RFC1808]] have been useful to
+ the same ways that relative URLs [[RFC3986]] have been useful to
traditional web systems. Since the things referred to by Linked Data
- URIs should ideally provide a retrievable representation, Linked
+ URIs should provide a retrievable representation [[LD-DI]], Linked
Data URIs are usually also URLs; they locate rather than just
identify. As such, the utilitarian value of relative URLs still
applies; especially since the LDP Container model promotes
@@ -440,9 +448,12 @@
<dt>Relative URIs can make resources more portable.</dt>
<dd>When information which is already known from the context of
the base resource's retrieval is omitted, there can be less
- information to modify when that information changes. This can make
- moving resources to new servers or to a new position in a
- containment hierarchy easier.</dd>
+ information to modify when its location changes. This can make
+ copying resources to new servers or to a new position in a
+ containment hierarchy easier; in the preceding example,
+ a process that clones just the container need not adjust any of
+ its member URIs.
+ </dd>
<dt>Relative URIs are convenient during development.</dt>
<dd>During development the scheme and network location
@@ -524,8 +535,12 @@
</p>
<p>In addition to making the use of relative URIs possible,
- hierarchical URIs make interacting with resources easier because
- they represent the actual structure of the underlying graph.</p>
+ hierarchical URIs make interacting with resources easier for users because
+ they represent the actual structure of the underlying graph.
+ Software agents (code acting on behalf of users [[WEBARCH]]) must be careful
+ before exploiting the structure of URIs, considering historical problems
+ when doing so ([[WEBARCH]], [[metaDataInURI]]).
+ </p>
</section>
@@ -537,8 +552,9 @@
<h4>Include a trailing slash in container URIs</h4>
<p>When representing container membership with hierarchical URLs,
- there is an advantage to including the trailing slash in the URI of
- a given container. Take the following container URI for example:</p>
+ including the trailing slash in a container's URI makes it
+ easier to use relative URIs.
+ Take the following container URI for example:</p>
<p>
<code>http://example.org/container1</code>
@@ -564,16 +580,18 @@
class='example' data-include='trailing-slash-2.ttl'
data-oninclude='fixCode'></pre>
- <p>But suppose that we ommit the trailing slash, issued an HTTP
+ <p>But suppose that we omit the trailing slash, issued an HTTP
GET, and the container returned the representation shown above. This
- could produce a graph that is isomorphic to the following:</p>
+ could produce a graph that is equivalent to the following:</p>
<pre title="Container URI is http://example.org/container1"
class='example' data-include='trailing-slash-3.ttl'
data-oninclude='fixCode'></pre>
- <p>That is not what was intended. The returned document would
- have to be more verbose:</p>
+ <p>That is not what was intended; the member URLs lack the
+ <code>container</code> path segment.
+ The returned document would
+ have to be more verbose in order to be correct:</p>
<pre title="Container URI is http://example.org/container1"
class='example' data-include='trailing-slash-4.ttl'
@@ -587,18 +605,20 @@
<section>
- <h3>Use fragments as object identifiers</h3>
+ <h3>Use fragments as relative identifiers</h3>
<p>
- The fragment identifier introduced by a hash mark (<b><code>#</code></b>)
- is the optional last part of a URI for an object, which is typically
- used to identify a subordinate or related object.
+ Resource URIs are permitted to end with a fragment; the fragment
+ component is delimited from the rest of the URI because it is
+ introduced by a hash mark (<b><code>#</code></b>).
+ For this reason, URIs with non-empty fragments are often called hash URIs;
+ a hash URI identifies a subordinate or related resource [[RFC3986]].
</p>
<p>
Take the URI,
<code>http://www.example.org/products#item10245</code>
- , for example. The base URI is the part preceding the hash mark,
+ , for example. The non-fragment portion of the URI is the part preceding the hash mark,
<code>http://www.example.org/products</code>
, and the fragment identifier is the part that follows,
<code>item10245</code>
@@ -613,7 +633,7 @@
<p>
First, it provides the convenience and efficiency of brevity.
- Suppose, for example, the resources foo, bar and baz, which are
+ Suppose, for example, the resources foo, bar, and baz are
contained in the same document. Since serving all of the
descriptions in a single document is acceptable, we can mint
relative URIs within the document using the fragment identifier (
@@ -622,8 +642,12 @@
<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.
+ ). [[LDP]] ensures that the default base URI is the document
+ URI (
+ <code>http://www.example.org/products</code>
+ ), so the absolute URI for each is
+ the base URI, plus the hash mark,
+ plus the fragment identifier.
</p>
@@ -926,7 +950,11 @@
<p>Clients should use the primary URL as an LDPR's identity;
for example, when determining if two URLs refer to the same resource
clients should compare the primary URLs, not the URLs used to
- access the resources.</p>
+ access the resources. Note that this usage <em>does</em> imply that the
+ client has sufficient reason to trust the headers and/or content
+ by which the primary URL is communicated to the client, which is
+ beyond what HTTP alone can guarantee [[RFC7231]].
+ </p>
</section>