What is Google's Digital Buildings ontology?

Google's Digital Buildings Ontology (DBO) is an open-source schema and toolset for representing structured information about buildings and the equipment installed in them, published under the Apache 2.0 licence. The project explains that it grew out of the need to manage a very large and varied building portfolio in a scalable way, that a version of it is used by Google to manage buildings in its own portfolio, and that its aim is analysis and management applications that are portable between buildings.

The name behind it is the least important thing about it. What matters to an owner is whether DBO supports a maintainable information model for their own buildings and applications, and whether their suppliers can work with it.

How it describes a building

The DBO documentation rests on a handful of ideas. Entities are instances of things in the model: a building, a floor, a piece of equipment such as an energy meter. Entity types place an entity in a composable taxonomy and define the data fields expected for it, so an air-handling unit type implies which measurements, set points and statuses the unit should have. Those fields are built from subfields, small words with precise definitions such as "discharge", "air", "temperature" and "setpoint", combined according to a defined format to give names like max_discharge_air_temperature_setpoint. Relationships between entities are directed, named connections. Namespaces organise the ontology, with a global namespace and only one further level beneath it.

At source, the ontology is a set of YAML configuration files, from which an RDF version is generated. Separate building configuration files map the real assets of a specific building to the abstract model, and validation tools check both ontology extensions and building configurations.

Its relationship to Brick and Haystack

The project states that it was inspired by Project Haystack and Brick, and that it maintains cross-compatibility and/or convergence with them as a long-term objective. An owner considering DBO should therefore ask how models would be exchanged with tools built around Brick or Haystack, and then test that exchange for itself.

Questions to settle before adopting it

Where the approach pays off

DBO's field-based types suit portfolios with many similar pieces of equipment. Because a type defines the fields a unit should have, validation can flag every unit that is missing something. The same discipline can also expose genuine differences between units that a looser approach would hide.