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

> What happens then, when there occur more than one thing that satisfy
> the properties you specify in the URI?

Then neither people nor machines can determine exactly and reliabily
what the URI denotes merely by examining the URI itself.  Oddly, this
problem is present with all URIs.  There is a conceptual dial where
you say how tighly you want to constrain interpretations of your URI.
My scheme just lets you turn the dial much looser than the other
schemes, so the looseness-of-definition becomes more apparent.

HTTP URIs, for instance, don't let you omit the authority component,
so they are roughly like

   something-which-has:named-by-owner-of-dns=example.com;<more-info>

which still allows tremendous vagueness, but it does narrow things
down on one axis, perhaps enough to be usable.

As I said "a red thing" makes a lousy-in-practice URI.  In practice
you'll want to include enough information to let readers know what is
denoted, in as tight a manner as needed.  

> UUIDs are nice in that they provide all the flexibility of anonymous
> nodes but without them actually being anonymous.

Yes, in practice providing UUID-like tightness is probably a good idea
most of the time. 

> > > 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.
> > 
> > Agreed.  I think Graham and Pat and you and I are in violent agreement
> > on this on this list.
> 
> Yes. And alot of the violence is my fault, being insane enough to 
> conduct discussions regarding logic in semantics using only the
> English language rather than more precise mathematical terms ;-)

Ah, me too, I think.  :)    

I think there is one real point of disagreement, though:

    You are saying that all communicating parties (using RDF on the
    SW) MUST agree which one thing is denoted by each URI they use (at
    least for many of the URIs they are using).

    Pat is saying that while all parties MUST agree that each name
    denotes one thing, it is not practical or necessary for them to
    agree on which thing each name denotes.  Instead, it is sufficient
    for some knowledge to be shared which constrains the possible
    denotations for each name.  The amount of knowledge which can and
    needs to be shared depends on the situation.  Sometimes it may
    seem that you can share enough knowledge to uniquely pin down the
    denotation of all the names you use, but (if I'm understanding
    right) this is an illusion.   I don't follow the theory there, but
    my intuition agrees that, whether or not it's theoretically
    possible, truly nailing down the terms is neither practical nor
    necessary. [more below]

I wonder where the test cases are which distinguish these two
positions?  In most cases I can think of, it is impossible to
distinguish between a disagreement about the denotation of a URI and a
disagreement about the state of the denoted thing.

> But in communicating about things, it seems to be best practice
> to choose names that have the greatest change of being recognized
> as widely as possible with the same denotation and have the
> smallest chance of being overloaded.

Agreed.   Thus "GoodURIs".   My scheme *allows* bad URIs, but no one
can really prevent them anyway.   By letting you construct URIs that
clearly can't walk, I'm trying to help show how none of them can fly
faster than the speed of light.

> It also seems to hide knowledge about the resource in the URI
> itself, rather than making it explicitly visible to agents
> as statements about the resource denoted by the URI.

Some knowledge is hidden in nearly all URIs.  And certain agents are
allowed to look inside and see it.  That's part of URIs.  URIs are
treatable as both opaque names and as information-bearing messages.

> So, while not all parties will be concerned with, nor even agree
> about all knowledge globally asserted (somewhere) about the resource
> in question, they still need to agree that they are talking about
> the same thing -- i.e. that the URI in question refers to one and
> only one thing and they agree what that thing is.

And how can they?  How do you and I come to an agreement on what
"something-which-has" means?  The point here is that even humans
cannot do this.  The best we can do is arbitrarily constrain the
interpretations of the term which are logically consistent.  I may be
able to constrain it such that there is only one thing in my known
universe which could possibly be being named -- but you may know of
something else!  In fact, I thought I *was* constraining it to exactly
one thing, and you *did* find another interpretation which was
logically consistent with all my constraints.  Now we act like we've
got it nailed down, but some other nuance of meaning may well come
along some day.

> Humans can make and test such agreements. SW agents must simply
> presume that such an agreement is in force and valid when it
> merges two RDF graphs from different sources.

They have to agree (as with the words I put in Pat's mouth above),
that each URI is being used to name one thing, but they don't have to
agree that anyone really knows what one thing happens to be named.

For instance, an RDFS processor doesn't need to know what class is
named by some URI, it just needs to know some of its subclass
relationships, right?  Going out on a limb here, it doesn't even
really need to know EXACTLY what rdfs:subclassOf means -- some nuance
of meaning may appear down the road -- it just needs to know what
logically valid things it can do with rdfs:subclassOf.  The test cases
give many formal test points for what rdfs:subclassOf could mean; the
prose may give humans additional fuzzyier constraints on its meaning.

In an oddly self-referential way, it seems to me like the way out of
this debate is via test cases, but I can't think of any which matter,
so it kind of proves the point that you can have wildly different
interpretations and nothing will break.  But please -- do give a test
case, sketching out where something will break if it follows the view
I ascribe to Pat, but not if it follows your view....

    -- sandro

Received on Monday, 5 May 2003 09:58:02 UTC