Plataforma POIS Linked Data. Aplicación a los recorridos de los buses de la UTPL

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Plataforma POIS Linked Data. Aplicación a los recorridos de los buses de la UTPL"

Transcripción

1 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

2 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

3 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

4 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

5 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

6 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

7 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

8 ÍNDICE DE CONTENIDOS CERTIFICACIÓN CERTIFICACIÓN AUTORÍA CESIÓN DE DERECHOS AGRADECIMIENTO DEDICATORIA I II III IV V VI ÍNDICE DE FIGURAS 1 ÍNDICE DE TABLAS 3 1. ESTADO DEL ARTE Introducción Linked Data RDFStore Sparql Update SPARUL y El Proceso Asistido de Actualización Puntos de Interés Trabajo Relacionado Trabajo futuro VOCABULARIO RDF Construcción Selección de Elementos Preliminares y Formulación de Interrogantes 17

9 Definición de Elementos Finales y sus Atributos Estructura de Vocabulario Consideraciones de Nomenclatura Descripción de Conceptos Esquema Preliminar Esquema Final Relaciones Binarias Diagrama RDF Validación del Vocabulario Instancias de Vocabulario Consultas SPARQL Resultados de Validación URI s Definición Uri s para el Vocabulario Publicación de Vocabulario Generación de la Descripción del Vocabulario PURL Configuraciones Apache HTTP Server Negociación de Contenido (Content Negotiation) Configuraciones Pruebas VAPOUR BACKEND OpenLink Virtuoso Carga de Tripletas al Store Sparql Endpoint Formatos de Respuesta SPARQL basado en REST Pruebas Autenticación sobre EndPoint Pruebas 53

10 3.2. Vocabulary of Interlinked Datasets (VoID) Servicio REST - CRUD Framework Funcionamiento del Servidor REST URIs de Recursos Métodos del API Eliminar una Ruta Agregar una nueva parada Eliminar parada Actualizar Propiedad URL para Imágenes Pruebas CLIENTE Tecnologías Integración Funcionalidades Verificación de Existencia de Estudiante Visualización de Vivienda Visualización de Parada Frecuente Registro de Vivienda Registro de Parada Frecuente Pruebas CASO CASO CASO DISCUSIÓN CONCLUSIONES 74

11 7. RECOMENDACIONES BIBLIOGRAFÍA ANEXOS ANEXO A 79 INSTALACIÓN DE PLUGIN - OWLDoc ANEXO B 81 CONFIGURACIONES - PURL ANEXO C 84 INSTALACIÓN DE SERVIDOR PURL ANEXO D 89 APACHE WEB SERVER: Instalación y Configuración 90 Instalación 90 Configuraciones ANEXO E 93 VAPOUR: VALIDACIÓN DE VOCABULARIO ANEXO F 98 INSTALACIÓN DE VIRTUOSO SERVER ANEXO G 102 VIRTUOSO: CARGA DE DATOS AL STORE ANEXO H 105 URIs POIS REST SERVER ANEXO I 108 PRUEBAS SERVICIO REST - POIS ANEXO J 131 CASOS DE USO Existencia de Estudiante 132

12 Visualizar Vivienda Visualizar Parada Frecuente Registro de Vivienda Registro de Parada Frecuente ANEXO K 135 INTERFAZ DE CLIENTE INGRESO PRINCIPAL VIVIENDA PARADA FRECUENTE PARADAS EXISTENTES ANEXO L CASO 1: Cédula Incorrecta CASO 2: Cédula Correcta NO existente en el Store CASO 3: Cambiar Parada Frecuente y Vivienda ANEXO M - PAPER 145

13 ÍNDICE DE FIGURAS Figura 1: Linked Open Data Cloud 6 Figura 2: Tabla de la BD Relacional 9 Figura 3: Extracto de Vocabulario - RDFs 21 Figura 4: Vocabulario - Esquema Preliminar 22 Figura 5: Vocabulario Esquema Final 23 Figura 6: Relaciones Binarios 24 Figura 7: Diagrama RDF Vocabulario: Generado con el plugin OntoGraf de Protégé 25 Figura 8: Instancias de Prueba 27 Figura 9: URIs for Vocabularies 33 Figura 10: Partes de una PURL 36 Figura 11: Funcionamiento de Server PURL 37 Figura 12: Content Negotiation - Archivo RDF 39 Figura 13: Content Negotiation - Archivo HTML 40 Figura 14: Interfaz del servicio VAPOUR 41 Figura 15: Resumen de Validación VAPOUR 42 Figura 16: Diagrama ER IRBU 44 Figura 17: Extracto del archivo OWL de salida 45 Figura 18: EndPoint generado por Virtuoso 46 Figura 19: Caracteres codificados 49 Figura 20: Usuarios Virtuoso Server 50 Figura 21: Roles Virtuoso Server 50 Figura 22: Error de Privilegios 51 Figura 23: Creación de Usuario 52 Figura 24: Servidor de Autentificación 53 Figura 25: Editor VoID - DERI 55 Figura 26: Servidor REST POIS 59 Figura 27: Estructura función Server REST 60 Figura 28: Correspondencia de Parámetros 61 Figura 29: Parámetro Opcional 61 Figura 30: Directorio Servidor Apache 62 Figura 31: Desplazamiento e inserción de Parada 64 Figura 32: Desplazamiento y eliminación de Parada 65 Figura 33: Doble codificación de una URL 66 Figura 34: Petición HTTP ExtJs 69 Figura 35: Documentación Generada con OWLDoc 80 Figura 36: Registro Server PURL OCLC 82 Figura 37: Registro de Dominio - PURL 83 Figura 38: Registro de PURL Individual 83 Figura 39: Instalación PURL - Wizard 85 Cúmar Ramiro Cueva Tacuri 1

14 Figura 40: Instalación PURL Especificación de BackEnd 86 Figura 41: Instalación PURL Permisos 86 Figura 42: PURL Interfaz Principal 87 Figura 43: PURL Creación de Dominio Público 87 Figura 44: PURL Creación de Dirección 88 Figura 45: Estructura de Directorios 91 Figura 46: URI y parámetros VAPOUR 94 Figura 47: Petición RDF/XML VAPOUR 95 Figura 48: Sin Content Negotiation - VAPOUR 95 Figura 49: Class - Petición RDF/XML VAPOUR 96 Figura 50: Class - Sin 'Content Negotiation' - VAPOUR 96 Figura 51: Property - RDF/XML VAPOUR 97 Figura 52: Property - Sin 'Content Negotiation' - VAPOUR 97 Figura 53: Interfaz Principal 100 Figura 54: Interfaz de Administración - CONDUCTOR 100 Figura 55: Carga de Archivo OWL 103 Figura 56: Grafo Creado 103 Figura 57: Verificación de Tripletas 104 Figura 58: Mensaje de Error al ingresar una cédula incorrecta, 140 Figura 59: Mensaje para ingresar un nuevo individuo. 140 Figura 60: Mensaje de bienvenida. 140 Figura 61: Aviso de Selección 141 Figura 62: Formulario sobre Vivienda 141 Figura 63: Información sobre Vivienda 142 Figura 64: Selección de Parada Frecuente 142 Figura 65: Información sobre Parada 143 Figura 66: Capas visibles 143 Figura 67: Peticiones REST 144 Cúmar Ramiro Cueva Tacuri 2

15 ÍNDICE DE TABLAS Tabla 1: Stores y Métodos de Actualización 8 Tabla 2: Resultados Benchmarking 10 Tabla 3: Atributos de un POI de categoría Clínica en dos entornos diferentes 13 Tabla 4: Preguntas Base para Generación de Vocabulario 18 Tabla 5: Elementos del Vocabulario 19 Tabla 6: Uri s de Vocabulario 35 Tabla 7: Prefijos de Individuos 44 Tabla 8: Formatos de Respuesta 47 Tabla 9: Lista de parámetros 47 Tabla 10: Métodos HTTP - CRUD 57 Tabla 11: Frameworks REST 57 Cúmar Ramiro Cueva Tacuri 3

16 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 Hyperlink 1, 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 HTTP 2, 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. 2 RFC2616 Cúmar Ramiro Cueva Tacuri 4

17 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 Life 3, Stuck 4 y Waze 5. 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 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 URIs 6 para nombrar las cosas. Usar URIs HTTP RFC3986 Cúmar Ramiro Cueva Tacuri 5

18 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 Figura 1: Linked Open Data Cloud 7 La aplicabilidad de Linked Data en la web transforma el paradigma de una web de 7 Cúmar Ramiro Cueva Tacuri 6

19 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

20 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 Hewlett- Packard 8 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 Método de Actualización 4store 9 SPARQLUpdate BigData 10 SPARQLUpdate BigOwlim 11 SPARQLUpdate(mediante Fuseki) TDB 12 SPARQLUpdate(mediante Jena 13 ) Virtuoso 14 SPARQLUpdate AllegroGraph 15 SPARQLUpdate Sesame 16 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 Cúmar Ramiro Cueva Tacuri 8

21 de conjuntos de datos de entre 100 y 200 millones de tripletas, el análisis y los resultados se pueden encontrar publicados en la red 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 Cúmar Ramiro Cueva Tacuri 9

22 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 Time taken (sec) SQL 240 RDF SQL 200 RDF SQL 170 RDF 300 Tabla 2: Resultados Benchmarking 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

23 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 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 personas 19. 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íficos 20. 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 Garmin 21 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 Cúmar Ramiro Cueva Tacuri 11

24 utilidad es Google con su iniciativa Maps 22, 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 MapMaker 23 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 GeoTourGuide 25 y Geovative 26, 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 Cúmar Ramiro Cueva Tacuri 12

25 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 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 DBPediaMobile 27 y el trabajo realizado en la universidad de Koblenz- Landau, 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 Cúmar Ramiro Cueva Tacuri 13

26 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 OpenStreetMap 29 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 Map 30 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 CRUZAR 31. 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 Vocabulary 32, el mismo que consiste de los elementos básicos para representar un POI como es Latitud, Longitud y Altitud. GeoOnionVocabulary 33, Se basa en el esquema del vocabulario anterior, pero Cúmar Ramiro Cueva Tacuri 14

27 orientado a la descripción de elementos en relación de distancia con otros. LGDVocabulary 34, 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. GoodRelations 35, 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 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 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 Cúmar Ramiro Cueva Tacuri 15

