Creando Ontologías desde Time Series

Con este título tan llamativo, hoy vamos a hablar de un tipo de ontologías -podríamos decir- diseñadas para gestionar datos en ventanas temporales.

O explicado de otro modo, la utilidad de estas ontologías es almacenar en un único registro de la base de datos los valores correspondientes a una unidad temporal definida.

Por ejemplo, supongamos que nuestra ontología recibe datos cada minuto, y lo quiero agrupar por horas. Entonces, cada registro de la ontología contendrá sesenta subregistros, cada uno correspondiente a cada minuto de la hora.

La ventaja de esto es que si queremos recuperar los datos de una hora en concreto, no tenemos que filtrar toda la ontología y recuperar los sesenta registros de la hora en cuestión, sino que únicamente tenemos que recuperar el registro de esa hora en particular, y tendremos todos los valores correspondientes.

Esto es ideal, como decimos, cuando estamos recogiendo datos periódicos y luego queremos recuperarlos de manera agrupada para hacer algo con ellos (como representarlos, generar estadísticas, etc.).

Un ejemplo práctico sería lo hablado previamente aquí en el blog con la serie de IoT de estar por casa (parte 1, parte 2 y parte 3), en donde con un par de sensores se iba recogiendo y enviando a la Plataforma cada minuto la medida de temperatura y humedad.

En su momento generamos una ontología genérica para almacenar sus datos, cuya estructura de datos es la que vemos a continuación:

Sin embargo, con esta Time Series, la estructura es esta otra:

¿Queréis saber cómo generar una Ontología de Time Series? ¡Pues volando al CloudLab!

Cómo crear una Time Series

Para crearla haremos como con una Ontología normal; iremos hasta el menú de Desarrollo > Mis Ontologías, y entre las diferentes opciones que aparecen seleccionaremos la que está más abajo, la de «Time Series».

Seguidamente rellenaremos los datos que nos solicitan:

• Nombre: el nombre que tendrá la ontología. En mi caso estoy usando «arduinoDHT22_timeseries» porque hace referencia a las ontologías que usé en el tutorial de IoT. Recordad que si estáis haciendo el tutorial, no podéis repetir el nombre de la ontología, por lo que os recomendaría incluir alguna variación, como las iniciales de vuestro nombre al final.
• Meta-Información: aquí añadiremos las etiquetas descriptivas de la ontología.
• Activa: esta casilla tendrá que estar marcada, para indicar que se está usando la ontología en cuestión.
• Pública: esta opción es… opcional. Marcadla si queréis que cualquiera pueda ver vuestra ontología.
• Descripción: pequeño texto en el que explicáis para qué sirve la ontología.
• Motor de Timeseries: aquí sólo se puede elegir -de momento- MongoDB, así que ya sabéis.

A continuación tenemos que indicar dos tipos de propiedades, y es bastante importante diferenciarlas bien:

• Etiquetas: se refiere a aquellas propiedades de la ontología que serán siempre constantes. Por ejemplo, si tengo una propiedad que identifica un dispositivo, o su localización, este valor va a ser constante; ahora y dentro de dos horas, el dispositivo es el mismo.
• Campos: aquí se refiere en cambio a las propiedades que varían; a los valores de medición. Ahora hace 26ºC, pero en dos horas puede hacer 28ºC (o cualquier otro valor).

Por tanto, dependiendo de lo que queramos meter en nuestra ontología, tendremos que diferenciar entre etiquetas (valores estáticos) y campos (valores dinámicos). En mi caso he definido los siguientes:

• Etiquetas:
  • deviceID: propiedad con el identificador único de mi sensor (en el ejemplo original usaba dos sensores IoT, pero para este ejemplo he dejado sólo uno de ellos).
  • location: propiedad con la localización del sensor en mi casa. Como estoy usando el segundo sensor, corresponderá con el despacho.
• Campos:
  • temperature: propiedad que almacenará el valor de temperatura medido.
  • humidity: como lo anterior, pero cambiando temperatura por humedad.

Bien, pues ya tenemos la información de la ontología introducida, y los campos a tener en cuenta. Por último nos queda elegir las ventanas temporales; es decir, indicar cada cuanto queremos agrupar los datos.

