Adquisición, transformación y consumo de datos GSMA/FIWARE Data Model

flujoDeconexion

En el post Cómo trabajar con Data Model FIWARE/GSMA en Sofia2 vimos cómo la plataforma Sofia2 soporta los Data Models GSMA y FIWARE. Aprendimos cómo crear Ontologías conforme a estos modelos y cómo insertar datos y consultarlos mediante la herramienta disponible en la plataforma Consola BDTR y BDH. También vimos cómo publicar esta Ontología como un API RESTFul y cómo consumir el API.

 

Además, disponemos del documento Uso de FIWARE Data Model y publicación API NGSI9donde se explica cómo consumir APIS modeladas conforme semántica FIWARE Data Model y publicadas en la Plataforma siguiendo el protocolo NGSI-9.

 

Para el ejemplo se utilizan las Ontologías:

  • GSMA_OffStreetParking_Destino
  • GSMA_PointOfInterest_Beach
  • GSMA_PointOfInterest_Museum

 

Paso a paso se explica cómo suscribirnos a éstas Ontologías, cómo consultar sus Datos mediante la Consola BDTR y BDH, cómo suscribirse a APIs NGSI-9 y consumirlas mediante el portal del desarrollador del API Manager y cómo acceder a estas APIs vía Curl.

 

consumoDatos

 

Con toda esta información, y conociendo que Sofia2 permite crear Reglas Scripts (se aconseja leer el documento Guía de Uso Motor Scripting Sofia2) que se ejecutarán ante la llegada de instancias de Ontologías o cada cierto tiempo, es fácil entender cómo podemos recibir datos con una estructura determinada y transformarlos para cumplir con estos Data Models. 

 

Lo comprobaremos mediante el siguiente flujo:

flujoDeconexion

 

En este ejemplo, se recogen datos de parkings de Smart Coruña, se ingestan en la plataforma Sofia2 a una Ontología, cada vez que se recibe una instancia de esta ontología se lanza un Script que transforma estos datos adaptándolos a los Data Model y consultándolos, vemos como efectivamente, se cumple con los Data Models GSMA y FIWARE.

 

ejemploparking

Adquisición, transformación y consumo de datos GSMA/FIWARE Data Model

Data Model GSMA en Sofia2

1

Se ha disponibilizado en Sofia2 la documentación que define el soporte y funcionamiento de los Data Model GSMA en la plataforma Sofia2.

La asociación GSMA (asociación de operadores móviles) está trabajando en un IoT Big Data Harmonised Data Model. Por otro lado en la iniciativa FIWARE se han inspirado en el Data Model GSMA para crear los FIWARE Data Models.

Los Data Models GSMA (también llamados FIWARE DataModel) se definen en JSON, por lo que su representación como Ontología Sofia2 es inmediata. Para ello, haremos uso de las plantillas predefinidas en Sofia2 que soportan los anteriores modelos:

plantillas

En la documentación, que te puedes descargar aquí, o puedes consultar en versión web aquí, encontrarás cómo se definen los modelos de datos en Sofia2 para soportar los Data Models GSMA, ejemplos de uso, y un completo “Hands On” que abarca la creación de Ontologías, carga de datos mediante CRUD de Instancias, consulta de datos con la Consola BDTR y BDH, y cómo publicar Ontologías como API RESTFUL.

Data Model GSMA en Sofia2

Cómo trabajar con Data Model FIWARE/GSMA en Sofia2

La asociación GSMA (asociación de operadores móviles está trabajando en un IoT Big Data Harmonised Data Model

Que define estas entidades: AgriCrop, AgriGreenHouse, AgriParcel, AgriParcelOperation, AgriParcelRecord, AgriPest, AgriProduct, AgriProductType, AgriSoil, AirQualityObserved, Building, BuildingOperation, BuildingType, Device, DeviceModel, DeviceOperation, EnvironmentObserved, Machine, MachineModel, MachineOperation, PointOfInterest, Road, RoadSegment, Subscriber, SubscriptionService,Vehicle, VehicleFault, VehicleType, WaterQualityObserved, WeatherForecast y WeatherObserved.

Por otro lado en la iniciativa FIWAREse han inspirado en el Data Model GSMA para crear los FIWARE Data Models, donde además se han seleccionado un conjunto de Entidades sobre estas de GSMA:

  • Alarms Events related to risk or warning conditions which require action taking.
  • Parks & Gardens Data models intended to make an efficient, effective and sustainable management of green areas.
  • Environment Enable to monitor air quality and other environmental conditions for a healthier living.
  • Point of Interest Specific point locations that someone may find useful or interesting. For instance, weather stations, touristic landmarks, etc.
  • Civic Issue tracking Data models for civic issue tracking interoperable with the de-facto standard Open311.
  • Street Lighting Modeling street lights and all their controlling equipment towards energy-efficient and effective urban illuminance.
  • Device IoT devices (sensors, actuators, wearables, etc.) with their characteristics and dynamic status.
  • Transportation Transportation data models for smart mobility and efficient management of municipal services.
  • Indicators Key performance indicators intended to measure the success of an organization or of a particular activity in which it engages.
  • Waste Management Enable efficient, recycling friendly, municipal or industrial waste management using containers, litters, etc.
  • Parking Real time and static parking data (on street and off street) interoperable with the EU standard DATEX II.
  • Weather Weather observed, weather forecasted or warnings about potential extreme weather conditions.

Los Data Models GSMA y FIWARE se definen en JSON por lo que su representación como Ontología Sofia2 es inmediata (recomendamos al respecto leer el documento Gobierno de Ontologías o el conjunto de posts al respecto).

En Sofia2 se soportan ya estas entidades vía Plantillas (una plantilla sirve para crear ontologías partiendo de una definición):

A continuación veremos cómo Sofia2 permite trabajar con estas entidades, pongamos el ejemplo de la entidad WeatherObserved (This entity contains a harmonised description of the weather at a particular location and time. This entity is primarily associated with the vertical segments of the environment and agriculture but is applicable to many different applications):

Seguir leyendo “Cómo trabajar con Data Model FIWARE/GSMA en Sofia2”

Cómo trabajar con Data Model FIWARE/GSMA 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