openscriptures/morphhb

Open Scriptures Hebrew Bible

morphhb's Issues

Research the part of speech of numerals

Currently we are parsing numerals as adjectives because they modify (i.e., count) nouns and secondarily can be substantival adjectives. However, this has not sit well with me as I have parsed them. It seemed an idiosyncratic way of parsing (though originally it may have been my suggestion), so I did a little research.

Among lexica (in order of publication):

• BDB parses numerals as nouns.
• HALOT/Holladay do not specify part of speech.
• Swanson, Dictionary of Biblical Languages: Hebrew, identifies them as "numerals."

The Westminster Hebrew Morphology parses them simply as numerals.

Among grammars (in order of publication):

• Gesenius, Kautzsch, Cowley, Hebrew Grammar, §97, §98, treats them under the broad category of nouns but in their own major sections at the end of the noun chapter. It is unclear how Gesenius would parse them, but he discusses them in a manner somewhat similar to adjectives, though his discussion deals with the historical development of the numeral's relationship to the noun it counts.
• Waltke and O'Connor, Introduction to Biblical Hebrew Syntax, §15, treats numerals separate from nouns or adjectives, though directly following adjectives.
• Van der Merwe et al., A Biblical Hebrew Reference Grammar, §37.1: "Numerals express numbers and are dealt with as a separate word type on that basis." They treat them under nouns, but they also treat adjectives and pronouns under nouns.
• Joüon, A Grammar of Biblical Hebrew (2006 ed.), §100.1a: "The nouns denoting number are in origin either substantives or adjectives, but all of them, to varying degrees, now possess a mixed character, partly substantival and partly adjectival."

In view of the ambiguity of numerals (as adjectival and substantival) and the general trend to treat them separately as numerals (as in van der Merwe et al.), I suggest we parse them separately as numerals rather than adjectives.

Versification issues in the Tanakh?

Do you have any background information for these observations:

-Nehemiah 7:68 text is missing, with versification off by one afterwards compared to translations
-Isaiah 64:1 text is missing, with similar consequences.
-Malachi 3:24 text is truncated, except in MapM, where the missing text is supplied but without diacritics

Front-ends with parallel passage display feature will present difficulties around these locations.

cf. Nehemiah 7 has 73 verses in the KJV versification. yet OSHB has only 72 verses.
It's conceivable that the displacement "error" might be earlier than verse 68.

b/994 should have lemma of just 994 and no morphological separator

Given that this is not "in me" but rather an exhortation particle.

Note: I will make this change in the parsing project which will eventually get exported to replace these files and so no real need to act upon this now. I just am writing up this issue to keep a record of the needed change.

Another missing entry in VerseMap.xml

In addition to verses mentioned in #54, there should be a split in Psalm 13:6 of WLC to map Psalm 13:5 and 13:6 of KJV.

Missing word break in Gen 38:24

כְּ/מִשְׁלֹ֣שׁ should be כְּ/מִ/שְׁלֹ֣שׁ

Hunt & Eaton

