[sword-devel] Av11n and coverage

Sat Jan 7 15:05:41 MST 2012

Hi,

I'm not a coder, just an interested theological student. I am excited about 
this debate. Logos does this and it would add a lot to SWORD-based programs if 
versifications were mapped like that. So, this is great from an academical 
point of view

I clearly cannot answer from a coder's perspective, but I can tell you about 
versification. It is not going to be simple. The good news is that you will be 
able to set a standard versification that you could define all the others 
against. I would suggest using the BHS versification for the OT and the 
UBS4/NA27 versification for the NT (SBLGNT would work too, but it's a few 
verses shorter that will likely be in many translations). 

To give you an idea about the diversitiy of versification systems. Different 
book orders have already been mentioned in this discussion. But there is also 
different traditions in handling e.g. longer Psalm titles (as verses in their 
own right, or as just preceding verses?). The English versification is very old 
and traditional, but unfortunately mostly deviates from the original texts in 
this. 

But the question, most of all, is one of textual basis. And every translation 
handles that differently. For example, some translations don't include Mark 
16:9-16 or the pericope adulterae in John. Some translations believed that 
some paragraphs in the OT were in the wrong order. That results in the NRSV 
and others clipping a few verses out of a chapter of Zechariah and adding them 
to a different one. And that's only one case that I know of. A mess! And then 
you have the Septuagint, with an alternative Psalm counting system and several 
additions to some books like Daniel and Esther, and it counts Ezra and 
Nehemiah as one (called 2 Esdras). 

A mapping system would have to be able to account for all of those to do its 
job at all. I think it would have to be done individually for almost every 
translation. The current v11n systems would definitely have to be extended, at 
the least. 

It seems that somebody at openscriptures.org has already started to work on 
something like this, and has collected v11n systems: 
http://openscriptures.org/blog/2011/01/bible-organisational-system/ 

Ben

