[JENA-1134] Support alternative QueryParsers in jena-text

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: Jena 3.0.1
• Fix Version/s: Jena 3.1.0
• Component/s: Text
• Assignee: Osma Suominen
• Reporter: Osma Suominen
• Created: 09/Feb/16 13:11
• Updated: 14/May/16 09:51
• Resolved: 18/Apr/16 11:31

Description

Jena-text is currently hardwired to use Lucene QueryParser. This parser is (intentionally) limited so that it doesn't analyze wildcard queries. Instead they will be expanded directly.

This is a problem if you want to do accent-insensitive wildcard queries (using ASCIIFoldingFilter) or other wildcard queries which rely on a special analyzer. However, Lucene offers an alternate parser, AnalyzingQueryParser, that could be used in such cases.

I'd like to extend jena-text with a configuration parameter that allows using AnalyzingQueryParser instead of the standard QueryParser. For example, the configuration could look like this:

<#indexLucene> a text:TextIndexLucene ;
    text:directory <file:Lucene> ;
    text:queryParser text:AnalyzingQueryParser ;
    text:queryAnalyzer [
        a text:ConfigurableAnalyzer ;
        text:tokenizer text:KeywordTokenizer ;
        text:filters (text:ASCIIFoldingFilter text:LowerCaseFilter)
    ] 
    text:entityMap <#entMap> ;

I've written some very preliminary code to implement this, but I'm not yet satisfied with it. It's a bit problematic because the parser cannot be constructed in advance but must be dynamically created separately for each query (because it needs parameters that can differ between queries).

Thus the TextIndexConfig must store information about which parser variant to use, but not the actual QueryParser/AnalyzingQueryParser instance. This isn't rocket science though, maybe some kind of Factory pattern would work.

For some background for why this is needed, see this Skosmos issue:
https://github.com/NatLibFi/Skosmos/issues/424