A Role-Based Conflict Resolution Method for a Collaborative System

A Role-Based Conflict Resolution Method for a Collaborative System Haibin Zhu Department of Computer Science and Mathematics, Nipissing University North Bay, Ontario, Canada [email protected] Abstract - Conflict resolution is one of the most important problems that must be solved in building a collaborative system. In many CSCW (Computer-Supported-Cooperative Work) applications or systems, roles were granted in the design and application of these systems. Consequently, we may infer that “without roles, there would be no collaboration”. Based on the success of RBAC, we found that role-based methods are very useful in building collaborative systems. However, there is little research on conflict resolution based on roles. This paper, briefly introduces an object model for collaborative systems OMCS and a multimedia coauthoring system MCAS, and mainly discusses the role management and a role-based conflict avoidance and resolution method in the system MCAS. It emphasizes the importance of roles in conflict avoidance and resolution. In the last section, it summarizes the paper and draws a conclusion that a role-based method can help greatly to resolve conflicts in collaborative systems. Keywords: Role, role-based, collaborative system

1

conflict

resolution,

Introduction

Collaborative systems combine communication, computer, and decision support technologies to support problem formulation and solution in group meetings [15]. Team members are dependent on mediated interactions for coordination, and are likely to face important deficits in the information they have about the day-to-day activities of their teammates [16]. Even though scientists are working hard to provide systems that provide a virtual environment to make collaboration easy and the collaborators work hard to be cooperative, there are still many problems for collaborators to know and overcome when using a collaborative system. Conflict resolution is one of the most important problems we must solve in building a collaborative system. Early in 1988, this problem was introduced and began to be studied among scientists [15]. For more than a decade, many scientists have made many contributions. Poole et.

al. did research on how a non- specialized multipurpose GDSS influences conflict management in groups [15]. Edwards proposed a flexible conflict detection and management method [4]. Jung et. al. proposed a conflict resolution method by coordination and argumentation agents [12]. Barber et. al. discussed conflict detection in multi-agent systems [1]. Sun et. al. proposed a formal specification of a unique combined effect for an arbitrary group of conflict and compatible operations [17]. Other scientist did this kind of research in a more general style like algorithms in access control to solve this problem [3 and 10]. However, there is little research on conflict management using role-based methods [5 and 8], even though RBAC has been very successful in the last few years [9]. We originally composed an object model for collaborative systems [18, 19, and 23], built a multimedia co-authoring system MCAS [20] with role-based architecture, and successfully resolved the conflict problems in the coauthoring processes. This paper discusses a role-based conflict avoidance and resolution method applied successfully in the multimedia ca-authoring system MCAS. It illustrates a reference to designing and building other collaborative systems. The other sections are organized as follows. In section 2, we briefly introduce an object model for collaborative systems OMCS, a multimedia co-authoring system MCAS and the role-based conflict avoidance structure we used in our system MCAS; in section 3, we discuss conflict avoidance at the management level and mainly demonstrate our regulations of role management used in the interface design; in section 4, we illustrate the conflict resolution at the document level and mainly discuss the regulations of editing operations used in the design of a manager object; in section 5, we discuss some implementation issues for the role-based method in our MCAS system; and in the last section, we summarize what we have discussed and draw a conclusion that a rolebased method can help greatly to avoid and resolve conflicts in collaborative systems and give some suggestions how to introduce role-based methods to designing a collaborative system.

2

OMCS (An Object Model for Collaborative Systems) and MCAS (a Multimedia Co-authoring System)

