tesis de maestrÍa en ciencias...lenguaje natural, sin considerar el dominio de la base de...
TRANSCRIPT
cenidet
Centro Nacional de Investigación y Desarrollo Tecnológico
Departamento de Ciencias Computacionales
TESIS DE MAESTRÍA EN CIENCIAS
Traductor de Consultas en Lenguaje Natural a SPARQL para Realizar Búsquedas sobre Ontologías
presentada por
Carlos Martín Vázquez Vásquez Ing. en Sistemas Computacionales por el I. T. de Minatitlán
como requisito para la obtención del grado de: Maestría en Ciencias en Ciencias de la Computación
Director de tesis: Dra. Azucena Montes Rendón
Co-Director de tesis: Dr. Hugo Estrada Esquivel
Cuernavaca, Morelos, México 05 de noviembre de 2010
cenidet
Centro Nacional de Investigación y Desarrollo Tecnológico
Departamento de Ciencias Computacionales
TESIS DE MAESTRÍA EN CIENCIAS
Traductor de Consultas en Lenguaje Natural a SPARQL para Realizar Búsquedas sobre Ontologías
presentada por
Carlos Martín Vázquez Vásquez Ing. en Sistemas Computacionales por el I. T. de Minatitlán
como requisito para la obtención del grado de: Maestría en Ciencias en Ciencias de la Computación
Director de tesis: Dra. Azucena Montes Rendón
Co-Director de tesis: Dr. Hugo Estrada Esquivel
Jurado:
Dr. Juan Gabriel González Serna – Presidente Dra. Alicia Martínez Rebollar – Secretario M.C.C. José Alejandro Reyes Ortiz – Vocal
Dra. Azucena Montes Rendón – Vocal Suplente
Cuernavaca, Morelos, México 05 de noviembre de 2010
iii
Dedicatoria
A Dios
Por acompañarme y guiar cada uno de mis pasos en todo momento de dificultad, por darme la familia y poner en mí camino los amigos que ahora tengo.
A mis padres
Carlos y Martina, por la educación que me dieron y el carácter que forjaron en mí, los cuales día con día valieron para no desfallecer antes las adversidades del entorno y siempre estuvieron ahí para motivarme a salir adelante cuando los problemas parecían no tener solución.
A mis hermanos
Antonio y Aranza, por todos los buenos momentos que pasamos, por su apoyo incondicional y preocupación constante.
iv
Agradecimientos
Agradezco a dos instituciones que me proporcionaron apoyo y formación para la culminación de mis estudios de maestría:
Al Consejo Nacional de Ciencia y Tecnología (CONACYT) por el apoyo económico que me brindó durante mis estudios de posgrado y durante mi estancia de investigación en España, cuyos resultados se reflejan en esta tesis.
Al Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET) por la preparación y formación que adquirí durante mis estudios de posgrado.
Esta tesis de maestría, si bien ha requerido esfuerzo y dedicación constante por parte de su autor y directora, no se hubiera culminado sin la colaboración de todas y cada una de las personas que a continuación mencionaré, muchas de las cuales han sido un soporte fuerte en momentos de angustia y desesperación.
A mis abuelos Felicitas y Esteban�, Julia y Timoteo que con sus consejos, regaños y buenos momentos logran formar la maravillosa familia con la que hoy cuento y siempre están dispuestos a apoyarme. Gracias a todos: tíos, primos, sobrinos, etc.
De igual manera mis más sinceros agradecimientos a mis asesores de tesis: la Dra. Azucena Montes Rendón por sus llamadas de atención, por sus recomendaciones y sobre todo por brindarme su amistad y apoyo incondicional en todo momento; al Dr. Hugo Estrada Esquivel por sus recomendaciones y orientaciones, además, por mantener siempre el buen humor y picardía que le caracteriza.
A mis revisores de tesis: Dr. Juan Gabriel González Serna, Dra. Alicia Martínez Rebollar y M.C.C. José Alejandro Reyes Ortiz, por todos sus comentarios y observaciones que contribuyeron a culminar con este proyecto.
También mi más grande agradecimiento a mis amigos de antaño Lilibeth, Miriam, Erika y Adrián, por todos los buenos recuerdos de cada momento que hemos pasado juntos, y sobre todo porque a pesar de la distancia se que siempre cuento con ustedes.
Un agradecimiento especial para las personas que llegaron a ser más que amigos: Alba, Lilian y Miguel muchas gracias por sus constantes consejos, comentarios y en ocasiones regaños para hacerme entrar en razón.
A mis compañeros y amigos de Sistemas Distribuidos, sin ninguna prioridad, Norma (NormiUX), Lizeth (una niña de azúcar), Adair (compita), Marino (el gordo), Cesar (casi coterráneo), Jeny y Toño (papás de pollo) y Hugo.
Para finalizar, y no menos importante, a @grupoTALN y @ironLP conformado por @reyes_or (Alex), y los mejor conocidos como “sólo una y nos vamos” (pero a otro lado) @r0manux (Felipe), @restrada9 (Ricardo) y @Munguua (Everardo).
A TODOS MIL GRACIAS.
v
Resumen
El gran volumen de datos disponibles en línea, la poca estructura y organización de los mismos,
hacen de la localización y recuperación de información una actividad que demanda tiempo y
esfuerzo, ante esta necesidad surgen los sistemas de recuperación de información, los cuales,
mediante el uso de interfaces en lenguaje natural se han convertido en herramientas esenciales
para el proceso de extracción, análisis y discriminación de información a partir de repositorios de
datos o la Web.
Actualmente, con el surgimiento de la Web semántica que tiene como finalidad dotar de
significado y estructura a la información contenida en la Web actual, emerge el concepto de
ontologías. Las ontologías son una representación abstracta de los conceptos de un dominio y
forman la base de la Web semántica.
Los sistemas de recuperación de información a partir de ontologías junto con las interfaces
de lenguaje natural crearon las bases para los sistemas de pregunta-respuesta sobre ontologías.
Estos sistemas tienen el objetivo de localizar información en ontologías a partir de una consulta
expresada en lenguaje natural. El reto primordial de estos sistemas es disminuir la brecha que
existe entre una consulta en lenguaje natural, y el lenguaje de consulta utilizado para acceder a las
ontologías: SPARQL.
El presente trabajo de tesis es parte de un sistema de recuperación de información a partir
de ontologías llamado ironLP. Este trabajo de tesis se enfoca en el desarrollo de un traductor que
genera tripletas y una consulta en lenguaje SPARQL a partir de una consulta expresada en
lenguaje natural, sin considerar el dominio de la base de conocimiento (ontología).
La consulta en lenguaje natural se analiza mediante expresiones regulares con la finalidad
de identificar patrones. Además, durante este proceso, se considera el tratamiento de fenómenos
lingüísticos como la elipsis y genitivo sajón. El resultados de estas actividades es la detección de
entidades (nombres) y acciones (verbos) presentes en la consulta en lenguaje natural con la
finalidad de construir tripletas.
Las tripletas generadas son estructuras del tipo <sujeto, predicado, objeto>, en las cuales
dependiendo del tipo de consulta, puede existir un componente desconocido (en consultas de tipo
ASK no se cuenta con estos valores) que representa el valor solicitado en la petición del usuario.
Las tripletas formadas se utilizan para construir la consulta en SPARQL correspondiente a la
solicitud del usuario en lenguaje natural.
vi
Abstract
The data amount available online, the little structure and organization of the same make localization
and information retrieval and activity that demands time and effort. Given this need arise,
information retrieval systems, which, using natural language interfaces have become essential tools
for the extraction, analysis and discrimination of information from data repositories or the Web.
Today, with the emergence of the semantic Web trying to give meaning and structure to the
information contained in the current Web, there emerges the concept of ontologies. Ontologies are
an abstract representation of the concepts in a domain and they are the backbone for the semantic
Web.
The information retrieval systems from ontologies and natural language interfaces together
formed the basis for question-answering systems on ontologies. These systems aim to locate
information in ontologies from a query expressed in natural language. The major challenge of these
systems is to break the gap between natural language query and the query language used to
access the ontologies, SPARQL.
This thesis is part of an information retrieval system based on ontologies named ironLP.
This thesis focuses on the development of a translator that generates triples and SPARQL
language query from a query expressed in natural language, regardless of the domain knowledge
base (ontology).
The natural language query is analyzed using regular expressions in order to identify
patterns. In addition, during this process, is considered the treatment of linguistic phenomena such
as ellipsis and Saxon genitive. The detection of entities (nouns) and actions (verbs) present in the
natural language query is the result of these activities in order to build triplets.
The triplets are type structures <subject, predicate, object>, in which depending on the
query type, there may be an unknown component (in ASK type queries there is lack of these
values) representing the data requested in the query user. The triplets are used to construct the
SPARQL query for the user request in natural language.
i
Tabla de contenido
Lista de figuras .................................. ................................................................................................ v
Lista de tablas.................................... .............................................................................................. vii
Glosario de términos y siglas ..................... .................................................................................... ix
Capítulo 1. Introducción ...................................... ......................................................................... 1
1.1 Planteamiento del problema...................................................................................................... 2
1.2 Descripción del marco de trabajo .............................................................................................. 3
1.3 Objetivos .................................................................................................................................... 6
1.3.1 Objetivo general ................................................................................................................. 6
1.3.2 Objetivos específicos ........................................................................................................ 6
1.4 Justificación y beneficios .......................................................................................................... 6
1.5 Alcances y limitaciones ............................................................................................................. 8
1.5.1 Alcances ............................................................................................................................. 8
1.5.2 Limitaciones........................................................................................................................ 8
1.6 Organización del documento..................................................................................................... 9
Capítulo 2. Marco teórico ..................................... ...................................................................... 11
2.1 Procesamiento del lenguaje natural ........................................................................................ 12
2.2 Recuperación de información, extracción de información y preguntas-respuestas ............... 13
2.3 Expresiones regulares para la identificación de patrones ...................................................... 14
2.4 Herramientas de la suite de Stanford ...................................................................................... 16
2.5 Extracción de tripletas mediante el reconocimiento de entidades .......................................... 16
2.6 Fenómenos lingüísticos: genitivo sajón y elipsis .................................................................... 17
2.7 Lenguaje de consulta SPARQL .............................................................................................. 19
ii
Capítulo 3. Estado del arte ................................... ...................................................................... 21
3.1 Definición de los criterios de análisis ..................................................................................... 22
3.2 QAS basados en ontologías utilizando técnicas de recuperación de información ................. 23
3.2.1 AquaLog ........................................................................................................................... 24
3.2.2 INVENIO ........................................................................................................................... 25
3.2.3 PowerAqua ....................................................................................................................... 26
3.3 QAS basados en ontologías utilizando el lenguaje de consulta SPARQL ............................. 28
3.3.1 GuNQ ............................................................................................................................... 28
3.3.2 Ginseng ............................................................................................................................ 29
3.3.3 Querix ............................................................................................................................... 29
3.3.4 NLP-Reduce ..................................................................................................................... 30
3.3.5 PANTO ............................................................................................................................. 31
3.3.6 QACID .............................................................................................................................. 32
3.3.7 NLION ............................................................................................................................... 33
3.4 Conclusiones y comparación con el trabajo de tesis .............................................................. 34
Capítulo 4. Metodología de solución .......................... ............................................................. 39
4.1 Vista general de la arquitectura del trabajo de tesis ............................................................... 40
4.2 Análisis lingüístico ................................................................................................................... 41
4.2.1 Análisis léxico/sintáctico ................................................................................................... 41
4.2.2 Identificación de fenómenos lingüísticos .......................................................................... 43
4.2.3 Reformulación de la consulta ........................................................................................... 51
4.3 Generación e identificación de patrones ................................................................................. 52
4.3.1 Generación del patrón de consulta .................................................................................. 52
4.3.2 Generación de tripletas de consulta ................................................................................. 53
4.3.3 Generación de consulta en SPARQL ............................................................................... 56
iii
Capítulo 5. Pruebas ........................................... ......................................................................... 61
5.1 Hipótesis .................................................................................................................................. 62
5.2 Convención de nombres ......................................................................................................... 62
5.3 Plan de pruebas ...................................................................................................................... 62
5.3.1 Introducción ...................................................................................................................... 62
5.3.2 Elementos de prueba ....................................................................................................... 63
5.3.3 Características probadas ................................................................................................. 63
5.3.4 Características excluidas de las pruebas ......................................................................... 64
5.3.5 Pruebas realizadas ........................................................................................................... 64
5.3.6 Enfoque ............................................................................................................................ 65
5.3.7 Criterios de éxito/fracaso de los casos de prueba ........................................................... 65
5.3.8 Tareas de prueba ............................................................................................................. 66
5.3.9 Liberación de pruebas ...................................................................................................... 67
5.3.10 Requisitos ambientales .................................................................................................. 67
5.3.11 Responsabilidades ......................................................................................................... 67
5.3.12 Aprobación ..................................................................................................................... 67
5.4 Especificación de los casos de prueba ................................................................................... 68
5.5 Resultados de las pruebas ...................................................................................................... 79
5.6 Análisis de los resultados ........................................................................................................ 92
5.7 Justificación de las pruebas fallidas ........................................................................................ 94
Capítulo 6. Conclusiones ...................................... ..................................................................... 97
6.1 Conclusiones ........................................................................................................................... 98
6.2 Aportaciones............................................................................................................................ 99
6.3 Trabajos futuros .................................................................................................................... 100
iv
Referencias ....................................... ............................................................................................. 101
Anexos… ………. ............................................................................................................................ 107
Anexo A. Herramientas libres para el procesamiento del lenguaje natural ................................ 108
Anexo B. Penn Treebank Tags ................................................................................................... 113
Anexo C. Ejemplos de estructuras gramaticales aceptadas ....................................................... 115
Anexo D. Resultados de la ejecución de las consultas dentro del banco de pruebas ............... 119
v
Lista de figuras
Figura 1-1. Arquitectura general del proyecto ironLP ......................................................................... 4
Figura 1-2. Arquitectura general del proyecto ironLP detallando el traductor de consulta ................. 5
Figura 3-1. Arquitectura genérica de la herramienta AquaLog ......................................................... 25
Figura 3-2. Vista general del funcionamiento de INVENIO ............................................................... 26
Figura 3-3. Arquitectura de PowerAqua ............................................................................................ 27
Figura 3-4. Arquitectura de la herramienta PANTO .......................................................................... 32
Figura 3-5. Arquitectura de la herramienta QACID ........................................................................... 33
Figura 3-6. Arquitectura de la herramienta NLION ........................................................................... 34
Figura 4-1. Arquitectura de la herramienta de tesis .......................................................................... 41
Figura 4-2. Árbol sintáctico generado por Stanford Parser ............................................................... 42
Figura 4-3. Palabras y categorías gramaticales de la consulta del usuario ..................................... 43
Figura 4-4. Generación de patrón con fenómenos lingüísticos ........................................................ 44
Figura 4-5. Tratamiento del caso genitivo y reformulación de consulta............................................ 45
Figura 4-6. Generación de sub-patrones unidos por conjunciones coordinantes ............................ 47
Figura 4-7. Reformulación de la consulta del usuario ....................................................................... 52
Figura 4-8. Plantilla de consulta SPARQL de tipo SELECT ............................................................. 57
Figura 4-9. Plantilla de consulta SPARQL selectiva con cláusula OPTIONAL ................................. 58
Figura 4-10. Plantilla de consulta SPARQL de tipo ASK .................................................................. 59
Figura 5-1. Ejecución del caso de prueba: ironLP-01-01 (tLp) ......................................................... 79
Figura 5-2. Ejecución del caso de prueba: ironLP-02-01 (tLp) ......................................................... 80
Figura 5-3. Ejecución del caso de prueba: ironLP-02-02 (tLp) ......................................................... 81
Figura 5-4. Ejecución del caso de prueba: ironLP-02-03 .................................................................. 82
Figura 5-5. Ejecución del caso de prueba: ironLP-02-04 (tLp) ......................................................... 83
Figura 5-6. Ejecución del caso de prueba: ironLP-03-01 (tLp) ........................................................ 84
vi
Figura 5-7. Tratamiento del caso genitivo del caso de prueba: ironLP-03-02 (tLp) ......................... 85
Figura 5-8. Ejecución del caso de prueba: ironLP-03-02 (tLp) ........................................................ 85
Figura 5-9. Tratamiento del fenómeno de la elipsis del caso de prueba: ironLP-03-03 (tLp) .......... 86
Figura 5-10. Ejecución del caso de prueba: ironLP-03-03 (tLp) ...................................................... 86
Figura 5-11. Tratamiento del caso genitivo del caso de prueba: ironLP-03-04 (tLp)....................... 87
Figura 5-12. Tratamiento del fenómeno de la elipsis del caso de prueba: ironLP-03-04 (tLp) ......... 87
Figura 5-13. Ejecución del caso de prueba: ironLP-03-04 (tLp) ...................................................... 87
Figura 5-14. Ejecución del caso de prueba: ironLP-03-05 (tLp) ...................................................... 88
Figura 5-15. Ejecución del caso de prueba: ironLP-04-01 (tLp) ...................................................... 89
Figura 5-16. Ejecución del caso de prueba: ironLP-04-02 (tLp) ...................................................... 90
Figura 5-17. Ejecución del caso de prueba: ironLP-04-03 (tLp) ...................................................... 91
Figura 5-18. Árbol sintáctico generado por Stanford Parser ............................................................. 95
vii
Lista de tablas
Tabla 2-1. Símbolos utilizados en expresiones regulares ................................................................ 15
Tabla 3-1. Comparativa de los QAS basados en ontologías utilizando técnica IR ........................... 24
Tabla 3-2. Comparativa de los QAS basados en ontologías utilizando el lenguaje de consulta SPARQL ............................................................................................................................................ 28
Tabla 3-3. Comparativa de las artículos del estado del arte con el trabajo de tesis ........................ 36
Tabla 4-1. Ejemplo de consulta en lenguaje natural ......................................................................... 42
Tabla 4-2. Correspondencia entre las categorías gramaticales y el valor asignado ........................ 44
Tabla 4-3. Algoritmo para la identificación y tratamiento de casos genitivo ..................................... 46
Tabla 4-4. Componentes lingüísticos presentes al comienzo de un subpatrón ............................... 48
Tabla 4-5. Resumen de expresiones regulares para la reformulación de consultas con elipsis ...... 49
Tabla 4-6. Algoritmo para la identificación y tratamiento de la elipsis (caso 1) ................................ 50
Tabla 4-7. Algoritmo para la identificación y tratamiento de la elipsis (caso 2) ................................ 51
Tabla 4-8. Categorías de expresiones regulares .............................................................................. 53
Tabla 4-9. Patrones para la generación de tripletas ......................................................................... 54
Tabla 4-10. Ejemplo de generación de tripletas................................................................................ 55
Tabla 4-11. Ejemplo de tripletas generadas ..................................................................................... 55
Tabla 4-12. Consulta construida en SPARQL ................................................................................... 60
Tabla 5-1. Descripción de las tareas de prueba ............................................................................... 66
Tabla 5-2. Características de hardware y software ........................................................................... 67
Tabla 5-3. Resultados del caso de prueba ironLP-01-01 (tLp) ......................................................... 79
Tabla 5-4. Resultados del caso de prueba ironLP-02-01 (tLP) ......................................................... 80
Tablas 5-5. Resultados del caso de prueba ironLP-02-02 (tLp) ....................................................... 81
Tabla 5-6. Resultados del caso de prueba ironLP-02-02 (tLp) ......................................................... 82
Tabla 5-7. Resultados del caso de prueba ironLP-02-04 (tLp) ......................................................... 83
Tabla 5-8. Resultados del caso de prueba ironLP-03-01 (tLp) ......................................................... 84
viii
Tabla 5-9. Resultados del caso de prueba ironLP-03-02 (tLp) ......................................................... 85
Tabla 5-10. Resultados del caso de prueba ironLP-03-03 (tLp) ....................................................... 86
Tabla 5-11. Resultados del caso de prueba ironLP-03-04 (tLp) ....................................................... 87
Tabla 5-12. Resultados del caso de prueba ironLP-03-05 (tLp) ....................................................... 88
Tabla 5-13. Resultados del caso de prueba ironLP-04-01 (tLp) ....................................................... 89
Tabla 5-14. Resultados del caso de prueba ironLP-04-02 (tLp) ....................................................... 90
Tabla 5-15. Resultados del caso de prueba ironLP-04-03 (tLp) ....................................................... 91
Tabla 5-16. Resultado de la primera ejecución de pruebas al banco de preguntas......................... 93
Tabla 5-17. Resultado de la segunda ejecución de pruebas al banco de preguntas ....................... 94
Tabla anexo 1. Comparación de herramientas para el procesamiento del lenguaje natural.......... 111
Tabla anexo 2. Penn Treebank Tags – Nivel de oraciones ............................................................ 113
Tabla anexo 3. Penn Treebank Tags – Nivel de frase .................................................................... 113
Tabla anexo 4. Penn Treebank Tags – Nivel de palabra ................................................................ 114
Tabla anexo 5. Ejemplos de formulación de nombres .................................................................... 115
Tabla anexo 6. Ejemplos de formulación de verbos ....................................................................... 116
Tabla anexo 7. Ejemplos de formulación de preguntas .................................................................. 117
Tabla anexo 8. Ejemplos de fenómenos lingüísticos en la gramática inglesa ................................ 118
Tabla anexo 9. Análisis de las preguntas del banco de prueba ..................................................... 119
ix
Glosario de términos y siglas
OWL (Web Ontology Language). OWL es un lenguaje de marcado
para publicar y compartir datos usando ontologías en internet.
QA (Question Answering). QA es la actividad de responder a
preguntas expresadas en lenguaje natural.
QAS (Question Answering System). QAS es una aplicación
desarrollada para realizar tareas de preguntas y respuestas.
RDF (Resource Description Framework). RDF es un framework para
metadatos en la World Wide Web (WWW), desarrollado por el
W3C.
SPARQL (SPARQL Protocol and RDF Query Language). SPARQL es una
recomendación para crear un lenguaje de consulta dentro de la
Web semántica.
Stanford Parser Un analizador léxico/sintáctico de oraciones para el idioma
inglés, mediante el análisis de las dependencias de las palabras
y generación de un árbol sintáctico.
TREC (Text Retrieval Conference). La TREC es un conjunto de
trabajos dirigidos a contribuir a la tarea de recuperación de
información.
URI (Uniform Resource Identifier). Un URI es una cadena corta de
caracteres que identifica inequívocamente un recurso (servicios,
página, documento, dirección de correo electrónico, etc.).
W3C (World Wide Web Consortium). W3C es el consorcio fundado en
1994, está formado aproximadamente de 400 organizaciones
miembros cuyo objetivo es desarrollar estándares Web.
Capítulo 1. Introducción
1
Capítulo 1. Introducción
En este capítulo se presenta el contexto del trabajo de tesis: la introducción al trabajo de tesis, el
problema que se aborda, la ubicación del trabajo dentro del proyecto llamado ironLP, los objetivos
perseguidos, la justificación, los beneficios que con éste se obtienen, y por último los alcances y
limitaciones considerados para el desarrollo de la investigación.
Capítulo 1. Introducción
2
1.1 Planteamiento del problema
Hoy en día, la World Wide Web se ha convertido en una de las principales fuentes de información,
por lo que contar con sistemas eficientes de recuperación de información se vuelve una necesidad
urgente.
Se necesitan sistemas que permitan a los usuarios realizar consultas a partir de solicitudes
en lenguaje natural, y que les proporcionen resultados precisos de acuerdo a sus peticiones,
utilizando mecanismos y técnicas de tratamiento del lenguaje que sean transparentes para él. Los
sistemas de preguntas y respuestas (mejor conocidos por sus siglas en inglés como Question
Answering Systems o QAS) tienen como objetivo solucionar este problema.
El número de investigadores interesados en técnicas de preguntas y respuestas en
lenguaje natural se ha incrementado a partir de la incorporación de los QAS a las áreas de interés
de la TREC (Text Retrieval Conference) en el año de 1999 [VOORHEES00]. Los QAS han sido
probados sobre distintos dominios y fuentes de datos, pero la implementación de todas sus
técnicas dentro de un nuevo paradigma de investigación conocido por su nombre en inglés
Ontology-Based Query Answering (peguntas y respuestas basadas en ontologías)
[WANG07][LÓPEZ09] está aún en desarrollo.
Las técnicas de análisis lingüístico dentro de los QAS basados en ontologías además de
encontrarse en evolución se encuentran limitadas al lenguaje de consulta recomendado por el
World Wide Web Consortium (W3C) denominado SPARQL. Este lenguaje de consulta se basa en
estructuras de tripletas, por lo que es necesario transformar la consulta en lenguaje natural del
usuario a estructuras del tipo <sujeto-predicado-objeto> y posteriormente integrar una consulta en
SPARQL.
Por lo tanto, el problema enfrentado en el presente trabajo es la carencia de métodos
formales o algoritmos que permitan la extracción de elementos relevantes en una consulta en
lenguaje natural con la finalidad de formar tripletas y construir consultas en SPARQL.
Debido al problema mencionado, se requiere desarrollar técnicas de análisis lingüístico que
permitan construir consultas en SPARQL mediante la identificación de estructuras de tripletas, sin
necesidad de conocer a priori la ontología ni su dominio.
Capítulo 1. Introducción
3
1.2 Descripción del marco de trabajo
Muchas de las técnicas de inferencia y de representación del conocimiento que han sido aplicadas
satisfactoriamente en sistemas basados en conocimiento, fueron desarrolladas para el
procesamiento del lenguaje natural (PLN), pero las aplicaciones para el PLN por sí mismas
siempre han parecido estar lejos de poder realizarse [PATTEN02].
El presente trabajo de tesis forma parte de un proyecto para la recuperación de información
a partir de ontologías denominado: ironLP (Information Retrieval from Ontologies using Natural
Language Processing).
El objetivo general que se persigue con el proyecto de ironLP es: “desarrollar una
herramienta que reciba consultas en lenguaje natural y permita la recuperación de información a
partir de un repositorio de datos estructurados como ontologías, y que mediante técnicas de
procesamiento de lenguaje natural y alineamiento de ontologías se conteste a una consulta del
usuario”.
La herramienta desarrollada en este trabajo utiliza expresiones regulares para la
identificación de patrones con la finalidad de analizar consultas en lenguaje natural en inglés para
formar tripletas, encontrando las dependencias entre sus componentes y obtener una estructura
del tipo <sujeto, predicado, objeto>.
La aportación del presente trabajo de tesis es la construcción de tripletas y consultas en
SPARQL a partir de una consulta del usuario en lenguaje natural sin necesidad de acceder a
alguna ontología.
La arquitectura en una vista general del proyecto ironLP tiene la estructura mostrada en la
figura 1-1:
Capítulo 1. Introducción
4
Figura 1-1. Arquitectura general del proyecto ironLP
La arquitectura anterior muestra los módulos del proyecto ironLP, los cuales se describen
de forma breve a continuación:
1. Traductor de consultas. El módulo recibe una consulta en lenguaje natural proporcionada
por el usuario, y la transforma a estructuras de tripletas con la finalidad de generar una
consulta en SPARQL.
2. Tratamiento ontológico. El módulo recibe las tripletas y consulta en SPARQL generadas a
partir de una consulta en lenguaje natural del usuario, y aplica técnicas de alineamiento de
ontologías con la finalidad de determinar las bases de conocimiento que den respuesta a la
solicitud del usuario.
3. Extracción de información. El módulo recupera la información contenida en las ontologías
(bases de conocimiento) y presenta la información de forma adecuada al usuario.
Una vista detallada de la arquitectura general del proyecto ironLP centrándose en el trabajo
realizado en la presente tesis se muestra en la figura 1-2:
Capítulo 1. Introducción
5
Figura 1-2. Arquitectura general del proyecto ironLP detallando el traductor de consulta
El módulo traductor de consultas, desarrollado en el presente trabajo de tesis, se encuentra
compuesto de los siguientes submódulos:
1. Análisis lingüístico. La función de este submódulo es categorizar los componentes
lingüísticos de la consulta del usuario mediante el uso de Stanford Parser, además
identificar y tratar los fenómenos de la elipsis y genitivo sajón para la reformulación de la
consulta del usuario en lenguaje natural.
2. Generación e identificación de patrones. La función de este submódulo es la identificación
de entidades (nombres) y acciones (verbos) para la construcción de las tripletas y la
consulta en SPARQL.
Capítulo 1. Introducción
6
1.3 Objetivos
1.3.1 Objetivo general
El objetivo general del presente trabajo de tesis es desarrollar una aplicación que tenga la
capacidad de recibir, analizar y transformar una consulta en lenguaje natural por parte del usuario,
a una sintaxis coherente del lenguaje de consulta SPARQL mediante el reconocimiento de
nombres y acciones.
1.3.2 Objetivos específicos
Para lograr el objetivo general, fue necesario cumplir con los siguientes objetivos específicos:
1. Implementar técnicas de análisis lingüístico para el reconocimiento de entidades (nombres)
y acciones (verbos y preposiciones) que componen la consulta realizada por el usuario.
2. Aplicar técnicas de procesamiento del lenguaje natural a una consulta realizada por el
usuario para la generación de tripletas.
3. Aplicar técnicas de procesamiento del lenguaje natural a una consulta realizada por el
usuario para la construcción de una consulta en SPARQL.
1.4 Justificación y beneficios
La extracción de información a partir de ontologías es un nuevo enfoque para los QAS, el
tratamiento lingüístico implementado por estos sistemas consiste en acceder de forma directa al
código fuente o background de la ontología, con la finalidad de conocer las relaciones entre las
entidades que la componen y a partir de ese momento extraer la información requerida por el
usuario mediante la implementación de servicios de relaciones de similitud [LÓPEZ06].
La aceptación de SPARQL como un lenguaje de consulta estándar, condujo a los
investigadores de esta área a dirigir esfuerzos para el desarrollo de técnicas de análisis lingüístico
en las que éste fuera el motor de consulta para ontologías.
Capítulo 1. Introducción
7
Muchas técnicas de análisis lingüístico se han realizado al respecto, pero debido a las
limitaciones del lenguaje de consulta SPARQL, algunas quedan restringidas al dominio para el cual
fueron desarrolladas o algunas otras requieren herramientas auxiliares para la construcción de las
consultas, independientemente de la herramienta para el análisis léxico/sintáctico.
La herramienta resultante de este trabajo de tesis permite construir consultas SPARQL
mediante la generación de tripletas a partir de la consulta en lenguaje natural, sin considerar el
dominio de la misma debido a la implementación de técnicas para la identificación de entidades
basadas en el análisis léxico/sintáctico generado por la herramienta Stanford Parser.
El presente trabajo de tesis se enfoca principalmente en el tratamiento lingüístico de la
consulta en lenguaje natural proporcionada por el usuario como parte del proyecto ironLP.
Los beneficios que se obtienen con el trabajo de tesis son:
• El desarrollo de una técnica genérica para la construcción de tripletas y consultas en
SPARQL sin considerar un dominio específico.
• Las facilidades para la integración de la herramienta desarrollada con otros sistemas que
requieran desempeñar la tarea de traducción de consultas mediante la generación de
tripletas.
• La identificación y tratamiento de algunos fenómenos lingüísticos presentes en la gramática
inglesa para facilitar la identificación de entidades (nombres) y acciones (verbos y
preposiciones) que conformarán las tripletas.
• El uso de expresiones regulares como mecanismo de identificación de entidades y
accesiones, lo que permite que la herramienta proporcione facilidades para ser extendida.
Además de los beneficios listados anteriormente, se dejan las bases necesarias para la
incorporación de la herramienta al proyecto ironLP.
Capítulo 1. Introducción
8
1.5 Alcances y limitaciones
1.5.1 Alcances
Los alcances considerados dentro de este trabajo de tesis se mencionan a continuación:
1. Implementación de técnicas para el procesamiento del lenguaje natural independientes del
dominio.
2. Representación de la consulta del usuario en lenguaje natural mediante una estructura en
forma de tripleta <sujeto-relación-objeto>.
3. Identificación del tipo de consulta SPARQL: selectivas (SELECT) y de respuestas si/no
(ASK), a partir de la solicitud de usuario.
4. Construcción de la consulta SPARQL a partir de los componentes gramaticales (palabras)
de la consulta realizada por el usuario.
5. Detección y tratamiento del fenómeno de la elipsis (economía de palabras) en las
consultas en lenguaje natural del usuario.
6. Detección y tratamiento del caso del genitivo sajón (posesivos en gramática inglesa) en las
consultas en lenguaje natural del usuario.
1.5.2 Limitaciones
A continuación se mencionan las limitaciones consideradas dentro de este trabajo de tesis:
1. La generación del patrón de la consulta depende en su totalidad del resultado del análisis
de la herramienta Stanford Parser.
2. Las preguntas con where, why, when, whom y how no son consideradas en el análisis
lingüístico de la consulta, debido a que requieren respuestas de tipo temporal, causal o
espacial y la metodología desarrollada no cubre estos aspectos.
3. Las consultas con elipsis no consideran el número de nexos coordinados presentes en la
misma, pero se limitan a que todos deben ser del mismo tipo, conjunción o disyunción, una
combinación de los mismos cambia el sentido semántico de la consulta.
Capítulo 1. Introducción
9
4. La herramienta no permite identificar si una consulta se encuentra bien formulada, esto es,
gramaticalmente correcta.
1.6 Organización del documento
La organización del presente trabajo de tesis se describe a continuación:
En el capítulo 2 se describe el marco teórico, el cual contiene los conceptos relevantes
para la compresión de este documento de tesis, comprende desde el procesamiento del lenguaje
natural hasta la generación de la consulta SPARQL, además del impacto dentro del trabajo de
tesis.
En el capítulo 3 se analiza el estado del arte con los trabajos revisados más
representativos, este capítulo se encuentra organizado en cuatro partes: la definición de los
criterios de evaluación de los trabajos revisados; análisis de aquellos que no utilizaron SPARQL y
aquellos que si lo consideraron para recuperar información desde ontologías; y la comparación con
el presente trabajo.
En el capítulo 4 se describe la metodología de solución utilizada para cumplir los objetivos
del presente trabajo de tesis, describiendo a detalle desde el análisis léxico/sintáctico de la
consulta en lenguaje natural hasta la generación de la consulta en lenguaje SPARQL.
En el capítulo 5 se analizan las pruebas de funcionalidad aplicadas a la herramienta, se
describe el plan de pruebas utilizado, los casos de prueba y los resultados obtenidos de su
ejecución.
Por último en el capítulo 6 se mencionan las conclusiones generadas con el desarrollo y
evaluación de este trabajo de tesis, las aportaciones logradas durante esta investigación y los
trabajos futuros.
Capítulo 1. Introducción
10
Capítulo 2. Marco teórico
11
Capítulo 2. Marco teórico
En este capítulo se describen los conceptos principales de este trabajo, cubriendo los temas de
procesamiento del lenguaje natural, las expresiones regulares para el reconocimiento de patrones,
extracción de tripletas, detección y tratamiento de fenómenos lingüísticos, hasta la generación de
consultas SPARQL.
Capítulo 2. Marco teórico
12
2.1 Procesamiento del lenguaje natural
El procesamiento del lenguaje natural (PLN) es un enfoque computacional para el análisis de
textos, está basado en un conjunto de teorías y tecnologías. En [DRAKE08] se define PLN como:
“Un grupo de técnicas computacionales motivadas teóricamente para el análisis y
representación de textos en lenguaje natural en uno o más niveles de análisis lingüístico con el
propósito de procesar el lenguaje humano para un conjunto de tareas o aplicaciones.”
A pesar de que el PLN ha tenido grandes avances en los últimos veinte años, esta
tecnología aun no ha tenido un impacto revolucionario en la sociedad, todo ello como
consecuencia de la maleabilidad del lenguaje natural.
Los resultados más visibles en esta área se ven reflejados en sistemas comerciales como
un QAS enfocado hacia base de datos. Tradicionalmente se puede dividir el procesamiento del
lenguaje natural en tres fenómenos [BATES93]:
1. Fenómeno sintáctico, es el relacionado a la estructura de la sentencia y al orden de las
palabras en la misma, basado en las categorías gramaticales de las palabras más que
en su significado.
2. Fenómeno semántico, es el relacionado al significado de una sentencia
independientemente del contexto en el que está ocurriendo.
3. Fenómeno pragmático, es el relacionado al proceso de enlazar el significado de una
sentencia al contexto en la cual ésta ocurre, el cual puede ser lingüístico o no
lingüístico.
El procesamiento del lenguaje natural comprende distintas fases análisis, cada una de ellas
se describe a continuación:
1. Análisis fonológico. Es el estudio de la estructura sonora del lenguaje. Los sonidos son
organizados en una estructura de contrastes y analizados en términos de fonemas. Un
fonema es la unidad mínima del sistema de sonidos de un lenguaje.
2. Análisis morfológico o léxico. Es el estudio de las estructuras que permiten la
formación de las palabras, separando de éstas sus elementos básicos o morfemas, a
partir de un proceso de lematización (obtención de la raíz de la palabra).
Capítulo 2. Marco teórico
13
3. Análisis sintáctico (parsing). Es el estudio de las estructuras que combinadas forman
oraciones. Las estructuras sintácticas se analizan en secuencias de categorías
sintácticas (o clases). El orden de dichas estructuras se establece sobre la base de
relaciones sintácticas.
4. Análisis semántico. Es el estudio del significado de las construcciones de un lenguaje.
Se hace una correspondencia entre las estructuras sintácticas y los objetos del dominio
[ZÁRATE07].
Las técnicas de procesamiento del lenguaje natural se han implementado en distintas
actividades concernientes a obtener información a partir de una fuente de datos, estas actividades
son la recuperación de información (de sus siglas en inglés Information Retrieval, IR), la extracción
de información (de sus siglas inglés Information Extraction, IE) y preguntas-respuestas (de sus
siglas en inglés Question Answering, QA). En la presente tesis se trabajó en la fase de análisis
lingüístico para un sistema QA.
2.2 Recuperación de información, extracción de info rmación y preguntas-respuestas
Hoy en día, las investigaciones y técnicas en los campos de la recuperación de información (IR),
extracción de información (IE) y preguntas-respuestas (QA) se acotan cada vez más, por lo que las
fronteras entre cada uno de ellos resulta difícil de diferenciar.
Los sistemas de preguntas-respuestas (de sus siglas en inglés Question Answering
Systems, QAS) analizan una consulta en lenguaje natural con el objetivo de encontrar una o más
respuestas a la misma a partir de una fuente de datos, presentando la(s) respuesta(s) en forma
apropiada al usuario. En [HIRSCHMAN01] se describen algunas semejanzas entre los QAS con los
sistemas de IR e IE.
El proceso de recuperación de información (IR) toma lugar en la localización de
documentos relevantes como respuesta a una consulta del usuario. La IR está relacionada con QA
en el sentido de que el usuario desea encontrar una respuesta a una consulta, pero los sistemas IR
regresan documentos completos y no respuestas concretas, por lo que los usuarios tienen que
extraer la información requerida localizándola de forma manual mediante la lectura del documento.
Las técnicas empleadas en la recuperación de información (IR) son relevantes para los
sistemas QA por dos razones: primero, las técnicas de IR se pueden extender para retornar no sólo
Capítulo 2. Marco teórico
14
documentos sino fragmentos relevantes contenidos en los mismos, al grado de que estos
fragmentos pueden ser tan concretos como una respuesta exacta; y segundo, la comunidad de IR
ha desarrollado mecanismos de evaluación de sus técnicas, entre la más conocida se encuentra la
Text REtrieval Conferences que se realiza de forma anual, respaldada sobre el US National
Institute of Standards and Technology, la cual ha estimulado el interés por los QAS.
El proceso de extracción de información (IE) ha despertado el interés de los sistemas QA
dentro del TREC. La IE se describe como la actividad de rellenar plantillas definidas a partir de
texto en lenguaje natural. Una plantilla puede ser vista como la expresión de preguntas y una
plantilla llenada como el contenedor de respuestas. Los sistemas de IE podrían ser vistos como
una versión limitada de sistemas QA en las cuales las preguntas (plantilla) son estáticas y los datos
a partir de los cuales las preguntas serán contestadas son una colección arbitraria de texto.
El desarrollo de técnicas para los sistemas de preguntas-respuestas (QAS) se centra en la
etapa de análisis lingüístico debido a los problemas y fenómenos inmersos en el lenguaje natural.
Hoy en día existen muchas técnicas de análisis, entre la más aceptadas y fácilmente adaptables se
encuentra el reconocimiento de patrones mediante expresiones regulares, técnica empleada para
el análisis lingüístico en el presente trabajo de tesis.
2.3 Expresiones regulares para la identificación de patrones
Las expresiones regulares son una representación algebraica de un patrón. En
[MUSZÁTKO96] se definió formalmente una expresión regular de la siguiente manera:
Una expresión regular V sobre un alfabeto A es definida de la siguiente forma:
1. ∅, ε, a son expresiones regulares para todo a ∈ A.
2. If x, y son expresiones regulares sobre A entonces:
a) ( x + y ) (unión)
b) ( x • y ) (concatenación)
c) (x)* (cerradura)
son expresiones regulares sobre A.
Capítulo 2. Marco teórico
15
Lo anterior se resume en que toda expresión regular basada en un alfabeto puede generar
muchas producciones, lo que en el presente trabajo se denomina patrón.
Un patrón es un conjunto de objetos que cuentan con propiedades identificables y
numerables, un ejemplo de un patrón son las fases lunares que comprenden siete etapas
repetitivas desde la luna nueva hasta la luna menguante pasando por la luna llena.
Las expresiones regulares utilizan símbolos especiales con la finalidad de aumentar o
enriquecer el número de patrones identificables, algunos de los símbolos utilizados en el trabajo
de tesis se resumen en la tabla 2-1:
Tabla 2-1. Símbolos utilizados en expresiones regulares
Símbolo Significado
*
Encuentra la coincidencia del o los caracteres que
preceden a este símbolo desde cero a muchas
repeticiones.
+
Encuentra la coincidencia del o los caracteres que
preceden a este símbolo desde una a muchas
repeticiones.
^ Establece el comienzo de un patrón.
x | y Evalúa la aparición de alguno de los dos valores
establecidos.
( )
Identifica patrones con los caracteres que
contiene respetando el uso de símbolos
especiales como “\” (escape).
[ ]
Identifica patrones con los caracteres que
contiene y desactiva el significado de símbolos
especiales.
Las expresiones regulares usadas en este trabajo fueron generadas con base en un
alfabeto reducido, el cual es generado a partir de la categoría gramatical de las unidades
lingüísticas (palabras) de la consulta del usuario. Este proceso es posterior y totalmente
dependiente al análisis léxico/sintáctico que se realiza mediante el razonador Stanford Parser
perteneciente a la suite de herramientas de Stanford.
Capítulo 2. Marco teórico
16
2.4 Herramientas de la suite de Stanford
La suite de herramientas de Stanford [STANFORD10] son un conjunto de aplicaciones para el
PLN, están escritas en lenguaje java, y están siendo desarrolladas y mejoradas por el grupo de
investigación del Procesamiento del Lenguaje Natural de la Universidad de Stanford.
Todas las herramientas pertenecientes a suite de Stanford son de código abierto bajo una
licencia libre. Algunas de las herramientas que conforman la suite de Stanford son:
• Stanford Parser. Implementación de java de un analizador del lenguaje natural
probabilístico.
• Stanford POS Tagger. Implementación en java de algoritmos de máxima entropía para el
análisis de datos y de part-of-speech tagger.
• Stanford Named Entity Recognizer. Una implementación en Java de un modelo secuencial
de Conditional Random Field (CRF) junto con otras características para el reconocimiento
de nombres de entidades.
La herramienta Standford Parser es una analizador probabilístico del lenguaje natural,
implementado en lenguaje java. Una versión on-line de la herramienta se encuentra disponible en
[STANFORD10], además, tiene soporte para los idiomas: inglés, árabe y chino. Stanford Parser
cuenta con funcionalidades como: POS tagging, parser, typed dependencies y typed dependencies
collapsed.
La herramienta Stanford Parser genera un árbol de análisis sintáctico basado en el
etiquetado propuesto en el Penn Treebank Project [PTP10], este árbol de análisis sintáctico sirve
de base para la extracción de las tripletas de consulta.
2.5 Extracción de tripletas mediante el reconocimie nto de entidades
Una tripleta puede ser vista como una relación entre sujeto y objeto de una oración, en donde la
relación es formada por el predicado de la misma [HOOGE06] [DALI09]. La generación de tripletas
en el presentante trabajo de tesis comienza a partir del análisis sintáctico realizado por la
herramienta Stanford Parser.
Capítulo 2. Marco teórico
17
El reto de convertir a partir de una estructura de árbol sintáctico a tripletas radica en la
complejidad de la relaciones entre sus entidades [HOOGE06]. El proceso de creación de tripletas
involucra varios pasos dependiendo del enfoque de cada autor, en los trabajos de [HOOGE06] y
[DALI09] conciben la idea de realizar un reconocimiento de entidades (y consideraciones
involucradas) como el paso principal para la generación de tripletas.
El reconocimiento de entidades involucra la identificación de los componentes de las
tripletas, considerando que una relación puede ser formada a partir de elementos adheridos a los
verbos, como adjetivos o preposiciones.
El objetivo principal de la creación de tripletas es representar el contenido de las consultas
en lenguaje natural con una estructura semejante a RDF, el cual es el marco de trabajo para la
representación del conocimiento de la Web semántica [HOOGE06].
La generación de tripletas en el presente trabajo se basa en el reconocimiento de las
entidades que formarán el sujeto y objeto de la tripleta, en este caso mediante expresiones
regulares se extraen nombres. El predicado (relación) entre los dos primeros componentes se
obtiene mediante la identificación de la acción (verbo).
Los nombres y verbos no son los únicos componentes lingüísticos que contribuyen a la
generación de tripletas, las frases preposicionales en muchas ocasiones indican una relación entre
dos entidades [DALI09], las cuales también son consideradas dentro del presente trabajo de tesis.
La extracción de tripletas es una actividad compleja cuando se atacan fenómenos
intrínsecos en la gramática del lenguaje, como son el genitivo sajón y la elipsis, problemas
presentes en la gramática y considerados en el presente trabajo de tesis.
2.6 Fenómenos lingüísticos: genitivo sajón y elipsi s
La gramática inglesa a pesar de ser una lengua lo suficientemente estudiada, cuenta con
características propias que limitan o retardan su análisis mediante herramientas computacionales,
estas características se denominan fenómenos lingüísticos, en el presente trabajo se consideraron
estudiar y tratar dos de ellos: el genitivo sajón y la elipsis.
El genitivo sajón es conocido en ocasiones como el caso posesivo o la forma posesiva. El
genitivo sajón se identifica mediante el uso de ‘s o s’ exclusivamente para personas u organismos
Capítulo 2. Marco teórico
18
vivientes. La construcción ‘s no es posible en the key of the door o the leg of the table por la regla
mencionada anteriormente [ALEXANDER99].
En la gramática inglesa el nombre poseedor se le conoce como poseedor adnominal
[ROSENBACH07], el cual recibe su nombre dependiendo su ubicación en la expresión de genitivo,
se denomina prenominal cuando el poseedor se encuentra al comienzo de la oración como John’s
wife, y se denomina postnominal cuando el poseedor se encuentra al final de la oración como roof
of the house.
En el presente trabajo de tesis se consideran los dos casos genitivos. Cuando se presente
un poseedor en posición adnominal o en posición prenominal, la expresión se analiza y trata para
reescribirla en su forma equivalente en posición postnominal, uniéndolas mediante la preposición
of la cual es equivalente a una relación de partencia [ALEXANDER99].
La elipsis es un fenómeno lingüístico ampliamente estudiando, se refiere a la economía de
palabras para evitar ser redundantes al momento de expresar una idea por cualquier medio.
Existen diferentes definiciones de elipsis aunque todas tienen un significado en común en el que la
consideran como un mecanismo de eliminar elementos repetitivos en una oración, las cuales
podrían ser considerados como obvios.
Según [ALLEN95] la elipsis implica el uso de oraciones que son incompletas
sintácticamente. En [COVINGTON94] se define al fenómeno de la elipsis como la omisión de
palabras repetidas dentro de una frase.
El análisis de las preguntas en lenguaje natural en el presente trabajo considera el
fenómeno de la elipsis, con la finalidad de reconstruir la pregunta original en dos o más consultas
complementando la información que fue omitida.
El tratamiento del caso genitivo y después considerar la presencia de la elipsis, generan
una consulta extensa con el mismo significado (sin considerar implicaciones semánticas de la
gramática) a la consulta original del usuario, este procedimiento es básico para la formulación de la
consulta en SPARQL sólo con la información contenida en las tripletas.
Capítulo 2. Marco teórico
19
2.7 Lenguaje de consulta SPARQL
Los QAS son desarrollados con la finalidad de recuperar información precisa a partir de una
solicitud del usuario, el proceso de recuperación se encuentra ligado a un lenguaje de consulta,
que a su vez depende de la fuente de datos desde la que se desea recuperar la información.
El presente trabajo hace uso de SPARQL [SPARQL08] como lenguaje de recuperación de
información a partir de ontologías. El lenguaje SPARQL es una recomendación del W3C desde el
15 de enero de 2008, con el objetivo principal de consultar bases de conocimiento expresadas en
RDF u OWL.
RDF y OWL son estándares para la Web semántica que proporcionan una infraestructura
para la compartición y reutilización de datos en la Web [W3C10]. SPARQL es un lenguaje para
consultar repositorios de tripletas, bien expresadas en RDF puro o como parte de una ontología
OWL.
Las clausulas más usuales en las consultas SPARQL son la SELECT y WHERE, ésta
última usa una sintaxis de tripletas para definir las condiciones que deben ser cumplidas, cada uno
de los componentes de las tripletas deben de estar escritos de forma completa, es decir,
acompañados de la URI correspondiente o en el mejor de los casos del PREFIX que la representa.
La salida de una consulta SPARQL es un grafo serializado RDF/XML o un enlace
serializado XML. Un ejemplo de consulta SPARQL se muestra a continuación:
PREFIX tutor: <http://inria.fr/2007/tutorial.rdfs>
SELECT ?student ?name ?firstname
WHERE {
?student tutor:isStudentOf ?univ .
?student tutor:name ?name .
OPTIONAL {
?student tutor:firstname ?firstname .
}
?student tutor:age ?age .
FILTER ( ?age > 21 )
Capítulo 2. Marco teórico
20
}
ORDER BY ?name
LIMIT 20
En la cual se declara un prefijo (PREFIX) denominado tutor que hace referencia a una URI
determinada, el resultado de la consulta serán los nombres de los estudiantes que de manera
opcional pueden ir acompañados de su primer apellido, además sólo mostrará aquellos con una
edad superior a los 21 años y ordenados por nombre.
El presente trabajo considera generar una estructura de consulta SPARQL solamente de la
información proporcionada en la consulta del usuario, y creado prefijos (PREFIX) que se
consideran estándares al momento de generar las ontologías (tales como rdf, rfs, owl). Permite
también la generación de consultas de tipo ASK (además de SELECT) cuya finalidad es la de
comprobar si las tripletas contenidas en consultas de este tipo pueden ser emparejadas una a una
con las relaciones en la ontología.
Capítulo 3. Estado del arte
21
Capítulo 3. Estado del arte
La necesidad por contar con QAS para el proceso de recuperación de información mediante un
análisis lingüístico eficiente, ha motivado a muchos investigadores a desarrollar e implementar
técnicas de tratamiento del lenguaje natural que contribuyan a esta necesidad, por lo que en el
presente capítulo se describen los trabajos más representativos acerca de este problema, éstos se
encuentran organizados de acuerdo al mecanismo de recuperación de información desde las
ontologías y finalmente se presenta una comparativa contra el presente trabajo de tesis.
Capítulo 3. Estado del arte
22
3.1 Definición de los criterios de análisis
Hoy en día, existen muchas técnicas de recuperación de información que han sido aplicadas y
probadas en situaciones reales, durante el estudio del estado del arte, se prestó especial interés en
el proceso de análisis la de consulta en lenguaje natural y al mecanismo de representación
intermedia (en caso de haberlo) a partir del cual se extrae la respuesta.
Las características que se analizaron en cada artículo son las siguientes:
1. Lenguaje aceptado en la consulta. Define la forma de realizar la consulta, sin considerar las
implicaciones inmersas en las limitaciones del mismo (preguntas completas, bien
formuladas, entre otras). Los criterios considerados son:
- Libre. Las consultas no cuentan con criterios establecidos en cuanto a la forma de
realizarse.
- Acotado. Las consultas se encuentran establecidas o la herramienta indica la forma
y qué preguntar.
- Palabras claves. La forma de preguntar es con base en los conceptos y no bajo
una sintaxis correcta de pregunta.
2. Análisis léxico/sintáctico. Define la forma de analizar los componentes gramaticales
(palabras) de la consulta del usuario. Los criterios considerados son:
- Herramienta. El nombre de la herramienta utilizada para el análisis.
- Técnica. El nombre de la técnica utilizada para el análisis.
- Ninguna. El artículo no mencionan ninguna de las dos anteriores o no aplica.
3. Fenómeno lingüístico: Elipsis. Define si la herramienta realiza la detección y tratamiento
(con las implicaciones de cada artículo) del fenómeno de la economía de palabras o
elipsis. Los criterios de evaluación son: si o no.
4. Fenómeno lingüístico: Genitivo sajón. Define si la herramienta realiza la detección y
tratamiento (con la implicaciones de cada artículo) de los casos genitivos o posesivos. Los
criterios de evaluación son: si o no.
Capítulo 3. Estado del arte
23
5. Técnica de análisis lingüístico. Define el mecanismo implementado para realizar el proceso
de análisis de la consulta del usuario. El criterio de evaluación es el nombre de la técnica,
método o herramienta implementada.
6. Representación intermedia: tripletas. Define si la herramienta genera tripletas como
resultado de la misma o como representación intermedia de la consulta del usuario. Los
criterios de evaluación son: si o no.
7. Representación intermedia: consulta SPARQL. Define si la herramienta genera una
consulta en SPARQL como resultado de la misma o como representación intermedia de la
consulta del usuario. Los criterios de evaluación son: si o no.
8. Dominio de aplicación. Define el domino sobre el cual se sustentó el desarrollo de la
herramienta. Los criterios de evaluación son:
- Abierto. El proceso de análisis de la consulta del usuario es independiente al
dominio de aplicación.
- Acotado. El proceso de análisis de la consulta del usuario depende del dominio de
aplicación y la técnica empleada no se puede aplicar en un dominio diferente.
El análisis de cada uno de los artículos, además de los criterios para ser comparados con
el presente trabajo de tesis, se deben de organizar bajo algún criterio como: el enfoque del autor,
dominio de aplicación, tipo de herramienta, entre otros, es este último el utilizado para presentar el
estado del arte.
Los artículos se encuentran organizados considerando los QAS basados en ontologías que
extraen información utilizando técnicas de IR, y aquellos que utilizan el lenguaje de consulta
SPARQL.
3.2 QAS basados en ontologías utilizando técnicas d e recuperación de información
En el análisis de artículos de esta sección, se consideraron sólo algunos representativos (cuyas
bases se sustentan en recuperar información desde ontologías) que cuentan con un mecanismo
de recuperación de información a partir de una consulta expresada en lenguaje natural.
Capítulo 3. Estado del arte
24
En la tabla 3-1 se resumen los aspectos antes mencionados para cada herramienta
analizada en esta sección.
Tabla 3-1. Comparativa de los QAS basados en ontologías utilizando técnica IR
AQUALOG [LÓPEZ06]
INVENIO [VIVANCOS09]
POWERAQUA [LÓPEZ09]
Lenguaje aceptado en la consulta Libre Libre Libre
Análisis léxico/sintáctico GATE Ninguna GATE
Fen
ómen
o lin
güís
tico Elipsis Si No Si
Genitivo sajón No No No
Técnica de análisis lingüístico Categorías Ontología de dominio Categorías
Rep
rese
ntac
ión
inte
rmed
ia Tripletas Si No Si
Consulta SPARQL Si No Si
Dominio de aplicación Abierto Acotado Abierto
A continuación se proporciona una descripción del funcionamiento de los trabajos
comparados en la tabla 3-1.
3.2.1 AquaLog
El sistema AquaLog [LÓPEZ06] es un sistema de preguntas y respuestas portable el cual toma
como entradas consultas expresadas en lenguaje natural y una ontología con información de un
dominio específico, y retorna respuestas desde una o más bases de conocimiento (KBs)
instanciadas a partir de la ontología de entrada.
El sistema AquaLog está implementado en Java como una aplicación Web modular,
usando la arquitectura cliente-servidor. El Componente Lingüístico (Linguistic Component) y el
Servicio de Similaridad de Relaciones (RSS, Relation Similatiry Service) son los dos componentes
centrales del sistema (ver figura 3-1).
Capítulo 3. Estado del arte
25
Figura 3-1. Arquitectura genérica de la herramienta AquaLog
El núcleo de la arquitectura es el enfoque de representación de los datos basado en
tripletas, una consulta introducida en el sistema puede ser transformada en una o más tripletas
lingüísticas, y cada tripleta lingüística puede ser traducida en una o más tripletas de ontología.
El componente Relation Similarity Service (RRS) se invoca después de que la consulta en
lenguaje natural ha sido transformada en la forma relación-término y clasificada en la categoría
apropiada. El RSS es el componente principal responsable de la generación de la consulta lógica
compatible con la ontología. Esencialmente, el RSS trata de dar sentido a la consulta introducida
mirando la estructura de la ontología y la información almacenada en la base de conocimiento (de
sus siglas en inglés Knowledge Base, KB), usando emparejamiento de similitud de cadenas,
recursos léxicos genéricos como WordNet, y un lexicón dependiente del dominio obtenido a través
del uso de un mecanismo de aprendizaje. Un aspecto importante del componente RSS es que es
interactivo, debido a que cuando surge una ambigüedad entre dos o más términos o relaciones el
usuario será requerido para interpretar la consulta.
El motor de respuesta (Answer Engine) es un componente del RSS. Éste contiene métodos
que toman como entrada las Onto-Triples, e infiere la respuesta adecuada para la consulta del
usuario.
3.2.2 INVENIO
El sistema INVENIO [VIVANCOS09] es un buscador semántico que permite realizar consultas en
Intranets donde se encuentra instalado el buscador de Google para Intranets (GSA). El sistema
INVENIO recibe la consulta del usuario y la transforma, creando una nueva consulta que obtendrá
Capítulo 3. Estado del arte
26
mejores resultados en GSA que la proporcionada por el usuario. Esta herramienta tiene una
ontología de dominio de los documentos indexados por el buscador GSA. De esta forma, cuando el
usuario escribe la consulta (palabras claves), INVENIO procesa esa consulta y obtiene qué
conceptos son los que le interesan al usuario, introduciendo además nuevos conceptos a partir de
heurísticas y de las relaciones existentes entre conceptos encontrados.
Una vez que se tienen los conceptos que conforman la búsqueda del usuario se
transforman nuevamente estos conceptos para lanzar la búsqueda en GSA, con la certeza de que
esas palabras aparecen en los documentos indexados (ver figura 3-2).
Figura 3-2. Vista general del funcionamiento de INVENIO
Durante la descripción de la herramienta INVENIO se mencionan las ventajas con las que
cuenta pero no es explícito respecto a pruebas realizadas en ambientes reales y no menciona
ningún resultado esperado.
3.2.3 PowerAqua
El sistema PowerAqua [LÓPEZ09] es una interfaz de lenguaje natural que acepta consultas del
usuario expresadas en común y devuelve una respuesta a partir de un recurso de la Web
semántica. La funcionalidad de acceso a distintos recursos semánticos online de la herramienta
PowerAqua, está dada por el uso de Watson Semantic Web Gateway [D’AQUIN07], la cual es una
herramienta que se encarga de recolectar, analizar e indexar ontologías y recursos semánticos
disponibles en la red.
Capítulo 3. Estado del arte
27
En la figura 3-3 se muestra una vista general de la arquitectura de de la herramienta
PowerAqua.
Figura 3-3. Arquitectura de PowerAqua
La herramienta PowerAqua recibe como entrada una consulta expresada en lenguaje
natural, el componente lingüístico (Linguistic Component) de PowerAqua analiza la consulta en
lenguaje natural, y la transforma en un conjunto de tripletas, llamadas tripletas de consulta (Query-
Triples ó QTs), mediante la identificación de las asociaciones de los términos relacionados.
Las tripletas de consulta generadas por el componente lingüístico se envían a PowerMap,
el cual identifica los recursos semánticos que pueden contestar a la consulta dada, y produce un
mapeo de elementos entre los términos las tripletas de consulta y las entidades en los recursos. La
salida de esto es un conjunto de tablas de mapeo de entidades (EMTs, Entity Mapping Tables).
El servicio de similaridad de tripletas (Triple Similarity Service ó TTS), recibe como entrada
las tablas de mapeo de entidades generadas por PowerMap y las tripletas de consulta, y regresa
un conjunto de tablas de mapeo de tripletas (TMTs, Triple Mapping Tables), las cuales especifican
un mapeo completo entre un las tripletas de consulta y tripletas de ontología (Ontology Triples)
apropiadas.
Finalmente, el componente “Merging and Ranking” genera la respuesta final devolviendo
tripletas generadas a partir de una ontología con base en la consulta expresada en lenguaje
natural.
Capítulo 3. Estado del arte
28
3.3 QAS basados en ontologías utilizando el lenguaj e de consulta SPARQL
Los artículos considerados en esta sección tienen la capacidad de recibir solicitudes en lenguaje
natural para consultar ontologías utilizando el lenguaje estándar de la W3C denominado SPARQL.
En la tabla 3-2 se resumen los aspectos antes mencionados para cada herramienta
analizada en esta sección
Tabla 3-2. Comparativa de los QAS basados en ontologías utilizando el lenguaje de consulta SPARQL
GUNQ [BHATIA06]
GINSENG [BERNSTEIN06]
QUERIX [KAUFMANN06]
NLP-REDUCE
[KAUFMANN07]
PANTO [WANG07]
QACID [FERRÁNDEZ08]
NLION [RAMACHANDRA09]
Lenguaje aceptado en la consulta
Palabras claves
Acotado Libre Libre Libre Acotado Libre
Análisis léxico/sintáctico Ninguna Ninguna
Stanford Parser Ninguna
Stanford Parser Ninguna Stanford Parser
Fen
ómen
o lin
güís
tico Elipsis No No No No menciona No menciona No No menciona
Genitivo sajón No No No No No No No
Técnica de análisis lingüístico Ninguna Ninguna
Identificación de patrones
Generación de lexicón
Identificación de
componentes lingüísticos
Emparejamiento difuso
Etiquetado de relaciones semánticas
Rep
rese
ntac
ión
inte
rmed
ia Tripletas No No No Si Si No Si
Consulta SPARQL Si Si Si Si Si Si Si
Dominio de aplicación
Abierto Abierto Abierto Abierto Abierto Acotado Abierto
A continuación se proporciona una descripción del funcionamiento de los trabajos
comparados en la tabla 3-2.
3.3.1 GuNQ
El sistema GuNQ [BHATIA06] es una herramienta basada en el motor para Web semántica que
permite a un usuario cargar una ontología de su elección y consultarla en una interfaz amigable
Capítulo 3. Estado del arte
29
donde la ontología es convertida en tripletas. Esta conversión, hace a la ontología equivalente a
un grafo dirigido.
Las tripletas inferidas desde el motor de consulta, visualizadas como un grafo RDF dirigido,
se representan como una matriz de adyacencia. En una consulta que contiene palabras claves, el
programa detecta los nodos en las palabras que el usuario ingresó en su consulta y se encuentran
las relaciones entre ellos. Una vez dadas las relaciones entre ellos se genera una consulta
equivalente en lenguaje RDQL o SPARQL, la cual en ambos casos debe devolver los mismos
resultados.
3.3.2 Ginseng
El sistema Ginseng [BERNSTEIN06] es una herramienta que permite realizar una consulta en
lenguaje natural restringido para tener acceso a una base de conocimiento OWL. La principal
diferencia entre Ginseng y las Interfaces en Lenguaje Natural es que Ginseng no usa un lenguaje
definido y realiza una interpretación lógica y sintáctica de la consulta. En vez de eso, Ginseng “sólo
conoce” el vocabulario definido en la ontología considerada.
Ginseng guía al usuario a través de un conjunto de posibles consultas mientras evita
preguntas fuera de la gramática conocida. Una vez introducida la consulta Ginseng la traduce a
una sintaxis SPARQL, la ejecuta sobre el modelo ontológico existente, y muestra la consulta
SPARQL generada y los resultados de la misma al usuario.
3.3.3 Querix
El sistema Querix [KAUFMMAN06] es una interfaz de lenguaje natural de dominio independiente
que usa diálogos de clarificación para realizar consultas sobre ontologías. El enfoque es simple y
no implementa técnicas de análisis lingüístico profundo, y en comparación con otros motores de
PLN, éste no trata de resolver las ambigüedades del lenguaje natural, pero responde a los usuarios
por medio de diálogos de clarificación.
El sistema consiste en siete partes principales: una interfaz de usuario, un administrador de
la ontología, un analizador de la consulta, centro de emparejamiento (matching center), un
generador de consultas, un componente de diálogo y una capa de acceso a la ontología.
Capítulo 3. Estado del arte
30
La interfaz de usuario, permite al usuario introducir la consulta en lenguaje natural y elegir
la ontología a consultar. El administrador de ontología mejora las etiquetas de los recursos
obteniendo sinónimos desde WordNet. El analizador de consultas emplea StanfordParser que
provee un árbol sintáctico para la consulta en lenguaje natural, desde el cual se extrae la
secuencia de las categorías gramaticales de las palabras como: sustantivo (Noun, N), verbo (Verb,
V), preposición (Preposition, P), pregunta (Wh-Word, Q), y conjunción (Conjunction, C). Estas
categorías se utilizan para la generación del patrón (“esqueleto”) de la consulta.
Después, el centro de emparejamiento busca todas las coincidencias entre los nombres y
verbos de la consulta en lenguaje natural y los componentes de la ontología. Cada posible
emparejamiento se almacena incluyendo el dominio y el rango de la información. El componente
de diálogo muestra al usuario un menú desde el cual puede elegir una consulta de sentido
semejante la que ingresó, y de esta manera, el sistema recupera la respuesta correcta. La capa de
acceso a la ontología usa Jena y el razonador Pellet para ejecutar la consulta SPARQL.
3.3.4 NLP-Reduce
El sistema NLP-Reduce [KAUFMANN07] es una interfaz de lenguaje natural de dominio
independiente para consultar bases de conocimiento para la Web semántica. El sistema consiste
de cinco partes principales: una interfaz de usuario (user interface), un lexicón (lexicon), un
procesador de consultas (input query processor), un generador de consultas SPARQL (SPARQL
query generator) y una capa de acceso a la ontología (ontology access layer).
El componente “interfaz de usuario” (user interface) permite introducir consultas en
lenguaje natural libre, fragmentos de sentencias o palabras claves. El componente “lexicón” se
construye automáticamente a partir de la extracción de todas las tripletas <sujeto-predicado-
objeto> explícitas o inferidas que existen en la base de conocimientos. Además, se obtienen los
sinónimos de las etiquetas de cada tripleta desde WordNet para obtener un vocabulario amplio que
se usa al consultar la ontología.
El componente “procesador de consultas” (input query processor) reduce la solicitud del
usuario quitando todas las marcas de puntuación. El componente “generador de consultas” (query
generator) trata de emparejar las palabras de la consulta y las tripletas almacenadas con los
sinónimos enlazados para generar las consultas SPARQL.
Capítulo 3. Estado del arte
31
La consulta SPARQL se ejecuta mediante el componente “capa de acceso a la ontología”
(ontology access layer) de la herramienta NLP-Reduce el cual usa Jena y el razonador de Pellet.
3.3.5 PANTO
El sistema PANTO [WANG07] es una interfaz de lenguaje natural que ofrece a los usuarios la
adquisición de la información necesaria desde una ontología determinada. Específicamente, los
usuarios solicitan la información necesaria en lenguaje natural incluso sin considerar la sintaxis
RDF u OWL, el lenguaje formal de consulta o el esquema y vocabularios de las ontologías.
Las 3 principales características de PANTO son:
• Diseño independiente de la ontología, y no cuenta con un conocimiento específico sobre un
dominio. La herramienta WordNet y algoritmos de métricas de cadenas (string metrics
algorithms) se integran para dar sentido a las palabras de la consulta en lenguaje natural y
mapearlas con las entidades (conceptos, instancias o relaciones) en la ontología.
• Considera los constituyentes de frases nominales en los árboles de parseo. Extrae las
frases nominales en los árboles de parseo para formar una representación intermedia
llamada QueryTriples, la herramienta PANTO mapea las QueryTriples a OntoTriples las
cuales representan las entidades en la ontología. Finalmente, las OntoTriples son
traducidas a una consulta en SPARQL (la arquitectura se muestra en la figura 3-4).
• Considera problemas, como sinonimia, en el proceso de traducción de consultas en
lenguaje natural a consultas en SPARQL. Además soporta características semánticas
avanzadas como la negación, comparación y modificadores superlativos.
Capítulo 3. Estado del arte
32
Figura 3-4. Arquitectura de la herramienta PANTO
3.3.6 QACID
El sistema QACID [FERRÁNDEZ08] es un sistema de preguntas y respuesta sobre el dominio del
cine. La estructura de QACID está desarrollada bajo cuatro componentes principales: la ontología,
los datos estructurados, la base de conocimiento de usuario y el módulo de implicación textual.
• La ontología. Se usa OWL para diseñar una ontología sobre el dominio turístico, las clases
y relaciones utilizadas por QACID pertenecen al subdominio del cine.
• Los datos. La ontología ha sido poblada con información sobre el dominio de cine,
almacenando los datos en formato RDF.
• Base de Conocimiento de Usuario. El conocimiento fue adquirido a partir de pruebas
realizadas con usuarios reales. Para esto, solicitaron a un grupo de personas que
demandaran datos sobre el dominio del cine, generando así un conjunto de preguntas
representativas del dominio. Después fueron analizadas y agrupadas automáticamente en
función de la información que solicitan, a cada agrupación se le asoció manualmente una
sentencia SPARQL
• Módulo de Implicación Textual. Este módulo implementa técnicas de implicación textual
con el objetivo de inferir deducciones semánticas entre preguntas de entrada y las
agrupaciones de la base de conocimiento de usuario previamente obtenidas. Este proceso
Capítulo 3. Estado del arte
33
permite asociar consultas SPARQL a las preguntas de entrada y así recuperar las
respuestas desde los datos RDF.
En la figura 3-5 se muestra la arquitectura general de QACID.
Figura 3-5. Arquitectura de la herramienta QACID
3.3.7 NLION
El sistema NLION [RAMACHANDRA09] es una interfaz de lenguaje natural que reconoce la
semántica superficial de la consulta del usuario por medio del método de etiquetado de relaciones
semánticas (Semantic Relation Tagging, SRT) y la traduce a SPARQL.
La arquitectura de NLION cuenta con diferentes componentes y relaciones entre ellos. La
secuencia clásica de acciones en NLION es la siguiente:
• El usuario ingresa una consulta en lenguaje natural al sistema.
• El sistema acepta la consulta, y aplica técnicas de expansión a ésta (Query Expansion,
QE).
Capítulo 3. Estado del arte
34
• La consulta resultante pasa al generador SPARQL. Éste transforma la consulta a
SPARQL. El resultado es procesado por un motor SPARQL y la salida será mostrada al
usuario (arquitectura figura 3-6).
Figura 3-6. Arquitectura de la herramienta NLION
3.4 Conclusiones y comparación con el trabajo de te sis
Durante el capítulo 3 del estado del arte se analizaron, descrito y comparado, distintos artículos de
investigación con base en las herramientas desarrolladas por cada uno.
Primeramente, se analizaron tres artículos que aplican procesamiento del lenguaje natural
a partir de preguntas formuladas por un usuario, y mediante técnicas de recuperación de
información devuelven una respuesta a partir de una ontología. Los aspectos más relevantes de la
comparación de estos trabajos son:
Capítulo 3. Estado del arte
35
• Los trabajos [LÓPEZ06], [VIVANCOS09] y [LÓPEZ09] coinciden al contar con la flexibilidad
de permitir al usuario introducir sus consultas en lenguaje natural libre, respetando las
reglas de formación de las preguntas en cada uno de los casos.
• Los trabajos de [LÓPEZ06] y [LÓPEZ09] utilizaron la herramienta GATE para realizar el
análisis léxico/sintáctico de la consulta del usuario en lenguaje natural, además de
implementar técnicas de categorización de consultas como mecanismo de análisis
lingüístico para trabajar en dominios abiertos.
La segunda parte del estado del arte, consiste en el análisis de siete artículos que a partir
de una consulta en lenguaje natural construyen una consulta en lenguaje SPARQL para consultar
una ontología definida. Los aspectos más relevantes de la comparación de estos trabajos son:
• El uso del de lenguaje natural libre predomina en 4 de los 7 trabajos analizados.
• Los trabajos [KAUFMMAN06], [WANG07] y [RAMACHANDRA09] utilizaron la herramienta
Stanford Parser para la tarea de análisis léxico/sintáctico, mientras que los artículos
restantes no consideran o no describen este proceso.
• Las técnicas de análisis lingüístico fueron diferentes para cada herramienta, a excepción
de los trabajos [BHATIA06] y [BERNSTEIN06] que no aplicaron.
• La representación intermedia de la consulta en los siete casos analizados coincidieron en
trasformar la consulta en lenguaje natural a una consulta en lenguaje SPARQL, y tan sólo
[KAUFMMAN07], [WANG07] y [RAMACHANDRA09] consideraron utilizar tripletas de
consulta como paso previo a la construcción de la consulta SPARQL.
Tomando en consideración estas conclusiones y los rasgos de evaluación, se construyó la
siguiente tabla (tabla 3-3) comparando las herramientas antes mencionadas con el prototipo
realizado en la presente tesis:
Capítulo 3. Estado del arte
36
Tabla 3-3. Comparativa de las artículos del estado del arte con el trabajo de tesis
Lenguaje
aceptado en la consulta
Análisis léxico/sintáctico
Fenómeno lingüístico Técnica de análisis
lingüístico
Representación intermedia
Dominio de aplicación Elipsis Genitivo
sajón Tripletas Consulta
SPARQL
PRIMERA SECCIÓN
AQUALOG
[LÓPEZ06] Libre GATE Si No Categorías Si Si Abierto
INVENIO [VIVANCOS09]
Libre Ninguna No No Ontología de dominio No No Acotado
POWERAQUA
[LÓPEZ09] Libre GATE Si No Categorías Si Si Abierto
SEGUNDA SECCIÓN
GUNQ [BHATIA06]
Palabras claves Ninguna No No Ninguna No Si Abierto
GINSENG
[BERNSTEIN06] Libre Ninguna No No Ninguna No Si Abierto
QUERIX [KAUFMANN06]
Libre Stanford Parser No No Identificación de patrones No Si Abierto
NLP-REDUCE
[KAUFMANN07] Libre Ninguna No No Generación de lexicón Si Si Abierto
PANTO
[WANG07] Libre Stanford Parser No
menciona No
Identificación de componentes lingüísticos
Si Si Abierto
QACID [FERRÁNDEZ08]
Acotado Ninguna No No Emparejamiento difuso No Si Acotado
NLION
[RAMACHANDRA09] Libre Stanford Parser
No menciona No
Etiquetado de relaciones semánticas Si Si Abierto
TESIS Libre Stanford Parser Si Si Identificación de patrones
Si Si Abierto
Capítulo 3. Estado del arte
37
Los resultados mostrados en la tabla 3-3, nos proporcionan una visión general de los
alcances y/o aportaciones que brinda el presente trabajo de tesis, a manera de conclusión final se
describen los siguientes puntos:
• Los QAS basados en ontologías analizados en el presente estado del arte al igual que en
este trabajo de tesis cuentan con la capacidad de recibir preguntas en lenguaje natural
libre, dependiendo la correcta estructura gramatical de la consulta.
• El análisis léxico/sintáctico de la consulta se realiza mediante la herramienta Stanford
Parser, debido a que es un desarrollo nativo para el idioma inglés y desarrollada en java,
por lo que proporciona facilidades de integración.
• Las herramientas analizadas consideran las oraciones conjuntivas pero ninguno menciona
las disyuntivas, además, ningún trabajo del estado del arte consideró el tratamiento del
genitivo sajón, por lo que estas características forman parte de la aportación del trabajo de
tesis.
• Las técnicas de identificación de patrones fueron diferentes en todos los casos del estado
del arte, para el trabajo de tesis se considera la técnica de identificación de patrones
implementada mediante expresiones regulares, la cual por su naturaleza facilita la
exportación a otros idiomas.
• Las técnicas de análisis lingüístico fueron diferentes en todos los casos, para el trabajo de
tesis se considera la técnica de identificación de patrones debido a las facilidades de
implementación mediante expresiones regulares y exportación a otros idiomas.
• El mecanismo de representación intermedia fue semejante en los trabajos analizados,
debido a los objetivos de la presente tesis se considera la generación de tripletas y
consulta SPARQL como dos módulos separados, y no como un proceso interno tal y como
se menciona en los artículos.
• El dominio de aplicación en la mayoría de los artículos del estado del arte fue abierto, el
presente trabajo de tesis considera, como parte de su aportación esta característica, con
la finalidad de no necesitar conocer la ontología para formar tripletas y consultas en
SPARQL.
El presente trabajo de investigación no pretende solucionar los problemas presentes en el
procesamiento del lenguaje natural, sino contribuir en el desarrollo de técnicas o nuevas
metodologías para abordarlos.
Capítulo 3. Estado del arte
38
Capítulo 4. Metodología de solución
39
Capítulo 4. Metodología de solución
En este capítulo se describe la metodología utilizada para solucionar el problema del presente
trabajo de tesis, la cual se divide en dos módulos el análisis lingüístico y la generación e
identificación de patrones. La metodología de solución considera desde el análisis de la consulta
de la entrada en lenguaje natural hasta le construcción de la consulta SPARQL, generando una
representación intermedia basada en tripletas considerando los fenómenos lingüísticos de la elipsis
y genitivo sajón.
Capítulo 4. Metodología de solución
40
4.1 Vista general de la arquitectura del trabajo de tesis
La herramienta ironLP, como ya se mencionó tiene la finalidad extraer la información solicitada a
partir de una consulta en lenguaje natural en idioma inglés desde un repositorio de ontologías.
La aportación principal del trabajo de tesis como parte del marco de trabajo del proyecto
ironLP, es construir tripletas y consultas en SPARQL a partir de una solicitud del usuario mediante
el reconocimiento de entidades y a diferencia de lo realizado en [WANG07] y [RAMACHANDRA09]
sin necesidad de acceder a una ontología.
La técnica empleada para la identificación de entidades y acciones dentro de la consulta es
la aplicación de expresiones regulares, estas expresiones operan sobre la consulta introducida por
el usuario para la identificación de su patrón correspondiente a partir del análisis léxico/sintáctico
del la herramienta Stanford Parser.
La técnica de identificación de patrones de consulta como base de los QAS que ocnsideran
ontologías fue utilizada con buenos resultados en [KAUFMMAN06], en el cual se buscaba dentro
de la ontología sub-secciones del patrón y mediante diálogos de clarificación le solicitaba al usuario
refinar su búsqueda. El trabajo de tesis no tiene el alcance de buscar en la ontología y resolver
fenómenos de ambigüedad debido a que esto es una tarea de un módulo diferente dentro del
proyecto ironLP. El presente trabajo de tesis no sólo genera un patrón de consulta también da
tratamiento a fenómenos característicos de la gramática inglesa como son: genitivo sajón (posesivo
‘s) y elipsis (información faltante), además de construir tripletas y consulta SPARQL a partir de la
solicitud del usuario.
La arquitectura de la herramienta desarrollada para el presente trabajo de tesis se muestra
en la figura 4-1:
Capítulo 4. Metodología de solución
41
Figura 4-1. Arquitectura de la herramienta de tesis
Durante los siguientes apartados se describen a detalle las actividades de cada uno de los
módulos que componente la arquitectura presentada.
4.2 Análisis lingüístico
El módulo de análisis lingüístico recibe como entrada la consulta en lenguaje natural del usuario, la
cual se analiza con la finalidad de detectar la presentación de los fenómenos lingüísticos de la
elipsis y casos genitivos.
4.2.1 Análisis léxico/sintáctico
El análisis léxico/sintáctico de la consulta del usuario consiste en la asignación de la categoría
gramatical a cada componente lingüístico (palabra) que conforman a la misma. La herramienta
Stanford Parser es la encargada de realizar este proceso.
Capítulo 4. Metodología de solución
42
Considerando la consulta mostrada en la tabla 4-1:
Tabla 4-1. Ejemplo de consulta en lenguaje natural
Which Azucena's students are working on ontologies and are generating ontologies of CENIDET?
La herramienta Stanford Parser toma como entrada la consulta anterior y generar su árbol
sintáctico correspondiente, el cual se puede observar en la figura 4-2.
Figura 4-2. Árbol sintáctico generado por Stanford Parser
A partir del árbol sintáctico de la figura 4-2 se extraen la categoría gramatical así como
cada una de las palabras de la consulta en lenguaje natural analizada por Stanford Parser,
generando una lista de cada una de ellas la cual es base para la generación del patrón de
consulta, la figura 4-3 muestra el resultado de esta actividad.
Capítulo 4. Metodología de solución
43
Figura 4-3. Palabras y categorías gramaticales de la consulta del usuario
Hasta este paso se concluye la actividad de análisis léxico/sintáctico de la consulta de la
tabla 4-1, a partir de este momento se procede a la identificación del patrón de consulta
correspondiente para la detección de fenómenos lingüísticos y su tratamiento.
4.2.2 Identificación de fenómenos lingüísticos
La identificación de fenómenos lingüísticos consiste en la detección de ciertas sintaxis propias de
la gramática que pueden resultar complejas al momento de analizar la consulta, considerando el
tratamiento de los fenómenos lingüísticos del genitivo sajón y elipsis.
Para la detección de estos fenómenos es necesario generar un primer patrón de la
consulta del usuario, a partir del etiquetado realizado por Stanford Parser. Para cada etiqueta
corresponde un símbolo representativo (una letra) con base a la siguiente tabla:
Capítulo 4. Metodología de solución
44
Tabla 4-2. Correspondencia entre las categorías gramaticales y el valor asignado
Categoría(s) gramatical(es) Valor asignado (letra)
WP, WDT Q
NN, NNP, NNPS, NNS N
VB, VBD, VBG, VBN, VBP,
VBZ
V
JJ, JJR, JJS A
IN P|F*
TO T
DT D
CC C
POS O
* Sólo casos genitivos
Las categorías gramaticales, como se mencionó en el capítulo 2, corresponden a las
propuestas por el [PTP10] (ver anexo A). El patrón generado a partir de la consulta de la tabla 4-1
considerando la tabla 4-2 se muestra en la figura 4-4:
Figura 4-4. Generación de patrón con fenómenos lingüísticos
Los fenómenos lingüísticos que se consideran en el presente trabajo de investigación son:
el genitivo sajón y la elipsis.
4.2.2.1 Genitivo sajón
El genitivo sajón, como se explicó en el capítulo 2, indica posesión o pertenencia de algo siempre y
cuando el poseedor sea un objeto viviente. En este trabajo de investigación suponemos que el
usuario podrá utilizar la estructura cuando lo crea conveniente, por lo que no se profundiza en
Capítulo 4. Metodología de solución
45
determinar si la consulta es semánticamente correcta, pero si se tiene la capacidad de transformar
la expresión a otra más simple mediante una preposición de pertenencia, en este caso of.
Considerando la pregunta del usuario (tabla 4-1) y el patrón generado en la figura 4-4, se
busca dentro de éste la aparición del carácter “O”, el cual como se mostró en la tabla 4-2 es el
valor asignado a la etiqueta POS devuelta por Stanford Parser para identificar un caso posesivo.
El tratamiento a los casos genitivos considera la aparición de este fenómeno sólo una vez
dentro de la consulta del usuario, es decir, consultas que contengan casos genitivos como
“Azucena’s students’ thesis” no están consideradas.
El tratamiento del caso genitivo para la pregunta del usuario se muestra en la figura 4-5:
Figura 4-5. Tratamiento del caso genitivo y reformulación de consulta
El tratamiento del caso genitivo implica la reformulación de la consulta del usuario, además
de generar el nuevo patrón reducido de la consulta (tabla 4-1). A manera de regla general el
tratamiento del caso genitivo se expresa de manera formal en el algoritmo mostrado en la
tabla 4-3:
Capítulo 4. Metodología de solución
46
Tabla 4-3. Algoritmo para la identificación y tratamiento de casos genitivo
Sea P el patrón reducido generado a partir de cada componente lingüístico en la consulta del
usuario y x el valor de cada elemento que integra a P, de tal forma que ¬(∃x ∉ P), entonces:
Para cada x ∈ P hacer
Si (∃x | xi ⇒ “O”) ⇒ (∃x | xi-1 ∧ ∃x | xi+1 ⇒ “N”) entonces
Mientras ∃x | xi-1 ⇒ “N” crear Ai ← ∃x | xi-1 ⇒ “N”
Mientras ∃x | xi+1 ⇒ “N” crear Ad ← ∃x | xi+1 ⇒ “N”
Fin_Si
Fin_Para
Identificar y sustituir [ (Ai ∪ “O” ∪ Ad) ⊂ P ] ← (Ad ∪ “F” ∪ Ai)
4.2.2.2 La elipsis
La elipsis se hace presente comúnmente en el lenguaje natural debido al fenómeno de la
economía de palabras. En el presente trabajo de tesis, se considera la elipsis que proviene de
conjunciones coordinantes, según [SÁNCHEZ07] existen tres tipos: copulativas, disyuntivas y
adversativas, de las cuales sólo se consideran las dos primeras.
El tratamiento de la elipsis en el presente trabajo implica la división del patrón generado a
partir de la consulta del usuario por cada conjunción coordinante, es importante que el genitivo
sajón (en caso de haberlo) haya sido resuelto antes de tratar este fenómeno. La figura 4-6
muestra los dos patrones que son generados a partir de la consulta del usuario:
Capítulo 4. Metodología de solución
47
Figura 4-6. Generación de sub-patrones unidos por conjunciones coordinantes
Realizada la división del patrón en subpatrones, el primero de ellos se toma como base
para analizar y complementar cada uno de los subpatrones adyacentes mediante la adición o
concatenación de la información elidida en la consulta en lenguaje natural.
Se considera que el primer subpatrón (llamado subpatrón i) contiene la información
necesaria para completar los subpatrones adyacentes (llamados subpatrón i+1) y formular
consultas simples a partir de la solicitud del usuario en lenguaje natural, los datos que serán
agregados a cada subpatrón a partir del primero dependen de la información con la que cuentan, la
tabla 4-4 resume los elementos esperados al principio de cada subpatrón (subpatrón i+1):
Capítulo 4. Metodología de solución
48
Tabla 4-4. Componentes lingüísticos presentes al comienzo de un subpatrón
COMPONENTE
LINGÜÍSTICO
EJEMPLO DESCRIPCIÓN
Preposición Which researchers are working in CENIDET
and on ontologies?
La preposición define o califica el tipo de
objeto sobre el cual está actuando, por lo
que resulta importante considerarla como
primer componente después de una
conjunción coordinada.
Determinante Which researchers are working in CENIDET
and the Semantic Web?
El determinante sirve para definir el
objeto sobre del cual se dice algo, en
muchas ocasiones el determinante the se
omite por regla general de la gramática.
Nombre Which researchers are working on ontologies
and networks?
El nombre después de una conjunción
coordinada indica que realiza la misma
acción que el objeto del primer subpatrón.
Verbo Which researchers are interested on Semantic
Web and are working in CENIDET?
El verbo después de una conjunción
coordinada indica que el objeto realiza
una acción distinta al objeto del primer
subpatrón.
Los ejemplos mostrados en la tabla 4-4 tienen una característica en común, todos ellos nos
indican el sujeto del cual se está preguntando. El presente trabajo de tesis considera este tipo de
preguntas para conocer la posible respuesta que el usuario espera obtener, pero además,
considera el caso especial de preguntas con Who, en la cual el sujeto en cuestión se encuentra
definido de forma implícita.
La identificación de los componentes lingüísticos en los subpatrones (subpatrones i+1) se
basa en expresiones regulares con la finalidad de identificar la información que debe ser extraída
del subpatrón i para reformular la consulta original en consultas simples. La tabla 4-5 resume las
expresiones regulares que se evalúan con la intención de formular las consultas simples:
Capítulo 4. Metodología de solución
49
Tabla 4-5. Resumen de expresiones regulares para la reformulación de consultas con elipsis
Expresión regular para el subpatrón i+1
Elementos identificados
Ejemplo Expresión regular para el subpatrón i
Elementos extraídos
Ejemplo Reformulación de consulta
Caso 1
^([P]{0,1}[D]{0,1}[A]*[N]+)
Preposición
Determinante
Adjetivo
Nombre
Which researchers are working in CENIDET and on ontologies ?
^([Q|V]{0,1}A*N*F*N*V*)
Palabra de pregunta o verbo auxiliar
Adjetivo
Caso genitivo o nombre
Verbo
Which researchers are working in CENIDET and on ontologies?
Which researchers are working in CENIDET
and
Which researchers are working on ontologies?
Which researchers are working on ontologies and the Semantic Web ?
^([Q|V]{0,1}A*N*F*N*V*P)
Palabra de pregunta o verbo auxiliar
Adjetivo
Caso genitivo o nombre
Verbo
Preposición
Which researchers are working on ontologies and the Semantic Web?
Which researchers are working on ontologies
and
Which researchers are working on the Semantic Web?
Caso 2
^((V)+(A){0,1}(P|T){0,1})
Verbo
Adjetivo
Preposición
Which researchers have a phD degree and are working on Semantic Web?
^([Q|V]{0,1}A*N*F*N*) Palabra de pregunta o verbo auxiliar
Adjetivo
Caso genitivo o nombre
Which researchers have a phD degree and are working on Semantic Web?
Which researchers have a phD degree
and
Which researchers are working on Semantic Web?
Who have a phD degree and are working on Semantic Web?
^(Q) Palabra de pregunta
Who have a phD degree and are working on Semantic Web?
Who have a phD degree
and
Who are working on Semantic Web?
Capítulo 4. Metodología de solución
50
La tabla 4-5 proporciona una visión general de la aplicación de las expresiones regulares
para el tratamiento del fenómeno de la elipsis, partiendo de dos casos: 1) considerando los
subpatrones i+1 que comienzan con una preposición, determinante, adjetivo o nombre; y 2)
considerando los subpatrones i+1 que comiencen con un verbo.
El proceso de análisis y tratamiento del fenómeno de la elipsis para el primer caso se
enuncia de manera formal en el siguiente algoritmo:
Tabla 4-6. Algoritmo para la identificación y tratamiento de la elipsis (caso 1)
Sea i el índice de cada uno de los subpatrones Qi generados de la consulta del usuario
comenzando por 1, de tal forma que Qi ∪ Qi+1 ∪ Qi+2 ∪ … Qn corresponden a la consulta original
(Q) del usuario. Sean R1, R2 y R3 expresiones regulares definidas como
(^([P]{0,1}[D]{0,1}[A]*[N]+)), (^([Q|V]{0,1}A*N*F*N*V*)) y (^([Q|V]{0,1}A*N*F*N*V*P))
respectivamente, que representan un conjunto infinito de patrones con índice k. Entonces:
Desde i+1 hasta n hacer
Si ∃k | R1k ⊂ Qi entonces
Si ‘P’ ∈ Qi entonces
Q ← Q1 ∪ ‘C’ ∪ {∃x | R2x ⊂ Q1} ∪ Qi
Sino
Q ← Q1 ∪ ‘C’ ∪ {∃x | R3x ⊂ Q1} ∪ Qi
Fin_Si
Fin_Sin
Fin_Desde
El proceso de análisis y tratamiento del fenómeno de la elipsis para el segundo caso se
enuncia de manera formal en el algoritmo de la tabla 4-7:
Capítulo 4. Metodología de solución
51
Tabla 4-7. Algoritmo para la identificación y tratamiento de la elipsis (caso 2)
Sea i el índice de cada uno de los subpatrones Qi generados de la consulta del usuario
comenzando por 1, de tal forma que Qi ∪ Qi+1 ∪ Qi+2 ∪ … Qn corresponden a la consulta original
(Q) del usuario. Sean R1, R2 y R3 expresiones regulares definidas como
(^((V)+(A){0,1}(P|T){0,1})), (^([Q|V]{0,1}A*N*F*N*)) y (^(Q)) respectivamente, que representan un
conjunto infinito de patrones con índice k. Entonces:
Desde i+1 hasta n hacer
Si ∃k | R1k ⊂ Qi entonces
Si (‘Q’ ∈ Qi) ∧ [parteDe(“Who”, Q)] entonces
Q ← Q1 ∪ ‘C’ ∪ {∃x | R3x ⊂ Q1} ∪ Qi
Sino
Q ← Q1 ∪ ‘C’ ∪ {∃x | R2x ⊂ Q1} ∪ Qi
Fin_Si
Fin_Sin
Fin_Desde
4.2.3 Reformulación de la consulta
El proceso de reformulación de la consulta tiene la finalidad de ensamblar la consulta en lenguaje
natural (tabla 4-1) para obtener dos o más estructuras gramaticales completas, considerando los
cambios efectuados después del tratamiento de los fenómenos lingüísticos (en caso de ser
necesario).
La nueva consulta obtenida de éste proceso se analiza nuevamente con la finalidad
generar un patrón de consulta completo a partir de cual se extraen las tripletas y consulta en
SPARQL.
Un ejemplo de este proceso se observa en la figura 4-7, considerando el ejemplo (tabla 4-
1) que se ha venido desarrollando:
Capítulo 4. Metodología de solución
52
Figura 4-7. Reformulación de la consulta del usuario
4.3 Generación e identificación de patrones
El módulo de generación e identificación de patrones es el encargado de detectar, mediante el uso
de expresiones regulares, las entidades que construyen la tripleta <sujeto, predicado, objeto>, la
cual es la base para la formación de la consulta SPARQL.
4.3.1 Generación del patrón de consulta
La generación del patrón de la consulta recibe como entrada la consulta reconstruida y la
transforma en una secuencia de valores (patrón) para ser analizados, como se observa en la
sección sombreada de la figura 4-7. Una vez generado el patrón se procede a analizarlo para la
identificación de entidades (nombres) y acciones (verbos).
Capítulo 4. Metodología de solución
53
La identificación de nombres y acciones se basa en la búsqueda de subpatrones que
coincidan con ciertas reglas, estas reglas se encuentran constituidas por tres componentes
principales: nombres, preposición y verbos. Las expresiones regulares que representan estos
componentes gramaticales se muestran en la tabla 4-8:
Tabla 4-8. Categorías de expresiones regulares
Categoría Expresión regular Descripción
Noun [D]{0,1}[A]*[N]+ Identifica la formación de nombres que
pueden comenzar con cero o un
determinante seguido de cero o muchos
adjetivos y de al menos un nombre.
Preposition [P|F]+ Identifica las preposiciones, las que son
etiquetadas como P son aquellas
identificadas desde el primer análisis de la
consulta, mientras que las etiquetadas
como F se generan cuando se resuelve
un caso genitivo.
Verb (V)+(A|P|T){0,1} Identifica la existencia de al menos un
verbo, el cual puede ir precedido por un
adjetivo adverbial, o preposición con cero
o una ocurrencia.
4.3.2 Generación de tripletas de consulta
La generación de tripletas de consulta consiste en el análisis del patrón generado, con la finalidad
de detectar los elementos que conformarán el sujeto, predicado y objeto de la misma, para esto, se
considera el uso de las categorías descritas en la tabla 4-8.
Durante este proceso se considera que la consulta del usuario no presenta los fenómenos
lingüísticos del genitivo sajón o elipsis (no presentaba o fueron resueltos), por lo tanto, la consulta
actual podría presentarse de dos maneras: como una consulta simple o como una consulta
compuesta que consta de dos o más consultas simples unidas por una conjunción.
Los patrones buscados en la consulta del usuario se resumen en la tabla 4-9:
Capítulo 4. Metodología de solución
54
Tabla 4-9. Patrones para la generación de tripletas
Patrón Descripción Ejemplo Tripleta generada
[Q] + Noun Patrón que permite identificar el sujeto
por el que el usuario pregunta,
considerando sólo los casos en los que el
what o which van seguidos por el mismo.
- Which students are from
Veracruz?
[ students? , is-a , students ]
[Q] + Verb + Noun Patrón que permite identificar el sujeto
por el que el usuario pregunta,
considerando que la consulta cuenta con
un verbo auxiliar después de palabra de
consulta.
- Who is working in CENIDET? [ Unknown ?, is-a , Person ]
Noun + Prepos ition + Noun Patrón que identifica la existencia de una
relación desconocida entre dos nombres,
la cual se encuentra implícita en la
preposición que los une.
- Which researchers in CENIDET
are living in Cuernavaca?
[ researchers , Unknown, CENIDET ]
Noun + Preposition + Noun +
Verb + Noun
Patrón que identifica un caso especial de
consultas en las que se encuentra
presente un caso genitivo, en donde la
acción realizada por el verbo y el objeto
afectado es ejecutada por el nombre que
antecede a la preposición y no al que
antecede al verbo.
- Which researchers in CENIDET
are living in Cuernavaca?
[ researchers , are living in ,
Cuernavaca ]
Noun + Verb + Noun Patrón ejecutado después del anterior,
debido a que identifica una acción simple
de dos objetos o sujetos realizando una
actividad.
- Which students are working on
ontologies?
[ students , are working on ,
ontologies ]
Capítulo 4. Metodología de solución
55
Los patrones mostrados en la tabla 4-8 permiten extraer las tripletas a partir de los valores
del patrón de la consulta, en donde cada subpatrón de consulta es mapeado con las palabras
correspondientes a la solicitud del usuario en lenguaje natural.
El proceso para la generación de las tripletas de consulta después de que se trataron los
fenómenos lingüísticos es la identificación de patrones mediante expresiones regulares,
considerando la consulta de la tabla 4-1, la identificación de patrones se realiza en el orden
mostrado en la tabla 4-10:
Tabla 4-10. Ejemplo de generación de tripletas
Patrón aplicado Elementos afectados Tripleta generada
[Q] + Noun QN FNVVPNC QN FNVVNPN [ students ? , is-a , students ]
[ students ? , is-a , students ]
Noun + Preposition + Noun Q NFN VVPNCQ NFN VV NPN [ students , Unknown ,
Azucena ]
[ students , Unknown ,
Azucena]
[ ontologies , Unknown ,
CENIDET ]
Noun + Preposition + Noun +
Verb + Noun
Q NFNVVPN CQ NFNVVN PN
[ students , are working on ,
ontologies ]
[ students , are generating ,
ontologies ]
Por lo tanto, después del análisis se obtienen las tripletas que corresponden a la unión de
todas las tripletas detectadas a partir de la aplicación de las expresiones regulares para la
identificación de patrones. Las tripletas generadas para el ejemplo de la tabla 4-10 se muestran en
la tabla 4-11:
Tabla 4-11. Ejemplo de tripletas generadas
[ students ? , is-a , students ]
[ students ? , is-a , students ]
[ students , Unknown , Azucena ]
[ students , Unknown , Azucena]
[ ontologies , Unknown , CENIDET ]
[ students , are working on , ontologies ]
[ students , are generating , ontologies ]
Capítulo 4. Metodología de solución
56
Las tripletas generadas pueden encontrarse más de una vez por consecuencia del
tratamiento del fenómeno de la elipsis, cada tripleta repetida es importante debido a que indica su
posición dentro de la consulta reconstruida del usuario, la cual como se mencionó, puede ser la
unión de consultas simples.
4.3.3 Generación de consulta en SPARQL
El módulo para la generación de la consulta en SPARQL tiene por objetivo representar las tripletas
formadas a partir de la consulta en lenguaje natural del usuario, en una secuencia de sentencias
que conformaran la consulta en SPARQL.
Se considera la construcción de dos tipos de consultas en SPARQL dependiendo de la
forma de la solicitud del usuario, estas son: SELECT y ASK. La consulta en SPARQL tendrá
definidos tres prefijos, cuyos valores (URI’s) se generan de forma automática cuando se crean
ontologías desde un editor, estos prefijos son: rdf, rdfs y owl.
4.3.3.1 Consultas SELECT
La consulta de selección se caracteriza por devolver un valor como resultado, este valor depende
de las variables de las que se solicita información. En el presente trabajo de tesis la variable que
acompañará a la cláusula SELECT se representa con el símbolo de interrogación (?) dentro de las
tripletas.
El presente trabajo cuenta con una plantilla establecida de una consulta en SPARQL, y en
ésta se agregan las tripletas generadas a partir de la consulta del usuario. La figura 4-8 muestra la
plantilla utilizada para este tipo de consultas:
Capítulo 4. Metodología de solución
57
Figura 4-8. Plantilla de consulta SPARQL de tipo SELECT
En donde:
(a) Dato solicitado por el usuario. El valor se extrae a partir de las tripletas de consulta y es la
variable acompañada por el signo de interrogación, considerando las tripletas del ejemplo
de la tabla 4-9, el valor buscado es: stundents ?.
(b) Condiciones. Las condiciones que se incluyen en este espacio son todas las tripletas
generadas a partir de la consulta del usuario sin considerar el orden o repetición de las
mismas, debido a que el resultado no se ve afectado. Sin embargo, cuando la consulta del
usuario contiene una o más oraciones coordinadas disyuntivas el orden de las tripletas se
convierte en un factor importante, debido a que este tipo de oraciones genera una cláusula
OPTIONAL la cual encierra bloques de tripletas generadas a partir de la segunda consulta
simple. La figura 4-9 muestra una plantilla de consulta SPARQL selectiva generada a partir
de una consulta coordinada disyuntiva, en la cual se hace presente la cláusula OPTIONAL:
Capítulo 4. Metodología de solución
58
Figura 4-9. Plantilla de consulta SPARQL selectiva con cláusula OPTIONAL
4.3.3.2 Consultas ASK
Las consultas de este tipo se caracterizan por no tener un valor de búsqueda, más bien, comparan
la existencia de una o más tripletas dentro de una ontología, el resultado de este tipo de consultas
sólo es: yes, no.
Este tipo de consulta será construido a partir de preguntas del usuario que carezcan de
una Wh-question, y en su lugar tengan un verbo auxiliar. Al igual que las consultas selectivas, las
consultas de tipo ASK cuentan con una plantilla definida en la cual se agregan las tripletas. La
figura 4-10 muestra la plantilla de este tipo de consultas:
Capítulo 4. Metodología de solución
59
Figura 4-10. Plantilla de consulta SPARQL de tipo ASK
En donde:
(a) Condición. La condición o condiciones que se van a agregar, son representadas por el
conjunto de tripletas generadas a partir de la consulta del usuario, sin que importe el orden
o las repeticiones de las mismas.
4.3.3.3 Construcción de consulta en SPARQL
La construcción de la consulta en SPARQL se basa en la identificación de la plantilla
correspondiente a la consulta en lenguaje natural. El proceso para definir la plantilla que se utilizará
se basa en análisis del primer componente (letra) del patrón de la consulta del usuario.
Con base en el proceso de identificación y generación del patrón de consulta, éste sólo se
compone por cualquiera de los dos siguientes elementos:
• Letra “Q”, para indicar que la consulta del usuario requiere una respuesta (valor) que
será tomado a partir de una ontología, por lo tanto se construye una consulta de tipo
SELECT.
• Letra “V”, para indicar que la consulta del usuario requiere conocer si cierta información
se encuentra contenida en una ontología, por lo tanto se construye una consulta de
tipo ASK.
Considerando el análisis de la consulta en lenguaje natural de la tabla 4-1, la cual generó
las tripletas de la tabla 4-11, se determina que el tipo de consulta en SPARQL corresponde a la
plantilla de tipo SELECT (figura 4-8), por lo tanto la consulta generada se muestra en la tabla 4-12:
Capítulo 4. Metodología de solución
60
Tabla 4-12. Consulta construida en SPARQL
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
SELECT DISTINCT students ?
WHERE {
students ? , is-a , students
students , Unknown , Azucena
students , Unknown , Azucena
ontologies , Unknown , CENIDET
students , are working on , ontologies
students , are generating , ontologies
}
La consulta en SPARQL de la tabla 4-12 muestra un par de tripletas repetidas: <students,
Unknown, Azucena>, lo cual es consecuencia del tratamiento lingüístico de la consulta en lenguaje
natural pero no altera el resultado esperado por el usuario.
El proceso de traducción de consultas en lenguaje natural a consultas en SPARQL que
implementan las plantillas de las figuras 4-9 y 4-10 se muestra en el siguiente capítulo.
Capítulo 5. Pruebas
61
Capítulo 5. Pruebas
En este capítulo se presentan las pruebas realizadas en base al estándar IEEE 829-1998. Se
presenta inicialmente la hipótesis a comprobar, la convención de nombres, el plan de pruebas
desarrollado, los resultados y conclusiones de la ejecución de las mismas.
Capítulo 5. Pruebas
62
5.1 Hipótesis
Una consulta en lenguaje natural aporta suficiente información para ser representada en estructura
de tripletas y en una consulta en lenguaje SPARQL, considerando sólo sus componentes
gramaticales.
5.2 Convención de nombres
La convención de nombres que se utiliza para evaluar la funcionalidad de la herramienta
desarrollada para el presente trabajo de tesis se describe a continuación:
ironLP
i � Information
r � Retrieval
o � Ontology
n � Natural
L � Language
P � Processing
Anexo a esta nomenclatura se encontrará la expresión “(tLp)”, con la intención de indicar
que la prueba representa parte de la funcionalidad de ironLP, exactamente en los módulos de:
tratamiento del lenguaje e identificación patrones.
5.3 Plan de pruebas
5.3.1 Introducción
El presente plan de pruebas está basado en el estándar IEEE 829-1998 para pruebas de software,
con la cual se puede verificar la funcionalidad de la herramienta en desarrollo.
Capítulo 5. Pruebas
63
Las pruebas de funcionalidad se realizaron para la reconstrucción de la consulta
considerando los fenómenos lingüísticos de la elipsis y casos genitivos, la construcción de tripletas
a partir de la consulta en lenguaje natural, y generación de una consulta en lenguaje SPARQL.
Este plan de pruebas contiene los siguientes puntos: elementos de prueba, características
probadas, enfoque, criterio de éxito/fracaso de los casos de prueba, criterio de suspensión y
requisitos de reanudación, tareas de pruebas, liberación de pruebas, requisitos ambientales,
responsabilidades, riegos y contingencias, procedimiento de pruebas y resultados obtenidos.
5.3.2 Elementos de prueba
Los casos de prueba tienen como fin validar y verificar que la construcción de tripletas y consulta
en SPARQL se realiza de forma satisfactoria, considerando que las preguntas están
sintácticamente correctamente.
Durante las pruebas se considera analizar preguntas que contengan fenómenos
lingüísticos, reconstruir las consultas, y a partir de esa actividad generar las tripletas de éstas con
el propósito de obtener su correspondencia en SPARQL.
5.3.3 Características probadas
Las características probadas se enlistan a continuación:
• Generación del patrón de consulta. Se analizó que los valores del patrón generado
corresponda a todas y cada una de las unidades léxicas de la consulta del usuario.
• Tratamiento del problema de la elipsis. Se revisó que la herramienta pueda detectar el
fenómeno de la elipsis y complementar la consulta original con la información faltante.
• Tratamiento de casos genitivos. Se verificó que la herramienta pueda detectar el fenómeno
del genitivo sajón y transforme los elementos que entran en juego a una sentencia de
pertenencia mediante una preposición.
• Construcción de tripletas. Se mostró que las tripletas generadas después del
procesamiento del la consulta correspondan en sentido y forma a lo solicitado en la
consulta del usuario.
Capítulo 5. Pruebas
64
• Construcción de consulta SPARQL. Se analizó que la estructura de la consulta en
SPARQL construida represente la consulta original del usuario en lenguaje natural.
5.3.4 Características excluidas de las pruebas
Las siguientes características no forman parte del criterio de evaluación:
• El diseño de la interfaz de usuario.
• El funcionamiento del analizador Stanford Parser.
• La introducción de consultas diferentes a los criterios establecidos.
• El uso de versiones de software distintas a las que serán establecidas dentro de los
requisitos ambientales.
5.3.5 Pruebas realizadas
Las pruebas realizadas se clasifican en cuatro categorías, las cuales se enlistan a continuación:
Categoría 1. Prueba para la generación del patrón reducido a partir de la asignación de
valores a las etiquetas devueltas por Stanford Parser.
1. ironLP-01-01 (tLp). Generación del patrón reducido de la consulta.
Categoría 2. Pruebas para la identificaron y tratamiento de los fenómenos lingüísticos
considerados en el presente trabajo.
1. ironLP-02-01 (tLp). Identificación del caso genitivo.
2. ironLP-02-02 (tLp). Tratamiento del caso genitivo.
3. ironLP-02-03 (tLp). Identificación del fenómeno lingüístico de la elipsis.
4. ironLP-02-04 (tLp). Tratamiento del fenómeno lingüístico de la elipsis.
Capítulo 5. Pruebas
65
Categoría 3. Pruebas para la identificación y generación de tripletas en la consulta del
usuario en lenguaje natural.
1. ironLP-03-01 (tLp). Generación de tripletas de preguntas simples.
2. ironLP-03-02 (tLp). Generación de tripletas de preguntas con caso genitivo.
3. ironLP-03-03 (tLp). Generación de tripletas de preguntas con elipsis.
4. ironLP-03-04 (tLp). Generación de tripletas de preguntas con caso genitivo y elipsis.
5. ironLP-03-05 (tLp). Generación de tripletas de preguntas Who.
Categoría 4. Pruebas para la generación de la consulta en SPARQL a partir de la solicitud
del usuario.
1. ironLP-04-01 (tLp). Generación de consulta SPARQL a partir de una consulta simple.
2. ironLP-04-02 (tLp). Generación de consulta SPARQL a partir de consulta disyuntiva.
3. ironLP-04-03 (tLp). Generación de consulta SPARQL de tipo ASK.
5.3.6 Enfoque
Las pruebas realizadas tienen la finalidad de probar la herramienta y la buena interpretación y
representación de la información contenida en la consulta del usuario, esto no supone que las
estructuras generadas puedan consultar una ontología de manera directa, sino que se encuentren
totalmente representadas para ello, para lograr eso es necesario implementar técnicas de
alineamiento que no fueron objetivo del presente trabajo.
5.3.7 Criterios de éxito/fracaso de los casos de pr ueba
La decisión de éxito o fracaso para cada uno de los casos de prueba descritos en el presente
documento, se basa en la comparación de los resultados esperados contra los resultados
obtenidos.
Capítulo 5. Pruebas
66
Se considera que una prueba ha pasado con éxito cuando los resultados obtenidos
coincidan o sean semejantes a los resultados esperados descritos para cada uno de los casos de
prueba.
Se considera que una prueba no resultó con éxito, si al momento de comparar los
resultados obtenidos contra los esperados son diferentes, por lo que se analizan las causas y se
realizan las modificaciones necesarias hasta obtener los resultados esperados.
5.3.8 Tareas de prueba
Las tareas desarrolladas para ejecutar las pruebas de este plan se describen en la tabla 5-1 a
continuación:
Tabla 5-1. Descripción de las tareas de prueba
Tarea Tarea
precedente
Habilidades Responsabilidad
1. Planificación de
la pruebas
Evaluación de
métodos de
solución.
Conocimiento del estándar IEEE 829
y del funcionamiento y alcances de la
herramienta.
Autor del reporte
2. Diseño de
pruebas
Tarea 1 Conocimiento de los objetivos de esta
tesis, así como de los módulos de la
herramienta ironLP.
Autor del reporte
3. Ejecución de
pruebas
Tarea 2 Conocimiento del funcionamiento del
prototipo desarrollado.
Autor del reporte
4. Depuración de
errores
Tarea 3 Conocimiento de:
• Lenguaje de programación
Java.
• Ambiente de desarrollo
integrado.
Autor del reporte
5. Evaluación de
resultados
Tarea 2 y 3 Conocimiento de los objetivos,
alcances, limitaciones e hipótesis del
trabajo de tesis.
Autor del reporte
Capítulo 5. Pruebas
67
5.3.9 Liberación de pruebas
La liberación de las pruebas se basa en la comparación de los resultados obtenidos contra los
esperados, si ambos coinciden se toma como objetivo de prueba alcanzado y por lo tanto el plan
de prueba es aceptado.
5.3.10 Requisitos ambientales
La tabla 5-2 describe las características de hardware y software del ambiente de prueba:
Tabla 5-2. Características de hardware y software
Hardware Software
• Laptop Compaq Presario F700
• Procesador Sempron 3600+ a 2.00
Ghz
• 120 GB de capacidad en disco duro
• 2.5 MB de RAM
• Sistema operativo Windows Vista
Ultimate
• Ambiente de desarrollo integrado
NetBeans 6.8
• JDK 1.6
• Librería de Stanford Parser revisión
26/10/2008
5.3.11 Responsabilidades
La responsabilidad de realizar las pruebas que se especifican en este plan es del autor del reporte,
Ing. Carlos Martín Vázquez Vásquez. El cual se encargó de ejecutar todas las pruebas, depurar los
fallos y comparar los resultados obtenidos contra los resultados esperados.
5.3.12 Aprobación
El plan de pruebas fue aprobado por la directora de tesis, Dra. Azucena Montes Rendón, y
evaluado por los revisores Dra. Alicia Martínez Rebollar, Dr. Juan Gabriel González Serna y el
MCC. José Alejandro Reyes Ortiz.
Capítulo 5. Pruebas
68
5.4 Especificación de los casos de prueba
Las pruebas realizadas se clasifican en cuatro categorías, las cuales se enlistan a continuación:
Categoría 1. Prueba para la generación del patrón reducido a partir de la asignación de valores a
las etiquetas devueltas por Stanford Parser.
1. ironLP-01-01 (tLp). Generación del patrón reduci do de la consulta.
a) Propósito
Generar el patrón reducido de la consulta en lenguaje natural del usuario, mediante el
uso de los valores que representan a las categorías gramaticales (tabla 4-1).
b) Entorno de prueba
Esta prueba se llevará a cabo después de la extracción de las categoría gramaticales
de las palabras de la consulta a partir del análisis léxico/sintáctico de la herramienta de
Stanford Parser.
c) Proceso
1) El usuario escribe su consulta en lenguaje natural.
2) El usuario presiona el botón “Execute”.
3) La herramienta muestra al usuario las categorías gramaticales de cada una de
las palabras en forma de lista en el cuadro “Tags”, y se genera un primer
patrón en la etiqueta “Query pattern”.
4) El usuario presiona el botón “Pattern”.
5) La herramienta genera el patrón reducido de la consulta en la etiqueta
“Reduced pattern”.
d) Resultado esperado
La herramienta generará el patrón reducido de la consulta del usuario, cada palabra en
su consulta corresponderá a un valor (letra) en el patrón generado.
Capítulo 5. Pruebas
69
Categoría 2. Pruebas para la identificación y tratamiento de los fenómenos lingüísticos
considerados en el presente trabajo.
1. ironLP-02-01 (tLp). Identificación del caso geni tivo.
a) Propósito
Analizar el patrón reducido que representa la consulta del usuario, identificar e informar
a éste de la presencia del caso genitivo en su consulta.
b) Entorno de la prueba
Esta prueba se llevará a cabo después de generar el patrón reducido de la consulta del
usuario, por lo que tiene como prerrequisito haber realizado el caso de prueba ironLP-
01-01 (tLp).
c) Proceso
1) El usuario escribe su consulta en lenguaje natural y presiona el botón
“Execute”.
2) El usuario presiona el botón “Pattern”.
3) La herramienta genera el patrón reducido de la consulta en la etiqueta
“Reduced pattern”.
4) La herramienta informa al usuario que su consulta contiene un caso genitivo.
d) Resultado esperado
La herramienta detecta el caso genitivo, y mediante un mensaje le informa al usuario
de su presencia.
2. ironLP-02-02 (tLp). Tratamiento del caso genitiv o.
a) Propósito
Identificar el poseedor y poseído dentro de una expresión con caso genitivo y reescribir
ésta mediante una relación con una preposición de pertenencia.
b) Entorno de la prueba
Capítulo 5. Pruebas
70
Esta prueba se llevará a cabo después de identificar un caso genitivo dentro del patrón
de la consulta del usuario, por lo que tiene como prerrequisito el caso de prueba
ironLP-02-01.
c) Proceso
1) El usuario escribe su consulta en lenguaje natural y presiona el botón
“Execute”.
2) El usuario presiona el botón “Pattern”.
3) La herramienta genera el patrón reducido de la consulta en la etiqueta
“Reduced pattern”.
4) La herramienta informa al usuario que su consulta contiene un caso genitivo y
reescribe la expresión.
d) Resultado esperado
La herramienta detecta y trata al caso genitivo, y mediante un mensaje le informa al
usuario de su presencia y le proponen una solución.
3. ironLP-02-03 (tLp). Identificación del fenómeno lingüístico de la elipsis.
a) Propósito
Analizar el patrón reducido que representa a la consulta del usuario, identificar e
informar a éste de la presencia del fenómeno de la elipsis en su consulta.
b) Entorno de la prueba
Esta prueba se llevará a cabo después de generar el patrón reducido de la consulta del
usuario y después de revisar y tratar los casos genitivos (si es que los hay), por lo que
tiene como prerrequisito haber realizado el caso de prueba ironLP-01-01 (tLp) y ironLP-
02-02 (tLp).
c) Proceso
1) El usuario escribe su consulta en lenguaje natural y presiona el botón
“Execute”.
2) El usuario presiona el botón “Pattern”.
Capítulo 5. Pruebas
71
3) La herramienta genera el patrón reducido de la consulta en la etiqueta
“Reduced pattern”.
4) La herramienta informa y trata casos genitivos en caso de existir.
5) La herramienta informa al usuario que su consulta presenta el fenómeno de la
elipsis.
d) Resultado esperado
La herramienta detecta el fenómeno de la elipsis, y mediante un mensaje le informa al
usuario de su presencia.
4. ironLP-02-04 (tLp). Tratamiento del fenómeno lin güístico de la elipsis.
a) Propósito
Identificar la información que debe ser repetida en la solicitud del usuario y para formar
dos consultas simples unidas por el nexo conjuntivo.
b) Entorno de la prueba
Esta prueba se llevará a cabo después de identificar el fenómeno de la elipsis dentro
del patrón de la consulta del usuario, por lo que tiene como prerrequisito el caso de
prueba ironLP-02-03 (tLp).
c) Proceso
1) El usuario escribe su consulta en lenguaje natural y presiona el botón
“Execute”.
2) El usuario presiona el botón “Pattern”.
3) La herramienta genera el patrón reducido de la consulta en la etiqueta
“Reduced pattern”.
4) La herramienta informa y trata casos genitivos en caso de haberlos.
5) La herramienta informa al usuario que su consulta contiene el fenómeno de la
elipsis y reescribe la consulta.
d) Resultado esperado
Capítulo 5. Pruebas
72
La herramienta detecta y le da tratamiento al fenómeno de la elipsis, y mediante un
mensaje le informa al usuario de su presencia y le proponen una solución.
Categoría 3. Pruebas para la identificación y generación de tripletas en la consulta del usuario en
lenguaje natural.
1. ironLP-03-01 (tLp). Generación de tripletas de p reguntas simples.
a) Propósito
Generar tripletas de consulta a partir de solicitudes del usuario que no contienen o
presentan fenómenos lingüísticos.
b) Entorno de la prueba
Esta prueba se llevará a cabo después de identificar y tratar los fenómenos lingüísticos
de la consulta del usuario, por lo que tiene como prerrequisitos los casos de prueba
ironLP-02-02 (tLp) y ironLP-02-04 (tLp).
c) Proceso
1) El usuario escribe su consulta en lenguaje natural y presiona el botón
“Execute”, y luego “Pattern”.
2) La herramienta genera el patrón reducido de la consulta en la etiqueta
“Reduced pattern” e identifica y trata los fenómenos lingüísticos presentes en
ella.
3) El usuario presiona el botón “getTriplets”.
4) La herramienta muestra al usuario la tripleta o tripletas generadas a partir de
su consulta dentro del recuadro “Triplets”.
d) Resultado esperado
La herramienta muestra todas las tripletas generadas a partir del análisis de la consulta
del usuario.
Capítulo 5. Pruebas
73
2. ironLP-03-02 (tLp). Generación de tripletas de p reguntas con caso genitivo.
a) Propósito
Generar tripletas de consulta a partir de solicitudes del usuario que contenga un caso
genitivo.
b) Entorno de la prueba
Esta prueba se llevará a cabo después de identificar y tratar los fenómenos lingüísticos
de la consulta del usuario, por lo que tiene como prerrequisitos los casos de prueba
ironLP-02-02 (tLp) y ironLP-02-04 (tLp).
c) Proceso
1) El usuario escribe su consulta en lenguaje natural y presiona el botón
“Execute”, y luego “Pattern”.
2) La herramienta genera el patrón reducido de la consulta en la etiqueta
“Reduced pattern” e identifica y trata los fenómenos lingüísticos presentes en
ella.
3) El usuario presiona el botón “getTriplets”.
4) La herramienta muestra al usuario la tripleta o tripletas generadas a partir de
su consulta dentro del recuadro “Triplets”.
d) Resultado esperado
La herramienta muestra todas las tripletas generadas a partir del análisis de la consulta
del usuario en lenguaje natural, en donde una de ellas se construye a partir de los
componentes gramaticales que conformaban el genitivo sajón.
3. ironLP-03-03 (tLp). Generación de tripletas de p reguntas con elipsis.
a) Propósito
Generar tripletas de consulta a partir de solicitudes del usuario que contenga el
fenómeno lingüístico de la elipsis.
b) Entorno de la prueba
Capítulo 5. Pruebas
74
Esta prueba se llevará a cabo después de identificar y tratar los fenómenos lingüísticos
de la consulta del usuario, por lo que tiene como prerrequisitos los casos de prueba
ironLP-02-02 (tLp) y ironLP-02-04 (tLp).
c) Proceso
1) El usuario escribe su consulta en lenguaje natural y presiona el botón
“Execute”, y luego “Pattern”.
2) La herramienta genera el patrón reducido de la consulta en la etiqueta
“Reduced pattern” e identifica y trata los fenómenos lingüísticos presentes en
ella.
3) El usuario presiona el botón “getTriplets”.
4) La herramienta muestra al usuario la tripleta o tripletas generadas a partir de
su consulta dentro del cuadro de texto “Triplets”.
d) Resultado esperado
La herramienta muestra todas las tripletas generadas a partir del análisis de la consulta
del usuario, se comprobará que existen tripletas repetidas a consecuencia de las
consultas simples generadas después del tratamiento del fenómeno de la elipsis.
4. ironLP-03-04 (tLp). Generación de tripletas de p reguntas con caso genitivo y elipsis.
a) Propósito
Generar tripletas de consulta a partir de solicitudes del usuario que contenga el
fenómeno lingüístico de la elipsis y contengan casos genitivos.
b) Entorno de la prueba
Esta prueba se llevará a cabo después de identificar y tratar los fenómenos lingüísticos
de la consulta del usuario, por lo que tiene como prerrequisitos los casos de prueba
ironLP-02-02 (tLp) y ironLP-02-04 (tLp).
c) Proceso
1) El usuario escribe su consulta en lenguaje natural y presiona el botón
“Execute”, y luego “Pattern”.
Capítulo 5. Pruebas
75
2) La herramienta genera el patrón reducido de la consulta en la etiqueta
“Reduced pattern” e identifica y trata los fenómenos lingüísticos presentes en
ella.
3) El usuario presiona el botón “getTriplets”.
4) La herramienta muestra al usuario la tripleta o tripletas generadas a partir de
su consulta dentro del cuadro de texto “Triplets”.
d) Resultado esperado
La herramienta muestra todas las tripletas generadas a partir del análisis de la consulta
del usuario, en donde una de ellas se construye a partir de los componentes
gramaticales que conformaban el genitivo sajón y además, se comprobará que existen
tripletas repetidas a consecuencia de las consultas simples generadas después del
tratamiento del fenómeno de la elipsis.
5. ironLP-03-05 (tLp). Generación de tripletas de p reguntas Who .
a) Propósito
Generar tripletas de consulta a partir de preguntas de tipo Who, en las cuales el sujeto
va implícito en la palabra de pregunta.
b) Entorno de la prueba
Esta prueba se llevará a cabo después de identificar y tratar los fenómenos lingüísticos
de la consulta del usuario, por lo que tiene como prerrequisitos los casos de prueba
ironLP-02-02 (tLp) y ironLP-02-04 (tLp).
c) Proceso
1) El usuario escribe su consulta en lenguaje natural y presiona el botón
“Execute”, y luego “Pattern”.
2) La herramienta genera el patrón reducido de la consulta en la etiqueta
“Reduced pattern” e identifica y trata los fenómenos lingüísticos presentes en
ella.
3) El usuario presiona el botón “getTriplets”.
Capítulo 5. Pruebas
76
4) La herramienta muestra al usuario la tripleta o tripletas generadas a partir de
su consulta dentro del recuadro “Triplets”.
d) Resultado esperado
La herramienta muestra todas las tripletas generadas a partir del análisis de la consulta
del usuario en lenguaje natural, se comprobará que se genera una tripleta inferida a
partir de la palabra de consulta buscando una persona.
Categoría 4. Pruebas para la generación de la consulta SPARQL representativa de la solicitud del
usuario.
1. ironLP-04-01 (tLp). Generación de consulta SPARQ L a partir de una consulta simple.
a) Propósito
Generar una consulta SPARQL a partir de las tripletas encontradas en una consulta
simple del usuario.
b) Entorno de la prueba
Esta prueba se llevará a cabo después de generar las tripletas de consulta a partir de
la solicitud del usuario, por lo que tiene como prerrequisitos los casos de prueba
ironLP-03-01 (tLp) al ironLP-03-05 (tLp).
c) Proceso
1) El usuario escribe su consulta en lenguaje natural, la herramienta genera el
patrón reducido y trata los fenómenos lingüísticos.
2) El usuario presiona el botón “getTriplets”.
3) La herramienta muestra al usuario la tripleta o tripletas generadas a partir de
su consulta dentro del recuadro “Triplets”.
4) El usuario presiona el botón “getSPARQL”.
5) La herramienta muestra al usuario la consulta SPARQL correspondiente a su
consulta en lenguaje natural dentro del recuadro “SPARQL”.
d) Resultado esperado
Capítulo 5. Pruebas
77
La herramienta muestra una consulta SPARQL básica que contiene todas las tripletas
generadas.
2. ironLP-04-02 (tLp). Generación de consulta SPARQ L a partir de consulta disyuntiva.
a) Propósito
Generar una consulta SPARQL a partir de las tripletas encontradas en una consulta
que contenga el fenómeno lingüístico de la elipsis, formado mediante una conjunción
coordinada disyuntiva.
b) Entorno de la prueba
Esta prueba se llevará a cabo después de generar las tripletas de consulta a partir de
la solicitud del usuario, por lo que tiene como prerrequisitos los casos de prueba
ironLP-03-01 (tLp) al ironLP-03-05 (tLp).
c) Proceso
1) El usuario escribe su consulta en lenguaje natural, la herramienta genera el
patrón reducido y trata los fenómenos lingüísticos.
2) El usuario presiona el botón “getTriplets”.
3) La herramienta muestra al usuario la tripleta o tripletas generadas a partir de
su consulta dentro del recuadro “Triplets”.
4) El usuario presiona el botón “getSPARQL”.
5) La herramienta muestra al usuario la consulta SPARQL correspondiente a su
consulta en lenguaje natural dentro del recuadro “SPARQL”.
d) Resultado esperado
La herramienta muestra una consulta SPARQL que tiene la clausula OPTIONAL en la
cual se organizan las tripletas generadas.
3. ironLP-04-03 (tLp). Generación de consulta SPARQ L de tipo ASK.
a) Propósito
Capítulo 5. Pruebas
78
Generar una consulta SPARQL a partir de las tripletas encontradas en una consulta
con verbo auxiliar.
b) Entorno de la prueba
Esta prueba se llevará a cabo después de generar las tripletas de consulta a partir de
la solicitud del usuario, por lo que tiene como prerrequisitos los casos de prueba
ironLP-03-01 (tLp) al ironLP-03-05 (tLp).
c) Proceso
1) El usuario escribe su consulta en lenguaje natural, la herramienta genera el
patrón reducido y trata los fenómenos lingüísticos.
2) El usuario presiona el botón “getTriplets”.
3) La herramienta muestra al usuario la tripleta o tripletas generadas a partir de
su consulta dentro del recuadro “Triplets”.
4) El usuario presiona el botón “getSPARQL”.
5) La herramienta muestra al usuario la consulta SPARQL correspondiente a su
consulta en lenguaje natural dentro del recuadro “SPARQL”.
d) Resultado esperado
La herramienta muestra una consulta en SPARQL de tipo ASK en la que se incluyen
las tripletas generadas, en este tipo de consulta no existe un variable solicitada, esto
es, ninguna de las tripletas contienen el signo de interrogación “’?”.
Capítulo 5. Pruebas
79
5.5 Resultados de las pruebas
Los resultados obtenidos una vez realizadas las pruebas descritas en la sección anterior se
presentan a continuación.
Tabla 5-3. Resultados del caso de prueba ironLP-01-01 (tLp)
Caso de prueba:
ironLP-01-01 (tLp). Generación del patrón reducido de la consulta
Resultado:
Se ejecutó la aplicación y se procedió a escribir una consulta simple, posteriormente se presionó el botón Execute y
mediante Stanford Parser se realizó el etiquetado de la consulta, posteriormente se presionó el botón Pattern y se
generaron dos patrones: Query pattern, aquel que se construye a partir del etiquetado de la herramienta Stanford
Parser, y Reduced pattern, construido a partir de la asignación de valores a cada una de la unidades léxicas y base
para todo el análisis de la pregunta (figura 5-1).
Figura 5-1. Ejecución del caso de prueba: ironLP-01-01 (tLp)
Observaciones:
- La generación del reduced pattern depende totalmente del buen análisis de la herramienta Stanford Parser.
Responsable:
Carlos Martín Vázquez Vásquez
Cargo:
Autor
Capítulo 5. Pruebas
80
Tabla 5-4. Resultados del caso de prueba ironLP-02-01 (tLP)
Caso de prueba:
ironLP-02-01 (tLp). Identificación del caso genitivo
Resultado:
Se ejecutó la aplicación y se procedió a escribir una consulta que presente un caso genitivo, después de su análisis
mediante el botón Execute se procede a generar el patrón mediante el botón Pattern y la aplicación detecta el
fenómeno lingüístico e informa al usuario del cambio a realizarse (figura 5-2).
Figura 5-2. Ejecución del caso de prueba: ironLP-02-01 (tLp)
Observaciones:
- La herramienta procede a reescribir la consulta del usuario de forma automática.
- El área de pregunta siempre está disponible por si el usuario no está convencido con la forma transformada
de su consulta.
Responsable:
Carlos Martín Vázquez Vásquez
Cargo:
Autor
Capítulo 5. Pruebas
81
Tablas 5-5. Resultados del caso de prueba ironLP-02-02 (tLp)
Caso de prueba:
ironLP-02-02 (tLp). Tratamiento del caso genitivo
Resultado:
Una vez que detectado el caso genitivo, de forma automática se reconstruye la consulta introducida por el usuario, y
éste nuevamente ejecuta el análisis de la consulta y genera el patrón correspondiente. Se puede observar (figura 5-3)
que la preposición de pertenencia con la que se resolvió el caso genitivo tiene un valor de F en lugar de P como
cualquier otra preposición.
Figura 5-3. Ejecución del caso de prueba: ironLP-02-02 (tLp)
Observaciones:
- El etiquetado de la preposición como F en lugar de P es sólo de carácter simbólico para que los casos
genitivos sean identificados.
Responsable:
Carlos Martín Vázquez Vásquez
Cargo:
Autor
Capítulo 5. Pruebas
82
Tabla 5-6. Resultados del caso de prueba ironLP-02-02 (tLp)
Caso de prueba:
ironLP-02-03 (tLp). Identificación del fenómeno lingüístico de la elipsis
Resultado:
Se ejecutó la aplicación y se procedió a escribir una consulta en donde exista un nexo coordinado como una
disyunción o conjunción, después de su análisis mediante el botón Execute se procede a generar el patrón mediante
el botón Pattern y la aplicación detecta el fenómeno lingüístico e informa al usuario del cambio a realizarse (figura 5-
4).
Figura 5-4. Ejecución del caso de prueba: ironLP-02-03
Observaciones:
- La propuesta de reconstrucción de la consulta tiene el objetivo de formular tantas preguntas como nexos
coordinados existan.
- La regla principal a seguir es utilizar siempre el mismo nexo coordinado en la pregunta, una combinación de
éstos (and, or) cambia el sentido semántico de la consulta y ésta no es posible interpretarse.
Responsable:
Carlos Martín Vázquez Vásquez
Cargo:
Autor
Capítulo 5. Pruebas
83
Tabla 5-7. Resultados del caso de prueba ironLP-02-04 (tLp)
Caso de prueba:
ironLP-02-04 (tLp). Tratamiento del fenómeno lingüístico de la elipsis
Resultado:
Una vez que se detecto la elipsis, de forma automática se reconstruyo la consulta introducida por el usuario, y éste
nuevamente ejecuta el análisis de la consulta y genera el patrón correspondiente (figura 5-5).
Figura 5-5. Ejecución del caso de prueba: ironLP-02-04 (tLp)
Observaciones:
- El usuario tiene la posibilidad de modificar el resultado generado por la herramienta sin problema alguno.
Responsable:
Carlos Martín Vázquez Vásquez
Cargo:
Autor
Capítulo 5. Pruebas
84
Tabla 5-8. Resultados del caso de prueba ironLP-03-01 (tLp)
Caso de prueba:
ironLP-03-01 (tLp). Generación de tripletas de preguntas simples
Resultado:
La generación de las tripletas depende del patrón reducido de la consulta, en este caso es una consulta simple (sin la
presencia de fenómenos lingüísticos), las tripletas generadas para un tipo de pregunta con Wh-question por lo menos
son dos, una que expresa la acción y otra que define la clase o categoría a la cual pertenece el objeto en cuestión
(figura 5-6).
Figura 5-6. Ejecución del caso de prueba: ironLP-03-01 (tLp)
Observaciones:
- El nombre de la variable es el mismo que el objeto por el cual se pregunta.
- La estructura de las tripletas está basada en el objeto del cual el usuario está preguntando.
Responsable:
Carlos Martín Vázquez Vásquez
Cargo:
Autor
Capítulo 5. Pruebas
85
Tabla 5-9. Resultados del caso de prueba ironLP-03-02 (tLp)
Caso de prueba:
ironLP-03-02 (tLp). Generación de tripletas de preguntas con caso genitivo
Resultado:
La generación de las tripletas depende del patrón reducido de la consulta, en la cual se presenta un caso genitivo, por
lo que éste tiene que ser resuelto (figura 5-7) y se vuelve a realizar el análisis correspondiente se generan las
tripletas de la consulta (figura 5-8).
Figura 5-7. Tratamiento del caso genitivo del caso de prueba: ironLP-03-02 (tLp)
Figura 5-8. Ejecución del caso de prueba: ironLP-03-02 (tLp)
Observaciones:
- La relación entre los dos objetos que conforman el caso genitivo es desconocida (“Unknown”).
Responsable:
Carlos Martín Vázquez Vásquez
Cargo:
Autor
Capítulo 5. Pruebas
86
Tabla 5-10. Resultados del caso de prueba ironLP-03-03 (tLp)
Caso de prueba:
ironLP-03-03 (tLp). Generación de tripletas de preguntas con elipsis
Resultado:
La generación de las tripletas depende de haber generado el patrón reducido de la consulta, en este caso es una
consulta que tiene presente el fenómeno lingüístico de la elipsis, por lo que éste tiene que ser resuelto (figura 5-9) y
se vuelve a realizar el análisis correspondiente para generar las tripletas de la consulta (figura 5-10).
Figura 5-9. Tratamiento del fenómeno de la elipsis del caso de prueba: ironLP-03-03 (tLp)
Figura 5-10. Ejecución del caso de prueba: ironLP-03-03 (tLp)
Observaciones:
- Las tripletas generadas de una consulta con el fenómeno de la elipsis son semejantes a tener las tripletas
generadas de dos consultas simples.
Responsable:
Carlos Martín Vázquez Vásquez
Cargo:
Autor
Capítulo 5. Pruebas
87
Tabla 5-11. Resultados del caso de prueba ironLP-03-04 (tLp)
Caso de prueba:
ironLP-03-04 (tLp). Generación de tripletas de preguntas con caso genitivo y elipsis
Resultado:
La generación de las tripletas depende de haber generado el patrón reducido de la consulta, cuando se presentan
varios fenómenos lingüísticos son tratados en el siguiente orden: primero se revisan y corrigen casos genitivos (figura
5-11) con la finalidad de que la consulta sea más fácil de analizar, posteriormente se evalúa el fenómeno de la elipsis
(figura 5-12). La reconstrucción de la consulta se realiza por cada paso, por lo que será necesaria la intervención del
usuario para volver a generar los patrones (figura 5-13).
Figura 5-11. Tratamiento del caso genitivo del caso de prueba: ironLP-03-04 (tLp)
Figura 5-12. Tratamiento del fenómeno de la elipsis del caso de prueba: ironLP-03-04 (tLp)
Figura 5-13. Ejecución del caso de prueba: ironLP-03-04 (tLp)
Observaciones:
- Las consultas del usuario deben presentar el caso genitivo antes del nexo coordinado.
- Los avisos de corrección de consultan implican realizar un nuevo análisis y generación del patrón.
Responsable:
Carlos Martín Vázquez Vásquez
Cargo:
Autor
Capítulo 5. Pruebas
88
Tabla 5-12. Resultados del caso de prueba ironLP-03-05 (tLp)
Caso de prueba:
ironLP-03-05 (tLp). Generación de tripletas de preguntas Who
Resultado:
La generación de las tripletas a partir de una pregunta con Who tiene un tratamiento particular, debido a que la
consulta carece del sujeto en cuestión, y éste queda de forma implícita dentro de la misma Wh-question. El mismo
caso se presenta con preguntas What, por lo que se opta por utilizar un sujeto desconocido (figura 5-14).
Figura 5-14. Ejecución del caso de prueba: ironLP-03-05 (tLp)
Observaciones:
- La tripleta [Unknown , is-a , Person] sólo se aplica a preguntas con Who.
- Las preguntas con What de forma genérica producen una tripleta.
Responsable:
Carlos Martín Vázquez Vásquez
Cargo:
Autor
Capítulo 5. Pruebas
89
Tabla 5-13. Resultados del caso de prueba ironLP-04-01 (tLp)
Caso de prueba:
ironLP-04-01 (tLp). Generación de consulta SPARQL a partir de una consulta
simple
Resultado:
Se considera una consulta simple aquella que el usuario introduce en lenguaje natural sin fenómenos lingüísticos y
genera dos tripletas, una de las cuales sirve para definir la posible subclase a la cual pertenezca el valor solicitado por
el usuario y la otra la condición que debe cumplir, por lo que la consulta SPARQL esperada debe contener dos
condiciones dentro de su cláusula Where (figura 5-15).
Figura 5-15. Ejecución del caso de prueba: ironLP-04-01 (tLp)
Observaciones:
- Los PREFIX agregados forman parte del estándar y son generados de forma automática dentro del gestor
de ontologías.
- La cláusula SELECT viene acompañada del modificador DISTINTIC el cual permite discriminar resultados
repetidos.
- La consulta SPARQL resultante es la siguiente:
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , is studying in , CENIDET . }
Responsable:
Carlos Martín Vázquez Vásquez
Cargo:
Autor
Capítulo 5. Pruebas
90
Tabla 5-14. Resultados del caso de prueba ironLP-04-02 (tLp)
Caso de prueba:
ironLP-04-02 (tLp). Generación de consulta SPARQL a partir de consulta disyuntiva
Resultado:
Las consultas disyuntivas se ven reflejadas en una consulta SPARQL mediante la cláusula OPTIONAL (figura 5-16), la
cual es anexada dentro de la sección de condiciones, dentro de esta cláusula se agregan las tripletas generadas
después del nexo disyuntivo.
Figura 5-16. Ejecución del caso de prueba: ironLP-04-02 (tLp)
Observaciones:
- El análisis de la consulta del usuario: “Which students are developing ontologies and are studiying about the
Semantic Web?”, implicó detectar y tratar el fenómeno de la elipsis, el proceso fue semejante al mostrado
en la prueba ironLP-02-03, después de tratar este fenómeno se obtuvo la siguiente consulta: “Which
students are developing ontologies and Which students are studiying about the Semantic Web?”, a partir de
la cual se generaron las tripletas y consulta en SPARQL.
- La consulta SPARQL resultante es la siguiente:
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT students ? WHERE { students ? , is-a , students . students ? , are developing , ontologies . OPTIONAL{ students ? , is-a , students . students ? , are studying about , the Semantic Web . } }
Responsable:
Carlos Martín Vázquez Vásquez
Cargo:
Autor
Capítulo 5. Pruebas
91
Tabla 5-15. Resultados del caso de prueba ironLP-04-03 (tLp)
Caso de prueba:
ironLP-04-023(tLp). Generación de consulta SPARQL de tipo ASK
Resultado:
Las consultas ASK se generan a partir de una solicitud del usuario que requiera solamente una respuesta corta (si o
no), a partir del patrón generado se identifican las entidades (nombres) y acciones (verbos) considerando la usencia
de una Wh-question, el verbo auxiliar utilizado para iniciar la pregunta no se considera (figura 5-17).
Figura 5-17. Ejecución del caso de prueba: ironLP-04-03 (tLp)
Observaciones:
- La generación de la tripleta no considera al verbo auxiliar (inicio de la consulta) como parte de una relación,
aún cuando en ocasiones es necesario como es el caso mostrado en la figura 5-17, a pesar de eso, si se
logra capturar la esencia de la acción.
- La consulta SPARQL resultante es la siguiente:
ASK{ Carlos , been working on , NLP }
Responsable:
Carlos Martín Vázquez Vásquez
Cargo:
Autor
Capítulo 5. Pruebas
92
5.6 Análisis de los resultados
El objetivo de las pruebas es comprobar la validez de la hipótesis planteada, a través de la
comparación de los resultados esperados contra los obtenidos. Las cuatro categorías de pruebas
realizadas comprenden desde un análisis inicial de la consulta en lenguaje natural, hasta la
formación de la consulta SPARQL a partir de los componentes lingüísticos de la misma.
Las pruebas fueron ejecutadas, y mediante un análisis de los resultados obtenidos, se
observó que estos resultados corresponden a los definidos en 5.4. Por lo tanto, la hipótesis
planteada se confirma, por lo que se puede concluir que: si es posible construir una consulta
SPARQL considerando solamente los componentes lingüísticos de la consulta en lenguaje natural
del usuario.
Para la aceptación de la hipótesis se tuvieron que realizar cada una de las pruebas, en las
cuales, de algunas no se obtuvieron los resultados esperados en su primera ejecución, por lo que
fue necesario realizar las modificaciones necesarias para que éstas fuera aceptadas dentro de la
etapa de depuraciones.
Con la finalidad de confirmar los resultados y conclusión obtenida, el prototipo fue probado
sobre un banco de preguntas [KMI10] desarrollado por los creadores de la herramienta Aqualog
[LÓPEZ06], en el cual definen 16 categorías de consultas basados en criterios lingüísticos puros.
Las categorías de preguntas probadas en el prototipo fueron:
• Categoría 1: Wh-genericterm
• Categoría 2: Wh-unknrel
• Categoría 5: Affirmative-negative
• Categoría 6: Affirmative-negative-pseudorel
• Categoría 7: Wh-3term
• Categoría 8: Wh-generic-1termclause
• Categoría 12: Wh-comb-and
• Categoría 13: Wh-comb.or
Capítulo 5. Pruebas
93
Las categorías de preguntas excluidas de estas pruebas fueron con base en los alcances y
limitaciones del presente trabajo (anexo C), en las que no se consideran preguntas con más de
una palabra de consulta o preguntas que requieran definiciones.
Un total de 105 preguntas se ejecutaron directamente del banco de pruebas (anexo D),
considerando que varias contenían errores gramaticales y algunas quedan fuera de los alcances
del presente trabajo de tesis. Los resultados se resumen a continuación:
Tabla 5-16. Resultado de la primera ejecución de pruebas al banco de preguntas
Preguntas totales 105
Éxitos 53
Fracasos 52
Eficiencia 50.48%
La tabla anterior muestra que sólo el 50.48% de las preguntas del banco de prueba se
transformaron a tripletas y consulta en SPARQL, por lo que del 49.52% de las mismas no se
obtuvieron los resultados esperados debido a que su estructura sintáctica se encuentra fuera de
los alcances del trabajo de tesis.
Se realizó un análisis de las preguntas que no pudieron ser traducidas, y fueron eliminadas
aquellas no consideradas en el presente trabajo de tesis como preguntas de cantidad (How +
cuantificador), preguntas de si o no con modificadores (is there) y preguntas que generan una
relación a partir de nombres (no taxonómicas), además, fueron reformuladas las consultas regidas
por una preposición, por ejemplo: which universities is Knowledge Media Institute collaborating
with?, fue reescrita como: which universities is collaborating with Knowledge Media Institute?. La
pregunta anterior es gramaticalmente incorrecta pero no afecta el proceso de análisis realizado en
el presenta trabajo.
Después del análisis y depuración de los fracasos, fueron nuevamente analizadas las
preguntas produciendo los resultados mostrados a continuación:
Capítulo 5. Pruebas
94
Tabla 5-17. Resultado de la segunda ejecución de pruebas al banco de preguntas
Preguntas totales 105
Preguntas eliminadas 29
Preguntas consideradas 76
Éxitos 65
Fracasos 11
Eficiencia 85.52%
Los resultados presentados muestran un 85.52% de efectividad después de eliminar y
corregir (en caso de haber sido necesario) las preguntas fallidas durante el primer análisis. El
resultado obtenido confirma la aceptación de la hipótesis perseguida durante el presente trabajo.
Los casos fallidos presentes después del segundo análisis se deben principalmente a
errores durante el análisis léxico/sintáctico arrojados por la herramienta StanfordParser, de
cualquier forma sólo representan el 14.47% del total de las preguntas.
5.7 Justificación de las pruebas fallidas
Las pruebas realizadas y presentadas dentro del capítulo 6 permitieron aceptar la hipótesis de
investigación, durante el proceso de pruebas se obtuvieron resultados no esperados debidos
principalmente a errores en el análisis léxico/sintáctico realizado por Stanford Parser.
Durante el análisis léxico/sintáctico, la identificación de los componentes lingüísticos de la
consulta no correspondía a la realidad, por lo que en varias ocasiones esta circunstancia conducía
a la generación de un patrón incorrecto que a su vez provoca la generación incorrecta de tripletas
respecto a la solicitud del usuario.
Un ejemplo de una prueba fallida se presentó al momento de analizar la pregunta “which
projects on language are sponsored by eprsc?”, con la cual se general el siguiente árbol sintáctico
(figura 5-18):
Capítulo 5. Pruebas
95
Figura 5-18. Árbol sintáctico generado por Stanford Parser
En la figura anterior se observa que Stanford Parser identifica la palabra “eprsc” como
adjetivo, la cual carece del nombre al que califica. El análisis del patrón generado a partir de la
figura 5-18 contendrá un adjetivo que no irá acompañado de un nombre por lo que no se podrá
identificar el componente de la tripleta correspondiente con base a la regla de identificación de
nombres de la tabla 4.7.
Además, la figura 5-18 muestra el etiquetado de la preposición “on” como una partícula
(elemento no identificado) en lugar de una preposición, de igual forma no será posible identificar la
relación entre “projects” y “language” que nos permitiría generar una tripleta con relación
desconocida.
Finalmente, el análisis generado para esta consulta cuenta con otro problema al momento
de identificar la palabra “projects”, la cual fue etiquetada de forma incorrecta como verbo en tercera
persona en lugar de un nombre en tercera persona, por lo que sin necesidad de solucionar los
problemas anteriores éste no permite identificar el valor solicitado en la consulta y todo el posible
resultado del análisis sería incorrecto.
Capítulo 5. Pruebas
96
La solución posible a este problema es reescribir la consulta respetando el sentido
semántico de la misma, de tal forma que a partir de la consulta “which projects on language are
sponsored by eprsc?” con todas las implicaciones que conlleva se transforme en una estructura
semejante a “which projects of language are sponsored by the eprsc?”, pero ésta es una actividad
no considerada en el presente trabajo de tesis debido a que no se identifica si el resultado del
análisis léxico/sintáctico fue incorrecto.
Los problemas mencionados son sólo algunos provenientes de un error en el análisis
léxico/sintáctico, el cual como se observó se puede presentar dentro de la categorización de
nombre, preposiciones o verbos.
Otro problema, no menos importante pero si fuera de los alcances del presente trabajo
recae sobre el sentido semántico, al considerar el tratamiento del fenómeno de la elipsis en el
presente trabajo con facilidad se hace presente el fenómeno lingüístico de la ambigüedad, el cual
se encuentra en la siguiente consulta: “Which students are studying ontologies and conceptual
modeling or mobile devices”, la cual solicita los estudiantes interesados en ontologías que además
están estudiando modelado conceptual o dispositivos móviles, esta característica no es identificada
dentro del proceso de análisis lingüístico del presente trabajo.
Los problemas mencionados anteriormente conducen a errores dentro del proceso de
generación de tripletas y construcción de consultas SPARQL, otros problemas se detectaron
dentro del análisis propuesto los cuales fueron solucionados para poder ejecutar las pruebas de
forma satisfactoria.
Capítulo 6. Conclusiones
97
Capítulo 6. Conclusiones
En este capítulo se mencionan las aportaciones del presente trabajo de tesis, se plantean las
conclusiones a las que se llegaron después de la investigación realizada y se proponen los
trabajos futuros que se pueden derivar del trabajo desarrollado.
Capítulo 6. Conclusiones
98
6.1 Conclusiones
Mediante el uso de herramientas de análisis léxico/sintáctico, y a partir de un tratamiento del
lenguaje natural basado en expresiones regulares para la identificación de patrones, es posible
representar la consulta del usuario en lenguaje natural en formato de tripletas <sujeto, predicado,
objeto> y éstas se organizan para formar una representación de consulta en SPARQL.
Para alcanzar los objetivos planteados en el presente trabajo se realizó un estudio de las
herramientas para el análisis léxico/sintáctico. Estas herramientas facilitan la manipulación e
interpretación del texto en lenguaje natural, debido a que su tarea principal consiste en el
etiquetado morfológico (categorías gramaticales) y sintáctico (sintagmas) regresando al usuario
información adicional acerca del texto analizado. Después de un estudio de las mismas se
seleccionó la herramienta Stanford Parser (ver anexo A).
La identificación y tratamiento de casos genitivos y el fenómeno de la elipsis se realizó
mediante la generación de conjunto de reglas, estas reglas consideran parte de las variantes
gramaticales en las que se presentan estos fenómenos con la finalidad de generar consultas sin
información gramatical faltante a partir de la consulta original del usuario en lenguaje natural.
El proceso de análisis de la consulta del usuario se basó en la generación de tripletas
como una representación intermedia de la misma, muchos trabajos habían concebido la idea de
formación de tripletas pero en base a la ontología a consultar, la metodología desarrollada en el
presente trabajo no considera una ontología base, por lo que fue necesario modificar e integrar
algunas de las técnicas revisadas, para construir tripletas sólo con la información proporcionada
por el usuario en su consulta.
La generación de la consulta en SPARQL se realiza a partir de las tripletas generadas, la
cual puede tener una estructura con sentencia SELECT o ASK considerando sólo la estructura e
información de la consulta del usuario en lenguaje natural.
El resultado de este trabajo muestra las siguientes ventajas en comparación con otras
herramientas semejantes presentadas en el estudio del estado del arte: el uso de expresiones
regulares para la identificación de patrones, permite detectar y extraer las entidades (nombres) y
acciones (verbos) en la consulta en lenguaje natural sin la necesidad de acceder y hacer
inferencias con las entidades de la ontología; el tratamiento de fenómenos lingüísticos o
peculiaridades de la gramática inglesa, con la finalidad de reconstruir la consulta en lenguaje
natural para analizarla sin necesidad de la intervención del usuario; la construcción de consultas en
Capítulo 6. Conclusiones
99
SPARQL con sentencias SELECT y ASK, a partir de las tripletas generadas mediante la
identificación de patrones con expresiones regulares.
Sin embargo, aun con las ventajas mencionadas anteriormente, el producto obtenido en
esta tesis es un prototipo y parte del marco de trabajo de ironLP, es por esto que se recomienda
implementar los puntos presentados en trabajos futuros para convertir este producto en una
herramienta competitiva.
6.2 Aportaciones
El presente trabajo de tesis deja como aportación principal el desarrollo de los módulos para el
análisis lingüístico de la herramienta ironLP, en los cuales se realiza un procesamiento del lenguaje
natural para transformar una consulta del usuario a una representación de una consulta en
lenguaje SPARQL.
Entre otras aportaciones se encuentran:
• La implementación de una técnica de procesamiento del lenguaje natural usando reglas
independientes del dominio de aplicación, con la finalidad de aportar en la tarea de
recuperación de información
• La generación de tripletas a partir de las unidades gramaticales que componen la consulta
del usuario en lenguaje natural, considerando el sentido semántico que pueden aportar las
palabras de pregunta, como es el caso de “Who” para referirnos a personas.
• La generación de consultas en SPARQL que representen la consulta del usuario, utilizando
la sentencia SELECT para recuperar un valor o conjunto de ellos, y la sentencia ASK para
verificar la existencia de una relación entre objetos.
• La aplicación de expresiones regulares para la identificación de patrones para construir
estructuras de la forma <sujeto, predicado, objeto> en textos en lenguaje natural.
• La detección y tratamiento de los casos genitivos o casos posesivos presentes en la
gramática inglesa, mediante la identificación de las entidades poseedor y poseído.
• La detección y tratamiento del fenómeno lingüístico de la elipsis, algunas veces llamado
economía de palabras, considerando oraciones coordinadas copulativas y disyuntivas, con
Capítulo 6. Conclusiones
100
la finalidad de reconstruir la consulta original repitiendo los elementos que fueron elididos
por el usuario al momento de preguntar.
• La utilización de expresiones regulares permite que el proceso de identificación de
entidades (nombres) y acciones (verbos) se aplique en otros idiomas tan sólo con
modificar su estructura sin afectar la metodología utilizada.
6.3 Trabajos futuros
Los resultados de este trabajo de investigación han permitido la identificación de actividades
adicionales que pueden ayudar a complementar y mejorar el trabajo presentado en esta tesis, los
cuales se describen a continuación:
• Agregar o modificar las expresiones regulares con la finalidad de reconocer y ampliar el
rango de preguntas aceptadas por el prototipo actual, tales como preguntas con when,
why, where y how, lo cual resultará factible una vez que toda la herramienta ironLP sea
integrada.
• Agregar reglas para el tratamiento del fenómeno lingüístico de la elipsis presente en
oraciones coordinadas adversativas, las cuales llevan de forma implícita la conjunción y
que no fueron consideradas en el desarrollo de la investigación.
• Generar consultas SPARQL complejas identificando elementos potenciales en la consulta
del usuario para ser transformados en sentencias FILTER, ORDER BY, LIMIT, etc.
• Modificar la generación de consultas SPARQL para construir consultas en otros lenguajes,
como SQL, a partir de la generación de tripletas de consulta.
• Incorporar el análisis de las consultas en lenguaje natural a un sistema de extracción de
información a partir de ontologías.
A partir de las actividades propuestas, se pretende proporcionar una idea de las posibles
actividades u objetivos que pudieran cubrirse con nuevos proyectos de investigación, todos con la
finalidad de mejorar el prototipo realizado y optimizar el trabajo de la herramienta ironLP.
Referencias
101
Referencias
[ALEXANDER99] Louis George Alexander. “Longman English Grammar”. 17th reimpresión.
Editorial Longman 1999.
[ALIAS-I10] ALIAS-I. “LingPipe Home”.. Documento en línea. http://alias-i.com/lingpipe/.
Consultado agosto de 2010.
[ALLEN95] James Allen. “Natural Language Understanding”. The Benjamin/Cummings
Publishing Company, Inc. 1995.
[BATES93] Madeleine Bates, Weischedel Ralph. “Challenges in Natural Language
Processing”. Editotial Cambridge University Press. Cambridge, Inglaterra.
1993.
[BERNSTEIN05] Abraham Bernstein, Esther Kaufmann, Anne Göhring, Christoph Kiefer.
“Queriying Ontologies: A Controlled English Interface for End-users”. 4th
International Semantic Web Conference. Galway, Irlanda. 2005.
[BERNSTEIN06] Abraham Bernstein, Esther Kaufmann, Christian Kaiser, Christoph Kiefer.
“Ginseng: A guiaded input natural language search engine for querying
ontologies”. 2006 Jena User Conference. Bristol, UK. 2006.
[BHATIA06] Nipun Bhatia, Prashant Gaharwar, Prayus Patnaik. “GuNQ: A semantic
Web engine with a keyword based query approach”. AAAI Fall Symposium
on Semantic Web for Collaborative Knowledge Acquisition. Arlington, VA.
2006.
[COVINGTON94] Michael Covington. “Natural Language Processing for Prolog
Programmers”. Prentice Hall. 1994.
[DALI09] Lorand Dali, Delia Ruso, Blaz Fortuna, Dunja Mladenic, Marco Grobelnik.
“Question Answering Based on Semantic Graphs”. Semantic Web Search
2009 Workshop located at the 18th International World Wide Web
Conference (WWW2009). Madrid, España. 2009.
[DRAKE08] Miriam Drake. “Encyclopedia of Library and Information Science”. Segunda
edición. Editorial Taylor & Francis. 2008.
[D’AQUIN07] Mathieu D’Aquin, Marta Sabou, Martin Dzbor, Claudio Baldassarre, Laurian
Gridinoc, Sofia Angeletou, Enrico Motta. “WATSON: A Gateway for the
Referencias
102
semantic Web”. 4th Eurpean Semantic Web Conference. Innsburck,
Australia. 2007.
[FBK10] Fundazione Bruno Kessler (FBK). “TextPro tool Home Page”. Documento
en línea. http://textpro.fbk.eu/home.html. Consultado agosto de 2010.
[FERRÁNDEZ08] Óscar Ferrández, Rubén Izquierdo, Sergio Ferrández, José Vicedo.
“QACID: Un sistema de búsqueda de respuestas basado en ontologías,
implicación textual y entornos reales”. Revista de la Sociedad Española
para el Procesamiento del Lenguaje Natural. Num. 41, pag. 47-54. 2008.
[GATE10] GATE Team. “GATE: General Architecture for Text Engineering”.
Universidad de Sheffield. Documento en línea. http://gate.ac.uk/.
Consultado agosto de 2010.
[HIRSCHMAN01] Lynette Hirschman, Robbert Gaizauskas. “Natural language question
answering: the view from here”. Natural Language Engineering, vol. 7, pag.
275-300. © Cambridge University Press. 2001.
[HOOGE06] David Carl Hooge Jr. “Extraction and indexing of triplet-based knowledge
using Natural Language Processing”. Tesis de maestría en ciencias.
Universidad de Georgia. 2006.
[KAGOLOVSKY03] Yuri Kagolovsky, Jochen R. Moehr. “Current Status of the Evaluation of
Information Retrieval”. Journal of Medical Systems. Volumen 27, número
5, páginas 409-424. Octubre de 2003.
[KAUFMANN06] Esther Kaufmann, Abraham Bernstein, Renato Zumstein. “Querix: A natural
language interface to query ontologies based on clarification dialog”. 5th
International Semantic Web Conference (ISWC). Atenas, Grecia. 2006.
[KAUFMANN07] Esther Kaufmann, Abraham Bernstein, Lorenz Fischer. “NLP-Reduce A
naïve but domain-independent natural language interface for querying
ontologies”. Innsbruck, Australia. 2007.
[KMI10] Knowledge Media Institute. “AquaLog”. Documento en línea.
http://technologies.kmi.open.ac.uk/aqualog/. Consultado septiembre de
2010.
[LÓPEZ06] Vanessa López, Victoria Uren, Enrico Motta, Michele Pasin. “AquaLog: An
ontology-driven Question Answering system as an interface to the
Referencias
103
Semantic Web”. Human Language Technology Conference of North
America Chapter of the Association of Computational Linguistics
Proceedings. Nueva York. 2006.
[LÓPEZ09] Vanessa López, Victoria Urem, Marta Sabou, Enrico Motta. “Cross ontology
query answering on the semantic Web: An initial evaluation”. Proceedings
of the fifth International Conference on Knowledge Capture, pag. 17-24.
California, USA 2009.
[MANNING09] Christopher D. Manning, Prabhakar Raghavan, Hinrich Schütze. “An
introduction to Information Retrieval”. Book on-line. © Cambridge University
Press. Abril de 2009. http://nlp.stanford.edu/IR-book/information-retrieval-
book.html. Consultado julio de 2010.
[MUSZÁTKO96] Pavel Muszátko. “Approximate Regular Expression Matching”. Proceedings
of the Prague Stringologic Club Workshop ’96. Prague, Czech Rupublic.
1996.
[PATTEN02] Tery Patten, Paul Jacobs. “Natural-Language Processing”. IEE Expert of
IEEE Computer Society. 2002.
[PTP10] The Penn Tree Bank Project. “Penn Treebank II Tags”. Documento en
línea. http://bulba.sdsu.edu/jeanette/thesis/PennTags.html. Consultado
agosto de 2010.
[RAMACHANDRA09] Vivek Ramachandran, Krishnamurthi Llango. “NLION: Natural language
interface for querying ontologies”. Proceedings of the 2nd Bangalore Annual
Computer Conference. Bangalore, India. 2009.
[REYES08] José Alejandro Reyes Ortiz. “Extracción de información semántica para la
clasificación de servicios Web”. Tesis de maestría. Centro Nacional de
Investigación y Desarrollo Tecnológico (CENIDET). 2008.
[ROSENBACH07] Anette Rosenbach. “Animacy and grammatical variation – Findings form
English genitive variation”. Lingua (journal), volumen 118 pag. 151-171.
ScienceDirect. 2007.
[SÁNCHEZ07] Francisco Sánchez Benedito. “Gramática Inglesa”. Novena edición.
Editorial Pearson Longman. 2007.
Referencias
104
[SÁNCHEZ08] Ebenezer Hasdai Sánchez Pacheco. “Generación de modelos
conceptuales a partir de modelos de requisitos: un enfoque basado en
Tratamiento Automático del Lenguaje Natural”. Tesis de maestría. Centro
Nacional de Investigación y Desarrollo Tecnológico. 2008.
[SPARQL08] W3C. “Query Language for RDF”. Documento en línea. http://
w3.org/TR/rdf-sparql-query. Consultado septiembre de 2010.
[STANFORD10] The Stanford NLP group. “The Stanford NLP (Natural Language
Processing) Group”. Documento en línea.
http://nlp.stanford.edu/software/lex-parser.shtml. Consultado agosto de
2010.
[TALP10] TALP Research Center. “Freeling Home Page”. Documento en línea.
http://www.lsi.upc.edu/~nlp/freeling/. Consultado agosto de 2010.
[TEROL06] Rafael Terol, Patricio Martinez-Barco, Manuel Palomar. “Aplicación de
técnicas basadas en PLN al tratamiento de preguntas médicas en
Búsqueda de Respuestas”. Revista de la Sociedad Española para el
Procesamiento del Lenguaje Natural. Num. 36, pp. 17-24. 2006.
[VIVANCOS09] Pedro Vivancos, Juan Salvador Castejón, David García. “INVENIO:
Búsqueda semántica basada en tecnología Google”. Revista de la
Sociedad Española para el Procesamiento del Lenguaje Natural. Num. 43,
pag. 353-354. ISSN: 1135-5048. 2009.
[VOORHEES00] Ellen M. Vorhees, Donna Harman. “Proceedings 8th Text Retrieval
Conference (TREC-8)”. Publicación especial NIST 500-246.
http://trec.nist.gov/pubs.html. 2000. Consultado agosto 2010.
[WANG07] Chong Wang, Miao Xiong, Qi Zhou, Yong Yu. “PANTO: A Portable Natural
Language Interface to Ontologies”. 4ta European Semantic Web
Conference. Innsbrick, Australia. 2007.
[W3C10] World Wide Web Consortium. “World Wide Web Consortium Issues RDF
and OWL Recommendations”. Comunicado de prensa 10 de febrero de
2004. http://www.w3.org/2004/01/sws-pressrelease.html.en. Consultado
agosto de 2010.
Referencias
105
[ZÁRATE07] José Antonio Zárate Marceleño. “Aplicación de ontologías en la
construcción de una base de conocimiento para una interfaz en español
hacia base de datos”. Tesis doctoral. Centro Nacional de Investigación y
Desarrollo Tecnológico. 2007.
Referencias
106
Anexos
107
Anexos
Anexos
108
Anexo A. Herramientas libres para el procesamiento del lenguaje natural
Actualmente existe una amplia variedad de herramientas para el Procesamiento del Lenguaje
Natural (PLN), muchas de ellas de libre descarga junto con su código fuente desde la página del
autor, algunas otras son desarrollos propietarios.
A continuación se procede a enlistar de forma breve algunas de las herramientas para el
PLN, y se finalizará con la comparación de las herramientas más destacadas, desde un punto de
vista personal.
• LingPipe
LingPipe [ALIAS-I10] es un conjunto de librerías de Java desarrolladas por Alias-i para el
procesamiento del lenguaje natural. Esta herramienta viene lista por defecto para el
reconocimiento y clasificación de nombres de entidades, tales como: personas, organizaciones, y
lugares en idioma inglés, pero tiene la posibilidad de ser entrenada para reconocer otros idiomas.
Adicionalmente a la detección e identificación de entidades, ofrece posibilidades como corrección
ortográfica y clasificación de textos en inglés. Cuenta con una interfaz de usuario y varios demos a
través de los cuales es posible experimentar su funcionamiento con textos de prueba. La
herramienta LingPipe es de código abierto (open-source) y libre para modificarse según los usos
que se le quiera dar.
• Freeling
Freeling [TALP10] es una herramienta desarrollada en C++ en el centro de investigación TALP de
la Universidad Politécnica de Cataluña. Es una herramienta de código abierto con una licencia
GNU y puede ser utilizado como una API o de forma independiente. Ofrece varios servicios
relacionados al procesamiento del lenguaje natural, como: Morphological Analisis, POS Tagging,
Shallow Parsing y Dependency Parsing. Cuenta con una demostración de su funcionamiento
dentro de su página Web y tiene soporte para varios idiomas como el español, inglés, portugués,
italiano, catalán, galiciano, asturiano y galés.
Anexos
109
• TextPro
TextPro [FBK10] es una suite desarrollada en C++ en el Centro para la Investigación Científica y
Tecnológica (ITC-irst), en Trento, y ofrece varias funcionalidades para el procesamiento del
lenguaje natural interconectadas en orden de pipeline. Cuenta con una licencia GNU, usa
aprendizaje automático y gazetteers. TextPro se encuentra disponible para el idioma inglés e
italiano, además ofrece una demostración de su funcionamiento en ambos lenguajes vía Web.
• GATE
GATE [GATE10] (General Architecture for Text Engineering) es un conjunto de herramientas de
Java para tareas del procesamiento del lenguaje natural incluyendo la extracción de información en
varios idiomas. GATE ha estado desarrollándose en la Universidad de Sheffield desde el año de
1995 y usado en una amplia variedad de proyectos de investigación y desarrollo. GATE es:
• Un IDE, GATE Developer: un entorno de desarrollo integrado para el procesamiento del
lenguaje con un amplio uso de sistemas de Extracción de Información y otro conjunto
significante de plugin.
• Un web app, GATE Teamware, un entorno de anotaciones colaborativas para la
construcción de proyectos de anotaciones semánticas.
• Un framework, GATE Embedded, una librería de objetos para ser incluidos en diversas
aplicaciones brindando acceso a todos los servicios usados por GATE Developer y otros.
• Una arquitectura, un esquema organizacional de alto nivel de la composición de software
para el procesamiento del lenguaje.
• Un proceso, para la creación de servicios robustos y mantenibles.
La herramienta GATE tiene soporte para muchos lenguajes, entre ellos: inglés, búlgaro,
rumano, español, sueco, alemán, italiano y francés.
Anexos
110
• Stanford Tools
Las Stanford Tools [STANFORD10] están escritas en lenguaje java, y están siendo desarrolladas y
mejoradas por el grupo de investigación de procesamiento del lenguaje natural de la Universidad
de Stanford.
Todas las herramientas pertenecientes a Stanford Tools son de código abierto bajo una
licencia GNU. Algunas de las herramientas que conforman la suite de Stanford son:
• Stanford Parser. Implementación de java de un analizador del lenguaje natural
probabilístico.
• Stanford POS Tagger. Implementación en java de algoritmos de máxima entropía para el
análisis de datos y de part-of-speech tagger.
• Stanford Named Entity Recognizer. Una implementación en Java de un modelo secuencial
de Condicional Random Field (CRF) junto con contras características para el
reconocimiento de nombres de entidades.
La herramienta Standford Parser es una analizador probabilístico del lenguaje natural,
implementado en lenguaje java. En su sitio web se encuentra disponible una implementación on-
line del mismo, además, tiene soporte para los idiomas: inglés, árabe y chino. Stanford Parser
cuenta con funcionalidades como: POS tagging, parser, typed dependencies y typed dependencies
collapsed.
La tarea de seleccionar la herramienta de apoyo, ha sido una actividad directamente
proporcional a las soluciones necesarias para los problemas encontrados durante el desarrollo del
trabajo de tesis, en la tabla anexo 1 se muestra una comparación de las herramientas descritas
hace un momento.
Anexos
111
Tabla anexo 1. Comparación de herramientas para el procesamiento del lenguaje natural
LingPipe
FreeLing
TextPro
GATE
Standford Parser
Análisis de
idioma inglés Si Si Si
Si Si
Independiente
del dominio Si Si Si
Si Si
Procesamiento
automático Si Si Si
No Si
Facilidades de
integración (API) No Si No
No Si
Desarrollo libre
para su uso Si Si No
Si Si
Las herramienta GATE fue descartada debido a que para el etiquetado usa el TreeTagger
y éste necesita entrenamiento para trabajar sobre un dominio específico, además cuenta con un
conjunto de aplicaciones auxiliares que no son necesarias para el trabajo de tesis, a pesar de
esto, es una herramienta potente para el análisis de corpus de texto y muy útil en el área de
minería de texto.
Las herramientas LingPipe y TextPro fueron descartadas debido a que cuentan con un
conjunto de aplicaciones de apoyo para el PLN las cuales no fueron necesarias para el desarrollo
del trabajo, LingPipe es ampliamente usada en el área de investigación y educación por: la
Universidad del Norte de Texas, por el Grupo de Investigación Alemán para la IA (Inteligencia
Artificial), Universidad de Cambridge, etc., y TextPro es un desarrollo propietario el cual se
encuentra disponible realizando una solicitud de licencia para su uso en investigación.
Las herramientas Freeling y StanfordParser son adecuadas para el trabajo de tesis debido
a que cumplen con todas las características solicitadas, por lo tanto, cualquiera de las dos podría
implementarse.
Se decidió utilizar la herramienta Stanford Parser debido a que se encuentra desarrollada
sobre lenguaje Java, misma plataforma sobre la cual se desarrolló la herramienta del trabajo de
tesis, además de tener la capacidad de realizar análisis léxico-sintáctico a partir de un texto u
oración y realizar un análisis semántico entre las dependencias de las palabras que componen el
Anexos
112
texto u oración. Uno de los principales problemas con los que cuenta la herramienta es el tiempo
de respuesta por cada solicitud que se realiza.
En el caso de Freeling, a pesar soportar análisis léxico-sintáctico de texto y los tiempos de
respuesta son mucho mejores que los de Stanford Parser, no fue inicialmente seleccionada debido
a que encuentra sobre una plataforma C++, en su última versión, Freeling incorpora una API que lo
hace extensible para trabajar sobre una plataforma Java, pero se ve afectado por problemas al
momento de implementarlo según se puede observar en el foro1 dentro de su misma página.
Un último aspecto considerado en la selección de la herramienta, fueron los casos de
éxitos obtenidos con el uso de la misma, los cuales se describen dentro del estado del arte,
ninguno de ellos hace uso de Freeling como herramienta de apoyo para el procesamiento del
lenguaje natural.
1 Foro Freeling - http://www.lsi.upc.edu/~nlp/freeling/index.php?option=com_simpleboard&Itemid=55
Anexos
113
Anexo B. Penn Treebank Tags
El proyecto Penn Treebank tiene la finalidad de crear anotaciones a textos en lenguaje natural. El
proyecto ha sido usado como línea base para el desarrollo de muchos etiquetadores como el
usado en el presente trabajo de tesis. Las etiquetas usadas en el mismo son las siguientes:
B.1 Nivel de oraciones o cláusulas
Tabla anexo 2. Penn Treebank Tags – Nivel de oraciones
S Cláusula declarativa simple. SBAR Cláusula introducida por una (posiblemente vacía)
conjunción subordinada. SBARQ Pregunta directa introducida por una wh-word o wh-
phrase. SINV Sentencia declarativa invertida, en la cual el sujeto
va seguido del verbo o modal. SQ Pregunta invertida yes/no, o cláusula de una wh-
question seguida de una wh-phrase en un SBARQ.
B.2 Nivel de frase
Tabla anexo 3. Penn Treebank Tags – Nivel de frase
ADJP Frase adjetival ADVP Frase adverbial CONJP Frase conjunción FRAG Fragmento INTJ Intersección LST Marcador de lista NAC Un no constituyente NP Frase nominal NX Usada para NP complejas PP Frase preposicional PRN Paréntesis PRT Partícula QP Frase cuantificadora RRC Cláusula de relativo reducido UCP Diferente a frase coordinada VP Frase verbal WHADJP Frase Wh-adjetive WHAVP Frase Wh-adverb WHNP Frase Wh-noun WHPP Frase Wh-prepositional X Desconocido
Anexos
114
B.3 Nivel de palabra
Tabla anexo 4. Penn Treebank Tags – Nivel de palabra
CC Conjunción coordinada CD Número cardinal DT Determinante EX No existencia FW Palabra extrajera IN Preposición o conjunción subordinada JJ Adjetivo JJR Adjetivo comparativo JJS Adjetivo superlativo LS Marcador de elemento de lista MD Modal NN Nombre singular NNS Nombre plural NNP Nombre propio singular NNPS Nombre propio plural PDT Pre-determinante POS Terminación posesiva PRP Pronombre personal PRP$ Pronombre posesivo RB Adverbio RBR Adverbio comparativo RBS Adverbio superlativo RP Partícula SYM Símbolo TO To UH Intersección VB Forma base del verbo VBD Verbo en pasado VBG Verbo en gerundio o participio presente VBN Verbo en participio pasado VBP Verbo en primera o segunda persona VBZ Verbo en tercera persona WHD Wh-determiner WP Wh-pronoun WP$ Possessive Wh-pronoun WRB Wh-adverb
Anexos
115
Anexo C. Ejemplos de estructuras gramaticales acept adas
Tabla anexo 5. Ejemplos de formulación de nombres
No. Tipo Ejemplo Considerado Comentarios
1 Nombre + Nombre
Adjetivo + Nombre
Research center Si Ninguno.
2 Determinante + Adjetivo + Nombre The semantic Web Si Ninguno.
3 Verbo + Nombre (the) Work table Si La detección de nombres
construidos juntos con un verbo
es dependiente al resultado del
análisis léxico/sintáctico.
4 Nombre + Preposición + Nombre Students of CENIDET (provenientes de) Si Ninguno.
5 Nombre + Conjunción + Nombre Research and technological development No La metodología del presente
trabajo de tesis detecta la
presencia del fenómeno de la
elipsis, y no identifica la
formación de un nombre.
Anexos
116
Tabla anexo 6. Ejemplos de formulación de verbos
No. Categoría Tipo Ejemplo Considerado
1 Verbos simples Presente simple
Presente continuo
Presente perfecto
Presente perfecto continuo
Alma has been developing ontologies of CENIDET Si
Pasado simple
Pasado continuo
Pasado perfecto
Pasado perfecto continuo
Alma had been developing ontologies of CENIDET Si
Futuro simple
Futuro continuo
Presente del futuro
Alma are developing ontologies of CENIDET
tomorrow
No
2 Verbos frasales Verbo + Preposición + Objeto
Verbo + Partícula adverbial + Objeto
Verbo + Partícula adverbial + Preposición + Objeto
Alma ran out without telling me anything No
Anexos
117
Tabla anexo 7. Ejemplos de formulación de preguntas
No. Categoría Palabra de
pregunta
Estructura Ejemplo(s) Consulta
SPARQL
Considerado Comentarios
1 Yes/No
questions
do,be,
have,
modals
Auxiliary/Modal verbs +
[Subject] + [Verbs] +
Complement
Did Alma study in
CENIDET?
Is Alma studying in
CENIDET?
Has Alma been studying in
CENIDET?
Can Alma study in
CENIDET?
ASK Si Ninguno.
2
Question-
word
questions
Who Who + [Verbs] +
Complement
Who is studying in
CENIDET?
SELECT Si Ninguno.
What,
which
What/Which + [Subject] +
[Verbs] + Complement
Which people are being
supervised by Azucena?
SELECT Si Ninguno.
Why,
when,
where
Why/When/Where +
[Verbs] + [Subject] +
Complement
Why study in CENIDET?
Where is CENIDET?
SELECT No
La metodología del trabajo de tesis
no considera el tratamiento de
preguntas espaciales y/o
temporales.
How How + [Modifier] +
[Verbs] + [Subject] +
Complement
How old are the students of
CENIDET?
N/A No
Las limitaciones de la consulta en
SPARQL no permiten contestar a
preguntas que requieran
respuestas de cantidad.
Anexos
118
Tabla anexo 8. Ejemplos de fenómenos lingüísticos en la gramática inglesa
No. Fenómeno Ejemplo Considerado Comentarios
1 Caso genitivo Which Students’ theses are about ontologies? Si Ninguno.
2 Ambigüedad (todos los tipos:
palabras u oraciones)
Which English teacher is working in CENIDET?
English teacher (teacher who teaches English)
English teacher (a teacher from Britain)
No El fenómeno de la ambigüedad no
se consideró dentro de los
alcances del trabajo de tesis.
3 Elipsis Who studies about ontologies or conceptual modeling or mobile
devices?
Who studies about ontologies or conceptual modeling and mobile
devices?
Si
No
La metodología del trabajo de tesis
no considera la presencia de
elementos coordinados disyuntivos
y copulativos dentro de la misma
consulta, la presencia de éstos
cambia el sentido semántico de la
consulta y conduce al fenómeno 2
de esta tabla.
Anexos
119
Anexo D. Resultados de la ejecución de las consulta s dentro del banco de pruebas
Tabla anexo 9. Análisis de las preguntas del banco de prueba
No. Consulta Análisis correcto
Triple tas Consulta SPARQL
1 who are the researchers in semantic web research area?
Si [ Unknown ? , is-a , Person ] [Unknown ? , are , the researchers ] [the researchers , Unknown , semantic web research area ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , are , the researchers . the researchers , Unknown , semantic web research area . }
2 who are the partners involved in AKT project? Si [ Unknown ? , is-a , Person ] [Unknown ? , are , the partners ] [the partners , involved in , AKT project ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , are , the partners . the partners , involved in , AKT project . }
3 who are the academics involved in AKT project? Si [ Unknown ? , is-a , Person ] [Unknown ? , are , the academics ] [the academics , involved in , AKT project ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , are , the academics . the academics , involved in , AKT project .
Anexos
120
} 4 What are the research areas covered by the
compendium project? Si [Unknown ? , are , the research areas ]
[the research areas , covered by , the compendium project ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , are , the research areas . the research areas , covered by , the compendium project . }
5 who are the members from southampton university?
Si [ Unknown ? , is-a , Person ] [Unknown ? , are , the members ] [the members , Unknown , southampton university ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , are , the members . the members , Unknown , southampton university . }
6 Which research area is interesting for Motta? Si [research area ? , is-a , research area ] [research area , is interesting for , Motta ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT research area ? WHERE { research area ? , is-a , research area . research area , is interesting for , Motta . }
7 which senior researcher works in project miakt? Si [senior researcher ? , is-a , senior researcher ] [senior researcher , works in , project miakt ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT senior researcher ? WHERE { senior researcher ? , is-a , senior researcher . senior researcher , works in , project miakt .
Anexos
121
} 8 which institution owns the project webonto? Si [institution ? , is-a , institution ]
[institution ? , owns , the project webonto ] PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT institution ? WHERE { institution ? , is-a , institution . institution ? , owns , the project webonto . }
9 which methods are relevant to knowledge capture?
Si [methods ? , is-a , methods ] [methods ? , are relevant , to knowledge capture ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT methods ? WHERE { methods ? , is-a , methods . methods ? , are relevant , to knowledge capture . }
10 who works in akt? Si [ Unknown ? , is-a , Person ] [Unknown ? , works in , akt ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT methods ? WHERE { methods ? , is-a , methods . methods ? , are relevant , to knowledge capture . }
11 who works at the Open university? Si [ Unknown ? , is-a , Person ] [Unknown ? , works at , the Open university ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , works at , the Open university . }
12 which kmi academics work in information extraction?
Si [kmi academics ? , is-a , kmi academics ] [kmi academics , work in , information
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
Anexos
122
extraction ] PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT kmi academics ? WHERE { kmi academics ? , is-a , kmi academics . kmi academics , work in , information extraction . }
13 who is manager of Vanessa? Si [ Unknown ? , is-a , Person ] [Unknown ? , is , manager ] [manager , Unknown , Vanessa ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , is , manager . manager , Unknown , Vanessa . }
14 who is managed by Enrico? Si [ Unknown ? , is-a , Person ] [Unknown ? , is managed by , Enrico ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , is managed by , Enrico . }
15 What publications cite AKT projects? Si [publications ? , is-a , publications ] [publications ? , cite , AKT projects ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT publications ? WHERE { publications ? , is-a , publications . publications ? , cite , AKT projects . }
16 who is the principle investigator of the AKT project?
Si [ Unknown ? , is-a , Person ] [Unknown ? , is , the principle investigator ] [the principle investigator , Unknown , the
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#>
Anexos
123
AKT project ] SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , is , the principle investigator . the principle investigator , Unknown , the AKT project . }
17 which researchers are interested in ontologies? Si [researchers ? , is-a , researchers ] [researchers ? , are interested in , ontologies ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT researchers ? WHERE { researchers ? , is-a , researchers . researchers ? , are interested in , ontologies . }
18 what are the research fellows working on the semantic web?
Si [Unknown ? , are , the research fellows ] [the research fellows , working on , the semantic web ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , are , the research fellows . the research fellows , working on , the semantic web . }
19 who is member of the Open University? Si [ Unknown ? , is-a , Person ] [Unknown ? , is , member ] [member , Unknown , the Open University ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , is , member . member , Unknown , the Open University . }
20 who are the research fellows in akt? Si [ Unknown ? , is-a , Person ] [Unknown ? , are , the research fellows ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
Anexos
124
[the research fellows , Unknown , akt ] PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , are , the research fellows . the research fellows , Unknown , akt . }
21 which secretary is related to akt? Si [secretary ? , is-a , secretary ] [secretary ? , is related , to akt ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT secretary ? WHERE { secretary ? , is-a , secretary . secretary ? , is related , to akt . }
22 who is a professor in knowledge media institute? Si [ Unknown ? , is-a , Person ] [Unknown ? , is , a professor ] [a professor , Unknown , knowledge media institute ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , is , a professor . a professor , Unknown , knowledge media institute . }
23 who is the project leader in the project scholonto?
Si [ Unknown ? , is-a , Person ] [Unknown ? , is , the project leader ] [the project leader , Unknown , the project scholonto ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , is , the project leader . the project leader , Unknown , the project scholonto .
Anexos
125
} 24 which person is the secretary in akt? Si [person ? , is-a , person ]
[the secretary , Unknown , akt ] [person ? , is , the secretary ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT person ? WHERE { person ? , is-a , person . the secretary , Unknown , akt . person ? , is , the secretary . }
25 does anybody works in Apollo? Si [anybody , works in , Apollo ] ASK { anybody , works in , Apollo }
26 which academics are being supervised by motta?
Si [academics ? , is-a , academics ] [academics ? , are being supervised by , motta ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT academics ? WHERE { academics ? , is-a , academics . academics ? , are being supervised by , motta . }
27 which research areas are related to john domingue?
Si [research areas ? , is-a , research areas ] [research areas , are related to , john domingue ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT research areas ? WHERE { research areas ? , is-a , research areas . research areas , are related to , john domingue . }
28 who is a phd student in akt? Si [ Unknown ? , is-a , Person ] [Unknown ? , is , a phd student ] [a phd student , Unknown , akt ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person .
Anexos
126
Unknown ? , is , a phd student . a phd student , Unknown , akt . }
29 which are the projects of vanessa lopez? Si [Unknown ? , are , the projects ] [the projects , Unknown , vanessa lopez ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , are , the projects . the projects , Unknown , vanessa lopez . }
30 what are the research areas in akt? Si [Unknown ? , are , the research areas ] [the research areas , Unknown , akt ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , are , the research areas . the research areas , Unknown , akt . }
31 Which is the job title of Enrico Motta? Si [Unknown ? , is , the job title ] [the job title , Unknown , Enrico Motta ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is , the job title . the job title , Unknown , Enrico Motta . }
32 Which is the research interest of John Domingue?
Si [Unknown ? , is , the research interest ] [the research interest , Unknown , John Domingue ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is , the research interest . the research interest , Unknown , John Domingue .
Anexos
127
}
33 which are the phd students in akt? Si [Unknown ? , are , the phd students ] [the phd students , Unknown , akt ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , are , the phd students . the phd students , Unknown , akt . }
37 What is the homepage address of the AKT project?
Si [Unknown ? , is , the homepage address ] [the homepage address , Unknown , the AKT project ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is , the homepage address . the homepage address , Unknown , the AKT project . }
35 Which are the publication of Motta? Si [Unknown ? , are , the publication ] [the publication , Unknown , Motta ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , are , the publication . the publication , Unknown , Motta . }
36 Is John Domingue working with knowledge management?
Si [John Domingue , working with , knowledge management ]
ASK { John Domingue , working with , knowledge management }
37 Does magpie utilize ontologies? Si [magpie , utilize , ontologies ] ASK { magpie , utilize , ontologies }
38 has john been working with ontologies? Si [john , been working with , ontologies ] ASK { john , been working with , ontologies }
39 which projects are headed by academics in knowledge media institute?
Si [projects ? , is-a , projects ] [academics , Unknown , knowledge media institute ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#>
Anexos
128
[projects ? , are headed by , academics ] SELECT DISTINCT projects ? WHERE { projects ? , is-a , projects . academics , Unknown , knowledge media institute . projects ? , are headed by , academics . }
40 Who works on AKT project in Knowledge media inst?
Si [ Unknown ? , is-a , Person ] [Unknown ? , works on , AKT project ] [AKT project , Unknown , Knowledge media inst ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , works on , AKT project . AKT project , Unknown , Knowledge media inst . }
41 Who are the members of AKT from Southampton University?
Si [ Unknown ? , is-a , Person ] [Unknown ? , are , the members ] [the members , Unknown , AKT ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , are , the members . the members , Unknown , AKT . }
41 Who is the director of the compendium project in Knowledge Media?
Si [ Unknown ? , is-a , Person ] [Unknown ? , is , the director ] [the director , Unknown , the compendium project ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , is , the director . the director , Unknown , the compendium project .
Anexos
129
}
43 who has research interest in Semantic web? Si [ Unknown ? , is-a , Person ] [Unknown ? , has , research interest ] [research interest , Unknown , Semantic web ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , has , research interest . research interest , Unknown , Semantic web . }
44 which senior researchers has research interest in ontologies?
Si [senior researchers ? , is-a , senior researchers ] [research interest , Unknown , ontologies ] [senior researchers , has , research interest ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT senior researchers ? WHERE { senior researchers ? , is-a , senior researchers . research interest , Unknown , ontologies . senior researchers , has , research interest . }
45 does anybody works on semantic web in akt? Si [semantic web , Unknown , akt ] [anybody , works on , semantic web ]
ASK { semantic web , Unknown , akt anybody , works on , semantic web }
46 Who is principle investigator of the AKT project? Si [ Unknown ? , is-a , Person ] [Unknown ? , is , principle investigator ] [principle investigator , Unknown , the AKT project ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , is , principle investigator . principle investigator , Unknown , the AKT project . }
47 What papers were written by members of AKT? Si [papers ? , is-a , papers ] [members , Unknown , AKT ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
Anexos
130
[papers ? , were written by , members ] PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT papers ? WHERE { papers ? , is-a , papers . members , Unknown , AKT . papers ? , were written by , members . }
48 which persons in akt are the phd students of john?
Si [persons ? , is-a , persons ] [persons ?, Unknown , akt ] [the phd students , Unknown , john ] [persons ? , are , the phd students ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT persons ? WHERE { persons ? , is-a , persons . persons ?, Unknown , akt . the phd students , Unknown , john . persons ? , are , the phd students . }
49 who works in akt and is supervised by motta? Si [ Unknown ? , is-a , Person ] [Unknown ? , works in , akt ] [ Unknown ? , is-a , Person ] [Unknown ? , is supervised by , motta ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , works in , akt . Unknown ? , is-a , Person . Unknown ? , is supervised by , motta . }
50 Who has interested in semantic area and is related with motta?
Si [ Unknown ? , is-a , Person ] [Unknown ? , has interested in , semantic area ] [ Unknown ? , is-a , Person ] [Unknown ? , is related with , motta ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , has interested in , semantic area .
Anexos
131
Unknown ? , is-a , Person . Unknown ? , is related with , motta . }
51 who are the phd students in semantic services and are supervised by john?
Si [ Unknown ? , is-a , Person ] [Unknown ? , are , the phd students ] [ Unknown ? , is-a , Person ] [Unknown ? , are supervised by , john ] [the phd students , Unknown , semantic services ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , are , the phd students . Unknown ? , is-a , Person . Unknown ? , are supervised by , john . }
52 which projects are about ontologies and the semantic web?
Si [projects ? , is-a , projects ] [projects ? , are about , ontologies ] [projects ? , are about , the semantic web ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT projects ? WHERE { projects ? , is-a , projects . projects ? , are about , ontologies . projects ? , is-a , projects . projects ? , are about , the semantic web . }
53 who is interested in ontologies and is working in akt?
Si [ Unknown ? , is-a , Person ] [Unknown ? , is interested in , ontologies ] [ Unknown ? , is-a , Person ] [Unknown ? , is working in , akt ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , is interested in , ontologies . Unknown ? , is-a , Person . Unknown ? , is working in , akt . }
54 in which projects is enrico motta working on? No considerada 55 which universities is Knowledge Media Institute
collaborating with? (reformulada) Si [universities ? , is-a , universities ]
[universities ? , is collaborating with , PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
Anexos
132
which universities is collaborating with Knowledge Media Institute?
Knowledge Media Institute ] PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT universities ? WHERE { universities ? , is-a , universities . universities ? , is collaborating with , Knowledge Media Institute . }
56 How many persons work on AKT project? No considerada 57 Which Universities does Knoledge media
institute collaborate with? (reformulada) Which Universities collaborate with Knoledge media institute?
Si [Universities ? , is-a , Universities ] [Universities ? , collaborate with , Knoledge media institute ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Universities ? WHERE { Universities ? , is-a , Universities . Universities ? , collaborate with , Knoledge media institute . }
58 How many members the buddy-space project has?
No considerada
59 How many pewrsons the Project webonto has? No considerada 60 How many senior researchers are there in AKT? No considerada 61 Which knowledge technologies institution
knowledge media institute has produced? (reformulada) Which knowledge technologies institution has produced knowledge media institute?
Si [knowledge technologies institution ? , is-a , knowledge technologies institution ] [knowledge technologies institution , has produced , knowledge media institute ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT knowledge technologies institution ? WHERE { knowledge technologies institution ? , is-a , knowledge technologies institution . knowledge technologies institution , has produced , knowledge media institute . }
62 which technologies Maria has produced? (reformulada) which technologies has produced Maria?
Si [technologies ? , is-a , technologies ] [technologies ? , has produced , Maria ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT technologies ? WHERE { technologies ? , is-a , technologies .
Anexos
133
technologies ? , has produced , Maria . }
63 which publications institution kmi had published? (reformulada) which publications had published institution kmi?
Si [publications ? , is-a , publications ] [publications ? , had published , institution kmi ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT publications ? WHERE { publications ? , is-a , publications . publications ? , had published , institution kmi . }
64 What software systems are produced in AKT project?
Si [software systems ? , is-a , software systems ] [software systems , are produced in , AKT project ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT software systems ? WHERE { software systems ? , is-a , software systems . software systems , are produced in , AKT project . }
65 are there any project founded by eprsc? No considerada 66 in which research areas is enrico motta working
on? No considerada
67 are there any phd student working in dotkom? No considerada 68 Give me all the projects related to semantic web. No considerada 69 List the research staff members related to akt. No considerada 70 Show all the research areas related to akt. No considerada 71 Tell me all the planet news related to vanessa. No considerada 72 which publications Maria Vargas had published?
(reformulada) which publications had published Maria Vargas?
Si [publications ? , is-a , publications ] [publications ? , had published , Maria Vargas ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT publications ? WHERE { publications ? , is-a , publications . publications ? , had published , Maria Vargas . }
73 Give me all the publications produced for akt. No considerada 74 Is John Domingue a Phd student? No considerada
Anexos
134
75 is motta an academics? No considerada 76 Does John Doo have any relation to AKT
project? No
77 enrico motta works in ibm? (reformulada) Does enrico motta work in ibm?
Si [enrico motta , work in , ibm ] ASK { enrico motta , work in , ibm }
78 Ontologies are a subarea of knowledge? No considerada 79 John Domingue has interest in ontologies? No considerada 80 motta works in ibm? (reformulada)
Does motta work in ibm?
Si [motta , work in , ibm ] ASK { motta , work in , ibm }
81 Ortenz is the secretary of motta? No considerada 82 Is ortenz the secretary of John Domingue? No considerada 83 Has john domingue interest in ontologies? No 84 Are ontologies a subarea of knowledge? No considerada 85 Are the ontologies a subarea of knowledge
reuse? No considerada
86 is ortenz the personal assistant of enrico mota? No considerada 87 is john domingue a research staff in knwoledge
media institute? No considerada
88 Who are the academics staff members of dotkom from knowledge media inst?
Si [ Unknown ? , is-a , Person ] [Unknown ? , are , the academics staff members ] [the academics staff members , Unknown , dotkom ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT Unknown ? WHERE { Unknown ? , is-a , Person . Unknown ? , are , the academics staff members . the academics staff members , Unknown , dotkom . }
89 how many projects are headed by researchers in the open university?
No considerada
90 which academics are project members in akt? No 91 which academics are the project members of akt
from southampton university? No
92 which projects include senior researchers from akt?
Si [projects ? , is-a , projects ] [senior researchers , Unknown , akt ] [projects ? , include , senior researchers ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT projects ? WHERE { projects ? , is-a , projects .
Anexos
135
senior researchers , Unknown , akt . projects ? , include , senior researchers . }
93 tell me all the publications written by researchers in akt?
No considerada
94 are there any publication written by researchers in ocml?
No considerada
95 Are there any publications in knowledge media institute related to semantic web service?
No considerada
96 are there any project in knowledge media institute related to semantic web?
No considerada
97 which projects on language are sponsored by eprsc?
No
98 which researchers in knowledge media inst has interest in artificial intelligence?
No
99 which project from akt are related to semantic web? (reformulada) which projects from akt are related to semantic web?
Si [projects ? , is-a , projects ] [projects ?, Unknown , akt ] [projects ? , are related to , semantic web ]
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX owl: <http://www.w3.org/2002/07/owl#> SELECT DISTINCT projects ? WHERE { projects ? , is-a , projects . projects ?, Unknown , akt . projects ? , are related to , semantic web . }
100 are there any publication from researchers working in hypermedia?
No considerada
101 which projects in semantic web are about ontologies?
No
102 does anybody in akt works on semantic web? No 103 which projects are funded by eprsc and are
about semantic web? No
104 does anybody works on akt and on the semantic web?
No
105 who is interested in ontologies or in the semantic web?
No
Anexos
136