These rules are now available in the original post.
Than you, Mark.
Question: Since I'm not a beta tester, how will we know when a stable release will handle these? Will it be 7.15 or other?
Harder question: How, exactly, do these perform better?
Thanks for all the work!
User speculation for 7.15 stable release is Mon 14 May.
Thread => Library Search Extensions in 7.15 Beta 2 includes Faithlife developer comments. Search extension seeks exact match while filter has wildcard implications (match part of a string). Exact match is quicker to evaluate. By way of example:
author:Calvin
matches Calvin, Jean OR Calvin, John OR Cowles, Calvin D OR McRae, Calvin Alexander OR Miller,Calvin OR Ratz, Calvin OR Schaap, James Calvin OR Smith, J. Calvin OR Stapert, Calvin R
{Author "Calvin, Jean", "Calvin, John"}
matches exactly two authors: (with their co-authors appearing in Library list)
Screen shot shows fewer resources for exact match of two authors.
Keep Smiling [:)]
Thanks for all your work, Mark!
A textual commentary that you haven't included is "New Testament Text And Translation Commentary"
I've simply modified the rule for myself but thought it might be good to have it in the rule for everyone.
EDIT–There are 3 series that should be added to the Technical collection:
"Translator's Notes" "Translator’s Notes" (needs the curly apostrophe)
"Semantic and Structural Analysis"
"Exegetical Helps"
These 3 series aren't available for individual purchase but there are at least 1242 people who have these in Logos, so I think it would be worth adding to the rule.
Thanks Rebuen. I've added these along with NET Bible Notes.
I've also applied the new syntax to the two rules that refer to the Crossway Classic Commentaries, as suggested by KS4J. It probably won't make any discernible difference, but it's good for completeness.
Since I'm not a beta tester, how will we know when a stable release will handle these? Will it be 7.15 or other?
I've played around with it quite a bit, and I haven't found any bugs, so I'd be confident about a 7.15 release.
I can't be sure of the exact technical operations, but effectively they sacrifice flexibility for speed.
So under the normal syntax I could type author:"macarthur, john", or author:"MacArthur, John", or even author:"mAcArThUr.,;'#-JoHn" and still get the results I want.
Under the new syntax, I can only type {Author "MacArthur, John F., Jr."}. Any tiny variation on that won't match.
Generally, in code, loose matches are slower than exact matches — either because the code has to check multiple possibilities, or because search terms have to be transformed into a slightly different format before searching, or because it's not possible to use an index, or a combination of these.
Presumably it wasn't considered worthwhile (or perhaps even possible) to speed up the existing syntax without breaking backward compatibility, and therefore an alternative syntax has now been added.
an alternative syntax has now been added
So I don't you-know-what by assuming anything, does this imply that the old syntax will still work, or will we need to learn a new syntax to use the tool?
will we need to learn a new syntax to use the tool?
The old syntax will still work. The new is really only useful to increase performance on particularly long collection rules. I don’t think anyone will use it to find a single library resource, for instance.
We investigated speeding up the existing syntax, but concluded that we couldn't do it without breaking many existing collections. (Which you probably saw when tweaking your existing collections to convert them to the new syntax.) Since these complicated author/commentary/denomination collections tend to be created once and then shared, we decided that the next-best approach was to introduce new syntax that a few people might have to learn (to convert the collections) but many people could benefit from.
Thank you Bradley. FWIW, from my perspective, allowing the old to continue to work was the right call. Now I can take whatever time I need to learn the new without being desperate to build a new collection.
Strongly agree.
One Volume Commentaries type:bible-commentary AND ({Series None} AND ((subject:"Bible—Commentaries" ANDNOT subject:"Bible—Commentaries—Collected works") OR (subject:”Bible. O.T.--Commentaries” AND subject:”Bible. .N.T.--Commentaries”) OR subject:"bible handbooks" OR subject:"bible introductions") ANDNOT title:volumes) OR {MyTag "commentary-one-volume"}
type:bible-commentary AND ({Series None} AND ((subject:"Bible—Commentaries" ANDNOT subject:"Bible—Commentaries—Collected works") OR (subject:”Bible. O.T.--Commentaries” AND subject:”Bible. .N.T.--Commentaries”) OR subject:"bible handbooks" OR subject:"bible introductions") ANDNOT title:volumes) OR {MyTag "commentary-one-volume"}
It includes:
It excludes:
Overall, I would recommend that the rule be changed by removing ANDNOT title:volumes.
The Apollos Old Testament Commentary came out recently... not sure if it would be better in expository or technical though. I remember someone somewhere on the forums compared it to the Pillar NTC
Thanks Mark!
Thanks, Mark. On the Historical Commentaries:Antiquity section, I'm seeing a few missed commentaries that can be included via something like author:("Cyril of Alexandria", "Theodore of Mopsuestia").
The works this adds are:
https://www.logos.com/product/16614/theodore-of-mopsuestia-commentary-on-the-minor-pauline-epistles
https://www.logos.com/product/27656/a-commentary-upon-the-gospel-according-to-s-luke
For the Historical Commentaries: Medieval rules, you are missing commentaries by Aquinas. They can be added by changing author:bede to author:(aquinas, bede).
This adds Aquinas's commentaries on John and Matthew.
