What is an ontology and how it can be used in buildings? Part 1
In my latest article, I mentioned the necessity of bridging the gaps between design and operation in buildings. This enables design and deployment of autonomous buildings at scale. But exactly how does this work?
The key driver is a detailed ontology, that provides a well-defined framework and understanding of both physical and digital world. But what is an ontology?
Introduction to Ontologies
Ontology is the philosophical study of being. (scary, I know, right?).
Humans are great at abstracting, while machine may require some help in doing so. In information science, an ontology is a structured framework that defines and organizes the properties, relationships, and categories of concepts or entities within a specific domain.
In simple terms, an ontology is an abstraction that allows to represent objects, and the relationship between them.
An ontology serves as a structured framework to represent knowledge about the domain. It defines the relationships and categories among various entities and it has several benefits:
Data Interoperability: It facilitates understanding and integration of diverse data sources.
Semantic Context: Provides meaning to raw data, aiding in more intelligent decision-making and automation.
Flexibility and Scalability: Graphs are inherently flexible to accommodate changes and expansions.
The Semantic Web framework was defined to describe these kind of relationship in a machine readable way, promoting common data formats. It was originally advocated for annotating the web documents, and since then multiple domains (including the building one) have adopted it.
Among its relevant standards Resource Description Framework (RDF) represents the information as controlled vocabularies in a directed graph where each triple of a head node, an edge, and a tail node expresses subject-predicate-object relationship.
Ontologies in Buildings
In buildings, ontologies play a critical role in organising and making sense of the complex systems and interactions within a building. A building ontology is a formal representation that includes the various components of a building – like rooms, floors, HVAC systems, lighting – and the relationships between them. It allows different systems – heating, cooling, lighting, security – to communicate between each other and with management systems, enabling a more efficient and responsive building environment. This interconnectedness is key to modern building management, where understanding and optimizing the use of space, energy, and resources is critical.
Unlike general data ontologies that might focus on broader categories, building ontologies are specifically designed to handle the nuances of building operations and management, and consist of several key components.
Spatial Elements: These include rooms, floors, and zones within a building. These elements are crucial for defining the physical structure and organization of the space.
Systems: HVAC, lighting, security, and other building systems. These components focus on the operational aspects of a building, ensuring that the right amount of energy/mass is used to meet all the objectives including comfort, safety, and efficiency.
Information Points: These includes sensors (data points) and actuators (control points), which allow for the extraction and injection of information into the system for control and analysis.
Using a nomenclature inspired by Brick, we will draw the following diagrams to showcase the different relationships between these 3 main group of classes.
History and evolution of ontologies in buildings
Initially, the building industry relied on tags – basic labels or keywords assigned to elements within building projects. These tags served as simple identifiers. For instance, a tag could denote a material type or a design feature. However, the simplicity of tags also limited their effectiveness. Tags provided no context or relationships between data points, making complex data interpretation and integration challenging.
The advent of Building Information Modeling (BIM) marked a significant leap forward. BIM's multi-dimensional models required more than just tags; they needed a system that could represent the rich, interrelated nature of building data. This necessity gave rise to the use of ontologies in the building domain.
One of the earliest examples is the Industry Foundation Classes (IFC) schema. However, IFC mainly deals with the spatial domain of the building, and while it is able to describe equipments such as HVAC and VAV, it leaves out other domains fundamental for the operational phase.
Later on, Brick and Haystack1 came to the rescue of an industry brutalised by the (mis)use of tags. Brick and Haystack are two schemas used in building automation and management systems to standardise and facilitate the integration of data from various devices and systems.
While Brick is an open-source schema that standardises building system components and their interrelations using a hierarchical model, Project Haystack focuses on IoT data management in buildings through a tag-based approach for semantic data modelling.
Expanding ontologies
As mentioned before, ontologies primarily consist of two parts: entities and relationships. Based on this, we can say that ontologies can be “expanded” in two directions, level of details and conceptual scope.
Level of details: describe the action of better detailing what composes a class, further populating it with subclasses. This concept is analogous to the level of detail (LOD) used in a a Building Information Modeling (BIM) system. It refers to the depth and resolution of information in a building model. It ranges from basic shapes and sizes at lower levels to intricate details like specific materials and mechanical systems at higher levels.
The more detailed an ontology is, the more information contains. However, containing more information doesn’t necessarily mean adding more functionalities. Information without a context is usually not so useful.
Conceptual Scope: This approach aims to either connect domains with each other or deepen our understanding of a domain. The goal is to better detailing the kind of relationship the different classes have. An intuitive example might be related to an ecosystem. Our first understanding of an ecosystem was with a predator-prey model. Reality though, is much more nuanced, including symbiotic partnerships, competition for resources and nutrient cycles.
Often, the natural evolution of ontologies touches both aspects, growing 'diagonally' as a higher level of detail might necessitate specific relationships.
In the case of buildings, two different approaches have been developed: ASHRAE 223P, to describe what’s in the building, and ASHRAE 231P, to control the building. Their goal is fundamentally different, one (223P) enables parametric design and analytics, mainly focusing on the connection between the 3 entities described. On the other hand, the other (231P) focuses on the kind of information and relationship required to control the energy systems within the building.
As I mentioned in my latest article, these two standards have been designed to be complementary, integrating the design and operational phases of building energy systems. De facto, if properly integrated, they potentially create a bigger ontology. This enables a level of detail and conceptual scope that unlock the potential of autonomous control and digital twins.
So far we got the idea that the ontology untap a bunch of opportunities, but how exactly does it work? In the next part of the article, we will deal with an example describing how ontologies can be used as foundations to design AI applications.
Brick: https://brickschema.org
Haystack: https://project-haystack.org/doc/docHaystack/Intro