Why does it make sense to use Platform Entities?

As we explained in this article, the Platform uses a Data-Centric Architecture and the Ontology represents this data model that can be shared between applications and systems.

Frequently, developers (particularly Java+Spring developers) working with the platform ask us, considering that the platform uses MongoDB below, why can't they use Spring Data to work with MongoDB instead of having to handle the abstraction of the ontology (remember that MongoDB is simply the reference implementation -RI-'s Database, but we also support other databases, including relational, columnar, indexes, ...).

Truly, I understand them. After all I still regard myself as a Java+Spring programmer, and what I liked most was to define my system's architecture: if this library to work with JSON, this otrher one to publish the services, then, when the next project came, I had learned something new and besides, as I knew those technologies, I could include some new (many of them did not contribute much but I had a good time:))... The years passed and I participated in many projects... so I had the opportunity to work with and implement many technologies.

That's why I understand when a Java Architect begins to work with the platform and misses the technologies that she knows or would like to implement... so I try to explain her that the platform aims to build more maintainable, extensible systems in a simpler way (you don't have to be an expert in a bazillion technologies for example) and focus on the business, but that's usually not enough... then what I suggest is that she helps us improve the platform, download its Open-Source version and add the missing capabilities, which will help those who come behind...

If you find yourself in this situation, please read these points. I hope you will change your mind:

• The Ontology concept may scare a little. We use this name because the platform was based on previous experiences that included Semantic Web (RDF, ...) but if you like this name, you may think that an Ontology is but the definition of an Entity in the simplest case or of a Domain Model in the most complex case, and that is finally represented as a JSON-Schema:

Open

• Besides, the platform offers a set of Templates (or Data Models) that allow ontologies to be created following the best recommendations and standards in this regard. Hasn't it happened to you that, when defining the concept Account or KPI or User, you have to do it differently in each application? Using one of these Data Models, you will have a good number of predefined templates on which to create your ontologies. Besides, administrators can create new Data Models for not-yet-standardized organizational concepts. A good example of an attempt to standardize in the Smart Cities field is the FIWARE Data Model (supported by the platform): https://www.fiware.org/developers/data-models/ 

Open

• Storage independence: as said before, the platform uses Mongo by default to store the ontologies but, depending on the use case, it allows to store the ontologies on other repositories. The platform will manage the creation on the DB (indexes, partitions, ...), for instance:

• SQL query engine: whichever be the underlying database of the ontology, the platform allows you to query the ontologies in SQL. This, coupled with the independence of the database, allows, where appropriate, to migrate from the chosen database technology should the scenario change. It will be simple:

• Security associated with the ontology: working with ontologies has other advantages. For example, the platform automatically manages security. By default, the user who creates the ontology is the only one who can access it, and she can give read, write or complete management permissions to the users that she considers. Besides, if you use the project concept, you can create shared entities for the users that make up the project (Projects within the platform: resources and user management) 

• Syntactic validation: as said, the ontology is represented as a JSON-Schema, and an ontology instances (in a relational model, that's the records) are JSON's. Whichever the repository where the ontology is stored, its interface is a JSON (you can see it by doing a query). Well, the platform automatically validates that the information sent to the platform complies with the defined JSON-Schema. In a JSON-Schema, you can define simple (mandatory), numerical (> 10) and complex semantic validations (position is in Spain).

• Rules and visual flows associated with ontologies: the platform offers several engines that can be executed upon arrival of an ontology instance. It is very common to have a control ontology that triggers an action in another system (invocation to a REST Service) or simply sends an e-mail. The platform allows you to define this without any programming:

• Transparent protocol management: the platform allows you to manage the ontologies in different protocols, including REST, MQTT, Kafka, WebSockets, ... and the client can choose the protocol according to the use case.

• Multilanguage APIS: in addition to the independence of the protocols, the platform offers APIs in several languages, so it is very easy to build a system in which:

  • a device sends Node-RED data to the platform ((Client APIs) A Node-RED client library to interact with onesait Platform),

  • then you visualize this data in real time through the WebSockets connector for JavaScript ((Client APIs) Developing a Client Application in Javascript),

  • you have a business logic in Java ((Client APIs) Using the Java Client API to connect and send Data to the Digital Broker)

  • or you even use a Wrapper for Spring Boot that allows me to manage ontologies through a Repository  ((Client APIS) What is the Spring client library, aka Client4SpringBoot, and how to use it?).

• Apify ontologies making them available as Swagger REST APIs without programming a single line (API Invocation with Swagger and Client Generation with Swagger Editor).

• Create complete dashboards, visually, that represent ontologies, filtering, drill-down, ... (How to create a dashboard step by step?).

• Automatic historification: the platform allows you to define, for each ontology (independently of its storage), if you want to do something with the stored data after a given time, allowing you to directly delete this data or to historize it (this is to say, store it as a CSV file in the platform's file repository, or pass it to the platform's Historical Database).

• AI capabilities on ontologies: the platform integrates a Notebook Hub, which allows you to create algorithms in languages ​​such as Python, R, Spark, Tensorflow, Keras, ... You can create algorithms traditionally, by ingesting and transforming to a file, or you can rely on the information stored on the platform as ontologies, then dump your model's result into an ontology. This guarantees your model's security, since the ontology can only be exploited by you or by users you have authorized. Using the platform interpreter in the Notebooks

But there's so many things we can improve and add to the platform. So, why don't you think about how you could improve the platform to suit your needs more accurately? We would be delighted to receive your contributions. We have a model and a government for that. Do you dare? Follow this article: Solving a bug in Control Panel and uploading it to Github

Pero, aún nos quedan muchas cosas que mejorar y añadir a la plataforma, por eso 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