Sergei Kuksin
email: sergei.kuksin@imj-prg.fr

Ergodicity, mixing and KAM

In this note we review recent progress in the problem of mixing for a nonlinear PDE of parabolic type, perturbed by a bounded random force.

Introduction

We are concerned with evolutionary nonlinear PDEs under periodic boundary conditions, perturbed by finite-dimensional random force. We write their solutions u(t, x) as curves u ω (t) = u ω (t, •) ∈ H

where (H, • ) is a certain Hilbert space of functions of x (usually this is a Sobolev space over L 2 ). We are interested in equations of the form u + Lu + B(u) = η(t), u(0) = u 0 , u(t) ∈ H, (1.1)

1
where L = -∆ (or, more generally, L = (-∆) a , a > 0) is the dissipation, B is a nonlinearity (its linear part may be non-zero), and η(t) = η ω (t, x) is a random force. We assume that eq. (1.1) is well posed if the function η(t) 2 is integrable on bounded segments. We regard Lu and η(t) as a perturbation and are the most interested in the case when the unperturbed equation

u + B(u) = 0 (1.2) B
is a Hamiltonian PDE. The problem of long time behaviour in hamiltonian systems (1.2) is related to the ergodic hypothesis and is hopelessly complicated. Instead our goal is to study the long-time dynamics of the perturbed eq. (1.1). Consider eigen-functions of the operator L (these are simply the complex exponents), and label them by natural numbers:

Le j = λ j e j , j = 1, 2, . . . .

1

We will decompose vectors u ∈ H in this basis, u = ∞ s=1 u s e s , and will identify any u ∈ H with the vector of its Fourier coefficients:

u = (u 1 , u 2 , . . . ).
Let us take any set M ⊂ N of indices j, finite or infinite, and consider the subspace

H M ⊂ H, H M = span(e j , j ∈ M ).
The random force η is assumed to be of the form

η(t) = j∈M a j η ω j (t)e j ∈ H M , a 2 j < ∞, (1.3) 2
where η j 's are i.i.d. real random processes. If |M | < ∞, the force η is called finite-dimensional. With this notation eq. (1.1) may be written as uj + λ j u j + B j (u) = a j η ω j (t), j ≥ 1;

a j = 0 if j ∈ M .
The objection is to show that a large class of "non-degenerate" equations (1.1) with finite-dimensional random forces η is "ergodic", more precisely -mixing: Denote by u(t; u 0 ) a solution of (1.1), equal u 0 at t = 0. It depends on a random parameter ω ∈ Ω, F, P ). What was known about the mixing in equations (1.1): i) If H M = H, then the mixing is proved for various classes of equations, see in [START_REF] Kuksin | Mathematics of Two-Dimensional Turbulence[END_REF]. ii) If the set M is finite, then what was available is the result of Hairer-Mattingly [START_REF] Hairer | Ergodicity of the 2D Navier-Stokes equations with degenerate stochastic forcing[END_REF] who proved the mixing for the case of white in time forces η. Their proof is based on an infinite-dimensional version of the Malliavin calculus and applies to a rather special class of eq. (1.1), which includes the 2d NSE on the torus. In particular, this approach does not apply if B(u) is a Hamiltonian nonlinearity which is a polynomial of degree > 3 (this restriction on the degree of nonlinearity also remains true for finite-dimensional systems). Even more: for some important equations (B) corresponding equations (1.1) with white-noise forces are not known to be well posed, while equations (1.1) with bounded random forces are well posed, and -as our results imply -are mixing. For example, this is the case for the primitive equations of atmosphere which are principal equations of meteorology (the stochastic primitive equations are known to be well posed only in some weak sense).

Below I present recent result on the mixing in equations (1.1) with bounded random forces, recently obtained in [2] and [START_REF] Kuksin | Exponential mixing for dissipative PDEs with bounded non-degenerate noise[END_REF]. In [START_REF] Kuksin | Exponential mixing for dissipative PDEs with bounded non-degenerate noise[END_REF] the approach of the original work [2] is repeated for an easier problem which resulted in a shorter and more accessible text.

Acknowledgements. I thank l'Agence Nationale de la Recherche for support through the project ANR-10-BLAN 0102, and the Russian Science Foundation -through the grant 18-11-00032.

2 Bounded random forces.

Recall that the random force η(t) has the form (1.3), where η ω 1 (t), η ω 2 (t), . . . are i.i.d. bounded random processes. To define a suitable class of processes η j we use a naive approach: Let {h 1 (t), h 2 (t), . . .} be a basis of functions on [0, ∞), made by bounded functions. We define

η ω j (t) = ∞ k=1 c k ξ jω k h k (t), c k = 0,
where {ξ jω k } are i.i.d., |ξ jω k | ≤ 1. So η j 's are random series in the basis {h j }. For our techniques to apply, we have to impose on the basis {h j } a restriction. For j ∈ N let us denote J j = [j -1, j]. We assume that for every function h l (t), its support belongs to some segment J j , j = j(l).

Our favorite example of a base as above is the Haar base "of step 1" {h j,l (t), j, l ≥ 0}. Each function h 0,l is a characteristic function of the segment [l, l + 1], while for j ≥ 1 each h j,l is a "dipole" of unit L 2 -norm on the segment [2 -j l, 2 -j (l+1)]:

h j,l (t) =      0 for t < l2 -j or t ≥ (l + 1)2 -j , 2 j/2 for l2 -j ≤ t < l + 1 2 2 -j , -2 j/2 for l + 1 2 2 -j ≤ t < (l + 1)2 -j .
This is an orthonormal base of L 2 (0, ∞).

Now consider the random force η(t, x) = j∈M a j η ω j (t)e j (x). We take the processes η j (t) to be i.i.d. random Haar series:

η 1 (t) = ∞ k=0 c k ∞ l=0 ξ ω k,l h k,l (t) , c k = 0.
(2.1) 3

Here {ξ ω k,l , k, l ≥ 0} are i.i.d. bounded random variables such that |ξ k,l | ≤ 1 a.s. and Dξ k,l = p(x) dx, where p(x) is a Lipschitz function, p(0) = 0.

It is known that if c k ≡ 1 and {ξ ω k,l } are independent N (0, 1) r.v., then (2.1) is a white noise. We assume that the random process in eq. (1.1) is much smoother than that: the i.i.d. r.v. {ξ ω k,l } are bounded and the process is "smooth in time":

|c n | ≤ Cn -q 2 -n/2 , for each n, (2.2) 33
where q > 1. Such processes are called red noises.

Consider any red noise η 1 as in. (2.1), (2.2), and for N ∈ N consider the process

