Did John the Baptist REALLY go to prison?
Comments
-
Your search is not built correctly try {Section <Event John the Baptist is arrested>}
0 -
Correction: the search generated by the context menu is not built correctly. I did not build it.
A perfect illustration of https://community.logos.com/forums/t/103515.aspx
Furthermore, compare the various < Searches > below:
0 -
The bug where right-click makes the wrong search has been reported. Sorry for the inconvenience.
(Yes, search got more powerful in L6, but also way more complex. We'll work on that, too. Stay tuned.)
0 -
Thanks, Eli. Is there a particular reason <Event Name of the Event> does not work (see screenshot above) while the other < FactbookDatatype Searchterm> searches work better?
0 -
Francis said:
Is there a particular reason <Event Name of the Event> does not work (see screenshot above) while the other < FactbookDatatype Searchterm> searches work better?
At least I think it should work like the others
(just noting for precision: in Bible Search. <Event xxxxx > does work in Basic Search and finds results in non-bibles)
Have joy in the Lord!
0 -
Events in this resource behave more like regular milestones, which also don't return results for this search syntax.
For example, a search for "<Bible Jn 3:16>" in a resource doesn't highlight the text of John 3:16 (but only references to it).
0 -
Events in this resource behave more like regular milestones, which also don't return results for this search syntax.
Are you merely describing what is happening or are you stating that this is as it should be? In relation to Factbook, it is difficult for the user to see the logic for a different behavior for Events from that of the other categories. This is all the more so as Factbook does list Events in a given book, with links to specific passages AND the passages in question do feature the events in the context menu AND provide searchability for them. If the event is tagged in a passage and can be found by Factbook, why could it not be found by searching?
0 -
Francis said:
Are you merely describing what is happening or are you stating that this is as it should be?
Why can't it be both? [:)]
To expand on Bradley's (cryptic) answer:
The different search extension syntaxes reflect where in the system the information is ferreted away, which generally reflects a real/substantive difference in the nature of the information:
- Milestones. The {Milestone ...} syntax searches the organizational waypoints within a resource. Generally speaking, these are native to the book and sitting there in black and white — the chapter headings and verse numbers in your Bible, for instance. If you can type it into the location bar of the resource, (that is, if it shows up in the "Indexes" section of the Resource Information) then use the {Milestone ...} syntax to search for it.
- Sections. The {Section ... } syntax searches for secondary information added to long stretches of resource text by way of some dataset that supplements the original resource. Generally speaking, these are like milestones in that that apply to long stretches of text, but not like milestones in that they aren't native to the book, that is, sitting there in black and white. Section data is editorial/subjective/supplemental in nature. Preaching Themes definitely falls into this category, as does Literary Typing, and Cultural Concepts, and most importantly for this discussion, Biblical Events.
- References. Everything else is searched with the <...> syntax. Generally speaking, this is hyperlinked citations or data attached to short words and phrases (such as Bible Sense Lexicon senses or Strong's Numbers).
All three of these types of information are stored in different parts of the system and so require very different methods for the search engine to locate. So to clue the search engine into the fact that you want it to look in the milestone index rather than the normal full-text index, we have to invoke the {Milestone ...} search extension. Similarly, {Section ...} tells the search engine to check various supplemental rather than primary resource data, and that it's looking for long stretches of text rather than single words. (We'd all be very upset to get N hits per N words for these searches.)
We're aware that this division by storage mechanism puts an extra cognitive burden on users and we are working on strategies for streamlining the syntax so that there's a way to look everywhere for a piece of information without worrying about whether it's a section or a milestone or whatever. In the meantime, I hope this explanation helps.
0
