Matchmaking among Heterogeneous Agents on the Internet*

Katia Sycara, Matthias Klusch, Seth WidoffThe Robotics Institute, Carnegie Mellon University, Pittsburgh, USA.

{katia, klusch, swidoff}@cs.cmu.edu

Jianguo LuComputer Science Department, University of Toronto, CA.

jglu@cs.toronto.edu

Abstract

The Internet not only provides data for users to browse,but also databases to query, and software agents to run.Due to the exponential increase of deployed agents on theInternet, automating the search and selection of relevantagents is essential for both users and collaboration amongdifferent software agents. This paper first describes theagent capability description language LARKS. Then wewill discuss the matchmaking process using LARKS andgive a complete working scenario. The paper concludeswith comparing our language and the matchmaking pro-cess with related works. We have implemented LARKSand the associated powerful matchmaking process, andare currently incorporating it within our RETSINA multi-agent framework (Sycara et al. 1996).

1 Introduction

The Internet not only provides data for users tobrowse in the Web, but also heterogeneous databasesto query, and software agents to run. Due to the ex-ponential increase of deployed agents on the Internet,automating the searching and selection of relevantagents is essential for both users and the softwareagent society in several ways. Firstly, novice users inCyberspace may have no idea where to find a service,and what agents are available for performing a task.

*This research has been sponsored in part by Office of NavalResearch grant N-00014-96-16-1-1222.

Secondly, even experienced users can’t be aware of ev-ery change on the Internet. Relevant agents may ap-pear and disappear over time. Thirdly, as the numberand sophistication of agents on the Internet increase,there is an obvious need for standardized, meaning-ful communication among agents to enable them toperform collaborative task execution.

To facilitate the searching and interoperationbetween agents on the Internet, we proposedthe RETSINA multi-agent infrastructure framework(Sycara et al. 1996). In this framework, distinguished two general agent categories: serviceproviders and service requester agents. Serviceproviders provide some type of service, such as find-ing information, or performing some particular do-main specific problem solving (e.g., number sorting).Requester agents need provider agents to performsome service for them. Since the Internet is an openenvironment where information sources, communica-tion links, and agents themselves may appear and dis-appear unpredictably, there is a need for some meansto help requester agents find providers. Agents thathelp locate other agents are called middle agents.

We have identified different types of middle agentson the Internet, such as matchmakers (yellow pageservices), brokers, billboards, etc., and experimen-tally evaluated different protocols for interoperationbetween providers, requesters, and various types ofmiddle agents (Decker, Sycara and Williamson 1997).We have also developed protocols for distributedmatchmaking (Jha et al. 1998). Matchmaking is the

152

From: AAAI Technical Report SS-99-03. Compilation copyright © 1999, AAAI (www.aaai.org). All rights reserved.

Matchmaker Agent x

M.t° n,-- ~K ~ AuxiliaryDB

Rcsnlt-of’MatchinV/ ]~--.// ~pablg~D~cdptions

Requester Agent P~" in, LARK%I \ ov,dorAgent,

LAR~ocol I’m mderAgentLAR tocol v’ n ConceptDB 1for providing"~A L"!~ "" J

~~ the service

~~ISonPr°cessRequest’Local IS ] C~ce~p~B n

Figure 1: Matchmaking using LARKS: An Overview

process of finding an appropriate provider througha middle agent, and has the following general form(Figure 1):

¯ Provider agents advertise their capabilities tomiddle agents.

¯ Middle agents store these advertisements.

¯ A requester asks some middle agent whether itknows of providers with desired capabilities.

¯ The middle agent matches the request againstthe stored advertisements and returns the result,a subset of the stored advertisements.

While this process at first glance seems very sim-ple, it is complicated by the fact that providers andrequesters are usually heterogeneous and incapableof understanding each other. This difficulty givesrise to the need for a common language for describ-ing the capabilities and requests of software agentsin a convenient way. In addition, one has to devisea mechanism for matching descriptions in that lan-guage. This mechanism can then be used by middleagents to efficiently select relevant agents for somegiven tasks.

