I can't seem to find the right formula for this. I have a need to build a
query where one of the fields should boost the score, but not affect the
query if there isn't a match. For example, if I have documents with
restaurants, name, address, cuisine, description, etc.  I want to search on,
say,

Romantic AND View AND city:Chicago

if city is in fact Chicago it should score higher, but if city is not
Chicago (or even if it's missing the city field), but matches the other
query parameters it should still come back in the results. Is something like
this possible?  It's kind of like  q=(some query) optional boost if
field:value.

Thanks,
Ken
--
View this message in context: http://lucene.472066.n3.nabble.com/Query-question-tp1828367p1828367.html
Sent from the Solr - User mailing list archive at Nabble.com.

I think you'll find the dismax request handler helpful in general, it
supports more flexible query wrangling like that.

With the dismax request handler, I think the bq (boost query) parameter
will do what you need, eg:

 bq=city:Chicago^5.0

The ^5.0 is how much boost you want, you can play around with it to see
what works well for your use cases.

http://wiki.apache.org/solr/DisMaxQParserPlugin

kenf_nc wrote:
> I can't seem to find the right formula for this. I have a need to build a
> query where one of the fields should boost the score, but not affect the
> query if there isn't a match. For example, if I have documents with
> restaurants, name, address, cuisine, description, etc.  I want to search on,
> say,
>
> Romantic AND View AND city:Chicago
>
> if city is in fact Chicago it should score higher, but if city is not
> Chicago (or even if it's missing the city field), but matches the other
> query parameters it should still come back in the results. Is something like
> this possible?  It's kind of like  q=(some query) optional boost if
> field:value.
>
> Thanks,
> Ken
>

Do you want something like (Romantic AND View) OR city:Chicago^10?

Best
Erick

On Tue, Nov 2, 2010 at 10:45 AM, kenf_nc <[EMAIL PROTECTED]> wrote:

>
> I can't seem to find the right formula for this. I have a need to build a
> query where one of the fields should boost the score, but not affect the
> query if there isn't a match. For example, if I have documents with
> restaurants, name, address, cuisine, description, etc.  I want to search
> on,
> say,
>
> Romantic AND View AND city:Chicago
>
> if city is in fact Chicago it should score higher, but if city is not
> Chicago (or even if it's missing the city field), but matches the other
> query parameters it should still come back in the results. Is something
> like
> this possible?  It's kind of like  q=(some query) optional boost if
> field:value.
>
> Thanks,
> Ken
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Query-question-tp1828367p1828367.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>

Jonathan, Dismax is something I've been meaning to look into, and bq does
seem to fit the bill, although I'm worried about this line in the wiki
 :TODO:  That latter part is deprecated behavior but still works. It can be
problematic so avoid it.
It still seems to be the closest to what I want however so I'll play with
it.

Erick, that query would return all restaurants in Chicago, whether they
matched Romantic View or not. Although the scores should sort relevant
results to the top, the results would still contain a lot of things I wasn't
interested in.
--
View this message in context: http://lucene.472066.n3.nabble.com/Query-question-tp1828367p1828639.html
Sent from the Solr - User mailing list archive at Nabble.com.

Don't worry about that line.  It just means that one particular kind of
'default' behavior in bq shouldn't be relied upon, if you don't entirely
understand that behavior they're saying is deprecated (as I don't
either!) anyway, don't worry about it, just supply an explicit boost in
your bq.

bq isn't going anywhere, it is a stable and well-used part of dismax.

kenf_nc wrote:
> Jonathan, Dismax is something I've been meaning to look into, and bq does
> seem to fit the bill, although I'm worried about this line in the wiki
>  :TODO:  That latter part is deprecated behavior but still works. It can be
> problematic so avoid it.
> It still seems to be the closest to what I want however so I'll play with
> it.
>
> Erick, that query would return all restaurants in Chicago, whether they
> matched Romantic View or not. Although the scores should sort relevant
> results to the top, the results would still contain a lot of things I wasn't
> interested in.
>

I... Need... more... coffee.....

On Tue, Nov 2, 2010 at 11:31 AM, kenf_nc <[EMAIL PROTECTED]> wrote:

>
> Jonathan, Dismax is something I've been meaning to look into, and bq does
> seem to fit the bill, although I'm worried about this line in the wiki
>  :TODO:  That latter part is deprecated behavior but still works. It can be
> problematic so avoid it.
> It still seems to be the closest to what I want however so I'll play with
> it.
>
> Erick, that query would return all restaurants in Chicago, whether they
> matched Romantic View or not. Although the scores should sort relevant
> results to the top, the results would still contain a lot of things I
> wasn't
> interested in.
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Query-question-tp1828367p1828639.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>

> Erick, that query would return all restaurants in Chicago,
> whether they
> matched Romantic View or not. Although the scores should
> sort relevant
> results to the top, the results would still contain a lot
> of things I wasn't
> interested in.

How about this one?

+(city:Chicago^1000 OR (*:* -city:Chicago)) +Romantic +View

My impression was that

city:Chicago^10 +Romantic +View

would do what you want (with the standard lucene query parser and
default operator OR), and I'm not sure about this, but I have a feeling
that the version with "Boolean" operators AND/OR and parens might
actually net out to the same thing, since under the hood all the terms
have to be translated into "optional", "required" or "forbidden": lucene
doesn't actually have true binary boolean operators.  At least that was
the impression I got after some discussion at a recent conference.  I
may have misunderstood - if so, could someone who knows set me straight?

Thanks

-Mike

On 11/2/2010 5:08 PM, Ahmet Arslan wrote:
>> Erick, that query would return all restaurants in Chicago,
>> whether they
>> matched Romantic View or not. Although the scores should
>> sort relevant
>> results to the top, the results would still contain a lot
>> of things I wasn't
>> interested in.
> How about this one?
>
> +(city:Chicago^1000 OR (*:* -city:Chicago)) +Romantic +View
>
>
>

> My impression was that
>
> city:Chicago^10 +Romantic +View
>
> would do what you want (with the standard lucene query
> parser and default operator OR), and I'm not sure about
> this, but I have a feeling that the version with "Boolean"
> operators AND/OR and parens might actually net out to the
> same thing, since under the hood all the terms have to be
> translated into "optional", "required" or "forbidden":
> lucene doesn't actually have true binary boolean
> operators.  At least that was the impression I got
> after some discussion at a recent conference.  I may
> have misunderstood - if so, could someone who knows set me
> straight?

Yes, you are completely right. If the default operator is set to OR, your query would do the trick. And it is better to use and think in terms of unitary operators.

Unfortunately the default operator is set to AND and I can't change that at
this time.

If I do  (city:Chicago^10 OR Romantic OR View) it returns way too many
unwanted results.
If I do (city:Chicago^10 OR (Romantic AND View)) it returns less unwanted
results, but still a lot.
iorixxx's solution of (Romantic AND View AND (city:Chicago^10 OR (*:*
-city:Chicago))) does seem to work. Chicago results are at the top, and the
remaining results seem to fit the other search parameters. It's an ugly
query, but does seem to do the trick for now until I master Dismax.

