Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Fri, 20 May 2011 11:56:47 +0000 (UTC)
From: "Koji Sekiguchi (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <1722081762.30275.1305892607422.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (SOLR-1878) RelaxQueryComponent - A new
 SearchComponent that relaxes the main query in a semiautomatic way
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SOLR-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036790#comment-13036790 ] 

Koji Sekiguchi commented on SOLR-1878:
--------------------------------------

Today I met a consultant and he told me the interesting idea about executing the relax query. His idea is quite simple, using {!tag} and {!ex}. For example:

{code}
q=*:*
&fq={!tag=re}rent:[* TO 1500]     # condition set by user
&fq={!tag=fl}floor:[100 TO *]     # condition set by user
&facet.query={!ex=re}rent:[* TO 1700]   # expanded condition
&facet.query={!ex=re}rent:[* TO 2000]   # expanded condition
&facet.query={!ex=fl}floor:[90 TO *]    # expanded condition
&facet.query={!ex=fl}floor:[80 TO *]    # expanded condition
{code}

Client should set the expanded (relaxed) condition. Client should also see the response and decide whether display the relaxed facet count or not.

In the original description of this issue, I'd say semiautomatic, but no automatic here. But I like it because of no need additional implementation.

> RelaxQueryComponent - A new SearchComponent that relaxes the main query in a semiautomatic way
> ----------------------------------------------------------------------------------------------
>
>                 Key: SOLR-1878
>                 URL: https://issues.apache.org/jira/browse/SOLR-1878
>             Project: Solr
>          Issue Type: New Feature
>          Components: SearchComponents - other
>    Affects Versions: 1.4
>            Reporter: Koji Sekiguchi
>            Priority: Minor
>
> I have the following use case:
> Imagine that you visit a web page for searching an apartment for rent. You choose parameters, usually mark check boxes and this makes AND queries:
> {code}
> rent:[* TO 1500] AND bedroom:[2 TO *] AND floor:[100 TO *]
> {code}
> If the conditions are too tight, Solr may return few or zero leasehold properties. Because the things is not good for the site visitors and also owners, the owner may want to recommend the visitors to relax the conditions something like:
> {code}
> rent:[* TO 1700] AND bedroom:[2 TO *] AND floor:[100 TO *]
> {code}
> or:
> {code}
> rent:[* TO 1500] AND bedroom:[2 TO *] AND floor:[90 TO *]
> {code}
> And if the relaxed query get more numFound than original, the web page can provide a link with a comment "if you can pay additional $100, ${numFound} properties will be found!".
> Today, I need to implement Solr client for this scenario, but this way makes two round trips for showing one page and consistency problem (and laborious of course!).
> I'm thinking a new SearchComponent that can be used with QueryComponent. It does search when numFound of the main query is less than a threshold. Clients can specify via request parameters how the query can be relaxed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org