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

From: Deborah McGuinness (dlm@ksl.stanford.edu)
Date: 10/25/01


If we ignore the skolem individuals and answer only named individuals without any
additional information,
then we are misleading users.

In my previous example where we know that pat has a parent who is a foo and pat has a
parent who is a bar
(and we do not know anything else)
if we ask who are pats parents and say there are no bindings, then we are certainly
misleading users into thinking we can not deduce that pat has any parents.

if we choose to return only named individuals, we need to hit the user over the head with
information that allows the user to easily figure out that the system does know that pat
has at least one parent even though we have not been told the name of the parent.

I am not saying that this can not be done with the interface, what I am saying is that it
is important not to give the user information that the majority of users will use the
wrong way.
In the case of my example, I would claim that the majority of users would take the
information that we do not know any bindings to infer that the system can not deduce that
pat has parents.

d


Ian Horrocks wrote:

> I still say we are getting in way to deep here when we haven't even
> devised a basic query language whose characteristics and behaviour we
> can formally define. As I said in my other messages, I believe that
> returning "skolems" could have many/serious consequences for the
> decidability, tractability etc. of the query language. Infinite
> answers is just one of these that springs to mind.
>
> Ian
>
> On October 24, Deborah McGuinness writes:
> > When i introduced the notion of followup questions for explanations and later for
> > querying frames,
> > it did not in my opinion modify the underlying structure of the language
> > requirements.
> > The followup query in explanation in my original work just exploits the system's
> > knowledge of variable bindings (and a tiny more) to generate appropriate followup
> > questions.
> >
> > In Alex's and my work on querying frames, the query language is simply the
> > underlying description language with variables in certain places.
> > The followup question mechanism I mentioned in the drop down menus  just returned a
> > pretty form (basically pretty printed objects with interactiveness thus they could
> > be clicked on and explored)
> > and then generated the followup menu choices from information encoded for the
> > class.
> >
> > I do not think it needs to modify the query language much - the only thing is
> > providing for the notion of a followup question that can be:
> > 1 - input by the user using the values returned in the previous answer - thus if we
> > have skolems in the previous answer, this should be able to be used as input
> > 2 - potentially generated by the system
> >
> > The fancy stuff with choosing "good" followup questions can just be viewed as a
> > kind of pruning
> > but i do not think it requires language extension.
> >
> > d
> >
> > Ian Horrocks wrote:
> >
> > > I think that we are now in danger of conflating the query language
> > > with a dialogue that some application might have with a user given the
> > > existence of a DAML+OIL reasoner with the kind of query language I
> > > thought we were discussing. The kind of query language structure I
> > > described in my previous message (which I thought was roughly what we
> > > have been talking about up to now) would be able to power the
> > > dialogues Pat described, but are we really imagining building all this
> > > extra stuff into it?
> > >
> > > E.g., in Pat's second example we could answer the question using the
> > > two queries "return me all the instances of the class of soups with
> > > things in them" and "return me all the instances of the class of
> > > things that are in MySoup" - if MySoup is in the first set we can
> > > return the second set, or "don't know" if it is empty (actually, Pat's
> > > dialogue seems a bit broken at this point as there may be many things
> > > in the soup, some/all of which we can name and some/all of which we
> > > can't).
> > >
> > > Ian
> > >
> > > On October 24, Deborah McGuinness writes:
> > > > comments inline below  but I think this discussion supports a position i
> > > > believe in - answers should be interactive - a user should be able to get
> > > > more information about portions of the answer.
> > > >
> > > > support below:
> > > >
> > > > Pat Hayes wrote:
> > > >
> > > > > >  >>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
> > > > > for.
> > > > >
> > > > > >I am ok with that scheme, and so could agree to query variable bindings
> > > > > >in answers that are identified as being gensyms representing existential
> > > > > >variables.
> > > > >
> > > > > 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. )
> > > > >
> > > >
> > > > I do not think it is so bad to return a gensym  or skolem as long as the user
> > > > can essentially point and click and ask what the system knows about it (or in
> > > > a text based interface  ask say for the parents of it, the color of it, etc.)
> > > >
> > > > >
> > > > > >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'?
> > > >
> > > > i dont think we want to give everything we know about it - that is likely to
> > > > be quite a lot.
> > > > this is where i think followup questions make sense
> > > >
> > > > >
> > > > >
> > > > > Pat
> > > > >
> > > > > 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.
> > > > >
> > > >
> > > > followup might be - would you like to know more about what is in the soup?
> > > > (in one interface i did, we had "obvious" followup questions appear in a pull
> > > > down menu.
> > > > these were based on meta information about what slots were "interesting" for
> > > > classes and then followup questions could be generated for the "interesting"
> > > > slots (along with followups about parents)
> > > >
> > > > >
> > > > > 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.
> > > > >
> > > >
> > > > a followup might say - i do have the following information about it -
> > > > parents  and information on the following 4 properties - would you like some
> > > > of 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
> > > > > phayes@ai.uwf.edu
> > > > > http://www.coginst.uwf.edu/~phayes
> > > >
> > > > --
> > > >  Deborah L. McGuinness
> > > >  Knowledge Systems Laboratory
> > > >  Gates Computer Science Building, 2A Room 241
> > > >  Stanford University, Stanford, CA 94305-9020
> > > >  email: dlm@ksl.stanford.edu
> > > >  URL: http://ksl.stanford.edu/people/dlm/index.html
> > > >  (voice) 650 723 9770    (stanford fax) 650 725 5850   (computer fax)  801
> > > > 705 0941
> > > >
> >
> > --
> >  Deborah L. McGuinness
> >  Knowledge Systems Laboratory
> >  Gates Computer Science Building, 2A Room 241
> >  Stanford University, Stanford, CA 94305-9020
> >  email: dlm@ksl.stanford.edu
> >  URL: http://ksl.stanford.edu/people/dlm
> >  (voice) 650 723 9770    (stanford fax) 650 725 5850   (computer fax)  801 705 0941
> >
> >

--
 Deborah L. McGuinness
 Knowledge Systems Laboratory
 Gates Computer Science Building, 2A Room 241
 Stanford University, Stanford, CA 94305-9020
 email: dlm@ksl.stanford.edu
 URL: http://ksl.stanford.edu/people/dlm
 (voice) 650 723 9770    (stanford fax) 650 725 5850   (computer fax)  801 705 0941


This archive was generated by hypermail 2.1.4 : 04/02/02 EST