Matchmaking Among Heterogeneous Agents on the Internet*

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 every 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, communication 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 capability 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 simple, 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 communication 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 describing 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 that the concept C is the (Language for Advertisement and Request for ontological description of the word w. The con- KnowledgeSharing), that enables for advertising, re- cept C is included in the slot ConcDescriptions questing and matching agent capabilities. if not already sent to the matchmaker.

154 ¯ TextDescription: Optional, textual descrip- ReqAirMissions tion of the meaning of the specification as a re- Context Attack, Mission*AirMission quest for or advertisement of agent capabilities. Types Date -- In addition, the meaning of input and output (mm: Int, dd: Int, yy: Int), DeployedMission --- declaration, type and context part of the spec- ListOf(mType: String, ification may be described by attaching textual miD:String[lint) comments. Input sd: Date, ed: Date Output missions: Mission Every specification in LARKScan be interpreted as InConstraints sd <= ed. an advertisement as well as a request; the specifica- OutConstraints deployed(miD), tion’s role depends on the agent’s purpose for sending launchedAffer(mlD,sd), it to a matchmaker agent. Every LARKSspecification launchedBefore(mlD,ed). must be wrapped by the sending agent in an appro- ConcDescriptions AirMission = priate KQMLmessage 1 that indicates if the message {and Mission content is to be treated as a request or an advertise- (atleast 1 has-airplane) ment. (all has-airplane Airplane) (all has-MissionType aset(AWAC,CAP,DCA))) 2.3 Using Domain Knowledge in TextDescription capable of providing LARKS information on deployed air combat missions LARKSoffers the option to use application domain launched in a given time knowledge in any advertisement or request. This interval is done by using a local ontology for describing the meaning of a word in a LARKSspecification. Local ontologies can be formally defined using concept languages such as ITL. The main benefits of providing a local ontology 3 The Matchmaking Process are twofold: (1) the user can specify in more detail Using LARKS what’s being requested or advertised, and (2) the matchmaker agent is able to make automated 3.1 Different Types of Matching in inferences on these additional semantic descrip- LARKS tions while matching LARKSspecifications, thereby improving the overall quality of the matching process. Agent capability matching is the process of determining whether an advertisement registered in the Example 2.1: Specification in LARKS matchmaker matches a request. Before we go into the We did apply the matchmaking process using LARKSin details of the matchmaking process, we should clarify the application domain of air combat missions. As an the ways in which two specifications can match. example for specification consider the following request ’ReqAirMissions’. The request is to find an agent which * Exact Match The most accurate type of match- is capable to give information on deployed air combat ing is when both descriptions are equivalent, by missions launched in a given time interval. The domain being literally equal, equal when the variables ontology is supposed to be written in ITL. are renamed, or equal by logical inference. This type of matching is the most restrictive one. t Althoughthe current implementation supports agent mes- sages in KQML,LARKS is independent of any communication * Plug-In Match A less accurate but most useful language or set of performatives/speech acts. type of match is the plug-in match. In a plug-in

155 match, the advertised input types are not more 3.2 The Filtering Stages of the Match- constrained than the requested input types, and making Process the advertised output types are not less constrained than the requested output types. A ser- The matching engine of the matchmaker agent con- vice described by a plug-in advertisement for a tains five different filters: request will not demand more or more specific input parameters than the requester can supply, 1. Context matching, and will not return fewer or more general output parameters than the requester needs. Hence the 2. Profile comparison, requester submits a subset of its input parate- mers to get in return a superset of the output 3. Similarity matching, parameters it needs. Exact match is a special case of plug-in match, that is, wherever two de- 4. Signature matching, and scriptions are an exact match, they are also a plug-in match. 5. Constraint matching.

A simple example of a plug-in match is between The first three filters are meant for relaxed match- a request to sort a list of integers and an adver- ing, and the signature and constraint matching filter tisement of an agent that can sort both lists of are meant for plug-in matching 2. On the basis of integers or strings. This example is elaborated the given notions of matching we implemented four on in section 4. different modes of matching for the matchmaker: 1. Complete Matching Mode. All filters are considered. ¯ Relaxed Match The least accurate type of match is the relaxed match. A relaxed matching 2. Relaxed Matching Mode. The context, pro- process will not return advertised services that file, and similarity matchingis done. can be immediately used by the requester, but instead it returns the subset of advertisements 3. Profile Matching Mode. Only the context whosedistance from the request is less than some matching and comparison of profiles is per- supplied threshold. Thus the requester obtains a formed. survey of the kinds of similar advertised services that have been registered with the matchmaker. 4. Plug-In Matching Mode. In this mode, the matchmaker performs the signature and con- For a request describing a service to locate Com- straint matching only. paq computer dealers in a state, a relaxed match might return an advertisement describing a ser- Users may select any of these modes Or combina- vice that returns a dealer location and price tion of these filters on demand. For example, when given a Compaq computer model. efficiency is the major concern, a user might select only the context and profile filters. On the other hand, when a user or agent wants to find agents that Different users in different situations maywant to plug-in match, then the matchmaking process would employ different types of matches. Thus the match- be configured with signature and constraint filters. maker agent supports several kinds of filters, which Wewill nowdescribe each filter in more detail. have different criteria for determining if advertise- 2Thecomputational costs of these filters are in increasing ments and requests match. order,

156 3.2.1 Context Filter heuristics and the set of keywords in LARKSitself.

Any matching of two specifications has to be in an The similarity dps(Req, Ad) of a request Req and appropriate context. In LARKSto deal with restrict- an advertisement Ad under consideration is then cal- ing the advertisement matching space to those in the culated by : same domain as the request, each specification sup- plies a list of key words meant to describe the domain dps(Req, Ad)= Req * Ad of the service. [Req[ . [Ad[ Whencomparing two specifications it is assumed where Req ¯ Ad denotes the inner product of the that their domains are the same (or at least suffi- weighted keyword vectors. If the value dps(Req, Ad) ciently similar) as long as (1) the real-valued dis- exceeds a given threshold fl E R, the matching tances between the roots of these words do not exceed process continues with the following steps. a given threshold and (2) subsumption relations between the attached concepts of the most similar words are the same. The matching process only proceeds if 3.2.3 Similarity Filter both conditions hold. The profile filter has two drawbacks. First, it does not consider the structure of the description. That 3.2.2 Profile Filter meansthe filter, for example, is not able to differen- Although context matching is efficient, it does not tiate amonginput and output declarations of a spec- consider the whole specification itself. This is done ification. Second, profile comparisondoes not rely on with a profile filter that compares two LARKSspeci- the semantics of words in a document. Thus the fil- fications by using the TF-IDFtechnique (Salton and ter is not able to recognize that the word pair (Com- Wong1975) from the domain of information retrieval. puter, Notebook), for example, should have a closer Each specification in LARKSis treated as a doc- distance than the pair (Computer, Book). ument, and each word w in a document Req is Computation of similarity distance is a combina- weighted for that document in the following way. The tion of distance values as calculated for pairs of input number of times w occurs throughout all documents and output declarations, and input and output constraints. Each of these distance values is computed in the matchmaker’s advertisement database is called in terms of the distance between concepts and words the document frequency -- dr(w) -- of w. that occur in their respective specification section. Thus for a given document d, the relevance of d The values are computedat the time of advertisement for word w is proportional to the number of times w occurs in d -- w f(w, d) -- and inversely proportional submittal and stored in the matchmaker database. to dr(w). A weight h(w, d) for a word in a document Word distance is computed using the trigger-pair model (Rosenfield 1994). If two words are signifi- d out of a set D of documents denotes the signifi- cantly co-related, then they are considered trigger- cance of the classification of w for d, and is defined pairs, and the value of the co-relation is domainspe- as follows: cific. In the current implementation we use the Wall Street Journal corpus of one million word pairs to h(w, d) = wf(w, d). log(~D~(w)). compute the word distance. The distance computation between concepts is discussed in section 3.3. The weighted keyword representation wkv(d,V) of a document d contains the weight h(w, d) as 3.2.4 Signature and Constraint Filters element for every word w in a given dictionary V. Since most dictionaries provide a huge vocabulary, The similarity filter takes into consideration the se- we cut down the dimension of the vector by using mantics of individual words in the description. How- a fixed set of appropriate keywords determined by ever, it does not take the meaningof constraints in a

157 LARKSspecification into account. A more sophisti- logical constraints defined in the term of the concept cated semantical matching is needed. This is done in C~ logically imply those of the more general concept our matchmaking process by the signature and con- C. straint filters. The two filters are designed to work Anyconcept language is decidable if concept sub- together to look for a so-called plug-in match. sumption between any two concepts defined in that Signature matching checks if the signatures of input and output declarations match. It is performed language can be determined. The concept language ITL we use is NP-complete decidable. We use an by a set of subtype inference rules as well as concept incomplete inference algorithm for computing sub- subsumption testing (see (Sycara, Lu and Klusch sumption relations between concepts in ITL 3. For 1998) for details). the mechanism of subsumption computation refer to, In software engineering it is proven that a com- e.g., (Smolka and Schmidt-Schauss 1991). ponent description Desc2 ’plug-in matches’ another description Descl if ¯ Their signatures match. ¯ InConstraint of Descl implies the InConstraints 3.4 Computation of Distances Among of Desc2, i.e., for every clause C1 in the set of Concepts input constraints of Specl there is a clause C2 in the set of input constraint of Spec2 such that For matchmaking,the identification of relations other C1 ___o C2. than subsumption between concepts is very useful be- ¯ OutConstraints of Desct2 implies the OutCon- cause it promotes a deeper semantic understanding. straints of Descl, i.e., for every clause C2 in Moreover, since we’ve restricted the expressiveness the set of output constraints of Spec2 there is of the concept language ITL in order to boost per- a clause C1 in the set of output constraints of formance, we need some way to express additional Specl such that C2 _0 C1. associations between concepts. where ~0 denotes the 0-subsumption[12] relation be- To express these associations we use a weighted tween definite program clauses. associative network (AN), a semantic network with The main problem in performing plug-in matching directed edges between concept nodes. The type of is that the logical implication between constraints is edge between two concepts denotes their binary rela- not decidable for first order predicate logic, and not tion, and edges are labeled with a numerical weight even for an arbitrary set of Horn clauses. To make (interpreted as a fuzzy number). The weight indi- the matching process tractable and feasible we use cates the strength of belief in that relation, since its the 0-subsumption relation (Muggleton and De Raedt real world semantics may vary. 1994). In our implementation we created an associative network by using the concept subsumption hierarchy 3.3 Concept Subsumption Checking and additional associations set by the user. Distance between two concepts C, C’ in an AN is computed Concept subsumption relationships and concept dis- as the strength ofthe shortest path between C and tances are frequently used in the matching engine, C~ on the basis of triangular norms (see (Fankhauser especially in the similarity, signature, and constraint and Neuhold 1992) for details). filters. These relations are computedat the time each advertisement is submitted and stored in the Concept Database. ~ 3Using the well-known tradeoff, we compromise expressive- A concept C subsumes another concept C if the ness for tractability in our subsumption algorithm, which is extension of C~ is a subset of C. This meansthat the correct but incomplete.

158 4 Example of Matchmaking Using LARKS Similarity Matching Using the current auxiliary database for word distance values, similarity matching of constraints yields, for Consider the following simple specifications ’Inte- example: gerSort’ and ’GenericSort’, a request for an agent that sorts integer numbers, and an advertisement for le(length(xs),100)) null an agent that is capable of sorting real numbers and before(x,y,ys)+-ge(x,y) in(x,ys)+--in(x,xs) strings. The similarity of both specifications is computed as: Sim(IntegerSort, GenericSort)= 0.64. IntegerSort Context Sort Signature Matching Types Consider the signatures tx= (List0f Integer)and t2= Input xs: ListOfInteger; (List0f ReallString ). Following the subtype inference Output ys: List0f Integer; rules 9., 4., and 1., it holds that tl _st t2, but not vice InConstraints le(length(xs), 100). versa. OutConstraints before(x,y,ys) e--ge(x,y). in(x,ys) +--in(x,xs). Constraint Matching ConcDescript ions The advertisement ’GenericSort’ semantically plugs into TextDescript ion sorting of list of the request ’IntegerSort’, because the input constraints integer numbers of ’IntegerSort’ are 0-subsumed by those of ’Generic- GenericSort Sort’, and the output constraints of ’GenericSort’ are 0- Context Sorting subsumed by those of ’IntegerSort’. Please note that the Types reverse does not hold. Input xs: List0f Real [ String; Output ys: ListOf Real [ String; InConstraints OutConstraints before(x,y,ys) ~-ge(x,y). before(x,y, ys) ~--preceeds(x,y). in(x,ys) ~--in(x,xs). ConcDescriptions TextDescription sorting of list of real numbers or string i~ x Receive Request ,, 14atchmakerAgent Assume that the provider agent submits the advertisement ’GenericSort’ to the matchmaker, ~WordFreq DB~ and that later the requester submits the request ’IntegerSort’.

Context Matching Both words in the Context declaration parts are sufficiently similar since they share the same root. We have no referenced concepts to check for terminologically equity, thus the matching process proceeds with the following two faltering stages.

Comparison of Profiles According to the result of the TF-IDF procedure both Figure 2: The User Interface of the Matchmaker specifications are sufficiently similar. Agent.

159 Figure 2 shows the user interface of the imple- The constraints for both the user request and the re- mented matchmaker agent. To help visualize the source data are specified in terms of somegiven cen- matchmaking process, we devised a user interface tral ontology. It is the use of this commonvocabu- that traces the path of the advertisement result set lary that enables the dynamic matching of requests to for a request through the matchmaker’s filters. The the available resources. The advertisements specify filters can be configured by selecting the checkboxes agents’ capabilities in terms of one or moreontologies. beneath the desired filters -- disabled filters are The constraint matching is an intersection function darkened and bypassed -- or by pressing one of the between the user query and the data resource con- buttons for a predefined mode. As the result set straints. If the conjunction of all the user constraints passes from one filter to the next, the filter’s outline with all the resource constraints is satisfiable, then highlights, the number above the filter increments the resource contains data that are relevant to the as it considers an advertisement, and the number user request. above its output arrow increments as advertisements Broker and matchmaker agents can be seen as a successfully pass through the filter. Pushing the kind of so-called mediator agents among heteroge- buttons above each inter-filter arrow reveals the neous information systems (Vassalos and Papakon- result advertisement set for the preceding filter. stantinou 1997; Ambite and Knoblock 1997). Each local information system is ’wrapped’ by a wrapper agent, and their capabilities are described in two lev- els. The first is what they can provide, which is 5 Related Work usually described in the local data model and. local database schema. The second is what kind of queries Agent matchmaking has been actively studied since they can answer, which is usually a subset of SQL. the inception of software agent research. The earliest The set of queries a service can accept is described matchmakerwe are aware of is the ABSIfacilitator, using a grammar-like notation. Matching between which is based on the KQMLspecification and uses the query and the service is simple: it just decides the KIF as the content language. The KIF expression whether the query can be generated by this gram- is basically treated like Horn clauses. The~ matching mar. This area emphasizes the planning of database between the advertisement and request expressed in queries according to heterogeneous information sys- KIF is the simple unification with the equality pred- tems not providing complete SQL services. Those icate. systems are not designed to be searched for among The SHADE and COINS (Kuokka and Harrada a vast number of Internet resources. The description 1995) are matchmakers based on KQML.The content of capabilities and matching are not only studied in language of COINSallows for free text and its match- the agent community,but also in other related areas. ing algorithm utilizes the TF-IDFlike the profile filter. The context language of the SHADEmatch- maker consists of two parts, one is a subset of KIF, 5.1 Works Related with Capability the other is a structured logic representation called Description MAX.MAX use logic frames to declaratively store The following approaches provide solutions for the knowledge. SHADEuses a frame-like representation problem of capability and service description match- and matching relies on a Prolog-like unification pro- ing: cess. A more recent service broker-based information 1. Software specification techniques. system is InfoSleuth (Jacobs and Shea 1996; Nodine Agents are computer programs that have some 1998). The content language supported by InfoS- specific characteristics. There is numerous work leuth is KIF and the deductive database language on software specifications in formal methods, is LDL++,which has semantics similar to Prolog. like the model-oriented VDMand Z[14], or the

160 algebra-oriented Larch. Although these lan- and Cheng1995) the distance between similar specifi- guages are good at describing computer pro- cations is computed. This work is based on algebraic grams in a precise way, the specification usu- specification of computer programs. No concept de- ally contains too manydetails to be of interest scriptions and concept hierarchies are considered. to other agents. The complexity of these lan- Concerning Web resource search techniques, the guages prohibits effective semantic comparison work (Li and Danzig 1997) proposes a method between the specifications. Reading and writ- look for better search engines that mayprovide more ing these specifications also requires substantial relevant data for the user concerns, and ranks those training. search engines according to their relevance to a user’s query. They propose a directory of services to record 2. Action representation formalisms. descriptions for each information server. A user sends Agent capability can be seen as the actions that a query to a directory of services, which determines the agents perform. There are a number of ac- and ranks the servers that are relevant to the user’s tion representation formalisms in AI planning, request. Both the query and the server are described like the classical one, STRIPS.Action represen- using boolean expressions. The search method is tation formalisms are inadequate for our task based on the similarity measure between the two since they are propositional and do not involve boolean expressions. data types. 3. Concept languages for knowledge representation. 6 Conclusion There are various terminological knowledge representation languages. However, an ontology it- The Internet is an open system where heterogeneous self does not describe any capability. On the agents can appear and disappear dynamically. As the other hand, it provides auxiliary concepts to as- number of agents on the Internet increases, there is sist the specification of agent capabilities. a need to define middle agents to help agents locate 4. Database query capability description. other agents that provide requested services. In prior research we have identified a variety of middle agent The database query capability description tech- types, their protocols and their performance charac- nique in (Vassalos and Papakonstantinou 1997), teristics. Matchmaking is the process that brings was developed as an attempt to describe the in- requester and service provider agents together. A formation sources on the Internet, such that an provider agent advertises its know-howor capabili- automated integration of information would be ties to a middle agent, which stores the advertise- possible. In this approach the information source ments. An agent that desires a particular service is modeled as a database with restricted query- sends a service request to a middle agent, which sub- ing capabilities. sequently matches the request against its stored advertisements. The middle agent communicates the 5.2 Works Related to Service Re- results to the requester (the way this happens depends on the type of middle agent involved). trieval We have also defined protocols that allow more In software component search techniques, (Zaremski than one middle agent to maintain consistency in and Wing1995) defines several notions of matching, their advertisement databases. Since matchmaking including exact and plug-in matching, and formally is usually done dynamically and over large networks, proves the relationship between those matches. The it must be efficient. There is an obvious trade-off work of (Goguen et al. 1996) proposes to use a se- between the quality and efficiency of service match- quence of filters to search for software componentsto making on the Internet. increase the efficiency of the search process. In (Jen We have defined and implemented a language

161 called LARKSfor agent advertisements and requests, [7] Jha, S., Chalasani, P., Shehory, O., and Sycara, K. and a matchmaking process that uses LARKS. LARKS 1998. A Formal Treatment of Distributed Match- judiciously balances language expressiveness and ef- making. In Proceedings of the Second International ficiency in matching. The LARKSmatchmaking pro- conference on Autonomous Agents (Agents 98), Min- neapolis, MN. cess performs both syntactic and semantic matching, and in addition allows the specification of concepts [8] Jeng, J-J., and Cheng, B.H.C 1995. Specification (local ontologies) via ITL, a concept language. matching for software reuse: a foundation. In Pro- ceedings of the ACMSIGSOFT Symposium on Soft- The matching process uses five filters: context ware Reusability, ACMSoftware Engineering Note. matching, profile comparison, similarity matching, signature matching and constraint matching. Dif- [9] Kracker, M. 1992. A fuzzy concept network. In Pro- ceedings of IEEE International Conference on Fuzzy ferent degrees of partial matching can result from Systems, IEEE Computer Society Press. utilizing different combinations of these filters. The selection of filters to apply is under the control of [10] Kuokka, D., and Harrada, L., 1995. On using KQML the user (or the requester agent). for Matchmaking. In Proceedings of 3rd Intl. Conf. on Information and Knowledge Management CIh’M- 95, 239-45, AAAI/MITPress. Acknowledgement: We thank Davide Brugali, Li, S.H., and Danzig, P.B. 1997. Boolean Similarity Somesh Jha and Anandeep Pannu for their helpful [11] Measures for Resource Discovery. IEEE Transactions discussions in this project. on Knowledge and Data Engineering, 9(6). [12] Muggleton, S., and De Raedt, L. 1994. Inductive logic programming: theory and methods. Journal of References Logic Programming, 19(20):629-679. [13] Nodlne, M. 1998. The InfoSleuth Agent System. [1] Ambite, J.L., and Knoblock, C.A. 1997. Planning In M. Klusch and G. Weiss. eds. Proceedings of by Rewriting: Efficiently Generating High-Quality Second International Workshop on Cooperative In- Plans. In Proceedings of the Fourteenth National formaiton Agents CIA-98, Paris, France, Springer, Conference on Artificial Intelligence, Providence, RI. LNAI 1435:19-20. [2] Decker, K., Sycara, K., and Williamson, M. 1997. [14] Potter, B., Sinclair, J., and Till, D.. Introduction to Middle-Agents for the Internet. In Proceedings of Formal Specification and Z. Prentice-Hall Interna- 15th IJCAI Conference, pp. 578-583, Nagoya, Japan. tional Series in Computer Science. [3] Fankhauser, P., and Neuhold, E.J. 1992. Knowl- [15] Resource Description Framework (RDF) Schema edge based integration of heterogeneous databases. Specification. ht tp://www.w3.org/TR/WD-rdf- In Proceedings of IFIP Conference DS-5 Semantics schema/. of Interoperable Database Systems, Lorne, Victoria, [16] Rosen_field, R. 1994. Adaptive statistic language Australia, 1992. model. PhDdiss., Carnegie Mellon University, Pitts- [4] Finin, T., Fritzson, R., McKay, D., and McEntire, burgh, USA. R. 1994. KQMLas an Agent Communication Lan- [17] Salton, G., and Wont, A. 1975. A vector space guage. In Proceedings 3rd International Conference model for automatic indexing. Communications of on Information and Knowledge Management CIKM- the ACM, 18:613-620. 94, ACMPress. [18] Sycara, K., Lu, J., and Klusch, M. 1998. Inter- [5] Goguen, J., Nguyen, D., Meseguer, J., Luqi, Zhang, operability among Heterogeneous Software Agents D., and Berzins, V. 1996. Software component on the Internet. Technical Report CMU-RI-TR-98- search. Journal of Systems Integration, 6:93-134. 22, Robotics Institute, Carnegie Mellon University, [6] Jacobs, N., and Shea, R. 1996. The role of Java in In- Pittsburgh PA (USA). foSleuth: Agent-based exploitation of heterogeneous [19] Sycara, K., Decker, K., Pannu, A., Williamson, M., information ressources. In Proceedings of Intranet-96 and Zeng, D. 1996. Distributed Intelligent Agents. Java Developers Conference. IEEE Expert, pp. 36-46.

162 [20] Smolka, G., and Schmidt-Schauss, M. 1991. Attribu- tive concept description with complements. A I Jour- nal, 48. [21] Wickler, G. 1998. Using Expressive and Flex- ible Action Representations to Reason about Capabilities for Intelligent Agent Cooperation. ht tp://www.dai.ed.ac.uk/students/gw/phd/story.html [22] Vassalos, V., Papakonstantinou, Y. 1997. Describ- ing and Using Query Capabilities of Heterogeneous Sources. In Proceedings of International Conference on Very Large Database Systems VLDB-97. available at http’//www-cse.ucsd.edu/yannis/papers/ [23] Zaremski, A.M., and Wing, J.M. 1995. Specifica- tion matching of software components. Technical Re- port CMU-CS-95-127, School of Computer Science, Carnegie Mellon University, Pittsburgh PA (USA).

163