On
1/15/2014 12:31 AM, Peter von Kaehne wrote:
On Tue, 2014-01-14 at 19:07
-0800, Chris Little wrote:
I haven't looked at the code,
but the idea of mapping between
versification systems (not versifications of
particular translations but
versification systems, as we define them) is
completely ridiculous.
Teus has already given a use case. The fact that most
of our frontends
have parallel displays which do not work well with
av11n is the other
compelling one.
The need for mapping has been discussed for many years
on this mailing
list and has also been agreed. To call it 'completely
ridiculous' is
neither reflecting what has been agreed upon nor the
actual facts -
approximate mapping via an intermediate super-v11n
system in a way as
Teus describes is a lot better than no mapping.
As the person who collated all of the data and created
all of the versification systems used in Sword (with the
exception of SynodalP(rot)), I'm perhaps in the unique
position of being able to state categorically that it
is, in fact, completely ridiculous to map between
versification systems that cover more than a single
edition (or strict translations of that edition, or
translations that strictly follow another edition's
versification).
You can safely map between the KJV(A), NRSV(A), MT,
Leningrad, and Luther systems. Those are all based on a
single text. They are effectively per-module
versification systems where we included the
versification system in the library because the precise
system is used broadly or the text itself is of great
significance. (SynodalP(rot) probably belongs in this
list too.)
You cannot map between Vulg, Catholic(2), LXX, German,
Synodal, and Orthodox and any other system because these
aren't versification standards, they are best-fit
maximal coverage systems. They're more like collections
of vaguely similar (or sometimes rather dissimilar, but
similarly named) versification systems. They can be a
bit like dialect continua: Similar translations with
similar source material may have very similar
versification systems, but other pairs of translations
using the same Versification value in Sword can have
widely differing internal versification systems.
I've contemplated 'intermediate super-v11n's, as you
term them, and they're an intractable solution if they
are any help at all. Among the problems are that you
can't simply map back to a Hebrew OT based on the MT
versification system and a Greek NT based on the
GNT/NRSV versification system. Even allowing for split
verse mappings (which would have the further
complication of introducing irreversible verse folding
in one direction), there are quite a few other sources
that people have used over the years with unique verses
(the LXX & Vulgate being the most significant).
Kostya's patch for v11n mapping
is well known on this list, it has been
tentatively discussed several times, Troy has
acknowledged its presence
on his list of things to look through - though that is
a long time ago.
Troy also has highlighted various border cases which
need a solution or
suggestions for solutions. Problems with module
variability has been
acknowledged as a problem, but also by all who asked
for mapping
described as an acceptable error - i.e. better than no
mapping.
JSWORD has now initial working code.
Further, quite unlike v11n systems there is probably
no need to get it
right first time but improvements could happen in an
iterative way. In
fact, i see no reason not to allow per-module user
modification of
mapping in frontends, which would lay to rest all of
your reservations
of mapping via v11n systems.
A per-module versification mapping system would work
fine. It requires a lot of data, but it is what
commercial Bible software does. It's also explicitly not
the topic at hand. In principle, I have no objection to
or criticism of per-module mapping.
Bible1 (v11n-1) -> v11n-1
generic mapping +/- bible-1 user-modifications
-> super v11n -> v11n-2 generic mapping +/-
bible-2 user-modifications
-> Bible 2 (v11n-2)
That's four mappings. Four opportunities to introduce
error. Four opportunities to fold verses together than
can't effectively be split again. And that brings me to
the real problem with error, the real reason for which
'something' is distinctly worse than 'nothing':
With our current system (nothing), if two translations
are viewed in parallel and have the same versification
system, they will be correctly displayed in parallel. If
their versification systems do not match, they may have
some offset, but the versification systems at least
reflect the native versifications and textual
order/context of the texts.
If we start mapping on the basis of versification system
"standard", as they're defined in Sword, then when the
versification systems of two texts do not match and
texts themselves don't closely reflect the "standard",
we end up shifting verses around to positions that
reflect neither a parallel verse nor the text's native
versification. There would be a further complication,
since the idiosyncratic variation among individual
texts' versifications tends to be additive, in that
mapping may lead to widespread stranding of verses
outside their textual context.
Versification systems aren't random, but they can be so
extremely idiosyncratic that it sometimes seems like
they might be. Per-module mapping will work fine, but is
difficult to implement (in terms of data collection).
Per-system mapping will work fine for about a dozen
texts (I would guess). Any sort of reliance on
per-system mappings that involve one of the best-fit
maximal coverage versification systems (Vulg,
Catholic(2), LXX, German, Synodal, & Orthodox) will
fail spectacularly.
--Chris
_______________________________________________
sword-devel mailing list:
sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at
above page