Ontology-driven coordination model for multiagent ... - Springer Link

Appl Intell (2012) 36:768–787 DOI 10.1007/s10489-011-0294-z

Ontology-driven coordination model for multiagent-based mobile workforce brokering systems Arash Mousavi · M. Jan Nordin · Zulaiha Ali Othman

Published online: 19 April 2011 © Springer Science+Business Media, LLC 2011

Abstract Coordination has been recognized by many researchers as the most important feature of multi-agent systems. Coordination is defined as managing interdependencies amongst activities (Malone and Crowston in ACM Comput. Surv. 26(1):87–119, 1994). The traditional approach of implementing a coordination mechanism is to hard-wire it into a coordination system at design time. However, in dynamic and open environments, many attributes of the system cannot be accurately identified at the design time. Therefore, dynamic coordination, capable of coordinating activities at run-time, has emerged. On the other hand, a successful dynamic coordination model for multi-agent systems requires knowledge sharing as well as common vocabulary. Therefore, an ontological approach is an appropriate way in proposing dynamic coordination models for multiagent systems. In this paper, an Ontology-Driven Dynamic Coordination Model (O-DC) for Multiagent-Based Mobile Workforce Brokering Systems (MWBS) (Mousavi et al. in Int. J. Comput. Sci. 6:(5):557–565, 2010; Mousavi et al. in Proceedings of 4th IEEE international symposium on information technology, ITSim’10, Kuala Lumpur, Malaysia, 15–17 June 2010, vol. 3, pp. 1416–1421, 2010; Mousavi and Nordin in Proceedings of the IEEE international conference on electrical engineering and informatics, Bandung, Indonesia, 17–19 June 2007, pp. 294–297, 2007) is proposed and formulated. Subsequently, the applicability of ODC is examined via simulation based on a real-world scenario. A. Mousavi () · M.J. Nordin · Z.A. Othman School of Computer Science, Faculty of Information Science and Technology, University Kebangsaan Malaysia, 43600, Bangi, Malaysia e-mail: [email protected]

Keywords Dynamic coordination · Ontology · Multi-agent systems · Mobile workforce management system · Mobile workforce brokering system

1 Introduction Coordination plays a vital role in open distributed systems where several different processes act concurrently and interdependably in a dynamic environment to achieve common goals. Therefore, the main objective of this paper is to describe how such an effective and ontology-driven dynamic coordination model can be modeled, formulated and implemented. For this reason, we believe that selecting a domain of discourse, which exhibits the common characteristics of a typical open distributed system such as openness, diversity and concurrency is an appropriate approach to achieve the aforementioned objective. An example of such an open distributed system is Mobile Workforce Brokering System (MWBS), an essential component of every Mobile Workforce Management Systems (MWM) [1]. MWBS In essence has to manage a diverse range of mobile workforces who are distributed in different geographical locations and may use different types of mobile devices in a concurrent manner. Moreover, MWBS has to deal with other open systems within the body of its MWM. Therefore, MWBS is a fitting example of open distributed systems. We have selected MWBS as our domain of discussion for three major reasons. First of all, MWBS is a system that has to be situated in a dynamic, unpredictable and uncertain environment (mobile environments) and therefore, it has to address certain risks. Next, MWBS comprises distributed processes (individual entities) that have to coordinate with each other in order to achieve a set of common goals. Finally, for

Ontology-driven coordination model for multiagent-based mobile workforce brokering systems

the reasons that will be described in the following lines, an automated MWBS is of high demand by contemporary organizations. As the population of the mobile workforces is rapidly increasing [2] and organizations are drastically attracted toward mobile technology for their business process enhancement, the demand for an effective and reliable MWM is escalating too. MWM comprises five phases, [1] namely task formulation, matchmaking, brokering, commuting, and service. Amid these phases, matchmaking and brokering collectively form a subsystem called Resource Allocation (RAL) [3]. Matchmaking is to find the most suitable class of resources competent in handling a specific task and Brokering is to disclose and allocate the task to the most appropriate and available member of the chosen resource class [3]. However, RAL as a process when the resources are mobile workforces (mobile device + human worker), endures a wider range of challenges. We found that the differences are mainly appearing in brokering phase. Thus, in this section, challenges that an MWBS has to encounter and our proposed solutions to respond to these challenges are discussed. 1.1 Challenges in MWBS Our previous works [10, 11] have already revealed that an appropriate MWBS has to exhibit three main characteristics as follows: 1. Accuracy: tasks have to be assigned to the right people and at the right time. Tasks should not be unattained and/or lost. 2. Fairness: in MWBS, the resources of the system are human, thus, tasks have to be assigned to them in a comparatively equal manner. 3. Automation: task allocation should be an automated process with minimum human involvement. In addition, MWBS has to address two major challenges, which might violate the accuracy, fairness and automation as follows: 1. Human Resource (HR) Risks: unexpected unavailability of mobile workforces due to involvement of human factors such as death, health, family problems, etc. 2. Environmental Risks: unpredictable disconnection cuts of the communication line between the MWBS and the mobile workforces in mobile environments. Both of these risks may transfer the system into a critical and unknown state, which requires human involvement and thus, reduce the reliability of the preferred automated system, which consequently penetrate the accuracy and fairness too.

769

1.2 Proposed solution In order to appropriately address the challenges mentioned in Sect. 1.1, an automated MWBS should possess the following features: 1. A Multiagent-Based Architecture: in order to be able to properly respond to the changes in a dynamic, distributed and heterogeneous environment, MWBS as a complex software must be capable of autonomous actions and deliberatively communicational and cooperative behaviors [4, 5]. For MWBS as an open distributed system, these capabilities cannot be gained without utilizing a multiagent-based architecture. 2. A BDI Agent Model: every agent which is designed to manage and control a dynamic and complex environment must follow Believe-Desire-Intention (BDI) architecture [6]. Using believe, desire and intention data sets, practical reasoning mechanism and commitment conditions, a BDI agent will be able to handle uncertainty and constantly changing nature of a dynamic environment. 3. An Ontology-Driven Knowledge Representation and Reasoning Mechanism: Semantic Knowledge Representation and Reasoning in general, and Ontology in particular, are two enabling technologies to represent information in a semantically rich format [7], which means easily understood by computers than human. This empowerment assists computer systems to manipulate information and carry out the processes in an automatic manner and with less human involvements. 4. A Coordination Model: communication in multi-agent systems is the ability by which agents coordinate their actions and behaviors to achieve common goals [8]. On the other hand, coordination is a key requirement for every software system in which different elements of the system have to be adjusted in order to reach a common goal. In response to the aforementioned requirements, we have proposed a multiagent-based architecture for MWBS in our early work [10]. An Ontology-Driven Procedural Reasoning System (O_PRS), which implements BDI architecture in MWBS, has also been proposed in our previous work in [9]. In addition, the importance of utilizing an ontology-driven approach in MWBS is described in [9, 10]. However, the only part of our proposed solution, which has not been described yet, is the desired coordination model. Therefore, the main focus of this paper is primarily to describe the role of an appropriate ontology-driven coordination model in MWBS, and subsequently to propose and formulate O-DC. 1.3 Structure of the paper The remainder of this paper is structured as per the following. In Sect. 2, the fundamental issues and concepts related

770

to coordination models are described. Section 3 illustrates an overview of MWBS, its architecture and life-time. In Sect. 4, features of the O-DC model are described. Section 5 describes a formal model for O-DC. Section 6 presents the result of a simulation, which has been conducted to examine the applicability of O-DC model based on a real world scenario. Section 7 describes the innovative values of this research. Finally, this paper is concluded in Sect. 8 and some future works in this field are suggested.

