TESIS DE MAESTRÍA EN CIENCIAS - cenidet.edu.mx Cesar... · o respuestas a consultas específicas,...
Transcript of TESIS DE MAESTRÍA EN CIENCIAS - cenidet.edu.mx Cesar... · o respuestas a consultas específicas,...
cenidet Centro Nacional de Investigación y Desarrollo Tecnológico
Departamento de Ciencias Computacionales
TESIS DE MAESTRÍA EN CIENCIAS
Desarrollo de una Web API para el Tratamiento Automático de Reglas Contextuales Aplicadas a
Servicios Basados en Localización.
Presentada por
I.S.C. César Francisco Villatoro Hernández Ing. en Sistemas Computacionales por el I. T. de Tuxtla Gutiérrez.
como requisito para la obtención del grado de:
Maestría en Ciencias en Ciencias de la Computación
Director de tesis:
Dr. Juan Gabriel González Serna
Co-Director de tesis: M.C. Ismael Rafael Ponce Medellín
Jurado:
Dra. Azucena Montes Rendón – Presidente
Dr. Máximo López Sánchez – Secretario
Dr. Guillermo Rodríguez Ortiz – Vocal
Dr. Juan Gabriel González Serna – Vocal Suplente
Cuernavaca, Morelos, México. 24 de Febrero del 2011.
ii
DEDICATORIA
A Dios:
Por ser quién ha iluminado mi camino y me ha bendecido para llegar tan lejos. Al ser divino que
me da fortaleza en los momentos agradables y más aún en los momentos difíciles.
A mi madre:
De quién he recibido todo el apoyo para llegar tan lejos. He terminado otro capítulo más en mi
vida gracias a tus enseñanzas y a tu cariño. Te quiero y te respeto.
A mi hermana:
Por ser mi ejemplo a seguir, por motivarme y darme la confianza que necesitaba para llegar tan
lejos. Porque siempre me enseñas a ver lo bueno aún en los momentos malos. Te quiero y te admiro.
iii
AGRADECIMIENTOS.
A Dios por iluminar mi camino durante toda mi vida, por hacer posible mi estancia en
la maestría, haber permitido permanecer siempre con mi familia y darme la oportunidad de
conocer a tantas personas grandiosas.
A mi madre Lilián que siempre me apoyó y estuvo al pendiente de cada paso que
realizaba. Aún en la distancia física, siempre ha permanecido a mi lado.
A mi hermana Angélica por apoyarme y compartirme sus experiencias que me
permitieron salir adelante en los momentos difíciles.
A mis tías y tíos y todos mis primos que siempre han estado al tanto de mí y me han
brindado sus muestras de apoyo. Y al buen Morris por esperarme con cariño.
A mis amigos que en esta ciudad he conocido y han sido con quiénes he compartido
tanto tiempo: Lily mi teacher pero sobre todo mi gran amiga que con sus experiencias y
amistad incondicional me ha apoyado tanto. A los grandes amigos de mi generación:
Carliux, Lizeth, Normita y el Compita por todos esos trabajos juntos, pero sobre todo por la
amistad incondicional. A los amigos que me enseñaron amistad y compañerismo: Jenny,
Toño, Elias, Marino, y a mis compañeros de generación en general porque de ellos pude
aprender a colaborar mejor. Y a Le Moniq por tanto apoyo y porras recibidas.
A mis amigos Karencilla, Yris y Adilene, que han sido parte de esta chocoaventura y
hemos trabajado y paseado como si fuésemos familia; Y a mis amigos de siempre de Tuxtla
Paty, Beto, Mau, Leo, Elo, Doña Dulce y a todos los amigos y compañeros del Registro
Civil.
A mi director de tesis Dr. Juan Gabriel González Serna, por haberme permitido
colaborar como su tesista, por las asesorías que recibí y por la paciencia tuvo hacia mi
persona. Y al M. C. Rafael Ponce, quién ha sido Codirector de esta tesis y que con sus
comentarios y aportaciones también he hecho posible este proyecto.
A mis revisores de tesis por sus valiosas aportaciones, revisiones y consejos
recibidos: Dra. Azucena Montes Rendón, Dr. Guillermo Rodríguez Ortiz y al Dr. Máximo
López Sánchez que además me ha brindado una amistad especial.
Al Consejo Nacional de Ciencia y Tecnología (CONACYT) y a la Dirección General
de Educación Superior Tecnológica (DGEST) por el apoyo de becas que me permitieron
realizar mis estudios de postgrado.
Al Centro Nacional de Investigación y Desarrollo Tecnológico por haberme
permitido pertenecer a su comunidad estudiantil y realizar así mis estudios de maestría.
iv
RESUMEN.
Los Servicios basados en localización (LBS por sus siglas en inglés) tienen como objetivo
obtener la ubicación geográfica de un dispositivo móvil y a partir de esta, ofrecer servicios
o respuestas a consultas específicas, tales como información a turistas o rutas hacia cierto
destino. Los LBS se basan en redes de comunicaciones móviles, una o más tecnologías de
localización (p. e. GPS) y Sistemas de Información Geográfica.
Cuando los usuarios realizan consultas sobre LBS, las mismas consultas deberían tener
resultados distintos según la información contextual del usuario, debido a que no todos los
usuarios tienen las mismas necesidades aunque estos estén ubicados en el mismo punto
geográfico. Los LBS que consideran la información contextual (LBS contextuales) agrupan
cualquier información que caracteriza a la situación de una persona, lugar u objeto, así
como el significado de las cosas y que se pueden utilizar para proporcionar servicios más
relevantes para el usuario.
Con las tecnologías de la Web Semántica también es posible proporcionar servicios a los
usuarios donde la información se vuelva dinámica y dependa de la posición donde se
encuentra el dispositivo y la información contextual del usuario.
En el presente trabajo de tesis se desarrolló una API (Interfaz de programación de
aplicaciones), que implementa algunas de las herramientas de la Web Semántica como las
bases de conocimientos representadas en ontologías y el uso de un lenguaje de reglas
semánticas aplicadas a las ontologías para realizar recomendaciones de los servicios de
hospedajes. Las ontologías permiten representar el conocimiento de los hospedajes, los
usuarios y los contextos que serán manejados con las reglas semánticas para determinar las
mejores recomendaciones de dichos servicios.
v
ABSTRACT
Location Based Services (LBS) have as primary objective the obtainment of the
geographical location of a mobile device and, with this location in mind, offer services or
results to specific queries: tourist information, routes to a particular destiny, etc. LBS are
based on mobile communication networks, one or more location technologies (e.g. GPS)
and Geographic Information Systems (GIS).
When different users make queries over the LBS, an exact same query should get different
results according to each of the users‟ contextual information, due to the dissimilarity of
each user‟s needs; even though their geographic location is the same. The LBSs that
consider contextual information (contextual LBS) group any type of data that characterize
the situation of a person, place or thing, as well as the meaning of these data, which are
useful when providing more relevant services for the user.
With Semantic Web technologies it is possible to provide services for users, in which
information becomes dynamic and depends on the geographic location of the device and
user‟s contextual information.
In this thesis, an API (Application Programming Interface) has been developed, that
implements some of the Semantic Web‟s tools –knowledge bases represented through
ontologies, and the use of a language of semantic rules applied to ontologies–, to bring up a
set of recommendations of lodging services. Ontologies allow to better represent the
knowledge on lodging services, the users and the contexts that will be handled by semantic
rules, in order to determine better recommendations for these services.
vi
Contenido
Listado de figuras ................................................................................................................................... viii
Listado de tablas....................................................................................................................................... ix
Glosario de términos y siglas..................................................................................................................... x
Capítulo 1. Introducción ........................................................................................................................... 1
1.1 Introducción del tema de tesis ................................................................................................. 2
1.2 Antecedentes ........................................................................................................................... 2
1.3 Trabajos relacionados .............................................................................................................. 4
1.4 Descripción del problema ........................................................................................................ 5
1.5 Objetivo .................................................................................................................................... 5
1.6 Justificación .............................................................................................................................. 5
1.7 Beneficios ................................................................................................................................. 6
1.8 Alcances .................................................................................................................................... 7
1.9 Limitaciones ............................................................................................................................. 7
1.10 Organización del documento ................................................................................................... 8
Capítulo 2. Marco Teórico ........................................................................................................................ 9
2.1 Servicios Basados en Localización (LBS) ................................................................................. 10
2.1.1 Ejemplos de Servicios Basados en la Localización (LBS) ......................................................... 11
2.1.2 El proceso de localización ...................................................................................................... 12
2.1.3 LBS contextuales .................................................................................................................... 12
2.2 Web Semántica ...................................................................................................................... 13
2.2.1 ¿Para qué sirve? ..................................................................................................................... 13
2.2.2 ¿Cómo funciona?.................................................................................................................... 13
2.3 SPARQL ................................................................................................................................... 15
2.3.1 Componentes ......................................................................................................................... 15
2.3.2 Sintaxis ................................................................................................................................... 16
2.4 SWRL....................................................................................................................................... 18
2.4.1 Máquina de reglas .................................................................................................................. 20
2.4.2 Preferencias de usuario, reglas y SWRL. ................................................................................ 20
Capítulo 3. Estado del arte ..................................................................................................................... 22
3.1 A Context-Aware e-Tourism Application Enabling Collaboration and Knowledge Exchange
among Tourists [Paganelli06]. ............................................................................................................ 23
vii
3.2 Semantic Rules for Context-Aware Geographical Information Retrieval [Carsten09]. .......... 24
3.3 Context inferring in the Smart Home: An SWRL approach [Ricqueb07]. ............................... 25
3.4 Semantic Location Based Services for smart spaces [Kostas07]. ........................................... 26
3.5 Towards Self-managed Pervasive Middleware using OWL/SWRL ontologies [Zhan08]. ....... 27
3.6 Self-adapted Service Offering for Residential Environments [González07]. .......................... 27
3.7 i-footman - A Knowledge-based Framework for Football Managers [Vassilis09].................. 28
3.8 Comparativa de trabajos relacionados con el proyecto. ....................................................... 29
Capítulo 4. Análisis y Diseño................................................................................................................... 32
4.1 Análisis .................................................................................................................................... 33
4.1.1 Arquitectura .......................................................................................................................... 33
4.2 Diseño ..................................................................................................................................... 45
4.2.1 Paquete conexiones .............................................................................................................. 46
4.2.2 Paquete estructuras .............................................................................................................. 46
4.2.3 Paquete inferencia ................................................................................................................ 48
4.2.4 Paquete conHotel .................................................................................................................. 48
4.2.5 Diseño del modelo de la base de datos ................................................................................ 50
Capítulo 5. Implementación ................................................................................................................... 52
5.1 Detalles tecnológicos ............................................................................................................. 53
5.2 Ontología. ............................................................................................................................... 54
5.2.1 Súper clases. .......................................................................................................................... 55
5.2.2 Subclases y propiedades. ...................................................................................................... 56
5.3 Reglas SWRL. .......................................................................................................................... 58
5.4 Ejecución de las reglas ........................................................................................................... 61
Capítulo 6. Pruebas funcionales ............................................................................................................. 63
6.1 Pruebas de ingreso de información a la Base de Datos ......................................................... 64
6.2 Pruebas de Consultas geolocalizables. ................................................................................... 69
6.3 Pruebas de instanciación de la Ontología .............................................................................. 74
6.4 Pruebas de ejecución de reglas contextuales. ....................................................................... 78
Capítulo 7. Conclusiones ........................................................................................................................ 83
7.1 Conclusiones........................................................................................................................... 84
7.2 Aportaciones .......................................................................................................................... 84
7.3 Trabajos futuros ..................................................................................................................... 85
viii
Referencias ............................................................................................................................................. 86
Listado de figuras
Figura 2.1. Resultados obtenidos con un buscador normal [W3C_WS08]. ........................................... 14
Figura 2.2. Resultados obtenidos con un buscador semántico [W3C_WS08]. ...................................... 15
Figura 2.3. Sintaxis de consultas en SPARQL [Ballesteros09]. ................................................................ 16
Figura 2.4. Vista parcial de la ontología “Restaurant”, graficada en Protégé [Ponce]. ......................... 17
Figura 2.5. Ejemplo de consulta sobre una ontología con SPARQL. ...................................................... 17
Figura 2.6. Resultados obtenidos al ejecutar la consulta con SPARQL. ................................................. 18
Figura3.1. Arquitectura del sistema Kamer [Paganelli06]...................................................................... 24
Figura3.2. Ontología Surf Spot [Carsten09]. .......................................................................................... 25
Figura 4.1. Arquitectura de la API .......................................................................................................... 33
Figura 4.2. Diagrama de Casos de Uso ................................................................................................... 35
Figura 4.3. Diagrama de secuencia – Alta usuario. ................................................................................ 36
Figura 4.4. Diagrama de secuencia – Alta hospedaje. ............................................................................ 37
Figura 4.5. Diagrama de secuencia – Consulta por zona........................................................................ 38
Figura 4.6. Diagrama de secuencia – Recomendación contextual. ........................................................ 40
Figura 4.7. Diagrama de secuencia – Cambios usuario. ......................................................................... 42
Figura 4.8. Diagrama de secuencia – Baja usuario. ................................................................................ 43
Figura 4.9. Diagrama de secuencia – Consulta información de usuario. ............................................... 44
Figura 4.10. Diagrama general de Paquetes. ......................................................................................... 45
Figura 4.11. Paquete conexiones. .......................................................................................................... 46
Figura 4.12. Paquete estructuras. .......................................................................................................... 47
Figura 4.13. Paquete inferencia. ............................................................................................................ 48
Figura 4.14. Paquete conHotel. .............................................................................................................. 49
Figura 4.15. Relación de tablas de la base de datos. ............................................................................. 51
Figura 5.1. Interacción de las tecnologías en la API. .............................................................................. 53
Figura 5.2. Taxonomía de la ontología. .................................................................................................. 55
ix
Listado de tablas
Tabla 3.1. Comparativa de trabajos relacionados. ................................................................................. 30
Tabla 3.2. Relación de los trabajos con la tesis. ..................................................................................... 30
Tabla 4.1. CU1.1 Alta usuario. ................................................................................................................ 36
Tabla 4.2. CU1.2 Alta hospedaje. ........................................................................................................... 37
Tabla 4.3. CU2.1 Consulta por zona. ...................................................................................................... 38
Tabla 4.4. CU2.2 Recomendación contextual. ....................................................................................... 41
Tabla 4.5. CU3 Cambios usuario. ............................................................................................................ 42
Tabla 4.6. CU4 Baja usuario. ................................................................................................................... 43
Tabla 4.7. CU5 Consulta información de usuario. .................................................................................. 44
Tabla 5.1. Súper clases de la ontología. ................................................................................................. 56
Tabla 5.2. Subclases de la ontología. ..................................................................................................... 57
Tabla 5.3. Propiedades de datos de las súper clases. ............................................................................ 57
Tabla 5.4. Reglas a ejecutar según la propiedad contextoViaje. ........................................................... 58
Tabla 5.5. Reglas a ejecutar con otras propiedades............................................................................... 60
Tabla 6.1. Caso de prueba SurfeousHospedajes-01-A. .......................................................................... 64
Tabla 6.2. Caso de prueba SurfeousHospedajes-01-B. .......................................................................... 67
Tabla 6.3. Caso de prueba SurfeousHospedajes-02-A. .......................................................................... 69
Tabla 6.4. Caso de prueba SurfeousHospedajes-02-B. .......................................................................... 72
Tabla 6.5. Caso de prueba SurfeousHospedajes-03-A. .......................................................................... 74
Tabla 6.6. Caso de prueba SurfeousHospedajes-04-A. .......................................................................... 78
x
Glosario de términos y siglas API ApplicationProgramming Interface. Interfaz de programación de aplicación. Es
el conjunto de funciones y procedimientos que ofrece cierta librería para ser
utilizado por otro software como una capa de abstracción. Representa una
interfaz de comunicación entre componentes de software.
DBMS Database Manager System, Sistema Manejador de Base de Datos.
GIS GeographicInformationSystem. Los sistemas de información geográfica son
una integración organizada de hardware, software, datos geográficos y
personal, diseñado para capturar, almacenar, manipular, analizar y desplegar en
todas sus formas la información geográficamente referenciada con el fin de
resolver problemas complejos de planificación y gestión.
GPS Global PositioningSystem. Sistema de Posicionamiento Global. Sistema Global
de Navegación por Satélite que permite determinar en todo el mundo la
posición de un objeto.
HTTP HyperText Transfer Protocol. Protocolo de transferencia de hipertexto.
Protocolo desarrollado por la W3C para la transferencia de información a través
de la Web. Es un protocolo sin estado –no guarda información sobre
conexiones anteriores- y está basado en el modelo de cliente-servidor.
IEEE Institute of Electrical and Electronics Engineers.Instituto de Ingenieros
Eléctricos y Electrónicos, una asociación técnico-profesional mundial dedicada
a la estandarización, entre otras cosas. Es la mayor asociación internacional sin
fines de lucro formada por profesionales de las nuevas tecnologías, como
ingenieros de telecomunicaciones, ingenieros electrónicos, Ingenieros en
informática e Ingenieros en computación.
JSP Del inglés Java Server Pages, es decir, Páginas de Servidor de Java. Es una
tecnología para crear aplicaciones Web. Es un desarrollo de la compañía Sun
Microsystems y su funcionamiento se basa en scripts, que utilizan una variante
del lenguaje java.
LBS LocationBasedServices. Los Servicios Basados en Localización buscan ofrecer
un servicio personalizado a los usuarios basado en información de ubicación
geográfica de estos.
xi
PostGIS Módulo que añade soporte de objetos geográficos a la base de datos relacional
PostgreSQL para su utilización en Sistema de Información Geográfica. Se
publica bajo la GNU -General PublicLicense-.
PostgreSQL Servidor de base de datos libre desarrollado en su primera versión con el
nombre de Ingres, proyecto desarrollado en la Universidad de Berkeley.
Considerado como el referente a los sistemas manejadores de base de datos
libres.
XML eXtensibleMarkupLanguage. Lenguaje de marcado extensible. Es un meta-
lenguaje que permite definir lenguajes de marcado adecuados a usos
determinados. En la práctica corresponde a un estándar que permite a diferentes
aplicaciones interactuar entre sí a través de una red.
Capítulo 1. Introducción En este capítulo se presenta la descripción del problema que dio origen al presente trabajo de
tesis, su objetivo, justificación y beneficios. También la ubicación que tiene con respecto a sus
antecedentes en Cenidet. Así mismo los trabajos relacionados. Por último se presenta la
organización del presente documento.
Capítulo I. Introducción
2
1.1 Introducción del tema de tesis
Hoy en día el Internet se ha convertido en una fuente de información de todo tipo, lo que
ha originado el surgimiento de motores de búsqueda que facilitan la recuperación de
información de manera rápida.
Los métodos de recuperación de información (IR por sus siglas en inglés) juegan un
papel muy importante cuando se trata organizar y recuperar información relevante en distintos
servidores Web localizados a lo largo del mundo [Carsten09]. Esto aplica también a la
recuperación de información geográfica (GIR), donde se requieren de técnicas novedosas para
convertir grandes cantidades de datos en fuentes de información útiles.
Cuando un usuario hace uso de aplicaciones, la información del contexto en el que se
desenvuelve el usuario (como la ubicación, las preferencias de servicios, medios de transporte,
etc.), es información que puede ser relevante para que dichas aplicaciones puedan ofrecer
opciones o servicios personalizados de acuerdo a las necesidades de los distintos usuarios. Hay
que considerar que los usuarios de una misma aplicación tienen necesidades distintas y en los
Servicios Basados en la Localización del usuario (LBS por sus siglas en inglés) la misma
consulta debería tener respuestas distintas según la información contextual del usuario
[Hérvas06].
El uso de la Web Semántica (constituida principalmente por ontologías y esquemas
RDF), tiene la tarea de dotar de significado a la Web actual, permitiendo que computadoras y
humanos entiendan las relaciones entre sus conceptos. Un objetivo de esto, es ofrecer mejores
buscadores y nuevas formas de navegación basado en las relaciones que tienen entre sí los
conceptos que son de interés del usuario, ofreciendo así mejores resultados [W3C_WS 08].
Está tecnología junto con el uso de un lenguaje que realice consultas a una ontología
(como el lenguaje SPARQL y SQWRL) y la implementación de reglas de inferencias para
tratar la información contextual, ofrece la posibilidad de desarrollar una aplicación que
recupere información de servicios y/o lugares, ofreciendo resultados que sean pertinentes al
usuario, lo cual es el objetivo de esta tesis.
1.2 Antecedentes
Se han considerado como antecedentes las tesis realizadas en el Cenidet en las que se
desarrollaron aplicaciones para servicios basados en localización.
API SMS para el procesamiento de consultas georeferenciadas / no
georeferenciadas. Lirio Ruiz Guerra, CENIDET 2007 [Ruiz07].
Capítulo I. Introducción
3
En este trabajo fue desarrollada una API para crear e implementar aplicaciones en
dispositivos móviles para buscar lugares y servicios a través de consultas SMS y el sistema de
posicionamiento global.
La API fue diseñada en el marco de los Servicios Basados en Localización, los cuales
responden a las preguntas ¿Qué hay cerca de..?, ¿Cómo llego a..?, ¿Qué pasa cerca de...? y
¿Qué clima hay en...? Con base en lo anterior, identifica cuatro tipos de objetos:
Punto de interés (georeferenciados o no georeferenciados). Para el primer caso la
localización del usuario se realiza a través de información que se obtiene de un GPS
Bluetooth; para el segundo caso la localización se realiza a través de información que
el usuario proporciona (calle, número, colonia, código postal, ciudad).
Camino. Sucesión de puntos que unen dos o más lugares.
Evento (político, religioso, cultural, etc.).
Clima (grados de temperatura y cielo nublado, despejado, etc.).
Gateway SMS/MMS Pull para servicios basados en localización con una
Arquitectura de Servicios Web, Pedro Quiñones Bernardino, CENIDET 2008
[Quiñones08].
En esta tesis se desarrolló un Gateway para procesar mensajes SMS/MMS que identifica
si se trata de una consulta georeferenciada o no georeferenciada proveniente de un cliente
móvil. Una vez que se identifica el tipo de consulta es posible procesarla de manera local o
externa. Todo esto sobre una arquitectura que soporte tecnologías de los servicios Web.
Los tipos de búsqueda que soporta la arquitectura del Gateway se definen mediante un
conjunto de palabras clave, cada una de las cuales representan un servicio reconocido por el
servidor de consultas y en base a éstas retorna la información solicitada en el formato
adecuado.
API para la gestión de mapas de navegación en dispositivos móviles mediante el
GPS y mensajería SMS/MMS, Claudia Victoria Rincón, CENIDET 2008 [Rincón08].
Esta tesis fue elaborada con el propósito de desarrollar una API bajo la plataforma J2ME
para procesar consultas georeferenciadas / no georeferenciadas a través de mensajes
SMS/MMS y el protocolo HTTP, para obtener un mapa o información que permita representar
puntos de interés. El usuario deberá visualizar e interactuar con la información de referencia
solicitada a través de un dispositivo móvil.
Capítulo I. Introducción
4
La API está dirigida a teléfonos celulares de última generación, Smartphone y Pocket
PC's que soporten ciertas características mínimas de Java. La idea es aprovechar la tecnología
actual de estos dispositivos para proporcionar a los usuarios servicios de localización en el
lugar y momento requeridos, ya sea de manera textual o gráfica, que les permita resolver
necesidades de ubicación.
1.3 Trabajos relacionados
Búsquedas Contextuales de Servicios Basados en Localización en un entorno de
Web Social. Ismael Rafael Ponce Medellín. CENIDET [Ponce].
Esta propuesta de tesis tiene como objetivo trabajar un sistema de recuperación de
información sobre LBS bajo un enfoque de dependencia contextual y de Web social,
sirviéndose de anotaciones sociales que describan los lugares geo-localizables que un usuario
puede consultar y cuantificando el impacto contextual de los mismos.
Este trabajo se enfoca en la utilización de datos tanto de información geoespacial,
contextual y la retroalimentación proporcionada por un usuario a través de anotaciones (tags)
que describen un lugar geo-localizable, para así obtener un conjunto socialmente popular y
valorado de resultados sobre lugares y servicios ante una solicitud de un LBS.
Modelado de perfiles de usuarios para Servicios Basados en Localización. Christian
Rojas Roldán. CENIDET [Rojas09].
El objetivo de esta tesis es modelar los perfiles de usuario mediante una ontología con el
fin de realizar un filtrado de los resultados de una búsqueda, de tal forma que a partir de una
consulta contextual de un usuario, dar una respuesta pertinente del servicio solicitado.
El proceso que debe seguir una consulta es el siguiente: un usuario con acceso a algún
dispositivo móvil realiza una consulta, la cual llega hasta los servidores de datos, que procesan
la información de acuerdo a un número de alternativas de servicios. Los resultados son
comparados contra el perfil de usuario, de objeto y de dispositivo para posteriormente filtrar
esta información y presentarla como un mensaje de respuesta que llegará a manos del usuario.
El alcance primordial de este trabajo sólo contempla el perfil de usuario, omitiendo en los
alcances los demás perfiles.
Capítulo I. Introducción
5
1.4 Descripción del problema
Los servicios actuales en la Web para recuperar información sobre lugares y servicios
(ejemplo: consulta de ubicación de hospedajes) usan técnicas de búsqueda que no son
diferentes del método de la Web tradicional, es decir, que realizan búsquedas por palabras
clave [Yu05], con lo que también tiene los mismos problemas de grandes cantidades de
resultados y que no siempre presentan lo que el usuario busca. Esto es debido a que no se
cuenta o no se considera la información contextual del usuario. El contexto del usuario puede
contener datos como su ubicación, sus preferencias o su perfil. Dicho contexto puede ser útil
para crear filtros que seleccionen resultados del interés del usuario.
La discriminación de resultados en la recuperación de información es un proceso muy
importante, debido a que si se regresa un grupo de resultados muy grande, el usuario puede no
tener la disponibilidad para revisarlos, por lo que es necesario descartar resultados que no sean
pertinentes para ese usuario en particular, ya que hay que considerar que varios usuarios
pueden realizar la misma consulta, pero los resultados que le interesan a cada uno pueden ser
totalmente diferentes si se considera su información contextual.
Los servicios disponibles en Internet que permiten la recuperación de información sobre
hospedajes devuelven demasiados resultados y muchos de estos no son del interés del usuario,
por lo que puede no tener disponibilidad de revisarlos, puede confundir la relevancia de estos
y hacer elecciones incorrectas. Este problema se origina porque existen servicios que no
consideran la información contextual, ni el perfil del usuario para discriminar los resultados no
pertinentes.
1.5 Objetivo
Desarrollar una Web API que brinde un conjunto de servicios para la recuperación de
información en base a búsquedas de servicios y/o lugares cercanos a la localización del
usuario que realiza la consulta, haciendo uso de lenguajes de consultas semánticos (SPARQL)
y lenguajes de reglas de inferencia (SWRL), considerando para ello la situación contextual en
la que se desenvuelve el usuario.
1.6 Justificación
Como cada año, el sector turístico tiende a un mayor crecimiento en muchos países, y en
México (situado en el 2007 como el 10° país a nivel mundial en llegada de turistas
internacionales [SecTur_OVT10]) adquiere mayor relevancia la disponibilidad de sitios de
consultas y recomendaciones de hospedajes.
Capítulo I. Introducción
6
Tan sólo en el año 2010 en México se recibieron 26 millones de visitantes
internacionales y 160 millones de viajeros nacionales [SecTur10]. El CIEET (Centro de
Información y Estadística para el Empresariado Turístico) anunció que en México 62 millones
de los viajeros nacionales hicieron uso del servicio de hoteles[CNT10]. Todos estos viajeros
representan la necesidad de servicios de hospedajes que cuenten con información disponible
en Internet para facilitar dicho servicio a los viajeros.
Por tanto, la información de los hospedajes debe hacerse llegar a los usuarios que la
requieren mediante un sistema que pueda realizar búsquedas contextuales, de tal forma, que el
usuario pueda acceder a los hospedajes que más le pueden llegar a convenir, descartando
resultados innecesarios.
La información contextual de los usuarios puede ser usada con las herramientas de la
Web Semántica para ofrecer servicios de recuperación de información en el ámbito de los
hospedajes.
Los Servicios Basados en la Localización de los usuarios y la implementación de
tecnologías de la Web Semántica permiten generar un componente de tipo API (Application
Programming Interface) que reciba una petición de recomendación de hospedajes y el
resultado devuelto al usuario sea considerando el uso de la información contextual, perfiles del
usuario y reglas contextuales para determinar la importancia de los resultados para el usuario,
para resolver ubicaciones de lugares o servicios de interés.
En CENIDET existen investigaciones desarrolladas previamente, las cuales abordan el
uso de tecnologías de Servicios Basados en Localización y servicios contextuales; actualmente
existen investigaciones en desarrollo con enfoque de servicios contextuales y
recomendaciones.
1.7 Beneficios
Con el desarrollo de la Web API propuesto para esta tesis se obtuvieron los siguientes
beneficios:
Permite que otros desarrolladores hagan uso de una o más funciones que requieran
para desarrollar interfaces de usuario personalizadas.
La API permite al desarrollador que seleccione una de las funciones que retorne
resultados con el nivel de precisión deseado.
Esta investigación continúa el trabajo de reglas de inferencia que está en desarrollo en
Cenidet.
Se genera una ontología del dominio de hospedajes y un conjunto de reglas de
inferencia de acuerdo a las preferencias del usuario que se puede llegar a reutilizar en
trabajos futuros.
Capítulo I. Introducción
7
El servicio de recuperación de información ofrece resultados de acuerdo a la
información que se recibe del entorno en el que se desenvuelve el usuario.
1.8 Alcances
Se identificarán y generarán una base de reglas (de acuerdo al dominio) que haga uso
de la información contextual del usuario que permitan añadir conocimiento a la API
para razonar sobre los resultados obtenidos.
Se implementarán reglas de inferencia para determinar las mejores coincidencias del
contexto del usuario con los resultados obtenidos.
Se genera una ontología de dominio de hospedajes que describa los servicios y
características de los mismos.
Se genera una base de reglas que hace uso de la información contextual del usuario
para inferir sobre los hospedajes a recomendar.
La API se desarrolla en lenguaje Java y las reglas en lenguaje SWRL/SQWRL.
Se programan clases en lenguaje Java que permiten administrar la base de datos y
ejecutar la máquina de inferencias.
1.9 Limitaciones
El dominio de específico es el de hospedajes.
La ontología considera los servicios, infraestructura y características de las
habitaciones y un perfil de usuario.
La ejecución de las reglas se realiza con la máquina de inferencias de Jess.
Se pueden eliminar reglas o añadir otras siempre que cumplan la estructura antecedente
y consecuente y que utilice las clases y propiedades definidas en la ontología.
El prototipo realiza recomendaciones contextuales mediante el uso del modelo
ontológico y de reglas de inferencia.
Se trabaja con las funcionalidades existentes en SWRLTab y los built-ins1
(funcionalidades adicionales) que éste incluye; por lo que no se desarrollaron built-ins
adicionales.
1 Built-in son funcionalidades que se agregan a SWRL como rutinas para manipular cadenas o datos.
Capítulo I. Introducción
8
1.10 Organización del documento
El documento se encuentra organizado en 7 capítulos, los cuales presentan la siguiente
información:
Capítulo 2: Marco Teórico. Se presentan los fundamentos teóricos de las diferentes
tecnologías usadas y se describen los conceptos utilizados en el desarrollo del
documento.
Capítulo 3: Estado del arte. Se presentan trabajos relacionados con el proyecto de tesis,
desarrollados recientemente.
Capítulo 4: Análisis y Diseño. Se describen los casos de uso, escenarios, diagramas de
clases y de secuencia que representan el análisis y diseño de la API realizada.
Capítulo 5: Implementación. Explica información detallada de la arquitectura y los
diferentes módulos que la conforman. Se describen los paquetes que se desarrollaron y
las clases que las conforman.
Capítulo 6: Pruebas. Describe los resultados de las pruebas realizadas a la
implementación.
Capítulo 7: Conclusiones. Se presentan las conclusiones derivadas de este trabajo, las
principales aportaciones y los posibles trabajos futuros que se pueden realizar a partir
de esta investigación.
Capítulo 2. Marco Teórico En este capítulo se presenta la teoría relacionada con este trabajo de tesis. Se inicia
describiendo los LBS, se continúa describiendo la Web Semántica y se finaliza describiendo
dos de los lenguajes de la Web semántica.
Capítulo II. Marco teórico
10
2.1 Servicios Basados en Localización (LBS)
El término “Servicios Basados en Localización” (LBS por sus siglas en inglés) se
describe en [Sanna08] como servicios que usan el conocimiento de la ubicación geográfica de
un usuario para proveerle respuestas a consultas específicas, tales como información a turistas
o rutas hacia cierto destino. Todos estos servicios son usualmente basados sobre redes de
comunicaciones móviles y una o más tecnologías de localización (GPS o la misma red de
dispositivos móviles) combinada con Sistemas de Información Geográfica (GIS).
Entre los sistemas LBS más difundidos están los sistemas de navegación para
automóviles, los cuales pueden calcular rutas para los usuarios móviles, integrando cálculos de
rutas óptimas con información de tránsito en tiempo real con el fin de re-calcular la ruta en
caso de tránsito pesado.
Otros sistemas LBS tienen propósitos de información (ej. Páginas amarillas o guías de
viaje multimedios) y contestan a preguntas como “¿Dónde está el servicio o lugar más cercano
a mi ubicación?” o proveer información acerca de un sitio de interés. Otros servicios
importantes son los de emergencia, como el “911” en Estados Unidos o el “118” en Europa,
los cuales deben de seguir estándares acerca de las tecnologías de localización para ser usadas,
los cuales requieren de mucha precisión. Esta lista podría continuar con el rastreo y servicios
de administración o servicios a la comunidad como “búsqueda de personas” (contestando las
peticiones como “encuentra mi amigo” o “¿Dónde está mi perro ahora?”).
La estructura de un LBS está compuesto por 5 elementos [SANNA 08]: Un dispositivo
móvil (ej. Un teléfono celular o PDA), una red de comunicación móvil, un componente de
localización (ej. un receptor GPS), un proveedor de servicios y finalmente un proveedor de
información.
Los dispositivos móviles son categorizados como dispositivos de uno o múltiples
propósitos. Un ejemplo de un dispositivo de un sólo propósito (dispositivo especializado) son
los sistemas de navegación para automóviles. Por otro lado los dispositivos multipropósito
pueden ser usados por aplicaciones que incluyen a los LBS, tales como teléfonos celulares,
computadoras portátiles, PDAs, etc.
Las redes de comunicación tienen la tarea de transmitir las peticiones del usuario desde
el dispositivo del usuario al proveedor del servicio y acarrear las respuestas de regreso al
usuario. Las redes pueden ser inalámbricas de área extensa (Wireless Wide Area Network,
WWAN) tal como las redes GSM o UMTS, de área local (Wireless Local Area Network,
WLAN) como la 802.11 de la IEEE, o de área personal (Wireless Personal Area Network,
WPAN) como las redes Bluetooth.
Capítulo II. Marco teórico
11
El componente de localización tiene el objetivo de determinar la localización del
dispositivo móvil. Este puede ser obtenido a través de las redes de comunicaciones
(triangulación celular) o con un receptor GPS.
El proveedor de servicio es el componente que ofrece el Servicio Basado en
Localización al usuario. El proveedor es el responsable de procesar los datos y puede ser
también el proveedor de información o hacer uso de un tercer proveedor de información.
Los tipos de datos involucrados en una aplicación LBS son de tipo geográficos como
mapas o imágenes satelitales georeferenciadas, datos de texto/numérico como páginas HTML
o archivos de audio/vídeo. En [Gerardo08] menciona algunos ejemplos de servicios que se
ofrecen utilizando LBS (puede verse en 2.1.1) y nos describe el proceso de localización (puede
verse en 2.1.2).
2.1.1 Ejemplos de Servicios Basados en la Localización (LBS)
A continuación se presenta una clasificación de los Servicios Basados en Localización y
algunos ejemplos del mundo real de algunas de las categorías:
Navegación y Guiado (ej. TomTom2).
Seguimiento (ej. de niños pequeños o personas con problemas de orientación como
ancianos).
Gestión de Grupos y Flotas: esta situación tiene gran aceptación en servicios de
ventas que consiste en el seguimiento y localización de personal y traslado de
productos).
Filtrado de la Información (por ejemplo localización de restaurantes cercanos o
sistemas de recomendación de servicios según perfil y ubicación de usuarios).
Redes Sociales (por ejemplo, MoSoSo3; el escenario que se plantea es que el usuario
llega a una ciudad y busca a gente de su red social con la cuál hospedarse).
Servicios de Proximidad (M2M4: por ejemplo el pago en máquinas de ventas
haciendo uso de sistemas RFID integrados en el dispositivo móvil).
Todas estas aplicaciones necesitan información de contexto, pero existe una polémica si
deben ser los operadores de los servicios los encargados de almacenar, custodiar y explotar la
información de contexto de los usuarios o debe ser el propio usuario quién resguarde su
información; de ahí se desprende la pregunta ¿cómo se mantiene la privacidad que puede verse
vulnerada? Los aspectos de seguridad de información representan una temática importante
dentro de los Servicios Basados en Localización, sin embargo, esta temática queda fuera de los
propósitos de esta tesis.
2www.tomtom.com 3MoSoSo es el acrónimo de “Mobile Social Software”. 4 M2M es el acrónimo de Machine to Machine, Máquina a Máquina.
Capítulo II. Marco teórico
12
2.1.2 El proceso de localización
Los tipos de localización son: físico (longitud, latitud, altura) y simbólico (comprensible
por la persona, ej. “estás en CENIDET”), absoluto (en el caso de disponer de un sistema de
referencia como lo es un GPS) y relativo (solamente se obtienen referencias respecto a otros
usuarios o estaciones base, como en redes WiFi o Bluetooth), soportado por red (la que hace
los cálculos de posicionamiento basándose en los datos suministrados por el terminal) o
soportado por terminal (realiza sus cálculos basándose en datos suministrados por la red y
otras fuentes externas).
Existen una serie de condicionantes que hay que tener en cuenta a la hora de desarrollar
el proceso de localización: precisión, disponibilidad, consistencia, overhead, consumo de
energía, escalabilidad, latencia, costos de operación, limitaciones (interior, exterior).
Los Servicios Basados en Localización y el uso de la información contextual es
actualmente una oportunidad de negocios para definir aplicaciones orientadas a las
necesidades específicas de los usuarios.
2.1.3 LBS contextuales
Para describir los LBS contextuales [Yu05], se debe considerar que todo servicio tiene
dependencia de algún contexto, en particular del significado de los términos que aparecen en
las consultas del usuario. Sin embargo, la tecnología tradicional de base de datos, ignora en su
mayoría la información de contexto, proporcionando servicios de datos basados en un único
contexto implícito. Los contextos son definitivamente un área de donde se pueden realizar
muchas investigaciones, en particular para la comunidad de base de datos.
Los LBS que consideran la información contextual (LBS contextuales) agrupan
cualquier información que caracteriza a la situación de una persona, lugar u objeto, así como
el significado de las cosas y que se pueden utilizar para proporcionar servicios más relevantes
para el usuario. La información contextual en los LBS contextuales normalmente incluye la
ubicación del usuario, el tiempo, el clima, las condiciones del tráfico, etc. Los sistemas que
utilizan contextos se denominan sistemas consientes del contexto (context-aware systems).
El contexto puede ser usado como un criterio fuerte o suave en la selección de servicios
pertinentes o relevantes. Un criterio fuerte permite descartar los servicios que no cumplen con
dichos criterios, mientras que un criterio suave ordena el conjunto de los servicios
seleccionados. Por ejemplo, la ubicación del usuario puede ser utilizada para seleccionar sólo
los hospedajes dentro de una cierta distancia desde la del usuario (criterio duro), o puede ser
usado para ordenar los hospedajes seleccionados en función de su distancia desde el usuario
(criterio suave).
En un entorno móvil, la información contextual puede estar continuamente cambiando.
Para los LBS contextuales, las condiciones meteorológicas, por ejemplo, pueden implicar
Capítulo II. Marco teórico
13
cambios en la estrategia en la búsqueda de información, o puede hacer que el usuario cambie
de actividad, del trabajo al ocio, por ejemplo, que impliquen diferentes requisitos de
información. En consecuencia, los contextos no pueden obtenerse una sola vez, sino que
tienen que ser controlados, a fin de mantener la información contextual actualizada.
El problema semántico en el manejo de LBS contextuales es determinar cuál es la
información contextual relevante para la tarea actual. No tiene sentido el manejo de contextos
muy sofisticados, si sólo unos pocos componentes son realmente útiles. Por el contrario, se
ofrecerán servicios de menor calidad si falta información contextual.
2.2 Web Semántica
La Web Semántica es una Web extendida, que está dotada de mayor significado, donde
cualquier usuario en Internet podrá encontrar respuestas a sus preguntas de forma más rápida y
sencilla, gracias a una información mejor definida. Al dotar a la Web de más significado y, por
lo tanto de más semántica, se pueden obtener soluciones a problemas habituales en la
búsqueda de información, gracias a la utilización de una infraestructura común, mediante la
cual es posible compartir, procesar y transferir información de forma sencilla. Esta Web
extendida y basada en el significado, se apoya en lenguajes universales que resuelven los
problemas ocasionados por una Web carente de semántica en la que, en ocasiones el acceso a
la información se convierte en una tarea difícil y frustrante [W3C_WS08].
2.2.1 ¿Para qué sirve?
A través de la Web actual tenemos acceso a millones de recursos, independientemente
de nuestra situación geográfica e idioma. Todos estos factores han contribuido al éxito de la
Web. Sin embargo, al mismo tiempo, estos factores que han propiciado el éxito de la Web
también han originado sus principales problemas: sobrecarga de información y heterogeneidad
de fuentes de información con el consiguiente problema de interoperabilidad.
La Web Semántica ayuda a resolver estos dos importantes problemas permitiendo a los
usuarios delegar tareas en software. Gracias a la semántica en la Web, el software es capaz de
procesar su contenido, razonar con éste, combinarlo y realizar deducciones lógicas para
resolver problemas cotidianos automáticamente.
2.2.2 ¿Cómo funciona?
Para comprender mejor el uso de la Web semántica, a continuación se describe un
ejemplo sobre una consulta para obtener información de vuelos y la diferencia de resultados al
usar un buscador que hace uso de información semántica y un buscador común que no la
utiliza. Por ejemplo, encontrar todos los vuelos a la ciudad de Praga para mañana por la
mañana, con el uso de la Web semántica se podrían obtener resultados más pertinentes y
Capítulo II. Marco teórico
14
exactos sobre su búsqueda. Sin embargo la realidad es otra. En la figura 2.1 se muestran los
resultados obtenidos con un buscador común, el cual ofrece información variada sobre Praga,
pero no muestra información que realmente el usuario requiere. El paso siguiente por parte del
usuario es realizar una búsqueda manual entre esas opciones que aparecen, con la consiguiente
dificultad y pérdida de tiempo.
Con la incorporación de semántica a la Web, los resultados de la búsqueda serían
exactos. La figura 2.2 muestra hipotéticamente los resultados que se obtendrían a través de un
buscador semántico. Estos resultados ofrecen al usuario información más precisa. La
ubicación geográfica desde la que el usuario envía su pregunta es detectada de forma
automática sin necesidad de especificar el punto de partida, elementos de la oración como
"mañana" adquirirían significado, convirtiéndose en un día concreto calculado en función de
un "hoy". Algo semejante ocurriría con el segundo "mañana", que sería interpretado como un
momento determinado del día. Todo ello a través de una Web en la que los datos pasan a ser
información llena de significado. El resultado final sería la obtención de forma rápida y
sencilla de todos los vuelos a Praga para mañana por la mañana.
Figura 2.1. Resultados obtenidos con un buscador normal [W3C_WS08].
Capítulo II. Marco teórico
15
Figura 2.2. Resultados obtenidos con un buscador semántico [W3C_WS08].
Los buscadores semánticos son un ejemplo más de aplicaciones basadas en Web
Semántica. El objetivo es satisfacer las expectativas de búsqueda de usuarios que requieren
respuestas precisas [W3C_WS08].
2.3 SPARQL
SPARQL es un acrónimo recursivo del inglés SPARQL Protocol and RDF Query
Language. Se trata de un lenguaje de consulta para la Web semántica que se estandarizó desde
el 2008 por el Grupo de Trabajo de Acceso a Datos (Data Access Working Group, DAWG) de
la W3C [Unicarlos08].
SPARQL define un lenguaje de recuperación para RDF/S (Resource Description
Framework/Schema). “El objetivo de la Web Semántica es permitir a las personas compartir,
combinar y reutilizar los datos de forma global. SPARQL ha sido diseñado para un uso a
escala de la Web, así permite hacer consultas sobre orígenes de datos distribuidos,
independientemente del formato. Es más sencillo crear una consulta a través de diferentes
almacenes de datos que crear varias consultas, además de tener un costo menor y de ofrecer
mejores resultados” [W3C_ES08].Esto permite consultar cualquier origen de datos que pueda
ser representada en RDF.
2.3.1 Componentes
El lenguaje SPARQL posee tres componentes importantes: URIs (Uniformed Resource
Identificator), literales y variables procedentes del lenguaje RDF.
Las URIs sirven para especificar los identificadores de las URLs (Uniform Resource
Locator). La descripción de este formato estándar está en la solicitud de comentarios
(Request For Comments) RFC 2396.
Capítulo II. Marco teórico
16
Literales se describen como una cadena de caracteres encerradas entre comillas " ",
lo que permiten definir valores.
Las variables son globales, además deben de ser prefijadas por "?" o "$" no
formando parte del nombre de la variable
2.3.2 Sintaxis
La sintaxis de SPARQL es similar a la de RQL (RDF Query Language), añadiendo
algunas modificaciones para facilitar el análisis sintáctico (parsing) del lenguaje. Como RQL,
SeRQL (Sesame RDF Query Language) se basa en una interpretación formal del grafo de
RDF, diferenciándose de RQL en que se basa directamente en la teoría del modelo RDF.
El lenguaje SPARQL tiene cuatro tipos de consultas, éstas con sus respectivas
descripciones se pueden observar en la figura 2.3:
Figura 2.3. Sintaxis de consultas en SPARQL [Ballesteros09].
Para ejemplificar el uso básico de SPARQL, la figura 2.4 muestra un ejemplo de una
ontología sobre el dominio de un “Restaurant”, la cual presenta una vista parcial de los
conceptos que caracterizan a los restaurantes. Entre estos conceptos se encuentran „Facilidad,
Bebida, Caracteristica_Especial y Cocina‟, los cuales a su vez describen los tipos de conceptos
existentes.
SELE
CT Devuelve todo,
o un conjunto de las variables que coinciden con el patrón de búsqueda. C
ON
STR
UC
T Devuelve un grafo RDF construido por la sustitución de variables en un conjunto de tres plantillas.
ASK
Devuelve un boolean indicando si los patrones de la consulta coinciden o no.
DES
CR
IBE Devuelve un
grafo RDF que describe los recursos encontrados.
Capítulo II. Marco teórico
17
Figura 2.4. Vista parcial de la ontología “Restaurant”, graficada en Protégé [Ponce].
En la figura 2.5 se ejemplifica una consulta SPARQL en la cual se hace uso de la
instrucción SELECT, la cual consulta los tipos de „facilidades‟ que un restaurant puede llegar
a ofrecer. La sintaxis de la instrucción SELECT en SPARQL es muy similar a la de SQL
(Structured Query Language) usada para recuperar información en bases de datos relacionales.
La forma en que se escriben la información solicitada (dentro del WHERE) es equivalente a
una tripleta en la forma sujeto-relación-objeto.
Figura 2.5. Ejemplo de consulta sobre una ontología con SPARQL.
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX rdfns: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX xmls: <http://www.w3.org/2001/XMLSchema#>
PREFIX rest: <http://www.owl-ontologies/restaurant.owl#>
SELECT ?Facilidades
WHERE
{
?Facilidades rdfs:subClassOf rest:Facilidad
}
ORDER BY (?Facilidades)
Capítulo II. Marco teórico
18
En la figura 2.6 se observa una tabla con los tipos de los „facilidades‟ que se consultaron
de la ontología.
Figura 2.6. Resultados obtenidos al ejecutar la consulta con SPARQL.
2.4 SWRL
El Lenguaje de Reglas de la Web Semántica (SWRL por sus siglas en inglés) de acuerdo
a [Cardoso09] es un formalismo para integrar reglas con ontologías en la Web Semántica y
está basado en una combinación de dos lenguajes: el Lenguaje de Ontologías Web (OWL por
sus siglas en inglés) y el Lenguaje de Marcas de Reglas (Rule Markup Language, RuleML).
Desde 2004, SWRL es un candidato a estándar por la W3C para formalizar la expresión de
reglas en el contexto de la Web Semántica.
La idea básica detrás de SWRL es el extender los axiomas OWL para incluir reglas tipo
“Horn” (Antecedente Consecuente; se lee Si Antecedente entonces Consecuente), mientras
mantiene la máxima compatibilidad con la sintaxis OWL y la semántica, es decir, la cabeza
(consecuente) y el cuerpo (antecedente) de la regla son generalmente sentencias OWL. Lo
anterior se refiere a que las reglas y las ontologías están combinadas en el mismo lenguaje
lógico. Específicamente en el enfoque SWRL, las reglas son introducidas al adaptar la
semántica existente por un lenguaje de reglas directamente en la capa de la ontología. Como
resultado de lo anterior la interacción entre reglas y ontologías es lograda con una fuerte
integración.
Las reglas SWRL se pueden ver como una fórmula del siguiente tipo:
Condición1 Condición2 … CondiciónN Consecuente
Capítulo II. Marco teórico
19
Donde Condición1 y Consecuente son átomos. Múltiples átomos antecedentes
son tratados con una conjunción (“y”), mientras que un conjunto de átomos en el consecuente
son tratados como consecuencias separadas (es decir, múltiples reglas con un único
consecuente en la cabeza). Tanto el antecedente como el consecuente pueden consistir de un
posible conjunto de átomos vacíos.
Los átomos pueden ser de la siguiente forma:
Conceptos, por ejemplo, C(x), donde C es una descripción OWL o un rango de datos y
„x‟ es cualquier variable, un “individual” (instancia) o un valor.
Objeto o una propiedad de tipo de datos, por ejemplo: P(x, y) donde P es una
propiedad y „x‟ y „y‟ son cualquier variable, un “individual” (instancia) o un valor.
sameAs (x, y), differentFrom (x, y) o builtIn (r, x, ···), donde r es una relación built-in y
„x‟ y „y‟ son cualquier variable, un “individual” (instancia) o un valor.
El conjunto de built-ins de SWRL se adhiere a un enfoque modular que permite que se
extiendan las funcionalidades a futuro. Existen built-ins para SWRL que proveen entre otros,
operadores de comparación aritméticos y de tiempo.
El inconveniente principal de extender OWL-DL con reglas SWRL es que el
conocimiento base extendido (OWL-DL + SWRL) llega a ser difícil de manipular.
Adicionalmente, SWRL no soporta „la negación‟ de los átomos (equivalente al operador not o
) ni en la cabeza ni en el cuerpo de una regla. Además se puede observar en la fórmula
anterior que las reglas SWRL no pueden incluir disyunciones5.Como resultado SWRL inserta
un número de limitaciones en la expresividad de la regla, por lo tanto limitan la funcionalidad
de una aplicación.
De manera informal una regla puede interpretarse como una indicación de que si el
antecedente es cierto entonces el consecuente también es cierto. Utilizando esta sintaxis
(notación lógica clásica) la propiedad de “ser tío de” se describiría de la siguiente forma:
Persona (?x) Persona (?y) esHermano (?x, ?y) esPadre (?x, ?z)
esTio (?y, ?z)
En el caso de una navegación en interiores de edificios se puede mencionar la siguiente
regla:
UsuarioSillaRuedas(u) Escaleras(s) ExcluirPara (s,u)
Esta regla captura el conocimiento común en el que una ruta adecuada para usuarios de
sillas de ruedas no debe contener escaleras.
5Disyunción es un operador lógico que representa un ‘o’ (“or”).
Capítulo II. Marco teórico
20
2.4.1 Máquina de reglas
Una máquina de reglas es un módulo que ejecuta las reglas de la aplicación e infiere
nuevo conocimiento. Actualmente existen varias máquinas de reglas utilizables y eficientes.
Algunas de las más representativas de acuerdo a [Cardoso09] son:
Bossam, es una máquina de inferencia que provee capacidades de razonamiento sobre
OWL, SWRL y RuleML. Bossam tiene varias características que incluyen soporte para
negaciones clásicas y negaciones como fallas (NAF, negation-as-failure), disyunciones en el
cuerpo y conjunciones en la cabecera de las reglas, un método Java, etc. Finalmente, provee
una API para manipular la máquina, cargar ontologías y reglas. Actualmente Bossam no
soporta la ejecución de consultas SPARQL.
RacerPro, es el nombre comercial de RACER software, el cual probablemente es la
máquina de inferencia más conocida para ontologías escritas en OWL. RacerPro aspira a
convertirse en un framework universal para manipular ontologías de la Web Semántica y
recientemente ofreció una máquina de reglas SWRL. Racer ha sido probado como un
razonador-DL (razonador de datos lógicos) y provee una eficiente ejecución de reglas.
Jena, es un Framework Java de fuente abierta para aplicaciones de Web Semántica.
Entre otras características Jena provee una máquina de inferencia basada en reglas pero no
soporta reglas SWRL. Esto hace que los usuarios de Jena como máquina de reglas adopten su
propio lenguaje de reglas RDF (Jena Rules) o haga uso de la herramienta “SweetRules” para
pasar parcialmente SWRL a Jena Rules.
Jess, es una máquina de reglas escrita completamente en Java. Aunque Jess no puede
procesar directamente las reglas SWRL, el módulo SWRLTab para Protégé ofrece la
capacidad de traducir la ontología OWL más las reglas SWRL en hechos y reglas. Como
resultado, Jess puede ser usado como un módulo razonador para ejecutar reglas en conjunto
con las ontologías.
2.4.2 Preferencias de usuario, reglas y SWRL.
Las preferencias del usuario pueden ser definidas como reglas o políticas que pueden ser
configuradas por el usuario para afinar el comportamiento de un servicio [Plas06].Esto
significa que las preferencias están siempre relacionadas a un servicio. Las preferencias de
usuario pueden ser usadas para: a) configurar información genérica que los servicios usan (ej.
Nombre, dirección, etc.), b) configurar la apariencia del servicio y c) influenciar el
comportamiento o funcionalidad del servicio.
Estos tres casos permiten definir qué sucederá en puntos específicos de tiempo: Auto
completar información en campos de entrada, seleccionar detalles como color de fondo, fuente
de letra, etc., o la ejecución de acciones o funciones específicas (ej. notificaciones por correo
Capítulo II. Marco teórico
21
electrónico, etc.).Las preferencias del usuario hacen que los servicios sean mucho más
flexibles y son absolutamente necesarios para personalizar estos servicios.
Las preferencias de usuario definen qué acciones necesitan ser tomadas cuando algo
sucede en una situación en particular. Si un evento es definido como algo que sucede y el
contexto es una situación particular, la forma general de la preferencia del usuario sería la
siguiente:
Si evento y condición de contexto entonces realiza acción.
El evento, es lo que sucede, está también relacionado al servicio (ej. una llamada
telefónica entrante en una nueva red disponible) o al cambiar de información contextual (ej.
recibir una alerta si un amigo está en nuestro vecindario).
La condición describe una situación en la cual ocurre el evento. El mismo evento puede
resultar en la ejecución de diferentes acciones en diferentes situaciones. Por ejemplo, se podría
desear manejar de distintas formas las llamadas telefónicas entrantes cuando el usuario se
encuentra trabajando en la oficina o cuando está en un día libre.
Las acciones son relacionadas a los servicios disponibles al usuario. Por ejemplo, cada
usuario puede estar suscrito o tener acceso a varios servicios mediante telefonía móvil como
servicios de comunicación de audio/vídeo, mensajería instantánea, Internet, etc. Ejemplos de
acciones para los servicios mencionados son: “desviar llamadas a buzón”, “contestar o no
contestar llamadas”, “recibir notificaciones mediante SMS”, “incluir vídeo en la llamada”, etc.
Usando el formato de reglas SWRL se pueden describir las preferencias de usuario
como:
evento ^ condición acción
en el cual el evento representa un cambio de información de contexto, la condición
describe la situación por el valor de atributos específicos de contexto y la acción identifica lo
que se realizará.
Hay que recordar que SWRL es una extensión de OWL y que las clases, propiedades y
las instancias de operadores que se definen en OWL pueden ser usadas para definir esas
reglas.
Capítulo 3. Estado del arte En este capítulo se describen los trabajos relacionados con el presente trabajo de investigación
analizando los métodos propuestos por sus autores. Se presenta también una comparación
entre los distintos trabajos relacionados y el método propuesto en este trabajo de investigación.
Capítulo III. Estado del arte
23
A continuación se analizan los trabajos relacionados en el área de implementación de reglas
contextuales para realizar recomendaciones. Específicamente se analizaron los trabajos que
llevan a cabo una implementación de ontologías con reglas contextuales con el fin de observar
las similitudes entre dichos trabajos y el presente trabajo de investigación. El orden en que se
presentan los trabajos relacionados denota la relevancia o similitud con el proyecto de tesis.
3.1 A Context-Aware e-Tourism Application Enabling Collaboration
and Knowledge Exchange among Tourists [Paganelli06].
El proyecto presentado en este artículo resume las características del Framework
'Kamer' (Knowledge Management in Ambient Intelligence) el cual describe una aplicación
orientada al e-Turismo (turismo electrónico) consciente de contexto, misma que a su vez
provee a los turistas servicios de acuerdo al contexto de estos.
El escenario propuesto consiste en usuarios (turistas) que disponen del servicio de
Kamer en su dispositivo móvil, el cual ofrece recorridos y puntos de interés de acuerdo a su
perfil y su información contextual. La aplicación Kamer ofrece servicio de mensajería
instantánea con otros turistas que tengan los mismos intereses. La arquitectura del sistema
consta de los siguientes componentes:
Un Middleware6 administrador de contextos (basado en ontologías), el cual se
encarga de obtener los contextos y calcular sobre los valores obtenidos de estos,
procesarlos y hacer inferencias.
Un servicio administrador de reputación de los proveedores, el cual ofrece ayuda
al turista en el proceso de toma de decisiones mediante un sistema de
calificaciones sobre los servicios que el sistema ofrece. Todos los usuarios pueden
colaborar con calificaciones de los servicios.
Una aplicación de entrega de contenido, la cual ofrece información multimedia al
usuario con respecto al punto de interés en donde se encuentre. La información no
es solicitada por el usuario, es decir, el sistema proactivamente entrega el
contenido correspondiente.
El sistema de mensajería instantánea (en desarrollo a la fecha de publicación del
artículo) el cual agrega a la lista de contactos a otros turistas cercanos y con
intereses similares.
Los contextos considerados son la ubicación, las preferencias de usuario, la actividad
actual, la cercanía a puntos de interés y la proximidad física a otros turistas, en especial a los
que tienen similitudes en recorridos y preferencias como servicios turísticos (hoteles,
restaurantes, etc.). También considera para el servicio de mensajería un perfil de datos como
6 Un Middleware es un software que conecta otros componentes de software o aplicaciones para que pueden intercambiar datos entre si [Midd08].
Capítulo III. Estado del arte
24
edad, nacionalidad, etc. Estos contextos son administrados por un middleware, permitiendo
obtener, almacenar o enviar los contextos a otras aplicaciones.
Los puntos de interés pueden tener su propio administrador de contextos, el cual está
enlazado al servicio principal y personaliza la información y servicios que ofrecen a los
usuarios que están cercanos de ese punto de interés mediante reglas SWRL. El razonador de
contextos está basado en la máquina de reglas "Jena". La arquitectura del sistema Kamer se
observa en la figura 3.1.
Figura3.1. Arquitectura del sistema Kamer [Paganelli06].
3.2 Semantic Rules for Context-Aware Geographical Information
Retrieval [Carsten09].
Este artículo presenta como escenario la tarea de encontrar lugares para practicar „Surf‟
tomando en cuenta información de contexto como: 1) la ubicación del usuario (y su cercanía
con el lugar a recomendar), 2) la altura de las olas, 3) el tipo de fondo del mar y 4) el nivel de
concurrencia (multitud de personas).
Considerando los 4 contextos anteriores, se definieron dos usuarios típicos para este
servicio de acuerdo a su nivel de experiencia en el Surf: Los usuarios principiantes y los
profesionales.
La ontología en la que se basan considera todos los aspectos que un Surfista requiere
conocer sobre un lugar para practicar Surf, aunque no todos los conceptos son considerados en
Capítulo III. Estado del arte
25
el sistema (Fig. 3.2) debido al problema de adquisición y actualización de datos hacia la
ontología.
En la ejecución del sistema se considera el modelo de usuario el cual modela las
preferencias de los dos tipos de usuarios mediante reglas SWRL y hace uso de built-ins para
las operaciones matemáticas correspondientes.
Figura3.2. Ontología Surf Spot [Carsten09].
3.3 Context inferring in the Smart Home: An SWRL approach
[Ricqueb07].
En este artículo los autores presentan un sistema consciente de contexto que permite la
implementación de algunos servicios de una casa inteligente haciendo uso de las herramientas
de la Web Semántica.
La casa inteligente requiere adquirir datos desde el comportamiento de los habitantes y
las características de su entorno. Proponen una arquitectura de tres capas: 1) la capa de
sensores se encarga de la adquisición de datos y los envía a la siguiente capa, 2) la capa de
Capítulo III. Estado del arte
26
contextos procesa la información a nivel semántico (apoyándose en una ontología de dominio
OWL) de los datos adquiridos, y 3) la capa de servicios decide si se ejecutarán acciones sobre
los actuadores en la casa.
Cada vez que un sensor detecta un cambio en el entorno del usuario envía los datos, los
cuales actualizan la ontología y a su vez la capa de servicios infiere con SWRL las acciones a
ejecutar.
El escenario actual con el que trabaja el sistema es con los servicios de iluminación en la
casa. El proceso se completa en 5 pasos: 1) los sensores proporcionan información de
detección de movimiento (múltiples sensores en una habitación segmentan las áreas en donde
se encuentra un usuario), 2) el evento es enviado al bus de datos, y los servicios suscritos
reciben el evento (todos los sensores se conectan al bus y llenan la ontología con los datos), 3)
las reglas de inferencia (SWRL) permiten deducir las acciones a realizar, 4) para decidir si se
realizará la acción, el servicio de la ontología observa los valores de las instancias buscando si
hay un cambio en el estado de los actuadores. Si es así, se envía la orden al actuador
correspondiente y 5) cuando el controlador del actuador recibe un evento enviado por la
ontología, este aplica el nuevo valor a la iluminación. El principal inconveniente encontrado
en este proyecto es el tiempo de razonamiento de la máquina de inferencia de alrededor de 5
segundos.
3.4 Semantic Location Based Services for smart spaces [Kostas07].
Este artículo presenta el desarrollo de un sistema de navegación basado en ontologías, el
cual permite hacer consultas para encontrar un punto espacial ubicado en interiores de
edificios. Dicho proceso se basa en una ontología de navegación en interiores (Indoor
Navigation Ontology, INO). En esta ontología se describen clases como espacios (pisos,
pasillos, cuartos, edificios, etc.), obstáculos, rutas, POI (puntos de interés), etc.
La navegación que permite este sistema es resultado de la unión de grafos y reglas en
lenguaje SWRL, donde se representan los perfiles de usuario y contenidos semánticos. Éste
sistema basado en localización implementa algoritmos de navegación a través de reglas. Estas
reglas son usadas para eliminar rutas que no pueden ser recorridas por ciertos usuarios (ej.
personas ciegas o que usan silla de ruedas) y es aquí donde implementan información
contextual de usuarios (perfiles).
Capítulo III. Estado del arte
27
3.5 Towards Self-managed Pervasive Middleware using OWL/SWRL
ontologies [Zhan08].
El enfoque de esta investigación radica en la capacidad de un Middleware auto-
administrado (proyecto Hydra), con capacidad de detectar problemas dentro del sistema e
incluso de proponer soluciones de auto-recuperación. La característica clave para que un
sistema sea auto-administrado es la conciencia del contexto (Context awareness).
El escenario propuesto es en una granja de animales, en donde uno de los trabajadores
recibe en su PDA una alarma de falla en el sistema de ventilación del establo. El sistema
realiza un diagnóstico y decide que el problema es un fusible quemado en la fuente de energía.
El trabajador prepara un fusible y repara el ventilador. Después elije un mensaje predefinido
en el sistema que describe lo acontecido.
Las características de conciencia que un sistema debe tener definidas por los autores son:
1) conciencia de los recursos (CPU, software y sistema operativo), 2) conciencia de energía
(los niveles de batería de los dispositivos móviles y del uso de energía para transmitir datos),
3) conciencia de la calidad en el servicio (Quality on Service, latencia) y 4) conciencia de
seguridad (entregar los datos al usuario exacto en el momento exacto y en el formato
adecuado).
Su arquitectura se basa en 18 ontologías, en donde una de ellas contiene 22 reglas que
monitorean al sistema, infieren errores o posibles fallos o proponen soluciones a los fallos
conocidos.
3.6 Self-adapted Service Offering for Residential Environments
[González07].
Este artículo presenta una herramienta que tiene como finalidad localizar y ofrecer al
usuario servicios disponibles y personalizados desde Internet. Para ofrecer estos servicios se
consideraron los dispositivos que se encuentran en la red de casa de los usuarios y las
características de subscripciones a otros servicios. Los proveedores de servicios deben definir
sus servicios y sus perfiles para permitir que esta aplicación obtenga servicios útiles y
personalizados. Ésta aplicación denominada en el artículo como un "Autonomic Element"
(Elemento autónomo) fue desarrollada considerando un Home Gateway y un Framework
OSGi (Open Service Gateway initiative).
La aplicación considera como entrada una breve información contextual y una lista de
servicios y dispositivos instalados en la red de casa. Por ejemplo, cuando se conecta un
Webcam en la red de la casa, el sistema busca y ofrece servicios de video-vigilancia o de
videoconferencia. El perfil de usuario que la aplicación utiliza incluye información como el
tipo de cliente, el costo máximo de los servicios entre otras propiedades que enlazan al usuario
Capítulo III. Estado del arte
28
con los proveedores de servicios. También es posible inferir con que servicios cuenta el
usuario y cuales más están disponibles que complementen a los existentes y al hardware
usado.
3.7 i-footman - A Knowledge-based Framework for Football
Managers [Vassilis09].
El proyecto i-footman (intelligent football manager) está enfocado a realizar sugerencias
en el proceso de toma de decisiones de un director técnico en el ámbito previo y durante un
juego de futbol soccer. La funcionalidad básica es el de proponer una alineación de jugadores
táctica (considerando la alineación del contrincante) y una selección de jugadores
(considerando las características de los que tienen ciertas habilidades para ciertas posiciones
en el campo).
El proyecto se basa en dos ontologías específicas del dominio (ontología de jugadores y
de equipos) y con reglas semánticas en el lenguaje SWRL con las cuales el sistema se apoya
para realizar las recomendaciones. Dichas reglas infieren sobre el contexto de datos y son
clasificadas en cuatro tipos, las cuales permiten establecer las recomendaciones ofrecidas:
1. Reglas de identificación: Tienen el objetivo de identificar las debilidades y ventajas
de los oponentes. Principalmente se basan en la formación y características de los
jugadores con el fin de deducir las capacidades del oponente.
2. Reglas de formación: Responsables de especificar la formación táctica que el
equipo debe seguir durante un encuentro. En particular el número de defensas,
medio-campistas, y delanteros es determinado así como las posiciones que ellos
deben cubrir.
3. Reglas de selección de jugadores: Usa las características de los jugadores y de la
formación táctica de los equipos. Proponen los jugadores apropiados de acuerdo a la
clasificación que ha sido completada en los procesos de razonamiento de la
ontología.
4. Reglas de instrucciones tácticas: Especifica las instrucciones tácticas sugeridas por
el sistema. Las reglas toman ventaja de las debilidades y fortalezas del oponente
especificadas por la identificación de reglas y de información proveniente de las
reglas de formación.
Las sugerencias del sistema se han implementado en dos simuladores, mejorando un
poco la cantidad de partidos ganados y disminuyendo por mucho los partidos perdidos
(aumentado las estadísticas de empates). La principal desventaja que los autores destacan de
trabajar con inferencias es el tiempo de ejecución.
Capítulo III. Estado del arte
29
3.8 Comparativa de trabajos relacionados con el proyecto.
En la tabla 3.1 se comparan las características deseadas en el proyecto de tesis con los
trabajos relacionados en el estado del arte. Las características requeridas en el proyecto son el
uso de ontologías OWL y reglas SWRL para poder realizar inferencias sobre los contextos de
usuario y/o de datos y ofrecer resultados en consideración a las preferencias del usuario. El
proyecto adicionalmente consulta la ubicación de lugares (hospedajes) sobre bases de datos
espaciales por lo que es otra característica a considerar.
Los criterios considerados en la búsqueda y comparación de los trabajos relacionados
son:
Ontologías OWL y reglas SWRL: El uso de ontologías OWL en conjunto con la
implementación de reglas SWRL son las principales características que deben de ser
considerados en los trabajos del estado del arte, pues estas dos características son las
herramientas principales en la técnica de la solución del problema.
Contexto de usuario: El uso de la información del contexto del usuario es el que
permite que se compare lo que el usuario necesita o realiza con lo que un servicio
puede ofrecer. El trabajo de tesis hace uso de esta información para establecer las
necesidades del usuario respecto a los hospedajes.
Contexto de datos: El contexto de datos aporta las características de lo que se está
recomendando para poder delimitar los servicios ofrecidos. El trabajo de tesis analiza
las características de los hospedajes para validar las recomendaciones.
Consultas sobre BD espaciales: La información con la que se trabaja puede estar
relacionada con puntos geo referenciados, por lo que es preferible que los trabajos
relacionados hagan uso de esta tecnología para aproximarse más con el método de
solución implementado en el trabajo de tesis.
Localiza servicios o lugares: Es importante conocer si el uso de ontologías y reglas
tienen el enfoque de localizar algún servicio o algún lugar, ya que no todos los
trabajos analizados tienen esa finalidad. Uno de los puntos clave de este trabajo de
tesis es recomendar los servicios de hospedajes que a su vez están marcados en un
lugar en específico.
Desarrollo de API: El objetivo de esta tesis es el desarrollo de una API, por lo que es
importante conocer si los trabajos relacionados tienen como resultado la creación de
un sistema o de una API que pueda ser reutilizada a la medida de las necesidades de
una aplicación desarrollada por algún tercero.
Capítulo III. Estado del arte
30
Tabla 3.1. Comparativa de trabajos relacionados.
Trabajo Ontologías
OWL y reglas
SWRL
Contexto
de
usuario
Contexto
de datos
Consultas
sobre BD
espaciales
Localiza
servicios
o lugares
Desarrollo
de API
[Paganelli06] Si Si No Si Si No
[Carsten09] Si (2 reglas) Si Si No Si No
[Ricqueb07] Si Si Si No No No
[Kostas07] Si Si No Si No No
[Zhan08] Si (22 reglas) Si Si No No No
[González07] Si Si Si No Si No
[Vassilis09] Si No Si No No No
Tesis Si (87 reglas) Si Si Si Si Si
En la tabla 3.2 se presentan los artículos anteriores con la finalidad de relacionar la
investigación realizada con el presente trabajo de tesis. La innovación en el uso de ontologías
y reglas semánticas delimita la cantidad de trabajos relacionados de la presente investigación.
En la misma tabla se presentan algunos de los principales centros de investigación públicos y
privados que trabajan con tecnologías OWL/SWRL.
Tabla 3.2. Relación de los trabajos con la tesis.
Área: Recomendaciones con ontologías OWL/SWRL
Relación con el trabajo Descripción
Las ontologías permiten mantener una estructura ordenada de conceptos sobre un dominio, así como una relación explícita entre los conceptos que la integran; las limitantes de falta de procesamiento matemático, manipulación cadenas de caracteres y otras capacidades de procesamiento junto con la representación del formalismo if… then son superados con la implementación de reglas semánticas SWRL.
El uso de ontologías para almacenar información permite un orden y una estructura donde se puede integrar y compartir la información. Las ontologías OWL no soportan condicionales y por lo tanto no se puede interpretar la información contextual con respecto a las actividades y preferencias del usuario. Este tipo de actividades se logra introduciendo reglas semánticas SWRL las cuales añaden esas capacidades de procesamiento a las ontologías OWL.
Capítulo III. Estado del arte
31
Estado del arte
En [Kostas07] y [Carsten09] orientan sus investigaciones a la localización de un lugar y consideran como principales entradas la ubicación del usuario y la del lugar que requieren. Además consideran contexto de datos como son las características del lugar que se busca.
A su vez, el trabajo de [González07] ofrece servicios de software al usuario de acuerdo a sus preferencias; el contexto principal es la lista de dispositivos conectados en su red. De manera similar el trabajo de [Paganelli06] ofrece a sus usuarios información dinámica respecto a algún lugar de interés en donde se encuentre el usuario. Este último proyecto ofrece recomendaciones como lo pueden ser restaurantes y añade la posibilidad de calificar el servicio recomendado por el sistema para compartir las calificaciones con otros usuarios de preferencias similares.
A su vez, trabajos como el de [Zhan08], presentan un Framework que considera como contexto la situación y los estados del mismo sistema en sí, con lo que puede hacer inferencias sobre la existencia de posibles problemas/soluciones en el sistema (sistema auto-administrado).
Principales centros de investigación
National Research Council, Canadá (Semantic Web Lab: SemWebLab), www.nrc-cnrc.gc.ca/eng/facilities/iit/semantic-web.html
Sirma Group, Bulgaria (trabajos: OntoText, OWLIM, PROTON ontology, WSMO Studio, etc.), www.sirma.com
MINDSWAP Group, Universidad de Maryland, EU (trabajos: Pellet, OWL-s API, SemPortal, etc.), www.mindswap.org
Centro de investigaciones de tecnologías de la información, Alemania (trabajos: KAON, KAON2, etc.). http://www.fzi.de/index.php/en
Universidad de Manchester, UK (trabajos: REWERSE, PEDRo, OntoGrid, DinamO, etc.) www.manchester.ac.uk
Competidores más cercanos
F. Paganelli et al (Proyecto Kamer, [Paganelli06]),
Carsten Keßler et. al. ([Carsten09]).
Capítulo 4. Análisis y Diseño En este capítulo se presentan los diagramas de caso de uso y la definición de los escenarios
que corresponden a la fase de análisis. También se presentan los diagramas de secuencia
correspondientes a la etapa del diseño y por último se detalla el diagrama físico de la base de
datos.
Capítulo IV. Análisis y diseño
33
4.1 Análisis
El análisis describe la arquitectura de la API de consulta desarrollada. Se presentan los
diagramas de caso de uso, la definición de escenarios y los diagramas de secuencia que
corresponden al proyecto.
4.1.1 Arquitectura
La arquitectura presentada en la figura 4.1 muestra los módulos de la API y la forma en
que interactúan.
Figura 4.1. Arquitectura de la API
La arquitectura del sistema se compone de tres secciones las cuales inician desde que el
cliente envía la solicitud en conjunto con el identificador y la ubicación del usuario. Estás
secciones son:
Realizar consultas: En este módulo se tienen que realizar dos tipos de consultas, por
lo que se divide en dos secciones:
Consulta de hospedajes: Consiste en obtener la lista de hospedajes que se
encuentran en el rango de distancia (dada en kilómetros) cercana al usuario.
Para realizar esto se requiere que el DBMS tenga soporte completo de bases de
datos espaciales, con la finalidad de ejecutar consultas que incluyen
información geo-referenciada y se pueda cumplir con otro de los requisitos de
la consulta que es el ordenamiento de resultados conforme a la cercanía de los
hospedajes con respecto al usuario.
Consulta de perfil: Esta consulta tiene la finalidad de obtener la información
del usuario. Es decir, con un identificador de usuario (ID_usuario) se realiza
Capítulo IV. Análisis y diseño
34
una consulta en el DBMS para obtener los datos personales del usuario y su
perfil.
Poblar ontología: Este módulo tiene la responsabilidad de cargar a la ontología los
resultados obtenidos en el módulo anterior:
Cargar hospedajes: Este sub-módulo debe recibir la información de los
hospedajes cercanos al usuario y por cada registro obtenido de la base de datos,
se deberá crear un individuo en la ontología para su posterior procesamiento.
Cargar perfil: Este sub-módulo tiene que considerar la información obtenida de
la base de datos y deberá crear un individuo de la clase persona en la ontología
para su posterior procesamiento.
Procesar reglas: Este módulo tiene la responsabilidad de entregar los resultados
finales al usuario, por lo que se compone de un sub-módulo:
Selección y ejecución: Se dedica a buscar las reglas semánticas SWRL que
incluyan de manera parcial o completa las preferencias del usuario respecto a
los hospedajes. Esto es, seleccionar las reglas que permitan inferir cuales son
los hospedajes que empaten con el perfil del usuario. En cuanto se tienen las
reglas seleccionadas, se procede a ejecutarlas con lo que se descartan los
hospedajes que no coincidan con el perfil.
A continuación se presentan los diagramas de caso de uso, la definición de escenarios y
los diagramas de secuencia que corresponden a la fase de análisis de la API.
En la Figura 4.2 se muestra el diagrama general de casos de uso de la API, se muestran
las funciones principales que ofrece. Dado que se trata de una API se consideró como actor y
usuario de la API al cliente (aplicación externa) que invoca las funciones de la API. El
Sistema Manejador de Base de Datos (DBMS) se consideró en el diagrama de casos de uso
como un actor externo que también interactúa con la API.
Capítulo IV. Análisis y diseño
35
Figura 4.2. Diagrama de Casos de Uso
En la figura 4.3 se muestra el diagrama de secuencia que define la interacción que existe
en el caso de uso 1.1 (CU1.1 Alta usuario) y en la tabla 4.1 se detalla el escenario del mismo
caso de uso.
uc 0_API
API de consultas
Cliente
CU1.1 Alta usuario
CU2_Consulta
Hospedajes
CU3_Cambios
usuario
CU4_Baja usuario
CU2.1 Consulta por
zona
CU5_Consulta
información de
usuario
CU1.2 Alta
hospedajesCU1_Altas
DBMS
CU2.2
Recomendación
contextual
Capítulo IV. Análisis y diseño
36
Figura 4.3. Diagrama de secuencia – Alta usuario.
Tabla 4.1. CU1.1 Alta usuario.
Nombre del caso de uso:
CU1.1 Alta usuario
Actores: Cliente, DBMS
Descripción: Permite que el cliente registre la información de un usuario en la base de datos de la API.
Precondiciones: *El usuario no debe estar registrado en la base de datos de la API.
Escenario de éxito:
1. El cliente invoca la función de la API alta usuario y envía los parámetros correspondientes a la información del usuario.
2. Se verifica que no exista ningún registro con el mismo ID de usuario en el DBMS.
3. Se crea un nuevo registro de usuario en el DMS con la información del usuario (un ID de usuario, datos personales y perfil).
4. El proceso termina exitosamente.
Escenario de fracaso 1:
Falta alguno de los parámetros o se envían valores fuera de rango.
Escenario de fracaso 2:
Ya existe un registro de usuario con el mismo ID de usuario enviado.
Salida: Mensaje de confirmación de registro o mensaje de error.
Pos condiciones:
Capítulo IV. Análisis y diseño
37
En la figura 4.4 se muestra el diagrama de secuencias que define la interacción que
existe en el caso de uso 1.2 (CU1.1 Alta hospedajes) y en la tabla 4.2 se detalla el escenario
del mismo caso de uso.
Figura 4.4. Diagrama de secuencia – Alta hospedaje.
Tabla 4.2. CU1.2 Alta hospedaje.
Nombre del caso de uso:
CU1.1 Alta hospedaje
Actores: Cliente, DBMS
Descripción: Permite que el cliente registre la información de un hospedaje en la base de datos de la API.
Precondiciones: *El hospedaje no debe estar registrado en la base de datos de la API.
Escenario de éxito:
1. El cliente invoca la función de la API alta usuario y envía los parámetros correspondientes a la información del usuario.
2. Se verifica que no exista ningún registro con el mismo nombre de hospedaje en la misma ciudad y en el mismo estado en el DBMS.
3. Se crea un nuevo registro de usuario en el DMS con la información del hospedaje (datos generales del hospedaje y sus características).
4. El proceso termina exitosamente.
Escenario de fracaso 1:
Falta alguno de los parámetros o se envían valores fuera de rango.
Capítulo IV. Análisis y diseño
38
Escenario de fracaso 2:
Ya existe un registro con los datos del hospedaje enviado.
Salida: Mensaje de confirmación de registro o mensaje de error.
Pos condiciones:
En la figura 4.5 se muestra el diagrama de secuencias que define la interacción que
existe en el caso de uso 2.1 (CU2.1 Consulta por zona) y en la tabla 4.3 se detalla el escenario
del mismo caso de uso.
Figura 4.5. Diagrama de secuencia – Consulta por zona.
Tabla 4.3. CU2.1 Consulta por zona.
Nombre del caso de uso:
CU1.1 Consulta por zona
Actores: Cliente, DBMS
Descripción: Realiza una consulta de los hospedajes que se encuentren en un rango de distancia a partir de un punto geo-referenciado.
Precondiciones: Se debe enviar las coordenadas geográficas (longitud y latitud) de la zona.
Escenario de éxito:
1. El cliente invoca la función de la API consulta por zona y envía los parámetros correspondientes.
2. La función genera y envía la petición de consulta al DBMS. 3. El DBMS regresa los registros de hospedajes que coincidan con la
consulta recibida. 4. La función regresa una lista de la clase hospedajes con la
información obtenida desde el DBMS. 5. El proceso termina exitosamente.
Capítulo IV. Análisis y diseño
39
Escenario de fracaso 1:
Falta alguno de los parámetros o se envían valores fuera de rango.
Escenario de fracaso 2:
No existen registros de hospedajes en la zona indicada.
Salida: Mensaje de confirmación de registro o mensaje de error.
Pos condiciones:
En la figura 4.6 se muestra el diagrama de secuencias que define la interacción que
existe en el caso de uso 2.2 (CU2.2 Recomendación contextual) y en la tabla 4.4 se detalla el
escenario del mismo caso de uso.
Capítulo IV. Análisis y diseño
40
Figura 4.6. Diagrama de secuencia – Recomendación contextual.
Capítulo IV. Análisis y diseño
41
Tabla 4.4. CU2.2 Recomendación contextual.
Nombre del caso de uso:
CU2.2 Recomendación contextual
Actores: Cliente, DBMS
Descripción: Realiza una consulta contextual de los hospedajes considerando los que se apeguen al perfil del usuario.
Precondiciones: Se debe enviar las coordenadas geográficas (longitud y latitud) de la zona y el ID del usuario.
Escenario de éxito:
1. El cliente invoca la función de la API recomendación contextual y envía los parámetros correspondientes.
2. Se crea un modelo ontológico a partir de una ontología OWL predeterminada.
3. La función genera y envía la petición de consulta al DBMS para recuperar los hospedajes cercanos a la ubicación indicada y la información del usuario.
4. El DBMS regresa los registros de hospedajes que coincidan con la consulta recibida.
5. Se crea sobre el modelo ontológico un individuo de la clase hospedaje por cada registro de hospedaje retornado así como un único individuo de la clase persona con la información del usuario obtenida del DBMS.
6. Se recuperan las reglas en formato SWRL desde un archivo con formato XML desde un archivo predeterminado y se agregan al modelo.
7. Se invoca la API de la máquina de inferencias y se le envía el modelo con las reglas válidas.
8. La máquina de inferencias retorna los hospedajes que cumplieron las reglas.
9. La función regresa una lista de la clase hospedajes con la información obtenida desde la máquina de inferencias.
10. El proceso termina exitosamente.
Escenario de fracaso 1:
Falta alguno de los parámetros o se envían valores fuera de rango.
Escenario de fracaso 2:
No existen registros de hospedajes en la zona indicada.
Escenario de fracaso 3:
No se puede leer la ontología base o el archivo con las reglas SWRL.
Salida: Mensaje de confirmación de registro o mensaje de error.
Pos condiciones:
En la figura 4.7 se muestra el diagrama de secuencias que define la interacción que
existe en el caso de uso 3 (CU3 Cambios usuario) y en la tabla 4.5 se detalla el escenario del
mismo caso de uso.
Capítulo IV. Análisis y diseño
42
Figura 4.7. Diagrama de secuencia – Cambios usuario.
Tabla 4.5. CU3 Cambios usuario.
Nombre del caso de uso:
CU3Cambios usuario
Actores: Cliente, DBMS
Descripción: Permite que la información del usuario sea modificada.
Precondiciones: Debe existir un registro en el DBMS con el ID de usuario enviado.
Escenario de éxito:
1. El cliente invoca la función de la API cambios usuario y envía los parámetros correspondientes.
2. La función genera y envía la petición de actualización del registro de usuario al DBMS.
3. El DBMS notifica el estado de la actualización. 4. El proceso termina exitosamente.
Escenario de fracaso 1:
Falta alguno de los parámetros o se envían valores fuera de rango.
Escenario de fracaso 2:
No existe el registro del usuario.
Salida: Mensaje de confirmación de actualización o mensaje de error.
Pos condiciones:
Capítulo IV. Análisis y diseño
43
En la figura 4.8 se muestra el diagrama de secuencias que define la interacción que
existe en el caso de uso 4 (CU4 Baja usuario) y en la tabla 4.6 se detalla el escenario del
mismo caso de uso.
Figura 4.8. Diagrama de secuencia – Baja usuario.
Tabla 4.6. CU4 Baja usuario.
Nombre del caso de uso:
CU4Baja usuario
Actores: Cliente, DBMS
Descripción: Permite eliminar el registro de un usuario.
Precondiciones: Debe existir un registro en el DBMS con el ID de usuario enviado.
Escenario de éxito:
1. El cliente invoca la función de la API baja usuario y envía el parámetro correspondiente.
2. La función genera y envía la petición de eliminación del registro de usuario al DBMS.
3. El DBMS notifica el estado de la actualización. 4. El proceso termina exitosamente.
Escenario de fracaso 1:
No se envía el ID de usuario o se envía un valor fuera de rango.
Escenario de fracaso 2:
No existe el registro del usuario.
Salida: Mensaje de confirmación de actualización o mensaje de error.
Pos condiciones:
Capítulo IV. Análisis y diseño
44
En la figura 4.9 se muestra el diagrama de secuencias que define la interacción que
existe en el caso de uso 5 (CU5 Consulta datos de usuario) y en la tabla 4.7 se detalla el
escenario del mismo caso de uso.
Figura 4.9. Diagrama de secuencia – Consulta información de usuario.
Tabla 4.7. CU5 Consulta información de usuario.
Nombre del caso de uso:
CU5Consulta información de usuario
Actores: Cliente, DBMS
Descripción: Permite consultar la información del registro de un usuario.
Precondiciones: Debe existir un registro en el DBMS con el ID de usuario enviado.
Escenario de éxito:
1. El cliente invoca la función de la API consultar información de usuario y envía el parámetro correspondiente.
2. La función genera y envía la petición de consulta del registro de usuario al DBMS.
3. El DBMS regresa la información del usuario solicitado. 4. Se genera un objeto persona y se retorna al cliente. 5. El proceso termina exitosamente.
Escenario de fracaso 1:
No se envía el ID de usuario o se envía un valor fuera de rango.
Escenario de fracaso 2:
No existe el registro del usuario.
Salida: Mensaje de confirmación de actualización o mensaje de error.
Pos condiciones:
Capítulo IV. Análisis y diseño
45
4.2 Diseño
La API consta de cuatro paquetes desarrollados en lenguaje Java y se muestran en la
figura 4.10:
Figura 4.10. Diagrama general de Paquetes.
conexiones, para manejar la interacción con la base de datos PostgreSQL.
estructuras, que mantiene las estructuras de las clases de hospedaje y
usuario.
inferencia, que lleva el control del modelo ontológico y las inferencias.
conHotel, que permite la interacción con un cliente separando vista-
controlador.
Capítulo IV. Análisis y diseño
46
4.2.1 Paquete conexiones
Este paquete contiene únicamente a la clase conectaBD, (figura 4.11) la cual tiene la
finalidad de servir de intermediario a un cliente y al DBMS de PostgreSQL para llevar a cabo
las inserciones, actualizaciones, eliminación y consulta de registros de la información de
usuario o de los hospedajes.
Figura 4.11. Paquete conexiones.
4.2.2 Paquete estructuras
En la figura 4.12 se muestra el diagrama de clases del paquete estructuras, el cual denota
tres clases que sirven para definir los atributos de los objetos hospedaje, usuario y
lugarUsuario.
A continuación se describen de manera general las clases que componen a este paquete,
las cuales tienen los métodos set y get para cada uno de sus atributos:
hospedaje: Contiene todos los atributos que reflejan las características posibles
de un hospedaje. Todos los campos son idénticos a los que se almacenan en la
base de datos.
usuario: Encapsula los atributos que representan la información personal del
usuario, así como su perfil y preferencias.
lugarUsuario: Permite que se pueda extraer información georeferenciada de un
catálogo de lugares asociados a un usuario.
class Clases
conexiones::conectaBD
+ id_usuario: int
+ nombre: String
~ resConsulta: int = 0
~ url: String = "jdbc:postgresq...
+ actualizarUsuario() : int
+ bajaUsuario() : int
+ consultarHospedajeCompleto() : ArrayList
+ consultarHospedajeKM() : ArrayList
+ consultarLugaresUsuario() : ArrayList
+ consultarPreferenciaHospedaje() : ArrayList
+ consultarUsuario() : int
+ consultarUsuarioCompleto() : usuario
+ eliminarLugaresUsuario() : void
+ insertarHospedajes() : int
+ insertarLugar() : int
+ insertarPreferenciaHospedaje() : int
+ insertarUsuario() : int
Capítulo IV. Análisis y diseño
47
Figura 4.12. Paquete estructuras.
class Clases
estructuras::hospedaje
~ acceso_aeropuerto: boolean
~ acceso_autobuses: boolean
~ acceso_centro_comercial: boolean
~ acceso_playa: boolean
~ acceso_trenes: boolean
~ acepta_mascotas: boolean
~ acepta_tarjeta: boolean
~ agencia_viajes: boolean
~ albercas: boolean
~ alimentos_habitacion: boolean
~ all_inclusive: boolean
~ area_fumar: boolean
~ bar: boolean
~ business_center: boolean
~ canchas: boolean
~ check_in_out_e: boolean
~ ciudad: String
~ cocina: boolean
~ desayuno_incluido: boolean
~ direccion: String
~ disco: boolean
~ elevadores: boolean
~ estacionamiento: boolean
~ estado: String
~ estrellas: int
~ extension_tel: boolean
~ frigobar: boolean
~ gimnasio: boolean
~ guarderia: boolean
~ id: int
~ internet: boolean
~ juegos_infantiles: boolean
~ latitud: double
~ lavanderia: boolean
~ limpieza_habitacion: boolean
~ longitud: double
~ lounge: boolean
~ nombre: String
~ pais: String
~ playa_privada: boolean
~ radio_taxis: boolean
~ rampas_minusvalias: boolean
~ restaurante: boolean
~ sala_juntas: boolean
~ salon_conferencias: boolean
~ salon_eventos: boolean
~ spa: boolean
~ teleferico: boolean
~ telefono: String
~ television: boolean
~ tiendas: boolean
~ tipohospedaje: int
~ tipotarifa: int
~ transporte_aeropuerto: boolean
~ url: String
~ valet_parking: boolean
estructuras::lugarUsuario
~ id_lugar: int
~ latitud: double
~ longitud: double
~ nombre_lugar: String
estructuras::usuario
~ acuaticas: boolean
~ adultosmayores: boolean
~ anio_nac: int
~ apell ido: String
~ contexto: int
~ deportes: boolean
~ fumador: boolean
~ id_usuario: int
~ mascotas: boolean
~ minusvalia: boolean
~ ninios: boolean
~ nombre: String
~ otrosfumadores: boolean
~ otrosminusvalias: boolean
~ pagoamerican: boolean
~ pagocheques: boolean
~ pagoefectivo: boolean
~ pagomaster: boolean
~ pagovisa: boolean
~ presupuesto: int
~ reqCajafuerte: boolean
~ reqInternet: boolean
~ reqLavanderia: boolean
~ reqTelefono: boolean
~ reqTelevision: boolean
~ sexo: char
~ tiendas: boolean
~ transporte: int
Capítulo IV. Análisis y diseño
48
4.2.3 Paquete inferencia
El paquete inferencia contiene una única clase llamada modeloOwl, la cual permite que
se pueda llevar a cabo las recomendaciones contextuales mediante la creación de un modelo
ontológico con el método crearModeloOwl() y poder así ejecutar reglas SWRL que
realicen las inferencias sobre los hospedajes a recomendar mediante el método
inferirModeloOWL(). En la figura 4.13 se pueden observar sus métodos.
Figura 4.13. Paquete inferencia.
4.2.4 Paquete conHotel
El paquete conHotel contiene clases que fueron desarrolladas específicamente para dar
soporte a páginas Web desarrollado bajo el esquema de tres capas realizado con el Framework
Java Server Faces. En la figura 4.14 se puede observar las clases que están incluidas en este
paquete.
consultaInferida: Está clase corresponde a la página que realiza la
recomendación contextual de hospedajes. Invoca a la clase conectaBD para
recuperar la información del usuario y los hospedajes cercanos y a su vez envía
esta información a los métodos de la clase modeloOwl para realizar la inferencia
de recomendación.
bienvenido: Contiene llamadas a los métodos de conexión al DBMS y recupera la
información de los hospedajes cercanos.
registroUsuario: Permite extraer la información de los datos personales del
usuario desde el formulario y enviarlo al DBMS para su almacenamiento y
redireccionar al formulario agregarUbicacion.
agregaUbicacion: Permite obtener coordenadas georeferenciadas del usuario y
agregarlo a un catálogo de ubicaciones durante la etapa en que un usuario se está
registrando en la aplicación y redirigirlo al formulario preferenciaHospedaje.
class Clases
inferencia::modeloOwl
+ crearModeloOwl() : void
- extraeContextoViaje() : String
- extraeTipoHospedaje() : String
- extraeTipoTarifa() : String
+ inferirModeloOWL() : void
- modeloOWL_A_Archivo() : void
Capítulo IV. Análisis y diseño
49
agregaUbicacionExtra: Permite obtener coordenadas georeferenciadas del
usuario y agregarlo a un catálogo de ubicaciones después de que el usuario ya
completó su registro.
preferenciaHospedaje: Permite extraer la información de las preferencias del
usuario respecto a los hospedajes desde el formulario y enviarlo al DBMS para
su almacenamiento y redireccionar al formulario index.
index: Ofrece la extracción del nombre de usuario y contraseña para consultarlo
en el DBMS y permitir al usuario el acceso a la aplicación.
datosNoGuardados: Ofrece redireccionamiento a la página de inicio después de
que envía a la interfaz un mensaje personalizado de algún error al intentar
insertar información al DBMS.
error: Permite redirigir a la página index después de haber desplegado algún
error generado en algún otro formulario de la aplicación.
RequestBean1: Clase generada por el Framework para almacenar variables de
ámbito local que se pasan de parámetro a la misma página al ser actualizada.
SessionBean1: Clase generada por el Framework para almacenar variables de
ámbito de sesión del usuario que se pasan de parámetro entre todas las páginas a
las se acceden.
ApplicationBean1: Clase generada por el Framework para almacenar variables de
ámbito de la aplicación que son accesibles para todas las páginas accedidas por
cualquier usuario.
Figura 4.14. Paquete conHotel.
class conhotel
AbstractPageBean
agregaUbicacion
AbstractPageBean
agregaUbicacionExtra
AbstractApplicationBean
ApplicationBean1
AbstractPageBean
bienv enido
AbstractPageBean
consultaInferida
AbstractPageBean
datosNoGuardados
AbstractPageBean
error
AbstractPageBean
index
AbstractPageBean
preferenciaHospedaje
AbstractPageBean
registroUsuario
AbstractRequestBean
RequestBean1
AbstractSessionBean
SessionBean1
Capítulo IV. Análisis y diseño
50
4.2.5 Diseño del modelo de la base de datos
La aplicación contará con una base de datos la cual almacenará información de los
hospedajes, los usuarios, las preferencias y las ubicaciones del usuario. La figura 4.15 muestra
el modelo de la base de datos.
La base de datos fue diseñada considerando los requerimientos geográficos de la
información, por lo que para realizar operaciones con dicha información se implementó en un
manejador de base de datos que de soporte a estas características. La creación de los campos
con información geográfica es distinta a la creación de campos con tipos de datos
tradicionales, al igual que las consultas hacia estos campos.
La base de datos perfiles cuenta con 4 tablas que permiten almacenar la información de
los usuarios, la ubicación actual de estos y los detalles de los hospedajes:
hospedajes: Almacena la información detallada de los hospedajes, como nombre,
dirección, ubicación geográfica y sus características.
usuarios: Almacena los datos personales del usuario como nombre, edad, etc.
preferenciaHotel: Almacena las preferencias de los usuarios respecto a los hospedajes.
lugaresUsuario: Permite mantener un catálogo de los lugares geográficos (mediante
longitud y latitud) más comunes para el usuario que le permita realizar las consultas a partir de
alguna de sus ubicaciones.
Capítulo IV. Análisis y diseño
51
Figura 4.15. Relación de tablas de la base de datos.
Capítulo 5. Implementación En este capítulo se presentan los detalles tecnológicos de la propuesta. Se describe la
implementación de los módulos que son resultado de la tesis, así como también elementos
desarrollados para completar la funcionalidad como la ontología y las reglas SWRL.
Capítulo V. Implementación
53
5.1 Detalles tecnológicos LA API para la consulta de hospedajes fue realizada utilizando diversas tecnologías de
software libre que incluyen manejadores de base de datos, la API de Jess como máquina de
inferencias y un Framework de Java para la creación del código fuente también en Java. El
esquema de interacción de estas tecnologías se muestra en la figura 5.1.
Figura 5.1. Interacción de las tecnologías en la API.
Las tecnologías empleadas que muestra la figura 5.1 son descritas a continuación.
PostgreSQL es el manejador de base de datos (DBMS) que da soporte a la base
de datos con capacidades de datos de tipo geográfico mediante la extensión
llamada PostGIS.
Java es el lenguaje de programación con el que se realiza el aplicativo que
controla las llamadas al DBMS, procesa la información y genera el modelo
ontológico.
La API de Protégé permite la creación y manipulación de ontologías dentro del
segmento de Java.
Jess es la máquina de reglas para java el cual realiza las inferencias determinadas
por un modelo ontológico con reglas en lenguaje SWRL.
Adicional a las tecnologías que se usan directamente en la API, también se hizo uso de
librerías y otras APIs para la creación del código fuente, de la ontología y las reglas SWRL
como se describe a continuación.
Protégé como editor de ontologías en formato OWL.
SWRLTab como extensión (plugin) de Protégé para la generación y la validación
automática del formato de las reglas SWRL.
NetBeans como IDE (Entorno de Desarrollo Integrado) para el desarrollo y
pruebas del código fuente.
Java J2SE Development Kit como motor de desarrollo y compilación de código
Java.
Capítulo V. Implementación
54
La descripción de la implementación de la API se divide en tres módulos, los cuales
están la figura de la arquitectura de la API. Estos módulos están apoyados por una ontología y
un archivo de tipo XML que contiene las reglas y así poder realizar la recomendación
contextual.
5.2 Ontología. La ontología es una base de conocimientos de un dominio específico y en este trabajo
corresponde al dominio de hospedajes. Para la realización del proyecto de tesis se requiere
contar con una ontología del dominio mencionado, por lo que se realizó una búsqueda de la
ontología en distintos portales y catálogos de ontologías en la Web, sin embargo, no se logró
encontrar una ontología que modelara por completo el dominio de los hospedajes.
La ontología es requerida para poder llevar a cabo el proceso de recomendaciones
contextuales por lo cual se determinó desarrollar una ontología para satisfacer esta necesidad.
Por lo anterior, la validación y comprobación de dicha ontología quedan fuera del objetivo de
esta tesis. A continuación se describe la ontología desarrollada.
La ontología tiene el dominio de hospedajes y es parte del proceso de recomendaciones
contextuales, por lo que se requirió analizar sitios de listados de hoteles y sitios de los mismos
hoteles para extraer los términos importantes en la información que ofrecen a sus visitantes.
Existen herramientas en línea conocidos como estimadores de tráfico que analizan la
dirección de un dominio el cual sea introducido y devuelven estadísticas y cálculos de cuantos
visitantes reciben diario o por mes los dominios introducidos. Ejemplos de estas herramientas
son los sitios trafficestimate.com, statbrain.com y alexa.com.
Este último fue utilizado para determinar la importancia de algunos de los sitios que
mantienen listas de hoteles como por ejemplo bestday.com el cual dicha herramienta calcula
en 79,000 visitas en el último trimestre del 2010 [AlexaBD11] y el sitio zonaturistica.com en
90,000 visitas en el mismo período [AlexaZT11]. Con base a lo anterior, estos dos sitios
fueron elegidos para extraer las características que se deben considerar de los hoteles e
incluirlos en la ontología.
El desarrollo de la ontología se realizó siguiendo la metodología recomendada por la
universidad de Stanford en [Noy05]. En la figura 5.2 se muestra el grafo de las clases y
subclases de la ontología resultante.
Capítulo V. Implementación
55
Figura 5.2. Taxonomía de la ontología.
5.2.1 Súper clases.
La ontología resultante se compone de 5 clases principales o también llamadas súper
clases que son las que definen los tópicos principales y de estas clases se derivan subclases. En
la figura 5.3 se puede observar las súper clases y sus relaciones.
Figura 5.3. Súper clases de la ontología.
Capítulo V. Implementación
56
En la tabla 5.1 se describen las súper clases y el número de propiedades y relaciones que
tienen.
Tabla 5.1. Súper clases de la ontología.
Nombre Subclases Propiedades Se relaciona con Descripción
Hospedaje 0 8 Infraestructura
Características_
Habitación
Servicios
Describe mediante sus
propiedades y la relación
que tiene con otras clases
los distintos tipos de
hospedajes.
Infraestructura 26 0 ----- Permite definir a través
de subclases las
instalaciones con las que
cuenta un hospedaje.
Caracteristicas_
Habitacion
13 0 ----- Describe mediante
subclases las
características que
pueden ofrecer las
habitaciones de los
hospedajes.
Servicios 14 0 ----- Permite definir a través
de subclases los servicios
que puede llegar a ofrecer
un hospedaje.
Persona 0 25 Hospedaje Describe mediante sus
propiedades el perfil del
usuario.
5.2.2 Subclases y propiedades.
Las subclases permiten crear individuos de las características que ofrecen hospedajes y
crear las relaciones dentro en la instancia de la ontología. En la tabla 5.2 se mencionan las
subclases que contienen y en la tabla 5.3 las propiedades de las clases Hospedaje y Persona.
Capítulo V. Implementación
57
Tabla 5.2. Subclases de la ontología.
Súper Clase Subclases
Infraestructura Acceso_CentroComercial, Acceso_Playa,
Acceso_TerminalAeropuerto, Acceso_TerminalAutobuses,
Acceso_TerminalTrenes, Albercas, Area_fumar, Bar,
Business_Center, Canchas_deportivas, Disco, Elevador,
Estacionamiento, Gimnasio, Juegos_Infantiles, Lounge,
Playa_privada, Rampas_Minusvalias, Restaurante, Sala_Juntas,
Salon_Conferencias, Salon_Eventos, Sauna, Spa, Teleferico, Tiendas
Caracteristicas_
Habitacion
AceptaMascotas, Alberca, Articulos_Varios, Banios, Cocina,
Extension_Telefonica, Frigobar, Internet, Jacuzzi, Kit_de_Banio,
Television, Ventilacion, Vista_Panoramica
Servicios Acepta_tarjeta, Agencia_viajes, Alimentos_a_la_habitacion,
All_inclusive, Check_in_out_express, Guarda_Valores, Guarderia,
Lavanderia, Limpieza_Habitacion, Radio_taxis, Sastre,
Transportacion_aeropuerto, Valet_Parking.
Tabla 5.3. Propiedades de datos de las súper clases.
Súper Clase Propiedades de datos (dataproperties)
Hospedaje clasificacionEstrellas, descripcion, direccion, id_hospedaje, nombre,
telefono, tipoHospedaje, tipoTarifa.
Persona acompaniaAdultosMayores, acompaniaMascotas, acompaniaNinios,
acompaniaOtrosFumadores, acompaniaOtrosFumadores,
acompaniaOtrosMinusvalias, anio_nac, apellido, contextoViaje,
fumador, gustaTiendas, haceActAcuaticas, haceEjercicio, minusvalía,
nombre,
pagoamerican,pagocheques,pagoefectivo,pagomaster,pagovisapresup
uesto,reqInternet, reqTelefono, reqTVsexo,viajaTransporte.
Durante la ejecución de una recomendación contextual, el modelo de la ontología es
cargado en la memoria de la aplicación. Conforme a la arquitectura de la aplicación, los
individuos de la ontología son creados de acuerdo a la información del usuario y a los
hospedajes cercanos a la ubicación del usuario. Esta información es recuperada del DBMS. El
proceso de la creación de los individuos también es conocido como instanciación de la
ontología.
Capítulo V. Implementación
58
5.3 Reglas SWRL. Como se menciona en el apartado 2.4.1 de este documento, las reglas SWRL tienen la
finalidad de inferir nuevo conocimiento a partir de un conocimiento existente en una
ontología. Las reglas escritas para este proyecto, tienen el propósito de tomar el conjunto de
clase, propiedades, relaciones e individuos contenidos en el modelo ontológico e inferir los
hospedajes que se le pueden recomendar a un usuario.
Las reglas que fueron creadas se basan en considerar los atributos de los usuarios
(propiedades del individuo Persona) y buscar en la clase hospedajes los individuos que tengan
propiedades que puedan ser del interés del usuario.
Aunque en la API se encuentra el archivo que contiene las reglas y estas pueden ser
modificadas a las necesidades de cada aplicación, en el presente trabajo se consideró las reglas
que se muestran en el resto de este apartado del documento.
Una de las principales propiedades del usuario consideradas para la creación de reglas es
el contexto de viaje (contextoViaje), el cual llevará a que se ejecuten ciertas reglas
dependiendo el valor de dicho contexto. En la tabla 5.4 se muestran las reglas ligadas a esta
propiedad.
Tabla 5.4. Reglas a ejecutar según la propiedad contextoViaje.
Contexto de
viaje
Nombres de la reglas Descripción
Amigos Amigos_AgenciaViajes, Amigos_Bar,
Amigos_Disco, Amigos_Frigobar,
Amigos_Lounge, Amigos_Restaurante,
Amigos_Teleferico,
Amigos_TodoIncluido.
En este contexto se buscarán los
hospedajes que cuenten con
agencia de viajes, bar, disco,
frigo bar, lounge, restaurante,
teleférico y el servicio all
inclusive (todo incluido).
Familiar Familiar_AgenciaViajes,
Familiar_AlimentosAlCuarto,
Familiar_Cocina,
Familiar_DesayunoIncluido,
Familiar_Frigobar,
Familiar_Restaurante, Familiar_Spa,
Familiar_Teleferico, Familiar_TV.
En este contexto serían
recomendable los hospedajes que
ofrezcan agencia de viajes,
servicio de alimentos a la
habitación, cocina, desayuno
incluido, frigo bar, restaurante,
Spa, teleférico y televisión.
Capítulo V. Implementación
59
Grupo
Turístico
GpoTuristico_AgenciaViajes,
GpoTuristico_Bar,
GpoTuristico_DesayunoIncluido,
GpoTuristico_Disco,
GpoTuristico_Frigobar,
GpoTuristico_Lavanderia,
GpoTuristico_Lounge,
GpoTuristico_Restaurante,
GpoTuristico_Spa,
GpoTuristico_Teleferico,
GpoTuristico_TodoIncluido.
En el contexto de los grupos
turísticos son recomendables los
hospedajes que cuenten con
agencia de viajes, bar, desayuno
incluido, disco, frigo bar,
servicio de lavandería, lounge,
restaurante, Spa, teleférico y el
servicio all inclusive (todo
incluido).
Individual Individual_AgenciaViajes,
Individual_AlimentosAlCuarto,
Individual_Bar,
Individual_DesayunoIncluido,
Individual_Disco, Individual_Frigobar,
Individual_Jacuzzi,
Individual_Lavanderia,
Individual_Lounge,
Individual_Restaurante,
Individual_Teleferico,
Individual_TodoIncluido,
Individual_TV.
En el contexto individual o que el
usuario no viaja acompañado son
recomendables los hospedajes
con agencia de viajes, servicio de
alimentos a la habitación, bar,
desayuno incluido, disco, frigo
bar, jacuzzi, servicio de
lavandería, lounge, restaurante,
teleférico, el servicio all
inclusive (todo incluido) y
televisión.
Pareja Pareja_AgenciaViajes, Pareja_Bar,
Pareja_Cocina,
Pareja_DesayunoIncluido,
Pareja_Disco, Pareja_Frigobar,
Pareja_Jacuzzi, Pareja_Lavanderia,
Pareja_Lounge, Pareja_Restaurante,
Pareja_Sauna, Pareja_Spa,
Pareja_TodoIncluido, Pareja_TV.
En este contexto son
recomendables los hospedajes
que cuenten con agencia de
viajes, bar, desayuno incluido,
disco, frigo bar, jacuzzi, servicio
de lavandería, lounge,
restaurante, sauna, Spa,
teleférico, el servicio all
inclusive (todo incluido) y
televisión.
Trabajo Trabajo_BusinessCenter,
Trabajo_CheckInOutExp,
Trabajo_DesayunoIncluido,
Trabajo_Jacuzzi, Trabajo_Lavanderia,
Trabajo_Restaurante,
Trabajo_SalaJuntas,
Trabajo_SalonConferencias
En el contexto de los usuario que
viajan por trabajo son
recomendables los hospedajes
con centro de negocios (Business
Center), proceso rápido de
registro y salida (check in/out
express), desayuno incluido,
jacuzzi, servicio de lavandería,
lounge, restaurante, sala de juntas
y salón de conferencias.
Capítulo V. Implementación
60
En la tabla 5.5 se mencionan las reglas correspondientes a las propiedades del usuario
que son de tipo booleano, es decir, se ejecutarán estas reglas sí el usuario cuenta con la
propiedad a evaluar. También se contemplan dos propiedades no booleanas.
Tabla 5.5. Reglas a ejecutar con otras propiedades.
Propiedad Nombres de la reglas Descripción
acompaniaMascotas Aceptan_Mascotas. Si el usuario viaja acompañado
de una mascota se recomendará
un hospedaje que acepte
mascotas.
haceActAcuaticas Acuaticas_AccesoPlaya,
Acuaticas_Albercas,
Acuaticas_PlayaPrivada.
Si el perfil del usuario indica que
realiza actividades acuáticas se
recomendarán los hospedajes con
acceso a una playa, que tengan
albercas o que cuenten con playa
privada.
haceEjercicio Deportes_Canchas,
Deportes_Gimnasio.
Si el perfil del usuario indica que
realiza ejercicio se recomendarán
los hospedajes con canchas
deportivas o gimnasio.
fumador Fuma. Si el perfil del usuario indica que
es fumador se recomendarán los
hospedajes con área para fumar.
minusvalia Minusvalia_Elevadores,
Minusvalia_Rampas.
Si el perfil del usuario indica que
es tiene alguna minusvalía se
recomendarán los hospedajes con
elevadores o rampas para
minusválidos.
acompaniaNinios Ninios_Guarderia,
Ninios_JuegosInfantiles.
Si el usuario viaja acompañado
con niños se recomendarán los
hospedajes que tengan servicio
de guardería o juegos infantiles.
Capítulo V. Implementación
61
presupuesto Presupuesto_Alto,
Presupuesto_Bajo,
Presupuesto_Medio.
El tipo de presupuesto indicado
en el perfil es comparado contra
la propiedad tipoTarifa de los
hospedajes para recomendar los
que coincidan (bajo, medio o
alto).
gustaTiendas Tiendas_AccesoCentroComer-
cial, Tiendas2.
Si el perfil del usuario indica que
le gustan las tiendas se
recomendarán los hospedajes con
tiendas propias o accesos a un
centro comercial.
viajaTransporte ViajaAuto_Estacionamiento,
ViajaAuto_ValetParking,
ViajaAutobus_Terminal,
ViajaAvion_Terminal,
ViajaAvion_Transportacion,
ViajaTren, ViajaX_RadioTaxis
El tipo de transporte en el que
viaje el usuario sirve para
determinar si se recomiendan
hospedajes con estacionamiento
o valet parking si viaja en
automóvil; buscar hospedajes
con acceso a la terminal de
autobuses en caso de que este sea
el medio de transporte y
finalmente buscar hospedajes con
acceso a la terminal aérea o
servicio de transportación al
aeropuerto en caso de que viaje
por avión. Para cualquier medio
de transporte distinto de
automóvil se recomendarán
hospedajes con servicio de radio
taxis.
5.4 Ejecución de las reglas Cuando el aplicativo ha consultado al DBMS y obtenido la información del usuario y de
los hospedajes, el siguiente paso es generar un modelo ontológico y llevar a cabo la
instanciación de dicho modelo. Con el modelo creado, se deben leer las reglas y cargarlas en el
mismo modelo y hacer un llamado a la máquina de inferencias para que ejecute estas reglas y
pueda generar nuevo conocimiento a partir del conocimiento existente.
En el trabajo actual se utiliza el motor de inferencias de Jess, el cual es compatible con
Java y es invocado desde su API. El motor valida el modelo ontológico con las reglas, es
decir, a cada regla que esta por ser ejecutada verifica que existan las clases, propiedades y
relaciones a las cuales hace mención dicha regla.
Capítulo V. Implementación
62
Si alguna regla contiene condiciones contradictorias (ejemplo ficticio: que una regla
intente evaluar que el usuario sea fumador y al mismo tiempo que no sea fumador), la regla no
satisface a ambas condiciones provocando que no se ejecute el consecuente de la regla. Por lo
anterior, las reglas que no satisfacen todas las condiciones (incluyendo alguna regla
contradictoria) no generan ningún resultado y no afecta de manera alguna al resto de las reglas
ni tampoco impide que el motor de inferencias siga ejecutándose normalmente.
Todas las reglas planteadas en este trabajo tienen como consecuente el consultar el
identificador del hospedaje (ID). Con lo anterior, el aplicativo genera internamente una la lista
de los identificadores que son arrojados por las reglas ejecutadas, lo cual permite que se dé
una puntuación a los hospedajes que más reglas hayan acertado y dando prioridad a las de
mayor puntuación. Cuando la lista de hospedajes está terminada, es devuelta al cliente de la
API como resultado del proceso de la recomendación contextual.
Capítulo 6. Pruebas funcionales En este capítulo se presentan los resultados de las pruebas llevadas a cabo sobre la
funcionalidad de la API.
Capítulo VI. Pruebas funcionales
64
La siguiente lista define las características probadas:
Ingreso de información a la Base de Datos. Define los casos de pruebas para la
creación de registros en la base de datos que a su vez servirá para la posterior
instanciación (población) de la ontología.
Consultas geolocalizables. Define los casos de pruebas para la recuperación de
información asociada con puntos geolocalizables y la compatibilidad del estándar
utilizado en la base de datos con sistemas como el de mapas de Google.
Instanciación de la Ontología. Define los casos de pruebas para creación de los
individuos de las clases de hospedajes y persona en la ontología con respecto a la
información contenida en la base de datos.
Ejecución de reglas contextuales. Define los casos de pruebas para la ejecución de las
reglas contextuales en lenguaje SWRL para la las inferencias que se realizan con la
base de conocimientos de la ontología.
A continuación se describen los resultados de las pruebas.
6.1 Pruebas de ingreso de información a la Base de Datos
Tabla 6.1. Caso de prueba SurfeousHospedajes-01-A.
CASO DE PRUEBA: SurfeousHospedajes-01-A Ingreso del perfil de usuario.
DESCRIPCIÓN:Permitir a un usuario ingresar su perfil a la base de datos mediante una
interfaz web. La prueba se realizó mediante una interfaz web utilizando el servidor de
páginas web Tomcat. A través de la página de registro de nuevo usuario se puede dar de alta
en el sistema y al mismo tiempo se registrará el perfil en un archivo “.foaf” que contendrá
una estructura RDF con el perfil indicado.
Resultados: OK
Capítulo VI. Pruebas funcionales
65
Proceso de registro de usuario: 1) Ingresa los datos de su nombre de usuario. 2)
Selecciona su ubicación en el mapa. 3) Ingresa su perfil personal. 4) Ingresa su contexto.
El archivo wolverine.foaf se genera y contiene el perfil indicado en la página Web:
Proceso de
registro de usuario
1 2
3 4
Capítulo VI. Pruebas funcionales
66
Características del perfil de usuario: Es el perfil que el usuario registra en la página Web.
El sistema genera un registro en la tabla de usuarios en la base de datos para garantizar el
acceso:
Observaciones:
El archivo .foaf fue creado exitosamente con el perfil indicado en la página Web. Y la base
de datos contiene un registro de usuario para garantizar el acceso al sistema.
Responsable de la prueba: César Villatoro Hdez. Cargo: Autor
Características del
perfil de usuario
Capítulo VI. Pruebas funcionales
67
Tabla 6.2. Caso de prueba SurfeousHospedajes-01-B.
CASO DE PRUEBA: SurfeousHospedajes-01-B Ingreso de hospedajes a la base de
datos
DESCRIPCIÓN: Permitir el registro de la información de un hospedaje hacia la base de
datos. La prueba se realizó mediante una interfaz web utilizando el servidor de páginas web
Tomcat. A través de la página de registro de nuevo hospedaje en el sistema.
Resultados: OK
Registro de un
hospedaje
1 2
Capítulo VI. Pruebas funcionales
68
Registro de un hospedaje: 1) Datos generales del hospedaje. 2) Información de la
infraestructura que ofrece. 3) Servicios ofrecidos. 4) Características de la habitación.
Registro de un
hospedaje
3 4
Capítulo VI. Pruebas funcionales
69
La base de datos contiene el perfil del hospedaje indicado en la página Web:
Observaciones:
Se creó un registro en la tabla hospedajes que a su vez contiene 57 campos correspondientes
a las características del hospedaje ingresadas en la página Web.
Responsable de la prueba: César Villatoro Hdez. Cargo: Autor
6.2 Pruebas de Consultas geolocalizables.
Tabla 6.3. Caso de prueba SurfeousHospedajes-02-A.
CASO DE PRUEBA: SurfeousHospedajes-02-A Consultas geolocalizables de
hospedajes cercanas al usuario.
DESCRIPCIÓN: Permitir recuperar información de los hospedajes en la base de datos. Se
extraen la ubicación del usuario (longitud y latitud) desde la tabla usuario en la base de
datos que contiene su registro. En la base de datos se realiza una consulta geo-referenciada
y se retornan los hospedajes encontrados en un rango de 8 kilómetros de la ubicación del
usuario. Los resultados de muestran en una página Web que implementa mapas de Google.
Resultados: OK
Capítulo VI. Pruebas funcionales
70
Recuperación de hospedajes cercanos: 1) Se realiza internamente en el sistema una
consulta con las coordenadas geográficas del usuario para buscar los hospedajes a una
distancia menor a 8 km. 2) Se recuperan los resultados obtenidos por el motor de la base de
datos.
Se despliega en el mapa dentro de la página los resultados de los hospedajes.
Recuperación de
hospedajes cercanos
2
1
Capítulo VI. Pruebas funcionales
71
Capítulo VI. Pruebas funcionales
72
Observaciones:
Se presentan en el mapa todos los hospedajes encontrados en el rango de 8 km de distancia
del usuario. Se realizó el despliegue de los detalles del hospedaje seleccionado en la página
Web.
Responsable de la prueba: César Villatoro Hdez. Cargo: Autor
Tabla 6.4. Caso de prueba SurfeousHospedajes-02-B.
CASO DE PRUEBA: SurfeousHospedajes-02-B Consultas geolocalizables de
hospedajes por zona especificada.
DESCRIPCIÓN: Permitir recuperar información de los hospedajes en la base de datos. El
usuario elige un punto en un mapa lo cual es traducido a coordenadas geográficas (longitud
y latitud) y se consultan los hospedajes en la base de dato considerando la distancia máxima
especificada en la página Web. Los resultados de muestran en una página Web que
implementa mapas de Google.
Resultados: OK
Recuperación de hospedajes por zona: 1) Se delimita la zona a buscar mediante el rango
de kilómetros. 2) Se elige el centro de la zona en la que se desea realizar la búsqueda.
Se genera internamente la consulta hacia la base de datos:
Recuperación de
hospedajes por zona
2
1
Capítulo VI. Pruebas funcionales
73
Recuperación de resultados en la BD: 1) Se introducen las coordenadas del lugar que el
usuario seleccionó en el mapa. 2) Se introduce la cantidad de kilómetros en donde se
realizará la búsqueda. 3) El motor de base de datos recupera los resultados.
Se despliegan los resultados de los hospedajes en el mapa y la información detallada de los
hospedajes:
Recuperación de
resultados en la BD.
3
2 1
Capítulo VI. Pruebas funcionales
74
Observaciones:
Se presentan en el mapa todos los hospedajes encontrados en el rango de la distancia
seleccionada (5 km en el ejemplo). Se realizó el despliegue de los detalles del hospedaje
seleccionado en la página Web.
Responsable de la prueba: César Villatoro Hdez. Cargo: Autor
6.3 Pruebas de instanciación de la Ontología
Tabla 6.5. Caso de prueba SurfeousHospedajes-03-A.
CASO DE PRUEBA: SurfeousHospedajes-03-A Instanciación de la ontología
DESCRIPCIÓN: Crea una instancia de la ontología base “OntoPhyr” con un individuo de
la clase “Persona” determinado por el usuario y los individuos de la clase “Hospedajes” con
los individuos de los hospedajes cercanos encontrados en la base de datos. La instancia de
la ontología creada servirá para la “Recomendación contextual”.
Capítulo VI. Pruebas funcionales
75
Resultados: OK
Carga del modelo base “OntoPhyr.owl”: 1) Cuando se inicia el proceso de
“recomendación contextual” se crea en el sistema un modelo OWL que contiene las clases,
relaciones y atributos de la ontología base OntoPhyr.owl 2) El modelo es creado
exitosamente.
Se crean las clases, propiedades y relaciones de la clase “hospedaje” así como sus
individuos:
Mensaje al completarse clases e individuos de “Hospedajes”: 1) Se crean las subclases
que definen a la clase principal “Hospedaje”, así como las relaciones entre las subclases y
se definen los atributos de cada clase. 2) Los individuos son creados a partir de los
resultados obtenidos de la base de datos con los hospedajes cercanos al usuario.
Carga del modelo
base “OntoPhyr.owl”
2
1
Mensaje al completarse
clases e individuos de
“Hospedajes”
1
2
Capítulo VI. Pruebas funcionales
76
Mensaje al completarse clases e individuos de “Persona”: 1) Se crean las subclases que
definen a la clase principal “Persona”, así como las relaciones entre las subclases y se
definen los atributos de cada clase. El individuo es creado a partir del perfil de usuario
obtenido del archivo .foaf del usuario. 2) El modelo OWL creado en el sistema es
almacenado en un archivo físico con la ontología resultante, incluyendo todas las clases,
relaciones y atributos mencionados en esta prueba.
Se comprueba la creación correcta de la ontología con los individuos en el archivo
generado:
Individuos de “Hospedaje” y “Persona”: 1) Se crean los 13 individuos (para este
ejemplo) de los hospedajes cercanos al usuario; varios de estos serán descartados en la fase
de inferencias. 2) Se crea el individuo “wolverine” (para este ejemplo) que corresponde al
usuario del sistema.
Se puede probar que el individuo se creó correctamente abriendo la ontología en un editor
Mensajes al completarse
clases e individuos de
“Persona”
1
2
Individuos de
“Hospedaje” y “Persona”
creados exitosamente.
2
1
Capítulo VI. Pruebas funcionales
77
de ontologías como Protégé:
Individuo “wolverine” en la ontología: 1) Se creó el individuo “wolverine” con el perfil
contenido en el archivo .foaf del usuario.
Se puede probar que los individuos de los hospedajes se crearon correctamente abriendo la
ontología en un editor de ontologías como Protégé (ejemplo con “hotel Cádiz”):
Individuo “wolverine”
en la ontología
1
Capítulo VI. Pruebas funcionales
78
Individuo “Cádiz” en la ontología: 1) Se creó el individuo “Cádiz” con los detalles de su
infraestructura, servicios y características de habitación tal como está almacenado en la
ontología.
Observaciones:
Los individuos fueron creados siguiendo la estructura de la ontología base OntoPhyr. Los
individuos se pueden comprobar abriendo el archivo “test.owl” en Protégé.
Responsable de la prueba: César Villatoro Hdez. Cargo: Autor
6.4 Pruebas de ejecución de reglas contextuales.
Tabla 6.6. Caso de prueba SurfeousHospedajes-04-A.
CASO DE PRUEBA: SurfeousHospedajes-04-A Ejecución de reglas
DESCRIPCIÓN: Utilizar el modelo OWL creado e instanciado en el sistema a partir de
OntoPhyr.owl para ejecutar reglas SWRL para inferir los Hospedajes con características
similares al perfil del usuario.
Resultados: OK
Al continuar con el proceso de “Recomendación Contextual” se carga en el sistema el
archivo “reglashospedajes.rdf” el cual contiene un documento de tipo XML que contiene las
reglas definidas para el modelo OWL generado en el sistema:
Individuo “Cádiz” en la
ontología
Capítulo VI. Pruebas funcionales
79
Vista parcial de las reglas SWRL en formato XML: Las reglas fueron diseñadas y
probadas en Protégé y fueron migradas al archivo “reglashospedajes.rdf” el cual contiene las
reglas disponibles para el modelo OWL generado por el sistema.
Mensajes de carga y ejecución de reglas: 1) El sistema lee las reglas y verifica que tengan
la estructura correcta de “antecedente” y “consecuente”. 2) Las reglas se añaden al modelo
OWL del sistema y se ejecutan las que hacen referencia a las clases y atributos que
coinciden con las características del usuario y del hospedaje. El resultado es el conjunto de
los “ID‟s” de los hospedajes ordenados por mayor número de reglas ejecutadas.
Se despliegan los resultados ordenados por importancia de las recomendaciones
contextuales:
Vista parcial de las reglas
SWRL en formato XML
Mensajes de carga y
ejecución de reglas
1
2
Capítulo VI. Pruebas funcionales
80
Características buscadas
para el perfil de usuario
Capítulo VI. Pruebas funcionales
81
Características buscadas para el perfil de usuario: Verdes: Características directas del
perfil de usuario y que si son ofrecidas por el hospedaje. Rojos: Características buscadas y
que el hospedaje no ofrece. Azul: Características buscadas para el “ambiente=amigos” del
perfil de usuario las cuales pueden variar si el “ambiente” es distinto.
Las características del hospedaje recomendado en primer lugar de la lista de
recomendaciones son similares con las necesidades descritas en el perfil del usuario. En este
ejemplo, la característica de ambiente = “amigos” denota que las reglas busquen 8
características en hospedajes (marcadas en azul en el ejemplo anterior):
Características del perfil de usuario: Es el perfil del individuo que se crea en la ontología
y que en base a estos atributos hace que solo se ejecuten las reglas que contienen estas
características y que en este ejemplo coincide en mayoría con el primer hospedaje
recomendado.
Como ejemplo la propiedad “medioTransporte=propio” produce la ejecución de dos reglas:
Características del
perfil de usuario
Capítulo VI. Pruebas funcionales
82
Reglas con el atributo medioTransporte=propio: 1) verde: buscando a un usuario “X” y su atributo “viajaTransporte=automóvil”. Azul:
buscando un estacionamiento “Z” y que esté relacionado con “tieneInfraestructura” de un
hospedaje.
2) verde: buscando a un usuario “X” y su atributo “viajaTransporte=automóvil”. Azul:
buscando un servicio de Valet Parking “Z” y que esté relacionado con “tieneInfraestructura”
de un hospedaje.
Observaciones:
La lista de hospedajes recomendados tiene como primer elemento al hospedaje que tiene
mayor cantidad de características que pueden ser compatibles con el perfil del usuario.
Responsable de la prueba: César Villatoro Hdez. Cargo: Autor
<regla nombre="ViajaAuto_Estacionamiento">
<antecedente>Persona(?x) ^ Hospedaje(?y) ^ id_hospedaje(?y,?id) ^ Estacionamiento(?z) ^
viajaTransporte(?x, "automovil") ^ tieneInfraestructura(?y, ?z)</antecedente>
<consecuente>sqwrl:selectDistinct(?id)</consecuente>
<tipo>2</tipo>
</regla>
<regla nombre="ViajaAuto_ValetParking">
<antecedente>Persona(?x) ^ Hospedaje(?y) ^ id_hospedaje(?y,?id) ^ Valet_Parking(?z) ^
viajaTransporte(?x, "automovil") ^ ofreceServicios(?y, ?z)</antecedente>
<consecuente>sqwrl:selectDistinct(?id)</consecuente>
<tipo>2</tipo>
</regla>
1 Reglas con el atributo
medioTransporte=propio
1
2 2
Capítulo 7. Conclusiones En este capítulo se presentan las conclusiones del desarrollo del presente trabajo, las
aportaciones y los trabajos futuros.
Capítulo VII. Conclusiones
84
7.1 Conclusiones El presente trabajo hizo posible la creación de una API que permite realizar aplicaciones
basadas en localización con recomendación contextual sobre el dominio de hospedajes y
ofreciendo como ventaja el uso de tecnologías de la Web Semántica.
Con la investigación realizada sobre desarrollo para la Web Semántica, que es la parte
medular de este proyecto, se comprobó que es factible el desarrollo de aplicaciones basadas en
ontologías y reglas SWRL. El uso de las reglas de inferencia para la Web Semántica permite
extender el razonamiento lógico de la ontología que representa un dominio específico.
Las recomendaciones contextuales con herramientas de la Web Semántica puede ser
reutilizado en distintos dominios, sin embargo, este trabajo adoptó el dominio de los
hospedajes para probar el enfoque de la recomendación.
Se logró la implementación de la API basada en otros proyectos de software libre como
por NetBeans, Java J2SE Development Kit, Postgres y APIs libres como la de Jess y Jena
entre otras. Además los clientes pueden llegar a implementar la API de GoogleMaps para la
visualización de resultados sobre mapas.
Con el presente trabajo se logró obtener conocimiento acerca de los sistemas de
información geográfica, servicios basados en localización y la implementación de otras APIs.
Durante el desarrollo de las etapas del presente proyecto se observa que existen diversos
trabajos relacionados con la Web Semántica alrededor de todo el mundo, sin embargo, en
México es un área en la que se está progresando lentamente y los primeros trabajos de gran
impacto aún están madurando. Lo anterior abre muchas oportunidades de investigación sobre
este tema.
En el desarrollo de las pruebas se observó que la implementación en los clientes puede
ser complicada cuando no está separada la capa de interfaz gráfica con la funcionalidad de la
API, por lo que el enfoque de separar estas capas permite que se pueda reutilizar el código
organizado en clases a múltiples clientes.
7.2 Aportaciones Los resultados obtenidos en este trabajo de tesis tiene las siguientes aportaciones:
El desarrollo de una API con clases y funciones que permiten la recomendación de
hospedajes considerando la ubicación del usuario y su perfil.
Métodos para la manipulación de la información del usuario y de los hospedajes sobre
una base de datos relacional con soporte de la información geo-referenciada.
La generación de una ontología de dominio que modelas las características y servicios
que ofrecen los hospedajes.
Capítulo VII. Conclusiones
85
Un conjunto de reglas de inferencia que sirve como parte crucial del mecanismo de
recomendación contextual
Estas aportaciones se basan en la obtención del perfil del usuario y los hospedajes; la
instanciación de la ontología y en la ejecución de reglas que determinan la recomendación
contextual.
7.3 Trabajos futuros Del presente trabajo de tesis, se pueden desprender otros trabajos y mejoras a la API:
Incrementar las características del perfil del usuario en la ontología para poder usar
esta ontología en trabajos con otros dominios.
Realizar un proyecto que recolecte la información de los hospedajes desde sitios de
listados de hoteles disponibles en la Web.
Establecer un módulo simplificado de creación/modificación de las reglas para
usuarios sin conocimiento del lenguaje de reglas SWRL.
Establecer el manejo de sesiones desde la API y no desde el cliente.
Establecer atributos muy específicos de las subclases en la ontología para perfeccionar
la ontología y sea reutilizada en una mayor cantidad de trabajos.
Referencias
86
Referencias [AlexaBD11] Alexa, the Web information company, “bestday.com”, 2011, recuperado de
http://www.alexa.com/siteinfo/bestday.com en Enero del 2011.
[AlexaZT11] Alexa, the Web information company, “zonaturistica.com”, 2011, recuperado
de http://www.alexa.com/siteinfo/zonaturistica.com en Enero del 2011.
[Ballesteros09] Ballesteros E. A., “Lenguaje SPARQL”, 2008, recuperado de
www.geocities.com/recuperacioninformacionorganiza/sparql.html en Enero
del 2009.
[Cardoso09] J. Cardoso, M. D. Lytras “Semantic Web engineering in the knowledge
society”, 2009.IGI Global, ISBN 978-1-60566-113-1, IRM Press.
[Carsten09] Carsten Keßler, M. Raubal, C. Wosniok, “Semantic Rules for Context-Aware
Geographical Information Retrieval”, ed.: European Conference on Smart
Sensing and Context, EuroSSC 2009. Volumen 5741 of LNCS., Springer
(2009) 77-92.
[CNT10] Confederación Nacional Turística, “Síntesis informativa del 14 de diciembre
de 2010”, 2010. Recuperado de http://www.confederacion.org.mx/revista-
detalle.asp?IDArticulo=399&IDGrupo=4el 15 de diciembre de 2010.
[Gerardo08] Gerardo de M. G., “Curso UIMP Servicios Basados en Localización”, 2008.
Recuperado de http://yerart.wordpress.com/2008/06/30/curso-uimp-servicios-
basados-en-localizacion-lbs/ el 26 de marzo de 2009.
[González07] J. M. González, J. A. Lozano (1), J. E. López, V. A. Villagrá, “Self-adapted
Service Offering for Residential Environments”, 2007. 1st IEEE Workshop on
Autonomic Communications and Network Management (ACNM'07), Munich,
Alemania.
[Hervás06] Hervás R., W. Nava S., Chavira G, Bravo J.,“Modelado de Contexto: Una
Ontología Adaptativa al Usuario en Ambientes Inteligentes”, 2006. 2nd
International Workshop on Ubiquitous Computing & Ambient Intelligence
(WUCAmI‟06), Puertollano, C. Real (España).
[Kostas07] Kostas Kolomvatsos, V. Papataxiarhis, V. Tsetsos “Semantic Location Based
Services for smart spaces”, 2007 Springer, en Proc. of the 2nd International
Conference on Metadata and Semantics Research (MTSR), Corfu, Grecia.
[Noy05] Natalya F. Noy, “Desarrollo de Ontologías-101: Guía Para Crear Tu
Primera Ontología” 2005. Recuperado de
http://protege.stanford.edu/publications/ontology_development/ontology101-
es.pdf en enero 2010.
[Paganelli06] F. Paganelli, G. Bianchi, V. Melani, “A Context-Aware e-Tourism Application
Enabling Collaboration and Knowledge Exchange among Tourists”,
eChallenges 2006, 25 - 27 October 2006, Barcelona, España.
Referencias
87
[Plas06] Plas, D.J., Verheijen, M., Zwaal, H., Hutschemaekers, M., “Manipulating
context information with SWRL”. I/RS/2005/117, Freeband/A-MUSE/D3.12,
2006.
[Ponce] I. R. Ponce Medellín, “Búsquedas Contextuales de Servicios Basados en
Localización en un entorno de Web Social”, tesis de doctorado en desarrollo,
CENIDET, México.
[Quiñones08] P. Quiñones, “Gateway SMS/MMS Pull para servicios basados en
localización con una Arquitectura de Servicios Web”. Tesis de maestría,
CENIDET, México, 2008.
[Ricqueb07] Vincent Ricquebourg, David Durand, David Menga, Bruno Marhic, aurent
Delahoche, Christophe Logé, Anne-Marie Jolly-Desodt, “Context inferring in
the Smart Home: An SWRL approach”. IEEE, UCI07 - May 2007 Cataratas
del Niágara, Canadá.
[Rincón08] C. Victoria Rincón, “API para la gestión de mapas de navegación en
dispositivos móviles mediante el GPS y mensajería SMS/MMS”, 2008. Tesis
de maestría, CENIDET, México.
[Rojas09] C. Rojas Roldán, “Modelado de perfiles de usuarios para servicios basados en
localización”, 2009.Tesis de maestría, CENIDET, México, por publicarse.
[Ruiz07] L. Ruíz Guerra, “APISMS para el procesamiento de consultas
georeferenciadas/no georeferenciadas”. Tesis de maestría, CENIDET,
México, 2007.
[Sanna08] G. Sanna, G. Vacca., “Indoor positioning in the located based services”
2008.En 21º congreso: International Society for Photogrammetry and Remote
Sensing, P. 931, Beijing China, 2008.
[SecTurOVT 10] Secretaría de Turismo, “Orientación vocacional turística”,
2010.Recuperado de
www.sectur.gob.mx/wb/sectur/sect_9076_orientacion_vocacion el 15 de
diciembre de 2010.
[SecTur10] Secretaría de Turismo, “Boletín 159: Se fortalecerá en 2011 la segmentación
de mercados para lo promoción de México en el extranjero”, 2010. Boletín
informativo. Recuperado de www.sectur.gob.mx/es/sectur/Boletin_159el 15
de diciembre de 2010.
[Unicarlos08] Alumnos de la Universidad Carlos III de Madrid, “Lenguaje de recuperación
en RDF”, 2008. Recuperado de
http://lenguajesrecuperacionweb.xm.com/sparql.htmlel 24 de enero del 2009.
[Vassilis09] Vassilis Papataxiarhis, Vassileios Tsetsos, Isambo Karali, Panagiotis
Stamatopoulos, Stathes Hadjiefthymiades, “i-footman- A Knowledge-based
Framework for Football Managers”. Proceedings of the 3rd
East European
Workshop on Rule-Based Applications (RuleApps2009) Cottbus, Germany,
September 21, 2009.
Referencias
88
[W3C_ES08] W3C, “El W3C expone los datos en la Web con SPARQL”, 2008.Nota de
prensa del World Wide Web Consortium, oficina española.Recuperado de
www.w3c.es/Prensa/2008/nota080115_sparqlel 11 de Junio de 2009.
[W3C_WS08] W3C, “Guía Breve de Web Semántica”, 2008, Recuperado de
www.w3c.es/Divulgacion/Guiasbreves/WebSemantica el 26 de enero del
2009.
[Yu05] S. Yu, L. Al-Jadir, S. Spaccapietra, "Matching user's semantics with data
semantics in Location-Based Services", 2005. SME'05, 9 de mayo de 2005.
Ayia Napa, Chipre. ACM 1-58113-000-0/00/0004.
[Zhan08] W. Zhan, K. Marius Hansen, “Towards Self-managed Pervasive Middleware
using OWL/SWRL ontologies”, 2008. Fifth International Workshop on
Modelling and Reasoning in Context. Países bajos (The Netherlands).