Figura 18: Cuadro de diálogo para añadir conceptos.
| ISSN: 1139-8736 Depósito Legal: B-39120-2002 Copyright: © Chantal Pérez |
Teniendo en cuenta todo lo expuesto hasta ahora en este capítulo, podríamos resumir las características que exigimos en un sistema de representación terminológica basada en conceptos en las siguientes:
Evidentemente, el primer problema con el que nos encontramos a la hora de poner en práctica nuestras ideas es la disponibilidad de un sistema de estas características. Por un lado, las aplicaciones de gestión terminológica disponibles en el mercado no ofrecen este tipo de características avanzadas, pues se reducen a la organización del conjunto de términos en torno a conceptos, cuyo estatus dentro del sistema no está claro. Por otro, las aplicaciones y sistemas que sí permiten la construcción de un sistema conceptual u ontología, no están preparadas para la gestión terminológica.
En el primero de los grupos se enmarcan las aplicaciones comerciales que, a pesar de carecer de un sistema conceptual adecuado, gozan de una gran difusión entre los usuarios de herramientas de gestión terminológica. De entre estos destaca, sin duda, TRADOS MultiTerm. Resulta interesante resaltar lo que para los creadores de este sistema significa significa "terminología orientada al concepto":quot;terminología orientada al conceptosignifica "terminología orientada al concepto":quot;:97
An entry always corresponds to one concept. This is why terminologists call MultiTerm "concept-oriented." For the English homonym "plane", you would create at least two entries: one for airplane, and one for the tool used to create a smooth surface on wood.
Dicho de otro modo: un gestor terminológico merece el calificativo de "orientado al concepto" si permite almacenar palabras homónimas. Sin duda el terminólogo moderno necesita herramientas que se tomen su trabajo mucho más en serio; de poco sirve postular la necesidad de realizar terminología basada u orientada al concepto si el enorme trabajo que supone la estructuración conceptual pormenorizada en un dominio no va a quedar plasmado en modo alguno en el resultado final.
Sin salir del ámbito de la terminología, el único sistema que permite una representación del sistema conceptual subyacente a una terminología es CODE4 (Skuce & Lethbridge 95). Este sistema se utilizó en la ejecución del proyecto Cogniterm desde 1991.98 CODE4 evolucionó hacia la herramienta llamada IKARUS (1996-97), la cual aportaba como novedad fundamental el estar escrita en Java, de modo que, en teoría podía ejecutarse a través de Internet desde cualquier navegador con una Máquina Virtual Java integrada. En nuestra experiencia, sin embargo, jamás conseguimos hacerla funcionar de este modo, dando señales de ser una aplicación extremadamente inestable. Tal vez debido a esto, IKARUS dejó de existir pronto para transformarse en la herramienta que este grupo canadiense está desarrollando en el presente: DOCKMAN, la cual, aunque también está escrita en Java, no se ofrece para su uso a través de Internet. Sus creadores resaltan las siguientes características fundamentales de este sistema:
DOCKMAN, por tanto, parece aglutinar las facilidades de CODE para la representación del conocimiento junto a herramientas de extracción de términos y gestión de córpora, basadas éstas últimas en el ya citado trabajo de J. Kavanagh, el TEXT ANALYZER.
Aunque no tenemos experiencia directa con este sistema o sus antecesores, algo que se desprende de las publicaciones en las que sus autores lo describen (Lethbridge & Skuce 1992; Skuce & Lethbridge 94, 95; Meyer, Eck & Skuce 1997), es el hecho es que nunca se ha empleado para la creación de una ontología a gran escala tal y como la que nosotros nos planteamos utilizar, por lo que pensamos que quizá este sistema está pensado para trabajar con pequeños dominios conceptuales en los que las relaciones entre los distintos conceptos puedan ser fácilmente controladas. Tampoco encontramos una descripción clara del tratamiento concreto que se ofrece para la gestión de información terminológica en lo que respecta a cuestiones fundamentales como son las categorías de datos o el intercambio de información. En realidad, toda la información lingüística asignada al término parece ser un único valor de un atributo, algo que dista mucho de lo que consideramos idóneo.
Incluso así éste es, sin duda, el sistema que más se acerca en cuanto a filosofía de diseño a OntoTerm®, el sistema gestor de conocimiento que hemos utilizado para la representación de información terminográfica y su estructuración conceptual. Como puntos destacados de este sistema, deberíamos resaltar los siguientes:
Estas características son las que han hecho posible que podamos manipular un cuerpo estructurado de conocimiento tan complejo como es la ontología de Mikrokosmos de forma relativamente sencilla, facilitando la integración de los conceptos específicos a nuestro ámbito de especialidad. Para describir de forma sucinta las funcionalidades de OntoTerm y las posibilidades que ofrece en el trabajo terminográfico, veamos cómo procedimos para incluir (y editar, borrar, modificar, etc.) la información referente a uno de los conceptos de la ontología: MYELOID-LEUKEMIA.99
Lo primero que tuvimos que hacer fue localizar la posición del concepto en la ontología, es decir, el concepto superordinado de nuestro concepto. En este caso, la elección del concepto padre de MYELOID-LEUKEMIA nos venía dada, puesto que la clasificación de neoplasias incluidas en la ontología está tomada del ICD-9 CM (ver sección 4.3.3.3),100 en la que la que MYELOID-LEUKEMIA se clasifica como un tipo de MALIGNANT-NEOPLASM-OF-LYMPHATIC-AND-HEMATOPOIETIC-TISSUE.
La siguiente captura de pantalla muestra el cuadro de diálogo en el que se añaden conceptos nuevos en la ontología. Como puede apreciarse en dicho cuadro de diálogo se especifica el tipo de concepto que se añade (EVENT, OBJECT, ATTRIBUTE o RELATION), se elige también el concepto superordinado, el tipo de relación que les une (INSTANCE-OF o IS-A) y puede, además, añadirse una definición, tomada en este caso del UMLS Metathesaurus:
Figura 18: Cuadro de diálogo para añadir conceptos.
Siguiendo el mismo procedimiento, incluimos a continuación los conceptos subordinados de MYELOID-LEUKEMIA (también obtenidos del ICD-9 CM). Una vez añadida esta información, podemos comprobar el concepto (o conceptos) superordinados y subordinados de MYELOID-LEUKEMIA en la pantalla de edición principal del editor de ontologías. Como muestra la siguiente captura, esta pantalla de edición nos permite en su barra de herramientas tener acceso a las funciones básicas del gestor de ontologías. A la hora de visualizar un concepto, la ficha de esta pantalla denominada description nos ofrece la información que hemos añadido sobre su conceptos super- y subordinados, su definición e identifica, en la parte inferior del editor, a MYELOID-LEUKEMIA como un concepto (en este caso un EVENT), añadido por un miembro de OncoTerm (para diferenciarlos de los conceptos ya existentes en la ontología de Mikrokosmos):
Figura 19: Pantalla de edición principal del Ontology Editor.
Además de la descripción básica del concepto, esta pantalla nos permite especificar las propiedades del concepto, el tipo de información que, sin lugar a dudas, más enriquece la ontología. Con ventanas de edición de estructura similar a la que nos permite añadir los conceptos (véase Figura 18), añadimos las RELACIONES y los ATRIBUTOS del concepto:
Figura 20: Cuadro de diálogo para añadir relaciones.
Al añadir esta relación, indicamos de forma explícita que la anemia es uno de los síntomas de MYELOID-LEUKEMIA. Una vez (o a la vez) que añadimos las relaciones de éste concepto con otros conceptos de la ontología y los atributos pertinentes, ambos tipos de información pueden verse resumidos en la pantalla de edición principal, en la ficha correspondiente a PROPERTIES:
Figura 21: Relaciones y Atributos en el Ontology Editor.
En el proceso de entrada de información que acabamos de mostrar, hay un hecho que no debemos dejar que pase desapercibido, ya que muestra la complejidad de la estructura de la ontología y la inherente consistencia que impone en el proceso de trabajo. Ya mencionamos anteriormente que en la estructura de la ontología original de Mikrokosmos, tanto relaciones como atributos se consideran conceptos de la ontología, con respectivas ramas en la jerarquía, sus definiciones y su explicitación por medio de la asignación de DOMAINs y RANGEs. Este hecho implica que, para poder asignar una relación o un atributo a un concepto de terminado, dicha relación o atributo se haya tenido que insertar previamente en su lugar correspondiente de la ontología. El gestor de ontologías, además, obliga al usuario a crear a la vez una relación y su relación inversa, actualizando después de forma automática la información de la ontología. Si volvemos a la captura de pantalla de la Figura 21, vemos que, en nuestro ejemplo, hemos usado en la descripción de nuestro concepto las relaciones AFFECTS-PHYSIOLOGICAL-SYSTEM, DIAGNOSED-WITH, HAS-SYMPTOM y TREATED-WITH y los atributos AFFECTED-POPULATION-AGE y DISEASE-PROGRESS-RATE. Para poder usarlas, debimos incluirlas previamente en sus lugares correspondientes de la ontología:
Figura 22: Relaciones en el Ontology Editor.
Como se puede observar en las capturas de pantalla, la relación AFFECTS-PHYSIOLOGICAL-SYSTEM es un concepto subordinado de la relación AFFECTS-BODY-PART. Además, hemos añadido la relación inversa PHYSIOLOGICAL-SYSTEM-AFFECTED-BY en su lugar correspondiente de la jerarquía (INVERSE-DISEASE-EVENT-OBJECT-RELATION).
Otro aspecto importante de la estructuración de la ontología que se hace patente en la Figura 21, en la que mostrábamos la pantalla principal de las relaciones y los atributos, es el hecho de que los conceptos relacionados con MYELOID-LEUKEMIA también son conceptos de la ontología. Esto, lógicamente, hace que fuera necesario insertarlos previamente en su lugar correspondiente de la jerarquía y, si se considera apropiado, definirlos y explicitar sus características propias.101 En muchas ocasiones, posicionar dichos conceptos en la ontología requería construir o completar una rama completa, sobre todo cuando se trata de un concepto muy específico, como por ejemplo LYMPHOCYTE o NEUTROPHIL. Como puede observarse en la captura de pantalla de la Figura 24, para llegar al nivel de dichos conceptos, partimos del concepto (original de la ontología de mK) INTERNAL-ANIMAL-PART y debimos completarlo con los conceptos hijos sucesivos PHYSIOLOGICAL-SYSTEM -> IMMUNE-SYSTEM -> LEUKOCYTE -> GRANULOCYTE -> NEUTROPHIL.
Para facilitar la visualización de los conceptos insertados en la jerarquía, el editor de ontologías nos permite ver la ontología completa en forma de árbol, o bien árboles parciales para EVENT, OBJECT, ATTRIBUTE y RELATION. La siguiente captura de pantalla muestra el árbol parcial de RELATION, donde se pueden ver las relaciones específicas a la oncología incluidas en la ontología (que parten de DISEASE-EVENT-RELATION y DISEASE-EVENT-OBJECT-RELATION), así como sus relaciones inversas:
Figura 23: Árbol parcial de RELATION.
Desde el punto de vista del terminógrafo que compila la información, estos árboles son de gran utilidad para ver de forma completa el desarrollo de la estructuración conceptual. En estos árboles puede, además, verse resumida la información que la ontología contiene sobre cada concepto o movernos a la pantalla de edición principal de un concepto:
Figura 24: Árbol Parcial de OBJECT (concepto SPLEEN).
El editor de ontologías permite además muchas otras funcionalidades que sería demasiado extenso mostrar aquí en detalle;102 permite, por ejemplo, modificar la información ya incluida en la ontología, asignar más de un concepto superordinado (herencia múltiple), ver todos los conceptos superordinados o subordinados de un concepto determinado y los valores que un concepto hereda de sus subordinados, de qué concepto hereda cada valor y la distancia que separa ambos conceptos (superordinado y subordinado).
El editor de ontologías ofrece, además, dos herramientas para la navegación y publicación de nuestra ontología. El primero es el llamado Ontology Navigator, que mostramos en la Figura 25. Se trata de una herramienta que combina los árboles ya mostrados en el panel izquierdo con un navegador web integrado en el panel derecho, en donde se nos mostrará de una forma mucho más legible que en el editor toda la información referente a cada uno de los conceptos que conforman nuestra ontología. Sirviéndose de esta herramienta, OntoTerm genera un documento HTML para cada uno de los conceptos introducidos. Lo único que debemos hacer para visualizar dichos documentos es hacer clic en cualquiera de los nodos del árbol del panel izquierdo. Los documentos se almacenan en un directorio específico que OntoTerm crea durante su instalación. Al hacer clic la aplicación busca en este directorio la existencia de la página web en cuestión y, si no la encuentra, la crea y la visualiza. Si queremos que se refleje información actualizada tras una primera visualización deberemos pulsar el botón "Refresh" en la barra de herramientas. La siguiente figura muestra parte de un documento HTML generado por el Ontology Navigator:
Figura 25: El "Ontology Navigator"
Como se puede apreciar en esta captura de pantalla, OntoTerm incluye un encabezado en el que se nos informa de la fecha y hora en la que esa página fue creada. Desde esta herramienta también se nos ofrece la posibilidad de publicar la ontología en conjunto. Si seleccionamos esta opción, OntoTerm generará una página web para cada uno de los conceptos incluidos en la ontología, convirtiendo las referencias a conceptos en hipervínculos y generando una página índice, con marcos en HTML. Esto nos permite publicar todo el contenido de nuestra ontología, bien localmente, bien en la red. En el Apéndice I incluimos ejemplos de documentos HTML correspondientes a conceptos del subdominio de oncología incluidos en la ontología.
La segunda herramienta de visualización e informe nos permite elegir para qué conceptos de nuestra ontología deseamos generar páginas, la información a incluir en cada una de ellas y la localización de los archivos resultantes.
Figura 26: El generador de informes de OntoTerm
Como muestra la Figura 26, esta herramienta nos permite, además seleccionar qué secciones queremos incluir en nuestros informes, pudiendo omitir aquellas en las que no estemos interesados.
Como ya hemos mencionado, éste es el primero de los dos módulos principales de los que consta OntoTerm; el segundo, el dedicado a la gestión de información terminológica propiamente dicha (lingüística y administrativa) es el llamado Termbase Editor, que describimos en el apartado 5.6. Antes, sin embargo, es importante que conozcamos las categorías de datos con las que trabaja este módulo de la aplicación.
Notas
97 Tomado de la ayuda de TRADOS MultiTerm '95 Plus!, © 1992-96, TRADOS GmbH.
98 Todo lo referente a este proyecto y sus posteriores evoluciones se puede encontrar en http://aix1.uottawa.ca/~imeyer/research.htm
99 La estructuración conceptual de los términos oncológicos y su inserción en la ontología ha sido fruto de un intenso trabajo de colaboración con otro miembro del grupo OncoTerm, M. García de Quesada, junto con los especialistas del Hospital Virgen de las Nieves de Granada integrados en el proyecto, a quienes queremos agradecer su entusiasta colaboración y su disposición a atender nuestras preguntas.
100 Tomamos la decisión de tomar el ICD-9 CM como base para la tipología de neoplasias incluidas en la ontología por otros tres motivos fundamentales (i) es una clasificación de uso muy extendido en la comunidad científica; (ii) es compatible y/o está integrada en otros recursos que teníamos a nuestra disposición (por ejemplo el ULMS Metathesaurus (sección 4.3.3.3); (iii) define explícitamente el criterio de clasificación (topográfico) y lo completa con otra clasificación complementaria basada en la histopatología (morfología) de la neoplasia, el ICD-O, por lo que es posible combinar ambas clasificaciones.
101 Mostramos la posición de algunos de dichos conceptos en las capturas de pantalla que muestran los árboles de la ontología (Figuras 23 y 24).
102 Véase Moreno Ortiz (2000a/b) y Moreno Ortiz & Pérez Hernández (2000).
| ISSN: 1139-8736 Depósito Legal: B-39120-2002 Copyright: © Chantal Pérez |