Arquitectura e interfaces multimodales

La arquitectura e interfaces multimodales ( MMI ) es la descripción específica de una infraestructura de servicios más amplia denominada Marco de Ejecución (Runtime Framework) , que proporciona las funciones principales que un sistema multimodal puede necesitar. Este marco se encuentra en un nivel de abstracción superior al de la arquitectura MMI. ^{[ 2 ]} El Marco de Ejecución MMI comprende los módulos de soporte y comunicación en tiempo de ejecución del sistema multimodal, mientras que la arquitectura MMI describe y especifica sus módulos principales, sus interfaces y sus modos de comunicación.

La especificación de Arquitectura e Interfaces Multimodales se basa en el patrón de diseño MVC , que propone organizar la estructura de la interfaz de usuario en tres partes: el Modelo , la Vista y el Controlador . ^{[ 3 ]} Este patrón de diseño también se muestra en la arquitectura Data-Flow-Presentation del Voice Browser Working Group. ^{[ 4 ]}

Una particularidad de esta arquitectura es que, si bien la capa de presentación representada por la Vista se ha asociado tradicionalmente con interfaces gráficas , esta abstracción de recomendación generaliza la Vista al contexto más amplio de la interacción multimodal , donde el usuario puede utilizar una combinación de modalidades visuales, auditivas, biométricas y/o táctiles.

La recomendación de la arquitectura MMI distingue tres tipos de componentes: el Gestor de Interacción (IM), el Componente de Datos (DC) y los Componentes de Modalidad (MC). Esta distinción es similar a la separación entre el Controlador , el Modelo y los documentos de presentación de la Vista en el patrón MVC.

Otra característica es la recursión . Los módulos son cajas negras y es posible encapsular varios componentes en un componente más complejo, que se comunica con un gestor de interacción de nivel superior. De esta forma, la arquitectura sigue el principio de muñecas anidadas . ^{[ 5 ]}

La especificación también abarca los aspectos de una implementación distribuida en múltiples recursos de material en una red o una implementación centralizada , con todos los módulos instalados en un único soporte de material. El intercambio de información entre módulos está débilmente acoplado . Esto promueve una baja dependencia entre módulos, reduciendo el impacto de los cambios en un módulo sobre otros módulos y facilitando su reutilización. De esta manera, los módulos tienen poco o ningún conocimiento del funcionamiento de otros módulos y la comunicación entre ellos se realiza mediante el intercambio de mensajes siguiendo un protocolo de comunicación preciso proporcionado por la API de la arquitectura . ^{[ 6 ]}

El gestor de interacciones es un componente lógico responsable de todos los intercambios de mensajes entre los componentes del sistema y el marco de ejecución multimodal . Es un bus de comunicación y también un gestor de eventos .

Cada aplicación puede configurar al menos un Gestor de Interacción para definir la lógica de interacción requerida. Este controlador es el núcleo de la interacción multimodal:

• Gestiona los comportamientos específicos que se desencadenan por los eventos que se intercambian entre los distintos componentes de entrada y salida.
• Gestiona la comunicación entre los módulos y la aplicación cliente .
• Garantiza la coherencia entre las distintas entradas y salidas, y proporciona una percepción general del estado actual de la aplicación.
• Es responsable de la sincronización de datos.
• Es responsable de la gestión del enfoque .
• Gestiona la comunicación con cualquier otra entidad externa al sistema.

Los componentes de la modalidad son responsables de tareas específicas, incluido el manejo de entradas y salidas de diversas maneras, como voz, escritura, vídeo, etc.

