Arquitectura del agente de gestión de tesauros

Una vez hemos elegido SKOS-Core como formato para la codificación de tesauros, podemos pasar a describir el diseño e implementación del núcleo del servidor de tesauros. Este núcleo del sistema se compone de dos clases destinadas a gestionar las funcionalidades básicas de acceso al tesauro, Thesaurus y Concept, y otras dos destinadas a proporcionar funcionalidades básicas de normalización conceptual, NormalizarTermino y Searcher.

La clase Thesaurus abstrae la idea del tesauro, con el objetivo de modelizarlo y permitir de esta forma su manejo mediante instancias por todas aquellas clases que necesiten realizar acciones sobre él. La clase Thesaurus contiene un objeto de tipo TreeMap como atributo de clase destinado al almacenamiento del tesauro, donde el par clave/valor viene definido por los descriptores y no descriptores que sirven como punto de entrada al tesauro y por objetos Concept que modelizan la idea de concepto respectivamente. Cada clave descriptor o no descriptor contiene como valor el objeto Concept al que pertenece.

Como hemos mencionado la clase Thesaurus utiliza objetos de tipo Concept para la abstracción del concepto de descriptor. Este objeto Concept incluye atributos relacionados con los componentes que forman parte de un descriptor en los tesauros tradicionales. De esta forma encontraremos entre sus atributos o variables de clase un String relativo al término preferente que representa al descriptor y, por lo tanto, a su concepto, y dos Strings relativos a la traducción del término preferente al inglés y al francés. A su vez encontraremos también una serie de listas, implementadas mediante ArrayList, referentes a términos generales de primer, segundo y tercer nivel, términos específicos de primer, segundo y tercer nivel, categorías a las que pertenece el concepto, términos relacionados y términos equivalentes o no descriptores. Finalmente contamos también con un String correspondiente a notas aclaratorias sobre el significado y utilización de los conceptos en el momento de la indización.

A través de esta estructura definimos un concepto de forma muy similar a como se ha hecho en muchos de los recursos lingüísticos informatizados utilizados en los últimos diez años en el campo de la recuperación de información y el procesamiento del lenguaje natural, es decir basado en sus relaciones semánticas con otros conceptos, si bien nos ajustamos a la concepción pura de tesauro documental definida mediante el estándar ISO-2788.

En la siguiente figura se muestran las clases que forman parte de este núcleo:

Como se puede ver ambas clases implementan el interfaz Serializable, esto es debido a que el almacenamiento del tesauro y de sus descriptores se realiza en un mismo fichero donde se almacenan sendos objetos serializados para que permanezcan de forma persistente más allá de la utilización del programa que los ha creado. Al inicio de la ejecución de la aplicación que utiliza estas clases, se cargan en memoria primaria para ser usados desde aquí durante la ejecución. Esto también permite la carga de varios tesauros por un mismo agente mediante mecanismos de serialización, lo que facilita el mapeo de conceptos entre varios tesauros. Esta forma de almacenamiento difiere de la utilizada normalmente sobre base de datos, y tiene como objetivo mantener la consistencia de los objetos más allá de la ejecución del programa con el objetivo de no tener que generar desde una base de datos los objetos Thesaurus y Concept cada vez que se usa el programa¹⁶. Esta implementación no perjudica en exceso la eficiencia del programa y nos permite mantener el enfoque orientado a objetos en todo momento de cara a contar con una mayor simplicidad en la implementación del sistema.

A partir de este núcleo hemos diseñado a modo de ejemplo un conjunto de clases encargadas de permitir operaciones avanzadas sobre el tesauro a partir de los métodos básicos que contiene la clase Thesaurus. Así pues contamos con la clase NormalizarTermino y la clase Searcher. La clase NormalizarTermino nos permite normalizar conceptos de forma automática contra el tesauro. La funcionalidad es muy sencilla ya que a partir de un entrada compuesta por una palabra o cadena de palabras¹⁷, esta clase es capaz de devolvernos los términos que normalizan los conceptos representados por el término o términos introducidos. Este proceso de normalización se realiza sobre la totalidad del tesauro, utilizando los términos preferentes y no preferentes como puntos de entrada al mismo. De esta forma garantizamos la coherencia del proceso de normalización en virtud del tesauro que estamos utilizando. Un ejemplo de utilización de esta clase sería el siguiente:

