Generación y Explotación de Mapas Semánticos de Instalaciones Organizacionales mediante el uso de Ontologías

Centro Nacional de Investigación y Desarrollo Tecnológico
Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Generación y Explotación de Mapas Semánticos de Instalaciones
Organizacionales mediante el uso de Ontologías

presentada por

Ricardo Estrada Peláez
Ing. En Sistemas Computacionales por el Instituto Tecnológico de Veracruz

como requisito para la obtención del grado de:
Maestría en Ciencias en Ciencias de la Computación

Director de tesis:
Dra. Azucena Montes Rendón

Co-director de Tesis:
Dr. Juan Gabriel González Serna

Jurado:
Dr. Máximo López Sánchez – Presidente
Dr. Hugo Estrada Esquivel – Secretario
M.C. Humberto Hernández García – Vocal
Dr. Juan Gabriel González Serna– Vocal Suplente

Cuernavaca, Morelos, México. 28 de febrero de 2012

Dedicatoria

A mi hijo por nacer:
Te estamos esperando con los brazos abiertos.

Agradecimientos

Quiero agradecer a mis padres María de los Ángeles Peláez Conde y José de Jesús Estrada
Aguilar† por haberme dado vida, y en especial a mi madre por todo el apoyo que me ha
brindado hasta la fecha.

A mi novia Lourdes Vázquez Coronado por estar conmigo todo este tiempo y soportar la
distancia.

Al CONACYT por el apoyo económico aportado por su sistema de becas, sin el cual
probablemente no hubiera realizado la maestría.

A la Dra. Azucena Montes Rendón y el Dr. Juan Gabriel González Serna por su orientación en
esta tesis, así como por sus clases de ontologías y redes respectivamente, que facilitaron de
buen modo el desarrollo de este trabajo.

A mis revisores el Dr. Hugo Estrada Esquivel, el Dr. Máximo López Sánchez y el M.C.
Humberto Hernández García por sus observaciones e interés por hacer de este el mejor trabajo
posible.

A mis amigos y compañeros de maestría que gracias a su compañía hacían menos pesados los
días, en especial a Felipe A. Román, Everardo Munguía y Nazir O. Molina.

Resumen

Los Servicios Basados en Localización (LBS por sus siglas en inglés) dan al usuario final un
conjunto de servicios empezando por su ubicación geográfica. Estos servicios le ofrecen la
posibilidad a los usuarios o máquinas de encontrar o localizar a otra persona, dispositivo,
vehículo, recurso o servicio sensibles a la ubicación, así como la posibilidad de rastrear su
propia ubicación.

El presente trabajo se enfoca en el subsistema de visualización, en donde surge la necesidad de
realizar, mapas auto descriptibles de las instalaciones de organizaciones, es decir, edificios,
plantas, habitaciones, pasillos, accesos, etc. pertenecientes a una organización, logrando con
esto mapas en los cuales sus elementos contengan información de su composición o
caracterización.

En este trabajo de tesis se propone un conjunto de herramientas de software que darán las
bases para mejorar el subsistema de visualización de un sistema de recomendación contextual,
permitiendo realizar una secuencia de tareas relacionadas a la generación y explotación de
mapas semánticos.

Abstract

Location-based services provide end users with a set of services starting by its geographical
location. This services offer to users or machines the possibility to find or locate another
person, device, vehicle, resource or service sensible to the location, as well as the possibility to
track their own position.

This work is focused in the visualization subsystem, where the need to create self-describing
maps of organization‟s facilities arise, that is; buildings, floors, rooms, corridors, access, etc.
belonging to the organization, achieving with this, maps where its elements contain
information about their composition or characterization.

On this thesis is proposed a set of software tools that will place the foundation to enhance the
visualization subsystem of a contextual recommendation system, by allowing to perform a
sequence of tasks related to the creation and exploitation of semantic maps.

Tabla de contenido.
Tabla de contenido........................................................................................................................i
Listado de códigos. .................................................................................................................... iii
Listado de figuras. ..................................................................................................................... iii
Listado de tablas. ........................................................................................................................vi
Glosario de términos y siglas................................................................................................... viii
Capítulo 1 Introducción. .............................................................................................................. 9
1.1 Introducción. .................................................................................................................... 10
1.2 Antecedentes del proyecto. .............................................................................................. 11
1.3 Descripción del problema. ............................................................................................... 13
1.4 Objetivos.......................................................................................................................... 14
1.4.1 Objetivo general. ...................................................................................................... 14
1.4.2 Objetivos específicos. ............................................................................................... 14
1.5 Justificación y beneficios del proyecto. ........................................................................... 14
1.6 Alcances y limitaciones. .................................................................................................. 16
1.6.1 Alcances. .................................................................................................................. 16
1.6.2 Limitaciones. ............................................................................................................ 16
1.7 Organización del documento. .......................................................................................... 16
Capítulo 2 Marco teórico ........................................................................................................... 18
2. 1 Ontologías....................................................................................................................... 19
2.2 Jena. ................................................................................................................................. 19
2.3 SVG y SVG Tiny. ............................................................................................................ 20
2.4 Android. ........................................................................................................................... 21
2.5 TinyLine SVG. ................................................................................................................ 22
Capítulo 3 Estado del arte .......................................................................................................... 24
3.1 Modelos de representación de espacios. .......................................................................... 25
3.1.1 An ontology for context-aware pervasive computing environments. [Chen 2003] 25
3.1.2 LAIR: Location awareness information representation. [Kottahachchi 2005]......... 27
3.1.3 OntoNav: A semantic indoor navigation system. [Anagnostopoulos 2005] ............ 29
3.1.4 ONALIN: ontology and algorithm for indoor routing. [Dudas 2009] ...................... 31
3.1.5 Semantic Location Modeling for Location Navigation in Mobile Environment. [Hu
2004] .................................................................................................................................. 33
3.2 Técnicas para extender SVG. .......................................................................................... 34

i

3.2.1 Embedding domain semantics. [Chang 2003] .......................................................... 34
3.2.2 Indoor navigation with SVG. [Schmitt 2005] .......................................................... 38
3.2.3 Techniques for binding scalable vector graphics to associated information. [Mor
2007] .................................................................................................................................. 39
3.3 Análisis comparativo. ...................................................................................................... 40
Capítulo 4 Análisis y diseño. ..................................................................................................... 43
4.1 Análisis. ........................................................................................................................... 44
4.1.1 Ontología de infraestructura. ........................................................................................ 45
4.1.2 Herramienta generadora de croquis. ......................................................................... 57
4.1.3 Módulo de edición automática. ................................................................................ 68
4.1.4 Visualizador SVG. .................................................................................................... 74
4.2 Diseño. ............................................................................................................................. 82
4.2.1 Herramienta generadora de croquis .......................................................................... 82
4.2.2 Módulo de edición automática. ................................................................................ 89
4.2.3 Visualizador SVG. .................................................................................................... 91
Capítulo 5 Implementación. ...................................................................................................... 99
5.1 Herramienta para la generación de croquis. .................................................................. 100
5.2 Módulo de edición automática de croquis. .................................................................... 104
5.3 Visualizador SVG. ......................................................................................................... 105
Capítulo 6 Pruebas ................................................................................................................... 110
Capítulo 7 Conclusiones. ......................................................................................................... 131
7.1 Conclusiones.................................................................................................................. 132
7.2 Aportaciones. ................................................................................................................. 133
7.3 Trabajos futuros. ............................................................................................................ 133
Referencias. ............................................................................................................................. 135
Anexos ..................................................................................................................................... 139
Anexo A1. Plan de pruebas – PP01 ..................................................................................... 140
Anexo A2. Formato del archivo de recomendaciones XML ............................................... 157
Anexo A3. Formato del archivo SVG ................................................................................. 158

ii

Listado de códigos.
Código 3.1 Ejemplo de extensión de atributos SVG [Chang 2003] .......................................... 35
Código 3.2 Ejemplo de extensión de modelo de contenido de SVG [Chang 2003].................. 35
Código 3.3 Ejemplo de enlace a datos desde elementos SVG [Chang 2003] ........................... 37
Código 4. Ejemplo de archivo XML de recomendaciones. ..................................................... 157
Código 5. Ejemplo de archivo SVG. ....................................................................................... 159

