[jira] [Updated] (JENA-1134) Support alternative QueryParsers in jena-text

["Osma Suominen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JENA-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Osma Suominen updated JENA-1134:
--------------------------------
    Affects Version/s: Jena 3.0.1

> Support alternative QueryParsers in jena-text
> ---------------------------------------------
>
>                 Key: JENA-1134
>                 URL: https://issues.apache.org/jira/browse/JENA-1134
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: Text
>    Affects Versions: Jena 3.0.1
>            Reporter: Osma Suominen
>            Assignee: Osma Suominen
>
> 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:
> {noformat}
> <#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> ;
> {noformat}
> 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



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)