Resolving Conflict and Inconsistency in Norm-Regulated Virtual Organizations Wamberto Vasconcelos Dept. of Computing Science University of Aberdeen Aberdeen AB24 3UE United Kingdom wvasconcelos@acm.org Martin J. Kollingbaum Dept. of Computing Science University of Aberdeen Aberdeen AB24 3UE United Kingdom mkolling@csd.abdn.ac.uk Timothy J. Norman Dept. of Computing Science University of Aberdeen Aberdeen AB24 3UE United Kingdom tnorman@csd.abdn.ac.uk ABSTRACT Norm-governed virtual organizations define, govern and facilitate coordinated resource sharing and problem solving in societies of agents. With an explicit account of norms, openness in virtual organizations can be achieved: new components, designed by various parties, can be seamlessly accommodated. We focus on virtual organizations realised as multi-agent systems, in which human and software agents interact to achieve individual and global goals. However, any realistic account of norms should address their dynamic nature: norms will change as agents interact with each other and their environment. Due to the changing nature of norms or due to norms stemming from different virtual organizations, there will be situations when an action is simultaneously permitted and prohibited, that is, a conflict arises. Likewise, there will be situations when an action is both obliged and prohibited, that is, an inconsistency arises. We introduce an approach, based on first-order unification, to detect and resolve such conflicts and inconsistencies. In our proposed solution, we annotate a norm with the set of values their variables should not have in order to avoid a conflict or an inconsistency with another norm. Our approach neatly accommodates the domain-dependent interrelations among actions and the indirect conflicts/inconsistencies these may cause. More generally, we can capture a useful notion of inter-agent (and inter-role) delegation of actions and norms associated to them, and use it to address conflicts/inconsistencies caused by action delegation. We illustrate our approach with an e-Science example in which agents support Grid services. Categories and Subject Descriptors I.2.4 [Artificial Intelligence]: Applications and Expert SystemsLaw; I.2.11 [Artificial Intelligence]: Distributed Artificial Intelligence-Multi-agent systems General Terms Algorithms, Theory 1. INTRODUCTION Virtual organizations (VOs) facilitate coordinated resource sharing and problem solving involving various parties geographically remote [9]. VOs define and regulate interactions (thus facilitating coordination) among software and/or human agents that communicate to achieve individual and global goals [16]. VOs are realised as multi-agent systems and a most desirable feature of such systems is openness whereby new components designed by other parties are seamlessly accommodated. The use of norms, that is, prohibitions, permissions and obligations, in the specification and operation of multi-agent systems (MASs) is a promising approach to achieving openness [2, 4, 5, 6]. Norms regulate the observable behaviour of self-interested, heterogeneous software agents, designed by various parties who may not entirely trust each other [3, 24]. However, norm-regulated VOs may experience problems when norms assigned to their agents are in conflict (i.e., an action is simultaneously prohibited and permitted) or inconsistent (i.e., an action is simultaneously prohibited and obliged). We propose a means to automatically detect and solve conflict and inconsistency in norm-regulated VOs. We make use of firstorder term unification [8] to find out if and how norms overlap in their influence (i.e., the agents and values of parameters in agents" actions that norms may affect). This allows for a fine-grained solution whereby the influence of conflicting or inconsistent norms is curtailed for particular sets of values. For instance, norms agent x is permitted to send bid(ag1, 20) and agent ag2 is prohibited from doing send bid(y, z) (where x, y, z are variables and ag1, ag2, 20 are constants) are in conflict because their agents, actions and terms (within the actions) unify. We solve the conflict by annotating norms with sets of values their variables cannot have, thus curtailing their influence. In our example, the conflict is avoided if we require that variable y cannot be ag1 and that z cannot be 20. This paper is organized as follows. In the next section we provide a minimalistic definition for norm-regulated VOs. In section 3 we formally define norm conflicts, and explain how they are detected and resolved. In section 4 we describe how the machinery of the previous section can be adapted to detect and resolve norm inconsistencies. In section 5 we describe how our curtailed norms are used in norm-aware agent societies. In section 6 we explain how our machinery can be used to detect and solve indirect conflicts/inconsistencies, that is, those caused via relationships among actions; we extend and adapt the machinery to accommodate the delegation of norms. In section 7 we illustrate our approach with an example of norm-regulated software agents serving the Grid. In section 8 we survey related work and in section 9 we discuss our contributions and give directions for future work. 644 978-81-904262-7-5 (RPS) c 2007 IFAAMAS 2. VIRTUAL ORGANIZATIONS Virtual organizations [17] allow various parties to come together to share resources and engage in problem solving. This paradigm has found strong applications in Web-service orchestration [14], e-Science [16] and the Grid [9]. VOs, in their most generic formulation, can be seen as coordination artifacts, allowing software and human agents to engage in sophisticated forms of interaction. We formally represent our VOs as finite-state machines in which the actions of individual agents label the edges between discrete states. This provides us with a lowest common denominator: there are much more sophisticated, convenient and expressive ways to represent interactions among agents (e.g., AUML [19] and electronic institutions [20], to name a few), but for the sake of generalising our approach, we shall assume any higher-level formalism can be mapped onto a finite-state machine (possibly with some loss of expressiveness). We show in Figure 1 a simple VO graphically represented as a finite-state machine1 . The labels on the edges con//?>=<89:;0 p(X) q(Y,Z) //?>=<89:;1 s(A,B) //?>=<89:;/.-,()*+2 Figure 1: Sample VO as a Finite-State Machine necting the states are first-order atomic formulae, denoted generically as ϕ; they stand for actions performed by individual agents. We define our virtual organizations as follows: DEF. 1. A virtual organization I is the triple S, s0, E, T where S = {s1, . . . , sn} is a finite and non-empty set of states, s0 ∈ S is the initial state, E is a finite set of edges (s, s , ϕ), s, s ∈ S connecting s to s with a first-order atomic formula ϕ as a label, and T ⊆ S is the set of terminal states. Notice that edges are directed, so (s, t, ϕ) = (t, s, ϕ). The sample VO of Figure 1 is formally represented as I = {0, 1, 2}, 0, {(0, 0, p(X)), (0, 1, q(Y, Z)), (1, 2, s(A, B)}, {2} . We assume an implicit existential quantification on any variables in ϕ, so that, for instance, s(A, B) stands for ∃A, B s(A, B). VOs should allow for two kinds of non-determinism corresponding to choices autonomous agents can make, viz., i) the one arising when there is more than one edge leaving a state; and ii) the one arising from variables in the formulae ϕ labelling an edge, for which the agent carrying out the action instantiates. These kinds of non-determinism are desirable as they help define generic and flexible coordination mechanisms. Another important concept we use is the roles of agents in VOs. Roles, as exploited in, for instance, [18] and [20], help us abstract from individual agents and define a pattern of behaviour to which any agent that adopts a role ought to conform. Moreover, all agents with the same role are guaranteed the same rights, duties and opportunities. We shall make use of two finite, non-empty sets, Agents = {ag1, . . . , agn} and Roles = {r1, . . . , rm}, representing, respectively, the sets of agent identifiers and role labels. We refer generically to first-order terms, i.e., constants, variables, and (nested) functions as τ. 2.1 Semantics of VOs The specification of a VO as a finite-state machine gives rise to a possibly infinite set of histories of computational behaviours, in which the actions labelling the paths from the initial state to a final state are recorded. Although the actions comprising a VO are carried out distributedly, we propose an explicit global account of all events. In practice, this can be achieved if we require individual 1 We adopt Prolog"s convention [1] and use strings starting with a capital letter to represent variables and strings starting with a small letter to represent constants. agents to declare/inform whatever actions they have carried out; this assumes trustworthy agents, naturally2 . In order to record the authorship of the action, we annotate the formulae with the agents" unique identification. Our explicit global account of all events is a set of ground atomic formulae ϕ, that is, we only allow constants to appear as terms of formulae. Each formula is a truthful record of an action specified in the VO. Notice, however, that in the VO specification we do not restrict the syntax of the formulae: variables may appear in them, and when an agent performs an actual action then any variables of the specified action must be assigned values. We thus define: DEF. 2. A global execution state of a VO, denoted as Ξ, is a finite, possibly empty, set of tuples a : r, ¯ϕ, t where a ∈ Agents is an agent identifier, r ∈ Roles is a role label, ¯ϕ is a ground first-order atomic formula, and t ∈ IN is a time stamp. For instance, ag1:buyer, p(a, 34), 20 states that agent ag1 adopting role buyer performed action p(a, 34) at instant 20. Given a VO I = S, s0, E, T , an execution state Ξ and a state s ∈ S, we can define a function which obtains a possible next execution state, viz., h(I, Ξ, s) = Ξ ∪ { a:r, ¯ϕ, t }, for one (s, s , ϕ) ∈ E. Such function h must address the two kinds of non-determinism above, as well as the choice on the potential agents that can carry out the action and their adopted roles. We also define a function to compute the set of all possible execution states, h∗ (I, Ξ, s) = {Ξ ∪ { a: r, ¯ϕ, t }|(s, s , ϕ) ∈ E}. 2.2 Norm-Regulated VOs We advocate a separation of concerns whereby the virtual organization is complemented with an explicit and separate set of norms that further regulates the behaviour of agents as they take part in the enactment of an organization. The freedom of choice given to agents (captured via the non-determinism of VOs, explained above) must be curtailed in some circumstances. For instance, we might need to describe that whoever carried out ϕ is obliged to carry out ϕ , so that if there is a choice point in which ϕ appears as a label of an edge, then that edge should be followed. Rather than embedding such normative aspects into the agents" design (say, by explicitly encoding normative aspects in the agents" behaviour) or into the VO itself (say, by addressing exceptions and deviant behaviour in the mechanism itself), we adopt the view that a VO should be supplemented with a separate set of norms that further regulates the behaviour of agents as they take part in the enactment of the organization. This separation of concerns should facilitate the design of MASs; however, the different components (VOs and norms) must come together at some point in the design process. Our norms are defined as below: DEF. 3. A norm, generically referred to as ν, is any construct of the form Oτ:τ ϕ, Pτ:τ ϕ, or Fτ:τ ϕ, where τ, τ are either variables or constants and ϕ is a first-order atomic formula. We adopt the notation of [18]: Oτ:τ ϕ represents an obligation on agent τ taking up role τ to bring about ϕ; we recall that τ, τ are variables, constants and functions applied to (nested) terms. Pτ:τ ϕ and Fτ:τ ϕ stand for, respectively, a permission and a prohibition on agent τ, playing role τ to bring about ϕ. We shall assume that sorts are used to properly manipulate variables for agent identifiers and role labels. We propose to formally represent the normative positions of all agents enacting a VO. By normative position we mean the social burden associated to individuals [12], that is, their obligations, permissions and prohibitions: 2 Non-trustworthy agents can be accommodated in this proposal, if we associate to each of them a governor agent which supervises the actions of the external agent and reports on them. This approach was introduced in [12] and is explained in section 5. The Sixth Intl. Joint Conf. on Autonomous Agents and Multi-Agent Systems (AAMAS 07) 645 DEF. 4. A global normative state Ω is a finite and possibly empty set of tuples ω = ν, td, ta, te where ν is a norm as above and td, ta, te ∈ IN are, respectively, the time when ν was declared (introduced), when ν becomes active and when ν expires, td ≤ ta < te. It is worth noticing that we do not require the atomic formulae of norms to be ground: there could be variables in them. We assume an implicit universal quantification on the variables A, R of norms XA:Rϕ (for the deontic modalities X ∈ {O, P, F}), so that, for instance, PA:Rp(X, b, c) stands for ∀A ∈ Agents.∀R ∈ Roles.∃X.PA:Rp(X, b, c). We also refer to the tuples in Ω as norms. Global normative states complement the execution states of VOs with information on the normative positions of individual agents. We can relate them via a function to obtain a norm-regulated next execution state of a VOs, that is, g(I, Ξ, s, Ω, t) = Ξ , t standing for the time of the update. For instance, we might want all prohibited actions to be excluded from the next execution state, that is, g(I, Ξ, s, Ω, t) = Ξ ∪ { a :r, ¯ϕ, t }, (s, s , ϕ) ∈ E and Fa:rϕ, td, ta, te ∈ Ω, ta ≤ t ≤ te. We might equally wish that only permitted actions be chosen for the next execution state. We do not legislate, or indeed recommend, any particular way to regulate VOs. We do, however, offer simple underpinnings to allow arbitrary policies to be put in place. In the same way that a normative state is useful to obtain the next execution state of a VO, we can use an execution state to update a normative state. For instance, we might want to remove any obligation specific to an agent and role, which has been carried out by that specific agent and role, that is, f(Ξ, Ω) = Ω − Obls, Obls = { Oa:rϕ, td, ta, te ∈ Ω| a:r, ¯ϕ, t ∈ Ξ}. The management (i.e., creation and updating) of global normative states is an interesting area of research. A simple but useful approach is reported in [11]: production rules generically depict how norms should be updated to reflect what agents have done and which norms currently hold. In this paper our focus is not to propose how Ω"s should be managed; we assume some mechanism which does that. 3. NORM CONFLICTS We now define means to detect and resolve norm conflicts and inconsistencies. We make use of the concept of unification [1, 8] of first-order terms τ, i.e., constants, variables or (nested) functions with terms as parameters. Initially we define substitutions: DEF. 5. A substitution σ is a finite and possibly empty set of pairs x/τ, where x is a variable and τ is a term. We define the application of a substitution as: 1. c · σ = c for a constant c 2. x · σ = τ · σ if x/τ ∈ σ; otherwise x · σ = x 3. pn (τ0, . . . , τn) · σ = pn (τ0 · σ, . . . , τn · σ). 4. (Xτ1:τ2 ϕ) · σ = X(τ1·σ):(τ2·σ)(ϕ · σ) 5. ν, td, ta, te · σ = (ν · σ), td, ta, te Where X generically refers to any of the deontic modalities O, P, F. Unification between two terms τ, τ consists of finding a substitution σ (also called, in this context, the unifier of τ and τ ) such that τ · σ = τ · σ. Many algorithms have been proposed to solve the unification problem, a fundamental issue in automated theorem proving [8], and more recent work provides very efficient ways to obtain unifiers. We shall make use of the following definition: DEF. 6. Relationship unify(τ, τ , σ) holds iff there is a possibly empty σ such that τ · σ = τ · σ. We also define the unification of atomic formulae as unify(pn (τ0, . . . , τn), pn (τ0, . . . , τn), σ) which holds iff τi · σ = τi · σ, 0 ≤ i ≤ n. The unify relationship checks if a substitution σ is indeed a unifier for τ, τ but it can also be used to find such σ. We assume that unify is a suitable implementation of a unification algorithm which i) always terminates (possibly failing, if a unifier cannot be found); ii) is correct; and iii) has a linear computational complexity. 3.1 Conflict Detection A norm conflict arises when an atomic formula labelling an edge in the VO, i.e. an action, is simultaneously permitted and prohibited [13]. In this case, both norms are in conflict with regard to their agents, roles and parameters (terms) of specific actions. We propose to use unification to detect when a prohibition and a permission overlap and to employ the unifier to resolve the conflict. For instance, PA:Rp(c, X) and Fa:bp(Y, Z) are in conflict as they unify under σ = {A/a, R/b, Y/c, X/d}). If, however, the variables in Fa:bp(Y, Z) do not get the values in σ then there will be no conflicts. We thus propose to annotate the prohibitions in Ω with unifiers, called here conflict sets, and use these annotations to determine what the variables of the prohibition cannot be in future unifications in order to avoid a conflict. Each prohibition is henceforth regarded as having such an annotation, denoted as (Fτ1:τ2 ϕ) Σc, td, ta, te . Initially, this annotation is empty. We propose to curtail the influence of prohibitions, thus giving agents more choices in the actions they may perform. A similar approach could be taken whereby permissions are curtailed, thus limiting the available agents" actions. Each of these policies is possible: we do not legislate over any of them nor do we give preference over any. In this paper we are interested in formalising such policies within a simple mathematical framework. A prohibition can be in conflict with various permissions in Ω. We, therefore, have to find the maximal set of conflicting pairs of permissions and prohibitions in Ω, by performing a pairwise inspection. This requires identifying the substitution between two pairs of norms that characterises a conflict. This is formally captured by the following definition: DEF. 7. A conflict arises between two tuples ω, ω ∈ Ω under a substitution σ, denoted as cflct(ω, ω , σ), iff the following conditions hold: 1. ω = (Fτ1:τ2 ϕ) Σc, td, ta, te , ω = Pτ1:τ2 ϕ , td, ta, te 2. unify(τ1, τ1, σ), unify(τ2, τ2, σ), and unify(ϕ, ϕ , σ) 3. |te − te| ≤ |ta − ta| That is, a prohibition and a permission conflict (condition 1) if, and only if, the agents and roles they apply to and their actions, respectively, unify under σ (condition 2) and their activation periods overlap (condition 3). Substitution σ, the conflict set, unifies the agents, roles and atomic formulae of a permission and a prohibition. The annotation Σc does not play any role when detecting conflicts, but, as we show below, we have to update the annotation to reflect new curtailments to solve conflicts. For instance, cflct( (Fa:bp(Y, d)) ∅, 1, 3, 5 , PA:Rp(c, X), 2, 3, 4 , {A/a, R/b, Y/c, Z/X}) holds. We define below how we obtain the set of conflicting norms of a normative state Ω: DEF. 8. The finite, possibly empty set of conflicting norms of a normative state Ω, denoted as CFLS(Ω), is defined as CFLS(Ω) = { ω, ω , σ |ω, ω ∈ Ω, cflct(ω, ω , σ)} 3.2 Conflict Resolution A fine-grained way of resolving conflict can be done via unification. We detect the overlapping of the norms" influences, i.e. how they affect the behaviours of agents in the VO, and we curtail the 646 The Sixth Intl. Joint Conf. on Autonomous Agents and Multi-Agent Systems (AAMAS 07) influence of the prohibition. We illustrate with Venn diagrams in Figure 2 the overlap of norm influences (left) which characterises a conflict and the curtailment necessary to resolve the conflict (right). The illustration shows the space of possible values for p(X, Y ) and p(X, Y ) PA:Rp(c, X) Fa:bp(Y, Z) p(X, Y ) Fa:bp(Y, Z) PA:Rp(c, X) Figure 2: Overlap of Influence (Left) and Curtailment (Right) two portions of this space defining the scope of influence of norms PA:Rp(c, X) and Fa:bp(Y, Z). The scope of these norms overlap, illustrated by the intersection of boxes on the left, in actions with values, for instance, a, b, p(c, 2) , . . . , a, b, p(c, n) . The curtailment of the prohibition eliminates the intersection: it moves the scope of the norm influence to outside the influence of the permission. If there were multiple overlaps among one prohibition and various permissions, which is likely to happen, then the prohibition will be multiply curtailed to move the scope of the norm to avoid all intersections. The algorithm shown in Figure 3 depicts how we obtain a conflictfree set of norms. It maps an existing set Ω possibly with conflictalgorithm conflictResolution(Ω, Ω ) input Ω output Ω begin Ω := Ω for each ω ∈ Ω s.t. ω = (Fa:r ¯ϕ) Σc, td, ta, te do if ω, ω , σ ∈ CFLS(Ω) then Ω := Ω − {ω} end for for each ω ∈ Ω s.t. ω = (Fτ1:τ2 ϕ) Σc, td, ta, te do ΣMAX c := [ ω,ω ,σc ∈CFLS(Ω ) {σc} Ω := (Ω − {ω}) ∪ { (Fτ1:τ2 ϕ) (Σc ∪ ΣMAX c ), td, ta, te } end for end Figure 3: Algorithm to Resolve Conflicts in a Set of Norms ing norms onto a new set Ω in which the conflicts (if any) are resolved. The algorithm forms Ω as a set that is conflict-freethis means that prohibitions are annotated with a conflict set that indicates which bindings for variables have to be avoided. Initially, Ω is set to be Ω. The algorithm operates in two stages. In the first stage (first for each loop), we remove all conflicting prohibitions ω = (Fa:r ¯ϕ) Σc, td, ta, te with ground agent/role pairs a : r and ground formulae ¯ϕ: the only way to resolve conflicts arising from such prohibitions is to remove them altogether, as we cannot curtail a fully ground norm. In the second stage (second for each loop), the remaining prohibitions in Ω are examined: the set CFLS(Ω ) contains all conflicts between permissions and the remaining prohibitions in Ω represented as tuples ω, ω , σc , with σc representing the conflict set. As a prohibition may have conflicts with various permissions, the set CFLS(Ω ) may contain more than one tuple for each prohibition. In order to provide an Ω that reflects all these conflicts for a specific prohibition, we have to form ΣMAX c containing all conflict sets σc for a given prohibition ω. The maximal set is used to update the annotation of the prohibition. It is important to explain the need for updating the conflict set of prohibitions. Normative states change as a result of agents" actions [11]: existing permissions, prohibitions and obligations are revoked and/or new ones are put in place as a result of agents" interactions with the environment and other agents. Whenever new norms are added we must check for new conflicts and inconsistencies. If we only apply our algorithm to a pair consisting of an old and a new norm, then some re-processing of pairs of old norms (which were dealt with before) can be saved. The removal of norms from the set Ω is dealt with efficiently: each permission to be removed must be checked first for conflicts with any existing prohibition (re-processing can be avoided if we record the conflict, instead of detecting it again). If there is a conflict, then the conflict set will have been recorded in the prohibition"s annotation; this conflict set is thus removed from the prohibition"s annotation. The removal of obligations follows a similar process. Prohibitions are removed without the need to consider their relationships with other norms. Our algorithm is correct in that it provides, for a given Ω, a new Ω in which i) all ground prohibitions which conflict with permissions have been removed; and ii) all remaining annotated prohibitions (Fτ:τ ¯ϕ) Σc, td, ta, te will not unify with any of the permissions in Ω , provided the unifier does not appear in Σc. The first requirement is addressed by the first for each loop, which does precisely this: it removes all ground prohibitions which unify with an obligation. The second requirement is addressed by the second for each loop: each prohibition has its annotation Σc added with ΣMAX c , thus accommodating the unifiers from all permissions that unify with the prohibition. It is easy to see that the algorithm always terminates: each of its two loops go through a finite set, processing one element at a time. The set CFLS(Ω) is computed in a finite number of steps as are the set operations performed within each loop. The algorithm has, however, exponential complexity3 , as the computation of CFLS(Ω) requires a pairwise comparison of all elements in Ω. We illustrate our algorithm with the following example. Let there be the following global normative state Ω: j (FA:Rp(X, Y )) {}, 2, 2, 9 , Pa:rp(a, b), 3, 4, 8 , (Fa:rp(a, b)) {}, 2, 4, 12 Pa:rp(d, e), 3, 4, 9 , ff The first loop removes the ground prohibition, thus obtaining the following Ω : j (FA:Rp(X, Y )) {}, 2, 2, 9 , Pa:bp(c, d), 3, 4, 8 , Pe:f p(g, h), 3, 4, 9 ff We then have the following set of conflicting norms CFLS(Ω ): 8 < : * (FA:Rp(X, Y )) {}, 2, 2, 9 , Pa:bp(c, d), 3, 4, 8 , {A/a, R/b, X/c, Y/d} + , * (FA:Rp(X, Y )) {}, 2, 2, 9 , Pe:f p(g, h), 3, 4, 9 , {A/e, R/f, X/g, Y/h} +9 = ; For each prohibition ω ∈ Ω we retrieve all elements from w, w , σ ∈ CFLS(Ω ) and collect their σ"s in ΣMAX c . The final Ω is thus: 8 < : (FA:Rp(X, Y )) j {A/a, R/b, X/c, Y/d} {A/e, R/f, X/g, Y/h} ff , 2, 2, 9 , Pa:rp(a, b), 3, 4, 8 , Pa:rp(d, e), 3, 4, 9 , 9 = ; The annotated set of conflict sets should be understood as a record of past unifications, which informs how prohibitions should be used in the future in order to avoid any conflicts with permissions. We show in Section 5.1 how annotations are used by norm-aware agents. 4. NORM INCONSISTENCIES If a substitution σ can be found that unifies an obligation and a prohibition, then a situation of norm inconsistency occurs [13]. The obligation demands that an agent performs an action that is forbidden. We can reuse the machinery, introduced above for resolving conflicts between permissions and prohibitions, in order to a) detect and b) resolve such inconsistencies. With Definition 7, we 3 The combinatorial effort is not necessary anymore if instead we maintain a set of norms conflict-free: each time a new norm is to be introduced then we compare it with the existing ones, thus making the maintenance process of linear complexity. The Sixth Intl. Joint Conf. on Autonomous Agents and Multi-Agent Systems (AAMAS 07) 647 express the nature of a conflict between a prohibition and permission. Similarly, a situation of inconsistency can be defined reusing this definition and replacing the P deontic modality with O. We can reuse the machinery for conflict resolution, developed previously, for resolving inconsistency. The conflict resolution algorithm can be applied without change to accumulate a maximal conflict set ΣMAX c for each prohibition in Ω that unifies with obligations. 5. NORM-AWARE AGENT SOCIETIES We now describe how our norm-regulated VOs give rise to normaware agent societies. We address open and heterogeneous MASs: we accommodate external agents by providing each of them with a corresponding governor agent [12]. This is a kind of chaperon that interacts with an external agent, and observes and reports on its behaviour. We show our architecture in Figure 4 below: a number External Governor Agents Agents Tuple Space ag1 £ ¢ ¡ gov1 ⇐⇒ . . . . . . . . . . . . I, s, Ξ, Ω I, s , Ξ , Ω · · · agn £ ¢ ¡ govn ⇐⇒ Figure 4: Architecture for Norm-Aware Agent Societies of external agents interact (denoted by the ) with their corresponding governor agents. The governor agents have access to the VO description I, the current state s of the VO enactment, the global execution state Ξ and the global normative state Ω. Governor agents are able to write to and read from (denoted by the ⇐⇒) a shared memory space (e.g., a blackboard-like solution implemented as a tuple space), updating the global configuration (denoted by the ) to reflect the dynamics of the VO enactment. Governor agents are necessary because we cannot anticipate or legislate over the design or behaviour of external agents. We depict below how the pairs of governor/external agents work together: any non-deterministic choices on the VO are decided by the external agent; any normative aspects are considered by the governor agent. The governor agent represents the external agent within the VO. As such, it has the unique identifier of the external agent. The governor agent keeps an account of all roles the external agent is currently playing: in our VOs, it is possible for agents to take up more than one role simultaneously. We define in Figure 5 how governor agents work - we use a logic program for this purpose. We show 1 main(Id, Roles) ← 2 get tuple( I, s, Ξ, Ω )∧ 3 terminate(Id, Roles, I, Ξ, Ω) 4 main(Id, Roles) ← 5 get tuple( I, s, Ξ, Ω )∧ 6 filter norms(Id, Roles, Ω, ΩId )∧ 7 discuss norms(Id, Roles, I, s, Ξ, ΩId , Actions)∧ 8 update tuple(Roles, Actions, NewRoles)∧ 9 main(Id, NewRoles) Figure 5: Governor Agent as a Logic Program the lines of our clauses numbered 1-9. The first clause (lines 1-3) depicts the termination condition: get tuple/1 (line 2) retrieves I, s, Ξ, Ω from the shared tuple space and terminate/4 checks if the current VO enactment (recorded in Ξ) has come to an end. The team of governor agents synchronise their access to the tuple space [12], thus ensuring each has a chance to function. The second clause (lines 4-9) depicts a generic loop when the termination condition of the first clause does not hold. In this case, the tuple is again retrieved (line 5) and the governor agent proceeds (line 6) to analyse the current global normative state Ω with a view to obtaining the subset ΩId ⊆ Ω of norms referring to agent Id under roles Roles. Predicate filter norms/4 collects the norms which apply to agent Id (the governor agent"s external agent). In line 7 the governor agent, in possession of the applicable norms as well as other relevant information, interacts with the external agent to decide on a set of Actions which are norm-compliant - these actions will be used to update (line 8) the global execution state Ξ. In the process of updating the state of execution, a new set of roles must be assigned to the external agent, represented as NewRoles. The governor agent keeps looping (line 9) using the identifier for the external agent and its new set of roles. 5.1 Using Annotated Norms We now explain how annotated norms are used by norm-aware agents. We do so via the definition of predicate check/2, which holds if its first argument, a candidate action (in the format of the elements of Ξ of Def. 2), is within the influence of an annotated prohibition ω, its second parameter. The definition, as a logic program, is shown in Figure 6. It checks (line 4) if the agent identifier 1 check(Action, ω) ← 2 Action = a:r, ¯ϕ, t ∧ 3 ω = (Fτ1:τ2 ϕ) Σc, td, ta, te ∧ 4 unify(a, τ1, σ) ∧ unify(r, τ2, σ) ∧ unify( ¯ϕ, ϕ, σ)∧ 5 forall(σ , (σc ∈ Σc, unify(σc, σ, σ )), MGUs)∧ 6 MGUs = ∅∧ 7 ta ≤ t ≤ te Figure 6: Check if Action is within Influence of Curtailed Norm and role of the action unify with the appropriate terms τ1, τ2 of ω and that the actions ¯ϕ, ϕ themselves unify, all under the same unifier σ. It then verifies (lines 5-6) that σ does not unify with any of the conflict sets in Σc. Finally, in line 7 it checks if the time of the action is within the norm temporal influence. The verification of non-unification of σ with any element of Σc deserves an explanation. The elements of Σc are unifiers stating what values the variables of the norm cannot have, that is, they represent gaps in the original scope of the norm"s influence. The test thus equates to asking if the action is outside such gaps, that is, the action is within the curtailed scope of influence of the norm. 6. ACTION CONFLICT & INCONSISTENCY In our previous discussion, norm conflict and inconsistency were detected via a direct comparison of the atomic formulae representing the action. However, conflicts and inconsistencies may also arise indirectly via relationships among actions. For instance, if p(X) amounts to q(X, X), then norms PA:Rp(X) and FA:Rq(X, X) are in conflict since PA:Rp(X) can be rewritten as PA:Rq(X, X) and we thus have both PA:Rq(X, X) and FA:Rq(X, X). In the discussion below we concentrate on norm conflict, but norm inconsistency can be dealt with similarly, if we change the deontic modalities P for O. Relationships among actions are domain-dependent. Different domains have distinct ways of relating their actions; engineers build ontologies to represent such relationships. We propose a simple means to account for such relationships and show how these can be connected to the mechanisms introduced above. Rather than making use of sophisticated formalisms for ontology construction, we employ a set of domain axioms, defined below: DEF. 9. The domain axioms, denoted as Δ, are a finite and possibly empty set of formulae ϕ → (ϕ1 ∧ · · · ∧ ϕn) where ϕ, ϕi, 1 ≤ i ≤ n, are atomic first-order formulae. Our example above can be captured by Δ = {(p(X) → q(X, X)), (q(X, X) → p(X))}. By explicitly representing and manipulating domain knowledge we achieve generality: the very same machinery can be used with different domains. A set of norms can have different conflicts and inconsistencies, for distinct domains of application. 648 The Sixth Intl. Joint Conf. on Autonomous Agents and Multi-Agent Systems (AAMAS 07) The Sixth Intl. Joint Conf. on Autonomous Agents and Multi-Agent Systems (AAMAS 07) 649 650 The Sixth Intl. Joint Conf. on Autonomous Agents and Multi-Agent Systems (AAMAS 07) The Sixth Intl. Joint Conf. on Autonomous Agents and Multi-Agent Systems (AAMAS 07) 651

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O B O O B O O O B O O O O O O O O O O O O O B O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O O O B O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