Listado de figuras.
Figura 1-1 Asociación de ubicaciones a mapa [Arjona 2009] .................................................. 12
Figura 1-2 Comparación de formato vectorial con formato de mapa de bits o raster [IES_EP
2011] .......................................................................................................................................... 13
Figura 1-3 Arquitectura general de la extensión de la plataforma T-Guía ................................ 15
Figura 2-1 Arquitectura general de Android [Android 2011] ................................................... 22
Figura 3-1 Parte central de INO [Anagnostopoulos 2005] ........................................................ 30
Figura 3-2 ONALIN [Dudas 2009] ........................................................................................... 32
Figura 3-3 Ejemplo de jerarquía de ubicaciones y salidas en base a un plano. [Hu 2004] ....... 34
Figura 3-4 Generador de mapas SVG ....................................................................................... 39
Figura 3-5 Representación general del trabajo de la patente [Mor 2007] ................................. 40
Figura 4-1 Esquema de interacción entre los módulos desarrollados. ...................................... 44
Figura 4-2 Diagrama conceptual del enlace de la ontología de infraestructura en la red de
ontologías .................................................................................................................................. 45
Figura 4-3 Casos de uso generales del conjunto de herramientas ............................................. 57
Figura 4-4 Caso de uso 1. Generar croquis ............................................................................... 58
Figura 4-5 Diagrama de actividad del caso de uso 1.1 .............................................................. 59
Figura 4-10 Diagrama de actividad del caso de uso 1.6 ............................................................ 64

iii

Figura 4-14 Diagrama de actividad del caso de uso 1.10 .......................................................... 68
Figura 4-15. Caso de uso 2. Editar croquis automáticamente. .................................................. 69
Figura 4-16. Diagrama de actividad del caso de uso 2.1 ........................................................... 70
Figura 4-20. Caso de uso 3. Visualizar croquis. ........................................................................ 74
Figura 4-28 Diagrama de clases de la Herramienta generadora de croquis .............................. 83
Figura 4-29 Diagrama de secuencia para la carga de croquis ................................................... 84
Figura 4-30 Diagrama de secuencia para la eliminación de croquis ......................................... 85
Figura 4-31 Diagrama de secuencia para la selección de croquis y organización .................... 86
Figura 4-32 Diagrama de secuencia para la asociación de información ................................... 87
Figura 4-33 Diagrama de secuencia para la desasociación de información .............................. 88
Figura 4-34 Diagrama de secuencia para generar croquis ......................................................... 88
Figura 4-35. Diagrama de clases de el módulo de edición automática. .................................... 89
Figura 4-36. Diagrama de secuencia del módulo de edición automática. ................................. 91
Figura 4-37. Diagrama de clases del visualizador de SVG. ...................................................... 93
Figura 4-38. Diagrama de secuencia para la carga del archivo SVG. ....................................... 94
Figura 4-39. Diagrama de secuencia para el zoom in y zoom out............................................. 95
Figura 4-40. Diagrama de secuencia para el panning. ............................................................... 96

iv

Figura 4-41. Diagrama de secuencia para el reset. .................................................................... 97
Figura 4-42. Diagrama de secuencia para el cambio de capa del croquis. ................................ 98
Figura 5-1 Interacción entre las herramientas desarrolladas ................................................... 100
Figura 5-2 Pantalla inicial de la aplicación ............................................................................. 101
Figura 5-3 Pantalla principal de la aplicación web (Parte 1) ................................................... 102
Figura 5-4 Pantalla principal de la aplicación web (Parte 2) ................................................... 103
Figura 5-5 Interfaz gráfica del editor automático de croquis .................................................. 104
Figura 5-6. Pantalla inicial del visualizador. ........................................................................... 105
Figura 5-7. Menú inferior del visualizador. ............................................................................. 106
Figura 5-8. Menú oculto del visualizador................................................................................ 106
Figura 5-9. Carga del croquis en el visualizador. .................................................................... 106
Figura 5-10. Zoom in y zoom out. ........................................................................................... 107
Figura 5-11. Panning. .............................................................................................................. 107
Figura 5-12. Reset. .................................................................................................................. 108
Figura 5-13. Localización ........................................................................................................ 108
Figura 5-14. Cambio de capas ................................................................................................. 109
Figura 6-1 Imágenes del archivo de pruebas por capas ........................................................... 111
Figura 6-2 Croquis de prueba que cumple con los requisitos del caso de prueba HGC-03-01
................................................................................................................................................. 111
Figura 6-3 Carga de croquis en la aplicación .......................................................................... 113
Figura 6-4 Selección de croquis y organización para trabajo .................................................. 113
Figura 6-5 Asociación de información al primer elemento ..................................................... 114
Figura 6-6 Asociación de información al segundo elemento .................................................. 115
Figura 6-7 Asociación de información al tercer elemento ...................................................... 116
Figura 6-8 Verificación de atributo xlink:href en el primer elemento .................................... 117
Figura 6-9 Verificación de atributo xlink:href en el segundo elemento .................................. 117
Figura 6-10 Verificación de atributo xlink:href en el tercer elemento .................................... 118
Figura 6-11 Verificando correspondencia de información para el primer elemento ............... 119
Figura 6-12 Verificando correspondencia de información para el segundo elemento ............ 119
Figura 6-13 Verificando correspondencia de información para el tercer elemento ................ 120

v

Figura 6-14 Desasociación de información a un elemento...................................................... 121
Figura 6-15 Asociación de información a un nuevo elemento ................................................ 122
Figura 6-16 Verificación del atributo xlink:href para el primer elemento después de la
reasociación ............................................................................................................................. 123
Figura 6-17 Verificación del atributo xlink:href para el segundo elemento después de la
reasociación ............................................................................................................................. 123
Figura 6-18 Verificación del atributo xlink:href para el tercer y cuarto elemento después de la
reasociación ............................................................................................................................. 124
Figura 6-19. Información existente depués de desasociar información. ................................. 124
Figura 6-20 Archivo de recomendaciones a utilizar ................................................................ 125
Figura 6-21 Información del croquis antes del proceso automático de depuración ................ 126
Figura 6-22 Ejecución del módulo de edición automática ...................................................... 126
Figura 6-23 Información adicional después del proceso de edición automática ..................... 127
Figura 6-24 Código de animación agregado por el proceso de edición automática ............... 127
Figura 6-25 Capas en la interfaz gráfica del visualizador ....................................................... 129
Figura 6-26 Efecto de animación e información del primer elemento .................................... 129
Figura 6-27 Efecto de animación e información del segundo elemento ................................. 130

Listado de tablas.
Tabla 2-1. Comparativa de APIs o visualizadores SVG para dispositivos móviles .................. 23
Tabla 3-1 Lista completa de clases y propiedades en COBRA-ONT v0.2 [Chen 2003] .......... 26
Tabla 3-2 Análisis comparativo del estado del arte en modelos de representación de espacios
................................................................................................................................................... 41
Tabla 3-3 Análisis comparativo del estado del arte en técnicas para extender SVG ................ 42
Tabla 4-1 Descripción del caso de uso 1.1. Cargar croquis ...................................................... 58
Tabla 4-2 Descripción del caso de uso 1.2. Eliminar croquis ................................................... 59
Tabla 4-3 Descripción del caso de uso 1.3. Seleccionar croquis y organización ...................... 60
Tabla 4-4 Descripción del caso de uso 1.4. Manipular información. ........................................ 61
Tabla 4-5 Descripción del caso de uso 1.5. Generar croquis .................................................... 62

vi

Tabla 4-6 Descripción del caso de uso 1.6. Cargar organizaciones .......................................... 63
Tabla 4-7 Descripción del caso de uso 1.7. Cargar croquis existentes...................................... 64
Tabla 4-8 Descripción del caso de uso 1.8. Asociar información ............................................. 65
Tabla 4-9 Descripción del caso de uso 1.9. Desasociar información ........................................ 66
Tabla 4-10 Descripción del caso de uso 1.10. Cargar información de espacios ....................... 67
Tabla 4-11. Descripción del caso de uso 2.1. Recibir solicitud de datos. ................................. 69
Tabla 4-12. Descripción del caso de uso 2.2. Enviar croquis editado. ...................................... 70
Tabla 4-13. Descripción del caso de uso 2.3. Extraer ID de recomendaciones......................... 71
Tabla 4-14. Descripción del caso de uso 2.4. Editar croquis en base a IDs. ............................. 72
Tabla 4-15. Descripción del caso de uso 3.1. Cargar croquis. .................................................. 75
Tabla 4-16 Descripción del caso de uso 3.2. Interactuar con croquis ....................................... 76
Tabla 4-17. Descripción del caso de uso 3.3. Zoom in. ............................................................ 77
Tabla 4-18. Descripción del caso de uso 3.4. Zoom out. .......................................................... 77
Tabla 4-19. Descripción del caso de uso 3.5. Panning. ............................................................. 78
Tabla 4-20. Descripción del caso de uso 3.6. Reset .................................................................. 79
Tabla 4-21. Descripción del caso de uso 3.7. Cambiar capa ..................................................... 80
Tabla 4-22. Descripción del caso de uso 3.8. Examinar información del croquis .................... 81
Tabla 6-1 Identificadores seleccionados con su información asociada ................................... 117
Tabla 6-2 Información asociada dentro del croquis ................................................................ 118
Tabla 6-3Información restante después del proceso de edición automática ........................... 128

