Keywords

1 Introduction

Cooperation and collaboration are two ambiguous notions that have different meanings across domains, and sometimes from one author to another. The difference between these two concepts seems related to the sharing of the goal in the interaction. Collaboration means to “work together”, i.e. a joint development of a negotiated and consensual solution, thus it is a task realization in different ways. Cooperation means to “operate together”, it is a negotiated division of the task realization among participants (a common goal but autonomous actions) and a pooling by the assembling of each subtask realization in a linear way, each participant has to handle a definite part of the shared task realization. Coordination is the technical organization of the different elements of a task realization to enable participants to work together effectively according to a plan. If coordination has a relatively well-accepted definition across disciplines and types of approaches, such as, cognitive (AI, psychology, etc.) or technology (CSCW, interface design, etc.) [2, 7, 9], it is not the case of collaboration and cooperation. In this paper, we retain that collaboration refers to work together while cooperation is to operate together.

We are interested in bringing the concept of context to group tasks as the relevant knowledge, regarding the task, that each actor possess and shares with the rest of the group, as this would help understanding the way the job gets actually done, which will bring benefits to decision makers and to groupware designers. Commonly, in the technology research field, context is restricted to a set of physical measurements that denotes the state of the environment (e.g., location, and temperature). Our study is based on the Contextual-Graphs formalism [5], which offers a uniform representation of elements of knowledge, reasoning, and context. This formalism has been used by Fan et al. [8] as a contextual complement to scientific workflows in virtual screening, demonstrating that it is more important to model a task realization than its theoretical model. However, the Contextual-Graphs formalism was conceived for task realizations involving a single actor. Therefore, we want to extend it to support group tasks, which represents a different challenge, as each actor involved realizes a set of subtasks in an ordered way (e.g., an actor is able to perform a subtask after another actor has completed theirs), such an actor also needs to share with the rest of the group those elements that are considered important for the group task realizations (i.e. shared context). The interaction between actors evolves, since it can start with superficial communication, but within the task realization development, it could become a strong engagement of the actors. In order to represent such an interaction, we have explored different ways of modeling the example of the paper submission in a contextual model based on the Contextual-Graphs formalism. From this analysis, it was found out that it is necessary to create a mechanism that establishes turns between actors. During each turn, an actor realizes a set of subtasks, and updates the shared context so the next actor understands the state of the task and is able to contribute to the group task.

This paper is organised as follows. In Sect. 2, the Contextual-Graphs formalism as a foundation of the paper is described. Then, in Sect. 3, a series of definitions regarding the levels of interaction among people working together are presented. In Sect. 4, an analysis of the common known paper submission process [1] is introduced in order to find a suitable way to represent group tasks through the Contextual-Graphs formalism. After exploring some options, we propose a mechanism for turns to manage the flow of this type of group tasks in Sect. 5. Then, in Sect. 6, the practice tree implementation as a way to facilitate the visualization of the exchange of turns is introduced. Finally, the conclusions are presented in Sect. 7.

2 On the Contextual-Graphs Formalism

Pomerol and Brézillon [10] define context as the sum of: (1) the contextual knowledge, which is all the knowledge relevant for a person in a given decision problem, (2) the external knowledge, corresponding to the rest of the knowledge that is not important for the current situation, and (3) the proceduralized context, which is a part of the contextual knowledge that becomes important at a specific step of the decision problem. Based on this context definition, Brézillon [4] introduces the Contextual-Graphs (CxG) formalism for obtaining a uniform representation of elements of knowledge, reasoning and context. Thus, a contextual graph represents the realization of a task, each path is a practice developed by an actor in a particular context for realizing the task. A contextual graph represents the accumulated experience of one or several actors realizing the same task.

The elements of a contextual graph are: actions, contextual elements, activities and parallel action groupings. An action is the building block of contextual graphs. A contextual element is a pair of nodes, a contextual and a recombination one; the former has one input and N outputs (branches) corresponding to the N instantiations of the contextual element; the latter is [N, 1] and represents the moment at which the instantiation of the contextual element does not matter anymore. An activity is a graph by itself that is identified by actors because it appears in the same way in different problem solving processes. An activity is defined in terms of the actor, situation, task and a set of actions. Finally, a temporal branching for action grouping expresses the fact that several set of actions can be realized in parallel or in a sequential way, no matter the order.