β ω N (T ) = 1 √ N N T 0 η ω 1 (t)dt = c 0 1 √ N [N T ]-1 l=0 ξ ω 0,l + O N T -[N T ] √ N .
Its trajectories are Lipschitz functions of T , and by Donsker's invariance principle the process β N (T )/σ, σ 2 = E(ξ 0,0 ) 2 , converges in distribution to the Wiener process. That is, on large time-scales η 1 behaves as a Wiener process. So the red noises are "smoother siblings" of the white noise.

In view of (2.2) and since a 2 j < ∞, the force η(t) is bounded in H, uniformly in t and ω. Since (1.1) is a well posed equation of parabolic type, then usually it possesses the following regularity property, which is being assumed below: there is a compact set X ⊂ H such that ∀ u 0 ∈ H there exists t( u 0 ) ≥ 0 such that u(t) ∈ X ∀ t ≥ t( u 0 ), ∀ ω.

Shift Operator S

We wish to pass from continuous to discrete time. To do that let us cut R + to the unit segments J l , l ≥ 1, and consider the process η, restricted to any J j :

η j (t) = η(t -(j -1)), 0 ≤ t ≤ 1, η j : [0, 1] → H M . Denote E = L 2 (0, 1; H M ).
Then the law of η j is a measure in E, independent from j, and supp D η j is a compact set in E since the r.v. ξ k,l are bounded and

a 2 j < ∞, c k < ∞.
Operator S. Consider the operator S : H × E → H, (u 0 , η 1 ) → u(1); u(t) -solution of eq. (1.1), u(0) = u 0 .

Then u(2) = S(u(1), η 2 ), etc. Our task is to understand iterations of the operator S, i.e. to study the equation This operator examines how a solution u(t) at t = 1 changes when we modify infinitesimally the force η(t), 0 ≤ t ≤ 1, keeping u(0) fixed. More precisely for any given u 0 ∈ H and η 0 ∈ E to calculate D η S(u 0 , η 0 )( ξ), ξ ∈ E, we do the following: find a solution u(t) of (1.1) for 0 ≤ t ≤ 1 such that u(0) = u 0 , η = η 0 . Linearise eq.( 1.1) about this u(t) and add to the obtained linear eq. the r.h.s. ξ:

u k+1 = S(u k , η k+1 ), k ∈ N, ( 3
v + Lv + dB(u(t))(v(t)) = ξ(t), v(0) = 0, 0 ≤ t ≤ 1. Consider v(1) ∈ H. This is D η S(u 0 , η 0 )( ξ).

The main theorem

We require from the shift-operator S the following three properties:

(H 1 ) (regularity). a) S(X× suppD( η j )) ⊂ X for some compact X ⊂ H, and b) there is a compactly embedded Banach space V H such that:

S : H × E → V is C 2 -smooth.
(H 2 ) (stability of 0). If in (1.1) η ≡ 0, then all solutions of (1.1) converge to 0 exponentially.

(H 3 ) (approximate linearised controllability). This assumption is a key point. It exists in a strong and weak forms:

(H strong 3

) For each point u ∈ X and every ξ ∈ E, ξ ∈ supp D( η 1 ), the mapping D η S(u, ξ) : E → H has dense image in H.

This condition is easy to verify. It holds if M = N (all modes are excited), but it does not hold if M is a finite set. To work with finite-dimensional random forces η we evoke a weaker condition: (H weak 3 ) For each point u ∈ X there exists a null-set Ω u such that if ω / ∈ Ω u , then the range of the linear operator D η S(u, η ω ) is dense in H.

FACT (see [2]

). If eq. (1.1) is the 2d NSE, or eq. (1.1) is the CGL equation ) hold, and the mapping S is analytic.

u -∆u -iγ∆u + i|u| 2p u = η(t, x), > 0, γ ≥ 0, x ∈ T d , where
The assertion 2) is proved in [2], and assertion 1) is established in [START_REF] Kuksin | Exponential mixing for dissipative PDEs with bounded non-degenerate noise[END_REF], using the method of [2].

5 How do we prove this? ("Doeblin meets Kolmogorov")

Let u(t) ∈ X and u (t) ∈ X be two solutions of (1.1) with initial data u 0 and u 0 . It is not hard to see that in our setting to prove the mixing we should verify that dist(Du(t), Du (t)) → 0 as t → ∞, (5.1) 4 for all u 0 , u 0 . How to establish (5.1) ?

Doeblin' coupling, a.k.a. the method of two equations. In X × X consider the integer-time dynamics (u k , v k ), k ≥ 1, where

(u 0 , v 0 ) = (u 0 , u 0 ), (u k , v k ) = (S(u k-1 , η k ), S(v k-1 , η k ), k ≥ 1, with η k = η k (u k-1 , v k-1 , η k ) such that D η k = D η k . (5.2) 6
Then for each k, u k = u(k) and Dv k = Du (k). If we can choose η k , k ≥ 1, such that (5.2) holds and

u k -v k → 0 as k → ∞ a.s., (5.3)
* then dist(Du(k), Du (k)) → 0 as k → ∞, and our goal (5.1) is achieved.

To achieve (5.3), at Step 1 we wish to choose the kick η 1 , depending on u 0 , v 0 and η, in such a way that D η 1 = D η 1 , and

u 1 -v 1 is small with hight probability.
Then the law of u 1 will be "rather close" to that of v 1 , and iterating we will get (5.3).

We have to distinguish two cases:

a) u 0 -v 0 ≤ δ 0 ,
where δ 0 is an additional small parameter; b) u 0 -v 0 > δ 0 .

In case b) we choose for η 1 an independent copy of η 1 , and use the assumption (H 2 ) (stability of zero) to achieve a) with positive probability, in a few steps. Now let u 0 -v 0 = δ 1. This is the main difficulty. Then we choose

η 1 = Ψ u0,v0 ( η 1 ),
where Ψ is an unknown mapping which preserves the measure D η 1 , so D η 1 = D η 1 . The dream would be to find Ψ such that

u 1 -v 1 = S(u 0 , η 1 ) -S(v 0 , Ψ u0,v0 ( η 1 )) = 0 ∀ η 1 .
(5.4) 7

Then v 1 = u 1 a.s., and (5.1) is achieved. But this is hardly possible since it is very exceptional that D(S(u 0 , η 1 )) = D(S(u 0 , η 1 )) for u 0 = u 0 . The situation is reminiscent to that treated by Kolmogorov in his celebrated work which initiated the KAM theory. There Kolmogorov considers a perturbation of an integrable Hamiltonian, H 1 (p, q) = H 0 (p) + εh(p, q), ε 1, (p, q) ∈ P × T n , (5.5) KK

where P is a domain in R n . If exists a canonical transformation S : P 1 × T n → P × T n , where P 1 is a large subdomain of P , such that

