Re: ldp-ISSUE-49 (Canonical-URI): Canonical URL - how to communicate its value to clients

hello all.

On 2013-02-13 14:25 , "Linked Data Platform (LDP) Working Group Issue
Tracker" <sysbot+tracker@w3.org> wrote:
>https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#general clause
>4.1.4 states: 4.1.4 Clients can access a LDPR using multiple URLs, for
>example when DNS aliasing is used. A 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.

i am wondering how this is going to be implemented or even
tested/enforced. if you access the same resource via various URIs, these
are not the same resources (per definitionem). what kind of mechanism may
be used to overlay a layer of "sameness" seems to be way outside of the
scope of something like LDP, and DNS aliasing is one of the many many ways
in which some level of sameness could be established.

even if we thought that LDP somehow should resolve sameness across URIs, i
am wondering how that should even work. it is not clear that it is the
*same* LDP service responding to requests to the various URIs that may
have some sameness to them, so would we require that LDP servers establish
some behind-the-scenes protocol to communicate, so that they can inform
clients about it?

as far as URIs are concerned, identity is established by identifier, and
nothing else. i think we would enter rather dangerous territory if we
changed this fundamental concept at the level of LDP. if there are
scenarios where sameness goes beyond URI equality, then it's up to these
to establish conventions and/or mechanisms how to do that, but LDP should
stay out of that.

>I want to verify that the WG believes the Location header is the
>appropriate vehicle for communicating the canonical URI for a resource.

if we want to get into the identity game, then i think it might best be in
the "best practices" part of LDP. personally, i think 308 would be good,
but that seems to be in some kind of limbo (maybe waiting for HTTPbis? i
don't really know...). moving identity management into the responsibility
of clients might be more error-prone than trying to address is using basic
HTTP mechanisms, but that's still assuming that LDP services actually know
aliases (see my above skepticism).

>The original use of C-L appears to have been cases where you GET a
>resource subject to conneg, the server offers several different
>representations, and each representation is ALSO a URI-addressable
>resource.  The original use of L appears to have been only Create and
>redirects.

i think this sums it up nicely. like many things on the web, these things
weren't developed top-down following a Grand Plan, but instead developed
bottom-up based on requirements and how early adopters actually used them.

>Looking through the link relations registry, I see "canonical" being
>defined in RFC 6596 [6] (Info'l though, not Standards track, but I'm
>unclear how much that matters in a case like this - it is in The link
>relation registry)

agreed that the status doesn't matter. but just serving links would be a
much weaker way of trying to make sure that canonical URIs are being used
than using HTTP mechanisms. i think if LDP does it, depending on HTTP
might be the better way to go. but since i think it should be "best
practices" only anyway, we could list both alternatives and state the pros
and cons.

cheers,

dret.

Received on Monday, 11 March 2013 05:45:53 UTC