What is RealEstateCore and how does it relate to Brick?

RealEstateCore (REC) is an open-source ontology for describing real estate and the data generated in and about buildings. It covers regions, sites, buildings, levels and rooms; the assets within them; the organisations and people involved; administrative groupings such as apartments or tenancies; and the data points that systems produce. It is published under the MIT licence. Brick, by contrast, is an open-source ontology focused on building equipment, operational data points and the relationships between them.

The two are complements, not competitors, and they have been brought together. Since Brick version 1.4.0, released in April 2024, the Brick download has contained the Brick and RealEstateCore ontologies in the same file, and REC's own documentation states that its point hierarchy is sourced from its collaboration with Brick.

What REC brings

REC's documentation describes a small set of core concepts governed by consistent design rules. Spaces are contiguous parts of the physical world that can contain other spaces, so a region contains sites, a site contains buildings, and a building contains levels and rooms. Assets are the equipment and other objects located in those spaces. Collections are administrative groupings treated as a unit for some purpose, such as an apartment or a set of rooms let together, and they need not be physically contiguous. Agents are the people, companies, departments and other stakeholders who hold roles. Points are the sensing and actuating capabilities of spaces and assets.

The rules are simple. Parthood (hasPart, isPartOf) only joins things of the same kind, spaces to spaces and assets to assets, while separate relationships such as locatedIn connect an asset to the space where it sits. Collections use an "includes" relationship. REC states that it does not aim to be a new standard, but to bridge existing ones pragmatically.

Two kinds of question, one model

Owners ask two kinds of question. Operational ones, such as "which unit serves this zone, and is its supply temperature right?", need equipment, points and topology, which is Brick's strength. Portfolio and commercial ones, such as "how does energy use per tenancy compare across our sites?", need the property hierarchy, tenancies and organisations, which is where REC comes in. A model that combines both can answer questions that cross the boundary, without maintaining two contradictory definitions of the same room.

Writing REC and Brick into a specification

A specification should say which vocabulary represents which concept, for instance spaces and tenancies from REC and equipment and points from Brick, held in one model with one set of identifiers. It should state the Brick release, which determines the bundled REC version, and the upgrade policy. It should ask for evidence of coverage, because a supplier's statement that it "supports Brick and REC" is weaker than a delivered model, validation results and a working query across the relationships you need. And any project-specific extensions should be documented, kept minimal and planned for migration if the shared ontologies later cover the same need.