La recomendación de Arquitectura e Interfaces Multimodales introduce una estructura genérica y un protocolo de comunicación para permitir que los módulos de un sistema multimodal se comuniquen entre sí.
Esta especificación propone una arquitectura basada en eventos como marco de referencia general enfocado en el intercambio de datos del flujo de control . Puede utilizarse para determinar las infraestructuras básicas necesarias para comandar los servicios multimodales de la aplicación.
La arquitectura también se propone para facilitar la tarea de implementar varios tipos de proveedores de servicios multimodales en múltiples dispositivos: dispositivos móviles y teléfonos celulares, electrodomésticos , objetos de Internet de las cosas , redes de televisión y del hogar, aplicaciones empresariales, aplicaciones web, [1] automóviles "inteligentes" o en dispositivos y aplicaciones médicas.
Estructura lógica
La arquitectura MMI en el marco de ejecución MMI
La arquitectura multimodal y sus interfaces es la descripción específica de una infraestructura de servicios más amplia denominada marco de ejecución que proporciona las principales funciones que puede necesitar un sistema multimodal. Este marco se encuentra en un nivel de abstracción más alto que la arquitectura MMI. [2] El marco de ejecución MMI son los módulos de soporte y comunicación en tiempo de ejecución del sistema multimodal, mientras que la arquitectura MMI es la descripción y especificación de sus módulos principales, sus interfaces y sus modos de comunicación.
El patrón de diseño MVC en la arquitectura MMI
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]
Recursión en la arquitectura MMI
Una particularidad de esta arquitectura es que si bien la capa de presentación representada por la Vista ha sido tradicionalmente asociada a 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 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 comunican con un Gestor de Interacción de nivel superior. De esta manera, la arquitectura sigue el principio de muñecas anidadas . [5]
La especificación también cubre las cuestiones de una implementación distribuida sobre múltiples recursos materiales en una red o una implementación centralizada , con todos los módulos instalados en un único soporte material. El intercambio de información entre módulos está acoplado de forma flexible . Esto promueve una baja dependencia entre módulos, reduciendo el impacto de los cambios en un módulo sobre otros módulos y facilitando la reutilización de los módulos. De esta manera, los módulos tienen poco o ningún conocimiento del funcionamiento de cualquier otro módulo y la comunicación entre módulos se realiza mediante el intercambio de mensajes siguiendo un protocolo de comunicación preciso proporcionado por la API de la arquitectura . [6]
Los módulos de arquitectura MMI
Módulos de arquitectura MMI
El gestor de interacciones
El gestor de interacciones es un componente lógico, responsable de todos los intercambios de mensajes entre los componentes del sistema y el Runtime Framework multimodal. Es un bus de comunicación y también un gestor de eventos .
Cada aplicación puede configurar al menos un Interaction Manager 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 desencadenados por los eventos intercambiados entre los distintos componentes de entrada y salida.
Gestiona la comunicación con cualquier otra entidad ajena al sistema.
Los componentes de la modalidad
Los componentes de modalidad son responsables de tareas específicas, incluido el manejo de entradas y salidas de diversas maneras, como habla, escritura, video, 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, (ver figura siguiente), un componente de modalidad A puede encargarse al mismo tiempo del reconocimiento de voz y de la gestión de la entrada de audio. Otro componente de modalidad B puede gestionar las entradas de comandos complementarios en dos dispositivos diferentes: una tableta gráfica y un micrófono. Dos componentes de modalidad C , pueden gestionar por separado dos entradas complementarias dadas por un único dispositivo: una videocámara. Y finalmente, un componente de modalidad D , puede utilizar un servicio web de reconocimiento externo y solo ser responsable del control de los intercambios de comunicación necesarios para la tarea de reconocimiento.
Abstracción de entrada en los componentes de modalidad
En los cuatro casos, el sistema tiene un componente de modalidad genérico para la detección de una entrada de comando de voz, a pesar de las diferencias en la implementación. Cualquier componente de modalidad puede potencialmente incluir múltiples características proporcionadas por múltiples dispositivos físicos, pero también se podría incluir más de un componente de modalidad en un solo dispositivo. En este sentido, el componente de modalidad es una abstracción del mismo tipo de entrada manejada e implementada de manera diferente en cada caso.
Por este motivo, la recomendación del W3C actualmente no describe en detalle la estructura o implementación de los componentes de modalidad, sino que se centra únicamente en la necesidad de una interfaz de comunicación con el Gestor de Interacción y en la necesidad de una implementación que siga un protocolo de comunicación específico : los Eventos del Ciclo de Vida.
Componente de datos públicos y privados
El componente de datos
La función principal del componente de datos es guardar los datos públicos de la aplicación que puedan requerirse por uno o varios componentes de modalidad o por 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 al Interaction Manager (ver Figura). Esto depende de la implementación elegida por cada aplicación. Sin embargo, el Interaction Manager es el único módulo que tiene acceso directo al Componente de Datos y sólo el Interaction Manager puede ver y editar los datos y comunicarse con servidores externos en caso de ser necesario. Como resultado, los Componentes de Modalidad deben utilizar el Interaction Manager 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 (ver Figura) y guardar los datos que el Componente de Modalidad pueda requerir, por ejemplo, en la tarea de reconocimiento de voz. Este puede ser el caso de una implementación siguiendo el principio de muñecas anidadas dado por la recomendación de arquitectura MMI.
Protocolo de comunicación entre diferentes módulos
Este protocolo define el modo de intercambio y cómo establecer y finalizar la comunicación entre módulos. En el caso de esta especificación, se refleja en los Eventos del Ciclo de Vida. Se trata de seis eventos de control estándar que se proponen para controlar dispositivos y servicios materiales (como un reproductor de vídeo o un dispositivo de reproducción de sonido) y dos notificaciones propuestas para monitorizar el estado actual del sistema multimodal.
Los eventos del ciclo de vida de MMI
Los eventos estándar del ciclo de vida
La especificación recomienda ocho eventos de ciclo de vida estándar especificados como pares de intercambios de Solicitud > Respuesta:
Indica la creación de un ciclo de interacción (contexto) entre cero, uno o más usuarios con uno o múltiples componentes de modalidad. El contexto es el período más largo de interacción en el que los módulos deben mantener disponible la información.
El contexto está asociado a 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 mantener la información aún tiene sentido para la ejecución de la actividad actual.
Generalmente, el contexto se crea a partir de la entrada del usuario. El evento normalmente lo envían uno o más componentes de modalidad al administrador de interacción que debe responder la consulta.
Por ejemplo, un componente de modalidad encargado de gestionar las entradas asociadas al gesto del dedo (touchmove) en una página web visualizada en una pantalla táctil. Al comienzo de la interacción física, el componente de modalidad enviará la consulta:
También es posible que el Interaction Manager esté en el origen de la solicitud. En este caso, la sintaxis sigue siendo la misma, pero el valor de las propiedades de origen y destino debe cambiar.
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 estaban asignados 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:
Enviado por el administrador de interacción, este control de evento le indica al componente de modalidad que debe estar preparado para iniciar su tarea y que puede cargar los datos que serán necesarios para realizar su trabajo. Por ejemplo:
Si hay varios documentos o datos que se deben cargar durante la fase de preparación, el Interaction Manager 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:
Si durante la ejecución de su trabajo el Componente Modalidad recibe un nuevo evento StartRequest puede iniciar la nueva tarea o informar del fallo. En caso de ejecución exitosa la respuesta debe ser:
Este evento de control, enviado por el administrador de interacciones, indica al componente de modalidad que debe detener su tarea actual. Por ejemplo:
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 administra la entrada de una tableta gráfica puede ser:
Enviado por el Administrador de interacción, este evento de control indica al Componente de modalidad que la tarea previamente pausada debe reanudarse:
Es enviado por el Gestor de Interacción o por los Componentes de Modalidad. Este evento indica si el ciclo de interacción sigue en marcha, es decir, si el contexto está "vivo". Por ejemplo, un Componente de Modalidad puede necesitar monitorear el estado del sistema para detener un proceso en caso de falla o suspensión. En este caso, puede enviar al Gestor de Interacción:
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 interacciones puede responder:
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 manejar dispositivos o servicios 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 llamaba Evento de Datos). Las dos notificaciones son:
Extensión (ExtensionNotification)
Este evento se utiliza para comunicar datos de control específicos de la aplicación o cualquier otro dato necesario. Puede generarse mediante el administrador de interacciones o mediante 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 maneja un reproductor de DVD puede indicar al sistema una interacción con el menú principal del DVD:
El componente de modalidad envía esta notificación al administrador de interacciones cuando ha finalizado su tarea. Por ejemplo, cuando un componente de modalidad reconocedor ha finalizado la tarea de reconocimiento de imágenes (encontrar un rostro):
^ RAGGETT, Dave.; FROUMENTIN, Max.; HOSCHKA, Philipp. (2004). "Hacia la interacción web multimodal". Construyendo la sociedad de la información . IFIP Federación Internacional para el Procesamiento de la Información. Vol. 156. Springer Boston. págs. 133–138. doi : 10.1007/978-1-4020-8157-6_37 . ISBN .978-1-4020-8156-9.
^ James A. LARSON (22 de febrero de 2005). "Lenguajes estándar para el desarrollo de aplicaciones multimodales" (PDF) . Larson Technical Services . Consultado el 20 de agosto de 2011 .
^ Gerald MCCOBB (8 de mayo de 2007). "La arquitectura multimodal del W3C, parte 1: descripción general y desafíos. Lo que debe saber sobre la arquitectura emergente para aplicaciones multimodales distribuidas". IBM . Consultado el 20 de agosto de 2011 .
^ VBWG (8 de febrero de 2006). "The Voice Browser DFP Framework". w3.org . Consultado el 11 de enero de 2011 .
^ GRIFONI, Patrizia (2009). Interacción multimodal entre humanos y computadoras y servicios generalizados . IGI Global. p. 538. ISBN978-1-60566-386-9.
^ Deborah DAHL (26 de abril de 2010). "Multimodalidad distribuida en la arquitectura multimodal del W3C" (PDF) . Tecnologías conversacionales . Consultado el 20 de agosto de 2011 .
Enlaces externos
Normas y notas del W3C
MMIF: Multimodal Interaction Framework (Marco de interacción multimodal) de James A. Larson, TV Raman y Dave Raggett, Ed., W3C, 2003. Esta nota del W3C propone un marco que describe los principales componentes genéricos de un sistema multimodal. Este marco es una base para el desarrollo de aplicaciones multimodales, sugiere qué lenguaje utilizar, qué scripts, qué estilos y otros recursos útiles.
SCXML: State Chart XML. A State Machine Notation for Control Abstraction por Jim Barnett et al. Ed. W3C, 2006. SCXML es un lenguaje de máquina de estados para uso general y basado en eventos. Puede utilizarse: como lenguaje de control de diálogos invocando 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 de negocios, como lenguaje de control multimodal que combina diálogos VoiceXML con otras modalidades, incluyendo teclado, mouse, tinta, visión, dispositivos hápticos, etc.; como lenguaje de gestión para call centers extendidos y finalmente como lenguaje de control para procesos generales en otros contextos que no involucran procesamiento de voz.
CCXML: Control de llamadas de voz del navegador Versión 1.0 de 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: Extensible Multimodal Annotation markup language (lenguaje de marcado de anotación multimodal extensible) de Michael Johnson y col., Ed., 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: Multimodal Interaction Use Cases (Casos de uso de interacción multimodal) por Emily Candell y Dave Raggett, Ed., 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 múltiples dispositivos y los eventos requeridos para cada caso de uso. Ayuda a ensamblar los diversos componentes de una aplicación multimodal en la que un usuario puede interactuar con múltiples modalidades, por ejemplo, usando el habla, la escritura, atajos, comandos de voz para obtener un resultado de salida de audio o visual.
SMIL: Synchronized Multimedia Integration Language Versión 2.1 de Dick Bulterman y otros. Ed. W3C, 2005. SMIL es un lenguaje que permite escribir presentaciones multimedia interactivas que describen el comportamiento temporal de la presentación, mediante la combinación de enlaces a los medios que describen la disposición de la presentación en la pantalla. También proporciona sincronización y temporización a otros lenguajes que lo puedan necesitar.
VoiceXML: Voice Extensible Markup Language Versión 2.0 de Scott McGlashan y otros. Ed., W3C, 2004. Permite crear páginas con las que un usuario puede interactuar con su voz o cualquier sonido. Permite, además, la creación de un diálogo entre el usuario y una página web con una voz sintetizada, una señal de audio digitalizada, una entrada de voz o un tono DTMF .
HTML: HyperText Markup Language Versión 4.01 de Raggett y col. Ed., W3C, 1999. Se utiliza para describir la presentación y el texto de páginas web e incluir en las páginas de enlaces a textos adicionales, recursos multimedia (imágenes, vídeo, sonido) y recursos multimedia interactivos (formularios, animaciones, universo interactivo 3D). Esta descripción se realiza con etiquetas escritas en un código estructurado y puede completarse con información sobre un estilo gráfico determinado ( CSS ) o una interacción programada mediante un script ( ECMAScript ).
SVG: Scalable Vector Graphics 1.1 de Jon Ferraiolo y otros. Ed., W3C, 1995. SVG es un formato de archivo para describir gráficos vectoriales adaptables .
XMLSig: XML-SignatureSyntax and Processing de Eastlake y otros. Ed., W3C, 2001. Se utiliza para autenticar al autor de la página web y asegurar su integridad a través de firmas digitales en documentos XML.
Otras normas
RFC 7230: Sintaxis y enrutamiento de mensajes HTTP/1.1. IETF, 2014.
RFC 2119: Palabras clave para usar en RFC para indicar niveles de requisitos en IETF, 1997.
RFC 2396: Identificadores uniformes de recursos en IETF, 1995.
Referencias académicas
Interacción multimodal en computación distribuida y ubicua por Pous, M. et Ceccaroni, L, Internet and Web Applications and Services (ICIW), 2010 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 2010, 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, Nelson Mandela Metropolitan University, Puerto Elizabeth, Sudáfrica, 2007.
Proporcionar servicios multimodales sensibles al contexto a usuarios móviles por Ardit, C et al., Evento Nacional sobre Guías Móviles Virtuales, Turín, Italia, 2006.
Documentos presentados en el Taller sobre arquitectura e interfaces multimodales del W3C, 19 y 20 de julio de 2004. Sophia Antipolis, Francia
Entrada de datos de campo móvil para información de control de calidad del hormigón por Irina KONDRATOVA en Actas de la Conferencia Europea sobre Modelado de Productos y Procesos (ECPPM 2004). Número de publicación NRC: NRC 47158.
Campo de golf
El W3C redacta un nuevo estándar multimodal por Leonard Klie, speechtechmag, 17 de febrero de 2009.
Taller sobre arquitectura e interfaces multimodales del W3C, 16 y 17 de noviembre de 2007. Universidad de Keio, Japón.
La arquitectura multimodal del W3C, parte 2: la pila de especificaciones XML. Creación 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. Introducción automática de 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 simples 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 usuarios. Autenticación segura de usuarios con interacción visual y de voz, 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.
W3C lidera un nuevo proyecto europeo: Web Multimodal Ercim News, 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 por Paolo Baggia. VoiceXML Italian User Group, julio de 2003.
