Como hemos hablado ya muchas veces, la transformación digital se encuentra extendida a todos los negocios y niveles, no sólo ya en el sector privado sino también en las administraciones públicas y gobiernos de todo el mundo. Esta digitalización ha venido acompañada de la generación de una cantidad ingente de datos, los cuales hay que almacenar para su posterior explotación, así como para poder reutilizar.

A la hora de generar estructuras de datos en las que almacenar toda esta información, como puede ser el caso de las Entidades de Onesait Platform, contar con un modelo de información que siga una estructura que haya sido adoptada globalmente resulta clave para poder crear y participar en un mercado digital de soluciones inteligentes, replicables y, sobre todo, interoperables. Y es aquí donde entran en juego los «Smart Data Models».

¿En qué consisten?

Los modelos de datos inteligentes son similares a los modelos de datos tradicionales, en donde se representan los elementos de un conjunto de datos y de sus relaciones y conexiones entre sí, pero que proporcionan una base técnica para lograr sustentar un mercado digital de soluciones inteligentes interoperables y replicables en múltiples sectores, de forma que se homogenice la disponibilidad de datos en ámbitos determinados.

El programa Smart Data Models

El programa Smart Data Models (SDM) es un programa de colaboración que busca apoyar la adopción de modelos de datos comunes y compatibles, que sustenten un mercado digital de soluciones inteligentes interoperables y reproducibles.

Este programa se encuentra liderado por la fundación FIWARE, la IUDX, TM Forum y OASC, organismos que buscan conseguir unos modelos comunes, como decimos, para utilizar en los mercados digitales de soluciones inteligentes, como en el caso de las Smart Cities, energía, medio ambiente, robótica, logística, sanidad, destinos inteligentes, etc.

El objetivo fundamental del SDM es que las organizaciones puedan evolucionar su visión de intercambio de datos hacia una compartición que dé soporte tanto a la llamada «economía del dato» como a los espacios de datos. Esta economía del dato no es más que el conjunto de actividades e iniciativas cuyo modelo de negocio se basa en el descubrimiento y explotación de los datos, para la identificación de oportunidades que generen productos y servicios.

Bases

La idea que se persigue es que los modelos se elaboren siguiendo los principios de la estandarización ágil, lo que va a permitir crear especificaciones en menos de una semana (data-model-in-a-week) siempre y cuando se disponga de ejemplos se uso y definiciones. Los modelos de datos se incorporarán a partir de dos fuentes diferentes: el mapeo de estándares abiertos y ya adoptados (estándares que permiten su libre uso, libre personalización y libre intercambio de personalizaciones) y casos de uso reales.

Para ello, se siguen estas siete prácticas de estandarización ágil:

1. No sólo hay que estandarizar, sino que hay que ser ágil y estandarizar.
2. No hay que reinventar la rueda.
3. Hay que normalizar casos reales.
4. Hay que ser abierto.
5. No hay que ser demasiado específico.
6. Centrarse en algo plano, no en profundidad.
7. La sostenibilidad es la clave.

Veamos con un poco más de detalle en qué consiste cada una de estas prácticas.

1.- No sólo hay que estandarizar, sino que hay que ser ágil y estandarizar.

La estandarización ágil se distingue por su rapidez, midiendo el progreso en días o semanas en lugar de meses o años. Esto implica automatizar procesos y minimizar la intervención humana para evitar errores y retrasos.

2.- No hay que reinventar la rueda

Hay que aprovechar lo que ya existe y está en uso común en el mercado con licencias abiertas. En lugar de crear nuevos estándares teóricos, hay que enfocarse en soluciones que resuelvan problemas reales y sean necesarias.

3.- Hay que normalizar casos reales

Basarse en casos de uso que ya han demostrado ser útiles en el mercado asegura que los estándares sean prácticos y aplicables.

4.- Hay que ser abierto

Los resultados de la estandarización ágil deben estar disponibles con licencias abiertas que permitan su reutilización, modificación y compartición libremente.

5.- No hay que ser demasiado específico

Aunque los modelos de datos deben resolver problemas reales, deben ser lo suficientemente generales para abarcar múltiples casos de uso. Se tiene que evitar, por tanto, hacer obligatorios demasiados atributos para no complicar los modelos.

6.- Centrarse en algo plano, no en profundidad

Los modelos deben ser lo más independientes posible. Es preferible acceder a los datos desde un único lugar, evitando referencias excesivas entre modelos que compliquen su uso.

7.- La sostenibilidad es la clave

La estandarización ágil debe considerar la continuidad y la mejora continua de los modelos, adaptándolos según cambie el mercado. No es un proyecto de un único uso, sino un esfuerzo constante.

Un ejemplo práctico de Smart Data Models: Smart Cities

La arquitectura de referencia y los modelos de datos utilizan la API FIWARE NGSI y las API abiertas de TM Forum para la interoperabilidad y escalabilidad de las soluciones inteligentes.

