GESTION DE PROFIL APPRENANT DISTRIBUE DANS UN ENVIRONNEMENT UBIQUITAIRE

1 Institut de la Francophonie Telecom & Management MEMOIRE DE STAGE DE FIN D’ETUDES MASTER EN INFORMATIQUE GESTION DE PROFIL APPRENANT DISTRIBUE DANS UN ENVIRONNEMENT UBIQUITAIRE Re

1

Institut de la Francophonie Telecom & Management

MEMOIRE DE STAGE DE FIN D’ETUDES

MASTER EN INFORMATIQUE

GESTION DE PROFIL APPRENANT DISTRIBUE DANS UN ENVIRONNEMENT UBIQUITAIRE

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 – Aỏt, 2009

2

Remerciements

Je tiens particulièrement à remercier professeur Amel BOUZEGHOUB, mon responsable de stage, pour l’encadrement, l’aide, les conseils précieux pendant 5 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

3

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

4

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,

Multi-agent systems, mobile, semantic web

5

Table des matières

1 Introduction 8

1.1 Problématique 8

1.2 Objectif du stage 10

1.3 Environnement de travail 10

1.4 Organisation du mémoire 11

2 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

3 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

4 Réalisation 44

6

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

5 Conclusion et perspectives 70

5.1 Conclusion 70

5.2 Perspectives 71

Bibliographie 72

Annexe 74

A Les messages 74

7

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

"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

9

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 1 : Un service de recommandation souhaite récupérer le profil de l’utilisateur afin de lui proposer un service

• Etape 2 : L’utilisateur lui donne son identité dans le système de gestion de profil

• Etape 3 : Le service de recommandation se connecte au système de gestion de profil et demande le profil correspondant à cette identité

1 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

10

• Etape 4 : 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

11

départements de l'INT, situé à Evry, France Le département INF assure la compétence dans le domaine général de l’informatique, et plus particulièrement dans les secteurs des bases de données, du parallélisme et des systèmes distribués Ces activités s’exercent dans tous les domaines d’activité de l’institution : formation initiale, mastères spécialisés, masters of sciences « Computer ans Communication Networks » et « Information Technologies), formation continue et recherche Sur ce dernier point, le département est structuré en quatre projets structurants (G2, MARGE, PFTCRE et SIMBAD) et participe

à l’Unité Mixte de Recherche CNRS “Samovar”, par le biais de l’équipe ACMES (qui regroupe MARGE et SIMBAD) dans le domaine des systèmes adaptatifs au contexte, avec une orientation vers la prise en compte de la mobilité Pour mener à bien ses activités, le département fait appel aux compétences d’une équipe composée de 19 enseignants-chercheurs, d’un ingénieur de recherche, d’une personne chargée de gestion, ainsi que de 17 doctorants

1.4 Organisation du mémoire

Ce mémoire vise à rapporter ce que j’ai fait pendant mon stage au sein de l'équipe de base de données du département INF sous la direction du professeur Amel BOUZEGHOUB

Le mémoire est divisé en cinq parties:

• La première partie est consacrée à l’introduction du sujet de stage

• La deuxième partie présente l‘étude bibliographique que j’ai fait comprenant les définitions, les modèles apprenant ainsi que les langages permettant de les représenter, et les architectures existantes dans les systèmes de gestion du profil

• Dans la troisième partie, après avoir explicité quelques modèles de référence issus

de la bibliographie, nous présentons notre proposition : un modèle apprenant adapté à l’apprentissage mobile et une architecture permettant de gérer efficacement des profils apprenant distribués

• La mise en œuvre de notre proposition est abordée dans la partie réalisation

• La dernière partie contient les conclusions et discussions sur le travail réalisé

12

• Le rapport se termine avec les références et l’annexe ó sont listés les liens vers les documents consultés au cours de mon travail et des informations additionnelles concernant la programmation

Un environnement ubiquitaire est un fonctionnement de la communication ó les

objets communicants se reconnaissent et se localisent automatiquement entre eux Les objets interagissent entre eux sans action particulière de l’utilisateur Autrement dit, l'on peut être connecté partout et tout le temps L'environnement ubiquitaire numérique sous-entend la notion de pro-activité, c'est-à-dire que des processus peuvent envoyer de l'information à ces terminaux à cœur numérique et en obtenir sans action d'un utilisateur