We designed an Object Model for Collaborative Systems (OMCS) and used it as a guide to design our coauthoring system [20]. In terms of object-oriented technologies [22], we address that a collaborative system can be an instance of the class CoSystemClass ::= [19], where • CSID ::= "CoSystem", it is a name or an identification. A URL on the Internet can be taken as an identification. • CSDS ::= expresses the structure (or state) of the system, where, A denotes the platform architecture of the system, A ::=Totally Centralized | Totally Distributed | Partially Distributed; M denotes the collaborative (or coordination) modes; W denotes a management model for information; and D denotes the support tools for discussion, D ::= Text | Audio | Video |Combined. • CSOP::= expresses the services provided by the system, where, R expresses the services for roles, such as, chairman, lecturer, audience or others; S expresses the services for cooperation, such as, start, enter, leave, late, leave early; E expresses the services for editor, such as text editor, hypertext editor, and multimedia editor; and I expresses the interface design for multi-user requirements, such as, WYSIWIS (What You See Is What I See) service, collaborative edit service. Based on the above model OMCS, we have implemented a Multimedia Co-Authoring System MCAS [20]. The design of a collaborative system is actually a process of instantiation. That is to say, we implemented each attribute and service. Therefore, MCAS is actually a special instance of class OMCS, i.e., MCAS ::= , where • a ::= partially distributed architecture • m ::= parallel + sequential + reciprocal • w ::= WNCH multimedia management model [22] • d ::= Text + Audio + Video + Combined • r ::= Chairman + session leader + lecturer + audience • s ::= Early messages + late comers + early leavers + transitions among roles • e ::= WNCH editor + special editors for different media such as text, image, audio and video information • i ::= Multi-user interfaces

View sharing is the most important mechanism for a synchronized collaborative system [2, 7 and 16]. It means that one user must be aware of others' existences explicitly that is the best awareness for a collaborative system. View sharing can help to eliminate unnecessary conflicts among collaborators. Distributed Shared Worksapce

Distributed Shared Worksapce


Shared Document ….. …. …..


Figure 1. Sharing with a shared workspace In MACS, the implementation is on a partly distributed system that means a centralized server manages the shared document and many distributed user interfaces on clients used directly by users as shown in Figure 1. By this architecture, we can support both view and document sharing. View sharing means that a system provides facility and lets all the co-authors have the same interface copy to work on as shown in Figure 1. We suppose that there are four copies of the same interface. A collaborative system should also provide facilities to support the following activities [18]: • To announce a collaborative work by earlier messages or calling in time; • To enter or leave in different time such as coming late and leaving early; • To designate the roles such as chairman, lecturer, audience, etc.; • To define tasks and priorities, because different roles in different tasks have different priorities at different times; and • To add and control comments, such as comments link, and modification records. Our MCAS system supports • Both earlier messages and calling in time to start collaborative work; • Both late comers and early-leavers; • Four roles such as chairman, session leader, lecturer, and audience; and • Role transitions based on co-authors’ requests and coordination among the co-authors.

Based on the above view sharing shown in Figure 1, we support document sharing by managing shared documents in shared workspaces. We used the WNCH model [21] in MCAS to manage these documents. In this model, a document (W) object is composed of node (N) objects that may contain content (C) objects and hotspot (H) objects. A content object is used to express different media information such as text, image, audio and video that is stored in a file or a database tuple. A hotspot object is a special area covering a part of a content object and used to express a hyperlink from a part of content object to another node. By this model, we may have several sharing levels, i.e., document sharing, node sharing, content sharing, and hotspot sharing. For each kind of sharing, we have different requirements for conflict avoidance. Based on our partially distributed architecture and information management model, we formed two levels of conflict controlling shown, that is, management level at the clients and document level at the server. • Management Level (Section 3) We assigned different roles such as a chairman, a session leader, a lecturer and an audience. This level was implemented mainly by interface changing. This level dealt with the operations to shared workspaces, documents and nodes. • Document Level (Section 4) We used a centralized information management. We mean that messages are received by a manager before they are sent to relevant objects. By designing a message queue in the manager, we could use regulations to resolve conflicts. The manager processes the message queue in an interval set or tuned by the system administrator. This level was implemented mainly by a manager incorporated with specific role-based regulations. This level processed the operations to contents and hotspots.

3

Conflict Avoidance at the Management Level

To support collaborative work, a workflow and access control mechanism is very useful [21]. In a rolebased system, there should be users, roles, objects, operations and permissions [6]. Where, • A user is defined as a human being. • A role is a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role. • Permission is an approval to perform an operation on one or more objects related. • An operation is an executable image of a program, which upon invocation executes some function for the user.

