Robert's point about also standardizing Scripture metadata with the
ScriptureBurrito standard is a good one.
USX's limitations relative to OSIS are both an advantage and a
disadvantage. Because USX is more focused on primarily Scriptures, it
has the advantage that the markup is less ambiguous and more likely to
be understood by someone else who just read the standard, but had no
additional information. It is clearly better as an interchange format
between applications. OSIS is probably better for non-Scripture texts,
or would be if it had enough software support. Ironically, constraining
the ways in which data can be represented makes it easier to represent a
richly formatted Bible. Importing from a ScriptureBurrito could include
not only the USX Bible text, but metadata for our config files.
Both USX and OSIS lack style sheets that say how data should be
presented, since both are (mostly) semantic markup. Paratext uses
external style sheets for this purpose, at least for display within that
program. Various other publishing paths have their own style sheets,
which are not really standard.
On 2/18/24 11:41, Robert Hunt wrote:
Just to add a little to Michael Johnson's comments below, OSIS can
include significantly more metadata than USX specifies (which is
little more than the book code -- not even whether it's an original
text (Heb/Greek) or what language translation it is). OSIS can specify
many other things like version number, licenses and contributors'
names, etc.
So for a fair comparison with OSIS, I think you'd have to specify USX
*along with ScriptureBurrito metadata*: see https://www.Burrito.Bible
<https://www.burrito.bible/> (which is also in the process of being
supported by the most influential Bible-translation orgs AFAIK).
Blessings,
Robert.
https://OpenEnglishTranslation.Bible
<https://OpenEnglishTranslation.Bible>
On 19/02/24 10:19, Michael Johnson wrote:
Thank you, Michael, for the pointer to Jonathan Robie's paper on
Scriptural markup in the Bible translation community. I think it
diplomatically states why USX won out over OSIS as the primary and
best-supported XML standard for representing Scripture.
I really don't expect USFM or USX to go away any time soon, nor do I
expect OSIS to gain significant traction where it is not in use
already. I think it is safe to say that Crosswire is the group that
cares most about OSIS. In many ways, the USX vs. OSIS competition is
like the old VHS vs. BetaMax video tape competition. (Remember way
back when video tapes were actually used?) BetaMax was technically
superior in many ways, but VHS won because of (1) greater support by
content providers, (2) slightly lower cost of implementation, and (3)
incompatibility between the formats (i.e. no machine could read both
formats).
I honestly think that fully supporting USX would be a better use of
limited resources than tweaking OSIS to overcome its current defects.
For those that don't know, USX is an XML representation of USFM.
USX is well documented and actively maintained at
https://ubsicap.github.io/usx/. OSIS is abandoned by almost everyone
by Crosswire. Backup copies of the Schema or on crosswire.org and
eBible.org, but there is currently no official pumpkin holder to
maintain it.
USX is fully automatically convertable to and from USFM with no loss
or human intervention needed. This is not true of pure OSIS for
technical and philosophical reasons. This is probably the biggest
reason that OSIS was never supported natively in Paratext, and most
likely never will be.
USX is the native format of the Every Tribe Every Nation Digital
Bible Library, which is the highest-quality and best-supported
repository of Bible translations in the world.
USX and/or USFM are supported by all of the best Bible translation
software, including open source options. OSIS has no Bible
translation software support.
USX and/or USFM are supported by numerous Bible publishing options,
both digitally and for print. OSIS has no significant Bible
publishing support outside of Crosswire.
USX has organizational support from the most influential Bible
translation agencies.
Using USX and/or USFM makes versification mapping easier, because
someone else has already done the work.
There are currently at least 2 reasonable ways to convert from USFM
or USX to OSIS with minimal losses in formatting. Neither one is
perfect, but maybe good enough. There is a lot of code assuming OSIS
inputs to Sword modules, and that could remain, along with GBF and
TEI, but I can see better quality coming from direct USX support.
If OSIS is good enough as is, fine. But if it isn't, then I suggest
that it be phased out rather than modified.
On 2/18/24 09:42, Michael H wrote:
Re: Lack of momentum for OSIS.
OSIS as described on wikipedia is owned by a committee including
United Bible Societies, SIL International, and the Society of
Biblical Literature.
However, this team got together and created the version that is
available, then almost completely ignored it, and went back to the
SFM tagging system and then produced USFM, when turned into several
more closely related XML languages, but has become USX. There was in
the UBS/SIL Paratext translation program the ability to produce OSIS
output until version 8, but since about 2016, there is no use or
mention of OSIS in Paratext.
A history and analysis of why this is published in Balisage 2021
conference:
https://www.balisage.net/Proceedings/vol26/html/Robie01/BalisageVol26-Robie01.html
Even in 2024, the tagging language USFM remains the "primary" tool
to encode biblical works at almost all the organizations that
produced OSIS. There is no momentum for that committee to ever meet
again. But the spec has holes.
https://gitlab.com/cmahte/osis-users-manual-2.1
I started working on updating OSIS, and in the process received a
reply from someone at ABS or UBS that although the OSIS spec is
copyrighted and does not contain specific verbiage about reuse, I
could and should consider it licensed under creative commons BY-SA.
(At the time, I wasn't seeking to update OSIS, but freely copy from
it in creating a successor or fork.)
This means that OSIS is both abandoned and available for adoption by
a successor body. I've also since moved on from ever producing
proposed changes to it or a fork myself. IF I ever got far enough
along to need a formal spec, it would be extensions USFM or to
OpenDocument or more directly synonymous with that XML. If you're
interested, I'll dig up the contact information, and pass it along.
But I do have a copy re-edited into USFM (or more specifically a
draft version of PSFM... which means the way tables are built in my
text are unusual.) If there is an effort to update. I can transform
my work into LibreOffice Writer format.
I suggest it is time to consider an OSIS 3, or at least an OSIS 2.2
spec that is owned by a successor organization instead of
organizations that effectively abandoned it. That's the missing link
which would provide a mechanism to actually make changes to the
standard. People (including me) keep doing this search and landing
at Crosswire Bible society as the best option for a new owner. But
maybe who OWNS can be one of the topics considered by a committee.
On Sat, Feb 17, 2024 at 9:47 AM Arnaud Vié <unas.zole+a...@gmail.com
<mailto:unas.zole%2ba...@gmail.com>> wrote:
Hi everyone,
Having dived into the whole crosswire ecosystem recently, I'm at
the same time impressed at the quality of the tools provided (in
particular the OSIS standard and the JSword lib, as I've been
working in Java), and worried by what I perceive as a lack of
dynamism around it's development and difficulty to contribute.
By "lack of dynamism" I of course don't mean to criticise the
time anyone spends (as we contribute to a free ecosystem, we all
have lives keeping us busy elsewhere), but rather to highlight
how rough it is for external enthusiastic people to join.
For example, I'd like to contribute evolutions to the OSIS
standard around versification systems, but I have no idea where
to make such proposals, as there is only a mailing list dead
since 2015 <http://crosswire.org/pipermail/osis-core/>, a few
wiki pages <https://wiki.crosswire.org/Category:OSIS> and a few
downloadable documents <https://crosswire.org/osis/> which are
supposedly the latest version.
I think a lot of that could be improved by making better use of
the crosswire github project <https://github.com/crosswire>,
which is nowadays the first contact most young developers will
have with these crosswire projects.
I'd like to propose a few changes, get your opinions, and
volunteer to execute them if everyone agrees.
* *Revive the jsword github repository*.
That includes
o Backporting the relevant changes from the andbible fork
<https://github.com/AndBible/jsword/pulls?q=is%3Apr+is%3Aclosed>
(excluding android-specific stuff - which I already
mostly removed in my last PR there).
o Setting up a release process to publish the jar on a
maven repository.
o Setting up a clear branching model and writing clear
contribution guidelines.
o Having a team of several people familiar with Java
development to review PRs or answer questions in the
issue tracker. I obviously volunteer, but more people is
always the best.
* *Create a new Git repository for the OSIS specification*.
Must contain :
o In Git, the OSIS XSD schema, and the functional
specification (basically, the contents of the current
manual) in markdown or asciidoc format.
So that contributions to the standard may be opened as
pull requests, reviewed, potentially stored as separate
branches, etc.
o A wiki tab where all relevant OSIS-related resources
from the crosswire wiki should be copied.
* Ideally, I'd also suggest *moving the C++ sword code to github*.
Having it only on an old SVN repo
<https://crosswire.org/svn/sword/trunk/>, not browsable or
searchable online, really harms its visibility. I used a
little bit of SVN while in engineering school 12 years ago,
but I doubt that most young devs nowadays even know about it.
But for this last C++ part, I suspect it has bigger impact on
current developers, since Troy is still actively developing it
and using the Jira bugtracker for this part - so there is no
urgent need to change.
I'm really more worried about the jsword repo (it breaks my
heart to see it dead since 2019) and having a visible and
versioned location for the OSIS standard.
Please let me know your thoughts !
And whoever is currently admin of the github project, would you
be willing to grant me some permissions on the jsword repo and a
new "osis-spec" repo to start setting up all of this ?
Regards,
Arnaud Vié
_______________________________________________
sword-devel mailing list:sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
--
signature
Aloha,
*/Michael Johnson/**
26 HIWALANI LOOP • MAKAWAO HI 96768-8747*• USA
mljohnson.org <https://mljohnson.org/> • eBible.org <https://eBible.org>
• WorldEnglish.Bible <https://WorldEnglish.Bible> • PNG.Bible
<https://PNG.Bible>
Signal/Telegram/WhatsApp/Telephone: +1 808-333-6921
Skype: kahunapule • Telegram/Twitter: @kahunapule • Facebook:
fb.me/kahunapule <https://www.facebook.com/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