H 1 • S = H 0 (p), ( 5
(H 0 + εh) • (id + εS 1 ) = H 0 (p) + εh 1 (p, q) + O(ε 2 ),
1 here S 1 is a vectorfield, and the expression id+εS should be properly understood.

and to search for an S 1 such that h 1 = O(ε 2 ). This transformation should be defined for p from a large subdomain P 1 ⊂ P . The term h 1 linearly depends on S, so the equation h 1 (S) = 0 (5.7) K0

is linear in S. It is called homological equation, and one looks for its approximate solution with a disparity of order ε. If such an S 1 exists, then replacing H 1 with the transformed Hamiltonian H 2 = H 1 • (id+εS 1 ) we arrive at a Hamiltonian of the form (5.5) but with ε replaced by Cε 2 . Then we would iterate the procedure and after infinitely many steps will arrive at a transformation S which satisfies (5.6) for all p from a Borel subset of P of large measure.

Let us proceed likewise with the impossible equation (5.4). Namely, for δ = u 0 -v 0 ≤ δ 0 let us re-write the equation, looking for the mapping Ψ u0,v0 in the form Ψ u0,v0 = id + δΦ and neglecting in (5.4) terms ∼ δ 2 . Then eq. (5.4) reeds

δ[D η S(u 0 , η 1 )Φ( η 1 ) -S ∆ (u 0 , v 0 , η 1 )] + O(δ 2 ) = 0,
where S ∆ = δ -1 (S(v 0 , η 1 )-S(u 0 , η 1 )) ∼ 1. Requiring that the sum of the terms in the square brackets vanishes we get the homological equation:

D η S(u 0 , η 1 )Φ = S ∆ (u 0 , v 0 , η 1 ), Φ =? (5.8) hom_eq -If (H strong 3
) holds, we can solve the homological equation approximately.

-If (H weak 3 ) holds, we can solve it approximately for all ω's outside some bad event Ω 1 u0 of small measure, like in the Kolmogorov scheme above, where the homological equation (5.7) may be non-soluble, even approximatively, for p from some small subset of P .

With the solution Φ = Φ( η 1 ) in hands we, as planned, choose η 1 = η 1 + δΦ( η 1 ). Then u 1 -v 1 δ for ω outside Ω 1 u0 . Note that since the control for the norm of the solution Φ of (5.8) is very poor, then now, in difference with KAM, we cannot obtain the quadratic approximation

u 1 -v 1 δ 2 = u 0 -v 0 2 ,
despite the method we are using is quadratic! We only can achieve that u 1 -v 1 ≤ 1 2 δ. But this turns out to be enough to get the convergence (5.1).

Two main problems appear on the way:

1) what should we do when ω / ∈ Ω 1 u0 , so we cannot solve (5.8) approximately? 2) the mapping η 1 → η 1 = Ψ( η 1 ) = η 1 + δΦ( η 1 ) does not preserve the measure D( η 1 ), so D( η 1 ) = D( η 1 ).

The difficulty 1) usually is present in KAM (there we simply throw away the set of bad parameters). The second difficulty is specific for this setting. What should we do?

Answer to 1). If ω /

∈ Ω 1 u0 , we take η 1 = η 1 (the trivial coupling). Then u 1 -v 1 = S(u 0 , η 1 ) -S(v 0 , η 1 ) ≤ C u 0 -v 0 = Cδ, where C is the Lipchitz constant. If still u 1 -v 1 ≤ δ 0 , we play the same game.

If u 1 -v 1 > δ 0 , we play the game a), i.e., choose η 1 to be an independent copy of η 1 .

Answer to 2). Despite D( η 1 ) = D( η 1 ), these two laws turn out to be close:

D( η 1 ) -D( η 1 ) var ≤ Cδ a , a > 0.
This is enough for us: careful analysis, similar to that in Sections 3.2.2-3.2.3 of [START_REF] Kuksin | Mathematics of Two-Dimensional Turbulence[END_REF], shows that iterating a) and b) we prove the theorem.

. 1 )

 1 S_eqwhere u 0 ∈ H is given. Certainly for k ∈ N the solution of (3.1) after k step equals u(k; u 0 ).Differential of S in η. For u ∈ H, η ∈ E consider the linearised in η map S: D η S(u, η) : E → H.

  ). For the 2d NSE similar results were first obtained by Weinan E, Mattingly, Pardoux, Hairer, next they were properly understood by Agrachev-Sarychev, and developed further by Shirikyan, Nersesyan and others.

		a) either d = 2 and p is any, or
		b) d = 3 and p ≤ 2, or
		b) d is any, p is any, γ = 0,
		and the force η ω (t, x) is a red noise as above, then:
		1) if M = N, then (H 1 )-(H strong 3 2) if M is a finite set, satisfying some small restrictions, then (H 1 )-(H weak ) holds. 3	)
		hold.
		The hardest is to check (H weak 3
	t_main	Theorem 4.1. Equation (1.1) is exponentially mixing if either
		1) (H 1 )-(H strong 3	) hold,
		or if
		2) (H 1 )-(H weak 3

  .6) KKK then the equation with the transformed Hamiltonian H 1 • S would be integrable on P 1 ×T n . Since Poincaré it is well known that normally such a transformation S does not exist. So instead of the hopeless equationH 1 • S -H 0 (p) = 0, S =?,Kolmogorov suggested to look for S in the form S =id+εS 1 , 1 to linearise the equation in ε,


Pascal Dugénie
email: dugenie@lirmm.fr

Philippe Lemoisson
email: lemoisson@lirmm.fr

Clement Jonquet
email: jonquet@lirmm.fr

Monica Crubézy
email: crubezy@stanford.edu

The Grid Shared Desktop: a bootstrapping environment for collaboration

Keywords: CSCL, Computer Supported Collaborative Learning, Grid, GSD, Grid Shared Desktop, collaborative ontology building

published or not. The documents may come

Introduction

Nowadays, everyone is familiar in using a desktop to interact with a computer. Graphical user interfaces are designed to allows users to manipulate graphical representations of concepts. Although the idea of desktop is commonly established, the idea of sharing a desktop is having much less interest for various reasons. Among these reasons, privacy and security are often seen as the major reason for people to be reluctant. Therefore, the main requirement for accepting to share a desktop with others is to share an environment that is not private. Furthermore, we believe that this environment should be ubiquitous and dedicated to the purpose of the community. We adopted the Grid as underlying technology to provide such a pervasive environment. Amongst other advantages, Grid offers a scalable, secure and reliable infrastructure that enables to achieve a GSD environment in which users may import new services and introduce new users dynamically according to the needs of the collaboration. Among the eLearning and semantic Grid activities, the GSD represents a typical example of what DeRoure et al. call a Live Information System for Collaboration [START_REF] Roure | Research Agenda for the Semantic Grid: A Future eScience Infrastructure[END_REF].