Un profil utilisateur (ou encore un modèle utilisateur) est une collection de données

personnelles associées à un utilisateur spécifique Un profil se réfère donc à la représentation numérique explicite de l’identité d’une personne

Selon Wahlster et al [1], un modèle utilisateur est une source de connaissance qui contient des acquisitions sur tous les aspects de l'utilisateur qui peuvent être utiles pour le comportement du système

Le profil utilisateur peut contenir non seulement les informations d'identification de base mais aussi regrouper des informations très diverses selon les besoins Parmi celles-ci [3] :

• Des caractéristiques personnelles pouvant influencer fortement l'interaction (âge, sexe, etc.)

• Les intérêts et les préférences générales relatives à la tâche à accomplir, qui permettent une adaptation aux attentes de l'utilisateur

• Les compétences ou le niveau d’expertise relative à la tâche (pour déterminer par exemple un degré d'autonomie et déceler un besoin d'aide ou de formation)

• Le but courant de l'utilisateur

Sur les sites web, le profil d’un utilisateur est souvent un curriculum vitae court de même, avec (ou non) une photo et ses informations statistique Mais dans les services de

lui-14

réseaux sociaux en ligne tels que Facebook, Google profile, Linkedin… un profil peut être compliqué puisque l’utilisateur a la 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 d’apprenant comme : le but,

la transcription, les compétences, les qualifications, les certifications, etc Alors, avec un profil d’un apprenant, on peut répondre à des questions comme celles cités ci-dessous:

• Quelles sont ses caractéristiques générales ?

• Quelle est son expérience d’apprentissage?

• Quelle est sa motivation ?

2.2.1 Standards et modèles de données du profil existants

Nous allons étudier dans la suite les différents standards existants permettant de modéliser les données du profil

2.2.1.1 IMS LIP

IMS LIP (learner information package specification)[4] est une spécification

décrivant une approche classique de CV structuré [2] Elle se focalise sur l’historique de

l’apprenant et de son expérience d’apprentissage Le but de ce standard est de faciliter l'échange des informations sur les apprenants entre systèmes éducatifs, systèmes de gestion d'apprentissage, etc

15

Figure 1: Eléments d’IMS LIP

IMS LIP est structurée en onze catégories de base :

• L’Identification décrit les données démographiques et biographiques sur

l’apprenant, (e.g : nom, âge, adresse, email, etc.)

• Le But : définit l’objectif de la tâche d’apprentissage, l'attente de carrière et

d'autres objectifs

• Qualifications, Certifications & Licences (QCL) décrit l’ensemble des

diplômes de l’apprenant

• L’Activité décrit toute activité liée à l'apprentissage dans n'importe quel état

d’exécution (exemples : formation, expérience professionnelle, etc.)

• Les Intérêts maintient toutes les informations décrivant les hobbies de

l’apprenant et les activités récréatives

• Compétences : décrit les compétences, l'expérience et les connaissances

acquises

• Transcription: Un dossier qui est utilisé pour fournir un résumé sur des

résultats scolaires

• Sécurité: L'ensemble des mots de passe et clés de sécurité affectés à

l'apprenant

• Relation : L'ensemble des relations entre les éléments de base Les structures de

base n'ont pas en leur sein des identifiants qui les relient avec les structures de base Toutes ces relations sont donc saisies dans une seule structure de base, ce qui rend les liaisons simples à identifier et à gérer

2.2.1.2 PAPI Learner

PAPI Learner (Public and private information)[5] est un standard proposé par le

groupe Learner Model Working Group de l'IEEE, qui décrit les informations sur l’apprenant utiles pour la communication entre les systèmes coopératifs

Figure 2: Eléments de PAPI

PAPI décompose le profil en six catégories :

• Informations personnelles contient des informations générales sur l'étudiant,

par exemple nom, adresse, etc

• Relations contient des relations apprenant avec d'autres personnes, par exemple

camarade, professeur, etc

17

• Sécurité occupe des fonctions de sécurité des apprenants et des droits d'accès,

par exemple clés publiques et privées

• Préférences occupe l'information publique sur les préférences de l'apprenant,

