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

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

From: David Booth <david@dbooth.org>
Date: Wed, 03 Oct 2012 14:54:48 -0400
To: Jonathan A Rees <rees@mumble.net>
Cc: www-tag@w3.org
Message-ID: <1349290488.1975.4141.camel@dbooth-laptop>
More background reading for TAG issue-57 discussion:

 - "Framing the URI Resource Identity Problem: The Fundamental
Use Case of the Semantic Web": 

 - "Resource Identity and Semantic Extensions: Making Sense
of Ambiguity":

And some basic points that should be kept in mind in thinking
about TAG issue-57 (and httpRange-14):

1. Ambiguity is a fact of life.  In spite of the AWWW's
statement that "By design, a URI identifies one resource",
http://www.w3.org/TR/webarch/#id-resources ambiguity of
reference is inescapable.  This is well established in
philosophy, and basically boils down to the fact that when
descriptions are used to define things, it is always possible
to make finer distinctions than a description anticipated.

2. Ambiguity is *relative* to the application.  In spite of
the fact that a URI's referent is inherently ambiguous, such
ambiguity may or may not matter to a particular application.
A URI that denotes influenza but fails to distinguish between
different kinds of influenza may be perfectly UNambiguous
to an application that merely needs to distinguish between
viral infections and bacterial infections, whereas it will be
hopelessly ambiguous to an application that attempts to measure
the incidence of different influenza strains.  Similarly,
a URI that ambiguously denotes both a web page and a toucan
may be perfectly UNambiguous to an application that cares only
about different kinds of birds, or to a different application
that cares only about web pages, even if it is ambiguous to
an application that needs to distinguish between birds and
web pages.

3. The context of this issue is RDF.  This issue only matters
in the RDF / Semantic Web world.  Nobody else cares about the
"meaning" of a URI.  The Semantic Web is the use case that
motivates this issue.  Although in concept the Semantic Web does
not require RDF per se, as a practical matter RDF is the lingua
franca for the Semantic Web.  Furthermore, since this same
issue would arise in any formal/machine-processable language
in which URIs are used as names for things, for simplicity,
and without loss of generality, we can assume that the context
of this issue is RDF.

4. Because we are attempting to address the meaning of a
URI in the context of RDF, it is essential to understand a
small amount about how the RDF semantics works -- not the gory
details or all the mathematical formalism, but one key point.
This key point is that RDF semantics does not assign a unique
interpretation to an RDF graph or URI.  As explained in the
RDF Semantics specification:

  "It is usually impossible to assert enough in any language
  to completely constrain the interpretations to a single
  possible world, so there is no such thing as 'the' unique
  interpretation of an RDF graph. In general, the larger an
  RDF graph is - the more it says about the world - then the
  smaller the set of interpretations that an assertion of
  the graph allows to be true - the fewer the ways the world
  could be, while making the asserted graph true of it."

Thus, there is no such thing as *the* referent of a URI in an
RDF graph.  A URI can have *many* referents -- infinitely many.
The referent of a URI only becomes unique when a particular
interpretation of that graph is selected, and that is up to
the *consumer* of that RDF graph -- not the RDF semantics.
This is not merely a technicality that can be waved away,
it is the formal manifestation of point #1 above.

5. Interpretations correspond to applications.  RDF graphs
are designed to be consumed by *applications* -- not people.
Thus, in essence, it is an RDF application that selects an
interpretation of a given RDF graph: different interpretations
correspond to different applications.  Thus, in an RDF graph
a URI that identifies one resource in one application may
identify a *different* resource in another application if those
applications have different purposes.  Compare point #2 above.


A consequence of the above points is that if one sets out to
solve TAG issue-57 (or httpRange-14) under the premise that
"a URI identifies one resource", then one will be heading in
the wrong direction, and solving it will be an exceedingly long
and difficult journey.  A solution might eventually be found,
but unless that faulty premise is corrected, it is apt to end
up being a solution to the wrong problem.

Since this message is only intended to provide general
background material for issue-57, I will comment on Proposal27
in a separate message.


David Booth, Ph.D.

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.
Received on Wednesday, 3 October 2012 18:55:17 UTC

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