Re: [sword-devel] Adding another Bible version

[Kahunapule Michael Johnson]

Hello David and all,

To add the Valera 1602 Purificada to the Sword project would require (1) 
permission, and (2) digital files in an acceptable format (OSIS, USFM, USX, or 
USFX).
It looks like the permission granted in 
https://www.valera1602.org/_files/ugd/804ef4_18fd4564ee2340f0ba4d3d661cef36d2.pdf
 is functionally equivalent to a CC-BY-ND-NC license, so the permission part is 
handled.

Whoever reads i...@valera1602.org email: do you have some digital files of this 
Bible translation in USFM, USX, OSIS, or something easy to convert to one of 
those formats? If so, could we please have a copy so that we can make it 
available to users of the Sword Project family of apps, including AndBible?

Thanks!

On 2/20/24 12:14, David Rez wrote:

Hello,

 I was wondering if you all can add a Spanish Bible version called Reina Valera 
Purificada 1602? It's a Spanish Bible created to read more like to the king James 
version. I use the "and Bible" app and they said to ask you all. Thank you


--
signature

Aloha,
*/Michael Johnson/**
26 HIWALANI LOOP • MAKAWAO HI 96768-8747*• USA
mljohnson.org  • eBible.org  • 
WorldEnglish.Bible  • PNG.Bible 
Signal/Telegram/WhatsApp/Telephone: +1 808-333-6921
Skype: kahunapule • Telegram/Twitter: @kahunapule • Facebook: fb.me/kahunapule 

___
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] Adding another Bible version

[David Rez]

Hello,

 I was wondering if you all can add a Spanish Bible version called Reina
Valera Purificada 1602? It's a Spanish Bible created to read more like to
the king James version. I use the "and Bible" app and they said to ask you
all. Thank you
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] Catholic versification / inter-versification mappings

[Kahunapule Michael Johnson]

Well said, Arnaud. It doesn't have to be an either/or choice between 
presentation as the translators intend and the ability to correlate matching 
content. Troy and I could both enjoy our different use cases, which are 
actually not unique just to Troy and me. It is worth the work to make both 
cases available.

On 2/20/24 05:09, Arnaud Vié wrote:

Thank you for your interest and your time !
And thanks Troy for your valuable historical explanation.

However, I can't help but feel that you all are underestimating the power of 
OSIS !
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.
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.
That's part of the reason why I fell in love with the format and believe it's 
worth maintaining.


In particular, some cases Michael mentions :

Chapter and verse "numbers" aren't always pure numbers. Letters get 
involved in the Deuterocanon/Apocrypha.

Here, OSIS already provides a distinction between :

  * 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.
  * The published number (the verse or chapter's "n" attribute) which is a free 
text, allowing to preserve the numbering from the published document.

In fact USFM provides a similar distinction between the "v" and "vp", "c" and 
"cp" keywords.
You can check the example in my first email about the proposed Catholic3 versification 
 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.
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).
The "n" attributes are what should be presented to the users when reading a 
bible.

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.


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)
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.



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.
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.
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.
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.



Le mar. 20 févr. 2024 à 14:54, Peter von Kaehne  a écrit :

There are two aspects here:

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.

The complications coming in due to modern translation are actually very 
limited:

FWIW, most modern translations which play about with versifications still 
actually follow an underlying well known and documented plan.

NRSV(A) eg seems to be all what UBS and Wycliffe use - even when allowing 
for verse bridges, reordering and more.

Which makes me think we should think more about a presentation overlay 
which we have at the moment very rudimentary only. OSIS 

Re: [sword-devel] Catholic versification / inter-versification mappings

[Arnaud Vié]

Thank you for your interest and your time !
And thanks Troy for your valuable historical explanation.

However, I can't help but feel that you all are underestimating the power
of OSIS !
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.
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.
That's part of the reason why I fell in love with the format and believe
it's worth maintaining.


In particular, some cases Michael mentions :

Chapter and verse "numbers" aren't always pure numbers. Letters get
> involved in the Deuterocanon/Apocrypha.


Here, OSIS already provides a distinction between :

   - 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.
   - The published number (the verse or chapter's "n" attribute) which is a
   free text, allowing to preserve the numbering from the published document.

In fact USFM provides a similar distinction between the "v" and "vp", "c"
and "cp" keywords.
You can check the example in my first email about the proposed Catholic3
versification
 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.
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).
The "n" attributes are what should be presented to the users when reading a
bible.

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.


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)
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.



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.
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.
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.
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.



Le mar. 20 févr. 2024 à 14:54, Peter von Kaehne  a écrit :

> There are two aspects here:
>
> 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.
>
> The complications coming in due to modern translation are actually very
> limited:
>
> FWIW, most modern translations which play about with versifications still
> actually follow an underlying well known and documented plan.
>
> NRSV(A) eg seems to be all what UBS and Wycliffe use - even when allowing
> for verse bridges, reordering and more.
>
> 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.
>
> 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.
>
> This would to my mind be a much better solution than ever increasing
> further system of av11n or indeed a complete 

Re: [sword-devel] Catholic versification / inter-versification mappings

[Peter von Kaehne]

  
  
  

There are two aspects here: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. The complications coming in due to modern translation are actually very limited:FWIW, most modern translations which play about with versifications still actually follow an underlying well known and documented plan. NRSV(A) eg seems to be all what UBS and Wycliffe use - even when allowing for verse bridges, reordering and more. 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. 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. This would to my mind be a much better solution than ever increasing further system of av11n or indeed a complete rewrite. Peter
Sent from Outlook for iOS
  

 From: sword-devel  on behalf of Troy A. Griffitts Sent: Tuesday, February 20, 2024 12:24 amTo: sword-devel@crosswire.org Subject: Re: [sword-devel] Catholic versification / inter-versification mappings 

  

  
  
Dear all,
These comments are a mix of background, history, and thoughts:
1) VERSIFICATION (v11n):
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.

SWORD and JSword support defined abstract versification schemes
  with 3 simple dimensions: [bookid : chapterMax][chapterNumber :
  verseMax][verseNumber : verseEntry]

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).

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.).
Historically, SWORD previously supported dynamic, per module,
  versification, with a 3 phase lookup:
index file .bks[book number] = book offset in next index;
index file .cps[book offset + chapter number] = chapter offset in
next index;
index file .vss[chapter offset + verse number] = verse offset and
entry size in data file.
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.
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.
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.

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.

  The engine allows common verse suffixes (e.g. Matt.2.7b);
  The engine skips verses in a Bible which are not present--
this allows us to create v11n schemes which are a superset of n