[sword-devel] Concerns about Alternate Versification

[Jonathan Morgan]

On Tue, Jan 6, 2009 at 2:20 PM, Familie von Kaehne <refdoc at gmx.net> wrote:
> Jonathan Morgan wrote:
>> Executive summary: I do not believe that alternate versification is
>> useful without mapping between versifications, and I am not convinced
>> that it is useful doing alternate versification with Genbooks.
>>
>> All of the work and discussion that I have seen on alternate
>> versification to date has been concerned with individual Bibles and
>> representing all the foibles and quirks of individual Bibles correctly
>> without the limitations of the KJV versification.  I am somehow better
>> off accessing /Gen/3/2 in the KJV than I am accessing Genesis 3:2,
>> since I can then access /1Mac/2/2 as well.  As a software developer I
>> have to accept the limitation that I now need to have references for
>> one particular Bible and keys for that Bible rather than generic
>> references.  However, I think all of this discussion ignores one
>> thing: In general, I (and probably the "average user") am not
>> interested in Bible specific references.  I am interested in Genesis
>> 3:2, not "Genesis 3:2 in this version".  A few examples:
>>
>> 1. My cross-references in the TSK or a Bible dictionary are references
>> to the entity "Genesis 3:5", not "Genesis 3:5 in a particular
>> version".
>
> Not correct. The TSK or any other reference work will have used an
> underlying particular versification - even if this is not documented. So
>  Gen 3:5 can contain any variety of text close by (KJV) Gen 3:5. As a
> user I do not want to get directed to a totally unrelated verse which
> happens to share the reference, but I want to end up at the right
> content. So a KJV Gen 3:5 reference should lead me to Luther Gen 3:4

Which is what I said later on, in effect.  For our English works, I am
assuming a KJV versification, and it is because of that that I am
basing the master versification on that.

> (I am making this up right now, so do not correct me on this. But Luther
> and KJV are over wide stretches of teh Pentateuch 1 or 2 verses up or
> down out of sync)

Yes.  Mentioned below.

>> 2. If I want to produce a list of references on a particular topic,
>> that list is almost always version independent.
>
> No. It is bound to a particular versification scheme and any other
> versification scheme will have errors subsequently. In terms of Luther
> the errors will make e.g. the TSK practically unusable.
>
> Further the current discrepancy between paper Luther and sword Luther is
> massive.

Again, it is version independent in the sense that I am referring to
the entity "Genesis 3:5" represented by the words in my current Bible,
and I want to read the same words in the German (or as close as I
could get) - e.g. Genesis 3:4 or whatever.

>> 3. I want to be able to view multiple Bibles in parallel.  This is not
>> possible if I cannot get version independent references (doing such a
>> display with a considerably different versification is a hard problem
>> that requires thought, but the need is there).
>
> CCEL has produced lengthly lists to make transformation easy.

You still have the question of how you display things in parallel
under reordering.  It might end up something like

Version 1   Version 2
3:1             3:2
3:2             3:1
3:3             3:3

Do I want to order with respect to the first version and get verse to
verse comparison, while possibly hacking version 2 into illegible
chunks because I've reordered?
Alternatively, do I want to merge the display of 1 and 2 in both, so
that you have multiple verses in parallel but they display in native
order?  [this could get worse if you had more than two versions with
different versifications in parallel.  That might seem a fringe case,
but I can quite see it happen if you had a Telugu, Hindi and English
parallel in India, where people do use English Bibles and mother
tongue Bibles and so forth.  It could also be bad if it just meant to
chapters side by side with no verse by verse parallelism at all,
though that might not be too bad].

Bear in mind that we must be able to handle any arbitrary
versification, and so I as the frontend developer must be aware of all
the combinations, including ones in languages I can't understand and
so can't judge if it is a good parallel or not.

>> I believe an important aim of Bible software should be, where
>> possible, to allow users to read the Bible in their own language (and
>> for me that includes not reading it in the KJV or DRC, since that is
>> not my language).  This is why I don't really like version specific
>> references, and this is why I don't like an alternate versification
>> that requires me to have module specific keys without a proper mapping
>> between them.
>
> The mapping is the way to make version specific references work. The
> mapping is available, even if it is not (yet) in the library.

If I understand you, that isn't a mapping at all, just encoding a
commentary saying "We MUST use this Bible." - I don't want that
restriction.