2 Coordination models 2.1 Fundamental concepts There are two categories of Approaches in Artificial Intelligence (AI), namely Knowledge-Based (classical or TopDown) AI and Behavior-Based (Bottom-Up) AI [12]. The former describes the internal model of the world using knowledge representation and the latter, which is the main focus of this section, studies the intelligent behavior of a system with regard to the interactions amongst its components. In a Multi-agent System (MAS), each agent has its own view of the world and therefore, no global control is applicable in MAS. Thus, modeling MAS necessitates utilizing a Behavioral-based approach [12], which implies managing the coordination amongst agents. Although a diverse range of definitions have been proposed for coordination, the most accepted definition [13] of coordination is the one proposed by Malone and Crowston [14], “. . . Coordination is managing dependencies between activities”. For MAS in general, there are two categories of dependencies, namely Objective (intra-agent) and Subjective (inter-agent) dependency and thus, there are two general categories of coordination which are Objective and Subjective [12] coordination. However, Modeling MAS requires an accurate specification of its objective dependencies. In addition, it is important to identify how the objective dependencies are managed in an environment where the agents are situated [12]. Coordination has been frequently recognized by many researchers as the most important attribute of any MAS in dynamic and heterogeneous environments [14–18]. 2.2 Components of coordination The specification and identification of interactions amongst agents that are involved in MAS, requires a specific class of languages known as Coordination Language [13]. The fundamental goal of a coordination language, according to [19] is to handle the interaction among the simultaneous activities of a distributed system. The relationship between pro-

A. Mousavi et al.

gramming and coordination can be shown on the following equation [20]: Program = Computation + Coordination This equation implies that in order to design and implement concurrent systems such as MAS, it is necessary to separate the computational entities from the way that they coordinate [12]. A coordination language however, corresponds to a Coordination Model that helps to design and study the language. Therefore, coordination is described by two basic concepts, a coordination language and its underpinning coordination model. Although the relationship between a coordination language and its model is complicated [13], Gelernter [20] portrays it in an ideal manner as “. . . a coordination language is the linguistic embodiment of a coordination model”. This definition can be enhanced further as “A coordination model is an abstract framework for the composition and interaction of active entities” [12]. A coordination model however, comprises three main entities as follows: 1. Coordinable Entities or Coordinables: are computing entities, which are active, running concurrently and their interdependencies are being coordinated by a coordination mechanism. 2. A Coordination Medium: is an abstract entity that allows agents (coordinables) to interact. It is also used to organize and configure the coordinables. Some examples of coordination media are Tuple Space, Semaphore and Channel. 3. The Coordination Laws: is a set of laws and protocols that identify and regulate the interactions between coordinables and the coordination medium. There are two main categories of coordination models and languages [12] as follows: 1. Data-Driven Coordination Model: In this model, coordinables interact via a coordination medium that is described in terms of data, and controls the interactions [13]. Most of the models under this category utilize a Shared Dataspace as coordination medium. However, structure of data and the way that they are exchanged are governed by coordination laws. Well-known examples of this class of coordination models are LINDA and GAMA [12]. 2. Control-Driven or Process-Oriented Model: In this model, entities communicate directly via input/output ports which act as coordination medium. The behaviors of coordinables in this model are perceived as events that occur at the input/output ports. Coordination laws determine what should be done upon occurrence of these events. Two well-known examples of this model are MANIFOLD and IWIM [12].


2.3 Dynamic coordination MAS may include heterogeneous and autonomous agents with no explicit information of each other [22]. In addition, an agent might be asked to perform unplanned tasks at runtime. Managing these complex situations cannot be achieved without utilizing coordination mechanisms [21, 23]. In addition, as the advancement in telecommunications and mobile computing has led the world of computing to pervasive and ubiquities computing, coordination has become a fundamental concept in managing the computer supported activities which run in such environments [24]. The traditional approach compels to hard-wire a coordination mechanism into its corresponding program at design time [25]. However, in dynamic and open distributed systems, where many dimensions of the system such as unplanned tasks and availability of resources cannot be accurately identified at the design time, a coordination mechanism capable of managing interdependencies at run-time, known as Dynamic Coordination, is required [25]. In a dynamic coordination model, coordinables have to communicate and reason on how they coordinate their activities at run-time [25, 26] to avoid conflicts. Therefore, communication and reasoning at run-time are two important attributes that a proper dynamic coordination model should possess. Some examples of dynamic coordination can be found in [27–29]. 2.4 Ontology-driven dynamic coordination In defining dynamic coordination model for MAS, it is essential to choose an appropriate knowledge representation method and an effective reasoning system. For instance, Game Theory employs probability distribution model for knowledge representation and Bayes formula as reasoning mechanism. However, game theory is not matured enough to manage huge complexity exhibited in MAS [30]. Another approach is to observe the coordination problem from a social view point which is to model the social reasoning based on the dependency relationship between the entities [30]. In this method, knowledge is represented in an ontology and is known as Ontology-Driven Dynamic Coordination Model. This model consists of an ontology, including knowledge concerning the entities of MAS and a common vocabulary containing the taxonomy of the domain [25, 26]. Ontology enables the agents to reason about the interdependencies between their own activities and the activities of other agents [25]. Such ontology in essence, should include the coordinable activities such as Agent and Event and their relationships. However, ontology has been represented in different formats but the most current and suitable format according to [31–34] is Web Ontology Language (OWL). OWL firstly,

771

expands the ability of Resource Description Framework (RDF), the fundamental data model which has been defined in Semantic Web technology. Secondly, it supports reasoning mechanisms based on Description Logic, such as SWRL [31]. Ontology-driven approach to dynamic coordination has been widely used in recent years and in various domains for different purposes. Some examples of this approach are, providing information for semantic interoperability in supply-chain Systems (SCS) [35], utilizing ontology in RFID networks [30] and coordinating semantic web processes [25, 26]. Therefore, this approach has been chosen in proposing O-DC.

3 MWBS: an overview 3.1 System definition MWBS is a system by which tasks can be assigned to the most appropriate member of a finite set of Mobile Workforces (MW) who are mobile and field workers and capable of performing certain tasks. To simplify the task allocation process, we assume that all MWs are capable of performing only one specific task. The process of task allocation in MWBS is an automated process that must be reliable, accurate and fair toward the entire MWs. MWBS is also responsible for managing and monitoring the process of task allocation and task execution for the entire MWs, which are registered to the system and are ready to work in the system’s environment at any operational time during the system’s life-time. 3.2 An organizational model of MWBS As mentioned earlier, MWBS is a subsystem of RAL. Figure 1 illustrates an organizational model for RAL system and its components in which the position of MWBS is depicted. In developing this model, we have used outsourcing, which we believe provides an adequate foundation for functional decomposition of the system [10]. Based on this model, companies who are in need of particular services, outsource these tasks to an appropriate vendor. An outsourcing vendor, that in our model is called Task Allocation System (TAS), is connected to a number of Mobile Workforce Clusters (MWC). Each cluster includes a number of MWs who are distinguished from the members of other clusters by their physical location (PL) and the service that they can provide in that location (LS). TAS can communicate to a cluster only via its corresponding MWBS, which in turn communicates to the members (MWs) of its cluster. MWBS is also responsible for controlling and monitoring the workforces of its cluster.

772

A. Mousavi et al.

Fig. 1 Structural model of RAL and MWBS

3.3 The architecture of MWBS Figure 2 illustrates the architecture of RAL and MWBS, and Table 1 describes the components of this architecture, which consists of two layers. The first layer or Mobile Network Infrastructure Layer connects different units of this architecture and the second layer or Multi-agent Platform layer, provides control and monitoring services for the agents, which are situated in MWBS. Multi-agent platform layer facilitates Java Agent Development Framework (JADE) [36]. In addition, Jena Semantic Web Platform has been utilized for connecting to ontology and to manipulate it. In order to examine this architecture, we have also developed a simulation tool called MWBS-SIM. Although this architecture and its underpinning features are described in our previous work [10] in details, we have included it in this paper to provide a comprehensive reference for the readers. 3.4 Life time of the MWBS The life time of the MWBS is divided into two phases, namely Initialization Phase and Run-time Phase: 1. Initialization Phase: the main aim of this phase is to figure out a realistic, applicable and fair deal to be made between TAS and MWBS. In doing that MWBS has to communicate to the entire MWs and request them to submit their monthly proposals. A monthly proposal is a schedule that a particular MW claims that he/she can perform for the coming month. Since the claims can be