multi-agent system
norm-regulated vo
conflicting prohibition
external agent
governor agent
artificial social systems

virtual organization
agent
norm conflict
norm inconsistency


Concept

and

Architecture

of

a

Pervasive

Document

Editing

and

Managing

System

Stefania

Leone

Thomas

B.

Hodel

Harald

Gall

University

of

Zurich,

Switzerland

University

of

Zurich,

Switzerland

University

of

Zurich,

Switzerland

Department

of

Informatics

Department

of

Informatics

Department

of

Informatics

leone@ifi.unizh.ch

hodel@ifi.unizh.ch

gall@ifi.unizh.ch

ABSTRACT

Collaborative

document

processing

has

been

addressed

by

many

approaches

so

far,

most

of

which

focus

on

document

versioning

and

collaborative

editing.

We

address

this

issue

from

a

different

angle

and

describe

the

concept

and

architecture

of

a

pervasive

document

editing

and

managing

system.

It

exploits

database

techniques

and

real-time

updating

for

sophisticated

collaboration

scenarios

on

multiple

devices.

Each

user

is

always

served

with

upto-date

documents

and

can

organize

his

work

based

on

document

meta

data.

For

this,

we

present

our

conceptual

architecture

for

such

a

system

and

discuss

it

with

an

example.

Categories

