Description

This document's goal is to describe in a more precise way the vision of the Social Extension for XWiki and the issues that should be addressed.

Definitions

In some cases it is useful to introduce also the following definition

Examples of how these definitions apply to some of the most known social network services. 

Because of the nature of the relation that is established between users, the action of establishing links between users might entail some kind of validation.

One of the most popular features that is present in these social network services is "user status", let's see how this is handled by using the previous definitions.

	Action	Impacted users	Remarks
Facebook	User u1 updates her status		The social network here is made of 8 users that are connected using a symmetric relation, like the Facebook friendship. Since the social relation is symmetric, the graph is not directed. We can imagine that an edge connecting two nodes ui and uj is actually made of two directed edges (ui, uj) and (uj, ui) neighborhood(u1) = { u2, u3, u5 } proximity(u1) = { u2, u3, u5 } The impacted users of a status update performed by u1 are those that are part of u1's neighborhood and are marked in green. When the social relation is symmetric ∀u ∈ U, neighborhood(u) = proximity(u)
Twitter	User u5 updates her status		Here we have a similar social network as in the previous example, but the relation is not symmetric (i.e., this models the Twitter's following relation) neighborhood(u5) = { u4 } (i.e., the users u5 is following) proximity(u5) = { u1, u6, u8 } (i.e., the users who follow u5 or u5's followers) The impacted users of a status update performed by u5 are those that are part of u5's proximity and are marked in green.
Twitter	User u1 updates her status		In this example we have the same social network of the previous one. We can see that since proximity(u1) = ∅ no one is impacted by a status update performed by u1 (i.e., she has no followers)

Current XWiki infrastructure

This section describes the current XWiki infrastructure from a social point of view. In the next sections we will build upon this in order to define what the XWiki social extension should be.

• From a social perspective, what is interesting in the XWiki platform are the activities that are generated by the users while collaborating. Currently these activities are displayed in the activity stream:
  • Page creation/deletion
  • Page modification
  • Comment creation/deletion
  • Annotation creation/deletion
• XWiki activities are page centric while in social network services these activities are user centric
• Though a social network abstraction is not explicitly defined in XWiki, we can implicitly define a social network associated to each XWiki page (this is due to the fact that activities are page centric)
  • Let U_P be the set of users that have sufficient rights to read a page P. So for page P we will have an implicit social network SN_P = (U_P, L) where ∀u_i, u_j ∈ U_P, (u_i, u_j) ∈ L
    
  • These implicit social networks are actually complete graphs where every user is linked to all the others or, in other terms, all the activities made by a user in U_P on page P impacts all the other users in U_P.
  • Often U_P has a one-to-one correspondence to a well defined XWiki group. In fact rights on a page are usually defined by granting them to a group.
  • If a page is public then the social network associated to it is the one made of all registered users interconnected each one to the other.

Adding user-centric social network services to XWiki

In order to add user-centric social network services to XWiki we must give users the ability to define their neighborhoods and to define user-centric activities.

We point out that XWiki already has the user abstraction in its model, modeled using a page and an object representing her profile. What is missing is the ability to manipulate the social binary function that defines a social network SN = (U, L)

• Let SN = (U, L) the current social network. A user u ∈ U can modify it either by adding or removing pairs of the form (u, u_i) to the social relation L
• When a user u wants to add a pair (u, u_j), user u_j should be able to validate the operation.

The basic social network service is the user status where a user can asynchronously exchange messages with her neighborhood or proximity.

• Given a social network SN = (U, L) a user status sent by user u should be communicated to all the users u_i ∈ proximity(u)
  • If the social relation L is symmetric, then we will have a behavior à la Facebook
  • If the social relation L is not symmetric, then we will have a behavior à la Twitter
  • User statuses can be communicated on the standard activity stream
• By having an abstraction for a user's neighborhood, this information can be used to calculate a projection of the displayed activities
  • Let u be the current user, an activity associated to user u_i is displayed if and only if u_i ∈ neighborhood(u)

Managing social network services for Workspaces

Workspaces are collaboration space where a group of people can collaborate on a given topic. The users associated to a workspace implicitly define a social network where every one is connected to everyone else: let U_WS = { u | u is member of the workspace WS} the social network SN_WS = (WS, L_WS) where L_WS = WS × WS

All activities performed in the context of a workspace have an impact on every user belonging to the workspace.

An activity stream for a user u and a workspace WS will show activities generated by all the users in U_WS 

Open issues

• What are the properties of the social relation we want to implement? (symmetric or not?)
• Should it be mandatory to validate the establishment of a social relation?
• Should it be possible, for a user, to define different kind of social relation (e.g., friends, colleagues, projectX members, XWiki Groups)
  • If this is the case, the social relation L should be made of triples (u_i, u_j, kind) where u_i, and u_j, are the user linked by the relation and kind defines the kind of the social link.
  • The neighborhood of a SN = (U, L) should be extended to take into account the kind of the social link: neighborhood(u, label) = { u_i | (u, u_i, label) ∈ L }
  • The proximity of a SN = (U, L) should be extended to take into account the kind of the social link: proximity(u, kind) = { u_i | u ∈ neighborhood(u_i, kind) } or proximity(u, kind) = { u_i | (u_i, u, kind) ∈ L }
• Where to put UI for the components?
• What are the administration options for the new features?