Reference search - is it missing references?

Can anyone confirm and/or explain this behavior?

Hi Bob

I can confirm it - can't explain it yet!

One question - I am running 4.2a Beta 7, are you running a released version or the beta code as well?

Graham

fgh

Deleted

<BibleNRSV = Luke 2:7> in Entire Library
<Bible = Luke 2:7> in Entire Library
<Luke 2:7> in Entire Library

There's two simple answers:

Bible versions are not supported in a search, so <bible = x> is identical to <biblenrsv = x>
<Luke 2:7> is shorthand for <bible ~ Luke 2:7> not <bible = Luke 2:7>

The difference between = and ~ is that:

the = operator searches only for references that are exactly equal to Luke 2:7
the ~ operator searches for references that intersect with Luke 2:7 (e.g. Luke 2:1-9, Luke 1-3, etc.)

For more info see: http://wiki.logos.com/Detailed_Search_Help#Searching_for_Bible_Verses_and_other_References

<edit>I initially said ~ searches for references that contain Luke 2:7. Whilst this is true when only one verse is being searched for, it is not true if more than one verse is being searched for (e.g. searching for Luke 2:7-9 would find Luke 2:8-11 if the ~ operator was used, though 2:7-9 is not contained in 2:8-11. So I corrected my post to make this clearer.</edit>

https://community.logos.com/discussion/comment/223294#Comment_223294

Thanks Mark

That clarifies things greatly!

<Luke 2:7> is shorthand for <bible ~ Luke 2:7> not <bible = Luke 2:7>

Do you know if this is documented anywhere? I couldn't see it in the wiki article (but it is getting late!!)

Thanks, Graham

https://community.logos.com/discussion/comment/223303#Comment_223303

Do you know if this is documented anywhere? I couldn't see it in the wiki article (but it is getting late!!)

I don't think it's in the Wiki article, but feel free to add it.

https://community.logos.com/discussion/comment/223323#Comment_223323

Thanks, Mark... that clarifies why the searches produce the results they do.

I guess the bigger question for me now is whether using an = search as the default query for the context menu makes sense.

Here's how I understood this menu option: "Show me all the places in my library and content that mention the verse(s) I've selected." Mathematically, that includes any place where my verse range intersects the reference's range.

Here's what the menu option actually does: "Show me all the places in my library that that specifically cite the particular verse(s) I've selected." This search includes any place where my verse range is equivalent to the reference's range - an obviously smaller target.

Now, if I'm alone in misunderstanding what this menu option does, I'll happily admit it - sometimes I'm just thick-skulled, and this could be one of those times. But if I'm right, then the disconnect between what users think they're searching for and the search Logos actually performs is problematic. It leads to de facto false negatives, even if technically Logos shows the user precisely what was requested.

I understand that there are times when either behavior is appropriate, but I suspect that the more commonly desired search is the ~ and not the = search. Folks are pretty good at sifting through heaps of hits, and would rather deal with the longer list of results than never even know about 2/3 of the possible results.

It would make sense to me that the default behavior of the context menu reference search use a ~, then. It might also make sense to somehow inform the user of these two possible search queries, although I don't have any recommendations how that might be done cleanly in the interface.

Here's another thought - do the Cited By and Passage Guide tools perform a ~ search or an = search to achieve their results? I wonder if they aren't being far more restrictive than I first assumed.

https://community.logos.com/discussion/comment/223383#Comment_223383

Hi Bob

I understand that there are times when either behavior is appropriate, but I suspect that the more commonly desired search is the ~ and not the = search.

I think the current behaviour should stay - just as when you use the menu to search on a selected word (option above reference) it searches for just that word.

It would make sense to me that the default behavior of the context menu reference search use a ~, then. It might also make sense to somehow inform the user of these two possible search queries, although I don't have any recommendations how that might be done cleanly in the interface.

But that made me think that there was a way of addressing both cases relatively cleanly.

Just as in there is a "match all word forms" in the search menu, there could be a "match intersection" option to cover this case.

Here's another thought - do the Cited By and Passage Guide tools perform a ~ search or an = search to achieve their results?

From a quick test I did they use the ~ form.

I did a Passage Search on Malachi 3:3 and looked at the Teacher's Commentary. It doesn't explicitly reference the verse but it has a range which includes it. It is reported on both the Passage Search and Cited By tool

Graham

https://community.logos.com/discussion/comment/223323#Comment_223323

Do you know if this is documented anywhere? I couldn't see it in the wiki article (but it is getting late!!)

I don't think it's in the Wiki article, but feel free to add it.

Done

https://community.logos.com/discussion/comment/223383#Comment_223383

I suspect that the more commonly desired search is the ~ and not the = search

You're probably right, and given that Logos interpret <Luke 2:7> as <bible ~ Luke 2:7> they probably agree with you.

I guess the bigger question for me now is whether using an = search as the default query for the context menu makes sense.

I doubt it will change now, as everyone is used to it the way it is. I think the difficulty is how to design the user interface in a way that gives a range of options, without confusing the user. That's not easy with a product as powerful as Logos.

https://community.logos.com/discussion/comment/223400#Comment_223400

Hi, Graham and Mark... you fellas have been excellent conversation partners in this. Thanks for that!

I think the current behaviour should stay - just as when you use the menu to search on a selected word (option above reference) it searches for just that word.[

First of all, I want to applaud your use of "-iour" above! For some reason that always pleases me...

About the search behavior - I don't think the context search for the selected word actually does limit the search to the precise word selected. As far as I can tell, it defaults to the last stemming behavior chosen by the user. If you've checked "Match all word forms," it will give the broader, stemming results.

But that made me think that there was a way of addressing both cases relatively cleanly. Just as in there is a "match all word forms" in the search menu, there could be a "match intersection" option to cover this case.

That would definitely be a help. I'd be grateful for the ability to choose which behavior the search exhibits!

I guess the bigger question for me now is whether using an = search as the default query for the context menu makes sense.

I doubt it will change now, as everyone is used to it the way it is. I think the difficulty is how to design the user interface in a way that gives a range of options, without confusing the user. That's not easy with a product as powerful as Logos.

Mark, do you think most users are used to the current behavior, or are they just not realizing what's going on? Obviously, I was personally floored when I noticed the discrepancy, and it wasn't a pleasant surprise. It made me wonder what I might have missed as I studied prior to this discovery. I'm also pretty sure I won't ever have occasion to use the context reference search again, at least with its current behavior. The = search is almost never going to be what I'm after when I do that.

So, at least in my case:

Being OK with the behavior of this menu option was a matter of ignorance, not acceptance.
Now that I'm no longer ignorant of its behavior, I find it's no longer of much use to me.

If that's true of many/most users, then I think a strong case can be made for changing the software, even if it's just adding an option, as Graham suggested.

I actually find Logos' behavior bafflingly inconsistent when it comes to how general or specific its automatic searches are:

In the case of the context menu's selection search, the stem/no-stem behavior depends on the preferences of the user's last search.
In the case of the context menu's reference search, the more restrictive approach is taken.
When double-clicking on an English word or doing a look-up from the context menu, stemming is used, since it takes the "dictionary form" of the word to correctly look up a definition.
When double-clicking on a Greek word, Logos looks for an article on the manuscript form of the word selected, rather than the "dictionary" lemma of the word, usually leading to a resource like ANLEX as opposed to the preferred lexicon.

I would argue that the less restrictive search is the more useful in each of these cases. But the real problem isn't so much that Logos preferences don't match my own - it's that I can't find any rhyme or reason to explain when Logos is going to be strict in its results, and when it will be looser. I just have to learn on a case by case basis which behavior will occur, and then learn how to work around the ones that aren't helpful to me.

Of course, I've been saying this since the keylinking days of Logos 3 - it never made sense to me that the keylink for English words found their dictionary form, but the one for Greek words refused to. So I've been grinding this axe for a while. [;)]

Which probably suggests it's not likely to change anytime soon, if ever...

https://community.logos.com/discussion/comment/223492#Comment_223492

Of course, I've been saying this since the keylinking days of Logos 3 - it never made sense to me that the keylink for English words found their dictionary form, but the one for Greek words refused to.

I don't disagree with what you wrote, though I guess I've got used to the inconsistencies by now (apart from stemming and match case 'sticking' - that is annoying!).

But regarding keylinking, the difference here is between the Greek and English dictionaries, not in the way Logos works. If I double click the word "passed" in English, it brings up by preferred dictionary, because that dictionary's headwords include all forms of the word. In Greek lexicons that's only the case in analytical lexicons.

Kevin Becker

https://community.logos.com/discussion/comment/223492#Comment_223492

When double-clicking on an English word or doing a look-up from the context menu, stemming is used, since it takes the "dictionary form" of the word to correctly look up a definition.
When double-clicking on a Greek word, Logos looks for an article on the manuscript form of the word selected, rather than the "dictionary" lemma of the word, usually leading to a resource like ANLEX as opposed to the preferred lexicon.

For onlookers let me remind them that going to ANLEX is a behavior if you double-click a Greek word in a book like a commentary. If you double click on a morphologically tagged text then you will go to the lexical entry.

I don't see this as an inconsistency but marking the difference between an inflected language (Greek) and a mostly noninflected language (English). Generally, English words vary must less widely from their dictionary forms than Greek words do. This means it is technically easier for a lookup to be performed. Greek's inflections communicate information that is not included in a dictionary article. If I come across an inflected form in a book that I don't recognize the Parsing information which the ANLEX will tell me is just as important as the gloss is. I can then use ANLEX to direct me next to BDAG or whatever lexicon I prefer.

https://community.logos.com/discussion/comment/223532#Comment_223532

For onlookers let me remind them that going to ANLEX is a behavior if you double-click a Greek word in a book like a commentary. If you double click on a morphologically tagged text then you will go to the lexical entry.

Thanks for mentioning that, Kevin... that's very interesting!

The results you get appear to depend on the morphology you use. I based my original statement on tests I did using NA26, which uses the GRAMCORD morphology. (NA26 was my go-to Greek Bible for years, and I just open it out of habit now. I don't have NA27 - I know I'm behind the curve, but money is money.) In that case, the lookup does indeed take me to ANLEX, and not my preferred lexicon.

Based on your comment, Kevin, I gave it a shot in the Lexham Discourse Greek NT and the SBL Greek NT. Both of these Bibles use the newer Logos morphology, and a double-click lookup takes me to the lemma entry in my preferred lexicon, just like you said. Very nice to know that!

But this adds another layer of inconsistency or unpredictability - the logic for having one kind of result in NA26 and another in SBLNT isn't apparent to the user (or, at least, this user!), and the behavior is only discoverable by accident. I'm glad that the newer resources default to the lemma - it makes the most sense to me. I wish there were an option that would let you choose the opposite behavior, Kevin, since I can see how it fits your study needs better. Mostly, though, I just wish the behavior were predictable.

The more complex and the less fully documented an application is, the more important it becomes for it to behave in predictable, discoverable, consistent ways. Logos is definitely in the running for both the most complex and least documented software I use, and it's not always so clear why it makes the choices it does, or whether I can change them, once I notice what's going on. I love Logos and wouldn't think of doing without it, but I do wish I didn't have to be taken by surprise by these things.

https://community.logos.com/discussion/comment/223544#Comment_223544

But this adds another layer of inconsistency or unpredictability - the logic for having one kind of result in NA26 and another in SBLNT isn't apparent to the user (or, at least, this user!), and the behavior is only discoverable by accident. I'm glad that the newer resources default to the lemma - it makes the most sense to me. I wish there were an option that would let you choose the opposite behavior, Kevin, since I can see how it fits your study needs better. Mostly, though, I just wish the behavior were predictable.

Logos has always provided several different databases. In your case you must be using an NA26 without morphological tagging. If you have multiple NA26s, I'd recommend hiding that resource - it's of little use if you also have a morphologically tagged version. The morphologically tagged version that I have does open an ordinary lexicon using the correct lemma.

Kevin Becker

https://community.logos.com/discussion/comment/223544#Comment_223544

Thanks for mentioning that, Kevin... that's very interesting!

The results you get appear to depend on the morphology you use. I based my original statement on tests I did using NA26, which uses the GRAMCORD morphology. (NA26 was my go-to Greek Bible for years, and I just open it out of habit now. I don't have NA27 - I know I'm behind the curve, but money is money.) In that case, the lookup does indeed take me to ANLEX, and not my preferred lexicon.

Based on your comment, Kevin, I gave it a shot in the Lexham Discourse Greek NT and the SBL Greek NT. Both of these Bibles use the newer Logos morphology, and a double-click lookup takes me to the lemma entry in my preferred lexicon, just like you said. Very nice to know that!

But this adds another layer of inconsistency or unpredictability - the logic for having one kind of result in NA26 and another in SBLNT isn't apparent to the user (or, at least, this user!), and the behavior is only discoverable by accident. I'm glad that the newer resources default to the lemma - it makes the most sense to me. I wish there were an option that would let you choose the opposite behavior, Kevin, since I can see how it fits your study needs better. Mostly, though, I just wish the behavior were predictable.

The more complex and the less fully documented an application is, the more important it becomes for it to behave in predictable, discoverable, consistent ways. Logos is definitely in the running for both the most complex and least documented software I use, and it's not always so clear why it makes the choices it does, or whether I can change them, once I notice what's going on. I love Logos and wouldn't think of doing without it, but I do wish I didn't have to be taken by surprise by these things.

Well, Logos adds another layer of complexity because they have been improving both the product and the tagging schemes over time.

The NA26 is a relic from the LLS days and its tagging scheme will not take advantages to the structural improvements that Logos has made over the years. It would be nice for long-time users to be able to have this resource updated to take advantages to the newer ways of doing things.

EDIT: Strike my relic comment about the NA26 if you're using the non-morphologically tagged version as Mark suggests above.

EDIT 2: Mark, doesn't Bob say he's using a Gramcord NA26?

https://community.logos.com/discussion/comment/223547#Comment_223547

Mark, doesn't Bob say he's using a Gramcord NA26?

He did, you're quite right. In that case, if ANLEX is opening when double clicking on NA26, then ANLEX must be prioritised above the other lexicons. Bob, you should make sure that ANLEX is prioritised below your other lexicons if you want the other lexicons to open.