RE: New version of URI Declarations [Usage scenarios]

There's a misconception here that I'll try to correct.  I apologize that I haven't been able to convey the idea more clearly yet, but hopefully I hope to get there eventually.  :)

> From: Pat Hayes [mailto:phayes@ihmc.us]
> . . .
> That is merely a consequence
> of the mistaken idea that fixing a bunch of assertions is the
> same as fixing a referent. This idea is wrong. They aren't
> the same, and to assume they are gets one into a host of
> muddles, just like this one.

The goal of a URI declaration is not to pin down the referent in
any theoretical sense. That, as you've pointed out, is not
generally possible. The goal is to pin down the referent in a
*practical* or *architectural* sense -- a sense that is useful to
Semantic Web applications.

"Pinning down the referent" in a practical or architectural
sense means that an application reading a statement involving
that URI has the essential information it needs to make useful
inferences based on that URI. This does *not* mean that a URI
denoting a particular referent will be useful tu *all*
applications, because different applications have different
needs. An approximation -- "the earth is flat" -- may be
perfectly fine for some applications but completely unusable for
others.

Thus, if I have a URI for "the earth", but it assumes the earth
is flat, and you have a URI for "the earth" that assumes the
earth is round -- also an approximation, BTW -- is my URI trying
to refer to the same thing as yours? From a theoretical
perspective, one might be tempted to claim that it is, and my
flat earth model is just *wrong*, because the earth is *not*
flat. But from an architectural perspective, they can and should
be viewed as denoting different things even though they clearly
are related, because they work in different applications. Your
notion of "the earth" may not work in my application and my
notion of "the earth" may not work in yours. That's okay.

By saying that the goal is to pin down the referent in a
*practical* or *architectural* sense, I do *not* mean to imply
that it is okay be fuzzy about what it means to "pin down the
referent" in a practical sense. Indeed, the architecture needs to
make that clear, and that is precisely the purpose of a URI
declaration. On the other hand, it *is* architecturally
permissible to have a referent whose real world interpretation is
ambiguous (and in fact, as you have pointed out, it is
unavoidable).

For example, suppose I mint a URI http://example#dbooth that
denotes a person named "David Booth" who works for HP, and I
supply a URI declaration such as:

  <http://example#dbooth>
      foaf:name "David Booth" .
  <http://example#dbooth>
      foaf:workplaceHomepage "http://www.hp.com/" .

Architecturally, this URI declaration *has* unambiguously pinned
down the referent of <http://example#dbooth>, even though the
real world interpretation is actually ambiguous, because there
are three people named "David Booth" who work for HP. From an
architectural perspective, that is not a problem: the URI
http://example#dbooth can be used to make statements about any of
the three "David Booth"s at HP and it may work perfectly fine in
some applications.

Of course, you may be tempted to assume that my URI was really
intended to denote *only* the "David Booth" who authored this
message, and hence you may be tempted to "correct" my URI
declaration by adding another assertion such as:

  <http://example#dbooth>
      foaf:mbox "dbooth@hp.com" .

However, your supposed "correction" may in fact be *wrong*: in
general, you have no way of knowing that I did not *intend* that
URI to be used to make statements about any of the "David Booth"s
who work in HP. Thus, if you wish to make statements that apply
*only* to the author of this message, then you need a different
URI with a more constraining declaration.

In short, the fact that a URI's referent has an ambiguous real
world interpretation does *not* mean that the referent is
ambiguous from an architectural perspective. Rather, it means
that the URI may be useful in some applications but not others.



David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent the official views of HP unless explicitly stated otherwise.

Received on Friday, 14 March 2008 17:56:21 UTC