Igual que antes, tenemos dos parámetros importantes a definir, que son:

• Tipo de ventana: aquí indicamos la agrupación temporal que nos interesa. Podemos elegir entre minutos, horas, días o meses.
• Frecuencia de la ventana: aquí se indica cada cuanto tiempo se ingestará un dato en la ontología. Como requisito, la unidad temporal tendrá que ser siempre un paso por debajo del tipo de ventana; es decir, si se selecciona una ventana de horas, se podrá elegir como frecuencia minutos o segundos. Las opciones son: segundos, minutos, horas, días y meses (este último no funcionará por lo que os he contado).

¿Y cómo he creado yo mi ontología? Pues recapitulando un poco, recibía datos cada minuto, así que mi frecuencia de ventana será cada minuto. Como me interesaba conocer la evolución de temperatura y humedad en la última hora, pues una de mis ventanas será la horaria. Y como ya estaba con ello, generé otra ventana diaria, para sacar información para los días de la semana.

Así como detalle, indicar que las políticas de borrado no se encuentran aun disponibles, por lo que no funcionará si lo intentáis activar. Para el limpiado de la ontología tendréis que recurrir a generaros un Flow Engine o Data Flow que pase la escoba.

A continuación le damos a crear la ontología y listo, ya lo tendríamos. Para comprender cómo funciona todo esto, podemos meter algunos valores invent_® mediante el CRUD de la ontología, a ver cómo se organizan.

Para eso, vamos hasta el listado de ontologías y buscamos la nuestra. Entonces, pulsamos en el botón de «CRUD».

Si usais los mismos campos que yo, tendréis una estructura de ontología como esta:

{
  "TimeSerie": {
    "timestamp": {
      "$date": ""
    },
    "deviceId": "",
    "location": "",
    "temperature": 0,
    "humidity": 0
  }
}

Un aspecto importante que no pasa con las ontologías normales, es que el campo de «timestamp» no se crea automáticamente, sino que es necesario introducirlo si o si para poder crear el nuevo registro (en las ontologías normales dicho campo se crea automáticamente en la propiedad de contextData).

Un par de ejemplos de registro a introducir en la ontología serían:

{
  "TimeSerie": {
    "timestamp": {
      "$date": "2020-09-30T07:00:00Z"
    },
    "deviceId": "test",
    "location": "universe",
    "temperature": 23.4,
    "humidity": 56.1
  }
}

{
  "TimeSerie": {
    "timestamp": {
      "$date": "2020-09-30T14:00:00Z"
    },
    "deviceId": "test",
    "location": "universe",
    "temperature": 27.3,
    "humidity": 66.6
  }
}

Tras introducir estos dos registros, si nos vamos hasta nuestra querida Herramienta de Consultas y hacemos una consulta de la ontología de Time Series que hemos creado, deberemos recibir ocho registros en total.

¿Eh? ¿Cómo que ocho (8)? Pero si sólo he metido dos registros… Bueno, todo tiene su explicación.

Cada registro tiene dos campos definidos, uno de temperatura y otro de humedad. Eso genera que para la ventana de horas, tenemos dos registros de temperatura, y dos registros de humedad. Ya van cuatro. Y no nos olvidemos de la ventana de días… que suman otros cuatro. Bien, ahí tenemos nuestros ocho registros.

Como son bastantes datos agrupados en agrupaciones agrupadas, lo mejor es que entréis en CloudLab y busquéis la ontología «arduinoDHT22_timeseries». Echadle un ojo con la Herramienta de Consultas y así podéis ir indagando en los registros.

Vale, tengo muchos datos. ¿Y cómo los saco de ahí para agruparlos o lo que sea? Pues para esto tenemos a nuestros amigos los Datasources, funcionando de manera similar a como lo haríamos en una Ontología normal. Si os interesa, en la tercera parte de la serie de IoT de estar por casa nos centramos en ellos, así como en esta entrada del Workshop de formación que publicamos hace no mucho.

¿Qué os parece? ¿Creéis que podéis sacarle partido a este tipo de Ontologías?

✍🏻 Author(s)