[sword-devel] Concerns about Alternate Versification

[Jonathan Morgan]

On Tue, Jan 6, 2009 at 2:51 PM, Greg Hellings <greg.hellings at gmail.com> wrote:
> On Tue, Jan 6, 2009 at 1:49 AM, Jonathan Morgan <jonmmorgan at gmail.com> 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:
>
> The question remains, though, in whose Bible are we talking?  Your
> experience of the "average user" is not necessarily the same as that
> of someone who lives in central Italy, nor of someone who lives in
> central Ethiopia, nor of someone who lives in Moscow.  It's bigger
> than KJV/RSV/NIV/etc.  There are whole separate canons.  When I say
> "Genesis 3:2" I don't know of anyone who gets confused, but when I say
> "Daniel 3:24," there is no guarantee I know whose Daniel 3:24 I'm
> referring to.  There are two of them, and either is equally valid.
> The only person who knows the correct one is the module creator (and
> sometimes then, even they might not know, as in the case of the
> Jerusalem Bible which has two verses labeled "Daniel 3:24").  By
> giving the creator complete control over the ordering, presence or
> naming of the full text, they can do as they need to represent the
> text faithfully according to their requirements.

And then the creator should reference it as according to the versification.

>> 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".
>
> But that's fine for TSK, but what if I create a module that is not
> keyed off of your version.  Say I create a module of the Catechism of
> the Catholic Church.  For sure that's going to use one of the standard
> Catholic versifications.  I, as the user, should have the right to
> specify what I want for my default Bible module, because I know that
> the Catechism is my most frequently used reference, and I use
> commentaries from a renowned Catholic scholar and I happen to be a
> language buff, so I pick the Vulgate for my default module.  I, as the
> user, want that Vulgate to properly represent a printed copy, not be
> conformed to your egocentric concept of "my Book CC:VV is the same as
> everyone's."

Then the user creating the module should create it as right as
possible to refer to the right versification.

>> 2. If I want to produce a list of references on a particular topic,
>> that list is almost always version independent.
>
> None of the ones I've seen claim that.  They all are either within a
> Bible themselves, or disclaim at the beginning, "Quotations are from
> such-and-such a version, unless otherwise indicated."  To be honest,
> most of our verses are the same from one version to another - yes -
> but not all of them are.  Actual places where one reference points to
> a different verse in version A than in version B, especially within
> the same translation language, are minimal.  Most of the difference
> comes down to reordering and omission.  But for those places that are
> different, it is important that the module creator have some way of
> clearly representing the original source, or their original intention.

Yes, but if I make a list of verses for my own reference I want to
access them in multiple versions - mapping needed.

>> 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).
>
> Then what we need is a mapping between them - we don't need to do away
> with them, nor do we need to do away with the Genbook implementation
> of them.

That's what I said.

>> 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.
>
> Proper mapping would, I imagine, be a requirement of the module
> creator.  Only they will know the actual mapping between any two
> versions.  Whether the choice of target display is decided by the
> module creator specifying, "Display Book CC:VV in version XYZ" or
> whether it's the user's choice of always opening references in their
> preferred version is possibly a matter of debate.  I know I would
> answer it differently if I was sitting there trying to create a module
> than I would if I was trying to read someone's.  Especially this
> becomes important for accessibility reasons.

So we need to draw some difference between referencing a Bible version
(which I don't like) and a versification (which could then be mapped
to the different versification of my preferred Bible).  I still say
default is KJV.

>> Producing a proper mapping is not an easy problem, 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.
>
> Again, the onus for this should be placed on the module creator.  I've
> never heard of Telugu, and I'm sure there are plenty of versions
> you've never heard of.  No committee of us here can dictate what all
> the proper mappings are.  Even the concept of "the standard
> versification" is impossible to define, since there are many
> standards.  Perhaps your Telugu OV is standard... for Telugu.  But
> even the source languages themselves differ between manuscripts
> sometimes in their ordering and content.  So to claim there is a
> "standard" that everyone can just point to is to open us up to have to
> maintain lists upon incomplete lists of all the possible mappings.  If
> the module creator wants to specify something, let them.

