UNIVERSIDAD CATÓLICA ANDRÉS BELLO

FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA INFORMATICA

SISTEMA DE PREGUNTA-RESPUESTA ORIENTADO

AL DOMINIO TURÍSTICO EN VENEZUELA PARA LA
EMPRESA MOMENTUM LAB, C.A.

TRABAJO INSTRUMENTAL DE GRADO

presentado ante la

UNIVERSIDAD CATÓLICA ANDRÉS BELLO

como parte de los requisitos para optar al título de

INGENIERO EN INFORMÁTICA

REALIZADO POR JESÚS HERRERA

PROFESOR GUÍA JESÚS LÁREZ

FECHA NOVIEMBRE, 2017

 Dedicatoria

A mis padres Pedro y Belinda por su amor y apoyo incondicional en todo momento, a
mi hermana Mary y mi hermano Pedro F por apoyarme y cuidarme siempre, a mi
sobrino Fabián Alejandro por alegrarme los días y a Dios Todopoderoso por guiarme
y acompañarme en cada etapa de mi vida.
 Agradecimientos

A Dios por guiarme y cuidarme siempre.

A mis padres Pedro Herrera y Belinda D’Ambrosi por todo el apoyo y amor
que me han dado durante toda mi vida, por todo lo que me han enseñado y los valores
que han inculcado en mí.

A mi hermana María Herrera y mi hermano Pedro F Herrera por cuidarme

siempre y querer lo mejor para mi desde que nací. A mi sobrino Fabián Alejandro por
alegrarme los días y acompañarme mientras escribía el informe y a mí cuñado Fabián
por sus consejos y apoyo. A mi familia en general.

A mis amigos Lino, Patricia, Chikito, Yanir, Miguel, José, Rafa, Marianny,
Vicky, Enrique, Cabral y Ezio por acompañarme durante estos cinco años y hacer de
la universidad momentos únicos e inolvidables.

A mi tutor académico y profesor Jesús Lárez por su apoyo y guía durante el

desarrollo de este proyecto, por incentivarme a explorar nuevas tecnologías y por
todos los conocimientos que durante la carrera me enseño para mi formación
profesional. A todos los profesores que me enseñaron sus conocimientos y en especial
a los profesores María Cora y Franklin Bello por apoyarme y servir de guía durante
estos cinco años.

A Mohamed El Saheli por apoyarme y brindar la oportunidad de realizar este

proyecto en la empresa Momentum Lab, C.A la cual me abrió las puertas para formar
mi primera experiencia profesional. A todos en la empresa Momentum Lab, C.A
Ibelice, Dorian, Nicolás Q, Manfred, Omar, El pibe, Robert, Jhonger, Alejandra,
Kevin, Betania, Enmy, Nancy, Jyfer, Jhosmiled, Eduardo, Cols, Nader, Miguel, John
y Nicolás.

Finalmente, gracias a todos los que de alguna forma u otra colaboraron en la

realización de este proyecto.
 Índice de Contenido

pp.

Dedicatoria ................................................................................................................... II

Agradecimientos ......................................................................................................... III

Índice de Contenido .................................................................................................... IV

Indice de Figuras ...................................................................................................... VIII

Indice de Tablas ........................................................................................................... X

Resumen ...................................................................................................................... XI

Introducción .................................................................................................................. 1

CAPÍTULOS

I. El Problema................................................................................................................ 3

Planteamiento del Problema ...................................................................................... 3

Solución Propuesta .................................................................................................... 6

Objetivos ................................................................................................................... 7

Objetivo general. ................................................................................................... 7

Objetivos específicos. ........................................................................................... 7

Alcance ...................................................................................................................... 7

Limitaciones .............................................................................................................. 8

Justificación............................................................................................................... 8

II. Marco Teórico ........................................................................................................ 10

La Empresa.............................................................................................................. 10

Descripción de la empresa. ................................................................................. 10

Misión. ................................................................................................................ 10

iv
 Visión. ................................................................................................................. 10

Valores. ............................................................................................................... 11

Estructura organizativa. ...................................................................................... 11

Antecedentes ........................................................................................................... 12

Bases Teóricas ......................................................................................................... 13

Asistentes digitales. ............................................................................................. 14

Humanización de la tecnología. .......................................................................... 15

Experiencia centrada en el usuario. ..................................................................... 16

Web semántica. ................................................................................................... 17

Identificador uniforme de recursos (URI). ...................................................... 19

Marco de descripción de recursos (RDF)........................................................ 19

RDF Schema (RDFS). ..................................................................................... 20

Lenguaje de Ontologías Web (OWL). ............................................................ 20

Lenguaje de Ontologías Web 2 (OWL 2). ...................................................... 21

Representación del conocimiento. ...................................................................... 21

Ontología. ........................................................................................................ 22

Base de conocimiento. .................................................................................... 23

Acceso a datos mediante ontologías (OBDA). ................................................... 24

Procesamiento del lenguaje natural (NLP). ........................................................ 25

Sistema de pregunta y respuesta. ........................................................................ 25

III. Marco Metodológico ............................................................................................. 27

Tipo de Investigación .............................................................................................. 27

v
 Según el Nivel de Investigación.......................................................................... 27

Según el Diseño de la Investigación. .................................................................. 27

Técnicas e Instrumentos de Recolección de Datos ................................................. 28

Metodología de Desarrollo ...................................................................................... 28

Etapas. ................................................................................................................. 30

Actividades.......................................................................................................... 30

Herramientas. ...................................................................................................... 32

Roles.................................................................................................................... 35

Product Owner ................................................................................................ 35

Development Team. ........................................................................................ 35

Metodología para la Construcción de Ontologías ................................................... 35

Metodología para la Construcción de Sistemas Basados en Ontologías para el

Acceso a Datos ........................................................................................................ 38

Procedimiento Metodológico .................................................................................. 40

IV. Resultados ............................................................................................................. 42

Estudio del Funcionamiento y las Tecnologías Empleadas en los Sistemas

Pregunta-Respuesta Actuales .................................................................................. 42

Definición de los requerimientos ............................................................................ 45

Levantamiento de requerimientos. ...................................................................... 45

Release planning. ................................................................................................ 45

Diseño y construcción del sistema de búsqueda de respuesta ................................ 47

Sprint backlog. .................................................................................................... 48

Codificación. ....................................................................................................... 56

vi
 Representación del conocimiento. .................................................................. 56

Construcción de una ontología del dominio turístico en Venezuela. .......... 56

Aplicación del paradigma OBDA. .............................................................. 63

Procesamiento de la consulta en lenguaje natural. .......................................... 67

Módulo de soporte para preguntas. ................................................................. 73

Caso de estudio. .......................................................................................... 73

Validación del sistema ............................................................................................ 76

V. Conclusiones y Recomendaciones ......................................................................... 78

Conclusiones ........................................................................................................... 78

Recomendaciones .................................................................................................... 79

Referencias Bibliográficas .......................................................................................... 81

Anexos ........................................................................................................................ 87

Anexo A. Documento de contexto con los requerimientos iniciales del sistema ... 88

Anexo B. Documentación del API Rest .................................................................. 90

Anexo C. Preguntas realizadas y resultados obtenidos durante el caso de estudio. 97

Glosario ..................................................................................................................... 115

vii
 Índice de Figuras

Figura pp.

1. Estructura Organizativa de la empresa Momentum Lab, C.A. ............................... 12

2. Pila de la web semántica ......................................................................................... 18

3. Etapas de la metodología Momentum.. ................................................................... 29

4. Actividad de Sprint Planning .................................................................................. 33

5. Etapa inicial ............................................................................................................. 34

6. Etapa Momentum .................................................................................................... 34

7. Arquitectura inicial del sistema con las herramientas utilizadas ............................ 49

8. Vista de la base de datos del sistema Travelea para el sistema de preguntas y

respuestas. ................................................................................................................... 50

9. Arquitectura del sistema correspondiente a la segunda iteración. .......................... 52

10. Fórmulas para el cálculo del Recall y Precision del sistema ................................ 53

11. Diseño preliminar del módulo para la visualización de preguntas no respondidas

en el sistema administrativo. ....................................................................................... 55

12. Diseño preliminar del módulo para la visualización del rendimiento del sistema
administrativo.............................................................................................................. 55

13. Diseño preliminar del módulo para la realización de preguntas desde el sistema
administrativo.............................................................................................................. 56

14. Extracto de taxonomía de servicios turísticos clasificada por Dulcey y Ramos ... 61

15. Extracto de la taxonomía resultante de sitios de interés luego de aplicar el

enfoque combinado en la jerarquización de las clases ................................................ 61

16. Taxonomía de localidades ..................................................................................... 62

17. Conexión con base de datos .................................................................................. 64

viii
18. Extracto de mapas de datos con conceptos y relaciones en la ontología .............. 64

19. Consulta en SPARQL y resultados de la pregunta de competencia ¿Que playas

hay en Margarita? ........................................................................................................ 65

20. Configuración del repositorio RDF....................................................................... 67

21. Configuración de los componentes para el sistema OBDA .................................. 67

22. Consulta SPARQL para la pregunta ¿Qué playas hay en Margarita? ................... 69

23. Patrón: ¿Qué {concepto} hay en {localidad}? ...................................................... 69

24. Patrón: ¿Dónde puedo comer {especialidad}? ...................................................... 70

25. Ejemplo de pregunta: ¿Dónde puedo comer sushi? enviada al servidor ............... 70

26. Ejemplo de pregunta: ¿Qué playas hay en Margarita? enviada al servidor .......... 71

27. Consulta SPARQL generada a partir de la pregunta: ¿Dónde puedo comer sushi?
..................................................................................................................................... 71

28. Consulta SPARQL generada a partir de la pregunta: ¿Que playas hay en

Margarita? ................................................................................................................... 72

29. Módulo de pruebas del sistema administrativo. .................................................... 74

30. Módulo de estadísticas del sistema administrativo ............................................... 74

31. Módulo de visualización de preguntas no contestadas ......................................... 76

ix
 Índice de Tablas

Tabla pp.

1. Actividades involucradas en la Metodología Momentum ...................................... 31

2. Herramientas utilizadas en la metodología Momentum.......................................... 32

3. Pasos de la metodología Ontology Development 101. ........................................... 37

4. Pasos de la metodología Ontology Development 101 (continuación). ................... 38

5. Cuadro con los aspectos de funcionamiento de los sistemas de pregunta y respuesta

estudiados. ................................................................................................................... 43

6. Cuadro con los aspectos de funcionamiento de los sistemas de pregunta y respuesta

estudiados (continuación)............................................................................................ 44

7. Información de historias de usuario ........................................................................ 47

8. Extracto de preguntas de competencia .................................................................... 58

9. Extracto de clases definidas y su descripción ......................................................... 60

10. Extracto de propiedades y sus facetas ................................................................... 62

11. Lista de validación de funcionalidades ................................................................. 77

x
 UNIVERSIDAD CATÓLICA ANDRÉS BELLO
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA INFORMATICA

Sistema de Pregunta-Respuesta Orientado al Dominio Turístico en Venezuela

para la Empresa Momentum Lab, C.A.

Realizado por: Jesús Herrera

Profesor guía: Jesús Lárez
Fecha: Noviembre, 2017.

RESUMEN

A continuación se presenta el desarrollo de una herramienta, para la empresa

Momentum Lab C.A, cuyo objetivo es responder preguntas realizadas en lenguaje
natural, con la cual se podrán consultar datos del ámbito turístico en Venezuela
contenidos en una base de datos relacional a través de una consulta en lenguaje
natural. Para ello, se utilizó una ontología para la representación del conocimiento, la
aplicación del paradigma de acceso a datos mediante ontologías (OBDA, por sus
siglas en inglés) y el enfoque basado en patrones para el análisis de la pregunta en
lenguaje natural. El sistema, fue desarrollado empleando la metodología Momentum
Methodology, propiedad de la empresa Momentum Lab C.A. Como resultado final se
obtuvo el sistema de pregunta-respuesta que forma parte esencial de uno de los
productos de la empresa llamado Travelea.

Descriptores: turismo, sistema de pregunta y respuesta, ontología, acceso a

datos mediante ontologías, web semántica.

xi
 1

Introducción

El uso del lenguaje natural como medio de interacción con los computadores
es una de las áreas de la ingeniería informática que más crecimiento ha alcanzado en
los últimos años, principalmente debido al auge del internet de las cosas y los
dispositivos móviles inteligentes que ha ocasionado que una gran cantidad de
personas tengan interacción diariamente con sistemas informáticos, en los que se
buscan la mejor experiencia de usuario.

Una de las áreas que se ha vuelto más popular en los últimos años para hacer
posible este tipo de interacción es el llamado Procesamiento del Lenguaje Natural
(NLP, por sus siglas en ingles). Bird et al. (2009) lo definen como un área que
involucra manipular computacionalmente el lenguaje natural y que involucra
“entender” expresiones humanas, hasta el punto de poder ofrecer una respuesta útil.
De esta manera, ofrece una serie de mecanismos que permiten la interacción entre el
lenguaje humano y las maquinas.

En conjunto con esta tecnología, el área de representación del conocimiento y

la web semántica han ido evolucionando paralelamente. De manera que, permiten dar
significado a información estructurada o no estructurada presente en la web, base de
datos o diferentes fuentes de datos, para así, poder brindar una mayor semántica a los
datos contenidos en los sistemas de información tradicionales. Así, la convergencia
de estas tecnologías podría apoyar al proceso de interacción entre humanos y
maquinas en lenguaje natural.

Actualmente, en Venezuela, haciendo énfasis en el sector turístico, se sufre un

déficit de soluciones hechas en el país que utilicen las tecnologías mencionadas
anteriormente. Sobre ello, Dulcey y Ramos (2016) mencionan que es apoyado por los
portales web y Camacho (s.f) en un estudio de mercado realizado sobre aplicaciones
turísticas afirma que existen pocas aplicaciones de guías turísticas para teléfonos
inteligentes y tabletas en Venezuela. Por lo cual, los turistas se ven en la necesidad de
consultar diversos sitios en la web, guías turísticas, entre otros medios de información
 2

para conocer sobre el país, el cual posee una enorme variedad de destinos turísticos.
Esto, utilizando los métodos convencionales de búsqueda de información como lo son
la navegación por el sitio y búsqueda por palabras claves.

La empresa Momentum Lab, C.A es una empresa dedicada al desarrollo de

soluciones de software innovadoras y en la actualidad busca apoyar e incentivar el
turismo en Venezuela a través del desarrollo de una aplicación que apoye al turista
durante las distintas etapas de su viaje utilizando tecnología de vanguardia.

Es por esta razón que a continuación se presenta, este trabajo de grado, cuyo
propósito es el desarrollo de una herramienta que proporcione una alternativa a los
métodos de búsqueda convencionales al momento de consultar información orientada
al dominio turístico en Venezuela, de tal forma que se pueda mejorar la experiencia
que tienen los usuarios al momento de realizar las búsquedas de información,
brindando la posibilidad de realizar preguntas en lenguaje natural como parte de la
aplicación Travelea, un desarrollo de la empresa Momentum Lab, C.A. Así mismo,
con el desarrollo de esta herramienta se estaría colaborando e incentivando con el
impulso tecnológico en el sector turístico del país.

El informe está estructurado en cinco capítulos que detallan cómo se logró

concretar este proyecto. En el capítulo I, se presenta el problema, los objetivos, la
justificación, el alcance y las limitaciones. En el capítulo II, se expone el marco
teórico en donde se presentan los antecedentes y bases teóricas. En el capítulo III, se
detalla los aspectos del marco metodológico utilizados para la realización del
proyecto. En el capítulo IV se muestran los resultados obtenidos y en el capítulo V se
discuten las conclusiones y recomendaciones que se llegaron al final de la
elaboración del proyecto. Finalmente, se incluyen las referencias bibliográficas y
anexos

.
 CAPÍTULO I

El Problema

Planteamiento del Problema

Venezuela se considera un país con potencial turístico, debido a la gran

variedad de paisajes y destinos que posee. Debido a esto, García (2014) comenta que
pudiese convertirse en una importante actividad económica en el país. Actualmente,
el uso de la tecnología ha permitido tener un mayor acceso a la información a los
usuarios, sobre ello, Dulcey y Ramos (2016) afirman que el turismo es apoyado por
tecnologías emergentes, a través de las TICs (Tecnologías de la información y la
Comunicación) y de la IA (Inteligencia Artificial).

Estas tecnologías ofrecen al usuario herramientas que apoyan la experiencia

que tiene una persona al momento de realizar turismo. Sin embargo, en Venezuela el
sector turístico parece ser poco apoyado por las tecnologías mencionadas
anteriormente. Las fuentes de información turística que posee son variadas, tal es el
caso de medios impresos, como, por ejemplo: periódicos, revistas, libros y medios
electrónicos con el uso portales web (Dulcey y Ramos, 2016); en el caso de este
último, la búsqueda de información en ellos ocasiona que las personas inviertan
mucho tiempo tratando de ubicar toda la información que necesitan debido a las
técnicas de búsquedas utilizadas.

Dentro de los métodos de búsqueda de contenido más comunes utilizados por

las personas, se pueden evidenciar dos de ellos: el primero, basado en navegación por
el sitio, en el cual la información que se encuentra disponible está distribuida en
diversos documentos del portal web. El segundo, con el uso de “Buscadores de
portal”, los cuales son clasificados por Fernández (s.f) como un tipo de motor de
 4

búsqueda basado en preferencias o palabras claves, donde sólo realiza búsquedas de

información dentro del portal, lo que ocasiona que el usuario deba hacer uso de un
lenguaje controlado para que el buscador pueda consultar con sus documentos, y
retornar aquellos que contengan dichas palabras claves. Vállez (2009) define el
lenguaje controlado “como un subconjunto del lenguaje natural con algunas
restricciones gramaticales y léxicas” (p.7). De las situaciones descritas, Inbenta
Technologies Inc. (2012) manifiesta que:

En una encuesta sobre el estado de búsqueda actual desde el punto de

vista de la experiencia del usuario (sondeo de 1.001 personas adultas
estadounidenses elaborado por Kelton Research) se llegaron a las
siguientes conclusiones:

 El 65,4% de los encuestados afirma haber empleado dos o más

horas seguidas buscando información específica en buscadores.

 El 72,3% experimentaron “cansancio en las búsquedas” cuando

intentaban encontrar la información en la web.

 El 75,1% de aquellos que experimentaron cansancio afirma que

se levantó y dejó el ordenador sin encontrar la información que
buscaba.

 El 78% desearía que los buscadores “les leyeran la mente” y

que ofrecieran los resultados esperados.

Al mencionar las situaciones típicas al momento de realizar búsqueda de

información, surge la pregunta ¿Los computadores podrían “entender” (Berners,
2001, p.1) lo que el usuario está buscando, de manera que mejore la experiencia del
usuario al realizar búsquedas de información?

En la actualidad, los sitios web emplean el Lenguaje de Marcado Para

Hipertextos (HTML) para la construcción de los contenidos de la web (Mozilla
Developer Network, 2005-2017). De esta manera, la información es presentada al
usuario en un formato entendible, sin embargo, para el computador no tiene
significado.
 5

En resumen, los contenidos de la web están diseñados de tal manera que

puede ser comprendido por un humano, pero el computador, no puede “entender”
(Berners, 2001, p.1) la información contenida. Es por ello que, Berners-Lee et al
(2001) presenta el concepto de la web semántica, “no como una web separada, sino
como una extensión de la actual, en la cual la información se relaciona a un
significado bien definido que permite trabajar en cooperación a las personas con
computadoras. “(p.1). Así pues, la tecnología de web semántica se preocupa por el
significado y no por la estructura de la información, a diferencia de las tecnologías de
la información actuales.

Además, al estar enfocada en el significado, la búsqueda de información se ve

beneficiada. Así, cualquier usuario en internet podría encontrar respuestas a sus
preguntas de forma más rápida y sencilla (Luzmila Pro, 2010).

Por otra parte, Vállez (2007) afirma que “El uso de lenguaje natural en la
recuperación de la información puede favorecer el acceso a los contenidos de la web
semántica, ya que a los usuarios les resulta más cómodo y ágil usar su forma habitual
de expresión” (como se cita en Olvera y Robinson, 2010). Por lo tanto, no poder
interactuar con las aplicaciones de manera natural, como si se tratase de un guía
turístico digital a través de un buscador, que brinde la posibilidad de realizar
consultas en un lenguaje no estructurado, hace que se evidencie la necesidad del uso
de técnicas de inteligencia artificial, como por ejemplo, procesamiento de lenguaje
natural (PLN) y aprendizaje por computador, con el fin de brindar una mejor
experiencia al usuario al momento de realizar búsquedas dentro de la aplicación, en
sustitución a las búsquedas por palabras claves, preguntas frecuentes o navegación
por el sitio.

No obstante, en Venezuela la mayoría de los portales web emplean

buscadores basados en palabras claves o preferencias. Los beneficios que aportaría
una herramienta con estas características, basada en un sistema capaz de responder
preguntas formuladas en lenguaje natural por los usuarios, se podría traducir en
 6

ofrecer una mejor experiencia al momento de planificar y consultar información de

sitios de interés, mejor interacción entre humano-computadora, información turística
en un solo lugar evitando las búsquedas en diferentes sitios a través de meta
buscadores.

En Guayana, la empresa Momentum Lab, C.A dedicada al desarrollo de

productos innovadores y soluciones informáticas, quiere apoyar al sector turístico en
Venezuela. Para ello, proponen la creación de una herramienta que permita mejorar la
experiencia de las personas en la búsqueda de información turística en Venezuela
haciendo uso de las tecnologías mencionadas anteriormente.

Sobre lo antes planteado surge la siguiente interrogante, ¿Qué herramienta

podría apoyar y mejorar la experiencia de los usuarios en la búsqueda de información
turística?

Solución Propuesta

Se propone como solución al problema planteado, el desarrollo de un sistema

de búsqueda de respuesta que reciba como entrada una consulta realizada por el
usuario en lenguaje natural y retorna una o varias respuestas que puedan satisfacer las
expectativas de la pregunta realizada. Para ello, se deberán usar diferentes técnicas de
procesamiento de lenguaje natural para el análisis sintáctico de la pregunta y el uso de
una base de conocimiento que permita representar el dominio turístico en Venezuela.

Además, se deberá aplicar un análisis semántico mediante que permita

transformar la consulta en lenguaje natural (no estructurado) a un lenguaje de
consulta (estructurado) que pueda ser utilizado para la obtención de la información en
la base de conocimiento y la base de datos.
 7

Objetivos

Objetivo general.

Desarrollar un sistema de pregunta-respuesta orientado al dominio turístico en

Venezuela para la empresa Momentum Lab, C.A.

Objetivos específicos.

1. Estudiar los métodos y técnicas empleadas en los sistemas de pregunta-

respuesta.
2. Definir los requerimientos para la construcción del sistema de búsqueda de
respuesta, con base en el análisis de las tecnologías estudiadas y
necesidades del cliente.
3. Diseñar el sistema cumpliendo con los requerimientos definidos.
4. Construir un sistema de búsqueda de respuesta orientado al dominio
turístico en Venezuela.
5. Validar el sistema construido tomando en cuenta los requisitos iniciales.

Alcance

La solución propuesta consiste en un proyecto de ingeniería informática, en el

área de ingeniería de software, donde se desarrollará un sistema de búsqueda de
respuesta que sirva de apoyo para la obtención de información de sitios turísticos en
Venezuela, y mejore la experiencia de usuario a través del uso del lenguaje natural
para la formulación de la pregunta; él mismo ha de cubrir las siguientes etapas de
desarrollo: análisis, diseño, construcción y pruebas, las cuales están representadas en
la metodología de desarrollo utilizada por la empresa Momentum Lab, C.A. Se
deberá hacer uso de la Metodología Momentum, ya que es un estándar utilizado por
la empresa para el desarrollo de sistemas.
 8

Es importante acotar que para la representación del conocimiento se utilizará

una ontología y el proceso de validación se realizará en base al conocimiento
contenido.

Su finalidad es ofrecer a Momentum Lab C.A un acercamiento al

funcionamiento de los sistemas de búsqueda de respuesta, que podría ser
implementado como un módulo en proyectos futuros.

Limitaciones

No se encontraron obstáculos que afectaron el normal desenvolvimiento del

proyecto.

Justificación

El sector turístico en Venezuela es un área que posee grandes oportunidades

para diversos sectores gracias a la variedad de destinos que el país posee. En el caso
del campo tecnológico, el apoyo que brinda al turismo en Venezuela es a través de
portales web que ofrecen información turística según Dulcey y Ramos (2015) y con
aplicaciones móviles (Camacho, s.f). Sobre esta premisa, la empresa Momentum Lab,
C.A propuso el desarrollo de una herramienta que integre diversas tecnologías
innovadoras en el sector turístico, como lo son: sistemas de perfilado, de
recomendación y el uso del lenguaje natural como medio de interacción. Esta última
funcionalidad, es una de las áreas de las tecnologías emergentes que mayor atención
tiene, esto, como consecuencia de la gran demanda que los dispositivos móviles y el
campo del internet de las cosas (IoT) ha tenido en los últimos años, lo cual permite
poder comunicarse con estos dispositivos de una manera natural, más humana.

Así pues, el uso de la manera en que las personas se comunican diariamente,

podría mejorar la experiencia que el usuario tiene al momento de buscar información
turística en el país. De esta manera, se brinda una alternativa a las herramientas
tecnológicas hechas en Venezuela que ofrecen información turística, pero que hacen
 9

uso de métodos de búsqueda convencionales como lo son la navegación por el sitio,

palabras claves o preguntas frecuentes. Entre otros beneficios que aportaría la
herramienta destacan:

 El apoyo al sector turístico del país. Haciendo uso de tecnologías emergentes.

 Brindar al usuario la posibilidad de consultar datos turísticos usando su
lenguaje cotidiano.
 Mejorar la experiencia de usuario al momento de búsquedas de información.
 Explorar nuevos campos de la tecnología mediante el uso de herramientas que
apoyen al desarrollo tecnológico del país.
 CAPÍTULO II

Marco Teórico

En este capítulo, se presenta una reseña de la empresa, los antecedentes de la

investigación y las bases teóricas que sustentaron su realización

La Empresa

Documentos internos de Momentum Lab, C.A (2016) muestran los siguientes

aspectos de la empresa.

Descripción de la empresa.

Empresa establecida en Ciudad Guayana dedicada al desarrollo de soluciones

únicas y rentables para productos en el área de desarrollo web, aplicaciones móviles y
emprendimientos.

Misión.

Momentum Lab, C.A es una organización dedicada al desarrollo de software

que brinda soluciones informáticas innovadoras a sus clientes; diferenciándolos por la
excelencia de un equipo de alto desempeño y la generación de valor a través de la
creatividad, compromiso y el uso de tecnologías de vanguardia.

Visión.

Momentum Lab, C.A tiene como visión ser una empresa reconocida a nivel
global por ofrecer soluciones de software innovadoras propias y a la medida de sus
clientes; ampliando la influencia hacia otros sectores de desarrollo tecnológico.
 11

Valores.

 Compromiso: siendo consecuentes con la promesa de calidad hacia los

clientes, satisfaciendo sus expectativas y siempre cumpliendo con lo
acordado.
 Innovación: basada no solo en el desarrollo de nuevos productos, sino de
nuevas tecnologías.
 Pasión: por lo que hacen día a día motivados hacia el logro de la excelencia en
cada uno de los productos que desarrollamos.
 Trabajo en equipo: compartir conocimientos y esfuerzos en un ambiente que
permita la consecución de metas como equipo.
 Orientación al cliente: busca desarrollar soluciones de software que se
anticipen y satisfagan las necesidades de nuestros clientes con un servicio que
genere fidelidad y hable sobre la calidad de sus productos.
 Integridad: comprometidos a llevar una gestión transparente y llevar cada uno
de los procesos de forma íntegra, respetando siempre la confidencialidad de
sus clientes.

Estructura organizativa.

La estructura organizativa de la empresa Momentum Lab se encuentra

descrita en la Figura 1:
 12

Figura 1. Estructura Organizativa de la empresa Momentum Lab, C.A.

Fuente: Momentum Lab (2016).

Antecedentes

El desarrollo de esta investigación, se fundamentó en una serie de proyectos

similares realizados por instituciones a nivel nacional e internacional. Estos trabajos
hacen uso del lenguaje natural para acceder al contenido de una fuente de datos, de
los mismos se obtuvo algunos conceptos de diseño y funcionalidades que incorpora la
herramienta propuesta. A continuación, se listan algunos sistemas de preguntas y
respuestas:

 Baseball: An Automatic Question-answerer: Un sistema de búsqueda de

respuestas desarrollado en el instituto de tecnología de Massachusetts
(Estados Unidos) que respondía preguntas realizadas en inglés acerca de los
datos de la liga estadounidense de Baseball que se encontraban en una base de
datos. Se utilizaron técnicas de análisis lingüístico para resolver la pregunta.
(Green et al., 1973)
 Lunar: Es un sistema que fue desarrollado con el apoyo de la NASA Manned
Spacecraft Center (Centro de naves espaciales tripuladas de la NASA) con la
finalidad de brindarle una interfaz en lenguaje natural a los geólogos para
 13

acceder, comparar y evaluar los datos de los análisis químicos de la

composición del suelo y roca lunar. (Woods, 1978)
 Start: Sistema de búsqueda de respuestas en lenguaje natural disponible en la
web desde 1993. Se especializa en preguntas de geografía y con información
relacionada al laboratorio de lenguaje MIT infolabs, lugar donde fue
desarrollado. Se empleaban técnicas basadas en triples para modelar el
conocimiento. (Katz et al,2006)
 Ask Jeeves: Sistema de búsqueda de respuesta en lenguaje natural basado en
reconocimiento de patrones para emparejar la consulta con su propia base de
conocimiento de preguntas. En caso de no encontrar la respuesta utiliza otros
buscadores en la web para dar respuesta a la necesidad. Posee un catálogo
previo de preguntas. (Vargas-Vera & Mota, 2000)
 Sistema de preguntas y respuestas basado en ontologías sobre el modelado
conceptual en base de datos: Un proyecto de fin de carrera realizado por Carlo
Baldacci Riobueno para la Universidad Simón Bolívar, el proyecto ofrece un
sistema tutorial inteligente para Base de Datos. Mediante este, los estudiantes
pueden realizar preguntas en lenguaje natural acerca del modelado de Bases
de Datos, lo cual permite el aprendizaje a los estudiantes en línea. (Baldacci,
2015)

Bases Teóricas

Arias (1999) sostiene que las bases teóricas “comprenden un conjunto de

conceptos y proposiciones que constituyen un punto de vista o enfoque determinado,
dirigido a explicar el fenómeno o problema planteado” (p.39). En tal sentido, para la
elaboración del software fue necesario partir del conocimiento de los fundamentos
teóricos que sirvieron para guiar su desarrollo y que se presentan en esta sección.
 14

Asistentes digitales.

La tecnología de asistentes personales digitales, también conocidos como

PDA (Personal digital Assistant) tiene sus orígenes desde hace décadas cuando
diversas compañías empezaron a desarrollar computadoras de bolsillo capaces de
realizar diversas tareas. Sobre ello, Grothaus (2014) menciona que, “en la actualidad,
los asistentes digitales están basados en software que viven en un teléfono inteligente
y que tienen la habilidad de saber lo que el usuario quiere.”(párr. 1). Así, podemos
mencionar algunos de los asistentes digitales actuales:

 Siri: fue presentado en el 2011 por Apple en el lanzamiento del iPhone 4s. Se
trata de un asistente de voz capaz de realizar diversas tareas como: realizar
una llamada, buscar en internet, escribir un email, entre otras. Para su
activación, el usuario debe presionar y sostener el botón Home del IPhone.
Heather (2015) en una comparación con otros asistentes digitales menciona
que “Siri es la mejor entendiendo el lenguaje natural. Puede entender
múltiples maneras de preguntas lo mismo, de manera que no tengas que
preocuparte por recordar las frases exactas de los comandos” (párr. 5).
 Google Now: es un asistente personal desarrollado por Google. Utiliza una
interfaz de usuario en lenguaje natural para responder preguntas, realizar
recomendaciones y delegar actividades a servicios web. Hill (2016) comenta
que, esta tecnología es más ambiciosa que Siri, debido a que Google Now
puede aprender de tus hábitos y puede ofrecer información en la cual piensa
que podrías estar interesado.
 Alexa: es un asistente personal inteligente desarrollado por Amazon integrado
en un altavoz desarrollado por esta misma empresa llamado “Amazon Echo”.
Se activa mediante un comando de voz y puede realizar tareas como
reproducir música, hacer recordatorios, comprar cosas (Heather, 2015, párr.
8). Una de las características innovadoras de este producto es que brinda
mediante una API la posibilidad de controlar otros artefactos inteligentes del
 15

hogar. De esta manera, sirve como un control remoto inteligente mediante

control de voz.
 Cortana: es un asistente digital desarrollado por Microsoft para el sistema
operativo Windows 10 y para dispositivos Windows Phone que permite
responder preguntas acerca de información del tiempo, deportes, archivos
contenidos en el dispositivo o nube, entre otras tareas como: activar
recordatorios, reproducir música mediante el uso del lenguaje natural (Hunter,
2015). La información que utiliza es recolectada a través de Bing, el cual es
un buscador web desarrollado por la misma empresa, Microsoft.
Adicionalmente, Cortana es activado a través de comandos de voz que pueden
ser personalizados por el usuario.

Humanización de la tecnología.

Los avances en la tecnología han hecho posible que los dispositivos

electrónicos se comporten de manera natural, respondiendo a preguntas en lenguaje
natural como si fuesen humanos.

Sobre este tema Turing (1950) propuso un experimento llamado The Imitation
Game, que posteriormente fue llamado “Test de Turing” (Rapaport, 2006, p.151). En
este experimento el investigador buscar determinar si el participante, en una
conversación en lenguaje natural, es un humano o una máquina. Así mismo, existen
competencias como los premios de Loebner en donde se aplica el experimento
propuesto por Turing para seleccionar al computador que se comporte de la manera
más humana en una conversación en lenguaje natural.

Además cabe mencionar que en el 2011 el sistema Watson, desarrollado por

IBM, ganó el concurso de preguntas Jeopardy, en la cual el participante elige un tema
y se le otorga una pista sobre la pregunta a responder; este sistema compitió contra
dos personas.
 16

Aunque se destacan estos grandes avances Todorović (2015) menciona que el

experimento de Turing no ha sido completado con éxito y que aún la inteligencia
artificial está lejos de pasar el experimento debido a diversos factores como: la
debilidad del hardware actual, pocas inversiones en el área de inteligencia artificial y
la dificultad de integrar múltiples componentes para realizar sistemas complejos,
entre otros factores.

En este mismo sentido, los asistentes digitales listados anteriormente son

