existential answers to queries (was: Re: on behalf of sandro)

From: Pat Hayes (phayes@ai.uwf.edu)
Date: 10/24/01

>  >>And then we have the query: "is there anything with any color?", or
>>>RDF(?x, color, ?y).
>>>Do we get back
>>>(a) 1 triple
>>>   <patsCar> <color> <blue>.
>>>or (b) 2 triples
>>>   <patsCar> <color> <blue>.
>>>   _:b <color> <red>.
>>>(where I've changed the _:a to _:b just to emphasise that it is an
>>>arbitrary term, and its scope does not carry over from the knowledge
>>>base to the response).
>>>or (c) 2 triples with genid (skolem constant)
>>>   <patsCar> <color> <blue>.
>>>   <reasonerCreatedSymbol79878687> <color> <red>.
>>>If everyone actually is happy with (b), then we were in fact in
>>>violent agreement.  If not, then there's a real issue here.
>If we accept that we can say in rdf "exists x (RDF(x, color, red))",
>then I indeed have been arguing for (a) rather than (b) or (c).
>It seems to me that (b) and (c) are saying that we will allow an answer
>to a query to contain a binding of a query variable to a constant
>created to represent an existential variable.  As I think Pat is
>pointing out, that makes sense only if the answer is constructed so that
>it is clear which constants represent existential variables, and that
>for query body instances to be entailed by the KB, the constants in the
>answers that represent existential variables need to be appropriately
>replaced by existential variables.

I wouldn't phrase it quite that way. If the KB uses *constants* then 
they are perfectly OK as bindings to query variables, right? The 
issue is what to do if the KB has an existential *variable* in it (eg 
an anonNode in RDF, say) and the query-answering process would 
'succeed' only if it were able to bind this existential to an answer 
variable. Notice that it would be fine to bind it to a variable in 
the query that is not an answer variable, as Ian pointed out in the 
telecon; so its not that the binding itself is logically invalid, 
only that it wouldn't be correct to deliver that variable as an 
answer (bound to a query variable), because that delivery - from the 
KB to the query engine - would take the name outside its scope. So, 
if we were to block the delivery of the local name from the KB to the 
query engine, in effect what the KB would be saying would be 
something like : 'your query is true, and I have found something that 
satisfies it, but I'm not going to tell what it is.' At which point 
the 'sensible' thing for the query engine to do is to decide to 
believe an existential assertion, ie to make up its own local name 
for the thing that it now knows exists but hasn't been told a name 

>I am ok with that scheme, and so could agree to query variable bindings
>in answers that are identified as being gensyms representing existential

I'd say that a gensym was a skolem constant if it was generated by 
the KB, and that a skolem constant is a perfectly reasonable 
answer-binding. (The trouble with talking about gensyms in this 
context is that you have to say who has the licence to generate the 
sym.  Gensyms are local variables inside the scope 'owned' by the 
generator of the symbol, and in this discussion there are two 
different generators, using different sets of rules. )

>Just to check, I presume this would apply to cardinality restrictions as
>well.  For example, if the KB says that persons have exactly two values
>of property "parent" (because of a cardinality restriction), the KB does
>not identify Pat's parent, and we ask the query RDF(Pat parent ?x), then
>I presume the complete set of answers would be the triples (Pat parent
>_:p1) and (Pat parent _:p2) (or the bindings {[?x _:p1]} and {[?x
>_:p2]}) where _:p1 and _:p2 are noted to be existentials.

That raises a more general issue, about how much information should 
be in an 'answer'. If the answer is just a set of bindings, I would 
say that in this case expecting to get two existentials back from a 
cardinality restriction is asking for too much. That is like saying 
'who is Pat's parent?' and getting the answer 'Don't know, but I know 
there are two of them'. That really is an answer to a different 
question, seems to me. Who knows what the KB might know about Pat's 
parent? Would you expect to get something like 'Don't know, but I 
know that one of them had an uncle who was once seen talking to 
someone in the Chinese civil service'?


PS. Example to illustrate the above discussion. Two people, K and Q, 
are talking to each other.
1. Simple existential query:
Q: Is there anything in the soup?
K: Yes.

2.  Existential query with answer variable binding:
Q: Is there anything in the soup, and if so what is it called?
K: Yes, but I'm not going to tell you what I call it.

3.  Simple existential query with constant name in the KB:
Q: Is there anything in the soup, and if so what is it called?
K: Yes, and it is called Fred.
Q: What kind of thing is Fred?
K: Fred is a frog.

The basic difference between 2 and 3 is that because the name is 
handed across the conversational boundary (ie is in the common ground 
of the conversation, which is like a global scope that contains both 
conversationalists), it is possible to ask for more information about 
it in case 3, but not in case 2. So handing out a name gives the 
querier a handle with which it can eventually extract more of the 
information about the entity, even though the KB does not deliver it 
all at once.

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