About OpenCDD

One vocabulary. Many domains. The same identifier everywhere it appears.

OpenCDD is an open-source ecosystem of tools around the IEC Common Data Dictionary. The dictionary itself is maintained by IEC TC 3; we build the browser, the Ruby model, and the TypeScript port. This page is about the name, the logo, and the design choices.

§ 1 — The spirit

Common ground, preserved differences.

OpenCDD exists to make one structural principle legible: seek the common ground, preserve the differences. It is a diplomatic and philosophical idea — find what is shared without erasing what makes each party distinct — and it is exactly what the IEC Common Data Dictionary does.

Manufacturers, regulators, suppliers, and engineers across electrotechnology, industrial measurement, low-voltage switchgear, and household equipment each maintain their own terminology. CDD does not ask them to give it up. Instead, it binds every entity — every class, property, value list, value term, unit, and relation — to a globally unique International Registration Data Identifier (IRDI). The vocabulary is shared. The terminology is preserved.

That is the structural foundation for everything OpenCDD cares about: encapsulation (private dictionaries that interoperate with public ones), reuse (one property definition cited everywhere it appears), the four-layer ontology (meta-class → class → instance → powertype), interoperability, and extensibility. Common ground, preserved differences.

§ 2 — The logo

Pools, water, and living data

OpenCDD · 2026

The logo is a landscape in miniature. A hexagonal prism holds three interconnected pools of water — the data lakes of the common dictionary. Each domain, each language, each manufacturer feeds its own stream into them; the pools collect these streams into one body and let them flow into each other, because a property in one domain is often a class in another.

The water is not still. It falls — a quiet, continuous waterfall — sustaining everything below. The dictionary is not a frozen snapshot but a living system: every entity receives its identifier, every identifier carries its version, every version is preserved. The water keeps coming.

And from the water, things grow. Atop the prism, golden branches reach upward — interoperable data trees, rooted in the same pools, drawing from the same water. Each tree is a domain: self-contained, yet connected through the water that feeds it all.

Water collected. Water flowing. Life growing. A common data dictionary is not a monument — it is a watershed.

Why pools and trees, not a graph?A graph shows connections but not sustenance. It tells you that A links to B, not that A and B draw from the same source and grow toward the same sky. CDD is older than the modern web and deeper than a graph: it is a four-layer ontology where identifiers carry water — version, definition, relation — to every branch that needs them.

§ 3 — The colours

Wabi-sabi, water, and a single capstone.

The palette is borrowed directly from the logo: warm creams, sandy beiges, ocean teals, and a strong amber-orange capstone. It is deliberately quiet. CDD is a reference work; the typography and the data should carry the page, not the chrome.

#1A1814

Ink

#FBFAF3

Paper

#D5AA65

Clay

#25A2CB

Teal

#3F6EA3

Lapis

#F4B03A

Hexagram

Paper is the background — warm cream, calmer than pure white.
Ink is the text — warm charcoal, never pure black.
Clay is the surface tone of the prism — the primary brand beige, used in cards and dividers.
Teal is the data accent — the colour of the pools. Used for secondary surfaces and success states.
Lapis is the depth accent — the deeper blue below the surface.
Hexagram amber is the single loud accent — the capstone colour, used sparingly for primary CTAs and brand moments. Never for body text.

§ 4 — The spirit

Four layers, two directions, one identifier.

CDD is structurally unusual. It is not a class diagram and it is not an RDF graph. It is a four-layer ontology:

the dictionary schema (defined normatively in EXPRESS);
the meta-classes (Class, Property, ValueList, ValueTerm, Unit, Relation);
the dictionary content (the actual classes and properties);
the instances — which, when class_type allows, can themselves act as classes elsewhere.

That last step — instances-as-classes, the power-type pattern — is what makes CDD extensible. A new domain can extend an existing class without modifying it; a private dictionary can interoperate with the public one without losing its own identity. The mechanism is the spec's class_type attribute (CATEGORICAL CLASS, FEATURE CLASS) and the is_case_of relationship. See CDD ontology vs UML and RDFfor the full argument.

Two directions of reuse, one identifier scheme. That is the whole point. OpenCDD exists to make that point legible, browseable, and machine-usable.

§ 5 — The ecosystem

Where OpenCDD lives.

Repository	Role
opencdd/opencdd-ruby	The Ruby model — the canonical implementation. Reads `.xls` and `.xlsx`, exports JSON and CDDAL.
opencdd/cdd-models-ts	`@opencdd/opencdd` on npm — the TypeScript port of the model types.
opencdd/opencdd.github.io	This browser — pre-renders every entity page; statically hosted and free to use.
opencdd/editor	Planned. A browser-based editor for authoring CDD content.

A note on IEC

OpenCDD is not affiliated with the International Electrotechnical Commission. IEC owns the standards (IEC 61360 and friends) and the dictionary content; we own the tooling. The logo's imagery and our design philosophy are our framing, not IEC's. For the canonical publications, see the IEC webstore.