In a collaborative system, there should be task distributions and role assignments [3]. Without role-based method, it is difficult to determine what permissions have been authorized for which users [11]. In our MCAS system, a user is called a co-author. A role is a state of a co-author that has specific responsibilities. Or a role is a version of a user object that has a definite scope of operations of objects in the system. We differentiate among co-authors into four kinds of roles such as chairman, session leader, lecturer, and audience. • A chairman can open a shared workspace, and manage other roles; • A session leader is a temporary role that can work in a shared workspace and manage documents and nodes; a chairman is granted a default session leader; • A lecturer can work in a shared workspace and operate on an opened node; and • An audience can only watch the collaboration and has no right to operate on the shared document. The assignment of this role is to help to decrease the possibility of conflict occurrences by decreasing the number of concurrent coauthors that might operate in parallel on shared objects. By this assumption, we provide role management regulations in the system design as follows. • Only one chairman exists in MCAS at a time; • Only one session leader exists in MCAS at a time; • The chairman is granted the session leadership before assigning it to another lecturer. • Only one session leader can manage (open, close, delete, or save) a document and a node. • Only one document can be opened at a time; • Only one node can be opened at a time; • A chairman can release his or her chairman role; • A session leader can release his or her leader role to become a lecturer; • A session leader can apply for a chairmanship; • A lecturer can apply for upgrading a session leader; • An audience can apply for upgrading to a lecturer; • The chairman can approve audiences’ and lecturers’ applications for upgrading; • The chairman can downgrade a session leader to a lecturer, and a lecturer to an audience; • The application for chairmanship of a session leader is granted when the chairman releases his or her chairmanship; and • Non-chairman co-authors can vote to downgrade the current chairman to a lecturer and the current session leader is granted the chairmanship. If

there is no current session leader, the lecturer that is applying to upgrade takes the chairmanship. At the management Level, many critical operations such as open, save and delete are allowed to only one role at one time. Therefore, no conflict occurs, because there is only one operation at one time. By this role assignment and operation enabling/ disabling regulations, we have done the serialization of operations issued by different co-authors and avoided conflicts among operations at the management level.

4

Conflict Resolution at the Document Level

There are several contributions about document level conflict resolution [4, 12, 14 and 17]. A conflict is defined simply as a special state that exists between two actions that have been applied, perhaps tentatively, to the artifact [4]. According to the ideas of object-orientation, we can define a conflict as a state of an object that accepts two messages that are not consistent. Use Dr. Sun’s specification [17] and suppose there are two operations O1 and O2. Conflict between these two occurs if and only if • • •

O1 is independent of O2; The object receiving O1 is the same as that receiving O2; and The result of O1 is different with that of O2.

By an object-oriented view and our model WNCH, we can define operation O as a triple, that is, O ::= , where • R expresses the receiver of the message related with this operation; • M is the message name; and • A is the argument attached with the message. Hence, a conflict between two operations O1 and O2 can occurs when O1.R = O2.R, O1.M ≠ O2.M or O1.M = O2.M but O1.A ≠ O2.A. This is not true for general object ideas such that two irrelevant messages to one object will not be considered conflicts. However, it is really true for a welldefined message set for components of a shared document. With this definition, we can find a typical conflict of O1 and O2, where O1 = and O2 = when x1 ≠ x2 or y1 ≠ y2, and p means a position with coordinates x and y. Here, O1.M = O2.M but O1.A ≠ O2.A. We can find another typical conflict between O1 and O2, where O1 = and O2 = . Here, O1.M ≠ O2.M.

With the role concepts introduced, we can redefine operation O as a quadruple as follows. O ::= , where • R, M, and A have the same meanings as above; and • S means the sender of the message, and there is role information in object S. By this definition, a conflict between two operations O1 and O2 occurs when O1.R = O2.R, O1.S ≠ O2.S, O1.M ≠ O2.M or O1.M = O2.M but O1.A ≠ O2.A. By this restriction, we do not consider two different operations sent by the same user as conflicts. We can express the above conflict with O1 and O2 where O1 = and O2 = when S1≠S2, x1 ≠ x2 or y1 ≠ y2. From the above definition, we can know that if there are definite roles limited in a definite context, conflicts can be avoided by specific regulations. This is demonstrated by the discussion in Section 3. Conflict management is performed in response to detected conflicts [4]. That is why we use a manager to detect conflicts. In our MCAS system, we set an interval for the manager to process a message queue. In the message queue, we store messages created by operations of coauthors in the format of the above definition, i.e., . The following regulations are used when the manager detects conflicts. We do not think that two operations in different processing intervals of the manager will create conflicts, because the operations in the former interval have been done permanently before the operations in the latter interval. • Only the save operation can change a node permanently. • More than one coauthor can add a new content to the current node in the shared workspace, because these operations are not in conflicting situations. • For moving, resizing, and deleting operations to content and hotspot objects, if there are many different moving operations to one content or hotspot object, o if there is a session leader, the result will be the session ’s operation. For example, suppose we have a conflict with two operations O1 and O2 where O1 = and O2 = when S1≠S2, x1 ≠ x2 or y1 ≠ y2. If S1.role is a session leader (Note that a chairman might be the default session leader), O1 is accepted and O2 is discarded. Suppose we have a conflict with two operations O1 and O2 where O1 = and O2 = where p means the new bottom-right of a rectangle, when S1≠S2, x1 ≠ x2 or y1 ≠ y2. If S2.role is a session leader, O2 is accepted and O1 is discarded. o if there is no session leader, the result will be the last lecturer’s operation upon the receiving timestamps by the manager. We use the Lamport’s algorithm [13] to deal with the synchronization of clocks. · For conflict deleting operations, the first role’s operation will be accepted and shown in the shared workspace, because the second operation has no receiving object. For same roles, any operation is discarded if there is a delete operation ahead because of no receiving object.