and

Subject

Descriptors

Distributed

Systems

[Computer-Communication

Networks]:

Computer

System

Organization,

Distributed

Systems,

Distributed

Applications

General

Terms

Management,

Measurement,

Documentation,

Economics,

Human

Factors

INTRODUCTION

Text

documents

are

a

valuable

resource

for

virtually

any

enterprise

and

organization.

Documents

like

papers,

reports

and

general

business

documentations

contain

a

large

part

of

today"s

(business)

knowledge.

Documents

are

mostly

stored

in

a

hierarchical

folder

structure

on

file

servers

and

it

is

difficult

to

organize

them

in

regard

to

classification,

versioning

etc.,

although

it

is

of

utmost

importance

that

users

can

find,

retrieve

and

edit

up-to-date

versions

of

documents

whenever

they

want

and,

in

a

user-friendly

way.

Problem

Description

With

most

of

the

commonly

used

word-processing

applications

documents

can

be

manipulated

by

only

one

user

at

a

time:

tools

for

pervasive

collaborative

document

editing

and

management,

are

rarely

deployed

in

today"s

world.

Despite

the

fact,

that

people

strive

for

location-

and

time-

independence,

the

importance

of

pervasive

collaborative

work,

i.e.

collaborative

document

editing

and

management

is

totally

