Matchmaking Among Heterogeneous Agents on the Internet*
Total Page:16
File Type:pdf, Size:1020Kb
From: AAAI Technical Report SS-99-03. Compilation copyright © 1999, AAAI (www.aaai.org). All rights reserved. Matchmaking among Heterogeneous Agents on the Internet* Katia Sycara, Matthias Klusch, Seth Widoff The Robotics Institute, Carnegie Mellon University, Pittsburgh, USA. {katia, klusch, swidoff}@cs.cmu.edu Jianguo Lu Computer Science Department, University of Toronto, CA. [email protected] Abstract Secondly, even experienced users can’t be aware of ev- ery change on the Internet. Relevant agents may ap- The Internet not only provides data for users to browse, pear and disappear over time. Thirdly, as the number but also databases to query, and software agents to run. and sophistication of agents on the Internet increase, Dueto the exponential increase of deployedagents on the there is an obvious need for standardized, meaning- Internet, automatingthe search and selection of relevant ful communication among agents to enable them to agents is essential for both users and collaboration among perform collaborative task execution. different software agents. This paper first describes the To facilitate the searching and interoperation agent capability description language LARKS.Then we between agents on the Internet, we proposed will discuss the matchmakingprocess using LARKSand the RETSINAmulti-agent infrastructure framework give a complete working scenario. The paper concludes (Sycara et al. 1996). In this framework, with comparing our language and the matchmakingpro- distinguished two general agent categories: service cess with related works. We have implemented LARKSproviders and service requester agents. Service and the associated powerful matchmakingprocess, and providers provide some type of service, such as find- are currently incorporating it within our RETSINAmulti- ing information, or performing some particular do- agent framework(Sycara et al. 1996). main specific problem solving (e.g., numbersorting). Requester agents need provider agents to perform some service for them. Since the Internet is an open 1 Introduction environment where information sources, communica- tion links, and agents themselves mayappear and dis- The Internet not only provides data for users to appear unpredictably, there is a need for some means browse in the Web, but also heterogeneous databases to help requester agents find providers. Agents that to query, and software agents to run. Due to the ex- help locate other agents are called middle agents. ponential increase of deployed agents on the Internet, Wehave identified different types of middle agents automating the searching and selection of relevant on the Internet, such as matchmakers (yellow page agents is essential for both users and the software services), brokers, billboards, etc., and experimen- agent society in several ways. Firstly, novice users in tally evaluated different protocols for interoperation Cyberspace may have no idea where to find a service, between providers, requesters, and various types of and what agents are available for performing a task. middle agents (Decker, Sycara and Williamson 1997). *Thisresearch has beensponsored in part by Officeof Naval We have also developed protocols for distributed Researchgrant N-00014-96-16-1-1222. matchmaking (Jha et al. 1998). Matchmaking is the 152 In the following, we first describe the agent capa- bility description language, LARKS.Then we will dis- MatchmakerAgent x cuss the matchmaking process using LARKSand give M.t°n, a complete working scenario. The paper concludes with comparing our language and the matchmaking ~K ~ AuxiliaryDB -- process with related works. We have implemented Rcsnlt-of’MatchinV/ ]~-- .// ~pablg~D~cdptions LARKSand the assQciated powerful matchmaking RequesterAgent P~" in, LARK% process, and are currently incorporating it within I \ ov,dorAgent,our RETSINAmulti-agent infrastructure framework (Sycara et al. 1996). LAR~ocol I’m mderAgent LAR tocol v’ n ConceptDB1 L"!~"" J ~ the servicefor providing"~A 2 The Agent Capability De- scription Language LARKS ~ onPr°cessRequest’LocalIS ]C~ce~p~B n ~~IS 2.1 Desiderata for an Agent Capabil- ity Description Language Figure 1: Matchmaking using LARKS:An Overview There is an obvious need to describe agent capabili- process of finding an appropriate provider through ties in a commonlanguage before any advertisement, request, or even matchmaking among the agents can a middle agent, and has the following general form take place. In fact, the formal description of capa- (Figure 1): bilities is one of the difficult problemsin the area of ¯ Provider agents advertise their capabilities to software engineering and AI. Some of the main de- middle agents. sired features of such a agent capability description language (ACDL)are the following: ¯ Middle agents store these advertisements. ¯ A requester asks some middle agent whether it Expressiveness The language should be ex- knowsof providers with desired capabilities. pressive enough to represent not only data and knowledge, but also the meaning of program ¯ The middle agent matches the request against code. Agent capabilities should be described at the stored advertisements and returns the result, an abstract rather than implementation level. a subset of the stored advertisements. Most existing agents should be distinguishable by their descriptions in this language. While this process at first glance seems very sim- ple, it is complicated by the fact that providers and Inferences. Inferences on descriptions written requesters are usually heterogeneous and incapable in this language should be supported. Auto- of understanding each other. This difficulty gives mated reasoning and comparison on the descrip- rise to the need for a commonlanguage for describ- tions should be possible and efficient. ing the capabilities and requests of software agents in a convenient way. In addition, one has to devise Ease of Use. Descriptions should not only be a mechanismfor matching descriptions in that lan- easy to read and understand, but also easy to guage. This mechanism can then be used by middle write by the user. The language should support agents to efficiently select relevant agents for some the use of domain or commonontologies for spec- given tasks. ifying agents capabilities. 153 ¯ Application in the Web. One of the main ap- 2.2 Specification in LARKS plication domainsfor the language is the specifi- A specification in LARKSis a frame with the following cation of advertisements and requests of agents slot structure. on the Web. The language allows for automated exchange and processing of information among Context Contextof specification these agents. Types Declaration of used variable types Input Declaration of There are many program description languages, input variables like Z, to describe the functionalities of programs. Output Declaration of output variables These languages contain too muchdetail to be useful InConstraints Constraints on for the searching purpose. Also reading and writ- input variables ing specifications in these languages require sophis- 0utConstraints Constraints on ticated training. On the other hand, the interface output variables definition languages, like IDL and WIDL,go to the ConcDescriptions Ontological descriptions other extreme by completely omitting the functional of used words descriptions of the services. Only the input and out- TextDescription Textual Description of put information is provided. specification In AI, knowledge description languages like KIF The frame slot types have the following meaning. are meant to describe the knowledge instead of the actions of a service. The action representation for- ¯ Context: The context of the specification in the malisms like STRIPSare too restrictive to repre- local domain of the agent. sent complicated services. Some agent communica- tion languages like KQML(Finin et al. 1994) and ¯ Types: Optional definition of the data types FIPA ACL concentrate on the communication pro- used in the specification.. tocals (message types) between agents but leave the Input and Output: Input/output variable dec- content part of the language unspecified. larations for the specification. In addition to the In Internet computing, various description formats usual type declarations, there may also be con- are being proposed, notably the WIDLand the Re- cept attachments to disambiguate types of the source Description Framework (RDF). Although the same name. The concept itself is defined in the RDFalso aims at the interoperablity between Web concept description slot ConcDescriptions. applications, it is intended to be a basis for describ- ing metadata. RDFallowes different vendors to de- InConstraints and Ou~;Constraints: Logical scribe the properties and relations between resources constraints on input/output variables that ap- on the Web. That enables other programs, like Web pear in the input/output declaration part. The robots, to easily extract relevant information, and to constraints are described as Horn clauses. build a graph structure of the resources available on ConcDesriptions: Optional description of the the Web, without the need to give any specific infor- meaning of words used in the specification. The mation. However, the description does not describe description relies on concepts in a given local do- the functionalities of the Webservices. main ontology. Attachement of a concept C to a Since none of those languages satisfies our re- word w in any of the slots above is done in the quirements, we propose an ACDL, called LARKS form: w*C. That means