A Categorical Approach to Semantic Interoperability across Building Lifecycle

TL;DR

The paper tackles the fragmentation of building lifecycle data by introducing a category-theoretic framework for semantic interoperability. By formalizing ontologies as first-order theories and using theory extensions plus lifting problems, the authors achieve provably structure-preserving data integration with only $O(n)$ specifications for $n$ ontologies. Two CQL-based demonstrations—generating BRICK models from IFC data and a three-way IFC/BRICK/REC integration—show correct-by-construction data migrations and cross-ontology queries via compositional inference. The approach promises scalable, modular digital twins and an app-oriented ecosystem that preserves the strengths of domain-specific models while enabling reliable integration across lifecycle stages.

Abstract

Buildings generate heterogeneous data across their lifecycle, yet integrating these data remains a critical unsolved challenge. Despite three decades of standardization efforts, over 40 metadata schemas now span the building lifecycle, with fragmentation accelerating rather than resolving. Current approaches rely on point-to-point mappings that scale quadratically with the number of schemas, or universal ontologies that become unwieldy monoliths. The fundamental gap is the absence of mathematical foundations for structure-preserving transformations across heterogeneous building data. Here we show that category theory provides these foundations, enabling systematic data integration with $O(n)$ specification complexity for $n$ ontologies. We formalize building ontologies as first-order theories and demonstrate two proof-of-concept implementations in Categorical Query Language (CQL): 1) generating BRICK models from IFC design data at commissioning, and 2) three-way integration of IFC, BRICK, and RealEstateCore where only two explicit mappings yield the third automatically through categorical composition. Our correct-by-construction approach treats property sets as first-class schema entities and provides automated bidirectional migrations, and enables cross-ontology queries. These results establish feasibility of categorical methods for building data integration and suggest a path toward an app ecosystem for buildings, where mathematical foundations enable reliable component integration analogous to smartphone platforms.

Figures (8)

• Figure 1: Comparison of pairwise, reference, and categorical integration of $n$ ontologies for building digital twins. a) Pairwise integration requires $O(n^2)$ mappings with no composition guarantees (order matters). b) Reference ontology requires $O(n)$ mappings into a predetermined universal schema, but transformations are one-way and lossy. c) Categorical integration requires $O(n)$ mappings to connect all schemas bidirectionally, enabling data exchange between any ontology pair through (path independent) composition -- the best of both previous approaches. Abbreviations (as example): IFC = Industry Foundation Classes, BRICK, Occ = Occupant behavior, REC = RealEstateCore, Ont = generic ontologies
• Figure 2: Individual schemas for IFC (left), REC (middle), and BRICK (right) used in the examples
• Figure 3: IFC instance for Example 1 (and 2) in CQL. The BRICK instance is initially empty (not shown).
• Figure 4: Theory extension $C$ for Examples 1 and 2. Example 1 (entities within dashed boundary): IFC$\leftrightarrow$BRICK integration for generating BRICK operational models from IFC design data. The unified Equipment entity merges IFC's IfcDistributionElement with BRICK's Equipment; the unified Location merges IfcSpace with BRICK's Location. Formula 2 copies deviceId from PropertySet through to BRICK's Point.timeseriesId. Example 2 (all entities): Three-way integration adding REC for property management. The unified Location now also incorporates REC's Room, enabling cross-ontology queries: BRICK's Meter and SetPoint connect to REC's Lease through the shared spatial reference. Crucially, only IFC$\leftrightarrow$BRICK and IFC$\leftrightarrow$REC mappings are specified; the BRICK$\leftrightarrow$REC relationship emerges automatically through categorical composition. (Attributes are only shown for the unified entities, otherwise they remain the same as in Fig. \ref{['fig:individual_schemas']}.
• Figure 5: BRICK instance for Example 2 in CQL. Note the empty entry setPointValue for the SetPoint entity.