[jsword-devel] Versification mapping

[Martin Denham]

When programming AB av11n ranges were not a concern.  The emphasis was the
current verse and to let the range sort itself out.  So for example, if a
user selects Daniel 3:1 in KJV then AB displays Daniel 3:1 in KJV and tells
any other displayed modules to act as if somebody had selected the
equivalent of Daniel 3v1 in those, and if they have extra content or a
different order of surrounding verses then to display as they normally
would, because

   - the current verse and not the range is important (at least in AB)
   - the other module has it's own specific ordering which it needs to
   follow

my 2p.

Martin


On 4 July 2013 21:39, Chris Burrell <chris at burrell.me.uk> wrote:

> Yes. I think we can detect this. Essentially, it will be confusing to the
> user if for some reason, the mapped passage he asked for is made of several
> ranges ( assuming of course he asked for a contiguous range in the first
> place). I think marking up in the OSIS before the XSL is executed where the
> bits that have been omitted are (i.e. near their closest verse) would be
> helpful. It would outline to the user where the bits are missing and maybe
> hovering over these would give an idea of which bits were omitted...
>
> Agreed on the DC.
>
> In terms of exactly what they asking for, I agree. But the question is
> what are they asking for when they are looking up Daniel 3. What they
> probably really mean is give me the content of the story of the burning
> furnace. They most likely don't mean 'Give me the entirety of Daniel 3 in
> the KJV, but omit the story of the three young men in the DR Catholic
> Bible", especially if they are comparing them in parallel views.
>
> But I'm guessing we could detect if someone is asking for a whole chapter,
> and if they are, we can mark the beginning/end of the DRC with a notice of
> some kind saying these are omitted - but click here to see them.
>
> Chris
>
>
> Chris
>
>
>
>
>
> On 4 July 2013 20:41, DM Smith <dmsmith at crosswire.org> wrote:
>
>> Can we detect when we might confuse the user? If so, how about a popup
>> "You're not in Kansas anymore" (i.e. appropriate blurbage of how to
>> understand the complex issues) and a check box to prevent the dialog from
>> coming up again? Maybe a warning icon (triangle with red ! in it) that when
>> clicked on gives the appropriate blurbage?
>>
>> For the most part, the mapping is sparse (i.e. usually maps to same).
>> Very seldom will it happen. Mostly in Psalms. And when looking at DC
>> material.
>>
>> BTW, I think we should mark in the v11n what is DC. So we can give users
>> and front-ends some semblance of control over seeing non-biblical material.
>>
>> I think we should give the users exactly what they ask for. No more, no
>> less. If they ask for a-e in a parallel view, that's what they get. Perhaps
>> with a "switch" button to change the primary translation.
>>
>> -- DM
>>
>>
>> On Jul 4, 2013, at 3:31 PM, Chris Burrell <chris at burrell.me.uk> wrote:
>>
>> So I'm looking at how we will use those mappings, however we implement
>> them, in the case of aligning texts to compare them together.
>>
>> Assume we have verses a-g (in that order) in two books. But for some
>> reason a versification has mapped verses in a slightly different order
>> (which Michael says can be the case).
>>
>> Say you ask you have the following mappings.
>>
>> a=b
>> b=c
>> c=d
>> d=e
>> e=g
>> f=h
>> g=f
>>
>> If you ask for the range *a-c*, then we can map it to* b-d* which works
>> well.
>> If you ask for range *a-e*, we map it to *b-e ; g*
>>
>> This is kind of unfortunate, because it will give the impression that a
>> Bible is completely missing some text, i.e. verse *f*.
>>
>> I'd like to say we expand the range of b-e to b (because it's the lowest
>> verse) to *g* (which is the highest verse). We then need to find some
>> way of saying that when you output e, you also output *g*. (which i
>> think is totally feasible)
>>
>> But obviously, this would go terribly wrong if g is 20 verses apart. And
>> we can't simply expand the original range of *a-e *to be *a-g *because
>> that's a recursive call and there may be a case where we never end.
>>
>> Do you have any thoughts?
>>
>> I personally feel the most intuitive is to show continuous ranges,
>> otherwise it gives the impression things are missing, so I'd show *a-e*on the left and
>> *b-g * on the other side. This might give the impression there is extra
>> material on the right hand side that is not in the left hand side, but if
>> the user were to expand his range, then he would see the text actually is
>> mapped.
>>
>> Do you have a better idea?
>> Chris
>>
>>
>>
>> On 4 July 2013 18:59, Chris Burrell <chris at burrell.me.uk> wrote:
>>
>>>
>>>
>>>
>>> On 4 July 2013 18:59, Chris Burrell <chris at burrell.me.uk> wrote:
>>>
>>>> In regards to " To prevent the factorial growth there needs to be a
>>>> notion of a middle, master table.", this is what I'm trying to achieve with
>>>> the 'verse parts'.
>>>>
>>>> For example, the verse can't be mapped into the KJV, but it can if we
>>>> assign parts to them.
>>>>
>>>> Gen.1.1=Gen1.1 at a
>>>> Gen.1.2=Gen.1.1 at b
>>>>
>>>> If two versifications have the above, it means we can go from A to B
>>>> without ending up with Gen.1.1-Gen.1.2. The middle mapping is essentially
>>>> the set of KJV verses + its parts. The parts can be named whatever you
>>>> like. The middle mappings don't need to be explicitly defined by themselves
>>>> however. (unless you simply want to document what @a and @b means).
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 4 July 2013 18:28, DM Smith <dmsmith at crosswire.org> wrote:
>>>>
>>>>>
>>>>> On Jul 3, 2013, at 5:22 PM, Martin Denham <mjdenham at gmail.com> wrote:
>>>>>
>>>>>  I would like to know DMs thoughts on how a mapper would be integrated
>>>>> into JSword.
>>>>>
>>>>>
>>>>> On sword-devel, Troy pointed out the tough display issues.
>>>>>
>>>>> Ultimately the mapping of two modules A and B having different
>>>>> versifications involve knowing the differences between the two. There are
>>>>> several conditions that can occur:
>>>>> Verse splits and merges: A verse in one might be two in the other.
>>>>> Extra and absent chapters or verses: A chapter or verse might be
>>>>> present in one but not the other. E.g. Malachi's last chapter in the KJV
>>>>> v11n is split into two chapters in the German v11ns.
>>>>>
>>>>> and so forth.
>>>>>
>>>>> To have mappings between x versifications poses a problem of needing
>>>>> many mappings. To prevent the factorial growth there needs to be a notion
>>>>> of a middle, master table.
>>>>>
>>>>> Anyway, I digress.
>>>>>
>>>>> The mapping will be complicated. I think it should be hidden behind a
>>>>> simple API, such as what Troy plans for SWORD:
>>>>>
>>>>> lxx->setKey(nasb->getKey())
>>>>>
>>>>> We don't have the notion of a module having a current verse and it
>>>>> doesn't make sense to go there now.
>>>>>
>>>>> But the basic idea is that there is a mapping facility that is known
>>>>> when translating a key from one v11n to another.
>>>>>
>>>>> From a code perspective the end user application should not care how
>>>>> it works. That is the simplicity of Troy's example.
>>>>>
>>>>> I'm not sure where it should be located in the versification package.
>>>>>
>>>>> Maybe something like Verse getVerse(Verse) in the Versification class?
>>>>>
>>>>> And there should be an optimal way of converting an ordered list of
>>>>> Passages:
>>>>> Key getKey(Key)
>>>>>
>>>>>
>>>>> Does that make sense?
>>>>>
>>>>> In Him,
>>>>> DM
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20130705/c5971693/attachment-0001.html>