[jsword-devel] Various thoughts

[Joe Walker]

Hi,

On Sun, 13 Feb 2005 22:49:10 -0500, DM Smith <dmsmith555 at yahoo.com> wrote:
> I have been working with Troy to see if JSword and Sword can share indexes.
> So far it looks very promising. One thing we had to agree upon was the
> naming of the fields.
> Ours are "name" and "body" for the verse reference and the verse text
> respectively.
> Sword's are "key" and "content". (They also have "strong")
> Unless, there are any objections, I will be changing ours to match Sword's.

That's fine. We will all need to delete all our search indexes, but
that isn't a problem for me. Lets make sure we break the old indexes
cleanly.

> While we are not in a position to generate an index with Strong's
> numbers, we can use one just fine.
> Should we suggest that notes and footnotes be indexed as well? Anything
> else? Morphology?
> Transliterations of Hebrew and Greek? Transliteration of other
> languages? Unaccenting of accented text?
> Most of these are in the bug database for post 1.0.

It would be good to keep original language indexes separate from
specific translation indexes. There is no good reason why I shouldn't
be able to see verses with some strongs number in "The Message" even
though the chances of getting a strongs tagged Message translation are
close to zero.

> The other thing we had to agree upon was which analyzer to use. We are
> both using the same one now.
> 
> As long as we can agree on the names of the fields, the analyzer and the
> values used for the keys
> we can most likely use the same indexes.
> 
> Sword is storing their index in a "lucene" subdirectory of the directory
> containing the module text.
> For example, modules/.../ztext/kjv/lucene.
> Should we do the same? I think the answer is dependent upon whether we
> think that an index
> should exist apart from a module. When we add the "Delete" button back
> in the installer, it will
> delete the entire module directory (e.g. kjv under ztext). If lucene is
> a subdirectory, then that
> will be deleted as well.

This is a big question. Issues include:
- What if Sword want to update their indexes and we can't or the other
way around.
- What if indexing becomes customizable so that users can select the
amount of info indexed to trade of speed against search depth. Then
indexes are fairly personal rather than book specific.
- Are Sword allowing index downloading? They were against it before,
but it sounds like they are for it now. It would make sense to make
use of indexes that exist already.


> ================================================================
> I noticed that JSword has its own search syntax and is doing a word at a
> time search and then
> merging the answer sets into a result.
> 
>  From looking at the lucene search syntax, it seems much richer than
> what is present in JSword.
> Would it make sense to add a pass through mode? For example, if the
> search begins with a
> particular prefix, say "lucene:" then the rest of the line would be
> passed untouched.
> 
> Also, if the search did not begin with "lucene:", would it make sense to
> translate it to an equivalent
> lucene search and let lucene do it's magic?

I don't have strong feelings about this, however when we (I?) last
considered the issue I felt that things like strongs number searching,
verse blurring, etc. were fairly Bible specific and valuable. The
searcher interface could be implemented to use lucene I think, but the
advanced search dialog probably depends on the search syntax.

> ================================================================
> I am in the process of refactoring the installer out of
> org.crosswire.bibledesktop.book and
> into a package of its own: org.crosswire.bibledesktop.book.install.
> I came up with this name to parallel the
> org.crosswire.jsword.book.install package name.

Eh? it is there already!

> ================================================================
> I will be working on various installer issues, which I have assigned to
> myself in the bug database.
> After that, I will be doing a thorough testing of the application to see
> what bugs we have introduced
> since 0.9.8. I have noticed some refresh problems related to displaying
> passages.

Thanks,

Joe.