(Untitled)
Comments
-
I should emphasise that due to the way things have developed over time, you can probably find many counterexamples of data being tagged as a reference where it shouldn't be, or being used inappropriately as a milestone, etc. Our ability to change these and standardise everything according to our current taxonomy is limited.
That doesn't negate the fundamental concept that there are distinct kinds of relationships between a section of text and a data type reference. These are encoded differently inside Logos resources, and the search engine surfaces that difference.
0 -
Mark Barnes said:
You search for datatype references, you search using search extensions.
I think this is a very helpful distinction.
You can even think of each search extension as being a "mini search engine" embedded inside the main Logos search engine.
That's why I keep saying "there's not a simple way to summarise them", each one is used for "other things", "there is no simple answer", etc.
0 -
There are three primary ways
A fourth way is for a word (or phrase) in a tagged text to be an instance or example of a classification. Lemmas, morphs, roots, senses, etc. all fall into this category. These are currently tagged as "references" (group #2 in my earlier post) in Logos, but are not hyperlinks.
0 -
May I make a suggestion?
This information should be made available in the Courses tool. Don't leave these details buried in a forum thread or in the heads of developers and power users.
Please guide people through learning the search terminology and functionality of the software.
I am sure there is a wealth of information here, and it just needs to be organized into a course, so people (like me) can learn it from beginning to end.
As Fr. Devin mentioned in another post, there is a lot on the wiki and the help system, but if you just vaguely leave it up to us to figure out on our own, it's honestly a bit too intimidating to tackle, or progress by teaching ourselves.
Thanks to FL for including Carta and a Hebrew audio bible in Logos 9!
0 -
TIP of the day: Putting a search together: Jesus speaking to God the Father in the Passion Narrative
TIP of the day: Reference operators in Search arguments
TIP of the day: Why is Search so ______________ difficult?
TIP of the day: Putting a search together: Jesus called Lamb, Lamb of God, Paschal Lamb ,,,
TIP of the day: Special search fields - Amplified Bible
Tip of the day: basic search options (Search panel icon menu) and drop-down options
TIP of the day: Search foreign languages - French, German, Spanish ...
TIP of the day: Add Collection or Commentary; Search milestone or reference
TIP of the day: Nitty-gritty of the very basic search
TIP of the day: Putting a search together: Finding the Suffering Servant songs
TIP of the day: Basic Search results options
TIP of the day: Putting a search together: Hannah's song and the Magnificat
TIP of the day: one common search error and its fix
TIP of the day: How do I find 2 or more passages used in the same Systematic theology article?
TIP of the day: Searches built by Guides
TIP of the day: Context menu searches for English New Testament part 1
TIP of the day:Term modifiers - specifying language and mark sensitivity
TIP of the day: Logos tagging #13: shortcut for Searching on tags
TIP of the day: Lemma searching for Hebrew
et. al.
Know that's not what you want but giving a sense of the about of information available
Orthodox Bishop Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship."; Orthodox proverb: "We know where the Church is, we do not know where it is not."
0 -
I think one of the "problems" here is the lingo. It's like listening to two medical doctors or two car mechanics discussing something, and not understanding the terminology, never mind the anatomy or how an engine works.
The how's and whys are probably interesting, but I think most of the terms go over peoples' heads, and frankly keep us from grasping what the software can truly do.
How do you bridge the gap between the technical know-how and the simpler, practical explanations? If we can't explain something that a four-year-old can grasp, perhaps it comes down to the terms we use for these concepts?
Thanks to FL for including Carta and a Hebrew audio bible in Logos 9!
0 -
PetahChristian said:
I think one of the "problems" here is the lingo. It's like listening to two medical doctors or two car mechanics discussing something, and not understanding the terminology, never mind the anatomy or how an engine works.
The how's and whys are probably interesting, but I think most of the terms go over peoples' heads, and frankly keep us from grasping what the software can truly do.
How do you bridge the gap between the technical know-how and the simpler, practical explanations? If we can't explain something that a four-year-old can grasp, perhaps it comes down to the terms we use for these concepts?
Yup, Yup, YUP!
Cynthia
Romans 8:28-38
0 -
MJ. Smith said:
Know that's not what you want but giving a sense of the about of information available
One of the things I like about the Courses tool is that I can filter courses by beginner, intermediate, and advanced.
If the search tips could be categorized the same way, we'd be able to progress through beginner tips, and so on, and finally master everything.
The other thing about a course is that it builds on the material within the course. For example, there is an introduction, then you get into more details, then you have an activity to explore/apply what you learned, then there's a test.
It might help if the search tips use something like Mobile Ed numbering. That way, even within the beginner search tips, someone would realize they would probably need to read a 101 or 102 level beginner tip, before a 131 level beginner tip, just so we can ensure we have the necessary "prerequisites" before delving into a different tip.
I think what makes the course more successful is that it's all neatly categorized and packaged and easily repeatable.
The key is to convert the wealth of forum/wiki details to make them accessible right within the courses tool.
Thanks to FL for including Carta and a Hebrew audio bible in Logos 9!
0 -
My head is spinning after reading through this thread. I guess that's normal.[:^)][:D]
0 -
PetahChristian said:
I think one of the "problems" here is the lingo.
Seeking to "translate" the lingo in concepts that are easier for everyone to relate to is a large part of what I am trying to do here. I think we have made progress in the last round.
Thank you Andrew, Mark, Bradley, and MJ for your replies. I found most helpful this:
The {Section syntax is used because we're talking about a different kind of annotation. There are three primary ways we can categorise the relationship of text to a data type reference:
- the content of that reference, e.g., "In the beginning was the Word..." is the content of John 1:1. When you look up John 1:1, that's where you go.
- a reference to that reference, e.g., "see John 1:1". This is the most common use of data type references in the system, and what the syntax <John 1:1> searches for
- text about that reference, e.g., a commentary on John 1:1
In the early days of the Logos search engine, the second kind of annotation (reference) was the only thing you could search for, and what the search syntax was designed to enable.
and that:
Mark Barnes said:you search for datatype references, you search using search extensions.
It feels indeed, as Andrew put it, that we are getting closer. There are still some bits and pieces that we can perhaps consolidate with these shorter, more to the point explanations:
The distinction about searching for and using is good, especially in relation to milestones and sections, but one also searches for a label and a highlighter style or a specific passage list, although it is also possible to search within (using) these. As I look on label, highlighter style, and passage lists, it strikes me that they all are user-defined annotations (they don't come with the resource or supplied through a dataset). This is not true of milestones and sections of course (they are not user defined), but it can be a useful additional criteria to distinguish between data types and extensions:
- Data types are specific referents one can find because the resources are encoded with them (a place, a person, a thing). What one finds by searching for a datatype is an instance of this datatype: Abraham is a person, Jerusalem a place, a stone is a thing, etc. As a result, normally* what a data type finds cannot be more than one data type at a time (Abraham is a person, and not a thing, a place, etc) and you cannot find <Thing X> WITHIN <Person Y>.
- Extensions allow one to either (a) find contexts in which instances of data types are found (a person or thing within a milestone or section) or (b) find information the user has tagged ("extended") resources with (label = Psalm, highlight = Yellow) or (c) the combination of both, find data types within user defined tagged text (a person within a highlighted text). What one finds is (except in b.) connected to a data type but not equal to it (a section in which a person is found is not itself a person, a text which has a preaching theme is not itself a preaching theme. Abraham is not a speaker or an addressee, sometimes he has that role but he is always a person). You can find <Thing X> WITHIN {Extension Y}. Except in (b), one does not search for an extension itself: you don't search for {Section 00149} if there is even such a thing.
I highlighted the sentence that I think is the key addition.
* I put "normally" just in case there are exceptions although I cannot think of any just now and am not sure there are.
I want to thank you for persevering in this. It is a passion of mine to help people understand complex concepts and I think that with effort it is usually possible to communicate in layman's terms what is otherwise normally expressed in specialist terms. I don't think that it is only my understanding that has progressed here: I think you have also wrestled with and improved your explanations. The purpose of my summary is to check understanding (summarising in one's own words is a great way to check for correct understanding) but also an attempt to further the effort to make it more intelligible, concrete, and rounded for "the rest of us".
Gary Mendenhall said:My head is spinning after reading through this thread. I guess that's normal.
My goal in starting this thread is not that one would have to read it all in order to "get it" but that hopefully, in the end, we have something is both reasonably accurate and accessible/elucidating to the average user. When we get there, I'd be happy to receive exceptional permission to edit the original post with an addendum that tells people they can skip to a specific post location for the best answer if they don't want to read it all and be overwhelmed by too much information. Hopefully this thread can also give ideas for a useful and needed addition to the help file and other help resources such as tip of the day and the wiki, and the latter would of course be more succint.
0 -
Francis said:
The distinction about searching for and using is good, especially in relation to milestones and sections, but one also searches for a label and a highlighter style or a specific passage list, although it is also possible to search within (using) these
{Highlighting Yellow} means you use a Highlighting search to search for Yellow highlighting.
<bible John 3:16> means you search for a bible reference to John 3:16.
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!
0 -
Francis, I appreciate your efforts here and hope your goals are reached. I have followed this thread since your original post with the hope of gaining insight in an area that I am sadly inept but as the dialog continued on I just became mired in the language and all of the exceptions as well as the responder's assumptions that the readers of this thread have prior knowledge of some of the concepts mentioned. Before this thread I had no idea what a "Milestone" was. This thread is bringing to my attention a fear that I have had for awhile; maybe I'm just too stupid to be using Logos.
Thanks again for your efforts and blessings to you,
Gary
0 -
Gary Mendenhall said:
I have followed this thread since your original post with the hope of gaining insight in an area that I am sadly inept but as the dialog continued on I just became mired in the language and all of the exceptions as well as the responder's assumptions that the readers of this thread have prior knowledge of some of the concepts mentioned.
As I've said before, the people responding to this thread have been trying to give clear definitions and explanations of what's going on under the hood. We've not been trying to give training in advanced search techniques. There's definitely a place for that, but this thread isn't that.
If you want to learn how to do advanced driving, you wouldn't gain much from listening in to a lecture on automobile mechanics. If you stumbled into that lecture but didn't follow everything that was going on, it wouldn't mean you were stupid — it would mean you were in the wrong place!
This might be better for you: https://www.logos.com/product/51655/verbum-advanced-search-training,
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!
0 -
Mark Barnes said:
Either I don't understand you or you did not understand me:
I could just as well say that in <Bible John 3:16> I am using "Bible" to search for John 3:16 which is a Bible reference just as in {Highlight Yellow} I am using "Highlight" to search for Yellow which is a Highlight colour. In both cases I use a class to search for an instance. This is why I suggested that these terms did not apply as readily to the user defined searchable entities such as labels or highlights although they do apply very well to milestones or sections.
Gary Mendenhall said:maybe I'm just too stupid to be using Logos
I am a doctorate candidate, top of class, and I use five different languages and I still find some of the explanations obscure. I don't think it's you, so don't be discouraged about this. Hang in there and hopefully we will land in a better place. When you are learning to drive with a standard transmission, you can be taught to listen for when your engine starts roaring and feel in the pedal the vibrations that show it needs a different gear. Or you can be given a lecture about pistons, RPMs and so on (which will not teach you to drive!). You CAN effectively drive without knowing anything about pistons! And I am sure you and most of us can use Logos without having to learn what goes on under the hood.
Mark Barnes said:As I've said before, the people responding to this thread have been trying to give clear definitions and explanations of what's going on under the hood.
As the OP, I disagree with the gist of your response to Gary. If you read my original post again you will see that I was specifically asking to limit jargon, and strive for something practical and easy to remember.
0 -
Thanks for your reply Mark, I guess I've been schooled. I've learned quite a lot from these forums over the years and I don't think it's too much of an expectation to think that I can still learn more by following a thread of interest. Indeed this thread became a bit over my head but I guess I wouldn't have known that had I not followed it; right? As I continued to follow the thread I kept hoping that things would be clearer and a bell would go off in my head but that didn't happen. I guess it takes some people a little bit longer to find out that the water is a little to deep for their swimming skill.
Regarding your advanced driving and auto mechanic analogy; I don't buy it. I have a sophisticated peace of software in Logos that has a sophisticated search capability. The only way I'm going to be able to understand how to take advantage of those functions is if I know what they do and how they work. In other words, "what's under the hood", or in your terms, "the mechanics". The problem I was having was mostly in the language/terms being used and my unfamiliarity. Was hoping to gain some insight here but see now that I was wrong and need to glean from another source for knowledge on such a sophisticated subject.
. Anyway, I have been in on the pre-pub for the advanced search training videos since it was offered and eagerly waiting for it to go live. Keep up the good work.
Blessings,
Gary
0 -
Thanks for the encouragement Francis.
Blessings,
Gary
0 -
Francis said:
I could just as well say that in <Bible John 3:16> I am using the Bible to search for John 3:16 which is a Bible reference just as in {Highlight Yellow} I am using Highlight to search for Yellow which is a Highlight colour. In both cases I use a class to search for an instance. This is why I suggested that these terms did not apply as readily to the user defined searchable entities such as labels or highlights although they do apply very well to milestones or sections.
You could say that, but that wouldn't make it correct :-). There's a subtle, but important distinction. To use your terms, when you're searching for <Bible John 3:16> the 'class' isn't "Bible". The 'class' is "datatype reference", and the 'instance' is "bible.64.3.16". ('64' because John is the 64th book of the Bible using Logos' way of counting - which includes apocryphal books).
Francis said:As the OP, I disagree with the gist of your response to Gary. If you read my original post again you will see that I was specifically asking to limit jargon, and strive for something practical and easy to remember.
We'll have to agree to disagree on that point. I entirely accept that in your original post you asked to limit jargon, and there was no jargon at all in my first five responses, which (IMO) were both practical and easy to remember, but ultimately unsatisfying to you. I only added jargon in my sixth response when you pushed me to specify what was wrong with your attempt at a definition. At that point I said, "We can either explain it simply (and leave stuff out), or explain it fully (and it will be overwhelming). I'm not sure there's a middle ground." I stand by that comment.
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!
0 -
Mark Barnes said:Francis said:
The distinction about searching for and using is good, especially in relation to milestones and sections, but one also searches for a label and a highlighter style or a specific passage list, although it is also possible to search within (using) these
{Highlighting Yellow} means you use a Highlighting search to search for Yellow highlighting.
<bible John 3:16> means you search for a bible reference to John 3:16.
Mark: I have to agree that the distinction between FOR and USE is the best, succinct piece of information on this thread. And...the way you just used them as examples has really brought a great deal of clarity regarding the {...} and <...>.
I too have to say THANK you to Francis for starting this thread, and Mark and MJ for sticking with it. Also, thank you FL employees (sorry, I can't remember names), for following through.
I think it's important for me to clarify something I said earlier. When I said that something is wrong when even the best of the best here cannot explain it to the most desirous learner, I wasn't putting the emphasis on the "best of the best" (i.e., the people). I was putting the emphasis more by saying, "okay, come on, if these amazing people (i,e, "the best of the best") can't explain it in a way that people who REALLY want to learn can understand," then something is broken because you have excellent teachers matched with students who really want to learn, and it's like there's some sort of chasm.
Someone in another thread said something fantastic. They said that there has to be a bridge between "us" and "them." The gap between those who REALLY known the program's search functions and "the rest of us" who are so frustrated because we know we have all these resources and are stuck in basic search functions (as evidenced by the many "how do you search for this threads), is so wide that something has GOT be done to bridge the gap. So, if in my frustration it came across that I was in any way complaining about the way MJ or Mark (or anyone else here for this matter), was explaining things, that was not at all my intent, and so I want to make sure I clarify myself. I am INCREDIBLY thankful, especially to our MVPs, who work so hard at helping and explaining things, and this thread is a testament to their tenacity in helping! THANK YOU!
Cynthia
Romans 8:28-38
0 -
Mark Barnes said:Francis said:
I could just as well say that in <Bible John 3:16> I am using the Bible to search for John 3:16 which is a Bible reference just as in {Highlight Yellow} I am using Highlight to search for Yellow which is a Highlight colour. In both cases I use a class to search for an instance. This is why I suggested that these terms did not apply as readily to the user defined searchable entities such as labels or highlights although they do apply very well to milestones or sections.
You could say that, but that wouldn't make it correct :-). There's a subtle, but important distinction. To use your terms, when you're searching for <Bible John 3:16> the 'class' isn't "Bible". The 'class' is "datatype reference", and the 'instance' is "bible.64.3.16". ('64' because John is the 64th book of the Bible using Logos' way of counting - which includes apocryphal books).
If we were to express a reference search using search extension syntax (which doesn't actually exist, but makes it easier to compare), it might look something like: {Reference <Bible John 3:16>}
You are using Reference search to search for instances of the Bible reference John 3:16.
Andrew Batishko | Logos software developer
0 -
Francis said:
Data types are specific referents one can find because the resources are encoded with them (a place, a person, a thing). What one finds by searching for a datatype is an instance of this datatype: Abraham is a person, Jerusalem a place, a stone is a thing, etc. As a result, normally* what a data type finds cannot be more than one data type at a time (Abraham is a person, and not a thing, a place, etc) and you cannot find <Thing X> WITHIN <Person Y>.
"normally" indeed [:D]
Try this Bible search: <Thing Fortress> WITHIN <Person God>
You can also find People within People, such as: <Person An Ancestor> WITHIN <Person God>
Andrew Batishko | Logos software developer
0 -
Try this Bible search: <Thing Fortress> WITHIN <Person God>
Thankful for 25 Bibles that have results:
Keep Smiling [:)]
0 -
Mark Barnes said:
That doesn't mean that search shouldn't be made easier. It should. But the way to make it easier is to allow users to construct complex searches without understanding how they work. As the developers have said, the right-click menu is a good way to do that now. A better way, which I'm hoping for in the future, would be a system which would present options for { searches whenever you typed { on the keyboard (in exactly the same way as @ does in a morph search). That would allow people to construct complex queries without having to remember a complex syntax.
Today, I stumbled across a post I wrote last year that explained this idea in more detail, including this mockup:
FWIW, Eli responded:
Eli Evans (Faithlife) said:Coincidentally, we are working on the spec for just such a contraption (though it may look a little different than your mockup since I don't know how much secret knowledge of each label type we'll be able to pump into the software, but we'll see).
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!
0 -
When I started this thread, I could remember vaguely that Devin Roza had posted something helpful on this. I have found it since and I think it is still the best explanation of search extensions I have read so far:
Fr Devin Roza said:The <> is used to indicate a datatype. An introduction to datatypes is here. A relatively complete list of datatypes is here. When you search for a datatype, you are searching for a "reference". The most common type is the <Bible> datatype, where a search like <Bible John 3:16> will find all "references" to John 3:16, regardless of whether they are in a Bible, a commentary, or even if they are within a larger reference, like John 3:10-20. Datatypes also allow for prioritizing resources, so a single datatype reference can open many different resources to the correct place, and show each person the resource they have highest prioritized.
The {} is used for what I like to call "search extensions" (not an official name, BTW, but the best I've found so far, and I don't think there's an official name yet). Each {searchextension} "extends" the functionality of search. Let me try to explain what I mean.
Each "search extension" can have its own search syntax, and can do something entirely different. They are actually analogous to "search tabs", like the Basic, Bible, Morph, Clause, etc. search tab. For example, when you go to the Morph Search tab, when you type g:logos and then @, you will see a dropdown menu with all the morph options. If you do the same thing on the Basic tab, it won't work the same - no morph dropdowns! And the search syntax between the two tabs changes. Each search tab has different functionality, different search syntax, etc.
Well, the {search extensions} offer all of that power - each one can have an entirely different syntax, drop down options, etc. So, instead of creating a lot of new search tabs - one search tab for searching Milestone, another for Speaker, another for Passage Lists, etc. - Faithlife created a new type of search syntax, the {searchextension}.
The great thing about this is that it allows us to use lots of different {searchextensions} together. So we can do great things like search for {Speaker <Person Jesus>} WITHIN {Section <LiteraryType Quotation, Old Testament>} to find all the instances in which Jesus quotes the Old Testament.
The only thing that is missing from it, I think, is the explanation about why {Label Psalms} and {Highlight Yellow} look so much like <Person Abraham> or <Thing Stone> (in that the constant {Label ...} is used to search for the label Psalms, just like the constant <Person...> is used to search for the person Abraham) (contrast with {Milestone <Person Abraham>} in which one must look for something else within the "tab" milestone). I think the explanation may be this (although I would not be surprised if I were told it is inaccurate):
Unlike milestones, sections, etc., which are regions of text defined by logos, labels and highlights are defined by users and so receive a specific identifier. So, you cannot search for section 001 (or at least if it is technically possible it is certainly not upfront to the user) but since one called a label "Psalms", a highlight "yellow" or a passage list "Commandments in the Gospels" one can search for the specific instance(s) of Label = Psalms, Highlight = Yellow etc. as well as using them as "tabs" in which we search for something else as in {Label Psalm WHERE Genre ~ "Praise"}. Nevertheless, this particular property of the user-defined regions of text does not eliminate the fact that these are still extensions designed to work as "tabs" / extend searches.
0 -
"normally" indeed
Try this Bible search: <Thing Fortress> WITHIN <Person God>
You can also find People within People, such as: <Person An Ancestor> WITHIN <Person God>
Thanks, Andrew! It is not only good to get that right, but actually suggestive also of further ways to combine fruitfully different types of searches.
0 -
Francis said:
The only thing that is missing from it, I think, is the explanation about why {Label Psalms} and {Highlight Yellow} look so much like <Person Abraham> or <Thing Stone> (in that the constant {Label ...} is used to search for the label Psalms, just like the constant <Person...> is used to search for the person Abraham) (contrast with {Milestone <Person Abraham>} in which one must look for something else within the "tab" milestone). I think the explanation may be this (although I would not be surprised if I were told it is inaccurate):
Unlike milestones, sections, etc., which are regions of text defined by logos, labels and highlights are defined by users and so receive a specific identifier. So, you cannot search for section 001 (or at least if it is technically possible it is certainly not upfront to the user) but since one called a label "Psalms", a highlight "yellow" or a passage list "Commandments in the Gospels" one can search for the specific instance(s) of Label = Psalms, Highlight = Yellow etc. as well as using them as "tabs" in which we search for something else as in {Label Psalm WHERE Genre ~ "Praise"}. Nevertheless, this particular property of the user-defined regions of text does not eliminate the fact that these are still extensions designed to work as "tabs" / extend searches.
When it comes down to it, all the things you can look for are just "regions" of text, whether you are looking for a phrase or a reference or a block of highlighted text or text spoken by a particular person. All blocks of text have pieces of data that are associated with them. Each type of data has a different format and therefore can require a different syntax to identify.
There are lots of different datatypes, but datatype references all have the same format, so we can use a common syntax to identify them. The key pieces of information we need to identify are the datatype (some like Bible references we can cheat and figure out it's a Bible datatype without having to explicitly specify it) and the exact reference. This syntax is <...>
Highlighting data doesn't look like datatype reference data, so we need a different syntax. The only piece of information we need to identify a highlight is its name. Therefore we have the {Highlight ...} syntax.
Identifying label data requires the label name, and optionally some constraints on the label's attributes. Therefore we have the {Label ...} syntax.
Instead of having {Highlight ...} and {Label ...} and {searchextension ...} we could have come up with unique symbols for each (like ^Yellow^ for a highlight search and %Psalm% for the label search), but we'd probably run out of useful symbols.
The fact that {Label Psalms} and {Highlight Yellow} look similar to <Person Abraham> is actually coincidental. The first two are identifying one piece of information, the name of the label and the name of the highlight. The last is identifying two pieces of information, the name of the datatype and the reference. It's just that Label and Highlight require an extra word to identify the type of search being done, while the datatype reference search has the search type identified by the symbols surrounding the term.
Andrew Batishko | Logos software developer
0 -
Oh, this makes me think of a new way to explain things...
Let's create a completely brand new search language (I'm sure you'll spot some similarities). In this search language we'll try to make all terms use as similar a syntax as possible.
All searches are a term followed optionally by an operator and another term followed optionally by any number of additional operator + term pairs.
Operators are things like: AND, OR, NEAR, etc.
A term looks like: {termtype termvalues}
termtype is one of the following: word, phrase, reference, highlight, label, etc. termvalues vary and depend on the termtype.
Example terms are:{Word heaven} The termvalues here are just the text of the word you are looking for.
{Phrase heavenly father} The termvalues here are the text of the phrase you are looking for.
{Reference Bible John 3:16} The termvalues here are the datatype and the reference (whose exact format is dependent on the datatype specified).
{Highlight Yellow} The termvalues here are just the name of the highlight you are looking for.
{Label Psalms} The termvalues here are the name of the label type, followed optionally by constraints on the label attributes.This new search language behaves exactly like the existing Logos search language. However, some of the terms defined above use a simplified syntax.
Word terms are simplified so that only the text of the word is written. {Word heaven} becomes heaven.
Phrase terms are simplified so that the text is surrounded by quotes. {Phrase heavenly father} becomes "heavenly father".
Reference terms are simplified so that the reference is surround by <>. {Reference Bible John 3:16} becomes <Bible John 3:16>. In fact, for some datatypes (such as Bible) the datatype can be removed too and the term becomes <John 3:16>.
All the other terms remain the same.
Andrew Batishko | Logos software developer
0 -
Late to the party, so just a quick note for anyone who wonders if we (FL) are a) aware that search syntax is too daggum complicated and if b) we intend to do anything about it in the future: Yes and yes.
I'm saving this thread as a design reference because I think it illustrates some key issues pretty well.
0 -
YES!!!
You would not believe it how many times I have thought during the conversation on this thread "Where's Eli when I need him?"
0 -
Francis said:
The only thing that is missing from it, I think, is the explanation about why {Label Psalms} and {Highlight Yellow} look so much like <Person Abraham> or <Thing Stone> (in that the constant {Label ...} is used to search for the label Psalms, just like the constant <Person...> is used to search for the person Abraham) (contrast with {Milestone <Person Abraham>} in which one must look for something else within the "tab" milestone). I think the explanation may be this (although I would not be surprised if I were told it is inaccurate):
Unlike milestones, sections, etc., which are regions of text defined by logos, labels and highlights are defined by users and so receive a specific identifier.
I don't think this quite gets to the heart of the matter. Let me explain how I understand it (which I believe corresponds to what Andrew explains here, in different words).
I find it helpful to think of search extensions as types of searches and datatypes as types of data. I think you've got that pretty clear. But it's also important to keep in mind that even though datatypes are "types of data", there are "types of data" that are NOT datatypes!
What do I mean? The example you give here is a good one.
When I search for {Milestone <Bible John 3:16>}, I'm using a milestone type of search, and I'm searching for a type of data, the Bible type of data, and specifically the Bible reference John 3:16 .
When I search for {Highlights Yellow}, I'm using a Highlights type of search, and am also searching for a type of data! In this case, however, the type of data I'm searching for is not a datatype. It's a highlighting style, and specifically the style Yellow.
So, when you say above,
Francis said:contrast with {Milestone <Person Abraham>} in which one must look for something else within the "tab" milestone
this is imprecise.
In both Milestone and Highlight searches, we must search for something. In the case of Milestone searches, the type of data we're searching for is a datatype. In the case of Highlight searches, the type of data we are searching for is a highlighting style, and we're searching for yellow. In both cases we're running a type of search, and we're searching for something, which is always a something of a certain type of data.
There are many other types of data we search for all the time that are not datatypes, the most common being a text string.
What makes a "datatype" a "datatype" is the under the hood format it has, which is something Faithlife gives it, creates. So, we could imagine someone using "labels" to tag morphological information on the New Testament. We could search on that without using datatypes. Faithlife could then like that Label tagging so much that they decide to transform it into a morph datatype database, and sell it. We could then search for it using datatypes. Either way, the raw data could in theory be the same, just in a different behind the scenes format. The search format would change - in the first case, we could use a Label search without datatypes; in the second case, a Morph search with datatypes. And in both cases, we're using a type of search to find specific types of data.
Of course, this also implies that in theory there could very well be search extensions that accept both datatypes and other types of data as the "something" they are searching for.
Francis said:The only thing that is missing from it, I think, is the explanation about why {Label Psalms} and {Highlight Yellow} look so much like <Person Abraham> or <Thing Stone>
Basically it's because both the search tabs and the search extensions allow "shortcuts".
Every search needs three items to work: (1) type of search (2) type of data (3) data.
Oftentimes one, or even two of these three items is presupposed. This causes the confusing similarities you mention.
So, the search <Person Abraham> supplies 2 and 3, but is missing 1. It works because the search tab supplies the missing (1) type of search, which would be something like {Reference} or {Tag}.
The search {Label Psalms} supplies 1 and 3, but is missing 2. It works because the search extension supplies the (2) type of data. In cases like the Highlights or Label search extension, the type of data is considered always the same, so we don't need to supply it. It's presupposed. Note that it could have been implemented differently. We could imagine the type of data also being required - something like {Highlights Style Yellow}, or {Highlights Palette Solid Colors}.
This applies even to a search like "hello, it's me." The phrase is 3, and 1 and 2 are presupposed. It works because the search tab supplies the missing (1) type of search, which would be something like {Phrase}, and the search tab also presupposes the (2) type of data: text.
And in searches like {Milestone <Bible John 3:16>} the end-user supplies all three explicitly. Although even there, Bible can be omitted, as it is the default datatype and can be presupposed.
Of course, we are really glad we don't have to always explicitly supply type of search, type of data, and data! But it can at times make for some confusion, as the similarities you pointed out.
Hope this helps, sorry for the long answer!
0 -
Gary Mendenhall said:
The only way I'm going to be able to understand how to take advantage of those functions is if I know what they do and how they work. In other words, "what's under the hood", or in your terms, "the mechanics". The problem I was having was mostly in the language/terms being used and my unfamiliarity. Was hoping to gain some insight here but see now that I was wrong and need to glean from another source for knowledge on such a sophisticated subject.
Anyway, I have been in on the pre-pub for the advanced search training videos since it was offered and eagerly waiting for it to go live. Keep up the good work.
Blessings,
Gary
FWIW, my main motivation to do the advanced search training videos was precisely what you express here - to try to help users get to the point where they feel comfortable and confident searching, which I am convinced necessarily includes an understanding of the essentials of what's going on under the hood, of what can be done and how it works. I hope it does the trick for you! These are difficult topics, and it's important we find the right ways to explain and make them understandable.
0 -
Oh, this makes me think of a new way to explain things...
Let's create a completely brand new search language (I'm sure you'll spot some similarities). In this search language we'll try to make all terms use as similar a syntax as possible.
All searches are a term followed optionally by an operator and another term followed optionally by any number of additional operator + term pairs.
Operators are things like: AND, OR, NEAR, etc.
A term looks like: {termtype termvalues}
termtype is one of the following: word, phrase, reference, highlight, label, etc. termvalues vary and depend on the termtype.
Example terms are:{Word heaven} The termvalues here are just the text of the word you are looking for.
{Phrase heavenly father} The termvalues here are the text of the phrase you are looking for.
{Reference Bible John 3:16} The termvalues here are the datatype and the reference (whose exact format is dependent on the datatype specified).
{Highlight Yellow} The termvalues here are just the name of the highlight you are looking for.
{Label Psalms} The termvalues here are the name of the label type, followed optionally by constraints on the label attributes.This new search language behaves exactly like the existing Logos search language. However, some of the terms defined above use a simplified syntax.
Word terms are simplified so that only the text of the word is written. {Word heaven} becomes heaven.
Phrase terms are simplified so that the text is surrounded by quotes. {Phrase heavenly father} becomes "heavenly father".
Reference terms are simplified so that the reference is surround by <>. {Reference Bible John 3:16} becomes <Bible John 3:16>. In fact, for some datatypes (such as Bible) the datatype can be removed too and the term becomes <John 3:16>.
All the other terms remain the same.
OH MY GOODNESS!!!N HOLD THE PRESSES!!!!
THIS ENTIRE POST MADE SENSE TO ME!!!! AS IN...
-----------EVERY
---------------------SINGLE
---------------------------------WORD!!!
EUREKA, I THINK I'VE GOT IT! (Or at least...I'm STARTING to! [:)]
Cynthia
Romans 8:28-38
0 -
Eli Evans (Faithlife) said:
Late to the party, so just a quick note for anyone who wonders if we (FL) are a) aware that search syntax is too daggum complicated and if b) we intend to do anything about it in the future: Yes and yes.
I'm saving this thread as a design reference because I think it illustrates some key issues pretty well.
Cynthia
Romans 8:28-38
0 -
Thank you Fr Devin Roza; its worth a lot. I'm looking forward to the training video release. I was a little concerned with Eli Evan's post a little earlier in this thread regarding Faithlife's being aware of the need for change in the search syntax. I may be borrowing trouble from the future but my concern is that future changes may negate some of the knowledge gleaned from your training videos. How frustrating it would be to finally gain knowledge and aptitude with the task of proper searching technique and then soon have it all dashed away with a completely revamped system. Knowing the inevitability and necessity of change I find it harder and harder to adapt in my older years [:^)] Well, I'm not going to let my mind wander any further into what isn't, try to stay focused on what is, and continue to look forward to your videos. Thanks again for filling this need for clarity.[:)]
Blessings to you,
Gary
0 -
Gary Mendenhall said:
How frustrating it would be to finally gain knowledge and aptitude with the task of proper searching technique and then soon have it all dashed away with a completely revamped system.
I'd be 99% certain that whatever Faithlife introduce, it won't replace the existing syntax, but complement it. Or more likely, it will be a way of generating the syntax without having to remember it. Power users would be up in arms if all our existing searches stopped working.
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!
0 -
Reassuring, Thanks Mark.
0 -
Mark Barnes said:Gary Mendenhall said:
How frustrating it would be to finally gain knowledge and aptitude with the task of proper searching technique and then soon have it all dashed away with a completely revamped system.
I'd be 99% certain that whatever Faithlife introduce, it won't replace the existing syntax, but complement it. Or more likely, it will be a way of generating the syntax without having to remember it. Power users would be up in arms if all our existing searches stopped working.
Quite so. If you'll indulge me in a little bit of historical contextualization, this is exactly why we have <...> and {...} today.
The last time we redesigned Search was for L4. Some syntax changes happened then, but they were relatively minor. Since then, we've built upon that foundation without changing it very much.
L5 introduced several new datasets, but they weren't searchable. (Remember how much less useful Bible Sense Lexicon was when you couldn't search the Bible for a given sense?)
Part of the mandate for L6 was to make L4 and L5 datasets searchable, as well as introducing a plethora of new datasets, plus a platform for multiplying datasets like the wind (Labels and Supplemental Datasets).
To fulfill that mandate, we decided to:
- Extend, not replace, the existing company investment in Search technology.
- Leverage, not sweep away, the existing user investment in Search syntax.
- Maintain our commitment to precise searching (perhaps too much at the expense of simplicity).
- as a result, create a multitude of heterogenous search types rather than shoehorning everything into the one monolithic search type.
The result of those guidelines was We had a choice between extending the <...> syntax so that its grammar (ie, what is considered valid within the brackets) was overly complex and potentially ambiguous, or to invent some new system for embedding multiple types of search (I agree that's a good way to explain it) within the same query. So {...} was born.
So L6 represented a quantum leap forward in both search capability and search syntax complexity.
L7 made only modest/incremental improvements on that front: Better autocomplete suggestions, more cookbook entries, and expanded help documentation. We also made some baby steps toward merging Morph and Bible search types together (ie, you can now set morph scheme at the term level instead of only at the query level).
L7's Bible Browser is, to some extent, a way to sidestep the issue by creating a simple point-and-click UI for finding things by browsing rather than by searching (by gathering rather than by hunting).
L8, I hope, goes further in the direction of Google-ness when you want it (probably in Everything and Basic search, with undecorated terms like Judah being a catch-all cross-dataset cross-datatype matching term instead of a limited text-only search that they are today) for those who are willing to sift through more results that include more false positives (and perhaps refine their query further after the fact, or click on a "Did you mean [someething more precise]" link at the top of the results) while retaining the mathematically precise searching with term decorations <{!":- !!! for those who want the ability to specify precisely what they're looking for before the fact to get a more exact set of results. (Standard disclaimers about talking about the future apply.)
We have open tasks to add more everything to the "Everything" search. (These jokes about "everything" bagels apply. Warning: Some cussing, because that's what our culture is like, sadly. http://kottke.org/11/01/the-hilarious-everything-bagel )
Additionally, we may explore more GUI-intense ways of making complex/specialist queries. The Morph Query grid-based UI that's currently in beta/Logos Now is an overture in that direction.
0 -
This example, though, brings up another question. Why does "Bible John 3:16" need to be inside <> but in the previous {Highlight Yellow} example, "Yellow" does not. That aspect of difference in search syntax has been confusing to me.
Donnie
0 -
Fr Devin Roza said:
I find it helpful to think of search extensions as types of searches and datatypes as types of data. I think you've got that pretty clear. But it's also important to keep in mind that even though datatypes are "types of data", there are "types of data" that are NOT datatypes!
[...]
Every search needs three items to work: (1) type of search (2) type of data (3) data.
Oftentimes one, or even two of these three items is presupposed. This causes the confusing similarities you mention.
So, the search <Person Abraham> supplies 2 and 3, but is missing 1. It works because the search tab supplies the missing (1) type of search, which would be something like {Reference} or {Tag}.
The search {Label Psalms} supplies 1 and 3, but is missing 2. It works because the search extension supplies the (2) type of data. In cases like the Highlights or Label search extension, the type of data is considered always the same, so we don't need to supply it. It's presupposed. Note that it could have been implemented differently. We could imagine the type of data also being required - something like {Highlights Style Yellow}, or {Highlights Palette Solid Colors}.
Thank you. To be honest, I understand that better than: You search for datatype references, you search using search extensions.
Thanks everybody for trying to explain this to us.
0 -
Mark Barnes said:
I like this a lot, for two reasons:
1. It helps immensely to put together the right search syntax
2. It reminds me of other things and ways, or other attributes that can be searched for.
And let me give a third reason that comes to my mind: It keeps all the different searches and their syntaxes in one place
[Y]
0 -
Donnie Hale said:
This example, though, brings up another question. Why does "Bible John 3:16" need to be inside <> but in the previous {Highlight Yellow} example, "Yellow" does not. That aspect of difference in search syntax has been confusing to me.
Yellow does not go in <> because it's not a data type reference. It's just a string, specifically the name of a highlighting style.
This post tries to explain: https://community.logos.com/forums/p/131253/854783.aspx#854783
Andrew Batishko | Logos software developer
0 -
Donnie Hale said:
This example, though, brings up another question. Why does "Bible John 3:16" need to be inside <> but in the previous {Highlight Yellow} example, "Yellow" does not. That aspect of difference in search syntax has been confusing to me.
Donnie
I have that same question!
Cynthia
Romans 8:28-38
0 -
Fr Devin Roza said:
Every search needs three items to work: (1) type of search (2) type of data (3) data.
I think this is the second most helpful point in this thread, after Mark's "search for" vs. "search using" point. It's the synopsis of Andrew's not-so-hypothetical new search syntax.
Donnie
0 -
Donnie Hale said:Fr Devin Roza said:
Every search needs three items to work: (1) type of search (2) type of data (3) data.
I think this is the second most helpful point in this thread, after Mark's "search for" vs. "search using" point. It's the synopsis of Andrew's not-so-hypothetical new search syntax.
[Y]
Thanks to FL for including Carta and a Hebrew audio bible in Logos 9!
0 -
Donnie Hale said:
I think this is the second most helpful point in this thread, after Mark's "search for" vs. "search using" point. It's the synopsis of Andrew's not-so-hypothetical new search syntax.
This thread is a MASSIVE help in understanding Logos' search infrastructure. Even hearing Eli's explanation of the journey in how the Search terms were improved across versions is insightful and very telling for the future (L8 and future LN releases, fingers crossed). Kudos to Francis for starting AND for Pressing the issue to create this conversation. It's nice seeing people put to words the questions I did not know how to properly articulate. (I did not know the things that I did not know. LOL.)
These posts have made me begin to feel empowered to create things like labels, tags, highlights, etc. in my books and resources. I feel like I can now PURPOSEFULLY use them in order to have access to them at later dates. Keep it coming!!
MBPro'12 / i5 / 8GB // 3.0 Scholars (Purple) / L6 & L7 Platinum, M&E Platinum, Anglican Bronze, P&C Silver / L8 Platinum, Academic Pro
0 -
Now all we need is for MJ to extract the best bits from this thread into a nice TIP OF THE DAY.
Wonder if she would keep <{~":- !!! as the subject of the TIP...
Peter
0 -
Yellow does not go in <> because it's not a data type reference. It's just a string, specifically the name of a highlighting style.
Or... Is it a data type reference to a "Text" data type, the equivalent of {Highlight <Text Yellow>}? (I hope I'm close to right here - along the lines of Andrew's not-so-hypothetical new search syntax...
Donnie
0 -
Donnie Hale said:
Yellow does not go in <> because it's not a data type reference. It's just a string, specifically the name of a highlighting style.
Or... Is it a data type reference to a "Text" data type, the equivalent of {Highlight <Text Yellow>}? (I hope I'm close to right here - along the lines of Andrew's not-so-hypothetical new search syntax...
Not really equivalent. If you want to compare things, it would be (note that the right side below is imaginary):
<Bible John 3:16> is like {Reference WHERE DataType=Bible AND Reference=John 3:16}
{Highlight Yellow} is like {Highlight WHERE Name=Yellow}Yellow is a Name. John 3:16 is a Reference. They are attributes of the data, and any further similarity is going to be coincidence.
Andrew Batishko | Logos software developer
0 -
PL said:
Now all we need is for MJ to extract the best bits from this thread into a nice TIP OF THE DAY.
Some was included in the TIP of the day: Best answers of the week. More will be revealed within the next few days depending upon how much time I have available ..
Orthodox Bishop Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship."; Orthodox proverb: "We know where the Church is, we do not know where it is not."
0 -
Yellow does not go in <> because it's not a data type reference.
This really matters. For anyone trying to reformulate what's Andrew/Bradley/I have said, you can't avoid distinguishing between "datatype reference" and "not a datatype reference". That really matters.
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!
0 -
This thread has been USEFUL. However, the eagle has not quite landed yet. What I perceive from the ongoing interaction here is that on the one hand, we have folks who know what these searches are technically. On the other hand, there is ongoing feedback that shows that these more technical answers are not regarded as sufficiently accessible, easy to grasp, remember, and use.
I think we have much greater clarity over datatypes searches as reference searches. I prefer personally to use the word referent because for many, the word reference conjures up Bible references or footnotes, but not so much the idea that "Sarah's husband" refers to "Abraham". But "Sarah's husband" is a referent to the person Abraham. These searches use <...> as syntax.
It is not completely useful to say that extension searches are not datatype searches because there are other types of searches that are not datatype searches but are not extension searches either (like a simple text search). It may say what extensions are not, but it does not say what they are.
It is useful to say that extension searches are different kinds of searches we can use to search and only look at time similar to datatype searches because the syntax has been abbreviated and obscures how the two type of searches are distinct in cases such as {Label Psalms} or {Highlight Yellow}.
Perhaps if syntax was consistently applied (but might become more cumbersome) we would have one syntax for them all:
<Person Abraham> would be {Referent <Person Abraham>} meaning I am looking for a referent. To what? A person. To whom? Abraham.
{Highlight Yellow} would be {Highlight <Colour Yellow>} meaning I am looking for a highlighted text. What kind? A colour. Which colour? Yellow.
Instead, we're supposed to know and remember that <...> imply that it is a reference search. And that {...} are different types of searches (not unlike the tabs "morph" "syntax" "clause" in the search pane).
Every attempt I have made so far to reformulate has not been adequate and perhaps this one will not be either. But then I would invite the techies to do it (as opposed to saying it cannot be done) recognising that (1) if what you deem simple has not cleared the confusion it is obviously because it is not as clear as you think or is still somewhat fuzzy definition; (2) considering the following of this thread and what the non-techies have said, the need is there and should not be denied; (3) obviously the fine-tuning and brainstorming has born fruit (showing it can be done): all we need now is an accessible summary if the above won't do.
0
