<$BlogRSDUrl$>

Pro·Log·[IR]

Programación Lógica y Recuperación de Información

«Algorithm = Logic + Control» Robert Kowalski (1979)

¡Importante! esta página hace uso de estilos recogidos en la especificación CSS2, no soportados por el navegador que está utilizando. Por favor, lea esta recomendación al respecto.

Archivo

Guardado por meses.

Enlaces

Los siguientes listados son una referencia a partir de la cual ampliar la búsqueda de sitios relacionados (i).

Bitácoras en castellano

Bitácoras en inglés

Directorios, metablogs

Programación lógica, Inteligencia Artificial, Recuperación de Información

Usabilidad, Arquitectura de la Información

Listas, foros, wikis

Matemáticas, ciencias

Miscelánea

Búsquedas

Búsqueda simple en varios de los motores más conocidos. Para mayor precisión, entrar en la página correspondiente e ir al apartado de búsqueda avanzada.

Búsqueda con Google
 

Búsqueda con Yahoo!
 

Búsqueda con AlltheWeb

Varios

Esta página traducida:

Traducción al catalán, internostrum; traducción al portugués, universia.

Reciba un aviso de nuevos comentarios (por Bloglet).


Agregue este sitio a su lector de "feeds" (sindicación mediante el sistema Atom).

Sobre este sitio

Espacio dedicado a la programación lógica y la recuperación de información, con una atención especial al lenguaje Prolog y otros lenguajes afines, pertenecientes al paradigma lógico y declarativo. También se tratará de hablar de estos temas desde la perspectiva de la Biblioteconomía y la Documentación.

En esta página

27.2.06

Analizadores sintácticos y tokenización

Dentro del complejo y amplio ámbito de dominio del Procesamiento del Lenguaje Natural (PLN), una de las funciones esenciales de los analizadores sintácticos o parsers es el análisis de cadenas de tokens en busca de posibles errores sintácticos (recordemos que la sintaxis, entendida en sentido amplio, es aquella parte de la gramática que se ocupa de las normas que rigen la formalización de las palabras en estructuras mayores tales como las oraciones, así como de las relaciones que establecen entre si dichas palabras). Un token se puede definir como la unidad mínima de información con significado propio dentro de una secuencia de caracteres alfanuméricos. Estas cadenas de unidades mínimas de información o unidades léxicas, son generadas previamente por el módulo lexicográfico integrado en el parser, encargado de identificarlas dentro de un texto o secuencia ordenada de caracteres alfanuméricos. Por su parte, la tokenización es un proceso consistente en la descomposición, en forma de lista, de esas cadenas de tokens en sus unidades mínimas. Así, un programa de este tipo podría generar la siguiente lista de tokens a partir de la frase "¡Hola Mundo!":

[161, 72, 111, 108, 97, 32, 77, 117, 110, 100, 111, 33]

Donde cada uno de los números de la lista se corresponde con el carácter ASCII (American Standard Code for Information Interchange) correspondiente a cada una de las unidades mínimas de significación identificadas en la frase, en el mismo orden. Por supuesto es posible llevar a cabo el proceso inverso, y a partir de esa lista generar las cadenas de tokens que forman la frase en cuestión. La tokenización es por tanto el proceso básico que permite manejar el lenguaje natural escrito para su posterior procesamiento, en base a su descomposición en unidades mínimas de información con significado propio.

La mayor parte de los lenguaje de programación contemplan instrucciones específicas para llevar a cabo el proceso de tokenización de cadenas ordenadas de caracteres alfanuméricos, si bien es posible implementar alternativamente esta operación mediante otros procedimientos proporcionados por esos lenguajes.

Así, un programa que pretenda "leer" un texto, deberá en primer lugar "tokenizarlo", generando una lista de los tokens, o unidades léxicas mínimas con significado propio, identificados en ese texto. A continuación, procederá a identificar unidades mayores de significado propio (contemplando por ejemplo la presencia, como elemento separador, del carácter ASCII 36, que se corresponde con el espacio en blanco), lo que podríamos asimilar como "palabras", para, finalmente, acabar identificando otras unidades de significación de orden superior, frases u oraciones. Diferenciadas las oraciones del texto "leído", el parser procede a realizar el análisis sintáctico propiamente dicho, identificando para ello las partes constitutivas de dichas oraciones que, a tal fin, son comparadas con patrones previamente definidos de estructuras posibles, que dependerán de la lengua de escritura del texto, y del nivel de complejidad de análisis que se pretenda alcanzar, ya que contemplar todas las posibles estructuras de una lengua y sus numerosas variaciones, y representarlas mediante una serie de reglas, no es una tarea precisamente sencilla.

