[sword-devel] Av11n and coverage

Sat Jan 7 11:59:36 MST 2012

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.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<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<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/20120107/1c7b059e/attachment.html>