Extracción de los términos del MeSH

7.2.1 Localización de la terminología

El primer paso para la elaboración del estudio es extraer la terminología necesaria para generar la base de datos de BoilerPlates. Para ello, se empleará la información ofrecida por MeSH (explicado más atrás) para realizar las siguientes tareas:

 Identificar la posición de los descriptores relacionados con nuestro dominio.

 _{Extraer el nombre de los descriptores seleccionados, así como sus} términos y sinónimos potenciales.

Ya que el dominio específico de la medicina que trata este proyecto es sobre la sordera genética, se hizo una consulta directa a la página web de MeSH sobre los términos “sordera” (“deafness” o “hearing loss”) y “genética” (“genetics”). Al final, se concluyó que los subárboles que contienen los descriptores necesarios tienen como nodo raíz “C09.218.458.341” para la sordera y “G05” para la genética.

54 Figura 38: Árboles jerárquicos de los descriptores a extraer [44, 45]

Una vez obtenidas localizaciones de los descriptores, el siguiente paso sería extraer los conceptos y sus términos para su posterior inserción en la base de datos.

Sin embargo, aquí surge un problema: si bien el número de descriptores en total para la sordera genética es lo suficientemente bajo para realizar la extracción de forma manual (17 descriptores) mediante el uso de un procesador de texto, el árbol correspondiente a la genética es considerablemente grande (294 descriptores).

Debido a la gran cantidad de conceptos a procesar, se consideró el uso de alguna herramienta obtenida de Internet o el uso de una funcionalidad implementada en la página web que permitiese realizar la extracción de forma manual. Sin embargo, no se encontró ningún programa pensado para MeSH y la página web de MeSH no ofrece dicha posibilidad.

7.2.2 Extracción de la terminología

Ante esta situación, se decidió que sería necesario codificar un programa que permitiese la exportación de los descriptores. Se optó por el lenguaje de programación Java ya que se disponía de mayor experiencia

programando con dicho lenguaje.

El primer paso fue descargar la base de datos MeSH en formato XML a partir de la página web. El fichero, desc2016.xml, tiene un tamaño de

aproximadamente 280MB descomprimido y su extensión es de más de nueve millones de líneas de texto en lenguaje de marcas.

55 Figura 39: Enlace de descarga del fichero desc2016.xml [46]

Al estudiar el texto contenido en el fichero, se identificaron los “tags” que contienen la información necesaria para nuestro proyecto, que son los siguientes:

 _{<DescriptorRecord>(…)</DescriptorRecord>: define el inicio y fin de} un descriptor.

 _{<ConceptName>(…)<ConceptName>: nombre del concepto. Es} posible que haya más de un nombre de concepto. El primero se establecerá como el nombre del descriptor y el resto se considerarán sinónimos.

 _{<TreeNumber>(…)</TreeNumber>: identificador del descriptor. Es} posible que haya varios identificadores. El primero de ellos es el que define su posición en el árbol jerárquico correspondiente.

 _{Abbreviation>(…) </Abbreviation>: calificador(es) del descriptor.}  _{<ScopeNote>(…)</ScopeNote>: información del descriptor.}  _{<Annotation>(…)</Annotation>: anotaciones del descriptor.}  _{<TermUI>(…)</TermUI>: términos asociados al descriptor.}

56 Durante el estudio del fichero desc2016.xml se descubrió la existencia de un problema adicional: los descriptores no están ordenados por orden jerárquico, por lo que no será posible reducir el cómputo del programa estudiando sólo secciones determinadas del fichero. En su lugar, será necesario estudiar todos los conceptos contenidos en él para asegurarse de que no falta ningún descriptor sin extraer tras el procedimiento.

7.2.3 Implementación del programa de extracción de descriptores

Para todas las implementaciones realizadas en el curso de este proyecto se ha creado un proyecto en Eclipse conocido como “MeSHParser”. Cada algoritmo implementado se ha introducido en un paquete independiente para acceder a su contenido con facilidad.

El primer programa implementado, “customParser”, permite estudiar el fichero desc2016 (insertado en el proyecto Eclipse) para exportar la información de todos los descriptores cuyo identificador sea o comience por una constante string (subCategory) establecido previamente, con un coste computacional relativamente bajo (aproximadamente 10 segundos).

Por ejemplo, si se establece el valor de subCategory a “C09.218.458.341”, el algoritmo extraerá el descriptor asociado a dicho identificador y al resto de nodos contenidos en el subárbol. Los resultados serán exportados a un fichero diferente en formato txt.

El algoritmo sigue los siguientes pasos:

Apertura de ficheros: se abren los ficheros desc2016.xml y un fichero

de salida (output). Además, se crea un buffer de lectura para desc2016 y un buffer de escritura para el fichero output.

Declaración de estructuras de datos: para almacenar temporalmente

la información de los descriptores, se emplearán variables de tipo ArrayList<string> y string. Dichas variables son las siguientes:

 conceptName: variable donde se almacena el nombre del descriptor.  description: variable donde se almacena la descripción.

 notes: variable donde se almacena las notas asociadas al descriptor.  nodes: variable donde se almacenan los identificadores del descriptor.

57  qualifiers: variable donde se almacenan los calificadores del descriptor.  terms: variable donde se almacenan los términos del descriptor.

 synonyms: variable donde se almacenan los posibles sinónimos del descriptor.

Procedimiento: se empieza a leer desc2016 y se realizará una acción

según la línea procesada. Mientras no se llegue al final del fichero:

 Si se lee <TreeNumber>, se introduce el nodo contenido en el “tag” en la variable nodes. Se comprueba si el descriptor está contenido en el árbol jerárquico que se desea extraer: si es el primer nodo leído de este descriptor corresponde al árbol jerárquico establecido con la constante subCategory, se registra este hecho con una variable booleana.

 Si se lee <Abbreviation>, se introduce el calificador contenido en el “tag” en la variable qualifiers.

 _{Si se lee <ScopeNote>, se introduce la descripción contenida en el “tag”} en la variable qualifiers.

 _{Si se lee <Annotation>, se introduce las notas contenidas en el “tag” en} la variable notes.

 Si se lee <ConceptName>, se introduce el nombre del descriptor en el “tag” en la variable conceptName. Si no es el primer nombre encontrado en el descriptor, es decir, se ha leído otro “tag” <ConceptName> en el mismo descriptor, se añade en la variable synonyms.

 Si se lee <TermUI>, se introduce el término contenido en el “tag” en la variable terms.

 Al leer </DescriptorRecord> se habrá llegado al final de la entrada para el descriptor. Entonces se realizará lo siguiente:

o Si el descriptor está contenido en el árbol jerárquico correcto, entonces se vuelca la información contenida en las variables del sistema en el fichero de salida, siguiendo el formato como aparece en la Figura 40: Formato de los descriptores tras su extracción. Después, se reinician las variables de datos.

o Si el descriptor no está contenido en el árbol jerárquico, se reinician las variables de datos sin volcar previamente los datos en el fichero de salida.

58 Figura 40: Formato de los descriptores tras su extracción

Al terminar el algoritmo, el fichero output contendrá todos los descriptores solicitados. Ya que los conceptos “sordera” y “genética” están en distintos árboles jerárquicos, se ha realizado el procedimiento dos veces, obteniendo dos ficheros de salida con los descriptores de cada uno.