vii

Glosario de términos y siglas.
Mapa semántico En un contexto geográfico, es una representación gráfica que muestra
ubicaciones y contiene información o situación de sus ubicaciones.
Ontología Es una jerarquía de conceptos con atributos y relaciones que describe un
dominio.
QRCodes Es un sistema para almacenar información en una matriz de puntos o un
código de barras bidimensional.
RFID Identificación por Radiofrecuencia (Radio Frequency Identification por
sus siglas en inglés). Es un sistema de almacenamiento y recuperación
de datos que usa dispositivos denominados etiquetas, transpondedores o
tags RFID. El propósito fundamental de la tecnología RFID es transmitir
la identidad de un objeto (similar a un número de serie único) mediante
ondas de radio.
SVG Gráficos Vectoriales Escalables (Scalable Vector Graphics por sus siglas
en inglés). Es un lenguaje para gráficos de dos dimensiones. Es un
estándar gratuito, abierto e independiente de plataforma basado en XML.
SVG Tiny Gráficos Vectoriales Escalables Pequeño (Scalable Vector Graphics
Tiny por sus siglas en inglés). Es un subconjunto de SVG, manejado
como un perfil para uso en dispositivos móviles.
LBS Servicios basados en localización (Location Based Services por sus
siglas en inglés).

viii

Capítulo 1 Introducción

1.1 Introducción.

Los Servicios Basados en Localización (LBS por sus siglas en inglés) dan al usuario final un
conjunto de servicios empezando por su ubicación geográfica. Estos servicios le ofrecen la
posibilidad a los usuarios o máquinas de encontrar/localizar a otra persona, máquina, vehículo,
recurso o servicios sensibles a la ubicación, así como la posibilidad de rastrear su propia
ubicación. La mayoría de los LBS incluyen dos grandes acciones: a) obtener la ubicación del
usuario y b) utilizar esta información para proveer un servicio personalizado [GSM
Association 2003]. Dentro del Departamento de Ciencias Computacionales del Centro
Nacional de Investigación y Desarrollo Tecnológico (CENIDET) se realizan diferentes
trabajos de tesis en las líneas de investigación de: Ingeniería de Software, Inteligencia
Artificial y Sistemas Distribuidos. En los últimos años, el área de Sistemas Distribuidos ha
desarrollado proyectos en LBS‟s. Algunos trabajos desarrollados en esta área son: “Gateway
SMS Pull para servicios basados en localización con arquitectura de servicios Web”
[Quiñonez 2008] y “API SMS para el procesamiento de consultas georeferenciadas y no
georeferenciadas” [Ruiz 2007]. Se hace particular énfasis en la tesis denominada “Servicios de
localización conscientes del contexto aplicando perfiles de movilidad y tecnologías de
localización heterogéneas” [Arjona 2009], donde se hace uso de dispositivos móviles para
proporcionar servicios conscientes del contexto; uno de estos servicios es el guiado en
interiores, que hace uso de mapas creados manualmente en el formato de imagen JPG, sobre
ellos se registran puntos de interés que se almacenan en un sistema gestor de base de datos, del
cual el dispositivo móvil extrae la información.

Este trabajo de tesis es continuación del trabajo “Servicios de localización conscientes del
contexto aplicando perfiles de movilidad y tecnologías de localización heterogéneas” [Arjona
2009], con el desarrollo de un proyecto compuesto de tres módulos: a) un servicio de
localización, b) un servicio de recomendación, y c) un servicio de visualización. En este
trabajo de tesis se modeló e implementó una ontología y prototipos para la creación, poblado
y visualización de mapas interactivos en formato SVG, estos mapas contienen información
que describe funcionalmente las instalaciones de una organización, es decir, edificios
multinivel, habitaciones, pasillos, accesos, recursos disponibles en cada área, personas

10


asociadas a las áreas y actividades asociadas a las áreas funcionales, como resultado se
obtienen mapas SVG auto-descriptibles. Al tener los mapas auto-descriptibles se logra que
sean independientes de algún servidor de aplicaciones web o sistema gestor de base de datos
para obtener información de su contenido. Para lograr esto, en el presente trabajo se diseñó e
implementó una ontología, la cual, es el punto de partida para generar los mapas de
instalaciones. En esta ontología se crean instancias con sus respectivos atributos y
características que describen en detalle la infraestructura de la organización, en instalaciones y
tecnología, por ejemplo, aulas, laboratorios, auditorios, cubículos, biblioteca, cafetería, etc.
De igual manera aquí se presenta el diseño y la implementaron de dos prototipos para la
explotación de la información almacenada en la ontología de la infraestructura, permitiendo
asociar a los elementos gráficos de archivo SVG, la información de una determinada instancia
de la ontología y posteriormente realizar la consulta en un dispositivo móvil.

1.2 Antecedentes del proyecto.

Servicios de localización conscientes del contexto aplicando perfiles de movilidad y
tecnologías de localización heterogéneas. [Arjona 2009]

Este trabajo se ubica sobre los servicios conscientes del contexto con localización en interiores
en edificios multinivel, presenta la realización de tareas (creación, cancelación y
cumplimiento) pudiendo asociar algún recurso a ella (mediante etiquetas RFID o QRCodes)
para el recordatorio de las tareas al estar en proximidad del recurso asociado a ella.

Dentro de sus tareas existe la capacidad de guiado, donde se selecciona un punto destino y,
basado en la posición actual del dispositivo se solicita a un servidor una ruta, el servidor
devuelve al dispositivo la ruta a seguir y muestra en pantalla la ubicación actual y el punto a
dirigirse, conforme se van leyendo nuevos sensores o códigos de barras, se va actualizando la
posición del usuario en el mapa hasta llegar al destino.

11


Cuenta con una aplicación web que gestiona la información de tareas, ubicaciones, usuarios y
recursos y una aplicación cliente para celulares basados en Android con las siguientes
características:
 Las ubicaciones se denotan a través de tarjetas RFID.
 Los valores RFID antes mencionados se guardan en una base de datos.
 Los valores se asocian a mapas en imágenes de tipo mapa de bits.
 Almacena recursos igualmente mediante RFID y sus datos se almacenan en una base
de datos.

Su relevancia para este trabajo de tesis consiste en retomar la parte del uso de mapas para la
orientación del usuario, buscando no depender de entidades externas como un servidor web
para saber la localización, para lo cual se plantea la incorporación de información adicional al
mapa o croquis que se esté desplegando.

Figura 1-1 Asociación de ubicaciones a mapa [Arjona 2009]

12


1.3 Descripción del problema.

Esta tesis es continuación del trabajo realizado en [Arjona 2009], se centra específicamente en
la optimización de mapas organizacionales, los mapas empleados en la tesis de [Arjona 2009]
son imágenes raster1 en formato JPG, las cuales se asocian a través de una aplicación que a
coordenandas de la imagen la ubicación de etiquetas RFID y QRCodes, estas coordenadas son
almacenadas en una base de datos, cuando el dispositivo lee una etiqueta RFID o decodifica
una imagen QRCodes envía una petición al servidor, como respuesta, el servidor le envía una
imagen JPEG en donde se muestra la ubicación del usuario en el mapa.

Una de las principales desventajas del método de solución de la tesis de [Arjona 2009] es que
utiliza mapas organizacionales en formato raster (JPEG), este formato se deforma cuando se
realizan acercamientos a la imagen, lo cual tiene como resultado una calidad de imagen
degradada debido a que se observan los pixeles que la componen. Otro problema con estos
formatos (JPEG) es que no permiten la incorporación de información contextual que los auto-
describa, esto genera que sea necesario recurrir a la manipulación a nivel de bits o se requiera
el acceso a alguna entidad externa, como una base de datos en el caso de [Arjona 2009],
aunado a esto, el uso sobre dispositivos móviles donde el espacio de visualización es reducido
requiere que las imágenes deban ser pequeñas y por lo tanto estas presentan una degradación
en su calidad si se realizan acercamientos sobre ellas como se aprecia en la Figura 1-2.

Figura 1-2 Comparación de formato vectorial con formato de mapa de bits o raster [IES_EP 2011]

1
Rejilla rectangular de pixeles

13


1.4 Objetivos.
1.4.1 Objetivo general.

Desarrollar un conjunto de herramientas para la generación y explotación de mapas
semánticos, en formato SVG, que describan las instalaciones de organizaciones mediante el
uso de ontologías, estos mapas contendrán información contextual de las instalaciones de una
organización que les permitirá ser auto-descriptibles.

1.4.2 Objetivos específicos.

