[sword-devel] 1.7.2 release

Wed Jan 15 08:23:00 MST 2014

I think we still need to try.

If I had a bunch of paper Bibles that had different v11ns and (presuming I could read the variety of languages) sat down to line them up, I would find that it is hard because it is in front of me. If I were a novice, I might be royally confused, but that would be the case even if I could line them up.

However, we line them up poorly today. Having some help in the app is better than assuming that the first Bible in the set is the authority on what the verses are. It may be that we need to allow the user to do the lining up. (e.g. move a passage up/down in one column until lines up with another.)

I'd rather start somewhere, get complaints/praise/whatever and improve from there. That's why it is in JSword.

In Him,
	DM

On Jan 15, 2014, at 10:12 AM, Chris Little <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
>> 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140115/4036d35f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140115/4036d35f/attachment-0001.p7s>