What is an ontology and how it can be used in buildings? Part 2
In the first part of the article, we described how ontologies offer a standardised vocabulary and set of rules that define how different aspects of a building, such as HVAC systems, lighting, and occupancy, are related and interact with each other.
From Ontologies to Knowledge Graph
To unlock the real value of ontologies, they need to interact with building data. In this context, Knowledge Graph1 represent the natural evolution of ontologies.
A knowledge graph is an interconnected network of data, structured by ontologies that define how different pieces of information relate to each other. This enables a contextual understanding of data across various domains.
We can simplify the concept as follows: knowledge graph = ontology + database.
Graph databases are a natural fit for this purpose (but not the only approach). They serve as the dynamic and scalable storage and access layer for the vast amounts of data generated in building operations. They excel in managing complex and interconnected data, allowing for efficient storage, retrieval, and analysis of data. This enables real-time insights and decision-making.
By combining the structured approach of ontologies with the flexible and powerful storage and analysis capabilities of graph databases, knowledge graphs offer an efficient way to create "plug and play" applications in this domain.
Navigating the complexity of the built environment with ontologies
We now possess all necessary elements to describe the building and the interaction of its various parts to achieve specific objectives. It becomes natural to gather all the information and develop applications based on this knowledge.
These applications can vary in complexity. Based on the ontology, they might range from straightforward informative dashboards to comprehensive autonomous control systems. Below are the three most typical applications found in buildings:
Dashboards: The Data Compass
Dashboards are the visual interface that brings the data layer to life for end-users, offering a comprehensive, at-a-glance view of a building's operational status. The dashboard illuminates the path with real-time insights and trends, empowering us to navigate through the building's performance landscape. The data compass guides our decisions, though the final actions remain in our hands. However, their simplicity also limits the benefits that could be extracted from them, tying them to deductions and actions that must ultimately be taken by people.
Fault Detection And Diagnostics: The Action Beacon
Fault detection applications thrive on the data, continuously monitoring and analysing data streams for anomalies or deviations from expected patterns. Using predefined rules or machine learning algorithms grounded in the ontological structure, these applications can pinpoint potential issues before they evolve into significant problems. When potential issues are detected, the action beacon highlights them, converting uncertainties into actionable insights. Moreover, diagnostics doesn't just alert to anomalies; they guide towards necessary interventions, ensuring we are always prepared to steer the building back on course.
Supervisory Control: The Steering Autopilot
Supervisory control applications are the captains of the building automation ship. They leverage the interconnected data to automate processes, execute control strategies, and respond to changing conditions dynamically. Supervisory control adjusts HVAC settings for optimal comfort and efficiency ensuring the building operates smoothly and efficiently.
All these applications provide different tools to navigate the complexity of the built environment, and we need them for different reasons. Unfortunately, often the benefits are directly proportional to the complexity of these solutions.
If you have arrived here, you may have noticed some similarities with the concept of the 'Independent Data Layer' concept popularised by James Dice and the Nexus Labs2. In fact, it is the same concept, just described from a different perspective.
If you do not know what I am talking about, this is a must read Nexus Lore: The smart building blocks. Using the same terminology of their article, the ontology is the “data model” and the database is the “data storage”.
So far, we have described what we could do with the ontology but haven't unlocked “any new features”. Why, then, is it so important?
This approach offers two main advantages:
Eliminate application silos: this results in lower costs for every application that the building might need.
Enable application portability: having an agnostic and standardised way of describing what's in the building, we can develop a single, generalised application ready to be integrated with a specific database.
At first glance, this might not seem worth the effort. However, anyone who has tried to develop an application on top of a messy naming convention understands the pain of mapping and standardizing everything. This process is essential to obtain the necessary data to begin building the requested application. If not, I hope ontologies spare you from that experience. Moreover, knowing you'll face the same challenges with every new building clarifies why I advocate for the use of ontologies.
Challenges of implementing ontologies
One significant challenge to implement ontology is ensuring that it is comprehensive enough to cover all aspects of the building while being flexible enough to accommodate changes and updates. Often, the result is the proliferation of new standards rather than building upon existing ones, followed by an explosion of standards, as illustrated in this xkcd cartoon.
ne solution involves engaging a broad spectrum of stakeholders in the ontology's development to ensure comprehensive coverage of all necessary aspects. Another option is to combine multiple ontologies, using a modular approach that can be updated and expanded as the building and its systems evolve. This approach mirrors ASHRAE's strategy, which promotes interaction among various standards, including communication protocols (ASHRAE 135 BACnet), semantic interoperability (ASHRAE S223P), and control description language (ASHRAE S231P).
If you want to understand how these standards can be combined in a real-world implementation, here you can find a very interesting application done by the Lawrence Berkeley National Lab.
Conclusions
As buildings become smarter and more connected, ontologies will evolve to handle new entities and more complex interactions. We can expect to see more dynamic ontologies that can adapt in real-time to changes within the building, providing insights on how to better use systems, leading to even more efficient and responsive environments.
In conclusion, ontologies are a crucial component in the modern management of buildings, providing a structured approach to understanding and optimizing the vast array of systems and interactions within a building.
If tasked with offering a non-traditional and provoking definition, I'd describe an ontology as follows:
An ontology is the most efficient pathway to implementing AI at scale in buildings
Some links if you want to read more about knowledge graph and ontologies