- From: Ian Horrocks <horrocks@cs.man.ac.uk>
- Date: Fri, 5 Apr 2002 18:34:46 +0100
- To: webont <www-webont-wg@w3.org>
------- 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