neglected.

Documents

could

therefore

be

seen

as

a

vulnerable

source

in

today"s

world,

which

demands

for

an

appropriate

solution:

The

need

to

store,

retrieve

and

edit

these

documents

collaboratively

anytime,

everywhere

and

with

almost

every

suitable

device

and

with

guaranteed

mechanisms

for

security,

consistency,

availability

and

access

control,

is

obvious.

In

addition,

word

processing

systems

ignore

the

fact

that

the

history

of

a

text

document

contains

crucial

information

for

its

management.

Such

meta

data

includes

creation

date,

creator,

authors,

version,

location-based

information

such

as

time

and

place

when/where

a

user

reads/edits

a

document

and

so

on.

Such

meta

data

can

be

gathered

during

the

documents

creation

process

and

can

be

used

versatilely.

Especially

in

the

field

of

pervasive

document

management,

meta

data

is

of

crucial

importance

since

it

offers

totally

new

ways

of

organizing

and

classifying

documents:

On

the

one

hand,

the

user"s

actual

situation

influences

the

user"s

objectives.

Meta

data

could

be

used

to

give

the

user

the

best

possible

view

on

the

documents,

dependent

of

his

actual

information.

On

the

other

hand,

as

soon

as

the

user

starts

to

work,

i.e.

reads