La tecnología FIWARE Context Broker, que implementa las API FIWARE NGSI (NGSI v2 y NGSI-LD), proporciona la base para romper los silos de información en las organizaciones que aspiran a convertirse en inteligentes. Esto va a permitir una visión en tiempo real (o muy próxima al tiempo real) y dar lugar a la base para el desarrollo de sistemas de gobernanza a nivel de organización global. Ejemplos de este tipo de organizaciones son ciudades, fábricas, hospitales, aeropuertos, granjas, etc.

Combinadas con las API abiertas del TM Forum, las plataformas de publicación de datos pueden ayudar a las organizaciones a aprovechar el potencial de los datos abiertos en tiempo real, facilitando el desarrollo de soluciones innovadoras por parte de terceros. Además, las organizaciones pueden hacer evolucionar sus actuales políticas de intercambio de datos hacia una visión que, compartida con otras organizaciones, aporte apoyo a una Economía de Datos. De este modo, la arquitectura de referencia propuesta está preparada para resolver las necesidades actuales de las organizaciones, al tiempo que se prepara para los requisitos futuros.

Para las ciudades inteligentes, existen de momento las siguientes estructuras de datos:

• dataModel.Building
• dataModel.GBFS
• dataModel.OSLO
• dataModel.Parking
• dataModel.ParksAndGardens
• dataModel.PointOfInterest
• dataModel.Ports
• dataModel.S4BLDG
• dataModel.Streetlighting
• dataModel.Transportation
• dataModel.UrbanMobility
• dataModel.WasteManagement
• dataModel.Weather
• dataModel.WifiNetwork

Dentro de cada una de ellas, encontramos diferentes tipos de entidades disponibles. Así, para el caso de los edificios (primera opción de la lista), se cuenta con estos cuatro tipos:

• Building: con la información correspondiente de un edificio.
• BuildingOperation: en este caso, con la información de operación del edificio.
• BuildingType: este tipo de entidad contiene una descripción armonizada de un tipo de edificio genérico.
• VibrationsObserved: para contener la información de vibraciones observadas en un lugar concreto.

Si nos centramos en el ejemplo genérico, el de «BuildingType», vamos a ver que sus especificaciones son, en formato JSON:

{  
  "id": "urn:ngsi-ld:BuildingType:57b912ab-eb47-4cd5-bc9d-73abece1f1b3",  
  "type": "BuildingType",  
  "source": {  
    "type": "Text",  
    "value": "https://source.example.com"  
  },  
  "dataProvider": {  
    "type": "Text",  
    "value": "https://provider.example.com"  
  },  
  "name": {  
    "type": "Text",  
    "value": "House"  
  },  
  "description": {  
    "type": "Text",  
    "value": "Standard building type definition for a domestic house"  
  },  
  "root": {  
    "type": "Boolean",  
    "value": false  
  },  
  "buildingTypeParent": {  
    "type": "Text",  
    "value": "urn:ngsi-ld:BuildingType:4146335f-839f-4ff9-a575-6b4e6232b734"  
  },  
  "buildingTypeChildren": {  
    "type": "StructuredValue",  
    "value": [  
      "urn:ngsi-ld:BuildingType:e4291e84-58f8-11e8-84c3-77e4f1f8c4f1",  
      "urn:ngsi-ld:BuildingType:a71c7a08-58f9-11e8-a41e-4bcb7249360e",  
      "urn:ngsi-ld:BuildingType:afac9bbc-58f9-11e8-b587-1f0d57b81bb4"  
    ]  
  }  
} 

De esta manera, contamos con una plantilla que permite definir lo que es un edificio genérico con toda la información más importante, la cual al estar normalizada permitirá utilizarse en APIs y demás servicios de consulta y consumo. En caso de que tanto el cliente como el proveedor trabajen con esta misma plantilla, el intercambio de información apenas requerirá ningún esfuerzo.

Modelos de datos en Onesait Platform

En la Plataforma, la entidad del modelo de datos la denominamos símplemente como Entidad, aunque inicialmente la llamábamos «Ontología». Estas Entidades van a permitir modelar desde conceptos sencillos como una medida o un registro, a conceptos complejos como una organización. Estas Entidades se definen en el formato JSON + JSON-Schema.

Origen de las Ontologías

El concepto de Ontología -actualmente Entidades, recordamos- prviene del proyecto europeo I+D SOFIA del que se origina la plataforma Sofia2, que usaba como modelos de datos Ontologías RDF/OWL, conforme los principios de la web semántica.

Cuando en el año 2013 Indra considera evolucionar SOFIA para crear una plataforma empresarial (Sofia2), que pueda usarse en proyectos productivos y complejos, se realiza un análisis y pruebas empíricas sobre Sofia2, y se concluye que la tecnología subyacente a las ontologías tradicionales modeladas en OWL no escala conforme a las necesidades de los proyectos IoT y Big Data.

Tras considerar diversas opciones, se consideró que JSON + JSON Schema era la mejor propuesta de presente y futuro.

Un poco de historia: modelo de datos de Sofia2

