Pois Plataform - Repositorio Digital UTPL
Anuncio
UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA
La Universidad Católica De Loja
MODALIDAD PRESENCIAL
ESCUELA DE CIENCIAS DE LA COMPUTACIÓN
Plataforma POIS – Linked Data.
Aplicación a los recorridos de los buses de la UTPL
TRABAJO DE FIN DE CARRERA PREVIO A LA
OBTENCIÓN DEL TÍTULO DE INGENIERO EN
SISTEMAS INFORMÁTICOS Y
COMPUTACIÓN
Autor:
Cueva Tacuri, Cúmar Ramiro
Director:
Ing. López Vargas, Jorge Afranio
LOJA – ECUADOR
2011
1
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
CERTIFICACIÓN
Ingeniero
Jorge A. López V.
DIRECTOR
CERTIFICA:
Haber dirigido y supervisado el desarrollo del presente proyecto de Tesis previo a la
obtención del título de INGENIERO EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN,
presentado por el alumno Sr. CÚMAR RAMIRO CUEVA TACURI, y una vez que este cumple
con todas las exigencias y requisitos legales establecidos por la Universidad Técnica
Particular de Loja, autorizo su presentación para los fines legales pertinentes.
Loja, Octubre de 2011
F.-----------------------------------Ing. López Vargas, Jorge Afranio
i
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
CERTIFICACIÓN
Ingeniera
Diana Torres
CO-DIRECTORA
CERTIFICA:
Haber dirigido y supervisado el desarrollo del presente proyecto de Tesis previo a la
obtención del título de INGENIERO EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN,
presentado por el alumno Sr. CÚMAR RAMIRO CUEVA TACURI, y una vez que este cumple
con todas las exigencias y requisitos legales establecidos por la Universidad Técnica
Particular de Loja, autorizo su presentación para los fines legales pertinentes.
Loja, Octubre de 2011
F.-----------------------------------Ing. Torres, Diana
ii
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
AUTORÍA
El presente proyecto de tesis con cada una de las observaciones, análisis, evaluaciones,
conclusiones y recomendaciones emitidas, son de absoluta responsabilidad del autor.
De igual manera, es necesario indicar que la información de otros autores incluida en el presente
trabajo se encuentra debidamente especificada en las fuentes de referencia y apartados
bibliográficos.
F.-----------------------------------CUEVA TACURI, CÚMAR RAMIRO
iii
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
CESIÓN DE DERECHOS
Yo, CÚMAR RAMIRO CUEVA TACURI, declaro ser autor del presente trabajo y eximo expresamente
a la Universidad Técnica Particular de Loja y a sus representantes legales de posibles reclamos o
acciones legales.
Adicionalmente declaro conocer y aceptar la disposición del Art. 67 del Estatuto Orgánico de la
Universidad Técnica Particular de Loja que su parte pertinente textualmente dice: “Forman parte
del patrimonio de la Universidad la propiedad intelectual de investigaciones, trabajos científicos o
técnicos y tesis de grado que se realicen a través, o con el apoyo financiero, académico o
institucional (operativo) de la universidad”.
F.-----------------------------------CUEVA TACURI, CÚMAR RAMIRO
iv
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
AGRADECIMIENTO
A Dios por hacer que un sueño sea convertido en
realidad.
Mi más profundo agradecimiento a mis Padres,
cuya confianza ha sido depositada en mí durante
todo este tiempo, de igual manera a mis
hermanos por permitirme tomar prestado su
tiempo para ser invertido en alcanzar esta meta y
el apoyo brindado de una u otra forma.
A mi director de Tesis Ing. Jorge López, por su
acertada labor de dirección, a la cual ha dedicado
gran parte de su tiempo y sin el cual este trabajo
no podría haber sido culminado.
A mi co-directora Ing. Diana Torres, por la
predisposición demostrada desde el inicio hasta el
final del proyecto y la colaboración brindada.
De igual forma a todas las personas cercanas que
de alguna manera y de forma desinteresada
brindaron su apoyo en el transcurso de esta meta,
cuando más se los necesitaba.
CÚMAR RAMIRO CUEVA TACURI
v
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
DEDICATORIA
Dedicado a Aquel que permitió que esta meta sea
cumplida, Aquel que me brindó su apoyo y
compañía durante todo este tiempo y estoy
seguro que lo seguirá haciendo en adelante, Dios.
A mis padres por ser mi ejemplo a seguir, por ser
este sueño compartido y por no perder su
confianza en mí. A ustedes hermanos que siempre
han estado presentes en cada instante de este
trayecto y me han motivado a seguir hasta el final,
en especial a ti Franklin.
A ti bonita, que has compartido junto a mi todo
este caminar, siendo el mejor soporte para no
desmayar.
Y en especial a todos los amigos y compañeros
que nunca dudaron que llegaría el momento en
que el esfuerzo sería recompensado.
CÚMAR RAMIRO CUEVA TACURI
vi
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
ÍNDICE DE CONTENIDOS
CERTIFICACIÓN
I
CERTIFICACIÓN
II
AUTORÍA
III
CESIÓN DE DERECHOS
IV
AGRADECIMIENTO
DEDICATORIA
V
VI
ÍNDICE DE FIGURAS
1
ÍNDICE DE TABLAS
3
1.
4
ESTADO DEL ARTE
1.1.
Introducción
4
1.2.
Linked Data
5
1.3.
RDFStore
7
1.3.1.
Sparql Update
8
1.3.2.
SPARUL y El Proceso Asistido de Actualización
9
1.4.
Puntos de Interés
11
1.5.
Trabajo Relacionado
13
1.6.
Trabajo futuro
15
2.
VOCABULARIO RDF
2.1.
2.1.1.
Construcción
Selección de Elementos Preliminares y Formulación de Interrogantes
17
17
17
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
2.1.2.
Definición de Elementos Finales y sus Atributos
18
2.1.3.
Estructura de Vocabulario
2.1.3.1. Consideraciones de Nomenclatura
2.1.3.2. Descripción de Conceptos
2.1.3.3. Esquema Preliminar
2.1.3.4. Esquema Final
2.1.3.5. Relaciones Binarias
2.1.3.6. Diagrama RDF
19
20
20
22
23
24
25
2.1.4.
Validación del Vocabulario
2.1.4.1. Instancias de Vocabulario
2.1.4.2. Consultas SPARQL
2.1.4.3. Resultados de Validación
25
26
27
32
2.2.
33
URI’s
2.2.1.
Definición
33
2.2.2.
Uri’s para el Vocabulario
34
Publicación de Vocabulario
35
2.3.
2.3.1.
Generación de la Descripción del Vocabulario
36
2.3.2.
PURL
2.3.2.1. Configuraciones
36
37
2.3.3.
Apache HTTP Server
2.3.3.1. Negociación de Contenido (Content Negotiation)
2.3.3.2. Configuraciones
38
38
38
2.3.4.
Pruebas
39
2.3.4.1.
VAPOUR
40
3.
BACKEND
3.1.
3.1.1.
OpenLink Virtuoso
43
43
Carga de Tripletas al Store
43
3.1.2.
Sparql Endpoint
3.1.2.1. Formatos de Respuesta
3.1.2.2. SPARQL basado en REST
3.1.2.3. Pruebas
45
46
47
48
3.1.3.
Autenticación sobre EndPoint
3.1.3.1. Pruebas
49
53
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
3.2.
Vocabulary of Interlinked Datasets (VoID)
54
3.3.
Servicio REST - CRUD
56
3.3.1.
Framework
3.3.1.1. Funcionamiento del Servidor REST
57
58
3.3.2.
URIs de Recursos
61
3.3.3.
Métodos del API
3.3.3.1. Eliminar una Ruta
3.3.3.2. Agregar una nueva parada
3.3.3.3. Eliminar parada
3.3.3.4. Actualizar Propiedad
3.3.3.5. URL para Imágenes
63
63
64
64
65
66
3.3.4.
67
4.
Pruebas
CLIENTE
68
4.1.
Tecnologías
68
4.2.
Integración
69
4.3.
Funcionalidades
70
4.3.1.
Verificación de Existencia de Estudiante
70
4.3.2.
Visualización de Vivienda
70
4.3.3.
Visualización de Parada Frecuente
70
4.3.4.
Registro de Vivienda
70
4.3.5.
Registro de Parada Frecuente
70
4.4.
Pruebas
71
4.4.1.
CASO 1
71
4.4.2.
CASO 2
71
4.4.3.
CASO 3
72
5.
DISCUSIÓN
73
6.
CONCLUSIONES
74
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
7.
RECOMENDACIONES
75
8.
BIBLIOGRAFÍA
76
9.
ANEXOS
78
9.1.
ANEXO A
79
INSTALACIÓN DE PLUGIN - OWLDoc
80
9.2.
81
ANEXO B
CONFIGURACIONES - PURL
82
9.3.
84
ANEXO C
INSTALACIÓN DE SERVIDOR PURL
85
9.4.
89
ANEXO D
APACHE WEB SERVER: Instalación y Configuración
Instalación
Configuraciones
90
90
90
9.5.
93
ANEXO E
VAPOUR: VALIDACIÓN DE VOCABULARIO
94
9.6.
98
ANEXO F
INSTALACIÓN DE VIRTUOSO SERVER
9.7.
ANEXO G
99
102
VIRTUOSO: CARGA DE DATOS AL STORE
103
9.8.
ANEXO H
105
URIs – POIS REST SERVER
106
9.9.
108
ANEXO I
PRUEBAS SERVICIO REST - POIS
109
9.10.
131
ANEXO J
CASOS DE USO
132
9.10.1.
132
Existencia de Estudiante
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.10.2.
Visualizar Vivienda
132
9.10.3.
Visualizar Parada Frecuente
133
9.10.4.
Registro de Vivienda
133
9.10.5.
Registro de Parada Frecuente
134
9.11.
ANEXO K
135
INTERFAZ DE CLIENTE
136
9.11.1.
INGRESO
136
9.11.2.
PRINCIPAL
136
9.11.3.
VIVIENDA
137
9.11.4.
PARADA FRECUENTE
137
9.11.5.
PARADAS EXISTENTES
138
9.12.
ANEXO L
139
5.8.1
CASO 1: Cédula Incorrecta
140
5.8.2
CASO 2: Cédula Correcta NO existente en el Store
140
5.8.3
CASO 3: Cambiar Parada Frecuente y Vivienda
144
9.13.
ANEXO M - PAPER
145
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
ÍNDICE DE FIGURAS
Figura 1: Linked Open Data Cloud
Figura 2: Tabla de la BD Relacional
Figura 3: Extracto de Vocabulario - RDFs
Figura 4: Vocabulario - Esquema Preliminar
Figura 5: Vocabulario – Esquema Final
Figura 6: Relaciones Binarios
Figura 7: Diagrama RDF – Vocabulario: Generado con el plugin OntoGraf de Protégé
Figura 8: Instancias de Prueba
Figura 9: URIs for Vocabularies
Figura 10: Partes de una PURL
Figura 11: Funcionamiento de Server PURL
Figura 12: Content Negotiation - Archivo RDF
Figura 13: Content Negotiation - Archivo HTML
Figura 14: Interfaz del servicio VAPOUR
Figura 15: Resumen de Validación – VAPOUR
Figura 16: Diagrama ER – IRBU
Figura 17: Extracto del archivo OWL de salida
Figura 18: EndPoint generado por Virtuoso
Figura 19: Caracteres codificados
Figura 20: Usuarios Virtuoso Server
Figura 21: Roles Virtuoso Server
Figura 22: Error de Privilegios
Figura 23: Creación de Usuario
Figura 24: Servidor de Autentificación
Figura 25: Editor VoID - DERI
Figura 26: Servidor REST – POIS
Figura 27: Estructura función – Server REST
Figura 28: Correspondencia de Parámetros
Figura 29: Parámetro Opcional
Figura 30: Directorio Servidor Apache
Figura 31: Desplazamiento e inserción de Parada
Figura 32: Desplazamiento y eliminación de Parada
Figura 33: Doble codificación de una URL
Figura 34: Petición HTTP – ExtJs
Figura 35: Documentación Generada con OWLDoc
Figura 36: Registro Server PURL OCLC
Figura 37: Registro de Dominio - PURL
Figura 38: Registro de PURL Individual
Figura 39: Instalación PURL - Wizard
6
9
21
22
23
24
25
27
33
36
37
39
40
41
42
44
45
46
49
50
50
51
52
53
55
59
60
61
61
62
64
65
66
69
80
82
83
83
85
Cúmar Ramiro Cueva Tacuri
1
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 40: Instalación PURL – Especificación de BackEnd
Figura 41: Instalación PURL – Permisos
Figura 42: PURL – Interfaz Principal
Figura 43: PURL – Creación de Dominio Público
Figura 44: PURL – Creación de Dirección
Figura 45: Estructura de Directorios
Figura 46: URI y parámetros – VAPOUR
Figura 47: Petición RDF/XML – VAPOUR
Figura 48: Sin ‘Content Negotiation’ - VAPOUR
Figura 49: Class - Petición RDF/XML – VAPOUR
Figura 50: Class - Sin 'Content Negotiation' - VAPOUR
Figura 51: Property - RDF/XML – VAPOUR
Figura 52: Property - Sin 'Content Negotiation' - VAPOUR
Figura 53: Interfaz Principal
Figura 54: Interfaz de Administración - CONDUCTOR
Figura 55: Carga de Archivo OWL
Figura 56: Grafo Creado
Figura 57: Verificación de Tripletas
Figura 58: Mensaje de Error al ingresar una cédula incorrecta,
Figura 59: Mensaje para ingresar un nuevo individuo.
Figura 60: Mensaje de bienvenida.
Figura 61: Aviso de Selección
Figura 62: Formulario sobre Vivienda
Figura 63: Información sobre Vivienda
Figura 64: Selección de Parada Frecuente
Figura 65: Información sobre Parada
Figura 66: Capas visibles
Figura 67: Peticiones REST
86
86
87
87
88
91
94
95
95
96
96
97
97
100
100
103
103
104
140
140
140
141
141
142
142
143
143
144
Cúmar Ramiro Cueva Tacuri
2
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
ÍNDICE DE TABLAS
Tabla 1: Stores y Métodos de Actualización
Tabla 2: Resultados Benchmarking
Tabla 3: Atributos de un POI de categoría ‘Clínica’ en dos entornos diferentes
Tabla 4: Preguntas Base para Generación de Vocabulario
Tabla 5: Elementos del Vocabulario
Tabla 6: Uri’s de Vocabulario
Tabla 7: Prefijos de Individuos
Tabla 8: Formatos de Respuesta
Tabla 9: Lista de parámetros
Tabla 10: Métodos HTTP - CRUD
Tabla 11: Frameworks REST
8
10
13
18
19
35
44
47
47
57
57
Cúmar Ramiro Cueva Tacuri
3
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
1. ESTADO DEL ARTE
Linked Data y su aplicación en sistemas de puntos de interés
georeferenciados y mecanismos de actualización de información
almacenada en un RDFStore
1.1.Introducción
El crecimiento de Internet en los últimos años, tomando como punto de referencia
América del Sur, demuestra que el índice de penetración es considerablemente mayor al
del resto de los continentes[1] lo que permite tener una perspectiva que apunta a que
Internet es cada vez una red de tal magnitud que se expande a través del globo.
Con este avance considerable de la red, el paradigma de la información y comunicación
se mantienen en igual forma sin alteraciones, donde podemos navegar a través de una
vasta cantidad de información y movilizarlos de una página a otra por medio de
interconexiones también llamadas Hyperlink1, los cuales a medida que avanzamos traen
hacia nosotros gran cantidad de contenido. Esto demuestra que la web se basa en la
visualización de información, puesto que su base es HTTP2, lo cual viene a ser un aspecto
muy útil para que las personas podamos comprender lo que se muestra, pero por otro
lado, solo se tiene enlaces externos o documentos aislados, cuya relación no constituye
mayor información.
La estructura manejada por la información en internet nos lleva a tener un espacio,
donde para llegar a la información que verdaderamente requerimos, sea necesario
recorrer gran cantidad de información poco relevante hasta poder llegar a nuestro
objetivo, esto debido a que los enlaces entre las páginas no son más que eso 'enlaces'
entre documentos estáticos que no aportan más que visualización para su
entendimiento, donde el usuario puede recorrer a través de un navegador web. En
cambio, los buscadores indexan toda la masa de datos analizando su contenido para
brindar al usuario una alternativa rápida a lo que intenta localizar.
El creador del internet, Tim Berners-Lee, sostiene la idea de que la información
contenida en recursos estáticos (documentos HTML) no es suficiente para el objetivo de
internet, lo que hace pensar en una forma en que los contenidos sean quienes se
vinculen a otros para generar solo información valiosa que a su vez pueda llevar a otro
tipo de información que de alguna manera está vinculada. Este concepto es conocido
1
w3schools.com. HTML Links. http://www.w3schools.com/html/html_links.asp
RFC2616
2
Cúmar Ramiro Cueva Tacuri
4
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
como Linked Data [2], el mismo que será tratado en el apartado 1.2.
A medida que los servicios dentro de internet se expanden, aparecen servicios que
escapan del esquema tradicional, uno de ellos es el servicio desarrollado a partir del
posicionamiento global (GPS) también conocidos como Location-BasedService (LBS). La
popularización de dispositivos gps integrados y de la tecnología asistida (a-gps), ha
permitido que la cantidad de usuarios crezca y se convierta en un mercado explotable.
Muestras de esto se pueden apreciar en aplicaciones que intentan aprovechar las
ventajas de estos dispositivos integrados en los teléfonos móviles principalmente, entre
ellas están Pocket Life3, Stuck4 y Waze5.
Las posibilidad que giran en torno a la geolocalización son variadas, estas se basan desde
la visualización en real-time de determinados elementos sobre un mapa georeferenciado
hasta la interacción con otros usuarios. Dentro de estos servicios también se enmarca un
concepto conocido como Puntos de Interés (PoI) [3] que será descrito en el apartado 1.4.
1.2. Linked Data
La web está conformada por información en gran cantidad, la forma tradicional de
publicar datos en la web de forma masiva se basa en formatos como csv, xml y el propio
HTML, esto limita la estructura y semántica de los datos, puesto que estos formatos no
fueron vistos como mecanismos de enlaces entre ellos, sino más bien como formas de
intercambio de información. De tal forma que un enlace dentro de un documento
(hyperlink) no representa suficiente descripción sobre el documento al cual se enlaza, lo
que dificulta de sobre manera el saber si la información contenida en él, es lo
suficientemente relevante como para ser visitado.
Esto ha llevado a tener una visión más amplia de la web, a visualizarla como un espacio
global en donde documentos y datos sean vinculados de tal manera que el acceso a ellos
genere un beneficio adicional, el conocimiento.
Linked Data, se basa en la ideología de conservar un conjunto de mejores prácticas para
hacer que el contenido de la web sea público y mantenga conexión entre sí, para ello sus
lineamientos radican en los siguientes 4 estamentos definidos por Tim Berners-Lee
(2006) los mismos que consisten en:
Usar URIs6 para nombrar las cosas.
Usar URIs HTTP.
3
http://www.pocketlife.com
http://www.swiftcover.com/stuck-iphone-app/
5
http://world.waze.com/
6
RFC3986
4
Cúmar Ramiro Cueva Tacuri
5
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Ofrecer información sobre los recursos mediante estándares (RDF, SPARQL)
Incluir enlaces a otras URIS, que permita descubrir más cosas.
Tomando estos principios se puede hacer una calificación de la calidad de nuestros datos
en torno a la perspectiva de Linked Data [6]:
1. Los datos se encuentra en la red (en cualquier formato), pero con una licencia
abierta.
2. Hacerlos disponibles como datos estructurados (ej. Excel en lugar de una
imagen)
3. Usar formatos no-propietarios (ej. csv en lugar de Excel)
4. Usar URLs para identificar cosas, así las personas pueden enlazarte.
5. Enlazar sus datos a los datos de otras personas para proporcionar un contexto.
Este tipo de calificativo es conocido como un entorno 5 estrellas. La idea que se persigue
es publicar datos de forma estandarizada, uniforme y mediante una forma genérica de
consumo. Desde el lanzamiento de estos principios el trabajo en Linked Data ha llevado a
que gran cantidad de datos sean colocados de manera pública y bajo un estándar en la
nube conocida como Linked Open Data la misma que se muestra en la Figura 1, cuya
última actualización es a Septiembre del 2010.
Figura 1: Linked Open Data Cloud
7
La aplicabilidad de Linked Data en la web transforma el paradigma de una web de
7
http://www.w3.org/wiki/SweoIG/TaskForces/CommunityProjects/LinkingOpenData
Cúmar Ramiro Cueva Tacuri
6
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
documentos a una web de cosas, donde se pueden determinar y reconocer las relaciones
entre estas. Para ello Linked Data utiliza el estándar de representación conocido bajo el
nombre de RDF. El mismo que hace posible esta relación de los datos y la transición
hacia un web de cosas [4].
Este modelo para el intercambio de datos en la web, se destaca por ser directo,
etiquetado y toda su estructura está basada en grafos, cuyo elemento principal son las
URI’s. Su base para realizar estas relaciones se basa en la estructura Triple que maneja
RDF también conocida como Tripletas.
Las propiedades en las que se basa el esquema RDF es conocido como Vocabulario, pero
para definirlo es necesario utilizar una extensión semántica conocida bajo el estándar de
RDFSchema [5] el mismo que es propuesto por la W3C. Esta extensión de RDF es
utilizada para describir clases (similares a las utilizadas en POO), propiedades y otros
recursos que pueden ser descritos, con eso se obtienen recursos agrupados en
categorías similares.
Debido a sus beneficios RDF se ha convertido en la web actual, en el formato en que
están escritos los datos. [6]
1.3.RDFStore
Esta información transformada a tripletas, las mismas que crean enlaces entre ‘cosas’
manteniendo el principio de Linked Data, necesitan, al igual que los datos relaciones
normales, un almacén de datos donde puedan ser guardadas y consultadas.
Lo que comúnmente se conoce en los ambientes relaciones como Base de Datos, dentro
de Linked data, el almacenamiento de tripletas es conocido bajo el nombre de RDFStore.
Estos son sistemas específicos para el almacenamiento de Grafos RDF, estos Stores
proporcionan mecanismos de backend para la extracción y almacenaje de información. El
estándar propuesto para este propósito por la W3C es SPARQL [7].
Aunque SPARQL fue definido por la W3C, cada Store implementa variaciones de este
adaptadas a sus entornos, posee una sintaxis similar a la utilizada por SQL, pero con
mayores ventajas como la recuperación de datos almacenados en localidades diferentes
(locales - remotas) así como de almacenes heterogéneos, esto debido a que SPARQL ha
sido pensado específicamente para el trabajo con Grafos RDF.
Cúmar Ramiro Cueva Tacuri
7
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
1.3.1. Sparql Update
Si bien SPARQL es el estándar de consulta para la extracción de datos del
RDFStore, para el proceso de realizar las operaciones restantes CRUD
(CreateReadUpdateDelete) sobre los grafos almacenados, se ha motivado la
tendencia a utilizar el lenguaje de actualización conocido como SPARQL/UPDATE,
el mismo que inició de la aportación de miembros de la compañía HewlettPackard8 y que la W3C ha acogido para crear un borrador [11] orientándolo a ser
definido como un estándar de la mano de SPARQL. Algunos de los almacenes de
RDF que implementan esta solución pueden ser observados en la Tabla 1.
Las facilidades que Sparql 1.1 Update presenta, se basan en permitir:
-
Insertar nuevas tripletas en un grafo RDF.
Eliminar tripletas de un grafo RDF.
Llevar a cabo un conjunto de operaciones de actualización en una sola acción.
Crear un nuevo grafo RDF en un RDFStore
Eliminar un grafo RDF en un RDFStore
Además de poseer una sintaxis similar a la utilizada por SPARQL, lo que permite
tener una curva de aprendizaje menor, facilitando la interacción.
RDFStore
4store9
BigData10
BigOwlim11
TDB12
Virtuoso14
AllegroGraph15
Sesame16
Método de Actualización
SPARQLUpdate
SPARQLUpdate
SPARQLUpdate(mediante Fuseki)
SPARQLUpdate(mediante Jena13)
SPARQLUpdate
SPARQLUpdate
API Nativo
Tabla 1: Stores y Métodos de Actualización
La eficiencia y rendimiento de varios de estos RDFStores ha sido evaluada por el
Equipo de la Universidad de Berlín SPARQLBenchmark, basándose en la utilización
8
http://www.w3.org/Submission/SPARQL-Update/
http://4store.org/
10
http://www.systap.com/bigdata.htm
11
http://www.ontotext.com/owlim/big/
12
http://www.openjena.org/wiki/TDB
13
http://jena.sourceforge.net/
14
http://virtuoso.openlinksw.com/
15
http://www.franz.com/agraph/allegrograph/
16
http://www.openrdf.org/
9
Cúmar Ramiro Cueva Tacuri
8
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
de conjuntos de datos de entre 100 y 200 millones de tripletas, el análisis y los
resultados se pueden encontrar publicados en la red17.
1.3.2. SPARUL y El Proceso Asistido de Actualización
Otros mecanismos utilizados para la actualización de datos se basan en la
construcción de sistemas intermedios utilizados como puentes para la
transformación de la información, en la mayoría son sistemas de bases de datos
relacionales.
Existe otro método implementado en la extracción de datos desde Wikipedia
conocido como DBPedia Live [12] en donde se distinguen 3 tipos de actualización.
La primera es la actualización basada en SPARUL sobre un mismo gráfoRDF, la
segunda mencionada es sobre distintos grafos, al igual que la anterior basándose
en SPARUL. Mientras que la tercera es una mezcla entre SPARUL y una Base de
Datos Relacional. Este proceso es conocido como “RDBassistedupdateprocess”.
Si bien estos dos métodos implican cambios en el RDFStore, el utilizar SPARUL de
forma aislada conlleva la utilización de acciones complejas para realizar una
determinada actualización sobre el Store puesto que, como se mencionó
anteriormente, las tripletas conforman un grafo relacionado.
En cambio, el proceso asistido para la actualización, utiliza una tabla relacional
para representar las tripletas existentes, de tal forma que puedan ser recuperadas
y analizadas para determinar los cambios que deben ser llevados a cabo sobre el
RDFStore. Los datos de las tripletas son almacenados de forma serializada en un
objeto JSON para su posterior comparación.
Un esquema de la forma en que los datos se almacenan en la Base Relacional
puede ser apreciado en la Figura 2.
Figura 2: Tabla de la BD Relacional
17
http://www4.wiwiss.fu-berlin.de/bizer/BerlinSPARQLBenchmark/results/V6/index.html
Cúmar Ramiro Cueva Tacuri
9
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
La principal diferencia entre estas dos formas de actualización radica en la
complejidad que adquiere SPARUL, con la utilización de un Base de Datos
Relacional esto se reduce significativamente de tal forma que las sentencias y
operaciones realizadas por SPARUL luego de este proceso es mínima.
El rendimiento de cada uno de estos métodos ha sido evaluado por el equipo de
la Universidad Leipzing, los cuales han obtenido un conjunto de métricas que se
pueden observar en la Tabla 2.
p
Added
Removed
Retained
Strategy
SQL
RDF
SQL
RDF
SQL
RDF
0.5
124924
124937
123319
0.8
79605
79710
318149
0.9
44629
44554
402748
Tabla 2: Resultados Benchmarking
Time
taken
(sec)
240
200
200
250
170
300
18
Debido a que estos métodos son utilizado para la actualización de contenido en
DBPedia, la medición fue realizada para simular cambios en 5000 recursos
distintos, por cada uno de estos se considera los conjuntos N y O los mismos que
hacen referencia al antes y después de la modificación de esa tripleta, la magnitud
del cambio realizado se basa en el porcentaje p. Donde ha tenido una variación de
p=0.9, p=0.8, p=0.5 correspondientes a un cambio del 10%, 20%, 50% de la
tripleta respectivamente.
En base a estos dos conjuntos se puede determinar la cantidad de tripletas
removidas (O – N), añadidas (N – O) y mantenidas (N O). Además, de estas
consideraciones la comparativa fue ejecutada sobre el RDFStore de Virtuoso.
La tabla muestra la eficiencia de la solución basada en un entorno de Base de
Datos Relacional cuando existe un solapamiento suficiente entre los conjuntos O y
N (p=0.9, p=0.8). A diferencia del caso en que existe menor solapamiento, en
donde la solución RDF tiene mejor desempeño (p=0.5), esto debido al costo
adicional de comparativas frente a la cantidad de tripletas que debe eliminar e
insertar.
Esta comparativa basada en la estructura de DBPedia permite apreciar que para
18
Universidad Leipzig (Alemania): Update Strategies for DBpedia Live
Cúmar Ramiro Cueva Tacuri
10
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
ambientes donde los UPDATES al RDFStore son frecuentes y los mismos
involucran un cambio mínimo en la estructura de las tripletas, una solución
basada en la utilización de una Base Relacional presenta ventajas, frente a la
utilización de la solución SPARUL por sí sola. Esto basado en que la solución con
SPARUL necesita de la utilización de FILTROS que ralentizan la búsqueda y además
de ignorar la duplicación de datos que se realiza en la Base Relacional.
1.4. Puntos de Interés
La creación de Point of Interests (POI), han sido un elemento relevante en la evolución de
las redes sociales basadas en geolocalización, estos consisten en la localización de un
punto específico sobre un mapa, el mismo que puede resultar de importancia para otras
personas19.
Su utilidad es variada, puesto que se puede considerar a prácticamente cualquier ‘cosa’
que pueda ser ubicada por una coordenada geográfica un punto de utilidad, como
Supermercados, Escuelas e incluso paradas de buses o domicilios de personas, tema
sobre el cual se desarrolla la plataforma Points of Interesting Semantic(POIS).
A medida que la información geográfica ha sido accesible y manejable, los POIs han
constituido el pilar fundamental, puesto que desde tiempo atrás se ha venido explotando
de forma no dirigida estas oportunidades, así existen utilidades capaces de brindar
información sobre determinados sitios de interés a usuarios, muchos de ellos vía web y
otros creados para dispositivos específicos20. La mayor parte de estos están orientados al
sector hotelero y turístico, basándose en información manejada por el sector público
para la categorización.
El transportar esta información a la web permite que sea manejada por los usuarios,
logrando que ellos sean quienes realicen su clasificación, permitiendo tener así una
visión más clara de lo que resulta de ‘interés’, esto mediante la utilización de métodos de
categorización basados en rankings asignados por los mismos usuarios.
Fabricantes de dispositivos de navegación los han venido incluyendo como valor añadido
a sus productos para brindar al usuario una experiencia basada en información, uno de
ellos es el fabricante Garmin21 para cuyos dispositivos existe una gama muy amplia de
POIs, que pueden ser obtenidos de forma gratuita o mediante pago.
Con relación a servicios de POIs basados en internet, el principal exponente de su uso y
19
http://en.wikipedia.org/wiki/Point_of_interest
http://www8.garmin.com/products/poiloader/
21
http://www.garmin.com
20
Cúmar Ramiro Cueva Tacuri
11
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
utilidad es Google con su iniciativa Maps22, la misma que permite la visualización de
información en forma de POIs basados en una determina posición geográfica,
principalmente orientado a mostrar información en tiempo real sobre el tráfico. El punto
de partida para la creación de estos POIs es mediante la aplicación MapMaker23 en
donde se puede apreciar la categorización existente para los diferentes puntos.
La información que se maneja sobre cada punto de interés varía de un proveedor a otro,
en este caso GPS-WAYPOINTS 24 realiza la categorización de los POIs utilizando
agrupaciones en subcategorías que permiten al usuario encontrar de forma rápida los
elementos de interés y permitiendo agrupar atributos comunes. En cambio MapMaker
de Google ofrece una gran cantidad de categorías de POIs específicas, sin utilizar subcategorías directamente. Otros proveedores como GeoTourGuide25 y Geovative26, llevan
el concepto de POI un nivel más arriba incluyendo en ellos elementos multimedia para
brindar información audiovisual de sitios de interés localizados geográficamente.
Una comparativa entre los atributos que cada proveedor maneja se puede apreciar en la
Tabla 3 donde se describen los atributos de un POI bajo la categoría de ‘clínica’ en los
entornos GPS-WAYPOINTS y MapMaker. Como se puede apreciar, la alternativa de
Google maneja gran cantidad de atributos relacionados a esta categoría específica de
POI, lo que da una visión muy clara de la representación de los atributos que un POI de
igual categoría puede tener en dos diferentes servicios.
GPS-WAYPOINTS
Latitud
Longitud
Altitud
Nombre
Descripción
País
Localización
Límite de Velocidad
Dirección
Teléfono
URL
MapMaker
Latitud
Longitud
Nombre
Idioma
Tipo
Nombre
Atributos
Categoría
Precisión
Popularidad
Categorías Adicionales
Horas Laborables
Métodos de Pago
URL de foto
Dirección
Parcela#
Calle
Información de Contacto
22
http://maps.google.com/maps
http://www.google.com/mapmaker
24
http://www.gps-waypoints.net
25
http://www.GeoTourGuide.com
26
http://www.geovative.com/
23
Cúmar Ramiro Cueva Tacuri
12
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Sitio Web
Correo Electrónico
Teléfono
Fax Móvil
Descripción
Información de Ubicación
Sublocalidad
Localidad
Ciudad
Distrito/Condado
Estado/provincia
Código postal
Tabla 3: Atributos de un POI de categoría ‘Clínica’ en dos entornos diferentes
Con la definición de Linked Data, la creación de POIs es un tema central, puesto que
estos constituyen una puerta de entrada hacia información contenida en diferentes
medios pero que se encuentra enlazada con el POI inicial, con ello, se obtiene
información específica de gran utilidad partiendo de un mismo inicio, todo esto
dependiendo de la definición que se haya dado en el vocabulario para la estructura RDF
que será almacenada en el RDFStore.
1.5. Trabajo Relacionado
Actualmente la integración de estos POIs al concepto de web semántica, basándose en
Linked Data, se puede ver reflejado en varios trabajos, como el realizado por el equipo de
DBPedia para crear DBPediaMobile27 y el trabajo realizado en la universidad de KoblenzLandau, donde se ha creado la propuesta de un entorno de puntos de interés capaz de
permitir la interacción entre usuarios en un entorno colaborativo basado en POIs [13].
DBPediaMobile, tiene como principio ser una solución móvil para la exploración de los
datos extraídos por DBPedia basándose en una aplicación LBS. Presentando información
geolocalizada y relevante en forma de POIs al usuario, permitiendo hacer una
exploración del espacio geográfico de forma interactiva. Siguiendo este mismo principio,
la iniciativa de la Universidad de Koblenz-Landau, se basa en la creación de un sistema
capaz de permitir a los usuarios de forma colaborativa crear, compartir y modificar
puntos de interés mediante la utilización de un programa cliente. Además de
proporcionar un mecanismo de revisión capaz de identificar diferentes Puntos de Interés
que han sido puestos por los usuarios pero que hacen referencia a un mismo sitio, para
ser agrupados en uno solo, formando así una herramienta de colaboración asistida.
La iniciativa de vincular información geográfica con datos de forma enlazada, o más
27
http://wiki.dbpedia.org/DBpediaMobile
Cúmar Ramiro Cueva Tacuri
13
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
explícitamente añadir una dimensión espacial a la web de datos, empezó con la iniciativa
planteada por la Universidad de Leipzig denominada LInkedGeoData 28 , la cual se
encuentra enmarcada dentro de la nube de Linked Open Data. Esta iniciativa se enmarca
en utilizar los datos recolectados por el proyecto libre OpenStreetMap29 y ser expresados
en formato RDF, de tal forma que la información geográfica sea enlazada a fuentes
externas y tenga acceso público.
Otra Universidad vinculada a la iniciativa de POIs a través de LinkedData es la
Universidad de Southampton en el Reino Unido, la misma que contiene un conjunto de
Datasets sobre información variada y entre ellos uno bajo el nombre de Open Data
Map30 que ubica diversos Puntos de Interés sobre un mapa georeferenciado.
Como se menciona, la aplicabilidad de los puntos de interés al sector turístico es el
principal punto de partida, tomando como punto de referencia el caso de estudio sobre
CRUZAR31. Se puede observar como las preferencias de los usuarios pueden ser tomadas
en cuenta para determinar puntos de interés basados en perfiles de usuario. Con esto se
logra que la información contenida en los puntos de interés no sea visualizada de forma
estática sino de acuerdo a preferencias, lo que convierte a los puntos de interés en
elemento principal de la construcción de rutas dinámicas interactivas bajo preferencias
de usuario. A diferencia de los folletos genéricos que pueden ser encontrados en la
mayoría de recorridos turísticos.
Otra aplicabilidad de los puntos de interés es el análisis, puesto que los puntos de interés
se encuentran enmarcados bajo una localización geográfica, es de fácil análisis el
determinar la concentración de puntos bajo un criterio en un determinado lugar, lo que
incrementa de forma sustancial la toma de decisiones en diversos campos. E incluso
pueden ser agrupados en base a criterios para ser evaluados o examinados.
La tarea de representar los POIs en Linked Data se realiza en base a la definición de un
vocabulario, pero debido a la variedad y diferentes usos que tienen, no existe un
estándar para su representación, puesto que diferentes POIs manejan diferentes
atributos como se menciona en [14].
El intento por crear Vocabularios que describan Puntos de Interés así como otros
aspectos ha llevado a realizar avances como:
Basic RDF Geo Vocabulary32, el mismo que consiste de los elementos básicos
para representar un POI como es Latitud, Longitud y Altitud.
GeoOnionVocabulary33, Se basa en el esquema del vocabulario anterior, pero
28
http://linkedgeodata.org/About
http://www.openstreetmap.org/
30
http://opendatamap.ecs.soton.ac.uk/
31
http://www.w3.org/2001/sw/sweo/public/UseCases/Zaragoza-2/
32
http://www.w3.org/2003/01/geo/#vocabulary
29
33
http://www.w3.org/wiki/GeoOnion
Cúmar Ramiro Cueva Tacuri
14
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
orientado a la descripción de elementos en relación de distancia con otros.
LGDVocabulary34, que es la base del proyecto Linked Geo Data para describir
puntos geográficos, manteniendo información sobre localización, datos
referentes a una posición, características del sitio como religión, aparcamiento,
altitud y una categoría.
GoodRelations35, orientado al E-Commerce permite describir productos y sus
propiedades asociadas como valor, información sobre el sitio de venta, detalles
de garantía, datos de la institución y otros.
csxPOISystem[13], utiliza un vocabulario capaz de clasificar a los puntos de
interés en categorías como ‘monumento’ las mismas que pueden pertenecer o
tener subcategorías, lo que permite realizar interrelaciones entre ellas, donde
cada categoría posee un conjunto de características.
Aunque la existencia de un Vocabulario común para la representación de POIs es aún un
tema de discusión como se mencionó, la información contenida en aplicaciones que
utilizan Puntos de Interés no semánticos y los vocabularios específicos que actualmente
existen en Linked Data permiten tener una perspectiva global de los aspectos que se
deben considerar para el planteamiento del vocabulario para el proyecto POIS.
En la actualidad existe un grupo que forma parte de la W3C bajo el nombre de "Points of
InterestWorkingGroup"36 que fue lanzado el 30 Septiembre del 2010 y uno de sus fines es
desarrollar especificaciones técnicas para la representación de "Puntos de Interés" como
información para la web creando una recomendación de Vocabulario para POIs, la fecha
preliminar de su lanzamiento está prevista para Abril del 2011.
El crecimiento y aplicabilidad de POIs junto a Linked data está en aumento, puesto que
cada vez más las redes sociales incorporan características de geolocalización para sus
usuarios y los dispositivos de localización son cada vez más accesibles.
1.6. Trabajo futuro
La construcción de la plataforma Points of Interesting Semantic(POIS) como proyecto
basado en Linked Data, tiene como objetivos la implementación de un Vocabulario
genérico para la representación de Puntos de Interés, buscando ser lo más genérico
posible capaz de englobar un sin número de categorías que pueden ser agregadas en un
futuro.
Así, este vocabulario será implementado en POIS para la representación de un
34
http://linkedgeodata.org/vocabulary
http://www.heppnetz.de/ontologies/goodrelations/v1
36
http://www.w3.org/2010/POI/charter/
35
Cúmar Ramiro Cueva Tacuri
15
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
determinado tipo de POIs, en este caso, las paradas realizadas por los Buses de la
Universidad Técnica Particular de Loja y la ubicación de la vivienda y la parada más
frecuente, de los estudiantes pertenecientes a la misma.
Esto contribuirá a la iniciativa de mantener información relacionada a la Universidad en
formato accesible a través de LinkedData en este caso RDF.
La prueba de concepto sobre la representación de estos datos en RDF y su consumo, será
basada en una aplicación Web que implemente un servicio de consulta capaz de permitir
al usuario obtener los horarios de los recorridos de los buses según su parada habitual,
definida previamente, para ello la aplicación permitirá que el usuario registre la posición
de su domicilio.
Además, se considerará la creación de un mecanismo de creación/actualización para la
información almacenada en un RDFStore.
Cúmar Ramiro Cueva Tacuri
16
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
2. VOCABULARIO RDF
2.1.Construcción
La creación del Vocabulario bajo la sintaxis RDF, permitirá definir el lineamiento principal
de la plataforma POIS. Para este fin se hará uso de la herramienta Protégé 4.x37, puesto
que presta de gran aceptación en los ambientes de trabajo semántico por su flexibilidad
y gran cantidad de funcionalidades.
2.1.1. Selección de Elementos Preliminares y Formulación de
Interrogantes
La construcción del vocabulario para la plataforma POIS, deberá cumplir como
objetivo principal, el ser capaz de expresar y representar las paradas de buses de
la UTPL como un punto de interés (POI). Además, de permitir la representación de
Puntos de Interés de diferente índole, tales como Parques, lugares turísticos o
edificios emblemáticos.
La Tabla 4 agrupa un conjunto de elementos y preguntas, a través de los cuales se
generará el vocabulario para la plataforma POIS.
COD
INTERROGANTE
IMPORTANCIA
IT1 A una hora Y que Rutas existen.
ALTA
IT2 Cuáles son las paradas de la Calle X.
ALTA
IT3 Cuáles son las paradas de una Ruta X.
ALTA
IT4 Cuantas paradas realiza una Ruta X.
ALTA
RECORRIDOS
Que rutas [bajan | suben | suben o bajan] de la
Universidad
ALTA
IT6 Que rutas pasan por la Parada X [a una Hora Y].
ALTA
IT5
IT11
37
[Cuales | Cuantos] barrios no poseen paradas de los
buses de la UTPL.
MEDIA
http://protege.stanford.edu/
Cúmar Ramiro Cueva Tacuri
17
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
A una hora X que Ruta debo elegir para [ subir a|
IT12 bajar de ] la UTPL -- Considerando la Parada
Frecuente de un Estudiante
IT15
ESTUDIANTE
Cuál es la parada de la Ruta X que se localiza más
cerca de mi casa
MEDIA
ALTA
IT7 Que estudiante posee la cedula X
ALTA
IT8 Cuál es la parada más frecuente de un estudiante X
ALTA
IT13
Cuál es el [ barrio | sector ] con mayor número de
estudiantes
MEDIA
IT14
Cuantos estudiantes toman el bus de la UTPL en el [
sector | barrio ] X
MEDIA
IT9
Cuáles son los POIs que se encuentran más cercanos
del Punto Y.
ALTA
[Cuantos | Cuales] POIs X contienen un nombre con X
características
ALTA
GENÉRICOS IT10
IT16
Cuál es el [ barrio | sector ] donde se ubican mayor
cantidad de POIs
MEDIA
Tabla 4: Preguntas Base para Generación de Vocabulario
2.1.2. Definición de Elementos Finales y sus Atributos
Elemento
Atributos
Anotaciones
Interrogantes
Nombre
Tipo
Ruta
Horario
Fecha
IT1 | IT5 | IT15
Dato de creación
Activa
Parada
Cúmar Ramiro Cueva Tacuri
Calle Principal
IT2 | IT3 | IT4 | IT6
18
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Calle Secundaria
Imagen
| IT12
Dirección de la Img
Lat
Lon
Pertenece_A_Ruta
Referencia
Activa
Cedula
Estudiante Parada_Frecuente
Vivienda
IT7 | IT8 | IT13
Dato geográfico
Nombre
Lat
Lon
Calle Principal
IT9 | IT10 | IT11 |
IT14 | IT16
Genérico
Calle Secundaria
Sector
Barrio
Fecha
Dato de creación
Tabla 5: Elementos del Vocabulario
2.1.3. Estructura de Vocabulario
La construcción del vocabulario a partir de otros ya existentes (reutilización) se
constituye en uno de los pilares fundamentales de LOD, de tal manera que
elementos que ya pertenecen a un vocabulario no sean nuevamente definidos.
Cúmar Ramiro Cueva Tacuri
19
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
En el vocabulario para la plataforma POIS, debido a la información a representar
que involucran los Puntos de Interés solamente es posible la reutilización del
vocabulario Basic Geo38, el mismo que establece una representación de puntos
geográficos basándose en los atributos lon (longitud) y lat (latitud) de una
coordenada geográfica, ignorando del mismo el atributo altitud.
Vocabularios ampliamente utilizados en diferentes ambientes como Doublin
Core39 o FOAF40, no formarán parte de la Plataforma por no tener relación con la
información manejada.
2.1.3.1.
Consideraciones de Nomenclatura
Los diagramas de vocabulario, como su posterior implementación sobre
RDF mantendrán el siguiente estándar de nomenclatura, lo que facilitará
el establecer relaciones entre los mismos:
Los conceptos serán nombrados en letras mayúsculas.
Las Propiedades Objeto serán nombradas en singular utilizando
notación CamelCase41.
Las Propiedades de Datos serán nombradas en singular y en letras
minúsculas, si contiene dos palabras serán separadas por un guión.
2.1.3.2.
Descripción de Conceptos
2.1.3.2.1. RUTA
Concepto para la representación de información relativa a una ruta
concreta. En la actualidad, en el sistema de transportación estudiantil
de la UTPL, cada ruta es nombrada en base a las calles por las que la
unidad de transporte realiza las paradas, y en ocasiones el barrio.
De esta forma las Rutas poseen nombres de sintaxis similar a:
“Av. Manuel Agustín Aguirre y Mercadillo”.
2.1.3.2.2. PARADA
Constituyen cada uno de los puntos geográficos que identifican los
sitios donde los buses de la UTPL, se detienen dentro de una RUTA.
38
http://www.w3.org/2003/01/geo/wgs84_pos#
http://purl.org/dc/elements/1.1
40
http://xmlns.com/foaf/0.1/
41
http://es.wikipedia.org/wiki/CamelCase
39
Cúmar Ramiro Cueva Tacuri
20
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
2.1.3.2.3. ESTUDIANTE
Considerado un usuario del sistema de transportación estudiantil de
la UTPL, el mismo que posee preferencias en cuanto a su PARADA y
vivienda.
2.1.3.2.4. POIG
Un punto de Interés genérico capaz de representar otros elementos
de forma directa.
2.1.3.2.5. ORDEN PARADA
Debido a que el actual sistema de transportación estudiantil involucra
RUTAS y PARADAS, a su vez estas siguen una secuencia determinada,
el conocimiento de esta secuencia, permitirá tanto el tratamiento de
las PARADAS en orden, como la determinación de la PARADA INICIAL
y FINAL del recorrido.
2.1.3.2.6. PARADA FRECUENTE
El enlace entre el estudiante y su parada seleccionada como
preferida, que permite mantener un historial de selecciones, puesto
que contiene una propiedad de fecha.
Figura 3: Extracto de Vocabulario - RDFs
Cúmar Ramiro Cueva Tacuri
21
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
2.1.3.3.
Esquema Preliminar
Figura 4: Vocabulario - Esquema Preliminar
Cúmar Ramiro Cueva Tacuri
22
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
2.1.3.4.
Esquema Final
Figura 5: Vocabulario – Esquema Final
Cúmar Ramiro Cueva Tacuri
23
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
2.1.3.5.
Relaciones Binarias
Figura 6: Relaciones Binarios
Cúmar Ramiro Cueva Tacuri
24
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
2.1.3.6.
Diagrama RDF
Basado en el archivo RDF que contiene la estructura del vocabulario, se
puede apreciar en la
Figura 7 el diagrama de relación entre los elementos del mismo.
42
Figura 7: Diagrama RDF – Vocabulario: Generado con el plugin OntoGraf de Protégé
De igual forma se puede generar un diagrama de modelo de datos
mediante el servicio de validación de RDF de la W3C43. Este diagrama
puede ser encontrado en la dirección:
[http://www.box.com/s/g26t41incyzd200ribze ]
2.1.4. Validación del Vocabulario
En base a la construcción del vocabulario, tomando en consideración las
relaciones establecidas entre conceptos, a continuación se demostrará la solución
de las preguntas planteadas en el primer enunciado. Se debe considerar que no
necesariamente todas las preguntas pueden o deben ser resueltas, ya que las
preguntas iníciales son una abstracción general de lo que se intenta abarcar con el
vocabulario.
42
43
http://protegewiki.stanford.edu/wiki/OntoGraf
http://www.w3.org/RDF/Validator/
Cúmar Ramiro Cueva Tacuri
25
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
La comprobación ha sido realizada basada en el lenguaje SPARQL, haciendo uso
de la herramienta de navegación Gruff 44 para AllegroGraph, un almacén de
tripletas, basándose en un archivo RDF para realizar la carga. Cabe recalcar que
Gruff no soporta Sparql 1.1 el cual permite utilizar funciones de agregación, razón
por la cual varias preguntas son omitidas o resueltas parcialmente.
2.1.4.1.
Instancias de Vocabulario
Para la comprobación del vocabulario se trabajará con el siguiente
esquema de instancias del vocabulario, el mismo que está estructurado en
base a las preguntas iniciales.
El vocabulario puede ser descargado en formato RDFs desde la siguiente
dirección:
[ http://www.box.net/shared/88cz8c06ojanjlhs11r6 ]
En apartados siguientes se mencionará la publicación del mismo, tanto en
formato html como rdfs.
44
http://www.franz.com/agraph/gruff/
Cúmar Ramiro Cueva Tacuri
26
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 8: Instancias de Prueba
2.1.4.2. Consultas SPARQL
IT1:: A una hora Y que Rutas Existen
PREFIX pois: <http://localhost/POIS.owl#>
SELECT *
WHERE
{
?Ruta a pois:RUTA.
?Ruta pois:nombre ?NameRuta.
?Ruta pois:horario ?horaRuta.
FILTER( regex(str(?horaRuta), "10:00") )
}
IT2:: Cuales son las paradas de la calle X
PREFIX pois: <http://localhost/POIS.owl#>
SELECT ?Parada ?CallePrincipal ?CalleSecundaria
WHERE
{
?Parada a pois:PARADA.
?Parada pois:LocalizadaEn ?Poig.
Cúmar Ramiro Cueva Tacuri
27
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
?Poig pois:calle1 ?CallePrincipal.
?Poig pois:calle2 ?CalleSecundaria.
FILTER(
regex(str(?CallePrincipal),
Kigman") ||
regex(str(?CalleSecundaria), "Eduardo
)
"Eduardo
Kigman")
}
IT3:: Cuales son las paradas de una Ruta X
IT4:: Cuántas paradas realiza una ruta X
PREFIX pois: <http://localhost/POIS.owl#>
SELECT ?NombreRuta ?RutaXPard ?ordenParada
WHERE
{
?RutaX a pois:RUTA;
pois:nombre ?NombreRuta;
pois:ParadaConOrden ?RutaXPardConst.
?RutaXPardConst pois:num_secuencia ?ordenParada;
pois:ParadaRelacionada ?RutaXPard.
FILTER(
regex(str(?NombreRuta),
"Rosales,
Pradera Catacocha,"))
}
ORDER BY ?ordenParada
IT5:: Que rutas [bajan | suben | suben o bajan] de la Universidad
PREFIX pois: <http://localhost/POIS.owl#>
SELECT ?nombreRuta
WHERE
{
?RutaX a pois:RUTA;
pois:nombre ?nombreRuta.
?RutaX pois:tipo ?SentidoRuta.
FILTER ( ?SentidoRuta = "BAJA")
}
order by ?nombreRuta
IT6:: Qué rutas pasan por la Parada X [a una hora Y]
PREFIX pois: <http://localhost/POIS.owl#>
SELECT ?Num_Parada ?RutaXNombre ?refParada
WHERE
{
?ParadaX a pois:PARADA.
?ParadaX pois:referencia ?refParada.
?RutaX a pois:RUTA;
Cúmar Ramiro Cueva Tacuri
28
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
pois:ParadaConOrden ?RutaXPardConst;
pois:nombre ?RutaXNombre.
?RutaXPardConst
pois:ParadaRelacionada
?RutaXParada;
pois:num_secuencia ?Num_Parada.
FILTER(regex(str(?refParada), "Laguna") &&
?RutaXParada = ?ParadaX )
}
IT7:: Qué estudiante posee la cédula X
PREFIX pois: <http://localhost/POIS.owl#>
SELECT ?EstudianteX
WHERE
{
?EstudianteX a pois:ESTUDIANTE.
?EstudianteX pois:cedula ?cedEstudiante.
FILTER(regex(str(?cedEstudiante), "1104665621"))
}
IT8:: Cuál es la parada más frecuente de una estudiante X.
PREFIX pois: <http://localhost/POIS.owl#>
SELECT ?callePrincipal ?calleSecundaria
WHERE
{
?EstudianteX a pois:ESTUDIANTE.
?EstudianteX pois:cedula ?cedEstudiante.
?EstudianteX pois:Prefiere ?preferEnlace.
?preferEnlace pois:VinculadaA ?PrdPreferida.
?PrdPreferida pois:LocalizadaEn ?poigLoc.
?poigLoc pois:calle1 ?callePrincipal;
pois:calle2 ?calleSecundaria.
FILTER(regex(str(?cedEstudiante), "1104665621"))
}
IT9:: Cuáles son los POIs que se encuentran más cercanos al punto Y.
La definición de 'cercano' es aún imprecisa así como la forma de
determinar distancia entre dos puntos geográficos, por ahora se
simulará asumiendo que esto se basa en estimación de la diferencia
de los valores.
PREFIX pois: <http://localhost/POIS.owl#>
PREFIX
<http://www.w3.org/2003/01/geo/wgs84_pos#>
SELECT *
Cúmar Ramiro Cueva Tacuri
geo:
29
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
WHERE
{
?PuntoInt a pois:POIG.
?PuntoInt pois:CoordenadaGeo ?CoordXY.
?CoordXY geo:lat ?LatPoig;
geo:long ?LonPoig.
FILTER ((?LatPoig>-3.98)&&(?LonPoig<-78.99))
}
IT10:: [Cuantos | Cuales] POIs X contienen un nombre con X
características.
Aplicado solo a elementos que no constituyen una parada, puesto que
las paradas no poseen nombres, solo los puntos genéricos.
PREFIX pois: <http://localhost/POIS.owl#>
SELECT *
WHERE
{
?PuntoInt a pois:POIG.
?PuntoInt pois:nombre ?NamePoig.
FILTER(regex(str(?NamePoig), "abc"))
}
IT11:: [Cuántos | Cuáles] barrios no poseen paradas de los buses de la
UTPL.
Se utilizará una búsqueda basada en el nombre del barrio.
PREFIX pois: <http://localhost/POIS.owl#>
PREFIX
geo:
<http://www.w3.org/2003/01/geo/wgs84_pos#>
SELECT *
WHERE
{
?ParadaX a pois:PARADA;
pois:LocalizadaEn ?Poig.
?Poig pois:barrio ?PoigBarrio.
FILTER(regex(str(?PoigBarrio), "La Pradera"))
}
order by ?ParadaX
IT12:: A una hora X que Ruta debo elegir para [subir a | bajar de] la UTPL
(parada frecuente)
Para considerar la parada frecuente en este resultado, se debería
considerar la implementación de un algoritmo que determine la
proximidad de los resultados a la parada frecuente. Por ahora no se lo
considera.
Cúmar Ramiro Cueva Tacuri
30
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
PREFIX pois: <http://localhost/POIS.owl#>
SELECT ?NombreRuta
WHERE
{
?RutaX a pois:RUTA.
?RutaX pois:tipo ?TipoRuta.
?RutaX pois:horario ?HoraRuta.
?RutaX pois:nombre ?NombreRuta.
FILTER( (?TipoRuta = "BAJA") &&
(regex(str(?HoraRuta), "10:00")) )
}
IT13:: Cuál es el [barrio|sector] con mayor número de estudiantes
Al igual que para dar respuesta a otras interrogantes que hacen
referencia a cantidad, es necesario utilizar funciones de agregación
disponibles en SPARQL 1.1
PREFIX pois: <http://localhost/POIS.owl#>
SELECT ?cedEstd
WHERE
{
?EstdX a pois:ESTUDIANTE.
?EstdX pois:ViveEn ?PoigEstd.
?PoigEstd pois:barrio ?BarrioEstd.
?EstdX pois:cedula ?cedEstd.
FILTER (?BarrioEstd = "Gran Colombia")
}
IT14:: Cuántos estudiantes toman el bus de la UTPL en el [sector | barrio]
X.
PREFIX pois: <http://localhost/POIS.owl#>
SELECT ?CedEstdX
WHERE
{
?EstdX a pois:ESTUDIANTE;
pois:Prefiere ?ParadaF;
pois:cedula ?CedEstdX.
?ParadaF pois:VinculadaA ?ParadaX.
?ParadaX pois:LocalizadaEn ?PoigPrd.
?PoigPrd pois:barrio ?Barrio.
FILTER(?Barrio = "San Sebastian")
}
IT15:: Cuál es la parada de la Ruta X que se localiza más cerca de mi casa.
Se debería considerar definir el término ‘cerca’, así como la
Cúmar Ramiro Cueva Tacuri
31
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
implementación de un algoritmo que determine la proximidad de los
resultados. Por ahora no se lo considera.
PREFIX pois: <http://localhost/POIS.owl#>
PREFIX
<http://www.w3.org/2003/01/geo/wgs84_pos#>
SELECT DISTINCT ?ParadaY
WHERE
{
?RutaX a pois:RUTA;
pois:nombre ?NombreRuta;
pois:ParadaConOrden ?PardCons.
?PardCons pois:ParadaRelacionada ?ParadaY.
geo:
?ParadaY pois:LocalizadaEn ?PoigPardY.
?PoigPardY pois:CoordenadaGeo ?CoordPoigPardY.
?CoordPoigPardY geo:lat ?LatParadaY.
?EstdZ a pois:ESTUDIANTE.
?EstdZ pois:cedula ?cedEstd.
?Estdz pois:ViveEn ?PoigCasaEstdz.
?PoigCasaEstdz
pois:CoordenadaGeo
?CoordPoigCasaEstdz.
?CoordPoigCasaEstdz geo:lat ?LatEstdZ.
}
ORDER BY ?ParadaY
IT16:: Cuál es el [barrio|sector] donde se ubican mayor cantidad de POIs
PREFIX pois: <http://localhost/POIS.owl#>
SELECT ?POIS
WHERE
{
?POIS a pois:POIG.
?POIS pois:sector ?sectorPOIS.
FILTER( ?sectorPOIS = "Pio Jaramillo Alvarado")
}
2.1.4.3. Resultados de Validación
En base a las consultas realizadas con SPARQL sobre las instancias del
vocabulario, se puede apreciar como la mayor parte de preguntas se han
podido resolver sin mayor problema. Existiendo casos en los que se
demanda la utilización de SPARQL 1.1 por permitir funciones de agregación
Cúmar Ramiro Cueva Tacuri
32
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
para el cálculo de cantidades.
Además, la determinación de conceptos como "cercano a" que se basa en
Coordenadas geográficas, deberá definirse, de tal forma que se implemente
un método (algoritmo) que permita extraer tal medida en base a una
distancia pre-establecida o a su vez el uso de las funciones geográficas de
sparql.
2.2. URI’s
2.2.1. Definición
La localización de recursos dentro del internet está basada en la asignación de URI
a los recursos, siendo este también una premisa importante en el ámbito de
Linked Data. Siguiendo esta línea W3C establece algunas recomendaciones [25]
generales. Así también el gobierno del Reino Unido ha creado un documento de
orientación, el mismo que puede ser encontrado en [26], orientado a la
representación de conocimiento en el área pública del gobierno.
Figura 9: URIs for Vocabularies
Fuente: http://data.gov.uk/resources/uris
Siguiendo este principio se han establecido las siguientes URI’s para el vocabulario
pois, las mismas que se estructuran bajo el esquema de ‘hash namespace’45
donde el vocabulario se construye con la colocación del nombre de la clase o
propiedad de forma directa en la URI antecedida de un ‘comodín’ (#).
45
http://www.w3.org/TR/swbp-vocab-pub/#hash
Cúmar Ramiro Cueva Tacuri
33
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Otra forma de posible representación es conocida como ‘slashnamespace’ 46
donde la diferencia radica en la utilización del ‘/‘ en lugar del ‘#’. La
representación ‘hash namespace’ ha sido elegida por prestar mayor simplicidad al
usuario al intentar acceder a determinada información del vocabulario.
Vocabulario:
/{prefijo}/{vocabulary}
Clases:
/{prefijo}/{vocabulary}#{class}
Propiedades:
/{prefijo}/{vocabulary}#{property}
2.2.2. Uri’s para el Vocabulario
Vocabulario
POIS
Clases
ESTUDIANTE
ORDEN_PARADA
PARADA
PARADA_FRECUENTE
POIG
RUTA
Propiedades
Activa
Barrio
Calle1
Calle2
Cedula
Fecha
Horario
Imagen
Nombre
Num_secuencia
ContieneEstudiante
46
URI
/POIS/vcblr
/POIS/vcblr#ESTUDIANTE
/POIS/vcblr#ORDEN_PARADA
/POIS/vcblr#PARADA
/POIS/vcblr#PARADA_FRECUENTE
/POIS/vcblr#POIG
/POIS/vcblr#RUTA
/POIS/vcblr#activa
/POIS/vcblr#barrio
/POIS/vcblr#calle1
/POIS/vcblr#calle2
/POIS/vcblr#cedula
/POIS/vcblr#fecha
/POIS/vcblr#horario
/POIS/vcblr#imagen
/POIS/vcblr#nombre
/POIS/vcblr#num_secuencia
/POIS/vcblr#ContieneEstudiante
http://www.w3.org/TR/swbp-vocab-pub/#slash
Cúmar Ramiro Cueva Tacuri
34
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
CoordenadaGeo
ElegidaPor
LocalizadaEn
MarcadaEn
OrdenEnRuta
OrdenParada
ParadaConOrden
ParadaRelacionada
PerteneceAParada
Prefiere
Referencia
Sector
Tipo
VinculadaA
ViveEn
/POIS/vcblr#CoordenadaGeo
/POIS/vcblr#ElegidaPor
/POIS/vcblr#LocalizadaEn
/POIS/vcblr#MarcadaEn
/POIS/vcblr#OrdenEnRuta
/POIS/vcblr#OrdenParada
/POIS/vcblr#ParadaConOrden
/POIS/vcblr# ParadaRelacionada
/POIS/vcblr#PerteneceAParada
/POIS/vcblr#Prefiere
/POIS/vcblr#referencia
/POIS/vcblr#sector
/POIS/vcblr#tipo
/POIS/vcblr#VinculadaA
/POIS/vcblr#ViveEn
Tabla 6: Uri’s de Vocabulario
2.3. Publicación de Vocabulario
La publicación del vocabulario implica permitir el acceso al mismo desde cualquier
lugar de la web, basándose comúnmente en la visualización del mismo en dos formas
diferentes, la primera una vista entendible para las personas regularme basado en un
documento HTML. Y la segunda un formato entendible para las máquinas en este caso
RDF.
El acceso a estas definiciones se gestiona a través de la misma URI, es decir, la URI
devolverá uno de los dos formatos según lo solicitemos. Este proceso es conocido
como Dereference URI 47 mediante un proceso conocido como negociación de
contenido.
Basado en esto, son necesarios dos servicios específicos, que pueden o no ejecutarse
en equipos físicamente separados, aunque esto es recomendable. El primer servicio se
encargará de receptar las peticiones y resolverlas (similar a un DNS), mientras que el
segundo almacenará y devolverá la información relativa al vocabulario.
En la actualidad existen servidores dedicados en la Internet que permiten realizar la
función de re-direccionar hacia el almacenaje del vocabulario, como lo es PURL48
gestionado por OCLC49.
47
Dereferencing HTTP URIs. http://www.w3.org/2001/tag/doc/httpRange-14/2007-08-31/HttpRange14.html (draft)
48
http://purl.oclc.org
Cúmar Ramiro Cueva Tacuri
35
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
En el presente trabajo se utilizará el servicio público de PURL para la publicación y para
el almacenaje del vocabulario se utilizará un servidor Web Apache, el mismo que será
instalado sobre una plataforma Linux, en este caso Ubuntu 11.04.
2.3.1. Generación de la Descripción del Vocabulario
La creación del archivo de descripción para el vocabulario (necesario para la
publicación) es generado mediante la utilización de OWLDoc[27], un plugin para
Protégé, que permite exportar un vocabulario (ontología) a una versión HTML
similar a la presentada por los JavaDoc. El plugin ha sido utilizado mediante la
versión 4.x de Protégé.
Su instalación y uso puede ser encontrada en el ANEXO A
2.3.2. PURL
El servicio de Persistent Uniform Resource Locator, conocido comúnmente como
PURL, brinda identificadores permanentes para recursos en la web. Lo que
permite mantener redirecciones a recursos que pueden cambiar a través del
tiempo. Una lista de los servidores en internet que prestan este servicio puede ser
encontrada en [28].
Figura 10: Partes de una PURL
50
Su funcionamiento se basa en el uso de redirecciones51 bajo el protocolo HTTP,
para el uso en Web Semántica se ha estandarizado el uso de la redirección 303
See Other para el uso con PURL. Este tipo de redirección especifica que la
respuesta a una solicitud puede ser encontrada en una URI diferente y que debe
ser recuperada mediante el uso del método GET. Hay que notar que la redirección
303 y todas las del tipo 3xx son llevadas a cabo por los agentes de usuario sobre
HTTP(user agents).
49
http://www.oclc.org
Extraído de: http://purl.oclc.org/docs/help.html#overview
51
RFC2616
50
Cúmar Ramiro Cueva Tacuri
36
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
En donde:
a. El usuario realiza una petición GET a un servidor PURL, especificando un
cierto tipo de contenido indicado por el campo Accept request-header.
b. El servidor PURL emplea la redirección 303 para re-direccionar la petición
del usuario.
c. El servidor de destino (a donde apunta la redirección 303) realiza la
operación de 'content negotiation' para finalmente devolver un recurso a
la petición del usuario.
Figura 11: Funcionamiento de Server PURL
2.3.2.1. Configuraciones
Basado en las especificaciones de inicio de este apartado, se utilizará un
servidor público PURL al cual se vinculará una dirección web en donde se
alojarán los datos del vocabulario. En este caso serán:
Server PURL: http://purl.oclc.org
Servidor Web (apache): http://200.0.29.117:8080/pois/conten
Para que se pueda utilizar la uri del servidor PURL
http://purl.oclc.org/POIS/vcblr
Como una uri desreferenciada que enlaza al vocabulario publicado en la
dirección:
http://200.0.29.117:8080/pois/conten
Es necesario realizar el proceso de configuración detallado en el ANEXO B.
Cúmar Ramiro Cueva Tacuri
37
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Recordando que este proceso es ejecutado sobre un servicio en internet. En
caso de requerir una instancia propia de PURL se puede contemplar la
instalación de este, como se detalla en el ANEXO C.
2.3.3. Apache HTTP Server
Apache HTTP Server 52 es un proyecto mantenido por la comunidad de
desarrolladores de Apache Software Fundation53, el cual en la actualidad se ha
convertido en uno de los Servidores HTTP más robustos y confiables.
2.3.3.1. Negociación de Contenido (Content Negotiation)
El proceso de devolver un recurso diferente al usuario basado en una
misma URI es conocido como Negociación de Contenido54, con lo cual el
usuario o aplicación puede solicitar determinado tipo de contenido que
desea aceptar como respuesta, esto en base al campo Accept requestheader que el protocolo HTTP especifica.
Una vez configurado nuestra PURL, la misma que referencia a nuestro
servidor HTTP, será necesario colocar dentro de este último, nuestro
contenido y configurar la recuperación del mismo mediante la negociación
de contenido.
2.3.3.2. Configuraciones
La negociación de contenido es llevada a cabo mediante la sobre escritura
de peticiones a una URL, para ello Apache HTTP Server posee un módulo
que permite hacer uso de esta funcionalidad, conocido bajo el nombre de
mod_rewrite 55 . Este módulo hace uso de expresiones regulares para
realizar el re-direccionamiento a un determinado recurso o URL.
El proceso de configuración puede ser encontrado en el ANEXO D.
52
http://httpd.apache.org/
http://apache.org/
54
http://httpd.apache.org/docs/trunk/content-negotiation.html
53
55
http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html
Cúmar Ramiro Cueva Tacuri
38
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Mediante este proceso nuestro servidor web será capaz de responder a una
petición en función del contenido solicitado, en este caso pudiendo
responder mediante un archivo HTML o RDF.
2.3.4. Pruebas
La comprobación de la funcionalidad completa de la publicación del vocabulario
será evaluada en base al funcionamiento descrito en la Figura 11. Para ello se
utilizará la utilidad cURL56, la misma que es una librería que automatiza el
intercambio de archivos.
El primer test de prueba será realizado para recuperar la versión en RDF del
vocabulario. Para ello utilizamos los siguientes parámetros en cURL:
curl -i -H "Accept: rdf/xml" -L http://purl.oclc.org/POIS/vcblr
Figura 12: Content Negotiation - Archivo RDF
En donde especificamos el tipo de documento solicitado mediante la sentencia:
Accept: rdf/xml. Obteniendo con ello el archivo Vocabulario.rdf que fue colocado
en el servidor Apache.
El segundo test se basa en la recuperación del archivo HTML del Vocabulario, para
ello utilizamos:
curl -i -H "Accept: text/html" -L http://purl.oclc.org/POIS/vcblr
56
http://curl.haxx.se/
Cúmar Ramiro Cueva Tacuri
39
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 13: Content Negotiation - Archivo HTML
La especificación del tipo de documento va contenida en la sentencia: Accept:
text/html. Con lo cual obtendremos la visualización del contenido del archivo
Vocabulario.html.
Al ser cURL una utilidad de línea de comandos, lo que se verá será el contenido
del archivo y no una representación gráfica. En caso de querer visualizar
gráficamente el contenido es posible ingresar a la misma dirección mediante un
navegador web con lo cual obtendremos una vista similar a la presentada en la
Figura 35, esto solo es aplicable para el documento HTML, puesto que un
navegador web utiliza por defecto el campo Accept: text/html.
2.3.4.1. VAPOUR
El proceso de validación de la correcta publicación del vocabulario
siguiendo los principios de LOD, también puede ser comprobada mediante
la utilización de un validador automático conocido como VAPOUR57
desarrollado por miembros de la Fundación CTIC58.
Este validador de carácter opensource, puede ser utilizado como una
instalación propia o hacer uso del mismo mediante el servicio público
levantado por la Fundación CTIC. Para la presente validación se utilizará el
servicio público por la facilidad que presenta.
57
58
http://vapour.sourceforge.net/
http://www.fundacionctic.org/
Cúmar Ramiro Cueva Tacuri
40
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 14: Interfaz del servicio VAPOUR
La interfaz principal del servicio puede ser observada en la Figura 14, en
este caso, de igual forma que en la validación utilizando curl, se utilizará la
URI del vocabulario basada en PURL.
Este servicio permitirá evaluar la capacidad de la URI para procesar la
petición, basándose para ello en la negociación de contenido. El resumen
de la ejecución de esta validación se puede apreciar en la Figura 15.
Cúmar Ramiro Cueva Tacuri
41
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 15: Resumen de Validación – VAPOUR
Esta validación ha sido realizada utilizando opciones específicas para
Vocabularios, como lo es la especificación de una Clase y propiedad.
Pudiendo así, apreciar que la publicación del vocabulario cumple con
todos los test aplicados por la herramienta.
El resultado completo de esta validación puede ser encontrado en el
ANEXO E.
Cúmar Ramiro Cueva Tacuri
42
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
3. BACKEND
La construcción de la plataforma POIS para el trabajo de puntos de interés geo referenciados,
necesita un almacén de tripletas capaz de permitir tanto su conservación como su consulta y
manipulación. Esta clase de ‘almacenes’ son conocidos bajo el nombre de TripleStore por
permitir el almacenaje y recuperación de datos RDF mediante un lenguaje de consulta
específico.
3.1.OpenLink Virtuoso
El almacén de datos (triplestore) será construido mediante la utilización de Virtuoso en
su versión OpenSource 659, puesto que esta presenta la característica de soportar el
lenguaje SPARQL 1.1, el mismo que contiene un conjunto de funciones necesarias para
cumplir con los objetivos del proyecto POIS, así como la inclusión de SPARUL, un lenguaje
de manipulación de datos que permitirá encargarse de las operaciones de actualización y
eliminación.
El proceso de instalación del Servidor Virtuoso puede ser consultado en el Anexo F.
3.1.1. Carga de Tripletas al Store
La finalidad de la plataforma POIS, como se ha venido mencionando, es la de
poder almacenar la representación de puntos de interés semánticos, los mismos
que pueden ser explotados posteriormente. Siendo su aplicabilidad práctica en
las paradas de los buses de la UTPL.
Toda esta información relativa al servicio de transportación estudiantil ha sido
levantada y almacenada dentro de una Base de Datos Relacional (MySQL), estos
datos son utilizados por una aplicación existente bajo el nombre de IRBU
(Información de Recorridos de Buses de la UTPL)60 que actualmente se encuentra
funcionando como servicio para la Universidad.
59
60
http://virtuoso.openlinksw.com/features-comparison-matrix/
http://200.0.29.121:8080/IRBU
Cúmar Ramiro Cueva Tacuri
43
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 16: Diagrama ER – IRBU
En base a esta estructura se ha seleccionado los elementos que serán
incorporados al Store, definiendo claramente la relación entre este esquema y el
planteado en el Vocabulario RDF de la plataforma POIS.
Individuo
Prefijo
POINT
crd
POIG
pg
PARADA
prd
ORDEN_PARADA
orden
RUTA
rt
Tabla 7: Prefijos de Individuos
Para el proceso de migración de estos datos, de una Base de Datos relacional a un
esquema RDF, ha sido realizado mediante la construcción de una aplicación
propia que se encarga de extraer la información y convertirlas a tripletas.
Esta aplicación genera como salida un archivo OWL con sintaxis RDF/XML que
contiene la información extraída del esquema relacional de la Figura 16,
utilizando para ello los valores de conexión establecidos previamente en la
aplicación.
Los identificadores de los individuos creados mediante esta aplicación son
Cúmar Ramiro Cueva Tacuri
44
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
creados en base a un prefijo y el identificador numérico contenido en la Base de
Datos como llave primaria, la tabla de prefijos utilizados puede ser observada en
la Tabla 7.
Figura 17: Extracto del archivo OWL de salida
Una vez transformados los datos relacionales en tripletas RDF, estás serán
cargadas al Store de Virtuoso (previamente instalado) utilizando para ello la
interfaz principal de administración CONDUCTOR, este proceso puede
encontrarse en el ANEXO G.
Con este proceso tendremos nuestro Store con la población inicial que ha sido
migrada de una Base de Datos Relacional y listo para ser operado a través del
lenguaje de consulta SPARQL.
3.1.2. Sparql Endpoint
Para la extracción de la información almacenada en el Store dentro del Servidor
Virtuoso, se utiliza la interfaz conocida como EndPoint a donde se pueden enviar
peticiones HTTP del tipo SPARQL que serán respondidas apropiadamente por el
servidor, este servicio es levantado por defecto en el puerto 8890.
Este tipo de peticiones involucran tanto la consulta de datos como las operaciones
de manipulación del Store mediante el uso de Sparql 1.1 (sparul), gracias al
soporte de Virtuoso. Siendo este un punto fuerte para la publicación y
mantenimiento del store RDF.
Al momento de la instalación Virtuoso se genera un ENDPOINT automático que
puede ser ubicado en la dirección web:
http://servidor.com:8890/sparql.
El mismo presenta una interfaz gráfica desde donde se puede realizar extracción
de datos utilizando el lenguaje de consulta SPARQL.
Cúmar Ramiro Cueva Tacuri
45
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 18: EndPoint generado por Virtuoso
El lenguaje utilizado para la recuperación de la información desde el EndPoint se
realiza mediante SPARQL, cuya sintaxis es similar al lenguaje SQL utilizado por las
bases de datos relacionales. Para profundizar sobre la sintaxis y sus beneficios se
puede remitir a [7].
3.1.2.1. Formatos de Respuesta
Las operaciones realizadas de extracción de datos, desde la interfaz del
EndPoint del servidor pueden ser visualizadas en diversos formatos, de tal
forma que la manipulación y visualización de los resultados se acoplan a la
integración con aplicaciones existentes (clientes). Un resumen de los
formatos permitidos puede ser encontrado en la Tabla 8.
Valor
Mimetype
HTML
text/html
json
application/sparql-results+json
json
application/rdf+json
js
application/javascript
table
text/html
XML
text/html
TURTLE text/html
Cúmar Ramiro Cueva Tacuri
46
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Tabla 8: Formatos de Respuesta
61
Para la interacción planeada con el EndPoint, tanto la recuperación de
datos como las operaciones de manipulación de datos (sparul) serán
manejadas mediante el formato JSON, esto debido a que es un formato
ligero para el intercambio de datos y permitiendo una manipulación más
versátil en comparación con respuestas del tipo XML u otros.
3.1.2.2. SPARQL basado en REST
REST, cuya representación se interpreta como Transferencia de Estado
Representacional, originado a partir de la tesis doctoral de Roy Fielding[29],
establece la creación e interacción de servicios en la red utilizando un
protocolo cliente/servidor sin estado, conteniendo en una sola petición
HTTP toda la información suficiente para procesarla.
El servidor Virtuoso, basa el funcionamiento de los EndPoint bajo esta
tendencia, permitiendo de esta forma que la información almacenada en el
store pueda ser consumida desde un cliente REST. En este caso, la dirección
indicada es la misma del EndPoint visualizado desde la web:
http://servidor.com:8890/sparql.
Para el consumo de este servicio se deben considerar un conjunto de
parámetros a ser enviados al servidor, en la Tabla 9 se muestra un resumen
de los más importantes:
Parámetro
query
Descripción
Requerido?
Consulta Sparql
Yes
dflt_graph URI del gráfico por defecto (string o NULL)
No
maxrows
Límite de filas mostradas
No
timeout
Tiempo máximo de duración de la consulta No
Tabla 9: Lista de parámetros
62
Mediante la utilización de estos parámetros, la extracción (interacción) con
el Store es realizada de forma sencilla mediante peticiones GET hechas a
dicho servicio.
61
62
http://docs.openlinksw.com/virtuoso/rdfsparql.html
http://docs.openlinksw.com/virtuoso/rdfsparql.html - 16.2.3.3.1. Request Parameters
Cúmar Ramiro Cueva Tacuri
47
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Al ser los datos almacenados en el Store considerados públicos (según los
principios de LOD) y por la cantidad de datos que se almacenan dentro, es
conveniente el acceso (recuperación – modificación) mediante peticiones
directas, las mismas que no deberán permitir crear ‘sesiones’ o almacenar
alguna información temporal sobre la petición (cookies).
De esta forma REST permite la interacción perfecta con el STORE
convirtiendo cada consulta de sparql en una petición GET directa al Store.
3.1.2.3. Pruebas
Una de las ventajas presentes en el uso de REST es la sencillez de los
clientes, pudiendo ser construidos en básicamente cualquier lenguaje. Para
la comprobación del servicio REST presente en Virtuoso se utilizará un
cliente desarrollado bajo el lenguaje PHP.
Se extraerán 3 elementos del tipo PARADA, donde los resultados serán
mostrados en formato JSON.
$query = “PREFIX pois:< select *
http://localhost:9090/pois/vcblr/#> where { ?Parada
a pois:PARADA } LIMIT 3”;
$baseURL = “http://localhost:9090/pois/vcblr/#”;
$format="application/json"
$params=array(
"default-graph" =>
"http://localhost:8890/poisV5",
"query" => $query,
"timeout" => "",
"format" => $format,
"save" => "display"
);
$querypart="?";
foreach($params as $name => $value)
{
$querypart=$querypart . $name . '=' .
urlencode($value) . "&";
}
$sparqlURL=$baseURL . $querypart;
file_get_contents($sparqlURL)
El resultado devuelto del store es el siguiente:
Cúmar Ramiro Cueva Tacuri
48
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
{ "head": { "link": [], "vars": ["Parada"] },
"results": { "distinct": false, "ordered": true,
"bindings": [
{ "Parada": { "type": "uri", "value":
"http://localhost:9090/pois/vcblr/#prd1" }},
{ "Parada": { "type": "uri", "value":
"http://localhost:9090/pois/vcblr/#prd2" }},
{ "Parada": { "type": "uri", "value":
"http://localhost:9090/pois/vcblr/#prd3" }} ] } }
Como se puede apreciar, la interacción con el Store desde su interfaz REST
es sencilla, donde es importante notar la importancia de los parámetros
correctos, así como indicar que los valores de los parámetros deberán ir
codificados mediante la función urlencode()63, que realiza un reemplazo
de los caracteres no alfanuméricos por símbolos equivalentes. De tal forma
que estos no interfieran con la sintaxis y caracteres propios de la URL a la
cual se hace la petición HTTP.
Texto : a ser enviado %
encode
Texto%20%3A%20a%20ser%20enviado%20%25
Figura 19: Caracteres codificados
3.1.3. Autenticación sobre EndPoint
Virtuoso, como se ha comentado en apartados anteriores, permite la utilización
de SPARQL 1.1, el mismo que posee el lenguaje de manipulación SPARQL UPDATE
(sparul), con el cual se pueden realizar operaciones de INSERCIÓN – BORRADO –
MODIFICACIÓN de tripletas almacenadas en el Store.
Este tipo de operaciones son necesarias para cumplir con el objetivo de la
plataforma POIS y su API CRUD. El uso de este lenguaje es realizado desde el
mismo EndPoint donde se interactúa con SPARQL. De esta forma, basándose en la
descripción dada de este EndPoint anteriormente, el mismo que es de acceso
público, implicaría que cualquiera desde el EndPoint podrá manipular la
estructura de los datos mediante la ejecución de sentencias SPARQL-UPDATE, algo
que compromete seriamente la integridad de los datos y la consistencia de los
mismos en el Store.
63
http://php.net/manual/es/function.urlencode.php
Cúmar Ramiro Cueva Tacuri
49
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 20: Usuarios Virtuoso Server
Para solventar este inconveniente Virtuoso implementa un conjunto de ROLES
que son asignados a determinados usuarios, de tal forma que un usuario
determinado puede poseer uno o varios roles que le permitan llevar acabo
determinadas acciones sobre el Store.
Dentro del conjunto de roles preexistentes en Virtuoso es importante enfocarse
en la existencia de dos roles: SPARQL_SELECT y SPARQL_UPDATE, los mismos que
contienen permisos de selección y permisos de actualización (selección implícita)
respectivamente.
Figura 21: Roles Virtuoso Server
Virtuoso por defecto enlaza la interfaz del EndPoint localizada en la dirección:
http://servidor.com:8890/sparql.
Al usuario SPARQL, el mismo que posee tan solo permisos de consulta de datos
Cúmar Ramiro Cueva Tacuri
50
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
bajo el rol de SPARQL_SELECT, es así que al intentar ejecutar una sentencia
DELETE (o cualquiera que involucre SPARQL – UPDATE) sobre esta interfaz
obtendremos un resultado similar al mostrado en la Figura 22.
Figura 22: Error de Privilegios
Donde se especifica que no existen los permisos asociados con el usuario para
realizar dicha acción, lo que resulta una medida necesaria para proteger la
integridad del Store dejando tan solo accesible la consulta de datos.
Aun así la necesidad de realizar manipulaciones sobre el Store es necesaria,
puesto que el API de la Plataforma deberá permitir esto, y debido a que desde
esta interfaz no es seguro aplicar también el rol SPARQL_UPDATE, se
implementará una solución que involucra la existencia de dos interfaces de
entrada hacia el Store. La ya conocida /sparql y una nueva bajo el directorio
/sparql-auth.
De tal forma que existirán dos interfaces una para la extracción y otra para la
manipulación de los datos del Store. Así, se creará un usuario con los permisos
necesarios (rol SPARQL_UPDATE) para que trabaje sobre esta interfaz, con los
siguientes datos:
User: test2
Pass: test2
La creación del usuario es realizada mediante la interfaz principal de Conductor,
bajo la opción ‘System Admin’. Donde además se asignará el rol
correspondiente para realizar la manipulación del Store.
Cúmar Ramiro Cueva Tacuri
51
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 23: Creación de Usuario
Una vez creado el usuario con los permisos adecuados (rol), se puede comprobar
su funcionamiento desde la dirección:
http://servidor.com:8890/sparql-auth
La autenticación utilizada por este tipo de usuario es una Autenticación Digest64,
conocida en Virtuoso como SQL Authentication. Siendo una forma útil y eficaz
para garantizar el acceso. Además de este método Virtuoso presenta otras formas
posibles como65:
OAuth
WebID Protocol based authentication
Para la utilización de estos tipos de autentificación es necesaria la instalación del
módulo policy_manager_dav.vad y acceder desde la dirección:
http://servidor.com:8890/ policy_manager/
Donde es posible seleccionar el método de autenticación, recordando que debe
existir al menos un usuario que acepte este tipo de autenticación.
64
65
http://en.wikipedia.org/wiki/Digest_access_authentication
http://docs.openlinksw.com/virtuoso/rdfsparql.html [16.2.3.4.2. Authentication]
Cúmar Ramiro Cueva Tacuri
52
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 24: Servidor de Autentificación
La selección de uno u otro método dependerá directamente de la aplicabilidad
que tendrá nuestro Store, en este caso, será consumido y actualizado desde otra
aplicación (cliente – API) por lo que utilizar autenticación digest, se convierte en la
mejor opción, por su valor de seguridad y facilidad.
3.1.3.1. Pruebas
Una vez creado el usuario con permisos de actualización sobre el Store, así
como identificado el punto de acceso, la interacción con él mediante el
protocolo REST es similar a las pruebas realizadas anteriormente. A
continuación se muestra la inserción de un individuo del tipo ESTUDIANTE
(según se define en el vocabulario POIS) desde un fichero PHP hacia el
Store, en este caso se utilizará la librería CURL66.
<?php
$user = "test2";
$pass = "test2";
$query = "PREFIX pois:<http://purl.oclc.org/POIS/vcblr/#>
INSERT INTO GRAPH <http://localhost:8890/POIS> {
pois:estd01 rdf:type pois:ESTUDIANTE; pois:cedula
1104698723; pois:ViveEn pois:pg64 }";
$format = "application/sparql-results+json";
$endPointSecure = "http://localhost:8890/sparql-auth/";
$URL = $endPointSecure."?query=".urlencode($query)."
&format=".urlencode($format);
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $URL);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_DIGEST);
66
http://curl.haxx.se/
Cúmar Ramiro Cueva Tacuri
53
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
curl_setopt($ch, CURLOPT_USERPWD, "$user:$pass");
$output = curl_exec($ch);
echo $output;
curl_close($output);
La salida producida será una confirmación de inserción de la siguiente
manera.
{ "head": { "link": [], "vars": ["callret-0"] },
"results": { "distinct": false, "ordered": true,
"bindings": [
{ "callret-0": { "type": "literal", "value": "Insert into
<http://localhost:8890/POIS>, 3 (or less) triples -- done" }}
] } }
De esta forma se ha insertado un nuevo individuo ESTUDIANTE que
contiene 3 tripletas, se debe recalcar que para realizar la autenticación
contra el EndPoint se especifica el tipo de autenticación a utilizar:
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_DIGEST);
Esta prueba demuestra la viabilidad de utilizar una interfaz de EndPoint
dedicada solo al proceso de manipulación de datos del Store y otra para la
extracción de información.
3.2. Vocabulary of Interlinked Datasets (VoID)
Una propuesta del Digital Enterprise Research Institute (DERI)67 y adoptada por la W3C
como una nota de grupo de interés68 permite expresar metadatos sobre los DataSets de
tripletas, intentando de esta forma ser un punto de enlace entre quienes publican el
DataSet y los que lo usan. Permitiendo que herramientas personalizadas puedan
examinar el documento y catalogar el DataSet, basándose para ello en el uso de,
principalmente, el vocabulario Dublin Core.
En este documento se especifica aspectos relevantes del DataSet como su localización,
la información que almacena, la vinculación existente con otros DataSets, así como el
uso de vocabularios. Así mismo se menciona la inclusión de información relativa a la
licencia con la cual se ha publica el mismo. Las principales han sido propuestas por
Open Data Commons69.
67
http://www.deri.ie/
“Describing Linked Datasets with the VoID Vocabulary” http://www.w3.org/TR/void/
69
http://opendatacommons.org
68
Cúmar Ramiro Cueva Tacuri
54
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
En este caso, para la publicación del DataSet de la plataforma POIS, se ha seleccionado
la licencia del tipo "Open Data Commons Attribution License (ODC-By) v1.0" la misma
que permite Compartir, crear y adaptar la información existente, siempre y cuando se
atribuya dicha información al productor del DataSet.
Para la creación de este documento VoID, el grupo DERI ha creado una herramienta
online70, capaz de permitir incluir de forma gráfica y detallada todos los aspectos
relativos al DataSet. Esta herramienta bajo el nombre de ve2 puede ser observada en la
Figura 25.
Esta herramienta genera la descripción del DataSet en base a la sintaxis RDF Turtle,
permitiendo además realizar una revisión de la salida y la facilidad de publicación del
documento en varios sitios como Sindice71, voiD Store72, voiD Browser73 y PTSW74, los
mismos que mantienen gran cantidad de DataSets registrados, facilitando de esta
manera su búsqueda y utilización.
Figura 25: Editor VoID - DERI
A continuación, se muestra el archivo VoID del Store de la Plataforma POIS, que ha sido
construido utilizando la herramienta antes descrita y cuya salida se encuentra en
formato RDF Turtle.
@prefix
@prefix
@prefix
@prefix
rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
foaf: <http://xmlns.com/foaf/0.1/> .
dcterms: <http://purl.org/dc/terms/> .
70
http://ld2sd.deri.org/ve2/
http://sindice.com/
72
http://void.rkbexplorer.com/
73
http://kwijibo.talis.com/voiD/
74
http://pingthesemanticweb.com/
71
Cúmar Ramiro Cueva Tacuri
55
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
@prefix void: <http://rdfs.org/ns/void#> .
@prefix : <#> .
## POIS DATASET
<http://www.utpl.edu.ec/poisDataSet> rdf:type void:Dataset ;
foaf:homepage <http://www.utpl.edu.ec/poisDataSet> ;
dcterms:title "POIS Plataform" ;
dcterms:description "Informacion relativa a todas las rutas
y paradas del sistema de transportacion estudiantil de la
Universidad Tecnica Particular de Loja." ;
dcterms:publisher <http://foaf.me/qmarqeva#me> ;
dcterms:license <http://opendatacommons.org/licenses/by/summary/> ;
void:sparqlEndpoint <http://www.utpl.edu.ec/poisDataSet/sparql> ;
void:vocabulary <http://purl.oclc.org/POIS/vcblr/#> ;
void:vocabulary <http://www.w3.org/2003/01/geo/wgs84_pos#> .
3.3. Servicio REST - CRUD
El acceso a los datos contenidos en el Store tanto para su consumo como modificación,
será realizado mediante la utilización de un servicio REST, el mismo que es desarrollado
bajo los principios de este estilo arquitectónico de la Web.
De esta forma, los clientes (software) que deseen interactuar con el Store tendrán una
vía de acceso sencilla, basada en recursos y accedida mediante peticiones HTTP,
dejando el trabajo de formular las consultas SPARQL al servicio REST.
La adopción de este tipo de servicios en la actualidad tiene gran acogida, en el internet
gran cantidad de empresas ofrecen sus servicios basados en REST como eBay 75,
Twitter76 así como el servicio de búsqueda de Google77.
La facilidad brindada por REST radica principalmente, en la utilización del protocolo
HTTP a nivel de aplicación, de tal forma que se obtiene un conjunto de operaciones bien
definidas como lo son POST, GET, PUT y DELETE (por mencionar las principales) las
mismas que actúan sobre recursos, donde cada uno de ellos son identificados de forma
única mediante la utilización de URIs78.
De esta forma se puede realizar una comparativa entre los métodos ofrecidos por el
protocolo HTTP y las operaciones CRUD de un sistema transaccional de base de Datos
como se muestra en la Tabla 10.
75
http://developer.ebay.com/developercenter/rest/
https://dev.twitter.com/docs/api
77
http://code.google.com/intl/es/apis/websearch/docs/
78
RFC3986
76
Cúmar Ramiro Cueva Tacuri
56
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Operación
Create
Read
Update
Delete
SQL
Insert
Select
Update
Delete
HTTP
POST
GET
PUT
DELETE
Tabla 10: Métodos HTTP - CRUD
Estas relaciones serán tomadas en consideraciones al momento de la implementación
del API para la plataforma POIS.
3.3.1. Framework
A medida que el uso de REST se ha popularizado, es frecuente encontrar
frameworks que permiten implementarlo en diferentes lenguajes. Cada una de
estas implementaciones presta un valor determinado en dependencia del
ambiente en el que se desarrollan. Para la utilización de uno de estos dentro de la
plataforma POIS es vital la consideración del servidor necesario por el framework
en donde residirá el aplicativo REST. Tomando en cuenta esta restricción a
continuación se expone un cuadro descriptivo conteniendo algunos framework
existentes en diversos lenguajes.
Lenguaje /
Framework
Tecnología
ASP.net
REST Starter Kit79
Axis280
Java
Jersey81
Restlet82
Recess83
PHP
Zend Framework84
Ruby
restful-rails85
Server
Internet Information Server
Servidor de Aplicaciones Java
Apache
Apache (soporte Ruby)
Tabla 11: Frameworks REST
79
http://www.asp.net/downloads/starter-kits/wcf-rest
http://axis.apache.org/axis2/java/core/
81
http://jersey.java.net/
82
http://www.restlet.org/
83
http://www.recessframework.org/
84
http://framework.zend.com/manual/en/zend.rest.client.html
85
http://rubyforge.org/projects/restful-rails/
80
Cúmar Ramiro Cueva Tacuri
57
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
En base a la Tabla 11, el backend para el servicio REST de la plataforma POIS será
realizado en PHP debido a su simplicidad y tiempo de aprendizaje.
Además, la interacción con el EndPoint de Virtuoso desde PHP se convierte en una
tarea relativamente sencilla, ya que PHP es un lenguaje para la web y para su
funcionamiento es necesario un servidor Web como lo es Apache, el mismo que
ya ha sido utilizado en la publicación del Vocabulario en apartados anteriores.
De esta forma y tomando como base el funcionamiento del framework Recess,
para la construcción del servicio REST para la plataforma POIS, se utilizará un
framework derivado de este que trabaja de forma similar pero presenta ventajas
en cuanto a simplicidad de funcionamiento, pues es una versión reducida del
mismo, la cual puede ser encontrada en [30], mismo que es totalmente
independiente de librerías y otros frameworks.
3.3.1.1.
Funcionamiento del Servidor REST
Al ser REST un servicio Web, este está encargado de responder la
peticiones realizadas por un usuario, como se mencionó anteriormente,
estas peticiones estarán dirigidas a un determinado recurso, el mismo que
ha sido identificado por una URI, las mismas que seguirán el siguiente
formato:
http://server.com/recurso/param1/param2/param3
Dónde:
http: Determinará el tipo de operación CRUD a realizar.
recurso: Identifica el recurso al que se va a acceder.
paramX: Estable todo el conjunto de parámetros (valores) que
serán enviados como parte de la petición.
Cúmar Ramiro Cueva Tacuri
58
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
JSON
JSON
EndPoint Virtuoso
Index.php
ControladorRest.php
HTTP METHOD
.htaccess
.htaccess
RestServer.php
Figura 26: Servidor REST – POIS
De esta forma, el servidor REST utilizará el módulo mod_rewrite del
servidor Apache para realizar la redirección, localización de recursos y el
paso de parámetros desde la petición. Para ello hace uso de un archivo
.htaccess, en el que se especifica la redirección de todas las peticiones a
un archivo inicial que se encargará de gestionarlas y asignar la operación
correspondiente.
DirectoryIndex index.php
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^.*$ index.php [QSA,L]
</IfModule>
En base a esto, y siguiendo la estructura de la Figura 26, la construcción
del servidor REST, involucra la utilización de 4 archivos:
.htaccess: Realiza la redirección de la petición a un archivo base.
Index.php: Archivo base que se encarga de levantar el servicio
REST y ejecutarlo.
RestServer.php: Gestiona todo el proceso del servidor, encargado
de localizar el recurso al que se quiere acceder en base
a la URI y el método HTTP de la petición.
ControladorRest.php: Contiene todas las operaciones posibles
sobre los recursos, así como definición de las URIs.
Cúmar Ramiro Cueva Tacuri
59
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Aquí es donde se implementarán
operaciones sobre el EndPoint.
todas
las
Toda petición realizada al servidor devolverá como resultado una
respuesta en formato JSON conteniendo en ella el resultado de la
interacción con el EndPoint o un código de estado HTTP.
{
"error": {
"code": 404,
"message": "Not Found"
}
}
El proceso de creación de URIs por parte del servidor así como la relación
entre los métodos HTTP, es realizada de una manera ingeniosa en base a
la definición de funciones (procedimientos) en php y a su vez haciendo
uso de los comentarios que son colocados al inicio de estas.
De esta forma la estructura básica de una función a ser definida en el
archivo ControladorRest.php se muestra en la Figura 27, considerando
que toda función que se enlazará a una URI deberá tener para ello un
comentario indicando esto.
Figura 27: Estructura función – Server REST
Al iniciar el servidor REST este mapeará todos métodos que contenga en
sus comentarios el tag @url de tal forma que se relacionará cada método
a esta sección de la URI, indicando además al inicio de esta el método
HTTP que trabajará con esta URI.
Se debe resaltar que todos los valores contenidos en esta URI precedidos
por el símbolo de moneda $ serán reconocidos como parámetros y serán
Cúmar Ramiro Cueva Tacuri
60
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
correspondidos directamente con los contenidos en la definición de la
función como se muestra en la Figura 28.
A diferencia de otros frameworks, el nombre colocado a la función no
tiene mayor relevancia ya que la relación es establecida directamente por
la URI en el comentario y los parámetros de entrada de la función.
Figura 28: Correspondencia de Parámetros
Para convertir uno de los parámetros en opcional, se deberá considerar el
añadir una nueva URI mediante el tag @url en donde no se mencionará el
parámetro opcional, así como indicar un valor por defecto al parámetro
relacionado en la función, similar a la Figura 29. Donde se ha considerado
opcional el segundo parámetro tienen asignado en el método un valor por
defecto null. Con esto se puede lograr vincular más de una URI a una
determinada acción (función).
Figura 29: Parámetro Opcional
3.3.2. URIs de Recursos
REST establece que toda URI indica una operación sobre un determinado recurso,
para cumplir con este principio dentro del servidor REST para la plataforma POIS,
se considerarán como recursos todos los elementos que conforman el
Vocabulario POIS, el cual se puede encontrar en la Figura 5.
Para este proceso de definición de URIs se establecerá un prefijo entre el nombre
del servidor y el recurso al que se está accediendo, con el nombre de /pois/ que
Cúmar Ramiro Cueva Tacuri
61
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
permitirá identificar el nombre de la plataforma, para ello se establecerá la
estructura de la Figura 30 para el directorio en el servidor web Apache.
Figura 30: Directorio Servidor Apache
En base a estas consideraciones el formato genérico de una URI proporcionada
por el servidor REST será la siguiente:
http://{dir_server}/pois/[individuo/]$params
Se debe recordar que debido al uso de SPARUL en interacción con el EndPoint de
Virtuoso, algunas URIs tendrán los parámetros $user - $pass que harán referencia
a un usuario válido con el rol de SPARQL_UPDATE.
La definición de todas las URIs proporcionadas por el servidor REST POIS, pueden
ser encontradas en el ANEXO H.
Cúmar Ramiro Cueva Tacuri
62
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
3.3.3. Métodos del API
Las operaciones posibles sobre el Store, como se mencionó anteriormente, están
dentro de cada función definida en el archivo ControladorRest.php ubicado en el
servidor Apache.
Estas devolverán el resultado de la operación sobre el Store (sparql), códigos de
estado HTTP, así como la confirmación de alguna acción o el fracaso de la misma.
{
"status": "[OK | FAIL]",
["indiv": "idIndividuo"],
["message": "Descripción"]
}
Cada uno de estos métodos tiene relación directa con una o más URIs como se ha
mencionado en los apartados anteriores, la mayoría de operaciones no conlleva
mayor proceso lógico, a diferencia de unas cuantas que se exponen a
continuación.
De la misma manera en que se utilizó prefijos para nombrar a los individuos que
fueron exportados desde la base de datos relacional, el API al crear individuos
utilizará un prefijo por cada individuo más una combinación de la fecha y hora
para crear un id único de individuo mediante el uso de la función
date("YmdHis") desde PHP.
3.3.3.1.
Eliminar una Ruta
Función:
delete_ruta($user, $pass, $ruta)
Http: DELETE
URI: /ruta/$user/$pass/$ruta
Descripción: El proceso de eliminación dentro del Store se convierte en un
proceso de desactivación, puesto que es necesario conservar estos
datos para la posterior extracción de información histórica.
En base a esto, al ‘eliminar’ un elemento del tipo RUTA, se procede a
desactivar la ruta manipulando su propiedad activa colocando en ella
el valor de 0. De la misma forma, se desactivarán solamente las
paradas que sean referenciadas únicamente por esta RUTA,
colocando igualmente el valor de 0 a su propiedad activa.
Cúmar Ramiro Cueva Tacuri
63
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
3.3.3.2.
Agregar una nueva parada
Función: add_ruta_parada($user, $pass, $ruta, $ordprd, $numsec)
Http: PUT
URI: /ruta/parada/$user/$pass/$ruta/$ordprd/$numsec
Descripción: Existe la posibilidad de agregar una nueva PARADA a una
determinada RUTA, sea esta PARADA nueva o existente en el Store.
Para ello se vincula un individuo del tipo ORDEN_PARADA que es
recibido como parámetro de entrada, así como el número de orden
que ocupará en la RUTA especificado en el parámetro numsec.
De esta forma, se actualizará la propiedad num_secuencia de todos
los individuos ORDEN_PARADA vinculados a esta RUTA y que sean
mayores o iguales al orden recibido, el proceso es ilustrado en la
Figura 31.
Luego de esto serán vinculados estos objetos de forma directa
haciendo uso de la propiedad ParadaConOrden del individuo RUTA.
4
1
1
2
2
3
3
4
4
5
6
+1
+1
+1
+1
+1
+1
5
6
7
Figura 31: Desplazamiento e inserción de Parada
3.3.3.3.
Eliminar parada
Función: delete_ruta_parada($user, $pass, $ruta, $parada){
Http: DELETE
URI: /ruta/parada/$user/$pass/$ruta/$parada
Descripción: El proceso de ‘eliminación’ de una parada en relación con una
ruta, es la eliminación del vínculo existente entre estas, así como
desactivar la parada si solamente es referenciada por esta ruta.
Al igual que el proceso anterior aquí se deberá realizar un
Cúmar Ramiro Cueva Tacuri
64
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
desplazamiento de acuerdo a la parada a eliminar.
1
1
2
2
3
3
4
5
-1
-1
-1
-1
4
5
6
Figura 32: Desplazamiento y eliminación de Parada
3.3.3.4.
Actualizar Propiedad
Función: update_propiedad($user, $pass, $individuo, $propiedad, $valor,
$tipo = null)
Http: PUT
URI: /propiedad/$user/$pass/$individuo/$propiedad/$valor/$tipo
/propiedad/$user/$pass/$individuo/$propiedad/$valor
Descripción: Este permite la actualización de cualquier propiedad de
cualquier individuo existente en el Store, lo que permite tener un
acceso global desde un solo punto.
Este proceso de actualización es llevado a cabo mediante el uso del
operador MODIFY contenido en SPARQL 1.1. El mismo que permite la
ejecución de una sentencia DELETE e INSERT al mismo tiempo que
permiten simular una sentencia UPDATE tradicional en SQL.
PREFIX
PREFIX
MODIFY
DELETE
INSERT
WHERE
:rt001
}
pois:<http://purl.oclc.org/POIS/vcblr/#>
:<http://localhost/pois/vcblr/indv/#>
GRAPH <http://localhost:8890/poisV5>
{ :rt001 pois:tipo ?y }
{ :rt001 pois:tipo "newValue" }
{
pois:tipo ?y
Como se puede apreciar esto permite ejecutar actualizaciones
específicas así como masivas, mediante la selección de las mismas en
base a la cláusula WHERE.
Cúmar Ramiro Cueva Tacuri
65
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
3.3.3.5.
URL para Imágenes
En la definición de los individuos PARADA, presente en la construcción del
vocabulario para la plataforma, se contempla que cada parada podrá
tener vinculada consigo una imagen bajo la propiedad del mismo
nombre. Esta propiedad hará referencia a una dirección URL en la cual
podrá ser encontrada la imagen.
Debido a que el servicio de la Plataforma POIS es accedido mediante REST,
mediante la utilización de notación ‘slash’ que utiliza como separadores
de recursos y parámetros el símbolo ‘/’. En este caso, al incluir una URL
como parámetro se creará un conflicto, puesto que se interpretarán los ‘/’
como recursos o propiedades del servicio.
La codificación de este parámetro tampoco es una solución puesto que al
utilizar una notación ‘hash’, el servidor Apache realiza una decodificación
de la URL y se obtiene el mismo problema.
Para solventar este inconveniente se ha considerado el envío de este
parámetro (URL de la imagen) con doble codificación, la misma que será
decodificada en primera instancia por el servidor Apache y luego por el
servicio REST. Este proceso puede ser observado en la Figura 33.
http://server.com/pictures/prd01.png
original
http%3A%2F%2Fserver.com%2Fpictures%2Fprd01.png
codificada
http%253A%252F%252Fserver.com%252Fpictures%252Fprd01.png
Doble codificada
Figura 33: Doble codificación de una URL
Cúmar Ramiro Cueva Tacuri
66
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
3.3.4. Pruebas
El proceso de pruebas ha sido desarrollado enfocado a comprobar tanto el
funcionamiento del API REST como la lógica aplicada en las acciones que se
deberán llevar acabo.
Los datos utilizados en las pruebas involucran datos ficticios como datos reales
cargados en el Store. Por cada URI se indicará los valores a ser enviados, la acción
esperada y el estado del Store antes y después de la acción (en los casos
aplicables). Estas han sido llevadas a cabo utilizando el complemento RESTClient86
para Firefox.
El proceso y resultado se puede encontrar en el ANEXO I.
86
https://addons.mozilla.org/en-US/firefox/addon/restclient/
Cúmar Ramiro Cueva Tacuri
67
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
4. CLIENTE
El funcionamiento de la plataforma POIS es comprobada con la construcción de un cliente con
funcionalidades básicas orientadas a los Estudiantes, haciendo uso del servicio prestado por el
servidor REST, todas ellas mediante el uso de peticiones HTTP. Se menciona que otras
funcionalidades relativas a la sección administrativa de la plataforma no han sido
contempladas en este cliente.
4.1. Tecnologías
Para el proceso de construcción del cliente se ha considerado la selección de
tecnologías que permitan una interoperabilidad alta, entre los componentes a
desarrollar y los servicios existentes.
En primera instancia es necesario el uso de un mapa digitalizado sobre el cual se
realizarán todas las operaciones de visualización, actualmente en el mercado existen
soluciones gratuitas como Bings Maps87, Google Maps88 y otros, que son una solución
excelente para diversos proyectos. En el caso de la plataforma POIS, la sección más
importante a visualizar en el mapa es la ciudad de Loja, motivo por el cual las soluciones
propuestas han sido desechadas, puesto que no poseen la ciudad entre sus mapas.
Con estos antecedentes la selección del servidor de mapas para el proyecto cliente, se
orienta al consumo de mapas de los servidores del Proyecto OpenStreetMap89 (OSM),
este proyecto libre y colaborativo, cuenta con una vasta colección de mapas de todo el
mundo, poseyendo entre estos la ciudad de Loja en su mayor parte digitalizada. Otra de
sus ventajas radica en que no es necesaria la utilización de una cuenta o key especial
para el consumo de los mismos, pues su uso se basa en la licencia Creative Commons90.
De esta misma forma se debe considerar un framework o librería capaz de permitir el
trazado de figuras y manipulación de las mismas sobre nuestro mapa, en este caso se ha
seleccionado a la librería OpenLayers(OL)91, una librería desarrollada totalmente bajo
javascript que permite la carga, manipulación y trazado, tanto de figuras como mapas
de cualquier lugar. Poseyendo además características notables como la manipulación de
gran cantidad de figuras en forma de vectores así como acceso al código fuente por ser
un proyecto de código abierto.
87
http://www.bing.com/maps/
http://maps.google.es/
89
http://www.openstreetmap.org/
90
http://creativecommons.org/
91
http://openlayers.org/
88
Cúmar Ramiro Cueva Tacuri
68
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Finalmente el cliente deberá cumplir con una característica importante, el ser de fácil
manejo y de apariencia agradable, siendo la construcción de esta dependiente de las
tecnologías antes seleccionadas. Razón por la cual se ha seleccionado el framework
ExtJs92 para la construcción de todo el frontEnd. ExtJs posee un gran conjunto de
componentes gráficos listos para su uso los mismos que son de fácil manejo y poseen
gran cantidad de documentación, siendo una de las características notables la
compatibilidad entre navegadores y el soporte para el trabajo con Ajax.
4.2. Integración
La creación de este cliente (prueba de concepto) ha involucrado aspectos relevantes
que se deben destacar, como el proceso de comunicación entre el cliente y el API REST ,
el mismo que es realizado mediante consultas HTTP efectuadas desde el framework
ExtJs, donde se especifica el tipo de petición a realizar sobre un determinado recurso, el
formato de una petición típica se puede apreciar en la Figura 34.
De igual forma, todo el procesamiento de la información recibida desde el servicio REST
es procesada mediante lectores JSON propios de ExtJs.
Figura 34: Petición HTTP – ExtJs
En el siguiente apartado se describirán cada una de las funcionalidades implementadas
en la aplicación cliente y que servirán para comprobar el funcionamiento de la
Plataforma POIS.
92
http://www.sencha.com/products/extjs/
Cúmar Ramiro Cueva Tacuri
69
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
4.3. Funcionalidades
4.3.1. Verificación de Existencia de Estudiante
El ingreso al cliente es realizado mediante el ingreso de un número de cédula
válido. La validación realizada determina la existencia de un estudiante con esta
cédula en el Store, en caso de existir son extraídas su vivienda y parada frecuente.
En caso de no existir y ser una cédula válida, se notificará al usuario la posibilidad
de incluirlo dentro del Store. Anexo 9.10.1
4.3.2. Visualización de Vivienda
El proceso de visualización de la vivienda de un estudiante dentro del
sistema, en caso de tenerla especificada, será graficada con un icono
representativo sobre un mapa de la ciudad, para esta visualización se
considera la extracción de la última vivienda registrada por el estudiante. Anexo
9.10.2
4.3.3. Visualización de Parada Frecuente
Al igual que el proceso de visualización de vivienda, la parada frecuente del
estudiante será visualizada al iniciar sesión, en caso de tenerla definida, la
misma corresponderá directamente a una Parada existente en el Store.
Anexo 9.10.3
4.3.4. Registro de Vivienda
Un usuario del sistema (estudiante) podrá fijar un determinado punto geográfico
como el sitio actual donde vive, permitiéndole las veces que desee el cambio de
ubicación del mismo. Para ello solo deberá ubicarse sobre el mapa y seleccionarlo.
Anexo 9.10.4
4.3.5. Registro de Parada Frecuente
El proceso de registro de la Parada Frecuente, permite al usuario (estudiante)
definir una parada actualmente existente como su preferida, pudiendo de la
misma forma cambiarla las veces que se desee. Para ello se mostrarán todas las
paradas existentes en el Store de tal manera que se podrá seleccionar la preferida
Cúmar Ramiro Cueva Tacuri
70
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
de forma gráfica. Anexo 9.10.5
La interfaz de la aplicación cliente puede ser encontrada en el Anexo: 0
4.4. Pruebas
El proceso de verificación para el funcionamiento del cliente y la consecuente
interacción con el API REST será evaluado mediante casos de prueba que
involucrarán todos los casos posibles así como las funciones existentes del cliente.
4.4.1. CASO 1
Nombre: Cédula Incorrecta
Descripción: Se proporciona al sistema una cédula incorrecta ya sea esta no
válida, incompleta o no numérica. Comprobando la reacción del
cliente.
Aspectos a Validar: Respuesta del cliente a ingreso de datos erróneos
Datos:
cedula: 1245785612 | 4556 | 45A8
Resultados: Al ingresar una cédula inválida, incompleta o alfanumérica los datos
son validados antes de llamar al servicio REST y se presenta un
mensaje indicando “Debe ingresar una cédula válida”. El mensaje
puede ser apreciado en el Anexo 0
4.4.2. CASO 2
Nombre: Cédula Correcta NO existente en el Store
Descripción: Se proporciona al sistema una cédula válida de un estudiante que
no ha sido agregado al store.
Aspectos a Validar: Ingreso automático de estudiantes. Procesos de agregar
Parada Frecuente y Vivienda por primera vez a un estudiante.
Datos:
cedula: 1104665623
Cúmar Ramiro Cueva Tacuri
71
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Resultados: El ingresar una cédula válida pero no existente en el Store, hace que
exista la opción de agregarla al Store o no. En caso de ingresarla se
podrá especificar tanto la posición de la vivienda como la Parada
Frecuente en el mapa.
Los mensajes visualizados en estos procesos, así como las
peticiones HTTP sobre el servicio REST pueden ser encontrados en
el Anexo 5.8.2.
4.4.3. CASO 3
Nombre: Cambiar Parada Frecuente y Vivienda
Descripción: Se proporciona al sistema una cédula válida de un estudiante
existente en el Store, el mismo que posee ya definidas su Parada
Frecuente y su Vivienda.
Aspectos a Validar: Carga de datos existentes. Cambio de Parada Frecuente y
Cambio de Vivienda.
Datos:
cedula: 1104665623
Resultados: El proceso y mensajes presentados son similares a los visualizados
al definir tanto la Parada Frecuente como Vivienda, por primera
ocasión. Esto determina que el usuario no tenga que realizar
procesos diferentes. Además, la aplicación refresca la localización
de estas, cada vez que son cambiadas, lo que permite tener una
interacción directa con la misma sin necesidad de recargar la
página. Mayor detalle puede ser encontrado en el Anexo 5.8.3.
Cúmar Ramiro Cueva Tacuri
72
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
5. DISCUSIÓN
La construcción de la plataforma POIS, ha permitido la integración de conceptos en una sola
solución funcional según los principios de Linked Data. Lo que demuestra la posibilidad de
acceso a datos públicos almacenados en un TripleStore desde un servicio REST.
Constituyendo, la creación del vocabulario, en una de las faces críticas del proyecto. Tanto por
la importancia de cumplir con el propósito de representar diversos tipos de Puntos de Interés
como de cumplir con el principio de reutilización. Luego del proceso de selección llegué a
determinar que solamente se puede reutilizar un elemento de un vocabulario ya existente,
como lo es Basic Geo, para la representación de un punto geográfico. Demostrando así, que
no existe aún un vocabulario capaz de abarcar atributos de diversos puntos de interés, por su
variada heterogeneidad.
De igual manera, el proceso de población del TripleStore en base a datos existentes y
almacenados en un ambiente relacional, no requiere de la realización de cambios drásticos en
la representación de información relacional para ser almacenada en tripletas. Es más, si la
información no hubiera estado en un RDBMS, el proceso de población hubiera tomado más
tiempo.
Además, el uso de REST para la interacción entre el cliente y el TripleStore permitió que se
integren conceptos de clases e individuos, lo que permitió desarrollar un API acoplado al
esquema del vocabulario RDF.
Un tema que requiere mayor análisis es la apertura al cliente de la modificación de los datos
en el TripleStore, proceso de modificación que fue solventado con las ventajas de Sparql 1.1,
esto debido a que si la información es pública la modificación no necesariamente debería
serlo, en especial si la información es relativa a preferencias del usuario (parada frecuente).
En el presente trabajo se ha utilizado una autenticación proporcionada por el TripleStore
Virtuoso, para evitar la manipulación de información, que si bien resuelve el problema de
modificación no autorizada, aún sigue siendo necesario el definir un esquema capaz de
permitir el acceso a los datos de forma pública y la modificación de los mismos solo por sus
creadores o personas con autorización.
Inconvenientes futuros también se han considerado, como el traslado del TripleStore a una
nueva ubicación (cambio de dirección) lo que haría necesario una actualización de todas las
aplicaciones que ya lo estén utilizando, solventando esto con la utilización de PURLs.
En definitiva puedo argumentar que el presente trabajo muestra la pauta necesaria para la
publicación y consumo de datos según LOD, lo que permite una interacción eficaz con la web
actual.
Cúmar Ramiro Cueva Tacuri
73
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
6. CONCLUSIONES
Al término del presente trabajo investigativo puedo concluir que:
La construcción de la Plataforma POIS, basada en los principios de Linked Data,
demuestra que el acceso y modificación de información localizada en el TripleStores
semánticos puede ser realizada de forma transparente para el usuario final (cliente).
Sin diferenciar la forma de almacenaje de la misma.
Dentro del proceso de construcción de un vocabulario para la representación de
datos, este debe contener la mayor cantidad de elementos reutilizados de
vocabularios existentes y ampliamente utilizados, lo que facilita el consumo e
integración de estos datos. Uno de los principios de Linked Data.
El proceso de migración de datos actualmente almacenados en ambientes
relacionales, es fácilmente transformado a un esquema semántico, considerando
primero la equivalencia de relaciones y el significado de los datos en base al
vocabulario RDF.
La organización de los datos en el TripleStore de acuerdo al vocabulario RDF, solo es
eficaz cuando existe una definición previa y estandarizada de URIs que representarán
los elementos, lo que facilita la localización de los mismos.
El uso de REST para el acceso a los datos en un TripleStore, resulta beneficioso puesto
que tanto REST como el vocabulario, que define el almacenamiento de los datos, se
basan en la definición de recursos (clases).
Sparql 1.1, también conocido como SPARUL permite completar el conjunto de
operaciones CRUD que se pueden realizar sobre los grafos del TripleStore y evitar el
uso de procesos asistidos.
Cúmar Ramiro Cueva Tacuri
74
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
7. RECOMENDACIONES
Durante el proceso de elaboración del presente trabajo investigativo se ha extraído las
siguientes recomendaciones:
Es necesario recomendar el uso de PURLs (direcciones URL permanentes) para todas
aquellas direcciones que involucren difusión, siendo necesario la creación de las
mismas en un servidor confiable.
Considerar siempre que si el valor almacenado como propiedad de una clase del
vocabulario es una URL (dirección de una imagen en el caso de POIS), esta debe ser
codificada para que no presente problemas al trabajar con navegadores.
Es recomendable validar cada uno de los componentes de la solución en base a los
principios de Linked Data que se pudieren aplicar, puesto que esto contribuirá a que
nuestros datos sean reutilizados.
Antes de realizar la publicación de datos, es recomendable considerar la clasificación
que estos datos tienen para el propietario, puesto que algunos pueden considerarse
datos personales que no podrán ser públicos.
Al publicar datos según LOD, se recomienda considerar el tema de modificación de los
mismos en el caso que estos dependan de terceras personas (usuario final) como es el
caso de la Plataforma POIS, para lo cual es necesario la utilización de un sistema de
autentificación.
Cúmar Ramiro Cueva Tacuri
75
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
8. BIBLIOGRAFÍA
[1] Miniwatts Marketing Group: Latin American Internet Usage Statistics. (2011)
http://www.internetworldstats.com/stats15.htm.
[2] LinkedData.org: Linked Data. Connect Distributed Data across the Web. (2010)
http://linkeddata.org/
[3] Wikipedia. Point of interest. (2011). Recuperado 22/02/2011. Disponible
http://en.wikipedia.org/wiki/Point_of_interest
[4] W3C.org: Resource Description Framework (RDF). (2004) http://www.w3.org/RDF/
[5] W3C.org: RDF Vocabulary Description Language 1.0: RDF Schema. (2004)
http://www.w3.org/TR/rdf-schema/
[6] Berners-Lee, T.: Linked Data. (2006) http://www.w3.org/DesignIssues/LinkedData.html
[7] WEC.org.: SPARQL Query Language for RDF. (2008). http://www.w3.org/TR/rdf-sparql-query/
[8] Wikipedia. SPARUL. (2010). http://en.wikipedia.org/wiki/SPARUL
[9]OpenLink. SPARUL -- an Update Language ForRDF Graphs. (2009)
http://docs.openlinksw.com/virtuoso/sparqlextensions.html#rdfsparul
[10] ARC. Easy RDF and SPARQL for LAMP systems. (2010) http://arc.semsol.org/
[11] W3C.org: Working Draft :SPARQL 1.1 Update. (14 Octubre 2010).
http://www.w3.org/TR/sparql11-update/
[12]OpenLink. Dbpedia Live Extraction. (2011) http://live.dbpedia.org/
[13] Max, B.: Context-aware Collaborative Creation of Semantic Points of Interest as Linked Data.
Thesis, Programa de Grado de Informática, University of Koblenz-Landau. (2009)
[14] Hegde, V. (febrero 2011). POIs in Semantic Web. Ponencia en el International AR Standards
Meeting, Barcelona, España
[15] LinkedDataTools. Introducing RDF/XML. (2010) http://www.linkeddatatools.com/introducingrdf-part-2
[16] INKDROID. The 5 Stars of Open Linked Data. (2010)
http://inkdroid.org/journal/2010/06/04/the-5-stars-of-open-linked-data/
[17] Stadler, C. Martin, M. Lehmann, J. Hellmann, S.: Update Strategies for DBpedia Live.
Departamento de Informática, Universidad Leipzig (Alemania)
Cúmar Ramiro Cueva Tacuri
76
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
[18]Bizer, C., Heath, T., Berners-Lee, T. Linked Data - The Story so Far. Paper presentado en:
Heath, T., Hepp, M., and Bizer, C. (eds.). Special Issue on Linked Data, International Journal on
Semantic Web and Information Systems (IJSWIS). http://linkeddata.org/docs/ijswis-specialissue
[19] Davis, I.: An Introduction to RDF. (2005) http://research.talis.com/2005/rdf-intro
[20] Lamarca, M.: RDF. (2009) http://www.hipertexto.info/documentos/rdf.htm
[21] Gómez, A.: La web de datos enlazados (Web of Linked Data). (2010). Ontología Grupo de
Ingeniería, Universidad Politécnica de Madrid. http://www.web-mix.ws/pyme/2010/06/laweb-de-datos-enlazados-web-of-linked-data/
[22] W3C.org.: Guía Breve de Linked Data. (2010)
http://www.w3c.es/divulgacion/guiasbreves/LinkedData
[23] Wisman, M.: Bringing Linked Data to the Geo World. (2009)
http://blog.safe.com/2009/07/bringing-linked-data-to-the-geo-world/
[24]W3C.org. Data Model. (2010). http://www.w3.org/2010/POI/wiki/Data_Model
[25]W3C.org. Cool URIs for the Semantic Web. (2008). http://www.w3.org/TR/cooluris/
[26] data.gov.uk - Opening up government. Creating URIs. http://data.gov.uk/resources/uris
[27] Drummond, Nick. OWLDoc - Plugin for Protégé. The University of Manchester.
http://code.google.com/p/co-ode-owl-plugins/wiki/OWLDoc
[28] Purlz.org. PURLs in the Wild. http://www.purlz.org/purls-in-the-wild
[29] Fielding T, Roy.: Architectural Styles and the Design of Network-based Software Architectures.
UNIVERSITY OF CALIFORNIA, IRVINE. (2000).
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
[30] Wright, Jacob: Simple REST server in PHP – Supports JSON & AMF.
http://jacwright.com/250/simple-rest-server-in-php-supports-json-amf/
[31] SourceForge: Quality Criteria for Linked Data sources.
http://sourceforge.net/apps/mediawiki/trdf/index.php?title=Quality_Criteria_for_Linked_Dat
a_sources. (2010)
Cúmar Ramiro Cueva Tacuri
77
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9. ANEXOS
Cúmar Ramiro Cueva Tacuri
78
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.1. ANEXO A
Cúmar Ramiro Cueva Tacuri
79
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
INSTALACIÓN DE PLUGIN - OWLDoc
El archivo instalador puede ser descargado desde la dirección:
http://code.google.com/p/persistenturls/downloads/list
a. En ventana principal de Protégé seleccionar la opción 'check for plugins...' del
menú 'File'
b. En la ventana lanzada 'Automatic Updates' buscar y seleccionar el plugin
'OWLDoc' dentro de la pestaña 'Downloads'.
c. Clic en el botón 'Install'
d. Reiniciar Protégé.
Utilizar Plugin:
a. Una vez terminada la ontología en Protégé seleccionar la opción 'Export
OWLDoc...' del menú 'Tools'
b. Seleccionar la ubicación en donde se almacenará los archivos (tiene que ser un
directorio válido)
El plugin OWLDoc genera un conjunto de archivos que contienen toda la información
relativa a la ontología, donde el archivo inicial está bajo en nombre de index.html.
Una vista inicial de la documentación se puede apreciar en la Figura 35.
Figura 35: Documentación Generada con OWLDoc
Cúmar Ramiro Cueva Tacuri
80
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.2. ANEXO B
Cúmar Ramiro Cueva Tacuri
81
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
CONFIGURACIONES - PURL
El servicio prestado por OCLC para la creación de dominios y PURLs individuales está
restringido para usuarios registrados. Para ello se debe llenar una forma de registro.
Figura 36: Registro Server PURL OCLC
Una vez dentro del Servicio PURL, es necesaria la creación de un Dominio, puesto
que toda PURL individual debe necesariamente pertenecer a un Dominio. El dominio
elegido estará bajo el nombre de POIS, es decir el dominio completo tendrá la
forma de:
http://purl.oclc.org/POIS
Este dominio es considerado de Alto Nivel, y OCLC deberá aprobarlo directamente
para su creación. Para ello se deberá llenar el formulario de Información sobre el
nuevo Dominio.
Cúmar Ramiro Cueva Tacuri
82
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 37: Registro de Dominio - PURL
Una vez aprobado el Dominio (proceso que lleva varios días) se puede proceder a
crear el PURL individual que re direccionará al servidor Apache donde se encuentra
nuestro vocabulario, tanto en formato RDF como HTML.
Figura 38: Registro de PURL Individual
Con lo que se obtiene un enlace entre el dominio de PURL y la dirección de nuestro
vocabulario.
Cúmar Ramiro Cueva Tacuri
83
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.3. ANEXO C
Cúmar Ramiro Cueva Tacuri
84
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
INSTALACIÓN DE SERVIDOR PURL
El archivo instalador puede ser descargado desde la dirección:
http://code.google.com/p/persistenturls/downloads/list
Para el ejemplo se creará la siguiente Persistent URL:
http://serverPurl/VOC/poisVocab
1. Ejecutar instalador:
$ java -jar PURLZ-Server-1.6.2.jar
2. Continuar con los pasos del wizard. En uno de ellos nos pedirá el puerto y host del
servicio. Si el servidor en el que se está instalando va a ser dedicado es mejor colocar
el puerto 80. De lo contrario cualquier otro. Esto por simplicidad en la dirección:
http://purl.example.com en lugar de http://purl.example.com:8080
Figura 39: Instalación PURL - Wizard
Cúmar Ramiro Cueva Tacuri
85
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
3. Configuraciones Adicionales. Especificar el BackEnd a utilizar, entre HSQLDB y MySQL.
Figura 40: Instalación PURL – Especificación de BackEnd
4. Configuraciones Adicionales. Definir la forma de creación de usuarios y la creación de
'Top Level Domains' similares a http://purl.example.com/NET/. Pudiendo ser
gestionadas por un administrador o no.
Figura 41: Instalación PURL – Permisos
Cúmar Ramiro Cueva Tacuri
86
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
5. Al finalizar la instalación podremos acceder a la interfaz de administración mediante
el uso del usuario 'admin' y la clave 'password' que se establecen por defecto.
Figura 42: PURL – Interfaz Principal
6. Desde la interfaz principal se crea el dominio de alto nivel VOC.
Figura 43: PURL – Creación de Dominio Público
7. Creamos la Persistent URL dentro de este dominio. Tomar en cuenta que para las
Cúmar Ramiro Cueva Tacuri
87
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
aplicaciones de Web Semántica es recomendado el uso de la redirección 303 puesto
que determina otro tipo de recursos. La dirección (recurso) a donde se re
direccionará será colocada en el campo “See Also URL”
Figura 44: PURL – Creación de Dirección
8. Permitir acceso público al servidor PURL
Por defecto la instalación de PURL solamente permite conexiones locales, para
colocarlo como un servicio público es necesario especificar el host o dirección ip que
se vinculará a este.
Para ello se localizar dentro del directorio de instalación el archivo:
modules/mod-purl-virtualhost/modules.xml
Y se añade la dirección pública o nombre de dominio del servidor en la sección
export del mismo. Con ello el servicio quedará de manera pública bajo un nombre de
dominio o una IP.
9. Obtendremos finalmente una PURL que redireccionará al valor colocado en el campo
‘See Also URL’.
http://[DIR_SERVIDOR]:8080/VOC/poisVocab
Cúmar Ramiro Cueva Tacuri
88
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.4. ANEXO D
Cúmar Ramiro Cueva Tacuri
89
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
APACHE WEB SERVER: Instalación y Configuración
Instalación
El proceso descrito a continuación es válido para el sistema operativo linux en su
distribución Ubuntu 11.04. Dentro de una terminal ejecutar ejecutar el siguiente
comando:
sudo apt-get install apache2
El cual descargará e instalará los archivos necesarios para que nuestro servidor
HTTP esté listo. A partir de la instalación es recomendable recordar los siguientes
directorios por defecto:
Directorio Instalación: /etc/apache2/
Directorio Web:
/var/www/
De igual forma el acceso al ‘demonio’ que controla el proceso es realizado
mediante las instrucciones:
/etc/init.d/apache2
start|stop|restart
Configuraciones
Para la instalación y activación del módulo de mod_rewrite, ejecutar la siguiente
instrucción en la terminal:
a2enmod rewrite
Las configuraciones de este módulo pueden ser colocadas dentro del archivo
principal de configuración de Apache HTTP Server o en un directorio específico
mediante el uso de un fichero .htaccess93. En este caso se utilizará un fichero
.htaccess y la siguiente estructura de directorios.
93
http://httpd.apache.org/docs/2.2/howto/htaccess.html
Cúmar Ramiro Cueva Tacuri
90
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 45: Estructura de Directorios
Donde el archivo vocabulario.rdf hace referencia al archivo del vocabulario
creado con la herramienta Protégé, mientras que el archivo vocabulario.html
corresponde al archivo index.html de la documentación del vocabulario que fue
generado con el plugin OWLDoc de Protégé. Se ha cambiado de nombre para
mantener una relación (visual) entre los dos archivos.
Ahora se debe definir el contenido del archivo .htaccess:
# Desactivar la visualización automática
# de archivos
Options -MultiViews
# Definir el tipo para el archivo .rdf
AddType application/rdf+xml .rdf
# Activar Modulo de SobreEscritura
RewriteEngine On
#Especificar URL base
RewriteBase /pois
# Especificar cuando se aplicará esta
# sobre escritura
RewriteCond %{HTTP_ACCEPT}
!application/rdf\+xml.*(text/html|application/xhtm
l\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml
[OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
# Documento que debe devolver basado
# en una petición HTML
RewriteRule ^conten$ contenido/vocabulario.html
[R=303]
Cúmar Ramiro Cueva Tacuri
91
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
# Documento que debe devolver basado
# en una petición RDF
RewriteRule ^conten$ contenido/vocabulario.rdf
[R=303]
Una vez creado el archivo .htaccess deberá ser colocado dentro del directorio
especificado en el parámetro RewriteBase, en este caso dentro del directorio
pois.
Con esto tendremos una configuración robusta capaz de responder a una petición
a la URI http://200.0.29.117:8080/pois/conten en función del contenido
solicitado.
Cúmar Ramiro Cueva Tacuri
92
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.5. ANEXO E
Cúmar Ramiro Cueva Tacuri
93
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
VAPOUR: VALIDACIÓN DE VOCABULARIO
Figura 46: URI y parámetros – VAPOUR
Cúmar Ramiro Cueva Tacuri
94
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 47: Petición RDF/XML – VAPOUR
Figura 48: Sin ‘Content Negotiation’ - VAPOUR
Cúmar Ramiro Cueva Tacuri
95
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 49: Class - Petición RDF/XML – VAPOUR
Figura 50: Class - Sin 'Content Negotiation' - VAPOUR
Cúmar Ramiro Cueva Tacuri
96
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 51: Property - RDF/XML – VAPOUR
Figura 52: Property - Sin 'Content Negotiation' - VAPOUR
Cúmar Ramiro Cueva Tacuri
97
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.6. ANEXO F
Cúmar Ramiro Cueva Tacuri
98
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
INSTALACIÓN DE VIRTUOSO SERVER
El proceso de instalación descrito a continuación es realizado sobre la distribución de
Linux Ubuntu. En esta distribución OpenLink Software94 mantiene Virtuoso OpenSource
dentro de los repositorios oficiales, puesto que el servidor no contendrá ninguna
configuración especial este método de instalación es adecuado, de lo contrario es
recomendable la instalación mediante el uso del código fuente95.
Actualizar los orígenes de datos
$ sudo apt-get update
Visualizar los paquetes disponibles, en caso de necesitar paquetes adicionales
$ apt-cache search '^virtuoso'
Descargar e Instalar
$ sudo aptitude install
virtuoso-opensource
Durante este proceso de instalación se notificará de la creación de dos usuarios con
privilegios de administrador en el servidor: “dba” y “dav” a los cuales se debe asignar una
clave. En este caso se ha colocado los valores:
dba
passwd: ‘dba’
dav
passwd: ‘dav’
Estos podrán ser utilizados en la interfaz de administración, la cual puede ubicada en la
siguiente dirección:
http://localhost:8890
94
http://www.openlinksw.com/
http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/VOSUbuntuNotes#Building Virtuoso from
Source
95
Cúmar Ramiro Cueva Tacuri
99
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 53: Interfaz Principal
El ingreso a la interfaz de administración proporcionada por Virtuoso bajo el nombre de
‘CONDUCTOR’ puede ser realizado mediante la URL:
http://localhost:8890/conductor
Esta permite tener un control total del servidor, desde donde se pueden gestionar
usuarios, servicios, paquetes, grafos entre otros.
Figura 54: Interfaz de Administración - CONDUCTOR
Cúmar Ramiro Cueva Tacuri
100
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
El proceso de iniciar, detener u obtener información sobre el proceso que ejecuta el
servidor puede ser llevado a cabo mediante la instrucción:
$ sudo /etc/init.d/virtuoso-opensource-6.1 [ start | stop |
status]
En ocasiones, cuando el servidor ha sido detenido de forma incorrecta puede presentar
problemas para iniciar nuevamente de forma automática, en estos casos, es
recomendable iniciar el servicio mostrando la información de log. Para ello ejecutamos el
siguiente comando, dentro del directorio database, el mismo que se encuentra dentro
de la instalación de Virtuoso:
$ virtuoso-t –df
Este mostrará información útil sobre el problema, uno de los más comunes es causado
por el archivo virtuoso.lck, el mismo que es creado en cada inicio del servidor, pero
si no ha sido borrado previamente por el servidor la instancia no se levantará
nuevamente. Si este fuera el problema, basta con eliminar el archivo virtuoso.lck
del directorio database de forma manual, para que el servicio vuelva a iniciar.
Cúmar Ramiro Cueva Tacuri
101
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.7. ANEXO G
Cúmar Ramiro Cueva Tacuri
102
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
VIRTUOSO: CARGA DE DATOS AL STORE
El proceso a seguir para la carga de datos desde un archivo de tripletas al Store,
es realizado mediante la interfaz principal CONDUCTOR, mediante los siguientes
pasos:
1. Hacer loggin en la interfaz principal con los datos user: dba passwd: dba
(Figura 54)
2. Bajo la pestaña RDF seleccionar la opción RDF Store Upload, la cual nos
permite efectuar la carga de datos desde un archivo, en este caso será el
que se creó con la aplicación anteriormente.
3. Una vez seleccionado el archivo y definido el nombre del grafo, completar
haciendo clic en el botón “UPLOAD”. El nombre del grafo definido será:
http://localhost:8890/poisV5
Figura 55: Carga de Archivo OWL
4. Una vez subidos los datos podremos comprobar la creación del grafo en
la opción Graphs.
Figura 56: Grafo Creado
5. La comprobación de la carga de las tripletas puede ser realizada mediante
la opción SPARQL, y ejecutando una consulta para extraer algunas
tripletas.
Cúmar Ramiro Cueva Tacuri
103
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 57: Verificación de Tripletas
Es importante notar que se ha definido el campo Default Graph IRI con el
nombre del grafo, indicando así al servidor de que grafo de recuperar las
tripletas.
Cúmar Ramiro Cueva Tacuri
104
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.8. ANEXO H
Cúmar Ramiro Cueva Tacuri
105
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
URIs – POIS REST SERVER
HTTP
METHOD
URI
Descripción
http://{dir_server}/pois
/point/$user/$pass/$lat/$lon
Crea un individuo del tipo
POINT
/poig/$user/$pass/$nombre/$point/$calle1/$calle2/$barrio/$sector
/poig/$user/$pass/$point/$calle1/$calle2/$barrio/$sector
Crea un individuo del tipo
POIG
/poig/$user/$pass/$point/$calle1/$calle2/$barrio
/parada/$user/$pass/$referencia/$img/$poig
/parada/$user/$pass/$img/$poig
Crear un individuo
PARADA
/parada/$user/$pass/$poig
/ordenparada/$user/$pass/$numsec/$parada
Crear individuo
ORDEN_PARADA
/ruta/$user/$pass/$nombre/$horario/$tipo
Crear individuo RUTA
/ordenparada/ruta/$user/$pass/$ruta/$ordParada
Relación entre un
elemento RUTA con un
ORDEN_PARADA
/paradafrecuente/$user/$pass/$parada
Crear individuo PARADA
FRECUENTE
POST
/estudiante/$user/$pass/$cedula/$poig/$prdfrc
/estudiante/$user/$pass/$cedula/$poig
/estudiante/$user/$pass/$cedula
Crear individuo
ESTUDIANTE
/estudiante2/$user/$pass/$cedula/$prdfrc
/estd_parada/$user/$pass/$estudiante/$prdfrc
Relación ESTUDIANTE con
PARADA_FRECUENTE
/estudiante/vivienda/$user/$pass/$estudiante/$poig
Relación con ESTUDIANTE
con su vivienda
/parada/$user/$pass/$parada/$poig
Reubicar parada
/ruta/horario/$user/$pass/$ruta/$horario
Agregar un horario a una
RUTA
PUT
Cúmar Ramiro Cueva Tacuri
106
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
/propiedad/$user/$pass/$individuo/$propiedad/$valor/$tipo
/propiedad/$user/$pass/$individuo/$propiedad/$valor
DELETE
/ruta/parada/$user/$pass/$ruta/$ordprd/$numsec
Agrega una nueva
PARADA a una RUTA
mediante el elemento
RUTA_PARADA
/ruta/horario/$user/$pass/$ruta/$horario
Borrar un Horario de una
RUTA
/ruta/$user/$pass/$ruta
Elimina una RUTA y sus
paradas únicas
/ruta/parada/$user/$pass/$ruta/$parada
Elimina una PARADA de
una RUTA
/individuo/$tipo/$propiedad/$valor/$tipoValor/$operador
/individuo/$tipo/$propiedad/$valor/$operador
GET
Actualizar propiedad de
un individuo
Extrae el identificador de
un individuo
/individuo/propiedad/$individuo
Extrae el valor de la
propiedad de un individuo
/individuos/fecha/$tipoIndv/$fechaIni/$fechaFin
Extrae el identificador de
un individuo basado en
fechas
/estudiante/parada/$estudiante
Extrae la parada frecuente
de un estudiante
/estudiante/vivienda/$estudiante
Extrae la vivienda actual
de un estudiante
/ruta/parada/$ruta
Devuelve todas las
paradas relacionadas con
una RUTA
/parada/
Devuelve todas las
paradas activas existentes
en el Store
/parada/ruta/$prd
Extrae todas las RUTAs y
sus respectivos horarios
que posean la PARADA
indicada.
Cúmar Ramiro Cueva Tacuri
107
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.9. ANEXO I
Cúmar Ramiro Cueva Tacuri
108
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
PRUEBAS SERVICIO REST - POIS
URI: /point/$user/$pass/$lat/$lon
DESCRIPCIÓN: Crear un individuo del Tipo POINT
HTTP: POST http://localhost/pois/point/test2/test2/-4.00135/-79.20124
RESPUESTA:
{
"status": "OK",
"indiv": "crd20110816220415"
}
STORE:
URI: /poig/$user/$pass/$nombre/$point/$calle1/$calle2/$barrio/$sector
DESCRIPCIÓN: Crea un individuo del Tipo POIG
HTTP: POST http://localhost/pois/poig/test2/test2/TestPois/crd20110816220415/1ero
de Mayo/10 de Agosto/Buena Esperanza/Centro
RESPUESTA:
{
"status": "OK",
"indiv": "pg20110816221900"
}
STORE:
Cúmar Ramiro Cueva Tacuri
109
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
URI: /poig/$user/$pass/$point/$calle1/$calle2/$barrio/$sector
DESCRIPCIÓN: Crea un individuo del Tipo POIG, sin especificar un nombre del mismo
HTTP: POST http://localhost/pois/poig/test2/test2/crd20110816220415/Olmedo/Abdon
Calderon/María Auxiliadora/San José
RESPUESTA:
{
"status": "OK",
"indiv": "pg20110816222408"
}
STORE:
URI: /poig/$user/$pass/$point/$calle1/$calle2/$barrio
DESCRIPCIÓN: Crea un individuo del Tipo POIG, sin especificar el nombre ni sector.
Cúmar Ramiro Cueva Tacuri
110
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
HTTP:
POST http://localhost/pois/poig/test2/test2/crd20110816220415/Av.
Octubre/Bolivar/Motupe
9
de
RESPUESTA:
{
"status": "OK",
"indiv": "pg20110816222945"
}
STORE:
URI: /parada/$user/$pass/$referencia/$img/$poig
DESCRIPCIÓN: Crea un individuo del tipo PARADA
HTTP: POST http://localhost/pois/parada/test2/test2/Junto a carpintería
Pinocho/paradaImg.png/pg20110816222945
RESPUESTA:
{
"status": "OK",
"indiv": "prd20110816224300"
}
STORE:
Cúmar Ramiro Cueva Tacuri
111
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
URI: /parada/$user/$pass/$img/$poig
DESCRIPCIÓN: Crea un individuo del tipo PARADA, sin especificar una referencia
HTTP: POST http://localhost/pois/parada/test2/test2/paradaImg.gif/pg20110816222945
RESPUESTA:
{
"status": "OK",
"indiv": "prd20110816224744"
}
STORE:
URI: /parada/$user/$pass/$poig
DESCRIPCIÓN: Crea un individuo del tipo PARADA, sin especificar una referencia ni una
imagen.
HTTP: POST http://localhost/pois/parada/test2/test2/pg20110816222945
RESPUESTA:
{
"status": "OK",
"indiv": "prd20110816225313"
}
STORE:
Cúmar Ramiro Cueva Tacuri
112
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
URI: /ordenparada/$user/$pass/$numsec/$parada
DESCRIPCIÓN: Crea un individuo del tipo ORDEN_PARADA
HTTP: POST http://localhost/pois/ordenparada/test2/test2/1/prd20110816225313
RESPUESTA:
{
"status": "OK",
"indiv": "ord20110816230103"
}
STORE:
URI: /ruta/$user/$pass/$nombre/$horario/$tipo
DESCRIPCIÓN: Crea un individuo del tipo RUTA
HTTP: POST http://localhost/pois/ruta/test2/test2/Belén - Bolonia/15:12:00/RECOGE
RESPUESTA:
{
"status": "OK",
"indiv": "ruta20110816230450"
}
STORE:
Cúmar Ramiro Cueva Tacuri
113
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
URI: /ordenparada/ruta/$user/$pass/$ruta/$ordParada
DESCRIPCIÓN: Establece la relación de un elemento ORDEN_PARADA con una RUTA
HTTP: POST
http://localhost/pois/ordenparada/ruta/test2/test2/ruta20110816230450/ord201
10816230103
RESPUESTA:
{
"status": "OK"
}
STORE:
URI: /paradafrecuente/$user/$pass/$parada
DESCRIPCIÓN: Crea un individuo del tipo, PARADA_FRECUENTE
HTTP: POST http://localhost/pois/paradafrecuente/test2/test2/prd20110816224300
RESPUESTA:
{
"status": "OK",
"indiv": "prdfrc20110816232851"
Cúmar Ramiro Cueva Tacuri
114
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
}
STORE:
URI: /estudiante/$user/$pass/$cedula/$poig/$prdfrc
DESCRIPCIÓN: Crea un individuo del tipo ESTUDIANTE
HTTP: POST
http://localhost/pois/estudiante/test2/test2/1104584875/pg20110816222408/pr
dfrc20110816232851
RESPUESTA:
{
"status": "OK",
"indiv": "estd20110816233215"
}
STORE:
URI: /estudiante/$user/$pass/$cedula/$poig
DESCRIPCIÓN: Crea un individuo
PARADA_FRECUENTE
del tipo ESTUDIANTE,
sin especificar
su
HTTP: POST
http://localhost/pois/estudiante/test2/test2/1109547875/pg20110816222408
Cúmar Ramiro Cueva Tacuri
115
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
RESPUESTA:
{
"status": "OK",
"indiv": "estd20110816233646"
}
STORE:
URI: /estudiante/$user/$pass/$cedula
DESCRIPCIÓN: Crea un individuo ESTUDIANTE con solamente su cédula
HTTP: POST http://localhost/pois/estudiante/test2/test2/1102507973
RESPUESTA:
{
"status": "OK",
"indiv": "estd20110816234709"
}
STORE:
URI: /estudiante2/$user/$pass/$cedula/$prdfrc
DESCRIPCIÓN: Crea un individuo ESTUDIANTE con su cédula y su parada frecuente
HTTP: POST
http://localhost/pois/estudiante2/test2/test2/1895123698/prdfrc2011081623285
Cúmar Ramiro Cueva Tacuri
116
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
1
RESPUESTA:
{
"status": "OK",
"indiv": "estd20110817003355"
}
STORE:
URI: /estd_parada/$user/$pass/$estudiante/$prdfrc
DESCRIPCIÓN: Relaciona un ESTUDIANTE con su PARADA_FRECUENTE
HTTP: POST
http://localhost/pois/estd_parada/test2/test2/estd20110816234709/prdfrc20110
816232851
RESPUESTA:
{
"status": "OK"
}
STORE:
URI: /estudiante/vivienda/$user/$pass/$estudiante/$poig
DESCRIPCIÓN: Relacionar un estudiante con su vivienda
HTTP: POST
Cúmar Ramiro Cueva Tacuri
117
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
http://localhost/pois/vivienda/estudiante/test2/test2/estd20110816234709/pg20
110816222945
RESPUESTA:
{
"status": "OK"
}
STORE:
URI: /parada/$user/$pass/$parada/$poig
DESCRIPCIÓN: Reubicar una parada existente
HTTP: PUT http://localhost/pois/parada/test2/test2/prd10/pg20110816222945
RESPUESTA:
{
"status": "OK"
}
STORE:
Cúmar Ramiro Cueva Tacuri
118
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
URI: /ruta/horario/$user/$pass/$ruta/$horario
DESCRIPCIÓN: Agregar un nuevo horario a una ruta
HTTP: PUT
http://localhost/pois/ruta/horario/test2/test2/ruta20110816230450/11:11:00
RESPUESTA:
{
"status": "OK"
}
STORE:
URI: /propiedad/$user/$pass/$individuo/$propiedad/$valor/$tipo
DESCRIPCIÓN: Actualiza la Propiedad de un Individuo
HTTP: PUT
http://localhost/pois/propiedad/test2/test2/estd20110816233215/cedula/123456
7890/string
RESPUESTA:
{
"status": "OK"
}
STORE:
Cúmar Ramiro Cueva Tacuri
119
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
URI: /propiedad/$user/$pass/$individuo/$propiedad/$valor
DESCRIPCIÓN: Actualiza la Propiedad de un Individuo valor de objetos
HTTP: PUT
http://localhost/pois/propiedad/test2/test2/estd20110816233215/ViveEn/pg102
RESPUESTA:
{
"status": "OK"
}
STORE:
URI: /ruta/parada/$user/$pass/$ruta/$ordprd/$numsec
DESCRIPCIÓN: Agrega una nueva PARADA a una RUTA mediante el elemento
RUTA_PARADA
HTTP: PUT http://localhost/pois/ruta/parada/test2/test2/rt18/orden3_5/5
RESPUESTA:
{
"status": "OK",
Cúmar Ramiro Cueva Tacuri
120
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
"message": "Nueva parada vinculada exitosamente"
}
STORE:
Antes:
Después:
URI: /ruta/horario/$user/$pass/$ruta/$horario
DESCRIPCIÓN: Borrar horario de una Ruta
HTTP: DELETE
http://localhost/pois/ruta/horario/test2/test2/ruta20110816230450/11:11:00
Cúmar Ramiro Cueva Tacuri
121
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
RESPUESTA:
{
"status": "OK"
}
STORE:
Antes:
Después:
URI: /ruta/$user/$pass/$ruta
DESCRIPCIÓN: Elimina una RUTA y sus paradas únicas
HTTP: DELETE http://localhost/pois/ruta/test2/test2/ruta20110731165403
RESPUESTA:
{
"status": "OK",
"message": "Ruta (ruta20110731165403) desactivada"
}
STORE:
Cúmar Ramiro Cueva Tacuri
122
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Antes:
Después:
URI: /ruta/parada/$user/$pass/$ruta/$parada
DESCRIPCIÓN: Elimina una PARADA de una RUTA
HTTP: DELETE http://localhost/pois/ruta/parada/test2/test2/rt31/prd51
RESPUESTA:
{
"status": "OK",
"message": "Parada eliminada"
}
STORE:
Antes:
Cúmar Ramiro Cueva Tacuri
123
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Después:
URI: /individuo/$tipo/$propiedad/$valor/$tipoValor/$operador
DESCRIPCIÓN: Extrae el identificador de un individuo
HTTP: GET http://localhost/pois/individuo/ESTUDIANTE/cedula/1102507973/string/=
RESPUESTA:
{ "head": { "link": [ ],
"vars": [ "obj" ] },
"results": {
"distinct": false,
"ordered": true,
"bindings": [
{
"obj": {
"type": "uri",
"value": "http: //localhost: 8080/pois/vcblr/indv/#estd20110816234709"
}}]}}
URI: /individuo/$tipo/$propiedad/$valor/$operador
DESCRIPCIÓN: Extrae el identificador de un individuo (basado en otro individuo)
Cúmar Ramiro Cueva Tacuri
124
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
HTTP: GET http://localhost/pois/individuo/PARADA/LocalizadaEn/pg39/=
RESPUESTA:
{ "head": { "link": [ ],
"vars": [ "obj" ] },
"results": {
"distinct": false,
"ordered": true,
"bindings": [
{
"obj": {
"type": "uri",
"value": "http: //localhost: 8080/pois/vcblr/indv/#prd39"
}}]}
URI: /individuo/propiedad/$individuo
DESCRIPCIÓN: Extrae todas las propiedades de un determinado individuo
HTTP: GET http://localhost/pois/individuo/propiedad/pg39
RESPUESTA:
{
.
.
.
"type": "uri",
"value": "http: //purl.oclc.org/POIS/vcblr/#POIG"
}
},
{
"prop": {
"type": "uri",
"value": "http: //purl.oclc.org/POIS/vcblr/#calle1"
},
"valor": {
"type": "typed-literal",
"datatype": "http: //www.w3.org/2001/XMLSchema#string",
"value": "Av. 8 de Diciembre"
}
Cúmar Ramiro Cueva Tacuri
125
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
.
.
.
}
URI: /individuos/fecha/$tipoIndv/$fechaIni/$fechaFin
DESCRIPCIÓN: Extrae todos los individuos que posean el atributo fecha entre los dos
valores especificados.
HTTP: GET http://localhost/pois/individuos/fecha/POIG/2011-06-14/2011-06-16
RESPUESTA:
{
.
.
.
"type": "uri",
"value": "http: //localhost: 8080/pois/vcblr/indv/#pg4"
},
"prop": {
"type": "typed-literal",
"datatype": "http: //www.w3.org/2001/XMLSchema#date",
"value": "2011-06-15"
}
},
{
"obj": {
"type": "uri",
"value": "http: //localhost: 8080/pois/vcblr/indv/#pg6"
.
.
.
}
URI: /estudiante/parada/$estudiante
Cúmar Ramiro Cueva Tacuri
126
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
DESCRIPCIÓN: Obtiene la parada frecuente de un estudiante
HTTP: GET http://localhost/pois/estudiante/parada/estd20110731172927
RESPUESTA:
{ "head": {"link": [ ], "vars": [ "parada", "fechaSelec" ] },
"results": {
"distinct": false,
"ordered": true,
"bindings": [
{
"parada": {
"type": "uri",
"value": "http: //localhost: 8080/pois/vcblr/indv/#prd20110731161335"
},
"fechaSelec": {
"type": "typed-literal",
"datatype": "http: //www.w3.org/2001/XMLSchema#date",
"value": "2011-07-31"
}}]}}
URI: /estudiante/vivienda/$estudiante
DESCRIPCIÓN: Obtiene la vivienda actual de un determinado estudiante.
HTTP: GET http://localhost/pois/estudiante/vivienda/estd20110731172927
RESPUESTA:
{
.
.
.
"type": "uri",
"value": "http: //localhost: 8080/pois/vcblr/indv/#pg20110731151108"
},
"fechaCreac": {
"type": "typed-literal",
"datatype": "http: //www.w3.org/2001/XMLSchema#date",
"value": "2011-07-31"
},
Cúmar Ramiro Cueva Tacuri
127
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
"lat": {
"type": "typed-literal",
"datatype": "http: //www.w3.org/2001/XMLSchema#integer",
.
.
.
}
URI: /ruta/parada/$ruta
DESCRIPCIÓN: Devuelve todas las paradas relacionadas con una ruta determinada.
HTTP: GET http://localhost/pois/ruta/parada/rt45
RESPUESTA:
{
.
.
.
"lon": {
"type": "typed-literal",
"datatype": "http: //www.w3.org/2001/XMLSchema#double",
"value": "-79.20137875411901"
}
},
{
"orden": {
"type": "typed-literal",
"datatype": "http: //www.w3.org/2001/XMLSchema#int",
"value": "2"
},
"parada": {
"type": "uri",
"value": "http: //localhost: 8080/pois/vcblr/indv/#prd66"
},
"lat": {
"type": "typed-literal",
"datatype": "http: //www.w3.org/2001/XMLSchema#double",
.
Cúmar Ramiro Cueva Tacuri
128
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
.
.
}
URI: /parada/
DESCRIPCIÓN: Extrae todas las paradas existentes en el Store.
HTTP: GET http://localhost/pois/parada/
RESPUESTA:
{
.
.
.
"type": "uri",
"value": "http: //localhost: 8080/pois/vcblr/indv/#prd20110731161335"
},
"lat": {
"type": "typed-literal",
"datatype": "http: //www.w3.org/2001/XMLSchema#integer",
"value": "5"
},
"lon": {
"type": "typed-literal",
"datatype": "http: //www.w3.org/2001/XMLSchema#integer",
"value": "7"
.
.
.
}
URI: / parada/ruta/$prd/
DESCRIPCIÓN: Devuelve todas las RUTAS de una determinada PARADA así como sus
horarios.
HTTP: GET http://localhost/pois/parada/ruta/prd25
RESPUESTA:
Cúmar Ramiro Cueva Tacuri
129
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
{
.
.
.
"nomb": {
"type": "typed-literal",
"datatype": "http://www.w3.org/2001/XMLSchema#string",
"value": "Av. Orillas del Zamora, Calle Guayaquil, Av. Salvador Bustamante,
SOLCA, La Paz, Colegio Militar, Cdla. La Banda."
}
,
"hr": {
"type": "typed-literal",
"datatype": "http://www.w3.org/2001/XMLSchema#time",
"value": "12:35:00-05:00"
}
,
"tp": {
"type": "typed-literal",
"datatype": "http://www.w3.org/2001/XMLSchema#string",
"value": "BAJA"
.
.
.
}
Cúmar Ramiro Cueva Tacuri
130
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.10. ANEXO J
Cúmar Ramiro Cueva Tacuri
131
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
CASOS DE USO
9.10.1.
Existencia de Estudiante
Existencia de Estudiante
App Cliente
Ingreso Cédula
Sin Acceso
9.10.2.
Rest API
Comprobar
existencia en el Store
Agregarlo al Store
Permitir Acceso
Store Virtuoso
Devolver Tripletas
Guardar Tripletas
Visualizar Vivienda
Visualizar Vivienda
Rest API
Store Virtuoso
Procesa y Dibuja
Vivienda
Consultar Vivienda
(posicion - informacion)
Devolver Tripletas
App Cliente
Cúmar Ramiro Cueva Tacuri
132
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.10.3.
Visualizar Parada Frecuente
Visualizar Parada Frecuente
Rest API
Store Virtuoso
Procesa y Dibuja
Parada Frecuente
Consultar Parada
Frecuente (posicion informacion)
Devolver Tripletas
App Cliente
9.10.4.
Registro de Vivienda
Registro de Vivienda
App Cliente
Activa Modo
Selección de Vivienda
Rest API
Store Virtuoso
Registra nuevo
sitio
Transmite Datos
usuario
Guardar Tripletas
Ingresa Información
Visualización de
Vivienda
Cúmar Ramiro Cueva Tacuri
133
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.10.5.
Registro de Parada Frecuente
Registro de Parada Frecuente
App Cliente
Activa Modo Selección
de Parada Frecuente
Rest API
Solicita los datos
de todas las paradas
Store Virtuoso
Devuelve Tripletas
Grafica todas las
paradas
usuario
Selecciona Parada
Transmite Datos
Guardar Tripletas
Visualización de
Parada Frecuente
Cúmar Ramiro Cueva Tacuri
134
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.11. ANEXO K
Cúmar Ramiro Cueva Tacuri
135
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
INTERFAZ DE CLIENTE
9.11.1.
INGRESO
9.11.2.
PRINCIPAL
Cúmar Ramiro Cueva Tacuri
136
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.11.3.
VIVIENDA
9.11.4.
PARADA FRECUENTE
Cúmar Ramiro Cueva Tacuri
137
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.11.5.
PARADAS EXISTENTES
Cúmar Ramiro Cueva Tacuri
138
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.12. ANEXO L
Cúmar Ramiro Cueva Tacuri
139
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
5.8.1 CASO 1: Cédula Incorrecta
Figura 58: Mensaje de Error al ingresar una cédula incorrecta,
incompleta o alfanumérica.
5.8.2 CASO 2: Cédula Correcta NO existente en el Store
En caso de aceptar estos datos son almacenados en el Store mediante el Servicio
REST y se presenta un mensaje de bienvenida.
Figura 59: Mensaje para ingresar un nuevo individuo.
Figura 60: Mensaje de bienvenida.
Cúmar Ramiro Cueva Tacuri
140
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
El proceso de vinculación de una vivienda inicia luego de hacer clic sobre el
botón ‘Mi Casa’ mostrando un mensaje de información sobre el proceso a seguir.
Siendo este la selección de un punto cualquiera sobre el mapa que será tomado
como el sitio donde se ubicará la nueva vivienda.
Figura 61: Aviso de Selección
Una vez ubicado el sitio se deberá completar cierta información necesaria que
hará mención a la localización de la vivienda, la misma que es relativa a calles y
barrio.
Figura 62: Formulario sobre Vivienda
Toda la información ingresada anteriormente puede ser observadas haciendo
clic sobre el icono de la vivienda que se ha colocado automáticamente luego del
proceso.
Cúmar Ramiro Cueva Tacuri
141
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Figura 63: Información sobre Vivienda
El proceso de selección de una Parada Frecuente inicia al hacer clic sobre el
icono “Mi Parada” con esto se muestran sobre el mapa todas las paradas
existentes en el Store y actualmente activas, en donde el usuario puede
seleccionar una de ellas haciendo clic y se visualizará información relativa a
localización y una imagen de la localización real.
Para aceptar una de estas como parada frecuente basta con hacer clic sobre el
botón “Seleccionar” del PopUp desplegado.
Figura 64: Selección de Parada Frecuente
Cúmar Ramiro Cueva Tacuri
142
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Una vez seleccionada la interfaz será actualizada y se mostrará sobre el mapa
solo la parada seleccionada de la cual se puede extraer más información relativa
a las Rutas y horas en las que pasa un recorrido por esta parada.
Figura 65: Información sobre Parada
Una característica especial del cliente es la capacidad de visualizar solamente la
información requerida, pudiendo ser esta filtrada mediante la activación y
desactivación de capas, a través del selector ubicado en la parte derecha
superior de la aplicación.
Figura 66: Capas visibles
Cúmar Ramiro Cueva Tacuri
143
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
Todo el proceso de visualización y actualización es realizado mediante el Servicio
REST creado para la Plataforma POIS.
Figura 67: Peticiones REST
5.8.3 CASO 3: Cambiar Parada Frecuente y Vivienda
El proceso de Cambio de Parada Frecuente y Vivienda sigue el mismo
procedimiento relatado en el apartado 5.8.2. Facilitando al usuario la interacción
con la aplicación.
Cúmar Ramiro Cueva Tacuri
144
Universidad Técnica Particular de Loja
POIS - Points Of Interest Semantic
9.13. ANEXO M - PAPER
Plataforma POIS – Linked Data
Cueva T, Cúmar R#, López V, Jorge A*
#
Sistemas Informáticos y Computación – UTPL
*
Tecnologías avanzadas de la Web- UTPL
1
[email protected]
[email protected]
2
Abstract— Plataforma Points of Interesting Semantic (POIS), se
basa en la implementación de un Vocabulario genérico para la
representación de Puntos de Interés de diversa índole. Siendo
prueba de concepto la aplicación a las paradas de los buses de la
UTPL, integrando datos de estudiantes como su Parada
Frecuente y la localización de su vivienda.
Vocabulario:
/{prefijo}/{vocabulary}
Clases:
/{prefijo}/{vocabulary}#{class}
Propiedades:
/{prefijo}/{vocabulary}#{property}.
Keywords— POIS - LINKED DATA - REST - WEB SERVICE
- VOCABULARIO
INTRODUCCIÓN
La plataforma POIS contempla la construcción de un
vocabulario genérico para la representación de puntos de
interés, así como la implementación de un método de
actualización de datos en el TripleStore por parte del usuario
final mediante la utilización de un Servicio REST.
VOCABULARIO
El componente inicial para definir el almacenaje y
representación de los datos.
Construcción
La construcción del vocabulario está basada en la selección
de elementos iniciales que hacen referencia a puntos de interés
diversos y en especial características del sistema de
transportación estudiantil de la UTPL.
La formulación de interrogantes en torno a estos elementos
y una asignación de prioridad permiten definir atributos
iniciales sobre los que se moldea el vocabulario. Estos
elementos plenamente identificados, son comparados con
elementos de vocabularios existentes para la selección de
términos que puedan ser reutilizables. Cumpliendo así con
uno de los principios de Linked Data.
Elementos
seleccionados en la Tabla 1.
En el caso de la plataforma POIS solo es posible la
reutilización de un elemento del vocabulario Basic Geo [1],
para la representación de puntos geográficos.
El modelado y la relación entre los conceptos han sido
realizados mediante la herramienta Protégé [2].
Definición de URIs
Las URIs que posee el vocabulario, así como las utilizadas
para la publicación, están definidas bajo el esquema ‘hash
namespace’ [3] donde se utiliza el símbolo ‘comodín’ (#) para
la identificación de los recursos
Obteniendo una distribución de la siguiente manera:
TABLA I
CONCEPTOS DE VOCABULARIO
Conceptos
RUTA
PARADA
ESTUDIANTE
POIG
ORDEN PARADA
PARADA FRECUENTE
Propiedades
Nombre
Tipo
Horario
Fecha
Activa
Referencia
Activa
Imagen
cedula
Calle 1
Calle 2
Barrio
Sector
Nombre
Fecha
Num_Secuencia
Fecha
VALIDACIÓN
Se han efectuado dos procesos de validación, una para
determinar que el vocabulario cumple con las expectativas
necesarias y otra para comprobar la correcta publicación del
vocabulario según los principio de LOD[4].
En el caso de validar el objetivo del vocabulario se ha
creado un conjunto de instancias de prueba que han sido
montados en la herramienta de navegación Gruff para
AllegroGraph[5] y sobre los cuales se ha efectuado consultas
SPARQL para resolver la mayor cantidad de inquietudes
planteadas en la construcción del Vocabulario.
El vocabulario final puede ser encontrado en la dirección:
http://www.box.net/shared/88cz8c06ojanjlhs11r6
Publicación
El proceso de publicación es efectuado con la creación del
vocabulario accesible en dos formatos RDF y HTML. El
formato HTML ha sido generado mediante el uso del plugin
OWLDoc[6] de Protégé que permite generar una descripción
de los conceptos y sus relaciones.
Este proceso de publicación utiliza PURLs[7] y una
negociación de contenidos para la identificación del recurso a
recuperar, en este caso, la negociación de contenidos[8] ha
sido implementada en un servidor web Apache mediante el
uso de reglas colocadas en un archivo .httaccess. El
funcionamiento se muestra en la Fig. 1.
para acceso a los datos y el soporte para la utilización de
SPARQL 1.1.[11]
El EndPoint generalmente se encuentra en la dirección:
http://servidor.com:8890/sparql
B. Población del Store
Los datos iniciales que tendrá el Store se encontraron
almacenados en una base de datos relacional, por lo que se
efectuó una migración de estos datos, en base al diagrama de
la Fig. 3.
Una vez transformados estos datos a tripletas en base al
vocabulario, fueron insertadas en el Store haciendo uso de la
interfaz de administración disponible, conocida como
CONDUCTOR. Lo que permite tener hasta este punto el Store
poblado y listo.
Fig. 1 Funcionamiento de PURL y la negociación de contenido
De esta forma se ha construido la URL Permanente como:
http://purl.oclc.org/POIS/vcblr
La misma que enlaza a una URI des referenciada que
contiene al vocabulario en sus dos formatos:
http://200.0.29.117:8080/pois/conten
La validación de la correcta publicación ha sido realizada
mediante consultas individuales utilizando la utilidad CURL y
su parámetro HEADER, lo que permite diferenciar el
contenido a recuperar.
Para determinar si los principios establecidos en LOD para
la publicación de Vocabularios han sido cumplidos se ha
utilizado la herramienta VAPOUR[9] desarrollada por la
Fundación CTIC.
Utilizando configuraciones propias para un vocabulario, el
test realizado con VAPOUR ha demostrado que la publicación
cumple con todos los requisitos. Los resultados pueden ser
observados en la Fig. 2.
SERVICIO REST
La interacción entre las instancias del vocabulario y el
usuario final, será realizada mediante la implementación de un
Servicio REST.
A. TripleStore
El almacenaje de las tripletas ha sido realizado sobre un
servidor Virtuoso en su versión OpenSource[10], siendo una de
sus principales fortaleces el proveer por defecto un EndPoint
C. Sparql basado en REST
REST,[12] cuya representación se interpreta como
Transferencia de Estado Representacional, originado a partir
de la tesis doctoral de Roy Fielding, establece la creación e
interacción de servicios en la red utilizando un protocolo
cliente/servidor sin estado, conteniendo en una sola petición
HTTP toda la información suficiente para procesarla.
Siguiendo este principio, Virtuoso permite el acceso a su
EndPoint utilizando esta tendencia, para ello es necesaria la
especificación de ciertos parámetros que deberán ser
utilizados al efectuar una petición. Una lista resumen puede
ser apreciada en la Tabla II.
Además, para el trabajo mediante REST, se ha determinado
la utilización del formato JSON debido a la gran acogida que
posee para el desarrollo de aplicaciones web y la
representación de datos.
TABLA III
PARÁMETROS CONSULTA REST – ENDPOINT VIRTUOSO
Parámetro
query
dflt_graph
maxrows
timeout
Descripción
Consulta Sparql
URI del gráfico por
defecto (string o NULL)
Límite de filas mostradas
Tiempo máximo de
duración de la consulta
Requerido?
Yes
No
No
No
En este proceso de extracción de datos desde el Store, al
igual que en la inserción, se debe considerar el almacenaje de
direcciones URL como valores de una propiedad
perteneciente a una instancia del vocabulario. Puesto que estos
no pueden ser almacenados en forma directa sino una vez que
hayan sido codificados, siendo útiles las funciones del
lenguaje php, urlencode() y urldecode(). [13]
Esto para evitar que el navegador interprete directamente
estos valores como direcciones que tenga que mostrar en lugar
de solo extraerlas.
D. Autenticación EndPoint
El uso de Sparql 1.1 para completar el esquema CRUD,
mediante operaciones de borrado, actualización y creación de
tripletas, lleva a la necesidad de la utilización de un
mecanismo que permita solo a determinado grupo la
modificación de los datos en el Store, esto para garantizar la
fiabilidad de los datos, puesto que seguiría el principio de:
público para todos editable para pocos.
F. Implementación de Servicio REST
Para la implementación del Servicio REST, se ha utilizado
el lenguaje PHP, debido a que permite el acoplamiento
perfecto para el manejo de peticiones HTTP.
Utilizando además, un framework basado en Recess, el
mismo que es una versión más simplificada y que presenta
facilidad de uso. [16]
Este framework permite hacer un mapeo directo desde una
URL a un método PHP, por medio de la utilización de las
partes de la URL, así como el método de la petición HTTP
que son enlazados directamente a una de las operaciones
CRUD. Como se puede apreciar en la Tabla IV.
Entre las principales funcionalidades que han sido
implementadas se mencionan:
Eliminar una Ruta:
Http: DELETE
URI: /ruta/$user/$pass/$ruta
Agregar una Nueva Parada
Http: PUT
URI: /ruta/parada/$user/$pass/$ruta/$ordprd/$numsec
Fig. 2 Resultados de Validación con VAPOUR
En este caso se ha hecho uso de las funcionalidades del
Store, el mismo que permite la gestión de usuarios y roles,
haciendo de esta forma que el acceso para modificar el Store
sea controlado mediante la utilización de un método de
autenticación Digest, basado en usuario y clave. [14]
Eliminar Parada
Http: DELETE
URI: /ruta/parada/$user/$pass/$ruta/$parada
Actualizar Propiedad
Http: PUT
URI: /propiedad/$user/$pass/$indv/$prop/$valor/$tipo
/propiedad/$user/$pass/$indv/$prop/$valor
Para ello es necesario acceder a una segunda interfaz del
EndPoint bajo esta dirección:
http://servidor.com:8890/sparql-auth
Otros métodos que pudieren se aplicados y que abarca este
trabajo contemplan la utilización de WebID y OAuth, también
soportados por Virtuoso.
E. Vocabulary of Interlinked Datasets (VoID)
Una propuesta del Digital Enterprise Research Institute
(DERI) y adoptada por la W3C como una nota de grupo de
interés permite expresar metadatos sobre los DataSets de
tripletas, intentando de esta forma ser un punto de enlace entre
quienes publican el DataSet y los que lo usan. Permitiendo
que herramientas personalizadas puedan examinar el
documento y catalogar el DataSet, basándose para ello en el
uso de, principalmente, el vocabulario Dublin Core. [15]
Para ello se hará uso de un editor online conocido como
ve2, aquí se especifica datos relativos a autor, dirección del
vocabulario y dataset. De igual forma la licencia de los datos.
Este además permite difundir el dataset(documento void)
en varios sitios como Sindice, voiD Store, voiD Browser y
PTSW.
Fig. 3 Esquema de datos Relacionales
La comprobación del funcionamiento de cada uno de estas
ha sido evaluada mediante la utilización del complemento
RESTClient 1.3.4 para el navegador Firefox. [17]
CLIENTE
La prueba de concepto para la plataforma POIS se basa en
la construcción de un Cliente básico capaz de hacer uso del
servicio REST y extraer/modificar la información contenida
en el Store desde un ambiente Web.
A. Tecnologías
El cliente ha sido elaborado mediante la utilización del
Framework ExtJs, [18] por la versatilidad para el desarrollo de
aplicaciones RIA así como el manejo de operaciones
Asíncronas. Integrado con el api OpenLayers [19] para el
manejo de mapas y operaciones sobre este.
TABLA IV
RELACIÓN ENTRE MÉTODOS HTTP Y CRUD
Operación
Create
Read
Update
Delete
SQL
Insert
Select
Update
Delete
HTTP
POST
GET
PUT
DELETE
de relaciones y el significado de los datos en base al
vocabulario RDF.
La organización de los datos en el TripleStore de acuerdo al
vocabulario RDF, solo es eficaz cuando existe una
definición previa y estandarizada de URIs que representarán
los elementos, lo que facilita la localización de los mismos.
El uso de REST para el acceso a los datos en un TripleStore,
resulta beneficioso puesto que tanto REST como el
vocabulario, que define el almacenamiento de los datos, se
basan en la definición de recursos (clases).
Sparql 1.1, también conocido como SPARUL permite
completar el conjunto de operaciones CRUD que se pueden
realizar sobre los grafos del TripleStore y evitar el uso de
procesos asistidos.
REFERENCIAS
W3C
De esta forma se han implementado las funcionalidades
siguientes:
1) Verificación de Existencia de Estudiante
2) Visualización de Vivienda
3) Visualización de Parada Frecuente
4) Registro de Vivienda
5) Registro de Parada Frecuente
CONCLUSIONES
La construcción de la Plataforma POIS, basada en los
principios de Linked Data, demuestra que el acceso y
modificación de información localizada en el TripleStores
semánticos puede ser realizada de forma transparente para el
usuario final (cliente). Sin diferenciar la forma de
almacenaje de la misma.
Dentro del proceso de construcción de un vocabulario para
la representación de datos, este debe contener la mayor
cantidad de elementos reutilizados de vocabularios
existentes y ampliamente utilizados, lo que facilita el
consumo e integración de estos datos. Uno de los principios
de Linked Data.
El proceso de migración de datos actualmente almacenados
en ambientes relacionales, es fácilmente transformado a un
esquema semántico, considerando primero la equivalencia
Semantic
Web
Interest
Group
(2003):
http://www.w3.org/2003/01/geo/wgs84_pos#
Stanford Center for Biomedical Informatics Research: Protégé. Standford
University (2011): http://protege.stanford.edu/
data.gov.uk
Opening
up
government.
Creating
URIs.
http://data.gov.uk/resources/uris
Berners-Lee,
T.:
Linked
Data.
(2006)
http://www.w3.org/DesignIssues/LinkedData.html
Franz Inc.(2011):Gruff-A Grapher-Based Triple-Store Browser for
AllegroGraph. http://www.franz.com/agraph/gruff/
Drummond, Nick. OWLDoc - Plugin for Protégé. The University of
Manchester.
http://code.google.com/p/co-ode-owlplugins/wiki/OWLDoc
OCLC.(2010): PURL. http://purl.oclc.org
Apache
Fundation
(2011):
Content
Negotiation.
http://httpd.apache.org/docs/trunk/content-negotiation.html
Fundación CTIC (2011): VAPOUR a Linked Data validator.
http://vapour.sourceforge.net/
OPENLINK SOFTWARE.(2011): Virtuoso Universal Server OpenSource.
http://virtuoso.openlinksw.com/
W3C.org: Working Draft :SPARQL 1.1 Update. (14 Octubre 2010).
http://www.w3.org/TR/sparql11-update/
Fielding T, Roy.: Architectural Styles and the Design of Network-based
Software Architectures. UNIVERSITY OF CALIFORNIA, IRVINE.
(2000). http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
PHP(2010): URLENCODE. http://php.net/manual/es/function.urlencode.php
OpenLink (2009): 16.2.3.4. Service Endpoint Security: Authentication.
http://docs.openlinksw.com/virtuoso/rdfsparql.html
W3C Interest Group Note(2011): Describing Linked Datasets with the VoID
Vocabulary. http://www.w3.org/TR/void/
Wright, Jacob: Simple REST server in PHP – Supports JSON & AMF.
http://jacwright.com/250/simple-rest-server-in-php-supports-json-amf/
ZHOU, Chao (2011): RESTClient Complemento para Firefox.
https://addons.mozilla.org/es-ES/firefox/addon/restclient/
Sencha (2011): ExtJS: JavaScript Framework for Rich Apps in Every
Browser. http://www.sencha.com/products/extjs/
Open Source Geospatial Foundation: OpenLayers: Free Maps for the Web.
http://openlayers.org/