La detección de las variaciones de posición admitidas en cada lengua, en relación con el orden de las palabras, o análisis de las transformaciones, se realiza mediante procesos de análisis estructural que tratan de identificar la estructura profunda de una oración en relación con su estructura superficial. El análisis estructural, en base a la estructura superficial (2) de una oración y, cambiando el orden de determinadas palabras, trata de determinar su posible transformación a una estructura de tipo profundo (1):

(1) Estructura profunda: "Pedro come una manzana"
(2) Estructura superficial: "Come Pedro una manzana"

La implementación del proceso de tokenización, al margen de la utilización de instrucciones específicas que transforman directamente una cadena de caracteres alfanuméricos en una cadena de tokens, implica la utilización de otro tipo de instrucciones cuya función es la "lectura" individual, uno a uno, de los caracteres presentes en el canal o grupo activo de entrada de datos (input stream) que se halla especificado, que por lo general será bien el teclado del ordenador, que es el canal activo de entrada por defecto (al igual que el canal de salida de datos, output stream, por defecto es el monitor del ordenador), o bien un fichero de texto ubicado en la ruta que se indique.

Así, en el lenguaje Prolog existe el predicado predefinido name(?AtomOrInt, ?String). El argumento AtomOrInt es la variable que representa la cadena de caracteres alfanuméricos o "átomo" que se desea tokenizar, mientras que el argumento String es la variable que representa la lista resultante. El símbolo "?" indica que ambos argumentos son reversibles, es decir, que pueden funcionar tanto como variables de entrada de datos como variables de salida, si bien uno de ellos ha de estar necesariamente instanciado. Su modo de funcionamiento es el siguiente:

?- name('¡Hola Mundo!', X).

X = [161, 72, 111, 108, 97, 32, 77, 117, 110|...] [write]

X = [161, 72, 111, 108, 97, 32, 77, 117, 110, 100, 111, 33]

Yes

La indicación [write] simplemente expresa que, una vez que el intérprete proporciona la lista de tokens, incompleta como indica la barra vertical seguida de puntos suspensivos "|...", se ha tecleado el operador w para que ésta se muestre en toda su extensión, ya que, en este caso SWI-Prolog, muestra por defecto en pantalla una versión abreviada de las listas, cuando estas exceden determinada longitud (no obstante se pueden obtener listas completas utilizando el comando "w", tal y como se explica en esta página).

Por supuesto, existen más predicados para la manipulación de átomos, como se referencia en el apartado "Analysing and Constructing Atoms" del manual de SWI-Prolog.

Otra forma de tokenizar átomos en Prolog es utilizar el predicado get0/1 y get0/2 y algún tipo de algoritmo recursivo que vaya "recorriendo" todo el texto del canal activo de entrada de datos (un archivo externo, por ejemplo), y al tiempo introduzca los tokens resultantes, incluyendo los espacios en blanco (get/1 y get/2 no los leen), en una lista acumuladora, en tanto no se alcance determinado marcador de parada, definido previamente (para este fin suele aprovecharse el átomo end_of_file, que se corresponde con el final de texto). Este predicado realmente lee el byte correspondiente a cada carácter alfanumérico individual, asociándolo con su correspondiente código ASCII.

El analizador sintáctico, en base a los constituyentes de una oración (véanse los principios de la gramática generativa de Noam Chomsky), y mediante un número finito de reglas, trata de determinar la gramaticalidad o no de un número infinito de construcciones. Un analizador sintáctico trata de ver hasta que punto puede someterse un grupo de palabras a una estructura de reglas. Así por ejemplo, si tenemos la oración:

Pedro come una manzana

en primer lugar, y mediante un proceso de tokenización, se genera una lista de las palabras que contiene. De esta lista inicial de palabras, se puede diferenciar una sublista que se corresponda con el Sintagma Nominal (SN) de la oración, y si ésta puede concatenarse con otras sublistas que según determinadas reglas se verifica como Sintagma Verbal (SV), la oración se concluye que es gramatical. Lo que importa en los constituyentes es el orden de las palabras de la oración.

El analizador sintáctico realiza el análisis secuencialmente, palabra por palabra, partiendo de una lista inicial que, siguiendo con el ejemplo de la oración expuesta, sería:

[pedro,come,una,manzana]

