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

Re: Ambiguity (was: issue-57 background reading for F2F (short required reading)

From: <david@dbooth.org>
Date: Mon, 15 Oct 2012 23:55:35 -0400
To: Graham Klyne <GK@ninebynine.org>, www-tag <www-tag@w3.org>
Message-ID: <a392501be9b1dba5246a2356aa629cdf@dbooth.org>
On Thu, 2012-10-11 at 09:32 +0100, Graham Klyne wrote:
[ . . . ]
> The example I picked, 
> http://dbpedia.org/resource/The_Lord_of_the_Rings, was
> chosen not because the notion of this "work" has a clear unambiguous 
> definition
> (it doesn't), but because people seem to have a broad common 
> understanding of
> what is meant, and it is introduced in a way that distinguishes it 
> from
> completely different referents that might be considered in the 
> context of the
> Web (such as the dbpedia web page, which has a different URI).  Thus, 
> we can say
> many things about what the URI does *not* denote (the web page, a 
> particular
> copy of the book, etc.), and we can make statements about it that 
> most who know
> the work would agree to be true (it's author, its subject matter, 
> etc.).

I agree that colloquially speaking, people have a broad common
understanding of what is meant by that URI.   But if we really examine
what it means to have a "broad common understanding" in the context of
RDF and the Semantic Web, it boils down to implicitly *assuming* a
particular class of applications for which that URI appears to be
unambiguous.  If that class of applications happens to be commonly 
then it appears as though people have a broad common understanding of
what is meant.  But as soon as you step outside of that class, to an
application that needs finer distinctions, the URI becomes ambiguous.

Thus, in my view it is best to think of UNambiguity as being *relative*
to the application -- not a characteristic the URI (or its resource 

David Booth, Ph.D.

Opinions expressed herein are those of the author and do not 
reflect those of his employer.
Received on Tuesday, 16 October 2012 03:55:57 UTC

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