What Structured Product Data Actually Looks Like: A Worked Example

"Structured data" gets used constantly in BIM and DPP conversations, and almost nobody shows what it actually looks like next to what it's replacing. So here's one ordinary product, a standard 12.5 mm gypsum board built to EN 520, in three versions: the PDF technical datasheet a specifier downloads today, the spreadsheet line it becomes in a bill of quantities, and the structured version a BIM model or a Digital Product Passport would actually need. The figures below are typical for this kind of board, not a real manufacturer's exact numbers. The point isn't the board, it's what happens to the same information at each handoff.

Version 1: the PDF technical datasheet

This is where most product information still lives. A typical datasheet for a 12.5 mm gypsum board covers the standard it's made to (EN 520), a table of available thicknesses and board sizes, weight per square metre, thermal conductivity, a paragraph describing its reaction-to-fire classification, application notes, and somewhere near the bottom, often a line referencing an EPD or a Declaration of Performance without including the actual figures.

Nothing here is wrong. But every value has to be found by a person reading the layout, and manually retyped into whatever comes next, a spec, a BOQ, a model. The fire classification is buried in a sentence rather than stated as a code. The EPD is mentioned, not included. Nothing enforces that the person retyping it does so correctly, or at all.

Version 2: the spreadsheet line

The same board, once it's on a bill of quantities, usually becomes a single row someone typed by hand while working from the PDF above.

This is genuinely better, it's tabular, it can be filtered and totalled. But "12.5mm" is text embedded in a description, not a numeric thickness field with a unit. "Class A" isn't a real fire classification code, it's a shorthand someone typed from memory of the PDF paragraph. There's no field identifying which specific product this row refers to once "per datasheet v.3" stops meaning anything to the next person who opens the file. And every one of these column names, and the units behind them, was decided independently by whoever built this particular sheet, which is exactly why merging two contractors' BOQs is never a clean operation.

Version 3: what structured data actually looks like

Structured data isn't a fancier spreadsheet. It's a fixed, shared set of property names, each with an explicit unit and a defined data type, plus a persistent identifier for the exact product, and references out to external standards instead of retyped prose.

Every property name here is fixed and shared, the next manufacturer's board uses the same field for thickness, not a differently worded column. The units are explicit in the field itself. The fire class is a real classification code, not a paraphrase. The GWP figure and EPD reference sit in dedicated fields rather than a sentence pointing vaguely at a document. And the classification and bSDD identifiers, which we covered in our COBie vs IFC piece, are what let this same data slot directly into an IFC property set inside a BIM model, instead of being retyped there too.

What breaks between each version

• Units get silently redefined. One file has thickness in millimetres, the next in centimetres, the next as a word inside a description string, and nothing flags the mismatch.
• The fire class becomes three different strings for one product. A precise code in the PDF becomes a shorthand in the spreadsheet and, without a structured source, an inconsistent guess by the time it reaches a model.
• The link back to the EPD or Declaration of Performance gets lost. It's mentioned in the PDF, dropped in the spreadsheet, and by the third handoff nobody can trace which document the environmental figures actually came from.
• There's no single identifier tying the product together across files. "Per datasheet v.3" is not an identifier. Without something like a GTIN, three files describing one board can't be reliably confirmed to describe the same board at all.
• Errors aren't caught until someone downstream notices. A retyped value that's simply wrong looks identical to a correct one until it contradicts the model, the site, or the compliance paperwork.

Why this matters for BIM and the Digital Product Passport

A BIM model needs product data in exactly this named, typed, unit-explicit shape to populate an IFC property set automatically rather than through manual data entry per object, per project. And under the Construction Products Regulation, GWP declarations become mandatory for products going through EU conformity assessment from 8 January 2026, feeding into a DPP registry that goes live on 19 July 2026. We looked at how that DPP data connects to a BIM model directly in our DPP-BIM connection post. Manufacturers whose product data already exists in the structured shape above are the ones who can generate a passport largely from data they already hold. Manufacturers whose data still lives only in PDFs and spreadsheets are, in effect, building the structured version from scratch, under regulatory deadline pressure rather than on their own schedule.

Frequently asked questions