BUG: Prioritized resource incorrectly listed on Context Menu

Page 1 of 1 (11 items)
This post has 10 Replies | 0 Followers

Posts 28019
Forum MVP
Dave Hooton | Forum Activity | Posted: Sun, Dec 13 2009 10:10 PM | Locked

DBL Hebrew is listed as a resource for Strong's Numbers when it is restricted to Hebrew headwords only!

 

Here is my Prioritize list

DBL Hebrew should not appear on the context menu!

Dave
===

Windows 11 & Android 8

Posts 2246
Damian McGrath | Forum Activity | Replied: Sun, Dec 13 2009 10:17 PM | Locked

Dave,

My understanding is that setting the advanced prioritisation limits does not exclude the resource from the context menu, rather it determines only whether it is considered on the first sweep through your prioritised resources. Having matched prioritised resources for Strong's numbers, the program appears to have then begun doing an alphabetical search (this probably also took a while).... 

Posts 28019
Forum MVP
Dave Hooton | Forum Activity | Replied: Sun, Dec 13 2009 11:15 PM | Locked

We know that this method is a compromise, but I restricted DBL Hebrew to the one data type because I didn't want it used for Strong's numbers. As food for further thought I don't need 5 resources listed every time!

Dave
===

Windows 11 & Android 8

Posts 2246
Damian McGrath | Forum Activity | Replied: Sun, Dec 13 2009 11:37 PM | Locked

Dave Hooton:
As food for further thought I don't need 5 resources listed every time!

Now we're returning to some of the reasoning behind the v3 keylinking.

Oh how I long for those days.... :)

While it may well have been a mystery to some users (and there were some "power users" who did not know that you could set the number of resources to be opened on a double-click from a data-type), I really want this level of control!

Posts 28019
Forum MVP
Dave Hooton | Forum Activity | Replied: Mon, Dec 14 2009 8:56 PM | Locked

Dave Hooton:

DBL Hebrew is listed as a resource for Strong's Numbers when it is restricted to Hebrew headwords only!

The non-forum response from Logos (Jacob Carpenter) is "prioritizing with a limit does not exclude the resource from participating as a candidate for other datatypes that it contains. If resources that you don’t prefer are showing up for specific types of references, you will need to prioritize resources that you do prefer for that reference type."

OK, let's look at the Hebrew resources I have prioritized:-

DBL Hebrew   -->  Heb Headwords + Heb Strong's ===> Apply only to Hebrew

BDB                   -->  Heb Headwords

Vine's (VONT) -->  Heb Headwords* + Heb & Gk Strong's

TWOT               -->  Heb Headwords + Heb Strong's

Concise Dict   -->  Heb Headwords* + Heb & Gk Strong's

ESL                   -->  Heb Headwords* + Heb & Gk Strong's

 

In terms of prioritised resources for Hebrew Strong's #430, the Context Menu I posted shows correctly

  • TWOT
  • Concise Dict
  • ESL                        

plus a non-prioritsed resource:

  • NASB Hebrew-Aramaic & Greek dictionaries

plus a prioritised limited resource:

  • DBL Hebrew

VONT ostensibly #1 for Strong's (actually prioritised for Hebrew words!) is not included because it doesn't have an entry for H430. But L4's logic for Prioritizing, having successfully excluded DBL Heb from being #1 for Strong's then snuck it back at #5! The suggestion that I Prioritize another resource for Strong's effectively means I have to find a better source than VONT and possibly another resource for Hebrew Headwords.  For starters, I wouldn't choose the NASB Hebrew-Aramaic & Greek dictionaries (above) because they have a suspect system of Strong's numbers. 

My suggestion is:

  • do not automatically provide 5 choices on the context menu, and
  • do not include a prioritised resource that was limited to another data type.

 

Dave
===

Windows 11 & Android 8

Posts 216
LogosEmployee
Jacob Carpenter (Faithlife) | Forum Activity | Replied: Thu, Dec 17 2009 8:57 PM | Locked

Forgive my naivety, but why is it so important that you would you want to see less results? Isn't knowing that another article is there, even if you don't want to read it, better than not knowing there are any more articles at all?