violated by unexpected unavailability (HR risk), the ultimate goal of MWBS in Initialization phase is to calculate a Realistic Monthly Capacity (RMC) for each MW and an Overall Realistic Monthly Capacity (ORMC) for its corresponding cluster, which is the sum of all RMCs. ORMC then, will be considered as the base for the monthly deal. 2. Run-Time Phase: after a monthly deal is made between an MWBS and TAS, the deal has to be fulfilled. This functional phase is called Run-time. In Run-time phase, which lasts for the period of one month, tasks will be sent to MWBS and dispatched to actual MWs to be performed according to the monthly schedule. The process of task allocation also is monitored in Run-time phase. Risk of disconnection as well as human resource risks have to be properly addressed in this phase otherwise MWBS will fail to fulfill the deal (ORMC) and therefore, it will lose profits and will pay penalty. In order to avoid any ambiguity in name similarity, it has to be mentioned that Run-time phase and Initialization phase are two main phases of MWBS’s life-time, which both happen at run-time and neither of them at design-time. Therefore, readers have to realize that Run-time phase and runtime are not used similarly in this article. The former refers to an operational phase of the MWBS’s life-time while the latter refers to the system’s statues after execution. Since our main objective in this article is to illustrate the O-DC and its underpinning mechanism and not to show its full contents, we have mainly focused on representing those features that are used in Initialization phase. As mentioned


773

Fig. 2 Architecture of RAL and MWBS

Table 1 RAL and MWBS functionalities and agents Functionality

Corresponding agent

Planning-Scheduling Subsystem (PSS) Supervise Agents of PSS

Supervisor Agent (SA)

Make Deal with TAS

Dealer Agent (DA)

Create Initial Plan

Initializer Agent(IA)

Do Runtime Planning

Runtime Planner Agent (RPA)

earlier, Initialization phase is also happening at run-time and therefore, O-DC as a dynamic coordination model can be used to address the interdependencies between the activities that are involved in this phase. However, the extension of O-DC which should be used in Run-time phase will be discussed in the future in a different article.

4 Features of O-DC

Brokering Subsystem (BS) Assign Task to Agent

Brokering Agent (BA)

Supervise Agents of BS

Brokering Supervisor (BSA)

Do Runtime Planning

Brokering Planner Agent (BPA)

Other Functionalities, Agents and Actors

4.1 Components of O-DC We begin describing the O-DC model by identifying its coordinable entities, coordination medium and coordination rules.

Deal With MWBS

Task allocation Agent (TAA)

Represent MW

Resource Agent (RA)

Request the functional outsourcing, start the system’s run, Deal with TAS

Simulation Agent (SimA)

• Coordinable Entities in O-DC: There are three categories of coordinable entities in MWBS:

Cooperate with MWBS via PDA and perform tasks.

Mobile Workforce (MW)

1. Task Allocator: is a person, an organization or a subsystem that deals with MWBS in order to establish a contract with system. Task allocator requests for

774

A. Mousavi et al.

monthly proposal and then follows the proposal until all the claims of the proposal are fulfilled. Since fulfillment of the claims requires execution of certain plan (s) therefore, another duty of task allocator is to monitor the process of plan execution. 2. Mobile Workforce: is an actual resource to which tasks are assigned, and is equipped with a mobile device like PDA, via which he/she communicates to the system. 3. Agent: is an entity that automates a process. It either represents a human (a task allocator or an MW), or does computations or both. • Coordination Medium in O-DC: ontology and semantic web are chosen for representing the coordination medium. The main features of this coordination medium, represented in an OWL Ontology called MWBSOnto.OWL are: 1. BDI features of Agents (O-PRS). 2. Organizational Policies. 3. Contingency Plans. • Coordination Rules in O-DC: rules are realized and represented as Policies and Plans. However, the rules which govern how coordinables communicate with coordination medium are apprehended as two operators namely; Query and Reason. These operators are defined to browse through the ontology in accordance to policies and plans to find out an appropriate plan which is suitable to be performed in a particular situation. Therefore, before describing these operations, a short description of policy and plan are given: – Policy: is an organizational norm defined to validate the information that agents provide and/or to evaluate the overall performance of an agent, a group or team of agents or the system as a whole, either at run-time or at design time. – Plan: is an instruction which dictates to an agent or to the whole system/sub-system what to do if an event occurs. Plans that describe what to do when an event occurs for an individual agent are parts of O-PRS model [9]. In contrast, plans that instruct the whole system or a particular subsystem to mange a risk or a critical situation, are called contingency plans which are incorporated into the coordination medium. Having these definitions, we can now define two operations that govern the communications between coordination medium and coordinable entities as follow: 1. Query Operation: is a query written in SPARQL [37] by means of which the existence of a particular entity in a specific relationship with other given entities is investigated. The outcome of this operation is to retrieve a piece of information/knowledge which is required for the coordination mechanism in order to take an appropriate action

Fig. 3 O-DC’s layered architecture

which manages the interdependencies amongst activities in the best manner. 2. Reason Operation: is a statement or rule written in Description Logic (DL) [38, 39], which in O-DC is represented as a valid Jena Rule. The main purpose of a Reason operation is to extend the knowledge of the coordination medium if certain conditions are valid. 4.2 Coordination mechanism in O-DC A coordination mechanism describes how the whole system acts in order to manage the interdependencies amongst activities. The ultimate goal of the mechanism underpinning O-DC is based on a three step algorithm, which determines how the activities are performed in this model. These three steps are: 1. An Event Occurs. 2. Entities using O-PRS, find what to do (Plan finding, deliberation) and how to do it (Plan execution or means-end reasoning) [9]. 3. Entities perform the appropriate activities. The core part of this model is a Plan which comprises of several interdependent activities. The interdependencies of activities involved in an individual plan or included in different plans have to be managed by O-DC, to avoid potential conflicts. In order to discover how to manage these interdependencies, a conceptualization model of all activities of the system is required. The first categorization criterion of the activities is based on operational differences that divides activities into four categories, namely Communicational, Validation, Computational and Risk Management activities. Based on this conceptualization, a layered architecture comprising of four following layers is depicted in Fig. 3: 1. Communication Layer. 2. O-PRS (Plan finding and execution) Layer.


3. Policy Enforcement Layer. 4. Contingency Planning Layer.

775

5.3 Formulizing the coordination rules In O-DC, coordinables communicate with coordination media in two ways:

5 Formal model of O-DC In this section, a formal description of O-DC is proposed that accurately describes entities and functions involved in this model. 5.1 O-DC and triple space computing O-DC is a Linda-like data-driven model, which uses a shared Tuple-Space. Representing Tuple-Space in OWL compels the following requirements [40]: 1. A reference mechanism for representing URL and URI (Universal Resource Identifier) in Tuple-Space. 2. A mechanism to represent namespace for vocabularies of different domains. 3. A mechanism to represent the nesting of tuples. Therefore, Linda model needs to be revised and extended in order to be able to address the requirements of semantic knowledge representation [40]. A new approach to extend Linda to address the aforementioned requirements is to combine it with semantic. This combination is known as Triplespace Computing [40]. Since O-DC has to deal with semantic data, autonomous coordinable entities, heterogeneous and large data, we define it as an extension to Linda, which utilizes the Triplespace model and thus, uses Triplespace computing formalism to formulate it. 5.2 Formulizing the coordination medium First step to formulate O-DC is to formally define its coordination medium (Ontology). We utilize Description Logic (DL) [38, 39] for this purpose. The main components of this formal model are: 1. T-Box Formulization: including concepts and the hierarchical or subsumption relationships between concepts. Tables 7 and 8 in Appendix A illustrate the Formulization of the MWBSOnto.OWL’s T-Box. 2. ObjectProperties and DataProperties Formulization: including the description and specifications of the ObjectProperties and DataProperties being defined and used to describe the relationships between entities of MWBSOnto.OWL. These relationships can be used in creating the Assertion Box (A-Box) too. Tables 9 to 14 in Appendix A illustrate the formulization of the ObjectProperties and DataProperties of the MWBSOnto.OWL ontology. To formulize the MWBSOnto.OWL, we used the notations and formalisms described in [38, 39] as our reference model.

