From: Ian Horrocks (horrocks@cs.man.ac.uk)
Date: 02/28/02
On February 27, Pat Hayes writes:
> >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))
> >
> >and
> >
> > 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:
> >
> > http://www.cs.man.ac.uk/~horrocks/Slides/dagstuhlP070202.pdf
> >
> >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.
Neither can I, but the point is that it is hard to come up with a
specification of a rules syntax that doesn't add expressiveness to
DAML+OIL (and I was discussing the intersection of rules with
DAML+OIL).
> 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?
If were discussing adding more general rules, and thus extending the
expressive power, then this would be one way to try to push as much as
possible into the existing DAML+OIL.
> >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
> >{mahogany}.
>
> 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.
Could be. But how does the querier know that mahogany is the default
material that tables are made of? I imagine some people would say that
should be in the ontology.
> > 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
> later.
>
> 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.
I agree - I have been arguing from the start to keep things simple as
far as the basic query language is concerned.
Ian.
>
> Pat
> --
> ---------------------------------------------------------------------
> IHMC (850)434 8903 home
> 40 South Alcaniz St. (850)202 4416 office
> Pensacola, FL 32501 (850)202 4440 fax
> phayes@ai.uwf.edu
> http://www.coginst.uwf.edu/~phayes
>
This archive was generated by hypermail 2.1.4 : 04/02/02 EST