Re: DQL Query Patterns and Variable Bindings

From: Pat Hayes (
Date: 01/13/02

>In this message, I will reply to your comments on my overview of what's
>in a query and in a query response.  I will comment on your proposed use
>of continuations in a following message.

OK, and sorry the response is so late. Im catching up slowly :-)

>>  >
>>  >* Knowledge Base - I think we are all agree that a query is posed with
>>  >respect to a DAML+OIL knowledge base.  Thus, a query needs to include a
>>  >reference to a DAML+OIL knowledge base.  I am referring to that
>>  >knowledge base as the "query KB".
>>  It would make more sense to call it the 'server KB'.
>>  Do we in fact want to assume that there is a unique KB for each
>>  query? Eg consider a 'services' setting in which a query can be
>>  published, meaning 'any site that can prove this, give me an answer'.
>>  The RDF core WG considered such a possibility, where one might
>>  publish a piece of RDF that said, in effect, please prove that I can
>>  get flowers from you amounting to this quantity before this date at
>>  less than this price (and then you and I have a deal).
>>  This might well be a natural way to deal with 'queries', in fact, in
>>  a commercial B2B context; the logic is the same, so why not allow it
>>  as a possibility? In other words, such a publication is a kind of
>>  open-ended query in which the KB - ie the identification of the KB -
>>  is itself part of the answer.
>Interesting.  I have been thinking of a query as asking what is entailed
>by a given logical theory.

Right, me too.

>I think you are suggesting that we expand
>that notion to include asking what is true in some domain of discourse
>like our consensus reality.

Well, you might phrase it that way, but what I had in mind was 
something more restricted, ie allowing logical theories to choose 
themselves to 'match' a query.

>That would mean, for example, that a query
>could ask "Who is the Chief Justice of the U.S. Supreme Court" (to take
>a random example), or as you suggest, ask a query about a Web service.
>If we do that expansion, what constitutes a correct answer to such a

Well, the answer is still what it was before, but now it includes a 
specification of the KB that is providing the answer. The only 
difference is who chooses the KB: is the query always directed to a 
particular KB, 'chosen' by the query itself, or can a query be 
directed to a community of KBs, and thereby invite many, possibly 
different, responses?

>What if a server said that I was Chief Justice of the U.S.
>Supreme Court?

Well, if that is what it said, then it could presumably be held 
responsible for any valid conclusions from that assertion.

>When a query is about entailment in a given logical
>theory, we know what the test is for correctness of an answer.

I wasn't suggesting changing that, only allowing the query to be 
answered by several different 'theories'. This is a web context, 
after all, and presumably we have to expect that there will be many 
ontologies in use.

>I don't
>know what a query is about when it is not with respect to a given
>logical theory.

Well, it is exactly the same, but it invites any theory to prove it. 
The logic is the same.

>Of course, an easy case is where a knowledge base is
>not specified in the query but is specified in a query answer so that
>the answer specifies a sentence that is entailed by the knowledge base
>that is referred to in the answer.

Right, exactly. That is what I was suggesting.

>>  >* Premise - I have proposed that a query optionally include a premise to
>>  >facilitate if-then queries while still remaining within the
>>  >expressiveness of DAML+OIL.  Specifically, I have proposed that a
>>  >premise be an arbitrary DAML+OIL knowledge base.  There has been no
>>  >formal agreement on whether or not DQL will allow a "query premise".
>>  I would vote not, in the first draft. It smacks of tiptoeing into
>>  'rules' territory, and it ought to be definable in any case by
>>  querying a KB containing the premise and an import of the previous KB.
>Well, we have discussed this before.

Right, and I still think that the answer should be not, in the first 
draft. I would like to keep the query language as simple as possible 
at first, and solve the problems a few at a time.

>  The primary motivation is to allow
>queries to be stated using only DAML+OIL (no rules) that hypothesize and
>describe objects and then ask a question about the hypothesized objects.

That seems like a potential minefield to me, and one that we should 
venture into carefully.

>>  >answer will include a binding for each distinguished variable.  I am
>>  >referring to the variables in the query pattern that are not
>>  >distinguished variables as "non-distinguished variables".
>>  undistinguished variables?
>From a quick check on the Web, I find them being called
>"nondistinguished variables".
>>  >
>>  >* Query - The query to which this is a response.
>>  >
>>  >* Server - The server that produced this response.
>>  ? This seems rather like having a piece of code sign its name to
>>  everything it does. Surely, if I am querying a KB, I already know
>>  what the query was. Why do I need to be told this again?
>>  BUt in any case, what exactly *is* the 'server' here? You seem to be
>>  assuming that servers are genuine things on the web, but that seems
>>  to be something that we havn't really decided on yet. How does DAML
>>  refer to agents, so it can express this response? (Or indeed to
>>  queries, for that matter)?
>I was assuming that a server has a URI.

OK. But then we need on ontology of servers, right?

>I suppose it is not critical that a query response contain a pointer to
>the query to which it is a response, but it certainly needs to contain a
>pointer to the server, since the answers contained in a response are
>server-specific in that those are the answers that that server did
>produce to the query.  (Yes, each answer is correct or not regardless of
>who produced it, but the set of answers is server-specific in that those
>are the ones that were produced by the server out of all the possible
>correct answers.)
>>  >* Answers - Zero or more answers to the query.
>>  Right, but how is 'zero answers' indicated?
>I don't see that as being a problem.  A query result would necessarily
>have some sort of collection (e.g., a list) of query answers, and if
>there are zero answers then that collection would be empty.

OK again.


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