<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I agree. From a strategic point of view, I think it makes sense to
place a priority on mapping between KJV, NRSV, and Leningrad, but
then LXX is important too. Even if it is only approximate, there are
some places where it is very simple (most of the Psalms are offset
by one chapter, for example), and when it can be done, accurate
(though maybe not precise) parallel display should be sought after
to make it easier for the user. It does not have to be perfect, and
certainly such mapping does not need to reorder verses like the
German Bible Society's Synopsis of the Gospels. The user just needs
to see in a parallel display that the two Bibles are roughly lined
up. <br>
<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 1/15/14, 11:23 PM, DM Smith wrote:<br>
</div>
<blockquote
cite="mid:D7A8451E-B56F-4439-A2C2-3B20EEE20B85@crosswire.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
I think we still need to try.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.)</div>
<div><br>
</div>
<div>I'd rather start somewhere, get complaints/praise/whatever
and improve from there. That's why it is in JSword.</div>
<div><br>
</div>
<div>In Him,</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>DM</div>
<div>
<div><br>
</div>
<div><br>
<div>
<div>On Jan 15, 2014, at 10:12 AM, Chris Little <<a
moz-do-not-send="true"
href="mailto:chrislit@crosswire.org">chrislit@crosswire.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="font-size: 12px; font-style: normal;
font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans:
auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;">On
1/15/2014 12:31 AM, Peter von Kaehne wrote:<br>
<blockquote type="cite">On Tue, 2014-01-14 at 19:07
-0800, Chris Little wrote:<br>
<blockquote type="cite">I haven't looked at the code,
but the idea of mapping between<br>
versification systems (not versifications of
particular translations but<br>
versification systems, as we define them) is
completely ridiculous.<br>
</blockquote>
<br>
Teus has already given a use case. The fact that most
of our frontends<br>
have parallel displays which do not work well with
av11n is the other<br>
compelling one.<br>
<br>
The need for mapping has been discussed for many years
on this mailing<br>
list and has also been agreed. To call it 'completely
ridiculous' is<br>
neither reflecting what has been agreed upon nor the
actual facts -<br>
approximate mapping via an intermediate super-v11n
system in a way as<br>
Teus describes is a lot better than no mapping.<br>
</blockquote>
<br>
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).<br>
<br>
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.)<br>
<br>
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.<br>
<br>
<br>
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).<br>
<br>
<blockquote type="cite">Kostya's patch for v11n mapping
is well known on this list, it has been<br>
tentatively discussed several times, Troy has
acknowledged its presence<br>
on his list of things to look through - though that is
a long time ago.<br>
Troy also has highlighted various border cases which
need a solution or<br>
suggestions for solutions. Problems with module
variability has been<br>
acknowledged as a problem, but also by all who asked
for mapping<br>
described as an acceptable error - i.e. better than no
mapping.<br>
<br>
JSWORD has now initial working code.<br>
<br>
Further, quite unlike v11n systems there is probably
no need to get it<br>
right first time but improvements could happen in an
iterative way. In<br>
fact, i see no reason not to allow per-module user
modification of<br>
mapping in frontends, which would lay to rest all of
your reservations<br>
of mapping via v11n systems.<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote type="cite">Bible1 (v11n-1) -> v11n-1
generic mapping +/- bible-1 user-modifications<br>
-> super v11n -> v11n-2 generic mapping +/-
bible-2 user-modifications<br>
-> Bible 2 (v11n-2)<br>
</blockquote>
<br>
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':<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
--Chris<br>
<br>
<br>
_______________________________________________<br>
sword-devel mailing list:<span
class="Apple-converted-space"> </span><a
moz-do-not-send="true"
href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a moz-do-not-send="true"
href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at
above page</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page</pre>
</blockquote>
<br>
</body>
</html>