On Apr 30, 2009, at 13:01, Sanne Grinovero wrote:
Basically I need a function to convert a user-proposed term to a
series of proposals
of "similar" terms but giving a higher rank to the terms I'd prefer
him to choose as they
are the correct names used in my domain.
You can think of it as a spellchecker/dictionary (using synonyms
toos), but giving priority to
a selected form of each term, known as the "root", or the standard
form in the domain.
Have you considered indexing the same property twice:
- once unaltered and giving it a high boost
- once with synonyms and giving it a low boost
That's how I would sove your use case personally.
This is the simple explanation which I believe is useful in all
indexing modes;
actually I'm also going to use it for the 2 reasons you are
listing, and it's not a problem for me as I rebuild the index
regularly and prefer for
several reasons to pre-compute the boosts needed for "categories in
marketing mood"
and "fade by age" effects.
2009/4/30 Emmanuel Bernard <emman...@hibernate.org>:
What's your use case?
I am not against that feature but I don't think it covers all use
cases:
- I want a higher boost for more recent documents
- I change priority in my categories depending on the marketing mood
Said otherwise, can have a true dynamic boost defined at query
time, not at
indexing time.
I think Solr has something named FunctionQuery that can do that.
On Apr 29, 2009, at 16:47, Sanne Grinovero wrote:
Hello,
I'm currently needing to be able to define a per-entity INSTANCE
different Boost, not just the type.
Currently I could obtain this functionality by using a custom
classbridge, but the entity is quite complex and building my own
classbridge I will have to map all fields myself loosing the
flexibility of annotations for the current type and
all @IndexedEmbedded.
I'd like to add a new parameter to @Boost; currently it has a float
mandatory value,
I'd like to add a new parameter:
Class<BoostScorer> impl();
where BoostScorer is an interface having something like
public float score(Object value);
The annotation would default to an implementation returning
constant 1.0f.
This would have an interaction with the existing "value" parameter:
IMHO they should
multiply each other, so I'd change the existing value to also have a
default of 1.0f
and people might want to change one or both values.
Setting both values might be useful to reuse the same impl on
different types/fields
and still be able to statically scale the result from the
score(Object) function, without having to
rewrite a new implementation.
What do you think?
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
