Re: rules, queries and DAML+OIL

From: Pat Hayes (
Date: 02/27/02

>Last week I promised to send something round about rules, and what I
>had learned at the Dagstuhl Workshop. Sorry that I am only doing so at
>the last minute. Please also be aware that the following are only
>intended to be ideas/discussion points and are very far from being
>fully thought through - in particular the idea about defaults is just
>me "thinking out loud", and I fully expect you to tell me that I am
>talking through my hat (as usual).
>Just to be clear, when I talk about rules here I am talking about horn
>rules of the form:
>q0(y0) <- q1(y1) ^ ... ^ qn(yn)
>where qi is a predicate and yi is a tuple of variables of the same
>arity as qi.
>The first point I wanted to make, which may be obvious to us but does
>not seem to be clear to all (even those at the Dagstuhl workshop), is
>that rules and DL/DAML+OIL axioms have a lot in common. In particular,
>many rules can be expressed as subClassOf axioms (and vice
>versa). E.g., :
>   p(x) <- q(x) ^ w(x)
>is equivalent to 
>   (subClassOf p (intersectionOf q w))
>   p(x) <- q(x) ^ r(x,y) ^ w(y) 
>is equivalent to
>   (subClassOf p (intersectionOf q (restriction onProperty r hasClass w)))
>In fact, based on the evidence of the examples given in the Dagstuhl
>talks (which may, of course, not be a representative sample), it seems
>that the kinds of thing that can't be captured in a DL axiom (e.g.,
>predicates of arity greater than 2, variable "cycles") are rarely used
>in ontology rules - at least nearly all of the examples could easily
>be expressed as a axioms - you can see a more complex example in slide
>35 of the talk at:
>We might consider including some syntax that allowed rules of the
>appropriate form to be included in ontologies - the problem is that it
>will be hard to come up with a way of syntactically restricting rules
>so that only "axiom equivalent" rules can ever be stated.

So, why bother? I cant see any harm in allowing people to write 
content in more than one way.

Perhaps more constructively, would it be possible to 'compile' some 
of (parts of?) the rules into axioms, and leave the remainder of them 
as rules?

>Another interesting point is that there seemed to be some confusion
>(at Dagstuhl) regarding D+O and the closed world assumption. For
>example, there seemed to be the idea that if a D+O KB contains the
>information that there is a train from A to B departing at 3 o'clock
>(and no other information about trains from A to B), and we want to
>ask "what time does the train from A to B depart", that this could not
>be answered because, under the open world assumption, there could be
>any number of other trains from A to B. Of course it is easy to get
>the required answer if we use a query. Moreover, the closed world
>assumption is clearly crazy in these kinds of case as we don't want to
>infer that the class of "trains from A to B" is subsumed by the class
>of "things that depart at 3 o'clock".

That might make sense in a closed application.

>Finally, a thought that occurred to me at Dagstuhl is that some of the
>things that people are trying to do with rules, a closed world
>assumption and/or defaults can be captured using queries. Take Guus'
>famous mahogany table example. If a given application wants to apply
>the default "rule" that tables are assumed to be made out of mahogany
>unless we know otherwise, it can do so by simply by adding the
>appropriate information to the results of queries. E.g., it is easy to
>answer the question "what is table t made out of?" simply by answering
>the query:
>(x) <- table(t) ^ made-of(t,x)
>and if the answer to this is empty, then returning

Ah, excellent. Note that you are here taking about something that 
poses a query  to a server and then returns a different answer to a 
querier, ie something that stands between a querier and a server, and 
looks like the former to the latter and like the latter to the former 
(work it out). That's what Richard and I have been calling a 
'wrapper'. I agree, such things are very important, and we should be 
seeing what else they can do.

>Similarly, to retrieve all mahogany tables, simply
>retrieve all tables and eliminate those not made of mahogany.

Right, exactly. So default assumptions can be made explicit in 
patterns of wrapper code, and do not need to be incorporated into the 
underlying logic of the basic query process. The more we can separate 
things out like this, the better.

>In terms of DQL, we could achieve this by adding an extra "premise" KB
>containing axioms of the form made-of(x,mahogany) for all tables x
>such that x is not in the answer to the query
>(x) <- table(x) ^ made-of(x,(not mahogany))
>Of course this still leaves many questions unanswered: how are such
>default rules to be expressed? how does the application know about the
>default rule (is it part of the ontology or some extra information
>only known to this particular application)?

Havnt you just answered that? Its part of the query, surely.

>  can we satisfactorily
>formalise the semantics?

Well, we could produce a very useful tool even before specifying the 
semantics. I would quite like to try designing a kind of PERL-for 
query-wrappers and give it to the world to see what people did with 
it. My guess is that they would start doing things that we havn't 
even thought of. We can come along and do a job on the semantics 

Notice, Im not suggesting that the query language itself shouldn't 
have a clear semantics. The part that might need to be allowed some 
freedom is the relationship between the meaning of the query given to 
the wrapper, and the meaning of the queries that the wrapper gives to 
the basic KB server.

>However, I do see some hope of dealing with
>these issues, and dealing with defaults in query answering certainly
>seems to be preferable to reasoning with them inside the ontology.

I agree!!  We need to divide and conquer, rather than trying to make 
a single monolithic DQL that can do everything.

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax

This archive was generated by hypermail 2.1.4 : 04/02/02 EST