[sword-devel] Chapter-centric browsing (was: iPhone frontend alpha screenshots)

[Greg Hellings]

On Mon, Nov 24, 2008 at 2:37 PM, Eeli Kaikkonen
<eekaikko at mail.student.oulu.fi> wrote:
> What boundary do you exactly mean? There are two problems: First, not
> all translations have paragraphs/passages. Second, if we want to have a
> system for all translations we have to create a paragraph division
> anyways. It could of course be a normal division with next
> paragraph/passage beginning where the previous one end. But the Biblical
> text have not been written like that. Many times the flow of thought is
> like this:

I mean the natural boundaries which already exist in translations.
For some translators, they believe that every verse is a paragraph
unto itself (the classic English example being the KJV) while many
others impose actual paragraph boundaries wherever they see fit.  For
those which have no such boundary or are paragraph-per-verse,
displaying a chapter at a time is fine.  For those with paragraph
boundaries, following the boundaries already given by the translators
by displaying where paragraphs are already broken in the text is more
natural.

>
> P1 -----------------------
> P2           -----------------------------
>
>
> But the modern way of dividing text is like this:
> P1 --------------------   P2 ---------------------
>
> That is one reason why different translations have different
> paragraph/passage boundaries. With the proposed system we could always
> get the larger passage, which is "safer" if we want to find context for
> some specific verse or some other small section. Additionally it could
> be even easier to create overlapping passage divisions because making
> decision between two possibilities may be quite difficult (which, again,
> can be seen in different translations).

Doing this would mean that we are imposing our own divisions and
decisions upon the passages, rather than attempting to faithfully
represent what the translators and publishers wanted to display.
Plus, you run into issues if we have a flat model (which, admittedly,
many publications use) or if we're trying to encode a text which not
only might have some over-lapping passages, but which might have whole
segments which are sub-portions of other segments (e.g. those study
Bibles which use an outline - what granularity of the outline for each
book should be used for displaying?).  Our view that a natural
boundary occurs between two verses might be completely different from
the translator or publisher who feels the natural boundary is in the
middle of a verse, or even that our verse-boundary division is in the
middle of a sentence in that translator's opinion.

As a simple example, look at Ephesians 1:3-23.  In my NIV-based Ryrie
Study Bible, there are paragraph beginnings at 3, 11 and 15 and the
whole section is outline segment II.A.  II.B. runs from 2:1-10, II.C.
runs from 2:11-22, II.D. encompasses all of chapter 3.  Should just A
be displayed?  How about all of II?  My USB 4th revised edition has
section headers at 1:3, 1:15, 2:1, 2:11, 3:1, 3:14.  It lacks the
paragraph division at 1:11 and introduces section headers at 1:15 and
3:14 which the Ryrie editors inserted.  My Jersualem Bible has the
exact same "section" divisions as the USB text, and also lacks the
paragraph break at 1:11, however it considers all of 1:3-1:14 to be in
verse form.  In fact, the 1:10-1:11 boundary isn't even a sentence
boundary in the Jerusalem Bible.

It seems to me that allowing the encoded paragraph or, possibly, even
section boundaries to be the natural division would make the most
sense.  Additionally, if future Bibles are prepared in the General
Book format, that would allow each text to have its own natural
divisions encoded even more rigidly than looking for paragraph or
other inferred boundaries.

--Greg

>
>
> --Eeli Kaikkonen
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>