[sword-devel] Parallel Display of Differing V11n Systems (was: Versifications and verse order)

Костя Маслюк kostyamaslyuk at gmail.com
Thu Jul 11 08:58:22 MST 2013

2013/7/11 Chris Burrell <chris �� burrell.me.uk>

> I don't think an explicit superset is required. An implicit one yes. By
> that I mean that if you allow a versification X to map to the known KJV
> Versification with parts (say 'a' 'b', or 'firstSentence',
> 'secondSentence', etc. - i.e. arbitrary parts), then it means you can go
> from X to Y via the KJV without losing resolution.
> For the Psalms all I was intending to have is for example (taken example
> from memory for Leningrad - so might be the wrong psalm).
> Psalm.51.1=Psalm.51.0 �� a
> Psalm.51.2=Psalm.51.0 �� b
> Psalm.51.3-21=Psalm.51.1-19
> Meaning Leningrad (left) maps to the KJV verses (right). The part suffixes
> are only used if you are going from Leningrad through the KJV to say
> Synodal. If the Synodal were to declare exactly the same breakdown as
> above, also using the parts @a and @b it would mean you could end go from
> Psalm.50.1 to Psalm.50.1 as opposed to Psalm.51.1=>Psalm.51.0=>Psalm.51.1-2

In current implementation there is some kind of backward translation
procedure. In cases where translation to KJV *contracts* verses, and then
it need to expand in destination v11n, i check of how KJV translate current
verse to source v11n and if there is expansion, i choose which verse i
should display. In other words it anyway will be

Or maybe i loose something?

> In the above, the superset of keys really is:
> Psalm.51.0 �� a, Psalm51.0 �� b, and Psalm.51.1, Psalm.51.2, etc.
> Yes but when i try to map this superset to another v11n, what i should
expect to get?

Ps.51.0 + Ps.51.1 + Ps.51.2 - first entry
Ps.51.0 + Ps.51.1 + Ps.51.2 - also second
Ps.51.2 + Ps.51.3 - third, and so on for each module?

