Lemma and Root searching...

Hi, James. I'll see if I can shed a little light on this thread.

1) In the Peshitta, 'root' and 'lemma' are not interchangeable, and a root search and a lemma search will return different hits, whether you're in LDLS 3 or Logos 4. Root is a superset of a number of lemmas that are derived from the same set of consonants (and are etymologically related - there are some roots that are spelled the same but still represent different sets of words). So if you want to do a search that will find both verbs and the nouns derived from the same consonants, using the root field is the way to do. We don't (yet) have root data in any of our Hebrew Bibles, which is why trying a root search on אבל was futile.

2) When I open a Search panel and choose 'morph' in the upper right, with the settings: "Search All Passages in All Resources with Comprehensive Aramaic Lexicon Morphology (CAL) Aramaic Morphology for" and lemma:טבה in the search box, I get 76 hits in 73 verses. That is the same number of hits I get by selecting one of those hits, right clicking it, selecting the lemma for and searching the entire library (though a whole library search there sorts by 'articles' instead of 'verses').

However, looking at your original search, I am guessing that you are not looking at instances of the lemma טבה (noun: goodness) at all, but rather instances of the lemma טב (adjective: good) which sometimes has a surface form of טבה and a homograph number and part of speech tags attached to the lemma to distinguish it from some other words in the CAL database that are spelled the same way. In other words, the hits you were looking at were false positives for טב A 0.

That said, you did help uncover a real bug that I've just reported to development: apparently for the 2 databases we have which use part of speech as part of their homograph distinction (most of our databases just use lemma + a number, if needed, no part of speech), there are some problems with the Morph search function. If you just choose 'search entire library' or 'search this resource' you'll get the hits properly, but we have to fix the Morph search for the CAL Targums and WIVU.

3) The advice to click on the encircled 'i' to see what fields and data types are present in a resource is a good one for seeing if a lexicon has field tagged head-words, but it is not a consistent indicator of if a text such as a Bible contains lemma tags. Only certain interlinears show a lemma field on that screen. So the best way to see if an ancient text has lemma tags is to open it up and right click a word. In the case of the Old Syriac Gospels, they do not contain lemma (or for that matter root) tags at all.

Or if you want to know specifically which morphology a particular resource uses, open a Morph search, and select the specific resource you want to search: only the morphologies that are in that book will appear as options in the morphology picker drop-down.

4) Libronix DLS 3 was like a fishing with a purse net. Sure, you get every fish in the school, but you also catch all the dolphins and sharks that were eating the fish, along with a few sea turtles that happened to be passing by. Logos 4 is more like using dolphin- and shark-safe towing lines so that you only get the fish you're hunting for.

To take up your first example of אבל, in the HALOT lexicon the consonants אבל represent 8 different words. And since one of the meanings is 'brook', it is used in up to another 5 or 6 'lemmas' for proper place names.  Different lexicons and databases may subdivide the consonants into a very different number of entries. They may even spell words completely differently.

It's fair to say that the design of Logos 4 assumes that if you want to find all the instances of 'to mourn' you don't want to waste time sorting through instances of 'to dry', 'brook',  'canal', 'truly', 'but', or 'no/not' (the only way it is used in the Hebrew/Canaanite inscriptions we have so far), let alone an Aramaic personal name found only in Targum Pseudo-Jonathan or an 'entrance-way' from a Hatrean text.

5) Even where two different corpuses share the same word, they may spell it differently (especially with regard to vowels, but sometimes consonants as well) and may have different homograph numbers. So אבל 2 in the Andersen-Forbes text means can be used for negation, but this is אבל 5 in the Hebrew and Canaanite inscriptions, but in the Westminster text, which has vowels in its lemmas, and thus less need for homograph numbers, it is simply אֲבָל .

So in Logos 4, there are still lemma field tags on head words in lexicons and glossaries, and these function the same as in LDLS 3. But lemmas in analyzed texts have become data type references that combine the exact spelling of the word (vowel-sensitive) with the corpus that it came from and, where necessary, a number and/or a part of speech tag to distinguish it from other lemmas with the same spelling. This tight integration of data tremendously reduces the chance of false positives in your searching.

Part of the confusion of 'lemma:' is that in Logos 4 that operator is overloaded - which is developer-speak for saying it does different things in different contexts. In the context of a Basic search, it is looking for text that has a field tag of 'lemma', and so it hits head words in lexicons where the surface text itself is the 'lemma', and has been tagged as such. Whereas in the Morph search, lemma: is performing a data type search, which has a very different internal syntax. It's getting the corpus information from morphology you've chosen in the Morph search dialog and constructing a search not on surface forms, but on tags underneath the surface forms of things like Bibles.

