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,
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)....
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!
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!
The non-forum response from Logos (Jacob Carpenter) is "prioritizing with a limit does not exclude the resource fromparticipating as a candidate for other datatypes that it contains. Ifresources that you don’t prefer are showing up for specific types ofreferences, you will need to prioritize resources that you do preferfor 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
plus a non-prioritsed resource:
plus a prioritised limited resource:
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:
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?
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....
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.
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?
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.
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.
