Details
-
Type:
Bug
-
Status: Open (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.9.0
-
Fix Version/s: None
-
Labels:None
Description
I have just observed a significant technical problem that may well turn out to be a software issue in the SWORD API.
OSHB is the initialism for Open Scriptures Hebrew Bible.
The diatheke output from the OSHB module using the output option -o n for Strong's numbers does not include any of the codes with a letter suffix that are part of the extended Strong's dictionary and markup devised for the OSHB project and maybe more widely used by some other modules since (e.g. those from Tyndale House).
Aside: This puts a whole new slant on the comparisons that I've done so far for the Strong's numbers in the CrossWire KJV project.
It will no doubt mean that some of my earlier reported observations will need to be revised once the dust settles.
This may also be where the JSword fork that is part of the STEPBible project is now ahead of the SWORD engine!
It's not just diatheke which shows the symptoms; it must also be that all SWORD-based front-ends do not include the letter suffixed codes when Strong's are displayed.
Whether they truncate the letter suffices or omit these entire codes is something I've yet to determine. More likely the former, but it needs checking.
Of course, it may simply be that when the extended Strong's codes were first proposed,
nobody thought to check whether they might not yet be supported in the SWORD API,
as all the attention would have been within front-end[s] based on JSword.
Problem reported after using diatheke command-line SWORD frontend Version 4.7 distributed with xiphos.exe 4.2.1 (gtk2 webkit1)
I assume that this was built with SWORD v1.9 - so correct me if I'm mistaken.
I have attached a counted list of the eXtended only Strong's numbers extracted from the exported IMP file generated (using mod2imp) from the OSHB module.
David Haslam
CrossWire volunteer since 2008
Mostly focused on text and module development and module testing/analysis.
Attachments
Activity
For the H-numbers with a letter suffix, SWORD simply truncates the extended Strong's code to display the numerical part only. It does not remove the H-number entirely.
David, it would be very helpful if you could provide a single example of the problem. I appreciate your comprehensive list of counts, but I would simply like 1 verse which displays the problem. Thank you!
The latest version of the OSHB module has an example in the very first verse of the Bible.
Shown in bold below:
$$$Genesis 1:1
<w lemma="strong:Hb strong:H7225" morph="oshm:HR/Ncfsa">בְּרֵאשִׁ֖ית</w> <w lemma="strong:H1254a" morph="oshm:HVqp3ms">בָּרָ֣א</w> <w lemma="strong:H0430" morph="oshm:HNcmpa">אֱלֹהִ֑ים</w> <w lemma="strong:H0853" morph="oshm:HTo">אֵ֥ת</w> <w lemma="strong:Hd strong:H8064" morph="oshm:HTd/Ncmpa">הַשָּׁמַ֖יִם</w> <w lemma="strong:Hc strong:H0853" morph="oshm:HC/To">וְאֵ֥ת</w> <w lemma="strong:Hd strong:H0776" morph="oshm:HTd/Ncbsa">הָאָֽרֶץ</w><seg type="x-sof-pasuq">׃</seg>
cf. The earlier version of the OHSB module back in 2014 had much more elaborate XML, viz.
$$$Genesis 1:1
<w lemma="OSHBprefix:b strong:H7225" n="1.0"><seg type="x-morph">בְּ</seg><seg type="x-morph">רֵאשִׁ֖ית</seg></w> <w lemma="strong:H1254 OSHBaugment:a"><seg type="x-morph">בָּרָ֣א</seg></w> <w lemma="strong:H430" n="1"><seg type="x-morph">אֱלֹהִ֑ים</seg></w> <w lemma="strong:H853"><seg type="x-morph">אֵ֥ת</seg></w> <w lemma="OSHBprefix:d strong:H8064" n="0.0"><seg type="x-morph">הַ</seg><seg type="x-morph">שָּׁמַ֖יִם</seg></w> <w lemma="OSHBprefix:c strong:H853"><seg type="x-morph">וְ</seg><seg type="x-morph">אֵ֥ת</seg></w> <w lemma="OSHBprefix:d strong:H776" n="0"><seg type="x-morph">הָ</seg><seg type="x-morph">אָֽרֶץ</seg></w><seg type="x-sof-pasuq">׃</seg>
It also included Strong's numbers with a letter prefix, but this approach seems to have been abandoned now that the module features Hebrew morphology codes specially developed for the project.
btw. That earlier version also had seg elements to mark the morphological segments, which also seem to have been discontinued. Those corresponded to the way the Hebrew text in the WLC module made use of a solidus marker between the word seg/ments.
Hope this helps.
The issue only concerns the SWORD engine output of Strong's markup from a Bible module.
Dictionary modules per se don't even come into the foreground for the issue.
They only become relevant if a front-end can also use the displayed Strong's code as a hyperlink to an entry in an installed dictionary module.
For this reported issue, we are not even anywhere close to that down-stream possibility.
In fact, there's no necessity for such a dictionary to even exist. The OSIS User Reference already admits that.
A comment from an immediate reply by Dr David Instone-Brewer.
Fortunately STEPBible Hebrew data does have the OpenScripture extended Strongs.
It is actually coded 4 ways: simple Strongs, extended Strongs, disambiguated Strongs and uniting Strongs
The latter links together Strong numbers that most users would expect to be considered as the same word - such as different spellings of the same person's name, or Aramaic & Hebrew versions of words - which are sometimes spelled completely differently but Strong gave them separate numbers!