Se trata de entidades lógicas que gestionan la entrada y salida de diferentes dispositivos de hardware (micrófono, tableta gráfica, teclado) y servicios de software (detección de movimiento, cambios biométricos) asociados al sistema multimodal. Por ejemplo (véase la figura a continuación), un componente de modalidad A puede gestionar simultáneamente el reconocimiento de voz y la entrada de audio. Otro componente de modalidad B puede gestionar las entradas de comandos complementarias en dos dispositivos diferentes: una tableta gráfica y un micrófono. Dos componentes de modalidad C pueden gestionar por separado dos entradas complementarias proporcionadas por un único dispositivo: una videocámara . Finalmente, un componente de modalidad D puede utilizar un servicio web de reconocimiento externo y ser responsable únicamente del control de los intercambios de comunicación necesarios para la tarea de reconocimiento.

En los cuatro casos, el sistema cuenta con un componente de modalidad genérico para la detección de comandos de voz, a pesar de las diferencias en la implementación. Cualquier componente de modalidad puede integrar múltiples funciones proporcionadas por diversos dispositivos físicos, e incluso un solo dispositivo podría incluir más de un componente de modalidad. En este sentido, el componente de modalidad es una abstracción del mismo tipo de entrada, gestionada e implementada de forma diferente en cada caso.

Por este motivo, la recomendación del W3C actualmente no describe en detalle la estructura ni la implementación de los componentes de la modalidad. Se centra únicamente en la necesidad de una interfaz de comunicación con el Gestor de Interacciones y en la necesidad de una implementación que siga un protocolo de comunicación específico : los Eventos del Ciclo de Vida .

La función principal del componente de datos es guardar los datos públicos de la aplicación que puedan ser necesarios para uno o varios componentes de modalidad o para otros módulos (por ejemplo, el módulo de sesión del Framework ).

El componente de datos puede ser un módulo interno A o un módulo externo B del Gestor de Interacción (véase la figura). Esto depende de la implementación elegida por cada aplicación. Sin embargo, el Gestor de Interacción es el único módulo que tiene acceso directo al Componente de Datos y solo él puede visualizar y editar los datos, así como comunicarse con servidores externos si fuera necesario. Por consiguiente, los Componentes de Modalidad deben utilizar el Gestor de Interacción como intermediario para acceder a los datos públicos de la aplicación multimodal.

Sin embargo, para el almacenamiento de datos privados, cada Componente de Modalidad puede implementar su propio Componente de Datos. Este Componente de Datos privado también puede acceder a servidores externos B (véase la figura) y almacenar los datos que el Componente de Modalidad pueda necesitar, por ejemplo, en la tarea de reconocimiento de voz. Este puede ser el caso de una implementación que siga el principio de las muñecas anidadas, tal como lo recomienda la arquitectura MMI.

La especificación recomienda ocho eventos estándar del ciclo de vida especificados como pares de intercambios de solicitud > respuesta:

• NuevoContexto ( NuevaSolicitudContexto/NuevaRespuestaContexto )

Indica la creación de un ciclo de interacción (contexto) entre cero, uno o más usuarios con uno o varios componentes de modalidad. El contexto es el período de interacción más largo durante el cual los módulos deben mantener la información disponible.

El contexto se asocia con la semántica de la actividad del usuario y del sistema durante el ciclo de interacción. Esto permite a la implementación decidir si conservar la información sigue siendo relevante para la ejecución de la actividad actual.

Normalmente, el contexto se crea a partir de la información proporcionada por el usuario. El evento suele ser enviado por uno o más componentes de la modalidad al gestor de interacción, que debe responder a la consulta.

Por ejemplo, un componente de modalidad responsable de gestionar las entradas asociadas al gesto del dedo (touchmove) en una página web visualizada en una pantalla táctil. Al inicio de la interacción física, el componente de modalidad enviará la consulta:

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

Ante esta solicitud, el gestor de interacciones responderá:

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

También es posible que el Administrador de Interacciones sea el origen de la solicitud. En este caso, la sintaxis permanece igual, pero el valor de las propiedades de origen y destino debe cambiar.

• ClearContext ( ClearContextRequest / ClearContextResponse )

Enviado por el gestor de interacciones, el evento marca el final del ciclo de interacción (contexto) y solicita la liberación de los recursos que se asignaron al contexto de interacción actual. El evento ClearContext puede estar asociado con el final de la actividad del usuario o del sistema. Por ejemplo:

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