All the XML files contained the following line (since fixed in my Pull Request #49 )

        <publisher>Hunt &amp;amp; Eaton</publisher>

Clearly this must have been caused by a scripting error.

A script that replaced the ampersand character & by the XML entity & must not have guarded against doing so for existing entities.

Although I've drawn attention to this with my commit and PR, I thought a separate new issue was in order so that whoever owns the delinquent script is prompted to review and fix it.

Incorrect Strong Number in Two Verses

Hi,
I'm not sure if this repository is still being worked on, but I've found that in two places, II Chronicles 28:3 and I Kings 17:14 the Tetragrammaton has a completely wrong Strong Number listed in the attribute for that word.

Parsing inseparable prepositions with the definite article

Currently the schema parses inseparable prepositions with the article in a strange way that could cause problems. As an example, consider:
לַ/חֹ֣דֶשׁ
The lemma is l/2320. This term includes two segments, the preposition and the noun. It's parsing, however, would involve three: HR/Tp/Ncmsa.
Perhaps it would be better to parse the definite article as an attribute of the preposition, so: HRd/Ncmsa, the Rd representing "preposition with the definite article."

Need tag for apocopation

In Obadiah 12, the form תֵּ֤רֶא is apocopated, but not jussive. Currently there's no way to indicate this. I shoved an "a" on the end of the string.

It also looks like a Niphal, but is really a Qal. ראה is slightly irregular (cf. JM §79i). I think what would be helpful is some way of adding notes to tagging. I just spent a couple of minutes tracking this down i the grammars, and I'm likely to forget by the time I next look at it.

When we upgrade the database, hopefully we can then add a field for references and other notes.

Change the lemma 3212 to 1980

I recently corresponded with Jason DeRouchie of Bethlehem College and Seminary on this question. He wrote as follows:

Yes, scholars do not affirm a ילךְ verbal root any more. Instead, they recognize that הלךְ acts like an original I-ו verb in certain conjugations of the Qal. I write in my Hebrew grammar on p. 198:

The very common common root הלךְ, “walk,” acts like an original I-ו verb in the Qal yiqtol, wayyiqtol, and imperative. For example, the Qal yiqtol 3ms and 3fs forms are יֵלֵךְ and תֵּלֵךְ, and the Qal wayyiqtol 3mp and 3fp are וַיֵּלְכוּ and וַתֵּלַכְנָה. (A similar situation occurs with הלךְ in all conjugations of the Hiphil––recall the form הוֹלִיךְ.)

Neither of the scholarly standard lexicons (HALOT and DCH) treat ילךְ as a root, so I would discourage its use in BibleArc. Feel free to follow-up with questions. I can develop any of my comments further if it will serve you.

I can make this change in the parsing project so that the lemmas will be updated in the xml that is produced from that. However, I first thought it would be good to bring it up for discussion.

2 Chronicles 25:17 what is the unique value for a morph attribute in this verse for?

This verse contains <w lemma="l" morph="Rli/2ms">

For some peculiar reason, the value of this unique morph attribute gets output as part of the plain text when the CrossWire SWORD module OSHB is operated on by the diatheke utility.

This is how it came to my attention. This is the sole morph attribute in this book.
No other morph attribute value anywhere in the whole work got handled like this.

When I examined the raw IMP file for the module, I had observed that it contained this instead.

<w lemma="OSHBprefix:l" morph="Rli/2ms">

1. What does this strange morph value mean?
2. Is it even valid?
3. Why might it have behaved differently to every other morph value?

Research why Strongs 376 and 582 are both applied to the form הָאֲנָשִׁים

Currently just over 2/3 of the occurrences of הָאֲנָשִׁים are tagged with the Strongs:376. However, just under a third are tagged with Strongs:582. The former lemma is אִישׁ while the latter is אֱנוֹשׁ. HALOT lists both as having the plural form אֲנָשִׁים (pp. 44 and 71). Need to research this and see whether there is any basis for assigning individual entries to one or the other lemma.

Codes for other morphological features

Can we please add codes for marking other morphological features, such as nunation.

Downstream uses of the text and Unicode Normalization

According to the SBL Hebrew Font User Manual

Unicode normalisation can easily break Biblical Hebrew text. (page 9)

The implications of this need to be clearly understood by any agency making a downstream use of the text. The ordering of the diacritics in Biblical Hebrew is important for the proper rendering of several composite characters.

Some Bible software utilities generally normalize the source text to NFC during the module build.

If the detailed arguments in the aforesaid User Manual are sound, this conversion should be avoided.

Something about this signficant issue should be included in the project README file.

Aramaic determined case

Technically speaking the א sometimes found on the end of an Aramaic noun is not the definite article, but a suffix marker of the determined case.

In many places it's marked off separately like pronominal suffixes are. In these cases I've tagged it as Td as well as marking the noun itself as determined. But we might want to find a more accurate way of expressing it.

BibleTechnologies.net

The BibleTechnologies website went AWOL several weeks ago.

This was the home for the official OSIS 2.1.1 XML schema.

Does anyone know what happened or whom to contact?

btw. I've asked Steve DeRose if he could find out, but as yet he's not been successful.

What are the n attribute values for ?

The w elements in OSIS XML files contain an n attribute with various values.

The n attribute does not seem to be documented anywhere, or, if it is mentioned, it's not easy to find.

What do these values signify in this context?

Incorporate Fixes for 2.1

This is a meta issue to ensure that we include fixes that we find over the next few weeks in the 2.1 release.

Some of these are already provided in #57

Aramaic Determined State

Hi David,

As we are parsing the Aramaic portions we have run into a snag in the division of the Aramaic words that are in a determined state. In short, we would like to remove the / that divides the ending א on words that are in the determined state. See the more detailed description below:

Concerning the determined state: Wright (Comparative Grammar of Semitic Languages, p.115,152) considers the determined ending a variation of the demonstrative particle, but different than the "definite article" of Hebrew. Thus, according to Wright, both the determined state ending in Aramaic and the definite article in Hebrew are derived from the same fundamental phenomenon (a demonstrative particle), but they are not full linguistic equivalents in their respective languages. Rosenthal considers the determined ending as having a demonstrative function, almost exactly like the word "the" in English. He speculates that the terminal א (and/or ה) originally served as a direct object marker. He does not comment on the similarity/dissimilarity of the Aramaic determined state and Hebrew definite article.

This would change the parsing of a word in the determined state from ANcmsd/Td to ANcmsd.

Incorrect lemma in Ezek 24:2

לְ/ךָ֙ should have a lemma of l

(v.2.0) No explanation of morphological code for Isa.53.5

No explanation of morphological code

    <verse osisID="Isa.53.5">
      ...................
      <w lemma="2490 a" morph="HVOsmsa" id="23VQE">מְחֹלָ֣ל</w>

the code "HVOsmsa" is not explained in the Oshm.xml file

and more

morph HVqsmsa

    <verse osisID="Isa.53.4">
      .........................................
      <w lemma="5060" n="0.0.0" morph="HVqsmsa" id="23tLg">נָג֛וּעַ</w>

morph HC/Vqi1cp/Sp3ms

    <verse osisID="Isa.53.2">
      .........................................
      <w lemma="c/7200" morph="HC/Vqi1cp/Sp3ms" id="2391S">וְ/נִרְאֵ֥/הוּ</w>

when do you update the Oshm.xml file?

Change מאת to always have a lemma of m/854 (versus m/853)?

After noticing that you had changed a few instances of this sort in recent updates, I took a look at the situation in general and had a conversation with Joel via the parsing project slack:

Me: This form (with or without suffix) currently has a lemma of m/853 (direct object marker) 147 times in our data, and a lemma of m/854 (preposition) 26 times. Given your suggestion that we would parse this as two prepositions in all cases, should the lemma for all of them be m/854?

Joel: Yes, that is correct. Languages do weird things sometimes, but as far as I know, the direct object marker never attaches to the preposition מִן in Hebrew. All these cases should be labeled m/854 and NOT m/853.

Thoughts?

Is a modal imperfect with nunation a jussive?

Traditionally the jussive is identified by the apocopated form of the imperfect, which only exists in some binyan with certain roots. Sometimes nunation appears to occur with the jussive. It also occurs with the imperfect.

Should an imperfect form where apocopation is impossible, which is jussive in meaning, be considered morphologically jussive if there is nunation?

There are other views on the function of nunation: a recent theory by Robar is that it performs thematic marking, for example.

But I just wanted to flag up that this is something we need to make a decision about. Should we only tag apocopated forms as morphologically jussive, or might nunation also be considered an occasional morphological indicator of the jussive form?

Code for conditional particles

How do I mark the conditional particles אם (Hebrew) and הן (Aramaic)?

In Gen 1, I made a hash of the conditional there not knowing how to classify it with the current system. Now working through Daniel 2, I discovered that I can just apply a code, even if it's not technically acceptable.

So... I've started marking הן as Tc for "conditional particle". Hope that's ok.

preposition + pronominal suffix combos incorrectly given lemma of 1992

The following outlier form-lemma combos should not have the /1992 in their lemmas since these are normally considered pronominal suffixes. (262 occurrences)

וְ/כָ/הֵם c/k/1992
וְ/לָ/הֶם c/l/1992
וּ/מֵ/הֶם c/m/1992
כָ/הֵם k/1992
כָּ/הֵם k/1992
לָ/הֶם l/1992
לָ/הֶן l/1992
מֵ/הֶם m/1992

I can correct these in the parsing data and so they will reflect the correct lemmas on export.

How are Conflicts Identified

Is there currently a way to see words whose parsing conflicts between users? I have been parsing and labelled a couple things differently from whoever came before me. Who is going to find that conflict? Should we be diverting parsers to those passages especially?

Thanks for the good work on this project. It is currently very easy to contribute, and took me all of 15 or 20 minutes to get rolling.

Accent Catalog

Hi,
I'm trying to parse the ETCBC data to build accentuation information. I have found your accent catalog (https://github.com/openscriptures/morphhb/blob/master/structure/OshbVerse/Script/AccentCatalog.js) particularly helpful for that (maybe I will submit a couple of other issues once I've used it a bit more). One thing that has just struck me as I've been testing my own code is that I searched for "Merkha with Atnach" (\u05A5\u0591), a poetic accent, and found only one instance but it was in Jer 46:4. Am I correct in understanding this to be a mistaken categorisation?
Thanks

