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
Comments
-
Jared Wood said:
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 11 & Android 13
0 -
Hi Jared,
I agree with Dave
I don't see this change as being helpful at all
Graham
0 -
Jared Wood said:
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.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Thank you for all of your suggestions. I will evaluate and work on improvements for the upcoming beta releases.
0 -
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.
tootle pip
Mike
How to get logs and post them.(now tagging post-apocalyptic fiction as current affairs) Latest Logos, MacOS, iOS and iPadOS
0 -
Jared Wood said:
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.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Mark Barnes said:
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 11 & Android 13
0 -
Dave Hooton said:
Analysis will consider the content of all cells where the match occurred
I know it does, but it shouldn't (IMO).
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Mark Barnes said:Dave Hooton said:
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.0 -
Bradley Grainger (Logos) said:
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.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Bradley Grainger (Logos) said:
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 [:)]
0 -
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.
0 -
Dave Hooton said:
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 11 & Android 13
0 -
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!
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
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.)
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Mark Barnes said:
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?
0 -
Brisa Davis said:
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.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Mark Barnes said:
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 said: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?
0 -
I didn't want to prevent the lemma column exporting, I wanted to prevent the Qere lemma spoiling the results.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Mark Barnes said:
Even if the cells do need to wrap, there shouldn't be all that blank space.
According to Development, this is not an issue that will be fixed at this time. The issue is due to the way Xceed handles the information.
0
