User Tools

Site Tools


vallet_vandewynckel:jason_vallet_julien_vandewynckel

La correction de votre projet est publiée ici.

Projet

Liens

L'ensemble de données est issu du site Wikipédia et ont été trouvée sur le site de Stanford.

L'ensemble des fichiers suivants peut être récupéré dans l'archive général du projet.

Vous trouverez ici le diaporama utilisé pour réaliser notre présentation en classe.

Le dataset choisi peut être trouvé ici ou bien est directement disponible sur le Wiki par ce lien.

Les fichiers générés pour les arêtes et les noeuds sont également disponibles directement.

Le script de traitement des données peut être téléchargé par ce lien.

Introduction

Même s'il emploi moins de 100 personnes, Wikipédia est un des sites les plus visités au monde. Il rassemble plus de 3 millions d'articles en anglais, soit plus de 22 millions de pages, et plus de 15 millions d'utilisateurs enregistrés, toute nationalités confondues.

À cause du grand nombre de modifications et de l'ampleur du site en comparaison du petit nombre d'employés, il est évident que l'administration ne peut être le fait d'une centaine de personnes.

Pour résoudre ce problème, Wikipédia a proposé la mise en place d'un système d'administration permettant à certains membres de la communauté de se voir attribuer des autorisations spéciales sur le contenu du site.

Ils peuvent alors résoudre différents problèmes de maintenance, notamment vis-à-vis de la suppression des pages non voulues, des documents sous copyright ou alors des discussions sur la véracité de certaines informations.

Présentation du sujet

Les administrateurs sont élus parmi les utilisateurs. Ces derniers soumettent une série de votes (pour, neutre, contre) tout au long de la période d'élection. Un administrateur déjà en place, que l'on désignera comme le nominateur, va alors, à une certaine date et en fonction des votes obtenus, procéder à la fermeture de l'élection et, selon les résultats de votes, à la nomination de l'utilisateur qui deviendra alors un administrateur.

Les administrateurs ont exactement les mêmes droits que les utilisateurs, c'est à dire qu'ils peuvent toujours participer aux élections en votant, mais aussi en nominant les candidats.

Plusieurs détails nous sont inconnus vis-à-vis des procédures de début de vote et des conditions d'admissibilité des candidats. Nous avions d'abord pensé que les procédures de votes étaient initialisées par les administrateurs déjà en place. Cependant, certains points parmi les données semblent indiquer le contraire. Nous pouvons citer au moins deux exemples où les personnes ont votés pour elles-mêmes. Ces procédures de vote ont été fermée moins de 24h après leur lancement. De la même façon, certaines procédures regroupant 3 ou 4 points ont été stoppées. La consécution des ids semblait suggérer que les comptes avaient été créés pour lancer le vote.

La démarche de proposition de nomination n'est pas importante pour nous. Le nombre des tentatives telles que décrites ci-dessus étant négligeable par rapport au nombre de points, nous admettons donc que la procédure de vote est légitime.

La base de donnée contient 7 194 points, désignant les utilisateurs/administrateurs, et 114 040 arêtes représentant les votes d'un utilisateur pour un autre.

Nous pouvons notamment annoncer :

  • 83962 votes pour
  • 23118 votes neutre
  • 6960 votes contre

De manière générale :

  • 2794 sessions de vote ont été initiées
  • 1248 ont abouti à une élection
  • 71430 votes ont menés à une élection (65693 pour, 1840 neutre, 3897 contre)
  • 42610 votes ont menés à un échec (18269 pour, 5120 neutre, 19221 contre)

Problématique

Depuis qu'Internet a été ouvert au grand public, de nombreux sites regroupant des forums ou des blogs se sont créés. Ces lieux virtuels permettaient à plusieurs personnes de discuter et d'échanger leurs points de vues, de présenter leurs intérêts et de communiquer avec d'autres personnes les partageant.

Ainsi, petit à petit, diverses communautés se sont développées, soit autour d'une personne en particulier, le propriétaire du blog par exemple, soit autour d'un sous-groupe réduit de personnes servant à modérer les propos tenus ou à animer les discussions. Ces modérateurs sont devenus la figure d'autorité des forums et sont responsable de l'ordre virtuel qui y règne.

