lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yonik Seeley <>
Subject Re: "Advanced" query language
Date Tue, 06 Dec 2005 16:21:58 GMT
On 12/6/05, Erik Hatcher <> wrote:
> Suppose a user of the Swing or RoR client enters "some phrase", who
> is responsible for analyzing that phrase so that it is suitable for
> PhraseQuery.add()?  Right?

Right, and even more.  The query one specifies may be morphed into
another type since the analysis phase can produce multiple tokens out
of one, and can produce multiple tokens at the same position (as well
as stopping out words, etc).

<TermQuery field="foo">laptop</TermQuery>
  with a synonym filter, would end up parsed into (using the current syntax)
foo:laptop foo:notebook


<TermQuery field="foo">WiFi</TermQuery>
  with a case-change splitter could end up as
foo:wifi foo:"wi fi"

That's what I meant about a lot of the QueryParser logic needing to be

> I'm currently thinking that we want to support both the client and
> the server having this option.

The server side is a must.  Can't have all the clients having to
duplicate the logic and stay in sync with how things were indexed.

> A client definitely must be able to
> construct a phrase query in XML precisely with each term (all XML
> just for example, no endorsement implied):
>         <PhraseQuery slop="3">
>                 <Term field="fieldname" value="some"/>
>                 <Term field="fieldname" value="phrase"/>
>         </PhraseQuery>
> but we should also allow for the client to push the analysis
> responsibility to the server:

I agree that level of control is needed, but the server side analysis
still needs to be done right (stemming, stopping, etc)

There may be an option to not do analysis in the event that it was
already done (that's the easier part of all of this).

>         <PhraseQuery slop="3">
>                 <Phrase analyzer="StandardAnalyzer">some phrase</Phrase>
>         </PhraseQuery>

Hmmm, I had thought it working like the current QueryParser... you
give it an Analyzer, and it knows about how to treat the different
fields.  Explicitly specifying it is interesting, but should be

> Interesting topic, even if this isn't what you originally meant Yonik :)

I think it was what I meant... I realized this isn't just query
serialization.  To be useful, all the related analysis stuff must be


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message