Plene/defective marker

We probably also need a code to mark when something is written plene/defectively.

E.g. for Hiphil forms which are otherwise hard to identify because they're written defectively.

FYI. Custom Unicode normalization of Biblical Hebrew using BabelPad

BabelPad

The BabelPad Unicode text editor for the Windows platform includes an Option for the custom Normalization of Biblical Hebrew that was based on the combining group scheme referred to in the SBL Hebrew font User Manual.

BabelPad developer Andrew West added this option at my suggestion in July/August 2014.

"The vowels and accents are ordered by the specified non-standard combining groups in the table. This ordering is a minor expansion of the custom mark ordering proposed by John Hudson of Tiro Typeworks in his SBL Hebrew Font User Manual that is part of the SBL Hebrew font release. Marks with lower values appear closer to the preceding consonant. Marks having the same combining class appear in the order in which they appear in the WLC text. "

NB. When the custom normalization option was added to BabelBad, the "minor expansion" was not known to either of us.

BabelPad uses the custom combining classes given in Appendix B of John Hudson's user manual, from which it is possible to work out the sole minor difference between BabelPad's implementation and the definitions in the Coding.xml page at tanach.us.

The sole minor difference

The phrase "minor expansion" was significant in that it only affects the relative order of the two marks LOWER DOT and UPPER DOT that are known also as puncta extraordinaria.