28 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

29 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.x 37, puesto que presta de gran aceptación en los ambientes de trabajo semántico por su flexibilidad y gran cantidad de funcionalidades 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 RECORRIDOS IT1 A una hora Y que Rutas existen. IT2 Cuáles son las paradas de la Calle X. IT3 Cuáles son las paradas de una Ruta X. IT4 Cuantas paradas realiza una Ruta X. IT5 Que rutas [bajan suben suben o bajan] de la Universidad IT6 Que rutas pasan por la Parada X [a una Hora Y]. IT11 [Cuales Cuantos] barrios no poseen paradas de los buses de la UTPL. ALTA ALTA ALTA ALTA ALTA ALTA MEDIA 37 Cúmar Ramiro Cueva Tacuri 17

30 ESTUDIANTE IT12 IT15 A una hora X que Ruta debo elegir para [ subir a bajar de ] la UTPL -- Considerando la Parada Frecuente de un Estudiante Cuál es la parada de la Ruta X que se localiza más cerca de mi casa IT7 Que estudiante posee la cedula X IT8 Cuál es la parada más frecuente de un estudiante X IT13 IT14 Cuál es el [ barrio sector ] con mayor número de estudiantes Cuantos estudiantes toman el bus de la UTPL en el [ sector barrio ] X MEDIA ALTA ALTA ALTA MEDIA MEDIA IT9 Cuáles son los POIs que se encuentran más cercanos del Punto Y. ALTA GENÉRICOS IT10 IT16 [Cuantos Cuales] POIs X contienen un nombre con X características Cuál es el [ barrio sector ] donde se ubican mayor cantidad de POIs Tabla 4: Preguntas Base para Generación de Vocabulario ALTA MEDIA Definición de Elementos Finales y sus Atributos Elemento Atributos Anotaciones Interrogantes Nombre Tipo Ruta Horario IT1 IT5 IT15 Fecha Dato de creación Parada Activa Calle Principal IT2 IT3 IT4 IT6 Cúmar Ramiro Cueva Tacuri 18

31 Calle Secundaria IT12 Imagen Dirección de la Img Estudiante Lat Lon Pertenece_A_Ruta Referencia Activa Cedula Parada_Frecuente IT7 IT8 IT13 Vivienda Dato geográfico Genérico Nombre Lat Lon Calle Principal Calle Secundaria Sector Barrio IT9 IT10 IT11 IT14 IT16 Fecha Dato de creación Tabla 5: Elementos del Vocabulario 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

32 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 Geo 38, 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 Core 39 o FOAF 40, no formarán parte de la Plataforma por no tener relación con la información manejada 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 CamelCase 41. 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 Descripción de Conceptos 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 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 Cúmar Ramiro Cueva Tacuri 20

33 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 POIG Un punto de Interés genérico capaz de representar otros elementos de forma directa 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 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

34 Esquema Preliminar Figura 4: Vocabulario - Esquema Preliminar Cúmar Ramiro Cueva Tacuri 22

35 Esquema Final Figura 5: Vocabulario Esquema Final Cúmar Ramiro Cueva Tacuri 23

36 Relaciones Binarias Figura 6: Relaciones Binarios Cúmar Ramiro Cueva Tacuri 24

37 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. Figura 7: Diagrama RDF Vocabulario: Generado con el plugin OntoGraf 42 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 W3C 43. Este diagrama puede ser encontrado en la dirección: [ ] 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 Cúmar Ramiro Cueva Tacuri 25

38 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 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: [ ] En apartados siguientes se mencionará la publicación del mismo, tanto en formato html como rdfs Cúmar Ramiro Cueva Tacuri 26

39 Figura 8: Instancias de Prueba Consultas SPARQL IT1:: A una hora Y que Rutas Existen PREFIX pois: < 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: < SELECT?Parada?CallePrincipal?CalleSecundaria WHERE {?Parada a pois:parada.?parada pois:localizadaen?poig. Cúmar Ramiro Cueva Tacuri 27

40 }?Poig pois:calle1?calleprincipal.?poig pois:calle2?callesecundaria. FILTER( regex(str(?calleprincipal), "Eduardo Kigman") regex(str(?callesecundaria), "Eduardo Kigman") ) IT3:: Cuales son las paradas de una Ruta X IT4:: Cuántas paradas realiza una ruta X PREFIX pois: < 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: < 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: < SELECT?Num_Parada?RutaXNombre?refParada WHERE {?ParadaX a pois:parada.?paradax pois:referencia?refparada.?rutax a pois:ruta; Cúmar Ramiro Cueva Tacuri 28

41 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: < SELECT?EstudianteX WHERE {?EstudianteX a pois:estudiante.?estudiantex pois:cedula?cedestudiante. FILTER(regex(str(?cedEstudiante), " ")) } IT8:: Cuál es la parada más frecuente de una estudiante X. PREFIX pois: < 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), " ")) } 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: < PREFIX < SELECT * geo: Cúmar Ramiro Cueva Tacuri 29

42 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: < 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: < PREFIX geo: < 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

43 PREFIX pois: < 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: < 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: < 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

44 implementación de un algoritmo que determine la proximidad de los resultados. Por ahora no se lo considera. PREFIX pois: < PREFIX < 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: < SELECT?POIS WHERE {?POIS a pois:poig.?pois pois:sector?sectorpois. FILTER(?sectorPOIS = "Pio Jaramillo Alvarado") } 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

45 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 URI s 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: 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 (#) Cúmar Ramiro Cueva Tacuri 33

46 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} 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 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 46 Cúmar Ramiro Cueva Tacuri 34

47 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 PURL 48 gestionado por OCLC Dereferencing HTTP URIs html (draft) 48 Cúmar Ramiro Cueva Tacuri 35

48 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 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 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 redirecciones 51 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) Extraído de: 51 RFC2616 Cúmar Ramiro Cueva Tacuri 36

49 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 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: Servidor Web (apache): Para que se pueda utilizar la uri del servidor PURL Como una uri desreferenciada que enlaza al vocabulario publicado en la dirección: Es necesario realizar el proceso de configuración detallado en el ANEXO B. Cúmar Ramiro Cueva Tacuri 37

50 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 Apache HTTP Server Apache HTTP Server 52 es un proyecto mantenido por la comunidad de desarrolladores de Apache Software Fundation 53, el cual en la actualidad se ha convertido en uno de los Servidores HTTP más robustos y confiables 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 Contenido 54, 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 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 Cúmar Ramiro Cueva Tacuri 38

51 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 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 curl 56, 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 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 Cúmar Ramiro Cueva Tacuri 39

52 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 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 VAPOUR 57 desarrollado por miembros de la Fundación CTIC 58. 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 Cúmar Ramiro Cueva Tacuri 40

53 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

54 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

55 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 OpenLink Virtuoso El almacén de datos (triplestore) será construido mediante la utilización de Virtuoso en su versión OpenSource 6 59, 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 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 Cúmar Ramiro Cueva Tacuri 43

56 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 POINT POIG PARADA ORDEN_PARADA RUTA Prefijo crd pg prd orden 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

57 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 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 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: 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

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

59 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 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: 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 Descripción Requerido? query 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 Request Parameters Cúmar Ramiro Cueva Tacuri 47

