[jsword-devel] Versification mapping

Thu Jul 4 13:39:11 MST 2013

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/20130704/335c7a0a/attachment.html>