Exact References Only
I have just carried out a basic Bible search for Heb 10:13-25 for my entire library, but obtained no hits.
I actually wanted Heb 10:19-25 so when I corrected my reference I obtained 232 references in 198 articles, which I thought strange.
So I tried:
Heb 10:20-25 and got no hits.
Does this mean that the search will only pick out exact references and will not allow for ranges that might fall inside a larger reference range? If so this seriousely limits the articles found "serendipidously"
I hope that question makes sense!
Comments
-
Ian,
Could you be more specific as to what you did? Did you perform a Bible search (which searches the text of the Bible) or a Basic search (which searches the text of everything in your library)? I just ran a Basic Search on my entire library for Hebrews 10:13-25 and came up with 5,293 results in 3,405 articles. Perhaps you could post a picture of the failed search.
For the record, the search time of 1.22 seconds is absolutely amazing. I reran the search and it clocked in at .49 seconds. Wow!
0 -
My Error!
I have entered the Bible search through the "Cited by" menu instead of the "search" button. I wondered why your screen shot looked different from mine. Thanks for the pictue. [:P]
The speed of the searches is fantastic!
0 -
Did you specify anything to let it know you are looking for any passages in that range? In Libronix 3 the query would be something like: bible in "Heb 10:13-25" it looks like in Libronix 4 searching for an exact passage has a query <bible = Heb 10:13-25> while looking for anything in that range would leave out the = as in: <bible Heb 10:13-25> when I do the last search I get 4,529 hits in 2,959 articles my library. Make sure you include your query in the < > symbols, that evidently tells the program that the string is a search query rather than a search for an exact match.
Logos, any other search format helps? I can't find specific info in the help window.
0 -
David,
Well THAT was simple! Here I am trying to find query strings and such and all you have to do is enter the reference range? Stop showing me up.
Edit:
Actually, the two searches don't return the same results... The search is giving me more results than just Heb 10:13-25. Not sure yet what the difference is.0 -
isn't the syntax
bible <heb 1013-25>
rather than
<bible heb 10:13-25>
When I ran the search as you suggested I got all numbers including passages; when I only enclosed the passage in the brackets...I got "all ranges within"
?
Robert Pavich
For help go to the Wiki: http://wiki.logos.com/Table_of_Contents__
0 -
I have entered the Bible search through the "Cited by" menu instead of the "search" button. I wondered why your screen shot looked different from mine. Thanks for the pictue.
There is a bug in Cited By (in Beta 1) that makes it only perform exact matches, which isn't very useful. We'll be broadening it in an upcoming release (I can't remember if it's fixed in Beta 2 yet or not) to allow it to match overlapping verse ranges. (So it should end up returning pretty similar results to Basic Search.)
0 -
Logos, any other search format helps? I can't find specific info in the help window.
Sorry that we haven't got the new search syntax documented yet. The basic structure for data type reference queries is
<DataType Operator Reference>
Only the angle brackets and Reference are required; the others are optional but can be used to disambiguate a query. (Minor note: because Bible references are so commonly searched for, we allow the angle brackets to be dropped in Basic Search if your Reference can be understood as a Bible reference.)
DataType is the data type aliases that you're generally familiar with from LDLS3: Bible, GreekStrongs, AF, etc. (We don't have a complete list available yet.)
Operator is how the query should be matched against your resources. ~ (intersection) is the default; = (equality) is another useful option. There's also "superset" and "subset".
Reference is the human-readable form of the reference itself. If this reference is pretty unambiguous, typing this in (between angle brackets) is all you need.
Some sample queries (the first three are just different ways of writing the same thing, but are included for illustrative purposes):
<GreekStrongs = 100>
<GreekStrongs 100>
<G100><1 Clement 1>
<af superset 1 Clement 2><jn 3:16-18>
<=jn 3:16-18>
"compare <jn 3:16>"0 -
isn't the syntax
bible <heb 1013-25>
rather than
<bible heb 10:13-25>
The first query (assuming you add the missing colon) finds all resources that have the word "Bible" and a reference that intersects Hebrews 10:13-25. (This happens because "bible" is outside the angle brackets, so the search engine treats it as a word.
The second query just finds Bible references that intersect with Hebrews 10:13-25. Because "heb 10:13-25" can be understood unambiguously by the search engine, the data type name "bible" is optional and can be omitted. (And then, as previously mentioned, if you run this query in Basic Search, you can omit the angle brackets, but that's a special feature for Bible references in Basic Search only.)
0 -
Thanks Bradley, that's all very helpful!
Chris, the only reason I can do the simple stuff is because I never understood all the complicated stuff with data types and angle brackets [:S]
0 -
Bradley,
Why would I get different results between searching for Heb 10:13-25 and <bible Heb 10:13-25> ? The screenshot shows one of the different hits - the very first result on the left is the fourth on the right. It *looks* like the search on the right does not pick up the hit from the Masoretic Text but it's not clear that this sort of thing would lead to almost 100 more results on the left and it doesn't quite explain the difference when searching a passage like Eph 4:7-10 (1,893 when searched in the angle brackets, 1,852 when just the reference is inserted)
.png)
0 -
I just ran a Basic Search on my entire library for Hebrews 10:13-25 and came up with 5,293 results in 3,405 articles. For the record, the search time of 1.22 seconds is absolutely amazing. I reran the search and it clocked in at .49 seconds. Wow!
For me I got 14,246 results in 8,948 articles in 19.06secs. (i.e. a Basic Search on my entire library for Hebrews 10:13-25)
Besides library size specs of machine would have an impact but search speed has never been a wow factor for me. LL2 could search faster than I could ever do with the traditional method. For me its a question of what can I do with those search results. But I'll put that in a different thread to keep this one on topic.
0 -
Why would I get different results between searching for Heb 10:13-25 and <bible Heb 10:13-25> ? The screenshot shows one of the different hits - the very first result on the left is the fourth on the right. It *looks* like the search on the right does not pick up the hit from the Masoretic Text but it's not clear that this sort of thing would lead to almost 100 more results on the left and it doesn't quite explain the difference when searching a passage like Eph 4:7-10 (1,893 when searched in the angle brackets, 1,852 when just the reference is inserted)
Looks like you've found a subtle bug in Bible searching. When you use the angle brackets, we implicitly convert to other versifications. The most obvious example you see in your screenshot is where the opening verses of Leviticus 6 (in English translations) are numbered as the end of ch. 5 in the BHS. (The ESV has 19 verses in Leviticus 5; BHS has 26.)
We automatically convert references when performing a data type reference search, so that you can find all references to the verse you specified, even if it's numbered differently in the source text. However, this conversion isn't taking place if the angle brackets are omitted, which is a bug.
The reason for missing hits in the Eph 4:7-10 query is that some resources might be (behind the scenes) citing a Catholic or TR verse number; even though it may be the same as the verse numbering in the critical text (which we in general use by default because most modern English translations do), the system internally treats it as a different reference. This is just another symptom of the same bug.
0
