5.5.4 El intercambio de información terminológica

ISSN: 1139-8736
Depósito Legal: B-39120-2002
Copyright: © Chantal Pérez

5.5.4 El intercambio de información terminológica

En repetidas ocasiones a lo largo de este trabajo hemos hecho referencia a uno de los problemas más importantes a los que la moderna terminología debe hacer frente de forma ineludible: la necesidad de reutilizar la información terminológica. Indudablemente, todas aquellas empresas que tienen como objetivo la recopilación y organización de información, sea ésta del tipo que sea, deben plantearse desde un principio qué garantías presenta ese cuerpo de información de ser reutilizado en empresas para las que inicialmente no fue concebido. En algunos ámbitos de investigación, tales como el de las bases de datos y sistemas de información en general, éste aspecto es, junto con el de la seguridad y coherencia de los datos, al que más tiempo se le ha dedicado en las últimas tres décadas (Gardarin & Valduriez 1989).

Sería de esperar, por tanto, que en un campo que tiene como principal objetivo la organización y almacenaje estructurado de un cuerpo de información complejo (una base de datos terminológica), aprovechando la experiencia obtenida en los campos antes mencionados, hiciese un esfuerzo por adoptar determinadas técnicas y recursos enfocados a garantizar esta reutilización. De hecho, como mencionamos en el apartado 3.1.1, los esfuerzos de normalización, en su vertiente de regulación metodológica, han sido y están siendo muchos por parte de organismos de estandarización internacionales (ISO, TEI, LISA).

En la actualidad, sin embargo, la mayoría de los sistemas gestores de bases de datos terminológicas existentes en el mercado permiten la exportación de sus datos a formato texto o texto enriquecido (RTF), pero casi ninguno permite la importación de datos de otras fuentes que no sean ficheros en su propio formato "propietario". Esto no causa problemas siempre y cuando sólo se pretenda presentar la información recopilada en formato textual, pero no permite la reutilización efectiva por parte de sistemas de información dispares, característica deseable y necesaria para los profesionales de la terminología y las empresas que alquilan sus servicios.

Podemos explicar el problema que resulta de la multiplicidad de formatos utilizando a modo de símil, aun siendo un ámbito íntimamente relacionado, el bien conocido problema n(n-1) que se da en los sistemas de traducción automática basados en transferencia. En un sistema de este tipo serán necesarios exactamente n(n-1) módulos de transferencia para cada lengua, siendo n el número de lenguas que el sistema pretenda traducir. Exactamente el mismo problema se plantea en el ámbito del intercambio de información, sea ésta terminológica o de cualquier otra naturaleza. La Figura 29 muestra este problema gráficamente:


A->B		A->C		A->D		A->E		A->F

B->A		B->C		B->D		B->E		B->F

C->A		C->B		C->D		C->E		C->F

D->A		D->B		D->C		D->E		D->F

E->A		E->B		E->C		E->D		E->F

F->A		F->B		F->C		F->D		F->E

Figura 29: Número de conversores necesarios.

Los conversores marcados en esta tabla son sólo los necesarios para convertir entre el formato A y el resto de formatos, 10 en total, resultado de la operación 2(6-1). También podemos ver cómo la fórmula que define el número total de conversores para n formatos es n(n-1), en este caso 6(6-1)=30. Si además tenemos en cuenta que los distintos fabricantes suelen modificar los formatos entre versiones de un mismo programa, el número crece exponencialmente.

El crecimiento exponencial de los módulos de conversión es ya por sí solo razón suficiente para tratar de encontrar un punto de encuentro, siguiendo con nuestro símil, una interlingua, entre los distintos formatos. Este problema, como venimos insistiendo, no es privativo de la terminología, sino que atañe a todos aquellos campos que se engloban dentro de las tecnologías de la información. En el campo de los procesadores de texto y el documento con formato en general, el problema, quizás por ser más acuciante debido al elevado número de usuarios, ha recibido mayor atención y se han aportado soluciones que se han adoptado en mayor o menor medida en la industria, de las que sin duda el formato RTF (Rich Text Format) ha sido el que más éxito ha obtenido hasta la fecha.¹⁰⁸

