Accueil🇫🇷Chercher

Multimodal Architecture and Interfaces

Multimodal Architecture and Interfaces (« architecture multimodale et interfaces Â» en anglais) ou MMI-Arch est un standard ouvert en dĂ©veloppement par le W3C depuis 2005. Depuis 2010 est une recommandation d'architecture Ă  composants conteneurs du W3C. Le document est le rapport technique de spĂ©cification d'une architecture informatique gĂ©nĂ©rique et de ses interfaces pour faciliter l’intĂ©gration et la gestion des interactions multimodales dans un environnement informatique. Il a Ă©tĂ© produit par le groupe de travail en Interaction multimodale du W3C.

Multimodal Architecture and Interfaces
Image illustrative de l’article Multimodal Architecture and Interfaces

Éditeur World Wide Web Consortium
Auteur MMI Working Group
Genre Recommandation
État Working Draft
Première publication 22 avril 2005
Dernière publication 25 janvier 2011
Standard Dernière version
Site web http://www.w3.org/2002/mmi/

Description

La recommandation Multimodal Architecture and Interfaces se concentre sur la proposition d'un cadre général pour permettre aux modules requis dans un système multimodal, de communiquer les uns avec les autres.

Cette spécification propose une architecture orientée évènement dont le principal objet est le flux de données de contrôle car en tant que cadre général de référence, elle sert à déterminer les infrastructures de base utiles pour le contrôle de l'application et des services multimodaux.

L'architecture est aussi proposée pour faciliter la tâche d'implémentation à plusieurs types de dispositifs fournisseurs de services multimodaux, comme les dispositifs mobiles et portables, les appareils électroménagers, l'internet des objets, la télévision et les réseaux domestiques, les applications d'entreprise, les applications web, [[1]] les voitures "intelligentes" ou comme les applications médicales.

Structure Logique

L'architecture dans le MMI Runtime Framework

Multimodal Architecture and Interfaces est la description spécifiée d'une infrastructure de services plus large appelée The Runtime Framework dans laquelle sont fournies les principales fonctions dont un système multimodal a besoin et qui se trouve a un niveau d'abstraction plus haut que l'architecture MMI.[[2]] Ce framework est le support d'exécution et de communication des modules du système multimodal tandis que l'architecture MMI est la description et la spécification de ses principaux modules, ses interfaces et son mode de communication.

Le Modèle MVC dans MMI-Arch

La recommandation Multimodal Architecture and Interfaces s'inspire du patron de conception d'architecture applicative MVC qui organise la structure des interfaces utilisateur en trois parties : le Modèle, la Vue et le Contrôleur.[[3]]

L'imbrication dans l'architecture MMI

Une particularité de cette architecture c'est que bien que la couche de présentation représentée par la Vue a été traditionnellement appliquée aux interfaces graphiques; cette recommandation généralise l'abstraction au contexte plus large de l'interaction multimodale où l'utilisateur peut utiliser une combinaison de modalités visuelles, auditives, biométriques et/ou tactiles.

L'architecture MMI fait donc la distinction entre le contrôleur d'interaction (Interaction Manager - IM), le composant de données (Data Component - DC) et les composants modalité (Modality Components - MC). Cette distinction est similaire à la distinction entre le Contrôleur, le Modèle et les documents de présentation de la Vue dans le patron MVC.

Une autre particularité est l'imbrication. Les modules étant des boîtes noires, il est possible d'encapsuler plusieurs composants dans un composant plus complexe, qui communiquerait avec un contrôleur de plus haut niveau. De cette manière l'architecture suit le principe des poupées russes.[[4]]

La recommandation propose aussi une mise en œuvre de façon distribuée sur plusieurs supports matériels en réseau ou de façon centralisée, avec tous les modules sur un même support matériel. L'échange d'information entre les différents modules se fait avec un couplage lâche qui favorise la faible dépendance entre les modules, la réduction de l'impact des changements dans un module et la réutilisation des modules. De cette manière les modules ont peu ou aucune connaissance du fonctionnement des autres modules et la communication entre les modules se fait grâce à l'échange de messages selon un protocole de communication précis à travers les interfaces de programmation fournies par l'architecture MMI.[[5]]

Les modules de l'Architecture MMI

Modules de l'Architecture

Le contrĂ´leur d'interaction (Interaction Manager)

Le contrôleur d'Interaction est un composant logique, chargé de tous les échanges de messages entre les composants de modalité du système et l'infrastructure multimodale (le Runtime Framework). Il est un bus de communication et un gestionnaire d'évènements.

