[sword-devel] Parallel Display of Differing V11n Systems
DM Smith
dmsmith at crosswire.org
Thu Jul 4 09:27:51 MST 2013
On Jul 4, 2013, at 12:01 PM, Troy A. Griffitts <scribe at crosswire.org> wrote:
> We have a design in place which allows for the code example I previously mentioned:
>
> lxx->setKey(nasb->getKey())
What Chris might not realize in this simple statement: In SWORD a module has the notion of current key. The module and the key each know their own versification.
>
> The engine recognized that the versifications are different and calls a facility to do the translation.
If I understand this correctly, the lxx.setKey will see that the v11n of the argument is different and needing translation by lookup. That lookup will get the equivalent for that verse. In most cases, there is no difference. In a made up example, Ps 14.1 in the NASB might be Ps 14.2 in the LXX. (Looking at the code, it always does the lookup.)
The front-end then has two current keys (verses) that it can display side by side. It can display the verse reference differences if desired.
> We have not finalized on this facility yet. As also mentioned, Костя has submitted an implementation (long long ago) available here (not sure if this is his latest version, as he is using it now in Bibletime Mobile):
>
> http://crosswire.org/~kalemas/work/v11nmapping/
>
> I am happy for his submission. We would like to include it or something based off of it, but before we finalize something in the engine for everyone to use, I want to be sure we handle the basic issues mentioned in my preceding email on this. I am not convinced I have mentioned all issues with implementing a parallel display frontend because I have not yet tried to implement a parallel display frontend which tries to implement the 'superset' view described in my previous email.
>
> Chris, you are in an ideal position to give feedback on this-- though it won't be as helpful for me or the solution within the SWORD engine, because I'm sure JSword has a completely different facility for versification classes internally. But regardless, your experience and feedback are invaluable as you drudge through this task. Let us know what you decide.
The implementation in JSword differs from that in SWORD with regard to the tables that are used for versification. SWORD reads in its tables and then optimizes them in core. JSword starts with different tables and then optimizes them in core. These optimized tables are substantially the same.
The problem with having different implementations is what is done when a bug is found in the v11n data. If the tables were the same then it would be trivial.
I think AndBible is using the tables from Костя with minor changes. STEP is using a different algorithm and tables.
In Him,
DM
>
> Troy
>
>
>
>
>
> On 07/04/2013 05:29 PM, Chris Burrell wrote:
>> I'm guess I've misunderstood as Ps.51 shows the wrong alignment between Hebrew and English for the first two verses... What are these "translation facilities currently designed in the engine"?
>> Chris
>>
>>
>>
>> On 4 July 2013 16:24, Chris Burrell <chris at burrell.me.uk> wrote:
>> I'm afraid, I'm not sure I follow. The screenshot looks ok, but then I don't read Greek or Hebrew so I don't really know.
>>
>> Are you saying Sword already has translation from 1 versification to another transparently, by " the v11n translation facilities currently designed in the engine"? From previous threads, I thought that was one major thing that was still being worked on. So you already do have all the mappings to convert from one versification to another?
>>
>> I'm confused!
>>
>> Chris
>>
>>
>>
>> On 4 July 2013 16:02, Troy A. Griffitts <scribe at crosswire.org> wrote:
>> 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
>>
>> 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
>> Sent from the SWORD Dev mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> 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
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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/20130704/8d11ad4a/attachment-0001.html>
More information about the sword-devel
mailing list