En esta línea, como adelantábamos en el apartado anterior, la norma ISO 12200: MARTIF (Machine-Readable Terminology Interchange Format) ha sido desarrollada con la finalidad de facilitar el intercambio de recursos terminológicos en formato electrónico.

El objetivo de MARTIF es, por decirlo llanamente, convertirse en "el RTF de las bases terminológicas". De este modo, al igual que su homólogo textual, MARTIF pretende servir de "interlingua" terminológica, garantizando el intercambio entre usuarios (individuos o corporaciones) que utilizan software y hardware dispares.

El otro concepto importante que ha de ser tomado en consideración al hablar de un estándar de intercambio de información es, por supuesto, la pérdida de información. En este sentido, entra en juego un concepto fundamental en las tecnologías de la información: el modelo de datos.¹⁰⁹ Como mencionamos en el apartado 5.2, en los sistemas gestores de bases de datos terminológicas modernos, la disparidad de modelos de datos es mayor de lo que en principio pudiera pensarse, debido a que muchos de ellos, sin duda los mejor aceptados por parte del usuario final, permiten a éste la definición de un modelo de datos individualizado para cada una de sus bases de datos (por ejemplo, Trados Multiterm^TM). Evidentemente, no es posible crear un algoritmo de conversión de un modelo de datos a otro, si no se conoce de antemano cuál es el modelo de datos. A la hora de intercambiar información terminológica almacenada en dos bases de datos distintas pueden darse tres situaciones bien diferenciadas:

Tanto el sistema gestor de bases terminológicas A como el B se basan en un modelo de datos único, aunque distintos el uno del otro. En este caso es factible, aunque costoso, que los fabricantes A y B creen sus propios algoritmos de conversión, o "filtros", desde sus respectivos productos al otro. La pérdida de información se producirá únicamente en aquellos casos en los que el modelo de datos difiera ostensiblemente.
El sistema A se basa en un modelo de datos único, mientras que el sistema B se basa en un modelo de datos definible por el usuario. En este caso el fabricante del sistema A puede construir un modelo de datos sobre la marcha, que genere durante la conversión un esquema conceptual en formato legible por B idéntico al original, que, posteriormente, el usuario del sistema B podrá modificar. En este caso la pérdida de información será nula o despreciable, dando por supuesta una flexibilidad real en cuanto a la definición del modelo de datos, así como la posibilidad de la generación de modelos de datos off-line por parte del sistema B. En el otro sentido, sin embargo, la conversión de datos no es posible, ya que el fabricante del sistema B, aunque conoce el modelo de datos de A, no puede prever cuál va a ser el definido por el usuario de su sistema. Únicamente sería factible realizar un análisis del modelo creado por el usuario y mostrar un índice de perdida de información al convertir los datos al formato de B, que el usuario podría aceptar o rechazar.
Ambos sistemas se basan en un modelo de datos definible por el usuario. En este caso cualquier intento de conversión entre formatos simplemente no es factible, dado el prohibitivo índice de pérdida de información.

Estas tres posibilidades (cuatro, realmente) se producen únicamente entre dos sistemas de gestión terminológica, pero, como hemos expuesto anteriormente, el problema es exponencial al aumentar el número de sistemas. Ante esta situación se pueden dar dos posibilidades para garantizar en cierta medida el intercambio de información entre dos sistemas:

