<p dir="ltr">I don't mind configuration so long as these indexes are stored separately per app.</p>
<p dir="ltr">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.<br>
Chris</p>
<div class="gmail_quote">On 19 Apr 2014 06:13, "Sijo Cherian" <<a href="mailto:sijo.cherian@gmail.com">sijo.cherian@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div><br></div>Great discussion. isProgress.<br><br></div>I am still pondering all the benefits of double indexing the entire content.<br><br><div><div><div class="gmail_extra">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. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Easter is almost here!<br></div><div class="gmail_extra">-sijo<br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 17, 2014 at 8:40 PM, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div>On Apr 17, 2014, at 12:09 PM, Chris Burrell <<a href="mailto:chris@burrell.me.uk" target="_blank">chris@burrell.me.uk</a>> wrote:</div>
<br></div><div><blockquote type="cite"><div dir="ltr">Hello<div><br></div><div>STEP uses stemming to improve search results, in some queries (whether on Sword modules or otherwise).</div></div></blockquote><div><br>
</div></div>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.</div><div><br></div><div>I've some times thought it'd be good to double index: stemmed and full word.</div>
<div><div><br><blockquote type="cite"><div dir="ltr"><div><br></div><div>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.</div>
<div><br></div><div>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. </div>
</div></blockquote><div><br></div></div>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.</div>
<div><br></div><div><div><blockquote type="cite"><div dir="ltr">
<div><br></div><div>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.</div></div></blockquote><div><br></div>
</div>I think the same manner that we index the main verse text should be applied to all text: intro, heading and verse text.</div><div><br></div><div><div><blockquote type="cite"><div dir="ltr"><div><br></div><div>
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.</div>
<div><br></div></div></blockquote><div><br></div></div>I think we should make store an option, possibly the standard.</div><div><br></div><div>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.</div>
<div><br></div><div>It still should be an option for the sake of devices that are disk limited.</div><div><div><br><blockquote type="cite"><div dir="ltr">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)</div>
</blockquote><div><br></div></div>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.</div>
<div><div><br><blockquote type="cite"><div dir="ltr">
<div><br></div><div><b>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. </b></div><div>
<br></div><div>pros & cons:</div><div>a- more extensible in the future, other frontends don't benefit from enhancements</div><div>b- solves an immediate problem, but impacts all frontends (i.e. space used in index).</div>
<div><br></div><div>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.</div></div>
</blockquote><div><br></div></div>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.</div>
<div><br></div><div>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.</div><div><div>
<br><blockquote type="cite"><div dir="ltr"><div>
<br></div><div>Let me know what your preferences are.</div></div></blockquote><div><br></div></div>Progress not perfection. Shared, configurable changes.</div><div><br><blockquote type="cite"><div dir="ltr"><div>Chris</div>
<div><br></div></div>
_______________________________________________<br>jsword-devel mailing list<br><a href="mailto:jsword-devel@crosswire.org" target="_blank">jsword-devel@crosswire.org</a><br><a href="http://www.crosswire.org/mailman/listinfo/jsword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/jsword-devel</a><br>
</blockquote></div><br></div><br>_______________________________________________<br>
jsword-devel mailing list<br>
<a href="mailto:jsword-devel@crosswire.org" target="_blank">jsword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/jsword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/jsword-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Regards,<br>Sijo
</div></div></div></div>
<br>_______________________________________________<br>
jsword-devel mailing list<br>
<a href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/jsword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/jsword-devel</a><br>
<br></blockquote></div>