Brick Schema vs Haystack vs RealEstateCore: Choosing a Building Digital Twin Ontology (2026)

Every building digital twin project hits the same wall in week three. The BACnet scan returns forty thousand objects named things like AI-1047 and Zn-T-Room_Occ_Cl, the CAD export knows the rooms but not the air handlers that serve them, and someone asks which semantic standard to adopt so the analytics vendor can “just plug in”. Three names come back from every search: Project Haystack, Brick, and RealEstateCore. The usual advice treats them as interchangeable competitors. They are not.

The brick schema vs haystack question is really a question about layers. Haystack is a tagging convention and data-exchange API that grew a schema language. Brick is an RDF class ontology built for validation and graph queries. RealEstateCore (REC) is a broader spatial, asset and capability model that ships as DTDL for twin platforms. This guide separates what each one models, shows the same AHU in all three, and gives a selection rule you can defend in a design review.

What this covers: the design philosophy of each model, a worked example, SPARQL and DTDL code, BACnet mapping, ASHRAE 223P status, tooling and convergence, failure modes, and a decision matrix.

Context and Background

Building metadata has always been a bottleneck. A typical commercial building has thousands of points spread across HVAC, lighting, metering and access control, and each vendor names them differently. Before analytics or a digital twin can do anything useful, a human has to tell the software what each point means and where it sits. Studies and vendor experience consistently describe this onboarding as manual, expensive and error-prone, which is exactly the gap the three efforts address from different angles.

Project Haystack was formed in 2011 as an open-source, member-driven effort to standardise semantic data models for IoT and building device data. It started as a lightweight tag convention: you attach marker tags such as point, sensor, discharge, air and temp to an entity and let software infer meaning. Brick came out of academic and national-lab work and is an open-source, BSD-licensed development effort to create a uniform schema for building metadata, expressed in RDF and OWL. RealEstateCore began as a Swedish and Nordic property-industry ontology effort and is documented in the ISWC 2019 paper by Hammar and colleagues. Its repository states that the equipment and point hierarchies were developed in collaboration with Brick.

A fourth actor sits behind all three. ASHRAE Standard 223P, titled “Semantic Modeling for Building Control and Monitoring Applications” on the US Department of Energy’s pages, is being developed on W3C Semantic Web standards: RDF for the model, SPARQL for queries and SHACL for constraints. The DOE describes BuildingMOTIF as a library and tool for creating, validating and translating semantic models in 223P, Brick and Haystack formats (US DOE, Semantic Modeling and Interoperability). Read that sentence twice: the people building the likely long-term standard treat the other three as formats to translate between, not rivals to eliminate.

If you want the deep dive on one of them, our existing post on Brick Schema with RDF and SHACL for semantic model building covers class hierarchies, relationships, ingestion and validation in depth. We deliberately do not repeat that here. This post is the comparison layer above it, and it assumes you can read Turtle at a glance. For the field-bus side of the story, see our guide to BACnet/IP and Secure Connect for building automation, since every model below has to be populated from BACnet or similar sources.

Three Models, Three Different Jobs

Short answer: Haystack is best understood as a tag and exchange convention for operational data, Brick as a validated RDF graph of building equipment, points and relationships, and RealEstateCore as a wider real-estate model covering spaces, assets and capabilities, distributed as DTDL for twin platforms. They overlap on equipment and points but optimise for different consumers.

The thesis of this article is simple and, in our experience, not stated clearly in the top search results: pick by consumer, not by ideology. Ask who or what will read the model. A rules engine that runs fault detection wants dense, queryable HVAC topology. A twin platform that renders a campus wants spaces, floors, parts and live telemetry bound to typed twins. A BMS integrator exchanging data with a front end wants a wire format and a tag vocabulary that already exists in their toolchain. Each of the three is the natural answer to a different one of those consumers.

Figure 1: The three models mapped to the layers they cover. Haystack spans the exchange and tagging layer, Brick the validated graph layer, RealEstateCore the spatial and twin-platform layer, with converters in between.