i. Crear una ontología de estructuras físicas de interiores y exteriores de organizaciones
que represente su caracterización tanto espacial como funcional.
ii. Crear una herramienta que permita generar mapas SVG con anotaciones semánticas
del exterior e interiores de una organización.
iii. Crear un módulo que permita recibir un conjunto de recomendaciones y modificar el
mapa SVG para que represente la información que corresponde a las recomendaciones.
iv. Crear un visualizador de mapas SVG que soporten anotaciones semánticas y trabajen
sobre plataforma Android 2.x en dispositivos móviles.

1.5 Justificación y beneficios del proyecto.

El presente trabajo forma parte de un sistema de recomendación contextual que tiene sus
orígenes en el trabajo desarrollado por “Servicios de localización conscientes del contexto
aplicando perfiles de movilidad y tecnologías de localización heterogéneas” [Arjona 2009] y
que es acompañado de los trabajos “Sistema de recomendación contextual basado en
ontologías para ambientes organizacionales y de usuario en entornos de cómputo móvil”
[González 2012] y “API para servicios de localización basada en tecnología RFID, QRCode,
WiFi y Bluetooth” [Yris 2012], la arquitectura general del proyecto que extiende la plataforma
T-Guía se describe en la Figura 1-3

14


Generador de mapas
Repositorio de semánticos SVG
mapas

Módulo de edición
automática de mapas Visualizador
Red de
SVG
ontologías

Gestor de recomendaciones
contextuales [González Evaluador de
2012] recomendaciones
BD Relacional [González 2012]

API de localización
[Yris 2012]

Figura 1-3 Arquitectura general de la extensión de la plataforma T-Guía

Con esta tesis se mejora y complementa la plataforma T-Guia desarrollada en [Arjona 2009],
específicamente en la parte del subsistema de creación y visualización de mapas mediante el
desarrollo de prototipos que permitan realizar tareas de una manera más eficiente y que
proporcionen nuevas funcionalidades.
El resultado de esta tesis ayudará a:
 Contar con un modelo semántico que caracterice y describa la infraestructura de las
organizaciones con el uso de la red de ontologías, que incluye la ontología desarrollada
en esta tesis.
 Mejorar el proceso de creación de mapas para el sistema de localización T-Guía.
 Contar con mapas de instalaciones organizacionales auto-descriptivos e interactivos
como resultado del uso del formato de imágenes vectoriales SVG.

15


1.6 Alcances y limitaciones.

Para el desarrollo de éste proyecto se tomaron las siguientes consideraciones.

1.6.1 Alcances.

 Se manipulan mapas en formato SVG y SVG Tiny y se generara mapas en formato
SVG Tiny.
 La aplicación para la generación de mapas semánticos es multiplataforma, esto
implementado mediante una aplicación web.
 La población de información a elementos en el mapa se hace de forma manual por
parte de un usuario, con la ayuda de la aplicación web.
 El módulo de edición automática de información contextual contenida en mapas SVG
sólo se encarga de remover la información que no sea necesaria del mapa.
 El visualizador de mapas SVG se implementa sobre la plataforma Android 2.x.

1.6.2 Limitaciones.

 No se considera la implementación del prototipo para la creación de mapas SVG, se
utilizarán editores de código abierto para este proceso de creación de los mapas.

1.7 Organización del documento.

La estructura restante del documento se presenta a continuación. El Capítulo 2 Marco teórico,
da un panorama general de las herramientas y plataformas sobre las cuales se basa el
desarrollo de esta tesis. El Capítulo 3 Estado del arte da una recopilación de los artículos más
relevantes que poseen similitudes en ciertos aspectos con el trabajo a desarrollado en esta
tesis, concluyendo el capítulo con una tabla comparativa entre estos trabajos y esta tesis. El
Capítulo 4 Análisis y diseño muestra los diagramas UML correspondientes de ambas etapas
que presentan las conceptualizaciones de las herramientas desarrolladas. El Capítulo 5
Implementación, muestra las interfaces gráficas y funcionalidades de los prototipos
desarrollados. El Capítulo 6 Pruebas, contiene la ejecución de los casos de prueba definidos en

16


el Anexo A1. El Capítulo 7 Conclusiones, describe los resultados obtenidos con este trabajo de
tesis, así como los trabajos futuros.

Posteriormente a esta serie de capítulos se encuentra una secuencia de anexos, donde el Anexo
A1 es el plan de pruebas que se ejecutó sobre los prototipos, el Anexo A2 especifica el
formato que debe tener el archivo de recomendaciones empleado por uno de los prototipos y el
Anexo A3 hace referencia al formato al cual se debe acoplar el mapa SVG para el
funcionamiento adecuado con los prototipos. Por último se encuentra la sección de referencias.

17

Capítulo 2 Marco teórico

La naturaleza de este trabajo de tesis requirió incursionar en diferentes disciplinas entre las
cuales sobresalen: ontologías, imágenes vectoriales, programación para dispositivos móviles y
para la Web. Por ello se destacan en esta sección las tecnologías involucradas.

2. 1 Ontologías.

En el contexto de las ciencias de la computación y la informática, [Gruber 2009] define a una
ontología como un conjunto de primitivas figurativas con las cuales se modela un dominio de
conocimiento o discurso. Las primitivas figurativas son típicamente clases (o conjuntos),
atributos (o propiedades) y relaciones (o relaciones entre miembros de clases). Las
definiciones de las primitivas incluyen información acerca de su significado. En un contexto
de sistemas de base de datos, la ontología se puede ver como un nivel de abstracción de
modelos de datos, análogo a los modelos relacionales y jerárquicos, pero pretendido para
modelar conocimiento acerca de individuos, sus atributos, y sus relaciones con otros
individuos. Las ontologías son normalmente especificadas en lenguajes que permiten separar
lo abstracto de las estructuras de datos e implementación de estrategias; en la práctica, los
lenguajes de ontologías están más cerca en expresividad a la lógica de primer orden que los
lenguajes utilizados para modelar bases de datos. Por esta razón, se dice que las ontologías
están a nivel “semántico”, mientras que los esquemas de base de datos son modelos a un nivel
“físico” o “lógico”. Debido a su independencia de modelos de datos a más bajo nivel, las
ontologías se utilizan para integrar bases de datos heterogéneas, permitir la interoperabilidad
entre sistemas distintos, y especificar interfaces para sistemas independientes basados en
conocimiento.

2.2 Jena.

Jena es un framework en Java para construir aplicaciones para la Web semántica [Jena 2011].
Jena es de código abierto e incluye:
 Una API para RDF.
 Una API para OWL
 Almacenamiento persistente y en memoria

19


 Un motor de consultas SPARQL.

Hay dos subsistemas para la persistencia de datos RDF y OWL en Jena, SDB y TDB [Jena2
2011]:
 TDB es un motor de persistencia nativo y de alto rendimiento que utiliza
almacenamiento e indexación a la medida.
 SDB es una capa de persistencia que utiliza una base de datos SQL y soporta
completamente transacciones ACID.

2.3 SVG y SVG Tiny.

De acuerdo con [SVG 2008], SVG es un lenguaje para describir gráficas de dos dimensiones
en XML. SVG permite tres tipos de objetos gráficos: figuras de gráficos vectoriales (ej. Trazos
que consisten de líneas o curvas), imágenes y texto. Dichos objetos gráficos pueden ser
agrupados, estilizados y transformados; este conjunto de características incluye
transformaciones anidadas, caminos de corte, máscaras alfa, filtros de efectos y plantillas de
objetos.
Los dibujos SVG pueden ser interactivos y dinámicos. Se pueden definir y activar
animaciones ya sea declarativamente (ej. Empotrando elementos de animación SVG en el
contenido de un elemento gráfico SVG) o por medio de scripts.

Se ha establecido por la demanda de la industria, que se requiere de alguna forma de visualizar
gráficas vectoriales en dispositivos pequeños. Para cumplir con estas demandas el grupo de
trabajo de SVG se comprometió a hacer un esfuerzo por crear una especificación para un
perfil que se enfocara a dispositivos móviles.
Sin embargo, su solo perfil no es suficiente para tratar con la variedad de dispositivos móviles,
porque cada dispositivo móvil tiene diferentes características en términos de velocidad de
CPU, tamaño de memoria y soporte de colores. Para atacar el rango de diferentes familias de
dispositivos, dos perfiles fueron definidos. El primer perfil de bajo nivel, SVG Tiny (SVGT)

20


es adecuado para dispositivos móviles altamente restringidos; mientras que el segundo perfil,
SVG Basic (SVGB) está enfocado a dispositivos móviles de mayor nivel.
Para asegurar la interoperabilidad entre contenido y herramientas de software que cumplen
con diferentes perfiles, SVGT está especificado como un subconjunto propio de SVGB, y
SVGB un subconjunto propio de SVG. [SVGM 2003]