A contextual element corresponds to an element of the nature that must be analyzed. The value taken by a contextual element when the focus is on it, its instantiation is considered as long as the situation is under analysis. The proceduralized context evolves dynamically during a practice development by addition (at the contextual node) or removal (at the recombination node) of a contextual element during the progress of the focus. Moreover, for group tasks, the shared context is formed by persistent (known by all the actors) contextual elements introduced by an actor, and eventually accepted by others after negotiation. Thus, contextual elements can be used as a way to manage turns among actors involved in a group task, as their instantiation would denote whose turn is next. The working context corresponds to all the contextual elements of a Contextual Graph and their instantiations [3].

3 Levels of Interaction

In the Computer Supported Cooperative Work (CSCW) research field, the group awareness need has been identified since early works as a requirement for applications supporting non-collocated teams [6], since variables such as presence, availability and activity of each member of the team need to be known to coordinate activities and achieve collaboration. Thus, many applications incorporated the availability and presence modes (e.g., busy, online, available, away), to let others users know if the interaction they require could be possible at a specific moment. Then, with the evolution of the field, the creation of applications for supporting not only non-collocated collaboration, but also collocated one, and the increasing attention to the Ubiquitous Computing field [12], arose a new way of thinking about context, since current authors have embraced and developed the view of context as any variable that characterize a situation [11]. Nowadays, the goal is to customize the response of an application based on the environment that surrounds the user and the user themselves. Thus, the most popular variables considered in a group application are presence, availability, activity, location, time and interests. This narrowed vision of context in CSCW is due to researchers concern on building applications limited to physical and environmental features. However, group tasks can be studied at another level, by focusing on human interaction and not just in the applications technical aspects.

We propose a deeper analysis of the interaction among users involved in a group task. Thus, in Table 1, we illustrate through a set of definitions that there is a large spectrum of collaboration/cooperation, which always involves a degree of coordination. In Table 1 we present six levels in this spectrum, namely: the task level, the task realization level, the actor level, the activity level, the team level, and the planning level. For each level we identify the actors’ commitment degree, then we propose a visual guide for each level of interaction, in which rectangles depict tasks (i.e., a task can consist of several actions) performed by a single participant at a specific moment. Finally, in the last column of the table, we use well-known collaborative applications as examples to illustrate that although they are all known as collaborative applications, they are targeted to provide support to one or several levels of interaction.

Table 1. Interaction between two actors’ tasks
Full size table

As mentioned before, most works in the CSCW field are focused on building applications, which is probably the reason why an agreement about the collaboration and cooperation concepts has not been reached yet. However, our objective is to provide support at a lower level, i.e. by understanding the way people actually realize tasks together. In Table 1, we see that it is important to differentiate the level of interaction among actors realizing a task. Since, the over simplification of using the term collaboration and cooperation to refer to any task group leads to lose the essence of the interactions, in which the shared context, the type of turns, and the degree of collaboration/cooperation varies significantly from one situation to another. Our conceptual framework allows to capture some contextual features related to the management of turns that otherwise would not be visible.

4 The Paper Submission Example as a Group Task

The submission of a scientific paper to a journal is a well-known process in the research community. In short, an author submits a paper to the editor of a journal. The editor may either accept the paper for reviewing, or reject it due to mismatch between the scope of the journal and the topics covered in the paper. An accepted paper is sent for evaluation to (at least) two reviewers. The reviewers read the submitted paper and provide their feedback before a deadline assigned by the editor. The reviewing process is an individual task that the reviewer performs based on his personal knowledge, expertise and point of view. Once the reviews are received, the editor makes a decision by comparing the reviewers’ evaluations. This process can be long, so the editor must evaluate their options and time constraints in order to decide the tactics to choose. If the paper is not rejected, the editor could: (a) conditionally accept the paper by demanding to the authors an improved version, which is verified by the editor or the reviewers, or (b) accept the paper with the minimal suggested changes. If the final editor’s decision is to reject the paper, the author is notified with reviewers’ comments. Otherwise, after receiving the new version, the editor sends the accepted submission to the publisher for publication. The paper submission process requires interaction among different actors with different roles: author, editor, reviewers and publisher. We choose to model the actors’ interaction in the Contextual-Graphs formalism.