Para conocer mejor cómo funcionan los modelos de datos en Onesait Platform, es interesante echar un ojo atrás y analizar el modelo de datos que había previamente en la plataforma Sofia2, en donde aunque el concepto clave del modelo de datos era la Ontología, existían a su vez otros conceptos importantes a considerar, como el de «Plantilla» y la de «Instancia de la Ontología».

Veamos en qué consisten:

	Modelo de datos o Plantilla	Ontología	Instancia de Ontología
Representa	Plantilla, bien creada por un Administrador, o bien creada conforme a un estándar concreto (como FIWARE Data Model), que permite que las Ontologías se creen.	Entidad que representa un concepto sobre el que trabaja la Plataforma.	Es un registro concreto de la entidad que define la Ontología.
Ejemplos	Plantilla definiendo los atributos de calidad medioambiental, conforme el FIWARE Data Model.	– Calidad medioambiental (obtenida de un dispositivo). – Previsión meterológica (obtenida por un algoritmo).	– Calidad medioambiental obtenida en una hora concreta en un punto concreto. – Previsión para una región y mes concreto.
Formatos	JSON-Schema	JSON-Schema	JSON
¿Dónde están?	No se almacena, es una definición.	Independiente del motor de persistencia elegido: en un modelo relacional representan una tabla, en una BD NoSQL tipo documental una colección de documentos, etc.	Independiente del motor de persistencia elegido: en un modelo relacional representan un registro, en una BD NoSQL tipo documental un documento concreto, etc.

Modelos de datos en el Control Panel de Onesait Platform 

Nuestro actual modelo de datos es una evolución natural del modelo de Sofia2, en el que conservamos los conceptos como la plantilla o las instancias. En este caso, el concepto de modelo de datos representa una plantilla sobre la que luego podrán crearse las Entidades.

Es por ello que la creación de las plantillas queda restringido a aquellos usuarios que tengan un rol de tipo «Administrador».

Para visualizar los distintos modelos de datos disponibles, desde el Control Panel de la Plataforma navegaremos hasta el menú Administración > Gestión de Plantillas (Data Models):

Se nos mostrará entonces un listado con los modelos de datos existentes, en donde podremos ver su nombre, el propietario, el tipo de plantilla, las etiquetas de categorización y las fechas de creación y edición.

Para analizar una de las plantillas de modelos de datos, únicamente tendremos que pulsar en el botón de «Mostrar» (icono con el ojo) situado en la parte derecha de cada plantilla.

Se mostrará entonces la información general de la plantilla del modelo de datos, así como el esquema JSON:

Entidades y modelos de datos

Las Entidades son el concepto clave del modelo de datos, así como también del funcionamiento completo de la Plataforma, ya que sobre estas se desencadenan el resto de procesos, como por ejemplo:

• Reglas: las cuales se aplican ante la llegada de una instancia de Entidad (o bien planificadas), y permite acceder a los atributos de las Entidades para actuar en base a esta.
• Dashboards: los paneles de mando se construyen, bien representando en tiempo real las instancias que van llegando a la Plataforma, o bien a través de una consulta que se realice sobre estas (DataSources, API REST, etc.).
• Analítica: los modelos de Machine Learning típicamente se realizan sobre las Entidades almacenadas en la infraestructura Big Data de la Plataforma (BDH)

Las Entidades pueden ser creadas por usuarios que tengan roles de «Desarrollador» o «Analista», así como los de tipo «Administrador». A la hora de crear estas Entidades, contamos con diversos mecanismos que nos van a facilitar el trabajo, tal y como explicamos en este artículo del Portal del Desarrollador.

Instancias de Entidad

Como ya se ha indicado, una instancia de Entidad representa un momento y posición concreto dentro de una Entidad.

La Plataforma ofrece diversas herramientas para acceder a las instancias, siendo la herramienta de consultas la más usadas por los desarrolladores, ya que permite a través de un asistente generar consultas rápidamente sobre las Entidades, tanto en SQL como en nativo, obteniendo el resultado de la consulta en formato JSON, el cual podremos descargar en nuestro local tanto en JSON como en formato CSV.

Otra opción que disponemos para ver el contenido de una Entidad es mediante las herramientas de CRUD de Entidades, en donde visualizaremos los registros existentes:

Desde el CRUD de Entidades vamos a poder editar los registros de manera sencilla. Esto no es práctico cuando se tienen miles de registros, pero para una corrección rápida resulta muy útil.

En conclusión

Vista la importancia de los modelos de datos, desde la Plataforma consideramos que el programa Smart Data Model es una grandísima iniciativa que va a permitir que los diferentes socios y clientes puedan trabajar bajo unos mismos formatos de datos, facilitando el intercambio de la información y trabajar de forma paralela para poder explotar la información.

Además, el que sean propuestas abiertas, consensuadas y adoptadas por un gran número de usuarios cuadra con nuestra mentalidad de código abierto, reutilización y adaptación a las necesidades del mercado, por lo que creemos y confiamos que estos modelos de datos tendrán un futuro interesante y seguirán creciendo las opciones disponibles.

---

Imagen de cabecera: Analytics Vidhya
Más información: Smart Data Models

✍🏻 Author(s)