Re: OSIS and intros

brickviking <[email protected]> Mon, 14 Jul 2025 12:07:49 +1200
Newsgroups gmane.comp.literature.sword.devel
Message-ID <CAHWye85EkU5ADQFUHPvOvKBKUNddUo1koPhxUej8boeHqL==PQ@mail.gmail.com>
--===============2208234569812002651==
Content-Type: multipart/alternative; boundary="00000000000071b3bf0639d8752b"

--00000000000071b3bf0639d8752b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I, like others, was also hoping for a way to put book introductions into
some bible format for translation into mod format. So far I've come up
relatively empty, and it seems reasonably obvious that at least OSIS
doesn't provide for book-level introductions, let alone chapter-level,
without some strange interpretation in either of Xiphos or Ezra. I haven't
really tried to see what Bibletime does. For example, one version I have of
the printed The Message bible includes these introductions, and I was
attempting to make myself a sword module I can carry around.

Ah well, that's the way things go, I guess.

God be with you,
brickviking


On Sat, 12 Jul 2025 at 08:34, pinoaffe <[email protected]> wrote:

>
> DM Smith <[email protected]> writes:
> > The issue with heuristics is that they essentially enforce
> > assumptions, which may very well be wrong.
> I think a heuristic along the line of "Does this book group contain only
> new testament books and are all new testament books that are present in
> this bible contained in this book group" might be good enough for our
> purpose
>
> > The module team has a usfm2osis.py to convert USFM to OSIS. Michael
> > also has one. The nature of USFM is that it=E2=80=99s goal is presentat=
ion not
> > OSIS=E2=80=99s nature of semantic markup. I don=E2=80=99t know how that=
 transformation
> > handles intro material. I=E2=80=99m pretty sure neither has a begin/end
> > testament construct. It is a simple thing to manually add such after
> > transformation if that fits with one=E2=80=99s workflow.
> >
> > I think it=E2=80=99s a shortcoming of the OSIS spec that it is flexible=
 when
> > marking up testaments. Your suggestion of explicitly marking testament
> > may be the only real solution. In the KJV=E2=80=99s OSIS it uses
> > type=3D=E2=80=9CbookGroup=E2=80=9D subType=3D=E2=80=9Cx-{testament}=E2=
=80=9D where {testament} is OT or
> > NT. It also uses x-DC for the apocrypha.
> I think OSIS's flexibility is also its strength, particularly when it
> comes to milestoning and giving module authors freedom on how to
> structure their bibles - otherwise many bibles could not be represented
> in OSIS.  However, an additional list of standards/conventions would be
> good to add, at the very least something like "If you have a testament
> bookGroup, represent it like this, if you have a gospels bookgroup,
> represent it like this, etc.
>
> In general, I think it would be good if the OSIS spec got a major
> overhaul.
>
> > I=E2=80=99m wondering whether SWORD=E2=80=99s [ Testament 1|2 Heading ]=
 could/should
> > be represented as an OSIS ID, type or subType.
>
> I've not put much thought into this, but have no strong preference
>
> > Should a mechanism be imposed on OSIS creators? We=E2=80=99ve resisted =
that as
> > much as possible.
> I feel like it would not be much of an imposition.  We could even add an
> (optional?)  preprocessing script that tries to group books by testament
> _______________________________________________
> sword-devel mailing list: [email protected]
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>

--00000000000071b3bf0639d8752b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I, like others, was also hoping for a way to put book intr=
oductions into some bible format for translation into mod format. So far I&=
#39;ve come up relatively empty, and it seems reasonably obvious that at le=
ast OSIS doesn&#39;t provide for book-level introductions, let alone chapte=
r-level, without some strange interpretation in either of Xiphos or Ezra. I=
 haven&#39;t really tried to see what Bibletime does. For example, one vers=
ion I have of the printed The Message bible includes these introductions, a=
nd I was attempting to make myself a sword module I can carry around.<div><=
br></div><div>Ah well, that&#39;s the way things go, I guess.</div><div><br=
></div><div>God be with you,</div><div>brickviking</div><div><br></div></di=
v><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Sat, 12 Jul 2025 at 08:34, pinoaffe &lt;<a href=3D"mai=
lto:[email protected]">[email protected]</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><br>
DM Smith &lt;<a href=3D"mailto:[email protected]" target=3D"_blank">dms=
[email protected]</a>&gt; writes:<br>
&gt; The issue with heuristics is that they essentially enforce<br>
&gt; assumptions, which may very well be wrong.<br>
I think a heuristic along the line of &quot;Does this book group contain on=
ly<br>
new testament books and are all new testament books that are present in<br>
this bible contained in this book group&quot; might be good enough for our<=
br>
purpose<br>
<br>
&gt; The module team has a usfm2osis.py to convert USFM to OSIS. Michael<br=
>
&gt; also has one. The nature of USFM is that it=E2=80=99s goal is presenta=
tion not<br>
&gt; OSIS=E2=80=99s nature of semantic markup. I don=E2=80=99t know how tha=
t transformation<br>
&gt; handles intro material. I=E2=80=99m pretty sure neither has a begin/en=
d<br>
&gt; testament construct. It is a simple thing to manually add such after<b=
r>
&gt; transformation if that fits with one=E2=80=99s workflow.<br>
&gt;<br>
&gt; I think it=E2=80=99s a shortcoming of the OSIS spec that it is flexibl=
e when<br>
&gt; marking up testaments. Your suggestion of explicitly marking testament=
<br>
&gt; may be the only real solution. In the KJV=E2=80=99s OSIS it uses<br>
&gt; type=3D=E2=80=9CbookGroup=E2=80=9D subType=3D=E2=80=9Cx-{testament}=E2=
=80=9D where {testament} is OT or<br>
&gt; NT. It also uses x-DC for the apocrypha.<br>
I think OSIS&#39;s flexibility is also its strength, particularly when it<b=
r>
comes to milestoning and giving module authors freedom on how to<br>
structure their bibles - otherwise many bibles could not be represented<br>
in OSIS.=C2=A0 However, an additional list of standards/conventions would b=
e<br>
good to add, at the very least something like &quot;If you have a testament=
<br>
bookGroup, represent it like this, if you have a gospels bookgroup,<br>
represent it like this, etc.<br>
<br>
In general, I think it would be good if the OSIS spec got a major<br>
overhaul.<br>
<br>
&gt; I=E2=80=99m wondering whether SWORD=E2=80=99s [ Testament 1|2 Heading =
] could/should<br>
&gt; be represented as an OSIS ID, type or subType.<br>
<br>
I&#39;ve not put much thought into this, but have no strong preference<br>
<br>
&gt; Should a mechanism be imposed on OSIS creators? We=E2=80=99ve resisted=
 that as<br>
&gt; much as possible.<br>
I feel like it would not be much of an imposition.=C2=A0 We could even add =
an<br>
(optional?)=C2=A0 preprocessing script that tries to group books by testame=
nt<br>
_______________________________________________<br>
sword-devel mailing list: <a href=3D"mailto:[email protected]" targ=
et=3D"_blank">[email protected]</a><br>
<a href=3D"http://crosswire.org/mailman/listinfo/sword-devel" rel=3D"norefe=
rrer" target=3D"_blank">http://crosswire.org/mailman/listinfo/sword-devel</=
a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote></div>

--00000000000071b3bf0639d8752b--

--===============2208234569812002651==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
sword-devel mailing list: [email protected]
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

--===============2208234569812002651==--