Update engine.json

[r4sn4]

representation of exclude field in engine.json and in query .
similar to "fields" param in engine.json and query

[pferrel]

I assume this is a proposal for how to configure exclusion rules? Looks good. These will then go into the should_not part of the Elasticsearch query exactly as encoded in the field values. This will allow "ands" and "ors" of fields.

When single valued arrays of strings are in should_not these are anded, meaning the presence of all of the excluded field values will disallow the item from recommendations where putting all the values in one array will mean the presence of any one of the values will disallow the item.

The same happens now with the inclusion rules.

[r4sn4]

I added this considering the fact that we want to completely exclude
products having certain properties.
In this case as well presence of excluded fields will disallow the item
from recommendation?

Could you please explain your case what you mean by this - "When single
valued arrays of strings are in should_not these are anded, meaning the
presence of all of the excluded field values will disallow the item from
recommendations where putting all the values in one array will mean the
presence of any one of the values will disallow the item."???

On Sat, Nov 5, 2016 at 10:08 PM, Pat Ferrel [email protected]
wrote:

I assume this is a proposal for how to configure exclusion rules? Looks
good. These will then go into the should_not part of the Elasticsearch
query exactly as encoded. This will allow "ands" and "ors" of fields.

When single valued arrays of strings are in should_not these are anded,
meaning the presence of all of the excluded field values will disallow the
item from recommendations where putting all the values in one array will
mean the presence of any one of the values will disallow the item.

The same happens now with the inclusion rules.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#27 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIA1E0q8-EQR5KbZYXpei65nwJNL1EdDks5q7LD3gaJpZM4KmdKO
.

[r4sn4]

Any further suggestion for numeric range filter?
What are the gaps in it as well?

On Sun, Nov 6, 2016 at 11:31 AM, Rasna Tomar [email protected] wrote:

I added this considering the fact that we want to completely exclude
products having certain properties.
In this case as well presence of excluded fields will disallow the item
from recommendation?

Could you please explain your case what you mean by this - "When single
valued arrays of strings are in should_not these are anded, meaning the
presence of all of the excluded field values will disallow the item from
recommendations where putting all the values in one array will mean the
presence of any one of the values will disallow the item."???

On Sat, Nov 5, 2016 at 10:08 PM, Pat Ferrel [email protected]
wrote:

I assume this is a proposal for how to configure exclusion rules? Looks
good. These will then go into the should_not part of the Elasticsearch
query exactly as encoded. This will allow "ands" and "ors" of fields.

When single valued arrays of strings are in should_not these are anded,
meaning the presence of all of the excluded field values will disallow the
item from recommendations where putting all the values in one array will
mean the presence of any one of the values will disallow the item.

The same happens now with the inclusion rules.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#27 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIA1E0q8-EQR5KbZYXpei65nwJNL1EdDks5q7LD3gaJpZM4KmdKO
.

[pferrel]

A: The logic of how filters work in Elasticsearch is that arrays of values are ORed, and single fields are ANDed.

That aside is this a proposal for how exclusion by field might be encoded? Since there is no actual code a change to engine.json would be incomplete.

If so then one question is how exclusion and inclusion should be mixed. For this reason I think I'd favor making "include" and/or "exclude" a param of field rather than creating a separate list, where it would be difficult to think about how and exclude relates to other fields that might be included.

At the same time we've been thinking about changing the bias to be used only for boosting and adding the new param "filter" as a substitute for bias < 0, which seems to confuse people--perhaps rightly so. To remove ourselves from the old encoding bias would be renamed "boost"

This would make the possible config look like this:

"fields": [
      {
        “name”: ”fieldname”,
        “values”: [“fieldValue1”, ...],
        “boost”: 0..maxFloat or  "filter": true,
        "include": true | false or  "exclude": true | false,
      },...
    ]
  }

If these are used then config errors are easily seen and reported. For instance bias: 5, filter: true would contradict and could be reported as well as include: true and exclude: true.

What do you think?

[r4sn4]

Thanks for your response. Which code do you mean by this "Since there is no actual code a change to engine.json would be incomplete"? Do you mean that inclusion and exclusion should be achived by single field rather introducing different field for exlusion in engine.json. If so, ye this is possible. As per my understanding different use cases are as follows - 1) only include items from certain fields - "fields": [ { “name”: ”fieldname”, “values”: [“fieldValue1”, ...], "filter": true, "include": true },... ] } 2) boost items from certain fields "fields": [ { “name”: ”fieldname”, “values”: [“fieldValue1”, ...], “boost”: 0..maxFloat, },... ] } 3) boost some fields while exclude recommendations from particular fields completely. fields": [ { “name”: ”fieldname”, “values”: [“fieldValue1”, ...], “boost”: 0..maxFloat or "filter": true, "include": true | false or "exclude": true | false, }, { “name”: ”fieldname”, “values”: [“fieldValue1”, ...], "filter": true, "exclude": true, } ] } 4) exclude certain fields "fields": [ { “name”: ”fieldname”, “values”: [“fieldValue1”, ...], "filter": true, "exclude": true, },... ] } Mixing inclusion and exclusion in single engine.json param is achievable. Is this what you mean? Regards Rasna Tomar

…

On Mon, Nov 21, 2016 at 2:54 AM, Pat Ferrel ***@***.***> wrote: A: The logic of how filters work in Elasticsearch is that arrays of values are ORed, and single fields are ANDed. That aside is this a proposal for how exclusion by field might be encoded? Since there is no actual code a change to engine.json would be incomplete. If so then one question is how exclusion and inclusion should be mixed. For this reason I think I'd favor making "include" and/or "exclude" a param of field rather than creating a separate list, where it would be difficult to think about how and exclude relates to other fields that might be included. At the same time we've been thinking about changing the bias to be used only for boosting and adding the new param "filter" as a substitute for bias < 0, which seems to confuse people--perhaps rightly so. To remove ourselves from the old encoding bias would be renamed "boost" This would make the possible config look like this: "fields": [ { “name”: ”fieldname”, “values”: [“fieldValue1”, ...], “boost”: 0..maxFloat or "filter": true, "include": true | false or "exclude": true | false, },... ] } If these are used then config errors are easily seen and reported. For instance bias: 5, filter: true would contradict and could be reported as well as include: true and exclude: true. What do you think? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#27 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIA1E2L-7PH2YFRQeYX2YuiQOcYopc2iks5rALqOgaJpZM4KmdKO> .