Thanks all!

--
View this message in context: http://lucene.472066.n3.nabble.com/Query-question-tp1828367p1834793.html
Sent from the Solr - User mailing list archive at Nabble.com.

Another alternative (prettier to my eye), would be:

(city:Chicago AND Romantic AND View)^10 OR (Romantic AND View)
-Mike

On 11/03/2010 09:28 AM, kenf_nc wrote:
> Unfortunately the default operator is set to AND and I can't change that at
> this time.
>
> If I do  (city:Chicago^10 OR Romantic OR View) it returns way too many
> unwanted results.
> If I do (city:Chicago^10 OR (Romantic AND View)) it returns less unwanted
> results, but still a lot.
> iorixxx's solution of (Romantic AND View AND (city:Chicago^10 OR (*:*
> -city:Chicago))) does seem to work. Chicago results are at the top, and the
> remaining results seem to fit the other search parameters. It's an ugly
> query, but does seem to do the trick for now until I master Dismax.
>
> Thanks all!
>
>

Another option is to override the default operator in the query.

{!lucene q.op=OR}city:Chicago^10 +Romantic +View

Colin.

> -----Original Message-----
> From: Mike Sokolov [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 03, 2010 9:42 AM
> To: [EMAIL PROTECTED]
> Cc: kenf_nc
> Subject: Re: Query question
>
> Another alternative (prettier to my eye), would be:
>
> (city:Chicago AND Romantic AND View)^10 OR (Romantic AND View)
>
>
> -Mike
>
>
>
> On 11/03/2010 09:28 AM, kenf_nc wrote:
> > Unfortunately the default operator is set to AND and I can't change
> that at
> > this time.
> >
> > If I do  (city:Chicago^10 OR Romantic OR View) it returns way too
> many
> > unwanted results.
> > If I do (city:Chicago^10 OR (Romantic AND View)) it returns less
> unwanted
> > results, but still a lot.
> > iorixxx's solution of (Romantic AND View AND (city:Chicago^10 OR (*:*
> > -city:Chicago))) does seem to work. Chicago results are at the top,
> and the
> > remaining results seem to fit the other search parameters. It's an
> ugly
> > query, but does seem to do the trick for now until I master Dismax.
> >
> > Thanks all!
> >
> >

Howdy,

I have a straight-forward index that contains a "name" field. I am currently
taking a string of text, tokenizing it into individual strings and making a
query out of them all against the "name" field.

Note that the name field is split up by a whitespace tokenizer and a lower
case filter during indexing.

My query is working fine but I want to boost the score when multiple terms
match. So for example if I had an entry in my index that was originally
"Valley Fair Mall" and the string I was using to search was "I'm shopping at
Valley Fair mall" my query is currently being chopped into:
name:i'm~ name:shopping~ name:at~ name:valley~ name:fair~ name:mall~

Note that I use OR by default.

So as I said, the search result I want is the one with the highest score,
but I was hoping to find a way to boost the score based on the number of
terms it finds (or matches well) so that I can differentiate between a close
match and nowhere near. Any suggestions?

Regards,

T

--
View this message in context: http://lucene.472066.n3.nabble.com/Query-question-tp4040559.html
Sent from the Solr - User mailing list archive at Nabble.com.