But it has to then go from what they specify to my preferred version.

>> 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.
>
> Who are you to say that /Gen/something or other/some random text/2/3
> is invalid?  Perhaps I, as the module creator, want to have every book
> of the Bible broken into an outline format.  Then I can do something
> like: /Gen/Prolog/Creation and Fall/Second Creation Story/2/3.  This
> is what is nice about Genbooks as the implementation of this.
> (Granted, I haven't yet created a module with the alternate
> versification code, and I don't know if the implementation allows for
> that much text in the middle, but allowing it is a good thing, not a
> bad one, as it allows the module creator to have finer control over
> their creation of content).

It will not be displayed properly.  That kind of formatting is already
provided by OSIS - why would you want an incompatible Sword specific
thing?

> Currently SWORD only has 3 base module types that I know of: Lexicon,
> Genbook, Bible.  Bible under static versification is almost useless if
> you're not encoding the KJV or something with identical layout and
> content, or at its best, forces you to shoehorn your content into the
> KJV.  Lexicon isn't particularly useful for Bible layout (though it
> could be a means of providing versification mappings?).  That leaves
> Genbook, which has a vastly less rigid layout than the Bible form
> currently in SWORD <=1.5.11.  So as to your question of why it is
> technically superior to use Genbook than something else - its the only
> format that fits the bill for what we need and wouldn't need to be
> coded from scratch.

Exactly: and I say that is the wrong argument to use.  We should have
something that suits the problem, and I'm not convinced Genbook does.

>> 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.
>
> But the current one doesn't have nearly enough to support anything
> other than the Protestant, KJV-based canon.  Forget other languages -
> we can't even properly represent all of the native English
> translations.

See my email to Peter.

>> 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].
>
> Reordering is taken care of in your scheme - but what about versions
> that split verses?  I went to look up a scripture for my friend the
> other day in Jeremiah.  He had quoted to me from a Protestant English
> translation and I was looking it up in a Catholic English translation.
>  Lo and behold, my version gave something to the like of verses 9a, 1,
> 2, 3, 4, 5, 9b, 10, 11a, 6, 7, 8, 11b, 12.  Are we going to have a
> static form that has every possible split in every published version
> of the Bible?  It's much simpler to have a Genbook - then no extra
> space is added for a lookup table (unless the module creator wants it)
> and no extra space is wasted in empty verses, extra linkages or
> keeping track of reorderings, beyond what is actually used in the
> module.

No space is being wasted on empty verses: you aren't understanding the
format.  Keeping track of reorderings is also handled directly by the
format.

>> 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?
>
> If it's done "statically by a module author," then it's being done
> dynamically.  That's the basis of dynamic versification - each module
> creator is able to dynamically give their own versification layout,
> content and ordering.  You're just going for a different name.  As for
> the mapping - I support letting the module creator do that if they
> want to.  Figuring out a standard way would be the next step -- hidden
> Lexica modules, map files included with the source of the module, etc.
>  All of them are valid possible ways.

My point is: as was currently suggested a Genbook was being read every
single time to determine its versification (from memory), presumably
checking every key.  Specifying this externally and as a difference
from an established versification might be better.

>> 4. Bible references from commentaries, etc. use this master versification.
>
> Then the module creator needs to go through and convert all of their
> references to that master versification.  Why would we do that when we
> can just tell them they have the right to specify a preferred module?
> One front-end might decide that the user is free to over-ride that, to
> their own possible confusion, but that allows the module creator to
> create the module correctly, instead of having to transfer it to a
> master versification.  Think of how confused a user would be if they
> click on a reference that says, "Matthew 3:17" and are taken instead
> to their favorite Bible module to the key "Matthew 2:27."  Sure, it
> might have the right content, but they would think the system was
> broken - and I don't blame them.  Likewise if I see a print copy of
> Matthew Henry's that refers me to Psalm 150:1 and then open SWORD and
> want to read the passage there some other day and it has been changed
> to Psalm 151:1 because of the differences in Psalm numbering - I'd be
> utterly confused and would report invalid module content.

