Simple Hebrew search help

[Deadlinguist]

Hi,

 

I just purchased and downloaded Accordance with great anticipation. Eager to try out the intuitive and powerful Hebrew search engine, I thought I'd try to find the stereotypical example of YHWH + (root)ahab. Two hours, multiple tutorial videos, and several articles (including Holmstedt's) later, and I still can't figure it out. My best attempt is attached; why won't it come up with anything? I'm sure it's a simple problem. Thanks for your help!

 

DL

[Helen Brown]

I don't see an attachment, and what do you mean by +? If you mean both in the same verse you simply link them with the command in the Search menu, thus:

יהוה אהב=

 

I hope this helps.

[Deadlinguist]

I don't see an attachment, and what do you mean by +? If you mean both in the same verse you simply link them with the <AND> command in the Search menu, thus:

יהוה <AND> אהב=

 

I hope this helps.

 

 

Hi Helen,

 

Sorry, I don't know why the attachment didn't work the first time. I don't mean both in the same verse: I want to find YHWH as the subject of the root ahab.

[Helen Brown]

In this screenshot the coinstruct looks OK, but you haven't clicked the search button in either of the tabs in order to run the search.

 

Remember that the syntax is still partial, covers only some books.

[Deadlinguist]

In this screenshot the coinstruct looks OK, but you haven't clicked the search button in either of the tabs in order to run the search.

 

Remember that the syntax is still partial, covers only some books.

 

I did press the search button and was told that no instances were found in the Hebrew Bible, which is incorrect.

[Anon]

I did press the search button and was told that no instances were found in the Hebrew Bible, which is incorrect.

 

Currently the database contains Genesis, Joshua, Ruth, Psalms, and an various prophetic books. Within this part of the Hebrew Bible, there isn't an occurrence that satisfies your search criteria. You're correct: there are instances where the tetragrammaton is the subject of אהב.

 

The database will eventually include the entire Hebrew Bible as well as Dead Sea Scrolls and Northwest Inscriptions.

[Helen Brown]

If you do the search with עשׂה instead of אהב and you check the search in both directions, you will get plenty of hits.

[David Knoll]

I did press the search button and was told that no instances were found in the Hebrew Bible, which is incorrect.

Ps 87:2 seems prima facie wrongly tagged. You'll get 11:7 by ticking the search both directions checkbox. As for 37:28 and 146:8 they have a null predicate because the generative philosophy of Holmstedt prevents him from recognizing nominal sentences. He didn't give examples in the forum (as far as I know) as to how to search for "null copula" sentences with participles as the complements of the "missing copula". I don't know how all these can be caught with a single search. I tried searching for complements that include the root אהב but no search returns both 37:28 and 146:8. I think Prof. Holmstedt will have to clarify this for us.

[Deadlinguist]

Ps 87:2 seems prima facie wrongly tagged. You'll get 11:7 by ticking the search both directions checkbox. As for 37:28 and 146:8 they have a null predicate because the generative philosophy of Holmstedt prevents him from recognizing nominal sentences. He didn't give examples in the forum (as far as I know) as to how to search for "null copula" sentences with participles as the complement of the "missing copula". I don't know how all these can be caught with a single search. I tried searching for complements that include the root אהב but no search returns both 37:28 and 146:8. I think Prof. Holmstedt will have to clarify this for us.

 

Thanks all. Thought I was going crazy. I suppose this illustrates the basic problem with all syntactical searches - the search is limited to some degree by the interpretation of the tagger.

 

DL

[David Knoll]

Thanks all. Thought I was going crazy. I suppose this illustrates the basic problem with all syntactical searches - the search is limited to some degree by the interpretation of the tagger.

 

DL

I enclose how I thought the participle complement search should look like. It returns no results. Perhaps Prof. Homstedt can explain what I am doing wrong.

[Robert Holmstedt]

This thread popped up while I was travelling. Let's see if I can sort out the issues as simply as possible:

 

1) the idea of a null copula is not generative. It is used in typological linguistics, an approach that is largely non-generative. The sooner users stop categorizing the database as "generative," the sooner it will be understand accurately. The issue of "nominal sentences" (a.k.a. verbless clauses) and the problems of terminology and classification in Semitic languages is addressed specifically in the volume of papers edited by Cynthia Miller (see below in bibliography). In other words, there is no consensus among Hebrew linguists on the nature of this animal, contrary to the implication of the comment made in the 8th post above.

 

