From: Ian Horrocks (horrocks@cs.man.ac.uk)
Date: 10/25/01
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
>
>
This archive was generated by hypermail 2.1.4 : 04/02/02 EST