Re: SEM: semantics for current proposal (why R disjoint V?) (fwd)

------- start of forwarded message -------
From: Ian Horrocks <horrocks@cs.man.ac.uk>
To: Dan Connolly <connolly@w3.org>
Date: Fri, 5 Apr 2002 18:33:48 +0100
Subject: Re: SEM: semantics for current proposal (why R disjoint V?)
Reply-To: Ian Horrocks <horrocks@cs.man.ac.uk>

On April 5, Dan Connolly writes:
> On Fri, 2002-04-05 at 07:08, Ian Horrocks wrote:
> > On March 21, Dan Connolly writes:
> > > On Thu, 2002-03-21 at 14:28, Ian Horrocks wrote:
> > > > On March 21, Libby Miller writes:
> > > > > >
> > > > > > As noted in the design discussions for DAML+OIL, I don't
> > > > > > see sufficient justification for making V disjoint
> > > > > > from R.
> > > > > >
> > > > > > It seems silly not to be able to talk about the intersection
> > > > > > of two sets of strings, or UniqueProperty's whose
> > > > > > range is dates, or whatever.
> > > > 
> > > > This means that any OWL reasoner has to take on responsibility for
> > > > reasoning about types
> > > 
> > > I gather when you say "OWL reasoner" you mean a complete
> > > reasoner.
> > > 
> > > I'm not very interested in such a thing.
> > > 
> > > Regular old horn-clause/datalog reasoners
> > > (with some built-in predicates like
> > > string:lessThan and such) seem
> > > to get me what I need pretty well.
> > 
> > Dan,
> > 
> > It seems that, on the basis of a few toy examples where using ad-hoc
> > reasoning seems give the results you want/expect, you conclude that
> > this will be appropriate/adequate for all applications.
> 
> No, just for an interesting class of applications.
> 
> By the way, if you consider
> formalizing the operations of W3C[1]
> to be a toy example, I'm interested to know what
> sort of applications you would take seriously.

I didn't intend to be pejorative - I was only referring to the examples
I have seen in email. It wasn't completely clear to me from [1] where
the ontology comes in or what kind of reasoning is being performed,
but I am guessing that you are not using a very large or complex
ontology.

> 
> >  I don't find
> > this argument very convincing. 
> 
> As I say, I didn't make that argument.
> 
> I'm arguing that we can advance the state of the art
> without a completeness requirement.
> 
> > Even w.r.t. ontology level reasoning I expect things to rapidly get
> > large and complex enough that humans wont be able to check all
> > inferences - we will just have to trust that the reasoner got it
> > right. Soundness is therefore essential, and completeness highly
> > desirable.
> 
> Yes, soundness is essential.
> 
> I don't see why completeness is all that interesting
> in the general case. I expect various reasoners
> to be complete for various classes of problems.

This is one of the problems with incompleteness - it is notoriously
difficult to characterise "classes of problem" for which such a
reasoner is complete. See [1] for a discussion of this issue.

> > For example, when multiple processes are interacting, some
> > action may be taken by one process on the basis of a non-inference by
> > another process,
> 
> That's non-monotonic reasoning. Part of life in the semantic
> web is: don't do that (without explicit license).

I don't see that this is non-monotonic. I'm not even talking about
changing any facts. I'm talking about the problems that can arise when
a "negation" is inserted by a process that uses the result of a query
to another process. E.g., a missile defense system might be programmed
to fire at any incoming aircraft not identified as a friendly. Firing
at a friendly aircraft due incompleteness in the identification
process might reasonably be considered as unsound behaviour on the
part of the overall system.

> > so incompleteness can easily lead to "unsoundness".
> 
> Unsoundness can result from all sorts of bugs; this
> is just one of them.
> 
> Actually, unsound/heuristic reasoning can be pretty interesting,
> as long as it's not confused with formal reasoning; e.g.
> 
> 	I conclude based on your recent buying patterns
> 	that the following products are likely to be
> 	interesting to you: X, Y, Z.
> 
> 	I didn't arrive at this conclusion based on
> 	sound reasoning, so take the recommendations
> 	with a grain of salt.
> 
> or
> 
> 	I conclude, based on a search of my extensive
> 	holdings, that there are no court cases
> 	in that jurisdiction involving chimpanzees and volkswagens.
> 
> 	Digitally signed,
> 	The BigLaw online service.

This might be true, but I fail to see the relevance. The question I am
addressing is, should we design the language in such a way that it is
possible to build sound and complete reasoners for usin in
applications where this is an important issue. The disjointness of
object/data domains and properties is required in order to guarantee
this characteristic of the language.

Ian

> > As far as the disjointness of object/data domains and properties is
> > concerned, there are also good pragmatic reasons for this, including
> > the ability to use hybrid designs for OWL reasoners, i.e., the ability
> > for an owl "object class" reasoner implementation to "bolt on" a type
> > checker for arbitrary type systems.
> 
> That seems like an interesting software architecture for
> a certain class of problems. But why should it constrain
> the language we're designing?
> 
> If such a system came across some data where "3" was
> a member of a class, I'd expect it to throw an exception ala:
> 
> 	Sorry, this software is limited to problems
> 	where the datatypes and the class members are disjoint.
> 	I can't compute the answer you asked for.
> 
> not
> 
> 	Sorry, your data doesn't conform to the language specification.
> 
> 
> [1] e.g. we're formalizing our tech report digital library,
> and the workflow around it.
>   http://www.w3.org/2002/01/tr-automation/
> 
> -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> 
------- end of forwarded message -------

Received on Friday, 5 April 2002 12:37:11 UTC