4.1 An Actor’s Task as Part of Another Actor’s Task

Figure 1 shows a fragment of a contextual graph centered in an actor’s vision: the editor, who communicates to other actors whose tasks are embedded in the editor’s graph. In Fig. 1 the activities 3 and 5 correspond to the reviewers’ tasks, while activities 14 and 16 are author’s tasks. In this contextual graph, “Document status” represents the common goal as a shared contextual element. “Document status” may be changed by one actor and then used by another. In this case, when a reviewer has finished or decides not to be involved in the task realization, he will change the “Document status”. Figure 1 shows in contextual element 73, that in case the reviewers have evaluated the paper, the instantiation of “Document status” becomes “reviewed” and the editor will be able to continue the decision process, by comparing the evaluations. In case a reviewer has refused to evaluate the paper, the Document status stays “to be reviewed”, so the editor needs to find a new evaluator. The introduction of this shared contextual element brings some advantages, as any person could easily understand the task realization flow without having to know the general protocol, they just need to understand the common goal. Furthermore, the working context is always denoting the current status of the process, making easy to obtain information. However, this representation is sequential, since the editor’s job is paused until the reviewers change the status of the shared context.

Fig. 1.
figure 1

A partial view of an actor’s task inside of another actor’s task

Full size image

4.2 One Branch for Each Actor’s Task Realization

Another way to represent interaction between the editor and reviewers as a working group is to consider all actors’ task realization at the same level. In Fig. 2, each branch of the graph corresponds to an actor’s activity. The branches correspond (from top to bottom) to the activities of the author, the editor, the reviewer, and the publisher. Thus, an actor is selected by the instantiation of the contextual element.

Fig. 2.
figure 2

A partial view of the paper submission problem presenting an actor in each branch

Full size image

This representation becomes difficult to follow when a change of actors is needed, since the Contextual-Graphs formalism is not adapted to model group tasks. Thus, elements for guiding the representation should be introduced. Figure 3 shows the extended view of the editor and reviewer activities. Specifically, in action 8 the editor’s task is to inform a reviewer about their new assignment. Once the request is sent, the next turn concerns the reviewer. This is realized by reapplying the global contextual graph of Fig. 3 in the new working context with reviewer as the actor in the focus. This representation, understandable in this well-known example, could become rapidly difficult to follow when jumping from one branch to another, without completing any branch. The representation is also inefficient, as it is difficult to know important information about the submission, such as its current status: Is the paper in the reviewers’ hands? Has the editor received the evaluations but has not yet made a decision? Is there a conflict between reviewers? The sequence fashion of the representation and the lack of shared contextual elements make it really difficult to notice information rapidly.

Fig. 3.
figure 3

A partial view of the branches representing the editor and reviewer’s task realization

Full size image

4.3 Lesson Learned

Modelling a group task realization supposes the management of several actor’s viewpoints in order to be able to follow the development of the task. In the framework of the Contextual-Graphs formalism, a contextual graph is the representation of a task realization. Thus, it is possible to represent the interaction between actors as an activity representing an actor’s task realization as a clearly defined part of another task realization, as in Fig. 1. However, it is not efficient to use this approach when two actors interact several times during the group task realization, as it supposes that an actor sending a request waits for the completion of the recipient’s task. It is an over-simplification of a group effort. The representation of an actor’s activity on each branch of a Contextual Graph is not efficient either for a task involving more than two actors, as it is contradictory with the definition of a contextual element with exclusive instantiations. Moreover, many task realizations could get mixed in a single contextual graph, violating this philosophy, which states that a contextual graph represents a single task realization. Thus, a particular mechanism for turns management in addition to the use of the shared context between the actors needs to be considered. The shared context will play the role of a virtual working context of the turns mechanism with contextual elements coming from the two working contexts associated with the task realization of the two actors.

