A Framework for Dynamic Matchmaking between Messages and Services in Multi-Agent

Systems

Thesis Proposal Presented to the Department of Computer Science at Brigham Young University

In Partial Fulfillment of the Requirement for the Degree of Masters of Science

Muhammed Al-MuhammedOctober 25, 2002

1 IntroductionAgents augment objects by adding autonomous behavior, by being goal-driven

(proactive), and by having the ability to communicate in high-level languages based on “speech-act theory” rather than on method-invocation [25]. Agents also have a knowledge base that contains knowledge about themselves and about their environment1

[27]. Agents, in large multi-agent systems, do not accomplish all their tasks alone, thus they need to cooperate [12, 20]. Cooperation among agents requires the ability to communicate, and this ability naturally leads to the need for mutual understanding.

Unfortunately, different designers create agents using different programming languages and different platforms [9]. This heterogeneity makes it difficult or even impossible for agents to directly communicate using method invocation. To address this interoperability difficulty, researchers have realized the need for a common language that all communicating agents can understand. This common language should allow queries (asking for information), assertions (inserting new formulas, deleting formulas, etc.), or other services (printing, doing computations, etc). Agents use messages in a commonly understood language as an indirect way to invoke each other’s capabilities2.

In order for messages to result in actions, an application programmer must map messages to methods that do the actual action specified in messages. Specifically, a programmer has to specify in advance what function is invoked for each message type [8, 30, 12, 13]. Figure 1 shows mappings between services and messages. After writing an agent, a programmer does the circled mapping in Figure 1 manually by specifying a service Si to be invoked as a response for a message whose perfomative [12] is Pi. For example, if an in-coming message has the performative P1 then the receiving agent should execute the service S1.

Figure 1: Mapping between agent services and in-coming messages

Providing the right function handlers requires a programmer to have an in-depth knowledge about the communication language used in the system. Moreover, the designer of an agent has to make decisions about what kind of functions to provide for handling in-coming messages, or even more difficult, has to expect the different forms of messages that can be received in advance. Unsound decisions may leave some of the messages unanswered although the agent is able to provide an answer for them.

1 The environment is the multi-agent system, to which an agent belongs.2 Methods, services, and capabilities are the same concept, and we will use them interchangeably.

1

Anticipating all types of messages beforehand is an extremely difficult task due to the dynamic nature of multi-agent systems.

Realizing the difficulties of writing agent software and establishing communications, researchers have made many interesting attempts to simplify this task. These attempts have resulted in producing helpful tools such as agent builder [28], Jack [29], JATLite [4], and Jfipa [24] for designing agents. These tools provide an environment that guides designers and allows them to write agents in a short amount of time without any need for previous knowledge of agent programming or even of agents themselves [29]. Unfortunately, these tools lack generality, when the system contains a considerable number of agents [24].

To develop a practical solution, more powerful tools are needed. These tools should make no assumption about the way in which developers design agents. The only requirement would be that an agent reveals its services and the knowledge it wishes to export to these tools. The tools should then utilize an agent’s services and exported knowledge to automatically map in-coming messages to appropriate services. Although capturing the semantics of messages and mapping them to appropriate methods are inherently difficult, doing such a mapping is beneficial because it 1) removes the burden of specifying the mapping from the designer and 2) increases the spectrum of messages that can be answered.

These advantages have motivated us to build such a system. This system makes use of information about the services an agent offers to automatically map messages to services. Consequently, the proposed system will free the agent developer from providing handler functions. This proposed system will attempt to dynamically 1) map messages to appropriate services and invoke them, 2) represent the information about agent services in a common frame, 3) capture semantics of an in-coming message, decompose it to its basic components (input, output, action, input constraints, and output constraints), and represent it in the same common frame, and 4) package answers and deliver them back to senders. Thus the system will make agents communicate without their developers having to worry about how to query other agents or what language they speak.

