TAGA: Using Semantic Web Technologies in Multi…

     TAGA: Using Semantic Web Technologies in
              Multi-Agent Systems

                   Youyong Zou, Tim Finin, Li Ding and Harry Chen

                   Computer Science and Electrical Engineering Department
                         University of Maryland, Baltimore County
                        {yzou1,finin,dingli1,hchen4 }@cs.umbc.edu


      Abstract. Travel Agent Game in Agentcities (TAGA) is a framework that ex-
      tends and enhances the Trading Agent Competition (TAC) scenario to work in
      Agentcities, an open multi agent environment based on FIPA compliant platforms.
      TAGA uses the semantic web languages and tools (RDF and OWL) to specify
      and publish the underlying common ontologies; as a content language within the
      FIPA ACL messages; as the basis for agent knowledge bases via XSB-based
      reasoning tools; to describe and reason about services. TAGA extends the FIPA
      protocols to support open market auctions and enriches the Agentcities with auc-
      tion services. The introducing of the semantic web languages improves the inter-
      operability among agents. TAGA is intended as a platform for research in multi-
      agent systems, the semantic web and automated trading in d    ynamic markets as
      well as a self -contained application for teaching and experimentation with these
      technologies.
      Keywords: Agentcities, FIPA, Multi Agent System, OWL, Semantic Web,
      Trading Agent Competition.



1 Introduction

The Trading Agent Competition (TAC) [Wellman, 2002] was a test bed for intelli-
gent software agents that interact through simultaneous auctions to obtain services
for customers. The trading agents operated within the travel market scenario, buying
and selling goods to best serve their given travel clients. TAC was designed to pr o-
mote and encourage research in markets involving auction and autonomous trading
agents and had proven to be successful after three consecutive year's competitions.

   Although TAC's framework, infrastructure and game rules had evolved over the
past three competitions [Stone, 2000] [Greenwald, 2001] [Wellman, 2001]
[Wellman, 2002], the assumptions and approach of TAC limited its usefulness as a
realistic test bed for agent based automated commerce. TAC used centralized market
server as the sole mechanism for service discovery, communication, coordination,
commitment, and control among the participating software agents. The trading agents
communicate with the central auction server through simple socket interface, ex-
changing pre-defined XML-based messages. In real world, the auction servers and
service providers are distributed among the massive open Internet and have distinct
service descriptions and diverse service access interfaces. The abstractness and
simplicity of the TAC approach helped to launch it as a research vehicle for studying
bidding strategies, but are now perceived as a limiting factor for exploring the wide
range of issues inherent in automated trading in open environment.

   Agentcities [Willmott, 2001] [Dale, 2002] is the international initiative designed to