2) the status of the "participle" in Hebrew is also a long-standing linguistic problem. It has been recently discussed in the articles by Frank Andersen and Dean Forbes and John Cook. In this project, we followed the analysis promoted by John Cook, which we found compelling typologically. Simply, like adjectives, the participle is taken as the complement to a copula, whether null or explicit (i.e., the cases where the participle follows a finite form of היה).

 

3) There are no cases of Yhwh as the Subject of a finite verb = אהב in the texts so far released. There is hit for me is in Prov 3:12, but that is a text that has not been released.

 

4) in the participle search #1 provided below, 3 of the 4 hits are correct; the hit in 145:20 is a mishit due to the continuing perfection of the searching algorithms (I think that's the correct word, but when it comes to the programming world, I'm quite lost). The point is, the actual tagging of 145:20 is correct and eventually it won't be a hit in this search.

 

5) in the tighter (and thus better) participle search #2, all three hits are correct and none are missing.

 

[Note that in both participle searches, the "chapter" option is chosen; currently (at least in 9.4beta) there appears to be a bug whereby the results may be slightly different between chapter and book searches.]

 

6) 11:7 in your search is a mishits due to the complexities of multiple clause juxtaposition that occurs greatly in poetry. The tagging is correct for the verses (look at the trees to see how it is tagged). The searching accuracy is being improved on this specific issue at this time. In fact, this looks like it's been taken care of in 9.4 beta! If so, it's a huge programming coup for Dr. Brown, since it has proven to be a very, very complex issue.

 

7) It is not clear why the tagging of Ps 87.2 is understood to be wrongly tagged. It is correct according to our tagging principles.

 

8) Finally, on the comment by deadlinguist regarding the limitation of syntactic searches—it is true that such databases are necessarily built upon *analysis*, which by nature is subjective. But such is the case with any area of grammar. There are enough ambiguities in Hebrew morphology (e.g., forms that can be parsed as participles or perfect/qatal verbs, forms that are either jussives or non-jussive imperfect/yiqtols) to make such a pronouncement about any analytical database (i.e., a database that does not simply present unprocessed data-- but even then, the order of presentation is often interpretive) both obvious and uncontroversial. We have never promoted the syntax database as an "objective" product—and even if the database were of our native language, English, we could not promote it as such, since linguists working on their native language often disagree with each other. We encourage all users to work through the syntax of a passage themselves. All such databases (morphological, syntactic, etc.) are simply tools that the scholar uses but should not depend blindly upon. I hope this clarifies our stance regarding the use of our database (or any other).

 

Thank you all for working with the database and asking the questions. As I have stated in the posts on the draft tagging guide, without user interaction, it is difficult to write up searches that represent something that users would actually look for.

 

• Andersen, Francis I., and A. Dean Forbes. 2007. The Participle in Biblical Hebrew and the Overlap of Grammar and Lexicon. Pp. 165-83 in Milk and Honey: Essays on Ancient Israel and the Bible in Appreciation of the Judaic Studies Program at the University of California, San Diego, ed. S. Malena and D. Miano. Winona Lake, IN: Eisenbrauns.

• Cook, John A. 2008. The Hebrew Participle and Stative in Typological Perspective. Journal of Northwest Semitic Languages 34 (1):1-19.

• Miller, Cynthia L., ed. 1999. The Verbless Clause in Biblical Hebrew: Linguistic Approaches. LSAWS 1. Winona Lake, IN: Eisenbrauns.

 

[David Knoll]

 

 

1) the idea of a null copula is not generative. It is used in typological linguistics, an approach that is largely non-generative. The sooner users stop categorizing the database as "generative," the sooner it will be understand accurately. The issue of "nominal sentences" (a.k.a. verbless clauses) and the problems of terminology and classification in Semitic languages is addressed specifically in the volume of papers edited by Cynthia Miller (see below in bibliography). In other words, there is no consensus among Hebrew linguists on the nature of this animal, contrary to the implication of the comment made in the 8th post above.

 

 

Well for a Semite הבית גדול is not a result of a transformation or movement or whatever of הבית הוא גדול with all due respect. Be that theory Generative Transformational Typological or other. That does not mar your achievement. I have been using AFAT SESB and your database. Yours is definitely the most useful and I don't care what linguistic theory lies behind it. I run searches and expect results. Simple as.

 

 

 

