[jsword-devel] Bookset
Chris Burrell
chris at burrell.me.uk
Thu Jan 30 12:46:00 MST 2014
There are a 3 issues being discussed here.
1- What do we do when verse 0 is requested and when it is in the mapping
files?
The current mapping files take account of that so should not be an issue.
I.e leningrad file had many mains in the psalms making verse 0 to the
relevant verse in kjv.
2- what do we do if a verse 0 is requested but we don't store any mappings?
3- when parsing the mappings, how do we handle verse 0?
On 3, if verse 0 is a single verse we already add the correct mapping. If
it's part of a range we skip it only if the cardinality of its owning range
is greater by 1 to the range it is being mapped to. (i.e. if we can map
verse for verse by not mapping verse 0, then we currently skip it). *My
suggestion here is to not skip it, but to associate it with the verse 1.*
That leaves us with case 2-, where I think it's reasonable to map it to the
equivalent verse 0 in KJV. (seen as it didn't specifically have a mapping
defined, nor was it part of a range of mappings), then we can map it to
verse 0.
So only two changes required:
* change the 'skip' verse, to map the verse itself: skipVerse0 = diff == 1;
on line 173 should become mapVerse0. 180 should be modified to do two
mappings rather than skip the verse.
* in the map/unmap functionality, we want to return the verse 0 rather than
an empty passage.
Does that make sense? Btw, STEP already has most, if not all, cases working
(in particular the Psalms). So any changes we make should be fairly minor
to make verse maps work. STEP currently works because we use ranges and
therefore a verse 0 => nothing mapping doesn't affect the range. That's the
only bit I think we need to fix for AB.
Chris
On 30 Jan 2014 18:15, "DM Smith" <dmsmith at crosswire.org> wrote:
> I haven't started to integrate it yet. So, I took "when found as part of a
> range" meaning that it applied to ranges but not single verses.
>
> The scenario I have in mind is that one has "show headings" on and has
> requested B.x.n-B.y.m (from somewhere in one chapter into the next
> chapter). If chapter y has verse 0 which is the chapter introduction,
> then it needs to be included.
>
> When lined up with a different v11n that breaks chapters x and y on
> different boundaries, the verse 0 of this one does not line up with verse 0
> of the other. These verse 0s need to stand before their respective verse 1.
>
> On a phone, I don't know that this scenario would happen, but on a tablet
> or desktop (like Bible Desktop), it makes sense to show arbitrary ranges in
> parallel.
>
> Maybe it is just the way it was said. But I don't know that it matters
> whether verse 1 is part of a range or not. Verse 0 needs to be before the
> first verse in the v11n for the chapter regardless. (As far as I know,
> this is verse 1. I've seen some v11n that leave out a verse as not part of
> the canon. The ESV does this in a few places, but as far as I know not at
> the beginning of the chapter. They actually have a footnote in the verse
> saying that some translations have that verse. But imagine if it were not a
> filled in with a footnote.) For simplicity, we assume that every chapter in
> a v11n begins at 0, 1, ....
>
> In Him,
> DM
>
> On Jan 30, 2014, at 12:46 PM, Martin Denham <mjdenham at gmail.com> wrote:
>
> I thought Chris was talking about single verses.
>
> But I suppose 'map verse 0 together with verse 1 when found as part of a
> range' is ambiguous as to whether it is 'verse 0' or 'verse 1' that is
> 'found as part of a range'.
>
> I had assumed we were talking about mapping single verses and that it was
> 'verse 1' that had to be 'part of a range' so I understood the following:
> [when mapping a single verse] 'map verse 0 together with verse 1 when
> [verse 1 is] found as part of a range [otherwise map verse 0 to verse 0]'
> [when mapping a range] do as now because it works fine.
>
> Martin
>
>
>
>
>
>
> On 30 January 2014 13:21, DM Smith <dmsmith at crosswire.org> wrote:
>
>> Good catch!
>>
>> The problem you've identified here is where two v11n break chapters at
>> different places.
>>
>> There are several verse 0s.
>> Start of a chapter. T,B,C,0
>> Start of a book. T,B,0,0
>> Start of a testament. T,0,0,0
>> Start of a module. 0,0,0,0
>> where
>> T = 1:OT, 2:NT in SWORD speak
>> B = book
>> C = chapter
>> V = verse
>>
>> We don't need to worry about testament and module starts. These are
>> invariant. And I'm not aware of any modules that have these. I know
>> osis2mod does not know how to construct these.
>>
>> I don't know if book boundaries change from one v11n to another. The only
>> place I can think of would be those books whose boundaries were determined
>> by scroll length, e.g. Kings.
>>
>> On a related note, verse 0 at chapter start of Psalms is important to get
>> right. Psalms is the one place where headings might be canonical. I did a
>> survey of all the modules I have for Ps 3:0-3:2, which contains a canonical
>> heading. The placement of the canonical material was more accidental than
>> deliberate. Sometimes it was in verse 0. Sometimes it was pre-verse in
>> verse 1. Sometimes it was verse 1.
>>
>> The solution that you've outlined (map verse 0 together w verse 1 when
>> found as part of a range) might need to be applied to single verses as well.
>>
>> In Him,
>> DM
>>
>> On Jan 30, 2014, at 4:20 AM, Martin Denham <mjdenham at gmail.com> wrote:
>>
>> I see now, so 'map verse 0 together with verse 1 when found as part of a
>> range' is the way to go.
>>
>> Martin
>>
>>
>> On 29 January 2014 23:20, Chris Burrell <chris at burrell.me.uk> wrote:
>>
>>> At the moment we ignore verse 0 when mapping ranges defined in
>>> properties files. As result you may have verse 0 of job 41 in leningrad
>>> mapped to verse 0 of job 41 in kjv. That would be incorrect. Since verse 0
>>> should map roughly to verse 8 in kjv
>>>
>>> Chris
>>> On 29 Jan 2014 21:45, "Martin Denham" <mjdenham at gmail.com> wrote:
>>>
>>>> If the verse 0 is actually unmapped then the current logic would map it
>>>> to verse 0 in the desired v11n.
>>>>
>>>> If mapping a verse then the current logic is:
>>>> If verse is mapped then use mapping
>>>> If verse is not mapped then use current verse (as now) e.g.
>>>> KJV:Gen.1.1->Ger:Gen.1.1
>>>> All this is as now, but the logic continues to work even if the verse
>>>> to be mapped is verse 0. The only logic that needs to change is the
>>>> deletion of Verse 0.
>>>>
>>>> If verse 0 is to be mapped but there is no mapping then it would seem
>>>> more correct to return verse 0 in the desired v11n rather than verses 0 &
>>>> 1. Although if you want to return verse 0 & 1 then AB would cope but it
>>>> seems wrong.
>>>>
>>>> Martin
>>>>
>>>>
>>>> On 29 January 2014 21:32, Chris Burrell <chris at burrell.me.uk> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> That's correct, but what happens if the verse 0 is actually unmapped?
>>>>> i.e. a mapping has not been specified in the file, or it was ignored as
>>>>> part of mapping a range? At the time of the map() / unmap() method, it's
>>>>> too late to distinguish between the two cases.
>>>>>
>>>>> In the first instance, we should assume same ref, but in the second it
>>>>> may be in the middle of another range. So the fix suggested before may work
>>>>> (i.e. map verse 0 together with verse 1 when found as part of a range.).
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>> On 29 January 2014 20:59, Martin Denham <mjdenham at gmail.com> wrote:
>>>>>
>>>>>> I think you have hit on the issue: And Bible maps a single verse and
>>>>>> allows the context to determine the passage displayed, whereas the JSword
>>>>>> v11n mapping code assumes a Passage range is mapped.
>>>>>>
>>>>>> I can imagine places where mapping a Passage would be better in And
>>>>>> Bible and may use it in the future e.g. the Verse > Compare Translation
>>>>>> screen, but I think that mapping the current verse works well for generally
>>>>>> moving around in Bibles and keeping them in sync.
>>>>>>
>>>>>> There may be a simple solution to this. The external interface to
>>>>>> the v11n mapping has 2 public methods:
>>>>>> public Passage map(final Passage key, final Versification target)
>>>>>> public Key mapVerse(Verse v, Versification targetVersification)
>>>>>>
>>>>>> So we can derive the intention of the calling code from the method
>>>>>> that is called - Verse or Passage.
>>>>>> Then if mapVerse() is called then it is clear that verse 0 should be
>>>>>> mapped, but if map() is called then verse 0 should not be mapped.
>>>>>> So the check in the code for zerosUnmapped would become zerosUnmapped
>>>>>> && !mapVerseFunctionCalled.
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>> On 29 January 2014 20:30, Chris Burrell <chris at burrell.me.uk> wrote:
>>>>>>
>>>>>>> OK - I think I see our issue, and it's in the difference of
>>>>>>> approach. We are using the versification system in different ways. You're
>>>>>>> using a single verse map to work out where something is, but we're mapping
>>>>>>> a whole range. A verse '0' in the mapping files means pre-verse 1, and
>>>>>>> there was some confusion on my part when I developed it in May. I had
>>>>>>> assumed that verse 0 in a chapter was actually the pre-verse content.
>>>>>>>
>>>>>>> So consider the following mapping in the Leningrad.properties.
>>>>>>>
>>>>>>> Ps.3.1-9=Ps.3.0-8
>>>>>>>
>>>>>>> The zero-unmapped is specified because there is no pre-verse
>>>>>>> content. That is, in my May-understanding of the issue, there wasn't a
>>>>>>> verse 0.
>>>>>>>
>>>>>>> The reason you are experiencing the issue is that you're converting
>>>>>>> a single verse. If you were to convert the whole chapter, then you'd end up
>>>>>>> with the correct range.
>>>>>>>
>>>>>>> In this case, allowing "verse 0" means that if we would be
>>>>>>> indicating that we have a pre-verse content in the Leningrad versification,
>>>>>>> which can be mapped to the KJV versification. In terms of the original
>>>>>>> implementation, it is true that Leningrad does not have pre-verse content.
>>>>>>> So it makes sense (to me at least) that we are getting a zero passage back.
>>>>>>>
>>>>>>> However, because verse 0 doesn't indicate a pre-verse content. I
>>>>>>> think we need to do something different. I don't think we can simply return
>>>>>>> the same verse in the different versification, as in the case of verse
>>>>>>> ranges like:
>>>>>>>
>>>>>>> Job.40.25-41.26=Job.41.1-34
>>>>>>>
>>>>>>> this would not work. Job 40.25-end has 8 verses. So the range
>>>>>>> Job.40.25-Job.41.26 has 34 verses. (i.e. verse 0 is left unmapped)
>>>>>>>
>>>>>>> There is specific code to ensure that these mappings are skipped,
>>>>>>> such that the range mentioned above works:
>>>>>>>
>>>>>>> if (isKJVMany) {
>>>>>>> //we detect if the keys are 1-apart from each other. If
>>>>>>> so, then we skip verse 0 on both sides.
>>>>>>> int diff = Math.abs(leftHand.getKey().getCardinality() -
>>>>>>> kjvVerses.getKey().getCardinality());
>>>>>>>
>>>>>>> if(diff > 1) {
>>>>>>> reportCardinalityError(leftHand, kjvVerses);
>>>>>>> }
>>>>>>> skipVerse0 = diff == 1;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> So, I'm not sure what the solution is, but I've hopefully given all
>>>>>>> of us some information to think about it.
>>>>>>>
>>>>>>> One solution, is that instead of 'skipping' the verse 0 during range
>>>>>>> iterations, we could map it to the next verse in the range. That would be
>>>>>>> fairly reflective of how things really should be. We'd have to test this
>>>>>>> carefully in terms of the OSIS iterator.
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 26 January 2014 00:15, Martin Denham <mjdenham at gmail.com> wrote:
>>>>>>>
>>>>>>>> This seems wrong "the purpose of the flag is to return an empty
>>>>>>>> key if you specifically ask for Verse 0".
>>>>>>>>
>>>>>>>> If a user is currently in Ex 20:0 in GerNeUe and switches to KJV
>>>>>>>> you would expect to go to KJV 20:0 but he is left at EmptyKey??
>>>>>>>> For comparison, if a user is currently in Ex 20:0 in ESV and
>>>>>>>> switches to KJV he does actually go to KJV 20:0 (Not EmptyKey - because it
>>>>>>>> is the same versification and the mapping returns v0 if it is the same
>>>>>>>> v11n).
>>>>>>>>
>>>>>>>> The fact that RangedPassage throws an exception and Rocket does not
>>>>>>>> may be just a matter of the specification of Passage not being tight enough
>>>>>>>> - what to do with an empty passage.
>>>>>>>>
>>>>>>>> For AB verse 0 needs to be mapped.
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 25 January 2014 23:34, Chris Burrell <chris at burrell.me.uk>wrote:
>>>>>>>>
>>>>>>>>> Thanks Martin. I'd be in favour of removing the lookup by name
>>>>>>>>> (but not essential for your release).
>>>>>>>>>
>>>>>>>>> Now that the build is stable, it would be a good time to label it
>>>>>>>>> (with the 3 extra pull requests) and you could take your cut? BTW, I label
>>>>>>>>> the JSword build in my repo when I release STEP.
>>>>>>>>>
>>>>>>>>> In terms of the zero unmapped option, it sounds like a bug in the
>>>>>>>>> Passage type if it works with some Passages and not others. Would you agree
>>>>>>>>> DM/Martin? They should either all fail or none of them, but not some and
>>>>>>>>> some not. Basically, the purpose of the flag is to return an empty key if
>>>>>>>>> you specifically ask for Verse 0, or if it happens to be asked for as part
>>>>>>>>> of a range map-request. For most of the time, you don't want that to map to
>>>>>>>>> any particular verse. We introduced it for some reason (can't quite
>>>>>>>>> remember why) but was to do with being able to map some sections to
>>>>>>>>> pre-verse content, as in the Psalms, whilst leaving all other verses (in
>>>>>>>>> other books for example) as is.
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 25 January 2014 23:23, Martin Denham <mjdenham at gmail.com>wrote:
>>>>>>>>>
>>>>>>>>>> And Bible tends to get lists of books and then store the relevant
>>>>>>>>>> Book object. I can't find anywhere that it asks for a book by name but it
>>>>>>>>>> does use initials sometimes.
>>>>>>>>>>
>>>>>>>>>> I recall there was a problem a few months ago in which KJVA had
>>>>>>>>>> the same name as KJV but different initials and use of the name as the id,
>>>>>>>>>> instead of the initials, caused problems - a fix had to be implemented
>>>>>>>>>> then. There were some similar cases of same name/different initials in the
>>>>>>>>>> IBT repo.
>>>>>>>>>>
>>>>>>>>>> AB should be fine/faster if JSword matches by initials first
>>>>>>>>>> rather than name - if that is what you are intending.
>>>>>>>>>>
>>>>>>>>>> I am hoping to settle on a stable build of JSword soon to prepare
>>>>>>>>>> for an AB release. When do you think would be a good time. It would be
>>>>>>>>>> good to get it labelled too. The only outstanding issue is with
>>>>>>>>>> 'zerosUnmapped' but I could just remove that line from the properties files
>>>>>>>>>> for AB if a fix is not easy. Currently I just catch the exception and
>>>>>>>>>> force the verse to the required v11n.
>>>>>>>>>>
>>>>>>>>>> Martin
>>>>>>>>>>
>>>>>>>>>> Martin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 25 January 2014 21:41, Chris Burrell <chris at burrell.me.uk>wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> I'm looking to refactor Books.installed().getBook(name) because
>>>>>>>>>>> it takes too long when you need to look up books multiple times (and don't
>>>>>>>>>>> have an easy way of caching the JSword lookup). It's particular slow when
>>>>>>>>>>> you have 200+ resources (our server will have). This will also be more
>>>>>>>>>>> prevalent in Android where method calls are quite expensive.
>>>>>>>>>>>
>>>>>>>>>>> In STEP we always have the initials of the module (the user
>>>>>>>>>>> selects by name/initials/STEP name in the browser, where it always gets
>>>>>>>>>>> translated to initials well before it hits JSword). Do any other frontends
>>>>>>>>>>> use the getBook(name) by name?
>>>>>>>>>>>
>>>>>>>>>>> I want to at least provide way of getting the book directly from
>>>>>>>>>>> its initials. As part of this, we can several things:
>>>>>>>>>>>
>>>>>>>>>>> In Books:
>>>>>>>>>>> - refactor the getBook() method to not search first against the
>>>>>>>>>>> name, then against name insensitive and then against the initials in the
>>>>>>>>>>> BMD, and then against the initials directly
>>>>>>>>>>> - If the above is not possible then at least provide a
>>>>>>>>>>> getBookByInitials (which would just look up the initials against their
>>>>>>>>>>> lower case value.
>>>>>>>>>>>
>>>>>>>>>>> In BookSet:
>>>>>>>>>>> - I can't work out why we're sorting the inserts in add(). They
>>>>>>>>>>> cause unecessary copies of the ArrayList contents in the creation of it.
>>>>>>>>>>> - I can't work out why it also implements Set. Especially, since
>>>>>>>>>>> contains would be a good candidate for using
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So there are two options really:
>>>>>>>>>>> - change BookSet to be based on a Map. getBooksByInitials would
>>>>>>>>>>> use the map directly. getBook would iterate through the contents (or key
>>>>>>>>>>> the contents in a separate map for faster access)
>>>>>>>>>>> - Add a map to BookSet to cache the lookups
>>>>>>>>>>>
>>>>>>>>>>> My preference would be to replace the BookSet implementation
>>>>>>>>>>> altogether. But the easy option would be to have a Map lookup. Do we use
>>>>>>>>>>> any of the Set<> methods? Would it make sense to replace BookSet with a
>>>>>>>>>>> LinkedHashMap?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Chris
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> jsword-devel mailing list
>>>>>>>>>>> jsword-devel at crosswire.org
>>>>>>>>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> jsword-devel mailing list
>>>>>>>>>> jsword-devel at crosswire.org
>>>>>>>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> jsword-devel mailing list
>>>>>>>>> jsword-devel at crosswire.org
>>>>>>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> jsword-devel mailing list
>>>>>> jsword-devel at crosswire.org
>>>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jsword-devel mailing list
>>>>> jsword-devel at crosswire.org
>>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> jsword-devel mailing list
>>>> jsword-devel at crosswire.org
>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>
>>>>
>>> _______________________________________________
>>> jsword-devel mailing list
>>> jsword-devel at crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>
>>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>>
>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20140130/63466bac/attachment-0001.html>
More information about the jsword-devel
mailing list