versification

[Daniel STOEKL BEN EZRA]

Thanks to Robert, Neil and David for your responses.

Robert, I am not sure from reading the blog I understand what exists and what you plan for. Could you be so kind to indicate which of the many readme files contains the description of how do you suggest to work?

Many thanks

Daniel

[Robert Hunt]

New Zealand.

Hi Daniel,

    Ok, I thought I had written quite a bit of explanation, but obviously too many details and not enough overview, and I know that it's always very difficult to get started into someone else's code.

    I tried to write a Bible organization system, usable say by a program that displays various translations, including parallel and interlinear displays, as well as searches, etc. It was aimed to be as international/multilingual/multicultural (and cross-platform) as possible and driven by standards where they exist, e.g., XML and Unicode. My test code was Python3, but JSON and other formats of the XML data (which is the real essence of the system) are also generated. (Presumably these might be what Neal is using? If so, I'm interested in any feedback.)

    At the highest level, if you would specify a code for a specific Bible publication, e.g., (English) KJV-1611 or KJV-1769 or (Greek) LXX or (Latin) VUL, the system would know the publication details about that version, including the display language/font, the versification used, the books included (and their names and abbreviations for search) and in which order, front and back matter, etc. (Of course, my personal knowledge is limited, so it would require a collective effort to enter the information for the several thousand languages in the world that have some kind of Bible publication.)

    The areas which are considered "done" below usually consist of one or more XML files, Python3 code to parse, check very thoroughly, handle, and export this data. There are also unit tests to help catch any regressions resulting from any future modifications.

    So let's look at this starting from the bottom level:

• Standard codes for Bible and non-canonical books -- done (including mapping to/from other book code subsets)
  
• Bible book names and book order -- done, done
• Bible punctuation systems -- done
• Bible reference parsing -- not committed yet
  
• Bible versification systems (including knowledge of omitted and combined/reordered verses) -- just committed today, not widely tested yet
  
• Bible versification mappings (down to 1/2, 1/3, or 1/4 verse accuracy) -- not completed or committed yet
• Bible editions, revisions, translations, and originals (including pointers to facsimiles where possible) -- not committed yet
  
• Import and export routines (USFM, OSIS, etc.) -- not committed yet
• Links to lexicons, notes, commentaries, and other resources -- nothing committed yet
  
• Mappings between different Bible translations, and between translations and originals -- not started yet
• Top level Bible display application -- not started yet
• Top level Bible editor application -- not started yet
  

    So how it might be used? Well, sadly it remains unfinished, although some of the low-level research (the first three lines in the list above) is already usable.

    I consider the Python3 code to be proof-of-concept. It's not optimised for performance at all and may not yet contain all of the routines that will be required by the higher levels. Some refactoring of the code is still likely to happen (and possibly even of the XML data). My personal aim is to work down through the entire list above in order to thoroughly test the data structures. Then it could potentially be recommended as a well-planned base for any program that handles a range of Bibles.

    I hope this gives a bit more understanding of where this project is at.

Shalom,
Robert.

[Neal Audenaert]

Hi Robert,

Thanks for that overview, that's very helpful. For me, I've just gotten started looking at your code and XML files. The first four points all make lots of sense and I'm quite interested in digging into the Bible versification that you've just checked in. 

As for the punctuation system, can you clarify how see that being used? This is probably just ignorance of how Bible applications are built, but but the use cases for that aren't very clear to me.

Neal

--
You received this message because you are subscribed to the Google Groups "Open Scriptures" group.
To post to this group, send email to openscr...@googlegroups.com.
To unsubscribe from this group, send email to openscripture...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openscriptures?hl=en.

--
Neal Audenaert

Institute for Digital Christian Heritage

979.739.5636 | ne...@idch.org

http://DigitalChristianHeritage.org

[Robert Hunt]

The Bible punctuation system is part of the foundation of the Bible
reference parsing system (not committed to Git yet). If you want to
parse a cross-reference from the text or especially if you want to be
able to automatically check a Bible for errors (which is part of my
interest as a Bible translator), it's helpful to know the expected form
such as 1 Kgs 1:3-7a vs 1Kg 1:3-7a (both English), or Num. 1:4-9
(English) vs 4 Mos 1.4-9 or IV Mos 1.4-9 (German?).

Robert.

[Neal Audenaert]

Thanks Robert, that's helpful.

--
You received this message because you are subscribed to the Google Groups "Open Scriptures" group.

To post to this group, send email to openscriptures@googlegroups.com.
To unsubscribe from this group, send email to openscriptures+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/openscriptures?hl=en.

[Daniel STOEKL BEN EZRA]

Many thanks for all your comments and reflections. Weston, I am skeptical with regard to the feasibility of a very fine grained word by word correspondence at this time. Yes, you can have a wonderful product as an outcome, something like Muraoka’s Hebrew equivalent list for the Septuagint, but you will spend years – or decades if you are talking about more than two Bibles.

I think instead of a bottom up, a top-down system is easier to assemble with regard to the masses of data.

Thanks Robert for uploading xmls for the max number of verses of any given chapter of the bible. I did already have such data in my database. What I am missing is the data permitting the conversion of one versification information, e.g. LXX, into another, e.g. MT or Vul. Please excuse me for my insistence and maybe my incomprehension. I am a scholar who can find his way around in computer stuff, sometimes, not a professional programmer. We work on quite a big project with a relational database on Jewish and Christian lectionaries. So I really need versification – as well as date conversion. To those among you who are database heroes (we work in mysql not in xml but that is not a problem) : what scheme seems more error-proof and elastic for future development and feasible at the same time with regard to feeding a database :

a)      One huge main table X with one line for every verse whose contents appear in at least one given Bible (so including Ethiopic with Enoch and Jubilees or Armenian with 3Corinthinthians). All verses in all other Bibles A, B, C are linked to the verses in this main table with a foreign key. Conversion of versification is through the intermediary X. Once the verses have been done, one could go and tune the granulation finer and go to half-verses. New verses that appear in new Bibles can be easily appended. Difficulty to implement multi-multi relationships if one verse appears several times in another Bible. Verses not existing in one Bible are simply not existing in the table of their versification correspondance to X.

