exploring ambiguity via the "something-which-has" URI scheme

I'm trying to see the difference between a name "not denoting" and a
name "having many interpretations" (as in Pat's recent mail [1]).
I've made up a new strawman URI scheme for this.  I'm going to skip
the detailed definition of this URI scheme and just discuss some
examples.  I think it'll make sense as we go.

[A] something-which-has:color='Red';def(color,http://example.com/color)

   This is a lousy URI.  Let's see why.

   Like all URIs it denotes something, and we don't have to know
   exactly what.  Humans and software can do useful things using it as
   an opaque logical constant, an opaque name.

   Like most URI schemes, the something-which-has URI scheme lets us
   do more than treat the URI as an opaque name.  It lets us see that the
   thing is red.  Or, more formally, that the following RDF triple
   (using "[A]" to stand for the big URI above) is true: 

       [A] <http://example.com/color> "Red".

   But this isn't very useful for a URI.  The information encoded in a
   URI should, among other things, help people reach a consensus of
   meaning about the URI.  With this (lousy) URI, it's quite likely
   people would form different ideas (if any) of what the thing was.
   It's not much more informative than a UUID or tag: URI, and yet it
   looks confusingly like it ought to be.

[B] <something-which-has:foaf_nick='DanC';defpre(foaf_,http://xmlns.com/foaf/0.1/)>

   This is somewhat better.  A person or computer which sees this URI
   knows it denotes something which has a foaf:nick of 'DanC'.  Many
   humans will either know that means Dan Connolly or know that they
   don't know who it is.

   It's a better URI than it might first appear.  It's far better than
   one using foaf_firstName='Dan' because so many FOAF aficianados use
   the freenode.net IRC network where Dan Connolly is registered as
   DanC.  But of course it's still kind of lousy; there may well be
   parts of the world that know FOAF and think of someone else as the
   thing nicknamed DanC.
   
[C] <something-which-has:foaf_mbox='connolly@w3.org';defpre(foaf_,http://xmlns.com/foaf/0.1/)>

   This is good.  FOAF defines mbox so that "there is (across time and
   change) at most one individual that ever has any particular value
   for foaf:mbox."  Here there is little chance of confusion, AND we
   have some useful additional information: the e-mail address of the
   denoted thing.  The FOAF comment text also makes it clear that the
   thing must be the kind of thing which can have a mailbox, but it
   doesn't name that class of things.  

   (I was hoping the FOAF ontology would give the owl:range of mbox as
   foaf:Person so that a machine could infer from this URI that it
   denoted a foaf:Person, but I guess FOAFers want to allow for other
   things with mailboxes.  That's reasonable enough.)

[D] <something-which-has:foaf_mbox='connolly@w3.org';foaf_nick='DanC';defpre(foaf_,http://xmlns.com/foaf/0.1/)>

   Now this is getting interesting.  
   
   [C] was already constrained by a foaf_mbox, an
   owl:InverseFunctionalProperty, on a literal string.  And [D] has
   the same property/value pair, so now a reasoner versed in RDF, OWL,
   FOAF, and something-which-has can conclude that [C] and [D] denote
   the same thing.

   But the use of [D] instead of [C] tells us that the thing also has
   foaf:nick "DanC".  Sometimes it doesn't matter.  To a
   something-which-has reasoner, these two RDF graphs are logically
   equivalent (they entail each other):

       # graph1
       <a> <b> [C].
       [C] foaf:mbox "DanC".

       # graph2
       <a> <b> [D].

   So why might you want to use [D] instead of [C]?  Because sometimes
   you want the extra information encoded in the URI.  Some protocols
   and formats have a space for a URI but not for an additional RDF
   Graph of information about that thing denoted by the URI.  I think
   there is also a trust/security issue, as in the recent thread on
   secure URIs.

I think there are some interesting directions to go next with this,
but I've made my basic point: we can have URIs that look quite
ambiguous and they still work with the RDF MT.  They denote one thing,
but you can't tell by looking at them what that thing is.  To go to
the extreme, you can perhaps never *really* know what thing is denoted
by a name, but this scheme makes it clear exactly which knowledge you
can glean from inspecting the name and which you need to learn from
elsewhere.

   -- sandro

 [1] http://lists.w3.org/Archives/Public/uri/2003Apr/0147.html

Received on Thursday, 1 May 2003 18:25:36 UTC