explore the commercial and research potential of agent -based applications by con-
structing an open distributed network of platforms to host diverse agents and ser-
vices. The ultimate goal is to enable the dynamic, intelligent and autonomous com-
position of services to achieve user and business tasks, therefore creating compound
services to address changing needs. In such an open and distributed environment, the
need of standard mechanisms and specifications is crucial for ensuring interopera-
bility of distinct systems. The Foundation for Intelligent Physical gents (FIPA) pr o-
duces such standards for heterogeneous and interacting agents and agent-based sys-
tems [O'Brien, 1998]. In the production of these standards, FIPA promotes the
technologies and interoperability specifications that facilitate the end-to-end inter-
working of intelligent agent systems in modern commercial and industrial settings.

   Inspired by TAC, we developed Travel Agent Game in Agentcities (TAGA) on the
foundation of FIPA technology and the Agentcities infrastructure. The agents and
services used FIPA supported languages, protocols and service interfaces to create
the travel market framework and provide stable communication environment where
messages expressed in semantic languages can be exchanged. The travel market was
the combination of auctions and varying markets including service registries, service
brokerage, wholesalers, peer-to-peer transactions, bilateral negotiation, etc. This
provided a much richer test bed for experimenting with agents and web services as
well as a rich and interesting scenario to test and challenge agent techno logy. TAGA
is running as a continuous open game at http://taga.umbc.edu/ and source code is
available for research and teaching purposes.

   The next section introduced the TAGA game and six types of agents. The details
of using semantic web technology were presented in Section three. We discussed
TAGA's features and our research contributions in Section four and suggested the
future works in Section five.


2. TAGA Game and Agents

We design TAGA as a general framework for running agent -based market simul a-
tions and games. Our first use of TAGA has been to build a travel competition along
the lines that used in the last three year`s TACs. In the competition, customers travel
from City A to City B and spend several days before flying back. A travel package
includes a round-trip flight ticket, corresponding hotel accommodation and tickets
to entertainment events. A travel agent (an entrant to the game) competes with other
travel agents in making contracts with customers and purchasing the limited travel
services from the Travel Service Agents. Customer selects the travel agent with best
travel itinerary. The objective of the travel agent is to acquire more customers, ful-
fill the customer's travel package, and maximize the profit.

TAGA provides a flexible framework to run the travel market game. Figure 1 show
the structure of TAGA. The collaboration and competition among six types of agents
who play different market roles simulate the real world travel market. We find that
basing our implementation on FIPA compliant agent platforms has made the frame-
work extremely flexible. We'll briefly describe the different agents in our initial
TAGA game.




                             Figure 1: TAGA Architecture

   The Auction Service Agent (ASA) operates all of the auctions in TAGA. Supported
auction types include English and Dutch auctions as well as other dynamic markets
similar to Priceline.com and Hotwire.com.

    A Service Agent (SA) offers travel related service units such as airline tickets,
lodging and entertainment tickets. Each class of travel related service has multiple
providers with different service quality level and with limited service units. It allows
other agents to query its description (e.g. service type, service quality, location) and
its inventory (the availability or price of a certain type of service unit). Other agents
may directly buy the service units through published service interface. SA also bids
intentionally in the auctions to sell its good, e.g. listing its goods in auction and wait
for the proper buyer.

  A Travel Agent (TA) is a business that helps customers acquire trave l service units
and organize travel plan. The units can be bought either directly from the service
agents, or through an auction server.
  A Bulletin Board Agent (BBA) provides a mechanism helping customer agents find
and engage one or more travel agents.

   A Customer Agent (CA) represents an individual customer who has particular
travel constraints and preferences. Its goal is to engage one or more TAs, negotiate
with them over travel packages, and select one TA that is able to acquire all needed
travel service units.

   The Market Oversight Agent monitors the game and updates the financial model
after each reported transaction and finally announces the winning TA when the game
is over.

The basic cycle of the TAGA game has the following five stages:

  · A customer-generating agent creates a new customer with particular travel con-
    straints and preferences chosen from a certain distribution.
  · The CA sends the customer's travel constraints and preferences to the BBA in
    the form of a CFP (call for proposal) message. The BBA forwards the CA's CFP
    message to each of the TAs that has registered with it. Each TA considers the
    CA's CFP independently and decides whether and how to r espond.
  · When deciding to propose a travel package, The TA contacts the necessary ASAs
    and SAs and assembles a travel itinerary. Note that the TA is free to implement a
    complex strategy using both aggregate markets (ASAs) as well as direct negotia-
    tion with SAs. The proposal to the CA includes the travel itinerary, a set of travel
    units, the total price and the penalty to be suffered by the TA if it is fail to com-
    plete the transaction.
  · The CA negotiates with the TAs ultimately selecting one from which to purchase
    an itinerary based on its constraints, preferences and purchasing strategy (which
    might, for example, depend on a TA's reput ation).
  · Once the TA has a commitment from the CA, it attempts to purchase the units in
    the itinerary from the ASAs and SAs. There are two possible outcomes: the TA
    acquires the units and completes the transaction resulting in a satisfied CA and a
    profit or loss for the TA, or the TA is unable or unwilling to purchase all of the
    units, resulting in an aborted transaction and the invocation of the penalty (which
    can involve both a monetary and a reputation component).


3. Agent Communication

The previous TACs had used a straightforward client-server architecture in which a
single TAC server managed all of the travel service suppliers as well as the custom-
ers. Game participants wrote travel agency (TA) agents that connected as clients to
the central TAC server. Moreover, these TA agents can only interact with service
providers through centralized auction markets. While this architecture greatly sim-
plifies both the development of the TAC infrastructure and the programming of a
TAC client, it is a poor model for commerce in the real world. Peer-to-peer or
multi-agent systems offer a more realistic model where customers, service provi d-
ers and various kinds of "middlemen", including market providers, operate as
autonomous peer agents. Moreover, agents can develop complex strategies, which
involve a combination of direct transactions (e.g., TA buy direct from hotel agent) as
well as auction-mediated transactions of various kinds. Finally, adopting a multi-
agent systems approach supports an environment in which all aspects of commerce
can be integrated in a more natural manner ­ service discovery, information seeking,
negotiation, decision making, commitment, transaction execution, etc.

   The FIPA standards offer mature, published specifications for multi-agent sys-
tems communication, interactions and infrastructure with an emphasis on agent
communication languages (ACLs) and protocols. We found the FIPA fram ework to
be a good one for TAGA when augmented with the semantic web languages RDF
[zou, 2003] and OWL. In the remainder of this section we will describe the choices
made for the content languages.


3.1 OWL as Content Language

The content language is a language used to express the content of messages ex-
changed between agents. The FIPA communication infrastructure allows agents to
communicate using any mutually understandable content language as long as it satis-
fied a few minimal criteria as a FIPA compliant content language [FIPA, 2003].
Published FIPA specifications provide a library of registered FIPA compliant con-
tent language, including FIPA-SL, XML and RDF. A good content language should be
able to express rich forms of content and can be efficiently processed and fit well
with existing technology. XML, used by the TAC system, is adequate as a low level
language for encoding information but falls short as a language in which to express
information at the knowledge level, even when augmented by more recent compo-
nents such as XML Schema, XSL or through applications such as WSDL.

   Our TAGA system uses OWL [Dean, 2002] as the content language for agent
communication. Compared with RDF that used on our previous TAGA work [Zou,
2003], OWL has a well-defined model-theoretic semantics as well as an axiomatic
specification that determines the intended interpretations of the language. OWL is
unambiguously computer-interpretable, thus making it amenable to agent interopera-
bility and automated reasoning techniques. The benefit of adopting a stronger seman-
tically rich content language like OWL is that it facilitates a higher-level of interop-
erability between agents. By agreeing on how meaning is conveyed, it is simpler for
applications to share meaningful content.

  We have defined the OWL ontology for use as a FIPA-compliant content lan-
guage. In addition to the basic required classes (e.g., Agent, ACLMessage, Service,
etc.) and necessary expressive requirement (such as Proposition, Action, and Reifi-
cation), our ontology provides supports for expressing rules, queries and responses
to queries. We believe that OWL is a good choice as a general ACL content lan-
guage for four reasons. First, its expressive power as a knowledge representation
language seems to be adequate for many if not most needs of current agent based
systems. Second, it offers better support for using terms drawn from multiple
ontologies than do current popular ACL content languages. Third, as a semantic web
language, it is designed to fit into and integrate with web-based information and ser-
vice systems. Fourth, OWL has the potential to be a widely accepted and used repr e-
sentation language, enhancing the potential for interoperability among many sys-
tems. We will touch briefly on the first two points and leave the others as exercises
for the reader.

    To demonstrate that OWL is an adequate language for ACL content we consider a
list of test cases presented in [Bothelo 2002]. These examples were used as an
expressive test for a candidate FIPA content language and compared the result of
encoding these in SL, KIF [Genesereth, 1992], ebXML, Prolog and DAML. Clearly
OWL is less expressive than SL, KIF or Prolog, but the OWL version of these test
cases given in Table 1 show that it's up to most of tasks it might be asked to serve.

    Expression              Representation                                      Comment
 "Schrödinger's                              There is a live cat in the world
 Cat is alive"                 Shrodinger                     whose owner is Shrodinger.
                                alive 
                         
 "Cats      are   ani-                               Cat is subclass of animal
 mals"                    
                         
 "You making the                        There is a making-tea action,
 tea"                      making-tea             "you" are the actor.
                         you
                         
 "Drinking   too                             The behavior of drinking too
 much is bad for