par exemple les styles d'apprentissage ou la langue

• Performances détient le record de la performance de l'apprenant, qui peut être

utilisée pour une évaluation ou d'identification des expériences, par exemple les notes d’apprentissage, les rapports, ou la certification, etc

• Portfolio décrit les travaux et les projets de l’apprenant Il a pour but d’accéder

à son histoire et son expérience précédente

2.2.1.3 FOAF

FOAF (Friend Of A Friend) est un vocabulaire basé sur RDF, défini dans le cadre

d’un projet open source, permettant de décrire des personnes et les relations qu'elles entretiennent entre elles [6] Il a été développé pour la construction de groupes sociaux

[7] FOAF distingue 5 catégories pour décrire un profil : FOAF Basics de base comprend une description de base telle que nom, adresse e-mail, images Personal Information

décrit plus d'informations personnelles telles que le blog, les intérêts, les publications et

les relations aux autres profils qui connaissent cette personne Online Accounts décrit les informations sur les comptes qu’une personne possède Projets and Groups définit les

informations sur les projets, les groupes ou les organisations dans lesquelles la personne

est membre Documents and Images décrit les documents et les images relatives à

l’apprenant, par exemple: document de profil, logo…

2.2.2 Catégories du modèle apprenant

Après avoir analysé la structure générale des modèles existants, on peut créer une taxonomie des caractéristiques possibles pouvant décrire un apprenant Cette taxonomie est classifiée en huit catégories, dont chacune est divisée en sous catégories Elle est générale et capture les types d’information modélisés dans les standards existants, plutôt que de définir un ensemble canonique de caractéristiques

• Données personnelles (Personal data)

18

o Identification : métadonnées identifiant uniquement une personne dans

le contexte du système, par exemple: nom, adresse, email, etc

o Description : s’occupe plus de détails de la personne, par exemple : page d’accueil, URL, images, etc

• Relations : les informations concernant les relations de l’apprenant avec d’autres personnes dans l’environnement d’apprentissage

o Informel : décrit les associations générales entre les personnes et les groupes, par exemple : les camarades, les enseignants, etc

o Formel : décrit les relations avec le profil d’autre apprenant ou d’autres documents

• But (Goal) : décrit les objectifs et les sous objectifs de l’apprenant

• Réalisations et historique de l’apprenant (Achievements and Learner history)

o Performances : les records de la performance apprenant pour une évaluation ou identification des expériences, par exemple les notes obtenues, les rapports, etc

o Certification: toutes qualifications, certificats ou licences

o Compétence: toutes les compétences ou capacités que l’apprenant peut avoir

o Portfolio: les travaux et les projets de l’apprenant, utilisés pour accéder

à l'histoire de l'apprenant et de l'expérience précédente

o Transcription: un résumé des résultats scolaires qui est stocké souvent sous la forme d’un fichier

o Activité: contient toutes les activités d'apprentissage

• Accessibilité et préférences

o Langue: les préférences linguistiques (parlé et écrit)

o Styles d'apprentissage: mode d'apprentissage de l'apprenant

o Éligibilité: spécifie toute l'admissibilité de l'apprenant

o Incapacité: spécifie toute incapacité de l'apprenant

2.2.3 Comparaison des standards

La figure 3 ci-dessous représente un tableau de comparaison entre les modèles apprenants présentés dans la section 2.2.1 Dans ce tableau, j’ai simplifié la représentation de la taxonomie Je ne présente que les grandes catégories et leur sous catégories pour mettre en évidence leur différences

Notation utilisée dans le tableau :

+ : support total, p : support partiel, e : capacité à être étendu,

et un standard qui est utilisé dans la plupart des systèmes d’apprentissage actuels

FOAF n’a pas été conçu pour les systèmes d’éducation, contrairement à IMS LIP et PAPI Toutefois, FOAF possède l’avantage de prendre en compte tous les types de relations entre les profils Parmi les normes citées précédemment, FOAF est le seul modèle qui décrit les relations entre les apprenants par l’élément « knows » Bien que PAPI stocke les relations avec les autres apprenants et les enseignants, ces relations sont développées principalement pour les systèmes de gestion d’apprentissage pour trouver d’autres membres du groupe d’apprentissage Donc, ce modèle sert à construire les

