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

Sandro,

This appears to be a URI scheme for expressing constellations
of properties defined for an anonymous node (and not very unlike
open-URIs).

I would think that what such URIs really denote would be the
*class* of all resources which match those specified properties.

I could see these URIs fitting nicely with DAML, which 
expresses alot using anonymous nodes denoting classes of
resources having particular features.

Whether the class only has one member is a different issue
than whether the URI denotes only one resource.

I think that it is (or should be) a fundamental presumption that,
within the scope of the S/Web, a given URI consistently denotes
a single thing. So if you tried to define a URI scheme that could
intentionally be used to provide for overloading of denotation,
I would consider that to be in conflict with the fundamental
S/Web architecture.

But if you say that your something-which-has URIs denote classes
of things, then they would have a single consistent denotation,
the class, and would be compatible with the S/Web architecture.

Eh?

Patrick



> -----Original Message-----
> From: ext Sandro Hawke [mailto:sandro@w3.org]
> Sent: 02 May, 2003 01:25
> To: uri@w3.org
> Cc: Stickler Patrick (NMP/Tampere); GK@ninebynine.org; pat hayes
> Subject: 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://xmln
> s.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 Friday, 2 May 2003 05:10:48 UTC