We have proposed our GSD solution [START_REF] Vaquerogonzalez | The Opportunity of Grid Services for CSCLApplication Development[END_REF] to boost CSCL (Computer Supported Collaborative Learning) activities. In a paper we published 2004 [START_REF] Dugenie | A bootstrapping scenario for elicitating CSCL services within a GRID virtual community[END_REF], we started to outline our approach by defining the bootstrapping aspects of a collaboration. Then, we presented the original GSD framework last year [START_REF] Dugenie | Orientation et usage de l'Architecture de Services Grille OGSA[END_REF]. Here, we present our latest experimental case study and results to determine how the GSD can facilitate the collaboration process in the context of developing of a shared ontology. More specifically, within a collaboration session, collaboration is realised following two modes: (i) a screen sharing mode, where each participant may alternatively (according to a turntaking mechanism) broadcast a part of his/her own desktop to all the other participants of the collaboration session; (ii) a common environment m_ode where each participant may alternatively (according to a turntaking mechanism) act on a special desktop common to all participants of the collaboration session.

One of the challenges of the GSD is to provide a serviceoriented architecture that enables collaborative work. We will see how Grid provide such a solution allowing the GSD to be itself a service and an environment for service exchange. The choice of Grid technology is motivated by recent research on these topics [START_REF] Allison | Services, Semantics and Standards: Elements of a Learning Grid Infrastructure[END_REF][START_REF] Ritrovato | Towards the Learning GRID: advances in Human Learning Services[END_REF][START_REF] Wesner | How GRID could improve ELearning in the environmental science domain[END_REF] that provides a significant contribution in understanding the actual Grid potentialities related to distant collaboration, and that promotes the development of serviceoriented usage (and expansion) of this technology in all contexts and especially where human collaboration is required (elearning, egovernment, ehealth, ebusiness, e science).

Requirements for a collaborative construction of an ontology

One frequent goal of human collaboration is to define a common corpus of knowledge about a domain of expertise; when formalised and computerised, this knowledge representation artefact is known as an ontology. A collaborative construction of an ontology consists of repeated short cycles of elicitation, specification, implementation, evaluation steps within a scenario. Collaborative ontology construction however presents a certain number of challenges (such as explanation of viewpoints, negotiation of terms and meaning, decision among modelling options) that lead to a number of requirements. Informal learning. A notifiable effect during a collaborative ontology construction consists in enhancing learning as a result of the interaction. This kind of learning, known as informal learning, happens as the side effect of activities and observations that have not learning itself as their aim [START_REF] Cerri | Models and Systems for Collaborative Dialogues in Distance Learning[END_REF]. Laurillard [START_REF] Laurillard | A conversational framework for individual learning applied to the 'learning organisation' and the 'learning society[END_REF] has outlined how knowledge acquisition can be linked to guided concrete action in the context of a conversational framework. Therefore collaboration can be seen as a normal opportunity for learning, as it interweaves individual experiences and exchange of concepts, in the context of an interactive use of language: conversation. Reversely, conversation establishes the necessary ingredient for cooperative activities including the conversation itself: trust. As a result, collaboration not only allows a community to perform a set of joint activities effectively, but also allows the members of that community to learn new knowledge and skills and to improve shared understanding overall. Therefore, a major goal of developing a generalpurpose collaborative environment is to allow informal learning to occur. Synchronous and asynchronous collaboration. Considering the timescale (duration) and the size (number of members, amount of resources) of a group, we distinguish between two modes of collaboration: synchronous and asynchronous modes. The synchronous mode is more appropriate to consider for shortlived collaboration sessions that involves a small number of participants, whereas the asynchronous mode fits better longterm collaboration activities that involves many members. These two modes of collaboration imply different requirements and characteristics for the collaborative environment. For example: (i) in a synchronous collaboration, users may inform others of their presence, they should follow a turntaking mechanism, they may communicate by direct means supporting audio or video channels (e.g., chat, videoconferencing, shared desktop); (ii) in an asynchronous collaboration, users communicate with indirect means (e.g., email, shared files) that entail delayed responses, they should follow a different kind of turn taking mechanism (e.g., file locking). A flexible collaborative environment should address the two modes of collaboration. Trusted environment. Users need a trusted environment to collaborate freely with others. One problem in remote collaboration is the fact that people are not physically interacting. Collaboration occurs via an environment in which they exchange their knowledge. This environment requires security to ensure privacy and reliability to ensure anytime availability. Among other features, such a collaborative environment needs to implement a simple userauthentication mechanism and needs to manage private user accounts and displays as well as shared areas of collaboration. Enhancedpresence. In a collaborative environment, participants need to be aware at all times of the presence and availability status of each of the other participants, and more generally of the life of the community. Indeed, participants need to be able to discover, locate and contact other participants easily, to have access to public availability information to schedule work sessions, to communicate directly or indirectly, and so on. In recent years, several network communication tools (such as videoconferencing or chat software) have been developed to include simple, yet powerful "enhancedpresence" features coupled to audiovideo devices such as webcams and headsets. Those tools not only indicate the presence, location and availability of people, but also instill a feeling of community belonging and awareness that mimics the social dynamics of a local work team. For example, BuddySpace, [START_REF]BuddySpace Instant Messaging + Maps + Semantics = Enhanced Presence Management for Collaboration[END_REF][START_REF] Eisenstadt | Instant messaging + maps = powerful collaboration tools for distance learning[END_REF] an enhancedpresence environment with instant messaging functionalities, allows for multiple views of collaborative workgroups. Presence awareness increases emotional wellbeing [START_REF] Whitelock | Perfect Presence: What does this mean for the design of virtual learning environments?[END_REF], and users benefit from knowing who else is around via presence and messaging tools. Another tool is for example Flashmeeting [START_REF]FlashMeeting The One Click Videoconference[END_REF]. Incorporating enhancedpresence at the heart of the collaborative environment may improve the effectiveness of joint activities. Persistent, searchable memory. The collaborative environment should not only enable the conduct of collaboration sessions, but also serve as a permanent, onestop repository of the virtual community's work. The environment hence needs to offer a structured space for creating, storing and consulting shared documents and artefacts, as well as to maintain a searchable, traceable history of collaboration activities, with timestamps and provenance metadata. Dynamicity. One can not know in advance precisely which tool, service or pedagogical technique will be employed within collaboration activities. Similarly, one cannot predict which members are part of the community (members may join or leave at any time). But one can provide the means to enable members to "do the right thing at the right time". A collaborative environment needs to bootstrap and support the collaboration by enabling people to dynamically: (i) import or remove services; (ii) discover and approach each other; (iii) notice who is available at a given time; (iv) schedule collaboration sessions; (v) communicate directly or indirectly; (vi) trace and analyse the history of community life. The notion of dynamicallygenerated, customtailored services thus becomes central to the design of a collaborative environment, that needs to be capable of instantiating and providing appropriate services to participants based on explicit requests, stored preferences or dynamically identified collaboration patterns. Usability. Accessing the collaboration environment must be possible with a simple click and without installation of any thirdparty application. This can be achieved through a thin terminal and a stateless client as long as the state is managed elsewhere (i.e. provided by a stateful service).

