Publicada Release 2.8.0 de SOFIA2

Ya está disponible la release 2.8.0 de SOFIA2, esta release también se ha disponibilizado en la Plataforma de Experimentación SOFIA2 In-Cloud.

Esta versión añade a la Plataforma las siguientes funcionalidades

· Nueva Web SOFIA2: estrenamos una nueva versión de la Web de SOFIA2 (http://sofia2.com/) , esta nueva Web sigue un responsive design adaptable al tipo de dispositivo desde el que se accede.

· Versión Inicial de API Manager SOFIA2: SOFIA2 incorpora en esta versión capacidades de API Manager. Esto permite que los usuarios de la Plataforma puedan interactuar con SOFIA2 a través de recursos REST sin la necesidad de manejar los conceptos avanzados de SOFIA2 (ontologías, KPs,…), permitiendo además que SOFIA2 disponga de un catálogo de APIs REST que permitirá al usuario acceder a la información almacenada para desarrollar sus propias aplicaciones o extender las propias de forma simple.

A través de estas capacidades el propietario de una ontología puede publicar las operaciones sobre una ontología como API REST de forma muy sencilla:

quedando automáticamente publicada su API en el SIB API Manager.

Cada usuario puede gestionar sus APIs (publicar, deprecar,…)

Los usuario pueden buscar APIs publicadas por otros usuarios de forma sencilla

y suscribirse a ellas para usarlas.

El usuario también puede probar las APIs a las que está suscrito a través de un interfaz Web:

Para acceder a las APIS se usa un API Key (X-SOFIA2-APIKey) que se genera para cada usuario y que se pasa por cabecera HTTP en las peticiones.

· Proceso Paso BDTR a BDH configurable: esta funcionalidad permite preprocesar los datos en el proceso automático que pasa de la BDTR a la BDH, lo que permite por ejemplo agrupar los datos antes de volcarlo, detectar datos inválidos y corregirlos,…

Un usuario administrador puede incorporar a la definición de una ontología una clase procesadora (clase Java siguiendo el paradigma MapReduce) que se encargue de ese preproceso. Se incluye también un ejemplo de proceso y un framework de testing.

· Publicación API Node.js se añade a las APIs ya disponibles (Java, Javascript, C, Android, Arduino) este API que comunica con SOFIA2 a través de MQTT soportando publicación y suscripciones, incluye ejemplos.

 

· Ampliación Wizard creación KPs Visualizadores en Tiempo real: en esta versión el Wizard que permite crear (y descargar) KP visualizadores soporta aparte de la suscripción definir la consulta SQL de los datos a representar.

· Montaje Infraestructura Nexus para descarga de dependencias y librerías del SDK: accesible a través de:

http://sofia2.org/nexus

http://sofia2.org/nexus/content/groups/public

Esto permite independizar las distribuciones del SDK de las versiones de la Plataforma, reducir el tamaño de este y permite que los desarrolladores SOFIA2 tengan en todo momento las últimas versiones de las API sin necesidad de descargarse y actualizarse su entorno de desarrollo.

· Creación de Plugin de Tipo Infraestructura: este nuevo tipo de plugin se integra en todas las capas de la plataforma, opera de forma asíncrona para no afectar al funcionamiento del SIB y puede usarse por ejemplo para auditar la información que fluye por la plataforma. Este tipo de plugin se ha usado para la integración con los Servicios Transversales de Smart Coruña.

· Ampliación Plugins Pre y post-procesamiento dotándoles de capacidad de ejecución asíncrona, lo que permite que estos plugins se ejecuten sin afectar el flujo normal de procesamiento de un mensaje

· Ampliación demostración Visor geográfico con los autobuses de Gijón integrados (http://sofia2.com/Examples/Geographics.html)

· Resolución de diversos bugs e incorporación de mejoras de rendimiento y estabilidad

Publicada Release 2.8.0 de SOFIA2

Protocolos IoT (MQTT, REST, CoAP, XMPP) y SOFIA2

En este post IoT Protocol Wars: MQTT vs CoAP vs XMPP Oleg Puzanov, un especialista en el mundo IoT, os recomiendo su Blog IoT Primer analiza los principales protocolos IoT actuales:

· MQTT and its variants like MQTT-S

· CoAP

· XMPP

· REST API

Este diagrama resume las características de cada protocolo:

Y la conclusion de Oleg tras el análisis es clara: “My personal experience with these protocols in IoT space makes me lean towards MQTT / MQTT-S or REST API in the end

Es muy interesante también este documento Google Docs público en el que se hace un análisis más completo de estos protocolos.

Y en SOFIA2:

Como sabéis los que ya conocéis SOFIA2 entre los diversos conectores de SOFIA2 tenemos el conector REST y el conector MQTT (además de conector WebSockets – en pruebas-, Ajax Push, Web Services y la capacidad de crear tus propios conectores).

Protocolos IoT (MQTT, REST, CoAP, XMPP) y SOFIA2

¿Qué es OGC SensorThings API y cómo encaja en SOFIA2?

El API OGC SensorThings es un candidato a convertirse en estándar por el grupo OGC Sensor Web for IoT Standards Working Group (SW-IoT SWG) para ofrecer una forma abierta y unificada de interconectar dispositivos IoT, datos y aplicaciones sobre la Web.

El API SensorThings es un estándar abierto, construido sobre protocolos Web y aplicando un estilo REST, su objetivo es ofrecer una forma unificada de exponer hacia el mundo toda la información del Internet de las Cosas.

Con el objetivo de proveer una forma unificada de acceso a los datos y capacidades de los dispositivos IoT el API SensorThings define un modelo de datos IoT, donde el core de ese modelo es una Thing.

· Cada Thing puede tener 0..* localizaciones en el espacio o tiempo.

· Cada Thing puede tener 0…* DataStreams (DataStreams core del Sensing Profile)

El data model consiste de 2 partes:

· Sensing Profile: permite a los dispositivos IoT y a las aplicaciones CREATE, READ, UPDATE, and DELETE (HTTP POST, GET, PUT yDELETE) datos IoT en un Servicio SensorThings.

· Tasking Profile: permite a las aplicaciones controlar dispositivos IoT a través de un Servicio SensorThings.

En la figura se muestra el Data Model:

· Thing tiene una Location en espacio y tiempo

· Thing puede tener múltiples DataStreams que son colecciones de Observation agrupadas por la misma Observed Property

· Una Observation es un evento ejecutado por un Sensor que produce un resultado cuyo valor es un estimado de una Observed Property de la Feature Of Interest

· Thing puede tener múltiples Tasking Capabilities como function ejecutable que es ejecutada por un Actuador

· Users pueden crear entidades Task en el servicio para ejecutar .

Un ejemplo de instanciación de una Thing (con hyperlinks) tendría este aspecto en JSON:

Donde la Location sería:

Y ahora su encaje en SOFIA2:

Para empezar encaja en el objetivo creacional de SOFIA2 de ser interoperable con diversos protocolos, lenguajes, plataformas y estándares.

En cuanto a la parte práctica, si os habéis fijado bien y conocéis lo suficiente el concepto de Ontologías SOFIA2 (si no podéis echarle un ojo a este documento) habréis descubierto que nada impide modelar este Data Model SensorThings a través de una Ontología SOFIA2, de hecho SOFIA2 ya soporta la definición de Ontologías siguiendo el modelo AMON que tiene muchas similitudes con este modelo.

Y por otro lado con la próxima nueva funcionalidad de API Manager SOFIA2 que permite de forma sencilla publicar cada Ontología como una API REST manteniendo los criterios de seguridad la funcionalidad del API REST SensorThings es muy semejante a la del API REST SOFIA2.

¿Qué es OGC SensorThings API y cómo encaja en SOFIA2?

Herencia de Ontologías en SOFIA2

En la nueva release de SOFIA (2.7.0) se ha añadido el concepto de herencia en las Ontologías SOFIA2.

Este concepto nos permite a través de una Jerarquía Padre-Hijo que a un grupo de ontologías con una estructura común (definida en la Ontología Padre) puedan establecérseles permisos a nivel de cada ontología (Ontología Hijo).

Por tanto a la hora de definir una ontología podemos elegir entre:

Ontologías Padre: son Ontologías abstractas (no instanciables) que sirven de “Plantilla” a las ontologías Hija.

Ontologías Hijas: son ontologías que extienden de una Ontología Padre (utilizarán su esquema). Mantienen su propia configuración (seguridad, paso BDH,…).

Ontologías de tipo general: Las ontologías que se conocen hasta el momento (la gestión y funcionamiento de las mismas es el utilizado hasta ahora).

Para usar estos conceptos desde la consola:

1- Un usuario COLABORADOR o ADMINISTRADOR crearía la Ontología Padre. Principalmente se definirá el esquema de la Ontología.

En la pantalla de creación de Ontología se incluye un nuevo panel Seguridad Ontología, en el que se mostrarán los controles asociados a la nueva funcionalidad.

Se seleccionará la opción Ontología Padre. Tras seleccionarla, se deshabilitará el combo Ontología Padre de la que extiende. Se completará el resto de campos y se pulsará sobre crear. Se habrá creado una ontología Padre, que se mostrará como tal en los listados (dependiendo de permisos y sólo para ADMINISTRADORES y COLABORADORES).

A la hora de listarse las ontologías Padre e Hijo se diferencian:

Donde indica Ontología Padre y indica Ontología Hija.

2- Mediante el uso de la pantalla de Autorizaciones Ontologías el usuario propietario podrá autorizar a otros usuarios a que usen la Ontología Padre. En la combo de Ontologías, para el usuario propietario (o ADMINISTRADOR) se incluirán sus ontologías padre, pudiendo seleccionarlas para permitir su uso por otros usuarios.

3- Los usuarios autorizados podrán crear Ontologías Hijas a partir de la Ontología Padre. Se definirán todos los parámetros de la misma, excepto el esquema, que lo tomará de la Ontología Padre de la que extienda. Se utilizará la pantalla de creación, pero en este caso se seleccionará una de las ontologías del campo Ontología Padre de la que extiende. Se recargará el esquema con la información asociada a la Ontología Padre seleccionada.

Una vez creada, se tratará a la Ontología Hija como una ontología más. Se podrá realizar todo tipo de operaciones sobre la misma. Además, se podrá autorizar a otros usuarios para que utilicen dicha ontología tal y como se hace con las actuales.

Se podrá consultar tanto las Ontologías Padres como las Hijas. En el caso de las Padres, se mostrará un enlace a las Ontologías Hijas (para el propietario) que extiendan de ella:

Para el caso de Ontologías Hijas, se incluirá la Ontología Padre de la que extiende y un enlace para consultarla:

Herencia de Ontologías en SOFIA2

Comparando sintaxis de consultas de FIWARE Orion Context Broker y SOFIA2 SIB

En este post vamos a ver cómo el SIB de SOFIA2 y el GE FIWARE Orion Context Broker permiten hacer consultas, empecemos:

Conforme a la documentación de FIWARE Orion Context Broker las consultas en el Orion Context Broker se realizan con el mensaje NGSI-10 queryContext que tiene esta sintaxis:

En XML:

REQUEST XML queryContext RESPONSE XML queryContext
<queryContextRequest><entityIdList>

<entityId type=”Room” isPattern=”false”>

<id>Room1</id>

</entityId>

</entityIdList>

<attributeList/>

</queryContextRequest>

<?xml version=”1.0″?><queryContextResponse>

<contextResponseList>

<contextElementResponse>

<contextElement>

<entityId type=”Room” isPattern=”false”>

<id>Room1</id>

</entityId>

<contextAttributeList>

<contextAttribute>

<name>temperature</name>

<type>centigrade</type>

<contextValue>23</contextValue>

</contextAttribute>

<contextAttribute>

<name>pressure</name>

<type>mmHg</type>

<contextValue>720</contextValue>

</contextAttribute>

</contextAttributeList>

</contextElement>

<statusCode>

<code>200</code>

<reasonPhrase>OK</reasonPhrase>

</statusCode>

</contextElementResponse>

</contextResponseList>

</queryContextResponse>

Y en JSON:

REQUEST JSON queryContext RESPONSE JSON queryContext
{“entities”: [

{

“type”: “Room”,

“isPattern”: “false”,

“id”: “Room1”

}

]

}

{“contextResponses”: [

{

“contextElement”: {

“attributes”: [

{

“name”: “temperature”,

“type”: “centigrade”,

“value”: “23”

},

{

“name”: “pressure”,

“type”: “mmHg”,

“value”: “720”

}

],

“id”: “Room1”,

“isPattern”: “false”,

“type”: “Room”

},

“statusCode”: {

“code”: “200”,

“reasonPhrase”: “OK”

}

}

]

}

En el caso de SOFIA2 se soportan mensajes SSAP de Query bien en el lenguaje nativo de la BDTR o bien en lenguaje SQL para la BDTR o la BDH, para eso SOFIA2 incorpora parsers SQL para MongoDB (BDTR) y Hadoop (BDH).

Más detalle sobre el protocolo SSAP aquí.

Request SSAP QUERY Response SSAP QUERY
{“body”:{

“query”:”select * from feedAutobus where Feed.assetId=’316′ limit 1“,

“queryType”:”SQLLIKE

},

“direction”:”REQUEST”,

“ontology”:”feedAutobus”,

“messageType”:”QUERY”,

“messageId”:null,

“sessionKey”: “480e20eb-9100-4c6d-af6f-da688095311b”

}

{“body”: {

“data”: [

{

“_id”: {

“$oid”: “533bff5f50ae67a5ab0c433c”

},

“Feed”: {

“assetId”: “316”,

“assetName”: ” Autobús nº 316 “,

“assetSource”: “guiaLocal”,

“assetType”: “Autobus”,

“attribs”: [

{

“name”: “linea”,

“value”: “1”

},

{

“name”: “nombreLinea”,

“value”: “Abente y Lago – Os Castros”

},

{

“name”: “estado”,

“value”: “Tipo de Autobús: Normal piso bajo . Última parada por la que ha pasado Plaza de Mina, 26 Hora de paso 14:15 Proxima parada: Plaza de Orense\\n”

}

],

“feedId”: “1:316:2014-04-02T12:15:28.706266”,

“feedSource”: “guiaLocal”,

“geometry”: {

“coordinates”: [

-8.403705353600992,

43.36721562022267

],

“type”: “Point”

},

“measures”: [ ],

“measuresTimestamp”: {

“$date”: “2014-04-02T12:15:28.706Z”

},

“measuresType”: “INSTANT”,

“timestamp”: {

“$date”: “2014-04-02T12:15:28.706Z”

},

“type”: “MOBILE”

}

}

],

“error”: null,

“errorCode”: null,

“ok”: true

},

“direction”: “RESPONSE”,

“messageId”: null,

“messageType”: “QUERY”,

“ontology”: “feedAutobus”,

“sessionKey”: “480e20eb-9100-4c6d-af6f-da688095311b”

}

Que expresado en lenguaje MongoDB quedaría:

{

“body”:{

“query”:”db.feedAutobus.find({assetId:’316’}).limit(1)“,

“queryType”:”NATIVE

},

“direction”:”REQUEST”,

“ontology”:”feedAutobus”,

“messageType”:”QUERY”,

“messageId”:null,

“sessionKey”: “480e20eb-9100-4c6d-af6f-da688095311b”

}

Además de las diferencias en el lenguaje de consultas puede apreciarse las diferencias en el modelado de la información, en FIWARE se manejan estructuras genéricas NGSI (contextElement,…) mientras que en SOFIA2 se consultan y se devuelve instancias de las ontologías definidas en SOFIA2.

Por otro lado en SOFIA2 se comprueban los permisos en la ejecución de la consulta, de modo que un usuario sólo pueda consultar (o insertar,…) sobre ontologías de las que tiene permiso.

Comparando sintaxis de consultas de FIWARE Orion Context Broker y SOFIA2 SIB

Publicando información Open Data en SOFIA2

En la actualidad muchas entidades públicas como Ayuntamientos, Diputaciones, Comunidades Autónomas publican información Open Data para que quede disponible a todo el mundo de forma libre para su uso y explotación.

Podemos encontrar gran cantidad portales públicos exponiendo información Open Data en internet. Ejemplos de ellos pueden ser:

· El catalogo de datos en el ayuntamiento de Gijón: http://datos.gijon.es/risp_datasets

· Portal Open Data del Ayuntamiento Málaga: http://datosabiertos.malaga.eu

· Portal de datos abiertos del Gobierno de Aragón: http://opendata.aragon.es/catalogo/catalogo.html

· Portal de datos abiertos de la Junta de Castilla y León http://www.datosabiertos.jcyl.es/

La información Open Data se expone en cualquier tipo de formato estándar (CSV, RDF, HTML, XML, Excel…) de manera que los ciudadanos pueden hacer uso de ella.

SOFIA2 como plataforma de interoperabilidad ofrece utilidades para almacenar, exponer e intercambiar información entre usuarios, dispositivos y aplicaciones.

Para ello, son necesarias las siguientes tareas:

1. Estructurar y normalizar la información con una ontología. Se trata de definir un esquema con el formato de la información.

2. Dar de alta la ontología con los permisos adecuados para que los KPs puedan producir y consumir información.

3. Inserción y mantenimiento en la BDTR de los datos de la ontología.

4. Consulta de la información.

SOFIA2 proporciona a colaboradores y administradores utilidades para almacenar y exponer a los KPs información Open Data del mismo modo que si se tratase de información producida por otros KPs.

En este sentido a partir de un fichero Excel/CSV es posible generar automáticamente la ontología que lo representa y cargarla en la base de datos de SOFIA2 con los datos almacenados en el fichero.

Esto es posible gracias a que los ficheros Excel/CSV por su estructuración en columnas de información, pueden ser convertidos automáticamente en ontologías siguiendo la siguiente regla:

· En la primera fila del fichero, cada columna se corresponderá con un atributo de la ontología y su valor será el nombre del atributo.

· El resto de filas serán instancias de ontologías donde cada columna será el valor del atributo correspondiente.

Veámoslo sobre la plataforma:

Vamos a generar en SOFIA2 una ontología Open Data a partir de un fichero Excel/CSV:

1. Descargamos el fichero Open Data desde el portal público. Para este ejemplo seleccionaremos el registro de centros sanitarios de Castilla y León, descargable desde http://www.datosabiertos.jcyl.es/ en formato CSV:

2. Examinamos el fichero descargado para comprobar que cumple la condición de que la primera fila es el nombre de cada columna:

En este caso vemos que no se cumple la condición, ya que la primera fila es un título, por lo que la borramos y salvamos dejando el fichero así:

3. Entramos en la consola de administración de la plataforma http://sofia2.com/console/ con rol Colaborador o Administrador y elegimos la opción de menú ONTOLOGIAS > Crear ontología desde Excel:

4. Daremos a la ontologia el nombre CentrosMedicosCYL, su descripción, la declaramos como Activa y Pública, seleccionamos el fichero Excel/CSV que descargamos (al ser un CSV indicamos el delimitador de campos). Pulsamos Generar Ontologia y si la generación es correcta, se mostrará la ontología en el editor de ontologías:

También es posible programar el paso desde BDTR a BDH, pero en nuestro caso carece de sentido al ser unos datos estáticos en el tiempo, por lo que seleccionaremos la opción No Pasar.

5. A continuación procedemos a Crear la ontología para que se genere en la plataforma. Durante este proceso se realizará la carga de los datos en BDTR. Para ello pulsamos el botón Crear:

6. Finalizado el proceso, se mostrará un resumen con la ontología creada:

junto con un informe de carga donde se mostrarán los problemas que hayan podido surgir cargando los datos en algún registro:

7. Una vez finalizada la carga, los datos que originalmente estaban en fichero Open Data, ahora pueden ser consultados en SOFIA2, como si de cualquier otra ontología se tratase:

Pudiendo ser consumidos por los KPs a traves de mensajes de SSAP QUERY:

Publicando información Open Data en SOFIA2

Consulta Información pública en SOFIA2

En la última release de SOFIA2 (2.7.0) se añadió a la consola y API Web de SOFIA2 la capacidad de poder consultar la información pública (las ontologías definidas como públicas) a usuarios no logados.

Esta funcionalidad corresponde con la ampliación de SOFIA2 hacia soporte de conceptos OpenData.

En la sección de la web correspondiente a la Plataforma de Experimentación SOFIA2 InCloud encontraréis una nueva opción:

Que permite localizar información pública registrada en la plataforma introduciendo cualquier palabra relacionada:

Tras introducir el término de búsqueda, se mostrarán todas las Ontologías relacionadas con el mismo.

Se incluye además la opción de mostrar los últimos 5 ó 100 registros asociados a dicha Ontología.

feed

Consulta Información pública en SOFIA2