5 The Turns Mechanism

To address the limits pointed out in the previous sections, we propose to manage turns with a specific contextual element. Figure 4 shows a “meta graph” for the paper submission example. This graph does not correspond to any actor’s particular view, but to the management of the turns between actors. The different actor’s views (e.g. the editor and the reviewer) are represented in individual contextual graphs shown in the activities. This representation introduces some reserved words to denote the name of the contextual elements in charge of the sequence of turns among actors. Such words are MANAGER, RECIPIENT and SENDER. The MANAGER is the actor responsible for the task realization at hand (the actor on focus); the RECIPIENT denotes the actor whose turn is next (the next actor on focus); and the SENDER is the actor whose turn is just ending (the actor releasing the focus). Thus, at the completion of the current task, the MANAGER informs the correct RECIPIENT, who in turn, will realize one task or another depending on the SENDER and the shared context. At the beginning of the graph in Fig. 4 the MANAGER becomes the last assigned RECIPIENT, thus the value of the contextual element 1 is known, and the corresponding branch is selected. By the end of a turn, the SENDER takes the value of the current MANAGER, since the next actor in turn needs to know the SENDER. Thus, a cycle is created through these contextual elements by instantiating the initial working context of the current turn with the final working context of the previous turn (i.e. MANAGER = RECIPIENT).

Fig. 4.
figure 4

A partial view of the Turns Mechanism model

Full size image

This representation preserves and enhances the use of shared contextual elements. The semantic of these contextual elements are task dependent, and can adopt different values from one actor to another. The idea is to give a common ground to all the actors, for them to be able to know the current situation of the task realization and perform the corresponding task when their turn comes. A shared contextual element is instantiated by one actor and used by another. The TASK_GOAL is a reserved contextual element shared among the actors corresponding to the status of the document (e.g., submitted, reviewed, etc.). Figure 5 shows an example of changing turns. As shown in Fig. 5 at the reception of a new paper, the editor can decide if the paper is suitable for the journal or not. In case the paper is suitable, the corresponding actions are done in the editor’s side, then the contextual element TASK_GOAL is instantiated to “to be reviewed” and the RECIPIENT is assigned as “reviewer”; which means that the turn of the editor has ended for now, and the focus should be placed on the reviewer, shown in Fig. 5 as a change from activity 137 to 140. Once the branch corresponding to this specific interaction between the author and the editor has been completed, the SENDER takes the value of “editor” in action 82 on Fig. 5, creating a loop in the reading of the graph, since the MANAGER instantiation will change and the next actor in focus should be found. In this case the focus will be on the reviewer (following the legends of Fig. 5) who detects that the editor has sent a paper to be evaluated, since the TASK_GOAL shared contextual element has been changed in the previous turn to “to be reviewed”. The reviewer will change the TASK_GOAL instantiation to either accept or refuse reviewing the paper, and the RECIPIENT of the focus will be assigned to the editor. Thus, the loop in the reading of the diagram continues, this time from activity 140 to 138. Such a loop is broken when the RECIPIENT is equal to NIL (i.e. it is the end of the overall task).

Fig. 5.
figure 5

A partial view of the Turns Mechanism shared context

Full size image

6 The Practice Tree for Identifying Turns

The Contextual-Graphs software includes a Practice Tree View that helps decision makers to quickly identify the possible practices to develop, considering the information they possess. This view is also important for group tasks, since each tree branch corresponds to a turn. Figure 6 shows the practice tree of the contextual graph in Fig. 5 followed by the practice tree of the actor’s activity 137. In the deployed view of activity 137 in Fig. 6, it should be noticed that a decision maker might need to have gathered a lot of information in order to choose the paths containing more contextual elements.

Fig. 6.
figure 6

Author’s Practice Tree for decision making

Full size image
Fig. 7.
figure 7

Author’s Practice Tree

Full size image

