[
https://issues.apache.org/jira/browse/SOLR-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15012182#comment-15012182
]
Markus Jelsma commented on SOLR-7539:
-------------------------------------
Hi Ted - i've read the code and your posts about this awesome feature but never
really knew how to apply it in real world apps without a.o. the problem pointed
out by jmlucjav. So regarding the current solution on that very problem; i feel
it would introduce a cumbersome maintenance hazard to any shop or catalog site
that has non trivial data, so probably most :)
This solution would require very frequent maintenance for any index that is
fueled by users or automatically as new examples of said exceptions come and go
and are not easy to spot.
Is it not a simpler idea to detect these ambiguities and not filter, but emit
the ambiguities to the ResponseBuilder so applications can deal with it? You
have the control of the SearchComponent so you can let app developers ask the
question to users, do you want the performer, or the writer?
In any case, filtering is bad here, boosting both writer and performer may be
another (additional) solution to deal with ambiguities. I fear labour intense
maintenance yields this cool feature unusable.
What do you think?
M.
> Add a QueryAutofilteringComponent for query introspection using indexed
> metadata
> --------------------------------------------------------------------------------
>
> Key: SOLR-7539
> URL: https://issues.apache.org/jira/browse/SOLR-7539
> Project: Solr
> Issue Type: New Feature
> Reporter: Ted Sullivan
> Priority: Minor
> Fix For: Trunk
>
> Attachments: SOLR-7539.patch, SOLR-7539.patch, SOLR-7539.patch,
> SOLR-7539.patch
>
>
> The Query Autofiltering Component provides a method of inferring user intent
> by matching noun phrases that are typically used for faceted-navigation into
> Solr filter or boost queries (depending on configuration settings) so that
> more precise user queries can be met with more precise results.
> The algorithm uses a "longest contiguous phrase match" strategy which allows
> it to disambiguate queries where single terms are ambiguous but phrases are
> not. It will work when there is structured information in the form of String
> fields that are normally used for faceted navigation. It works across fields
> by building a map of search term to index field using the Lucene FieldCache
> (UninvertingReader). This enables users to create free text, multi-term
> queries that combine attributes across facet fields - as if they had searched
> and then navigated through several facet layers. To address the problem of
> exact-match only semantics of String fields, support for synonyms (including
> multi-term synonyms) and stemming was added.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
