In Formatting Synonyms, we have seen that it is 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.
This section deals with single-word synonyms only. Multiword synonyms add another layer of complexity and are discussed later in Multiword Synonyms and Phrase Queries.
With simple expansion, any of the listed synonyms is expanded into all of the listed synonyms:
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.
|Index time||Query time|
⬇︎ Bigger index because all synonyms must be indexed.
⬇︎ All synonyms will have the same IDF (see What Is Relevance?), meaning that more commonly used words will have the same weight as less commonly used words.
⬆︎ The IDF for each synonym will be correct.
⬆︎ 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.
⬇︎ 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.
Simple contraction maps a group of 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.
- ⬇︎ The IDF for all terms is the same, so you can’t distinguish between more commonly used words and less commonly used words.
- ⬆︎ A query needs to find only the single term that appears in the index.
⬆︎ 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
boundto the rule specified previously. The following rule would work for queries that contain
boundor for newly added documents that contain
"leap,hop,bound => jump"
But we could expand the effect to also take into account existing documents that contain
boundby 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.
Genre expansion is quite different from simple 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
kittenwould find just documents about kittens.
A query for
catwould find documents abouts kittens and cats.
A query for
petwould find documents about kittens, cats, puppies, dogs, or pets.
Alternatively, by applying genre expansion at query time, a query for
would be expanded to return documents that mention kittens, cats, or pets
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
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
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
pet would be right at the bottom.