ejemplos de tecnologías que buscan imitar el comportamiento humano respondiendo
a preguntas realizadas en lenguaje natural. En una entrevista realizada al fundador de
la compañía Verbios, empresa dedicada al desarrollo de comunicaciones entre
máquinas y personas de manera natural, Antonio Terradas, menciona que “La
máquina no sustituirá al hombre, pero le hará la vida más fácil”(Oscar, 2013, párr. 3).
Actualmente, uno de los retos de las ciencias de la computación es hacer que las
computadoras entiendan el lenguaje natural, siendo el que las personas usan como
medio de comunicación diariamente. Para este propósito, existe un campo de las
ciencias de la computación dedicado a la interacción entre las computadoras y
humanos, llamado Inteligencia Artificial.

Experiencia centrada en el usuario.

La experiencia de usuario son las emociones positivas o negativas o

experiencias que una persona tiene interactuando con un producto digital. La
mayoría de los sistemas que ofrecen información turística solamente soportan la
interacción entre el usuario y el sistema a un nivel básico, como por ejemplo:
búsqueda a través de navegación por el sitio, buscador por palabras claves, entre
otros; dejando de lado el soporte a la interacción de los usuarios como comúnmente
lo harían estando con un guía turístico. Así, Salcedo (2016) menciona que “significa
considerar que su accesibilidad se ajuste al modo de uso más natural para las personas
y le faciliten o reduzcan el número de pasos necesarios para llevar a cabo una
tarea.”(p.41)
 17

Marcus (2014) define la experiencia de usuario como “la totalidad de los

efectos sentidos internamente por el usuario como resultado de la interacción, la cual
puede empezar antes del contacto visual (expectativas) y además, durante y después
de la interacción.” (p. 344).

Salcedo (2016) además, asegura que:

“La experiencia de usuario no se trata sobre cómo el producto funciona

internamente, sino externamente cuando una persona hace contacto
con él, donde depende de sus factores psicológicos y de
comportamiento, de esta forma se asegura que tanto los aspectos
estéticos como los funcionales trabajan dentro del contexto apropiado
(Garret, 2010), enfatizando los aspectos interactivos en cada estado del
producto.”(p.42)

Web semántica.

Esta idea fue conceptualizada por Tim Berners Lee en 2001, como la
obtención de datos definidos y conectados de una manera que pueda ser usada por las
máquinas no sólo con fines de visualización, sino que, pueda automatizarse,
integrarse y reusar entre varias aplicaciones. De acuerdo con Los Santos et al (2009)
“la web semántica pretende dar una mejor estructura a los contenidos de las páginas
web para que puedan ser entendidos por los ordenadores.” (p. 4).

Como se mencionó en la problemática de este trabajo, los usuarios cuando

realizan una búsqueda, recorren varios enlaces antes de dar con la información que
requiere. Los Santos et al (2009), afirman que, “esto se debe a que los buscadores
realizan las búsquedas a través de coincidencias de palabras, pero las máquinas no
entienden cuál es el contexto.” (p. 4). Sin embargo, la web semántica al pretender dar
una mejor estructuración de la información y utilizando técnicas de inteligencia
artificial para que los ordenares pueden entender el contenido, se pueda ofrecer un
mejor resultado a los usuarios (Los Santos et al, 2009, p.4).

En consecuencia, con la web semántica se busca transformar la red o espacio

de información, también llamado WWW, en un espacio de conocimiento. Berners
 18

(2001) menciona que, la web semántica será una extensión de la actual web y no una
nueva. Berners, indica además, que “en este proyecto convergen la IA, las tecnologías
Web y se proponen nuevas técnicas y paradigmas para la representación del
conocimiento que contribuyan a la localización e integración de recursos a través de
la WWW” como se cita en Milagros et al (2012).

El consorcio de la WWW, también conocido como W3C, ha establecido una

serie de tecnologías estándares para la web semántica y ha establecido la “Pila de la
web semántica” (Anton, 2016, p.199). En ella, se ilustran cómo las tecnologías son
organizadas para que la Web Semántica sea posible. En la Figura 2, se muestra la pila
de la web semántica.

Figura 2. Pila de la web semántica.

Tomado de: https://www.w3.org/2001/sw/

Sobre estas tecnologías, Baldacci (2015) afirma que “un producto o proyecto
puede tratar con la semántica, pero si no utiliza estas normas, no puede conectarse y
ser parte de la web semántica” (p.16).

A continuación, se definirán algunas de las tecnologías estándares, presentes

en la Figura 2.
 19

Identificador uniforme de recursos (URI).

Los URI son identificadores que son asignados a recursos para identificarlos
de manera única. Sobre ello, Cáceres (2006) menciona que:

El objetivo de la Web Semántica es el de identificar ítems, nombres de

documentos, contenidos de documentos; si queremos buscar algo sobre
“un tipo de golosinas”, “el tráfico en Madrid”, “Adolfo Suárez”, todos
estos conceptos son ítems en la Web, bien, para identificarlos en la
Web, necesitamos usar identificadores, pero eso sí usaremos un
sistema uniforme de identificadores y cada ítem identificará a un único
recurso. A estos identificadores los llamaremos URI “Uniform
Resource Identifiers”. Los URIs pueden identificar cualquier cosa y
para la WWW tener una URI significa “estar en la Web”. (párr. 5).

Marco de descripción de recursos (RDF).

Según Labras (2011) “uno de los pilares de la Web Semántica es el desarrollo

de técnicas que faciliten la descripción de recursos mediante la creación de
metadatos.”(p.56). Cabe agregar que, los metadatos son datos que describen otros
datos, sobre ello, Ergovac (1999) afirma que “un metadato describe los atributos de
un recurso, teniendo en cuenta que el recurso puede consistir en un objeto
bibliográfico, registros e inventarios archivísticos, objetos geoespaciales, recursos
visuales y de museos o implementaciones de software.”(p.1).

Para la definición de los datos, el consorcio W3 creó un marco de trabajo para

modelar y describir recursos llamado RDF (Resource description framework en
inglés). Con la intención de definir recursos, el marco de trabajo RDF hace uso de las
tripletas, también llamados “triples” (DuCharme, 2011, p.25). Para ello, Baldacci
(2015) lo define como “la combinación de tres recursos (un sujeto, un predicado y un
objeto) y en términos de relaciones puede verse como la combinación entre el sujeto
y un objeto, a través del predicado” (p.18).
 20

RDF Schema (RDFS).

Este vocabulario extiende la expresividad de RDF, permitiendo describir los

recursos definidos con RDF. Yahuita (2014) menciona que “Es un vocabulario RDF
para describir propiedades y clases de recursos RDF, con semántica para generalizar
jerarquías de las propiedades y clases”

Lenguaje de Ontologías Web (OWL).

Es el lenguaje recomendado por la W3C para construcción de ontologías.

Yahuita (2014) lo define como un mecanismo que se utiliza para la construcción de
vocabularios específicos en donde se puedan asociar recursos.

Anton (2016) menciona que OWL:

Extiende RDFS añadiendo construcciones más avanzadas para

describir semánticamente las declaraciones RDF. Permite declarar
limitaciones adicionales, restricciones de valores o características de
propiedades como la transitividad. Se basa en la lógica de la
descripción y aporta lógica de razonamiento a la Web Semántica.
(p.200).

Existen tres variantes de este vocabulario, a continuación se listan y definen

cuándo usar este tipo de vocabularios:

 OWL Lite: está diseñado para aquellos usuarios que necesitan

principalmente una clasificación jerárquica y restricciones simples.
 OWL DL: está diseñado para aquellos usuarios que quieren la máxima
expresividad conservando completitud computacional (se garantiza
que todas las conclusiones sean computables), y re solubilidad (todos
los cálculos se resolverán en un tiempo finito).
 OWL Full: está dirigido a usuarios que quieren máxima expresividad y
libertad sintáctica de RDF sin garantías computacionales.
 21

Lenguaje de Ontologías Web 2 (OWL 2).

Posteriormente, la W3C anunció la expansión de las funcionalidades del OWL

y presentó OWL 2. Narváez (2010) afirma que “esta extensión tenía como finalidad
la creación de un nuevo grupo de trabajo para adicionar nuevas características como
mayor expresividad sintáctica, extensiones sobre los tipos de datos y capacidad de
anotaciones, meta modelado simple, entre otras.”

Así mismo, OWL 2 presenta una serie de sublenguajes que pueden ser
utilizados dependiendo del caso que se requiera. Narváez (2010), además, describe
cada uno de ellos:

 OWL EL: Este perfil garantiza que todas las tareas de

razonamiento comunes dentro de la ontología requieren un
tiempo polinomial. Esto es útil, particularmente, al trabajar con
ontologías de gran tamaño, pues bajo estas circunstancias es
posible intercambiar la expresividad del lenguaje por una
mayor eficiencia en los algoritmos.

 OWL QL: Este perfil permite la realización de consultas

conjuntivas a la ontología por medio de lenguajes relacionales
como SQL garantizando que las mismas puedan ser resueltas
en Espacio Logarítmico. Puede ser utilizado para definir
ontologías que luego serán consultadas directamente a modo de
bases de datos.

 OWL RL: Este sublenguajes permite ejecutar razonamientos

sobre la ontología en tiempo polinomial utilizando técnicas de
bases de datos extendidas por reglas aplicadas directamente a
los datos representados como ternas RDF.

Representación del conocimiento.

Según Luzmila Pro (2010) “la representación del conocimiento se enfoca en el

diseño de formalismos epistemológicos y computacionalmente apropiados para
expresar el conocimiento en un área en particular” (p.79). En otras palabras, busca
modelar de forma estructurada la experiencia que se tiene sobre un cierto dominio.
 22

Así, este concepto podría ayudar a la idea de “la web semántica” propuesto
por Berners (2001) en la creación de un espacio de conocimiento.

Yahuita (2014) afirma que, “La representación del conocimiento es un

elemento fundamental en la implementación de las web semánticas, ya que permite a
las aplicaciones implementar funciones que incorporan estrategias de localización de
información que sean óptimas y eficientes.”(p. 59).

Sobre ello, el modelo de representación de recursos RDF facilita la

integración de sistemas al utilizar identificadores únicos globales (URIs) para
identificar conceptos. Por otro lado, José (2011) menciona que si a dichas conceptos
se le asigna un significado determinado, se posibilita la creación de un sistema global
de representación del conocimiento.

Ontología.

La ontología, es una antigua disciplina que fue caracterizada por Aristóteles

como la disciplina que trata del estudio del ser o de los principios que componen la
realidad. En el área de la informática, existen diversas definiciones sobre este
concepto. Entre ellas, la definición más popular según Yahuita (2014) es la dada por
Gruber (1993) el cual la define como “Una especificación explícita de una
conceptualización” (p.1). Luego, Borst (1997) definió una ontología como “Una
especificación formal de una conceptualización compartida” (p.12). Posteriormente,
Studer (1998) mezcló estas dos definiciones y la definió como “Una especificación
formal, explícita de una conceptualización compartida” (p. 184). Sobre esta última
definición, una conceptualización es una vista abstracta y simplificada del mundo que
se desea representar. Explícita significa que los conceptos, propiedades, relaciones,
funciones y axiomas utilizados estén explícitamente definidos. Formal se refiere a
que la ontología debe ser legible por la máquina. Por último, es compartida, si el
conocimiento que captura tiene el conceso de la comunidad. (A. Gómez et al, 2004)
 23

En otras palabras, una ontología define un esquema específico que refleja una
visión específica del mundo. En sistemas basados en conocimiento, lo que puede ser
representado, puede existir en un mundo conceptualizado (Gruber, 1994, p.1).

En el área de la web semántica, Tim Berners Lee (2001) ejemplifica el uso de

las ontologías:

“Imagina que tenemos acceso a una diversidad de bases de datos con

información acerca de personas, incluyendo sus direcciones. Si
quisiéramos encontrar personas en una específica área postal,
deberíamos saber cuáles campos en cada base de datos representan
nombres y cuales representan códigos postales. Con RDF podríamos
especificar que ‘(El campo 5 en la base de datos A) (Es un campo de
tipo) (Código Postal)’ usando identificadores únicos para cada término
en lugar de frases. Por supuesto, este no es el fin de la historia, porque
dos bases de datos pueden usar diferentes identificadores lo cual en
realidad es el mismo concepto, como el código postal. Un programa
que quiera comparar y combinar información acerca de las dos bases
de datos debe saber que aquellos dos términos son usados para
representar la misma cosa. Idealmente, el programa debe descubrir una
manera de descubrir aquellos significados comunes para cualquier base
de datos que encuentre. Una solución para este problema es
proporcionado por el tercer componente de la web semántica, una
colección de información llamada Ontologías.”(párr. 19)

En el ámbito del Procesamiento del Lenguaje Natural, Pérez (2002) menciona

que:

“Las ontologías se están empleando para construir representaciones

independientes de la lengua que puedan servir de punto de encuentro
entre dos o más lenguas naturales.”. En este sentido, la ontología se
considera como un documento de conceptos que establecen conexiones
entre la terminología de una lengua y sus referentes en el mundo o
mundo conceptualizado que se contempla.”(párr. 1)

Base de conocimiento.

Una base de conocimiento (BC) contiene un componente terminológico o

llamado también Tbox que contiene el vocabulario del dominio de la aplicación y un
componente de afirmaciones Abox sobre individuos en términos del vocabulario
 24

presente en la terminología (Baader et al, 2003, p.50). Las afirmaciones que existen
sobre la terminología definida, puede facilitar la inferencia o razonamiento. En otras
palabras, en una base de conocimiento se registran unas estructuras de datos que
representan un conocimiento estructurados en hechos, y reglas que permiten generar
más conocimiento.

Acceso a datos mediante ontologías (OBDA).

El acceso a datos basados en ontologías (OBDA) es un nuevo paradigma que

se basa en el uso de representación del conocimiento y técnicas de razonamiento, para
consultar los recursos de sistemas de información modernos.

Rodríguez et al (s.f) mencionan que en este paradigma, una ontología provee

un vocabulario, una representación de alto nivel del dominio de interés, de manera
que la estructura de las fuentes de datos (base de datos, almacenamiento de triples,
catálogo de datos) es transparente para el usuario.

Existen tres componentes que están presentes en este paradigma, en el sitio

web OBDA Systems definen la arquitectura como:

La idea clave de OBDA es proporcionar a los usuarios acceso a la

información en sus fuentes de datos a través de una arquitectura de tres
niveles, constituida por la ontología, las fuentes y el mapeo entre
ambas, donde la ontología es una descripción formal del dominio de
interés, y es el corazón del sistema. A través de esta arquitectura,
OBDA proporciona una conexión semántica de extremo a extremo
entre los usuarios y las fuentes de datos, lo que permite a los usuarios
consultar directamente los datos esparcidos por múltiples fuentes
distribuidas, a través del vocabulario familiar de la ontología: el
usuario formula consultas SPARQL sobre la ontología que se
transforman, a través de la capa de mapeo, en consultas SQL sobre las
bases de datos relacionales subyacentes.

En resumen, en el paradigma OBDA, la ontología provee una abstracción

lógica, independiente de cómo y donde los datos están físicamente almacenados
(Sequeda, 2017).
 25

S. Gómez (2017) describe algunas características que hacen que el uso de

sistemas OBDA sea importante:

1. Brindan una vista conceptual del alto nivel de los datos.

2. Brindan al usuario un vocabulario conveniente para consultas.

3. Permiten al sistema enriquecer datos incompletos con

conocimiento del dominio.

4. Soportan consultas sobre múltiples fuentes de datos

heterogéneas.

Procesamiento del lenguaje natural (NLP).

El procesamiento de lenguaje natural (NLP) es un campo de la informática,

inteligencia artificial y la lingüística. Chowdhury (2003) define NLP como “un área
de investigación y aplicaciones que explora cómo los computadores pueden ser
usados para entender y manipular el lenguaje natural en textos o habla para realizar
cosas útiles” (p.1). Así pues, Baldacci (2015) comenta que, se relaciona con el campo
de la interacción persona/ordenador.

Sistema de pregunta y respuesta.

Los sistemas de preguntas y respuestas (sistemas PR) se caracterizan por ser

sistemas que aplican diversas técnicas para resolver consultas realizadas en lenguaje
natural y devolver una respuesta. De esta manera, se pueden clasificar como un tipo
de sistemas de recuperación de información (RI) el cual tiene por misión devolver,
dada una consulta los documentos más relevantes de acuerdo a la consulta (Martínez-
Barco et al, s.f). A diferencia de los sistemas RI, los sistemas PR no devuelven un
documento que contenga la respuesta, sino la propia respuesta. Cabe destacar que,
Berners (2001) explica que las computadoras no entienden verdaderamente el
significado de la información contenida, sin embargo, pueden manipular los términos
de una manera más efectiva que pueda ser de utilidad y significativo para un usuario.
 26

Dwivedi y Singh (2013) categorizaron los sistemas de preguntas y respuesta

basados en las distintas técnicas utilizadas, como resultado obtuvieron la siguiente
clasificación: enfoque lingüístico, enfoque estadístico y enfoque basado en patrones.

A continuación, se describen cada uno de los enfoques mencionados anteriormente

 Enfoque lingüístico: la lógica del sistema contiene métodos que integran el

procesamiento del lenguaje natural y bases de conocimiento. El conocimiento
es organizado en forma de reglas, ontologías y redes semánticas; este es usado
durante el análisis de la pregunta. Análisis sintáctico, tokenización y
etiquetador de palabras son alguna de las técnicas lingüísticas usadas en la
pregunta del usuario para formular una consulta que pueda extraer la respuesta
en una base de datos estructurada. (Sasikumar, 2014, p.1)
 Enfoque estadístico: utilizan técnicas que no sólo se refieren a la gran
cantidad de datos, sino también a su heterogeneidad. Además, los enfoques
estadísticos también son independientes de lenguajes de consulta
estructurados. Sin embargo, estos enfoques requieren una cantidad adecuada
de datos para un aprendizaje estadístico preciso, pero una vez aprendidos
adecuadamente, producen mejores resultados que otros enfoques
competidores. Entre algunas de las técnicas utilizadas son: máximo modelos
de entropía, clasificadores de máquinas vectoriales (SVM), clasificadores
bayesianos. (Dwivedi, 2013, p.1)
 Enfoque basado en patrones: utiliza la expresividad de patrones de texto,