Al recibir la solicitud, el componente de modalidad puede dar como respuesta:

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

• Preparar ( PrepararSolicitud / PrepararRespuesta )

Enviado por el gestor de interacciones, este control de eventos indica al componente de modalidad que debe estar preparado para iniciar su tarea y que puede cargar los datos necesarios para realizar su trabajo. Por ejemplo:

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

Si hay varios documentos o datos que cargar durante la fase de preparación, el Administrador de interacciones podría activar el evento PrepareRequest varias veces sin iniciar la tarea después de cada solicitud. No obstante, cada llamada de solicitud debe ser respondida. En nuestro ejemplo, si el contenido se ha precargado correctamente, la respuesta es:

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

• Inicio ( InicioSolicitud/InicioRespuesta )

Este evento de control, enviado por el Administrador de Interacción, indica al Componente de Modalidad que puede comenzar su tarea. Por ejemplo:

<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 durante la ejecución de su trabajo el Componente de Modalidad recibe un nuevo evento StartRequest, puede iniciar la nueva tarea o informar del fallo. En caso de una ejecución exitosa, la respuesta debe ser:

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

En caso de fallo, la respuesta podría ser, por ejemplo:

<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> Sin contenido </mmi:statusInfo> </mmi:startResponse> </mmi:mmi>

• Cancelar ( CancelarSolicitud / CancelarRespuesta )

Enviado por el Administrador de Interacción, este evento de control indica al Componente de Modalidad que debe detener su tarea actual. Por ejemplo:

<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 respuesta del componente de modalidad puede ser:

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

• Pausa ( Solicitud de pausa/Respuesta de pausa )

Enviado por el Administrador de Interacción, este evento de control indica al Componente de Modalidad que debe pausar su tarea actual. Por ejemplo, la solicitud para un Componente de Modalidad que gestiona la entrada de una tableta gráfica puede ser:

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

Y la respuesta del Componente de Modalidad puede ser:

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

• Currículum ( Solicitud de currículum / Respuesta de currículum )

Enviado por el Administrador de Interacciones, este evento de control indica al Componente de Modalidad que la tarea previamente pausada debe reanudarse:

<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 respuesta del Componente de Modalidad puede ser:

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

• Estado ( Solicitud de estado / Respuesta de estado )

Es enviado por el Administrador de Interacción o por los Componentes de Modalidad. Este evento indica si el ciclo de interacción sigue en ejecución, es decir, si el contexto está "activo". Por ejemplo, un Componente de Modalidad puede necesitar monitorear el estado del sistema para detener un proceso en caso de falla o espera. En este caso, puede enviar al Administrador de Interacción  :

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

Dado que la solicitud no tiene el parámetro de contexto , el controlador debe devolver el estado del sistema o del servidor host y no el estado del contexto de interacción actual. A esta solicitud, el Administrador de Interacción puede responder:

<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 especificación también recomienda dos tipos de notificaciones, una de las cuales, la Notificación de Extensión, puede contener datos de control o comando para gestionar dispositivos o servicios de materiales. Por este motivo, esta notificación se considera una excepción, un evento de control estándar que no se describe como un par Solicitud > Respuesta (en una versión anterior se denominaba Evento de Datos ). Las dos notificaciones son:

• Extensión ( Notificación de extensión )

Este evento se utiliza para comunicar datos de control específicos de la aplicación o cualquier otro dato necesario. Puede ser generado tanto por el Administrador de Interacciones como por un Componente de Modalidad. Garantiza la extensibilidad de la arquitectura al proporcionar una API genérica dedicada a las necesidades específicas de la aplicación. Por ejemplo, un Componente de Modalidad que gestiona un reproductor de DVD puede indicar al sistema una interacción con el menú principal del DVD:

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

• Hecho ( Notificación de hecho )

