Mailing-List: contact lucene-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Lucene Users List" <lucene-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
From: Paul Elschot <paul.elschot@xs4all.nl>
To: lucene-user@jakarta.apache.org
Subject: Re: Query#rewrite Question
Date: Thu, 11 Nov 2004 09:10:32 +0100
User-Agent: KMail/1.5.4
References: <005b01c4c799$674e1270$32e0fcca@satoshiobtu4n6>
In-Reply-To: <005b01c4c799$674e1270$32e0fcca@satoshiobtu4n6>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200411110910.32745.paul.elschot@xs4all.nl>


On Thursday 11 November 2004 03:51, Satoshi Hasegawa wrote:
> Hello,
> 
> Our program accepts input in the form of Lucene query syntax from the user, 
> but we wish to perform additional tasks such as thesaurus expansion. So I 
> want to manipulate the Query object that results from parsing.
> 
> My question is, is the result of the Query#rewrite method guaranteed to be 
> either a TermQuery, a PhraseQuery, or a BooleanQuery, and if it is a 
> BooleanQuery, do all the constituent clauses also reduce to one of the above 
> three classes? If not, what if the original Query object was the one that 
> was obtained from QueryParser#parse method? Can I assume the above in this 
> restricted case?
>
> I experimented with the current version, and the above seems to be positive 
> in this version; I'm asking if this could change in the future. Thank you. 
 
In general, a Query should either rewrite to another query, or provide a
Weight. During search, the Weight then provides a Scorer to score the docs.

The only other type of query currently available is SpanQuery, which is
a generalization of PhraseQuery. It does not rewrite and provides a Weight.

However, the current QueryParser does not have support for SpanQuery.
So, as long as the QueryParser does not support more than the current types
of queries, and you only use the QueryParser to obtain queries, all the
constituent clauses will reduce as you indicate above.

SpanQuery could be useful for thesaurus expansion. The generalization
it provides is that it allows nested distance queries. For example, in:
"word1 word2"~2
word2 can expanded to:
word2 or "word3 word4"~4
leading to a query that is not supported by the current QueryParser:
"word1 (word 2 or "word3 word4"~4)"~2

SpanQueries can also enforce an order on the matching subqueries,
but that is difficult to express in the current query syntax.

Regards,
Paul Elschot


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