From: Ian Horrocks (horrocks@cs.man.ac.uk)
Date: 10/25/01
On October 24, Richard Fikes writes:
> >The knowledge base contains the statements: "Pat's car is blue, and
> >there is something colored red." Somewhat more formally:
> >
> > RDF(PatsCar, color, blue).
> > exists x (RDF(x, color, red)).
>
> Sorry to be dense, but how does one state "there is something colored
> red" in DAML+OIL?
The simple answer is that you can't without either naming it (i.e.,
asserting that some named individual is red) or connecting it to some
named individual via properties. This "collapsed model property" is
one of the basic properties of description logics on which their
decision procedures depend.
To be honest, I think we are getting way off base here with the whole
discussion. If we are talking about querying a DAML+OIL KB, the
problem is whether a query such as "give me all the red objects in the
KB" should return individuals whose existence is only implied by the
logic, i.e., individuals that don't exist at all in terms of the rdf,
either as named or anonymous nodes. E.g., if I assert that the
individual Ian is an instance of the class of people that own at least
one car and all of whose cars are red, then a REASONER can INFER that
some instance of red coloured car must exist, but there may be no RDF
node representing that individual. In this case, we can't/shouldn't
return it as part of the answer to our query. On the other hand, if
the query asks for all people owning red cars, then we CAN return Ian
as part of the answer, even if there is no RDF node representing the
red car Ian owns, because the reasoner can infer that in all models
satisfying the KB such an individual must exist.
As far as I can understand it we were all agreed on this point - i.e.,
that the answer to queries should only include named individuals, and
not those whose existence is only implicit.
Things seem to get a bit more tricky when the query asks for a
tuple. E.g., we ask for all <x,y> such that x is a person, y is a red
car, and x owns y. There may be a temptation to want to return the
tuple consisting of Ian and the "anonymous" car which we know he must
own. I am convinced we should NOT do this. If there is no individual
in the KB that we can infer to be a red car owned by Ian, then Ian
should not form part of the answer to the query - if we are really
only interested in the owners, then the query should simply have asked
for the instances of the class of red car owners.
As far as I can understand it, most/all of us were agreed on this
point (at least Richard, Peter, Pat and I).
As far as the case where Ian owns two red cars is concerned, this is
straightforwardly dealt with by returning 2 tuples: <Ian, RedCar1>,
<Ian,RedCar2>. Note that we already agreed that all names should
really be sets of equivalent names, we can deal with the case where
RedCar1 and RedCar2 are inferred to be the same car by returning the
tuple <Ian, {RedCar1,RedCar2}>. Anyway, these are relatively minor
details compared to the above.
Apart from this kind of query, I think we also need a second kind of
logical query relating to subsumption/satisfiability questions, e.g.,
is the class C satisfiable and does C subsume D. These kinds of query
can all be reduced to KB satisfiability.
Then, there is a third kind of query that asks about the structure of
the current class hierarchy, e.g., give me all the (direct)
sub-classes of C. These kinds of query are not really "logical"
queries in the same sense as the first two types - the query asks
about the structure of the class hierarchy based on (possibly implicit)
subsumption relationships. For this reason I don't really believe that
the "non-monotonicity" of the answers to the direct subsumer query is
a problem - DL systems have been living with this for years without
anyone worrying about it (so it must be OK!). In any case, this is a
relatively minor detail.
Finally (maybe), we could also consider queries relating to the
syntactic structure of the asserted facts, but I'm not sure that this
should be part of a basic query language.
Regards, Ian
>
> Richard
This archive was generated by hypermail 2.1.4 : 04/02/02 EST