PaperlayerView exact revision on arXiv

Source-linked AI summary

BuildGraph: A Synthetic Multi-Archetype Building Knowledge Graph Dataset

Wooyoung Jung

arXiv:2610.00038v1cs.DB

TL;DR

Public building knowledge graphs are scarce, limiting the scale and structural diversity available for research and evaluation. BuildGraph provides a synthetic, empirically grounded Brick KG dataset and query benchmark; it reaches 91.5% QAR versus 35.8% for 59 public real-world Brick files. Its text-to-SPARQL evaluation uses structured natural-language building summaries rather than raw graphs, so the reported scores are a conservative lower bound.

  • Problem

    Public building KGs are scarce, and existing resources provide insufficient scale and structural diversity for systematic text-to-SPARQL evaluation and cross-building generalization studies.

    Source: §1 · p. 2, §3.1 · p. 5

  • Method

    BuildGraph generates 120 synthetic Brick KGs across eight commercial building types and three energy-code vintages, grounding configurations in DOE prototypes and sensor placement in real buildings.

    Source: §1 · p. 2

  • Results

    91.5% overall QAR versus 35.8% for 59 publicly available real-world Brick files on the 75-query SPARQL benchmark.

    Source: §1 · p. 2

  • Takeaways & Limitations

    The dataset provides a resource for text-to-SPARQL research and building-ontology benchmarking, with labeled archetype, vintage, seed, equipment, and sensor inventories.

    Source: §1 · p. 2

    Text-to-SPARQL scores use structured natural-language summaries rather than raw RDF graphs and are a conservative lower bound; evaluation across all 120 buildings remains future work.

    Source: §7.3 · p. 20

Abstract

from arXiv · show

Semantic querying of building knowledge graphs (KGs) underpins the integration of artificial intelligence into building operations, from natural-language access to cross-building analytics, but such KGs are rarely public owing to proprietary, security, and cost barriers. BuildGraph is a synthetic building KG dataset of 120 buildings in the Brick Schema ontology, grounded in U.S. Department of Energy prototype models and sensor-placement patterns from real buildings. It spans eight commercial building types across three ASHRAE energy-code vintages, with five realizations per archetype varying URI naming, sensor-attachment predicates, and topology. A 75-query SPARQL benchmark confirms structural completeness: BuildGraph reaches 91.5% Query Answerability Rate versus 35.8% for 59 real-world Brick files. Independently, it reproduces real buildings' sensor-type proportions on their shared vocabulary (cosine 0.86-0.94), evidence of realistic instrumentation where measurable. A downstream text-to-SPARQL experiment with Gemma 4 (26B) reaches 27.3% Row-Matching F1 (+17.5 pp over zero-shot) on 12 held-out buildings. BuildGraph gives facility managers and digital-twin developers a testbed for portable analytics and natural-language interfaces, and its dataset, generator, and benchmark are openly available at https://github.com/humanbuildingsynergy/BuildGraph.

Practical Applications

BuildGraph addresses limited access to diverse building knowledge graphs with a synthetic, empirically grounded dataset and benchmark. Its query benchmark outperforms public real-world Brick files on answerability, while the dataset supports testing analytics and natural-language query tools.

Practical Applications

  • Practitioners can test fault-detection and energy-analytics queries across building types before applying them to their sites, while developers can prototype semantic applications.The released generator also lets users create buildings tailored to their portfolios.Source: Practical Applications · p. 1

1 Introduction

  • Real building KGs are scarce because of proprietary restrictions, security concerns, and limited instrumentation; the four-building BuildingQA benchmark offers insufficient scale and structural diversity.Synthetic graphs can provide research data without privacy risk or access barriers, but must be empirically grounded to avoid physically implausible structures.Source: §1 · p. 2
  • Building configurations draw on DOE prototype models, while sensor-placement probabilities are calibrated against real buildings in the Mortar corpus.The models cover HVAC systems, equipment counts, terminal-unit configuration, and zone structure.Source: §1 · p. 2
  • 91.5% overall QAR versus 35.8% for 59 public real-world Brick files shows higher answerability on the 75-query benchmark.QAR is the fraction of applicable queries returning at least one result row.Source: §1 · p. 2
  • The dataset contains 120 Brick KGs spanning eight commercial building types and three energy-code vintages, with archetype coverage validated against CBECS 2018.The 120 buildings form five realizations per archetype.Source: §1 · p. 2
  • The open-source generation methodology is reproducible and designed for extension to additional building types, ontology modes, or seeds.It is grounded in published prototype models and empirical sensor-placement data.Source: §1 · p. 2

