[
https://issues.apache.org/jira/browse/SOLR-12581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16553510#comment-16553510
]
Hoss Man commented on SOLR-12581:
---------------------------------
bq. Sort of a side-question, but this work seems to overlap/compliment the
significantTerms ..
That does seem very tangential, but important to consider – so i spun it off
into SOLR-12582. One key aspect of my comments there that is directly
signifincat to this issue is the question of the name "min_popularity" and
wether it makes sense to re-think that...
{quote}as far as trying to maintain the same option names – i don't know that
that is feasible or really makes sense – at least in so much as adding new
options to relatedness() using hte same names as the existing options on
significantTerms. notably the existing {{minDocFreq}} option on
significantTerms is similar _in concept_ to the {{min_popularity}} option
proposed in SOLR-12581 for relatedness(), but it would not really make sense to
use {{minDocFreq}} as the option name in SOLR-12581 since the relatedness()
function isn't tied to "terms" the way significantTerms is – so "docFreq" has
no real meaning, and the more general "popularity" makes more sense (i suppose
we could change the option name in signifncatTerms – but even then
significantTerms doesn't produce the same concept of "popularity" that
relatedness() does, andeven if it did because that that expression focuses
exclusively on "terms" the concept of "DocFreq" is very appropriate.
{quote}
> add a "min_popularity" option to relatedness() aggregation that forces scores
> to -Inf if fg/bg pops don't meet a threshold
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-12581
> URL: https://issues.apache.org/jira/browse/SOLR-12581
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Assignee: Hoss Man
> Priority: Major
> Attachments: SOLR-12581.patch
>
>
> as discussed in SOLR-9480 and noted in TODO comments, the original SKG code
> base had a "min_pop" option that would completely ignore "terms" if the fg/bg
> popularities weren't above a user specified threshold. with the
> implementation of SKG as a {{relatedness()}} aggregation function, we need to
> leave any actual filtering of buckets by an aggregation result to a future
> generalized JSON facet enhancement, but what we can do today is implement an
> optional {{min_popularity}} option on {{relatedness()}} that forces the
> {{relatedness}} score to -Infinity so buckets that don't meat the threshold
> at least score "as low as possible"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