Figure 1 shows the layering. Field protocols such as BACnet and Modbus sit at the bottom and supply raw points. Haystack and Brick both describe those points, but with different mechanics. REC adds the spatial and asset context around them. A twin platform or analytics application sits on top and consumes whichever representation fits its query model. Converters, notably in BuildingMOTIF, run sideways between the middle three.

Haystack: tags as the unit of meaning

In Haystack, an entity is a dictionary of tags. A tag is a name with an optional value, and a marker tag is a name with no value that simply asserts a property. An AHU discharge-air temperature sensor is written as a dict with point, sensor, discharge, air, temp, a kind of Number, a unit, and reference tags such as equipRef and siteRef that link to other entities. There is no class named Discharge_Air_Temperature_Sensor. The meaning emerges from the combination of tags.

Haystack 4 formalised this with defs. A def is a dictionary with a def tag that binds a symbolic name to a formal definition, and defs are ordinary Haystack data declared in Trio files and packaged as libraries in zip files. The is tag places defs in a subtype taxonomy, and conjuncts such as hot-water combine terms with a dash where order matters. The official documentation notes that conjuncts do not inherit subtypes implicitly, so each needs an explicit is (Project Haystack: Defs). In effect, Haystack 4 gave a free-form tagging convention a machine-readable dictionary, which allows inference such as deducing that something tagged chilled-water is a kind of water.

Haystack 5 was announced on 13 May 2025 at Haystack Connect 2025. Per the project’s press release, it introduces Xeto, a schema language with schema-based model definitions, built-in validation and rule enforcement, and inheritance, composition and typing, along with RDF export of semantic models as Turtle files for interoperability with other ontologies (Project Haystack press release). That is a significant philosophical shift. Tagging stays, but the validation story that was Brick’s main differentiator is no longer exclusive.

Brick: a closed vocabulary with first-class relationships

Brick takes the opposite approach to naming. Instead of letting meaning emerge from tag combinations, it defines a class for each concept: brick:Discharge_Air_Temperature_Sensor, brick:Air_Handling_Unit, brick:Variable_Air_Volume_Box. Classes form a subclass hierarchy, so a query for brick:Temperature_Sensor returns every specialised temperature sensor. Relationships are first-class, typed predicates: brick:hasPoint, brick:isPartOf, brick:feeds, brick:hasLocation. The whole model is an RDF graph, queried with SPARQL and validated with SHACL.

The cost of this precision is that you must model topology explicitly. Saying that an AHU feeds a VAV box which serves a zone is three triples, and those triples are what unlock the interesting analytics, such as tracing a hot room back to its source air handler. Haystack can express this with equipRef and similar reference tags, but the vocabulary of relationships is thinner and less formally constrained.

RealEstateCore: the building as a real-estate asset

REC has a wider remit. It models buildings, floors, rooms and zones as a spatial hierarchy, assets and components, people and agents, and capabilities and sensors. According to the REC release notes, version 3.3 added an Asset module, a spatial model separating building components from spaces, simplified part-of relations, a Capability model, a LogicalDevice class and QUDT-based units. The 4.0 release is described as a major, backwards-incompatible rewrite released as SHACL and DTDL models with OWL deprecated, integrating Brick concepts and moving to a BSD license. The latest release listed at the time of writing is 4.1.0, which adds a Warranty event type, a few room subclasses and introduces Ontology Decision Records (RealEstateCore releases).

The DTDL packaging matters for one reason: Microsoft’s Azure Digital Twins documentation names RealEstateCore as the open-source DTDL ontology for smart buildings, and says it reuses industry standards, specifically Brick Schema and the W3C Building Topology Ontology (BOT), to avoid reinvention (Microsoft Learn: adopt an ontology). If your twin runs on that platform, REC is the path of least resistance. For the DTDL authoring mechanics, see our DTDL v3 and Azure Digital Twins tutorial.

Deeper Analysis: One AHU, Three Representations

Abstract comparisons hide the differences that matter, so we model the same equipment three times. The scenario: air handling unit AHU-1 serves VAV box VAV-101, which serves room 101 on level 1. AHU-1 has a discharge-air temperature sensor sourced from BACnet analog-input 1047 on device 2001. The point names below are illustrative, not taken from a real project.

The Haystack version

Haystack data travels as Zinc, Trio or JSON. Here is the AHU and its point as Trio records, the format used for defs and for human-edited models:

id: @site-hq
dis: "HQ Campus"
site
area: 12400m²
---
id: @ahu-1
dis: "AHU-1"
equip
ahu
hvac
siteRef: @site-hq
---
id: @ahu-1-dat
dis: "AHU-1 Discharge Air Temp"
point
sensor
discharge
air
temp
kind: "Number"
unit: "°C"
siteRef: @site-hq
equipRef: @ahu-1
bacnetCur: "AI1047"
bacnetDevice: "2001"

Three things are worth noticing. First, the marker tags are the semantics, so a query like point and discharge and air and temp finds the sensor without any class lookup. Second, topology is carried by reference tags, equipRef and siteRef, and stays shallow unless you add more. Third, the BACnet addressing tags are local conventions layered on top. Haystack’s wire protocol, the HTTP API, supplies standard operations for reading entities, subscribing to values and reading history, so a client can request read with a filter and then hisRead on the matches. That operational API is something neither Brick nor REC defines.

The Brick version

The same facts in Turtle:

@prefix brick: <https://brickschema.org/schema/Brick#> .
@prefix bldg:  <urn:hq-campus#> .
@prefix ref:   <https://brickschema.org/schema/Brick/ref#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix unit:  <http://qudt.org/vocab/unit/> .

bldg:ahu-1 a brick:Air_Handling_Unit ;
    rdfs:label "AHU-1" ;
    brick:feeds bldg:vav-101 ;
    brick:hasPoint bldg:ahu-1-dat .

bldg:vav-101 a brick:Variable_Air_Volume_Box ;
    brick:feeds bldg:room-101 .

bldg:room-101 a brick:Room ;
    brick:isPartOf bldg:level-1 .

bldg:ahu-1-dat a brick:Discharge_Air_Temperature_Sensor ;
    brick:hasUnit unit:DEG_C ;
    ref:hasExternalReference [
        a ref:BACnetReference ;
        ref:BACnetURI "bacnet://2001/analog-input,1047/present-value"
    ] .

The class name carries the full meaning, and the graph captures the chain from AHU to VAV to room explicitly. The ref: namespace is Brick’s mechanism for binding a point to its timeseries or protocol source, which keeps the semantic model free of live values. The BACnet reference URI form shown follows the pattern in Brick’s documentation for external references, but confirm the exact property names against the schema version you pin before generating them at scale.

The RealEstateCore version

REC is distributed as DTDL, so the equivalent is a set of twins instantiated from interface models. A sketch of a twin instance in the shape Azure Digital Twins accepts, with illustrative model identifiers:

{
  "$dtId": "ahu-1-dat",
  "$metadata": {
    "$model": "dtmi:digitaltwins:rec_3_3:core:TemperatureSensor;1"
  },
  "name": "AHU-1 Discharge Air Temp",
  "externalIds": [
    { "bacnet": "2001/AI1047" }
  ]
}

Relationships between twins, such as a sensor isCapabilityOf a device and a device isPartOf a building component, are created as separate relationship objects. The exact interface names depend on the REC release you import. The 4.x line is documented as SHACL and DTDL, and the older Azure-hosted repository carries the 3.x DTDL interfaces, so check which version a given platform tool expects before assuming a model ID. The takeaway is structural: REC emphasises typed twins with capabilities and spatial containment, the shape a twin graph wants.

Figure 2: The same AHU discharge-air sensor expressed as Haystack tags, Brick triples and REC twins. Semantics move from tag combinations to class names to typed twins with relationships.

Semantic model creation pipeline

Writing these records by hand does not scale past a demo. Every real project runs a pipeline, and the structure is nearly identical whichever target you choose. The stages are discovery, classification, topology, validation and publication.

Figure 3: A semantic model creation pipeline. Raw BACnet objects are classified, topology is added from drawings and schedules, and the result is validated before being published to a twin platform or analytics store.

Discovery enumerates BACnet devices and objects, typically with Who-Is and Read-Property-Multiple, producing an inventory of object identifiers, names, descriptions and units. Classification maps each point to a class or tag set, usually with rules on name patterns first and a human or model-assisted review second. Topology comes from mechanical schedules, one-line diagrams and floor plans. Validation applies shapes or schemas. Publication writes the graph to a triple store, pushes twins to a platform, or serves the entities through a Haystack-style API.

