W3C home > Mailing lists > Public > uri@w3.org > May 2003

RE: Resources and URIs

From: <Patrick.Stickler@nokia.com>
Date: Fri, 2 May 2003 11:59:04 +0300
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B5FBBAE@trebe006.europe.nokia.com>
To: <phayes@ai.uwf.edu>
Cc: <GK@ninebynine.org>, <uri@w3.org>

> -----Original Message-----
> From: ext pat hayes [mailto:phayes@ai.uwf.edu]
> Sent: 30 April, 2003 05:16
> To: Stickler Patrick (NMP/Tampere)
> Cc: GK@ninebynine.org; uri@w3.org
> Subject: RE: Resources and URIs
> (I'm CCing this to the URI list as it tries to explain a 
> misapprehension about interpretations and naming. But I gather that 
> this thread is rather beside the URI WG list topic, so I will only 
> send messages to URI in future which have direct editorial content.
>   -Pat Hayes)
> >  > >Implicitly, there is a single interpretation that defines the
> >>  >denotation of the URI.
> >>
> >>  People keep SAYING that, but I havn't seen a single 
> ARGUMENT for it.
> >
> >Consider the following two use cases:
> >
> >1. Overloading of denotation looks like disagreement, but isn't:
> >
> >My graph:
> >x:J rdfs:label "Jane" .
> >x:J x:address "123 Main Street" .
> >x:address rdf:type owl:FunctionalProperty .
> >
> >Your graph:
> >x:J rdfs:label "Judy" .
> >x:J x:address "345 Main Street" .
> >x:address rdf:type owl:FunctionalProperty .
> >
> >Since the denotation of x:J has different interpretations, and
> >hence its denotation is overloaded, if you syndicate my knowledge
> >into yours, it will appear that we disagree about Judy's address.
> No, no. We are agreeing about matters of fact, but disagreeing about 
> how to say it. Since this entire discussion is about the right form 
> of words, however, let me explain why you are saying it wrong. :-)
> First, lets agree about some things. If you have some information 
> expressed using URIs to denote things, and I have some similar 
> information, and we use the same URIs, then indeed we have agreed (or 
> assumed) that we are using the URIs in the same way. Everyone should 
> feel entitled to assume that our uses of a given URI correspond, so 
> that whatever it refers to when you use it, is whatever it refers to 
> when I use it.  RDF and the SW generally is predicated on this, as 
> you point out.  OK, agreed.  With this much, I agree with everything 
> you say in all your messages.

Great. And I would like this expressed in some clear, normative
manner in the RDF specs. I appreciate that the MT must allow for
multiple interpretations, but we should be clear that the global
interchange of RDF expressed knowledge between arbitrary systems
presumes a single shared interpretation for all URIs.

The present RDF specs do not say this clearly and explicitly, even
if it is implicitly reflected in the graph merge operation.

Perhaps the place for this to be stated is in Concepts.

> But(but, but...) it is NOT correct to describe this agreement by 
> saying that there is a SINGLE thing which the URI denotes in ALL 
> interpretations, 

I agree with this, and I hope my other posts have reflected this.

It is a matter of what the MT allows and what the SW requires. The
MT of course allows for multiple interpretations, since RDF may be
used in contexts other than the SW -- but the SW requires a single
shared interpretation.

I admit that some of my earlier posts were not clear about that

> or that there is a single intended interpretation, 

Well, within the context of the SW, I think there is presumed to be
a single intended interpretation.

> or that the URI, all by itself, somehow identifies a single thing in 
> the world.  

Agreed -- not all by itself, devoid of context, but within the
context of the SW, a URI does, all by itself identify a single
thing in the world (or at least, is presumed to)

