Soutenance mémoire
Web sémantique RDF et OWL
Sélection des modalités
Après avoir défini l’environnement sous forme d’une ontologie, nous focalisons sur la sélection des modalités qui sont affectées par des contextes spécifiques. Dans cette partie, le contextes déjà vus dans l’ontologie seront détaillés et les requêtes de sélection seront définies.
Le contexte est considéré comme une information sur l’environnement d’un système informatique, ou bien comme des conditions qui déterminent un événement qui nous semble sans limite apparente. En effet, qu’obtiendrons-nous si nous envisageons de décrire dans le moindre détail les composants d’un système informatique ? De plus, il peut sembler ambitieux de vouloir décrire l’ensemble des conditions qui régissent le déclenchement d’un événement donné. C’est pour ces raisons et bien d’autres que des chercheurs, non satisfaits des définitions générales, ont essayé de définir ce terme pour permettre son utilisation dans leurs recherches. Avant de définir nos propres contextes, nous allons présenter dans l’ordre chronologique d’apparition une liste non exhaustive des définitions du contexte dans le domaine de l’informatique.
(Schilit 1994) a considéré que le contexte possède trois aspects importants qui consistent à répondre aux questions suivantes : Où es-tu ? Avec qui es-tu ? De quelles ressources disposes-tu à proximité ?
(Theimer. 1994) a défini le contexte comme la localisation, la description de personnes et d’objets dans l’entourage et les changements à ces objets.
(Brown 1995) a défini le contexte comme : « les éléments de l’environnement d’un utilisateur dont l’ordinateur a connaissance ».
(Brown 1997) a proposé un ensemble d’éléments extensibles pour caractériser le contexte dont les éléments de base sont : la localisation, l’ensemble des objets dont l’utilisateur a besoin, le temps et l’orientation spatiale (direction). (Ryan 1997) : « les éléments du contexte sont : la localisation de l’utilisateur, l’environnement, l’identité et le temps ».
(Ward 1997): « les états des environnements possibles de l’application ».
(Pascoe 1997): « ensemble d’états physiques et conceptuels ayant un intérêt pour une entité particulière ».
(Schmidt 1999): « connaissances à propos de l’utilisateur et les états des équipements, l’entourage, la situation et la localisation ».
(Brézillon 1999): « tout ce qui n’intervient pas explicitement dans la résolution d’un problème mais le contraint ».
(Chen 2000): « ensemble des états environnementaux et paramètres qui déterminent le comportement d’une application ou dans lequel un événement de l’application se déroule et ayant un intérêt pour l’utilisateur ».
(Dey 2001): « toute information qui peut être utilisée pour caractériser la situation d’une entité.
Toute entité est une personne, ou un objet qui est considéré comme significatif à l’interaction entre l’utilisateur et l’application, incluant l’utilisateur et l’application eux-mêmes ».
(Henricksen 2002) :« circonstance ou situation dans laquelle une tâche informatique se déroule». Malgré le grand nombre de définitions existantes et les similarités (la plupart font références à la localisation et l’environnement), le mot contexte reste toujours général. Deux techniques sont utilisées par les chercheurs pour la définition du contexte : l’une est basée sur l’énumération des exemples du contexte et l’autre fait plutôt des tentatives en vue de formaliser le terme. L’importance du contexte dans le domaine de l’interaction personnemachine et les systèmes mobiles a généré des définitions centrées sur l’utilisateur et d’autres sur l’application
Définition des contextes
Les contextes dans notre recherche permettent d’optimiser le travail du système de fusion multimodale, que ce soit par l’activation ou la désactivation des modalités spécifiques afin de garantir que les événements captés soient identifiables d’une manière correcte.
Puisque le système se trouve dans l’environnement et reçoit ces commandes d’un utilisateur, trois contextes différents ont été identifiés, qui sont les suivants :
• le contexte environnemental : il est responsable de l’ambiance générale de l’environnement, c’est-à-dire le bruit, le niveau de la lumière et la température de l’endroit où se trouvent le système et l’utilisateur.
o niveau de lumière : qui affecte l’utilisation des modalités gestuelles, manuelles et visuelles, car si le niveau de lumière est trop faible, ces modalités seront incapables d’identifier les événements d’une manière correcte ; par exemple, une modalité gestuelle ne détectera pas un objet pointé par l’utilisateur ; o niveau du bruit : qui affecte les modalités vocales, car s’il y a beaucoup de bruit dans l’environnement, cette modalité ne sera pas capable d’identifier les commandes vocales d’un utilisateur ; o la température : malgré son effet indirect sur les modalités, elle reste un paramètrequi doit être pris en considération dans des cas spécifiques, comme par exemple s’il fait froid et l’utilisateur ne veut pas envoyer des commandes gestuelles ou bien tactiles ;
• le contexte de l’utilisateur : qui est le profil de l’utilisateur, surtout à savoir s’il a un handicap ou non, car un utilisateur aveugle ne peut ni envoyer des commandes gestuelles, ni visuelles, donc ces modalités seront désactivées ;
• le contexte de la localisation : pour savoir si l’utilisateur est dans une maison, dans la rue ou bien à son travail, car par exemple s’il est dans la rue et entrain de conduire une voiture, il est préférable dans ce cas-là d’envoyer des commandes vocales ou bien tactiles plutôt que des commandes visuelles qui vont disperser sa concentration sur la conduite d’une voiture.
La Figure 4.17 représente tous les contextes définis dans l’ontologie avec leurs instances et leurs propriétés d’objets et de données. La classe Handicap a les instances deaf, blind, manualHandicap et mute qui sont reliées avec des valeurs booléennes vraies ou fausses à l’aide de la propriété de données hasHandicap. La classe LocationContexte a les instances home, work et road qui sont reliées à des valeurs booléennes vraies ou fausses à l’aide des propriétés de données isAtHome, isAtWork, isAtRoad. Les deux sous-classes Light et Noise de la classe EnvironmentalContext ont les instances BedRoomLight, DeskLight,
LivingRoomLight et NoiseFromOutsides, les instances de la classe Light sont reliées à leurs valeurs par une propriété de données hasLightnessLevel et les instances de Noise avec hasNoiseLevel.
La Figure 4.18 montre comment les modalités sont affectées par les contextes. Chaque modalité est reliée aux contextes qui affectent sa fonctionnalité. La modalité visuelle a une instance Eye_Gaze_Sensor qui est affectée par le niveau de la lumière du contexte environnemental et le type d’handicap du contexte de l’utilisateur. Eye_Gaze_Sensor est relié à l’instance LivingRoomLight de la classe Light par une propriété d’objet hasLight et à l’instance blind de la classe Handicap par une autre propriété d’objet hasContextUser. La modalité visuelle est affectée par ces deux contextes car si le niveau de la lumière est faible et/ou si l’utilisateur est aveugle, il sera difficile de capter les événements provenant de l’environnement, la modalité sera alors désactivée.
Les modalités à saisie manuelle, gestuelle et tactile sont affectées par le niveau de la lumière et le type d’handicap de l’utilisateur. S’il fait sombre et/ou si l’utilisateur est aveugle ou a un handicap manuel ces modalités seront désactivées.
La modalité vocale s’intéresse au niveau du bruit et au type d’handicap de l’utilisateur ; s’il y a beaucoup de bruit et/ou si l’utilisateur est sourd ou muet, cette modalité sera inutile et désactivée.
Les requêtes de sélection des modalités
Après la description des contextes et de leurs relations avec les modalités dans l’ontologie, la sélection des modalités peut être réalisée par de simples requêtes afin de sélectionner la modalité la plus appropriée par rapport aux contextes définis. Ces requêtes sont définies en utilisant le langage des requêtes SQWRL. Elles comparent les événements provenant des fichiers XML à ceux qui sont définis dans l’ontologie. À noter que SQWRL existe sous forme d’un plugin dans PROTÉGÉ. La représentation générale de la requête responsable de la sélection des modalités selon la description logique d’OWL est la suivante :
Sélection des modèles
Comme mentionné auparavant, nous avons défini une trentaine de modèles de fusion dans l’ontologie. Chaque modèle représente une combinaison correcte des événements pour différentes commandes d’un utilisateur. Un exemple de modèle est présenté dans la Figure 4.20. Il montre les différents événements qui forment le Model01 et l’ordre suivi par l’utilisation de la propriété d’objet hasNextM01. Ce modèle est constitué par :
La Figure 4.21 représente un exemple de relations entre les instances de la classe Model02.
Le modèle02 est formé par trois sous-classes ActionForMovableObject, AverageObject et IntendedLocation qui ont comme instances get, box et here respectivement. Une relation hasNextM02 de type propriété d’objet a été créée pour définir l’ordre des instances. Cela veut dire qu’après get il y a box suivie par here. Ce type de relations aide à mieux comprendre l’ordre des événements dans une commande spécifique.
Requêtes de sélection des modèles
Une fois les modèles définis dans l’ontologie, il suffit de déclarer les requêtes SQWRL pour sélectionner un modèle approprié à une combinaison d’événements détectés par les modalités. Chaque modèle a sa propre requête. Une trentaine de requêtes ont été créées pour sélectionner chaque modèle. La représentation générale d’une requête de sélection du modèle selon la description logique d’OWL est comme suit :
Avec C une classe de l’ontologie, R une propriété d’objet et , des instances.
La requête (5) est un exemple qui sélectionne le modèle 05. Dans cet exemple, x, y et z sont des événements détectés par les modalités. La requête demande à l’ontologie de vérifier si x, y et z sont des instances des classes ActionForMovableObject, MovableObject et Person respectivement, de vérifier si 1) y vient après x, 2) z vient après y et 3) si ces trois classes sont reliées directement à une super classe m qui désigne un modèle. Si les conditions sont vérifiées, la requête sélectionne le modèle approprié qui est dans ce cas le modèle 05. La Figure 4.22 représente l’exécution de la requête (5) dans PROTÉGÉ et le résultat obtenu.
|
Table des matières
INTRODUCTION
CHAPITRE 1 REVUE DE LA LITTÉRATURE
1.1 Introduction
1.2 Terminologie de la fusion
1.3 Évolution de la fusion multimodale suivant le model BRETAM
1.3.1 Phase de découverte
1.3.2 Phase de réplication
1.3.3 Phase empirique
1.3.4 Phase de théorie et d’automatisation
1.3.5 Phase de maturité
1.4 Caractéristiques du moteur de fusion
1.5 Mécanisme de fusion
1.6 Algorithmes de fusion
1.7 Méthodes de fusion multimodale
1.8 Raisonnement et représentation de la connaissance
1.8.1 Web sémantique RDF et OWL
1.8.1.1 RDF Resource Description Framework
1.8.1.2 OWL Ontology Web Language
1.8.1.3 Comparaison d’RDF, OWL, UML et OCL
1.8.1.4 Langages du marquage multimodal
1.8.2 Les ontologies
1.8.2.1 Ontologie formelle
1.8.2.2 Types des ontologies
1.8.2.3 Critères d’évaluation d’une ontologie
1.8.2.4 Utilisations des ontologies
1.8.2.5 Langage des règles pour les ontologies
1.8.2.6 Langage de requêtes pour les ontologies
1.8.2.7 Raisonneurs pour les ontologies
1.9 Systèmes et architectures multimodaux existants
1.9.1 Smartkom
1.9.2 ICARE
1.9.3 SmartWeb
1.9.4 HEPHAISTK
1.10 Synthèse et conclusion
CHAPITRE 2 BUT, OBJECTIFS ET MÉTHODOLOGIE DE RECHERCHE
2.1 Introduction
2.2 Problématique de recherche
2.3 Buts et objectifs de recherche
2.4 Méthodologie de recherche
2.4.1 Phase 1 : Exploration
2.4.2 Phase 2 : Modélisation de l’environnement
2.4.3 Phase 3 : Définition des Contextes et sélection des modalités
2.4.4 Phase 4 : Définition des modèles de fusion
2.4.5 Phase 5 : Développement du moteur de fusion
2.4.6 Phase 6 : Validation
2.4.7 Phase 7 : Implémentation
2.5 Originalité des travaux proposés
CHAPITRE 3 ARCHITECTURE PROPOSÉE
3.1 Introduction
3.2 Exigences pour modéliser une architecture de l’interaction multimodale
3.3 Approche générale
3.4 Architecture du système de fusion multimodale
3.4.1 L’architecture de sélection des modalités
3.4.2 L’architecture du moteur de fusion
3.5 Conclusion
CHAPITRE 4 CONCEPTION DE L’ARCHITECTURE
4.1 Introduction
4.2 Modélisation de l’environnement
4.2.1 Outil de modélisation de l’ontologie
4.2.2 Modélisation de l’ontologie
4.2.2.1 Définition des classes .
4.2.2.2 Définition des instances de l’ontologie
4.2.2.3 Relations sémantiques de l’ontologie
4.3 Sélection des modalités
4.3.1.1 Définition des contextes
4.3.2 Définition des contextes dans l’ontologie
4.3.3 Les requêtes de sélection des modalités
4.4 Sélection des modèles
4.4.1 Requêtes de sélection des modèles
4.5 La fusion multimodale
4.5.1 Les pré-conditions
4.5.2 Algorithme de fusion
4.5.3 Scénario « get that here »
4.6 Conclusion
CHAPITRE 5 VALIDATION DE L’ARCHITECTURE
5.1 Introduction
5.2 Les réseaux de Petri colorés et le CPN-Tools
5.3 Simulation de l’architecture
5.3.1 Définition des paramètres
5.3.2 Implémentation
5.3.3 Résultat de la simulation
5.4 Conclusion
CHAPITRE 6 IMPLÉMENTAION DU PROTOTYPE
6.1 Introduction
6.2 Réalisation
6.3 Conclusion
CONCLUSION
ANNEXE I Déclarations du réseau du Petri coloré dans le chapitre 5
ANNEXE II Rapports de simulations du réseau de Petri dans le chapitre 5
ANNEXE III Requêtes SQWRL et règles SWRL
BIBLIOGRAPHIE
Télécharger le rapport complet
