A FIPA Compliant Query Mechanism
Using DAML Query Language (DQL)

 

Mithun Sheshagiri and Anugeetha Kunjithapatham

University of Maryland, Baltimore County
Baltimore MD 21250 USA

 

Draft 2 June 2003

 

 

Exchange of information is a very important aspect of a multi-agent system. The two most common forms of information are; a ‘push’ like mechanism where an agent informs other agents and a ‘pull/query’ like mechanism in which the agent asks other agents for information.  We propose a mechanism which could let heterogeneous agents interact with each other using a query-response mechanism. We have used DAML Query Language (DQL) [1] for query description and a FIPA [2] compliant protocol is used as the transport mechanism.

 

This work was supported by DARPA contract F30602-97-1-0215.  Please contact Mithun Sheshagiri (mits1@csee.umbc.edu) or Anugeetha Kunjithapatham (anu1@csee.umbc.edu) for more information.

 

 

1. Introduction

 

Distributed planning, distributed problem solving, co-operation, collaboration, team formation and team work, joint intentions and goals etc are some of the concepts that let us harness the benefits of multi-agent systems. The common thread that runs along all the above concepts is effective communication methods. Although simple communication mechanisms can be made effective in a narrow domain, they can’t handle the challenges of an open environment. As pointed out earlier querying forms an important mechanism for information exchange. The manner in which the querying mechanism is implemented varies for different systems. As a result, querying across agent applications is difficult. By describing the query using DQL and using FIPA interaction protocol for message transport, we propose a mechanism that can be used by FIPA compliant heterogeneous agents which commit to the DQL ontology.

 

This note briefly describes an implementation based on the August 2002 DQL specifications. Some additional protocol elements have been added since then. Some of the interaction protocols and communicative acts have been deprecated.

 

2. DQL

 

DAML Query Language (DQL) is a formal language that defines a set of protocol elements for conducting a query-answer conversation between agents. A DQL query contains, among other things, a query pattern framed in DAML+OIL. Some literals in this query pattern are unbound variables. The answer consists of a set of terms that bind to the variables and the conjunction of answer sentences are entailed by the knowledge base (referred to as the answer KB) of the replying agent.

 

A DQL query should necessarily contain the following elements:

 

·       Query pattern (explained above)

·       An answer KB pattern that could be an answer KB, a list of answer KBs or a variable. If the variable forms the answer KB pattern then, the replying agent should send reference(s) to the answer KB(s) that was used.

·       All variables should either be categorized as must-bind or may-bind. The answer must contain bindings to all must-bind variables and may or may-not contain bindings to may-bind variables.

 

Optional elements that can be specified in a query are:

 

·       Query premise: statements that need to be asserted into answer KB before querying it.

·       Answer Bundle Size: Size of packets sent as answers (default value infinity)

 

The response to a query (an answer) has the following components:

 

·       Answer sentences to the query

·       The query pattern

·       The agent/server that replied to the query.

 

The answer set is enveloped in an answer bundle which contains a continuation token that indicates future interaction patterns. The continuation token could be a process handle that can used by querying agent to request further answers or an end (unexplained termination) or none (no more answers in answer KB) token. Interested readers are asked to refer the latest DQL specifications for detailed explanations.

 

3. Motivation

 

DQL requires you to adhere to certain protocol elements during a query-answer conversation. It does not describe the interaction protocols that need to be used among participating agents. The query pattern by itself is just a set of triples and does not anyway convey the intention behind sending the set of triples. Attaching communicative acts improves the semantics of the query. We use FIPA communicative acts and protocols to enhance DQL and provide it a transport mechanism.

 

ITtalks [3] is a talk notification service with agent and human interfaces. This agent application was developed to demonstrate various ways of using semantic web descriptions and inferencing in a multi-agent environment. One of the goals was to demonstrate DAML+OIL as an inter-lingua. We wanted our agents to be capable of asking and replying arbitrary queries. The application uses JADE [4] agents that support FIPA protocols. Therefore use of DQL along with FIPA interaction protocols seemed to be a natural choice.

 

