[sword-devel] Status of av11n conversions

Mon Mar 18 13:28:51 MST 2013

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 Gen.1.1
and Gen.1.2
For verse ranges, we can expand out to its list of verses contained in the
source versification first. Then there needs to be a choice by the
user/software of whether we're attempting to compare a contiguous section
in the target versification, or verses of the same content..

The good about this is that we don't need to create any record of the
"master" versification, except to document how it is being used, what the
splits are, etc.
What do people think?

Chris

On 18 March 2013 19:24, Konstantin Maslyuk <kostyamaslyuk at 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/**35a3fc6bde1ccff945d51558d7e21a**
> b1074a4152<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 <chris at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20130318/7de1fc35/attachment.html>