For example, suppose we encounter the conflict with two operations O1 and O2 where O1 = and O2 = when x1 ≠ x2 or y1 ≠ y2. The manager will check the senders’ roles. • If S1.role is a session leader, O1 is accepted and O2 is discarded. • If S2.role is a session leader, O2 is accepted and O1 is discarded. • If S1.role and S2.role are both lecturers, the manager checks the operation arriving timestamps, the late one is accepted and the early one is discarded.

5 Implementation At the management level, we designed different login interfaces for the different default roles for coauthors. All co-author’s interfaces are similar, but different roles will see different menus or menu items in a window within their clients. The interface is changed dynamically when the co-authors change their roles, such as enable or disable some operation menu items in the menu bar of a window. The objects managed in this level are shared workspace, document, and node and the operations include new, open, close, save, delete, and structure. At the document level, a document contains only node objects. The interface will be enabled when a document and a node is opened. The two kinds of objects are content and hotspot and the operations include add, delete, move, resize, and hyperlink. With the regulations discussed in Sections 3, we implemented a multi-interface with the help of logged role information. If a co-author changes his or her role, the operation menu will be changed by disable or enable

some specific operation menu items. With the regulations discussed in Section 4, we designed a manager object to detect and resolve conflicts.

5

Conclusions

By using role management and role-based regulations, we can simplify the task of conflict resolution. Many possible conflicts are avoided with the role assignment, management and regulations. From the implementation of MCAS, we believe that the role-based method is a practical way to general conflict resolution in collaborative systems. To generalize and utilize our methods to resolve conflicts in a collaborative system, we need to provide • A high-level strategy to avoid conflicts; • A flexible role definition and tuning tool; • A mechanism to check conflicts; and • An easily understandable user interface for users to recognize his or her roles. From what we have discussed, we know that this successful practice comes from the combination of a document management model WNCH, a partially distributed architecture, and a group of role-based policies. From a systems engineering’s view, a standalone technology or methodology would not be very successful without being in combination with other related ones. Role-based methods would also have the same results. In our research and practice, we found that role management is a complex task to which we must pay more attention. Therefore, the number of roles in a system should not be too large. We hope that the role-based method we have practiced can be used as a reference for researchers, designers and developers of collaborative systems.

Acknowledgement This research is partly supported by the research funding of Nipissing University (No.: 10-3287-42195). Thanks to Bill Ross and Janet Ross of Nipissing University for their proofreading.

References [1] K. S. Barber, T. H. Liu, and S. Ramaswamy, “Conflict detection during plan integration for multi-agent systems”, IEEE Trans. On Systems, Man, and Cybernetics- Part B: Cybernetics, Vol. 31, No. 4, pp. 616-628, Aug. 2001 [2] J. Begole, M. B. Rosson, and C. A. Shaffer, “Flexible collaboration transparency: supporting worker

independence in replicated application-sharing system”, ACM Transactions on Computer-Human Interaction, Vol. 6, No. 2, pp. 95-132, June 1999

[13] L. Lamport, L., “Time, clocks, and the ordering of events in a distributed system”, Communication of the ACM, Vol. 21, No. 7, pp. 558-564, July 1978