Although we would like to address all these issues and provide solutions for them, the amount of work is beyond the requirements of a master’s thesis. Thus, in this thesis, we initiate this work 1) by focusing only on query messages, 2) by only demonstrating the feasibility of the approach without resolving difficult differentiations in shades of semantic meaning that themselves would constitute a major work, and 3) by not piecing together and sorting out partial or overlapping queries. We thus aim to show the end-to-end framework of the workable approach rather than solve the subtleties of some partial match or conversion. 2 Thesis Statement

Given the limited situation in which agents only communicate with direct query messages without subtly shades of meaning, how can we dynamically determine what a message requests? Specifically, what is the required information? What are the parameters? And what action(s) should the receiving agent take? What is the appropriate model in which to represent messages and methods? Given such a model, how can we dynamically map an agent’s services to messages? How can we ensure flexibility, scalability, and correctness?

2

3 Methods

3-1 The Problem Currently, in order for agents to communicate, researchers frequently make three assumptions [18]: 1) agents share an ontology that defines the concepts used by these agents, 2) agents communicate with the same agent communication language (ACL), and 3) agents pre-agree on a message format. These three assumptions constitute the fundamental requirements, which are necessary and sufficient for agents to communicate. These three assumptions impose many difficulties. First, they explicitly mean that unless one designer or a group of designers (with full communication among them) develops these agents, the communication among agents is not likely to succeed. That is because if different designers (with no communication among them) develop these agents, then it is unlikely that they will use the same ontologies to describe their agents’ domains and use the same ACL and message format. Therefore all or some of the three assumptions will not hold. Second, the assumptions require a designer who develops a new agent for a multi-agent system (MAS) to know what ontologies other agents in that MAS use, what language they speak, and what messages format they use. This requirement imposes a stiff requirement on an outside developer.

We intend to show in this research how agents can communicate with each other without relying on any of the three assumptions above. We will accomplish this by building a matchmaking system that achieves three goals; namely, it allows agents to communicate without requiring them 1) to have a shared ontology, 2) to share a common communication language, and 3) to pre-agree on a message format. In addition to these three goals, the matchmaking system also has two other goals, namely flexibility and scalability. We ensure flexibility by not making assumptions about how designers develop their agents. Thus, designers can develop their agents any way they wish. We ensure scalability by limiting the requirements for an agent to join a MAS. Crucially, these limited requirements do not require an agent programmer to know information about other agents in the MAS. More specifically, developers do not have to know the languages other agents speak, the vocabularies they use to describe their domains, or the message formats they accept.

3-2 The Proposed SolutionRather than relying on a shared ontology, a common communication language,

and a pre-agreed upon message format to achieve interoperability, we use the capabilities of the proposed matchmaking system (MMS) to achieve this interoperability. We use a global ontology of the MMS to encode all messages exchanged among agents. Significantly, our MMS does not require agents to share ontologies or to know anything about the global ontology. We use other capabilities of the matchmaking system to dynamically map messages to services, regardless of their format. Consequently, agents do not have to pre-agree upon message format or deal directly with an ACL. Instead, they receive all information contained in an in-coming message in their native language.

3-2-1 Agents Although developers are free to design their agents as they wish, we do require an

agent developer to provide two files. One file contains definitions of services that an

3

agent is capable of doing and the other contains vocabularies. Crucially though, these definitions and vocabularies are local to that agent and do not have to be understood by or shared with other agents in the MAS, nor do they need to reference or make any use of the MAS’s global ontology. (Ideally, we would develop a process to extract this information automatically, but this is beyond the scope of this thesis.)

The service definitions describe the action type of the service, its parameters, and the constraints over its action and parameters. The vocabularies include words or phrases that describe an agent’s exported knowledge base, services, input and output parameters of a service, and input and output constraints on parameters of a service. We call a vocabulary for an agent, the agent’s local ontology.

3-2-2 Matchmaking SystemThe MMS consists of a global ontology, a cache to store agent services, a