7) It is not clear why the tagging of Ps 87.2 is understood to be wrongly tagged. It is correct according to our tagging principles.

 

 

This isn't clear to me either. I must have been wrong. It looks perfect now. Pardon

 

Still if I run this search I get only two verses and one of them is a mishit. (see attached screenshot).

 

Am I right in assuming that a "null copula" sentence would always have a predicate PHRASE?

Why don't I get any hits if I put a null predicate column before the Lex אהב column?

(See attached)

As for Miller I guess I prefer the essays in this volume which you dislike.

[Robert Holmstedt]

1. Nowhere do we explain null copula clauses, or any other clauses, as the result of transformations. I have no idea where this is coming from. Though my own theoretical stance is within generative grammar, it is precisely the type of concept we chose not to build the database upon, as I described in the "background" paper from last November. I also never indicated which articles in the Miller volume I consider better arguments; I simply used the breadth in the volume as an example of the lack of consensus in the field. Both comments feel like a bit of eisegesis w.r.t. to the database and my positions.

 

But I am certainly happy that you're using the database.

 

2. The mishit in your search (Ps 11.7) is also due to the explanation I gave in #6 in my other post and no longer pops up in 9.4 beta.

 

3. It is not necessary to use the PHRASE for a simple null copula clause (see attachment #1). But without the phrase, you cannot further disambiguate what type of complement (= "predicate nominative") occurs. To specify the type of complement, the PHRASE must be used (see attachment #2).

 

 

4. Are you using the 9.4 beta? I indicated in my last post that some issues have been fixed (although there are more left). Whether you use the search I showed in my last post or one in which the null copula column is added (see below), the results should be the same. Admittedly, the search below is missing 87.2, which means I have another bug to report.

 

 

 

Again, thank you for using and testing the database.

[David Knoll]

1. Nowhere do we explain null copula clauses, or any other clauses, as the result of transformations. I have no idea where this is coming from. Though my own theoretical stance is within generative grammar, it is precisely the type of concept we chose not to build the database upon, as I described in the "background" paper from last November.

I must have misdunderstood your post:

Example (1) illustrates how want and to are often contracted in colloquial English when they are immediately adjacent. Example (2) shows that when a constituent intervenes between want and to, the two words cannot be contracted. Finally, example (3) demonstrates that when the noun phrase this novel is moved from its position after want, the result is the adjacency of want and to. And yet, because the movement leaves a

[Robert Holmstedt]

Ahh, the cut-and-paste culprit (from other work of mine—it just illustrates the problem of being in a hurry.)

 

You need only replace "move" with "positioned". Non-movement functionalists also recognize that in "This novel I want to be considered for a prize", the phrase "this novel" is not in its normal position.

 

So, my use of "move" was infelicitous in the context of the searching guide and will be changed precisely (indeed, already is in that post) so that a generative framework (or agenda) is not read into the project. Indeed, if a fellow generativist came along and considered the database, he/she would likely note the number of deep non-generative choices we intentionally made in order to keep the database "data primary" while also "theory wise".

[Deadlinguist]

Ahh, the cut-and-paste culprit (from other work of mine

[David Knoll]

Ahh, the cut-and-paste culprit (from other work of mine—it just illustrates the problem of being in a hurry.)

 

You need only replace "move" with "positioned". Non-movement functionalists also recognize that in "This novel I want to be considered for a prize", the phrase "this novel" is not in its normal position.

 

So, my use of "move" was infelicitous in the context of the searching guide and will be changed precisely (indeed, already is in that post) so that a generative framework (or agenda) is not read into the project. Indeed, if a fellow generativist came along and considered the database, he/she would likely note the number of deep non-generative choices we intentionally made in order to keep the database "data primary" while also "theory wise".

The basic search works now with the beta. I have two problems though. One is that if I add the null predicate column I lose 87:2. The other is that if I reverse the order of the columns inside the predicate phrase i.e. complement first and null predicate second, I get no results even though search both directions is turned on. Is this to be expected? If so could you explain why, so that I can construct future searches more efficiently?

[Robert Holmstedt]

The basic search works now with the beta. I have two problems though. One is that if I add the null predicate column I lose 87:2.

 

Yes, that is what I indicate a few comments ago in my #4.

 

 

The other is that if I reverse the order of the columns inside the predicate phrase i.e. complement first and null predicate second, I get no results even though search both directions is turned on. Is this to be expected? If so could you explain why, so that I can construct future searches more efficiently?

 

At this time, the "search both directions" appears to apply to the primary constituents within the uppermost clause/phrase. So, when doing a clause search, "search both directions" applies to, e.g., the Subject and Predicate, but not to the constituents within the Predicate Phrase. But if you were doing a Predicate Phrase search (i.e., the Pred Phrase was the highest level), then the "both directions" would apply to the constituents within.

 

Although I am not positive, I imagine that this is a necessary (or nearly so) constraint. Think about what a multi-level nested search would be like if "both directions" applied at each level -- any notion of linearity is thrown out the window. Since I think in terms of such levels, I can actually imagine cases where this might be useful, but on a practical level it is unclear whether the majority of users would appreciate this and, more important, the programming complexity to do this is no doubt immense. In contrast, the effort required to manually re-order the constituents is minimal.

 

Thus, I recommend for just about every kind of serious search that users use BOTH the "search both directions" (unless a specific direction is desired, of course) AND manually reorder constituents in order to check results. It is what I do with the database, anyway.

[David Knoll]

 

Although I am not positive, I imagine that this is a necessary (or nearly so) constraint. Think about what a multi-level nested search would be like if "both directions" applied at each level -- any notion of linearity is thrown out the window. Since I think in terms of such levels, I can actually imagine cases where this might be useful, but on a practical level it is unclear whether the majority of users would appreciate this and, more important, the programming complexity to do this is no doubt immense. In contrast, the effort required to manually re-order the constituents is minimal.

 

Thus, I recommend for just about every kind of serious search that users use BOTH the "search both directions" (unless a specific direction is desired, of course) AND manually reorder constituents in order to check results. It is what I do with the database, anyway.

 

It can be very cumbersome to reverse every constituent in a complex search and it is also not intuitive for the user. On the long run I think you may need to reconsider that and I am not sure programming would be that complex (In fact from what I have seen there is no programming that is too complex for Accordance ). It can also be a source for mistakes if the user thinks he already reversed that part of the construct or if he merely forgets to reverse. Since this is a new product I think you should aim at keeping the learning curve to a minimum.

[Robert Holmstedt]

It can be very cumbersome to reverse every constituent in a complex search and it is also not intuitive for the user. On the long run I think you may need to reconsider that and I am not sure programming would be that complex (In fact from what I have seen there is no programming that is too complex for Accordance ). It can also be a source for mistakes if the user thinks he already reversed that part of the construct or if he merely forgets to reverse. Since this is a new product I think you should aim at keeping the learning curve to a minimum.

 

We appreciate the input. But it is not always clear what is intuitive for a given user or a group of users, or if there even exists a very large number of "intuitive" choices that apply broadly enough to merit the energy and time.

 

As for learning curve -- yes, I have heard this before (many times). But we must also recognize that there is a significant learning curve with regard to syntax in general (on any language) and most certainly on the syntax of Hebrew. I see this again and again with first, second, and third year students (undergraduate and graduate), or even colleagues to whom I explain the database.

 

The fact appears to be that however hard we try, there will likely be a learning curve for the analysis of syntax

[David Knoll]

A case in point is the excellent database by Frank Andersen and Dean Forbes. I know that Dean Forbes uses it easily because he designed the "guts" (just like I can use our database easily, even in the text files). But the AFAT database remains, even for me, very difficult to use and achieve accuracy (and I had the privilege of using it before it went public). The result: when I use it, I run numerous searches, all slightly different, and then read through all the examples one-by-one.

 

 

My verdict wouldn't be that lenient.

In their defence: I am not sure AF are to blame. It could be the integration in the software.

[Robert Holmstedt]

My verdict wouldn't be that lenient.

In their defence: I am not sure AF are to blame. It could be the integration in the software.

 

My was not either until I came to know both Frank and Dean personally and gained an informed understanding of the guts of the AFAT database.

And yes, a good deal of the usability issue has to do with the software running their database.

 

Users who are truly interested in syntax should urge Accordance to add the Andersen-Forbes database alongside ours. Both databases running on Accordance would provide a complementary view of Hebrew syntax where they overlap (on the Hebrew Bible).