2 Background

Building KGs encode typed entities and relationships that SPARQL can traverse, but schema conformance alone does not guarantee that queries can be answered. Public Brick resources remain limited, motivating a controlled synthetic corpus that supports building-specific text-to-SPARQL research.

2.1 From Sensor Data to Queryable Knowledge Graphs

  • RDF triples encode building facts as subject–predicate–object, and SPARQL property paths can traverse consecutive Brick feeds relationships across a structurally complete graph.Brick supplies the shared vocabulary for entity types and relationship semantics.Source: §2.1 · p. 3

2.2 Schema Conformance vs. Query Answerability

  • SHACL checks whether present relationships conform to schema, whereas QAR measures whether applicable queries return results; QAR does not establish semantic correctness, realism, or coverage beyond its workload.Both example graphs satisfy SHACL, but only the graph containing the required AHU-to-zone relationships answers that query.Source: §2.2 · pp. 3–4, Figure 2 · p. 4

3.1 Building Metadata Standards and the Brick Schema

  • Public Brick resources are limited: Mortar offers real models without a paired query benchmark, while BuildingQA provides paired questions and SPARQL for only four buildings.Mortar is described as the largest public resource, with 45 real buildings.Source: §3.1 · p. 5

3.2 Synthetic Building Data Generation

  • Prior building-model generation either produces non-semantic BIM or simulation outputs, or requires existing building data and substantial expert effort; building informatics lacks an equivalent synthetic resource.Semantic inference methods can take hours to days of expert effort per building.Source: §3.2 · pp. 5–6

3.3 Text-to-SPARQL for Building Systems

  • Building text-to-SPARQL requires domain-specific data because HVAC queries traverse multi-hop topology, equipment varies by building type, and sensor predicates differ across deployments.BuildGraph varies naming, attachment predicates, and topology across labeled, reproducible buildings and pairs them with a reusable 75-query benchmark.Source: §3.3 · p. 6

4 Dataset Description

BuildGraph contains 120 self-contained Brick Schema graphs covering 24 commercial building archetypes. Five realizations per archetype introduce controlled variation in structure, naming, and sensor attachment.

4.1 Overview

  • 120 self-contained Brick Schema graphs cover 24 archetypes formed by crossing eight commercial building types with three ASHRAE energy-code vintages.Each file contains its declarations, relationships, sensor attachments, and metadata; no external ontology files are required.Source: §4.1 · p. 6, §4.2 · p. 6
  • Dataset size ranges from 81 to 12,790 triples per building, with a mean of 2,107 triples and 451 typed entities.Table 5 reports dataset scale by building type and vintage as means over five realizations.Source: §4.1 · p. 6, Table 5 · p. 7

4.2 Building Archetypes and Vintages

  • Building-type and vintage coverage is summarized in Tables 3 and 4, including vintage effects on sensor density, metering, and system configuration.Table 3 presents archetype coverage; Table 4 summarizes vintage effects.Source: §4.2 · p. 6, Table 3 · p. 7, Table 4 · p. 7
  • Five structurally distinct realizations per archetype vary building structure, URI naming conventions, and sensor-attachment predicates.Structural sampling uses archetype-specific ranges, while sensor inclusion probabilities are based on the Mortar corpus.Source: §4.2 · p. 8

Entity Classes

BuildGraph uses 83 distinct Brick classes, with equipment entity classes organized by functional category.

Entity Classes

  • BuildGraph uses 83 distinct Brick classes.Source: Entity Classes · p. 8
  • Table 6 organizes equipment entity classes by functional category.Source: Table 6 · p. 8
  • Table 6’s Scope indicates which buildings include instances of each equipment category.Source: Table 6 · p. 8

Sensor and Control Points

