[sword-devel] Alternate Versification
dmsmith at crosswire.org
Wed Apr 29 12:27:27 MST 2009
Kahunapule Michael Johnson wrote:
> DM Smith wrote:
>> A good place for this would be:
>> Just add a section that gives:
>> The name of the versification, the description of the versification
>> and the date that it was added to the SWORD engine.
Only a partial reply. As the JSword developer I'm interested in what's
going to happen with av11n so that I can implement it in Java. JSword
will be following the lead of SWORD, thus lagging it.
> The number of versification schemes that must be supported is at least
> one greater than the number of pre-defined versification schemes that
> you come up with.
:) Probably true. The more that are defined in the engine, the larger
the engine is. I don't know if this growth will ever become an issue
(e.g. for hand-held devices).
For JSword, I plan to have data files that are loaded on demand (i.e.
actual use). One advantage of this is that we'll not need a full release
to update JSword to have another v11n scheme. It will simply be a matter
of adding it to the jsword properties folder.
Basically for JSword to be efficient, we need to know the order of the
books, the number of chapters in each book and the number of verses in
each chapter. From this we build auxiliary data structures that provide
efficient conversion of a reference to the ordinal position in the v11n
scheme and given an ordinal position, we can efficiently convert it
back. (At times, we use this in a bitset.)
The SWORD canon header files provide the same information.
> If the versification schemes must each individually be
> added into the SWORD engine, and not just into the modules, there will
> be Bibles that you can't properly encode without upgrading the SWORD
> engine. Hasn't anyone considered a way to put the versification scheme
> entirely in the module, along with a recommended equivalent display in
> one or more reference versification schemes?
Yes. But not in this release.
The idea is to store the references in the module (right now the idea is
to use a GenBook and VerseTreeKey) and have the program discover the
When we get to the implementation, I plan to modify osis2mod to handle
such a module.
I'm going to guess that if the discovery process is slow, that the
module's versification will be computed once and written to disk for
reuse. I'm anticipating that's what we'll do for JSword. JSword will
use the same format as the data files that are loaded on demand.
I think it would be possible to modify osis2mod to create the module's
> Usually, differences aren't
> major, but the number of probable permutations is daunting when you
> consider the thousands of languages spoken on this planet.
I don't think the number of languages has any bearing on the problem.
OSIS has a predefined set of book names. So in Farsi, Swahili, German,
or any other language, "Matt" is the only way to reference the "Gospel
according to St. Matthew".
> So, some sort
> of difference encoding might be an efficient way to do things. For
> example, in some schemes, the Hebrew Title of a Psalm is verse 1, and
> the first actual verse of the psalm is 2, etc.-- a constant offset of
> just one for Psalms with titles. Then there are verse bridges (not
> technically another versification scheme, but related in the way they
> are handled), as well as those pesky moved paragraphs, one verse counted
> as two or vise versa, etc. I'm guessing that if you think you have all
> of the versification schemes enumerated, a different one will come
> along, and not because of any heretical work, either.
A later release will tackle the mapping of one known versification to
another known one. You have hit on some of the issues involved.
Mapping is desired as a way to properly do parallel display and also for
lookup using references from one scheme in a Bible with another.
I'll leave response to any alternate ideas to those that are doing the
More information about the sword-devel