TESIS DE MAESTRÍA EN CIENCIAS - CENIDET - … Carlos Martin... · preparación y formación que adquirí durante mis estudios de posgrado. Esta tesis de ... análisis y discriminación

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-4. Ejecución del caso de prueba: ironLP-02-03 .................................................................. 82


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-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




viii


Tabla 5-10. Resultados del caso de prueba ironLP-03-03 (tLp) ....................................................... 86






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


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.


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.


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:


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:


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.


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.


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.


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.


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.


10

Capítulo 2. Marco teórico

11


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.


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).


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


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.


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.


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.


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


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.


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 )


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


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.


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.


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.


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).


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á


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.


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.


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


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.


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.


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.


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


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).


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:


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:


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


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.


38

Capítulo 4. Metodología de solución

39


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.


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:


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.


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.


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:


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


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:


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:


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):


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:


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


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


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?


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:


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:


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).


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:


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 ]


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 , Unknown , Azucena ]

[ students , Unknown , Azucena]

[ ontologies , Unknown , CENIDET ]

[ students , are working on , ontologies ]

[ students , are generating , ontologies ]


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:


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:


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:


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:


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


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.


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.


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.


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.


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.


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


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.


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.


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”.




4) La herramienta informa al usuario que su consulta contiene un caso genitivo.


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.



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


“Execute”.




4) La herramienta informa al usuario que su consulta contiene un caso genitivo y

reescribe la expresión.


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.


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


“Execute”.



71



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.


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.


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


“Execute”.




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.



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.


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


“Execute”, y luego “Pattern”.


“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”.


La herramienta muestra todas las tripletas generadas a partir del análisis de la consulta

del usuario.


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.





c) Proceso





ella.






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.



74




c) Proceso





ella.



su consulta dentro del cuadro de texto “Triplets”.



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.





c) Proceso




75



ella.



su consulta dentro del cuadro de texto “Triplets”.



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.





c) Proceso





ella.



76





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.


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.




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”.



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


que contenga el fenómeno lingüístico de la elipsis, formado mediante una conjunción

coordinada disyuntiva.





c) Proceso










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


78


con verbo auxiliar.





c) Proceso










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 “’?”.


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


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).


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:


Cargo:

Autor


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.


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:


Cargo:

Autor


82


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:


Cargo:

Autor


83


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).


Observaciones:

- El usuario tiene la posibilidad de modificar el resultado generado por la herramienta sin problema alguno.

Responsable:


Cargo:

Autor


84


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).


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:


Cargo:

Autor


85


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)


Observaciones:

- La relación entre los dos objetos que conforman el caso genitivo es desconocida (“Unknown”).

Responsable:


Cargo:

Autor


86


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)


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:


Cargo:

Autor


87


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)


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:


Cargo:

Autor


88


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).


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:


Cargo:

Autor


89


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).


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:


Cargo:

Autor


90


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.


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.


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:


Cargo:

Autor


91


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).


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.


ASK{ Carlos , been working on , NLP }

Responsable:


Cargo:

Autor


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


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:


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):


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.


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


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.


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


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


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 ]


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 ]


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

Documents

TESIS DE MAESTRÍA EN CIENCIAS - CENIDET - … Carlos Martin... · preparación y formación que adquirí durante mis estudios de posgrado. Esta tesis de ... análisis y discriminación