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

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

From: Graham Klyne <GK@ninebynine.org>
Date: Sat, 06 Oct 2012 08:14:20 +0100
Message-ID: <506FDA4C.3060708@ninebynine.org>
To: David Booth <david@dbooth.org>
CC: Jonathan A Rees <rees@mumble.net>, www-tag@w3.org

While I agree with most of what you say, I think it's maybe unhelpful to treat 
the consequences of RDF's logical formalism as the whole story.  There is the 
matter of *intended* meaning of a URI which, as you indicate, can never be 
completely nailed down formally, does exist pragmatically and unambiguously in 
many cases, and is (AIUI) part of the "by design ..." of the web.

When humans are "in the loop", then we can reasonably appeal to a human notion 
of unambiguous (e.g. http://dbpedia.org/resource/The_Lord_of_the_Rings refers to 
the work, not the web page, or some particular copy).  When humans are not in 
the loop, then it doesn't really matter, as long as the logical inferences 
provided are consistent with what people expect, and the logical formalism does 
provide for that much.

So, while I think we mostly agree on the details, I personally think it's OK to 
talk about *the* [intended] referent of a URI as long as we don't expect the 
formal logic to constrain itself to that single denotation.


On 03/10/2012 19:54, David Booth wrote:
> More background reading for TAG issue-57 discussion:
>   - "Framing the URI Resource Identity Problem: The Fundamental
> Use Case of the Semantic Web":
> http://dbooth.org/2012/fyn/Booth-fyn.pdf
>   - "Resource Identity and Semantic Extensions: Making Sense
> of Ambiguity":
> http://dbooth.org/2010/ambiguity/paper.html
> 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."
>    http://www.w3.org/TR/rdf-mt/#interp
> 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.
> Thanks!
Received on Saturday, 6 October 2012 08:07:38 UTC

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