Why does it make sense to use Platform Entities?

Owned by DevPortal Editor (Unlicensed)
13/09/21
8 min read

From version 3.1.0 in the Control Panel, Ontologies have been renamed as Entities. This does not alter any functionality, simply the nomenclature has been changed for a better understanding of the concept.

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:

  • 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/ 

You can read more about the concept of Data Model and its support on the platform here.

  • 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:

-From a relational database: this is very useful if you want to use the platform but you already have your own data model created or your team is used to this type of DB. (Read Creating an ontology from a relational database and showing it in a dashboard).

-On Elasticsearch: for scenarios prioritizing free-text searches or Time Series representations.

-On Kudu: an operational, columnar database running on Hadoop (something like an HBase + HIVE).

-Even on external APIS REST for scenarios where I cannot connect to the Database of the system to be integrated but I am interested in that representation as an ontology.

  • 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:

In addition, the platform allows aggregations (JOINS, GROUPS) for any of the supported DBs of the platform.

In specific cases, using the underlying database's native language may be necessary or convenient. The platform also allows this, although you must be aware of what this decision implies.

  • 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).

Those of you who have worked with Mongo know that, by default (although in recent versions it allows you to define one scheme per collection), in a Mongo collection you can insert data that is not coherent and transferring the coherence problem to system execution.

  • 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:

or the opposite case, where one of these rules/flows ends up inserting in an ontology:

  • 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