Back to ResearchWorks

 

 Subject of my PhD thesis / Sujet de thèse

 

 

Subject in english :

« Contextual filtering of mediated interactions »

 

Sujet en français :

 

Contribution principale

 

Moteur de filtrage en charge de :

• Sélectionner et diffuser des informations du contexte d’un utilisateur qui pourraient être valorisées sur son réseau social (en provocant de la communication)

• Filtrer et agréger les interactions du réseau social de cet utilisateur de manière à donner un ressenti de son état actuel, de manière plus ou moins pertinente par rapport au contexte actuel de cet utilisateur, en fonction de la granularité d’information souhaitée.

 

 

Architecture

 

 

Contributions secondaires

 

• Définition d’un cadre applicatif pour le développement de visualisations de l’état actuel du réseau social

• Recommandation d’applications sociales permettant d’optimiser un motif d’interaction identifié

 

 

Contraintes

 

• D’abord répondre à un use case concert pour ensuite généraliser l’approche

• Prendre en compte le feedback de l’utilisateur pour affiner le filtrage

 

 

Expérimentation proposée

 

Afin de pouvoir vérifier que le filtrage des interactions sociales basées sur le contexte des utilisateurs permet de leur proposer des informations sociales intéressantes et pertinentes, nous allons réaliser un premier prototype dont l'utilisation sera expérimentée.

 

Afin de récupérer un spectre large d'interactions sur un ensemble cohérent et suffisant d'utilisateurs sans reposer sur une telle plateforme sociale, nous proposons de développer une application expérimentale d'« ambiant awareness Â» dans le cadre d'une entreprise (ou de tout autre structure reposant sur une infrastructure logicielle commune suffisamment riche). Cette application tirera parti de tous les fournisseurs  exploitables d'information sur les employés de cette entreprise (ex: annuaire professionnel, outils de partage d'information, archives documentaires, canaux de communications...) afin de consolider un réseau social dont les données seront diffusées en fonction du contexte de ses utilisateurs (les employés) et de règles de contrôle (pour gérer la vie privée et la confidentialité). Ici, le contexte est le type d'activité en cours d'exécution, le sujet d'un travail en cours (projet) ou d'une discussion professionnelle.

 

 

Architecture de la solution initiale

 

Nous proposons de concevoir un premier prototype selon l'architecture suivante:

 

Appliqué à une communauté d'employés, ce premier prototype sera constitué d'une plateforme serveur pour consolider le réseau social et d'un ensemble de clients connectés au nom de chaque employé utilisateur. Les données sociales seront à la fois extraites de l'infrastructure logicielle de l'entreprise et des stations de travail exécutant le client logiciel. Ce client logiciel récoltera des informations sur les activités informatiques et communications en cours de chaque utilisateur, filtrera ou synthétisera ces informations pour ne garder que les plus pertinentes pour le réseau social, après application de règles de contrôle. Chaque utilisateur aura le contrôle sur les informations le concernant sur le réseau social. Aucune information personnelle ne sera transmise sur le réseau social sans son accord. En retour, chaque utilisateur aura une visualisation en temps réel (et historique) des interactions actuelles (et passées) du réseau social en rapport avec son activité actuelle. L'affichage contextuel de ces interactions sociales ont pour but de stimuler la communication entre employés en utilisant la proximité contextuelle de leurs activités comme point d'accroche pour une discussion (ou autre échange d'informations).

 

 

Définition du « contexte Â» considéré

 

 

Dans notre prototype, nous définissons un « contexte Â» par les quatre dimensions suivantes:

• l'activité en cours (cf. types d'interactions envisagés, ci-dessous)