Wikipédia, dans sa politique d'ouverture à tous, propose à chacun de rédiger les articles et compte sur les membres pour être sérieux, objectifs et corriger les éventuelles erreurs écrites. Cependant, à cause des proportions que le site à pris, il est devenu évident que les personnes travaillant légitimement pour l'entreprise ne pouvaient être partout.

Des modérateurs furent alors nommés parmi les membres les plus actifs, droits et appréciés de la communauté. Un système d'élection a été mis en place et la machine était lancée. Depuis, l'élection des administrateurs est devenue quasi routinière.

Comme toutes les communautés, nous pensons que celle de Wikipédia est hétéroclite et est donc constituée de plusieurs sous ensembles regroupant des personnes ayant des affinités plus particulières, que ce soit par intérêt commun ou parce qu'elles se connaissent réellement. Nous nous sommes donc interrogés sur l'impact que pouvait représenter l'élection d'une personne au sein de ces micro-communautés et si elle pouvait influencer sur tous les membres de ce groupe.

On peut alors se demander qu'elle est le réel découpage de la communauté de Wikipédia ? Est-elle constituée de plusieurs sous-groupes ou factions, promouvant les leurs au rang d'administrateurs et cherchant à empêcher les membres d'autres groupes de percer ? Où bien la communauté est-elle dans un esprit plus unitaire, agissant, globalement, d'un seul mouvement pour le bien de l'ensemble des membres et le bon fonctionnement du site ?

Gestion des données

Traitement des données originales

Le dataset original que nous avions à disposition comprenait plusieurs informations. Voyons par exemple les premières lignes de celui-ci :

# Wikipedia elections (http://cs.stanford.edu/people/jure/pubs/triads-chi10.pdf). Data format:
#   E: is election succesful (1) or not (0)
#   T: time election was closed
#   U: user id (and username) of editor that is being considered for promotion
#   N: user id (and username) of the nominator
#   V: <vote(1:support, 0:neutral, -1:oppose)> <user_id> <time> <username>
E	1
T	2004-09-21 01:15:53
U	30	cjcurrie
N	32	andyl
V	1	3	2004-09-14 16:26:00	ludraman
V	-1	25	2004-09-14 16:53:00	blankfaze
V	1	4	2004-09-14 17:08:00	gzornenplatz
V	1	5	2004-09-14 17:37:00	orthogonal
...

Nous pouvons ici avoir un aperçu de la structure du fichier utilisée.

  • E indique le résultat du vote,
  • T la date de clôture du vote,
  • U le candidat au poste d'administrateur (numéro id et pseudonyme),
  • N l'administrateur ayant clôturé l'élection (numéro id et pseudonyme),
  • V le vote réalisé, constitué de la valeur du vote émit, de l'identifiant du votant, de la date du vote et du pseudonyme du votant.

La majorité des informations renseignées sont intéressantes et vont être utilisées. Nous devons donc commencer par savoir comment nous allons les stocker. Tout d'abord, nous allons commencer par les utilisateurs.

Ne connaissant encore aucune informations, nous ajoutons des points à notre graphe. Ces derniers représentent tous les utilisateurs, c'est-à-dire les candidats et les votants. Les nominateurs ne sont pas référencés comme tels. Leur rôle se limite à celui de témoin du nombre de votes et appliqueront le résultat de vote objectivement. Ils ont la possibilité de voter comme n'importe quel membre, et sont donc traités comme tels, mais leur fonction de nominateur n'est pas retenue puisqu'étant une simple application objective de leur devoir. Leur appartenance à une prétendue faction ne jouant alors aucun rôle sur la nomination. Les points contiendront l'identifiant de la personne et son pseudonyme.

Les arêtes contiennent davantage d'informations. Elle partent du votant pour aller vers la personne désignée. Elles renseignent la valeur du vote et la date à laquelle il a été réalisé. À des fins de disponibilité de l'information, les liens contiennent également le résultat final du vote et la date de clôture.

Nous avons donc rédigé un script, "DataTreatment", permettant le traitement du fichier texte de base et nous fournissant deux fichiers csv compatibles avec Tulip contenant la liste des points :

# U_id		user id
# U_name	user nickname
U_id	U_name
30	cjcurrie
3	ludraman
25	blankfaze
4	gzornenplatz
...

et l'ensemble des arêtes :