b)      One table indicating the versification changes between any two given Bibles. These can often be pretty short and indicate only those verses that are different such as in the Bibleworks tables. But if you have 5 Bibles entered and you want to enter a sixth Bible you would have to add 5 new versification-conversion tables. All verses not existing in any other version have to be noted extra.

I tend to see more advantages in a. Would greatly appreciate any comments.

Daniel

[Peter von Kaehne]

On 09/12/11 15:56, Daniel STOEKL BEN EZRA wrote:
> Would greatly appreciate any comments.

Are you aware that CrossWire is doing (slowly) some work on this matter too?

Peter

[Butrus Damaskus]

On Fri, Dec 9, 2011 at 4:56 PM, Daniel STOEKL BEN EZRA
<sto...@mmsh.univ-aix.fr> wrote:
> Many thanks for all your comments and reflections. Weston, I am skeptical
> with regard to the feasibility of a very fine grained word by word
> correspondence at this time. Yes, you can have a wonderful product as an
> outcome, something like Muraoka’s Hebrew equivalent list for the Septuagint,
> but you will spend years – or decades if you are talking about more than two
> Bibles.
>
> I think instead of a bottom up, a top-down system is easier to assemble with
> regard to the masses of data.
>
> Thanks Robert for uploading xmls for the max number of verses of any given
> chapter of the bible. I did already have such data in my database. What I am
> missing is the data permitting the conversion of one versification
> information, e.g. LXX, into another, e.g. MT or Vul. Please excuse me for my
> insistence and maybe my incomprehension. I am a scholar who can find his way
> around in computer stuff, sometimes, not a professional programmer. We work
> on quite a big project with a relational database on Jewish and Christian
> lectionaries.

I would be very interested in this, will this database be freely available?
What sort of informations you intend to provide?

> So I really need versification – as well as date conversion.
> To those among you who are database heroes (we work in mysql not in xml but
> that is not a problem) : what scheme seems more error-proof and elastic for
> future development and feasible at the same time with regard to feeding a
> database :
>
> a)      One huge main table X with one line for every verse whose contents
> appear in at least one given Bible (so including Ethiopic with Enoch and
> Jubilees or Armenian with 3Corinthinthians). All verses in all other Bibles
> A, B, C are linked to the verses in this main table with a foreign key.
> Conversion of versification is through the intermediary X. Once the verses
> have been done, one could go and tune the granulation finer and go to
> half-verses. New verses that appear in new Bibles can be easily appended.
> Difficulty to implement multi-multi relationships if one verse appears
> several times in another Bible. Verses not existing in one Bible are simply
> not existing in the table of their versification correspondance to X.
>
> b)      One table indicating the versification changes between any two given
> Bibles. These can often be pretty short and indicate only those verses that
> are different such as in the Bibleworks tables. But if you have 5 Bibles
> entered and you want to enter a sixth Bible you would have to add 5 new
> versification-conversion tables. All verses not existing in any other
> version have to be noted extra.

I would probably go for yet another approach: create some (hypothetic)
"standard version" and have a table which would record any differences
between the actual versions and the virtual "standard version".

> I tend to see more advantages in a. Would greatly appreciate any comments.
>
> Daniel
>

> --
> You received this message because you are subscribed to the Google Groups
> "Open Scriptures" group.

> To post to this group, send email to openscr...@googlegroups.com.

> To unsubscribe from this group, send email to

> openscripture...@googlegroups.com.

[kingdomme...@gmail.com]

Can anyone help me with a copy of the KJV that can be used in bibledit I cant seem to find a proper one at all