Data model and data format — the difference that determines interoperability

Hardly any distinction in the DPP context is skipped over as often — and comes back to bite people as reliably — as the one between data model and data format.

The data format: the technical shell

A data format specifies the technical form in which information is stored and transmitted — JSON, XML, CSV, PDF. It says nothing about what the information means.

The data model: the meaning

A data model describes what information is captured, how it is defined, what meaning it has, and how it relates to other information. For the DPP, it answers questions such as: what information describes a product? How are materials, components and suppliers represented? How are repairs and recycling information captured? What relationships exist between them?

Two companies both use JSON. One calls a material "raw material," the other "material" — and structures it differently. Automatic understanding remains impossible. Only a shared data model ensures that the same information has the same meaning for different systems.

The same data model can be implemented in JSON, XML or another format. The format question is interchangeable, the model question is not.

Two levels of interoperability

• Technical interoperability — systems can exchange data at all: shared identifiers, data carriers, formats, protocols, APIs.
• Semantic interoperability — systems interpret the meaning the same way: shared data models, standardized term definitions, controlled vocabularies.

Technical interoperability is readily solvable and is usually tackled first. The semantic level is the real work — and it is predominantly a subject-matter issue, not a technical one.

Machine-readable is not machine-interpretable

Machine-readability means: a system can technically capture and process the data. Machine-interpretability means: it also correctly recognizes its meaning. A machine-readable dataset without described semantics can only be used to a limited extent in an automated way — and that is exactly what the ESPR's "interoperable" requirement targets.

You can find the terms explained in detail in the Glossary.