The Heterogeneous Data Problem in AEC

Case study on costing

Early in a project, the costing team builds an estimate by breaking the design docket into item descriptions. As the project progresses, these estimates evolve into formal vendor quotes, with quotes coming from multiple vendors. Each vendor's quote would vary from one another to fit that vendor's own specifications, formats, and company workflows. So, how do you compare these quotes?

Given enough time, a human can quite well reconcile and understand them, but what about machines? A machine has no concept that a chair specified as, for example, "ergonomic, mesh back, 320mm base" and one specified as "model X-200, mesh, castors" are the same item.

The problem gets even worse if we need to pull intelligence out of older costing history, or that done by a different team, with their own estimate structure and set of vendors.

So, how do we make sense of these different formats and derive knowledge?

Can a relational database be a solution?

An RDBMS defined with a solid schema and normalized/canonical data seems to be a solution, with its linked, structured data better than the spreadsheet.

But AEC projects are not tabular at their core. They're graphs. A single line item in a quotation is not just a simple item. A single line item and its description could belong to assemblies, or systems, or trades, making it a graph of elements. What if you want to track changes and versions? And what about the complex multi-hop queries? An RDBMS will increasingly become slow and impractical.

Ontologies and knowledge graphs

An ontology is a formal, explicit model of a domain: what entities exist (CostItem, DesignElement, VendorQuote, Revision), what properties they have, and how they relate to each other. It's a shared vocabulary that both humans and machines can operate on.

A knowledge graph uses the ontology to create the graph from the siloed, heterogeneous data into a network of connected facts.

Multi-hop questions about complex relationships and dependencies become efficient graph traversals, and not table joins.

Inference from data

Beyond querying, ontologies enable inference, deriving facts that were never explicitly written down.

In AEC, much of the critical information lives in the non-explicit. For example, combined with the beam's geometric relationship to the opening, encoded as rules, the graph can infer that the beams above openings are lintels, and are distinct from structural beams at slab levels, without anyone having to manually recorded that connection. Such inferences become computable, rather than discoverable only by domain expert intuition.

Where this goes

Data silos won't disappear in AEC - too many stakeholders, too many tools, too much legacy. The goal should not be eliminating heterogeneity but unifying it - agreeing on a shared model of what things mean, and connecting everything to it.