Esta notificación la envía el Componente de Modalidad al Gestor de Interacción cuando ha finalizado su tarea. Por ejemplo, cuando un Componente de Modalidad de reconocimiento ha finalizado la tarea de reconocimiento de imágenes (detección de un rostro):

<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: Marco de Interacción Multimodal, por James A. Larson, TV Raman y Dave Raggett (eds.), W3C, 2003. Esta nota del W3C propone un marco que describe los principales componentes genéricos de un sistema multimodal. Este marco sirve de base para el desarrollo de aplicaciones multimodales, sugiriendo el lenguaje, los scripts, los estilos y otros recursos útiles.
• SCXML: XML de diagrama de estados. Una notación de máquina de estados para la abstracción de control por Jim Barnett et al. Ed. W3C, 2006. SCXML es un lenguaje de máquina de estados de uso general basado en eventos. Puede utilizarse como lenguaje de control de diálogo que invoca diferentes tipos de reconocimiento ; como metalenguaje para aplicaciones de voz que también pueden controlar el acceso a bases de datos y módulos de lógica empresarial, como un lenguaje de control multimodal que combina diálogos VoiceXML con otras modalidades, como teclado, ratón, tinta, visión, dispositivos hápticos, etc.; como lenguaje de gestión para centros de llamadas extendidos y, finalmente, como lenguaje de control para procesos generales en otros contextos que no implican procesamiento de voz.
• CCXML: Control de llamadas de voz en navegador, versión 1.0, por RJ Auburn Ed., W3C, 2005. CCXML permite el control de llamadas de voz en sistemas de diálogo. Puede manejar varios tipos de medios, por ejemplo, en sistemas que utilizan VoiceXML .
• EMMA: Lenguaje de marcado de anotación multimodal extensible, por Michael Johnson y otros (eds.), W3C, 2005. EMMA es un formato XML para marcar la interpretación de la entrada del usuario con información específica de la aplicación, como el nivel de confianza, la marca de tiempo, la modalidad de entrada y las opciones relevantes para el reconocimiento de los datos de entrada.
• MMIUse: Casos de uso de interacción multimodal, por Emily Candell y Dave Raggett (eds.), W3C, 2002. Esta nota del W3C describe varios casos de uso para la interacción multimodal y los presenta en términos de las capacidades de los diferentes dispositivos y los eventos necesarios para cada caso. Ayuda a ensamblar los diversos componentes de una aplicación multimodal en la que un usuario puede interactuar con múltiples modalidades, por ejemplo, mediante voz, escritura, atajos y comandos de voz para obtener un resultado de audio o visual.
• SMIL: Lenguaje de Integración Multimedia Sincronizada, versión 2.1, por Dick Bulterman y otros. Ed. W3C, 2005. SMIL es un lenguaje que permite crear presentaciones multimedia interactivas que describen el comportamiento temporal de la presentación, combinando enlaces a los medios que describen la disposición de la presentación en pantalla. También proporciona sincronización y control de tiempo a otros lenguajes que lo requieran.
• VoiceXML: Lenguaje de marcado extensible de voz, versión 2.0, por Scott McGlashan y otros (eds.), W3C, 2004. Permite crear páginas con las que un usuario puede interactuar mediante su voz o cualquier sonido. También permite crear un diálogo entre el usuario y una página web con voz sintetizada, señal de audio digitalizada, entrada de voz o tono DTMF .
• HTML: HyperText Markup Language versión 4.01, de Raggett et al. (eds.), W3C, 1999. Se utiliza para describir la presentación y el texto de las páginas web e incluir enlaces a textos adicionales, recursos multimedia (imágenes, vídeo, sonido) y recursos multimedia interactivos (formularios, animaciones, universos interactivos 3D). Esta descripción se realiza mediante etiquetas escritas en un código estructurado y puede complementarse con información sobre un estilo gráfico determinado ( CSS ) o una interacción programada mediante un script ( ECMAScript ).
• SVG: Gráficos vectoriales escalables 1.1 por Jon Ferraiolo y otros, eds., W3C, 1995. SVG es un formato de archivo para describir gráficos vectoriales adaptables .
• XMLSig: Sintaxis y procesamiento de firmas XML, por Eastlake et al. Ed., W3C, 2001. Se utiliza para autenticar al autor de la página web y garantizar su integridad mediante firmas digitales en documentos XML.

