Most Recent

Friday, May 29, 2020

Endeca Experience Manager Rule - What happens when Auto correction happened for search term?

Spelling Correction operates by computing alternate spellings for user query terms, evaluating the likelihood that these alternate spelling... thumbnail 1 summary
    • Spelling Correction operates by computing alternate spellings for user query terms, evaluating the likelihood that these alternate spellings are the best interpretation, and then using the best alternate spell-corrected query forms to return extra search results.

    For example, a user might search for records containing the text "Dressas". With spelling correction enabled, the Endeca MDEX Engine will return the expected results: those containing the text "Dresses".


    What happens if auto correction happens during keyword search :-

    1. Suppose, we create a rule in Endeca experience manager with Location search term "dresses".
    2. User enters a search term as "dressas".
    3. For First keyword, "dressas" would auto corrected to "dresses".
    4. Rule created as part of step 1 would be triggered if the user searches for "dresses" or any term that would be auto corrected to "dresses".
    5. Same thing applicable for stemming as well.
    Endeca XM Auto correction Rule based on Location

    Thursday, March 17, 2016

    Oracle Endeca - how to use snippeting in Record Searches??

    Definition :- The snippeting feature (also referred to as keyword in context or KWIC) provides the ability to return an extract from a r... thumbnail 1 summary
    • Definition:-

    The snippeting feature (also referred to as keyword in context or KWIC) provides the ability to return
    an extract from a record—called a snippet—to an application user who performs a record search query. A snippet contains the search terms that the user provided along with a portion of the term’s surrounding content to provide context

     A snippet can be based on the term itself or on any thesaurus or spell-correction equivalents. At least
    one instance of a term or equivalent is highlighted per snippet, regardless of the number of times the
    term or its equivalents appear in the snippet. A thesaurus or spell-corrected alternative may be
    highlighted instead of the term itself, even if both appear within the snippet.
    Enabling and Configuring snippeting :-

     You can configure snippeting on a per query basis by using the Ntx URL query parameter, the snip operator of Ntx , and key/value pairs that indicate which field to snippet and how many words to return
    in a snippet. 

     Find out example below:-

     In a record search for records containing the word brilliant, snippet the product.longDescription property with
    a maximum size of 10 words:

    N=0&Ntk=All&Ntt=brilliant&Ntx=snip+product.longDescription:10


    Endeca Record search snippeting


    Endeca generates a new property "product.longDescription.Snippet" as part of attributes as per screen shot above.

    Wednesday, March 16, 2016

    Oracle Endeca x.x - Search query processing order in MDEX

    This section summarizes how the MDEX Engine processes record search queries. The process outlined here assumes that other features (such as ... thumbnail 1 summary
    • This section summarizes how the MDEX Engine processes record search queries.
    The process outlined here assumes that other features (such as spelling correction and thesaurus) are being used.

     The MDEX Engine uses the following high-level steps to process record search queries:

     1. Record filtering
    2. Endeca Query Language (EQL) filtering
    3. Auto-correction (spelling correction and automatic phrasing)
    4. Thesaurus expansion
    5. Stemming
    6. Primitive term and phrase lookup
    7. Did you mean
    8. Range filtering
    9. Navigation filtering
    10. Business rules and keyword redirects
    11. Relevance ranking

     Step 1: Record filtering
    If a record filter is specified, whether for security, custom catalogs, or any other reason, the MDEX Engine applies it before any search processing.The result is that the search query is performed as if the data set only contained records allowed by the record filter.

     Step 2: Endeca Query Language filters
    The Endeca Query Language (EQL) contains a rich syntax that allows an application to build dynamic,complex filters that define arbitrary subsets of the total record set and restrict search and navigation results to those subsets. If used, this feature is applied after record filtering.

     Step 3: Auto-correction (spelling correction and automatic phrasing)
    If spelling correction and automatic phrasing are enabled and triggered, the MDEX Engine implements them as part of the record search processing.If the spelling correction feature is enabled and triggered, the MDEX Engine creates spelling suggestions by enumerating (for each query term) a set of alternatives, and considering some of the combinations of term alternatives as whole-query alternatives.

     Step 4: Thesaurus expansion
    The tokenized query, as well as each query alternative generated by spelling suggestion, is expanded by the MDEX Engine based on thesaurus matches. This topic describes the behavior of the thesaurus expansion feature.
    Thesaurus expansion replaces each expanded query term with an OR of alternatives.
    For example, if the thesaurus expands pentium to intel and laptop to notebook, then the query pentium laptop will be expanded to: (pentium OR intel) AND (laptop OR notebook) assuming the match mode is MatchAll.

     Step 5: Stemming
    Query terms, unless they are delimited with quotation marks to be treated as exact phrases, are expanded by the MDEX Engine using stemming.

    Step 6: Primitive term and phrase lookup
    Primitive term and phrase lookup is the lowest level of search processing performed by the MDEX Engine.

    Step 7: Did You Mean
    The MDEX Engine performs the "Did You Mean" processing as part of the record search processing."Did You Mean?" processing is analogous to the spelling correction and automatic phrasing processing, only that the results are not included, but rather the spelling suggestions and automatic phrases themselves are returned.

    Step 8: Range filtering
    Range filter functionality allows a user, at request time, to specify an arbitrary, dynamic range of values that are then used to limit the records returned from a navigation query. Because this step comes after "Did you mean?" processing, it reports the number of records before filtering.

    Step 9: Navigation filtering
    The MDEX Engine performs all filtering based on the navigation state after the search processing.This order is important because it ensures that the spelling suggestions remain consistent as the navigation state changes.

    Step 10: Business rules and keyword redirects
    Dynamic business rules employ a trigger and target mechanism to promote contextually relevant records to application users as they search and navigate within a data set. Keyword redirects are similar to dynamic business rules also use trigger and target values. However, keyword redirects are used to redirect a user's search to a Web page (that is, a URL). These features are applied after navigation filtering.

    Step 11: Relevance ranking
    Relevance ranking is the last step in the MDEX Engine processing for the record search. Each of the navigation-filtered search results is assigned a relevance score, and the results are sorted in descending order of relevance.

    Click here to get more topics related to Endeca basic concepts.

    Thursday, March 10, 2016

    Endeca all versions : Special character in search term

    Endeca uses only alphanumeric characters to be searchable by default as part of Endeca search query. Behavior: If any search term con... thumbnail 1 summary

    • Endeca uses only alphanumeric characters to be searchable by default as part of Endeca search query.


    Behavior:

     If any search term contains any special characters, Endeca replaces special characters by "space" and make Endeca query. This may not give intended results.

     Example: If a search term is T-Shirts, Endeca internally replaces with space so searchable terms would be "T Shirt". Search using internally updated search term by Endeca would not give desired results.

    Solution :

    For Forge-based Application

    1. Open  <<Endeca_App_Path>>/config/pipeline/<<app_name>>.search_chars.xml.
    2.  Add all characters that you want to make searchable.
    3.  Run baseline.


    For CAS based Application

    1. Open  <<Endeca_App_Path>>/config/mdex/<<app_name>>.search_chars.xml.
    2.  Add all characters that you want to make searchable.
    3.  Run baseline.

    Find out the screen shot below.

    Wednesday, March 9, 2016

    Relevance Ranking Modules in Endeca

    Relevance Ranking controls the order in which search results are displayed to the end user . You configure the Relevance Ranking feature to ... thumbnail 1 summary
    • Relevance Ranking controls the order in which search results are displayed to the end user . You configure the Relevance Ranking feature to display the most important search results earliest to the user.

    Relevance ranking can be used to independently control the result ordering for both record search and dimension search queries.

    The importance of a search result is generally an application-specific.The Relevance Ranking feature provides a flexible, configurable set of result ranking modules to build application specific ranking.

    Relevance raking can be applied using search interface or passing algorithm while building query.
    Site specific relevance ranking can be applied as well using results list cartridge or passing at query time.

    Followings are available set of Relevance Ranking modules and their ranking behaviors.

    Exact

    Provides a finer grained but more expansive alternative.
    Groups the results into three strata.
    1.      Highest stratum contains results whose complete text matches the user’s query exactly.
    2.      Middle stratum contains results that contain the user’s query as a sub phrase.
    3.      Lowest stratum contains other match types such as normal conjunctive matches.
    Use only on small text fields such as dimension values or small property values like part IDs


    Field

    Ranks documents based on the search interface field with the highest priority in which it matched.
    Useful in relevance ranking strategies for catalog applications.
    Assigns a score to each result based on the static rank of the dimension or property member or members of the search interface that caused the document to match the query.
    Valid only for record search operations.
    Assigns a score of zero to all results for other types of search requests.
    Treats all matches the same, whether or not they are due to query expansion.


    First

    Designed primarily for use with unstructured data.
    Ranks documents by how close the query terms are to the beginning of the document.
    Groups its results into variably-sized strata.
    Takes advantages of the fact that the closer something is to the beginning of a document, the more likely it is to be relevant.
    When the query has a single term, the First module behavior is straight-forward:
    -        It retrieves the first absolute position of the word in the document, then calculates which stratum contains that position.
    When the query has multiple terms, the First module behaves as follows:
    -        The first absolute position for each of the query terms is determined, and then the median position of these positions is calculated.
    Supports wildcard queries.
    Does not work with Boolean searches and cross-field matching.



    Freq

    Provides result scoring based on the frequency of the user’s query terms in the result text
    Score produced for a result record is the sum of the frequencies of all user search terms in all fields that match a sufficient number of terms
    Number of terms depends on the match mode
    Cross-field match records are assigned a score of zero
    Ignores matches due to query expansion



    Glom

    Ranks single-field matches ahead of cross-field matches and also ahead of records that do not contain the search term at all
    Tie-breaker function in combination with the Maxfield module
    Only useful with record search operations
    Treats all matches the same, whether or not they are due to query expansion



    Interp

    General-purpose module that assigns a score to each result record based on the query processing techniques used to obtain the match.
    Ranks results as follows:
    All non-partial matches are ranked ahead of all partial matches
    All single-field matches are ranked ahead of all cross-field matches
    All non-spelling-corrected matches are ranked above all spelling-corrected matches
    All thesaurus matches are ranked below all non-thesaurus matches
    All stemming matches are ranked below all non-stemming matches.



    MaxField

    Behaves like the field module, except in how it scores cross-field matches.
    Selects the score of the highest-ranked field that contributed to the match.
    Valid only for record search operations.
    Treats all matches the same, whether or not they are due to query expansion.



    Nterms

    Ranks matches according to how many query terms they match.
    Only applicable to search modes where results can vary in how many query terms they match.
    Treats all matches the same, whether or not they are due to query expansion.



    Numfields

    Ranks results based on the number of fields in the associated search interface in which a match occurs.
    Treats all matches the same, whether or not they are due to query expansion.
    Only useful with record search operations.



    Phrase

    Ranks results containing the user’s query as an exact phrase, or a subset of the exact phrase.
    Records that have the phrase are ranked higher than records which do not contain the phrase.
    Three options that you can use to customize its behavior:
    1.   Rank based on length of sub-phrases
    2.   Use approximate sub-phrase/phrase matching
    Apply spell correction, thesaurus, and stemming.




    Proximity

    Designed primarily for use with unstructured data.
    Ranks how close the query terms are to each other in a document by counting the number of intervening words.
    Groups its results into variable sized strata.
    When the query has multiple terms, Proximity behaves as follows:
    -        All of the absolute position for each of the query terms are computed
    -        The smallest range that includes at least one instance of each of the query terms is calculated
    -        This range’s length is given in number of words
    -        The score for each document is the strata that contains the difference of the range’s length and the number of terms in the query
    -        Smaller differences are better than larger differences
    Under stemming, spelling correction, and the thesaurus, the expanded terms are treated as if they were in the query.
    Proximity scores partially matched queries as if the query only contained the matching terms.
    Does not work with Boolean searches, cross-field matching, or wildcard searches.



    Spell

    Ranks spelling-corrected matches below other kinds of matches
    Assigns a rank of zero to matches from spelling correction, and a rank of one from all other sources
    Ignores all other sorts of query expansion.



    Static

    Assigns a static or constant data-specific value to each search result
    For record search operations, the first parameter to the module specifies a property, which defines the sort order assigned by the module
    The second parameter can be specified as ascending or descending to indicate the sort order to use for the specified property
    In a catalog application, setting the static module by Price, descending leads to more expensive products being displayed first.
    For dimension search, the first parameter can be specified as nbins, depth, or rank.


    Stem

    Ranks stemming matches below other kinds of matches
    Assigns a rank of zero to matches from stemming, and a rank of one from all other sources
    Ignores all other sorts of query expansion


    Stratify

    Used to boost or bury records in the result set
    Takes one or more Endeca Query Language (EQL) expressions and groups results into strata
    Records are placed in the stratum associated with the first EQL expression they match
    If an asterisk is specified instead of an EQL expression, unmatched records are placed in the corresponding stratum
    Basic component of the record boost and bury feature



    Thesaurus

    Ranks thesaurus matches due to below other sorts of matches.
    Thesaurus assigns a rank of zero to matches from the thesaurus, and a rank of one from all other sources.
    Ignores all other sorts of query expansion.



    Weighted Feq

    Scores results based on the frequency of user query terms in the result
    Weights the individual query term frequencies for each result by the overall frequency in the complete data set of each query term
    Terms resulting in fewer search results are weighted more heavily than more frequently occurring terms
    Ignores matches due to query expansion

    Text Widget