BuildGraph defines sensor and control points across building systems and attaches metadata and timeseries references to graph entities. Its construction uses DOE-derived archetypes and a staged graph-generation pipeline with structural checks and a SPARQL benchmark.

Sensor and Control Points

  • Sensor and control points cover zone, AHU, terminal-unit, and central-plant systems, with sensors and setpoints alongside equipment commands and metering.The listed points include zone temperature, CO2, and occupancy; AHU airflow and pressure; terminal airflow and commands; and plant-loop measurements.Source: Sensor and Control Points · p. 8

Building and Zone Metadata

  • Building metadata records archetype, vintage, and climate zone, while HVAC zones carry floor area, spatial location, and zone type.Climate zones are sampled from a floor-area-weighted CBECS distribution; zone areas are drawn from DOE prototype ranges.Source: Building and Zone Metadata · pp. 8–9

Timeseries References

  • Approximately 85% of sensors carry timeseries reference records with unique persistent identifiers derived from sensor name and realization index.Source: Timeseries References · p. 9

5 Methodology and Data Collection

  • Generation proceeds from DOE-derived archetypes through specification construction, graph building, Turtle serialization, and validation.Validation includes generation-time structural checks and the full SPARQL benchmark.Source: §5 · p. 9, Figure 3 · p. 9
  • BuildGraph contributes the intermediate specification, plausibility constraints, controlled Brick graph construction, 75-query QAR benchmark, and released 120-building corpus.DOE supplies archetype parameters, and Mortar informs sensor-inclusion priors; neither supplies the building KGs or benchmark queries.Source: §5 · p. 9

5.1 Archetype Design

  • Archetypes encode building and vintage parameters from DOE prototype models, while structural sampling is bounded and checked for cross-field consistency.For example, chiller and boiler counts depend on plant-presence flags, and AHU count cannot exceed zone count.Source: §5.1 · pp. 9–10

Topology construction

Topology construction connects floors and zones, then links air handlers to terminals and served zones according to HVAC configuration.

Topology construction

  • The spatial hierarchy links floor and HVAC Zone nodes through brick:hasPart, with lobby and mechanical-room assignments constrained by floor.Lobby zones are restricted to the first floor; mechanical rooms to the first or top floor.Source: Topology construction · p. 10
  • Air handlers feed HVAC-specific terminal units, which deliver conditioned air to zones; service zones without terminals receive direct AHU-to-zone links.VAV and PVAV use VAV boxes with reheat, packaged single-zone systems use VAV terminal boxes, and fan-coil systems use FCUs.Source: Topology construction · p. 10

Sensor and setpoint attachment

Sensor attachment probabilities are grounded in real-building patterns and adjusted for sparse or unrepresentative data; independent random sequences make structural and sensor variation reproducible. The benchmark spans five query categories, with natural-language prompts paired with representative SPARQL queries.

Sensor and setpoint attachment

  • Sensor probabilities use Mortar frequencies by equipment class, reviewed and adjusted where data are thin or unrepresentative, with raw corpus frequencies as fallback.The curated probability tables are the primary source; the fallback covers sensor subclasses absent from them.Source: Sensor and setpoint attachment · p. 10
  • Vintage density scales base probabilities before sensor sampling, while sampled relationship styles use brick:hasPoint, brick:isPointOf, or both.Zones also receive direct temperature, CO2, and occupancy sensor attachments, enabling zone-to-sensor queries without traversing a terminal unit.Source: Sensor and setpoint attachment · p. 10

5.3 Reproducibility

  • A single seed produces independent structural and sensor random sequences, so sensor-probability changes do not alter topology and identical seeds reproduce identical files.Structural choices include zone count, AHU configuration, naming style, and relationship style.Source: §5.3 · p. 10

5.4 SPARQL Benchmark Design

  • The 75-query benchmark covers five categories, including equipment discovery, sensor relations, topology, aggregation, and multi-hop queries.Representative queries range from single-class lookups to five-hop traversals, and include natural-language prompts paired with SPARQL queries.Source: §5.4 · p. 11, Table 7 · p. 11

Scope detection

The benchmark excludes queries whose required features are absent and stratifies results by four building-complexity tiers.