jose@leviathan: /eclipse/workspace/ThesaurusManager$ java NormalizarTermino spines cancer
La consulta es "cancer"
El descriptor correspondiente es "neoplasmas malignos"
El número de términos es de 10772

Aunque en el ejemplo realizamos una normalización simple por un término, la aplicación es capaz de procesar cadenas enteras de términos y devolver los descriptores correspondientes por separado. Así mismo permite la recuperación de los términos relacionados semánticamente con cada descriptor. Se puede incluso pasar un texto completo para realizar la normalización sobre los conceptos que aparecen en él.

Por su parte la clase Searcher funciona de la misma forma que la clase anterior, si bien la diferencia principal reside en que Searcher devuelve el resultado de la consulta en formato RDF/SKOS-Core, con el mismo formato que hemos definido anteriormente. La respuesta de esta clase a la consulta anterior tiene el aspecto siguiente:

jose@leviathan: /eclipse/workspace/ThesaurusAgent$ java thes.Searcher cancer
$<$rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:skos="http://www.w3.org/2004/02/skos/core#"$>$
$<$skos:Concept rdf:about="http://spines/neoplasmas%20malignos"$>$
$<$skos:broader rdf:resource="http://spines/enfermedades"/$>$
$<$skos:related rdf:resource="http://spines/transformacion%20neoplasica%20celular"/$>$
$<$skos:prefLabel$>$neoplasmas malignos$<$/skos:prefLabel$>$
$<$skos:prefLabel xml:lang="en"$>$malignant neoplasms$<$/skos:prefLabel$>$
$<$skos:prefLabel xml:lang="fr"$>$neoplasmes malins$<$/skos:prefLabel$>$
$<$skos:related rdf:resource="http://spines/neoplasmas%20benignos"/$>$
$<$skos:related rdf:resource="http://spines/habito%20de%20fumar"/$>$
$<$skos:related rdf:resource="http://spines/enfermedades%20incurables"/$>$
$<$skos:altLabel$>$cancer$<$/skos:altLabel$>$
$<$skos:altLabel$>$carcinoma$<$/skos:altLabel$>$
$<$skos:related rdf:resource="http://spines/i+d%20medica"/$>$
$<$skos:related rdf:resource="http://spines/neoplasmas%20experimentales"/$>$
$<$skos:related rdf:resource="http://spines/pechos"/$>$
$<$skos:narrower rdf:resource="http://spines/neoplasmas%20inducidos%20por%20radiacion"/$>$
$<$skos:related rdf:resource="http://spines/antineoplasicos"/$>$
$<$skos:related rdf:resource="http://spines/enfermedades%20de%20la%20mama"/$>$
$<$skos:related rdf:resource="http://spines/enfermedades%20gastrointestinales"/$>$
$<$skos:broader rdf:resource="http://spines/neoplasmas"/$>$
$<$skos:related rdf:resource="http://spines/condiciones%20precancerosas"/$>$
$<$skos:related rdf:resource="http://spines/enfermedades%20ginecologicas"/$>$
$<$skos:related rdf:resource="http://spines/cancerigenos%20ambientales"/$>$
$<$skos:related rdf:resource="http://spines/enfermedades%20del%20aparato%20genital%20masc."/$>$
$<$skos:related rdf:resource="http://spines/amianto"/$>$
$<$skos:narrower rdf:resource="http://spines/leucemias"/$>$
$<$skos:narrower rdf:resource="http://spines/sarcoma"/$>$
$<$/skos:Concept$>$
$<$/rdf:RDF$>$

Como se puede ver en este caso la consulta devuelve un documento RDF con el marcado definido en el schema de SKOS-Core con toda la información referente al concepto solicitado¹⁸.

El objetivo de ambas clases es mostrar algunos ejemplos de las funcionalidades que ofrece la estructura de clases Thesaurus y Concept anteriormente descrita, tanto para su consulta por usuarios humanos, como es el caso de normalizar término, como para su uso por otras aplicaciones, como es el caso de Searcher.

A partir de esta descripciones de clases podemos definir un núcleo básico del servidor de tesauros que implementa tanto al tesauro como las operaciones que se realizan sobre él y sobre los conceptos. De esta forma el diseño de la aplicación se correspondería con la figura siguiente: