[jsword-devel] Bookset
Martin Denham
mjdenham at gmail.com
Thu Jan 30 10:46:37 MST 2014
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20140130/0fdaf886/attachment-0001.html>
More information about the jsword-devel
mailing list