...
...
| Info |
|---|
Desde la versión 3.1.0-KickOff, en el Control Panel se ha pasado a denominar a las Ontologías como «Entidades». Esto no altera ninguna funcionalidad; simplemente se ha cambiado la nomenclatura para un mejor entendimiento del concepto. |
| Table of Contents | |
|---|---|
|
...
|
Introducción
La arquitectura de la
...
Plataforma es una arquitecturaData-Centric(centrada en los datos), los datos son el activo principal y permanente. En este tipo de arquitecturas el modelo de datos precede a la implementación de cualquier aplicación dada y será válido mucho después de que se reemplacen.
Onesait Platform soporta este tipo de arquitectura a través del concepto de Ontología (ahora denominada Entidad), y todas las funcionalidades de la plataforma se basan en este concepto.
Las ontologías son las entidades que gestiona el sistema y que se comparten con otros sistemas.
En el caso más simple, se puede comparar una ontología con una tabla en una base de datos relacional, pero una ontología puede contener un modelo de dominio completo, lo que requeriría en una base de datos relacional un conjunto de tablas relacionadas.
En este enlace: ¿Por qué tiene sentido usar las Ontologías de la plataforma? se detallan los motivos por los que es recomendable implementar el modelo de datos utilizando ontologías.
Definición y estructura
En la plataforma, para la definición de las ontologías se utiliza un esquema en formato JSON-Schema. Este esquema define la estructura de la información que almacenará dicha ontología, permitiendo validaciones semánticas sobre los datos que se reciban.
Un ejemplo de esquema de definición de una Ontología sería similar a:
| Code Block | ||
|---|---|---|
| ||
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "SensorTemp",
"type": "object",
"required": [
"SensorTemp"
],
"properties": {
"SensorTemp": {
"type": "string",
"$ref": "#/datos"
}
},
"datos": {
"description": "Properties for DataModel SensorTemp",
"type": "object",
"required": [
"measure",
"units",
"timestamp",
"geoposition"
],
"properties": {
"measure": {
"type": "number"
},
"units": {
"type": "string"
},
"timestamp": {
"type": "string",
"format": "date-time"
},
"geoposition": {
"type": "object",
"required": [
"coordinates",
"type"
],
"properties": {
"coordinates": {
"type": "array",
"items": [
{
"type": "number",
"maximum": 180,
"minimum": -180
},
{
"type": "number",
"maximum": 90,
"minimum": -90
}
],
"minItems": 2,
"maxItems": 2
},
"type": {
"type": "string",
"enum": [
"Point"
]
}
},
"additionalProperties": false
}
}
},
"description": "Temperature ontology",
"additionalProperties": true
} |
La información que se envíe a la plataforma utilizando la ontología deberá cumplir ese esquema de definición.
La unidad de información en la plataforma se denomina instancia. Una instancia de una ontología sería el equivalente a un registro en una tabla de bbdd.
Para el ejemplo anterior, una instancia válida de ontología sería:
| Code Block | ||
|---|---|---|
| ||
{"SensorTemp":{ "measure":28.6,"units":"C","timestamp":"2014-01-30T17:14:00Z","geoposition":{"coordinates":[4 ,28.6],"type":"Point"}}} |
Cualquier instancia que no cumpla semánticamente con el esquema de definición de la ontología destino será rechazada por la plataforma, garantizando así la corrección de la información.
Siempre que una instancia se inserta en plataforma, se le añade una información de auditoría adicional:
| Code Block | ||
|---|---|---|
| ||
"contextData": {
"deviceTemplate": "clientSensor",
"device": "sensorTemperatura01",
"clientConnection": "53643241-1497-17ea-436e-ba74618f7322 ",
"clientSession": "64376481-4139-48cb-ad6e-dc7bdd8f73ca",
"user": "user_developer",
"timezoneId": "GMT",
"timestamp": "Thu May 31 14:51:31 GMT 2018",
"timestampMillis": 1527778291886
} |
, con información como el origen o dispositivo que ha enviado la información, la sesión que se ha utilizado, la zona horaria y el instante en el que se recibió,etc.
Además de la estructura de la ontología, pueden definirse otra serie de características que definirán su comportamiento:
...
Nombre: Identificador de la ontología que permitirá referirse a ella, realizar consultas, inserciones, etc. Los elementos que se inserten en la ontología deberán tener este identificador como elemento raíz (como se ha visto en el ejemplo anterior).
Metainformación: Información adicional en forma de tags que permiten categorizar la ontología para filtrado, etc…
Descripción: Permitirá detalla cualquier aspecto acerca de la ontología que su propietario considere oportuno.
Activa: Indica si una ontología se encuentra activa en la plataforma. De no ser así, no estará disponible para uso.
Publica: Una ontología pública es una ontología a la que tienen acceso todos los usuarios. Si una ontología no es pública, se debe dar acceso de forma explícita a cada usuario para que pueda utilizarla. Además hay que detallar el nivel de acceso para cada usuario:
Query: Se permite consultar la información almacenada en la ontología.
Insert: Se permite insertar información en la ontología.
All: Permite un control total sobre la ontología.
Encriptación de campos: Para añadir un nivel de seguridad, se permite la encriptación de los atributos de las instancias de la ontología.
Como opciones avanzadas, se incluye:
...
Creación de tópico de Kafka: Para ontologías destinadas a recibir ingestas masivas de datos.
Borrado automático de BBDD: Se puede definir un borrado automático de la información almacenada en BBDD y el periodo de tiempo que se quiere mantener en BBDD
Historificación de los datos: En lugar de borrar los datos, se migran o bien a un sistema de ficheros o bien a una base de datos histórica.
Para facilitar la creación de ontologías la plataforma ofrece distintos métodos para registrarlas.
Creación Paso a paso: A través de un asistente se puede generar el JSON-Schema de la Ontología con tan solo añadir los atributos que se deseen incluir. Además se facilitan una serie de plantillas base de las que partir para la construcción de la ontología.
...
Para más información: /wiki/spaces/PT/pages/51478530
Creación desde fichero: A partir de un fichero con información a almacenar, se extrapola el esquema JSON de la ontología que modelará dicha información. Se ofrece la posibilidad adicional de realizar la carga de los registros que se incluyan en el fichero.
...
Creación a partir de una base de datos externa: Partiendo de los datos de conectividad de una bbdd externa, se permite seleccionar un o más tablas para generar su representación como ontología (JSON-Schema). La plataforma actuará como conector con la BBDD externa cuando se realicen operaciones sobre la ontología.
...
Para más información: (Ontologies) (ES) Crear una ontología desde una base de datos relacional y representarla en un dashboard
Creación a través de un API Rest: Disponibiliza un API Rest como ontología. Para ello habrá que definir el mapeo de los métodos de API Rest con las operaciones propias que se pueden realizar sobre una ontología.
...
Para más información: (Ontologies) (ES) Crear una ontología desde una API REST y ejemplos de uso con FlowEngine y Dashboards
Creación de una ontología KPI: Permite definir una ontología cuyos valores son KPIs generados a partir de información almacenada en la plataforma.
...
Para más información: (Ontologies) (ES) Cómo crear un KPI para medir el resultado de mi negocio
Creación de Timeseries: Una ontología de tipo TimeSeries se caracteriza por que su esquema describe la estructura de las instancias que recibe el IoTBroker, pero no la estructura de las instancias almacenadas en el motor de Base de datos, esto es, y como veremos mas adelante, la plataforma hace una gestión interna de los datos recibidos, para construir una agrupación mas eficiente de las distintas señales.
...
Para más información: Soporte para modelado TimeSeries en Ontologías
Una vez se ha definido la ontología en plataforma, se ha definido el modelo de datos, se puede proceder a implementar funcionalidades sobre la misma.