In the following, we first describe the agent capa-bility description language, LARKS. Then we will dis-cuss the matchmaking process using LARKS and givea complete working scenario. The paper concludeswith comparing our language and the matchmakingprocess with related works. We have implementedLARKS and the assQciated powerful matchmakingprocess, and are currently incorporating it withinour RETSINA multi-agent infrastructure framework(Sycara et al. 1996).

2 The Agent Capability De-scription Language LARKS

2.1 Desiderata for an Agent Capabil-

ity Description Language

There is an obvious need to describe agent capabili-ties in a common language before any advertisement,request, or even matchmaking among the agents cantake place. In fact, the formal description of capa-bilities is one of the difficult problems in the area ofsoftware engineering and AI. Some of the main de-sired features of such a agent capability descriptionlanguage (ACDL) are the following:

Expressiveness The language should be ex-pressive enough to represent not only data andknowledge, but also the meaning of programcode. Agent capabilities should be described atan abstract rather than implementation level.Most existing agents should be distinguishableby their descriptions in this language.

Inferences. Inferences on descriptions writtenin this language should be supported. Auto-mated reasoning and comparison on the descrip-tions should be possible and efficient.

Ease of Use. Descriptions should not only beeasy to read and understand, but also easy towrite by the user. The language should supportthe use of domain or common ontologies for spec-ifying agents capabilities.

153

¯ Application in the Web. One of the main ap-plication domains for the language is the specifi-cation of advertisements and requests of agentson the Web. The language allows for automatedexchange and processing of information amongthese agents.

There are many program description languages,like Z, to describe the functionalities of programs.These languages contain too much detail to be usefulfor the searching purpose. Also reading and writ-ing specifications in these languages require sophis-ticated training. On the other hand, the interfacedefinition languages, like IDL and WIDL, go to theother extreme by completely omitting the functionaldescriptions of the services. Only the input and out-put information is provided.

In AI, knowledge description languages like KIFare meant to describe the knowledge instead of theactions of a service. The action representation for-malisms like STRIPS are too restrictive to repre-sent complicated services. Some agent communica-tion languages like KQML (Finin et al. 1994) andFIPA ACL concentrate on the communication pro-tocals (message types) between agents but leave thecontent part of the language unspecified.

In Internet computing, various description formatsare being proposed, notably the WIDL and the Re-source Description Framework (RDF). Although theRDF also aims at the interoperablity between Webapplications, it is intended to be a basis for describ-ing metadata. RDF allowes different vendors to de-scribe the properties and relations between resourceson the Web. That enables other programs, like Webrobots, to easily extract relevant information, and tobuild a graph structure of the resources available onthe Web, without the need to give any specific infor-mation. However, the description does not describethe functionalities of the Web services.

Since none of those languages satisfies our re-quirements, we propose an ACDL, called LARKS(Language for Advertisement and Request forKnowledge Sharing), that enables for advertising, re-questing and matching agent capabilities.

2.2 Specification in LARKS

A specification in LARKS is a frame with the followingslot structure.

Context Context of specificationTypes Declaration of used

variable typesInput Declaration of

input variablesOutput Declaration of

output variablesInConstraints Constraints on

input variables0utConstraints Constraints on

output variablesConcDescriptions Ontological descriptions

of used wordsTextDescription Textual Description of

specification

The frame slot types have the following meaning.

¯ Context: The context of the specification in thelocal domain of the agent.

¯ Types: Optional definition of the data typesused in the specification..

Input and Output: Input/output variable dec-larations for the specification. In addition to theusual type declarations, there may also be con-cept attachments to disambiguate types of thesame name. The concept itself is defined in theconcept description slot ConcDescriptions.

InConstraints and Ou~;Constraints: Logicalconstraints on input/output variables that ap-pear in the input/output declaration part. Theconstraints are described as Horn clauses.

ConcDesriptions: Optional description of themeaning of words used in the specification. Thedescription relies on concepts in a given local do-main ontology. Attachement of a concept C to aword w in any of the slots above is done in theform: w*C. That means that the concept C is theontological description of the word w. The con-cept C is included in the slot ConcDescriptionsif not already sent to the matchmaker.

154

