Why SKOS

The translation problem sets the requirement

A team that works in more than one language hits a problem a single-language team never sees. A word in one language does not always mean the same thing as its translation. The German word Mehrwertsteuer does not equal the English word VAT, because the law behind each word differs.

A glossary that cannot record that difference presents a false equality as a decision. The vocabulary behind the format therefore has three things to model. It needs a label per language. It needs a rejected label with the reason for the rejection. It needs a relation between two vocabularies that stops short of equality.

SKOS carries all three

SKOS, the Simple Knowledge Organization System, is a World Wide Web Consortium Recommendation of 18 August 2009. It models a preferred label, an alternative label, and a hidden label, each with a language tag. It models relations inside one vocabulary through a broader term and a related term. It models relations between two vocabularies through five separate mapping properties. Those five carry exactly the distinction the translation problem needs, because a close match is not an exact match.

The standing of the vocabulary matters as much as its shape. The project goal is a standard built on established practice, under the not-invented-here principle. Domain-Driven Design defines the practice of a Ubiquitous Language and defines no storage format for it. SKOS fills that gap. Existing Resource Description Framework tools already read SKOS, so a glossary is open to more than one tool.

The four options the project rejected

The Event-Sourced Domain Modeling core field for a ubiquitous language holds a term, a definition, and a list of avoided terms with reasons. It supports one language only, it carries no relations between terms, and its schema forbids extra properties. An extension needs a change to the ESDM binary itself, which puts the evolution of the format outside the project’s hands.

TermBase eXchange, ISO 30042:2019, comes from the translation industry and does model multilingual terminology well. It is an XML format, which sits uneasily next to source code in a repository. It also carries no relations between vocabularies. That second point is decisive. A link from a term in Sales to a term in Billing is the record that makes a translation reviewable.

The schema.org types DefinedTerm and DefinedTermSet are the lightest option and the weakest one. They carry no language tags, no relations, and no history. All three of the format’s requirements fall outside them.

A home-made format in Markdown, TOML, or YAML with invented keys was the last option. Nothing standard stands behind such a format. No existing tool reads it, and any project that adopts the format inherits this project’s invention along with it.

Where SKOS-XL enters and where it stops

SKOS-XL, the extension for labels, turns a label into a resource of its own. A label then carries properties such as a reason and a date. The project did not take SKOS-XL as the base vocabulary, because plain SKOS labels answer most of the format’s fields and the extension adds a layer to every field that does not need one.

SKOS-XL stays in use where a label genuinely needs a reason and a date. The JSON-LD output uses it for hidden labels, which are the rejected words. That is the one place where the extra structure earns its cost.

What SKOS does not carry

SKOS has no property for four things the format needs. It cannot say how far a term is settled. It cannot say who put the word into circulation. It cannot say what kind of thing the term names, or where the model uses the term. The format names these four itself and maps them to project-local properties in its JSON-LD context. A reader can tell which parts of a document are standard and which parts are the project’s, because the mapping says so.

The project deliberately deferred an envelope from the Event-Sourced Domain Modeling extension pattern and did not reject it forever. SKOS stays the vocabulary in either case, and an ESDM wrapper adds only an envelope around it. The deferral keeps the simpler path open now and costs nothing later.