# V_id		voter id
# U_id		vote recipient
# Vote		value of the vote < 1 : support ; 0 : neutral ; -1 : against >
# Time		date of the vote
# Result_Vote	result of the vote
# Result_Time	date of the end of the vote
V_id	U_id	Vote	Time	Result_Vote	Result_Time
3	30	1	2004-09-14 16:26:00	1	2004-09-21 01:15:53
25	30	-1	2004-09-14 16:53:00	1	2004-09-21 01:15:53
4	30	1	2004-09-14 17:08:00	1	2004-09-21 01:15:53
5	30	1	2004-09-14 17:37:00	1	2004-09-21 01:15:53
6	30	1	2004-09-14 19:28:00	1	2004-09-21 01:15:53
...

Importation des données et opérations initiales

Les csv précédemment générés peuvent être directement importés en utilisant Tulip. Il faut bien évidemment commencer par les points et finir par les arêtes et prendre garde de bien supprimer les premières lignes marquées par un “#” et ne servant qu'à expliquer les champs.

Avant toute chose, nous avons cherché une visualisation contenu dans le logiciel permettant de clarifier l'affichage. La plus intéressante que nous avons trouvé est celle nommée FM^3.

[Image FM^3]

Sa mise en place des données nous permet déjà d'observer plusieurs faits. Tout d'abord, les points ne sont pas tous reliés entre eux. Certains sont isolés et regroupés par 2 ou 3 éléments.

Si l'on s'intéresse à ces éléments, nous nous rendons compte que ce sont des micro-groupes, d'après la définition de nos données. En effet, plusieurs personnes ont votées pour une même personne. Cependant, les relations trouvées sont inutiles. Nous pouvons voir une personne qui a voté pour elle-même et les autres groupes sont vraiment petits et n'ont pas de poids face au groupe que l'on peut identifier en bas à gauche.

C'est très précisément ce groupe important qui va nous intéresser et qui doit contenir les fameuses factions.

Questions relationnelles

Notre recherche de groupes implique plusieurs paramètres. Avant toutes chose, nous devons trouver la définition de ce qu'est un groupe. Le dictionnaire Larousse peut nous assister pour ce cas :

Groupe :

  • Partie homogène d'un ensemble dans une classification : Division en groupes et en sous-groupes.
  • Ensemble de choses, d'animaux ou de personnes, formant un tout et définis par une caractéristique commune.
  • Ensemble formé par des choses ou des êtres de même nature et, en particulier, ensemble défini par le nombre ou la quantité qui le constitue (par opposition à un).

La seconde définition apportant l'idée d'une caractéristique commune est extrêmement intéressante. Qu'est-ce qui, au juste, va nous permettre d'identifier un groupe donné ?

Dans le monde réel, un groupe de personnes est le plus souvent construit par rapport à un intérêt commun ou sur la base d'une amitié entre plusieurs de ses membres. Les groupes virtuels suivent-ils la même logique ou alors sont-ils complètement différents ?

Si nous suivons le modèle réel classique, nous nous rendons compte que nous manquons d'informations. Comment savoir si deux personnes sont réellement amies et si le vote n'est pas dû qu'au respect dû à une personne pour son travail sur le site ou au hasard ?

Nous ne sommes malheureusement pas en mesure de le savoir. Ne possédant que les votes comme indicateurs de liens entre les personnes, nous considérerons que ces derniers sont les signes de la caractéristique énoncée plus haut indiquant l'appartenance à un groupe.

Comment pouvons nous utiliser les votes pour identifier les groupes ? Pour commencer, réfléchissons aux différentes formes de constructions possibles. Le groupe peut soit s'organiser autour d'un leader, soit autour d'une relation partagée entre plusieurs personnes. De façon logique, le leader devrait être la première personne élue au rang d'administrateur par les autres, à moins d'un vote négatif massif de la part d'une autre faction visant à empêcher cette élection.

Nous décidons donc de partir de cette hypothèse de lien temporel dans un premier temps. [Voir partie : Élections en fonction du temps]

La seconde hypothèse que nous allons formuler va davantage se baser sur les votes réalisés et reçus. Si une personne entre en candidature pour le poste d'administrateur, tout le groupe va voter pour elle afin d'augmenter son pouvoir. Par la suite, dès qu'une autre des personnes du groupe proposera sa candidature, l'ensemble du groupe votera de la même manière. En accord avec ce fait qui nous semble naturel, nous avons basé notre seconde hypothèse sur ce principe de réciprocité de vote, permettant de mettre en évidence les sous groupes. [Voir partie : Recherche de sous-groupes par réciprocité]