¯ TextDescription: Optional, textual descrip-tion of the meaning of the specification as a re-quest for or advertisement of agent capabilities.In addition, the meaning of input and outputdeclaration, type and context part of the spec-ification may be described by attaching textualcomments.

Every specification in LARKS can be interpreted asan advertisement as well as a request; the specifica-tion’s role depends on the agent’s purpose for sendingit to a matchmaker agent. Every LARKS specificationmust be wrapped by the sending agent in an appro-priate KQML message1 that indicates if the messagecontent is to be treated as a request or an advertise-

ment.

2.3 Using Domain Knowledge inLARKS

LARKS offers the option to use application domainknowledge in any advertisement or request. Thisis done by using a local ontology for describing themeaning of a word in a LARKS specification. Localontologies can be formally defined using concept lan-

guages such as ITL.The main benefits of providing a local ontology

are twofold: (1) the user can specify in more detailwhat’s being requested or advertised, and (2) thematchmaker agent is able to make automatedinferences on these additional semantic descrip-tions while matching LARKS specifications, therebyimproving the overall quality of the matching process.

Example 2.1: Specification in LARKS

We did apply the matchmaking process using LARKS inthe application domain of air combat missions. As anexample for specification consider the following request’ReqAirMissions’. The request is to find an agent whichis capable to give information on deployed air combatmissions launched in a given time interval. The domainontology is supposed to be written in ITL.

t Although the current implementation supports agent mes-sages in KQML, LARKS is independent of any communicationlanguage or set of performatives/speech acts.

ReqAirMissions

Context Attack, Mission*AirMissionTypes Date --

