[
https://issues.apache.org/jira/browse/LUCENE-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870374#action_12870374
]
Simon Willnauer commented on LUCENE-2458:
-----------------------------------------
bq. FWIW, I agree w/ Mark. I don't think it's a bug, but more of a user option
I would rather agree with Shai and Mark here but it is also not the behavior I
would expect if I come to lucene the first time and use query parser. I still
don't understand why this should not be done by using version. Exactly stuff
like that where the reason to introduce it. Using Version to change runtime
behavior has been done before (see CharTokenizer, CharacterUtils,
LowerCaseFilter). IMO this is a totally valid usage and makes people aware of
that something has changed. I also figured that Version seriously got adopted
in the Community, people start using and appreciating it which somewhat changed
my mind on Version.
bq. And for what's it's also worth, we've once worked w/ a Japanese linguist,
There will be tons of different opinions to that around linguists around the
world but this parser is not for linguists in the first place. It should give
the majority of users a good DEFAULT and has never aimed to be a perfect
solution. I usually recommend to misplease everybody equally than being biased
towards a certain usergroup when providing an API which is not super special
purpose.
It seems to me making this behavior available with Version is the right way to
go. I don't care if people call it a bug or a good default for US text - what
count is to give people a good default no matter what they index or where they
come from. (sounds like this is close to discriminating people - just kidding)
Another thing i wanna mention is that QueryParser should really be in contrib /
modules rather than in core. I don't know how many parsers we have in the
meanwhile but we should really consolidate them in a new module for 4.0. Get
the stuff out there, make a copy of the current parser, name it
"SmartENBiasedAutomaticPhraseGeneratingQueryParser", fix that in the other one
and provide people a good default.
just my $0.05
> queryparser shouldn't generate phrasequeries based on term count
> ----------------------------------------------------------------
>
> Key: LUCENE-2458
> URL: https://issues.apache.org/jira/browse/LUCENE-2458
> Project: Lucene - Java
> Issue Type: Bug
> Components: QueryParser
> Reporter: Robert Muir
> Assignee: Robert Muir
> Priority: Blocker
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2458.patch, LUCENE-2458.patch
>
>
> The current method in the queryparser to generate phrasequeries is wrong:
> The Query Syntax documentation
> (http://lucene.apache.org/java/3_0_1/queryparsersyntax.html) states:
> {noformat}
> A Phrase is a group of words surrounded by double quotes such as "hello
> dolly".
> {noformat}
> But as we know, this isn't actually true.
> Instead the terms are first divided on whitespace, then the analyzer term
> count is used as some sort of "heuristic" to determine if its a phrase query
> or not.
> This assumption is a disaster for languages that don't use whitespace
> separation: CJK, compounding European languages like German, Finnish, etc. It
> also
> makes it difficult for people to use n-gram analysis techniques. In these
> cases you get bad relevance (MAP improves nearly *10x* if you use a
> PositionFilter at query-time to "turn this off" for chinese).
> For even english, this undocumented behavior is bad. Perhaps in some cases
> its being abused as some heuristic to "second guess" the tokenizer and piece
> back things it shouldn't have split, but for large collections, doing things
> like generating phrasequeries because StandardTokenizer split a compound on a
> dash can cause serious performance problems. Instead people should analyze
> their text with the appropriate methods, and QueryParser should only generate
> phrase queries when the syntax asks for one.
> The PositionFilter in contrib can be seen as a workaround, but its pretty
> obscure and people are not familiar with it. The result is we have bad
> out-of-box behavior for many languages, and bad performance for others on
> some inputs.
> I propose instead that we change the grammar to actually look for double
> quotes to determine when to generate a phrase query, consistent with the
> documentation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
