Re: Resources and URIs

I agree with everything you say here, by the way.   I point that out
just because sometimes (like in JC today) it seems like we're on
different planets.  I'm still not sure what happened there.

Oh, wait... one little disagreement.   I think you're making an
inappropriate exception:

>                                           (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.)

I think perhaps you misunderstand these "special" URIs.   

As I pointed out in my proposed 2386 text, URIs do double duty: (1)
they are names, as you describe, and (2) they can be sentences in some
(usually very limitted and compact) KR language.  It's this second
aspect that comes into play in these "special" cases, but there's no
magic, and there is still no single-interpretation.

Take a URI:

We know by parts of the the HTTP spec that:

   all x (
      uri(x, "")
      <-> (
      interactionProtocolName(x, "http") &
      interactionServerAddress(x, "") &
      interactionServerPort(x, 80) &     % defaulted
      remainder(x, "Consortium")

and thus:
     interactionProtocolName('<>', "http") 

[I'm using the '<...>' to put URIs into otter-style FOL as normal
constant symbol names which happen to contain odd characters.]

Having that additional knowledge about the thing, in the most common
case, allows a "sensing" "procedural attachment" to run (using
Benjamin Grosof's terminology), doing an HTTP GET operation, to learn 
new facts like
   exists r (
      mime_type(r, "text/html")
      representation('<>', r)
      text(r, "<html><head> ....      </html>")

which in turn allows stuff to be displayed on the screen, etc.

But the web server which responded to the HTTP GET does not need to be
somehow specially unique.  It's anything that answers to "".
(In fact, there are five or six physical machines which can and may
well answer that request.)  I'm not sure that's exactly the same sense
of having different interpretations as you mean in general, but it's
related.  If there is only one running process which may answer some
HTTP request, that's just because the network intrastructure has
enough knowledge to limit the correct interpretations.  Apache
normally has a large pool of waiting server processes; which one gets
picked is considered non-deterministic.  Isn't that just like having
multiple interpretations?

Similarly, the thing named by '<>' isn't
specially identified either.  In fact, as I think any discussion of
2396 quickly reveals, no one has any *precise* idea what is denoted by
any of these operational web-page URIs, yet we get along okay.  It's
all about (as you say in general) communicating by passing sentences
which help constrain the possible interpretations.  When I use the
address information in a URI X, I'm just asking some agent (whose
identity I can only partially constrain) to perform some operation
involving X; there are no special guarantees that we really mean the
same thing by "X", but that's okay.


      -- sandro


> (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.
> 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, or that there is a single intended interpretation, 
> or that the URI, all by itself, somehow identifies a single thing in 
> the world.  (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.  Its the 
> knowledge that is shared, not the interpretation of the knowledge. 
> In extreme cases this 'background' might be nothing, as when you 
> start telling me about something entirely new; in other cases it may 
> be quite a lot, eg we might both have access to a common store of 
> background information which we use to help us figure what the other 
> one is talking about. (This is how people do it, as far as we can 
> tell.)  But it will be most unusual if we share so much knowledge 
> that it is *impossible* for anything other than  a single thing to be 
> the referent.  And more to the point, whether or not we can is 
> completely irrelevant to being able to communicate with each other.
> Heres a way to put it. In order to communicate properly, we have to 
> agree to use names in the same WAY.  But that is not an agreement to 
> use the names with a single, globally fixed meaning; it would be 
> better described as an agreement to each believe the logical 
> consequences of the other's beliefs. Syndicating knowledge - 
> communicating it, putting it in the common ground - is agreeing to 
> the CONSEQUENCES of some sentences, not agreeing on a single 
> INTERPRETATION of them. We USE names by drawing conclusions. (- Who 
> is Joe? - My brother.  -Ah, Joe is your brother!  (Now I can draw 
> more conclusions about Joe than I could before. I have learned 
> something new, which may be useful. I don't need to know enough about 
> Joe to single him out from all other people, though.) )
> 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.)
> >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.)
> >--
> >
> >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? As you say, there is no way that a reasoning engine (and 
> we humans are reasoning engines too) could possibly discover whether 
> or not it had one. So why does it matter? (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.)
> >  >
> >>  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. 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.
> 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.
> 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.  Agreeing to 
> walk in step is not agreeing to stand still in one place.
> ....
> >
> >>  >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? And why should it care? Why would anything 
> depend crucially on that? (With the exception already noted.)
> ....
> >
> >>  >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. 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.
> >
> >>  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.
> Pat
> -- 
> ---------------------------------------------------------------------
> IHMC					(850)434 8903 or (650)494 3973   home
> 40 South Alcaniz St.			(850)202 4416   office
> Pensacola              			(850)202 4440   fax
> FL 32501           				(850)291 0667    cell
>   for spam

Received on Tuesday, 29 April 2003 23:42:55 UTC