I recommend BabelPad unreservedly. I wouldn't be without it.

Best regards,

David Haslam
Volunteer for CrossWire Bible Society

Special markup for large letters, small letters and raised letters?

In a few places in the Tanakh, the Hebrew letter size or vertical placement differs from the rest of the text.

See https://www.win.tue.nl/~aeb/natlang/hebrew/hebrew_bible.html

Should there be some special markup for such large letters, small letters and raised (aka suspended) letters?

Even if most Bible software currently has no means to render these differently, it would still be sensible to provide the means in the XML to identify these unusual letters in order to support these traditional features.

cf. MapM uses the seg element with these user eXtension type attribute values:

• x-big
• x-small
• x-suspended

See counted list of OSIS eXtensions found in MAPM.xml

MAPM.xox.cdl.txt

Describe IDs that Have been Added to Text

This is a reminder for @AndyHubert to write up a short description of the IDs that we can put into the README.

Distinguishing morphology and grammar

Just parsed שגיא, which is I believe a masculine form, though grammatically it modifies a feminine noun.

Rosenthal states "Adjective are place after the nouns to which they belong and to which they conform grammatically as closely as possible." (§41).

Is there any way to express "X in form but Y in meaning"?

Flag for question over lemma decision

The form נָכְר֔/וֹ in Obadiah 12 is tagged as the adjective 5237. I'm wondering if it should be tagged as the noun 5235. Could we extend the parser to also allow functionality to raise a flag questioning the lemma?

missing entries in VerseMap.xml

In the books of 1Kings, there should be verse breaks in WLC in 18:34, 20:3 and 22:21 to map KJV versification. 22:44 of WLC should be mapped to part "b" of 22:43 in KJV.