Chaque application peut configurer au moins un contrôleur d'interaction (Interaction Manager) pour définir la logique d'interaction souhaitée. Ce contrôleur est au cœur de l'interaction multimodale:

  • Il gère les comportements spĂ©cifiques dĂ©clenchĂ©s par les messages Ă©changĂ©s entre les diffĂ©rents modules d'entrĂ©e et de sortie.
  • Il gère la communication entre les modules et l'application cliente.
  • Il assure la cohĂ©rence entre plusieurs entrĂ©es et sorties et fournit une perception de l'Ă©tat gĂ©nĂ©ral de l’application.
  • Il est responsable de la synchronisation des donnĂ©es.
  • Il est responsable de la gestion du focus.
  • Il gère la communication avec toute entitĂ© externe au système.

Les composants de modalité (Modality Component)

Les composants de modalité sont responsables de tâches spécifiques, notamment la manipulation des entrées et des sorties dans les diverses modalités, comme la parole, l'écriture, la vidéo, etc. Ce sont des entités logiques responsables du contrôle des entrées et des sorties des différents dispositifs matériels (microphone, tablette graphique, clavier) et logiciels (détection de mouvement, changements biométriques) associés au système multimodal. Par exemple (voir diagramme ci-dessous), un composant de modalité A peut se charger de la reconnaissance de la parole avec la gestion des entrées audio. Un autre composant de modalité B peut gérer plutôt les entrées complémentaires provenant de deux dispositifs différents : une tablette graphique et un microphone. Deux composants de modalité C, peuvent gérer séparément deux entrées complémentaires fournies par un même dispositif: une caméra vidéo. Un dernier composant de modelité D, peut utiliser un service externe de reconnaissance et ne contenir que le contrôle des échanges nécessaires à la reconnaissance.

Abstraction des entrées avec les Modality Components

Dans les quatre cas le système possède un composant de modalité pour la détection des commandes vocales en entrée, malgré les différences d'implémentation: le composant de modalité étant une abstraction d'un type d'entrée qui est gérée et implémentée de manière différente à chaque cas. Tout composant de modalité peut éventuellement envelopper de multiples fonctionnalités fournies par plusieurs périphériques physiques, mais aussi plusieurs composants de modalité pourraient être inclus dans un seul appareil. Pour cette raison, la recommandation du W3C dans son état actuel ne décrit pas en détail la structure ou l'implémentation des composants de modalité. Elle porte seulement sur la nécessité de prévoir une interface de communication avec le contrôleur d'interaction et une implémentation qui respecte un protocole de communication précis: les Life-Cycle Events.

Le composant de données publiques et privées

Le composant de données (Data Component)

Le composant de données a pour rôle de sauvegarder les données publiques de l'application qui peuvent être requises par plusieurs composants de modalité ou par d'autre modules (par exemple, le module de session du framework MMI).

Le composant de données peut être un module interne A au contrôleur d'interaction ou externe B (voir diagramme). Ceci dépend de l'implémentation choisie par chaque application. Toutefois le contrôleur d'interaction est le seul à avoir un accès direct au composant de données et lui seul peut consulter et modifier ses données et même communiquer avec des serveurs externes si besoin. En conséquence, les composants de modalité doivent se servir du contrôleur comme intermédiaire pour accéder aux données publiques de l'application multimodale.

En revanche, pour le stockage des données privées, chaque composant de modalité peut implémenter son propre composant de données qui lui-même peut accéder aussi à des serveurs externes B et garder les données dont le composant de modalité peut avoir besoin, par exemple, pour la tâche de reconnaissance de la parole. Ceci peut être un cas d'implémentation du principe des poupées russes de l'architecture MMI.

Protocole de communication entre les différents modules

Dans l'architecture MMI le protocole de communication est asynchrone, bi-directionnel et il est basé sur l'échange de notifications d'événements qui sont levés par le système à la suite d'une action de l’utilisateur ou par une activité interne.

Ce protocole définit le mode de communication et la façon d'établir et de terminer la communication. Dans le cas de cette recommandation, il est reflété dans les Life-Cycle Events. Ce sont des événements de contrôle de base qui sont proposés pour la commande des dispositifs et services matériels (par exemple un lecteur vidéo ou un appareil de reproduction sonore) et des notifications pour le monitoring de l'état du système multimodal.

Les événements définis dans l'architecture MMI

Les événements de base (Standard Life-Cycle Events)

La spécification propose huit Life-Cycle Events de base qui sont spécifiés sous la forme des paires d'échanges Request > Response:

Indique la création d'un cycle d'interaction (un contexte) entre zéro, un ou plusieurs utilisateur avec une modalité ou plusieurs modalités. Le contexte représente la période la plus longue d'interaction pendant laquelle les modules doivent garder l'information.
Le contexte est associé à la sémantique de l'activité de l'utilisateur et du système pendant le cycle d'interaction ; ceci permet de décider si garder l'information a encore un sens en vue du déroulement de l'activité courante.
Généralement le contexte est créé à partir d'une entrée utilisateur. L'évènement est normalement envoyé par un ou plusieurs composants de modalité au contrôleur d'interaction qui devrait répondre à la requête.
Imaginons par exemple, un composant de modalité chargé de gérer les entrées associées au déplacement du doigt (touchmove) dans une page web lue sur un écran tactile. Lors du démarrage de l'interaction le composant de modalité enverra la requête :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:newContextRequest requestID="myReq1" source="myPointerMC.php" target="myIM.php" data="myMCStatus.xml" />
</mmi:mmi>
À cette requête le contrôleur d'interaction donnera comme réponse :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:newContextResponse requestID="myReq1" source="myIM.php" target="myPointerMC.php" context="myContextID1" status="success" />
</mmi:mmi>
Il est aussi possible que le contrôleur d'interaction soit à l'origine de la requête. Dans ce cas la syntaxe reste la même mais la valeur des propriétés source et target doit changer.
Envoyé par le contrôleur d'interaction, l'évènement indique la fin du cycle d'interaction (le contexte) et demande la libération des ressources qui étaient allouées au contexte d'interaction courant. L'évènement ClearContext peut être associé à la fin de l'activité de l'utilisateur ou du système. Par exemple :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:clearContextRequest requestID="myReq2" source="myPointerMC.php" target="myIM.php" context="myContextID1" />
</mmi:mmi>
Lors de la réception de la requête le composant de modalité peut donner comme réponse :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:clearContextResponse requestID="myReq2" source="myPointerMC.php" target="myIM.php" context="myContextID1" status="success" />
</mmi:mmi>
Envoyé par le contrôleur d'interaction cet événement de contrôle signale au composant de modalité qu'il doit se préparer pour le démarrage de sa tâche et qu'il peut charger les données qui seront nécessaires à l'exécution de la même. Par exemple :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0" xmlns:svg="http://www.w3.org/2000/svg">
   <mmi:prepareRequest requestID="myReq3" source="myIM.php" target="myDisplayMC.php" context="myContextID2" >
       <mmi:content>
           <svg:svg width="100%" height="100%" version="1.1">
              <rect width="300" height="100" style="fill:rgb(0,0,255);stroke-width:1; stroke:rgb(0,0,0)"/>
           </svg:svg> 
       </mmi:content>
   </mmi:prepareRequest>
</mmi:mmi>
S'il y a plusieurs documents ou données à charger lors de la phase de préparation, le contrôleur d'interaction pourrait déclencher plusieurs fois l'évènement PrepareRequest sans pour autant démarrer la tâche après chaque envoi. Néanmoins, à chaque envoi il devra recevoir une réponse. Dans notre exemple, si le contenu a été correctement préchargé la réponse est :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:prepareResponse requestID="myReq3" source="myDisplayMC.php" target="myIM.php" status="success" context="myContextID2">
    </mmi:prepareResponse>
</mmi:mmi>
Envoyé par le contrôleur d'interaction cet événement de contrôle signale au composant de modalité qu'il peut démarrer sa tâche. Par exemple :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:startRequest requestID="myReq4" source="myIM.php" target="myPlayerMC.php" context="myContextID3" data="myPlayerParams.xml">
        <mmi:contentURL href="myAnimation.swf"/>
    </mmi:startRequest>
</mmi:mmi>
Si pendant l'exécution de sa tâche le composant de modalité reçoit un nouvel évènement StartRequest il peut, soit démarrer au nouveau sa tâche, soit signaler l'échec. Dans le cas d'une exécution réussie la réponse doit être :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:startResponse requestID="myReq4" source="myPlayerMC.php" target="myIM.php" status="success" context="myContextID3">
    </mmi:startResponse>
</mmi:mmi>
Dans le cas d'un échec la réponse peut être, par exemple :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:startResponse requestID="myReq4" source="myPlayerMC.php" target="myIM.php" status="failure" context="myContextID3">
         <mmi:statusInfo>
         NoContent
         </mmi:statusInfo>
    </mmi:startResponse>
</mmi:mmi>
Envoyé par le contrôleur d'interaction, cet événement de contrôle signale au composant de modalité qu'il doit arrêter le processus en cours. Par exemple :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
    <mmi:cancelRequest requestID="myReq5" source="myIM.php" target="mySpokerMC.php" context="myContextID4" Immediate="true"/>