6) This is why you don't want to combine 'lemma:' and 'syriac:' in the Morph search, because this textbox is creating a data type search, not a field search. We probably could add some smarts so that if someone typed syriac: into the Morph search we just threw that part of the data away. But really, there is no reason for you to be typing 'syriac:' anyway, even in a Basic search. Simply typing in the Syriac script is all that is needed to inform the application that you want Syriac results, so it doesn't surprise me that the developers didn't write special code for getting rid of input that is never actually needed. root:syriac:ܐܒܠ and root:ܐܒܠ will return the exact same hits. (We do not yet have root data type references, so even in the Morph search, root: is simply a field search. But since some databases, Peshitta included, do have root homographs with numbers to distinguish them, in time we'll probably end up supporting roots in the same way we support lemmas, especially once we have roots in a Hebrew text.)

7) The current Morph panel with its lemma-picker can actually save you a lot of time sorting through bad hits. You can see, for example, without even running a search that אבל is not used in the Hebrew and Canaanite Inscriptions, the Aramaic Inscriptions, or the Targums to mean the verb 'to mourn'. In some cases, if the spellings of words are similar, but not the same between languages or databases, examining the lemma picker can help you find the right word without wasting time on bad searches. For example, if you're studying ברא  but it doesn't show up in the lemma picker for the Targums, then delete the א scroll down and you'll find 'create' listed under ברי. So for your examples of wanting to search Hebrew, Aramaic, Ugaritic and Syriac all at once, well, excepting those very few words that are actually in common across all of those languages and don't also have an undue amount of false positives from homographs, the present method of constructing each search from the lemma picker in the Morph panel may be a more fruitful use of time.

8) All that said, we may want to think about a way to do a greedy purse net search like LDLS 3. We'll be able to evaluate if that is necessary better once bugs like the Targum one you helped find are fixed and our customers have a chance to get to know the new system and see if it isn't more efficient for most real-world search scenarios.

Sorry that the reply is verbose - you raised a lot of very different (though related) issues. I hope this clears up some of the confusion, and thanks for helping us find a bug!

Ah, right, I somehow picked the wrong word from your second example (blasted homophones), but the bug is the same. That will be fixed.

Yes, right now the only way to get lemmas from multiple different databases is to run separate searches. This is, of course, no different from the way morph searching has always been done. If you wanted to find every infinitive absolute, you'd find yourself constructing a separate search for each morphology you were interested in.

Some of these changes were necessary to get good search results from interlinears and reverse interlinears. In Libronix 3, when homograph numbers were not tied so closely to the lexical forms and the corpuses they came from, you could get some really absurd search hits in certain interlinears and particularly Semitic reverse interlinears.

There's really nothing preventing us from creating a method for searching the new lemma data type references that ignores the corpus identifier and any homograph distinguishing fields. (It'd be like a feature that finds every verse 17 in every Bible, regardless of what versemap, book, or chapter the verse is in. It's just C#, we can do almost whatever we want.) There was a time in Libronix DLS when we did this sort of thing for Targums and Dead Sea Scrolls in the Bible Word Study report, but besides "very carefully selected" examples, a great deal of gibberish was returned - particularly when converting to or from any database that didn't provide vowel points for the lemmas. But I'll put in a case for providing such a syntax for brave souls like yourself.

Regarding the Leiden Peshitta, we are simply waiting on an updated version of Psalms from Leiden. I'm told the edits were done on paper first and are being transcribed into the digital files, but have no time estimate from Leiden for the completion. I haven't worried too much about it because pointed Syriac won't display right in WPF until .NET 4 is released, which is still a few months out, I think.

Simply installing the new .NET RC won't fix the problems. Once .NET 4 is released, applications still need to be recompiled to use that version of .NET. We have an internal build of Shibboleth, for example, built with the .NET Beta 2 code, and the Syriac looks good (except for the abbreviation mark, which to my knowledge Microsoft hasn't fixed yet, but I haven't tested the latest drop). So we're probably looking at 4.0c or 4.0d, depending on how our development cycle coincides with the release of .NET 4 and how much work has to go into incorporating that into Logos 4. That's all outside my purview.

James W Bennett said:

But the big question is: is the major bug you cannot workaround in .NET 4 bigger than the bugs that .NET 4 fixes ...

...and whether the fixed bugs include a fix for the synaptics scrolling problem...