Undo in Peer-to-peer Semantic Wikis

Abstract

The undo mechanism is an essential feature in collaborative editing systems. Most popular semantic wikis support a revert feature, some provide an undo feature to remove any modi cation at any time. However this undo feature does not always succeed. Supporting the undo mechanism for P2P semantic wikis has never been tackled. In this paper, we present an undo approach for Swooki, the rst P2P semantic wiki. We identify the problems to resolve in order to achieve such mechanism for P2P semantic wikis. We give the de nition of the undo and the properties that must ensure. This approach allows both a revert and a permanent successful undo.

Introduction

Wiki systems are very popular collaborative editing systems. Thanks to a simple syntax, users can build complex text documents, including tables, pictures or videos. As collaborative editors, wiki systems provide an undo mechanism. This mechanism is integrated in two forms, either through a revert which allows to return to an old version, or through an undo allowing to remove any modi cation from the current version [ 24 ].

In spite of their success, wiki systems have some limitations such as:

To overcome these limitations, two orthogonal solutions are proposed: P2P wiki systems and semantic wiki systems.

P2P wiki systems [ 28, 12 ] are based on a decentralized architecture and optimistic replication[ 19 ] mechanism to improve scalability and data availability. As traditional wiki systems, they su er from low structuring.

Semantic wiki systems [ 27, 20, 6 ] allow users to incorporate some computer readable information in wiki pages. Such information can be used to improve navigation and search. However, they su er from centralization limitations.

Swooki [ 21 ] aims at conciliating both directions, it combines the advantages of P2P systems and semantic wikis. Swooki is a semantic wiki inspired from Semantic MediaWiki [ 27 ]. Moreover, Swooki supports massive collaboration, fault tolerance, o -line work mode and ad hoc collaboration thanks to its P2P structure and to the replication of semantic wiki pages on di erent sites. Unfortunately, this approach does not o er any undo mechanism.

In the literature, several collaborative editing systems o er an undo mechanism. Existing semantic wikis are centralized, therefore their undo mechanism is not adequate for the P2P environment. On the contrary, some undo frameworks were devised for distributed collaborative systems, however they do not support semantic wiki data type. The data type maintained in semantic wikis is the wiki pages and the semantic annotations storage. Our goal is to design an undo mechanism that is compatible with P2P constraints, that supports the semantic wiki data type and that ensures the consistency between the wiki pages and the semantic storage.

In this paper, we propose an undo mechanism for Swooki. We de ne the property that this mechanism must ensure. This mechanism supports both undo and revert features. We develop the undo component and the needed algorithms and extensions to instantiate this undo mechanism in Swooki.

The paper is organized as follows. In section 2, we motivate the need for the undo mechanism. Section 3 presents existing approaches for the integration of the undo mechanism in collaborative editing systems. Section 4 presents Swooki. An overview of the undo in Swooki approach is given in section 5. Section 6 describes the implementation of the approach. The last section concludes the paper. 2

Motivation