I did not find them in VerseMap.xml in "WLC" folder.

A screenshot for an example attached (English text = KJV; Hebrew Interlinear built from latest OSHB).

A standard linguistic reference

Dear colleagues,

The traction that the project currently has is fantastic. However, as we continue parsing, consistency and quality is important.

Can I suggest that we consider adopting a standard linguistic reference for biblical hebrew that we use as a reference?

It is quick and easy to default to such a reference volume, and this provides consistency to the project. The project may choose to depart from the reference at points. But at least, then, the reference point provides a consistent place from which we are departing.

IMHO, the most up to date linguistic tools at present are:

• grammar: the three volume Encyclopedia of Hebrew Language and Linguistics
• lexicon: Gesenius' Hebräisches und Aramäisches Handwörterbuch über das Alte Testament: Gesamtausgabe

Both were released in 2013.

Geoffrey Khan, who edited the EHLL, is currently heading up a project to release a New Gesenius' grammar, which I think should probably take over from the EHLL as the grammar reference once it's published.

If the team would like to stick to English, then for lexical reference, perhaps we might make use of a triad of the Semantics of Ancient Hebrew Database, the Dictionary of Classical Hebrew, and HALOT.

If we like the idea, we could distill some key principles for parsing that extend the page on morphology codes.

What do people think.

Attach JSON and USFM Files to Release

Especially for the 2.1 release coming up it would be good if we could attach downloadable assets for JSON and USFM representations of the OSIS files.

Parashah?

Does the OSIS source text make any special provision to encode the parashah found in some MSS?

There are 1168 instances of the Hebrew letter PE terminating a verse in the OSHB.
Those mean "the end of a parashah".
You could interpret it to mean "end of a paragraph", roughly speaking.

Currently the XML makes no use of the OSIS element <p>... </p>

Might there be some real advantage in doing so?

And related to this question, should the SWORD module for OSHB include

Feature=NoParagraphs

which for some front-ends (e.g. Xiphos) at least, has the effect to make the default setting as Verse Per Line after the module is first installed.

cf. The letter PE at the end of a parashah is a bit like the Pilcrow symbol at the start of a paragraph in translations such as the King James Bible.

It would be interesting to see how well these correlate to a PE at the end of the previous verse.

Swapped lemmas in 2Sam 10:6

אלף should be 505
איש should be 376

Using the solidus to separate morpheme segments is against OSIS philosophy

The general philosophy of OSIS is to use XML elements for all the semantic markup.

Using the solidus within the text to separate morpheme segments within Hebrew words goes against this OSIS philosophy. One friend has described this as "bad, bad, very bad".

cf. The XML files for the CrossWire WLC module are more conformant with this principle where they used the XML seg element for this purpose. The original data was obtained from the website tanach.us but further preprocessing was done before building the latest version of module, which differs from it's earliest version in this respect.

• Edited: @DavidHaslam

e.g. Taken from the mod2imp output of the CrossWire WLC module, they are generally like this:

$$$Genesis 1:1
<w><seg type="x-morph">בְּ</seg><seg type="x-morph">רֵאשִׁ֖ית</seg> </w>
<w><seg type="x-morph">בָּרָ֣א</seg> </w>
<w><seg type="x-morph">אֱלֹהִ֑ים</seg> </w>
<w><seg type="x-morph">אֵ֥ת</seg> </w>
<w><seg type="x-morph">הַ</seg><seg type="x-morph">שָּׁמַ֖יִם</seg> </w>
<w><seg type="x-morph">וְ</seg><seg type="x-morph">אֵ֥ת</seg> </w>
<w><seg type="x-morph">הָ</seg><seg type="x-morph">אָֽרֶץ</seg> </w>
<w type="x-sofpasuq">׃ </w>

NB. In this extract, the output was also converted to Word Per Line format afterwards.

Aside: That is not to say that the WLC module is perfect.
Irrespective of any text critical issues, at least these mistakes were made when it was first built.

1. The Hebrew text should not have been normalized to NFC.
2. There should not be a space either before or after each MAQAF.
3. The space between Hebrew words should be outside the w elements.