Sin embargo, avances en el DOM nivel 3, provocaron que se diera una revisión al uso de
lenguajes de programación en SVG Tiny. También se desarrolló una interfaz ligera
denominada Micro DOM, o uDOM. Con lo anterior se hizo posible el control programático
sobre SVG en todo el rango de plataformas, desde celulares a equipos de escritorio. En
consecuencia, solo existe un perfil móvil para SVG: Svg Tiny 1.2.

2.4 Android.

Android es una plataforma para dispositivos móviles que incluye un sistema operativo,
middleware y aplicaciones clave desarrollado por la Open Handset Alliance, un grupo de
líderes en tecnología y móviles que comparten la visión de cambiar la experiencia móvil de los
consumidores [OPA 2011].
La arquitectura de Android se puede apreciar en la Figura 2-1 y sus partes principales se
describen a continuación:
 Aplicaciones. Android se instala con un conjunto básico de aplicaciones todas escritas
en el lenguaje de programación Java.
 Framework de aplicaciones. Se provee una plataforma de desarrollo abierta que
permite a los desarrolladores construir aplicaciones innovadoras, teniendo acceso a las
mismas API utilizadas por las aplicaciones básicas de Android.
 Librerías. Se incluyen también un conjunto de librerías en C/C++ utilizadas por varios
componentes del sistema Android. Capacidades que también están expuestas a los
desarrolladores mediante el framework de aplicaciones.
 Tiempo de ejecución. Android incluye un conjunto de librerías que provee la mayoría
de la funcionalidad de las librerías básicas de Java. También posee la capacidad de
ejecutar múltiples máquinas virtuales de manera eficiente.

21


 Kernel de Linux. Android se basa en la versión 2.6 de Linux para el sistema básico de
servicios como la seguridad, administración de memoria y procesos, la pila de red, etc.

Figura 2-1 Arquitectura general de Android [Android 2011]

2.5 TinyLine SVG.

TinyLine SVG implementa un motor de SVG Tiny 1.1 y superior para la plataforma Java y
Android. [TinyLine 2011]. Sus principales características son: motor SVG Tiny 1.1 y superior,
soporta fuentes SVG, imágenes raster, caminos y elementos texto, soporta animaciones SMIL
y eventos, permite flujos en texto y comprimidos gzip, posee un código compacto (JAR de
100KB aproximadamente) y una API con una pequeña curva de aprendizaje.
Esta API es la empleada para el desarrollo de uno de los prototipos y fue elegida en base a la
comparación de sus características con otros opciones que trabajan con SVG, siendo esta la
que proporciona mayores ventajas, como se observa en la Tabla 2-1.

22


Tabla 2-1. Comparativa de APIs o visualizadores SVG para dispositivos móviles

Opción Ventajas Desventajas
Anti-Grain Código abierto. Código nativo (C++).
Geometry Soporte básico de SVG.
Visualizador solamente.
libsvg-android Código abierto. Código nativo (Lenguaje C).
Solo funciona con imágenes
estáticas.
Visualizador solamente.
svg4mobile Código abierto en Java. Visualizador solamente.
Implementa una porción reducida de
la especificación SVG Tiny 1.1
TinyLine SVG Código para Java. Código cerrado.
Soporta SVG Tiny 1.1+. De paga.
Permite alterar el DOM
de SVG.
Posee una API

23

Capítulo 3 Estado del arte

Para este trabajo fue necesario recurrir a diferentes áreas de las ciencias computacionales,
destacando la ingeniería ontológica y las imágenes vectoriales. Por ello, el estado del arte se
divide en dos grandes secciones, los trabajos que involucran el aspecto relacionado al
modelado de espacios mediante el uso de ontologías y la segunda sección, los trabajos que
involucran técnicas para extender el formato SVG que permitan contener información
adicional a la provista por el estándar.

3.1 Modelos de representación de espacios.
3.1.1 An ontology for context-aware pervasive computing environments. [Chen 2003]

Descripción.
En este trabajo se presenta a CoBrA (Context Broker Architecture), una arquitectura
mediadora de agentes para apoyar a los sistemas conscientes del contexto en espacios
inteligentes. El rol de esta arquitectura es mantener un modelo compartido del contexto para
una comunidad de agentes y dispositivos en un espacio, protegiendo la privacidad de los
usuarios aplicando políticas definidas por los usuarios para compartir información con otros
agentes en el espacio asociado.

Características.
 Utiliza un conjunto un conjunto de ontologías denominado COBRA-ONT, que le
ayuda a CoBrA a compartir el conocimiento del contexto con otros agentes y le
permiten razonar acerca del contexto, el cual se categoriza en cuatro temas:
1. Lugares físicos.
2. Agentes (humanos o software).
3. Contexto de localización de los agentes.
4. Contexto de actividades de los agentes.
 No menciona el uso de mapas dentro de su sistema, solamente el uso de la información
espacial descrita en la ontología para realizar inferencias.
 La conceptualización de espacios va desde un Campus a una habitación
 Ontologías expresadas en OWL.

25


Tabla 3-1 Lista completa de clases y propiedades en COBRA-ONT v0.2 [Chen 2003]

Relevancia para la tesis.
Es de particular interés la definición de la clase Place (lugar) y dos subclases de Place (que
representa la abstracción de una ubicación física), AtomicPlace (lugar atómico) y
CompoundPlace (lugar compuesto). La propiedad de contención está representada por
spatiallySubsumes (contiene espacialmente) y isSpatiallySubsumedBy (está espacialmente
contenido por). Existen subclases predefinidas de AtomicPlace tales como, Room (habitación),
Hallway (pasillo), Stairway (escalera) y ParkingLot (estacionamiento), y subclases
predefinidas de CompoundPlace como Campus y Building (Edificio).

Sin embargo, la categorización de los conceptos anteriores se basa en un tipo de aplicaciones
conscientes del contexto que necesitan basarse en el prototipo CoBrA (como lo es la ubicación
de agentes y políticas de seguridad). Por tanto para una aplicación consciente del contexto con
un enfoque diferente es necesario modificar la jerarquía de la ontología para poder reutilizarla.

26


3.1.2 LAIR: Location awareness information representation. [Kottahachchi 2005]

Descripción.
Este artículo se enfoca a la necesidad de un modelo de espacios que represente no solo dónde
está una persona, sino también de qué lugares está cerca y que puede hacer en esos lugares
cercanos. Pretende dejar a un lado los modelos hechos a la medida y propone una
representación universal de ubicaciones, que pueda ser utilizada sin pensar en una aplicación
específica, para construir aplicaciones basadas en dicho modelo.

Características.
 El modelo representa tanto exteriores como interiores.
 El modelo puede representar las características funcionales de los espacios así como
recursos.
 Se pretende que la ontología esté disponible en DAML, OWL y RDF.
 Dado que solamente se propone un modelo; el uso de mapas, su formato e
implementación es dependiente de la aplicación a crear.

LAIR es una ontología inspirada en el modelo TOUR de Kuiper [Kuipers 1977] de los mapas
cognitivos de una persona acerca de los espacios a gran escala, utiliza los siguientes
conceptos:
Entity: colección de Resources que representan al mundo real Person, Place, etc.
Resource: artículo o servicio dentro del control de una Entity en particular.
Security Manager: software contenido en cada Entity para administrar su seguridad, tal como
control de acceso.

Derivado de los conceptos básicos, se definen los siguientes subconceptos:
Place: Entity utilizado para representar un lugar del mundo real. En general contiene las
siguientes propiedades:
Name: forma de referirse al Place.

27


On: lista de Paths sobre los que está este Place.
Star: lista de tripletas (Path, heading, dirección de Path), que describe la geometría de la
intersección formada por los Paths, que se encuentran en este Place, el valor de heading va de
0 a 360.
View: lista de tripletas (Place, orientación, distancia) que describe los otros Place que pueden
ser vistos desde este.
Contained: lista desordenada de Places.
Function: lista de Functional Places que describe que puede hacerse y para que se usa este
Place.
AbnormalActions: modifica la lista de acciones heredada de Funcional Place.
Resources: describe los servicios e ítems disponibles en este lugar. Heredado de Entity.
Occupants: propiedad dinámica que lista las entidades Person que ocupan actualmente el
lugar.

Path: enlazan Places. Se puede viajar en dirección +1 o -1 (+, - son direcciones arbitrarias).
Sus propiedades son:
Name: Una forma de referirse a este Path.
Row: Una lista de listas ordenadas de Places. Cada lista es una secuencia de Places
encontrados cuando se va por el Path en dirección +1.