>> Producing a proper mapping is not an easy problem,
>
> It has been done by CCEL.
>
>> since even versions
>> close to the standard versification can reorder verses, and that needs
>> to be considered when showing in parallel or displaying a reference
>> (e.g. if my English commentary refers to Romans 4:13, I want it to
>> display Romans 4:16 in the Telugu OV, since that is the equivalent
>> verse - this is a problem that is likely not solved by the current
>> system).  However, without such a mapping I believe that we are worse
>> off with alternate versification than without it.
>
> A reference to Romans 4:13 in your English commentary is meaningless in
> your Telugu OV paper version. And in your CrossWire
> KJV-force-versification module it is only occasionally useful - whenever
> the vector of forced re-versification has produced sense rather than not.

That is my point - it should not be meaningless.  Again: my goal is
reading the Bible in your own language, doing whatever mapping is
necessary so that that works.

>> I am also concerned about the choice of using Genbooks to represent
>> books, just based (as far as I can tell) on the fact that we already
>> have Genbook support.  Is there any technical reason that makes the
>> Genbook reference "/Gen/3/2" superior?  Remember that this is not
>> being displayed to the user at all, so we are at liberty to choose any
>> representation we like.  The Genbook representation allows all sorts
>> of invalid data - I could have /Gen/2, or /Gen/something or other/some
>> random text/2/3.
>
>> How I would represent it is (in broad sketch) as follows:
>> 1. Use the current Bible representation of one entry per verse, but
>> only have as many entries as there are verses in the versification and
>> have a mapping table at the start mapping from verses to indices.
>
> And what do you do about chapters which are longer?

The issue doesn't arise.  The mapping looks in rough form like:
Genesis 1:1 -> block 1.
Genesis 1:2 -> block 2.
Genesis 1:3 - 4 -> block 3.
etc.
etc.

It could even theoretically support:
Daniel 3:23 -> block 20000
Daniel 3:90 -> block 20001
Daniel 3:24 -> block 20002

This kind of an index is currently implicit and KJV versification
only.  I would suggest making it explicit and changable, that's all
(it seems more sensible than the Genbook route to me).

This structure is of course pseudo-code and you would represent it
efficiently, etc.

>> 2. Have a master versification scheme (probably based on augmented KJV
>> versification, since that is probably the most influential and
>> standard).
>
>> Have VerseKeys using that master scheme, getting book
>> name, chapter number, verse number, etc. out of there, and then
>> mapping to the particular versification necessary.  [not 100% sure of
>> this, because of the reordering problem - if I'm in Telugu OV and type
>> in Romans 4:16, does the user mean master Romans 4:16 or Telugu Romans
>> 4:16 - probably wiser to go for Telugu Romans 4:16, master Romans
>> 4:13].
>>
>> 3. Allow versifications and mappings to be done statically by a module
>> author rather than dynamically as has currently been suggested,
>> preferably expressed as differences from a standard versification.
>> Also allow generation of this versification from a source text?
>>
>> 4. Bible references from commentaries, etc. use this master versification.
>
> A German commentary will either use Luther or Elberfelder. It would be
> wrong to change this. And while Elberfelder is originally basically a
> KJV versification it is getting more and more assimilated from edition
> to edition to Luther's versification.  And Luther is very different.

I'll rephrase then: all otherwise not marked plain Bible references
use the master versification, since it is assumed that that is the
most common versification for the types of modules we are dealing with
(English).  You must choose something, and basing it on language ID is
probably fraught with danger.

> Basically I think you are misunderstanding the impact versification has.
> The Genbook versification idea is for me one of the most exciting
> changes to SWORD since it will finally allow that my German Bible is
> shown in GS the same way as on paper. And that is more important than
> making Matthew Henry work with Luther. Mapping will sort out latter
> eventually too.

Alternate versification is important.  I just don't see that Genbook
is necessarily the right way to do it, and my impression is that we
have gone Genbook just because we can, rather than because it is
superior.

> It is better to make something correct and then try and work out how to
> map it then to work the other way round. And the mapping work is largely
> done anyway. By others.

I think we are in agreement on the importance of versification and
mapping.  Where we are in disagreement is which is more important.  I
do believe that the mapping must be solved before it can replace what
is currently there, and I feel this more strongly because my
experience with Sword work is that work that is left until later does
not happen and certainly doesn't happen soon.

Jon