From: Pat Hayes (phayes@ai.uwf.edu)
Date: 10/24/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.
Hmm. This seems easy in RDF:
_:xxx hasColor Red .
That would seem to imply that RDF can express something that DAML+OIL
cannot express! Which is fine, I guess, but it doesn't jibe with what
I had (perhaps naively) thought was the intended relationship between
RDF/S and DAML+OIL.
(Or does this example satisfy your c.m.property by using 'Red' as the
named individual??)
>
>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.
That is yet another problem.
>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.
But what if the reasoner can infer that a blank RDF node represents
such an individual? That is the case that seems to be tricky here,
when there is no name to be returned.
>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.
Well, I can see a reasonable sense in which if the query is simply
'does such a thing exist?' then the answer could be simply 'yes',
even when no name of any thing is known, as in this case. Did you
meant to allow this kind of simple query?
>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).
Hmmm. I'm not so sure. Consider a query formalization like this:
?[x,y] ( P(x) & RC(y) & O(x,y) )
where the query marker binds the variables defining the required
answer. Then we can distinguish this from
?[x] (exists (y) ( P(x) & RC(y) & O(x,y) ) )
, right? In your example, the second query will return [x/Ian], but
the first one will return nothing. But it seems to me to be
reasonable for the first query to return something like [x/Ian,
y/<blank>], meaning that something exists which satisfies the query,
but no name is available for it (contrast [x/Ian, y/y], which says
that Ian owns all the red cars in the universe), thereby answering
the second query form automatically. Any reasoner that could answer
the second query could in fact generate this information in response
to the first query, so it seems kind of petty to withhold such an
answer on the grounds that the query wasn't formulated in exactly the
right way.
>
>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.
I agree here.
>
>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.
Can't they all be so reduced?
>
>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.
I don't agree either that it is minor or that it is so easily
dismissed. If we are just considering querying in isolation, I might
agree. But if you put it into a broader semweb context, I think this
needs to be looked at more carefully.
>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.
How about answers which indicate contradictions? eg if I ask
?[x] (P(x))
and the system is able to prove that the class of P's has *no*
members. Should it just say 'no answer', or should it tell you that
your assumptions are wrong?
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