El proceso de computación de las reglas del analizador sintáctico debe dar como resultado otra lista, que será una lista vacía [] si la oración inicial es gramatical (siempre en base a las reglas que tenga definidas el analizador). En definitiva, partiendo de la lista inicial de palabras, el analizador sintáctico comprueba si ésta se puede subdividir en dos sublistas, que se corresponden, respectivamente, con el SN y el SV de la oración.

Más información: El análisis sintáctico y el análisis semántico.

[1] comentarios | # | lista |

19.2.06

¿Ha llegado el fin de los tesauros documentales?

Aunque no suele ser mi costumbre publicar integramente textos completos en este sitio (para esos menesteres mantengo abierto Visto y Leído), me permito hacerlo en esta ocasión dado el indudable interés que tiene el que reproduzco a continuación, en función de las ideas que plantea, las experiencias prácticas puestas de manifiesto y compartidas por el autor, y el debate que todo ello pretende suscitar. Se trata de un mensaje enviado por José Ramón Pérez Agüera (Departamento de Sistemas Informáticos y Programación, Facultad de Informática, Universidad Complutense de Madrid) a la lista de distribución IWETEL, el pasado 13/02/2006 (para acceder al texto original, en el apartado de archivos, hace falta estar suscrito a dicho foro de discusión para profesionales del ámbito de las bibliotecas y los centros de documentación).

[Comienza el texto de Pérez Agüera]

"Aunque no me toca publicar nota en Thinkepi, llevo unos meses (de hecho algún año que otro) dándole vueltas a este asunto y me gustaría contar con la opinión de la comunidad de documentalistas, más allá de mis propias observaciones, con lo cual este correo no pretende ser una nota sino dar pie a un debate en el que los documentalistas no están teniendo voz, al desarrollarse dentro del campo de la informática.

Trabajo en generación automática de tesauros, lo cual me ha llevado a realizar experimentos de indización automática y expansión de consultas a partir de tesauros realizados a mano. Concretamente he utilizado tres tesauros: ISOC-Economía, EUROVOC y SPINES, todos ellos conocidos de sobra. La colección sobre la que he realizado las pruebas ha sido el sub-conjunto de noticias de economía y política generadas por la Agencia EFE en 1994 (efe94 es una colección típica en experimentos de recuperación de información que consta de un total de 215.738 documentos. Yo he utilizado 23.390 en mis experimentos para centrarme en el área de política y economía, las cuales son cubiertas en buena medida por los tesauros anteriormente mencionados).

A parte también he contado con un conjunto 22 de consultas con sus respectivos juicios de relevancia para el dominio mencionado de cara a la realización de los experimentos. Estas consultas las he obtenido del congreso CLEF [Cross-Language Evaluation Forum] que se celebra todo los años y que se centra en temas de recuperación de información mono y multilingüe.

Como motor de búsqueda he usado Lucene, adaptado al español con stemming sobre los términos de indización, el cual está basado en el modelo tradicional de espacio vectorial de Salton (un clásico, vamos).

El objetivo de mis primeros experimentos ha sido el de comprobar de que forma afectaba a la recuperación de información automatizada el uso de tesauros documentales como los que se usan todos los días en centros de documentación de todo el mundo. Y cual no ha sido mi sorpresa al comprobar que tanto juntos como por separado, usando todos o parte de los tipos de relaciones que existen en los tesauros, realizando expansión global directa o ponderada (la forma en que he ponderado los tesauros es otra historia), en cada uno de los casos los tesauros mencionados, no han mejorado prácticamente nada la recuperación en la colección, ni en precisión, ni en recall (ni en otro cerro de medidas que he ido aplicando basadas en el modelo propuesto por TREC [Text REtrieval Conference], otro congreso de RI que tiene un programita bastante completillo llamado trec_eval para evaluar la recuperación), es más en algunos de los experimentos, dependiendo de la longitud de la consulta el uso de tesauros documentales hechos a mano empeoraba los resultados.

El siguiente paso en mi investigación ha sido trabajar con tesauros generados automáticamente a partir de tres metodologías básicas:

Los tesauros generados automáticamente a partir de estas metodologías sí han proporcionado mejoras significativas en la recuperación. No me quiero poner aquí más pesado de la cuenta sobre los detalles técnicos y las cifras pero para el que las quiera se las puedo pasar.

El caso es que comenté el hecho con Antonio García Jiménez, que de esto de tesauros documentales sabe un rato, y me comentó ciertas ideas muy valiosas que explicaban en parte los resultados, y que se podrían resumir (Antonio, si andas por ahí, corrígeme si me equivoco) en que los tesauros no se adaptaban perfectamente a la colección sobre la que yo los aplicaba y que por tanto se necesitaría un tesauro hecho a mano para la colección con la que yo trabajo para obtener una mejora basada en el uso de tesauros documentales.