Am Samstag, 7. Januar 2012, 13:59:36 schrieb Paul A. Martel:
> Versification mapping sounds very useful. Is there any
> agreement/design/plan for what it would actually entail?
> From my uninformed perspective, it seems like there could be lots of
> ambiguity or disagreement about the "use cases" and priorities
> especially if there needed to be a staged implementation.
> 
> Has the question "What kinds of differences can two v11ns or canons have
> and still be usefully mapped?" been discussed and resolved to any depth?
> 
> There may even deeper questions like:
> 
> - Can or should all v11ns be defined normally in such detail that all
> possible mappings to other v11ns becomes a purely mechanical inference
> process?
> 
> - If not, can or should the versification mapping process consist of an
> abnormally detailed independent analysis of each v11n, after which the
> mappings to other v11ns similarly analyzed becomes a purely mechanical
> inference process?
> 
> - If not, would each mapping between any 2 particular v11ns have to be hand
> authored and "coded" in some way (possibly something more like a conf file
> than a C++ header file, but "different arts for different parts...").
> 
> Or is there some compromise in which the mechanical inference does most of
> the work, based on details specific to each canon and v11n, with hints or
> customizations for any particular v11n pairing optionally coded by some
> author?
> 
> Maybe another way of asking these questions is:
> 
> Is there or could there be a v11n equivalent of the "Periodic Chart of the
> Elements" in which each element identifies an indivisible "atom" of
> scripture content so that each v11n could define (or be defined AS) a
> mapping to its component atoms? If so, it should be a simple matter to
> transitively map one v11n's arrangement of those atoms to another v11n's
> arrangement of those same atoms (each analyzed in isolation) to
> automatically infer the mapping between any 2 v11n's and to identify where
> there are no mappings due to canonical differences.
> 
> Or is this approach impractical, and so we are better off with a less
> formal approach, like one that assumes that the number N of v11ns is small
> and will stay small and that the mappings between any 2 v11ns will mostly
> be simple and will follow common patterns, so someone (possibly even just
> the same C++ priesthood, bless 'em, that maintains those canon header
> files) could humanly keep up with N x (N-1) hand-coded mappings.
> 
> I just find it an interesting problem.  Maybe it's something a new
> volunteer with some programming skills could kick around, regardless of
> chickens or eggs.
> 
> --paul
> 
> On Fri, Jan 6, 2012 at 8:54 PM, Daniel Owens <dcowens76 at gmail.com> wrote:
> > Yes, mapping! I don't have strong opinion about how this works out on
> > the
> > engine side of things, but proper mapping between versifications for
> > front-ends that support parallel display is essential for doing work
> > with
> > Old Testament Hebrew and Greek texts and with modern translations.
> > 
> > I have happily used BibleTime frequently in my dissertation because it
> > supports parallel display and effectively uses the mag window to display
> > lemma and morphology, which I much prefer to the clutter of Strongs
> > numbers in the main screen. But putting two Bibles side-by-side (which
> > I do almost all the time) creates problems. When I put the ESV
> > side-by-side with OSMHB or the forthcoming Wesminster Hebrew
> > Morphology, it is a mess. Content invariably gets dropped at the end of
> > the chapter. Add LXX and it is not workable (chapters are offset).
> > 
> > Daniel
> > 
> > On 01/07/2012 07:54 AM, DM Smith wrote:
> >> I agree with Chris.
> >> 
> >> It will take a lot of work in the SWORD and JSword engine to implement
> >> it.
> >> 
> >> If anything we should develop a v11n that can be read in from a
> >> resource
> >> file. But before that I'd like to see support for mapping from one
> >> v11n to another.
> >> 
> >> In Him,
> >> 
> >>        DM
> >> 
> >> On Jan 6, 2012, at 6:31 PM, Chris Little wrote:
> >>  On 1/6/2012 1:29 AM, David Haslam wrote:
> >>>> Extending Peter's concept, might we also make the book order
> >>>> something
> >>>> that
> >>>> can be worked with by front-end developers?
> >>>> 
> >>>> e.g. For the NT in Eastern Canonical order we might have:
> >>>> 
> >>>> Scope=Matt-Acts James-Jude Rom-Heb Rev
> >>>> 
> >>>> i.e. with the General Epistles ordered prior to the Pauline
> >>>> Epistles.
> >>> 
> >>> I am very much against this idea. (I have no problem with different
> >>> book orders, and would happily add a new v11n system if the need
> >>> can be proven to me and the data can be provided to me.)
> >>> 
> >>> Scope/Coverage is very strongly dependent on the reference system
> >>> (v11n) used. And other aspects of the library, such as verse
> >>> reference resolution, are very dependent on the reference system as
> >>> well. An osisRef such as "Matt-Jude" has to mean something within
> >>> the context of a particular reference system. In the KJV v11n, this
> >>> means all of the text of the NT except Revelation. If we were to
> >>> support use of Scope/Coverage to re-order books, we would be
> >>> creating new de facto v11ns. Under the above Scope, the osisRef
> >>> "Matt-Jude" has a very different meaning from what would be
> >>> expected, assuming the KJV v11n were still employed.
> >>> 
> >>> Fundamentally, I think we should avoid adding new, complex methods
> >>> of
> >>> solving problems for which we already have solutions. In particular,
> >>> the book-ordering issue can already be addressed by addition of new
> >>> v11ns. The number of cases where two v11ns differ only in the
> >>> ordering of their books is probably quite minimal and better served
> >>> by adding a new v11n.>>> 
> >>>  This would be a further step towards "canon neutrality" as
> >>>  expounded by>>>  
> >>>> Neil
> >>>> Rees ("Studge") at BibleTech 2010.
> >>> 
> >>> I'm also not clear on how this would achieve canon neutrality.
> >>> 
> >>> --Chris
> >>> 
> >>> ______________________________**_________________
> >>> sword-devel mailing list: sword-devel at crosswire.org
> >>> http://www.crosswire.org/**mailman/listinfo/sword-devel<http://www.c
> >>> rosswire.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<http://www.cro
> >> sswire.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<http://www.cross
> > wire.org/mailman/listinfo/sword-devel> Instructions to
> > unsubscribe/change your settings at above page