common frame to represent an agent’s services and in-coming messages, and heuristics for matching. The global ontology also includes dictionaries that contain vocabularies, relationships among the words in the vocabularies, and synonyms that describe a particular domain. The MMS encodes messages exchanged between agents in terms of the global ontology. We use the common frame, which is similar to the one described in [23], as a way to represent messages and services in order to make the matching process easier. It consists of slots, and each slot represents some useful piece of information about a message or a service. Table1 shows the proposed common frame.

Service-name The name of the serviceService-type The service type; i.e. query for this thesisAction-type The type of action that is performed on an input parametersInput Input parametersOutput Output parametersInConstraints Constraints on input parameters, if any.OutConstraints Constraints on output, if any.

Table1: The proposed common frame.

3-2-2-1 TranslationsDetermining the translations between service and description vocabularies in an

agent’s local ontology and the global ontology is the hardest part of the research [1]. There are two important issues related to the translation process: translations and conversions.

Generally, translation is the process of matching3 words of a local ontology of an agent with words of the global ontology. These words are service names, input or output parameters of a service, concepts in an agent’s knowledge base, relationships among these concepts, and constraints on input and output parameters of a service. The translation process takes the following general form: take a word from an agent’s local ontology, find the right word from the global ontology that matches it, and store the two

3 We are only interested in exact matching.

4

words in the translation database as being equivalent. That is likely to be possible because both the global ontology and a local ontology describe the same domain.

In order to make the translation work, we need some auxiliary information that helps in the translation. The only auxiliary information that we have is: 1) Word: a wordi

that defines some concept in the agent knowledge base, 2) Synonyms: terms that mean the same as the wordi, 3) Type: some data type, 4) Values: values that this word can take, 5) Domain: the domain of word, and 6) Relations: the relationships among words. Some possible relations are ISA, ISPARTOF, and ISFOR.

A Local ontology The global ontologyWord: sellingvalue.Synonyms: price.Type: integerValues: $100.Domain: computerRelation: price ISFOR memory

Word: priceSynonyms: value, sellingvalue.Type: realValues: price value recognizerDomain: computerRelation: price ISFOR memory

Table 2: Definition of a word from a local ontology and another word from the global ontology.

We use an example to show how we match words of a local ontology to words of the global ontology and to highlight some of the difficult issues. Table 2 shows a word from a local ontology and another word from the global ontology. The first problem is that the two words price and sellingvalue are different at least from a string matching point of view. Examining the right column of Table 2, the MMS finds that sellingvalue is listed as one of the price synonyms. (When using the linguistic-based match, we rely on techniques of [1].) This signals a potential match but does not guarantee it. The second problem is that the types of the two words are incompatible, namely real and integer. (For the type incompatibility, we rely on [2, 15, 16, 21], which study type incompatibility in schema matching.) Since integer is a subset of real we can convert from integer to real. The third problem is to recognize the semantics of the represented values. The price recognizer in the global ontology will recognize that the values of sellingvalue represent a currency. (For these matches we rely on techniques described in [5, 21].) The fourth problem is that even though the two words represent the same thing, currency, it is not clear if they refer to the same object. Price could be for a whole computer and sellingvalue could be for a component part. (Here we rely on techniques described in [6] to determine exactly which object each word refers to.) Since the relation relates both price and sellingvalue to memory, the MMS concludes that these two words match, so it stores them in the translation database.

In addition to translations between a local ontology and the global ontology, there are conversions for types and data formats. There could be incompatibility between the data in a response (an answer for a query message) and a data representation in a receiving agent (that receives this response). An example is a currency mismatch such as a receiving agent that expects money to be in US$ while a response should be in Syrian Pounds (SP). Conversions can present complications as in [2]. (For solving any really difficult issues, we rely on Issue/Default/Suggestion statements as in [2, 21]. This appropriately brings a human to the loop while minimizing the effort involved.)

5

3-2-2-2 MatchmakingAfter the translations between an agent’s local ontology and the global ontology