1. Via Semantic Inferencing Rules, represented in DL notations. 2. Via Queries written in SPARQL. In O-DC Inferencing Rules as well as Queries are implemented using Jena APIs. Inferencing rules are represented as Jena Rules that are quite similar to SWRL (a standard rule language for semantic web) rules. In this subsection, we represent the general syntax of Inferencing Rules and SPARQL Queries that are defined in DL. In Sect. 6 however, some examples of Rules and Queries will be shown and explained. 5.3.1 Formulization of the inferencing rules in DL DL is extendable by means of inferencing rule clauses, which can be interpreted with semantic of the First-Order language. To formulize an inferencing rule, we have utilized the notations, which have been described in [41]. We do not show these notations in this article for the sake of simplicity. 5.3.2 Formulization of the SPARQL queries in DL In Description Language systems, a query answering system is a mechanism that can identify if a statement can be logically derived from a knowledgebase. This logical derivation (logical consequence) for a query statement α and a knowledgebase K and interpretation I are shown as follows [42]: 1. K | α: means α is a logical consequence of K 2. K | α iff ∀I , I | K → I | α The standard query language which is used for querying over OWL knowledgebases is SPARQL-DL, which is basically meant to query RDF graphs. An RDF graph is a finite set of RDF triples, therefore, an SPARQL query statement is made up of a set of triple patterns called Basic Graph Patterns (BGP). A triple pattern, however, is a triple with zero or more variables each one may represent a subject, object or predicate (the building blocks of an RDF triple). We formulize the SPARQL-DL Query and Query statements using the formalism described in [37, 42]. 5.4 Formulizing the O-DC coordination model This subsection illustrates the formulization of O-DC. The symbols and entities used in O-DC are defined as follows: Let: K be a triple space, the OWL ontology which represents the Coordination Medium. Ag be a Multi Set of Agents. A be a typical agent belongs to Ag. η be a set of primitive or operator actions. 0 be an agent with no capability. ηA be an agent capable of performing operation η.

776

A. Mousavi et al.

Table 2 Formulization of O-DC Model (qans(Q)A ⊕ Ag, K) → (A ⊕ Ag, K) (rexe(r)A ⊕ Ag, K) → (A ⊕ Ag, K ⊕ v), , K) → (A , K )

