<div dir="ltr"><div>Thank you for your interest and your time !</div><div>And thanks Troy for your valuable historical explanation.<br></div><div><br></div><div>However, I can't help but feel that you all are underestimating the power of OSIS !<br>Your
are splitting the use cases of "rendering a bible mostly as it was
published" versus "making a bible searchable accurately for bible study
and research", as if we had to choose one and neglect the other.<br></div><div>These use cases are both equally valid, but the
good news is that OSIS is already a (mostly) perfect format to handle
both at the same time.</div><div>That's part of the reason why I fell in love with the format and believe it's worth maintaining.<br></div><div><br></div><div><br></div><div>In particular, some cases Michael mentions :</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Chapter and verse "numbers" aren't
always pure numbers. Letters get involved in the
Deuterocanon/Apocrypha.</blockquote><div> </div><div>Here, OSIS already provides a distinction between :</div><div><ul><li>The
OSIS ID, which is a "technical" ID supposed to be a unique identifier
for the book/verse/chapter. On this, OSIS imposes a constrained format
and structure because applications will need to process it.<br></li><li>The
published number (the verse or chapter's "n" attribute) which is a free
text, allowing to preserve the numbering from the published
document.<br></li></ul></div><div>In fact USFM provides a similar distinction between the "v" and "vp", "c" and "cp" keywords.</div><div>You can check <a href="http://crosswire.org/pipermail/sword-devel/2024-January/049928.html" target="_blank">the example in my first email about the proposed Catholic3 versification</a>
for an example : it's perfectly fine to have an OSIS ID "Esth.3.20" for
a verse that is labelled as "13G" in the published document, because
the OSIS ID is technical.<br>The OSIS ID should be used almost
exclusively for this need of referencing and mapping verses between
different translations ; in an ideal world, the OSIS ID shouldn't even
be visible to end users (even though I know that's not currently the
case).<br></div><div>The "n" attributes are what should be presented to the users when reading a bible.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Verse bridges (like verse 1-3 with
everything from verses 1 through 3 but possibly rearranged and
with no other verse markings within them) are very common.</blockquote><div><br></div><div>OSIS
already natively supports its, without any changes to versifications :
it allows several OSIS IDs on a single tag explicitly for this purpose.
(section "15.4. Grouping" of the OSIS manual)<br></div><div>So it's
perfectly valid to define verses 1,2,3 in the versification, and then
have one single "verse" element with all of these IDs at once for this
use case. This "verse" tag can then provide an n="1-3" attribute to
preserve the published document notation.</div><div><br></div><div><br></div><div><br></div><div>My proposal for a new way of defining versifications aims purely at improving the mapping feature - the same one that Troy relies on for bible study and research.</div><div>It has no impact on the "presentation" side of things - because of these existing OSIS features I mentioned above which already allow preserving the original text's numbering.<br></div><div>The "principle 1" of my proposal in the other thread is the core of what a versification system should be : a versification system should assign a unique ID to identify a verse's contents (what I called the "meaning" of the verse in my proposal), so that this ID can be used to reference or map the equivalent or related text in other bibles.</div><div>That's where the current versification system is problematic, because many bibles do not fit exactly into one of the default versifications, and they have no way of building a "custom" versification. That's the problem I'm trying to solve.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 20 févr. 2024 à 14:54, Peter von Kaehne <<a href="mailto:refdoc@gmx.net">refdoc@gmx.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div>
</div><div><div dir="ltr">There are two aspects here:</div><div dir="ltr"><br></div><div dir="ltr">Historical developments which have been by and large well explored by Chris and are mirrored well in our various av11n system - with specific and now largely known gaps - we have less clue on the Roman catholic development of versification systems and probably even less on a variety of autochthone churches with their own historical development of translations an versification. But these are well defined tasks and e.g. the work of Dominique to bring in the French systems documents well how we should handle that side. </div><div dir="ltr"><br></div><div dir="ltr">The complications coming in due to modern translation are actually very limited:</div><div dir="ltr"><br></div><div dir="ltr">FWIW, most modern translations which play about with versifications still actually follow an underlying well known and documented plan. </div><div dir="ltr"><br></div><div dir="ltr">NRSV(A) eg seems to be all what UBS and Wycliffe use - even when allowing for verse bridges, reordering and more. </div><div dir="ltr"><br></div><div dir="ltr">Which makes me think we should think more about a presentation overlay which we have at the moment very rudimentary only. OSIS certainly allows for more than we incorporate right now. </div><div dir="ltr"><br></div><div dir="ltr">This could take eg in the engine the form of a resorting filter where text is reordered and marked up for user facing presentation based on additional presentation info in modules. </div><div dir="ltr"><br></div><div dir="ltr">This would to my mind be a much better solution than ever increasing further system of av11n or indeed a complete rewrite. </div><div dir="ltr"><br></div><div dir="ltr">Peter</div><div dir="ltr"><br></div>
<div id="m_860571014849005652ms-outlook-mobile-signature"><div><br></div>Sent from <a href="https://aka.ms/o0ukef" target="_blank">Outlook for iOS</a></div>
<div> </div><hr style="display:inline-block;width:98%"><div id="m_860571014849005652divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif"><b>From:</b> sword-devel <<a href="mailto:sword-devel-bounces@crosswire.org" target="_blank">sword-devel-bounces@crosswire.org</a>> on behalf of Troy A. Griffitts <<a href="mailto:scribe@crosswire.org" target="_blank">scribe@crosswire.org</a>><br><b>Sent:</b> Tuesday, February 20, 2024 12:24 am<br><b>To:</b> <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a> <<a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a>><br><b>Subject:</b> Re: [sword-devel] Catholic versification / inter-versification mappings<div> </div></font></div>
<p>Dear all,</p>
<p>These comments are a mix of background, history, and thoughts:</p>
<p>1) VERSIFICATION (v11n):</p>
<p>Variation between reference systems sucks. Until you get into
the weeds of the details, it is normal to assume the problems are
not complex. SWORD tries to implement a simple 90% solution.<br>
</p>
<p>SWORD and JSword support defined abstract versification schemes
with 3 simple dimensions: [bookid : chapterMax][chapterNumber :
verseMax][verseNumber : verseEntry]<br>
</p>
<p>Conceptually we also operate on these assumptions (I've skimmed
the proposal by Arnaud which differs here, but I haven't given it
the thought it deserves to comment yet): that book order is
defined in the v11n system; that chapter and verse numbers are
numeric and begin at 1 and increase to verseMax. We also allocate
a special slot '0' for: Module Introduction; Testament
Introduction; Book Introduction; and Chapter Introduction (e.g.,
Matt.0.0 can hold an introduction to Matthew).<br>
</p>
<p>Those who have been exposed to many Bibles will immediately think
of places these assumption fall short. But for >90% of our
Bibles, these assumption hold true, and these assumption make many
aspects of our work much simpler (abstract parsing of verse lists
and ranges, bookmark ordering, etc.).</p>
<p>Historically, SWORD previously supported dynamic, per module,
versification, with a 3 phase lookup:</p>
index file .bks[book number] = book offset in next index;<br>
index file .cps[book offset + chapter number] = chapter offset in
next index;<br>
index file .vss[chapter offset + verse number] = verse offset and
entry size in data file.
<p>20 years or so, we made the decision to begin the hard work to
understand versification systems within Bibles so we could begin
to map them appropriately. This let us remove the .bks, and .cps
index files and store that data in versification system
definitions, leaving only the final .vss index file which gave the
offsets and entry sizes into the data file.</p>
<p>Caring about versifications was a decision we made. Our previous
design let any Bible decide how many books, how many chapters, and
how many verses each chapter contained. This had its merits
because any new versification could be defined in each module
without anyone caring what it was. But the drawback was the same:
any Bible could decide how many books, how many chapters, and how
many verses without anyone knowing why or what they were.</p>
<p>Some have pushed for dynamic definitions of v11n systems again,
and I understand why. I am in favor of moving forward with a
hybrid approach: a set of defined versification systems, which a
module will still need to choose from, to which it most closely
adheres, + the ability for that module to specify its variation.<br>
</p>
<p>Toward 98%: We have tried to work around the cons of this simple
design and approach 100% support by accounting for the most common
types of problems, e.g.</p>
<ul>
<li>The engine allows common verse suffixes (e.g. Matt.2.7b);</li>
<li>The engine skips verses in a Bible which are not present--
this allows us to create v11n schemes which are a superset of n
number of closely related v11n schemes, knowing that the engine
will skip over the verses that are not present in the module; We
also have tools which print out missing verses which has proven
a good QA check for our modules team.<br>
</li>
<li>When we run across a Bible which adds an odd verse here or
there or an out of order verse, our workaround has been to
append these to end of the verse just before where they should
appear, so the text flows the same as the printed Bible, and we
include for the reader an inline visual separator and marker
showing the publisher's verse number.<br>
</li>
</ul>
<p><br>
</p>
<p>These work arounds get us pretty close to being able to support
98% of our Bibles exactly as the publisher wishes, and the
remaining 2% is supported "well enough" for no complaints by
publishers. Could we build a system which allowed out of order
verses, or which allowed any scheme a Bible wished to follow?
Sure, but the added complexity for various tasks increases quite a
bit for some of these allowances-- e.g., think index math for book
chapter verse when we cannot assume numeric sequence; think
abstract ordering of bookmarks not tied to any specific Bible,
search results across Bibles, etc.<br>
</p>
<p>Our vision with v11n definitions is that they will be a few as
possible allowing us to map between them most easily; and as many
as necessary to allow us to represent well enough a published
work.<br>
</p>
<p>Chris Little previously was our versification pumpkin holder and
did some amazing work researching all this material. As a
demonstration of his thorough work and an example of the
difficulties with v11n, see his work on just the LXX tradition:</p>
<p><a href="https://www.crosswire.org/svn/sword-tools/trunk/versification/lxx_v11ns/" target="_blank">https://www.crosswire.org/svn/sword-tools/trunk/versification/lxx_v11ns/</a></p>
<p>Chris has left our community after many years of volunteering
massive time and effort.</p>
<p>We haven't had anyone step up who is willing to commit the time
and effort necessary and who holds our vision (as few as possible,
as many as necessary).</p>
<p><br>
</p>
<p>2) MAPPINGS:</p>
<p>SWORD and JSword support v11n to v11n mappings. Graciously, Костя
Маслюк worked with us for over a year to discuss the problems and
implement a versification mapping system which has been included
in the engine. He also added v11n mappings for systems he was
interested in supporting. If anyone is interesting in the
discussions, they can see the archives, e.g.,</p>
<p><a href="https://www.crosswire.org/pipermail/sword-devel/2013-July/040154.html" target="_blank">https://www.crosswire.org/pipermail/sword-devel/2013-July/040154.html</a></p>
<p>Historically, we called this topic alternate versification, so if
you see "av11n" in the archives, you'll be aware.</p>
<p>Registering v11n systems and mappings in the engine is
straightforward in our versification manager, and as you can see,
loading these dynamically from a file would be simple to
implement:</p>
<p><a href="https://www.crosswire.org/svn/sword/trunk/src/mgr/versificationmgr.cpp" target="_blank">https://www.crosswire.org/svn/sword/trunk/src/mgr/versificationmgr.cpp</a></p>
<p>During the development of the mapping infrastructure, our proof
of concept was to see if we could concisely build a parallel Bible
HTML display across versification systems, letting a user specify
any number of Bibles, the first Bible v11n being the primary
ordering driver:</p>
<p><a href="https://www.crosswire.org/svn/sword/trunk/examples/tasks/parallelBibles.cpp" target="_blank">https://www.crosswire.org/svn/sword/trunk/examples/tasks/parallelBibles.cpp</a></p>
<p>____<br>
</p>
<p>So, now to the issue with adding another Catholic versification
system. I would love to continue to delegate ownership of v11n
decisions! I trusted Chris. He said "no" all the time, and only
allowed new versification definitions if we really couldn't
support a set of Bibles using an existing system with our work
arounds. He spent the time necessary to understand the
traditions, which published works would use the proposed
versification, he had excellent skills clearly delineating
systems-- generally he made well informed decisions from many
hours of research.<br>
</p>
<p>I don't understand the complex details nor have the time to do
the research for each individual request. My first thought is,
where is Chris?! Next, my uninformed mind thinks: we have v11n
definitions "Catholic" and "Catholic2"! Why do we need an
additional Catholic versification system? Did we do a bad job
with the first two? Can we not follow our principles and create a
superset between 2 or more of these? And of course, these are not
proper responses.<br>
</p>
<p>So, if anyone is prayfully willing to take up this pumpkin-- to
put in the time necessary to research Bible traditions and
published works, to truly understands both the pros and cons of
the decisions we've made to go down the path we are on, along with
our workarounds for the cons, and is willing to live
wholeheartedly with where we are now, but certainly always open to
improve, I would love for that person to take ownership of
versification.</p>
<p>I appreciate the pointers to the Paratext v11ns and mappings,
maybe we compare where we are now with what they have.</p>
<p>Thank you all for being zealous to improve things. Looking
forward the conversation to follow,</p>
<p>Troy<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>On 1/26/24 06:10, Arnaud Vié wrote:</p>
<blockquote type="cite">
<div dir="ltr">
<div>Hello everyone,</div>
<div><br>
</div>
<div>I'm the person Cyrille mentioned, and I just joined the
mailing list as I thought I could maybe explain a bit more
what I'm trying to do with this new versification.</div>
<div><br>
</div>
<div><b>1. Problem statement</b><br>
</div>
<div><br>
</div>
<div>Simply put, my objective is to be able to align
verse-by-verse the contents of two bibles that use different
versifications.</div>
<div>For example :</div>
<div>- I open Daniel 3 in a Catholic bible, it has 100 verses
because the Prayer of Azariah is included.</div>
<div>- I want to compare the translation verse by verse with,
for example, the KJVA. This means I want to see the Daniel 3
from KJVA, with all verses from PrAzar included in the
corresponding place.</div>
<div><br>
</div>
<div>There was already logic to perform such mapping in jsword,
and I recently included it to support deuterocanonical
contents (on the AndBible fork, since that's the only one
where I got answers from the maintainer) : <a href="https://github.com/AndBible/jsword/pull/13" target="_blank">https://github.com/AndBible/jsword/pull/13</a> </div>
<div><br>
</div>
<div>Now, the problem is to be able to do the same with the
deuterocanonical additions to the book of Esther, because
there are many different "strategies" adopted by different
bibles.</div>
<div>- Protestant bibles, when they have it, usually have it a
separate books (AddEsth in KJVA).</div>
<div>- Some catholic bibles have it as additional chapters at
the end of Esther, making Esther 16 chapters long : that's the
existing "Catholic2" versification, which maps to KJVA easily
: <a href="https://github.com/AndBible/jsword/blob/develop/src/main/resources/org/crosswire/jsword/versification/Catholic2.properties#L392" target="_blank">https://github.com/AndBible/jsword/blob/develop/src/main/resources/org/crosswire/jsword/versification/Catholic2.properties#L392</a>
<br>
</div>
<div>- Most catholic bibles actually have the additions
integrated directly within the original text, using lettered
verse numbers (13A, 13B, etc., see here for example : <a href="https://www.aelf.org/bible/Est/3" target="_blank">https://www.aelf.org/bible/Est/3</a>
)<br>
</div>
<div><br>
</div>
<div>Currently, these catholic bible with the text integrated
use the "Catholic" versification, and ignore all the lettered
verses (or include the letters as raw text) : basically,
Esther 3.13 with these additions becomes one single very long
verse. This makes it impossible to map properly with the
AddEsth of KJVA.</div>
<div><br>
</div>
<div><b>2. Proposed solution (Catholic3 versification)</b><br>
</div>
<div><br>
</div>
<div>With the proposed Catholic3 versification (except it needs
a few adjustments compared to the file proposed by Cyrille),
what I'd like to achieve is to give a unique verse number to
each of those.</div>
<div>For example, Esther 3 goes from 15 to 22 verses, with the
OSIS IDs becoming :</div>
<div>- Esth.3.13 for verse 13</div>
<div>- Esth.3.14 for verse 13A...</div>
<div>- Esth.3.20 for verse 13G</div>
<div>- Esth.3.21 for verse 14<br>
</div>
<div>(Basically, the OSIS ID identifies the position of the
verse; the actual numbering from the bible can be preserved
separately with the OSIS "n" attribute or the "\vp" USFM
keyword.)</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">would
your use-case be served if canon_catholic.h was<br>
modified to increase the verse counts in Esther to 39, 23, 22,
47, 29,<br>
14, 10, 41, 32, 14?</blockquote>
<div>Since my objective is to allow mapping verse by verse,
you'll understand that I need the verse counts to be aligned
with the actual usage. Having the "versification" allow more
verses than what's actually used defeats the purpose.</div>
<div>In addition, I believe it's a very bad idea to make big
changes to already published versifications : the point of
versifications is to give a unique ID to a verse. Updating a
versification will change all IDs for the verses of already
existing bibles that use this versification.</div>
<div>I really believe the best solution for the time being is to
create a new Catholic3 versification, as originally suggested.<br>
I can provide the full definition very soon (though since I'm
working with JSword it will be in Java format first), and it
should in theory be aligned with Catholic and Catholic2 except
for these differences in Esther. (I'll check if there are more
differences I missed).</div>
<div><br>
</div>
<div><b>3. Modular versifications</b><br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I
think at some point it would be nice to have per-book
versifications<br>
or some other way to deal with bibles that don't follow a
"standard"<br>
versification</blockquote>
<div>Agreed.<br>
</div>
<div>If everyone is open to the idea, I'd like to work in the
next few months on an extension of the OSIS standard to define
"modular" versifications, ie. versifications that can be built
by composing other versifications and applying a diff.</div>
<div>Then each bible could, in its document header, not only
reference a standard versification with refSystem, but include
its own specific changes and how they map to the standard.<br>
</div>
<div><br>
</div>
<div>Before I spend time on the topic though, is there anyone in
particular I should ask to approve the general idea, and who
would be interested in reviewing proposals on the topic ?<br>
</div>
<div><br>
</div>
<div>Thanks all and best regards,</div>
<div><br>
</div>
<div>Arnaud<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Le jeu. 25 janv. 2024 à 16:35,
pinoaffe <<a href="mailto:pinoaffe@gmail.com" target="_blank">pinoaffe@gmail.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hello,<br>
<br>
I don't know much about catholic bibles or sword, but just out
of<br>
curiosity: would your use-case be served if canon_catholic.h
was<br>
modified to increase the verse counts in Esther to 39, 23, 22,
47, 29,<br>
14, 10, 41, 32, 14? Or would the decreases in verse counts in
other<br>
chapters of other books also be necessary?<br>
<br>
And would such a change be acceptable to others?<br>
<br>
The catholic bibles I've encountered "in the wild" are the
dutch<br>
Willibrordvertaling of 1975 and the neovulgate. Both of these
appear to<br>
follow canon_catholic3.h everywhere except in Esther, where
they have 16<br>
chapters<br>
<br>
I think at some point it would be nice to have per-book
versifications<br>
or some other way to deal with bibles that don't follow a
"standard"<br>
versification, but for now we'll have to make do with what we
got<br>
<br>
Kind regards,<br>
pinoaffe<br>
<br>
Fr Cyrille <<a href="mailto:fr.cyrille@tiberiade.be" target="_blank">fr.cyrille@tiberiade.be</a>>
writes:<br>
> Hello,<br>
> Recently a person interested in the Catholic bible in
French told me<br>
> about the mapping problems between Catholic versification
and the kjva<br>
> concerning Esther. So I'm bringing up the question of a
new Catholic<br>
> versification that could better deal with this kind of
problem and at<br>
> the same time incorporate some of the errors in current
Catholic<br>
> versifications. I should mention that two versifications
for French<br>
> Bibles have been added since my proposal for a new
Catholic<br>
> versification, which was made long before these
versifications were<br>
> added, and which was not favorably received at the time.
In our case,<br>
> the number of Bibles that follow this versification is
simply<br>
> enormous, since the majority of Catholic Bibles do. I
would also add<br>
> that the LXX versification is not entirely correct. There
are no LXX<br>
> today that put 16 chapters to Esther. Ralph's already
uses letters to<br>
> integrate Greek passages into the text.<br>
> In fact, Catholic versification simply follows Ralph's.
So I suggest<br>
> that we seriously reopen this question with concrete
suggestions.<br>
> For my part, the suggestion is simple: convert the
numbers in the<br>
> Greek passages into verses and offset the numbered verses
in the same<br>
> chapters. I'll copy you on what that might look like.<br>
><br>
> Br Cyrille<br>
><br>
> [2. text/x-chdr; canon_catholic3.h]...<br>
><br>
> _______________________________________________<br>
> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
> <a href="http://crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
> Instructions to unsubscribe/change your settings at above
page<br>
<br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a>
<a href="http://crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
</blockquote>
</div></div></div>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote></div>