Scope detection

  • Fourteen ASK queries detect required features, and queries requiring absent features are marked N/A and excluded from the Query Answerability Rate denominator.Detected features include chillers, ERVs, FCUs, zone sensors, lobbies, and mixed relationship styles.Source: Scope detection · p. 11
  • Results are stratified into four complexity tiers, from packaged-unit buildings through high-performance DOAS+ERV buildings.The tiers distinguish packaged-unit, standard central-plant, complex VAV+DOAS, and high-performance DOAS+ERV designs.Source: Scope detection · p. 11
  • The tier breakdown separates design-driven performance differences from generation failures.Source: Scope detection · p. 11

Query Answerability Rate

Query Answerability Rate measures the share of applicable building-query pairs that return at least one result row.

Query Answerability Rate

  • Query Answerability Rate is the number of passing building-query pairs divided by the number of applicable pairs.Source: Query Answerability Rate · p. 11
  • A query passes for a building only when it returns at least one result row, and it is applicable when all required scope features are present.Source: Query Answerability Rate · p. 11
  • An applicable query returning no rows remains in the denominator but not the numerator, whereas an N/A query is excluded from both sums.A generator change lowers QAR by turning passing queries into zero-row failures, not by making queries N/A.Source: Query Answerability Rate · p. 12

6 Data Validation and Quality Control

Validation combines construction checks with comparisons against building-stock data and real buildings, plus a downstream task; the construction checks guarantee well-formedness but are not independent evidence of quality.

6 Data Validation and Quality Control

  • Validation spans structural and SHACL checks, archetype coverage, sensor attachment and composition, SPARQL benchmark performance, and downstream text-to-SPARQL utility.Construction invariants are correctness guarantees, while comparisons with stock data and real buildings and the downstream task provide generator-independent evidence.Source: §6 · p. 12, §6.1 · p. 12

6.1 Generation Coverage and Structural Validation

  • Pattern coverage flags buildings with fewer than three empirical entity-property-entity matches, reflecting minimum floor-zone, zone-terminal, and AHU-terminal relationships.The check can catch equipment without sensors or zones without an AHU association.Source: §6.1 · p. 12
  • Structural checks test floor-zone, zone-terminal, AHU-feed, and terminal-zone links, as well as zone sensor attachments and temperature-sensor coverage.Service zones are excluded from the occupied-zone terminal-unit check; occupied zones with occupancy or CO2 sensors but no temperature sensor are treated as physically inconsistent.Source: §6.1 · p. 12
  • All 120 released buildings passed the post-hoc audit, with 4–65 matched empirical patterns per building, a median of 38, and zero structural or answerability failures.The corpus was generated directly rather than filtered to retain only passing buildings.Source: §6.1 · pp. 12–13
  • At 5% edge removal, 62.5% of ablated graphs were rejected, rising to 100% at 50% removal, showing the checks detect missing-structure defects.Each selected feeds, hasPart, hasPoint, and isPointOf triple was independently removed with probability p; the deposited dataset was unchanged.Source: §6.1 · p. 13, Table 8 · p. 13

SHACL Conformance

BuildGraph is assessed for schema conformance, archetype coverage, sensor fidelity, query answerability, and text-to-SPARQL performance. Across these checks, it is more answerable than the real-building corpus, while sensor-composition comparisons separately test fidelity to real buildings.

SHACL Conformance

  • 100% of the 120 released buildings conform to Brick Schema 1.3 SHACL shapes, with zero shape violations and reproducible triple sets across repeated generation.The repeated runs used the same seed sequence.Source: SHACL Conformance · p. 13

6.2 Archetype Representativeness

  • BuildGraph’s 24 archetypes account for 30.2% of U.S. commercial buildings by count; excluded categories share covered HVAC families but differ chiefly in envelope and internal loads.The generator can produce excluded categories on demand, while category-specific instrumentation remains a coverage limitation.Source: §6.2 · pp. 13–14

6.3 Sensor Attachment Rate Validation

  • AHU and VAV trunk-sensor output rates stay within ±3 percentage points of input probabilities, as do zone-level IAQ sensors; chiller deviation is −9 pp.The chiller result reflects a 36-instance sample and only five building types with central chillers.Source: §6.3 · p. 14, Table 10 · p. 14

