This scenario shows the effects of various relevance ranking strategies on a small data set.
This example illustrates the richness of relevance ranking tuning possible with the modular Oracle Commerce relevance ranking system: using two modules on a data set of three records, we found that all four possible combinations of the modules into strategies resulted in different orderings, all of which were different from the default ordering.
The example uses the following example record set:
|
Record |
Title property |
Author property |
|---|---|---|
|
1 |
Great Short Stories |
Mark Twain and other authors |
|
2 |
Mark Twain |
William Lyon Phelps |
|
3 |
Tom Sawyer |
Mark Twain |
In Oracle Commerce Developer Studio, we have defined a search interface named Books that contains both Title and Author properties. The relevance rank is determined by the order in which the dimensions or properties appear in the Selected Members list.
Assume that we have not defined an explicit default sort order for the records, in which case their default order is determined by the system.
Suppose that the user enters a record search query against the Books search interface for Mark Twain. All three of the records are matches, because each record has at least one searchable property value containing at least one occurrence of both the words Mark and Twain. But in what order should the results be presented to the application user? Without relevance ranking enabled, the results are returned in their default order: 1, 2, 3.
If relevance ranking were enabled, the order depends on the relevance ranking strategy selected.
Suppose we have selected the Exact relevance ranking strategy, either by assigning this as the default strategy for the Books search interface in Developer Studio or by using URL-level search options.
In this case, the order of results would be based only on whether results were Exact, Phrase, or other matches. Because records 2 and 3 have properties whose complete values exactly match the user query Mark Twain, these results would be returned ahead of record 1, with the tie being broken by the default sort set by the system (remember that we have not defined a default sort).
Suppose we have selected the Exact relevance ranking strategy and also
specified the
considerFieldRanks parameter in the query URL. Also,
suppose that the Title property has a higher field rank value than Author for
any search matches.
In this case, the order of results would be based only on whether
results were Exact, Phrase, or other matches. Because records 2 and 3 have
properties whose complete values exactly match the user query
Mark Twain, these results would be returned ahead of record 1.
And further, because we specified
considerFieldRanks, record 2 would be returned ahead
of record 3.
Now, assume that we have selected the Field relevance ranking strategy.
The order of results would be based only on which property caused the match, with Author matches being prioritized over Title matches. Because records 1 and 3 match on Author, these are returned ahead of record 2 (again, with ties broken by the default sort imposed by the system).
Now, consider using a combination of these two strategies: Field,Exact.
In this case, the primary sort is determined by the first module, Field, which again dictates that records 1 and 3 should be returned ahead of record 2. But in this case, the Field tie between records 1 and 3 is resolved by the Exact module, which prioritizes record 3 ahead of record 1. Thus, the order of results returned is: 3, 1, 2.
Finally, consider combining the same two modules but in a different priority order: Exact,Field.
In this case, the primary sort is determined by the Exact module, which again prioritizes records 2 and 3 ahead of record 1. In this case, the Exact tie between records 2 and 3 is resolved by the Field module, which orders record 3 ahead of record 2 because record 3 is an Author match. Thus, the order of results returned is: 3, 2, 1.