> (Maybe it does, but that's not required for agreement.) 
> Successful communication doesn't depend on having that (magical) 
> level of precision about reference or meaning: it depends only on our 
> having enough assumptions and knowledge in common (or mutually 
> accessible) that we are both able to draw whatever conclusions are 
> needed for the particular act of communication to work.  

That's fine for humans. But for "stupid" SW agents, drawing conclusions
about things is more difficult, if not impossible to do reliably if
there is overloading of denotation.

Also, SW agents do not "communicate" the same way that humans do.
SW agents perform operations on statements. Period. You seem to
be talking about communication as it relates to full cognition
of sentient beings. I am talking about communication at the level
of interchange of data resulting in the consistent behavior of software

> Its the 
> knowledge that is shared, not the interpretation of the knowledge. 


But if we do not express the knowledge in a way that has a consistent
interpretation by both parties, how can the knowledge be shared and
exchanged by means of that expression?

> Heres a way to put it. In order to communicate properly, we have to 
> agree to use names in the same WAY.  

Right. If only *you* and *I* wish to communicate.

> But that is not an agreement to 
> use the names with a single, globally fixed meaning; 

Ahhh, but here is where you are wrong, within the context of the SW.

On the SW, we usually do not *know* with whom we are communicating!

We cannot agree on a case by case basis on the names to be used
for *each* case.

So we agree, using the SW, that we will (at least try to) use a
set of global names with which to denote things, so that no matter
who our SW agents communicate with, there will be a single (presumed)
interpretation of all URIs.

It is this global scope of the SW involving arbitrary parties
engaged in communication that requires a single consistent
(presumed) interpretation of all URIs.

> Now, that said, there are counterexamples in particular cases. What I 
> think is driving the debate about the RFC 2396+ wording, in part, is 
> the fact that successful communication (human or machine) does indeed 
> often depend on having mutual access to a sufficiently rich *source 
> of knowledge* ; and on the Web, these sources are themselves some of 
> the 'resources' that the document is talking about; and this 
> particular kind of link between a URI and a source of knowledge is 
> indeed often much more like a genuine 'identifier' kind of 
> relationship, rather than merely a denotation: it is mechanically 
> defined, single-valued, uniquely determined, etc., and all the 
> terminology of 'indicating' and 'bound to' and so on all applies to 
> it very naturally, hence in fact the ubiquity of transfer protocols 
> in the fabric of the Web and their intimate relationships with URI 
> syntax. But *these* 'resources' aren't always the things that get 
> denoted by URIs: they are more often the *sources of information 
> about* the things that are denoted. (Much of the confusion I am in 
> about the wording is that parts of it read as though they are meant 
> to apply only to this sense of 'resource', while other parts read as 
> though they are explicitly not intended to, so reading the text 
> produces a kind of cognitive dissonance.)

I follow you. But this is surely an issue of how important a given
resource is. The more important a resource is (such as a resource that
is part of the fundamental machinery of the SW, such as rdf:type
or rdfs:Class) is simply more sensitive to overloading than other
resources and thus, the need for consistent interpretation becomes
critical -- giving rise to the "illusion" of appearing like a 
genuine 'identifier'. But in fact, it is no different than any other
case of URI denotation. Only the degree of negative impact from
overloading is different.

If two SW agents have knowledge that reflects a human disagreement
in the denotation of rdf:type, that will likely be fatally detrimental
to their operation. If they have knowledge that reflects a human
disagreement in the denotation of e.g. ex:foo (whatever that is)
then the impact on their behavior is likely to be far less drastic.

But the two cases are the same. Both involve URIs that denote
resources. Neither URI is a 'genuine identifier', even if one
appears to act more like one then another, because of its significance
to the core SW architecture.

> >If I syndicate my knowledge into yours, it will appear that we
> >disagree about Jane's address. But it may very well be that we
> >both agree about both Judy's and Jane's addresses, yet we can't
> >see that because we are using the URI x:J inconsistently.
> We agree to use them consistently in this sense, of course. In MT 
> terms, we have formed a single theory and have thereby (kind of 
> automatically) agreed to have our two theories interpreted together, 
> in the same way, by every interpretation. That is what graph merging 
> does.  We have agreed to share some of our beliefs: I have taken 
> yours on board, and you have taken mine on board.  Our knowledge has 
> gotten syndicated (great word).  But, to repeat, that is NOT the same 
> as saying that we have agreed ON A SINGLE INTERPRETATION. In fact, as 
> you also point out, there is no way we can possibly do that, right? 
> (So why would our communication depend on URI's doing that?? It 
> doesn't.)

OK. Let's say that we presume we have agreed on a single intepretation,
even if in fact, we haven't -- in which case our communication will
be impacted.

Our communication depends on, or embodies, the presumption that we
have agreed on a single interpretation.

> >--
> >
> >In either case, it is *impossible* for the reasoning engine
> >to determine that overloading has occurred, since URIs are
> >atomic primitives and it has no (formal and reliable) machinery
> >at its disposal to inspect or test the actual denotations.
> Exactly; but then why is it necessary for URI's to have a single 
> denotation? 

Because our SW agents won't be able to detect overloading and without
this presumed (and ideally achieved) single interpretation, the SW
cannot be an effective tool for the global interchange of knowledge.

> As you say, there is no way that a reasoning engine (and 
> we humans are reasoning engines too) 

No, no no. *Please* do not throw current software systems in with
humans. When a system passes the Turing Test, fine, include *that*
system in with humans, but for now, let's only talk about (fairly
stupid, limited) software applications.

> could possibly discover whether 
> or not it had one. So why does it matter? 

Because we want our SW agents to communicate reliably with any
and every other SW agent on the SW.

> (Except, of course, for the 
> special cases where we can use the URI to locate the actual resource 
> and perform some actions on it directly, eg by pinging it to make it 
> send us something. In those cases we actually get to the referent, 
> and then it really is important that there really is one thing that 
> is 'identified' by being 'bound' to the URI.  But those cases are 
> special.)

No. It is not important. And what a server provides as a representation
of a resource does not necessarily give any indication of what resource
is actually denoted by the URI. 

> >  >
> >>  The fact that the Internet functions is an indication that even
> >>  though one person may be using a URI with one thing in mind, and
> >>  another person using it with another thing in mind, the 
> variations in
> >>  these interpretations somehow do not matter.
> >
> >Of course it doesn't matter, on the *Web*, but we are talking here
> >about the SW, and the needs of the SW for non-overloaded, consistent
> >interpretations of URIs is far higher than that of the Web. 
> Please don't
> >presume (as you seem to do) that the Web deeply cares about 
> the issue now
> >being discussed. I don't think it does.
> >
> >The SW is a bright light shining on the present Web architecture
> >showing things in dark corners where no'one before cared or 
> dared to go.
> >So don't expect to see clear answers to these questions in 
> the present Web
> >architecture specs, because they simply haven't been critical issues
> >to the practical, day to day operation of the Web.
> >
> >Yes, there are hints here and there of these issues, but not really
> >in those parts of the Web architecture specs where the "rubber meets
> >the road".
> >
> >The SW is now putting those sections to task, and not getting much
> >traction...  hence the need to revise, clarify, and expand the
> >specifications -- for the needs of the *SW*, not for the Web.
> Well, maybe: but I want to go on record that this is not why I am 
> primarily concerned with the RFC 2396 wording. If RFC 2396 declares 
> clearly that resources cannot be, say, integers or unicorns, then 
> that will not be a total disaster for the SW. 

But I think that *is* why you are concerned with the wording. 

It is because the *Web* does  not need URIs to denote integers and 
unicorns that the specs do not say clearly and explicitly (enough) that 
they can be used that way.

It is the needs of the SW that is forcing this issue, and those
who have been involved in the specification of RFC 2396 have 
(understandably) be thinking in terms of the Web, not the SW.
So it is not surprising that these special needs of the SW (but
not the Web) are not clearly and explicitly provided for.

Any revisions to RFC 2396, however, *must* account for and support
these special needs of the SW.

Of that, it appears, we are in full agreement.

> We will just have to 
> say that what the SW reasoners are reasoning about needn't be just 
> 'resources'. That would require a few changes to the wording of some 
> of the specs, and it would leave rdfs:Resource with a rather bad 
> name, but nothing would actually break.

Yes, but...

I think that would constitute a schism of sorts between the Web
and SW whereby there is no direct connection between the two. Both
use URIs, but that is then just a practical coincidence.

Rather, and ideally, the primary point of intersection between the
Web and SW are in fact the globally consistent denotation of URIs.

Given any URI within the scope of the Web+SW, it is presumed to 
consistently denote the same thing, and one may either obtain a
representation of that thing, such as via an HTTP server, or reason
about that thing, such as by a SW agent. But in either case, the
thing denoted by the URI is the same.

In this way, one can use the SW to reason about things that are
accessible via the Web, as well as other things that are not 
directly accessble via the Web.

For this to happen, both the Web and SW architectures *must* agree
on the nature and denotation of resources.

> My chief concern is that the wording is unclear, and I think it is 
> just generally important to get it as clear as possible. If it then 
> clearly says the 'wrong' thing (from an SW point of view) then that 
> will be kind of a pity, but I don't think that the SW 's job is to 
> clear out the Augean stables of the Web.  Just getting the 
> terminology straight would be worth a lot at the present time.

Agreed. Clear and wrong is better than unclear.

But hopefully we can get it clear and right.

> Also, I actually think that the current Web architecture is pretty 
> damn good. I am in awe of it, in fact. I just think that what people 
> say ABOUT it could be improved.
> >You seem to be arguing that there is no way that my SW agent can
> >presume that its interpretation of that URI actually corresponds
> >to your interpretation of that URI -- that our two SW agents can
> >in fact interpret them in entirely different, and possibly
> >incompatible ways, and moreover, that such incompatible
> >interpretations are perfectly OK.
> No. I am arguing that an agreement to interpret in the same way, is 
> not an agreement to use one particular interpretation. 

Eh? This sounds like a tautology to me.

>  Agreeing to 
> walk in step is not agreeing to stand still in one place.

Well, yes, but I guess I am unaware of some significant distinction
between "interpreting X" and "interpretation of X". I would use
the two interchangably.

(remember, I'm speaking in English terms, not Mathematical terms ;-)

> >
> >>  >I don't know if this is just word-play, but my view is not to
> >>  >attempt to claim a URI has a single denotation in all possible
> >>  >interpretations, but to suggest that there exists a particular
> >>  >intended interpretation, which provides a denotation for 
> all URIs,
> >>  >and hence that the thing "identified" by a URI is that which it
> >>  >denotes in this particular interpretation.
> >>
> >>  I agree that makes sense, but its just as fantastic, and just as
> >>  corrosive to semantic analysis. It means that A entails B 
> just when B
> >>  is true in the single intended interpretation, for 
> example, so that
> >>  inference engines should ignore any facts they may have been told,
> >>  and just read off their conclusions from the single True
> >>  Interpretation. That is like telling the inference engines to seek
> >>  enlightenment through prayer.
> >
> >Pat, how can an inference engine *know* that B does not have a
> >single interpretation?
> It cannot.  But more to the point, how can it know that B *has* a 
> single interpretation? 

Because, if it is a SW agent (or a component thereof), it has this
presumption hard-coded as part of the SW architecture itself.

> And why should it care? Why would anything 
> depend crucially on that? (With the exception already noted.)

Because if I am asking my SW agent to do things for me, such as
make an appointment at my dentists, and the denotation of the
URI x:firstDayOfWeek is IMO Monday but for my dentist it is Sunday,
then I may very well find myself a day late or early for my

> ....
> >
> >>  >It seems clear that we don't know enough to completely 
> specify this
> >>  >interpretation, but on the other hand there are demonstrably a
> >>  >useful number of things we do agree on for it to be of some
> >>  >practical use.
> >>
> >>  The current MT semantic framework expresses this 
> perfectly. There are
> >>  a number of things we agree on.  Express those things somehow, and
> >>  they amount to some assertions which we both can agree to 
> accept as
> >>  true. We have a "common ground", and we have agreed to limit the
> >>  interpretations to those that keep it true. The practical 
> use arises
> >>  right here: we are both able to draw the same conclusions. 
> >
> >Hmmm... you seem to be expressing here the point I've been trying to
> >make, that while the MT might allow for multiple interpretations,
> >the SW Architecture nevertheless purports a presumption that there
> >is a single interpretation shared by all SW agents, for the purpose
> >of consistent interchange of knowledge.
> >
> >No?
> No.  Did I say that the common ground was a single interpretation? 
> Its a set of shared beliefs.  Beliefs are sentences, and they can 
> have many interpretations. 

OK, I am now completely lost as to what you are saying.

I'm talking here *only* about denotation of URIs. There are beliefs that
are expressible in RDF *about* a resource denoted by a URI, and there
are beliefs that humans have about the denotation of URIs used to
express those other beliefs. A SW agent only has access to the former
kind of beliefs. It has no access to human beliefs about denotation.

The common ground is the shared *human* belief in a single interpertation
of the denotation of a given URI, not a shared belief *about* the
resource denoted by the URI.

When I say "single interpetation" I mean "single agreed denotation"
or "everyone interprets the URI to denote the same thing".

> Remember, an interpretation is a possible 
> WORLD. By saying 'unique interpretation' you are saying that you can 
> pin down an entire universe uniquely. That is a very large claim to 
> make; a few hundred years ago you could probably have been burned for 
> making a claim like that.

I appear to be making (or you understand me to be making) a claim that
I am not trying to make.

Apparently, the terminology gremlins are getting out of line again..

Hopefully I've made clear above what I am trying to say.

> >
> >>  This is
> >>  how most communication works, maybe ALL communication, in 
> fact.  But
> >>  we don't need to have so much agreement that between us 
> that we have
> >>  managed to pin down a SINGLE interpretation. If we did need to do
> >>  that it would get in the damn way, we would be always arguing over
> >>  *exactly* what one another meant (just like we do on these mailing
> >>  lists, but all the time about everything) , we wouldnt be able to
> >  > move until we were SURE that the thing you were referring to was
> >>  EXACTLY what I was referring to, and so on.
> >
> >Well, we certainly would be able to move, even if we were not sure
> >if we agreed on our interpretations -- as our SW agents would presume
> >that we did, and if we seemed to be arriving at different 
> conclusions,
> >or the conclusions we were arriving out did not reflect our view of
> >reality, then we would have to consider that we were not in agreement
> >and take steps to rectify the situation. That's how communication on
> >the SW will work. We presume we mean the same thing when we all use
> >the same URI, until and unless stuff blows up. Then, someone 
> will have
> >to probably start using some other URI than the one they were using.
> >
> >So even if we can formally prove agreement of 
> interpretation, we *can*
> >specify as part of the SW architecture that SW agents may *presume*
> >that such agreement exists, and proceed accordingly.
> Agreement, yes. Uniqueness of interpretation, no. Different topics 
> altogether. If the was only one interpretation, it would be 
> impossible to disagree and we wouldn't even need to communicate.

Well, by uniqueness of interpretation, I have been meaning "agreement
about what the URI denotes". If that is not what uniqueness of 
interpretation means, I'd love to know what it does mean. It seems
that it includes, in addition to agreement about denontation, all
assertions also made *about* the resource denoted. I never meant
to say that everyone has to agree about everything asserted about
every resource. That's silly. Only that everyone needs to (presume)
to agree about the denotation of every URI. 


Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com
Received on Friday, 2 May 2003 04:59:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:05 UTC