Gobierno de Ontologías en Sofia2 (parte I)

Blog de Sofia2 IoT Platform

Como ya conocéis las ontologías son el concepto clave de Sofia2 y el que le da esa visión semántica (en este post podéis ver cómo se trabaja con ontologías en la Plataforma).

En este primer post de una serie de 3 definiremos los conceptos básicos:

Gobierno de Ontologías en Sofia2 (parte II)

Gobierno de Ontologías en Sofia2 (parte III)

Otro tema fundamental en un Sistema es que existan una serie de normas, estándares de definición, tipos de datos predefinidos,… en general un gobierno de los conceptos que se manejan en el sistema:

Imaginemos una Smart City en la que Sofia2 se usa como Plataforma IoT para interconectar cualquier tipo de red de sensores, parece lógico que todos los dispositivos envíen la información de su posición geográfica en el mismo formato, o la medida y su magnitud de forma coherente.

Para ayudar en este gobierno Sofia2 propone una serie de…

Ver la entrada original 714 palabras más

Gobierno de Ontologías en Sofia2 (parte I)

Comó crear un Dashboard paso a paso.

En este post vamos a explicar el proceso de creación de un Dashboard.

En la Plataforma todos los módulos trabajan alrededor del concepto de Ontología, y esto también aplica a los Dashboards. Por tanto lo primero será seleccionar/crear/cargar las Ontologías que va a manejar.

En este ejemplo voy a crear un Dashboard que representa las Ventas de una empresa, así que crearemos:

  • una ontología ‘PuntoVenta‘ para representar los puntos de ventas global (continente)
  • y otra ‘PuntoVentaCliente‘ en la que representamos el punto de venta local (ciudad).

De las diversas formas que tenemos para crear una ontología seleccionamos ‘Creación Guiada Ontología’ dentro del menú Ontologías>Crear Ontología.

Veamos los atributos de cada una de ellas.

Seguir leyendo “Comó crear un Dashboard paso a paso.”

Comó crear un Dashboard paso a paso.

Usando el nuevo Visor #OpenData de Sofia2

En la última release de Sofia2 se ha incorporado una utilidad que permite visualizar ontologías definidas como públicas dentro de un Visor OpenData.

En este post vamos a:

  • Buscar un DataSet
  • Cargar el DataSet en Sofia2
  • Visualizarlo en el nuevo Visor

 

BÚSQUEDA DEL DATASET

Existen numerosos portales donde buscar un DataSet a cargar, por ejemplo:

  • Portal de datos abiertos de la Unión Europea: este portal agrupa fuentes de datos gratuitas disponibles por parte de las instituciones de la Unión Europea. Hay sobre 8200 datasets y podéis acceder a ellos en Portal de datos abiertos de UE
  • Portal de datos abiertos del Gobierno de USA: Al igual que en los datos del portal de la Unión Europea son fuentes de datos gratuitas y libres para su explotación. Además ofrecen ejemplos de aplicaciones desarrolladas, Se puede acceder a través de este enlace: Portal de datos abiertos de USA
  • Quandl: Quandl es un buscador de datos abiertos numéricos. La mayor parte de las fuentes de datos gratuitas que ofrece son datos financieros, económicos y sociales. Acceso a Quandl
  • DBpedia/Wikipedia Wikipedia está formado por millones de datos, estructurados y desestructurados sobre cualquier tema del que se tenga constancia en el mundo. DBPedia es el proyecto que busca catalogar y crear un fuente pública de datos para que cualquier persona que quiera pueda analizar los datos volcados en la wikipedia. Acceso DBPedia

En este caso usaremos el Portal de Datos Abiertos del Ayuntamiento de Madrid. Que ofrece datos en diversos formatos.

Para el ejemplo hemos elegido la información de los Aparcamientos públicos municipales,

Seguir leyendo “Usando el nuevo Visor #OpenData de Sofia2”

Usando el nuevo Visor #OpenData de Sofia2

Soporte Kudu

En esta release se ha incorporado el soporte de Apache Kudu como Base de Datos de Tiempo Real (BDTR). Kudu es una solución open-source que soporta cargas de trabajo mixtas: real-time y analytics mediante un mecanismo eficiente de escaneado sobre una única capa de almacenamiento.

Al utilizar una base de datos relacional como Kudu como BDTR, la información suministrada en las ontologías será mapeada a tabla, aunque se seguirá pudiendo insertar consultar la información en formato JSON.

Esta implementación se ha realizado utilizando el acceso JDBC de Hive, mediante el cual se tiene acceso a Impala y con ella a la interconexión Impala-Kudu.

Con el uso de Kudu se diluye la diferencia entre BDTR y BDH, permitiendo el almacenamiento sobre una única capa de almacenamiento y simplificando la arquitectura de aplicacions mixtas.

Para configurar Kudu como BDTR en una instalación de Sofia2 únicamente hay que modificar unos parámetros de configuración para redirigir la lógica hacia el DAO encargado de la gestión.

parametrosKudu.JPG

En una instalación de Sofia2 con Kudu como BDTR, la creación de ontologías se realiza campo a campo, en el que en cada uno habrá que indicar el tipo de dato. Con esta información se irán generando las columnas de nuestra tabla relacional.

Seguir leyendo “Soporte Kudu”

Soporte Kudu

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

Concepto Usuario Extendido

El concepto de Usuario Extendido en Sofia2 surge de la necesidad de disponer de información adicional acerca de los usuarios registrados en la plataforma. Además, se entiende que la información adicional requerida puede variar a lo lago del desarrollo de una actividad, por lo que se ha desarrollado este concepto de manera que es fácilmente configurable y ampliable.

Si se desean añadir campos adicionales dentro del formulario de registro de usuario de la plataforma tan solo es necesario registrar dichos campos en la Base de Datos de Configuración (BDC), concretamente en la tabla “tipodatoformulario”, que dispone de las siguientes columnas:

  • ID: Identificación única de la fila.
  • Tipo: Tipo de dato que se desea añadir. Puede ser String, Date, Double o Float.
  • Clave: Nombre que representa al campo adicional que se desea registar. No puede contener espacios ni tildes.

A continuación se muestra un ejemplo en el que se han añadido cuatro campos adicionales al formulario del usuario en la plataforma:

datosejemplotipodatoformulario.JPG

Seguir leyendo “Concepto Usuario Extendido”

Concepto Usuario Extendido

Extended User Concept

The Extended User concept in Sofia2 arises from the necessity of having additional information of registered users on the platform. Because of the required additional information can been changed during the development of an activity, this concept has been developed for being easily configurable and expandable.

If you want to add fields within the user registration form of the platform, you only have to register the fields in the Configuration Database (CDB), specifically in the table “tipodeatoformularo”, which has the following columns:

  • ID: Identification of the row
  • Tipo (Type): Data type to be added. It only can be String,Date,Double or Float
  • Clave (Key): Name of the field that you want to add. It can neither spaces nor accents.

Here there is an example about this:

datosejemplotipodatoformularioen

Seguir leyendo “Extended User Concept”

Extended User Concept