I N T E L L I G E N T
A G E N T S
Impact: A Platform for Collaborating Agents Khaled A. Arisha, Fatma Ozcan, Robert Ross, and V.S. Subrahmanian, University of Maryland Thomas Eiter, Technical University of Vienna Sarit Kraus, Bar-Ilan University and the University of Maryland
T
HE INTERACTIVE MARYLAND PLATform for Agents Collaborating Together is a software platform for creating and deploying autonomous intelligent agents that can dynamically interact with other agents. Impact has two main goals. The first is to formally define what a software agent is— unlike most previous definitions in the AI community,1 our definition is structural rather than behavioral. In Impact, then, “agentization” of a software program corresponds to augmenting the program’s code with “wrapping” code that gives it its structure. However, agentizing a program is not enough. In a distributed, independently evolving software environment, agents still need to know what other agents lurk in the environment, and they might wish to advertise their presence and the services they offer. So, any infrastructure that supports multiagent interactions and applications must provide a basic set of services that other agents can access. The Impact architecture achieves this second goal through a set of special servers, which we have implemented and deployed. These servers identify agents that provide services that are the same as or similar to a requested service. Impact computes similarity using a search and a query algorithm, which we’ve successfully tested on large data sets. 64
IMPACT AGENTS CONSIST OF SOFTWARE CODE WITH AN ASSOCIATED WRAPPER THAT “AGENTIZES” THE CODE. A SET OF SPECIALIZED SERVERS FACILITATE AGENT INTEROPERABILITY IN AN APPLICATION-INDEPENDENT MANNER.
Impact’s architecture The Impact architecture (see Figure 1) supports the interactions between a set of agents that might be geographically dispersed on a network. The Impact server provides the infrastructure upon which different Impact agents can interact. To avoid a performance bottleneck, multiple copies of the server can be replicated and scattered across the network.
Impact agents A set of data objects can be represented in a wide variety of ways. When building an application, we’d like to select a data structure that supports the application operations that are the most frequently executed, the most 1094-7167/99/$10.00 © 1999 IEEE
critical, or both. So, any definition of an agent must support such flexible choice of data structures, and agentization must let us extend arbitrary data representations. In Impact, an agent consists of any body of software code whatsoever, with the associated wrapper. Figure 2 shows such an agent’s architecture. The software code. The agent’s code consists of two parts: • a set of data structures (or data types) manipulated by the agent. For example, if we are building a database agent, this set of data types might consist of a set of primitive attribute types, together with all the record types constructible from those attribute types. • a set of functions that manipulate the data types. These functions are typically the IEEE INTELLIGENT SYSTEMS
Impact server
function calls supported by the application programmer interface for the software code. Each function specifies the types of its inputs and outputs.
Impact server detail
Agent
Agent
Yellow pages
Type
Thesaurus Interface
Impact server
The wrapper. An agent’s wrapper has nine basic components: Service descriptions. A set of service descriptions, one for each service the agent offers, facilitates access to that agent’s services by other agents or humans. We’ll describe this component in more detail in the next section. Figure 2 does not show service descriptions because they are typically stored by the Impact server rather than in the agent wrapper, although individual agents are free to store this information locally as well.
Agent
Network
Agent Agent
Agent
Impact server
Figure 1. Impact’s architecture.
Security
Message box. This program lets multiple agents exchange messages and lets each agent manipulate its message box. The message box consists of a set of data structures for message storage, with a set of operations for inserting, deleting, reading, and modifying messages. This component is optional; an agent can use a different messaging program.
Agent program Metaknowledge
Action base
Action constraints
Integrity constraints
Message box
To network
Concurrent action mechanism
Heterogeneous query language
State. At any given point in time, each agent has a state, which consists of all the agent’s data objects (each data object must belong to one of the data types associated with the agent), with all the messages in the agent’s message box. Action base. This is a set of actions that the agent can use to change its state. The actions can be implemented either logically or through procedural code. However, each action must have descriptions of the preconditions on the agent’s state that must be satisfied for the action to be executable, and of that execution’s effects on the agent’s state. In Impact, the “tick” of a clock is an action, an agent’s decision to do nothing is an action, and the sending or reading of a message is an action. Unlike most AI systems, planning is also an action. For example, an agent might explicitly invoke a route planner or a hierarchical-task-network planner. Query language. Agents can be built on top of arbitrary data structures, and preconditions of actions (and, in general, conditions over agent states) must be expressed in terms of such data structures. So, each agent has a query language for expressing queries (and hence conditions, because conditions are just MARCH/APRIL 1999
Function calls
Action code
Data
Figure 2. The Impact agent architecture. The grey boxes represent the wrapper; the white represent the legacy code.
Boolean queries) over arbitrary sets of data types. To query heterogeneous data types, Impact uses the Hermes Query Language, which can express arbitrary Boolean queries over arbitrary data types and whose current implementation can access over 20 commercial and specialized data structures and software packages.2–4 However, Impact can also use any query language—for example, Tsimmis5 and SIMS6—that can query multiple data structures. Concurrent action mechanism. A CAM takes as input an agent state and a set of actions, and returns as output a single action. This action could be a member of the input set, or it could be a completely new, composite action. If this action has a precondition that is false in the state, the set of actions cannot execute concurrently. Otherwise, the set of
actions specifies the result of the concurrent execution of this set in the specified state. Thomas Eiter and his colleagues have developed several specific instances of concurrentaction execution and have shown that adding stronger epistemic properties increases the computational complexity of concurrentaction execution.7 Action constraints. These constraints explicitly state that if the agent state satisfies certain conditions, certain actions cannot execute concurrently. (A CAM only specifies the result of concurrent-action execution.) Integrity constraints. These constraints specify which agent states are legal. For example, a robot might have an integrity constraint saying that in any state, its location must be unique. 65
〈S〉
〈\S〉
find:route 〈MI〉from_streetnumber:integer〈\MI〉 〈MI〉from_street:string〈\MI〉 〈MI〉from_city:city〈\MI〉 〈MI〉from_state:us_states〈\MI〉 〈MI〉to_streetnumber:integer〈\MI〉 〈MI〉to_street:string〈\MI〉 〈MI〉to_city:city〈\MI〉 〈MI〉to_state:us_states〈\MI〉 〈O〉map:file〈\O〉
Figure 3. A service description of a Web site service to find a route between two points on a map. Agent program. This specifies the agent’s operating principles, including what actions the agent may do, what it must not do, what it must do, and so on. In effect, these principles describe the dos and don’ts for the agent and the conditions under which these dos and don’ts apply. Impact specifies operating principles through the Agent Program Language.7 Creating agents. So, agentization of a legacy program consists of associating with that program an action base, a CAM, a set of integrity constraints, a set of action constraints, and an agent program. We have also extended the definition of an agent state to include security-related structures8 and metareasoning structures.9
The service-description language Although the agent’s code can be implemented in different languages, all service descriptions must be in a single HTML-like language. We’ll describe this language using a series of definitions. In the following discussion, we use “verb” and “noun” in their usual English sense. A service description consists of that service’s • Service name: This is a verb-noun (noun) expression describing the service. For example, plans:travel() specifies a service for travel planning. Similarly, sell:car(Japanese) describes a service that sells Japanese cars. • Inputs: Services assume that their users will provide zero or more inputs. The service description must specify what inputs are expected and which of these inputs are mandatory. For each input, this specification must provide an “English” name and a semantic type. For example, destination:city specifies an input called destination of the type city (which 66
could be an enumerated type). • Outputs: Each output is specified in the same way as an input. • Attributes: Services might also have attributes such as cost (for using the service) and average time of responses to requests for that service. Defining service names. We first introduce the noun term: Definition 1. If n1,n2 are nouns (where n2, but not n1, may also be the empty string) in English, then n1(n2) is a noun term. In this case, n1 is the root of this noun term. When n2 is empty, we will often abuse notation and write n1 instead of n1( ).
For example, car(Japanese) and tickets(plane) are noun terms. Noun terms by themselves mean nothing. However, noun terms considered jointly with a verb define a service name, and a verb by itself can constitute a service: Definition 2. If v is a verb in English, and n1(n2) is a noun term, then both v and v : n1(n2) are service names.
For example, sell:car(Japanese) is a service name, and the verb search can be one too. Defining inputs and outputs. As we mentioned before, each service expects the client that is requesting it to provide inputs having specified types: Definition 3. A type τ is a set whose elements are called values of τ. The pair (T, ≤) is a type hierarchy if T is a set of types, and ≤ is a partial ordering on T.
A type variable ranges over the values of a given type: Definition 4. Associated with any type hierarchy (T, ≤) is a set VT of symbols called type variables.
For instance, Author can be a type variable ranging over strings.
When specifying the inputs required to invoke a service, we need to specify variables and their associated types. We do this in the usual way: Definition 5. If s is a variable ranging over objects of type τ, then s:τ is an item.
For example, Author:String, Document:Ascii_file, and Addr:Netaddress are all valid items, assuming that the types String, Ascii_file, and Netaddress are all well-defined. As is common in most imperative programming languages, the syntactic object s:τ means “The variable s may assume values drawn from the type τ.” Some inputs are mandatory (that is, the service cannot or will not honor a request for the service if these inputs are not provided), while others are discretionary (the service would like them, but does not insist they be provided). For example, the sell:car (Japanese) service might require that the model and maxcost fields be filled, but might not require a sunroof field to be filled (although the user may specify that he or she wants or does not want a sunroof). This leads to the next definition: Definition 6. If s:τ is an item, then 〈I〉s:τ〈\I〉 is an input-item atom, 〈MI〉s:τ〈\MI〉 is a mandatory input-item atom, and 〈O〉s:τ〈\O〉 is an output-item atom.
For instance, 〈I〉sunroof:boolean〈\I〉 is a (discretionary) input-item atom; 〈MI〉model: japanese_car〈\MI〉 is a mandatory input-item atom. Similarly, 〈O〉cost:real〈\O〉, 〈O〉specs: car_spec_record〈\O〉, and 〈O〉financing_ plan:finance_record〈\O〉 are output-item atoms. Defining the service description. Now we put it all together: Definition 7. If sn is a service name, and i1, …, in are input-item atoms, mi1, …, mik are mandatory input-item atoms, and o1, …, or are outputitem atoms, then 〈S〉 sn mi1, …, mik i1, …, in o1, …, or 〈\S〉 is a service description.
For example, Travelocity (www.travelocity. com) is a well-known Web site providing travel services. Using our service description language, Figure 3 describes Travelocity’s route service (to find a route between two IEEE INTELLIGENT SYSTEMS
{seek, search} 5
points on a map). We’ve used this syntax to describe a wide variety of services available through the World Wide Web, ranging from travel services, bibliographic search services, and mortgage services.
provide 3
2
rent
(a)
sell
2
3
{explore, investigate} 2 hire vehicle() 2
1 {car(), automobile()}
The Impact server
1
Yellow-pages server. The yellow-pages server maintains three data structures: two term hierarchies and an agent table. To process requests for services, the server employs the find_nn algorithm and the range query algorithm. Term hierarchies. These hierarchies comprise a noun hierarchy and a verb hierarchy. The nodes in the verb hierarchy are sets of synonym verbs, while the nodes in the noun hierarchy are sets of synonymous noun terms. If node N is an ancestor of node N′ in either of these hierarchies, the labels of N are more general than those of N′. For example, the verb provide is more general than sell, and the noun car is more general than car (Japanese). Weights on the edges denote degrees of dissimilarity—the larger the weight, the less similar the nodes involved. To define term hierarchies, we start by assuming a set Σ whose elements are terms, and an equivalence relation ∼ on Σ. Basically, Σ is a set of words, and ∼ represents synonymity. For example, Σ could be a set of verbs, and v1 ∼ v2 might indicate that verbs v1 and v2 are synonymous. Definition 8. A Σ-node N is any subset Σ that is closed under ∼. That is, x ∈ N & y ∼ x ⇒ y ∈ N, and x,y ∈ N ⇒ x ∼ y. MARCH/APRIL 1999
1 Chevy()
1 Dodge()
3
van() {truck(), pickup()} 1
car(American)
One agent might use terminology different from that of another agent to describe a service that it seeks. For example, agent A might want to find agents that provide cars. Agent B might specify that it offers the service sell:car(Japanese), but agent A might be searching for a service specified as provide:car. Here, different terms denote a similar service—however, determining that these two syntactically different expressions are semantically similar is nontrivial. To facilitate such transactions, an Impact server includes five components (together with traversal algorithms): a yellow-pages server, a registration server, a type server, a thesaurus server, and a synchronization module.
scan
car(Japanese) 2 Geo()
1 Honda()
1 Mazda()
2
2
Nissan()
Toyota()
(b) Figure 4. Hierarchy examples: (a) verb; (b) noun. In other words, Σ-nodes are equivalence classes of Σ.
If ∼1 denotes the ordinary notion of equivalence among these terms, the following are Σ1-nodes: N1 = {car, automobile} N2 = {truck, pickup} Definition 9. A Σ-hierarchy is a weighted, directed acyclic graph SH = (T, E, ℘) such that • each vertex of T is a nonempty Σ-node; • if t1,t2 ∈ T are different, then t1 and t2 are disjoint; and • ℘ is a mapping from E to Z+ indicating a positive distance between two neighboring vertices (we currently do not require ℘ to satisfy any metric axioms).
When SH is fixed, triples of the form (t1, t2, d) denote an edge from t1 to t2 (in SH) having ℘(t1, t2) = d. Figure 4a shows a sample verb hierarchy; Figure 4b shows a noun-term hierarchy. All edges in these graphs are directed downwards. In Figure 4a, the edge between nodes {seek, search} and {provide} has a weight of five, while the edge between {seek, search} and {scan} has a weight of three, indicating that{scan} is more similar to {seek, search} than to {provide}. Definition 10.A Σ-Path p between two nodes t, t′ ∈ T in the Σ-hierarchy SH = (T, E, ℘) is a sequence t1, t2, …, tn such that t1 = t, tn = t′, and for all 1 ≤ i < n, (ti, ti+1) ∈ E. The length of such a path is (n − 1). The cost, cost(p), of this path is the sum of the weights of the edges along the path.
We are now ready to define the notion of distance between two nodes in a hierarchy.
Definition 11. Consider a Σ-hierarchy, SH = (T, E, ℘), and suppose w1,w2 ∈ Σ are terms. Then the distance between w1 and w2 with regard to SH, denoted as dSH(w1, w2), is • 0 if there exists t ∈ T such that {w1, w2} ⊆ t; • cost(pmin) if a Σ-path exists between w1 and w2, and pmin is such a least-cost path; and • ∞ otherwise.
Given any Σ-hierarchy, SH = (T, E, ℘), the distance function, dSH, induced by it is welldefined and satisfies the triangle inequality. We denote a verb hierarchy by Σv = (Tv, Ev, ℘v), and a noun-term hierarchy by Σnt = (Tnt, Ent, ℘nt). When human beings or agents access the yellow-pages server, they specify a service vQ:ntQ and make one of two requests: • k-nearest-neighbor request: Find the k “nearest” pairs (v, nt) in the hierarchy such that an agent exists who provides that service, and identify that agent. • Range query: Find all pairs (v, nt) within a specified “distance” d such that an agent exists who provides that service, and identify that agent. However, thus far, we have only defined distances on Σv and Σnt individually—we haven’t proposed a notion of distance between pairs of verbs and noun-terms. We now define the combination of two distance functions on two hierarchies: Definition 12. Suppose we have two different hierarchies, Σ1 = (T1, E1, ℘1) and Σ2 = (T2, E2, ℘2). Let d1 and d2 be the distance functions induced by Σ1 and Σ2, respectively. Consider two pairs of words, (w1, w′1), (w2, w′2) ∈ Σ1 × Σ2. A 67
Table 1. An agent table. VERB
NOUNTERM
AGENT
WORD
SYNONYMS
rent rent rent hire rent sell rent
car(Japanese) car(American) vehicle() Honda() car(Japanese) Mazda() vehicle()
agent1 agent3 agent6 agent4 agent2 agent2 agent3
explore vehicle car(Japanese) scan provide seek rent car(American)
inquire, examine, probe, investigate carrier, carriage, van, wagon, car, truck Honda, Nissan, Mazda, Toyota browse, glance, skim supply, hand over search, look up hire, lease Chevy, Neon, Dodge
composite distance function, cd, is any mapping from (Σ1 × Σ2) × (Σ1 × Σ2) to Z+ such that • cd((w1, w′1), (w2, w′2)) = cd((w2, w′2), (w1, w′1)). • cd((w1, w′1), (w1, w′1)) = 0. • If d1(w1, w2) ≤ d1(w1, w3), then cd((w1, w′1), (w2, w′2)) ≤ cd((w1, w′1), (w3, w′2)). • If d2(w′1, w′2) ≤ d2(w′1, w′3), then cd((w1, w′1), (w2, w′2)) ≤ cd((w1, w′1), (w2, w′3)). • cd(w1, w′1), (w3, w′3), ≤ cd((w1, w′1), (w2, w′2)) + cd((w2, w′2), (w3, w′3)).
The last entry in the above definition might seem redundant, but it isn’t (because of space restrictions, we do not present a proof of this here). Agent table. The agent table is a relational table containing three attributes: NounTerm is the table’s primary key, Verb is its secondary key, and Agent is an agent id. Suppose the tuple (rent, car(Japanese), agent1) is in this table. This means that agent1 provides the service (rent, car (Japanese)). Table 1 shows an example agent table, in which two agents provide (rent, car(Japanese)). Impact implements the agent table as an Oracle relation. We have implemented a search_agent_table function, which takes three arguments—a verb v, a noun term nt, and an integer k. This function searches the agent table to find at most k agents that provide the exact service (v, nt). It first executes the SQL query SELECT Agents FROM AgentTable WHERE Verb = v AND NounTerm = nt,
which returns a set of agents. If this set has k or more elements, search_agent_table returns k of these; if it has fewer than k elements, it returns the entire set. Find_nn algorithm. To perform the k-near-
est-neighbor request, this algorithm examines the hierarchies and the thesaurus. It determines the closeness between (v, nt) and another pair (v′, nt′) using the distance func68
Table 2. Samples from an Impact thesaurus.
tions associated with the verb and noun-term hierarchies, together with the composite-distance function specified by the agent invoking the algorithm. Besides using the above structures and the agent table, this algorithm uses these internal data structures and subroutines: • Todo is a list of verb-and-noun-term pairs, which are extended by their distances from the verb-and-noun-term pair that is requested in the initial or recursive call to the find_nn algorithm. Todo is maintained in the ascending order of distance and is not necessarily complete. • ANSTABLE is a table consisting of at most k entries (k being the number of agents requested). At any given point during the find_nn algorithm’s execution, ANSTABLE will contain the best answers found thus far, together with their distances from the requested service (v, nt). The algorithm lists the answers in the ascending order of distance. • The search_service_table function, given a verb-and-noun-term pair (v, nt) and an integer k, returns the set of all agents that provide the service (v, nt); if their number exceeds k, it returns k of them, which it chooses deliberately. (Different selection strategies are imaginable—for example, random or order of appearance in the agent table. We assume that such a fixed strategy is chosen, but do not discuss this issue further here.) • The num_ans function merely keeps track of the number of answers in ANSTABLE. • The next_nbr function takes as input Todo and a pair (v, nt). Todo consists of verb-and-noun-term pairs that have not yet been relaxed. Suppose (v1, nt1) is the first pair in this list. Candidate relaxation of (v1, nt1), cr(v1, nt1), involves two parts. First, if v′ is an immediate neighbor of v1 in the verb hierarchy, then (v′, nt1) is in cr(v1, nt1). Second, if nt′ is an immediate neighbor of nt1 in the noun-term hierarchy, then (v1, nt′) is in cr(v1, nt1). The next_nbr function removes (v1, nt1) from Todo and then inserts all the members of cr(v1, nt1) into
Todo, while ensuring that Todo is in the
ascending order of distance from (v, nt). The next_nbr function returns as output Todo’s first member. If Todo is empty, it returns a special pair. • The relax_thesaurus function is called when either v or nt of the specified service name does not appear in the corresponding hierarchy. It returns a pair similar to (v, nt) whose components do appear in the hierarchies. For example, a thesaurus might include the words and synonyms in Table 2. Figure 5 describes the find_nn algorithm. To see how the algorithm works, consider the verb and noun-term hierarchies in Figure 4 and the agent table and thesaurus in Tables 1 and 2. Furthermore, suppose the compositedistance function is addition of the components; that is, cd((w1, w2), (w1′, w2′)) = d1((w1, w1′) + d2(w2, w2′)). Consider the call find_nn(rent, car(), 2), which requests two agents that rent cars. Initially, the pair 〈v, nt〉 is 〈rent, car()〉. Todo initially contains (rent, car()). Because 〈rent, car()〉 ∈ Σv × Σnt, the algorithm executes search_agent_table (rent, car(), 2). This returns the empty set because no agent provides the service rent:car(). The algorithm now relaxes (rent, car()) by calling next_nbr, which returns (rent, vehicle()). Todo now contains the set {(rent, car(Japanese)), 1), (rent, car(American)), 1), (provide, car()), 3)}. The call search_ agent_table (rent, vehicle(), 2) will return agent6, which provides a rent:vehicle() service. The algorithm inserts this result into ANSTABLE, with the result’s composite-distance-func-
tion value of one. Because we still need to find another answer, the algorithm calls next_nbr again. This call returns the pair (rent, car (Japanese)), and the call search_ agent_table (rent, car(Japanese), 1) results in agent1, which provides rent: car(Japanese). Although agent2 also provides rent:car(Japanese), search_ agent_table only returns agent1 because IEEE INTELLIGENT SYSTEMS
(* find the k agents offering the services closest to 〈v, nt〉, and output them *) (* with their distances; relax 〈v, nt〉 first, if it is not in the hierarchy *) create(Todo, v, nt); ClosedList = NIL; ANSTABLE = ∅; if 〈v,nt〉 ∈ Σv × Σnt, then { done = false; SOL = search_agent_table(v, nt, k); while ¬done do { insert((v, nt), ClosedList); insert(SOL, ANSTABLE); n = num_ans(ANSTABLE); if n ≥ k then done = true else { (v’, nt’) = next_nbr(Todo); if error(v’, nt’) = true then done = true else { 〈v, nt〉 = 〈v’, nt’〉; SOL = search_agent_table(v, nt, k − n); } (* end inner if *) } (* end middle if *) } (* end while *) } (* end outer if *) else {(* search thesaurus *) (v’, nt’) = relax_thesaurus(v, nt); if error(v’, nt’) = true then return ERROR else find_nn(v’, nt’, k) } return ANSTABLE; end
Figure 5. The find_nn algorithm, which performs the k-nearest neighbor request. only one was requested. Now that ANSTABLE contains two answers, the find_nn function terminates by returning {(agent6, 1), (agent1, 1)}. The range query algorithm. This algorithm (see Figure 6) has two steps. The first is the while loop, which finds all pairs vnt* = 〈v*, nt*〉 that are within the specified distance d from vnt. This step uses an expand procedure,
which behaves as follows: expand(vnt, vnt′, d) first computes the set {vnt# | d′ = def cd(vnt#, vnt) ≤ d, vnt# ∈ cr(vnt′), 〈vnt#, d′〉 ∉ RelaxList}. RelaxList contains the services that have already been considered. Then, expand inserts the elements of this set into Todo. The second step executes a select opera-
tion on the agent table, finding all the agents that offer any of the service names identified in the first step. As in the find_nn algorithm, if v or nt are not in the relevant verb or nounterm hierarchies, the range query algorithm calls relax_thesaurus to find a similar pair that belongs to them. Registration server. A new agent’s owner must register that agent with this server,
(* find all agents offering a service within distance d to 〈v, nt〉 *) if d < 0 then return NIL(exit); if 〈v, nt〉 ∈ Σv × Σnt then { RelaxList = NIL; Todo = 〈〈v, nt〉, 0〉; while Todo ≠ NIL do { 〈〈v’, nt’〉, d’〉 = first element of Todo; insert 〈〈v’, nt’〉, d’〉 into RelaxList; remove 〈〈v’, nt’〉, d’〉 from Todo; expand (〈v, nt〉, 〈v’, nt’〉, d’); } return πAgents,Dist(RelaxList[Verb = v’, NounTerm = nt’]AgentTable) else {(* search thesaurus *) 〈v’, nt’〉 = relax_thesaurus(v, nt); if error(v’, nt’) then return ERROR else return range(v’, nt’, d-cd(〈v, nt〉, 〈v’, nt’〉)) } end
Figure 6. The range query algorithm. MARCH/APRIL 1999
69
Related work In matchmaking, agents advertise their services, and matchmakers match an agent requesting a service with one (or more) that provides it. We’ll look at two of the best-known examples. Daniel Kuokka and Larry Harada present the Shade and Coins systems for matchmaking.1 Shade uses logical rules to support matchmaking—the logic is a subset of the Knowledge Interchange Format and is very expressive. In contrast, Coins assumes that a message is a document (represented by a weighted term vector) and retrieves the most similar advertised services, using Gerard Salton’s Smart algorithm.2 Keith Decker, Katia Sycara, and Mike Williamson present matchmakers that store capability advertisements of different agents.3 They look for exact matches between requested services and retrieved services, concentrating on architectures that support load balancing and protect the privacy of different agents. Impact (see the main article) differs from these approaches in two main ways. First, our service descriptions use a simple, restricted language similar to HTML. By restricting our language, we can clearly articulate what we mean by “similar” matches in terms of nearestneighbor and range queries, and can provide efficient algorithms to implement these operations (as our experiments described in the main article demonstrate). Second, the user (or owner of an agent) can expand the underlying ontologies (verb and noun-term hierarchies) arbitrarily, and we provide the software tools for this. To date, we have explicitly encoded (in our language) service descriptions of over 40 well-known independently developed programs available on the Web, and this number is increasing. However, we do not address load balancing and privacy. With respect to agent architectures, Michael Genesereth and Steven Ketchpel have taken several proposals4–6 and broadly classified them into four categories.7 In the first category, each agent has an associated “transducer” that converts all incoming messages and requests into a form that is intelligible to the agent. This is clearly not what happens in Impact—the transducer must anticipate what other agents will send us and translate that—which is difficult to do.7 The second category uses wrappers that “inject code into a program to allow it to communicate.”7 The Impact architecture provides a language (the service-description language) for expressing such wrappers, together with accompanying algorithms. The third category completely rewrites the code implementing an agent,7 which is an expensive alternative. The fourth is Gio Wiederhold’s mediation approach, which assumes that all agents will communicate with a mediator, which in turn might send messages to other agents.8 In contrast, our framework allows point-to-point communication between agents without requiring a mediator. Researchers have also extensively investigated collaborative problem solving and negation in multiagent systems9–13 Because our
which provides these facilities: (1) Hierarchy search and browsing: The server contains an interface through which the user can browse the verb and noun-term hierarchies to see if they contain words to describe the agent’s services. The registration server also supports querying the hierarchy; for instance, the user can ask if honda is in the noun-term hierarchy. If so, the server displays an appropriate part of that hierarchy above, below, and including honda. This facility lets the 70
approach supports point-to-point interagent communication, such negotiations can be built on top of our architecture. So, this research complements ours.
References 1. D. Kuokka and L. Harada, “Integrating Information via Matchmaking,” J. Intelligent Information Systems, Vol. 6, Nos. 2–3, 1996, pp. 261–279. 2. G. Salton and M. McGill, Introduction to Modern Information Retrieval, McGraw-Hill, New York, 1983. 3. K. Decker, K. Sycara, and M. Williamson, “Middle Agents for the Internet,” Proc. IJCAI ’97: Intl’l Joint Conf. Artificial Intelligence, AAAI Press, Menlo Park, Calif., 1997, pp. 578–583. 4. L. Gasser and T. Ishida, “A Dynamic Organizational Architecture for Adaptive Problem Solving,” Proc. AAAI ’91, AAAI Press, 1991, pp. 185–190. 5. L. Glicoe, R. Staats, and M. Huhns, “A Multi-Agent Environment for Department of Defense Distribution,” Proc. IJCAI ’95 Workshop on Intelligent Systems, 1995. 6. W.P. Birmingham et al., “The Distributed Agent Architecture of the University of Michigan Digital Library (UMDL),” Proc. Spring Symp. Series on Software Agents, 1995. 7. M.R. Genesereth and S.P. Ketchpel, “Software Agents,” Comm. ACM, Vol. 37, No. 7., July 1994, pp. 48–53, 147. 8. G. Wiederhold, “Intelligent Integration of Information,” Proc. 1993 ACM SIGMOD Conf. Management of Data, ACM Press, New York, 1993, pp. 434–437. 9. S.E. Conry et al., “Multistage Negotiation for Distributed Satisfaction,” IEEE Trans. Systems, Man, and Cybernetics, Vol. 21, No. 6, 1991, pp. 1462–1477. 10. N.R. Jennings. “Controlling Cooperative Problem Solving in Industrial Multi-Agent Systems Using Joint Intentions,” Artificial Intelligence J., Vol. 75, No. 2, 1995, pp. 1–46. 11. S. Kraus, “Negotiation and Cooperation in Multi-Agent Environments,” Artificial Intelligence J., Vol. 94, Nos. 1–2, 1997, pp. 79–98. 12. J.S. Rosenschein and G. Zlotkin, Rules of Encounter: Designing Conventions for Automated Negotiation among Computers, MIT Press, Cambridge, Mass., 1994. 13. M. Wellman, “A Market-Oriented Programming Environment and Its Application to Distributed Multicommodity Flow Problems,” J. Artificial Intelligence Research, Vol. 1, 1993, pp. 1–23.
owner modify an agent’s service description to take into account existing terminology, rather than expand the existing vocabulary needlessly. (2) Hierarchy updates: Then, once the user has determined exactly how he or she wants to specify the agent’s services, the registration server inserts any new words introduced by the user into the hierarchies, in consultation with the user. Only authorized users (for example, those allowed to introduce new agents to the system) may make hierarchy updates. (3) Agent table update: Finally, the regis-
tration server updates the agent table to reflect the new services offered by the agent. Type server. This server maintains type information as a hierarchy (for example, the type city might be a subtype of the type place) that is used to specify the τ component of an item s:τ. When registering a new agent, human users access the type server with a graphical user interface through the registration server. The type server offers users the same hierarchy search and browsing that the registration server offers. IEEE INTELLIGENT SYSTEMS
0.30
1.0
0.25 Average time (seconds)
Average time (seconds)
1.2
0.20
0.8
0.15
0.6
0.10
0.4
0.05
0.2 0
0 2
(a)
4
6
8 10 12 14 Number of neighbors
16
18
20
2
4
6
(b)
8 10 12 14 Number of neighbors
16
18
20
Figure 7. The k-nearest-neighbor request algorithm’s performance: (a) the average time per query; (b) the average time per retrieved answer. Agents access the type server directly. They can contact the type server with queries of the form, “Is type τ1 a subtype of type τ2?” Such queries arise when one agent wants to see if it can pipe certain information it has (of type τ1) to another agent that requires inputs of type τ2. Answering such a query involves nothing more than a straightforward traversal of the type hierarchy. Thesaurus server. This server lets the owner of a new agent browse a thesaurus and find words similar to the ones he or she is using to describe services. We are building it on top of a commercial thesaurus system (the ThesDB Thesaurus Engine from Wintertree Software) The server supports only one request type, which provides a word as input, and requests all synonyms as output. The thesaurus server also “marks” those synonyms that appear in the verb or noun-term hierarchy. As with the type server, human users access the thesaurus server with a graphical user interface through the registration server, and agents access it directly. Synchronization module. The mirroring of Impact servers raises the problem of consistency across those servers. To solve this, the synchronization module ensures that all servers access the same data. Users and agents do not access the synchronization module. Every time a copy of data structures maintained by an Impact server is updated, the module time-stamps these updates and propagates them to all the other servers. Each server incorporates the updates according to the time-stamps. If a server performs a local update before it should have incorporated a remote update, the module performs a rollback, as in classical databases.10 An Impact server’s data structures are only MARCH/APRIL 1999
updated when a new agent (or a new service) is added to an existing agent’s service repertoire. Because the use of existing agents and interactions between existing agents are typically much more frequent than new agent or service introductions, updating should not burden the system much.
Implementation and experiments So far, we’ve implemented the algorithms underlying all parts of the Impact architecture, except for the synchronization component. (However, some graphical interfaces are still under construction.) Wherever possible, we’ve used commercially available software—for example, Oracle and ThesDB, as we mentioned earlier. We evaluated the performance of the k-nearest-neighbor request algorithm as the number of nearest neighbors requested increased, and of the range query algorithm as the query’s range increased. We used a NASA hierarchy consisting of 17,445 words (solely for experimental purposes, we used the same hierarchy as both a verb and a noun hierarchy, although the Impact prototype uses different hierarchies). We assumed that the weights on all edges in the hierarchies were 1 and that the composite-distance function was addition. Figure 7 shows the k-nearest-neighbor algorithm’s performance as k increases from 1 to 20. For any given k, we considered 100 queries, generated randomly. Figure 7a shows the average time for these queries. In some cases, even though we requested k neighbors, we only got back k′ < k answers. Figure 7b shows the average time per retrieved answer, which varies between 0 and 1 second, and rises more or less linearly as k increases.
However, the average time per retrieved answer (see Figure 7b) is more or less constant, fluctuating around 0.2 second. Figure 8 shows the range query algorithm’s performance. Again, we ran 100 queries and increased the range from 1 to 20 units. Figure 8a shows the average time; Figure 8b shows the average time per retrieved answer. The average time per query stays more or less constant at 1.6 seconds. This number is higher than that of the k-nearest-neighbor algorithm, but this might likely be because the number of retrieved answers within r radial units might be significantly larger than r. The average time per retrieved answer for range queries is approximately 0.5 second.
W
E ARE EXTENDING THE IMPACT server design so as to support a host of security features and to support scalable interaction with a variety of agents. The former includes techniques by which an agent developer can specify conditions under which information about data services that he or she offers may be disclosed to other agents. The latter includes the development of methods by which an Impact server can prioritize requests from agents and can attempt to simultaneously compute multiple yellowpages requests instead of queuing them. We’ve also made significant progress on the 71
2.0
0.7 0.6
1.6
Average time (seconds)
Average time (seconds)
1.8
1.4 1.2 1.0 0.8 0.6 0.4
0.5 0.4 0.3 0.2 0.1
0.2 0
0 2
4
(a)
6
8
10
12
Radius of query
14
16
18
20
2
4
6
(b)
8
10
12
14
16
18
20
Radius of query
Figure 8. The range query algorithm’s performance: (a) the average time per query; (b) the average time per retrieved answer. design and implementation of tools for wrapping agents.7
Acknowledgments Impact is a joint effort between the Army Research Laboratory, the University of Maryland, Bar-Ilan University (Israel), the Technical University of Vienna (Austria), the University of Koblenz (Germany), and the University of Torino (Italy). This work was supported by the Army Research Office under Grants DAAH-04-95-10174, DAAH04-96-10297, and DAAH04-96-1-0398; by the Army Research Laboratory under contract DAAL01-97-K0135; by NSF Young Investigator award IRI-93-57756; by TASC/ DARPA grant J09301S98061; and by a DAAD grant.
References 1. J.P. Müller, M.J. Wooldridge, and N.R. Jennings, eds., Intelligent Agents III: Int’l Workshop on Agent Theories, Architectures, and Languages, Lecture Notes in Computer Science/Lecture Notes in Artificial Intelligence, No. 1193, Springer-Verlag, Berlin, 1996. 2. A. Brink, S. Marcus, and V.S. Subrahmanian, “Heterogeneous Multimedia Reasoning,” Computer, Vol. 28, No. 9, Sept. 1995, pp. 33–39. 3. S. Adali et al., “Query Processing in Distributed Mediated Systems,” Proc. 1996 ACM SIGMOD Conf. Management of Data, ACM Press, New York, 1996. 4. J. Lu et al., “Efficient Maintenance of Materialized Mediated Views,” Proc. 1995 ACM SIGMOD Conf. Management of Data, ACM Press, 1995. 5. S. Chawathe et al., “The TSIMMIS Project: Integration of Heterogeneous Information Sources,” Proc. 100th Anniversary Meeting Information Processing Soc. Japan, Information Processing Soc. Japan, Tokyo, 1994, 72
pp. 7–18; www-db.stanford.edu/~chaw/pubs/ tsimmis-ipsj94.ps. 6. Y. Arens et al., “Retrieving and Integrating Data from Multiple Information Sources, Int’l J. Intelligent Cooperative Information Systems, Vol. 2, No. 2, 1993, pp. 127–158. 7. T. Eiter, V.S. Subrahmanian, and G. Pick, Heterogeneous Active Agents, Tech. Report CSTR-3880, Univ. of Maryland, College Park, Md., 1998. 8. P. Bonatti et al., “Data-Security in Heterogeneous Agent Systems,” Cooperative Information Agents, M. Klusch, ed., SpringerVerlag, 1998, pp. 290–305. 9. J. Dix, V.S. Subrahmanian, and G. Pick, Meta Agent Programs, submitted to J. Logic Programming. 10. H. Korth and A. Silberschatz, Database System Concepts, McGraw-Hill, New York, 1986.
Khaled A. Arisha is a software and system engineer in AlliedSignal Advanced Systems Technology Group, building communication protocols for the avionics industry. His technical interests include communication-protocol modeling, intelligent information agents, databases, networking. He is also pursuing his PhD in communicationprotocol modeling. He received his BS in computer science and engineering and an MS in computer science from Alexandria University in Egypt. He also received an MS in computer science from the University of Maryland at College Park. He is a member of the Egyptian Engineer Society. Thomas Eiter is a professor of computer science at the Technical University of Vienna, where he heads the Knowledge-Based Systems Group of the Information Systems Department. His research interests include the foundations of databases and artificial intelligence, knowledge representation and reasoning, and intelligent agents. He received his PhD in computer science from the Technical University of Vienna.
Sarit Kraus is an associate professor of mathematics and computer science at Bar-Ilan University and an adjunct associate professor at the Institute for Advanced Computer Studies, at the University of Maryland. She has worked extensively in automated negotiation and cooperation among automated agents, development of intelligent agents, information agents, distributed artificial intelligence, and nonclassical logics. She received her PhD in computer science from the Hebrew University of Jerusalem. Fatma Ozcan is a PhD student in the Computer Science Department at the University of Maryland, College Park. Her research interests include agents, integration of heterogeneous information systems, and query optimization. She got her BSc and MSc in computer engineering from the Middle East Technical University, Ankara, Turkey. Robert Ross is a faculty research assistant at the University of Maryland, where he received a BS in computer science and in psychology. His areas of interest are databases, agent systems, probabilistic and temporal reasoning, and geographic information systems. V.S. Subrahmanian is an associate professor in the Computer Science Department at the University of Maryland, College Park. He has worked extensively in knowledge bases, bringing together techniques in artificial intelligence and databases. He coedited the Proceedings of the First International Workshop on Logic Programming and NonMonotonic Reasoning (MIT Press, 1991) and Multimedia Database Systems: Research Issues and Directions (Springer-Verlag, 1995). He coauthored Introduction to Advanced Database Systems (Morgan Kaufmann, 1997) and wrote Principles of Multimedia Database Systems (Morgan Kaufmann, 1998). He serves on DARPA’s Executive Advisory Council for the Advanced Logistics Program. He received his PhD in computer science from Syracuse University.
Address correspondence to V.S. Subrahmanian, Computer Science Dept., A.V. Williams Bldg., Univ. of Maryland, College Park, MD 20742;
[email protected]. IEEE INTELLIGENT SYSTEMS
