What is a building ontology?

A building ontology is a formal, shared definition of the kinds of things that exist in a building, such as equipment, systems, spaces, sensors and meters, and of the ways they can be related. It lets software record that an item is a pump, that it is part of a heating system, that it serves a particular set of spaces, and that a given sensor measures its outlet temperature. A list of point names and values cannot carry that context reliably; an ontology can.

The word comes from philosophy, but in practice an ontology is a carefully defined vocabulary plus rules about how its terms connect. Project Haystack's documentation shows the progression in a single model, from formally defined tag names up to an ontology of relationships between them.

Why shared definitions matter

Without them, every application has to be taught each building's naming conventions by hand. With them, an application can ask a question once, say "find every air-handling unit and its supply-air temperature sensor", and get an answer in any building modelled the same way. That is the foundation for portfolio analytics, for reusable fault detection and for applications that can move from one building to another.

The main options

Several open building ontologies are in use, each with a different emphasis:

They overlap, and some are converging. The choice is usually driven by the tools, suppliers and skills available, and by the questions the owner needs answered.

A shared vocabulary still needs correct facts

ETSI's SAREF principles describe the aim of a shared reference model: different semantic assets keep their own terminology but relate through common semantics, so that one set of mappings to the reference replaces a dedicated mapping between every pair. That is a genuine benefit. It still requires the mappings to be made, though, and the underlying information to be right. If nobody knows which unit serves which floor, the ontology has nothing correct to record.

Model for the decisions you have

The model should be shaped by the decisions it must support, with the vocabulary and level of detail following from them. Maintenance planning, energy analysis and space management need overlapping but different relationships, and modelling every conceivable detail on day one consumes budget without improving the first decision.

Established vocabularies should be used wherever they fit. Where an extension is unavoidable, it should be documented, kept small and accompanied by a plan to migrate if the shared ontology later covers the same concept. Recording the versions used means another team can still interpret the model in five years' time.

Changes need an approver, too. Renaming a room, replacing a controller or splitting a tenancy may require several relationships to change as well as a label.