Think how confused they would be likewise if the verse didn't say
anything like what the commentary said it did.  Which would you
prefer?

All I am saying is "Make bible: equivalent to KJV_versification:",
since that is most common.  There is certainly a need for references
in other versifications.

>> I'm not sure such a scheme will handle every possible versification,
>> but that is not really important, IMHO.  It should be able to support
>> all kinds of oddities as things in the master versification that have
>> no equivalent in most Bibles (e.g. Book: Daniel, Chapter: 3, Verse:
>> 90).  Then the particular Bible concerned has a mapping from there and
>> everyone is happy - if it is really a version specific oddity no-one
>> will mind too much that there is no mapping to other versions, so long
>> as it can be represented.
>
> Why would no one mind?  And who's to say what is "most" Bibles?  I
> daresay I'd be willing to bet that most Bibles have Daniel 3:90 in
> them.  Do realize that the Protestant canon, which does not have that
> verse, is only in use by a TINY minority of Christians compared to
> those who use the Catholic, Orthodox and other verifications.  And why
> should we adopt this model, which might not represent some things,
> when we have a model in place that represents everything and can be
> extended by adding extra files through the module's configuration for
> such things as mapping between versifications, etc?

I said that they are represented, just not in a readily mappable way.
Anyway, whatever you do I as a frontend author am saying "we have to
have an independent verse reference that we can store and work with".
I am agreeing that the string "Daniel 3:24" is not a useful way of
storing references, but I think we need a better one that is not
"Daniel 3:24 in version X whether or not you like version X".

>> I think we also need to consider very carefully how we encode Bibles
>> that have Aprocryphal additions in the main text (in Esther, Daniel,
>> etc.).  I personally think that it is just as silly having a KJV with
>> apocrypha and one without as it is to have a KJV with strong's numbers
>> and one with WoC in red and one without (e-Sword, anyone?).
>> Therefore, I think we should consider having display options to turn
>> on or off apocryphal additions (at least ones in the main, canonical
>> text) in the same way as we have display options to turn on or off WoC
>> or strong's numbers.  I have no idea whether this is supported by
>> OSIS, but I seem to remember there is a canonical attribute that might
>> support this kind of action.
>
> So how do we label them?  "<v osisRef="Dan.3.77"
> canonical="not-considered-by-Protestants-as-such">"?  Because the
> reason that they're in that version is because they're probably
> considered canonical by someone.  Daniel 3:24-90 was considered
> canonical for a long time and by many people.  Some people would even
> claim that Jesus himself saw those "extra-canonical" or "apocryphal"
> books as canonical.  There are still others who would claim that some
> of the apocalyptic writings of the Essenes may have been considered
> canonical by some, very likely even by them.  So whose criteria should
> be applied to those which are visible in a "canonical" form and whose
> criteria should be ignored?  Is that something we, as the developers,
> should decide?  Should we let the module creator decide?  The
> front-end programmer?

If it is OSIS markup, it is obviously the module creator that decides.
 And I don't know what the canonical means in OSIS if it is there as
my memory tells me.

> To me, it makes excellent sense to have multiple versions when what
> differs is the textual content, and not the supplemental material like
> the WoC and Strongs, etc.  For the same reason there are NRSV and
> NRSVA analog Bibles around, it makes sense for us to have a KJV and
> KJVA around.  I think the bigger issue is where are they placed in the
> module and in what order are they displayed?  That's another thing the
> Genbook is good for - it allows the module creator to either lay out
> the books as OT, Apoc, NT or OT (with apoc integrated), NT - depending
> on their source text and intentions.

And that is perfectly supported by my suggestion.

Jon