- From: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
- Date: Mon, 23 Jun 2014 15:08:53 -0400
- To: Cody Burleson <cody.burleson@base22.com>
- Cc: Linked Data Platform WG <public-ldp-wg@w3.org>
On Jun 23, 2014, at 11:19 AM, Cody Burleson <cody.burleson@base22.com> wrote:
> Regarding today's discussion about the ambiguity and possible inaccurate nature of our use of the the term "canonical"...
>
> How about "identifying" ?
I'm sorry I missed this discussion.
In the quoted section, this isn't about the *term* "canonical".
It's about the *link relation* "canonical".
As I've said before -- <link rel="canonical" ...> (whether
communicated via HTTP header or as part of the payload) ...
is the existing solution to this issue -- of multiple URIs
leading by dereference to a single resource, which is *itself*
denoted by one *canonical* URI.
So again, in other words -- the *canonical* URI (which denotes
the resource of which the server is providing a representation)
should be in the *Link* header with *rel* canonical -- and/or
in the payload, expressing the same.
<link rel="canonical"> tells the agent that, no matter what URI
was dereferenced to get this response -- the URI which *denotes
the represented resource* is the one provided *here*.
> Here's how it reads:
>
> <section>
> <h3>Respond with identifying 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, an <em>identifying</em> URL, for
> the LDPR. This identifying 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 on either URL with a single
> (identity) URL.</p>
>
> <p>Clients should use the identifying URL as an LDPR's
> identity; for example, when determining if two URLs refer
> to the same resource clients should compare the identifying
> URLs, not the URLs used to access the resources.</p>
Reworded (perhaps reverted?) --
<h3>Respond with canonical URIs and use them for
identity comparison</h3>
<p>Clients may access a single LDPR by dereferencing
multiple URIs. An LDPR server's response to each of those
requests should include a single consistent URI, a
<em>canonical</em> URI, for the LDPR. This canonical
URI may be found in the response's Link header with
rel="canonical", and potentially also in the representation
of the LDPR. A common case is URIs that vary by protocol,
one HTTP and one HTTPS, but are otherwise identical. In
most cases, dereferencing those two URIs leads to the same
resource, and the server should respond to requests on
either URI with a single (canonical) URI (usually HTTP,
for this example).</p>
<p>Clients should treat the canonical URI as an LDPR's
identifier; for example, when determining if two URIs refer
to the same resource, clients should compare the canonical
URIs, not the URIs which were dereferenced to access the
resources.</p>
Regards,
Ted
--
A: Yes. http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?
Ted Thibodeau, Jr. // voice +1-781-273-0900 x32
Senior Support & Evangelism // mailto:tthibodeau@openlinksw.com
// http://twitter.com/TallTed
OpenLink Software, Inc. // http://www.openlinksw.com/
10 Burlington Mall Road, Suite 265, Burlington MA 01803
Weblog -- http://www.openlinksw.com/blogs/
LinkedIn -- http://www.linkedin.com/company/openlink-software/
Twitter -- http://twitter.com/OpenLink
Google+ -- http://plus.google.com/100570109519069333827/
Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers
Received on Monday, 23 June 2014 19:09:18 UTC