Wiki source code of XWiki Social

Last modified by Vincent Massol on 2024/11/19 16:12

Show last authors
1 {{include document="XWiki.DesignClassSheet"/}}
2
3 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.
4
5 == Definitions ==
6
7 |= Social network (informal)
8 |(((
9 A social network is a social structure made up of individuals (or organizations) called "nodes", which are tied (connected) by one or more specific types of interdependency, such as friendship, kinship, common interest, financial exchange, dislike, sexual relationships, or relationships of beliefs, knowledge or prestige. ([[Wikipedia>>http://en.wikipedia.org/wiki/Social_network]])
10 )))
11
12 |= Social network service
13 |(((
14 A social network service is an online service, platform, or site that focuses on building and reflecting of social networks or social relations among people, e.g., who share interests and/or activities. A social network service essentially consists of a representation of each user (often a profile), his/her social links, and a variety of additional services. ([[Wikipedia>>http://en.wikipedia.org/wiki/Social_network_service]])
15 )))
16
17 |= Social network (formal)
18 |(((
19 A //social network// is a directed graph //SN = (U, L)// where //U// is a set of users and //L {{html}}⊆{{/html}} U × U// is a binary relation that defines the links between users.
20 )))
21
22 |= Neighborhood
23 |(((
24 Given a //social network// //SN = (U, L)// and a user //u {{html}}∈{{/html}} U//, the //neighbourhood// of user //u// is the set of users //u,,i,,// who are linked to the user //u//, i.e., //neigbourhood(u) = { u,,i,, | (u, u,,i,,) {{html}}∈{{/html}} L }//.
25 )))
26
27 In some cases it is useful to introduce also the following definition
28
29 |= Proximity set
30 |(((
31 Given a //social network// //SN = (U, L)// and a user //u {{html}}∈{{/html}} U//, the //proximity set// of user //u// is the set of users //u,,i,,// who have user //u// in their //neighborhood//, i.e., //proximity(u) = { u,,i,, | u {{html}}∈{{/html}} neighborhood(u,,i,,) }// or //proximity(u) = { u,,i,, | (u,,i,,, u) {{html}}∈{{/html}} L }//
32 )))
33
34 Examples of how these definitions apply to some of the most known social network services.
35
36 | |= Social relation |= Social relation properties |= Neighborhood |= Proximity |= Remarks
37 |**Facebook** | Friendship | Symmetric //(u,,i,,, u,,j,,) {{html}}∈{{/html}} L {{html}}⇒{{/html}} (u,,j,,, u,,i,,) {{html}}∈{{/html}} L// | Friends | Friends | Since the social relation //L// is symmetric then //{{html}}∀{{/html}} u {{html}}∈{{/html}} U, if u,,i,, {{html}}∈{{/html}} neighborhood(u) then u {{html}}∈{{/html}} proximity(u,,i,,)//
38 |**Twitter** | Following | | Following | Followers |
39
40 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.
41
42 | |= Social relation |= Validation |= Remarks
43 |**Facebook** | Friendship | Yes | Due to the symmetric nature of the "friendship" relation, when a user //u,,1,,// wants to become friend of a user //u,,2,,// user //u,,2,,// must accept this fact because //u,,1,,// will automatically become part of //neighborhood(u,,2,,)//
44 |**Twitter** | Following | No | In twitter when a user //u,,1,,// follows a user //u,,2,,// this does not imply that the user //u,,2,,// also follows user //u,,1,,// so there is no need to validate a link request.
45
46 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.
47
48 | |= Action |= Impacted users |= Remarks
49 |**Facebook** | User //u,,1,,// updates her status |[[image:facebook.png||width="200"]] |(((
50 * The social network here is made of 8 users that are connected using a symmetric relation, like the Facebook friendship.
51 * Since the social relation is symmetric, the graph is not directed. We can imagine that an edge connecting two nodes //u,,i,,// and //u,,j,,// is actually made of two directed edges (//u,,i,,//, //u,,j,,//) and (//u,,j,,//, //u,,i,,//)
52 * //neighborhood(u,,1,,) = { u,,2,,, u,,3,,, u,,5,, }//
53 * //proximity(u,,1,,) = { u,,2,,, u,,3,,, u,,5,, }//
54 * The impacted users of a status update performed by //u,,1,,// are those that are part of //u,,1,,//'s //neighborhood// and are marked in green.
55 * When the social relation is symmetric //{{html}}∀{{/html}}u {{html}}∈{{/html}} U, neighborhood(u) = proximity(u)//
56 )))
57 |**Twitter** | User //u,,5,,// updates her status |[[image:twitter.png||width="200"]] |(((
58 * 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)
59 * //neighborhood(u,,5,,) = { u,,4,, }// (i.e., the users //u,,5,,// is following)
60 * //proximity(u,,5,,) = { u,,1,,, u,,6,,, u,,8,, }// (i.e., the users who follow //u,,5,,// or //u,,5,,//'s followers)
61 * The impacted users of a status update performed by //u,,5,,// are those that are part of //u,,5,,//'s //proximity// and are marked in green.
62 )))
63 |**Twitter** | User //u,,1,,// updates her status |[[image:twitter2.png||width="200"]] |(((
64 * In this example we have the same social network of the previous one.
65 * We can see that since //proximity(u,,1,,) = {{html}}∅{{/html}}// no one is impacted by a status update performed by //u,,1,,// (i.e., she has no followers)
66 )))
67
68 == Current XWiki infrastructure ==
69
70 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.
71
72 * 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//:
73 ** Page creation/deletion
74 ** Page modification
75 ** Comment creation/deletion
76 ** Annotation creation/deletion
77 * XWiki activities are page centric while in social network services these activities are user centric
78 * 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)
79 ** 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 //{{html}}∀{{/html}}u,,i,,, u,,j,, {{html}}∈{{/html}} U,,P,,, (u,,i,,, u,,j,,) {{html}}∈{{/html}} L//
80 [[image:complete.png||width="200"]]
81 ** 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,,//.
82 ** 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.
83 ** 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.
84
85 {{info}}
86 To resume we can say that:
87 * XWiki activities are page centric
88 * XWiki social networks are implicitly defined by the rights configuration on each given page
89 {{/info}}
90
91 == Adding user-centric social network services to XWiki ==
92
93 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.
94
95 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)//
96
97 * Let //SN = (U, L)// the current social network. A user //u {{html}}∈{{/html}} U// can modify it either by adding or removing pairs of the form //(u, u,,i,,)// to the social relation //L//
98 * When a user //u// wants to add a pair //(u, u,,j,,)//, user //u,,j,,// should be able to validate the operation.
99
100 The basic social network service is the user status where a user can asynchronously exchange messages with her neighborhood or proximity.
101
102 * Given a social network //SN = (U, L)// a user status sent by user //u// should be communicated to all the users //u,,i,, {{html}}∈{{/html}} proximity(u)//
103 ** If the social relation //L// is symmetric, then we will have a behavior à la Facebook
104 ** If the social relation //L// is not symmetric, then we will have a behavior à la Twitter
105 ** User statuses can be communicated on the standard activity stream
106 * By having an abstraction for a user's neighborhood, this information can be used to calculate a projection of the displayed activities
107 ** Let //u// be the current user, an activity associated to user //u,,i,,// is displayed if and only if //u,,i,, {{html}}∈{{/html}} neighborhood(u)//
108
109 === Managing social network services for Workspaces ===
110
111 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//
112
113 All activities performed in the context of a workspace have an impact on every user belonging to the workspace.
114
115 An activity stream for a user //u// and a workspace //WS// will show activities generated by all the users in //U,,WS,,//
116
117 == Open issues ==
118
119 * What are the properties of the social relation we want to implement? (symmetric or not?)
120 * Should it be mandatory to validate the establishment of a social relation?
121 * Should it be possible, for a user, to define different kind of social relation (e.g., friends, colleagues, projectX members, XWiki Groups)
122 ** 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.
123 ** 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) {{html}}∈{{/html}} L }//
124 ** 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 {{html}}∈{{/html}} neighborhood(u,,i,,, kind) }// or //proximity(u, kind) = { u,,i,, | (u,,i,,, u, kind) {{html}}∈{{/html}} L }
125 * Where to put UI for the components?
126 * What are the administration options for the new features?

Get Connected