un environnement ubiquitaire, surtout dans l’apprentissage mobile

Par conséquent, un modèle apprenant attendu qui peut être adapté à l’apprentissage mobile doit non seulement avoir tous les avantages des normes ci-dessus mais aussi l’ajout de contexte courant

Après avoir étudié quelques modèles apprenant, nous abordons dans l’étape suivante, l’étude des langages permettant de les représenter

2.3 Langages de représentation de modèle apprenant

Il existe plusieurs langages permettant de représenter des modèles apprenant Dans cette partie, on n’aborde que les langages les plus utilisés : F-Logic, OWL et RDF

2.3.1 F-Logic

Frame logique (F-Logic) est un langage déductif de base de données orientée objet qui combine la sémantique déductive et l’expressivité des langages de base de données déductive avec la richesse de modélisation des modèles de données orientés objet

La représentation d’ontologie en F-Logic est très flexible et peut exprimer n’importe quelle relation d’une ontologie en utilisant des règles en F-logic Il est de même facile d’écrire des requêtes en F-logique et les moteurs d’inférence en F-Logic sont très puissants

La définition des ontologies à l’aide de F-logique se base sur ce schéma générique:

O : C [A -> V]

ó O : instance, C : classe, A : attribut de la classe, V : valeur d’attribut

Ce schéma désigne que l’objet O est une instance de la classe C dont l’attribut A qui a

la valeur V

22

La définition de certaines propriétés se fait à l’aide de cette syntaxe:

• Sous classe : C1 :: C2 (C1 est la sous-classe de C2)

• Instance : O : C (O est une instance de la classe C)

• Déclaration des attributs: C1[A=>>C2] (instance de la classe C1 dont l’attribut A sont des instances de la classe C2)

• Donner une valeur à un attribut : O[A->>V] (instance O dont l’attribut A a la valeur V)

L’exemple suivant illustre des faits écrits en F-Logic :

user1 : Person

user1[hasProfile->profile1:Profile]

Le premier fait crée une instance user1 de la classe d’ontologie Person Le deuxième fait permet de créer une autre instance profile1 de la classe Profile et de relier ensuite l’instance 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#U:N#Person[hasProfile -> N#P:N#Profile]@M

U,P,N et M sont des variables à chercher U est une instance de la classe Person, P est une instance de la classe Profile, N représente l’espace de nommage et M représente le module ó le serveur doit chercher

2.3.2 OWL

Web Ontology Language (OWL) est un langage XML qui profite de l’universalité syntaxique du langage XML Fondé sur la syntaxe de RDF/XML, ce langage offre un moyen d’écrire des ontologies web

Le langage OWL offre trois sous-langages d’expression croissante conçus pour des communautés de développeurs et d’utilisateurs spécifiques:

• Le langage OWL Lite concerne les utilisateurs ayant principalement besoin d’une hiérarchie de classification et de mécanismes de contraintes simples Par exemple,

ou une classe) Le langage OWL DL, conçu pour gérer le secteur existant de la logique de description, offre les propriétés de calcul souhaitées pour les systèmes

de raisonnement

• Le langage OWL Full est destiné aux utilisateurs souhaitant une expressivité maximum et la liberté syntaxique de RDF sans garantie de calcul Le langage OWL Full permet à une ontologie d’augmenter la signification du vocabulaire prédéfini (RDF ou OWL) Un système de raisonnement ne pourra probablement pas mettre en œuvre toutes les caractéristiques d’OWL Full

Eléments du langage OWL

Classe

Une classe définit un groupe d’individus possédant des caractéristiques similaires Nous présentons dans ce qui suit les différentes manières pour déclarer une classe ainsi que la notion d’héritage En effet, il existe dans toute ontologie OWL une superclasse,

nommée Thing, dont toutes les autres classes définies par l’utilisateur sont implicitement

des sous-classes Ceci nous amène directement au concept d’héritage, disponible à l’aide

de la propriété subClassOf

Individu

Outre les classes, on veut pouvoir décrire leurs instances ou individus La définition d’un individu consiste à énoncer un fait, encore appelé “axiome d’individu” Il existe deux types de faits :