Functional Place: Describen aquellas Actions que pueden hacerse en un espacio dado. Tiene
las siguientes propiedades:
Name: forma de referirse a este Functional Place.
Supports: lista de Actions que pueden realizarse en este lugar.

Action: tarea que puede realizarse en un espacio dado usando los Resources disponibles.
Contienen las siguientes propiedades.
Name: forma de referirse a esta acción.
Requires: lista de Resources requeridos para realizar la acción.

28


Utility: función que describa la utilidad ganada por el Place cuando esta acción se lleva a
cabo.
Cost: función que describa el costo incurrido por el lugar al realizarse la acción.

Person: Entity representando una persona del mundo real. Hereda de Entity una lista de
Resources en el control de esta persona. Tiene las siguientes propiedades:
Name: forma de referirse a esta persona.
Location: lugar donde esta persona está actualmente.
Interests: lista de Actions que describen los intereses de esta persona.

Del modelo anterior podemos extraer algunos conceptos y propiedades generales que pueden
ayudar a describir la infraestructura del edificio, como lo son el FunctionalPlace y Action, así
como observar que pueden no ser necesarios subconceptos de Place como se propone en
[Chen 2003]

3.1.3 OntoNav: A semantic indoor navigation system. [Anagnostopoulos 2005]

Descripción.
OntoNav es un sistema de navegación en ambientes interiores basado en un modelo híbrido
(geométrico y semántico) de éstos ambientes. OntoNav está centrado en el usuario en el
sentido que las rutas y las guías que las describen son dadas dependiendo de las capacidades
perceptivas o físicas del usuario, así como sus preferencias particulares. Para este trabajo
desarrollaron INO (Indoor Navigation Ontology), que se adecua a las tareas de presentación y
búsqueda de rutas. Una parte central de la ontología se muestra en la Figura 3-1.

29


Figura 3-1 Parte central de INO [Anagnostopoulos 2005]

Características.
 El modelo presentado limita su capacidad de representación a interiores de edificios.
 Se utiliza una base de datos espacial para calcular las rutas.
 La ontología sirve para rutas en base a preferencias o perfiles de usuario.
 Se devuelve un conjunto de instrucciones y no un mapa de la ruta.

INO es nuestro punto de interés dado que es el modelo encargado de representar los caminos y
ubicaciones:
User: representa los usuarios del servicio de navegación.
PointOfInterest: cualquier ubicación física o virtual u objeto que le resulte de interés al
usuario.
Passage: cualquier elemento espacial parte de un Path y que tiene propiedades de
accesibilidad específicas. Se pueden caracterizar en horizontales (conectan corredores en el
mismo piso) y verticales (conectan corredores de diferentes pisos). Los cruces son un tipo
especial de passage que conectan uno o más corredores o fuerzan al cambio de dirección del
usuario o indican el inicio o fin de corredores.
Exit: una entrada o salida de una región interior, La región puede ser todo el edificio, una
planta o un cuarto.

30


Obstacle: cualquier cosa que impida el paso del usuario.
CorridorSegment: concepto creado para facilitar el modelado, conecta exits con passages.
Corridor: compuesto de segmentos de corredor, el cual conecta dos cruces o un passage
vertical con un cruce.
Anchor: cualquier passage, exit, o pointofinterest en un path que pueda ayudar a la
presentación del plan de navegación.
Path: una secuencia intercalada de corridors, exits y passages, que es capaz de llevar a un
usuario de su ubicación a su destino.

El autor considera que los conceptos anteriores son insuficientes, por ello importan de otras
ontologías espaciales conceptos como habitación, planta, edificio. Sin embargo de este trabajo
podemos utilizar el concepto de salida que es importante en la definición de la infraestructura
de un edificio.

3.1.4 ONALIN: ontology and algorithm for indoor routing. [Dudas 2009]

Descripción.
Aquí se presenta una ontología y un algoritmo para encontrar rutas en interiores para
diferentes tipos de usuarios (personas con discapacidades físicas, cognitivas o sensoriales)
basándose en los estándares ADA (American Disability Act) [ADA 1994], entre otros
requerimientos.

Características.
 La conceptualización de espacios se enfoca solamente a interiores.
 Acceso al sistema a través de internet vía un cliente web o un dispositivo móvil con
acceso a internet.
 No menciona si el resultado es un mapa con la ruta visible o un conjunto de
direcciones.

31


 Utiliza un servidor web para contener la ontología, una estructura que modela los
pasillos y sus conexiones, el BIM2 y un módulo para calcular rutas.

Figura 3-2 ONALIN [Dudas 2009]

Para cumplir con los estándares ADA se incluyen información como la altura de una escalera,
disponibilidad de un pasamanos, el ancho de los pasillos, inclinación de rampas o corredores,
varios conjuntos de datos para sanitarios, señalamientos permanentes que por su lectura
ayuden al usuario o Braille, de lo cual se pueden rescatar para nuestro trabajo algunas
propiedades necesarias para la descripción de las capacidades de la infraestructura a modelar.
De igual manera que en [Anagnostopoulos 2005] podemos observar la incidencia en el
concepto de salida.

2
BIM (Building Information Modeling). Es la última generación de OOCAD (Object Oriented Computer-Aided
Design, Diseño Asistido por Computadora Orientado a Objetos) en el cual todos los objetos del edificio son
capturados en un solo “proyecto de base de datos” o “edificio virtual”.

32


3.1.5 Semantic Location Modeling for Location Navigation in Mobile Environment. [Hu
2004]

Descripción.
Los autores nos presentan un modelo de ubicación semántica que conserva la semántica de la
topología y la distancia para apoyar a la navegación en interiores esto para facilitar el
mantenimiento y la construcción programática del modelo. Dicho modelo tiene la visión de
permitir al usuario mirar, navegar o buscar una ubicación física en interiores u otros ambientes
restringidos.

Características.
 Conceptualización del modelo para interiores o espacios restringidos.
 Uso para navegar en interiores y búsqueda de ruta más corta.
 Utilización de grafos para representar el modelo.
 La población del modelo puede ser manual o automática (técnicas de reconocimiento
de lugares de un plano de plantas).
 Presenta una jerarquía de ubicaciones y salidas.

En la metodología que propone este trabajo es definido un concepto de “ubicación” que
menciona que “la ubicación de una entidad es un área geográfica limitada con una o más
„salidas‟, donde una „salida‟ es un punto límite desde el cual una entidad puede ser accedida”.
El trabajo utiliza las salidas para crear una jerarquía de estas y así buscar rutas de navegación.
Para nuestro trabajo tomamos la asociación de ubicación-salida para establecer solamente una
relación espacial entre ubicaciones de modo que se defina el número de salidas de cada
ubicación.

33


Figura 3-3 Ejemplo de jerarquía de ubicaciones y salidas en base a un plano. [Hu 2004]

3.2 Técnicas para extender SVG.
3.2.1 Embedding domain semantics. [Chang 2003]

Descripción.
Este trabajo presenta tres enfoques para asociar datos de otros dominios a elementos gráficos
de SVG, haciendo énfasis en producir documentos SVG que sean desplegables por un
visualizador SVG convencional.

Características.
 Presenta métodos para agregar información a un archivo SVG sin perder sus
capacidades de visualización.
 Son métodos de propósito general, por tanto su uso depende de la aplicación a
desarrollar.
 El SVG resultante no necesariamente es un mapa.
 No utiliza recursos externos para la información asociada a los mapas.

De este trabajo podemos obtener formas de estructurar el documento SVG para agregarles
información adicional a la que provee la especificación por omisión. Nos presenta los
siguientes 3 métodos:

34


a) Agregar nuevos atributos a los elementos de SVG.
Teniendo de ejemplo a un polígono que represente a un pueblo o ciudad, podría desearse tener
asociados su área y perímetro en el mapa. Una forma directa de lograrlo es extendiendo los
atributos del tipo polígono con su área y perímetro, de manera que cada información pueda ser
asociada a cada elemento polígono como un atributo.

Código 3.1 Ejemplo de extensión de atributos SVG [Chang 2003]

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"
"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd" [
<!ATTLIST polygon
area CDATA #IMPLIED
circumference CDATA #IMPLIED>
]>
Información adicional
<svg width="100" height="100" viewBox="0 0 100 100"
xmlns="http://www.w3.org/2000/svg">
mediante la extensión
<defs> de atributos
<style type="text/css"><![CDATA[
polygon { fill: green;
stroke: black;
stroke-width: 1}
]]> Uso de los
</style> atributos
</defs>
definidos
<polygon id="_10001001" points="10,10 10,90 90,90 90,10"
area="6400" circumference="320"/>
</svg>

