Proceedings of the 8th International Conference on Business Information Systems (BIS)

Poznan, Poland, April 20-22 2005

Ontology-Driven Decision Making in Transportation Transactions Management

Alexios Lasanas, Christina E. Evangelou and Nikos Karacapilidis

Ontology-Driven Decision Making in Transportation

Transactions Management

Alexios Lasanas, Christina E. Evangelou and Nikos Karacapilidis

Industrial Management and Information Systems Lab

MEAD, University of Patras

26500 Rio Patras, Greece

Email:{alexlas, chriseva, nikos}@mech.upatras.gr

Abstract: This paper presents an ontology-driven, multi-agent system that addresses a

series of decision making issues arising in the management of freight transportation

transactions. The proposed system can be employed for the automatic formulation of

alternative transportation routes, as well as their evaluation through a dynamic

consideration of the available carriers’ services and the customer’s profile and

preferences. Its underlying ontology model is based on semantics extracted from the

freight transportation literature and interviews with potential users, and provides the

means to efficiently accomplish tasks related to information modelling and sharing,

communication between the parties involved, and coordination of activities that support

the underlying decision making.

Keywords: Ontologies for Business Information Systems, Internet services, Decision

Making, Intelligent Agents, AHP.

1. Introduction

Aiming at aiding individuals and companies meet their needs in the most efficient way, freight

transportation management involves a series of decision making processes on issues such as carrier

and route selection, shipment scheduling, and cost accounting (Tilanus, 1997). The complexity of

these issues stems basically from the multitude of the transportation means offered and the variety of

the transportation transactions requested by customers. More specifically, the former refers to the

available transportation means with regard to their capacity and itineraries, while the latter to the

customers’ preferences and constraints with respect to multiple criteria, such as cost, loading and

delivery dates, or even cargo safety and carrier’s dependability. The frequent need of finding a

modular transportation solution, that is one that fragments the itinerary requested to a set of sub-

routes that may involve different transportation means (trains, trucks, ships, airplanes, etc.),

aggravates further the above complexity.

At the same time, efficient transportation management usually involves extensive communication

among the parties involved, and requires well-developed strategies for the coordination of the

underlying transactions. Towards this end, and taking into account the requirements imposed by the

2

global market, the need for Information Technology support is ubiquitous. Computer-based

applications offering freighting and fleet scheduling services in international transportation networks

are limited and can be classified under two broad categories. The first one includes some web-based

approaches that merely offer the interested customers the ability to register their transportation

request, which is then handled in the traditional way. Applications falling in this category are, among