• l'entité / identité de l'effecteur (i.e. l'auteur ou l'agent logiciel initiateur de l'action)

• le sujet / l'objet de l'activité (ex. un nom de projet, un domaine...)

• l'heure de l'activité

   

Ces données pourraient être exprimées de manière sémantique afin de permettre une mesure de similarité/distance entre concepts et une représentation plus ou moins précise en fonction de la granularité du filtrage et le degré de divulgation souhaités.

 

 

Types d'interactions envisagés

 

Dans cette section, nous proposons une liste non exhaustive d'informations qui pourraient être récoltées afin de nourrir la base d'interactions:

• participation d'une personne P à un événement/rendez-vous E (ex. réunion)
• une personne P publie un contenu SC (dont elle est l'auteur)
• référence à une personne P sur un contenu partagé SC
• annotation d'une personne P sur un contenu partagé SC (note ou commentaire)
• discussion entre plusieurs personne P* sur un sujet S (chat/IM)
• visite d'une personne P sur un site internet WS (domaine)
• visite d'une personne P sur une page internet WP
• une personne P est en train de rédiger un document D
• une personne P vient de poster un status S (twitter)
• une personne P vient de quitter son poste de travail (logoff)
• une personne P vient de rejoindre son poste de travail (logon)

 

 

Reconnaissance du contexte

 

Les actions/interactions seront reconnues par le sniffer tournant en tâche de fond sur la machine de l'utilisateur, grâce à des requêtes au système d'exploitation ainsi qu'aux API des logiciels qui le permettant.

 

Le mécanisme de reconnaissance du sujet/objet de l'activité sera spécifique à chaque action/interaction identifiée. Une approche semi-automatique est souhaitée, permettant à l'utilisateur de corriger les résultats du mécanisme de reconnaissance en cas d'erreur, ce qui devra affiner la qualité de ses prochains résultats. Dans la plupart des cas, une analyse textuelle du contenu basée sur l'identification de mots clés suffirait à se faire une idée du sujet. Il est aussi envisageable d'exploiter des connaissances sur les personnes/agents concernées par l'interaction (ex. groupe de personnes étant connu pour travailler sur un projet commun) ainsi que sur les autres métadonnées éventuellement disponibles sur l'objet de l'interaction (ex. nom d'un fichier, description sémantique d'une ressource...).

 

Lorsque le contexte est reconnu, il est représenté de manière concise à l'utilisateur, sous  forme d'une notification, d'une manière semblable à un message twitter, éventuellement enrichi avec des éléments graphiques ou multimédias (comme le news feed de facebook). Cette représentation du contexte est accompagnée d'une version traitée par les filtres de confidentialité de l'utilisateur et de l'entreprise, telle qu'elle sera stockée sur la base d'interactions et diffusée au réseau social (les autres utilisateurs). L'utilisateur a alors la possibilité de:

• consulter le raisonnement qui a conduit à la reconnaissance de ce contexte
• corriger les éléments de contexte reconnus, et éventuellement le raisonnement
• régler la précision du contexte qui sera diffusé, voire empêcher sa diffusion
• annoter/commenter ce contexte de manière libre
• forcer la diffusion de ce contexte à un/des utilisateur(s) spécifiés

 

Après validation, le contexte est transmis à la base d'interactions, et le moteur de filtrage décidera des modalités de sa diffusion dans le réseau social.

 

 

Filtrage et diffusion d'interactions contextuelles

 

Le moteur de filtrage tourne en permanence sur un serveur. Il est capable de diffuser de manière synchrone et adaptive les nouvelles interactions contextuelles générées par les sniffers vers les utilisateurs, et de générer à la demande un état plus ou moins synthétique concernant un sujet ou une entité basé sur leur historique récent.

 

Le filtrage adaptif consiste à:

• évaluer l'indice de pertinence d'une interaction effectuée par un utilisateur U1 avec le contexte actuel d'un destinataire potentiel U2, afin de décider de sa diffusion

• ajuster la précision de l'interaction à diffuser à chaque destinataire, en fonction des politiques de confidentialité de l'utilisateur émetteur et de l'entreprise

   

L'indice de pertinence sera basé sur la distance sémantique entre le sujet de l'interaction effectuée par l'utilisateur U1 et le sujet du contexte actuel du destinataire potentiel U2.

 

Le contexte actuel d'un utilisateur correspond à celui de sa dernière interaction diffusée. Il est envisageable d'intégrer avec un poids plus faible le contexte des interactions antérieures, du moment qu'elles sont complémentaires (ou en tout cas non contradictoires), afin de donner une certaine inertie au contexte.

 

 

Notifications contextuelles d'interactions

 

Une fois le contexte C1 de l'utilisateur U1 connu par le système, toute interaction I2 effectuée par U2 et jugée pertinente en ce contexte par le moteur de filtrage F sera notifiée à l'utilisateur U1.

 

Une notification doit faire apparaître de manière concise et discrète quelle interaction I2 vient d'avoir lieu et qui en est l'auteur U2. Cette interaction pourrait être représentée sous forme textuelle, éventuellement accompagnée d'éléments graphiques et/ou multimédias (à la manière du news feed de facebook).

 

L'utilisateur U1 doit être en mesure d'obtenir des informations de profile sur l'auteur U2, et de le contacter de manière simple et rapide. Il doit aussi pouvoir transférer cette information à un utilisateur U3. Il est aussi invité à annoter l'interaction par un commentaire, un ou plusieurs tags (mots clés) et/ou une note sur l'informativité/utilité de cette interaction pour le réseau social. Ces annotations sont considérées comme des interactions initiées par U1 et sont donc susceptibles d'être notifiées à U2. U1 doit être en mesure d'obtenir une explication sur le raisonnement mené par le filtre pour juger que I2 est pertinent avec le contexte actuel C1 de U1, et de corriger ce raisonnement (feedback) au cas où U1 ne la jugerait pas pertinente.

 

Dans le but d'éviter une trop grande quantité de notifications successives ou simultanées, un ensemble d'interactions jugées similaires par le moteur de filtrage devront être affichées de manière groupée et canonique dans une même notification.

 

 

Exemples de notifications (cas d'utilisations)

 

Cas n°1

Contexte C1: Entité=U1, Activité=Programmation, Sujet=ProjetEASY, Heure=11h45

Interaction I2: Entité=U2, Activité=« j'ai terminé le rapport Â», Sujet=ProjetEASY, Heure...

Interaction I3: Entité=U3, Activité=Programmation, Sujet=ProjetCOCO, Heure=11h35

Interaction I4: Entité=U3, Activité=« argh! segmentation fault... Â», Sujet=ProjetCOCO...

=> I2 est affiché car le sujet est le même que celui de C1

=> I4 est affiché car l'activité de I3 (interaction précédente) est la même que celle de C1

 

Cas n°2

Contexte C1: Entité=U1, Activité=Réunion, Sujet=ProjetEASY, Heure=9h35

Interaction I2: Entité=U2, Activité=Planification, Sujet=SocialCom, Heure 9h36

Interaction I3: Entité=U3, Activité=ModificationRapport, Sujet=ProjetEASY, Heure=9h37

Interaction I4: Entité=U4, Activité=ModificationRapport, Sujet=ProjetEASY, Heure=9h38

=> I2 est affiché car U1 appartient à l'équipe SocialCom (sujet de I2)

=> I3 et I4 sont affichés ensembles car leur activité est identique et sur le sujet de C1

 

Back to ResearchWorks