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
1
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.
2
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.
3
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.
4
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
5
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
6
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
7
1.
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
8
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.
9
• 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
10
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é.
11
• Le rapport se termine avec les références et l’annexe où sont listés les liens vers
les documents consultés au cours de mon travail et des informations additionnelles
concernant la programmation.
12
2. Etat de l’art
2.1 Définitions
Afin de lever toute ambiguïté, nous définissons tout d’abord les concepts de base de
notre champ d’étude.
Un environnement ubiquitaire est un fonctionnement de la communication où 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 sousentend 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 luimême, avec (ou non) une photo et ses informations statistique. Mais dans les services de
13
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 ?
• Que sait-il déjà ?
• Ce qui est susceptible d'être son style d'apprentissage favorisé ?
2.2 Modèle apprenant
Dans cette partie, je vais présenter certains standards existant de modèle apprenant
existants avec leurs caractéristiques. En se basant sur cette étude, nous proposons une
taxonomie de caractéristiques possibles dans un modèle apprenant. Ensuite, un tableau de
comparaison des standards basés sur la taxonomie et certaines discussions sont donnés.
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.
14
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.
15
• Affiliation : présente des informations sur l'appartenance aux organisations
professionnelles.
• Accessibilité :
décrit
l'accessibilité
générale
comme :
les
capacités
linguistiques, les handicaps, les conditions d'admissibilité et les préférences
d’apprentissage.
• 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.
16
• 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)
17
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.
18
• Intérêt : décrit les loisirs et les activités récréatives
• Contexte
o Affiliation: décrit les relations de l'apprenant à l'institution, par exemple
groupes de travail, etc.
o Droit: URI qui indique un ensemble de droits aux ressources
spécifiques.
o Groupe / Organisation: informations concernant les groupes ou les
organisations dont l'apprenant est un membre.
• Sécurité : L'ensemble des mots de passe et clés de sécurité affectés à
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,
19
Figure 3: Tableau comparatif des standards du modèle utilisateur
2.2.4 Discussion
On voit bien que les modèles PAPI et IMS LIP se concentrent sur l'activité et les
accomplissements de l'apprenant. IMS LIP propose un modèle de profil structuré et riche,
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
20
réseaux sociaux d'apprenant. L'autre avantage de FOAF est que la représentation de
FOAF est en RDF. Il est ainsi facile à étendre.
On remarque aussi que tous les trois modèles supportent totalement les données
personnelles. Mais aucun d’eux ne décrit le contexte courant de l’apprenant. Tandis que
des informations concernant le contexte courant de l’utilisateur sont très importantes dans
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ù 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.
21
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 où 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,
22
quoiqu’OWL Lite gère des contraintes de cardinalité, il ne permet que des valeurs
de cardinalité de 0 ou 1.
• Le langage OWL DL concerne les utilisateurs souhaitant une expressivité
maximum sans sacrifier la complétude de calcul et la décidabilité des systèmes de
raisonnement. Le langage OWL DL comprend toutes les structures de langage
OWL avec des restrictions comme la séparation des types (une classe ne peut pas
être en même temps un individu ou une propriété, une propriété être un individu
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 :
23
• 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.
24
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 : multiagent 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
le serveur centralisé.
• Les données du profil se trouvent hors du contexte dans lequel il a été récupéré.
Les données peuvent être interprétées différemment dans un autre contexte.
• Différents scénarios non adaptés à l’architecture centralisée [Fink & Kobsa,
2000] : notamment dans l’informatique ubiquitaire, où l’utilisateur dispose
d’informations en différents points sur le réseau.
2.4.1.2 Modèle distribué
Dans un modèle distribué, le profil de l’utilisateur est distribué sur plusieurs
applications. Chaque application dispose d’un fragment particulier du profil sous son
propre langage de représentation. Alors, il n’assure pas la cohérence des données de
l’utilisateur. Les fragments pertinents sont retrouvés et intégrés seulement au moment du
besoin et pour un objectif spécifique.
25