24

• Les faits qui concernent l’appartenance à une classe Ce type de fait concerne généralement la déclaration de l’appartenance à une classe d’un individu et les valeurs de propriété de cet individu

• Les faits qui concernent l’identité des individus: une difficulté qui veut éventuellement apparaître dans le nommage des individus concerne la non-unicité éventuelle des noms attribués aux individus Par exemple, un même individu pourrait être désigné de plusieurs façons différentes C’est la raison pour laquelle OWL propose un mécanisme permettant de lever cette ambigüité, à l’aide des

propriétés owl:sameAs, owl:differentFrom et owl:allDifferent

Propriété

Les propriétés permettent d’exprimer les faits au sujet des classes déclarées et de leurs instances Le langage OWL fait la distinction entre deux principaux types de propriétés:

• Les propriétés d’objet qui relie des instances à d’autres instances

• Les propriétés de type de donnée qui relie des individus à des valeurs de données

Le langage OWL possède éventuellement la notion de propriétés d’annotation

(owl:AnnotationProperty) qui 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 d’annotations 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 à l’aide d’expressions de structure fixée sous la forme des collections de triplets (Sujet, Prédicat, Objet) RDF permet d’associer à une ressource

un ensemble de triplets dont la sémantique n’est pas définie La sémantique de ces relations n’est 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 s’intéresse à deux problèmes principaux : le modèle de gestion du système et la technique convenable pour le mettre en œuvre Nous présentons ces problèmes dans cette section

25

Nous traitons d'abord des caractéristiques des deux modèles possibles : centralisé et distribué Ensuite, nous étudions un certain nombre de techniques spécifiques : multi-agent et service web Et nous terminons cette section par une discussion

2.4.1 Modèle de gestion

2.4.1.1 Modèle centralisé

Le modèle centralisé a pour objectif de collecter sur un seul serveur autant d’informations possibles sur le profil de l’utilisateur Il permet d’assurer la cohérence des données de l’utilisateur afin de pouvoir les réutiliser de manière non redondante Mais il présente aussi les inconvénients suivants:

• Le serveur central (ou médiateur) peut tomber en panne en cas de surcharge de requêtes (serveur très sollicité)

• Il peut être une cible pour le piratage et un risque pour la confidentialité des données sur le profil utilisateur

• Nécessite une représentation standard des données de l’utilisateur : toutes les applications doivent partager le même schéma de métadonnées (ontologies)

• Les applications utilisent seulement un fragment des données du profil stocké sur

26

Peer-to-Peer (P2P) est un modèle typiquement distribué Les informations dans un

réseau P2P sont stockées dans plusieurs serveurs, qui seront interrogés si on connaît ce que l’on cherche et quel serveur peut fournir l’information L’interrogation des pairs nécessite des métadonnées décrivant les ressources gérées par ses pairs [21]

Dans un système ou une application P2P, il n’y a pas besoin de contrôle central ou d’organisation hiérarchique Voici les caractéristiques d’une application P2P :

• Autonomie : chaque pair est vu comme un serveur indépendant qui gère son accès aux différents services et applications

• Dynamique : des pairs peuvent être ajoutés ou supprimés à n’importe quel moment

• Décentralisé : l’ensemble des pairs peut réaliser un objectif indépendamment de tout composant spécifique

• Coopératif : afin de se connecter et utiliser le système, chaque pair doit fournir des ressources et des services aux autres pairs

Ainsi, ce modèle assure le partage et l’échange des fragments du profil accessibles par les différents fournisseurs de profils afin d’enrichir leurs modèles d’apprenant, ce qui permet d’obtenir des fragments pertinents tout en assurant la cohérence des données du profil

Toutefois, les mappings entre les schémas permettant la communication entre les serveurs distribués n’ont pas été étudiés, ce qui limite le processus d’échange de profils D’autre part, le problème de sécurité des données du profil n’a pas été soulevé, ainsi que

la possibilité de réutiliser les fonctionnalités du système de personnalisation dans d’autres contextes

2.4.2 Techniques spécifiques

2.4.2.1 Multi-agent

Un agent est considéré comme une entité autonome se situant dans un environnement spécifique, il est capable de vivre de façon autonome et flexible en percevant et en

