[sword-devel] Alternate Versification question

Andrew Thule thulester at gmail.com
Mon Aug 13 12:10:36 MST 2012


Actually this whole business raises another issue.  In the collection
of modules I've been building up, I've added Dead Sea Scrolls texts as
OSIS (but have not yet created modules for them, pending working
though versification issues).

For biblical scrolls, versification isn't so much an issue, since they
can match which every versification system the module creator selects.
 For some non-biblical scrolls (such as 11QPs) since they do show up
in other versification traditions such as the Septuagint, they too can
be incorporated.   But many of the DJD translations/transliterations
are non-biblical scrolls, or fall out of typical versification
systems, though do naturally suggest one based upon where they were
found.  (i.e all 4Q... scrolls were found in Cave 4 at Qumran, all
11Q.. scrolls were found in Cave 11 etc).

What is the recommended approach for all other materials in terms of
turning them into modules?  (I guess I'm saying - I half expected
working through the versification system for the LXX and the LXXE
would have put me in a better position to create a versification
system for the DSS, but now I'm not sure which way I should go (in
terms of making a DJD module (Discoveries from the Judea Desert)?

~A

On Mon, Aug 13, 2012 at 2:43 PM, Andrew Thule <thulester at gmail.com> wrote:
> On Mon, Aug 13, 2012 at 1:48 PM, Chris Little <chrislit at crosswire.org> wrote:
>> Because we don't do dynamic loading of versification systems, whenever we
>> add a versification system to Sword, it takes up space in memory just to
>> hold the versification tables. Accordingly, we try to be as conservative as
>> possible in adding new versification systems. And once we have released a
>> Bible using a versification system, we can never change or remove that
>> versification system from the library. So we have to be extremely careful
>> that the versification systems we include in the library are correct.
>
> Greg wrote: "If the one you need isn't supported (I don't see LXX or
> GNT at present) then you're welcome to create such a file and submit
> it along with your module."
>
> I  must have mistook your earlier comments as well.. I implicitly took
> them to mean you're normally not open to having versifications
> submitted, but because you were already working on one be open to
> having an LXXE versification submitted.  I wouldn't have not wasted my
> time working one out if I had know there was not chance of influencing
> these things.
>
> Given that you have to be extremely careful as to which versification
> systems you include in the library, how do I go about incorporating it
> privately?  Is it a matter of including the canon_xxx.h file
> somewhere?  Whether the one I submitted gets distributed or not, I
> still require it for an English version of Brentons text for the LXXE
> module I've created.
>
>> We have two types of versification systems that we will add to Sword. The
>> first type is for particularly important individual texts, generally
>> specific manuscripts or editions. The Leningrad and Luther versifications
>> are in this category. Leningrad is used for exactly one manuscript, though
>> it appears in 2-3 modules, but it's of such significance that we added the
>> versification system to Sword. Luther, similarly, is employed specifically
>> by a set of translations by a single translator.
>>
>> The other type attempts to formalize a versification system representative
>> of numerous Bibles within a tradition. Examples of this include the KJV(A),
>> NRSV(A), Synodal, Catholic, & Catholic2. KJV(A) & NRSV(A) happen to exactly
>> match particular translations, but those versification systems are in wide
>> use beyond those translations. Synodal and the two Catholics began with the
>> versification systems of exemplar translations and were then expanded to
>> incorporate additional verses from translations within the same tradition so
>> that the system within Sword could achieve maximal coverage of the verses
>> within Bibles we might encode.
>>
>> Versification systems for particular manuscripts or editions are relatively
>> easy to define and incorporate in Sword, provided the edition they represent
>> is sufficiently significant to merit such treatment. The next versification
>> system that we'll add to Sword will be of this type, and that's Rahlfs,
>> representing Rahlfs' LXX. To construct it, I'll derive the versification
>> system based on a couple of independent encodings of Rahlfs', compare them,
>> and break any ties using the printed text of the DBG.
>
> Perhaps the Septuagint (in English) isn't significant enough to
> warrant such treatment .. but users willing to generate their own
> versification systems, especially ones based upon historic documents,
> should still be able to influence module creation shouldn't they?
> Module creation presupposes a versification system, and it seems (to
> spectators at least) there's been pressure last few revisions to open
> up support for more.  Personally, I don't care one way or the other if
> Crosswire is not interestd in the one I just submitted.  I am
> interested though (as a module creator) that every time I OSIS2MOD my
> LXXE it appends ridiculous amount of verses onto chapters in a
> versification system neither the underlying Greek, or the English
> translation employ.
>
> So restricting module creation to versification system 'officially
> sanctioned' by Crosswise, however sound the logic behind imposing
> distribution restrictions, seems arbitrary.  Either provide an
> official Septuagint versification system close, or allow the user to
> specific their own.
>
>> Creating a versification system for Sword based on a broader tradition
>> requires identifying a distinct tradition, collecting many different
>> translations within that tradition, comparing them, and deriving the maximal
>> verse set that covers all of them. The first two parts require quite a lot
>> of work.
>>
>> Your LXXE versification system is not a candidate for inclusion in Sword
>> because it neither represents a broad versification tradition nor a
>> particular edition of sufficient significance. Without even looking at the
>> file, I can know that it does not represent Brenton's LXX because the
>> versification of Brenton's LXX is not supportable by Sword. Multiple verses
>> of the same number within a chapter and verses that do not strictly increase
>> cannot be represented by a SWText module, as currently implemented. Brenton
>> includes both of these and so its native versification cannot be supported
>> by Sword.
>
> Respectfully, I disagree.   I made every effort to confirm Brenton's
> English versification matched the typical underlying Greek LXX's
> formats; and that the underlying Greek format he matched was
> widespread.  By virtue your own comments explaining my observations
> about the mess in Sirach 30-36 shows that I've largely matched the
> underlying Greek (except where the Greek is inconsistent).
>
>  This hows that I've done this diligently.  Otherwise, if the LXXE
> versification system doesn't match the broad versification tradition
> of LXX, I'd happy to amend any errors you see.  If you look at it,
> you'll see this is a widespread LXX versification.  Or are you saying
> LXX isn't a broad versification tradition?
>
>
>> In short order, the Rahlfs versification system should be available in Sword
>> SVN. That may suffice for your encoding needs in the near term.
>> Subsequently, it may be possible to define a more general LXX versification
>> system that excludes the Rahlfs'-specific books like the variants of Joshua
>> & Judges, the Theodotian variant books, Odes, and PsSol and that adds verses
>> absent from Rahlfs' in order to maximize verse coverage in similar editions.
>> I'll certainly consult your versification system submission while working on
>> that. Going forward, that might be a better candidate for the versification
>> system employed by a Brenton module.
>
> I'd be happy to give it a try, once its available.  Feel free to
> consult the one I've submitted in the production Rahlf's-specific in
> the meanwhile.  It wasn't done mindlessly or without due care and
> attention and comparison to the broader LXX formats.
>
>>
>> On 08/12/2012 11:37 PM, Andrew Thule wrote:
>>>
>>> Thanks Chris.
>>>
>>> Here's an English Septuagint versification system, based upon the text
>>> I got from Michael  and compared to a number of printed version.  The
>>> Chapter order doesn't quite follow the KJV or NSRV convention, but it
>>> does follow the Septuagints order.
>>>
>>> I appreciate it if you could add this so we can get an English
>>> Septuagint module out.  I worked on this weekend quickly because I've
>>> seen you reference you're working through another one, and I wanted to
>>> get it in on your timeline.
>>>
>>> One question - I stuck with the names listed in the abbrevs.h and I
>>> understand that the short forms as markers.  So for example the
>>> Septuagint calls the Prayer of Azariah the Song of the Three Children
>>> (in Greek) and Breton translate it as such - yet the marker will be
>>> PrAzar.  I have no issue with that, but how do I now influence the
>>> appearance of the book names (however the program deals with them).
>>>
>>> I see this can be done in locales, but is that the right place for it?
>>>   I'd like to keep the Greek influenced names - since the original
>>> language was Greek.  I.e.
>>> Esias for Isaiah
>>> Jermias for Jeremiah
>>> Osee for Hosea
>>> Aggaeus for Haggai
>>>
>>> Etc.
>>
>>
>> There is no way for module authors to influence how titles appear in front
>> ends, as far as verse pickers, searching, etc. are concerned. You can always
>> add a <title> element before the first chapter of the book. Then the front
>> end should print the title above chapter 1.
>>
>>
>> --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



More information about the sword-devel mailing list