of the MMS have been done, the matchmaking between an in-coming message and a service becomes somewhat easier. The MMS activates the matching process when an agent receives a query message from another agent. Upon receiving a query message, which the MMS encodes in terms of the global ontology, the MMS decomposes it into input, output, input constraints, output constraints, and maps it to the common frame. The MMS then accesses its cache of services and attempts to match the query message with a service. If a service and the query request match, then the MMS passes the matching service to the agent for execution after translating it to the agent’s vocabulary. Generally, the matching process involves matching input parameters of a message with those of a service, output parameters of a message with those of a service, and constraints on input and output parameters of a message and a service. We demonstrate the matching process and the problems that occur during this process by an example, taken from [23].

Generally, either an agent or its user specifies a query. The user specifies a query through a form. This form has fields to specify inputs, fields to specify outputs, and fields to specify constrains on inputs or outputs, if any. The user specifies a query in terms of an agent’s local ontology. The MMS does not care who specifies the query as long as it gets the input parameters, the output parameters, and the constraints on the inputs and outputs specified using an agent’s local ontology. Assume as an example that a user (or an agent) wants some information about PCs and sends the following information: outputs: prices, models, and makes of PCs; inputs: LowPrice=SP 20,000, HighPrice=SP 25,000. The MMS then gets this information and translates the terms into global ontology terms. Assume further that an agent provider reveals among others the following service. PCINFOMATION(Real: LowPrice, Real: HighPrice), output: String: make, String: model, Real: price, Date: warranty. InConstraints: LowPrice>=$0 and HighPrice>=LowPrice. OutConstraints: Sorted(price). Table 3 shows the message and the service after the MMS has mapped them to the common frame.

The message The serviceService-name None Service-name PCINFOAMTIONService-type Query Service-type QueryAction-type None Action-type NoneInput Integer: HighPrice=SP20,000

Integer: LowPrice=SP25,000Input Real: LowPrice

Real: HighPriceOutput String: model, Integer: prices,

String: make.Output String: make, String:

model, Real: price,Date: warranty

InConstraints None InConstraints LowPrice>=$0, LowPrice<HighPrice

OutConstraints None OutConstraints

Sorted (price)

Table 3: Shows representation of the message and one of an agent provider services.

Although the service and the message in Table 3 are both represented in terms of the global ontology, there are still several problems to resolve. The order of input

6

parameters in the message differs from order in the service. The types of the message input parameters differ from the types of the service input parameters. The service puts constraints on both the input parameters and the out parameters while the message does not. The order and some types of the service output parameters differ form those of the message. The service provides more information than the message requests. Finally, the message represents the money in SP and the service requires the money in US$. With all these problems, the MMS can still determine that the message and the service match. MMS starts with the inputs. It takes the first input parameter from the service (LowPrice) and matches it against the first parameter in the message (HighPrice). Because they do not match, MMS tries the second input parameter of the message (LowPrice). This time they match (LowPrice=LowPrice). The MMS reorders the input parameters of the message. The value conversions require knowledge both of currency conversions and type conversions. With this knowledge, the MMS converts the integer to real and the Syrian Pounds to US Dollars. The same process applies to the outputs. The MMS filters out and discards the warranty and returns the make, prices (converted to SP), and the model. When the MMS considers input and output constraints, it notices that the service imposes some constraints on the input but the message does not. The MMS should not consider this as a mismatch; instead it checks to see that the input parameters of the message satisfy these constraints; indeed they do since LowPrice=SP20,000>0 and HighPrice> LowPrice. The service imposes some constraints on the output, namely that the output is sorted by prices, but the message again does not impose any. MMS does not consider this as a problem since the message does not care whether the output is sorted.

At this time, the service can execute and return results. The MMS receives these results returned from the service after the execution, translates them to global ontology terms, then translates them to the sending agent’s local ontology, and delivers them to the sending agent. We use KQML [8, 12] as an envelope to transmit messages among agents in a MAS. The results of executing the service become the content part of a KQML message.

3-3 Performance-Measuring IssuesIn this research, we follow the same methodology used in related work, namely

