Search Panel - Analysis View Changes

Page 1 of 2 (21 items) 1 2 Next >
This post has 20 Replies | 3 Followers

Posts 4
LogosEmployee
Jared Wood | Forum Activity | Posted: Mon, Mar 4 2013 3:28 PM

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

Posts 25663
Forum MVP
Dave Hooton | Forum Activity | Replied: Mon, Mar 4 2013 4:44 PM

Jared Wood:

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.

Dave
===

Windows 10 & Android 8

Posts 22750
Forum MVP
Graham Criddle | Forum Activity | Replied: Tue, Mar 5 2013 4:05 AM

Hi Jared,

I agree with Dave

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

Graham

Posts 13397
Mark Barnes | Forum Activity | Replied: Tue, Mar 5 2013 4:47 AM

Jared Wood:
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.

Posts 4
LogosEmployee
Jared Wood | Forum Activity | Replied: Tue, Mar 5 2013 11:32 AM

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

Posts 4732
Forum MVP
Mike Binks | Forum Activity | Replied: Wed, Mar 6 2013 1:37 AM

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.

Posts 13397
Mark Barnes | Forum Activity | Replied: Wed, Mar 6 2013 2:24 AM

Jared Wood:

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.
Posts 25663
Forum MVP
Dave Hooton | Forum Activity | Replied: Wed, Mar 6 2013 5:28 AM

Mark Barnes:
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
===

Windows 10 & Android 8

Posts 13397
Mark Barnes | Forum Activity | Replied: Wed, Mar 6 2013 6:34 AM

Dave Hooton:
Analysis will consider the content of all cells where the match occurred

I know it does, but it shouldn't (IMO).

Posts 8227
LogosEmployee

Mark Barnes:

Dave Hooton:
Analysis will consider the content of all cells where the match occurred

I know it does, but it shouldn't (IMO).

AFAIK, we don't plan to address this issue with this revamp of search analysis results. (We are mainly trying to remove the display of duplicated rows in the current 5.0b implementation.) Searching a reverse interlinear for Greek or Hebrew is inherently "messy" (because of the reverse interlinear alignment, particularly of idioms), so we recommend searching an original language text when you want to perform detailed analysis of the results.
Posts 13397
Mark Barnes | Forum Activity | Replied: Wed, Mar 6 2013 10:32 AM

Bradley Grainger (Logos):
so we recommend searching an original language text when you want to perform detailed analysis of the results

If you're not planning to fix this (and I appreciate it's a non-trivial fix), I think that you ought to add one of those yellow warning bars to the search screen when you do an analysis search of reverse interlinears that in one sentence explains the problem and suggests a search in an original language text. "We recommend" is all very well, but the tens of thousands of Logos users who never call support or read the forums don't know that.

Posts 15805
Forum MVP
Keep Smiling 4 Jesus :) | Forum Activity | Replied: Sat, Mar 9 2013 8:29 PM

Bradley Grainger (Logos):
so we recommend searching an original language text when you want to perform detailed analysis of the results.

Using Logos 5.1 Beta 1 on OS X 10.8.2 noticed Morph Search Analysis of LXX H.B. Swete Editions doubles usage count since Form is on a separate line.

Dreaming of English Literal Translation column(s) that would enable an Englishman's Greek Concordance search in LXX, ideally with a Language column.  Wonder about changing Previous, Result, and Next on H.B. Swete LXX lines with English Lexical Definition to have English Literal Translation (instead of Greek) ?

Noticed New Revised Standard Version has Greek Reverse Interlinear tagging for Deuterocanonical (Apocryphal) books.  Wonder about Greek Reverse Interlinear plans for other Bibles with Deuterocanonical (Apocryphal) books ?  Likewise wonder about Greek and Hebrew Reverse Interlinear tagging in Old Testament ?

Keep Smiling Smile

Posts 1649
Room4more | Forum Activity | Replied: Sat, Mar 9 2013 10:04 PM

I like the amalgamation, but I will side with Mark on this. I am sure that Bro.George is out there somewhere and would like to comment as well.....calling Bro.George, hheelllloo George......

DISCLAIMER: What you do on YOUR computer is your doing.

Posts 25663
Forum MVP
Dave Hooton | Forum Activity | Replied: Mon, Mar 25 2013 6:00 PM

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

Dave
===

Windows 10 & Android 8

Posts 13397
Mark Barnes | Forum Activity | Replied: Sat, Apr 20 2013 3:28 AM

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!

Posts 13397
Mark Barnes | Forum Activity | Replied: Mon, May 27 2013 2:53 AM

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:

<Lemma = lbs/he/שְׂגִיב>

(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.)

Posts 777
Brisa Davis | Forum Activity | Replied: Thu, May 30 2013 12:37 PM

Mark Barnes:
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?

Posts 13397
Mark Barnes | Forum Activity | Replied: Fri, May 31 2013 3:44 PM

Brisa Davis:
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?

Note the the lemma and root columns. There are two problems:

  • Even if the cells do need to wrap, there shouldn't be all that blank space.
  • If would be better not to display (and therefore export) the lemmas and roots from the Qere and Hybrid readings - at least if those rows are turned off it in the display dropdown.
Posts 777
Brisa Davis | Forum Activity | Replied: Mon, Jun 10 2013 10:40 AM

Mark Barnes:
Even if the cells do need to wrap, there shouldn't be all that blank space.

I am able to reproduce this issue on Windows and will report it to Development.

Mark Barnes:
If would be better not to display (and therefore export) the lemmas and roots from the Qere and Hybrid readings - at least if those rows are turned off it in the display dropdown.

I am able to prevent the lemma and root columns from exporting by turning those columns off in the display dropdown. 

Is that behavior different than the behavior you are seeing?

Posts 13397
Mark Barnes | Forum Activity | Replied: Tue, Jun 11 2013 7:19 AM

I didn't want to prevent the lemma column exporting, I wanted to prevent the Qere lemma spoiling the results.

Page 1 of 2 (21 items) 1 2 Next > | RSS