Classifying BACnet points: runnable code

Here is a small but real classifier that maps BACnet point names to both Haystack tag sets and Brick classes. It uses only the Python standard library plus rdflib, and the rules are deliberately naive so you can see the mechanism:

import re
from rdflib import Graph, Namespace, RDF, RDFS, Literal

BRICK = Namespace("https://brickschema.org/schema/Brick#")
BLDG = Namespace("urn:hq-campus#")

# (regex on a normalised point name) -> (haystack tags, brick class)
RULES = [
    (r"\b(dat|disch\w*)\b.*\btemp\b|\bdischarge.*air.*temp",
     ["point", "sensor", "discharge", "air", "temp"],
     BRICK.Discharge_Air_Temperature_Sensor),
    (r"\b(rat|return)\b.*\btemp\b",
     ["point", "sensor", "return", "air", "temp"],
     BRICK.Return_Air_Temperature_Sensor),
    (r"\bfan\b.*\b(cmd|command)\b",
     ["point", "cmd", "fan", "run"],
     BRICK.Supply_Fan_Run_Command),   # illustrative: confirm class name
    (r"\bzone\b.*\btemp\b|\broom\b.*\btemp\b",
     ["point", "sensor", "zone", "air", "temp"],
     BRICK.Zone_Air_Temperature_Sensor),
]

def norm(name: str) -> str:
    return re.sub(r"[_\-\.]+", " ", name.lower())

def classify(name: str):
    n = norm(name)
    for pattern, tags, brick_cls in RULES:
        if re.search(pattern, n):
            return tags, brick_cls
    return None, None

points = [
    {"id": "ahu-1-dat", "equip": "ahu-1", "name": "AHU1_Disch_Air_Temp",
     "bacnet": "2001/analog-input,1047"},
    {"id": "ahu-1-rat", "equip": "ahu-1", "name": "AHU1_Return_Air_Temp",
     "bacnet": "2001/analog-input,1048"},
    {"id": "mystery-7", "equip": "ahu-1", "name": "AV_77", "bacnet": "2001/analog-value,77"},
]

g = Graph()
g.bind("brick", BRICK)
g.bind("bldg", BLDG)

for p in points:
    tags, cls = classify(p["name"])
    if cls is None:
        print(f"UNCLASSIFIED {p['id']}: {p['name']} -> send to review queue")
        continue
    node = BLDG[p["id"]]
    g.add((node, RDF.type, cls))
    g.add((node, RDFS.label, Literal(p["name"])))
    g.add((BLDG[p["equip"]], BRICK.hasPoint, node))
    print(f"{p['id']}: haystack={' '.join(tags)} | brick={cls.split('#')[-1]}")

print(g.serialize(format="turtle"))

Two honest caveats. The regexes are a teaching device, and real deployments combine pattern rules with unit checks, value ranges from sampled data and review queues; the research literature on automated metadata inference exists precisely because naming conventions vary so much. Second, the class names in the rule table must be checked against the Brick version you load, because Brick has renamed and deprecated classes between releases, as its release notes document.

Querying and validating the Brick graph

Once the graph exists, SPARQL answers cross-system questions that tag filters cannot express cleanly. This query finds every temperature sensor, of any specialised subtype, on equipment that feeds a given room, using the rdfs:subClassOf* property path so you do not need an inference engine:

import brickschema

g = brickschema.Graph(load_brick=True)   # loads the bundled Brick ontology
g.parse("hq-campus.ttl", format="turtle")

q = """
PREFIX brick: <https://brickschema.org/schema/Brick#>
PREFIX rdfs:  <http://www.w3.org/2000/01/rdf-schema#>
PREFIX bldg:  <urn:hq-campus#>

SELECT ?equip ?sensor ?cls WHERE {
  ?equip brick:feeds+ bldg:room-101 .
  ?equip brick:hasPoint ?sensor .
  ?sensor a ?cls .
  ?cls rdfs:subClassOf* brick:Temperature_Sensor .
}
"""
for row in g.query(q):
    print(row.equip, row.sensor, row.cls)

