Re: [sword-devel] Status of av11n conversions
My impression is that this patch has been broken from the recent renaming of VersificationMgr? But, could this patch be applied to SVN without affecting anything? My impression is that if you don't call the new methods, there will be no change to the way things currently work? I'm really interested in getting this working, but given that we don't even do a split screen yet (which is something like the oldest feature request currently outstanding?), there's no real need or point of it in PS yet... :( If it's applied, people may try it more and report possible bugs (before I get to play with it!)? ;) Thanks, ybic nic... :) On 15/03/2013, at 11:47 AM, Troy A. Griffitts scr...@crosswire.org wrote: Костя Маслюк submitted a patch to add this a while back. I had asked him to try it out in one of his favorite frontends to see how it works. He's since integrated it into Bibletime Mobile for Android. Attached is his latest email to sword-devel. On 03/12/2013 08:44 PM, Chris Burrell wrote: Hi I was wondering if someone is working on being able to convert from 1 versification system to another. This very important for being to line up verses and therefore very important to STEP for our interlinears. I'm told someone is doing the work for Sword first and then we will bring it across into JSword. Is someone working on this? Does anyone know what the status of this is? Is there a target date for when the design will be finalised such that we can implement this in JSword? Chris ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page Attached Message.eml___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Status of av11n conversions
There is code/tool/data set at
http://crosswire.org/~kalemas/work/v11nmappinghttps://crosswire.org/%7Ekalemas/work/v11nmapping
That would be missed link to understand how it works. RefMap2cpp.py is
used to convert v11n description in XML file to data table that you
have been seen in the patch. XML files contain of two parts: full list
of the verses and mapping data for transitions only.
There is also testmappings.exe if you would like to test NRSV John 3,
it probably would work (i remember that in nrsv there are two cases,
but John would need no corrections). You can quickly move along the
module with this, switch active modules with different versification.
Source code is also available.
I use KJVA versification as intermediate, with use of meta space. I did
not encountered with complicated cases of meta space usage so I did not
documented it anywhere.
In NRSV Rev 12.18-19 is necessary for backward transition from KJVA to
NRSV. Rev 12.19 means next chapter first verse.
66, 13, 1, 1, 13, 1, 0,
66 - Rev, 13 - chapter, 1, 1 and 1, 0 means mapping ranges. It is exact
verse if range end is equal to zero or is below range start. In this
case nrsv is range and kjv is exact verse... This is necessary when we
transit from nrsv to vulg, because Rev 12.18-Rev 13.1 is the same, so i do
ranges comparision in KJV to correctly bring NRSV.Rev.13.1 to
VULG.Rev.13.1, because KJV.Rev.13.1 = VULG.Rev.12.18-Rev.13.1
66, 12, 18, 19, 13, 1, 0,
66, 13, 1, 1, 13, 1, 0,
Note, there is also different parse order: to KJV we parse backwards from
last to first, from KJV - forward data table parsing (or vice versa, i do
not remember :^).
*Absent Books*
unsigned char mappings_nrsv[] = {
0,
66, 12, 18, 19, 13, 1, 0,
66, 13, 1, 1, 13, 1, 0,
0
};
This data contain of two parts, first in Book Names list, NULL terminated,
second is Mapping Rulles List, also NULL terminated. Here Book names is
empty, but for Vulg there is:
unsigned char mappings_vulg[] = {
'E', 'p', 'J', 'e', 'r', 0,
'P', 'r', 'A', 'z', 'a', 'r', 0,
'S', 'u', 's', 0,
'B', 'e', 'l', 0,
0,
...
It is absent book names in KJV, necessary to correctly transit with non KJV
v11ns. For example, KJV does not contain PrAzar, but we able to correctly
transit from Synodal to Vulg, because Synodal have following:
map from=Dan.3.24 to=PrAzar.1.1/
map from=Dan.3.25 to=PrAzar.1.2/
map from=Dan.3.26 to=PrAzar.1.3/
...
In cpp data we use book numbers above versification book count: like
refSys.getBookCount() + 1 = Sus. In Synodal:
unsigned char mappings_synodal[] = {
'P', 'r', 'A', 'z', 'a', 'r', 0,
'S', 'u', 's', 0,
'B', 'e', 'l', 0,
0,
...
26, 7, 2, 0, 7, 1, 0,
79, 3, 24, 0, 1, 1, 0, 35,
We test if 79 is greater than getBookCount(), if so we take last number -
35 as current book and 79 as target book: 79 - getBookCount() = PrAzar.
Chapter and verse data is used as always.
*Verse Shifting*
21, 106, 0, 0, 107, 0, 0,
21, 107, 1, 2, 108, 1, 0,
First line - Vulg Ps.106 = KJV Ps.107, it should be clear.
Second Line: for whole chapter there is only one rule. I only need to
declare expansion or contraction, the rest of the chapter will be shifted,
including meta-versification space. Rules works on chapter level.
In conclusion two things i would add. Probably v11n xmls should be
converted to OSIS format, i have no decision because i do not see
advantages for now. I plan to change cpp rules format to have first number
equal to binary size of the rule, this seem to me good tone and would bring
backward compatibility for if we ever have module supplied versification
with mappings included.
Blessings.
2013/3/19 DM Smith dmsm...@crosswire.org
Konstantin,
Thanks very much for the work you've done.
I'm trying to understand the data structure. JSword is an independent
implementation and doesn't use SWORD libraries. So to implement something
like this, it'll be helpful to understand what the data structures and the
data means.
If I understand, you are using the KJVA as the common bridge between
different versifications.
For the NRSV you have the following:
unsigned char mappings_nrsv[] = {
0,
66, 12, 18, 19, 13, 1, 0,
66, 13, 1, 1, 13, 1, 0,
0
};
If I read this correctly, 66 refers to Revelation (with the books are
numbered from 1 for Genesis to 66 for Rev as appears in the KJV, and all
apocryphal books are numbered higher than the canonical ordered as in the
KJVA).
In the first non-zero row, the 66, 12, 18, 19 means Rev 12:18-19 from the
NRSV.
And the 13, 1, 0 means Rev 13:1 in the KJV.
So basically, NRSV Rev 12:18-19 is the same as KJV Rev 13:1.
When I look into the NRSV versification in SWORD, I'm seeing that Rev 12
goes to verse 18. Whereas the KJV goes to verse 17. Where does
Re: [sword-devel] Status of av11n conversions
Thanks. It'll take me some time to wrap my head around this.
-- DM
On Mar 19, 2013, at 5:54 AM, Костя Маслюк kostyamasl...@gmail.com wrote:
There is code/tool/data set at
http://crosswire.org/~kalemas/work/v11nmapping
That would be missed link to understand how it works. RefMap2cpp.py is
used to convert v11n description in XML file to data table that you
have been seen in the patch. XML files contain of two parts: full list
of the verses and mapping data for transitions only.
There is also testmappings.exe if you would like to test NRSV John 3,
it probably would work (i remember that in nrsv there are two cases,
but John would need no corrections). You can quickly move along the
module with this, switch active modules with different versification. Source
code is also available.
I use KJVA versification as intermediate, with use of meta space. I did
not encountered with complicated cases of meta space usage so I did not
documented it anywhere.
In NRSV Rev 12.18-19 is necessary for backward transition from KJVA to
NRSV. Rev 12.19 means next chapter first verse.
66, 13, 1, 1, 13, 1, 0,
66 - Rev, 13 - chapter, 1, 1 and 1, 0 means mapping ranges. It is exact
verse if range end is equal to zero or is below range start. In this
case nrsv is range and kjv is exact verse... This is necessary when we
transit from nrsv to vulg, because Rev 12.18-Rev 13.1 is the same, so i do
ranges comparision in KJV to correctly bring NRSV.Rev.13.1 to VULG.Rev.13.1,
because KJV.Rev.13.1 = VULG.Rev.12.18-Rev.13.1
66, 12, 18, 19, 13, 1, 0,
66, 13, 1, 1, 13, 1, 0,
Note, there is also different parse order: to KJV we parse backwards from
last to first, from KJV - forward data table parsing (or vice versa, i do not
remember :^).
Absent Books
unsigned char mappings_nrsv[] = {
0,
66, 12, 18, 19, 13, 1, 0,
66, 13, 1, 1, 13, 1, 0,
0
};
This data contain of two parts, first in Book Names list, NULL terminated,
second is Mapping Rulles List, also NULL terminated. Here Book names is
empty, but for Vulg there is:
unsigned char mappings_vulg[] = {
'E', 'p', 'J', 'e', 'r', 0,
'P', 'r', 'A', 'z', 'a', 'r', 0,
'S', 'u', 's', 0,
'B', 'e', 'l', 0,
0,
...
It is absent book names in KJV, necessary to correctly transit with non KJV
v11ns. For example, KJV does not contain PrAzar, but we able to correctly
transit from Synodal to Vulg, because Synodal have following:
map from=Dan.3.24 to=PrAzar.1.1/
map from=Dan.3.25 to=PrAzar.1.2/
map from=Dan.3.26 to=PrAzar.1.3/
...
In cpp data we use book numbers above versification book count: like
refSys.getBookCount() + 1 = Sus. In Synodal:
unsigned char mappings_synodal[] = {
'P', 'r', 'A', 'z', 'a', 'r', 0,
'S', 'u', 's', 0,
'B', 'e', 'l', 0,
0,
...
26, 7, 2, 0, 7, 1, 0,
79, 3, 24, 0, 1, 1, 0, 35,
We test if 79 is greater than getBookCount(), if so we take last number - 35
as current book and 79 as target book: 79 - getBookCount() = PrAzar.
Chapter and verse data is used as always.
Verse Shifting
21, 106, 0, 0, 107, 0, 0,
21, 107, 1, 2, 108, 1, 0,
First line - Vulg Ps.106 = KJV Ps.107, it should be clear.
Second Line: for whole chapter there is only one rule. I only need to declare
expansion or contraction, the rest of the chapter will be shifted, including
meta-versification space. Rules works on chapter level.
In conclusion two things i would add. Probably v11n xmls should be converted
to OSIS format, i have no decision because i do not see advantages for now. I
plan to change cpp rules format to have first number equal to binary size of
the rule, this seem to me good tone and would bring backward compatibility
for if we ever have module supplied versification with mappings included.
Blessings.
2013/3/19 DM Smith dmsm...@crosswire.org
Konstantin,
Thanks very much for the work you've done.
I'm trying to understand the data structure. JSword is an independent
implementation and doesn't use SWORD libraries. So to implement something
like this, it'll be helpful to understand what the data structures and the
data means.
If I understand, you are using the KJVA as the common bridge between
different versifications.
For the NRSV you have the following:
unsigned char mappings_nrsv[] = {
0,
66, 12, 18, 19, 13, 1, 0,
66, 13, 1, 1, 13, 1, 0,
0
};
If I read this correctly, 66 refers to Revelation (with the books are
numbered from 1 for Genesis to 66 for Rev as appears in the KJV, and all
apocryphal books are numbered higher than the canonical ordered as in the
KJVA).
In the first non-zero row, the 66, 12, 18, 19 means Rev 12:18-19 from the
NRSV.
And the 13, 1, 0 means Rev 13:1 in
Re: [sword-devel] Status of av11n conversions
Hello. There really is done work for av11n conversion support for sword. You even may get patch at https://gitorious.org/~kalemas/sword-svn-mirrors/kalemas_at_mail_ru-trunk/commit/35a3fc6bde1ccff945d51558d7e21ab1074a4152 and use it if you compile libsword for your self. But you also should take into account that this feature is not supported officially and would be incompatible with future releases of Sword. And there is no known schedule for this as this work was not considered for two years. Blessings. Chris Burrell ch...@burrell.me.uk писал(а) в своём письме Tue, 12 Mar 2013 23:44:36 +0400: Hi I was wondering if someone is working on being able to convert from 1 versification system to another. This very important for being to line up verses and therefore very important to STEP for our interlinears. I'm told someone is doing the work for Sword first and then we will bring it across into JSword. Is someone working on this? Does anyone know what the status of this is? Is there a target date for when the design will be finalised such that we can implement this in JSword? Chris -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Status of av11n conversions
Hi All Troy, thanks for the patch. Would you be able to send it as a text file or something? I'm not sure what I can use to open your attachment? It looks base-64 encoded on my laptop. Konstantin, I've had a brief look and can see lots of numbers. Presumably the numbers are the versifications, and the mappings array is the mappings between two or three or four versifications? The mappings look like they are possibly verse numbers? I was hoping for a versification patching system that might be a bit more supportable/maintainable if possible, i.e. using references to match up between versions. I've copied below my suggestion of a system, originally posted on the JSword list, based on some of the posts I've seen previously in the Sword mailing list. = *Key ideas* - create a converter that goes through to a master versification as you suggested. We define the mappings for those OsisIDs that don't match. The master version is based on the KJV versification (for ease of being able to create new mappings) + the books that aren't in the KJV. - mappings include just the bits that don't match up. - mappings can be define for sets of verses with offset, e.g. Psalm 51:1-5=Psalm 51:1+1 (where +1 indicates an offset of 1 to be applied to the source. - Have the concept of split verses (i.e. Rom 1:1a, Rom 1:1b, etc.) - A tool to create a split in the master versification, which rewrites all the current versifications, such that when someone writes a mapping and needs to split a verse, they can introduce the split without adversely affecting every other mapping. - the lookup process takes an String (OSIS ID) with a source and target versification. (also overload that with Key/Verse). It then queries the master mapping, which returns 1 or more entries (an entry being a whole verse, or set of split verses). Then goes to reverse mappings for the target versification and does the same. For incomplete verses on one side or the other, we round up the closest verse. - The reason for basing the versification on KJV (or some other English versification), is that's it easy to work against. The alternative would be to go for the most split versification ever found, but that becomes painful in the future if someone decides to split another verse in 2 parts. - When introducing a split, we would want to record what the split actually refers to (i.e. what content). This wouldn't be used by the library, but instead be useful for people coming along and writing new mappings. = *And here are some examples of how it would work in practice:* *2 verse in the original, 1 verse in the KJV-based master* Gen.1.1=Gen.1.1 Gen.1.2=Gen.1.1 *1 verse in the original, 2 verses in the master* Gen.1.1=Gen.1.1-Gen.1.2 *Using splits, so that 2 separate versifications can refer to the same parts of verses* Gen.1.1=Gen.1.1a Gen.1.2=Gen.1.1b Gen.1.3=Gen.1.1.c Then another versification can also refer to the same parts. It would become necessary to keep track of what the parts are, such that they can be easily re-used when approrpriate. For example, a second versification might be mapped as follows: Gen.1.1=Gen.1.1a-Gen.1.1b Gen.1.2=Gen.1.c *No mapping* Osis IDs mean the same thing. I think the above covers, Split verse, Merged verse, Different verse boundaries. *Chapter boundaries can be mapped equally the same:* Gen.1.1=Gen.1.1 Gen.1.2=Gen.2.1 indicates that that Genesis 1:2 can be found in Gen 2:1 in the master. *Extra verses* We simply introduce some identified ids (osis ids, or other form of unique identifier) in the master to identify the content of these verses Additional verses within a chapter can be represented using the above. *Psalm headings:* Ps.53.1=Ps.53.1 (not required, or required if map it to 'nothing' or '0') Ps.53.2=Ps.53.1 Ps.53.3=Ps.53.2 We can reduce this to if we want to introduce a less verbose way of mapping things. Ps.53.2-7-=Ps.53.1-+1 (where minus simply indicates that there is an offset of 1 compared to the master) *Absent verses* absent=Gen1.91,Gen.2.32 *For new sections in the middle:* We invent some new ideas, for example in Daniel, we could have the mappings: Dan.3.24=songofchildren.1 Dan.3.25=songofchildren.2 ... I don't think we need to introduce splits on the left hand-side. The reason being, you can't do anything with an OSIS id of Gen.1.1a, since you're going to retrieve a whole verse anyway, so we can keep things with splits only-ever on the right hand side. Splits are only used to refer to the master system. They are not necessary but they add resolution to the mapping lookups. Here's the reason. If a and b split verses in a similar way we would like to be able to go from a to b without ending up with a bigger chunk of text. Gen.1.1=Gen.1.1a Gen.1.2=Gen.1.1b If both versifications define the above we can go from gen.1.1 in one versification to the equivalent in the target. Without the split, the intermediate master resolves to gen.1.1 which in turn resolves to
Re: [sword-devel] Status of av11n conversions
Konstantin,
Thanks very much for the work you've done.
I'm trying to understand the data structure. JSword is an independent
implementation and doesn't use SWORD libraries. So to implement something like
this, it'll be helpful to understand what the data structures and the data
means.
If I understand, you are using the KJVA as the common bridge between different
versifications.
For the NRSV you have the following:
unsigned char mappings_nrsv[] = {
0,
66, 12, 18, 19, 13, 1, 0,
66, 13, 1, 1, 13, 1, 0,
0
};
If I read this correctly, 66 refers to Revelation (with the books are numbered
from 1 for Genesis to 66 for Rev as appears in the KJV, and all apocryphal
books are numbered higher than the canonical ordered as in the KJVA).
In the first non-zero row, the 66, 12, 18, 19 means Rev 12:18-19 from the NRSV.
And the 13, 1, 0 means Rev 13:1 in the KJV.
So basically, NRSV Rev 12:18-19 is the same as KJV Rev 13:1.
When I look into the NRSV versification in SWORD, I'm seeing that Rev 12 goes
to verse 18. Whereas the KJV goes to verse 17. Where does the 19 come in?
The next line has 66, 13, 1, 1 (So NRSV 13:1) maps to 13, 1, 0 (to KJV 13:1).
Putting all of this together, KJV 13:1 is NRSV 12:18-13:1.
Curious why is it 66, 13, 1, 1 and not 66, 13, 1, 0?
Am also wondering why there's no entry for John 3. In the NRSV, there are 15
verses but in the KJV there are 14. So shouldn't there be a line with:
64, 1, 14, 15, 1, 14, 0
I'm sure as I dig into Synodal, I'll have more questions. But I wait until I
find out whether I'm missing something here.
In Him,
DM
On Mar 18, 2013, at 3:24 PM, Konstantin Maslyuk kostyamasl...@gmail.com
wrote:
Hello. There really is done work for av11n conversion support for sword. You
even may get patch at
https://gitorious.org/~kalemas/sword-svn-mirrors/kalemas_at_mail_ru-trunk/commit/35a3fc6bde1ccff945d51558d7e21ab1074a4152
and use it if you compile libsword for your self. But you also should take
into account that this feature is not supported officially and would be
incompatible with future releases of Sword. And there is no known schedule
for this as this work was not considered for two years.
Blessings.
Chris Burrell ch...@burrell.me.uk писал(а) в своём письме Tue, 12 Mar 2013
23:44:36 +0400:
Hi
I was wondering if someone is working on being able to convert from 1
versification system to another. This very important for being to line up
verses and therefore very important to STEP for our interlinears.
I'm told someone is doing the work for Sword first and then we will bring
it across into JSword.
Is someone working on this? Does anyone know what the status of this is? Is
there a target date for when the design will be finalised such that we can
implement this in JSword?
Chris
--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
Re: [sword-devel] Status of av11n conversions
Костя Маслюк submitted a patch to add this a while back. I had asked him to try it out in one of his favorite frontends to see how it works. He's since integrated it into Bibletime Mobile for Android. Attached is his latest email to sword-devel. On 03/12/2013 08:44 PM, Chris Burrell wrote: Hi I was wondering if someone is working on being able to convert from 1 versification system to another. This very important for being to line up verses and therefore very important to STEP for our interlinears. I'm told someone is doing the work for Sword first and then we will bring it across into JSword. Is someone working on this? Does anyone know what the status of this is? Is there a target date for when the design will be finalised such that we can implement this in JSword? Chris ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ---BeginMessage--- Just update. Now it handle content absent in intermediate system (like PrAzar), test Vulg mappings (i have used DRC in experimental and it seems several books content is absent(1Esd)). I have never develop for Linux/Mac platforms so i would like to know if this patch works for this platforms. v11nmappings3.patch Description: Binary data ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page---End Message--- ___ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