Tras este comentario me quede rumiando y modifique la colección para adaptarla terminológicamente a los tesauros con los que yo contaba, para hacer confluir ambos conjuntos de datos en lo posible y así comprobar si mejoraba algo la capacidad de recuperación de los tesauros, pero por desgracia los datos han seguido siendo bastante descorazonadores.

Después de todas estas pruebas me surgió la siguiente pregunta ¿realmente tienen lugar los tesauros hechos a mano, y basados en la metodología y normativas tradicionales en el panorama de recuperación automatizada imperante hoy, ya sea dentro o fuera de Internet?

Mi respuesta por el momento, y a falta de vuestros comentarios, es que no tienen lugar y que es necesario plantearse con urgencia varios cambios en la metodología de elaboración de tesauros que existe actualmente y de la que las normas ISO, el libro de Gilchrist y Aitchison y el libro de Blanca Gil, suponen las principales referencias.

Los principales problemas del uso de tesauros documentales en Recuperación de Información Automatizada son:

Todos estos problemas son normales teniendo en cuenta que son tesauros hechos y gestionados a mano sin ningún mecanismo más o menos automático de control de consistencia (de hecho la mera importación de los tesauros a SQL a permitido la detección de estas inconsistencias estructurales) más allá de programas tipo multites y demás.

A esto se suma que tal y como se hacen los tesauros hoy en día, y en contra de lo que muchos opinan, tampoco sirve para la transición a las ontologías, debido a cuestiones básicas de diseño (fundamentalmente el paradigma orientado a objetos) con las que los tesauros documentales no cumplen ni de lejos y que provoca serios problemas de consistencia cuando intentamos convertir un tesauro documental en una ontología.

En vista a estos hechos y a que yo no doy más de mi por el momento en este asunto, me gustaría conocer vuestra opinión en este tema (pues a muchos les va el pan en ello, pienso yo). Por concretar, las preguntas iniciales, sin excluir otras posible que podéis ir haciendo serían:

Yo, aunque no soy un experto tesaurista tengo mis opiniones que iré poniendo aquí si el debate tiene éxito, pero las que me interesan son las vuestras.

Espero haber sido claro, si tenéis cualquier duda sobre lo que he escrito o algo no se entiendo no dudéis en preguntar, espero que con suerte y entre todos le podamos dar un tiento a este problema tan puramente documental."

[Fin del texto de Pérez Agüera]

Pues ya saben, cualquier comentario, rectificación, aportación etc., en relación con las cuestiones planteadas en el texto anterior, pueden enviarlo a la referida lista IWETEL, y así enriquecer el debate que sin duda merece el conjunto de asuntos planteados por Pérez Agüera en relación con la recuperación de información, la indización automatizada, y el papel que los tesauros como instrumento de descripción normalizada juegan en todo ello...

De Pérez Agüera, y sobre los temas que aborda en su comunicación a la lista IWETEL, ver también: "Automatización de Tesauros y su utilización en la Web Semántica" (SWAD-Europe, taller Introducción al uso de la Web Semántica, 13 de junio 2004). Véanse también en general los SWAD-Europe Reports y SWAD-Europe Presentations. SWAD significa Semantic Web Activity: Advanced Development. También me parece pertinente reseñar, de la revista Anales de Documentación (nº 7, 2004, págs. 79-95), el artículo de Antonio García Jiménez "Instrumentos de Representación del Conocimiento: Tesauros versus Ontologías" (en PDF).

En otro orden de cosas, aprovecho la ocasión para relacionar a continuación una serie de enlaces, referencias y textos que han ido mereciendo mi atención en los últimos meses (los entrecomillados son citas textuales tomadas de los sitios referenciados):

Artículos, introducciones, anotaciones de "blogs":

Páginas y sitios web:

Conferencias, congresos:

[1] comentarios | # | lista |


Pro·Log·[IR],

Publicación: Blogger | Estadísticas: eXTReMe Tracking

Se recomienda ver este sitio con Mozilla 1+, Firefox 0.8+ ó Netscape 7+. Si no queda más remedio, con IE 6+. Si lo desea, comunique cualquier problema al respecto. También será bien recibida cualquier sugerencia sobre el contenido. La fuente de letra preferente es Georgia. Se prohibe la utilización del diseño de la página salvo autorización expresa del autor. Los contenidos escritos son de uso libre, siempre que se cite la fuente.