4.6.1 El módulo ontológico (Ontology Editor)

Se trata del principal componente de la aplicación, ya que para crear una nueva base terminológica es necesario construir una ontología porque se parte del principio de que ningún término puede existir antes de haber sido relacionado con un concepto (Moreno et al. 2000: 3). Como ya hemos mencionado, la ontología de ONTOTERM^® se construye a partir de la ontología de MK y hay que tener en cuenta que no es necesario contar con una ontología completamente desarrollada para poder comenzar el trabajo terminológico, ya que el usuario puede optar por desarrollar ambas tareas de manera simultánea, al relacionar términos del módulo terminológico con conceptos definidos en el módulo ontológico a medida que se van introduciendo. Siempre que se añada, elimine o modifique un concepto en el módulo ontológico todas las bases terminológicas asignadas a éste serán actualizadas (Moreno et al. 2000: 3). Por tanto, la estructuración del conocimiento se ha ido realizando de manera paralela a la adquisición del mismo teniendo en cuenta las normas y clasificaciones internacionales pertinentes, no sólo las que regulan el campo de especialidad (ICD-9, MeSH, etc.) sino también las que normalizan el intercambio de información terminológica (§4.5).

El objetivo es que esta red conceptual se convierta en el eje central en la búsqueda, elección, estructuración y continua evaluación de los términos. Como ya vimos, una vez generadas las categorías conceptuales del subdominio oncológico (§2.3.3.1), es decir, los conceptos más representativos, los términos se clasifican de acuerdo con éstas. El ontólogo lleva a cabo una disección del conocimiento (Galeazzi 1998: 35) para satisfacer las demandas del usuario (Lindberg 1993: 45). Los conceptos resultantes no son más que una formalización posible de una parte del conocimiento y serán punto de referencia para la unidad terminológica.

Hay que tener en cuenta que, aunque a nivel conceptual tratemos con abstracciones, éstas han de formalizarse por medio de unidades léxicas, expresiones pertenecientes al lexicón primario, imágenes (Galinski y Picht 1997: 45-47) o incluso responder a un amplio tono de grises que cubra el espacio existente entre estos tres extremos. En ONTOTERM^®, el nombre del concepto recogido en *.ont siempre formará parte del vocabulario de la ontología, de la terminología ontológica, aunque no tiene por qué ser un término recogido en *.otb. Además se ha optado por utilizar la lengua inglesa para "bautizar" al concepto (García de Quesada 2001:238):

DISEASE-EVENT EVENT

MEDICAL-ROLE OBJECT

INVERSE-DISEASE-EVENT-OBJECT-RELATION PROPERTY: RELATION

AFFECTED-POPULATION-SEX PROPERTY: ATTRIBUTE: LITERAL RECOVERY-RATE PROPERTY: ATTRIBUTE: SCALAR

Tabla 4.1: Ejemplos de conceptos y sus correspondientes categorías ontológicas

Por lo que, una vez más, la importancia no estriba tanto en la correspondencia concepto-mundo real como en la cohesión interna del evento médico (§2.3.3), alrededor del cual gira el diseño de la estructura ontológica del subdominio oncológico, y su correspondencia con los textos y el conocimiento experto. De esta forma se facilita una infraestructura de apoyo para el análisis, la inclusión y evaluación de términos en ambas lenguas (inglés-español).

El proceso seguido para la adquisición y posterior estructuración del conocimiento experto (§2.3) es por tanto muy difícil de seccionar en módulos individuales y secuenciales, ya que estas dos tareas responden a un proceso cognitivo complejo, no lineal, y con un feedback continuo en donde se alterna una postura analítica sobre los detalles específicos de cada categoría conceptual y de cada término, con una sintética sobre las regularidades y estructuras existentes. Por tanto, no podemos separar el diseño ontológico del terminográfico; son la cara de la misma moneda, son dos partes de un todo que sólo está completo cuando puede verse como tal.

En ONTOTERM^® es posible marcar los conceptos como pertenecientes a un proyecto o subconjunto específico y visualizar sólo éstos. En la barra de estado situada en la parte inferior del módulo ontológico existen tres paneles que muestran, de izquierda a derecha, el subconjunto al que pertenece el concepto seleccionado, el tipo de concepto del que se trata, el número de conceptos asignados al grupo seleccionado y el número total de conceptos en la ontología:

Figura 4.8: Información sobre el subconjunto conceptual de ONCOTERM

Como se puede observar, un concepto determinado se describe gracias a una definición, las propiedades que este concepto hereda de otro superordinado y sus conceptos hijos en la jerarquía. Se incluye, por tanto, una especificación de sus propiedades (relaciones y atributos) en la pestaña "Properties" (Fig. 4.9 ). Las otras dos pestañas se utilizan para mostrar los ancestros y descendientes ("Relatives") (Fig. 4.10) y las propiedades heredadas ("Inheritance") (Fig. 4.11). Éstas se muestran junto con el concepto del que se heredan y la distancia entre el concepto seleccionado y el concepto a partir del cual se hereda dicha propiedad. La herencia generalmente se desactiva para conseguir una mayor velocidad de navegación pero los botones que aparecen en la parte inferior también permiten al usuario ver las propiedades heredadas tanto acumulativas como exclusivas. Además, como se puede observar en la Fig. 4.11, las propiedades se heredan no sólo a partir de conceptos pertenecientes al proyecto ONCOTERM sino también a partir de conceptos situados más arriba en la jerarquía y que pertenecen a la ontología de MK (Moreno et al. 2000: 3):

Figura 4.9: Información sobre las "properties" de HAVE-NEOPLASM

Figura 4.10: Información sobre los "relatives" de HAVE-NEOPLASM

Figura 4.11: Información sobre "inheritance" en HAVE-NEOPLASM

En cuanto a las herramientas de navegación, encontramos la aplicación "trees" que, además del árbol global de la ontología, permite a los usuarios tener tantos árboles parciales abiertos como deseen lo que les facilita la concentración en la sección de la ontología que sea relevante para el trabajo que desarrollan en ese momento (Moreno et al. 2000: 4):

Figura 4.12: Árbol parcial de HAVE-NEOPLASM

Otra herramienta de navegación disponible es el "Ontology Navigator" (Fig. 4.13), una ventana de doble panel que contiene la jerarquía completa del concepto en la parte izquierda. Al pinchar en cualquiera de los nodos del árbol, ONTOTERM^® generará un archivo HTML con toda la información (tanto local como heredada) y la mostrará en el navegador integrado (parte derecha de la ventana) donde todos los conceptos y relaciones son hipervínculos a los archivos HTML que los describen. Esta herramienta se puede utilizar también para publicar la ontología en formato HTML (Moreno et al. 2000: 4):

Figura 4.13: Archivo HTML de HAVE-NEOPLASM generado por el Ontology Navigator

Así, a la hora de incrementar y adaptar la información conceptual de la ontología de MK a las necesidades de ONTOTERM^®, partiendo de la idea de no modificar o eliminar conceptos existentes a menos que fuera estrictamente necesario, se utilizaron las herramientas de navegación y de edición. Las operaciones básicas de edición conceptual ('añadir', 'definir', 'eliminar', 'mover') se llevan a cabo a través de la interfaz gráfica y el sistema se encarga de que la consistencia interna no se vea modificada por ninguna de estas operaciones.

Para estructurar e introducir los conceptos en la BD en primer lugar se ha de ubicar conceptualmente el término extraído o adquirido. Se trata de determinar a qué concepto se refiere el término o viceversa teniendo en cuenta que puede tratarse de una unidad léxica que no sea un concepto relevante, una conclusión a la que no siempre se llega desde el principio. Si creemos que se trata de un concepto necesario, y no ha sido recogido con anterioridad en ONTOTERM^®, habrá que crearlo. Si el concepto responde a una especificación de otro ya existente, se ubicará como hijo de éste; es decir, un concepto siempre habrá que clasificarlo (decir qué tipo de concepto es) y ubicarlo en la ontología por medio de inferencias a partir del texto y de nuestro conocimiento del dominio oncológico. Una vez situado en el editor ontológico se le añaden unas características mínimas y su concepto inmediatamente superior. En el caso de tratarse de una RELATION además habrá que añadir su relación inversa, y si se trata de un ATTRIBUTE habrá que añadir un número, color, etc. dependiendo de si es escalar o literal (§2.3.3.1). Lo ideal es que cada concepto cuente con un abanico de vínculos con otros conceptos que fluctúe entre 10 y 15 (Mahesh 1996: 42).