> You could obviously chose more meaningful part names say:
> Psalm.51.1=Psalm.51.0 �� repentance-prayer
> Psalm.51.2=Psalm.51.0 �� bathsheba-intro
> Or obviously, just keep track somewhere of what those parts really mean in
> practice.
> I think in terms of displays, there are really many options. Two things
> I'm looking at:
> * warning the user if for some reason we're displaying more verse ranges
> than the original passage... In other words, if we've broken 1 range into
> 2, and therefore omitted displaying some verses (because they don't map to
> the original passage), then we warn the user to say "it's not an error, and
> you're not seeing everything on purpose). The alternative is to somehow
> decide to show the missing verses - and then the complication is where do
> you put the missing verse in the verse order.
> * warning the user if you're displaying a verse more than once (nice to
> tell the user, hey, because of versification issues, this verse shouldn't
> be there twice, but we think it's beneficial to display twice because it
> really does map to both source verses).
> * Absent verses, I'm leaving blank at the moment.
> Chris
> On 10 July 2013 17:02, Костя Маслюк <kostyamaslyuk �� gmail.com> wrote:
>> Sorry, when i try to imagine your conception of 'superset', i found
>> verses scattered all around the room after translation procedure. Have you
>> any visual representation of what you would like to achieve in final, or
>> would you make such a table by your self?
>> Should verses content be always equivalent in parallel view?
>> What a text should fill the gaps? This is most confusing to me, module
>> simply does not contain corresponding content, haven't clue what it could
>> be...
>> If we start to translating ListKey superset and displaying its content,
>> we can got long enough recursion, for example in Psalms, all the book will
>> be displayed when user request verse in chapter #3.
>> I have added rough draft of Parallel display with respect of av11n
>> mappings in BibleTime Mini:
>> https://www.dropbox.com/s/11a3dvdz0yu8xf3/boundle.zip
>> 2013/7/4 Troy A. Griffitts <scribe �� crosswire.org>
>> Hi guys. The questions that need answers in this thread are logically
>>> complex and are one of the reasons we haven't finalized any additions to
>>> the core SWORD library to support this-- though I greatly appreciate the
>>> contributions made by Костя.
>>> Take, for example our standard 4 Bible web display preset for "OT
>>> Scholar", at Daniel chapter 3, around veres 23:
>>> http://crosswire.org/study/**parallelstudy.jsp?del=all&add=**
>>> NASB&add=WLC&add=KJV&add=LXX&**key=Dan.3.23#cv<http://crosswire.org/study/parallelstudy.jsp?del=all&add=NASB&add=WLC&add=KJV&add=LXX&key=Dan.3.23#cv>
>>> How should this look?
>>> The problem, for the uninitiated, is that The Prayer of Azariah and the
>>> Song of the Three Jews in the LXX is inserted between what we traditionally
>>> think of as verses 23 and 24. This makes verse 24 in the KJV very different
>>> content than what should be verse 24 in the LXX (our current LXX displayed
>>> from the link above does not include Apocryphal content)-- verse 24 in the
>>> LXX being the first part of the Apocryphal content, thus verse 91 in the
>>> LXX picking back up where verse 24, in say the NASB (without the apocryphal
>>> insertion), continues.
>>> The web interface above always displays in windows of 1 chapter. Thus
>>> the user has asked for Chapter 3 of Daniel, centered on verse 23.
>>> There are a few questions to answer.
>>> What if they had asked for verse 24?
>>> What content do we show?
>>> Use case: The user is a protestant pastor, has chosen NASB as his
>>> primary Bible, and is interested in seeing the parallel verses to the NASB
>>> in the other texts. He is not interested in seeing apocryphal insertions.
>>> He primarily cares about the NASB and only glances at the content from the
>>> other modules when interested in seeing the parallel.
>>> This is how the web frontend, and all current SWORD based frontends
>>> *should* currently work with no code changes, with the v11n translation
>>> facilities currently designed in the engine. It uses the first module as
>>> the "master" and iterated its key and pulls the equivalent verses from the
>>> other modules. The current facility in the engine allows for:
>>> lxx->setKey(nasb->getKey())
>>> resulting in the LXX being positioned to the equivalent verse (e.g., v91
>>> from nasb v24)-- if translation tables (for example from Костя) were in
>>> place.
>>> But this use case, while likely the most dominant, is not the most
>>> scholarly. A scholar would likely wish to see a *superset* of all verses
>>> from all displayed parallel Bibles, inserting gaps where they should go in
>>> the other text which do not contain the verses.
>>> Not too hard to imagine, but what is the programmer-friendly API
>>> interface for this? Harder to imagine. You can't simply choose one of the
>>> modules to iterate.
>>> Possibly:
>>> ListKey superset;
>>> superset << kjv->getKey() << nasb->getKey() << lxx->getKey() <<
>>> wlc->getKey();
>>> then one could iterate the superset listkey.
>>> This would leave the work of figuring out where the gaps should go up to
>>> ListKey, or something in the translation system in VerseKey which backs
>>> ListKey.
>>> It's a complex problem, but we haven't even talked about the issue of
>>> reordered content. Sometime Romans 16:25-27a (obviously excluding the
>>> subscriptio) is located after Romans 14:23. This is an example of
>>> reordering. It doesn't give problems from our "chapter window display"
>>> because the reordering is across different chapters and you could still
>>> pick your poison from the 2 choices above for display logic, but what about
>>> display windows which allow more than a single chapter, like BibleDesktop?
>>> Now the question arises. If you've chosen to build a superset, where do the
>>> gaps go? You could reasonably add them to either place (after Romans 14:23
>>> in the modules which don't include the doxology here or after Romans 16:24
>>> for modules which don't include the doxology here). How do you decide? How
>>> should the program decide?
>>> Lot's of questions and input we all need to give and a working proof of
>>> concept for at least a single frontend before we commit to something for
>>> everyone to use in the engine.
>>> Obviously not a 1.7.x issue, but feel free to continue to give input.
>>> Troy
>>> On 07/04/2013 03:26 PM, David Haslam wrote:
>>>> And (for example) if you wish to query the whole of the JPS module
>>>> using book
>>>> names, it will not do to specify *Gen-Mal*.
>>>> You'd need to remember that in the Tanakh, the last book is *II
>>>> Chronicles*.
>>>> --
>>>> View this message in context: http://sword-dev.350566.n4.**
>>>> nabble.com/Versifications-and-**verse-order-tp4652697p4652712.**html<http://sword-dev.350566.n4.nabble.com/Versifications-and-verse-order-tp4652697p4652712.html>
>>>> Sent from the SWORD Dev mailing list archive at Nabble.com.
>>>> ______________________________**_________________
>>>> sword-devel mailing list: sword-devel �� crosswire.org
>>>> http://www.crosswire.org/**mailman/listinfo/sword-devel<http://www.crosswire.org/mailman/listinfo/sword-devel>
>>>> Instructions to unsubscribe/change your settings at above page
>>> ______________________________**_________________
>>> sword-devel mailing list: sword-devel �� crosswire.org
>>> http://www.crosswire.org/**mailman/listinfo/sword-devel<http://www.crosswire.org/mailman/listinfo/sword-devel>
>>> Instructions to unsubscribe/change your settings at above page
>> _______________________________________________
>> 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
> _______________________________________________
> 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
----------- ???????? ????? -----------
???????? ? ??????? HTML ???? ?????????&hellip;
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20130711/6e2c610b/attachment-0001.html>

More information about the sword-devel mailing list