(mm: Int, dd: Int, yy: Int),DeployedMission ---ListOf(mType: String,miD:String[lint)

Input sd: Date, ed: DateOutput missions: MissionInConstraints sd <= ed.OutConstraints deployed(miD),

launchedAffer(mlD,sd),launchedBefore(mlD,ed).

ConcDescriptions AirMission ={and Mission(atleast 1 has-airplane)(all has-airplane Airplane)(all has-MissionTypeaset(AWAC,CAP,DCA)))

TextDescription capable of providinginformation ondeployed air combat missionslaunched in a given timeinterval

3 The Matchmaking ProcessUsing LARKS

3.1 Different Types of Matching inLARKS

Agent capability matching is the process of deter-mining whether an advertisement registered in thematchmaker matches a request. Before we go into thedetails of the matchmaking process, we should clarifythe ways in which two specifications can match.

* Exact Match The most accurate type of match-ing is when both descriptions are equivalent, bybeing literally equal, equal when the variablesare renamed, or equal by logical inference. Thistype of matching is the most restrictive one.

* Plug-In Match A less accurate but most usefultype of match is the plug-in match. In a plug-in

155

match, the advertised input types are not moreconstrained than the requested input types, andthe advertised output types are not less con-strained than the requested output types. A ser-vice described by a plug-in advertisement for arequest will not demand more or more specificinput parameters than the requester can supply,and will not return fewer or more general outputparameters than the requester needs. Hence therequester submits a subset of its input parate-mers to get in return a superset of the outputparameters it needs. Exact match is a specialcase of plug-in match, that is, wherever two de-scriptions are an exact match, they are also aplug-in match.

A simple example of a plug-in match is betweena request to sort a list of integers and an adver-tisement of an agent that can sort both lists ofintegers or strings. This example is elaboratedon in section 4.

3.2 The Filtering Stages of the Match-making Process

The matching engine of the matchmaker agent con-tains five different filters:

1. Context matching,

2. Profile comparison,

3. Similarity matching,

4. Signature matching, and

5. Constraint matching.

The first three filters are meant for relaxed match-ing, and the signature and constraint matching filterare meant for plug-in matching 2. On the basis ofthe given notions of matching we implemented fourdifferent modes of matching for the matchmaker:

1. Complete Matching Mode. All filters areconsidered.

¯ Relaxed Match The least accurate type ofmatch is the relaxed match. A relaxed matchingprocess will not return advertised services thatcan be immediately used by the requester, butinstead it returns the subset of advertisements 3.whose distance from the request is less than somesupplied threshold. Thus the requester obtains asurvey of the kinds of similar advertised servicesthat have been registered with the matchmaker. 4.

For a request describing a service to locate Com-paq computer dealers in a state, a relaxed matchmight return an advertisement describing a ser-vice that returns a dealer location and pricegiven a Compaq computer model.

Different users in different situations may want toemploy different types of matches. Thus the match-maker agent supports several kinds of filters, whichhave different criteria for determining if advertise-ments and requests match.

2. Relaxed Matching Mode. The context, pro-file, and similarity matching is done.

Profile Matching Mode. Only the contextmatching and comparison of profiles is per-formed.

Plug-In Matching Mode. In this mode, thematchmaker performs the signature and con-straint matching only.

Users may select any of these modes Or combina-tion of these filters on demand. For example, whenefficiency is the major concern, a user might selectonly the context and profile filters. On the otherhand, when a user or agent wants to find agents thatplug-in match, then the matchmaking process wouldbe configured with signature and constraint filters.We will now describe each filter in more detail.

2The computational costs of these filters are in increasingorder,

156

3.2.1 Context Filter

Any matching of two specifications has to be in anappropriate context. In LARKS to deal with restrict-ing the advertisement matching space to those in thesame domain as the request, each specification sup-plies a list of key words meant to describe the domainof the service.

When comparing two specifications it is assumedthat their domains are the same (or at least suffi-ciently similar) as long as (1) the real-valued dis-tances between the roots of these words do not exceeda given threshold and (2) subsumption relations be-tween the attached concepts of the most similar wordsare the same. The matching process only proceeds ifboth conditions hold.

3.2.2 Profile Filter

Although context matching is efficient, it does notconsider the whole specification itself. This is donewith a profile filter that compares two LARKS speci-fications by using the TF-IDF technique (Salton andWong 1975) from the domain of information retrieval.

Each specification in LARKS is treated as a doc-ument, and each word w in a document Req isweighted for that document in the following way. Thenumber of times w occurs throughout all documentsin the matchmaker’s advertisement database is calledthe document frequency -- dr(w) -- of w.

Thus for a given document d, the relevance of dfor word w is proportional to the number of times woccurs in d -- w f(w, d) -- and inversely proportionalto dr(w). A weight h(w, d) for a word in a documentd out of a set D of documents denotes the signifi-cance of the classification of w for d, and is definedas follows:

h(w, d) = wf(w, d). log(~D~(w)).

The weighted keyword representation wkv(d,V)of a document d contains the weight h(w, d) as element for every word w in a given dictionary V.Since most dictionaries provide a huge vocabulary,we cut down the dimension of the vector by usinga fixed set of appropriate keywords determined by

heuristics and the set of keywords in LARKS itself.

The similarity dps(Req, Ad) of a request Req andan advertisement Ad under consideration is then cal-culated by :

dps(Req, Ad)= Req * Ad[Req[ . [Ad[

where Req ̄ Ad denotes the inner product of theweighted keyword vectors. If the value dps(Req, Ad)exceeds a given threshold fl E R, the matchingprocess continues with the following steps.

3.2.3 Similarity Filter

The profile filter has two drawbacks. First, it doesnot consider the structure of the description. Thatmeans the filter, for example, is not able to differen-tiate among input and output declarations of a spec-ification. Second, profile comparison does not rely onthe semantics of words in a document. Thus the fil-ter is not able to recognize that the word pair (Com-puter, Notebook), for example, should have a closerdistance than the pair (Computer, Book).

Computation of similarity distance is a combina-tion of distance values as calculated for pairs of inputand output declarations, and input and output con-straints. Each of these distance values is computedin terms of the distance between concepts and wordsthat occur in their respective specification section.The values are computed at the time of advertisementsubmittal and stored in the matchmaker database.Word distance is computed using the trigger-pairmodel (Rosenfield 1994). If two words are signifi-cantly co-related, then they are considered trigger-pairs, and the value of the co-relation is domain spe-cific. In the current implementation we use the WallStreet Journal corpus of one million word pairs tocompute the word distance. The distance computa-tion between concepts is discussed in section 3.3.

3.2.4 Signature and Constraint Filters

The similarity filter takes into consideration the se-mantics of individual words in the description. How-ever, it does not take the meaning of constraints in a

157

LARKS specification into account. A more sophisti-cated semantical matching is needed. This is done inour matchmaking process by the signature and con-straint filters. The two filters are designed to worktogether to look for a so-called plug-in match.

Signature matching checks if the signatures of in-put and output declarations match. It is performedby a set of subtype inference rules as well as conceptsubsumption testing (see (Sycara, Lu and Klusch1998) for details).

In software engineering it is proven that a com-ponent description Desc2 ’plug-in matches’ anotherdescription Descl if

¯ Their signatures match.

¯ InConstraint of Descl implies the InConstraintsof Desc2, i.e., for every clause C1 in the set ofinput constraints of Specl there is a clause C2in the set of input constraint of Spec2 such thatC1 ___o C2.

¯ OutConstraints of Desct2 implies the OutCon-straints of Descl, i.e., for every clause C2 inthe set of output constraints of Spec2 there isa clause C1 in the set of output constraints ofSpecl such that C2 _0 C1.

where ~0 denotes the 0-subsumption[12] relation be-tween definite program clauses.

The main problem in performing plug-in matchingis that the logical implication between constraints isnot decidable for first order predicate logic, and noteven for an arbitrary set of Horn clauses. To makethe matching process tractable and feasible we usethe 0-subsumption relation (Muggleton and De Raedt1994).

3.3 Concept Subsumption Checking

Concept subsumption relationships and concept dis-tances are frequently used in the matching engine,especially in the similarity, signature, and constraintfilters. These relations are computed at the time eachadvertisement is submitted and stored in the ConceptDatabase.

A concept C subsumes another concept C~ if theextension of C~ is a subset of C. This means that the

logical constraints defined in the term of the conceptC~ logically imply those of the more general concept

C.

Any concept language is decidable if concept sub-sumption between any two concepts defined in thatlanguage can be determined. The concept languageITL we use is NP-complete decidable. We use anincomplete inference algorithm for computing sub-sumption relations between concepts in ITL 3. Forthe mechanism of subsumption computation refer to,e.g., (Smolka and Schmidt-Schauss 1991).

3.4 Computation of Distances Among

Concepts

For matchmaking, the identification of relations otherthan subsumption between concepts is very useful be-cause it promotes a deeper semantic understanding.Moreover, since we’ve restricted the expressivenessof the concept language ITL in order to boost per-formance, we need some way to express additionalassociations between concepts.

To express these associations we use a weightedassociative network (AN), a semantic network withdirected edges between concept nodes. The type ofedge between two concepts denotes their binary rela-tion, and edges are labeled with a numerical weight(interpreted as a fuzzy number). The weight indi-cates the strength of belief in that relation, since itsreal world semantics may vary.

In our implementation we created an associativenetwork by using the concept subsumption hierarchyand additional associations set by the user. Distancebetween two concepts C, C’ in an AN is computedas the strength ofthe shortest path between C andC~ on the basis of triangular norms (see (Fankhauserand Neuhold 1992) for details).

3Using the well-known tradeoff, we compromise expressive-ness for tractability in our subsumption algorithm, which iscorrect but incomplete.

158

4 Example ofUsing LARKS

Matchmaking

Consider the following simple specifications ’Inte-gerSort’ and ’GenericSort’, a request for an agentthat sorts integer numbers, and an advertisement foran agent that is capable of sorting real numbers andstrings.

IntegerSort

Context SortTypesInput xs: ListOf Integer;Output ys: List0f Integer;InConstraints le(length(xs), 100).OutConstraints before(x,y,ys) e--ge(x,y).

in(x,ys) +--in(x,xs).ConcDescript ionsTextDescript ion sorting of list of

integer numbers

GenericSort

Context SortingTypesInput xs: List0f Real [ String;Output ys: ListOf Real [ String;InConstraintsOutConstraints before(x,y,ys) ~-ge(x,y).

before(x,y, ys) ~--preceeds(x,y).in(x,ys) ~--in(x,xs).

ConcDescriptionsTextDescription sorting of list of

real numbers or string

Assume that the provider agent submits the

advertisement ’GenericSort’ to the matchmaker,and that later the requester submits the request

’IntegerSort’.

Context MatchingBoth words in the Context declaration parts are suf-ficiently similar since they share the same root. Wehave no referenced concepts to check for terminologicallyequity, thus the matching process proceeds with thefollowing two faltering stages.

Comparison of ProfilesAccording to the result of the TF-IDF procedure bothspecifications are sufficiently similar.

Similarity MatchingUsing the current auxiliary database for word distancevalues, similarity matching of constraints yields, forexample:

le(length(xs),100)) null before(x,y,ys)+-ge(x,y) in(x,ys)+--in(x,xs) The similarity of both specifications is computed as:

Sim(IntegerSort, GenericSort) = 0.64.

Signature MatchingConsider the signatures tx= (List0f Integer)and t2=(List0f ReallString ). Following the subtype inferencerules 9., 4., and 1., it holds that tl _st t2, but not viceversa.

Constraint Matching

The advertisement ’GenericSort’ semantically plugs intothe request ’IntegerSort’, because the input constraintsof ’IntegerSort’ are 0-subsumed by those of ’Generic-Sort’, and the output constraints of ’GenericSort’ are 0-subsumed by those of ’IntegerSort’. Please note that thereverse does not hold.

i~ x Receive Request,, 14atchmaker Agent

~Word Freq DB~

Figure 2: The User Interface of the MatchmakerAgent.

159

Figure 2 shows the user interface of the imple-mented matchmaker agent. To help visualize thematchmaking process, we devised a user interfacethat traces the path of the advertisement result setfor a request through the matchmaker’s filters. Thefilters can be configured by selecting the checkboxesbeneath the desired filters -- disabled filters aredarkened and bypassed -- or by pressing one of thebuttons for a predefined mode. As the result setpasses from one filter to the next, the filter’s outlinehighlights, the number above the filter incrementsas it considers an advertisement, and the numberabove its output arrow increments as advertisementssuccessfully pass through the filter. Pushing thebuttons above each inter-filter arrow reveals theresult advertisement set for the preceding filter.

5 Related Work

Agent matchmaking has been actively studied sincethe inception of software agent research. The earliestmatchmaker we are aware of is the ABSI facilitator,which is based on the KQML specification and usesthe KIF as the content language. The KIF expressionis basically treated like Horn clauses. The~ matchingbetween the advertisement and request expressed inKIF is the simple unification with the equality pred-icate.

The SHADE and COINS (Kuokka and Harrada1995) are matchmakers based on KQML. The contentlanguage of COINS allows for free text and its match-ing algorithm utilizes the TF-IDF like the profile fil-ter. The context language of the SHADE match-maker consists of two parts, one is a subset of KIF,the other is a structured logic representation calledMAX. MAX use logic frames to declaratively storeknowledge. SHADE uses a frame-like representationand matching relies on a Prolog-like unification pro-cess.

A more recent service broker-based informationsystem is InfoSleuth (Jacobs and Shea 1996; Nodine1998). The content language supported by InfoS-leuth is KIF and the deductive database languageis LDL++, which has semantics similar to Prolog.

The constraints for both the user request and the re-source data are specified in terms of some given cen-tral ontology. It is the use of this common vocabu-lary that enables the dynamic matching of requests tothe available resources. The advertisements specifyagents’ capabilities in terms of one or more ontologies.The constraint matching is an intersection functionbetween the user query and the data resource con-straints. If the conjunction of all the user constraintswith all the resource constraints is satisfiable, thenthe resource contains data that are relevant to theuser request.

Broker and matchmaker agents can be seen as akind of so-called mediator agents among heteroge-neous information systems (Vassalos and Papakon-stantinou 1997; Ambite and Knoblock 1997). Eachlocal information system is ’wrapped’ by a wrapperagent, and their capabilities are described in two lev-els. The first is what they can provide, which isusually described in the local data model and. localdatabase schema. The second is what kind of queriesthey can answer, which is usually a subset of SQL.The set of queries a service can accept is describedusing a grammar-like notation. Matching betweenthe query and the service is simple: it just decideswhether the query can be generated by this gram-mar. This area emphasizes the planning of databasequeries according to heterogeneous information sys-tems not providing complete SQL services. Thosesystems are not designed to be searched for amonga vast number of Internet resources. The descriptionof capabilities and matching are not only studied inthe agent community, but also in other related areas.

5.1 Works Related with CapabilityDescription

The following approaches provide solutions for theproblem of capability and service description match-ing:

1. Software specification techniques.Agents are computer programs that have somespecific characteristics. There is numerous workon software specifications in formal methods,like the model-oriented VDM and Z[14], or the

160

algebra-oriented Larch. Although these lan-guages are good at describing computer pro-grams in a precise way, the specification usu-ally contains too many details to be of interestto other agents. The complexity of these lan-guages prohibits effective semantic comparisonbetween the specifications. Reading and writ-ing these specifications also requires substantialtraining.

2. Action representation formalisms.Agent capability can be seen as the actions thatthe agents perform. There are a number of ac-tion representation formalisms in AI planning,like the classical one, STRIPS. Action represen-tation formalisms are inadequate for our tasksince they are propositional and do not involvedata types.

3. Concept languages for knowledge representation.There are various terminological knowledge rep-resentation languages. However, an ontology it-self does not describe any capability. On theother hand, it provides auxiliary concepts to as-sist the specification of agent capabilities.

4. Database query capability description.

The database query capability description tech-nique in (Vassalos and Papakonstantinou 1997),was developed as an attempt to describe the in-formation sources on the Internet, such that anautomated integration of information would bepossible. In this approach the information sourceis modeled as a database with restricted query-ing capabilities.

5.2 Works Related to Service Re-

trieval

In software component search techniques, (Zaremskiand Wing 1995) defines several notions of matching,including exact and plug-in matching, and formallyproves the relationship between those matches. Thework of (Goguen et al. 1996) proposes to use a se-quence of filters to search for software components toincrease the efficiency of the search process. In (Jen

and Cheng 1995) the distance between similar specifi-cations is computed. This work is based on algebraicspecification of computer programs. No concept de-scriptions and concept hierarchies are considered.

Concerning Web resource search techniques, thework (Li and Danzig 1997) proposes a method look for better search engines that may provide morerelevant data for the user concerns, and ranks thosesearch engines according to their relevance to a user’squery. They propose a directory of services to recorddescriptions for each information server. A user sendsa query to a directory of services, which determinesand ranks the servers that are relevant to the user’srequest. Both the query and the server are describedusing boolean expressions. The search method isbased on the similarity measure between the twoboolean expressions.

6 Conclusion

The Internet is an open system where heterogeneousagents can appear and disappear dynamically. As thenumber of agents on the Internet increases, there isa need to define middle agents to help agents locateother agents that provide requested services. In priorresearch we have identified a variety of middle agenttypes, their protocols and their performance charac-teristics. Matchmaking is the process that bringsrequester and service provider agents together. Aprovider agent advertises its know-how or capabili-ties to a middle agent, which stores the advertise-ments. An agent that desires a particular servicesends a service request to a middle agent, which sub-sequently matches the request against its stored ad-vertisements. The middle agent communicates theresults to the requester (the way this happens de-pends on the type of middle agent involved).

We have also defined protocols that allow morethan one middle agent to maintain consistency intheir advertisement databases. Since matchmakingis usually done dynamically and over large networks,it must be efficient. There is an obvious trade-offbetween the quality and efficiency of service match-making on the Internet.

We have defined and implemented a language

161

called LARKS for agent advertisements and requests,and a matchmaking process that uses LARKS. LARKS

judiciously balances language expressiveness and ef-ficiency in matching. The LARKS matchmaking pro-cess performs both syntactic and semantic matching,and in addition allows the specification of concepts(local ontologies) via ITL, a concept language.

The matching process uses five filters: contextmatching, profile comparison, similarity matching,signature matching and constraint matching. Dif-ferent degrees of partial matching can result fromutilizing different combinations of these filters. Theselection of filters to apply is under the control ofthe user (or the requester agent).

Acknowledgement: We thank Davide Brugali,Somesh Jha and Anandeep Pannu for their helpfuldiscussions in this project.

References[1] Ambite, J.L., and Knoblock, C.A. 1997. Planning

by Rewriting: Efficiently Generating High-QualityPlans. In Proceedings of the Fourteenth NationalConference on Artificial Intelligence, Providence, RI.

[2] Decker, K., Sycara, K., and Williamson, M. 1997.Middle-Agents for the Internet. In Proceedings of15th IJCAI Conference, pp. 578-583, Nagoya, Japan.

[3] Fankhauser, P., and Neuhold, E.J. 1992. Knowl-edge based integration of heterogeneous databases.In Proceedings of IFIP Conference DS-5 Semanticsof Interoperable Database Systems, Lorne, Victoria,Australia, 1992.

[4] Finin, T., Fritzson, R., McKay, D., and McEntire,R. 1994. KQML as an Agent Communication Lan-guage. In Proceedings 3rd International Conferenceon Information and Knowledge Management CIKM-94, ACM Press.

[5] Goguen, J., Nguyen, D., Meseguer, J., Luqi, Zhang,D., and Berzins, V. 1996. Software componentsearch. Journal of Systems Integration, 6:93-134.

[6] Jacobs, N., and Shea, R. 1996. The role of Java in In-foSleuth: Agent-based exploitation of heterogeneousinformation ressources. In Proceedings of Intranet-96Java Developers Conference.

[7] Jha, S., Chalasani, P., Shehory, O., and Sycara, K.1998. A Formal Treatment of Distributed Match-making. In Proceedings of the Second Internationalconference on Autonomous Agents (Agents 98), Min-neapolis, MN.

[8] Jeng, J-J., and Cheng, B.H.C 1995. Specificationmatching for software reuse: a foundation. In Pro-ceedings of the ACM SIGSOFT Symposium on Soft-ware Reusability, ACM Software Engineering Note.

[9] Kracker, M. 1992. A fuzzy concept network. In Pro-ceedings of IEEE International Conference on FuzzySystems, IEEE Computer Society Press.

[10] Kuokka, D., and Harrada, L., 1995. On using KQMLfor Matchmaking. In Proceedings of 3rd Intl. Conf.on Information and Knowledge Management CIh’M-95, 239-45, AAAI/MIT Press.

[11] Li, S.H., and Danzig, P.B. 1997. Boolean SimilarityMeasures for Resource Discovery. IEEE Transactionson Knowledge and Data Engineering, 9(6).

[12] Muggleton, S., and De Raedt, L. 1994. Inductivelogic programming: theory and methods. Journal ofLogic Programming, 19(20):629-679.

[13] Nodlne, M. 1998. The InfoSleuth Agent System.In M. Klusch and G. Weiss. eds. Proceedings ofSecond International Workshop on Cooperative In-formaiton Agents CIA-98, Paris, France, Springer,LNAI 1435:19-20.

[14] Potter, B., Sinclair, J., and Till, D.. Introduction toFormal Specification and Z. Prentice-Hall Interna-tional Series in Computer Science.

[15] Resource Description Framework (RDF) SchemaSpecification. ht tp://www.w3.org/TR/WD-rdf-schema/.

[16] Rosen_field, R. 1994. Adaptive statistic languagemodel. PhD diss., Carnegie Mellon University, Pitts-burgh, USA.

[17] Salton, G., and Wont, A. 1975. A vector spacemodel for automatic indexing. Communications ofthe ACM, 18:613-620.

[18] Sycara, K., Lu, J., and Klusch, M. 1998. Inter-operability among Heterogeneous Software Agentson the Internet. Technical Report CMU-RI-TR-98-22, Robotics Institute, Carnegie Mellon University,Pittsburgh PA (USA).

[19] Sycara, K., Decker, K., Pannu, A., Williamson, M.,and Zeng, D. 1996. Distributed Intelligent Agents.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 aboutCapabilities 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 HeterogeneousSources. In Proceedings of International Conferenceon Very Large Database Systems VLDB-97. availableat 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