• Réactivité : l'agent perçoit son environnement (pouvant être un monde physique,

un utilisateur via une interface graphique, un ensemble d'autres agents ou encore tous ces éléments combinés) et répond de manière opportuniste aux changements qui y surviennent

• Pro-activité : l'agent n'agit pas simplement aux stimuli de son environnement, il est aussi capable de démontrer des comportements dirigés par des buts en prenant des initiatives

• Sociabilité : l'agent interagit avec d'autres agents (pouvant être des êtres humains)

à l'aide d'un langage de communication d'agent

Un système multi-agent est un réseau d’entités qui peuvent interagir pour obtenir leurs propres objectifs, et donc, le système atteint l'objectif général Le système multi-agent est efficace dans les contextes suivants [13]:

• Le système a besoin de communications complexes Une communication est considérée complexe si : elle a au moins deux participants et l’échange d’informations entres eux se passe en plusieurs fois

• Le système doit fonctionner dans les cas ó on ne peut pas prévoir ou spécifier tout son comportement au cas par cas (case-by-case)

• Le système concerne la négociation, la collaboration ou la compétition entre plusieurs entités différentes

• Le système doit fonctionner de façon autonome

• Le système prévoit qu'il y ait des changements ou que le but du système soit changé dynamiquement

28

2.4.2.2 Service web

Un service web est un programme informatique permettant la communication et l'échange de données entre applications et systèmes hétérogènes dans des environnements distribués Il s'agit donc d'un ensemble de fonctionnalités exposées sur internet ou sur un intranet, par et pour des applications ou machines, sans intervention humaine, et en temps réel Les services web possèdent les avantages suivants :

• Ils fournissent l'interopérabilité entre divers logiciels fonctionnant sur diverses plates-formes

• Ils utilisent des standards et protocoles ouverts

• Les protocoles et les formats de données sont au format texte dans la mesure du possible, facilitant ainsi la compréhension du fonctionnement global des échanges

• Basés sur le protocole HTTP, les services Web peuvent fonctionner au travers de nombreux pare-feux sans nécessiter de changements sur les règles de filtrage

• Les outils de développement, s'appuyant sur ces standards, permettent la création automatique de programmes utilisant les services Web existants

Il existe deux technologies derrière le terme services web: les services web de type REST et les Services Web WS-*

REST (Representational state transfer) est une architecture originale du web, bâtie sur

quelques principes simples :

• URI est important : connaître l’URI doit suffire pour accéder à la ressource

• HTTP fournit toutes les opérations nécessaires (GET, POST, PUT, DELETE)

• Chaque opération est auto-suffisante: il n’y a pas d’état

• Utilisation des standards hypermédias : HTML ou XML qui permettent de faire des liens vers d’autres ressources et d’assurer ainsi la navigation dans l’application 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 :

29

• 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 leurs protocoles, de leur localisation au sens internet

• Une entrée éventuelle dans un annuaire UDDI (Universal Description Discovery and Integration)

2.4.3 Discussion

En se basant sur les caractéristiques des services web et des systèmes multi-agent, nous en déduisons que les deux technologies sont adaptées au développement d’applications interopérables dans des environnements hétérogènes

Néanmoins, pour les applications distribuées, les services web qui utilisent le protocole HTTP sont moins adaptés que les multi-agents, pour les raisons suivantes : Premièrement, bien que HTTP et 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 et vice versa Ce type d'interaction est difficile avec les services Web

Deuxièmement, le protocole HTTP est un protocole de type « stateless » C’est-à-dire que l'interaction entre le serveur et le client est généralement brève et quand il n'y a pas

de données échangées, le serveur et le client ne se connaissent pas Plus précisément, si

un client fait une demande au serveur, reçoit quelques informations, puis tombe en panne (ex : à cause d’un défaut de ressources électriques), le serveur ne saura pas que le client n'est plus actif

Alors, si on utilise les services web pour développer une application distribuée, cela nécessitera un travail supplémentaire pour rattraper ce que HTTP ne fait pas

30

