The HVAC ontology - an inquiry from a visitor of universaal.info

[saiedt]

universaal.info wrote on 28.10.2018 23:52:

The following details were submitted from your website, universaal.info.

From: Richard Contact Email: ... Phone: ...

Message: Hello, I found Your project at https://github.com/universAAL during looking for some ontologies related with HVAC. You developed some ont.hvac ontology at Your project but i see it as wery simple with many entities missing. Do You consider it useful? Is the state like it is for Your project usefull or it may be possibl work with it? best Richard

[saiedt]

Dear Richard,

if I understand well, you are offering to help to improve the HVAC ontology. This is certainly more than welcome!

Nevertheless, let me forward your email to the developers mailing list. I hope that someone there knows more about the existing HVAC ontology and can provide some more specific comment.

Dear developers mailing list, I created https://github.com/universAAL/ontology/issues/481 in order for the discussions to be logged and reusable.

From my perspective, what I can tell you generally about the set of ontologies in the universAAL repositories is the following:

• Although ontologies play a central role in universAAL based systems, they however belong to the set of pluggable modules. The core middleware is totally independent from concrete ontologies and just uses the injected ontologies for matchmaking between offers and inquiries in order to achieve interoperability between modules to the extent of compatibility between the ontologies used by these modules (cf. the communication between humans that also understand each other to the extend of shared understandings :-) )
• There is a set of core ontologies that are used by some of the "manager" components of universAAL and/or reused in the definition of many other ontologies (e.g. the physical world, the device, the measurement and the unit ontologies). In these cases, the ontologies have been developed in a more targeted team work. But even here, there have been different views and the team had to proceed with only one of them. We live with that because ontologies are a matter of taste and anyhow pluggable, replace-able and extendible.
• The above fact has led to the development of more concrete ontologies to the extent of needs in the concrete application scenarios that the corresponding developers had. In any case, our recommendation is to maximize reuse but when developing new ontologies for universAAL based systems, one should try to stay focused to own needs and create them in a very modular way by importing overlapping ontologies and referring to as many existing concepts (mostly classes and properties) as possible in order to achieve a higher level of interoperability.
• In any case, big ontologies can get very complex, very fast; and, we should bear in mind: there is no perfect ontology...
• Nevertheless, it is clear that when converting (parts of the) results of previous work outside universAAL (such as the HVAC part of the IFC data model) to ontologies usable in universAAL, then we should be very loyal to the original results. I don't know to what extent such existing work has been considered by the developers of the HVAC ontology, but we will be very happy if alternative ontologies are contributed to our repositories :-)

Kind regards,

-- Saied

[amedranogil]

My ream is responsible for the development of the HVAC ontology since we had the need to control HVAC system in our living lab. The methodology of ontology design, in this case specific for universAAL, is to keep ontologies as generic as posible but simple too. The main model is there are 3 components Heating, Ventilation, and Air Conditiong (HVAC), Heating is defined as any system capable of increasing the temperature of a location (e.g: Radiator); Ventilation is any system which makes the air flow to,from or in a location(e.g: a fan); and Air Conditions is a system capable of lowering the temperature of a location (e.g evaporative cooler); additionally there are systems which not only are turned on, or off, but they are programable to keep a target temperature, for these kind of system there is the target temperature class. These are very simple, but abstract concepts, one may define different sub classes for each type of system, for example the given examples above; the problem with this is that from a programmatic perspective they do not add any new properties, and because you may construct instances as sub class of one or more of these abstract classes, there is no need to be more explicit. The ontology also covers the main objective of "standarising" most of the HVAC systems out there (which is a feat on its own, as the industry has very limited vocabulary: winter, summer, heating, cooling modes, using either a sun or a snowflake to represent them, yet each vendor has different meaning to each symbol). Nevertheless this ontology can be extended, and the sub classes added, we can also think of humidification and dehumidification as 2 more main abstract classes missing. universAAL is an open project and we very gladly accept any contribution.