La ventaja de este enfoque es que la relación entre el elemento SVG y los datos de dominio es
bastante clara. La desventaja es que solo datos de tipo simple pueden ser introducidos para los
atributos y no permite la incorporación de información de dominio de tipo estructurado.

b) Extender los modelos de contenido de los elementos de SVG.
Aquí se extiende el modelo del elemento SVG permitiendo que se tengan hijos de tipo canton
del nombre de espacios m, que tiene a su vez hijos con los datos relacionados al dominio de un
pueblo o ciudad: nombre, estadística, límites (el límite expresado por un elemento geométrico
de SVG).

Código 3.2 Ejemplo de extensión de modelo de contenido de SVG [Chang 2003]

<!ATTLIST svg
xmlns:m CDATA #IMPLIED>

35


<!ENTITY % svgExt "| m:canton">

<!ELEMENT m:canton (m:name*, m:statistics, m:boundary)> Información adicional
<!ATTLIST m:canton
id ID #REQUIRED
mediante la extensión
bndtype (village | county) #REQUIRED> del modelo SVG.
<!ELEMENT m:name EMPTY>
<!ATTLIST m:name
lang (chinese | tonyonPinyin) "chinese"
desc CDATA #REQUIRED>

<!ELEMENT m:statistics (m:population)>

<!ELEMENT m:population EMPTY>
<!ATTLIST m:population
count CDATA #REQUIRED>

<!ELEMENT m:boundary ((g | path| polygon | polyline |
rect | circle | ellipse | line)*, m:geometricInfo)>

<!ELEMENT m:geometricInfo EMPTY>
<!ATTLIST m:geometricInfo
area CDATA #IMPLIED
circumference CDATA #IMPLIED>
]>

<svg width="100" height="100" viewBox="0 0 100 100"
xmlns="http://www.w3.org/2000/svg"
xmlns:m="http://example.tsm.iis.sinica.edu.tw">
<defs>
<style type="text/css"><![CDATA[
polygon { fill: green;
stroke: black;
stroke-width: 1}
]]>
</style>
</defs>

<m:canton id="_10001001" bndtype="village">
<m:name lang="tonyonPinyin" desc="myvillage"/>
<m:statistics> Integración de un
<m:population count="100"/> elemento externo a SVG.
</m:statistics>
<m:boundary>
<polygon id="_pg01" points="10,10 10,90 90,90 90,10"/>
<m:geometricInfo area="6400" circumference="320"/>
</m:boundary>
</m:canton>
</svg>

Las ventajas con respecto al enfoque anterior es que se puede utilizar un vocabulario ajeno del
dominio de SVG, la relación entre los elementos geométricos de SVG y sus anotaciones
semánticas es clara y no es muy difícil extraer los elementos núcleo de SVG para formar un
documento renderizable3.
La desventaja principal de este enfoque es que el SVG resultante solo será reconocido por
algunos de los visualizadores SVG.
3
El renderizado es el proceso de generar una imagen desde un modelo.

36


c) Enlazar a datos de un dominio específico desde elementos de SVG.
Este enfoque es una mezcla de los dos anteriores, en este caso se extiende el elemento defs de
SVG para incorporar los datos del dominio y a través del atributo xlink:href en la figura
geométrica se apunta a la información adicional declarar en los defs.

Código 3.3 Ejemplo de enlace a datos desde elementos SVG [Chang 2003]

....

<!ENTITY % defsExt "| tsm:cantons">
<!ELEMENT tsm:cantons (tsm:canton)*>
<!ELEMENT tsm:canton (tsm:countyName, tsm:townName,
tsm:countyNamePinyin, tsm:townNamePinyin, tsm:area,
tsm:population, tsm:statistics)*>
....

<!ELEMENT tsm:statistics (tsm:Han | tsm:Paiwan | tsm:Bunun |
tsm:Puyuma | tsm:Amis | tsm:Atayal | tsm:Rukai |
tsm:Tsou | tsm:Tau | tsm:Others | tsm:Saisiat)*>

<!ELEMENT tsm:Han EMPTY>
<!ATTLIST tsm:Han
count CDATA #REQUIRED>

....
]>

<svg viewBox="0 0 260618 377029" xmlns="http://www.w3.org/2000/svg"
xmlns:tsm="http://example.tsm.iis.sinica.edu.tw"
xmlns:xlink="http://www.w3.org/1999/xlink">
<defs>
....

<tsm:canton id="infoOf_1000801">
<tsm:countyNamePinyin>Nantou County</tsm:countyNamePinyin>
<tsm:townNamePinyin>Nantou City</tsm:townNamePinyin>
<tsm:area>71.6008</tsm:area>
<tsm:population>97469</tsm:population>
<tsm:statistics desc="Population of Ethnic Groups">
<tsm:Han count="96921"/>
<tsm:Paiwan count="45"/>
<tsm:Bunun count="216"/>
<tsm:Puyuma count="13"/>
<tsm:Amis count="113"/>
<tsm:Atayal count="94"/> Se define
<tsm:Rukai count="12"/> información
<tsm:Others count="11"/>
<tsm:Tsou count="27"/> adicional dentro de
<tsm:Tau count="14"/> la etiqueta <defs>
<tsm:Saisiat count="3"/>
</tsm:statistics>
</tsm:canton>

....
</defs>

....

37


<path centroidX="126307.837425" centroidY="152741.66092"
class="normalBoundary" d="M126434,149343L131895,149725 .... "
id="_1000801" xlink:href="#infoOf_1000801"/>

.... Se enlaza a la información mediante
</svg>
el atributo xlink:href

3.2.2 Indoor navigation with SVG. [Schmitt 2005]

Descripción
El trabajo describe una guía móvil para proveer ayuda de navegación en interiores a los
visitantes de un edificio de oficina.

Características.
 El trabajo está limitado a interiores de edificios de oficina.
 Se hace uso del formato SVG para los croquis de los interiores.
 No hace uso de ontologías
 Se hace uso de XSLT para pasar de XML a SVG

En el trabajo se desarrollaron un conjunto de herramientas de ayuda para la guía móvil, de la
cual es de interés el componente de generación de mapas SVG.

Para cumplir el propósito del trabajo, desarrollaron un DTD especial modelando conceptos
comunes como habitaciones de diferente forma y función (oficina, cocina, etc.), puertas,
accesos, objetos especiales como extintores, entre otros. Para facilitar la creación de mapas de
plantas se creó un editor a la medida en Java. Este editor permite definir nuevos objetos de
planta y previsualizar la salida en SVG. Se tienen hojas de estilo XSLT para las diferentes
configuraciones y se emplean para convertir el archivo XML en un plano de habitaciones en la
versión de SVG deseada.

38


Figura 3-4 Generador de mapas SVG

3.2.3 Techniques for binding scalable vector graphics to associated information. [Mor
2007]

Descripción.
Esta patente presenta una técnica para proveer información adicional relacionada a un objeto
de SVG a través de una interfaz gráfica. Las sentencias SVG están ligadas con un apuntador
hacia un recurso que incluye información que le pertenece al objeto. El apuntador del recurso
asociado a una sentencia SVG, puede ser extraído del documento. La información es retirada
del recurso en base al apuntador.

Características.
 Método de propósito general para incorporar y obtener información adicional de un
elemento de SVG.
 Utiliza recursos externos para la información adicional.

39


Figura 3-5 Representación general del trabajo de la patente [Mor 2007]

A pesar de emplear recursos externos para contener la información adicional a los elementos
propios de SVG, en este trabajo se pueden notar el uso del método (c) descrito en [Chang
2003] y por tanto considerarlo como una de las mejores formas de agregar datos de otro
dominio a un documento SVG.

3.3 Análisis comparativo.

En la Tabla 3-2 se presenta el análisis comparativo de los trabajos descritos en el estado del
arte referentes a los modelos de representación de espacios, se definen 4 características de
relevancia para la comparación:
1. Granularidad de la representación de espacios. Se utiliza para observar el alcance
que se tiene en cuanto a qué espacios pueden ser representados dentro de cada trabajo.
2. Representación de objetos adicionales a espacios. Esto es, si la representación
modela por default o mediante el uso de otros recursos alguna otra característica que
no sea un espacio.

40


3. Tecnología de la representación. Define en dónde es plasmada la información
relacionada con los espacios.
4. Uso de la representación de espacios. Esta característica indica para que se emplea la
representación de espacios dentro del trabajo.

Dentro de los valores para las características se encuentra el valor “Dependiente de la
aplicación” esto se da debido a que los trabajos para los cuales el valor aplica son trabajos
sobre los cuales no necesariamente se utilizan para representación de espacios y mapas y por
tanto quedan a disposición de quien desarrolle la manera de implementar.

Tabla 3-2 Análisis comparativo del estado del arte en modelos de representación de espacios

