- From: pat hayes <phayes@ai.uwf.edu>
- Date: Thu, 21 Nov 2002 14:03:55 -0600
- To: Jeff Heflin <heflin@cse.lehigh.edu>
- Cc: www-webont-wg@w3.org
>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