</mmi:mmi>
La réponse du composant de modalité peut être :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:cancelResponse requestID="myReq5" source="mySpokerMC.php" target="myIM.php" context="myContextID4" status="success" data="myMCStatus.xml"/>
</mmi:mmi>
Envoyé par le contrôleur d'interaction, cet événement de contrôle signale au composant de modalité qu'il doit mettre en pause le processus en cours. Par exemple, la requête pour une composant qui gère les entrées d'une tablette graphique peut être :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:pauseRequest requestID="myReq6" source="myIM.php" target="myWriterMC.php" context="myContextID5" immediate="false"/>
</mmi:mmi>
Et la réponse du composant de modalité peut être :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:pauseResponse requestID="myReq6" source="myWriterMC.php" target="myIM.php" context="myContextID5" status="success" data="myMCStatus.xml"/>
</mmi:mmi>
Envoyé par le contrôleur d'interaction, cet événement de contrôle signale au composant de modalité qu'il doit reprendre la tâche précédemment mise en pause par un évènement Pause.
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:resumeRequest requestID="myReq7" source="myIM.php" target="myWriterMC.php" context="myContextID5"/>
</mmi:mmi>
La réponse du composant de modalité peut être :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:resumeResponse requestID="myReq7" source="myWriterMC.php" target="myIM.php" context="myContextID5" status="success"/>
</mmi:mmi>
Il est envoyé indifféremment par le contrôleur d'interaction ou par les composants de modalité. Cet événement indique si le cycle d'interaction est encore en cours, c'est-à-dire, si le contexte est "en vie". Par exemple, un composant de modalité peut avoir besoin de surveiller l'état du système pour arrêter un processus en cas de faille ou mise en veille du système. Dans ce cas, il peut envoyer cette requête au contrôleur d'interaction :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:statusRequest requestID="myReq8" source="myRecorderMC.php" target="myIM.php" requestAutomaticUpdate="true" />
</mmi:mmi>
Étant donné que la requête n'indique pas le paramètre context, le contrôleur d'interaction doit fournir l'état du système ou du serveur hôte et pas du contexte courant d'interaction. À cette requête le contrôleur d'interaction peut donc donner comme réponse :
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:statusResponse requestID="myReq8" source="myIM.php" target="myRecorderMC.php" status="alive" AutomaticUpdate="true" />
</mmi:mmi>

Les notifications