or

edits

a

document,

new

meta

data

can

be

gathered

in

order

to

make

the

system

more

adaptable

and

in

a

sense

to

the

users

situation

and,

to

offer

future

users

a

better

view

on

the

documents.

As

far

as

we

know,

no

system

exists,

that

satisfies

the

aforementioned

requirements.

A

very

good

overview

about

realtime

communication

and

collaboration

system

is

described

in

We

therefore

strive

for

a

pervasive

document

editing

and

management

system,

which

enables

pervasive

(and

collaborative)

document

editing

and

management:

users

should

be

able

to

read

and

edit

documents

whenever,

wherever,

with

whomever

and

with

whatever

device.

In

this

paper,

we

present

collaborative

database-based

real-time

word

processing,

which

provides

pervasive

document

editing

and

management

functionality.

It

enables

the

user

to

work

on

documents

collaboratively

and

offers

sophisticated

document

management

facility:

the

user

is

always

served

with

up-to-date

documents

and

can

organize

and

manage

documents

on

the

base

of

meta

data.

Additionally

document

data

is

treated

as

‘first

class

citizen"

of

the

database

as

demanded

in

Underlying

Concepts

The

concept

of

our

pervasive

document

editing

and

management

system

requires

an

appropriate

architectural

foundation.

Our

concept

and

implementation

are

based

on

the

TeNDaX

collaborative

database-based

document

editing

and

management

system,

which

enables

pervasive

document

editing

and

managing.

TeNDaX

is

a

Text

Native

Database

eXtension.

It

enables

the

storage

of

text

in

databases

in

a

native

form

so

that

editing

text

is

finally

represented

as

real-time

transactions.

Under

the

term

‘text

editing"

we

understand

the

following:

writing

and

deleting

text

(characters),

copying

pasting

text,

defining

text

layout

structure,

inserting

notes,

setting

access

rights,

defining

business

processes,

inserting

tables,

pictures,

and

so

on

i.e.

all

the

actions

regularly

carried

out

by

word

processing

users.

With

‘real-time

transaction"

we

mean

that

editing

text

(e.g.

writing

a

character/word)

invokes

one

or

several

database

transactions

so

that

everything,

which

is

typed

appears

within

the

editor

as

soon

as

these

objects

are

stored

persistently.

Instead

of

creating

files

and

storing

them

in

a

file

system,

the

content

and

all

of

the

meta

data

belonging

to

the

documents

is

stored

in

a

special

way

in

the

database,

which

enables

very

fast

real-time

transactions

for

all

editing

tasks

The

database

schema

and

the

above-mentioned

transactions

are

created

in

such

a

way

that

everything

can

be

done

within

a

multiuser

environment,

as

is

usual

done

by

database

technology.

As

a

consequence,

many

of

the

achievements

(with

respect

to

data

organization

and

querying,

recovery,

integrity

and

security

enforcement,

multi-user

operation,

distribution

management,

uniform

tool

access,

etc.)

are

now,

by

means

of

this

approach,

also

available

for

word

processing.

APPROACH

Our

pervasive

editing

and

management

system

is

based

on

the

above-mentioned

database-based

TeNDaX

approach,

where

document

data

is

stored

natively

in

the

database

and

supports

pervasive

collaborative

text

editing

and

document

management.

We

define

the

pervasive

document

editing

and

management

system,

as

a

system,

where

documents

can

easily

be

accessed

and

manipulated

everywhere

(within

the

network),

anytime

(independently

of

the

number

of

users

working

on

the

same

document)

and

with

any

device

(desktop,

notebook,

PDA,

mobile

phone

etc.).

DB

RTSC

RTSC

RTSC

RTSC

AS

AS

DB

DB

AS

AS

DB

A

B

C

D

E

F

G

Figure

TeNDaX

Application

Architecture

In

contrast

to

documents

stored

locally

on

the

hard

drive

or

on

a

file

server,

our

system

automatically

serves

the

user

with

the

up-to-date

version

of

a

document

and

changes

done

on

the

document

are

stored

persistently

in

the

database

and

immediately

propagated

to

all

clients

who

are

working

on

the

same

document.

Additionally,

meta

data

gathered

during

the

whole

document

creation

process

enables

sophisticated

document

management.

With

the

TeXt

SQL

API

as

abstract

interface,

this

approach

can

be

used

by

any

tool

and

for

any

device.

The

system

is

built

on

the

following

components