Technological background

Potentialities offered by Grid

In order to achieve an ubiquitous collaborative environment with the requirements described in the previous section, Grid offers three major capabilities: scalability, security and reliability. In addition Grid has made a major step towards standardization that enable Grid technologies to evolved from adhoc solutions to the socalled Open Grid Services Architecture (OGSA) [START_REF]The Open Grid Services Architecture[END_REF].

OGSA aims to support "flexible, secure, coordinated resource sharing and coordinated problem solving in dynamic, multi institutional virtual organizations" [START_REF]The Grid: Blueprint for a New Computing Infrastructure[END_REF][START_REF] Foster | The Anatomy of the Grid: Enabling Scalable Virtual Organizations[END_REF]. It was originally designed to be an environment with a large number of networked computer systems where computing and storage resources could be shared as needed and on demand; therefore OGSA provides the protocols, services and software development kits needed to implement flexible, controlled resource sharing on a large scale. Grid users are members of virtual organizations. A virtual organization is a dynamic collection of individuals, institutions and resources brought together by common goals of sharing resources and services. OGSA introduces two major characteristics in the socalled serviceoriented architectures by distinguishing service factory from service instance. In other words, services are instantiated with their own dedicated resources and for a certain amount of time. These characteristics enable: (i) service state management: Grid services can be either stateful or stateless; (ii) service lifetime management: Grid services can be either transient or persistent 1 .

Grid standardization has been extended with the Web Service Resource Framework (WSRF) [START_REF] Foster | Modeling Stateful Resources withWeb Services[END_REF] to adopts Web services (Foster [15]). WSRF defines uniform mechanisms for defining, inspecting, and managing stateful resources in Web/Grid services. Grid service concepts and standardisation are described in detail in [START_REF] Comito | Grid Services: Principles, Implementations and Use[END_REF]. Grid has now started to evolve toward the Semantic Grid [START_REF] Geldof | The Semantic Grid: will Semantic Web and Grid go hand in hand? Technical report[END_REF][START_REF] Roure | Research Agenda for the Semantic Grid: A Future eScience Infrastructure[END_REF] and the Learning Grid [START_REF] Allison | Services, Semantics and Standards: Elements of a Learning Grid Infrastructure[END_REF][START_REF] Ritrovato | Towards the Learning GRID: advances in Human Learning Services[END_REF][START_REF] Wesner | How GRID could improve ELearning in the environmental science domain[END_REF].

Figure 1 represents the key concepts of Grid in the OGSA terms. The bottom of the figure represents the Grid resources and the dual process of virtualisation/reification into service containers. Two different size containers are represented at the centre of the figure. Users may access to the services running in these container if they belong to the virtual organisation associated with this container. Adopting a Grid infrastructure as the backbone of a collaborative environment therefore enables to benefit from robust, readytouse infrastructural means that address many of the implementation requirements identified earlier.

Current collaborative environments