These are not your responsibility. I mention them merely in passing.

Those defects were rectified in the WLC module after I created this issue in 2017.

• Edited: @DavidHaslam

Where are Data Stored?

I'm happy to be parsing and adding information into this Open Scriptures project, but where are the data going? Where can I view the data as compiled so far?

Questions regarding the words list file Words.csv

I just examined the file Words.csv which has 64587 lines.

This CSV file has two columns; the first appears to be the the frequency of occurrence, the second the actual Hebrew word (complete with diacritics). The file is sorted on column one in ascending order.

What's puzzling are the last 136 lines of the file, where the first column contains a single letter rather than a four digit integer (packed with leading zeros where required).

A further question is prompted by a brief examination of the Hebrew words.

None of the words contains a maqaf which means that there are no compound words (usually proper names) in the list. Here's a character frequency analysis of Words.csv obtained using BabelPad.

Words.csv.character.frequency.txt

When performing the statistical analysis of words found in any particular text, it's preferable to classify each compound word as an item to be counted.

Bad lemma in ezek 45:25

בשביעי should be b/7637

Parsing vav conjunctions

We currently parse vav consecutives using "HCv," but we use "w" for the sequential imperfect (i.e., wayyiqtol). For consistency's sake and for ease of parsing, I suggest we parse vav consecutives as "HCw."

Pentateuchal pronouns

How are we tagging those pronouns in the Pentateuch that are masculine consonantally but pointed as feminine?

They're not a normal Ketiv/Qere. In my view they probably represent some small collapse of the gender system, perhaps due to contact with another language. So, if I were in an idiosyncratic mood I'd tag them as "common" or "both" gender.

But, since I'm not in an idiosyncratic mood, I'll tag them by grammatical gender.

Textual issue in Song 6:12

There is an ambiguity in the text of Song of Songs 6:12, regarding the final two words, עמּי־נדיב. In the OSHB text these are two lemmas, although perhaps there should be three lemmas instead. The LXX and the KJV translate both these words as a single proper name, "Aminadab" and "Amminadib", respectively. However, the NRSV and NIV both translate these as common words: either [H5971a+1cs suffix and H5081] or [H5971b+1cs suffix and H5081]. I prefer the NIV reading, i.e. H5971a+1cs suffix and H5081, yielding either "royals chariots of my people" or perhaps "chariots of my royal people". If we take either of the more modern readings, the pronominal suffix will need to be separated from the noun and marked with its own lemma.

Aramaic participles inflect by person number

I just had to insert a number for Daniel 2:8 word 11 into the code. It's a 2nd person participle. Currently that's a malformed code, but Aramaic participles inflect according to person (either 2 or 3).

WLC version 4.20

I recently discovered this project. Since the activity level has decreased, I was wondering if anyone is already working on updating the WLC with the changes released in version 4.20?

Song format in prose books (e.g. The list of defeated kings in Joshua 12)?

MAPM uses OSIS table elements to markup the passages containing song format in prose books.

e.g. The list of defeated kings in Joshua 12:9-31

This topic is described in Column F: The Verse in Song Format (with table code)

Currently, this markup is not used in the WLC text used to make the OSMHB module.
Is there any reason to not use this eventually?

Out of date SWORD module OSHB dated 2013-10-11

As I see that there have been a signifcant number of commits to the repo since 2013-10-11, it would be certainly useful to SWORD users for the OSHB module to be updated.

Or maybe OSHB should be replaced by one with a slightly different module name, being careful to use the Obsoletes key in the .conf file if that route is taken.

If you can find time to do this, it would be much appreciated.

In order to validate to the OSIS 2.1.1 schema, the contributor element must be moved

Attempting to validate the XML files to a local copy of osisCore.2.1.1.xsd gave the following:

ERROR: Element 'contributor': This element is not expected. Expected is one of ( rights, scope, castList, teiHeader, refSystem ).

This happens with some or all of the XML files unless within each work element, the contributor element is moved to immediately after the title element.

i.e. The contributor element is not expected after the creator element.

This must be due to an error in the .xsd file whereby it does not match the examples given in section 7.1 on page 23 in the OSIS 2.1 User Manual.