W3C home > Mailing lists > Public > www-tag@w3.org > October 2011

Re: Comments on "Interoperability of referential uses of hashless URIs"

From: David Booth <david@dbooth.org>
Date: Mon, 24 Oct 2011 10:02:34 -0400
To: www-tag <www-tag@w3.org>
Cc: Jonathan Rees <jar@creativecommons.org>
Message-ID: <1319464955.2178.85770.camel@dbooth-laptop>
Further comments . . .

On Wed, 2011-10-19 at 15:47 -0400, David Booth wrote:
> Regarding
> http://www.w3.org/2001/tag/2011/09/referential-use.html

Although this document provides a very good example of the harm that can
occur when a web publisher uses a different convention for the semantics
of a URI than the consumer of that page assumes -- see the Creative
Commons licensing example in the section called "The Conflict" -- I
think there is some danger in the way this document describes the
problem and potential solutions, in that it subtly perpetuates the idea
that ambiguity is universally harmful and can be avoided by consistent
use of better conventions.

For example, the document says: "It should be clear that these answers
[D2 and S2] are mutually exclusive."  But in the general case, these
answers are *not* mutually exclusive.  These answers (i.e., the
conventions described as D2 and S2) only create a conflict for
applications that *need* to distinguish between the two resources that
the use of both conventions simultaneously would conflate.  But for
applications that do not need to make such distinctions, there is no

Second, it is impossible to remove all ambiguity anyway.  Thus, it is
misleading to call out this particular kind of ambiguity as somehow
special or deserving of more architectural attention than other kinds of
ambiguity.  The best a URI owner can do is to make a URI unambiguous
*within* the particular class of applications that the URI owner is
attempting to support -- hopefully a fairly wide class of applications,
though never universal.  In the Creative Commons licensing example,
where the landing page becomes conflated with the artistic content to be
licensed, the publisher clearly failed to do that very well, because
there are currently two conventions in use, and a machine cannot
reliably know which convention a particular site has used.


> This document provides a very good explanation and example of the harm
> that can be caused by the use of conflicting conventions around URI use.
> The Creative Commons licensing case is a great example, as the publisher
> of http://www.jamendo.com/en/album/78807 (for example) has created an
> ambiguity problem for consumers who do not know which convention the
> site has used.
> However, the document seems to assume that the solution to this problem
> (i.e., the conventions that the W3C should recommend) *must* prevent the
> ambiguity problems that are described in section "The Conflict".  But I
> think what is required from an architectural perspective is not that the
> conventions *necessarily* prevent such ambiguity (because we will always
> have sites of varying quality), but that the conventions support the
> *ability* of publishers to avoid such ambiguity problems if they choose
> to do so, and the conventions furthermore encourage publishers to do
> so.  
> In other words, another potential way forward is to permit both
> conventions D2 ("A hashless URI refers to the document at that URI, when
> there is one") and S2 ("A hashless URI permitting retrieval refers to
> something described by what's retrieved") to be used, but recommend that
> S2 be used *only* in cases where the ambiguity that it creates is likely
> to be harmful, such as in the Creative Commons licensing case.
> Such guidance also might acknowledge that: (a) it is impossible for the
> publisher to foresee all of the downstream uses that could lead to
> conflict or ambiguity; and (b) downstream conflict or ambiguity are
> impossible to prevent anyway (in the general case), regardless of what
> conventions are adopted.

David Booth, Ph.D.

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.
Received on Monday, 24 October 2011 14:02:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:40 UTC