From: Richard Fikes ([email protected])
Date: 09/24/01
DQL 0.1 provides a language for expressing a query to a DAML+OIL
knowledge base and a language for expressing an answer to such a query.
Although languages for expressing a query and an answer are clearly
needed, they support only a subset of the essential information that
needs to be exchanged during query-answering. Specifically, they do not
support the following:
* How many answers to a query does the query asking agent (which we
will refer to as the client) want? All of them? At most n? All that
can be found in k seconds? �
* What does the query answering agent (which we will refer to as the
server) return when it has been asked for all answers and it concludes
that there are an infinite number of answers?
* What does the server return when it has found all the answers it can
(or has the resources to find), but doesn't know whether it has found
all possible answers?
* What does the server return when it knows how many answers there are
(e.g., from a cardinality restriction), but has no object names from the
knowledge base for those answers? (I.e., is the server to return
anonymous objects as answers to a query?)
* How does the client ask for the answers "a batch at a time" so that
it can dynamically decide whether it wants the server to produce more
answers.
* How does the client ask for proofs (or other explanatory information)
of the answers provided by the server?
Such requirements would lead us to expand DQL to include what might be
considered to be a set of commands (e.g., "Ask"), each with a set of
arguments and expected return values. For example, we might posit an
"Ask" command as follows:
Ask Command
* Arguments: kb, query premise, query pattern, answers needed
(either a positive integer or "All")
* Results: answer collection, answer status
where the answer status has one of three values indicating:
* The answer collection is all possible answers;
* There are infinitely many answers and if n answers
were requested the answer collection contains as many
of the n answers as the server could produce or if all
answers were requested the answer collection contains
a sampling of answers;
* The answer collection contains all the answers the server can
produce and there may be more.
We may also want to posit a collection of commands that enables the
client to pose a query and get back a process handle (aka, a
continuation) that can be sent to the server in subsequent commands to
incrementally request answers to the query.
Yulin Li and I have been developing a design for such expansions to DQL
0.1, but rather than send out that design at this point, I propose that
the committee consider the need for such an expansion. When we reach a
consensus on whether and in what form to address the issues raised in
this message, we can then consider specific design proposals for doing
so.
Richard
This archive was generated by hypermail 2.1.4 : 04/02/02 EST