There is PhraseQuery, too, but lets consider two cases:
case1: that PhraseQuery is not being used:
then should i add to standard filter’s stopwords also the french
stopwords
both at index & search times? can i just add them at search time
and keep
old friends index as it is?
case2: that PhraseQuery being used:
i guess i need to play with the “slops” and stopwords in this case
will
not help, right?
Thanks
On Feb 24, 2019, at 2:25 PM, baris.kazar <baris.ka...@oracle.com>
wrote:
That is not what i am looking for. Thanks.
c b search string finds
a b
but how cant find
a de la b
so i will try french stopwords.
Doing that i am using 8 queries like the ones i mentioned.
Best
On Feb 24, 2019, at 1:19 PM, Erick Erickson
<erickerick...@gmail.com>
wrote:
Phrase search is looking for words next to each other. A phrase
search
on the text “my dog has fleas” would succeed for “my dog” or “has
fleas”
but not “my fleas” since the words are not right next to each
other. “my
fleas”~3 would succeed because the “~3” indicates that the words
can have
intervening terms.
Searching (dog AND fleas) would match no matter how many words were
between the two.
If you’re unclear about what phrase search .vs. non-phrase search
means, some background research/ self-education are strongly
recommended,
such basic understanding of search is pretty much assumed.
Best,
Erick
On Feb 24, 2019, at 9:25 AM, baris.kazar <baris.ka...@oracle.com>
wrote:
i guess so
what is phrase search?
c b is searched do you expect a de la b?
Thanks
On Feb 24, 2019, at 10:49 AM, Erick Erickson
<erickerick...@gmail.com>
wrote:
Not sure we’re talking about the same thing. I was talking
specifically about _phrase_ searches. If all you want is the clause
you
just said, phrases are not involved at all and the presence or
absence of
intervening words is totally unnecessary. This assumes your field type
tokenizes the input similar to the text_general field in the examples.
Specifically _not_ “string” fields or fields that use
KeywordTokenizer.
q=name:(a AND b) OR name:b
for instance. With a query like that it doesn’t matter in the
least
whether there are, or are not any words between “a” and “b”.
All that may be obvious to you, but when I read your latest
e-mail it
occurred to me that we might not be talking about the same thing.
Best,
Erick
On Feb 23, 2019, at 7:33 PM, baris.kazar <baris.ka...@oracle.com>
wrote:
In this case search string is c b
and then search query has 8 combos
including two cases with c b ~ which means find all containing
c And
b and c Or b ( two separate queries having ~ )
and then i can find a b but not a de la b without French
stopwords.
Thanks
On Feb 23, 2019, at 6:52 PM, Erick Erickson <
erickerick...@gmail.com> wrote:
Lucene won’t ignore these unless you tell it to via stopwords.
This is a problem no matter how you look at it. If you do put in
stopwords, the word _positions_ are retained. In your example,
word position
a 1
de 2
la 3
b 4
If you remove “de” and “la” via stopwords, the positions are
still:
word position
a 1
b 4
So searching for “a b” would fail in the second case unless you
included “slop” as
“a b”~2
But let’s say you _do not_ have input with these stopwords,
just “a
b". The positions
will be 1 and 2 respectively. Here the user would expect “a
b” to
match this doc, but
not a doc with “a de la b” (unless they knew a lot about
search!).
So maybe the right thing to do is let phrases have slop as a
matter
of course.
Best,
Erick
On Feb 23, 2019, at 11:07 AM, baris.kazar
<baris.ka...@oracle.com>
wrote:
Thanks Erick there is a pattern i cant catch in my results
such as:
a de la b
i catch “a b” though.
I though Lucene might ignore those automatically while creating
index.
On Feb 23, 2019, at 12:29 PM, Erick Erickson <
erickerick...@gmail.com> wrote:
Use stopwords, although it's becoming less of a concern,
why do
you think
you need to?
On Sat, Feb 23, 2019, 08:42 baris.kazar
<baris.ka...@oracle.com>
wrote:
Hi,-
What is the (most efficient) way to
ignore “de la” kinda connectors
in a string at index or search time?
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail:
java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail:
java-user-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail:
java-user-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail:
java-user-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
