Documentaci ´on del sistema de c ´odigo abierto Opentrad Apertium

Documentación del sistema de código
abierto Opentrad Apertium de
traducción automática de transferencia
sintáctica superficial
AUTORES:
Mikel L. Forcada
Boyan Ivanov Bonev
Sergio Ortiz Rojas
Juan Antonio Pérez Ortiz
Gema Ramı́rez Sánchez
Felipe Sánchez Martı́nez
COORDINADORA:
Mireia Ginestı́ Rosell
Departament de Llenguatges i Sistemes Informàtics
Universitat d’Alacant
29 de enero de 2008
c
Copyright °2006
Grup Transducens, Universitat d’Alacant. Se
otorga permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia de Documentación Libre
de GNU, Versión 1.2 o cualquier otra versión posterior publicada por la Free Software Foundation; sin Secciones Invariantes
ni Textos de Cubierta Delantera ni Textos de Cubierta Trasera.
Una copia de la licencia se puede consultar en http://www.
gnu.org/copyleft/fdl.html. En http://gugs.sindominio.
net/licencias/gfdl-1.2-es.html puede leerse la traducción no oficial de la licencia al español, en http://www.softcatala.
org/llicencies/fdl-ca.html la traducción no oficial al
catalán y en http://members.tripod.com.br/RamonFlores/
GNU/gpl.html la traducción no oficial al gallego.
Índice general
Introducción
1
1. El ingenio de traducción
5
2. Especificación del formato de flujo
2.1. Introducción . . . . . . . . . . .
2.2. Flujo de datos sin formato . . .
2.2.1. Formato de flujo . . . .
2.3. Flujo de datos segmentado . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
. 11
. 13
. 14
. 15
3. Especificación de los módulos
3.1. Módulos de procesamiento léxico . . . . . . . . . . . . . . . .
3.1.1. Descripción del funcionamiento . . . . . . . . . . . .
3.1.2. Formato de los datos: los diccionarios . . . . . . . . .
3.1.3. Generación automática de los módulos . . . . . . . .
3.2. Desambiguador léxico categorial . . . . . . . . . . . . . . . .
3.2.1. Descripción del funcionamiento . . . . . . . . . . . .
3.2.2. Datos para el desambiguador léxico categorial . . . .
3.2.3. Consideraciones sobre el entrenamiento del desambiguador léxico categorial . . . . . . . . . . . . . . . .
3.3. Preproceso de la transferencia . . . . . . . . . . . . . . . . . .
3.3.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2. Comportamiento y ejemplo . . . . . . . . . . . . . . .
3.4. Módulo de selección léxica . . . . . . . . . . . . . . . . . . . .
3.4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . .
3.4.2. Preprocesamiento de los diccionarios bilingües . . . .
3.4.3. Funcionamiento del módulo de selección léxica . . .
3.5. Módulo de transferencia estructural . . . . . . . . . . . . . .
3.5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . .
3.5.2. Transferencia sintáctica superficial . . . . . . . . . . .
3.5.3. Transferencia sintáctica avanzada . . . . . . . . . . .
III
17
17
17
20
55
57
57
58
62
67
67
67
68
68
71
73
76
76
77
80
ÍNDICE GENERAL
IV
3.5.4. Especificación del formato de las reglas de transferencia estructural . . . . . . . . . . . . . . . . . . . . .
3.5.5. Especificación de los tres módulos del sistema de
transferencia avanzada . . . . . . . . . . . . . . . . . .
3.5.6. Preproceso del módulo de transferencia estructural .
3.6. Desformateador y reformateador . . . . . . . . . . . . . . . .
3.6.1. Funcionamiento . . . . . . . . . . . . . . . . . . . . . .
3.6.2. Datos: reglas de especificación de formato . . . . . .
3.6.3. Generación de formateadores y desformateadores . .
4. Instalación y ejecución del sistema
4.1. Requisitos del sistema . . . . . . . . . . .
4.2. Instalación de los paquetes de programas
4.3. Instalación de los paquetes de datos . . .
4.4. Ejecución del traductor . . . . . . . . . . .
83
110
118
118
118
122
125
.
.
.
.
129
129
129
131
131
5. Mantenimiento de datos lingüı́sticos
5.1. Descripción de los datos lingüı́sticos . . . . . . . . . . . . .
5.2. Introducir palabras en los diccionarios . . . . . . . . . . . .
5.2.1. Añadir restricciones de dirección . . . . . . . . . . .
5.2.2. Añadir multipalabras . . . . . . . . . . . . . . . . .
5.2.3. Colaborar en la mejora de datos léxicos . . . . . . .
5.3. Introducir reglas de transferencia . . . . . . . . . . . . . . .
5.4. Añadir datos al desambiguador léxico . . . . . . . . . . . .
5.5. Detección de errores . . . . . . . . . . . . . . . . . . . . . .
5.5.1. Control de las marcas de error . . . . . . . . . . . .
5.5.2. Salida de los diferentes módulos de Apertium . . .
5.5.3. Ejemplos de errores . . . . . . . . . . . . . . . . . . .
5.5.4. Comprobación de la integridad de los diccionarios
5.6. Generar un nuevo sistema con los nuevos datos . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
135
135
137
143
145
150
151
158
161
161
162
166
167
168
6. Formularios web de inserción de datos
6.1. Introducción . . . . . . . . . . . . . .
6.2. Instalación y administración . . . . .
6.2.1. Instalación de la herramienta
6.2.2. Estructura de directorios . . .
6.2.3. Ficheros php . . . . . . . . . .
6.2.4. Ficheros de diccionario . . . .
6.2.5. Ficheros de paradigmas . . .
6.3. Utilización de los formularios . . . .
6.3.1. Introducción . . . . . . . . . .
.
.
.
.
.
.
.
.
.
169
169
169
169
171
173
181
181
185
185
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ÍNDICE GENERAL
V
6.3.2. Inserción de entradas . . . . . . . . . . . . . . . . . . . 186
6.3.3. Validación de entradas pendientes de aprobación . . 187
A. DTDs en XML
A.1. DTD para el formato de los diccionarios . . . . . . . . . . . .
A.1.1. Modificación en la DTD de diccionarios para selección léxica . . . . . . . . . . . . . . . . . . . . . . . . .
A.2. DTD para el desambiguador . . . . . . . . . . . . . . . . . . .
A.3. DTD del módulo chunker . . . . . . . . . . . . . . . . . . . .
A.4. DTD del módulo interchunk . . . . . . . . . . . . . . . . . . .
A.5. DTD del módulo postchunk . . . . . . . . . . . . . . . . . . .
A.6. DTD para reglas de formato . . . . . . . . . . . . . . . . . . .
A.7. DTD de los paradigmas del formulario . . . . . . . . . . . . .
189
189
B. Sı́mbolos gramaticales
B.1. Sı́mbolos de los diccionarios . . . . . . .
B.1.1. Lista de sı́mbolos . . . . . . . . .
B.1.2. Especificación de formas léxicas
B.2. Categorı́as del desambiguador . . . . .
B.2.1. Desambiguador de español . . .
B.2.2. Desambiguador de catalán . . .
B.2.3. Desambiguador de gallego . . .
209
210
210
212
214
214
216
217
C. Abreviaturas usadas en el texto
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
190
191
192
197
201
205
207
219
VI
ÍNDICE GENERAL
Introducción
La presente documentación describe el sistema Opentrad Apertium1 , uno
de los sistemas de traducción automática de código abierto creados en el
marco del proyecto ”Traducción automática de código abierto para las lenguas del estado español”
[Nota: Posem un resum de les dades del projecte en un apèndix (codi, durada, finançament, participants, etc.) i hi fem referència acı́? Mikel]
. Se trata de un sistema de traducción automática de transferencia sintáctica superficial y está pensado inicialmente para la traducción entre pares de lenguas relacionadas, aunque algunos de sus componentes se han
utilizado también en la arquitectura de transferencia sintáctica profunda
(Opentrad Matxin) que se ha desarrollado en el mismo proyecto para el
par español–euskera. Apertium traduce actualmente entre los pares español–gallego y español–catalán2 , y puede utilizarse para la construcción de
traductores entre otros pares de lenguas relacionadas como danés–sueco,
checo–eslovaco, etc.
Los demás sistemas de traducción automática disponibles hasta el momento para los pares es–ca y es–gl son mayoritariamente comerciales
o utilizan tecnologı́a de propiedad, con lo que es muy difı́cil adaptarlos
a nuevos usos; además, utilizan diferentes tecnologı́as para los distintos
pares de lenguas, lo que hace muy difı́cil integrarlos en un único sistema
de gestión de contenidos multilingües.
Una de las principales novedades de la arquitectura que presentamos
es que se ha liberado bajo una licencia de código abierto (licencia GNU
GPL para los programas y Creative Commons para los datos) y es de distribución gratuita. Esto significa que cualquier persona que tenga los conocimientos lingüı́sticos e informáticos necesarios podrá adaptar o ampliar
1
En adelante, nos referiremos a él simplemente como Apertium
Con la denominación catalán nos referimos también a la variante dialectal valenciana
de este idioma.
2
1
2
ÍNDICE GENERAL
el producto para crear un nuevo sistema de traducción automática, incluso para nuevos pares de lenguas relacionadas. Esperamos, por ello, que
la introducción de esta arquitectura de traducción automática de código
abierto solucione algunos de los problemas mencionados (existencia de diferentes tecnologı́as para diferentes pares, dificultad de adaptación de las
arquitecturas de código cerrado a nuevos usos, etc.) y favorezca el intercambio de datos lingüı́sticos ya existentes utilizando los formatos basados
en XML que se definen en esta documentación. Al mismo tiempo, creemos
que ayudará a cambiar el modelo de negocio actual en este campo, basado
en licencias, por un modelo basado en la prestación de servicios.
Cabe mencionar que es la primera vez que el Gobierno español ha subvencionado un proyecto de código abierto de esta envergadura, aunque
la adopción de software de código abierto por las administraciones españolas no es algo nuevo.
En los capı́tulos de la presente documentación se explican detalladamente las caracterı́sticas del sistema Apertium, con la información organizada de la siguiente manera:
Capı́tulo 1: descripción general del sistema de traducción automática de transferencia superficial y de los módulos de los que se compone.
Capı́tulo 2: descripción del formato del flujo de los datos que circulan de un módulo a otro.
Capı́tulo 3: especificación de los módulos del sistema. Para cada
módulo se describe: el funcionamiento del módulo, el formato de los datos
sobre los que trabaja el módulo, y los compiladores correspondientes.
Este capı́tulo se divide en las siguientes secciones:
- sección 3.1: Módulos de procesamiento léxico, en la que se describe el funcionamiento del analizador morfológico, del módulo
de transferencia léxica, del generador morfológico y del postgenerador (apartado 3.1.1), el formato de los diccionarios con los
que trabajan estos módulos (apartado 3.1.2) y los compiladores
de los mismos (apartado 3.1.3)
- sección 3.2: Desambiguador léxico categorial, en la que se describe
el funcionamiento del desambiguador (apartado 3.2.1), el formato de los datos lingüı́sticos con los que trabaja (apartado 3.2.2.
[Nota: falta parlar del lextor, i afegir-ho a tot arreu on es parli
dels mòduls del sistema]
ÍNDICE GENERAL
3
- sección 3.3: Módulo de preproceso del transfer, en la que se describe el módulo que se ejecuta antes del módulo de transferecia estructural para realizar ciertas operaciones en las unidades
multipalabra
- sección 3.5: Módulo de transferencia estructural, en la que se describe el funcionamiento del módulo (apartado 3.5.2) y el formato de las reglas de transferencia estructural (apartado 3.5.4).
- sección 3.6: Desformateador y reformateador, en la que se describe
el funcionamiento de estos módulos (apartado 3.6.1), las reglas
de especificación de formato (apartado 3.6.2) y el proceso de
generación de los módulos (apartado 3.6.3)
Capı́tulo 4: describe cómo instalar el sistema y cuáles son los requisitos para ello, ası́ como la manera de utilizar el traductor.
Capı́tulo 5: describe cómo se pueden modificar los datos lingüı́sticos del traductor, es decir, los diccionarios, los datos de desambiguación léxica categorial y las reglas de transferencia estructural que se
han creado para el español, el catalán, el gallego. Además, aquı́ se
describen brevemente las caracterı́sticas de los datos existentes para
los tres pares de lenguas del proyecto.
[Nota: Es diuen a tot arreu els noms de programa i en quin paquet estan?]
Los ficheros a los que hace referencia este informe se pueden consultar y descargar desde la página web del proyecto en Sourceforge: http:
//apertium.sourceforge.net/. En esta página se pueden descargar
los paquetes para la instalación, ası́ como consultar los archivos individualmente, en el repositorio de CVS (http://cvs.sourceforge.net/
viewcvs.py/apertium/). Los sistemas de traducción automática también se pueden probar a través de internet en http://xixona.dlsi.
ua.es/prototype/.
Agradecimientos:
El presente trabajo se ha beneficiado de las aportaciones de muchas
personas e instituciones:
El Ministerio de Industria, Comercio y Turismo ha financiado este trabajo a través del proyecto “Traducción automática de código
abierto para las lenguas del Estado español” del programa PROFIT,
claves FIT-340101-2004-3 y su ampliación FIT-340001-2005-2.
4
ÍNDICE GENERAL
Trabajadores y becarios de otros proyectos de traducción automática de la Universidad de Alicante: Mı́riam Antunes Scalco, Carme
Armentano i Oller, Raül Canals i Marote, Alicia Garrido Alenda,
Patrı́cia Gilabert i Zarco, Maribel Guardiola i Savall, Javier Herrero Vicente, Amaia Iturraspe Bellver, Sandra Montserrat i Buendia,
Hermı́nia Pastor Pina, Antonio Pertusa Ibáñez, Francisco Javier Ramos Salas, Marcial Samper Asensio y Miguel Sánchez Molina.
Las empresas e instituciones que han financiado estos otros proyectos de traducción automática: el Ministerio de Ciencia y Tecnologı́a,
la Caja de Ahorros del Mediterráneo, la Universitat d’Alacant y Portal Universia, S.A.
Iñaki Alegria, del grup Ixa de la Euskal Herriko Unibertsitatea, por
su lectura atenta de versiones anteriores de este documento.
ADVERTENCIA: Algunas partes de esta documentación están provisionalmente en catalán, a la espera de su traducción al español.
Capı́tulo 1
El ingenio de traducción de
transferencia sintáctica superficial
Este capı́tulo describe brevemente la estructura del ingenio de traducción automática de transferencia superficial, basado en el de los sistemas
español–catalán interNOSTRUM [2, 5, 4] y español–portugués Traductor
Universia [7, 17], ambos desarrollados por el grupo Transducens de la Universitat d’Alacant. Se trata de un sistema clásico de traducción automática
indirecta que utiliza una estrategia de transferencia sintáctica parcial similar a la de algunos sistemas comerciales de TA para ordenadores personales.
El diseño del sistema permite obtener sistemas de TA rápidos (que traducen decenas de miles de palabras por segundo en ordenadores de sobremesa comunes) y cuyos resultados son, a pesar de los errores, razonablemente inteligibles y fáciles de corregir. En el caso de lenguas emparentadas como las que nos ocupan (español, gallego, catalán), una traducción
mecánica palabra por palabra (con un equivalente fijo) presentarı́a errores
que, en su mayorı́a, se pueden resolver con un análisis bastante somero
(un análisis morfológico seguido de un análisis sintáctico superficial, local y parcial) y con un tratamiento adecuado de las ambigüedades léxicas
(principalmente de la homografı́a). El diseño adoptado sigue estas directrices con resultados muy interesantes. La arquitectura de Apertium utiliza transductores de estados finitos para el procesamiento léxico, modelos
ocultos de Markov para la desambiguación léxica y procesamiento de patrones basado en estados finitos para la transferencia estructural.
El ingenio de traducción consiste en una cadena de montaje de ocho
módulos, que puede verse representada en la figura 1.1. Para facilitar el
diagnóstico y la comprobación independiente, los módulos se comunican
entre sı́ en formato de texto. De esta manera, siempre que se quiera se
5
CAPÍTULO 1. EL INGENIO DE TRADUCCIÓN
6
texto
LO
↓
postdesfor- → anal. → desamb. → transf. → gen. →
reformagenera- →
categ.
morf.
mateador
morf.
estruc.
teador
dor
l
↓
texto
transf.
LM
léxica
Figura 1.1: Los ocho módulos que forman la cadena de montaje del sistema de
traducción automática por transferencia sintáctica superficial.
puede comprobar cuál es la entrada y la salida de los mismos y, cuando se
produce algún error en la traducción, examinar por separado la salida de
cada uno de ellos para detectar dónde se localiza el error. Asimismo, la comunicación vı́a texto permite que los módulos se usen de manera aislada,
independientemente del resto del sistema de traducción automática, para
otras tareas de procesamiento del lenguaje natural, y posibilita la construcción de prototipos con módulos modificados o añadidos.
Se ha elegido que el formato de los ficheros de datos lingüı́sticos sea
XML1 por su interoperabilidad, por su independencia del juego de caracteres y por la existencia de numerosos útiles y librerı́as que facilitan el
análisis de los datos codificados en este formato. Como bien se afirma en
[8], XML es el estándar emergente para la representación y el intercambio
de datos en Internet. Las tecnologı́as en torno a XML incluyen mecanismos muy potentes para el acceso y la manipulación de documentos XML
que probablemente tendrán un impacto significativo en el desarrollo de
herramientas para el procesamiento del lenguaje de natural y de corpus
anotados.
Los módulos de los que se compone Apertium son los siguientes:
El desformateador, que separa el texto a traducir de la información
de formato (RTF, HTML, etc.); su especificación se describe en el
apartado 3.6.1. La información de formato es encapsulada de manera que los módulos restantes la tratan como blancos entre palabras.
Por ejemplo, ante el texto HTML en español:
es <em>una señal</em>
1
http://www.w3.org/XML/
7
el desformatador encapsula las etiquetas HTML entre corchetes y
proporciona como salida:
es [<em>]una señal[</em>]
Las secuencias de caracteres entre corchetes son tratadas por el resto
de módulos como simples espacios en blanco entre palabras.
El analizador morfológico, que segmenta el texto en formas superficiales (FS) (las unidades léxicas tal como se presentan en los textos) y
entrega para cada FS una o más formas léxicas (FL) consistentes en
un lema (la forma base comúnmente usada para las entradas de los
diccionarios clásicos), la categorı́a léxica (nombre, verbo, preposición,
etc.) y la información de flexión morfológica (número, género, persona, tiempo, etc.). La división de un texto en FS presenta aspectos
complejos debido a la existencia, por un lado, de contracciones (del,
teniéndolo, vámonos) y, por otro, de unidades léxicas de más de una
palabra (a pesar de, echó de menos). El analizador morfológico permite
analizar estas FS complejas y tratarlas adecuadamente para que sean
procesadas por los módulos posteriores. En el caso de las contracciones, el sistema lee una única forma superficial y da como salida una
secuencia de dos o más formas léxicas (por ejemplo, la contracción
del serı́a analizada como dos formas léxicas, una para la preposición
de y otra para el artı́culo el). Las unidades léxicas de más de una palabra (multipalabras) son tratadas como formas léxicas individuales
y, según su naturaleza, reciben un tratamiento especı́fico.2
Al recibir como entrada el texto de ejemplo proveniente del módulo
anterior, el analizador morfológico proporcionarı́a como salida:
ˆes/ser<vbser><pri><p3><sg>$[ <em>]
ˆuna/un<det><ind><f><sg>/unir<vblex><prs><1><sg>/unir
<vblex><prs><3><sg>$
ˆseñal/señal<n><f><sg>$[</em>]
donde cada forma superficial es analizada como una o más formas
léxicas. Ası́, es es analizada como una FS con lema ser, mientras que
una recibe tres análisis: lema un, determinante indefinido femenino
singular; lema unir, verbo en presente de subjuntivo, 1a persona del
2
Para más detalles sobre la el tratamiento de las unidades léxicas de más de una palabra, véase la página 44.
8
CAPÍTULO 1. EL INGENIO DE TRADUCCIÓN
singular, y lema unir, verbo en presente de subjuntivo, 3a persona del
singular.
Este módulo se genera a partir de un diccionario morfológico para la
lengua origen (LO), cuyo formato se especifica en el apartado 3.1.2.
El desambiguador léxico categorial, elige, usando un modelo estadı́stico
(modelo oculto de Markov), uno de los análisis de una palabra ambigua de acuerdo con su contexto; en el ejemplo utilizado, la palabra
ambigua serı́a la forma superficial una, que puede analizarse de tres
maneras diferentes. Las formas superficiales ambiguas por tener más
de un lema, más de una categorı́a o representar más de una flexión
son muy comunes (en las lenguas románicas, en torno a una de cada
tres palabras) y son una fuente muy importante de errores de traducción en caso de elegir el equivalente incorrecto. El modelo estadı́stico
se entrena sobre corpus suficientemente representativos de textos en
LO.
El resultado de procesar mediante el desambiguador el texto de ejemplo proporcionado por el analizador morfológico serı́a:
ˆser<vbser><pri><p3><sg>$[ <em>]ˆun<det><ind><f><sg>$
ˆseñal<n><f><sg>$[</em>]
en que se ha elegido la forma léxica correcta (el determinante) para
la palabra una.
La especificación del desambiguador léxico categorial se describe en
la sección 3.2.
El módulo de transferencia léxica, que gestiona un diccionario bilingüe
y es invocado por el módulo de transferencia estructural, lee cada
FL en LO y entrega la FL correspondiente en lengua meta (LM). El
diccionario contiene un único equivalente para cada forma léxica de
la LO; esto significa que no se realiza ningún tipo de tratamiento de
la polisemia. Las multipalabras son traducidas como una unidad. En
el ejemplo utilizado, cada una de las formas léxicas se traducirı́a al
catalán de la siguiente manera:
ser<vbser> −→ ser<vbser>
un<det> −→ un<det>
señal<n><f> −→ senyal<n><m>
9
Este módulo se genera a partir de un diccionario bilingüe, descrito
en el apartado 3.1.2).
El módulo de transferencia estructural, que detecta y trata patrones de
palabras (sintagmas) que exigen un tratamiento especial por causa de las divergencias gramaticales entre las lenguas (cambios de
género y número, reordenamientos, cambios preposicionales, etc.).
Este módulo se genera a partir de un archivo de reglas que describen la acción que debe realizarse para cada patrón. Ante la frase de ejemplo, el patrón formado por ˆun<det><ind><f><sg>$
ˆseñal<n><f><sg>$ serı́a detectado por una regla determinante–
nombre, que en este caso modificarı́a el género del determinante para que concuerde con el nombre; el resultado serı́a:
ˆser<vbser><pri><p3><sg>$[ <em>]ˆun<det><ind><m><sg>$
ˆsenyal<n><m><sg>$[</em>]
La especificación del formato del archivo de reglas de transferencia
estructura, que se inspira en la descrita en [5], se encuentra en la
sección 3.5.
El generador morfológico, que genera a partir de la forma léxica en lengua meta una forma superficial flexionada adecuadamente. El resultado para la frase de ejemplo serı́a:
és[ <em>]un senyal[</em>]
Este módulo se genera a partir de un diccionario morfológico, cuyas
caracterı́sticas están descritas en el apartado 3.1.2.
El postgenerador, que realiza algunas operaciones ortográficas en LM
tales como contracciones y apostrofaciones, y que es generado a partir de un archivo de reglas de transformación con un formato similar
al de los diccionarios anteriores. Su formato se especifica en la sección 3.1.2. En la frase de ejemplo utilizada no hay que realizar ninguna contracción ni apostrofación.
El reformateador, que reintegra la información de formato original al
texto traducido; el resultado para la frase de ejemplo serı́a la correcta
conversión del texto a formato HTML:
és <em>un senyal</em>
10
CAPÍTULO 1. EL INGENIO DE TRADUCCIÓN
La especificación del reformateador se describe en la sección 3.6.1.
Los cuatro módulos de procesamiento léxico (el analizador morfológico, el módulo de transferencia léxica, el generador morfológico y el postgenerador) utilizan un único compilador, basado en un tipo de transductores
de estados finitos [4], concretamente en transductores de letras [14, 11] cuyas
caracterı́sticas se explican en 3.1.3.
Capı́tulo 2
Especificación del formato del
flujo de datos entre módulos
[Nota: Material duplicat en ”formatadors i reformatadors”: declararho, treure-ho? - Gema]
2.1. Introducción
Para enteder y hacer más efectivo el procesamiento de documentos es
necesario especificar el formato de la información que circula como texto
entre los módulos del traductor. El diseño propuesto (véase sección 1) impone la necesidad de utilizar tres tipos de flujo de datos distintos como se
expresa en la figura 2.1.
El formato de flujo está basado en texto para facilitar, entre otras cosas,
la tarea de diagnóstico sobre posibles errores del sistema ya que resulta sencillo manipular el flujo para reproducir aquellos fenómenos que se
desee probar y modificarlos para comprobar el resultado. Otra ventaja destacable es la posibilidad de comprobar de manera independiente la salida
de cada módulo del traductor y, junto a esto, la rapidez en la construcción
de prototipos para comprobar su funcionamiento global, la validez de los
datos lingüı́sticos, etc.
Estos flujos de datos son:
Flujo de datos con formato: Es el texto en su formato original, sin ningún
otro tipo de marca: XML, texto ANSI, RTF, HTML, etc. Por ser el formato original de los documentos, de este flujo de datos no hay nada
que especificar salvo el tipo de formato de que se trata.
11
12
CAPÍTULO 2. ESPECIFICACIÓN DEL FORMATO DE FLUJO
Figura 2.1: Los diversos tipos de flujo de datos en el sistema de traducción automática. Véase el texto para la definición de los diferentes tipos de flujo.
Flujo de datos sin formato: Consiste en el texto con superblancos, marcas que encapsulan el formato (véase el apartado 3.6.1) y que son
tratadas como si de blancos se tratase (con algunas salvedades) por
los módulos lingüı́sticos del sistema. Este formato es el que genera
el desformateador, y el que utiliza el reformateador para generar el
documento traducido final.
Flujo de datos segmentado: Además de superblancos, este formato tiene delimitadas mediante marcas las unidades léxicas que se debe traducir. Estas marcas son establecidas por el analizador morfológico, y
son eliminadas por el generador, que entrega las formas superficiales
finales.
A continuación describiremos las caracaterı́sticas del flujo de datos empleado entre módulos del traductor. A grandes rasgos, se trata de un forTexto
Texto
mato
en texto llano con marcas de carácter que poseen un significado
esorigen
meta
pecial. Dicho formato está orientado al procesamiento en servidores que
Flujo de texto segmentado
traduzcan grandes volúmenes
de texto.
Flujo de texto sin formato
Flujo
texto original
Algunos de los formatos quedepuede
tratar el traductor pueden contener
bloques extensos de información en formato binario —como por ejemplo
RTF, que puede incluir imágenes de mapa de bits—. Para facilitar un proDes- cesamiento
Analizador
Transfer.
Re- el apareficiente
de este tipo
de documentos
se Postespecifica en
Etiquetador
Generador
formateador
morfólogico
estructural
generador
formateador
tado 3.6.1 una forma de extraer esta información para restituirla tras la
traducción.
Transfer.
léxica
2.2. FLUJO DE DATOS SIN FORMATO
2.2.
13
Flujo de datos sin formato
El flujo de datos sin formato es producido como salida por el desformateador y por el generador
[Nota: no del tot: postgenerador]
, y es usado como entrada por el analizador morfológico, por el postgenerador y por el reformateador.
En el subapartado de esta sección se especifica la forma de delimitar
superblancos y superblancos extensos. Para los ejemplos, tomaremos como
referencia el documento HTML de la figura 2.2.
<html>
<head>
<title>Tı́tulo</title>
</head>
<body>
<p>Frase
dividida</p>
</body>
</html>
Figura 2.2: Ejemplo de documento HTML
Los elementos estructurales que debe incluir este flujo de datos son los
siguientes:
Superblancos. Se trata de bloques que incluyen segmentos de información de formato incluida en los documentos, cuando estos son
cortos.
Superblancos extensos. Son marcas que se usan para especificar aquellos documentos externos que incluyan segmentos de información
de formato del documento que se está procesando, cuando estos son
largos.
Texto. El texto de los documentos susceptible de ser traducido.
Finales de frase artificiales. Cuando el formato de los documento induzca una separación de frases que no esté marcada por ningún
signo de puntuación (por ejemplo, los tı́tulos que no acaban en punto
o el contenido de las celdillas de una tabla), el formato debe instrumentar un mecanismo (invisible para el usuario) que permita marcar
estos finales de frase.
CAPÍTULO 2. ESPECIFICACIÓN DEL FORMATO DE FLUJO
14
Protección de caracteres especiales (para el caso del flujo no XML). Los
caracteres que se deben proteger para que no entren en conflicto con
los usados en el propio formato del flujo de datos.
2.2.1.
Formato de flujo
Este formato se basa en el formato utilizado en los sistemas de traducción interNOSTRUM [2, 5, 4] y Traductor Universia [7, 17].
En este tipo de flujo se usan los carácteres [ y ] para marcar los superblancos tal y como se muestra a continuación:
[contenido del superblanco]
Si se trata de superblancos extensos, el nombre del fichero se especifica
utilizando el carácter de arroba @:
[@nombre de fichero]
El texto se encuentra fuera de las marcas de superblanco.
Los finales de frase artificialesse expresan mediante un punto y un superblanco vacı́o inmediatamente a continuación.
.[]
Los caracteres protegidos se muestran en la siguiente tabla:
Nombre
Arroba
Barra
Barra invertida
Circunflejo
Corchete de apertura
Corchete de cierre
Dólar
Mayor que
Menor que
Carácter
@
/
\
ˆ
[
]
$
>
<
Forma proteg.
\@
\/
\\
\ˆ
\[
\]
\$
\>
\<
Significado
Superblanco externo
Divisor de acepciones
Carácter de protección
Inicio de FL
Inicio de blanco
Fin de blanco
Fin de FL
Inicio de sı́mbolo gram.
Fin de sı́mbolo gram.
En la figura 2.3 muestra cómo quedarı́a encapsulado el documento de
la figura 2.2.
2.3. FLUJO DE DATOS SEGMENTADO
15
[<html>
<head>
<title>]Tı́tulo.[][</title>
</head>
<body>
<p>]Frase[
]dividida.[][</p>
</body>
<html>]
Figura 2.3: El documento de la figura 2.2 con el formato encapsulado usando
corchetes
2.3. Flujo de datos segmentado
El flujo de datos segmentado es el que circula entre los módulos que
manejan información lingüı́stica dentro del traductor. En este flujo las palabras se encuentran delimitadas y etiquetadas. Hay dos tipos de flujo segmentado:
Flujo segmentado ambiguo. Su caracterı́stica principal es que las palabras tienen forma superficial y potencialmente varias formas léxicas
(multiformas léxicas). Este flujo es el formato en el que el analizador morfológico proporciona los datos de entrada al desambiguador
léxico categorial (consulte el esquema 3.2 de la página 59 para obtener una descripción detallada del flujo segmentado ambiguo).
Flujo segmentado no ambiguo. Sólo tiene una forma léxica para cada
palabra y no incluye la forma superficial. En este formato transitan
los datos desde el desambiguador al módulo de transferencia y desde éste al generador (consulte el esquema 3.3 de la página 62 para
ver el formato del flujo segmentado no ambiguo).
Por otro lado, además de la información que ya marca el flujo de datos
sin formato, el nuevo flujo deberá permitir marcar la siguiente información:
Unidades léxicas. Una unidad léxica consta de la forma superficial (para el caso del flujo segmentado ambiguo) más una o más formas léxicas (que corresponden a los posibles análisis de la FS) con sus sı́mbolos gramaticales.
16
CAPÍTULO 2. ESPECIFICACIÓN DEL FORMATO DE FLUJO
[<html>
<head>
<title>]ˆTı́tulo/Tı́tulo<n><m><sg>$ˆ./.<sent>$[][</title>
</head>
<body>
<p>]ˆFrase/Frase<n><f><sg>$[
]ˆdividida/dividir<vblex><pp><f><sg>$ˆ./.<sent>$[][</p>
</body>
<html>]
Figura 2.4: Ejemplo de flujo segmentado con el formato encapsulado en formato
no XML, correspondiente al documento HTML de la figura 2.2.
Formas superficiales (flujo segmentado ambiguo). Se trata de la palabra
tal y como se encuentra en el texto original.
Formas léxicas. El lema de la palabra con los sı́mbolos gramaticales
correspondientes.
Sı́mbolos gramaticales. Marcan los atributos gramaticales de la forma
superficial correspondiente.
Para delimitar palabras se usan los caracteres de comienzo de palabra
’ˆ’ y de fin de palabra ’$’ como se muestra a continuación:
ˆpalabra$
Para delimitar la forma superficial y las sucesivas formas léxicas se usa
el carácter de separación /. Este separador sólo tiene sentido en el flujo
segmentado ambiguo ya que el no ambiguo sólo tiene la forma léxica. Su
forma es la siguiente:
ˆforma superficial/forma léxica 1/...$
Las formas léxicas pueden incluir sı́mbolos (generalmente situados al
final), tal y como se muestra en el ejemplo de la figura 2.4.
Capı́tulo 3
Especificación de los módulos
3.1. Módulos de procesamiento léxico
3.1.1. Descripción del funcionamiento
Una de las aproximaciones más eficientes al procesamiento léxico usa
transductores de estados finitos (TEF) [10, 15]. Los TEF son una clase de
autómatas de estados finitos que se describen en el apartado siguiente. Los
TEF pueden ser usados como analizadores morfológicos de una sola pasada y se pueden implementar de manera muy eficiente. En este proyecto
se usa una clase de TEF denominados transductores de letras [15, 6, 4]; de
hecho, cualquier transductor de estados finitos se puede convertir siempre en un transductor de letras. Garrido y colaboradores [4, 6] dan una
una definición formal de los transductores de letras usados en este trabajo; informalmente, un transductor de letras es una máquina idealizada que
se compone de:
1. Un conjunto (finito) de estados, es decir, de situaciones en las que
se puede encontrar el transductor según va leyendo, de izquierda
a derecha, las letras o sı́mbolos de la entrada. Entre los estados del
conjunto se distinguen:
a) Un único estado inicial: el estado en el que se encuentra el transductor antes de procesar la primera letra o el primer sı́mbolo de
la entrada.
b) Uno o más estados de aceptación, a los que sólo se llega después
de haber leı́do completamente una entrada válida y, por tanto,
sirven para detectar las palabras válidas.
17
18
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
2. Un conjunto (también finito) de transiciones de estado, cada una de
las cuales se compone de:
a) el estado de partida
b) el estado de llegada
c) la letra o el sı́mbolo de entrada
d) la letra o el sı́mbolo de salida
Para permitir que la salida y la entrada tengan longitud diferente en
cualquier momento, se permite que el sı́mbolo de entrada esté ausente, que el sı́mbolo de salida esté ausente o que ambos estén ausentes.
Esta circunstancia se indica normalmente usando un sı́mbolo especial (el sı́mbolo vacı́o).
El transductor construye, cada vez que lee un sı́mbolo de la entrada,
una lista de estados vivos o activos, cada uno de los cuales tiene una salida
asociada (una secuencia de sı́mbolos). El funcionamiento del transductor
de letras es distinto para cada tipo de operación de procesamiento léxico.
Por ejemplo, en el análisis morfológico se intenta leer la entrada más larga que reconoce el diccionario (modo “de izquierda a derecha, segmento
concordante más largo”).
1. Iniciación: se hace que el conjunto de estados vivos contenga un único estado vivo: el estado inicial, con la palabra vacı́a () como salida
asociada al estado.
2. Si desde alguno de los estados del conjunto de estados vivos actual
se llega a otros estados mediante transiciones que no tienen sı́mbolo
de entrada, se añaden estos estados al conjunto de estados vivos, y
se les asocia la salida obtenida alargando las salidas asociadas con
el sı́mbolo de salida que se haya encontrado en las correspondientes
transiciones. Esta operación de ampliación del conjunto de estados
vivos se efectúa hasta que no sea posible añadir más.
3. Se lee un sı́mbolo de la palabra de entrada.
4. Se crea un nuevo conjunto de estados vivos con aquellos a los que se
llega mediante transiciones que tienen ese sı́mbolo como entrada, y
se asocia a estos estados las salidas alargadas con los correspondientes sı́mbolos de salida encontrados en las transiciones.
5. Si el conjunto actual tiene algún estado vivo se va al paso 2.
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
19
6. Se recorren hacia atrás los conjuntos de estados vivos hasta que encontramos algún conjunto en el que aparecen estados de aceptación.
Los análisis morfológicos serán las salidas asociadas a dichos estados, y la posición de lectura se fija a la posición inmediatamente posterior a la de ese conjunto (para que pueda volver a ser procesada
por el transductor en la siguiente pasada).
No todos los estados de aceptación son de la misma clase, y esto añade
algunas condiciones más al proceso de aceptación, para permitir el tratamiento de palabras desconocidas o de palabras que van unidas a otras,
como se explicará más adelante.
Como puede verse, el transductor lee la palabra de entrada sólo una
vez como caso promedio, de izquierda a derecha y sı́mbolo a sı́mbolo, y
mantiene una lista tentativa de posibles salidas parciales que va actualizando y podando según lee la entrada. Cuando los transductores de letras
se usan como analizadores morfológicos o como lematizadores, leen una
forma superficial y escriben la(s) forma(s) léxica(s) correspondiente(s). En
este caso, los sı́mbolos de entrada son las letras de la forma superficial y
los de salida las letras necesarias para formar los lemas y los sı́mbolos especiales que representan el análisis morfológico, como, por ejemplo, <n>,
<f>, <2p>, etc.
El funcionamiento de los transductores en otras tareas de procesamiento léxico es similar.
[Nota: La noció de LRLM (left-to-right, longest-match) (o ODSCML,
”izquierda a derecha, recortando el segmento concordante más largo”) ha de quedar clara en el funcionamient del morfològic i del trànsfer
estructural. Afegir coses de l’article de EAMT 2005.]
3.1.1.1.
Tratamiento de mayúsculas y minúsculas en los diccionarios
Una misma palabra a la entrada de un módulo de procesamiento léxico
puede presentar aspectos diferentes respecto al formato de mayúsculas y
minúsculas. Los casos más frecuentes son los siguientes:
Toda la palabra está en minúsculas.
Toda la palabra está en mayúsculas.
La primera letra de la palabra está en mayúsculas y el resto en minúsculas (caso más tı́pico de los nombres propios).
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
20
Las transducciones en el diccionario también se pueden encontrar en
los tres estados. La forma en la que un término se encuentre en el diccionario se usa para tratar de descartar acepciones de la palabra de la siguiente
manera:
Si la letra de la entrada es mayúscula y en el estado actual de análisis
tenemos transiciones concordantes en minúsculas, estas transducciones se realizan.
Si la letra de la entrada es minúscula y en el estado actual no tenemos
transiciones concordantes en minúsuculas, no se realizan.
Esta polı́tica nos facilita que no figuren acepciones de nombres propios
para una forma superficial que no empieza por mayúscula.
La condición de mayúscula o minúscula de una letra en una palabra
será respetada a la salida del traductor a menos que se decida cambiar
dicha condición. Esta opción está disponible en el módulo de transferencia
estructural para casos como el de traducción de una palabra en origen por
dos palabras en la lengua meta: Canté –¿Vaig cantar.
3.1.2.
Formato de los datos: los diccionarios
3.1.2.1. Criterios generales para el diseño de los diccionarios
La experiencia del grupo Transducens de la Universitat d’Alacant en la
construcción de sistemas de traducción automática ya operativos y públicamente accesibles entre lenguas románicas (es, ca y pt) ha inspirado los
aspectos fundamentales del diseño completo del sistema de traducción
automática de transferencia sintáctica superficial que se describe en este
documento y de su aplicación a las lenguas románicas de España (es, ca
y gl). En cierto sentido, se podrı́a decir que en el presente proyecto sólo
se ha tenido que adaptar (reescribir en un formato estandarizado e interoperable) las especificaciones y los programas ya usados en proyectos ya
operativos.
En particular, el diseño de los diccionarios se ha seguido realizando
a partir de una arquitectura que pretende independizar al máximo la lengua origen de la lengua meta, incluso sabiendo que se trata de diccionarios
orientados a la traducción y que no conviene elaborarlos completamente
por separado. El formato utilizado sirve para especificar tanto los diccionarios morfológicos (monolingües) como los diccionarios bilingües.
El formato de los diccionarios, al igual que el de los demás datos lingüı́sticos (fichero de definición del desambiguador y reglas de transferencia
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
21
estructural) es XML1 , un estándar internacional utilizado en numerosos
proyectos de tratamiento del lenguaje natural que, gracias a la existencia
de numerosos útiles y librerı́as, se está conviertiendo en una herramienta
muy potente para la representación y el intercambio de datos lingüı́sticos
(véase el artı́culo [8]).
Los diccionarios están diseñados de manera que puedan compilarse
para elaborar transductores de letras con ellos, por cuestiones de eficiencia.
Para más información sobre transductores de letras como caso particular
de transductores de estados finitos véase el artı́culo [6].
Los transductores de letras que se elaboran a partir de los diccionarios
(morfológicos, bilingües y de postgeneración) procesan cadenas de caracteres de entrada para ofrecer cadenas de salida. De este modo, los diccionarios están formados por entradas consistentes en parejas de cadenas que
constituyen las entradas y las salidas de los transductores.
La herramienta más potente de estos diccionarios es la definición y el
uso de paradigmas. Como en las lenguas romances muchos lemas comparten una misma flexión (existen regularidades en la flexión), resulta útil y
directo agrupar estas regularidades en paradigmas de flexión para evitar
tener que escribir todas las formas de cada palabra. Los paradigmas permiten representar las entradas del diccionario de manera compacta y optimizar la velocidad de construcción del diccionario. Una vez establecidos
los paradigmas más frecuentes en un diccionario, un lingüista no tiene que
preocuparse en la mayorı́a de ocasiones por toda la flexión de un nuevo
término, puesto que introducir una palabra que se flexiona se reduce generalmente a indicar el lema e identificar la flexión entre los paradigmas previamente definidos. Además, el uso de paradigmas reduce los requisitos
de memoria, favorece la construcción de transductores de letras eficientes
y aumenta la velocidad de compilación [11]. En los diccionarios bilingües
no se han utilizado paradigmas (aunque se podrı́an utilizar), puesto que la
mayor parte de la información de flexión se procesa de manera implı́cita,
como se explica en la página 40.
3.1.2.2.
Tipos de diccionarios
En el sistema tenemos tres tipos de diccionarios: diccionarios morfológicos (monolingües) de cada uno de los idiomas implicados (español, catalán y gallego); diccionarios bilingües para los distintos pares de traducción (español–catalán y español–gallego), y diccionarios de postgeneración para cada uno de los idiomas (que más que un diccionario con lemas
1
http://www.w3.org/XML/
22
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
e información morfológica son un pequeño diccionario de las transformaciones ortográficas que pueden sufrir las palabras al entrar en contacto
entre sı́). La estructura de los tres tipos de diccionarios está especificada
mediante la misma DTD (definición de tipo de documento), que puede consultarse en el apéndice A.1.
Los diccionarios morfológicos se usan tanto para construir analizadores morfológicos —el módulo del sistema de traducción que se usa para
obtener todas las formas léxicas posibles para una forma superficial dada
en la lengua origen— como generadores morfológicos —el módulo que
se ocupa de generar la forma superficial en la lengua meta a partir de la
forma léxica de cada palabra—. Estos dos módulos se obtienen a partir de
un mismo diccionario morfológico, según el sentido en que el sistema lo
lea: leı́do de izquierda a derecha se obtiene el analizador, y de derecha a
izquierda, el generador.
La estructura de bloques tı́pica de estos diccionarios consta de:
Una definición del alfabeto. Esta definición se usa exclusivamente para la construcción del analizador morfológico; en concreto, para que
éste pueda recortar las palabras desconocidas y las de las secciones condicionales (ver la explicación del elemento <section> en la
página 25) de forma adecuada; el generador morfológico no necesita
esta definición.
Una definición de los sı́mbolos. Consiste en una declaración de los sı́mbolos gramaticales que se usarán en las entradas del diccionario (véase
en el Apéndice B una lista con los sı́mbolos gramaticales utilizados
en este proyecto).
Una definición de paradigmas. Para poder referirse a ellos en las secciones del diccionario o en otros paradigmas.
Una o más secciones de diccionario de recorte condicional, de tipo standard.
Para incluir la mayorı́a de las palabras del diccionario.
Una o más secciones de diccionario de recorte incondicional. Para incluir
ciertas palabras que siguen algún patrón regular o se recortan independientemente del texto que les sigue (ver discusión del elemento
<section> en la página 25). En los diccionarios morfológicos de catalán, las palabras que requieren un recorte incondicional se reparten
en dos secciones: una para las formas que necesitan que se coloque
un blanco a continuación (por razones de procesamiento de las formas léxicas), como l’ o d’, y otra para signos de puntuación, números
y otros signos.
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
23
Los diccionarios bilingües son los que representan en el sistema el proceso de la transferencia léxica, esto es, la asignación de la forma léxica de
la LM que corresponde a cada forma léxica de la LO. De cada diccionario
bilingüe se obtienen dos productos según el sentido en el que el sistema los
lea: leı́dos de izquierda a derecha se obtiene el módulo de transferencia
léxica en uno de los sentidos de traducción, y leı́dos de derecha a izquierda, en el otro sentido. Para los diccionarios bilingües de este proyecto se
ha convenido que el español se situará siempre en la parte izquierda de las
entradas, y las demás lenguas (catalán y gallego), en la parte derecha. Ası́,
por ejemplo, el diccionario bilingüe español–gallego se leerá de izquierda a derecha para la traducción es–gl y de derecha a izquierda para la
traducción gl–es. En aplicaciones como las de este proyecto, estos diccionarios no tienen paradigmas: se construyen mediante entradas genéricas
en las que casi nunca se especifica más que su lema y categorı́a gramatical
y no hay información de flexión.
El esquema de bloques usado en este proyecto para los diccionarios
bilingües es el siguiente:
Una definición de los sı́mbolos. Consiste en una declaración de los sı́mbolos gramaticales que se usarán en las entradas del diccionario.
Una sección única de diccionario. Para incluir las correspondencias bilingües del diccionario.
A partir de 2007, los diccionarios bilingües permiten la especificación
de más de una traducción en lengua meta para que un módulo de selección léxica (veáse el apartado 3.4) pueda elegir el equivalente más adecuado según el contexto. Para tal fin se ha añadido un atributo a los diccionarios bilingües, que se describe en la sección 3.1.2.4.
Los diccionarios de postgeneración se usan para llevar a cabo las operaciones de transformación ortográfica, contracción, apostrofación, etc. que
sean necesarias una vez generadas las formas superficiales de la lengua
meta debido al contacto entre palabras. Como este tipo de operaciones se
pueden expresar como traducciones de cadenas de caracteres se ha optado por usar el mismo tipo de diccionarios. Implı́citamente, se entiende que
las partes del texto cuyo procesamiento no se especifica se copian tal como
llegan. En estos diccionarios es útil la definición de paradigmas para expresar cambios sistemáticos en los fenómenos de contacto entre palabras.
A diferencia de los demás tipos de diccionarios, estos no tienen sı́mbolos
gramaticales, ya que procesan formas superficiales.
El esquema de bloques de los diccionarios de postgeneración es el siguiente:
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
24
Una sección de definición de paradigmas. Para componer las entradas.
Una sección de diccionario. Para incluir los patrones para realizar la
postgeneración.
En la siguiente tabla se presentan de forma resumida los sentidos de
lectura de los diccionarios y su utilidad para las lenguas románicas del
presente proyecto:
Diccionario
Morfológico
Bilingüe
Postgeneración
3.1.2.3.
Sentido de lectura
izquierda–derecha
derecha–izquierda
izquierda–derecha
derecha–izquierda
izquierda–derecha
Función
análisis de es, ca y gl
generación de es, ca y gl
traducción es-ca y es-gl
traducción ca-es y gl-es
postgeneración para ca, es y gl
Descripción del formato de los diccionarios
En esta sección se presentan los principales elementos del formato en
el que se construyen los diccionarios. La definición formal (una DTD) se
da en el apéndice A.1. En la sección 3.1.2.4 se describen las caracterı́sticas
de un diccionario bilingüe que funcione en un sistema Apertium que disponga de módulo de selección léxica. Finalmente, en las páginas 40 a 43
se describen las caracterı́sticas particulares de las entradas de los tres tipos
de diccionarios (morfológicos, bilingües y de postgeneración respectivamente).
Elemento diccionario <dictionary>
Es el elemento raı́z, que incluye todo el diccionario. Incluye una definición de caracteres alfabéticos, una definición de sı́mbolos (que son las
etiquetas morfológicas de las palabras), una definición de paradigmas de
flexión y una o varias secciones de diccionario, en las que se encuentran
las entradas correspondientes a las formas léxicas (formadas por pares de
forma superficial–forma léxica). En la figura 3.1 se muestra la estructura
básica de bloques de un diccionario genérico.
Elemento alfabeto <alphabet>
Permite especificar una definición de caracteres alfabéticos. El objeto de
esta especificación es que los módulos que procesan la entrada mediante
transductores de letras puedan recortarla en palabras individuales.
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
25
<?xml version="1.0" encoding="iso-8859-15"?>
<dictionary>
<alphabet>abcdefghijk ... ABCDEFGH ... çñáéı́óú</alphabet>
<sdefs>
<!-- ... -->
</sdefs>
<pardefs>
<!-- ... -->
</pardefs>
<section ...>
<!-- ... -->
</section>
<!-- ... -->
</dictionary>
Figura 3.1: Uso de los elementos <dictionary> y <alphabet>
[Nota: Parlar dels mots desconeguts. Cita 3.1.2.3 - Mikel?]
En la actual especificación, sólo tiene sentido la definición de este elemento en los diccionarios morfológicos, por ser necesario para el análisis.
La figura 3.1 muestra un ejemplo de uso de este elemento.
Elemento sección de definición de sı́mbolos <sdefs>
Agrupa todas las definiciones de sı́mbolos de un diccionario (<sdef>).
Un ejemplo se muestra en la figura 3.2.
Elemento definición de sı́mbolos <sdef>
Se trata de un elemento vacı́o (no delimita ningún contenido): sirve
para especificar los nombres de los sı́mbolos gramaticales que se usan en
este diccionario mediante los valores del atributo n. Estos sı́mbolos son los
que se utilizarán para etiquetar morfológicamente las formas léxicas. En la
figura 3.2 se ilustra un ejemplo del ámbito en el que se usa este elemento.
En el Apéndice B puede verse una lista de todos los simbolos gramaticales
utilizados en los diccionarios de este proyecto.
Elemento de sección del diccionario <section>
Define en su interior las palabras que serán reconocidas por el diccionario. La razón de dividir el diccionario en secciones es porque ciertos
26
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<sdefs>
<sdef n="n"/>
<sdef n="det"/>
<sdef n="sg"/>
<sdef n="pl"/>
<!-- ... -->
</sdefs>
Figura 3.2: Uso del elemento <sdefs>
grupos de formas —como por ejemplo, las que proceden de la identificación de ciertos patrones regulares, o las que pudieran depender de un
dialecto especı́fico— necesitan en ocasiones un procesamiento diferente.
Uno de los procesamientos especı́ficos que se resuelven mediante la
definición de secciones en el diccionario es el problema del procedimiento
de recorte (división de palabras) en el análisis morfológico. La mayor parte de formas se recortan mediante un criterio condicional, atendiendo a si
viene un carácter no alfabético —es decir, no definido en <alphabet>—
después del carácter que está siendo procesado. Pero hay otras formas, como las catalanas l’ o d’, que requieren un modo de recorte incondicional,
sin esperar a leer lo que viene después —ya que si viene un carácter alfabético después, forma parte de la siguiente palabra—. Estas formas que
requieren de un recorte incondicional se incluyen en una sección especı́fica
del diccionario. Otros tipos de procesamiento también pueden resolverse
mediante estas divisiones.
Se usa el valor del atributo type para expresar el tipo de reconocimiento de las cadenas que se usa en cada sección del diccionario: los valores
del atributo son standard para casi todos los propósitos del diccionario
(condicional), postblank para las formas que requieren un recorte incondicional y la colocación de un blanco, e inconditional para las demás
formas de recorte incondicional.
El atributo id se usa para otorgar un identificador (un nombre) a las
secciones del diccionario.
Elementos de las entradas <e>
La entrada es la unidad básica del diccionario o de la definición de paradigma. Las entradas consisten en una concatenación en cualquier orden
de parejas de cadenas <p>, transducciones identidad <i>, referencias a
paradigmas <par> o expresiones regulares <re>. La estructura y el signi-
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
27
<section id="principal" type="standard">
<!-- ... -->
</section>
<section id="patterns" type="inconditional">
<!-- ... -->
</section>
Figura 3.3: Uso del elemento <section>
ficado de estos elementos se explica más adelante (en las páginas 28, 29,
33 y 34 respectivamente).
Se usan dos atributos opcionales con esta entrada. Uno es r (de restriction) que define si esa entrada se tiene que tener en cuenta durante la
lectura del diccionario sólo de izquierda a derecha (LR) o sólo de derecha
a izquierda (RL). Si no se especifica nada se supone que la entrada se debe
tener en cuenta en ambas direcciones.
En los diccionarios morfológicos, la restricción de dirección LR se utiliza para que una FL sea analizada pero no generada (por ejemplo, por
tratarse de una FL en una variante dialectal que se desea reconocer pero
no generar) y la restricción RL para que una palabra sólo se genere pero no
se analice (necesario, por ejemplo, para las formas con marca de activación
del postgenerador, véase la página 36).
En los diccionarios bilingües, las restricciones LR y RL sirven para que
la traducción se haga sólo en un sentido: por ejemplo, en un diccionario
bilingüe es–ca, LR indicarı́a que la FL sólo se traduce de español a catalán, y RL sólo de catalán a español. Lo ilustraremos con un ejemplo: los
adverbios españoles aún y todavı́a los traducimos al catalán por una misma palabra, encara. El adverbio catalán encara sólo podemos traducirlo al
español por uno de las dos, y decidimos traducirlo por todavı́a. En este
caso, debemos escribir dos entradas en el diccionario bilingüe: la que empareja aún con encara debe tener la restricción LR (traducción sólo de es a
ca) y la que empareja todavı́a con encara no debe tener ninguna restricción
(traducción en ambos sentidos).
Las restricciones de dirección en diccionarios bilingües son necesarias
también en el caso de palabras con género por determinar (”GD”) o número por determinar (”ND”) (véase la página 40).
El otro atributo opcional de las entradas es el nombre del lema lm. Debido a la utilización de paradigmas para representar las regularidades en
la flexión de las unidades léxicas, las entradas de los diccionarios morfológicos contienen la parte del lema que es común a todas las formas
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
28
<p>
<l><!-- ... --></l>
<r><!-- ... --></r>
</p>
Figura 3.4: Uso del elemento <p>
flexionadas, es decir, contienen el lema cortado en el punto en que empieza la regularidad del paradigma (por ejemplo, los adjetivos españoles
distinto, absoluto y marino aparecen en las entradas como distint, absolut y
marin, siendo el resto de sus formas flexionadas común a todos ellos y
descrito en un paradigma). Este hecho puede provocar dificultades en la
comprensión del diccionario. Por ello, en las entradas se ha añadido este
atributo, que contiene el lema completo de la forma léxica, de modo que el
diccionario gane en claridad y los lingüistas puedan solucionar problemas
rápidamente. En los diccionarios bilingües, que no suelen tener referencias
a paradigmas,2 no suele ser necesario usarlo.
Elemento pareja de cadenas <p>
Este elemento básico de los diccionarios se usa en cualquier tipo de
entrada para indicar la correspondencia entre dos cadenas de sı́mbolos,
correspondencia que especifica una transformación léxica que será realizada por un camino de estados en el transductor de estados finitos [4]
resultante.
Están definidas por un par de elementos internos. Uno es el izquierdo
(elemento <l>, left) y el otro el derecho (elemento <r>, right). La estructura
de esta etiqueta presenta el aspecto que se muestra en la figura 3.4.
Una pareja <p> debe incluir estas dos partes aunque una de ellas puede estar vacı́a, lo que se corresponde con borrar (o insertar) una cadena.
Los elementos <l> y <r> tienen la misma estructura interna y los mismos requisitos. Dentro de cada pareja puede haber texto y referencias a
sı́mbolos gramaticales (que en las lenguas del presente proyecto, con flexión sufijal, se suelen poner al final en cualquier cantidad). En el exterior
de las etiquetas <l> y <r> de las parejas de cadenas no hay nada.
2
Podrı́an tener referencias a paradigmas, pero no lo hemos considerado necesario para
las lenguas involucradas
[Nota: atenció: ex–, vice–?]
.
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
29
Elemento referencia a sı́mbolo (o etiqueta) <s>
Las referencias a sı́mbolos sirven para especificar la información morfológica de una FL y se usan en cualquier punto dentro de una pareja de
cadenas, es decir, dentro de <l>, <r> o de ambos, como si se tratasen de
caracteres individuales, aunque en las lenguas del presente proyecto se
suelen poner al final de las parejas y siempre en el mismo orden para el
mismo tipo de palabra. Este orden lo decide el lingüista según como quiera caracterizar morfológicamente las FL de los diccionarios, y debe ser el
mismo en todos los diccionarios del sistema para que las operaciones de
transferencia léxica y estructural funcionen correctamente. Ası́, por ejemplo, en los diccionarios de este proyecto, un nombre común lleva primero
el sı́mbolo de categorı́a (n, nombre), luego el de género (m, masculino, f,
femenino, mf, masculino–femenino), y finalmente el de número (sg, singular, pl, plural, sp, singular–plural). En el Apéndice B se ofrece una lista con
los sı́mbolos gramaticales utilizados en los diccionarios de este proyecto y
el orden que se ha establecido para definir los distintos tipos de palabra.
En los diccionarios morfológicos las referencias a sı́mbolos se usan en
los paradigmas de flexión y en las entradas que no incluyen ninguna referencia a paradigma. En los diccionarios bilingües suelen indicarse únicamente los primeros sı́mbolos gramaticales (normalmente sólo el primero)
de cada FL, ya que el resto se copia automáticamente de la FL en lengua
origen a la FL en lengua meta (si coincide en ambas lenguas).
Para especificar el sı́mbolo al que nos referimos se usa el atributo (obligatorio) n. Se requiere que el sı́mbolo esté definido en la sección de definición de sı́mbolos (<sdefs>).
Elemento transducción identidad <i>
Debe ser visto como una forma de escribir una pareja de cadenas en
la que la parte izquierda y la parte derecha son idénticas. Por ejemplo, a
todos los efectos las dos entradas que se muestran en la figuras 3.5 son
equivalentes. La ventaja de escribir las entradas en esta notación es que
resultan más compactas y también más legibles.
Elemento sección de definición de paradigmas <pardefs>
Este elemento agrupa todas las definiciones de paradigmas del diccionario, contenidas cada una en un elemento <pardef>, como se muestra
en la figura 3.6.
30
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
[1]
<e lm="perro">
<p>
<l>perr</l><r>perr</r>
</p>
<par n="abuel_o__n"/>
</e>
[2]
<e lm="perro">
<i>perr</i>
<par n="abuel_o__n"/>
</e>
Figura 3.5: Uso del elemento <i>: las entradas [1] y [2] son equivalentes
<pardefs>
<pardef n="abuel_o__n">
<!-- ... -->
</pardef>
<!-- ... -->
</pardefs>
Figura 3.6: Uso del elemento <pardefs>
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
31
Elemento de definición de paradigmas <pardef>
Define un paradigma de flexión del diccionario. Un paradigma se puede entender como un pequeño diccionario de transformaciones alternativas que se pueden concatenar a partes de las palabras (o a entradas de
otro paradigma) para especificar regularidades en el procesamiento léxico
de las entradas del diccionario, como, por ejemplo, regularidades en la flexión. Para especificar estas regularidades, cada paradigma es una lista de
entradas <e> como las del diccionario, es decir, tiene la misma estructura
que una sección del diccionario <section>; por tanto, las entradas consisten en una pareja (<p>) con parte izquierda (<l>) y parte derecha (<r>).
Dentro de estos elementos se puede incluir texto o sı́mbolos morfológicos
<s>.
Como en el caso de las definiciones de sı́mbolos, las definiciones de
paradigmas tienen un atributo n que especifica el nombre del paradigma
para poder utilizarlo posteriormente dentro de las entradas del diccionario. Ası́, en cada entrada del diccionario bastará con indicar el nombre del
paradigma que le corresponde para que queden especificadas todas sus
posibles formas.
El ejemplo de definición de paradigma que se apunta en la figura 3.6
se desarrolla en la figura 3.7. Para ilustrar qué información se expresa mediante el paradigma se presenta la siguiente tabla:
Raı́z (FS y FL)
abuel
abuel
abuel
abuel
Desinencia (FS)
o
a
os
as
Análisis (FL)
o<n><m><sg>
o<n><f><sg>
o<n><m><pl>
o<n><f><pl>
Este paradigma se asigna a todos los sustantivos (n) que se flexionan
igual que abuelo, como alumno, amigo o gato, y está pensado para ser usado como sufijo en las entradas del diccionario. En general se pueden usar
paradigmas en cualquier punto de las entradas del diccionario (siempre
que tenga sentido, claro está). Podemos pensar en los paradigmas como
transductores que se insertan en el punto en el que se haga referencia a
ellos. En la figura 3.8 se muestra un ejemplo de un paradigma definido
para ser usado como prefijo. Es el caso del paradigma que se usa para
analizar y generar las palabras que empiezan por ex, ex-, etc., como expresidente, exministro, ex director, etc., con sus variaciones ortográficas (ex
con guión, sin guión unido y sin guión separado por un blanco <b/>,
véase la pàgina 3.1.2.3); el lema entregado simplemente añade ex sin guión
32
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<pardef n="abuel_o__n">
<e>
<p>
<l>o</l>
<r>o<s n="n"/><s n="m"/><s
</p>
</e>
<e>
<p>
<l>a</l>
<r>o<s n="n"/><s n="f"/><s
</p>
</e>
<e>
<p>
<l>os</l>
<r>o<s n="n"/><s n="m"/><s
</p>
</e>
<e>
<p>
<l>as</l>
<r>o<s n="n"/><s n="f"/><s
</p>
</e>
</pardef>
n="sg"/></r>
n="sg"/></r>
n="pl"/></r>
n="pl"/></r>
Figura 3.7: Uso del elemento <pardef> para definir la morfologı́a flexiva de
substantivos de cuatro terminaciones como abuelo, -a, -os, -as.
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
33
<pardef n="ex">
<e r="LR"><p><l>ex<b/></l><r>ex</r></p></e>
<e><i>ex</i></e>
<e r="LR"><p><l>ex-</l><r>ex</r></p></e>
<e><i/></e>
</pardef>
Figura 3.8: Uso del elemento <pardef> en el paradigma usado para el prefijo ex.
ni blanco al lema del resto. Las restricciones de dirección ("LR") que aparecen en el ejemplo se usan para decidir qué forma es la que va a generar
el traductor. La transducción identidad vacı́a (<i/>) es necesaria en este
caso para analizar y generar la palabra sin el prefijo ex.
Las entradas de un paradigma pueden incluir referencias a otros paradigmas con la condición de que hayan sido definidos previamente en el
fichero. Por otro lado, por el momento, una definición de paradigma no
puede incluirse a sı́ mismo ni directa ni indirectamente.
Los paradigmas se usan en los diccionarios morfológicos para el análisis y la generación de formas léxicas. Para los pares de lenguas de este
proyecto, no es necesaria la definición de paradigmas en los diccionarios
bilingües (véase la página 40).
A partir de Apertium 2 existe un nuevo tipo de paradigma, llamado
metaparadigma, que permite definir paradigmas con variaciones según
el valor de un atributo especificado en cada entrada que haga referencia
al metaparadigma. En el apartado 3.1.2.7 se explican sus caracterı́sticas y
utilización.
Elemento referencia a paradigma de flexión <par>
Se utiliza dentro de las entradas para indicar qué paradigma, de los que
se han definido en <pardefs>, sigue la entrada en cuestión. Gracias a las
referencias a paradigmas no es necesario escribir en cada entrada de un
diccionario morfológico todas las formas flexionadas del lema. El atributo
n sirve para especificar a qué paradigma se hace referencia.
El resultado de insertar una referencia a paradigma en una entrada es
la creación de tantas parejas de cadenas como casos especifique el paradigma. Por ejemplo, la entrada de la figura 3.9, con la referencia al paradigma
”abuel o n”(que está definido en la figura 3.7), equivale a realizar una
entrada con cada pareja de cadenas del paradigma concatenada al lema
(es decir, con cada forma flexionada del lema), como se representa en la
34
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<e lm="perro">
<i>perr</i>
<par n="abuel_o__n"/>
</e>
Figura 3.9: Uso del elemento <par>
figura 3.10. En ella puede verse como el paradigma ofrece siempre como
cadena derecha (<r>) el lema (perro) junto con los sı́mbolos gramaticales
correspondientes a la forma superficial, ya que es a partir del lema que se
realizan las operaciones de transferencia.
El uso adecuado de paradigmas, además de permitir la creación de
diccionarios compactos, favorece la velocidad de compilación y rebaja la
necesidad de memoria durante la misma, ya que durante el proceso de
compilación es posible crear una única estructura de datos para cada uno
de la mayor parte de paradigmas [11].
Elemento expresión regular <re>
En los lenguajes naturales también hay patrones que se pueden reconocer como expresiones regulares: por ejemplo, los signos de puntuación,
los números (latinos o romanos), las direcciones de correo electrónico o de
páginas de internet o cualquier tipo de código identificable mediante estos
mecanismos.
Para estos usos se utiliza la cadena que contiene la etiqueta <re>. El
compilador lee la definición de la expresión regular y la transforma en un
transductor que se integra en el resto del diccionario y que traduce todas
las cadenas que concuerdan con la expresión por cadenas idénticas.
La sintaxis de la implementación actual de estas expresiones regulares
procesa un subconjunto de las expresiones regulares de Unix, que incluye
los operadores *, ?, | y +, además de agrupaciones mediante paréntesis
y rangos de caracteres opcionales como por ejemplo [a-zA-zñú] o sus
versiones negadas, por ejemplo [ˆa-z].
Por analogı́a, se pueden ver como si se tratase de elementos <i>, pero
con la caracterı́stica de que pueden identificar cadenas que en algún caso
pueden ser infinitas (como los números).
En la figura 3.11 se muestra cómo etiquetar cantidades expresadas como números arábigos en el diccionario.
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
<e>
<p>
<l>perro</l>
<r>perro<s n="n"/><s
</p>
</e>
<e>
<p>
<l>perra</l>
<r>perro<s n="n"/><s
</p>
</e>
<e>
<p>
<l>perros</l>
<r>perro<s n="n"/><s
</p>
</e>
<e>
<p>
<l>perras</l>
<r>perro<s n="n"/><s
</p>
</e>
35
n="m"/><s n="sg"/></r>
n="f"/><s n="sg"/></r>
n="m"/><s n="pl"/></r>
n="f"/><s n="pl"/></r>
Figura 3.10: Entrada equivalente a la de la figura 3.9 que muestra el resultado de
insertar la referencia a paradigma <par> con el paradigma definido en la figura
3.7.
<e>
<re>[0-9]+([.,][0-9]+)?( %)?</re>
<p><l/><r><s n="num"/></r></p>
</e>
Figura 3.11: Uso del elemento <re> en una entrada que sirve para la identificación de números arábigos.
36
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<e lm="hoy en dı́a">
<p>
<l>hoy<b/>en<b/>dı́a</l>
<r>hoy<b/>en<b/>dı́a<s n="adv"/></r>
</p>
</e>
Figura 3.12: Uso del elemento <b>
Elemento de bloque de blancos <b>
Se usa para expresar la presencia de blancos entre palabras de una unidad multipalabra (vea la explicación de las multipalabras en la página 44).
Se puede usar dentro de los elementos <i>, <l> y <r>. En la figura 3.12 se
puede ver la entrada correspondiente a la expresión hoy en dı́a: los espacios
existentes entre las palabras aparecen como elementos <b/> dentro de las
cadenas izquierda y derecha.
Los blancos pueden ser caracteres de espaciado normales o bloques de
información sobre el formato del documento encapsulados por el desformatador (superblancos, ver sección 3.6.1).
Elemento de activación del postgenerador <a>
El elemento de activación del postgenerador <a> se usa para indicar
que algunas palabras en la lengua meta son susceptibles de sufrir transformaciones ortográficas por contacto con otras palabras; por ejemplo,
ser apostrofadas, contraı́das, escritas sin espacios intermedios, etc. Estas
transformaciones deben realizarse tras la generación de las formas superficiales en la lengua meta, ya que antes, con las palabras aisladas, no es posible saber qué palabras entrarán en contacto. Ası́, es el módulo siguiente
al generador (llamado postgenerador) el que se encarga de tales operaciones. Para indicar qué palabras debe procesar el postgenerador, se usa este
elemento en la parte de la forma superficial de las entradas correspondientes de los diccionarios morfológicos.
El ejemplo de la figura 3.13 muestra su uso en un diccionario morfológico de catalán para la preposición de, la cual, si aparece delante del
artı́culo definido masculino singular o plural (el, els) forma una contracción (del, dels). La etiqueta <a/> incluye información que provoca la activación del postgenerador, el cual comprueba si la preposición viene seguida de las palabras que provocan su contracción y, de ser ası́, la realiza
(véase la página 43 para más detalles). La restricción RL indica que es-
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
37
<e r="RL" lm="de">
<p>
<l><a/>de</l>
<r>de<s n="pr"/></r>
</p>
</e>
Figura 3.13: Uso del elemento <a> en un diccionario morfológico
ta entrada es sólo de generación, ya que no tiene ningún sentido para el
análisis.
Elemento de marcado de grupos <g>
Este elemento se usa para definir, dentro de los elementos <l> y <r>,
grupos que requieren un tratamiento especial más allá del tratamiento palabra por palabra. Se utiliza en las multipalabras con flexión para señalar
el principio y el final de la forma o formas léxicas que van unidas a la palabra flexionada y que, junto a ella, forman una unidad inseparable. En la
página 44 se explican con más detalle los distintos tipos de multipalabra, y
en la figura 3.22 del mismo puede verse un ejemplo de utilización de este
elemento.
Elemento de unión de formas léxicas <j>
Este elemento se utiliza sólo en la parte izquierda de las entradas (<r>)
para indicar que las palabras que forman parte de una multipalabra son
tratadas como formas léxicas individuales y, por lo tanto, tienen cada una
un sı́mbolo morfológico. Estas multipalabras serán tratadas como una unidad por el analizador y por el desambiguador hasta llegar al módulo auxiliar pretransfer (véase el apartado 3.3), que se encarga de separar las
formas léxicas que las componen para que lleguen al módulo de transferencia como formas independientes. Si se desea que estas formas lleguen
al generador como formas unidas, formando una multipalabra otra vez,
debe haber una regla de transferencia estructural que realice la acción de
agruparlos (véase el apartado 3.5.4). Si, por el contrario, estas formas deben ser sólo de análisis, la entrada debe tener la restricción LR.
En la página 44 se ilustra más detalladamente el uso de este elemento.
Puede verse un ejemplo de uso en la figura 3.20 de la mencionada sección.
38
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
3.1.2.4. Modificación de los diccionarios bilingües para el nuevo módulo de selección léxica
En 2007 se ha añadido un nuevo módulo al sistema Apertium: el módulo de selección léxica, que se describe en el apartado 3.4.
Para funcionar en un sistema de selección léxica, los diccionarios bilingües deben ser modificados ligeramente para permitir la especificación
de más de una traducción en lengua meta. El único cambio consiste en el
añadido de dos nuevos atributos al elemento <e>. Estos nuevos atributos
pueden utilizarse en todos los diccionarios pero sólo tienen sentido cuando se trata de una entrada del diccionario bilingüe.
En el Apéndice A.1.1 se muestra el fragmento de la DTD dix.dtd
[Nota: MG: no caldria ajuntar les dues DTDs en una de sola?]
donde se define el elemento e usado para codificar las entradas en los
diccionarios. Los nuevos atributos introducidos son:
slr (sense from left to right) se utiliza para especificar la marca de traducción cuando hay más de una traducción de izquierda a derecha para
el lema situado en la parte izquierda de la entrada. El atributo puede
recibir cualquier valor; sin embargo, lo más apropiado es que reciba
como valor el lema situado en la parte derecha <r> (la traducción
del lema).
srl (sense from right to left) se utiliza para especificar la marca de traducción cuando hay más de una traducción de derecha a izquierda para
el lema situado en la parte derecha de la entrada. Como antes, el
atributo puede recibir cualquier valor, pero lo más apropiado es que
reciba el lema situado en la parte izquierda <l> (la traducción del
lema).
Además, en ambos casos el valor del atributo puede acabar con un
espacio en blanco y la letra “D” para indicar que ésta es la traducción predeterminada, es decir, la traducción a emplear cuando no hay suficiente
información para elegir otra. Es obligatorio que las entradas con más de
un equivalente en lengua meta tengan una, y sólo una, de estas equivalencias marcada con la letra “D” de predeterminado.
El siguiente ejemplo ilustra el funcionamiento de los nuevos atributos. Consideramos el caso de un diccionario bilingüe inglés–catalán y las
siguientes entradas con más de una traducción en lengua meta:
look: que se puede traducir al catalán por mirar (por defecto) o por
semblar (en español, mirar/parecer),
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
39
floor: que se puede traducir al catalán por pis (por defecto) o por terra
(en español, piso/suelo)
pis: que se puede traducir al inglés por flat (por defecto) o por floor.
Esta información se representa utilizando los dos atributos descritos
antes:
<e srl="flat D">
<p>
<l>flat<s n="n"/></l>
<r>pis<s n="n"/><s n="m"/></r>
</p>
</e>
<e slr="pis D" srl="floor">
<p>
<l>floor<s n="n"/></l>
<r>pis<s n="n"/><s n="m"/></r>
</p>
</e>
<e slr="terra">
<p>
<l>floor<s n="n"/></l>
<r>terra<s n="n"/><s n="m"/></r>
</p>
</e>
<e slr="mirar D">
<p>
<l>look<s n="vblex"/></l>
<r>mirar<s n="vblex"/></r>
</p>
</e>
<e slr="semblar">
<p>
<l>look<s n="vblex"/></l>
<r>semblar<s n="vblex"/></r>
</p>
</e>
40
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<e>
<p>
<l>pan<s n="n"/></l>
<r>pa<s n="n"/></r>
</p>
</e>
Figura 3.14: Entrada en el diccionario bilingüe para la traducción pan (es)–pa (ca)
3.1.2.5. Particularidades de los distintos tipos de diccionarios
Las entradas de los diccionarios tienen algunas caracterı́sticas diferenciadas según el diccionario de que se trate. Aunque en la especificación
precedente han quedado apuntadas algunas de estas particularidades, a
continuación las presentamos de manera más exhaustiva.
Diccionarios morfológicos
En estos diccionarios, que se usan para construir los analizadores y
los generadores morfológicos, se deben marcar mediante <a/> las formas
superficiales que una vez generadas pueden necesitar ciertas transformaciones ortográficas por contacto con otras palabras, operaciones de la que
se encarga el postgenerador. Como se trata de marcas que sólo se generan,
las entradas que contengan estas marcas deben ser sólo de generación, es
decir, con la restricción r="RL" (de derecha a izquierda). En la figura 3.13
puede verse un ejemplo de entrada con este elemento.
Diccionarios bilingües
Como ya hemos explicado, en nuestro sistema no se utilizan paradigmas en los diccionarios bilingües; éstos se construyen mediante entradas
genéricas en las que casi nunca se especifica más que su categorı́a gramatical y no hay información de flexión. Por ejemplo, en el diccionario es-ca
la entrada para la palabra española pan, panes, traducida al catalán por pa,
pans, quedarı́a como muestra la figura 3.14.
Como vemos, en la entrada únicamente se especifica el primero sı́mbolo gramatical <s n="..."/> de ambas palabras, ya que los sı́mbolos no
especificados que siguen a los especificados en el diccionario bilingüe son
copiados de la forma léxica original a la forma léxica de la lengua meta;
ası́, esta entrada vale tanto para pan (singular) como para panes (plural),
ya que el módulo analizador entrega el lema (pan) seguido de los sı́mbo-
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
41
<e>
<p>
<l>cama<s n="n"/><s n="f"/></l>
<r>llit<s n="n"/><s n="m"/></r>
</p>
</e>
Figura 3.15: Entrada en el diccionario bilingüe para la traducción cama (es)–llit
(ca)
los gramaticales correspondientes a la forma superficial analizada (n m sg
o n m pl según el caso); por lo tanto, los sı́mbolos no especificados en la
entrada (m sg o m pl) se copian a la lengua meta. Lo mismo vale para los
dos sentidos de traducción. La idea es que se especifica la información
imprescindible para diferenciar las entradas y el resto de información se
sobreentiende (se copia). Es importante tener en cuenta este hecho ya que,
si existen diferencias entre los sı́mbolos gramaticales de una forma léxica entre la LO y la LM, estas diferencias deben quedar especificadas en el
diccionario bilingüe. Ası́, por ejemplo, cuando hay un cambio de género
o de número entre la forma original y la forma traducida, hay que especificar los sı́mbolos gramaticales por orden (el orden en que aparecen estos
sı́mbolos en los diccionarios morfológicos)3 hasta que lleguemos al sı́mbolo divergente entre LO y LM.
Por ejemplo, para traducir la palabra española cama, nombre femenino,
por la palabra catalana llit, nombre masculino, la entrada en el diccionario
bilingüe debe ser como se muestra en la figura 3.15. Debe especificarse el
género (f, m) ya que, de no hacerlo, se copiarı́an los sı́mbolos de género
y número de la forma léxica en LO a la forma léxica en LM. Por lo tanto,
al traducir de es a ca se obtendrı́a la forma léxica llit con los sı́mbolos
n f sg o bien n f pl. En ambos casos, el generador se encontrarı́a con
una palabra imposible de generar, ya que los diccionarios morfológicos
del catalán no contienen ninguna entrada con lema llit y género femenino.
En este ejemplo el número no se especifica y la entrada sirve tanto para la correspondencia cama–llit como para la correspondencia camas–llits.
Sin embargo, si hay que especificar un cambio de número, no hay más remedio que especificar también el género si en todo el diccionario el orden
usado es género, número.
Mediante la restricción de dirección r podemos indicar qué traduccio3
Para saber qué sı́mbolos gramaticales se han utilizado en los diccionarios morfológicos y en qué orden, consúltese el Apéndice B.
42
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
nes tienen lugar en un sentido y no en el otro (véase la descripción de las
restricciones LR y RL en la página 27). Esto es necesario cuando la correspondencia entre dos formas léxicas no es simétrica, en cuyo caso deben
realizarse varias entradas en el diccionario bilingüe con alguna restricción
de dirección, como en el ejemplo de la figura 3.16. En este ejemplo, cuando
traducimos de español a catalán (LR), necesitamos que solo se generen formas en plural porque la palabra postres en catalán no tiene singular. Pero
en cambio, sólo traduciremos al español en plural porque no hay forma de
determinar si el número serı́a singular o plural.
<e r="LR">
<p>
<l>postre<s n="n"/><s n="m"/><s n="sg"/></l>
<r>postres<s n="n"/><s n="m"/><s n="pl"/></r>
</p>
</e>
<e>
<p>
<l>postre<s n="n"/><s n="m"/><s n="pl"/></l>
<r>postres<s n="n"/><s n="m"/><s n="pl"/></r>
</p>
</e>
Figura 3.16: Entradas en el diccionario bilingüe español–catalán/valenciano para
la correspondencia postre–postres
Existe otro problema debido a las diferencias gramaticales entre dos
lenguas determinadas que se soluciona con dos sı́mbolos especiales, GD
(de género por determinar) y ND (de número por determinar), sı́mbolos que deberán estar definidos en la sección de sı́mbolos del diccionario bilingüe.
Este problema surge cuando la información gramatical de una forma léxica en LO no es suficiente para determinar el género (masculino o femenino) o el número (singular o plural) de la forma léxica en LM. Por poner un ejemplo, el adjetivo común en español es tanto masculino como
femenino (y por tanto masculino/femenino, mf), pero en catalán hay formas diferentes para el masculino, comú/comuns, y para el femenino, comuna/comunes. En el diccionario bilingüe la entrada quedarı́a como se ve
en la figura 3.17: en la dirección LR (de español a catalán), la información
de género no es m, f ni mf sino GD; este género por determinar lo determinará a continuación el módulo de transferencia estructural mediante
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
43
la aplicación de las reglas de transferencia apropiadas (normalmente reglas de concordancia entre formas léxicas de un patrón; véase el apartado
3.5 para obtener una descripción detallada del funcionamiento de las reglas de este módulo). Análogamente, se puede definir un mecanismo similar, mediante el sı́mbolo ND, para el caso del número singular–plural (por
ejemplo, en español análisis es singular y plural, mientras que en catalán
el singular es anàlisi y el plural anàlisis).
<e r="LR">
<p>
<l>común<s n="adj"/><s n="mf"/></l>
<r>comú<s n="adj"/><s n="GD"/></r>
</p>
</e>
<e r="RL">
<p>
<l>común<s n="adj"/><s n="mf"/></l>
<r>comú<s n="adj"/><s n="m"/></r>
</p>
</e>
<e r="RL">
<p>
<l>común<s n="adj"/><s n="mf"/></l>
<r>comú<s n="adj"/><s n="f"/></r>
</p>
</e>
Figura 3.17: Entradas en el diccionario bilingüe español–catalán para la correspondencia común–comú, la primera para la traducción del español al catalán y las
dos últimas para la traducción del catalán al español
Diccionarios de postgeneración
En el diccionario morfológico, las formas léxicas que, una vez generadas, pueden sufrir operaciones de contracción, apostrofación, etc., según
las palabras que entren en contacto con ellas en el texto resultante, deben
llevar la marca de activación del postgenerador (<a/>, véase la página 36)
en la entrada de generación (dirección LR). Es fundamental que las formas superficiales marcadas con la marca de activación del postgenerador
44
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
coincidan en los diccionarios morfológicos y de postgeneración del mismo
traductor. En el diccionario de postgeneración, todas las entradas comienzan por esta marca de activación.
En la figura 3.18 se muestra un ejemplo de fragmento del postgenerador para el español; en este ejemplo se puede ver cómo se realiza la
contracción de de y el para formar del. En el ejemplo, el paradigma no definido, puntuación, es un paradigma que se limita a definir los caracteres
no alfabéticos que pueden formar parte de un texto. Vemos en el ejemplo que la entrada para la preposición de lleva la marca <a/>. El paradigma asignado a esta entrada, ”el”, es el que encontramos definido arriba.
De este modo, cuando el sistema se encuentra con la cadena izquierda
de la entrada (la parte entre <l>) concatenada con la cadena izquierda
del paradigma (es decir, cuando se encuentra con las cadenas de entrada "<a/>de<b/>el<b/>" o bien "<a/>de<b/>el[puntuación]"), el
módulo ofrece como cadena de salida (la parte entre <r>) la cadena "del"
seguida de los blancos representados por <b/> o de los sı́mbolos representados por [puntuación]. Nótese que a la salida del módulo todas las
marcas <a/> han sido eliminadas.
[Nota: en l’exemple, .el”no ha de portar la marca d’activació oi? - l’he
treta de l’exemple, treure-la dels diccionaris (Mikel?)]
3.1.2.6. Unidades léxicas multipalabra
Con el formato propuesto para los diccionarios es posible introducir
unidades léxicas multipalabra —simplificando, multipalabras— de formas diferentes dependiendo del problema que haya que resolver.
En este proyecto se consideran tres tipos básicos de unidades multipalabra:
1. El caso más sencillo es el de las multipalabras sin flexión, que están
formadas por una sola forma léxica, ya que su lema consta de varias
palabras ortográficas invariables pero se etiqueta como una unidad.
En la figura 3.19 se muestra un ejemplo de unidad multipalabra invariable (la expresión hoy en dı́a). Esta multipalabra consta de tres
palabras separadas por un blanco (<b/>) y, aunque estrictamente
esté formada por un adverbio, una preposición y un nombre, se etiqueta globalmente como adverbio, pues cumple una función equivalente.
2. Un caso algo más complejo es el de las multipalabras compuestas, que
están formadas por más de una forma léxica, cada una con sus sı́mbo-
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
45
<dictionary>
<pardefs>
...
<pardef n="el">
<e>
<p>
<l>el<b/></l>
<r>l<b/></r>
</p>
</e>
<e>
<p>
<l>el</l>
<r>l</r>
</p>
<par n="puntuación"/>
</e>
</pardef>
...
</pardefs>
<section id="main" type="standard">
...
<e>
<p>
<l><a/>de<b/></l>
<r>de</r>
</p>
<par n="el"/>
</e>
...
</section/>
</ditionary>
Figura 3.18: Diccionario de postgeneración en el que se observa la información
necesaria para la contracción española de + el = del .
46
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<e lm="hoy en dı́a">
<p>
<l>hoy<b/>en<b/>dı́a</l>
<r>hoy<b/>en<b/>dı́a<s n="adv"/></r>
</p>
</e>
Figura 3.19: Ejemplo de multipalabra sin flexión en el diccionario morfológico.
los gramaticales. Se considera que las palabras de las que se componen no conforman una unidad semántica como en el caso anterior, y
que sólo aparecen juntas formando una unidad por razones de contacto entre sı́ (razones fonéticas u ortográficas). En esta categorı́a entran las contracciones y los pronombres enclı́ticos que acompañanan a
los verbos. Para marcar este fenómeno se usa la etiqueta <j> descrita en la página 37. Puede verse un ejemplo en la figura 3.20, en la que
el análisis de del entrega una multiforma léxica compuesta por dos
formas léxicas: de, preposición, y el, determinante definido masculino singular, enlazadas mediante el elemento <j/>. El analizador y
el desambiguador léxico categorial tratan estas multipalabras como
una unidad; sin embargo, antes de entrar al módulo de transferencia son procesadas por un módulo auxiliar llamado pretransfer
(véase el apartado 3.3) que se encarga de separar las formas léxicas
de las que se componen. De este modo llegan al módulo de transferencia como formas independientes; es el lingüista quien debe decidir si hay que volver a unirlas (tarea que debe realizarse en el módulo
de transferencia estructural) o si deben continuar como formas independientes a través de los módulos posteriores.
En nuestro sistema, los elementos que forman cada contracción prosiguen como formas independientes, y es tarea del postgenerador
realizar la contracción en la lengua meta en caso de que sea necesaria. En cambio, los pronombres enclı́ticos vuelven a unirse al verbo
mediante una regla de transferencia estructural (véase el apartado
3.5), de modo que el verbo más los enclı́ticos llegan como una sola multiforma léxica al módulo de generación, unidos entre sı́ mediante el elemento <j/>. Por lo tanto, las entradas que contienen
pronombres enclı́ticos no deberán tener ninguna restricción de dirección, como puede verse en el ejemplo de la figura 3.21, que muestra
un fragmento del paradigma del verbo ”dar”, concretamente la en-
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
47
<e lm="del" r="LR">
<p>
<l>del</l>
<r>de<s n="pr"/><j/>
el<s n="det"/><s n="def"/>
<s n="m"/><s n="sg"/></r>
</p>
</e>
Figura 3.20: Ejemplo de entrada para analizar una contracción (la contracción española del) en el diccionario morfológico.
<e>
<p>
<l>ar</l>
<r>ar<s n="vblex"/><s n="inf"/><j/></r>
</p>
<par n="S__cantar"/>
</e>
Figura 3.21: Fragmento del paradigma de flexión del verbo dar, que muestra la entrada correspondiente a la forma de infinitivo seguida de un pronombre enclı́tico. Los pronombres enclı́ticos están contenidos en el paradigma S cantar. Obsérvese que, a diferencia de la figura 3.20, la entrada
es tanto de análisis como de generación.
trada correspondiente a la forma de infinitivo unida a un pronombre
enclı́tico.
3. El caso más complejo de los que se especifican en este documento
es el de las multipalabras con flexión intercalada en medio del lema (o
formas de ”lema partido”), que se muestra en la figura 3.22. Este tipo
de multipalabras se caracterizan por tener lemas con una parte afectada por la flexión (a la que llamamos cabeza del lema) seguida de una
parte invariable (a la que llamamos cola del lema). La parte invariable
se colocará entre elementos <g>, para poder moverla a la posición
inmediatamente posterior a la cabeza del lema con el objetivo de obtener el lema de la multipalabra. Es decir, conviene considerar que
el lema de multipalabras como echó de menos, echándole de menos, etc.
sea echar de menos, ya que será esta forma la que se buscará en el
diccionario bilingüe para encontrar su traducción. Esto supondrá un
48
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<e lm="echar de menos">
<i>ech</i>
<par n="aspir/ar__vblex"/> <!-- incluye pronombres enclı́ticos -->
<p>
<l><b/>de<b/>menos</l>
<r><g><b/>de<b/>menos</g></r>
</p>
</e>
Figura 3.22: Ejemplo de entrada en el diccionario morfológico que contiene
un grupo <g>.
adelantamiento de la cola del lema (de menos) detrás de la forma no
flexionada de la cabeza del lema (echar). Este adelantamiento se realizará en el módulo auxiliar pretransfer (véase el apartado 3.3)
que se ejecuta antes del módulo de transferencia estructural.
Para entender el ejemplo de la figura 3.22, hay que tener en cuenta
que el paradigma que define el verbo echar incluye, además de la
flexión del verbo, los pronombres enclı́ticos que van al final de las
formas flexionadas del verbo, los cuales aparecen enlazados, en la
multiforma léxica resultante, usando el elemento vacı́o <j/>.
Cuando la traducción es también un lema partido (por ejemplo, en
catalán trobar a faltar, con formas como trobem a faltar, trobar-lo a faltar, etc.), es necesario recolocar la cola en su sitio, tras la forma flexionada más los pronombres enclı́ticos, en caso de haberlos, e indicar la correspondencia de estos fragmentos invariables del lema
(de menos, a faltar) a ambos lados de la traducción. Ası́, en el ejemplo de la figura 3.22, el elemento <g> sirve para diferenciar el grupo
‘<b/>de<b/>menos’ en el diccionario morfológico. En el diccionario bilingüe (véase la figura 3.23), el elemento <g> sirve para establecer una correspondencia entre los grupos “<b/>de<b/>menos”
y “<b/>a<b/>faltar”.
[Nota: I com serà el cas de “dirección general” - “direcciones
generales”?]
Cuando la traducción no es ningún lema partido, no hace falta introducir ningún elemento <g> en la cadena correspondiente a la lengua
meta.
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
49
<e>
<p>
<l>echar<g><b/>de<b/>menos</g><s n="vblex"/></l>
<r>trobar<g><b/>a<b/>faltar</g><s n="vblex"/></r>
</p>
</e>
Figura 3.23: Ejemplo de entrada en el diccionario bilingüe que contiene dos grupos <g> en correspondencia.
3.1.2.7.
Metaparadigmas
[Nota: Marco diu: Especificar la DTD?]
Al desarrollar los diccionarios para el traductor de occitano surgió la
necesidad de crear una herramienta que permitiera la especificación de
paradigmas para verbos que tenı́an una misma flexión pero cuya raı́z cambiaba en las diferentes formas flexionadas. Con el sistema de especificación
de paradigmas existente, era necesario crear un paradigma diferente para
cada verbo, puesto que los paradigmas sólo permitı́an especificar regularidades en la flexión de verbos con raı́z invariable. Con los metaparadigmas,
se puede especificar la regularidad de flexión junto con variaciones en la
raı́z del verbo.
Asimismo, los metaparadigmas permiten también especificar, en un
mismo paradigma, variación de sı́mbolos gramaticales para determinados
lemas. Es decir, varios lemas pueden hacer referencia a un mismo metaparadigma aunque tengan algún sı́mbolo gramatical diferente. Ası́ como en
el caso del occitano, los metaparadigmas han servido para tener un mismo
paradigma para entradas con variaciones en la raı́z, para el inglés, éstos
han servido para tener un mismo paradigma para entradas con variaciones en los sı́mbolos gramaticales.
A partir de ahı́ se ha creado el concepto de metadiccionario: un diccionari que contiene tanto metaparadigmas como paradigmas con el formato utilizado hasta ahora. El nombre de un diccionario de este tipo es
apertium-L1 -L2 .L1 .metadix (por ejemplo, para el diccionario monolingüe inglés de Apertium-en-ca, apertium-en-ca.en.metadix). Estos diccionarios son preprocesados cuando se compilan los datos lingüı́sticos de modo que tengan un formato apto para el compilador de diccionarios.
50
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
Especificación de metaparadigmas
Los metaparadigmas se definen en la sección <pardefs> del diccionario monolingüe, que es donde se definen también los demás paradigmas
del diccionario. Un metaparadigma, al igual que un paradigma, tiene un
nombre especificado en el atributo n. Este nombre tendrá las mismas caracterı́sticas que en los demás paradigmas, con la diferencia de que la parte variable del lema estará entre corchetes y con las letras en mayúsculas,
como se ve en este ejemplo:
<pardef n="m/é[T]er vblex">
Esto define un paradigma para verbo, donde las terminaciones de flexión presentan una parte variable en la raı́z. La flexión que se especifique
en este metaparadigma tiene que ser tal que flexione sólo la parte que hay
a la derecha de los corchetes, por ejemplo la que se especifica en el paradigma:
<par n="mét/er vblex"/>
De este modo, un ejemplo entero de elemento de definición de metaparadigma mediante <pardef> serı́a:
<pardef n="m/é[T]er__vblex">
<e>
<p>
<l>e</l>
<r>é</r>
</p>
<i><prm/></i>
<par n="sent/eria__vblex"/>
</e>
<e>
<i>é<prm/></i>
<par n="mét/er__vblex"/>
</e>
</pardef>
La etiqueta <prm/> es el indicativo que sirve para situar la parte de
texto variable (la terminación variable de la raı́z) dentro de la definición
del paradigma.
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
51
Ası́ es como se define un metaparadigma. Si ahora queremos que un
verbo lo utilice, en la entrada del verbo (dentro de un elemento <e>) debe
indicarse el metaparadigma correspondiente y , mediante el atributo prm,
especificar por qué letras se debe sustituir la parte variable cerrada entre
corchetes. Por ejemplo:
<e lm="acuélher">
<i>acu</i>
<par n="m/é[T]er__vblex" prm="lh"/>
</e>
Esta entrada define el verbo acuélher y especifica que el paradigma de
flexión que debe seguir es el indicado por el metaparadigma m/é[T]er vblex
pero sustituyendo T por lh; es decir, las letras que vienen después de acu
serán élher en lugar de éter.
Como se ha apuntado antes, los metaparadigmas pueden utilizarse
también para entradas que presenten alguna variación en los sı́mbolos
morfológicos. El modo de especificarlos es básicamente el mismo: la parte variable debe especificarse en la entrada correspondiente, mediante un
atributo sa, y en el paradigma debe colocarse la etiqueta <sa> en el lugar
en el que debe situarse el sı́mbolo morfológico opcional.
Por ejemplo, tenemos el siguiente metaparadigma:
<pardef n="house__n">
<e>
<p>
<l/>
<r><s n="n"/><sa/><s n="sg"/></r>
</p>
</e>
<e>
<p>
<l>s</l>
<r><s n="n"/><sa/><s n="pl"/></r>
</p>
</e>
</pardef>
y una entrada como la que sigue:
52
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<e lm="time">
<i>time</i>
<par n="house__n" sa="unc"/>
</e>
en la que unc especifica que el nombre es incontable.
En el metaparadigma, la etiqueta <sa> indica el lugar que debe ocupar
la etiqueta, en el caso de que una entrada contenga el atributo sa con un
valor, como es el caso de la entrada para time.
Un diccionario que presenta entradas como las descritas se denomina
metadiccionario y tiene que ser procesado para generar un diccionario que
siga la DTD de Apertium 2, puesto que el motor no permite el uso directo
de estos metaparadigmas. A continuación se explica en qué consiste este
procesamiento.
Procesamiento del metadiccionario
El metadiccionario es un fichero escrito en XML al que, para procesar
los metaparadigmas, se aplican dos hojas de estilo XSLT para obtener el
diccionario con todos los paradigmas derivados de los metaparadigmas.
Con una primera hoja de estilo, buscaPar.xsl, se obtienen los verbos
que hacen uso de metaparadigmas y se eliminan posibles repeticiones de
metaparadigmas a expandir. Esta hoja de estilo genera, en combinacio con
la hoja principal.xsl, una segunda hoja de estilo llamada gen.xsl,
que procesa el metadiccionario con la lista de paradigmas a expandir para
generar un diccionario con formato de Apertium 2. Básicamente lo que
hace esta hoja de estilo generada es:
1. En las entradas de verbos, si el verbo utiliza la flexión de un metaparadigma, se sustituye el metaparadigma por su correspondiente
paradigma expandido y desparametrizado. Ası́, la entrada del ejemplo anterior:
<e lm="acuélher">
<i>acu</i>
<par n="m/é[T]er__vblex" prm="lh"/>
</e>
se desparametrizarı́a y expandirı́a a:
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
53
<e lm="acuélher">
<i>acu</i>
<par n="m/élher__vblex"/>
</e>
2. Por otro lado, como de la primera pasada ya se sabe qué paradigmas
se tienen que crear a partir de los metaparadigmas, éstos se crean. En
el caso del ejemplo anterior, a partir del metaparadigma
<pardef n="m/é[T]er__vblex">
<e>
<p>
<l>e</l>
<r>é</r>
</p>
<i><prm/></i>
<par n="sent/eria__vblex"/>
</e>
<e>
<i>é<prm/></i>
<par n="mét/er__vblex"/>
</e>
</pardef>
se generarı́a el paradigma <pardef n="m/élher vblex/> :
<pardef n="m/élher__vblex">
<e>
<p>
<l>e</l>
<r>é</r>
</p>
<i>lh/></i>
<par n="sent/eria__vblex"/>
</e>
<e>
<i>élh</i>
<par n="mét/er__vblex"/>
</e>
</pardef>
54
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
Después de haber procesado el metadiccionario de esta forma se genera un diccionario .dix que sigue la DTD de Apertium 2 y que ya se puede
compilar.
En el segundo ejemplo que hemos dado, en el que la parte variable
era la secuencia de sı́mbolos morfológicos del paradigma, a partir de la
especificación del atributo sa como unc y de la aplicación de las hojas de
estilo, se generarı́a el paradigma:
<pardef n="house__n__unc">
<e>
<p>
<l/>
<r><s n="n"/><s n="unc"/><s n="sg"/></r>
</p>
</e>
<e>
<p>
<l>s</l>
<r><s n="n"/><s n="unc"/><s n="pl"/></r>
</p>
</e>
</pardef>
para nombres cuyo análisis morfológico deba ser (en formato del flujo
de datos):
time<n><unc><sg>
La utilización de metaparadigmas permite, en este caso, aprovechar
un mismo paradigma para entradas con misma flexión pero con análisis
morfológico ligeramente diferente.
Es importante tener en cuenta que, cuando un diccionario utilice metaparadigmas y, por lo tanto, tenga un nombre con extensión .metadix,
éste será el fichero en el que deben realizarse todos los cambios en el
diccionario (modificación, adición y borrado de entradas o paradigmas),
puesto que el fichero .dix se genera automáticamente a partir del primero cada vez que se compilan los datos lingüı́sticos y, por lo tanto, cualquier
cambio realizado directamente en este último será sobrescrito al realizarse
la compilación.
3.1. MÓDULOS DE PROCESAMIENTO LÉXICO
3.1.3.
55
Generación automática de los módulos de procesamiento léxico
Los cuatro módulos de procesamiento léxico (analizador morfológico,
transferencia léxica, generador morfológico y postgenerador) se compilan a partir de los diccionarios mediante un único compilador basado en
transductores de letras [14]. Este compilador es mucho más rápido que los
utilizados en los sistemas interNOSTRUM [2, 5, 4] y Traductor Universia
[7, 17], gracias a la utilización de nuevas estrategias de construcción de
transductores y a la minimización de transductores parciales durante la
construcción [11].
La división de entradas del diccionario en lema y paradigma permite construir eficazmente transductores de letras mı́nimos. El compilador
aprovecha completamente la factorización que permiten los paradigmas
para acelerar la construcción. Como en la mayorı́a de lenguas europeas
las modificaciones de las palabras tienen lugar al final o al principio de las
mismas, hemos explotado este hecho para mejorar la velocidad de construcción del transductor mı́nimo.
Los paradigmas se minimizan antes de ser insertados en el transductor
para reducir el tamaño del transductor completo final antes de minimizar. Como antes de minimizar, los paradigmas de los diccionarios de las
lenguas con las que hemos trabajado suelen tener unos pocos cientos de
estados, la minimización de estos paradigmas es un proceso muy rápido.
Si suponemos que una entrada puede presentar una referencia a un
paradigma en cualquier punto de la misma, podrı́amos pensar en copiar
en ese punto el transductor que se calcula en la definición del paradigma. El procedimiento utilizado en Apertium se basa en que no siempre es
necesario copiar, sino que en determinadas ocasiones es posible reutilizar
un paradigma que ya haya sido copiado. En particular, dos o más entradas que comparten un paradigma como sufijo pueden reutilizar la misma
copia de ese paradigma y lo mismo sucede cuando ocurre como prefijo.
Sin embargo, en general, no es posible reutilizar paradigmas si se encuentran en posiciones intermedias de entradas diferentes, ya que se pueden
introducir nuevos sufijos (prefijos) a entradas existentes, lo que hace que
la información que se introduce en el transductor no sea consistente con
el diccionario, y el transductor generado serı́a incorrecto (añadirı́a pares
de cadenas que no se encuentran en el lenguaje formal que definen los
diccionarios).
La construcción de transductores de letras mı́nimos se realiza como se
explica a continuación. A partir de una transducción de cadenas se puede
construir una secuencia de transducciones de letras S(s : t) de longitud N =
56
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
Figura 3.24: Construcción del diccionario como aceptor de prefijos y enlace con
paradigmas mediante transiciones (θ : θ).
Figura 3.25: Paradigma ((-es n m)) minimizado que se usa en la figura 3.24.
máx(|s|, |t|) que se define como sigue para cada elemento 1 ≤ i ≤ N :


 (si : θ)
si i ≤ |s| ∧ i > |t|
(θ
:
t
)
si i ≤ |t| ∧ i > |s|
Si (s : t) =
i


(si : ti ) en otro caso
(3.1)
Hay que destacar que, por construcción, se asegura que no puede existir ningún (s : t) que sea igual a (² : ²), lo que es crucial para la consistencia
del método de construcción.
El método de construcción usa dos procedimientos, el procedimiento
de montaje que se infiere de la ecuación 3.1 y el de minimización, que se
realiza por un algoritmo convencional de minimización [16] de autómatas
finitos que consiste en invertir, determinizar, volver a invertir y volver a
determinizar, tomando como alfabeto del autómata que hay que minimizar el producto cartesiano L y como transición vacı́a la (θ : θ).
En la figura 3.24 se observa un ejemplo simplificado de este montaje.
Se introduce transducción por transducción compuesta como en la ecuación 3.1 en un transductor en forma de aceptor de prefijos o trie, es decir, de
manera en la que haya sólo un nodo para cada prefijo común del conjunto
3.2. DESAMBIGUADOR LÉXICO CATEGORIAL
57
Figura 3.26: Paradigma ((z/-ces n m)) minimizado que se usa en la figura 3.24.
de transducciones que forman el diccionario. Con los sufijos de las transducciones (que no se comparten) se crean estados nuevos. En el punto en
el que se haga referencia a un paradigma, se crea una réplica de ese paradigma y se enlaza a la entrada del diccionario que se está insertando en el
transductor mediante una transducción nula (θ : θ).
Cada uno de los paradigmas, en tanto que pueden ser vistos como pequeños diccionarios, se han construido por este mismo procedimiento a
su vez y se han minimizado para reducir el tamaño del problema en la
construcción del diccionario grande. En las figuras 3.25 y 3.26 se muestra
el estado de los dos paradigmas utilizados en la figura 3.24 después de la
minimización.
3.2. Desambiguador léxico categorial
3.2.1. Descripción del funcionamiento
El desambiguador léxico categorial está basado en modelos ocultos de
Markov [13] de primer orden, es decir, en información de naturaleza estadı́stica. Los estados del modelo de Markov representan categorı́as gramaticales y los observables son clases de ambigüedad [3], esto es, conjuntos de categorı́as gramaticales.
A pesar de trabajar con información estadı́stica, el entrenamiento y el
comportamiento actual del desambiguador mejoran si se introducen restricciones que impiden determinadas secuencias de categorı́as (en los modelos de primer orden, estas secuencias solo pueden implicar a dos categorı́as); por ejemplo, en español o catalán una preposición nunca puede ir
seguida de un verbo conjugado en forma personal, restricción que es de
gran ayuda cuando la forma que sigue a la preposición es ambigua y uno
58
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
de sus análisis morfológicos es verbo en forma personal (p.e., de trabajo,
en libertad, etc.). En el fichero de definición del desambiguador se declaran
explı́citamente estas restricciones, a veces en forma de prohibiciones y otras
en forma de obligaciones.
Las etiquetas gramaticales con las que trabaja el desambiguador no son
las mismas que se utilizan en el analizador morfológico. Normalmente, la
información que entrega el analizador morfológico es demasiado detallada para la desambiguación léxica categorial (por ejemplo, para la mayorı́a
de los propósitos, es suficiente agrupar en una misma categorı́a todos los
substantivos comunes, independientemente de su género y su número).
El empleo de etiquetas más finas no mejora los resultados, al tiempo que
incrementa considerablemente el número de parámetros a estimar y hace
más acusado el problema de la escasez de recursos lingüı́sticos tales como
textos desambiguados a mano. Por este motivo, en el fichero del desambiguador se especifica cómo agrupar las etiquetas finas (o especı́ficas) proporcionadas por el analizador morfológico en etiquetas gruesas —que llamaremos categorı́as— más generales que se emplearán en la desambiguación léxica categorial. Además de las categorı́as gruesas, también pueden
definirse etiquetas lexicalizadas. En la bibliografı́a se describen básicamente dos tipos de lexicalizaciones, las que añaden nuevos observables y las
que además añaden nuevos estados al modelo de Markov [12]; el desambiguador léxico categorial de Apertium utiliza este último tipo de lexicalización.
Cabe recordar que, pese a trabajar con categorı́as gruesas, el desambiguador proporciona a su salida etiquetas finas como las del analizador
morfológico. De hecho, en ocasiones, puede suceder que el analizador
morfológico entregue, para una palabra dada, dos o más etiquetas finas
que pueden agruparse bajo una misma categorı́a: p. e., en español cante
puede ser la 1a o la 3a persona del presente de subjuntivo del verbo cantar;
las dos etiquetas finas, <vblex><prs><p1><sg> y <vblex><prs><p1><sg>,
se agrupan bajo la categorı́a VLEXSUBJ (verbo subjuntivo). En este caso,
una de las dos etiquetas finas es descartada; en el fichero de definición del
desambiguador se puede definir qué etiqueta fina de las que componen
una etiqueta gruesa será la entregada tras la desambiguación.
3.2.2.
Datos para el desambiguador léxico categorial
3.2.2.1. Introducción
A continuación se describe el formato de los ficheros en los que se especifica cómo agrupar las etiquetas finas proporcionadas por el analiza-
3.2. DESAMBIGUADOR LÉXICO CATEGORIAL
59
dor morfológico en etiquetas gruesas más generales. En dichos ficheros,
además, se pueden especificar restricciones que ayuden a la estimación
del modelo estadı́stico encargado del proceso de desambiguación léxica,
ası́ como reglas de preferencia para el caso de que a dos etiquetas finas les
corresponda la misma categorı́a.
El desambiguador asume que a su entrada las palabras se encontrarán
convenientemente delimitadas, tal como se especifica en el formato del flujo de datos entre módulos (capı́tulo 2). El formato de los datos entregados
por el analizador morfológico, a grandes rasgos, es como sigue:
formaanalizada
multiformaléxica
formaléxica
cola-lema
etiquetafina
→
→
→
→
→
multiformaléxica [ multiformaléxica ]∗
formaléxica [ formaléxica ]∗ cola-lema?
lema etiquetafina
lema
sı́mbologram [ sı́mbologram ]∗
(3.2)
donde:
formaanalizada es toda la información que se entrega para cada forma
superficial a la salida del analizador morfológico
multiformaléxica es una secuencia de una o más formas léxicas seguida, opcionalmente, por una cola invariable como en el caso de
algunas multipalabras (cántale las cuarenta).
formasléxicas4 son unidades compuestas por un lema y una o más
etiquetas con la información de la salida del analizador
cola-lema está compuesta por uno o más lemas5 que forman la parte
invariable de una multipalabra. La cola de una multipalabra está formada por el lema o los lemas sin flexión que siguen a los lemas con
flexión. Por ejemplo, la multipalabra cantar las cuarenta puede tomar
las formas cántale las cuarenta, (le) cantaré las cuarenta, cantándole las
cuarenta, etc. La cola serı́a en este caso las cuarenta (véase la página 44
para más información).
etiquetafina corresponde a uno o más sı́mbolos gramaticales (sı́mbologram).
4
Separadas entre ellas por un delimitador que se corresponde con el elemento <j/>
(ver página 37).
5
Separados entre ellos mediante el elemento <b/> (ver página 36).
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
60
Por ejemplo, la entrada correspondiente a la forma superficial ambigua
española correos tendrı́a dos multiformas léxicas; la primera multiforma
léxica tendrı́a una única forma léxica, con lema correo y una etiqueta fina
compuesta de los sı́mbolos gramaticales nombre común, masculino, plural; la
segunda multiforma léxica serı́a una secuencia de dos formas léxicas, una
con lema correr y etiqueta fina compuesta de los sı́mbolos gramaticales
verbo léxico, imperativo, segunda persona, plural y la otra con lema vosotros, y
etiqueta fina compuesta por los sı́mbolos pronombre, enclı́tico, segunda persona, masculino-femenino, plural.
3.2.2.2. Especificación del formato
El formato del fichero (codificado en XML) se especifica mediante la
DTD que se observa en el apéndice A.2.
El significado de las etiquetas es como sigue:
tagger : es el elemento raı́z; su atributo obligatorio name sirve para especificar el nombre del etiquetador generado a partir del fichero.
tagset : define el etiquetario grueso de las categorı́as con el que trabaja
el desambiguador. Las categorı́as se definen a partir de las etiquetas
finas que proporciona el analizador morfológico a su salida.
def-label : define una categorı́a o etiqueta gruesa (cuyo nombre se indica en el atributo obligatorio name) en términos de listas de etiquetas
finas definidas mediante uno o más elementos tags-item; un atributo opcional closed indica si la categorı́a es cerrada; de ser cerrada
se entiende que una palabra desconocida nunca puede pertenecer a
esta categorı́a.6
Las categorı́as más especı́ficas deben definirse antes de las más generales. Cuando la definición de una categorı́a general incluye implı́citamente la de una categorı́a especı́fica definida previamente, se entiende que se refiere a todos los casos excepto los definidos por las
categorı́as más especı́ficas.
tags-item : permite definir una etiqueta fina en términos de una secuencia de sı́mbolos gramaticales. Mediante el atributo obligatorio tags
se define la secuencia de sı́mbolos gramaticales que conforman la etiqueta fina. En dicha secuencia los sı́mbolos gramaticales se separan
6
Las categorı́as cerradas son aquellas que no crecen cuando se crea nuevo léxico: preposiciones, determinantes, conjunciones, etc.
3.2. DESAMBIGUADOR LÉXICO CATEGORIAL
61
por puntos y el asterisco “*” se utiliza para indicar que en determinada posición puede aparecer cualquier secuencia de sı́mbolos.
También se pueden especificar categorı́as lexicalizadas indicando en
el atributo lemma el lema deseado.
def-mult : define categorı́as especiales (multicategorı́as) formadas por varias categorı́as, para tratar el caso de que una entrada presente multiformas léxicas como las definidas en la sección anterior. Cada categorı́a se define como un conjunto de secuencias (sequence) válidas
de categorı́as definidas previamente o de etiquetas finas. Su uso es
apropiado para contracciones, verbos con enclı́ticos, etc.
sequence : define una secuencia de elementos que pueden ser categorı́as
(label-item) o etiquetas finas (tags-item). El utilizar directamente etiquetas finas es útil si se desea utilizar una secuencia de
sı́mbolos gramaticales que no forma parte de una etiqueta fina ya
definida o que supone una especialización mayor de una etiqueta
fina ya creada.
label-item : permite hacer referencia a una categorı́a o etiqueta gruesa
ya definida con anterioridad y que se especifica en el atributo obligatorio label.
forbid : esta sección (opcional) permite definir restricciones en forma de
secuencias de categorı́as label-sequence que no pueden darse en
el idioma en cuestión. En la versión actual, al estar el desambiguador
basado en modelos ocultos de Markov de primer orden, las secuencias sólo pueden estar formadas por dos label-items.
label-sequence : define una secuencia de categorı́as (label-item).
enforce-rules : esta sección (opcional) permite definir restricciones en
forma de obligaciones.
enforce-after : define una restricción que obliga a que a una determinada categorı́a sólo puedan seguirle categorı́as pertenecientes al conjunto (label-set) de categorı́as que se define. Nótese que este tipo
de restricciones es equivalente a definir varias secuencias (label-sequence)
prohibidas (forbid) con la categorı́a definida mediante el atributo
obligatorio label y el resto de categorı́as no pertenecientes al conjunto definido en label-set. Por esta razón, este tipo de restricción
debe usarse con mucha cautela.
label-set : define un conjunto de categorı́as (label-items).
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
62
preferences : permite definir prioridades en cuanto a qué etiquetas finas se deben producir a la salida del desambiguador cuando una o
más etiquetas finas sean asignadas a la misma categorı́a.
prefer : especifica que en caso de conflicto entre varias etiquetas finas
asignadas a la misma categorı́a, el desambiguador debe proporcionar a la salida la etiqueta definida mediante el atributo obligatorio
tags. Si la categorı́a contiene más de una de las etiquetas finas definidas en estos elementos prefer, se entregará la que esté definida
antes.
Las figuras 3.27 y 3.28 muestran con un ejemplo las partes más importantes de un fichero de especificación de desambiguador definido por la
DTD que acabamos de describir.
3.2.3.
Consideraciones sobre el entrenamiento del desambiguador léxico categorial
El entrenamiento del desambiguador léxico categorial podrá hacerse
tanto de forma supervisada, utilizando textos desambiguados a mano, como de forma no supervisada, con textos ambiguos.
Cuando el entrenamiento se realice a partir de textos ambiguos (de forma no supervisada) el formato de dicho texto se podrá obtener de forma
automática a partir de un corpus de texto llano de la lengua deseada utilizando el analizador morfológico del sistema; en este caso el formato de las
formas del texto será como el definido en el esquema 3.3 (puede leerse su
descripción en la página 59). Como muestra el esquema, puede haber más
de un análisis para cada forma superficial analizada (una formaanalizada
puede dar como resultado más de una multiformaléxica).
formaanalizada
multiformaléxica
formaléxica
cola-lema
etiquetafina
→
→
→
→
→
multiformaléxica [ multiformaléxica ]∗
formaléxica [ formaléxica ]∗ cola-lema?
lema etiquetafina
lema
sı́mbologram [ sı́mbologram ]∗
(3.3)
Para el entrenamiento supervisado se necesita texto desambiguado a
mano. El formato de las formas de estos textos será como el proporcionado por el analizador morfológico (véase el capı́tulo 2) con la salvedad de
3.2. DESAMBIGUADOR LÉXICO CATEGORIAL
63
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE tagger SYSTEM "tagger.dtd">
<tagger name="es-ca">
<tagset>
<def-label name="adv">
<tags-item tags="adv"/>
</def-label>
<def-label name="detnt" closed="true">
<tags-item tags="detnt"/>
</def-label>
<def-label name="detm" closed="true">
<tags-item tags="det.*.m"/>
</def-label>
<def-label name="vlexpfci">
<tags-item tags="vblex.pri"/>
<tags-item tags="vblex.fti"/>
<tags-item tags="vblex.cni"/>
</def-label>
<def-mult name="infserprnenc" closed="true">
<sequence>
<label-item label="vserinf"/>
<label-item label="prnenc"/>
</sequence>
<sequence>
<label-item label="vserinf"/>
<label-item label="prnenc"/>
<label-item label="prnenc"/>
</sequence>
</def-mult>
<def-mult name="prepdet" closed="true">
<sequence>
<label-item label="prep"/>
<tags-item tags="det.def.m.sg"/>
</sequence>
</def-mult>
</tagset>
<!-- ... -->
Figura 3.27: Ejemplo de fichero de definición del desambiguador (continúa en la
figura 3.28).
64
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<!-- ... -->
<forbid>
<label-sequence>
<label-item label=="prep"/>
<label-item label=="vlexpfci"/>
</label-sequence>
<!-- ... -->
</forbid>
<enforce-rules>
<enforce-after label=="prnpro">
<label-set>
<label-item label=="prnpro"/>
<label-item label=="vlexpfci"/>
<!-- ... -->
</label-set>
</enforce-after>
<!-- ... -->
</enforce-rules>
<preferences>
<prefer tags="vblex.pii.3.sg"/>
<prefer tags="vbser.pii.3.sg"/>
<!-- ... -->
</preferences>
</tagger>
Figura 3.28: Ejemplo de fichero de definición del desambiguador (viene de la figura 3.27).
3.2. DESAMBIGUADOR LÉXICO CATEGORIAL
65
que, al tratarse de texto ya desambiguado, nunca habrá más de una forma léxica asociada a cada forma superficial como se muestra en 3.4 (una
formadesambiguada consistirá siempre en una única multiformaléxica).
formadesambiguada
multiformaléxica
formaléxica
cola-lema
etiquetafina
→
→
→
→
→
multiformaléxica
formaléxica [ formaléxica ]∗ cola-lema?
lema etiquetafina
lema
sı́mbologram [ sı́mbologram ]∗
(3.4)
Por último, para el entrenamiento también se precisa del diccionario de
la lengua implicada. Este diccionario se emplea para determinar conjuntamente con la especificación del etiquetario a emplear las distintas clases
de ambigüedad con las que trabaja el desambiguador.
La figura 3.29 muestra el esquema de dependencias para el entrenamiento y el uso del desambiguador.
[Nota: Aquest esquema canviarà amb el nou tagger - Sergio]
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
66
Figura 3.29: Esquema de dependencias del desambiguador léxico categorial.
used only if supervised training
tagset definition
lang.tsx
dictionary
lang.dic
training corpus
lang.crp
tagged corpus
analized corpus
lang.tagged
lang.untagged
apertium-tagger { --train <n> | --supervised <n> } lang
3.3. PREPROCESO DE LA TRANSFERENCIA
67
3.3.
Módulo auxiliar: módulo de preproceso de
la transferencia
3.3.1.
Motivación
El módulo de preproceso de la transferencia pretransfer, se ocupa
de fragmentar las unidades multipalabra compuestas (ver la página 44) y
mover ciertas partı́culas de lugar en las multipalabras con flexión intercalada o de lema partido. Este módulo procesa la salida del etiquetador y
genera una entrada apta para el módulo de transferencia. Este procesamiento es necesario por varias razones:
Para que el módulo de transferencia pueda tratar estas unidades por
separado para tratar, por ejemplo, fenómenos de cambio de pronombres enclı́ticos por pronombres proclı́ticos o viceversa.
Para que en el diccionario bilingüe sólo haya que almacenar información de los lemas que se traducen. Si las partı́culas que componen
una unidad multipalabra se presentan conjuntamente en el diccionario bilingüe, este diccionario tiene que tener una entrada para cada
una de estas composiciones. Mediante la separación se consigue no
tener entradas para multipalabras que incluyan la flexión en el diccionario bilingüe.
3.3.2. Comportamiento y ejemplo
El funcionamiento del programa consiste en sustituir cada <j/> en el
diccionario, es decir, cada + en el flujo de datos, por un carácter de fin
de palabra, un espacio en blanco y un carácter de comienzo de palabra.
Además, si se trata de una multipalabra de lema partido, se mueve la cola
a la posición que queda entre el final de la primera palabra de la multipalabra y la primera etiqueta morfológica que se corresponde con esta
palabra.
La responsabilidad de generar una salida de este módulo que tenga el
orden original que acepta el generador se deja a las reglas correspondientes del módulo de transferencia, ası́ como la de crear las multipalabras
compuestas que sean necesarias en la lengua meta. El generador trabaja,
en general, con las mismas multipalabras que el analizador morfológico, y
con los elementos en el mismo orden, y es por eso que esta tarea hay que
realizarla en el módulo de transferencia.
68
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
A continuación se muestra el resultado de aplicar este proceso a la multipalabra compuesta darlo:
$ pretransfer
ˆdar<vblex><inf>+lo<prn><enc><p3><m><sg>$
ˆdar<vblex><inf>$ ˆlo<prn><enc><p3><m><sg>$
←− entrada
←− salida
Como se puede ver, sencillamente se trata de dividir las formas léxicas
de una unidad multipalabra compuesta en formas léxicas individuales.
Cuando se trata de una multipalabra con lema partido, se opera como
se ve en el siguiente ejemplo para la multipalabra echarte de menos:
$ pretransfer
ˆechar<vblex><inf>+te<prn><enc><p2><m><sg># de menos$
ˆechar# de menos<vblex><inf>$ ˆte<prn><enc><p2><m><sg>$
Aquı́, además de dividir las formas léxicas, se produce un movimiento
de la cola invariable del lema a la posición anunciada. Como vemos, con el
movimiento de esta cola invariable, las unidades semánticas se mantienen,
ya que se puede considerar echar de menos como una unidad verbal con
significado propio.
3.4.
Módulo de selección léxica
3.4.1.
Introducción
Cuando el sistema Apertium se utiliza para traducir automáticamente
entre lenguas menos emparentades que las que ha tratado hasta ahora, toma importancia la cuestión de la selección léxica, que debe llevarse a cabo
cuando una palabra de la lengua origen puede tener más de una traducción en lengua meta. Por este motivo se ha creado un nuevo módulo, el
módulo de selección léxica, que se ocupa de esta cuestión.
Antes de explicar sus caracterı́sticas, veremos como los problemas de
equivalencia múltiple (la existencia de más de una traducción posible en lengua meta para un lema o una forma léxica en lengua origen) se tratan en
Apertium de dos maneras diferentes.
Por un lado, nos encontramos con la situación en que entre los múltiples equivalentes en lengua meta no hay una gran diferencia de significado, y el hecho de escoger entre uno u otro no comportarı́a ningún error
de traducción. Podrı́amos decir que entre estos equivalentes hay una relación de sinonı́mia o casi-sinonı́mia. En este caso, el lingüista escoge como
3.4. MÓDULO DE SELECCIÓN LÉXICA
69
traducción uno de los dos lemas (generalmente el más frecuente o más
usual), y pone una restricción de dirección en los otros (con los atributos
LR o RL) para que sean traducidos en la dirección contraria pero no en la
dirección en que hay múltiples equivalentes.
Por otro lado, tenemos el caso en que entre los múltiples equivalentes en lengua meta hay una evidente diferencia de significado que puede
conllevar errores de traducción cuando se elige el lema inadecuado. Estos
casos son los que trata el nuevo módulo de selección léxica. El lingüista codifica las entradas con los atributos slr o srl que se explican en el
apartado siguiente, identificando ası́ las diferentes posibilidades de traducción, y el módulo de selección léxica se ocupa de escoger, mediante
procedimientos estadı́sticos, cuál es la traducción adecuada en un contexto determinado.
Decidir cuándo una situación de equivalencia múltiple debe solucionarse de una manera o de la otra, a veces no es sencillo. Por ejemplo,
cuando entre dos o más lemas de la lengua meta existe diferencia de significado, pero consideramos que el módulo de selección léxica no será capaz
de escoger la buena traducción a partir del contexto, seguiremos el primer
método: escoger la traducción fija que queramos (la más general, la que
consideramos adecuada en el máximo de situaciones posibles) y poner
una restricción de dirección en el resto de equivalentes. En los demás casos, codificaremos las entradas de forma que la decisión quede en manos
del módulo de selección léxica.
Cuando se utilice un sistema Apertium sin módulo de selección léxica, la única manera de codificar entradas con varias traducciones posibles
es la primera, es decir, escogiendo una única traducción y marcando el
resto de equivalencias con una restricción de dirección. En caso de que
utilicemos diccionarios bilingües con múltiples traducciones, codificades
con los atributos slr o srl, en un sistema que no dispone de módulo de
selección léxica, una hoja de estilo se encarga de convertir estas entradas
pensadas para el módulo de selección léxica en entradas con restricciones
de dirección LR o RL, de manera que uno de los múltiples equivalentes
(el que el lingüista haya escogido como entrada predeterminada) queda
como traducción fija del lema en lengua origen.
Como ejemplos de equivalencias bilingües que deberı́an llevar una restricción de dirección, podemos dar los pares de traducción ca-es encara –
aún/todavı́a y sobtat – súbito/repentino, el primero de los cuales podrı́a quedar ası́:
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
70
text
en
llengua
origen
↓
transf.
postgen.
desfor- → anal. → desamb.→ selec.→
→
→
→ reforesgenerador matador
categ.
morf.
matador morf.
lèxic
truc.
l
↓
text
en
transf.
llenlèxica
gua
meta
Figura 3.30: Los nuevo módulos que forman la cadena de montaje de la versión 2
del sistema de traducción automática Apertium.
<e r="LR">
<p>
<l>aún<s n="adv"/></l>
<r>encara<s n="adv"/></r>
</p>
</e>
<e>
<p>
<l>todavı́a<s n="adv"/></l>
<r>encara<s n="adv"/></r>
</p>
</e>
Como ejemplo del segundo caso (múltiples equivalentes con gran diferencia de significado) tenemos los pares es-ca hoja – full/fulla o muñeca
– nina/canell, y los ejemplos en-ca que se muestran en la página 39, donde se explica de qué manera se indican en el diccionario bilingüe estos
múltiples equivalentes.
La figura 3.30 muestra cómo queda la cadena de montaje en la versión
2 de Apertium.7
7
Esta figura reemplaza la figura 1.1 que se encuentra en la página 6 de la documentación de la versión 1 de Apertium.
3.4. MÓDULO DE SELECCIÓN LÉXICA
71
[Nota: MG: caldria canviar la figura de la pàgina 6 per aquesta d’aquı́?]
El módulo encargado de la selección léxica (selector léxico) se ejecuta después del desambiguador léxico categorial y antes del módulo encargado
de la transferencia estructural; por lo tanto, este nuevo módulo trabaja
únicamente con información de la lengua origen.
A continuación, en la sección 3.4.2 se explica el preprocesamiento a que
debe someterse un diccionario bilingüe que contiene más de una traducción por entrada, tanto si se usa un módulo de selección léxica como si no,
y en la sección 3.4.3 se explica cómo funciona y cómo se tiene que entrenar
el módulo que realiza la selección léxica.
3.4.2.
Preprocesamiento de los diccionarios bilingües
El hecho de que, con esta modificación, se creen diccionarios bilingües
que permiten la especificación de más de una traducción por entrada (véase
en la sección 3.1.2.4 cómo se especifican estas entradas) hace necesario un
preprocesamiento de estos diccionarios, puesto que el motor de traducción
Apertium trabaja con diccionarios compilados en los que cada palabra tiene sólo una traducción posible.
El preprocesamiento de los diccionarios se hace automáticamente durante la compilación, por lo que el usuario final no tiene que ejecutar ninguna acción especial.
3.4.2.1.
Preprocesamiento sin módulo de selección léxica
Cuando los diccionarios bilingües con múltiples equivalentes se utilicen en un sistema que no dispone de módulo de selección léxica, el preprocesamiento se realiza con la aplicación de la hoja de estilo translate-to-default-equivalent.xsl. Esta hoja de estilo convierte los diccionarios con más de una posible traducción por entrada en diccionarios con
una sola traducción por entrada, escogiendo como traducción la entrada
marcada como equivalente predeterminado, y poniendo una restricción
de dirección (LR o RL según el caso) en las demás entradas, de forma que
éstas sólo se traducen en la dirección de traducción en la que no hay multiplicidad de equivalentes. Esta hoja de estilo se llama desde el Makefile.
Como ejemplo, las tres primeras entradas que se muestran en la página
39 quedan ası́ después de la aplicación de la hoja de estilo mencionada:
<e>
<p>
72
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<l>flat<s n="n"/></l>
<r>pis<s n="n"/><s n="m"/></r>
</p>
</e>
<e r="LR">
<p>
<l>floor<s n="n"/></l>
<r>pis<s n="n"/><s n="m"/></r>
</p>
</e>
<e r="RL">
<p>
<l>floor<s n="n"/></l>
<r>terra<s n="n"/><s n="m"/></r>
</p>
</e>
3.4.2.2. Preprocesamiento con módulo de selección léxica
En el caso de que el sistema Apertium funcione con un módulo de
selección léxica, el diccionario bilingüe se tiene que preprocessar para obtener:
un diccionario monolingüe que para cada palabra en lengua origen
(por ejemplo look) devuelva todas las posibles marcas de traducción
o equivalencias (look mirar D y look semblar), este diccionario será utilizado por el módulo que hace la selección léxica; y
un nuevo diccionario bilingüe que dada una palabra con la selección
léxica ya hecha (por ejemplo look semblar) devuelva la traducción (parèixer); este será el diccionario bilingüe a emplear en la transferencia lèxica.
Este preprocesamiento se hace automáticamente con el siguiente software en compilar los diccionarios:
apertium-gen-lextormono, que recibe tres parámetros:
• el sentido de traducción para el cual se quiere obtener el diccionario monolingüe usado en la selección lèxica; lr (left to rigth)
para la traducción de izquierda a derecha, y rl (right to left) para
la traducción de derecha a izquierda;
3.4. MÓDULO DE SELECCIÓN LÉXICA
73
• el diccionario bilingüe a preprocesar; y
• el fichero donde se tiene que escribir el diccionario monolingüe
resultante.
apertium-gen-lextorbil, que recibe tres parámetros:
• el sentido de traducción (lr o rl) para el que se quiere obtener
el diccionario bilingüe a usar por el módulo de transferencia
léxica;
• el diccionario bilingüe a preprocesar; y
• el fichero donde se tiene que escribir el diccionario bilingüe resultante.
3.4.3. Funcionamiento del módulo de selección léxica
El módulo encargado de la selección léxica se ejecuta después del desambiguador léxico categorial y antes de la transferencia estructural (véase la
figura 3.30 de la página 70); por lo tanto hace uso únicamente de información de la lengua origen de la traducción. Sin embargo, para el entrenamiento del módulo también se hace uso de información de la lengua
meta.
3.4.3.1. Entrenamiento
Para el entrenamiento del módulo que realiza la selección léxica se necesitan un corpus en lengua origen y otro en lengua meta; no es necesario
que estén relacionados. Los dos corpus tienen que ser preprocesados antes del entrenamiento. Este preprocesamiento, que consiste en analizar los
corpus y hacer la desambiguación léxica categorial, se puede hacer con
apertium-preprocess-corpus-lextor.
El entrenamiento del módulo encargado de la selección léxica consiste
en hacer las siguientes tareas:8
1. obtener la lista de palabras que no tendrán que ser tenidas en cuenta a la hora de hacer la selección lèxica (stopwords). Esta lista puede
hacerse a mano o mediante apertium-gen-stopwords-lextor;
8
El entrenamiento de los modelos usados para la selección léxica se ha automatizado
en aquellos paquetes lingüı́sticos que lo usan. Además todo el software mencionado tiene
su página de manual UNIX
74
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
2. obtener la lista de palabras (en lengua origen) que tienen más de una
traducción en lengua meta con apertium-gen-wlist-lextor;
3. traducir a la lengua meta cada una de las palabras obtenidas en el paso anterior con apertium-gen-wlist-lextor-translation;
4. entrenar con apertium-lextor --trainwrd y usando el corpus
preprocesado de la lengua meta un modelo de coaparición de palabras para las obtenidas en el paso anterior;
5. entrenar con apertium-lextor --trainlch y usando el corpus
preprocesado de la lengua origen, los diccionarios generados con los
programas mencionados en la sección 3.4.2 y los modelos de coaparición de palabras estimados en el paso anterior, un modelo de coaparición para cada una de las marcas de traducción de aquellas palabras que pueden tener más de una traducción en lengua meta.
3.4.3.2. Utilización
Los modelos de coaparición de palabras estimados en la sección anterior para cada una de las marcas de traducción proporcionan la información necesaria para llevar a cabo la selección léxica con información del
contexto.
La selección léxica se hace con apertium-lextor --lextor; los
formatos usados para la comunicación con el resto de módulos del motor de traducción son:
Entrada: texto en el mismo formato que el de entrada al módulo de transferencia estructural, es decir, texto analizado y desambiguado con
las colas invariantes de las multipalabras desplazadas antes de cualquier etiqueta.
Salida: texto en el mismo formato pero con la marca de traducción a emplear cuando se haga la transferencia léxica.
El siguiente ejemplo ilustra los formatos de entrada/salida usados por
el selector léxico (suponemos que únicamente el verbo inglés get tiene más
de un equivalente de traducción en los diccionarios):
Texto en lengua origen (inglés): To get to the city centre
Entrada al selector léxico: ˆTo<pr>$ ˆget<vblex><inf>$ ˆto<pr>$
ˆthe<det><def><sp>$ ˆcity<n><sg>$ ˆcentre<n><sg>$
3.4. MÓDULO DE SELECCIÓN LÉXICA
75
Marcas de traducción en el diccionario bilingüe para el verbo get:
rebre, agafar, arribar, aconseguir D
Salida del selector léxico: ˆTo<pr>$ ˆget__arribar<vblex><inf>$
ˆto<pr>$ ˆthe<det><def><sp>$ ˆcity<n><sg>$ ˆcentre<n><sg>$
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
76
3.5.
Módulo de transferencia estructural
[Nota: Faena per fer (mlf):
El document no diu encara res de metaparadigmes. En cal una
descripció.
Caldria demanar comentaris a Marta Villegas com a usuària del
document perquè ens indique parts fosques, possibles suggeriments, etc.
Hi ha bastants vacil·lacions en la terminologia usada per a referirse a conceptes i en els noms usats per als programes.
He intentat substituir en cada cas l’expressió per defecte per
una altra més adequada; però caldrà distingir en quin cas ens
trobem en cada cas.
]
3.5.1.
Introducción
A partir de 2007, Apertium dispone de un sistema de transferencia estructural más avanzado que el que utilizaba anteriormente, cuya necesidad aparece con el desarrollo de traductores para pares de lenguas menos
emparentadas entre sı́ que los que se habı́an tratado hasta el momento,
como por ejemplo el par inglés–catalán.
Este sistema de transferencia se compone de tres módulos, el primero de los cuales puede utilitzarse aisladamente cuando se desee ejecutar
un sistema de transferencia sintática superficial, es decir, el sistema de
transferencia utilizado ya para pares de lenguas emparentadas como español–catalán o español–gallego. Cuando el sistema se utiliza para pares de
lenguas más alejadas y se desee, por lo tanto, realizar una transferencia
sintáctica avanzada, se ejecutarán los tres módulos de transferencia.
Los dos sistemas de transferencia se diferencian por el número de pasadas que se realizan sobre el texto de entrada. El sistema de transferencia
superficial realiza las transformaciones estructurales en una única pasada
de las reglas, las cuales detectan secuencias o patrones de formas léxicas
y realizan sobre ellas las comprobacions y cambios pertinentes. Por otro
lado, el sistema de transferencia avanzado funciona con una nueva arquitectura de transferencia que permite detectar patrones de patrones de formas
léxicas mediante tres pasadas, que realizan sus tres módulos.
A continuación se describen sus caracterı́sticas. En el apartado 3.5.2 se
describe el sistema de transferencia superficial y en el apartado 3.5.3, el
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
77
sistema de transferencia avanzada. La descripción del sistema de transferencia superficial es aplicable también al funcionamiento del primero
módulo del sistema de transferencia avanzada, con las diferencias que se
exponen en el apartado correspondiente. En el apartado 3.5.4 se describe
el formato utilizado para crear reglas en ambos sistemas. En el apartado
3.5.5 se describe en detalle el funcionamiento de los tres módulos del sistema de transferencia avanzada y finalmente, en el apartado 3.5.6 se explica
el preprocesamiento de los módulos para su ejecución.
3.5.2.
Transferencia sintáctica superficial
Este sistema utiliza únicamente el primero de los tres módulos de los
que se compone el sistema de transferencia avanzada. Este módulo lo hemos denominado chunker.
El diseño del lenguaje y del compilador que se usan para generar el
módulo encargado de la transferencia estructural está fuertemente inspirado en el lenguaje MorphTrans descrito en [5] y usado por los sistemas
de TA español–catalán interNOSTRUM [2, 5, 4] y español–portugués Traductor Universia [7, 17], desarrollados por el grupo Transducens de la Universitat d’Alacant.
La tarea de transferencia se realiza a partir de patrones que representan secuencias de longitud fija de formas léxicas (véase página 7) de la
lengua origen (FLLO); una secuencia sigue un cierto patrón cuando contiene la secuencia de categorı́as léxicas correspondiente. Los patrones no
tienen por qué ser constituyentes o sintagmas en un sentido sintáctico estricto, sino que son meras concatenaciones de formas léxicas que pueden
necesitar un procesamiento conjunto adicional a la simple traducción palabra por palabra, debido a las divergencias gramaticales existentes entre
la LO y la LM (cambios de género y número, reordenamientos, cambios
preposicionales, etc). Los patrones que forman el conjunto definido para
una lengua determinada se escogen de manera que definan las transformaciones estructurales más comunes. Cuando las lenguas origen y meta
son sintácticamente similares, como es el caso del español, el catalán y el
gallego, reglas simples basadas en secuencias de categorı́as léxicas permiten obtener una calidad razonable en la traducción.
El módulo de transferencia detecta en la LO secuencias de formas léxicas que concuerden con algun patrón de los previamente definidos en un
catálogo de patrones y los procesa aplicando unas reglas de transferencia
estructural al mismo tiempo que realiza la transferencia léxica consultando el diccionario bilingüe.
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
78
La detección de patrones funciona como sigue: si el módulo de transferencia empieza a procesar la iésima FLLO del texto, li , éste intenta comparar la secuencia de FLLO li , li+1 , . . . con todos los patrones que hay en su
catálogo: escoge el patrón más largo que coincida, procesa la secuencia detectada (mirar más abajo), y el proceso continúa en la FLLO li+k , donde k
es la longitud del patrón que se acaba de procesar. Si ningún patrón coincide con la secuencia que empieza con la FLLO li , ésta se traduce como una
palabra aislada y el proceso comienza de nuevo con la FLLO li+1 (es decir,
cuando ningún patrón es aplicable, el sistema recurre a la traducción palabra por palabra). Nótese que cada FLLO es procesada una sola vez: los
patrones no se solapan; por tanto, el procesamiento se realiza de izquierda
a derecha y en fragmentos bien definidos.
Para el procesamiento de patrones, el sistema toma la secuencia de FLLO
detectada y construye (utilizando un programa para la consulta del diccionario bilingüe) una secuencia de formas léxicas en la lengua meta (FLLM)
obtenidas por aplicación de las operaciones descritas en la regla que afecta al patrón (reordenación, adición, sustitución o eliminación de palabras,
cambios en la flexión, etc.). La información que no cambia se copia automáticamente de la lengua origen a la lengua meta. Los datos resultantes,
es decir, los lemas más todas las etiquetas morfológicas correspondientes,
se envı́an al generador, el cual se encarga de crear las formas flexionadas.
Como ejemplo, la secuencia en español una señal inequı́voca, que llegarı́a desde el desambiguador al módulo de transferencia en el siguiente
formato 9 :
ˆuno<det><ind><f><sg>$
ˆseñal<n><f><sg>$
ˆinequı́voco<adj><f><sg>$
serı́a detectado como patrón por una regla para determinante–nombre–
adjetivo. El módulo de transferencia consultarı́a el diccionario bilingüe para establecer las correspondencias en catalán y, como detectarı́a un cambio
de género en la palabra señal (su equivalente catalán señal es masculino),
propagarı́a este cambio al determinante y al adjetivo para ofrecer la secuencia de salida:
9
El ejemplo se ha elegido de manera que no tenga superblancos con información de
formato, para que quede más clara la parte lingüı́stica de la transformación. Véase el
capı́tulo 2
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
79
ˆun<det><ind><m><sg>$
ˆsenyal<n><m><sg>$
ˆinequı́voc<adj><m><sg>$
que el módulo de generación convertirı́a en la forma catalana flexionada:
un senyal inequı́voc.
La mayorı́a de reglas se encargan de garantizar la concordancia de
género y número en varios sintagmas nominales (SN) sencillos (determinante–nombre, determinante–nombre–adjetivo, determinante–adjetivo–
nombre, determinante–adjetivo, etc.), siempre que haya concordancia entre las FLLO del patrón detectado. Estas reglas son necesarias bien porque
el nombre cambia de género o número entre la LO y la LM (como en el
ejemplo que acabamos de describir) o bien porque hay que determinar el
género o el número en la LM debido a que en la LO era ambiguo para alguna de las palabras (por ejemplo, el determinante cap en catalán se puede
traducir al español por ningún (masc.) o ninguna (fem.) según el nombre al
que acompañe: cap cotxe (ca) → ningún coche (es) y cap casa (ca) → ninguna
casa (es)). Además, hay definidas otras reglas para solucionar problemas
frecuentes de transferencia entre el español, el catalán y el gallego, como,
entre otras:
reglas para cambiar preposiciones en determinadas construcciones:
en Barcelona (es) → a Barcelona (ca); consiste en hacer (es) → consisteix
a fer (ca);
reglas para añadir/quitar la preposición a en determinadas construcciones modales del gallego con ir y vir: vai comprar (gl) → va a comprar (es);
reglas para los artı́culos delante de nombres propios: ve la Marta (ca)
→ viene Marta (es);
reglas léxicas, por ejemplo, para decidir la traducción correcta del
adverbio molt (ca) al español (muy, mucho) o la del adjetivo primeiro
(gl) o primer (ca) al español (primer, primero);
reglas para reposicionar los pronombres átonos o clı́ticos, cuya distribución en gallego es diferente que en español (proclı́tico en gallego y
enclı́tico en español o viceversa): envioume (gl) → me envió (es); para
nos dicir (gl) → para decirnos (es).
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
80
Las multipalabras (sus diferentes tipos están explicados en la página 44)
son procesadas de una manera especial en este módulo:
Las multipalabras sin flexión, formadas por una sola forma léxica, no
necesitan ningún procesamiento especı́fico, ya que son tratadas como las demás FL.
Cuando se trata de multipalabras compuestas, es decir, multipalabras
formadas por varias formas léxicas, cada una con un sı́mbolo gramatical propio y unidas mediante el elemento <j> en la entrada del diccionario (que se corresponde con el sı́mbolo ’+’ en el flujo de datos),
el módulo auxiliar pretransfer (véase 3.3), situado antes del presente módulo, separa las distintas formas léxicas para que lleguen
aquı́ como FL independientes. Si se desea volver a unirlas para que
lleguen al generador como multipalabras (como es el caso de los pronombres enclı́ticos en nuestro sistema), hay que hacerlo mediante
una regla de transferencia, utilizando el elemento <mlu> (descrito
más adelante, en el apartado 3.5.4.42). En la página 156 puede verse un ejemplo de regla para la unión de los pronombres enclı́ticos al
verbo.
En el caso de las multipalabras con flexión intercalada, el módulo pretransfer adelanta la cola del lema (la parte invariable) y la coloca
detrás de la cabeza del lema (la forma que se flexiona), para que sea
posible buscar la multipalabra en el diccionario bilingüe. Este tipo de
multipalabras deben procesarse mediante una regla de transferencia
estructural, que recoloque la cola del lema en la posición adecuada.
Esto se realiza utilizando los atributos lemh (lemma head o “cabeza del lema” y lemq (lemma queue o “cola del lema”) del elemento
<clip> a la salida de la regla. Véase la página 105 para obtener una
explicación más detallada del uso de este elemento, y la página 156
para ver dos reglas en que se utilizan estos atributos.
3.5.3.
Transferencia sintáctica avanzada
La arquitectura de transferencia superficial descrita en el apartado anterior se basa, como hemos visto, en la manipulación automática de determinados patrones de aparición de palabras mediante reglas definidas por
el usuario. Este modelo considera dos niveles desde el punto de vista de
la naturaleza de los datos: un nivel básico que denominamos nivel léxico,
que se ocupa de las palabras y de las operaciones de consulta y modificación de sus caracterı́sticas (lema y etiquetas), además de la traducción de
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
81
lemas individuales mediante consultas al diccionario bilingüe; y otro nivel
que denominamos nivel de patrones de palabras, que se encarga de realizar,
cuando conviene, reordenamientos con las palabras que constituyen estos
patrones, ası́ como cambios en las caracterı́sticas de las palabras que dependan de cada patrón concreto que haya sido detectado. Todo este procesamiento de detección y manipulación léxica y de patrones se lleva a cabo
en una única pasada.
Como contraste, la nueva arquitectura de transferencia avanzada se define como un sistema de transferencia en tres niveles y tres pasadas. Los
dos primeros niveles, el nivel léxico y el de patrones, son homólogos a los
del sistema de transferencia superficial. El nuevo nivel que aparece es un
nivel de patrones de patrones de palabras. El objetivo de la existencia de este nuevo nivel de procesamiento es permitir la manipulación y la relación
de patrones de patrones de palabras de manera similar a cómo se tratan
las palabras en los patrones de palabras del sistema superficial. Con esta nueva estructura de niveles se pretende que haya un tratamiento más
adecuado de todas las transformaciones que se requieren para traducir de
una lengua a otra. Por esto se tiene que poner de manifiesto que la identificación de patrones de palabras en el sistema de transferencia superficial
no tiene que coincidir con la identificación de patrones de palabras en el
sistema avanzado: se pretende que los patrones en este último tengan un
espı́ritu de sintagmas que no tienen en el sistema anterior. Por esta razón
utilizaremos el término segmento (en inglés chunk), para referirnos a las
secuencias de palabras del sistema de transferencia avanzada.
La arquitectura de transferencia avanzada se organiza en tres pasadas.
Siguiendo el modelo de procesamiento de Apertium, estas tres pasadas
son realizadas por tres módulos (programas) diferentes:
chunker: identifica los segmentos, realiza la traducción palabra por
palabra, ası́ como ciertas operaciones de reordenamiento y propagación de información morfosintáctica dentro del segmento (por ejemplo, para establecer la concordancia). Además, crea los segmentos
para que sean tratados por el módulo siguiente. El chunker tiene
la opción de funcionar como único módulo en un sistema de transferencia sintáctica superficial. Ello se controla mediante un atributo
del elemento <transfer>.
interchunk: este módulo recibe los segmentos construidos por el
chunker y permite reordenarlos, modificar la “información sintáctica” asociada a cada segmento y, finalmente, imprimir los segmentos
en el orden nuevo y con las caracterı́sticas nuevas en la salida, creando segmentos nuevos si es necesario.
82
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
postchunk: este módulo recibe los segmentos modificados por el
interchunk y realiza tareas finales de modificación de las palabras
contenidas en cada segmento y de impresión del texto contenido en
los segmentos en el formato que acepta el generador.
A continuación se especifica el formato de los segmentos que circulan
entre los tres módulos del sistema de transferencia (sección 3.5.3.1) y el tratamiento de mayúsculas y minúsculas en los segmentos (sección 3.5.3.2),
que difiere del que se da para las formas léxicas individuales en el caso de
un sistema de transferencia superficial.
El siguiente apartado, 3.5.4, está dedicado a la descripción del formato
de las reglas de transferencia, que es común para los tres módulos y para
los dos modos de transferencia, con algunas diferencias. Finalmente, tras
esta descripción, en 3.5.5 se describen en más detalle los tres módulos de
los que se compone un sistema de transferencia sintáctiva avanzada.
3.5.3.1. Formato de los segmentos
La comunicación entre los módulos chunker e interchunk, al igual
que la comunicación entre interchunk y postchunk, se lleva a cabo
mediante secuencias de segmentos. Definimos C como una secuenca de segmentos, que tiene la forma:
C = b0 c1 b1 c2 b2 . . . bk−1 ck bk
Donde cada bi es un superblanco, y cada c es un segmento. Un segmento
c se define como a una cadena ˆF {W }$ que contiene la siguiente información:
F es el pseudolema del segmento, y es una cadena que tiene la forma
f E, donde f es el pseudolema del segmento, y E = e1 e2 . . . es una secuencia de etiquetas morfológicas denominadas etiquetas del segmento. La modificación de estas etiquetas provocará la modificación de
la información morfológica de las palabras del segmento que esté enlazada a estos parámetros.
W = b0 w1 b1 w2 b2 . . . wk bk es la secuencia de palabras wi enviada por
el chunker con los superblancos bi intercalados. Estas palabras se encuentran en el mismo formato an ambos sistemas de transferencia, es
decir, una palabra individual wi =ˆli Ei $ contiene lema li y etiquetas
Ei , algunas de las cuales pueden ser referencias o enlaces a las etiquetas
del segmento y se designan con números naturales <1>, <2>, <3>,
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
83
etc. Estas referencias a etiquetas se corresponden, en el orden especificado, con las etiquetas de E.
Un ejemplo de uso de este formato es el siguiente:
ˆdet_nom<SN><m><pl>{ˆel<det><def><2><3>$[
<a href="http://www.ua.es">]ˆgat<n><2><3>$}$[</a>]
Los caracteres { y }, cuando estén presentes en el texto original, deberán protegerse colocando una barra invertida \ delante.
3.5.3.2.
Tratamiento de mayúsculas y minúsculas
Para cada segmento, la información de mayúsculas y minúsculas de las
palabras viene determinada por la información de mayúsculas y minúsculas del pseudolema del segmento, teniendo en cuenta estas condiciones:
Si todas las letras del pseudolema están en minúsculas: el estado de
mayúsculas y minúsculas no se modifica.
Si la primera letra del pseudolema está en mayúsculas y el resto en
minúsculas: en la generación en el módulo postchunk, se hará que
la primera letra que resulto de todos los posibles cambios de orden
de las palabras del segmento esté en mayúsculas.
Si todas las letras del pseudolema están en mayúsculas: todas las
palabras permanecerán en mayúsculas.
Un requisito es que las palabras del interior del segmento no empiecen por mayúsculas si no se trata de nombres propios, con tal de evitar
que el último módulo busque cuál es la palabra que tiene que perder la
mayúscula, si la hay. Esta tarea corresponde al módulo chunker y se hace
mediante una macro o algún mecanismo similar.
3.5.4. Especificación del formato de las reglas de transferencia estructural
En esta sección se explica el formato en el que se escriben las reglas de
transferencia estructural. En el apéndice, en las secciones A.3, A.4 i A.5 se
ofrece la descripción formal (DTD).
Los archivos de reglas de transferencia estructural tienen dos partes
bien diferenciadas: una de declaración de los elementos que se utilizarán
84
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
en las reglas y otra de reglas propiamente dichas.
En la parte de declaración encontramos:
Una serie de declaraciones de categorı́as léxicas que especifican aquellas formas léxicas que serán tratadas como una categorı́a particular
y que serán detectadas en los patrones. Hemos de destacar que el
lingüista puede incluir cualquier información de la forma léxica para
definir una categorı́a; las categorı́as pueden ser muy genéricas (p.e.
todos los nombres) o muy especı́ficas (p.e. sólo aquellos determinantes que son demostrativos femeninos plurales).
Una serie de declaraciones de los atributos que queremos detectar en
las formas léxicas (como el género, el número, la persona o el tiempo),
para realizar con ellos las operaciones de transformación pertinentes y enviar la información resultante a la salida de las reglas. En la
declaración de los atributos se incluye el nombre del atributo y los
posibles valores que puede tomar este atributo en una forma léxica
(por lo general se corresponden con los sı́mbolos morfológicos que
la caracterizan): por ejemplo, el atributo de número puede tomar los
valores de singular, plural, singular-plural (para formas léxicas invariables, como crisis en español) y número por determinar (para formas
léxicas de la LM con distinción singular–plural cuyo número no se
puede determinar en la traducción al ser la forma léxica de la LO
invariable en número, véase la explicación de la página 42). Si dentro de la regla, fuera del patrón, debe hacerse referencia a alguna de
las categorı́as léxicas definidas en el punto anterior (para someterlas
a acciones o comprobaciones), deberán definirse también atributos
para las mismas.
Una serie de declaraciones de variables globales, que se usan para
transferir valores de atributos activos dentro de cada regla o de una
regla a las que se apliquen posteriormente.
Una sección de definición de listas de cadenas, generalmente listas de
lemas, que serán utilizados para buscar en ellas un valor que corresponda para realizar una transformación determinada.
Una serie de declaraciones de macroinstrucciones; las macroinstrucciones contienen secuencias de instrucciones de operaciones frecuentes y pueden incluirse en varias reglas (por ejemplo, una macroinstrucción para asegurar la concordancia de género y número entre dos
formas léxicas de un mismo patrón).
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
85
En las reglas de transferencia estructural encontramos:
La definición del patrón que será detectado, especificado como una
secuencia de categorı́as léxicas tal como se han definido en la parte
de declaración. Cabe resaltar que, si la secuencia de formas léxicas
concuerda con dos reglas diferentes, primero, prevalece la más larga y, segundo, para reglas de la misma longitud, prevalece la regla
definida en primer lugar.
La parte de proceso de las reglas, en la que especifican las acciones a
realizar sobre las FLLO y se construye el patrón en la LM.
[Nota: Assegurem-nos que totes les sigles estan definides]
A continuación se explican detalladamente las caracterı́sticas de cada
uno de los elementos utilizados.
3.5.4.1. Elemento <transfer>
(Sólo en el módulo chunker)
Es el elemento raı́z del módulo chunker y contiene todos los demás
elementos del archivo de reglas de transferencia estructural de este módulo.
Su atributo default puede tomar dos valores:
lu: indica que funcionará en modo superficial, es decir, como único módulo de transferencia en un sistema de transferencia sintáctica
superficial y que, por lo tanto, las palabras implı́citas deben dejarse
intactas
chunk: indica que funcionará en modo avanzado y, por lo tanto,
cuando una palabra no es reconocida por ninguna regla, se creará de
oficio un segmento que encapsule esta palabra para que pueda ser
tratada por los siguientes módulos de transferencia de un sisema de
transferencia sintáctica avanzada.
El valor por defecto es lu.
3.5.4.2. Elemento <interchunk>
(Sólo en interchunk)
Es el elemento raı́z del módulo interchunk y contiene todos los demás
elementos del archivo de reglas de transferencia estructural de este módulo.
86
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
3.5.4.3. Elemento <postchunk>
(Sólo en postchunk)
Es el elemento raı́z del módulo postchunk y contiene todos los demás
elementos del archivo de reglas de transferencia estructural de este módulo.
3.5.4.4. Elemento de sección de definición de categorı́as
<section-def-cats>
[Nota: Atenció a l’ús polisèmic del mot categoria en el document]
En esta sección se definen las categorı́as léxicas que se usarán para
crear los patrones utilizados en las reglas. Cada definición se realiza con
un <def-cat>.
3.5.4.5. Elemento de definición de categorı́as <def-cat>
Cada definición de categorı́a tiene un nombre n obligatorio como por
ejemplo det, adv, prep, etc. y una lista de categorı́as (<cat-item>) que
la definen. El nombre de la categorı́a no puede contener acentos.
3.5.4.6. Elemento de categorı́a <cat-item>
Este elemento tiene dos usos marcadamente diferenciados según el
módulo en el que se utilice.
Uso en el módulo chunker (transferencia superficial y transferencia avanzada)
Mediante este elemento se definen las categorı́as léxicas que se utilizarán en los patrones, es decir, que se desea detectar en el texto origen.
Estas categorı́as se definen a partir de una subsecuencia de las etiquetas
finas (ver definición en la página 58) que entregan tanto el analizador morfológico como el desambiguador10 .
10
Hay que tener en cuenta que a lo largo de los distintos módulos de procesamiento
lingüı́stico se utilizan distintas categorizaciones léxicas: en los diccionarios morfológicos,
los lemas se acompañan de una etiqueta fina (por ejemplo, <n><m><pl> para los nombres masculinos en plural); el desambiguador categorial agrupa estas etiquetas finas en
etiquetas más generales (por ejemplo, la categorı́a NOM para todos los nombres), aunque a
su salida vuelve a entregar la etiqueta fina completa de cada FL; finalmente, en el módulo
de transferencia, las etiquetas finas de las FL se agrupan otra vez en categorı́as más ge-
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
87
Cada elemento <cat-item> tiene un atributo obligatorio tags cuyo valor es una secuencia de sı́mbolos gramaticales separados por puntos; esta secuencia es una subsecuencia de la etiqueta fina, es decir, de la
secuencia de sı́mbolos gramaticales que define cada posible forma léxica
entregada por el desambiguador léxico categorial. De este modo, una categorı́a representa un determinado conjunto de formas léxicas. Tenemos que
definir tantas categorı́as distintas como tipos de formas léxicas queramos
detectar en los patrones. Ası́, si nos interesa detectar todos los nombres para realizar operaciones con ellos, crearemos una categorı́a definida a partir
del sı́mbolo gramatical n. Por otro lado, si nos interesa detectar todos los
nombres femeninos en plural, deberemos definir una categorı́a mediante
los sı́mbolos n f y pl.
Cuando un sı́mbolo gramatical utilizado para definir una categorı́a viene seguido por otros sı́mbolos gramaticales en el grupo de lemas que se
quiere incluir, se utiliza el carácter "*". Por ejemplo, tags="n.*" abarca
todas las formas léxicas que contengan este sı́mbolo, como casa<n><f><pl>
o coche<n><m><sg>. En cambio, cuando detrás del sı́mbolo utilizado no
puede venir ningún otro sı́mbolo, no se incluye el asterisco: por ejemplo,
tags="adv" abarcará todos los adverbios, pues en nuestro sistema son
caracterizados por una única etiqueta. También puede utilizarse el asterisco para indicar la existencia de sı́mbolos precedentes: tags="*.f.*" incluye a todas las formas léxicas femeninas, sean de la categorı́a que sean.
Además, puede utilizarse un atributo opcional, lemma, para definir formas léxicas a partir de su lema (ver figura 3.31).
Uso en el módulo interchunk
Se utiliza igual que en el módulo chunker, pero aquı́, en lugar de definirse a partir de los sı́mbolos gramaticales de las formas léxicas, se define a partir de los sı́mbolos de los segmentos entregados por el módulo
chunker. Si, por ejemplo, queremos definir una categorı́a para detectar
todos los sintagmas nominales determinados, la definiremos mediante los
sı́mbolos SN y DET si ası́ hemos caracterizado el segmento o chunk mediante las instrucciones <tag> contenidas en el elemento <chunk> (véase
3.5.5.1). También se puede utilizar el atributo opcional lemma para hacer
referencia al pseudolema del segmento. Ası́ pues, sus caracterı́sticas formales son las mismas en los módulos chunker e interchunk, con la única
diferencia que en el primero se utilizan para detectar formas léxicas y en
nerales (aunque pueden definirse también categorı́as detalladas) según el tipo de formas
léxicas que se quiera detectar en los patrones.
88
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<def-cat n="nom"/>
<cat-item tags="n.*"/>
</def-cat>
<def-cat n="que"/>
<cat-item lemma="que" tags="cnjsub"/>
<cat-item lemma="que" tags="rel.an.mf.sp"/>
</def-cat>
Figura 3.31: Uso del elemento <cat-item> para definir dos categorı́as, una para
nombres sin especificar ningún lema (nom) en la que se incluyen todas las formas
léxicas cuyo primer sı́mbolo morfológico sea n, y otra con lema asociado (que),
que tiene más de un sı́mbolo gramatical asociado, para incluir el que conjunción
y el que relativo.
<def-cat n="det-nom"/>
<cat-item name="det-nom"/>
</def-cat>
Figura 3.32: Uso del elemento <cat-item> en el módulo postchunk para detectar chunks de determinante-nombre.
el segundo, para detectar segmentos o chunks.
Uso en el módulo postchunk
En este módulo, este elemento solo prevé el atributo obligatorio name,
que hace referencia al nombre del segmento o chunk,
[Nota: MG: abans deia ’al nom de la regla’, comentari mlf: De la regla
o del patró?]
sin etiquetas, ya que en el módulo postchunk sólo se usa el pseudolema
(nombre del segmento) para la detección. En la detección no se distingue
entre mayúsculas y minúsculas, porque el pseudolema se usa para transmitir la información sobre las mayúsculas y las minúsculas del segmento.
(Véase la figura 3.32).
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
3.5.4.7.
89
Elemento de sección de definición de atributos de categorı́a
<section-def-attrs>
En esta sección se definen los atributos que se extraerán de las categorı́as detectadas por el patrón y que se utilizarán en la parte de acción de
las reglas. Cada atributo se define mediante una etiqueta <def-attr>.
[Nota: De vegades les etiquetes aprareixen en el text en negretes i
de vegades sense negretes. Decidim-nos per una tipografia i usem-la
en tot el document.]
3.5.4.8.
Elemento de definición de atributos de categorı́a
<def-attr>
Cada <def-attr> define un atributo con información morfológica
(tanto información flexiva –género, número, persona, etc.–, como categorial –verbo, adjetivo, etc–) mediante una lista de elementos de atributo
de categorı́a (<attr-item>) y tiene un nombre único obligatorio n. Un
atributo se define, por lo tanto, a partir de los sı́mbolos morfológicos que
pueden encontrarse en una forma léxica dada. Cada atributo extrae, de las
formas léxicas del patrón, los sı́mbolos que éstas contienen de entre los
posibles valores dados.
3.5.4.9.
Elemento de atributo de categorı́a <attr-item>
Cada elemento de atributo de categorı́a representa uno de los valores
posibles que puede tomar el atributo. Por ejemplo, el atributo de número
nbr puede tomar los valores singular sg, plural pl, singular–plural sp
y número por determinar ND. Estos valores son una subsecuencia de las
etiquetas morfológicas que caracterizan a las formas léxicas y se indican
en el atributo tags del elemento, separadas por punto si hay más de una.
En la figura 3.33 puede verse un ejemplo de utilización de este elemento
para el atributo de número y el atributo de nombre.
[Nota: Potser s’hauria d’explicar per què s’ha triat el nom a nom en
la figura]
Compárese la definición del atributo de nombre en esta figura (con todos los valores posibles y sin asteriscos) con la definición de la categorı́a
de nombre de la figura 3.31.
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
90
<def-attr n="nbr"/>
<attr-item tags="sg"/>
<attr-item tags="pl"/>
<attr-item tags="sp"/>
<attr-item tags="ND"/>
</def-attr>
<def-attr n="a_nom"/>
<attr-item tags="n"/>
<attr-item tags="n.acr"/>
</def-attr>
Figura 3.33: Definición del atributo de categorı́a número nbr, que puede tomar
los valores singular, plural, singular-plural o número por determinar, ası́ como del
atributo de categorı́a nombre a nom, que puede tomar los valores de los sı́mbolos
n o n acr.
3.5.4.10.
Elemento de sección de definición de variables
<section-def-vars>
En esta sección se definen (mediante etiquetas <def-var>) las variables globales de tipo cadena que se utilizarán para transferir información
dentro de una regla y de una regla a otra (por ejemplo, para poder transmitir información de género o número entre dos patrones).
[Nota: Que quede clar que aquesta transferència d’una regla a altra
es fa només d’una aplicació d’una regla a l’aplicació d’altra regla en
un moment posterior, o d’esquerra a dreta]
3.5.4.11.
Elemento de definición de variables <def-var>
La definición de una variable global de tipo cadena tiene un nombre
único obligatorio n que se utilizará para referirse a la misma dentro de las
reglas. Las variables contienen cadenas que describen información de estado, como la existencia de concordancia entre dos elementos, la detección
de un signo de interrogación en la LO que haya que eliminar en LM, etc.
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
91
<def-list n="verbos_est">
<list-item v="actuar"/>
<list-item v="buscar"/>
<list-item v="estudiar"/>
<list-item v="existir"/>
<list-item v="ingressar"/>
<list-item v="introduir"/>
<list-item v="penetrar"/>
<list-item v="publicar"/>
<list-item v="treballar"/>
<list-item v="viure"/>
</def-list>
Figura 3.34: Definición de una lista de lemas en catalán. Estos lemas se utilizan
en una regla que puede verse en la figura 3.39.
3.5.4.12. Elemento de sección de definición de listas de cadenas
<section-def-lists>
En esta sección se definen (mediante etiquetas <def-list>) las listas que se utilizarán para realizar búsquedas de cadenas. Estas listas se
pueden utilizar para agrupar lemas de palabras que tengan alguna caracterı́stica común (por ejemplo, verbos que expresen movimiento, adjetivos
que expresen estados de ánimo, etc.). Esta sección es opcional.
3.5.4.13.
Elemento de definición de listas de cadenas <def-list>
Este elemento sirve para ponerle nombre a la lista de cadenas mediante
el atributo n y para encapsular la lista que se define mediante uno o más
elementos <list-item>. Puede verse un ejemplo de uso en la figura 3.34.
3.5.4.14.
Elemento de miembro de lista de cadenas <list-item>
Este elemento define, mediante el valor del atributo v, la cadena concreta que se incluye en la definición de la lista que engloba a este elemento.
Puede verse un ejemplo de uso en la figura 3.34.
3.5.4.15.
Elemento de sección de definición de macroinstrucciones
<section-def-macros>
En esta sección se definen las macroinstrucciones que contienen fragmentos de código utilizado con frecuencia en la parte de acción de las
92
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
reglas.
3.5.4.16. Elemento de definición de macroinstrucciones
<def-macro>
Cada definición de una macroinstrucción tiene un nombre obligatorio
(el valor del atributo n), el número de argumentos que se le pasan como
referencia (atributo npar) y un cuerpo con instrucciones.
3.5.4.17. Elemento de sección de reglas <section-rules>
Esta sección contiene las reglas de transferencia estructural, cada una
en un elemento <rule>.
3.5.4.18. Elemento de regla <rule>
Cada regla tiene un patrón (<pattern>) y la acción (<action>) asociada que se ejecuta cuando es detectado.
La regla puede especificar en un atributo opcional comment un comentario que explique cuál es la función de la regla.
3.5.4.19. Elemento de patrón <pattern>
Un patrón se especifica utilizando componentes de patrón (<patternitem>), cada uno de los cuales corresponde a una forma léxica en el patrón
detectado, en orden de aparición.
3.5.4.20. Elemento de componente de patrón <pattern-item>
En cada componente de un patrón se indica, mediante un atributo de
nombre obligatorio n, qué tipo de forma léxica se quiere detectar. Para
ello se utiliza una de las categorı́as definidas en <section-def-cats>
(véase un ejemplo de cómo se detecta el patrón determinante–nombre en
la figura 3.41).
3.5.4.21. Elemento de acción <action>
En este elemento se incluyen las “instrucciones” que se tienen que ejecutar para llevar a cabo el procesamiento que se desee para cada detección
de patrones.
La parte de procesamiento del patron detectado es un bloque de cero o
más instrucciones de tipo: <choose> (procesamiento condicional), <let>
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
93
(asignación de valores), <out> (escritura de formas léxicas de la LM),
<modify-case> (modificación del estado de las mayúsculas y minúsculas de una forma léxica), <call-macro> (llamadas a macroinstrucciones)
y <append> (concatenación de cadenas).
Durante el procesamiento, según se cumplan o no una serie de opciones condicionales, se realizan distintas operaciones, como por ejemplo la
concordancia de los elementos de un patrón, ya que éstos están sujetos a
posibles cambios de género o número durante el proceso de transferencia
léxica. Para ello, a pesar de trabajar con FL en LM también se tiene en cuenta la información de la LO ya que si, por ejemplo, en LO los elementos de
un patrón no concuerdan, tal vez tampoco deben hacerlo en LM. Durante
la aplicación de las distintas operaciones realizadas dentro un patrón, se
asignan valores a atributos del patrón y, en su caso, a variables globales
o de estado y se envı́a la información del patrón en LM resultante al siguiente módulo (el generador morfológico en un sistema de transferencia
sintáctica superficial, o bien un módulo posterior de transferencia en un
sistema de transferencia sintáctica avanzada).
3.5.4.22. Elemento de llamada a macroinstrucción
<call-macro>
Dentro de una regla puede invocarse cualquiera de las macroinstrucciones definidas en <section-def-macros>. Para ello, hay que especificar el nombre de la macroinstrucción en el atributo n y uno o más argumentos en el elemento de parámetros <with-param> (ver a continuación).
3.5.4.23.
Elemento de parámetros <with-param>
Este elemento se utiliza dentro de las llamadas a macroinstrucciones
<call-macro>. El atributo pos de cada argumento se utiliza para referirse a una forma léxica de la regla que invoca la macroinstrucción. Por
ejemplo, si se ha definido una macroinstrucción de 2 parámetros que realiza operaciones de concordancia nombre–adjetivo, puede utilizarse con los
argumentos 1 y 2 en una regla de nombre–adjetivo, con los argumentos 2
y 3 en una regla de determinante–nombre–adjetivo, con los argumentos 1
y 3 en una regla de nombre–adverbio–adjetivo y con los argumentos 2 y 1
en una regla de adjetivo–nombre. Véase un ejemplo de llamada a macroinstrucción en la figura 3.35.
94
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<call-macro n="f_concord2">
<with-param pos="3"/>
<with-param pos="1"/>
</call-macro>
Figura 3.35: Llamada a la macroinstrución f-concord2 para hacer concordar
los elementos de un patrón como por ejemplo determinante–adverbio–nombre.
La propagación de género y número se hace a partir de uno de los elementos,
en este caso el nombre que aparece como tercer elemento del patrón (3). Por eso,
la posición del nombre se pasa como primer parámetro y después se pasan el
resto de elementos. Como el adverbio (en posición 2) no necesita información de
concordancia, sólo se pasa la posición del determinante (1).
3.5.4.24. Elemento de selección <choose>
La instrucción de selección se compone de una o más opciones condicionales (<when>) y una opción alternativa <otherwise>, de inclusión
opcional.
3.5.4.25. Elemento de condición <when>
Con este elemento se describe una opción condicional (véase la página
94). Se compone de la condición a verificar <test> y de un bloque de cero
o más instrucciones de tipo <choose>, <let>, <out>, <modify-case>,
<call-macro> o <append>,
[Nota: OK append?]
que se ejecutarán si se cumple la citada condición.
3.5.4.26. Elemento de opción alternativa <otherwise>
El elemento <otherwise> contiene un bloque de una o más instrucciones (de tipo <choose>, <let>, <out>, <modify-case>, <call-macro>
y <append>) que deben realizarse si no se cumple la condición descrita en
ninguno de los <when> de un <choose>.
3.5.4.27. Elemento de evaluación <test>
El elemento de evaluación <test> dentro de un elemento de condición <when> puede estar compuesto por una conjunción (<and>), una disyunción (<or>) o una negación (<not>) de condiciones a evaluar, ası́ como por una simple condición de igualdad de cadenas (<equal>), de prin-
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
95
cipio de cadena (<begins-with>), de final de cadena (<ends-with>),
de subcadena (<contains-substring>) o de inclusión en conjunto (<in>).
[Nota: Segur que es pot millorar la redacció de l’últim paràgraf, canviat per mlf perquè hi estiguen totes les condicions booleanes simples.]
3.5.4.28.
Elementos de operadores condicionales o booleanos: <equal>,
<and>, <or>, <not>, <in>
[Nota: Cal completar-ho: falten contains-substring, ends-with,
begins-with, etc.]
El elemento de conjunción <and> representa una condición, compuesta de dos o más condiciones, que se cumple cuando todas las
condiciones en él incluidas son ciertas. Se puede ver un ejemplo de
su uso en la figura 3.41
El elemento de disyunción <or> representa una condición, compuesta de dos o más condiciones, que se cumple cuando al menos una de
ellas es cierta. En la figura 3.38 hay un ejemplo de este tipo de condición para evaluar la concordancia de género de un patrón en LO.
El elemento de negación <not> representa una condición que se
cumple cuando la condición incluida no se cumple y viceversa. Se
puede ver un ejemplo de negación de una igualdad en la figura 3.38.
El operador condicional de igualdad <equal> es una instrucción
que comprueba si dos argumentos (dos cadenas) son o no idénticos. Véase un ejemplo del uso de este elemento en las figuras 3.36
y 3.37. En este operador, además, se puede especificar el atributo
caseless, el cual, si tiene el valor yes, hace que la comparación entre cadenas se realice sin tener en cuenta las diferencias de mayúsculas y minúsculas.
[Nota: Totes les comprovacions condicionals de cadenes tenen
l’atribut caseless; in també; més avall]
El operador de búsqueda en listas, <in> sirve para buscar cualquier
valor (que corresponde al primer parámetro de la condición) en una
lista a la que se hace referencia mediante el atributo n del elemento <list> y que debe estar definida en la sección correspondiente
(<section-
96
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
def-lists). El resultado de la búsqueda es cierto si el valor se encuentra en la lista. En esta comparación se puede utilizar también el
atributo caseless: si se le asigna el valor yes, se realiza la búsqueda en la lista sin tener en cuenta las diferencias de mayúsculas y
minúsculas. En la figura 3.39 puede verse un ejemplo de su uso.
[Nota: Cal unificar tota la discussió anterior, traient factor comú.]
[Nota: Cal descriure la resta d’elements condicionals que no hi són.]
3.5.4.29. Elemento <clip>
El elemento <clip> representa una subcadena de una forma léxica
de la LO o de la LM, definida por el valor de varios atributos (véase un
ejemplo de uso en la figura 3.36):
pos es un ı́ndice (1, 2, 3, etc.) utilizado para seleccionar una forma
léxica dentro de la regla: se corresponde con el lugar que ocupa la
forma léxica en el patrón. En el módulo postchunk, també existe el
ı́ndice “0”, que hace referencia al pseudolema del chunk, el cual es
tratado como una palabra más para poder acceder a su información
y tomar decisiones a partir de ella.
side (sólo en módulo chunker) especifica si se selecciona un clip de
la lengua de origen (sl, por source language) o de la lengua de destino
(tl, por target language).
part indica qué parte de la forma léxica se procesa; generalmente
su valor es uno de los atributos definidos en <section-defattrs> (gen, nbr, etc.), aunque también puede tomar cuatro valores predefinidos que son: lem (para hacer referencia al lema de la
forma léxica), lemh (para hacer referencia a la primera parte de un
lema partido), lemq (la cola del lema partido), y whole (la forma
léxica completa, con el lema y todos los sı́mbolos gramaticales, que
pueden haber sido modificados en la parte precedente de la regla).
link-to (sólo en chunker en modo avanzado) sustituye el valor que
se derivarı́a de la consulta del resto de atributos del clip por el valor
especificado en este atributo, que ha de ser un número natural (> 0).
Este número indica con qué etiqueta <tag> del <chunk> se enlaza el
contenido del clip, siendo el número el orden que ocupa esta etiqueta
dentro de <tags>. El resto de atributos del clip quedan únicamente
como información, pues son sobrescritos por el valor de la etiqueta
enlazada. Puede verse un ejemplo de su uso en la figura 3.45.
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
97
<test>
<not>
<equal>
<clip pos="2" side="tl" part="gen"/>
<clip pos="2" side="sl" part="gen"/>
</equal>
</not>
</test>
Figura 3.36: Fragmento de una regla en la que se comprueba si el género (gen)
en LM (tl) de la segunda unidad léxica identificada en un patrón es distinto del
género de la misma unidad léxica en LO (sl)
<equal>
<clip pos="2" side="tl" part="nbr"/>
<lit-tag v="ND"/>
</equal>
Figura 3.37: Uso del elemento <lit-tag>: se comprueba si la etiqueta (o sı́mbolo) de número (nbr) de la segunda unidad léxica de la LM (tl) es ND (número
por determinar)
3.5.4.30.
Elemento de cadena literal <lit>
Este elemento sirve para especificar el valor de una cadena literal mediante el atributo v. Por ejemplo, <lit v="andar"/> representa la cadena andar.
3.5.4.31.
Elemento de valor de etiqueta <lit-tag>
Es similar al elemento <lit> pero no especifica el valor de una cadena
literal sino el de una etiqueta morfológica, mediante el atributo v. Véase
un ejemplo de su uso en la figura 3.37.
3.5.4.32.
Elemento de variable <var>
Cada <var> es un identificador de variable: el atributo obligatorio
n indica su nombre tal como se ha definido en <section-def-vars>.
Cuando se encuentra en un <out>, un <test>, o la parte derecha de un
<let>, representa el valor de la variable; cuando se encuentra en la parte
izquierda de un <let>, dentro de un <append> o en un <modify-case>,
98
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<test>
<or>
<not>
<equal>
<clip pos="1"
<clip pos="3"
</equal>
</not>
<not>
<equal>
<clip pos="2"
<clip pos="3"
</equal>
</not>
</or>
</test>
side="sl" part="gen"/>
side="sl" part="gen"/>
side="sl" part="gen"/>
side="sl" part="gen"/>
Figura 3.38: Fragmento de una regla en la que se comprueba si el género en LO
de la primera o de la segunda unidad léxica identificada en un patrón (podrı́a ser
determinante–adjetivo–nombre) es distinto del género de la tercera unidad léxica
también en LO.
representa la referencia de la variable y se puede cambiar su valor.
3.5.4.33. Elemento de referencia a lista de cadenas <list>
Este elemento sólo se usa como segundo parámetro de una búsqueda
<in>. El atributo n hace referencia a la lista concreta definida en la sección de definición de listas de cadenas <section-def-lists>. Véase
un ejemplo de uso en la figura 3.39.
3.5.4.34. Elemento de información de mayúsculas/minúsculas
<get-case-from>
El elemento <get-case-from> representa la cadena resultante de
aplicar el esquema de mayúsculas que presenta el lema de una unidad
léxica en LO a una cadena (clip, lit o var). Para hacer referencia a la unidad léxica de la que se tomará la información, se utiliza el atributo pos
que indica la posición de dicha unidad léxica en LO. Se utiliza cuando se
reordenan las unidades léxicas de un patrón o cuando se añade o se suprime una unidad léxica. Puede verse un ejemplo de uso en la figura 3.40,
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
99
<rule>
<pattern>
<pattern-item n="verb"/>
<pattern-item n="a"/>
</pattern>
<action>
<choose>
<when>
<test>
<in caseless="yes"/>
<clip pos="1" side="sl" part="lem"/>
<list n="verbos_est"/>
</in>
</test>
<let>
<clip pos="2" side="tl" part="lem"/>
<lit v="en"/>
</let>
</when>
<!-- ... -->
Figura 3.39: Fragmento de una regla que detecta un patrón formado por un verbo
más la preposición a y a continuación comprueba si el verbo (el lema indicado en
lem) de la lengua origen (sl) es uno de los que se han incluido en la lista de
verbos de estado (definida en la figura 3.34). En caso afirmativo, el lema de la
segunda palabra de la lengua meta (tl) se cambia por en.
100
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
que contiene una regla para transformar el pretérito perfecto simple español (dije) por el pretérito perfecto perifrástico catalán (vaig dir). En esta
regla se añade una FL con lema anar y sı́mbolo morfológico vaux (”verbo
auxiliar”), el cual debe tomar la información de mayúsculas del verbo en
español (que tiene la posición ”1.en el patrón), para que se traduzca Dije
por Vaig dir, dije por vaig dir y DIJE por VAIG DIR.
3.5.4.35. Elemento de obtención del patrón de mayúsculas/minúsculas
<case-of>
Sirve para obtener el patrón de mayúsculas/minúsculas, es decir, uno
de los valores ”aa”, ”Aa" o ”AA”, de una cadena, que se obtiene como
en el caso de la etiqueta <clip>, pues tiene los mismos atributos: pos,
la posición que ocupa la palabra en el patrón detectado; part, el atributo
concreto al que se hace referencia (normalmente el lema), con los atributos predefinidos que ya se mencionan en la página 96, y, sólo en el caso
del módulo chunker, el atributo side, el lado de la traducción, sl para la LO y tl para la LM. En la figura 3.40 puede verse un ejemplo de
utilización de este elemento, y en el apartado siguiente (la explicación de
<modify-case>) se encuentra una explicación más detallada del ejemplo.
3.5.4.36. Elemento de modificación de estado de
mayúsculas/minúsculas <modify-case>
Esta instrucción sirve para modificar las mayúsculas o minúsculas de
la primera expresión (el primer parámetro, tı́picamente un lema) mediante un literal o una variable (el segundo parámetro). El primer parámetro
puede ser una <var>, un <clip> o un <case-of>, mientras que el segundo puede ser cualquier cosa que devuelva un valor, pero en principio será <var> o <lit>. Los valores que puede tomar este valor suelen
ser “Aa” para expresar que la “parte izquierda” de esta modificación de
las mayúsculas debe tener la primera letra en mayúsculas y el resto en
minúsculas, “aa” para poner todo en minúsculas y “AA” para poner todo
en mayúsculas.
En la figura 3.40 puede verse un ejemplo de su utilización. En esta regla
se modifica el estado de mayúsculas del lema en LM en posición ”1”, que
corresponde a dir, puesto que, aunque a la salida de la regla sea la segunda
forma léxica (vaig dir), es la traducción de la FL que tiene la posición 1 en la
LO, y por lo tanto sigue teniendo asignada esta posición en la LM. A este
lema se le asigna el valor “aa” en caso de que el lema en LO tenga el estado
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
101
“Aa”. En los demás casos no hay que especificar nada, pues el estado de
mayúsculas/minúsculas en la FL con posición 1 coincidirá en la LO y en
la LM y, por lo tanto, se transfiere automáticamente (véase la página 19
para más información sobre la gestión de mayúsculas y minúsculas en los
diccionarios).
3.5.4.37.
Elemento de asignación <let>
La instrucción de asignación <let> asigna el valor de la parte derecha
de la asignación (una cadena literal, un clip, una variable, etc.) a la parte
izquierda (un clip, una variable, etc.). Véase un ejemplo de uso en la
figura 3.41.
3.5.4.38. Elemento de concatenación de cadenas <concat>
Este elemento se usa para concatenar cadenas para asignarlas a una
variable. Se usa de manera combinada con <let>, y el valor anterior de la
variable que se modifica con la asignación de <concat>, se pierde.
No tienen ningún atributo. Puede contener qualquier instrucción que
devuelva una cadena, como <lit>, <lit-tag> o <clip>.
En la figura 3.42 puede verse un ejemplo de uso.
3.5.4.39.
Elemento de concatenación de cadenas
<append>
La instrucción <append> puede utilizarse para almacenar la salida de
una acción antes de imprimirla en el <out> correspondiente, por conveniencia del diseñador de las reglas de transferencia.
El atributo obligatorio n especifica el nombre de variable que tiene la
expresión. Al final de la instrucción, el contenido antiguo de la variable
referenciada será prefijo del nuevo contenido, es decir, el nuevo contenido
indicado dentro de <append> se concatenará al contenido preexistente en
la variable indicada en n.
El contenido de esta instrucción puede ser una o más de las siguientes
etiquetas: <b>, <clip>, <lit>, <lit-tag>, <var>, <get-case-from>,
<case-of> o <concat>. Se puede ver un ejemplo en la figura 3.43.
3.5.4.40.
Elemento de salida <out>
En la instrucción de salida se especifican las formas léxicas que se envı́an
a la salida del módulo tras haber sido sometidas a las operaciones de
102
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<rule>
<pattern>
<pattern-item n="pretind"/>
</pattern>
<action>
<out>
<lu>
<get-case-from pos ="1">
<lit v="anar"/>
</get-case-from>
<lit-tag v="vaux"/>
<clip pos="1" side="sl" part="persona"/>
<clip pos="1" side="sl" part="nbr"/>
</lu>
<b/>
</out>
<choose>
<when>
<test>
<equal>
<case-of pos="1" side="sl" part="lemh"/>
<lit v="Aa"/>
</equal>
</test>
<modify-case>
<case-of pos="1" side="tl" part="lemh"/>
<lit v="aa"/>
</modify-case>
</when>
</choose>
<out>
<lu>
<clip pos="1" side="tl" part="lemh"/>
<clip pos="1" side="tl" part="a_verb"/>
<lit-tag v="inf"/>
<clip pos="1" side="tl" part="lemq"/>
</lu>
</out>
</action>
</rule>
Figura 3.40: Regla para traducir de español a catalán que transforma los verbos en
pretérito perfecto simple o indefinido (dije) en la forma de pretérito perfecto perifrástico usual en catalán (vaig dir), al mismo tiempo que se asigna la información
correcta de mayúsculas/minúsculas a las dos palabras resultantes.
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
103
<rule>
<pattern>
<pattern-item n="det"/>
<pattern-item n="nom"/>
</pattern>
<action>
<choose>
<when>
<test>
<and>
<not>
<equal>
<clip pos="2" side="tl" part="gen"/>
<clip pos="2" side="sl" part="gen"/>
</equal>
</not>
<not>
<equal>
<clip pos="2" side="tl" part="gen"/>
<lit-tag v="mf"/>
</equal>
</not>
<not>
<equal>
<clip pos="2" side="tl" part="gen"/>
<lit-tag v="GD"/>
</equal>
</not>
</and>
</test>
<let>
<clip pos="1" side="tl" part="gen"/>
<clip pos="2" side="tl" part="gen"/>
</let>
</when>
</choose>
<!-- Otras operaciones de concordancia de género y número -->
Figura 3.41: Fragmento de una regla en la que el patrón detectado es
determinante–nombre (continúa en la fig. 3.44): en esta parte de la regla, se asigna
el género del nombre al determinante en caso de que el nombre cambie de género entre la LO (sl) y la LM (tl) durante el proceso de transferencia léxica entre
ambas lenguas.
104
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<let>
<var n="palabra"/>
<concat>
<clip pos="3" side="tl" part="lem"/>
<lit-tag v="adj"/>
</concat>
</let>
Figura 3.42: En este ejemplo se atribuye a la variable palabra el valor de la concatenación de un clip (el lema de la posición 3) y una etiqueta adj.
<append n="temporal">
<clip pos="3" part="gen" side="tl"/>
</append>
Figura 3.43: En este ejemplo se concatena a la variable temporal el valor de
género de la parte de LM de la tercera palabra detectada por la regla.
transferencia estructural pertinentes. El uso de este elemento varı́a según
el módulo. Por un lado, el uso en el módulo chunker cuando funciona
como único módulo (transferencia sintáctica superficial) y en el módulo
postchunk son similares, pues la salida que hay que imprimirse en los
dos casos será la entrada del generador. El módulo chunker en Apertium
2 y el módulo interchunk tienen modos de uso diferentes: el primero
para crear los segmentos y el segundo para modificar los segmentos sin
modificar su parte interna.
1. Uso en chunker en modo superficial y en postchunk
La instrucción envı́a cada forma léxica dentro de un conjunto <lu>,
que a su vez puede estar contenido dentro de un elemento <mlu>
si lo que se envı́a es una multipalabra compuesta de dos o más FL.
Además, se envı́an también los espacios en blanco o superblancos
(<b>) que haya que colocar entre FL y FL. En las figuras 3.40 y 3.44
puede verse un ejemplo de uso.
2. Uso en chunker en modo avanzado
La salida de este módulo se espera que sea una secuencia de uno
o más chunks (enviados con el elemento <chunk>) separados por
blancos <b>. Las formas léxicas y multiformas léxicas, ası́ como los
blancos entre las mismas, se envı́an dentro de los chunks. En la figura
3.45 se puede ver su uso.
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
105
<!-- ... -->
<out>
<lu>
<clip pos="1" side="tl" part="whole"/>
</lu>
<lu>
<clip pos="2" side="tl" part="whole"/>
</lu>
</out>
</process>
</action>
</rule>
Figura 3.44: Fragmento de una regla (viene de la fig. 3.41). Al final de la
regla, y tras varias operaciones, se da salida a la información resultante mediante el atributo whole, que contiene el lema y los sı́mbolos morfológicos
de cada FL (posiciones 1 y 2 del patrón).
3. Uso en interchunk
En este módulo, las formas léxicas de las palabras son inaccesibles,
pues sólo son posibles las operaciones con los chunks y, por lo tanto,
dentro de un elemento <out> sólo puede haber elementos <chunk>
o blancos <b>. La información de lema y de etiquetas que hay dentro
del elemento <chunk> corresponde al lema del chunk y a las etiquetas del chunk exclusivamente.
Se puede ver un ejemplo de uso en la figura 3.46.
3.5.4.41. Elemento de unidad léxica <lu>
Su nombre proviene de lexical unit o “unidad léxica” y es el elemento
mediante el que se envı́a cada forma léxica del patrón en lengua meta a
la salida de la regla, dentro del elemento <out>. Mediante este elemento puede enviarse la forma léxica completa, con el atributo whole de un
<clip>, o bien, en caso necesario, indicar explı́citamente cada una de sus
partes (lema más etiquetas, especificadas mediante cadenas <clip>, cadenas literales <lit>, etiquetas <lit-tag>, variables <var>, ası́ como información de mayúsculas y minúsculas [<get-case-from>, <case-of>]).
Hay que tener en cuenta que, como se ha explicado antes, en el caso de
las multipalabras con lema partido hay que resituar la cola de un lema multipalabra detrás de los sı́mbolos gramaticales de la palabra flexionada (o
106
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<out>
<chunk name="pr" case="caseFirstWord">
<tags>
<tag><lit-tag v="PREP"/></tag>
</tags>
<lu>
<clip pos="1" side="tl" part="whole"/>
</lu>
</chunk>
<b pos="1"/>
<chunk name="probj" case="caseOtherWord">
<tags>
<tag><lit-tag v="SN"/></tag>
<tag><lit-tag v="tn"/></tag>
<tag><clip pos="2" side="tl" part="pers"/></tag>
<tag><clip pos="2" side="tl" part="gen"/></tag>
<tag><clip pos="2" side="tl" part="nbr"/></tag>
</tags>
<lu>
<clip pos="2" side="tl" part="lem"/>
<lit-tag v="prn"/>
<lit-tag v="2"/>
<clip pos="2" side="tl" part="pers"/>
<clip pos="2" side="tl" part="gen" link-to="4"/>
<clip pos="2" side="tl" part="nbr" link-to="5"/>
</lu>
</chunk>
</out>
Figura 3.45: Instrucción de salida que imprime dos segmentos separados
por un blanco. La secuencia que se imprime es la de preposición seguida
de sintagma nominal. Las etiquetas que se enlazan a fuera como referencia
son la persona, el género y el número del sintagma nominal. Usa las etiquetas <tag> para especificar las etiquetas del segmento, y el valor de los
atributos name y case para especificar la forma léxica del chunk.
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
107
<out>
<b pos="1">
<chunk>
<clip pos="2" part="lem"/>
<clip pos="2" part="tags"/>
<clip pos="2" part="chcontent"/>
</chunk>
</out>
Figura 3.46: Esta salida se ha hecho para descartar el primer chunk de una
regla (caı́da de pronombre). El uso de los tres elementos <clip> se ha hecho aquı́ con fines ilustrativos, puesto que se habrı́an podido sustituir por
la part="whole" que los agruparı́a en un único <clip> .
cabeza del lema), ya que el módulo pretransfer ha adelantado la cola
y la ha colocado antes de los sı́mbolos gramaticales de la cabeza. Esta recolocación se realiza aquı́, dentro del elemento <lu>, mediante los valores
lemh y lemq del atributo part de un <clip>. El atributo lemh corresponde a la cabeza de lema, y el atributo lemq, a la cola del lema. Como
se ve en el ejemplo 3.40, la parte lemq del <clip> se coloca detrás de la
cabeza del lema y de los sı́mbolos gramaticales que la acompañan. Esta regla servirı́a, por ejemplo, para la forma en español eché de menos, que debe
traducirse al catalán por vaig trobar a faltar. El atributo a verb que aparece
detrás de lemh contiene el sı́mbolo gramatical que describe la categorı́a
del verbo (vblex, vbser, vbhaver o vbmod según el caso). Ası́, la última forma
léxica enviada por esta regla, para el caso de vaig trobar a faltar, serı́a en el
flujo de datos:
ˆtrobar<vblex><inf># a faltar$
El sı́mbolo almohadilla del flujo de datos se corresponde con el elemento
<g> de los diccionarios, utilizado para indicar la posición de las partes
invariables de una unidad multipalabra con lema partido.
Es importante tener en cuenta que los atributos que se incluyen dentro
de <lu> pueden estar vacı́os. Ası́, un verbo que entre por la regla de la
figura 3.40 y que no sea una multipalabra con lema partido, será enviado
con el atributo lemq vacı́o, puesto que no tiene cola de lema. De este modo no hay que definir reglas diferentes para formas léxicas con cola y sin
cola. Puede verse también otro ejemplo en la página 156, en que la regla
para verbo envı́a con <lu> los atributos gen (género) y nbr (número). De
este modo se incluyen los participios (con género y número) y las demás
formas verbales (que llevarán estos atributos vacı́os).
108
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
En la misma página puede verse una regla para verbo seguido de pronombre enclı́tico. Aquı́, la cola del lema se coloca detrás del pronombre
enclı́tico; ası́, las formas léxicas enviadas en el caso de una multipalabra
unida a un pronombre enclı́tico, como echándote de menos, serı́an, en el flujo de datos y traduciendo al catalán:
ˆtrobar<vblex><ger>+et<prn><enc><p2><mf><sg># a faltar$
Por supuesto, esta regla sirve también para verbos que no sigan este
patrón de multipalabra, de modo que la forma explicándote serı́a ası́ enviada por la regla en la traducción de español a catalán:
ˆexplicar<vblex><ger>+et<prn><enc><p2><mf><sg>$
En cuanto al atributo whole de un <clip>, es importante tener en
cuenta que sólo puede utilizarse para enviar la forma léxica completa en
caso de que la palabra enviada no pueda ser una multipalabra, es decir,
no pueda contener un lema partido. Compárense las figuras 3.40 y 3.44. El
atributo whole puede utilizarse en el segundo ejemplo porque contiene
el lema lem más todas las etiquetas morfológicas de las formas léxicas en
posición 1 y 2 (determinante y nombre). En cambio, en el primer ejemplo,
la forma léxica enviada dentro de <lu> se envı́a por partes, con un lemh
(cabeza del lema) y un lemq (cola del lema), puesto que puede ser que el
verbo detectado en el patrón sea una multipalabra con lema partido. En
la práctica, esto significa que, en nuestro sistema, el atributo whole puede
utilizarse para enviar cualquier tipo de forma léxica excepto los verbos y
los nombres, puesto que sólo hemos definido multipalabras con flexión
para formas verbales y nombres.
3.5.4.42. Elemento de unidad léxica <mlu>
Su nombre proviene de multilexical unit o “multiforma léxica” y se utiliza dentro del elemento <out> para enviar multipalabras compuestas por
más de una forma léxica. Cada forma léxica de una <mlu> se envı́a dentro
de un elemento <lu>. A la salida del módulo, las formas léxicas contenidas dentro de este elemento aparecerán unidas entre sı́ mediante el sı́mbolo ’+’ del flujo de datos. Esto significa que se convertirán en una multipalabra compuesta por varias formas léxicas y que serán tratadas como una
unidad por los módulos subsiguientes; por lo tanto, en el diccionario de
generación deberá existir una entrada para esta multipalabra para que sea
posible generarla.
En nuestro sistema, este elemento se utiliza para unir los pronombres
enclı́ticos a los verbos conjugados.
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
3.5.4.43.
109
Elemento de encapsulamiento de segmento <chunk>
Es el elemento con el que se envı́an los chunks a la salida del módulo
dentro de un elemento <out>. Este elemento sólo se utiliza en el módulo
chunker en modo avanzado y en el módulo interchunk. En el módulo
postchunk no se usa porque no es necesario crear ningú chunk a la salida.
En el módulo chunker en modo superficial tampoco seusa porque a la
salida no se envı́an chunks sino unidades léxicas individuales y blancos.
1. Uso en el módulo chunker en modo avanzado
En este modo, el elemento <chunk> debe tener un atributo name
que es el lema del segmento, o bien un atributo namefrom que hace
referencia a una variable previamente definida, el valor de la cual se
usará como lema del segmento. Además, puede incorporar un atributo case para especificar de qué variable se toma la polı́tica de
mayúsculas (con un valor obtenido con la instrucción <case-from>,
por ejemplo).
Se puede ver un ejemplo de uso del elemento en la figura 3.45.
2. Uso en el módulo interchunk
En este módulo, el elemento <chunk> no especifica ningún atributo,
sólo se usa del modo en que se usa <lu> en el transfer superficial
o en el postchunk para deliminar la forma léxica. Dentro de él se
envı́an (generalmente con una instrucción de <clip>)
[Nota: MG: generalmente o sempre]
, el lema del chunk (lem), las etiquetas (tags) y el contenido del
chunk (chcontent, contiene las FL más los blancos), que es una
parte invariable pues en el módulo interchunk no se puede acceder a él. La parte invariable del segmento se envı́a al final. También
puede utilizarse el atributo whole para enviar el chunk entero (lema,
etiquetas y contenido invariable).
Se puede ver un ejemplo de uso del elemento en la figura 3.46.
3.5.4.44. Elemento de sección de enlace de etiquetas <tags>
Sólo en chunker en modo avanzado.
Este elemento sirve para especificar una lista de etiquetas o elementos
<tag> que serán las pseudoetiquetas del chunk. No tiene atributos, y debe
especificarse como primer elemento dentro del elemento <chunk>. Véase
la figura 3.45.
110
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
3.5.4.45. Elemento de enlace de etiquetas <tag>
Sólo en chunker en modo avanzado.
El elemento <tag> tiene que contener una una etiqueta morfológica,
que se puede especificar mediante una instrucción <clip> o bien una etiqueta literal <lit-tag>. No tiene atributos.
La etiqueta o las etiquetas especificadas de esta manera dentro de un
chunk pasarán a ser las etiquetas morfológicas del segmento, que el módulo siguiente, interchunk, podrá utilizar para realizar comprobaciones y
modificaciones en las caracterı́sticas de los segmentos.
3.5.4.46. Elemento de blanco <b>
El elemento <b> hace referencia a los [super]blancos, y se indexa mediante el atributo pos; por ejemplo, un <b> con pos="2" se refiere a los
[super]blancos (incluidos los datos de formato encapsulados por el desformatador) entre la 2a FLLO y la 3a FLLO. La gestión explı́cita de [super]blancos permite la colocación correcta del formato cuando el resultado
de la transferencia estructural tiene más o menos elementos léxicos que el
original o bien ha sido sometido a algún tipo de reordenación.
3.5.5.
Especificación de los tres módulos del sistema de transferencia avanzada
A continuación se describen las caracterı́sticas diferenciadas del formato de los reglas en los tres módulos de un sistema de transferencia sintáctica avanzada. Cuando Apertium funcione con un sistema de transferencia sintáctica superficial, sólo entra en acción el primero módulo, llamado
chunker, que se comunica directamente con el módulo de generación.
3.5.5.1. Programa chunker
Este módulo puede utilizarse individualmente como sistema de transferencia sintáctica superficial, o en combinación con los otros dos módulos de transferencia para construir un sistema de transferencia sintáctica
avanzada. Un atributo del elemento <transfer> controla su modo de
funcionamiento.
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
111
Entrada/salida
Entrada: datos con el formato de salida del pretransfer, es decir, con las colas invariantes de las multipalabras desplazadas a una
posición anterior a cualquier etiqueta.
Salida:
- en modo avanzado (en un sistema de transferencia avanzada):
segmentos (chunks), para que el módulo siguiente los detecte y
realice operaciones con ellos
- en modo superficial (en un sistema de transferencia superficial):
formas léxicas que constituyen la entrada del módulo de generación.
Ficheros de datos
[Nota: Explicar millor això de l’únic fitxer de configuració]
Este programa usa un único fichero de configuración y un fichero precompilado de detección de patrones calculado a partir del primero. El
nombre del fichero de patrones (el fichero de configuración) tendrá la extensión .t1x. Como el chunker es quien hace la consulta del diccionario
bilingüe, éste (en forma compilada) también se tiene que aportar al programa.
[Nota: Potser seria bona idea esmentar en quina secció s’explica el
compilador a què es fa referència]
La DTD de este fichero de datos se especifica en el apéndice A.3, y en
el apartado 3.5.4 se describen los elementos utilizados para crear las reglas
del fichero.
Detección de patrones
El sistema de detección de reglas de este módulo será el que se ha explicado en 3.5.2 pues es el mismo en modo de transferencia avanzada y en
modo de transferencia superficial. El programa apertium-pretransfer
[Nota: Vacil·lació terminològica pretransfer.]
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
112
es necesario para adaptar el formato de salida del etiquetador a la entrada que reconoce el módulo de transferencia. En posteriores versiones de
Apertium no se descarta que se modifique el desambiguador categorial para
que haga el trabajo del apertium-pretransfer.
[Nota: També hem d’unificar la terminologia d’altres mòduls: desambiguador categorial, etiquetador ; tal com està redactat el paràgraf es
podria pensar que són dues coses diferents.]
Funcionamiento
El funcionamiento es básicamente similar en el modo superificial y en
el modo avanzado, con estas diferencias:
Para que el módulo funcione como primer módulo de un sistema de
transferencia sintáctica avanzada, en el atributo opcional default
del elemento raı́z <transfer> debe especificarse el valor chunk.
El valor por defecto es lu, que implica que el chunker funcione en
modo de transferencia sintáctica superficial (como único módulo).
Generación de segmentos (chunks) a la salida: la etiqueta <chunk>
es una etiqueta de un nivel más alto que <lu> (lexical unit) que permite generar segmentos con las caracterı́sticas que han sido especificadas en 3.5.3.1; tiene los siguientes atributos:
• name (opcional): pseudolema del segmento. Una cadena que
permita identificar el pseudolema del segmento.
• namefrom (opcional): pseudolema del segmento, obtenido de
una variable. Es obligatorio especificar o name o namefrom.
• case (opcional): variable que sirve para obtener la información
de mayúsculas o minúsculas de una variable y aplicarla al lema
especificado bien por name, bien por namefrom.
Cada chunk empieza por una instrucción <tags>, que no permite
especificar ningún atributo, la cual, por su parte, contiene una o más
instrucciones individuales <tag>.
Las instrucciones <tag> no tienen atributos. Dentro de ellas se puede poner cualquier instrucción que devuelva como valor una cadena:
<lit>, <var>.
Las instrucciones <clip> tienen un nuevo atributo opcional: link-to,
que sirve para especificar una etiqueta <valor de link-to> en lugar de
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
113
[Nota: Es “en lugar de” o “adicionalmente a”?]
la información que contenga el <clip> en los demás atributos.
[Nota: No s’entén gaire bé]
Esta información es prescindible pero puede servir como documentación del origen de la decisión lingüı́stica.
Veamos con un ejemplo el uso del elemento <chunk>:
<out>
<chunk name="adj-nom" case="variableCase">
<tags>
<tag><lit-tag v="SN"/></tag>
<tag><clip pos="2" side="tl" part="gen"/></tag>
<tag><clip pos="2" side="tl" part="nbr"/></tag>
</tags>
<lu>
<clip pos="2" side="tl" part="lemh"/>
<clip pos="2" side="tl" part="a_nom"/>
<clip pos="2" side="tl" part="gen" link-to="2"/>
<clip pos="2" side="tl" part="nbr" link-to="3"/>
</lu>
<b pos="1"/>
<lu>
<var n="adjectiu"/>
<clip pos="1" side="tl" part="lem"/>
<clip pos="1" side="tl" part="a_adj"/>
<clip pos="2" side="tl" part="gen" link-to="2"/>
<clip pos="2" side="tl" part="nbr" link-to="3"/>
</lu>
</chunk>
</out>
Acción implı́cita
Los superblancos aislados, que no son detectados por ningún patrón de
este módulo, se escriben en el mismo orden en el que llegan.
El elemento raı́z del fichero .t1x de reglas del chunker, <transfer>,
tiene un atributo opcional default que puede tomar los valores
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
114
chunk: cuando el módulo funcione en modo avanzado (transferencia sintáctiva avanzada), para que se generen segmentos triviales con
las palabras que no son detectadas por ninguna regla, para que a
la salida no haya ninguna palabra no integrada en un segmento. El
nuevo segmento se creará mediante la traducción de la palabra por
el diccionario bilingüe. El lema fijo de los chunks creados implı́citamente es default.
lu (valor implı́cito): cuando el módulo funcione como único módulo
de transferencia en modo superficial (transferencia sintáctica superficial), para que no se creen segmentos para las palabras no detectadas
por reglas, y simplemente se traduzcan con el diccionario bilingüe.
A continuación se muestra el segmento generado automáticamente con
una forma léxica no detectada por ninguna regla del chunker cuando el
atributo default tiene el valor chunk:
ˆdefault{ˆthat<cnjsub>$}$
[Nota: Va sense etiquetes entre default i {? No caldria dir-ho explı́citament?]
3.5.5.2.
Programa interchunk
[Nota: És apertium-interchunk o interchunk només?]
El programa interchunk trata los segmentos, los reordena y hace los
cambios pertinentes en la información morfosintáctica. Esto se hace mediante la detección de patrones de segmentos (secuencias de segmentos).
Las instrucciones que se usan para controlar su funcionamiento son, con
pocas diferencias, las mismas que usa el programa chunker, pero tiene
que quedar claro que se utiliza un archivo diferente. Los segmentos son
tratados de forma similar a como se tratan las palabras en el transfer o
chunker de Apertium.
[Nota: Comprovar la denominació dels programes]
Entrada/salida
Entrada: segmentos procedentes de chunker.
Salida: segmentos posiblemente reordenados y con la información
del pseudolema del segmento posiblemente modificada.
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
115
Ficheros de datos
Este módulo usa dos ficheros de datos. Un fichero de especificación
del comportamiento del programa interchunk, con extensión .t2x por
analogı́a con el módulo anterior, y un fichero de patrones precalculados
para acelerar el análisis de la entrada. No se incluye el fichero binario del
diccionario bilingüe porque no se usa.
[Nota: Citar el compilador?]
La sintaxi del fichero de especificación es muy similar a la del módulo
chunker. Su DTD se especifica en el Apéndice A.4, y en el apartado 3.5.4
se describen los elementos utilizados para crear las reglas del fichero.
Detección de reglas
Las reglas detectan patrones que están definidos mediante secuencias
de pseudopalabras. Estas pseudopalabras tienen un formato basado en el
formato de la forma léxica de las palabras. Desde el punto de vista práctico, este pseudolema es visto de manera equivalente a como se
[Nota: La alternança pseudolema i pseudoparaula s’ha de resoldre]
ve la forma léxica de una palabra en el módulo chunker para realizar la
detección. De esta forma, se usará una detección de patrones con atributos definidos sobre las pseudopalabras y no sobre las palabras del patrón
original.
Funcionamiento
Las modificaciones en el juego de instrucciones de este módulo —respecto
del juego de instrucciones utilizado en chunker— son las siguientes:
El elemento raı́z se llama <interchunk> y no especifica ningún
atributo.
Desaparición del atributo side: este módulo no usa diccionarios bilingües; por lo tanto el atributo que indica si la parte que se consulta
es la lengua origen o la meta no tiene sentido. Este atributo era usado
fundamentalmente en las instrucciones <out>.
La etiqueta <chunk> ahora se usa sin atributos, sencillamente dentro
de <out> para delimitar la salida de segmentos.
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
116
El atributo predefinido lem hace referencia al pseudolema del segmento. De la misma manera, el atributo predefinido tags hace referencia a las etiquetas del segmento. El contenido del segmento queda
como una cola que se puede imprimir mediante el atributo implı́cito
chcontent.
[Nota: Només imprimir o s’hi pot fer referència també?]
[Nota: Dir de quin element són aquests atributs]
Todos los valores de part, excepto chname, acceden a la información del lema y las etiquetas del pseudolema de cada segmento.
A diferencia de lo que sucede en el módulo chunker, no se permite
imprimir otra cosa que <chunk>s en las instrucciones <out> en el
fichero de especificación del comportamiento de este módulo, y en
ningún caso palabras sueltas.
Acción implı́cita
Al igual que en el módulo anterior, se ha establecido una acción implı́cita que escribe sin modificar los segmentos no reconocidos por ningún
patrón del fichero de especificación de este módulo. Esta acción implı́cita
escribe exactamente lo que lee, tanto si se trata de chunks como de blancos.
[Nota: Atenció a la vacil·lació regla/acció en la resta del document.
Sempre havia cregut que era regla=patró+acció.]
3.5.5.3. Programa postchunk
El programa postchunk detecta segmentos individuales, y para cada
uno de ellos, ejecuta unas acciones especificadas. La detección se basa en el
lema del segmento, y no en patrones (no en las etiquetas); esto hará que la
detección en este módulo sea especı́fica para cada “nombre” de segmento.
[Nota: Quan fixem bé la terminologia hem d’assegurar-nos que la
redacció d’aquesta part és l’adequada.]
Por otro lado, el funcionamiento de la detección y del procesamiento
de las reglas se basa en que las referencias a parámetros se resuelven inmediatamente después de la detección, es decir, las etiquetas <1>, <2>, etc.
son sustituidas automáticamente por el valor de los parámetros antes de
empezar el procesamiento. Las posiciones (atributo pos) a las que se hace
3.5. MÓDULO DE TRANSFERENCIA ESTRUCTURAL
117
referencia con las instrucciones <clip>, etc. corresponden a la posición
de las palabras en el interior del segmento.
También aplica automáticamente la polı́tica de mayúsculas (ver sección
3.5.3.2) de los lemas de las pseudopalabras hacia las palabras que están
dentro del segmento.
Entrada/salida
Entrada: segmentos procedentes de interchunk.
Salida: entrada válida para el módulo de generación morfológica de
Apertium.
Ficheros de datos
Este programa tiene su propio archivo de especificación, que tendrá extensión .t3x. La sintaxis está basada igualmente en el chunker i en el
interchunk.
[Nota: Explicar que no ha de llegir cap fitxer compilat de patrons perquè usa noms i no patrons?]
Detección de reglas
La detección de los segmentos se basa en el nombre de los segmentos.
Los segmentos no detectados reciben el procesamiento implı́cito.
Funcionamiento
Las diferencias en las acciones en comparación con interchunk son
las siguientes:
Prohibición de la escritura de segmentos (<chunk>s) a la salida: sólo
se pueden escribir unidades léxicas (<lu> o <mlu>) y blancos.
[Nota: Comprovar aquest ı́tem perquè era incomplet i l’ha completat mlf]
Nuevo atributo de detección name de <cat-item>, que se usa en la
parte de <pattern> de las reglas de manera aislada, para forzar la
detección de los patrones por su nombre.
[Nota: Què vol dir “de manera aı̈llada”? Sembla que vulga dir “de
tant en tant”]
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
118
Tampoco existe el atributo side en los elementos a los que es aplicable en el módulo interchunk, por la misma razón por que en
interchunk no se accede al diccionario bilingüe.
[Nota: MG: però llavors això no és una diferència respecte de
interchunk no?]
Acción implı́cita
En este módulo la acción implı́cita es la de escribir las palabras de dentro del segmento, sustituyendo las referencias por los parámetros del segmento. Será usada para la mayor parte de segmentos, ya que se prevé que
este módulo se utilice para casos muy especı́ficos en los que sea necesario
hacer algún procesamiento concreto.
También se aplica implı́citamente la polı́tica de mayúsculas (sección
3.5.3.2).
En cualquier caso, los blancos externos a los segmentos son copiados en
el mismo orden en que son leı́dos, puesto que la detección de segmentos
es unitaria (este módulo no los agrupa).
3.5.6.
Preproceso del módulo de transferencia estructural
Los ficheros de especificación de los módulos de transferencia estructural, también llamados ficheros de reglas de transferencia, son preprocesados
por el programa apertium-preprocess-transfer que calcula los patrones para
casar precondiciones de las reglas y además indexa las reglas para acelerar
su procesamiento en tiempo de ejecución. Esta información se almacena en
un archivo en formato binario que se lee junto con el diccionario bilingüe
correspondiente y el propio fichero de reglas de transferencia para la ejecución conjunta de los módulos de transferencia léxica y estructural.
3.6.
Desformateador y reformateador
3.6.1.
Tratamiento del formato de los documentos
En esta sección se describe cómo tratan el formato de los documentos
los desformateadores y reformateadores de este sistema, creados a partir
de las reglas de especificación de formato en XML que se describen más
adelante, en la sección 3.6.2.
Los requisitos del proyecto indican que el traductor debe ser capaz de
procesar documentos en formato XML, HTML, RTF y texto llano. En todos
3.6. DESFORMATEADOR Y REFORMATEADOR
119
estos tipos de documento es posible realizar una encapsulación del formato,
tal como se describe a continuación.
El procedimiento consiste en encapsular las cadenas de texto —en adelante bloques de formato o superblancos— que se identifiquen como parte del
formato entre delimitadores que dependerán de la especificación del flujo
de datos entre módulos (que se discute en detalle en el capı́tulo 2); ası́, en
el formato de flujo (secciones 2.2.1 y 2.3), los superblancos van entre corchetes ’[’ y ’]’. Cada una de estas cadenas encapsuladas será tratada como si
de un blanco <b/> (página 36) se tratara —de ahı́ lo de superblancos— y
serán restituidas en el orden correcto a la salida del traductor.
Como ya se ha indicado en el capı́tulo 2, cuando los bloques de formato sean grandes (como ocurre a veces en HTML con segmentos de código
en Javascript, o en RTF con imágenes en formato de mapa de bits), se utilizará un mecanismo de almacenamiento en ficheros temporales de estos
bloques de formato grandes para eliminarlos del flujo de datos de la traducción.
Un requisito adicional que aparece es que muchas veces el formato de
una parte del documento marca implı́citamente la división del texto en
oraciones (véase la página 13 del capı́tulo 2). Por ejemplo, los tı́tulos de
secciones o de documentos pueden estar en frases que no acaben en punto. Si sabemos que una marca de formato nos está indicando esta división
debemos aprovechar esta información para poder traducir mejor estos casos. Ejemplos de este fenómeno pueden ser: dos saltos de lı́nea seguidos
en el formato de texto llano, una etiqueta </h1> en HTML, etcétera. El
módulo desformateador debe generar en estos casos una marca de final
de oración equivalente a un punto.
3.6.1.1.
Sistema de encapsulación del formato y ejemplo
Los tipos de bloques de formato o superblancos que se generan como
resultado del procesamiento del formato se presentan a continuación:
Bloques de formato o superblancos no vacı́os. Son los que contienen exclusivamente marcas de formato del documento original. En el flujo
de datos descrito en el capı́tulo 2 se abren con un corchete izquierdo
’[’ y se cierran con el derecho ’]’.
Bloques de formato con referencia a archivo externo o superblancos extensos. Sirven para encapsular segmentos de formato largos y ası́ mejorar el rendimiento del traductor. En el flujo de datos descrito en el
capı́tulo 2 comienzan por la cadena ’[@’, siguen con el nombre del
120
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
archivo en el que se almacena el segmento de formato extraı́do del
documento original, y finalmente acaban en un corchete derecho ’]’.
Bloques de formato vacı́os. Sirven para incorporar información artificial
de segmentación del texto obtenida a partir del formato. Antes del
bloque de formato vacı́o se coloca el signo de puntuación artificial
que se tenga que incluir. Cuando sea necesario restituir el formato
original al documento, la presencia de un bloque de formato de estas
caracterı́sticas obligará a la supresión del carácter inmediatamente
anterior que se encuentre en el flujo de datos.
El criterio que se aplica para crear estos bloques de formato se basa en
los siguientes criterios generales:
Se debe encapsular todo lo que no se considere parte del texto que
hay que traducir para formar bloques de formato.
No debe haber dos o más bloques de formato no vacı́os estrictamente
consecutivos. Dos bloques de formato consecutivos siempre deben
unirse en un solo bloque.
Los bloques de formato vacı́os deben preceder a un bloque de formato no vacı́o o al fin de fichero.
En la figura 3.47 se muestra un documento de ejemplo cuyo formato
debe ser tratado previamente a la traducción; en el ejemplo, el encapsulamiento se corresponde con el formato de flujo no basado en XML. La
figura 3.48 muestra el resultado de procesar el anterior documento.
De este ejemplo conviene resaltar los siguientes fenómenos:
No se generan bloques de formato con contenido (no vacı́os) consecutivos.
Las etiquetas como </title> y </p> inducen la introducción de
signos de puntuación artificiales, y esta introducción se realiza de
manera sistemática (incluso cuando no hace falta, porque no molesta
y es eficiente).
Los superblancos extensos salen literalmente del proceso de la traducción. En este caso, el fichero temporal temp35345 contiene las
etiquetas desde </title> hasta <p>
Los blancos sencillos entre palabras no se encapsulan. No ocurre lo
mismo con los blancos múltiples (dos o más blancos consecutivos),
tabuladores, etc. que son encapsulados. Los saltos de lı́nea también
se encapsulan.
3.6. DESFORMATEADOR Y REFORMATEADOR
121
<html>
<head>
<title>Esto es el tı́tulo</title>
<script>
<!-- ... (un bloque de código extenso) -->
</script>
</head>
<body>
<p>Esto
es un párrafo escrito en dos lı́neas</p>
</body>
</html>
Figura 3.47: Ejemplo de documento HTML
[<html>
<head>
<title>]Esto es el tı́tulo.[][@/tmp/temp35345]Esto[
]es un párrafo escrito en dos lı́neas.[][</p>
</body>
</html>]
Figura 3.48: Ejemplo de documento HTML con los bloques de formato encapsulados por el desformateador
[Nota: repeteix coses capı́tol format -revisar -Gema]
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
122
3.6.2.
Datos: reglas de especificación de formato
En esta sección se describe el proceso de generación de formateadores
y desformateadores a partir de una especificación de formato en XML.
Las reglas para los formatos se especifican, como los datos lingüı́sticos,
en XML, y dentro de ellas se declaran expresiones regulares con sintaxis
de flex. La especificación se estructura en tres partes (ver DTD de la definición formal en el apéndice A.6):
Opciones de configuración. En este apartado se especifica el valor
de la longitud máxima de un superblanco no extenso, las codificaciones de entrada y de salida, la necesidad de la distinción o no entre
mayúsculas y minúsculas y las expresiones regulares para los caracteres de escape y para los caracteres de espaciado.
Reglas de formato. Se describe el conjunto de etiquetas propias de
un formato determinado que han de ser encerradas en un bloque de
formato por el desformateador. Dichas etiquetas de formato podrán,
opcionalmente, indicar el fin de frase para que el desformateador
inserte el signo de puntuación artificial (seguido de un bloque de
formato vacı́o, como se especifica en la sección anterior). También se
ha de especificar la prioridad de aplicación de las reglas aunque, en
caso de no ser necesario, se puede dar a todas reglas la misma prioridad mediante la asignación del mismo valor (cualquier número) a
todas ellas.
Se entiende que todo lo que no sea especificado como formato quedará sin encapsular y será texto para traducir.
Reglas de sustitución. Permiten sustituir caracteres especiales del
texto. Una expresión regular recogerá un conjunto de caracteres especiales, y los sustituirá por los caracteres que se especifique. Por
ejemplo, en HTML los caracteres especificados en hexadecimal deben ser sustituidos por su correspondiente entidad o carácter ASCII.
Por ejemplo, camión se corresponde con camión.
A continuación se describen las reglas con más detalle.
Raiz del documento de especificación. En el atributo name está el
nombre del formato.
<?xml version="1.0" encoding="ISO-8859-1"?>
<format name="html">
3.6. DESFORMATEADOR Y REFORMATEADOR
123
<options>
...
</options>
<rules>
...
</rules>
</format>
Dentro deben estar las opciones y las reglas de las que se presenta un
ejemplo a continuación:
Opciones.
<options>
<largeblocks size="8192"/>
<input encoding="ISO-8859-1"/>
<output encoding="ISO-8859-1"/>
<escape-chars regexp=’[\[\]ˆ$\\]’/>
<space-chars regexp=’[ \n\t\r]’/>
<case-sensitive value="no"/>
</options>
El elemento <largeblocks> sirve para especificar la longitud máxima de un superblanco no extenso, mediante el valor del atributo size.
Los elementos <input> y <output> sirven para especificar la codificación de entrada y de salida del texto mediante el atributo encoding.
El elemento escape-chars permite especificar, mediante una expresión regular que se da en el valor del atributo regexp, qué caracteres deben protegerse mediante una barra invertida. El elemento <space-chars>
especifica el conjunto de caracteres que tienen que ser tomados como si
fueran espacios en blanco.
Finalmente, el elemento case-sensitive sirve para especificar si, en
todas las especificaciones de atributos del formato en las que intervengan
expresiones regulares es relevante si se especifican mayúsculas o minúsculas.
Reglas. Hay reglas de formato y de sustitución.
<rules>
<format-rule ... >
...
124
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
</format-rule>
...
<replacement-rule>
...
</replacement-rule>
...
</rules>
Se detallan en los dos puntos siguientes.
Reglas de formato. El desformateador encerrará en bloques de formato las etiquetas que estas reglas indiquen en su campo regexp. Si
se trata de etiquetas de inicio y fin, y todo lo que encierran es formato, se especifica una regexp tanto para begin como para end:
<format-rule eos="no" priority="1">
<begin regexp=’"\<!--"’/>
<end regexp=’"--\>"’/>
</format-rule>
De lo contrario se utiliza sólo un elemento begin-end:
<format-rule eos="yes" priority="3">
<begin-end regexp=’"<"[/]?"li"[ˆ>]*">"’/>
</format-rule>
Además, en priority se especifica una prioridad que sirve para
saber en qué orden se aplican las reglas de formato (el valor absoluto
no es relevante, sólo se utiliza el orden que se establece entre los
valores usados en las reglas). En “eos” se indica mediante yes o
no si el bloque de formato del que forme parte el patrón detectado
deberá ir precedido de un signo de puntuación artificial o no.11
Reglas de sustitución. Sirve para sustituir caracteres especiales del
texto. La expresión regular del atributo regexp recogerá un conjunto de caracteres especiales y los sustituirá en el texto a traducir por
los caracteres que se especifiquen. La correspondencia entre caracteres originales y sustituidos se establece en los atributos source y
target de los elementos replace, que pueden ser múltiples:
11
En todos estos casos, se usan las tı́picas entidades < y > para representar los
caracteres < y > respectivamente.
3.6. DESFORMATEADOR Y REFORMATEADOR
125
<replacement-rule regexp=’"&"[ˆ;]+;’>
<replace source="À" target="À"/>
<replace source="À" target="À"/>
<replace source="À" target="À"/>
<replace source="À" target="À"/>
<replace source="Á" target="Á"/>
<replace source="Á" target="Á"/>
<replace source="Á" target="Á"/>
<replace source="Á" target="Á"/>
...
</replacement-rule>
Expresiones regulares de los atributos regexp. Tienen la sintaxis utilizada en flex [9].
Como ejemplo de especificación de formato vamos a utilizar el de HTML,
del que se puede seguir la explicación que ofrecemos a continuación mirando la figura 3.49.
Encontramos, en primer lugar, la regla de formato que especifica de
forma general todas las etiquetas de HTML, es decir, considera etiqueta
HTML todo aquello que empiece por el signo < y termine por el signo >.
Esta regla tiene la prioridad más baja (4) para permitir que las reglas más
especı́ficas se apliquen preferentemente. Pero antes de considerar una etiqueta como general, es decir, antes de aplicar esta regla, se aplicará alguna
de las reglas de mayor prioridad. En el caso de HTML, la mayor prioridad la tienen los comentarios <!-- ... -->. Las marcas de inicio y fin
<script></script> y <style></style>, donde se considera formato todo que lo éstas encierren, tienen prioridad 2. Prioridad 3 tienen las
etiquetas que implican fin de frase (puntuación artificial), que son </br>,
</hr>, </p>, etc.
Finalmente se especifican las reglas de sustitución, para sustituir todos
los códigos que empiecen por &, y ası́ se especifica en la expresión regular.
Después se define cada una de las sustituciones: tanto &Agrave, como
&#192, &#xC0 y &#xc0 se sustituyen por À. De igual manera se declaran
los demás caracteres especiales.
3.6.3. Generación de formateadores y desformateadores
Para generar el formateador y el desformateador de un formato dado,
se aplica a las reglas en XML que declaran este formato (que se describen
a continuación) una hoja de estilo generadora de formateadores y desformateadores Esta transformación XSLT da como resultado un fichero lex
126
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
<?xml version="1.0" encoding="ISO-8859-1"?>
<format name="html">
<options>
<largeblocks size="8192"/>
<input encoding="ISO-8859-1"/>
<output encoding="ISO-8859-1"/>
<escape-chars regexp=’[\[\]ˆ$\\]’/>
<space-chars regexp=’[ \ n\ t\ r]’/>
<case-sensitive value="no"/>
</options>
<rules>
<format-rule eos="no" priority="1">
<begin regexp=’"<!--"’/>
<end regexp=’"-->"’/>
</format-rule>
<format-rule eos="no" priority="2">
<begin regexp=’"<script"[ˆ>]*">"’/>
<end regexp=’"</script"[ˆ>]*">"’/>
</format-rule>
<format-rule eos="no" priority="2">
<begin regexp=’"<style"[ˆ>]*">"’/>
<end regexp=’"</style"[ˆ>]*">"’/>
</format-rule>
<format-rule eos="yes" priority="3">
<begin-end regexp=’"<"[/]?"br"[ˆ>]*">"’/>
</format-rule>
<!-- Aquı́ faltan más declaraciones format-rule eos="yes"-->
<!-- ...
-->
<format-rule eos="no" priority="4">
<begin-end regexp=’"<"[a-zA-Z][ˆ>]*">"’/>
</format-rule>
<replacement-rule regexp=’"&"[ˆ;]+;’>
<replace source="À" target="À"/>
<replace source="À" target="À"/>
<replace source="À" target="À"/>
<replace source="À" target="À"/>
<!-- Aquı́ faltan más elementos replace
<!-- ...
</replacement-rule>
</rules>
</format>
Figura 3.49: Parte de la definición de reglas del formato HTML
-->
-->
3.6. DESFORMATEADOR Y REFORMATEADOR
127
[9] que, una vez compilado, es el ejecutable del formateador o desformateador para el formato especificado.
Gracias a la especificación general de formatos descrita en este capı́tulo, se han podido definir las especificaciones para los formatos HTML, RTF
y texto llano. Estas especificaciones se hallan en el paquete apertium, en
los ficheros respectivos html-format.xml, rtf-format.xml, txt-format.xml.
En particular, es relativamente sencillo definir desformateadores y reformateadores de cualquier formato XML.
128
CAPÍTULO 3. ESPECIFICACIÓN DE LOS MÓDULOS
Capı́tulo 4
Instalación y ejecución del
sistema
4.1. Requisitos del sistema
El sistema en el que se desee instalar y ejecutar Apertium debe tener
los siguientes programas instalados:
libxml2 versión 2.6.17 o superior
programa xmllint (generalmente viene incluido en libxml2, pero
puede ser un paquete independiente en el sistema, por ejemplo en
Debian GNU-Linux)
programa xsltproc (para no usuarios de PowerPC); también viene
con libxml2 pero puede ser igualmente un paquete independiente
en el sistema, como en el caso de xmllint
programa sabcmd (usuarios de PowerPC), suministrado con el paquete sablotron
GNU make, gcc (g++), intérprete de comandos bash
4.2. Instalación de los paquetes de programas
Para instalar los programas y librerı́as del sistema de traducción automática Apertium, deberá descargarse (de http://sourceforge.net/
projects/apertium), compilar e instalar la última versión de los siguientes paquetes, en el orden especificado:
129
130
CAPÍTULO 4. INSTALACIÓN Y EJECUCIÓN DEL SISTEMA
1. lttoolbox
2. apertium
La manera más sencilla de compilar los paquetes es la siguiente:
1. Vaya al directorio que contiene el código fuente del paquete y escriba
./configure; se configurará el paquete en su sistema. Si utiliza csh
en una versión antigua de System V, probablemente deberá escribir
sh ./configure para evitar que csh (el intérprete de comandos
por defecto en el antiguo System V) intente ejecutar configure por
sı́ solo. La ejecución de configure tarda un tiempo; mientras se
ejecuta, muestra en pantalla algunos mensajes que indican qué comprobaciones está realizando.
2. Escriba make para compilar el paquete
3. Escriba make install (probablemente necesitará privilegios de administrador) para instalar los programas, los ficheros de datos y la
documentación.
4. Si desea eliminar del directorio de código fuente los archivos binarios y los archivos de objetos del programa, escriba make clean.
Para eliminar también los ficheros que configure ha creado (de
modo que pueda compilar el paquete para un ordenador de diferente tipo), escriba make distclean. También hay una opcion
maintainer-clean en el Makefile, pero está prevista principalmente para los desarrolladores del paquete. Si lo utiliza, es probable
que después tenga que buscar varios programas que necesitará para
volver a generar los archivos que estaban incluidos en la distribución.
Si no dispone de privilegios de administrador para instalar los programas en su sistema, puede utilizar la opción -prefix con el script de
configuración para que se instalen en su cuenta de usuario. Por ejemplo:
$ pwd
/home/me/lttoolbox-0.9.1
$ ./configure --prefix=/home/me/myinstall
Las librerı́as se instalarán en el directorio LIBDIR=$prefix/lib. Si
no se especifica ninguna opción -prefix con el script de configuración,
el directorio LIBDIR será /usr/local/lib.
4.3. INSTALACIÓN DE LOS PAQUETES DE DATOS
131
Si encuentra algún error de enlace con las librerı́as instaladas en el directorio LIBDIR, deberá usar libtool y especificar la ruta de acceso completa de la librerı́a, o bien utilizar la opción LIBDIR durante el enlace y
realizar al menos una de las siguientes acciones:
añadir LIBDIR a la variable de entorno LD_LIBRARY_PATH durante
la ejecución
añadir LIBDIR a la variable de entorno LD_RUN_PATH durante el
enlace
utilizar -Wl, --rpath -Wl, opción de enlazado LIBDIR
pedir al administrador del sistema que añada LIBDIR a /etc/ld.so.conf
y ejecute ldconfig
Consulte la documentación del sistema operativo relativa a las librerı́as
compartidas para obtener más información; por ejemplo, las páginas de
manual ld(1) y ld.so(8).
4.3. Instalación de los paquetes de datos
Para instalar los paquetes de datos lingüı́sticos, siga los pasos siguientes:
1. Descargue un paquete de datos (apertium-L1 -L2 -VERSION.tar.gz)
de la página web de Apertium en Sourceforge (http://apertium.
sourceforge.net/). Por ejemplo, para obtener la versión 0.9 de
los datos lingüı́sticos del traductor español–catalán, deberá descargarse el paquete apertium-es-ca-0.9.tar.gz.
2. Descomprima el archivo en cualquier directorio, vaya al directorio
en cuestión y escriba make en el terminal. Espere mientras se compilan los datos lingüı́sticos.
4.4. Ejecución del traductor
Hay versiones del traductor Apertium que funcionan tanto en sistemas operativos Linux (siempre más actualizadas) como en Windows. La
información de este capı́tulo está básicamente dirigida a los usuarios de
Linux.
132
CAPÍTULO 4. INSTALACIÓN Y EJECUCIÓN DEL SISTEMA
Para utilizar el traductor, debe ejecutarse la herramienta apertium-translator
haciendo referencia al directorio en el que se encuentran los datos lingüı́sticos, indicando además la dirección de traducción (es-ca, ca-es, es-gl,
etc.), el formato del fichero (txt, html, rtf), el nombre del fichero a traducir y el nombre del fichero resultante. La estructura del comando es por
tanto la siguiente:
$ apertium-translator <directorio> <traducción> <formato>
< fichero_original > fichero_traducido
Por ejemplo, si el directorio es /home/maria/apertium-es-ca, hay
que escribir lo siguiente para traducir un fichero en formato txt de español a catalán:
$ apertium-translator /home/maria/apertium-es-ca es-ca
txt <fichero_esp >fichero_cat
Es aconsejable situarse en el directorio en el que están almacenados los
datos lingüı́sticos, porque de este modo es suficiente con escribir un punto
para hacer referencia al directorio presente:
$ apertium-translator . es-ca txt <fichero_esp >fichero_cat
Si no se indica ningún formato, el formato por defecto es txt. Con los
formatos txt, html y rtf, las palabras desconocidas se marcan con un
asterisco (*) y los errores con un sı́mbolo (@, # o /); si se desea que no se
marquen las desconocidas ni los errores, se añade una u al nombre del
formato. Ası́, las opciones de formato son las siguientes:
txt : Opción predeterminada, texto con marca de desconocidas y de
errores
txtu : texto sin marca de desconocidas ni de errores
html : HTML con marca de desconocidas y de errores
htmlu : HTML sin marca de desconocidas ni de errores
rtf : RTF con marca de desconocidas y de errores
rtfu : RTF sin marca de desconocidas ni de errores
4.4. EJECUCIÓN DEL TRADUCTOR
133
Si no se desea traducir un fichero sino traducir directamente una frase
en pantalla, puede ejecutarse la herramienta apertium-translator sin
indicar ningún nombre de archivo. El comando, si estamos situados en el
directorio de datos lingüı́sticos, serı́a como sigue:
$ apertium-translator . es-ca
A continuación, debe escribirse el texto que se desea traducir (pueden
incluirse saltos de lı́nea). Para obtener la versión traducida, debe pulsarse
Ctrl + D, con lo que la traducción aparecerá en pantalla.
Una tercera manera de traducir con Apertium es utilizando el comando
echo para pasar texto a través del traductor:
$ echo "texto que quiero traducir" | apertium-translator . es-ca
134
CAPÍTULO 4. INSTALACIÓN Y EJECUCIÓN DEL SISTEMA
Capı́tulo 5
Mantenimiento de los datos
lingüı́sticos del traductor
5.1. Descripción de los datos lingüı́sticos existentes
Actualmente, Apertium posee datos lingüı́sticos para dos pares de lenguas: español–catalán y español–gallego. Los archivos que contienen los
datos lingüı́sticos están contenidos en un solo directorio: apertium-es-ca
para el par español–catalán y apertium-es-gl para el par español–gallego.
Los nombres de los ficheros contenidos en este directorio siguen la siguiente estructura:
apertium-L1 -L2 .L1 .dix : diccionario monolingüe del idioma L1 .
apertium-L1 -L2 .L2 .dix : diccionario monolingüe del idioma L2 .
apertium-L1 -L2 .L1 -L2 .dix : diccionario bilingüe del par de idiomas L1 -L2 (en ambas direcciones).
apertium-L1 -L2 .trules-L1 -L2 .dix : reglas de transferencia estructural para la traducción de L1 a L2 .
apertium-L1 -L2 .trules-L2 -L2 .dix : reglas de transferencia estructural para la traducción de L2 a L1 .
apertium-L1 -L2 .L1 .tsx : fichero de definición del desambiguador para L1 .
apertium-L1 -L2 .L2 .tsx : fichero de definición del desambiguador para L2 .
apertium-L1 -L2 .post-L1 .dix : diccionario de postgeneración para L1 (se aplica al traducir hacia la lengua L1 ).
135
136
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
apertium-L1 -L2 .post-L2 .dix : diccionario de postgeneración para L2 (se aplica al traducir hacia la lengua L2 ).
directorio L1 -tagger-data : contiene datos necesarios para el tagger de L1 (corpus, etc.)
directorio L2 -tagger-data : contiene datos necesarios para el tagger de L2 (corpus, etc.)
apertium-L1 -L2 hace referencia a la combinación lingüı́stica del traductor. Sus dos valores posibles actualmente son apertium-es-ca y
apertium-es-gl. De acuerdo con esta estructura, el fichero monolingüe
de catalán se llama apertium-es-ca.ca.dix, el fichero bilingüe español–gallego se llama apertium-es-gl.es-gl.dix y el fichero de reglas de transferencia estructural para la traducción de catalán a español se
llama apertium-es-ca.trules-ca-es.xml.
Los datos lingüı́sticos de que se dispone (datos de enero del 2006) para
los distintos pares de lenguas se resumen en el siguiente cuadro.
Traductor Apertium-es-ca
Diccionario monolingüe de español
11.800 entradas
Diccionario monolingüe de catalán
11.800 entradas
Diccionario bilingüe español–catalán
12.800 entradas (correspondencias es-ca)
Reglas de transferencia estructural de español a 44 reglas
catalán
Reglas de transferencia estructural de catalán a 58 reglas
español
Diccionario de postgeneración para el español 25 entradas y 5 paradigmas
Diccionario de postgeneración para el catalán
16 entradas y 57 paradigmas
Traductor Apertium-es-gl
Diccionario monolingüe de español
9.000 entradas
Diccionario monolingüe de gallego
8.600 entradas
Diccionario bilingüe español–gallego
8.500 entradas (correspondencias es-gl)
Reglas de transferencia estructural de español a 46 reglas
gallego
Reglas de transferencia estructural de gallego a 38 reglas
español
Diccionario de postgeneración para el español 36 entradas y 12 paradigmas
Diccionario de postgeneración para el gallego
74 entradas y 48 paradigmas
5.2. INTRODUCIR PALABRAS EN LOS DICCIONARIOS
5.2.
137
Introducir palabras en los diccionarios monolingües y bilingües
La adición de léxico a los diccionarios es seguramente la operación que
con más probabilidad realizarán quienes quieran ampliar o adaptar Apertium, más que añadir reglas de transferencia o de postgeneración.
A continuación se explican los aspectos más importantes que hay que
tener en cuenta a la hora de introducir palabras. Esta información es más
general que la ofrecida en el apartado de descripción de los diccionarios
(punto 3.1.2), aunque contiene información práctica que puede ser de gran
utilidad para quienes decidan llevar a cabo esta tarea.
Para añadir una palabra a Apertium hay que realizar tres entradas
en los diccionarios. Supongamos que está trabajando con el par español–
catalán. En este caso, deberá añadir:
1. una entrada en el diccionario monolingüe español: para que el traductor pueda analizar (”entender”) la palabra cuando la encuentre
en un texto, y la pueda generar al traducir esta palabra al español.
2. una entrada en el diccionario bilingüe: para que Apertium pueda
traducir esta palabra de una lengua a la otra.
3. una entrada en el diccionario monolingüe de catalán: para que el traductor pueda analizar (”entender”) la palabra cuando lo encuentre
en un texto, y la pueda generar al traducir esta palabra al catalán.
Deberá ir al directorio que contiene los diccionarios en XML (para el
par español–catalán, por ejemplo, es apertium-es-ca) y abrir con un
editor de texto o un editor de XML especializado los tres diccionarios mencionados: apertium-es-ca.es.dix, apertium-es-ca.es-ca.dix y
apertium-es-ca.ca.dix. Las entradas que deberá añadir en estos tres
diccionarios tienen una estructura similar.
Diccionario monolingüe (español)
Supongamos que desea añadir el adjetivo español cósmico, cuyo equivalente en catalán es còsmic. El primer paso es añadir esta palabra al diccionario monolingüe español.
Verá que un diccionario monolingüe tiene principalmente dos tipos de
datos: paradigmas (en la sección ”<pardefs>”del diccionario, cada uno
en un elemento <pardef>) y entradas léxicas (en la sección principal del
138
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
diccionario (<section>), cada una dentro de un elemento <e>. Las entradas léxicas se componen de un lema (es decir, la palabra que encontrarı́amos como entrada en un diccionario en papel) y de información gramatical; los paradigmas contienen los datos de flexión de todos los lemas
del diccionario. Para buscar una palabra concreta, puede buscar la cadena
lm="palabra" (lm de lema). Tenga en cuenta, sin embargo, que el elemento lm es opcional en los diccionarios y que es posible que algunos no
incluyan esta información.
Observe cómo son las entradas léxicas del diccionario monolingüe español, por ejemplo la entrada para el adjetivo bonito. Puede encontrarla
buscando la cadena lm="bonito":
<e lm="bonito">
<i>bonit</i>
<par n="absolut/o__n"/>
</e>
Para añadir una palabra, deberá crear una entrada con la misma estructura. La parte entre <i> e </i> contiene la parte inicial de la palabra que
es común a todas las formas flexionadas, y el elemento <par> indica cuál
es su paradigma de flexión. Por lo tanto, esta entrada significa que el adjetivo bonito se flexiona igual que el adjetivo absoluto con el mismo análisis
morfológico: las formas bonito, bonita, bonitos, bonitas son equivalentes a
las formas absoluto, absoluta, absolutos, absolutas y tienen el mismo análisis
morfológico: adj m sg, adj f sg, adj m pl y adj f pl respectivamente.
Primero debe decidir cuál es la categoria léxica de la palabra que desea
añadir: la palabra cósmico es un adjetivo, como bonito. A continuación, debe
encontrar el paradigma apropiado para este adjetivo. ¿Es el mismo que
el de bonito o absoluto? ¿Puede decir cósmico, cósmica, cósmicos, cósmicas?
Como la respuesta es afirmativa, ya tiene la información necesaria para
crear la entrada:
<e lm="cósmico">
<i>cósmic</i>
<par n="absolut/o__adj"/>
</e>
Si la palabra que desea añadir tiene un paradigma diferente, deberá buscarlo en el diccionario y asignarlo a la entrada. Hay dos maneras de buscar
un paradigma: mirando en la sección <pardefs> del diccionario, donde
están definidos todos los paradigmas, cada uno dentro de un elemento
5.2. INTRODUCIR PALABRAS EN LOS DICCIONARIOS
139
<pardef>, o bien buscando una palabra que pensemos que pueda existir en el diccionario y que tenga el mismo paradigma de inflexión que la
que queremos añadir. Por ejemplo, si desea añadir la palabra genoma, deberá encontrar un paradigma para un nombre de género masculino que
forme el plural añadiendo una -s. En los diccionarios actuales, se trata del
paradigma ”abismo n”. Por lo tanto, la entrada para esta nueva palabra
serı́a:
<e lm="genoma">
<i>genoma</i>
<par n="abismo__n"/>
</e>
En casos excepcionales será necesario crear un nuevo paradigma para
una palabra determinada. Para ello, observe la estructura de los demás paradigma y cree uno nuevo a partir de alguno que sea similar. Para obtener
una descripción más detallada de los paradigmas y de las entradas léxicas
de los diccionarios, consulte la sección 3.1.2.
Diccionario monolingüe (catalán)
Una vez añadida la palabra a un diccionario monolingüe, hay que hacer lo mismo en el otro diccionario monolingüe del par de traducción (en
el ejemplo actual, el diccionario monolingüe de catalán) aplicando la misma estructura. El resultado serı́a:
<e lm="còsmic">
<i>còsmi</i>
<par n="acadèmi/c__adj"/>
</e>
Diccionario monolingüe (gallego)
Si lo que quiere es mejorar los diccionarios XML para el par español–
gallego, deberá ir al directorio apertium-es-gl y abrir, con un editor
de texto o un editor XML especializado, los tres ficheros de diccionarios
apertium-es-gl.es.dix, apertium-es-gl.es-gl.dix y apertium-es-gl.gl.dix.
En este caso, una vez ha añadido la nueva palabra genoma al diccionario
monolingüe español (apertium-es-gl.es.dix), deberá añadir la palabra gallega equivalente xenoma al diccionario monolingüe gallego (apertium-es-gl.gl.dix),
es decir:
<e lm="xenoma">
<i>xenoma</i>
<par n="Xulio__n"/>
</e>
140
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
Diccionario bilingüe
El último paso es añadir la traducción al diccionario bilingüe.
Generalmente, un diccionario bilingüe no tiene paradigmas, sino sólo
lemas. Una entrada contiene únicamente el lema en ambos idiomas y el
primer sı́mbolo gramatical (la categorı́a léxica) de cada uno. Las entradas
tienen una parte izquierda (<l>) y una parte derecha (<r>), y un idioma
tiene que ocupar siempre la misma posición: en nuestro sistema, se ha
convenido que el español ocupe la parte izquierda, y el catalán y el gallego
la parte derecha.
Añadiendo el lema de ambas palabras, el sistema traducirá todas sus
formas flexionadas (puesto que los sı́mbolos gramaticales se copian desde
la palabra original a la palabra en lengua meta). Esto sólo dará resultado
si la palabra de origen y la palabra de destino son gramaticalmente equivalentes, es decir, si comparten exactamente los mismos sı́mbolos gramaticales para todas sus formas flexionadas. Como este es el caso del ejemplo
que nos ocupa, la entrada que hay que añadir al diccionario bilingüe es:
<e>
<p>
<l>cósmico<s n="adj"/></l>
<r>còsmic<s n="adj"/></r>
</p>
</e>
Esta entrada servirá para traducir todas las formas flexionadas, es decir, adj m sg, adj f sg, adj m pl y adj f pl. Sirve para ambas direcciones: de español a catalán y de catalán a español.
En el caso del par español–gallego, la siguiente entrada en el diccionario bilingüe español–gallego (apertium-es-gl.es-gl.dix) traducirá todas las formas flexionadas de las palabras equivalentes genoma/xenoma
en ambas direcciones:
<e>
<p>
<l>genoma<s n="n"/></l>
<r>xenoma<s n="n"/></r>
</p>
</e>
En caso de que el par de traducción no sea gramaticalmente equivalente (sus sı́mbolos gramaticales no sean exactamente los mismos), es necesario especificar todos los sı́mbolos gramaticales (en el mismo orden en que
5.2. INTRODUCIR PALABRAS EN LOS DICCIONARIOS
141
están especificados en los diccionarios monolingües) hasta llegar al sı́mbolo que cambia entre la forma léxica origen y la forma léxica destino. Por
ejemplo, el nombre español limón, de género masculino, se traduce al catalán por un nombre de género femenino, llimona. Por lo tanto, la entrada
en el diccionario bilingüe debe ser:
<e>
<p>
<l>limón<s n="n"/><s n="m"/></l>
<r>llimona<s n="n"/><s n="f"/></r>
</p>
</e>
Un caso más complicado es el que surge cuando, teniendo dos formas
léxicas con sı́mbolos gramaticales diferentes, la información gramatical de
la forma de la lengua origen no es suficiente para determinar el género
(masculino o femenino) o el número (singular o plural) de la forma de la
lengua destino. Ası́ sucede, por ejemplo, con el adjetivo español canadiense.
Su género es masculino–femenino puesto que es de invariable en género,
es decir, puede acompañar a nombres tanto masculinos como femeninos
(hombre canadiense, mujer canadiense. En catalán, en cambio, el adjetivo se
flexiona de manera diferente para el masculino y para el femenino (home
canadenc, dona canadenca). Ası́, al traducir de español a catalán no es posible saber, sin mirar el nombre al que acompaña, si el adjetivo español (mf )
tiene que traducirse como un adjetivo femenino o masculino en catalán.
En este caso se utiliza el sı́mbolo GD (de ”género por determinar”) en lugar del sı́mbolo de género. Será en el módulo de transferencia estructural
donde se determinará el género de la palabra mediante una regla de transferencia (en este caso concreto, una regla que detecte el género del nombre
precedente). El sı́mbolo GD debe utilizarse sólo para la traducción de español a catalán, y no viceversa, ya que en español el género será siempre
mf independientemente del género de la palabra original. En el diccionario bilingüe, habrá que añadir más de una entrada con restricciones de
dirección, puesto que es necesario indicar en qué dirección de traducción
el género queda sin determinar. Las entradas para este adjetivo deben ser
como sigue:
<e r="LR">
<p>
<l>canadiense<s n="adj"/><s n="mf"/></l>
<r>canadenc<s n="adj"/><s n="GD"/></r>
</p>
142
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
</e>
<e r="RL">
<p>
<l>canadiense<s n="adj"/><s n="mf"/></l>
<r>canadenc<s n="adj"/><s n="f"/></r>
</p>
</e>
<e r="RL">
<p>
<l>canadiense<s n="adj"/><s n="mf"/></l>
<r>canadenc<s n="adj"/><s n="m"/></r>
</p>
</e>
”LR”significa left to right (”de izquierda a derecha”) y ”RL”, right to left
(”de derecha a izquierda”). Puesto que el español está situado a la izquierda y el catalán a la derecha, el adjetivo será GD sólo en la traducción de
español a catalán (LR). Para la traducción RL hay que crear dos entradas,
una para el adjetivo en femenino y otra para el adjetivo en masculino.1
Este mismo principio se aplica cuando no es posible determinar el
número de la palabra destino por los mismos motivos que se acaban de
exponer. Por ejemplo, el nombre español rascacielos es invariable en número, es decir, tiene la misma forma para el singular y para el plural (un rascacielos, dos rascacielos). En catalán, el nombre tiene diferente flexión para el
singular y para el plurar (un gratacel, dos gratacels). En este caso, el sı́mbolo
utilizado es ”ND”(de ”número por determinar”) y las entradas para estos
lemas deben ser como sigue:
<e r="LR">
<p>
<l>rascacielos<s n="n"/><s n="m"/><s n="sp"/></l>
<r>gratacel<s n="n"/><s n="m"/><s n="ND"/></r>
</p>
</e>
<e r="RL">
<p>
<l>rascacielos<s n="n"/><s n="m"/><s n="sp"/></l>
<r>gratacel<s n="n"/><s n="m"/><s n="pl"/></r>
</p>
</e>
<e r="RL">
1
También se podrı́an agrupar usando un pequeño paradigma
5.2. INTRODUCIR PALABRAS EN LOS DICCIONARIOS
143
<p>
<l>rascacielos<s n="n"/><s n="m"/><s n="sp"/></l>
<r>gratacel<s n="n"/><s n="m"/><s n="sg"/></r>
</p>
</e>
Para obtener una descripción más detallada de este tipo de entradas,
consulte lapágina 40.
5.2.1.
Añadir restricciones de dirección
En el ejemplo anterior hemos visto el uso de restricciones de dirección
en las entradas con género o número por determinar (GD o ND). Estas restricciones también pueden utilizarse en otros casos.
Hay que tener en cuenta que la versión actual de Apertium sólo puede
proporcionar un único equivalente para cada forma léxica de la lengua origen, es decir, no realiza ningún tipo de desambiguación semántica.2 Cuando una forma léxica puede traducirse a la lengua meta de dos o más maneras diferentes, hay que escoger una (las más general, la más frecuente,
etc.). Puede indicarse al sistema que una forma sea analizada (.entendida”)
pero no generada, puesto que no es la traducción de ningún lema de la
otra lengua.
Veámoslo con un ejemplo. El nombre español muñeca puede traducirse al catalán por dos palabras diferentes dependiendo de su significado:
canell o nina. El contexto es el que decide cuál es la traducción correcta,
pero el sistema Apertium actual no puede tomar este tipo de decisiones.3
Por lo tanto, debe decidirse qué palabra será el equivalente para la traducción de español a catalán. Para la traducción catalán–español, ambos
lemas pueden traducirse como muñeca y no surge ningún problema. Todas estas circunstancias deben quedar reflejadas en las entradas bilingües
utilizando las restricciones de dirección (LR, ”de izquierda a derecha”, es
decir, es–ca, y RL, ”de derecha a izquierda”, es decir, ca–es). Si se decide traducir muñeca como canell en todos los casos, las entradas que deben
crearse en el diccionario bilingüe son:
2
El sistema realiza únicamente desambiguación categorial para las palabras homógrafas, es decir, para formas que pueden tener como análisis más de una forma léxica, como
ocurre con la forma vino en español, la cual puede ser tanto un sustantivo masculino como la forma pretérita del verbo venir. El desambiguador léxico categorial es el encargado
de deshacer este tipo de ambigüedad.
3
En el apartado 5.2.2 dedicado a la adición de multipalabras se explican maneras de
sortear este problema.
144
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
<e>
<p>
<l>muñeca<s n="n"/><s n="f"/></l>
<r>canell<s n="n"/><s n="m"/></r>
</p>
</e>
<e r="RL">
<p>
<l>muñeca<s n="n"/></l>
<r>nina<s n="n"/></r>
</p>
</e>
Con estas entradas, las direcciones de traducción serán las siguientes:
muñeca --> canell
muñeca <-- canell
muñeca <-- nina
(Observe también que hay un cambio de género entre muñeca y canell).
Es muy importante que una forma léxica no tenga dos traducciones en
la lengua meta, puesto que, de lo contrario, se producirı́a un error en el
proceso de traducción (véase la sección 5.5 sobre cómo pueden detectarse
y corregirse este y otros tipos de errores). Cuando una palabra puede traducirse a la lengua meta de dos maneras diferentes en todos los contextos,
hay que elegir una como equivalente de traducción y dejar la otra como
forma léxica analizable pero no generable, valiéndose de restricciones de
dirección como en el ejemplo anterior. Por ejemplo, como los lemas catalanes mot y paraula pueden traducirse ambos al español como palabra, las
entradas del diccionario bilingüe deberı́an ser como las siguientes:
<e>
<p>
<l>palabra<s n="n"/></l>
<r>paraula<s n="n"/></r>
</p>
</e>
<e r="RL">
<p>
<l>palabra<s n="n"/><s n="f"/></l>
<r>mot<s n="n"/><s n="m"/></r>
</p>
</e>
5.2. INTRODUCIR PALABRAS EN LOS DICCIONARIOS
145
de las que resultan las siguientes direcciones de traducción:
palabra --> paraula
palabra <-- paraula
palabra <-- mot
En algunos casos puede ser necesario especificar restricciones de dirección también en los diccionarios monolingües. Por ejemplo, las dos formas
verbales españolas cantaran y cantasen deben ser analizadas como lema
cantar, verbo, pretérito imperfecto de subjuntivo, 3a persona plural, pero
al traducir al español, debe decidirse e indicarse qué forma será la que se
generará. Los diccionarios monolingües se leen en dos direcciones según
su finalidad: para el análisis, la dirección de lectura es de izquierda a derecha; para la generación, de derecha a izquierda. Por lo tanto, una palabra que debe analizarse pero no generarse debe contener la restricción LR,
mientras que una que deba generarse pero no analizarse debe contener la
restricción RL.
El caso de cantaran o cantasen debe haberse tratado en los paradigmas
de flexión verbal y es poco probable que constituya un problema para alguien que esté ampliando un diccionario. En algunos otros casos puede ser
necesario introducir una restricción en las entradas léxicas del diccionario
monolingüe.
5.2.2.
Añadir multipalabras
Es posible crear entradas formadas por dos o más palabras si se considera que éstas forman una sola ünidad de traducción”. Las unidades
multipalabra pueden ser útiles también cuando se trata de seleccionar el
equivalente correcto de una palabra dentro de una expresión fija. Por ejemplo, la palabra española dirección puede traducirse al catalán de dos maneras: direcció (el sentido más general) y adreça (en el sentido de “dirección
postal”); si se añaden, por ejemplo, unidades multipalabra frecuentes como dirección general → direcció general y dirección postal → adreça postal se
pueden conseguir mejores traducciones en determinadas situaciones.
Las unidades multipalabra pueden clasificarse básicamente en dos categorı́as: multipalabras con flexión intercada y multipalabras sin flexión
intercalada.
5.2.2.1.
Multipalabras sin flexión intercalada
Son iguales a las entradas léxicas de una sola palabra, con la única diferencia de que debe inserirse el elemento <b> (que representa un espa-
146
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
cio en blanco) entre las palabras que forman la unidad. Ası́, si se quiere
añadir, por ejemplo, la multipalabra española hoy en dı́a, cuyo equivalente
en catalán es avui dia, las entradas que habrá que crear en los diferentes
diccionarios son:
Diccionario monolingüe de español:
<e lm="hoy en dı́a">
<i>hoy<b/>en<b/>dı́a</i>
<par n="ahora__adv"/>
</e>
Diccionario monolingüe de catalán:
<e lm="avui dia">
<i>avui<b/>dia</i>
<par n="ahir__adv"/>
</e>
Diccionario bilingüe español–catalán:
<e>
<p>
<l>hoy<b/>en<b/>dı́a<s n="adv"/></l>
<r>avui<b/>dia<s n="adv"/></r>
</p>
</e>
Para el par español–gallego, si desea añadir, por ejemplo, la multipalabra española manga por hombro, cuyo equivalente en gallego es sen xeito nin
modo, las entradas que hay que crear son las siguientes:
Diccionario monolingüe de español:
<e lm="manga por hombro">
<i>manga<b/>por<b/>hombro</i>
<par n="ahora__adv"/>
</e>
Diccionario monolingüe de gallego:
<e lm="sen xeito nin modo">
<i>sen<b/>xeito<b/>nin<b/>modo</i>
<par n="Deo_gratias__adv"/>
</e>
5.2. INTRODUCIR PALABRAS EN LOS DICCIONARIOS
147
Diccionario bilingüe español–gallego:
<e>
<p>
<l>manga<b/>por<b/>hombro<s n="adv"/></l>
<r>sen<b/>xeito<b/>nin<b/>modo<s n="adv"/></r>
</p>
</e>
5.2.2.2. Breve introducción a los paradigmas
Los paradigmas de los ejemplos anteriores, como los adverbios, no tienen flexión, contienen sólo el sı́mbolo gramatical de la forma léxica, como
se puede ver a continuación:
<pardef n="ahora__adv">
<e>
<p>
<l/>
<r><s n="adv"/></r>
</p>
</e>
</pardef>
Los paradigmas se construyen del mismo modo que una entrada léxica. Hasta ahora, hemos visto entradas léxicas en que la parte invariable
del lema se coloca entre <i> </i>:
<e lm="cósmico">
<i>cósmic</i>
<par n="absolut/o__adj"/>
</e>
Ahora bien, es posible expresar lo mismo mediante un par de cadenas: una cadena izquierda <l> y una cadena derecha <r> dentro de un
elemento <p>:
<e lm="cósmico">
<p>
<l>cósmic</l>
<r>cósmic</r>
</p>
<par n="absolut/o__adj"/>
</e>
148
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
Las dos entradas son equivalentes. El elemento <i> se utiliza porque
permite obtener entradas más simples y compactas, y puede emplearse
cuando la parte izquierda y la parte derecha del par de cadenas son idénticas. Como ya se ha indicado, los diccionarios monolingües se leen LR para
el análisis de un texto y RL para la generación. Por ello, cuando hay alguna
diferencia entre la cadena analizada y la cadena generada (cosa que no sucede normalmente) la entrada no puede escribirse utilizando la <i>. Esto
es lo que sucede con los paradigmas, en los cuales las cadenas izquierda y
derecha no son nunca idénticas, puesto que la parte derecha debe contener
los sı́mbolos gramaticales que circularán a través de todos los módulos del
sistema.
5.2.2.3. Multipalabras con flexión intercalada
Consisten en una palabra con flexión (en general un verbo) seguida
de una o más palabras invariables. En las entradas correspondientes debe especificarse el paradigma de flexión justo detrás de la palabra que se
flexiona, mientras que la parte invariable debe quedar incluida en un elemento <g> (de grupo) en la cadena derecha. Los blancos entre palabras
se indican, como en el caso anterior, mediante la colocación del elemento
<b>. Su estructura puede observarse en el siguiente ejemplo, correspondiente a la multipalabra española echar de menos, que se traduce al catalán
por trobar a faltar:
Diccionario monolingüe de español:
<e lm="echar de menos">
<i>ech</i>
<par n="aspir/ar__vblex"/>
<p>
<l><b/>de<b/>menos</l>
<r><g><b/>de<b/>menos</g></r>
</p>
</e>
Diccionario monolingüe de catalán:
<e lm="trobar a faltar">
<i>trob</i>
<par n="abander/ar__vblex"/>
<p>
<l><b/>a<b/>faltar</l>
5.2. INTRODUCIR PALABRAS EN LOS DICCIONARIOS
149
<r><g><b/>a<b/>faltar</g></r>
</p>
</e>
Diccionario bilingüe español–catalán:
<e>
<p>
<l>echar<g><b/>de<b/>menos</g><s n="vblex"/></l>
<r>trobar<g><b/>a<b/>faltar</g><s n="vblex"/></r>
</p>
</e>
Obsérvese cómo el sı́mbolo gramatical se agrega al final, tras el grupo
marcado con <g>.
Puede suceder también que un lema sea una multipalabra de este tipo en un idioma, mientras que en el otro idioma sea una única palabra.
En este caso, en el diccionario bilingüe, la multipalabra contendrá el elemento <g> y la palabra simple no. En los diccionarios monolingües, se
creará cada entrada de acuerdo con el tipo de lema. Esto se ilustra con el
siguiente ejemplo, correspondiente a la multipalabra española darse cuenta, cuya equivalencia en catalán es el verbo adonar-se:4
Diccionario monolingüe de español:
<e lm="darse cuenta">
<i>d</i>
<par n="d/ar__vblex"/>
<p>
<l><b/>cuenta</l>
<r><g><b/>cuenta</g></r>
</p>
</e>
Diccionario monolingüe de catalán:
4
El verbo adonar-se es considerado una palabra simple, pues la colocación de los pronombres enclı́ticos es tratada dentro del paradigma de flexión de los verbos (para todos
los idiomas de Apertium); ası́, no es necesario especificarlos en las entradas léxicas. La
correcta colocación de los pronombres clı́ticos es una de las principales razones de la
utilización de las etiquetas <g>... </g> alrededor de la parte invariable de los verbos
multipalabra.
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
150
<e lm="adonar-se">
<i>adon</i>
<par n="abander/ar__vblex"/>
</e>
Diccionario bilingüe español–catalán:
<e>
<p>
<l>dar<g><b/>cuenta</g><s n="vblex"/></l>
<r>adonar<s n="vblex"/></r>
</p>
</e>
Los mismos principios y acciones descritos para las entradas básicas
(cambio de género y número, restricciones de dirección, etc.) se aplican
también a todos los tipos de multipalabras. Para obtener una descripción
más detallada de las unidades multipalabra, consulte la página 44.
5.2.3.
Colaborar en la mejora de datos léxicos
Si ha añadido satisfactoriamente datos léxicos de propósito general para cualquiera de los pares lingüı́sticos de Apertium, considere la opción de
facilitarlos a los desarrolladores del proyecto para que podamos ofrecer
una mejor herramienta a los usuarios. Puede enviar los datos léxicos por
correo electrónico (en tres ficheros XML, uno para cada diccionario monolingüe y uno para el diccionario bilingüe) a las direcciones siguientes:
Datos español–catalán
Mireia Ginestı́: [email protected]
Datos español–portugués Carme Armentano: [email protected]
Datos español–gallego
Xavier Gómez-Guinovart: [email protected]
Si cree que va a contribuir de manera más decisiva al proyecto, puede unirse al grupo de desarrollo a través de www.sourceforge.net. Si no
dispone de cuenta en Sourceforge, primero deberá crearse una; a continuación, escriba a Mikel L. Forcada ([email protected]) o a Sergio Ortiz ([email protected]),
o bien a Xavier Gómez Guinovart si está interesado en el par español–
gallego, explicando brevemente sus motivaciones y experiencia para unirse al proyecto. La forma usual de aportar datos es mediante CVS; como
miembro del proyecto, podrá hacer commit para subir los cambios a los
diccionarios directamente.
5.3. INTRODUCIR REGLAS DE TRANSFERENCIA
151
La adición de contribuciones léxicas se ha simplificado recientemente a
través de formularios web en http://xixona.dlsi.ua.es/prototype/
webform/, de manera que los colaboradores ocasionales no tienen que
manejar ficheros XML.
Tenga en cuenta que los datos que aporte al proyecto serán distribuidos
gratuitamente bajo la licencia que corresponda al producto (licencia GNU
GPL o Creative Commons 2.5 Atribución-NoComercial-LicenciarIgual, según
se indique). Asegúrese de que los datos que entregue no estén afectados
por ningún tipo de licencia que pueda ser incompatible con las licencias
utilizadas en este proyecto. No se creará ningún tipo de acuerdo o contrato
entre usted y los desarrolladores. Si tiene alguna duda, o si tiene previsto hacer una contribución de gran envergadura, póngase en contacto con
Mikel L. Forcada.
5.3.
Introducir reglas de transferencia estructural
El contenido de este capı́tulo repite parcialmente información ya expuesta en el apartado de descripción del módulo de transferencia estructural (punto 3.5), aunque aquı́ se describen las reglas de una manera más
general y práctica, orientada a quienes deseen una primera aproximación
a su funcionamiento.
Las reglas de transferencia estructural llevan a cabo transformaciones
en el texto analizado y desambiguado, que son necesarias debido a divergencias gramaticales, sintácticas y léxicas entre los dos idiomas implicados (cambios de género y de número para garantizar la concordancia en
la lengua meta, reordenamientos de palabras, cambios de preposiciones,
etc.). Las reglas detectan patrones (secuencias) de formas léxicas de la lengua origen y les aplican las transformaciones correspondientes. El módulo
detecta los patrones de izquerda a derecha y recortando el segmento concordante más largo (left-to-right, longest-match): Por ejemplo, el sintagma
el gato verde será detectado y procesado por la regla para determinante–
nombre–adjetivo y no por la regla para determinante–nombre, puesto que el
primer patrón es más largo. Si dos patrones tienen la misma longitud, la
regla que se aplica es la definida en primer lugar.
El módulo de transferencia estructural (generado a partir del fichero
de reglas de transferencia estructural) llama, durante el procesamiento, al
módulo de transferencia léxica (generado a partir del diccionario bilingüe)
para determinar los equivalentes en lengua de meta de las formas léxicas
152
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
en lengua origen.
Las reglas de transferencia estructural están guardadas en un fichero
XML, uno para cada dirección de traducción (por ejemplo, para la traducción de español a catalán, el fichero se llama apertium-es-ca.trules-es-ca.xml).
Deberá editar este fichero para añadir o modificar las reglas de transferencia.
Las reglas tienen un patrón y una acción. El patrón indica qué secuencias de formas léxicas tienen que ser detectadas y procesadas. La acción describe las verificaciones y transformaciones que deben realizarse
en ellas. Algunas operaciones de transformación usuales (como las operaciones de concordancia de género y número) están definidas dentro de
una macroinstrucción que se llama dentro de la regla. Al final de la parte
de acción de cada regla, se envı́an las formas léxicas resultantes en la lengua meta para que puedan ser procesadas por los módulos posteriores del
sistema de traducción.
Un fichero de reglas de transferencia contiene cuatro secciones con definiciones de elementos utilizados en las reglas, y una quinta sección en
la que se definen las reglas propiamente dichas. Las secciones son las siguientes:
<section-def-cats>: Esta sección contiene la definición de las
categorı́as que se utilizarán en los patrones de las reglas (es decir,
los tipos de formas léxicas que serán detectados por una regla determinada). Para la regla que se presenta más abajo, es necesario haber
definido aquı́ las categorı́as det y nom (determinante y nombre). Las
categorı́as se definen especificando los sı́mbolos gramaticales que
tienen las formas léxicas que se quiere incluir. Un asterisco indica que
los sı́mbolos gramaticales especificados van seguidos de uno o más
sı́mbolos en las formas léxicas correspondientes. A continuación se
presenta la definición de la categorı́a det, que agrupa determinantes
y predeterminantes6 en una misma categorı́a pues para el módulo de
transferencia desempeñan un papel similar:
<def-cat n="det">
<cat-item tags="det.*"/>
<cat-item tags="predet.*"/>
</def-cat>
También es posible definir definir una categorı́a para un lema determinado, como la siguiente para la preposición en:
6
como el español todo, toda, todos, todas
5.3. INTRODUCIR REGLAS DE TRANSFERENCIA
153
<def-cat n="en">
<cat-item lemma="en" tags="pr"/>
</def-cat>
<section-def-attrs>: Esta sección contiene la definición de los
atributos que se utilizarán dentro de las reglas, en la parte de acción.
Se necesitan atributos para las categorı́as definidas en la sección anterior si van a utilizarse en la parte de acción de una regla (para realizar
verificaciones en ellas o para enviarlas al final de la regla), ası́ como
para otros atributos necesarios en la regla (como el género o el número). Los atributos se definen especificando los sı́mbolos gramaticales
correspondientes y no pueden llevar asteriscos; su nombre tiene que
ser unı́voco. A continuación se muestran las definiciones para los
atributos a det (para determinantes) y gen (para el género):
<def-attr n="a_det">
<attr-item tags="det.def"/>
<attr-item tags="det.ind"/>
<attr-item tags="det.dem"/>
<attr-item tags="det.pos"/>
<attr-item tags="predet"/>
</def-attr>
<def-attr n="gen">
<attr-item tags="m"/>
<attr-item tags="f"/>
<attr-item tags="mf"/>
<attr-item tags="nt"/>
<attr-item tags="GD"/>
</def-attr>
<section-def-vars>: Esta sección contiene la definición de las
variables utilizadas en las reglas.
<def-var n="interrogativa"/>
<section-def-macros>: Aquı́ se definen las macroinstrucciones,
que contienen secuencias de código utilizado con frecuencia dentro
de las reglas; esto evita tener que escribir repetidamente las mismas
acciones al crear las reglas. Hay macroinstrucciones, por ejemplo, para operaciones de concordancia de género y número.
154
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
<section-def-rules>: Esta es la sección en la que se escriben las
reglas de transferencia estructural.
A continuación se presenta como ejemplo una regla que detecta la secuencia determinante–nombre:
<rule>
<pattern>
<pattern-item n="det"/>
<pattern-item n="nom"/>
</pattern>
<action>
<call-macro n="f_concord2">
<with-param pos="2"/>
<with-param pos="1"/>
</call-macro>
<out>
<lu>
<clip pos="1" side="tl" part="whole"/>
</lu>
<b pos="1"/>
<lu>
<clip pos="2" side="tl" part="whole"/>
</lu>
</out>
</action>
</rule>
Una parte de la acción ejecutada en este patrón está especificada dentro de la macroinstrucción f concord2, que está definida en la sección
<section-def-macros>. Esta macroinstrucción realiza operaciones de
concordancia de género y de número: si se produce un cambio de género
o número entre la lengua origen y la lengua meta (en el nombre), se cambia el género o el número del determinante de acuerdo con ello; además,
si el género o el número son indeterminados (GD o ND7 ), el nombre recibe el valor correcto de género o número aportado por el determinante
que le precede. En Apertium es–ca, es–gl y es–pt, se han definido macroinstrucciones de concordancia para una, dos, tres o cuatro formas léxicas
(f concord1, f concord2, f concord3, f concord4). Cuando se llama una macroinstrucción en una regla, debe indicarse cuál es la forma
léxica principal (la que tiene más peso en la determinación de género o
7
Véanse las páginas 42 o 141
5.3. INTRODUCIR REGLAS DE TRANSFERENCIA
155
número de las demás formas léxicas) y qué otras formas léxicas del patrón
tienen que incluirse en las operaciones de concordancia, en orden de importancia. Esto se realiza con el elemento <with-param pos=/>. En la
regla precedente, la forma léxica principal es el nombre (posición ”2.en el
patrón) y la segunda es el determinante (posición ”1.en el patrón).
Tras las acciones pertinentes, se envı́an las formas léxicas resultantes,
dentro del elemento <out>. Cada forma léxica se define mediante un
<clip>, cuyos atributos significan lo siguiente:
- pos: hace referencia a la posición de la forma léxica en el patrón; 1
representa la primera forma léxica (el determinante) y 2 la seguna (el
nombre).
- side: indica si la forma léxica está en lengua origen (sl) o en lengua
meta (tl). Naturalmente, al final de la regla las palabras se envı́an
siempre en la lengua meta; las formas léxicas en lengua origen pueden necesitarse dentro de una regla para evaluar sus atributos o caracterı́sticas.
- part: indica qué parte de la forma léxica incluye el clip. Pueden
utilizarse algunos valores predefinidos:
- whole: la forma léxica completa (lema más sı́mbolos gramaticales). Se utiliza sólo al enviar la forma léxica (dentro de un
elemento <out>).
- lem: el lema de la forma léxica
- lemh: la cabeza del lema de una multipalabra con flexión intercalada (véase el apartado 5.2.2 de este capı́tulo, o bien la página 44 si desea una explicación más detallada)
- lemq: la cola del lema de una multipalabra con flexión intercalada
A parte de estos valores predefinidos, puede utilizarse cualquiera de
los atributos definidos en la sección <section-def-attrs> (como
gen o a det).
Los valores lemh y lemq se utilizan al enviar multipalabras con flexión intercalada para poder colocar la cabeza y la cola del lema en la
posición correcta, puesto que el módulo previo desplazó la cola justo
después de la cabeza del lema por varios motivos. En la práctica, en
nuestro sistema, esto significa que para enviar verbos hay que utilizar estos valores en lugar de whole. Esto se debe a que, en nuestros
156
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
diccionarios, las multipalabras con flexión intercalada son siempre
verbos y, si se utiliza el valor whole al enviarlos al final de una regla, la multipalabra quedarı́a mal formada (la cabeza y la cola del
lema no tendrı́an la posición correcta y la multipalabra no podrı́a
generarse en el generador).
Según lo dicho, pues, una regla que contenga un verbo en el patrón
debe enviar las formas léxicas como en estos dos ejemplos:
<rule>
<pattern>
<pattern-item n="verb"/>
</pattern>
<action>
<out>
<lu>
<clip pos="1" side="tl"
<clip pos="1" side="tl"
<clip pos="1" side="tl"
<clip pos="1" side="tl"
<clip pos="1" side="tl"
<clip pos="1" side="tl"
<clip pos="1" side="tl"
</lu>
</out>
</action>
</rule>
part="lemh"/>
part="a_verb"/>
part="temps"/>
part="persona"/>
part="gen"/>
part="nbr"/>
part="lemq"/>
<rule>
<pattern>
<pattern-item n="verb"/>
<pattern-item n="prnenc"/>
</pattern>
<action>
<out>
<mlu>
<lu>
<clip pos="1" side="tl"
<clip pos="1" side="tl"
<clip pos="1" side="tl"
<clip pos="1" side="tl"
<clip pos="1" side="tl"
</lu>
part="lemh"/>
part="a_verb"/>
part="temps"/>
part="persona"/>
part="nbr"/>
5.3. INTRODUCIR REGLAS DE TRANSFERENCIA
<lu>
<clip
<clip
<clip
<clip
<clip
<clip
</lu>
</mlu>
</out>
</action>
</rule>
pos="2"
pos="2"
pos="2"
pos="2"
pos="2"
pos="1"
side="tl"
side="tl"
side="tl"
side="tl"
side="tl"
side="tl"
157
part="lem"/>
part="a_prnenc"/>
part="persona"/>
part="gen"/>
part="nbr"/>
part="lemq"/>
La primera regla detecta un verbo y coloca la cola en la posición correcta, después de todos los sı́mbolos gramaticales. La unidad léxica se envı́a
especificando sus atributos por separado: cabeza del lema, categorı́a léxica
(verbo), tiempo, persona, género (para los participios), número y cola del
lema.
La segunda regla detecta un verbo seguido de un pronombre enclı́tico
y envı́a dos formas léxicas especificando también sus atributos por separado; la primera unidad léxica se compone de: cabeza del lema, categorı́a
léxica (verbo), tiempo, persona y número; la segunda unidad léxica se
compone de: lema, categorı́a léxica (pronombre enclı́tico) , persona, género, número y cola del lema (de la primera unidad léxica). De este modo, la
cola se coloca después del pronombre enclı́tico. Las dos unidades léxicas
(verbo y pronombre enclı́tico) se envı́an dentro de un elemento <mlu>,
puesto que tienen que llegar al generador morfológico como unidad multiléxica.
Teniendo en cuenta todo lo que se ha explicado, para añadir una regla
de transferencia deben seguirse los pasos siguientes:
1. Especificar el patrón que se quiere detectar. Téngase presente que las
palabras sólo son procesadas una vez por las reglas, y que las reglas
se aplican de izquierda a derecha y escogiendo el segmento concordante más largo. Por ejemplo, supongamos que tenemos un fichero
de reglas de transferencia con sólo dos reglas, una para el patrón
determinante–nombre y otra para el patrón nombre–adjetivo. El sintagma español el valle verde serı́a detectado y procesado por la primera
regla, no por la segunda. Si queremos que las tres palabras sean procesadas por una misma regla, deberemos añadir una regla para el
patrón determinante - nombre - adjetivo
158
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
2. Describir las operaciones que deben realizarse sobre el patrón. En los
sistemas Apertium es-ca, es-gl y es-pt, las operaciones normales de concordancia (de género y número) son fáciles de especificar
utilizando una macroinstrucción. Para realizar otras operaciones hay
que utilizar elementos del lenguaje más complicados, que están explicados con detalle en la sección 3.5.4.
3. Enviar las unidades léxicas del patrón en la lengua meta dentro de
un elemento <out>. Cada unidad léxica debe estar dentro de un elemento <lu>. Si dos o más unidades léxicas deben ser generadas como una unidad multiléxica (sólo para pronombres enclı́ticos en los
pares de lenguas actuales), deben estar agrupadas dentro de un elemento <mlu>.
Todas las palabras que sean detectadas por la regla (que son parte
del patrón) deben enviarse al final de la regla para que el módulo
siguiente (el generador) las reciba. Si una unidad léxica es detectada por un patrón y no se incluye dentro del elemento <out>, no se
generará.
5.4.
Añadir datos para el desambiguador léxico
categorial
La información lingüı́stica que necesita el desambiguador léxico categorial para desambiguar un texto proviene básicamente de dos fuentes: del fichero de definición del desambiguador y de corpus. Los ficheros
de definición del desambiguador se encuentran en el directorio de datos
lingüı́sticos y su nombre tiene la estructura apertium-L1 -L2 .L1 .tsx y
apertium-L1 -L2 .L2 .tsx, mientras que los corpus se encuentran en los
directorios L1 -tagger-data y L2 -tagger-data que están contenidos
en el directorio anterior.
Los ficheros de definición del desambiguador contienen la definición de las
etiquetas gruesas (o categorı́as) que utiliza el desambiguador durante su
entrenamiento y al desambiguar un texto, ası́ como restricciones de ocurrencia de etiquetas que ayudan a obtener mejores probabilidades para la
desambiguación. En el apartado 3.2 se describen en detalle sus caracterı́sticas.
Los corpus que deben encontrarse en el directorio LAN G-tagger-data
son diferentes según si el entrenamiento del desambiguador se realiza de
forma supervisada (con texto desambiguado a mano) o no supervisada
5.4. AÑADIR DATOS AL DESAMBIGUADOR LÉXICO
159
(sin texto desambiguado a mano):
para el entrenamiento de forma supervisada se necesitan los ficheros (para español): es.tagged.txt, es.untagged, es.tagged,
es.dic.
para el entrenamiento de forma no supervisada se necesitan los ficheros (para español): es.crp.txt, es.crp, es.dic
Las caracterı́sticas de estos ficheros son las siguientes:
es.tagged.txt: Un corpus español en formato de texto llano.
es.untagged: El corpus es.tagged.txt analizado morfológicamente, es decir, procesado por el desformateador de texto y el analizador morfológico (corpus creado automáticamente).
es.tagged: El corpus anterior desambiguado manualmente.
es.crp.txt: Un corpus grande (cientos de miles de palabras) utilizado cuando se entrena el desambiguador de forma no supervisada
mediante el algoritmo de maximización de la esperanza matemática.
es.crp: El corpus anterior procesado consecutivamente por el desformateador de texto y el analizador morfológico (corpus creado automáticamente).
es.dic: Fichero creado a partir del diccionario monolingüe de español *.es.dix, mediante las herramientas lt-expand y apertium-filter-ambiguity, que expanden el diccionario y filtran
las clases de ambigüedad, de modo que el fichero contenga todas
las formas distintas que el etiquetador definido mediante el archivo *.es.tsx identifica como clases de ambigüedad diferentes, es
decir, qué categorı́as léxicas pueden ser homógrafas (fichero creado
automáticamente).
Al bajarse el traductor Apertium de Sourceforge (http://apertium.
sourceforge.net/), si el desambiguador ha sido entrenado de forma
supervisada es probable que se bajen los ficheros necesarios para este tipo de entrenamiento, es.tagged y es.tagged.txt (para español). Los
demás ficheros requeridos son generados automáticamente al ejecutarse
el entrenamiento. Si el desambiguador ha sido entrenado de forma no supervisada, no se bajará ningún corpus pues los ficheros necesarios para
160
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
entrenar de esta forma son de enorme tamaño. En caso de que el usuario
desee reentrenar el traductor de este modo, deberá recolectar un corpus
de gran tamaño para ello y ponerle el nombre es.crp.txt. Los demás
ficheros requeridos son generados automáticamente al ejecutarse el entrenamiento.
De todos modos, el traductor Apertium vienen con todos los datos necesarios para que el desambiguador funcione correctamente. No es necesario entrenar el desambiguador para utilizar Apertium. Puede ser necesario realizar un reentrenamiento en caso de que se hayan realizado grandes
cambios en los diccionarios o se haya modificado el fichero de definición
del desambiguador.
Ası́ pues, los datos del desambiguador se pueden modificar de dos
maneras:
1. Modificar el fichero de definición del desambiguador. Se pueden añadir,
modificar o suprimir etiquetas gruesas si se considera que una nueva categorı́a serı́a útil para la desambiguación o que la modificación
de una categorı́a comportarı́a mejoras. También pueden añadirse restricciones (por ejemplo, se puede prohibir la secuencia determinante–
determinante en un idioma si se trata de una combinación imposible
o poco probable y con ello puede mejorarse la desambiguación de
ciertas palabras homógrafas).
2. Modificar los corpus utilizados para entrenar el desambiguador. Puede modificarse el texto desambiguado a mano (es.tagged para español) para corregir algunas etiquetas mal elegidas. También pueden
añadirse frases a este texto (ası́ como el corpus es.tagged.txt,
usado para generar automáticamente el corpus es.untagged) para
dar más información al desambiguador, puesto que es posible que
la mala desambiguación de ciertas categorias de palabras se deba a
poca presencia o inexistencia en los corpus de entrenamiento.
Para llevar a cabo el reentrenamiento, existen dos comandos:
para entrenar de forma supervisada, debe escribirse, en el directorio
en el que se encuentren los datos lingüı́sticos (ejemplo para es–ca):
make -f es-ca-supervised.make
para entrenar de forma no supervisada, debe escribirse, en el directorio en el que se encuentren los datos lingüı́sticos (ejemplo para es–ca):
make -f es-ca-unsupervised.make
En ambos casos se generarán automáticamente los ficheros previstos.
5.5. DETECCIÓN DE ERRORES
5.5.
161
Detección de errores
Es fácil cometer errores al añadir nuevas palabras o reglas de transferencia al sistema Apertium.
Por un lado, es posible que, al compilar los ficheros nuevos, el sistema
muestre un mensaje de error. En este caso se tratará muy probablemente
de un error formal (una etiqueta XML que falta, una etiqueta no permitida en un determinado contexto, etc.). Sólo hay que ir al número de lı́nea
indicado en el mensaje de error, corregirlo y compilar de nuevo. Por otro
lado, hay otros tipos de errores que no se detectan al compilar pero que
pueden provocar una mala traducción o la traducción de una palabra por
una cadena de texto incomprensible. Éstos son errores lingüı́sticos, que
pueden detectarse y corregirse con la ayuda de la información ofrecida en
este capı́tulo. La siguiente información está dirigida a los usuarios de Linux, puesto que por el momento Apertium funciona únicamente con este
sistema operativo.8
5.5.1.
Control de las marcas de error
Cuando el sistema tiene algún problema para traducir una o más palabras del texto en lengua origen, en el modo de funcionamiento por defecto
se muestra la palabra problemática acompañada de un sı́mbolo que indica
que se ha producido algun error. El significado de los diferentes sı́mbolos
es el siguiente:
’@’: El problema se ha producido en el módulo de transferencia léxica, que no puede traducir la forma léxica (el diccionario bilingüe no
la contiene)
’#’: El problema se ha producido en el generador, que no puede generar una forma superficial a partir de la forma léxica (el diccionario
morfológico no la contiene en la dirección de generación)
’/’: Este sı́mbolo separa dos o más formas superficiales ofrecidas por
el generador. El problema, por lo tanto, está en el diccionario monolingüe de la lengua meta, que contiene, en la dirección de generación,
dos formas superficiales para una forma léxica, cuando deberı́a contener sólo una.
8
Existen en http://apertium.org paquetes experimentales para Windows con los
datos lingüı́sticos fijos (binarios no modificables).
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
162
El módulo de generación tiene tres modos de funcionamiento, con los
cuales podemos elegir la forma en que se mostrarán los errores en el resultado final. Los tres parámetros que pueden utilizarse son los siguientes:
-n : no se visualizan ni los sı́mbolos de error ni el sı́mbolo de palabra
desconocida, ası́ como ninguna etiqueta morfológica
-g : se visualizan los sı́mbolos de error y el sı́mbolo de palabra desconocida (funcionamiento por defecto)
-d : se visualizan los sı́mbolos de error y el de palabra desconocida,
además de las etiquetas morfológicas de las formas léxicas en las que
se ha producido el error.
Según el tipo de usuario y la finalidad de la traducción, es más conveniente utilizar una u otra opción. La primera opción es la más adecuada
cuando no se desea que signos ajenos al texto interfieran en la lectura de la
traducción. La segunda opción es útil cuando el usuario quiere que el sistema le muestre cuándo ha habido algún problema en la traducción (errores o palabras desconocidas) para poder posteditarla con más facilidad. La
tercera opción es ideal para los desarrolladores lingüı́sticos de Apertium,
puesto que muestra toda la información lingüı́stica de las formas que han
sufrido errores.
Utilizando los sı́mbolos de error visualizados por el sistema, se puede hacer una comprobación exhaustiva de los diccionarios de un par de
lenguas determinado, para detectar y corregir todos los errores que contienen; la forma de hacerlo se explica en el apartado 5.5.4.
5.5.2.
Salida de los diferentes módulos de Apertium
A veces es difı́cil localizar el origen de un error determinado. En este
caso es útil poder ver la salida de cada uno de los módulos. Como todos los
datos procesados por el sistema, desde el texto original al texto traducido,
circulan entre los módulos del sistema en formato de texto, es posible detener el flujo de texto en cualquier punto y examinar la entrada o la salida
de un módulo determinado.
Utilizando una estructura de tuberı́a y los comandos echo o cat, se
puede enviar texto a través de uno o varios módulos para detectar el motivo del error. A continuación se explica cómo hacerlo. El usuario debe
situarse en el directorio en que se guardan los datos lingüı́sticos y escribir
los comandos mostrados.
5.5. DETECCIÓN DE ERRORES
5.5.2.1.
163
La salida del analizador morfológico
Para saber cómo el traductor analiza una palabra, escriba lo siguiente
en el terminal (ejemplo para la palabra catalana sabates):
echo "sabates" | apertium-destxt | lt-proc ca-es.automorf.bin
Puede sustituirse ca-es por la dirección de traducción que se desea
comprobar.
La salida de Apertium deberı́a ser:
ˆsabates/sabata<n><f><pl>$ˆ./.<sent>$[][]
La estructura de la cadena es ˆpalabra/lema<análisis morfológico >$.
La etiqueta <sent> corresponde al análisis del punto, ya que el sistema
representa cada fin de frase como un punto, tanto si aparece explı́citamente en el texto como si no.
El análisis de una palabra desconocida es (prescindiendo de la información del final de frase):
ˆgenoma/*genoma$
y el análisis de una palabra ambigua:
ˆcasa/casa<n><f><sg>/casar<vblex><pri><p3><sg>/casar<vblex><imp><p2><sg>$
Cada forma léxica (lema más análisis morfológico) es presentada como
análisis posible de la palabra casa.
5.5.2.2.
La salida del desambiguador
Para saber cuál es la salida que da el desambiguador de un texto, escriba lo siguiente en el terminal (ejemplo para la dirección catalán – español):
echo "sabates" | apertium-destxt | lt-proc ca-es.automorf.bin
|apertium-tagger -g ca-es.prob
La salida será:
ˆsabata<n><f><pl>$ˆ./.<sent>$[][]
La salida de una palabra ambigua será igual que esta, puesto que el
desambiguador elige una forma léxica de entre todas las posibles. Por lo
tanto, la salida para la palabra casa en catalán será, por ejemplo (según el
contexto):
ˆcasa<n><f><sg>$ˆ.<sent>$[][]
164
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
5.5.2.3. La salida del módulo pretransfer
Este módulo aplica algunos cambios a las multipalabras (desplaza la
cola del lema de una multipalabra con flexión intercalada justo detrás de
la cabeza del lema). Para conocer su salida, escriba:
echo "sabates" | apertium-destxt | lt-proc ca-es.automorf.bin
|apertium-tagger -g ca-es.prob | apertium-pretransfer
Como sabates no es una multipalabra este módulo no altera la entrada.
5.5.2.4. La salida del módulo de transferencia estructural
Para saber cómo se traduce a la lengua meta una palabra o un grupo de
palabras y cómo lo procesan las reglas de transferencia estructural, escriba
lo siguiente en el terminal:
echo "sabates" | apertium-destxt | lt-proc ca-es.automorf.bin
|apertium-tagger -g ca-es.prob | apertium-pretransfer
| ./ca-es.transfer ca-es.autobil.bin
La salida para esta palabra serı́a:
ˆzapato<n><m><pl>$ˆ.<sent>$[][]
Analizar cómo una palabra o frase sale de este módulo puede ayudar
a detectar errores en el diccionario bilingüe o en las reglas de transferencia
estructural. Los errores más comunes debidos al diccionario bilingüe son:
la existencia de dos equivalentes para una misma forma léxica de la lengua
origen, o una asignación incorrecta de sı́mbolos morfológicos. Los errores
debidos a las reglas de transferencia estructural pueden ser muy variados
ya que dependen de las acciones realizadas por las reglas.
5.5.2.5. La salida del generador morfológico
Para saber cómo el sistema genera una palabra, escriba lo siguiente en
el terminal:
echo "sabates" | apertium-destxt | lt-proc ca-es.automorf.bin
|apertium-tagger -g ca-es.prob | apertium-pretransfer
| ./ca-es.transfer ca-es.autobil.bin | ltproc -g ca-es.autogen.bin
5.5. DETECCIÓN DE ERRORES
165
Con este comando se pueden detectar errores de generación causados
por una entrada incorrecta en el diccionario monolingüe de la lengua meta
o por divergencias entre la salida del diccionario bilingüe (la salida del
módulo anterior) y la entrada en el diccionario monolingüe.
La salida correcta para la entrada sabates serı́a:
zapatos.[][]
Aquı́ ya no aparecen los sı́mbolos morfológicos y la palabra aparece
flexionada.
5.5.2.6.
La salida del postgenerador
No es muy usual que se produzcan errores debido al postgenerador, ya
que generalmente el diccionario de postgeneración es de pequeño tamaño
y raras veces se modifica una vez añadidas las combinaciones más usuales,
pero también puede comprobar cómo un texto en lengua origen sale de
este módulo, escribiendo:
echo "sabates" | apertium-destxt | lt-proc ca-es.automorf.bin
|apertium-tagger -g ca-es.prob | apertium-pretransfer
| ./ca-es.transfer ca-es.autobil.bin | ltproc -g ca-es.autogen.bin
| ltproc -p es-ca.autopgen.bin
5.5.2.7.
La salida de Apertium
Se pueden poner todos los módulos del sistema en la estructura de tuberı́a para ver cómo un texto en lengua origen pasa a través de los módulos
y es traducido a la lengua meta. Sólo hace falta añadir el reformateador al
comando anterior:
echo "sabates" | apertium-destxt | lt-proc ca-es.automorf.bin
|apertium-tagger -g ca-es.prob | apertium-pretransfer
| ./ca-es.transfer ca-es.autobil.bin | ltproc -g ca-es.autogen.bin
| ltproc -p es-ca.autopgen.bin | apertium-retxt
Esto es lo mismo que utilizar el script (guión del intérprete de comandos de Linux) apertium-translator proporcionado por el paquete
Apertium:
echo "sabates" | apertium-translator . ca-es
166
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
(El punto indica el directorio en el que se guardan los datos lingüı́sticos,
en este caso el directorio actual).
Naturalmente, en lugar de escribir todos los comandos presentados cada vez que necesite probar una traducción, puede crear scripts para cada
acción y utilizarlos para probar la salida de cada módulo.
5.5.3.
Ejemplos de errores
1) Podemos encontrarnos con el siguiente resultado en la traducción:
$ echo "nord" | apertium-translator . ca-es
$ #norte<n><m><sg>
Esto significa que la palabra ha sido traducida correctamente por el diccionario bilingüe pero que el sistema no la ha encontrado en el diccionario
morfológico de español para generarla. El problema puede encontrarse
en el diccionario morfológico, pero puede deberse también a una entrada
bilingüe incorrecta, en la que los sı́mbolos morfológicos que recibe la palabra traducida no se corresponden con los sı́mbolos morfológicos que esta
palabra tiene en el diccionario morfológico.
2) La siguiente entrada bilingüe es-ca no tiene en cuenta el cambio de
género entre adhesiu (masculino) y pegatina (femenino), con lo cual provoca
un error del traductor:
<e>
<p>
<l>pegatina<s n="n"/></l>
<r>adhesiu<s n="n"/></r>
</p>
</e>
$ echo "adhesiu" | apertium-translator . ca-es
$ #pegatina<n><m><sg>
La entrada correcta es:
<e>
<p>
<l>pegatina<s n="n"/><s n="f"/></l>
<r>adhesiu<s n="n"/><s n="m"/></r>
</p>
</e>
5.5. DETECCIÓN DE ERRORES
167
3) El siguiente error se produce cuando la forma léxica de la lengua origen no se ha podido encontrar en el diccionario bilingüe, ya sea porque no
hay ninguna entrada para este lema o porque la entrada no se corresponde
con los sı́mbolos morfológicos recibidos del analizador:
$ echo "illot" | apertium-translator . ca-es
$ @illot<n><m><sg>
4) Cuando una forma léxica de la lengua origen tiene dos equivalentes
en el diccionario bilingüe, la salida del traductor será como la que sigue:
$ echo "llavor" | apertium-translator . ca-es
$ #pepita<n>/semilla<n><m><sg>
La solución es poner una restricción de dirección en una de las entradas
bilingües.
Algunos errores pueden ser debidos a reglas de transferencia estructural. La manera de solucionar un error cuya causa no conocemos es comprobar la salida de cada uno de los módulos para detectar en qué punto
surge el problema.
5.5.4.
Comprobación de la integridad de los diccionarios
Es muy recomendable comprobar la integridad de los diccionarios de
vez en cuando, especialmente si se ha hecho cambios significativos en ellos
(o bien si se ha modificado las reglas de transferencia, ya que algunos errores pueden deberse a su aplicación).
La comprobación se realiza en una dirección de traducción, por lo que,
para un par de lenguas determinado, hay que realizar dos comprobaciones, una en cada dirección.
Para ello, los pasos a seguir son los siguientes:
expandir el diccionario monolingüe de la lengua origen, mediante la
herramienta lt-expand, para obtener todas las formas léxicas (que
son las formas que aparecen a la derecha de los dos puntos en el
fichero resultante);
pasar estas formas léxicas (exceptuando las que sean sólo de generación, que lt-expand habrá marcado con el signo ’<’ ) por todos los
módulos del sistema desde el pretransfer hasta el generador;
Buscar en el resultado las formas léxicas marcadas con los signos ’#’
, ’@’ o ’/’, que serán las formas con error (véase el apartado 5.5.1).
168
5.6.
CAPÍTULO 5. MANTENIMIENTO DE DATOS LINGÜÍSTICOS
Generar un nuevo sistema con los nuevos
datos
Si se realiza algún cambio a cualquiera de los ficheros de datos de
Apertium (diccionarios, reglas de transferencia o fichero de definición del
desambiguador), es necesario volver a compilar los módulos para que el
sistema incorpore estos cambios. Para ello, hay que escribir make en el
directorio en el que se guardan los datos lingüı́sticos, y el sistema genererará los nuevos ficheros binarios.
Si se ha hecho algún cambio en el fichero de definición del desambiguador o en el corpus utilizado para entrenar el mismo, será necesario además
reentrenar el desambiguador: en el mismo directorio de datos lingüı́sticos,
debe escribirse (ejemplo para el desambiguador de español en el traductor es-ca) make -f es-ca-unsupervised.make para el entrenamiento no supervisado o make -f es-ca-supervised.make para el entrenamiento supervisado.
Tras las operaciones de compilación, apertium-translator ya utilizará los nuevos datos.
Capı́tulo 6
Formularios web de inserción de
datos
Este capı́tulo presenta el sistema de mantenimiento de diccionarios de
Apertium 2. Está estructurado en dos secciones. En la sección 6.2 se da la
información necesaria para instalar la herramienta y realizar adaptaciones.
En la sección 6.3 se expone el modo de uso de la aplicación web para llevar
a cabo la mejora de los datos lingüı́sticos.
6.1. Introducción
La tarea de introducir nuevos términos a los diccionarios de las diferentes lenguas del traductor es lenta si se hace editando manualmente los
diccionarios en XML; para ello se han creado estos formularios, que facilitan considerablemente la tarea de inserción de palabras y además permiten hacerlo de forma remota desde cualquier ordenador que tenga acceso
a Internet.
Ası́ se plantean como unos formularios escritos en php que son utilitzables con cualquier navegador de Internet, ya sea de forma local en
el mismo ordenador donde se almacenan los diccionarios, ya sea remotamente.
6.2. Instalación y administración
6.2.1. Instalación de la herramienta
La instalación debe realizarse en un máquina Unix que tenga instalado
un servidor web Apache con php. Ası́, primero debe hacerse la instala169
170
CAPÍTULO 6. FORMULARIOS WEB DE INSERCIÓN DE DATOS
ción del servidor php en caso de que no estuviera hecha, y a continuación
puede ya instalarse la herramienta de formularios.
Para ello, debe descargarse el paquete ‘apertium-lexical-webform-0.9’ de
la página web de Apertium en Sourceforge (http://apertium.sourceforge.
net/) y descomprimirlo dentro del directorio donde vaya a dejarse la herramienta.
# cd /ruta/de los/formularios
# tar -xvzf /ruta/apertium-lexical-webform-0.9.tar.gz
Hay que tener en cuenta que Apache sólo sirve las páginas que están
dentro del directorio raı́z con el que lo hemos configurado. Por lo tanto,
el directorio donde dejemos los formularios tiene que ser un subdirectorio
que esté dentro de la raı́z del servidor Apache.
A continuación debe editarse el fichero de configuración que está en
private/config.php y dar valores adecuados a las variables de configuración:
$anmor: ruta entera donde se encuentra el analizador morfológico
lt-proc.
$dicos path: ruta donde se encuentran los diccionarios finales y
los binarios compilados de cada diccionario. Este directorio tiene que
contener un subdirectorio para cada diccionario con el que puede
trabajar el formulario. El nombre del subdirectorio tiene que seguir
la siguiente sintaxis: paradigmes-ll-rr , donde ll y rr son las iniciales del par de lenguas del traductor en concreto. En cada directorio se dejan los diccionarios finales con los que trabaja el traductor y
los correspondientes binarios compilados. Estos directorios se pueden sustituir por enlaces simbólicos en caso de que se encuentren en
diferentes lugares.
$usuaris professionals: un listado de los usuarios profesionales del sistema que tienen permiso para inserir en los diccionarios
del formulario y validar entradas (equivalencias) pendientes de confirmación.
$mail: Dirección electrónica del administrador encargado de los formularios. Cuando alguien solicite darse de alta como usuario se enviará un correo electrónico a esta dirección.
Una vez configurados los parámetros de este fichero, el servidor de
formularios ya se encuentra en funcionamiento.
6.2. INSTALACIÓN Y ADMINISTRACIÓN
6.2.2.
171
Estructura de directorios
Todos los ficheros necesarios para el correcto funcionamiento se estructuran de la siguiente forma:
/index.php: presenta el formulario inicial de inserción. Tiene un
apartado para cada par de lenguas donde se introduce el lema en lengua origen y en lengua meta y se elige el tipo de categorı́a gramatical
apropiado. Al pulsar el botón ’Go on’ se pasa a la página siguiente,
donde deben seleccionarse los paradigmas de flexión correspondientes a cada uno de los lemas en lengua origen y lengua meta.
/dics: directorio con los diccionarios de las entradas que van inseriéndose desde los formularios. Están los ficheros con las entradas
de los usuarios no profesionales (pendientes de ser validades) y los
diccionarios con las entradas en formato XML de los usuarios profesionales.
/private: aquı́ está la mayor parte de los módulos utilizados en
los formularios. También contiene los directorios con la definición
de paradigmas para todas las lenguas con las que podemos trabajar;
estos directorios tienen la forma paradigmes-ll-rr siendo ll y rr
las iniciales del par de lenguas del traductor en concreto. El orden
escogido para las dos lenguas, primero ll y después rr, depende del
orden en que se hayan construido las entradas para el diccionario
bilingüe. También están en este directorio los ficheros encargados de
hacer todo el procesamiento de las palabras a inserir. Estos son:
• resultado.php: Este php es llamado cuando se insieren dos
palabras de cualquier par de lenguas desde el módulo index.php.
Básicamente lo que hace es establecer el par de lenguas con que
se trabajará ($LR y $RL) y la categorı́a gramatical de la palabra
que se inserirá ($tipus). Se incluye en el módulo selec.php que
será el siguiente que se llama en el proceso de inserción. En el
supuesto de que el tipus (tipo) de la palabra a inserir fuera una
unidad multipalabra (Multi Word Verb) entonces es el módulo
multip.php el que se incluye y se llama en vez de selec.php. Los
elementos Multi Word Verb o unidades multipalabra están formados por un verbo que puede flexionar seguido de una cola
invariable de una o más palabras (véase una descripción más
detallada en la sección 3.1.2.6.
172
CAPÍTULO 6. FORMULARIOS WEB DE INSERCIÓN DE DATOS
• selecc.php: Es el módulo encargado de proporcionar la selección del paradigma escogido para cada una de las dos palabras, la palabra en lengua origen y la palabra en lengua meta. Proporciona una lista de paradigmas para escoger que dependen del tipo gramatical de la entrada que estamos creando.
Cuando se selecciona un nuevo paradigma para uno de los dos
lemas, proporciona unos ejemplos de la flexión del lema a inserir según el paradigma que hemos escogido. Si aceptamos los
paradigmas escogidos, el módulo llama a insertarPro.php o insertar.php dependiendo de si el usuario que está haciendo la nueva
inserción está considerado como profesional o no profesional
respectivamente.
• multip.php: Tiene la misma función que el módulo selecc.php
pero para las unidades multipalabra. Utiliza las mismas variables y realiza las mismas operaciones, pero cuando muestra los
ejemplos lo hace flexionando el verbo y añadiendo todas las palabras que forman la cola. La manera de funcionar del módulo
es análoga a la del módulo selecc.php y su descripción detallada
la encontraremos en el apartado 6.2.3.2.
• valida.php: Este módulo se llama cuando un usuario profesional decide validar palabras que están en la cola de entradas
pendientes de validación. Lee el fichero con la cola de palabras
por validar y lo recorre de una en una, coge los datos de la entrada correspondiente (LRlem, RLlem, paradigmaLR, paradigmaRL,
LR, RL, etc...) y llama a selecc.php para continuar con el proceso
de inserción de esa entrada particular.
• insertarPro.php: Este módulo se llama cuando ya hemos
seleccionado el paradigma adecuado para la palabra en lengua origen y en lengua meta (operación realizada en selecc.php)
y queremos visualizar como quedará la entrada en el formato XML de los tres diccionarios, monolingüe origen, bilingüe y
monolingüe meta. Desde esta pantalla se podrá modificar directamente el código y finalmente aceptar la nueva entrada o
cancelar la operación.
• ins multip.php: Tiene la misma función que insertarPro.php
pero está pensado para las unidades multipalabra, de forma que
tiene un tratamiento especial con la entrada para que el código
XML que se insiere en los diccionarios sea correcto.
• insertar.php: Es el módulo equivalente a insertarPro.php
6.2. INSTALACIÓN Y ADMINISTRACIÓN
173
pero cuando la operación está realizándola un usuario no profesional. Las acciones que se realizan en este caso son mucho
más sencillas puesto que la única cosa que se hace es inserir
en el fichero de términos pendientes de validar los lemas y los
paradigmas escogidos por el usuario no profesional, y quedan
allı́ hasta que un usuario profesional los valida.
• verSemi.php: Este módulo tiene la función de mostrar el
fichero con las entradas inseridas por usuarios no profesionales y que están pendientes de ser validadas. Puede servir como
ayuda para los usuarios profesionales que antes de empezar a
validar palabras quieran comprobar cuáles están en la cola para
validar. Para llamarlo aparece un enlace en el formulario generado por selec.php desde donde se puede llamar esta funcionalidad.
• paradigmas.xsl: Hoja de estilos que se utiliza para generar
los ficheros de paradigmas con que trabajan los módulos del
formulario. Se utiliza con la especificación de los paradigmas de
cada lengua escrita en formato XML. Este punto se tratará más
extensamente en el apartado Ficheros de Paradigmas.
• creaparadigma.awk: Fichero awk que también se utiliza para generar los ficheros de paradigmas de trabajo.
• gen paradig.sh: Script que se puede usar si queremos que
automáticamente se generan los ficheros de paradigmas de todos los pares de lenguas que tenemos instalados.
La especificación detallada de las tareas de cada módulo se encuentra
en las secciones correspondientes.
6.2.3. Ficheros php
6.2.3.1. resultado.php
Dependiendo del valor de la variable $nomtrad actualizada por index.php el módulo asigna los valor adecuados a $LR y $RL (la lengua origen y la lengua meta respectivamente). Seguidamente, dependiendo de la
categorı́a gramatical de la palabra que se inserirá, asignamos el valor adecuado a la variable $tipo y llamamos a selec.php o multip.php dependiendo
de si se trata de una palabra simple o de una unidad multipalabra.
[Nota: MG: “asignamos” i “llamamos” no seria més aviat “se asigna”
y “se llama”?]
174
CAPÍTULO 6. FORMULARIOS WEB DE INSERCIÓN DE DATOS
6.2.3.2. selecc.php
Este módulo tiene la función de elegir el paradigma correspondiente a
las palabras que queremos introducir. Se elige el paradigma de la palabra
en lengua origen y en lengua meta.
En función de la categorı́a gramatical de la palabra que estamos introduciendo, se asignan unos determinados valores a unas variables que
darrerament se utilizarán
[Nota: MG: vol dir “que se utilizarán más adelante”?]
, estas son
cadFich: categorı́a gramatical del lema.
show: cadena que se muestra en el formulario indicando la categorı́a gramatical de la palabra que está inseriéndose.
tag: cadena con la etiqueta XML de salida del analizador morfológico para esta categorı́a gramatical.
tagout: cadena con el código XML que indica la categorı́a gramatical de la palabra. Esta cadena se utilizará cuando se componga la
entrada final XML que se inserirá en el diccionario.
nota: cadena con posibles comentarios a inserir en el código XML
de la entrada.
Los formularios trabajan con 4 tipos de diccionarios:
Semiprofesionales: Estos contienen las palabras inseridas desde el formulario por usuarios no profesionales y que están pendientes de validación. Acaban con la extensión ”semi.dic”
Diccionarios del formulario: Contienen las palabras que han sido inseridas desde el formulario por usuarios profesionales y también las que
han sido validades desde los diccionarios semiprofesionales. Acaban
con la extensión ”webform”.
Finales: Son los ficheros con todas las entradas escritas en código XML
. Estos ficheros son los que utiliza definitivamente el traductor después de recibir un tratamiento adecuado de compilación. Acaban
con la extensión ”dix”.
Finales compilados: Después de haber compilado los diccionarios finales ya pueden ser utilizados por los binarios del traductor. Acaban
con la extensión ”bin”
6.2. INSTALACIÓN Y ADMINISTRACIÓN
175
Estos diccionarios son utilizados por los formularios y hay variables
que contienen las rutas donde se pueden encontrar. También se dan valores a las variables que mantienen las rutas donde se tienen que buscar los
ficheros auxiliares y de configuración:
path: ruta para los diccionarios temporales.
fich LR: diccionario de la lengua origen de las palabras inseridas
mediante el formulario y que todavı́a no están en el diccionario final
ni en el diccionario compilado.
fich RL: diccionario de la lengua meta de las palabras inseridas
mediante el formulario y que todavı́a no están en el diccionario final
ni en el diccionario compilado.
fich LRRL: diccionario bilingüe de las palabras inseridas mediante
el formulario y que todavı́a no están en el diccionario final ni en el
diccionario compilado.
fich-semi: entradas inseridas mediante el formulario por usuarios no profesionales y que están pendientes de validación.
path paradigmasLR: ruta de los ficheros con los paradigmas de
flexión para la lengua origen.
path paradigmasRL: ruta de los ficheros con los paradigmas de
flexión para la lengua meta.
anmor: ruta del analizador morfológico.
aut LRRL: ruta del binario morfológico de lengua origen a lengua
meta.
[Nota: MG: no serà “binario bilingüe”?]
aut RLLR: ruta del binario morfológico de lengua meta a lengua
origen.
[Nota: MG: ı́dem]
A continuación se insiere el código html de lo que hay que hacer según
la acción seleccionada. Las acciones que se producen por orden secuencial
son las siguientes:
176
CAPÍTULO 6. FORMULARIOS WEB DE INSERCIÓN DE DATOS
Comprueba que el lema en lengua origen a inserir no esté ya en los
diccionarios de palabras inseridas por el formulario. Si se ha llamado a selecc.php desde la pantalla de validación de palabras
(valida.php), entonces comprueba que el lema no esté ya en el fichero de palabras inseridas por usuarios no profesionales. También
lo comprueba en el diccionario completo final.
Hace la misma comprobación correspondiente para la lengua meta.
Seguidamente se escribe código para seleccionar restricciones del
sentido de la traducción.
Se definen una serie de funciones que se utilizarán en la generación
de ejemplos para los lemas cuando elegimos el correspondiente paradigma. Estas son:
• esVocalFuerte
• esVocalDebil
• esVocal
• PosicioVocalTall
Estas funciones se describen más adelante en el apartado correspondiente a insertarPro.php.
Se abre el fichero de paradigmas para mostrar una ventana de selección desplegable con los paradigmas que podemos elegir para el lema en lengua origen que estamos tratando. Para hacer esto se tienen
que comprobar secuencialmente los paradigmas correspondientes a
la categorı́a gramatical del lema y comprobar que el paradigma se
puede aplicar al lema correspondiente.
A continuación se hace lo mismo pero para los paradigmas del lema
en lengua meta.
Con los lemas y con los paradigmas correspondientes seleccionados, se tienen que generar los ejemplos de cómo quedarı́a la flexión
de esos lemas según los paradigmas escogidos. Para conseguir esto necesitamos, por un lado, la raı́z del lema (raiz LR y raiz RL)
y, por otro, las terminacions de ejemplo para el paradigma escogido (paradigma LR y paradigma RL), terminaciones que se obtienen del fichero de paradigmas. Finalmente se compone una cadena
con los ejemplos generados (ejemplos LR y ejemplos RL) y se
muestran.
6.2. INSTALACIÓN Y ADMINISTRACIÓN
177
Si estamos en esta pantalla porque venimos de validar palabras (valida=1) entonces se añade al formulario un botón para eliminar la
entrada actual en caso de que no queramos validarla e inserirla.
Si el usuario que ha entrado en esta pantalla es un usuario reconocido como profesional, entonces se añade al formulario un botón para
que ese usuario pueda elegir la opción de validar palabras inseridas
por usuarios no profesionales
Finalmente tenemos el tratamiento de la acción correspondiente activada al pulsar uno de los botones de confirmación que se muestran
en la parte inferior del formulario. Si la acción es ”Delete” , lo cual
sólo puede ocurrir cuando se están validando entradas, se elimina
la entrada correspondiente del fichero con las entradas de usuarios
no profesionales. Si la acción es la de confirmar (botón ”Go on”), se
llama al módulo insertarPro.php o insertar.php dependiendo de si el usuario es profesional o no profesional respectivamente.
Estos módulos se encargan de hacer la inserción en los diccionarios.
Cuando se ha inserido la palabra, se vuelve a mostrar la página de validar.php o de selecc.php según si habı́amos entrado desde un procedimiento de validación (y entonces valida=1) o desde una inserción normal.
6.2.3.3. multip.php
El código y el comportamiento de este módulo es el mismo que el de
selecc.php. La única diferencia es que este está pensado para tratar las unidades multipalabra, mientras que selec.php trata el resto de unidades. Ası́,
la diferencia más evidente es que tenemos las variables $LRcua y $RLcua
que contienen la cola invariable que va después de la parte variable de la
multipalabra. Cuando se muestran los ejemplos, aparte de mostrar la parte variable flexionada según el paradigma escogido, también se muestra
un cuadro de texto modificable con la cola invariable.
Cuando se pulse el botón de seguir con la inserción de la entrada en los
diccionarios, se llama al módulo ins multip.php en vez de insertarPro.php..
6.2.3.4. valida.php
Este módulo es llamado cuando un usuario profesional pulsa el botón
”validate pairs”. El control pasa a este módulo que lee el diccionario de
entradas pendientes de ser validadas ($fichSemi) del par de lenguas correspondiente. Entonces se entra en un bucle que recorre este fichero y va
178
CAPÍTULO 6. FORMULARIOS WEB DE INSERCIÓN DE DATOS
leyendo las entradas una a una. Con la información de la entrada particular da valor a una serie de variables que serán utilizadas en los módulos
que harán el tratamiento posterior, como por ejemplo:
$LRlem
$paradigmaLR
$direccions
$comentarios
$geneLR
$numLR
$LR
$RLlem
$paradigmaRL
$tipo
$user
$geneRL
$numRL
$RL
Una vez establecidos los valores adecuados para estas variables se cede el control a selec.php que trata la entrada como si de una inserción de
usuario profesional se tratara. Después de inserir las entradas en los diccionarios mediante insertarPro.php, el flujo vuelve a valida.php que continúa
con la siguiente entrada por validar.
6.2.3.5. insertarPro.php
Una vez introducidos los lemas y seleccionados los paradigmas correspondientes en selec.php, este módulo es el encargado de generar las correspondientes entradas en código XML e inserirlas en los diccionarios monolingües y en el bilingüe.
Realiza muchas operaciones parecidas a las realizadas en selec.php, como por ejemplo generar los ejemplos de la palabra flexionada. Ası́ primeramente da valor a cadFich, show, tag, tagout, nota dependiendo de la categorı́a gramatical ($tipus) de la palabra a inserir. Asigna
rutas a las variables de ubicación de ficheros y define unas funciones necesarias de igual manera a como ocurrı́a en selec.php.
esVocalFuerte: Devuelve true si la vocal es fuerte, es decir a, e, o.
esVocalDebil: Devuelve true si la vocal es débil, es decir a, e, o.
[Nota: MG: vol dir “i, u”?]
esVocal: Devuelve true si el carácter que le pasamos como argumento es una vocal.
diptongo: Devuelve true si las dos letras que se le pasan como argumentos forman diptongo. Esto ocurrirá siempre que las dos vocales
no sean fuertes.
6.2. INSTALACIÓN Y ADMINISTRACIÓN
179
acentuar: Se le pasa una cadena de texto y lo acentúa siguiendo las
reglas del castellano en función del parámetro $siguienteletra.
esMayuscula: Devuelve true si el carácter está en mayúscula.
TieneAcento: Devuelve true si la cadena tiene acento.
acentua: Acentúa la última vocal accentuable de una palabra con
un acento cerrado o abierto dependiendo del sentido indicado en el
parámetro $sentit.
PonQuitaAcento: Pone o quita el acento de la primera cadena pasada como argumento en función de si la segunda cadena argumento
tiene o no tiene acento.
PosicioVocalTall: Devuelve la posición dentro del lema ($lema)
donde se encuentra la vocal ($vocal) que separa la raı́z de la desinencia. Se busca la vocal del final hacia el principio y se devuelve la primera ocurrencia de $vocal.
Ahora se realizan las mismas operaciones que en selec.php. Primero,
comprueba que la entrada no esté ya en los diccionarios y genera los ejemplos de la palabra flexionada con el paradigma previamente escogido. A
continuación se construye la cadena con el código XML que va a inserirse
en el diccionario monolingüe de lengua origen. Con la información que tenemos de los lemas proveniente de selec.php, se genera una cadena de texto
($cad LR) que contiene el código XML para el diccionario monolingüe. Esta cadena se muestra en una ventana de texto que puede ser modificada
manualment. El mismo proceso se repite para generar la cadena correspondiente al diccionario monolingüe de lengua meta ($cad RL) y para
el diccionario bilingüe ($cad bil). Luego, se concatena a estas variables
de cadena los comentarios y el nombre del usuario que insiere la entrada,
si procede. Finalmente se acaba de componer la pantalla de formulario,
con botones de aceptar, eliminar y volver atrás. El código que hace el tratamiento de cada una de las posibles acciones se encuentra al final del
fichero:
Inserir: En este caso, hace unas sustituciones de caracteres para que la entrada tenga el formato adecuado para los diccionarios,
e insiere las cadenas $cad LR, $cad bil, $cad RL en los diccionarios monolingüe origen, bilingüe y monolingüe meta respectivamente ($fich LR, $fich LRRL, $fich RL). Si se produce algún
tipo de error al inserir la entrada, informa de este hecho con una
CAPÍTULO 6. FORMULARIOS WEB DE INSERCIÓN DE DATOS
180
notificación por pantalla. Si insertarPro.php habı́a sido llamado desde un procedimiento de validación de palabras ($valida=1), entonces
insiere un botón ”Continue”para seguir validando palabras. En caso
contrario insiere un botón de cerrar la ventana que nos permitirá acabar.
Eliminar: En este caso, elimina la entrada del fichero de entradas
pendientes de validar.
6.2.3.6.
ins multip.php
Realiza las mismas operaciones que insertarPro.php pero cuando la entrada a inserir es una unidad multipalabra. La diferencia principal es que
ahora disponemos de dos variables adicionales $LRcua y $RLcua que
contienen la parte invariable de la multipalabra. Cuando se insiere la entrada en los diccionarios se tiene que añadir esta cola en el lugar conveniente y convertir los espacios en blanco por la etiqueta de blanco <b/>.
6.2.3.7. insertar.php
La función de este módulo es muy sencilla. Compone una cadena de
texto con la información proveniente de selec.php separada por tabuladores. Esta cadena contiene toda la información necesaria para generar una
entrada de diccionario:
$LRlem.$RLlem.$paradigmaLR.$direccion.$paradigmaRL.
$tipo.$comentarios.$user.$geneLR.$geneRL.
Esta entrada se guarda en un fichero ($fichSemi) que contiene la cola
con las entradas pendientes de validar inseridas por usuarios no profesionales. Cuando un usuario considerado profesional quiera validar entradas
pendientes, el módulo valida.php leerá este mismo fichero.
6.2.3.8.
verSemi.php
Se encarga de mostrar por pantalla el fichero de entradas pendientes de
validación, y lo hace ası́: lee el fichero con las entradas ($fichSemi) y entra
en un bucle que recorre todas las entradas que se encuentran en el fichero.
Para cada una de ellas muestra una lı́nea con la siguiente información:
$LRlem $paradigmaLR $direccion $RLlem
$paradigmaRL $tipo $comentarios
6.2. INSTALACIÓN Y ADMINISTRACIÓN
6.2.4.
181
Ficheros de diccionario
Los ficheros con las entradas inseridas desde el formulario se encuentran en /dics. Aquı́ se encuentran dos tipos de ficheros:
apertium-ll-rr.xx.webform: El fichero que contiene entradas
en código XML preparadas para ser copiadas en los diccionarios finales. El nombre del fichero tiene el formato mostrado, siendo ll-rr
las iniciales correspondientes al traductor al que hace referencia el
fichero y xx las iniciales de la lengua del monolingüe al que hace referencia o las iniciales del bilingüe. Por ejemplo, las iniciales
del traductor español-catalán son es-ca. Para este traductor tenemos el monolingüe de español (es), el de catalán (can) y el bilingüe
(es-ca) Ası́, en este directorio tendremos los siguientes ficheros para el traductor español-catalán:
apertium-es-ca.es.webform
apertium-es-ca.ca.webform
apertium-es-ca.es-ca.webform
oo-mm.semi.dic: El fichero que contiene las entradas pendientes
de ser validadas de un determinado par de lenguas. oo-mm son las
iniciales correspondientes al par concreto. Por ejemplo, el traductor
español-catalán tendrá este fichero para el semi-profesional: es-ca.semi.dic
6.2.5. Ficheros de paradigmas
Los paradigmas utilizados para cada par de lenguas se especifican en
dos archivos de formato XML denominados paradig.ll-rr.xx.xml donde xx son las iniciales correspondientes a una lengua y ll-rr las iniciales
correspondientes a un par de lenguas. Estos archivos están formados por
un conjunto de entradas correspondientes a paradigmas o modelos de flexión de las palabras de una lengua en concreto. El fichero XML se compone
de las siguientes partes:
Cabecera/Raı́z del documento de especificación.
<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="text/xsl" href="paradigmas.xsl"?>
<!DOCTYPE form SYSTEM "form.dtd">
<form lang="oc" langpair="oc-ca">
182
CAPÍTULO 6. FORMULARIOS WEB DE INSERCIÓN DE DATOS
El atributo lang indica las iniciales de la lengua para la cual están
especificándose paradigmas y el atributo langpair indica las iniciales
correspondientes al par de lenguas del traductor al que corresponde
el fichero. Es necesario que en el mismo directorio donde están los
ficheros de paradigmas esté form.dtd, donde se especifica la DTD
que siguen estos ficheros. Esta DTD está detallada en el anexo A.7.
Un conjunto de elementos que definen los paradigmas. Para explicar
el formato de los elementos reproducimos este ejemplo:
<entry PoS="adj" nbr="sg_pl" gen="mf">
<endings>
<stem>amable</stem>
<ending/>
<ending>s</ending>
</endings>
<paradigms howmany="1">
<par n="amable adj"/>
</paradigms>
</entry>
Cada paradigma está especificado en un elemento <entry>. Este
elemento puede tener tres atributos:
• PoS: la categorı́a gramatical del paradigma. Puede tomar los valores: acr, adj, adv, noun, pname, pr, verbo.
[Nota: faltaria cnjadv?]
Es obligatorio para cualquier categorı́a gramatical.
• nbr: los números admitidos por el paradigma. Puede tener los
valores: sg, pl, sg pl, sp.
• gen: los géneros admitidos por el paradigma. Puede tener los
valores: m, f, m f, mf.
Además, está formado por dos elementos:
• endings: la raı́z y las terminacions utilizadas para seleccionar
el paradigma en el formulario y mostrar los ejemplos de flexión.
• paradigms: especificación del paradigma o paradigmas que
definen la flexión seguida por una entrada en concreto. Necesita del atributo howmany que indica el número de paradigmas
6.2. INSTALACIÓN Y ADMINISTRACIÓN
183
que utiliza la entrada. Para cada uno de los paradigmas utilizados hay una lı́nea que especifica el nombre del paradigma del
diccionario, y que tiene el siguiente formato:
<par n="long adj"/>
A partir del fichero de paradigmas escrito en XML, se tienen que generar los ficheros con los que directamente trabajan los módulos de los
formularios. Si se ejecuta el script /private/gen paradig.sh el proceso se realiza automáticamente para todos los pares de lenguas de que
disponemos:
#
#
cd private
./gen paradig.sh
Para añadir un nuevo paradigma a los formularios, debe prepararse la
entrada correspondiente en el fichero de paradigmas en formato XML y
después actualizar los archivos de trabajo con la orden anterior.
El proceso automatizado también se puede realizar de forma manual
si no queremos actualizar los ficheros de todos los pares de lenguas que
tenemos instalados. La generación manual de los archivos de trabajo se
hace con una hoja de estilo XSL mediante esta orden:
#
xsltproc paradigmas.xsl fichero de paradigmas.xml
| ./creaparadig.awk
Esta acción genera un fichero de trabajo para cada categorı́a gramatical.
Los ficheros generados se encuentran en los directorios /private/paradigmas.ll-rr.
Cada directorio contiene ficheros con los paradigmas que se pueden utilizar para cada par de lenguas ll-rr y para cada componente gramatical.
Cada uno de estos directorio contiene los ficheros siguientes:
paradigacr xx: paradigmas para acrónimos de la lengua xx.
paradigadj xx: paradigmas para adjetivos de la lengua xx.
paradigadv xx: paradigmas para adverbios de la lengua xx.
paradigcnjadv xx: paradigmas para conjunciones adverbiales de
la lengua xx.
paradigcnjcoo xx: paradigmas para conjunciones copulativas de
la lengua xx.
[Nota: MG: aquesta no està en la pàgina web del formulari]
184
CAPÍTULO 6. FORMULARIOS WEB DE INSERCIÓN DE DATOS
paradigcnjsub xx: paradigmas para conjunciones subordinadas
de la lengua xx.
[Nota: ı́dem]
paradignoun xx: paradigmas para nombres de la lengua xx.
paradigpname xx: paradigmas para nombres propios de la lengua
xx.
paradigpr xx: paradigmas para preposiciones de la lengua xx.
paradigverb xx: paradigmas para verbos de la lengua xx.
Los ficheros están compuestos por una entrada por lı́nea. Cada entrada
contiene la información siguiente:
ejemplos número de paradigmas
paradigmas modelo (números) (géneros)
El separador utilizado para las diferentes partes de la entrada es el tabulador.
Ejemplos: son las terminacions que se utilizarán para generar los ejemplos cuando escogemos este paradigma como prototipo para una determinada palabra a inserir.
Número de paradigmas: es el número de paradigmas del diccionario
que se utilizarán para flexionar adecuadamente este modelo de flexión en particular.
Paradigmas modelo: es el nombre del paradigma o paradigmas que
están en el diccionario y que son los que se utilizarán para flexionar
la nueva entrada.
(Números): Sólo se pone en el caso de nombres, adjetivos y acrónimos.
Hace referencia al número del paradigma.
(Géneros): Sólo se pone en el caso de nombres, adjetivos y acrónimos.
Hace referencia al género del paradigma.
Ası́ por ejemplo, en el traductor español-catalán tendrı́amos el directorio /private/paradigmas.es-ca donde encontrarı́amos dos ficheros
XML: paradig.es-ca.es.xml y paradig.es-ca.ca.xml con la especificación de los paradigmas utilizados en cada lengua. A partir de estos
ficheros se pueden generar todos los ficheros de paradigmas para un par
de lenguas concreto con la orden:
6.3. UTILIZACIÓN DE LOS FORMULARIOS
#
#
#
185
cd private/paradigmas.es-ca
xsltproc ../paradigmas.xsl paradig.es-ca.es.xml
| ../creaparadig.awk
xsltproc ../paradigmas.xsl paradig.es-ca.ca.xml
| ../creaparadig.awk
O bien, se pueden generar automáticamente para todos los pares de
lenguas con:
#
./private/gen paradig.sh
Entre los ficheros de trabajo generados, habrı́a uno, por ejemplo, denominado paradigverb ca que contendrı́a los posibles paradigmas de
verbos para el catalán, donde una posible lı́nea serı́a la siguiente:
abra/çar /ço /ci 1 abalan/çar vblex
que deriva de la entrada en XML:
<entry PoS="verb">
<endings>
<stem>abra</stem>
<ending>çar</ending>
<ending>ço</ending>
<ending>ci</ending>
</endings>
<paradigms howmany="1">
<par n="abalan/çar vblex"/>
</paradigms>
</entry>
6.3. Utilización de los formularios
6.3.1. Introducción
[Intentar evitar el llenguatge sexista en tot el document: usuari, etc.]
Cuando la persona usuaria quiera inserir nuevas entradas a un diccionario
tiene que conectarse mediante un cliente navegador a la dirección donde
se haya instalado el servidor de formularios, por ejemplo:
http://xixona.dlsi.ua.se/forms
CAPÍTULO 6. FORMULARIOS WEB DE INSERCIÓN DE DATOS
186
Se abrirá una página web con el portal de entrada a Opentrad ApertiumInsertion Form. En el marco de la izquierda hay enlaces para obtener
más información , descargar los programas y contacto para solicitar inscribirse como usuario del sistema. Para inscribirse como usuario hay que enviar
un correo electrónico al webmaster encargado de los formularios.
[Canviar a tot arreu registrar per inscribir.]
Para inserir nuevas palabras, se llenará el formulario con los datos correspondientes y se pulsará el botón ’Go On’; en este momento habrá que identificarse como usuario inscrito o no se podrá continuar con el procedimiento de inserir palabras. Cuando una persona se inscribe se puede registrar
de dos maneras: como profesional o como no profesional. Cada modalidad
tiene unas habilitacions diferentes, que se explicarán en los apartados siguientes.
6.3.2.
Inserción de entradas
6.3.2.1. Perfil profesional
Cuando se quiere inserir una nueva entrada a los diccionarios hay que
dirigirse al apartado correspondiente al par de lenguas que se quiera ampliar. Entonces se especifica el lema en lengua origen y en lengua meta y
se elige la categorı́a gramatical de las entradas que se inserirán. A continuación, se pulsa el botón Go on para seguir con el proceso de inserción.
En este punto aparece una nueva ventana que muestra los lemas y unos
parámetros que caracterizan la nueva entrada de diccionario. Si la entrada
ya está en alguno de los diccionarios, se avisará a la persona usuaria y el
sistema automáticamente escogerá sentido unidireccional (de izquierda a
derecha o al inrevés). Si no está en ninguno, se elegirá doble sentido de
traducción.
En esta nueva ventana se pueden hacer estas tres acciones:
[Cal repassar la primera oració del paràgraf següent; sembla que hi
ha algun material que hauria de ser esborrat; Una altra cosa, els
formularis en l’actualitat no tenen suport per a traduccions múltiples,
segons sembla. Caldria fer constar aquesta circumstància en algun
lloc.]
Escoger el paradigma para el lema en lengua origen y para el lema
en lengua meta (esta acción es obligatoria, el resto no).1
1
Escoger el paradigma es un proceso que debe realizarse con mucho cuidado. Hay
6.3. UTILIZACIÓN DE LOS FORMULARIOS
187
Escoger la dirección de traducción de la entrada si es diferente de la
propuesta automáticamente.
Añadir comentarios en la entrada que quedarán en el diccionario
final.
Una vez se han hecho las operaciones correspondientes, debe pulsarse
’Go on’ si queremos confirmar la entrada o ’Close’ si queremos cancelar la
operación de inserción.
La siguiente y última pantalla que se nos muestra contiene las tres entradas en formato XML generadas para los diccionarios monolingüe lengua
origen, bilingüe y monolingüe lengua meta. Estas entradas se muestran
en tres ventanas de texto y se pueden editar si se desea hacer alguna modificación. Una vez revisadas las entradas, se pulsa el botón ’Insert’ para
inserirlas definitivamente en los diccionarios correspondientes. También
tenemos la posibilidad de pulsar el botón ’Go back’ si queremos volver al
paso anterior.
6.3.2.2. Usuario no profesional
Cuando un usuario entra al sistema de inserción como usuario no profesional, el procedimiento de inserción de palabras es el mismo que para el
usuario profesional, pero las entradas inseridas no se guardan en los diccionarios generados por los formularios sino que quedan en una cola de
entradas pendientes de validación. Para inserir las palabras de esta cola a
los diccionarios hace falta que un usuario profesional las valide.
6.3.3. Validación de entradas pendientes de aprobación
Los usuarios profesionales, en la pantalla donde se escoge el paradigma de los lemas inseridos, tienen dos enlaces adicionales:
See pairs to be validated: Aquı́ se abre una ventana donde se muestra el
contenido del fichero con las palabras que están pendientes de valique elegir el paradigma exacto que describe el comportamiento del lema que estamos
inseriendo. En el caso de adjetivos, nombres y acrónimos, hay que escoger el paradigma
que se ajuste a la flexión deseada y también a los géneros admitidos. En el caso de acrónimos, por ejemplo, hay que fijarse en el género y número que admite cada paradigma de
los que podemos escoger; por ejemplo BBC sirve para acrónimos femeninos singulares y
SA para acrónimos femeninos que admiten plural). En el caso de nombres propios, debe
escogerse el paradigma en función de si se trata de un nombre propio de cosa (p. ej. un
periódico), de persona o de lugar.
188
CAPÍTULO 6. FORMULARIOS WEB DE INSERCIÓN DE DATOS
dación; son palabras que han sido inseridas por usuarios no profesionales. Esta ventana es meramente informativa y se cierra pulsando
el botón ’Close’.
Validate pairs: Esta opción permite a un usuario profesional validar
una a una las entradas pendientes. Al pulsar este botón se abre la
ventana de selección de paradigmas que se ha visto en el apartado de inserción de nuevas palabras. Esta ventana muestra los datos
que ha escogido el usuario para la entrada que ha añadido. Ahora,
el usuario profesional puede modificar los lemas, borrar la entrada
(botón ’Delete’) o seguir con el proceso de inserción. Si sigue con la
inserción de la entrada, el proceso es el mismo que en una inserción
normal, sólo que cuando la entrada queda definitivamente añadida a
los diccionarios de formulario el control vuelve a mostrar la siguiente entrada a validar de la cola.
Este proceso es repite hasta que se validen todas las palabras de la
cola o se finalice el proceso pulsando el botón ’Close’.
Apéndice A
Definiciones de tipos de
documento (DTD) en XML
A.1. DTD para el formato de los diccionarios
Definición de tipo de documento para el formato de los diccionarios
morfológicos, bilingües y de postgeneración en XML; esta definición viene con el paquete apertium (última versión) que se puede descargar de
http://www.sourceforge.net.
La explicación de los distintos elementos se encuentra en la página 24
y siguientes.
<!ELEMENT dictionary (alphabet?, sdefs?,
pardefs?, section+)>
<!ELEMENT alphabet (#PCDATA)>
<!ELEMENT sdefs (sdef+)>
<!ELEMENT sdef EMPTY>
<!ATTLIST sdef n ID #REQUIRED>
<!ELEMENT pardefs (pardef+)>
<!ELEMENT pardef (e+)>
<!ATTLIST pardef n CDATA #REQUIRED>
<!ELEMENT section (e+)>
<!ATTLIST section id ID #REQUIRED
189
APÉNDICE A. DTDS EN XML
190
type (standard|inconditional|postblank) #REQUIRED>
<!ELEMENT e (i | p | par | re)+>
<!ATTLIST e r (LR|RL) #IMPLIED
lm CDATA #IMPLIED
a CDATA #IMPLIED
c CDATA #IMPLIED
<!ELEMENT par EMPTY>
<!ATTLIST par n CDATA #REQUIRED>
<!ELEMENT i (#PCDATA | b | s | g | j | a)*>
<!ELEMENT re (#PCDATA)>
<!ELEMENT p (l, r)>
<!ELEMENT l (#PCDATA | a | b | g | j | s)*>
<!ELEMENT r (#PCDATA | a | b | g | j | s)*>
<!ELEMENT a EMPTY>
<!ELEMENT b EMPTY>
<!ELEMENT g (#PCDATA | a | b | j | s)*>
<!ATTLIST g i CDATA #IMPLIED>
<!ELEMENT j EMPTY>
<!ELEMENT s EMPTY>
<!ATTLIST s n IDREF #REQUIRED>
A.1.1.
Modificación en la DTD de diccionarios para selección léxica
La DTD para el formato de los diccionarios se ha modificado ligeramente para que éstos pueden funcionar en un sistema con módulo de selección léxica. A continuación se muestra el cambio realizado, que afecta
sólo al elemento <e>
A.2. DTD PARA EL DESAMBIGUADOR
191
...
<!ATTLIST e
r (LR|RL) #IMPLIED
lm CDATA #IMPLIED
a CDATA #IMPLIED
c CDATA #IMPLIED>
i CDATA #IMPLIED
slr CDATA #IMPLIED
srl CDATA #IMPLIED>
<!-- r: restriction LR: left-to-right,
RL: right-to-left -->
<!-- lm: lemma -->
<!-- a: author -->
<!-- c: comment -->
<!-- i: ignore (’yes’) means ignore, otherwise it is not ignored) -->
<!-- slr: translation sense when translating from left to right -->
<!-- srl: translation sense when translating from right to left -->
...
A.2.
DTD para el formato de los ficheros del desambiguador
DTD que define el formato del fichero de especificación del desambiguador. Esta definición viene con el paquete apertium (última versión)
que se puede descargar de http://www.sourceforge.net.
La descripción de los distintos elementos se encuentra en la página 60.
<!ELEMENT tagger (tagset,forbid?,enforce-rules?,preferences?)>
<!ATTLIST tagger name CDATA #REQUIRED>
<!ELEMENT tagset (def-label+,def-mult*)>
<!ELEMENT def-label (tags-item+)>
<!ATTLIST def-label name CDATA #REQUIRED
closed CDATA #IMPLIED>
<!ELEMENT tags-item #EMPTY>
<!ATTLIST tags-item tags CDATA #REQUIRED
lemma CDATA #IMPLIED>
APÉNDICE A. DTDS EN XML
192
<!ELEMENT def-mult (sequence+)>
<!ATTLIST def-mult name CDATA #REQUIRED
closed CDATA #IMPLIED>
<!ELEMENT sequence ((tags-item|label-item)+)>
<!ELEMENT label-item #EMPTY>
<!ATTLIST label-item label CDATA #REQUIRED>
<!ELEMENT forbid (label-sequence+)>
<!ELEMENT label-sequence (label-item+)>
<!ELEMENT enforce-rules (enforce-after+)>
<!ELEMENT enforce-after (label-set)>
<!ATTLIST enforce-after label CDATA #REQUIRED>
<!ELEMENT label-set (label-item+)>
<!ELEMENT preferences (prefer+)>
<!ELEMENT prefer EMPTY>
<!ATTLIST prefer tags CDATA #REQUIRED>
A.3.
DTD del módulo de transferencia estructural (chunker)
DTD para el formato de las reglas de transferencia estructural del módulo chunker. Esta definición viene con el paquete apertium (versión 2.0)
que se puede descargar de http://www.sourceforge.net.
La descripción de los distintos elementos se encuentra en el apartado
3.5.4.
<!ENTITY % condition "(and|or|not|equal|begins-with|
ends-with|contains-substring|in)">
<!ENTITY % container "(var|clip)">
<!ENTITY % sentence "(let|out|choose|modify-case|
call-macro|append)">
<!ENTITY % value "(b|clip|lit|lit-tag|var|get-case-from|
A.3. DTD DEL MÓDULO CHUNKER
case-of|concat)">
<!ENTITY % stringvalue "(clip|lit|var|get-case-from|
case-of)">
<!ELEMENT transfer (section-def-cats,
section-def-attrs,
section-def-vars,
section-def-lists?,
section-def-macros?,
section-rules)>
<!ATTLIST transfer default (lu|chunk) #IMPLIED>
<!ELEMENT section-def-cats (def-cat+)>
<!ELEMENT def-cat (cat-item+)>
<!ATTLIST def-cat n ID #REQUIRED>
<!ELEMENT cat-item EMPTY>
<!ATTLIST cat-item lemma CDATA #IMPLIED
tags CDATA #REQUIRED >
<!ELEMENT section-def-attrs (def-attr+)>
<!ELEMENT def-attr (attr-item+)>
<!ATTLIST def-attr n ID #REQUIRED>
<!ELEMENT attr-item EMPTY>
<!ATTLIST attr-item tags CDATA #IMPLIED>
<!ELEMENT section-def-vars (def-var+)>
<!ELEMENT def-var EMPTY>
<!ATTLIST def-var n ID #REQUIRED>
<!ELEMENT section-def-lists (def-list)+>
<!ELEMENT def-list (list-item+)>
<!ATTLIST def-list n ID #REQUIRED>
<!ELEMENT list-item EMPTY>
<!ATTLIST list-item v CDATA #REQUIRED>
193
194
APÉNDICE A. DTDS EN XML
<!ELEMENT section-def-macros (def-macro)+>
<!ELEMENT def-macro ( %sentence;)+>
<!ATTLIST def-macro n ID #REQUIRED>
<!ATTLIST def-macro npar CDATA #REQUIRED>
<!ELEMENT section-rules (rule+)>
<!ELEMENT rule (pattern, action)>
<!ATTLIST rule comment CDATA #IMPLIED>
<!ELEMENT pattern (pattern-item+)>
<!ELEMENT pattern-item EMPTY>
<!ATTLIST pattern-item n IDREF #REQUIRED>
<!ELEMENT action ( %sentence;)*>
<!ELEMENT choose (when+,otherwise?)>
<!ELEMENT when (test,( %sentence;)*)>
<!ELEMENT otherwise ( %sentence;)+>
<!ELEMENT test ( %condition;)+>
<!ELEMENT and (( %condition;),( %condition;)+)>
<!ELEMENT or (( %condition;),( %condition;)+)>
<!ELEMENT not ( %condition;)>
<!ELEMENT equal ( %value;, %value;)>
<!ATTLIST equal caseless (no|yes) #IMPLIED>
<!ELEMENT begins-with ( %value;, %value;)>
<!ATTLIST begins-with caseless (no|yes) #IMPLIED>
<!ELEMENT ends-with ( %value;, %value;)>
<!ATTLIST ends-with caseless (no|yes) #IMPLIED>
<!ELEMENT contains-substring ( %value;, %value;)>
<!ATTLIST contains-substring caseless (no|yes) #IMPLIED>
A.3. DTD DEL MÓDULO CHUNKER
<!ELEMENT in ( %value;, list)>
<!ATTLIST in caseless (no|yes) #IMPLIED>
<!ELEMENT list EMPTY>
<!ATTLIST list n IDREF #REQUIRED>
<!ELEMENT let ( %container;, %value;)>
<!ELEMENT append ( %value;)+>
<!ATTLIST append n IDREF #REQUIRED>
<!ELEMENT out (mlu|lu|b|chunk)+>
<!ELEMENT modify-case ( %container;, %stringvalue;)>
<!ELEMENT call-macro (with-param)*>
<!ATTLIST call-macro n IDREF #REQUIRED>
<!ELEMENT with-param EMPTY>
<!ATTLIST with-param pos CDATA #REQUIRED>
<!ELEMENT clip EMPTY>
<!ATTLIST clip pos CDATA #REQUIRED
side (sl|tl) #REQUIRED
part CDATA #REQUIRED
queue CDATA #IMPLIED
link-to CDATA #IMPLIED>
<!ELEMENT lit EMPTY>
<!ATTLIST lit v CDATA #REQUIRED>
<!ELEMENT lit-tag EMPTY>
<!ATTLIST lit-tag v CDATA #REQUIRED>
<!ELEMENT var EMPTY>
<!ATTLIST var n IDREF #REQUIRED>
<!ELEMENT get-case-from (clip|lit|var)>
<!ATTLIST get-case-from pos CDATA #REQUIRED>
<!ELEMENT case-of EMPTY>
<!ATTLIST case-of pos CDATA #REQUIRED
195
APÉNDICE A. DTDS EN XML
196
side (sl|tl) #REQUIRED
part CDATA #REQUIRED>
<!ELEMENT concat ( %value;)+>
<!ELEMENT mlu (lu+)>
<!ELEMENT lu ( %value;)+>
<!ELEMENT chunk (tags,(mlu|lu|b)+)>
<!ATTLIST chunk name CDATA #IMPLIED
namefrom CDATA #IMPLIED
case CDATA #IMPLIED>
<!ELEMENT tags (tag+)>
<!ELEMENT tag ( %value;)>
<!ELEMENT b EMPTY>
<!ATTLIST b pos CDATA #IMPLIED>
A.4. DTD DEL MÓDULO INTERCHUNK
A.4.
197
DTD del módulo interchunk
DTD para el formato de las reglas de transferencia estructural del módulo interchunk. Esta definición viene con el paquete apertium (versión
2.0) que se puede descargar de http://www.sourceforge.net.
La descripción de los distintos elementos se encuentra en el apartado
3.5.4.
<!ENTITY % condition "(and|or|not|equal|begins-with|
ends-with|contains-substring|in)">
<!ENTITY % container "(var|clip)">
<!ENTITY % sentence "(let|out|choose|modify-case|
call-macro|append)">
<!ENTITY % value "(b|clip|lit|lit-tag|var|get-case-from|
case-of|concat)">
<!ENTITY % stringvalue "(clip|lit|var|get-case-from|
case-of)">
<!ELEMENT interchunk (section-def-cats,
section-def-attrs,
section-def-vars,
section-def-lists?,
section-def-macros?,
section-rules)>
<!ELEMENT section-def-cats (def-cat+)>
<!ELEMENT def-cat (cat-item+)>
<!ATTLIST def-cat n ID #REQUIRED>
<!ELEMENT cat-item EMPTY>
<!ATTLIST cat-item lemma CDATA #IMPLIED
tags CDATA #REQUIRED >
<!ELEMENT section-def-attrs (def-attr+)>
<!ELEMENT def-attr (attr-item+)>
<!ATTLIST def-attr n ID #REQUIRED>
<!ELEMENT attr-item EMPTY>
<!ATTLIST attr-item tags CDATA #IMPLIED>
198
APÉNDICE A. DTDS EN XML
<!ELEMENT section-def-vars (def-var+)>
<!ELEMENT def-var EMPTY>
<!ATTLIST def-var n ID #REQUIRED>
<!ELEMENT section-def-lists (def-list)+>
<!ELEMENT def-list (list-item+)>
<!ATTLIST def-list n ID #REQUIRED>
<!ELEMENT list-item EMPTY>
<!ATTLIST list-item v CDATA #REQUIRED>
<!ELEMENT section-def-macros (def-macro)+>
<!ELEMENT def-macro ( %sentence;)+>
<!ATTLIST def-macro n ID #REQUIRED>
<!ATTLIST def-macro npar CDATA #REQUIRED>
<!ELEMENT section-rules (rule+)>
<!ELEMENT rule (pattern, action)>
<!ATTLIST rule comment CDATA #IMPLIED>
<!ELEMENT pattern (pattern-item+)>
<!ELEMENT pattern-item EMPTY>
<!ATTLIST pattern-item n IDREF #REQUIRED>
<!ELEMENT action ( %sentence;)*>
<!ELEMENT choose (when+,otherwise?)>
<!ELEMENT when (test,( %sentence;)*)>
<!ELEMENT otherwise ( %sentence;)+>
<!ELEMENT test ( %condition;)+>
<!ELEMENT and (( %condition;),( %condition;)+)>
<!ELEMENT or (( %condition;),( %condition;)+)>
A.4. DTD DEL MÓDULO INTERCHUNK
<!ELEMENT not ( %condition;)>
<!ELEMENT equal ( %value;, %value;)>
<!ATTLIST equal caseless (no|yes) #IMPLIED>
<!ELEMENT begins-with ( %value;, %value;)>
<!ATTLIST begins-with caseless (no|yes) #IMPLIED>
<!ELEMENT ends-with ( %value;, %value;)>
<!ATTLIST ends-with caseless (no|yes) #IMPLIED>
<!ELEMENT contains-substring ( %value;, %value;)>
<!ATTLIST contains-substring caseless (no|yes) #IMPLIED>
<!ELEMENT in ( %value;, list)>
<!ATTLIST in caseless (no|yes) #IMPLIED>
<!ELEMENT list EMPTY>
<!ATTLIST list n IDREF #REQUIRED>
<!ELEMENT let ( %container;, %value;)>
<!ELEMENT append ( %value;)+>
<!ATTLIST append n IDREF #REQUIRED>
<!ELEMENT out (b|chunk)+>
<!ELEMENT modify-case ( %container;, %stringvalue;)>
<!ELEMENT call-macro (with-param)*>
<!ATTLIST call-macro n IDREF #REQUIRED>
<!ELEMENT with-param EMPTY>
<!ATTLIST with-param pos CDATA #REQUIRED>
<!ELEMENT clip EMPTY>
<!ATTLIST clip pos CDATA #REQUIRED
part CDATA #REQUIRED>
<!ELEMENT lit EMPTY>
<!ATTLIST lit v CDATA #REQUIRED>
<!ELEMENT lit-tag EMPTY>
199
200
APÉNDICE A. DTDS EN XML
<!ATTLIST lit-tag v CDATA #REQUIRED>
<!ELEMENT var EMPTY>
<!ATTLIST var n IDREF #REQUIRED>
<!ELEMENT get-case-from (clip|lit|var)>
<!ATTLIST get-case-from pos CDATA #REQUIRED>
<!ELEMENT case-of EMPTY>
<!ATTLIST case-of pos CDATA #REQUIRED
part CDATA #REQUIRED>
<!ELEMENT concat ( %value;)+>
<!ELEMENT chunk ( %value;)+>
<!ELEMENT pseudolemma ( %value;)>
<!ELEMENT b EMPTY>
<!ATTLIST b pos CDATA #IMPLIED>
A.5. DTD DEL MÓDULO POSTCHUNK
A.5.
201
DTD del módulo postchunk
DTD para el formato de las reglas de transferencia estructural del módulo postchunk. Esta definición viene con el paquete apertium (versión
2.0) que se puede descargar de http://www.sourceforge.net.
La descripción de los distintos elementos se encuentra en el apartado
3.5.4.
<!ENTITY % condition "(and|or|not|equal|begins-with|
ends-with|contains-substring|in)">
<!ENTITY % container "(var|clip)">
<!ENTITY % sentence "(let|out|choose|modify-case|
call-macro|append)">
<!ENTITY % value "(b|clip|lit|lit-tag|var|get-case-from|
case-of|concat)">
<!ENTITY % stringvalue "(clip|lit|var|get-case-from|
case-of)">
<!ELEMENT postchunk (section-def-cats,
section-def-attrs,
section-def-vars,
section-def-lists?,
section-def-macros?,
section-rules)>
<!ELEMENT section-def-cats (def-cat+)>
<!ELEMENT def-cat (cat-item+)>
<!ATTLIST def-cat n ID #REQUIRED>
<!ELEMENT cat-item EMPTY>
<!ATTLIST cat-item name CDATA #REQUIRED>
<!ELEMENT section-def-attrs (def-attr+)>
<!ELEMENT def-attr (attr-item+)>
<!ATTLIST def-attr n ID #REQUIRED>
<!ELEMENT attr-item EMPTY>
<!ATTLIST attr-item tags CDATA #IMPLIED>
<!ELEMENT section-def-vars (def-var+)>
202
APÉNDICE A. DTDS EN XML
<!ELEMENT def-var EMPTY>
<!ATTLIST def-var n ID #REQUIRED>
<!ELEMENT section-def-lists (def-list)+>
<!ELEMENT def-list (list-item+)>
<!ATTLIST def-list n ID #REQUIRED>
<!ELEMENT list-item EMPTY>
<!ATTLIST list-item v CDATA #REQUIRED>
<!ELEMENT section-def-macros (def-macro)+>
<!ELEMENT def-macro ( %sentence;)+>
<!ATTLIST def-macro n ID #REQUIRED>
<!ATTLIST def-macro npar CDATA #REQUIRED>
<!ELEMENT section-rules (rule+)>
<!ELEMENT rule (pattern, action)>
<!ATTLIST rule comment CDATA #IMPLIED>
<!ELEMENT pattern (pattern-item+)>
<!ELEMENT pattern-item EMPTY>
<!ATTLIST pattern-item n IDREF #REQUIRED>
<!ELEMENT action ( %sentence;)*>
<!ELEMENT choose (when+,otherwise?)>
<!ELEMENT when (test,( %sentence;)*)>
<!ELEMENT otherwise ( %sentence;)+>
<!ELEMENT test ( %condition;)+>
<!ELEMENT and (( %condition;),( %condition;)+)>
<!ELEMENT or (( %condition;),( %condition;)+)>
<!ELEMENT not ( %condition;)>
A.5. DTD DEL MÓDULO POSTCHUNK
<!ELEMENT equal ( %value;, %value;)>
<!ATTLIST equal caseless (no|yes) #IMPLIED>
<!ELEMENT begins-with ( %value;, %value;)>
<!ATTLIST begins-with caseless (no|yes) #IMPLIED>
<!ELEMENT ends-with ( %value;, %value;)>
<!ATTLIST ends-with caseless (no|yes) #IMPLIED>
<!ELEMENT contains-substring ( %value;, %value;)>
<!ATTLIST contains-substring caseless (no|yes) #IMPLIED>
<!ELEMENT in ( %value;, list)>
<!ATTLIST in caseless (no|yes) #IMPLIED>
<!ELEMENT list EMPTY>
<!ATTLIST list n IDREF #REQUIRED>
<!ELEMENT let ( %container;, %value;)>
<!ELEMENT append ( %value;)+>
<!ATTLIST append n IDREF #REQUIRED>
<!ELEMENT out (b|lu|mlu)+>
<!ELEMENT modify-case ( %container;, %stringvalue;)>
<!ELEMENT call-macro (with-param)*>
<!ATTLIST call-macro n IDREF #REQUIRED>
<!ELEMENT with-param EMPTY>
<!ATTLIST with-param pos CDATA #REQUIRED>
<!ELEMENT clip EMPTY>
<!ATTLIST clip pos CDATA #REQUIRED
part CDATA #REQUIRED>
<!ELEMENT lit EMPTY>
<!ATTLIST lit v CDATA #REQUIRED>
<!ELEMENT lit-tag EMPTY>
<!ATTLIST lit-tag v CDATA #REQUIRED>
203
204
APÉNDICE A. DTDS EN XML
<!ELEMENT var EMPTY>
<!ATTLIST var n IDREF #REQUIRED>
<!ELEMENT get-case-from (clip|lit|var)>
<!ATTLIST get-case-from pos CDATA #REQUIRED>
<!ELEMENT case-of EMPTY>
<!ATTLIST case-of pos CDATA #REQUIRED
part CDATA #REQUIRED>
<!ELEMENT concat ( %value;)+>
<!ELEMENT mlu (lu+)>
<!ELEMENT lu ( %value;)+>
<!ELEMENT b EMPTY>
<!ATTLIST b pos CDATA #IMPLIED>
A.6. DTD PARA REGLAS DE FORMATO
A.6.
205
DTD para las reglas de especificación de formato
DTD para las reglas de especificación de formato, que puede descargarse de la página web http://cvs.sourceforge.net/viewcvs.py/
apertium/apertium/apertium/format.dtd.
La descripción de los distintos elementos se encuentra en el apartado
3.6.2.
<!ELEMENT format (options,rules)>
<!ATTLIST format name CDATA #REQUIRED>
<!ELEMENT options (largeblocks, input, output,
escape-chars, space-chars, case-sensitive)>
<!ELEMENT largeblocks EMPTY>
<!ATTLIST largeblocks size CDATA #REQUIRED>
<!ELEMENT input EMPTY>
<!ATTLIST input zip-path CDATA #IMPLIED
encoding CDATA #REQUIRED>
<!ELEMENT output EMPTY>
<!ATTLIST output zip-path CDATA #IMPLIED
encoding CDATA #REQUIRED>
<!ELEMENT escape-chars EMPTY>
<!ATTLIST escape-chars regexp CDATA #REQUIRED>
<!ELEMENT space-chars EMPTY>
<!ATTLIST space-chars regexp CDATA #REQUIRED>
<!ELEMENT case-sensitive EMPTY>
<!ATTLIST case-sensitive value (yes|no) #REQUIRED>
<!ELEMENT rules (format-rule|replacement-rule)+>
<!ELEMENT format-rule (begin-end|(begin,end))>
<!ATTLIST format-rule eos (yes|no) #IMPLIED
priority CDATA #REQUIRED>
<!ELEMENT begin-end EMPTY>
<!ATTLIST begin-end regexp CDATA #REQUIRED>
206
APÉNDICE A. DTDS EN XML
<!ELEMENT begin EMPTY>
<!ATTLIST begin regexp CDATA #REQUIRED>
<!ELEMENT end EMPTY>
<!ATTLIST end regexp CDATA #REQUIRED>
<!ELEMENT replacement-rule (replace+)>
<!ATTLIST replacement-rule regexp CDATA #REQUIRED>
<!ELEMENT replace EMPTY>
<!ATTLIST replace source CDATA #REQUIRED
target CDATA #REQUIRED
prefer (yes|no) #IMPLIED>
A.7. DTD DE LOS PARADIGMAS DEL FORMULARIO
A.7.
207
DTD de los paradigmas del formulario
DTD para el formato de los ficheros de paradigmas que utiliza la herramienta de formularios. Esta definición viene con el paquete apertium-lexical-webform.
<!ELEMENT form (entry)+>
<!ATTLIST form
lang CDATA #REQUIRED
langpair CDATA #REQUIRED>
<!ELEMENT entry (endings, paradigms)+>
<!ATTLIST entry
PoS CDATA #REQUIRED
nbr CDATA #IMPLIED
gen CDATA #IMPLIED>
<!ELEMENT endings (stem, ending+)>
<!ELEMENT stem (#PCDATA)>
<!ELEMENT ending (#PCDATA)>
<!ELEMENT paradigms (par+)>
<!ATTLIST paradigms howmany CDATA #REQUIRED>
<!ELEMENT par EMPTY>
<!ATTLIST par n CDATA #REQUIRED>
208
APÉNDICE A. DTDS EN XML
209
APÉNDICE B. SÍMBOLOS GRAMATICALES
210
Apéndice B
Sı́mbolos gramaticales utilizados
en los módulos
B.1. Sı́mbolos gramaticales utilizados en los diccionarios
B.1.1. Lista de sı́mbolos
aa
acr
al
an
ant
cni
cnjadv
cnjcoo
cnjsub
def
dem
det
detnt
enc
f
fti
fts
ger
ifi
ij
imp
ind
inf
adjetivo-adjetivo (función antecedente relativo)
acrónimo
otros
adjetivo-nombre (función antecedente relativo)
antropónimo
condicional
conjunción adverbial
conjunción coordinativa
conjunción subordinativa
definido
demostrativo
determinante
determinante neutro
enclı́tico
femenino
futuro de indicativo
futuro de subjuntivo
gerundio
pretérito perfecto o indefinido
interjección
imperativo
indeterminado
infinitivo
B.1. SÍMBOLOS DE LOS DICCIONARIOS
itg
loc
lpar
lquest
m
mf
n
nn
np
nt
num
p1
p2
p3
pii
pis
pl
pos
pp
pr
preadv
predet
pri
prn
pro
prs
ref
rel
rpar
sent
sg
sp
sup
tn
vaux
vbhaver
vblex
vbmod
vbser
interrogativo
locativo
([
¿
masculino
masculino-femenino
nombre
nombre-nombre (función antecedente relativo)
nombre propio
neutro
numeral
primera persona
segunda persona
tercera persona
pretérito imperfecto de indicativo
pretérito imperfecto de subjuntivo
plural
posesivo
participio
preposición
preadverbio
predeterminante
presente de indicativo
pronombre
proclı́tico
presente de subjuntivo
reflexivo
relativo
)]
.?;:!
singular
singular-plural
superlativo
tónico
verbo auxiliar
verbo haver
verbo léxico
verbo modal
verbo ser
211
APÉNDICE B. SÍMBOLOS GRAMATICALES
212
B.1.2. Especificación de formas léxicas
Orden de colocación de las etiquetas en los diccionarios morfológicos
de este sistema (orden de izquierda a derecha en la tabla):
Adjetivos generales
(difı́cil, rojo)
Categorı́a
adj
Adjetivos interrogativos,
posesivos, indeterminados
y superlativos
(qué, tus, otra, buenı́simo)
Categorı́a
adj
Adverbios
(siempre, mañana)
Preadverbios
(muy, tan)
Adverbios interrogativos
(dónde)
Conjunciones adverbiales
(que, ası́ como)
Determinantes
(el, uno, este, mi)
Categorı́a
adv
Categorı́a
preadv
Categorı́a
adv
Categorı́a
cnjadv
cnjcoo
cnjsub
Categorı́a
det
Determinante neutros
(lo)
Predeterminantes
(todos)
Categorı́a
detnt
Categorı́a
predet
Interjecciones
(hola)
Nombres comunes
(casa, perro)
Categorı́a
ij
Categorı́a
n
n
n
Categorı́a
np
Nombres propios
(Pedro, Londres)
Género
m
f
mf
Tipo
itg
pos
ind
sup
Número
sg
pl
sp
Género
m
f
mf
Número
sg
pl
sp
Tipo
def
ind
dem
pos
Género
m
f
mf
Número
sg
pl
sp
Género
m
f
nt
Número
sg
pl
sp
Género
m
f
mf
Tipo
ant
loc
al
Número
sg
pl
sp
Tipo
itg
B.1. SÍMBOLOS DE LOS DICCIONARIOS
Acrónimos
(IRPF, INEM)
Categorı́a
n
Tipo
acr
Numerales
(tres)
Categorı́a
num
Género
m
f
mf
Preposiciones
(de, por)
Pronombres interrogativos
(quién, qué)
Categorı́a
pr
Categorı́a
prn
Pronombres enclı́ticos,
proclı́ticos y tónicos
de persona
(yo, vosotros, ayudarte,
te ayudo)
Categorı́a
prn
Pron. procl. reflexivo (se):
Pron. tón. reflexivo (si):
Pron. tónicos posesivos
(mı́o, suyo)
213
Género
m
f
mf
Número
sg
pl
sp
Número
sg
pl
sp
Tipo
enc
pro
tn
Género
m
f
Persona
p1
p2
p3
Número
sg
pl
Género
m
f
mf
nt
prn
prn
Categorı́a
prn
pro
tn
Tipo
tn
ref
ref
Pos.
pos
Otros pron. tónicos
(aquella, nadie, otro)
Categorı́a
prn
Tipo
tn
Relativos pronominales
y adjetivales
(que, cuyo)
Categorı́a
rel
Relativos adverbiales
(como, donde)
Verbos
(formas personales)
(subo, vamos)
Categorı́a
rel
Tipo
Verbos
(infinitivo y gerundio)
(cantar, buscando)
Tipo
vblex
vbser
vbhaver
vbmod
Tipo
vblex
vbser
vbhaver
vbmod
Tipo
nn
an
aa
Tipo
adv
Tiempo
y modo
cni
fti
fts
ifi
imp
pii
pis
pri
prs
Forma
inf
ger
Género
m
f
mf
nt
Género
m
f
f
p3
p3
Género
m
f
Número
sg
pl
sp
Verbos
(participio)
(dormido, cansadas)
vblex
vbser
vbhaver
vbmod
Tipo
itg
Forma
pp
Número
sg
pl
pl
Persona
Número
p1
p2
p3
sg
pl
Género
m
f
Número
sg
pl
Número
sg
pl
sp
mf
mf
Número
sg
pl
sp
sp
214
APÉNDICE B. SÍMBOLOS GRAMATICALES
B.2. Categorı́as del desambiguador
B.2.1. Desambiguador de español
Estas son las categorı́as o etiquetas gruesas con las que trabaja el desambiguador léxico categorial del español.
Etiqueta
PARAPR
PARAVBPRI
PARAVBIMP
QUECNJ
QUEREL
COMOPR1
COMOREL
COMOVB
MASADV
MASADJ
MASNP
ALGO
ACRONIMOM
ACRONIMOF
ACRONIMOMF
INTNOM
ADJINT
INTADV
PREADV
ADV
CNJSUBS
CNJCOORD
CNJADV
DETNT
DETM
DETF
DETMF
INTERJ
NOM
ANTROPONIM
1
Descripción
Etiquetas simples
Lexicalización para como preposición
Lexicalización para como verbo léxico
en presente de indicativo
Lexicalización para como verbo léxico
en imperativo
Lexicalización que como conjunción
Lexicalización que como relativo
Lexicalización como como preposición
Lexicalización como como relativo
Lexicalización como como verbo léxico
en presente de indicativo
Lexicalización más/menos como advervio
Lexicalización más/menos como adjetivo
Lexicalización Más como nombre propio
Lexicalización algo como nombre propio
Acrónimo
Acrónimo
Acrónimo
Pronombre interrogativo
Adjetivo interrogativo
Adverbio interrogativo
Advervio que puede preceder a otro
adverbio o adjetivo
Adverbio
Conjunción subordinante
Conjunción coordinante
Conjunción subordinante adverbial
Determinante neutro
Determinante
Determinante
Determinante
Interjección
Nombre
Nombre propio de persona
Cerrada
Ejemplos
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
No
No
No
Sı́
Sı́
Sı́
BCH
ONUH
ATS
quién, cuál
cuánto, qué
cuándo, dónde
Sı́
No
Sı́
Sı́
No
Sı́
Sı́
Sı́
Sı́
No
No
No
muy, bien, mal
nunca, ahı́
que
y, pero
si
lo
el, un
la, una
cada
ojalá, hola
casa, coche
Fernando
El analizador morfológico considera que como puede ser una preposición ya que puede sustituirse por en calidad de en algunos contextos (Ej.- ’Os hablo como director de la pelı́cula’
B.2. CATEGORÍAS DEL DESAMBIGUADOR
Etiqueta
TOPONIM
NPALTRES
NUM
PREDETNT
PREDET
PREP
PRNTNNT
PRNTN
PRNENCREF
PRNPROREF
PRNENC
PRNPRO
VLEXINF
VLEXGER
VLEXPARTPI
VLEXPFCI
VLEXIPI
VLEXSUBJ
VLEXIMP
VSERINF
VSERGER
VSERPARTPI
VSERPFCI
VSERIPI
VSERSUBJ
VSERIMP
VHABERINF
VHABERGER
VHABERPARTPI
VHABERPFCI
VHABERIPI
VHABERSUBJ
VMODALINF
VMODALGER
VMODALPARTPI
VMODALPFCI
VMODALIPI
VMODALSUBJ
Descripción
Nombre propio de lugar
Otros nombre propios
Numeral
Predetermiante neutro
Predeterminante Ej. todo
Preposición
Pronombre tónico neutro
Pronombre tónico
Pronombre enclı́tico reflexivo
Pronombre proclı́tico reflexivo
Pronombre enclı́tico
Pronombre proclı́tico
Verbo léxico en infinitivo
Verbo léxico en gerundio
Verbo léxico en participio
Verbo léxico en presente, futuro o
condicional de indicativo
Verbo léxico en pretérito imperfecto o
perfecto simple de indicativo
Verbo léxico subjuntivo
Verbo léxico imperativo
Verbo ser en infinitivo
Verbo ser en gerundio
Verbo ser en participio
Verbo ser en presente, futuro o
condicional de indicativo
Verbo ser en pretérito imperfecto o
perfecto simple de indicativo
Verbo ser subjuntivo
Verbo ser imperativo
Verbo haber en infinitivo
Verbo haber en gerundio
Verbo haber en participio
Verbo haber en presente, futuro o
condicional de indicativo
Verbo haber en pretérito imperfecto o
perfecto simple de indicativo
Verbo haber subjuntivo
Verbo modal en infinitivo
Verbo modal en gerundio
Verbo modal en participio
Verbo modal en presente, futuro o
condicional de indicativo
Verbo modal en pretérito imperfecto o
perfecto simple de indicativo
Verbo modal subjuntivo
215
Cerrada
No
No
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
No
No
No
Ejemplos
Alicante
Linux, Seat
tres, cuatro
todo
toda
ante, desde
algo, esto
ambos, nadie
se
se
me, nos
le, te
cantar, reı́r
hablando
dicho, cantado
No
digo, diré, dirı́a
No
No
No
Sı́
Sı́
Sı́
cantaba, dijo
hablase, dijeramos
canta, comed
ser
siendo
sido
Sı́
soy, seré, serı́a
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
era, fui
fueras
sé
haber
habiendo
habido
Sı́
hay, habrán, habrı́a
Sı́
Sı́
Sı́
Sı́
Sı́
habı́a, hubo
hubieran
deber, poder
debiendo
podido
Sı́
puede, deberá, podrı́a
Sı́
Sı́
podı́a, debió
pudiese, debiéramos
APÉNDICE B. SÍMBOLOS GRAMATICALES
216
Etiqueta
VMODALIMP
ADJM
ADJF
ADJMF
ADJPOS
REL
RELADV
PREPDET
PRCNJ
PRREL
INFLEXPRNENC
GERLEXPRNENC
IMPLEXPRNENC
INFSERPRNENC
GERSERPRNENC
IMPSERPRNENC
INFHABPRNENC
GERHABPRNENC
INFMODPRNENC
GERMODPRNENC
IMPMODPRNENC
LQUEST
LPAR
RPAR
CM
SENT
B.2.2.
Descripción
Verbo modal imperativo
Adjetivo
Adjetivo
Adjetivo
Adjetivo posesivo
Relativo
Relativo adverbial
Etiquetas compuestas
Contracción de preposición y determinante
Multipalabra formado por preposición y
conjunción
Multipalabra formado por preposición y
relativo
Verbo léxico en infinitivo con enclı́ticos
Verbo léxico en gerundio con enclı́ticos
Verbo léxico en imperativo con enclı́ticos
Verbo ser en infinitivo con enclı́ticos
Verbo ser en gerundio con enclı́ticos
Verbo ser en imperativo con enclı́ticos
Verbo haber en infinitivo con enclı́ticos
Verbo haber en gerundio con enclı́ticos
Verbo modal en infinitivo con enclı́ticos
Verbo modal en gerundio con enclı́ticos
Verbo modal en imperativo con enclı́ticos
Otras etiquetas
Apertura de frase interrogativa
Apertura paréntesis o corchete
Cierre paréntesis o corchete
Coma
Finalizador de oraciones
Cerrada
Sı́
No
No
No
Sı́
Sı́
Sı́
Ejemplos
poded, debed
gracioso
graciosa
inteligente
mı́o
quien, cuya
cuando, donde
Sı́
del, al
Sı́
a que
Sı́
No
No
No
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
en que
dármelo, cantarlo
cantándosela
dı́melo
serlo
siéndolo
sedlo
habérsela
habiéndole
poderla, deberlo
debiéndosela
debédmela
?
(, [
), ]
,
., :, ;, ?, !
Desambiguador de catalán
Dada la similitud con las categorı́as del desambiguador de español,
sólo se describen en la siguiente aquellas etiquetas que son nuevas o diferentes para el desambiguador de catalán.
Etiqueta
Descripción
MOLTADV
MOTLPREADV
VOLERMOD
VOLERLEX
Etiquetas simples
Lexicalización molt/gaire como adverbio
Lexicalización molt/gaire como adverbio
Lexicalización voler como verbo modal
Lexicalización voler como verbo léxico
Cerrada
Sı́
Sı́
Sı́
Sı́
Ejemplos
B.2. CATEGORÍAS DEL DESAMBIGUADOR
Etiqueta
VA
Descripción
Lexicalización va como forma del verbo anar
217
Cerrada
Sı́
Ejemplos
B.2.3. Desambiguador de gallego
Dada la similitud con las categorı́as del desambiguador de español,
sólo se describen en la siguiente aquellas etiquetas que son nuevas o diferentes para el desambiguador de gallego.
Etiqueta
VBIRNPS
VBIRPARTPI
VBIRPS
VBIRIMP
VHABERNPS
VHABERPARTPI
VHABERPS
VHABERIMP
APREP
VLEXNPS
VLEXPS
VSERNPS
VSERPS
VHABERNPS
VHABERPS
PREPDETM
PREPDETF
PREPDETN
PREPDETDET
PREPPRTNNT
Descripción
Etiquetas simples
Lexicalización ir como infinitivo
y gerundio
Lexicalización ir como participio
Lexicalización ir como formas personales
de indicativo
y subjuntivo
Lexicalización ir como imperativo
Lexicalización haber como infinitivo
y gerundio
Lexicalización haber como participio
Lexicalización haber como formas personales
de indicativo
y subjuntivo
Lexicalización haber como imperativo
Lexicalización a como preposición anar
Verbo léxico: infinitivo y gerundio
Verbo léxico: formas personales
de indicativo
Verbo ser: infinitivo y gerundio
Verbo ser: formas personales
de indicativo
Verbo haber: infinitivo y gerundio
Verbo haber: formas personales
de indicativo
Etiquetas compuestas
Contracción de preposición y
determinante masculino
Contracción de preposición y
determinante femenino
Contracción de preposición y
determinante neutro
Contracción de preposición y
dos determinantes
Contracción de preposición y
Cerrada
Ejemplos
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
No
achegar, achegándomos
No
Sı́
achegue, achegaré
ser, seres
Sı́
Sı́
fosen, es
haber
Sı́
achegue, achegaré
Sı́
do, ao
Sı́
da, ás
Sı́
do
Sı́
destoutro
218
Etiqueta
PREPPRNTN
PREPTNTN
PREPNUM
PREDETDET
determinante
INTADVDET
determinante
DETDETM
DETDETF
PRNPRN
PRNPRN
CNJCDET
CNJSUB
determinante
INFSERPRNENC
GERSERPRNENC
IMPSERPRNENC
INFHABPRNENC
GERHABPRNENC
INFMODPRNENC
GERMODPRNENC
IMPMODPRNENC
APÉNDICE B. SÍMBOLOS GRAMATICALES
Descripción
pronombre tónico neutro
Contracción de preposición y
pronombre tónico
Contracción de preposición y
dos pronombres tónicos
Contracción de preposición y
numeral
Contracción de predeterminante y
Sı́
Contracción de interrogativo adverbial y
Sı́
Contracción de dos determinantes masculinos
Contracción de dos determinantes femeninos
Contracción de dos pronombres tónicos
Contracción de dos pronombres proclı́ticos
Contracción de conjunción coordinada y
determinante
Contracción de conjunción subordinada y
Sı́
Verbo ser en infinitivo con enclı́ticos
Verbo ser en gerundio con enclı́ticos
Verbo ser en imperativo con enclı́ticos
Verbo haber en infinitivo con enclı́ticos
Verbo haber en gerundio con enclı́ticos
Verbo modal en infinitivo con enclı́ticos
Verbo modal en gerundio con enclı́ticos
Verbo modal en imperativo con enclı́ticos
Cerrada
Sı́
Ejemplos
daquilo
Sı́
daqueloutra
Sı́
nestoutra
Sı́
dunha
tódalas
u-la
Sı́
Sı́
Sı́
Sı́
ámbolos
ámbalas
esoutra
chas
Sı́
maila
cás
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
Sı́
serlo
siéndolo
sedlo
habérsela
habiéndole
poderla, deberlo
debiéndosela
debédmela
Apéndice C
Abreviaturas usadas en el texto
ANSI American National Standards Institute, instituto nacional norteamericano de estándares; cuando se usa informalmente en la expresión
texto ANSI, se refiere a un texto codificado en alguna de las codificaciones de un byte por carácter definidas en el estándar ISO-8859
[1].
ca Código ISO 639 de dos letras1 del catalán
DTD Definición del tipo de documento en XML
es Código ISO 639 de dos letras del español
eu Código ISO 639 de dos letras del euskera
FL Forma léxica (véase la página 7)
FLLM Forma léxica de la lengua meta
FLLO Forma léxica de la lengua origen
FS Forma superficial (véase la página 7)
gl Código ISO 639 de dos letras del gallego
HTML Hypertext markup language, lenguaje de marcas para hipertextos.
LM Lengua meta (lengua de llegada)
LO Lengua origen (lengua de partida)
RTF Rich text format, formato de texto enriquecido.
1
Véase http://www.w3.org/WAI/ER/IG/ert/iso639.htm
219
220
APÉNDICE C. ABREVIATURAS USADAS EN EL TEXTO
TA Traducción automática
XML Extensible markup language, lenguaje de marcas extensible.
221
[Nota: Afegir article de l’EAMT 2005 i citar-lo]
222
APÉNDICE C. ABREVIATURAS USADAS EN EL TEXTO
Bibliografı́a
[1] Unicode. http://www.unicode.org.
[2] R. Canals-Marote, A. Esteve-Guillén, A. Garrido-Alenda,
M. Guardiola-Savall, A. Iturraspe-Bellver, S. Monserrat-Buendia,
S. Ortiz-Rojas, H. Pastor-Pina, P.M. Perez-Antón, and M.L. Forcada.
El sistema de traducción automática castellano-catalán interNOSTRUM. Procesamiento del Lenguaje Natural, 27:151–156, 2001. XVII
Congreso de la Sociedad Española de Procesamiento del Lenguaje
Natural, Jaén, Spain, 12-14.09.2001.
[3] D. Cutting, J. Kupiec, J. Pedersen, and P. Sibun. A practical part-ofspeech tagger. In Third Conference on Applied Natural Language Processing. Association for Computational Linguistics. Proceedings of the Conference., pages 133–140, Trento, Italia, 31 marzo–3 abril 1992.
[4] A. Garrido, A. Iturraspe, S. Montserrat, H. Pastor, and M. L. Forcada. A compiler for morphological analysers and generators based on
finite-state transducers. Procesamiento del Lenguaje Natural, (25):93–98,
1999.
[5] Alicia Garrido-Alenda and Mikel L. Forcada. Morphtrans: un lenguaje y un compilador para especificar y generar módulos de transferencia morfológica para sistemas de traducción automática. Procesamiento del Lenguaje Natural, 27:157–164, 2001.
[6] Alicia Garrido-Alenda, Mikel L. Forcada, and Rafael C. Carrasco. Incremental construction and maintenance of morphological analysers
based on augmented letter transducers. In Proceedings of TMI 2002
(Theoretical and Methodological Issues in Machine Translation, Keihanna/Kyoto, Japan, March 2002), pages 53–62, 2002.
[7] Alicia Garrido-Alenda, Patrı́cia Gilabert Zarco, Juan Antonio PérezOrtiz, Antonio Pertusa-Ibáñez, Gema Ramı́rez-Sánchez, Felipe
223
224
BIBLIOGRAFÍA
Sánchez-Martı́nez, Miriam A. Scalco, and Mikel L. Forcada. Shallow
parsing for portuguese-spanish machine translation. In A. Branco,
A. Mendes, and R. Ribeiro, editors, TASHA 2003: Workshop on Tagging
and Shallow Processing of Portuguese, pages 21–24, October 2003.
[8] N. Ide. The XML Framework and Its Implications for the Development of
Natural Language Processing Tools. Luxembourg, 2000.
[9] M.E. Lesk. Lex — a lexical analyzer generator. Technical Report Technical Report 39, AT&T Bell Laboratories, Murray Hill, N.J., 1975.
[10] Mehryar Mohri. Finite-state transducers in language and speech processing. Computational Linguistics, 23(2):269–311, 1997.
[11] Sergio Ortiz-Rojas, Mikel L. Forcada, and Gema Ramı́rez-Sánchez.
Construcción y minimización eficiente de transductores de letras a
partir de diccionarios con paradigmas. Procesamiento del Lenguaje Natural, (25):51–57, 2005.
[12] Ferran Pla and Antonio Molina. Improving part-of-speech tagging
using lexicalized HMMs. Journal of Natural Language Engineering,
10(2):167–189, June 2004.
[13] L. R. Rabiner. A tutorial on hidden Markov models and selected applications in speech recognition. Proceedings of the IEEE, 77(2):257–
286, 1989.
[14] E. Roche and Y. Schabes. Introduction. MIT Press, Cambridge, Massachusetts, 1997.
[15] E. Roche and Y. Schabes. Introduction. In E. Roche and Y. Schabes,
editors, Finite-State Language Processing, pages 1–65. MIT Press, Cambridge, Mass., 1997.
[16] J. L. A. van de Snepscheut. What computing is all about. SpringerVerlag, New York, 1993.
[17] Patrı́cia Gilabert Zarco, Javier Herrero-Vicente, Sergio Ortiz-Rojas,
Antonio Pertusa-Ibáñez, Gema Ramı́rez-Sánchez, Felipe SánchezMartı́nez, Marcial Samper-Asensio, Mı́riam A. Scalco, and Mikel L.
Forcada. Construcción rápida de un sistema de traducción automática español-portugués partiendo de un sistema español–catalán. Procesamiento del Lenguaje Natural, (32):279–285, 2003. (Actas del XIX congreso de la Sociedad Española de Procesamiento del Lenguaje Natural).