como reemplazo al procesamiento sofisticado utilizado por otros enfoques.
(Dwivedi, 2013, p.1). Por ejemplo, la pregunta “¿Que playas hay en
Margarita?” seguiría el siguiente patrón “¿Que <concepto> hay en
<locación>?”.
 CAPÍTULO III

Marco Metodológico

Tipo de Investigación

Según el Nivel de Investigación.

Según Fidias Arias (1999) “El nivel de investigación se refiere al grado de

profundidad con que se aborda un objeto o fenómeno¨ (p.45). La solución propuesta
pertenece a un tema del cual se desea explorar nuevas alternativas al problema
planteado. Los resultados obtenidos a través del desarrollo de dicha solución
proporcionan un acercamiento al diseño y funcionamiento de los sistemas de
búsqueda de respuesta, permitiendo observar los beneficios de emplear nuevas
tecnologías en el ámbito turístico en Venezuela. Es por ello que, el nivel de
investigación corresponde al tipo exploratorio.

Según Sampieri, Collado y Baptista (2003), un estudio exploratorio se realiza:

“cuando el objetivo es examinar un tema poco estudiado, del cual se tienen muchas
dudas o no se ha abordado antes.” (p. 79). Siendo el tema, el desarrollo de un sistema
de búsqueda de respuesta orientado al turismo en Venezuela, que permita la
contestación de preguntas realizadas por el usuario en lenguaje natural.

Según el Diseño de la Investigación.

El diseño de la investigación alude a las decisiones que se toman en cuanto al

proceso de recolección de datos, que permitan al investigador lograr la validez interna
de la investigación, es decir, tener un alto grado de confianza de que sus conclusiones
no son erradas. (Hurtado, 2007)
 28

Por lo tanto, el diseño abarca los procedimientos que se realizarán para

establecer dónde y cuándo se recopila la información.

Debido a la naturaleza de la solución propuesta, se espera que en base a la

documentación bibliográfica y escrita que existe de sistemas similares podamos
diseñar una solución que se adapte a las necesidades planteadas. Los usuarios y
cliente también formarán parte del proceso de levantamiento de requerimientos, ya
que se deberá conocer ¿qué preguntas son las más comunes en relación al turismo?
esto brinda un acercamiento sobre qué tipo de preguntas el sistema deberá responder.

Hurtado (2007) alude que, si las fuentes de información son vivas y se recoge
en su ambiente natural, el diseño se denomina de campo. Por lo tanto, Se considera
que según el diseño de investigación es de campo.

Técnicas e Instrumentos de Recolección de Datos

Carlos Sabino (1992) define los instrumentos de recolección de datos como

“cualquier recurso de que se vale el investigador para acercarse a los fenómenos y
extraer de ellos información”. Para el estudio de las características que debe poseer y
que se evaluarán del sistema de pregunta-respuesta, es necesario utilizar un conjunto
de técnicas para realizar el levantamiento de requerimientos en la etapa inicial del
proyecto y para la etapa final en la evaluación del mismo.

El uso de la documentación como técnica de investigación, será la

herramienta principal para recolectar información en la fase inicial del trabajo. Esta
servirá como punto de partida para ubicar los estudios, investigaciones, datos e
información sobre el problema planteado.

Metodología de Desarrollo

Salcedo (2016) menciona que “es necesario definir un marco y métodos de

trabajo para su realización de forma eficiente, tomando en cuenta aspectos como la
 29

comunicación con el cliente, la dinámica de trabajo, los tiempos de entrega

pertinentes, los requerimientos del sistema, entre otros.”

Documentos internos de Momentum Lab C.A (2016) muestran que la empresa

posee una metodología de desarrollo la cual utiliza para el proceso de desarrollo de
software dentro de la empresa. La metodología busca integrar las mejores prácticas
del marco de trabajo SCRUM y documentos de la programación extrema (XP), las
cuales son dos de las principales metodologías ágiles que se aplican en el desarrollo
de software.

La metodología Momentum cuenta con cuatro etapas, como se muestra en la

Figura 3 en donde la primera es previa al proceso iterativo y contempla el
levantamiento de requerimientos, luego, consta de una fase iterativa. Después, se
verifica el cumplimiento de los requisitos del sistema y, por último, en función de una
revisión, se define una entrega o no del producto final.

Figura 3. Etapas de la metodología Momentum.

Tomado de: Momentum Lab, C.A (2016).
 30

Etapas.

1. Primera etapa o fase inicial: se utilizan técnicas de recolección de datos para

la obtención de las funcionalidades y requisitos del sistema. Durante esta
etapa se capta la finalidad de la aplicación, las entidades que interactúan y
otros factores que permitirán comprender la visión del sistema. A partir de los
resultados obtenidos se recopilan los requerimientos iniciales o fundamentales
de la aplicación los cuales se representarán a través de historias de usuario.
2. Segunda etapa o fase Momentum: es responsable de la planificación de las
tareas a realizar, su codificación, las reuniones de avance y las revisiones de
funcionalidad. Durante cada iteración se establece una lista de entregables los
cuales contendrán elementos de la pila de entregables obtenidos en la etapa
anterior, también se define la manera en las que se solucionarán los
entregables. Durante esta etapa se realiza el diseño, codificación y evaluación
de cada entregable.
3. Tercera etapa o Revisión final: se verificará que todos los requerimientos del
sistema fueron cubiertos correctamente y se confirmara el funcionamiento de
los elementos de la lista de entregables.
4. Cuarta etapa o Entrega: luego de concluida la revisión final, se procede al
lanzamiento del producto en función al tipo definido en el contrato. En este
sentido, se le entrega al cliente el sistema donde revisa que todo se encuentra
en orden. Adicionalmente, es enviado un cuestionario al cliente, para conocer
su opinión en cuanto a la calidad del servicio.

Actividades.

En cada etapa de la metodología, se llevan a cabo distintas actividades que

deberán ser realizadas en la investigación, las cuales se describen en la Tabla 1.
 31

Tabla 1.
Actividades involucradas en la Metodología Momentum

Actividad Etapa Descripción

Levantamiento de Inicial Obtención de los requerimientos.

requerimientos.

Release Planning Inicial Construcción de la lista de requisitos priorizadas

Sprint Planning Momentum Establece un listado de entregables al inicio de

cada iteración.

Codificación Momentum Se toma algún ítem de la pila de entregables y se

procede a su construcción.

Daily scrum Momentum Se planifica qué actividades se realizarán en el

día.

Sprint Review. Diseño Se realizan reuniones con el cliente, esté

realizará pruebas del sistema y expondrá
cambios de ser necesarios. Si el cliente está
satisfecho con el incremento, entonces se
establecerá como “terminado y funcional” dicho
incremento.

Retrospectiva Momentum Evaluación realizada luego del proceso anterior.

Se busca definir qué aspectos se pueden mejorar
para la planificación del próximo incremento.

Nota. Recuperado de documentos internos de Momentum Lab, C.A.

Cabe destacar que la fase de lanzamiento no fue tomada en cuenta, debido a

que el resultado del desarrollo es un prototipo del producto final, por lo cual las tareas
realizadas en dicha fase no están en concordancia con el alcance del proyecto.
 32

Herramientas.

Para el cumplimiento de las actividades, se utilizan en conjunto una serie de

herramientas que permiten realizar una mejor planificación y organización del
proyecto. En la Tabla 2, se describen las herramientas que se usan en la metodología.

Tabla 2.
Herramientas utilizadas en la metodología Momentum.

Herramienta Descripción

Product Backlog Es un listado de todo lo que es necesario en el producto.

Estará representado por un conjunto de historias de usuario.

Sprint Backlog Es una lista de tareas que se elabora en la reunión de

planificación de la iteración, así como el plan para
completar los objetivos/requisitos seleccionados para la
iteración y que se compromete a demostrar al cliente al
finalizar la iteración, en forma de incremento de producto
preparado para ser entregado.

Historias de Es un instrumento utilizado para delimitar los

usuario requerimientos del sistema de una forma clara y precisa,
Tienen por objetivo contemplar las diferentes funciones a
realizar para alcanzar el producto de software que desea el
cliente.

Contexto Contiene los requerimientos iniciales o fundamentales de la

aplicación.

Nota. Recuperado de documentos internos de Momentum Lab, C.A (2016).

Las historias de usuario de la metodología Momentum Methodology, que son

descritas en la Tabla 2, tienen un formato definido y deben llevar los siguientes
elementos:

 ID: corresponde al número que identifica la historia de usuario.

 33

 Título: Equivale al nombre de la historia, que debe ser relevante con la

funcionalidad a construir.
 Tiempo estimado: periodo de tiempo expresado en días o semanas, que
contempla la duración para elaborar la historia.
 Prioridad: Indica el nivel de importancia de la historia con respecto a otras, las
prioridades son alta, media y baja.
 Descripción: contempla de manera general la funcionalidad a desarrollar
especificando las tareas a realizar.

Por lo tanto, a lo largo de este trabajo al referirnos a las historias de usuario

estaremos haciendo referencia a las usadas por la metodología de desarrollo de la
empresa.

Durante la actividad del Sprint Planning descrita en la Tabla 1, se tiene como

objetivo resolver las preguntas: ¿Qué historias debemos agrupar? y ¿Cómo
resolveremos cada una de ellas? Así también, se diseñan diagramas, se realizan
algoritmos, bocetos de funciones, entre otros. Por lo que, al asociar el resultado de las
preguntas anteriores (qué y cómo) se construye el sprint backlog, tal y como es
descrito en la Tabla 2, consiste en una pila de entregables que siguen el esquema de
“La historia de usuario numero N se resolverá de la siguiente manera”, siendo N el
identificador de la historia de usuario. En la Figura 4 se muestra un diagrama con las
tareas involucradas durante la actividad del Sprint Planning.

Figura 4. Actividad de Sprint Planning

Tomado de: Momentum Lab (2016)
 34

En la Figura 5, se muestra las distintas actividades realizadas durante la etapa

inicial de la metodología.

Figura 5. Etapa inicial.

Fuente: Momentum Lab, C.A (2016)

En la Figura 6, se muestra las distintas actividades realizadas durante la etapa

iterativa denominada etapa Momentum.

Figura 6. Etapa Momentum.

Tomado de: Momentum Lab, C.A (2016)
 35

Roles.

Momentum Lab (2016) define los siguientes roles

Product Owner

Es el responsable de delimitar todo lo que el sistema necesita (product backlog)

exponiendo de forma clara los requerimientos, estableciendo prioridad en las
actividades y procura que el equipo de desarrollo comprenda el listado del product
backlog de forma precisa. Este rol sólo lo cumple una persona y no una asociación o
comité. Además, debe:

 Definir los componentes de la lista del producto (product backlog).

 Ordenar los ítems del product backlog (priorizar).
 Optimizar el valor del trabajo del equipo de desarrollo.
 Asegurar que el product backlog es comprendido por los involucrados,
mostrando las funcionalidades a desarrollar.
 Confirmar que el equipo de desarrollo comprende de forma clara los
requerimientos, al nivel necesario

Development Team.

Consiste en un grupo de desarrolladores que tienen por objetivo entregar los

incrementos “terminados” del producto y son los únicos involucrados en los aspectos
de codificación.

Metodología para la Construcción de Ontologías

La construcción de una ontología es un proceso y como tal, está compuesto de

una serie de actividades que se realizan en un determinado orden. Existen diversos
métodos y metodologías que se orientan al desarrollo y mantenimiento de ontologías.
 36

Para el desarrollo de este proyecto se utilizó la metodología de construcción

de ontologías de Noy & Mcguinness (1995) “Ontology Development 101”, para
describir el contenido semántico del dominio, posteriormente se utiliza la herramienta
Protégé para obtener una representación de la ontología en el lenguaje OWL.

Los autores mencionan que no hay una manera “correcta” para desarrollar
ontologías. Por ello, discuten los problemas generales a considerar durante el
desarrollo y ofrecen un posible proceso para desarrollar una ontología. Es por ello,
que describen un proceso iterativo en donde empiezan con un primer acercamiento a
la ontología, se realizan revisiones del alcance y de ser necesario se refinan y llenan
los detalles necesarios. Además, enfatizan algunas reglas fundamentales en el diseño
de ontologías, que pueden ayudar a tomar decisiones en algunos casos:

 No existe una manera correcta de modelar un dominio. Siempre hay

alternativas viables. La mejor solución casi siempre depende de la
aplicación que se tiene en mente y la extensión que puedas anticipar.
 El desarrollo de ontología es necesariamente un proceso iterativo.
 Conceptos en la ontología deben ser cercanos a objetos (físicos o
lógicos) y relaciones del dominio de interés. Casi siempre suelen ser
sustantivos (objetos) o verbos (relaciones) en oraciones que describen
tu dominio.

Este método se desarrolló como ejemplo de construcción de ontologías OWL

con la herramienta Protégé desarrollada en la universidad de Stanford. Actualmente
es muy popular debido a su sencillez, y, sobre todo a la popularidad que ha alcanzado
Protégé. Se considera una ontología como una descripción explícita y formal de
conceptos (clases) en un dominio de discurso. Estas clases tienen una serie de
propiedades (slots o roles), que describen las características y atributos del concepto,
y restricciones sobre los slots. En la Tabla 3 y Tabla 4 se describe los pasos
propuestos por la metodología.
 37

Tabla 3.
Pasos de la metodología Ontology Development 101.

Fase Entrada Descripción Salida

Determinar el Definición de: El documento

dominio y - ¿Cuál es el dominio que la ontología resultante podría
alcance de la cubrirá? cambiar durante
ontología - ¿Para qué usaremos la ontología? todo el proceso,
- ¿Para qué tipos de preguntas la pero en
información en la ontología deberá cualquier
proveer respuestas? (Las preguntas de momento, esta
competencia son muy importantes en este documentación
dominio; ellas permiten a los diseñadores será de ayuda
entender cuando la ontología contiene para limitar el
suficiente información y cuando obtiene alcance del
el nivel de detalle o representación). modelo.
- ¿Quién usará y mantendrá la ontología?

Considerar Documentos Buscar por otras ontologías que definen Una o más
reusar con el el dominio. Existen librerías de ontologías del
ontologías dominio y el ontologías reusables en la web y en la dominio, o parte
existentes alcance de la literatura. de ellas con su
ontología. descripción.

Enumerar Documento Escribir una lista con todos los términos Terminas y
términos con el usados en la ontología, describir los aspectos
importantes dominio y el términos, su significado y propiedades. importantes de
de la alcance de la modelar en la
ontología ontología, y ontología.
bibliotecas
del dominio.

Definir clases Importantes Existen diversos enfoques para Clases y la

y jerarquía de términos en desarrollar la jerarquía de las clases: jerarquía de
clases la ontología, - Top-down: empieza con la definición de clases.
dominio y la los conceptos más generales en el
descripción dominio y subsecuentemente la
del alcance. especialización de conceptos.
- Bottom-up: el proceso va en dirección
contraria al mencionado anteriormente.
- Combinación de los enfoques Top-
down y Bottom-up
Nota: Adaptado de Cristani, Matteo & Cuel, Roberta. (2005). A Survey on Ontology
Creation Methodologies. Int. J. Semantic Web. Inf Syst. 1, 49-69.
 38

Tabla 4
Pasos de la metodología Ontology Development 101 (continuación).

Fase Entrada Descripción Salida

Definir las La Agregar todas las propiedades necesarias e Clases,

propiedades taxonomía, el información que permitirá a la ontología jerarquía de
de las clases dominio y la responder las preguntas de competencia. clases y
descripción propiedades
del alcance.

Definir las Propiedades Existen diferentes facetas describiendo el Ontología

facetas de las y clases tipo de dato permitido, numero de datos, y
propiedades otras características del valor que la
propiedad puede tener: cardinalidad, tipo de
dato, dominio y rango

Creación de Ontología Crear instancias de los individuos de las Ontología y

instancias clases en la jerarquía, que consiste en elegir dominio
una clase, crear una instancia de un modelado.
individuo de esa clase y llenar los valores
de las propiedades.

Nota: Adaptado de Cristani, Matteo & Cuel, Roberta. (2005). A Survey on Ontology
Creation Methodologies. Int. J. Semantic Web. Inf Syst. 1, 49-69.

Metodología para la Construcción de Sistemas Basados en Ontologías para el

Acceso a Datos

Como se mencionó en el capítulo 3 el paradigma OBDA proporciona una

manera de acceder a la base de datos a través de un vocabulario conocido por los
usuarios mediante la aplicación de técnicas estudiadas en la representación del
conocimiento. Se presentan tres componentes: una ontología, una fuente de datos y
una serie de mapeos declarativos que conecta la fuente de datos con las ontologías.

Sequeda y Miranker (2017) proponen la metodología “Pay-As-You-Go’ para

la creación de la ontología y los mapas para el sistema OBDA, en ella, se especifica
lo siguiente:
 39

Se identifican tres actores en el proceso los cuales son:

 El usuario del negocio: el cuál es el sujeto que tiene el conocimiento

del negocio y puede identificar la lista de preguntas.
 Desarrollador IT: es la persona que tiene el conocimiento con la base
de datos y sabe cómo los datos se interrelacionan.
 Ingeniero de conocimiento: es la persona que sirve como puente entre
el usuario del negocio y los desarrolladores de IT y tiene experiencia
modelando datos usando ontologías.

La metodología es dividida en dos fases:

1. Captura de conocimiento: el objetivo de esta fase es extraer los conceptos y

