lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ype Kingma <>
Subject Re: Status of proximity in query language
Date Tue, 19 Feb 2002 18:52:08 GMT
Dear developers,

> > These are situation where the end user who is using this syntax has to know
>> the limitations and options.
>Right, but that's no excuse for creating more of these situations,
>especially one as egregious as introducing an infix operator that
>_looks_ like it should work with arbitrary operands but doesn't.
>That's like offering a desk calculator with a + button that only adds
>even numbers. 
>Lets not lose sight of something: the query parser is a peripheral
>element of lucene; it converts text representation of queries into the
>internal representation.  No one _has_ to use it.  Its supposed to be
>a convenient first-order approximation that is good enough for most
>> In my user documentation
>We can't assume every end user will have access to good documentation,
>or any for that matter.  The Yahoo serach engine has a doc page, but
>few users ever look at it. 
>Having NEAR as an infix operator is simply confusing.  Lets not add
>confusing features. 
>> For Doug's case
>>   ((a AND b) OR (c AND d)) NEAR20 ((e AND f) OR (g AND h))
>> I understand that this is a difficult case to process, but I also think it
> > is somewhat of an unpractical case in reality.

I happen to be familiar with a (boolean) query language that only allows
proximity operators between or like queries (including prefix terms).
This case is not too difficult to explain and not confusing at all.
It might be not too difficult to implement, either.
It allows eg.

asdf* NEAR3 (fdsa* OR jkl* OR quotsch)

I can't find a good meaning for ((a AND b) NEAR (c AND d)) anyway.



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

View raw message