[sword-devel] Concerns about Alternate Versification

[Greg Hellings]

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.

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

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

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

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

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

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

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.

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

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

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

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

>
> 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 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?

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.

--Greg