- From: pat hayes <phayes@ai.uwf.edu>
- Date: Sat, 30 Nov 2002 22:28:35 -0600
- To: Jeff Heflin <heflin@cse.lehigh.edu>
- Cc: www-webont-wg@w3.org
>Pat, > >The proposal that was approved by the WG is significantly different from >the "A imports B means if B entails P then A entails P" proposal. In >particular the semantics define an imports closure and then says that an >OWL interpretation of a document is defined as the OWL interpretation of >its imports closure. That does avoid the problems of definition I was grousing about, but it has some rather peculiar semantic consequences of its own, since now there is no way to tell whether one document entails another by examining the documents themselves. That is, there cannot possibly be any inference system applying to documents which corresponds to this notion of 'interpretation'. It is defined in such a way that it is impossible to ever prove any kind of completeness theorem. Personally, I think this is a disaster. >Please see [1] for details. This gives the >semantics in terms of the abstract syntax, If I understand what you are proposing, that is not true. I believe it cannot possibly give a semantics corresponding to ANY syntax, in fact, since the imports closure of a document is not a function of the syntax of that document. The semantics document should be rewritten completely to reflect his notion of 'interpretation', if we decide to adopt it. It is not a simple tweak, since this notion of interpretation is very non-standard and does not satisfy most of the normal properties of semantic interpretations; for example, Herbrand's theorem fails for this notion. I also think that the closure conditions on the large-OWL semantics will need to be re-stated to take these changes into account, since in general the imports-closure may introduce new vocabulary; and since the definition of closure is dependent on the state of the Web, I don't see how it can possibly be true that OWL/RDF can be layered on RDF, since the two languages now have different notions of interpretation, and one cannot possibly be mapped into the other. This is a far bigger change than the relatively simple matter of 'layering' that we used up nine months arguing over. > but Peter has also added >corresponding information for the RDF compatible semantics (see the >Semantics document). I don't believe your arguments below apply to this >approach to owl:imports, but would like to know if you disagree or >believe there are other problems with the approach. There are certainly problems, see above. Look, there is a more general issue here. Terms like 'interpretation' (in the MT sense) and 'valid' and 'entails' already have widely accepted meanings, and have done now for about 60 years. Virtually the entire edifice of metamathematics and formal logic is based on these accepted ideas. It is really, really, really a bad idea to try tinkering with these meanings in order to avoid doing a job properly. Its like someone who wants a theory of approximate numbers trying to get it for free by re-defining what 'add' means, say. So I would *strongly* suggest that we do not adopt any nonstandard notions of 'entailment' or 'interpretation', because to do so will almost certainly break something very basic in the foundations of the entire business. If you want 'imports' to mean something to do with the imports closure, then let us just say that explicitly by referring explicitly to the imports closure. A document containing an owl:imports is understood to define the RDF graph which is the imports closure of the document. Then all the usual semantics applies to this RDF graph, and that is all we need to say about it. > >Jeff > >[1] http://lists.w3.org/Archives/Public/www-webont-wg/2002Nov/0004.html I confess to not fully understanding what is being suggested here. But recall that we (finally) got rid of the need for 'dark triples'; if we have things in the OWL/RDF graph that are triples but are not allowed to have their RDF meaning, then we will need to bring dark triples back again, or something similar. That is why, unlike Peter, I think that it is best to specify the meaning in terms of the OWL/RDF graph rather than in terms of the abstract syntax. The abstract syntax is a luxury for theoreticians, but it cannot be taken as the defining syntax for all semantic content if we are to preserve OWL/RDF layering. We must make sure that any triple in the OWL/RDF graph can be given a meaning which is at least consistent with the RDF semantic conditions on that triple. The minimal requirements for the satisfaction of a triple aaa owl:imports bbb . are that IEXT(I(owl:imports)) contains the pair <I(aaa), I(bbb)> So we need to somehow make that be the case. I emphasize: this is not merely a decoration or an option. If the OWL semantics says that this triple is true when this condition is not satisfied, of not true when it is, then OWL/RDF is in violation of the RDF spec. Alternatively, of course, we can say that owl:imports is not encoded in the OWL/RDF at all, but is a kind of macro that should be replaced by the graph that is gotten by actually doing the importing of the imports closure. That would have the merit of being clear and unambiguous and the demerit, to my mind, of being so damn silly that nobody in their right mind would ever use it. But that is just my opinion; and I also think that clearly defined idiocy is vastly preferable to semantic confusion. Pat > >pat hayes wrote: >> >> >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 -- --------------------------------------------------------------------- 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 Saturday, 30 November 2002 23:55:01 UTC