Re: [sword-devel] French versification schemes

Konstantin Maslyuk Mon, 19 Jun 2017 00:27:12 -0700

Yes i called it meta v11n in past. I think it is possible, but with OSIS i simply do not know where exactly we have to map.

Отправлено с Mi Phone

Martin Denham <mjden...@gmail.com> | От: 19 июня 2017 г. 12:59 AM | Сообщение:

Should we consider introducing a new, fabricated translation (IIRC this may have originally been your idea DM), containing all potential books and used for mapping between different v11n? I was recently struggling to sort bookmarks from multiple different v11n and wrote the following at the time:

1. JSword's VersificationsMapper uses KJV as the intermediate mapping so Vulgate->KJVA will not work for dc books.
What about using a fabricated-v11n which contains all possible books, chapters and verses as the intermediate v11n. Maybe this would be based on something like KJVA

Martin

On 18 June 2017 at 22:40, DM Smith <dmsm...@crosswire.org> wrote:
Good idea. I’ll look into how we can markup an OSIS text with a mapping to the KJV. If we can do that, then the form that SWORD/JSword needs is merely a form that the two can agree upon.

DM Smith

On Jun 18, 2017, at 3:45 PM, Костя Маслюк <kostyamasl...@gmail.com> wrote:

Having one file for canon defnition and mappings is preffered in my point. Having source(reference) text in that file as well is best.

So would OSIS gurus say whether it is possible to store all data required to build canon and mappings in valid OSIS document?

As i realize convenience of readable formats my point is still the same. So i count on some sort of authoritative desision.

10 июня 2017 г. 5:31 PM пользователь "DM Smith" <dmsm...@crosswire.org> написал:
Circling back around to this.
There are two parts to the problem:
1) AV11N
2) Mapping to KJV

AV11N:
In JSword, we don’t yet have a form for external AV11N. There are two parts to this: Books and Verse/Chapter counts. Books have presence and ordering. Chapters have verse counts, answering "What is the highest verse number in the chapter?” JSword and SWORD differ a bit on internal representation of chapter counts, but the biggest difference is that we have one representation for the OT and one for the NT, allowing reuse of a testament’s chapter counts. The other is a slight difference where we don’t have a separate array of the counts of chapters.

In canon.h there is:
struct sbook ntbooks[] = {
{"Matthew", "Matt", "Matt", 28},
JSword doesn’t have the chapter count, 28, present in its book order array.

The canon.h vm[] array is:
int vm[] = {
// Genesis
31, 25, 24, 26, 32, 22, 24, 22, 29, 32,
32, 20, 18, 24, 21, 16, 27, 33, 38, 18,
34, 24, 20, 67, 34, 35, 46, 22, 35, 43,
55, 32, 20, 31, 29, 43, 36, 30, 23, 23,
57, 38, 34, 34, 28, 34, 31, 22, 33, 26,
// Exodus
22, 25, 22, 31, 23, 30, 25, 32, 35, 29,
10, 51, 22, 31, 27, 36, 16, 27, 25, 26,
36, 31, 33, 18, 40, 37, 21, 43, 46, 38,
18, 35, 23, 35, 35, 38, 29, 31, 43, 38,
The difference for JSword is that we use a doubly nested array:
  /* protected */ static final int[][] LAST_VERSE_OT =
{
// Genesis
{
   31, 25, 24, 26, 32, 22, 24, 22, 29, 32,
   32, 20, 18, 24, 21, 16, 27, 33, 38, 18,
   34, 24, 20, 67, 34, 35, 46, 22, 35, 43,
   55, 32, 20, 31, 29, 43, 36, 30, 23, 23,
   57, 38, 34, 34, 28, 34, 31, 22, 33, 26,
},
// Exodus
{
   22, 25, 22, 31, 23, 30, 25, 32, 35, 29,
   10, 51, 22, 31, 27, 36, 16, 27, 25, 26,
   36, 31, 33, 18, 40, 37, 21, 43, 46, 38,
   18, 35, 23, 35, 35, 38, 29, 31, 43, 38,
},

We’ve maintained the comments as the same and the number of elements on a line the same, allowing us to diff the corresponding canon.h for verification.

The practical difference is that we use sizeof to get the chapter count rather than a lookup in a 2D book array.

Looking at Костя’s file his representation, while easy to generate from a module’s original OSIS xml is too verbose. It has one XML element per verse. We only need chapters/book and verses/chapter. The above representations are sufficiently compact. The python script that is used to generate the canon file can be adapted to create any format we choose.

The format we choose should be:
easy to read
easy to parse and convert into the internal format needed
compact

The book names being standardized to OSIS is sufficient.
The array of chapters having 10 per line make it easy for people to read.
I’ve also spaced it so commas line up even for chapters with over 99 verses.

I’d suggest JSON over XML as it can represent arrays in a more compact form.
E.g. (off the top of my head, can be otherwise)
KJV = [
[
[ "Gen",
[
  31,  25,  24,  26,  32,  22,  24,  22,  29,  32,
32,  20,  18,  24,  21,  16,  27,  33,  38,  18,
34,  24,  20,  67,  34,  35,  46,  22,  35,  43,
55,  32,  20,  31,  29,  43,  36,  30,  23,  23,
  57,  38,  34,  34,  28,  34,  31,  22,  33,  26
]
],
[ "Exod",
[
  22,  25,  22,  31,  23,  30,  25,  32,  35,  29,
10,  51,  22,  31,  27,  36,  16,  27,  25,  26,
36,  31,  33,  18,  40,  37,  21,  43,  46,  38,
18,  35,  23,  35,  35,  38,  29,  31,  43,  38
]
],
... rest of OT ...
],
[
... NT spec ...
]
]

Of course we could come up with a proprietary format. E.g.
KJV 29 27
Gen 50
31 25 24 26 32 22 24 22 29 32
32 20 18 24 21 16 27 33 38 18
34 24 20 67 34 35 46 22 35 43
55 32 20 31 29 43 36 30 23 23
57 38 34 34 28 34 31 22 33 26
Exod 40
22 25 22 31 23 30 25 32 35 29
10 51 22 31 27 36 16 27 25 26
36 31 33 18 40 37 21 43 46 38
18 35 23 35 35 38 29 31 43 38

I favor a standard format over proprietary. For JSword, if standard, we'd use a 3rd-party parser. But writing a parser is fairly trivial.

Response on standardizing mapping file next.

In Him,
DM

On Oct 2, 2016, at 6:13 AM, Troy A. Griffitts <scr...@crosswire.org> wrote:

Thanks for bringing this up Dominique. Костя, what do we need to move forward into this next release?

I also, with you, would like to have one common format shared with JSword to store our mappings. Do you have any comments about their format? Is it something we should simply adopt and write a generator utility to our .h mappings? Does JSword's format include anything we don't support? or vice versa?

Troy

On 10/02/2016 09:08 AM, Dominique Corbex wrote:
On Sun, 24 Jul 2016 01:45:00 +0300
Костя Маслюк <kostyamasl...@gmail.com> wrote:

It is still important to place all we have for av11n schemes and mappings
in one place.
I agree..

At http://crosswire.org/~kalemas/work/v11nmapping there are examples
I'd like to submit sword mappings to these French versification schemes
before the next release of Sword.

So, I just need to write 3 Bible xml files with all the <OsisIDs>
related to these schemes and the mappings <refMap> at the end, and run:
$ python refMap2cpp.py Bible.<versification>.xml

and then add the resulting code to the associated .h file.

Am I right?

In Christ

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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] French versification schemes

Reply via email to