The brick:feeds+ path walks the chain from AHU through VAV to the room, which is the multi-hop topology question that motivates a graph in the first place. Validation uses SHACL, for example to demand that every brick:Air_Handling_Unit has at least one supply-air temperature sensor. We covered shape authoring in the Brick RDF and SHACL deep dive, so here we only note the comparison point: Brick’s validation is applied to an open-world RDF graph through a separate SHACL step, while Xeto builds validation into the schema language itself.

Interoperability, Convergence and ASHRAE 223P

The most useful fact for decision makers is that these ecosystems are converging rather than diverging, and that the convergence is visible in release notes. The REC 4.0 release notes state that it integrated Brick Schema concepts and ships as SHACL and DTDL, with OWL deprecated. Brick’s 1.5.0 release candidate notes deprecate brick:Collection in favour of rec:Collection, begin lighting alignment with the REC working group, and update REC patches for compatibility with Brick 1.4 (Brick releases). Haystack 5 added RDF export so that its models can meet RDF ontologies halfway. Each project is quietly building bridges to the other two.

That does not mean the models are equivalent. Round-tripping loses information in predictable places. Going from Brick to Haystack tags discards the formal class hierarchy and the typed relationship vocabulary, leaving reference tags. Going from Haystack to Brick requires a decision for every ambiguous tag combination, because tags are open and classes are closed. Going from either to REC adds spatial and capability structure that the source never had, so someone has to supply it. Plan converters as one-directional enrichment pipelines, not as lossless synchronisation.

Where ASHRAE 223P fits

ASHRAE 223P, whose full title on the DOE page is “Semantic Modeling for Building Control and Monitoring Applications”, aims to standardise queryable, checkable descriptions of building systems, components, relationships and their sensing and actuation points. The DOE describes the project as building on RDF, SPARQL and SHACL, with templates, compliance-checking tools and translators to and from other metadata schemas. The same page, last modified in April 2026, still presents the standard as under development and lists a project term that ended on 30 September 2025, and it says the effort aims to eventually become an ISO standard (US DOE).

A caveat on status: we could not confirm from a primary source in this research pass whether the standard has completed publication or in what edition. Our recollection is that the ASHRAE 223 standard was published in the 2023 to 2024 timeframe with continuing addenda, but treat that as unverified and check the ASHRAE store or the Open223 site before citing a specific edition in a specification. What we can say with confidence is the direction: a standard whose technical substrate is the same RDF, SHACL and SPARQL stack that Brick uses, with the open-source BuildingMOTIF toolchain handling 223P, Brick and Haystack models.

The practical consequence is a mild tilt toward RDF-based modelling for long-lived assets. If your building will be operated for fifteen years, a model that can be validated with SHACL and translated by standard tooling is a safer bet than a purely proprietary convention. That tilt does not make Haystack a bad choice. It makes the ability to export to RDF a requirement you should check.

Tooling snapshot

The tooling landscape differs more than the models do. We list what is documented in the sources above and flag the rest as our own experience.

Concern	Haystack	Brick	RealEstateCore
Native serialisation	Zinc, Trio, JSON; Xeto for schemas	RDF (Turtle, JSON-LD)	SHACL and DTDL in 4.x; earlier DTDL v2 JSON-LD and OWL
Schema validation	Xeto built-in validation (Haystack 5)	SHACL via separate step	SHACL shapes in 4.x
Query	Filter expressions, HTTP API	SPARQL	Platform query language, for example Azure Digital Twins queries
Live data API	Standard HTTP operations for read, watch, history	None, uses external references	Defined by the host platform
Governance	Project Haystack non-profit, member-driven	Open-source, BSD, semantic versioning	Open-source, BSD-3, Ontology Decision Records
Typical consumers	BMS front ends, analytics apps, edge gateways	Research, FDD, graph analytics	Twin platforms, property portfolios

Mapping BACnet points into any of the three