others, the Spitrans Brokering Inc. (http://www.spitrans.com), the CargoWorld Inc. (see,

http://www.cargoboss.com.hk/about_cargoworld.htm), and the Global Book Agents Network (see,

http://www.globalbook.net/quote.html). The second category comprises a limited number of web-

based or windows-based Transportation Management Systems (TMSs), which aim at better serving

the needs of various parties involved in the related transactions. These systems are often parts of

enterprise-wide logistics solutions that consist of modules serving a diversity of associated needs,

such as supply chain management, invoicing, and accounting. Representative applications of this

category are Cadence TMS (http://www.cadretech.com), E.R.T. TMS

(http://www.ertsoftware.com), and LoadMaster (http:/www.mcleodsoftware.com).

A basic disadvantage of the above systems is the requirement for extensive human interference in the

cargo freighting process, in that an expert should be responsible for the management of critical

issues, such as carrier selection, delivery date matching, route planning, and transportation pricing.

Furthermore, the above applications are characterized by a limited ability in providing optimal or

suboptimal solutions, as far as the transportation’s cost and duration are concerned. Their route

planning procedure does not involve a detailed consideration of modular solutions, as far as

alternative carriers or alternative paths are concerned, in that it is based on a customer’s request about

a specific direct route. Moreover, the matching of a customer’s request with the appropriate carriers

is based on data extracted from static databases. Generally speaking, these systems do not offer

adequate automation of the problem’s solution, while they do not guarantee any optimization of

critical factors such as the transportation’s duration, cost and route selected.

To remedy these problems, this paper presents a multi-agent system that efficiently addresses the

multiplicity and complexity of the issues involved in freight transportation management, paying

particular attention to decision making processes concerning the formulation and evaluation of

alternative transportation routes with respect to the customers’ preferences. Our approach has been

based on the specification of the appropriate ontology model for the setting under consideration. It is

based on flexible models that achieve efficient communication among all parties involved and

coordinate the overall process. The agents of the proposed system represent and act for any user

involved in a transportation scenario, while they cooperate and get the related information in real-

time mode.

The remainder of the paper is structured as follows. Section 2 describes our overall approach and

highlights issues related to the proposed system’s implementation and interaction features. Section 3

3

presents the underlying ontology model. Section 4 discusses decision making issues concerning the

formulation of alternative solutions and their evaluation with respect to the customer’s profile and

preferences. Section 5 concludes by making final remarks and listing directions for future work.

2. The overall approach

Existing web sites providing transportation management services are essentially static, while the

interaction among all parties involved is performed by humans. However, recent developments in the

areas of Web Services, Grid Computing and P2P networks, as well as the growing interest in the

establishment of e-Business standards, make the management of a complex system’s interactions

more and more efficient (Willmott et al., 2002). Multi-agent systems, in particular, can be used to

solve complex problems, as groups of different types of agents set up efficient and effective ways of

communication (Sycara and Zeng, 1996). Such systems have been successfully used to address a

variety of real world business problems, such as business process management (Jennings et al.,

2000), supply chain management (Fox et al., 2000), and dynamic manufacturing scheduling (Shen

and Norrie, 1998). In our approach, we exploit multi-agent technologies to provide services of high

standard, while paying much attention to the users’ needs and preferences.

The development of the proposed web-based system for the management of transportation

transactions is ontology-driven. The use of a properly defined ontology for the development of our

system is expected to result in building an intelligent application that works more accurately in the

human conceptual level (Chandrasekaran et al., 1999). Towards this aim, our primary task was to

specify the appropriate ontology model for the specific context. Beyond the identification and

interrelation of the underlying entities and types of users involved, this task had to consider

communication and coordination issues, as well as the decision making features we intended to

integrate in our approach. Such features concern the automatic search, formulation and evaluation of

alternative shipping options, by taking into account the customers’ preferences and constraints, as

well as the available services of the carriers.

2.1 Implementation Issues

As shown in Figure 1, the management of transportation transactions in our approach is carried out

by a series of software agents that autonomously perform predefined activities (based on rules and

procedures coded into their behaviour) and cooperate upon well-specified business models. The

involved parties (i.e., customers and transport companies) may register to the system through secure

connections and specify their profiles (as far as companies are concerned, this task includes the

registration of the itineraries offered, the capacity of the available fleet, etc.). Customers may also

register their requests about a particular shipping of goods and check for alternative solutions to

satisfy them. The Customer and Carrier agents involved in the proposed system represent and act on

4

behalf of the above two basic types of users involved in a transportation scenario, that is, for

customers looking for the appropriate way to ship their products, and for transportation companies

that may (fully or partially) carry out such requests. To accomplish these tasks, they cooperate with

three special-purpose agents, namely the Broker, the Itinerary_Builder and the Decision_Maker, which

manage the related transportation transactions by coordinating request and offers, formulating

possible alternative solutions and supporting the required decision-making, respectively.

Figure 1: The proposed system’s architecture

In the implementation of our approach, we have exploited a series of technologies supported by the

Microsoft’s .NET platform, such as ADO.NET, XML Web Services, multithreading, message

queuing, and object serialization (all of them are components of Visual J#.NET, see

http://www.microsoft.com/net). All messages exchanged between agents are FIPA (Foundation

for Intelligent Physical Agents, see http://www.fipa.org) compliant and use the ACL (Agent

Communication Language) Message Structure Specification (see

http://www.fipa.org/specs/fipa00061/SC00061G.pdf). The proper definition of these messages

is very important, since it determines (among others) the responding actions of an agent’s behaviour

and the way of agents’ communication. According to the communication protocols specified, agents

exchange each time the appropriate ACL messages. The population of customers and carriers

databases is performed through user-friendly interfaces.

5

2.2 Interacting with the customer

The system implemented, namely FTMarket (Freight Transportation Market), provides users with the

appropriate interfaces to register their profiles (stands for both customers and carriers), services

offered (stands for carriers) and requests (stands for customers). Registration of profiles serves the

gathering of basic information, such as personal and contact details, and billing preferences. Profiles

can be updated at any time, upon the user’s request. In the case of customers, the system also

maintains information about the frequency and type of services requested.

Figure 2: Request of a transaction: Transaction details and selection of transportation plan.

In the context of this paper, we focus on the system’s features and functionalities concerning the

interaction between a customer and the system in the case that the former submits a request for a

transportation transaction. After registration, the customer may request a freight transportation

transaction through the interface shown in Figure 2. By doing so, the customer submits a set of

“primary preferences”, corresponding to the desired loading and delivery places and dates, freight

quantity, and maximum cost and duration of the transaction. In addition, he/she may select the

“transportation plan” preferred for the specific transaction. In the current version of the system, the

options offered at this point are Economy, Express, Safe, Dependable and User Defined

transportation plans. Each of these plans actually associates different weights to the criteria used in

the corresponding evaluation of solutions, namely cost, duration, safety level and dependability level.

The weights associated to the first four plans are predefined. It should be noted here that the set of

criteria used and their weights as far as the first four plans are concerned came out of a series of

interviews conducted with potential users of the system, who were already experienced in the

management of freight transportation transactions. The rationale behind the definition of these plans

6

is that in most cases customers seek for automated and fast solutions, since they may have not the

time or expertise required to define precisely their needs and preferences. Moreover, the interviews

conducted revealed that the above plans reflect the most widely used parameters and can efficiently

support the underlying decision making processes. The selection of the fifth option (User Defined

transportation plan) obliges the customer to put in (implicitly, see Section 4.2) his/her own weights

for the above set of criteria.

The interface shown in Figure 2 corresponds to the first step of submitting a transportation request. In

the second one (a similar interface appears by clicking on the “Next” button of Figure 2), the

customer may define a set of “special requirements” that portray his/her preferences as far as the

freight’s characteristics (volume, weight, parcelling, etc.), type (liquid, fragile, etc.) and shipping

conditions (temperature, pressure, etc.) are concerned.

Figure 3: Candidate solutions for a specific transportation request.

After the specification of all these preferences, FTMarket is able to formulate and evaluate

alternative transportation solutions. Through a set of procedures described in detail in Section 4, it

constructs a set of solutions that satisfy the customer’s requirements and ranks them appropriately

(see Figure 3). At this point, the customer may either select a candidate solution or go back to the

transaction request step, modify the previously inserted requirements, and consider the corresponding

(new) set of solutions. As shown in Figure 3, the solutions constructed may be either direct or

modular (in the second case, and by clicking on the link provided, the customer is able to view the

detailed path and the carrier that has been associated to each part of it).

7

3. The Underlying Ontology Model

Ontologies are bound to become the backbone of the emerging Semantic Web technologies in the

years to come (Vatant, 2004). This is because they serve as a way of representing the semantics of

documents and enabling these semantics to be used by web applications and intelligent agents. On

the other hand, they are a means to accomplish a shared understanding of different knowledge

domains and allow for sharing and reuse of bodies of knowledge across groups and applications

(Duineveld et al., 2000). They are usually expressed in a logic-based language, so that detailed,

accurate and consistent distinctions can be made among their constituent entities. Following the

object-oriented paradigm, an ontology may comprise classes (general things), instances (particular

things), relationships among these things, properties and property values of the above, as well as

functions, processes, constraints and rules (Daconta et al., 2003). At the same time, different formats

and technologies have been used so far to construct ontologies. The Resource Description

Framework (RDF) and RDF Schema (RDFS) constitute a general-purpose language for representing

information on the Web, based on the XML syntax (Brickley and Guha, 1999). DAML+OIL and the

Web Ontology Language (OWL) are the two most prominent semantic markup languages providing

additional vocabulary to the RDF and RDFS, along with formal semantics for defining and

instantiating Web ontologies (Horrocks and van Harmelen, 2001; W3C, 2004).

Ontologies range from the simple notion of a taxonomy to a thesaurus, a conceptual model, or a

logical theory. In this vain, ontologies related to the transportation management domain vary from

comprehensive transportation glossaries such as TheEyeForTransport glossary (see

http://www.eyefortransport.com/glossary/op.shtml) to more complex ontology models (see,

for instance, http://opencyc.sourceforge.net/daml/cyc.daml). The above ontologies do not

cover efficiently the transactions aspect of transportation management, nor they provide a detailed

analysis of a transportation plan. Moreover, they do not describe the potential customers’ needs at the

desired level of detail.

The ontology model developed for our purposes, namely TM-DM (Transportation Management

Decision Making), was formally defined with the use of the XML technologies for interoperable,

generic, extensible and neutral information modelling that provides the semantic means to specify

diverse knowledge domains and achieve a common understanding. Furthermore, it complies with the

OWL language semantics, striving for maximum machine interpretability of Web content. For the

construction of the proposed ontology model, we used Protégé 3.0 Beta (available online at

http://protege.stanford.edu), an ontology editor that can read directly in the OWL format and

provides a user friendly graphic interface. Furthermore, the Altova XML Spy editor has been used in

order to formulate an XML Schema that depicts the ontology’s main features. The design of the

communication and coordination protocols of the various types of agents involved in our system was

8

based on the above model. The TM-DM ontology model is based on semantics extracted after a

thorough study of the related literature and through a series of interviews conducted with experts in

transportation management. The backbone of TM-DM consists of three main classes (see Figure 4):

Figure 4: The basic structure of TM-DM ontology model.

9

■ The Freight class refers to the characteristics, type and shipping conditions of the freight to

be transported, which are explicitly defined by the customer (Section 2.2).

■ The InvolvedParties class conveys information about the customer and carrier(s) involved in

a transportation transaction; thus, it comprises the CustomerProfile and CarrierProfile

subclasses. The CustomerProfile subclass consists of the customer’s personal and contact

information, as well as his/her billing preferences. Furthermore, it contains information

related to the frequency and type of services requested in the past. In a similar vein, the

CarrierProfile subclass comprises the carrier’s contact information, available itineraries and

billing policy. Moreover, this subclass maintains information about past transactions carried

out by the specific carrier, as well as the carrier’s dependability indicator.

■ The TransportationService class comprises information related to the transportation services

provided, such as the transportation plan type on which it is based, the related criteria and

their weights, itineraries, and shipping conditions.

The decision making processes concerning the construction of the alternative transportation solutions

and the matching of them with the customer’s preferences and the carriers’ available services is

discussed in the following section.

4. Decision Making Issues

Each time a customer puts in a request for freight transportation, the system’s agents cooperate

aiming at satisfying it. The related decision making processes fall into two distinct phases concerning

the formulation of all possible alternative solutions and their evaluation in order to decide which one

meets best the customer’s requirements.

4.1 Formulation of alternative solutions

Let a customer intending to transport a specific freight from place A to place B. In case that one or

more direct transportation routes exist, these are automatically considered as alternative solutions to

be evaluated. Moreover, modular transportation solutions are constructed if possible (these solutions

fragment the intended itinerary to a set of sub-routes). Modular solutions may prove to be better than

the direct ones, and cover cases where there is no transportation company acting directly between the

loading and delivery places. It is noted that carriers may be associated with diverse transportation

means, thus a series of additional implications (concerning issues such as the freight’s parcelling and

the safety level of the transportation means) may arise.

Formally speaking, the above problem can be expressed as follows: Let a graph G={V, A}, where V

is the set of vertices (representing loading/delivery terminals) and A the set of arcs joining them. If

each arc aij is associated with a transportation cost cij and a time distance dij, find the minimum total

10

cost CSE

opt for the transportation of products from a vertex S to a vertex E within a given time frame

(up to Tmax). Exploiting well-established Operations Research approaches for the solution of the

shortest route problem (Shapiro, 1979), an iterative algorithm has been developed to address the

above problem. The proposed algorithm was based on the minimization of only two parameters, the

transportation’s duration and cost, for surpassing complexity issues and minimisation of the time

required for retrieving alternative solutions. The following algorithm, presented in the form of

pseudocode, has been employed for the alternative solutions’ formulation:

Step 1: /* Searching for direct routes. These routes are sorted according to their cost (primary

criterion) and duration */

Retrieve all direct Routes (Loading_term, Delivery_term, cij, dij) from vertex S to

vertex E;

Sort Routes by cij then by dij;

Set Routeopt = {min(cSE), dSE ≤ Tmax};

If ∃ route with dij ≤ Tmax then set Tmax = min(dSE);

Go to Step 2;

Step 2: /* Searching for modular solutions that are either better than a direct one found in Step 1 or

satisfy the customer’s requests */

Retrieve all RouteArcij(i, j, cij, dij) in RouteSE ;

Sort RouteArcij by cij then by dij;

Set copt = min(c’ij, c”ij, …);

Go to Step 3;

Step 3: /* Using the shortest route algorithm and by taking into account the best solutions found in

Step 2 for each segment of the route, we calculate each modular solution’s total cost and duration */

for each modular solution

{use shortest route algorithm to find the minimum cij ;

if (cSE ≤ Cmax ∧ dSE ≤ Tmax) then {

Routeopt = RouteSE ;

exit;}

else if (cSE > Cmax ∨ dSE > Tmax ) then copt =Cmax ;}

Go to Step 4;

Step 4: /* Each route arc found in the modular route constructed above is replaced by alternatives

having a shorter duration. For each such replacement, we calculate the associated cost increment

and we sort the route arcs accordingly */

for each modular solution

{∀ RouteArcij ∈ RouteSE

opt

find the cost increment dc’ij = c”ij – c’ij for every dij reduction;

Sort RouteArcij by dc’ij;}

11

Go to Step 5;

Step 5: /* Considering the sorted route arcs list for each segment (taking into account the solution

with the less cost increment for each segment), we calculate the total cost of the corresponding

modular solution */

for each modular solution

{for each segment

{∀ cij ∈ RouteArcij

set cij = min(dc’ij)};

if (d’SE ≤ Tmax ∧ c’SE ≤ Cmax) then {

RouteSE

opt found;

exit;}

else if (c’SE ≤ Cmax ∧ d’SE > Tmax) go to Step 6;}

Step 6: /* We repeat the cost substitution procedure performed in the previous step by considering

alternative route arcs for each segment (successive solutions from the sorted route arcs lists), until

the duration and cost of the corresponding modular solutions are less than the time and cost upper

bounds, respectively */

for each modular solution

{for each segment

{repeat

{consider the next min(dcij) increment;

if (d’SE ≤ Tmax ∧ c’SE ≤ Cmax) then {

RouteSE

opt found;

exit;}}

until (d’SE ≤ Tmax ∧ c’ij ≤ Cmax )};

if (c’SE > Cmax ∨ d’SE > Tmax) then no solution;}

4.2 Evaluation of alternative solutions

Having constructed all possible transportation solutions, our approach proceeds to the evaluation

phase, which is customized according to the specific customer’s needs and preferences. In this phase,

the Decision_Maker agent performs two distinct tasks. Firstly, a refinement of the set of alternative

solutions constructed takes place, by excluding solutions that do not comply with the customer’s

requirements (as stated above, the algorithm developed for the construction of alternative routes takes

into account only the duration and cost parameters). In this phase, a set of predefined rules are

employed to exclude the alternative solutions that do not respond to the specific freight

transportation’s requirements and customer preferences. For instance, if the customer had chosen the

“safe” transportation plan, the following set of rules would apply:

12

for each constructed_solution {

if (safety level < AVERAGE) OR ((safety_level == AVERAGE) AND (dependability_level

< LOW)) then discard constructed_solution;

else if (safety_level >= HIGH) OR ((safety_level == AVERAGE) AND

(dependability_level >= LOW)) then candidate_solution � constructed_solution;}

A similar process is followed as far as the “special requirements” are concerned; solutions that do not

satisfy them are also discarded.

The next task performed by the Decision_Maker agent concerns the comparative evaluation of the

candidate solutions. For the processes described in this paper, we employ the Analytical Hierarchy

Process (AHP) aggregation methods (Saaty, 1980) to calculate the overall priorities for each solution

and determine their final ranking. As noted above, our approach takes into account four criteria,

namely cost, duration, safety_level and dependability_level, to reach a decision. The evaluation

scales of the above criteria are numerical for the first two (in euros and days, respectively) and

qualitative for the last two (values permitted are in the set {very_low, low, average, high,

very_high}). The preferences regarding the above criteria have fixed values for the Economic,

Express, Safe and Dependable transportation plans. In the case of the User Defined transportation

plan, preferences regarding the evaluation criteria are defined by the user, in the form of dual

comparisons. The final outcome of the evaluation phase is the complete ranking of the candidate

solutions.

5. Summary

We have presented an ontology-driven and agent-based approach for the facilitation of the decision

making processes involved in the management of freight transportation transactions. The formulation

and evaluation of alternative transportation plans is performed through a dynamic consideration of

the available carriers’ services and the customer’s profile and preferences. Much attention has been

paid to the system’s extensibility in order to easily integrate additional features and functionalities.

For instance, the inclusion of additional criteria and transportation plan types, as well as alternative

evaluation mechanisms, is straightforward. Being based on a properly defined ontology for the

domain under consideration, our approach is able to reflect the human conceptual level more

accurately. The exploitation of .NET technologies contributes further to the above issues and ensures

a high standard of communication and collaboration among all parties involved (humans and

software agents).

A future work direction concerns the more detailed association of the proposed ontology model with

the software agents’ services, in the context of Web Services and Semantic Web (Daconta et al.,

2003; Davies et al., 2003; Newcomer, 2002), the aim being to enhance our system’s functionalities

13

through the communication with other applications. A related direction concerns ontology

management, in case that these applications are built on properly defined ontology models. Finally,

work is planned towards considering alternative ways of coordination among customers and carriers

in the setting under consideration. More specifically, we intend to investigate the proposed system’s

performance when alternative types of middle-agents (Guttman et al., 1998; Klusch and Sycara,

2001) undertake pieces of the matching processes required to satisfy the customers’ needs.

Acknowledgements

The last two authors thank European Social Fund (ESF), Operational Program for Educational and

Vocational Training II (EPEAEK II), and particularly the Program HERAKLEITOS, for funding the

above work.

References

Brickley, D. and Guha, R.V. (1999). Resource Description Framework (RDF) Schema Specification. Proposed

Recommendation. The World Wide Web Consortium. Available online: http://www.w3.org/TR/PR-rdf-

schema.

Chandrasekaran, B., Josepheson, J. and Benjamins, V.R. (1999). Ontologies: What Are They? Why Do We

Need Them? IEEE Intelligent Systems, 14(1), 20-26.

Daconta, M.C., Obrst, L.J. and Smith, K.T. (2003). The Semantic Web: A Guide to the Future of XML, Web

Services, and Knowledge Management. Wiley Publishing, Indianapolis, IN.

Davies, J., Fensel, D. and van Harmelen, F. (2003). Towards the Semantic Web: Ontology-Driven Knowledge

Management. John Wiley & Sons, Chichester, UK.

Duineveld, A.J., Stoter, R., Weiden, M.R., Kenepa, B. and Benjamins, V.R. (2000). WonderTools? A

Comparative Study of Ontological Engineering Tools. International Journal of Human-Computer Studies, 52,

1111-1133.

Fox, M.S., Barbuceanu, M. and Teigen, R. (2000). Agent-Oriented Supply-Chain Management. International

Journal of Flexible Manufacturing Systems 12(2/3), 165-188.

Guttman, R., Moukas, A. and Maes, P. (1998). Agents as Mediators in Electronic Commerce. Electronic

Markets 8(1), 22-27.

Horrocks, I., and van Harmelen, F. (2001). Reference Description of the DAML+OIL (March 2001) Ontology

Markup Language. Technical report. Available online: http://www.daml.org/2001/03/reference.html.

Jennings, N., Faratin, P. Norman, T.J., O'Brien, P. and Odgers, B. (2000). Autonomous Agents for Business

Process Management. International Journal of Applied Artificial Intelligence 14(2), 145-189.

14

Klusch, M. and Sycara, K. (2001). Brokering and Matchmaking for Coordination of Agent Societies: A Survey.

In A. Omicini et al. (Eds.), Coordination of Internet Agents: Models, Technologies, and Applications, Springer,

197-224.

Newcomer, E. (2002). Understanding Web Services: XML, WSDL, SOAP, and UDDI. Addison-Wesley,

Boston, MA.

Saaty, T.L. (1980). The Analytical Hierarchy Process. McGraw-Hill, New York, NY.

Shapiro F.J. (1979). Mathematical Programming: Structures and Algorithms. John Wiley & Sons, New York.

Shen W. and Norrie, D.H. (1998). An Agent-Based Approach for Dynamic Manufacturing Scheduling. In

Proceedings of Autonomous Agents '98 Workshop on Agent-Based Manufacturing, Minneapolis/St. Paul, MN,

117-128.

Sycara, K. and Zeng, D. (1996). Coordination of Multiple Intelligent Software Agents. International Journal of

Cooperative Information Systems 5(2-3), 181-212.

Tilanus, B. (1997). Information Systems in Logistics and Transportation. Elsevier Science & Technology

Books, Oxford, UK.

Vatant, B. (2004). Ontology-Driven Topic Maps. In Proceedings of the XML Europe 2004, Amsterdam,

Netherlands, 18-21 April.

W3C (2004). The Web Ontology Language. Available online: http://www.w3.org/2004/OWL/.

Willmott, S., O’Brien, P., Thompson, S., Cortes, U., Charlton. P., Bonnefoy, D., Girenko, A., Klusch, M. and

Luck, M. (2002). iNet: Large-Scale Intelligent Open Service Environments. Available online:

http://www.agentlink.org/fp6/docs/agentcities-inet_eoi-response_07.06.02b.pdf.