Controlled vocabularies and adjacent semantic models
Type: Finding
Status: Active supporting research
Canonical for: Transferable and non-transferable lessons from SKOS, WAI-ARIA, schema.org and DTCG
Depends on: The cited standards; standards do not prove LLM performance
SKOS
W3C SKOS separates a concept from its lexical labels. A concept may have a preferred label, alternative labels and hidden labels; it can also carry definitions, examples, scope notes, history/change notes, and broader, narrower and related relationships. It constrains preferred labels to at most one per language tag. Documented. SKOS Reference
Transferable lesson: a public human label need not be the canonical identity of a concept. Aliases and relationships can be explicit without forcing one string to do every job.
Non-transfer: SKOS is intentionally a semi-formal knowledge-organization model. It does not by itself express executable UI constraints, valid property combinations or task-selection policy.
WAI-ARIA
ARIA defines named roles, states and properties with inheritance, supported-state rules and relationships. Native host-language semantics remain preferable when available. Documented. WAI-ARIA
Transferable lesson: role, state and property are distinct semantic kinds, and conformance rules matter as much as labels. Accessibility semantics should not be inferred from visual variant names.
Non-transfer: ARIA describes accessibility semantics and interaction exposure, not product intent or visual hierarchy.
schema.org
Schema.org assigns stable types and properties, with labels, descriptions, expected types and relationships; aliases can coexist with canonical identifiers. Documented. schema.org documentation
Transferable lesson: identifiers, human labels and definitions can be separate artifacts, and concepts become more useful through typed relationships.
Design Tokens Community Group
The DTCG format gives tokens explicit types and supports references/aliases, separating a token’s identifier from its resolved value. Documented. Design Tokens Format Module
Transferable lesson: blue-500, color-action-primary and color-action-transaction are not merely naming styles; they sit at different abstraction layers. References can preserve a stable semantic token while themes change its concrete value.
Non-transfer: token aliasing governs values, not complete component-selection decisions.
Does a design system need an ontology?
Inferred: it may benefit from controlled-vocabulary features—stable concept IDs, labels, definitions, aliases, typed relations and scope notes—without requiring a full formal ontology. The missing design-system layer is executable decision metadata: applicability, exclusions, alternatives, required context and valid combinations.
The adjacent fields warn against conflating:
- concept identity with display label;
- role with state;
- semantic token with raw value;
- taxonomy relationships with behavioral constraints.