Re: LANG: need to CLOSE Issue 5.6 Imports as magic syntax

>Jim,
>
>I believe you are correct that there is consensus on the points you
>detail below. It seems to me that there are three issues currently
>unresolved.
>
>1) Should an imports failure make the imports statement "true by
>default" as suggested by Pat in [1]. I argued problems with this in [2]
>and suggested that the "A imports B means if B entails P then A entails
>P" solution is better. I have not heard a counter-argument on this
>point. Perhaps silence can be taken as assent?

No, you cannot take silence as assent, only that I had other things 
to do for a week or so. (Sorry Ive been behind on webont email. But 
this is a good illustration of the perils of non-monotonic reasoning 
in a distributed environment.) Dan Connolly explained why not some 
time back and I have repeated the point several times, at F2F and in 
emails, but apparently it does not sink in, so I will explain again 
in detail. Basically, the objection is that this 'definition' as it 
stands is either empty or self-contradictory.

The English word "entails" already has a meaning which is quite 
precise, especially in this kind of context, as follows: A entails B 
means that any interpretation which makes A true also makes B true. 
Or, if you like: B is true in all models of A. To emphasize: that is 
what the English word "entails" MEANS in this context.

So it just won't do to SAY that "A imports B means if B entails P 
then A entails P" if, in fact, A does NOT entail P. Its like saying 
"A imports B means that if B is green then A is green" when A is red. 
And if, for example, we say that owl:imports has no formal semantics, 
or is 'magic syntax', then the presence of some owl:imports triples 
makes no difference to whether or not A is true in I. So whether or 
not B entails something makes no difference to A entailing it, even 
if A does import B; unless of course that phrase 'A imports B' 
actually means that all of B is literally, syntactically, included in 
A: in which case there is no need to say anything about entailment, 
since in that case it is trivial that A entails anything that B does. 
See http://www.w3.org/TR/2002/WD-rdf-mt-20021112.html,  section 2, 
subgraph lemma. So either way, the proposed definition is dumb. Its 
either false or its vacuous.

To make the point in excruciating detail, consider Jim's example 
where A says (imports B; Joe a man) and B says (man subclass mortal) 
and the question is whether or not A entails Joe a mortal. Well, if 
imports is outside the 'formal semantics', ie has no bearing on the 
truth-conditions, then the answer is unequivocally, no, it does not 
entail it. Because there is an interpretation in which Joe is a man 
but not mortal, and that interpretation makes A true but the 
conclusion false. Of course, it makes B false as well, and A imports 
B. But, by semantic decree, that has got NOTHING TO DO WITH truth in 
interpretations and hence nothing to do with entailment. So the 
suggested 'definition' just does not work if imports doesn't have the 
appropriate truth-conditions in interpretations. 'Magic syntax' isn't 
magic: it's just plain meaningless.

Now, of course, we can just mis-use terminology to suit our purposes, 
and say that we are re-defining what "entails" means; but if we are 
using some other notion then we really ought to use some other word. 
One option is to say that the use of 'owl:imports' means that we are 
no longer thinking about entailment: the basic semantic relationship 
between documents is not entailment but some other notion, such as 
imports-closure-entailment.

But there is another way out of the problem. We can specify the 
meaning of owl:imports any way we want, and so impose 
truth-conditions on owl:imports which make "A imports B means if B 
entails P then A entails P" work out true WITH the usual meaning of 
'entails'. I did that, and sent you an account of the relevant 
truth-conditions which would make your intended meaning of 
owl:imports come out the way you want it to while satisfying the 
usual English meanings of all the words involved. In effect, I took 
your phrase, used the usual meaning of "entails" , and 
reverse-engineered the required truth-conditions. Seems to me that 
this solved the problem. You get owl:imports, it has exactly the 
intuitive meaning and formal consequences that you want it to have, 
"entails" means entails, and the usual advantages of having a precise 
model theory accrue: you can use owl:imports freely in the language, 
take subproperties of it, define classes by restrictions on it, deny 
it, whatever you want.

But apparently the WG rejected this last week. I confess to being 
totally astonished by this decision. Not wanting to Defend my Work or 
anything, but it solved a problem which is now a problem again. We 
now have owl:imports, and either it doesn't, in fact, mean what we 
say it means, or we aren't talking English. Why in God's name a group 
of intelligent people would decide to use a technical English word 
with an exact meaning, but simultaneously reject the technical 
account which makes the English decision factually correct, is beyond 
me. I am tempted to use modus tollens reasoning to conclude something 
about the WG, but no doubt that would be inappropriate.

To be fair, those truth-conditions may have been overly complex, 
since if we only allow what I called there 'I-import' assertions then 
we don't need to get into the stuff about tokens and indexicals, and 
the simpler MT trick that Dan C. suggested will work fine. But if we 
are going to talk about imports and entailment in the same breath, 
then we need to have *some* account of the truth-conditions for 
owl:imports. If owl:imports has no effect on truth in interpretations 
then it doesn't have any effect on anything entailing anything: 
that's just a fact.

>
>2) Should we have an operational semantics as opposed to a
>entailment-based smenatics as argued by Massimo [3]. The operational
>solution is more constraining: it requires developers to implement
>things in a certain way. The entailment semantics on the other hand
>allows Massimo to implement his operational solution, but allows other
>developers to implement things differently. This is a key feature of the
>entailment-based solution.
>
>3) How should error conditions be handled (e.g., 404 errors). Some
>people have argued that the system should report errors to users, others
>that additional triples should be added to the graph. I do not think we
>will reach consensus on this. However, the entailment-based solution
>once again embraces the various opinions. It simply says if you don't
>draw all the inferences then your reasoning is incomplete (see [4]).
>Thus, particular implementors are free to provide warning messages,
>error messages, meta-information in the graph, or whatever else they
>choose when such situations arise.
>
>Therefore, I propose the following:
>
>1) The syntax for imports be the same as that of DAML+OIL
>
>2) The semantics essentially be "A imports B means if B entails P then A
>entails P."

Saying that it is a 'semantics' means that you need to work out the 
actual truth-conditions on owl:imports to ensure that it really does 
mean this. With the decisions we currently have, this is now not only 
not a semantics, it is plain false. Either that is not what A imports 
B means, or else, if it does mean that, then it's almost always 
false. You can't have it both ways: if its outside the MT, then 
entailment ignores it. If you want it to entail something, then you 
need to make it come out true in the appropriate interpretations. Let 
me emphasize: WITHOUT TRUTH CONDITIONS, THERE IS NO SUCH THIS AS AN 
ENTAILMENT SEMANTICS.

>Here A and B can be any document, not just ontologies.

Then we have to say what 'entailment' means when used between 
non-ontology documents, which requires us to say what it means for 
them to be true in an interpretation, which requires us to specify 
what counts as an interpretation of them and the conditions under 
which they are true in it. They start to sound like ontology 
documents to me.

>  >
>>  We need to close this issue somehow - suggestions?
>  >   -JH

Well, I expect you think you have now closed it, Jim, but I don't 
think in fact you have. All you have done is put a bomb in a 
suitcase. Its going to go off eventually.

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam

Received on Thursday, 21 November 2002 15:04:00 UTC