[jsword-devel] Extending Lucene Indexes and stemming in particular

Chris Burrell chris at burrell.me.uk
Mon Apr 21 06:01:56 MST 2014 

Hi Martin

My immediate requirement is for 1 addition (heading stems) to the index. I
could a new method in the IndexPolicyAdapter if you want. The others were
suggested by DM. As I've said quite a few times now, I'd be happy to remove
these, or also put these in the policy adapter. They are deliberately
additions to ensure backwards compatibility of the index. (i.e.
deliberately ensured that I would not break AB!)

As for the difference in requirements, it's not that far off. As you'll
know from some emails in 2012, STEP will be available on mobile devices (as
well as Desktops), so Sijo's code will come in useful for this (i.e.
detecting that new indexes are required, downloading them, etc.)

Chris



On 21 April 2014 12:11, Martin Denham <mjdenham at gmail.com> wrote:

> I don't want to be seen as a 'stick-in-the-mud' regarding index
> improvements so could I emphasize that STEP and AB requirements are very
> different and I suppose most desktop apps like BD are probably somewhere in
> the middle:
>
> AB
> Indexes all over the world
> Low powered devices
> Need small indexes
> Need to have fast index generation
> Need low memory and storage requirements
> I have no direct access to devices
> Users normally have no technical experience
> Users very happy with current search functionality
> Need backward compatibility
> Download speed very slow in general 2G/3G and costs money
> Frequent connection problems depending on country, provider
>
> STEP
> Indexes at single centralized location
> High powered server
> Index size not a factor
> Index generation only occurs once
> Lots of RAM and disk space available
> Experienced dev-op (Chris)
> Regeneration simple
> Pressing for enhanced functionality
> No need for backward compatibility
> Instant access to server
>
> I realise Sijo is implementing upgrade functionality but even then it will
> still not be a simple upgrade for AB given the architecture but STEP would
> not even need to use the new upgrade code.
>
> *Questions*
> I haven't followed all of the preceding discussion, partly because the
> finer details of Lucene have beaten me, so could I ask for clarification of
> some of the changes.  There seem to be 3 changes being discussed:
>
> *New code to support index upgrades* (Sijo)
> I understand most of this.  It looks useful.  I am hoping to submit a
> simple change/suggestion for the download index method compatible with
> this.  Index upgrades should have a deprecation period when old indexes
> work but new indexes are available for download or generation.
>
> *Changes to the generated indexes to support different search methods*
> I got a bit lost in the detail here.  Is this to allow enhanced STEP
> specific functionality or a required change for basic JSword searches.  If
> it is for STEP could this be handled via IndexPolicyAdapter.
>
> *Upgrade of Lucene*
> I realise STEP and AB have different leanings on this because of different
> architectures.  Which version of Lucene is it currently being planned to
> move to as various versions were discussed, some of which have a modified
> api and incompatible indexes, some don't.  If the target version of Lucene
> is incompatible then DM's suggestion will hopefully work but will it be
> possible to isolate api differences sufficiently to use the plugin
> architecture.
>
> Regards
> Martin
>
>
>
> On 21 April 2014 04:28, Sijo Cherian <sijo.cherian at gmail.com> wrote:
>
>> Thanks DM for explaining this far. The plugin configuration is nice way
>> for index customization.
>> As we extend our index fields, we should make it easier for the api user
>> to see all index fields present, and analyzer used for each.
>>
>> I am working on getting lucene upgrade functionality done.
>>
>>
>> On Sun, Apr 20, 2014 at 3:22 PM, DM Smith <dmsmith at crosswire.org> wrote:
>>
>>> He is risen!
>>>
>>> I haven't pulled the push request, atm. I think we need a bit more
>>> discussion. We are close.
>>>
>>> Indexing/searching is specified via interface and implemented via
>>> plugins. The IndexManager.plugin, QueryBuilder.plugin,
>>> QueryDecorator.plugin and Searcher.plugin. AnalyzerFactory.properties that
>>> Sijo mentioned is also a critical part. There may be a few others.
>>>
>>> There is no problem with AndBible having a different Index
>>> implementation (i.e. the current one) if we create the new one with a
>>> different name. AndBible will need to have a jar with the old
>>> implementation. JSword will provide the new implementation.
>>>
>>> This plugin mechanism was provided to be able to swap out one
>>> implementation for another during development, but can serve this purpose
>>> well.
>>>
>>> DM
>>>
>>>
>>> On Apr 20, 2014, at 3:39 AM, Chris Burrell <chris at burrell.me.uk> wrote:
>>>
>>> Hi Sijo
>>>
>>> That wouldn't do what I want. I need the non stemmed body content and a
>>> separate stemmed heading field.
>>>
>>> Even if I did want the stemmed body, I would want it in addition to the
>>> non stemmed body.
>>>
>>> As I said, happy to remove the other ones. They were put in at DM s
>>> suggestion.
>>>
>>> Chris
>>>  On 20 Apr 2014 03:09, "Sijo Cherian" <sijo.cherian at gmail.com> wrote:
>>>
>>>> Chris,
>>>> Since we already have a language based Analyzer configuration, if you
>>>> can provide a custom jsword/src/main/resources/AnalyzerFactory.properties
>>>> in STEP and add custom config for english like this:
>>>>
>>>>
>>>> en.Analyzer=org.crosswire.jsword.index.lucene.analysis.ConfigurableSnowballAnalyzer
>>>>
>>>> This will stem the "content" field, both during indexing & query. Can
>>>> you override prop files in your classpath, easily?
>>>>
>>>> Regarding your requirement to stem the heading: Since the current impl
>>>> for "heading" uses the default analyzer, you will have to change prop
>>>> "Default.Analyzer" to snowball, but that will have bigger impact - uses
>>>> snowball for all other fields.
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Apr 19, 2014 at 4:14 AM, Chris Burrell <chris at burrell.me.uk>wrote:
>>>>
>>>>> I don't mind configuration so long as these indexes are stored
>>>>> separately per app.
>>>>>
>>>>> STEP relies on stemming and in places it uses it, we can't ask the
>>>>> user, nor does it make sense there. So things would break and be quite hard
>>>>> to debug.
>>>>> Chris
>>>>> On 19 Apr 2014 06:13, "Sijo Cherian" <sijo.cherian at gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> Great discussion. isProgress.
>>>>>>
>>>>>> I am still pondering all the benefits of double indexing the entire
>>>>>> content.
>>>>>>
>>>>>> For specialized users, who don't want stemming factor in their
>>>>>> searching: Can we provide a API for them to specify param like noStemming,
>>>>>> noLowercase etc at the time of indexing on per-book basis, and persist
>>>>>> those metadata in property file. Use exact  property during query analysis.
>>>>>> These users probably won't want auto-reindexing on major jsword upgrade.
>>>>>>
>>>>>> Easter is almost here!
>>>>>> -sijo
>>>>>> On Thu, Apr 17, 2014 at 8:40 PM, DM Smith <dmsmith at crosswire.org>wrote:
>>>>>>
>>>>>>>
>>>>>>> On Apr 17, 2014, at 12:09 PM, Chris Burrell <chris at burrell.me.uk>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hello
>>>>>>>
>>>>>>> STEP uses stemming to improve search results, in some queries
>>>>>>> (whether on Sword modules or otherwise).
>>>>>>>
>>>>>>>
>>>>>>> Stemming is very useful. On occasion, there is a need for a
>>>>>>> non-stemmed search. Especially for theological purposes. But for general
>>>>>>> purpose searching it should be the default.
>>>>>>>
>>>>>>> I've some times thought it'd be good to double index: stemmed and
>>>>>>> full word.
>>>>>>>
>>>>>>>
>>>>>>> There are currently 2 limitations in JSword, both of which could
>>>>>>> easily be fixed. Please let me know if you have concerns around me
>>>>>>> implementing both.
>>>>>>>
>>>>>>> a- the frontend can't extend/control the use of indexes. I'm
>>>>>>> suggesting we add a registerFieldIndexer(fieldIndexer) with a simple
>>>>>>> interface: indexField(doc, osis). This would allow frontends to specify its
>>>>>>> own indexing. This would allow a frontend to index new things, or enable
>>>>>>> term vectors / store fields, etc.
>>>>>>>
>>>>>>>
>>>>>>> I'd really rather that we didn't go down this route. I don't mind
>>>>>>> plugin architecture as a way to experiment with different techniques, but
>>>>>>> I'd really rather that we all benefit from the changes.
>>>>>>>
>>>>>>>
>>>>>>> b- Extend the LuceneIndex to have a stemmed version of the heading.
>>>>>>> We could replace the existing index, but that would mean all frontends will
>>>>>>> require re-indexing.
>>>>>>>
>>>>>>>
>>>>>>> I think the same manner that we index the main verse text should be
>>>>>>> applied to all text: intro, heading and verse text.
>>>>>>>
>>>>>>>
>>>>>>> c- Had JSword been configured to 'STORE' the content of some fields,
>>>>>>> I would have used that for headings. For example, if the headings is stored
>>>>>>> in the index, STEP would not need to do an osis extract and XML transform
>>>>>>> to display to the user. It could come straight from the index. Two
>>>>>>> possibilities here: change the existing index field configuration, or
>>>>>>> duplicate into a different field.
>>>>>>>
>>>>>>>
>>>>>>> I think we should make store an option, possibly the standard.
>>>>>>>
>>>>>>> Right now the way we do the index prevents us from using Lucene to
>>>>>>> highlight the search hit. If that is STORE, then I'd be in favor of making
>>>>>>> STORE standard. I wonder if our stripping the text to no include OSIS
>>>>>>> before indexing will frustrate this change.
>>>>>>>
>>>>>>> It still should be an option for the sake of devices that are disk
>>>>>>> limited.
>>>>>>>
>>>>>>> d- the other side of c- is that ideally multiple headings should be
>>>>>>> stored in multiple entries to the same field, rather than a concatenation
>>>>>>> of the field (doesn't much matter if it's only ANALYZED)
>>>>>>>
>>>>>>>
>>>>>>> Some verses have headings in the middle of the verse. Don't make the
>>>>>>> mistake of assuming an order of heading. Or that heading contains only
>>>>>>> pre-verse material or all pre-verse material.
>>>>>>>
>>>>>>>
>>>>>>> *I only need one of a- or b- to be able to progress. Happy to do
>>>>>>> either. I don't need c- because I've worked around, but it would have been
>>>>>>> nice to have some control over that. *
>>>>>>>
>>>>>>> pros & cons:
>>>>>>> a- more extensible in the future, other frontends don't benefit from
>>>>>>> enhancements
>>>>>>> b- solves an immediate problem, but impacts all frontends (i.e.
>>>>>>> space used in index).
>>>>>>>
>>>>>>> The only other bit in my mind is whether we need to ensure
>>>>>>> index-cross-application compatibility. I suspect some of this will tie in
>>>>>>> with the good work that Sijo has done on index management.
>>>>>>>
>>>>>>>
>>>>>>> The index management will be more critical with such a change. I've
>>>>>>> talked about having a manifest which defines the characteristics of the
>>>>>>> index. If we share an index created by two different systems, it will be
>>>>>>> important to "know" what an index supports.
>>>>>>>
>>>>>>> One of the changes that is being worked on is the update to a more
>>>>>>> recent version of Lucene. This affects how stemming is done. The way we are
>>>>>>> doing it now is deprecated and dropped.
>>>>>>>
>>>>>>>
>>>>>>> Let me know what your preferences are.
>>>>>>>
>>>>>>>
>>>>>>> Progress not perfection. Shared, configurable changes.
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jsword-devel mailing list
>>>>>>> jsword-devel at crosswire.org
>>>>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jsword-devel mailing list
>>>>>>> jsword-devel at crosswire.org
>>>>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Sijo
>>>>>>
>>>>>> _______________________________________________
>>>>>> jsword-devel mailing list
>>>>>> jsword-devel at crosswire.org
>>>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> jsword-devel mailing list
>>>>> jsword-devel at crosswire.org
>>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Sijo
>>>>
>>> _______________________________________________
>>> jsword-devel mailing list
>>> jsword-devel at crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>
>>>
>>>
>>
>>
>> --
>> Regards,
>> Sijo
>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20140421/050ac2ad/attachment-0001.html>

More information about the jsword-devel mailing list