6.4 Independent Fidelity: Sensor Composition vs. Real Buildings

  • For shared sensor types, composition cosine similarity is 0.94 for AHUs, 0.91 for VAV terminals, and 0.86 for chillers, despite differences in vocabulary coverage.Common vocabulary covers 40–48% of BuildGraph AHU and VAV points; zone-level points are excluded from this comparison.Source: §6.4 · p. 15, Table 11 · p. 15

6.5 Benchmark Results

  • Category 2 scores lower because predicate-specific queries return results only for graphs with the corresponding inverse or mixed attachment style, an intentional benchmark feature.The benchmark tests both hasPoint and isPointOf patterns found in real Brick deployments.Source: §6.5 · pp. 15–16

6.6 Comparison with Real-World Brick Buildings

  • 91.5% QAR for BuildGraph exceeds the 59-building Brick corpus’s 35.8%, a 55.7-point gap in benchmark structural completeness.The comparison measures answerability, not realism; sensor-placement realism is assessed separately.Source: Table 13 · p. 16, §6.6 · p. 16

6.7 Component Contribution Analysis

  • +40.1 pp from flat-probability sensors raises overall QAR to 91.9%; Mortar calibration adds 2.4 pp, while vintage density scaling yields 91.5% and more representative density variation.The full dataset’s lower score is concentrated in sparse pre-1980 buildings, where fewer attached sensors leave applicable queries without matching rows.Source: §6.7 · p. 17

6.8 Downstream Validation: Text-to-SPARQL Generalization

  • 27.3% Row-Matching F1 with cross-building examples improves on 9.8% zero-shot by 17.5 pp on held-out buildings.Category 5 reaches 10.1% with examples, while Category 4 gains 37.8 pp, from 10.8% to 48.6%.Source: §6.8 · p. 18, Table 15 · p. 19

7 Usage Notes

BuildGraph is a reusable dataset, generator, and benchmark intended for others to use and extend. The section outlines research and analytics applications, ways to expand the corpus, and its scope boundaries.

7.1 Intended Use Cases

  • The corpus supports text-to-SPARQL examples, fine-tuning, cross-building evaluation, and Brick-formatted KG benchmarking through its 75 query-description pairs and reusable QAR protocol.URI naming, relationship styles, and topologies vary across the buildings; paraphrase diversity remains a training bottleneck.Source: §7.1 · p. 19
  • Its shared Brick vocabulary lets portable analytics queries run across all 120 buildings, while its controlled topology and instrumentation variation also supports building-domain model training and evaluation.Use cases include fault detection, commissioning, and energy benchmarking.Source: §7.1 · p. 20

7.2 Extending the Dataset

  • The open generator can create reproducible realizations and new archetypes, with sensor probabilities adjustable for specific deployment contexts.New archetypes use DOE-style parameters without changes to the Brick builder or benchmark infrastructure.Source: §7 · p. 19, §7.2 · p. 20

7.3 Known Limitations

  • The dataset contains structural and topological information, not sensor measurements, and excludes controls, schedules, equipment sizing, and efficiency ratings.Applications needing time-series values must use a separate source.Source: §7.3 · p. 20
  • All files use Brick Schema 1.3; tools built for earlier versions may report unknown classes for equipment types introduced later.The namespace is unchanged in Brick 1.4, but users applying its updated constraint rules should re-run SHACL validation.Source: §7.3 · p. 20
  • The generated graphs do not represent individual real facilities and should not replace site-specific building models.Their statistical properties match real buildings at the distribution level.Source: §7.3 · p. 20

Data Availability Statement

The dataset, generator, benchmark queries, and pattern databases are publicly deposited or documented online under a CC BY-NC 4.0 license.

Data Availability Statement

  • The dataset is deposited at Zenodo, while the generator, benchmark queries, and pattern databases are available in the BuildGraph repository under a CC BY-NC 4.0 license.The repository documents the data used to produce the dataset, including DOE prototype parameters and empirical pattern databases.Source: Data Availability Statement · p. 20
Loading 2610.00038v1…