build test cases and try the system on them. We carefully choose and implement some real multi-agent systems described in the literature. We will use three collections of agents: two for comparison-shopping and one for meeting scheduling.

1- Comparison Shopping Agents [28]This collection will contain several agents, one buyer and at least two sellers. We

create agents working on different domains: one collection for PCs and one collection for Books. The buyer agent will assist its user to buy a PC (Book) with the least price. The buyer agent will provide a form for its user. The user uses this form to type in information such as maximum prices about the PC (Book). The buyer agent will send messages to all seller agents. When it receives all proposals, it compares them and displays the best deal for its user. We will implement the functional part of these agents. Agents’ local ontologies terms and services (services names, inputs, outputs, constraints) will be taken from real resources to avoid any kind of bias toward our work. The resources from which we take this information will be referenced.

7

2- Agent-based Meeting Scheduling [11] In this test system we will implement agents that are responsible for arranging meeting for their users. To make the ontologies realistic, graduate students in our research group at BYU will create their own scheduling information for agents in their own terms. They will provide their calendars and preferences and all relevant information. Knowing the preferences of their users, the agents will negotiate with one another to find the most acceptable meeting times. Figure 2 captures the essence of the system:

Figure 2: Agent-based meeting scheduling [11].

Using these collections of agents, we will measure the accuracy of three processes: 1) the translation process between the global ontology and an agent’s local ontology, 2) the matching process between messages and services, and 3) the over all performance of the MMS. For (1), let n be the number of all words in an agent’s local ontology, m (mn) be the number of the words that the MMS was able to translate, and c (cm) be the number of words that the MMS correctly translated. We compute the recall, R=c/n, the precision, P=c/m, and F-measure, F=(2+1)PR/(2P+R), where [0,1]. According to values of P, R, and F4, we determine the performance of the translation. The processes involved in (2) are: reordering input and output parameters (message-service), type conversions, format conversions, matching constraints on input and output parameters, and matching input and output parameters. Each time the MMS matches a message to a service these processes are invoked. We count the number of times that each process correctly does its job. The performance then measured by dividing that number by the number of the total invocations. As a further decomposition of these results, we can measure each process separately in the same way. The over all efficiency (3) will depend on the efficiency of the two other processes (1 and 2). In the overall efficiency, we have four possible outcomes, namely 1) a message and a service really match, and the MMS correctly matches them, 2) a message and a service do not match, and the MMS does not match them, 3) a message and a service really match, but the MMS decides that they do not match, and 4) a message and service do not really match, and the MMS

4 We are looking for values for P, R, and F to be very close to 100%.

8

wrongly matches them. We will determine the overall performance by computing the recall and precision. Let n be the number of all in-coming messages to an agent, m (mn) be the number of the messages that really match services, k (kn) be the number of messages that MMS matched with services, and c (ck) be the number of messages that the MMS correctly matched. We compute the recall, R=c/m and the precision, P=c/k, and F. values of P, R, and F will determine the performance.

4 Contribution to Computer ScienceThe research will provide a prototype software system for assisting developers of

agents to dynamically map in-coming query messages to appropriate capabilities. This can replace the current approach, which requires developers to manually register handler methods for each type of in-coming message. The major contribution, however, will be to allow agents to communicate with no assumption about shared ontologies, languages, or pre-agreed-upon message format. Establishing communication among agents without requiring them to share ontologies will be a step toward increasing the interoperability among heterogeneous agents and reducing the amount of work required of agent developers.

5 Delimitations of the thesis We make the following delimitations, leaving much for future work:1- As this research is restricted to query messages, we will not tackle other types of messages.2- No attempt will be made to deal with in-coming messages that do not provide sufficient values for the service input parameters.3- We will not provide partial answers for messages when a complete answer is not possible. 4- We will not tackle all translation problems (such as translations from other languages to English or where there are subtle shades of semantic meaning.)5- No effort will be made to deal with the issue of providing default services for answering messages that cannot map to any provided service.6- All agents should be cooperative and trust each other. Agents that do not have cooperative behavior and are not trustful are out of the scope of this research.7- We will not focus in this thesis on the architecture of the MAS (centralized or distributed).8- Recognizing that the security is a large issue in its own right, no work will be attempted to handle this issue.

