W3C home > Mailing lists > Public > www-tag@w3.org > March 2008

RE: URI Declarations versus competing definitions]

From: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Fri, 21 Mar 2008 04:19:36 +0000
To: Pat Hayes <phayes@ihmc.us>
CC: "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>, John Cowan <cowan@ccil.org>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <184112FE564ADF4F8F9C3FA01AE50009FCE9CC6E3A@G1W0486.americas.hpqcorp.net>

> From: Pat Hayes [mailto:phayes@ihmc.us]
> [ . . . ]
>       > I should publish an ontology using his URI but
>       > correcting his error, and maybe (if possible) indicate
>       > explicitly that this ontology is a correction to his
>       > ontology, which is (in my opinion, of course)
>       > deprecated. Maybe I can include an annotation property
>       > to a comment indicating the reason (for humans to
>       > read). The world now has two versions of an ontology,
>       > and its up to others which they want to use.
> > And therein lies the problem with the approach that you're
> > describing. The world is now faced with the problem of
> > deciding which ontology to use.
> THIS IS NOT A PROBLEM. This is the absolute basis of the way
> that the SWeb will succeed.

I disagree. I think the SWeb can hobble along that way, but it
will work better if applications can determine what ontology to
use more easily more often.

Permitting competing URI definitions[1] for the same URI causes
URI collision[3], which makes it harder for a SWeb application to
determine the intended "meaning"[2] of a statement without human
assistance. Consider a statement such as:

  :thermostat :adjust <http://alice.example#foo> .

which is intended to indicate whether a thermostat should be
adjusted up or down. What must an application reading this
statement and encountering the URI http://alice.example#foo for
the first time do to determine the "meaning" of that URI?

Under the "URI declarations" approach, the application merely
needs to get the follow-your-nose definition. In contrast, under
the "competing definitions" approach, the application cannot be
assurred of getting the statement author's intended URI
definition by "following its nose" from the URI, because the
statement author may have based his/her statements on an
alternate definition of that URI. Thus it must either incur the
cost of finding and correctly deciding between competing URI
definitions -- a judgement call that it is unlikely to be able to
fully automate -- or risk misinterpreting the statement.

> I call it 'distributed syndication'. Communities will evolve by
> their mutual selection of commonly accepted ontologies.

If different communities adopt different definitions of the same
URI that sounds to me like a chaos of fiefdoms. That would defeat
a key purpose of the SWeb: the ability to serendipitously
connect, through use of common URIs, data produced by different

> A key part of this is that ontologies themselves be connected
> by machine-readable links which express mutual endorsement
> (currently called 'imports', confusingly). We need, to be sure,
> a richer vocabulary of such inter-ontology connections, which
> was part of our old 'named graph' proposal, which allows
> ontologies to deny, qualify, deprecate and otherwise positively
> or negatively relate themselves to other
> ontologies: and indeed these ideas are creeping into wider
> use, slowly.

Yes, that's needed under either architectural approach.

> [ . . . ]
>        Compare this with the architectural approach that I
>        described for URI declarations: One forces the world to
>        decide which *ontology* to use -- I'll call this the
>        ontology redefinition approach -- the other forces the
>        world to decide which *URI* to use.
> Nobody forces the world to do anything. Seems to me the
> difference is that in one, but not the other, a genuine
> disagreement is revealed as a logical inconsistency between
> ontologies.

No, disagreements can be expressed as logical inconsistencies
under either approach, as I described in

>        On the face of it, those options may seem quite
>        equivalent, because they both force a human to make a
>        value judgement that is not likely to be automatable.
>        But they're not equivalent.
>        Under the ontology redefinition approach, given a set of
>        assertions, an application cannot determine the meaning
>        of those assertions
> ?? An application can never determine meaning. SWeb
> applications can do things like detect inconsistency and
> subsumption, compute entailments, and so on.

By "meaning" I meant the URI definition that the author of those
assertions intended, thus permitting the reader to determine the
assertions' intended "meaning".

>        without *first* involving the human judgement step of
>        searching out the possible ontologies that might be
>        defined for each URI that is used, and deciding which
>        one to invoke.
> Nonsense. No application is obliged to search for alternatives.
> It will work with what it has got.

If a URI is permitted to have competing definitions, and the
application wishes to be assurred of using the right one, then I
do not see how the task of finding and judging between those
competing definitions can be avoided. Simply assuming that the
task will be done by something outside the application does not
make the task go away.

> [ . . . ]
> The two cases seem entirely equivalent to me. In both cases, a
> URI is used in an ontology, and a human has to decide whether
> they like the ontology or not.

No, in the URI declarations approach, a human gets to choose
which *URI* to use in writing a statement, and an application
reading that statement (in normal cases) knows what URI
definition to use: the follow-your-nose definition.

But in the competing definitions approach, a human gets to decide
which URI *definition* to use in writing a statement, and an
application reading that statement must *guess* which one was

Both approaches rely on the marketplace to decide on popularity,
but one approach more strongly associates each URI with a single
definition, thus easing a consuming application's task.

> Maybe this decision can be semi-automated, eg by software which
> reports unexpected inconsistencies and traces them to their
> source. Neither option provides any automatic way of finding a
> better ontology if all you have is a broken one: but at least
> if the URI is the same, you can embark on a search for newer
> ontologies mentioning that URI.

You can embark on such a search if the *relationship* between the
"broken" and "fixed" ontologies is expressed.

> [ . . . ] Right now, we can
> typically get from the URI root of a URIref to an ontology
> which was the original 'source' of that URIref, and such
> ontologies are typically treated as definitive. What is
> markedly different about your proposal?

I am not proposing a new approach. If such an ontology is treated
as definitive then that *is* the URI declarations approach, and
it has been used and advocated by various people for a while.
However, as I explained in
(a) it is not yet universally accepted in the Semantic Web
community; and
(b) it lacked a simple, descriptive name.


1. By the "meaning" of a URI I mean the set of assertions that
should be accepted if the URI is used in a statement to denote a

2. By "URI definition" of a URI I mean the set of assertions that
should be accepted if the URI is used in a statement to denote a

3. http://www.w3.org/TR/webarch/#URI-collision

David Booth, Ph.D. HP Software
+1 617 629 8881 office  |  dbooth@hp.com

Opinions expressed herein are those of the author and do not
represent the official views of HP unless explicitly stated
Received on Friday, 21 March 2008 04:21:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:53 GMT