Suponiendo que antes del comienzo del proyecto se tenga la intención de compartir la información resultante, las dos partes, A y B, pueden estipular o negociar, de antemano, la utilización de un mismo modelo de datos. Pero además, en el caso de una base de datos terminológica, puesto que los distintos gestores emplean distintos modelos internos de representación (ver nota al pie 109), esto implica la utilización del mismo gestor de bases de datos terminológicas. Siguiendo con el símil del intercambio de documentos, esta opción, denominada intercambio negociado, equivaldría a que ambas partes accedieran a utilizar un procesador de texto determinado y siguiendo un formato determinado en cuanto tipos de letra, formato de párrafos, márgenes, etc, es decir, la adopción de una "hoja de estilo" común.
Utilizar un formato de intercambio de datos ciego, es decir, una interlingua para información terminológica. El intercambio es "ciego" (Hardman 2000, Melby 1998) porque ninguna de las dos partes puede "ver" a la otra. Esto equivaldría al empleo del formato RTF para el intercambio de documentos, es decir, ninguna de las dos partes tiene por qué saber a qué sistema gestor (o procesador de textos), serán importados los datos, ni de cuál provienen.

La creación de un formato que permita este último tipo de intercambio de información terminológica ha sido durante algunos años el objetivo del Comité Técnico Nº 37 de ISO, culminando en la especificación MARTIF para intercambio ciego de información terminológica (Melby 1997). El formato resultante de esta especificación, que aún está por completarse en sus últimos detalles, recibe el nombre de TBX (TermBase eXchange).

MARTIF tiene su origen en el proyecto TEI,¹¹⁰ y se basa en XML, el nuevo subconjunto de SGML que está llamado a convertirse en el sustituto del desfasado HTML para la publicación de documentos en la Web. De este modo, no sólo se posibilita el intercambio de recursos terminológicos entre instituciones y empresas, sino que también se hace posible el intercambio de recursos a través de la red.

XML (eXtensible Markup Language) presenta los requisitos para representar independientemente de la plataforma (al igual que su antecesor) no sólo documentos con formato sino también (a diferencia de éste) información estructurada. Para mostrar la diferencia entre un documento HTML y un documento XML a continuación mostramos un documento XML simple, primero su código fuente (Figura 30), es decir, lo que mostraría un editor de texto ASCII, y a continuación la interpretación que de él hace un editor XML (Figura 31):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Bookstore SYSTEM "bookshop.dtd">
<Bookstore><br>
   <!--J&R Booksellers Database-->
   <Book Genre="Fiction" In_Stock="Yes">
      <Title>The Round Door</Title>
      <Author>Tom Evans</Author>
      <Year_Published>1996</Year_Published>
      <ISBN>0-9546-0274-3</ISBN>
      <Price>$23.00</Price>
      <Review>An Intriguing Tale Of A Round Door In A Wall</Review>
   </Book>
   <Book Genre="Non-Fiction" In_Stock="Yes">
      <Title>Creating Real Xml Applications</Title>
      <Author>Bill Eaton</Author>
      <Year_Published>1998</Year_Published>
      <ISBN>7-4562-0167-8</ISBN>
      <Price>$35.00</Price>
      <Review>A Look At How To Build Real Xml Applications</Review>
   </Book>
   <Book Genre="Fiction" In_Stock="No">
      <Title>Over The Hills Of Yukon</Title>
      <Author>Bert Colewell</Author>
      <Year_Published>1993</Year_Published>
      <ISBN>5-6524-3054-1</ISBN>
      <Price>$22.00</Price>
      <Review>A Warm Story About A Man And A Moose In Yukon</Review>
   </Book>
   <Book Genre="Fiction" In_Stock="Yes">
      <Title>The Lion's Gold</Title>
      <Author>Daphne Griswald</Author>
      <Year_Published>1989</Year_Published>
      <ISBN>6-7896-2498-2</ISBN>
      <Price>$15.00</Price>
      <Review>One Of The Most Compelling Books Since "The Tiger's Silver".</Review>
   </Book>
</Bookstore>

Figura 30: Código fuente de un documento XML.

Figura 31: Resumen de la estructura de base de datos en el CLS Framework

Para esta interpretación, el editor o intérprete XML hace uso del DTD (Document Type Definition) correspondiente, mostrado en el documento fuente. En este caso es obviamente muy simple:


<!--   A Sample DTD for the Bookshop Demo  -->