La spécification propose aussi deux types de notifications dont une, l'Extension Notification, peut contenir des données de contrôle ou de commande des dispositifs ou services matériaux et pour cette raison cette notification est considérée comme un évènement de base qui exceptionnellement n'est pas décrit comme une paire Request > Response (dans des versions précédentes il était appelé l'évènement data). Ces deux notifications sont:

Cet évènement est utilisé pour communiquer des données de contrôle spécifiques à chaque application. Il peut être généré par le contrôleur d'interaction ou par l'un des composants de modalité indifféremment. Il assure l'extensibilité de l'architecture, dans le sens de donner une API générique dédié aux besoins propres des applications. Par exemple, un composant de modalité qui gère un lecteur DVD peut indiquer au système l'interaction avec le menu principal:
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:extensionNotification requestID="myReq9" source="myPlayerMC.php" target="myIM.php" context="myContextID6" name="playerNavigation">
     <applicationdata> 
         <data id="menu" selected="true" />
     </applicationdata>
     </mmi:extensionNotification>
</mmi:mmi>
Cette notification est envoyée par le composant de modalité au contrôleur d'interaction dès qu'il a fini sa tâche. Par exemple, lorsqu'un composant de modalité a fini sa reconnaissance d'image (un visage):
<mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0">
     <mmi:doneNotification requestID="myReq10" source="myDetectorMC.php" target="myIM.php" context="myContextID7" status="success">
         <mmi:data>
           <data id="detectionList">
               <users>
                   <user id="u58" confidence=".85" />
                   <user id="u32" confidence=".75" />
                   <user id="u87" confidence=".60" />
               </users>
           </data>
         </mmi:data>
     </mmi:doneNotification>
</mmi:mmi>

Références

  1. (en) Dave RAGGETT, Max FROUMENTIN et Philipp HOSCHKA, « Towards Multimodal Web Interaction », Building the Information Society, Springer Boston, vol. 156,‎ , p. 5 (lire en ligne)
  2. (en) James A. LARSON, « Standard Languages for Developing Multimodal Applications », Larson Technical Services, (consulté le )
  3. (en) (en) Gerald MCCOBB, « The W3C Multimodal Architecture, Part 1: Overview and challenges. What you should know about the emerging architecture for distributed multimodal applications », IBM, (consulté le )
  4. (en) Patrizia GRIFONI, Multimodal Human Computer Interaction and Pervasive Services, IGI Global, , 538 p. (ISBN 978-1-60566-386-9 et 1-60566-386-7)
  5. (en) Deborah DAHL, « Distributed Multimodality in the W3C Multimodal Architecture », Conversational Technologies, (consulté le )

Références Externes

Standards et notes du W3C associés à cette recommandation

MMIF: Multimodal Interaction Framework (en) par James A. Larson, T.V. Raman and Dave Raggett, Ed., W3C, 2003. Cette note du W3C propose un framework qui identifie de manière abstraite les principaux composants d'un système multimodal. Ce framework est une base pour développer des applications multimodales en termes de langage de description à utiliser, les scripts, les styles et d'autres ressources utiles.

SCXML: State Chart XML. A State Machine Notation for Control Abstraction (en) par Jim Barnett et al. Ed. W3C, 2006. C'est un langage de machine à états à usage général basé sur des événements. Il peut être utilisé : comme un langage de contrôle de dialogue invoquant différents types de reconnaissance ; comme un métalangage d'application vocale qui peut également contrôler l'accès à des bases de données et des modules de logique métier; comme un langage de contrôle multimodal combinant les dialogues VoiceXML avec des dialogues dans d'autres modalités, y compris le clavier, la souris, l'encre, la vision, les dispositifs haptiques, etc; comme un langage de gestion de centre d'appels étendu et finalement comme langue de contrôle de processus généraux dans d'autres contextes ne comportant pas de traitement de la parole.

CCXML: Voice Browser Call Control Version 1.0 (en) par R.J. Auburn Ed., W3C, 2005. CCXML permet de contrôler les appels vocaux dans des systèmes de dialogue capables de gèrer divers médias comme c'est le cas des systèmes utilisant VoiceXML.

EMMA: Extensible Multimodal Annotation markup language (en) par Michael Johnson et al. Ed., W3C, 2005. Format XML pour annoter l'interprétation des entrées utilisateur avec des informations spécifiques à chaque application telles que le taux de confiance, l'horodatage, la modalité d'entrée et les hypothèses utiles pour la reconnaissance des données saisies.

MMIUse: Multimodal Interaction Use Cases (en) par Emily Candell et Dave Raggett, Ed., W3C, 2002. Cette Note du W3C décrit plusieurs cas d'utilisation pour l'interaction multimodale et les présente en termes de capacités de l'appareil variables et les événements nécessaires à chaque cas d'utilisation de coupler les différentes composantes d'une application multimodale dans laquelle il est possible d'interagir avec de multiples modalités, par exemple, en utilisant la parole, l'écriture, des raccourcis, des commandes vocales et avoir une sortie sonore et visuelle en retour.

SMIL: Synchronized Multimedia Integration Language Version 2.1 (en) par Dick Bulterman et al. Ed. W3C, 2005. Langage qui permet d'écrire des présentations multimédias interactives en décrivant le comportement temporel de la présentation, en associant des liens hypertextes aux médias et en décrivant la disposition de la présentation sur l'écran. Il apporte aussi de la temporisation et de la synchronisation à d'autres langages qui en ont besoin.

VoiceXML: Voice Extensible Markup Language Version 2.0 (en) par Scott McGlashan et al. Ed., W3C, 2004. Il permet de créer des pages avec lesquelles on interagit avec la voix et le son. Il permet la création de dialogues entre l'utilisateur et la page web avec une voix synthétisée, un signal sonore numérisé, une entrée vocale ou une tonalité DTMF.

HTML: HyperText Markup Language Version 4.01 (en) par Raggett et al. Ed., W3C, 1999. Il permet de décrire la présentation et le texte des pages web et d'inclure dans les pages des liens vers des textes complémentaires; des ressources média (images, vidéo, sons) et des ressources média interactifs (formulaires, animations interactives, univers 3D). Cette description est faite avec des balises écrites selon un code structuré et peut être complétée par des informations de style graphique (CSS) ou par une programmation de l'interaction par script (ECMAScript)

SVG: Scalable Vector Graphics 1.1 (en) par Jon Ferraiolo et al. Ed., W3C, 1995. SVG est un format de fichier qui permet de décrire des ensembles de graphiques vectoriels adaptables.

XMLSig: XML-SignatureSyntax and Processing (en) par Eastlake et al. Ed., W3C, 2001. Permet d'authentifier l'auteur de la page et de garantir son intégrité grâce à la signature numérique des documents XML.

Autres standards associés à cette recommandation

Références académiques

Autres références utiles

Éditeurs

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.