Every model eventually binds to BACnet, so the binding design matters more than the model choice. A BACnet object is identified by the device instance, object type and object instance, such as analog-input 1047 on device 2001. Its Object_Name, Description and Units properties are your classification inputs. Keep three rules. Store the BACnet identity as an external reference, not as part of the semantic identity, so a controller replacement does not rename your twin. Keep units explicit and, where possible, normalised to a unit vocabulary such as QUDT, which both Brick and REC reference. Treat the semantic model and the timeseries store as separate systems joined by a stable key, which our BACnet/IP guide discusses from the network side.

Selection Matrix: Which Model for Which Project

Reducing the choice to a table risks false precision, but a matrix forces the right questions. The ratings below are our judgement from the documented capabilities above, not benchmark results.

Scenario	Best fit	Why	Watch out for
BMS vendor or integrator exchanging data with front ends	Haystack	Existing tag vocabulary, HTTP API, wide tool support	Tag drift between teams; validate with Xeto where available
Fault detection and analytics on HVAC topology	Brick	Typed relationships, SPARQL multi-hop queries, SHACL	Modelling effort for topology; class renames across versions
Campus or portfolio twin on Azure Digital Twins	RealEstateCore	DTDL packaging, spaces, assets, capabilities	Version alignment between REC 3.x DTDL and 4.x
Long-lived owner-operated building seeking standards alignment	Brick or 223P-ready RDF	RDF and SHACL substrate shared with 223P	Standard maturity; toolchain still evolving
Retrofit with poor documentation	Haystack-style tags first, upgrade later	Cheapest path to usable metadata	Rework if you later need strict topology
Multi-vendor tenant fit-out data handover	Brick or REC with SHACL profile	Contractual validation of delivered models	Need an agreed profile and checker

Figure 4: A decision flow. Start with the consumer of the model, then the platform constraint, then the validation requirement. Most projects end at Brick, REC or Haystack within three questions.

Figure 4 encodes the argument of this article as three questions. If the primary consumer is a twin platform with a hard model format, the platform decides. If it is a rules or analytics engine needing topology, you want a graph. If it is an operational exchange with existing BMS tools, tags and the Haystack API are the shortest route. Validation requirements then break ties: contractual validation of deliverables favours SHACL-capable formats.

A second-order effect deserves a sentence. Hybrid architectures are normal. A common pattern keeps Brick or a Haystack-RDF export as the system of record for equipment and topology, and projects a subset into DTDL twins for the platform, treating REC as the target schema for the projection. That keeps the authoritative model portable and the platform model replaceable.

Trade-offs, Gotchas, and What Goes Wrong

Tag sprawl in Haystack. Because tags are open, two teams can tag the same point differently and both be technically valid. Haystack 4 defs and Haystack 5 Xeto exist to constrain this, but only if you enforce them in CI. Without enforcement a large portfolio drifts into dialects, and analytics written for one dialect silently miss points in another.

Version churn in Brick and REC. Brick’s release notes show deprecations and renames in minor releases, for example the deprecation of many Brick-defined quantities in favour of QUDT in 1.4.4, and the pending move from brick:Collection to rec:Collection. REC 4.0 is documented as backwards-incompatible and 4.1 deprecates some controller classes. Pin versions in your repository, record the version in every exported model and write migration scripts early. A model with no recorded version is an unreadable legacy file in three years.

Over-modelling. Teams modelling a graph for a thirty-point rooftop unit spend months on topology no application consumes. Model what a named use case needs, then extend. The inverse failure is equally common: tagging points with no equipment or location references, which yields a flat list that supports no spatial query.

Semantic model versus live data. None of the three should carry timeseries values. Mixing live telemetry into a semantic graph produces enormous, stale graphs. Keep values in a historian or timeseries store and join on a key.

Closed-world surprises. RDF uses an open-world assumption, so a missing sensor is not a violation until a SHACL shape says it is. Teams that expect “unknown means false” are surprised when a query returns nothing but validation also passes. Write the shapes that encode your minimum viable model.

Treating a converter as a migration. Automated conversion between Haystack and Brick produces plausible output that looks complete. Sample it. Review a few percent of converted points by hand and track an error rate, because silent misclassification is worse than an obvious gap.

Standards timing risk. Betting a whole programme on a standard still moving, including 223P, is risky. Isolate the model behind an adapter so that the translation layer, not your applications, absorbs change.

