UNIVERSITA’ DEGLI STUDI DI TORINO Dottorato di Ricerca...

UNIVERSITA’ DEGLI STUDI DI TORINO

Dottorato di Ricerca in Informatica (XIV° ciclo)

Ph.D. Thesis

Alignment of meanings and of protocols as a form of articulation work in cooperation

MARCELLO SARINI

Advisor: PROF. CARLA SIMONE

Dipartimento di Informatica – Universita’ degli Studi di Torino

Corso Svizzera 185-I-10149 Torino (Italy)

http://www.di.unito.it/

Table of contents

i

Table of Contents Chapter 1: Introduction...................................................................................................... 1 Chapter 2: The ABACO conceptual architecture.............................................................13 2.1: Introduction..................................................................................................................... 13 2.2: ABACO: a conceptual architecture to support articulation work................................... 15

2.2.1: Agent basic features............................................................................................... 15 2.2.1.1: Agent internal architecture......................................................................... 15 2.2.1.2: The Agent Communication Language....................................................... 16

2.2.2: The Infrastructure level.......................................................................................... 17 2.2.3: The Application level............................................................................................. 19 2.2.4: More on the agents at the Application level.......................................................... 22

2.2.4.1: The Organizational and Operative contexts............................................... 22 2.2.4.2: The CAW agents........................................................................................ 23 2.2.4.3: The Active Artifact.................................................................................... 24 2.2.4.4: The Protocol agent..................................................................................... 24

2.3: The architecture in use.................................................................................................... 26 2.3.1: Interaction patterns at Template level.................................................................... 26

2.3.1.1: The Initialization phase.............................................................................. 27 2.3.1.2: Assigning Actors to Roles......................................................................... 28 2.3.1.3: Creation of constellations.......................................................................... 30 2.3.1.4: Creation of Application agents.................................................................. 31 2.3.1.5: Definition of Application agents................................................................32

2.3.2: Interaction patterns at Instance level..................................................................... 36 2.3.2.1: Execution of Tasks and Activities............................................................. 36

2.4: A first implementation of ABACO using Jafmas........................................................... 39 2.4.1: The Initialization phase.......................................................................................... 39 2.4.2: The main ABACO conversations.......................................................................... 40

2.5: Implementing ABACO in a richer concrete architecture............................................... 42 2.5.1: The concrete architecture....................................................................................... 42 2.5.2: About mapping conceptual and concrete architecture........................................... 45

2.6: Related work................................................................................................................... 50

Table of contents

ii

Chapter 3: Alignment of protocols..................................................................................... 53 3.1: Introduction..................................................................................................................... 53 3.2: Related work................................................................................................................... 54

3.2.1: Negotiation support................................................................................................ 55 3.2.2: Consistency check.................................................................................................. 56

3.3: The Modify CM: negotiating propagation of changes.................................................... 57 3.3.1: More on protocols.................................................................................................. 57 3.3.2: The approach.......................................................................................................... 59 3.3.3: The basic idea........................................................................................................ 62 3.3.4: Modeling partial visibility..................................................................................... 63 3.3.5: Changes without negotiation................................................................................. 65 3.3.6: Negotiating changes............................................................................................... 67

3.3.6.1: The hierarchy supporting change management......................................... 67 3.3.6.2: How to use the change hierarchy............................................................... 68 3.3.6.3: Acceptance criteria.................................................................................... 69

3.3.7: Negotiation is a distributed process....................................................................... 74 3.4: How to integrate in ABACO the Modify CM:............................................................... 76 Chapter 4: Alignment of meanings.................................................................................... 80 4.1: Alignment of meanings as a form of articulation work.................................................. 83 4.2: The Reconciler................................................................................................................ 84

4.2.1: The schemes........................................................................................................... 85 4.2.2: The conflicts.......................................................................................................... 90 4.2.3: The algorithm......................................................................................................... 100

4.3: Related work................................................................................................................... 116 Chapter 5: the support to alignment of meanings provided by the Reconciler in different scenarios.................................................................................. 123 5.1: An experiment to test the Reconciler.............................................................................. 124

5.1.1: The role of the Reconciler in the experimental setting.......................................... 125 5.1.2: The description of the experiment......................................................................... 129 5.1.3: Lessons learned...................................................................................................... 132

5.2: the integration of the Reconciler tool into the ABACO architecture............................. 134 5.2.1: The definition phase supported by the Reconciliation CM................................... 136 5.2.2: The communication supported by the Reconciler................................................. 140 5.2.3: The impacts on the underlying conceptual architecture........................................ 143 5.2.4: The current level of integration............................................................................. 145

Chapter 6: Achievements and future work....................................................................... 149

Table of contents

iii

References............................................................................................................................. 154 Appendix A: The Ariadne categories................................................................................. 162

Chapter 1: Introduction

1

Chapter 1:

Introduction The work presented in this thesis is rooted in a research effort in the area of Computer Supported Cooperative Work , that took place in the last years at the University of Milano and Torino in cooperation with researchers in Europe and in the US. This introduction aims to provide the conceptual and technological backgrounds necessary to clarify the contribution of the presented work.

The conceptual background

Cooperative work involves several actors who interact to jointly perform shared activities. Hence, it is intrinsically distributed. The concept of distributedness is widespread in computer science and refers to systems whose components are physically distributed in different sites in order to be more reliable and flexible, as well as logically distributed to represent complex systems as interactions of autonomous parts (Shaw et al. 1996). Distributedness can be related to database systems too, by considering distributedness of data. Here, the aim is to give applications uniform access to data which can be heterogeneous in terms of models describing them and in terms of meaning associated to their descriptions (Kambayashi et al. 1991). Since the 80s distributedness was used to describe also human actors working in organizations. The first applications taking into account this idea were related to Office Automation Systems and Information Systems. In the former case the approach followed a bureaucratic conception of organizational work: work is regulated by a set of fixed procedures which have to be “simply” followed step-by-step by the involved people (e.g.,. XCP (Sluizer et al. 1984) and DOMINO (Victor et al. 1991) systems). Though in some specific situations this could be the case, work procedures and the consequent practical actions carried out by workers need a higher degree of flexibility. Consider for instance the situation described in (Schmidt 1997). In order to deal with the complexity of a manufacturing process concerning products composed by many components which, in turn, may require a number of interdependent production processes in a specific sequence, the production managers introduced a kanban system1 to coordinate these processes. Though the system was able to coordinate the different production processes predefining the interdependencies among the different tasks and the use of the different assembly machines, the experience showed that the actors involved in the processes needed to change the definitions of the interdependencies in order to deal with exceptions and to improve the production according to specific workloads. On the other hand, Information Systems considering distributed actors have been designed in order to let people work on shared data, as for example in systems for flight tickets reservations allowing different operators to book tickets on the same flights. Usually these systems do not provide

1 Kanban is a japanese word for card which is widely used to denote a just-in-time production control system regulating the coordination of manufacturing processes.


2

different users with the sense of presence of the others working on the same shared data in order to collaborate. In the situation of ticket reservation this is not a problem because collaboration among actors is not needed. However, in other cases the mutual transparency of users hinders their collaboration. Consider for instance a group of researcher working on the definition of a shared reference file. In this situation it is useful not only provide them with lock control of the file, but also to consider additional features in order to let the involved researchers know who is working on the file, which reference is added, edited or deleted, and also to allow researchers to interact in order to establish the suitable formatting style of the references. Moreover, also when distributed systems incorporate collaboration supports, often the latter are transparent to the users. In fact, the aspects involving the policies of control of the functionalities provided by the different system components are usually hidden to users, in this way preventing them from a conscious and explicit collaboration (Rodden et al. 1991). At the beginning of the 90s researchers, expecially from social sciences (Gerson et al. 1986; Schmidt et al. 1992; Suchman 1987), focused their field research on how technology was used to support collaborative work and concluded that the available technologies were not flexible enough to cope with the dynamicity of the considered work settings. These critical observations led, among the others, to the birth of a new research area, called Computer Supported Cooperative Work (CSCW). As reported by (Schmidt et al. 1992) “CSCW should be conceived as an endeavor to understand the nature and requirements of cooperative work with the objective of designing computer-based technologies for cooperative work arrangement”. Hence, the goals of CSCW are twofold: on the one hand, to study the social mechanisms governing the collaboration among human actors; on the other hand, on the base of these empirical studies, to design suitable technologies supporting the social mechanisms whenever the complexity of collaborative settings requires more than simply relying on them. These goals focus on the concept of cooperative work, which has a long tradition in social sciences. Marx in 1867 defined cooperative work in terms of “multiple individuals working together in a conscious way in the same production process or in different but connected production processes” (cited in (Schmidt et al. 1992)). At the core of this conception of cooperative work is the notion of interdependence in work, which is however insufficient to describe the essence of cooperation. A new definition is proposed, which shifts from the more general concept of interdependence to the stronger concept of mutual dependency: “people engage in cooperative work when they are mutually dependent in their work and therefore are required to cooperate in order to get the work done” (Schmidt 1991). Here mutual dependency does not refer only to the interdependencies that arise by simply having to share the same resource (e.g. time-sharing systems where there is user-transparency). In fact, “being mutual dependent in work means that A relies positively on the quality and timeless of B’s work and vice versa and should primary be conceived of as a positive, though by no means necessarily harmonious (e.g. conflicting) interdependence” (Schmidt et al. 1992). In other words, cooperative work implies mutual dependency. The cooperating actors in a given cooperative work arrangement are interdependent in their work in the sense that one actor’s action will change the state of a set of objects and processes and, in turn, this change of state has implications, directly or indirectly, for the work of the other members in the ensemble and vice versa. The above general definitions do not highlight the peculiarities characterizing different cooperative work settings and the consequent needs for a suitable technological support.


3

In the CSCW literature distinctions related to cooperative work settings usually refer to the co-location of the people involved in the collaboration, that is whether they mostly interact during their work being face-to-face or not. In the former case, the involved people share the same work context, capture the gestures, the non verbal-communication, use the social mechanisms of interaction allowing them to obtain articulation of their activities and the solution of the possible conflicts. As reported in (Schmidt 1997) actors in small ensembles do not require any additional effort (and supporting technology) in order to collaborate, because the work setting provides them the “medium” to articulate their different interdependent activities. Instead, actors are distributed when they do not work at the same time or in the same space. In this case, distributedness increases the complexity of the collaborative settings and reduces the effectiveness of the social mechanisms people spontaneously apply . This situation has been described in (Simone et al. 1998) emphasizing that none of the actors can be all-knowing and all-powerful. For what concerns knowledge, actors must act and interact on the basis of their local and partial knowledge of the setting, and they do not know the global consequences of their actions. Moreover, due to the mutual dependency discussed above, they are partially autonomous in their work and limited in their actions. Since distributedness reduces the positive influence of the social mechanisms that rely on co-location of actors, the articulation of activities and the solution of conflicts among the involved actors are more complex. Hence, since actors lack of a common work context, they require doing an explicit additional effort in order to articulate their distributed interdependent activities and to solve the possible conflicts. This effort is called Articulation Work (Schmidt et al. 1992). The increased complexity in managing articulation work in distributed settings is illustrated by the case reported in (Schmidt 1997). It refers to a project where a team of engineers is involved in the design of a new complex product combining software and mechanical parts. This project defines a large-scale cooperative setting where the complexity of managing work interdependencies is increased by the distributedness of people. In fact, the involved engineers realized that the social mechanisms they used in previous settings to govern collaboration were not effective enough and introduced additional aids, in terms of artifacts and related procedures, in order to cope with the complexity of their articulation effort oriented to monitoring and control of their interrelated activities. Articulation work, that is, the effort to articulate interdependent distributed activities, is distinct from cooperative work, that refers to the ongoing activities in the field of work This distinction allows articulation work to be supported as an independent process that manages the coordination of interdependent activities abstracting from the cooperative work setting they belong to. The same idea is applied in software engineering where, for the same reasons, coordination languages (Papadopoulos et al. 1998) are used to separate the aspects related to the definition of coordination from the ones concerning the definition of actions. Strange enough, almost all technologies proposed in CSCW do not consider clearly this separation reducing in this way the capability of the provided support to manage the two aspects in a separate way. In the above view, articulation work is an additional effort that requires being justified. Each activity people perform during their work requires an effort and since always people try to reduce the effort associated to their work. This is the history of technology and of the tools people invented to this aim. We can classify different kinds of effort associated to work. For what concerns the people involved, the effort can be individual or cooperative. In the first case effort is related to individual activities people fulfill according to their duties and skills. In the second case, the effort


4

is a joint activity performed by a group of people to accomplish their interdependent tasks. Considering instead the involved tools, defined here as any kind of material or conceptual artifact people design and use to reduce their work efforts, we can raise a question: why people are willing to make efforts in using a tool? The answer can be twofold. To be supported in the completion of a complex activity. Imagine for instance the use of satellites with devices to discover cosmic X-ray sources to recognize the presence of black holes in the Universe. Tools of this kind can be classified as essential, since without them the supported activity can not be completed (probably neither imagined). To reduce the effort of doing an activity. Consider a calculator device for performing mathematical calculations. We can do sums without a calculator, but we can reduce our effort using it. This kind of tool is not essential in the above considered sense, rather it is useful. We accept using a tool if the related effort it is not harder than the completion of the same activity without using it. If our calculator worked only with binary digits, probably we did not use it since we need to translate each number from decimal to binary. We can distinguish between two kinds of effort in using a tool: conceptual effort and usage effort. In the second case, the effort is strongly related to the tool design, that is how natural is for us to use that tool. This interpretation is related to the concept of “affordance” proposed in cognitive design (Norman 1990): affordance is the ability of a tool of suggesting us its use according to its “shape”. On the other hand, conceptual effort is related to the conceptualization of the current situation needed in order to get the support provided by the tool. The difference among conceptual effort and usage effort can be illustrated considering the effort needed to use a database system with encompasses a data model and a user interface, and the effort needed to model the database schemes which represent the part of the world we are interested in. While the first kind of effort is related to the “shape” of the tool (that is in this case to learn how the user interfaces are designed, which are the features of the data model, which is the language it provides the user with to model the world) and can be reduced with the experience of use, the second kind of effort involves more substantially the user knowledge and skill, and is required each time a new model of the world is needed (although some experience in modeling can help in reducing this effort). According to this classification we can refer to articulation work, as an effort which is collaborative, essential and conceptual. In fact, since the activities which need to be articulated are interdependent and each of the involved people mutually depend on the work of the others, also the effort to articulate this activities is collaborative. This kind of effort is essential, in the sense that the resulting artifacts are able to reduce and manage complexity of articulating activities which can be impossible without this effort. Finally, it is conceptual in the sense it is not related to the use of the artifact, but to the conceptualization and modeling of articulation work activities which changes according to the considered situation. Since the effort related to articulation is a collaborative activity, actors are involved in the discussion to define the articulation of the distributed interdependent activities and in some cases they have to negotiate to solve the related conflicts. Hence, this effort could need in turn to be articulated, showing in this way the recursive2 nature of articulation work (Schmidt et al. 1996).

2 This term was used in an informal way and reported here for consistency. Formally, it could have been called “reflective”.


5

Moreover, since the pertinent actors are distributed, articulation work is a distributed activity too. As a consequence of the above considerations, technological supports to cooperative work can be applied to support articulation work, at a higher level, guaranteeing a smooth transition from a level to another one.

The technological background

The above considerations are the basis of a conceptual and technological framework whose development started within the COMIC project3. The framework focuses on articulation work and specifically, on those aspects that are related to the design of a flexible support following the requirements of flexibility claimed in the CSCW literature (see for instance (Klein (editor) 2000)). We will come later on this point. Here we want to clarify some basic characteristics of the approach distinguishing it from other proposals. According to the key ideas of CSCW, the approach aims to support human actors in their articulation effort, and looks for a solution that combines flexibility with a user-centered strategy. This means to provide actors with the ability to perform the articulation of their activities when and in the way they need considering their work context, and not to provide them with predefined and rigid articulation patterns. Consider for instance the case of planner systems developed to support production processes (see i.e. (Russell et al. 1995)). These systems are often very flexible in terms of plan definition and are able to dynamically change the proposed plans according to the current situation. They automatically articulate activities imposing a decomposition of work in tasks. The latter are then assigned by the system to actors according to some predefined strategies the involved actors cannot control. Hence, this kind of solutions lacks to involve actors in the planning effort. Again, these solutions can be read in terms of reducing the users’ effort in modeling the articulation needed. But this is not a real advantage, since “no representation of the world is either complete or permanent” (Gerson et al. 1986), that is, any representation needs to be completed by the actors according to their current context. This implies that actors have to be provided with technologies supporting them in the articulation effort with means that are at their semantic level. The choice to support articulation work focusing on actors and their semantic level leads to take into account the artifacts they build to this purpose. For centuries people have relied on ad hoc, paper-based artifacts defined to explicitly support the articulation of their interdependent activities. Examples are timetables, checklists, routing schemes and so on. Artifacts can be seen as informational structures built by actors to codify consolidated practices in order to support the articulation of their activities. Notice that, in this view, artifacts are not related to the activities pertinent to the field of work. On the contrary, their role is to objectify an agreed protocol determining the coordination of distributed activities, and providing in this way a support to articulation work. The strict connection between protocols and artifacts is captured by the concept of coordination mechanism (CM), which is defined as “a construct consisting of a coordinative protocol (an integrated set of procedures and conventions stipulating the articulation of interdependent distributed activities) on the one hand and on the other hand an artifact (a permanent symbolic construct) in which the protocol is objectified” (Schmidt et al. 1996). From the observations of how people define and use different coordination mechanisms in order to

3 Esprit BRA-Comic (Coordination Mechanism in Cooperative Work) project (1993-1995).


6

reduce and support the complexity of articulation work, these authors identified recurrent categories and recurrent patterns of interactions among them. On this basis, they proposed a notation by which users can define the CMs needed to support the articulation of their activities. The notation, called Ariadne (Divitini et al. 2000), provides human actors with a set of categories, called Categories of Articulation Work (CAW), which can be composed in order to define CMs. Every single category can be considered as a class representing some aspects of articulation work, e.g. Roles, Resources, Tasks, and is characterized by a set of attributes referring to some properties of the category, or expressing relations with other categories. Moreover, each category is equipped with communication capabilities which are expressed in a uniform language provided by the notation. The communications among categories represent both coordination among interdependent activities to be performed in the field of work and awareness information to be propagated among actors. Ariadne proposes also a construct, called Active Artifact, which extends the concept of artifacts described above with active coordination capabilities using the communication capabilities provided by the notation. Being the results of the observation of real work in the field, the notation aims to provide human actors with the right semantic level of articulation work that is the one they used during articulation of their activities. Let us now consider flexibility in the construction of CMs , since it is one of the main requirements the notation has to fulfill in order to be effectively useful during the life-cycle of CMs: from their definition to their enactment and execution, in order to support users not only in the articulation of their activities, but also in using the defined support in order to perform their activities accordingly. The flexibility provided by the notation encompasses different dimensions. Languages: CMs are defined by the composition of a different set of Categories of Articulation Work chosen by the actors according to their articulation needs. In fact, not all the situations require the same CAWs to achieve articulation. Consider for instance two cases. In the first case, articulation can refer to the execution of Tasks related to a quality control process involving some specific Roles executing specific Activities. Consider the scenario where some workers in a control room are in charge to evaluate whether the complex products, which have been just carried out by some production plants, fulfill the quality parameters required to be sold. In this situation, a Quality Control Supervisor Role is responsible for the overall Task of evaluating a single product. Since the product is complex, the evaluation of the supervisor is given on the basis of the results of different kinds of Tests (Task) each distinct Tester (Role) performs according to her skills and machinery. Each of the Roles involved in the corresponding Task chooses a product to be evaluated from a pool. In this situation a product can be picked up from the pool without any order because each Test can be performed without following any preordered sequence. The product itself, through a technical form associated to it, conveys to the involved Roles the (awareness) information about the Tests performed on it. This information provides the involved Roles with the articulation of their activities. In fact, a Tester performing a specific Test is able to choose from the pool a product which still need to be subjected to this test. Each Test is then described in terms of a sequence of predefined Activities which the involved Tester has to complete. In the same way, the Quality Control Supervisor is able to pick up the products which received all the required Tests and hence need her final evaluation Task. Again the latter is expressed through to a specific sequence of Activities the Supervisor has to complete. In the second case, articulation is required to manage the review process of documents like project proposals. In this situation, Reviewers (Roles) can achieve the articulation of their review activities


7

filling in and circulating the review forms (Resources) related to the documents under concern. Notice that the composition of CAWs provides a weak implicit protocol which supports the articulation of activities, thanks to the coordination capabilities of the involved CAWs regulating the flow of work related to these activities. On the contrary, in situations where the composition of the CAWs does not provide enough support to the coordination of activities, Ariadne provides an explict construct, the protocol category, to define more complex dependencies among CAWs through an explicit representation of the flow of work. Incremental design: definitions of CMs can be completed by actors in a fully incremental way, since they can specify the values of the attributes and the communication of the categories of the chosen language at any time. This kind of flexibility is in accordance with what reported in (Schmidt 1997) about formal constructs defining articulation of activities which must be completed according to the current situation. Notice that incremental design allows the definition (and the modification) of the involved CAWs during execution of CMs. In fact, any CAW does not need to be fully specified before it is enacted or executed. Everything but its name and the Role responsible for its definition could be in principle unspecified, allowing, in this way, the maximum level of flexibility at enactment and execution time (Divitini et al. 2000). There is a further kind of flexibility related to incremental design associated to the statement of Suchman (Suchman 1987): “plans are resources for situated actions, but do not in any strong sense determine its course”. In fact, CAWs are grouped into two groups4. In the former group they are used as resources representing organizational constraints for the CAWs belonging to the second group which represent the situated actions which are then defined contextually according to current situation in the field of work. Modifiability: since “no representation of the world is either complete or permanent“ (Gerson et al. 1986) the defined CMs have to be modified when they do not reflect the current articulation needs any more. Hence, Ariadne provides actors with the possibility to modify CMs. Modifiability poses further requirements, which will be discussed in more details later, on the ability to manage the conflicts arisen as a consequence of the proposed modification. Visibility is strictly related to the fact that CMs do not act in a vacuum, but they are part of the organizational setting. In this view, each of the involved human actors is associated with different responsibilities according to her role in the organization. Hence, visibility means that the notation takes into account this situation providing actors with different abilities of definition and modification of CMs according to their duties and responsibilities in the organization. Uniformity for the definition of CMs: the notation provides actors with three common interaction modes allowing them to compose the different constituents of Ariadne in the same way at any level. These interaction modes was identified as the results of a comparative analysis of field studies on how various types of coordinative artifacts are jointly used by cooperating actors (Divitini et al. 1996). They specify the kind of interactions among the actors involved in cooperation: inscription, prescription, and subscription. The aim of inscription is to support cooperation providing actors with the ability to exchange information in absence of any global information they can access. Prescription provides actors with the ability to overwrite the components of the notation supporting in this way the management of definitions and modifications of CMs. Subscription is related to the ability of actors to invoke the concurrent execution of the behaviour of another CAW or CM.

4 Schmidt (Schmidt et al. 1996) defined these two groups as nominal and actual status of the CAWs.


8

This uniformity produces two forms of compositionality: horizontal compositionality and vertical compositionality. Horizontal compositionality can be applied at two different levels. First, it applies to the definition of a single coordination mechanism: in this view, each different CAW can be composed with others relying on the common modes of interaction and on the uniform language expressing communication capabilities of the CAWs. Second, horizontal compositionality applies to the composition of different coordination mechanisms allowing one to consider a bottom up approach in the definition of CMs. In fact, they can be composed in turn into compound CMs to represent more complex articulation settings, involving additional actors, often belonging to other organizations. Notice that this kind of compositionality reflects the distributed nature of articulation work because each CM can represent articulation of activities in local organizations and their composition into compound CMs can express the articulation of activities across distributed organizations. Vertical compositionality, instead, takes into account the recursive nature of articulation work. In fact, since each level of articulation work can be articulated in turn, at a higher level, actors involved in a CM, using the subscription mode provided by the notation, are able to activate the coordination mechanism representing a higher level of articulation work in order to define the articulation needed a the lower level. Ariadne provides actors with a notation to construct the needed CMs that has to be implemented in a technological support able to guarantee the functionalities necessary to fulfill the above requirements. The high modularity and compositionality characterizing Ariadne suggested, from the very beginning (Divitini et al. 1995), to base its implementation on a multi-agent architecture, called ABACO (Agent-Based Architecture for COoperation). In this effort, the uniform kinds of interaction described above supported the identification of an Agent Communication Language (ACL) associated to it. ABACO can be considered as the operational semantics of Ariadne representing the meaning of the CAWs and of their compositions at any level, in terms of agents’ interactions. ABACO is a conceptual agent-based architecture, that is, without any reference to a specific agent technology, with the only concern to fulfill the requirements imposed by Ariadne. In fact, ABACO reproduces all the above-mentioned characteristics of Ariadne and in particular it allows, without imposing, a bottom-up construction of the technological support of articulation, at any level of composition. The basic intuition underlying ABACO is that each CM can be effectively decomposed into constellations of independent agents that collaborate and exchange information using an expressive communication language. In this view, each agent represents a category of articulation work. Each attribute expressing relations with other categories and each communication expressing coordination or awareness information are transformed into agent’s behaviors expressed in terms of communication scripts built using the primitives of the common agent communication language. The definition of the conceptual architecture was followed by a first implementation of a prototype using Jafmas, a platform to develop multi-agent applications (Chauhan 1997). The leading idea in this framework is that agents’ behaviors are expressed in terms of conversations. Conversations are modeled as automata where nodes represent the current state of the conversation, while arcs represent conditions (expressed on internal values of the agent or on communication from other agents) which, when true, allow the change of state of the conversation. Basically, this implementation transforms into Jafmas conversations the scripts written in ABACO’s ACL, that


9

represent the behaviors of the agents and their aggregations.

The contents and structure of the thesis

The contribution of the thesis to the conceptual and technological framework described above goes mainly in two directions: towards a new implementation of ABACO and the integration in it of specific functionalities focusing on what we call alignment of protocols and alignment of meanings. Here below, we sketch the basic aspects respectively, and give the main structure of the thesis. The prototype mentioned above exhibits a behavior complying with the described design principles. However, it still lacks to implement the full potentiality of the ABACO conceptual architecture. On the one hand, in terms of development, not all the described agents have been fully implemented. On the other hand, Jafmas does not provide all the characteristics needed for a full implementation of ABACO, like reflection capabilities and the ability for the agents to create other agents. These limits led us to look for a better environment to fully realize the features of ABACO. Specifically, we need a robust platform endowed with modularity, support for dynamic communication protocols, and especially reflection, to allow us to express the claimed requirements. We are currently considering RTP (Micucci et al. submitted), a platform developed at DISCO in Milano, which shows the above characteristics together with mobility features and has been used in industrial applications. This choice led us to revise the definition of the ABACO architecture, and specifically to complete the definition of the scripts describing the agents’ behaviors according to the reflection capabilities of the ACL in order to fully capture the characteristics of Ariadne in supporting CMs’s lifecycle (Divitini et al. to appear). Hence, Chapter 2 presents ABACO, starting with the description of the internal structure of the single agents and the common ACL by which they interact. Then, the overall characteristics of the new architecture are described together with its structure which encompasses two levels: the Infrastructure level supporting the basic functionalities to let the agents interact, and the Application level which is specific for the application to be designed. Specifically, the final sections show a detailed description of a selection of ACL scripts representing the basic behaviors of the agents and how they can be realized in RTP. In the subsequent chapters we focus on articulation work which provides the activities in the field of work with the needed coordination (see Figure 1.1). Since articulation work is a cooperative activity involving distributed actors, the latter reflecting the distributedness of underlying field of work, it is likely that conflicts arise, that require to be solved in terms of negotiations among the involved actors. Since negotiation is a cooperative activity in turn, it can be supported by specific coordination mechanisms whose protocols represent the way in which the involved actors negotiate to agree on a solution of the discussed conflicts and whose artifacts, objectifying the protocols, keep the information structure needed to support the negotiation process. ABACO allows the defined coordination mechanism to be dynamically added as a new component of the application and provides features to modify the other agents in order to provide immediately the involved actors with the related functionality. In particular, we consider two kinds of negotiations that become part of the articulation work performed by actors belonging to distributed organizations to articulate their activities.


10

The first form of articulation work is a consequence of horizontal compositionality and in particular of the modifiability imposed by the dynamicity of the field of work. In particular, we consider the changes of protocols inside a CM, focusing in this case on situations requiring a strong support for the coordination of the related activities. Since actors belonging to the different local organizations are distributed, any change they propose for a protocol happens under a regime of partial autonomy and partial visibility. The former means that local behavior is, on the one hand, fully under the control of the actor authorized to perform the modification, but on the other hand, is inextricably interlaced with the local behavior of the other protocols with which it interacts. Partial visibility means that each actor performing the modification has different degrees of visibility of the other protocols that are directly or indirectly affected by the change. This means that each actor acting under these conditions, when proposes a change, is not able to foresee the consequences of the proposed change on the other agents belonging to the protocols interacting with the changing protocol. In this situation some conflicts arise as a consequence of the modification of agents in protocols not desired by the responsible actors, but generated by a propagation of an initial proposal of change. According to visibility, a modification is an activity in charge of some specific actors who have to be involved, according to the propagation of changes in the components they are able to modify, in a negotiation process in order to handle the correct propagation of changes and solve the related conflicts. We call this negotiation alignment of protocols.

Figure 1.1 different levels of articulation work

Since this negotiation process is an effort representing the articulation work needed to keep aligned the different protocols, we propose a specific coordination mechanism which is able to provide support to the involved actors for the management of this articulation activity (see upper part of Figure 1.1). In this case the coordination mechanism provides the actors responsible for the

field of work

distributed activities

articulation work

CM

distributed activities

CM

negotiation negotiation

articulation of activities articulation of activitiesarticulation w

ork

compound CM

negotiation

definition/ modification

CM definition/modification CM alignment of protocols CM alignment of meanings

CAWs’ interactions CAWs’ interactionsCMs

propagation of changes alignment of meanings


11

modification of the agents affected by an initial proposal of modification with a protocol supporting their negotiations. Moreover, it keeps in an artifact the information structure needed to support this negotiation process. More precisely, in this situation we need a support able to notify the actors involved in the propagation of changes in order to call them to negotiate. Moreover, the support needs to inform each involved actor on how the modification on the component she can perform is constrained in order to keep the interacting protocols consistent according to the propagated changes. In addition, the support should be able to evaluate each proposed modification according to the current constraints in order to help the involved actors in the continuation of the negotiation process. In Chapter 3 we discuss in details the solution we propose to handle propagation of changes. The second form of articulation work, strictly related to horizontal compositionality, refers to the articulation needed when collaboration in a larger organization is obtained as interactions among actors belonging to different local organizations. Again, considering distributedness and its consequences, actors involved in different coordination mechanisms supporting local organizations have a local context of work which represents only what happens in the local organizations and is partial. Hence, they do not share the same context of work, even if they have to collaborate. This means that during collaboration they can use different terminologies, professional terms, and jargons according to their local context of work. Moreover, since the actors’ local descriptions of the objects belonging to the common space of collaboration heavily depend on their local contexts of work, actors can make use of different concepts and consider different levels of abstraction in their descriptions referring to the same objects. Hence, during communication devoted to collaboration, actors belonging to different organizations may misunderstand the concepts used in the communication, and this misunderstanding may compromise collaboration. The kind of communication misunderstandings encountered may be related to the meaning of the single terms used in communication or may refer to ambiguities which are consequence of the different meanings and uses of the elements constituting the local descriptions of the common objects. To solve these problems, that are the consequence of the disalignment of meanings among actors belonging to different local contexts of work, we propose another form of articulation work, which is again, a negotiation process among the involved actors. Local concepts and descriptions used in different contexts of work are compared in order to find correspondences among elements constituting them and where the possible conflicts arisen as a consequence of the established correspondences can be solved. We call this negotiation process alignment of meanings. In Chapter 4 we discuss this negotiation process aiming at alignment of meanings and present the tool we developed to support the involved actors in this effort. In Chapter 5 we present the use of the tool in different situations. We consider both an experimentation of the tool and its integration in terms of coordination mechanisms inside the ABACO architecture. In the latter case, the involved actors will be provided with a suitable coordination mechanism incorporating a protocol supporting them in the negotiation process needed to solve the disalignment of meanings in their local contexts of work (see upper part of Figure 1.1). The corresponding artifact is an information structure keeping the information defined during the alignment of meanings, that is the established correspondences among concepts and elements of the different local descriptions, and the methods defined to solve the detected conflicts consequence of these correspondences. Then, the information collected in the artifact is used by the support in order to help actors in reducing communication misunderstandings;


12

this is done by the support presenting to the receiver of the communication the notions used by the sender expressed in terms of her local context of work, when possible. When this is not possible the support involves the sender and the receiver of the communication in order to solve the not managed ambiguities. A concluding chapter highlights the next steps of this research effort.

Chapter 2: The ABACO conceptual architecture

13

Chapter 2:

The ABACO conceptual architecture

2.1 Introduction As anticipated in Chapter 1, we are interested in supporting actors involved in interdependent and distributed activities in order to reduce the complexity of their articulation work effort by making reference to the notion of Coordination Mechanisms (CM), the notation to define them and finally, the ABACO architecture supporting their construction. This chapter presents the second version of ABACO, as the basis to realize its new implementation. The redefinition of ABACO (Divitini et al. to appear) led to a better understanding of the role of agents in the design of CSCW applications: agents are not only useful from the engineering point of view but also support a systemic approach in the design of CSCW applications to be used in cooperative settings. The latter, a special kind of real systems, show a complexity which arises from the following properties. First, they are difficult to be specified in terms of properties of global states: in fact, the latter cannot be identified because real systems are inherently distributed. Second, and in consequence of that, modeling can consider local behaviors only and obtain global behaviors as emergent properties generated by the local behaviors and their interactions. Finally, real systems are always embedded in and interacting with a broader environment: in this respect they are open to it and subject to the perturbations it generates. Agent technologies can support a systemic approach since they focus on locality, interaction and sensitivity to the environment. These characteristics fit the above properties in a natural way. Hence, ABACO uses a multi-agent approach where agents are heterogeneous, that is equipped with different local behaviors. Agents can be grouped in constellations where agents locally cooperate to accomplish logically related tasks, possibly interacting with agents belonging to different constellations. There is a class of agents, playing as Receptionists (Agha et al. 1987), managing the interaction with the cooperative setting: they are collecting from it and distributing in the pertinent constellation(s) the related information as well as giving back to the cooperative setting possible output information. Each agent owns a local memory to record its current state and the content of the received messages. Hence, the approach is fully distributed since there is no global data that can be accessed and there is no global control on agents that are executed concurrently. Moreover, there is no global representation of the cooperative setting: each agent owns in its memory the kind of pertinent information it is responsible for. Finally, the behavior of an agent is specified in terms of communication patterns (through a specialized Agent Communication Language) that follow the sensing/reacting paradigm, typical of the class of tropistic agents (Genesereth et al. 1994) or of the Actor Model (Agha et al. 1987). Each agent is sensing/reacting to (able to receive/send information from/to) an environment that is constituted of the agents of the constellation it belongs to, the agents of other constellations and the external environment through the Receptionist agents. The proposed approach shares many basic features of the approach rooted in the seminal work by


14

Brooks (Brooks 1991), and considers agents as situated in a logical abstract space (Ferber et al. 1996; Werger et al. 2001). As in these cases, the autonomous and intelligent behavior emerges from elemental local capabilities combined with the perturbations generated by the environment on agents’ local behavior. Looking at a CSCW application as an artificial component acting in the physical and logical space of the cooperative setting and defining its behavior as a property emerging from its capabilities and its interactions with this environment is fully compatible with the phenomenon that has been described as evolutionary use of a technology (Kahler et al. 2000). According to this set of empirical evidences, the true functionality of an application evolves together with the use its users are willing to make of it. Often their use is fully unanticipated (Robinson 1993), or at least not fully coherent with the initial goals of the designers. The reactive agents characterizing our approach are particularly suitable to comply with the above perspective. Specifically, ABACO was designed bearing in mind the requirements of flexibility imposed by the distributed nature of articulation work illustrated in Chapter 1. In our effort to design a suitable architecture providing users with a support to articulation work, we decided to keep separated the ABACO architecture from the implementation details entailed by a concrete architecture. This choice was made in order to take advantages both of a top down approach (from requirements to conceptual architecture capturing them) and of a bottom up approach (from a general purpose and robust concrete architecture to applications built on the basis of the conceptual one). In this way, we can look for concrete architectures providing the designers with suitable features in order to fully implement the ABACO’s characteristics. Once identified a concrete architecture, the implementation effort can be based on the definition of a (conceptual) mapping among the two architectures. A first prototypical implementation was developed using the Jafmas multi-agent framework (Chauhan et al. 1998) as a concrete architecture. In this implementation, aggregation of agents representing coordination mechanisms were represented in terms of agents’ federations and the scripts representing agents interactions in terms of conversations. Unfortunately, the selected framework did not incorporate all the characteristics of the ABACO architecture especially in terms of “dynamicity” and incremental design that a framework with reflection capabilities could provide. In order to define a mapping able to consider all the features of ABACO’s architecture we focused on the RTP (Real Time Performer) architecture (Micucci et al. submitted), which is a general purpose architecture for the development of strongly modular and configurable distributed systems with reflection capabilities. The chapter is organized as follows. Firstly, we present the ABACO conceptual architecture. This description encompasses both the characteristics of a single agent and the structure of the architecture. Each agent is expressed in terms of internal structure and of the uniform agent communication language providing interoperability among different agents. For what concerns the structure of the architecture, ABACO considers two different levels: Infrastructure and Application levels. In this way it is keeps a clear separation between general aspects which refer to the management of a multi-agent architecture from the ones specifically related to the support of articulation work. Then, we describe a selection of standard interaction patterns among agents to sketch how the architecture is able to provide the desired functionality. The last two sections describe two concrete architectures and the mappings proposed between them and ABACO. The first section illustrates the mapping of ABACO with Jafmas and then outlines the associated


15

prototype. The second section describes the RTP concrete architecture and the conceptual mapping with ABACO. The chapter ends with related works concerning the use of agent based architectures to design applications supporting cooperative work.

2.2 ABACO: a conceptual architecture to support articulation work In order to support articulation work following the systemic approach illustrated in the previous section, we define ABACO as a multi-agent architecture whose components are reactive agents sharing a common language. The architecture is organized into two levels in order to keep conceptually separated the generic services from the ones more specific to the support of articulation work. The first level is called Infrastructure level. First, it provides generic services that are needed in any multi-agent system, such as the management of the naming space and the support for the interaction between the application and its users. Second, since articulation work involves tasks requiring the cooperation of many agents, the Infrastructure level provides agents that are specialized in supporting the cooperation among agents grouped into constellations, and among various constellation grouped into compound ones. This allows the designer to structure cooperative applications as a recursive composition of basic components (agents): the basic agents can be identified and grouped together into constellations to construct aggregated components realizing specialized applications. Constellations can be composed recursively to build further levels of aggregation of cooperative applications. Notice that, at the Infrastructure level the agents that are to be used as basic components at the second level are represented as placeholders. The second level, called Application level, allows the designer to specialize the generic agents (placeholders) identified at the Infrastructure level and the related communication patterns. At this level agents are the basic building blocks specialized for the design of applications supporting articulation work. Through the functionality provided by each level, it is possible to group agents into constellations to design coordination mechanisms that take into account the articulation needs of actors belonging to local and distributed organizations. In the following section we present the basic features of ABACO agents. These features are common to both levels. We then present the Infrastructure and the Application levels in details.

2.2.1. Agent basic features Agents in ABACO are characterized by their internal architecture and by the language they use. The language plays a key role since it is the unifying element that makes possible the interaction among various agents, or constellations of agents. These interactions define their behaviors of both agents and constellations of them.

2.2.1.1. Agent internal architecture

An agent is composed by local data and communication. The former contains its internal state and the latter its communicative behavior (see Figure 2.2.1). The internal state of an agent is expressed in terms of the values of a list of attributes characterizing the agent. Moreover, each agent contains a local working memory used to store information needed for its behavior: typically information gathered through communication. As anticipated in Section 2.1, there is no global representation of the setting where agents operate and each agent contains in its local data all the information that it is responsible for. The communication capabilities are expressed in terms of scripts containing


16

conditions that are evaluated on the local data or on communication received from other agents and triggers a communication with other agents or modify the local data of the agent.

Figure 2.2.1: Agent’s internal structure

2.2.1.2. The Agent Communication Language

The behavior of every agent is expressed in terms of scripts that follow the ACL syntax described in Table 2.2.1. The behavior of an agent is the result of processing incoming messages. The latter are characterized by the type of ‘task’ they refer to and by additional information allowing the task to be performed by a suitable handler in reaction to the message. <behavior>::= <pattern>+ <pattern>::= <message> [ IF <cond>] <handler>| < cond> <handler> <handler>::= <reaction> | <reaction> ; <handler> <reaction> [<local computation>;] [<communication>;] <communication>::= [ IF <cond>] <out-comm> | [ IF <cond>] <out-comm> //

<communication> <out -comm>::= send to <agent> : <message> <agent>::= all (<list>) | anyof (<list>) <list>::= <agent-type>+ | <agent-name>+

tell (<data > [{<attribute: value>* }] ) | ask ( < info > [{<attribute: value>* }] ) | create (<attribute: value>* [{<attribute: value>* }]) |

<message>::=

define (<attribute: value>* [{<attribute: value>* }]) < data >::= <attribute: value>* | new-behavior: <behavior> < info >::= <attribute>* | behavior <value>::= <any-data-type>* | <agent-type>* Table 2.2.1: the ACL syntax

A handler is a sequence of possible local computations with the possibly guarded and concurrent sending of messages (reaction). Local computation refers to any computation involving the local data of the agent. Cond is any expression containing both local data and the content of messages received by the agent (stored in its working memory). The structure of incoming messages and messages contained in outgoing communications (out-comm) is the same in order to allow pattern matching and the unification of the related information. More specifically, in outgoing communications:

• tell means that the agent is sending data to <agent> possibly together with a context {...} where to interpret them;

• ask means that the agent is sending to <agent> a request of info along with the context {...}

Working memory attribute

attribute

value

value

script

local data behavior

script

script

script

internal state


17

where to interpret it. Both data and info may concern attributes or behavior. For sake of conciseness, the syntax does not explicitly specify that attribute, value and behavior may be variables or constants. Moreover, attributes and their values may be of any data-type and/or agent type. Attributes and their values are application dependent.

• create means that the considered agent is requested to create an agent according to the specified data, where usually the required attributes are CM (coordination mechanism), category, name to indicate the aggregation it belongs to, the category characterizing the agent, and the name of the agent being created, respectively;

• define means that the addressee agent is requested to define its behavior or its internal state according to the specified data.

The ACL syntax expresses communication capabilities similar to the ones characterizing the Actor Model (Agha 1988). The main difference concerns the possibility for the language to express the reflection capabilities required to cope with the flexibility requirement in terms of dynamic definition and modification of agent behaviors. The suitability of the Actor model as a reference framework for developing CSCW applications has been discussed in (Dix 1993): specifically, message passing and the parallelism inherent to the approach fit the requirements of distributedness characterizing CSCW applications. The main drawback concerns the lack of conceptual tools to verify the correctness of the constructed behaviors. Instead, these tools characterize other approaches to coordination languages ( see e.g., (Papadopoulos et al. 1998) for a review). However, the proposed ACL was conceived of in view of the implementation of ABACO in a concrete architecture (see Section 2.5) and by considering that all of them provide asynchronous communication primitives. Moreover, the discipline of communication imposed by the language reduces the possibility to specify uncontrolled behaviors. This concludes the general description of agents. The next section describes the Infrastructure level whose services are provided to the Application level (Section 2.2.3).

2.2.2 The Infrastructure level All the agents at the infrastructure level own the above internal architecture where the local data and communication capabilities are designed to provide the services characterizing the Infrastructure level. The latter distinguishes agents into: System agents, which are created to provide aggregation and communication services, and generic Application agents, which at this level are place-holders for agents to be constructed at the second level to build applications. System agents are the means to let the different application agents work together in a common framework and to support the interaction of users with the architecture during the different phases of the CM life cycle. They offer a set of specialized functionalities to create agents, to manage the related naming space(s) and to mediate the communication among agents, as described below. System agents can be classified into two main types:

• Interface agents • User agents

Each Interface agent is a communication mediator connecting different agents according to the structure of the constellation it is associated with: typically, groups of agents in a constellation and groups of constellations into compound constellations. Hence, they basically stand proxy for those


18

aggregations (see Figure 2.2.2). These agents realize a trade-off between the efficiency of communication and the support to flexibility in the dynamic construction of the applications. We can distinguish between two types of Interface agents, which are created when the related aggregation is defined: External and Internal Interface agents. Each of them maintains in its local data an agent lists containing the names of the Application agents using their communication services. More specifically: • Each External Interface agent allows for the communication between agents belonging to the

same compound constellation. Since there is only one External Interface agent serving all the constellations of a specific compound constellation, every agent belonging to these constellations is registered to it. Every communication between agents crossing different constellations belonging to the same compound constellation passes through the related External Interface agent.

• Each Local Interface agent allows for the communication between agents of the same constellation. Since there is one Local Interface agent for each specific constellation, every agent belonging to the same constellation is registered to the Local Interface related to that constellation. Every communication among agents belonging to the same constellation passes through the related Local Interface agent.

In addition to Interface agents, the Infrastructure level contains User agents (UA) that play as communication mediators between the human actors and the agents of the application (Figure 2.2.2 a). Without loss of generality, we will refer to a unique User agent since their number and aggregation is strictly related to the organization of the user interfaces that are not central to the presentation of ABACO. To this aim, it is sufficient to say that the User agent allows human actors to interact with the applications through any graphical user interface (GUI) especially designed to satisfy their needs and preferences. Since a GUI does not necessarily have communication capabilities compatible with ACL, each GUI is incorporated in a Wrapper agent that communicates with User agents using the ACL primitives of Section 2.2.1.2. To this aim it incorporates a GUI-UA/message transformer module that translates the events coming from the GUI as communication messages containing information for the User agent, and vice versa the information contained in communication messages coming from the User agent into the GUI primitives realizing the visualization of that information. The User agent offers a set of standard interaction patterns representing the different kinds of interactions human actors can have with the applications according to their different tasks and duties. More precisely, the standard interaction patterns which involve the User agent are creation, definition/modification, enactment and execution. They are used respectively to create Application agents and constellations, to define/modify them and to manage the communication flow during the enactment and execution of applications when the involvement of human actors is needed. The role of the User agent in these interaction patterns is to elaborate and redirect messages. In other words, it is continuously waiting for the reception of messages coming from the Wrapper agent or from the other agents. When the User agent receives a message it prepares the related answer in the appropriate form and sends it to the appropriate addressee (Application or Wrapper) agent according to the sender agent name (Wrapper or Application, respectively). Interface agents are endowed with behaviors realizing the above functionality and are basically application independent. On the contrary, the User agent functionality is influenced by the


19

application being defined since its behavior has to identify, on the basis of message content, the addressee agents and construct the messages the latter have to receive.

Figure 2.2.2: a) the Infrastructure level (disregarding names of Application agents) b) The Application level (considering names of Application agents) (thin arrows represent message exchange between agents, dashed boxes express logical grouping of agents according to the model of the application and dotted box represent groups of application agents)

2.2.3. The Application level The Application level of ABACO complements the Infrastructure level to design the applications supporting the articulation of cooperative activities. The place-holder agents of the Infrastructure level are created and fully defined in terms of local data and communicating behavior. As mentioned in the previous chapter, ABACO has been conceived of as an abstract machine defining the operational semantics of a notation, Ariadne, for the construction of coordination mechanisms (Divitini et al. 2000; Divitini et al. 1996). Hence, the structure of ABACO mirrors its basic constituents. The Application agents of the Infrastructure level are specialized into: CAW agents, corresponding to the categories of articulation work (CAW) characterizing Ariadne, Active Artifact agents, capturing the notion of artifact used to support articulation work, and Protocol agents,

USER

S

External Interface agent

ExternalInterface

agent

Local Interface

agent

Application agents CM

Compound CM

Local Interface

agent

Application agents

CM

Local Interface

agent Application agents

Organizational context

Actor Role Resource

Role Role

Task Task

AA AAU

ser agent

GU

Is

CMs

Operative context

CM


20

capturing the procedures and conventions stipulating the coordination of interdependent activities. Coordination mechanisms are the results of the composition of these agents. Therefore, at the application level, the generic notion of constellation defined at the Infrastructure level corresponds to Coordination Mechanisms (CM) and compound constellations correspond to compound Coordination Mechanisms. In order to guarantee the greatest degree of “dynamicity”, Application agents are organized according to the possible kind of stimuli an external user can ‘send to the architecture’ through the User agent. There are three kind of roles a user can take: Programmer, who implements the generic Application agents that can be selected to construct the coordination mechanisms constituting the cooperative application; CM-definer, who selects and defines the Application agents of each specific coordination mechanism and builds their aggregations; and End-user, who puts at work instances of the defined coordination mechanisms supporting actual cooperative activities. Accordingly, there are three classes of Application agents (see Figure 2.2.3). Description agents. They contain the behaviors of the basic building blocks, that is the behaviors pertinent to the specialized category of the considered Application agent. The behaviors are “implemented” in terms of the Agent Communication Language associated with the architecture. Their role is reminiscent of the ‘description actors’ proposed in the Actor Model (Agha 1988). They are created by the Programmer (through the User agent). Description agents are able to elaborate two types of events: definition and modification (when a Programmer constructs them) and creation of the corresponding templates agents (when a CM-definer builds a coordination mechanism, see below). Template agents. They are the agents constituting the coordination mechanism, that is, they are the basic building blocks (agents) constituting an aggregation. Template agents are created by the corresponding Description agents. After their creation, these agents are able to elaborate events concerning their definition and modification, and the creation of their instances. Instance agents. They are agents constituting a specific instantiation of a defined coordination mechanism. Obviously, several instantiations of the same coordination mechanism can coexist. An instantiated coordination mechanism can be enacted, that is, appropriate resources are assigned to it, and executed, that is, put at work. Enactment and execution are the events generated by the End-user that Instance agents are able to elaborate. Moreover, they are able to elaborate events concerning their definition and modification. The above three classes of Application agents concurrently populate the architecture, and cooperate, together with System agents, to provide the various types of users with the pertinent functionality (see Figure 2.2.4). To this aim, the behavior of each agent contributes to the definition of interaction patterns that are triggered by the various events users generate (through the mediation of the User Agent). Application agents show behaviors that are partly uniform among them: typically, every agent, after its creation, is able to receive and elaborate triggers concerning its definition/modification. This responds to the requirement of incremental definition mentioned in the first chapter.


21

Figure 2.2.3: The user roles and the related levels of definition of application agents in the conceptual architecture

Moreover, all of them will be enacted and executed, sooner or later. These basic capabilities are given to agents when they are created (default behavior). On the other hand, agents behavior is also specialized to the specific agent type. The above definition/modification capabilities are put at work to construct the desired behavior of each Template agent, through an appropriate interaction pattern that involves in addition to the Template agent the User agent and the pertinent Description agent. Instance agents follow a similar interaction pattern as far as their definition/modification are concerned.

Figure 2.2.4: the different aggregation of agents according to their level

Description agents

UA

User Role

Programmer

CM-definer

End user

System agent Application agents

build behaviors

build CMs

put instances of CMs at work

GU

I

Wrapper agent

Template agents

Instance agents

get behavior

instance of

Description agents

Template agents

Instance agents

LI CM

EI LICM

Compound CM

Compound CM1 Compound CMn


22

We conclude this section by mentioning that agents at the Infrastructure level (specifically, Interface agents) could be partitioned in the same way in three levels, so as to reflect the same flexibility as Application agents. In this view, Description System agents contain the behaviors of the System agents that are programmed by a (System) programmer. For what concerns the Template and Instance levels, the needed Interface agents are created as instances of the corresponding Description Interface agents with their default behavior. In particular, these agents are explicitly defined by CM-definer role when a new aggregation of agents at template level is created and therefore can be specialized to the needs of the CM under definition. In following chapters we present new communication services concerning Interface agents that can be considered as examples of this specialization. Finally, Instance System agents can be (automatically) created at Instance level when new instances of the CMs containing them are created.

2.2.4. More on the agents at the Application level Before going into the details of how the Agent Communication Language is used to specify the behavior of the agents constituting ABACO, we give more information on how these agents reflect the expressive needs required by CSCW applications devoted to support articulation work. This kind of information is useful to better understand both the technical aspects illustrated in the next section and the contents of the following chapters dealing with alignment of protocols and alignment of meanings.

2.2.4.1 The Organizational and Operative contexts

The application domain of ABACO requires a deeper investigation on the aspects related to modeling organizations. In fact, coordination mechanisms do not act in a vacuum: they are acting in a wider organizational context that specifies constraints and opportunities governing their definition and execution. This central point influences the structure of the Application level of ABACO, which is organized into two main contexts, which are highly interrelated but consider different aspects: Organizational context and Operative context. The Organizational context contains a (compound) coordination mechanism (see Figure 2.2.2 b) which includes the agents representing resources (informational, human, material, etc.) that belong to the organization and that CMs of the Operative context can use as a common patrimony. Moreover, it includes the agents that represent human resources having the rights and duties to create and define different (compound) CMs together with their agents. It also contains recursively other organizational sub-contexts (again expressed in terms of CMs) structuring the organizational context in a flexible way to cope with the structure of real organizations. In fact, these sub-contexts can be naturally associated to the organizational units constituting the organizational structure of the considered setting. The Operative context contains the CMs constructed to articulate the distributed and interrelated actions of the involved actors. All the CMs in this context interact during their life cycle with the CMs of organizational context. Notice that both contexts are expressed in terms of CMs built up from the same kind of agents with their interaction patterns. This is an important characteristic of ABACO. In fact, in this way, the organizational context of a CM and the CM itself are described using the same components, and can be defined and adapted in a uniform way. The only difference is that the organizational context is


23

defined and possibly modified by the qualified roles who own the ‘institutional’ responsibility: typically, to introduce or cancel a Institutional role, to hire or fire an actor, and finally to acquire or dismiss a common resource. This assures a high degree of integration of the organizational and operative context, both during the definition and use of coordination mechanisms. This is a basic consequence of fully taking into account the recursive nature of cooperative work (Divitini et al. 1996) and is one of the main characteristics of the cooperative applications that can be constructed with ABACO.

2.2.4.2 The CAW agents

As anticipated in Chapter 1, Ariadne (the notation to define CMs that ABACO implements) identifies a set of basic Categories of Articulation Work (CAW) (see Appendix A), i.e., basic components for the description of coordination mechanisms, and support users to define how they are connected. Given the identified categories, the corresponding CAW agents are: Role, Actor, Task, Activity, Action, Interaction, and Resource1. Each of them is characterized in terms of internal state and communicative behavior by a specific local data structure and by a suitable set of scripts that capture the interaction of the specific CAW with its environment, both at the organizational and the operative level. More specifically, the data structure contains a set of attributes that identifies the category and describes its informational content. For example, an agent realizing a task has information about its preconditions or priority; an agent realizing a resource keeps information on the status of the actual resource. The communicative behavior of a CAW agent specifies the meaning of the relations among CAW. For example, each category has associated a Role in charge of defining it: this means that both the category and the Role have to contain scripts making this definition possible. As another example, a Role can be defined as responsible for a Task or a Resource. Again both Role and Task or Resource have to contain scripts able to make this responsibility operative. CAW agents are the basic elements on which to build the languages to describe coordination mechanisms, as anticipated in Chapter 1. In the simpler case, a coordination mechanism can be obtained just adopting the subset of CAW agents that are relevant to describe the case at hand. This type of CM is appropriate in situations that are characterized by ad-hoc coordination, often based on improvisation. In these circumstances, the CM relies only on the basic capabilities of ABACO agents and on their relationships. In the following, two examples are provided in order to clarify this type of CMs. Coordination can be described in terms of a constellation of Resources. The communication capabilities of Resources can be used to promote awareness of their current state or to support coordination among different Resources in relation to their allocation to Tasks and usage by Activities. The provided support is light as coordination is mainly achieved through the access control to Resources and the related policies. As a second example, let us consider the quite common process of collecting proposals for new projects. The overall process is normally characterized by a lightweight control. Two Roles are involved in this process: the Proponent and the Collector. The former prepares a proposal and submits it, possibly after some formal control by an appointed authority. The Collector collects the 1 From now on, where it is clear, we refer to the specific CAW agents simply with the name of the category they stand for, omitting the word agent


24

proposals within a specified interval in time. After the deadline, the Collector activates the review procedure of the proposals. This coordination mechanism can be simply described in terms of Roles, Tasks they are responsible for, and Activities realizing the Tasks. In ABACO, in order to support this process, it is possible to associate to each Role and to each Task the appropriate agents. ABACO already provides the basic relations that have to be active among these agents. These relations need simply to be specified by the CM-definer role who defines the mechanism. The control flow of the CM is expressed in terms of the responsibilities of Roles on Tasks and the execution of the related Activities. The latter are fully under the control of the responsible Role that might delegate their execution. Awareness capabilities of agents complement coordination by disseminating the pertinent information.

2.2.4.3. The Active Artifact

In different work settings artifacts play an essential role in mediating cooperative work. It is therefore necessary to provide a specialized agent playing a similar role. From the architectural point of view, an Active Artifact (AA) is an agent specialized in managing a data structure collecting the information about the status of the field of work that is needed within the coordinated activities (Divitini et al. 1996). Moreover, the Active Artifact assumes an active role in mediating the coordination among the cooperating entities. This is achieved by awareness (i.e., with scripts for providing other agents with appropriate information in presence of particular conditions) as well as by directly participating in the coordination thanks to coordination capabilities (i.e., collecting from agents and conveying to agents information which is compulsory to coordinate their work). For example, in (Carstensen 1996; Divitini et al. 1996) is presented a simple coordination mechanism in the context of software testing. In the analyzed case, the members of the software team, in order to face a growing complexity in their work, introduce a bug form for the reporting and management of bugs detected in the code. This form has a predefined structure conveying information that is needed by different members of the team at different times. Together with the form, a protocol for its handling is defined, specifying who has to provide which information in which moment as well as the steps of the debugging process. An AA can be introduced to manage the information collected in the bug form. Moreover, this agent can play an active coordinative role by communicating appropriate information to the Roles involved in the cooperative work. For instance, in the case as described in (Divitini et al. 1996), the tester is responsible to send the bug form to the team allocating the debugging to a designer. In the computational counterpart, the workload of the tester can be reduced allocating to the AA the responsibility of sending the bug form to the team and so activating the process for the correction of the code. Active Artifacts agents can be grouped into constellations with other CAW agents in order to realize coordination mechanisms.

2.2.4.4. The Protocol agent

In some cases, however, the predefined relations among CAW agents and their grouping into CMs, possibly including Active Artifacts, are not enough to support the needs of complex settings. The definition of an explicit coordinative protocol is required. A Protocol agent is devoted to manage the flow of work when its articulation requires a more complex and/or structured interaction pattern than the one provided by the above coordination capabilities. The protocol is expressed in terms of relations among CAW agents. Different forms of cooperation normally require different protocols,


25

expressing different forms of control (Divitini et al. 1996). Protocols can be expressed in terms of relations among Tasks and Roles, Roles and Resources, and the like. Moreover, through protocols, it is possible to define the causal and temporal relationships among Tasks. From the architectural point of view, a protocol is an agent that manages the composition of various basic agents, according to a given grammar. Protocol agents maintain a data structure representing the composition of the basic agents and, as a result, they manage and monitor (through the primitives provided by the agent communication language) the activation of the various agents of the CM. Let us consider again the software-testing example. In this case, a Protocol agent can be defined to capture the behavior of the involved Roles and to describe the causal relationships among the Task to be performed by them. Let’s look at the tester. The tester is responsible to report any bug that she finds in the program that she is testing. This is achieved by filling in a bug form and forwarding it to a team. This means that the tester, after having recognized a bug, has to submit a bug or requesting help for the classification of the bug itself. From an agent perspective, submitting a bug implies an interaction between the Role “tester” and the Active Artifact, asking it to update its internal values. For requesting help, the tester could make a reference to another dedicated CM. This communication implies the activation of another CM. The full definition of a mechanism for supporting the software testing process requires to specify, in a similar vein, the behavior expected from each role involved in the software testing process, describing the procedures defined in the domain and determining the behavior of the actors playing the different roles. We conclude this section with considerations on the flexibility by with CM can be constructed in ABACO. Application agents (CAW, AA, Protocol agents) play a different role during the lifecycle of a CM (Table 2.2.2). For example, Role, Task and Resources express the organizational constraints (nominal status) for the behavior of the agents that become active during the enactment and execution of CM (actual status) at Instance level. For example, a Task can be differently accomplished by activating different Activities: the same holds for Activities and Actions. The distinction between the two above status plays a relevant role in the way ABACO provides flexibility, since the actual status agents can be specified when contextualized in the specific and dynamic field of work. Moreover, all CAW agents do not need to be fully specified before they are enacted or executed. Everything but its name and the Role responsible for its definition could in principle be unspecified. This allows for the maximum level of flexibility at enactment and execution time (Divitini et al. 2000). The shift to a different status sometimes requires only a change in the current internal state of the CAW agent (as in the case of Resources which in the passage from enactment to execution only change their state from allocated to in use). Sometimes it is realized by a more complex communicative behavior among different agents (as in the case of the activation of an Activity). NOMINAL STATUS: Definition of a CM

ACTUAL STATUS: Enactment of a CM

ACTUAL STATUS: Execution of a CM

Role committed Actor Actor in action Task enacted Task Activity: Action/Interaction Resource allocated Resource Resource in use Table 2.2.2: Examples of Nominal and Actual status of Application agents


26

2.3. The architecture in use The previous section presented the conceptual architecture in terms of its structure, without taking into account how it can be actually used. What we have are constellations of agents that are prepared to have an internal state and exhibit a communicative behavior. The next step is to describe how the latter are constructed. The idea leading the construction is to provide agents, by default, with basic attributes and communicative behaviors. The latter bootstrap the real definition by reacting to the stimuli coming from the human agents interacting with ABACO. This idea is fully coherent with the systemic approach illustrated in the introductory section, which states that the behavior of the resulting application is the outcome of its predefined capabilities and the perturbations coming from its environment. The construction of agents’ behaviors is therefore driven by events originated by the GUI, captured by the Wrapper agent and handled by the User Agent (UA) which redirects the received stimuli to the pertinent ABACO agents (see Figure 2.3.1). In this way, every event causes the association of a specific portion of behavior to the agents addressed by the User Agent according to the event itself. This approach has the advantage to make the construction highly dynamic and tailored to the user needs in terms of selected agents (language) as well as incremental definition and modification (compositional and reflective behavior).

Figure 2.3.1 The User agent communication flow in ABACO architecture associated to the creation, definition (modification) interaction patterns.

2.3.1 Interaction patterns at Template level This section describes the interaction patterns involving agents at Template level. Mainly, these patterns are related to creation and definition both of constellations and Application agents.

communication mediated by the pertinent Interface agent

creation, definition

USER

S

GU

I

Institutional Role

Actor

wrapper t U

ser agent

Role

creation, (re-)definition


Operative context

local creation, local definition, modification

Super User

Resource

Task

Resource

CMs

CMs

direct communication among agents user events


27

Let us suppose that a programmer did already define a set of Description agents (DA). This means that the programmer both created the Description agents and defined for them the general behaviors which regulate the possible interactions between Application agents. At Template level, the CM-definer role is in charge of creating Template agents (TA). The CM-definer role is also in charge of providing the Template agents with the information needed to get from the corresponding Description agents the general behaviors specialized on the basis of the provided information: i.e. attributes and their values. Moreover, this role creates and defines the aggregation of agents expressing coordination mechanisms. First, we show the interaction patterns related to the initialization phase of ABACO. Then, we consider the relation linking Actor and Role agents by explaining how ABACO assigns an Actor to a Role; then, we consider the creation of constellations followed by the creation and definition of generic Application agents. Every Application agent receives, upon its creation, a default behavior making it able both to ask to the Description agent of the corresponding category the needed specialized behaviors and to incorporate them as its own behaviors. Once these behaviors are incorporated into the considered Template agent, they cannot become active until the agent is enacted or activated during the execution of the associated CM at Instance level. Hence, they become part of the agent in a guarded form expressed in the left-hand side of the behavior. Usually this guard is represented by the message which activates the agent itself. Hence, this guard is triggered when the enactment/activation event is generated at the GUI and propagated through the Wrapper and User agents. For what concerns Role agents, the guard is expressed as a condition on the agent’s internal state, since the activation of Roles follows a different pattern, as described in Section 2.3.1.2. At this point, the default behavior and the specialized behaviors of a Template agent run in parallel allowing for the incremental definition and

dynamic modifications when the agent is activated (see Figure 2.3.2).

2.3.1.1 The Initialization phase

During initialization, ABACO provides, beside the Wrapper and User system agents, a Super User Application agent (see Figure 2.3.1 and 2.3.3) whose aim is to generate the minimal amount of information needed to start the creation of CMs. The human actor playing as Super User agent, through the standard interaction pattern associated to her graphical user interface, creates at least a CM expressing the Organizational context (let us call it Institutional CM). In principle the latter can be composed of a single Institutional Role together with the Actor assuming that Role but richer configurations are possible, depending on the needs of the target organization. To this aim, the User

DA

general behavior

default behavior

TA

default behavior

guarded specialized behavior

ask(behavior)

tell(specialized behavior)

Figure 2.3.2: the behaviors for Description and Template agents.


28

agent receiving creation requests from the Super User agent first creates the Institutional CM and then sends to the pertinent Description agents the corresponding request: UA create(<createConstellation: Institutional CM>{< defined_by: super user >})

create_constellation(Institutional CM, external_interface_name); create(<createAgent:Institutional CM, Institutional Role, name> { <defined_by: super user >})

send to Institutional Role (DA): create(Institutional CM, Institutional Role, name { <defined_by: super user >})

create(<createAgent:Institutional CM, Actor, name> {<defined_by: super user >}) send to Actor (DA):create(Institutional CM, Actor, name {<defined_by: super user >})

Box 1: the initialization phase

As a result, the involved Description agents create the requested agents with the default behaviors pertinent to their category. These default behaviors will be described in more details in the next sections. Once the initial Institutional Roles and Actors assigned to them are created and defined, and the Organizational context is activated, the start-up services provided by Super User agent are no more needed, and this agent disappears.

Figure 2.3.3: The structure of the Organizational context

2.3.1.2 Assigning Actors to Roles

Figure 2.3.1 shows the interactions among agents in the ABACO architecture which are part of the creation, definition and modification interaction patterns. These interactions follow a flow that is a consequence of the centrality of Roles and Actors in ABACO. The leading idea is that the definition of a Role establishes, among the others, which Role has the right to assign it to an Actor and that, when this happens, the assigned Actor subscribes the (already defined) behaviors associated to the

Institutional Role

Actor


Operative context

Super User

CMs

ActorInstitutional Role

define

ActorInstitutional Role

Institutional CM

CM

CM


29

pertinent Role. Since Actors have to be assigned to Roles, the default behavior associated to an Actor upon its creation contains the two following scripts: ACTOR (1) define(<assigned_to:Role_name>)

send to Role_name: ask(behaviors{<assigned:Actor_name >}) (2) tell(<new-behavior:behaviors>)

assigned = true; incorporate_behavior

Box 2: the default behavior of an Actor

In (2), setting assigned to true means that the specialized behaviors which in the Role are not active, (since the Role has been not assigned to an Actor and assigned is false), become active as soon as they are incorporated in the Actor’s behaviors. The default behavior of a Role contains the following scripts in order to manage the symmetric situation devoted to its assignment: Role ask(behaviors {<assigned:Actor_name >})

send to Actor_name: tell(<new-behavior:behaviors>}); Box 3: the default behavior related to assignment of Roles to Actors

Hence, Actors assume duties and responsibilities through a subscription to Institutional Roles and to Operative Roles, that is Roles inside a CM in the operative context. Roles have different duties and responsibility according to the context they belong to. Institutional Roles have the rights to create, define and re-define portion of the organizational context (defining for instance other organization sub-levels in terms of CMs) and of the operative context (defining CMs which represent articulation among tasks and activities) while the Operative Roles have only the ability to create and to modify portion of the CM they belong. Hence, the main difference concerns creation and the type of modifications the Role can perform: creation of constellations as well as agents belonging to them and permanent changes (re-definitions) are prerogatives of the Institutional Roles while Operative Roles can only perform creations and modifications local to the instances of the CM they are involved in. Moreover, Roles can always perform ‘free’ communication with other Roles. This results in the behaviors associated to Roles as illustrated in Figure 2.3.4. As described above, they can be grouped into default behaviors and specialized behaviors. The former ones are needed both to get behaviors from the Description Role agents and to handle the assignment of Actors to Roles. The specialized behaviors concern the duties of the Roles in creating and defining other Application agents and constellations.

specialized behavior: creation, (re-) definition (of CMs and agents)

specialized behavior: communication (with other Roles)

specialized behavior: communication (with other Roles)

IR

default behavior: define (..)

send to IR(DA):... ...

default behavior: ask(behaviors){reply:Actor_name}

send to Actor_name: tell(behaviors)

OR

specialized behavior: local creation, definition,modification (of CMs and agents)

default behavior: define (..)

send to OR(DA):......

default behavior: ask(behaviors){reply:Actor_name}

send to Actor_name: tell(behaviors)

Figure 2.3.4: The behaviors of Institutional and Operative Roles


30

2.3.1.3 Creation of constellations

In the following, we explain in more detail the creation interaction pattern considering the creation of a constellation (CM) that involves the creation of a Local Interface (system) agent. The case of Application agents will be considered later on. When an event related to the creation of a constellation is generated at the GUI typically by Actors in the Organizational context associated to humans playing CM-definer role, the Wrapper agent transforms (through its internal module) the event into a message2 and sends it to the User agent according to the following script (numbers refer to Figure 2.3.5): WRAPPER (1) event(CreateConstellation(info))

send to UA: create(<createConstellation:name> {<defined_by: Role_name >}) Box 4: the event triggering the building of a new constellation

Then the User agent creates constellations, through the following script: UA (2) create(<createConstellation:name>{< defined_by: Role_name >)

(3) create_constellation(name, local_interface_name); (4) send to Role_name: tell(new-behavior:

assigned send to UA: tell<defineConstellation: name>)

) Box 5: the UA’s behavior associated to the building of a new constellation

In fact, it creates the Interface agent (local_interface_name) of the Template level which really represents the communication mediator among Template agents constituting a coordination mechanism through the create_constellation local computation (3). Then the User agent stores in its createdConstellation attribute the name of the constellation and the name of the related Interface agent, in order to find the right association of names for the future messages it will send to Application agents belonging to that constellation. Furthermore, the Role responsible for the definition of the CM receives (4) the pertinent behavior which makes explicit its responsibility in the definition of the CM when it will be enacted (that is assigned to an Actor). In fact, when the considered Role is enacted, the behaviors of the Actor assuming it are triggered. In this case, the UA is involved in the interactions needed to display on the user interface of the CM-definer the information devoted to fill in the definition of the pertinent constellation. The duties of a Role for the definition of a constellation concern both the creation of the CAW agents belonging to the CM and the choice of the Roles which will define the created agents.

2 In the following of this section, we will not describe the scripts associated to the Wrapper agent. In general these scripts express interaction with the UA following always two directions: from UA in order to build the suitable user interface associated to the received message; to UA in order to propagate the information associated to user’s choices done on her interface.


31

Figure 2.3.5: the User agent communication flow

2.3.1.4 Creation of Application agents

The creation of a Template agent by the CM-definer is a stimulus triggering a chain of interactions among agents which produces as a result the creation of the desired agent with the definition of its default behavior (see Figure 2.3.6 a)). More precisely, the creation message, along with the pertinent attributes, is sent by the Wrapper agent (associated to the CM-definer user interface) to the User agent. When the latter receives this message, it redirects the message to the pertinent Description agent, which maintains the behaviors related to the category of the agent being created. Then the involved Description agent performs a local computation which physically creates the desired Template agent according to the received parameters. According to the incremental design philosophy of ABACO, the creation provides the minimal amount of information, that is the CM it belongs to, the category (CAW, AA or Protocol) of the agent, the agent name, and the Role which has the responsibility for the agent definition. Moreover, the Description agent provides the created Template agent with its default behavior. Box 6 describes the scripts associated to the creation of Template agents. In particular, scripts (1) and (2) describe the default behavior associated to the created Template agents. The first one allows to ask to the appropriate Description agent the behaviors associated with the definition of an attribute, while the second one allows the Template agent to receive from its Description agent the asked behavior and to incorporate it. Instead, script (3) describes the portion of behavior which need to be provided to the Role in charge of the definition of the Template agent. In this way, the definition of the pertinent Template agent is performed by the definer Role only when the latter is assumed by an Actor. This happens because during the assignment of an Actor to a Role (see Boxes 2 and 3) the former subscribes all the behaviors of the latter and hence also the one expressed in Box 6 (3) if this Role is in charge of the definition of a Template agent. In fact, the interactions devoted to the assignment of Actors to Roles encompass also the setting of assigned to true (see (2) Box 2). This assignment fires the left hand side of the behavior (Box 6 (3)) which is now part of the Actor’s behaviors and this triggers a chain of interactions from the Actor to the Wrapper agent. As a result, the information needed to define the Template agent under concerns is displayed on the user interface of the human actor associated to the Actor. Then the user choice triggers a chain of interactions in the opposite direction (from Wrapper to Template agent) causing the definition of the Template agent, as described in the next section.

Application agents

ACL communication GUI event/action user events

USER

S

wrapper agent

GU

I

GU

IUA

/protocol transform

er

User agent

(1)

CREATIONInterface agents

Local

External

DEFINITION

EXECUTION

(2,3,4)


32

Figure 2.3.6: the a) creation and b) definition interaction patterns related to Template agents Category(DA) create(CM, category, category_ name {<defined_by: Role_name>})

create_agent(CM, category, category_ name); send to category_ name: tell(new-behavior:

(1) define(<attribute: value>{<CM:value> }) send to Category(DA): ask(behavior {<attribute: value>,<reply: category_ name>})

(2) tell(new-behavior: behavior) incorporate_behavior

); (3) send to Role_name: tell(new-behavior: assigned

send to UA: tell(<define:category, category_name>{<CM:value> }) ) Box 6: The scripts associated to the interaction pattern for the creation of a Template agent

2.3.1.5 Definition of Application agents

The definition of a Template agent concerns both the definition of the attributes characterizing the category it belongs to and of the related behaviors. Some attributes of the corresponding Ariadne’s category are simply pairs of <attribute, value> that become parts of the agent’s internal state, while others express mutual references between agents: they have a semantics described in terms of behaviors which define the interactions between the involved agents. When a CM-definer chooses from her interface to define attributes of the first kind for a Template agent, they are simply written as a pairs in the local data of the agent. When the attributes are of the second kind, the stimulus from the CM-definer triggers a chain of interactions among agents which produces as a result the definition of the agent behaviors corresponding to the semantics of the defined attributes (see Figure 2.3.6.b)). More precisely, the message defining an attribute of a Template agent is sent by the Wrapper agent (associated to the CM-definer user interface) to the User agent. When the latter receives this message, it redirects the message to the pertinent Template agent under definition. At this point the involved Template agent, according to its default behavior, is able to ask to the related Description agent (that is the Description agent belonging to the same category) the specific behaviors associated to the attribute under definition. Then the Template agent receives from the involved Description agent the requested behaviors instantiated with the values currently associated to the definition and incorporates them. As an example we consider here the definition of two specific attributes: responsible for Task, and the symmetric under responsibility of, which define the appropriate behaviors describing an interaction between Role and Task Template agents previously

UA

Category(DA)

create Category(TA)

Category(TA)

create Category(TA) + add default behavior

a) creation of Category(TA) (Box 6)

UA

Category(DA)

define Category(TA) (Box 8)

Category(TA)

b) definition of Category(TA)

ask behavior (Box 6(1))

tell behavior (Box 7)


33

created. The former attribute represents the duties of the Role in activating the associated Task and in waiting for the results from its computation (see script (3) in Box 7 expressing this latter duty). More precisely, script (1) in Box 7 expresses the duty of Role Role_name in activating the Task Task_name it is responsible for. Again, this activation can be performed only when the activating Role is enacted, that is an Actor is assuming this Role. When this happens assigned is set to true, and this assignment triggers the pertinent chain of interactions among agents. In this case, the User agent is involved (see script (2) in Box 8) and this results in the possibility for the human actor (associated to the Actor) to activate the Task Task_name from her interface. When the human actor activates the Task, this results in another chain of interactions from the Wrapper agent up to the User agent and then to the pertinent activator Role (through script (4) in Box 8). At this point, according to the context provided by the message, the latter is redirected to the proper Actor assuming that Role. Hence, the Actor receives the message which triggers the activation of the pertinent instance of Task_name (that is the right-hand side of script (4) in Box 8 matches with the left-hand side of script (2) in Box 7). Instead, under responsibility of means that the Task, once activated, creates the pertinent instance of Task Instance of Task_name which performs some local computation and then sends back to the activating Role the related results (see Box 7, (4) for Task_name). Again, according to the context contained in the current message, the Task’s results are redirected to the pertinent Actor agent which is assuming that Role. For what concerns scripts (1) and (3) of Box 8, they describe the pattern of UA’s behavior related to the definition of a Template agent. More precisely, script (1) is a general behavior and is triggered by the right-hand side of script (3) Box 6 when the Role with the duties of defining the Template agent is enacted. In this way, the UA involves the Wrapper agent in order to show the pertinent user interface to let the involved user to define the Tempate agent category_name under concerns. On the other hand, script (3) expresses a specific behavior associated either to the definition of a specific attribute or to pairs of symmetric attributes (in the proposed case of the symmetric attributes responsible_for_Task and under_responsibility_of). In this way, the script of UA’s behavior conveys the information provided by the user to the pertinent Template agents in order they can retrieve from the Description agents the corresponding actualized behaviors. Figure 2.3.7 describes the part of the interaction chain among agents pertinent to the incorporation of the behaviors related to the definition of attribute responsible for Task when the CM-definer established that Role1 is responsible for Task Task1 (the chain starts from script (3) of Box 8). The matching between the incoming message and the left hand side of behaviors patterns considers both the name of the primitive, the related parameters, and also the context in which the message is sent: this is represented in Figure 2.3.7 through the arrows connecting the received message with the behaviors of the agent. In this way, the variables describing the general behavior are “unified” with the values associated to the received message in order to instantiate the selected behavior according to the current values expressed by the CM-definer during the corresponding attribute’s definition.


34

Role(DA) ask(behavior {<responsible for Task: Task_name>,<reply: Role_name>})

send to Role_name: tell(new-behavior: (1) assigned

send to UA: tell(<event: activate, Task_name>{<activator:Role_name><assigned:Actor_name>}); (2) tell(<activate:Task_name> {<activator:Role_name><assigned:Actor_name><activated: Instance ofTask_name>})

send to Task_name: tell(<event:activate>{<activator:Role_name><assigned:Actor_name><activated:InstanceofTask_name>};

(3) tell(<result:value>{<assigned:Actor_name>})

update_local_data(result) )

Task(DA) ask(behavior {<under-responsibility-of: Role_name>,<reply: Task_name>})

send to Task_name: tell(new-behavior: (4) tell(<event: activate> {<activator:Role_name><assigned:Actor_name><activated: Instance ofTask_name>})

update_local_data; send to Role_name: tell(<result:value>{<assigned:Actor_name>})

) Box 7: a fragment of behaviors related to the definition of Template agents UA (1) tell(<define:category, category_name>{<CM:value> })

send to Wrapper: tell(<define:category, category_name>{<CM:value> }) (2) tell(<event: activate, Task_name>{<activator:Role_name><assigned:Actor_name>})

send to Wrapper: tell(<event: activate, Task_name>{<activator:Role_name><assigned:Actor_name>}) (3) define(<responsible for Task:Task_name, Role_name > {<CM:value>})

send to Role_name: define(<responsible for Task: Task_name>{<CM:value>}) || send to Task_name: define(<under responsibility of: Role_name>{<CM:value>})

(4) tell(<event: activated, Task_name> {<activator:Role_name><assigned:Actor_name><activated: Instance of Task_name>})

send to Role_name: tell(<activate:Task_name>{<activator:Role_name><assigned:Actor_name><activated: Instance ofTask_name>})

Box 8: a fragment of User agent behavior

Since the above described behaviors imply interactions with Roles, we want to consider in the following how the definition of the Role attribute concerning its assignment to Actors (assigned_by) is expressed in terms of behaviors of the involved agents (see Box 9). In this definition, we want to distinguish the case of Institutional and Operative Roles and hence we present separated the corresponding Description agents keeping the pertinent behaviors. In the first case, the request to show the pertinent user interface (again, through the User agent mediation expressed in script (2)) can happen without constraints: in fact, Institutional Roles can be assigned by a pertinent Actor as soon as the Role in charge of the assignment is enacted (script (5)). Instead, an assignment of an Operational Role can happen only when the related CM is enacted. In fact, when a CM is enacted (see script (1)), this event triggers a notification to all the Roles of the pertinent CM (hence the attribute enacted of the involved Roles is set to true). In this way, when the Role in charge of the assignment is enacted (script (6)), the considered Actor can ask to the Operative Role if it can be assigned to an Actor (that is if the CM this Operative Role belongs to is enacted) through script (7). In the affirmative case, enacted in the Operative Role has value true (see (9)) and hence (through the intermediate interaction expressed by script (10)) this condition


35

triggers script (3) which allows to display the pertinent user interface in order to assign an Actor to the involved Operative Role.

Figure 2.3.7: the flow of agent messages and the related message pattern matching during the definition of Template agents

When, as a consequence either of script (2) or of script (3), the user can choose from the pertinent interface to assign the Role to an Actor, this assignment (script (4)) triggers the User agent to send to the assigned Actor a message so that the latter can ask to the Role it has just assumed its behaviors. In fact, the right hand side of script (4) in Box 9 matches with the left hand side of script (1) in Box 2 and this triggers the Actor to ask to the pertinent Role its behaviors. Again, contextual information contained in the exchanged messages provides the system with the possibility to address messages to the pertinent agents.

UA

define(<responsible for Task:Task1, Role1> {<CM:CM-A>})

define(<responsible for Task:Task, Role_name> {<CM:value>}) send to Role_name: define(<responsible for Task: Task_name>{<CM:value>}) || send to Task_name: define(<under responsibility of: Role_name>{<CM:value>})

Role(DA) ask(behavior {<responsible for Task: Task_name >,<reply: Role_name >}) send to Role_name: tell(new-behavior: ...

tell(<activate:Task_name>{...}) send to Task_name: tell(<event:activate>{...})

tell(<result:value>) update_local_data(result))

)

ask(behavior {<responsible for Task: Task1>,<reply: Role1>})

Role1

tell(<new-behavior: ...

tell(<activate:Task1>) send to Task1:tell(<event:activate>{...})

tell(<result:value>) update_local_data(result))

tell(<new-behavior: behavior>) incorporate_behavior

Role1

define(<responsible for Task: Task1>{<CM:CM-A>}) || define(…

define(<attribute: value>{<CM:value> }) send to Role(DA): ask(behavior {<attribute: value>,<reply: Role_name>}) Task1


36

UA (1) tell(<event:activate, CM>)

send to all Role CM: tell(<enacted:true>) (2) tell(<assign: InstitutionalRole_name >{<assigned_by:Role_name><assigned:Actor_name>})

send to Wrapper: tell(<assign: InstitutionalRole_name >{<assigned_by:Role_name><assigned:Actor_name>}) (3) tell(<assign: OperativeRole_name >{<assigned_by:Role_name><assigned:Actor_name>})

send to Wrapper: tell(<assign: OperativeRole _name >{<assigned_by:Role_name><assigned:Actor_name>}) (4) define(<assigned to: Actor_name, Role_name>)

send to Actor_name: define(<assigned to: Role_name>) Institutional Role (DA) ask(behavior {<assign: InstitutionalRole_name ><assigned_by: Role_name>})


send to UA: tell(<assign: InstitutionalRole_name >{<assigned_by:Role_name><assigned:Actor_name>}) )

Operative Role (DA) ask(behavior {<assign: OperativeRole_name ><assigned_by: Role_name> })


(7) send to OperativeRole_name: ask(enacted {<assigned_by: Role_name><assigned:Actor_name>}); (10) IF enacted {<under assignment: OperativeRole_name><assigned_by:Role_name><assigned:Actor_name>})

send to UA: tell(<assign: OperativeRole_name >{<assigned_by:Role_name><assigned:Actor_name>}) ); send to OperativeRole_name: tell(new-behavior:

(8) ask(enacted {<assigned_by: Role_name><assigned:Actor_name>}) (9) IF enacted

send to Role_name:tell(<enacted:true> {<under assignment: OperativeRole_name><assigned_by:Role_name><assigned:Actor_name>})

) Box 9: The behaviors handling the assignment of Actors to Roles

2.3.2 Interaction patterns at Instance level This section is devoted to illustrate at the Instance level of the architecture both the activation and the execution of the Application agents constituting a CM. In this case, we consider a particular instance of a CM previously defined at Template level according to what described in the previous section. This means that the behaviors associated to the pertinent Application agents of the considered aggregation have been already defined. Let us consider in the following the case describing the execution of Tasks and of the associated Activities.

2.3.2.1 Execution of Tasks and Activities

The execution of a CM is started by its activation. This means that when the pertinent Roles are enacted, they can in turn activate the pertinent Application agents that are part of the CM. We consider as an example the case in which a CM contains Task agents that, once activated, subscribe to the behavior of Activities that, in turn, subscribe to the behavior of Actions. The related behaviors involve also Resources. Once a Task is activated (and this activation creates a corresponding Task instance), the GUI representing the duties of its responsible Role contains the list of Activities realizing the Task: then, the human actors playing that Role can activate the presented Activities (and again the activation of an Activity creates the corresponding instance).


37

Once an Activity is activated3 with the associated Actor, the Activity and the Actor are informed and the Task containing the Activity has to wait for the results of its computation (Box 10 (A)). This is expressed in the following scripts, which follow the standard interaction pattern involving Wrapper and User agents: WRAPPER event(activate(Activity_name))

send to UA: tell(<activate_info: Actor_name, Task_name, Activity_name > {<activated:Instance of Activity_name><activated_by:Instance of Task_name>})

UA tell(<activate_info: Actor_name, Task_name, Activity_name > {<activated:Instance of Activity_name>< activated_by:Instance of Task_name>})

send to Activity_name: tell(<initiated_by: Actor_name >{<activated:Instance of Activity_name>}); send to Actor_name: tell(update, <initiator_of: Activity_name >{<activated:Instance of Activity_name>}); (1) send to Activity_name!tell(<event:activate, Task_name> {<activated:Instance of Activity_name>< activated_by:Instance of Task_name>});

Box 10 (A): Behaviors for the activation of an Activity

When receiving the activation message (Box 10 (A) script (1)), the Activity must acquire the related Resources (expressed as all Activity-Resource in Box 10 (B)) before actually executing its own Actions. This is done by sending (1) to each Role responsible for the required Resource the request to be considered in the list of Activities needing the Resource. Then the involved Roles (1a) test the state of the Resource and if the latter is NOT in-use, then the Resource is allocated to the requesting Activity. At this point the Activity needs to wait until all the needed resources are allocated. This condition is tested on its All needed resources allocated local variable. The latter is evaluated according to the Activity’s behavior expressed in (1c) in Box 10 (B). In fact, each of the involved Roles allocating the requested Resource for the Activity, notifies the latter with the script expressed in (1b) in Box 10 (B). At this point the Activity for each received notification, thanks to its local computation, is able to detect if the list of the allocated Resources (currentlist) contains all the needed Resources (neededlist) and when this is the case All needed resource allocated becomes true. Hence, once all the needed resources are allocated, the Activity sends to the Actor being its initiator (2a) the list of Actions realizing the Activity that can be activated. Then the initiator Actor triggers the User and Wrapper agents in order to let the related human actor select the Action to be done (Box 10(C)). Once this information arrives (3), the involved agents, namely Actor, Action and Activity, are informed. The current doer of the Action (specified in message (3)) can be different from the initiator one. In this way, the latter can perform a delegation of her duty to another Actor. Moreover, when the assignment is done, the Action can be activated ((4a) in Box 10(B) and (4b) in Box 10 (C)) (and when this happens it is created a corresponding instance). This form of delegation is very simple. In the case of delegation governed by a policy, the latter should be applied before the assignment is possible. Since policies are expressed either by conditions or by CM (describing the related communicative behavior) both of them become part of the above-described behaviors either as condition or as additional communication scripts. The relevant point here is that the uniformity of the definition language allows us to treat this additional behavior by applying the approach described for the other parts of the CM definition. The remaining parts of the behaviors described above concerns the termination of the (instance of) Action (see (5) in Box 11(C)) and the related Activity as well as the release of the acquired Resources (see (6) in Box 11(B)).

3 for sake of readibility from now on, we use in the text Task and Activity but, since they are activated, we are considering the corresponding Instance agents


38

ACTIVITY tell(<event:activate, Task_name>{<activated:Instance of Activity_name>< activated_by:Instance of Task_name>})

send to all Activity-Resource: ask(<Role_ responsible_for_Resource>{assigned:Actor_name}); (1) send to all Role_ responsible_for_Resource: tell(<Resourcelist: add Activity_name>{<assigned:Actor_name><activated:Instance of Activity_name>}); All needed resources allocated

(2a) send to Actor_name: tell(list of Action(s) {<activated:Instance of Activity_name>}) // tell(<assigned Action_name, Actor_name > {<activated:Instance of Action_name>< activated_by:Instance of Task_name>})

(4a) send to Action_name: tell (<event:activate> {<activated:Instance of Action_name>< activated_by:Instance of Activity_name>}); (6) tell(<result:value>{<activated:Instance of Action_name>})

send to Task_name: tell(<result:value>{< activated_by:Instance of Task_name>}); send to all Role_ responsible_for_Resource: tell(<use: no-more> {<assigned:Actor_name><activated: Instance of Activity_name>})

(1c) tell(< in_use: Resource_name>) add(Resource_name, currentlist); compare (currentlist, neededlist); currentlist = neededlist, All needed resources allocated = true

ROLE RESPONSIBLE FOR RESOURCE tell(<Resourcelist: add Activity_name >{<activated:Instance of Activity_name>})

add(Activity_name, Resourcelist); (1a) send to Resource_name: ask(<state>{<assigned:Actor_name>}); IF state=NOT in-use

(1b) send to Activity_name! tell(< in_use: Resource_name >{<activated:Instance of Activity_name>}); send to Resource_name: tell(<state: in-use>{<assigned:Actor_name>}); remove(Activity_name, Resourcelist);

tell(<use: no-more>) send to Resource_name: tell(<state: NOT in-use>{<assigned:Actor_name>}); Box 10 (B): Behaviors for the Resources acquisition ACTOR (2b) tell(list of Action(s) {<activated:Instance of Activity_name>})

send to UA: tell(<Actions: list of Action(s), list of Actor(s)> {<activated:Instance of Activity_name>}) WRAPPER tell(<Actions: list of Action(s), list of Actor(s)> {<activated:Instance of Activity_name>})

show(list of Action(s), list of Actor(s)) event(assign(Actor_name, Action_name))

send to UA: tell(<assign_info: Actor_name, Action_name >{<activated:Instance of Action_name>}) UA tell(<Actions: list of Action(s), list of Actor(s)> {<activated:Instance of Activity_name>})

send to Wrapper: tell(<Actions: list of Action(s), list of Actor(s)> {<activated:Instance of Activity_name>}) (3) tell(<assign_info: Actor_name, Action_name >{<activated:Instance of Action_name>})

send to Action_name: tell(<done_by: Actor_name >{<activated:Instance of Action_name>}); send to Actor_name: tell(<doer: Action_name >{<activated:Instance of Action_name>}); send to Activity_name: tell(<assigned Action_name, Actor_name >{<activated:Instance of Action_name>})

ACTION (4b) tell(<event:activate>{<activated:Instance of Action_name>< activated_by:Instance of Activity_name>})

update(local_data) (5) end_computation

send to Activity_name: tell(<result:value>{< activated_by:Instance of Activity_name>{<activated:Instance of Action_name>}})

Box 10 (C): Behaviors for the assignment of Actor to Action with a possible delegation


39

2.4. A first implementation of ABACO using Jafmas The proposed architecture is conceptual and hence abstract in the sense that the structure of its constituent agents as well as the language they use do not have direct correspondences in any existing platform. On the contrary, both of them have been derived from observations of how human being actually articulate their work in real settings. This effort has at least two advantages. First, the user requirements influenced the definition of the conceptual architecture rather than the technological constraints. Second, the architecture, being conceptual, is a bridge between requirements and implementations, where the latter can be realized using different concrete architectures. This is actually what happened. A first implementation in an OO environment was followed by an implementation in the Jafmas agent platform (Chauhan 1997; Chauhan et al. 1998) which was considered as a concrete architecture. The main characteristic of the Jafmas environment is the presence of conversations. They govern the communication behavior of Jafmas agents and the activation of suitable methods to realize the actions related to them. Conversations are modelled as automata where nodes represent the current state of the conversation, while arcs represent conditions (expressed on internal values of the agent or on communication from other agents) which, when true, allow the change of state of the conversation. In this way, the mapping of ABACO into the concrete architecture considered ABACO agents as corresponding to Jafmas agents, constellations as federations of agents and the ABACO scripts translated into Jafmas conversations. Moreover, the different classes of Application agents associated to different users’ roles have been not considered also as a consequence of some technological limitations of the Jafmas platform described in the following sections. In the considered case, only two roles are considered: a programmer and a user. The former is both a system and an application programmer since she defines at compile time the behaviors of both System and Application agents (at Description level) in terms of conversations expressed through the Java language. The user is both at system and application level (as CM-definer) since she has to create and define both the System and Application agents (at Template level) needed and the related constellation using both command line scripts and the user interfaces provided by the framework. Notice that in this implementation, Template level coincides with Instance level since it is not possible to create instances of the same aggregation (cloning) and hence each Template agent can be considered as the only possible instance of itself. In the following, we sketch the main conversations of the ABACO system (that is, the considered implementation of ABACO in Jafmas according to the oulined mapping) once it has been initialized. In doing so, we will refer to Figure 2.4.1, which mirrors the ABACO architecture shown in Figure 2.2.2 of Section 2.2. These two figures testify the incremental design of the system, from the user-oriented Ariadne notation to the Jafmas concrete system through the conceptual ABACO architecture and ACL.

2.4.1 The Initialization Phase Obviously, the ABACO system requires an initialization phase that creates the minimum set of agents that will be able to define, enact and activate the rest of the system. Notice that in Jafmas an agent can not directly create another agent. This means that all the needed agents are created offline through the invocation of suitable creation system calls, specialized for the kind of agents they create. In this concrete implementation, we need to consider an additional System agent which has no correspondence in the conceptual architecture: the Manager agent. Its basic functionality is to


40

maintain the domain list, a dynamic list containing pairs that associate the name of a constellation with the addresses of the Interface agents supporting the communication among the agents belonging to that constellation. This domain list is needed in order to support the dynamical, incremental and distributed creation of agents. In the ABACO system, the first initialization step creates the Manager agent (CreateManager). The second step concerns the creation of the Organizational CM which addresses all the organizational aspects of the target reality. In this implementation we consider only a single CM completely describing the Organizational context. In order to simplify the development of the initial prototype, this limitation can be overcome since it is not imposed by the Jafmas. This step requires creating the Local Interface of the Organizational CM (CreateCM) and the External Interface (CreateInterface) which relates the CMs of the Operative context with the CM of the Organizational one. Once the Organizational CM and External Interface are created the domain list of the Manager is updated accordingly. The next step defines the Super User Role and the Super User Actor (CreateInstitutional). The Super User Actor is the assigned actor to Super User Role through the RoleAssign conversation. The Super User Role has the responsibility for the creation and the definition of the Institutional level agents: the Institutional Roles and the related Actors assuming them, the Institutional Resources and their responsible Roles, and finally the creation of the list of the CMs (again offline with CreateCM) constituting the Operative level. At this point, after the involved agents have been created, the Super User Agent can perform the agent definitions through its suitable graphical interface. In this case, the only defined attributes are name and defined by, so that the mentioned Roles can start the definition at the Operative level. Notice that in this implementation, instead of defining a new specific kind of Super User agent with appropriate local data and behaviors, we consider Super User Role and Super User Actor simply as two Institutional CAWs. The difference with other Institutional CAWs concerns the time of their creation: in fact they are created before the other Institutional Roles and Actors in order to initialize the system. This uniformity allows us to consider the usual conversation flow related to assignment of Actors to Roles to provide the pertinent human actors with the functionalities needed to play the role of Super User.

2.4.2 The main ABACO conversations After the initialization, which can be partial (only the assignment of Super User Role to Super User Actor is required), it is possible to define the Operative context. For the Operative context we have to define the Operative CMs, which are seen as Local Interface agents, create the External Interface agents (again CreateInterface) and choose which of the created operative CMs form the compound CM identified by each External Interface. Then, it is possible to create any of the CAW agents (CreateCAW) in order to build the application. Any creation of a new agent activates a sequence of conversations automatically handled by the system for registering each CAW agent (Join) to the proper interfaces.


41

Figure 2.4.1: the ABACO system The main conversations of the ABACO system correspond to the interaction patterns involving the User agent which concern the definition, the enactment and the execution of CMs or of their components. Notice that in the current implementation the User agent is not considered: the interaction patterns in which it is involved are expressed in terms of conversation mainly involving Actor and Interface agents, where the Actor agent is in charge of managing the user interfaces and the associated user interactions. This difference in the concrete implementation of ABACO is primarily a consequence of the lack of reflection capabilities of the Jafmas framework. In fact, while in the ABACO architecture it is possible to dynamically build the behaviors of the Application agents, in Jafmas all the behaviors must be build and defined in advance following the patterns provided by the related conversations. In this case the ability of the agents to react to the environment according the sensing/reacting paradigm is limited and the user interfaces are built in advance as part of the features of the Actor agents to react to predefined patterns according to user interactions. For sake of testing some of the characteristics of the ABACO architecture in a

CreateInstitutional

Agent list

Super User Role

Domain list

Manager

Agent list

Organizational CM

Agent list

External Interface

CM list External Interface

CM list

Agent list

External Interface

Institutional CAWs Organizational context

Operative CAWs

Operative context

EI listAgent list

Operative CM

EI list

Agent list

Operative CM

Operative CMs

Compound CMs

join

join

join

join

join

join

join

addDomainInfo

addDomainInfo

CreateCAW

CreateCM

CreateInterface

CreateManager

CreateCM

CreateInterface

Organizational CM

Super User Actor


42

prototype, these limitations can be accepted. This is less acceptable in situations when we want to fully take advantage of the systemic approach provided by ABACO architecture and specifically we want to consider the incremental design approach of coordination mechanisms. In general, the structure of ABACO interaction patterns, expressed here in terms of conversations involving Actor, Interface and CAW agents, can be summarized as follow:

• an event triggers a conversation to acquire from the appropriate Interface agent the addresses of the involved CAW agents;

• this information is used by the Actor agent to build the appropriate user interface where the user can select the CAW agents to manipulate.

• each choice activates the suitable indirect conversation with the selected CAW agent through the appropriate Interface agent.

• the closing event (typically the pressing of the Done button) activates a indirect conversation (in the previous sense) between the Actor agent and the manipulated CAW agent to permanently register the information related to the manipulation.

Notice that a similar pattern is followed for the communications between any pairs of agents not requiring the intervention of the user. In this case, the only missing part is related to the management of the user interface.

2.5 Implementing ABACO in a richer concrete architecture The proposed prototype shows a behavior according to the described design principles. However, it still lacks of representing the full potentiality of the ABACO conceptual architecture. On the one hand, in terms of development, not all the described agents have been fully implemented. They have been mainly developed as placeholders, to test the communication capabilities related to ABACO according to the conversation approach provided by Jafmas. Moreover, the exchanged messages represent only a subset of the richness expressed through the ACL language. On the other hand Jafmas, as a platform to develop multi-agent applications, does not provide all the characteristics needed for a full implementation of ABACO, as reflection capabilities and the ability for the agents to create other agents. These limits led us to look for a better concrete architecture to fully realize the features of ABACO. Specifically, we need a robust platform endowed with modularity, support for dynamic communication protocols, reflection, where to express ABACO scripts giving us the real feasibility to integrate in the architecture the advanced features we will describe in the following of the dissertation. We are currently considering RTP (Micucci et al. submitted), a platform developed at DISCO in Milan, which shows the above characteristics together with mobility features and has been used in industrial applications.

2.5.1 The concrete architecture RTP is a general-purpose architecture for the development of strongly modular and configurable distributed systems. The architecture reifies the definition of a formal model (abstract machine) supporting the operational semantics of complex systems. RTP provides also a framework implementing the architecture and supporting the implementation of domain related systems. Most of the underlying ideas of the architecture borrow from previous research activities and projects, in particular Kaleidoscope (Savigni et al. 1999), RAID4 (Micucci 2002) and (Micucci et al. 4 Rilevamento dati Ambientali con Interfaccia DECT


43

2001), RTO5, Architectural Reflection, HyperReal, and MAIN-E. The architecture is mainly based on some core considerations:

• a system is made up by connected entities performing some kind of activity; • an entity exchanges information with other entities; • every activity is controlled by “supervisor” entities, which can be also distributed; • only the “supervisor” may start performing activities without being triggered;

The considerations above has lead to the definition of three primary components inside the architecture: Performer, an entity executing a specific task; Projector, a special kind of Performer whose task is to allow information exchange between Performers; and Strategist, a domain-related active entity that controls the system behaviour. Conceptually, a Performer can be modelled as a classical state machine: it has a local behaviour defining what to do when receiving a command but it is not aware of command sequences. In the RTP architecture we have a hierarchy of Performers: a Performer representing a generic command acceptor and a specialised ProgrammablePerformer representing a concrete state machine. In Figure 2.5.1 we show the UML6 (Fowler et al. 2000) Class Diagram of ProgrammablePerformer with its set of states and ECA7-transitions.

Figure 2.5.1: Performer's State Machine Class Diagram

The Performer environment is made up of variables belonging to two different sets: one containing

5 Real-Time Objects 6 Unified Modeling Language 7 Event-Condition-Action


44

local variables, i.e. only visible inside the performer, the other containing visible variables, i.e. the variables that the Performer decides to export. The latter, in turn, has two subsets: exported visibles (writeable from the inside and readable from the outside), and imported visibles (vice versa). We consider an advantage confining a Performer visibility in its environment only: in this way a Performer can be exploited in different concrete topologies. Projections are the entities that define mappings from visible exported variables of a Performer into imported visible variables of another Performer. In other terms, a Performer can observe the exported variables of another Performer not directly but only if they are projected (i.e. copied) into its own imported variables. A set of projections defines the topology of a system. In terms of architecture, Projectors exploit projections. They are special kind of Performers that define alignment mechanisms without dealing with alignment timings. The system topology is realized by a special kind of Performer, hereafter Topologist, whose role consists in relating Performers. The Topologist first creates Projectors and then binds the related exported and imported visibles of Performers through the pertinent Projectors. In Figure 2.5.2 we show the projection (reified through a ConcreteProjector, specialising a general Projector) class diagram. A Projector links (passes values of Visibles from) one source to many targets.

Figure 2.5.2. Projection Class Diagram

Issues about when and why elaboration and information alignment have to be done are encapsulated inside traces. Every trace defines a part of the system behaviour in terms of partially ordered set of requests. In turn, a request is a pair (command, recipient), where recipient denotes either a Performer or a Projector. Finally, a Strategist is the entity that is able to create and dynamically manage traces. In doing so, it controls the part of the system part related to the trace. A strategy encapsulates any domain-related issues and so, it is the only entity that must be re-designed (better say, developed) when the application domain change.


45

2.5.2 About mapping conceptual and concrete architecture To define a mapping between the conceptual and the concrete (RTP) architectures we have to describe the three conceptual levels of the conceptual architecture in terms of RTP concepts. In (Micucci et al. 2002) we defined a first tentative mapping among ABACO and RTP. The latter architecture, being based on UML (and general Object Oriented concepts), normally considers only two levels of abstraction: the class level (representing classes and relationships between them) and the instance level (representing concrete objects created from classes). Since the conceptual architecture encompasses three different levels, we chose to map the “Description Agents” level with RTP class level and the other two remaining ones with the RTP instance level in which we defined a “template” abstraction mechanism to distinguish between the two levels in the conceptual architecture (see Figure 2.5.3). Hence in the proposed mapping, a Template agent in ABACO is created in RTP with all the behaviors pertinent to the category it belongs to even if these behaviors have not been still defined by the CM-definer.

Figure 2.5.3. Mapping between conceptual and concrete architecture

This choice limits the incremental design of agents’ aggregations supported by ABACO. In fact, in ABACO a Template agent receives the actualized behaviors from the corresponding Description agent only during the definition of the corresponding attributes, as described in the definition interaction pattern reported in Section 2.3. In order to overcome the above described limitation, we propose here an alternative mapping that guides the current implementation. This mapping considers the definition of three levels of Instances in the concrete architecture to be associated to the three levels of the conceptual architecture. In this way, the Class level corresponding to the Description agent level considered in the previous mapping, is substituted by a Meta-Meta Instance level. This means that the Description agents of the ABACO architecture are represented by instances of Performers whose behaviors can be dynamically defined by Programmers at run time. Following this idea, the incremental design claimed in the ABACO architecture can be implemented in terms of information exchange among objects of the Meta-Meta Instance level (representing Description agents in ABACO) and objects of the Meta-Instance level (representing Template agents in ABACO). In fact, the former incorporate


46

the general behaviors of agents while the latter receive only the behaviors which have been defined for them by the CM-definer role. More specifically, the mapping is as follows (see Figure 2.5.4 which mirrors Figure 2.2.3 in terms of RTP concepts):

Figure 2.5.4. the new mapping between conceptual and concrete architecture

− the “Description Agents” level is mapped into the Meta-Meta Instance level in RTP: a high-level language programmer personifies the “programmer role”. In this view Performers, when created, are Description Agents containing only default behaviors. In addition, the Topologist (let us call it TUA) involved by the related Strategist (hereafter SUA) creates Projectors allowing exchange of behaviors among User agent and the new created Description agents (see (1) Figure 2.5.4). In fact, the latter ones are in charge of managing the interactions involving the User Agent with the other Application agents. Thanks to the default behaviors incorporated in the created Description agents, a programmer at run time is able to define for them the general behaviors pertinent to their category. At this level, these behaviors are expressed as information structures which will be interpreted by agents belonging to lower Instance levels.

− the “Template-agent” level is mapped into the Meta Instance level. We have to introduce a “component” concept to reify a meta-level representing building blocks aggregates. When a CM-definer defines a coordination mechanism, in the concrete architecture this fact corresponds to the creation of a TemplateComponent (see Figure 2.5.5). The latter is built aggregating Performers (representing Template agents) which, once created, will receive the information needed for their definition. Again, each Template agent is created as a Performer incorporating the pertinent default behaviors which are different from the ones of a Description agent. In addition, each TemplateComponent expressing an aggregation of Template agents is associated to a pair <Topologist, Strategist> which is able to manage the

UA user

Meta-Meta Instance level

wrapper

Pw-Ua

Pw-Ua

DA1

PUa-DA1

DAn

Meta Instance level

TA11

TUA SUA

PUa-TA11

PUa-TA11

PTA11-DA1

TA1j

CM1

TCM1 SCM1 CMx

Instance level

instances of CM

Class level Performer

PDA1-TA11

(1)

(2)

(3)

(4)

(5)


47

definition of the corresponding coordination mechanism. The ability of the two latter components concerns the creation of Projectors among Template agents and Description agents so that they can exchange the defined behaviors. Moreover, once the related behaviors are incorporated in the pertinent Template agents, the pair <Strategist, Topologist> is in charge of managing the interactions among Template agents according to the defined behaviors.

− the “Instance agents” level is mapped by a successive runtime phase. The transition from the above level to the Instance level (see Figure 2.5.5) is realized using the generate() method on instances of TemplateComponent. The generate() method spawns a concrete Component reflecting the TemplateComponent definition.

Figure 2.5.5. TemplateComponent Class Diagram

In the following, we describe more in details how creation and definition interaction patterns can be expressed in terms of concrete architecture. We are not considering in details how ACL scripts expressing agents’ behaviors are transformed in terms of Performers’ behaviors. In general, they may be described in terms of the state machine controlling Performers’ behaviors according to the semantics of the considered script. Rather, we focus on the interactions among agents involved in the creation and definition interaction patterns. Creation and definition of Description agents A Description agent DA1 is created by a programmer through her pertinent interface. In RTP a Description agent is created as an instance of a Performer containing as default behavior, among the others, the ability to actualize the general behaviors defined by a programmer. This actualization happens when a Description agent receives from the corresponding Template agent a request of a behavior along with the actual values provided by the CM-definer during the definition of the Template agent, accordingly (let us call this behavior transform). These behaviors are implemented as Java methods and are provided as specializations of the class Action which defines all the possible computations of a Performer according to what described in its state machine. In addition, the SUA Strategist receives as a consequence of creation of DA1 the behavior needed to manage the definition of behaviors for DA1. As for the other Performers, the behaviors of a


48

Strategist can be expressed as terns <Event, Condition, Action> on the related automaton. An Event is triggered when a value is copied either on the exported or on the imported visible of the pertinent Performers on which the Strategist has access. Once a Condition evaluated on the corresponding value is true, the Action of Strategist consists in the definition of a new trace which is passed to the engine of the architecture as the first one to be executed. A trace is a pair <command, addressee> which represents a request managed by the engine. In general, a request triggers the execution of a certain command for an addressee Performer. Hence, this allows the execution of the behaviors defined for different Performers. In our case, a request may represent both commands for a Topologist to create new Projections connecting Performers and commands for the created Projectors to exchange messages among the connected Performers. The execution of the two subsequent traces performed by the engine which create a projection among Performers (representing agents) and copy information among the exported visible and the imported visible of the connected Performers describes in RTP terms the mechanism of message exchange among agents in ABACO. In the considered case concerning the creation of DA1, the first trace created by SUA forces the Topologist TUA to create a new Projector (PUA-DA18) which connects the User agent with the created Description agent (see (2) Figure 2.5.4). Then, again through a pertinent trace this Projector is triggered to execute a command allowing the DA1 to receive the behaviors defined by programmers in terms of information structures. Creation and definition of Template agents Let us consider now a CM-definer in charge to define a new coordination mechanism (in the following we refer to the CM1 reported in Figure 2.5.4). In particular, she creates through her interface the Template agents needed to constitute the desired agent’s aggregation. According to the incremental design approach, the pertinent behaviors of the Template agents are defined whenever she defines the corresponding attributes on her interface. First, she has to create the related constellation (CM1) including the agents devoted to manage the agents’ constellation. In ABACO, only one agent was needed: the Local Interface. Here, each creation of a constellation proposed by a CM-definer creates automatically in RTP a Strategist (let us call it SCM1) and a Topologist (hereafter TCM1) (see (3) Figure 2.5.4). Let us consider in the following the situation related to the creation and to the successive definition of a specific Template agent (let us call it TA11) belonging to the constellation CM1 whose corresponding Description agent is DA1. As for the case related to the creation of Description agents, the SCM1, as a result of the creation of TA11, receives in terms of its automaton the behaviors needed to comply with its duties. Once created, a Template agent TA11 is an instance of a Performer which contains its default behaviors. In particular, one of these behaviors parses the behavior received by the corresponding Description agent in order to transform this data structure in terms of behaviors of the pertinent Strategist, which allows the interaction among the involved RTP components, accordingly (let us call this behavior parse). Hence, the creation of TA11 triggers the Strategist SCM1 to force TCM1 to create two Projectors (PTA11-DA1, PDA1-TA11) through the definition of the pertinent traces (see (4) Figure 2.5.4). The new Projectors are used to connect TA11 with the Pertinent Description agent (which is DA1). These connections are then used in order to let the former agent get from the latter the needed behavior. In

8 As naming convention, in the following we denote the Projector in charge of allowing exchange of information from Performer named P1 to Performer P2 as PP1-P2


49

addition, the SUA Strategist in charge of managing the interactions involving User agent forces the corresponding Topologist to create two Projectors (PUA-TA11, PTA11-UA) among UA and the created Template agent TA11 in order to exchange the information provided by the CM-definer through her user interface (see (5) Figure 2.5.4). When the UA writes on its exported visible the values concerning the definition of a general behavior, this Event triggers the Condition part of the pertinent behavior of SUA. Since also the Condition holds, the SUA Strategist passes to the engine the following trace: <copy(define(behavior, values)), PTUA-TA11> which causes the copy of the define message from UA to the Template agent TA11. Then, the Strategist SCM1 is triggered and passes to the engine the following trace which allows TA11 to copy the received message on its exported visible: <copy(define(behavior, values)), TA11>. At this point, when the value define(behavior, values) is put on the exported visible of TA11, the Strategist SCM1, is triggered and passes to the engine the following trace: <copy(define(behavior, values)), PTA11-DA1> which copies the request pertinent to the behavior expressed in define(behavior, values) in the imported visible of DA1 connected to TA11 through the PTA11-DA1 Projector. At this point, the reception of this message from DA1, triggers the corresponding Condition on the SCM1 which reacts passing to the engine the following trace: <transform(define(behavior, values)), DA1> and this triggers DA1 to execute its default behavior (transform) in order to actualize the request for the general behavior with the actual values. As a result, this actualized behavior is put on its external visible. Then the Strategist SCM1, when the resulting actualized behavior actual behavior is put on the exported visible of DA1, passes to the engine the following trace: <copy(define(actual behavior)), PTDA1-TA11> When TA11 receives the actual behavior on its imported visible, the Strategist is triggered to pass to the engine the following trace <parse(actual behavior), TA11> and this causes the involved Template agent to execute its parse default behavior to transform the information contained in the data structure representing the actual behavior in terms of Strategist’s behaviors in the concrete architecture. Let us consider in the following two different situations concerning two different structures of the received behavior. In the first case, the received behavior has the structure: message send to Template agent TA2: message1. In the second case, it has the following structure: message local computation. In the former case, the transformation of the received behavior according to the parse behavior triggers the pertinent SCM1 Strategist to create the behaviors corresponding to the actions needed to send message1 from TA11 to TA2 when TA11 receives the message message. In RTP terms this means that the following traces which are executed sequentially by the engine when the Strategist is triggered by the presence of message on the imported visible of TA11: <copy(message1), TA11> <connect(TA11, TA2), PTA11-TA2>


50

The first one copies message1 in the exported visible of TA11 and the second one creates a new Projector connecting Template agent TA11 with TA2, let us call it PTA11-TA2. At this point, when TA11 receives message (that is, TA11 is connected to another Template agent (i.e. T3) through a Projector and a trace of the pertinent Strategist, when executed by the engine, performs the copy of the exported visible of T3 with the message to the imported visible of TA11), the Strategist, testing the imported visible of the TA11, provides the engine with the following trace: <copy(message1), PTA11-TA2> which causes the copy of message1 from the exported visible of Template agent TA11 into the imported visible of TA2. At this point, the Template agent TA2 reacts on the basis of the behavior received during the definition appropriately transformed in terms of operations of the pertinent Strategist. Instead, when the behavior received by TA11 has the simpler structure message local computation, it results more simply in forcing SCM1 to define of a trace which triggers the execution of the local computation, when TA11 receives message. In other words, when the Condition associated to evaluate the presence on the imported visible of TA11 of message is true, the involved SCM1 passes to the engine the following trace: <local computation, TA11> which causes the execution of the local computation in TA11.

2.6. Related work The use of intelligent software agents for developing CSCW systems has been advocated for a long time (Ellis et al. 1991). One of the first research prototype in this area using agents is OVAL (Malone et al. 1997). This system shares with the present proposal many concerns, foremost the need of defining groupware systems starting from a set of basic building blocks. However, these blocks are not realized as software agents and, moreover, they are not associated to categories actually used by users when coordinating their activities. Various groupware systems supporting articulation work are nowadays using software agents for providing advanced services, both at the commercial and at the research level. For example, MILANO (Agostini et al. 2000) is “a CSCW platform supporting its users so that they can remain aware of the history they share with the actors with whom they cooperate and of the activities they are committed to perform in the future.” In MILANO, agents are used for the elaboration of messages and for keeping the overall status of the on-going processes, by combining information provided by the system and by the users. Though agents are extensively used, the architecture underlying the system is not agent-based. Other systems take a more radical approach, being partially or fully based on agents. Traditionally workflow systems have been based on databases or extended e-mail systems (Abbott et al. 1994). Lately, agents have been considered an alternative approach to the construction of workflow systems once designers acknowledged their potentialities from a software engineering perspective. Agents provide, for example, a computation paradigm for the development of systems characterized by a high degree of distribution and compositionality (Tokoro 1998). Lately, mobile agents have also been proposed in the context of workflows. For example, DartFlow (Cai et al. 1996) combines Web technology and Agent Tcl and focuses on the usage of transportable agents. DartFlow uses Java applets embedded in Web-browser as its front end and transportable agents as the backbone.


51

Each business process can be handled by an agent. The agent carries specific knowledge about how it must process. While Java applets provide a platform independent GUI, the use of transportable agents is intended to make DartFlow highly flexible and scalable. However, the use of agents is not only motivated by software engineering considerations, rather is driven by the need to provide a solution to open problems in supporting articulation work. For example, WorkWeb System (Tarumi et al. 1997) is a multi agent architecture that focuses on the management of resources. An agent is given to each office worker and it serves as a schedule management secretary for the user. Each of the other resources is also associated with a managing agent. These system encompasses four types of agents: Personal agents, managing human resources, Resource agents, managing non human resources, BTP agents, managing workflow process instances, and Data Management agent, collecting data from the agent network according to a given theme and returning it to other agents. Also in ABACO resources play a key role, but their management is not isolated from the other coordinating activities. Rather, resources are one of the components that can be used to define coordination mechanisms. In most of the existing proposals, however, agents are adopted to tackle one of the most critical issues within the research field of workflow systems: their lack of flexibility. In fact, the increasing complexity of working settings calls for more flexible systems able to adapt to the changing environment, see, e.g., (Klein et al. 2000; van der Aalst et al. 2000). In (Borghoff et al. 1997), for example, the authors propose the use of reflective agents for the construction of workflow systems that can adapt to changes in organizational procedures and business rules. In their approach the process engine is viewed as controlled and executed by autonomous agents capable of reacting and adapting to external changes. Agents can observe and modify their own behavior. In this case, the focus is on the capabilities on the individual agents, rather then on their combination. Most of the existing proposals use agents to redefine the management and execution of a workflow, without rethinking the underlying model. In this way, we believe, they fail to take fully advantage of the systemic approach that, as discussed in Section 2.1, is made possible by the adoption of agents. Taking this approach implies that the system must be fully rethought in terms of agents. An example of the former category of systems is represented by ADEPT, an agent-based process management system (O'Brien et al. 1998). In ADEPT a business process is viewed as a community of negotiating, service providing agents. Each agent represents a distinct role in the enterprise and provides services to other agents. Services are provided to other agents after a negotiation, where agreement results in binding agreements between agents. With respect to ABACO, ADEPT focuses more on the business perspective, partly discarding the cooperation among the people actually involved in the process. Moreover, in ADEPT agents are autonomous and proactive, showing an intelligent behavior. For example, negotiation among agents is based on a negotiation reasoning model that exploits heuristics inspired by successful human negotiation behaviors. In ABACO instead, agents are acting according to a sensing/reacting model and negotiation can possibly be performed through the activation of a coordination mechanism added as a new layer dedicated to provide the desired negotiation framework. Moreover, mainly relying on direct negotiation between agents, ADEPT does not adopt a federation-type architecture (Genesereth et al. 1994) as it is instead done in ABACO, though the term constellation is used. Examples of federated agent architectures are SHADE and PACT (Tenenbaum et al. 1992) that have been used for the interoperation of cooperative agents at the team level of an organization. Though different terms are in use, all the architectures based on the notion of federations include agents similar to the Interface Agents in


52

ABACO. However, the services that these agents provide slightly vary from architecture to architecture. For example, in ABACO Interface agents do not provide automatic translation of ontologies, but this can be done through a dedicated coordination mechanism involving users to establish how the messages have to be manipulated. The description of this coordination mechanism is central in the second part of the dissertation. Agents are used for rethinking enterprise models also. In (Papazoglou 2001) intelligent business agents are proposed as the higher level of abstraction in model based solution to e-business application. For example, a distributed workflow application encompasses various types of application agents such as inventory and production agents. Each application agent has an area of specialization and agents need to cooperate to implement a business ecosystem, showing an intelligent behavior as in ADEPT. On the other hand, as in ABACO, there is a distinction between agents specialized within the domain area and others that provide supporting services to the agents realizing the application. However, the distinction is made at a different semantic level than in ABACO and agents are mainly intended to realize complex functionalities, such as scheduling, production, and distribution. This brief overview of the usage of agents for supporting articulation work allows us to point out some of the original aspects of ABACO. To our knowledge, none of the existing systems provides a set of basic building blocks at the semantic level of articulation work and allows combining them to express different languages, and therefore different perspectives on the articulation work. Moreover, none of the proposed approaches and systems recognizes, and introduces as first class concept, the existence of artifacts specifically devoted to support articulation work, and therefore clearly distinct from the artifacts belonging to the field of work. Finally we believe that the possibility to construct the support to articulation by combining coordination mechanisms dealing with specific sub-problems and possibly built at local level is an important aspect that has been underestimated in many proposals, where flexibility is seen only as the possibility to perform global changes to the description of the business process. On the one hand, the point of view taken by ABACO allows for a true distributed view of the articulation support; on the other hand, this true distribution implies to consider modifications under a regime of partial knowledge about the (global state of the) articulation support that is unique to the ABACO approach. How these modifications are handled in the ABACO approach will be explained in more detail in the second part of the dissertation.

Chapter 3: Alignment of protocols

53

Chapter 3:

Alignment of protocols

3.1 Introduction In this chapter we deal with the problem of changing protocols belonging to CMs and propagating the related effects on other protocols belonging to different CMs with which the former interact. As discussed in Chapter 1, protocol modifications is performed under a regime of partial visibility and partial autonomy of the actors involved in the modification process. This basic assumption has strong impacts on the requirements of a technology supporting the management of changes, in all the involved aspects, namely: 1) local modifications and the evaluation of their impacts on the other protocols, 2) the consequent negotiation among Roles if the modifications interfere with them, 3) the strategy to propagate changes among the various CMs, 4) the verification of the local and global consistency of the new coordination protocol in the related coordination mechanisms, and finally 5) the alignment of the current behavior of each involved CM to the new coordination protocol. Moreover, partial autonomy has also an impact on how to specify the various changes that occur during the collaboration involving agents belonging to different coordination mechanisms. In fact, under the hypothesis of partial autonomy, changes may concern:

• the structure of the protocol in terms of mutual relationships of the involved communications. Typically, modifying the degree of concurrency or the order of execution of some communication set.

• the parameters of the communications involved in the protocol: for example, when the communication flow is altered so as to by-pass an agent and directly connect previously disconnected agents; or when a new agent joins a coordination mechanism.

• the number of local activities, their mutual relationships, and how they are interlaced with the coordination protocol: for example, when an alternative path is introduced, or again, the degree of concurrency or the order of execution of local actions is modified.

Changes are commonly distinguished in static changes and dynamic changes. The former modify (part of) the structure of the protocols regulating the interactions among different coordination mechanisms. These changes do not affect the instances of the coordination mechanisms currently under execution, but only their new activated instances. Instead, dynamic changes enforce modifications of the current state of the involved CMs according to the modifications established on the related protocols (Ellis et al. 1995). Moreover, changes can be considered temporary or permanent. In the former case they reflect the idea of change of the related protocols to deal with unexpected events or events whose handling strictly depend on the current situation and hence not permanently affecting the organization of work. Conversely, permanent changes are motivated by


54

the need for adapting the current protocols to lasting organizational changes and/or to a new demand of support due to an evolution of the domain (Divitini et al. 2000). In our approach we consider the management of permanent static changes. The hypothesis of partial visibility and partial autonomy makes change management crucial since changes may be required locally and asynchronously. In order to support the handling on such types of changes it is important to go deeper in the analysis of the situation in which they realistically occur. In fact, many approaches propose solutions that are useful to define powerful supports but are based on the full access of a distributed protocol global state and suppose that changes occur synchronously on all components. Since these hypotheses can hardly be met in real situations, we consider here an alternative approach. According to our view, change management is a distributed activity and hence a form of articulation work which requires its own support. We propose here a specialized CM, Modify CM, to provide actors with the support to manage the articulation work associated to the propagation of changes. Modify CM contains an active artifact, called the hierarchy AA1, embodying information structures supporting the negotiation and a protocol defining the negotiation itself among the different Roles responsible for the management of the modification of the involved coordination mechanisms. The specificity of our approach is to deal with the management of the propagation of changes inside a coordination mechanism that do interfere with the other coordination mechanisms representing its environment. The chapter is organized as follows. The next section presents the related work focusing on the two constituent aspects of the Modify CM: how to support actors in the negotiation process concerning propagation of changes and which kind of information structures are needed in order to check consistency among the protocols involved by the initial proposed change. Section 3.3 illustrates the basic constituents of the Modify CM. Then, the next subsections describe how they are put at work to answer the requirements raised by propagation of changes under the hypotheses of partial autonomy and partial visibility. We show how actors are provided with a strategy for the management of changes and a number of criteria for their acceptance or refusal. Finally, Section 3.4 describes how the presented approach can be integrated in the ABACO architecture.

3.2 Related work Before to deepen the Modify CM we propose to support actors in the management of the propagation of changes, we present here different approaches to handle the same kind of problems. In particular the reported approaches are related to two different aspects the Modify CM encompasses in order to provide actors with a useful support. On the one hand, the aspects related to negotiation support, since the management of the propagation of changes is a distributed process requiring the involved actors to negotiate in order to achieve an agreement on the propagation of changes. On the other hand, the aspects related to the support needed to keep consistent during the negotiation process the different protocols affected by the proposed changes. As we can see, in the second case the different solutions proposed in the literature reflect the hypotheses on which the approach to handle the management of changes is based, that is whether the considered changes are static or dynamic, whether they are global or local, centralized or distributed and so on.

1 Remember that from the ABACO point of view this AA is represented by an agent, the hierarchy AA agent


55

3.2.1 Negotiation support More generally, the problem of supporting a negotiation to reach an agreement among actors is considered in different research areas. The area of Distributed Artificial Intelligence presents several proposals: for instance the Contract Net Protocol (Smith 1980) and its extensions (see e.g. (Sandholm et al. 1997)). We take a different point of view, since we consider negotiation as a social process where the role of technology is to support human decisions and not to substitute them. In this view, the technology can provide actors with supports ranging from weaker to stronger ones. Weaker supports simply provide actors with communication links in order to let them discuss and find an agreement without any explicit aid (as for example in videoconferencing systems or in ‘media spaces’ (Gaver et al. 1992; Hindus et al. 1996)). In addition, actors can be provided with a set of general communication primitives they can use for coordination purposes which can also facilitate their negotiation process (as for the Coordinator described in (Flores et al. 1988)). Another form of support to negotiation can be provided by technologies devoted to aid people in cooperative problem solving, as Delphi methods (Turoff et al. 1995) which establish a set of methodologies to find consensus among people inside groups, or voting algorithms designed to support decision making inside groups in Group Support Systems (GSSs) (Nunamaker et al. 1997). A more comprehensive support of actors during their negotiations is proposed in (Wulf et al. 2001): the authors illustrate different mechanisms allowing users to solve conflicts arisen as a consequence of the execution of a function provided by the technological framework they jointly use. These mechanisms establish different forms of conflict resolution giving the affected users different forms of control, visibility and negotiation capabilities that are structured, unstructured, structured single loops, and counter-controllable. For what concerns negotiation capabilities, in the first case the mechanism allows both users to choose from a set of predefined alternatives provided by the system implementing the mechanism. In the second case, actors are provided only with a communication channel and there is no additional technical support. In the third case, the user affected by the activator’s decision can only express a form of disagreement. In the last case, the affected user can express through a counter-controlling function her level of disagreement on the activation of certain functions, before they are really activated. Moreover, Wulf and his colleagues define an architecture that implements these mechanisms so that users can handle the conflicts by choosing the mechanism they consider more useful for the current situation. According to the definition of conflict proposed in the paper: “a groupware-specific conflict is defined as a special relationship in which one user either feels disturbed or affected by the fact that another user has executed a certain function”, the problem of management of propagation of changes could be considered as a specific case of the problem of conflict resolution considering the execution of a function by a certain user as the proposal of a change performed by a Role responsible for the modification of a coordination mechanism. Hence, in this view the proposed architecture could be used to manage the propagation of changes, even if this architecture provides actors with a support for the negotiation of propagation of changes without considering the aspects related to the consistency check of the proposed changes. On the contrary, our approach does not predefine a specific way to manage the interactions during the negotiation process, rather we claim that the construction of suitable information structures and the definition of a set of criteria, guiding and informing the responsible Roles of how changes in a protocol can affect the others, can be useful enough during the negotiation irrespective of the specific approach chosen to perform it. In other words, like in any other CM, the Modify CM


56

protocol is defined by the involved Roles using the information structures contained in the Active Artifact incorporating the consistency check functionality.

3.2.2 Consistency check The literature presents different approaches to maintain consistency among protocols affected by propagation of changes. These approaches differ in the ways changes are managed and in the characteristics of the considered changes. The principles used to manage changes can be divided in two broad classes: approaches based on the principle of compositionality that maintain consistence of the changes through a flexible combinations of modular (software) components carrying specific meaning in coordination (e.g., (Dourish et al. 1996; Glance et al. 1996; Kaplan et al. 1992; van Reijswoud et al. 1999)); and approaches based on theories supporting techniques that guide changes towards a new protocol which still is consistent with the previous ones. The first class is more related to a software engineering approach, where the changes are confined to the possibility of composition offered by the different components. In this way, the consistency is kept because all the compositions allowed by the support are also consistent. The second class is more related to a modelling approach, based formal theories, which allow the check of consistency of a new protocol with respect to the older one, using suitable behavioral properties. Here we just consider the second class of proposals since they are more related to our approach. If we consider static changes, and specifically permanent changes, a big effort has been devoted to the definition of techniques which are borrowed from system construction and are mainly based on the notion of refinement preserving system properties (e.g., in the framework of Petri nets (Brauer et al. 1991; van der Aalst 1997)). Temporary changes did not receive great attention apart from a recent proposal by van der Aalst on which we will come back later on. They are just considered as special cases of permanent ones, let us say, as volatile changes with similar behavioral requirements. Dynamic changes received an increasing attention in the last years. The migration of instances from the old version to the new workflow structure was initially treated in (Ellis et al. 1995): since then, other solutions have been proposed under different hypotheses in the framework of Petri nets, specifically for the class of safe nets (e.g., “simple workflow” (Agostini et al. 2000) or Workflow-Nets (van der Aalst et al. 1999)). An important aspect which distinguishes the different approaches refers to their ability to manage changes which are centralized on a unique, common, global protocol, or distributed on different protocols representing the coordination of activities related both to local organizations and to larger organizations crossing the local ones. All the above mentioned approaches refer to the management of centralized changes. That is, changes are managed under the hypothesis that all the information is contained in the considered global protocol and, consequently, that consistency of any change can be completely evaluated within it. This hypothesis is however unrealistic in front of the distributed nature of any form of cooperation in complex settings (Simone et al. 1998). The only exception is the approach proposed by van der Aalst in (van der Aalst et al. 1999) that we consider in more detail as it shares both similarities and differences with the one we propose. The main common feature is the usage of techniques based on observability of actions (Milner 1980), which distinguishes both proposals from any other one. Hence, both techniques are defined to manage changes affecting different protocols and to check their consistency proposing forms of


57

abstraction that cannot be restricted neither to refinement nor to closed systems. Openness is the basic ingredient of observability and abstraction is based on the visibility/hiding of some action, at the same level of granularity. The main difference concerns the final goal. In (van der Aalst et al. 1999) the focus is on rules governing modifications so that the latter do not interfere with the environment and do not cause problems in the definition of dynamic changes and on the check of their consistency. Instead, our goal is the management of the propagation of changes that cannot be avoided and possibly interfere with the environment of the changed components. A second difference is in the usage of abstraction. In (van der Aalst et al. 1999) it is proposed to introduce the notion of inheritance which is used to manage different versions of protocols or to guarantee a proper solution of migration of cases. Our use of abstraction is towards the definition of different “places” where propagation of changes can be negotiated and verified against environments at different levels of comprehensiveness. To sum up, the two approaches use compatible basic notions and could be integrated to manage a wider set of situations than each one taken in isolation.

3.3 The Modify CM: negotiating propagation of changes

3.3.1 More on protocols Before illustrating how the Modify CM is built to support the negotiation of propagation of changes, it is in order to specify how protocols are constructed in coordination mechanisms. In ABACO the definition of the protocol of a CM is the result of the communication capabilities of its constituting CAWs, possibly in combination with a Protocol and/or Activity agents devoted to manage the flow of work when a stronger form of control is required. The Protocol agent is expressed in terms of relations among CAW agents according to the form of control required by the related form of cooperation. To achieve coordination each agent can communicate with other agents through scripts defined using the common agent communication language. For sake of illustration, let us consider a Protocol agent composed of Tasks. Protocol agents and Activity agents contain in their data structure (working memory) the causal relation linking together Tasks and Interactions and Actions and Interactions, respectively. Tasks, Actions and Interactions are called altogether nodes. The causal relations (abstracting from the details of their specific implementation) can be conceived of as expressed through any of the well-known formalisms representing concurrent processes: in our case we adopt the Petri net formalism (Desel et al. 1998). Moreover, Protocol agent contains an interpreter of the Petri net formalism in order to ‘execute’ the related behaviors when the agent is activated. The same representation can be constructed for the coordination behaviors expressed by the pertinent scripts. Hence, the whole protocol incorporated in a coordination mechanism can be seen as a set of protocol components expressed in terms of Petri nets that run concurrently and synchronize themselves through the Interactions they incorporate. A change of the protocol is therefore a change of either the causal relation among nodes and/or of the nodes themselves. In order to support the evaluation of how a change of a protocol affects other protocols is useful to combine them into a global (possibly disconnected) Petri net by identifying correspondent communications. Hence, the global protocol (global in the scope of the considered coordination mechanism) contains three sets of nodes: Tasks/Actions, Local Interactions (i.e., between the components of the same coordination mechanism), and External Interaction (i.e., with


58

components of other coordination mechanisms) (see Figure 3.3.1 where each dotted box includes the global protocol of a CM).

Figure 3.3.1: The interactions among nodes of global protocols representing two related CMs.

CM1

CM2

External Interaction

Local Interaction

Local Interaction

Task/ Action

CAW agents(*)

External Interaction

Local Interaction

Local Interaction

Task/ Action

(*) CAW agents with coordination capabilities: Roles, AAs, Resources

mediated by External Interface agent mediated by Local Interface agent

coordination

coordination

coordination

coordination

coordination

coordination

CAW agents(*)


59

3.3.2 The approach Our approach to change management (Donatelli et al. 2000) is based on the system specification technique introduced by Buchholz in (Buchholz 1996). Paraphrasing what described in the previous section in terms of Buchholz terminology, the whole system refers to the global Petri net composing the set of global protocols related to the coordination mechanisms defined in the ABACO framework, while a single component of the system refers to a single global protocol of a coordination mechanism. For sake of simplicity, in the following we refer simply to the set of coordination mechanisms to consider the whole system, and to a coordination mechanism to identify both a system component or the related Petri net identifying the corresponding global protocol. Moreover, when we consider the behavior of a CM we can refer, according to the context, both to the single agents’ behaviors belonging to the considered CM and to the single global connected Petri net representing its protocol. Buchholz’s technique proposes a quite original notion of hierarchical model: in fact, each node of the hierarchy tree describes the whole system as the composition of a part of the system specified in more detail with a more abstracted representation of the rest of the system. In particular (Figure 3.3.2): leaf node i includes a detailed description of a system component, that is a coordination mechanism, called “local behavior” (LBi), and an abstract representation of the remaining system components, that is the set of the other coordination mechanisms describing the system, called its “local environment” (LEi); intermediate node i having n children contains an abstract representation of the local behavior of each one of its children and a single abstract representation of the rest of the world, i.e., of all the nodes that are not part of the subtree rooted in i; additionally there can be some local-to-i behavior, called “coupling activity” (CA), to specify how the the above abstractions interact; the root node is like an intermediate one, but it contains only the representation of its children. It is important to observe that each coordination mechanism appears in several points of the tree: as the “local behavior” Li in the leaf node i, in the abstract representation of i inside its father node, and in the local environment of all the other leaves. To apply Buchholz’s approach we need a “hierarchy kit” with four ingredients: 1) a modelling formalism to describe the content of the nodes, 2) an operator to compose abstract and detailed representation of node components, 3) one or more equivalence notions supporting different types of abstraction, and 4) one aggregation algorithm per equivalence notion, or equivalently, a set of reduction rules that realizes, at a structural level, the required aggregation. First Ingredient: unlike (Buchholz 1996) where components are mainly represented in terms of Labelled Transition Systems, we adopt the modelling formalism of labelled Place Transition nets (P/T nets) (Desel et al. 1998), for the compromise they realize in between ease of representation and formal definition. In labelled P/T nets, labels of transitions are used to distinguish actions that are local to a CM (τ label) from observable communications, and labels associated to places identify communication buffers between CMs. For a labelled P/T net N, the alphabet α(N) of N contains the labels of the transitions. Let Com denote the set of all possible transition labels, then α(N) ⊆ Com. In the graphical representation of a labelled P/T net labels are associated to transition and place names, separated by a vertical bar, and boldfaced to increase readability; τ labels are usually not written.


60

Figure 3.3.2: hierarchy definition.

Figure 3.3.3: transition superposition.

Second Ingredient: to compose labelled P/T nets we use the classical operations of superposition of transitions and superposition of places of equal label (Best et al. 1998). Given two labelled P/T nets LS1 and LS2 and the “synchronization set” L’ ⊆ L of labels, we denote the labelled P/T net LS, place and transition superposition of LS1 and LS2 over L’, as LS = LS1 ||L’ LS2 . Please note that transitions (places) that represent the superposition of two transitions (places) of equal label are relabelled to τ in the resulting net. An example of transition superposition is illustrated in Figure 3.3.3, where LS1 is composed


61

Figure 3.3.4: place superposition in labelled P/T nets.

with LS2 over the set L = {a}. In the resulting net transitions labelled by a are substituted by the the cross-product of the transitions of equal label: in this example transition t5 substitutes t2 of LS1 and t3 of LS2 . It is obvious that the ||L operator realizes a synchronous communication among the two nets. Since the synchronization transitions are τ labelled, each superposed transition represents a point to point communication. Place labelling and superposition is used to realize asynchronous communication, where the place is the buffer: therefore we assume that labelled places have only input arcs or output arcs, and that when two places in two nets have the same label, then one of them has only input arcs and the other has only output arcs. An example of this reduced form of place superposition is illustrated in Figure 3.3.4, where the new place P7, obtained by the superposition of P3 of LS1 with P6 of LS2, plays the role of the buffer of an asynchronous communication between LS1 and LS2. Third Ingredient: abstraction is based on the notion of observational equivalence. Several notions have been proposed in the literature (see, e.g., (Pomello et al. 1992)) mainly based on what an observer may distinguish. The approach we are proposing does not depend on the adopted equivalence, provided it is a congruence with respect to parallel composition and has associated equivalence preserving reduction rules. Specifically, we use the notion of Exhibited-Behavior

equivalence EB≈ which distinguishes two systems with respect to deadlock, and to “when the choices

are made”: as a result EB≈ preserves deadlocks and the language of observable actions. In (Pomello

et al. 1992) there is a comparison of EB≈ with other notions, where it is shown that

EB≈ is weaker than

Branching Bisimulation (van Glabbeek 1990), which is used in (van der Aalst et al. 1999). Our choice was guided by the availability of a, unfortunately not complete, set of reduction rules, but most importantly by the compatibility of this notions with aspects related to Stochastic Petri nets (Simone et al. 1992). In this way, the approach (especially consistency criteria) could be improved by features related to performance evaluation. Fourth Ingredient: aggregation is obtained by applying to a P/T net a number of equivalence preserving reduction rules, defined in (De Cindio et al. 1985), that are based on τ-labelled transition elimination. If N is the source labelled-P/T net, we denote by red(N) the reduced labelled-P/T net.

Reduction rules for EB≈ (Simone et al. 1992) can be applied in an automatic manner, moreover there


62

is a stochastic version of them that maintains lumpability of the underlying continuous time Markov chain, so that, as mentioned above, they are suitable to performance evaluation techniques as well.

3.3.3 The basic idea Since the coordination of activities can be modelled in a distributed way considering several interacting coordination mechanisms, partial autonomy implies that each Role in a coordination mechanism has different degrees of visibility of the protocols belonging to different CMs. The same happens when a responsible Role is in charge to modify a CM changing the behaviors of the related agents. The aim of this section is to show that the modeling approach presented in the previous section provides the involved Roles with means useful to handle both situations. In the case of a change triggered by the Role responsible for modification of CM X, that is, X becomes X’ and affecting other CMs, the hierarchical modeling approach provides an effective support to manage this change. In this case the hierarchy represents a support to this Role for managing the change of X and the negotiation with the Roles involved by the impacts of these changes on the coordination mechanisms the Role responsible for X is aware of: hence we call it change hierarchy. These CMs, together with X’, constitute the local behavior of the leaves of the hierarchy. The local environment of any CM Y, different from X’, contains the local environment of X’ in which X’ is added and Y is deleted. This information will be used by the Role responsible for Y to decide how to potentially change the behavior of Y’s agents to comply with the change under negotiation. To support negotiation, the contents of various nodes and their relationships have to be interpreted in an appropriate way. The initial contents of the hierarchy represents the old situation but for the change from X into X’. As a plan for to support Roles in negotiation, the hierarchy organizes the CMs (and consequently the negotiation among their responsible Roles) according to the priority by which they will be involved. The partial order by which this involvement is scheduled defines the structure of the change hierarchy under construction. In this view, the intermediate nodes of the change hierarchy define what we call places for negotiation. In fact, the Roles responsible for the CMs whose aggregated representations are contained in intermediate nodes are involved in the negotiation, whose constraints are expressed by the aggregated view of the father node (that is, of the remaining portion of the system). More specifically, the aggregated representations of the children of an intermediate node provide the latter with the aggregated results of their mutual negotiations that in that node have to be checked for consistency with the aggregation of the father node. As soon as partial results are acceptable, in the leaves or in the intermediate nodes, they are propagated, in aggregated form, to the other nodes up to the root involving the Roles responsible for those nodes. Hence some parts of the contents of the various nodes can be empty, filled-in or updated according to the various negotiation steps. The negotiation among Roles progresses until no inconsistency is left. This must be true at the root, otherwise the negotiation fails, but it can become true also at intermediate nodes. The approach is an optimistic one, in the sense that new requests of change to not yet involved CMs are propagated to the right along the hierarchy, under the hypothesis that the Roles responsible for these CMs will be able to respond to the new requests to meet the final goal. Of course, this optimistic approach is based on the idea to provide these Roles with some criteria supporting decisions that, if not met, make the negotiation fail or backtrack (to the left) along the hierarchy. It is important to notice that the availability of the hierarchy kit mentioned in the previous section


63

allows one to envisage a technological module able to perform hierarchy construction and modification as well as the management of the communication among the involved components. This module represents the core of the Modify CM providing the involved Roles responsible for modifications with a support for the negotiation of the related propagation of changes. In fact, the hierarchy in this case represents the information structure supporting the negotiation and, in terms of ABACO, can be managed by a suitable Artifact agent, while the management of communication is part of the protocol supporting negotiations among the involved Roles. As claimed in Section 3.2.1, we do not propose a specific protocol to support negotiation among Roles, but we leave them free to define their own protocol with the aid of the information provided by the hierarchy Active Artifact agent. When needed, it also possible to support negotiation among the involved Roles in a stronger way providing them with more specific technical supports as described in the same section. The following sections will deepen the general ideas sketched above.

3.3.4 Modeling partial visibility Since, as a consequence of partial visibility, each agent in a CM has only a limited knowledge of the rest of the system, each local environment will comprise only a subset of CMs. Partial visibility is modeled by a publishing/subscribing mechanism as follows. Each Role responsible for the modification of X publishes its reduced version red(X) to hide the internal behavior of X. Each Role responsible for a CM is allowed to subscribe to the communications of other CMs in accordance with some interorganizational policy. By default, the subscription applies to the communications of the agents of CMs with which the agents of X directly interacts. In addition, some communications belonging to the agents of the remaining coordination mechanisms can be made visible to agents of X simply because there is an agreement between the Role responsible for modification of X and some Roles responsible for the modification of other CMs. To this aim for each CM X there is a set of communication labels representing its acquaintances (Agha 1988), denoted by Acq(X), that is the set of communications of which its agents have a full visibility: α(X) ⊆ Acq(X) ⊆ Com. We denote by )(XAcq = Com \ Acq(X).

The local environment of X models its view of the overall system reduced with respect to τ actions and filtered by the set Acq(X). For this purpose, we introduce the notion of an “encrypted” communication, which is denoted by a for all a ∈ Com. Transitions labelled by encrypted

Figure 3.3.5: the meaning of LE(X)

communications do not show to agents of X any information on their parameters (typically source or destination, since communication is point-to-point); this information is however visible to the mechanism managing the parallel composition in order to handle the related communication in the appropriate way. Unlike τ actions, encrypted communications cannot be reduced by any reduction


64

rule. In order to refer to the (agents of) CMs containing communications in the acquaintances of X we define ACQ(X) = {Y∈ COMP : Y ≠ X and α(Y ) ∩Acq(X) ≠ ∅} where COMP is the set of all CMs, and the local environment of X using ACQ(X) is defined as follows2: LE(X) =

)]()([)()(|| XAcqXAcqXACQY

Yred →∈

Figure 3.3.5 shows the basic idea: in LE(X) the communications among agents within X are explicit; the communications synchronizing the behavior of agents of CMs inside ACQ(X) are set to τ , and finally, the communications with the remaining agents of CMs are encrypted. The above definition of partial visibility guarantees that no strong hypotheses are made on the target reality. In fact, the only visibility which is required is about the communication interfaces each agent in a coordination mechanism needs to know in order to perform its behavior. These interfaces can be read as contracts between agents of CMs which are unavoidable when coordination of activities in larger organizations is modelled as coordination of activities among distributed local ones. Moreover, it is important to notice that partial visibility is in principle fully asymmetric among CMs and by consequence, mutual visibility does not imply a uniform sharing of information within and across the coordination mechanisms crossing local organizations. Working example (1). Let us consider coordination of activities modelled in terms of coordination of activities among four interacting CMs A, B, C and D. Each (protocol of a) CM is described by a labelled P/T net. For sake of brevity we show in Figure 3.3.6 the four nets after a first reduction step to remove τ actions. For example the net for A contained nine places and eight transitions, while the reduced one has only eight places and seven transitions. There is an asynchronous communication between A and B through the label buf, that is associated to place A9 in A and place B7 in B. Transitions that send and receive to and from the buffer are labelled send_buf and rec_buf, respectively. The global system can be obtained by the following composition: (((A ||{buf, b} B) ||{c, d, l, e, f} C) ||{g, i, h} D) To compute the local environments it is necessary to define the visibility of each CM: let us suppose that Acq(A) = α(A) ∪ {g}, and that Acq(Y ) = α(Y ) for Y∈ {B; C; D}. Figure 3.3.7 shows, as an example, the local environment of A.

2 From now on, the operator of parallel composition will leave the synchronization alphabet implicit and mention explicitly the involved components.


65

Figure 3.3.6: the CMs A, B, C and D

Notice that the construction of a local environment may synchronize a number of nets, and therefore a number of observable transitions and places may become τ. This may allow further application of the reduction rules. For example, in Figure 3.3.7 the portion of B in net LE(A) has place B5 and transition TB4 removed, since f is now τ and it can be reduced, although of synchronization with C, since also C is included in LE(A).end(1)

3.3.5 Changes without negotiation The information contained in the local environment of a CM X provides an initial support when the Role responsible for X needs to change the behavior of X into X’. In fact, LE(X) allows X to complete its open behavior so that the Role can verify the compatibility of the changes with respect to the CMs aggregated in its local environment. Compatibility can be defined and checked at

different levels, by using the notion of EB≈ -equivalence. If

X EB≈ X’ (1)


66

the change does not affect the communicative behavior of X with its environment, by definition of EB≈ . If the previous check fails, we can define an alternative notion of compatibility, based on a

weaker requirements on X’ :

X || LE(X) EB≈ X’ || LE(X) (2)

This equation ensures that all communications of X’ can still be properly matched with those offered by the environment. Observe that X || LE(X) can be seen as the communication

Figure 3.3.7: the local environment of A

frontier with the “rest of the world”, that we shall name F(X). In both cases the change of X into X’ can be realized without any negotiation. Working example (2). Let us suppose that the Role responsible for D wants to change D’s behavior into D’ by “sequentializing” the concurrent communications g and h: the new sequence is g followed by h. The check of Eq. 1 obviously fails, but that of Eq. 2 is satisfied, since the local environment of D offers action g followed by h too. D can then be changed into D’ without any negotiation with the Roles responsible of changes of other CMs. Instead, if in D’ h is followed by g both checks (Eq. 1 and Eq. 2) fail. In fact the local environment of D expects g followed by h and the change requires negotiations which involve the Roles responsible for the modification of A and C. end(2) If the change proposed by the Role responsible for X cannot be avoided or revised to find a modification compatible with the local environment of X, then the aggregated information contained in LE(X) becomes too coarse grained to be used as a support for the Roles to change management. In fact, in this case a propagation of the change is needed and its negotiation among Roles requires, in the general case, a more detailed information about each involved CM in order to


67

evaluate the nature of the impacts triggered by X’: this is where the change hierarchy comes into play to support the Roles in the decision.

3.3.6 Negotiating changes Before discussing how the change hierarchy is constructed by the support provided by the Modify CM and used by the Role proposing changes, it is necessary to define when a negotiation among Roles is successful under the hypothesis of partial visibility. A negotiation is successful when altogether the involved changes modify only the CMs belonging to ACQ(X), in such a way that their joint observable behaviour is maintained. That is to say:

F (X) EB≈ X’ ||Y ∈ACQ(X) Y’ (3)

where Y’ is Y after the modification. On the one hand, this condition allows for any type of modification of X and Y into X’ and Y’ (e.g. change of alphabet, causality, and splitting into subcomponents). On the other hand, this definition of successfulness reduces the space of possible modifications that we allow here. In fact, it prevents changes on the CMs outside ACQ(X) which are produced by coordination mechanisms in ACQ(X) as side-effects of the change triggered by the change in X. We want to notice that, if the change proposed by the Role responsible for X affects CMs outside ACQ(X), then the approach still holds if, before starting the negotiation of the change, the Role responsible for the modification of X negotiates with the Roles responsible for those CMs their mutual visibility. In this case, the process starts with the enlarged ACQ(X). However, in Section 3.3.7 we will further discuss how to relax the above limit.

3.3.6.1 The hierarchy supporting change management

When a Role responsible for the modification of X proposes a change of X’s behavior into X’ affecting other CMs, the proposed approach suggests to construct a hierarchy where X’ plays a distinguished role. As usual we start from the leaves (see Figure 3.3.8). There is a leaf containing X’ and LE(X). In addition, there are as many leaves as the coordination mechanisms in ACQ(X): we denote them conventionally by X1, ... Xn where obviously n = | ACQ(X) |. The i-th leaf (for i∈ {1 ... n}) contains Xi and its local environment defined as follows: LE(XiX’) =

)]()([}{\)')(()(||

iii XAcqXAcqXXXACQYYred →∪∈

(4)

That is, X’ exports to Xi all the CMs X’ can see (and may be Xi cannot), but filtered by Acq(Xi). This means that each CM Xi has, beside its own local environment LE(Xi) information provided by X’ that the Role responsible for Xi can use to modify the behavior of Xi. The next step is to define the upper nodes of the change hierarchy supporting the involved Roles in the negotiation of the change from X to X’ that may affect in different ways the CMs in ACQ(X). Some impacts are evident from the check of compatibility of X’ with LE(X) (Eq. 2). In fact, the change may modify the communication alphabet of X by adding or deleting some communications, or the causal relationships of existing communications, or both. This analysis allows the Role responsible for X’ to consider a subset of CMs X1 ... Xk that are directly affected, while the impacts on the remaining ones in ACQ(X), Xk+1 ... Xn , (that we call potentially affected CMs) is implicit as it is due to the interactions among, possibly, all the CMs composing the system. Figure 3.3.8 shows the hierarchical organization that we shall take as reference for this section: the Role responsible for X’ starts the negotiation involving the responsible Roles from the directly affected coordination mechanisms, that have different levels of importance in the negotiation of the


68

change, as some Roles have to be involved first to find a solution that can be imposed with different strength on the other ones. Let us suppose that the directly affected CMs (and, as a consequence, the related Roles responsible for the modifications) can be partitioned into three decreasing priority sets: {X1, ... , Xj}, {Xj+1, … , Xl} and {Xl+1, … , Xk} with j < l < k. The hierarchy of Figure 3.3.8 is constructed in order to act according to these priorities. Notice that the above sets could be further partitioned if it is useful to have, at the father node, a more modular view of their aggregated behavior. In any case, the potentially affected CMs are grouped in the same priority class since we assume that nothing is known about their role in negotiation. Hence, the hierarchy can capture different strategies by allowing flexible aggregations of CMs belonging to the same priority class and by locating aggregations pertinent to different priority classes at different levels of the hierarchy. Working example (3). Suppose the Role responsible for the modification of A wants to change A’s behavior into A’ so that the communications c and d currently with C are instead done through B. A is modified into A’ as

Figure 3.3.8: a change hierarchy supporting the responsible Role in the change of X into X’

shown in Figure 3.3.11. A’ is not EB≈ with A, since two new labels are present (cc and dd), and two

are missing (c and d). Also the check of Eq. 2 fails, as expected, since there has been a change of alphabet. Obviously, this change directly affects B and, if and when the Role responsible for B accepts, then also the Role responsible for C will be involved since the change affects the communication between A and C. Since the Role responsible for A gives priority to B over C, the support provided by the Modify CM for the Role responsible for A constructs a hierarchy whose structure is shown in Figure 3.3.9. end(3)

3.3.6.2 How to use the change hierarchy

The first step we consider is the negotiation between the Role responsible for X’ and the responsible Roles for the CMs belonging to the highest priority class, namely {X1 ... Xj}. Let Xi ,


69

for i∈ {1 ... j}, be one of these coordination mechanisms. The local environment LE(XiX’) in the change hierarchy can provide useful information to the Role responsible for Xi to negotiate Xi’s change with the Role responsible for X’, and to evaluate the impact of this change on the other CMs. In fact, this information can at the same time play the role of a constraint to any local decision of the Role responsible for Xi and of an enlargement of the knowledge contained in the local environment of Xi, since LE(XiX’) contains informations on CMs not necessarily present in LE(Xi). The problem is how the Role responsible for Xi should use this information in combination with the information contained in the local environment LE(Xi). Here is where the technological support provided by Modify CM and based on the hierarchy kit plays an essential role, by combining information from different sources. From ACQ(X) and ACQ(Xi) the support can derive the following set: ACQ(X’, Xi) = {{X’} ∪ ACQ(X) ∪ ACQ(Xi)} \ {X, Xi} that can then be used to define LE(XiX’) ⊗ LE(Xi) =

)]()([),'(()(||

iii XAcqXAcqXXACQZZred →∈

(5)

This information describes the constraints the change of Xi has to satisfy in relation to its local environment possibly augmented by the constraints requested by X’, suitably encrypted by

)( iXAcq . The same construction is done for all Xi with i∈{1 ... j}. Then, all the Roles responsible for these CMs can individually propose the new version X’i to the node, called N in Figure 3.3.8, playing the role of the negotiation place between the Roles responsible for X’ and for X1, … ,Xj. The above procedure can be applied for each place of negotiation, that is, at a level greater than one in the hierarchy. In this case, the pertinent node, as for example M in Figure 3.3.8, contains the aggregation of a partial negotiation at node M - 1 for which the acceptance criteria of the next section led to a positive result. Since partial results are propagated in the hierarchy, then all the nodes, and among them M, are updated accordingly. So, the Roles responsible for the new coordination mechanisms involved in M can use the information updated by the Modify CM both in the leaves of the hierarchies involving these coordination mechanisms and in the related local environments built by using Eq. 5, where Z obviously becomes Z’.

3.3.6.3 Acceptance criteria

The next point is to define the criteria the support provides the Roles involved in the negotiations with to guide them in the management of propagation of changes. The involved Roles should cooperatively and incrementally apply these criteria for evaluating the acceptance of the proposals they have individually submitted in order to proceed in their negotiation process. We discuss these criteria in relation to a generic negotiation place M which has nodes M- 1 and Mi, for i∈ {1 ... m}, as children. Obviously, if M is at level one in the hierarchy, M - 1 is the empty net. Moreover, we denote by aggregated environment AE(M) the aggregation of the father node of M , that is, the aggregation of all the remaining nodes not belonging to the subtree rooted in M. First criterion The modifications from Mi into M’i, for i∈ {1 ... m}, proposed by the involved Roles are accepted at M if the following holds:

M -1 || M’1 || ... || M’m || AE(M) EB≈ F (X) (6)


70

The left hand side of the equation expresses the combination of the results of the previous negotiations in M - 1 with the current proposals M’i, and the portion of ACQ(X) which did not participate to those negotiations. If the equivalence holds, the negotiation stops, since it proves its success according to Eq. 3. If this is not the case, then we have to consider different situations. To this aim we define Σ ≡ (M1 || ... || Mm) Σ’ ≡ (M’1 || ... || M’m ) ∆- ≡α’(Σ) \ α’(Σ’) ∆+ ≡ α’(Σ’) \ α’(Σ) where α’(Σ) ≡ α(Σ) \ α(F (X)) and α’(Σ’) ≡ α(Σ’) \ α(F (X)) ∆- contains the communications no more offered by Σ’ and ∆+ contains the new communications offered by Σ’. Second criterion The second criterion establishes that if ∆+ ∩ α’(M - 1) ∩ α’(AE(M)) ≠ ∅ (7) the proposed changes contain violations of the point-to-point communication that prevents more than two CMs to offer the same communication. Consequently, the changes have to be reformulated and submitted again. If this is not possible, then the negotiation fails.

Figure 3.3.9: the hierarchy supporting the change of A into A’ at the negotiation place M


71

Third criterion The third criterion establishes that if ∆- ∩ α’(M - 1) ≠ ∅ (8) the proposed changes does not respond any more to the expectations of the negotiating Roles at node M - 1, since some communication label is missing. If these changes cannot be avoided, a re-negotiation among the Roles responsible for the pertinent CMs is required (backtracking). Fourth criterion The fourth criterion is based on the following sets: ∆-

R ≡ ∆- ∩ α’(AE(M))

of the communications no more offered to the right of the hierarchy and ∆+

R ≡ ∆+ \ {α’(AE(M)) ∪ α’(M - 1)}

of the new communications offered to the right of the hierarchy. The fourth criterion establishes that the proposed changes can be accepted if:

M - 1 || Σ || D(∆-R)

EB≈ M - 1 || Σ’ || D(∆+

R) (9) (where D(∆) is the daisy net built on ∆ ⊆ Com) that is, the proposed changes do not interfere with the already negotiated ones and moreover:

F (X) ≤EB

M - 1 || Σ’ || AE(M) || D(∆+R) (10)

(where A ≤EB

B means that B “simulates” A)3 , that is, the partial results of the negotiation at node M are not consistent with F(X) but there is nothing at this stage preventing the possibility of finding appropriate causal relations for the communications in ∆+

R that will satisfy the global constraint expressed by F(X). Fifth criterion If the previous relation does not hold, then the only way for the Roles to decide if it is worthwhile to proceed the negotiation is to look at the information provided by the hierarchy kit available at the current node M, that is to say to the counter-examples provided by the algorithms

that check EB≈ and ≤

EB

. If the changing process proceeds, then the aggregation of M updated with the prospective modifications is put into the father node M + 1 where the acceptance process is repeated. If instead the changing process does not proceed, then a failure is declared, or a backtracking activity takes place, as in the case considered in the third criterion. Backtracking means that a portion of the changes can be accepted by the involved Roles while others are refused. Let us consider the case of the change of alphabet, that is to say, a modified child M’i of node M does not offer a communication that was offered by Mi, and the partner of the communication is a children of a node M - j. The involved Roles can decide to backtrack the negotiation process by either refusing M’i and accepting M - j, or vice versa. If M’i is refused the process starts again from node M. If all changes are accepted, but the one of M - j, then the changing process starts again from M - j in a new system with the agreed upon changed coordination mechanisms. The same idea applies if the change involves causal relations among communications.

3 The same idea of preorder is proposed for many equivalence notions, see e.g. (van Glabbeek 1990) and (Pomello et al. 1992).


72

Figure 3.3.10: LE(BA’ ) in the change hierarchy supporting the responsible Role in the change of A into A’

Working example (4). Let us now consider again the change of the behavior of A into A’ proposed by the responsible Role, that in working example(3) was shown to require the change hierarchy of Figure 3.3.9. For the Role responsible for B to take care of the change, the leaf node B contains a local environment computed according to Eq. 4 and ACQ(A): LE(BA’) = )||||'( )]()([DCAred BAcqBAcq →

The corresponding net is shown in Figure 3.3.10. The information in LE(BA’) is combined with LE(B), according to Eq. 5. Using this information, the responsible Role for B modifies B into B’, as shown in Figure 3.3.11. Then, the first criterion is applied by the Roles to decide whether the modification of the whole node N comprising A’ and B’ can be accepted. This check fails: in fact, the parallel composition of A’ and B’ contains the labels c’ and d’ that do not belong to the alphabet of F (A), which is empty. Since the rule of point-to-point communication of the second criterion is not violated, the third criterion should be checked. The sets ∆- and ∆+ are computed for N . ∆- = {c; d}, that is, it contains the two labels that have been removed from the set of labels A and B offered to the rest of the system. For analogous and symmetric reasons, ∆+ = {c’; d’}. The third criterion is not met since α’(M - 1) is empty: this means that there is no need of an immediate backtracking. The negotiating Roles consider now the fourth criterion. The set ∆-

R is equal to ∆- since c and d, offered by C, are in the alphabet of AE(N) =C || D. The set ∆+

R is equal to ∆+ since the new labels c’ and d’ are offered to the right of the hierarchy. The daisy net D(∆-

R) contains a place with two self loops labelled c and d, respectively. Similarly, the daisy net D(∆+

R) contains a place with two self loops labelled c’ and d’, respectively, so that:

A || B || D(∆-R)

EB≈ A’ || B’ || D(∆+

R) is true. Then we check Eq. 10, which is also true. Therefore the changes of A into A’ and of B into B’ are accepted by the involved Roles negotiating at node N. Intuitively, the changing process continues since there is a “hope” that the responsible Roles for the remaining CMs (in this case C) will “adjust” the problem of the unmatched labels c, d, c’, and d’.


73

Figure 3.3.11: the CMs after the modifications consequence of the proposal of the Role responsible for A

Now the Roles move one level up (node M) in the hierarchy of Figure 3.3.9. In virtue of the acceptance of the negotiation at N, LE(CA’) is recomputed with the new CMs A’ and B’ according to Eq. 5. On the basis of this information the responsible Role modifies C into C’, by renaming transitions labelled c and d into c’ and d’, as shown in Figure 3.3.11. The acceptance cycle starts again. The first criterion is satisfied at node M and the negotiation stops with the change negotiated at node M being accepted. Hence, the parallel composition of A’, B’, C’, and D is the modified system. As another example of modification, we consider the change of D into D’ described in the second part of working example(2). Since the Role responsible for D’ decides to manage the change by involving the Roles responsible for A and C simultaneously the change hierarchy is as in Figure 3.3.12. The contents of the nodes are built again by using Eq. 5. Since all CMs of ACQ(D) are considered at the same time, there is a single negotiation place N for the Roles which coincides with the root of the hierarchy. The Role responsible for A uses the information in LE(AD’) to modify A into A’ , so that h precedes l as shown in Figure 3.3.13. Using a similar procedure, the Role for C modifies C into C’, where l


74

precedes g.

Figure 3.3.12: the hierarchy supporting the Role in the change of D into D’

Figure 3.3.13: the CMs after the modifications r consequence of the proposal of the Role responsible for D

The first criterion is met, and therefore no additional negotiation is needed. Observe that CM B is not part of the hierarchy, since B ∉ ACQ(D). Therefore the interactions of A, C, and D with B are visible in the two nets compared in Eq. 6: the first criterion guarantees that the modifications preserve the interface with B. end(4)

3.3.7 Negotiation is a distributed process In the previous sections the proposed approach to change management was illustrated under some hypotheses on how the negotiation among Roles is conducted. Specifically, the Role responsible for X plays a primary role since the criterion to have a successful negotiation prevents side-effects on components outside ACQ(X). Obviously this is a quite serious limitation. However, some strategy is needed to govern a distributed decision process in order to avoid divergence. A first generalization of the above strategy can be that, when a Role responsible for a CM Y has to


75

change Y’s behavior and proposes it in the appropriate place of negotiation, it can act in the same way as the Role responsible for X did. That is, this Role could look at local environment of Y, evaluate the impacts on the CMs it interacts with, and possibly send them requests of changes with the related contextual information. This means that each Role responsible for the modification of a CM involved in a primary negotiation can activate sub-negotiations supported by the appropriate hierarchy. The latter is managed by a new instance of the Modify CM which activates the related hierarchy Active Artifact agent, and used to validate the incremental local solution with the criteria illustrated in the previous sections. When sub-negotiations are completed, then their results are propagated back to the places of negotiation where they are expected. In this more articulated and realistic scenario, negotiation can be seen as a distributed process among Roles responsible for CMs cooperating towards the common goal to positively answer to the initial request of the Role responsible for X by respecting local and global constraints. Of course, the real change can occur only when all involved Roles of the affected CMs agree on the distributed solution. In this scenario it is likely that each Role responsible for a CM can receive different requests of change coming from different originators (places of negotiation). Consequently, the problem is to synchronize the various sub-negotiations among Roles in such a way that the possibly different requests can be considered in a coherent framework to increase the chance of converging to the desired final solution, if possible. The tight synchronizations carried out in negotiation places considered here are an example of a possible, although limited, solution. The distributed negotiation described above represents a more complex scenario of articulation work with respect to the articulation work needed to manage a single propagation of changes at time. In this case the related support to articulation work expressed in terms of coordination mechanisms has to be designed in terms of a compound Modify CM able to coordinate and synchronize the single instances of Modify CMs that are activated to manage the related propagation of changes as a consequence of the concurrent proposal of changes presented by the involved Roles. Many solutions are possible to design the functionalities needed for this compound Modify CM. For example, approaches like (Khedro et al. 1994) can be taken as source of inspiration to manage the related complexity and guarantee a higher probability of convergence towards a common solution. These techniques assign a different authority to the various agents and distinguish between hard and soft constraints. Hence, since the hierarchy kit contains tools that are compatible with the above notions, it can support those approaches when constraints are expressed in terms of behavioral properties. First of all, hierarchies naturally contain the notion of different authority in negotiation. The flexibility by which each change hierarchy can be constructed by Modify CM allows each Role responsible for the CM under concern to define, and possibly modify, the CM structure (partial order of negotiations) according to the different hypotheses the selected approach assume to reach a consensus. In addition, the partial order of negotiation define in a natural and dynamical way for a place of negotiation M hard constraints (M - 1 and F (X)) and soft constraints (AE(M)). Secondly, if suitably coordinated, requests coming from different originator Roles can be managed concurrently since the way in which they are expressed (that is, by combinations of local environments as described in Section 3.3.4) allow them to be composed in more demanding requests to be simultaneously satisfied, if possible. Obviously, a more articulated negotiation pattern requires improving the hierarchy kit of each Modify CM and of the compound Modify CM accordingly, especially for what concerns the


76

acceptance criteria of the partial solutions and the composition of different concurrent partial solutions in a consistent way. This is one of the most challenging aspects of a future research on this topic.

3.4 How to integrate in ABACO the Modify CM The previous sections described the Modify CM which supports users in the management of propagation of changes, thanks to the functionalities provided by a hierarchy kit. Here, we want describe how this CM can be integrated in ABACO. This integration effort requires adding new characteristics to ABACO agents: they encompass both local data to keep the results needed during the overall process and behaviors to allow the interaction among the involved agents. Moreover, new functionalities need to be added to Actor’s user interfaces in order to allow the involved users to perform the activities associated with the management of propagation of changes. In the following, we focus on the sequence of information flows among the agents of the Modify CM involved during the management of propagation of changes and their corresponding behaviors according to the exchanged information. Each of the following figures illustrates the current situation of the Modify CM after the exchanged information flows. 1) The event completing the definition of a CM causes the creation of a data structure which contains the information (Petri net) describing the protocol of the related CM: the protocol (called X as in the previous sections) incorporates all the interactions among the involved CAW agents and possibly the causal relations among CAW agents established in the Protocol agent. Then X is sent to the Role responsible for the modification of the CM (Figure 3.4.1) and the Role is enriched with the behaviors needed to manage X during its modification following the patterns illustrated in Chapter 2.

Figure 3.4.1: information flow 1

2) At this point, the Role responsible for a CM is able to propose a modification of its protocol X into X’ through the same functionalities available to define a CM. A hypothetical modification causes the activation of an instance of the Modify CM whose hierarchy Active Artifact immediately receives the new protocol X’.


Using the ability provided by the underlying hierarchy kit, the hierarchy Active Artifact is able to compute the ACQ of the pertinent CM on the basis of X’ and, accordingly, identifies the list of the CMs which can be affected by the proposed change: specifically, the hierarchy Active Artifact identifies the Roles responsible for the modification of the CMs which could be involved in a negotiation for the propagation of the change. In this way, the Roles participating to the Modify CM

CM1 X1

Role1 CMn

Xn

Rolen

Role1

X’

Role2

Rolen hierarchy AA


77

are dynamically identified on the basis of the computed ACQ. At this point, the hierarchy Active Artifact evaluates the impacts of the proposed change on the other protocols. If the change does not affect them, there is no need to negotiate the propagation of changes and the Modify CM can be closed. Then, the proponent Role is in charge to perform the change of X into X’ on the basis of the scripts which are part of its behavior. 3) If the proposed change affects other protocols, the hierarchy Active Artifact asks to the Roles identified in step 2), the pertinent protocol in order to start the construction of the modification hierarchy (Figure 3.4.3). This is done (again, using the capabilities of the hierarchy kit) beginning from the leaves. In addition to the leaf representing the protocol under modification (X’), there are as many leaves as many CMs belonging to the computed ACQ.


4) At this point, the Role proposing the modification is asked by the hierarchy Active Artifact to choose the negotiation strategy (Figure 3.4.4). To this aim, the Role accesses the information contained in the leaves of the hierarchy and groups them according to different priorities. This establishes a partial order of negotiation among the involved Roles which influences the structure of the hierarchy under construction. The CMs belonging to the considered ACQ and whose protocols are not directly affected by the proposed change, are grouped together in the lowest priority group since at this point nothing is known about their role in the negotiation process. 5) Then the hierarchy Active Artifact uses the negotiation strategy to incrementally build the hierarchy by starting from the left and considering the leaves related to protocols belonging to the highest priority group; then it proceeds to the right toward the leaves of protocols included in lower priority groups (Figure 3.4.5). In doing this, the hierarchy Active Artifact creates a new node in the hierarchy (place for negotiation), where the Roles belonging to the group currently under consideration are involved in the negotiation for the propagation of changes. For each protocol affected by the current step of negotiation, the hierarchy Active Artifact computes the information about the corresponding leaf according to previous accepted modifications. Through the hierarchy Active Artifact, this information can be accessed by each negotiating Roles in order to support the definition of the modification of the protocol under its responsibility, since each proposal can take into account the propagation of the initial change which triggered the negotiation process.

Role1

protocol2

Role2

Rolen

hierarchy AA

protocoln

Modify CM

X’ p1 pn


78



6) Once each negotiating Roles has sent to the hierarchy Active Artifact the proposed change, the latter evaluates the received proposals on the basis of the acceptance criteria provided by the hierarchy kit, as described in Section 3.3.6.3. The results of this evaluation influence the associated negotiation process. In fact, the negotiation may stop either because the proposed changes did not fulfill the considered criteria or because the proposed change fulfilled them. In the first case this means that the negotiation about propagation of changes failed and it is not possible to backtrack the negotiation process. In the second case, this means that the initial change proposed by a Role and its propagations are accepted. The involved Roles then receive by the hierarchy Active Artifact the information concerning their protocols to be modified accordingly. At this point each of them is in charge of modifying the agents in the pertinent CM in order to reflect the contents of the received information using the appropriate scripts. If the negotiation did not stop, the hierarchy Active Artifact updates the previously considered nodes according to the results of the last negotiation step. Then, it looks for the group of Roles with the next priority, builds for them a new negotiation node in the hierarchy, and derives the information to be put in this node from the accepted changes

Role1Rolei

Rolej

hierarchy AA

Modify CM

X’ p1 pk

groupA groupZ

group A (highest priority)

Rolek

group Z (lowest priority)

negotiations

information

place for negotiation

proposals

Role1Rolei

Rolej

hierarchy AA

negotiation strategy

Modify CM

X’ p1 pk

groupA groupZ

group A (highest priority)

Rolek

group Z (lowest priority)

pk+1,..,pn

p.a.

Rolek+1 Rolen

potentially affected


79

coming from the left-handed leaves of the hierarchy. This information again can be accessed by each involved Roles in order to define the modification under its responsibility. This iterates the negotiation process until a final success or failure is met. Notice that these iterations might involve Roles belonging to the lowest priority group (i.e., potentially affected by the negotiation): in this case, they will be added in the pertinent group and possibly all the previously considered nodes of the hierarchy (i.e., on the left of the current node) are updated according to the modifications they propose and are accepted. If the negotiation requires backtracking, that is starting again from a node on the left of the current one, all the previously considered nodes on its right are cleared up and the involved Roles are notified of this event. We conclude this chapter by emphasizing again the central role of the hierarchy Active Artifact in the Modify CM, since it constructs the information useful for the involved Roles at the various steps of the negotiation process, performs the related consistency checks and activates the pertinent notifications. However, this support is by no means prescriptive, since the Role proposing the first change and raising the propagation problem can, at any moment, change the negotiation strategy and the related flow of communications: the Active Artifact adapts the hierarchy contents accordingly thanks to the functionalities of the hierarchy kit and the communication capabilities it incorporates.

Chapter 4: Alignment of meanings

80

Chapter 4:

Alignment of meanings Due to the inherently distributed nature of cooperation each involved actor has a local context of work and consequently a partial visibility and partial knowledge about the contexts where the other actors operate. This causes several problems in the course of collaboration according to different aspects which put in evidence an unavoidable tension between locality and the shared understanding on which collaboration relies. This tension can be formulated as the problem of representation, the problem of diverging viewpoints, the problem of the tension between local customization and mutual intelligibility, and the problem of the tension between locality of work contexts and mutual alignment of meanings. In the following we consider these aspects in turn. The problem of representation In his seminal book (Kent 1978) Kent discusses the nature of the process involving human beings in the modeling of data in the design of information systems. He claims that data structures are artificial formalisms, i.e., maps to describe a territory. Any description of the territory a person can give to another is just another map. As a first step people need some language in order to discuss and articulate concepts: constructs as “entities”, “categories”, “names”, “relationships”, and “attributes” are useful since they the constitute a basic “model” people use to organize their perceptions of the reality and discuss about them. When descriptions become the data of an information system they are not used by a single person but become part of a communication process among people as a the basic means of their collaboration. In fact, during communication there are translations along the way, from concept to natural languages to formal languages (representing data) and back again. In this flow the persistence of meaning heavily depends on the participants’ common understanding of the elementary references , that is more easily found if the involved people share a common context that provides the elementary references. The author reports as an example a database concerning parts and warehouses. The same parts and warehouses can be described in two distinct databases with different views: the view in the context of the inventory file and the view in the context of quality control application. If a database integration is needed, the people involved in the integration process need to recognize that there are two different notions of “thing” associated with the concept of “part” and the two views must be reconciled. They will have to work out a “convention” so that the information system is able to deal with two kinds of representations. In other words, there is a semantic problem of data description caused by the intrinsic ambiguity of the words used to describe data. Usually human beings solve this problem in a largely unconscious way, because they understand the context in which the words are being used. But when human actors are distributed they have not a common context acting as a common reference and that ambiguity-solving mechanism is lost. In the same vein other authors (Ventrone et al. 1994) identify the semantic heterogeneity problem in


81

federated databases which are constituted by highly distributed and heterogeneous database components. This problem arises because differences in the meaning of similar data in distinct member components poses a severe obstacle to information integration in the federation precisely because federation has to respect local autonomy. Instead, information integration requires a common reference in order to make different users collaborate through their applications. Single applications, and even groups of applications, are typically built around a common understanding of the data, i.e., a single agreed-upon meaning for each data type and data value across all applications associated to users accessing the data. In federated environment, however, we cannot assume that all users agree on the meanings of the types and values because the components were developed independently. Data semantics can be implicit in the understandings that users (and related application) have about the data that they share. This means that the type definitions in the scheme of the shared databases are mainly specifications of agreements among users about the structure and the representation of the data in terms of entities, their attributes, and the types of the attributes. In this situation, the semantics of types are only partially represented in scheme type definitions (i.e., in the type, attribute and operation names). The rest of the semantic content is represented in the mind of people using the data, in naming conventions, in textual documentation, and in the local “oral tradition”. Relying on implicit agreements about semantics may be adequate in local database environments because related groups of local applications and users work with a shared set of assumptions. However, serious problems are likely to occur in a federated environment because sets of local assumptions clash. In a federation in fact, users of a component do not have access to the semantic assumptions of users of other components because they are not explicit in the information available to the federation. Sometimes, schema type definitions also make some of the semantic agreements explicit, expressed mainly in the names of the types (and the names of their attributes and operations), which convey intuition about the meaning of the type. In this case the difficulty is that different users gathering data from the federation components may have different intuitions about the used names. The problem of diverging viewpoints In their paper (Gerson et al. 1986) Gerson and Star tackle the problem of the definition and management of common representations related to work involving different people: these representations are used as resources devoted to keep together the related different points of view and needs. The authors assume that offices are open systems, hence systems in evolutionary change, where a central authority is lacking, and with perpetual inconsistency among the different knowledge bases related to different work contexts. This means that representations are neither complete nor permanent. Rather, any description is a snapshot of historical processes in which differing viewpoints, local contingencies, and multiple interests have been temporarily reconciled. In order to create adequate representations, office workers must somehow reconcile multiple viewpoints with inconsistent and evolving knowledge bases. In particular, the authors analyze the situation at “Pacific Health Underwrites Company” (PHU) which is a large insurance company that provides health insurance to both individuals and groups. In this company paying health care professionals is an important task for the central office. The company maintains a unit which writes the guidelines that describe all the services provided by professionals, together with the price which PHU pays for each service. For this unit keeping a common representation coding the different diseases along with their procedures associated with the related reimbursement codes does not come


82

without any problem since different groups involved in the process have different viewpoints about how to code medical procedures. The different viewpoints must be reconciled into a single representation, a manual of procedure codes and reimbursement rates. However, creating a common representation will generate problems when the object is used in the local circumstances. Moreover, changes in medical work organization and technology, as well as new insurance products, force continual re-categorization an re-pricing of procedures. Different and mismatching categories require conflicting viewpoints being reconciled in order for the procedure codes to be made uniform. As another situation in which diverging viewpoints can be problematic for cooperation, Star and Griesemer analyze scientific work in (Star et al. 1989), in particular the development of a natural history research museum. According to their investigations, scientific work is heterogeneous, requiring many different actors and consequent distinct viewpoints. It also requires cooperation among these different actors to create common understandings. This creates a ‘central tension’ in science between divergent viewpoints and the need for generalizable findings. In particular the development of natural history research museum is a case in which both heterogeneity and cooperation are central issues for participants. The creation of new scientific knowledge depends on communication as well as on creating new findings. But because these new objects and methods mean different things in different worlds, actors are faced with the task of reconciling these meanings if they wish to cooperate. This reconciliation requires substantial labour on everyone’s part. Scientists and other actors contributing to science translate, negotiate, debate and simplify in order to work together. The problem of the tension between local customization and mutual intelligibility In (Dourish et al. 1999) the authors analyze the connection between customization and collaboration. While customisation comes without problems when performed by a single user in isolation, customisation performed locally by distributed actors involved in collaboration can interfere with collaborative work itself and generates a tension between local customisation and mutual intelligibility. As case study the authors consider a state government organization (The Department) responsible for the overall management of large engineering projects. Projects may take many years, in the course of which they will move through a number of different phases which may be carried out by different groups of people. Coordination between these different groups, and the different individuals in a group, is achieved in part through the maintenance of a large document collection called the project files. The project files are coded according to an organizational filing scheme called the Uniform File System (UFS), and each document is assigned a numeric UFS code, which determines its position in the collection that makes up the project files. Customisation of the UFS allows members to bridge the gulf between the UFS and their immediate needs. However, since the project files are a shared repository, the problem of the tension between customization and mutual intelligibility emerges both at individual and at group level. In the first case, individual approaches to filing may make it difficult for others to retrieve documents if they approach the project files from a different perspective. In the second case, this problem emerges on a larger scale since groups, as well as individuals, can have incompatible views of the document corpus. In this case, since the project files serve not only for local coordination, but also persist across the different groups involved in the lifetime of the project and serve as an archive, the customization of UFS introduces changes not only for the local group but also for other groups who may have to use the


83

project files immediately and in the future. In order to look up documents, or identify the structure of the document corpus, users need to understand the category structure in use and the practices surrounding it. This is a typical problem of mutual intelligibility: if the “language” of the category scheme is subject to local modifications or revisions, it is not clear how communication can take place. More specifically, if someone categorizes documents according to a locally accepted version of the UFS, then the access by someone belonging to another group can be problematic and make it difficult to get the documents she really needs according to her current categorisation scheme. To solve this problems, the authors propose a system able to convert a local customization into another one, passing through the general scheme incorporated in the UFS categorization.

4.1 Alignment of meanings as a form of articulation work The above considerations and the analysis of other situations reported in the literature (Simone et al. 2001) show that the mutual understanding needed to collaborate is the outcome of a specific effort that can be viewed as a special kind of articulation work: we call it alignment of meanings. In particular, we focus on aspects related to the communication devoted to collaboration among the different actors (Mark et al. 2002; Sarini et al. 2002; Simone et al. 1999b) and specifically on the possible misunderstandings that make collaboration more problematic. The kind of misunderstandings may differ according to the considered situation. One kind of misunderstanding concerns the different terminologies related to the professional domains actors are using during their collaboration. Consider for instance two different professionals collaborating to write the requirements of a new software product. The first one has technical skills and often uses technical jargon to refer to some properties of the product, while the second one, having marketing skills, uses a jargon more focused on the usability of the product. Hence, their communication can become ambiguous if the terms they are using are not correctly understood by the collaborating partner. Obviously, this situation can restrain collaboration and make it difficult to reach the common goal. A second kind of misunderstanding is similar to the representation problem discussed above and concerns to the local descriptions associated to the work context of the collaborating partners. In fact, these descriptions can represent in very different ways the common objects which take part in the collaboration. Different descriptions of these common objects are like different “maps” which are drawn using a set of concepts in which different levels of granularity, different names and structures represent each of the different but not irreconcilable local perspectives the distinct organizations have on the same common object. Furthermore, since each local view represents consolidated conventions, each organization wants to maintain it without being enforced to create and use a unique standardized global view. Consider as an example two offices in a University. The first one is the Technical office whose duties concern the technical aspects of personal computers in the laboratories of the University. The second one is the Administration office which has the responsibility of dealing with all the aspects of buying computers, keeping relationships with external companies for maintenance of the computers and so on. When the personnel of the two offices have to collaborate, i.e. for deciding how to the modernize the machines in the laboratories according to both technical and financial aspects, they could have some problems in mutual understanding because different concepts, as personal computer or invoice, are described locally in a different way according to the local office mission. The solution to the problem described above is not “algorithmic”, that is, it is impossible to simply define a sequence of computations which produces the desired results: rather it requires negotiation


84

among the involved actors (Gerson et al. 1986). For this reason we interpret alignment of meanings as a form of articulation work. The idea that this kind articulation work has to be explicitly considered was additionally supported by empirical investigations in the framework of the POLITeam project (Mark et al. 1997; Wulf 1997) that gave us inspiration on a possible way to manage it. This project was sponsored by the German federal ministry in order to define a shared workspace and to design the related technology with the aim of supporting cooperative production and use of documents among different offices. In that experience, the effort to recompose dis-alignments among the different users of the system belonging to different offices was mainly performed during workshops where the involved users, with the help of technologists, discussed the linguistic misunderstandings specifically induced by the introduction of a document management technology supporting their cooperation. Moreover, it was recognized that the outcomes of that re-alignment were not naturally incorporated in this technology, and users were in charge to manage the established clarifications outside the system. From that experience, we derived the idea that the alignment of meanings has to be explicitly supported as part of the system in use. In this view, it can be obtained by the combination of two phases that we distinguished for sake of analysis, although they are mutually interrelated: the first one, called definition phase, where users are active in clarifying the problems and negotiate partial solutions; the second one, called communication phase, where this effort is paid back since the supportive technology alleviates the communication problems using of the collected information. As a technological support for the process of alignment of meanings among the different actors with different work contexts, we implemented a tool, called Reconciler (Simone et al. 1999b). The latter is a technology to let the actors involved in the collaboration interactively solve conflicts related to different descriptions of concepts expressed according to their local points of view. The tool provides users with a uniform language to describe the objects which could be referenced by them during collaboration: we call these descriptions schemes. In order to support the definition phase of alignment of meanings, users are provided with a Reconciler definition interface through which they can cooperatively establish correspondences between the elements of the two different schemes, highlight the various kinds of semantic conflicts arisen as a consequence of the correspondences, and use the functionalities offered by the framework to (partially) solve them. The information produced in the definition phase is then stored by the Reconciler tool in order to provide the needed support among actors during the communication phase. In fact using this information, the Reconciler is able to provide the actors with an elaboration functionality, the Reconciler algorithm, which transforms the elements in the exchanged messages according to the receiver’s point of view, whenever possible. The support provided by the Reconciler in this phase should limit the communication misunderstandings between actors since it elaborates the communication contents created by the sender taking into account the local point of view of the receiver.

4.2 The Reconciler Let us consider here in more details the framework provided by the Reconciler in order to support the alignment of meanings among actors belonging to different work contexts. For what concerns the definition phase we illustrate firstly the language to express the schemes. Secondly, we describe the functionalities provided by the Reconciler definition interface in order to support the negotiation process between the involved users. This means support their collaboration both to establish


85

correspondences among elements of the schemes and to solve the related semantic conflicts. For what concerns the communication phase, we describe the Reconciler algorithm to elaborate messages according to the receiver’s point of view. In the next chapter we will propose different scenarios where the definition and communication phases are put at work to align meanings according to the characteristics of each scenario.

4.2.1 The schemes In order to support users in describing their local contexts of work at a semantic level close to the perceived world, we selected a language to describe the related schemes. This language is derived from the semantic (or conceptual) modeling approach (Loucopoulos et al. 1992)) that uses the notions of entity to express objects of the real world and relationship to express associations among entities (Wand et al. 1999). Among the different semantic models, we chose as a reference for our language the Enhanced ER (EER) model (Chen 1976), (Elmasri et al. 1994)), (Peckham et al. 1988). The language is described in Figures (4.2.1, 4.2.2, 4.2.3) in terms of syntactic diagrams. In particular Figure 4.2.1 illustrates the main elements used to represent an object; they are Entity, Attribute and Rel (relationships), with the description of their associated Cardinalities. In Figure 4.2.2 are described the elements to describe different kind of attributes: Primary keys, Candidate keys and Generic attributes. In the description of attributes, the language distinguishes the Domain type of the attributes among Simple and Compound that are illustrated in Figure 4.2.3. In the first case, the language provides the attributes with three simple Domain types, String, Number, Date, and a Set domain type, which allows the definition of sets of simple types. In the second case, the language allows a recursive definition of compound types, with the structure Attribute(Domain)&Attribute(Domain) where each Domain can be further decomposed in Attribute(Domain)&Attribute(Domain) and so on. Notice that the definition of the domain type of attributes is a way to represent explicitly and uniformly aspects which, although part of the ER model, are not explicitly represented in ER diagrams.

Figure 4.2.1: the grammar associated to the language describing schemes in the Reconciler tool


86



In order to illustrate the usage of the language, we consider an example related to the work of two administration offices of a University. The first one, called Local Office, is concerned with the


87

scheduling of lecture rooms for courses, exam sessions and presentations of degree theses. The second one, called Central Office, is concerned with the preparation of certificates related to the marks of exams and the degree of students. The schemes in Figure 4.2.4 and Figure 4.2.5, expressed in terms of ER diagrams, contain the local descriptions of objects that people working in the two offices have defined.

Final_year_stud

OfficeTel

Address

Figure 4.2.4: local office scheme.

A: Controlled B: Related_to C: Sat_for D: Held E: Attend F: Communicate G: Report H: Discussed I: Exam_Takeplacein J: Course_Takeplacein K: Discussed_in

ACADEMIC_TERM

Sex

Title

Period

C OfficeNum

Ssn

MatrAddr

FirstNameCode

ExamDate

B

A

G

H

E D

FEXAM_SESSION STUDENT PROFESSOR

THESIS COURSE

1 N

M

N N

M

N

1 N

1

N

1

1

N

M

N

LastName

Name

CourseName Program

TermNumber

AcademicYear

Phone_Num

HallAddrHallName Timetable

Floor

LECTURE_HALL

Building

I

J

K

1 1

1 1

1

1

SCHEDULE

Tel


88

In Figure 4.2.4, the area called SCHEDULE highlights concepts used by Local Office’s workers for the organization of the scheduling, while in Figure 4.2.5 the area called CERTIFICATE highlights concepts associated by Central Office’s personnel to the certificate creation. During their collaboration, people of the two different offices need to communicate using concepts related to work activities belonging to the routine work of people of the other group: for instance, when a secretary of the Local Office asks for certificates related to some students (for checking purposes) or a secretary of the Central Office asks for the scheduling related to a professor. Hence, the schemes describing local conventions of work usually include also the boundary objects (Star et al. 1989) used in the communication devoted to collaboration crossing the two offices. Often these objects are described at different abstraction levels and with some degree of imprecision especially if they are not frequently used. Moreover, these descriptions could focus on different aspects according both to their use and the associated activities. In Figures 4.2.6 and 4.2.7 the schemes of the Local Office and Central Office include concepts related to CERTIFICATE and SCHEDULE activities, respectively. For example, in the representations reported in SCHEDULE (Figure 4.2.7), Professor is the name of the professor involved in the activity explained in Description and whose timetable is expressed in Task as a composition of location (where) and date (when). Since this formalization is done from the point of view of the users working for the Central Office, the related concepts can be different in meaning and formulation from the ones used by the people involved in Local Office work. Here is where a reconciliation process can be applied to align the different views among the people of the two different offices which have to collaborate. To this aim the

Figure. 4.2.5: central office scheme.

Sex

OfficeTel

A

OfficeNum

MemNum

Matr

ThesisTitle

Name

Average

BD

C

E FINAL_YEAR_UNDERGRADUATE DEGREE

BOARD SESSION

N 1 N 1

N

1 N

1

N

1

Supervisor

Dep

EXAM

MEMBER

Examiner

Code

Phone_Num

DegreeSession

BoardName

SessionNumber Academic_year

MemberName

Grade

ExamName

Degree_ScoreCERTIFICATE

A: Sat_for B: Held_during C: Composed_by D: Examined_by E: Take Department


89

Reconciler definition interface (see Figure 4.2.8) implements the framework we propose to support the collaborating people belonging to the two different offices in the process of alignment of meanings associated to the different local descriptions.

OfficeTel

Figure 4.2.6: local office scheme (modified to include some CERTIFICATE concepts).

A: Controlled B: Related_to C: Sat_for D: Held E: Attend F: Communicate G: Report H: Discussed I: Exam_Takeplacein J: Course_TakeplaceinK: Discussed_in L: Is_Related_to M: Contains_Score N: Contains_Degree

ACADEMIC_TERM

Sex

Final_year_stud

Title

Period

C

Address

OfficeNum

Ssn

MatrAddr

FirstNameCode

ExamDate

B

A

G

H

E D

FEXAM_SESSION STUDENT PROFESSOR

THESIS COURSE

1 N

M

N N

M

N

1 N

1

N

1

1

N

M

N

LastName

Name

CourseName Program

TermNumber

AcademicYear

Phone_Num

HallAddrTimetable

Floor

LECTURE_HALL

Building

I

J

K

1 1

1 1

1

1

SCHEDULE

ExamCode

CERTIFICATE

L 1

1

Value

SCORE

Rank

DEGREE

Supervisor

M N1

1

1

N

CERTIFICATE

CertName

ExamName DegreeTitle

Tel

HallName


90

4.2.2 The conflicts In this section we present the conflicts, which summarizes incompatibilities between concepts which are part of the descriptions reported in the different local schemes. We express conflicts according to the terminology presented by (Batini et al. 1986; Kahng et al. 1998). In the following, along with the definition of the considered conflicts, we present the related functionalities the Reconciler definition interface provides the involved users with in order to support the negotiation phase related to the alignment of meanings. As a reference case we consider the schemes associated to the two University offices, as described above. Let us start with a general description of

Figure. 4.2.7: central office scheme(modified to include some SCHEDULE concepts).

Sex

OfficeTel

A

OfficeNum

MemNum

Matr

ThesisTitle

Name

Average

BD

C

E FINAL_YEAR_UNDERGRADUATE DEGREE

BOARD SESSION

N 1 N 1

N

1 N

1

N

1

Supervisor

Dep

EXAM

MEMBER

Examiner

Code

Phone_Num

DegreeSession

BoardName

SessionNumber Academic_year

MemberName

Grade

ExamName

Degree_ScoreCERTIFICATE

A: Sat_for B: Held_during C: Composed_by D: Examined_by E: Take F: Exam_Occurs_in G: Is_Scheduled H: Lecture_Occurs _in

Department

Task

Professor

SCHEDULE

Description

SCHEDULE

LECTURE Lecturer

F

G

H

1

1

N 1 1 1

[*]

[*] Similarly to H, F is intended to be of cardinality 1:1 because one specific SCHEDULE instance is associated to one specific EXAM instance and viceversa

Id

CourseName


91

Reconciler definition interface (see Figure 4.2.8). The latter is not focused on functionalities providing the distributed actors with support to co-presence during their collaborative alignment of meanings, rather it realizes a support to keep track of the information generated during the negotiation phase. Hence, this information can be also registered by a single user responsible for this task. Moreover, we do not focus here on an explicit technologic solution supporting actors during their negotiation process. From our point of view, the agreement on the correspondences between elements of the two schemes and the associated conflict resolutions can be the result of any social process (for example meetings), supported or not by a technology, among two or more involved users belonging to the different organizations.

Figure 4.2.8: the Reconciler definition interface The Reconciler definition interface is split in two parts: the first one contains the scheme (let us refer to it as A) of the Local Office and the second one contains the scheme (let us refer to it as B) of the Central Office. This means that the interface offers the shared space where members of the two groups can maintain the results of the reconciliation process supported by the Reconciler. The interface shows, for each scheme, the set of its entities and the attributes related to the selected entity. The relationships among entities can be visualized by clicking on the pop-up menu on the left of the upper-bar. Moreover, the domain type of attributes can be visualized by clicking on the pop-up menu on the right of the upper-bar. Furthermore, for each scheme there are sections devoted to show both the correspondences the users have recognized and the related conflicts. At the beginning these sections are obviously empty. As the use of Reconciler proceeds, they are filled in according to the identified correspondences among concepts in the two schemes.


92

The various types of conflicts

The first kind of correspondences to consider are those related to Terminology (Naming) Conflicts: that is, the identification of homonyms, synonyms and local terms.

1) Homonyms

Def: Homonyms are concepts that in the two schemes have the same name while the users agree that they have different meaning. The system automatically identifies concepts with the same name in the two schemes (note that it is not possible to have concepts with the same name in a single scheme) and considers them, by default, as equivalent (that is, also with the same meaning). These equivalences are not explicitly represented in the interface. Consider for instance the following table containing homonymous attributes : ENTITY of A Attribute ENTITY of B Attribute EXAM_SESSION Code EXAM Code PROFESSOR Phone_Num FINAL_YEAR_UNDERGRADUATE Phone_Num Table 4.2.1

In the first case the users agree that the two attributes refer to the same concept (hence are equivalent) while in the second case that the two attributes refer to different concepts (i.e., they have different meanings hence are homonyms). The Reconciler allows to express this fact by allowing the users to define new names (see Figure 4.2.9) for the homonymous attributes (even if these names are shown only on users’ request when this can help them in recalling the homonymy). In other words, the users will use their local names in communication; the related interpretation is done automatically by the Reconciler. Consider the following table reporting the equivalences of concepts (agreed upon by the users) that could be used during communication concerning a collaboration involving CERTIFICATE activities. ENTITY of A Attribute ENTITY of B Attribute SCORE ExamName (String) EXAM ExamName (String) DEGREE DEGREE DEGREE Supervisor (String) FINAL_YEAR_UNDERGRADUATE Supervisor (Compound) Table 4.2.2

The following table shows instead pairs of homonyms that are managed as illustrated in Figure 4.2.9. ENTITY of A Attribute ENTITY of B Attribute PROFESSOR Name (Set of String) FINAL_YEAR_UNDERGRADUATE Name(Compound)PROFESSOR SCHEDULE Professor (String) Table 4.2.3


93

Figure 4.2.9: an example of homonym resolution

2) Synonyms and local terms

Def: Synonyms are concepts with different names in the two different schemes while the users agree that they have the same meaning. All the concepts not involved in synonym correspondences and equivalences are supposed to be local terms, at least until a message involving them is misunderstood and a new reconciliation phase about these concepts is started. The users have now to establish correspondences to define synonyms in the two schemes. Obviously they cannot be proposed by the Reconciler. The following table shows the correspondences the users have established for dealing with communication about collaboration involving CERTIFICATE activities: ENTITY of A Attribute ENTITY of B Attribute SCORE ExamCode (String) EXAM Code (String) SCORE Value (Number) EXAM Grade (Number) STUDENT FINAL_YEAR_UNDER

GRADUATE

DEGREE DegreeTitle (String) FINAL_YEAR_UNDERGRADUATE

ThesisTitle (String)

DEGREE Rank (Number) DEGREE Degree_Score (String) Table 4.2.4


94

Similarly, Table 4.2.5 shows the correspondences that could be useful for dealing with communication about collaboration on SCHEDULE activities: ENTITY of A Attribute ENTITY of B Attribute PROFESSOR Name (set of String) SCHEDULE Professor (String) LECTURE_HALL SCHEDULE Task (compound) LECTURE_HALL Timetable (compound) SCHEDULE Description (String) Table 4.2.5

Figure 4.2.10: an example of synonymous correspondences

Hence, the Reconciler interface allows users to express these correspondences among synonymous concepts (see Figure 4.2.10). In this case, the figure represents PROFESSOR.Name which is synonym of SCHEDULE.Professor. This correspondence is established by clicking on the button 'Add Synonym'. The correspondences among concepts the users establish to solve Terminology conflicts or the equivalences may create other kinds of conflicts according to the nature of the involved constructs: Category Conflicts, Structural Conflicts (Type and Dependency), Unit Conflicts (Measurement’s Unit and Compound Domain).

3) Category

Def: Synonym correspondences or equivalence among entities and their attributes can generate different degrees of mutual overlapping (category relations). The various situations: sub-entities, super-entities, overlapping entities, disjoint entities are characterized as follows, respectively:


95

synonymous/equivalent attributes of one entity are included in the set of attributes of the corresponding one; or vice-versa include; or partly correspond to; or finally are disjoint from the synonyms/equivalent attributes of the corresponding entity. These category relations have associated a priority which is defined as follows (from the highest to the lowest one): super-entities, sub-entities, overlapping entities and disjoint entities. These priorities are used by the reconciler algorithm (see next section). The system automatically suggests the entities that could be in conflict showing for each of them the list of corresponding attributes. It is left to users the marking of the conflicts. This marking is then used by the algorithm to solve ambiguities when the same entity is involved in more than one synonym correspondence or equivalence. Furthermore for sake of awareness and to improve the performance of the algorithm, the Reconciler offers the possibility of making visible in a scheme attributes of the other scheme which have no correspondences. In Table 4.2.4 STUDENT in A and FINAL_YEAR_UNDERGRADUATE in B are synonyms. In Figure 4.2.11 STUDENT in A and FINAL_YEAR_UNDERGRADUATE in B are visualized as overlapping entities. The users decide to make Average of FINAL_YEAR_UNDERGRADUATE visible as an additional attribute of STUDENT in A, by using the pertinent dialog box.

Figure 4.2.11: an example of Category conflict resolution.

4) Type

Def: Type conflict is a consequence of a synonym correspondence or an equivalence between an entity in one scheme and an attribute in the other one.


96

The system automatically recognizes this conflict and proposes a solution which modifies the scheme containing the conflicting attribute by transforming the latter in an entity. In this way the Type conflict is transformed into Synonym conflict (or equivalence) among entities. If the solution is not accepted by the users then the correspondence between the involved entity and attribute is discarded. Consider LECTURE_HALL in A and SCHEDULE.Task in B in Table 4.2.5: they are synonyms, and hence are in Type conflict. Figure 4.2.12 shows the portion of the scheme B modified after the conflict resolution where the domain of Info-Task is the same as the domain previously associated to Task.

The next table shows the new correspondences after the conflict resolution ENTITY of A Attribute ENTITY of B Attribute PROFESSOR Name (set of String) SCHEDULE Professor (String) LECTURE_HALL Task LECTURE_HALL Timetable (compound) SCHEDULE Description (String) Table 4.2.6 In Figure 4.2.13 is reported the Reconciler definition interface after the conflict resolution.

5) Dependency

Def: Dependency conflict refers to relations which are comparable but have different cardinality. Two relations are defined comparable if they are marked as equivalent by the users and all the corresponding entities are equivalent or synonym. The system automatically looks for relations which have different cardinality and the corresponding entities are equivalent or synonym, that might turn into conflict. It is left to users the marking of these relations as equivalent. The system then automatically recognizes Dependency conflicts. The Reconciler makes available to the users a set of heuristics applicable to the attributes of the involved entities to align the different cardinalities, in order to solve the conflict. The conflict resolution is then used by the algorithm.

Figure 4.2.12: the part of central office scheme modified after type conflict resolution

Info-Task

Id

Professor

SCHEDULE

Description

Task

SCHEDULE Task

1 N


97

Figure 4.2.13: an example after Type conflict resolution.

Consider as an example for Dependency conflict in Figure 4.2.6 the relation Sat_for of cardinality M:N among STUDENT and EXAM_SESSION. In Figure 4.2.7, instead, is reported the relation Sat_for1 of cardinality 1:N among FINAL_YEAR_UNDERGRADUATE and EXAM. These relations are marked as equivalent by the users in the case they represent the same concept. While STUDENT is synonym of FINAL_YEAR_UNDERGRADUATE, no synonym correspondence was established among EXAM_SESSION and EXAM. The latter have to be in synonym correspondence for the relations to be comparable. Suppose the users defines a synonym correspondence between EXAM_SESSION and EXAM. Figure 4.2.14 shows the Reconciler definition interface related to Dependency conflict resolution where the areas devoted to attribute and related conflicts presentation are replaced with the ones to show relations. The box bottom right dialog of Figure 4.2.14 shows the set of available heuristics the users can choose in trying to make equal the two cardinalities.

6) Unit

Def: this conflict arises when synonymous/equivalent attributes have associated different domain types. The language to express schemes contains three simple domain types, String, Number, Date; a Set domain type, which allows the definition of sets of simple types and a Compound domain type. At the moment a limited support is provided for conflict solution techniques in the case of Compound domains since the solution involves only the couple of outermost attributes and in 1 notice that Reconciler, differently from entities and attributes, does not consider by default as equivalent relations with the same name.


98

addition the their names must correspond to the names of attributes with simple or set domains in the other scheme. The system automatically suggests the attributes that are in Unit conflict. The Reconciler then makes available to the users a set of functions to define a mapping among the values belonging to different domain types, if possible. The Reconciler is designed in a way that makes it open to add new functions, whenever the users agree on functions that are missing and could be used to solve the conflicts related to the domains under concern. The chosen functions are then used by the algorithm during the communication phase when the messages contain references to attribute values.

Figure 4.2.14: an example of Dependency conflict resolution In this case the latter are transformed according to the application of the function established by the involved users. Table 4.2.4 shows a case of Unit conflict involving DEGREE.Rank in A whose domain type is Number and DEGREE.Degree_Score in B whose domain type is String. Figure 4.2.15 shows the Unit conflict resolution for this case where the users chose Function2 which casts Number values to String values, and Function3, the inverse function of Function2, casting instead String values to Number values.


99

Figure 4.2.15: an example of Unit conflict resolution

To conclude this section, the following table summarizes the above described conflicts: an X in a cell indicates which elements of the schemes can be involved in the conflicts listed in the first column.

Conflicts Entities Attributes Relationships

Naming

Homonyms X X X

Synonyms X X X

Category X

Structural

Type X ← →X

Dependency X

Unit

Measurement X

Compounds X(*) Table 4.2.7: table summarizing the kind of conflicts considered. Notice that (*) refers to Compound Domain Attributes only and that Type conflicts involve elements of different type.


100

4.2.3 The Algorithm The information gathered during the definition phase is used by the Reconciler during the communication phase in order to elaborate the exchanged messages according an algorithm that is described here below. The algorithm is composed of three sequential steps (see Figure 4.2.16). When an actor sends a message built using her communication interface, the message content is parsed in order to identify the concepts used by the sender and belonging to the sender scheme (sender scheme). According to the structure of the message, the recognized concepts are grouped into entities (ENT1), attributes (ATTR1), and conditions expressed both in terms of predicates (PRE1) and of relationships (JOIN1). Then the orginal message together with the concepts grouped according to their type is passed to the Reconciler algorithm. Step 1) At this point the algorithm performs a sequence of sub-steps to update the above groupings in order to keep trace of the transformations of the sender scheme according to the resolution of Type conflicts (modified sender scheme). Step 2) Then the algorithm searches for the correspondences involving the elements inside every single group, by using the information established in the previous reconciliation process (see the middle part of Figure 4.2.16). The algorithm is driven by entities because people mainly use them to describe concepts. For every entity there are three possible situations: there are no correspondences in the other scheme (zero correspondence), there is exactly one correspondence in the other scheme (one-to-one correspondence), there is more than one correspondence in the other scheme (one-to-many correspondences). In the first case the algorithm does not propose any solution. For the one-to-one correspondence the entity is associated with the corresponding one of the other scheme. For the third case the algorithm uses a set of heuristics based on the resolution of the conflicts proposed during the reconciliation process. The aim of these heuristics is to choose, if possible, an entity of the other scheme maximizing the similarity with the current one. At this point, the same search for correspondences is made for the other elements. The heuristics for the solution of the ambiguities related to one-to-many correspondences between attributes and relations are based on the previously selected correspondences between entities and on how the current elements are linked to the latter. Furthermore for what concerns predicate conditions, the algorithm elaborates the values of the attributes expressed in the conditions according to the solution of Unit conflicts provided by the users during the reconciliation process. The algorithm associates the concepts recognized during the first step with the corresponding concepts found in this second step. Notice that not for all concepts an association can be found : this happens for zero correspondence and for one-to-many correspondences when the heuristics are not able to select a unique correspondence. In these cases the sender and the receiver will be notified of the possible sources of misinterpretation due to unsolved ambiguities (that is, there is no one-to-one correspondences). In this case, they will interact with the Reconciler in order to try to overcome them.


101

Figure 4.2.16: the transformation of the message according to the algorithm

Step 3) The last step is devoted to transform all the found associations expressed as elements of the modified scheme of the receiver (modified receiver scheme) in terms of the original receiver scheme (receiver scheme) taking into account its modifications which are consequence of the Type conflict resolution. In this way, the algorithm produces the transformed concepts grouped into entities (ENT2), entities with zero correspondences (ENT_G or ENT_R for entities with homonymous correspondences or not, respectively), attributes (ATTR2), attributes with zero correspondences (ATTR_G or ATTR _R for attributes with homonyms or not, respectively), predicates (PRE2), and join relations (JOIN2). These grouped concepts are then passed together with the original message to the communication interface of the receiver. Then the interface recomposes the message presenting the concepts contained in the sender message according to the receiver point of view (see Figure 4.2.16). The above descriptions are refined here below with reference to the pseudo-code listed in the following boxes. Step 1 is composed of a sequence of sub-steps (see Figure 4.2.17):

• Entity Transfer (see lines 1-2, Box 4.2.1), • Attribute Transfer (see lines 3-14, Box 4.2.1), • Predicate Transfer (see lines 15-26, Box 4.2.1), and • Join Relation Transfer (see 27-31, Box 4.2.1)

ENT1, ATTR1, PRE1, JOIN1 expressed according to the

sender Scheme

ENT2, ATTR2, PRE2, JOIN2 expressed according to the

receiver Scheme, ENT_R, ENT_G, ATTR_R, ATTR_G

ENT1’, ATTR1’, PRE1’, JOIN1’ expressed according to the

modified sender Scheme

message

Step 3

Step 2

transformed message

Step 1

Sender Receiver

Stored information of Reconciliation

+ Sender and receiver

schemes

ENT2’, ATTR2’, PRE2’, JOIN2’ expressed according to the modified receiver Scheme

parsing of the message

recomposition of the message

communication interface communication interface


102

which concern the transformation of the elements of the group of entities, attributes, predicates, and join relations, respectively according to the resolution of Type conflicts, that is considering the attributes in the sender scheme which were transformed into entities. The new detected elements are now grouped into entities (ENT1’), attributes (ATTR1’), predicates (PRE1’) and join (JOIN1’) sets. When transferring attributes and predicates (see lines 11-14, 23-26 in Box 4.2.1), the algorithm puts in ENT1’ also the entities which own the considered attributes, if not already present, in order to give the contextual information needed to perform the related computations. Moreover, in JOIN1’ are also created new join conditions concerning the new relationships among the original entity containing the attribute and the new entity defined in the scheme after the Type conflict resolution (see lines 29-31, Box 4.2.1). Now the algorithm can perform the elaborations related to Step 2 by considering these new sets. According to sequence reported Figure 4.2.17, Step2 is divided into different subsequent computations devoted to find the correspondences by considering the pertinent sets:

• Attribute Pick up (see lines 1-15, Box 4.2.2.a), • Entity Correspondences (see lines 16-35, Box 4.2.2.a), • Attribute Correspondences (see lines 36- 67, Box 4.2.2.b), • Join Relation Building (see lines 68-108, Box 4.2.2.c), • Attribute Insertion (see lines 109-111, Box 4.2.2.d), and • Predicate Insertion (see lines 112-115, Box 4.2.2.d)

Attribute pick up refers to the picking of all the attributes from the related sets and their grouping according to the entities they belong to (that is in the set ATTRi1’ for the attributes belonging to entity enti). Since entities are the most relevant concepts expressed in a message and the search for the correspondences of the other kinds of concepts are based on them, the computation Entities Correspondences is one of the most important parts of the algorithm: it finds the correspondences in the modified receiver scheme for the entities in ENT1’. In addition, this computation puts in the set CORR the correspondences found between entities. In this way CORR is built during the computation of the algorithm to keep the detected correspondences between elements of the different schemes explicitly used in the exchanged message. CORR is a subset of all the correspondences established by users during the definition phase dynamically built in order to take into account also the capabilities of the algorithm to solve the detected ambiguities. For each entity in ENT1’ the algorithm searches for the correspondences defined in the definition phase and according to this information, puts in ENT_G (or ENT_R) the entity of ENT1’ if it has no correspondences, into ENT2’ the corresponding entity if there is exactly one correspondence. If the entity has many correspondences, the algorithms calls a module to identify the most suitable correspondence. This module incorporates different strategies in order to solve ambiguities related to one-to-many correspondences. First, it collects in ENTx all the entities which are in correspondence with the considered entity in ENT1’ (let us call it enti). If an entity equivalent to enti exists in ENTx then the algorithm chooses it (lines 2-5, Box 4.2.3.a). In the opposite case, the algorithm applies three different strategies. The first one is based on the use of information related to the relations among the involved entities. The second one uses the information about the attributes belonging to the involved entities, and the last one uses information related to the possible solution of Category conflicts among the involved entities.


103

In the first strategy the algorithm searches for all the join relations in JOIN1’ involving the entity enti. Among them it selects the join relations whose entities are involved in a relation of the sender scheme. Then, for each one of them it considers the two sets of entities in the receiver scheme that correspond to the entities involved in the considered relation. Next, it looks for all the relations in the receiver scheme that involve elements of the two sets and are synonymous of the currently considered relation in the sender scheme, and finally collects in REL_CORRjr the above identified pairs of synonymous relations (see lines 6-23, Box 4.2.3.a). At this point the algorithm selects the entity entxj as the correspondent entity for enti if the following conditions hold (see Figure 4.2.18): there is only a pair of synonymous relations in REL_CORRjr, (relation1 and relation2) and either the entity entr does not have any equivalent entities in the receiver scheme or, if there is the case, the equivalent entity is equal to enty (that is involved in the relation2 synonymous of relation1) (see lines 24-43, Box 4.2.3.b). If the above conditions are not satisfied, the algorithm applies the second strategy by considering only to the entities of the receiver scheme belonging to the set ENTx that are involved in the relations collected in REL_CORRjr (see lines 44-49, Box 4.2.3.b).

Figure 4.2.18: the first strategy

The second strategy looks in ENTx for the entity with the greatest number of attributes in correspondence with the entity under concerns (enti). To do this the algorithm builds for each entxj in ENTx the set COMMON_ATTRj considering each occurrence of the attributes in ATTR_ENTxj which are in correspondence with the ones belonging to enti (see line 53, Box 4.2.3.c), where ATTR_ENTxj contains all the attributes belonging to the entity entxj (in ENTx) currently under consideration. At this point the algorithm chooses as correspondence for enti the entity entxj whose set COMMON_ATTRj has the greatest cardinality. . If there are more than one of such entities (see at line 70, Box 4.2.3.d the check on numberOfEntities), the algorithm needs to apply the third strategy. The algorithm considers only the entities whose set COMMON_ATTRj has the greatest cardinality (at line 75, Box 4.2.3.d maxCar checks the cardinality of these sets) and sorts them according to the priority of category relation with enti. (see lines 76-104, Box 4.2.3.d). At this point, the strategy looks for a correspondence for enti by considering first the set with the highest priority (see lines 105-117, Box 4.2.3.e). If this set (called ENTITIES) contains only one entity, the latter is the solution (see lines 118-119, Box 4.2.3.e); otherwise the algorithm is not able to make a choice and involves the receiver to solve, if possible, the ambiguities (see lines 120-124, Box 4.2.3.e). If ENTITIES contains more that one element (see lines 120-121, Box 4.2.3.e), the receiver can solve the ambiguities on the basis of the elements contained in the set ENTITIES, which is a subset of ENTx. If ENTITIES is empty (see lines 122-123, Box 4.2.3.e) the receiver can use the whole set ENTx. Hence, even in situation where the algorithm is not able to completely solve the ambiguities, nevertheless it can help users in reducing, where possible, the degree of choices to manage the

enti

entr

relation1

ENTy

entxj

enty

relation2

ent_equiv


104

detected ambiguities. Attribute correspondences are looked for in a similar way (see Box 4.2.2.b). If in the message an attribute is mentioned without the related entity, the latter is added to the set of entities to be considered and its possible correspondences with the entities of the receiver scheme are used to look for the solution. In the Join Relation Building substep, the algorithm builds the join relations to be added to JOIN2’ starting from the ones contained in JOIN1’. During this construction, the algorithm makes a distinction if the entities participating to the join under consideration are involved or not in relations expressed in the modified sender scheme. If the considered entities are not involved in a relation, (see lines 75-76, Box 4.2.2.c), a new join relation involving the corresponding entities is added to JOIN2’. In the other case, the algorithm gets from the modified sender scheme the relation (relation1) which corresponds to the join relation under concerns (see lines 78-82, Box 4.2.2.c). In order, the algorithm searches in the modified receiver scheme the relations (relation2) that are synonymous to relation1 , to create the join relation in JOIN2’. If only one relation is found, then the algorithm defines the new join relation taking it into account (see lines 89-93 and 98-102, Box 4.2.2.c). Otherwise the new join relation is created in the same way as in the first case (see lines 85-86 and 107-108, Box 4.2.2.c). When relation1 and relation2 are synonymous and also in Dependency conflict (see lines 90-92 and 99-101, Box 4.2.2.c), the algorithm uses the criterion established to solve the Dependency conflict between the two considered relations as a new condition for the join relation being added to JOIN2’. For what concerns Attribute and Predicates insertion (see lines 109-111 and 112-115, Box 4.2.2.d), the algorithm gets the correspondences established during Attribute Correspondence substep from the set CORR, considering the set ATTR1’ of all the attributes involved in the message. Then the algorithm puts the attributes belonging to the receiver modified scheme retrieved from CORR in ATTR2’ and PRE2’, respectively. Notice that predicates are transformed by the algorithm in this way: firstly, the attributes involved in the predicate are transformed according to the correspondence stored in CORR. Then the values associated to the predicate described in the sender message are transformed into the values considering the receiver’s point of view according to the strategies of Unit conflict resolution defined by the involved users in the previous negotiation phase (see line 114, Box 4.2.2.d). Step 3 is the symmetric of Step1: it has the duty to transform elements expressed in terms of the modified receiver scheme into elements of the receiver scheme (according to the Type conflict resolution which in this case is applied backward). Similarly, it is composed of a sequence of sub-steps (see Figure 4.2.17):

• Entity Transfer (lines 1-7, Box 4.2.4.a) • Attribute Transfer (lines 8-15, Box 4.2.4.a) • Predicate Transfer (lines 16-23, Box 4.2.4.a) • Join Relation Transfer (Box 4.2.4.b)

This concludes the description of the Reconciler tool. In the following section we present several approaches proposed in different research areas. These approaches share the goal to provide users with a support to manage the problems which arise in collaboration as a consequence of the


105

unavoidable tension between locality and the shared understanding on which collaboration relies.

STEP 2 ATTRIBUTE PICK UP

ENTITY CORRESPONDENCE

ATTRIBUTE CORRESPONDENCE

JOIN RELATION BUILDING

ATTRIBUTE INSERTION

PREDICATE INSERTION

STEP1 ENTITY TRANSFER

ATTRIBUTE TRANSFER

PREDICATE TRANSFER

JOIN RELATION TRANSFER

STEP 3

JOIN RELATION TRANSFER

ENTITY TRANSFER

ATTRIBUTE TRANSFER

PREDICATE TRANSFER

Figure 4.2.17: the structure of the algorithm according to its subsequent steps


106

1 ∀ ent ∈ ENT1

2 ENT1’ = ENT1’ ∪ {ent};

3 ∀ attr ∈ ATTR1

4 if (attr has Type Conflict) {

5 ent_attr = get Entity from Attribute attr;

6 info_attr = get Attribute from Entity ent_attr;

7 ENT1’ = ENT1’ ∪ {ent_attr};

8 ATTR1’ = ATTR1’ ∪ {info_attr};

9 } else {

10 ATTR1’ = ATTR1’ ∪ {attr};

11 entx = get Entity from Attribute attr;

12 if (entx∉ENT1’)

13 ENT1’ = ENT1’ ∪ {entx};

14 }

15 ∀ pr(attr) ∈ PRE1

16 if (attr has Type Conflict) {

17 ent_ attr = get Entity from Attribute attr;

18 info_attr = get Attribute from Entity ent_attr;

19 ENT1’ = ENT1’ ∪ {ent_attr};

20 PRE1’ = PRE1’ ∪ {pr(info_attr)};

21 } else {

22 PRE1’ = PRE1’ ∪ {pr(attr))};

23 entx = get Entity from Attribute attr;

24 if (entx∉ENT1’)

25 ENT1’ = ENT1’ ∪ {entx};

26 }

27 ∀ join ∈ JOIN1

28 JOIN1’ = JOIN1’ ∪ {join};

29 ∀ entA ∈ ENT1’ s.t. entA ∉ ENT1 and ∀ entB ∈ ENT1’ s.t. entA ≠ entB

30 if (entA is in Relation with entB)

31 JOIN1’ = JOIN1’ ∪ {entA<J>entB};

Box 4.2.1: the first step


107

1 ∀ enti ∈ ENT1’, i=1..card(ENT1’)

2 ∀ attr ∈ ATTR1’

3 if (attr ∈ enti)

4 ATTRi1’ = ATTRi1’ ∪ {attr};

5 ∀ pr(attr) ∈ PRE1’

6 if (attr ∈ enti)

7 ATTRi1’ = ATTRi1’ ∪ {attr};

8 ∀ join ∈ JOIN1’

9 if (join has Condition) {

10 (attr1, attr2) = get Attributes of Condition from join

11 if (attr1 ∈ enti)

12 ATTRi1’ = ATTRi1’ ∪ {attr1};

13 if (attr2 ∈ enti)

14 ATTRi1’ = ATTRi1’ ∪ {attr2};

15 }

16 ∀ enti ∈ ENT1’, i=1..card(ENT1’)

17 numbOfCorri = get number of correspondences for enti;

18 if (numbOfCorri == 0) {

19 if (enti has Homonym) {

20 Notify user about zero correspondences for enti;

21 entx = get Homonym for enti;

22 ENT_G = ENT_G ∪ {entx};

23 } else {

24 Notify user about zero correspondences for enti;

25 ENT_R = ENT_R ∪ {enti};

26 }

27 } else if (numbOfCorri == 1) {

28 entx = get correspondence for enti;

29 ENT2’ = ENT2’ ∪ {entx};

30 CORR = CORR ∪ {(enti, entx)};

31 } else if (numbOfCorri > 1) {

32 entx = get one correspondence for enti from many;

33 ENT2’ = ENT2’ ∪ {entx};

34 CORR = CORR ∪ {(enti, entx)};

35 }

Box 4.2.2.a the second step


108

36 ∀ i=1..card(ENT1’) {

37 ∀ attrs ∈ ATTRi1'

38 numbOfCorrs = get number of correspondences for attrS;

39 if (numbOfCorrs == 0) {

40 if (attrS has Homonym) {

41 Notify user about zero correspondences for attrs ;

42 attrx = get Homonym for attrs;

43 ATTR_G = ATTR_G ∪ {attrx};

44 } else {

45 Notify user about zero correspondences for attrs;

46 ATTR_R = ATTR_R ∪ {attrs};

47 }

48 } else if (numbOfCorrs == 1) {

49 attrx = get correspondence for attrs;

50 CORR = CORR ∪ {(attrs, attrx)};

51 enty = get the Entity of attrx;

52 if (enty∉ENT2’) {

53 Notify user about inserting enty in the transformation process;

54 ENT2’ = ENT2’ ∪ {enty};

55 JOIN2’ = JOIN2’ ∪ {(entx<J>enty)};

56 }

57 } else if (numbOfCorrs > 1) {

58 attrx = get one correspondence for attrs from many;

59 CORR = CORR ∪ {(attrs, attrx)};

60 enty = get the Entity of attrx;

61 if (enty∉ENT2’) {

62 Notify user about inserting enty in the transformation process;

63 ENT2’ = ENT2’ ∪ {enty};

64 JOIN2’ = JOIN2’ ∪ {(entx<J>enty)};

65 }

66 }

67 }

Box 4.2.2.b the second step


109


69 enti = get first Entity of join;

70 entj = get second Entity of join;

71 condition = get Condition of join;

72 newCond = create new Condition from condition;

73 entx = get correspondence for enti;

74 enty = get correspondence for entj;

75 if (enti is not in Relation with entj)

76 JOIN2’ = JOIN2’ ∪ {(entx <J> enty, newCond)};

77 else{

78 if (join has name){

79 name = get name of join;

80 relation1 = get Relation named name between enti and entj;

81 } else

82 relation1 = get Relation between enti and entj;

83 found = false;

84 REL2 = get all Relations between entx and enty;

85 if (card(REL2) == 0)

86 JOIN2’ = JOIN2’ ∪ {(entx <J> enty, newCond)};

87 else if (card(REL2) == 1){

88 relation2 =get one Relation from REL2;

89 if (relation1 is Synonym of relation2){

90 if (relation1 is in Dependency Conflict with relation2)

91 JOIN2’ = JOIN2’ ∪ {(entx <J[get name of relation2]> enty, get

92 else solution criterion for DC between relation1 and relation2)};

93 JOIN2’ = JOIN2’ ∪{(entx <J[get name of relation2]> enty,newCond)};

94 found = true;

95 }

96 } else if (card(REL2) > 1){

97 ∀ relation2 ∈ REL2 and ¬found {

98 if (relation1 is Synonym of relation2) {

99 if (relation1 is in Dependency Conflict with relation2)

100 JOIN2’ = JOIN2’ ∪ {(entx <J[get name of relation2]> enty, get

101 else solution criterion for DC between relation1 and relation2)};

102 JOIN2’ = JOIN2’ ∪{(entx <J[get name of relation2]> enty,newCond)};

103 found = true;

104 } 105 } 106 } 107 if (¬found) 108 JOIN2’ = JOIN2’ ∪ {(entx <J> enty, newCond)};}

Box 4.2.2.c the second step


110


110 attrx = get correspondence for attr;

111 ATTR2’ = ATTR2’ ∪ {attrx};


113 attrx = get correspondence for attr;

114 pr’(attrx) = get Predicate applying function chosen to solve Unit

Conflicts on pr(attr);

115 PRE2’ = PRE2’ ∪ {pr’(attrx)};

Box 4.2.2.d the second step

1 ENTx = get all correspondences of enti;

2 ∀ entxj ∈ ENTx, j=1..card(ENTx){

3 if (enti is equivalent to entxj))

4 return(entxj);

5 }

6 JOIN = get from JOIN1’ all join relations related to enti;

7 ∀ joinr ∈ JOIN, r = 1..card(JOIN) {

8 entr = get from Join Relation joinr the Entity in relation with enti;

9 if (enti is in Relation with entr){

10 relation1= get Relation between enti and entr;

11 ENTyr = get all correspondences of entr;


13 ∀ entyr ∈ ENTyr{

14 if (entxj is in Relation with entyr){

15 REL2 = get all Relations between entxj and entyr;

16 ∀ relation2 ∈ REL2

17 if (relation1 is Synonym of relation2)

18 REL_CORRjr = REL_CORRjr ∪ {(relation1, relation2)};

19 }

20 }

21 }

22 }

23 }

Box 4.2.3.a get one correspondence for enti from many


111

24 if (∃ (j, r) j=1..card(ENTx) and r=1..card(ENTyr)] s.t. REL_CORRjr ≠ ∅ {

25 if (∃! (j, r) s.t. card(REL_CORRjr) == 1) ∧ (¬∃(j, r) s.t.

card(REL_CORRjr) ≠ 0) {

26 (relation1, relation2) = get one couple of relations from REL_CORRjr;

27 entr = get from Relation relation1 the Entity in Relation with enti;

28 ENTy = get all correspondences of entr;

29 equiv = false;

30 ∀ enty ∈ ENTy and (¬equiv){

31 if (entr is equivalent to enty){

32 equiv = true;

33 ent_equivalent = enty;

34 }

35 }

36 entxj = get correspondence of enti in Relation relation2;

37 enty = get correspondence of entr in Relation relation2;

38 if (¬equiv) ∨ (ent_equivalent ≡ enty){

39 if (relation1 is in Dependency conflict with relation2)

40 JOIN2’ = JOIN2’ ∪ {(entxj <J> enty , get solution criterion for

DC between relation1 and relation2)};

41 else

42 JOIN2’ = JOIN2’ ∪ {(entxj <J> enty)};

43 return(entxj);

44 }

45 } else{

46 ENTx = ∅;

47 ∀ REL_CORRjr

48 ENTx = ENTx ∪ get from REL_CORRjr all Entities in correspondences

with enti;

49 }

50 }

Box 4.2.3.b get one correspondence for enti from many


112


52 ATTR_ENTxj = get all Attributes of entxj;

53 COMMON_ATTRj = get from ATTR_ENTxj all Attributes in correspondence with

the ones beloning to enti; 54 }

55 maxCard = 0;

56 numberOfEntities = 0;

57 index = 0; 58 cardinality = 0;

59 ∀ j=1..card(ENTx){

60 cardinality = card(COMMON_ATTRj);

61 if (cardinality > maxCard) {

62 maxCard = cardinality;

63 numberOfEntities = 1;

64 index = j;

65 } else if (cardinality == maxCard)

66 numberOfEntities++;

67 }

Box 4.2.3.c get one correspondence for enti from many


113

68 if (numberOfEntities == 1)

69 return(entx, index);

70 else (numberOfEntities > 1){

71 maxclass = ord(NO RESOLUTION of CATEGORY CONFLICT);

72 maxclassnum = 0;

73 ∀ entxj ∈ ENTx, j=1..card(ENTx) {

74 cardinality = card(COMMON_ATTRj);

75 if (cardinality == maxCard) {

76 if (enti is super entity of entxj) {

77 SUPERENTx= SUPERENTx ∪ {entxj};

78 maxclass = ord(SUP);

79 maxclassnum++;

80 } else if (enti is sub entity of entxj) {

81 if (maxclass >= ord(SUB)) {

82 SUBENTx= SUBENTx ∪ {entxj};

83 maxclass = ord(SUB);

84 maxclassnum++;

85 }

86 } else if (enti overlaps with entxj) {

87 if (maxclass >= ord(OVE)) {

88 OVEENTx= OVEENTx ∪ {entxj};

89 maxclass = ord(OVE);

90 maxclassnum++;

91 }

92 } else if (enti is disjointed from entxj) {

93 if (maxclass >= ord(DIS)) {

94 DISENTx= DISENTx ∪ {entxj};

95 maxclass = ord(DIS);

96 maxclassnum++;

97 }

98 } else if (maxclass >= ord(NO RESOLUTION of CATEGORY CONFLICT)){

99 NORESENTx= NORESENTx ∪ {entxj};

100 maxclass = ord(NO RESOLUTION of CATEGORY CONFLICT);

101 maxclassnum++;

102 }

103 }

104}

Box 4.2.3.d get one correspondence for enti from many


114

105 case (maxclass){

106 ord(SUP): ∀ entxj∈ SUPERENTx, j=1..card(SUPERENTx)

107 ENTITIES = ENTITIES ∪ {entxj};

108 ord(SUB): ∀ entxj∈ SUBENTx, j=1..card(SUBENTx)


110 ord(OVE): ∀ entxj∈ OVEENTx, j=1..card(OVEENTx)


112 ord(DIS): ∀ entxj∈ DISENTx, j=1..card(DISENTx)

113 ENTITIES = ENTITIES ∪ {entxj}; 114 ord(NO RESOLUTION of CATEGORY CONFLICT):

115 ∀ entxj∈ NORESENTx, j=1..card(NORESENTx)

116 ENTITIES = ENTITIES ∪ {entxj}; 117 }

118 if (card(ENTITIES) == 1) 119 return(entity from ENTITIES);

120 else if (card(ENTITIES) > 1){

121 Ask user to choose one entity from ENTITIES;

122 } else if (card(ENTITIES) == 0){

123 Ask user to choose one entity from ENTx;

124 }

Box 4.2.3.e get one correspondence for enti from many


115

1 ∀ ent ∈ ENT2’

2 if (ent was an Attribute) {

3 attr_ent = get from original scheme Attribute which was transformed

into Entity ent after Type Conflict resolution;

4 ENT2 = ENT2 ∪ {get Entity from Attribute attr_ent};

5 ATTR2 = ATTR2 ∪ {attr_ent}; 6 } else

7 ENT2 = ENT2 ∪ {ent};


9 ent = get Entity from Attribute attr;





13 ATTR2 = ATTR2 ∪ {attr_ent};

14 } else

15 ATTR2 = ATTR2 ∪ {attr};


17 ent = get Entity from Attribute attr;





21 PRE2 = PRE2 ∪ {pr(attr_ent)};

22 } else

23 PRE2 = PRE2 ∪ {pr(attr)};

Box 4.2.4.a the third step


116


25 entx = get first Entity of join;

26 enty = get second Entity of join;

27 if (entx was not an Attribute AND enty was not an Attribute)

28 JOIN2 = JOIN2 ∪ join;

29 else if (entx was an Attribute AND enty was not an Attribute){

30 attry = get from original scheme Attribute which was transformed into

Entity entx after Type Conflict resolution; 31 entk = get Entity from Attribute attry;

32 if (entk ∈ ENT2)

33 JOIN2 = JOIN2 ∪ {enty <J> entk};

34 else {

35 Notify user about inserting entk in the transformation process;

36 ENT2 = ENT2 ∪ {entk};


38 }

39 } else if (entx was not an Attribute AND enty was an Attribute){

40 attrx = get from original scheme Attribute which was transformed into

Entity enty after Type Conflict resolution; 41 entk = get Entity from Attribute attrx;

42 if (entk ∈ ENT2)


44 else{

45 Notify user about inserting entk in the transformation process;

46 ENT2 = ENT2 ∪ {entk};


48 }

49 }

Box 4.2.4.b the third step

4.3 Related work As anticipated in the introductory section, the problems concerning communication misunderstandings are analogous to the ones concerning heterogeneity when users formulate queries accessing to different distributed data sources. In this case, the aim of distributed databases is to provide users with uniform access to data stored in different data sources. In doing so, distributed databases have to manage two different kinds of heterogeneity. The first one concerns the use of different data models to represent the data sources. The second one, called also heterogeneity at logic level or semantic heterogeneity, refers to the different meanings and representations of data elements stored in different data sources. The first kind of heterogeneity can be solved with an intermediate “normalization” step involving the heterogeneous schemes. For instance, as described in (Bertino 1991), it is possible to build for each local data source a view expressed according to the elements of a uniform object oriented data model. Alternatively, it is possible to consider a reference data model (see i.e. (Aslan et al. 1999)) and transform all the


117

schemes in terms of this model. In the cited paper the authors propose as reference model HSDM (Heterogeneous Semantic Data Model). HDSM is a semantically rich and expressive object-based data model encompassing, in addition to the traditional object-based notions, a set of constructs in order to represent semantics within conceptual schemes. Hence, during the “semantic clarification” phase devoted to the transformation of schemes belonging to different data sources into a scheme expressed according to the reference model, the domain expert in charge of this process can provide additional information to enrich the semantics of the schemes thanks to the special constructs provided by HSDM (semantic enrichment). This information can be used in the future in order to solve inconsistencies among elements belonging to different data sources. In the following, we focus only on the approaches dealing with semantic heterogeneity without taking into account how heterogeneous data models can be transformed into a common data model. The literature in the distributed databases research area presents different approaches to solve the semantic heterogeneity problem. On the one hand, multidatabases (Litwin 1989) provide users with a uniform data manipulation language allowing them to formulate queries on different heterogeneous data sources. In this situation, the language does not provide any support to manage semantic heterogeneities of elements belonging to different data sources: detection and solution of heterogeneities are in charge of the user. The resulting systems are often called loosely coupled systems (see i.e. (Goh et al. 1999)) because they do not constrain the autonomy of the single data sources in order to provide uniform access to data. On the other hand, other approaches propose to build a global common scheme integrating the local data sources. In this way, through their applications users can formulate queries referring to this common scheme. Then, an underlying mechanism is able to rewrite the query in terms of the distributed data sources and then recompose the received results in terms of the global scheme. This mechanism is called mediator (Wiederhold 1992). In this case, the architecture of the database system is enriched with an intermediate software level, the mediator, between the user formulating queries and the distributed data sources involved in these queries. Hence, the mediator is in charge to solve heterogeneities in a user transparent way. This approach requires solving, a priori, the semantic inconsistencies among data belonging to different local data sources in order to build a common scheme. Since this integration process is difficult because often the scheme analyst lacks the needed knowledge, tools have been designed to support the analyst in her work. For example, ARTEMIS (Castano et al. 1999) provides the user with a support to both analysis and reconciliation of schemes into a common one. During the analysis phase, the elements of different schemes representing the same concept are automatically identified. This is done through “affinity coefficients” computed on the basis of semantic relationships among elements of the considered schemes. In the reconciliation phase, similar elements are clustered according to unification rules in order to build a unique common scheme. Unlike the first kind of approaches presented above and for analogous reasons, the systems resulting from these approaches are referred in literature as tightly coupled systems (Goh et al. 1999) since they limit the autonomy of local data sources by considering a global common one. Other approaches are based on the concept of mapping, that is on the possibility to establish explicit correspondences among elements belonging to different schemes in order to solve the semantic inconsistencies among them. The resulting systems can be considered as loosely coupled systems since they do not impose a tight integration among the distributed data sources. An approach proposed in (Bertino 1991) considers the definition of a hierarchy of integrated views (multiviews)


118

where each view maps elements of the data source (or of the view of the level below) into elements of the view under definition by providing an application with the appropriate integration level. Different views on top of the hierarchy can then support different integration levels. In this way, the considered view solves in a different way semantic incongruence among elements of different data sources, according to the specific needs of an application. The integration process in a view considers two kinds of mappings: structural and operational. The former concerns the mapping among elements of the data source (or of the view below in the hierarchy) with the ones of the integrated view under construction. The latter is about the definition of correspondences among operations: this mapping is used when data sources do not have well defined data schemes. Since our research effort is rooted in the CSCW area, it is in order to point out that its aims and topics of interest are distinct from the ones of the distributed database area and this difference influences the design of possible solutions in CSCW. In fact, databases are devoted to provide users with the ability of retrieving sets of data values that satisfy qualifications or predicates, specified through a query. Hence, databases deal with what is called the extensional aspects of data. If the considered data are heterogeneous, the semantic heterogeneity problems concern data integration. In addition, the focus of database research is on data itself, not on how users are going to use the retrieved data. Instead, our effort is devoted to provide actors belonging to different organizations with a support to facilitate their collaboration. In doing this, we refer to what is called the intensional aspects of the data, or conceptual schemes. Hence, we are more interested in the structure of the schemes and the information they convey on the corresponding context of work, than on their extensions, the data associated to them. We deal with semantic heterogeneity of schemes rather than with semantic heterogeneity of data. This view is consistent with new research efforts in the database area aiming at the definition of tools which, on the basis of object oriented data models and rule-based modelling, support the formulation of intensional queries, that is queries concerning knowledge on the scheme itself, rather than on the data (extension) underlying them (Papazoglou 1995). Beside the distributed database area, other research areas consider problems analogous to semantic heterogeneity from different points of view. These problems are characterized by what the local data sources represent in the considered framework: knowledge, unstructured data, and finally objects and activities involving actors in local contexts of work. These approaches, although rooted in different research areas, share the common aim to consider users when applications are designed. For these reasons, their solutions can be considered in the design of a support to alignment of meanings. Analogously to distributed databases, these solutions are mainly based on two techniques integration and mapping. The first one means that a unique global representation is built in order to provide actors belonging to different organizations with the support needed to collaborate. Hence, collaboration happens on the basis of actors’ mutual understanding supported by using the common language provided by the global scheme. As pointed out by Maedche et al. (Maedche et al. 2002a), this kind of approaches is “centralized”, since it makes reference to a centralized common scheme. In this way, these approaches are not suitable for situations where high flexibility is needed to manage distributed settings. An alternative approach to solve communication misunderstandings is mapping. This implies two steps. First to establish correspondences among elements belonging to


119

the different local schemes in order to let the involved actors maintain the different local descriptions. Second, to solve the possible (semantic) conflicts related to the defined correspondences. The approaches are characterized by the role of the technology in supporting the different ways to realize mappings and to solve the related conflicts. The area of Distributed Knowledge Management (Bonifacio et al. 2001) deals with heterogeneity in order to allow the exchange of meaningful knowledge among distributed workers using different knowledge sources. In EDAMOK (Bonifacio et al. 2001), a project about building Distributed Architecture for KM Systems, knowledge sharing among distributed communities is based on two steps: making explicit each community context, and creating mappings among elements belonging to different contexts. Mapping is realized automatically thanks to algorithms of context matching. However, the authors claim that providing support to context matching is not enough to solve conflicts as a consequence of mappings among elements of different contexts. For human beings knowledge sharing is often the result of a social process, in which many different cooperative strategies are used. In that case, the system should aim at reproducing this social process, called meaning negotiation. This is realized in the architecture through communication “protocols”2 supporting negotiation between autonomous agents in order to reproduce the dynamics of social interaction at system level. In the same vein, Bailin and Truszkowsi (Bailin et al. 2001) propose a protocol defined through a ontology (Ontology Negotiation Protocol). This protocol is designed in order to let the involved agents both negotiate and solve the semantic conflicts associated to the different information sources they are using. Other approaches to meaning negotiation are reported in (Bouquet (ed) 2002) and altogether adopt similar solutions. For what concerns unstructured data, Semantic web (Berners-Lee 1999) is a promising topic, because of the increasing use of Internet as a worldwide distributed repository of documents. Semantic web aims at enabling annotation mechanisms for web resources with machine-processable metadata by providing these resources with contextual knowledge helping people in accessing, extracting, interpreting and maintaining information on the web. In (Holowczak et al. 1996) the authors present a survey on different metadata representation approaches, where metadata represent data at a meta level concerning the correspondences established among the elements of the considered schemes, ranging from simpler tables to more complex ontologies. An approach considering ontologies to describe mappings is proposed in the MAFRA framework (Maedche et al. 2002a). In fact, in this framework is provided a Semantic Bridge Ontology (SBO) which describes the structure of a mapping of elements belonging to different ontologies. Then, in order to map elements of the two different ontologies, every mapping is established as an instance of what described in the SBO. According to the survey on different ontology-based approach reported in (Wache et al. 2001), MAFRA can be considered a Multiple Ontology approach since each of the different sources is expressed as an ontology. In order to allow the inter-ontology mapping, MAFRA provides an ontology (SBO) as formalism to express the correspondences among elements of the ontologies. In this vein, MAFRA can be considered also as an Hybrid approach to solve the problems of integration information coming from different data sources (Wache et al. 2001), since

2 here the term protocol refers to generic interaction flows among agents (or humans) and is not explicitly related to the protocol associated to a coordination mechanism.


120

the SBO ontology can be considered as a global shared vocabulary in order to express mappings. In the framework of CSCW, alignments of meanings is implicitly considered in field studies that analyze how information is incorporated in artifacts supporting cooperation (See (Simone et al. 2001) for a partial survey). From the technological point of view, a proposal tries to solve the problem of heterogeneity without imposing a unique global view. Macadam (Dourish et al. 1999) provides users with the possibility to define local customizations of the global view according to their needs and preferences. Macadam is a prototype allowing users to construct personalized local views of a global classification scheme organizing information in an engineering environment. In order to avoid misinterpretations among the collaborating actors, the system provides the users with techniques to align the different customized local schemes through a two way translation process: from the scheme of a user to the common scheme and from the common scheme to the scheme of another user. However, this approach is based on the strong hypotheses that at the beginning all the different users and groups working together are provided with a common agreed global scheme, irrespective of their local contexts. This becomes unrealistic in highly distributed work situations where each different context of work is created independently from the other ones: that is, these contexts lack a common reference starting point. The above considered approaches use algorithms to detect similarities among elements of the different schemes or among their structures in order to automatically build meaningful correspondences among them (Maedche et al. 2002b). Our approach is in the line of emphasizing social processes. Our choice is based on the considerations that if users are not part of the process aiming to alignment of meanings, they are not able to deal with the possible ambiguities unsolved by the system. This because it is hard for them to understand the meaning of the correspondences among elements of different contexts, if they are automatically generated. Rather, users need to be provided with tools allowing them to cooperatively construct the correspondences as part of the more general mutual learning process going on during collaboration (Mark et al. 1997). This implies to provide users with languages whose semantics allows them to express the descriptions concerning the local contexts of work and the correspondences among elements of the different schemes. In addition, users need suitable interfaces allowing them to manage both schemes and correspondences trying to reduce the effort for the alignment of meanings. Once the correspondences are established, the system can use this information in order to support the meaning of the communication exchanged in a format appropriate to users. In our view, the problem is not to find sophisticated algorithms detecting similarities, rather to find the appropriate way to represent information supporting communication understanding reflecting the users needs and skills according to their work contexts. The Reconciler helps users in establishing correspondences by distinguishing among synonymous, homonymous and equivalent elements belonging to the two considered schemes. In this way, the metadata expressing correspondences among schemes’ elements are not part of the two schemes and are not expressed using the same language. In fact, correspondences are stored as tables, with additional information related to the solution of the conflicts associated to them. We opted for this simple solution to avoid overloading users with a too rich formalism for establishing correspondences. However, an enrichment of the Reconciler could be performed in the direction of a more articulated characterization of the correspondences: for example, it could be defined according to an ontology as in the MAFRA framework. For instance not only proposing that an


121

entity X of the receiver scheme corresponds to an entity Y in the sender’s scheme, but also presenting which kind of correspondences holds among them according to the ontology. However to deal with these correspondences, the users should be provided with a support in order to avoid misinterpretations. Otherwise different users could understand the classification of correspondences in a different way, and, recursively, perceive the need for a reconciliation of the ontology itself. We conclude this section with considerations more specifically oriented to the two phases characterizing the support provided by the Reconciler. For what concerns the definition phase, the goal of supporting the reconciliation of different perspectives can be achieved in two ways: either incorporating in the support a predefined model of reconciliation or proposing a light support and let users define their own way to handle the reconciliation process. In the first case, models based on argumentation and explanation could be adopted as well as based on the structure of the dialogue (e.g. (Conklin et al. 1988), (Fisher et al. 1991), (Karsenty et al. 1995), (Winograd et al. 1986), (Zacklad et al. 1995)). The Reconciler is based on the second approach. We implemented a light support that can be enriched by integrating the Reconciler in frameworks possibly supporting negotiation in an explicit way. According to this choice, the next chapter presents how the tool can be integrated in ABACO. In so doing, we will not propose any predefined process to support the reconciliation process and let the involved actors to possibly define the process they prefer, by using the facilities provided by ABACO. We believe that the strength of our approach is based on its flexibility which allows the involved actors to define the negotiation protocol they consider more suitable at hand, according to the situation. For what concerns the communication phase, we consider the support which technologies could provide to actor during their communication in terms of the structure and the flow of the exchanged messages. For what concerns the structure of the messages, Information Lens (Malone et al. 1988) allows the exchange of semi-structured messages among people belonging to different groups. Each message encompasses a type structure which defines the structure of the fields of a (semi-structured) message associated to specific actions. The problems here is that people belonging to different groups using Information Lens could create different message type hierarchies and the structure of the exchanged messages could be misunderstood by the local systems interpreting them. To overcome this problem, Information Lens provides the ability to transform (both the field structure and the contents (format) of) the messages which belong to different type hierarchies on the basis of predefined translation schemes. As for the previous case, introducing a classification of messages could generate additional needs of reconciliation. However, classifications are an important means used in collaboration and are part of our future research agenda (see Chapter 6). For what concerns the second aspect, we considered only a chat-like way to communicate. However, if communication is part of a wider business process, it could be adequate to give messages a more structured flow. For example the Coordinator (Flores et al. 1988) , and systems improving it (e.g., CHAOS (Simone et al. 1999a), UTUCS (Agostini et al. 1994)) allow the definition of protocols based on the language/action perspective. These protocols regulate the flow


122

of the exchanged messages according to the actions expressed into the single messages. Since the communication among the involved actors follows a flow which depends on the actions contained in the exchanged messages, the structure of the conversation could be used as an additional source of information to contextualize messages and improve their understanding. Since the Reconciler is an open tool, it could be integrated in different frameworks providing the involved actors with a support to collaboration. The next chapter presents how the functionalities supplied by the Reconciler tool can be integrated in ABACO to provide the involved actors with a richer support to their collaboration.

Chapter 5: The support to alignment of meanings provided by the Reconciler in different scenarios

123

Chapter 5:

The support to alignment of meanings provided by the Reconciler in different scenarios The Reconciler was conceived as an open tool providing the involved users with a support to alignment of meanings in different scenarios. From an implementation point of view, this means that the Reconciler was developed as a set of stand-alone modules characterized by the high modularity of their internal structure and by well defined information interfaces. The latter are fundamental requirements to facilitate the integration of the Reconciler with the applications of the considered scenarios. In the following, we describe which information the Reconciler needs to get from these applications in order to offer its support to alignment of meanings (see Figure 5.1). The definition phase is composed of two sub-phases: the acquisition of the schemes and the definition of the correspondences among their components. The former can be performed in two ways: either as a data structure provided by an application of the considered scenario (1) or through an ad hoc definition interface (2). In any case, the Reconciler accepts inputs in a textual format according to the grammar described in the previous chapter. The definition of the correspondences among elements of the two schemes and the solution of the related conflicts are performed through the Reconciler definition interface described in the previous chapter (see (2) in Figure 5.1). However, in specific scenarios, it is more convenient to allow users to jointly define schemes and correspondences. In this case, the considered definition interface needs to produce, in addition to the coding of the schemes, the information related to the established correspondences in a format compatible with the one used by the Reconciler (see (3) in Figure 5.1). The communication phase involves the activation of the Reconciler algorithm that works on the information collected in the previous phase. In any considered scenario using the services provided by the Reconciler, a communication interface has to be designed (see (4) in Figure 5.1). The latter must allow users to build messages using the concepts related to the schemes and parse the sent messages in order to extract from them the used concepts together with additional information, as for instance the position of the detected concepts in the message. The Reconciler algorithm receives these pieces of information and performs its computation on their bases. The communication interface needs to be able to involve both sender and receiver accordingly in order to solve the ambiguities the algorithm cannot solve. This involvement can range from simple notification to the explicit request of trying to solve ambiguities, depending on the strategy adopted by the scenario under consideration. Likewise, the communication interface receives from the Reconciler algorithm the information related to its computation together with the information provided by the sender’s communication interface, and recomposes the message accordingly. The recomposing capability is


124

characterized by both the strategy of information presentation considered useful according to the scenario and on possible customization capabilities provided to the users. For instance, in some scenarios the received communication is transformed by simply substituting the sender’s concepts for the corresponding receiver’s concepts, in other scenarios the received communication is augmented with tables helping the user to understand the original sender message. The customization of the communication interface concerns the possibility to tune the additional information. For instance, when some concepts of the sender are well understood by the receiver, the information related to the correspondences with the receiver’s concepts is no more useful and hence no more presented in the communication interface.

Figure 5.1 the different entry points provided by the Reconciler tool to achieve support for alignment of meanings

The above architectural choice makes the Reconciler module easy to integrate in different scenarios. This possibility is valuable for two reasons: first, to achieve adaptability to different user needs and technological environments; second, to start experimentations of Reconciler usage as a fundamental step to identify features to be incorporated both in definition and communication interfaces according to the considered scenarios, and to evaluate the capabilities of the Reconciler to manage misunderstandings in real communication contexts. In the following sections, we propose two different scenarios of use of the Reconciler and we describe the related integration needs. These two scenarios consider different situations in which communication misunderstandings among collaborating actors may arise.

5.1. An experiment to test the Reconciler The kind of communication misunderstanding we consider in this section is related to the different terminologies actors with different professions and skills are using during their collaboration. Since each of them communicates in terms of her professional domain, the construction of a shared space of understanding is needed to work jointly. Articulation work aiming at alignment of meanings concerns the communication effort of the involved actors in order to create the space meshing

Definition phase

Communication phase

definition interface

communication interface

communication interface

corrsdefinition interface

Reconciler

definition interface

corrs

scheme

scheme + corrs

scheme

Reconciler algorithm

Reconciler tool

definition interfacescheme

scheme

definition interfacescheme + corrs

msg+groups+ msg info

A B

msg+groups+ msg info

(1)

(2)

(3)

(4)


125

different perspective to achieve collaboration. In this case, the actors using the Reconciler can cooperate to clarify the meaning of the professional terms so that each actor, not skilled in the profession of her interlocutor, can construct the paraphrases1 of the related professional terms according to what she perceives as their key features. Then the Reconciler is able to elaborate the terms with the previously established definitions so to improve understanding during communication among the actors. In the following we describe an experimentation which took place at University of California, Irvine in summer 2001. This experimentation aimed to better understand how the Reconciler supports collaborating users in alignment of meanings when they encounter the kind of communication misunderstandings described above. In this scenario, actors are not supposed to use additional tools for their cooperation but for a communication medium. In this case, it is useful to have the definition of the schemes and of the correspondences at the same time.

5.1.1 The role of the Reconciler in the experimental setting In this scenario, the Reconciler provides the two collaborating professionals with the support needed during the two different phases of alignment of meanings, as described in the previous chapter: definition phase and communication phase. The first one is devoted to the identification of the (professional) terms used by one interlocutor and their definition from the point of view of the other interlocutor; the second one supports the use of this reconciled terminology in the messages exchanged between professionals during their cooperation. The settled technological environment to experiment the Reconciler is structured as illustrated in Figure 5.1.1. Figure 5.1.1: The experimental environment

The definition interface

The definition interface is a software component which is shared between the two interlocutors by using an application sharing software. This interface allows the interlocutors to establish definitions of the different terms they are likely to use in their cooperative activity, so that they can better communicate. For the considered experiment, the two interlocutors are A, a Chief Technology Officer (CTO), and B, a Product Manager (Manager). Without loss of generality, we illustrate the case where a given list of computer science terms used by A is considered. With the help of A, user

1 From now on, according to the “jargon” used by users during experimentation, these paraphrases are called definitions.

Chat-like toolCommunication Interface

Definition Interface

Definition Interface

Reconciler

App. Sharing

Communication Interface


126

B identifies definitions which she, as a non-technical person, can understand and use. The interface is designed to facilitate the introduction of definitions for the technical terms (see Figure 5.1.2): it is possible to define or delete terms and associate new definitions with them, or to change them. Moreover, the user can reuse existing definitions using the Define As button. This is useful, since for non-technical persons, different technical terms can be naturally described in the same way. If, afterward, the user wants to distinguish between them, it is also possible to associate further information to better specify the concepts by adding attributes. For instance, the concepts HTML and WML could both be defined by B as WEB PROGRAMMING LANGUAGE (see Figure 5.1.2). Since WML is related to a more specific use of a pda/mobile phone, while HTML is more related to a pc, this additional information can be expressed as a new attribute associated to the technical term. An automatic selection is provided, in order to help users recognize the pre-defined correspondences. That is, when a concept or a definition is selected, the corresponding definition or concept(s) is highlighted.

Figure 5.1.2: the definition interface

At the end of the definition phase, the definition interface transforms the collected information in terms of Reconciler schemes and associated conflicts (in this scenario only of synonymy). Hence in this case, the definition interface falls in the situation expressed in point (3) of Figure 5.1 of the introduction. Both terms and the established definitions are considered as entities in the schemes


127

associated to the technical role and to the marketing role, respectively. The established correspondences among terms and definitions, implicitly associated to the definition of terms in the definition interface, are considered as correspondences among entities of the two Reconciler schemes (that is the involved entities are synonymous). The enrichment of concepts by adding attributes in the definition interface is considered as a creation of attributes and of association among them in terms of Reconciler schemes. In fact, for each attribute associated to a term during its definition, is created a corresponding attribute both for the entities representing the term and the definition in the two schemes. According to the above reported example, when the attribute pda/mobile phone is added to the definition of WML, the attribute pda/mobile phone is created both in the CTO’s scheme and in the Manager’s scheme. In the first case the attribute is associated to the entity WML, in the second case it is associated to the entity WEB PROGRAMMING LANGUAGE representing WML definition from the Manager’s point of view. Instead, the attribute pc is added to the HTML entity in CTO’s scheme, and again to the WEB PROGRAMMING LANGUAGE entity of Manager’s scheme. For what concerns correspondences, the attributes associated to the entities in the different schemes are considered as corresponding (they are equivalent) since they have the same name in both the schemes. The collected information is saved in a persistent format and is used by the Reconciler algorithm during the communication phase.

The communication interface

Once the definitions of the considered terms are established, the interlocutors can use both definitions and terms during their communication through the communication interface. The latter is implemented as two instances of the same application that are customized to their specific role. This means that the two interfaces are similar (see Figures 5.1.3 and 5.1.4) but each one shows in the Concepts list panel the list of concepts defined in the previous step according to the user’s point of view: A will find all the technical terms while B will find the corresponding negotiated definitions. In addition to the concept list, the interface contains different chat boxes. The Message History panel keeps track of the messages exchanged between A and B. The Outgoing Message panel contains the message that is currently sent. The message is a combination of free text (as for standard chat messages) and concepts chosen from the concept list. To overcome the problem of disrupting users in their online chat communication when they want to choose a concept from the concept list, an automatic word completion feature was added. The interface recognizes when the user is writing a concept and completes it only after a few characters are typed. This functionality has been realized adapting the partial matching algorithm proposed in (Flint 2001). Both recognized and chosen concepts are automatically inserted in the message text between square brackets so that the users can immediately recognize that the former are not simply words, but something they have already discussed before and that the interface will handle in a special way. Once the message is defined and sent, the communication interface activates the reconciler algorithm. To this aim, the Send Message event triggers the parsing functionality of the communication interface in order to group the concepts detected in the message according to their types (here only entity and attribute types are possible). Then the grouped concepts, together with the message, are transferred to the Reconciler algorithm in order to be elaborated. The Reconciler algorithm looks for the correspondences according to the definitions given in the previous step.


128

Notice that in the simplest case the algorithm operates a one-to-one substitution, as in the case of SOFTWARE TO RECOGNIZE HANDWRITING (see Figure 5.1.2), which is univocally associated to the technical term OCR. A more complicated case arises when two or more technical terms share the same definition. In fact, in case of one-to-many correspondences,(for example in Figure 5.1.2 where HTML and WML are both defined as WEB PROGRAMMING LANGUAGE), the definition interface, as explained above, allowed the users to define additional attributes. So when the Manager writes a message for the CTO about WEB PROGRAMMING LANGUAGE, if the attribute pda/mobile phone was associated to this concept, then the algorithm transforms WEB PROGRAMMING LANGUAGE into WML. This ambiguity resolution is performed by the using in combination the information collected in the definition phase and the second strategy of the module handling one-to-many correspondences of entities (see Section 4.2.2). In fact, the involved module searches among the entities in the receiver scheme (that is the scheme containing the entities WML and HTML) for the one which has the maximum number of attributes (expressed in the message) in correspondences with the ones belonging to the entity of the sender scheme under concerns (that is WEB PROGRAMMING LANGUAGE). In this case, according to the established definitions, the attribute pda/mobile phone present in the exchanged message allows the selection of WML. Instead, if the message contains both attributes, the above ambiguity resolution technique fails. The algorithm involves the interlocutors as follows. First, in presence of one-to-many correspondences, the sender is notified and asked whether she wants to send the ambiguous message anyway. In the affirmative case, the receiver is presented with information to solve the ambiguity. In fact, in this situation the algorithms visualizes the message augmented by a dialog box containing the ambiguous definition and the possible terms associated to it (in this example the CTO is presented with WEB PROGRAMMING LANGUAGE and the two defined terms WML and HTML): this information is a useful context for the receiver to understand which term was meant by the sender. In the above scenario not all the capabilities of the Reconciler algorithm are used: in fact the considered schemes (and the related conflicts and resolutions) are expressed in terms of entities enriched with attributes: hence, in relation to the richer capabilities of the Reconciler language, relationships and the domains of attributes were not considered. Moreover, there are only Terminology conflicts among entities and there are not situations of zero-correspondences, that is each technical terms has associated at least one definition. This simplification is motivated by one of the purposes of this scenario and of the related experimentation: to test how users accepted the two phases of alignment of meanings and their impacts on the communication interface that becomes more complex than the one proposed by the chat tools they were familiar with. Once all concepts are transformed and hence the computation performed by the algorithm ends, the detected information and the original message are sent to the addressee role. In the considered scenario, the message is recomposed by the associated communication interface keeping the same structure of the sent message and substituting the sender’s concepts in brackets with the ones found by the algorithm. Notice that from a technological point of view, the two instances of the Communication interface exchange messages through Java RMI. This allows them to communicate through remote objects which export methods making them visible to the other applications through the network. In the presented simplified scenario, the remote objects simply export a “print” method invoked by the


129

sending instance to write the original message and the elaborated information in some informational structure of the receiving instance. According to users’ suggestions after the first pilot tests, a Reminding functionality has been added to the communication interface. In fact, sometimes the users could not remember the definitions given in the previous step. This led us to add new features to the interface trying to help users in remembering and to support their mutual learning process: the first one is a text box which shows the correspondence established for a concept when it is selected from the list (for instance, in Figure 5.1.3 the selection of the HTML term shows the corresponding definition: WEB PROGRAMMING LANGUAGE). The second feature presents to the receiver the translated concept in a message together with the corresponding sender’s concept (see in Figure 5.1.4 the last message of the Message History).

Figure 5.1.3. the Communication interface for A (technical).

5.1.2 The description of the experiment The experiment was designed with the fundamental contribution of Prof. Gloria Mark and conducted in cooperation with V. Gonzales in summer 2001 at University of California, Irvine (Mark et al. 2002). The aims of experiment were twofold: to test the usefulness of the system and to get from users indications useful for the improvement of the Reconciler in terms of both the individuation of new functionalities to be added and the redesign of the user interface. To do the experiment, we followed a process whereby people initially developed alignment of meanings for the professional terms. We then focused on the use of the communication interface to determine how well it could support people in applying these alignment of meanings in their communication.


130

Figure 5.1.4. the Communication interface for B (non-technical).

In order to evaluate the Reconciler, we developed two hypotheses on how the Reconciler could affect articulation work:

− Articulation should be more explicit when not using the Reconciler. Since both actors know that the other understands the term being sent, we would expect fewer messages that concern articulation when the Reconciler is used. Conversely, without using the Reconciler, we expect more explicit messages concerning articulation. We consider messages concerning explanations, asking for clarifications, and confirming the other (establishing common ground) to be articulation messages.

− Communication should involve a higher proportion of task-related messages when using the Reconciler. We expect that the use of a system to support the alignment of meaning of terms would result in actors exchanging a higher proportion of messages that are task-related, compared to without such technical support.

In addition to these hypotheses, we investigated the use of the interface, and the application of the terms in the communication. To verify the above hypotheses and the system usability, we designed a task which involved people in negotiating the alignment of meanings for technical computer science terms. In order to have an experimental paradigm that more realistically replicated the idea that organizations have different specialties that must communicate with each other, we paired together students from different university specialties: computer science and from a non-technical discipline (for a total of forty subjects). Articulation was needed for the two people to understand and make sense of the technical terms so that together they could perform the task. In order to construct an initial list of technical terms, we performed a pretest survey of terms with technical and non-technical students. Then we conducted a series of pilot experiments to select terms from this


131

list that we felt confident would be understood by an upper level computer science student, but not by an upper level non-computer science student. The task designed for the experiment intended to recreate a common situation in the IT industry: planning a proposal for a new product: Personal Organizer software for a Personal Digital Assistant (PDA). Since our goal was to study the articulation process, the task focused on the initial phases of planning: selecting general technical features that the software will include or support. These were: (1) Interface: How should information be presented with the interface? (2) Information Organization: How should information be organized to fit the PDA screen, (3) How should input be given? (4) Support for peripherals: What kind of external devices should the software support? (5) Security: What kind of security systems or methods should be implemented, (6) Threat: How can the product resist threat, (7) Communication: methods for the PDA to communicate with other devices. Examples of technical terms that needed to be discussed as options were: RGB, XLST, OCR, Jaz drive, Public Key, SSL, USB. During the experiment, each student played the role of an employee of a software company. The computer science student played the role of the Chief Technology Officer and the non-technical student played the role of the Product Manager. The experiment was conducted in a large single room lab. Students sat at workstations facing each other, but were visually separated by partitions. The goal was to simulate distance collaboration. Each computer was equipped with a small web camera, noise-cancelling headphone and microphone. For the first part of the experiment the students communicated by using audio headphones and video. For the second part, they wore noise cancelling headphones, communicating only with online text chat. The task was split into two consecutive days, 45 minutes each day. On the first day the students defined the list of terms. They returned a second day to use the terms in discussing the proposal. Our intention was to create a time separation so that subjects would have less reliance on their memory of their predefined terms from Day 1. Day 1. The experiment was explained to the subjects as well as the role they would be playing. Both conditions considering the use of the Reconciler tool (with Reconciler, R) and not (Without Reconciler, W) used audio and video to communicate to define the terms. In the R condition, the subjects used the definition interface of the system and worked together to define the technical term so it would be understandable to the Manager. In the W condition, subjects defined the same terms as in the R condition, but wrote the results on paper. An example was for “HTML” to be defined as “WEB PROGRAMMING LANGUAGE” for the Manager. They had to define 39 technical terms. Day 2. All subjects were trained for five minutes on using the chat functionality of the Reconciler. In addition, in the R condition, subjects were trained on how to use the communication interface of the system. In R, subjects were given examples about how the system automatically recognizes terms, how to introduce them directly, and how to check for the definitions in the screen. All subjects were told to analyze advantages and disadvantages of the different options that the proposed “Personal Organizer” software would include. Each category (e.g. Interface) involved discussing and selecting among the set of technical terms that they defined on Day 1. Groups had 35 minutes for the task. Thus, in the R condition, groups used the communication interface of the Reconciler, and in the W condition, groups used the Reconciler interface only as a chat tool without the support provided by the Reconciler algorithm. The W groups could refer to their defined terms on paper from Day 1. Groups then filled out a questionnaire.


132

5.1.3 Lessons learned The results of the experiment were altogether positive. In fact, during the completion of their task, subjects using the Reconciler sent fewer message concerning articulation than the ones completing the same task without using the Reconciler. That is using the tool, people involved in collaboration during the communication phase focused more on the completion of their task and spent less time in exchanging messages concerning the meanings of the professional terms. More details on the data that describe the outcome of the experiment can be found in (Mark et al. 2002). For what concerns the indication on the usefulness of the system, we have to focus again to the concept of effort reported in Chapter 1. Let us consider in turn the definition and the communication phase associated to day 1 and day 2 in the experiment. The definition phase concerns articulation work which represents the collaborative and conceptual effort needed by the two professionals in order to achieve collaboration. In fact, the involved roles have to establish definitions for the professional terms in order to understand each other in the successive communication. Hence, we can question the Reconciler against the ability to reduce this effort. In this view, we have to consider if our definition interface is an useful tool to manage this articulation effort. The experiment provided us with suggestions proposed by the involved subjects. These suggestions are of different nature. On the one hand, they refer to the nature of the articulation effort itself highlighting how the users can be involved in the related process. This kind of advices directed us in searching for a smooth integration among the applications people use for everyday work and our definition interface which supports them during definition phase. Consider again a CTO and a Manager collaborating to write the joint proposal of a new product as in the scenario related to the proposed experiment. In this situation, the definition phase supported by the designed interface may be too separated from the routine work of the involved roles. The same consideration holds for the communication phase. It is possible to imagine a scenario where each of the involved roles writes separately the part of the proposal concerning her duties and according to what the other one had already written. In this situation, some of the terms used by one of the two roles could be misunderstood by the other collaborating one. This considerations guided us in the development of a prototype trying to smoothly integrate both aspects of preparation of the proposal and alignment of meanings for the misunderstood terms. In the prototype, the definition interface was integrated in the production tool needed by the two professionals to perform their collaborative work. More precisely, the word processor, each of the two roles uses to write the joint proposal, supports also the definition of a term not known by the other partner providing the users with an additional functionality. The latter allows the involved users to jump into the definition phase by opening the related interface in order to establish the definition of the selected term which is misunderstood. After the definition of the selected term, the tool automatically switches back to the word processor allowing the role to continue her work of writing the proposal. In this view, the system supports both the individual work and the joint articulation effort aiming at term definitions needed to complete the work. In addition, the subjects noticed that the introduction of terms and their definitions was too complicated, since it requires selecting terms and activating the desired functionality through a button that opens a dedicated window. They suggested that the columns related to terms and their definitions should behave like the grid provided by spreadsheet applications. In this way users might add terms and their definitions by pointing the desired cells and type directly what they want. To delete a term they just highlight the cell and press the Delete key. To modify a term, they just go


133

to the cell and press the Insert key. Only to add attributes they are provided with a special button that opens another window where they type the attributes concerning that particular term. For what concerns the communication phase, there is a conflict between the effort devoted to define terms during the definition phase and the effort needed by users during the communication phase to take advantage of this additional information. In fact, if the effort in using the functionalities provided by communication interface is greater than the articulation effort, then users can simply decide to skip the aid provided by the tool and use the Reconciler simply as a chat tool using the exchanged messages to convey the definitions needed for the technical terms. To avoid this situation, we designed the communication interface taking into account a suggestion emerged during the pilot test in order to make the interaction easier. We added a functionality to automatically complete the technical concepts when they are typed, in order to avoid users to loose the focus in their communication by picking up concepts from the concept list. Moreover, sometimes users had problem to keep the rhythm of the conversation. They often experienced cross communication problems (e.g. “I already answered that, check my last message”). In fact, the system (as any chat tool) allows the users to type as many messages as they wish without having to wait for the answer from their partner. To handle this situation, we introduced in the communication interface a functionality to help users to get the right turn-taking during conversations. In fact, the system now presents a label on top of the area where messages are written as soon as the other role starts to writing. When the message is sent the label disappears. This experience suggests a consideration about the usage of chat tools in business communication. When the matter is not just a simple message (e.g., to notify something) and becomes part of a longer and more demanding conversation, chat tools might fail to provide an adequate support. However, this is a controversial matter and more field analysis is required (Isaacs et al. 2002). We conclude this section be noticing that this experiment considered the transformation of messages only in one direction. In fact, it was supposed that only one role was using the specific jargon related to her expertise and the other one had to understand the terms used during collaboration. Hence, the related prototype supported a one-way transformation of the message, accordingly. This fact was perceived as unnatural by the people involved in the experiment. Then the prototype was enriched, allowing, in the definition phase, each role to define the specific terms related to the profession of the other which could not be understood during collaboration. For what concerns the communication phase, the new prototype allows each role to compose messages using both the specific terms related to her profession and the established definitions of the terms used by the other collaborating partner. In this way, the prototype supports the transformation of the messages in both directions, according to the computations provided by the Reconciler algorithm. An experiment considering this new scenario was sketched, but not realized. In this scenario a Design Engineer and a Medical Chief collaborate in the development of a joint proposal concerning the definition of a new palmtop device able to check the health of people with cardiopathies through suitable sensors. In their joint effort each of the two roles may use some terms related to her jargon the other one could not understand. See Figure 5.1.5 showing the two different communication interfaces associated to the involved roles. The interface of the Medical Chief Engineer contains for instance the terms GCR and HA which she normally uses with her colleagues, but which the Engineer could not understand. Instead, in the definition list are reported MARKUP LANGUAGE FOR MOBILES and MOBILE DEVICE which are the definitions of terms used by the Design


134

Engineer. Conversely, the communication interface of the latter contains technical terms PDA and WML and definitions corresponding to medical terms like GRAPHIC CARDIAC RYTHM and HEARTH ATTACK. Compare the message history panels of the two interfaces shown in Figure 5.1.5. The message sent by the Medical chief both using her jargon and the definition for technical terms how can we display [GCR] on a [MOBILE DEVICE]? is displayed on the Engineer’s communication interface as how can we display [GRAPHIC CARDIAC RYTHM(GCR)] on a [PDA(MOBILE DEVICE)]?, according to the algorithm’s elaboration. In this way, the GCR medical term is transformed according to the definition established in the definition phase and the definition MOBILE DEVICE is substituted by the known technical term.

Figure 5.1.5. the two-ways communication interfaces of Medical Chief and Design Engineer.

5.2 The integration of the Reconciler tool into the ABACO architecture As reported in the previous section, the outcomes of the experiment were altogether positive. In particular the first hypotheses was proved to be true. This means that the roles involved in the completion of the collaborative task, using the Reconciler tool, got a reduction in communication for explanation of the terms related to their different professional jargons. We have to recall here that in order to start the experimental phase as soon as possible, we identified a context of use where the involved actors did not have a long tradition in cooperating together and any specific technology supporting this collaboration. Usually, this is not the case in real work situations. In fact, people collaborate on the basis of a (often implicit) shared experience, which requires time to be achieved: the latter is a critical point in the experimentation of CSCW systems. In this section, we want to consider a scenario where the capabilities of the Reconciler can


135

be fully exploited. To this aim, we shift our focus from experiments involving individual professionals to a scenario considering distributed organizations whose contexts of work are explicitly coded through suitable information structures. Hence, the idea is to consider the use of the Reconciler in a scenario taking into account the experience of people working together, where a notion of context of work is stronger and the communication among actors belonging to different local context refers to common objects which are described locally in different ways. In particular, we consider the situation of actors belonging to different organizations which collaborate through the use of technologies supporting their cooperative work. To deal with this situation, we could refer to any technological support to cooperation: however, we propose ABACO as the reference framework for the integration with the Reconciler. Apart from that ABACO is the multi-agent architecture we designed to support articulation work (Divitini et al. to appear), we make this choice also for other reasons. In fact ABACO provides a flexible support to articulation work through the incremental and dynamic definition of coordination mechanisms expressing articulation of activities at local organizational levels; and the latter can be composed to define collaboration at higher inter-organizational levels. According to this view, collaboration is often achieved at inter-organizational level where, typically, communication devoted to collaboration may be misunderstood. Moreover, ABACO provides the involved actors with a notation (Ariadne) to describe coordination mechanisms at the semantic level of articulation work. In this way, since ABACO allows the actors to describe their contexts of work in a way which is close to their experience, the communication devoted to their collaboration can refer to concepts described in the coordination mechanisms incorporating this experience. In this view, it is reasonable to consider alignment of meanings at the level of coordination mechanism and hence to integrate the Reconciler within ABACO. As previously described, alignment of meanings is a form of articulation work and the latter is a cooperative activity too involving distributed actors. Since in general this articulation process generates conflicts, it can be expressed in terms of negotiations among the involved actors in order to solve them. In terms of ABACO this means to design a specific coordination mechanism, hereafter Reconciliation CM, which handles the definition phase aiming at alignment of meanings between the different CMs representing local contexts of work (see Figure 5.2.1). As the Modify CM described in Chapter 3 aiming at alignment of protocols, the Reconciliation CM encompasses both a protocol and an artifact. The protocol represents the way in which the involved actors negotiate to agree on a solution for the discussed conflicts. The artifact, which objectifies the protocol, keeps the information structure needed to support this negotiation process.

Figure 5.2.1: the Reconciliation CM

During the definition phase, the categories of the coordination mechanisms used in the

Manager

Reconciliation CM

Schemes and correspondences

Role

Role

Role

RoleReconciliation Artifact


136

communication supporting collaboration are 'materialized' in the artifact included in the Reconciliation CM together with the explicit correspondences that can be used to avoid repeating the same negotiation in the future. More precisely, the Reconciliation CM includes as protocol the communication patterns governing the process of alignment of meanings and as artifact, called from now on Reconciliation Artifact, the temporary storage both of the local CMs expressed in terms of schemes and of the correspondences among elements of the schemes the involved Roles established in this phase. For what concerns the communication phase, the External Interface agents of ABACO (from now on Reconciler agents) which mediate the information exchange among agents belonging to different coordination mechanisms, are modified to manage the transformation of the messages exchanged according to the reconciliation information they keep and the Reconciler algorithm they execute (see Figure 5.2.2). In order to provide the services associated with their duties, the Reconciler agents store in a persistent way both the local CMs expressed in terms of schemes and the correspondences among elements of the schemes established during the definition phase. Notice that the Reconciler agents have to manage many communications in parallel. This is possible thanks to their internal structure which allows to activate a specific thread for any communication across pairs of CMs, where each thread starts a local copy of the Reconciler algorithm fed with the appropriate information to elaborate the considered message.

Figure 5.2.2: The Reconciler agent

ABACO dynamically adds the defined coordination mechanism as a new component of the application and is able to modify the agents in order to immediately provide the involved actors with the related articulation. Here, the new coordination mechanism exploits different reflection abilities of the architecture with respect to the Modify CM. In fact, the latter is activated on the fly when the support for the negotiation related to the propagation of changes is needed and disregarded when an agreement among the involved actors is reached. In this case, the application agents, involved by the changes as a result of the negotiation, need to be modified in their behaviors, accordingly. For what concerns alignment of meanings, the Reconciliation CM is again activated when needed to support the definition phase and then disregarded when an agreement is reached. Unlike the previous case, the Reconciler agents coexist with the coordination mechanisms they refer to and need to update their local data to keep the results of alignment of meanings in a persistent way, since the negotiation of the meanings can happen at different times and the same meanings can be re-negotiated in the future, when the agreement previously established does not hold anymore.

5.2.1 The definition phase supported by the Reconciliation CM In the following, we present in more details the Reconciliation CM by considering first how it supports actors in the definition phase: this requires deepening the description of the Reconciliation Artifact. In so doing, we will refer to the Ariadne notation (see Appendix A that contains the

Reconciler agent Schemes and

correspondences


CM1 CM2message message


137

Categories of Articulation Work together with their attributes) when we consider the definition of a CM that provides pieces of information to the Reconciliation CM (semantic level) and to ABACO when we discuss how the Reconciliation CM becomes one of its components (architectural issue).

The Reconciliation Artifact: constructing the schemes

At the user interface level (i.e., through the Ariadne notation) the construction of coordination mechanisms is divided in two steps: the selection of the CM language and the CM definition according to it. The choice of the language is about the selection of the categories used to build the CM while the definition of a CM concerns the construction of the instances of the categories through the specification of the values of their attributes. The result of this construction represents what we call a CM scheme. Since the Reconciliation Artifact has to contain the information about the local CMs, the CM scheme has to be transformed into a Reconciler scheme (based on the grammar described in Chapter 4), so that the latter can be used to define the needed correspondences during the definition phase of the alignment process. This transformation process takes into account that the construction of a coordination mechanism is composed of the two above steps that generate a partial scheme and its completion, respectively, as follows. In order to build the partial scheme, every category of the CM scheme is translated into an entity of the partial Reconciler scheme. For what concerns its attributes2:

− the attribute of type name becomes the key attribute name of the entity corresponding to the category;

− all attributes of type content become attributes of this entity keeping the same name; − the attributes of type reference become relations between entities. Specifically, the relation is

between the entity (representing the category in the scheme) the attribute belongs to and the entity (or entities) referred to by the value of the attribute. Recall that for every attribute of type reference in a category there is, in the category referred to by the value of the attribute, an attribute of type reference that describes the inverse relation. For example, in the category Role the attribute responsible for refers to Tasks, and in the category Task the attribute under responsibility of refers to a Role. In the scheme the two unidirectional relations become a single bi-directional relation whose cardinality is the composition of their cardinalities. In the above example, the resulting bi-directional relation responsibility has cardinality 1:N since the relations responsible for between Role and Tasks has cardinality (1:N) and under responsibility of between Task and Role has cardinality (1:1).

The categories representing Resources are handled in a slightly different way, since they are especially involved in the process of alignment of meanings. There are four kinds of Resources: Informational, Material, Technical and Infrastructural Resources. The latter become four entities of the scheme keeping the same name. Attributes of type content, like location and state whose value is a data-frame directly become attributes of those entities. Attribute description of type content, which is different in each kind of Resource, can be either a further composition of categories, attributes and relations, typically in the

2 see Appendix A to have all details about the attributes. For the purpose of the following description it is enough to know that the attributes of type content are data structures while the attributes of type reference are references to other categories.


138

case of Informational Resources, or a data-frame, typically in the case of Technical Resources. We will call sub-schemes the schemes associated to the attributes description. The first possibility is the most interesting one for what concerns alignment of meanings. Hence, we consider only the Informational Resources in the explanation of the global scheme generation. They will be referred simply as Resources. Let us consider, as an example, the same scenario described in Chapter 4. The coordination mechanism defined in the Local office contains, among the others, a Role secretary which is responsible for the Task of scheduling the use of halls (let us call it schedule halls). This Task is completed using as (informational) Resource a form reporting the information related to the scheduling of a specific hall (let us call it hall schedule form). According to this CM language, we obtain the partial scheme represented in Figure 5.2.3.

Figure 5.2.3: the partial scheme related to the Local office example

Completing the schemes

Once the language has been selected, the definition of a CM concerns the construction of the instances of the chosen categories. The complete Reconciler scheme corresponding to the CM scheme is obtained by considering the values of the attributes as the domains of the attributes of the corresponding entities3 (see Figure 5.2.4) Specifically, since each attribute of type reference becomes a relation, their domain is the Cartesian product of the domains associated to the name attribute of the involved entities.

Figure 5.2.4: the resulting complete scheme according to the Local office example

Again, (informational) Resources are considered in more detail. Since in the language phase the 3 The scheme does not consider additional information about the instances of the categories since this is not required by the functionality currently implemented in the Reconciler.

Resource

Task

usage

Schedule hall form

is a

name: {...}

sub-scheme specified in the attribute description

instance of

Schedule hall form A111

attribute values become domains

Schedule hall form A111

component

location: state:

instance of

schedule hall usage

{...}name: {...}

schedule hall

Role

resp. for

instance of

secretary

name: {...}

secretary

Task

usage

Resource

name: {...}

location: state: {...}

name: {...}

Role

resp. for

name: {...}


139

choice of a Resource does not include the specific sub-scheme associated to its description attribute, in this definition phase the attributes of the Resource are handled differently. Every value assigned to the attribute name is translated in the scheme as an entity carrying the same name. Again, considering the Local office example, the Resource schedule hall form corresponds to an entity schedule hall form in the scheme. In addition, the scheme contains an entity (informational) Resource and an is-a relation between the two considered entities. This amounts to consider this naming as a specialization of the resource: we refer to the specialized category by resource sub-category and the related entity as resource sub-entity. The latter inherits from the resource its attributes (and also the relationships which are the result of the transformation from CM schemes into partial Reconciler schemes). In fact, Task attribute of type reference used by became the relationship usage between Task and Resource in the partial scheme (see Figure 5.2.3). Then usage relationship is inherited between the sub-entity and the entity Task in the complete scheme (see Figure 5.2.4). Notice that in the current version of the Reconciler tool, is a relationships are not considered during the definition of correspondences aiming at alignment of meanings because we still do not consider hierarchical, but only flat descriptions. Hence, they do not compare in the complete schemes which need to be aligned. Moreover, the definition of a CM entails the definition of the attribute description by specifying the corresponding sub-scheme that becomes part of the general scheme. Since Ariadne requires the user to express an entity of the sub-scheme serving as connection with the resource sub-entity, the transformation automatically adds in the global scheme a standard relation, called component, with cardinality (1:1), to realize the above connection (see Figure 5.2.4 where, according to the proposed example, the subscheme may refer to the highlighted part SCHEDULE of the Local office’s scheme reported in Figure 4.2.6). This completes the sub-category management. Obviously, the definition of a CM creates instances of sub-categories. Again, the latter do not appear in the scheme (dotted boxes in Figure 5.2.4). Instead, for all of them, the values of their attributes become the domains of the attributes of the connected sub-scheme, apart from the names of the instances of the resource sub-entity that become the domain of the attribute name of the resource sub-entity (bottom right of Figure 5.2.4). The following table summarizes the correspondences among elements of a CM scheme and its corresponding Reconciler scheme according to the above described transformation process. CM scheme Reconciler scheme

CM Language step CAWs Entities Attributes (name, content) Attributes Attributes (reference) Relationships Resources Entities Resources

CM Definition step Values of attributes of CAW instances Domain (Set) of the corresponding attributes Attributes (descriptions) sub-schemes + component relations Resource names Entity names + is a relations Instances of Resource names Domain (Set) both of attributes names and

attributes in sub-schemes Table 5.2.1: The transformation of CM schemes into Reconciler schemes


140

The protocol: materializing the correspondences

The main purpose of the protocol of Reconciliation CM is to support users in the negotiation aiming at alignment of meanings which is materialized in the correspondences between Reconciler schemes elements. These correspondences have to be incorporated in the Reconciler artifact and have to be stored permanently also in Reconciler agents to construct the whole information needed in the communication phase. In the previous section, we described how to get from CM schemes the information needed by the Reconciler, i.e., Reconciler schemes. Now these schemes have to be aligned by the involved users according to the Reconciler CM protocol using the functionalities provided by the Reconciler definition interface (that in this case is of type (2) in Figure 5.1). As for any other CM, the protocol can be defined by the involved users. For sake of testing the integration we are aiming at, we consider the simplest protocol: all the users involved in the alignment of meanings process can communicate among themselves to define the correspondences, while a single Actor assumes the Role of Manager of the Reconciliation Artifact and is in charge of keeping it updated through the Reconciler definition interface. This simplified choice is reasonable since it leaves the users free to organize their negotiation in a quite flexible way, in principle also by communicating outside the system: e.g., in a workshop like in the Politeam case (Wulf 1997). Notice that during definition phase, entities and attributes coming from the partial schemes related to the CM language step mainly generate Naming and Unit conflicts. In particular, for what concerns Unit conflicts, the latter involve only domains of type Set because, as reported in the above described transformation process, the values of the defined attributes are collected in the Set domains of the corresponding attributes of the scheme under construction. Instead, in the case of entities and attributes coming from the sub-schemes associated to the attributes description, the correspondences may involve all the types of conflicts that we are able to deal with, since the involved schemes are fully user defined. This concludes the description of the Reconciliation CM and how it can support the definition phase aiming at alignment of meanings. In the following, we describe how the information collected in the pertinent Reconciler agents can be used to support the communication phase. This means to present how the exchanged communication can be transformed in order to make it more comprehensible by the receiver using the information established during the definition phase.

5.2.2 The communication supported by the Reconciler In the communication phase, three important aspects are the structure of the messages exchanged between the involved users; the strategy used to involve the sender and the receiver when the message raises ambiguities the algorithm is not able to solve; and finally, how the information provided by the Reconciler algorithm is presented at the receiver communication interface. For what concerns the first aspect, messages can be: structured, semi-structured or free text. Structured messages are expressed through the ACL syntax presented in Chapter 2. This means that <data> and <info>, which are the parameters of the message primitives, make use of concepts and objects belonging to the schemes of both the sender and the receiver. This kind of messages represents explicit coordination between human actors associated to Role agents. Semistructured messages contain both free text fields and fields which have associated a specific type (Malone et al. 1987). Hence, semi-structured messages are codified in a predefined structure whose typed fields contain concepts belonging to local contexts of work. Typically, messages of this kind are forms generated by applications used in the cooperative setting and incorporate


141

codified experiences of work. An example related to already considered Local and Central offices, are the certificates that are usually codified as forms with typed fields requiring to be filled according to their meaning (as for instance the section of a certificate referring to information about a student is expressed in terms of the STUDENT entity of the Local Office scheme together with the associated attributes). Moreover, certificates contain additional free text fields (used for instance to insert notes and so on). Actors belonging to the two offices collaborate, for instance to complete a certificate, by exchanging the related form. In this situation, the contents of the form may be misunderstood by the receiver if the fields are filled in according to the sender point of view. Consider for instance the section related to student information which is expressed by the Local office point of view with the STUDENT entity. On the other hand, the same information related to a student is codified in terms of entity FINAL_YEAR_UNDERGRADUATE and the associated attributes in the Central office scheme. Free text messages are related to free text communication the involved actors may exchange. In this case, the message is without a specific structure because there is not a well codified structure reflecting a specific aspect of collaboration. The above structures can be handled in a uniform way if concepts belonging to the free text part are identified. This is why we concentrate on the free-text and propose two strategies to “work” the concepts so that they can be recognized by the parser, grouped according to their types and passed to the algorithm. A first strategy was presented in Section 5.1. A second one will be illustrated in Section 5.2.4. For what concerns the strategy to involve both sender and receiver of the message in presence of ambiguities the algorithm can not solve (see Figure 5.2.5), we consider the kinds of ambiguities requiring users intervention: zero and one-to-many correspondences either among synonymous entities or among synonymous attributes belonging to the different schemes. If the algorithm does not detect any ambiguity, the message is sent to the receiver without any additional notification. Instead, if during algorithm computation, one of the above considered ambiguities ((1) in Figure 5.2.5) is detected in the sent message, the sender is asked whether she still wants to send the ambiguous message that could be misunderstood by the receiver (2). In case the sender decides to send the message, the involvement of the receiver changes according to the kind of the detected ambiguity. In all the situations the addressee agent receives the original message. In particular, since zero correspondences can not be solved, the information concerning these ambiguities (3) is passed to the receiver together with the message. If at least one sender’s entity has many correspondences with some receiver’s entities (4), the receiver gets the message together with the information concerning both the current elaboration and the unsolved ambiguities. In this situation (5) the receiver can choose from her communication interface to abort the algorithm (skip) since she is able to understand enough of the received message though the reported ambiguities. Otherwise (help), the receiver can try to solve the reported ambiguities with the support of her communication interface which presents for each ambiguous entity, the list of the corresponding entities belonging to the receiver’s scheme. Then the receiver can decide which entity of her scheme corresponds to the considered sender’s entity (6). This choice transforms the one-to-many correspondence involving the sender’s entity into one-to-one correspondence. In this way, the algorithm can take advantage of the additional information provided by receiver (7) in order to solve one-to-many correspondence ambiguities involving attributes, if any (8). In case the receiver does not make any choice, the considered one-to-many


142

no

(2)

msg+transf-info+ unsolved ambiguities

msg +transf-info

receiver sender Reconciler algorithm msg

msg +transf-info no

yes ambiguities notification

yes msg

no

yes msg+ transf-info+ unsolved ambiguities

no

yes solution no

yes

ambiguities?

Add info related to solution

send anyway?

add ambiguities related to zero corr if any

one-to-many corr for entities?

start elaboration

continue elaboration

solve one-to-many corr for entities?

continue elaboration

one-to-many corr for attributes?

(1)

(3)

skip/help?

no

help

skip

(4)

(5)

(6) (7)

(8)

Figure 5.2.5: the strategy expressing the involvement of both sender and receiver in presence of detected ambiguities


143

correspondence is transformed into zero-correspondence for the sender’s entity under concerns. This means that the algorithm continues the message processing without receiving any additional help to solve the possible ambiguities involving attributes. At the end of the elaboration concerning attributes’ ambiguities, the message is sent to the receiver with the information concerning its presentation on the related communication interface. In case some ambiguities are still unsolved, they will be notified during the visualization of the message, accordingly. When the communication interface receives the message elaborated by the Reconciler algorithm, it is able to recompose the message according both to its structure and to the strategy of presentation of the correspondences computed by the algorithm. We consider here a different strategy to present the information computed by the algorithm with respect to what described in Section 5.1. In fact, in this scenario, collaboration among users is not extemporaneous, rather it is the usual way to perform their day by day work. Hence, the flow of message exchanges is more relaxed since communication is intertwined with other activities and lasts over long periods. Moreover, collaboration is part of a mutual learning process among the involved users about the different local contexts of work and consequently about the related local descriptions concerning the objects of the collaboration. This means that often the receiver can understand the meaning of the sender’s concepts expressed in the message both using the contextual information provided by the message itself and her experience grown during collaboration. Hence, to avoid information overload for the receiver, we decided to let her free to look only for the information about concepts she still does not understand. In fact, as illustrated in Figure 5.2.10 of Section 5.2.4 (illustrating the description of the communication interface of the developed prototype managing free text messages) the receiver can directly select from her communication interface just the concepts she misunderstood in order to get the related information provided by the previous computation performed by the Reconciler algorithm.

5.2.3 The impacts on the underlying conceptual architecture In the previous sections we described how the Reconciliation CM is structured to support the definition phase, both for what concerns the transformation of CM schemes into Reconciler schemes and the negotiation process aiming at alignment of meanings; how a communication interface can be designed so that the communication phase can use the information established during the previous phase; and finally, how the Reconciler algorithm involves users, when needed. Moreover, we presented how External Interface agents mediating communication among application agents in ABACO are modified into Reconciler agents in order to support the transformation of the exchanged messages according to the support provided by the Reconciler. In this section we illustrate (see Figure 5.2.6) the communication flows among the involved ABACO agents expressing the Reconciler interaction pattern, that is, how the services provided by Reconciler are transformed into agent’s interactions inside the ABACO architecture. In ABACO, every Actor owns a user interface allowing human actors to select the working space associated to their current Role and to handle the related duties. Hence, a human actor, with the appropriate responsibilities can, among the others, define and activate another CM, and specifically a Reconciliation CM. Figure 5.2.6 shows the situation of a compound CM composed of n CMs and focuses on the information flows between agents in the reconciliation process involving CM1 and CM2. In Flow 1 an Actor involved in CM1 activates the Reconciliation CM. This causes the involved


144

Roles and Reconciliation Artifact to be activated too. In Flow 2 the Reconciliation Artifact retrieves from the Reconciler agent the schemes and the correspondences needed to support the current process of alignment of meanings between the two CMs. In fact, the Reconciler agent creates the schemes related to the two CMs as soon as the definition of the CMs is terminated, according to the transformation process explained in the previous section. Then the Reconciler agent maintains in its local data the correspondences which are the results of all processes of alignment of meanings between the two considered CMs. In Flow 3 the Roles involved in the Reconciliation CM start the negotiation to find a mutual alignment of meanings: each achieved agreement is input by the Manager through the Reconciler definition interface and, at the end of the negotiation, the resulting information is stored in the local data of the Reconciliation Artifact. In Flow 4 the Reconciliation Artifact passes to the Reconciler agent the new information so that the latter can update the part of its local data related to this particular pair of CMs. At this point the phase of alignment of meanings is terminated. Now this information can be used to support human actors in understanding their communication devoted to collaboration. Flow 5 corresponds to the case where a Role belonging to CM1 writes a message to be sent to a Role belonging to CM2 through the Communication interface of the Actor associated to it. Before to redirect the message, the Reconciler agent checks whether its local data contain information about the two involved CMs. In the negative case, it simply redirects the message. In the positive one it activates the algorithm that works on the most updated version of the schemes and correspondences. Flow 6: Since a compound CM can compose more than two CMs and each CM can activate several messages at the same time, the Reconciler agent has to manage all these communication in parallel. This duty is in charge of the Message Dispatcher which activates a specific thread for any communication across pairs of CMs. Each thread starts a local copy of the Reconciler algorithm to elaborate the message. Flow 7: Once the message is transformed the Message Dispatcher redirects it to the receiver agent of the other CM. Notice that Flows 5 and 7 are bi-directional because when not all conflicts can be solved, the users associated to the sender and receiver Actor/Role agents are asked by the Reconciler agent to solve ambiguities through their Communication interfaces. The above described Reconciler interaction pattern manages the possible parallelism of the definition phase with the elaboration of the messages exchanged by the reconciled CMs. In fact, the former is in charge of the appropriate Reconciliation CM whose Artifact serves as a temporary working memory while the latter is in charge of the Reconciler agent that represents a persistent memory where the reconciliation information is stored and subsequently used for the elaboration of the messages.


145

Figure 5.2.6: the Reconciler protocol expressing the integration of the Reconciler tool in ABACO

5.2.4 The current level of integration This section describes the prototype we developed to test the functionalities of the Reconciler once integrated in ABACO. Since the full implementation of ABACO is still part of our future research effort, we developed a simulator of the ABACO architecture to reproduce the functionalities required to evaluate its integration with the Reconciler. In particular, we implemented in Java three different software components which run in parallel across the network and communicate through the RMI protocol. Two components represent the user interfaces of the actors involved in collaboration; the third one contains the information about the correspondences established among the elements of the two considered schemes and the algorithm to compute the received messages, accordingly. The user interface (see Figure 5.2.7) is composed of three subparts. Starting from the top, the first one, creation/modification of the scheme, and the second one, reconciliation of schemes, opens the Reconciler scheme and the Reconciler definition interface, respectively. The bottom part is where messages are sent (sent messages) and received (received messages) during the communication phase.

USER

USER

Assumed by

Role

Actor

Manager

Actor

CM1-CM2 reco info


Assumed by

Role

Actor

Assumed by

fill in

communication

communication

exchange informationActivate CM

CM1

CM2

Compound CM

Reconciliation CM

activate thread

Reconciler Definition Interface

Message Dispatcher

CM3

CMn

USER

(1)

(3)

(5)(6)

(7)

(2),(4)

Reconciler agent

RoleRole

Role


Reconciliation Artifact Role





146

Figure 5.2.7: the user interface associated to the concrete actor agent

More specifically, during the definition phase the button Create allows users to choose from a list the Reconciler scheme of interest. When both the actors opened the pertinent schemes, one of the two can choose to open the Reconciler definition interface by clicking on the button Reconcile. The Reconciler definition interface can be opened by an actor, in mutual exclusion with the other one, only when the two schemes are opened. This starts the negotiation process among users in order to establish correspondences and solve the possible conflicts devoted to alignment of meanings. In fact, the user who opened the Reconciler definition interface (see Figure 4.2.8 in the previous chapter) is presented with the two different schemes and is in charge to enter the agreed information. When the users agree on the current level of information about alignment of meanings, the user who opened the Reconciler interface can close it. Once a new alignment of meanings is needed, either she or the other actor can open the Reconciler interface again to modify the previously established information. For what concerns communication phase, each user may open the interface devoted to compose the messages she wants to send (see Figure 5.2.8) through the button compose msg. Like in the case reported in Section 5.1, the message is a combination of free text and concepts chosen from a concept list. Hence, the interface is similar to the one showed in Figure 5.1.3 of Section 5.1: the differences concern the fact that the concepts a user can choose are not restricted to terms or definitions, but encompass all the richness of the Reconciler language used to express schemes. In order to consider the richer structure of the message, an interface allows users to add predicates in the message (see Figure 5.2.9) to express conditions on attribute values. Since in this scenario communication has the pace of a mail system than of a chat tool (as discussed in Section 5.2.2), we decided to let users choose the concepts to be used in the message only by picking up them from the displayed list without the support of the functionality of auto word completion. Moreover, this is motivated by the fact that predicates construction requires different steps and can not be performed through an automatic world completion. In any case, if the users testing the system will indicate the need for such functionality, we can simply add it by modifying the interface according to the prototype described in Section 5.1. Then the sent message is parsed in order to group the different concepts and passed to the component incorporating the algorithm. Since the elaboration of each sent message starts a separate thread, both users can simultaneously send and receive messages through their communication interfaces. When either the sender or the receiver needs to be contacted if some ambiguities can not


147

be solved by the Reconciler algorithm, they are involved both according to the strategy described in Section 5.2.2. Through the view buttons, the user can view the received messages or view the sent messages. In the first case, the original message is displayed and the user is free to get from her interface the information about the correspondence computed by the algorithm by selecting the concept of the received message she can not understand (see Figure 2.5.10). In this way the user is able to look only for the information she really needs. The communication interface provides the users with the ability to view all the received messages, and for all of them get the information elaborated by the algorithm in the same way. Figure 5.2.10 illustrates both the sent message (top-right part) containing concepts related to the Local Office scheme of the sender (see Figure 4.2.6) and the received message (bottom-left part) together with the corresponding concepts belonging to the receiver’s Central scheme (see Figure 4.2.7), according to the receiver’s information needs.

Figure 5.2.8: the interface devoted to message composition


148

Figure 5.2.9 the predicate interface

Figure 5.2.10: the exchanged message on sender’s and receiver’s communication interfaces

Chapter 6: Achievements and future work

149

Chapter 6:

Achievements and future work The research effort presented in the previous chapters is focused on how to provide actors with an effective support to manage the complexity of articulating the interdependent and distributed activities they are involved in. In fact, the distributedness of the collaborative settings increases the complexity of cooperation and reduces the effectiveness of the social mechanisms people spontaneously apply to articulate their activities. The research effort is rooted in previous works that led to define the notion of coordination mechanisms (Schmidt et al. 1996) as composed by an artifact and a protocol: they took inspiration from the practices and the artifacts people use to manage the complexity of articulation work. Coordination mechanisms can be flexibly defined according to a notation, Ariadne (Divitini et al. 2000; Schmidt et al. 1996), which provides users with categories of articulation work (CAW) representing recurrent constructs they use in their articulation effort. In order to make a coordination mechanism a computational entity, the operational semantics of Ariadne was defined (Divitini et al. 1996) in terms of a multi-agent framework, ABACO (Agent-Based Architecture for COoperation). That is, ABACO represents the meaning of the CAWs and of their compositions at any level of aggregation in terms of agents interactions. In order to enhance the previous results, our research effort was oriented towards two main goals: first, to improve the implementation of ABACO and second to integrate new functionalities devoted to support specific aspects of articulation work. The initial definition of ABACO was revisited and reformulated in terms of reactive agents by taking a systemic approach to cope with the complexity of cooperative systems (Divitini et al. to appear). ABACO is still a conceptual agent-based architecture, hence without any reference to specific implementation aspects, with the only concern to fulfill the flexibility requirements imposed by Ariadne. The new formulation introduces features that make the structure of the architecture more articulated by distinguishing groups of agents with specialized functionality (System an Application agents) and by organizing them into levels according to the functional roles of the users interacting with them (Description, Template and Instance agents). Moreover, the Agent Communication Language was redefined in order to minimize its basic constructs still preserving the previously achieved expressiveness. The new ACL was used to specify the interaction patterns characterizing agents behavior: they lead the ongoing implementation of ABACO in a concrete architecture. The choice to keep separated the ABACO conceptual architecture from the implementation details entailed by a concrete architecture was made in order to take advantages both form a top down approach (from requirements to conceptual architecture capturing them) and a bottom up approach (from a general purpose and robust concrete architecture to applications built on the basis of the conceptual one). According to this separation, we looked for concrete architectures offering suitable


150

features to fully implement the ABACO characteristics. A first prototype was developed using the Jafmas multi-agent framework (Chauhan et al. 1998). In this implementation, aggregation of agents representing coordination mechanisms were represented in terms of agents’ federations and the scripts representing agents interactions in terms of conversations. Unfortunately, the proposed prototype did not incorporate all the characteristics of ABACO especially in terms of support to “dynamicity” and incremental design that a framework with reflection capabilities could provide. In order to overcome these limits we considered the RTP (Real Time Performer) architecture (Micucci et al. submitted), which is a general purpose framework for the development of strongly modular and configurable distributed systems with reflection capabilities. In Chapter 2 we presented the mapping between ABACO and RTP on which the current implement of ABACO is based. The preliminary results (Micucci et al. 2002) show that RTP is an adequate support in order to fully implement ABACO. The identification of functionalities supporting articulation work was driven by the consideration that articulation work is a cooperative activity performed by autonomous, and still interdependent, actors. The tension between autonomy and interdependency generates conflicts that can be solved through negotiations among the involved actors. Since negotiation is a cooperative activity in turn, it can be supported by specific coordination mechanisms whose protocol represents the way in which the involved actors negotiate to agree on a solution and whose artifact, objectifying the protocol, keeps the information structure needed to support the negotiation process. This makes the integration of the new functionalities easier since ABACO allows the specialized coordination mechanism to be dynamically added as a new component of the application and incorporates features to modify the other agents in order to immediately provide the involved actors with the related functionality. In particular, we considered two kinds of negotiations characterizing two specific aspects of articulation work. The first concerns what we call alignment of protocols. Protocols can be changed in a distributed way by the pertinent actors to reflect new coordination needs for the activities in the field of work. Since they represent the more structured patterns of interaction linking together actors, their tasks and the resources they use according to the role they play, any local modification can seriously affect the interactions among the distributed actors; moreover, once the new protocol is agreed upon, the related changes have to be propagated in the distributed setting. As a consequence of the above multifaceted distributedness, changes of a protocol are managed under a regime of partial visibility, that is without knowing how the proposed change might affect other protocols. This consideration makes almost all proposed solutions to change management inapplicable in real distributed settings. Our proposal manages changes concerning the structure of the protocols, which are permanent and might influence other (partially visible) protocols. The approach is based on Buchholz’s system specification techniques (Buchholz 1996) in order to build a “kit” of functionalities supporting actors in the management of the propagation of changes. This technique is based on an innovative notion of hierarchical model, where each node contains the overall protocols as the composition of sub-parts at different levels of abstraction. This modeling approach, allows us to take into account the partial visibility each actors owns of the distributed protocol components. The integration of this new functionality in ABACO is based on the definition of a specialized CM, Modify CM, whose hierarchy Active Artifact incorporates the


151

hierarchy kit supporting the negotiation. Its implementation can be obtained as the integration of a tool managing Petri nets (GreatSPN (Chiola et al. 1995)) augmented by a module (De Cindio et al. 1985) realizing equivalence preserving reduction rules and comparing protocols according to the considered observational equivalence. The second kind of articulation work , that we called alignment of meanings, deals with another tension generated by the distributed nature of cooperation: the need to use local languages to describe the entities involved in local activities and the need to achieve a sufficient degree of mutual understanding in order to make the cooperation possible. As a consequence of this fact, communication devoted to collaboration can be expressed using concepts the actors could misunderstand, making collaboration more difficult. In this situation, alignment of meanings represent the articulation effort needed in order to let the involved actors understand each others during collaboration still using concepts described in terms of local contexts of work. Observations in the field suggested the idea that alignment of meanings has to be explicitly supported as part of the system in use through the combination of two phases that we distinguished for sake of analysis, although they are mutually interrelated: a definition phase where users are active in negotiating partial alignment of the different local descriptions; a communication phase where this effort is paid back since the supporting technology alleviates the communication problems using the collected information. On the basis of this distinction, we proposed a tool, the Reconciler, which provides the involved actors with a support to let them collaborate during the definition phase and to better understand each others during communication. This happens providing the actors with different supports. First, a language to define the local descriptions concerning their contexts of work based on the EER model. Second, a Reconciler interface letting the involved actors establish correspondences among elements of the two schemes in terms of synonymy, homonymy and equivalence, and a Reconciler algorithm which is able to use the information collected in the definition phase in order to let the communication interface show the concepts used by the sender according to the receiver’s point of view. From the implementation point of view, the Reconciler was conceived as an open tool to be used in different scenarios where communication misunderstandings may arise. In the first scenario users cannot rely on explicit descriptions of the entities belonging to their local context of work. The specific case we considered is when communication misunderstandings concern the different terminologies actors use during their collaboration according to their professions. In this situation we developed a first integration with the Reconciler tool. In definition phase, we provided the collaborating actors with a definition interface allowing them to formulate professional terms used by one of the two roles according to the skills of the other one. Then, a communication interface allows users to collaborate by exchanging messages where the professional terms are explained according to the definitions established in the previous phase. The Reconciler was tested in an experiment developed at University of California, Irvine to evaluate its usefulness and to collect from users hints to improve the design of suitable interfaces. In the second scenario users are supposed to own more structured descriptions of their local contexts of work. In this scenario, misunderstandings may arise from the different ways in which the common objects are referenced by actors belonging to different contexts during their collaboration. Hence, the definition of correspondences and the algorithm has to take into account all aspects of the structured definitions. As for the case of the alignment of protocols, the services


152

provided by the Reconciler during the definition phase are integrated in ABACO through a specific coordination mechanism which contains a Reconciliation artifact managing the information established during the negotiation process devoted to alignment of meanings. We considered the case where the local descriptions are formulated in terms of Ariadne. Hence, the Reconciler supports the cooperation of actors cooperating through different coordination mechanisms. To integrate the functionality supporting the communication phase, the Reconciler algorithm is incorporated in the External Interfaces agents in order to augment the exchanged messages with information to make the latter more comprehensible for the receiving actors. The support provided by the Reconciler is not usually part of the functionalities offered by technologies supporting cooperative work. It constitutes a step in a unexplored field of research. On the one hand, it cannot use a wide experience coming from the CSCW community and on the other hand it has to consider the application of techniques coming from other fields of research in the light of the requirements identified by the field studies of cooperative work conducted by the CSCW community. Specifically, the role of mutual learning to enhance cooperation. The Reconciler offers a support that can be improved by considering aspects with different complexity. One improvement concerns the interfaces to define the schemes and the correspondences among their elements, for instance, through the functionality provided by JOE (Mahalingam et al. 1998). JOE is a graphical editor allowing users to enter and modify (ER) schemes in a diagrammatic format and provides users with graphical abstraction mechanisms as selective viewing, graphical search, zooming and magnification in order to focus on some aspects of a scheme and to manage schemes larger than the usual screen. Other improvements concern the language both to express local descriptions and the kind of correspondences established among the elements of the different descriptions. In this view, we aim to the definition of a technology supporting alignment of meanings in Categorical work (Simone et al. 2001). Categorical work is a form of Articulation work where the effort is devoted to manage the classification of entities used during collaboration. Classification Schemes are artifacts people widely use to organize entities of various kinds. CS do not serve the only purpose of organizing entities: in so doing, they contribute to the definition and the coordination of individual and collective actions around the classified entities. In order to get this integration a first research step is the investigation of specificities of Categorical Work with respect to Articulation work. A second step concerns the extension of the current language to express schemes within the Reconciler: in fact, its expressiveness is limited to the description of entities and not on their classification. Hence, extensions are needed in order to deal with different forms of abstractions (as Inclusion, Aggregation, Association reported in (Goldstein et al. 1999)) and to incorporate in the language an algebra of (semantic) relations (Gerson 2000; Huhns et al. 1989) to support the manipulation of classification schemes through the composition of relations that preserve meaning and internal consistency of the modified classification schemes. The envisaged extensions of the language require considering new kinds of conflicts and techniques to support their representation and solution. Approaches as MAFRA (Maedche et al. 2002) which use ontologies to characterize the different kind of correspondences may enrich the information to be used by the Reconciler algorithm. Finally, the latter has to be adapted to take into account the above mentioned extensions. Other improvements concern the communication phase where the crucial problem is to provide a support in the less intrusive way. To this aim, the message interface defined in the prototype


153

provides receivers with a form of customisation of the information supplied by algorithm, since they can choose which are the concepts expressed in the sender’s message which needs an explanation, according to their current understandings. We still have to test which is the most suitable format to present this information and if all the information provided by the algorithm is really useful for the receiver, also in relation with the structure of the message. The presented results are the outcome of a conceptual and technological effort to identify adequate supports of articulation work aiming to the alignment of activities, protocols and meanings. The basic goal to achieve an integrated environment required taking into account a broad spectrum of functionalities. While their integration is achieved at the logical as well as at the specification level in the conceptual architecture, the completion of the technological integration is part of our ongoing research on top of the concrete architecture we have identified.

References

154

References Abbott, K.R., and Sarin, S.K. "Experiences with Workflow Management: Issues for the next

generation," Proceedings of the Conference on Computer Supported Cooperative Work, Chapel Hill, October 22-26, NC, USA, 1994, ACM Press, pp. 113-120.

Agha, G., and Hewitt, C. "Actors: A Conceptual Foundation for Concurrent Object-Oriented Programming," in: Reasearch Directions in Object-Oriented Programming, W. Wegner (ed.), The MIT Press, Cambridge, MA, 1987, pp. 49- 74.

Agha, G.A. ACTORS: a model of concurrent computation in distributed systems The MIT Press, Cambridge, 1988.

Agostini, A., De Michelis, G., Patriarca, S., and Tinini, R. "A Prototype of an Integrated Coordination Support System," Computer Supported Cooperative Work, The Journal of Collaborative Computing (2:4) 1994, pp 209-238.

Agostini, A., and de Michelis, G. "A Light Workflow Management System Using Simple Process Models," Computer Supported Cooperative Work, The Journal of Collaborative Computing (9:3) 2000, pp 335-363.

Aslan, G., and McLeod, D. "Semantic heterogeneity resolution in federated databases by metadata implantation and stepwise evolution," The VLDB Journal (8:2) 1999, pp 120-132.

Bailin, S., and Truszkowski, W. "Ontology negotiation between agents supporting intelligent information management," Workshop on Ontologies in Agent-based Systems (OAS 2001) - ACM Agents 2001 Conference, Montreal, 2001.

Batini, C., Lenzerini, M., and Navathe, S.B. "A comparative analysis of methodologies for database schema integration," ACM Computing Surveys (18:4) 1986, pp 323-364.

Berners-Lee, T. Weaving the Web Harper, San Francisco, 1999. Bertino, E. "Integration of Heterogeneous Data Repositories by Using Object-Oriented Views,"

First International Workshop On Interoperability in Multidatabase Systems, Kyoto, Japan, 1991. Best, E., Devillers, R., and Koutny, M. "Petri Nets, Process Algebras and Concurrent Programming

Languages," in: Lectures in Petri Nets I: basic models, W. Reisig and G. Rozenberg (eds.), Springer Verlag, Berlin, 1998, pp. 1-84.

Bonifacio, M., Bouquet, P., and Traverso, P. "Enabling Distributed Knowledge Management: Managerial and Technological Implications," UPGRADE (3:1) 2001, pp 1-7.

Borghoff, U., Bottoni, P., Mussio, P., and Pareschi, R. "Reflective Agents for Adaptive Workflows," Second International Conference on the Practical Application of Intelligent Agents and Multi-Agent Technology, London, UK, 1997, Blackpool, U. K.: The Practical Application Company Ltd, pp. 405-420.

Bouquet (ed), P.," Workshop on Meaning Negotiation held in conjunction with AAAI-2002, Edmonton, 2002.

References

155

Brauer, W., Gold, R., and Wogler, W. "Behavior and equivalences preserving refinements of Petri nets," in: LNCS 483, G. Rozenberg (ed.), 1991, pp. 1-46.

Brooks, R.A. "Intelligence without representation," Artificial Intelligence (47) 1991, pp 139-159. Buchholz, P. "A framework for the hierarchical analysis of discrete event dynamic systems,"

Universitaet Dortmund, 1996. Cai, T., Gloor, P.A., and Nog, S. "DartFlow: A Workflow Management System on the Web using

Transportable Agents," Dartmouth Technical Report PCS-TR96-283, 1996. Carstensen, P.H. Computer Supported Coordination Department of Computer Science, Roskilde

University, Roskilde, Denmark, 1996, p. 248. Castano, S., and De Antonellis, V. "ARTEMIS: Analysis and Reconciliation Tool Environment for

Multiple Information Sources," Dipartimento di Elettronica per l'Automazione. Universita' degli Studi di Brescia, Brescia - Italy, 1999.

Chauhan, D. "JAFMAS: a Java-based agent framework for multi-agent system development and implementation," in: ECECS Department, University of Cincinnati, Cincinnati, Ohio, 1997.

Chauhan, D., and Baker, A. "JAFMAS: a multi-agent application development system.," Second International Conference on Autonomous Agents (Agents'98), Minneapolis, USA, 1998, ACM Press.

Chen, P.P. "The entity-relationship model: Toward a unified view of data," ACM Transactions on Database Systems (1:1) 1976, pp 9-36.

Chiola, G., Franceschinis, G., Gaeta, R., and Ribaudo, M. "GreatSPN 1.7: Graphical Editor and Analyzer for Timed and Stochastic Petri Nets," Performance Evaluation, special issue on Performance Modeling Tools (24:1&2) 1995, pp 47-68.

Conklin, J., and Begemann, M.L. "gIBIS: a Hypertext tool for argumentation," ACM Transactions on Office Information Systems (6:4) 1988, pp 303-331.

De Cindio, F., De Michelis, G., Pomello, L., and Simone, C. "Exhibited-behavior equivalence and organizational abstraction in concurrent systems design," 5th Intern. Conference on Distributed Computing Systems, Denver CO USA, 1985, Computer Society Press, pp. 486-495.

Desel, J., and Reisig, W. "Place/Transition Petri Nets," in: Lectures in Petri Nets I: basic models, W. Reisig and G. Rozenberg (eds.), Springer Verlag, Berlin, 1998, pp. 122-174.

Divitini, M., Simone, C., Schmidt, K., and Carstensen, P.H. "A multi-agent approach to the design of coordination mechanisms," First International Conference on Multi-Agent Systems, San Francisco, CA, USA, 1995.

Divitini, M., Simone, C., and Schmidt, K. "ABACO: Coordination Mechanisms in a Multi-agent Perspective," Proceedings of the 2nd International Conference on the Design of Cooperative Systems, Juan-les-Pins, France, June 12-14, 1996, 1996, INRIA Press, pp. 103-122.

Divitini, M., and Simone, C. "Supporting different dimensions of workflow adaptability," Computer Supported Cooperative Work, The Journal of Collaborative Computing (9:3) 2000, pp 365-397.

Divitini, M., Sarini, M., and Simone, C. "Reactive Agents for a systemic approach to the construction of Coordination Mechanisms," in: Agents supported Cooperative work, E. Churchill and Y. Yiming (eds.), Kluwer Academic Press, to appear.

Dix, A. "An agent based architecture for groupware applications," Computer Science Department, University of York, 1993.

References

156

Donatelli, S., Sarini, M., and Simone, C. "Negotiating propagation of changes in interorganizational workflows," International Journal of Computer Systems Science and Engineering (15:5) 2000.

Dourish, P., Holmes, J., MacLean, A., Marqvardsen, P., and Zbyslaw, A. "Freeflow: Mediating Between Representation and Action in Workflow Systems," ACM Conference on Computer Supported Cooperative Work - CSCW'96, Boston, Mass. (USA), 1996, ACM Press, pp. 190-198.

Dourish, P., Lamping, J., and Rodden, T. "Building Bridges: Customisation and Mutual Intelligibility in Shared Category Management," ACM Conference on Supporting Group Work GROUP'99, Phoenix, AZ, 1999.

Ellis, C.A., Gibbs, S.J., and Rein, G.L. "Groupware: Some issues and experiences," Communications of the ACM (34:1), January 1991, pp 38-58.

Ellis, C., Keddara, K., and Rozenberg, G. "Dynamic Change within Workflow Systems," 1995 conference on Organizational Computing Systems, San Josè, CA, 1995, pp. 10-21.

Elmasri, R., and Navathe, S.B. Foundamental of Database Systems (second edition) Benjamin-Cummings Publ. Co., Inc, Redwood City CA, 1994.

Ferber, J., and Muller, J. "Influences and Reaction: A Model of Situated multiagent Systems," in: Proceedings of 2nd International Conference on Multiagent Systems, Nara, Japan, 1996.

Fisher, G., Lemke, A.C., McCall, R., and Morch, A. "Making Argumentation Serve Design," Human-Computer Interaction (6:3&4) 1991, pp 393-419.

Flint, W. "Plant your data in a ternary search tree (create an English dictionary that checks spelling and matches words as you type)," in: Java World http://www.javaworld.com/javaworld/jw-02-2001/jw-0216-ternary.html, 2001.

Flores, F., Graves, M., Hartfield, B., and Winograd, T. "Computer Systems and the Design of Organizational Interaction," ACM Transactions on Office Information Systems (6:2) 1988, pp 153-172.

Fowler, M., and Scott, K. UML Distilled. Second Edition Addison-Wesley, 2000. Gaver, W., Moran, T., MacLean, A., Lovstrand, L., Dourish, P., Carter, K., and Buxton, W.

"Realizing a video environment:EuroPARC's RAVE system," ACM Conference on Human Factors in Computing Systems-CHI'92, Monterey, CA (USA), 1992, ACM Press, pp. 27-35.

Genesereth, M.R., and Ketchpel, S.P. "Software Agents," Communication of the ACM (37:7) 1994, pp 48-54.

Gerson, E.M., and Star, S.L. "Analyzing the due process in the workplace," ACM Transactions on Office Information Systems (4:3) 1986, pp 447-465.

Gerson, E.M. "Different parts for different smarts: partonomies and the organization of work," Workshop on Classification Schemes in Common Information Spaces, Lyngby, Denmark, 2000.

Glance, N.S., Pagani, D.S., and Pareschi, R. "Generalized Process Structure Grammars (GSPS) for flexible representation of work," Conference on Computer Supported Cooperative Work -CSCW'96, Boston (USA), 1996, ACM Press, pp. 180-189.

Goh, C.H., Bressan, S., Madnick, S., and Siegel, M. "Context Interchange: New Features and Formalisms for the Intelligent Integration of Information," ACM Transactions on Information Systems (17:3) 1999, pp 270-293.

References

157

Goldstein, R.C., and Storey, V.C. "Data abstractions: Why and how?," Data and Knowledge Engineering (29:3) 1999, pp 293-311.

Hindus, D., Ackerman, M.S., Mainwaring, S., and Starr, B. "Thunderfire: a field study of audio-only media space," Conference on Computer-Supported Cooperative Work-CSCW'96, Boston, Mass. (USA), 1996, ACM Press, pp. 238-247.

Holowczak, R.D., and Wen-Syan, L. "A survey on attribute correspondence and heterogeneity metadata representation," First IEEE Metadata Conference, Silver Spring, Maryland, 1996.

Huhns, M., and Stephens, L.M. "Plausible Inferencing Using Extended Composition," 11th International Joint Conference on Artificial Intelligence, Detroit, MI, 1989, pp. 1420-1425.

Isaacs, E., Walendowsky, A., Whitaker, S., and Schiano, D.J. "The Character, Functions, and Styles of Instant messaging in the workplace," CSCW2002, New Orleans, 2002, ACM Press, pp. 11-20.

Kahler, H., Morch, A., Stiemerling, O., and Wulf, V. (eds.) Tailorable Systems and Cooperative Work, special issue of Computer Supported Cooperative Work, The Journal of Collaborative Computing. Vol. 9, no. 1. Kluwer Academic Publishers, 2000.

Kahng, J., and McLeod, D. "Dynamic classification ontologies: mediation of information sharing on cooperative federated database systems," in: Cooperative Information Systems, M.P. Papazoglou and G. Schlagter (eds.), Academic Press, San Diego, 1998.

Kambayashi, Y., Rusinkiewicz, M., and Sheth (eds), A. "First International Workshop On Interoperability in Multidatabase Systems," Kyoto, Japan, 1991, IEEE CS Press.

Kaplan, S.M., Tolone, W.J., Bogia, D.P., and Bignoli, C. "Flexible, Active Support for Collaborative Work with Conversation Builder," ACM Conference on Computer Supported Cooperative Work - CSCW'92, Toronto (Canada), 1992, ACM Press, pp. 378-385.

Karsenty, L., and Brezillon, P. "Cooperative problem solving and explanation," International Journal of Expert Systems with Applications (8:4) 1995, pp 445-462.

Kent, W. Data and Reality North Holland, New York, 1978. Khedro, T., and Genesereth, M.R. "Modeling Multiagent Cooperation as Distributed Constraint

Satisfaction Problem Solving," 11th ECAI, 1994, John Wiley & Sons, pp. 249-253. Klein, M., Dellarocas, C., and Bernstein, A. (eds.) Adaptive Workflow Systems, special issue of

Computer Supported Cooperative Work, The Journal of Collaborative Computing. Vol. 9, No. 3--4. Kluwer Academic Publishers, 2000.

Klein (editor), M. "Special Issue on Adaptive Workflow Systems," Computer Supported Cooperative Work, The Journal of Collaborative Computing (9:3-4) 2000.

Litwin, W. MSQL: A Multidatabase Language Elsevier Science Publishing, 1989. Loucopoulos, P., and Zicari (Eds), R. Conceptual Modeling, Databases, and CASE (an integrated

view of information systems development) John Wiley & Sons, Inc., 1992. Maedche, A., Motik, B., Silva, N., and Volz, R. "MAFRA - A MApping FRAmework for

Distributed Ontologies," EKAW 2002, Siguenza, Spain, 2002a, Springer, pp. 235-250. Maedche, A., and Staab, S. "Measuring Similarity between Ontologies," EKAW 2002, Siguenza,

Spain, 2002b, Springer, pp. 251-263.

References

158

Mahalingam, K., and Huhns, M.N. "Ontology Tools for Semantic Reconciliation in Distributed Heterogeneous Information Environments," Intelligent Automation and Soft Computing: An International Journal (special issue on Distributed Intelligent Systems)) 1998.

Malone, T.W., Grant, K.R., Lai, K.-Y., Rao, R., and Rosenblitt, D. "Semistructured Messages Are Surprisingly Useful for Computer-Supported Coordination," ACM Transactions on Office Information Systems (5:2) 1987, pp 115-131.

Malone, T.W., and Lee, J. "How Can Groups Communicate When They Use Different Languages? Translating Between Partially Shared Type Hierarchies," Conference on Office Information Systems, Palo Alto, CA, 1988, pp. 22-29.

Malone, T.W., Grant, K.R., and Lai, K.-Y. "Agents for Information Sharing and Coordination: A History and Some Reflections," in: Software Agents, J.M. Bradshaw (ed.), AAAI & MIT Press, Menlo Park, CA, 1997, pp. 109-144.

Mark, G., Fuchs, L., and Sohlenkamp, M. "Suppoting groupware conventions through contextual awareness," ECSCW'97, Lancaster, 1997, Kluwer Academic Publisher.

Mark, G., Gonzalez, V., Sarini, M., and Simone, C. "Reconciling different perspectives: an experiment on technology support for articulation," COOP2002, Saint Raphael (FR), 4-7 June, 2002.

Micucci, D., Savigni, A., and Tisato, F. "Environmental Monitoring Systems: the Kaleidoscope architecture and the RAID case," Como, Italy, 2001.

Micucci, D. "Exploiting the Kaleidoscope architecture in an industrial environmental monitoring system with heterogeneous devices and a knowledge-based supervisor," SEKE 2002 Conference, Ischia, Italy, 2002.

Micucci, D., Sarini, M., Simone, C., Tisato, F., and Trentini, A. "Conceptual and concrete architectures in the design of CSCW applications," Workshop WOA2002- Dagli oggetti agli agenti, Milano, Italy, 2002.

Micucci, D., Trentini, A., and Tisato, F. "A connector-based approach for controlled data distribution in RTP architecture," 1st Workshop on Data Distribution in Real Time Systems (held in conjunction with ICDCS2003), Providence, Rhode Island, USA, submitted.

Milner, R. A calculus of Communicating systems Springer-Verlag, Berlin Heidelberg, 1980. Norman, D.A. The Design of Everyday Things Doubleday, New York, 1990. Nunamaker, J., Briggs, R., Mittleman, D., Vogel, D., and Balthazard, P. "Lessons form a dozen

years of Group Support Systems research: a discussion of lab and field findings," Journal of Management Information Systems (13:3) 1997, pp 163-207.

O'Brien, P.D., and Wiegand, M.E. "Agent based process management: applying intelligent agents to workflow," Knowledge Engineering Review (13:2) 1998.

Papadopoulos, G.A., and Arbab, F. "Coordination Models and Languages," Advances in Computers (46) 1998.

Papazoglou, M.P. "Unravelling the Semantics of Conceptual Schemas," Communication of the ACM (38:9) 1995, pp 80-94.

Papazoglou, M.P. "Agent-oriented technology in support of e-business," Communications of the ACM (44:4) 2001, pp 71-76.

References

159

Peckham, J., and Maryanski, F. "Semantic Data Models," ACM Computing Surveys (20:3), September 1988 1988, pp 153-189.

Pomello, L., Rozenberg, G., and Simone, C. "A survey of Equivalence Notion for Nets based Systems," in: Advances in Petri Nets- Lectures in Computer Science 609, G. Rozenberg (ed.), Springer Verlag, Berlin, 1992, pp. 410-472.

Robinson, M. "Design for Unanticipated Use ..." Third European Conference on Computer- Supported Cooperative Work, Milano, Italy, 13-17 September 1993, 1993, Kluwer Academic Publishers, pp. 187-202.

Rodden, T., and Blair, G. "CSCW and Distributed Systems: the problem of control," Second European Conference on CSCW, Amsterdam, 1991, Kluwer Academic Publisher.

Russell, S., and Norvig, P. Artificial Intelligence: A Modern Approach Prentice Hall, 1995. Sandholm, T., and Lesser, V. "Issues in Automated Negotiation and Electronic Commerce:

Extending the Contract Net Framework.," in: Readings in Agents, M. Huhns and M. Singh (eds.), Morgan Kaufmann Publishers, 1997.

Sarini, M., and Simone, C. "Recursive Articulation work in Ariadne: the alignment of meanings," COOP2002, Saint Raphael, France, 2002, pp. 191-206.

Savigni, A., and Tisato, F. "Kaleidoscope. A reference Architecture for Monitoring and Control Systems," First Working IFIP Conference on Software Architecture (WICSA), San Antonio, TX, USA, 1999.

Schmidt, K. "Riding a Tiger, or Computer Supported Cooperative Work," Second European Conference on CSCW, Amsterdam, 1991, Kluwer Academic Publisher, pp. 1-16.

Schmidt, K., and Bannon, L. "Taking CSCW Seriously: supporting Articulation Work," Computer Supported Cooperative Work, The Journal of Collaborative Computing (1:1) 1992, pp 7-40.

Schmidt, K., and Simone, C. "Coordination Mechanisms: Towards a conceptual foundation for CSCW systems design," Computer Supported Cooperative Work, The Journal of Collaborative Computing (5:2-3) 1996, pp 155-200.

Schmidt, K. "Of maps and scripts: the status of formal constructs in cooperative work," GROUP 97, Phoenix Arizona USA, 1997, ACM Press, pp. 138-145.

Shaw, M., and Garlan, D. Software architecture. Perspectives on an emerging discipline. Prentice Hall, 1996.

Simone, C., and Ajmone Marsan, M. "The application of EB-equivalence rules to the structural reduction of GSPN models," Journal of Parallel and Distributed Computing (15) 1992, pp 296-302.

Simone, C., and Schmidt, K. "Taking the distributed nature of cooperative work seriously," 6th Euromicro Workshop on Parallel and Distributed Processing, Madrid, Spain, 1998, IEEE Computer Society, pp. 295-301.

Simone, C., and Divitini, M. "Integrating Contexts to Supporting Coordination: The CHAOS Project," Computer Supported Cooperative Work, The Journal of Collaborative Computing (8:3) 1999a, pp 239-283.

Simone, C., Mark, G., and Giubbilei, D. "Interoperability as a means of articulation work," WACC'99, San Francisco, 1999b, ACM Press, pp. 39-48.

References

160

Simone, C., and Sarini, M. "Adaptability of Classification schemes in Cooperation: what does it mean?," ECSCW 2001, Bonn (D), 2001, Kluwer Academic Publishers.

Sluizer, S., and Cashman, P. "XCP. An experimental tool for supporting office procedures.," First International Conference on Office Automation, 1984, IEEE-CS Press, pp. 73-80.

Smith, R.G. "The Contract Net Protocol: High Level Communication and Control in a Distributed Problem Solver," IEEE Trans on Computer (29:12) 1980, pp 1104-1113.

Star, S.L., and Griesemer, J.R. "Institutional Ecology, 'Translations' and Boundary Objects: Amateurs and Professionals in Berkeley's Museum of Vertebrate Zoology, 1907-39," Social Studies of Science (19) 1989, pp 387-420.

Suchman, L.A. Plans and situated actions. The problem of human-machine communication Cambridge University Press, Cambridge, 1987.

Tarumi, H., Kida, K., Ishiguro, Y., Yoshifu, K., and Asakura, T. "WorkWeb Systems - Multi Workflow Management in a Multi Agent System," SIGGROUP 1997, Phoenix, Arizona USA, 1997, ACM Press, pp. 299-308.

Tenenbaum, J.M., Weber, J.C., and Gruber, T.R. "Enterprise integration: Lessons from SHADE and PACT.," in: Proc. 1st Int. Conf on Enterprise Integration Modelling, 1992, pp. 356-369.

Tokoro, M. "The Society of Objects," in: Readings in Agent, M.P. Singh (ed.), Morgan Kaufmann Publishers, San Mateo, CA, 1998, pp. 421-429.

Turoff, M., and Hiltz, S.R. "Computer Based Delphi Processes," in: Gazing Into the Oracle: The Delphi Method and Its Application to Social Policy and Public Health, M. Adler and E. Ziglio (eds.), Kingsley Publishers, London, 1995, pp. 56-88.

van der Aalst, W. "Verification of workflow nets," in: Proc. of the 18th Intern. Conference on Applications and Theory of Petri Nets, P. Azema and G. Balbo (eds.), Springer-Verlag, Berlin Heidelberg, 1997, pp. 407-426.

van der Aalst, W.M.P., and Basten, T. "Inheritance of Workflows: An approach to tackling problems related to changes," Computing Science Reports 99/06, Eindhoven University of Technology, Eindhoven, 1999 (wwwis.win.tue.nl/~wsinwa/publications.html) 1999.

van der Aalst, W., Desel, J., and Oberweis, A. (eds.) Business Process Management - Models, Techniques and Empirical Studies. Springer Verlag, Berlin, 2000.

van Glabbeek, R. "The Linear Time -Branching Time spectrum," in: Concur'90, Lncs 458, J.C.M. Beaten and J.W. Klop (eds.), Springer Verlag, 1990, pp. 278-297.

van Reijswoud, V.E., Mulder, B.F., and Dietz, J. "Communicative action-based business process and information systems modelling with DEMO," Information System Journal (9) 1999, pp 117-138.

Ventrone, V., and Heiler, S. "Some Advice for Dealing with Semantic Heterogeneity in Federated Database Systems," Database Colloquium-AFCEA, San Diego, 1994.

Victor, F., and Sommer, E. "Supporting the Design of Office Procedures in the DOMINO System," in: Studies in Computer Supported Cooperative Work. Theory, Practice and Design, J.M. Bowers and S.D. Benford (eds.), North-Holland, Amsterdam, 1991, pp. 119-130.

Wache, H., Vogele, T., Visser, U., Stuckenschmidt, H., Schuster, G., Neumann, H., and Hubner, S. "Ontology-Based Integration of Information - A Survey of Existing Approaches," IJCAI-01 Workshop: Ontologies and Information Sharing, Seattle, WA, 2001, pp. 108-117.

References

161

Wand, Y., Storey, V.C., and Weber, R. "An Ontological Analysis of the Relationship Construct in Conceptual Modeling," ACM Transactions on Database Systems (24:4) 1999, pp 494-528.

Werger, B.B., and Mataric, M. "From insect to Internet: Situated control for networked robot teams," Annals of Mathematics and Artificial Intelligence - special issue on Ant Robotics (31:1-4) 2001, pp 173-197.

Wiederhold, G. "Mediators in the architecture of future information systems," IEEE Computer (25:3) 1992, pp 38-49.

Winograd, T., and Flores, F. Understanding Computers and Cognition: a new foundation for design Addison Wesley, Reading MA, 1986.

Wulf, V. "Storing and retrieving documents in a shared workspace: experiences from the political administration," INTERACT'97, 1997, Chapman & Hall, pp. 469-476.

Wulf, V., Pipek, V., and Pfeifer, A. "Resolving function-based conflicts in groupware systems," AI&Society (15) 2001, pp 233-262.

Zacklad, M., and Rousseaux, F. "Modelling Co-operation in the Design of Knowledge Production Systems: the MadeIn'Coop Method - An example in the field of C3I systems," COOP'95, Juan-les-Pins (Fr), 1995, pp. 1-19.

Appendix A: The Ariadne categories

162

Appendix A.

The Ariadne categories The basic Categories of Articulation Work (CAW) considered in Ariadne are: Role, Actor, Task, Activity, Action, Interaction, Resource. In addition, Ariadne considers two additional categories: Active Artifact and Protocol. CAWs are described in terms of sets of pairs <attribute name: attribute type>. The attributes can be grouped in general as follows:

− name) an attribute, called name, whose value identifies the specific instance of a category; − content) attributes describing the informational content of the categories. The most important

one is description: it allows the definition of the category informational content in terms of a ERR scheme that, for some category, collapses into a simple data-frame (that is, pairs <slot name: slot type>);

− reference) attributes representing references to other CAWs or other CMs, allowing so compositionality, expressing each element of Ariadne in terms of its relation to other elements;

− OC-ref) attributes representing relationships with the Organizational Context: defined by, adapted by and assigned by Roles, possibly applying suitable policies. A policy is a set of rules or a reference to another CM.

− communication) two attributes expressing the communication capabilities of the category: a) coordination, expressing the capability of the category to communicate with the other CAWs or CMs to provide to them information about its current state or, conversely, to obtain information about their current state. The semantic of coordination implies that the related message must be sent or received in order to fulfil the rules of the CM; b) awareness, expressing the capability of the category to make other CAWs aware both of its internal state and of communication received from its environment. The semantic of an awareness communication follows the classical broadcast protocol: a sent message can be disregarded by the receivers.

In the description of the CAWs we denote with X* a finite sequence of item


163

Attribute name Attribute type name (name) role-id description (content) data-frame responsible for (ref) Resource* responsible for (ref) Task* responsible for (ref) CM* involved in (ref) CM* assumed by (ref) Actor* defined by (OC-ref) <Role, policy> adapted by (OC-ref) <Role, policy> assigned by (OC-ref) <Role, policy> coordination (communication) <condition, out msg>* awareness (communication) <condition, out msg>* Tab A.1: the Role category

where assigned by is an asymmetric attribute needed to handle the asymmetric assignment Role-Actor. Attribute name Attribute type name (name) actor-id personal data (content) data-frame locality (content) data-frame skills (content) data-frame assigned to (ref) Role* initiator of (ref) Activity* doer (ref) Action awareness (communication) <condition, out msg>* Tab A.2: the Actor category

To accomplish a Task, an Actor has to start Activities (attribute initiator of) and to do Actions (attribute doer). The Action that an Actor is doing is not necessarily part of one of the Activities she started; an Actor, in fact, can start an Activity and delegate other Actors to do the Actions that are part of the Activity.


164

Attribute name Attribute type name (name) task-id description (content) data-frame preconditions (content) condition priority (content) value postconditions (content) condition in-triggers (communication) in msg* under responsibility of (ref) Role supervised by (ref) <Role, policy> has allocated (ref) Resource* realised by (ref) Activity* assigned by (OC-ref) <Role, policy> defined by (OC-ref) <Role, policy> adapted by (OC-ref) <Role, policy> awareness (communication) <condition, out msg>* Tab A.3: the Task category

In-triggers are coordination events that must be listen to before the Task can start. The Role responsible for the Task is the one that activates and accomplishes the task, whereas the Role in the attribute supervised by must be contacted in case of exceptions. Attribute name Attribute type name (name) activity-id description (content) data-frame initiated by (ref) Actor in, out, used (ref) Resource* realises (ref) Task structure of (ref) Action*, Interaction* awareness (communication) <condition, out msg>* Tab A.4: the Activity category


165

Attribute name Attribute type name (name) action-id description (content) data-frame/f.o.w. procedure realises (ref) Task initiated by (ref) Actor done by (ref) Actor in, out, used (ref) Resource* in-triggers (communication) in-msg precondition (content) condition priority (content) value postcondition (content) condition state (content) state-value awareness (communication) <condition, out msg>* Tab A.5: the Action category

where state-value belongs to {waiting, ready, started, under-execution, concluded, error}. Field of Work (f.o.w.) procedure refers to applications/practices that belong to the target environment. Attribute name Attribute type name (name) interaction-id belongs to/realises (ref) Protocol/Activity sender (ref) Role(Actor)* message (content) any content attribute * receiver (ref) Role(Actor)* type (content) (must, may) awareness (communication) <condition, out msg>* Tab A.6: the Interaction category

An Interaction can be a step of a Protocol: in this case the sender(s) and the receiver(s) are Roles. An interaction can be a step of an Activity: in this case it realises a Task and the sender(s) and the receiver(s) are Actors. The attribute type indicates if the communication is synchronous (must) or asynchronous (may).


166

Ariadne makes available four different types of Resources: Informational, Material, Technical and Infrastructural Resources. They share the same structure but have different values in some attributes. Attribute name Attribute type name (name) info-resource-id link (ref) <relation, CAW>* description (content) scheme under responsibility of (ref) Role allocated to (ref) Task* needed/produced/used by(ref) Activity/Action usability (content) <access-type, policy> location (content) data-frame state (content) state-value assigned by (OC-ref) <Role, policy> defined by (OC-ref) <Role, policy> adapted by (OC-ref) <Role, policy> coordination (communication) <condition, out msg>* awareness (communication) <condition, out msg>* Tab A.7: the Informational Resource category

where: access-type belongs to {read, write, copy, move, transfer, load, unload}; state-value belongs to {allocated, in-use, in-use-by}. The attribute link indicates all the possible relations between the Informational Resource and other categories. The Role responsible for the Resource, when it allocates a Resource to a Task, must follow the policies specified by the usability attribute. Description describes the informational content of a Resource in terms of EER schemes. In the case of Material Resource access-type belongs to {reserve, consume, move, place} while state-value belongs to {allocated, in-use, in-use-by}. In the case of Technical Resource and Infrastructural Resource access-type belongs to {reserve, move, place} while state-value belongs to {idle, allocated, in-use, out-of-order}. In both cases, the description is a data-frame.


167

Attribute name Attribute type name (name) active-artifact-id description (content) scheme access rights (content) <Role, type>* defined by (OC-ref) <Role, policy> adapted by (OC-ref) <Role, policy> coordination (communication) <condition, out msg/function>* awareness (communication) <condition, out msg/function>* Tab A.8: the Active Artifact category

where type belongs to {update , read}. In addition to the other cases, here coordination can also activate some internal function as a consequence of the fulfillment of some condition expressed in terms both of received messages and of internal data. Attribute name Attribute type name (name) protocol-id description (content) Partial order relation ⊆

CAWs x (CAWs ∪ {ε}) defined by (OC-ref) <Role, policy> adapted by (OC-ref) <Role, policy> Tab A.9: the Protocol category

A protocol is a compound entity obtained from the composition of CAWs by means of formal structures (attribute description) to reflect the fact that in a cooperative arrangement procedures are usually expressed in terms of relations among CAWs. Ariadne does not propose a unique approach to the representation of procedures. Then the selection of the CAWs and of their relations is defined by the grammar the designer of the CM wants to adopt for its definition. Attribute name Attribute type name (name) CM-id coordinative information (ref) Active Artifact behavior (ref) Protocol* under responsability of (ref) Role defined by (OC-ref) <Role, policy> modified by (OC-ref) <Role, policy> Tab A.10: the CM

A coordination mechanism (CM) is described as the aggregation of a selection of CAWs, Protocol and Active Artifact.


168

Elemental CMs can be combined to form compound CMs. Ariadne exploits the notion of interface to manage interactions among the different CMs belonging to the same compound CM.

Date post:	18-Feb-2019
Category:	Documents
Upload:	vodan
View:	217 times
Download:	0 times

UNIVERSITA’ DEGLI STUDI DI TORINO Dottorato di Ricerca...

Documents