:
Subject:Re: RE: RE: Query parser and minus signs
On May 26, 2004, at 10:48 AM, [EMAIL PROTECTED] wrote:
Query: hsbc -language:zh-HK
Parsed query: (contents:hsbc -language:zh -contents:hk) (keywords:hsbc
-language:zh -keywords:hk) (title:hsbc -language:zh -title:hk)
(language:hsbc
looks OK at least to a relative beginner like myself), and also
through the search code but I'm still none the wiser.
Am I doing something wrong, or have I completely missed the point ??
To:Alex BOURNE/IBEU/[EMAIL PROTECTED]
cc:
bcc:
Subject:RE: RE: Query parser and minus signs
??
To:Alex BOURNE/IBEU/[EMAIL PROTECTED]
cc:
bcc:
Subject:RE: RE: Query parser and minus signs
remember luke does not display the indexed tokens but the stored
field. So
you would expect to see en-uk in the field.
doc.add(Field.Keyword(locale,test-uk));
are you adding to the document like
it just become
part of the query??
Erik Hatcher [EMAIL PROTECTED] on 26 May 2004 15:11
Please respond to Lucene Users List [EMAIL PROTECTED]
To:Lucene Users List [EMAIL PROTECTED]
cc:
bcc:
Subject:Re: RE: RE: Query parser and minus signs
What is the value of your Parsed query
On May 26, 2004, at 10:48 AM, [EMAIL PROTECTED] wrote:
Query: hsbc -language:zh-HK
Parsed query: (contents:hsbc -language:zh -contents:hk) (keywords:hsbc
-language:zh -keywords:hk) (title:hsbc -language:zh -title:hk)
(language:hsbc
-language:zh -language:HK)
Hits: 169
Not quite what I was
respond to Lucene Users List [EMAIL PROTECTED]
To:Lucene Users List [EMAIL PROTECTED]
cc:
bcc:
Subject:RE: RE: Query parser and minus signs
Doesn't en UK as a phrase query work?
You're probably indexing it as a text field so it's being tokenised.
-Original Message-
From: [EMAIL
On May 24, 2004, at 4:50 AM, [EMAIL PROTECTED] wrote:
I tried this, but no it does not work. I'm concerned that escaping the
minus symbol does not appear to work. The field is indexed as a
keyword so
is not tokenized - I've checked the contents using luke which confirms
this.
You will need to
if you're dealing with locales, why not use java's built in locale syntax (ex: en_UK,
zh_HK)?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, May 21, 2004 10:36 AM
To: [EMAIL PROTECTED]
Subject: Query parser and minus signs
Hi All,
PROTECTED]
cc:
bcc:
Subject:RE: Query parser and minus signs
if you're dealing with locales, why not use java's built in locale syntax
(ex: en_UK, zh_HK)?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, May 21, 2004 10:36 AM
To: [EMAIL PROTECTED
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 21, 2004 11:36 AM
Subject: Query parser and minus signs
Hi All,
I'm using Lucene on a site that has split content with a branch containing
pages in English and a separate branch in Chinese.
Doesn't en UK as a phrase query work?
You're probably indexing it as a text field so it's being tokenised.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 21 May 2004 16:47
To: Lucene Users List
Subject: Memo: RE: Query parser and minus signs
Hmm, we may
Dror Matalon writes:
my $.02.
Before having patches, I think it's a good idea to agree on what the
right solution is.
I tried to raise that question in the first place. But there wasn't much
responce.
So I decided to make a concrete suggestion, how to change things.
Most of it is obvious
Hi,
First, let me say something that wasn't obvious from my first mail.
While I had opinions about the implementation, I have a lot of respect
for your finding a problem, and going ahead and coding a solution.
On Tue, Dec 30, 2003 at 11:40:17AM +0100, Morus Walter wrote:
Dror Matalon writes:
Hi Dror,
thanks for your answer. I really appreciate your comments.
Before having patches, I think it's a good idea to agree on what the
right solution is.
I tried to raise that question in the first place. But there wasn't much
responce.
Might be the time of the year when many
On Dec 30, 2003, at 3:13 PM, Morus Walter wrote:
Hmm. That's be up to the developers.
Don't know how many of them are reading lucene-user.
I suspect we're all here!
QueryParser is Lucene's red-headed step-child. It works well enough,
but it has more than its share of issues. It is almost a
On Tue, Dec 30, 2003 at 03:25:08PM -0500, Erik Hatcher wrote:
On Dec 30, 2003, at 3:13 PM, Morus Walter wrote:
Hmm. That's be up to the developers.
Don't know how many of them are reading lucene-user.
I suspect we're all here!
Great.
QueryParser is Lucene's red-headed step-child. It
On Tue, Dec 30, 2003 at 09:13:30PM +0100, Morus Walter wrote:
...
What's the meaning of a OR b c +d ?
(Acutally there must be two meanings, one for default or, one for default and).
Maybe it's obvious, but I fail to see it.
You're right, it is confusing. Assuming default OR I would
Hi Dror,
I was thinking about this issue, and currently I think that the only way to
define this type of queries formally, is to give the default operator it's own
precedence relativly to the precedence of 'OR' and 'AND'.
So there are two possibilities:
either the default operator has
On Tue, Dec 30, 2003 at 11:19:38PM +0100, Morus Walter wrote:
Hi Dror,
For one thing, I would advocate for using the '+' notation as the
underlying syntax and migrating to boolean operators since that's many
more people are used to that syntax, and I believe it's better
understood.
my $.02.
Before having patches, I think it's a good idea to agree on what the
right solution is. Most of it is obvious using boolean logic, but we
have some additional requirements like not having a query that only has
a NOT clause. Is this the only exception?
As far as the actual patch, I
Jamie Stallwood wrote:
What Morus is saying is right, an expression without parenthesis, when
interpreted, assumes terms on either side of an AND clause are compulsory
terms, and any terms on either side of an OR clause are optional. However,
if you combine AND and OR in an expression, the
Morus Walter writes:
I attached the patch (made against 1.3rc3 but working for 1.3final as well)
and a test program.
Seems the attachments got stripped...
So once again:
The patch:
===File lucene/QueryParser.jj.patch===
*** QueryParser.jj.org Mon Dec 22 11:47:30 2003
---
Hi Dror,
thanks for your answer.
I'm having problems understanding query parsers handling of AND and OR
if there's more than one operator.
E.g.
a OR b AND c
gives the same number of hits as
b AND c
(only scores are different)
This would make sense if all the document that
Message-
From: Morus Walter [mailto:[EMAIL PROTECTED]
Sent: 10 December 2003 09:01
To: Lucene Users List
Subject: Re: Query Parser AND / OR
Hi Dror,
thanks for your answer.
I'm having problems understanding query parsers handling of AND and OR
if there's more than one operator.
E.g
On Tue, Dec 09, 2003 at 10:57:51AM +0100, Morus Walter wrote:
Hi,
I'm having problems understanding query parsers handling of AND and OR
if there's more than one operator.
E.g.
a OR b AND c
gives the same number of hits as
b AND c
(only scores are different)
This would make sense if
Try using the newest release and read the Queryparser syntax.
http://jakarta.apache.org/lucene/docs/queryparsersyntax.html
Escape characters were just added.
--Peter
On 5/29/02 10:53 PM, Harpreet S Walia [EMAIL PROTECTED] wrote:
Hi
I am trying to search words which have characters { ,
: query parser deafults
I've been looking at the query parser source code and have come to a
loose end.
Not surprising! Many people have a hard time wrapping their
head around
parsers; the logic is not straightforward.
I'm attempting to modify the query parser so that all terms
Peter,
What do you mean with
This will make documents with the term IBM appear more relevant. You can
also boost Phrase Terms as in the example:
Where is the example with IBM ?
I think that the example
jakarta apache^4 jakarta lucene
could be
IBM^4 jakarta lucene
Thanks,
28 matches
Mail list logo