(Aj ( i∈1 Ai ⊕ Ag, K) → (A ⊕ Ag, K ) (A, K) → (A , K ) (AN ⊕ Ag, K) → (A ⊕ Ag, K )

v ∈ {rHead, ∅}

If j ∈ I

If AN = A

qans( ) be a coordination primitive by which a valid query Q can be run over K. rexe( ) be a coordination primitive by which a rule r∈R can be executed over K. ⊕ be the Multiset Union Operator. M be a FIPA message. inform(A, M) be a coordination primitive by which coordination medium informs agent A with message M. notify(A, M) be a coordination primitive by which coordination medium notifies the agent A with message M. Definition 1 We define Agent generator grammar [13] for O-DC as follow: Ai |AN A ::= 0|ηA| i∈1

η ::= qans(Q)|rexe(r)|notify(A, M)|inform(A, M) Definition 2 We formulate the O-DC model as in Table 2 using formalism described in [13], which is an extension to Linda.

6 Experiment and simulation In this section the coordination mechanism described and provided by O-DC is explained via a real-world scenario derived from Initialization phase of MWBS’s life-time. 6.1 Describing the scenario In MWBS, every MW can choose the number of days that he/she wants to work during a month, given via a valid proposal by each MW. Next, MWBS has to calculate ORMC based on these proposals. The process of gathering Monthly Proposals from MWs is a team work in which IA, RAs and MWs (as described in Table 1) are involved. To perform this process from coordination prospective, the team leader (IA) first needs to form its team of RAs. Secondly the team members should be able to communicate appropriately. Hence, O-PRS and Team Formation are the first two coordination mechanisms required in calculating ORMC. Although the liberty in working times provides working flexibility for MWs, each proposal should comply with a specific organizational policy. For instance, in MWBS, an MW’s proposal cannot be less than a minimum and greater

than a maximum value. The enforcement of the organizational policies undoubtedly prevents the MWs from violating the social norms and provides integrity for the system. Thus, Policy Checking is another key coordination mechanism required in calculating ORMC. Moreover, human resource risk is the main risk that needs to be addressed in calculating ORMC. Even though an MW proposes a monthly capacity, he/she might not be able to perform the proposed workload due to different circumstances. The main factors that make a Monthly Deal are the monthly capacities proposed and agreed by MWs and any breach of the this deal will cause some penalty. Therefore, an appropriate contingency plan has to be planned to prevent or minimize these sorts of penalties. Thus, another effective factor in calculating ORMC is its corresponding and appropriate Contingency Plan. Our proposed contingency plan is based on a statistical method for calculating RMC which evaluates an MW’s proposal according to the task performance history and discovers the reliability of his/her proposal. Formulating the statistical method for HR risk management is beyond the scope of this article. Furthermore, calculating the ORMC can only take place with the condition if RMCs for the entire MWs are calculated. In other words, if RMC for some of the MWs are not calculated, the ORMC which is the sum of all RMCs cannot be figured out correctly. Therefore, the coordination media has to notify the agent that is responsible for calculating this summation (IA in this case) when RMC for all MWs are entered into the system. Therefore, notification should be also considered as a mechanism or action which plays a key role in this scenario. Based on the aforementioned discussion, the features of an appropriate coordination mechanism capable of handling the complexities and interdependencies of the activities included in calculating ORMC can be summarized as follows: 1. 2. 3. 4. 5.

Communication. Team Formation. Policy Checking and Enforcement. Contingency Planning. Notification.

In the next subsections, each one of these aforementioned factors and the way that they are represented, applied or addressed in O-DC are described in detail. 6.2 Communication Communication in MWBS is done using JADE messaging system. BDI agents of MWBS, as it has been described in [9], utilize O-PRS model in their deliberation and meansend reasoning cycles. Figures 4 and 5 illustrate the location of Initializer Agent (IA) and Resource Agent (RA) in the


777

Fig. 4 IA, it’s believe and plans

Fig. 5 RA, it’s believe and plans

ontology. These figures also illustrate how the plans and Believes are assigned to IA and RA. Since there are many instances of RA in the system, only a typical RA is shown in Fig. 5. In reality for every RAi there will be a sub graph in MWBSOnto.OWL. As all parties in MWBS are communicating via a standard and well-known messaging system as well as the same ontological format, we conclude that the openness for this system can be addressed properly using our proposed coor-

dination mechanism. In addition our proposed coordination mechanism can handle the communication between many parties at the same time and thus addresses the concurrency for the open distributed system (MWBS) that utilizes it. 6.3 Team formation In this scenario, team formation comprises two phases; finding the team members and sending appropriate request to them.

778

A. Mousavi et al.

Fig. 6 Agents communicate to form a team of ResourceAgents

Team formation starts, as depicted in Fig. 6, when SA sends a (REQUEST: Initialize) message to IA. IA, using O-PRS mechanism finds out what to do (plan finding), by sending a (REQUEST: getPlan) message to OA. OA, sends an (INFORM: iaInitPlan) message to IA, which shows the plan signature for (REQUEST: Initialize) event. iaInitPlan, is a valid plan with two sub actions. Firstly, IA by executing iaInitPlan sends a (REQUEST: getResourceAgents) message to OA to get a list of potential team members (RAs). OA, sends back an (INFORM: RA List) to IA. Secondly IA, after receiving the RA list, sends a (REQUEST: Initialize) message to the entire list of RAs to get their monthly proposal. Initialize request for an RA is interpreted in this way; it has to send a (REQUEST: sendProposal) message to its corresponding MW. An RA, then, upon receiving a proposal which is an integer value indicating the number of days that an MW is willing to work in the next working month, sends a (REQUEST: addNewHistory) to OA. This event then triggers a policy checking process, which is described in Sect. 6.4. There are three operations defined in O-DC model which are involved in team formation activity as follows:

6.3.1 Plan discovery query( ) operation This operation is a standard query used within O-PRS mechanism to find the plan signature for a specific event which happens (in this case REQUEST: initialize message) for an agent (in this case IA). The query and the query execution operation are depicted in Fig. 7 6.3.2 Team discovery query( ) operation This query operation and its corresponding query are shown in Fig. 8. The Query is written to find all the Instances of ResourceAgents who are active in the system. 6.3.3 Inform( ) operation Inform( ) operation in team building sends an Inform message to IA, giving it the list of RAs (team members) available in the system. The sender of this message is coordination medium (via OA). Figure 9 illustrates the message and the inform( ) operation. Since our proposed coordination mechanism has to support Team Formation for a various range of mobile workforces, it has to be mentioned that O-DC is capable of addressing the diversity which is another important characteristic of the open distributed systems.


6.4 Policy checking and enforcement Policy checking is another important layer of O-DC model which is required in calculating ORMC. This processes checks if a proposal sent by an MW is valid. The Proposal Policy in O-DC is represented as a sub-graph in MWBSOnto.OWL. Figure 10 depicts the policy used in this scenario. As Fig. 10 illustrates, ProposalPolicy1 is an instance of ProposalPolicy class, which on the other hand is a sub class of Policy. ProposalPolicy1 has two DataProperties, hasMax and hasMin that respectively identify the maximum and the

minimum value that a proposal may carry. In this case hasMax = 20 and hasMin = 10 which means an MW can work from 10 to 20 days per month and proposals with values above or below this range are not valid or acceptable. Upon receiving a proposal by an RA, it will send a message (REQUEST: addNewHistory) to OA (coordination medium) and a history including only a history name and its

Fig. 8 query( ) operation for Team discovery

Fig. 7 query( ) operation for plan discovery

Fig. 10 Representing proposal policy in ontology

779

Fig. 9 inform( ) operation for team building

780

A. Mousavi et al.

Fig. 11 Representing history in ontology

date will be temporarily added to the Ontology and then the policy will be checked over it. Figure 11 illustrates an instance of the History class which represents the proposal, which has been received from MW1. The History name: History_MW1_06-2010, the Date of this instance of History: 06-2010 (June-2010) indicating that this proposal has been made to be applied in this month. The hasProposal DataProperty of this instance has the value of 15 assigned to it which means that MW is able to work 15 days. To check this policy in MWBS, a certain Jena Rule has been written to evaluate the validity of a proposal. If the body of the rule is correct, it will link the history to its corresponding MW in ontology. Figure 12 illustrates the ProposalPolicy1Check Rule and its corresponding Rule Execution rexe( ) operation, which is one of the O-DC Model’s standard operations. Since the value of proposal History_MW1_06-2010 is 15, which makes the Body of this rule correct, the Head of the rule will be fired, which in turn creates a link between History_MW1_06-2010 and MW1. Figure 13 represents the new History that has been added to the Ontology and its link to its corresponding MW (MW1). 6.5 Contingency planning One of the most important parts of O-DC is the appropriate contingency plans which have to be designed to prevent or battle risks. In the abovementioned scenario, unexpected absence is the risk that O-DC has to address in Initialization phase. This risk is a potential threat to the fulfillment of monthly deal and therefore, may cause penalties for the cluster. Although in most cases the unexpected absence cannot be avoided, it can be approximately predicted. One way to

Fig. 12 Rule for policy checking

predict the unexpected absence for an individual MW is to evaluate the working history of the MW. The history always demonstrates the gap between one’s claim and one’s fulfillment. In other word, by analyzing the history of an MW we can roughly estimate that up to what extent his/her claim is reliable. Therefore, figuring out the gap between MW’s claim and performance can help to organize a realistic figure of MW’s monthly capacity by figuring out his/her RMC. We are utilizing a statistical method to calculate the RMC based on the working history of MWs. The description of the statistical method is beyond the objective of this article. In addition, calculating RMC can only predict how likely an MW can be absent during a specific period of time, but it cannot predict on what exact date an MW will be absent. For instance, if MW’s claim is 15 days and his RMC is 12, it shows that most likely he/she will be absent for 3 days in the coming month, but it fails to reveal when exactly these 2 days of absence will take place. For this reason, in order to avoid any penalty, the deal itself should be flexible, which means if a deal claims that an MW should work 15 days in a specific month, these 15 days can be any working days of that month. Therefore, in addition to Monthly Plan and schedule, there is a Daily Plan and schedule in MWBS. Before starting a working day, MWBS contacts the RAs that


781

Fig. 14 Representing ORMC in ontology Fig. 13 Linking history and MW Table 3 Contingency plan for HR risk

Upon receiving this notification, IA who is responsible for calculating the ORMC for the whole cluster, firstly calculates the ORMC which is the sum of all individual RMCs and then links the ORMC to the History of the Next Month of the Cluster. In other words, ORMC belongs to the Cluster itself but not to any individual MW. Figure 14 illustrates the link between ORMC and Cluster which in this case is called C1.

Event

The Event that causes this risk is: an MW informs the system that he/she won’t be available at work for a working day that has been scheduled for him/her in the monthly schedule one day in advance.

Impact

If it is not taken care of, it will cause a financial penalty for the cluster in which the MW works.

Solution

1. Making the process of task allocation more flexible by introducing the concept of Daily Schedule.

6.7 A case study

2. Modifying the MW’s claim during initialization phase by calculate the Realistic Monthly Capacity (RMC) for each MW and an Overall Realistic Monthly Capacity (ORMC) for the whole cluster.

In this section we study the behaviors of a typical MW Cluster (C1) with regards to O-DC. This case study has been defined and conducted to firstly, prove the applicability of the O-DC in real-world problems. Secondly, since the value of a new technique is not only defined by its applicability but also is measured by the improvement that it brings to the system in which it is applied, we illustrate how O-DC and its underpinning features improve the overall performance of C1. Although the overall performance of an MW cluster is a function of its accuracy, fairness and automation, investigating all of these factors is beyond the scope of this article. To simplify our discussion we focus on a quantitative variable called overall profit which indicates the overall profit that C1 earns during a time frame. We then compare the values of this variable between Existing System, that does not utilize O-DC and MWBS, which uses O-DC. Finally, we will show the overall improvement in overall profit caused by applying our proposed coordination model. However, improvement in overall profit of a cluster caused by utilizing O-DC implies less penalty, effective rescheduling and more realistic monthly deal which are achieved with minimum human involvement. Therefore, this improvement entails improvement in accuracy and automation as well.

3. Use ORMC as a norm for monthly scheduling.

are supposed to work on the following day, according to the monthly plan, and confirm their availabilities. If an MW is not able to be present on the coming day, then MWBS will modify the monthly plan and then confirm with the Task Allocation System (TAA). The MW’s duty might be then postponed to another day. Table 3 describes the contingency plan used in this scenario as suggested in [43–45]. 6.6 Notification When the entire RAs have evaluated the proposal against the policy and calculated the RMC for their corresponding MW, they have to store the RMC for their corresponding MW as a link to its History for the Next Month in the MWBSOnto.OWL. Upon finishing this job by entire RAs, system should notify the IA who is the team leader for RAs team. The notification as mentioned earlier, will be performed using O-DC’s standard function; notify (A,M).

782 Table 4 Data needed to calculate the RMC and ORMC and the calculated values

A. Mousavi et al. MWi

i

No.

MonthNo.

ProposedNo.

PerformedNo.

Proposedi,(n+1)

RMCi,(n+1)

MW1

1

1

Jan-10

13

10

Proposed1,6 = 15

RMC1,6 = 12

2

Feb-10

14

12

3

Mar-10

18

18

4

April-10

17

11

5

May-10

16

10

1

Jan-10

17

12

Proposed2,6 = 12

RMC2,6 = 10

2

Feb-10

14

14

3

Mar-10

15

15

4

April-10

18

14

5

May-10

12

11

1

Jan-10

10

10

Proposed3,6 = 14

RMC3,6 = 11

2

Feb-10

19

11

3

Mar-10

18

17

4

April-10

16

10

5

May-10

12

11

1

Jan-10

15

10

Proposed4,6 = 16

RMC4,6 = 14

2

Feb-10

18

16

3

Mar-10

12

12

4

April-10

15

15

5

May-10

20

17

MW2

MW3

MW4

2

3

4

ORMC6

Our case study begins with reviewing the past history of the system, including 5 months from the run of the existing system (January to May 2010). Our case study is then followed by a simulation conducted for the period of 4 months (June to September 2010) using MWBS-SIM simulation tool which utilizes the O-DC. Finally, we will illustrate the improvement in overall profits for the period of this simulation. Once again, it has to be mentioned that the objective of this section is not to discuss the simulation itself but to use partial result of the simulation to prove the applicability and profitability of O-DC. 6.7.1 Reviewing the past history of the system Table 4 illustrates the Proposed and Performed value for 4 mobile workforces MW1–MW4 of cluster C1 for five consecutive months, which in the course of this case study is considered as the past history of the system. This table also depicts the proposed (Proposed i,(n+1) ) value for the following month (6th month) and the RMC calculated for each MW based on a statistical method. Finally, the ORMC is calculated and depicted in this table, which is used as a norm for making a monthly deal between MWBS and TAS. Figure 14 illustrates a partial view of the MWBSOnto.OWL including the links between Cluster: C1, its

47

History: History_C1_06-2010 and the ORMC = 47 for June-2010 which is supposed to be the Next Month for this system. 6.7.2 Simulation: assumption and data manipulation MWBS using O-DC includes mechanisms to approximately predict the possible absence of MWs in initialization phase and to address the unpredictable absence of the MWs at Run-Time phase. Therefore, we assume that using this framework, the penalty that system has to pay for the unattended claims will be drastically reduced in comparison with the existing system. Less penalty that a cluster pays, more profit it gains, thus, this assumption implies that MWBS increases the overall profit of its cluster. However, in order to manipulate the data collected from the run of the Existing System as well as MWBS the following terms have to be defined: TP (Total Penalty): Total penalty that a cluster has to pay for the unpredicted absence of the MWs, which is the sum of monthly penalties of each MW of the cluster. TPE (Total Performed): Total Working Days of a Cluster, which is the sum of Performed for the entire MWs. TTP (Total Task Performed): Total Tasks performed by a cluster during a month. We assume that each MW has to perform 15 tasks per each working day. TTP = TPE × 15.


783

Table 5 Run of the existing system Month

Overall proposed

Overall performed

Total penalty

TTP

Profit

June

57

48

9

720

585

July

59

48

11

720

555

Aug.

78

60

18

900

630

Sept.

64

53

11

795

630

Overall profit for 4 months

2400

Table 6 Run of the MWBS Month

ORMC

Overall performed

Total penalty

TTP

Cluster profit

June

47

63

0

945

July

50

58

0

870

870

Aug.

68

70

0

1050

1050

Sept.

52

63

0

930

930

Overall profit for 4 months

945

Fig. 15 Overall profit comparison from June to September 2010

3795

Profit: It is the total profit that a cluster earns during a month and is calculated based on total tasks performed by a cluster. In this scenario, every MW has to perform 15 tasks in a working day. Thus the profit is calculated as follow: Profit = TTP − (TP × 15). 6.7.3 Result of the simulation Table 5 illustrates the values of the parameters described in Sect. 6.7.2 which are calculated based on the data collected from the run of the Existing System. In contrast, Table 6 illustrates the values for the same variables from the run of the MWBS. We calculate Overall Profit for Existing System and MWBS and then compare them to find out how MWBS improves the overall profit. • Overall Profit for Existing System = (585 + 555 + 630 + 630) = 2400 • Overall Profit for MWBS = (945 + 870 + 1050 + 930) = 3795 • Percentage of Improvement: [(3795 − 2400) ÷ 2400] × 100 = 58% Comparison: MWBS improved the profit that a cluster earns up to 58% in four months. Figure 15 illustrates the overall profit comparison between Existing System and MWBS, and Fig. 16 depicts the entire profits for Existing System and MWBS for June to September 2010.

Fig. 16 Monthly profits for existing system and MWBS from June to September 2010

7 Innovative values of this research The innovative values that distinguish our work from similar works in this field and hence justify our research are listed below: 1. Combining coordination model and multi-agent systems via ontology: Although some research works have been published in using ontology as coordination media [25, 26, 30], we have not found considerable efforts in proposing ontology-driven coordination models in which multi-agent communication mechanism, agent plans and the coordination laws are incorporated within the body of a single coordination media, which

784

2.

3.

4.

5.

is in this case an ontology. In contrast, O-DC possesses these attributes. This integration increases the integrity of the multi-agent system and therefore, enhances the quality of the system. In addition, incorporating the aforementioned components within a single ontology reduces the potential difficulties, which may occur during the implementation phase and increases the visibility of the system, which in turn simplifies the testing phase. Our research was an endeavor to break these limitations and to illustrate how this integration can be done. Formulizing ontology-driven coordination model: The lack of an appropriate formulization methodology for ontology-driven coordination models motivated us to propose a method for this purpose. Our proposed model is a combination of prominent triple space formalism [40], Description Logic [38, 39] and the formalism used in Linda [12] reference model, which extends Linda model. Our proposed formulization technique can be used for similar models by other researchers in this field. Representing organizational policies, and policy checking mechanism in coordination model: Organizational policies are certain rules that synchronize activities in an organization and therefore, should be embedded in a coordination model that has to comply with these rules. In this research, we have shown how these rules can be represented as a set of semantic rules, which partially validate the knowledge stored in ontology as well. Representing risk management methods in an ontology: As it is mentioned prior to this, risk management is an important factor that identifies the efficiency of an automated open distributed system that deals with entities such as human workforces that might cause high amount of risks. Thus, one of the main contributions of this research is, to propose a method for embedding the risk management plans, known as contingency plans within the body of the coordination model. Since risk management is a common necessity amongst all automated open distributed systems, this achievement makes O-DC generalizable meaning that it can be applied on a wide range of cases. Testing the applicability of O-DC in a real-world domain: We have utilized O-DC in MWBS and illustrated on how it can be applied, firstly, to implement a multi-agent system and secondly, how to simulate a scenario using the implemented system. Our work can provide the designers of multi-agent systems with a template that can be used to design and implement ontology-driven coordination based multi-agent systems.

A. Mousavi et al.

8 Conclusion and future work In this paper we have proposed and formulated an ontologydriven coordination model (O-DC) for managing interdependencies amongst the activities of the agents involved in open multi-agent systems. In this research MWBS has been chosen as our domain of discourse. We believe that MWBS exhibits common characteristics of a typical open distributed system, which can be situated in dynamic and unpredictable environments. Finally, the applicability of ODC has been examined via a simulation, which has been conducted based on a real-world scenario. The result of this research proves that an ontology-driven approach to coordination is applicable and suitable for being used on a range of open multi-agent systems, which in this article are represented by MWBS. Furthermore, we have shown that MWBS can be more profitable using O-DC. Profitability in MWBS implies that it is more accurate with less human involvement. However, in this article, we have mainly focused on proposing a coordination model capable of addressing the common characteristics as well as risk management for open distributed systems. In this regard, we have selected the Initialization Phase of the MWBS’s life-time as a scenario for our case study. Nevertheless, there are some open issues that have not been addressed in this article such as formulization of the statistical method for HR risk management, analyzing the fairness of task allocation process and investigating the applicability of O-DC in MWBS’s Run-time Phase. We believe that these open issues are mainly related to the content of the O-DC and they do not have any impact on O-DC’s model and structure thus, in this article we have considered them as out of the scope. Therefore, we decided to address these issues in another article in the near future. Moreover, the future works that can be considered based on our research undergoes three main directions. First of all, in our current work, we have assumed that factors which are influential in describing the risks, such as type of tasks that an MW is able to perform and the number of the tasks that an MW can perform per each working day are constant. Therefore, extra effort should be spent on studding the internal dynamicity of open distributed systems and enhancing O-DC to address it. Secondly, in our research a single plan has been assigned to each situation, while in the real world, there are often a range of plans that are suitable for making decision in a particular situation. Thus, O-DC has to be enhanced to support multiple-planning approach to decision making as well. Finally after the aforementioned enhancements, MWBS and O-DC have to be situated in a real environment (instead of simulation environment) in order to examine the applicability as well as the performance of these models and methods in a real-world situation.


Appendix A: formulization of O-DC’s coordination medium Table 7 Concepts and their representing symbols

785

Table 10 Specifications of ObjectProperties No.

Symbol

Specifications

1

R0

domain(C0 ): range(C6 ):

No.

Concepts (classes)

Symbol

2

R1

≥ 1R0 C0

∀R0 .C6 ≥ 1R1 C6

domain(C6 ): range(C2 ):

∀R1 .C2

1

Agent

C0

2

DealerAgent

C0,0

3

InitializerAgent

C0,1

≥ 1R2 C1 ≥ 1R2 C7

4

ResourceAgent

C0,2

range(C3 ), range(C3,0 ), range(C3,1 ):

5

SupervisorAgent

C0,3

∀R2 .C3 ∀R2 .C3,0 ∀R2 .C3,1

6

MobileWorkforce

C1

7

Event

C2

8

Message

C2,0

9

History

C3

10

MobileWorkforceHistory

C3,0

11

ClusterHistory

C3,1

12

Plan

C4

13

Policy

C5

14

ProposalPolicy

C5,0

15

Believe

C6

16

Cluster

C7

Table 8 Subsumption relationships between concepts No.

Hierarchical relationship

1

C0 C1 C2 C3 C4 C6 C7

2

C0,0 C0 C0,1 C0 C0,2 C0 C0,3 C0

3

C2,0 C2

4

C3,0 C3 C3,1 C3

5

C5,0 C5

Table 9 ObjectProperties and their symbols

3

4

R2

R3

domain(C1 ), domain(C7 ):

range(C4 ): 5

R4

≥ 1R3 C6

domain(C6 ):

∀R3 .C4

domain(C0,2 ): range(C1 ):

≥ 1R4 C0,2

∀R4 .C1

Table 11 DataProperties and their symbols No.

DataProperty

Symbol

1

historyProperties

U0

2

hasDate

U0,0

3

hasLabel

U0,1

4

hasPerformed

U0,2

5

hasProposal

U0,3

6

hasRealisticMonthlyCapacity

U0,4

7

messageProperties

U1

8

hasContent

U1,0

9

hasPerformative

U1,1

hasSignature

U1,2

11

policyProperties

U2

12

hasMax

U2,0

13

hasMin

U2,1

10

Table 12 Data types and their symbols

No.

ObjectProperty

Symbol

1

hasBelieve

R0

1

Any

D0

2

hasEvent

R1

2

String

D1

3

hasHistory

R2

3

Integer

D2

Float

D3

Boolean

D4

No.

4

hasPlan

R3

4

5

represents

R4

5

Data type

Symbol

786

A. Mousavi et al.

Table 13 Subsumption relationships between DataProperties No.

Appendix B: Table of acronyms

Hierarchical relationship

1

U0,0 U0 U0,1 U0 U0,2 U0 U0,3 U0 U0,4 U0

2

U1,0 U1 U1,1 U1 U1,2 U1

3

U2,0 U0 U2,1 U2

Abbreviation

Full expression

A-Box

Assertion Box

BDI

Believe Desire Intention

DL

Description Logic

MAS

Multi-agent System

MWM

Mobile Workforce Management System

MWBS

Mobile Workforce Brokering System

Table 14 Specifications of DataProperties

MW

Mobile Workforce

No.

O-DC

Ontology-Driven Dynamic Coordination

O-PRS

Ontology-Driven Procedural Reasoning System

1

2

Symbol U0

U0,0

Specifications domain( ):

≥ 1U0

ORMC

Overall Realistic Monthly Capacity

range(D0 ):

∀U0 .D0

OWL

Web Ontology Language

RAL

Resource Allocation

RDF

Resource Description Framework

domain(C3 ), domain(C3,0 ), domain(C3,1 ): ≥ 1U0,0 C3 ≥ 1U0,0 C3,0 ≥ 1U0,0 C3,1 range(D1 ):

3

U0,1

∀U0,0 .D1


4

U0,2

∀U0,1 . D1


5

U0,3

∀U0,2 .D2


6

U0,4

∀U0,3 . D2

domain(C3 ), domain(C3,0 ), domain(C3,1 ): ≥ 1U0,4 C3 ≥ 1U0,4 C3,0 ≥ 1U0,4 C3,1

7

8

U1

U1,0

range(D2 ):

∀U0,4 .D2

domain( ):

≥ 1U1

range(D0 ):

∀U1 .D0

domain(C2,0 ) ≥ 1U1,0 C2,0 range(D1 ):

9

U1,1


10

11

12

U1,2

U2

U2,0

U2,1

∀U1,1 .D1


∀U1,2 .D1

domain( ):

≥ 1U2

range(D0 ):

∀U2 .D0


13

∀U1,0 .D1

∀U2,0 .D2


∀U2,1 .D2

RMC

Realistic Monthly Capacity

T-Box

Taxonomy Box

References 1. Chiu DKW, Cheung SC, Ho-fung L (2005) A multi-agent infrastructure for mobile workforce management in a service oriented enterprise. In: Proceedings of the 38th Hawaii international conference on system sciences, Hawaii, 3–6 Jan 2005, pp 85–95 2. Drake SD, Boggs R, Giusto MSR, Stacy K, Ryan SS (2008) Worldwide mobile worker population 2007–2011 forecast EXCERPT, IDC, IDC, #209883E. http://www.workshifting.com/ IDC_MobileWorker_excerpt_0_0.pdf 3. Van Der Aalst W, Van Hee K (2002) Workflow management: models methods and systems. MIT Press, Cambridge. ISBN:0262011891 4. Huhns MN (2002) Agents as Web services. IEEE Internet Comput 6(4):93–95 5. Huhns MN, Stephens L (1999) Multi-agent systems and societies of agents. In: Weiss G (ed) Multi-agent systems: a modern approach to distributed artificial intelligence, 3rd printing. MIT Press, Cambridge, pp 79–120. ISBN:0262232030 6. Rao AS, Georgeff MP (1995) BDI agents from theory to practice. In: Proceedings of the first international conference on multi-agent systems, ICMAS, San Francisco, USA, 12–14 June 1995, pp 312– 319 7. Hadzic M, Wongthongtham P, Dillon T, Chang E (2009) Ontology-based multi-agent systems. Springer, Berlin. ISBN:9783642019036 8. Weiss G (1999) Multi-agent systems: a modern approach to distributed artificial intelligence, 3rd printing. MIT Press, Cambridge. ISBN:0262232030 9. Mousavi A, Nordin M, Othman Z (2010) An ontology driven procedural reasoning system-like agent model for multi-agent based mobile workforce brokering systems. Int J Comput Sci 6(5):557– 565 10. Mousavi A, Nordin M, Othman Z (2010) An ontology driven multi-agent based framework for automated resource allocation in mobile workforce management systems. In: Proceedings of 4th IEEE international symposium on information technology, ITSim’10, Kuala Lumpur, Malaysia, 5–17 June 12010, vol 3, pp 1416–1421 11. Mousavi A, Nordin M (2007) An architectural model for a multi-agent mobile workforce brokerage system based on CBRBDI agent architecture and active shared-data space coordination


12.

13.

14. 15.

16.

17.

18.

19.

20. 21.

22.

23.

24.

25.

26.

27.

28.

model. In: Proceedings of the IEEE international conference on electrical engineering and informatics, Bandung, Indonesia, 17– 19 June 2007, pp 294–297 Schumacher M (2001) Objective coordination in multi-agent system engineering: design and implementation. Lecture notes in artificial intelligence, vol 2039. Springer, Berlin. ISBN:3540419829 Omicini A, Zambonelli F, Klusch M, Toksdorf R (2001) Coordination of Internet agents: models technologies and applications. Springer, Berlin. ISBN:3540416137 Malone T, Crowston K (1994) The interdisciplinary study of coordination. ACM Comput Surv 26(1):87–119 Ossowaski S (2008) Coordination and agreement in multi-agent systems. In: Proceedings of the 12th international workshop on cooperative information agents XII. Lecture notes in computer science, vol 5180. Springer, Berlin, pp 16–23 Lianzhong L, Xiangrong Z, Xu R (2008) multi-agent system coordination architecture and its use in electric power decision support system. In: Proceedings of IEEE international conference on industrial informatics, INDIN 2008 DCC, Daejeong, Korea, 13–16 July 2008, pp 731–736 Bouslimi I, Hanachi C, Tout H, Ghedira K (2008) A coordination framework for cooperative information gathering. Int J Adv Intell Paradigms 1(1):60–79 Brazier FMT, Mobach D, Overeinder BJ, Wijngaards NJE (2002) Supporting life cycle coordination in open agent systems. In: Proceedings of the MAS problem spaces workshop at AAMAS, Bologna, Italy, July 2002, pp 1–4 Papadopoulos G, Arbab F (1998) Coordination models and languages. In: The engineering of large systems. Advances in computers, vol 46. Academic Press, New York, pp 329–400. ISBN:0120121468 Gelernter D, Carriero N (1992) Coordination languages and their significance. Commun ACM 35(2):97–107 Huhns M, Singh M (2005) Research direction for serviceoriented multi-agents systems. IEEE Internet Comput November– December 2005:65–70 Bouaziz W, Andonoff E (2009) Dynamic execution of coordination protocols in open and distributed multi-agent systems. In: Proceedings of the 3rd KES international symposium on agent and multi-agent systems: technologies and applications. Lecture notes in computer science, vol 5559. Springer, Berlin, pp 609–618 Excelente-toledo C, Jennings N (2004) The dynamic selection of coordination mechanisms. Auton Agents Multi-Agent Syst 9:55– 85 Ferscha A (2003) Coordination in pervasive computing environments. In: Proceedings of the 12th IEEE international workshops on enabling technologies: infrastructure for collaborative enterprises, WETICE’03, Linz, Austria, 9–11 June 2003, pp 3–9 Tamma V, Van Aart C, Moyaux T, Paurobally S, Lithgow-Smith B, Wooldridge M (2005) An ontological framework for dynamic coordination. In: Proceedings of the 4th international semantic web conference, ISWC’05. Lecture notes in computer science, vol 3729. Springer, Berlin, pp 638–652 Moyaux T, Smith BL, Paurobally S, Tamma V, Wooldridge M (2006) Towards service-oriented ontology-based coordination. In: Proceedings of IEEE international conference on web services ICWS’06, Chicago, USA, 18–22 September 2006, pp 265–274 Jin L, Qinmin W, Daoli Z, Yihong H (2009) Multi-stage dynamic coordination model for large-scale crowd’s activities based on multi-agent. In: Proceedings of the WRI world congress on computer science and information engineering, CSIA, Los Angeles, 31 March–02 April 2009, vol 1, pp 487–491 Gang C, Zhonghua Y, Chor PL (2006) Coordinating agents in shop floor environments from a dynamic systems perspective. IEEE Trans Ind Inf 2(4):269–280

787

29. Johansson S, Davidsson P, Carlsson B (2000) Coordination models for dynamic resource allocation. In: Proceedings of the 4th international conference on coordination languages and models, Coordination 2000. Lecture notes in computer science, vol 1906. Springer, Berlin, pp 182–197 30. Jianmu Y, Chen L (2008) Ontology based coordination in RFID network. In: Proceedings of 4th international conference on wireless communication, networking and mobile computing, Dalian, China, 12–14 October 2008, pp 1–4 31. Cregan A, Mochol M, Vrandecic D, Bechhofer S (2005 ) Pushing the limits of OWL, rules and Protégé: a simple example. http:// dblp.uni-trier.de/db/conf/owled/owled2005.html#CreganMVB05 32. Vuong XT, Tsuji H (2007) OWL-T: an ontology-based task template language for modeling business processes. In: Proceedings of IEEE 5th international conference on software engineering research, management and applications, Busan, Korea, 20–22 August 2007, pp 101–108 33. Laclavik M, Babik M, Balogh Z, Hluchy L (2006) AgentOWL: semantic knowledge model and agent architecture. Comput Inform 25(5):419–437 34. Sycara K, Paolucci M, Soudry J, Srinivasan N (2004) Dynamic discovery and coordination of agent-based semantic web services. IEEE Internet Comput 8(3):66–73 35. Xin J (2005) Ontology-driven coordination for supply chain system. In: Proceedings of IEEE international conference on natural language processing and knowledge engineering, Beijing, China, 30 October–01 November 2005, pp 331–335 36. Bellifemine F, Caire G, Greenwood D (2007) Developing multi-agent systems with JADE. Wiley, New York. ISBN: 9780470057476 37. Sirin E, Parsia B (2007) SPARQL-DL: SPARQL query for OWLDL. In: Proceedings of the 3rd International workshop on OWL: experiences and directions, Innsbruck, Austria, 6–7 June 2007, pp 1–19 38. Horrocks I (2005) OWL: a description logic based ontology language. In: Van Beek P (ed) CP’05. Lecture notes in computer science, vol 3709. Springer, Berlin, pp 5–8 39. Baader F, Calvanese D, McGuninness DL, Nardi D, PatelSchnider PF (2003) The description logic handbook: theory, implementation and applications. Cambridge University Press, Cambridge. ISBN: 9780511066948 40. Simperl E, Kurmmencher R, Nixon L (2007) A coordination model for triplespace computing. In: Proceedings of the 9th international conference on coordination models and languages. Lecture notes in computer science, vol 4467. Springer, Berlin, pp 1– 18 41. Motik B, Grau BC, Horrocksa I, Sattler U (2009) Representing ontologies using description logics, description graphs and rules. Artif Intel 173(14):1275–1309 42. Horrocks I, Tessaris S (2007) Querying the semantic web: a formal approach. In: Proceedings of the 6th international semantic web conference, Busan, Korea, 11–15 November 2007, pp 177–191 43. Marshall MI, Alexander C (2005) Planning for the unexpected human resource risk and contingency planning. Online Journal of Purdue Extension EC-736. http://www.ces.purdue. edu/extmedia/EC/EC-736.pdf 44. Marshall MI, Alexander C (2006) Using a contingency plan to combat human resource risk. Online Journal of Purdue Extension. http://www.joe.org/joe/2006april/tt1.php 45. Marshall MI, Alexander C (2006) The risk matrix: illustrating the importance of risk management strategies. Online Journal of Purdue Extension. http://www.joe.org/joe/2006april/tt1.php