What are ontologies?
The webpage “Summum of Interoperability” describes that KNX with its KNX IoT 3rd Party API has set as goal not only to define a manufacturer independent RESTful web service interface to KNX installations, but it also wants to add semantic meaning to data exchanged via this API.
As human beings, we are trained to understand concepts and also understand relations between concepts. For instance, we know that when a mother has a child and the child is a boy, this is her son.
A machine cannot interpret this without us human beings programming it to understand these concepts and the relations between them. For this, ontologies are used, for software to better understand this without additional help of a human (to “reason” on this basis).
Separate Concepts in ontologies are called classes and relationships between classes are called properties. There is not necessarily a hierarchy between classes. However, classes can have subclasses, in this case there is a hierarchical structure amongst them.
To describe the KNX system and in the framework of the KNX IoT development, KNX also designed its own ontology, which can help software understand the principal concepts in a KNX installation and the relations between them. The practical realization of this ontology is an ETS project, it is an “instantiation” of the blueprint as documented in the ontology.
Points and Tags
KNX experts know that communication in a KNX system is done via KNX group objects. In the KNX ontology this is called a “Point”.
This concept “Point” has a relation in the ontology to the concept “Tag”, which allows to add additional information on the “Point”.
Instead of just having a flat and unsorted list of such tags, KNX has opted to further distinguish certain tag categories (different subclasses), so to give further semantic meaning to different types of tags. This will then also bring additional benefit if wanting to find products that offer certain Points with certain features e.g. in the context of new planning tools or in the context of Building Information Modelling (BIM).
The actual tags are then documented as “individuals” in the ontology, i.e. possible tag types of a certain tag subclass. These individuals are entries in a KNX specific dictionary.
For some of the dictionary entries, KNX was inspired by the tagging initiative Haystack, for others KNX simply refers to existing other ontologies like qudt, for still others KNX has designed own tags.
For certain collections of tags from different subclasses as used by a Point or another concept, KNX has also designed another class called “Quality Kind”, thus avoiding that one needs to reference the tags individually.
The above should make clear that the ontology consists of a static part generally describing the KNX system and a dynamic part, i.e. the KNX dictionary that may evolve over time.
Exporting from ETS
Based on the ontology it will be possible in the ETS to export the data of a KNX installation as JSON linked data, which will always also be accompanied by a copy of the ontology valid at the time of the export, to even be able to interpret data that are not instantiated in the exported project. Linked data allows to search for relations between data.
Based on a piece of developed software and the linked data, a KNX IoT Server or a Client then needs to create the necessary software objects that can then be accessed via the different KNX IoT 3rd Party API endpoints. Run time values sent to or received through the bus need to be stored in these objects, then also offering the semantic data exported for use by the API.
Adding Semantics to KNX product data
An additional work group in KNX is currently streamlining the workflow to ensure that sufficient extra semantic data is made available in or in addition to the current KNX product database entries via the KNX Online Catalogue. This extra semantic information padded as tags to the KNX group objects is depicted in yellow in the below picture and will make use of the common semantic dictionary data that will host data of both KNX Association as well as KNX members.
It will cover both templates for the product catalog as well as installation/project data (e.g. ETS functions). Work of the group currently concentrates on creating more content in the semantic dictionary based on the current KNX standardized functional blocks.
It is foreseen that it will be possible to add this data to product databases in a new KNX Manufacturer tool version. A future ETS6 will then retrieve this extra data to be able to create an IoT export file with sufficient semantic data.