6 Thesis Outline1- Introduction (2 Pages)2- Agents Theory (4 Pages)

2-1 Definitions2-2 Agent Software

2-2-1 Characterization of Agent Software2-2-2 Major Differences between Objects Software and Agents Software

3- Matching Issues (20 Pages)3-1 The Common Framework

9

3-2 Representing Methods and Messages3-3 Matching Methods3-4 The Matching Methods Performance

4- The Matchmaking System (12 Pages)4-1 Architecture of the System4-2 Implementation Issues

5- System Evaluation (10 Pages)5-1 Test Cases

5-1-1 Comparison Shopping Agents Systems5-1-2 Agent-Based Scheduling Task

5-2 Analysis Results5-3 Discussion and Limitations

6- Conclusions and Future Work (2 Pages)

7 Thesis Schedule The tentative schedule of the thesis will be as follows: Literature review December 2001 – October 2002Chapter 3 November 2002 – December 2002Chapter 4 December 2002 – January 2002Chapter 5 January 2002 – February 2003Chapters 1 & 2 & 6 February 2003 – March 2003Thesis Revision and Defense April 2003

8 References

[1] P. A. Bernstein and E. Rahm. A Survey of Approaches to Automatic Schema Matching. The VLDB Journal, Vol. 10, No.4, pp. 334-350. 2001.This paper has some means for translations between two schemas. We use them for translations between a local ontology and the global ontology.

[2] J. Biskup, D. W. Embley. Extracting Information from Heterogeneous Information Sources using Ontologically Specified Target Views. To appear in Information System, Vol. 28, No.1. 2003.This paper provides means such as type conversions and format conversions. We use these means to achieve conversions.

[3] J. M. Bradshaw. Software Agents. AAAI press, Menlo Park, California. 1997.This book contains fundamental papers about agents. It describes a wide range of basic concepts and implementations that are vital for all researchers in the agent computation area. It introduces the topics in an academic fashion but without being bogged down with the very low level details. This makes the book easy to read even for noncomputing professionals and comprehend the concepts.

10

[4] H. J. Charles and M. R. Cutkosky. JATLite: A Java Agent Infrastructure with Message Routing. IEEE Internet Computing ,Vol.4, No.2, pp. 87-96. March-April 2000.This paper provides some java tools to help in writing software agents. [5] D. W. Embley and D. Jackman, and L. Xu. Multifaceted Exploitation of Metadata for Attribute Discovery in Information Integration. Proceedings of the Integration International Workshop on Information Integration on the Web (WIIW01), Vol.3, No.8, pp. 110-117, Rio de Janeiro, Brazil. April 2001.This paper provides means for schema matching. We use these means to help translate between the global ontology and an agent local ontology.

