¿Por qué tiene sentido usar las Ontologías de la plataforma?

Como explicábamos en este artículo la plataforma usa una Arquitectura Data-Centric y la Ontología representa ese modelo de datos que puede compartirse entre aplicaciones y sistemas. 

En muchas ocasiones, los desarrolladores (sobre todo los desarrolladores Java+Spring) que trabajan con la plataforma nos preguntan que si la plataforma por debajo usa MongoDB por qué no pueden usar Spring Data para trabajar con MongoDB en lugar de tener que manejar la abstracción de la ontología  (recordad que MongoDB es simplemente la Base de Datos de la implementación de referencia -RI- pero que soportamos otras bases de datos, relacionales, columnares, de índices, ....).

Lo cierto es que les entiendo, al fin y al cabo me sigo sintiendo un programador Java+Spring, y lo que más me gustaba era definir la arquitectura de mi sistema, que si esta librería para trabajar con JSON, que si esta otra para publicar los servicios, luego llegaba el siguiente proyecto, había aprendido algo más y además como ya conocía esas tecnologías pues metía algunas nuevas (muchas de ellas no aportaban mucho pero me lo pasaba bien :))....pasaron los años y participé en muchos proyectos...así que tuve la oportunidad de trabajar e implantar con muchas tecnologías.

Por eso, entiendo cuando un Arquitecto Java empieza a comenzar a trabajar con la plataforma y echa de menos las tecnologías que conoce o las que querría poner en práctica...entonces intento explicarle que la plataforma tiene como objetivo construir sistemas más mantenibles, extensibles y de forma más sencilla (no hay que ser un experto en n-mil tecnologías por ejemplo) y centrarse en el negocio, pero eso no suele bastar...entonces lo que le propongo es que nos ayude a mejorar la plataforma, que se descargue la versión Open-Source y le añada las capacidades que echa en falta, que con esto ayudará a que los que vengan detrás de él...

Si te encuentras en esta situación, por favor lee estos puntos, espero que te hagan cambiar de opinión:

  • Quizás el concepto de Ontología asuste un poco. Usamos este nombre porque la plataforma se nutrió de experiencias previas que incluían Web Semántica (RDF,...) pero si este nombre te gusta puede pensar que una Ontología no es más que la definición de una Entidad en el caso más sencilla o de un Modelo de Dominio en el caso más complejo, y que finalmente se representa como un JSON-Schema:

  • Además, la plataforma ofrece un conjunto de Plantillas (o Data Models) que permiten que las ontologías se creen siguiendo las mejores recomendaciones y estándares en este sentido. ¿No os ha pasado que para definir el concepto Cuenta o KPI o Usuario lo habéis hecho de forma diferente en cada aplicación? Usando uno de estos Data Models tendré ya predefinidos un buen número de plantillas sobre las que crear mis ontologías. Además los administradores pueden crear nuevos Data Models para los conceptos de la organización aún no estandarizados.Un buen ejemplo de intento de estandarización en el ambito Smart Cities es el FIWARE Data Model (soportado por la plataforma): https://www.fiware.org/developers/data-models/ 

Podéis leer algo más sobre el concepto de Data Model y su soporte en la plataforma aquí.

  • Independencia del almacenamiento: como decíamos antes, la plataforma usa Mongo por defecto para almacenar las ontologías pero en función del caso de uso permite almacenar las ontologías sobre otros repositorios. La plataforma gestionará la creación sobre la BD (índices, particiones,...), por ejemplo

-Desde una base de datos relacional: esto es muy útil si quiero utilizar la plataforma pero ya tengo mi modelo de datos creado o mi equipo está acostumbrado a este tipo de BD. (Leer (Ontologies) (ES) Crear una ontología desde una base de datos relacional y representarla en un dashboard).

-Sobre Elasticsearch: para escenarios donde prima búsquedas de texto libre o representaciones Time Series.

