Re: Query continuations (was: Re: DQL Query Patterns and VariableBindings)

From: Pat Hayes (phayes@ai.uwf.edu)
Date: 01/13/02


>  > Here's a modification to Richard's suggestion for handling queries.
>
>I basically like this proposal.  My proposals have included the option
>of returning answers a batch at a time along with a continuation (aka
>enumerator).  I had been assuming that we would also want to support the
>case that did not use such continuations.  But, I think you make a
>compelling argument that the other cases can be constructed from the
>core enumeration mechanism that you describe.
>
>Here are some detailed comments.
>
>>  A query is an expression containing d-variables and nd-variables
>>  which would be legal DAML+OIL when appropriate bindings are made to
>>  the variables.
>
>Change "A query is" to "A query includes a query pattern that is".  We
>have not yet decided what else is included in a query (e.g., a knowledge
>base, premise, request for justifications, etc.).

OK.

>  > An answer is a set of bindings to some of the d-variables, with the
>>  understanding that the expression got taking the existential closure
>>  of the expression got by applying those bindings to the query follows
>>  from the KB. An answer may be empty, which simply means that the
>>  existential closure of the query follows from the KB. Notice that
>>  there is no need to have a special 'blank' binding, with this
>>  convention.
>
>Interesting.  I would certainly welcome getting rid of the "blank"
>bindings.  However, your proposal seems to have two problems:
>
>First, the proposal is not sufficiently restrictive in that it allows
>for answers in which distinguished variables do not have bindings to any
>of whatever the DAML+OIL equivalent to RDF nodes turns out to be.  For
>example, if the query pattern is "(parentOf Joe ?p)" and ?p is a
>distinguished variable, a legitimate answer would be the empty set of
>bindings based only on the cardinality constraint on parents of
>persons.  I thought we agreed on the telecon that we wanted
>query-answering to mean finding bindings for distinguished variables to
>"whatever the DAML+OIL equivalent to RDF nodes turns out to be", and
>that it did not mean determining whether objects exist that satisfy the
>query pattern.  So, your proposal would need to be amended to say
>something like that the entailed sentence is one in which the unbound
>distinguished variables can only be bound to (anonymous) nodes in the
>query KB.

Sorry, I was careless in the phrasing. I did not mean to imply that 
if the existential closure follows then an empty answer *must* be 
given; only that *if* an empty answer is given that this would be an 
appropriate - valid - conclusion to draw. Its only meant to specify 
the semantics of the answering API, if you see what I mean, not to 
impose any burden on the QA process to deliver all possible answers..

I don't like *defining* answers in terms of the answering machinery. 
While most 'good' QA systems might indeed work with a strict 
delivering-bindings regime, and we should take care that the 
definitions always allow for that case, it is also *possible* to 
imagine other mechanisms, and maybe people will figure out efficient 
ways to do some kinds of cardinality inference, say; so we shouldn't 
rule those cases out either. All we need to say is that the answers 
should follow from the KB, right? That doesn't require the KB to 
solve all logical problems or deliver all possible answers, but it 
allows it to deliver as many as it can or wishes to.

>Second, the proposal does not require the server to return bindings for
>the d-variables when it knows them.  For example, if the query pattern
>is "(parentOf Joe ?p)" and ?p is a distinguished variable, a legitimate
>answer would be the empty set of bindings even in the case where values
>of parentOf for Joe are asserted in the knowledge base.  So, again, I
>think we want to say that unbound distinguished variables can only be
>bound to anonymous nodes in the query KB.

Well, I think that we should indeed allow this case. That is, the 
answering process might be incomplete in some way, but it can still 
deliver useful information. We might add a level of QA 'binding 
conformance' that requires bindings to be given as answers whenever 
they can be found, or some such, but I don't think that it should be 
part of the very definition of what counts as an answer. For example, 
there might be a very fast but very simple QA system that only 
delivers empty answers. That would have its uses for some purposes.

>  > (Each answer indicates a distinct proof found by the KB, but there is
>>  no guarantee that each answer represents a distinct set of entities,
>>  so it is not in general valid to infer numbers of distinct answers
>>  from numbers of responses; the task of finding a set of semantically
>>  distinct answers is a different, quite complex inference process.)
>
>We have discussed this before.  I don't like the idea of defining
>answers in terms of "distinct proofs".  What makes one proof distinct
>from another?  Such a definition will likely vary for varying reasoning
>algorithms.  I would prefer, instead, to say that each set of bindings
>must be distinct.  They don't have to guarantee that they denote
>different sets of objects, just that the bindings themselves must be
>distinct.  So, all that says is that it would not be acceptable to
>return the identical set of bindings a second time.

Well, I have no problem with 'distinct proof', but I would be happy 
to go along with this modification. In fact, I wouldn't even mind 
having the same set of bindings occur more than once in a 'basic' QA 
regime, and have some 'cleverer' process take the trouble to check 
for duplications and eliminate them if it wants to. That takes 
another burden off the basic QA process, and enables it to have a 
smaller, lighter state in its continuations.

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