Issue des déductions de la seconde hypothèse, la troisième hypothèse nous permet de détecter l'existence de factions. Si au sein d'un groupe, une élection permet à tous de donner leur voix au candidat, la faction inverse devrait, en théorie, s'opposer farouchement à cette nomination. Ainsi, les membres d'une faction pourrait s'identifier par le fait qu'ils appartiennent à une même groupe et qu'ils s'unissent contre une troisième personne. [Voir partie : Recherche de factions par ennemis communs]

Élections en fonction du temps

Dans un premier temps, nous voulions réduire la quantité de nœuds, car les algorithmes sont généralement plus rapides sur un petit ensemble de données. Notre dataset s’étalant de sur cinq années, nous avions donc pensé à créer un découpage sur la dimension temporelle. En effet et grâce à la fonction initDecoupe, nous éclatons le graphe original en cinq sous graphes puis répartissons les points par années (2004 à 2008 inclus) en utilisant “decoupeAnnuelle”. Puis chacun de ces sous graphes est morcelé en douze mois (sous graphes) en faisant appel à “decoupeMensuelle”. Il est important de noter que ces deux fonctions contiennent un appel à l’outil subGraphDate.

Cette fragmentation nous a donné un premier renseignement sur l’évolution de la participation des personnes à ces élections qui passe de 359 nœuds et 1 591 arêtes en 2004 à 6 546 nœuds et 100 563 arêtes en 2007 (l’année 2008 n’est pas complète); preuve d’une augmentation conséquente.

Dans un deuxième temps, nous avons essayé de regarder s’il existait des retours de faveurs chez les électeurs. Ainsi, prenons une personne A et un ensemble de personnes D qui ont votés favorablement pour A, et ainsi garanti à A son élection, sans qu’elles-mêmes soient des administrateurs. Il semble naturel que si A connaissait ces personnes, comme si elles étaient sa famille ou ses amis, il voterait pour eux en retour afin de les aider à accéder au cercle fermé des élus. L’ensemble E résultant de ce dernier point est alors inclus dans D et est désigné comme le groupe de retour de faveur. On comprend alors l’utilité et l’implication de la dimension temporelle, car nous devons récupérer la date d’élection de A et la comparer avec ses votes pour trouve ceux qui sont postérieurs à cet événement. En plus de cela, elle nous permet d’éliminer des groupes qui serait trop ancien et regarder à quel point A participera dans le temps à l’élection de ses amis.

C’est à travers la procédure “find_patient0” que nous allons établir ces groupes (création de sous-graphes). Elle prend donc en paramètre le graphe orignal et une date de départ. En plus de cela, et afin d’éliminer les groupes trop petits, nous avons introduit un paramètre pour indiquer le nombre minimum de personnes dans l’ensemble D. Elle fait appel sur chaque ensemble D pour un A donné à la procédure check_copain qui retourne l’ensemble E parmi D. Cette dernière utilise l’outil “find_node_UID”, car nous devons faire le lien entre l’id lue sur l'arête d’un nœud et l’id réelle de celui-ci donné par tulip (on recherche l’objet Node correspondant).

L’image ci-dessus représente le plus grand groupe que nous avons trouvé (16 nœuds) où A fut élue en 2006. Nous avons fait un FM^3 sur le graphe déduit et un algorithme du degré entrant pour retrouver clairement la personne A et l’ensemble des personnes E qui sont coloriées du rouge à bleu très clair en passant par le jaune pour indiquer que les degrés entrant à ceux-ci sont faibles par rapport à notre nœud central. On remarque tout de même certains membres de E qui ont reçu beaucoup de votes ce qui permet de présupposer que les nœuds ayant une couleur bleue autre qu’A sont très connus des amis de A.

Regroupement par triade

Les parties suivantes font appelle aux relations entre les membres pour décrire leur ressenti à l'égard de l'autre. Si une personne A apprécie une personne B, elle lui donnera son vote; si les deux personnes s'entendent bien les votes seront réciproques…

Ne possédant pas de réelles informations sur les relations entre personnes, l'utilisation des votes est le seul moyen pour voir les interactions entre les gens.

Nous pouvons alors définir ce que nous appelons des triades. Ce terme désigne les relations entre 3 personnes. Dans chacune des parties suivantes nous donnerons un schéma permettant de représenter le type d'interaction cherché.

