Re: New issue - Meaning of URIs in RDF documents

>On Tuesday, Jul 22, 2003, at 12:31 US/Eastern, pat hayes wrote:
>
>>[...] And the answer is, there isn't anything to say.  Just by 
>>using the same URIs, any two agents who swap or communicate some 
>>RDF have *already* agreed to use those URIs to "mean the same 
>>thing" in all the senses required for proper communication. The 
>>syntactic coincidence of vocabulary by itself is enough to do this, 
>>given the model theory: we don't need to add any extra conditions 
>>or principles.
>
>First of all, I am much relieved that what I was trying to say has 
>been reclassified from "crazy" to so obvious that it "doesn't need 
>to be said"!

:-). Though to be fair, I have never said that what you were *trying* 
to say was crazy.

>There's that communication thing happening again.
>
>So yes, it is obvious to you who have internalized the RDF model 
>theory.   But it needs to be said in a wider context, because those 
>who use RDF more peripherally or do not use it at all have actually 
>considered quite deliberately using the same URI for distinct things.

Well, as long as they do that in some sense systematically, or if 
there are systematic ways to map between their meanings, then I don't 
think that the sky will fall. It might be better to urge people to 
sin responsibly than to try to make it impossible to sin.

>Much of the architecture document sometimes seems like stating 
>what's obvious to some, to the great surprise or objection of some 
>others.  We have a diverse set of cultures here.

Point taken.  Suppose we said something like, think carefully about 
what you take a URI to mean, the softbots will get confused unless 
y'all choose meanings that are related in some fairly close way.  So 
your choice has consequences: think on. Now, as a general guide, here 
are some design principles:.....
rather than things like "a URI identifies a unique resource" which 
reads like a natural law, or a claim about the universe, or something 
like that.

The kind of language I have in mind is illustrated nicely by the way 
that charmod handles the meaning of 'character' eg at 
http://www.w3.org/TR/2002/WD-charmod-20020430/#sec-Storage.  It reads 
like a discussion and some sensible advice, rather than like a kind 
of frontal assault on your beliefs about the world.

>>   That is the current SW design; names are thought of as being in 
>>global use, so that whenever two or more agents use those names, 
>>their assertions can all be merged; and then applying the model 
>>theory to the merged ontology *does* treat the names as meaning the 
>>same thing, automatically.
>
>Absolutely
>
>>Further, if some thing external to RDF somehow does magically fix 
>>the referent of a URI, then as long as the RDF uses that URI, what 
>>the RDF is saying will be about that thing; that also is already 
>>guaranteed by the model theory.
>
>Absolutely.
>
>>So this problem is solved: no need to say or do anything else, no 
>>need for further axioms or principles. The purely syntactic fact of 
>>using the same URIs is enough to capture the required degree of 
>>semantic alignment, without any further stipulations.
>
>Given the RDF model theory.

Well, given *any* model theory, pretty much.  That is, it doesnt 
depend on the RDF details.

>Note though that other non-RDF systems may and do use URIs.  So the 
>principle can must be a general one of web architecture.

Names are global in scope.  OK, though (in the other branch of the 
discussion) I don't think this is going to be feasible, myself, if 
taken strictly. Still, I agree, its not a bad place to start, as long 
as we understand that we will eventually have to replace it with 
something more sophisticated.

>>Another way to put the same point: how could two agents not mean 
>>the same thing, when using the same URI? The only way, if you check 
>>the model theory, would be for them to both somehow distinguish the 
>>URI-when-used-by-A from the URI-when-used-by-B, perhaps by some 
>>kind of McCarthy/Guha style 'context logic' mechanism,
>>or by 'separating' the vocabulary in the way that OntoMerge does. 
>>Ie, to treat them like two different names in the semantics. But 
>>our basic SW design doesn't have any provision for doing this: we 
>>just assume that all tokens of a URI are the same URI, and hence 
>>mean the same thing, wherever they occur, anywhere on the planet at 
>>any time.
>
>>That is not, note, the same as saying that all URIs must denote 
>>only one thing (one resource), or still less that the agents need 
>>to or can possibly know what that thing is, or have any kind of 
>>access to it. It is saying that whatever the URI might denote, the 
>>agents have all agreed, as it were, ahead of time that what they 
>>are saying to one another is about that.  But it might be easier to 
>>just say "they agree URIs mean the same thing".
>
>So long as we say "mean" it is obvious, and "denote" is is wrong.
>Ok. I can live with that, when talking to you at least.
>
>Tim
>
>PS: (I had personally preferred "identify" for when we talk about 
>what does a symbol mean, and keep "mean" for what a document or 
>message means.   In the latter sense there is a sense of information 
>transfer, a reduction in the number of interpretations believed by 
>the receiver, a possibility of expressing the meaning in different 
>languages.    In the first case there is non of that sort of 
>meaning, as one symbol doesn't make a sentence in RDF at least.)

Point taken, but we do often ask what a word 'means' or what someone 
means by it; and 'identify' to me has an unfortunate overtone of 
'single out' or 'gotcha!' about it.

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
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Friday, 25 July 2003 18:29:59 UTC