relaciones de la lista de preguntas del negocio. El ingeniero de conocimiento
trabaja en conjunto con los usuarios del negocio para entender el significado
de los conceptos y relaciones para eliminar la ambigüedad. El segundo
objetivo es el de identificar qué base de datos contiene los datos relacionados
a los conceptos y relaciones extraídos. Así, durante esta fase se realizan las
siguientes actividades:
 Descubrimiento: se descubre los conceptos y relaciones de la lista de
preguntas del negocio e identifica como los conceptos y relaciones se
relacionan con la base de datos.
 Vocabulario: se identifica la terminología como nombres alternativos,
definiciones en lenguaje natural para los conceptos y relaciones.
 Ontología: se formaliza la ontología en OWL de tal manera que cubra
las preguntas del negocio.
2. Implementación: el objetivo de la fase de implementación es habilitar la
contestación de la preguntas conectando la ontología con los datos. Esto es, el
ingeniero de conocimiento toma lo aprendido de los pasos anteriores e
implementa los mapas en el lenguaje en R2RML. La lista de preguntas son
 40

implementadas como consultas SPARQL usando la terminología definida por

la ontología. Por lo tanto, se sugieren las siguientes actividades:
 Mapa: se implementa el mapeado en R2RML, utilizando el resultado
de las actividades de descubrimiento y ontología. Los mapas son luego
usados para configurar el sistema OBDA.
 Consulta: La lista de preguntas son implementadas como consultas
SPARQL usando la terminología presente en la ontología. La
respuesta a las preguntas son los resultados arrojados de la consulta
SPARQL.
 Validación: Se confirma que la consulta SPARQL retorna las
respuestas correctas.

Sequeda (2017) afirma que esta metodología es un primer paso en mostrar

cómo puede aplicarse ingeniería en las ontologías y los mapas de una manera ágil
para el paradigma OBDA. Sequeda menciona, además, que la ingeniería aplicada
para el paradigma OBDA aún es un área de investigación.

Procedimiento Metodológico

Para la realización de este trabajo de investigación, se deberá seguir la

metodología de desarrollo seleccionada para completar cada objetivo específico,
mediante un conjunto de tareas ordenadas.

1. Estudio del funcionamiento y las tecnologías empleadas en los sistemas

pregunta-respuesta actuales.
Para ello, se utilizara la técnica de revisión bibliográfica en donde se
estudiaran los sistemas y aplicaciones que estén relacionados con los sistemas
de búsqueda de respuesta. De tal manera, se investigara el funcionamiento de
las siguientes de las diferentes soluciones que existen para responder las
preguntas formuladas en lenguaje natural. Esto dará como resultado parte de
las especificaciones a considerar al momento de diseñar el sistema.
 41

2. Definición de los requerimientos

Mediante entrevistas con el cliente y la documentación obtenida en la
etapa anterior, se procederá a definir los requerimientos del sistema los cuales
estarán representados por historias de usuario. Además, se obtendrá una lista
priorizada de las historias de usuario que servirán para la especificación de
cada incremento durante la construcción del sistema.
3. Diseño del sistema de búsqueda de respuesta
En esta etapa a partir de los requerimientos obtenidos, se tendrá
información necesaria para determinar el diseño del sistema que permita
responder preguntas realizadas en lenguaje natural orientadas al dominio
turístico en Venezuela. Para lograr esto se tomará la información recopilada
en etapas anteriores en conjunto con diagramas que ayuden a visualizar los
componentes que conforman al sistema. Para esta fase se obtendrá como
resultado un esquema de la arquitectura del sistema de búsqueda de respuesta,
que guiarán la construcción del sistema.
4. Construcción del sistema de búsqueda de respuesta en función al diseño
elaborado.
Luego, en función de los resultados obtenidos en etapas anteriores, se
procederá a construir el sistema de búsqueda de respuesta. Para ello, se
utilizarán las herramientas y técnicas provistas por la Metodología
Momentum, como reuniones diarias, revisión de los avances, planeación de
incrementos, retroalimentación, entre otras. Durante esta fase se incluye la
codificación del sistema y sus respectivas pruebas unitarias. Como resultado,
se obtendrá el sistema de búsqueda de respuesta.
5. Validación del sistema.
Finalmente, con ayuda del cliente se realizará una serie de pruebas al
sistema construido de tal manera de validar y verificar los requerimientos del
sistema de búsqueda de respuesta. El resultado de esta fase otorgará
información acerca de la validez que el sistema posee.
 CAPÍTULO IV

Resultados

En este capítulo, se describen los pasos que se siguieron y los productos

obtenidos durante el desarrollo del trabajo, considerando los antecedentes de
soluciones similares y utilizando como metodología de desarrollo la Metodología
Momentum, descrita en el capítulo 4. Cabe mencionar que, el desarrollo del sistema
formo parte de un módulo de la aplicación que está en desarrollo por la empresa que
lleva por nombre: Travelea. Por lo tanto, se trabajó conjunto a un equipo de
desarrollo el cual tenían asignadas diferentes funcionalidades del producto.

Durante el desarrollo del proyecto, se realizaron varias iteraciones o sprints

donde todos los productos fueron implementados tanto en documentación como en
software funcional; finalmente, este fue validado con el cliente para verificar las
funcionalidades y usabilidad de la herramienta.

Estudio del Funcionamiento y las Tecnologías Empleadas en los Sistemas

Pregunta-Respuesta Actuales

Antes de iniciar la Metodología Momentum, al ser una metodología ágil se

debía tener conocimiento acerca del tema antes de iniciar el desarrollo. Es por ello
que, se investigaron el funcionamiento de diversos sistemas de preguntas y respuestas
previo al desarrollo. Así mismo, se estudiaron los conceptos asociados a este tipo de
sistemas los cuales fueron expuestos en el capítulo 3. Esta investigación dio como
resultado las características principales de sus funcionalidades y diseño.

A continuación, en la Tabla 5 y Tabla 6 se muestran las características más

relevantes de algunos de los sistemas de preguntas y respuestas estudiados.
 43

Tabla 5.
Cuadro con los aspectos de funcionamiento de los sistemas de pregunta y respuesta
estudiados.

Sistema Funcionamiento

START START es un sistema web que permite responder preguntas en

lenguaje natural en idioma inglés. A través del uso de
anotaciones (frases u oraciones) realizadas sobre distintos tipos
de recursos, el sistema realiza un análisis de la consulta realizada
y decidir que anotación es más relevante para la consulta de
manera que una vez encontrada la coincidencia, devolverla una
respuesta. Las ventajas de usar este tipo de técnica, es que el
sistema era capaz de manejar distintos tipos de información como
por ejemplo: textos, diagramas, imágenes, videos, audio, sitios
web, etc.

BASEBALL BASEBALL es un programa capaz de responder preguntas

simples realizadas en lenguaje natural, específicamente el idioma
inglés, sobre los datos que tenía almacenados, usando las listas
como estructura de datos. El sistema recibe un conjunto de
preguntas en forma de cartas, seguidamente la preguntas son
desglosadas en listas de palabras las cuales son identificadas
mediante un diccionario el cual corresponde a una lista que
contiene especificación de palabras. Seguidamente, se aplica un
análisis sintáctico mediante el cual las palabras son etiquetadas,
especificando la información dada y la información solicitada. El
sistema buscará aquella información que coincida con la
descripción de la información solicitada y posteriormente es
realizado el procedimiento necesario para devolver la respuesta.

Sistema de Es un desarrollo en el cual se construía una ontología a partir de

pregunta y un texto que contenía información acerca del modelado de base
respuesta para el de datos relacionales. El texto era analizado y las entidades
modelado de base (conceptos y sus relaciones) eran extraídas e identificadas para su
de datos clasificación en la ontología. Posteriormente, se utilizó un
enfoque basado en patrones con el uso de plantillas de preguntas.
El sistema era capaz de responder preguntas realizadas en idioma
inglés.
 44

Tabla 6.
Cuadro con los aspectos de funcionamiento de los sistemas de pregunta y respuesta
estudiados (continuación).

Sistema Funcionamiento

ATHENA Es un sistema guiado por ontología que proporciona una interface en

lenguaje natural para consultar complejas base de datos relacionales.
Para ello, propone el uso de dos actividades: la primera, la traducción
de la pregunta en lenguaje natural a una consulta definida por un
lenguaje de consulta sobre la ontología, y segundo, traducir esta
consulta a la ontología generada a su correspondiente consulta en SQL.

YAGO-QA Este sistema transformaba preguntas en lenguaje natural a consultas

SPARQL. Para ello, descomponía la pregunta en unidades más
pequeñas y se les asignaba un patrón de triple en SPARQL. Para el
mapeado, utilizaban un enfoque basado en patrones de superficie. Este
método, consiste en buscar las respuestas de la estructura superficial de
los documentos recuperados basándose en una extensa lista de
patrones. La respuesta a una pregunta se identifica sobre la base de la
similitud entre sus patrones que tienen cierta semántica.

WATSON Es un sistema de pregunta y respuesta de dominio abierto desarrollado

por IBM, es capaz de extraer información de contenido estructurado y
no estructurado. Para ello, utiliza diversas técnicas de procesamiento de
lenguaje natural, representación de conocimiento, recuperación de la
información, reglas lógicas, entre otras áreas de computación. Para
preguntas complejas, WATSON las descompone en unidades más
pequeñas con la meta de obtener subconsultas que serán realizadas a
diversas fuentes de información o bases de conocimiento como
DBPEDIA, Freebase.

QACID Es un sistema de búsqueda de respuestas basado en ontologías de

dominio cerrado que utiliza una base de conocimiento que permite
asociar preguntas en lenguaje natural con una representación formal de
datos. Utiliza una técnica de implicación textual la cual se basa en
detectar las implicaciones entre las preguntas y la base de
conocimiento. Con este proceso, se permite asociar consultas SPARQL
a las preguntas de entrada y así recuperar las respuestas desde los datos
RDF.
 45

Como se observó en la tabla anterior, existen diversos enfoques para la

construcción de los sistemas de preguntas y respuesta. Debido a la naturaleza de los
datos, el sistema desarrollado en este trabajo es un sistema de pregunta y respuesta
sobre el dominio turístico en Venezuela, por lo que es de dominio cerrado y mediante
el cual se espera extraer información sobre datos estructurados almacenados en una
base de datos relacional utilizando el lenguaje natural como interfaz.

Definición de los requerimientos

La Metodología Momentum propone dos procesos iniciales, los cuales son el

levantamiento de requerimientos y el Release Planning, ambos, con la finalidad de
delimitar el esquema inicial del producto. Por consiguiente, se delimitó el sistema de
preguntas y respuestas orientado al dominio turístico en Venezuela.

A continuación, se describen las actividades realizadas:

Levantamiento de requerimientos.

Como el software a desarrollar es un producto interno de la empresa, se usó la

técnica de entrevista no estructurada con el Product Owner y la revisión documental
realizada anteriormente para levantar los requerimientos iniciales de la aplicación.
Esto, con el fin de definir el alcance de la aplicación con el documento de contexto
definido por la metodología, el cual se especifica en el Anexo A.

Release planning.

Con el documento de contexto definido en la actividad anterior, se procedió a

construir el product Backlog, listando todo lo necesario por el producto, el cual es
representado por un conjunto de historias de usuario, priorizadas por el Product
Owner y con un tiempo estimado de desarrollo.
 46

A continuación, se describe un extracto del product Backlog que corresponden

a las historias de usuario del sistema pregunta-respuesta con su información de
interés:

1. Consulta en lenguaje natural: Consultar la base de datos del negocio en

lenguaje natural
2. Módulo de soporte para preguntas Brindar un módulo administrativo que
brinde información a los desarrolladores y product Owner sobre las preguntas
realizadas al sistema.

Sin embargo, la historia de usuario titulada consulta en lenguaje natural fue

subdividida en dos sub historias debido a la complejidad en sus tareas. Por lo tanto,
fue sub dividida en las siguientes historias de usuario:

1. Representación del conocimiento: Consultar la base de datos del negocio sin

conocer el esquema, esto a través de un vocabulario conocido por el usuario y
el sistema.
2. Procesamiento de la pregunta en lenguaje natural: transformar la consulta en
lenguaje natural a una consulta estructurada.

Para completar la información descrita anteriormente, en la Tabla 7 se indican el

resto de la información referente a cada historia de usuario. Cabe mencionar que, la
prioridad fue dada por el Product Owner y la estimación del tiempo fue realizada a
través de una reunión con el equipo de desarrollo en donde se definió el tiempo
estimado de cada historia de usuario.
 47

Tabla 7. Información de historias de usuario

ID Titulo Tiempo Prioridad Descripción

estimado
(semanas)

1 Representación 3 alta Consultar la base de datos del

del conocimiento negocio sin conocer el esquema,
a través de un vocabulario
conocido por el usuario y el
sistema.

2 Procesamiento de 3 alta Transformar la consulta en

la consulta en lenguaje natural a una consulta
lenguaje natural estructurada.

3 Módulo de 2 media Brindar un módulo

soporte para administrativo que brinde
preguntas información a los
desarrolladores y product
Owner sobre las preguntas
realizadas al sistema. De manera
que brinde apoyo en la toma de
decisión para la incorporación
de nuevo conocimiento para la
contestación de nuevas
preguntas.

Diseño y construcción del sistema de búsqueda de respuesta

Se debe mencionar, que la construcción del sistema contó con el desarrollo de

varios sprints. Al inicio de cada sprint, se realizó la actividad del Sprint Planning,
mediante la cual se seleccionaron un conjunto de historias de usuario del Product
Backlog. En este sentido, las historias de usuario presentadas anteriormente fueron
seleccionadas y agrupadas para producir un entregable que sería un sistema que
brinda la contestación de preguntas en lenguaje natural.
 48

Así mismo, durante esta actividad se definió la manera en que se daría

solución a los entregables. Como resultado, se construyó el Sprint Backlog el cual es
descrito a continuación.

Sprint backlog.

La historia de usuario con el identificador número 1, se resolvió de la

siguiente manera: El desarrollo se realizó bajo el paradigma OBDA (Ontology Based
Data Access), en el cual se prevé que un usuario pueda consultar la base de datos
(BD) del negocio, sin conocer el esquema, a través del vocabulario definido por una
ontología la cual se usará como técnica de representación del conocimiento.

Para la construcción de la ontología, se utilizó la metodología mencionada en

el capítulo 3, propuesta por Noy y Mcguinness, también conocida como “Ontology
Development 101”, mediante la cual, se implementaran los pasos descritos en la
metodología.

Así mismo, se usará el editor de ontologías Protégé en su versión 5.2 para la

codificación en el lenguaje OWL. Esta herramienta, es de código abierto, fue
desarrollada por la universidad de Stanford y es ampliamente utilizada en diversos
proyectos que involucran construcción de ontologías en la actualidad.

Para la aplicación del paradigma OBDA se usó el framework ONTOP, el cual

es de código abierto, posee una licencia Apache, utiliza las recomendaciones dadas
por la W3C para la web semántica, posee una extensión en el editor Protégé y soporta
diversos manejadores de bases de datos. Se siguió los pasos descritos en la
metodología para la construcción de sistemas basados en OBDA descrita en el
capítulo 3.

La documentación de este framework ofrece y recomienda utilizar el servidor

web JETTY pre configurado con el framework RDF4J y ONTOP. Así, brinda un
endpoint de consultas SPARQL vía HTTP al repositorio donde se almacena la
 49

ontología, el mapeado de los datos y los datos de conexión a la base de datos. De esta
manera, se seguirán las instrucciones dadas por el framework para la configuración
del sistema.

En la Figura 7 se muestra el diagrama de la arquitectura inicial del sistema

con las herramientas utilizadas. A continuación se explican con detalle el
funcionamiento de cada herramienta:

Figura 7. Arquitectura inicial del sistema con las herramientas utilizadas

 SGBD: Representa el manejador de bases de datos necesario para cumplir las

tareas de almacenamiento de datos del negocio. En el caso de este sistema, vendrá
dado por la base de datos desarrollada por el equipo de desarrollo del sistema
Travelea, la cual esta implementada en el manejador de bases de datos
PostgreSQL y que se tendrá acceso a ella mediante el conector de bases de datos
JDBC. En la Figura 8, se muestra la vista de la base de datos para el sistema de
pregunta y respuesta.
 50

Figura 8. Vista de la base de datos del sistema Travelea para el sistema de preguntas
y respuestas.

 Servidor RDF4J y SPARQL Endpoint: Como se mencionó en las historias de

usuario, es necesario brindar al usuario un endpoint mediante el cual pueda
consultar la base de datos a través de la ontología. El servidor RDF4J brinda un
acceso vía HTTP que permite acceder a los repositorios RDF, exponiéndolos
como un SPARQL Endpoint.
 Sistema OBDA - ONTOP: Es el componente que permite realizar consultas a una
base de datos a través de una ontología por medio de consultas SPARQL. El
framework utiliza un motor SPARQL llamado Quest, que está contenido en el
servidor RDF4J el cual es usado en el repositorio donde está alojada la ontología.
En este repositorio, también se encuentra los mapeados y conexión con la base de
datos. El modo en que se utilizara el repositorio es ONTOP Grafo virtual RDF,
este modo también es llamado Virtual Abox. En este modo Quest recibe como
entrada una ontología RDFS/OWL2QL y un conjunto de mapeos (en un archivo
 51

con extensión .obda). Quest usará los mapeos para traducir las consultas SPARQL
sobre la ontología a consultas SQL sobre la base de datos definida en el archivo
de propiedades.
 Mapeado: Conecta la ontología con la fuente de datos a través de la definición de
las relaciones entre los conceptos del dominio y los datos a través de un archivo
.obda.
 Ontología: Es el componente que representa el conocimiento o los conceptos y