Recherche de sous-groupes par réciprocité

D'après la seconde hypothèse que nous avons émis, un groupe est défini par des personnes témoignant d'une réciprocité par rapport aux votes réalisés.

Nous devons donc traiter toutes les triades de points de la forme suivante : Schéma d'une triade positive

Chacun des points A, B et C vote pour les deux autres positivement. Nous cherchons donc pour un point A par exemple, tous les couples B et C respectant cette condition. Nous stockons ensuite ces ensembles dans des sous-graphes pour pouvoir travailler dessus par la suite. Par exemple avec un ensemble de triades regroupant 58 points :

 Ensemble de triades sur 58 points

Ces ensembles sont créés par la fonction “TriangulationPositive(graph, k)” où k indique le double du nombre de points minimal que contiendrons les ensembles que l'on calcul. Si le nombre de points n'est pas suffisant, l'ensemble n'est pas ajouté à la liste.

Nous avons ainsi regroupé plusieurs points qui, semblerait-il, forment des groupes.

Recherche de factions par ennemis communs

Le principe est pratiquement le même que celui posé précédemment. Seulement, dans ce cas ci, la réciprocité de votes positifs entre tous les membres n'est pas ce que l'on recherche. Nous nous intéressons ici aux groupes s'opposant à une personne particulière.

Le schéma suivant permet d'illustrer les triades que nous recherchons :

B et C sont considérés comme amis, leurs votes étant réciproques, et ils se liguent contre A.

Pour réaliser cette opération de tri, nous utilisons la fonction “TriangulationAgainst(graph, k)”. Le résultat obtenu est bien moins satisfaisant que celui obtenu avant. En effet, seuls deux personnes semblent avoir été exclues par des groupes de personnes et, pour chaque cas, le nombre d'opposant ne dépasse pas cinq.

Les résultats sont bien en dessous de ce que l'on a observé avec les votes réciproques. Si nous essayons d'être un peu plus flexible au niveau des contraintes en supprimant la nécessité du vote négatif de A vers B et C, nous obtenons des résultats beaucoup plus intéressants.

Par exemple :

Cependant, la suppression du vote négatif de A à l'encontre de B et C ne traduit pas vraiment l'existence de factions s'opposant l'une à l'autre, mais plutôt fortifie l'idée de groupes votant pour leurs membres.

Nous ne pouvons donc pas mettre en avant l'existence réelle de groupes s'opposant les uns aux autres.

Généralisation de la recherche de sous-groupes par réciprocité

Nous décidons donc de développer la recherche de groupe par vote réciproque. L'ensemble des solutions que nous récupérons avec “TriangulationPositive(graph, k)” n'est cependant pas idéal. Afin de pouvoir travailler sur un échantillon plus intéressant, nous décidons de récupérer tous les points proposant des liens positifs réciproques sur tout l'ensemble du graphe.

La fonction développée à cette attention se nomme “Faction(graph)”. Attention, l'exécution de cette fonction sur un de nos postes de travail (processeur QuadCore 3.1GHz) à pris plus de deux heures. Le résultat obtenu a été stocké dans le sous-graphe “Factions”.

Nous réalisons ensuite un autre traitement du graphe permettant d'isoler le sous-groupe nous intéressant, le numéro 4148 pour notre cas, puis nous réalisons la fonction “FactionFor” ne gardant que les arêtes positives et supprimant tous les noeuds n'ayant plus leur place au sein du groupe.

Nous obtenons finalement un graphe bien plus épuré.

Sous-graphe nettoyé présentant les groupes tels que définis

Celui-ci ne contient plus que 534 points et 1726 arêtes. Il faut noter que ce graphe ne se base plus seulement sur les triades réciproques positives mais sur tous les liens réciproques positifs existants dans le graphe. L'ensemble que nous obtenons alors rassemble tous les groupes tels que décrits dans notre définition.

La première observation que nous pouvons réaliser est que, de manière évidente, il n'y a qu'un seul groupe qui se détache des autres. Nous pouvons également voir que plusieurs noeuds se trouvent au milieu et semble être reliés à beaucoup d'autres. Nous réalisons un calcul de “betweeness centrality” pour trouver les points d'articulation du groupe principal :

Betweenness Centrality sur le groupe principal