<!ELEMENT Bookstore (Book+)>
<!ELEMENT Book (Title, Author, Year_Published, ISBN, Price, Review)>
<!ATTLIST Book
	  Genre (Fiction I

Non-Fiction) "Fiction"
	  In_Stock (Yes I

No) "Yes">
<!ELEMENT Title (#PCDATA)>
<!ELEMENT Author (#PCDATA)>
<!ELEMENT Year_Published (#PCDATA)>
<!ELEMENT ISBN (#PCDATA)>
<!ELEMENT Price (#PCDATA)>
<!ELEMENT Review (#PCDATA)>

El DTD implementado para MARTIF es mucho más complejo, distribuido en tres ficheros, de los cuales mostramos a continuación el segundo, donde se expresa el cuerpo de un documento MARTIF:



<!--  *****  MARTIF BODY DTD (revised 1997.February.19) *****  -->
<!--  *****  Defines the body element of the MARTIF DTD **** -->

<!ENTITY %     AuxInfo        'descrip I

descripGrp I

admin I

adminGrp I

ptr I

ref I

date I

note'  >

<!ELEMENT body           - -  (termEntry+)  >

<!—termEntry = one concept entry: ideally, one concept, one entry -->
<!ELEMENT termEntry      - -  ((%AuxInfo;)*, (langSet I

tig I

ntig)+) >
<!ATTLIST termEntry      %a.global;
                         type CDATA          #IMPLIED  >

<!—langSet = cluster of terms in one language plus associated info -->
<!ELEMENT langSet        - -  ((%AuxInfo;)*, (tig I

ntig)+) >
<!ATTLIST langSet        %a.global;
                         type CDATA          #IMPLIED  >

<!-- tig='terminological information group (flat)' -->
<!ELEMENT tig            - -  (term, (termNote)*,
                              (descrip I

admin I

ptr I

ref I

date I

note)*)  >
<!ATTLIST tig            id   ID        #IMPLIED
                         lang CDATA     #IMPLIED >

<!-- ntig ='terminological information group, nested'  -->
<!ELEMENT ntig           - -  (termGrp,
                              (%AuxInfo;)*) >
<!ATTLIST ntig           id   ID        #IMPLIED
                         lang CDATA     #IMPLIED >

<!ELEMENT term           - -  (%bText;)  >
<!ATTLIST term           %a.global       >

<!ELEMENT termGrp        - -  (term, (termNote I

termNoteGrp I

ptr I

ref I

date I

note)* )  >
<!ATTLIST termGrp        %a.global; >

<!ELEMENT termNoteGrp    - -  (termNote,
                         (ptr I

ref I

date I

note)* )  >
<!ATTLIST termNoteGrp    %a.global; >

<!ELEMENT descripGrp     - -  (descrip,
                         (ptr I

ref I

date I

descripNote I

note)* )  >
<!ATTLIST descripGrp     %a.global;              >

<!ELEMENT adminGrp       - -  (admin,
                         (ptr I

ref I

date I

adminNote I

note)* )  >
<!ATTLIST adminGrp       %a.global;      >

<!ELEMENT descrip        - -  (%dText;)  >
<!ATTLIST descrip        %a.global;
                         type CDATA          #REQUIRED >

<!ELEMENT admin          - -  (%bText;)  >
<!ATTLIST admin          %a.global;
                         type CDATA          #REQUIRED >

<!ELEMENT termNote       - -  (%nText;)  >
<!ATTLIST termNote       %a.global;
                         type CDATA          #REQUIRED >

<!ELEMENT descripNote    - -  (%nText;)  >
<!ATTLIST descripNote    %a.global;
                         type CDATA          #REQUIRED >

<!ELEMENT adminNote      - -  (%nText;)  >
<!ATTLIST adminNote      %a.global;
                         type CDATA          #REQUIRED >

Haciendo uso de este DTD, un editor o intérprete XML es capaz de "entender" un documento MARTIF y procesarlo adecuadamente. Los implementadores de MARTIF han desarrollado un conjunto de herramientas para facilitar y añadir funcionalidad al tratamiento de documentos, entre ellos, un programa "validador" de documentos MARTIF y un conversor a HTML para su visualización en navegadores convencionales.¹¹¹ Tras convertir el documento Martif, según se muestra en la Figura 32, obtenemos los dos documentos HTML (índice + entradas terminológicas) que mostramos en el apéndice IV.

Figura 32: Conversor MARTIF -> HTML

La ventaja obvia de disponer de tal herramienta es la publicación en web de forma directa, ya que la generación de documentos HTML puede ser realizada bajo demanda a través de un formulario web. Como podemos observar, el documento ofrecido es una entrada terminológica completa, incluyendo índice de entradas (primer documento) e información compartida (back matter) al final del documento que contiene las entradas. Así mismo, el cuerpo de la entrada contiene enlaces a posibles objetos binarios (imágenes, audio, etc.) y otros elementos a los que se hace referencia en el documento MARTIF original mediante punteros.

Por tanto, MARTIF es una especificación que hace uso de las tecnologías más avanzadas en cuanto a representación y organización de información de un modo independiente de la plataforma, por lo que se configura como un formato estándar para el intercambio flexible de información terminológica entre sistemas basados en hardware y software dispares.

En este sentido, y a juzgar por el parcial éxito del formato RTF, existe un factor fundamental que a medio y largo plazo va a determinar el éxito de MARTIF. Se trata de la implementación que de él se haga por parte de los distintos fabricantes de herramientas previamente establecidas en el mercado y otros nuevos. Recordemos que MARTIF es únicamente una especificación basada en otros estándares de intercambio de información (SGML y XML), que debe ser implementada por los distintos fabricantes de herramientas de ayudas a la traducción.

Por tanto, no se trata sólo de acoger una iniciativa de estandarización, sino de llevarla a cabo correctamente. Esto es lo que, dentro del proyecto OncoTerm, hemos intentado. En el apartado siguiente describimos el gestor de terminología de OntoTerm, que basado en las categorías de datos del CLS Framework, el modelo de datos Reltef^TM (Hardman 2000), implementa Martif.

Notas

¹⁰⁸ No deberíamos tampoco ignorar otros dos formatos de presentación de documentos con formato independientes de la plataforma: PostScript y Acrobat PDF (Portable Document Format). Sin embargo, éstos no permiten la reutilización efectiva del formato ya que únicamente es posible, además de la visualización en pantalla y la impresión en papel, la extracción de texto sin formato, es decir, no son formatos editables.

¹⁰⁹ Este término, proveniente del ámbito de las bases de datos, hace referencia al esquema conceptual (en realidad, el término original) existente en toda base de datos que cumple con la arquitectura ANSI/X3/SPARC, donde se consideran, además de este nivel, los niveles interno y externo, entre los cuales se sitúa el primero. Es en este nivel conceptual donde el administrador de la base de datos organiza la estructura de los datos, decide qué entidades van a ser consideradas en el sistema, qué propiedades van a tener y qué relaciones van a establecerse entre esas entidades. En la actualidad, y sobre todo dentro del ámbito de las bases de datos terminológicas, se emplea el término modelo de datos para hacer referencia a este esquema conceptual. Este término no es nuevo, sino que surge evidentemente del uso original del termino "modelado conceptual", que se refiere a la actividad de organización del esquema conceptual.

¹¹⁰ Ver http://etext.virginia.edu/TEI.htm especialmente la sección dedicada a bases de datos terminológicas, Parte 3; también Melby, Schmitz y Wright (en prensa) detallan el desarrollo de MARTIF (denominado en sus orígenes TIF) a partir de otros modelos anteriores de intercambio de datos como MATER y MicroMATER.

¹¹¹ La siguiente generación de navegadores web tendrá soporte para documentos XML.

Índice General I Índice Capítulo 5 I Siguiente