A continuación, a modo de ejemplo, mostramos algunos casos de reestructuración de conceptos contenidos en la ontología inicial de MK correspondientes a las categorías OBJECT, EVENT, PROPERTY (RELATION, ATTRIBUTE) (García de Quesada 2001: 239-248). Como se puede observar en la Fig. 4.13, dentro de la rama de DISEASE-EVENT, se mantuvieron todos los conceptos iniciales tales como COUGH, HAVE-VIRUS y HAVE-FEVER y se añadieron otros como ANAPLASIA, FLU, ANEMIA, ANOREXIA, CONSTIPATION, INFECTION, NAUSEA y DIARRHEA que eran esenciales para la representación de relaciones propias de los conceptos sobre tipos de cáncer. El concepto original HAVE-CANCER se modificó por HAVE-NEOPLASM, de naturaleza más genérica que permite englobar casos de neoplasias malignas (cáncer) y benignas. Además, en esta sección de la jerarquía se introdujo una clasificación jerárquica muy amplia de tipos y subtipos de neoplasias procedente de la ICD-9 (§4.2.1):

Figura 4.14: La ICD-9 y el concepto HAVE-NEOPLASM

En el caso del objeto DRUG, la organización inicial era la siguiente:

(98)
PHARMACEUTICAL-MATERIAL: A raw material that is used in the preparation of drugs.

DRUG: A material used as a medicine to cure or get relief from ailments.
MEDICAL-PREPARATION: A pharmaceutical material used for prevention of a disease, as opposed to curing or getting relief from one.

BLOOD-TRANSFUSION: the transfer of whole blood or blood products from one individual to another.
LINIMENT a soothing medicated liquid to be rubbed on the skin

VACCINE any preparation used for inoculation to produce immunity against a particular disease

SERUM: Blood serum as an antitoxin, taken from an animal inoculated for a specific disease.

Frente a esta estructuración, como ya se intuía en las definiciones presentadas, se propuso cambiar los nombres y crear MEDICAL-MATERIAL en lugar de PHARMACEUTICAL-MATERIAL como superordinado de los conceptos DRUG y PHARMACEUTICAL-PREPARATION, concepto que también hubo que cambiar de nombre. A continuación, como conceptos-hijo de PHARMACEUTICAL-PREPARATION, se conservó LINIMENT y se añadió COSMETICS, rellenando un espacio conceptual que quedaba vacío. Así, el conocimiento relacionado con los fármacos utilizados en el tratamiento del cáncer se ha incluido bajo el concepto MEDICAL-MATERIAL de MK:

Figura 4.15: El concepto DRUG

En cuanto a las PROPERTIES, la ontología de MK permite representar tanto las RELATIONs (y sus INVERSE-RELATIONs) (Fig. 4.16) como los ATTRIBUTEs (divididos en LITERAL-ATTRIBUTEs y SCALAR-ATTRIBUTEs) (Fig. 4.17) como conceptos en sí mismos. Este rico sistema de relaciones existente en MK se ha complementado con otras necesarias para la caracterización conceptual en el ámbito del cáncer:

Figura 4.16: La relación HAS-SYMPTOM y su inversa SYMPTOM-OF

Figura 4.17: El atributo escalar RECOVERY-RATE

Entre las relaciones y atributos específicos añadidos a la ontología hasta el momento se incluyen los siguientes:

Tabla 4.2: Ejemplos de RELATIONs añadidas a la ontología de MK

Tabla 4.3: Ejemplos de ATTRIBUTEs añadidos a la ontología de MK

Como ya vimos, estas relaciones y atributos son parte esencial de los esquemas categoriales formalizados en la definición terminográfica (§2.3.3.2) propuesta por García de Quesada (2001).

Índice general I Índice Capítulo 4  I Siguiente