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 18:14:57 -0400
To: Tim Berners-Lee <timbl@w3.org>
Cc: www-tag <www-tag@w3.org>, Jonathan Rees <jar@creativecommons.org>
Message-ID: <1319494497.2178.91610.camel@dbooth-laptop>
Hi Tim,

No, I'm not assuming that the publisher is the only agent using the
URIs.  But I *am* assuming that the publisher (or URI owner) is
implicitly supporting a particular class of applications, by deciding
how those URIs are defined.  (I.e., in deciding on the definition of the
resource to which the URI is bound, as described in 
http://www.w3.org/TR/webarch/#def-uri-ownership  .)  It may be a large
class of applications, but it is *not* universal, since it would be
impossible to mint URIs that would be suitable and unambiguous to all
possible applications.

It is true that two independent people can use the URI inconsistently,
even if *both* of them separately used that URI in a manner consistent
with the URI's definition.  This phenomenon is illustrated here:
http://dbooth.org/2010/ambiguity/paper.html#inconsistent-merge
This will *always* be the case -- it is not unique to this particular
kind of "web page versus primary subject" ambiguity. 
David


On Wed, 2011-10-19 at 17:31 -0400, Tim Berners-Lee wrote:
> David,
> 
> Your solution though surely assumes that only one agent, the publisher,
> is doing all this use of these URIs.    But that is not the case. 
> One person can publish a web page at a URI,  and two independent
> people can use that URI inconsistently without conferring or knowing each other exist.
> So no one is in a position to determine whether in this case
> ambiguity may be a problem.
> 
> Tim
> 
> On 2011-10 -19, at 15:47, David Booth wrote:
> 
> > Regarding
> > http://www.w3.org/2001/tag/2011/09/referential-use.html
> > 
> > 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.
> > http://dbooth.org/
> > 
> > Opinions expressed herein are those of the author and do not necessarily
> > reflect those of his employer.
> > 
> > 
> > 
> 
> 
> 
> 

-- 
David Booth, Ph.D.
http://dbooth.org/

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

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