En ce qui concerne la mise en œuvre, l’approche multi-agent nous prend moins d’effort et moins de temps que l’approche service web C’est parce que pour l’approche multi-agent nous avons déjà une plateforme complète - qui joue le rôle de l’environnement d’exécution pour les agents Par conséquent, nous définirons seulement des protocoles et des fonctions pour chaque agent, sans avoir besoin de faire attention à la communication entre ces agents

3.1 Description du modèle d’apprenant

L’apprentissage mobile est l’apprentissage à distance via des technologies électroniques ou digitales, qui s’appuie sur des technologies hautement portables comme ordinateur portable, téléphone mobile, PDAs, etc Avec l’apprentissage mobile, l’apprenant peut accéder à des ressources pédagogiques d’une façon personnalisée (ó il veut, quand il veut, comme il veut, etc.)

Le modèle utilisé dans l’apprentissage mobile doit supporter l’adaptation à l’apprenant et l’adaptation dispositif Une adaptation à l’apprenant consiste à présenter les contenus d'apprentissage en se basant sur les profils et les préférences des apprenants individuels L’adaptation au dispositif est le processus de transformation automatique du contenu original en contenu adaptatif en fonction des spécifications des dispositifs (par exemple : la taille de l'écran, la résolution, l’alimentation, etc.) Pour fournir un contenu adaptatif, nous avons besoin d'informations sur l'apprenant et de son environnement Ici, l’environnement est le contexte courant de l’apprenant Il se compose de plusieurs éléments comme la localisation, le dispositif utilisé, l’état courant du dispositif (ex: l’alimentation), la température, etc Mais dans l’échelle de mon étude, je m’intéresse seulement au dispositif utilisé par l’apprenant En outre, l’agenda est une ressource d’informations très utile pour des systèmes recommandation

En se basant sur les résultats d’analyse dans la section 2.2, nous avons construire un modèle apprenant en combinant les avantages des standards (IMS LIP, PAPI, FOAF) et

en ajoutant ce qui leur manque Particulièrement, le standard IMS LIP va fournir la

32

plupart du vocabulaire qui a été approuvé dans un contexte large De plus, il définit une structure de données plus riche que PAPI, tels que les objectifs, les intérêts et les préférences de l’apprenant, éléments indispensables pour les applications d’adaptation Afin de bénéficier de la capacité de FOAF à gérer les relations entre les apprenants, notre choix s’est fixé sur une fusion des modèles IMS LIP et FOAF, avec une extension décrivant le contexte de l’utilisateur (dispositif), et l’agenda

Ainsi, le modèle peut avoir les catégories suivantes :

Figure 4: Une partie de la proposition du modèle apprenant

Voici la description en détail des informations sur le modèle apprenant

Catégorie Sous-Catégorie Description

ContactInfor L’adresse en détail pour contacter

l’apprenant

Demographics Les informations démographiques de

l’apprenant

33

MaritalStatus L’état matrimonial

Eligibility L’éligibilité associé à de l’apprenant.Disability La disponibilité de l’apprenant

Priority La priorité du but

Description Description du but

Organisation L’organisation chargée de l'attribution

du diplôme Level Le niveau du diplôme Date La date de l’obtention du diplôme Description La description au diplôma

Status L’état de l’activité

Evaluation L’évaluation de l’activité (ex: par un

examen, etc.) Product Les produits créés dans le cadre de

l’activité Description Description de l’activité

Description Description de l’intérêt

Affiliation Classification Type de l’affiliation

Role Le rôle entrepris par l’apprenant Organisation L'organisation à laquelle l'apprenant

est affilié

Date Date de l’affiliation

Status L’état de l’affiliation

Description Description de l’affiliation

Exrefrecord Le duplicata utilisant une structure

externe

StartTime L’heure de début EndTime L’heure de la fin Description Description de l’événement

34

Mark Marque du dispositif Model Modèle du dispositif Manufacture Constructeur

Hardware Software Description Description du dispositif

Password Mot de passe du compte

Catégorie Sous-Catégorie Description

Locality Localisation

Postcode Code postal

Catégorie Sous-Catégorie Description

ContactInfor Telephone Téléphone mobile de l’apprenant

Web Adresse du site web de l’apprenant

IM Compte IM en ligne de l’apprenant

Catégorie Sous-Catégorie Description

PlaceofBirth Lieu de naissance

