GESTION DE PROFIL APPRENANT DISTRIBUE DANS UN ENVIRONNEMENT UBIQUITAIRE

Institut de la Francophonie pour l’Informatique Telecom & Management SudParis MEMOIRE DE STAGE DE FIN D’ETUDES MASTER EN INFORMATIQUE GESTION DE PROFIL APPRENANT DISTRIBUE DANS UN ENVIRONNEMENT UBIQUITAIRE Stagiaire : NGUYEN Thanh Binh Responsable de stage : Amel BOUZEGHOUB Ce stage a été réalisé au sein de l’équipe Base des données du département Informatique de Telecom & Management SudParis Evry, Avril – Août, 2009 Remerciements Je tiens particulièrement remercier professeur Amel BOUZEGHOUB, mon responsable de stage, pour l’encadrement, l’aide, les conseils précieux pendant mois de mon stage Je tiens également remercier DO Ngoc Kien, un thésard Télécom & Management SudParis qui a travaillé avec moi pendant ce stage, et m’a beaucoup aidé grâce ses explications, ses conseils utiles et les documents J’adresse mes sincères remerciements tous les professeurs de l’Institut de la Francophonie pour l’Informatique (IFI) pour m’avoir enseigné et me donnée les cours intéressants pendant mes études au niveau master Je profite de cette occasion pour dire remercier tous les personnels de l’IFI qui m’ont apporté de l’aide Finalement, je voudrais remercier ma famille, mes parents et mes amis qui sont toujours près de moi et m’ont apporté de courage dans les moments difficiles RÉSUMÉ L’apprentissage pervasif est une façon d’utiliser les nouvelles technologies pour améliorer l’apprentissage traditionnel et élargir les perspectives du processus d’apprentissage lui-même L’un des objectifs principaux dans un environnement d’apprentissage pervasif est de fournir aux apprenants la bonne ressource au bon moment et de la meilleur façon Le profil apprenant est un concept important dans le domaine de l’apprentissage Une gestion efficace du profil apprenant est une bonne condition pour avoir de meilleurs services de recommandation des ressources De nombreuses solutions efficaces ont été proposées pour gérer le profil apprenant dans un environnement centralisé Mais dans le contexte mobile, la décentralisation du profil est encore un point étudier L’objectif de ce travail est double Il s’agit d’une part d’étudier les différents standards existants pour la modélisation du profil utilisateur, et de proposer un modèle pour la gestion des profils apprenant D’autre part, il vise proposer et réaliser une architecture pour l’intégration du profil apprenant adapté un contexte ubiquitaire Avec ce système, on peut récupérer, intégrer et gérer efficacement des fragments du profil apprenant dans un environnement mobile Mots-clés: profil apprenant distribué, modélisation, apprentissage pervasif, ontologies, système multi-agent, mobilité, web sémantique ABSTRACT Pervasive learning is a way to use new technologies to enhance learning and expand the traditional perspective of the learning process itself One of the main objectives of pervasive learning is to provide learners the right resource at the right time and in the best way Learner profile is an important concept in the field of learning An effective management of learner profile is a good condition for having the best services of resource recommendation There have been several effective solutions to manage the profile in centralized environment But in a context of mobility, decentralization of the profile is another point to consider This internship has two objectives First, we study the various existing standards for modeling the user profile, and then propose a model for managing learner profiles On the other hand, it is intended to propose and implement an architecture for integrating the profile learning suited to a ubiquitous environment With this system, we can retrieve, integrate and effectively manage fragments of learner profile in a mobile environment Keywords: distributed learner profile, modeling, pervasive learning, Ontology, Multiagent systems, mobile, semantic web Table des matières Introduction 1.1 Problématique 1.2 Objectif du stage 10 1.3 Environnement de travail 10 1.4 Organisation du mémoire 11 Etat de l’art 13 2.1 Définitions 13 2.2 Modèle apprenant 14 2.2.1 Standards et modèles de données du profil existants 14 2.2.2 Catégories du modèle apprenant 17 2.2.3 Comparaison des standards 19 2.2.4 Discussion 20 2.3 Langages de représentation de modèle apprenant 21 2.3.1 F-Logic 21 2.3.2 OWL 22 2.3.3 RDF 24 2.4 Architecture des systèmes de gestion du profil 24 2.4.1 Modèle de gestion 25 2.4.2 Techniques spécifiques 26 2.4.3 Discussion 29 Proposition d’un modèle d’apprenant distribué dans un contexte ubiquitaire 31 3.1 Description du modèle d’apprenant 31 3.2 Description de l’approche 35 3.2.1 Modèle de gestion de profil 35 3.2.2 Architecture du système proposé 36 3.3 Modélisation du scénario 38 3.4 Discussion 42 Réalisation 44 4.1 Représentation du modèle apprenant 44 4.1.1 Moteur d’inférence 44 4.1.2 Représentation des données 45 4.2 Spécification du système proposé 49 4.2.1 Plateforme multi-agent 49 4.2.2 Spécification des agents 52 4.2.3 Les messages 58 4.3 Méthodes de récupération des données 59 4.3.1 Parse web site 59 4.3.2 API de fournisseur 63 4.3.3 Discussion 64 4.4 Intégration de schémas et de données 64 4.5 Prototype 67 Conclusion et perspectives 70 5.1 Conclusion 70 5.2 Perspectives 71 Bibliographie 72 Annexe 74 A Les messages 74 Table des figures Figure 1: Eléments d’IMS LIP 15 Figure 2: Eléments de PAPI 16 Figure 3: Tableau comparatif des standards du modèle utilisateur 20 Figure 4: Une partie de la proposition du modèle apprenant 32 Figure 5: Architecture du système 37 Figure 6: Etape de prétraitement 40 Figure 7: Etape de traitement de la demande 41 Figure 8: Processus de mise jour des données 42 Figure 9: Architecture d’Ontobroker 45 Figure 10 : Schéma du modèle de l'utilisateur multi-dimensionnel 46 Figure 11: Plateformes et Container de JADE 50 Figure 12: Le cycle de vie d'un de JADE 51 Figure 13: Environnement d’exécution du LEAP-JADE 52 Figure 14: Les états de l'agent système 52 Figure 15: Les états de l'agent gestionnaire de service 54 Figure 16: Les états de l'agent gestionnaire de service 55 Figure 17: Les états de l'agent fournisseur 56 Figure 18: Les états de l'agent service 57 Figure 19: Les états de l'agent mobile 57 Figure 20: Exemple d'arbre DOM 60 Figure 21: Exemple des régions dans l'arbre DOM 62 Figure 22: Exemple d'un objet normal 63 Figure 23: Exemple d'un objet non-continue 63 Figure 24 : Quelques interfaces du dispositif mobile 67 Figure 25: Les messages échangés dans le processus de mise jour 68 Figure 26: Les messages échangés dans le processus de traitement d’une demande 68 Figure 27: Résultat sur service extérieur 69 Introduction 1.1 Problématique Un nouveau concept a émergé ces dernières années pour traduire le potentiel de l’informatique ubiquitaire dans le domaine de l’apprentissage Cette nouvelle façon d'utiliser des technologies pour soutenir les processus d'apprentissage est appelée "Apprentissage pervasif" Cette évolution s’intensifie ces dernières années avec l’émergence des terminaux mobiles et ultra-mobiles (par exemple : ordinateurs, portables, téléphones mobiles, Pocket PC, PDA) et des réseaux mobiles (GSM, 3G+, réseaux sans fil, Bluetooth, etc.) L’apprentissage pervasif utilise ces nouvelles technologies comme support pour améliorer l’apprentissage traditionnel et élargir les perspectives du processus d'apprentissage lui-même Il s’appuie sur un environnement riche en services et en capacité d’interaction (par exemple une salle augmentée ou smartroom) Cela permet d’accéder un contexte plus riche et une interaction qui se déroule travers de multiples dispositifs (par ex téléphone + écran tactile + détecteur de mouvement) Un des objectifs principaux dans un environnement d’apprentissage pervasif est de fournir aux apprenants la bonne ressource au bon moment et de la meilleur façon Dans ce processus, le profil apprenant est un des critères fondamentaux Il existe de nombreux modèles de profil ainsi que de technologies et d’architectures de gestion de modèle du profil Mais toutes les propositions qui ont fait leurs preuves sont des solutions centralisées La gestion des profils dans les systèmes distribués est encore un point étudier, surtout dans un environnement ubiquitaire Dans ce problème, deux questions se posent Comment représenter le profil apprenant ? Et quelle architecture choisir pour gérer le profil apprenant dans un environnement ubiquitaire ? Actuellement, chaque personne peut être membre de plusieurs services sur internet Normalement, ces services demandent l’utilisateur de déclarer certaines informations personnelles quand ils s’inscrivent Un utilisateur a donc plusieurs fragments du profil sur internet Un problème posé est que comment peut-on gérer ces fragments de façon efficace, et ensuite les réutiliser facilement Une des premières difficultés de ce problème est que la plupart des services internet actuels ne partage pas leurs données avec les autres services Par conséquent, chaque fois que l’utilisateur veut s’inscrire un nouveau service, il faut qu’il redéclarer ses informations Par ailleurs, certains services ont besoin de connaitre un certains nombre d’informations sur l’utilisateur pour lui proposer des services, mais le stockage n’est pas efficace (par exemple : les données stockées sont trop grandes, mais la fréquence d’utilisation est trop petite) Dans ce cas, la capacité d’importation partir des ressources extérieures est une alternative très importante Par exemple, un service de recommandation d’un grand musée (ex: musée du Louvre) a pour but de donner des informations convenables d’un objet aux clients en se basant sur les connaissances de celui-ci Néanmoins, une demande de déclaration d’informations de chaque client n’est pas une bonne idée De plus, il est sans aucun doute inefficace de stocker des informations sur des clients qui peut-être visitent le musée une seul fois (par exemple : les touristes) Par conséquent, il est nécessaire de construire un système qui récupère et gère efficacement des fragments de profil de l’utilisateur afin de permettre leur partage ou/et réutilisation Dans le contexte du projet SIMBAD1, le système possède un module de recommandation qui permet de recommander les ressources convenables l’apprenant en se basant sur son profil Ainsi, le système de gestion de profil comme mentionné ci-dessus lui serait une source utile Nous pouvons d’illustrer le fonctionnement de notre proposition par le scénario suivant : • Etape : Un service de recommandation souhaite récupérer le profil de l’utilisateur afin de lui proposer un service • Etape : L’utilisateur lui donne son identité dans le système de gestion de profil • Etape : Le service de recommandation se connecte au système de gestion de profil et demande le profil correspondant cette identité SIMBAD (Semantic Interoperability for Mobile collaborative and ADaptive application) est un projet de l'INT qui s'intéresse la description et la composition de ressources pédagogiques et de workflows • Etape : Le système de gestion de profil se basera sur les paramètres configurés par l’utilisateur pour générer le profil, et ensuite, le renvoie au service de recommandation 1.2 Objectif du stage Ce stage a pour objectif l’étude et la mise en place d’un gestionnaire de profil apprenant dans un environnement ubiquitaire Les travaux réaliser dans ce stage sont les suivants : • Analyse des modèles existants pour la structuration des données apprenant • Proposition d’un modèle pour la gestion des profils apprenants dans un contexte mobile • Définition d’une architecture pour l’intégration et la gestion du profil apprenant dans un environnement ubiquitaire • Développement d’un système de gestion de profils basé sur le modèle et l’architecture proposés pour un dispositif mobile • Développement d’une interface permettant d’intégrer ce système de gestion de profil au module de recommandation de ressources pédagogiques du système d’apprentissage ubiquitaire 1.3 Environnement de travail TELECOM & Management SudParis, appelé auparavant Institut National des Télécommunications (INT), est un établissement public d’enseignement supérieur et de recherche Il rassemble deux grandes écoles sur son campus francilien : l’école de management Télécom Ecole de Management (INT Management) et l’école d’ingénieurs Télécom SudParis (TELECOM INT), un centre de formation continue et un pôle de recherche en Science et Technologies de l’Information et de la Communication (STIC) et en management Les travaux de recherche qui sont présentés dans ce rapport ont été menés au sein de l'équipe de base de données, du département Informatique (INF) - un des neuf 10 On sélectionne des régions dans l'arbre DOM qui sont susceptibles de représenter des informations dont on a besoin Des régions sont sélectionnées en comparant la distance éditée [15] entres les nœuds de l'arbre DOM : plus la distance éditée est petite, plus les deux nœuds font partie d'une même région Pour extraire des régions, on définit des termes sur l'arbre DOM : • Un nœud généralisé [14] de longueur n est un ensemble des nœuds qui contient n nœuds dans DOM qui satisfont les conditions : o Les nœuds ont le même nœud parent o Les nœuds sont adjacents • Une région de données est une collection d’au moins deux nœuds généralisés qui satisfont des conditions : o Les nœuds généralisés ont le même nœud parent o Les nœuds généralisés ont la même longueur o Les nœuds généralisés sont adjacents o La distance éditée normalisée entre eux est inférieur un seuil sélectionné • La distance éditée mesure la distance entre deux strings Elle est déterminée par le nombre de points de mutation nécessaire pour changer une chaîne de caractère en une autre chaîne de caractère Le point de mutation est un des cas suivants: o Changement d'une lettre o Ajout d'une lettre o Suppression d'une lettre Ainsi, les étapes pour déterminer les régions d’informations sont les suivantes (figure 21) : • Trouver tous les nœuds généralisés de l'arbre • Pour chaque nœud de l'arbre qui a au moins un nœud généralisé On collecte tous les nœuds généralisés comme un ensemble 61 • On calcule toutes les combinaisons (chaque combinaison a au moins deux éléments) possibles de l'ensemble ci-dessus • On calcule toutes les distances éditées entre les pairs de nœuds généralisés dans chaque combinaison • Si toutes les distances éditées d'une combinaison sont inférieures au seuil, on considère cette combinaison comme étant une région d’informations • Dans le cas où une région contient une autre région, on ne considère que la région la plus grande Figure 21: Exemple des régions dans l'arbre DOM Extraction des informations On extraie des enregistrements de données partir des régions obtenues dans l'étape précédente Les régions contiennent des nœuds généralisés, on considère alors les nœuds généralisés de chaque région : • Dans le cas où chaque nœud généralisé a un seul nœud de tag : o Si tous les fils du nœud sont similaires et ce nœud n'est pas une ligne d'un tableau, chaque fils du nœud devient un enregistrement de données o Sinon, ce nœud devient un enregistrement de données 62 • Dans le cas où chaque nœud généralisé a plusieurs nœuds de tag : o Si tous les fils de chaque nœud de tag sont similaires et chaque nœud de tag a le même nombre de fils, ces fils sont des descriptions d’objets non continus Un objet non continu est représenté par un tableau (figure 23) : une ligne représente le nom des attributs de l'objet, puis une ligne représente la valeur (ou description) de l'attribut correspondant o Sinon, ce nœud devient un enregistrement de données Figure 22: Exemple d'un objet normal Figure 23: Exemple d'un objet non-continue Après ces étapes, on obtient les informations nécessaires représentées sous forme d’objets avec leurs attributs 4.3.2 API de fournisseur Certains fournisseurs fournissent une API (Application Programming Interface) pour permettre aux développeurs de créer des applications extérieurs qui peuvent intégrer les services du fournisseur Lorsqu’elles existent, ces API sont des moyens efficaces pour accéder au système intérieur du service Elles peuvent être utilisées pour retirer des fragments du profil du fournisseur Dans la version démo du système, j’ai utilisé les API de Facebook et Google 63 4.3.3 Discussion Comme énoncé dans la section précédente, les API sont le meilleur moyen pour accéder et retirer des données partir des fournisseurs Elles permettent de garantir la stabilité et l’efficacité Néanmoins, s’il n’existe pas d’API officielle du fournisseur, alors une API de la troisième partie est une bonne alternative Facebook est un exemple pour ce cas Depuis mai 2008, Facebook n’a plus supporté d’API Java, toutefois il est un service très connu, et il existe beaucoup d’applications Facebook développées en Java, donc il y a plusieurs projets source ouverts continuant la maintenant de l’API qui permet de développer des applications Facebook en Java Cependant, dans le cas où il n’existe ni API officielle ni API troisième partie, alors la méthode parsing web est recommandée Actuellement, Linkedin est un réseau professionnel en ligne ayant plus de 45 millions de membres issus de 170 secteurs d'activités dans plus de 200 pays Il est donc un grand fournisseur profil, malheureusement, son API n’est pas encore publique Seuls quelques développeurs peuvent utiliser cette API avec l’acception de l’équipe Linkedin Alors, dans la version démo, j’ai choisit Linkedin pour appliquer la méthode parsing web Il existe certaines techniques de parsing d’une page de site web, mais j’ai choisit la technologie basée sur la structure de la page HTML (comme description dans la section 4.3.1) en raison de sa simplicité Néanmoins, la fonction de la méthode dépend de la structure de page Elle ne sera pas efficace sur des pages web changeant souvent ses interfaces Cela constitue l’inconvénient principal de la méthode En conclusion, chaque méthode a des avantages et des inconvénients individuels Les conditions spécifiques l’application permettront de choisir la méthode appropriée 4.4 Intégration de schémas et de données Le processus d’intégration des fragments de profil pose beaucoup de problèmes résoudre : information ambigu, manipulation ambigu, information incertaine, mapping de schéma et d’ontologie, données inconsistantes, médiation, données de disséminations, réplications de données, détection et réconciliation de confit Les techniques et 64 architectures pour résoudre ces problèmes appartiennent plusieurs domaines de recherches – tels que les systèmes informatiques mobiles, les technologies web sémantique, les bases de données, etc Dans le cadre de ce stage, nous nous intéressons seulement deux problèmes : mapping de schéma et mapping de données Mapping de données Dans notre système, l’utilisateur a un rôle fondamental Le résultat final étant son profil complet comme il le souhaite Alors, les dernières décisions appartiennent l’utilisateur Le profil de l’utilisateur est fragmenté et maintenu par plusieurs fournisseurs indépendants de profil Par conséquent, la redondance des données est inévitable C’est la raison du problème de données conflictuelles C’est-à-dire qu’une information peut avoir plus de deux valeurs Notre solution de base sur la priorité L’utilisateur indique la priorité pour chacun de ses fournisseurs Plus précisément (s’il le souhaite), il peut préciser la priorité pour chaque catégorie et/ou chaque information Et la caractéristique de priorité est héritable C’est-à-dire que si une information de sous catégorie n’indique pas la priorité, celle-ci va se voir assigner la valeur de la priorité de la catégorie-père Quand un conflit a lieu, le système se base sur la priorité pour déterminer quelle information reste et quelle information est effacée Mapping schéma Du côté du service consommant le profil, il va faire le mapping de schéma lui-même Ce fait n’est pas difficile, puisque notre schéma et sa description sont ouverts Le service consommateur peut se baser sur leurs attributs pour construire la liste des informations désirées Précisément, pour chaque information, il indique son nom d’attribut et le chemin correspondant, par exemple : hasAddress = User.hasProfile.hasIdentification hasGender = User.hasProfile.hasIdentification.hasDemograhic 65 Du côté du fournisseur de profil, dans la version actuelle, nous réalisons le mapping de schéma la main Mais dans les versions futures, nous prévoyons d’ajouter un mécanisme semi-automatique de mapping de schéma en se basant sur un service mapping de troisième partie 66 4.5 Prototype Dans cette section, nous illustrons certaines interfaces de l’application que nous avons développée Cette application est une implémentation de la proposition énoncée dans la section 3.2 pour réaliser le scénario de la section 3.3 Figure 24 : Quelques interfaces du dispositif mobile La figure 24 montre diverses interfaces du dispositif mobile correspondant aux processus : authentification, choix des fournisseurs pour mettre jour les informations dans étape de prétraitement, confirmation des informations partageables 67 Figure 25: Les messages échangés dans le processus de mise jour La figure 25 montre les messages échangés entre les agents dans le processus de mise jour (et dans l’étape de prétraitement) Les agents (de gauche droite) sont : l’agent système, l’agent gestionnaire de service, l’agent gestionnaire de fournisseur, l’agent mobile (l’utilisateur « ntbinh ») et deux agents fournisseur pour Facebook et Linkedin Ces messages sont une visualisation de la description de l’étape de prétraitement énoncée dans la section 3.3 Figure 26: Les messages échangés dans le processus de traitement d’une demande Les messages dans la figure 26 sont une description visualisée des messages échangés dans le processus de traitement d’une demande énoncé dans la section 3.3 La liste des agents (de gauche droite) est : l’agent système, l’agent gestionnaire de service, l’agent gestionnaire de fournisseur, l’agent mobile (de l’utilisateur « ntbinh »), l’agent de 68 service, l’agent de fournisseur pour google (fournisseur du calendrier de l’utilisateur ntbinh) et l’agent du service extérieur Figure 27: Résultat sur service extérieur La figure 27 montre le résultat (le profil de l’utilisateur ntbinh : nom, intérêts, adresse, éducation, calendrier, etc.) dans l’écran du service extérieur Ici, le résultat est représenté sous une forme très simple directement sur la console Il est bien entendu que l’agent de service extérieur peut représenter le résultat sous une autre forme s’il le souhaite 69 Conclusion et perspectives 5.1 Conclusion Le profil apprenant a un rôle important pour la recommandation dans le domaine de l’apprentissage pervasif Toutefois, la gestion de profil apprenant distribué dans un environnement ubiquitaire pose plusieurs problèmes résoudre Ce stage vise mettre en place un gestionnaire de profil apprenant dans un environnement ubiquitaire Précisément, les travaux demandés dans ce stage sont: (1) faire une étude bibliographique sur les normes de modèle utilisateur et ses représentations ainsi que les techniques applicables (2) proposer un modèle de profil apprenant convenable et une architecture permettant de gérer efficacement ce modèle de profil ; (3) mettre en œuvre un système en se basant sur le modèle et l’architecture proposés sur un dispositif mobile et faire une intégration de ce système au module de recommandation de ressources pédagogiques du système d’apprentissage ubiquitaire En fait, après une étude sur les normes de modèle de profil, on s’est aperçu que ces normes (par exemple IMS LIP, PAPI, FOAF, etc.) sont de bonnes façons de décrire un profile apprenant Mais elles ont encore plusieurs limitations quand on les applique l’environnement ubiquitaire Nous avons alors proposé un modèle apprenant qui hérite de tous les avantages des normes existantes et ajoute les manquements nécessaires pour l’environnement ubiquitaire Une étude sur les avantages et inconvénients des modèles de gestion profil ainsi que les techniques applicables a permis de guider notre choix Le modèle de gestion choisi est une fusion du modèle centralisé et décentralisé Les informations sensibles sont gérées dans un modèle décentralisé et le modèle centralisé s’applique aux informations assez stables qui ne changent pas souvent Du point de vue de la mise en ouvre, la technologie multi-agents est choisie en raison de ses avantages sur les applications reparties mobiles Le résultat obtenu est un système permettant de retirer des fragments de profil partir des fournisseurs, de gérer et partager des profils aux services extérieurs Un prototype a été fournit afin d’intégrer le système au module de 70 recommandation de ressources pédagogiques Mes travaux sont validés et publiés dans un workshop de la conférence ECTEL09 [23] 5.2 Perspectives Le système réalisé a encore plusieurs limitations Nous proposons dans ce qui suit quelques idées d’amélioration possibles: Une étude sur le mécanisme de mapping automatique (ou semi-automatique) du côté des services fournisseur est envisagée Ceci afin d’augmenter la capacité d’ajouter dynamiquement des fournisseurs au système A l’heure actuelle, l’information contextuelle du système est limitée au dispositif utilisé par utilisateur Une étude sur la collection et gestion du contexte plus riche est très utile pour les services recommandation De plus, une interface conviviale et le support OpenID2 constituent des évolutions utiles du système OpenID est un système d’authentification décentralisé qui permet l’authentification unique [22] 71 Bibliographie [1] Wahlster W et Kobsa A.,Dialogue-based user models In Proceedings of IEEE, Vol 74(7), pp 948-960, 1986 [2] Wilson, S., Jones, P.R.: What Is…IMS Learner Information Packaging? In standards briefings series, c.JISC, Editor (2002) [3] Jameson A., User Adaptive Systems An integrated Overview Tutorial presented at the 7th International Conference on User Modeling, June 20-24, 1999 [4] MS Consortium: http://www.imsproject.org [5] PAPI (2000) Public and Private Information; IEEE 2000, Draft Standard for Learning Technology - Public and Private Information (PAPI) for Learner, IEEE P1484.2/D6, 2000 http://ltsc.ieee.org/ [6] Dumbill, E.: XML Watch: Finding friends with XML and RDF: The Friend-of-aFriend vocabulary can make it easier to manage online communities (2002) [7] Brickley, D., Miller L.: FOAF Vocabulary Specification -Namespace Document 27 July 2005 - ('Pages about Things' Edition) (2005) [8] Tomaz Klobucar, Vanja Senicar, Borka Jerman Blazic(2004), Privacy Issues of a Smart Space for Learning, In: Proceedings of ICALT 2004 (The 4th IEEE International Conference on Advanced Learning Technologies) [9] W Nejdl, B Wolf, Ch Qu, S Decker, M Sintek, A Naeve, M Nilsson, M Palmr and T Risch (2001) EDUTELLA: A P2P Networking Infrastructure Based on RDF, Edutella White Paper, http://edutella.jxta.org/reports/edutella-whitepaper.pdf [10] George McDaniel IBM Dictionary of Computing, Tenth Edition, McGraw-Hill, (1993) [11] M Wooldridge and N.R Jennings Inteliigent Agents: Theory and Practice The Knowledge Engineering Review, 10 (2), pages 115-152, 1995 [12] K.P Sycara Multi-agent Systems AI Magazine, vol 10, n°2, pages 79-93, 1998 72 [13] S.A O’Malley and S.A DeLoach Determining When to Use an Agent Oriented Software Engineering Paradigm Proceedings of the Second International Workshop On Agent-Oriented Software Engineering (AOSE 2001), Montreal, Canada, May 29th 2001 [14] JADE, JADE tutorial http://jade.tilab.com [15] L Yi, B Lui and X Li Eliminating Noisy Information in Web Pages for Data Mining [16] B Lui, R Grossman and Y Zhai Mining Data Records in Web Pages Proceedings of the ACM SIGKDD International Conference on Knowledge Discovery & Data Mining (KDD2003), Washington, DC, USA, August 24 27, 2003 [17] M Bouzeghoub and D Kostadinov Personnalisation de l'information : aperçu de l'état de l'art et définition d'un modèle flexible de profils In CORIA, pages 201-218, 2005 [18] Voyager – Voyager by Object Space www.objectspace.com/products/voyager1.htm [19] Aglets Workbench – laboratoire IBM Tokyo Research Laboratory – open source http://www.trl.ibm.com/aglets/ [20] Light Extensible Agent Platform – LEAPJADE, http://jade.tilab.com/ [21] Wofgang Nejdl, Mario Schlosser, Wolf Siberski, Martin Wolpers, Bernd Simon, Stefan Decker, Michael Sintek, RDF-based Peer-to-Peer-Networks for Distributed (Learning) Repositories 17th IFIP World Computer Congress, Intelligent Information Processing / IIP-2002 [22] OpenID – Wikipédia - http://fr.wikipedia.org/wiki/OpenID [23] Nguyen Thanh Binh, Anis Chouchane, Amel Bouzeghoub, An agent-based architecture for user profile sparseness, Workshop ECTEL 09, Future Learning Landscapes, Nice, 2009 73 Annexe A Les messages Message : requête de connexion • Départ de l’agent mobile vers l’agent système • Performative : INFORM • Conversation ID : auto-génération • Contenu : texte (username + password) Message : la réponse de la connexion • Départ de l’agent système vers l’agent mobile • Performative : INFORM • Conversation ID : auto-génération • Contenu : texte (ok/no) Message : la demande d’un profil • Départ de l’agent du service extérieur vers l’agent gestionnaire de service • Performative : REQUEST • Conversation ID : auto-génération • Contenu : texte (UID + liste des attributs) Message : la demande d’une mise jour profil • Départ de l’agent mobile vers l’agent système • Performative : REQUEST • Conversation ID : auto-génération • Contenu : texte (« updateProvider » + UID + liste de fournisseur) Message : demande de destruction • Départ de l’agent service vers l’agent gestionnaire de service • Performative : INFORM • Conversation ID : auto-génération 74 • Contenu : texte (kill-me) Message : demande de destruction • Départ de l’agent fournisseur vers l’agent gestionnaire de fournisseur • Performative : INFORM • Conversation ID : auto-génération • Contenu : texte (kill-me) Message : confirmation de la liste des informations demandées • Départ de l’agent système vers l’agent mobile • Performative : REQUEST • Conversation ID : auto-génération • Contenu : texte (nom du service + liste de couples (attribut;chemin)) Message : requête de demande de fragment de profil • Départ de l’agent système vers l’agent gestionnaire de fournisseur • Performative : REQUEST • Conversation ID : auto-génération • Contenu : instance de la classe VectorSerial (UID, liste de compte) Message : résultat de la requête de demande de fragment de profil • Départ de l’agent fournisseur vers l’agent système • Performative : INFORM • Conversation ID : auto-génération • Contenu : instance de la classe Infor2 Message 10 : résultat du profil (en réponse au message 3) • Départ de l’agent système vers l’agent service • Performative : INFORM • Conversation ID : auto-génération • Contenu : instance de la classe Infor1 75 [...]... possibilitộ de dộcrire son identitộ Un profil apprenant (ou un modốle apprenant) est un profil utilisateur qui dộcrit un apprenant Ce profil contient non seulement les informations gộnộrales mais aussi les informations concernant des caractộristiques et des activitộs dapprenant comme : le but, la transcription, les compộtences, les qualifications, les certifications, etc Alors, avec un profil dun apprenant, ... de lactivitộ Lộvaluation de lactivitộ (ex: par un examen, etc.) Les produits crộộs dans le cadre de lactivitộ Description de lactivitộ Description des compộtences Type de lintộrờt Description de lintộrờt Type de laffiliation Le rụle entrepris par lapprenant L'organisation laquelle l 'apprenant est affiliộ Date de laffiliation Lộtat de laffiliation Description de laffiliation Description du duplicata... (Sujet, Prộdicat, Objet) RDF permet dassocier une ressource un ensemble de triplets dont la sộmantique nest pas dộfinie La sộmantique de ces relations nest dộfinie que par un Schộma RDF (RDFS) ou une ontologie 2.4 Architecture des systốmes de gestion du profil Dans un systốme de gestion du profil, on sintộresse deux problốmes principaux : le modốle de gestion du systốme et la technique convenable... permet de dộfinir des propriộtộs internes aux classes 2.3.3 RDF RDF (Resource Description Framework) est un langage de description de mộtadonnộes et/ou dannotations au niveau sộmantique qui permet dộchanger et de traiter ces mộtadonnộes par des opộrations humaines ou artificielles RDF proc de par une description de connaissances laide dexpressions de structure fixộe sous la forme des collections de triplets... seulement des protocoles et des fonctions pour chaque agent, sans avoir besoin de faire attention la communication entre ces agents 30 3 Proposition dun modốle dapprenant distribuộ dans un contexte ubiquitaire Dans cette partie, notre objectif est de dộcrire une proposition du modốle apprenant et une architecture du systốme permettant de le gộrer Nous prộsentons tout dabord les descriptions du modốle apprenant. .. dontologie Person Le deuxiốme fait permet de crộer une autre instance profile1 de la classe Profile et de relier ensuite linstance user1 profile1 par la propriộtộ hasProfile Pour rechercher les instances de la classe Person ayant un profil, la requờte est sộcrit comme suit: FORALL U,P,N,M N#P:N#Profile]@M U,P,N et M sont des variables chercher U est une instance de la classe... Compte IM en ligne de lapprenant Description Sexe de lapprenant Date de naissance Lieu de naissance Le nombre identitộ de lapprenant (ex: sur carte identitộ, passeport) La particularitộ de lapprenant (ex: sur visage) Description Type de CPU du dispositif La taille du mộmoire 34 Display InputMethod Network Camera Battery Catộgorie Software Informations sur lộcran du dispositif La mộthode dentrộe du dispositif... types de rộseau supportộs La fonction dappareil photo Description de lalimentation Sous-Catộgorie Name Vendor Version Description Le nom du logiciel Le vendeur du logiciel La version du logiciel 3.2 Description de lapproche 3.2.1 Modốle de gestion de profil Un profil apprenant contient plusieurs informations Chaque type dinformation a des caractộristiques diffộrentes Alors, pour simplifier la gestion, une... dans lapplication REST Les Services Web WS-* reposent sur un ensemble de protocoles et de standards de base utilisộs pour lộchange de donnộes entre application dans des environnements hộtộrogốnes : 28 Le protocole SOAP (Simple Object Access Protocol) pour lộchange de messages Le fichier WSDL (Web Service Description Language) pour la description des messages utilisộs, de leurs types de donnộes, de. .. HTTPS (les protocoles Web de base) soient simples, ils ne sont pas vraiment destinộs des sessions longues Typiquement, un navigateur fait une connexion HTTP, demande une page Web, puis se dộconnecte Dans un environnement typique CORBA ou RMI, un client se connecte au serveur et peut rester connectộ pendant une pộriode de temps prolongộe Le serveur peut pộriodiquement envoyer des donnộes vers le client