Just a few quick comments before I run into work this morning.
I'm excited about your ideas and progress. There are a few social
things you might want to know first.
JSword has an interesting past. Years ago it was a separate project.
The developer came to us and asked if he could write low level
drivers to read our data format and then make it part of
CrossWire. We had some conditions setup for this to take place. Two of them:
Also develop a programming interface similar enough to the C++ engine
that someone familiar with the C++ API would be able to get around in
the Java code.
Follow all CrossWire authoring rules: code authorship is granted to
CrossWire and licensed back to the general public under the GPL.
... never happened.
DM Smith now has taken ownership of the codebase (he was not the
original author spoken of above, but from my past experience with DM,
has probably written most of the code which is out there now). DM is
a great guy. I have no idea how he feels about the remaining 2 items.
A few technical things about JSword:
JSword obviously does not use our standard C++ engine and is behind
in supporting some of the data we make available
It currently does not use our standard module installation process
for autodiscovery of remote installation locations and modules, so it
will not find new material offered by publishers in our standard method.
It uses XSLT transformations to convert OSIS XML markup to display
format-- which some will say is a plus, but the overhead of the XSLT
engine and the nuances of writing XSLT, to some are a detriment.
It likely will not run anytime soon on mobile devices.
It does not have our 'entryAttributes' concept offered by the C++
engine for building research software, e.g.
SWMgr library;
SWModule *kjv = library.getModule("KJV");
nasb->setKey("jn.3.16");
string morphology = kjv->getEntryAttributes()["Word"]["003"]["Morph"];
string greekSource = kjv->getEntryAttributes()["Word"]["003"]["Src"];
... which will tell you the morphological parsing of the 3rd word in
John 3:16 (Conjuction) and will tell you that it came from the 2nd
Greek word in the same verse of the Textus Receptus Greek text.
The Entry Attributes concept makes, well, tons of attributes
(footnotes, cross-refs, headings, morphology, etc.) about an entry
(like Jn.3.16) available for easy programmatic retrieval. Writing
short programs to do interesting statistical analysis of the text is
really quick and fun.
e.g., how many times is XXX Greek word translated as YYY in the KJV?
NASB? what are the words which occur most frequency with Greek word
XXX, but have a total frequency count in the NT under 50 usages.
Anyway, just wanted to give you a heads up regarding the JSword
framework. It's still a great framework, and of course I'm biased
because I wrote the C++ engine. :) I'm sure DM would give you the
pros to using JSword.
A quick note about the DB. What kinds of data are you planning on
storing in a database? SWORD (and JSword) support storage and
retrieval of 3 main types of data:
Bibles: primarily indexed by Testament, Book, Chapter, Verse
Lexica/Dictionaries: primarily indexed by word/phrase/strongs number, etc.
General Books: primarily indexed by a table of contents tree
All of these data types have full lucene word search indexes built
against their contents.
I would say that if your data fits into any of these 3 formats, then
use our storage format and the result will benefit all of our other frontends.
Of course, if there's a good reason to use a database, please do so,
but I think you will find that our retrieval engine as fast or faster
than a traditional RDBMS, and of course it is no extra
code/setup/dependency-- and as I mentioned above, has the bonus of
letting your data be discovered and installed by our other applications.
This is much longer than I intended. Gotta run to work!! Sorry for
any typos-- hope they're not in code examples!
-Troy.
No comments:
Post a Comment