Why dictionary references decide whether your product data is portable

Most conversations about digital product data stop at structure. Get the declarations out of documents, into a spreadsheet or a database, and the job looks done. The data is digital. It is machine-readable. A system can open it.

That is stage one, and it is genuinely necessary. But it leaves the harder question untouched, and the harder question is the one that determines whether the work you do this year is still useful in three.

The question structure does not answer

Suppose your cement declaration has a row that reads:

Resistência à compressão    42,5 MPa

A machine can now read that. It cannot tell you what it means.

Specifically, it cannot tell you whether your Resistência à compressão is the same property as the Compressive strength in your German customer's procurement system, or the fck in an engineer's structural model, or the CompressiveStrength in an IFC property set, or whatever the EU registry will expect when your family's deadline arrives. A human reads all five and knows they are the same thing. Software does not. Software sees five different strings.

So every time your data crosses a boundary, somebody translates it. A consultant writes a spreadsheet that says their column 4 is our column 7. That translation is correct on the day it is written and silently wrong the first time either side changes a column. Nobody notices, because a translation failure does not look like an error. It looks like a value in the wrong field, which looks like a value.

What a dictionary reference actually is

A dictionary reference attaches a stable, resolvable identifier to the property itself, not to its name.

Instead of a column called Resistência à compressão, the declared property carries a reference to a published definition. One that states what is being measured, in what unit, under which test method, in both Portuguese and English. The string in your spreadsheet becomes a label for humans. The identifier becomes what machines match on.

The consequence is small to describe and large in effect: two systems no longer have to agree on wording to agree on meaning. Your Portuguese label and your customer's English label resolve to the same definition, so the match is a lookup rather than an interpretation.

This is what ISO 23386 and ISO 23387 specify, and it is what the Portuguese data dictionary at PDTs.pt implements for construction products. It is not a format. It is the layer underneath whatever format you happen to be exporting this year.

Why this is about to stop being optional

Three things are converging.

The Construction Products Regulation (EU 2024/3110) requires declarations to be available digitally and machine-readable. That is a structure requirement, and structuring alone satisfies the letter of it.

The Digital Product Passport standards go further. EN 18223 governs system interoperability and EN 18216 governs data exchange protocols. Both assume the data being exchanged carries meaning a receiving system can resolve without a bilateral agreement. Those standards were published by CEN in May 2026 and cited in the EU Official Journal on 15 July 2026, and the EU DPP Registry has been live since 20 July 2026. A passport now has somewhere to be registered, and something to be read by.

The DoPC standard is prEN 18357, at draft stage with CEN/TC 442/WG 12. Its title is worth reading in full: a methodology and criteria to develop data templates.

You can meet the first requirement with a spreadsheet. You cannot meet the second and third with one, because they are about data leaving your organisation and being understood elsewhere.

What it changes in practice

Your data stops being locked to a vendor

If your properties are identified only by the column names in one supplier's platform, your data is that supplier's shape. Moving it means translating it again. With dictionary references, the meaning travels with the data, so the platform is replaceable and the data is not.

This matters more than it sounds. The software you choose for digital declarations in 2026 is unlikely to be the software you use in 2036. The data will be the same data.

One declaration serves every destination

The same referenced property set becomes the digital DoPC, the product passport, the BIM property set and the figures a customer's procurement system ingests. There is no separate translation exercise per destination, because each destination resolves the same identifiers.

A gap becomes visible instead of hidden

This is the part that surprises people. When every property must reference a definition, the properties with no definition available become impossible to overlook.

We run into this constantly. Cement has eight essential characteristics under EN 197-1; five have a genuine entry in the dictionary today, and three do not, because the cement product data template does not exist yet. The honest response is to record those three as awaiting a definition, not to attach them to an approximate one.

A system that attaches everything to something reports full coverage and tells you nothing. A system that can say these three have no definition yet has told you precisely where the remaining work is, and given you the evidence to take to whoever maintains the dictionary.

What to ask a supplier

If you are evaluating anyone who offers to digitise your declarations, the question that separates stage one from stage two is:

For each declared property, what identifier do you store, and where does it resolve to?

Three answers are possible.

A column name, or a code internal to their platform, means your data carries their shape. It will need translating at every boundary, including the one where you leave them.

An identifier that resolves to a published dictionary definition means the meaning travels with the data.

And "we convert to the standard on export" means the conversion exists somewhere you cannot inspect, maintained by someone who will not tell you when it drifts.

Where this leaves you

Structuring your product data is worth doing regardless; nothing here argues against it. But structure is a local improvement. It makes your data usable by you.

References are what make it usable by everyone else, which is the whole point of a declaration. A declaration that only your own systems can interpret has not actually declared anything.

Dictagon builds the data-dictionary-referenced foundation underneath digital declarations and product passports, on PDTs.pt. Every standard we work to, and the current status of each, is listed on [the standards we build to](/standards).