[6] D. W. Embley and L. Xu. Discovering Direct and Indirect Matches for Schema Elements. (Submitted for Publication- see http://www.deg.byu.edu/papers). 2002.This paper provides means to detect relationship among objects. We use these means to help in relating terms to their objects.

[7] T. Finn, D. McKay and R. McEntire. KQML as an Agent Communication Language. Proceedings of the 3rd International Conference on Information and Knowledge Management, ACM Press, Vol.1, No.2, pp. 456-463. November 1994.This paper Provides a rich bases for the components of KQML and how these components interact with each other to achieve the desired function. It gives also some examples of communications using KQML as ACL.

[8] T. Finn, Y. Labrou, and J. Mayfield. KQML as an Agent Communication Language. Chapter 14, pp. 291-316. Software Agents. J. M. Bradshaw (ed.). AAAI Press, Menlo Park, California. 1997.This chapter contains fundamental information about agents’ communication language, KQML. KQML as a language and protocol is of special importance for this thesis.

[9] M. Genesereth and S. Ketchpel. Software Agents. Communications of the ACM, Vol.37, No.7, pp. 48-53. July 1994.This paper provides details about agent software. It answers important questions such as: What are the appropriate agent communication languages, how we build agents that are capable of communicating using these languages, and what communication “architectures” are conducive to cooperation.

[10] N. R. Jennings. An Agent-Based Approach for Building Complex Software Systems. Communications of the ACM, Vol.16, No.2, pp. 35-41. April 2001.This paper provides information about using agents for building complex software. In addition, it provides information about the merits of agent-oriented decomposition for complex tasks.

[11] N. R. Jennings and A. J. Jackson. Agent-Based Meeting Scheduling: A Design and Implementation. IEEE Electronics Letters Journal, Vol. 31, No.5, pp. 350-352. March

11

1995.This paper contains a design and implementation for agents that we are going to use for testing the system.

[12] Y. Labrou. Semantics for an Agent Communication Language KQML. PhD Dissertation, University of Maryland. 1997.This PhD Dissertation provides information about the syntax and semantics of the KQML communication language. In addition, it describes the interaction between the API (Application Programming Interface) and the application.

[13] Y. Labrou and T. Finn. Comments on the Specification for FIPA Agent Communication Language. Technical Report, University of Maryland, Baltimore Maryland. February 28, 1997. This technical report contains comments on FIPA (Foundation for Intelligent Physical Agents). This paper particularly helps in gaining a better understanding of the nature of the communication languages.

[14] J. Lind. Issues in Agent-Oriented Software Engineering. Proceedings of the First International Workshop On Agent-Oriented Software Engineering (AOSE-2000), pp. 45-58. 2000.This paper provides very important information about the characterizations of agent software engineering. It gives a mapping between concepts of agent’s software and object’s software.

[15] S.E. Madnick , H. Lu, W. Fan, C. Goh, and D. Cheung. Discovering and Reconciling Value Conflicts for Numerical Data Integration. Information Systems, Vol.26, No.8, pp. 635- 656. December 2001.This paper provides bases for numerical data conversions.

[16] S.E. Madnick and M. Siegel. A Metadata Approach to Resolving Semantics Conflicts. Proceedings of the 17th International Conference on Very Large Database, Vol.14, No.13, pp.133-145, Barcelona, Spain. September 3-6, 1991.This paper provides the bases for discovering attributes that are semantically the same. we use these bases to help translate between the global ontology and an agent’s local ontology.

[17] N. F. Noy and D. L. McGuinness. Ontology Development 101: A Guide to Creating your First Ontology. Technical Report, Stanford University, Palo Alto, California. 1994.This technical report provides us with the bases for developing ontologies. How we measure the efficiency of the ontologies.

[18] T. R. Payne, M. Paolucci, R. Singh and K. Sycara. Facilitating Message Exchange through Middle Agent. ACM press, pp. 561-562. 2002.

12

This paper provides information about the matching between messages and agent’s capabilities. It shades some light on a concept that is very important nowadays, peer-peer communication.

[19] S. Pearson, C. Priest, T. Dahl and E. de Kroon. An Agent-Based Approach to Task Allocation in Computer Support Team. In Proceedings of The Practical Application of Intelligent Agents and Multi-Agent Technology (PAAM'97), pp.365-379, London, UK. April 1997.This paper contains a rich design and implementation for one of the multi-agent systems that we are going to use for testing of the system.

[20] J. Pitt, A. Mamdani. Designing Agent Communication Language for Multi- Agent Systems. Proceedings of the 9th European Workshop On Modeling Autonomous Agents In A Multi-Agent Worlds, pp.102-114, Valencia, Spain. June- July 1999.This paper contains information about designing agent communication languages for multi-agent systems. It introduces a method for designing ACL for a particular application.

[21] E. Sciore, M. Siegel, and A. Rosenthal. Using Semantic Values to Facilitate Interoperability among Heterogeneous Information Systems. ACM Transactions on Database Systems, Vol. 19, No. 2, pp. 254-290. June 1994.This paper provides bases for translations from one context to another.

[22] H. Stuckenschmidt, I. J. Timm. Adapting Communication Vocabularies using Shared Ontologies. Proceedings of the 1st International Joint Conference on Autonomous Agents and Multi-Agent Systems, Bologna, Italy. 15-19 July, 2002This paper contains portion of the information that we need for supporting communication between agents without assumed shared ontology.

[23] K. Sycara, M. Klusch, S. Widoff, and J. Lu. Dynamic Services Matchmaking among Agents in Open Information Environments. SIGMOD Record, Vol.28, No.1, pp. 47-53. 1999.This paper contains methods that show how agents’ services can be mapped to messages with assumption that agents share ontologies (not real message but templates. It provides some good strategies to achieve such mapping. We use some of the strategies described in it.

[24] A. Tveit. Jfipa - An Architecture for Agent-Based Grid Computing. In Proceedings of the Artificial Intelligence and the Simulation of Behavior Convention, Symposium on AI and Grid Computing, London, U K. April 2002This paper contains information about a specific agent architecture (Agent-based grid computation). It offers some tools for building agent software that speaks FIPA.

[25] A. Tveit. A Survey of Agent-Oriented Software Engineering. NTNU Computer Science Graduate Student Conference, Report, Norwegian University of Science and

13

Technology. May 2001.This paper provides information about agent-oriented software engineering, the methods used to develop agents, and give a comparison between agents and objects.

[26] M. F. Wood and S. A. DeLoach. An Overview of the Multi-Agent Systems Engineering Methodology. In Agent-Oriented Software Engineering- Proceeding of the First International Workshop on Agent-Oriented Software Engineering, Vol.13, No.3, pp. 207-222, Berlin, Germany. June 10, 2000.This paper contains a methodology that describes how to build multi-agent software from the specification till the implementation level. We use it in the research to help build the test agents.

[27] M. Wooldridge and A. Lomuscio. Reasoning about Visibility, Perception, and Knowledge. The 6th International Workshop, pp.1-12, Orland, Florida, USA. 1999.This paper provides theoretical bases for agent architecture.

[28] Reticular Systems, Inc. San Diego, California. AgentBuilder, an Integrated Toolkit for Constructing Intelligent Agents “Reference Manual “ Version 1.3. April 11, 2000. More information is available at http://www.agentbuilder.com.This manual provides tools for building agents that are capable of communicating in KQML language. It defines some important aspects such as Multi-thread software, protocols, ontologies, etc. It also gives some practical agent examples such as buyer-seller agents, which we use for testing the system.

[29] JACK Intelligent Agents, Available At: http://www.agent- software.com.au/shared/homeThis website gives information about tools that help build agents that speak FIPA. [30] KQML Developers. Software user's manual prepared for United States Air Force, versions 1.8 and 1.95. March 1995.This document shades some light on how to integrate an application and make it agent that speaks KQML. It provides a guide for the application programmer to how to handle the coming messages by providing function handlers that handle each coming message.

[31] Specification of the KQML Agent-Communication Language - plus example Agent Policies and Architectures. By the DARPA Knowledge Sharing Initiative External Interfaces Working Group.This document is relevant to the research as it gives specifications of KQML, the communication language that we use for transmitting messages among agents.

9 Artifacts The written thesis Two multi-agent system for the test purposes The matchmaking system A demonstration program

All programs are to be written in Java.

14

10 Signatures

This proposal by Muhammed Al-Muhammed is accepted in its present form by the Department of Computer Science of Brigham Young University as satisfying the proposal requirement for the degree of Master of Science.

Date: _______________________ David W. Embley, Committee Chairman

Date: _______________________ Michael Goodrich, Committee Member

Date: _______________________ Bryan Morse, Committee Member

Date: _______________________ David W. Embley, Graduate Coordinator

15

16