LNE2NEXI: Traductor de consultas del lenguaje natural a nexi con analizador sintáctico
- Materiales y métodos o metodología computacional
- Clasificación de operadores lógicos y relacionales
- Módulo para realizar el análisis sintáctico de las consultas en NEXI
- Resultados y discusión
- Conclusiones
- Referencias
Resumen
Para interactuar con los Sistemas de Recuperación de Información sobre documentos XML, los usuarios deben expresar tanto su necesidad de contenido como las restricciones estructurales en forma de una consulta estructurada. Históricamente, estas consultas estructuradas han sido elaboradas en lenguajes formales, tales como XPath o NEXI. Desafortunadamente, los lenguajes formales de consulta son demasiado complejos para ser utilizados por los usuarios inexpertos, y están estrechamente ligados a la estructura física subyacente de la colección de documentos XML.
La presente investigación se basa en la idea de especificar el contenido de los usuarios y las necesidades estructurales a través de consultas en lenguaje natural. Consecuentemente, se desarrolló un traductor que transforma consultas formuladas en lenguaje natural a NEXI, que incluye un analizador sintáctico que verifica si las consultas obtenidas están correctas sintácticamente.
Palabras claves: Analizador sintáctico, Recuperación de información XML, Traductor de Lenguaje natural a NEXI.
LNE2NEXI: TRANSLATOR OF QUERIES OF THE NATURAL LANGUAGE TO NEXI WITH
SYNTACTIC ANALYZER
ABSTRACT
To interact with information retrieval systems on XML documents, users must express both their need for content and structural constraints in the form of a structured query. Historically, these structured queries have been developed in formal languages ??such as XPath or NEXI. Unfortunately, formal query languages ??are too complex to be used by inexperienced users, and are closely linked to the underlying physical structure of the collection of XML documents.
This research is based on the idea of ??specifying users' content and structural needs through natural language queries. Consequently, it is developed a translator that converts natural language queries to NEXI. This translator includes a parser which checks if obtained queries are syntactically correct.
Keywords: Retrieval of XML information, Syntactic analyzer, Translator of the natural language to NEXI.
Introducción
Formular una consulta en lenguaje natural y obtener una respuesta pertinente es lo que el usuario frecuente echa de menos en el proceso de recuperación de información. Además, como el lenguaje natural es la mejor manera hasta ahora para exponer nuestra necesidad de información, su uso ayudaría en gran medida a cualquier Sistema de Recuperación de Información (SRI) si la consulta se analiza correctamente.
Sin embargo, en la actualidad, las técnicas de Procesamiento del Lenguaje Natural (NLP, siglas en inglés) no están lo suficientemente desarrolladas para acercarse a la percepción humana del lenguaje, y los resultados reales aún no se ajustan a los que podríamos esperar{Tannier, 2006 #402}.
En el caso de los SRI "tradicionales", donde los documentos se consideran solo como texto (documentos planos), los motores de búsqueda clásicos necesitan una consulta compuesta por una lista de términos o palabras claves. Redactar este tipo de consultas es muy simple para el usuario ocasional, y el valor añadido por las técnicas de NLP no vale la pena debido a la complejidad de las mismas.
Por otra parte, se han desarrollado muchas interfaces en lenguaje natural (NLI, siglas en inglés) para consultar documentos estructurados como bases de datos; la mayoría de ellos mediante la transformación del lenguaje natural al lenguaje de consultas SQL {Copestake, 1990 #379}. Los beneficios que se pueden obtener usando estas interfaces son mucho más altos que en la Recuperación de Información (RI) tradicional. De hecho, SQL (y cualquier lenguaje de consulta estructurado) es apenas usado por los usuarios inexpertos. Además, el empleo directo de estos lenguajes exige al usuario conocer la estructura de la base de datos (o de los documentos).
La Recuperación de Información sobre documentos XML (RI-XML) se enmarca entre estos dos dominios pues combina características de la RI tradicional y la RI sobre bases de datos. Debido a que los documentos XML separan el contenido de su estructura, los Sistemas de Recuperación de Información sobre documentos XML (SRI-XML) son capaces de retornar como respuesta a una consulta resultados más específicos dentro de un documento y no el documento en su totalidad. Para que el usuario tome ventaja de esta posibilidad se necesita una interfaz lo suficientemente flexible que recoja tanto los requerimientos estructurales como los de contenido de sus consultas. Históricamente, los SRI-XML han utilizado dos tipos de interfaces: una basada en palabras claves y otra basada en un lenguaje de consulta establecido con este fin. Los primeros son por lo general fáciles de usar, pero son incapaces de expresar las necesidades estructurales del usuario. En comparación, las interfaces basadas en algún lenguaje de consulta son capaces de expresar las necesidades estructurales de los usuarios (así como las necesidades de contenidos), pero no son prácticos para un uso operativo toda vez que son muy difíciles de utilizar, especialmente para los usuarios no expertos; además de que están atadas a la estructura física del documento.
El lenguaje de consultas NEXI (Narrowed Extended XPath I) {Trotman, 2005 #419}para la RI-XML se introdujo en el 2005 como un lenguaje derivado de XPath {Clark, 1999 #338} que elimina aspectos limitantes de este e incorpora nuevas características. La diferencia más significativa con XPath es la semántica. Mientras que en XPath se define la semántica, en NEXI el motor de recuperación debe deducir la semántica a partir de la consulta.
En la literatura se reportan diversos trabajos que tratan el empleo de técnicas de procesamiento del lenguaje natural para transformar consultas a lenguajes de recuperación de información ya establecidos como XPath y sus variantes, NEXI, etc.{Woodley, 2005 #418}. Sin embargo estos trabajos usan como lenguaje natural al idioma inglés y algunas de las herramientas obtenidas como resultado de sus investigaciones no son de carácter público.
Atendiendo a lo expuesto anteriormente se percibe como problema de investigación la necesidad de una herramienta que transforme consultas formuladas en lenguaje natural sobre el idioma español al lenguaje de consultas NEXI para ser usada en un SRI-XML.
De esta forma, el objetivo general del presente trabajo es desarrollar una herramienta en el lenguaje de programación Java que transforme consultas formuladas en lenguaje natural sobre el idioma español a NEXI. Para dar cumplimiento a este objetivo se plantean los siguientes objetivos específicos:
Desarrollar una herramienta que transforme las consultas formuladas en lenguaje natural a NEXI haciendo uso de técnicas de procesamiento del lenguaje natural.
Implementar un analizador sintáctico que verifique la sintaxis de las consultas escritas en NEXI y adicionarlo a la herramienta anterior.
Los resultados de esta investigación se podrán aplicar en múltiples escenarios con un impacto positivo desde el punto de vista social, educacional y económico, pues contribuirá a la incorporación en los Sistemas de Información existentes de un motor de búsqueda sobre documentos estructurados (XML), con una interfaz de consulta en lenguaje natural.
El traductor que se obtendrá podrá ser adaptado para que tenga una aplicabilidad inmediata en diversos escenarios como en la medicina, bibliotecas o repositorios científicos; permitiéndoles a los usuarios obtener información relevante sobre una colección de documentos XML formulando una consulta en lenguaje natural.
Materiales y métodos o metodología computacional
Transformación de las consultas de lenguaje natural a NEXI
Para efectuar la traducción de consultas de lenguaje
natural a NEXI se requirió un estudio de los lenguajes de consulta XML,
de las tecnologías existentes relacionadas con la RI y de técnicas
para el procesamiento del lenguaje natural. Este trabajo presenta una aproximación
para la transformación de consultas realizadas en lenguaje natural a
documentos XML y su traducción al lenguaje de consultas NEXI, siendo
este procedimiento transparente para el usuario ocasional.
Características generales del lenguaje de consultas NEXI
El lenguaje de consultas NEXI para la RI-XML se introdujo
en el 2005 como un lenguaje derivado de Xpath que elimina aspectos limitantes
de este e incorpora nuevas características.
La sintaxis de las consultas en NEXI es la siguiente:
//A[about(.//B,C)]
Donde A es la ruta de contexto, B es la ruta de acceso relativa y C es
el contenido requerido. Es posible que una sola consulta NEXI contenga más
de una solicitud de información. El objetivo de la solicitud se formula
primero y, a continuación cada una de las solicitudes de apoyo es insertada
mediante la búsqueda de su descendiente más cercano, siguiendo
el formato NEXI {Xavier Tannier, 2006 #439}.
Herramienta que realiza el proceso de traducción de LN a NEXI
A continuación se describe la confección de la herramienta que transforma consultas formuladas en lenguaje natural sobre el idioma español al lenguaje de consultas NEXI.
Las solicitudes realizadas en lenguaje natural fueron analizadas a través de varias etapas (Figura 1):
1. Análisis de la estructura: se detectan en caso de existir las definiciones que representan a las etiquetas de la colección XML.
2. Clasificación de solicitud de información: se clasifican las construcciones gramaticales típicas para indicar solicitud de información.
3. Clasificación de operadores lógicos: se detectan las conjunciones que representan operadores lógicos.
4. Clasificación de operadores relacionales: se buscan las construcciones gramaticales del idioma español (por ejemplo "mayor que", "igual a", "menor que", etc.), que representan operadores relacionales.
5. Clasificación del lenguaje: se procesan los elementos propios del lenguaje como adjetivos, sustantivos, pronombres, adverbios, entre otros.
6. Construcción de las consultas a NEXI: se transforman las consultas a NEXI, teniendo en cuenta que NEXI tiene la forma general: //A[about(.//B,C)],donde A es la ruta de contexto, B es la ruta de acceso relativa y C es el contenido requerido.A continuación se abordan los detalles del proceso de traducción.
Fig. 1. Flujo de la aplicación.
Análisis de la estructura
En esta etapa se detectan las limitaciones estructurales de los documentos XML sobre los cuales se realizan las consultas, para esto debe confeccionarse por el experto en el dominio de aplicación un diccionario, que contenga todas las construcciones gramaticales que se refieren a las etiquetas XML, de esta forma a la hora de utilizar la aplicación para otra base documental, lo único que varía es la confección de dicho diccionario, el que debe ser enriquecido mediante sinónimos y definiciones, para hacer más eficiente el proceso de traducción.
Los conocimientos sobre la estructura de la colección son muy importantes, sobre todo porque las etiquetas en los documentos XML son en muy pocas ocasiones equivalentes a las palabras o frases reales, sino abreviaturas o siglas. Por ejemplo en una base documental de autopsias se utiliza la abreviatura para nombrar a la etiqueta que representa el número de la autopsia y las siglas representan la causa directa de muerte).
Por otra parte, una única etiqueta se puede denominar con diferentes nombres (por ejemplo: "documento", "artículo", "trabajo" para referirse a un artículo científico).Los conocimientos gramaticales se pueden agregar con el fin de reconocer algunas construcciones lingüísticas frecuentes que implícitamente se refieren a la estructura (el agente del verbo "escribir" es un autor ()).En la Figura 2 se ilustra la estructura de los documentos XML de una base documental de autopsias con información relativa a las historias clínicas de autopsias que se practican en el Hospital "Arnaldo Milián Castro" de la ciudad de Santa Clara, utilizada como problema particular en esta investigación.
Fig. 2. Fragmento de la estructura de la colección XML correspondiente a autopsias.
En el análisis de la estructura la consulta realizada en lenguaje natural español es analizada en busca de requisitos estructurales (las etiquetas de los XML), los que son marcados y clasificados como caminos. Ver en la Figura 3 el análisis de la estructura.
Ejemplo1: Buscar las autopsias donde la causa directa de muerte sea insuficiencia cardiorespiratoria aguda.
Fig. 3. Análisis de la estructura.
Clasificación de la solicitud de información
La consulta original ya fue procesada por el módulo descrito en el epígrafe anterior, o sea ya se identificaron en caso de existir los caminos que representan la estructura de los XML. Se efectúa entonces la búsqueda de construcciones típicas en idioma español que nos indican solicitud de información (por ejemplo: "sobre", "que traten de", "que tengan", "que contengan", "que hablen de", etc.), estas construcciones son clasificadas como "about", etiqueta utilizada posteriormente en el proceso de traducción a NEXI.
Una vez identificada la solicitud de información se podrán obtener los requerimientos de contenido de los usuarios, tanto en términos como en frases. Estos términos de contenido se utilizan para crear una búsqueda contextual a lo largo de toda la estructura de los documentos.
Ejemplo2: Listar pacientes que tengan en los pulmones aisladas placas de ateroma (Ver figura 4).
Fig. 4. Clasificación de construcciones gramaticales que indican solicitud de información.
Clasificación de operadores lógicos y relacionales
Los operadores lógicos son detectados y clasificados como "opl", este grupo está compuesto generalmente por las conjunciones y, e, o, u, cuando estas están ubicadas entre requerimientos estructurales.
Por otro lado los operadores relacionales lo componen construcciones gramaticales típicas en idioma español (por ejemplo: "mayor que", "igual a", etc.), las que son clasificadas como "opr". Estos dan gran precisión si se desea una cantidad específica de documentos o documentos de un año determinado.
Ejemplo: Listar fallecidos que tengan número de autopsia mayor que 20 y el corazón tenga forma cónica, véase las figuras 5 y 6.
Fig.5. Clasificación de operadores lógicos
Fig.6. Clasificación de operadores relacionales
Clasificador del lenguaje
En esta fase la consulta ya ha sido analizada por los módulos anteriores y solo falta por identificar especificaciones del lenguaje como pronombres, adverbios, sustantivos y adjetivos. En este paso se eliminan de la consulta los elementos del lenguaje que se conoce no aportan nada en el proceso de traducción a NEXI, por ejemplo pronombres personales y adverbios. Se obtienen los requerimientos de contenido de los usuarios, tanto en términos o frases (en la figura 2.9 se ilustra la clasificación del lenguaje para la consulta en lenguaje natural del siguiente ejemplo).
Ejemplo: Listar fallecidos donde los números de las autopsias sean mayores que 20 y el corazón tenga forma cónica.
Fig.7. Clasificador del lenguaje
Formulación de consultas en NEXI
La etapa final de la traducción es la formulación de consultas NEXI, ya se conoce que de manera general la sintaxis NEXI es la siguiente:
//A[about(.//B, C)], donde A es la ruta de contexto, B es la ruta de acceso relativa y C es el contenido requerido.
Es posible que una sola consulta NEXI contenga más de una solicitud de información. El objetivo de la solicitud se formula primero y, a continuación cada una de las solicitudes de apoyo es insertada mediante la búsqueda de su descendiente más cercano, siguiendo el formato NEXI.
Como ya se había explicado anteriormente las consultas CAS en NEXI se construyen adoptando las tres formas posibles:
/ / A [B], devolver la etiqueta A sobre B
/ / A [B] / / C, descendientes C de A, donde A es sobre B (utilizado en INEX'02)
/ / A [B] / / C [D], descendientes C de A, donde A es sobre B y C sobre D, A y C son las rutas donde B y D son los filtros, respectivamente.
Ejemplo: Listar fallecidos donde los números de las autopsias sean mayores que 20 y el corazón tenga forma cónica (Figura 2.10).
Fig.8. Generador NEXI
Módulo para realizar el análisis sintáctico de las consultas en NEXI
A continuación se describe la confección de un módulo que chequea las consultas formuladas en NEXI, el mismo fue implementado en Java y posteriormente fue integrado al traductor propuesto en esta investigación. Para su realización se utilizó un analizador sintáctico para NEXI, de carácter público, implementado en Flex y Bison (herramientas compatibles con LEX y YACC).
Fig.9. Módulo para realizar el análisis sintáctico de las consultas en NEXI
El analizador léxico es el encargado de reconocer los distintos tipos de tokens de la gramática y analizar si estos están bien formados, en caso de no ser así reportará el error y parará el análisis. Para implementar el analizador sintáctico en Java, se utilizó JFlex que es un generador de analizadores lexicográficos desarrollado por Gerwin Klein como extensión de la herramienta JLex {Rojas, 2005 #451} desarrollada en la universidad de Princeton. Este software además de generar código en Java también fue realizado en este mismo lenguaje. Para utilizar JFlex sólo se necesita conocer: el conjunto de tokens del lenguaje y las expresiones regulares que lo definen.
El análisis sintáctico fue realizado con la herramienta CUP (Constructor of Useful Parsers) que genera código Java que implementa el analizador sintáctico a partir de un fichero con la especificación sintáctica del lenguaje. CUP genera dos ficheros con los nombres por defecto:
sym.java: contiene las definiciones de constantes de la clase sym, que asigna un valor entero a cada terminal y, opcionalmente, a cada no terminal.
parser.java: clase pública del analizador sintáctico.
Resultados y discusión
Pruebas realizadas a la herramienta
A continuación se describe el comportamiento de la herramienta ante una selección de consultas representativas para analizar el comportamiento de la herramienta en el proceso de traducción, se utiliza el analizador sintáctico incorporado a la aplicación para verificar que dichas consultas están sintácticamente bien formadas según las especificaciones del lenguaje de consultas NEXI.
Los ejemplos de las consultas fueron realizados utilizando los datos almacenados en una colección de documentos XML con información relativa a historias clínicas de autopsias y serán analizados de la manera siguiente:
consulta en lenguaje natural
respuesta del traductor
análisis efectuado por el parser
Ejemplos:
C1: Obtener las autopsias que traten deficiencias respiratorias
LNE2NEXI: //Autopsia[about(.,deficiencias respiratorias)]
Parser: Consulta CAS válida para NEXI
Ante esta consulta en lenguaje natural la herramienta retorna una consulta CAS clásica en NEXI, donde se especifica la estructura y se expresa la solicitud de información. Se deben devolver las autopsias sobre "deficiencias respiratorias". La consulta en NEXI obtenida con el traductor está bien formada sintácticamente lo que se puede asegurar gracias al Parser incluido en la herramienta.
C2: Devolver los fallecidos que presentaron como causa directa de muerte infarto cerebral
LNE2NEXI: //Autopsia [about (.//CDM, infarto cerebral)]
Parser: Consulta CAS válida para NEXI
La consulta en NEXI devuelta por el traductor nos indica que la etiqueta Autopsias constituye la ruta de contexto y la etiqueta CDM, representa la ruta de acceso relativa donde se realiza la búsqueda, en este ejemplo se restringe la búsqueda a la causa directa de muerte. Esta representa una consulta válida para NEXI.
C3: Listar los fallecidos cuyos riñones o pulmones presentaron lesiones asociadas
LNE2NEXI: //Autopsia[about (.//(Rinnones|Pulmones), lesiones asociadas)]
Parser: Consulta CAS válida para NEXI
En este caso se pretenden obtener las autopsias que presentaron en riñones o pulmones lesiones asociadas, lo que según el traductor puede ser expresado en NEXI de la forma siguiente: (.//(Rinnones|Pulmones).El parser interpreta la consulta devuelta por el traductor como una consulta CAS válida para NEXI.
C4: Devolver autopsias que presentan como causa básica de muerte la hipertensión arterial y como causa directa de muerte paro respiratorio
LNE2NEXI: //Autopsia[about(.//CBM, hipertensión arterial) and about(.//CDM, paro respiratorio)
Parser: Consulta CAS válida para NEXI
La consulta devuelta en NEXI hace uso de operadores lógicos, específicamente el AND lógico, se desea obtener las autopsias donde la causa básica de muerte es hipertensión arterial y la causa directa de muerte es paro respiratorio, se retornaran las autopsias que cumplan ambas condiciones. En la consulta se presentan dos rutas de acceso relativo y es sintácticamente correcta.
C5: Las autopsias con el epicardio liso y brillante o con el corazón cónico
LNE2NEXI:
//Autopsia[about(.//Epicardio,liso brillante ) or about(.//Corazon,cónico )]
Parser: Consulta CAS válida para NEXI
En este ejemplo se utiliza el operador lógico OR, se deben retornar autopsias donde el epicardio sea liso y brillante, o autopsias donde el corazón sea cónico.
Puede apreciarse que existe gran diferencia entre la consulta anterior y esta, pues en la primera se retornaran autopsias que cumplan ambas condiciones, mientras que en este caso se retornaran las que cumplan una u otra condición.
C6: causa básica de muerte ateromatosis severa de vasos coronarios
LNE2NEXI: //CBM[about(.,ateromatosis severa de vasos coronarios)]
Parser: Consulta CAS válida para NEXI
En el ejemplo se pone de manifiesto una de las ventajas de utilizar NEXI para consultar documentos estructurados, pues en este caso se pretende devolver solo la sección correspondiente a la etiqueta CBM (causa básica de muerte).
Se desea como respuesta a esta consulta en NEXI resultados más específicos dentro de un documento y no el documento en su totalidad, la consulta obtenida en NEXI es una consulta de contenido y estructura válida.
C7: Pacientes con número de autopsia mayor que 20 y que tengan el ano permeable sin alteraciones
LNE2NEXI:
//Autopsia[(.//Nro>20) and about (.//RectoAno, permeable sin alteraciones)]
Parser: Consulta CAS válida para NEXI
En la consulta se combinan dos elementos importantes, se utiliza un operador aritmético, que nos ofrece gran exactitud en la búsqueda y además se utiliza el operador lógico AND, explicado en ejemplos anteriores.
C8: En los pacientes que fumaban, devolver los que tuvieron causa directa de muerte cáncer pulmonar
LNE2NEXI: //Autopsia[about(.,fuman )]//CDM[about(.,cáncer pulmonar )]
Parser: Consulta CAS válida para NEXI
Este ejemplo representa una consulta con dos solicitudes de información (también llamado sub-temas):
//Autopsia[about(., fuman )]
And:
//Autopsia [about(.//CDM, cáncer pulmonar)]
En este caso se desea obtener las CDM por cáncer pulmonar dentro de los pacientes que fuman, lo que puede resultar de gran interés en caso de estudios médicos.
Conclusiones
Se desarrolló una herramienta que transforma las consultas formuladas en lenguaje natural a NEXI haciendo uso de técnicas de procesamiento del lenguaje natural, el sistema obtenido acepta una amplia variedad de consultas y ofrece buenos resultados.
Se implementó y añadió a la herramienta anterior un analizador sintáctico que permite verificar la sintaxis de las consultas obtenidas en el lenguaje de consultas NEXI.
Referencias
1. Tannier, X., From Natural Language to NEXI, an Interface for INEX 2005 Queries, in Advances in XML Information Retrieval and Evaluation, N. Fuhr, et al., Editors. 2006, Springer Berlin / Heidelberg. p. 373-387.
2. Copestake, A. and K.S. Jones, Natural language interfaces to databases. An introduction. The Knowledge Engineering Review, 1990. 5(04): p. 225-249.
3. Woodley, A. and S. Geva, NLPX at INEX 2006, in Comparative Evaluation of XML Information Retrieval Systems, N. Fuhr, M. Lalmas, and A. Trotman, Editors. 2007, Springer Berlin / Heidelberg. p. 302-311.
4. Trotman, A. and B. Sigurbjörnsson, Narrowed Extended XPath I (NEXI), in Advances in XML Information Retrieval, N. Fuhr, et al., Editors. 2005, Springer Berlin / Heidelberg. p. 16-40.
5. Clark, J. and S. DeRose, XML Path Language (XPath). 1999, Technical report, World-Wide-Web Consortium (W3C).
6. Tannier, X., J.-J. Girardot, and M. Mathieu, Analysing Natural Language Queries at INEX 2004, in Advances in XML Information Retrieval, N. Fuhr, et al., Editors. 2005, Springer Berlin / Heidelberg. p. 395-409.
7. Woodley, A. and S. Geva, NLPX at INEX 2005, in Advances in XML Information Retrieval and Evaluation, N. Fuhr, et al., Editors. 2006, Springer Berlin / Heidelberg. p. 358-372.
8. Woodley, A. and S. Geva, NLPX at INEX 2004, in Advances in XML Information Retrieval, N. Fuhr, et al., Editors. 2005, Springer Berlin / Heidelberg. p. 382-394.
9. Woodley, A. and S. Geva. NLPX – An XML-IR System with a Natural Language Interface. in ADCS 2004, Proceedings of the Ninth Australasian Document Computing Symposium. 2004: University of Melbourne, Department of Computer Science.
10. Geva, S. and A. Woodley, The NLP task at INEX 2005. SIGIR Forum, 2006. 40(1): p. 60-63.
11. Geva, S. and T. Sahama, The NLP task at INEX 2004. SIGIR Forum, 2005. 39(1): p. 50-53.
12. Zargayouna, H., V. Rosas, and S. Salotti, Shallow Parsing of INEX Queries, in Comparative Evaluation of XML Information Retrieval Systems, N. Fuhr, M. Lalmas, and A. Trotman, Editors. 2007, Springer Berlin / Heidelberg. p. 284-293.
13. Raja, F., et al., Using Rich Document Representation in XML Information Retrieval, in Comparative Evaluation of XML Information Retrieval Systems, N. Fuhr, M. Lalmas, and A. Trotman, Editors. 2007, Springer Berlin / Heidelberg. p. 294-301.
14. Tannier, X. and S. Geva, XML Retrieval with a Natural Language Interface, in String Processing and Information Retrieval, M. Consens and G. Navarro, Editors. 2005, Springer Berlin / Heidelberg. p. 29-40.
15. Baeza-Yates, R.A. and B. Ribeiro-Neto, Modern Information Retrieval. 1999: Addison-Wesley Longman Publishing Co., Inc. 513.
16. Bickley, L.S., B. Bates, and P.G. Szilagyi, Bates' Guide to Physical Examination And History Taking. 2005, Philadelphia, USA: Lippincott Williams & Wilkins.
17. Chiaramella, Y., P. Mulhem, and F. Fourel, A model for multimedia information retrieval. 1996, Technical Report, University of Glasgow. p. 58.
18. Amer-Yahia, S. and M. Lalmas, XML search: languages, INEX and scoring. SIGMOD Rec., 2006. 35(4): p. 16-23.
19. Navarro, G. and R. Baeza-Yates, Proximal nodes: a model to query document databases by content and structure. ACM Trans. Inf. Syst., 1997. 15(4): p. 400-435.
20. Fuhr, N. and M. Lalmas, Advances in XML retrieval: the INEX initiative, in Proceedings of the 2006 international workshop on Research issues in digital libraries. 2007, ACM: Kolkata, India. p. 1-6.
21. Kazai, G., Lalmas, M., and Malik, S, INEX"03 guidelines for topic development. 2003.
22. Li, Y., C. Yu, and H.V. Jagadish, Schema-free XQuery, in Proceedings of the Thirtieth international conference on Very large data bases – Volume 30. 2004, VLDB Endowment: Toronto, Canada. p. 72-83.
23. Tannier, X., JeanlJacques, and G.M. Mathieu, Analysing Natural Language Queries 2004.
24. Xavier Tannier , A.W., Approaches to Translating NL Queries for use in XML IR Systems.pdf. 2006.
25. Ferro, J.V., Aplicaciones del Procesamiento del Lenguaje Natural a la Recuperacion de Informacion en español2005.
26. Jones, K.S., What is the role of NLP in text retrieval? InTomek Strzalkowski, editor, Natural Language Information . Kluwer Academic Publisher, Dordrecht, NL. 1999: p. 1–24.
27. Rojas, S.G., Java a Tope Traductores y Compiladores con LEX/YACC, JFLEX/CUP Y JAVACC. 2005.
Autores:
Ernesto Pereiras García1*,
Darién Rosa Paz2
1Dirección Municipal de Finanzas y Precios, Mollinedo
# 6D / Martí y Felipe Pasos, Cifuentes, Villa Clara, Cuba.
2Universidad Central de las Villas, Carretera a Camajuaní
Km. 5.5, Santa Clara, Cuba
*Autor para la correspondencia:
CP 52900