If the DBL Hebrew is a good enough resource for Hebrew headwords, that you wouldn't want to hide it (in fact you even prioritize it), why do you want to totally prevent it from participating as a destination for Strong's references?

Posts 2246
Damian McGrath | Forum Activity | Replied: Thu, Dec 17 2009 9:22 PM | Locked

Jacob Carpenter:
why is it so important that you would you want to see less results?

I would like to be able to chose to display fewer results in some cases because it speeds things up if it only has to look at 2 of my resources. Seriously, in right clicking, on a Gk word I only want to know if it's in BDAG or LSJ... no more.   Right clicking on an English word, is it in ABD... no more.... Hebrew in HALOT, no more....

Posts 28019
Forum MVP
Dave Hooton | Forum Activity | Replied: Fri, Dec 18 2009 7:05 AM | Locked

Jacob Carpenter:
If the DBL Hebrew is a good enough resource for Hebrew headwords, that you wouldn't want to hide it (in fact you even prioritize it), why do you want to totally prevent it from participating as a destination for Strong's references?

It's important because I deliberately limited DBL Hebrew so I wouldn't have it used as a source for Strong's - it's my #1 for Hebrew Headwords not Strong's numbers. I'm puzzled why the Prioritize logic would disrespect that desire and list it at #5 when I obviously didn't want it at #1.

As you can see my bottom line Strong's resource is ESL which should guarantee a result. So I'm not bothered if that is the only lexicon listed, but I'll usually get three (prioritised) lexicons. However, the others are prioritized primarily for Hebrew headwords and ESL is deliberately last for Hebrew headwords. If I wanted DBL Hebrew to participate as a candidate for Strong's I would NOT restrict it!

Above all that, I usually only look at the top 1 or 2 resource results in any category.

 

Dave
===

Windows 11 & Android 8

Posts 216
LogosEmployee
Jacob Carpenter (Faithlife) | Forum Activity | Replied: Fri, Dec 18 2009 9:30 AM | Locked

Dave Hooton:
I'm puzzled why the Prioritize logic would disrespect that desire and list it at #5 when I obviously didn't want it at #1.

I can try and explain the current implementation:

Out-of-the box, the library has an ordered pool of resources available to satisfy any reference/headword keylink. When we keylink on a specific reference/headword, we filter the ordered list of available resources for resources which include that headword/reference, and we return the desired number of results.

In different situations that desired number of results is different: a reference typed into the command bar only wants the top result; the context menu asks for 5 results; the passage guide's commentary section asks for 6 (until you click more; and then it asks for them all).

In Logos 4, you can prioritize a resource. This promotes the specific resource above any default ordering for all reference/headword types it supports.

You can also set limits on a priority. This restricts the promotion of that resource to the selected reference/headword type. (You can also limit a resource's promotion based on a reference range, or even limit promotion to only apply when following links from a specific resource.)

But promoting a resource with some limit on its promotion does not exclude it from the default ordered list for the other types of references it contains.

Does that make any more sense?

Posts 13428
Mark Barnes | Forum Activity | Replied: Fri, Dec 18 2009 2:30 PM | Locked

It makes sense to me. Although I'd like a gazillion program settings so I can have Logos 4 exactly how I want it (and therefore would like to agree with Dave), I understand that you like to keep things simple. We'll live with 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!

Posts 28019
Forum MVP
Dave Hooton | Forum Activity | Replied: Fri, Dec 18 2009 3:24 PM | Locked

Jacob Carpenter:
Does that make any more sense?

That's precisely why I put forward the suggestion to exclude a prioritised resource that was limited to another data type. I think most people would understand that "apply only to...." effectively means "forget I'm a candidate for other data types". In L3 I could simply untick DBL Hebrew from the Hebrew Strong's Data Type list and it would never be considered. Likewise,  I excluded the NASB Hebrew-Aramaic & Greek dictionaries (that appears at #4 for Strong's) from every data type list in which it appeared! Because I cannot readily achieve that in L4 I would have to Hide it because adding it to the Prioritized list would create undesirable side-effects with the 4 other data types for which it has inadvertently been promoted! Some users have ended up frustrated with this lack of control and hidden the offending resource.

Dave
===

Windows 11 & Android 8

Page 1 of 1 (11 items) | RSS