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.  

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

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.

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

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

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.

>   -JH

peter

Received on Thursday, 14 November 2002 10:03:00 UTC