Here's a link to the VMRCRE which Troy mentioned.
[VMR CRE - Virtual Manuscript Room Collaborative Research Environment - Virtual
Manuscript Room Collaborative Research Environment (VMR
CRE)](https://vmrcre.org/)
It may be of wider interest than the particular technical point about
versification data.
Best regards,
David
Sent with [Proton Mail](https://proton.me/mail/home) secure email.
On Monday, January 27th, 2025 at 4:00 PM, Troy A. Griffitts
<scr...@crosswire.org> wrote:
> Hey guys. I recently had to port the mapping work done in VersificationMgr
> for use in the VMRCRE and had to fully understand the scheme and syntax used
> in the good work done by Костя on this a few years back.
>
> It was a bit difficult for me to keep each component straight in my mind
> initially so during my port, I created a class with clear property names to
> hold each value, and an import format which makes it clear what values do
> what. Here are the lines of code for reference:
>
> This is the VMRCRE equivelant to a canon.h file (MTNU: the Masoretic OT +
> Nestle/Aland NT) and has mappings between the MTNU and the LXXNU (LXX =
> Göttingen/Rahlfs) versifications under the <mappings> section near the end:
>
> https://crosswire.org/svn/community/trunk/contrib/v11ns/MTNU.xml
>
> Port of VersificationMgr with class to hold the mappings section:
>
> https://git.crosswire.org/main/crosswire-java/-/blob/master/src/org/crosswire/sword/mgr/VersificationMgr.java#L233
>
> Hope this is helpful,
>
> Troy
>
> On 1/24/25 3:11 PM, DM Smith wrote:
>
>>> On Jan 23, 2025, at 6:40 PM, Arnaud Vié
>>> [<unas.zole+a...@gmail.com>](mailto:unas.zole+a...@gmail.com) wrote:
>>>
>>>> Le jeu. 23 janv. 2025 à 22:18, Fr Cyrille <fr.cyri...@tiberiade.be> a
>>>> écrit :
>>>>
>>>>> So I think that for versifications, catholic catholic2 and LXX there is
>>>>> no mapping (which would explain some of the problems I've had displaying
>>>>> in parallel?).
>>>>> In the other v11n files I see an entry by instance in vulg:
>>>>> unsigned char mappings_vulg[] = {
>>>>>
>>>>> If someone can explain or give me a documentation to understand how it
>>>>> works, and if this is where the mapping takes place, I'd like to work on
>>>>> it. Especially as it should be possible to use Arnaud's work?
>>>
>>> You're correct Cyrille, the mapping data is in this char array defined with
>>> the versifications in the canon_*.h files.
>>> This array is injected (for the versifications which have one) and decoded
>>> within versificationmgr.cpp.
>>>
>>> The format of this char array is really obscure though, and it's completely
>>> different from the format of mappings used in jsword (which is a lot
>>> clearer and a lot easier to edit and maintain).
>>> From what I understand in the code ("// parse mappings" section of the
>>> loadFromSBook method in versificationmgr.cpp) and the canon_vulg.h example :
>>
>> SWORD is built for speed. The format is a C string (characters followed by a
>> null). SWORD’s format is meant to be obscure to force the use of SWORD and
>> JSword as the mechanism to read SWORD modules.
>>
>> JSword is meant to be in lock step with the formats of SWORD. WRT the
>> mapping files, these were developed independently and at the same time. I
>> deemed it too hard at the time to bring JSword back into alignment w SWORD’s
>> format. JSword’s format is human readable, external, easily maintainable and
>> is read when needed.
>>
>>> 1.
>>> The array starts with a sequence of book names, which are the books present
>>> in this bible and absent from KJV.
>>> Each such name is a sequence of letters followed by a null character
>>> serving as delimiter.
>>> In canon_vulg, thoses are the
>>> 'E', 'p', 'J', 'e', 'r', 0,
>>> 'P', 'r', 'A', 'z', 'a', 'r', 0,
>>> 'S', 'u', 's', 0,
>>> 'B', 'e', 'l', 0,
>>>
>>> 2. Then, you have an additional null character indicating the end of that
>>> first section - the rest of the array is encoded completely differently.
>>>
>>> 3. The rest of the array is meant to be split in sequences of 7 numbers,
>>> each such 7-number sequence corresponding to a mapping rule.
>>> For example, this is a mapping rule :
>>> 21, 4, 9, 10, 4, 8, 0,
>>>
>>> First digit indicates the book (index in the sequence of books, starting at
>>> 1). In vulg, book 21 is Psalms.
>>> The next 3 digits indicate the destination of the mapping. "4,9,10"
>>> corresponds to chapter 4, verses 9 to 10.
>>> The final 3 digits are the source of the mapping. "4,8,0" corresponds to
>>> chapter 4, verse 8 alone.
>>> So this rule I used as example denotes that verses Ps 4:9-10 of KJV are
>>> mapped to Ps 4:8 in Vulg.
>>> Which corresponds indeed to one rule that is present in the jsword mapping
>>> file.
>>>
>>> I guess I could try to build a converter to export the jsword mapping
>>> properties files into this format, so that we could indeed add the Catholic
>>> and Catholic2 mappings that I spent hours building for the AndBible jsword
>>> fork.
>>
>> That would be greatly appreciated!
>>
>>> But going forward, for maintaining versifications, it would be a lot better
>>> to have a central way of defining all our versifications and all their
>>> mappings in an easily readable and editable format (maybe the one defined
>>> by the Copenhagen Alliance, cf
>>> https://github.com/Copenhagen-Alliance/versification-specification/blob/master/versification-mappings/json-schema/versification_schema.json
>>> ), serving as a source of truth for both sword and jsword. Because even
>>> just looking at this Vulg versifications, the mapping have vastly diverged
>>> between sword and jsword...
>>
>> IIRC, the mapping of deuterocanonical material I don’t think was ever
>> completed.
>>
>>> Even if we don't go as far as implementing the full modular versification
>>> system that I would like to build, if at the very least we could have a
>>> central, easy-to-maintain place to manage all our versifications, and then
>>> could easily export them to both sword and jsword, that would be a huge
>>> step forward.
>>
>> I think Chris Little developed an external format that would build the
>> canon_*.h files. I don’t remember if there was something like this that was
>> developed for mappings.
>>
>>> Regards,
>>>
>>> Arnaud
>>>
>>> _______________________________________________
>>> sword-devel mailing list: sword-devel@crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>
>> _______________________________________________
>> sword-devel mailing list:
>> sword-devel@crosswire.org
>>
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
