Multimodal Architecture and Interfaces

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]^]

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é 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 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.

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

• NewContext (NewContextRequest / NewContextResponse)

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.

• ClearContext (ClearContextRequest / ClearContextResponse)

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>

• Prepare (PrepareRequest / PrepareResponse)

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>

• Start (StartRequest / StartResponse)

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>

• Cancel (CancelRequest / CancelResponse)

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>

• Pause (PauseRequest / PauseResponse)

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>

• Resume (ResumeRequest / ResumeResponse)

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>

• Status (StatusRequest / StatusResponse)

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>

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:

• Extension (ExtensionNotification)

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>

• Done (DoneNotification)

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>

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.

• RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1 in R. Fielding et al. editors. IETF, 1999.
• RFC 2119: Key words for use in RFCs to Indicate Requirement Levels in IETF, 1997.
• RFC 2396: Uniform Resource Identifiers in IETF, 1995.

• Multimodal Interaction in Distributed and Ubiquitous Computing (en) par Pous, M. et Ceccaroni, L, Internet and Web Applications and Services (ICIW), 2010 Fifth International Conference on, Barcelone, Espagne, 2010.
• A Multimodal Interaction Manager for Device Independent Mobile Applications (en) par Wegscheider, F. et al., Internet and Web Applications and Services (ICIW), 2010 Fifth International Conference on, Barcelone, Espagne, 2010.
• (en) Adrian STANCIULESCU, A Methodology for Developing Multimodal User Interfaces of Information Systems, Presses universitaires de Louvain, 2008, 318 p. (ISBN 978-2-87463-114-6 et 2-87463-114-0, lire en ligne)
• « A Model for Adaptive Multimodal Mobile Notification »^{(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)} (consulté en 20130318) (en) par William Brander, Nelson Mandela Metropolitan University, Port Elizabeth, Afrique du Sud, 2007.
• Providing multimodal context-sensitive services to mobile users (en) par Ardit, C et al., National Event on Virtual Mobile Guides, Turin, Italie, 2006.
• Articles présentés dans le Workshop W3C autour de l'Multimodal Architecture and Interfaces du 19-20 juillet 2004. Sophia Antipolis, France (en)
• Mobile Field Data Entry for Concrete Quality Control Information par Irina KONDRATOVA dans Proceedings of the European Conference on Products and Processes Modelling (ECPPM 2004). NRC Publication Number: NRC 47158.

• W3C Drafts New Multimodal Standard (en) par Leonard Klie, speechtechmag, 17 fév. 2009.
• Workshop W3C autour de l'Multimodal Architecture and Interfaces du 16-17 novembre 2007. Keio University, Japon.
• The W3C Multimodal Architecture, Part 2: The XML specification stack. Multimodal authoring with SCXML, XHTML, REX, and more (en) par Gerald MCCOBB, IBM, 31 mai 2007.
• Multimodal interaction and the mobile Web, Part 1: Multimodal auto-fill. Automatically enter personal information into forms (en) par Gerald MCCOBB, IBM, 15 novembre 2005.
• Multimodal interaction and the mobile Web, Part 2: Simple searches with Find-It How to enable voice access to the Yahoo! local search engine (en) par Gerald MCCOBB, IBM, 6 décembre 2005.
• Multimodal interaction and the mobile Web, Part 3: User authentication. Secure user authentication with voice and visual interaction (en) par Gerald MCCOBB, IBM, 10 janvier 2006.
• Distributed Multimodal Synchronization Protocol (DMSP) (en) par Chris Cross With Contribution from Gerald McCobb and Les Wilson, IBM Corporation, 13 juillet 2006.
• W3C leads a New European Project: Multimodal Web (en) Ercim News, 2004.
• Multimodal interaction promises device integration, accessibility, and enhanced communication services (en) Techrepublic, 2003.
• Interview to Dr. Deborah Dahl (en) par Paolo Baggia. VoiceXML Italian User Group, juillet 2003.

• (en) Multimodal Interaction Activity
• (en) Multimodal Interaction Activity dans le site du W3C