Expand contract

[[synonyms-expand-or-contract]] === Expand or contract

In <>, we have seen that it is((("synonyms", "expanding or contracting"))) possible to replace synonyms by simple expansion, simple contraction, or generic expansion. We will look at the trade-offs of each of these techniques in this section.

TIP: This section deals with single-word synonyms only. Multiword synonyms add another layer of complexity and are discussed later in <>.

[[synonyms-expansion]] ==== Simple Expansion

With simple expansion,((("synonyms", "expanding or contracting", "simple expansion")))((("simple expansion (synonyms)"))) any of the listed synonyms is expanded into all of the listed synonyms:

"jump,hop,leap"

Expansion can be applied either at index time or at query time. Each has advantages (⬆)︎ and disadvantages (⬇)︎. When to use which comes down to performance versus flexibility.

[options="header",cols="h,d,d"] |=================================================== | | Index time | Query time

| Index size | ⬇︎ Bigger index because all synonyms must be indexed. | ⬆︎ Normal.

| Relevance | ⬇︎ All synonyms will have the same IDF (see <>), meaning that more commonly used words will have the same weight as less commonly used words. | ⬆︎ The IDF for each synonym will be correct.

| Performance | ⬆︎ A query needs to find only the single term specified in the query string. | ⬇︎ A query for a single term is rewritten to look up all synonyms, which decreases performance.

| Flexibility | ⬇︎ The synonym rules can't be changed for existing documents. For the new rules to have effect, existing documents have to be reindexed. | ⬆︎ Synonym rules can be updated without reindexing documents. |===================================================

[[synonyms-contraction]] ==== Simple Contraction

Simple contraction maps a group of ((("synonyms", "expanding or contracting", "simple contraction")))((("simple contraction (synonyms)")))synonyms on the left side to a single value on the right side:

"leap,hop => jump"

It must be applied both at index time and at query time, to ensure that query terms are mapped to the same single value that exists in the index.

This approach has some advantages and some disadvantages compared to the simple expansion approach:

Index size::

⬆︎ The index size is normal, as only a single term is indexed.

Relevance::

⬇︎ The IDF for all terms is the same, so you can't distinguish between more commonly used words and less commonly used words.

Performance::

⬆︎ A query needs to find only the single term that appears in the index.

Flexibility::

+

⬆︎ New synonyms can be added to the left side of the rule and applied at query time. For instance, imagine that we wanted to add the word bound to the rule specified previously. The following rule would work for queries that contain bound or for newly added documents that contain bound:

"leap,hop,bound => jump"

But we could expand the effect to also take into account existing documents that contain bound by writing the rule as follows:

"leap,hop,bound => jump,bound"

When you reindex your documents, you could revert to the previous rule to gain the performance benefit of querying only a single term.

--

[[synonyms-genres]] ==== Genre Expansion

Genre expansion is quite different from simple((("synonyms", "expanding or contracting", "genre expansion")))((("genre expansion (synonyms)"))) contraction or expansion. Instead of treating all synonyms as equal, genre expansion widens the meaning of a term to be more generic. Take these rules, for example:

"cat    => cat,pet",
"kitten => kitten,cat,pet",
"dog    => dog,pet"
"puppy  => puppy,dog,pet"

By applying genre expansion at index time:

  • A query for kitten would find just documents about kittens.
  • A query for cat would find documents abouts kittens and cats.
  • A query for pet would find documents about kittens, cats, puppies, dogs, or pets.

Alternatively, by applying genre expansion at query time, a query for kitten would be expanded to return documents that mention kittens, cats, or pets specifically.

You could also have the best of both worlds by applying expansion at index time to ensure that the genres are present in the index. Then, at query time, you can choose to not apply synonyms (so that a query for kitten returns only documents about kittens) or to apply synonyms in order to match kittens, cats and pets (including the canine variety).

With the preceding example rules above, the IDF for kitten will be correct, while the IDF for cat and pet will be artificially deflated. However, this works in your favor--a genre-expanded query for kitten OR cat OR pet will rank documents with kitten highest, followed by documents with cat, and documents with pet would be right at the bottom.