-Sobre Kudu: una Base de Datos operacional y columnar que corre sobre Hadoop (algo así como un HBase+HIVE) .

-Incluso sobre APIS REST externas para escenarios donde no puedo conectarme a la Base de Datos del sistema a integrar pero me interesa esa representación como ontología.

  • Motor de consultas SQL: sea cual sea la base de datos subyacente a la ontología, la plataforma me permite consultar las ontologías en SQL. Esto unido a la independencia de la base de datos permite que, llegado el caso, migrar de la tecnología de base de datos elegida si cambia el escenario. Será sencillo:

Además la plataforma permite hacer agregaciones (JOINS, GROUPS) para cualquiera de las BDs soportadas en la plataforma.

En casos concretos, puede ser necesario o conveniente usar el lenguaje nativo de la BD subyacente, la plataforma también lo permite, aunque debemos ser conscientes de lo que implica esta decisión.

  • Seguridad asociada a la ontología: trabajar con ontologías tiene otras ventajas, por ejemplo que la plataforma gestiona de forma automática la seguridad. Por defecto el usuario que crea la ontología es el único que puede acceder a ella y podrá darle permisos a los usuarios que considere, permisos de lectura, escritura o de gestión completa. Además si uso el concepto de proyecto podré crear entidades compartidas para los usuarios que conforman el proyecto (Projects within the platform: resources and user management

  • Validación sintáctica: como hemos dicho, la ontología se representa como un JSON-Schema, y las instancias de una ontología (en un modelo relacional los registros) son un JSON. Sea cual sea el repositorio donde acaba la ontología el interfaz de esta es un JSON (podemos verlo haciendo una query). Pues bien, la plataforma de forma automática valida que la información que se envía a la plataforma cumple con el JSON-Schema definido. En un JSON-Schema podré definir validaciones sencillas (obligatorio), numéricas (>10) y validaciones semánticas complejas (posición está en España).

Los que hayáis trabajado con Mongo sabéis que por defecto (aunque en las versiones recientes permite definir un esquema por colección) en una colección Mongo puedo estar metiendo datos que no sean coherentes y trasladar el problema de la coherencia a la ejecución del sistema.

  • Reglas y flujos visuales asociados a las ontologías: la plataforma ofrece diversos motores que pueden ejecutarse a la llegada de una instancia de una ontología. Es muy típico tener una ontología de control que desencadena una acción en otro sistema (invocación a un Servicio REST) o simplemente envía un mail. La plataforma permite definir esto sin programar nada:

o el caso contrario, que una de estas reglas/flujos acabe insertando en una ontología:

table(2).png

  • Historificación automática: la plataforma permite definir para cada ontología (independiente de su almacenamiento) si quiero hacer algo con los datos almacenados pasado X tiempo, permitiendo borrar directamente estos datos o historificarlos (esto es almacenarlo como un fichero CSV en el repositorio de ficheros de la plataforma, o pasarlo a la Base Datos Histórica de la plataforma).

  • Capacidades IA sobre las ontologías: la plataforma integra un Notebook Hub, que permite crear algoritmos en lenguajes como Python, R, Spark, Tensorflow, Keras,... puedo crear algoritmos de la forma tradicional: haciendo la ingesta y transformación a un fichero, o me puedo basar en la información almacenada en la plataforma como ontologías y volcar el resultado de mi modelo en una ontología. Esto garantiza la seguridad de mi modelo ya que la ontología sólo podrá ser explotada por mi o a quien haya dado permiso. Usando el intérprete de la plataforma en los Notebooks


Pero, aún nos quedan muchas cosas que mejorar y añadir a la plataforma, así que ¿por qué no piensas en cómo podrías mejorar la plataforma para que se adecúe más a tus necesidades? Estaríamos encantados de recibir tus aportaciones, tenemos un modelo y un gobierno para ello. ¿Te animas? Sigue este artículo: (ES) Cómo resolver un bug en el Control Panel y subirlo a Github vía Pull Request