Practical Recommendations

Start with the consumer, not the ontology. Write down the three questions the model must answer in year one, for example “which zones are served by an AHU with a failed discharge sensor”, “what is the floor area per tenant”, and “which twins have a warranty expiring this quarter”. Those questions tell you whether you need topology depth, spatial structure, asset lifecycle or all three.

Then choose one authoritative representation and treat the others as projections. For most owner-operators who need analytics and long-term portability, that is an RDF model, either Brick directly or a Haystack 5 model exported to RDF, validated with SHACL. For platform-first twin programmes, adopt REC in the DTDL form your platform supports and keep a source-of-truth graph beside it. For integrator-led BMS work, stay with Haystack tags and the Haystack API, but adopt Xeto or defs validation so tags cannot drift.

Whatever you choose, build the pipeline before the model. Discovery, classification, review queue, validation and publication are the real product. A model without a repeatable way to regenerate it from the field decays within a year as controllers are replaced and points are renamed.

A short checklist you can paste into a project charter:

Name the primary consumer and the three year-one questions the model must answer.
Pin the exact version of Haystack, Brick or REC, and record it in every exported model.
Store BACnet identities as external references, never as semantic identity.
Keep timeseries values out of the semantic graph and join on a stable key.
Write validation rules (SHACL shapes or Xeto specs) for your minimum viable model and run them in CI.
Sample and hand-review at least a few percent of automatically classified points.
Isolate the model behind an adapter so standards such as 223P can evolve underneath.
Check licences: Brick and REC repositories are BSD-licensed, but verify each release you adopt.

Frequently Asked Questions

Is Brick or Haystack better for a building digital twin?

Neither is universally better, because they optimise for different consumers. Brick gives you a closed class vocabulary, typed relationships, SPARQL and SHACL, which suits topology-heavy analytics and validated handovers. Haystack gives you flexible tags, a standard HTTP API and a large installed base in BMS tools, and Haystack 5 adds Xeto schemas and RDF export. Choose Brick when graph queries drive value, Haystack when operational exchange with existing tools does.

Can Haystack and Brick be used together?

Yes, and many projects do. A common approach keeps tags for the operational API and maps them to Brick classes for graph analytics. The US Department of Energy describes BuildingMOTIF as a library for creating, validating and translating semantic models in 223P, Brick and Haystack formats. Expect the conversion to be one-directional enrichment: Haystack to Brick requires classification decisions for ambiguous tag combinations, so review the output rather than trusting it blindly.

What is RealEstateCore and how does it differ from Brick?

RealEstateCore is a real-estate ontology covering spaces, building components, assets, agents and capabilities, distributed in recent versions as SHACL and DTDL models. Brick focuses on building equipment, points and their relationships in RDF. They overlap on equipment and points, and REC credits a collaboration with Brick for those hierarchies. Use REC when the consumer is a twin platform needing spatial and asset structure, especially Azure Digital Twins.

Does Azure Digital Twins support Brick or RealEstateCore?

Microsoft’s documentation describes RealEstateCore as an open-source DTDL ontology for smart buildings that reuses Brick Schema and the W3C Building Topology Ontology. Azure Digital Twins itself consumes DTDL models, so REC is the direct path. Brick is RDF, so using it there means mapping classes to DTDL interfaces or keeping Brick as an external model alongside the platform. Check which DTDL version your platform release supports before importing.

What is the status of ASHRAE 223P?

The US Department of Energy’s page, last modified in April 2026, still describes ASHRAE 223P as a standard under development, based on RDF, SPARQL and SHACL, with translators to and from other metadata schemas. We could not verify the current publication edition from a primary source, so confirm with ASHRAE before citing one in a specification. The practical guidance is stable either way: favour models that export to RDF and validate with SHACL.

Should I model every BACnet point in the semantic model?

No. Model the points that an identified use case consumes, plus enough equipment and location context to make them findable. Thousands of unused configuration and status points add classification cost and validation noise. You can always extend the model, provided the BACnet identity is stored as an external reference and the pipeline can regenerate the model from the field.

Project Haystack vs Brick Schema vs RealEstateCore for Building Digital Twins (2026)