• RFC 7230: Sintaxis y enrutamiento de mensajes HTTP/1.1 . IETF, 2014.
• RFC 2119: Palabras clave para su uso en RFC para indicar los niveles de requisitos en IETF, 1997.
• RFC 2396: Identificadores uniformes de recursos en IETF, 1995.

• Interacción multimodal en computación distribuida y ubicua por Pous, M. y Ceccaroni, L, Internet and Web Applications and Services (ICIW), Quinta Conferencia Internacional sobre, Barcelona, ​​España, 2010.
• Un gestor de interacción multimodal para aplicaciones móviles independientes del dispositivo por Wegscheider, F. et al., Internet and Web Applications and Services (ICIW), Quinta Conferencia Internacional sobre Aplicaciones y Servicios Web, Barcelona, ​​España, 2010.
• STANCIULESCU, Adrian (2008). Una metodología para el desarrollo de interfaces de usuario multimodales de sistemas de información . Presses universitaires de Louvain. ISBN 978-2-87463-114-6.
• Un modelo para la notificación móvil multimodal adaptativa, por William Brander, Universidad Metropolitana Nelson Mandela, Port Elizabeth, Sudáfrica, 2007.
• Provisión de servicios multimodales sensibles al contexto para usuarios móviles por Ardit, C et al., Evento Nacional sobre Guías Móviles Virtuales, Turín, Italia, 2006.
• Artículos presentados en el Taller de Arquitectura e Interfaces Multimodales del W3C, 19-20 de julio de 2004. Sophia Antipolis, Francia.
• Entrada de datos de campo móviles para información de control de calidad del hormigón por Irina KONDRATOVA en las Actas de la Conferencia Europea sobre Modelado de Productos y Procesos (ECPPM 2004). Número de publicación de NRC: NRC 47158.

• El W3C elabora un nuevo estándar multimodal, por Leonard Klie, speechtechmag, 17 de febrero de 2009.
• Taller del W3C sobre Arquitectura e Interfaces Multimodales, 16-17 de noviembre de 2007. Universidad de Keio, Japón.
• Arquitectura multimodal del W3C, Parte 2: El conjunto de especificaciones XML. Creación de contenido multimodal con SCXML, XHTML, REX y más, por Gerald McCobb, IBM, 31 de mayo de 2007.
• Interacción multimodal y la web móvil, Parte 1: Autocompletado multimodal. Introduzca automáticamente información personal en formularios. Por Gerald McCobb, IBM, 15 de noviembre de 2005.
• Interacción multimodal y la web móvil, Parte 2: Búsquedas sencillas con Find-It. Cómo habilitar el acceso por voz al motor de búsqueda local de Yahoo! por Gerald MCCOBB, IBM, 6 de diciembre de 2005.
• Interacción multimodal y la web móvil, Parte 3: Autenticación de usuario. Autenticación segura de usuario con interacción por voz y visual, por Gerald McCobb, IBM, 10 de enero de 2006.
• Protocolo de sincronización multimodal distribuida (DMSP) por Chris Cross con contribuciones de Gerald McCobb y Les Wilson, IBM Corporation, 13 de julio de 2006.
• El W3C lidera un nuevo proyecto europeo: la web multimodal. Noticias de Ercim, 2004.
• La interacción multimodal promete integración de dispositivos, accesibilidad y servicios de comunicación mejorados (Techrepublic , 2003).
• Entrevista a la Dra. Deborah Dahl realizada por Paolo Baggia. Grupo de Usuarios Italianos de VoiceXML, julio de 2003.

• Grupo MMI del W3C
• Actividad de interacción multimodal
• Actividad de interacción multimodal en el sitio web del W3C