ID Le nombre identité de l’apprenant (ex:

sur carte identité, passeport…)

Representation La particularité de l’apprenant (ex: sur

visage)

Catégorie Sous-Catégorie Description

35

Display Informations sur l’écran du dispositif

InputMethod La méthode d’entrée du dispositif

Network Les types de réseau supportés

Battery Description de l’alimentation

Catégorie Sous-Catégorie Description

3.2 Description de l’approche

3.2.1 Modèle de gestion de profil

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 Il y a beaucoup de critères pour les classer, mais on s’intéresse ici à deux critères: la stabilité et la taille

Avec le premier critère, nous distinguons deux types :

• Les informations assez stables : ce sont les informations comme les données personnelles de base (ex : nom, âge, adresse, démographique, etc.) et les données éducatives (ex : transcription, goal, certification, etc.) Elles ne changent pas souvent

• Les informations non-stables (sensibles) : ce sont les informations comme les tâches, l’agenda, etc Elles changent souvent, surtout l’agenda

Avec la taille, nous avons aussi deux types : petite taille correspondant aux informations sous forme de texte, et grande taille pour les informations comme les images, les documents, etc

Dans le cadre de notre étude, les données du profil d’un apprenant sont fragmentées et maintenues par des fournisseurs de profil qui se situent dans des serveurs différents sur le réseau Internet Notre système joue le rôle d’un intermédiaire C’est-à-dire qu’il récupère

36

les fragments du profil, construit un profil complet, et le partage avec d’autres services

Si nous construisons un profil une seule fois au début, ensuite nous le stockons dans notre système pour le réutiliser plusieurs fois, alors nos données deviennent périmées quand l’utilisateur fait une mise à jour de ses informations dans les fournisseurs originaux, surtout les informations non-stables Par contre, si le profil est construit au moment du besoin, alors le cỏt performance du système sera très élevé

Notre solution consiste à fusionner les deux approches C’est-à-dire qu’on va stocker les données assez stables et faire la récupération pour les données sensibles Les informations assez stables ne changent pas souvent mais ce n’est pas toujours le cas Alors, un mécanisme de mise à jour va résoudre ce problème

Ainsi, notre modèle de gestion est une combinaison de modèles centralisé et décentralisé

3.2.2 Architecture du système proposé

Selon le modèle de gestion du profil abordé ci-dessus, notre système sera à la fois centralisé et décentralisé Il est centralisé parce qu’il a besoin d’un contrơle central qui réalise des opérations comme : le stockage des données, l’analyse des demandes, la récupération des données, la construction profil, etc En outre, il est décentralisé parce que ses données sont distribuées sur plusieurs « nœuds » Chaque nœud stocke localement un fragment particulier du profil dans sons propre langage de représentation Comme déjà mentionné dans la synthèse de la partie 2.5.3, l’architecture basée sur les agents a plusieurs avantages par rapport aux services web dans le contexte ubiquitaire, surtout pour les applications distribuées Nous décidons alors de choisir la technologie multi-agent pour mettre en œuvre notre système

Notre système se compose d’une partie médiateur (système central), la partie des services, la partie des utilisateurs et la partie des fournisseurs Toutes ces parties créent

un système multi-agents La communication entre ces parties se base sur la communication des agents, sauf la partie des fournisseurs

37

Le concept de base du médiateur est basé sur cinq types d’agent : l’agent système, l’agent gestionnaire de fournisseur, l’agent gestionnaire de service, l’agent fournisseur et l’agent service Les trois premiers sont des agents stables, ils fonctionnent continuellement et forment la fondation du système Les agents fournisseur et les agents service sont créés automatiquement en fonction de l’état du système à chaque moment

De plus, il y a un moteur d’inférence et des adaptateurs qui permettent de communiquer avec les fournisseurs

Figure 5: Architecture du système

L’agent système: est l’agent le plus important dans notre système Il réalise la

plupart de tâches importantes du système: il reçoit recevant les demandes des utilisateurs

et des agents service, analyse des demandes, envoie dea requêtes à l'agent gestionnaire de fournisseur en synthétisant les résultats envoyés par des agents fournisseur, la récupération des données sur OntoBroker (qui n'est pas seulement un moteur d'inférence, mais aussi une base de données)