Similarly to classical collaborative editors, P2P semantic wikis require supporting the undo feature for many reasons: { Undo is a user required feature. Indeed, users can use the undo feature as a powerful way to recover from their proper errors. { In collaborative editors, when two or more users modify the same data, the system proposes a document based on all modi cations. This merge algorithm is a best-e ort and is not able to produce the result expected by users. The undo feature is useful to recover from unexpected results. { We consider a P2P semantic wiki as an open system where anyone can join and leave. Since anyone can join, malicious users can also join. As a result, the undo feature can be used to remove the impact of vandalism acts. In all these cases, the expected result matches the undo de nition [ 23 ]: \Undoing a modi cation makes the system return to the state it would have reached if this modi cation was never produced."

To achieve such a goal, the revert feature seems to be adequate: we can remove the whole content and add a previously created one. Unfortunately, the revert feature does not allow to undo any modi cation.

Another common idea is to undo changes by doing the inverse modi cation. Unfortunately, this does not achieve the undo de nition.

shhhhhhhMhh2hhhhhh

Peer2

\The Ferrari FXX is a [type::race car].

It can reach [topSpeed:=349km/h].

It has a [topSpeed:=49km/h]." \ "

M2

Peer1

\The Ferrari FXX is a [type::race car].

It can reach [topSpeed:=349km/h].

It has a [topSpeed:=49km/h]." \The Ferrari FXX is a [type::race car].

It can reach [topSpeed:=349km/h]." \ "

M1

Inverse(M2) \The Ferrari FXX is a [type::race car].

It can reach [topSpeed:=349km/h].

It has a [topSpeed:=49km/h]."

Starting from a version V1 (Figure 1), a user2 on Peer2 generates a malicious modi cation M2 by deleting the whole document. M2 deletes all the document lines. Concurrently, user1 on Peer1 deletes the third line that contains an error. The inverse modi cation of M2 inserts the three lines. As a consequence, when user1 on Peer1 undoes M2, it reinserts the three lines and looses its proper modi cation M1 which aims at deleting the third line. If M2 was never produced, the document would be corrected to "The Ferrari FXX is a [type::race car]. It can reach [topSpeed:=349km/h].". A correct undo must return the document to this state. Our goal is to provide such an undo feature. 3

Related work

This section gives an overview about the undo mechanism in di erent collaborative editors. 3.1

Undo in semantic wikis

Semantic wikis such AceWiki [ 10 ], Rise [ 7 ] and WikiSar [ 4 ] do not support versioning for wiki pages, hence they do not support an undo mechanism.

Makna [ 8 ] is a wiki based tool for distributed knowledge engineering. It extends the JSPWiki wiki engine with generic, easy to use ontology-driven components for collaboratively authoring, querying and browsing Semantic Web information. Makna supports versioning for pages and metadata within the pages, thus the revert feature is provided. However, it does not support the undo feature.

IkeWiki [ 20 ] is a semantic wiki with features to support collaborative knowledge engineering, di erent levels of formalization ranging from informal texts to formal ontologies, and it has a sophisticated, interactive user interface. IkeWiki supports also a revert feature to restore an old version. IkeWiki does not support a feature to undo modi cations applied on a page version. In addition, the annotations about the wiki pages are outside the content of these pages. Tracking the annotations changes is not provided, an insert or a delete of annotations can not be detected.

SweetWiki [ 6 ] is a semantic wiki based on the CORESE engine. It supports WYSIWYG edition of pages and annotations, and use the CORESE engine and the SeWeSe library for all semantic operations : navigation, search and others. Pages are annotated using tags which are outside the content of the pages. SweetWiki does not support a versioning support for the formalized content, i.e. changes in the tags on pages are not tracked. SweetWiki supports a revert feature without an undo one.

Rhizome [ 22 ] supports a modi ed version of WikiML (ZML) that uses special formatting conventions to make semantic properties directly explicit in the page content. Pages are saved in RDF and another editor can be used to edit the RDF directly. Rhizome provides a native versioning of content and metadata. It provides only a revert feature without an undo one.

Semantic MediaWiki (SMW) [ 27 ] is an extension of MediaWiki that helps to search, organize, tag, browse, evaluate, and share wiki content. SMW adds semantic annotations in wiki pages in order to bring the power of the Semantic Web into the wiki. SMW inherits all the features of MediaWiki including revert and undo. While the revert always succeeds in restoring an old version, in some cases the undo can fail 1. For instance, the undo of a modi cation in a paragraph followed by other modi cations in the same paragraph can not succeed.

OntoWiki [ 3 ] and Powl [ 2 ] are web based applications designed to collaboratively build ontologies and create instances. Every change on any element such as knowledge model, concept, property or instance is logged. So they enable users to track, review and selectively roll-back changes. Consequently, they can o er both the revert and the undo features. Unfortunately, their undo mechanism is designed only for ontological elements and not for text. 3.2

Undo in di erent collaborative editors

DBin [ 26 ] enables end users to create and experience the Semantic Web by exchanging RDF knowledge in P2P \topic" channels. DBin is not designed to 1 http://en.wikipedia.org/wiki/Wikipedia:Undo#Undo exchange and edit semantic wiki pages. However, it can be used as a complementary component for P2P semantic wikis separating the annotations from the wiki page content. There is no indication about the support of an undo mechanism.

Most undo approaches were devised in the Operational Transformation [ 9 ] (OT) framework.

In [ 15 ], the authors propose to select which operation to undo. They also add the notion of con ict. If a con ict occurs, the undo is aborted. Therefore, this framework does not allow undoing any operation.

In [ 18 ], the authors propose a solution to undo operations in the inverse chronological order, i.e. from the last operation to the rst one without skipping one. Therefore this approach does not allow undoing any operation.

The GOTO-ANYUNDO approach [ 23 ] is the rst approach that allows any user to undo any operation at any time. This approach is designed for real-time editing and uses state vectors [ 11 ]. Since state vectors size is proportional to the number of sites, this approach cannot be used in a P2P environment.

The COT approach [ 25 ] is an OT system designed for real-time editing which introduces the notion of \context vector". A context vector is associated to each operation and represents the operations executed before its generation. As state vectors, context vectors are not suitable in a P2P environment.

Distributed version control systems (DVCS) as Git 2 are P2P collaborative systems mainly used for source code editing. They compute a new patch to remove the e ect of a previous one and treat it as a new patch. However, DVCS lack of a formal framework: there is no property to validate their correctness. For instance, in Git, the use of the undo feature may confuse further merges 3.

The UNO[ 29 ] framework proposed an undo for P2P collaborative editing based on the Operational Transformation approach. The main idea of this approach is to devise new operations for counterbalancing previously made operations. This framework cannot be used directly to provide an undo feature in Swooki. However, we propose an undo mechanism inspired by this framework capable of undoing any modi cation at any time, i.e. supporting both a revert and an undo features. 4

Swooki System

Swooki [ 16, 21, 17 ] is the rst P2P semantic wiki, it combines the advantages of P2P wikis and semantic wikis. Swooki is a P2P network of a set of autonomous semantic wiki servers called also peers, that can dynamically join and leave the network.

Every peer hosts a copy of all wiki pages where these pages embed semantic data and an RDF store. Every peer can autonomously o er all the services of a semantic wiki server. Swooki supports massive collaboration, improves data availability and has a high performance thanks to its total replication of shared 2 http://git.or.cz/ 3 http://www.kernel.org/pub/software/scm/git/docs/user-manual.html# undoing-a-merge data. It allows to query and access data locally without any data transfer. In addition, it enables o -line works and transactional changes.

As in any wiki system, the basic element is a wiki page and every wiki page is assigned a unique identi er P ageID, which is the name of the page. The name is set at the creation of the page. If several servers create concurrently pages with the same name, their content will be directly merged by the synchronization algorithm. An U RI can be used to unambiguously identify the page. The U RI is global and location independent.

A semantic wiki page P age is an ordered sequence of semantic wiki lines. A semantic wiki line L is a four-tuple < LineID, content, degree, visibility > where LineID is a unique line identi er in the whole network, content is a string representing text and the semantic data embedded in the line. degree is an integer used by the synchronization algorithm. visibility is a boolean representing whether the line is visible or not. Lines are not deleted physically, they are just invisible in the view of the semantic wiki page.

Changes in semantic wiki pages are detected as operations. An operation is either an insert operation Op = Insert(P ageID, line, lP , lN ) or a delete operation Op = Delete(P ageID, LineID) where lP and lN are the previous and the next lines of the inserted or the deleted line. An update of a line is considered as a delete of the old value followed by an insert of a new value.

A Swooki peer is composed of the following components (see gure 2): User Interface. The Swooki UI component is basically a regular wiki editor. It allows users to edit a view of a page by getting the page from the Swooki manager. Users can disconnect their peer to work in an o -line mode and they can add new neighbors in their list to work with. In addition, the UI allows users to see the history of a page, to execute semantic queries and to export the semantic annotations of the wiki pages in an RDF format. The history of a page is the set of events concerning that page on a peer.

Swooki Manager. The Swooki manager is responsible for the generation and the integration of the editing patches. A patch is the set of delete and insert operations on the semantic wiki page. Patches are stored in a patchGraph. The SWooki manager implements the Swooki algorithm [ 17 ]. Requesting and modifying a page or resolving a semantic query in the RDF repository pass through this manager.

Sesame Engine. The RDF repository used in Swooki is Sesame 2.0 [ 5 ]. Sesame is controlled by the Swooki manager for storing and retrieving RDF triples. We used a facility of Sesame to represent RDF triples as multi-set. This component allows also generating dynamic content for wiki pages using queries embedded in the wiki pages. It provides also a feature to execute semantic queries and to export RDF graphs.

Di usion Manager. The di usion manager maintains the membership of the unstructured network and implements a reliable broadcast. This component is described in [ 21, 28 ].

The integration of the undo mechanism in Swooki requires the addition of the undo component, with slightly extensions of some existing elements. The undo mechanism is designed to allow users to remove or reinsert the e ect of some changes in the wiki pages and consequently to update their semantic annotations in the RDF repository. A detailed overview of the proposition is given in the following section. 5

Proposition

We developed the undo component for Swooki to provide users a feature to handle vandalism, to correct errors and to improve easily undesired result of an automatic merge done by Swooki. 5.1

Undo component

In this section, we describe the behavior of the undo component which is responsible of handling undo actions.

When a user wants to undo a modi cation, i.e. a patch, the document must return to a state in which the modi cation was never performed according to the undo de nition see section 2. This de nition implies two cases: { the patch is already undone and the document must not be changed, { the patch must be disabled and its e ect must be removed.

Moreover, since the action of undoing a patch is also a modi cation of the document, users must be able to undo an undo modi cation, also called redo.

Similarly, according to the undo de nition, if a patch is already redone, the action of \redo" has no e ect, otherwise, we must re-apply its e ect.

As a result, the system must know if a patch is enabled or not. Moreover, the system has to know how many times a patch has been undone or redone as illustrated in gure 3.

Peer1

P 1

Peer2

P 1 M1 = undoL(LPLL1L)L M2 = undo(P 1)

tiiiiLLiLiiiiiiiii M2 = undo(P 1) LLLL M3 = redo(P 1)

tiiiiiiiiiiLiLLiLiLiLLL% M3 = redo(P 1) M1 = undo(P 1)

Assume that two sites, called Peer1 and Peer2, have received the same patch P 1. Concurrently, both sites decide to undo this patch. Consequently, Peer1 generates a modi cation M1 while Peer2 generates M2. Then, Peer2 chooses to redo the patch P1. Finally, each peer receives each other modi cations. Peer1 has received both \undo" modi cations and then the \redo". If the system just knows that P1 is undone, the \redo" will reapply P1. Unfortunately, this example violates the de nition. Indeed, if the modi cation M2 was never produced, the only remaining modi cation is M1, then the P1 must remain undone.

For instance, a patch with a patchDegree equals to three implies that the patch has been redone three times and that it has an e ect in the semantic wiki page model. Actually, patches are never deleted from the patchGraph, however their e ect is removed from the wiki page model as if they did not exist.

As a result, we propose to extend the patchGraph as de ned in Swooki by associating a patchDegree to each patch in that graph. This patchGraph becomes a set of <patch, patchDegree> where the patchDegree indicates whether the patch has an e ect or not in the current state of the wiki page. We arbitrary choose to a ect a degree of 1 at the patch reception, to decrease by one the degree at the execution of an undo and increase it by one for a redo. Then, a patch is undone if its degree is strictly less than to 1.

Consequently, in Figure 3, Peer1 will compute a degree of 0 and will not restore P1.

Finally, we translate the description of the undo component above into the following algorithm: integrateUndo(patchId): patch := getPatch(patchId) decreasePatchDegree(patch) if getPatchDegree(patch) = 0 then

disable (patch) integrateRedo(patchId): patch := getPatch(patchId) increasePatchDegree(patch) if getPatchDegree(patch) = 1 then

enable(patch)

Now, the system can compute whether or not a patch has to be reapplied or undone. Next, we will explain how to remove or reapply a patch. 5.2

Removing and reapplying a patch

Since we keep deleted lines as tombstones in Swooki, we propose to reuse them instead of inserting new lines in case of redo. We call deletion the transformation of a line into a tombstone and, reinsertion the inverse of deletion.

Moreover, using the inverse operations as shown in Figure 1 is not su cient for removing the e ect of a patch. This is mainly due to concurrency: the line \It has a [topSpeed:=49km/h]." is deleted twice (by M1 and M2) and \reinserted" once by \Inverse(M2)". Similarly to the previous example, we propose to count the number of deletions/reinsertions to overcome this issue.

In Swooki, a line in the wiki page model is never deleted, it is only set to invisible in the wiki page view. The visibility of a line is determined through a boolean visibility eld. We change the line visibility as de ned in Swooki into a visibility degree in order to let the system detect whether a line is visible or not after multiple undo and redo of patches. In our case, a line is visible if it is visibility degree is positive. A delete of a line turns its visibility degree to zero, however an undo (or a redo) action decreases (respectively increases) it by one.

Since we have changed the data model, we have to rede ne the operations to modify it. In Swooki, the integration of an operation is processed in two steps: (1) text integration and (2) RDF statements integration. To integrate an insert operation op = insert(P ageID; line; lP ; lN ), the line has to be placed among all the lines between lP and lN . Finding the right position where the line should be inserted is done through the Woot algorithm (for more details see [ 14 ]).

Once the right position is found, we insert the line in the page with a degree of 1 and insert the metadata into the RDF store: insertLine ( line ): insert (PageID, line, NextIdenti er ) integrateInsRDF(line)

Due to concurrency, a line can have a degree greater than 1. Therefore, the execution of a delete consists in decreasing the degree of that line. If the line becomes invisible, i.e. its degree is zero, we have to update the RDF store using the method \integrateInsRDF".

Similarly, the reinsertion of a line increases its degree. If the line becomes visible, we update the RDF store. delLine(lineID ): line := getLine(lineID) decreaseVisibilityDegreeOfLine( line ) if visibilityDegree ( line ) = 0 then

integrateDelRDF(getContent(line)) reinsertLine (lineID ): line := getLine(lineID) increaseVisibilityDegreeOfLine( line ) if visibilityDegree ( line ) = 1 then

integrateInsRDF(getContent(line))

Finally, we can now remove a patch e ect: disablePatch(patch): for op in patch do line := getLine(op) switch(type(op)) `` insert '': delLine( line ) `` delete '': reinsertLine ( line ) or reapply its e ect: enablePatch(patch): for op in patch do line := getLine(op) switch(type(op)) `` insert '': reinsertLine ( line ) `` delete '': delLine( line )

In Figure 1, since the third line is deleted twice, its degree is 1. As a consequence, when Peer1 undoes M2, the line degree is increased by one and the line remains invisible. 5.3

Messages

As usual modi cations, the undo/redo actions must be propagated to all other sites. Therefore, we need to extend the di usion manager to take account of undo/redo messages. We de ne three kind of messages: Do message: In case of a do message (i.e. containing only insert or delete operations), the patch is added in the patchGraph with a patchDegree equals to one. The operations of that patch are integrated depending on their type. Undo message: In case of an undo message, the patch on which the undo message will be applied is extracted from the patchGraph; Redo message: Similarly for a redo message, the patch is extracted from the patchGraph.

When a message is received, it is added into a waiting queue. Then each message in that waiting queue is tested if it is executable or not. A do message is executable if its operations satisfy their preconditions as de ned in [ 13 ], however an undo or a redo message is executable if the patch on which it is applied exists in the patchGraph. In case of an executable message, its message information mInf o is added into the page history. Then the message is integrated depending on its type. The algorithm stops when the waiting queue does not contain any executable message. uponReceive(message): addMsgWaitingQueue(message) stop := false while(stop = false) do stop := true for msg in MsgWaitingQueue do if isExecutable(msg)= true then stop := false writeHistoryEvent(mInfo) switch(type(msg)) `` Do'': addInPatchGraph(getPatch(msg)) for op in patch do if type(op) = insert

integrateIns (op) else

integrateDel(op) done `` Undo'':

disablePatch(getPatch(msg)) `` Redo'':

enablePatch(getPatch(msg)) endif

endif 6

Implementation

The undo or redo of changes can take place either by visiting the history or the patch graph of a page. The gure 4 shows the history where di erent messages are integrated on the wiki page. A line in the history is equivalent to the message information. It indicates the identi er of the patch, the peer that generated the patch, the type of the message and a user comment when it exists. The undo action of a patch has a grey background. In order to undo a set of patches, a user can click the checkbox that precedes each one of them and then press the undo preview link. The result of this preview is a temporary version of the page which undoes these patches. If he is satis ed, he can apply these changes by saving the undo preview.

Another option provided in the history is to revert the current version of the wiki page. Users can choose to return to a state of a page undoing all the changes integrated after the chosen patch. This is can be achieved by selecting the patch and clicking on the revert preview. Similarly, if he is satis ed the user can save the revert preview and his changes will be applied. The undo of each patch inserts a new line in the history. The history allows also providing more information about each patch by a click on show details link at the end of each line. Each undo action in the history generates a new message of type undo. This message is sent through Swooki di usion manager to the other peers in order to be integrated. The integration of that message locally or on the other peers is done as de ned in section 5.

Another way to undo or redo a patch is through the patch graph (see Figure 5). The patch graph is viewed as an oriented graph of patches. Each patch is a node in the graph and the arrows represent the dependence between these patches. A node relating one or more nodes implies that this patch was generated on a state integrating these patches. Each node is labeled with the patch identi er and the patch degree. A black node is a disabled patch that has no e ect in the wiki page. A right click on a node allows to show the information about the patch, to undo or redo a patch or to preview a version of the wiki page. The patch graph is visualized through an applet built using JGraphT java libraries and JGraph is used to render the graph layout. It is based on a recursive algorithm browsing the patch graph [ 1 ]. The patch graph provides information about the patches dependency, hence the concurrency between them. In this paper, we propose an undo mechanism for Swooki. This mechanism allows users to undo any modi cation at any time, i.e. to remove any modi cation as if it was never produced. It provides both an undo and a revert features. We developed the undo component, the appropriate algorithms and extended some parts of Swooki to provide it with an undo mechanism. The undo component is responsible for the generation and the integration of undo and redo actions. The propagation of these actions lies on Swooki di usion manager. Swooki extension ensures the convergence of the wiki pages and the RDF stores on all peers. This convergence is independent from concurrent modi cations, the order of integration of the undo or redo actions and the fact that users can edit in an o -line mode i.e. join or leave at anytime.

We identi ed the problems to resolve in order to achieve such mechanism for P2P semantic wikis. While the revert feature may be su cient for centralized semantic wikis, this is not the case for P2P semantic wikis aiming at removing any modi cation at any time. Our solution is general, it is based: (1) on enabling/disabling patches in the patchGraph and (2) on the generation and the integration of undo/redo actions. It can be adopted in any P2P semantic wiki and any P2P wiki.

As future work, we intend to carry out user studies to evaluate: (1) the quality improvement of wiki pages and the knowledge in the RDF stores using our approach and (2) how this mechanism facilitates the task of the users compared to Swooki without the undo mechanism.

References

1. S. Alshattnawi , G. Canals, and P. Molli . Concurrency awareness in a p2p wiki system . In Proceedings of CTS 2008 , The 2008 International Symposium on Collaborative Technologies and Systems , Irvine, California, USA, May 2008 .

2. S. Auer . Powl. In Proceedings of the 1st Workshop on Scripting for the Semantic Web (SFSW'05) , Hersonissos, Greece, 2005 .

3. S. Auer , S. Dietzold , and T. Riechert . Ontowiki - A tool for social, semantic collaboration . In International Semantic Web Conference , volume 4273 of Lecture Notes in Computer Science, pages 736 { 749 . Springer, 2006 .

4. D. Aumueller and S. Auer . Towards a semantic wiki experience - desktop integration and interactivity in wiksar . In Proceedings of the Workshop on Semantic Desktop , Galway, Ireland, 2005 .

5. J. Broekstra , A. Kampman , and F. van Harmelen. Sesame: A generic architecture for storing and querying rdf and rdf schema . In ISWC 2002: First International Semantic Web Conference , 2002 .

6. M. Bu a , F. L. Gandon , G. Ereteo, P. Sander , and C. Faron . Sweetwiki: A semantic wiki . Journal of Web Semantic , 6 ( 1 ): 84 { 97 , 2008 .

7. B. Decker , E. Ras , J. Rech , B. Klein , and C. Hoecht . Self-organized Reuse of Software Engineering Knowledge Supported by Semantic Wikis . Proceedings of the Workshop on Semantic Web Enabled Software Engineering (SWESE) , November 6th-10th , 2005 .

8. K. Dello , E. P. B. Simperl , and R. Tolksdorf . Creating and using semantic web information with makna . In Proceedings of the First Workshop on Semantic Wikis { From Wiki To Semantics. ESWC2006 , June 2006 .

9. C. A. Ellis and S. J. Gibbs . Concurrency control in groupware systems . In J. Clifford, B. G. Lindsay , and D. Maier, editors, SIGMOD Conference , pages 399 { 407 . ACM Press, 1989 .

10. T. Kuhn . Acewiki: Collaborative ontology management in controlled natural language . In Proceedings of the 3rd Semantic Wiki Workshop, CEUR Workshop Proceedings , 2008 , Jul 2008 .

11. F. Mattern . Virtual time and global states of distributed systems . In M. C. et al., editor, Proceedings of the International Workshop on Parallel and Distributed Algorithms , pages 215 { 226 , Cha^teau de Bonas, France, october 1989 . Elsevier Science Publishers.

12. J. C. Morris . Distriwiki: : a distributed peer-to-peer wiki network . In Int. Sym. Wikis , pages 69 { 74 , 2007 .

13. G. Oster, P. Urso , P. Molli , and A. Imine . Data consistency for P2P collaborative editing . In Proceedings of the ACM Conference on Computer Supported Cooperative Work , CSCW , Ban , Alberta, Canada, November 2006 .

14. G. Oster, P. Urso , P. Molli , and A. Imine . Tombstone transformation functions for ensuring consistency in collaborative editing systems . In The Second International Conference on Collaborative Computing: Networking, Applications and Worksharing (CollaborateCom 2006 ), Atlanta, Georgia, USA, November 2006 . IEEE Press.

15. A. Prakash and M. J. Knister . A framework for undoing actions in collaborative systems . ACM Transactions on Computer-Human Interaction (TOCHI) , 1 ( 4 ): 295 { 330 , 1994 .

16. C. Rahhal , H. Skaf-Molli , and P. Molli. Swooki : A peer-to-peer semantic wiki . In The 3rd Workshop: 'The Wiki Way of Semantics'-SemWiki2008 , co -located with the 5th Annual European Semantic Web Conference (ESWC), Tenerife , Spain, June 2008 .

17. C. Rahhal , H. Skaf-Molli , and P. Molli. Swooki : A peer-to-peer semantic wiki . Research Report 6468, INRIA , Mars 2008 .

18. M. Ressel and R. Gunzenha user. Reducing the problems of group undo . In GROUP, pages 131 { 139 , 1999 .

19. Y. Saito and M. Shapiro . Optimistic replication . ACM Computing Surveys , 37 ( 1 ): 42 { 81 , 2005 .

20. S. Scha ert. Ikewiki: A semantic wiki for collaborative knowledge management . In WETICE , pages 388 { 396 . IEEE Computer Society, 2006 .

21. H. Skaf-Molli , C. Rahhal , and P. Molli . Peer-to-peer semantic wikis . Research report, INRIA , 2008 .

22. A. Souzis . Building a semantic wiki . IEEE Intelligent Systems , 20 ( 5 ): 87 { 91 , 2005 .

23. C. Sun . Undo as concurrent inverse in group editors. ACM Transactions on Computer-Human Interaction (TOCHI) , 9 ( 4 ): 309 { 361 , December 2002 .

24. C. Sun and C. A. Ellis . Operational transformation in real-time group editors: Issues, algorithms, and achievements . In Proceedings of CSCW , pages 59 { 68 , New York, New York, Etats-Unis, Novembre 1998 . ACM Press.

25. D. Sun and C. Sun . Operation Context and Context-based Operational Transformation . In Proceedings of CSCW , pages 279 { 288 , Ban , Alberta, Canada, November 2006 . ACM Press.

26. G. Tummarello, C. Morbidoni , and M. Nucci . Enabling semantic web communities with dbin: An overview . The Semantic Web - ISWC 2006 , pages 943 { 950 , 2006 .

27. M. Vo^lkel, M. Krto^zsch, D. Vrandecic, H. Haller , and R. Studer . Semantic wikipedia . Journal of Web Semantics , 5 ( 4 ), 2007 .

28. S. Weiss , P. Urso, and P. Molli . Wooki: a p2p wiki-based collaborative writing tool . In Web Information Systems Engineering, Nancy, France, December 2007 . Springer.

29. S. Weiss , P. Urso, and P. Molli . An undo framework for p2p collaborative editing . In CollaborateCom, Orlando, USA, November 2008 .