(see

Figure

An

editor

in

Java

implements

the

presentation

layer

(A-G

in

Figure

The

aim

of

this

layer

is

the

integration

in

a

well-known

wordprocessing

application

such

as

OpenOffice.

The

business

logic

layer

represents

the

interface

between

the

database

and

the

word-processing

application.

It

consists

of

the

following

three

components:

The

application

server

(marked

as

AS

in

Figure

enables

text

editing

within

the

database

environment

and

takes

care

of

awareness,

security,

document

management

etc.,

all

within

a

collaborative,

real-time

and

multi-user

environment.

The

real-time

server

component

(marked

as

RTSC

in

Figure

is

responsible

for

the

propagation

of

information,

i.e.

updates

between

all

of

the

connected

editors.

The

storage

engine

(data

layer)

primarily

stores

the

content

of

documents

as

well

as

all

related

meta

data

within

the

database

Databases

can

be

distributed

in

a

peer-to-peer

network

(DB

in

Figure

In

the

following,

we

will

briefly

present

the

database

schema,

the

editor

and

the

real-time

server

component

as

well

as

the

concept

of

dynamic

folders,

which

enables

sophisticated

document

management

on

the

basis

of

meta

data.

Application

Architecture

A

database-based

real-time

collaborative

editor

allows

the

same

document

to

be

opened

and

edited

simultaneously

on

the

same

computer

or

over

a

network

of

several

computers

and

mobile

devices.

All

concurrency

issues,

as

well

as

message

propagation,

are

solved

within

this

approach,

while

multiple

instances

of

the

same

document

are

being

opened

Each

insert

or

delete

action

is

a

database

transaction

and

as

such,

is

immediately

stored

persistently

in

the

database

and

propagated

to

all

clients

working

on

the

same

document.

Database

Schema

As

it

was

mentioned

earlier

that

text

is

stored

in

a

native

way.

Each

character

of

a

text

document

is

stored

as

a

single

object

in

the

database

When

storing

text

in

such

a

native

form,

the

performance

of

the

employed

database

system

is

of

crucial

importance.

The

concept

and

performance

issues

of

such

a

text

database

are

described

in

collaborative

layouting

in

dynamic

collaborative

business

processes

within

documents

in

the

text

editing

creation

time

meta

data

model

in

and

the

relation

to

XML

databases

in

Figure

depicts

the

core

database

schema.

By

connecting

a

client

to

the

database,

a

Session

instance

is

created.

One

important

attribute

of

the

Session

is

the

DocumentSession.

This

attribute

refers

to

DocumentSession

instances,

which

administrates

all

opened

documents.

For

each

opened

document,

a

DocumentSession

instance

is

created.

The

DocumentSession

is

important

for

the

realtime

server

component,

which,

in

case

of

a

is

beforeis

after

Char

(ID)

has

TextElement

(ID)

starts

with

is

used

by

InternalFile

(ID)

is

in

includes

created

at

has

inserted

by

inserted

is

active

ir

ir

CharacterValue

(Unicode)

has

List

(ID)

starts

starts

with

ends

ends

with

FileSize

has

User

(ID)

last

read

by

last

written

by

created

at

created

by

Style

DTD

(ID)

is

used

by

uses

uses

is

used

by

Authors

arehas

Description

Password

Picture

UserColors

UserListSecurity

has

has

has

has

has

has

FileNode

(ID)

references/isreferencedby

is

dynamic

DynStructure

NodeDetails

has

has

is

NodeType

is

parent

of

has

parent

has

Role

(ID)

created

at

created

created

by

Name

has

Description

is

user

Name

has

has

main

role

FileNodeAccessMatrix

(ID)

has

is

AccessMatrix

read

option

grand

option

write

option

contains

has

access

Times

opened

times

with

by

contains/ispartof

ir

ir

is...andincludes

Lineage

(ID)

references

is

after

is

before

CopyPaste

(ID)

references

is

in

is

copy

of

is

a

copy

from

hasCopyPaste

(ID)

is

activeLength

has

Str

(Stream)

has

inserted

by

inserted

RegularChar

StartChar

EndChar

File

ExternalFile

is

from

URL

Type

(extension)

is

of

Title

has

DocumentSession

(ID)

is

opened

by

has

opened

has

opened

Session

(ID)

isconnectedwith

launched

by

VersionNumber

uses

has

read

option

grand

option

write

option

ends

with

is

used

by

is

in

has

is

unique

DTD

(Stream)

has

has

Name

Column

(ID)

has

set

on

On/off

isvisible…for

false

LanguageProfile

(ID)

has

contains

Name

Profile

Marking

(ID)

has

parent

internal

is

copy

from

hasRank

is

onPosition

starts

with

ends

with

is

logical

style

is

itemized

is

italic

is

enumerated

is

underline

is

is

part

of

Alignment

Size

has

Font

has

hasColor

is

bold

has

uses

ElementName

StylesheetName

isused

by

Process

(ID)

is

running

by

OS

is

web

session

MainRoles

Roles

has

has

Timestamp

(Date,

Time)

created

at

Timestamp

(Date,

Time)

Timestamp

(Date,

Time)

Timestamp

(Date,

Time)

Timestamp

(Date,

Time)created

at

Type

has

Port

IP

has

has

MessagePropagator

(ID)

Picture

(Stream)

Name

Picture

(ID)

has

contains

LayoutBlock

WorkflowBlockLogicalBlock

contains

BlockDataType

has

property

BlockData

is

of

WorkflowInstance

(ID)

isin

TaskInstance

(ID)

has

parent

Timestamp

(Date,

Time)

Timestamp

(Date,

Time)

Timestamp

(Date,

Time)

Timestamp

(Date,

Time)

last

modified

at

completed

at

started

at

created

at

is

on

has

Name

created

by

has

attached

Comment

Typeis

of

Timestamp

(Date,

Time)

Timestamp

(Date,

Time)

Timestamp

(Date,

Time)

created

at

started

at

last

modified

at

is

Category

Editors

has

Status

has

Timestamp

(Date,

Time)

status

last

modified

Timestamp

(Date,

Time)

is

due

at

DueType

has

Timezone

has

Notes

has

SecurityLevel

hasset

Timestamp

(Date,

Time)

is

completed

at

isfollowedby

Task

(Code)

Description

has

Indent

references

hasbeenopenedat...by

Timestamp

RedoHistory

is

before

is

after

references

hasCharCounter

is

inhas

has

Offset

ActionID

(Code)

Timestamp

(Date,

Time)

invoked

at

invoked

by

Version

(ID)

isbuild

from

has

created

byarchived

has

Comment

Timestamp

(Date,

Time)

<<createdat

UndoHistory

(ID)

starts

ends

has

Name

created

by

Name

has

is

before

is

after

references

CharCounter

has

is

in

created

at

Timestamp

is

active

created

by

is

used

by

Offset

has

created

at

Timestamp

Index

(ID)

lastmodifiedby

Lexicon

(ID)

isof

Frequency

is

occurring

is

stop

word

Term

is

is

in

ends

with

starts

with

original

starts

with

WordNumber

SentenceNumber

ParagraphNumber

Citatons

has

is

in

is

is

in

istemporary

is

in

has

Structure

has

ElementPath

createdat

Timestamp

describes

SpiderBuild

(ID)

is

updated

is

deleted

Timestamp

(Date,

Time)

<<lastupdatedat

has

validated

structure

<<neededtoindex

Time

(ms)

IndexUpdate

nextupdatein

hasindexed

isrunningbyOS

lastupdate

enabled

Timestamp

Time

(s)

Documents

StopCharacter

Description

Character

Value

(ASCII)

is

sentence

stop

is

paragraph

stop

Name

has

is

is

OptionsSettings

show

information

show

warningsshow

exceptions

do

lineage

recording

do

internal

lineage

recording

ask

for

unknown

source

show

intra

document

lineage

information

are

set

for

X

X

X

VirtualBorder

(ID)

isonhas

ir

ir

UserMode

(Code)

UserMode

(Code)

Figure

TeNDaX

Database

Schema

(Object

Role

Modeling

Diagram)

change

on

a

document

done

by

a

client,

is

responsible

for

sending

update

information

to

all

the

clients

working

on

the

same

document.

The

DocumentId

in

the

class

DocumentSession

points

to

a

FileNode

instance,

and

corresponds

to

the

ID

of

the

opened

document.

Instances

of

the

class

FileNode

either

represent

a

folder

node

or

a

document

node.

The

folder

node

corresponds

to

a

folder

of

a

file

system

and

the

document

node

to

that

of

a

file.

Instances

of

the

class

Char

represent

the

characters

of

a

document.

The

value

of

a

character

is

stored

in

the

attribute

CharacterValue.

The

sequence

is

defined

by

the

attributes

After

and

Before

of

the

class

Char.

Particular

instances

of

Char

mark

the

beginning

and

the

end

of

a

document.

The

methods

InsertChars

and

RemoveChars

are

used

to

add

and

delete

characters.

Editor

As

seen

above,

each

document

is

natively

stored

in

the

database.

Our

editor

does

not

have

a

replica

of

one

part

of

the

native

text

database

in

the

sense

of

database

replicas.

Instead,

it

has

a

so-called

image

as

its

replica.

Even

if

several

authors

edit

the

same

text

at

the

same

time,

they

work

on

one

unique

document

at

all

times.

The

system

guarantees

this

unique

view.

Editing

a

document

involves

a

number

of

steps:

first,

getting

the

required

information

out

of

the

image,

secondly,

invoking

the

corresponding

methods

within

the

database,

thirdly,

changing

the

image,

and

fourthly,

informing

all

other

clients

about

the

changes.

Real-Time

Server

Component

The

real-time

server

component

is

responsible

for

the

real-time

propagation

of

any

changes

on

a

document

done

within

an

editor

to

all

the

editors

who

are

working

or

have

opened

the

same

document.

When

an

editor

connects

to

the

application

server,

which

in

turn

connects

to

the

database,

the

database

also

establishes

a

connection

to

the

real-time

server

component

(if

there

isn"t

already

a

connection).

The

database

system

informs

the

real-time

server

component

about

each

new

editor

session

(session),

which

the

realtime

server

component

administrates

in

his

SessionManager.

Then,

the

editor

as

well

connects

to

the

real-time

server

component.

The

real-time

server

component

adds

the

editor

socket

to

the

client"s

data

structure

in

the

SessionManager

and

is

then

ready

to

communicate.

Each

time

a

change

on

a

document

from

an

editor

is

persistently

stored

in

the

database,

the

database

sends

a

message

to

the

real-time

server

component,

which

in

turns,

sends

the

changes

to

all

the

editors

working

on

the

same

document.

Therefore,

a

special

communication

protocol

is

used:

the

update

protocol.

Update

Protocol

The

real-time

server

component

uses

the

update

protocol

to

communicate

with

the

database

and

the

editors.

Messages

are

sent

from

the

database

to

the

real-time

server

component,

which

sends

the

messages

to

the

affected

editors.

The

update

protocol

consists

of

different

message

types.

Messages

consist

of

two

packages:

package

one

contains

information

for

the

real-time

server

component

whereas

package

two

is

passed

to

the

editors

and

contains

the

update

information,

as

depicted

in

Figure

RTSC

Parameter

Parameter||

Editor

Data

Protocol

between

database

system

and

real-time

server

component

Protocol

between

real

-time

server

component

and

editors

Figure

Update

Protocol

In

the

following,

two

message

types

are

presented:

||u|sessionId,...,sessionId||||editor

data||

u:

update

message,

sessionId:

Id

of

the

client

session

With

this

message

type

the

real-time

server

component

sends

the

editor

data

package

to

all

editors

specified

in

the

sessionId

list.

||ud|fileId||||editor

data||

ud:

update

document

message,

fileId:

Id

of

the

file

With

this

message

type,

the

real-time

server

component

sends

the

editor

data

to

all

editors

who

have

opened

the

document

with

the

indicated

file-Id.

Class

Model

Figure

depicts

the

class

model

as

well

as

the

environment

of

the

real-time

server

component.

The

environment

consists

mainly

of

the

editor

and

the

database,

but

any

other

client

application

that

could

make

use

of

the

real-time

server

component

can

connect.

ConnectionListener:

This

class

is

responsible

for

the

connection

to

the

clients,

i.e.

to

the

database

and

the

editors.

Depending

on

the

connection

type

(database

or

editor)

the

connection

is

passed

to

an

EditorWorker

instance

or

DatabaseMessageWorker

instance

respectively.

EditorWorker:

This

class

manages

the

connections

of

type

‘editor".

The

connection

(a

socket

and

its

input

and

output

stream)

is

stored

in

the

SessionManager.

SessionManager:

This

class

is

similar

to

an

‘in-memory

database":

all

editor

session

information,

e.g.

the

editor

sockets,

which

editor

has

opened

which

document

etc.

are

stored

within

this

data

structure.

DatabaseMessageWorker:

This

class

is

responsible

for

the

connections

of

type

‘database".

At

run-time,

only

one

connection

exists

for

each

database.

Update

messages

from

the

database

are

sent

to

the

DatabaseMessageWorker

and,

with

the

help

of

additional

information

from

the

SessionManager,

sent

to

the

corresponding

clients.

ServiceClass:

This

class

offers

a

set

of

methods

for

reading,

writing

and

logging

messages.

tdb.mp.editor

tdb.mp.database

tdb.mp.mgmt

EditorWorker

DatabaseMessageWorker

SessionManager

MessageHandler

ConnectionListener

ServiceClass

MessageQueue

tdb.mp.listener

tdb.mp.service

junit.tests

Editors

Datenbanksystem

TCP/IP

Figure

Real-Time

Server

Component

Class

Diagram

Dynamic

Folders

As

mentioned

above,

every

editing

action

invoked

by

a

user

is

immediately

transferred

to

the

database.

At

the

same

time,

more

information

about

the

current

transaction

is

gathered.

As

all

information

is

stored

in

the

database,

one

character

can

hold

a

multitude

of

information,

which

can

later

be

used

for

the

retrieval

of

documents.

Meta

data

is

collected

at

character

level,

from

document

structure

(layout,

workflow,

template,

semantics,

security,

workflow

and

notes),

on

the

level

of

a

document

section

and

on

the

level

of

the

whole

document

All

of

the

above-mentioned

meta

data

is

crucial

information

for

creating

content

and

knowledge

out

of

word

processing

documents.

This

meta

data

can

be

used

to

create

an

alternative

storage

system

for

documents.

In

any

case,

it

is

not

an

easy

task

to

change

users"

familiarity

to

the

well

known

hierarchical

file

system.

This

is

also

the

main

reason

why

we

do

not

completely

disregard

the

classical

file

system,

but

rather

enhance

it.

Folders

which

correspond

to

the

classical

hierarchical

file

system

will

be

called

static

folders.

Folders

where

the

documents

are

organized

according

to

meta

data,

will

be

called

dynamic

folders.

As

all

information

is

stored

in

the

database,

the

file

system,

too,

is

based

on

the

database.

The

dynamic

folders

build

up

sub-trees,

which

are

guided

by

the

meta

data

selected

by

the

user.

Thus,

the

first

step

in

using

a

dynamic

folder

is

the

definition

of

how

it

should

be

built.

For

each

level

of

a

dynamic

folder,

exactly

one

meta

data

item

is

used

to.

The

following

example

illustrates

the

steps

which

have

to

be

taken

in

order

to

define

a

dynamic

folder,

and

the

meta

data

which

should

be

used.

As

a

first

step,

the

meta

data

which

will

be

used

for

the

dynamic

folder

must

be

chosen

(see

Table

The

sequence

of

the

meta

data

influences

the

structure

of

the

folder.

Furthermore,

for

each

meta

data

used,

restrictions

and

granularity

must

be

defined

by

the

user;

if

no

restrictions

are

defined,

all

accessible

documents

are

listed.

The

granularity

therefore

influences

the

number

of

sub-folders

which

will

be

created

for

the

partitioning

of

the

documents.

As

the

user

enters

the

tree

structure

of

the

dynamic

folder,

he

can

navigate

through

the

branches

to

arrive

at

the

document(s)

he

is

looking

for.

The

directory

names

indicate

which

meta

data

determines

the

content

of

the

sub-folder

in

question.

At

each

level,

the

documents,

which

have

so

far

been

found

to

match

the

meta

data,

can

be

inspected.

Table

Defining

dynamic

folders

(example)

Level

Meta

data

Restrictions

Granularity

Creator

Only

show

documents

which

have

been

created

by

the

users

Leone

or

Hodel

or

Gall

One

folder

per

creator

Current

location

Only

show

documents

which

where

read

at

my

current

location

One

folder

per

task

status

Authors

Only

show

documents

where

at

least

was

written

by

user

‘Leone"

Each

one

folder

ad-hoc

changes

of

granularity

and

restrictions

are

possible

in

order

to

maximize

search

comfort

for

the

user.

It

is

possible

to

predefine

dynamic

folders

for

frequent

use,

e.g.

a

location-based

folder,

as

well

as

to

create

and

modify

dynamic

folders

on

an

ad-hoc

basis.

Furthermore,

the

content

of

such

dynamic

folders

can

change

from

one

second

to

another,

depending

on

the

changes

made

by

other

users

at

that

moment.

VALIDATION

The

proposed

architecture

is

validated

on

the

example

of

a

character

insertion.

Insert

operations

are

the

mostly

used

operations

in

a

(collaborative)

editing

system.

The

character

insertion

is

based

on

the

TeNDaX

Insert

Algorithm

which

is

formally

described

in

the

following.

The

algorithm

is

simplified

for

this

purpose.

Insert

Characters

Algorithm

The

symbol

c

stands

for

the

object

character,

p

stands

for

the

previous

character,

n

stands

for

the

next

character

of

a

character

object

c

and

the

symbol

l

stands

for

a

list

of

character

objects.

c

character

p=previous

character

n

next

character

l

list

of

characters

The

symbol

stands

for

the

first

character

in

the

list

l,

ci

stands

for

a

character

in

the

list

l

at

the

position

i,

whereas

i

is

a

value

between

and

the

length

of

the

list

l,

and

cn

stands

for

the

last

character

in

the

list

l.

first

character

in

list

l

ci

character

at

position

i

in

list

l

cn

last

character

in

list

l

The

symbol

β

stands

for

the

special

character

that

marks

the

beginning

of

a

document

and

ε

stands

for

the

special

character

that

marks

the

end

of

a

document.

β=beginning

of

document

ε=end

of

document

The

function

startTA

starts

a

transaction.

startTA

start

transaction

The

function

commitTA

commits

a

transaction

that

was

started.

commitTA

commit

transaction

The

function

checkWriteAccess

checks

if

the

write

access

for

a

document

session

s

is

granted.

checkWriteAccess(s)

check

if

write

access

for

document

session

s

is

granted

The

function

lock

acquires

an

exclusive

lock

for

a

character

c

and

returns

for

a

success

and

for

no

success.

lock(c)

acquire

the

lock

for

character

c

success

return

no

success

return

The

function

releaseLocks

releases

all

locks

that

a

transaction

has

acquired

so

far.

releaseLocks

release

all

locks

The

function

getPrevious

returns

the

previous

character

and

getNext

returns

the

next

character

of

a

character

c.

getPrevious(c)

return

previous

character

of

character

c

getNext(c)

return

next

character

of

character

c

The

function

linkBefore

links

a

preceding

character

p

with

a

succeeding

character

x

and

the

function

linkAfter

links

a

succeeding

character

n

with

a

preceding

character

y.

linkBefore(p,x)

link

character

p

to

character

x

linkAfter(n,y)

link

character

n

to

character

y

The

function

updateString

links

a

character

p

with

the

first

character

of

a

character

list

l

and

a

character

n

with

the

last

character

cn

of

a

character

list

l

updateString(l,

p,

n)

linkBefore(p

cl)∧

linkAfter(n,

cn

The

function

insertChar

inserts

a

character

c

in

the

table

Char

with

the

fields

After

set

to

a

character

p

and

Before

set

to

a

character

n.

insertChar(c,

p,

n)

linkAfter(c,p)

linkBefore(c,n)

linkBefore(p,c)

linkAfter(n,c)

The

function

checkPreceding

determines

the

previous

character's

CharacterValue

of

a

character

c

and

if

the

previous

character's

status

is

active.

checkPreceding(c)

return

status

and

CharacterValue

of

the

previous

character

The

function

checkSucceeding

determines

the

next

character's

CharacterValue

of

a

character

c

and

if

the

next

character's

status

is

active.

checkSucceeding(c)

return

status

and

CharacterValue

of

the

next

character

The

function

checkCharValue

determines

the

CharacterValue

of

a

character

c.

checkCharValue(c)

return

CharacterValue

of

character

c

The

function

sendUpdate

sends

an

update

message

(UpdateMessage)

from

the

database

to

the

real-time

server

component.

sendUpdate(UpdateMessage)

The

function

Read

is

used

in

the

real-time

server

component

to

read

the

UpdateMessage.

Read(UpdateInformationMessage)

The

function

AllocatEditors

checks

on

the

base

of

the

UpdateMessage

and

the

SessionManager,

which

editors

have

to

be

informed.

AllocateEditors(UpdateInformationMessage,

SessionManager)

returns

the

affected

editors

The

function

SendMessage(EditorData)

sends

the

editor

part

of

the

UpdateMessage

to

the

editors

SendMessage(EditorData)

In

TeNDaX,

the

Insert

Algorithm

is

implemented

in

the

class

method

InsertChars

of

the

class

Char

which

is

depicted

in

Figure

The

relevant

parameters

for

the

definitions

beneath,

are

introduced

in

the

following

list:

nextCharacterOID:

OID

of

the

character

situated

next

to

the

string

to

be

inserted

previousCharacterOID:

OID

of

the

character

situated

previously

to

the

string

to

be

inserted

characterOIDs

(List):

List

of

character

which

have

to

be

inserted

Thus,

the

insertion

of

characters

can

be

defined

stepwise

as

follows:

Start

a

transaction.

startTA

Select

the

character

that

is

situated

before

the

character

that

follows

the

string

to

be

inserted.

getPrevious(nextCharacterOID)

PrevChar(prevCharOID)

Π

After

ϑOID

nextCharacterOID(Char))

Acquire

the

lock

for

the

character

that

is

situated

in

the

document

before

the

character

that

follows

the

string

which

shall

be

inserted.

lock(prevCharId)

At

this

time

the

list

characterOIDs

contains

the

characters

to

cn

that

shall

be

inserted.

characterOIDs={

cn

Each

character

of

the

string

is

inserted

at

the

appropriate

position

by

linking

the

preceding

and

the

succeeding

character

to

it.

For

each

character

ci

of

characterOIDs:

insertChar(ci,

p,

n)

Whereas

ci

cn

Check

if

the

preceding

and

succeeding

characters

are

active

or

if

it

is

the

beginning

or

the

end

of

the

document.

checkPreceding(prevCharOID)

IsOK(IsActive,

CharacterValue)

Π

IsActive,

CharacterValue

(ϑ

OID

nextCharacterOID(Char))

checkSucceeding(nextCharacterOID)

IsOK(IsActive,

CharacterValue)⇐

Π

IsActive,

CharacterValue

(ϑ

OID

nextCharacterOID(Char))

Update

characters

before

and

after

the

string

to

be

inserted.

updateString(characterOIDs,

prevCharOID,

nextCharacterOID)

Release

all

locks

and

commit

Transaction.

releaseLocks

commitTA

Send

update

information

to

the

real-time

server

component

sendUpdate(UpdatenMessage)

Read

update

message

and

inform

affected

editors

of

the

change

Read(UpdateMessage)

Allocate

Editors(UpdateMessage,

SessionManager)

SendMessage(EditorData)

Insert

Characters

Example

Figure

gives

a

snapshot

the

system,

i.e.

of

its

architecture:

four

databases

are

distributed

over

a

peer-to-peer

network.

Each

database

is

connected

to

an

application

server

(AS)

and

each

application

server

is

connected

to

a

real-time

server

component

(RTSC).

Editors

are

connected

to

one

or

more

real-time

server

components

and

to

the

corresponding

databases.

Considering

that

editor

A

(connected

to

database

and

and

editor

B

(connected

to

database

and

are

working

on

the

same

document

stored

in

database

Editor

B

now

inserts

a

character

into

this

document.

The

insert

operation

is

passed

to

application

server

which

in

turns,

passes

it

to

the

database

where

an

insert

operation

is

invoked;

the

characters

are

inserted

according

to

the

algorithm

discussed

in

the

previous

section.

After

the

insertion,

database

sends

an

update

message

(according

to

the

update

protocol

discussed

before)

to

real-time

server

component

(via

AS

RTCS

combines

the

received

update

information

with

the

information

in

his

SessionManager

and

sends

the

editor

data

to

the

affected

editors,

in

this

case

to

editor

A

and

B,

where

the

changes

are

immediately

shown.

Occurring

collaboration

conflicts

are

solved

and

described

in

SUMMARY

With

the

approach

presented

in

this

paper

and

the

implemented

prototype,

we

offer

real-time

collaborative

editing

and

management

of

documents

stored

in

a

special

way

in

a

database.

With

this

approach

we

provide

security,

consistency

and

availability

of

documents

and

consequently

offer

pervasive

document

editing

and

management.

Pervasive

document

editing

and

management

is

enabled

due

to

the

proposed

architecture

with

the

embedded

time

server

component,

which

propagates

changes

to

a

document

immediately

and

consequently

offers

up-to-date

documents.

Document

editing

and

managing

is

consequently

enabled

anywhere,

anytime

and

with

any

device.

The

above-descried

system

is

implemented

in

a

running

prototype.

The

system

will

be

tested

soon

in

line

with

a

student

workshop

next

autumn.

REFERENCES

Abiteboul,

S.,

Agrawal,

R.,

et

al.:

The

Lowell

Database

Research

Self

Assessment.

Massachusetts,

USA,

Hodel,

T.

B.,

Businger,

D.,

and

Dittrich,

K.

R.:

Supporting

Collaborative

Layouting

in

Word

Processing.

IEEE

International

Conference

on

Cooperative

Information

Systems

(CoopIS),

Larnaca,

Cyprus,

IEEE,

Hodel,

T.

B.

and

Dittrich,

K.

R.:

"Concept

and

prototype

of

a

collaborative

business

process

environment

for

document

processing."

Data

Knowledge

Engineering

Special

Issue:

Collaborative

Business

Process

Hodel,

T.

B.,

Dubacher,

M.,

and

Dittrich,

K.

R.:

Using

Database

Management

Systems

for

Collaborative

Text

Editing.

ACM

European

Conference

of

Computersupported

Cooperative

Work

(ECSCW

CEW

Helsinki,

Finland,

Hodel,

T.

B.,

Gall,

H.,

and

Dittrich,

K.

R.:

Dynamic

Collaborative

Business

Processes

within

Documents.

ACM

Special

Interest

Group

on

Design

of

Communication

(SIGDOC)

Memphis,

USA,

Hodel,

T.

B.,

R.

Hacmac,

and

Dittrich,

K.

R.:

Using

Text

Editing

Creation

Time

Meta

Data

for

Document

Management.

Conference

on

Advanced

Information

Systems

Engineering

Porto,

Portugal,

Springer

Lecture

Notes,

Hodel,

T.

B.,

Specker,

F.

and

Dittrich,

K.

R.:

Embedded

SOAP

Server

on

the

Operating

System

Level

for

ad-hoc

Automatic

Real-Time

Bidirectional

Communication.

Information

Resources

Management

Association

(IRMA),

San

Diego,

USA,

O"Kelly,

P.:

Revolution

in

Real-Time

Communication

and

Collaboration:

For

Real

This

Time.

Application

Strategies:

In-Depth

Research

Report.

Burton

Group,

O O O O O B I I I I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I I I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

pervasive document edit and management system

pervasive document editing and managing system