4. FIPA Communicative Acts

 

There is fixed pattern involved in querying. First an agent poses a query and waits for an answer. This is followed by one or more replies from agents who were queried.
The following sub-sections discuss possible candidates for a suitable communication protocols.
 
4.1. FIPA Query Interaction Protocol
 
The Query Interaction Protocol consists of a query-ref message followed by a reply from the answering agent. The content of query-ref message is an object described by a referential expression. When we adapt this in the context of DQL, the content would be the query pattern. An agent on receiving a query-ref responds either with a refuse, failure message or with an inform-result when it has an answer. Although this protocol is a good fit, it does not support the DQL notion of sending answers in multiple-bundles: the protocol terminates as soon as a failure or inform-result is received. 
 
4.2. FIPA Request Interaction Protocol
 
The Request Interaction Protocol is also a reasonable fit into the DQL framework. The protocol consists of a request message consists of a description of the action that it wants the receiving agent to perform. In our case the action description is querying the answer KB. The agent receiving the request could reply with a refuse, failure, or (inform-done or inform-result). The communicative act inform-done just informs of the completion of the action and inform-result also provides the result. Obviously, inform-result is appropriate in our case. Again, this protocol almost satisfies out need. Again there is no commitment on the receiving agent’s behalf to send multiple inform-results.
 
4.3. New Interaction Protocol
 
We could alternatively specify our own interaction protocol which could support the requirements posed by DQL completely. This interaction protocol is very similar to the above protocol in which we could use query-ref to send the query across to the receiving agent. However, in reply the receiving agents can send multiple inform-result messages followed by a single inform-end message.
 
We chose to use Query Interaction Protocol with multiple inform-result in the interest of sticking to standards. 
 
5. JESS KB
 
Personal agent in the ITtalks system used JESS (Java Expert System Shell) [5] and DAMLJessKB[6] as the knowledge base and inferencing. We found it convenient to use JESS defqueries for the purpose of querying the answer KB and returning the answers. We have built an ontology [7] that lets us express query-patterns in DAML+OIL. The DAML statements that represent the query pattern are packed into query-ref messages. The agent on receiving the query re-builds the query pattern from DAML sentences and forms a JESS defquery from it. The defquery is fired to obtain the answer set. The answer set is packed into an inform-result and sent across the querying agent. For the sake of readability and compactness, we have not included complete URIs.
 
We represent facts in our JESS KB as follows:
 
(PropertyValue (p predicate) (s subject) (o object))
 
 A query has the form: 
 
(PropertyValue (p place-ont#city) (s person-ont#tom) (o ?x))
 
x is the variable here. In addition the query also contains a simple reference to the answer KB and other details. If the query contains a query premise, then the facts that constitute the premise are asserted before querying.
 
The corresponding defquery looks like this:
 
(defquery foo
       (PropertyValue (p place-ont#city) 
                                (s person-ont#tom) 
                               (o ?x)))
 
The answer returned is in the form of triples and sent back to the querying agent.
 

5. Conclusion & Future Work

 

We have discussed a system that uses FIPA interaction protocols that act as the transport mechanism for DQL. Existing protocols and communicative acts with slight changes satisfy our needs. We also demonstrate our ideas by implementing our mechanism on our agent test-bed. There do not exist ways to elegantly represent the answer set.

 

6. References

 

[1] http://www.daml.org/2002/08/dql/dql

[2] http://www.fipa.org/

[3] http://www.ittalks.org/

[4] http://sharon.cselt.it/projects/jade/

[5] http://herzberg.ca.sandia.gov/jess/

[6] http://plan.mcs.drexel.edu/projects/legorobots/design/software/DAMLJessKB/

[7] http://userpages.umbc.edu/~anu1/DAML/DQLOntology.daml