Une architecture multi-agents pour la découverte et la construction de profils utilisateurs distribués
1. Anis Chouchane, Amel Bouzeghoub TELECOM SudParis, Département Informatique 9, rue Charles Fourier, 91011 Evry, France Une architecture multi-agents pour la découverte et la construction de profils utilisateurs distribués EGC 2010
2.
3.
4. Page EGC 2010 – Hammamet, Tunisie 26 - 29 janvier 2010 Profil 3 Profil 2 Profil 1 Syst è me de gestion du profil Service de recommandation Introduction Adaptation selon le contexte Partage de profils (intérêts…) Demande d’informations sur le profil Internet Service de ressources pédagiques Profil intégré Fragments de profil
5.
6.
7.
8.
9.
10.
11. Page EGC 2010 – Hammamet, Tunisie 26 - 29 janvier 2010 Etat de l’art Comparaison des standards du modèle utilisateur + : support total p : support partiel x : capacité à être étendu Contexte courant ? + + x + + p + + PAPI x + Sécurité Catégories Sous-catégories IMS LIP FOAF Données personnelles + + Relations A d’autres profils + Référence aux autres + Groupe / Org description p + But + Réalisations et Historique Activité + Compétences + Certification + Transcript + Intérêts + + Accessibilité Langue + + Style d’apprentissage + Eligibilité + Incapacité + + Systèmes éducatifs +
12.
13.
14.
15.
16. Page EGC 2010 – Hammamet, Tunisie 26 - 29 janvier 2010 Modèle de profil apprenant Proposition d’un modèle apprenant } LIP FOAF Données stables Contexte LIP Donnés dynamiques
17.
18.
19. Page EGC 2010 – Hammamet, Tunisie 26 - 29 janvier 2010 Architecture de gestion de profils distribués Communication entre les agents Adaptor 1 Mediator Adaptor 2 Provider Manager Agent System Agent Service Manager Agent Service 1 User Device Agent Ontobroker 1 : envoi requête 5 : oui ? 6 : récupération de données 6 : récupération de données 5 : non ? fin du processus 3 : transfert requête 4 : accord de l’utilisateur ? 7 7 7 : envoi des fragments récupérés Service Agent 2 : création Agent Service 8 : envoi du profil integré Provider Agent 2 Provider Agent 1 Création Agents Fournisseurs 9 :envoi du profil 10 : Recommandation
20.
21.
22.
23.
24.
25. Page EGC 2010 – Hammamet, Tunisie 26 - 29 janvier 2010 Merci de votre attention
26. Page EGC 2010 – Hammamet, Tunisie 26 - 29 janvier 2010 L Aroyo, P Dolog, GJ Houben, M Kravcik, A Naeve, M Nilsson, F Wild Interoperability in Personalized Adaptive Learning Educational Technology & Society (Projet Prolearn), 2006. Andreas von Hessling, Thomas Kleemann, and Alex Sinner, Semantic User Profiles and their Applications in a mobile Environment, 2005. D.L. Musa, J.P.M de Oliveira, Integration of Distributed Learner Information through Web Services, 2005. FOAF (Friend Of A Friend, projet Open Source), 2007. http://www.foaf-project.org/ ; http://fr.wikipedia.org/wiki/FOAF Houben, J., Geert-Jan Houben, Ad Aerts, Lora Aroyo, Kees van der Sluijs, Bas Rutten, Paul De Bra., State of the art: semantic interoperability for distributed user profiles, Telematica Institut Report, 2005. IMS LIP (Information Model Specification, Learner Information Packaging), 2001. Références (1)
27. Page EGC 2010 – Hammamet, Tunisie 26 - 29 janvier 2010 Jameson A., User Adaptive Systems An integrated Overview. Tutorial presented at the 7th International Conference on User Modeling, June 20-24, 1999. K. Kabassi et Maria Virvou, Using Web Services for Personalised Web-based Learning, Educational Technology & Society, 6(3), 61-71, 2003. Katerina Kabassi and Maria Virvou, 2003. Using Web Services for Personalised Web-based Learning Mohammad Alrifai, Peter Dolog, Wolfgang Nejdl Learner Profile Management for Collaborating Adaptive eLearning Applications., 2006. P3P (Platform for Privacy Preferences, W3C) http://www.w3.org/P3P/, 2002. PAPI Learner (Public and Private Information, IEEE), 2000. http://edutool.com/papi/ Références (2)
Notes de l'éditeur
Je vais présenter l’article que j’ai publié dans le cadre de ma thèse que j’effectue à TELECOM SudParis en France sous l’encadrement de Mme Amel Bouzeghoub. L’article est intitulé « une architecture multi-agents pour la découverte et la construction de profils utilisateurs distribués ».
Le plan de cet exposé se compose en 5 parties, je commencerai par une introduction, suivie de l’état de l’art. Ensuite je présenterai une proposition de modèle de profil apprenant, une architecture de gestion de profils distribués, et enfin, je finirai pas une conclusion.
Au cours d’une activité d’apprentissage, différents utilisateurs apprenants se connectent à un service de ressources pédagogiques en utilisant des dispositifs mobiles comme un ordinateur portable, un PDA.. Chaque utilisateur dispose d’un ensemble de profils distribués sur le web (tels que les sites de web sociaux facebook, google, linkedIn etc). Afin de fournir à l’utilisateur des informations adaptées à son profil, il est nécessaire d’intégrer ces fragments de profils distribués. Le système de gestion de profil sera l’interface entre l’utilisateur et le service de recommandation qui pourra proposer des recommandations à l’utilisateur adapté à son contexte courant en se basant sur son profil. D’autre part, l’utilisateur peut avoir la possibilité de partager certaines informations de son profil avec les membres de sa (ses) communauté(s).
Ainsi, les problèmes auquel on peut faire face dans l’élaboration de ce scénario : Les informations du profil utilisateur sont distribués et hétérogènes dans les systèmes de profils. Ce qui nécessite l’intégration de ces fragments de profils suivant des critères bien précis. L’identification des fragments de profil distribués sur différents sites web est nécessaire pour les services d’adaptation. Il faudrait donc adapter ces informations suivant le contexte de l’utilisateur. Les données du profil étant considérées comme des informations confidentielles, il convient alors de de trouver un moyen pour utiliser ses informations avec l’accord de l’utilisateur. D’autre part, comme les données du profil utilisateur sont il est utile d’étudier les moyens et les normes permettant à l’utilisateur d’interopérer avec les différents membres de sa communauté.
Notre objectif est donc composé de 2 parties : il s’agit d’abord de : Proposer un modèle de données pour la gestion des profils apprenants dans un contexte mobile en se basant sur les modèles existants. Ensuite : Proposer une architecture pour la découverte et la construction du profil apprenant. Pour cela, nous avons développé un prototype permettant à un service donné de proposer des recommandations à un apprenant adaptées à son profil. Ce dernier étant construit dynamiquement et à la demande.
Afin de proposer un modèle pour la gestion des profils utilisateurs, il convient d’étudier les différents standards existants sur la structuration des données du profil. Les standards de modélisation que nous présentons sont PAPI, IMS LIPS et FOAF. PAPI Learner (2000) : standard proposé par le groupe Learner Model Working Group de l'IEEE, il décrit les informations sur l’apprenant utiles pour la communication entre les systèmes coopératifs. Et se focalise sur les performances et les interactions entre apprenants. PAPI décompose le profil en 6 catégories : Informations personnelles, Relations, Sécurité, Préférences, Performances, Portfolio .
IMS LIP : Une spécification décrivant une approche classique de CV structuré. Son but est de faciliter l'échange d’informations sur les apprenants entre les systèmes éducatifs et les systèmes de gestion d'apprentissage. Elle possède une structure composée de 11 catégories.
FOAF (Friend Of A Friend) : Une spécification basé sur RDF et décrivant des personnes et les relations qu’elles entretiennent entre elles. 5 catégories.
Afin de comparer les standards de modélisation, on a établi un tableau de comparaison avec comme critères les les catégories principales de description du profil. IMS LIP définit une structure de données plus riche que PAPI, en introduisant des éléments tels que les objectifs, les intérêts et les préférences de l’apprenant, éléments indispensables pour les applications d’adaptation. FOAF possède l’avantage de pouvoir gérer totalement les relations entre plusieurs profils utilisateurs. Les modèles IMS LIP et PAPI sont définis dans le cadre de systèmes éducatifs. Nous constatons que ces modèles ne prennent pas en compte le contexte courant de l’utilisateur, un critère important dans l’étape d’adaptation du profil.
De la même manière qu’on a décrit les normes de modèle de profil utilisateur, nous présentons une étude des architectures de gestion du profil dans les systèmes d’adaptation et de personnalisation. Il existe pour cela 2 types d’architecture…
L’architecture centralisée permet un contrôle central qui réalise des opérations comme : le stockage et la récupération des données, l’analyse des demandes, etc.
L’architecture distribuée est adaptée lorsque les données sont distribuées sur plusieurs « nœuds ».
11 catégories : Une fusion des modèles IMS LIP et FOAF IMS LIP: fournir un vocabulaire plus riche que PAPI FOAF: gérer les relations entre les apprenants Extension décrivant le contexte de l’utilisateur (dispositif), et l’agenda. L’agenda : source d’informations très utile pour des systèmes de recommandation. Classification des données Un profil apprenant contient plusieurs informations. Chaque type d’information a des caractéristiques différentes. Alors, pour simplifier la gestion, une classification des informations est nécessaire. On s’intéresse ici au c ritère suivant : la stabilité Les informations stables : Les données personnelles de base, Les données éducatives Les informations dynamiques : Les tâches, L’agenda
Implémentation d’un prototype basé sur l’architecture multi-agents. - L’architecture du système est composée de 3 agents principaux . (Un système multi-agents est composé d’un groupe d’agents autonomes ou semi-autonomes qui interagissent entre eux, afin de réaliser des tâches ou atteindre quelques buts.)
Communication entre les agents : Lorsqu’un service externe souhaite proposer une recommandation à l’utilisateur, il envoie une requête à l’Agent Gestionnaire de Services demandant une liste d’informations du profil. L’Agent Gestionnaire de Services va donc créer l’Agent Service correspondant. Ce dernier se base sur cette liste d’informations pour relayer la requête et l’envoyer à l’Agent Système. Ensuite l’Agent Système se base sur cette requête pour demander à l’utilisateur s’il est d’accord pour que ces informations soient utilisées. Si l’user n’accepte pas, le processus se termine ici. Si l’user accepte, L’agent système se base sur les informations login de l’utilisateur pour déterminer les fournisseurs du profil de l’utilisateur. En se fondant sur les connaissances concernant ces fournisseurs (liste des informations du profil qu’il maintient), l’agent système crée une requête, et l’envoie à l’agent gestionnaire du fournisseur. L’Agent Système analyse la liste des données renvoyées pour décider quelles informations seront récupérées de la base de données du système, et quelles informations seront récupérées directement à partir des fournisseurs de profils. Après avoir reçu la requête, l’agent gestionnaire de fournisseur l’analyse, et ensuite crée les Agents Fournisseurs correspondants à chaque fournisseur de profils. Le système dispose, pour chaque fournisseur de profils, d’un adaptateur correspondant qui se connecte au fournisseur afin de récupérer le fragment du profil. Les agents fournisseur vont donc communiquer avec les adaptateurs correspondants pour récupérer le fragment du profil. Puis ils l’envoient à l’agent système. Après avoir reçu tous les fragments, l’agent système met en œuvre le processus d’intégration des fragments, traite le conflit des données, et stocke le résultat dans la base de données. Après avoir reçu les résultats des ressources, l’agent système les combine afin de créer un profil complet. Ensuite, il l’envoie à l’agent service. Finalement, l’Agent Service renvoie ce profil à l’agent service extérieur, et ainsi le service envoie la recommandation à l’utilisateur. A la fin du processus, les Agents Service et Fournisseurs sont supprimés.
Intégration selon le type de données : Pour les données stables, l’intégration se fait une seule fois à partir du serveur de profil. Pour les données dynamiques, l’intégration se fait seulement au moment du besoin et pour un objectif spécifique. Mobilité : L’utilisateur peut se connecter à partir de différents dispositifs mobiles et peut accéder aux informations sur son profil n’importe où, n’importe quand et en temps réel. Evolutivité : Possibilité d’ajout de nouveaux fournisseurs de profils au système. Possibilité d’ajout de nouveaux services de consommation du profil.
Collaboration : Il est possible de partager les profils ente les utilisateurs si des accords existent entre eux. Confidentialité : La communication entre profils est effectuée à travers des accords entre les deux partis en utilisant P3P (Platform for Privacy Preferences). Autonomie : Les agents réduisent le trafic au niveau du réseau. Ils sont exécutés d’une manière asynchrone et autonome. Le choix de l’architecture multi-agents permet de déployer et d’élargir le système facilement dans un environnement ubiquitaire, surtout sur des dispositifs ayant une configuration faible.
Pour mettre en œuvre l’architecture présentée, nous avons implémenté un framework développé avec Java….