Search Panel - Analysis View Changes

I have made some changes to the way results are displayed in the analysis view of the Search panel. Previously, if you had a result which contained several Roots, you would get a result row for each Root in search analysis. This produced numerous result rows for some entries which were not unique. To address this we are now collapsing the following fields into a delimited list for each result:

Highlight

Lemma

Louw-Nida

Root

Strongs

The goal is to make the results in search analysis more useful and easier to read.

Example:

Search for <Lemma = lbs/he/צִיּוֹן> in the Lexham Hebrew Bible

Each of the results have three different roots.

Previously, there would have been three entries for each result. One entry for each unique Root for each result.

Now, the Roots have been collapsed into a comma delimited list and a single entry is displayed for each result.

Search for "birth" in the New Testament of the ESV

Look at the entries for Matthew 19:12. There are several entries here which is caused by different Forms for one result. Since Forms are not being collapsed into a delimited list, they still produce multiple results, as expected.

However, there are now fewer entries for each result because the Lemma, Louw-Nida, Roots and Strong are collapsed into comma delimited lists.

I would appreciate any comments or feedback on this change.

Thanks!

Jared

Find more posts tagged with

Comments

Dave Hooton

However, there are now fewer entries for each result because the Lemma, Louw-Nida, Roots and Strong are collapsed into comma delimited lists.

That is confusing. I can't tell which lemma, LN, Root, or Strong's number applies to the Form. AFAIK there's no need for delimiting in this example. Further, it's not clear why there are 2 entries for ἐγεννήθησαν which is truncated without ellipsis ... to indicate that. The display in 5.0b is much cleaner.

Graham Criddle

Hi Jared,

I agree with Dave

I don't see this change as being helpful at all

Graham

Mark Barnes

I would appreciate any comments or feedback on this change.

I'm delighted at this change, but don't feel it's 100% right yet. I'm delighted because having multiple rows is really confusing - and with all the extra tagging you've added in Logos 5, you could end up with ten or more rows for one result (multiple forms, multiple roots, multiple people tagging, etc.).

So collapsing them together is really important. That said, the screenshots you've posted are still confusing because the forms don't match the lemmas. This can't be helpful. The row has to be consistent.

Let's imagine a word that has two forms, and each form has two roots. Currently that displays four rows:

Form1 Root1
Form1 Root2
Form2 Root1
Form2 Root2

What should display? That must depend on what the search matches. So if the verse matches the search criteria on Form 1, I would expect the search results to say:

Form1 Root1, Root2

But if the verse matches the search criteria on Root2, I would expect the results to say:

Form1, Form2 Root 2

It's really confusing when you search for a particular root or lemma, and end up with other roots or lemmas appearing in analysis, just because those roots/lemmas share a form with the root you're searching for. That really should be excluded.

Jared Wood

Thank you for all of your suggestions. I will evaluate and work on improvements for the upcoming beta releases.

Mike Binks

Thank you for seeking opinions - I hope the responses have been helpful.

It is really good to find developers both punting new solutions and taking feedback into consideration.

It bodes well for the time this is incorporated into a stable release.

Mark Barnes

Thank you for all of your suggestions. I will evaluate and work on improvements for the upcoming beta releases.

If you want to see the problem, do your test searching in reverse interlinears. For example, if you search for <Root = lbs/el/καλεω> in the ESV you get the following (grouped by root):

None of those roots should show up as I didn't search for them.

Using the same search, take the result in Acts 23:29 where the phrase ἔχοντα ἔγκλημα is translated by the one English word 'charged'. Despite doing a search on the root καλεω (which is obviously matched by ἔγκλημα), data for ἔχοντα comes into the analysis, because both are translated by the one English word.

I know that you shouldn't really do Root/Morph searches on an reverse-interlinear for precisely these reasons, but regardless of what you're supposed to do, people will inevitably do this, and as Logos is constantly marketed as a way for people without Greek to perform searches like this, Logos needs to do more to support it.

Dave Hooton

None of those roots should show up as I didn't search for them.

Analysis will consider the content of all cells where the match occurred, so it does not matter if the search was for one root and it returns a cell with multiple different roots e.g. Eph 1.18 in ESV. What matters is how the 15 results are condensed and the key is the 5 English words that cause the repetition of 5 groups of 3.

Dave Hooton

Further, it's not clear why there are 2 entries for ἐγεννήθησαν which is truncated without ellipsis ...

Still concerned about the multiple entries. Same thing happens in Acts 14.8

Mark Barnes

I just did a simple analysis search for an English word in version 5.0, and was annoyed that the count was wrong (it had doubled the count of the Greek article was used). So I repeated the search in 5.1, and was glad to see that this time the count was correct. So thanks for the improvement!

Mark Barnes

I was working on the Lexham Hebrew Bible today, and am concerned about the way Qere readings are exported to Excel from Analysis View. When you export to Excel, the row height is much larger than it should be.

The search below will return one result from a lemma that has a Qere reading, so you can see the problem without wading through lots of results:

(By the way, having the Qere reading showing the lemma column and the export is a pain, but I guess from your earlier comments you're not going to change that.)

Brisa Davis

When you export to Excel, the row height is much larger than it should be.

I'm having some trouble reproducing this issue. Would you mind including screen shots so I have a better idea of the issue you are seeing?