Figure 7 presents the author’s practice tree, which is encapsulated in activity 136 in the general graph. Each branch finishes in a change of turns (e.g. author to editor, and author to publisher), meaning that the focus of attention moves from the editor to another actor. Branch 1 of Fig. 7 corresponds to the beginning of the group task, since the author sends a paper to the editor of the journal. The level of interaction in branch 1 is at “task level”, regarding the types of interaction presented in Table 1, since the editor’s turn is activated until a new paper submission has been received, the author instantiates the TASK_GOAL contextual element to “Submitted” just before their turn is over. The second branch corresponds to the author finishing his turn by instantiating the TASK_GOAL contextual element to “Revised version” and passing the focus of attention to the editor. Here the interaction is at the “activity level”, since the editor task is different to the author, but they communicate to reach agreements regarding the submitted paper, e.g. the author attaches a document explaining the changes made to the revised version. Once the submission is accepted, on branch 3, the author and the publisher interact at the “team level”, since they both work on the document to create the last version of the paper. When the author finishes correcting the typos, he instantiates the TASK_GOAL contextual element to “final version”. Branch 4 does not create any further interaction, since it corresponds to the case in which the paper has not been accepted. Finally, branch 5 is really similar to branch 2, because it corresponds to the case in which the author has been asked by the editor to change the paper. The difference with branch 2 is that this time, the editor asks for a complete new version, not just some small changes. Thus, the interaction is at “activity level” and the TASK_GOAL contextual element is instantiated to “revised version”. Although not all interaction levels presented in Table 1 can be found in the paper submission example, it is important to do not forget about them, since they are present in different types of group tasks, that have lead to the development of divers applications, such as the ones mentioned in Table 1.

By analyzing the levels of interaction detected in the paper submission group task, we see that, as the actors become more engaged in the group task realizations, the need of just coordination among them, evolves to collaboration and then to cooperation. In branch 1 of Fig. 7, the interaction between the author and editor requires coordination, as the editor tasks starts after receiving a new paper. Not presented in the author’s interactions, but following the flow of the submission example, once the editor has sent the paper for reviewing, the interaction between the two reviewers denotes collaboration, as they both realize the same task in their own way. However, the interaction among the editor and the reviewers is at “planning level”. Moreover, in Fig. 7, branches 2 and 5, the collaboration evolves to cooperation between the author and the editor, as their common goal is to obtain a new paper version, but each one has a different task to realize. While the author is in charge of providing a new paper version, the editor should answer the author’s questions. Finally, once the paper has been accepted for publishing, the author and the publisher engage into a strong cooperation, as they both work in the same document to get it ready for publishing.

Beyond the Paper Submission Example. The paper-submission example is a task that involves several actors constantly interacting to reach a goal. However, group tasks are not limited to this type of team configuration, in which a leader coordinates the group actions and the shared context is reduced. Shorter and more dynamic group tasks (e.g. brainstorming sessions), as long as those including two groups working together at specific times might have several leaders coordinating the task realization of their own group. Thus, further discussion can be held regarding the passing of turns among groups, and the efficiency on the quick management of the shared context modifications.

7 Conclusions

Discussions on collaboration and cooperation must be considered in a large spectrum, going from a superficial approach focused on the built of applications, as found in the literature, to an approach aiming to understand the way people really work together, as proposed in this paper.

There is a need to extend the scope of the research on collaboration and cooperation upstream (experts working jointly to develop a contextual model satisfying everybody) as well as downstream (the contextual model as a medium of communication between experts). This means that it looks difficult to obtain a unique way to create contextual graphs for representing group task realizations. However, this paper explore some approaches. Through the analysis of the paper-submission example, we have notice the importance of the shared context, since it is a way to make compatible an actor’s viewpoint with the rest of the group, because each actor is an expert in their own domain. Furthermore, the shared context, along with some reserved words, conform the turns mechanism we propose. Such mechanism helps experts to use the Contextual-Graphs formalism to model their group tasks and to analyze the type of interaction produced in each turn. Moreover, the understanding of a group interaction, will also help experts to make decisions regarding the way the task are realized, and application designers would be able to easily spot the real requirements for supporting a specific group tasks.