60 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 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 * where {?Parada a pois:parada } LIMIT 3 ; $baseurl = ; $format="application/json" $params=array( "default-graph" => " "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

61 { "head": { "link": [], "vars": ["Parada"] }, "results": { "distinct": false, "ordered": true, "bindings": [ { "Parada": { "type": "uri", "value": " }}, { "Parada": { "type": "uri", "value": " }}, { "Parada": { "type": "uri", "value": " }} ] } } 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 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 Cúmar Ramiro Cueva Tacuri 49

62 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: Al usuario SPARQL, el mismo que posee tan solo permisos de consulta de datos Cúmar Ramiro Cueva Tacuri 50

63 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

64 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: La autenticación utilizada por este tipo de usuario es una Autenticación Digest 64, 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 como 65 : 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: 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 [ Authentication] Cúmar Ramiro Cueva Tacuri 52

65 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 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 CURL 66. <?php $user = "test2"; $pass = "test2"; $query = "PREFIX pois:< INSERT INTO GRAPH < { pois:estd01 rdf:type pois:estudiante; pois:cedula ; pois:viveen pois:pg64 }"; $format = "application/sparql-results+json"; $endpointsecure = " $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 Cúmar Ramiro Cueva Tacuri 53

66 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 < 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 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és 68 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 Commons Describing Linked Datasets with the VoID Vocabulary Cúmar Ramiro Cueva Tacuri 54

67 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 online 70, capaz de permitir incluir de forma gráfica y detallada todos los aspectos relativos al DataSet. Esta herramienta bajo el nombre de ve 2 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 Sindice 71, void Store 72, void Browser 73 y PTSW 74, 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 rdf: rdfs: foaf: dcterms: < Cúmar Ramiro Cueva Tacuri 55

68 @prefix void: : <#>. ## POIS DATASET < rdf:type void:dataset ; foaf:homepage < ; 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 < ; dcterms:license < ; void:sparqlendpoint < ; void:vocabulary < ; void:vocabulary < 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, Twitter 76 así como el servicio de búsqueda de Google 77. 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 URIs 78. 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 RFC3986 Cúmar Ramiro Cueva Tacuri 56

69 Operación SQL HTTP Create Insert POST Read Select GET Update Update PUT Delete Delete 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 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 / Tecnología Framework Server ASP.net REST Starter Kit 79 Internet Information Server Java Axis2 80 Jersey 81 Restlet 82 Servidor de Aplicaciones Java PHP Recess 83 Zend Framework 84 Apache Ruby restful-rails 85 Apache (soporte Ruby) Tabla 11: Frameworks REST Cúmar Ramiro Cueva Tacuri 57

70 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 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: 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

71 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

72 Aquí es donde se implementarán todas las operaciones sobre el EndPoint. 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 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

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

74 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: 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

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

76 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 Figura 31: Desplazamiento e inserción de Parada 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

77 desplazamiento de acuerdo a la parada a eliminar Figura 32: Desplazamiento y eliminación de Parada 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 pois:< PREFIX :< MODIFY GRAPH < DELETE { :rt001 pois:tipo?y } INSERT { :rt001 pois:tipo "newvalue" } WHERE { :rt001 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

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

79 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 RESTClient 86 para Firefox. El proceso y resultado se puede encontrar en el ANEXO I Cúmar Ramiro Cueva Tacuri 67

80 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 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 Maps 87, Google Maps 88 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 OpenStreetMap 89 (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 Commons 90. 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 Cúmar Ramiro Cueva Tacuri 68

81 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 ExtJs 92 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 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 Cúmar Ramiro Cueva Tacuri 69

82 4.3. Funcionalidades 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 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 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 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 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

83 de forma gráfica. Anexo La interfaz de la aplicación cliente puede ser encontrada en el Anexo: 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 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: A8 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 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: Cúmar Ramiro Cueva Tacuri 71

84 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 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: 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 Cúmar Ramiro Cueva Tacuri 72

85 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

86 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

87 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

88 8. BIBLIOGRAFÍA [1] Miniwatts Marketing Group: Latin American Internet Usage Statistics. (2011) [2] LinkedData.org: Linked Data. Connect Distributed Data across the Web. (2010) [3] Wikipedia. Point of interest. (2011). Recuperado 22/02/2011. Disponible [4] W3C.org: Resource Description Framework (RDF). (2004) [5] W3C.org: RDF Vocabulary Description Language 1.0: RDF Schema. (2004) [6] Berners-Lee, T.: Linked Data. (2006) [7] WEC.org.: SPARQL Query Language for RDF. (2008). [8] Wikipedia. SPARUL. (2010). [9]OpenLink. SPARUL -- an Update Language ForRDF Graphs. (2009) [10] ARC. Easy RDF and SPARQL for LAMP systems. (2010) [11] W3C.org: Working Draft :SPARQL 1.1 Update. (14 Octubre 2010). [12]OpenLink. Dbpedia Live Extraction. (2011) [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) [16] INKDROID. The 5 Stars of Open Linked Data. (2010) [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

89 [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). [19] Davis, I.: An Introduction to RDF. (2005) [20] Lamarca, M.: RDF. (2009) [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. [22] W3C.org.: Guía Breve de Linked Data. (2010) [23] Wisman, M.: Bringing Linked Data to the Geo World. (2009) [24]W3C.org. Data Model. (2010). [25]W3C.org. Cool URIs for the Semantic Web. (2008). [26] data.gov.uk - Opening up government. Creating URIs. [27] Drummond, Nick. OWLDoc - Plugin for Protégé. The University of Manchester. [28] 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). [30] Wright, Jacob: Simple REST server in PHP Supports JSON & AMF. [31] SourceForge: Quality Criteria for Linked Data sources. a_sources. (2010) Cúmar Ramiro Cueva Tacuri 77

90 9. ANEXOS Cúmar Ramiro Cueva Tacuri 78

91 9.1. ANEXO A Cúmar Ramiro Cueva Tacuri 79

92 INSTALACIÓN DE PLUGIN - OWLDoc El archivo instalador puede ser descargado desde la dirección: 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

93 9.2. ANEXO B Cúmar Ramiro Cueva Tacuri 81

94 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: 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

95 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

96 9.3. ANEXO C Cúmar Ramiro Cueva Tacuri 84

97 INSTALACIÓN DE SERVIDOR PURL El archivo instalador puede ser descargado desde la dirección: Para el ejemplo se creará la siguiente Persistent URL: 1. Ejecutar instalador: $ java -jar PURLZ-Server 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: en lugar de Figura 39: Instalación PURL - Wizard Cúmar Ramiro Cueva Tacuri 85

98 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 Pudiendo ser gestionadas por un administrador o no. Figura 41: Instalación PURL Permisos Cúmar Ramiro Cueva Tacuri 86

99 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

100 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. Cúmar Ramiro Cueva Tacuri 88

101 9.4. ANEXO D Cúmar Ramiro Cueva Tacuri 89

102 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 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: Directorio Web: /etc/apache2/ /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.htaccess 93. En este caso se utilizará un fichero.htaccess y la siguiente estructura de directorios Cúmar Ramiro Cueva Tacuri 90

103 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

104 # 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 en función del contenido solicitado. Cúmar Ramiro Cueva Tacuri 92

105 9.5. ANEXO E Cúmar Ramiro Cueva Tacuri 93

106 VAPOUR: VALIDACIÓN DE VOCABULARIO Figura 46: URI y parámetros VAPOUR Cúmar Ramiro Cueva Tacuri 94

107 Figura 47: Petición RDF/XML VAPOUR Figura 48: Sin Content Negotiation - VAPOUR Cúmar Ramiro Cueva Tacuri 95

108 Figura 49: Class - Petición RDF/XML VAPOUR Figura 50: Class - Sin 'Content Negotiation' - VAPOUR Cúmar Ramiro Cueva Tacuri 96

109 Figura 51: Property - RDF/XML VAPOUR Figura 52: Property - Sin 'Content Negotiation' - VAPOUR Cúmar Ramiro Cueva Tacuri 97

110 9.6. ANEXO F Cúmar Ramiro Cueva Tacuri 98

111 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 Software 94 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 fuente 95. 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 dav passwd: dba passwd: dav Estos podrán ser utilizados en la interfaz de administración, la cual puede ubicada en la siguiente dirección: Virtuoso from Source Cúmar Ramiro Cueva Tacuri 99

112 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: 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

113 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

114 9.7. ANEXO G Cúmar Ramiro Cueva Tacuri 102

115 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á: 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

116 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

117 9.8. ANEXO H Cúmar Ramiro Cueva Tacuri 105

118 URIs POIS REST SERVER HTTP METHOD POST URI /point/$user/$pass/$lat/$lon /poig/$user/$pass/$nombre/$point/$calle1/$calle2/$barrio/$sector /poig/$user/$pass/$point/$calle1/$calle2/$barrio/$sector /poig/$user/$pass/$point/$calle1/$calle2/$barrio /parada/$user/$pass/$referencia/$img/$poig /parada/$user/$pass/$img/$poig /parada/$user/$pass/$poig /ordenparada/$user/$pass/$numsec/$parada /ruta/$user/$pass/$nombre/$horario/$tipo /ordenparada/ruta/$user/$pass/$ruta/$ordparada /paradafrecuente/$user/$pass/$parada /estudiante/$user/$pass/$cedula/$poig/$prdfrc Descripción Crea un individuo del tipo POINT Crea un individuo del tipo POIG Crear un individuo PARADA Crear individuo ORDEN_PARADA Crear individuo RUTA Relación entre un elemento RUTA con un ORDEN_PARADA Crear individuo PARADA FRECUENTE PUT /estudiante/$user/$pass/$cedula/$poig /estudiante/$user/$pass/$cedula /estudiante2/$user/$pass/$cedula/$prdfrc /estd_parada/$user/$pass/$estudiante/$prdfrc /estudiante/vivienda/$user/$pass/$estudiante/$poig /parada/$user/$pass/$parada/$poig /ruta/horario/$user/$pass/$ruta/$horario Crear individuo ESTUDIANTE Relación ESTUDIANTE con PARADA_FRECUENTE Relación con ESTUDIANTE con su vivienda Reubicar parada Agregar un horario a una RUTA Cúmar Ramiro Cueva Tacuri 106

119 DELETE GET /propiedad/$user/$pass/$individuo/$propiedad/$valor/$tipo /propiedad/$user/$pass/$individuo/$propiedad/$valor /ruta/parada/$user/$pass/$ruta/$ordprd/$numsec /ruta/horario/$user/$pass/$ruta/$horario /ruta/$user/$pass/$ruta /ruta/parada/$user/$pass/$ruta/$parada /individuo/$tipo/$propiedad/$valor/$tipovalor/$operador /individuo/$tipo/$propiedad/$valor/$operador /individuo/propiedad/$individuo /individuos/fecha/$tipoindv/$fechaini/$fechafin /estudiante/parada/$estudiante /estudiante/vivienda/$estudiante /ruta/parada/$ruta /parada/ /parada/ruta/$prd Actualizar propiedad de un individuo Agrega una nueva PARADA a una RUTA mediante el elemento RUTA_PARADA Borrar un Horario de una RUTA Elimina una RUTA y sus paradas únicas Elimina una PARADA de una RUTA Extrae el identificador de un individuo Extrae el valor de la propiedad de un individuo Extrae el identificador de un individuo basado en fechas Extrae la parada frecuente de un estudiante Extrae la vivienda actual de un estudiante Devuelve todas las paradas relacionadas con una RUTA Devuelve todas las paradas activas existentes en el Store Extrae todas las RUTAs y sus respectivos horarios que posean la PARADA indicada. Cúmar Ramiro Cueva Tacuri 107

120 9.9. ANEXO I Cúmar Ramiro Cueva Tacuri 108

121 PRUEBAS SERVICIO REST - POIS URI: /point/$user/$pass/$lat/$lon DESCRIPCIÓN: Crear un individuo del Tipo POINT HTTP: POST RESPUESTA: STORE: { "status": "OK", "indiv": "crd " } URI: /poig/$user/$pass/$nombre/$point/$calle1/$calle2/$barrio/$sector DESCRIPCIÓN: Crea un individuo del Tipo POIG HTTP: POST de Mayo/10 de Agosto/Buena Esperanza/Centro RESPUESTA: STORE: { "status": "OK", "indiv": "pg " } Cúmar Ramiro Cueva Tacuri 109

122 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 Calderon/María Auxiliadora/San José RESPUESTA: STORE: { "status": "OK", "indiv": "pg " } 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

123 HTTP: POST 9 de Octubre/Bolivar/Motupe RESPUESTA: { "status": "OK", "indiv": "pg " } STORE: URI: /parada/$user/$pass/$referencia/$img/$poig DESCRIPCIÓN: Crea un individuo del tipo PARADA HTTP: POST a carpintería Pinocho/paradaImg.png/pg RESPUESTA: STORE: { "status": "OK", "indiv": "prd " } Cúmar Ramiro Cueva Tacuri 111

124 URI: /parada/$user/$pass/$img/$poig DESCRIPCIÓN: Crea un individuo del tipo PARADA, sin especificar una referencia HTTP: POST RESPUESTA: STORE: { "status": "OK", "indiv": "prd " } URI: /parada/$user/$pass/$poig DESCRIPCIÓN: Crea un individuo del tipo PARADA, sin especificar una referencia ni una imagen. HTTP: POST RESPUESTA: STORE: { "status": "OK", "indiv": "prd " } Cúmar Ramiro Cueva Tacuri 112

125 URI: /ordenparada/$user/$pass/$numsec/$parada DESCRIPCIÓN: Crea un individuo del tipo ORDEN_PARADA HTTP: POST RESPUESTA: STORE: { "status": "OK", "indiv": "ord " } URI: /ruta/$user/$pass/$nombre/$horario/$tipo DESCRIPCIÓN: Crea un individuo del tipo RUTA HTTP: POST - Bolonia/15:12:00/RECOGE RESPUESTA: STORE: { "status": "OK", "indiv": "ruta " } Cúmar Ramiro Cueva Tacuri 113

126 URI: /ordenparada/ruta/$user/$pass/$ruta/$ordparada DESCRIPCIÓN: Establece la relación de un elemento ORDEN_PARADA con una RUTA HTTP: POST RESPUESTA: STORE: { "status": "OK" } URI: /paradafrecuente/$user/$pass/$parada DESCRIPCIÓN: Crea un individuo del tipo, PARADA_FRECUENTE HTTP: POST RESPUESTA: { "status": "OK", "indiv": "prdfrc " Cúmar Ramiro Cueva Tacuri 114

127 STORE: } URI: /estudiante/$user/$pass/$cedula/$poig/$prdfrc DESCRIPCIÓN: Crea un individuo del tipo ESTUDIANTE HTTP: POST dfrc RESPUESTA: { "status": "OK", "indiv": "estd " } STORE: URI: /estudiante/$user/$pass/$cedula/$poig DESCRIPCIÓN: Crea un individuo del tipo ESTUDIANTE, sin especificar su PARADA_FRECUENTE HTTP: POST Cúmar Ramiro Cueva Tacuri 115

128 RESPUESTA: STORE: { "status": "OK", "indiv": "estd " } URI: /estudiante/$user/$pass/$cedula DESCRIPCIÓN: Crea un individuo ESTUDIANTE con solamente su cédula HTTP: POST RESPUESTA: { "status": "OK", "indiv": "estd " } STORE: URI: /estudiante2/$user/$pass/$cedula/$prdfrc DESCRIPCIÓN: Crea un individuo ESTUDIANTE con su cédula y su parada frecuente HTTP: POST Cúmar Ramiro Cueva Tacuri 116

129 1 RESPUESTA: STORE: { "status": "OK", "indiv": "estd " } URI: /estd_parada/$user/$pass/$estudiante/$prdfrc DESCRIPCIÓN: Relaciona un ESTUDIANTE con su PARADA_FRECUENTE HTTP: POST RESPUESTA: STORE: { "status": "OK" } URI: /estudiante/vivienda/$user/$pass/$estudiante/$poig DESCRIPCIÓN: Relacionar un estudiante con su vivienda HTTP: POST Cúmar Ramiro Cueva Tacuri 117

130 RESPUESTA: STORE: { "status": "OK" } URI: /parada/$user/$pass/$parada/$poig DESCRIPCIÓN: Reubicar una parada existente HTTP: PUT RESPUESTA: STORE: { "status": "OK" } Cúmar Ramiro Cueva Tacuri 118

131 URI: /ruta/horario/$user/$pass/$ruta/$horario DESCRIPCIÓN: Agregar un nuevo horario a una ruta HTTP: PUT RESPUESTA: STORE: { "status": "OK" } URI: /propiedad/$user/$pass/$individuo/$propiedad/$valor/$tipo DESCRIPCIÓN: Actualiza la Propiedad de un Individuo HTTP: PUT /string RESPUESTA: STORE: { "status": "OK" } Cúmar Ramiro Cueva Tacuri 119

132 URI: /propiedad/$user/$pass/$individuo/$propiedad/$valor DESCRIPCIÓN: Actualiza la Propiedad de un Individuo valor de objetos HTTP: PUT RESPUESTA: STORE: { "status": "OK" } URI: /ruta/parada/$user/$pass/$ruta/$ordprd/$numsec DESCRIPCIÓN: Agrega una nueva PARADA a una RUTA mediante el elemento RUTA_PARADA HTTP: PUT RESPUESTA: { "status": "OK", Cúmar Ramiro Cueva Tacuri 120

133 STORE: "message": "Nueva parada vinculada exitosamente" } Antes: Después: URI: /ruta/horario/$user/$pass/$ruta/$horario DESCRIPCIÓN: Borrar horario de una Ruta HTTP: DELETE Cúmar Ramiro Cueva Tacuri 121

134 RESPUESTA: STORE: { "status": "OK" } Antes: Después: URI: /ruta/$user/$pass/$ruta DESCRIPCIÓN: Elimina una RUTA y sus paradas únicas HTTP: DELETE RESPUESTA: STORE: { "status": "OK", "message": "Ruta (ruta ) desactivada" } Cúmar Ramiro Cueva Tacuri 122

135 Antes: Después: URI: /ruta/parada/$user/$pass/$ruta/$parada DESCRIPCIÓN: Elimina una PARADA de una RUTA HTTP: DELETE RESPUESTA: STORE: { "status": "OK", "message": "Parada eliminada" } Antes: Cúmar Ramiro Cueva Tacuri 123

136 Después: URI: /individuo/$tipo/$propiedad/$valor/$tipovalor/$operador DESCRIPCIÓN: Extrae el identificador de un individuo HTTP: GET RESPUESTA: { "head": { "link": [ ], "vars": [ "obj" ] }, "results": { "distinct": false, "ordered": true, "bindings": [ { "obj": { "type": "uri", "value": "http: //localhost: 8080/pois/vcblr/indv/#estd " } } ] } } URI: /individuo/$tipo/$propiedad/$valor/$operador DESCRIPCIÓN: Extrae el identificador de un individuo (basado en otro individuo) Cúmar Ramiro Cueva Tacuri 124

137 HTTP: GET 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 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: // "value": "Av. 8 de Diciembre" } Cúmar Ramiro Cueva Tacuri 125

138 ... } URI: /individuos/fecha/$tipoindv/$fechaini/$fechafin DESCRIPCIÓN: Extrae todos los individuos que posean el atributo fecha entre los dos valores especificados. HTTP: GET RESPUESTA: { } "type": "uri", "value": "http: //localhost: 8080/pois/vcblr/indv/#pg4" }, "prop": { "type": "typed-literal", "datatype": "http: // "value": " " } }, { "obj": { "type": "uri", "value": "http: //localhost: 8080/pois/vcblr/indv/#pg6" URI: /estudiante/parada/$estudiante Cúmar Ramiro Cueva Tacuri 126

139 DESCRIPCIÓN: Obtiene la parada frecuente de un estudiante HTTP: GET RESPUESTA: { "head": {"link": [ ], "vars": [ "parada", "fechaselec" ] }, "results": { "distinct": false, "ordered": true, "bindings": [ { "parada": { "type": "uri", "value": "http: //localhost: 8080/pois/vcblr/indv/#prd " }, "fechaselec": { "type": "typed-literal", "datatype": "http: // "value": " " } } ] } } URI: /estudiante/vivienda/$estudiante DESCRIPCIÓN: Obtiene la vivienda actual de un determinado estudiante. HTTP: GET RESPUESTA: {... "type": "uri", "value": "http: //localhost: 8080/pois/vcblr/indv/#pg " }, "fechacreac": { "type": "typed-literal", "datatype": "http: // "value": " " }, Cúmar Ramiro Cueva Tacuri 127

140 ... } "lat": { "type": "typed-literal", "datatype": "http: // URI: /ruta/parada/$ruta DESCRIPCIÓN: Devuelve todas las paradas relacionadas con una ruta determinada. HTTP: GET RESPUESTA: {.... "lon": { "type": "typed-literal", "datatype": "http: // "value": " " } }, { "orden": { "type": "typed-literal", "datatype": "http: // "value": "2" }, "parada": { "type": "uri", "value": "http: //localhost: 8080/pois/vcblr/indv/#prd66" }, "lat": { "type": "typed-literal", "datatype": "http: // Cúmar Ramiro Cueva Tacuri 128

141 .. } URI: /parada/ DESCRIPCIÓN: Extrae todas las paradas existentes en el Store. HTTP: GET RESPUESTA: {... }... "type": "uri", "value": "http: //localhost: 8080/pois/vcblr/indv/#prd " }, "lat": { "type": "typed-literal", "datatype": "http: // "value": "5" }, "lon": { "type": "typed-literal", "datatype": "http: // "value": "7" URI: / parada/ruta/$prd/ DESCRIPCIÓN: Devuelve todas las RUTAS de una determinada PARADA así como sus horarios. HTTP: GET RESPUESTA: Cúmar Ramiro Cueva Tacuri 129

142 {... "nomb": { "type": "typed-literal", "datatype": " "value": "Av. Orillas del Zamora, Calle Guayaquil, Av. Salvador Bustamante, SOLCA, La Paz, Colegio Militar, Cdla. La Banda." }, "hr": { "type": "typed-literal", "datatype": " "value": "12:35:00-05:00" }, "tp": { "type": "typed-literal", "datatype": " "value": "BAJA"... } Cúmar Ramiro Cueva Tacuri 130

143 9.10. ANEXO J Cúmar Ramiro Cueva Tacuri 131

144 CASOS DE USO Existencia de Estudiante Existencia de Estudiante App Cliente Rest API Store Virtuoso Ingreso Cédula Comprobar existencia en el Store Devolver Tripletas Sin Acceso Permitir Acceso Agregarlo al Store 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

145 Visualizar Parada Frecuente Visualizar Parada Frecuente Procesa y Dibuja Parada Frecuente Rest API Consultar Parada Frecuente (posicion - informacion) Store Virtuoso Devolver Tripletas App Cliente Registro de Vivienda App Cliente Activa Modo Selección de Vivienda Registro de Vivienda Registra nuevo sitio Rest API Store Virtuoso usuario Transmite Datos Guardar Tripletas Ingresa Información Visualización de Vivienda Cúmar Ramiro Cueva Tacuri 133

146 Registro de Parada Frecuente App Cliente Registro de Parada Frecuente Rest API Store Virtuoso Activa Modo Selección de Parada Frecuente Solicita los datos de todas las paradas Devuelve Tripletas Grafica todas las paradas usuario Selecciona Parada Transmite Datos Guardar Tripletas Visualización de Parada Frecuente Cúmar Ramiro Cueva Tacuri 134

147 9.11. ANEXO K Cúmar Ramiro Cueva Tacuri 135

148 INTERFAZ DE CLIENTE INGRESO PRINCIPAL Cúmar Ramiro Cueva Tacuri 136

149 VIVIENDA PARADA FRECUENTE Cúmar Ramiro Cueva Tacuri 137

150 PARADAS EXISTENTES Cúmar Ramiro Cueva Tacuri 138

151 9.12. ANEXO L Cúmar Ramiro Cueva Tacuri 139

152 5.8.1 CASO 1: Cédula Incorrecta Figura 58: Mensaje de Error al ingresar una cédula incorrecta, incompleta o alfanumérica 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

153 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

154 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

155 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

App para realizar consultas al Sistema de Información Estadística de Castilla y León

App para realizar consultas al Sistema de Información Estadística de Castilla y León App para realizar consultas al Sistema de Información Estadística de Castilla y León Jesús M. Rodríguez Rodríguez rodrodje@jcyl.es Dirección General de Presupuestos y Estadística Consejería de Hacienda

Más detalles

Resumen de la Tesina. Autor: Adrià Batet López. Tutor: Víctor Pascual Ayats

Resumen de la Tesina. Autor: Adrià Batet López. Tutor: Víctor Pascual Ayats Inventario y geolocalización de las actividades comerciales en las plantas bajas de los edificios de L Hospitalet de Llobregat. Aplicación web de recursos para el ciudadano. Resumen de la Tesina. Autor:

Más detalles

Escudo Movistar Guía Rápida de Instalación Dispositivos Symbian

Escudo Movistar Guía Rápida de Instalación Dispositivos Symbian Escudo Movistar Guía Rápida de Instalación Dispositivos Symbian Guía de Instalación Página 1 Índice ESCUDO MOVISTAR.... 3 1. INSTALACIÓN DEL SERVICIO ESCUDO MOVISTAR... 3 1.1. VERSIONES SOPORTADAS... 3

Más detalles

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Documento de trabajo elaborado para la Red Temática DocenWeb: Red Temática de Docencia en Control mediante Web (DPI2002-11505-E)

Más detalles

Principios de Privacidad y Confidencialidad de la Información

Principios de Privacidad y Confidencialidad de la Información Principios de Privacidad y Confidencialidad de la Información Con el objetivo de mantener nuestro permanente liderazgo en la protección de la privacidad del cliente, Manufacturera 3M S.A de C.V está activamente

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

RESUMEN INFORMATIVO PROGRAMACIÓN DIDÁCTICA CURSO 2013/2014

RESUMEN INFORMATIVO PROGRAMACIÓN DIDÁCTICA CURSO 2013/2014 RESUMEN INFORMATIVO PROGRAMACIÓN DIDÁCTICA CURSO 2013/2014 FAMILIA PROFESIONAL: INFORMATICA Y COMUNICACIONES MATERIA: 28. DESARROLLO WEB EN ENTORNO SERVIDOR CURSO: 2º DE CFGS DESARROLLO DE APLICACIONES

Más detalles

Manual PARA EL ADMINISTRADOR DE LA WEB DE PRÁCTICAS PRE PROFESIONALES Y PASANTÍAS

Manual PARA EL ADMINISTRADOR DE LA WEB DE PRÁCTICAS PRE PROFESIONALES Y PASANTÍAS Manual PARA EL ADMINISTRADOR DE LA WEB DE PRÁCTICAS PRE PROFESIONALES Y PASANTÍAS UNIVERSIDAD TÉCNICA DE MANABÍ Dirección General de Vinculación con la Sociedad FLUJOGRAMA DE PROCESOS USADOS EN LA WEB

Más detalles

"Diseño, construcción e implementación de modelos matemáticos para el control automatizado de inventarios

Diseño, construcción e implementación de modelos matemáticos para el control automatizado de inventarios "Diseño, construcción e implementación de modelos matemáticos para el control automatizado de inventarios Miguel Alfonso Flores Sánchez 1, Fernando Sandoya Sanchez 2 Resumen En el presente artículo se

Más detalles

Manual de uso de la plataforma para monitores. CENTRO DE APOYO TECNOLÓGICO A EMPRENDEDORES -bilib

Manual de uso de la plataforma para monitores. CENTRO DE APOYO TECNOLÓGICO A EMPRENDEDORES -bilib Manual de uso de la plataforma para monitores CENTRO DE APOYO TECNOLÓGICO A EMPRENDEDORES -bilib [Manual de uso de la plataforma para monitores] 1. Licencia Autor del documento: Centro de Apoyo Tecnológico

Más detalles

Funcionalidades Software SAT GotelGest.Net (Software de Servicio de Asistencia Técnica)

Funcionalidades Software SAT GotelGest.Net (Software de Servicio de Asistencia Técnica) Funcionalidades Software SAT GotelGest.Net (Software de Servicio de Asistencia Técnica) Servinet Sistemas y Comunicación S.L. www.softwaregestionsat.com Última Revisión: Octubre 2014 FUNCIONALIDADES SAT

Más detalles

MANUAL DE USUARIO APLICACIÓN SYSACTIVOS

MANUAL DE USUARIO APLICACIÓN SYSACTIVOS MANUAL DE USUARIO APLICACIÓN SYSACTIVOS Autor Edwar Orlando Amaya Diaz Analista de Desarrollo y Soporte Produce Sistemas y Soluciones Integradas S.A.S Versión 1.0 Fecha de Publicación 19 Diciembre 2014

Más detalles

Oficina Virtual Manual del usuario

Oficina Virtual Manual del usuario Oficina Virtual Manual del usuario AJUNTAMENT D ALGEMESÍ 1/24 Índice 1. Introducción.. 3 2. Oficina Virtual.. 3 2.1. Organización... 3 2.2. Idioma 5 2.3. Información del portal 5 3. Perfiles de usuario

Más detalles

Introducción a la Firma Electrónica en MIDAS

Introducción a la Firma Electrónica en MIDAS Introducción a la Firma Electrónica en MIDAS Firma Digital Introducción. El Módulo para la Integración de Documentos y Acceso a los Sistemas(MIDAS) emplea la firma digital como método de aseguramiento

Más detalles

Studium, Campus Virtual de la Universidad de Salamanca.

Studium, Campus Virtual de la Universidad de Salamanca. Studium, Campus Virtual de la Universidad de Salamanca. Contenidos 1 Qué es Studium 2 Instalación de Studium en USAL 3 Atención a los usuarios 4 Instalación Moodle. MoodleWindowsInstaller 5 Moodle portable

Más detalles

Novedades en Q-flow 3.02

Novedades en Q-flow 3.02 Novedades en Q-flow 3.02 Introducción Uno de los objetivos principales de Q-flow 3.02 es adecuarse a las necesidades de grandes organizaciones. Por eso Q-flow 3.02 tiene una versión Enterprise que incluye

Más detalles

Contenido. Email: capacitacion@u cursos.cl / Teléfono: 9782450

Contenido. Email: capacitacion@u cursos.cl / Teléfono: 9782450 GMI Contenido PUBLICAR AVISO... 3 CREAR PROCESO DE SELECCIÓN... 6 VER/ELIMINAR AVISOS PUBLICADOS... 8 ETAPAS DE UN PROCESO DE SELECCIÓN... 10 SECCIONES DE LOS PROCESOS DE SELECCIÓN (GPS)... 21 PERSONALIZAR

Más detalles

Tema II Comercio Electrónico 2.1 Concepto de e-commercee

Tema II Comercio Electrónico 2.1 Concepto de e-commercee UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO FACULTAD DE CONTADURIA Y ADMINISTRACIÓN Construcción de sitios web comerciales Tema II Comercio Electrónico 2.1 Concepto de e-commercee Presenta: ING. y M.A.. RENÉ

Más detalles

Sistema de SaaS (Software as a Service) para centros educativos

Sistema de SaaS (Software as a Service) para centros educativos Sistema de SaaS (Software as a Service) para centros educativos Definiciones preliminares: Qué es SaaS? SaaS (1) es un modelo de distribución del software que permite a los usuarios el acceso al mismo

Más detalles

Maxpho Commerce 11. Gestión CSV. Fecha: 20 Septiembre 2011 Versión : 1.1 Autor: Maxpho Ltd

Maxpho Commerce 11. Gestión CSV. Fecha: 20 Septiembre 2011 Versión : 1.1 Autor: Maxpho Ltd Maxpho Commerce 11 Gestión CSV Fecha: 20 Septiembre 2011 Versión : 1.1 Autor: Maxpho Ltd Índice general 1 - Introducción... 3 1.1 - El archivo CSV... 3 1.2 - Módulo CSV en Maxpho... 3 1.3 - Módulo CSV

Más detalles

Prezi: editor de presentaciones

Prezi: editor de presentaciones Prezi: editor de presentaciones Descripción Francisco Mora En momentos en que la Web 2.0 es un entorno de interacción, aparecen múltiples servicios que permiten compartir y editar recursos de forma conjunta.

Más detalles

Manual de Usuario Sitio Dinámico e-ducativa Versión 7.01.00

Manual de Usuario Sitio Dinámico e-ducativa Versión 7.01.00 Manual de Usuario Sitio Dinámico e-ducativa Versión 7.01.00 ÍNDICE DE CONTENIDOS INTRODUCCIÓN...3 ÁREAS DEL SITIO WEB...4 1. ENCABEZADO...5 2. SECCIONES Y PÁGINAS DEFINIDAS...5 3. CONTENIDO...5 4. NOVEDADES

Más detalles

http://www.manavell.com info@manavell.com

http://www.manavell.com info@manavell.com http://www.manavell.com info@manavell.com Antes que nada le agradecemos su interés en nuestros servicios. Nuestro interés es poder ayudar a su organización a tener una presencia online segura, profesional

Más detalles

Sistema Inteligente de Exploración

Sistema Inteligente de Exploración Observatorio Municipal de Estadística Sistema Inteligente de Exploración Capítulos 1. Consideraciones iniciales y requerimientos... 2 2. Navegación... 3 3. Consulta de indicadores... 5 3.1. Elaboración

Más detalles

GUIA COMPLEMENTARIA PARA EL USUARIO DE AUTOAUDIT. Versión N 02 Fecha: 2011-Febrero Apartado: Archivos Anexos ARCHIVOS ANEXOS

GUIA COMPLEMENTARIA PARA EL USUARIO DE AUTOAUDIT. Versión N 02 Fecha: 2011-Febrero Apartado: Archivos Anexos ARCHIVOS ANEXOS ARCHIVOS ANEXOS Son los documentos, hojas de cálculo o cualquier archivo que se anexa a las carpetas, subcarpetas, hallazgos u otros formularios de papeles de trabajo. Estos archivos constituyen la evidencia

Más detalles

Bechtle Solutions Servicios Profesionales

Bechtle Solutions Servicios Profesionales Soluciones Tecnología Bechtle Solutions Servicios Profesionales Fin del servicio de soporte técnico de Windows Server 2003 No hacer nada puede ser un riesgo BECHTLE Su especialista en informática Ahora

Más detalles

Multipedidos es un sistema de ventas on-line que permite gestionar pedidos por internet en tiempo real de manera económica, simple y eficaz.

Multipedidos es un sistema de ventas on-line que permite gestionar pedidos por internet en tiempo real de manera económica, simple y eficaz. Presentación Multipedidos es un sistema de ventas on-line que permite gestionar pedidos por internet en tiempo real de manera económica, simple y eficaz. El sistema está pensado para empresas que deseen

Más detalles

Introducción a los sitios de SharePoint en Office 365

Introducción a los sitios de SharePoint en Office 365 Introducción a los sitios de SharePoint en Office 365 Universidad Central del Este Contenido 1. QUÉ ES UN SITIO SHAREPOINT?... 3 2. CÓMO INGRESAR AL ÁREA DE SITIOS?... 3 3. DESCRIPCIÓN GENERAL DEL ÁREA

Más detalles

INGENIERÍA DE SOFTWARE. Sesión 3: Tipos

INGENIERÍA DE SOFTWARE. Sesión 3: Tipos INGENIERÍA DE SOFTWARE Sesión 3: Tipos Contextualización Actualmente existe una gran variedad en los software que se pueden clasificar en varias categorías, como pueden ser, por tipo de licencia, tipo

Más detalles

MANUAL DE USUARIO CMS- PLONE www.trabajo.gob.hn

MANUAL DE USUARIO CMS- PLONE www.trabajo.gob.hn MANUAL DE USUARIO CMS- PLONE www.trabajo.gob.hn Tegucigalpa M. D. C., Junio de 2009 Que es un CMS Un sistema de administración de contenido (CMS por sus siglas en ingles) es un programa para organizar

Más detalles

Capítulo 3 Diseño del Sistema de Administración de Información de Bajo Costo para un Negocio Franquiciable

Capítulo 3 Diseño del Sistema de Administración de Información de Bajo Costo para un Negocio Franquiciable Capítulo 3 Diseño del Sistema de Administración de Información de Bajo Costo para un Negocio Franquiciable 1. Introducción. El Sistema de Administración de Información de un Negocio Franquiciable (SAINF)

Más detalles

revista transparencia transparencia y... 3.3. UNIVERSIDADES

revista transparencia transparencia y... 3.3. UNIVERSIDADES revista transparencia transparencia y... 3.3. UNIVERSIDADES 35 revista transparencia Mónica López del Consuelo Documentalista Open Data Universidad de Granada 3.3.1. El filtro básico de la transparencia.

Más detalles

LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN

LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN Tabla de Contenidos LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN... 1 Tabla de Contenidos... 1 General... 2 Uso de los Lineamientos Estándares...

Más detalles

Capítulo 5. Cliente-Servidor.

Capítulo 5. Cliente-Servidor. Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor

Más detalles

Modulo I. Introducción a la Programación Web. 1.1 Servidor Web.

Modulo I. Introducción a la Programación Web. 1.1 Servidor Web. Modulo I. Introducción a la Programación Web. 1.1 Servidor Web. Antes de analizar lo que es un servidor Web y llevara a cabo su instalación, es muy importante identificar diferentes elementos involucrados

Más detalles

SCGDoc. SisConGes & Estrategia WWW.SISTEMACONTROLGESTION.COM

SCGDoc. SisConGes & Estrategia WWW.SISTEMACONTROLGESTION.COM SCGDoc SisConGes & Estrategia WWW.SISTEMACONTROLGESTION.COM POR QUÉ NECESITA USTED EL SCGDoc? DIFICULTAD PARA CONSOLIDAR JUNTOS ARCHIVOS DE DIFERENTES TIPOS, NOTAS Y EMAILS. MUCHA INFORMACIÓN DE DIFERENTES

Más detalles

Región de Murcia Consejería de Educación, Ciencia e Investigación. Manual Usuario FCT

Región de Murcia Consejería de Educación, Ciencia e Investigación. Manual Usuario FCT . Manual Usuario FCT Murcia, 9 de Julio de 2007 Manual de Usuario FCT v1.0 pág. 2 de 73 ÍNDICE Manual Usuario FCT...1 1. Tipos de usuarios... 4 2. Modelo de navegación... 5 3. Servicios... 6 3.1. Convenios...

Más detalles

Manual de usuario de Windows Live Writer

Manual de usuario de Windows Live Writer Manual de usuario de Windows Live Writer Índice 0.- Introducción. 3 1.- Descarga e Instalación. 4 2.- Conexión a un blog. 7 3.- Interfaz de Windows Live Writer. 12 4.- Creación de un Post. 13 5.- Creación

Más detalles

Artículo dedicado a la Innovación y Mejores Prácticas en la Ingeniería de Negocios

Artículo dedicado a la Innovación y Mejores Prácticas en la Ingeniería de Negocios Herramienta para Indicadores de Gestión Se ha dado cuenta de lo difícil que es conseguir que todos los miembros de su organización vean "la gran foto" y trabajen juntos para lograr los objetivos estratégicos

Más detalles

e-commerce, es hacer comercio utilizando la red. Es el acto de comprar y vender en y por medio de la red.

e-commerce, es hacer comercio utilizando la red. Es el acto de comprar y vender en y por medio de la red. Comercio electrónico. (e-commerce) Las empresas que ya están utilizando la red para hacer comercio ven como están cambiando las relaciones de la empresa con sus clientes, sus empleados, sus colaboradores

Más detalles

PROCEDIMIENTO ESPECÍFICO. Código G083-01 Edición 0

PROCEDIMIENTO ESPECÍFICO. Código G083-01 Edición 0 Índice 1. TABLA RESUMEN... 2 2. OBJETO... 2 3. ALCANCE... 2 4. RESPONSABILIDADES... 3 5. ENTRADAS... 3 6. SALIDAS... 3 7. PROCESOS RELACIONADOS... 3 8. DIAGRAMA DE FLUJO... 4 9. DESARROLLO... 5 9.1. DEFINICIÓN...

Más detalles

http://www.nicasoft.com.ni

http://www.nicasoft.com.ni BSC-RH es un sistema automatizado de planificación estratégica y gestión, utilizado en empresas para direccionar las actividades del negocio a la visión y estrategia de la organización. Mejora la comunicación

Más detalles

PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO...

PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO... Tabla de Contenido PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO... 2 1. LA PRESENCIA DE INFORMACIÓN Y AYUDA ÚTIL PARA COMPLETAR LOS TRÁMITES EN LÍNEA.... 2 2. LA DISPONIBILIDAD DE DIVERSOS

Más detalles

Sistema Web BTU 1.0 (versión beta) M a n u a l d e U s u a r i o s

Sistema Web BTU 1.0 (versión beta) M a n u a l d e U s u a r i o s Unidad Regional Norte Nogales Santa Ana Caborca Sistema Web BTU 1.0 (versión beta) M a n u a l d e U s u a r i o s Elaborado por M.A.P. Fca. Cecilia Encinas Orozco & M. C. Samuel González López Nogales,

Más detalles

Manual LiveBox WEB USUARIO. http://www.liveboxcloud.com

Manual LiveBox WEB USUARIO. http://www.liveboxcloud.com 2014 Manual LiveBox WEB USUARIO http://www.liveboxcloud.com LiveBox Srl no asume responsabilidades o garantías sobre el contenido y uso de ésta documentación y declina cualquier garantía explicita o implícita

Más detalles

LAS REGLAS DEL MERCADO HAN CAMBIADO

LAS REGLAS DEL MERCADO HAN CAMBIADO LAS REGLAS DEL MERCADO HAN CAMBIADO Hoy en día, cuando los consumidores escuchan sobre un producto, su primera reacción es Voy a buscarlo en Internet. Y emprenden una aventura de descubrimiento: sobre

Más detalles

Novedades. Introducción. Potencia

Novedades. Introducción. Potencia Introducción Basado en el demostrado rendimiento y flexibilidad de la versión 8.5, Crystal Reports 9 presenta una amplia variedad de avanzadas funciones para que el diseño, entrega e integración de informes

Más detalles

La Web Semántica como herramienta para e-learning

La Web Semántica como herramienta para e-learning La Web Semántica como herramienta para e-learning Lidia Marina López llopez@uncoma.edu.ar Departamento de Ciencias de la Computación Universidad Nacional del Comahue Buenos Aires 1400 8300 Neuquén Tel.

Más detalles

Aplicaciones Móviles. Sesión 12: Acceso a datos

Aplicaciones Móviles. Sesión 12: Acceso a datos Aplicaciones Móviles Sesión 12: Acceso a datos Contextualización Los datos son actualmente elementos muy importantes, pues éstos definen características de uso de elementos en la informática, dan identidad

Más detalles

LiLa Portal Guía para profesores

LiLa Portal Guía para profesores Library of Labs Lecturer s Guide LiLa Portal Guía para profesores Se espera que los profesores se encarguen de gestionar el aprendizaje de los alumnos, por lo que su objetivo es seleccionar de la lista

Más detalles

DG.CO.P00.E03-Manual de Usuario Carpeta Ciudadana

DG.CO.P00.E03-Manual de Usuario Carpeta Ciudadana Resumen Manual de usuario de la Carpeta Ciudadana Contenido 1. Introducción... 3 1.1 Alcance... 3 1.2 Terminología y acrónimos... 3 2. Oficina Virtual... 4 2.1 Acceso... 4 2.2 Organización... 4 2.3 Idioma...

Más detalles

Unidad II. - Las técnicas en las que se basó, las categorías de análisis o ejes centrales que permiten guiar el proceso de investigación.

Unidad II. - Las técnicas en las que se basó, las categorías de análisis o ejes centrales que permiten guiar el proceso de investigación. Unidad II Metodología de Solución de Problemas 2.1 Descripción del problema (enunciado). Este aspecto nos indica describir de manera objetiva la realidad del problema que se esta investigando. En la descripción

Más detalles

Introducción. Metadatos

Introducción. Metadatos Introducción La red crece por momentos las necesidades que parecían cubiertas hace relativamente poco tiempo empiezan a quedarse obsoletas. Deben buscarse nuevas soluciones que dinamicen los sistemas de

Más detalles

Plataforma e-ducativa Aragonesa. Manual de Administración. Bitácora

Plataforma e-ducativa Aragonesa. Manual de Administración. Bitácora Plataforma e-ducativa Aragonesa Manual de Administración Bitácora ÍNDICE Acceso a la administración de la Bitácora...3 Interfaz Gráfica...3 Publicaciones...4 Cómo Agregar una Publicación...4 Cómo Modificar

Más detalles

DOCENTES FORMADORES UGEL 03 PRIMARIA

DOCENTES FORMADORES UGEL 03 PRIMARIA DOCENTES FORMADORES UGEL 03 PRIMARIA 1. Recursos y Aplicaciones del Servidor La página de inicio del servidor (http://escuela) contiene los enlaces a las aplicaciones instaladas en el servidor, un enlace

Más detalles

Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere.

Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere. UNIVERSIDAD DE CARABOBO FACULTAD DE CIENCIA Y TECNOLOGÍA DIRECCION DE EXTENSION COORDINACION DE PASANTIAS Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere. Pasante:

Más detalles

Base de datos en Excel

Base de datos en Excel Base de datos en Excel Una base datos es un conjunto de información que ha sido organizado bajo un mismo contexto y se encuentra almacenada y lista para ser utilizada en cualquier momento. Las bases de

Más detalles

APLICATECA. Guía para la contratación y gestión de. Te Destaco

APLICATECA. Guía para la contratación y gestión de. Te Destaco APLICATECA Guía para la contratación y gestión de Te Destaco INDICE 1 QUÉ ES TE DESTACO?... 1 1.1 PARA QUÉ SIRVE?... 1 1.2 CARACTERÍSTICAS DE TE DESTACO... 1 2 CONTRATACIÓN DE TE DESTACO... 2 2.1 INICIAR

Más detalles

GUÍA Nro. 1 TECNOLOGÍA DE INTERNET. TIII PIII

GUÍA Nro. 1 TECNOLOGÍA DE INTERNET. TIII PIII GUÍA Nro. 1 TECNOLOGÍA DE INTERNET. TIII PIII GUIA DISPONIBLE EN: http://preparadorivan.blogspot.com/ - http://preparadormssi.50webs.com/inicio.html La World Wide Web o la Web, es una de las múltiples

Más detalles

Información de Producto:

Información de Producto: Windows Server 2008 Foundation La nueva tecnología rentable de Windows Server 2008 Foundation La tecnología confiable y comprobada de Windows Server Foundation proporciona una base para ejecutar las aplicaciones

Más detalles

G R U P O S INDICE Cómo crear una cuenta en ARQA? Cómo tener un grupo en ARQA? Secciones y funcionalidades de los grupos Configuración del grupo

G R U P O S INDICE Cómo crear una cuenta en ARQA? Cómo tener un grupo en ARQA? Secciones y funcionalidades de los grupos Configuración del grupo INDICE Cómo crear una cuenta en ARQA? 4 Cómo tener un grupo en ARQA? 5 Secciones y funcionalidades de los grupos 6 Muro del Grupo 6 Compartir Textos 8 Compartir Imágenes 9 Compartir videos 10 Compartir

Más detalles

WALMAR CONTROL EN RUTA MANUAL DE USUARIO ADMINISTRACION EMANAGER 6

WALMAR CONTROL EN RUTA MANUAL DE USUARIO ADMINISTRACION EMANAGER 6 WALMAR CONTROL EN RUTA MANUAL DE USUARIO ADMINISTRACION EMANAGER 6 P á g i n a 2 ÍNDICE Administración... 6 Configuración... 6 Usuarios... 6 Mantenedores... 8 Niveles de usuarios... 8 Geografía... 10 Indicadores...

Más detalles

Tools. Ibermática Soluciones Empresariales 2012, Todos los derechos reservados http://soluciones.ibermatica.com

Tools. Ibermática Soluciones Empresariales 2012, Todos los derechos reservados http://soluciones.ibermatica.com Tools http://soluciones.ibermatica.com La aplicación Tools Ibermática incluye 15 aplicaciones que llevan a cabo varios trabajos centrados en el diseño. Estas aplicaciones han sido desarrolladas pensando

Más detalles

Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech

Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech Resumen Todo documento XBRL contiene cierta información semántica que se representa

Más detalles

ÍTEMS DEL MENÚ CREACIÓN Y GESTIÓN (Última revisión: lunes, 9 de marzo de 2009)

ÍTEMS DEL MENÚ CREACIÓN Y GESTIÓN (Última revisión: lunes, 9 de marzo de 2009) JOOMLA! ÍTEMS DEL MENÚ CREACIÓN Y GESTIÓN (Última revisión: lunes, 9 de marzo de 2009) Es necesario comentar que este manual ha sido diseñado en su mayor parte por comunidadjoomla.org. Este manual es una

Más detalles

BANCO CENTRAL DE RESERVA DEL PERÚ

BANCO CENTRAL DE RESERVA DEL PERÚ CONSULTA DE DATOS ESTADÍSTICOS DEL BCRP GUÍA DE USO ÍNDICE 1. Organización de las series y zonas de la pantalla 2. Acceso a las series y consultas 3. Suscripción de usuarios 4. Manejo de listas personalizadas

Más detalles

Máster en Lenguajes y Sistemas Informáticos: Tecnologías del Lenguaje en la Web Universidad de Educación a Distancia Marzo 2013

Máster en Lenguajes y Sistemas Informáticos: Tecnologías del Lenguaje en la Web Universidad de Educación a Distancia Marzo 2013 Presentación de Trabajo de Fin de Máster PROPUESTA DE BÚSQUEDA SEMÁNTICA: APLICACIÓN AL CATÁLOGO DE MAPAS, PLANOS Y DIBUJOS DEL ARCHIVO GENERAL DE SIMANCAS Máster en Lenguajes y Sistemas Informáticos:

Más detalles

POLÍTICA DE PRIVACIDAD PARA APLICACIONES MÓVILES GRUPOCOPESA. 1. información que se obtiene la aplicación y su utilización

POLÍTICA DE PRIVACIDAD PARA APLICACIONES MÓVILES GRUPOCOPESA. 1. información que se obtiene la aplicación y su utilización POLÍTICA DE PRIVACIDAD PARA APLICACIONES MÓVILES GRUPOCOPESA Nuestra política de privacidad se aplica al uso de las aplicaciones informáticas de los siguientes medios de comunicación: LaTercera, LaCuarta,

Más detalles

ADT CONSULTING S.L. http://www.adtconsulting.es PROYECTO DE DIFUSIÓN DE BUENAS PRÁCTICAS

ADT CONSULTING S.L. http://www.adtconsulting.es PROYECTO DE DIFUSIÓN DE BUENAS PRÁCTICAS ADT CONSULTING S.L. http://www.adtconsulting.es PROYECTO DE DIFUSIÓN DE BUENAS PRÁCTICAS ESTUDIO SOBRE EL POSICIONAMIENTO EN BUSCADORES DE PÁGINAS WEB Y LA RELEVANCIA DE LA ACTUALIZACIÓN DE CONTENIDOS

Más detalles

Manual de Usuarios Contratistas y Consultores

Manual de Usuarios Contratistas y Consultores Departamento de Registros y de Consultores del MOP Manual de Usuarios Contratistas y Consultores Registro de Contratistas y Consultores Versión 6.0 Versiones del Manual Versión Mejora Fecha 1.0 Versión

Más detalles

Ajustes del Curso en egela (Moodle 2.5)

Ajustes del Curso en egela (Moodle 2.5) Ajustes del Curso en egela (Moodle 2.5) Manual para el profesorado Versión 2 (12/05/2015) El presente manual ha sido desarrollado por el Campus Virtual de la Universidad del País Vasco / Euskal Herriko

Más detalles

Los mayores cambios se dieron en las décadas de los setenta, atribuidos principalmente a dos causas:

Los mayores cambios se dieron en las décadas de los setenta, atribuidos principalmente a dos causas: SISTEMAS DISTRIBUIDOS DE REDES 1. SISTEMAS DISTRIBUIDOS Introducción y generalidades La computación desde sus inicios ha sufrido muchos cambios, desde los grandes equipos que permitían realizar tareas

Más detalles

Oasis es una fábrica para el bien común de los datos mediante la utilización de aplicaciones propuestas.

Oasis es una fábrica para el bien común de los datos mediante la utilización de aplicaciones propuestas. 1. Manual de usuario 1.1 Esquema de Oasis Oasis es una fábrica para el bien común de los datos mediante la utilización de aplicaciones propuestas. Gracias a OASIS usted podrá comprar o seleccionar aplicaciones

Más detalles

Capítulo 1 Documentos HTML5

Capítulo 1 Documentos HTML5 Capítulo 1 Documentos HTML5 1.1 Componentes básicos HTML5 provee básicamente tres características: estructura, estilo y funcionalidad. Nunca fue declarado oficialmente pero, incluso cuando algunas APIs

Más detalles

1 Itinerario. 2 Descripción y funcionalidades principales. Google Docs. 1.1 Qué vamos a hacer? 1.2 Qué pasos vamos a seguir?

1 Itinerario. 2 Descripción y funcionalidades principales. Google Docs. 1.1 Qué vamos a hacer? 1.2 Qué pasos vamos a seguir? Google Docs 1 Itinerario 1.1 Qué vamos a hacer? En este tutorial aprendemos a manejar la herramienta Google Docs, de esta forma nos introduciremos en el llamado cloud computing, que podemos traducir como,

Más detalles

GUÍA BÁSICA USUARIO MOODLE 2.6

GUÍA BÁSICA USUARIO MOODLE 2.6 GUÍA BÁSICA USUARIO MOODLE 2.6 Esta guía representa los pasos a seguir por el alumno desde la aceptación en un curso Moodle hasta su posterior utilización, pero antes de explicar la forma de acceder y

Más detalles

NOTAS TÉCNICAS SOBRE EL SIT: Comunicados (I)

NOTAS TÉCNICAS SOBRE EL SIT: Comunicados (I) NOTAS TÉCNICAS SOBRE EL SIT: Comunicados (I) Introducción...2 Introducción a los Códigos de Fusión... 2 Modelos de Cartas...2 Elaboración del Modelo... 2 Formato HTML (para envíos por correo electrónico)...

Más detalles

Mineria de datos y su aplicación en web mining data Redes de computadores I ELO 322

Mineria de datos y su aplicación en web mining data Redes de computadores I ELO 322 Mineria de datos y su aplicación en web mining data Redes de computadores I ELO 322 Nicole García Gómez 2830047-6 Diego Riquelme Adriasola 2621044-5 RESUMEN.- La minería de datos corresponde a la extracción

Más detalles

POLÍTICAS DE SEGURIDAD PARA EL DESARROLLO DE SISTEMAS DE CAPUFE

POLÍTICAS DE SEGURIDAD PARA EL DESARROLLO DE SISTEMAS DE CAPUFE SISTEMAS DE ÍNDICE PÁGINA INTRODUCCIÓN OBJETIVO 3 FUNDAMENTO LEGAL 4 DEFINICIONES 5 POLÍTICAS 6 De la base de datos Del acceso a los sistemas De los sistemas Web Ambientes de Desarrollo, Calidad o Pruebas,

Más detalles

DISPOSITIVO DE BANDA ANCHA

DISPOSITIVO DE BANDA ANCHA Como funciona un ISP Un ISP es un canalizador de información, puede canalizar la información desde Internet y hacia Internet, es decir brinda acceso a paginas de Internet y a el correo electrónico (utilizando

Más detalles

Ministerio de Salud de la Nación

Ministerio de Salud de la Nación Buenos Aires, 01 de julio de 2011 LICITACIÓN PÚBLICA ABREVIADA NACER2-114-CP-B. SOFTWARE DE TABLERO DE CONTROL Préstamo BIRF Nº 7409-AR Enmienda Nº 3 y Circular Aclaratoria Nº 1 De acuerdo a lo establecido

Más detalles

Configuración factura electrónica. construsyc instasyc

Configuración factura electrónica. construsyc instasyc Configuración factura electrónica construsyc instasyc Facturación electrónica Según la propia definición de la Agencia Tributaria, la factura electrónica es un documento tributario generado por medios

Más detalles

Oferta tecnológica: Herramienta para el desarrollo de sistemas multimedia de navegación pedestre

Oferta tecnológica: Herramienta para el desarrollo de sistemas multimedia de navegación pedestre Oferta tecnológica: Herramienta para el desarrollo de sistemas multimedia de navegación pedestre Oferta tecnológica: Herramienta para el desarrollo de sistemas multimedia de navegación pedestre RESUMEN

Más detalles

Manual para el profesor

Manual para el profesor Tus Cursos en la Web 5.0 4.2 6.3 4.2 Manual para el profesor VICERRECTORÍA DE ASUNTOS ECONÓMICOS Y GESTIÓN INSTITUCIONAL DIRECCIÓN DE GESTIÓN INSTITUCIONAL Qué es U- Cursos? U-Cursos es un servicio de

Más detalles

Haga clic en los recuadros donde indica la mano y regrese al inicio del capítulo al hacer clic en el título de la sección donde se encuentra

Haga clic en los recuadros donde indica la mano y regrese al inicio del capítulo al hacer clic en el título de la sección donde se encuentra Cómo gestiono el Plan Anual de Adquisiciones de mi Entidad en el SECOP II? Crear equipo Crear Plan Anual de Adquisiciones Publicar Plan Anual de Adquisiciones Modificar Plan Anual de Adquisiciones Buscar

Más detalles

CMMI (Capability Maturity Model Integrated)

CMMI (Capability Maturity Model Integrated) CMMI (Capability Maturity Model Integrated) El SEI (software engineering institute) a mediados de los 80 desarrolló el CMM (modelo de madurez de la capacidad de software). CMMI: CMM integrado, una mezcla

Más detalles

Este documento se distribuye bajo los términos de la licencia Creative Commons by sa. http://creativecommons.org/licenses/by sa/2.

Este documento se distribuye bajo los términos de la licencia Creative Commons by sa. http://creativecommons.org/licenses/by sa/2. Análisis de aplicación: Visual Understanding Environment (VUE) Este documento ha sido elaborado por el Centro de excelencia de software libre de Castilla La Mancha (Ceslcam, http://ceslcam.com). Copyright

Más detalles

GUÍA PARA SISTEMAS DE RASTREABILIDAD

GUÍA PARA SISTEMAS DE RASTREABILIDAD REQUISITOS GENERALES Y RECOMENDACIONES PARA IMPLEMENTAR RASTREABILIDAD DE ALIMENTOS AGROPECUARIOS PRIMARIOS Y PIENSOS 1 CAMPO DE APLICACIÓN Esta guía específica los requisitos mínimos que debe cumplir

Más detalles

Gestión de contenidos Para Editores de la Nueva Plataforma web Red Local

Gestión de contenidos Para Editores de la Nueva Plataforma web Red Local Gestión de contenidos Para Editores de la Nueva Plataforma web Red Local Objetivo de desarrollo implementar un portal web autoadministrable, práctico y amigable que integre herramientas web 3.0 que facilite

Más detalles

Servicios y aplicaciones clave de la web 2.0

Servicios y aplicaciones clave de la web 2.0 Servicios y aplicaciones clave de la web 2.0 Etiquetado y social bookmarking La web 2,0 ha permitido crear comunidades llamadas Social Bookmarking o marcadores sociales, las cuales son una forma en la

Más detalles

Capítulo 4 Pruebas e implementación de la aplicación CAPÍTULO 4 PRUEBAS E IMPLEMENTACIÓN DE LA APLICACIÓN

Capítulo 4 Pruebas e implementación de la aplicación CAPÍTULO 4 PRUEBAS E IMPLEMENTACIÓN DE LA APLICACIÓN CAPÍTULO 4 PRUEBAS E IMPLEMENTACIÓN DE LA APLICACIÓN CONCEPTOS DE PRUEBAS DE APLICACIÓN El departamento de Testing se encarga de diseñar, planear y aplicar el rol de pruebas a los sistemas que el PROVEEDOR

Más detalles

Guía de instalación de la carpeta Datos de IslaWin

Guía de instalación de la carpeta Datos de IslaWin Guía de instalación de la carpeta Datos de IslaWin Para IslaWin Gestión CS, Classic o Pyme a partir de la revisión 7.00 (Revisión: 10/11/2011) Contenido Introducción... 3 Acerca de este documento... 3

Más detalles

Guías _SGO. Gestione administradores, usuarios y grupos de su empresa. Sistema de Gestión Online

Guías _SGO. Gestione administradores, usuarios y grupos de su empresa. Sistema de Gestión Online Guías _SGO Gestione administradores, usuarios y grupos de su empresa Sistema de Gestión Online Índice General 1. Parámetros Generales... 4 1.1 Qué es?... 4 1.2 Consumo por Cuentas... 6 1.3 Días Feriados...

Más detalles

Windows Server 2012: Infraestructura de Escritorio Virtual

Windows Server 2012: Infraestructura de Escritorio Virtual Windows Server 2012: Infraestructura de Escritorio Virtual Módulo 1: Application Virtualization Módulo del Manual Autores: James Hamilton-Adams, Content Master Publicado: 5 de Octubre 2012 La información

Más detalles

I. OBJETIVOS INTRODUCCIÓN. Oscar Daniel Camuendo Vásquez e-mail: oscardny86@hotmail.com

I. OBJETIVOS INTRODUCCIÓN. Oscar Daniel Camuendo Vásquez e-mail: oscardny86@hotmail.com DISEÑO, IMPLEMENTACIÓN E IMPLANTACIÓN DE UNA APLICACIÓN WEB DE ADMINISTRACIÓN Y CONTROL DE CALIFICACIONES PARA LA UNIDAD EDUCATIVA PARTICULAR OVIEDO (SECCIÓN SECUNDARIA), UTILIZANDO SOFTWARE LIBRE. Oscar

Más detalles

Mi Negocio en Línea. DESCRIPCIÓN y CONCEPTO DEL PRODUCTO

Mi Negocio en Línea. DESCRIPCIÓN y CONCEPTO DEL PRODUCTO DESCRIPCIÓN y CONCEPTO DEL PRODUCTO INTRODUCCIÓN A LA HERRAMIENTA MI NEGOCIO EN LINEA es una revolucionaria herramienta online para crear y administrar sitios Web. Está orientado a Pequeñas y Medianas

Más detalles

www.artologik.com Programa de soporte y gestión de incidencias efectivo y fácil de usar

www.artologik.com Programa de soporte y gestión de incidencias efectivo y fácil de usar Programa de soporte y gestión de incidencias efectivo y fácil de usar Gestión de proyectos Gestión del tiempo Creación de encuestas HelpDesk Herramienta de publicación web Sistema de reservas www.artologik.com

Más detalles

QUÉ ACTIVIDADES PODEMOS HABILITAR EN EL CAMPUS VIRTUAL?

QUÉ ACTIVIDADES PODEMOS HABILITAR EN EL CAMPUS VIRTUAL? QUÉ ACTIVIDADES PODEMOS HABILITAR EN EL CAMPUS VIRTUAL? En este tutorial presentamos los distintos tipos de actividades disponibles en el Campus Virtual UNER. Para agregar una actividad dentro de un tema:

Más detalles

Gestor de Contenidos CMS. Prof: Ing. Henrry Servitá

Gestor de Contenidos CMS. Prof: Ing. Henrry Servitá Gestor de Contenidos CMS Que es un CMS? CMS son las siglas de Content Management System, que se traduce directamente al español como Sistema Gestor de Contenidos. Como su propio nombre indica, es un sistema

Más detalles

Qué es una página web?, qué conoces al respecto?, sabes crear una página

Qué es una página web?, qué conoces al respecto?, sabes crear una página Semana 13 13 Empecemos! Bienvenidos a una nueva sesión, llena de aprendizajes! En semanas anteriores estudiamos lo que son bases de datos, estructuras de datos y métodos de ordenamientos, todo lo cual

Más detalles