Re: New issue - Meaning of URIs in RDF documents

Tim, after sending off that huge screed of responses to responses.. 
last night I realized that there are two issues which I am getting 
mixed up in all the to-and-fro. This is an attempt to sort them out 
and state them succinctly. (Tag group, I promise not to raise the 
second issue on this list again.)

The first is a purely technical matter, or maybe just to do with 
terminology, where at times you (and others, eg Patrick) say things 
in a way that doesnt make semantic sense. So on this first one, Im 
just tying to explain to y'all why you should find another way 
(please) to express what it is that you want to say.  The second is 
more a design issue in the SWeb, and here I am defending an opinion 
which I agree is a matter of debate.  So its important not to get 
these mixed up.

The first issue is this idea that in order to have proper 
communication, people need to agree that the names they are using 
(the URIs in our case) "mean the same thing". You often phrase this 
by saying that URIs must have a unique denotation or meaning, but 
that isn't the right way to say it. Taken literally, that is crazy: 
so Im sure that you in fact don't mean to say what you seem to saying 
here.  So, one might reasonably ask, what is the right way to say it? 
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.  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. 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. 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.

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 that was my first point: please don't talk about the need to fix a 
single interpretation for URIs, or that URIs must be required to 
denote (or identify, if that means denote) a single unique resource: 
that doesn't make semantic sense, I think it isn't what you in fact 
want to say, and what you want to do is already done. And this may be 
relevant to the wording of the TAG architecture document.

My other, second, point - and this is where I was chuntering about 
human communication and lexical ambiguity of "bank" and so on - is 
less to do with the TAG and more of a design debate within the SWeb. 
It is relevant, however, as I suspect that your position on this 
matter is partly what makes you so anxious to insist on single 
interpretations.  The question is, is our current design assumption - 
that all URIs always have the same meaning for all agents, so that 
RDF can be freely swapped around from ontology to ontology and 
processed by simple inference engines without any kind of checking 
for consonance of meaning - really realistic? You seem to think that 
it is, that the SWeb will be able to evolve into a global system of 
clear and unambiguous concepts, each assigned uniquely to a URI. This 
is what I doubt. This might be a kind of short-term ideal, or first 
approximation to get things going (that is how I keep my conscience 
clear, anyway) and it might be possible, with great effort and 
constant maintenance and training, to keep it up in limited areas - 
certainly enough to make a lot of $$ for some folk for a while - but 
in the long run, or even the medium run, I do not think it is 
globally feasible, for the reasons outlined in the last message. Its 
a Dream of Reason that harkens back to Leibnitz, his calcul 
ratiocinateur writ large on the Web (I was reminded of this by your 
insistence that it was Math and better than natural language... now 
where had I heard that before??); but all our experience (linguistic, 
semantic, ontology-engineering, cognitive science, AI) indicates that 
it is not a feasible dream for a genuine world-wide semantic web made 
by people.  I don't expect you to agree with this second point, of 
course (well, maybe eventually...), and I don't think it has anything 
directly to do with the TAG, but Im just staking out my position here.

So, ironically, the issue about agreeing to a common meaning, that 
you keep making an inappropriate fuss about, is actually a non-issue: 
our current design handles it perfectly, and you don't even need to 
mention "resources"; but I am saying that the current design is in 
fact broken, for just this reason. It is predicated on a falsehood 
that you wish to be made into a principle. You don't need to make it 
into a principle; and making it into a principle isn't going to make 
it any truer than it is, or make the knowledge integration problem go 
away, in any case, as practical SW users will rapidly discover; in 
some cases, are already discovering, eg see 
http://smi-web.stanford.edu/si2003/

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 Tuesday, 22 July 2003 13:01:32 UTC