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

> >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.

I can agree with that last one

  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.

*HOw* an engine is getting those is a totally different issue
we just suppose it can get those just as we suppose it is
getting power supply.

So this is an option that can work in our experience,
see old testcase


where <>
owl:imports <>.

On the other hand we can also be explicit and say


and omit the <SocratesP> owl:imports <SocratesA>.
I think I now prefer the latter...

> >
> >Jeff
> >
> >[1]
> 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
> >>  >and suggested that the "A imports B means if B entails P then A
> >>  >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,  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
> >>  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
> >>  >developers to implement things differently. This is a key feature of
> >>  >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,
> >>  >that additional triples should be added to the graph. I do not think
> >>  >will reach consensus on this. However, the entailment-based solution
> >>  >once again embraces the various opinions. It simply says if you
> >>  >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
> >>  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
> >>
> >>  >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
> >>       
> >>   for spam
> --
> ---------------------------------------------------------------------
> IHMC                                                   (850)434 8903
> 40 South Alcaniz St.                              (850)202 4416   office
> Pensacola                                              (850)202 4440
> FL 32501                                                    (850)291 0667
>   for spam

-- ,
Jos De Roo, AGFA

Received on Sunday, 1 December 2002 12:37:06 UTC