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.4. Caso de prueba SurfeousHospedajes-02-B. .......................................................................... 72



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


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.


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.


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.


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.


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.


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.


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.

http://www.tomtom.com/


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


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


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


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.


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.


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)


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


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


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


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


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


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


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


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


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.


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.


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.


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

http://www.nrc-cnrc.gc.ca/eng/facilities/iit/semantic-web.html

http://www.nrc-cnrc.gc.ca/eng/facilities/iit/semantic-web.html

http://www.sirma.com/

http://www.mindswap.org/

http://www.fzi.de/index.php/en

http://www.manchester.ac.uk/

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


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.


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


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.


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:


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.


CU1.1 Alta hospedaje


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.


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





38


Ya existe un registro con los datos del hospedaje enviado.


Pos condiciones:


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.


CU1.1 Consulta por zona


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.


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.


39




No existen registros de hospedajes en la zona indicada.


Pos condiciones:


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.


40

Figura 4.6. Diagrama de secuencia – Recomendación contextual.


41

Tabla 4.4. CU2.2 Recomendación contextual.


CU2.2 Recomendación contextual


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.


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.





No existen registros de hospedajes en la zona indicada.


No se puede leer la ontología base o el archivo con las reglas SWRL.


Pos condiciones:


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.


42

Figura 4.7. Diagrama de secuencia – Cambios usuario.

Tabla 4.5. CU3 Cambios usuario.


CU3Cambios usuario


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.


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.




No existe el registro del usuario.

Salida: Mensaje de confirmación de actualización o mensaje de error.

Pos condiciones:


43


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.


CU4Baja usuario


Descripción: Permite eliminar el registro de un usuario.



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.


No se envía el ID de usuario o se envía un valor fuera de rango.




Pos condiciones:


44


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.


CU5Consulta información de usuario


Descripción: Permite consultar la información del registro de un usuario.



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.


No se envía el ID de usuario o se envía un valor fuera de rango.




Pos condiciones:


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.


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


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


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


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


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.


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.


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.


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.


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.


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.


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.


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


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


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.


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.


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.


es tiene alguna minusvalía se


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.


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.


le gustan las tiendas se


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.


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


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


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


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


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


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.


6.2 Pruebas de Consultas geolocalizables.


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


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


71


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.


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


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


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.


6.3 Pruebas de instanciación de la Ontologí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”.


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


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


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


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


6.4 Pruebas de ejecución de reglas contextuales.


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


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


80

Características buscadas

para el perfil de usuario


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


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.


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

http://www.alexa.com/siteinfo/bestday.com

http://www.alexa.com/siteinfo/zonaturistica.com

http://www.geocities.com/recuperacioninformacionorganiza/sparql.html

http://www.confederacion.org.mx/revista-detalle.asp?IDArticulo=399&IDGrupo=4

http://www.confederacion.org.mx/revista-detalle.asp?IDArticulo=399&IDGrupo=4

http://yerart.wordpress.com/2008/06/30/curso-uimp-servicios-basados-en-localizacion-lbs/

http://yerart.wordpress.com/2008/06/30/curso-uimp-servicios-basados-en-localizacion-lbs/

http://protege.stanford.edu/publications/ontology_development/ontology101-es.pdf

http://protege.stanford.edu/publications/ontology_development/ontology101-es.pdf

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.

http://www.sectur.gob.mx/wb/sectur/sect_9076_orientacion_vocacion

http://www.sectur.gob.mx/es/sectur/Boletin_159

http://lenguajesrecuperacionweb.xm.com/sparql.html



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

http://www.w3c.es/Prensa/2008/nota080115_sparql

http://www.w3c.es/Divulgacion/Guiasbreves/WebSemantica

TESIS DE MAESTRÍA EN CIENCIAS - cenidet.edu.mx Cesar... · o respuestas a consultas específicas,...

Documents

Transcript of TESIS DE MAESTRÍA EN CIENCIAS - cenidet.edu.mx Cesar... · o respuestas a consultas específicas,...