[
https://issues.apache.org/jira/browse/SOLR-6878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14524285#comment-14524285
]
Hoss Man commented on SOLR-6878:
--------------------------------
the "expand" option in the original SynonymFilterFactory was/is really just
about allowing brevity for symetric synonyms in the data file -- the best
approach for the API is to tackle the same problem.
Instead of thinking about "expand" as a stateful option in
ManagedSynonymFilterFactory (or worse, an _immutabe_ stateful option), i would
suggest that instead it should just be a (transient) property of the request to
add to / create the synonyms mappings -- one that doesn't even need to be
explicit, since the list syntax already makes it clear.
today, if someone sends a map of "KEY => LIST-OF(VALUES)" to the API, we
interpret that as "for each KEY, for each VALUE in LIST-OF(VALUES), add a
synonym mapping of KEY=>VALUE" and later if the user asks to GET mappings or
delete mappings they do so by KEY.
why not let the new "expand" feature just be syntactic sugar on adding symetric
sets of KEY=>VALUE mappings via lists of lists?
if a user is creating or adding to a synonym mapping with a
"LIST-OF(LIST-OF(VALUES))" then let the logic be: "for each LIST-OF(VALUES) in
the outer LIST, loop over the inner LIST and add a mapping from every VALUE =>
ever other VALUE in the same inner LIST"
it should be purely syntactic sugar -- GET requests should make it clear how
the data is internally modeled.
bq. What should the API do if the user then decides to update the specific
mappings for "funny" by sending in a request such as ...
we update that exact mapping, and no other mappings are changed --
update/delete requests should operate on individual keys, regardless of what
type of request added those keys.
----
The (more complex) alternative is to create a much more general abstraction of
"synonym dictionary entries" where each entry is either a "one way mapping" or
a "multi directional mapping" ... so that we internally track & remember that
the user gave us some set of one way mappings like \{'mad': \['angry'\]\} and
also gave us a set of multi directional mappings as lists like
\['funny','jocular','whimiscal'\] and support some new syntax for saying "i
want to edit the list i previously gave you which contains 'jocular' such that
it no longer contains 'whimiscal' but now contains 'happy'" and also have
sanity checks in place to prevent people from trying to mix the two.
but i think (as you alluded to above) that way leads to madness.
> solr.ManagedSynonymFilterFactory all-to-all synonym switch (aka. expand)
> ------------------------------------------------------------------------
>
> Key: SOLR-6878
> URL: https://issues.apache.org/jira/browse/SOLR-6878
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
> Affects Versions: 4.10.2
> Reporter: Tomasz Sulkowski
> Assignee: Timothy Potter
> Labels: ManagedSynonymFilterFactory, REST, SOLR
> Attachments: SOLR-6878.patch
>
>
> Hi,
> After switching from SynonymFilterFactory to ManagedSynonymFilterFactory I
> have found out that there is no way to set an all-to-all synonyms relation.
> Basically (judgind from google search) there is a need for "expand"
> functionality switch (known from SynonymFilterFactory) which will treat all
> synonyms with its keyword as equal.
> For example: if we define a "car":["wagen","ride"] relation it would
> translate a query that includes one of the synonyms or keyword to "car or
> wagen or ride" independently of which word was used from those three.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
