Synonyms need mapping, not coexistence

What it is

People arrive with any of “invoice,” “bill,” or “receipt.” If the system treats them as three sibling classes or three sibling filter values, the collection is sliced and hits fall. Synonyms need mapping: one preferred term for the interface to show, the rest as entrances that route to it, with retrieval and filter results identical to submitting the preferred term. Coexistence turns aliases into new objects. Mapping admits that an alias is only another key for the same lock.

Mapping lives on the lookup path. It is not writing every near-synonym into the navigation. The nav still shows only the preferred term.

Why it happens

Lookup language is more scattered than display language. Industry, region, and period variants arrive together in the search box and in support chat. Without mapping, the index honours only the preferred term, and alias queries become zero-results or walk into a side branch. If aliases are minted as sibling classes, the same object is counted twice, or split into two buckets that both look right, and choice cost rises.

Mapping folds aliases onto one concept node at query time and unfolds the preferred term at display time. What people see is stable; what they type is tolerated. Folding must be one-way: alias → preferred. Two preferred terms must not fold into each other, or concept boundaries dissolve.

Studying it

Measure mapping by aligning real query words with interface labels, not by a thesaurus.

• Paradigms: pull aliases that co-refer with a preferred term from logs; compare known-item retrieval with mapping off versus on; then test whether aliases incorrectly appear as a navigation layer.
• Independent variables: coverage of the mapping table, inclusion of misspellings and mixed-script forms, folding at query time versus displaying aliases as siblings.
• Dependent variables: recall on alias queries, rate of wrongly folding two concepts into one, dual-entrance choices caused by aliases on the nav.
• Methodological note: linguistic synonymy is not user co-reference. Gold is “points at the same object.” Over-mapping creates false positives (“order” as both a purchase and a menu); report precision with recall.

Where it stops holding

If two words are not synonyms in this domain (“account” as customer record versus “login”), mapping erases a real difference and must be refused entry to the table. User-generated tags cannot be fully mapped in advance; they can only be clustered later and suggested. Multiple languages are translation, not synonym mapping; each language has its own preferred term, and the cross-language path is a language layer, not an alias layer.

Applying it

• Keep “preferred term + alias list” for each core concept. Aliases go into retrieval and support, not into the first navigation layer.
• When a suggestion matches an alias, show the preferred term and keep the typed string recoverable.
• Absorb new aliases regularly from zero-result queries and support phrasing; entering the table requires a co-reference review.
• Verify by searching the same object once with the alias and once with the preferred term; the result sets should match. If the alias walks into another class or zero results, mapping did not happen. If two concepts that should stay apart collapse into one pot, mapping went too far.

Related

• Within the group: G1.08.1 Inconsistent terms are read as different features · G1.08.3 The glossary must cover UI, docs, and search
• Adjacent: G1.10 Controlled vocabularies and synonyms · G3.04 Spelling correction · G3.14 Fuzzy matching and approximate search
• Search terms: synonym mapping · non-preferred term · query expansion