From: Deborah McGuinness (dlm@ksl.stanford.edu)
Date: 08/20/02
a few comments below with examples of why I have found descriptions of queries to be useful. pat hayes wrote: > >We're developing an environment in which agents that > >communicate with the standard FIPA (http://fipa.org/) agent > >communication language and protocols can use DAML+OIL as a > >content language. Our immediate applications involve agents > >which provide event and calendar management related services > >as part of our ongoing ITTALKS (http://ittalks.org/) system. > > > >One of our current implementations uses the Jess rules > >engine to reason about DAML+OIL content (using an enhanced > >and extended version of the DAMLJessKB), draw additional > >domain and application appropriate inferences, make > >decisions and perform actions. > > > >The FIPA ACL has a very simple query model (query-if and > >query-ref) so we are trying to fit DQL into this framework > >by adding a few new communicative acts (CAs), reusing > >existing FIPA CAs as much as possible, and developing > >appropriate FIPA protocols, specifying them in agent UML > >(http://www.auml.org/). Since have a working prototype, > >we're anxious to use it to experiment with the DQL concepts. > > > >To this end, we've written an initial DAML Ontology for DQL queries > >(http://userpages.umbc.edu/~anu1/DAML/DQLOntology.daml) > >based on 01-DQL_spec_version2.html and are using this in our > >prototype. > > Er..guys, I havnt looked at the details of this, and maybe I have > misunderstood what you are doing; but there seems to me to be > something fundamentally wrong with the very idea of having an > ontology for queries. Ontologies express assertions; they describe > things. Queries, in contrast, ask questions. A query is not an > assertion. In logical terms, assertions (ontologies) and queries are > on opposite ends of the sequent arrow. Querying is a different kind > of speech act from asserting. So an ontology of queries seems like an > oxymoron. > I would like to give another perspective. In previous work, I with a lot of colleagues at AT&T, did an application of description logics for "data archaelogy". the stated purpose was to help data analysts look for patterns in their data. (one example was looking for customers who were likely to disconnect service and thus point a marketing person at them to help them get a service from the company they would not be likely to disconnect). The project was called imacs (see [1] at end) the data analysts formed "queries" in the form of class descriptions. Those class descriptions were then used as a query as "get all instances (or subclasses) of the description. These descriptions were stored and rerun. The descriptions were also in an embedded system that had nice graphics for displaying the results of those "queries". the ontology of class descriptions used for querying the system was found valuable for a number of reasons - some of which were: 1 - ease of query formation (the data analysts previously had to form queries with awk or grep) 2 - reuse of queries 3 - consistency of query usage 4 - analysis of queries (we kept a subsumption hierarchy, told them if the queries were incoherent or redundant with other queries, etc.) 5 - understandability of query results (the graphical presentation of the information was found to be very useful to the data analysts. > To make the point in another way: suppose one does have an ontology > of queries, and I then use it to describe a query. OK, Ive described > a query. But I havnt thereby actually QUERIED anything: describing queries can be of value as i tried to state above. also, once the query is described markup including how to present instances of the description or answers to the query can be quite useful. I have that point better documented in a paper with borgida called asking queries about frames [2] and in a configuration example application [3] discussed in a paper called "description logic in practice". > I havnt > expressed a request for information, or asked for something to be > proved, or requested that a knowledge-base server actually do > anything about it. All I have done is make another assertion, one > that says a query exists, in effect. But of course queries exist: > that doesnt need to be asserted. > > So my comment is that I fail to see what you think the point is of doing this. > > Comments? > > Pat Hayes > > PS. There is another technical reason why any such attempt to > describe what is essentially a piece of syntax in a language like > DAML is bound to be incomplete, which is that DAML simply doesn't > have the expressive resources to describe syntax adequately. Even > full first-order logic doesn't have enough, so DAML certainly does > not. > > -- > --------------------------------------------------------------------- > 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 [1] Ronald J. Brachman, Peter G. Selfridge, Loren G. Terveen, Boris Altman, Alex Borgida, Fern Halper, Thomas Kirk, Alan Lazar, Deborah L. McGuinness, Lori Alperin Resnick. ``Integrated Support for Data Archaeology.'' In International Journal of Intelligent and Cooperative Information Systems, 2:2 1993, pages 159--185. [2] http://www.ksl.stanford.edu/people/dlm/papers/kr96-abstract.html [3] http://www.research.att.com/sw/tools/classic/tm/ijcai-95-with-scenario.html -- 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 : 08/20/02 EDT