Consistency Maintenance of Group/Ungroup Operations in Object-based Collaborative Graphical Editing Systems Liping Gao, Fangyu Yu School of Optical-Electrical and Computer Engineering, University of Shanghai for Science and Technology, Shanghai, 200093, China. Email: lipinggao@usst.edu.cn; fangyuyu@st.usst.edu.cn Abstract In real-time collaborative graphical editing systems, Object-based Group/Ungroup operations are frequently accessible and practically useful. However, the existing research on these operations of the graphical editing is rare and defective. In this paper, based on Multi-Version strategy and Address Space Transformation method, a new MVSDR algorithm, which is not only applied to simple operations (such as Create, Delete, ChangeATT, etc.), but also suitable for Group/Ungroup ones, is proposed to solve the consistency maintenance problem. The proposed algorithm abandons previous attempts to divide conflict operations into Real-Conflict operations and Resolvable-Conflict ones and to deal with them separately, thus making the algorithm more simple and effective. In addition, an example analysis is also given in this paper to prove the algorithm's correctness and effectiveness. Keywords: Real-time Collaboration, Graphical Editing System, Object-based, Group/Ungroup, Multi-Version Strategy, Address Space Transformation, Consistency Maintenance. 1. Introduction Real-time collaborative graphical editing system allows multiple users to view and edit the shared graphics at the same time from geographically different sites via network connections, which has higher editing efficiency and more conforms to the trend of the modern collaborative thoughts, compared with previous single-user editing system. Collaborative editing system can be classified into three types: Object-based, bitmap-based and hybrid [5]. Wherein, Object-based editing system is a special collaborative editing system, whose operation targets are objects such as points, lines, circles, triangles, etc., and each object has attributes such as color, coordinate, size, etc. Users can create, update and delete objects, and the attributes of objects can be also updated. Lots of research has been developed in this field, including Co-PowerPoint, Co-AutoCAD, Co-Visio, etc. However, existing studies are mostly aimed at simple operations such as Create, Delete, ChangeAtt, etc., by comparison, rarely at complex operations of Group/Ungroup, which are indispensable common operations in graphical editing system, thus making the research on this field of great significance. For the sake of operations' consistence maintenance, existing collaborative graphical editing system usually adopts the following three strategies: Locking, Serialization and Operation Transformation (OT). Locking [3] allows only one user to edit the shared documents at one time, and collaborative editing is allowed only if different users are locking and editing different objects. Locking is divided into Pessimistic Locking and Optimistic Locking. Wherein, Pessimistic Locking causes the operation's delay when obtaining the Lock, while Optimistic Locking avoids the delay, but the system is not clear what to do when the Lock is denied. In addition, the target objects by users must be stored in their initial states. Serialization guarantees that the effects of all concurrent operations are just like their execution orders are the same at all sites. When there are conflicts between concurrent operations, the last operation is allowed to be executed only. Wherein, the applications in [1] [2] [3] belong to this method. The main problem with Serialization is the operational delay, thus making the response time too slow and reaching the requirement of real-time collaborative editing too difficult. OT strategy transforms the to-be-executed operation against all executed concurrent operations before it being executed. OT ensures the operation to be executed correctly and the convergence and intention-preservation to be satisfied successfully. Some celebrated studies by this method include GOT/GOTO [6] and COT [7] [11] algorithm. The main limitation of OT is that the complex relationship between operations has to be considered, especially while dealing with Group/Ungroup, the transformation method will become completely complicated. This paper adopts a novel approach named AST (Address Space Transformation) [8], which utilizes Mark-Retrace strategy. AST retraces the document state to that when the operation is generated, and retraces the document back to the current state after executing the operation. Without considering the complex relationship between operations, this method thus has higher algorithm efficiency and is also suitable for Group/Ungroup operations. The following paper is organized as follows. In section 2, some previous works on graphical editing and the AST method are introduced briefly. An object-based document model is established and definitions of related operations are presented in section 3. In section 4, a new MVSDR algorithm is proposed to resolve Group/Ungroup operation's consistency maintenance problem, and an example analysis is also given to verify the correctness and effectiveness of the algorithm, which is the focus of the paper. Finally, the paper is concluded with a brief summary of major contributions and future work. 2. Related Work 2.1. Preparatory Work In graphical editing system, Group/Ungroup are all-important operations. In short, Group intends to combine a series of objects (including group) into a group, while Ungroup attempts to divide a group into a series of objects (including group). However, existing objet-based graphical editing is mainly focused on simple operations [5], the research on Group/Ungroup is quite scanty. In previous works, Ignat [1] [2] [3] classifies conflict operations into two types: Real-Conflict operations and Resolvable-Conflict operations. Real-Conflict operations refer to the situation that executing one operation will make it impossible to execute the other operation or will mask the execution effect of the other one. In this case, a priority-based policy is adopted in which only the operation with the highest priority will be executed. Resolvable-Conflict operations are the situation that conflict operations can be executed correctly by changing their execution orders. On this occasion, Ignat adopts Serialization method, which ensures all conflict operations being executed in the same order at each site. Obviously, the way of categorizing conflict operations is not only cumbersome but also may omit some cases. Besides, the adopted priority-based policy makes it impossible to preserve the effects of any other operation whose priority is not the highest, which goes against the collaborative idea of maintaining all users' intentions. Note that the priority is an artificial rule and it will become meaningless if any one user does not comply with the rule. Moreover, in order to ensure operational order consistency, Serialization has to undo and redo certain operations repeatedly, thus leading to low efficiency of the algorithm. Related to these studies, Xia [4] proposes Multi-Version Single-Display (MVSD) strategy, i.e., all operations' effects are preserved, but one version is displayed on the user interface only. Meanwhile, combined with an Operation Transformation (OT) technique, the remote operation is guaranteed to be executed aright by transforming against all executed concurrent operations before its execution. However, although the MVSD strategy preserves all operations' intentions, users have to pause and then to choose which one version to be displayed once multiple versions are generated, which cause higher overhead and lower efficiency for executing operations. Besides, due to the addition of Group/Ungroup, the process of operational transformation will be surprisingly complicated, accordingly increasing greatly the complexity of the algorithm. In this paper, the attempt of classifying operations into Real-Conflict and Resolvable-Conflict operations is discarded. Combined with the AST method, the Multi-Version strategy is adopted, which maintains all users' intentions without considering complex relationships between operations, thereby improving the algorithm's efficiency. Details will be described in the following parts. 2.2. Overview of the AST Method Different with OT which transforms the operation itself, AST [8] retraces the document state to that at the time of the operation's generation so as to conceal the effects of executed concurrent operations without considering complex relations among operations. AST is originally applied in text document environments [10] supporting users to insert, delete and update characters, by contrast, little research has been done on graphical editing systems. Here, we continue to use Timestamp scheme and status Mark technique. Each operation is attached with its generating site's current state vector and then broadcast to other sites, and the target object or group of every operation is added with an Effective/Ineffective Mark which indicates whether it is visible or not on the user interface. Each object or group may have several operations targeting itself and each operation may target several objects or groups equally. As shown in Fig.1, given three operations O1, O2 and O3, generated at sites 1, 2 and 3 separately. Wherein, O1=Group([G1, Obj3], G2), O2=Ungroup(G1) and O3=Group([G1, Obj4], G3). Execution orders are different at different sites, assuming that the order is: O2, O1 and O3 at site 2. O1 cannot be executed directly after O2's execution, because the current document state has been changed. To execute O1 correctly, we should retrace the document state to that when O1 is generated, and execute O1 in this new document state, then retrace back to the current document state and finally execute subsequent operation O3. At this moment, the state of G1 is Ineffective, Obj3 and Obj4's are Effective. Fig.1 also shows the result of the execution of O2 and O1 on user's view. Obj2 G1 Obj3 G2 O1=Group([G1, Obj3], G2) <1,0,0> Obj4 IneffectiveEffective Effective Obj3 G1 Obj4 Obj1 O3=Group([G1, Obj4], G3) <0,0,1> O2=Ungroup(G1) <0,1,0> Fig.1 the AST Strategy and the User Interface View 3. Document Model and Basic Operations 3.1. Document Model Here, an address tree is used to store the target objects. In the tree, Object is the basic unit as a leaf node, and Group can be represented both as a parent node and leaf node, which means that Group can contain Objects and Group at the same time. If one Group both has a parent and children, it is called an intermediate node, as G3 shown in Fig.2, and if one Group has only children, it is the root node, as G5 in Fig.2. The parent and children information, together with the state for each Object or Group shall be recorded, i.e., Obj/G :=(<Parent, Children>, State). Wherein, Obj denotes a simple object, and G is a group. Parent denotes one object or group's parent node of which has only a parent. Children, expressed with an unordered list (Child1, Child2,..., Childn), denote the leaf nodes of one group which may have several children. State denotes one object or group's state, which has two states: Effective and Ineffective. As shown in Fig.2, G5 :=(<Null, (G4, Obj7, Obj8)>, Effective), G3 :=(<G4, (Obj4, Obj5, Obj6)>, Effective) and Obj3 :=(<G2, Null>, Effective). Obj2 Obj3 G2 Obj1 G1 G3 G5 G4 Obj4 Obj5 Obj6 Obj7 Obj8 ...... Fig.2 an Instance Diagram of Document Model 3.2. Basic Operations In this part, five types of basic operations are introduced, including Create, Delete, ChangeAtt, Group and Ungroup. In addition, Conflict and Compatible Relations are also defined in detail. Definition 1: Graphical Operations Create(Obj): an object Obj is created. Delete(ObjList): an ObjList is deleted. ChangeAtt(ObjList, Attribute): the attribute of an ObjList is updated, wherein, the type of Attribute can be Position, Color, Size, Text, etc. For example, ChangePosition(ObjList, (dx0, dy0), (dx1, dy1)) moves ObjList from the initial coordinate position (dx0, dy0) to (dx1, dy1), ChangeColor(ObjList, Color) changes the color of ObjList to color Color (such as Red, Green, Blue, etc.), ChangeSize(ObjList, (dx0, dy0), (Δdx, Δdy)) changes the size of ObjList by the ratio Δdx and Δdy, with (dx0, dy0) as the center. Group(ObjList, G): an ObjList is grouped into a group G. Ungroup(G): a group G is ungrouped, and the objects or groups contained in G still exist but no longer belong to the G. Note that the ObjList mentioned above can be either an object or a group which includes objects or groups with an unordered list [Ojb1, Obj2, ..., Objn]. Definition 2: Conflict Relations "" [9] Given two operations O1 and O2, they conflict with each other, denoted as O1  O2, iff: (1) O1 || O2; (2) Target(O1) ∩ Target(O2) ≠{}; (3) Att.Type(O1) = Att.Type(O2); (4) Att.Value(O1) ≠ Att.Value(O2). Note that Target(O) denotes the target object or group of operation O, Att.Type(O) denotes the attribute type of O, and Att.Value(O) denotes O's attribute value. Definition 3: Compatible Relations "⊙" [9] Given two operations O1 and O2, if they are not conflict with each other, they are compatible relations, denoted as O1⊙ O2. 4. Consistency Maintenance Strategy of Group/Ungroup Operations 4.1. Description of the Algorithm The main idea of the algorithm is that the local operation can be executed immediately, and then attached with its generating site's state vector, broadcast to other sites. As for the remote operation, it cannot be executed at once. First of all, it is checked to find whether it is a causally ready operation or not. If not, it has to be queued since the sending site has executed operations which have not been executed at this site. If so, steps are as follows: if the operation desires to Delete/Ungroup one object or group that has been deleted/ungrouped, it is cancelled. If not, firstly, retrace the document state to that when the operation is generated, and then find all executed conflict operations, if there is no such operation, execute the operation directly in this new document state, if there does exist such operations, retain the effects of the operation and all other conflict ones to create multiple versions with Multi-Version Strategy. Finally, retrace back to the current document state and add the operation into the history buffer (HB). The MVSDR (Multi-Version Strategy based Double Retracing) algorithm reveals the execution process of remote operation Oi at one site, assuming that Oi is a causally-ready operation. Wherein, Docs denotes the current document state, SVoi is the state vector at the time of O i's generation, and SVc is the state vector of current document state. Besides, all executed operations are stored in HB. Algorithm: MVSDR(Docs, Oi, HB): Note: Given executed operations O1, O2,..., Oi-1, and Oi is the operation to be executed. Begin: 1. HB ={ O1, O2,..., Oi-1}; 2. If Oi is a Delete/Ungroup Operation whose target object/group has been Deleted/Ungrouped 3. Oi is refused to be executed; 4. else 5. Retracing(Docs, SVoi); //call Retracing function 6. If there is any executed operation Oj (1≤j≤i-1), such that Oj  Oi then 7. FindConflict (Oset, Oi); //call FindConflict function 8. Multi-Version(Oset, Oi, VSi); //call Multi-Version function 9. else 10. execute Oi directly; 11. end if 12. end if 13. SVc =SVc+1; 14. Retracing(Docs, SVc); //call Retracing function again 15. HB =HB+{Oi}; End The Retracing function specifies the procedure of retracing the document state to that at a given timestamp SVo i, wherein, SVoi is the state vector when Oi is generated, and ON is the object or group node in the tree structure of the document Docs. Function 1: Retracing(Docs, SVoi): Docs Note: Before executing Oi, retrace the document's state to the time when Oi is generated. Wherein, ON is the Object (including group) Node, in the tree structure of the document Docs. Begin: 1. For any Ungroup/Delete Operation Ougr/Odel of ON 2. If the Ougr is timestamped by SVugr, and SVugr < SVoi then 3. Set ON Ineffective; 4. ON.children ←ON.parent; 5. else if the Odel is timestamped by SVdel, and SVdel < SVoi then 6. Set ON Ineffective; 7. else 8. Set ON Effective; 9. end if 10. end for 11. For any other Operation Oany of ON 12. Set ON Effective; 13. end for End The FindConflict function specifies that all executed operations which are conflict with Oi are stored in Oset. Function 2: FindConflict (Oset, Oi): Oset Note: Given executed operations O1, O2,..., Oi-1, and Oi is the operation to be executed. Begin: 1. Oset ={}; 2. Remove Oj from HB and repeat until HB ={}; 3. If Oj  Oi then 4. Oset =Oset+{Oj}; 5. else 6. do nothing; 7. end if 8. Return Oset; End The Multi-Version function specifies the process of preserving the effects of O i and all executed conflict operations that are stored in Oset to generate multiple versions. Mainly four cases are listed in the function, and other cases can be accomplished based on the Multi-Version idea. Function 3: Multi-Version(Oset, Oi, VSi): VSi Note: Oi is the operation to be executed, Oset is the set of all executed operations that conflict with Oi, and VSi is the new generating versions set. Begin: Case 1: Oi and Oset are Group Operations // Case 1: Group Operations 1. Pre: Oi =Group(ObjList1, G1) and Oset =Group(ObjList2, G2) and ObjList1 ∩ ObjList2≠{ } 2. VSi←{Vii (ObjList1, G1); Vij(ObjList2, G2)}; //j is the number of the operation in Oset Case 2: Oi and Oset are ChangePosition Operations // Case 2: ChangePosition Operations 3. Pre: Oi =ChangePosition(ObjList, (dx0, dy0), (dx1, dy1)) and Oset =ChangePosition (ObjList, (dx0, dy0), (dx2, dy2)) 4. VSi←{Vii (ObjList1, (dx1, dy1) ); Vij(ObjList2, (dx2, dy2))}; Case 3: Oi and Oset are ChangeColor Operations // Case 3: ChangeColor Operations 5. Pre: Oi =ChangeColor(ObjList1, Color1) and Oset =ChangeColor(ObjList2, Color2) and ObjList1 ∩ ObjList2 ≠{ } 6. VSi←{Vii (ObjList1 ∩ ObjList2, Color1; Vij(ObjList1 ∩ ObjList2, Color2; }; 7. Put {ObjList1 ObjList2, Color1} on VSi; 8. Put {(ObjList2 ObjList1, Color2} on VSi; Case 4: Oi and Oset are ChangeSize Operations // Case 4: ChangeSize Operations 9. Pre: Oi =ChangeSize(ObjList, (dx0, dy0), (Δdx1, Δdy1)) and Oset =ChangeSize(ObjList, (dx0, dy0), (Δdx2, Δdy2)) 10. VSi←{Vii (ObjList1, (Δdx1, Δdy1)); Vij(ObjList2, (Δdx2, Δdy2))}; Case 5: Oi and Oset are other types of Operations //Other Situations 11. Do something accordingly based on the Multi-Version idea; 12. end Case 13. CheckVersion(VSi); //Check and Delete the redundant versions 14. Return VSi; End The CheckVersion function checks whether there are duplicate versions or not, and if so, those redundant versions will be deleted. Function 4: CheckVersion(VSi): VSi Note: VSi is the new generating versions set. Begin: 1. For each Vi in VSi { 2. For each Vj in VSi{ 3. If i≠j and Vi=Vj 4. Delete Vj; 5. end if 6. } 7. } End 4.2. Example Analysis Assume that the shared editing area for users is a square, and the graphical initial state on the user interface view is shown in Fig.3. Wherein, group G1 includes two objects Obj1 and Obj2, Obj3 and Obj4 are the other objects. Obj2 G1Obj1 Obj4 Obj3 Site1 Site3 O1=Group([G1, Obj3], G2 ) <1, 0, 0> O4=Group([G1, Obj4], G3 ) <0, 0, 1> Site2 O2=ChangeColor(G2, Green) <2, 0, 0> O5=ChangeColor(Obj2, Red) <0, 0, 2> O3=Ungroup(G1 ) <0, 1, 0> Fig.3 the Initial State Fig.4 Example Analysis As shown in Fig.4, O1 and O2 are generated at site 1, O2 at site 2, O3 and O4 at site 3, and their relations are: (O1→O2) || O3 || (O4→O5). Now, the process of executing operations will be analyzed detailedly at all sites, and the execution result is shown in Fig.5. Site 1: Site 2: Obj2 G1Obj1 Obj4 Obj3 V1 O1, O2: O4: O5: G2 Obj2 G1Obj1 Obj4 Obj3 G2 O3: Obj2 G1Obj1 Obj4 Obj3 G2 Obj2 G1Obj1 Obj4 Obj3 G3 V2 V3 Obj2 G1Obj1 Obj4 Obj3 G2 Obj2 G1Obj1 Obj4 Obj3 G3 V1 V4 Obj2 G1Obj1 Obj4 Obj3 G2 Obj2 G1Obj1 Obj4 Obj3 G3 V2 A B Obj2 G1Obj1 Obj4 Obj3 V2 O4, O5: O1: O2: G2 O3: Obj2 G1Obj1 Obj4 Obj3 G2 Obj2 G1Obj1 Obj4 Obj3 G3 V1 V4 Obj2 G1Obj1 Obj4 Obj3 G2 Obj2 G1Obj1 Obj4 Obj3 G3 V2 V3 Obj2 G1Obj1 Obj4 Obj3 G2 Obj2 G1Obj1 Obj4 Obj3 G3 V1 Obj2 G1Obj1 Obj4 Obj3 G3 A B Fig.5 Execution Result of Operation Process At site 1: (the execution order: O1, O2, O3, O4, O5) 1. O1 and O2 are executed immediately at the local site 1, generating the version A. 2. With the arrival of O3, HB ={O1, O2} at the moment. Firstly, retrace the document state to that when O3 is generated, whose state vector is SVo3<0, 1, 0>. Then for executed operations O1 and O2, the state of their target object or groups G1, Obj3 and G2 shall be set Effective. Due to both O1 and O2 do not conflict with O3, so O3 is executed directly in this document state. Secondly, retrace back to the current document state whose state vector is SVc<2, 1, 0>. Since O3 is an Ungroup operation and SVo3 < SVc, set the state of O3's targeting group G1 Ineffective, and G1's parent node G2 is given to Obj1 and Obj2. Finally, add O3 into the HB, and the version B is generated finally. 3. When O4 arrives at site 1, HB ={O1, O2, O3}. Firstly, retrace the document state to that at the time of O4's generation, whose state vector is SVo4<0, 0, 1>. Then, put the state of target group G1 Effective since SVo3≥SVo4, Obj3 and G2 are set Effective. And then, there is found executed operation O1 are conflict with O4, meeting the case 1 in Multi-Version function, thus generating two versions V1 and V2. Secondly, retrace back to the current document state whose state vector is SV c<2, 1, 1>. Since O3 is Ungroup and SVo3 < SVc, set the state of O3's targeting group G1 Ineffective. And G1's parent node is given to Obj1 and Obj2, thus making their parent node become G3 in V1 and the parent node is G2 in V2. Finally, O4 is added into the HB. 4. At the time of O5's arrival, HB ={O1, O2, O3, O4}. Firstly, retrace the document state to that at the time of O5's generation, whose state vector is SVo5<0, 0, 2>. Then, put the state of target group G1 Ineffective since SVo3 < SVo5, Obj3, G2 and Obj4 are set Effective. And then, it is found executed operation O2 conflicts with O5, meeting the case 3 in Multi-Version function, thus generating four versions V1, V2, V3 and V4. Secondly, retrace back to the current document state whose state vector is SV c<2, 1, 2>. Since O3 is Ungroup and SVo3 < SVc, still set the state of its targeting group G1 Ineffective. And G1's parent node is given to Obj1 and Obj2, thus making their parent node become G3 in V1 and V2 and the parent node is G2 in V3 and V4. Finally, add O5 into the HB so that HB ={ O1, O2, O3, O4, O5}. The process at site 3 is not described in this paper because of its similar to that at site 1, and site 2's process is omitted here due to this paper's length limitation, with their same results as at site 1. As we can see, the final result is always the same even though the execution orders are diverse at diverse sites, thus proving the algorithm's correctness and effectiveness. 5. Conclusions and Future Work In this paper, based on the AST method and the Multi-Version Strategy, we propose a novel approach to resolve the Group/Ungroup consistency maintenance problem in graphical editing systems. Since abandoning the attempt to classify conflict operations into Real-Conflict and Resolvable-Conflict operations, the algorithm adopted becomes simpler and easier to achieve. This paper's main contribution includes that it is the first time to adopt AST method to solve Group/Ungroup questions in graphical environments, which does not have to consider complex relations among operations and reduces delay greatly, with comparison to previous approaches such as Serialization and OT. In addition, the Multi-Version Strategy is proposed to resolve conflict operations' problem, which reflects the effects of all users and satisfies the users' intentions better than the priority-based policy. However, there are other operations such as Undo/Redo of Group/Ungroup and the version identification in practical graphical editing systems, which is the next focus on these issues in the future work. Acknowledgements The work is supported by the National Natural Science Foundation of China(NSFC) under Grant No. 61202376, Shanghai Natural Science Foundation under Grant No. 15ZR1429100, Innovation Program of Shanghai Municipal Education Commission under Grant No. 13YZ075 , Shanghai Key Science and Technology Project in Information Technology Field under Grant No. 14511107902, Shanghai Leading Academic Discipline Project under Grant No. XTKX2012, and Shanghai Engineering Research Center Project under Grant No. GCZX14014 and C14001. References [1] Claudia-Lavinia Ignat, Moira C. Norrie. Grouping/ungrouping in graphical collaborative editing systems[C]. In: Proceeding of the 5th Int. Workshop on Collaborative Editing Systems, (2003), Helsinki, Finland. [2] Claudia-Lavinia Ignat, Moira C. Norrie. Grouping in collaborative graphical editors[C]. In: Proceedings of the 2004 ACM conference on Computer supported cooperative work. ACM, (2004), pp: 447-456. [3] Claudia-Lavinia Ignat, Moira C. Norrie. Draw-Together: Graphical editor for collaborative drawing[C]. In: Proceedings of the 2006 20th anniversary conference on Computer supported cooperative work. ACM, (2006), pp: 269-278. [4] Xia S, Sun D, C Sun, Chen D. Collaborative object grouping in graphics editing systems[C]. Collaborative Computing: Networking, Applications and Worksharing, (2005), 2005 International Conference on. IEEE. [5] Xueyi Wang, Jiajun Bu, and Chun Chen. Achieving Undo in Bitmap-based Collaborative Graphics Editing Systems. In: Proceeding of the Conference on Computer Supported Cooperative Work, (2002), pp: 68-76. [6] Sun C, Ellis C. Operational transformation in real-time group editors: issues, algorithms, and achievements[C]. In: Proceedings of the 1998 ACM conference on Computer supported cooperative work. ACM, (1998), pp: 59-68. [7] David Sun and Chengzheng Sun. Operation Context and Context-based Operational Transformation [A]. In: Proceeding of the Conference on Computer Supported Cooperative Work, (2006), pp: 279-288. [8] Ning Gu, Jiangming Yang and Qiwei Zhang. Consistency Maintenance Based on Address Space Transformation Technique in Group Editor [J]. Chinese Journal of Computers, 30(5): 763-774 (2007). [9] Y Cheng, F He, B Xu, S Han, X Cai and Y Chen. A multi-user selective undo/redo approach for collaborative CAD systems. Journal of Computational Design and Engineering, 103-115 (2014). [10] Hansu Gu, Haojie Hang, Qin Lv and Dirk Grunwald. Fusing Text and Frienships for Location Inference in Online Social Networks. In Web Intelligence and Intelligent Agent Technology (WI-IAT), 2012 IEEE/WIC/ACM International Conferences on, vol.1, (2012), pp. 158-165. IEEE. [11] Hansu Gu, Mike Gartrell, Liang Zhang, Qin Lv and Dirk Grunwald. AnchorMF: towards effective event context identification. In Proceedings of the 22nd ACM international conference on Conference on information & knowledge management, (2013), pp. 629-638. ACM. Authors Liping Gao(1980-) graduated from Fudan University, China with a PhD in 2009 in Computer Science. She received her BSc and master degree in Computer Science from Shandong Normal University, China in 2002 and 2005 respectively. She is doing her research work in University of Shanghai for Science and Technology as an assistant professor. Her current research interests include CSCW, heterogeneous collaboration, consistency maintenance and collaborative engineering. Fangyu Yu(1989-) is a postgraduate student in University of Shanghai for Science and Technology. She obtained her BSc degree in Electronic Information Engineering from Henan University of Science and Technology, China. Her current research interests include CSCW, collaborative design and collaborative computer.