Soutenance mémoire
Quelques Applications de l’Informatique Ubiquitaire
Parmi les applications de l’informatique ubiquitaire on peut citer les suivantes: L’infrastructure MyCampus de [Gandon04]. Elle est basée sur le Web Sémantique, sensible au contexte, en particulier aux préférences de confidentialité de l’utilisateur (« privacy preferences»). L’objectif de Mycampus est l’affichage des informations journalières d’un campus universitaire. Les applications WAY (« Where Are You ») [Collier03], Ad-Me (« Advertising for Mobile e-commerce user ») [Hristova04] et Gulliver’s Genie [O’Hare02] ont été réalisées pour assurer l’adaptation de l’information à la localisation de l’utilisateur, en prenant en considération les caractéristiques de son DM (Dispositif Mobile) (en général, des PDA et des téléphones portables).
WAY [Collier03] est un système destiné pour la synchronisation et la prise de rendez-vous entre utilisateurs nomades en se référant à leurs PDA.
Ad-Me [Hristova04] est un système qui utilise les informations sur la localisation et les préférences des utilisateurs nomades, pour leurs offrir des services de publicité. Par exemple : des magasins et des restaurants.
Gulliver’sGenie [O’Hare02] est un guide touristique qui se configure selon la localisation et l’orientation de déplacement de l’utilisateur et personnalise l’information en prenant en compte son profil (par exemple, Gulliver’s Genie fait un plan de la ville en soulignant tous les ruines si les sites touristiques les plus visités par l’utilisateur sont des ruines).
En conclusion, les applications de L’informatique ubiquitaire doivent satisfaire l’utilisateur en lui fournissant une réponse appropriée coté contenu et temps. Pour cela, elles doivent prendre en considération la situation contextuelle de cet utilisateur, ensuite, adapter tout le comportement de ces applications à cette situation en cours. Dans ce domaine, les applications sont sensibles au contexte « context-aware applications ». La section suivante est consacrée à la notion de contexte.
L’Approches basées sur les langages de balisage
La structure hiérarchique des données modélisées est le point commun entre toutes les approches qui utilisent un langage de balises. Cette modélisation admet à utiliser un ensemble de balises avec des attributs et des contenus. Dans XML (eXtensible Markup Language), les balises sont déclarées dans un document appelé DTD (Document Type Définition). Le contenu des balises est défini récursivement par d’autres balises; un exemple d’utilisation de ce type de modélisation est la description des profils. Dans Pascoe [Pascoe97], on trouve une modélisation du contexte en utilisant un protocole d’échange de données contextuelles au format XML entre un serveur et un utilisateur nomade, pour le compte d’une application appelée Stick-e Note. Ce protocole nommé ConteXtML [Ryan06] a deux utilisations possibles. La première est de décrire le contexte acquis d’un utilisateur, la deuxième utilisation est de représenter le profil de l’application. La figure 2.3 montre un exemple d’un message qui décrit la position capturée de l’utilisateur. Cette position est représentée par les coordonnées x, y et z [Belhanafi06]. Figure 2.3 : Exemple de description de contexte avec conteXtML [Belhanafi06] 1 < context session= « 123 » action « update »> 2 3 4 CHAPITRE 2 LES APPROCHES DE MODELISATION DU CONTEXTE Etat de l’art 25 Malgré que cette modélisation est utile pour certaines applications, elle ne définit qu’un format d’échange de données et ne représente pas les contextes de haut niveau. Aussi, elle ne présente plus de solutions pour la résolution des conflits. De plus, elle ne décrit pas les relations entre les informations de contexte. Une autre approche dans cette catégorie est le CC/PP (Composit Capability/Prefrence Profile) de [Klyne04]. Il représente la proposition du W3C pour la représentation de profils. Il utilise RDF (Resource Description Framework) [Manola04] pour représenter les profils. Par l’utilisation d’une structure de profils, le CC/PP décrit les capacités d’un dispositif et les préférences de l’utilisateur. Cette structure est composée d’une hiérarchie à deux niveaux. Chaque profil a un certain nombre de composants et chaque composant a des caractéristiques. La figure 2.4 représente le profil d’un client. Figure 2.4 : Exemple de description de contexte avec CC/PP [Belhanafi06] Les chercheurs ont remarqué que CC/PP est pauvre en termes de vocabulaire et a besoin d’être étendu car il est destiné à la description de profil. De plus, il ne prend pas en compte la résolution des conflits qui peuvent survenir lors de la vérification des préférences. Aussi, il ne permet pas la description de relations et de contraintes complexes entre les informations de contexte [Belhanafi06]. A leur côté, Held et al. [Held02] ont proposé CSCP (Compréhensive Structured Context Profile) qui utilise RDF/S pour représenter les structures naturelles d’informations de profil comme requis à l’information contextuelle. Cette proposition ne permet pas la résolution des conflits, ni de décrire des relations, des contraintes ou des dépendances entre les informations de contexte. Une approche semblable à CSCP est le CC / PP Contexte Extension Par Indulska et al. [Indulska03]. Les auteurs ont étendu le CC / PP et le vocabulaire de User Agent Profile UAProf [WAPF03] par un certain nombre d’arbres de composants et d’attributs reliés à 1 < rdf : Description rdf :about= « http://www.example.com/profile#MyProfile »> 2 3 < rdf : Description rdf :about= « http://www.example.com/profile#TerminalHardware »> 4 < rdf : type rdf :ressource= http://www.example.com/schema#HardWarePlatform » /> 5 < ex :displayWidth>320</ex :displayWidth> 6 < ex :displayHeight>200</ex :displayHeight> 7 </rdf :Description> 8 </ccpp :component> 9 </rdf :Description> CHAPITRE 2 LES APPROCHES DE MODELISATION DU CONTEXTE Etat de l’art 26 certains informations du contexte, par exemple: localisation, les caractéristiques du réseau et des informations sur la session. Cette approche est capable de permettre la sensibilisation de contexte aux applications et d’autres parties de l’infrastructure de l’informatique ubiquitaire. A son tour, [Chtcherbina03] a proposé PPDL (Pervasive Profile Description Language), un langage basé sur le XML. Il représente l’information contextuelle et les dépendances lors de la définition des modèles d’interaction. Ce langage présente quelques anomalies, il est limité en termes de nombre d’aspects contextuels évaluables et critères de conception. Seulement des parties du langage sont à la disposition du public. Pour cela, cette approche n’est pas pertinente pour la modélisation du contexte. Il y’a plusieurs autres approches de modélisation du contexte dans la catégorie des langages de balisage, par exemple, le contexte de configuration Capra et al. [Capra01] qui utilise le langage XML pour la modélisation du profil de l’utilisateur et le profil d’une application. Cette approche est utilisée par l’intergiciel CARISMA [Capra03] pour la reconfiguration d’une application ou l’adapter aux changements du contexte. Une autre approche de modélisation de contexte dans cette catégorie est le projet SECAS réalisé par T.Chaari et al [Chaari06]. Le projet SECAS (Simple Environment for Context Aware Systems) s’intéresse à l’adaptation des applications au contexte d’utilisation (préférences et environnement de l’utilisateur, terminal utilisé…). Dans le projet SECAS, les auteurs ont proposé une nouvelle définition de la notion de contexte qui sépare les données de l’application des paramètres du contexte. Ils ont utilisé une représentation basée sur RDF pour la modélisation du contexte (figure 2.5). Figure 2.5 : Le modèle de contexte de SECAS [Chaari06] Une autre approche est celle proposée dans [Kanellopoulos08b] qui consiste en un modèle de métadonnées pour coder l’information sémantique des destinations touristiques, en utilisant une architecture de réseau P2P basé sur RDF. Le modèle combine des structures ontologiques de l’information pour les destinations touristiques et les pairs. Dans ce travail, le modèle proposé est spécifique et très prometteur pour les destinations touristiques. Le travail de [Soukkarieh10] est une plateforme CA-WIS (Context Adaptation of Web Information System) qui est une démarche plus générale pour concevoir des Systèmes d’Information Web fournissant des Services Web sensibles au contexte. Ils ont intégré un modèle générique du contexte dans les deux parties de l’architecture de cette plateforme pour permettre à un utilisateur de recevoir d’une part des Services Web pertinents par rapport à son contexte, et d’autre part d’interagir avec un service sensible au contexte. Ce modèle générique concerne non seulement le contexte de l’utilisateur mais aussi le contexte du service.
Les approches basées sur les langages de balisages
Ces approches satisfont le critère « validation partielle » grâce aux outils de validation et une définition de structure qui les supportent et qui peuvent être aussi utilisés pour contrôler les types simples et complexes. Même chose pour le critère « Incomplétude et ambiguïté ». Aussi, ces approches donnent une définition complète des structures, ce qui assure une formalité de haut niveau, qui peut être utilisée pour la détermination de l’interopérabilité. L’applicabilité aux infrastructures d’un environnement de l’informatique ubiquitaire (par exemple : les Web services) est un avantage de ce type d’approches.
Origine Des Ontologies
L’arrivée de l’Ingénierie des Connaissances (IC) a été l’occasion pour l’apparition des ontologies dans le domaine de l’Intelligence Artificielle (IA), et ceci, pour répondre aux problèmes rencontrés lors de la représentation et la manipulation des connaissances dans les systèmes informatiques. La racine du mot ontologie est du grec :
Onto (le participe présent du verbe être) qui est l’étude de l’être en tant qu’être ;
Et logie qui signifie discours.
Les ontologies ont trouvé leur origine depuis le XIXième siècle en philosophie, où ils ont défini l’ontologie comme l’étude des propriétés générales de ce qui existe. Ce qui est équivalant à l’ensemble des connaissances que l’on a sur le monde [Welty01].
CLASSIFICATIONS DES ONTOLOGIES
Cette section présente la manière de classifier les ontologies. Dans la littérature, on trouve beaucoup de travaux qui ont proposé différents critères pour classifier une ontologie. Dans la suite, nous allons exposer quelques exemples : Selon [Uschold96], les ontologies varient selon trois axes : (1) le degré de formalisme de la représentation de connaissances: qui est sélectionné selon les contextes d’utilisation des ontologies, et ça pour éviter la contredit qui peut survenir entre, d’une part, la nécessité de formaliser qui est lié au partage des connaissances et à la réutilisabilité, et, d’autre part, l’obligation de construire une ontologie lisible pour les utilisateurs. (2) l’objectif opérationnel : qui représente l’interopérabilité entre les systèmes, la communication entre les utilisateurs, la résolution de problèmes et l’utilisation par un problème d’ingénierie comme la réutilisabilité de composants. (3) et le sujet : qui est composé du domaine de connaissance, les connaissances d’inférence et les connaissances attachées au modèle de représentation. A son tour [Gómez-Pérez04] a distingué deux classes d’ontologie, les ontologies légères (lightweight ontologies) et les ontologies lourdes (heavyweight ontologies). Il les définit comme suit: (1) Les ontologies légères : qui incluent des concepts englobant des propriétés organisées en taxonomies avec des relations conceptuelles (exemple :Yahoo! Directory); (2) Les ontologies lourdes : qui ajoutent aux ontologies légères des règles(axiomes) et des conditions (restrictions) pour éclaircir le sens. Les ontologies lourdes modélisent un domaine de manière plus profonde avec plus de restrictions basées sur la sémantique du domaine. [Gómez-Pérez04] a proposé, à son tour, une classification où les ontologies sont classées selon deux critères: (1) la quantité et le type de structure dans la conceptualisation, (2) le sujet de la conceptualisation comme suit :
Ontologies de représentation de connaissances : qui modélisent les représentations fondamentales utilisées pour la formalisation des connaissances sous un modèle donné.
Ontologies générales ou communes : qui modélisent les connaissances de sens collectif partageables et réutilisables d’un domaine à l’autre. Elles incluent un vocabulaire correspondant aux évènements, choses, espaces, fonctions, temps, comportements causalités, etc.
Ontologies de niveau supérieur (top-level, upper-model): qui modélisent les concepts très généraux auxquels les racines des ontologies de plus bas niveaux faudrait être reliées. Elles définissent des notions générales comme les notions d’objet, d’état, de propriété, de moment, de valeur, d’action, d’événement, d’effet et de cause [Sowa84].
Ontologies de domaine : ont pour but la modélisation des connaissances réutilisables dans des domaines bien définis. Elles offrent des concepts et des relations qui permettent de couvrir les activités, les vocabulaires, et les théories de ces domaines. Leurs concepts sont généralement des spécialisations de concepts décrits dans des ontologies de niveau supérieur. Il existe déjà de nombreuses ontologies de domaine comme : ENGMATH pour les mathématiques [Gruber94] et MENELAS dans le domaine médical [Zweigenbaum99].
Ontologies de tâches : qui modélisent les vocabulaires liés à une activité générique ou une tâche avec la spécialisation de certains termes des ontologies de niveau supérieur.
Ontologies de tâches de domaine : ce sont des ontologies de tâches réutilisables dans un domaine précis, mais pas d’un domaine à l’autre et elles sont autonomes de l’application.
Ontologies de méthodes : qui modélisent les définitions des concepts et des relations adéquates pour le processus d’inférence et de raisonnement pour exécuter une tâche spécifique.
Ontologies d’applications : qui modélisent les connaissances utiles pour des applications spécifiques. Elles spécialisent généralement le vocabulaire des ontologies de domaine et des ontologies de tâches.
|
Table des matières
INTRODUCTION GENERALE
1. Contexte général
2. Contributions
3. Organisation du document
CHAPITRE 1 : L’INFORMATIQUE UBIQUITAIRE ET LA NOTION DE CONTEXTE
Introduction
1. L’informatique ubiquitaire
1.1 Définition
1.2 Caractéristiques de l’informatique ubiquitaire
1.3 Quelques applications de l’informatique ubiquitaire
2. La notion de contexte
2.1. Definition du contexte
2.2. Le processus d’acquisition de contexte
2.2.1 Méthodes pour l’acquisition de contexte
2.2.2 Difficultés dans l’acquisition de contexte
2.2.3 Exemples d’infrastructures pour l’acquisition de contexte
2.3. Importance du contexte dans le domaine de l’informatique
2.3.1 Contexte dans le traitement du langage
2.3.2 Contexte pour l’aide à la prise de décision
2.3.3 Contexte dans l’informatique sensible au contexte
2.3.4 Contexte dans l’informatique ubiquitaire
2.4. Caractéristiques des informations de contexte
Conclusion
CHAPITRE 2 : LES APPROCHES DE MODÉLISATION DU CONTEXTE
Introduction
1 Typologie d’Approches de la Modélisation du Contexte
1.1 Les approches Paires/Triplets
1.2 Les approches orientées modèles
1.2.1 Les approches basées sur les langages de Balisage(Markup Scheme Models)
1.2.2 Les approches graphiques
1.2.3 Les approches orientée objet
Conclusion pour les approches oriéntées modéles
1.3 Les approches basées sur la logique
1.4 Les approches orientées ontologie
1.4.1 Presentation des approches orientées ontologies
1.4.2 Conclusion pour les approches oriéntées ontologie
2 Evaluation des approches
2.1 Les critères généraux
2.1.1 Validation partielle
2.1.2 Richesse et qualité d’information
2.1.3 Incomplétude et ambiguïté
2.1.4 Niveau de formalité
2.1.5 Applicabilité aux environnements existants
2.2 Evaluation
2.2.1 Les approches paires/triplets
2.2.2 Les approches orientées modèle
2.2.3 Les approches basées sur la logique
2.2.4 Les approches basées sur les ontologies
Synthèse
Conclusion
CHAPITRE 3 : LES ONTOLOGIES ET LEURS CONCEPTS
Introduction
1. Notion d’ontologie
1.1 Origine et définitions des ontologies
1.2 Définitions informatique
2. Les constituants d’une ontologie
2.1 Les Concepts
2.2 Les relations
2.3 Axiomes (règles)
2.4 Instances
3. Utilisations des Ontologies : Différents besoins
3.1 Communication
3.2 Ingénierie des systèmes
3.3 Le Web sémantique
3.4 Les ontologies dans les systèmes sensibles au contexte
4. Classifications Des Ontologies
5. Formalismes De Representation
5.1 Frames
5.2 Graphes conceptuels
5.3 Logique de description LD
5.3.1 Historique
5.3.2 Les deux niveaux de description
5.3.2.1 Le niveau terminologique (TBox)
5.3.2.2 Le niveau assertionnel (ABox)
5.3.3 L’inférence
6. Les Langages De Construction Des Ontologies
6.1 eXtended Markup Language et XML Schema
6.2 Resource Description Framework et RDF Schéma
6.3 OWL (Ontology Web Language)
7 Editeur D’ontologies
7.1 OILEd
7 2 OntoEdit
7.3 Ontosaurus
7.4 Protégé2000
8. Systemes De Raisonnement Sur Les Ontologies
8.1 Racer
8.2 Pellet
8.3 JENA
8.4 Comparaison entre les systemes de raisonnement
9 Langages D’interrogation D’ontologies
10 Méthodes de Construction D’ontologie
10.1 ENTERPRISE
10.2 TOVE
10.3 METHONTOLOGY
10.4 OTK
Conclusion
CHAPITRE 4 : «CONTOLOGY » : UNE ONTOLOGIE POUR LA MODELISATION DE CONTEXTE ET LA GESTION DES CONFLITS
Introduction
1. Motivations Pour L’utilisation Des Ontologies
2. La Representation Du Modele De Contexte
2.1 La Définition Du Contexte
2.2 La Représentation Du Contexte: Préférences, Conflits
2.2.1 Preferences
2.2.2 Conflict
3. Processus De Construction De L’ontologie
3.1 Spécification
3.2 Conceptualisation
3.2.1 Construction De Glossaire De Termes
3.2.2 Construction Du Diagramme De Classification Des Concepts
3.2.3 Construction Du Diagramme Des Relations Binaires
3.2.4 Dictionnaire De Concepts
3.2.5 Tableaux Des Relations Binaires
3.2.6 Tableaux Des Attributs
3.2.7 Tableaux Des Instances
3.2.8 Description Des Règles Du Contexte : Les Règles De La Gestion Des Conflits
3.3 Formalisation
3.3.1 Construction De Tbox
3.3.2 Construction De Abox
3.4 Implémentation
3.4.1 Présentation De L’éditeur PROTEGE OWL
3.4.2 Définition De La Hiérarchie Des Classes
3.4. 3 Définition Des Propriétés
3.4.4 Définitions Des Restrictions
3.4.5 Création Des SWRL Sous Protégé
3.4.6. Génération du code
3.5 Test De L’ontologie
4 L’exploitation De L’ontologie De Contexte: Le Processus D’adaptation
4.1 Les Etapes de Processus d’Adaptation
4.2 Présentation Du Processus D’adaptation
4.2.1 Preferences Manager Web Service
4.2.2 Conflicts Manager Web Service
4.2.3 Adapter Web Service
4.2.4 Context Sensor
4.2.5 Context Integration
Conclusion
CHAPITRE 5 : ETUDE DE CAS : THE TRAVEL BOOKING APPLICATION
Introduction
1. Environnent De L’Implémentation
1.1 Microsoft Visual Studio
1.2 PROTEGE
2. Etude De Cas
2.1 Motivations pour l’utilisation des Service Web
2.2 L’Application Travel Booking
2.3 Déroulement du Processus d’Adaptation : Exploitation de l’Ontologie
2.3.1 Interaction Entre L’utilisateur, La Partie Dynamique Et l’Ontologie De Contexte
2.3.2 Vérification de la requête de l’utilisateur
2.3.3 Le Conflit entre les Caractéristique du DM et Display Préférences
2.3.4 L’adaptation De La Requête De L’utilisateur
Conclusion
CONCLUSION GENERALE ET PERSPECTIVES
ANNEXE
REFERENCES BIBLIOGRAPHIQUES
Télécharger le rapport complet