sus relaciones presentes en el dominio turístico Venezolano. Será codificada
usando el estándar OWL 2 QL propuesto por la W3C para la codificación de
ontologías en sistemas OBDA.

La historia de usuario con el identificador número 2, se resolvió de la

siguiente manera: Para la resolución de la consulta en lenguaje natural se utilizó un
enfoque basado en patrones de preguntas, estos patrones pueden ser representados
mediante expresiones regulares que contienen partículas correspondientes al lema de
las palabras claves y etiquetas de parte de la oración. Además, se debió implementar
una interfaz (API Rest) que permita recibir las consultas realizadas en lenguaje
natural por los usuarios de la aplicación “Travelea” y retornar una respuesta a su
consulta.

Debido a que identificar todas las maneras que una pregunta puede ser
realizada en lenguaje natural es bastante amplio, se implementó un módulo de
búsqueda de similitud con preguntas que el sistema ya conoce. El módulo de
similitud estará basado en identificar las palabras como vectores por medio del
análisis sintáctico de las palabras contenidas en la consulta y aplicar el cálculo de la
similitud basada en cosenos entre las preguntas.

Como herramienta, se utilizara el framework de desarrollo Django, escrito en

Python, debido a que es un estándar propuesto por la empresa para el desarrollo del
sistema. De esta forma, para la aplicación del enfoque basado en patrones de
 52

preguntas se integró un framework de Python para la transformación de la pregunta al

lenguaje de consulta SPARQL llamado Quepy.

En la Figura 9, se muestra la arquitectura del sistema integrando el servidor de

pregunta y respuesta que se encargara de transformar la pregunta en lenguaje a
natural a una consulta estructurada en el lenguaje de consulta SPARQL, en términos
del vocabulario definido en la ontología, que será realizada a la ontología mediante el
SPARQL endpoint definido en el desarrollo de la historia de usuario con identificador
número 1.

Figura 9. Arquitectura del sistema correspondiente a la segunda iteración.

La historia de usuario con el identificador número 3 se resolvió de la siguiente

manera: Se desarrolló un sistema administrativo web para el sistema pregunta-
respuesta con el fin de brindar al equipo de desarrollo y cliente, un sistema para que
apoye a la toma de decisiones en base a las preguntas realizadas con el fin de:
aumentar el conocimiento al sistema mediante la inclusión de nuevos conceptos en la
ontología, incremento en los datos que almacena el negocio, revisión de los patrones
de preguntas para la inclusión de nuevos, evaluación del rendimiento del sistema,
visualización de preguntas contestadas y no contestadas. Para ello, se almacena en
una base de datos las preguntas realizadas al sistema y obtener la calificación dada
por el usuario a la respuesta enviada por el sistema, con el fin de validar si fue la
pregunta fue respondida correctamente o no.
 53

Para la evaluación del rendimiento del sistema se utilizó la información que es

almacenada de las preguntas realizadas al sistema. Para ello, se utilizaran métricas
utilizadas para la evaluación de rendimiento en sistemas de búsqueda de información,
como lo es el Recall el cual mide los resultados relevantes recuperados según la
consulta del usuario, y Precision el cual es la medida de los resultados recuperados
que son relevantes para el usuario (B.Sujatha, 2016, p.490). Por lo tanto, las métricas
serán calculadas con las siguientes formulas presentadas en la Figura 4:

Figura 10. Fórmulas para el cálculo del Recall y Precision del sistema. Adaptado de
“Ontology Based Natural Language Interface for Relational Databases” por
B.Sujatha, .S.Viswanadha, 2016, Procedia Computer Science, 92, p.490, Copyright
2016 por los autores.

Donde Preguntas contestadas correctamente, son la cantidad de preguntas

que el sistema logro responder con información relevante para el usuario, Preguntas
contestadas la cantidad de preguntas que el sistema pudo contestar y Total de
preguntas la cantidad total de preguntas realizadas al sistema.

Para el módulo de soporte, se propuso un registro en caso de que una pregunta

no pudo ser contestada, cuáles fueron los motivos del porque no pudo responder. Para
ello, en base al requerimiento planteado, se proponen los siguientes casos con los
posibles escenarios.

1. Si la pregunta realizada por el usuario no está en los patrones de preguntas

conocidas por el sistema y el porcentaje de similitud con preguntas
previamente contestadas es menor al 95% se concluye que el sistema no
puede reconocer el patrón de pregunta realizada, por ende se almacenará
 54

como mensaje en base de datos sobre la pregunta “Patrón no encontrado”.

Entre las acciones que deberá realizar el usuario de soporte serán:
a. Analizar el patrón de la pregunta y encontrar otras posibles preguntas
que puedan ser usadas por dicho patrón.
b. En caso de que la pregunta esté dentro del alcance del sistema y se
tengan los datos para responder, el patrón será incluido en la lista de
patrones de preguntas y se construye la representación semántica de la
misma sobre la base de conocimiento. Si no se tienen los datos para
responder, se deberá realizar los pasos correspondientes al caso 2.
2. Si la pregunta fue asignada a un patrón conocido por el sistema, pero al
resolver la pregunta no se obtuvo ningún dato, se deberá almacenar la
pregunta con mensaje “Pregunta no respondida”.
a. Analizar la pregunta y revisar la base de conocimiento para corroborar
si los conceptos usados por el usuario se encuentran con otro nombre
similar o no existe este concepto.
b. Si se desea incluir el conocimiento en el sistema se deberá evaluar la
posibilidad de incorporar dicho conocimiento en el sistema en base a
los datos que contiene la base de datos del negocio, incorporación del
nuevo concepto en la ontología y asignación del mapeado de la
terminología nueva incorporada con la fuente de datos.

Así mismo, se diseñó las interfaces preliminares del sistema

administrativo, a continuación, en las Figuras 11, 12 y 13 se presentan las
interfaces diseñadas.
 55

Figura 11. Diseño preliminar del módulo para la visualización de preguntas no

respondidas en el sistema administrativo.

Figura 12. Diseño preliminar del módulo para la visualización del rendimiento del
sistema administrativo
 56

Figura 13. Diseño preliminar del módulo para la realización de preguntas desde el
sistema administrativo.

Codificación.

Luego de definir los entregables en la actividad de Sprint Planning, se

procedió a realizar la etapa de codificación.

Representación del conocimiento.

Primero, se procedió a realizar el desarrollo de la historia de usuario 1 (ver

tabla 4) la cual era de mayor prioridad para el Product Owner y se seleccionó para el
primer sprint. Esta comprendió las siguientes tareas:

Construcción de una ontología del dominio turístico en Venezuela.

Como se había mencionado anteriormente, en la solución propuesta para esta

actividad se utilizara la metodología presentada en el capítulo 3 para el desarrollo de
ontologías propuesta por Noy y Mcguinness (1995) “Ontology Development 101”.

Así, se describió el contenido semántico del dominio, posteriormente se

utiliza la herramienta Protégé para obtener una representación formal de la ontología
 57

en el lenguaje OWL. Para ello, se siguieron los pasos propuestos en la metodología y

se obtuvieron los siguientes resultados:

1. Determinar el dominio y alcance de la ontología

Como primer paso para el desarrollo de una ontología se realiza un
documento de especificación en donde se define su dominio y alcance. Para la
determinación del alcance, la metodología propone realizar un bosquejo de la
lista de preguntas que la base de conocimiento basado en la ontología debería
ser capaz de responder (ver Tabla 6). Esta lista de preguntas también son
llamadas preguntas de competencia por Gruninger y Fox 1995. Para la
realización de las preguntas de competencias, se utilizó la técnica de la
entrevista no estructurada con el cliente, usuarios expertos en el área del
turismo y usuarios potenciales de la aplicación con el fin de obtener un listado
de preguntas que las personas comúnmente realizan durante un viaje.
 ¿Cuál es el dominio que la ontología cubrirá?

Respuesta: El dominio de la ontología es la representación de información

turística en Venezuela.

 ¿Para qué usaremos la ontología?

Respuesta: Se planea utilizar la ontología para apoyar el procesamiento del

lenguaje natural en la búsqueda de información sobre este ámbito del turismo.

 ¿Para qué tipos de preguntas la información en la ontología deberá proveer

respuestas?:

Respuesta: Se utilizó la técnica de entrevista no estructurada con el cliente,

distintos expertos en el área del turismo y usuarios del sistema. De aplicar el
instrumento, se obtuvo una serie de preguntas (ver Tabla 8) que fueron las
más comunes que los usuarios realizaban al momento de viajar y durante el
 58

viaje, posteriormente fueron revisadas con el cliente para validar el alcance

que tendría la ontología y que la base de datos debería dar soporte.

 ¿Quién usará y mantendrá la ontología?:

Respuesta: La ontología será usada para la aplicación en desarrollo por la

empresa Momentum Lab, C.A llamada Travelea. Para la etapa de
mantenimiento el ingeniero experto en conocimiento y desarrolladores serán
garantes de mantener y expandir el conocimiento en futuros escenarios.

Tabla 8.
Extracto de preguntas de competencia

Preguntas de competencia

¿Qué playas hay en Margarita?

¿Dónde puedo comer Pizza?
Líneas de taxi en Margarita
Quiero un helado
¿Dónde están los centros comerciales?
¿Qué supermercado queda más cerca?
¿Dónde puedo comer?

Juzgando a partir de las preguntas de competencias, la ontología incluirá

la información de varios lugares físicos a los cuales una persona puede visitar.
Estos lugares pueden ser sitios turísticos, sitios no turísticos o servicios turísticos.
Así mismo, la clasificación de las diferentes actividades que pueden realizarse en
dichos lugares, información geoespacial. Como la ontología será usada para
apoyar al procesamiento del lenguaje natural, es importante incluir sinónimos e
información de las varias clases de palabras a las cuales un concepto puede estar
relacionado en la ontología.

2. Consideración de la reutilización de ontologías existentes

Se ha identificado la existencia de una ontología desarrollada por

Dulcey y Ramos (2015) que conceptualiza el dominio turístico en Venezuela
 59

en una ontología enfocándose los posibles lugares que un turista puede visitar
en un determinado viaje y los servicios turísticos que se pueden brindar
durante su estadía en un lugar determinado.

Esta ontología está formalizada e implementada en el sub-lenguaje

OWL DL de OWL. Por lo tanto, la importación de la misma puede ser el
primer paso hacia la identificación de términos y clasificación de los lugares y
servicios turísticos. Sin embargo, para la construcción de la ontología del
presente trabajo se seleccionó el sub-lenguaje OWL 2 QL debido a que es el
estándar que propone W3C para la recuperación de datos en bases de datos
relacionales desde la ontología, por lo que, se importara solamente la
clasificación y jerarquización de conceptos y propiedades de conceptos
propuesta por Dulcey y Ramos (2015).

3. Enumerar términos importantes para la ontología

En esta etapa, se realiza una lista integral de términos con los que se
quisiera hacer enunciados o dar explicación al usuario sin preocuparse de las
relaciones entre estos, propiedades o si pertenece a una clase o propiedad.
Como producto de las preguntas de competencia recopiladas en la etapa
anterior se pueden identificar los siguientes términos:
Localidad, playas, centros comerciales, establecimientos, diferentes
tipos de alimentos como sushi o pizza, hospedaje en general, hotelería,
servicios de hospedaje como wifi, número de estrellas, características de
lugares, ubicación de los lugares, eventos, horarios de apertura, servicios
turísticos, Líneas de taxi, Ferias de comida, Restaurantes, sitios para comer,
sitios para dormir, restaurantes, margarita.
4. Definir clases y jerarquía de clases
Como se mencionó en el capítulo 3, existen diferentes enfoques para el
desarrollo de la jerarquía de clases, entre ellos podemos mencionar:
 Top Down: Desde conceptos generales a más específicos.
 Bottom up: Desde conceptos específicos a más generales.
 60

 Combinación de ambos: Guiando por conceptos generales y

específicos destacados e introduciendo conceptos medios que
los unan.

Dada la lista de términos relevantes identificados en la actividad

anterior se observa que la ontología deberá manejar una clasificación de sitios
a los cuales un turista puede visitar ya sea turístico o no turístico y de
servicios turísticos. La ontología considerada para su reutilización
proporciona dos taxonomías acerca sitios de interés y servicios turísticos que
servirán como base para la definición y clasificación de los términos debido a
que brindan la conceptualización del conocimiento de los lugares y servicios
turísticos en Venezuela. En la Tabla 9, se muestra un extracto de las clases
definidas con su descripción.

Por lo tanto, varios de los términos a utilizar están formalmente

clasificados y servirán como base para la elaboración de la ontología. De esta
manera, se evitará la redundancia de clases que ya están definidas. Para ello se
utilizará un enfoque combinado con las nuevas clases que se incorporaran

Tabla 9.
Extracto de clases definidas y su descripción

Clase Descripción

Sitios para dormir Lugar donde una persona puede descansar y hospedarse.
Sitios para comer Lugar donde una persona puede ingerir alimentos o bebidas.
Estación de servicio Instalación situada cerca de una vía de circulación rápida que
dispone de expendedores de combustible y generalmente de
otros servicios, como teléfono, supermercado, etc.
Ferretería Es un establecimiento comercial dedicado a la venta de útiles
para la construcción y las necesidades del hogar.
Mercado de alimentos Establecimiento comercial donde se vende diversos
productos alimenticios.
Abastos Tienda de comestibles y artículos para el hogar.
 61

Seguidamente, se procede a jerarquizar los conceptos definidos de tal

manera que se puedan combinar con los conceptos de la ontología definidos
en el dominio ya conceptualizado. En las Figuras 14, 15 y 16 se muestran
extractos de las taxonomías que contiene la ontología.

Figura 14 Extracto de taxonomía de servicios turísticos clasificada por Dulcey y

Ramos (2016)

Figura 15. Extracto de la taxonomía resultante de sitios de interés luego de aplicar el

enfoque combinado en la jerarquización de las clases
 62

Figura 16. Taxonomía de localidades

5. Definir las propiedades de las clases y facetas de las propiedades

De igual manera, la ontología que se considera reutilizar contiene
diferentes propiedades que se pueden encontrar en servicios de hospedaje. Por
lo tanto, se considerará incorporar aquellas propiedades que no están presentes
en el vocabulario y que forman parte del dominio de la ontología en
desarrollo. Las propiedades que se incorporarán deberán estar en la clase más
general que pueda tener esa propiedad. Esto debido a que las propiedades que
contenga una clase serán heredadas por todas aquellas subclases. Así mismo,
se puede definir si existe alguna restricción sobre qué clases pueden tener la
propiedad, a través de su dominio. También, se puede especificar el rango de
valores que puede tener la propiedad siendo esta una clase o un literal. Añadir
estas restricciones permite además realizar inferencias, basado en el uso de la
propiedad. En la Tabla 10, se muestra un extracto de las propiedades
identificadas y las restricciones que se establecen.

Tabla 10. Extracto de propiedades y sus facetas

Propiedad Dominio Rango

Latitud No posee Decimal

Longitud No posee Decimal
especialidad Sitios de comida y bebida String
Tarjeta de crédito No posee String
Tags No posee String
Tiene vecinos No posee No posee
Se localiza en No posee Organización Territorial
 63

6. Creación de instancias
El último paso de la metodología consiste en crear instancias de clases
en la jerarquía. La definición de una instancia individual requiere: elegir una
clase, crear una instancia individual de la clase y rellenar los valores de la
clase. Sin embargo, la mayoría de los individuos que tendrá nuestra base de
conocimiento estarán almacenados en la base de datos del negocio.

Por lo tanto, como resultado de aplicar la metodología se obtuvo una

ontología de dominio turístico en Venezuela. La cual será utilizada en la siguiente
tarea en la aplicación del paradigma OBDA para acceder a los datos contenidos en la
base de datos del negocio.

Aplicación del paradigma OBDA.

Para el cumplimiento de esta tarea, se utilizó la metodología “Pay-As-You-

Go” propuesta por Sequeda y Marinker (2017) presentada en el capítulo 3.

Cabe mencionar que, solo se realizó la fase de implementación, debido a que

la fase de captura de conocimiento se enfoca en la creación de la ontología, la cual se
obtuvo como resultado de la tarea anterior. Además, durante el proceso de
construcción se tenía comunicación con los encargados del desarrollo de la base de
datos del sistema Travelea. De esta manera, se obtuvo el conocimiento de la
información que estaba contenida en base de datos y su esquema.

Así mismo, la lista de preguntas de competencia desarrollada en la tarea

anterior, corresponden a la lista de preguntas del negocio propuesta por la
metodología “Pay-As-You-Go".

 Fase de implementación

Durante esta fase se utilizó el editor de ontologías Protégé con la extensión del
framework de OBDA ONTOP. De esta manera, era posible realizar los mapas en
 64

R2RML desde el editor así como realizar la actividad de consulta y validación. A

continuación se detalla cada una de las actividades de esta fase:

1. Mapeo: Primero se estableció una conexión con la base de datos utilizando el

driver JDBC para PostgreSQL (ver Figura 8).

Figura 17 . Conexión con base de datos

Seguidamente, se realizó el mapeado (ver Figura 18) de los datos presentes en

base de datos con los conceptos y relaciones de la ontología.

Figura 18. Extracto de mapas de datos con conceptos y relaciones en la ontología

 65

2. Consulta y validación: durante esta actividad se tomaron las preguntas de

competencia que formaban parte del alcance de la ontología y se
implementaron como consultas SPARQL, de esta manera se validaron dos
componentes: la ontología de manera que brindara el vocabulario para
expresar la pregunta, y la base de conocimiento para corroborar que podía dar
respuesta a las consultas.
Por ejemplo, en la figura 19 se muestra la pregunta de competencia
¿Que playas hay en Margarita? la implementación como consulta en
SPARQL y los resultados obtenidos. Se debe recordar que los datos de los
sitios están contenido en la base de datos del negocio por lo que existirán
preguntas que la base de conocimiento no podrá contestar debido a que no se
poseen los datos para dar respuesta a esa pregunta

