Re: (DQL) Expressiveness of Query Patterns

From: Richard Fikes (fikes@ksl.stanford.edu)
Date: 11/30/01


> >We seem to agree on the following: a query contains a "query pattern"
> >that specifies relationships among unknown sets of objects in a domain
> >of discourse.  Each unknown object is represented in the query pattern
> >by a variable.  Answering a query with variables x1,,xn involves
> >identifying tuples of term expressions such that for any such tuple
> ><c1,,cn>, if ci is substituted for xi in the query pattern for i=1,,n,
> >then the resulting "query pattern instance" specifies a sentence that is
> >entailed by the query KB.
> 
> I'm happy with that, but I'm surprised that you are. For example, 
> this would rule out queries about the immediate superclass of a 
> class, or about the numbers of different answers, and so on.

We indeed will need to add on capabilities for "immediate superclass of
a class", "numbers of different answers", etc.  I am becoming
increasingly concerned that we do not have agreement on even the basics
of DQL, and so I am focusing on one piece at a time.  The query pattern
and the bindings seem to be a core place to start.  Note that in the
above I didn't say that a query *is* a query pattern, I said that a
query *contains* a query pattern.  

> >Let's focus here only on issues related to the expressive power of the
> >query pattern.  I proposed that we define the query pattern language so
> >that a query pattern specifies a conjunction of RDF statements
> >containing variables.  A query pattern instance would then specify a
> >collection of RDF statements that are entailed by the query KB.
> 
> Entailed in RDF or in DAML+OIL?

Entailed in DAML+OIL.

> But in any case, this seems wrong-headed. Why a conjunction of RDF 
> statements? Wouldn't it be more fitting for us to have a conjunction 
> of DAML+OIL statements? After all, arbitrary conjunctions of RDF have 
> almost nothing to do with DAML+OIL: they might not encode any 
> DAML+OIL, and quite a lot of DAML+OIL, when encoded in RDF, is not 
> validly RDF-entailed (as Peter pointed out recently).

This issue came up in the telecon this week.

The first sentence of the "Introductory remarks" section of the
reference description for DAML+OIL
(http://www.daml.org/2001/03/reference.html) says: "A DAML+OIL knowledge
base is a collection of RDF triples."

I mean for a query pattern to specify a conjunction of DAML+OIL
sentences.  I thought since a DAML+OIL knowledge base is a collection of
RDF triples that an appropriate form for the query pattern is a set of
triples corresponding to RDF statements with variables.  If you disagree
with that, propose an alternative.  That is, what would "a conjunction
of DAML+OIL statements" look like?

In any case, I presume we agree that a query pattern is to be a
specification of a conjunction of DAML+OIL statements containing
variables.

> >In general, I don't think we should restrict the expressiveness of our
> >query language based on the capabilities of our reasoning algorithms.
> 
> I strongly disagree. The entire philosophy of DAML+OIL has been to 
> take reasoning capability as a central guiding principle. There is no 
> other reason to even consider description logics, in fact: if we are 
> not concerned with reasoning efficiency, then full omega-order logic 
> provides a much more natural, compact and expressive notation. I 
> think we should retain processing efficiency as a central guiding 
> principle of the DAML+OIL 'class' of web logics.

Well, there is an issue here of goals.  I am interested in designing a
query-answering language and protocol for DAML+OIL that will be
generally useful for the Semantic Web.  Almost no one outside the KR&R
community cares about logical completeness or tractability in most
cases.  The typical application needs to be able to effectively retrieve
information from a knowledge base and have the retrieval operation be
able to make simple inferences from the information in the associated
ontologies.  We don't want to force people to reformulate simple queries
into class membership or subsumption queries or to interpret results
stated in those terms.

Also, as soon as we expand the expressiveness of DAML to include some
kinds of rules, I expect that most of the formal reasoning results will
be inapplicable.  So, I think that a successful markup language for the
Semantic Web is indeed going to be sufficiently expressive to be
difficult to reason with and that a successful query language for the
Semantic Web is indeed going to allow one to express queries that are
extremely difficult or perhaps impossible to answer.  I don't think we
want to require that knowledge servers be able to answer any query that
is expressible, nor do we want to require them to be logically complete.

> I would suggest a different proposal. Let us adopt as a very simple 
> basic query format which the DL gurus know how to answer rapidly in a 
> guaranteed timeframe, eg the query of membership in a named class. 
> Then, let us invent a set of query/client protocols for encoding more 
> elaborate or subtle queries as 'conversations' made up of these 
> simpler queries, perhaps taking place in an order that is sensitive 
> to the replies gotten from earlier queries and perhaps involving the 
> maintenance of a temporary namespace to act as a common ground 
> between the server and client (which is now acting as a server for 
> the more elaborate querying process.) In this way, rather than invent 
> querying formats in the abstract, we can ensure that the more 
> elaborate queries are implementable; and, if we design the protocols 
> with care, that they have appropriate logical properties.
> 
> For example, to find out how many things there are in a class, one 
> way might be to ask if it has any members; then ask the same question 
> about the class defined by the intersection of the previous class 
> with the complement of the set of members found so far. This might 
> iterate for a while, of course, but if it terminates then you have a 
> list of the members. And the client/server agent could, for example, 
> be delivering those answers to its client in real time, as it finds 
> them on its server.

The floor is open to alternative proposals.  I would encourage you to
turn the sketch above into a specific detailed proposal for the
committee's consideration.

Richard


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