[3] P. Dewan, and H. Shen, H., “Controlling access in multiuser interfaces”, ACM Transactions on ComputerHuman Interaction (TOCHI), Vol. 5, No. 1, pp. 34 – 62, March 1998

[14] M. Nyanchama, and S. Osborn, “The role graph model and conflict of interest”, ACM Transactions on Information and System Security (TISSEC), Vol. 2, No. 1, pp. 3-33, Feb. 1999

[4] W. K. Edwards, “Flexible conflict detection and management in collaborative applications”, Proc. Symposium on User Interface Software and Technology(UIST’97), Alberta, Canada, pp. 139-148, Oct. 1997

[15] M. S. Poole, M. Homes, G. DeSanctis, “Conflict management and group decision support systems”, Proc. CSCW’88, Portland, Oregan, USA, pp. 227-243, Jan. 1988

[5] W. K. Edwards, “Policies and roles in collaborative applications”, Proc. ACM 1996 Conference on Computer Supported Cooperative Work (CSCW’96), Cambridge, USA, pp. 11-20, Nov. 1996 [6] D. F. Ferraiolo, R. Sandhu, S. Gavrila, D. R. Kuhn, and R. Chandramouli, “Proposed NIST standard: rolebased access control”, ACM Transactions on Information and system Security, Vol. 4, No. 2, pp. 224-274, Aug. 2001 [7] C. Gutwin, and S. Greenberg, “The effect of workspace awareness support on the usability of real-time distributed groupware”, ACM Transactions on ComputerHuman Interaction, Vol. 6, No. 3, pp. 243-281, Sept. 1999 [8] M. Guzdial, J. Rick, and B. Kerimbaev, “Recognizing and supporting roles in CSCW”, Proc. (CSCW’00), Philadelphia, Pennsylvania, United States, pp. 261-268, Dec. 2000 [9] http://csrc.nist.gov/rbac/ [10] T. Jaeger, A. Edwards, and X. Zhang, “Managing access control policies using access control spaces”, Proc. 2002 ACM Symposium on Access Control Models And Technologies (SACMAT’02), Monterey, California, USA, pp. 3-12, June 2002 [11] P. Jeffrey, and A. McGrath, “Sharing serendipity in the workplace”, Proc. Conference on Collaborative Virtual Environments (CVE’00), San Francisco, CA, USA, pp. 173-179, Sept. 2000 [12] H. Jung, M. Tambe, M., and S. Kulkarni, “Argumentation as distributed constraint satisfaction: applications and results”, Proc. Fifth International Conference on Autonomous Agents, Montreal, Quebec, Canada, pp. 324-331, May 2001

[16] C. Steinfield, C. Y. Jang, and B. Pfaff, “Supporting virtual team collaboration: the teamSCOPE system”, Proc. ACM 1999 Conference on Supporting Group Work (GROUP’99), Phoenix, Arizona, USA, pp. 81-90, Nov. 1999 [17] C. Sun, and D. Chen, “Consistency maintenance in real-time collaborative graphics editing systems”, ACM Transactions on Computer-Human Interactions, Vol. 9, No. 1, pp. 1-41, March 2002 [18] H. Zhu, M. Turoff, and Z. Li, “An object model for collaborative systems and a toolkit to support collaborative activities", Proc. 2000 American Conference on Information Systems (AMCIS'00), Long Beach, USA, pp. 590-594, Aug. 2000 [19] Zhu, H., Wang, P., and Hu, S., "CoWNCH: An object-oriented model for computer supported hypermedia co-authoring", Proc. 1995 European Simulation Symposium (ESS'95), Erlangen-Nuremberg, Germany, Oct., 1995 [20] H. Zhu, P. Wang, and S. Hu, “The design of a multimedia co-authoring platform based on client/server model", ACTA Electronica Sinica, Vol. 25, No. 5, May 1997 [21] H. Zhu, P. Wang, and S. Hu, “An Object-Oriented Multimedia Management Model WNCH”, Software Journal, Vol. 7, Suppl., Dec. 1996 [22] H. Zhu, G. Yang, and Z. Liu, Object-oriented principle and its applications, Publishing House of Changsha Institute of Technology, Sept. 1998 [23] H. Zhu, and M. Zhou, “Formalizing the Design of a Collaborative System”, Proc. IEEE International Conference on Systems, Man, and Cybernetics (SMC’02), Tunisia, Oct. 2002