Granularidad Representación Tecnología de Uso de la
de la de objetos la representación
representación adicionales a representación de espacios
de espacios espacios
Chen 2003 De Campus a Agentes y OWL Realizar
habitación actividades inferencias sobre
mediante el contexto
ontologías
adicionales
Hu 2004 Plantas y Ninguna Grafos Navegación en
habitaciones interiores y
búsqueda de
camino más
corto
Anagnostopoulos Plantas y No menciona Base de datos Hacer
2005 habitaciones espacial y OWL inferencias para
seleccionar la
mejor ruta de un
conjunto de rutas
en base a perfil
del usuario
Kottahachchi De países a Funciones, DAML, OWL y Modelo general
2005 habitaciones actividades, RDF para apoyar a
recursos, aplicaciones
personas de conscientes del
forma nativa contexto
Dudas 2009 Plantas y Objetos que Ontología, Proveer la mejor

41


habitaciones representen modelo de ruta en base a
obstáculos redes de perfil del usuario
pasillos y BIM
Tesis De países a Funciones, OWL Acotado a la
habitaciones actividades y descripción de la
recursos para infraestructura
enlace con de
ontologías organizaciones
externas

En la Tabla 3-3 se presenta el análisis comparativo de los trabajos descritos en el estado del
arte referentes a la extensión del formato SVG para contener información adicional a lo
establecido en el estándar, se definen la técnica empleada, así como sus puntos a favor y en
contra.

Tabla 3-3 Análisis comparativo del estado del arte en técnicas para extender SVG

Técnica Pros Contras
Chang Agregar atributos a los Propósito general, No permite información
2003 (a) elementos SVG Claridad de la relación estructurada.
elemento-información.
Chang Extender los modelos Propósito general. Puede no ser reconocido el
2003 (b) de los elementos SVG Claridad de la relación formato por algunos visores.
elemento-información.
Permite información
estructurada.
Chang Enlazar a datos desde Propósito general. El desarrollo de la DTD puede
2003 (c) elementos SVG Claridad de la relación volverse complejo dependiendo
elemento-información. de la información que se quiera
Permite información incluir
estructurada.
Schmitt Conversión a SVG de No menciona. Limitado a un vocabulario de
2005 datos en XML oficina
mediante DTD y
XSLT
Mor Enlazar a datos desde Propósito general. El enlace se realiza a entidades
2007 elementos SVG externas que proveen la
información.
Tesis Enlazar a datos desde Propósito general.
elementos SVG No requiere DTD.
Información
estructurada.

42

Capítulo 4 Análisis y diseño.

Capítulo 4 Análisis y diseño

4.1 Análisis.

El presente trabajo de tesis se conforma del desarrollo de un conjunto de herramientas que
permiten: a) agregar información a un mapa SVG de manera manual asociando a las figuras
del mapa información de la organización, b) recibir un conjunto de recomendaciones que
permiten modificar de manera automática el mapa SVG, extrayendo información que no está
considerada en las recomendaciones, este proceso lo denominamos destilado del mapa SVG,
para denotar de manera gráfica los puntos de interés y eliminar información que no es
pertinente a las recomendaciones de entrada y c) hacer uso del mapa SVG y explorar su
información dentro de un dispositivo móvil que funcione con la plataforma Android 2.x.
También incluyó el desarrollo de una ontología para la representación de infraestructura que
funge como fuente de datos para los prototipos software y que además es parte de una red de
ontologías, donde es complemento para proveer una descripción más amplia de una
organización.

Módulo de
generación de
Repositorio de ontologías existentes mapas SVG con
anotaciones
semánticas
Ontología de infraestructura

Módulo de
Visualizador edición Repositorio de
SVG automática de mapas SVG
mapas SVG

Figura 4-1 Esquema de interacción entre los módulos desarrollados.

La Figura 4-2 muestra de manera sencilla como una ubicación (infraestructura de una
organización) puede relacionarse con conceptos de otras ontologías como lo son personas (que
utilizan el espacio) y recursos (que son propios del lugar). La ontología de infraestructura

44


complementa la red de ontologías y a la vez funciona como un puente de comunicación entre
los datos ya registrados en la red de ontologías mediante la relación de los conceptos
existentes con los definidos en la infraestructura.

Figura 4-2 Diagrama conceptual del enlace de la ontología de infraestructura en la red de ontologías

4.1.1 Ontología de infraestructura.

4.1.1.1 Metodología para crear la ontología.
Nos basamos en dos trabajos respecto a creación de ontologías para llevar a cabo la tarea de
desarrollo de la ontología de infraestructura necesaria para la tesis: “Guía Para Crear Tu
Primera Ontología” [Noy 2005] y “METHONTOLOGY” [Fernández 1997]:

[Noy 2005] propone los siguientes pasos:
1. Determinar el dominio y alcance de la ontología, con ayuda de preguntas básicas
como:

45


a. ¿Cuál es el dominio que cubrirá la ontología?
b. ¿Para qué usaremos la ontología?
c. ¿A qué tipos de preguntas deberá proveer respuestas la información en la
ontología?
2. Considerar la reutilización de ontologías existentes. Verificar si podemos refinar y
extender recursos existentes para nuestro dominio y tarea particular.
3. Enumerar términos importantes para la ontología. Escribir una lista con todos los
términos con los que quisiéramos hacer enunciados o dar explicación a un usuario.
4. Definir las clases y la jerarquía de clases.
5. Definir las propiedades de las clases (denominados en esta metodología “slots”).
6. Definir las facetas de los slots. (Cardinalidad, tipo de valor, dominio y rango).
7. Crear instancias.

[Noy 2005] da un panorama general, por lo que se complementan las etapas y plantillas con el
trabajo de [Fernández 1997], la cual propone las siguientes tareas [Gómez 2004]:
1. Construir un glosario de términos que identifique el conjunto de términos que serán
incluidos en la ontología, su definición en lenguaje natural, y sus sinónimos y
acrónimos.
2. Construir una taxonomía de conceptos para clasificar conceptos.
3. Construir diagramas de relaciones binarias para identificar relaciones entre conceptos
de la ontología.
4. Construir el diccionario de conceptos, que contiene principalmente instancias de
conceptos para cada concepto, atributos de clases y sus relaciones.
5. Describir a detalle cada relación binaria que parece en los diagramas y el diccionario
de conceptos.
6. Describir a detalle cada atributo de instancia que aparece en el diccionario de
conceptos.
7. Describir a detalle cada atributo de clase que aparece en el diccionario de conceptos.
8. Describir a detalle cada constante y producir una tabla de constantes
9. Describir axiomas formales.

46


10. Describir reglas.
Opcionalmente, introducir información de instancias.

4.1.1.2 Definición de dominio y alcances de la ontología.

La ontología debe cubrir los conceptos y relaciones inherentes a la descripción de ubicaciones
(espacios físicos) que puedan existir dentro del perímetro de los terrenos de organizaciones.
El uso de la ontología es para representar funciones y recursos asociados a los elementos de
mapas de interiores y exteriores de la infraestructura de una organización.
Se pueden atacar preguntas que traten con la ubicación de espacios y con las capacidades de
estos, como pueden ser: ¿En qué edificio está el laboratorio x, la oficina y, o el aula z?,
¿Cuántas personas pueden estar en el auditorio de la organización?, ¿Quién es la persona que
ocupa esta área?, etc.

4.1.1.3 Ontologías existentes.

Dentro del reporte del estado del arte se localizaron algunas ontologías que no tratan
precisamente de modelar la infraestructura pero si los espacios, por lo tanto se utilizaron
algunos de sus conceptos y relaciones como base para nuestra ontología. Para observar lo
relevante de esos trabajos referirse al reporte del estado del arte.

4.1.1.4 Conceptos extraídos de las ontologías existentes.

Door [Dudas 2009]
AutomaticDoor [Dudas 2009]
EmergencyDoor [Dudas 2009]
ManualDoor [Dudas 2009]
Function [Kottahachchi 2005] (Nombrada como Activity)
FunctionalPlace [Kottahachchi 2005]
Person [Kottahachchi 2005]

47

Generación y Explotación de Mapas Semánticos de Instalaciones Organizacionales mediante el uso de Ontologías

Generación y Explotación de Mapas Semánticos de Instalaciones Organizacionales mediante el uso de Ontologías

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Generación y Explotación de Mapas Semánticos de Instalaciones Organizacionales mediante el uso de Ontologías

Semelhante a Generación y Explotación de Mapas Semánticos de Instalaciones Organizacionales mediante el uso de Ontologías (20)

Mais de Gabriel Gonzalez Serna

Mais de Gabriel Gonzalez Serna (16)

Último

Último (20)

Generación y Explotación de Mapas Semánticos de Instalaciones Organizacionales mediante el uso de Ontologías