The domain of distant collaboration is in real expansion both in research and business. An important number of tools are becoming available. We have evaluated some of them to check whether they meet the requirements that we have identified as crucial for collaboration. In particular, we evaluated Goto Meeting (www.gotomeeting.com), GatherPlace (www.gatherplace.net), Glance (www.glance.net), Beam4Free (http://beam4free.com), WorkSpace3D (www.tixeo.com), Groove Virtual Office (www.groove.net), AccessGrid (www.accessgrid.org). The idea of using desktops on the Grid was suggested in the Entropia project [START_REF] Calder | The Entropia Virtual Machine for Desktop Grid[END_REF]. A study of Computer Supported Collaborative Learning (CSCL) applications in a Grid context was also addressed in [START_REF] Dugenie | A bootstrapping scenario for elicitating CSCL services within a GRID virtual community[END_REF]. An example is Gridcole, a Grid based system that enables easy integration of CSCL application [START_REF] Botelorenzo | Towards Reusability and Tailorability in Collaborative Learning Systems using IMSLD and Grid Services[END_REF]. These works adopt various approaches to offer three main types of functionalities:

Screen sharing (or desktop broadcasting) that allows users to share their screen display on a network for other users to see exactly the same screen that they see.

Desktop sharing that allows all the users to take a remote control of the devices (mouse, keyboard…) of the desktop owner. Screen/Desktop sharing functionalities are traditionally used in collaborative work sessions for slide shows or application demonstration.

Common environment that provides all users with a virtual environment which can be a simple set of windows or a complex 3D space with avatars for users' representation. Users can interact and work together through the applications available on the common environment (chat, slide show, document edition, browsing, etc.). However, it appeared through our evaluation that: (i) none of these tools satisfies the totality of identified requirements for collaboration. For example, the two first functionalities are only suitable for synchronous collaboration mode. The last one is suitable for both synchronous and asynchronous but lack the full dynamicity required (e.g., none of them support dynamic introduction of users); (ii) few of them fully benefit from the totality of the potentialities offered by Grid services.

The GSD architecture

The GSD architecture relies on the capability of Grid services to be dynamic and stateful. The GSD architecture adopts the Grid service container as a model of GSD instance. In a GSD instance, a number of services are persistent, in the sense that they are instantiated during the initialisation of the service container. For this reason, we call these services bootstrapping services. Also we distinguish between two levels of GSD instances. The VC (Virtual Community) level and the CS (Collaboration Session) level. In this section, we describe the bootstrapping services and the subsequent differences between a VC and a CS service container.

The bootstrapping services

As a result of identifying the requirements for a collaborative environment and of assessing the Grid specifications, we have identified seven bootstapping services:

[Authorisation] to provide mechanisms to allow a user to access to the services of the community;

[Notifications] to provide immediate awareness of the life of the community;

[Members Management] to manage member such as add, delete or modify profiles;

[Services Management] to manage a set of services that are relevant for the community;

[Services Activation] to activate new instances of services;

[Sessions Management] to manage the different collaboration session within the community;

[History] to trace the history of collaboration within the community.

Authorisation. This service, called CAS (Community Autorisation Service) in the OGSA specifications, specifies the user rights levels towards any given services including the bootstrapping services. These rights level can be represented in a MxS matrix, where M are the members and S are the instances of services. For example only member m x as a service manager may be allowed to import new services, while any member m y would be allowed to set a new CS.

Notifications. This service is a broker responsible to dispatch messages between members to enable them to be immediately informed on everything concerning the VC life. These messages include the change of presence state of members, importation of a new service, invitation to participate to a CS, changes in relevant documentation, etc. The Notifications Service is tightly connected to the History Service which traces the community history.

Members Management. This service is responsible for introducing or removing dynamically users in a group. The Members Management Service plays an important role in the GSD architecture 'group dynamics'. Services Management. This service is responsible for importing new services in the service container of a given group. These services become accessible and can be activated. It is also responsible for removing services. The Services Management Service offers to users the ability to bring new tools as services for the group. Services Activation. Any service available within a group service container may be activated by the Services Activation Service, generally requested by a user, for a given duration and for certain users. The corresponding technical term used in Grid specifications is "service instantiation:" a Grid service instance has its own state, lifetime management and allocated resources. The Services Activation Service allows using all the other services in the GSD. The Services Management Service and the Services Activation Service play important roles in the GSD architecture 'service dynamics'. Sessions Management. Each member of a VC may decide to initiate a CS to address a specific collaboration need (more often synchronous). The Collaboration Sessions Management Service enables users to create, manage and delete CS. The life of this CS is then managed by six local services (cf. Figure 3) which are created as soon as the CS is created. The member initiating a CS, adds into the CS service container services he likes to benefit in the CS using the local Services Management Service. Then he invites participants to the CS with the local Members Management Service and manages rights between these participants and local services with the local CAS. He also activates the local services when needed with the local Services Activation Service. In the GSD architecture, the Collaboration Sessions Management Service is the only service capable to instantiate service containers.

History. An important aspect of collaboration is history. Indeed, group users actions and activities may be traced and logged to keep an history of the collaboration progress. The role of the History Service is to capture all significant events coming from the use of other services. It can for example log the access to a specific resource, register users profile evolution, inventory the past services activation, CS history, realise a shared document versioning etc.

Virtual Communities and Collaboration Sessions

We distinguish two kinds of groups in the GSD architecture: Virtual Community (VC). VC are quite stable and static groups. Their lifetime can be measured in months or years. A VC is composed of members and owns one service container.

Collaboration Session (CS). CS are groups formed for a short period of time, measured in hours or days. A CS is created by a VC when members decide to collaborate in a synchronous mode. Goals of CS are similar to a meeting: planning work, finalizing a document, brainstorming, etc. May need different services, documents or communication tools that are not managed at the VC level. For this reason a CS own also a service container. Figure 2 summarises the two kind of service containers with the bootstrapping services and the interaction between a VC and a CS. We may notice also that VC collaboration is mainly in asynchronous mode whereas CS collaboration is most of the time in synchronous mode. However, the real argument for distinction between VC and CS is related to the dynamics of the collaboration: a VC may engender a CS while a CS may not engender anything. From a Grid pointofview, VC and CS are both seen as virtual organizations and therefore they are each associated to a Grid service container. The service container will be destroyed and the Grid resource will be freed as soon as the group lifetime is over.

A typical scenario is the creation of a VC with many members who interact asynchronously on various occasions (e.g., using collaboratively a shared file system with a given set of permission for each member). For each required synchronous interaction, a CS is set for a short time with a subset of the members of that VC (and possibly external invited members). The output of the collaboration corresponding to that CS (e.g., a synthesis of a discussion or decision report that is relevant for the VC) can be stored in a repository belonging to the VC.

GSD processes

The bootstrapping services are involved in processes that correspond to the structure that defines dynamical relations between these services and interaction with them. We detail here some of this processes. Service activation process. A member wanting to activate a service within a group requests the Services Activation Service with its user certificate and the service handle (and eventually some other information such as: involved members, lifetime expected etc.).

Then the Services Activation Service checks (by requesting the CAS) the member's right level for this service. Then, the Services Activation Service creates the service instance with a specific state, lifetime and allocated resources. It next requests the Notifications Service to notify group members that a service was activated. In parallel, it requests and activates the History Service respectively for both recording the service activation in the community history and for logging/tracing the userservice interactions from now to the end of the service life. The service is activated and group users may interact with it during the service life. At the end of the service life, the Services Activation Service both requests the History Service to stop recording and to store the service results (by versioning old ones etc.) and the Notifications Service to inform the community of the results of the end over service. Afterwards, it destroys the service instance and frees the allocated resources. Service importation process. A member wanting to import a service in a group activates the Services Management Service as any other service (cf. service activation process) by giving it a service "external ID" and a table of rights levels for all users. The Services Management Service firstly includes in the service in the group service container and gives it an handle. Then, the Services Management Service requests the CAS to add a column in the members x services matrix. The Services Management Service has to specify the rights level of all members for the added service. Then, it requests the History Service to add an entry in its service database, and give it the trace/log mechanism for this new service. Afterwards, the Services Management Service asks the Notifications Service to notify the group members, that a new service was imported and is now available (following their rights level). User introduction process. A member wanting to introduce a user in a group activates the Members Management Service as any other service (cf. service activation process) by giving it a user "external ID" and a table of rights levels for all services. The Members Management Service firstly stores the new user information (status, name, address etc.) and gives him a local ID. Then, the Members Management Service requests the CAS to add a row in the members x services matrix. The Members Management Service has to specify the rights level of all services for the added user. Then, it requests the History Service to add an entry in its user list. Afterwards, the Members Management Service asks the Notifications Service to notify other members, that a new member was introduced in the group. Collaboration session management process. A member wanting to manage a CS within a VC activates the Collaboration Sessions Management Service by giving it three important things: (i) the list of services that he wants the CS to benefit from; (ii) the list of members he wants to participate in the CS; (iii) the information necessary to build the local CAS matrix of rights levels. The Collaboration Sessions Management Service firstly instantiates a new CS service container. Then it requests the local Services Management Service to import each service requested by the CS manager and requests the local Members Management Service to introduce each requested participant. These subprocesses are the same than the service importation process and the member introduction process specified before. Afterwards, the local CAS is requested to build its rights levels matrix. The Collaboration Sessions Management Service also requests (i) the Notifications Service to notify the entire VC of the creation of a new CS2 , (ii) the History Service to register the CS creation in VC history. The CS is now created and may be started. Each time the CS manager wants to activate a local service he requests the local Services Activation Service (cf. service activation process). The CS takes place with several services and their results. At the end of the CS, the Collaboration Sessions Management Service destroys the CS service container and frees the allocated resources. Local History Service data are transferred to the VC History Service. Finally, the Collaboration Sessions Management Service asks the Notifications Service to inform the VC of the set of results of the end over CS.

Collaborative construction of a shared ontology

To demonstrate and validate our approach and implementation of the GSD in a realworld setting, we conducted an experimental scenario involving the development of a shared ontology-computerised representation of knowledge-using a renowned ontology building tool supported as a service on the GSD, as well as additional humancommunication services.

The problem of collaborative ontology construction

A frequent goal of human collaboration is to define a shared, agreedupon corpus of knowledge about a domain of expertise common to the members of the collaboration community. When formalised and computerised, shared knowledge can serve as the basis for better understanding among members of the community and better communication with external people, as well as for further development of common resources and for many problemsolving activities. In recent years, the representation of such shared knowledge has largely been implemented by ontologies-formal, computerised conceptualisation of the notions, properties and relationships in a domain [START_REF] Gruber | A translation approach to portable ontologies[END_REF].

Building an ontology requires the use of a tool that provides means for creating and organising concepts, properties and relationships that are important in a given domain of expertise. Adopting such a tool, however, requires to understand the principles of ontology construction as well as mastering the set of associated userinterface tasks. Building an ontology collaboratively requires an additional level of service that includes multiuser serving of the ontology contents and userinterface views, user authentication and rights management, provision of realtime information on collaborators that are editing the ontology, portions of the ontology that are being modified, history of modifications, as well as provision of locking and commitment mechanisms. The Protégé knowledge modeling environment (http://protege.stanford.edu) is a de facto standard tool that supports single and multiuser construction of ontologies.

Collaborative ontology construction presents a certain number of challenges, that exercise well the different kinds of interactions that can occur among the participants of a collaboration session. Types of interactions include the presentation/teaching of portions of the ontology, the discussion and reconciliation of multiple viewpoints on knowledge, the negotiation of vocabulary terms, their meanings and their relationships, and the confrontation of various knowledgemodelling options. Such interactions typically are not supported by current ontologybuilding tools; instead they need to be supported at a humancommunication level by the collaborative environment with help of additional services. Specifically, by interacting through a multiuser ontologydevelopment service, augmented by presentation services such as slidepresentation software, drawing and annotation boards, and enhanced presence services such as chat and videoconferencing, in addition to using the GSD CS modes (i.e., screen sharing mode and common environment mode), members of the community are able to teach, learn, share and model knowledge of mutual interest.

General scenario presentation and experimental setup

Our objective in this scenario is to show how the collaborative environment created by a virtual community and supported by the GSD service can foster the collaborative modelling of shared knowledge in the form of an ontology.

A two steps experiment scenario

We argue that our scenario is typical of the process by which a set of collaborators initiate and execute a joint piece of work. At the start of a collaboration, participants present, discuss and choose their goals and the tools and methods that they are going to employ to achieve their goals. Methods and tools might not be known by everyone in the community; knowledgeable participants hence need to walk other participants through the principles of the tools and methods and their basic operation. This can be seen as a learning phase. Once most participants feel confident with the tools and methods, a productive phase can start in which the actual collaborative work takes place and more learning can occur along the way. Note that this is a typical context of informal learning. Collaborative ontology construction being no different from other collaborative activity, we divided our experiment scenario into two steps:

A first, learning experiment in which the GSD service supports participants in teaching and learning principles of ontology development and the use of the Protégé ontology editor; A second, production experiment in which the GSD service supports participants in creating, explaining and maintaining an ontology collaboratively. Consequently, our scenario enables us to show how the GSD service both (1) supports a typical elearning setting with added features of screen sharing and common environment collaboration modes (in the first step experiment) and ( 2) provides an engaging framework for helping participants to reconcile, formalise and capture knowledge that is initially informal and distributed into a shared ontology that then can be used inside or outside of the GSD context (in the second step experiment). Notice that the second step experiment would not be possible without considering the results of the first one. Experimental setup of the GSD For the purpose of our experiments, we created a small VC, called "okprotege," denoting the fact that members are willing to collaborate on a given task. First, we conducted four remote sessions focused on testing technical aspects of the GSD, and configuring the ontologybuilding and enhancedpresence services supported. Then, we conducted three shorttime (2 hours) CSs involving five participants each accessing the GSD service by logging onto their Private Ubiquitous Desktop (PUD) in a Web browser. The chosen collaboration mode for these CSs was screen sharing mode. Each PUD was equipped with necessary collaborative and preference setting services as well as a oneclick toggle granting a readonly access to the Broadcasted Virtual Desktop (BVD) and full access to the member's own PreBVD. At any time, participants could switch from operating the services on their PUD to visualizing both the PreBVD and the BVD.

During the experiments, the Protégé service supported by the GSD was available to each participant via their PUD as a client to a central Protégé server. Participants accessed and controlled shared ontology files on the server, following a classical client/server approach with authentication mechanisms allowing for parallel editing of the shared ontology. At the same time, participants communicated in private or joint conversations by audio, video or text chat using the FlashMeeting [START_REF]FlashMeeting The One Click Videoconference[END_REF] videoconferencing service and the BuddySpace [START_REF]BuddySpace Instant Messaging + Maps + Semantics = Enhanced Presence Management for Collaboration[END_REF] chat service, both running on their private desktop3 . In addition, collaborative tools such as text and document editors, a file system explorer and a Web browser were all available as services to CS participants within the GSD.

Prelimilary results

In our experiment, our main interest was to assess the use of the different collaboration modes supported by the GSD. The main collaboration mode that we adopted for this scenario was screen sharing. Motivations behind this choice were: (i) at any time during a CS, participants could make modifications to the shared ontology in parallel, hence fostering participants' initiative; (ii) participants could work on their own PreBVD when they needed to do isolated work or try out ideas, either on the common ontology or on a local copy of the files; (iii) according to a turntaking mechanism, participants could each broadcast their actions, ideas or work to the community once they were ready to do so. This collaboration mode was appropriate both for a learning and a production phase.

Very interestingly, our experiments demonstrated the gradual transition from a learning phase of collaboration to a more productive phase, by which the role of participants evolved. The first two experiments were very much organised as an "instructor" remotely walking a small group of "students" through the concepts and userinterface metaphors underlying ontologies and ontology editing with the Protégé tool (see Figure 3). In these sessions, the instructor was the main participant broadcasting her desktop, demonstrating how to use Protégé and explaining ontologybuilding principles along the way. The instructor also guided other participants into trying simple exercises in front of others, by taking their turn on the BVD.

The third experiment revealed an evolution of participants' roles and actions by which more initiative was taken by initial "students" and less direction was instilled by the initial "instructor." Although these initial experiments did not lead us to a full production phase in a newlycreated ontology of particular interest to the okprotege community, they still demonstrated production level creation of new concepts and properties in the tutorial ontology. Figure 3 shows a screenshot of the GSD during one experiment. Left, the Webaccessible PUD of a participant is shown (here a Linux KDE desktop), focused on that participant's PreBVD, displaying his Protégé client serving a tutorial ontology about Wines. Center, a FlashMeeting videoconferencing session is running in parallel, showing the instructor explaining what she does with Protégé and other participants listening and following instructions. Right, another part of the participant's PUD is shown, focused on the BVD, broadcasting the PreBVD of the currently active participant (as denoted by the orange tab) displaying her Protégé client .

Conducting these initial experiments was crucial in devising the right mode of operation of the GSD in a scenario such as ontology building with Protégé. For instance, our experiments enabled us to improve the configuration of private and broadcasted desktops, to decide on a set of available services, to experiment turntaking policies and moderator roles, as well as to study voice/video/screen interactions from the point of view both of technological interference and of each participant's experience in managing these collaboration modes simultaneously. In addition, we were able to solve a number of infrastructural details, such as providing a oneclick Webaccessible interface for the GSD, managing user accounts, groups and rights, implementing efficient screenbroadcasting mechanisms and identifying multiuser requirements for applications such as Protégé.

Studying the dynamics of turntaking on the BVD, we experimented with tasking the instructor with the role of moderating the turntaking queue (as would a teacher in a classroom), as well as tasking any other participant with this role, mimicking a more spontaneous setting. In our current version of the GSD, we decided that spontaneity is most appropriate, and the GSD allows anyone to switch the BVD to any other participant. We still want to setup safeguard and privacy mechanisms by which participants could prevent their PreBVD from being broadcasted at certain times, as well as a turnasking queuing mechanism that would organise the dialogue among participants.

Conclusion and perspectives

In this paper, we have presented a novel approach to the design and implementation of a collaborative environment for virtual communities of practice. Our solution, the Grid Shared Desktop, or GSD, enables the bootstrap and support of remote collaboration among humans, by drawing from the powerful Grid infrastructure to provide a set of virtual desktops (private, broadcasted and common) to a community of users logging in and interacting through their Web browser. The main new aspect of our solution is a Grid service oriented approach. Via the GSD, users access a context dedicated to the collaboration within the different communities that they form. Virtual desktops play the role of service containers available for both of the two identified collaboration levels: virtual community and collaboration session. Each community member has his or her own Private Virtual Desktop, and both screen sharing mode and common environment mode of collaboration are possible thanks to a (Pre)Broadcasted Virtual Desktop and a Common Virtual Desktop. In this environment, an array of services are available to community members and provide them with means of communicating and working together in collaborative activities, as well as working in isolation on common documents and resources. We believe that supporting mechanisms such as authentication, turntaking and enhancedpresence services allow users to feel at home in a trusted environment.

We conducted initial experiments using the GSD among ourselves in the context of a common activity in collaboration: constructing a shared understanding of knowledge as an ontology, using a set of renowned, wellaccepted tools. The valuable results from the initial experiments provide an initial validation of our GSD approach. These encouraging results are now leading to a large scale experiment within a community of Chemists and Computer scientists. This community has started constructing collaboratively an ontology of Organic Chemistry, using the full potential of the GSD. This effort is part of the ambitious EnCOrE project (Encyclopédie de Chimie Organique Electronique). A preliminary assessment shows that this collaborative work is following the same twostep process that we experienced in our test experiments: from initially instructordriven, the collaboration is now becoming more spontaneous, allowing for individual initiative as well as for small subgroup formation.

Figure 1 .

 1 Figure 1.The Grid underlying infrastructure.

Figure 2 .

 2 Figure 2.Bootstrapping service in the VC and CS service containers.

Figure 3 .

 3 Figure 3. Screenshot of the Grid Shared Desktop in action, during our first collaboration session experiment.

Biographies

  Pascal Dugénie received his MSc. degree in communication systems from the University of Bristol, U.K., in 1993. He has been involved in hardware and software design of telecommunications equipment. He began in radio systems design and participated in network planning for the French broadcasting operator TDF. He has been involved in research in networks, protocols and systems for six years at the Centre for Communication Research, Bristol, U.K. where his interests concerned analysis of telecommunication traffic and performance of fixed and mobile networks. Later he joined Motorola as a system engineer where he improved a heuristic for the optimisation of frequency plans for GSM infrastructure. He chaired an ACTS Group during 199798 and participated to ETSI standardisation. Since, June 2004, he is research engineer at the LIRMM and prepares a PhD at University of Montpellier in the area of Grid computing.Philippe Lemoisson is a graduate of "Ecole Polytechnique" (1977) and of "Ecole Nationale des Ponts et Chaussées"(1982). Throughout his whole career as an engineer since 1980, he has been working on information management solutions and tools for a better collaboration inside companies: (i) as a senior consultant in the domain of Information System Management; (ii) as a research engineer in the area of telecommunications. Since 2000, he has been sharing his time between the management of Industrial or European projects and Scientific Research in the domain of Computer Science. He is currently working on a conceptual framework for "human cooperation enabled by formal systems", including a protocol for a "conversational calculus" in the context of a PhD to be achieved in 2006.Clement Jonquet, obtained a BSc. and a MSc. in Computer Science (CS) from the University of Montpellier, France. He is currently a PhD student in CS at the same university, in the Laboratory of Informatics, Robotics, and Microelectronics of Montpellier (LIRMM -www.lirmm.fr). At the same time, he is training as a junior lecturer and teaches CS to BSc students at the University of Montpellier. At LIRMM, he is a member of the Social Informatics/Kayou team, concerned with topics such as agents and multiagent systems, distributed systems, Web and Grid infrastructures, intelligent services, ontologies, collaborative learning, elearning. He is a member of the ELeGI project. Clement Jonquet's home page is www.lirmm.fr/~jonquet. Monica Crubézy is a research scientist in the Stanford Medical Informatics Laboratory at Stanford University. Her research focuses on modeling libraries of problemsolving methods and integrating them with domain ontologies to achieve knowledgeintensive tasks. She also studies mapping and mediating knowledge among ontologybased system components, such as in the context of the Semantic Web. Recently, she has been concentrating on the study of ontology building as a central activity in human collaboration. She received her PhD in computer science from the Université de NiceSophia Antipolis and the Institut National de Recherche en Informatique et Automatique. http://smiweb.stanford.edu/people/crubezy.

Whereas Web services have instances that are stateless and nontransient.

Notice that CS participants have received two notifications: the one done by the local Members Management Services, and this one.

For the sake of simplifying these first experiments, enhancedpresence tools were used externally to the GSD, on each participant's host desktop.

Acknowledgements

Work partially supported by the European Community under the Information Society Technologies (IST) programme of the 6th Framework Programme for RTD project ELeGI, contract IST002205 [3]. This document does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be made of data appearing therein.

Work performed in 2005 was also supported as a FranceStanford Development Project "TechnologyEnhanced Learning on the GRID." by the FranceStanford Center for Interdisciplinary Studies.