[sword-devel] Alternate Versification

[DM Smith]

Kahunapule Michael Johnson wrote:
> DM Smith wrote:
>   
>> A good place for this would be:
>> www.crosswire.org/wiki/Alternate_Versification.
>>
>> 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 
versification.

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 
versification definition.

>  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 
implementation.

In Him,
    DM