Figura 19. Consulta en SPARQL y resultados de la pregunta de competencia ¿Que

playas hay en Margarita?

El desarrollo de esta historia de usuario fue un proceso incremental, mediante

el cual al final de cada sprint durante la actividad Sprint Review se consultaba con el
cliente y el equipo de desarrollo, la posibilidad de considerar nuevos datos en el
modelo de negocio en base a las preguntas de competencia. La naturaleza de la
 66

metodología de desarrollo aplicada por la empresa permite considerar nuevos

cambios sobre el proceso de construcción, por lo que la incorporación de estos
nuevos datos al modelo de negocio no causaban problemas.

Luego, para brindar la posibilidad de consultar la ontología vía http se utilizó

la recomendación del servidor web Jetty pre configurado propuesta por el framework
ONTOP, para brindar un SPARQL endpoint. A continuación se explica cómo
interactúan las herramientas utilizadas: Jetty el cual es un servidor web basado en
Java y contenedor de servlets escritos en Java, se utiliza debido a que se necesita una
aplicación que utilice el protocolo HTTP y que permita expandir sus capacidades a
través de servlets escritos en Java . Para expandir las capacidades del servidor web
para trabajar con repositorios RDF se utiliza el framework Eclipse RDF4J que brinda
la posibilidad de almacenamiento, razonamiento y acceso vía HTTP a los repositorios
contenidos, exponiéndolos como SPARQL endpoint. Así luego, se incluye como
aplicación web el motor utilizado por el framework ONTOP de manera que pueda ser
utilizado y expuesto como un SPARQL endpoint brindando la capacidad de utilizar la
funcionalidad de los sistemas OBDA.

Cabe mencionar que, se configuró el repositorio con el modo de grafo virtual

RDF ofrecido por el motor Quest en el cual recibe como entrada una ontología
RDFS/OWL2QL, un archivo de propiedades con los datos de la conexión de la base
de datos y un conjunto de mapas entre la ontología y la base de datos. Como se
observa, los tres documentos fueron productos obtenidos en tareas previas. En la
figura 20 y 21 se muestra la configuración del repositorio.
 67

Figura 20. Configuración del repositorio RDF

Figura 21. Configuración de los componentes para el sistema OBDA

Procesamiento de la consulta en lenguaje natural.

Posteriormente, se abordó la historia de usuario 2 que contempla el desarrollo

del módulo encargado de servir como interfaz entre la consulta realizada en lenguaje
natural y la fuente de datos. A continuación se muestran los resultados y las tareas
involucradas en la historia de usuario.

El objetivo de esta tarea es la transformación de una consulta en lenguaje

natural a una consulta SPARQL que será realizada a la base de conocimiento
desarrollada en la historia de usuario anterior. Para ello, se utilizó un enfoque basado
en patrones de plantillas de preguntas. Como se explicó en el capítulo 3, este enfoque
 68

con un patrón se puede abarcar una diversa cantidad de datos relevantes y todas las
preguntas de ese estilo. Sin embargo, este enfoque requiere de gran esfuerzo humano
y tiempo para la elaboración de una amplia variedad de patrones, por lo que
incrementar el número de patrones que el sistema conocerá es un proceso irá
evolucionando a medida que se identifiquen nuevos patrones y se incorporen. Por
consiguiente, las preguntas de competencias utilizadas en la construcción de la
ontología servirán de base para la creación de una primera versión de los patrones de
preguntas.

Para llevar a cabo este enfoque, se utilizó el framework Quepy, mencionado

en la fase de diseño en el sprint backlog, que brinda la posibilidad de transformar
preguntas en lenguaje natural a una consulta en formato SPARQL utilizando un
enfoque basado en patrones de preguntas, parecidos a expresiones regulares pero
enriquecidos con información sintáctica que ayuda a ser más expresivos.

La librería tuvo que ser modificada para que pudiera aplicar elementos de
procesamiento de lenguaje natural sobre preguntas realizada en español. Para ello se
incorporó el módulo de Pattern el cual es un módulo lingüístico para python que
brinda un etiquetador que ayuda analizar lenguaje natural y ofrece soporte para el
idioma español, anteriormente se habían probado otras herramientas como nltk,
StanfordTagger pero no se obtuvieron los resultados esperados analizando la pregunta
en el idioma español, por lo tanto, se decidió utilizar la herramienta Pattern que
brindaba mejores resultados etiquetando palabras en el idioma español.

Por ejemplo, para la pregunta ¿Qué playas hay en Margarita? Se puede

identificar el patrón de preguntas ¿Qué {concepto} hay en {localidad}?. Además,
agregando información sintáctica sobre el patrón se puede establecer que:

 {localidad}: corresponde a una posible agrupación de sustantivos, nombre

propio, singular o plural.
 69

 {concepto}: corresponde a una posible agrupación de sustantivos, nombres

propio, singular o plural.

Luego, a partir de la información obtenida del patrón de la pregunta se

construye su representación semántica a través de una consulta SPARQL en la cual
son usadas las entidades obtenidas de la pregunta. Siguiendo el ejemplo anterior, la
pregunta ¿Qué playas hay en Margarita? estaría representada por la consulta en
SPARQL presentada en la Figura 22.

Figura 22. Consulta SPARQL para la pregunta ¿Qué playas hay en Margarita?

De esta manera, se construyó una lista de patrones identificados. En la Figura

23 se observa la codificación para el ejemplo de la pregunta presentada anteriormente
y en la Figura 24 se muestra un patrón distinto que resolvería las preguntas del tipo:
¿Dónde puedo comer {especialidad}?

Figura 23. Patrón: ¿Qué {concepto} hay en {localidad}?

 70

Figura 24. Patrón: ¿Dónde puedo comer {especialidad}?

Posteriormente, se desarrolló una API Rest mediante la cual se brinda un

endpoint que recibirá una consulta en lenguaje natural, en el Anexo B se muestra la
documentación del API desarrollado. En la Figura 25 y Figura 26, se muestra el envío
al servidor de las preguntas en lenguaje natural: ¿Dónde puedo comer sushi? y ¿Qué
playas hay en Margarita? respectivamente.

Figura 25. Ejemplo de pregunta: ¿Dónde puedo comer sushi? enviada al servidor
 71

Figura 26. Ejemplo de pregunta: ¿Qué playas hay en Margarita? enviada al servidor

Como se observa, se obtuvieron los resultados correspondientes a los sitios

donde se puede comer sushi según mi posición actual y a las playas pertenecientes a
la localidad de Margarita. En la Figura 27 y Figura 28 se muestra la consulta
SPARQL generada a partir de las preguntas: ¿Dónde puedo comer sushi? y ¿Qué
playas hay en Margarita? consultadas anteriormente.

Figura 27. Consulta SPARQL generada a partir de la pregunta: ¿Dónde puedo comer
sushi?
 72

Figura 28. Consulta SPARQL generada a partir de la pregunta: ¿Que playas hay en
Margarita?

Cabe destacar que, algunas de las preguntas obtenidas durante el desarrollo de

la ontología trataban acerca de consultas geoespaciales, como por ejemplo cercanía
de sitios y obtención de recomendaciones. Por lo que, dichas preguntas serán tratadas
de la siguiente manera:

 Consultas geoespaciales: dado las coordenadas del usuario se filtraran

aquellos sitios que estén cercanos a su posición. Las coordenadas serán
obtenidas a través del API del servidor. Esto se aplicara para los patrones de
pregunta que requieran filtrar por cercanía.
 Consultas personalizadas: para la obtención de recomendaciones, el sistema
Travelea propone un sistema de recomendación y de perfilado que ofrecen
la personalización de recursos según el perfil del usuario. Por ello, el
sistema de pregunta-respuesta tendrá una interfaz con el sistema de
recomendación, de manera que, para aquellas preguntas que sean de esta
categoría, se filtrara la respuesta a través del sistema de recomendación, así
devolviendo solo aquellos resultados que sean de interés para el usuario
según su perfil.
 73

Módulo de soporte para preguntas.

Finalmente, se desarrolló el módulo de administrativo para el sistema de

pregunta y respuesta. Para ello, se siguieron las características de diseño definidas en
la etapa de planificación del entregable. A continuación se presenta un caso de
estudio y los resultados obtenidos serán presentados a través del sistema
administrativo.

Caso de estudio.

Se estableció realizar un total de 30 preguntas al sistema con el fin de

visualizar su comportamiento y rendimiento. Para ello, se establecieron las siguientes
distribuciones en las preguntas aplicadas:

 5 preguntas que el sistema conocía los patrones.

 5 preguntas que el sistema no conocía los patrones.
 5 preguntas que el sistema parcialmente conocía los patrones
 15 preguntas al azar a personas que no tuviesen conocimiento acerca del
sistema.

En el Anexo C, se muestran las distintas preguntas aplicadas y los resultados

obtenidos.

En la Figura 29, se presenta el módulo de pruebas. Este módulo brinda la

posibilidad al administrador de realizar consultas en lenguaje natural desde el sistema
administrativo. De esta manera, se puede probar el funcionamiento del sistema y
verificar las respuestas otorgadas. Así, durante el caso de estudio se utilizó este
módulo como interfaz para realizar las preguntas al sistema.
 74

Figura 29. Módulo de pruebas del sistema administrativo.

En la Figura 30, se presenta el módulo de rendimiento. Este módulo brinda la

posibilidad al administrador de visualizar las estadísticas del sistema. De esta manera,
usando las métricas propuestas en la etapa de diseño se puede observar el rendimiento
del sistema luego de aplicar el caso de estudio.

Figura 30. Módulo de estadísticas del sistema administrativo

Analizando el caso de estudio, se obtuvieron los siguientes resultados:

Precision = 0.76 y Recall = 0.53. Estos resultados indican que el 76% de las
 75

preguntas realizadas al sistema lograron ser respondidas y 53% de las respuestas son
relevantes para el usuario. Existen diversas razones que pueden explicar los valores
obtenidos, en primer lugar, se tiene una versión inicial de patrones de preguntas que
modelan preguntas factuales. Este tipo de preguntas, son las que devuelven un hecho
en particular. En este caso, los sitios que el usuario este consultando. Como se
mencionó anteriormente, el sistema mejorara a medida que aumenta el uso, pues, se
incrementara la cantidad de patrones conocidos por el sistema. De este modo, se
mejoraría su rendimiento..

Adicionalmente, es posible que la ontología no abarque todos los sinónimos

que un usuario podría utilizar al momento de preguntar o que dicho concepto no se
encuentre definido, por lo que el sistema no tendrá conocimiento acerca de lo que se
solicita. Además, existe una reducida cantidad de sitios almacenados en la base de
datos del negocio, y por ello, se pueden presentar situaciones en donde el sistema
conozca el concepto, tenga el patrón de la pregunta pero no se tienen los individuos.
Por lo tanto, a medida que el sistema vaya incorporando nuevos datos, tendrá un
mejor rendimiento.

Así también, se analizaron los distintos casos planteados según la distribución

en las preguntas y se obtuvieron los siguientes resultados:

 Las 5 preguntas conocidas por el sistema fueron respondidas.

 De las preguntas no conocidas, se obtuvo que 4 de las preguntas no fueron
identificadas por los patrones y no se obtuvieron resultados y 1 fue
identificada pero no se obtuvo resultados.
 De las preguntas parcialmente conocidas se obtuvo que 3 de las preguntas
no fueron identificadas y 2 fueron respondidas a través de una pregunta
similar.
 De las preguntas realizadas a personas que no conocían el sistema se
obtuvo que 8 de las preguntas fueron contestadas correctamente, 3 fueron
identificadas pero no se obtuvieron resultados, 3 no fueron identificadas ni
 76

se obtuvieron resultados y 1 fue respondida a través de una pregunta

similar.

En la Figura 31, se presenta el módulo de visualización de preguntas. Este

módulo brinda la posibilidad al administrador de visualizar las preguntas que se han
realizado al sistema. Además, las preguntas contendrán metadatos que proporcionaran
información acerca de si fue respondida, sí el patrón de la pregunta es conocido por el
sistema, si se respondió por similitud y en caso de no ser respondidas mostrar los
mensajes que almaceno el sistema.

Figura 31. Módulo de visualización de preguntas no contestadas

Validación del sistema

Para la validación del sistema, la metodología de desarrollo propone la

actividad de Final Review. Durante esta actividad, se realizó una reunión con el
cliente en la cual se verificaba que todos los requerimientos fueron cubiertos
correctamente. Así mismo, se confirmaba el funcionamiento de los ítems del Product
Backlog.
 77

Como resultado se realizó un listado de las historias de usuarios con sus tareas
correspondientes, el estado de culminación y la manera en cómo se dio solución, ver
Tabla 11. De esta manera, el listado fue validado y los productos entregados al
cliente.

Tabla 11. Lista de validación de funcionalidades

ID Historia de usuario Valor

1 Representación del conocimiento Completado

 Construcción de la ontología Completado
 Aplicación paradigma OBDA Completado
2 Procesamiento del lenguaje natural Completado
3 Módulo de soporte para preguntas Completado
Estado: Aprobado
Mohamed El Saheli Jesús Herrera
Product Owner Desarrollador
 CAPÍTULO V

Conclusiones y Recomendaciones

Conclusiones

El uso del lenguaje natural como forma de comunicación con las

computadoras conforma una de las áreas con mayor auge en la actualidad, su
presencia representa un gran impacto en la experiencia de usuario de los individuos,
determinando el grado de humanización que una máquina podría llegar a tener.
Cuando problemas relacionados en la búsqueda de la información se presentan, se
vuelve necesario mejorar la interacción de los individuos para ofrecer nuevos
resultados en base a nuevas experiencias y métodos de búsqueda.

La convergencia entre varias tecnologías como lo son el área de inteligencia

artificial con el procesamiento de lenguaje natural, la web semántica y representación
del conocimiento hace posible que se puedan desarrollar sistemas innovadores.

Una vez terminada las fases planteadas en la metodología Momentum

Methodology, cumpliendo con los objetivos definidos al inicio del proyecto, podemos
concluir lo siguiente:

 Los sistemas de pregunta y respuesta estudiados, representaron un insumo

importante para definir los aspectos a tomar en cuenta durante el
levantamiento de requerimientos y diseño del proyecto, ya que se
caracterizaron por los distintos conceptos, métodos y técnicas utilizadas para
lograr responder preguntas en lenguaje natural.
 Los aspectos de diseño que fueron obtenidos mediante el estudio de sistemas
preguntas y respuestas existentes, ayudaron a identificar los requerimientos
 79

necesarios para llevar a cabo el desarrollo del sistema de pregunta y respuesta

propuesto en este trabajo.
 Los aspectos de diseño que fueron obtenidos mediante el estudio de sistemas
preguntas y respuestas existentes, ayudaron a diseñar durante la fase de sprint
planning de la metodología de desarrollo la arquitectura final del sistema a
responder los problemas planteados en la realización del proyecto. Así mismo,
se lograron aplicar los conceptos principales en los que se basa el sistema de
pregunta y respuesta desarrollado.
 El uso de la metodología Momentum Methodology permitió tener una
constante comunicación con el cliente y el equipo de desarrollo, lo que brindó
asegurar que las funcionalidades deseadas fueran en dirección correcta
permitiendo así, el desarrollo y la integración con otros módulos del sistema
Travelea.
 Las fases de revisión de cada iteración y revisión final del sistema propuestas
por la metodología de desarrollo, permitió realizar la validación del sistema
durante su desarrollo y al final del ciclo.

Recomendaciones

Debido a la magnitud real del sistema diseñado, sólo una serie de patrones de
preguntas fueron implementadas en concordancia con el tiempo de desarrollo del
trabajo investigativo. Por lo tanto, para ampliar la funcionalidad del sistema, se
realizan las siguientes recomendaciones:

 Añadir al módulo de procesamiento de la pregunta nuevos métodos de

búsqueda de preguntas similares contenidas en el sistema que le permitan
realizar una mejor comparación de las consultas realizadas. Entre los métodos
de búsqueda por similitud que podrían implementarse, destacaría la búsqueda
por conceptos entre preguntas haciendo uso de la ontología del sistema y
alguna ontología lingüística que permita abarcar una mayor cantidad de
 80

información. De esta manera, se podría establecer la relación de similitud a

través del contexto de la pregunta.
 Agregar nuevas métricas y casos al módulo de soporte. De esta manera, se
brindara un mejor apoyo a los desarrolladores y encargados del negocio.
 Profundizar el estudio de los métodos de contestación de preguntas en
lenguaje natural a través del análisis semántico de la pregunta para continuar
con el desarrollo de estas tecnologías que se encuentran en auge.
 Expandir el conocimiento en la ontología agregando nuevos conceptos,
propiedades y relaciones que se relacionen con el ámbito del turismo y del
negocio.
 Establecer reglas en el cliente que haga uso del sistema de pregunta-respuesta,
mediante el cual se pueda deducir a través de la interacción del usuario si la
respuesta devuelta fue de utilidad, sin necesidad de ser invasivos preguntando
si la pregunta fue correcta. De esta manera, se obtendría una mejor
retroalimentación en el sistema de soporte ya que se obtendría información
acerca de las respuestas que están siendo respondidas pero que no son
relevantes para los usuarios.
 81

Referencias Bibliográficas

Anton, A. (2016). Tecnologías de la web semántica (tesis doctoral). Universidad

Complutense de Madrid.

Arias, F. (1999). El Proyecto de Investigación: Guía para su elaboración. 3ra edición.

