Creación de una interfaz gráfica de traducción automática para las lenguas de signos

TREBAJO FIN DE CARRERA TÍTOL DEL TFC: Creación de una interfaz gráfica de traducción automática para las lenguas de signos. TITULACIÓ: Ingeniería Técnica de Telecomunicación, especialidad Sistemas de Telecomunicación. AUTOR: Javier Marín Rey DIRECTOR: Dolors Royo SUPERVISOR: Guillem Massó (Barcelona Media) DATA: Títol: Creación de una interfaz gráfica de traducción automática para las lenguas de signos. Autor: Javier Marín Rey Director: Dolors Royo Data: Resumen Con la realización de este trabajo se pretende el desarrollo y evaluación de una plataforma gráfica para el sistema de traducción automática Moses, que permite transformar frases de una lengua a otra, en nuestro caso, de catalán a Lengua de Signos Catalana. El sistema Moses es un software de código abierto que obtiene un modelo de traducción a partir del alineamiento y extracción de subsecuencias utilizando un corpus paralelo, compuesto por documentos de texto en la lengua origen y sus equivalentes en la lengua destino. La plataforma está formado por 3 módulos principales: una aplicación cliente, una aplicación servidor y un avatar. La aplicación cliente envía un texto en catalán a la aplicación servidor, este ejecuta el sistema Moses para encontrar su traducción y busca en nuestra base de datos sus signos correspondientes codificados en formato XML mediante el sistema de notación HamNoSys para las lenguas de signos. Esta codificación es enviada al cliente para ser procesada por el avatar y ejecutar los movimientos correspondientes. Por otro lado, hemos realizado un editor de signos que nos permite crear y editar signos y ser guardados luego a la base de datos. Todas estas aplicaciones han sido creadas en lenguaje Java. Este sistema ayudará a mejorar la comunicación con las personas sordas signantes y tener el derecho de recibir la información en su lengua propia. La importancia de esta plataforma reside en la necesidad cada vez mayor de una herramienta que permita una traducción rápida y relativamente precisa entre lenguas. El proyecto ha sido desarrollado con colaboración de Barcelona Media-Centro de Innovación. Title: Creación de una interfaz gráfica de traducción automática para las lenguas de signos. Author: Javier Marín Rey Director: Dolors Royo Date: Overview With the completion of this work aims at the development and evaluation of a graphical platform for the Moses machine translation system, which transforms phrases from one language to another, in our case, Catalan Catalan Sign Language. Moses is a system open source software gets a translation model from the alignment and extraction of subsequences using a parallel corpus, consisting of text documents in the source language and their equivalents in the target language. The platform consists of 3 main modules: a client application, an application server and an avatar. The client application sends a text in Catalan to the application server which runs the system to find its translation Moses and search our database for the signs encoded in XML format by HamNoSys notation system for sign languages. This encoding is sent to the client to be processed by the avatar and run the corresponding movements. On the other hand, we made a sign editor that lets you create and edit signs and then be stored in the database. All these applications have been created in Java. This system will help improve communication with deaf signers and have the right to receive information in their own language. The importance of this platform lies in the increasing need for a tool that allows quick and relatively accurate translation between languages. The project has been developed in collaboration with Barcelona Media-Center of Innovation. ÍNDICE INTRODUCCIÓN ........................................................................................................ 1 CAPÍTULO 1. LA LENGUA DE SIGNOS ................................................................... 3 1.1. Introducción .................................................................................................................................... 3 1.2. Situación actual ............................................................................................................................... 3 1.3. Estudio lingüístico .......................................................................................................................... 4 1.4. Sistema de transcripción ............................................................................................................... 6 1.4.1. HamNoSys ............................................................................................................................. 7 1.2.2. SiGML ..................................................................................................................................... 7 CAPÍTULO 2. LA TRADUCCIÓN AUTOMÁTICA ...................................................... 9 2.1. Introducción a la traducción automática ...................................................................................... 9 2.1.1. Limitaciones ........................................................................................................................... 9 2.1.2. Tipos de traducción automática ........................................................................................... 10 2.2. SMT Moses .................................................................................................................................... 11 2.2.1. Funcionamiento .................................................................................................................... 11 2.2.2. Preparar corpus paralelo ...................................................................................................... 14 2.2.3. Crear modelo de lenguaje .................................................................................................... 14 2.2.4. Entrenamiento ...................................................................................................................... 15 2.2.5. Tuning ................................................................................................................................... 15 2.2.6. Traducción ............................................................................................................................ 17 2.2.7. Evaluación ............................................................................................................................ 18 CAPÍTULO 3. DISEÑO DEL SISTEMA .................................................................... 19 3.1. Arquitectura cliente/servidor ....................................................................................................... 19 3.2. Herramientas de desarrollo ......................................................................................................... 21 3.2.1. Java SE ................................................................................................................................ 21 3.2.2. Entorno de desarrollo NetBeans .......................................................................................... 21 3.2.3. Java Web Start ..................................................................................................................... 22 3.2.4. XAMPP ................................................................................................................................. 23 3.2.5. SiGML Service Player ......................................................................................................... 24 3.3. Diagrama de casos de uso ........................................................................................................... 25 3.3.1. Diagrama de caso de uso de la aplicación Servidor ............................................................ 25 3.3.2. Diagrama de caso de uso de la aplicación Cliente .............................................................. 26 3.3.3. Diagrama de caso de uso de la aplicación Editor ................................................................ 27 3.4. Diseño de la base de datos .......................................................................................................... 28 CAPITULO 4. DESARROLLO DE LAS APLICACIONES ........................................ 29 4.1. Aplicación Servidor ...................................................................................................................... 29 4.2. Aplicación Cliente ......................................................................................................................... 39 4.3. Aplicación Editor .......................................................................................................................... 42 CAPÍTULO 5. CONCLUSIONES .............................................................................. 46 5.1. Pruebas y resultados .................................................................................................................... 46 5.2. Limitaciones .................................................................................................................................. 48 5.3. Lineas futuras ............................................................................................................................... 48 5.4. Conclusiones personales ............................................................................................................ 49 BIBLIOGRAFÍA ........................................................................................................ 50 ANEXO A. Guía de instalación del SMT Moses .................................................... 52 ANEXO B. Formato de archivo .sgm .................................................................... 57 ANEXO C. Formato de archivo .jnlp ...................................................................... 59 ANEXO D. Lista de símbolos HamNoSys .............................................................. 60 ANEXO E. Lista de movimientos no manuales ..................................................... 64 ÍNDICE DE FIGURAS Fig. 1.1 Signo “PLUJA” de la Lengua de Signos Catalana ......................................... 3 Fig. 1.2 a) Notación Stokoe para describir el lugar de articulación de la mano. b) Representación del signo “CONOCER”. ..................................................................... 6 Fig. 1.3 Representación del signo “ALEMANIA” en HamNoSys ................................. 7 Fig. 2.1 Arquitectura del Sistema Moses .................................................................. 14 Fig 2.2 Bucle externo e interno de MERT ................................................................. 16 Fig. 3.1 Modelo Cliente/Servidor ............................................................................... 20 Fig. 3.2 Esquema final del proyecto .......................................................................... 21 Fig. 3.3 NetBeans ..................................................................................................... 23 Fig. 3.4 Panel de control XAMPP ............................................................................. 24 Fig. 3.5. Página inicial de XAMPP ............................................................................ 24 Fig. 3.6 Herramienta phpMyAdmin de XAMPP ......................................................... 25 Fig. 3.7 Diagrama de caso de uso en la aplicación Servidor .................................... 26 Fig. 3.8 Diagrama de caso de uso en la aplicación Cliente ...................................... 27 Fig. 3.9 Diagrama de caso de uso en la aplicación Editor ........................................ 28 Fig. 4.1 Funcionamiento de una conexión socket TCP ............................................. 32 Fig. 4.2 Trama de datos del cliente ........................................................................... 33 Fig. 4.3 Trama de datos del servidor ........................................................................ 34 Fig. 4.4 Diagrama de flujo de entrada y salida de datos de la aplicación ................. 34 Fig 4.5 Estructura de la aplicación Servidor .............................................................. 35 Fig. 4.6 Ventana principal de la aplicación ................................................................ 35 Fig. 4.7 Ventana de configuración para la aplicación Servidor ................................. 36 Fig. 4.8 Ventana “corregir corpus” ............................................................................ 37 Fig. 4.9 Ventana “model de llenguatge” .................................................................... 37 Fig. 4.10 Ventana “Entrenament” .............................................................................. 37 Fig. 4.11 Ventana “Tuning” ....................................................................................... 38 Fig. 4.12 Ventana “Traductor” ................................................................................... 38 Fig. 4.13 Ventana “Evaluació” ................................................................................... 38 Fig. 4.14 Ventana “Convertir .sgm” ........................................................................... 39 Fig. 4.15 Ventana “Base de dades” de la aplicación Servidor .................................. 39 Fig. 4.16 Ventana “Codi SiGML” ............................................................................... 39 Fig. 4.17 Estructura de la aplicación Cliente ............................................................. 41 Fig. 4.18 Ventana principal de la aplicación Cliente ................................................. 41 Fig. 4.19 Ventana de configuración para la aplicación Cliente ................................. 42 Fig. 4.20 Estructura de la aplicación Editor ............................................................... 43 Fig. 4.21 Ventana principal de la aplicación Editor ................................................... 44 Fig. 4.22 Ventana de configuración de la aplicación Editor ...................................... 44 Fig. 4.23 Ventana “base de dades” de la aplicación Editor ....................................... 45 Fig. 4.24 Lista de movimientos para la boca ............................................................. 45 Fig. 4.25 Lista de movimientos para el cuerpo ......................................................... 45 Fig. 4.26 Ventana “HamNoSys” para la configuración de manos ............................. 46 Fig. 5.1 Comparativa de los valores obtenido en traducción con cada tipo de alineamiento por BLEU ............................................................................................. 48 ÍNDICE DE TABLAS Tabla 1.2 Codificación en SiGML ............................................................................... 8 Tabla 2.1 Ventajas e inconvenientes de los diferentes tipos de TA .......................... 11 Tabla 3.1 Diseño de la base de datos....................................................................... 29 Tabla 3.2 Representación del signo ......................................................................... 29 Tabla 5.1 Datos de entrenamiento y test .................................................................. 47 Tabla 5.2 Resultados con cada tipo de alineamiento en el modelo de traducción .... 47 Tabla 5.3 Resultados obtenidos sin/con Tuning para el alineamiento Destino-Origen .......................................................................................................... 48 GLOSARIO ASL American Sign Language BLEU Bilingual Evaluation Understudy eSIGN Essential Sign Language Information on Government Networks EUA University of East Anglia GIZA++ Herramienta para la traducción automática estadísitca HamNoSys Hamburg Sign Language Notation IDE Integrated Development Environment IP Internet Protocol JAR Java Archive Java Lenguaje de programación Java SE Java Standard Edition JDBC Java DataBase Connectivity JDK Java Development Kit JNLP Java Networking Launching Protocol JRE Java Runtime Environment JVM Java Virtual Machine LGPL Lesser General Publi License LS Lengua de Signos LSC Lengua de Signos Catalana LSE Lengua de Signos Española MERT Minimum Error Rate Training MySQL Sistema de gestión de base de datos NIST National Institute of Standards and Technology SiGML Signing Gesture Markup Language SMT Statistical Machine Translation SRILM SRI Language Modeling Toolkit TA Traducción Automática TCP Transmission Control Protocol ViSiCAST Virtual Signing, Captute, Animation, Storage and Transmission XAMPP X, Apache, MySQL, Php, Perl, XML Extensible Markup Language 6 La lengua de signos 1.4. Sistema de transcripción La necesidad de representar por escrito la producción signada se remonta a los inicios de la investigación lingüística de las lenguas de signos. William C. Stokoe no sólo ha pasado a la historia por su pionero análisis lingüístico de La lengua de Signos Americana (ASL), sino también por el hecho de haber sido el primero en crear un sistema de notación que permitiera la transcripción de los elementos que constituían los signos de la ASL. Sus parámetros engloban la configuración de la mano, el lugar de articulación y el movimiento, y su sistema significó la creación de símbolos con los que escribir los cincuenta y cinco “fonemas” que constituían estos tres parámetros formativos. Stokoe diseñó este sistema para que pudiera escribirse con una máquina de escribir empleando una fuente especial. Procuró utilizar símbolos que fueran tan icónicos como fuera posible con respecto de la localización y el movimiento. (a) (b) Fig. 1.2 a) Notación Stokoe para describir el lugar de articulación de la mano. b) Representación del signo “CONOCER” Algunos inconvenientes de la notación Stokoe es que el sistema se basaba en la Lengua de Signos ASL, con lo cual no se reflejaba todos los movimientos posibles en otras lenguas de signos. Otro de los inconvenientes de este sistema de notación es que no se tienen en cuenta los componentes no manuales de los signos (boca, ojos, cejas, hombros, etc.). La lengua de signos 7 Posteriormente y a medida que se ha ido avanzando en la investigación lingüística de las diferentes lenguas de signos, los investigadores se han visto en la necesidad de desarrollar diversos sistemas de notación que contemplaban o modificaban el sistema desarrollado por Stokoe. Uno de ellos es el que vamos a analizar a continuación y el que utilizaremos en nuestro proyecto para la transcripción de los signos. 1.4.1. HamNoSys HamNoSys ó Sistema de Notación de Hamburgo es un sistema de transcripción “fonética” de las lenguas de signos. Su principal característica frente a otros sistemas de notación es que no se concibió para la transcripción de una lengua de signos en particular, sino como un intento de crear un sistema internacional de notación por ordenador para la investigación internacional de las lenguas de signos. Por esta razón, no se basa en un alfabeto dactilológico concreto, rompiendo así con la tradicción iniciada por Stokoe. HamNoSys fue creado en el Center for German Sign Language and Comunicaction on the Deaf de la Universidad de Hamburgo alrededor de 1987 y consta de más de 150 símbolos. Incluye símbolos que representan las configuraciones de la mano, la orientación, el lugar y el movimiento. Los símbolos se disponen de una forma lineal y con un orden fijo. Hasta ahora, HamNoSys se ha empleado como un sistema de notación de referencia en varios proyectos de investigación en lengua de signos. En primer lugar, es el sistema de notación más estable y más frecuentemente utilizado entre la comunidad de lengua de signos. Por último, las notaciones son más compactas y sencillas de introducir en un entorno de edición de signos. Fig. 1.3 Representación del signo “ALEMANIA” en HamNoSys En la web de la Universidad de Hamburgo existe un tutorial que explica el significado de cada signo y los pasos a seguir para formar una palabra (ver [9]). En el anexo D hemos elaborado una lista completa de los símbolos HamNoSys. 1.4.2. SiGML (Signing Gesture Markup Language) es un tipo de lenguaje del formato XML que permite la transcripción de los gestos de la lengua de signos. Dado que los ordenadores no pueden procesar la sintaxis de estas descripciones en HamNoSys, la 8 La lengua de signos Universidad Est Anglian diseñó SIGML, una versión modificada de XML y que generó un traductor de HamNoSys a SIGML. La descripción en SIGML de un signo contiene exactamente la misma información que la descripción en HamNoSys, pero en un lenguaje que pueden procesar los ordenadores. HamNoSys SiGML Tabla 1.2 Codificación en SiGML Cada signo se diseña dentro de la etiqueta <hns_sign> y en el que está compuesto por dos etiquetas internas (<hamnosys_nonmanual> y <hamnosys_manual>. Dentro de la etiqueta <hamnosys_nonmanual> se define los movimientos de boca, cabeza, nariz, ojos, cejas y hombros. En la etiqueta <hamnosys_manual> se describe los movimientos de las manos. La notación SiGML se ha desarrollado en EUA para apoyar el trabajo de los proyectos ViSiCAST y eSIGN (ver [3] y [4]). La traducción automatica 9 CAPÍTULO 2. LA TRADUCCIÓN AUTOMÁTICA 2.1. Introducción a la traducción automática La traducción automática (TA) es una rama de la Lingüística Computacional y accesible desde muchos puntos de vista (informático, lingüístico, empresarial, etc). A principios de los años 50 y comienzos de los 60 del siglo XX existía entre algunos técnicos en inteligencia artificial estadounidenses la confianza de que la tarea de la traducción se podría automatizar, y que existirían sistemas capaces de traducir cualquier texto. Dado que las máquinas son más baratas de mantener que los traductores humanos y además pueden producir mucho más y en menos tiempo, la TA se perfilaba como una línea de investigación que podía ser aplicada para reducir los costes de traducción de las empresas, los organismos internacionales y los servicios de inteligencia militar. Los sistemas de TA permiten traducir amplios cuerpos de texto en un tiempo inferior a la traducción humana. Proyectos como la edición de la versión en catalán de “El Periódico” no serían posibles si no se llevaran a cabo con un sistema de TA. Por otra parte, para organismos internacionales como la Comunidad Europea, que tiene que generar grandes volúmenes de documentos en muchas lenguas en un tiempo limitadamente corto, la TA se ha convertido también en una necesidad. Por esta razón la Comunidad financió el proyecto Eurotra, que consistió en la preparación de un sistema capaz de traducir automáticamente su documentación en las lenguas oficiales de la Unión Europea. La TA disminuye costes cuando se trata de traducir constantemente documentos escritos en un lenguaje controlado. Un documento está escrito en un lenguaje controlado si tiene unas estructuras sintácticas simples y rígidas, no es ambiguo, su léxico es limitado y tiene una fraseología formada previamente. 2.1.1. Limitaciones Las restricciones de un sistema de TA conmueven sobre todo a la calidad de la traducción. Si un sistema de TA no tiene una representación adecuada del significado de la frase original es más que probable que la traducción no se entienda o sea ilógica. La compresión de una frase requiere de un conocimiento complejo de la lengua origen, de unos elementos que procesen la información lingüística y de conocimiento del mundo contenida en la frase. Evidentemente, el procesamiento de todo ella tendría un enorme coste en tiempo y probablemente los recursos de memoria del sistema se colapsarían precipitadamente. 10 La traducción automática Ahora bien, la precisión en la designación de conceptos puede mejorar mediante la consulta automática a bases de datos terminológicas de un dominio concreto en el par de lenguas del sistema. No todos los sistemas de TA permiten que los usuarios incorporen base de datos terminológicos. 2.1.2. Tipos de Traducción Automática Se pueden diferenciar dos tipos principales de sistemas de traducción automática: los que se basan en reglas lingüísticas y los que se basan en corpus textuales.  Basados en reglas lingüísticas: Consisten en sustituir las palabras por su equivalente más cercano. Primero se hace una representación simbólica interna del texto original. Desde ahí se puede hacer la traducción palabra por palabra o utilizando una intermedia. - Por transferencia: Se analiza el original que da paso a una representación interna que será el enlace a otros idiomas. - Por lenguaje intermedio: El texto base se convierte en un lenguaje intermedio con estructura diferente al lenguaje origen y al lenguaje destino.  Basados en corpus textuales: Se basa en un corpus lingüístico que se ha obtenido de muestras reales. - Estadística: Se obtienen corpus de textos bilingües como fuente. Actualmente la investigación en traducción automática se ha centrado en estos sistemas porque los resultados obtenidos, sobre todo cuando se trata de lenguas cercanas, son bastantes prometedores y los costes en tiempo y dinero de su construcción son menores que para la creación de motores de traducción con conocimiento lingüístico. Consiste en buscar las palabras de la lengua destino que traducen mejor las palabras de la oración original y en encontrar la secuencia de estas palabras que es más adecuada para ser una oración correcta en la lengua destino. Los cálculos de las probabilidades son significativos si los corpus son muy grandes. - Basado en ejemplos: Parte de un corpus bilingüe como fuente. Se basa en analogías. Resuelve un problema tomando como base otras soluciones similares ya resueltas. - Basado en el contexto: Consiste en traducir cada palabra teniendo en cuenta las palabras que le rodean. Divide el texto en unidades de cuatro a ocho palabras y las traduce al idioma destino. Después se eliminan aquellas que han generado frases sin sentido. Luego se mueve la ventana una posición o palabra volviendo a traducir de nuevo dejando solo las frases con sentido. Se repite este proceso de nuevo La traducción automatica 11 hasta terminar todo el texto. Después se unen los resultados de cada ventana de modo que quede un texto unitario. Ventajas Inconvenientes Basados en reglas lingüísticas Buenos resultados en las traducciones Más complejo, alto coste en inversión de capital humano Basados en corpus textuales Bajo coste de tiempo y dinero Resultados pobres si no disponemos de un gran corpus paralelo Tabla 2.1 Ventajas e inconvenientes de los diferentes tipos de traducción automática 2.2. SMT Moses SMT Moses (Statistical Machine Translation Moses) es un sistema de Traducción Automática Estadístico de código abierto, bajo licencia LGPL. El desarrollo de Moses se apoya principalmente en los proyectos EuroMatrix y EuroMatrixPlus, financiados por la Comisión Europea y recibe apoyo adicional de: Universidad de Edimburgo (Escocia), RWTH Aachen (Alemania), Fundación Bruno Kessler de Trento (Italia), Universidad de Maryland (EE.UU), Instituto Tecnológico de Massachusetts (EE.UU), Universidad Charles (Praga), las agencias de financiamiento de DARPA, NSF, el Departamento de Defensa EE.UU y financiación de la UE a través del proyecto TC-Star. El sistema Moses se ejecuta en Linux. Es posible ejecutarlo desde Windows pero utilizando sobre Cygwin, que emula la ejecución de Unix en Windows. Las secuencias de comandos de entrenamiento y puesta a punto fueron desarrolladas para Unix como sistema operativo por lo que es difícil de ejecutar sin el entorno Cygwin. Además, la instalación de Cygwin requiere algunos cambios en los Makefiles y scripts debido a diferencias entre Cygwin y Linux. Para evitar problemas, en este proyecto instalaremos el sistema Moses en una máquina con Linux. En el anexo A hemos elaborado una guía de instalación del sistema Moses. 2.2.1. Funcionamiento Moses permite entrenar de forma automática los modelos de traducción para cualquier par de lenguas. Todo lo que necesitas es una colección de textos traducidos (corpus paralelo). Un algoritmo de búsqueda eficaz encuentra rápidamente la traducción, aplicando el Teorema de Bayes calcula la probabilidad de que la cadena del idioma destino (d) haya sido generada por la cadena origen (o). De tal manera que para conseguir p(d|o) se calcula p(o|d) · p(d), donde p(o|d) es la probabilidad de que la cadena origen sea la traducción de la cadena destino (modelo de traducción), y p(d) es 12 La traducción automática la probabilidad de ver aquella cadena destino (modelo de lenguaje de la lengua de destino). Matemáticamente, encontrar la mejor traducción õ se consigue escogiendo aquella secuencia de signos que permita obtener la probabilidad máxima. (2.1) Modelo de lenguaje Es un mecanismo para definir la estructura del lenguaje, es decir, para restringuir adecuadamente las secuencias de unidades lingüísticas más probables. En general son útiles en aplicaciones que exhiban una sintaxis y/o semántica compleja. Un buen modelo de lenguaje solamente debería aceptar (con alta probabilidad) frases correctas y rechazar (o asignar baja probabilidad a) aquellas secuencias de palabras incorrectas. Para generar el modelo de lenguaje se emplea la herramienta SRILM (SRI Languages Modeling Toolkit), que permite estimar modelos de lenguaje tipo n-grama. Un modelo de n-grama determina la probabilidad de una palabra dadas las n-1 palabras previas. Modelo de traducción Para generar el modelo de traducción se emplea la herramienta GIZA++. Además, se necesita una colección de textos en lengua origen traducidos a lengua destino (corpus paralelo). GIZA++ es una herramienta software que permite alinear textos y aprender modelos de traducción basada en palabras a partir de ellos, empleando en este sistema 5 iteraciones. De tal manera que, a partir del corpus bilingüe, se obtiene el alineamiento en los dos sentidos: origen-destino y destino-origen, para posteriormente combinar dichos alineamientos. Esta combinación puede realizarse de varias formas que se comentan a continuación.  Destino-Origen (DO): Sólo se tiene en cuenta el alineamiento en un sentido, ignorando el alineamiento en sentido contrario.  Origen-Destino (OD): En este caso el alineamiento que se tiene en cuenta es el contrario.  Intersección (I): Partiendo de los dos alineamientos anteriores, se obtiene como alineamiento final los alineamientos intersección de ambos. Este tipo de alineamiento es el más exigente: permite tener alineamientos más fiables pero a costa de tener menos. Esta característica influye en la calidad del modelo de traducción cuando no se dispone de una gran cantidad de frases para su entrenamiento. La traducción automatica 13  Unión (U): En este caso, se toma la unión de los puntos de alineamiento en los dos sentidos. De esta manera, se obtiene puntos adicionales de alineamiento, consiguiendo más ejemplos para entrenar el modelo de traducción de palabras, pero también la calidad de los alineamientos considerados es menor que en el caso de la intersección.  Crecimiento (C): En este tipo de alineamiento se toman los puntos de alineamiento de la intersección y, a continuación, se añaden los puntos de la unión que estén contiguos a los puntos de la intersección. Con esta probabilidad, se intenta buscar una situación intermedia entre la unión y la intersección consideradas anteriormente. El objetivo es buscar un punto de equilibrio entre cantidad de puntos de alineamiento y su calidad.  Crecimiento diagonal (CD): Igual que el alineamiento anterior, pero añadiendo sólo los puntos de la unión contiguos a la intersección y situados en la diagonal.  Crecimiento diagonal evitando casos de no alineamiento (CDP): Este tipo de combinación es similar a la anterior con un postproceso adicional que tiene como objetivo evitar que ninguna palabra o signo se quede sin ningún punto de alineamiento. En el caso de que eso ocurra se añaden los alineamientos en uno u otro sentido necesarios. A partir de dicho alineamiento, se obtienen las probabilidades de traducción para todos los pares de palabra (w(d|o) y w(o|d)), realizándose así una estimación de la tabla de traducción léxica más probable. A continuación, de todos los pares de subsecuencias obtenidos, se escogen con el programa phrase_extract sólo los que sean consistentes con el alineamiento de palabras. Y, por último, con el programa phrase_score, se calculan las probabilidades de traducción para todos los pares de subfrases en los dos sentidos. Estos dos últimos programas (phrase_extract y phrase_score) ya están incluidos dentro de la herramienta GIZA++. Los modelos de traducción y de lenguaje (en lengua destino) se combinan linealmente para ser utilizados como heurístico en el proceso de búsqueda necesario para generar la traducción de una frase dada. Para ello, con el traductor Moses se traduce y evalúa una lista de frases de validación cuya traducción correcta se conoce, probando con distintos pesos aleatoriamente y escogiendo los que dan los mejores resultados. Por último, para la traducción se emplea el decodificador Moses, que implementa un algoritmo de búsqueda para obtener, a partir de una frase de entrada, la secuencia de palabras que con mayor probabilidad corresponde a su traducción. Para ello, utiliza los modelos de traducción y lenguaje obtenidos anteriormente, con los pesos de sus probabilidades ajustados. 14 La traducción automática Alineamiento palabras (GIZA++) Entrenamiento N-gramas (SRILM) Modelo de frases Traducción Moses Evaluación Modelo de Traducción Modelo de lenguaje Corpus Origen Corpus Destino Corpus Destino Corpus Origen Corpus Destino Fig. 2.1 Arquitectura del Sistema Moses 2.2.2. Preparar corpus paralelo Los datos del corpus paralelo han de cumplir los siguientes puntos: - Una frase por línea, no líneas vacías. - Las frases con más de 100 palabras (y su correspondiente traducción) tienen que ser eliminadas (tenga en cuenta que un límite de longitud menor de la frase acelerará el entrenamiento). - Todo en minúscula. - Las palabras han de estar separadas de los signos de puntuación y ortográficos. 2.2.3. Crear modelo de lenguaje Para crear el modelo de lenguaje utilizamos el programa ngram-count de la herramienta SRILM. Su sintaxis es la siguiente: ./srilm/bin/i686/ngram-count -order 3 -interpolate -kndiscount -text meteo.lsc -lm meteo.lm -order: Establecer el orden de máxima (longitud) de N-gramas para contar. El orden por defecto es de 3. -text: Se indica la ruta del corpus de la lengua destino. -lm: Se define un archivo para guardar el modelo de lenguaje. La traducción automatica 15 Desde la web http://www-speech.sri.com/projects/srilm/manpages/ngram-count.1.html explica con detalle cada uno los parámetros que podemos incluir. 2.2.4. Entrenamiento Por último, entrenamos el corpus paralelo utilizando el script train-model.perl. Su sintaxis es la siguiente: ./moses-scripts/scripts-YYYYMMDD-HHMM/training/train-model.perl - scripts-root-dir /moses-scripts/scripts-YYYYMMDD-HHMM/ -root-dir /home/javi.marin/demo/work -corpus /home/javi.marin/demo/work/corpus/meteo -f cat -e lsc -alignment growdiag-final-and -reordering msd-bidirectional-fe -lm 0:3:/home/javi.marin/demo/work/lm/meteo.lm >& work/training.out & -scripts-root-dir: ruta de directorio de la carpeta scripts-YYYYMMDD-HHMM/. -root-dir: ruta de directorio raíz del corpus paralelo. -corpus: ruta de directorio de la carpeta donde se encuentra el corpus paralelo. -f: nombre de extensión del archivo de la lengua origen (“cat”). -e: nombre de extensión del archivo de la lengua destino (“lsc”). -lm: ruta de archivo del modelo de lenguaje. El “0” indica el número de modelos de lenguajes utilizados empezando por el 0. El “3” indica el número de n-gramas utilizado en ese modelo de lenguaje. El entrenamiento habrá sido un éxito si en la última línea del archivo training.out indica que se ha creado el archivo de configuración “moses.ini”. Este archivo de configuración contiene todas las rutas para el modelo generado y una serie de ajustes de los parámetros por defecto. Más adelante veremos cómo usar este archivo en la etapa de traducción. 2.2.5. Tuning El script de entrenamiento train-model.perl genera un archivo de configuración “moses.ini” con unos pesos por defecto de baja calidad. Es por eso que necesitamos obtener mejores pesos mediante la optimización de rendimiento de la traducción del modelo generado. En la traducción automática estadística, los modelos probabilísticos son usados para encontrar la mejor traducción e* de un determinada frase de origen f, entre todas las traducciones posibles e. La búsqueda de la mejor traducción se conoce como descodificación. Los modelos probabilísticos son estimados desde los datos de entrenamiento, y puede incluir modelos de traducción, modelos de lenguajes, modelos de reordenamiento, etc. Con el fin de combinar las pruebas de diferentes modelos, es una práctica habitual de utilizar un modelo lineal, con las probabilidades de registro 22 Diseño del sistema Fig. 3.3 NetBeans 3.2.3. Java Web Start Java Web Start es una solución de distribución de aplicaciones basada en tecnología Java. Es la canalización entre Internet y el sistema que permite al usuario ejecutar y gestionar aplicaciones desde la Web. Proporciona una activación fácil y rápida de las aplicaciones, garantiza la ejecución de la última versión de la aplicación, eliminando los complicados procesos de instalación o de modernización. Cuando se descarga por primera vez una aplicación que utiliza la tecnología Java Web Start se ejecuta automáticamente y guarda la aplicación localmente, en la memoria del caché del equipo. De este modo, las subsiguientes ejecuciones son prácticamente instantáneas, ya que los recursos necesarios están disponibles de forma local. Cada vez que se inicia la aplicación, el componente de software de Java Web Start comprueba si en la sede Web de la aplicación hay una nueva versión disponible; si es así, la descarga y la ejecuta de forma automática. Ejecutar una aplicación Java desde la web únicamente se requiere crear un archivo JNLP (Java Networking Launching Protocol). Cualquier enlace JNLP, al iniciar el proceso de ejecución, pide autorización al usuario. Además, las aplicaciones pueden estar firmadas para asegurar el remitente de la aplicación de modo que pueden seguir el modelo de seguridad de la plataforma Java 2 para asegurar la integridad de los datos que obtenemos a través de la red. En el anexo C tenemos un ejemplo del formato de archivo .jnlp Diseño del sistema 23 3.2.4. XAMPP Nuestro propósito es que el cliente pueda descargar y ejecutar las aplicaciones Cliente y Editor desde una página web. Para eso es necesario tener instalado un servidor web. Además, tanto las aplicaciones Servidor y Editor, necesitarán una base de datos para consultar signos y recoger su codificación SiGML. XAMPP es una distribución multiplataforma libre que integra el servidor web Apache, la base de datos MySQL y los intérpretes para lenguajes script: PHP y Perl. Una vez instalado, accedemos a su panel de control y arrancamos el servidor web Apache y MySQL. Fig. 3.4 Panel de control XAMPP Para comprobar que funciona, abrimos nuestro navegador web y escribimos http://localhost. XAMPP mostrará su página inicial. Fig. 3.5. Página inicial de XAMPP 24 Diseño del sistema El directorio de trabajo se encuentra ubicado en la subcarpeta “htdocs” del directorio XAMPP. Desde ahí, crearemos una carpeta y guardaremos los archivos JNLP y JAR de nuestras aplicaciones. PhpMyAdmin XAMPP permite configurar la base de datos MySQL utilizando la herramienta PhpMyAdmin (http://localhost/phpmyadmin/). Nos permite, entre otras opciones, crear, editar y eliminar base de datos. Desde ahí crearemos nuestra base de datos de signos, insertando su transcripción en glosa y su correspondiente codificación SiGML de todos sus movimientos. Desde Barcelona Media hemos podido almacenar un total de 260 signos aproximadamente. Fig. 3.6 Herramienta phpMyAdmin de XAMPP 3.2.5. SiGML Service Player Este avatar sustituye al anterior software SiGMLSigning que fue desarrollado en Europa para los proyecto proyectos eSIGN y ViSiCAST y que proporcionaba la animación de secuencias de signos defindos en SiGML. Esta última versión del avatar JASigning se puede ejecutar en Windows (XP, Vista, 7) y en las últimas versiones del MAC OS X 10.5 y 10.6. JASigning no es compatible con Linux en la actualidad. Es preferible ejecutar JASigning con las nuevas actualizaciones de Java 6 (JRE), aunque debe funcionar con las últimas versiones de Java 5. Para los usuarios del Windows Xp, requiere la previa instalación del paquete Microsoft Visual C++ 2008 SP1 Redistributable Package, que lo podemos obtener desde la web oficial de Microsoft. Desde la web Virtual Humans podemos descargar la aplicación JNLP SiGML Service Player. Esta aplicación reproduce una secuencia SiGML entregado en un socket de Diseño del sistema 25 red. Esta aplicación acepta solicitudes de conexión en el estándar TCP/IP con el número de puerto 8052. 3.3. Diagrama de caso de uso En este diagrama identificamos previamente los actores del sistema y el listado de las acciones que pueden realizar. A continuación vamos a mostrar las acciones que aparecen en nuestro sistema para cada una de las aplicaciones que crearemos. 3.3.1. Diagrama de caso de uso en la aplicación Servidor Definir rutas de configuración Usuario (aplicación Servidor) Corregir corpus Crear modelo de lenguaje Entrenar corpus paralelo Optimizar modelo de traduccion Evaluar modelo de traducción Convertir archivos de texto en .sgm Traducir Obtener codificación SiGML Ejecutar avatar Fig. 3.7 Diagrama de caso de uso en la aplicación Servidor  Definir rutas de configuración: Establece las rutas de las distintas herramientas y scripts que utilizará el sistema Moses, así como los datos de configuración del servidor MySQL y del Avatar.  Corregir corpus: Corrige el corpus adaptándolo al formato requerido por Moses (convertir en minúscula, separar signos de puntuación, eliminar signos no ortográficos, etc.).  Crear modelo de lenguaje: Ejecuta la herramienta SRILM del sistema Moses a partir del corpus de la lengua destino.  Entrenar corpus paralelo: Ejecuta el script train-model.perl del sistema Moses para obtener un modelo de traducción. 26 Diseño del sistema  Optimizar el modelo de traducción: Ejecuta el script mert-moses.pl del sistema Moses para mejorar la tasa de error mínimo del entrenamiento.  Evaluar el modelo de traducción: Ejecuta el script mteval-v12.pl para evaluar el modelo de traducción con los sistemas NIST y BLEU.  Convertir archivos de textos en forma .sgm: Permite convertir los textos que serán evaluados en un formato que pueda ser procesado por los sistemas de evaluación NIST y BLEU.  Traducir texto: Ejecuta el decodificador Moses para obtener la traducción de un texto de entrada. Permite activar la opción “Mostrar palabras desconocidas” en caso de que Moses no encontrara su traducción y la opción “Deletrear” para aquellos signos, obtenidos por Moses, que no se encuentren en la base de datos y quisiéramos deletrearlos. Útil para traducir nombres propios donde no existe un signo específico (ej: “JAVIER”).  Obtener codificación SiGML: Establece una conexión con el servidor MySQL para consultar y recoger la codificación SiGML de la secuencia de signos obtenidos por el decodificador Moses.  Ejecutar Avatar: Envía la codificación SiGML obtenida al Avatar. 3.3.2. Diagrama de caso de uso en la aplicación Cliente Cargar un corpus Usuario (aplicación Cliente) Traducir Ejecutar el avatar Ver codificación SiGML Fig. 3.8 Diagrama de caso de uso en la aplicación Cliente  Cargar un corpus: Permite seleccionar un corpus para mostrar las frases por pantalla y seleccionar la que queramos traducir. Diseño del sistema 27  Traducir: Envía una trama de datos, donde incluye la frase o texto escrito por el usuario, a la aplicación Servidor para recoger y mostrar el resultado de la traducción. Esta trama incluye unos campos que informa a la aplicación Servidor si el usuario desea ver las palabras desconocidas por el sistema Moses (palabras que no ha podido traducirlas) y/o deletrear una palabra por si la base de datos no encuentra el signo correspondiente.  Ver codificación SiGML: Muestra la secuencia de signos en SiGML obtenido en la traducción.  Enviar traducción al Avatar: Crea un socket de red con el avatar y envía la secuencia de signos en SiGML. 3.3.3. Diagrama de caso de uso en la aplicación Editor Nuevo signo Usuario (aplicación Editor) Cargar signos de la base de datos Ejecutar avatar Ver codificación SiGML Guardar signo Fig. 3.9 Diagrama de caso de uso en la aplicación Editor  Nuevo signo: Permite definir un nuevo signo estableciendo los movimientos de boca, cuerpo, espalda, cabeza, mirada, cejas, párpados, nariz y manos.  Cargar signos de la base de datos: Establece una conexión con el servidor MySQL y muestra la lista de signos de la base de datos para cargar y editar el signo seleccionado.  Ver codificación del signo en SiGML: Muestra la codificación SiGML del signo a editar.  Enviar signo al Avatar: Abre un canal de comunicación con el Avatar y envía el signo seleccionado para ver sus movimientos. 28 Diseño del sistema  Guardar signo en un archivo de texto: Guarda en un archivo de texto los signos editados por el usuario. Por seguridad, hemos evitado que cualquiera pueda guardar directamente los signos a la base de datos del servidor MySQL. 3.4. Diseño de la base de datos XAMPP, visto anteriormente en el apartado de herramientas de desarrollo, incluye el servidor MySQL, un gestor de base de datos potente y de libre distribución. Allí guardaremos los signos (glosas) en la Lengua de Signos Catalana que Barcelona Media ha ido desarrollando. Cada signo contiene la información de sus movimientos en formato SiGML. A continuación se muestra la estructura de la base de datos: Campo Tipo Descripción ID Int(11) Identificador del signo GLOSA Varchar(80) Nombre del signo MANOS Text Movimientos de manos BOCA Varchar(30) Movimiento de boca COS Varchar(4) Movimiento de cuerpo ESQUENA Varchar(4) Movimiento de espalda CAP Varchar(4) Movimiento de cabeza MIRADA Varchar(4) Movimiento de mirada CELLES Varchar(4) Movimiento de cejas PARPELLES Varchar(4) Movimineto de párpados NAS Varchar(4) Movimiento de nariz Tabla 3.1 Diseño de la base de datos En el campo “MANOS”, los movimientos que se ejecutan son separados por un espacio en blanco. Cada movimiento es una representación SiGML del símbolo icónico HamNoSys utilizado. GLOSA HamNoSys Representación SiGML MAR  hamfinger2 hamthumbacrossmod hamfingerhookmod hamextfingeru hampalml hamnose hammoved hamsmallmod Tabla 3.2 Representación del signo En el anexo D podemos ver la lista de símbolos del sistema HamNoSys con su correspondiente representación SiGML. Para la representación de los movimientos faciales (boca, cuerpo, espalda, cabeza, etc.) podemos mirar la lista de códigos del anexo E. Desarrollo de las aplicaciones 29 CAPÍTULO 4. DESARROLLO DE LAS APLICACIONES 4.1. Aplicación Servidor El objetivo de esta aplicación es poder utilizar el sistema Moses de una manera gráfica, utilizando las herramientas que maneja para entrenar un corpus paralelo, probar su traducción y evaluar el modelo. Además, la aplicación permitirá escuchar y recibir mediante sockets de red los datos de los clientes para posteriormente enviarles a cada uno de ellos la traducción obtenida por el sistema Moses y su codificación SiGML.  Ejecutar un programa externo Entre muchas de sus funciones, la aplicación Servidor destaca por tener que acceder y ejecutar herramientas del sistema Moses. Desde Java, podemos ejecutar programas externos utilizando la clase Runtime. Ofrece diversos servicios como los de obtener la memoria disponible o ejecutar un comando del sistema con el método exec(). String cmd = “echo 'dilluns , 19 de novembre de 2007' | moses/moses-cmd/src/moses -f /work/model/moses.ini > out.txt”; String[] command = {“sh”, “-c”, cmd}; Process proc = Runtime.getRuntime().exec(command); new Thread(){ public void run(){ InputStream is = proc.getInputStream(); BufferedReader br = new BufferedReader(new InputStreamReader(is)); String linea; while((linea = br.readLine()) != null){ System.out.println(linea); } } }.start(); new Thread(){ public void run(){ InputStream is = proc.getErrorStream(); BufferedReader br = new BufferedReader(new InputStreamReader(is)); String linea; while((linea = br.readLine()) != null){ System.out.println(linea); } } }.start(); int returnCode = proc.waitFor(); 30 Desarrollo de las aplicaciones En el código anterior crea un proceso de la clase Runtime para ejecutar el comando “echo 'dilluns , 19 de novembre de 2007' | moses/moses-cmd/src/moses -f /work/model/moses.ini > out.txt”. Acto seguido utilizamos la función getInputStream() para poder ver la salida estándar del comando. Para la salida de errores lo mostrará con la función getErrorStream(). La línea proc.waitFor() espera que termine el proceso. Normalmente devuelve el código 0, que significa que la ejecución ha sido correcta. En caso de que se haya producido algún error lo normal es que devuelva otro valor.  Conexión con una base de datos MySQL Otras de las funciones de la aplicación, es obtener el código SiGML de una secuencia de signos obtenida a la salida del decodificador Moses. La aplicación conectará con la base de datos para recoger la codificación SiGML del signo consultado. Lo primero que necesitamos para conectarnos con una base de datos es un Driver. Ese Driver es la clase que, de alguna forma, sabe cómo hablar con la base de datos. Java no viene con todos los Drivers de todas las posibles bases de datos que hay. MySQL provee conectividad para aplicaciones desarrolladas en Java mediante un driver llamado MySQL Connector/J, que es el driver JDBC (Java DataBase Connectivity) oficial para MySQL. Lo primero que debemos hacer, es descargar la última versión del conector MySQL: http://dev.mysql.com/downloads/connector/j/. Nos bajamos y descomprimimos el archivo “mysql-connector-java-X.zip”, donde “X” es la última versión actual. El archivo que viene dentro es un archivo jar, que es donde está la clase Driver que nos interesa. Únicamente tenemos que agregarlo como una librería externa JAR a nuestra aplicación Java. String ip = “localhost”; String bd = “lsc”; String user = “root”; String pass = “”; //Conexion con la base de datos Class.forName(“com.mysql.jdbc.Driver”); Conection con = DriverManager.getConnection(“jdbc:mysql://” + ip + “/” + bd, user, pass); //consulta Statement s = con.createStatement(); ResultSet rs = s.executeQuery(“SELECT * FROM signes”); //Recorre el resultado mientras hay registros while(rs.next()){ System.out.println(rs.getString(0)); // muestra los valores de la 1º columna } //Cierra conexión con.close(); Desarrollo de las aplicaciones 31 En el código siguiente, la aplicación permite conectar con el servidor MySQL pasando los parámetros “dirección ip” “base de datos”, “usuario” y “contraseña”. Una vez establecida la conexión se realiza la consulta, obteniendo los resultados que necesitemos.  Creación de un socket TCP/IP La comunicación con los clientes para recibir los texto a traducir y enviarles tanto la secuencia de signos obtenida por el sistema Moses y su codificación en SiGML se realiza mediante sockets de red. Los sockets son un sistema de comunicación entre procesos de diferentes máquinas de una red. Es un punto de comunicación por el cual un proceso puede emitir o recibir información. Los procesos los tratan como descriptores de ficheros, de forma que se pueden intercambiar datos con otros procesos transmitiendo y recibiendo a través de dichos sockets. Una de las principales características de Java es su tratamiento de la red. Java abstrae todos los detalles de manejo a bajo nivel de la red, dejándole ese trabajo a la Máquina Virtual de Java. Además, la capacidad de manejo de múltiples tareas que proporciona Java es muy cómoda a la hora de poder manejar múltiples conexiones a la vez. El tipo de socket que utilizaremos es el Socket Stream (TCP), que son un servicio orientado a conexión, donde los datos se transfieren sin encuadrarlos en registros o bloques. Hay que establecer en primer lugar una conexión entre un par de sockets. Mientras uno de los sockets atiende peticiones de conexión (Aplicación Servidor), el otro solicita una conexión (Aplicación Cliente). Una vez que los dos sockets estén conectados, se pueden utilizar para transmitir datos en ambas direcciones. Abrir canal de comunicación Publicar en la red la dirección del canal de comunicación Espera recibir solicitudes Esperar peticiones Crear proceso hijo Envío y recepción de datos Cerrar canal de comunicación Abrir canal de comunicación Conectar con servidor Envío y recepción de datos Cerrar canal de comunicación Aplicación Servidor Aplicación Cliente Fig. 4.1 Funcionamiento de una conexión socket TCP 38 Desarrollo de las aplicaciones - JDialogConvertirXml.java Permite definir la ruta de archivo de un corpus para adaptarlo al formato .sgm para la etapa de evaluación. Se especifica el tipo de corpus (origen, referencia o test) y unos atributos para el nuevo archivo .sgm. - JDialogBD.java Permite mostrar la lista de signos de la base de datos, ver la codificación SiGML de un signo y enviarlo al avatar. - JDialogVerSigml.java Permite mostrar la codificación SiGML del signo seleccionado de la base de datos y enviarlo al avatar. Fig. 4.14 Ventana “Convertir .sgm” Fig. 4.15 Ventana “Base de dades” de la aplicación Servidor Fig. 4.16 Ventana “Codi SiGML” Desarrollo de las aplicaciones 39 4.2. Aplicación Cliente El objetivo de esta aplicación es permitir que un usuario pueda traducir un texto (en catalán) a la lengua de signos catalana obteniendo su correspondiente secuencia de signos en glosas y su codificación SiGML. La aplicación Cliente conectará mediante un socket de red a la aplicación Servidor para enviarle el texto a traducir y esperará obtener una respuesta por parte del Servidor. Una vez obtenida la respuesta se mostrará por pantalla la traducción en glosas, guardando en una variable su codificación SiGML. La aplicación Cliente crea un nuevo socket de red con el avatar para enviar los datos SiGML obtenidos.  Conectar con un socket de red Una de sus funciones más importantes es la conexión con la aplicación Servidor y con el avatar a través de un socket de red. A continuación vamos a mostrar como conectar con un socket de red. La aplicación cliente se conecta con la aplicación Servidor indicando el nombre de la máquina y el número puerto en el que el servidor está instalado. Una vez conectado, el cliente envía una cadena de datos al servidor y recibe una respuesta. Lo mismo pasa al enviar datos a nuestro Avatar. El avatar se muestra como un servidor que escucha por su número de puerto 8052, pero únicamente recibe datos, sin devolver nada. Socket cliente; String ip; int port; … function(){ try{ cliente = new Socket(ip, port); //Crea una conexión al socket servidor //Crea las referencias al canale de escritura y lectura del socket OutputStream out = cliente.getOutputStream(); DataOutputStream Dout = new DataOutputStream(out); InputStream in = cliente.getInputStream(); DataInputStream Din = new DataInputStream(in); String entrada; … Dout.writeUTF(entrada); //Escribe en el canal de escritura del socket String salida = Din.readUTF(); //Espera la respuesta por el canal de lectura cliente.close(); }catch(Exception e){} } 40 Desarrollo de las aplicaciones Estructura de la aplicación Cliente Aplicación Cliente Control client - Configuracion.java - Control.java - ClientApp.java - ClientView.java - JDialogConfig.java - JDialogSigml.java - ClientApp.java Es la clase principal de la aplicación. Ejecuta el método startup() para crear un objeto de la clase ClientView. - ClientView.java La clase ClientView es la “ventana” principal de la aplicación. Fig. 4.17 Estructura de la aplicación Cliente Fig. 4.18 Ventana principal de la aplicación Cliente Desarrollo de las aplicaciones 41 - Configuracion.java La clase Configuracion permite guardar y leer las rutas de las herramientas del sistema Moses, los datos de configuración del servidor MySQL y del avatar. - Control.java La clase Control proporciona los métodos necesarios para la ejecución de las funciones que realiza la aplicación. - JDialogConfig.java Permite definir las rutas de las herramientas del sistema Moses, los datos de configuración del servidor MySQL y del avatar. - JDialogSigml.java Permite visualizar la secuencia de signos en SiGML obtenidos en la traducción. Fig. 4.19 Ventana de configuración para la aplicación Cliente 42 Desarrollo de las aplicaciones 4.3. Aplicación Editor El objetivo de esta aplicación es permitir crear o editar un signo de la base de datos. Además de definir el movimiento de manos, podremos añadir movimientos faciales (boca, cuerpo, espalda, cabeza, mirada, cejas, párpados y nariz).Los movimientos creados por la aplicación se pueden exportar a SiGML, de manera que podemos enviar el signo editado a nuestro avatar. Por último, los signos editados pueden ser guardados en un archivo de texto, no directamente de la base de datos. Estructura de la aplicación Editor Aplicación Cliente Control data - Configuracion.java - Control.java - Signo.java - myRenderCell.java - HamSymbols.txt - boca.txt - cap.txt - celles.txt - cos.txt - esquena.txt - mirada.txt - nas.txt - parpelles.txt editor - EditorApp.java - EditorView.java - JDialogBD.java - JDialogBoca.java - JDialogConfiguracion.java - JDialogHamnosys.java - JDialogMovimiento.java - JDialogSigml.java - EditorApp.java Es la clase principal de la aplicación. Ejecuta el método startup() para crear un objeto de la clase EditorView. - EditorView.java La clase EditorView es la “ventana” principal de la aplicación. Fig. 4.20 Estructura de la aplicación Editor Desarrollo de las aplicaciones 43 - Configuración.java La clase Configuracion permite guardar y leer los datos de configuración del servidor MySQL y del avatar. - Control.java La clase Control proporciona los métodos necesarios para la ejecución de las funciones que realiza la aplicación. - Signo.java La clase Signo permite guardar y leer los valores para los movimientos de boca, cuerpo, espalda, cabeza, mirada, cejas, párpados, nariz, manos y el nombre del signo (glosa). - myRenderCell.java Es una clase que extiende de la clase DefaultTableCellRenderer. Contiene el método getTableCellRendererComponent que permite definir las propiedades de las columnas de la tabla que queramos editar. Esta clase la utilizaremos para avisar que la última columna (“HamNoSys”), tendrá el tipo de letra “HamNoSysUnicode.ttf”, de esta manera podremos ver los icónos gráficos sin ningún problema. - JDialogConfiguracion.java Permite definir los datos de configuración del servidor MySQL y del avatar. Fig. 4.21 Ventana principal de la aplicación Editor Fig. 4.22 Ventana de configuración de la aplicación Editor 44 Desarrollo de las aplicaciones - JDialogBD.java Muestra la lista de signos de la base de datos. - JDialogBoca.java Lee la lista de códigos del archivo “boca.txt” para definir el tipo de movimiento de boca. Los movimientos pueden ser: dientes, mandíbula, labios, lengua y mejilla, - JDialogMovimiento.java Dependiendo del tipo de movimiento que queramos editar, la aplicación leerá el archivo de texto correspondiente para cargar la lista de movimientos posibles para cada tipo (boca.txt, cap.txt, celles.txt, cos.txt, esquena.txt, mirada.txt, nas.txt o parpelles.txt). Fig. 4.23 Ventana “base de dades” de la aplicación Editor Fig. 4.24 Lista de movimientos para la boca Fig. 4.25 Lista de movimientos para el cuerpo Desarrollo de las aplicaciones 45 - JDialogHamnosys.java Permite definir el movimiento de manos. Cada botón representa un icóno gráfico del sistema de notación HamNoSys. Los iconos están divididos según la forma de mano, la orientación, la localización, el movimiento y si el movimiento es con la mano secundaria. - JDialogSigml.java Muestra la codificación SiGML del signo que estemos editando. - HamSymbol.txt Lista de iconos HamNoSys con su correspondiente traducción textual para la codificación SiGML (ver anexo D). Fig. 4.26 Ventana “HamNoSys” para la configuración de manos 46 Conclusiones CAPÍTULO 5. CONCLUSIONES 5.1. Pruebas y resultados La información utilizada para los experimentos consiste en un corpus paralelo que contiene 262 frases típicas de un texto restringido en el dominio de la meteorología. Este conjunto de fases se dividió en 2 grupos de forma arbitraria: entrenamiento (contenido aproximadamente el 80% de las frases) y evaluación (con el 20% de las frases). A continuación se muestra un resumen de los datos: Catalán LSC Total Pares de frases 262 Nº de palabras / glosas 3536 2440 Entrenamiento Pares de frases 221 221 Nº de palabras / glosas 3067 2069 Test Pares de frases 41 41 Nº de palabras / glosas 469 371 Tabla 5.1 Datos de entrenamiento y test Para este experimento se analizó la influencia del tipo de alineamiento utilizado en la etapa de entrenamiento para la evaluación del corpus paralelo. Se emplean métricas (NIST y BLEU) que compara la traducción que realiza el sistema con una traducción de referencia. Los resultados para cada tipo de alineamiento pueden verse en la tabla 5.2 y en la figura 5.1. Tipo de alineamiento Test NIST BLEU Origen-Destino (OD) 3.5186 0.1698 Destino-Origen (DO) 4.2156 0.2220 Intersección (I) 3.7009 0.1835 Unión (U) 2.4214 0.1277 Crecimiento (C) 3.3626 0.1798 Crecimiento diagonal (CD) 3.6635 0.1715 Crecimiento diagonal evitando casos de no alineamiento (CDP) 3.5186 0.1698 Tabla 5.2 Resultados con cada tipo de alineamiento en el modelo de traducción Conclusiones 47 Fig. 5.1 Comparativa de los valores obtenido en traducción con cada tipo de alineamiento por BLEU Observamos que el tipo de alineamiento que mejor resultado se ha obtenido es el tipo Destino-Origen. Esto es así porque, al traducir a LSC una frase en catalán, lo que se está haciendo principalmente es extraer información semántica, y esto se consigue mejor con el alineamiento destino-origen (DO). Es importante tener en cuenta que este comportamiento se da con un corpus limitado. Al aumentar el corpus, los resultados podrían variar. Por último, en el archivo de configuración moses.ini, los distintos modelos implicados en el proceso de traducción (modelo de traducción y de lenguaje de la lengua destino) tienen unos pesos por defecto que no son los óptimos. Utilizando previamente la etapa “Tuning” mejoramos ligeramente los resultados obtenidos de la tabla 5.2. Tipo de alineamiento Test Sin Tuning Con Tuning NIST BLEU NIST BLEU Destino-Origen 4.2156 0.2220 4.3991 0.2446 Tabla 5.3 Resultados obtenidos sin/con Tuning para el alineamiento Destino-Origen La mejora conseguida ha sido de una reducción relativa de la tasa de error del 10%. 0 0,05 0,1 0,15 0,2 0,25 OD DO I U C CD CDP (Valor) (Tipo de alineamiento) Test BLEU 52 Anexo A. Guía de instalación del SMT Moses ANEXO A. GUÍA DE INSTALACIÓN DEL SMT MOSES Pre-requisitos La instalación del SMT Moses1 se ejecutará desde Linux. Antes de empezar con la instalación es importante asegurar de que tengamos instalados los siguientes paquetes que se pueden descargar desde el Administrador de paquetes Synaptic: Instalar desde el Administrador de paquetes Synaptic los siguientes paquetes:  Gcc  G++  Make  Gawk  Gzip  Tcl8.5  Tcl8.5-dev  Csh  Autoconf  Automake 1.9  Texinfo  Zlib1g  Zlib1g-dev  Zlib-bin  Zlibc  Libtool 1 http://www.statmt.org/moses/ Fig. 1 Administrador de paquetes Synaptic de Linux Anexo A. Guía de instalación del SMT Moses 53 Instalación Giza++ Descargar y descomprimir en la carpeta tools/ la herramienta GIZA++2 http://code.google.com/p/giza-pp/downloads/list Antes de compilar debemos modificar el archivo file_spec.h, situado dentro de la carpeta giza-pp/GIZA++/ Aquí dejo un ejemplo de lo que debe contener ese archivo: #ifndef FILE_SPEC_H #define FILE_SPEC_H #include <time.h> #include <stdlib.h> #include <string.h> #include <stdio.h> char *Get_File_Spec (){ struct tm *local; time_t t; char *user; char time_stmp[19]; char *file_spec = 0; t = time(NULL); local = localtime(&t); sprintf(time_stmp, "%04d-%02d-%02d.%02d%02d%02d.", 1900 + local->tm_year, (local->tm_mon + 1), local->tm_mday, local->tm_hour, local->tm_min, local- >tm_sec); user = getenv("USER"); file_spec = (char *)malloc(sizeof(char) * (strlen(time_stmp) + strlen(user) + 1)); file_spec[0] = '\0'; strcat(file_spec, time_stmp) ; strcat(file_spec, user); return file_spec; } #endif Una vez modificado el archivo ya podremos compilar GIZA++ $ make Se generará unos archivos ejecutables (GIZA++, mkcls, snt2cooc.out) donde los copiaremos en una nueva carpeta llamada por ejemplo “/bin”. 2 http://code.google.com/p/giza-pp/ 54 Anexo A. Guía de instalación del SMT Moses $ mkdir tools/bin $ cd tools $ cp giza-pp/GIZA++-v2/GIZA++ bin/ $ cp giza-pp/mkcls-v2/mkcls bin/ $ cp giza-pp/GIZA++-v2/snt2cooc.out bin/ Instalación SRILM Descargar y descomprimir en la carpeta tools/ la herramienta SRILM3 http://www-speech.sri.com/projects/srilm/download.html Antes de compilarlo, editaremos el fichero Makefile. Es posible que este fichero no tenga permisos de escritura, para ello escribimos: $ chmod +w Makefile Dentro del archivo Makefile editamos la ruta del SRILM: SRILM = /home/javier.marin/demo/tools/srilm Abrimos el archivo Makefile.machine.XXX que está dentro de la carpeta common/, donde “XXX” representa el valor del tipo de máquina. Podemos comprobar que tipo de máquina que tenemos con la siguiente comanda: $ ./srilm/sbin/machine-type Sobre ese archivo reemplazamos las siguientes líneas: # Tcl support (standard in Linux) TCL_INCLUDE = -I/usr/include/tcl8.5/ TCL_LIBRARY = -L/usr/lib/libtcl8.5.so A continuación compilamos: $ sudo make $ sudo make World 3 http://www-speech.sri.com/projects/srilm/ Anexo A. Guía de instalación del SMT Moses 55 Instalación Moses Descargar y descomprimir en la carpeta tools/ el decodificador Moses http://sourceforge.net/projects/mosesdecoder/files/ Una vez descomprimido, ejecutamos los siguientes scripts: $ ./regenerate-makefiles.sh $ ./configure --with-srilm=/home/javi-ubuntu/demo/tools/srilm Y compilamos: $ make -j 4 Scripts de apoyo de Moses Moses usa una serie de scripts de soporte para el entrenamiento, tunning y otras tareas. Creamos una carpeta moses-scripts/. Editamos las rutas siguientes del archivo Makefile de la carpeta ../moses/scripts/ TARGETDIR?=/home/usuario/demo/tools/moses-scripts BINDIR?=/home/usuario/demo/tools/bin La primera línea define donde está la carpeta que habíamos creado anteriormente y en la segunda línea define la ruta de los archivos ejecutables del GIZA++. $ cd moses/scripts $ make release Una vez compilado se habrá creado una carpeta del tipo “scripts-YYYYMMDD-HHMM” dentro de la carpeta moses-scripts/. Por último abriremos el archivo train-model.perl situado en la carpeta scriptsYYYYMMDD-HHMM/training/. Este archivo contiene una serie de funciones para ejecutar el entrenamiento de un corpus paralelo. La función que debemos modificar se llama reduce_factors(), a continuación dejo un ejemplo de lo que debe contener esa función: sub reduce_factors { my ($full,$reduced,$factors) = @_; print STDERR "(1.0.5) reducing factors to produce $reduced @ ".`date`; while(-e $reduced.".lock") { sleep(10); } if (-e $reduced) { print STDERR " $reduced in place, reusing\n"; return; } 56 Anexo A. Guía de instalación del SMT Moses `touch $reduced.lock`; # my %INCLUDE; # foreach my $factor (split(/,/,$factors)) { # $INCLUDE{$factor} = 1; # } my @INCLUDE = sort {$a <=> $b} split(/,/,$factors); *IN = open_or_zcat($full); open(OUT,">".$reduced) or die "ERROR: Can't write $reduced"; my $nr = 0; while(<IN>) { $nr++; print STDERR "." if $nr % 10000 == 0; print STDERR "($nr)" if $nr % 100000 == 0; chomp; s/ +/ /g; s/^ //; s/ $//; my $first = 1; foreach (split) { my @FACTOR = split /\Q$___FACTOR_DELIMITER/; # \Q causes to disable metacharacters in regex print OUT " " unless $first; $first = 0; my $first_factor = 1; foreach my $outfactor (@INCLUDE) { print OUT "|" unless $first_factor; $first_factor = 0; my $out = $FACTOR[$outfactor]; die "ERROR: Couldn't find factor $outfactor in token \"$_\" in $full LINE $nr" if !defined $out; print OUT $out; } # for(my $factor=0;$factor<=$#FACTOR;$factor++) { # next unless defined($INCLUDE{$factor}); # print OUT "|" unless $first_factor; # $first_factor = 0; # print OUT $FACTOR[$factor]; # } } print OUT "\n"; } print STDERR "\n"; close(OUT); close(IN); `rm -f $reduced.lock`; } Anexo B. Formato de archivo .sgm 57 ANEXO B. FORMATO DE ARCHIVO .SGM Formato de archivo de origen Contiene la etiqueta “<srcset>” y los siguientes atributos: - “setid” : El conjunto de datos - “srclang”: La lengua de origen La etiqueta “<srcset>” contiene uno o más elementos “doc”, que tendrá las siguientes atribuciones: - “docid”: El documento - “genre”: El tipo de dato Cada elemento “doc” contiene varios segmentos (elementos “seg”). Cada segmento tiene un atributo único, “id”, que debe incluir el uso de comillas dobles. Ejemplo: <srcset setid="meteo" srclang="any"> <DOC docid="meteo"> <seg id="1"> dijous , 22 de novembre de 2007</seg> … </DOC> </srcset> Formato de archivo de referencia Contiene una o más etiquetas “<refset>”. Cada etiqueta “<refset>” contiene los siguientes atributos: - “setsid”: El conjunto de datos - “srclang”: La lengua origen - “trglang”: La lengua destino - “refid”: La referencia actual El formato de los elementos del documento es exactamente igual como el archivo de origen descrito anteriormente. Ejemplo: <refset setid="meteo" srclang="any" trglang="lsc"> <DOC docid="meteo" sysid="ref"> <seg id="1"> dijous després dia 22 mes novembre any 2007</seg> … </DOC> </refset> 58 Anexo B. Formato de archivo .sgm Formato de archivo de test Un archivo de traducción contiene una o más etiquetas “<tstset>”. Cada “<tstset>” contiene los siguientes atributos: - “setid”: El conjunto de datos - “srclang”: La lengua origen - “trglang”: La lengua destino - “sysid”: Un nombre de identificación del sitio y sistema El contenido de cada “<tstset>” es exactamente igual que los archivos de origen y referencia. Ejemplo: <tstset setid="meteo" srclang="any" trglang="lsc" sysid=”meteo”> <DOC docid="meteo" sysid="ref"> <seg id="1"> dijous després dia 22 mes novembre any 2007</seg> … </DOC> </tstset> Anexo C. Formato de archivo .jnlp 59 ANEXO C. FORMATO DE ARCHIVO .JNLP Un archivo JNLP es un XML especialmente formado compuesto por:  Una cabecera XML típica.  Una ruta predeterminada para que los archivos puedan ser llamados desde un path relativo.  Una o varias etiquetas “information” en que van varias informaciones.  Una etiqueta “resources”.  Una etiqueta “security”.  Una etiqueta “aplication-desc” con la clase predeterminada a ejecutar. El ejemplo mostrado no incluye todas las posibles opciones. Hay muchas más que pueden verse desde la documentación de Java: http://download.oracle.com/javase/6/docs/technotes/guides/javaws/ 60 Anexo D. Lista de símbolos HamNoSys ANEXO D. LISTA DE SÍMBOLOS HAMNOSYS Representación de los símbolos HamNoSys en forma icónica y textual para la codificación SiGML.  hamalternatingmotion  hamarmextended  hambelowstomach  hamcee12  hamceeall  hamceeopen  hamcheek  hamchest  hamchin  hamclose  hamear  hamearlobe  hamelbowinside  hamextfingerd  hamextfingerdi  hamextfingerdl  hamextfingerdo  hamextfingerdr  hamextfingeri  hamextfingeril  hamextfingerir  hamextfingerl  hamextfingero  hamextfingerol  hamextfingeror  hamextfingerr  hamextfingeru  hamextfingerui  hamextfingerul  hamextfingeruo  hamextfingerur  hameyebrows  hameyes  hamfinger2  hamfinger23  hamfinger2345  hamfinger23spread  hamfingerbase  hamfingermidjoint  hamfingernail  hamfingerpad  hamfingertip  hamfist  hamflathand  hamforehead  hamfusionbegin  hamfusionend  hamhandback  hamhead  hamheadtop