[sword-devel] 1.7.2 release

[Chris Little]

Chris,

Briefly, no, you didn't get any mappings to work that wouldn't obviously 
work. Based on your mappings at 
https://github.com/tyndale/jsword/tree/jsword-tyndale-master/src/main/resources/org/crosswire/jsword/versification, 
your successes fall in three categories:

Leningrad, Luther, MT, & NRSV mapping to KJV will work fine because 
they're single-translation to single-translation mappings. They're 
essentially per-module mappings because those translations that use this 
set of versification system definitions use those versifications very 
regularly and precisely. (There's actually some slight variability with 
NRSV-versified texts, since any translation with either of the verses 
added relative to the KJV will be categorized as NRSV-versified. But 
that's minor--as is the variance between the KJV & NRSV systems itself.) 
These account for 35 of the 53 non-KJV(A) versified translations we 
distribute.

Synodal mapping to KJV will work well for the two Russian Synodal 
Bibles, of course. They were the primary exemplars for the system's 
definition. I would estimate it will work less well for the two 
non-Russian Bibles and rather poorly for the Church Slavonic Bible. 
However, there's a chance we'll favor Orthodox over Synodal for many of 
these sorts of translations, going forward, so Synodal might move into 
the above category of being a single-translation system. (This accounts 
for 5 of our 53 non-KJV(A) versified translations.)

Vulg mapping to KJV will work well, to the extent you have defined it, 
because you've only got mappings for a few verses outside of Psalms. 
Psalms are fairly easy to reliably map to/from because they are 
versified in the originals, so there are only two parameters of 
variation, each with two possible values (whether to number the titles 
and whether to follow Hebrew or Greek numbering of the Psalms 
themselves). Thus, there are four major Psalm versification systems, 
with far less variation than we see in other books. (This accounts for 9 
of 53 non-KJV(A) versified translations.)

The last set of mapping data you have (German) is presumably just copied 
from the Luther mapping. I predict it's not likely to work well at all, 
especially for the non-German-language texts.

This is all to say that, yes, translation-to-translation mapping will 
work great. To the extent that versification system definitions in Sword 
reflect a single translation's versification reliably, mapping between 
them will work fine. Beyond that, everything breaks down. You haven't 
actually approached any remotely difficult cases.

--Chris



On 1/15/2014 12:08 PM, Chris Burrell wrote:
>
> On 15 Jan 2014 15:13, "Chris Little" <chrislit at crosswire.org
> <mailto:chrislit at crosswire.org>> wrote:
>  >
>  > 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
>
> Jsword simply uses kjv as intermediary and copes for bidirectional
> splits/merges across kjv as well as extra/missing verses,  chapters. The
> fact that kjv has, has not or has a different mapping is irrelevant and
> you can go from a to b without losing resolution.
>
>  >> 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.
>
> Anything is better than nothing. And it usually is the case that all
> Catholic Bibles will have roughly the same mapping. As you say they are
> often collections of similar versification systems. In particular it's
> useful for those commonly offset verses belonging in both kjv and other
> text.
>
>  >
>  >
>  > I've contemplated 'intermediate super-v11n's, as you term them, and
> they're an intractable solution if they are any help at all.
>
> That's exactly what we have in jsword so definitely not intractable.
> They work quite well.
>
>  > 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),
>
> Not true. We have bidirectional splits and JSword doesn't suffer from
> verse folding.
>
> 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.
>
> Would be interested to hear which as we've solved a number of these in
> jsword.
>
> 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.
>
> That's unacceptable for several reasons. 1- Makes interlinears
> impossible to do properly with lots of empty words all over the place.
> 2- Issues arise frequently over chapter boundaries and most
> users/frontends work by default with the unit of chapter. 3- Makes
> automatic word by word text comparisons/diffs impossible especially in
> Psalms for example due to headings vs verse 1 where the problem is
> easily solved
>
>  >
>  > 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.
>
> Again not true of JSword. For example, you can simply map parts of
> verses to other parts of other verses in any order you like. The two
> limitations are that you will only ever display at a minimum the whole
> verse in each case (not usually an issue and you can display these
> verses with explanations). And within the same versification you can't
> currently make new mappings (fixable). But you can map any part to any
> other part against any other verse or verse range(s) of your choice. You
> can declare as many parts as you like and name them whatever you like.
> Parts are just always held against non-kjv versification.
>
> I don't understand the shifting issue. Surely you follow at least the
> order of verses in one versification. At least, we do.
>
>  > 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.
>
> That's purely an implementation detail of how you use the mappings. And
> where we detect issues,  we mark these outfor the user.
>
>  >
>  >
>  > 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 at crosswire.org
> <mailto:sword-devel at crosswire.org>
>  > http://www.crosswire.org/mailman/listinfo/sword-devel
>  > Instructions to unsubscribe/change your settings at above page
>
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>