Caracas: Episteme. ISBN: 980-07-3868-1.

B.Sujatha., S.Viswanadha (2016). Ontology Based Natural Language Interface for

Relational Databases. Procedia Computer Science (92) ,487 – 492.

Baader, F., McGuinness, D., Nardi, D., Patel-Scheneider, P. (2003). The description
logic Handbook: Theory, implementation and applications. New York:
Cambridge University Press. Recuperado de: https://goo.gl/83H6mf

Baldacci, C. (2015). Sistema de pregunta y respuestas basado en ontologías sobre el

modelado conceptual en base de datos. Universidad Simón Bolívar,
Sartenejas, Caracas, Miranda.

Barrera, M., Núñez, H., Esmeralda R. (2012). Ingeniería Ontológica. Lecturas en

Ciencias de la Computación.

Berners-Lee, T.; Hendler, J.; Lassila, O. (2001) “The semantic web”. Scientific
American, v. 284, n. 5, pp. 34-43. Recuperado de: https://goo.gl/2Ch24J

Bird, S. Klein, E. Loper, E. (2009). Natural Language Processing with Python.

Sebastopol, C.A. O’reilly Media, Inc.

Borst, W. (1997). Construction of Engineering Ontologies for Knowledge Sharing

and Reuse (Tesis doctoral). University of Twente. Enschede, Netherlands.
Recuperado de: https://goo.gl/fk3kFm

Cáceres, J. (2006). “La web semántica y el lenguaje RDF”. Universidad de Alcalá

 82

Camacho, A., Matos, M., Santana, I. (s.f). Desarrollo de guía turística a través de
aplicaciones para Smartphone. Universidad Católica Andrés Bello.
Disponible en: https://goo.gl/5ppbh1

Cambridge Semantics (s.f). Introduction to the semantic web. Recuperado

de:http://www.cambridgesemantics.com/semantic-university/introduction-
semantic-web

DuCharme, B. (2011). Learning Sparql. Sebastopol, California: O’Reilly. Recuperado

de: https://goo.gl/tD9vaX

Ercegovac, Z. (1999). Introduction. Journal of the American Society for Information

Science, 50 (13), p. 1165-1168, Recuperado de: https://goo.gl/kUrMmz

Fernández, H. (s/f) Motores de búsqueda Recuperado de:

http://especializacion.una.edu.ve/Internet/paginas/Lecturas/Fernandez.pdf

García, G. (6 de abril de 2014). ¿Venezuela potencia turística? El Universal.

Recuperado de http://www.eluniversal.com/opinion/140406/venezuela-
potencia-turistica

Garret, J. (2010). Elements of User Experience. The User-Centered Design for the
Web and Beyond. 2da edición. Pearson Education. Recuperado el 25 de
Julio del 2017 de: https://goo.gl/TLXfQE

Gómez, A., Fernández L, M. Corcho, O. (2004). Ontological Engineering. Springer-

Verlag, London. Recuperado de: https://goo.gl/aGiEKD

Gómez, S., Fillottrani, P. (2017). Completitud de los Métodos de Acceso a Datos

Basado en Ontologías: Enfoques, Propiedades y Herramientas.

Green, B. F., Wolf, A. K., Chomsky, C., y Laughery, K. (1961). BASEBALL: An

automatic question-answerer. In Proceedings of the Western Joint Computer
Conference 19, 219-224.
 83

Grothaus, M. (2014). Cortana vs Siri: Which PDA system Does What Best? : Know
your mobile. Recuperado de https://goo.gl/Fv2hdx

Gruber, T. (1993). A translation approach to portable ontologies specifications-

Journal Knowledge Acquisition - Special issue: Current issues in knowledge
modeling. 5(2). 119-220.

Heather, K (2015). Which is the best digital assitant: Siri, Cortana, Alexa or Google
Now?. San Francisco: CNN Tech. Recuperado de https://goo.gl/UvbU1m

Hill, S. (2016). How to get the most out of google now: Digital Trends. Recuperado
de: https://goo.gl/jcKZxb

Hunter. K (2015). Cortana and Speech Platform Overview. WinHEC Cortana

Workshor Shenzhen.

Hurtado de Barrera, J. (2010). Guía para la compresión holística de la ciencia. 3ra

edición, Fundación Sypal: Caracas.

Inbenta Technologies, C.A (2012). La búsqueda basada en palabras clave frente la

búsqueda en lenguaje natural. Recuperado de:
https://www.inbenta.com/es/blog/la-busqueda-basada-en-palabras-clave-
frente-la-busqueda-en-lenguaje-natural/

Katz, B. Borchardt, G. Felshin, S. (2006) Natural Language Annotations for Question

Answering. Recuperado el 10 de julio de 2017 de: https://goo.gl/BHY955

Labra, J. (2011) Web Semántica. Madrid, España: Netbiblio.

Los Santos, A., Nava, M., Godoy, D. (2009). Web 3.0: integración de la Web
Semántica y a Web 2.0. Recuperado de: https://goo.gl/Y9BBbK
 84

Luzmila Pró Concepción. (2010) “Fundamentos de Ingeniería de la Web: Ontologías,

Web Semántica y Agentes de Software”. Revista de investigación de
sistemas e informática, pp. 77-89.

Marcus, A. (2014). Design, UserExperience and Usability: User Experience

DesignPractice. Crete, Grecia: Springer. Recuperado el 10 de Junio del 2017
de: https://goo.gl/o587mf

Momentum Lab, C.A. (2016, octubre). Momentum Methodology. Documento interno

no publicado.

Mozilla Developer Network y colaboradores individuales. (2005-2017). Tecnologías

web para desarrolladores: HTML. Recuperado de
https://developer.mozilla.org/es/docs/Web/HTML

Noy, Natalya., McGuinness, Deborah. (2001). Ontology Development 101: A Guide

to Creating Your First Ontology. Stanford Knowledge Systems Laboratory
Technical Report. Recuperado de: https://goo.gl/u6WhGx

Olvera-Lobo, María-Dolores; Robinson-García, Nicolás. (2009) “Tratamiento

lingüístico de las preguntas en español para su clasificación en los sistemas
de búsqueda de respuestas”. El profesional de la información, v. 18, n. 2, pp.
180-187.

Oscar (2013). “La humanización de las tecnologías es el futuro de la atención al

cliente”.Tech Group Sales. Recuperado de: https://goo.gl/rDaTgZ

Pérez, C. (2002). Explotación de los córpora textuales informatizados para la

creación de bases de datos terminológicas basadas en el conocimiento.
Universidad de Málaga. Recuperado de: https://goo.gl/N6D7b4
 85

Rapaport, W (2006). Turing Test. In: Keith Brown, (Editor-in-Chief) Encyclopedia of

Language & Linguistics, Second Edition, (13), pp. 151-159. Oxford:
Elsevier

Rodríguez, M., Kontchakov, R., Zakharyaschev, M. (s.f). Ontology-Based Data

Access: Ontop of Databases. Recuperado de: https://goo.gl/GEQhMJ

Roxydel, Dulcey; Ramos, Esmeralda. (2016) “Ontología para apoyar el sector

turismo en Venezuela”. IV Simposio Científico y Tecnológico en
Computación, Universidad Central de Venezuela, pp. 96-107.

Sabino, C (1992). El Proceso de Investigación, Caracas: Ed, PANAPO, ISBN: 980-

230-577-4

Salcedo, M. (2016). Desarrollo de una herramienta de colaboración en línea orientada

en la seguridad ciudadana. (Tesis de pregrado). Universidad Catolica Andres
Bello, Ciudad Guayana.

Sampieri Hernandez, Roberto ç; Collado Fernandez, Carlos; Baptista, Lucio. (2003).

Metodología de la investigación, McGraw Hill: México D.F.

Sequeda, J., Miranker, D. (2017). A Pay-As-You-Go Methodology for Ontology-

Based Data Access. IEEE Internet Computing, 21(2), 92-96.

Studer, R., Bejamins, R., Fensel, D. (1998). Knowledge engineering: principies and
methods. Data & Knowledge Engineering. 25(1-2). 161-197. Recuperado de:
https://goo.gl/2rEGHG

Todorović, A. (2015). Has The Turing Test Been Passed? Recuperado de:
http://isturingtestpassed.github.io/

Turing, A (1950). Computing machinery and intelligence. Mind 59, 433-460

 86

UPEL. (2011). Manual de Trabajos de Grado de Especialización y Maestría y Tesis

Doctorales. Caracas: FEDUPEL.

Vallez, Mari (2009). “La web semántica y el procesamiento del lenguaje natural”, en
Lluis

Vargas-Vera, M., Motta, E. (2014) AQUA: A Question Answering Systems for

heterogeneous sources. Technical Report. Recuperado el 10 de julio de 2017
de: https://goo.gl/d1MDee

Woods, W.A. (1978) Semantics and quantification in Natural Language Question

Answering. Advances in computers, 17.

Yahuita, German. (2014). Web Semántica y Representación del Conocimiento con

Ontologías. Revista PGI [online]., n.1, pp. 57-61. ISSN 3333-7777
 87

Anexos
 88

Anexo A.
Documento de contexto con los requerimientos iniciales del sistema
89
 90

Anexo B.
Documentación del API Rest
 91

Descripción

Devuelve una lista de sitios que pueden ser de utilidad para la consulta
realizada en lenguaje natural.

Petición

GET https://emprenomina.com/api/search

Parámetros

Nombre Ejemplo Descripción De no ser enviado

user_id 15 Requerido identificador único Error.

del usuario.

Query Que playas hay en Consulta realizada por el Error.

margarita usuario en lenguaje natural

lat 69.3125 Latitud actual del usuario No se filtraran los

resultados por
contexto

long 72.0215 Longitud actual del usuario

limit 15 Número de resultados que Devuelve máximo 10

usted solicita. por defecto

offset 0 Envía los primeros N (límite Envía los primeros N

establecido) resultados. resultados.

radius 5km Radio de búsqueda No filtra por radio.

 92

qtime 1224858393 Tiempo en el que el usuario No pasa nada

realizo la pregunta.

movibilidad {‘car’,’bicycle’,’walk’} Transporte usado por el OPCIONAL

usuario

Campos de Respuesta

Campo Descripción

meta Objeto que contiene metadatos de la pregunta

requestId Identificador único de la pregunta

message Respuesta enviada por el servidor en lenguaje natural.

code HTTP status

response Objeto que contiene información acerca de los sitios

encontrados por el sistema

Ítems Arreglo de sitios

 93

Id ID del sitio.

Name Nombre del sitio

description Descripción del sitio

photo Foto principal del sitio

categories Arreglo con los concepto al que está asociado el sitio.

Price Característica económica del sitio

address Dirección del sitio

lat Latitud

lon Longitud

Respuesta

meta:

{
 94

"code": "200",

"requestId": 14,

"message": "Se encontraron los siguientes restaurantes en Ciudad guayana",

“limit”: 15,

“offset”: 0,

},

Response:{

Items:

"price": "$$$",

"name": “Tomasa Restaurant”

"description": "Restaurante Criollo",

"address": "Altavista",

"photo": "",

"category": ["Restaurante criollo", “Restaurante”]

"id": 13

"lat": “8.6565324”

"lon”: “-64.86858”
 95

},

"price": "$$$",

"name": “Tomasa Restaurant”

"description": "Restaurante Criollo",

"address": "Altavista",

"photo": "",

"category": ["Restaurante criollo", “Restaurante”]

"id": 13

"lat": “8.6565324”

"lon”: “-64.86858”

},

Descripción

Endpoint mediante el cual un usuario califica la respuesta recibida.

Petición

POST https://emprenomina.com/api/rating/question
 96

Parámetros

Nombre Ejemplo Descripción De no ser enviado

user_id 15 Requerido identificador único del Error.

usuario.

Request_id Que playas Id de la pregunta Error.

hay en
margarita

isCorrect? True o False Respuesta del usuario indicando si la Error

respuesta recibida fue de su util.

Campos de Respuesta

Campo Descripción

status Devuelve el código HTTP con el estado de la petición. Ej. 200 indica que
se recibió el rating de la pregunta se realizó correctamente
 97

Anexo C.
Preguntas realizadas y resultados obtenidos durante el caso de estudio
 98

Tabla C- 1
Preguntas conocidas por el sistema

Preguntas conocidas por el sistema

¿Qué playas hay en margarita?

posadas en margarita

donde puedo comer sushi ?

playas en porlamar

¿ que hoteles hay en ciudad guayana?

Tabla C- 2
Preguntas no conocidas por el sistema

Preguntas no conocidas por el sistema

a que hora abre orinokia ?

Donde puedo recargar saldo?
sitios para jugar futbol
eventos en ciudad guayana
¿Dónde consigo hielo?

Tabla C- 3.
Preguntas parcialmente conocidas por el sistema

Preguntas parcialmente conocidas por el sistema

 99

playas cerca de Porlamar

playas para niños
playas con buena infraestructura
¿ donde están los lugares de entretenimiento?
¿ que hoteles cinco estrellas hay en ciudad guayana?

Tabla C- 4
Preguntas realizadas por personas externas al sistema.

Preguntas realizadas por personas que no conocían el sistema

donde se come arepa

donde venden pollo ?
farmacias cerca
¿ donde comprar maquillaje ?
¿ donde hay hospedaje en cabañas?
¿ donde puedo encontrar un zoologico?
que centros comerciales hay en margarita ?
donde hay un supermercado?
paseo a caballo
playa más cerca
quiero un helado
Sitios para comer
Playas en margarita
Donde puedo desayunar?
Eventos hoy
 100

Figura C- 1. Pregunta ¿Qué playas hay en Margarita?

Figura C- 2. Pregunta: playas en margarita

 101

Figura C- 3. Pregunta: posadas en margarita

Figura C- 4. Pregunta: ¿Qué hoteles hay en ciudad guayana?

 102

Figura C- 5. Pregunta: donde puedo comer sushi?

Figura C- 6. Pregunta: quiero un helado

 103

Figura C- 7. Pregunta: sitios para comer

Figura C- 8. Pregunta: que hora abre orinokia?

 104

Figura C- 9. Pregunta: ¿Dónde puedo recargar saldo?

Figura C- 10. Pregunta: sitios para jugar futbol

 105

Figura C- 11. Pregunta: ¿Donde consigo hielo?

Figura C- 12. Pregunta: Playas en porlamar

 106

Figura C- 13. Pregunta: playas cerca de porlamar

Figura C- 14. Playas para niños

 107

Figura C- 15. Pregunta: Playas con buena infraestructura

Figura C- 16. ¿ donde estan los lugares de entretenimiento?

 108

Figura C- 17. Pregunta: ¿que hoteles cinco estrellas hay en ciudad guayana?

Figura C- 18. Pregunta: Donde se come arepa

 109

Figura C- 19. Pregunta: Donde venden pollo?

Figura C- 20. Pregunta: farmacias cerca

 110

Figura C- 21. Pregunta: ¿donde comprar maquillaje?

Figura C- 22. Pregunta: ¿Dónde hay hospedaje en cabañas?

 111

Figura C- 23. Pregunta: ¿Donde puedo encontrar un zoologico?

Figura C- 24. Pregunta: Que centros comerciales hay en Margarita?

 112

Figura C- 25. Pregunta: Donde hay un supermercado

Figura C- 26. Pregunta: Paseo a caballo

 113

Figura C- 27. Pregunta: Playa más cerca

Figura C- 28. Pregunta: eventos hoy

 114

Figura C- 29. Pregunta: Donde puedo desayunar

Figura C- 30. Pregunta: eventos en ciudad guayana

 115

Glosario

 Análisis sintáctico: consiste en identificar la función que realizan las palabras

dentro de la oración.
 API: la interfaz de programación de aplicaciones, es un conjunto de
subrutinas, funciones y procedimientos (o métodos, en la programación
orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro
software como una capa de abstracción.
 Django: es un framework de desarrollo de código abierto escrito en python,
que. Proporciona una serie de herramientas para facilitar la creación de
páginas, siguiendo los principios DRY (Don’t Repeat Yourself; No Te
Repitas) para evitar duplicidad en las líneas de código e invertir el menor
esfuerzo posible.
 Etiquetador gramatical: es el proceso de asignar (o etiquetar) a cada una de las
palabras de un texto su categoría gramatical.
 Jetty: es un servidor web y contenedor de servlets escrito en java.
 Lema: es la forma canónica de una palabra
 Python: Se trata de un lenguaje de programación multiparadigma, ya que
soporta orientación a objetos, programación imperativa y, en menor medida,
programación funcional. Es un lenguaje interpretado, usa tipiado dinámico y
es multiplataforma.
 Quepy: es un framework escrito en python para transformar lenguaje natural a
consultas estructuradas.
 R2RML: es un lenguaje utilizado para expresar mapeados entre bases de datos
relacionales y datos RDF.
 RDF4J Workbench: es un framework que ofrece una interfaz gráfica para el
manejo del servidor RDF4J.
 Servidor RDF4J: es un servidor que provee acceso a repositorios RDF a través
del protocolo HTTP.
 116

 Servlets: es una clase en el lenguaje de programación Java, utilizada para

ampliar las capacidades de un servidor.
 Similitud basada en cosenos: La similitud coseno es una medida de la
similitud existente entre dos vectores en un espacio que posee un producto
interior con el que se evalúa el valor del coseno del ángulo comprendido entre
ellos. Esta función trigonométrica proporciona un valor igual a 1 si el ángulo
comprendido es cero, es decir si ambos vectores apuntan a un mismo lugar.
Cualquier ángulo existente entre los vectores, el coseno arrojaría un valor
inferior a uno.
 Token: pueden ser palabras, números o signos de puntuación.
 Tokenización: se refiere al proceso de separar un texto en unidades más
pequeñas llamadas token.