Data arrived. Meaning did not.

A building management system exposes thousands of points. A gateway publishes values. A historian stores them. An API returns them on request.

Technically, the integration works.

Then the questions begin:

• Which sensor belongs to the supply-air path?
• Which equipment serves this room?
• Is this value a measurement, command, setpoint or alarm?
• Which upstream system affects this downstream zone?
• Where can software find the live value behind this logical point?

The answers often live in point names, drawings, vendor manuals, spreadsheets and the memory of the person who commissioned the system. The data is available, but its context is not.

Data without context is a well-delivered mystery.

This is the gap Brick addresses. It does not focus on moving values between endpoints. It focuses on making the surrounding meaning explicit enough for people and software to use consistently.

An ontology is a vocabulary with relationships.

Brick is an open ontology and metadata schema for describing physical, logical and virtual entities in buildings, together with the relationships between them.

In plain language, Brick gives us four building blocks:

Entities are the things

An entity can represent something physical, such as a pump or room; something virtual, such as a sensor point; or something logical, such as an HVAC zone.

Classes declare what kind of thing

A class is a named category with a definition. An entity can be declared as an instance of brick:Pump, brick:Air_Handling_Unit or a more specific sensor class.

Relationships create the neighbourhood

Relationships make context explicit. An AHU can brick:hasPoint a temperature sensor, brick:feeds a terminal unit and brick:hasLocation a mechanical room.

The graph makes it queryable

Brick represents these statements as a directed, labelled graph using RDF. Entities become nodes. Relationships become edges. Software can ask for a pattern of meaning instead of decoding a local naming pattern.

An ontology is not a bag of better tags. It is a governed way to state what things are and how they relate.

Stop decoding labels. Start asking the graph.

A conventional integration often begins with a string such as B4_AHU03_SAT. A knowledgeable person may read building 4, air-handling unit 3, supply-air temperature. Software only sees characters until someone writes the decoding rules.

In a Brick model, the useful statements are separate and explicit:

Now an application can query for supply-air temperature sensors belonging to air-handling units, or follow the air path toward the zones they affect. The names may differ between buildings. The declared pattern can remain the same.

A tag is compressed local knowledge. A graph is declared shared knowledge.

Brick makes more sense. It is still not the popular name.

IEC 81346 designations are precise, but precision does not make them good everyday names. =H1.PA1.GPB1 can be an excellent governed reference and a poor heading on an operator screen.

Brick vocabulary feels more natural because classes such as brick:Pump, brick:Room and brick:Temperature_Sensor use recognisable concepts. That helps both people exploring the model and software interpreting it.

But the class is still not what people call the individual machine. A clean model keeps three roles distinct:

The preferred name can be multilingual and can change without redefining the entity. The semantic class remains a classification, not a nickname. The designation remains a governed route, not a prose description.

Let people read the name. Let software understand the class. Let the RDS preserve the route.

Stop re-teaching the building to every application.

Without a common semantic model, every dashboard, analytics package and optimisation application begins with another mapping exercise. The application may be reusable. Its understanding of the building is not.

Brick aims to make that understanding more portable. When different sites describe equivalent concepts through the same classes and relationships, software can discover what it needs instead of requiring every installation to be hard-coded in advance.

• Lower integration effortLess repeated interpretation of vendor-specific labels.
• Cross-vendor discoveryApplications can find related entities across several building subsystems.
• Reusable analyticsRules can target semantic patterns instead of one site’s tag syntax.
• Traceable data accessPoints can refer to BACnet objects, time-series identifiers or other external representations.
• Machine validationConstraints can test whether required classes, properties and relationships are present.
• ReasoningFormal axioms can make implied classes and inverse relationships explicit.

The goal is not to make the graph clever. It is to make applications less dependent on clairvoyance.

IEC 81346 gives the route. Brick describes the neighbourhood.

Brick does not complete IEC 81346 as if something were missing from the standard. It adds a semantic capability that IEC 81346 does not attempt to provide.

The models should remain connected, but not collapsed. A Brick hasPart statement is not automatically equivalent to an IEC 81346 constituent relation in a selected aspect. Similar words do not guarantee identical scope.

A robust owner architecture can connect the IEC 81346 view, the Brick view, ISA-95 operational roles and platform references through stable canonical identities.

Identity tells us which object. Semantics tells us what it means here. A durable interface needs both.

A semantic layer is not the entire stack.

Brick can serve as a semantic interfacing layer when the term is used carefully. It can provide shared meaning through which applications find the same concepts. It does not itself move the values or replace every model around it.

Brick documentation deliberately does not prescribe one standard API. Instead, the model can contain references that allow applications to locate live or historical data through external systems. The graph describes context. Other systems remain authoritative for their payloads.

The final warning is organisational. RDF syntax does not create governance. A Brick model can be technically valid and still contain the wrong entities, weak relationships, stale references or uncontrolled local extensions.

Good semantics do not emerge from syntax alone. They are governed into existence.

Give Brick the job it is good at. Make its connections to identity, operations and live data explicit. Then the semantic layer becomes infrastructure instead of another abandoned model.