Les deux points mis en évidence sont ce que l'on pourrait nommer les centres du groupe. Tout le groupe s'est construit autour de ces personnes. On peut donc en conclure qu'elles sont extrêmement importantes pour la communauté.

Les opérations que nous avons réalisé ici nous permettent de voir que finalement il n'y a pas énormément de groupes, mais plutôt, un seul ensemble de personnes représentant le coeur de la communauté, près de 1/10 de tous les membres ayant votés, qui s'avère assez soudé.

Limite de l'utilisation des triades

L'utilisation des votes comme lien d'amitié ou de connaissance est inattendu est peut-être critiquable sur plusieurs points.

  • Tout d'abord, le vote n'implique pas la connaissance ou l'appréciation du désigné.
  • D'après nos informations, toute personne ne s'étant pas présentée ne peut être considéré comme appartenant à un groupe.
  • Nous ne testons que deux ou trois modèles de triade sur toutes les possibilités. Nous manquons donc plusieurs cas pouvant exister.

Tester toutes les représentations pour se faire une vrai idée des différents modèles de groupes probables ou existant est bien trop long et nous estimons que les cas choisis correspondent le plus simplement aux cas cherchés. Un approfondissement de l'étude des triades aurait pu être intéressant.

Résultats et Conclusion

Les différents algorithmes développés ont permis de mettre en avant des factions matérialisant deux types de groupes : un noyau très important de votants et de petites assemblées de deux ou trois personnes. Parmi celles-ci, il n’y en a aucune de taille importante qui se démarquerait en tant que groupe d’opposition, c’est-à-dire qui se liguerait contre une ou plusieurs personnes. Dans le plus gros groupe, on remarque, à l'aide de la fonction “EvolutionDate”, qu’il s’agrandit au fil des années et que le nombre de participants actifs au cours du temps augmente.

Au vu des résultats obtenus, nous nous devons d'admettre notre erreur. En effet, nous pensions, tout d'abord, trouver plusieurs grandes factions. L'utilisation des triades nous aurait permis de mettre en évidence les liens, aussi bien positif entre les membres, que négatif entre les opposants.

Finalement, il s'avère que les utilisateurs de Wikipédia sont dévoués et travaillent tous dans le même sens. Leur but est d'améliorer le site et ceci peut être prouvé par la présence d'un seul groupe. Celui-ci est majoritaire et rassemble tous les membres les plus actifs. L'objectif visant à comprendre la répartition des utilisateurs de Wikipédia est donc atteint.

Néanmoins, nous pensons qu’avec l’expansion de Wikipedia depuis 2008 les résultats ont très certainement évolué. Il se peut alors qu'un groupe d'opposant se soit développé mais si l'ensemble des membres ont pour but l'amélioration de Wikipédia, il est plus probable que le groupe solide que nous avons isolé ici ait été renforcé. Il aurait été intéressant de trouver un jeu de données plus récent afin de vérifier ces faits.

Au travers des recherches que nous avons effectuées, nous avons put trouver différentes publications scientifiques se servant d'un jeu de données assez similaire au notre. Cependant, les leurs s’avéraient comporter des informations que l'on aurait pu assimiler à des liens d’amitié. Nous aurions pu répondre à notre problématique plus surement si nous avions disposé de telles informations. Nos algorithmes auraient donc été simplifiés et nous nous serions plus attardés sur la représentation de données plutôt que sur l’analyse de celles-ci, même si ces deux notions sont fortement liées.

Publications consultées

  • Network Analysis for Wikipedia, F. Bellomi and R. Bonato, 2005
  • Interaction vs. Homophily in Wikipedia, Administrator Selection, Allen Lavoie
  • Governance in Social Media: A case study of the Wikipedia promotion process, Jure Leskovec, Daniel Huttenlocher, Jon Kleinberg, 2010
  • Voting Behavior Analysis in the Election of Wikipedia Admins, Gerard Castillo, Ralph Lee, John Boaz, 2011

Lors de la rédaction finale du présent Wiki, nous avons également découvert une publication dont l'adresse était renseignée dans le fichier de jeu de données :

  • Signed Networks in Social Media, Jure Leskovec, Daniel Huttenlocher, Jon Kleinberg, 2010
/net/html/perso/melancon/Visual_Analytics_Course/data/pages/vallet_vandewynckel/jason_vallet_julien_vandewynckel.txt · Last modified: 2012/05/04 17:58 by melancon