Re: MT for imports

From: Jim Hendler <hendler@cs.umd.edu>
Subject: Re: MT for imports

> >From: Jim Hendler <hendler@cs.umd.edu>
> >Subject: RE: MT for imports (was: Re: Imports Proposal)
> >Date: Thu, 14 Nov 2002 09:46:36 -0500
> >
> >>
> >>  Jerome- I understood what you wanted, and I didn't mean nonmon in a
> >>  formal sense.  But suppose I was using the SW for e-commerce and we
> >>  had a situation where
> >>
> >>  Document 1 says:
> >>    I sell pencils
> >>    pencils are a document2:commodity
> >
> >I don't see how you can negotiate to buy pencils when this is all that you
> >know.  You don't know pricing, etc.
> 
> come on Peter, I was simplifying for the sake of the example -- 
> assume I put in some ...s and give me credit for not being totally 
> stupid.

Well, without nailing down *all* this, I don't see that any reasonable
example here.

> >  > Document 2 says:
> >>    Commodity has restriction onproperty "quantity" of numeral 1000.
> >>  (i.e. commodities are sold in lots of 1000)
> >>
> >>  Then if document 2 is down and I negotiate to buy a pencil from
> >>  document 1, when document 2 comes back up, I suddenly find I have to
> >>  pay for 999 more pencils than I wanted.
> >
> >Well, if what you wanted to do was to buy one pencil, then you tried to do
> >something that was not possible.  When all the information is known, a
> >contradiction should result.
> 
> why was it not possible?  at the time that I was talking to Document 
> 1, it had no reason to know that commodities are not sold in single 
> units

Precisely.  You had no reason to know what unit this good was sold in.  If
you, or your agent, went ahead under this basis, then you get what you
asked for.

>  -- I'm really not trying to formalize the buying of pencils - 
> I'm trying to point out that when documents are linked together, the 
> meaning of the whole requires that they all be there - otherwise even 
> in a monotonic system there could be missing information that could 
> have a negative effect

Only if some other portion of the larger system makes unwarranted
assumptions from the lack of information.  The reasoning engine can work
perfectly fine here.  Other components have to treat missing information
with the appropriate care.

> (in fact, I'm pretty sure that when Ron 
> Brachman presented the paper you guys did on using Classic in the 
> real world, he used an example of a procedural attachment that failed 
> if the program it tried to run failed).  

The contract for procedural attachments in Classic requires that the
attachments return an answer of true, false, or insufficient information.
I do not believe that Classic can handle procedural attachments that fail
to return any answer.  

> When the information is know 
> a contradicition should result - that's exactly my point - we agree.

Yes, but I'm saying that work can be done in the absence of information, as
long as the non-logical parts of the entire system are extremely careful
when they consider non-entailments.

> >If what you wanted to do was to buy some one quantity of some good that had
> >``pencil'' in its description for some known or unknown price, then that
> >happened.  The fact that you assumed that the good was a single pencil when
> >that information was not available to you is your problem.
> >
> >>  If we assume that imports is used to mean "My meaning relies on the
> >>  meaning of the other document" in any real sense, then if that
> >>  document is missing, what does the first document mean?
> >
> >It means what it says it means.  Imports should not be read as ``My meaning
> >*relies* on the meaning of the other document''.  It should instead be read
> >as ``Part of my meaning is contained in that other document''.  Then if
> >that document cannot be found all that has happened is that not all
> >relevant information can be accessed.
> 
> ok, this is fine - but then I would expect to do the same thing I 
> would do if I went to read your single ontology document and found it 
> referred to some classes that didn't seem to be there (perhaps 
> because I only read part of it before some server crashed).  I don't 
> know what that would be formally, but practically I would hope my 
> system would return a "class undefined" error or something like that 
> rather than blithely assuming that everything was just fine.

What do you mean by referring to some class that didn't seem to be there?
In OWL/Full there is no need to introduce classes, so there is no way that
a class can't be there.  

> >  > My proposal is simply to do what programming languages do - if I say
> >>    include foo.h
> >>  and foo.h can't be found for some reason, the program simply returns
> >>  an error, rather than trying to compile - because you said it needs
> >>  foo.h to run correctly and it knows that means it could possibly
> >>  return erroneous values even if it compiles okay without it.
> >
> >Well, I would hope that we can do a bit better.
> >
> >The analogy I would like to make is that if all the information that is
> >needed can be found in the accessible documents, then the unavailability of
> >the other documents can be handled in ways different from throwing an error.
> 
> are we going to specify them?  I hope not, because then we'll never 
> get to CR in the next few weeks - unless there's a whole literature I 
> don't know about, I would assume that dealing with missing 
> information is not a solved problem.

A specification is already available.  An informal version is in one of
Jeff Heflin's messages
(http://lists.w3.org/Archives/Public/www-webont-wg/2002Nov/0004.html) and a
more-formal version is in the semantics WD.

> >>  I actually expect the ontology documents to be relatively robust, so
> >>  I don't think this is something we need to worry about a lot - but I
> >>  think having a strong imports with "graceful degradation" is
> >>  contradictory in settings like ecommerce where real money changes
> >>  hands
> >
> >I don't see how this follows.  In some cases the inability to obtain the
> >information in imported document will cause important consequences to be
> >underivable resulting in the transaction not being completed.  In other
> >cases sufficient information will be available and the transaction could be
> >completed.
> 
> and how will you know?

Well, for example, if you can infer a price per unit and a unit description.

> >Applications that make (unwarranted) conclusions from the absence of
> >information will, of course, potentially do the wrong thing.  This is one
> >reason to not write such applications or, at least, to require that they
> >worry about incompleteness.
> 
> duuuh, which is why I said what I did in the first place -- that when 
> a document is missing we don't want graceful degradation or the 
> system using the first document won't know that there might be 
> missing information - I don't care how we do it - but if something 
> doesn't let me know a document was missing in the imports closure, 
> then I cannot know that there might be missing information.

Well, this argues that implementations of OWL will need an API that goes
beyond simple determination of entailment.  

> I really do think we are agreeing, not disagreeing.

Well, as long as OWL implementations can either
1/ signal an error when an imported document cannot be found
OR
2/ continue as best possible under this circumstance, ideally indicating
   that their reasoning is incomplete.

>   -JH

peter

Received on Thursday, 14 November 2002 11:20:07 UTC