(Untitled)

Ok, I know it looks like perhaps a swear word, but it is not, and it got your attention. I am inviting the forum illuminati Wink to provide a short guide to these elements of search syntax: <...>, {...}, ~ "...", and I think I have seen in some cases - used as well. Let's keep out excessive technical answers/jargon and provide easy to remember guidelines.

For instance, <...> what do I use it for? Without having to necessarily memorise all the different types of data that can be mined, what would be a helpful question I can ask myself about what I am looking for that will help me determine when I need to use <...> and when I need to use {...}?

The idea here is to keep users from being constantly dependent on others to know how to formulate search syntax correctly (or to have to look it up).

Bring up the goods! Remember please keep it to the point and practical.

Find more posts tagged with

Comments

Graham Criddle

<...> is used for datatype searching - for searching within a dataset

{...} is used for extending regular search capabilities and do not require additional datsets

This is outlined at https://wiki.logos.com/Search_HELP#New_Datatypes

Francis - does this adequately answer your question?

Yasmin Stephen

Ok, I know it looks like perhaps a swear word, but it is not, and it got your attention.

What's this??? [:P] (On a serious note, I have no problem with this; I actually like enigmatic titles [:)])

To get back on topic, I appreciate this request, and would like to suggest that examples be given as well (maybe a couple, ranging from simple to more complex?).

Mark Barnes

Graham' reply is correct. If you want a more general rule, generally datatypes (e.g. <>) will represent individual points of data, whilst the special searches (e.g. {}), will tend to identify longer sections.

Francis

https://community.logos.com/discussion/comment/854136#Comment_854136

What's this???

Touché! [:D]

Francis - does this adequately answer your question?

No, Graham. What there is on this page is precisely what I do not want: mostly prescriptions and little in term of elucidation (at best one must wrestle with the clues in that section in order to make sense of things). I find that info tends to go from mere prescriptivism to utter technical jargon. Think "for Dummies" as an approach, not so dumb as the title suggests, but made easy to understand and put to use.

If you want a more general rule, generally datatypes (e.g. <>) will represent individual points of data, whilst the special searches (e.g. {}), will tend to identify longer sections.

This is a guideline, but it is still too vague. For instance, based on your proposed explanation, I can readily understand <Bible John 3:16> as pointing to an "individual point of data". BUT to say that {...} will tend to identify longer sections does not help much as one compares <Bible John 1:1-19:1> with {Section... } or {Milestone...}. John 1-19 refers to a long section, but <...> still applies. Alternatively, even if I had only one word highlighted in my entire library, I would still need to use {Highlight...} to search for it (although it is not "a longer section").

Cynthia in Florida

Ok, I know it looks like perhaps a swear word, but it is not, and it got your attention. I am inviting the forum illuminati to provide a short guide to these elements of search syntax: <...>, {...}, ~ "...", and I think I have seen in some cases - used as well. Let's keep out excessive technical answers/jargon and provide easy to remember guidelines.

For instance, <...> what do I use it for? Without having to necessarily memorise all the different types of data that can be mined, what would be a helpful question I can ask myself about what I am looking for that will help me determine when I need to use <...> and when I need to use {...}?

The idea here is to keep users from being constantly dependent on others to know how to formulate search syntax correctly (or to have to look it up).

Bring up the goods! Remember please keep it to the point and practical.

I swear I could have written everything above...word for word! Thanks for this question!

Cynthia in Florida

https://community.logos.com/discussion/comment/854151#Comment_854151

[

Francis - does this adequately answer your question?

No, Graham. What there is on this page is precisely what I do not want: mostly prescriptions and little in term of elucidation (at best one must wrestle with the clues in that section in order to make sense of things). I find that info tends to go from mere prescriptivism to utter technical jargon. Think "for Dummies" as an approach, not so dumb as the title suggests, but made easy to understand and put to use.

Francis! I swear it's like you're in my head!

Edited to add: I particularly like the Think "for Dummies" as an approach comment. The truth is, it's not insulting. It's a hard fact and those of us who KNOW that we don't know, know that references to "put this around for a datatype" (or whatever that said) are asking two questions: 1) WHAT THE HECK IS A DATA TYPE and 2) WHY would I use it for a data type set. (Again, I don't even know if that's the technical name but I don't even know what it is, regardless of what it's called. My point is this. If we can't understand the question, how in God's green earth are we going to understand the answer!?

Mark Barnes

https://community.logos.com/discussion/comment/854151#Comment_854151

This is a guideline, but it is still too vague. For instance, based on your proposed explanation, I can readily understand <Bible John 3:16> as pointing to an "individual point of data". BUT to say that {...} will tend to identify longer sections does not help much as one compares <Bible John 1:1-19:1> with {Section... } or {Milestone...}. John 1-19 refers to a long section, but <...> still applies. Alternatively, even if I had only one word highlighted in my entire library, I would still need to use {Highlight...} to search for it (although it is not "a longer section").

You need to be thinking about what searches will return (as we're talking about search syntax).

If you search for <Bible John 1:1-19:1>, each result will be an individual point of data (e.g. John 3:3, John 18:1-25, John 19:1, etc.), and you'll see the search highlights dotted about resources. The same is true for almost any other datatype search.

On the other hand, special searches will tend to return long sections, often with whole paragraphs highlighted.

Francis

https://community.logos.com/discussion/comment/854165#Comment_854165

You need to be thinking about what searches will return

That's promising.

On the other hand, special searches will tend to return long sections, often with whole paragraphs highlighted.

Okay, so to help make this clearer yet, can you explain the difference between the results of the two following searches (both return a highlighted paragraph/section) in the snapshot below and relate it to the role of < > and { } in each?

Thanks, Mark, your contributions are appreciated, as always (as well as Graham's).

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/854151#Comment_854151

The <...> syntax was introduced in Logos 4 to differentiate textual queries from data type reference queries.

How are the following queries different?

John 3:16
"John 3:16"
<John 3:16>

The first finds articles that have both ‘John’ and ‘3:16’ somewhere in the article. The second finds those two terms, but requires them to be adjacent, i.e., an exact phrase. The third uses Logos’ data type reference technology to find text that has been tagged with the Bible reference Jn 3:16; this might include “John 3:16”, “Jn III. 16”, “see v.16”, “16”, etc. And by default, it also finds intersecting references, so it'll match John 3:16–18, John 3:1–16, etc. (This can be customised by specifying an operator, e.g., <=John 3:16>.)

For more on data type reference searching, see:

The {...} syntax was introduced in Logos 6 for “search extensions”. These are hard to describe briefly, because each one can be implemented quite differently; in fact, their purpose is to extend the search engine by finding data that isn't stored in the full text index. As a result, you probably have to learn each one individually; there isn't usually a general rule that applies to all of them. (FWIW, {...} was chosen because we needed a way to differentiate these from “regular” queries and those characters weren't already in use.)

{Milestone <Reference>} — uses a resource’s milestone index (unrelated to the full text index) to find the portion of a resource that's tagged as a milestone for the given reference. Use normal data type reference syntax to specify the reference.
{Speaker <Reference>} / {Addressee <Reference>} — uses the Reported Speech dataset to find original language or reverse-interlinear-aligned text tagged as reported speech. Use data type reference syntax to specify the person or thing that's speaking.
{Highlight Palette/Style} — uses your notes to find text marked with the specified highlighting style
{PassageList Name} — performs a data type reference search for all of the passages in a specified passage list
{Label query} — provides a mini SQL-like language for finding label references; the matched references may come from supplemental data resources, label tagging inside resources themselves (this actually does come from the full text index), labels attached to your own highlights. Implemented as a search extension because it specifies a query for finding many matching label references.
{Section ...} — perhaps one of the most “vague” extensions. Uses supplemental data resources to find results from datasets that can be purchased for Logos 7. Consult the corresponding dataset documentation for specific details.

Andrew Batishko

I'll take a shot.

< > indicates that your are search for a reference to something. Rather than looking at the text in the resource, this search looks for special tags that Faithlife has added to the resource indicating that the text refers to a particular thing. The things that are tagged are extremely broad. The easiest way to learn about these are to right-click on some text in a resource. Selecting many of the items on the right side of the menu and then selecting "Search all resources" on the left side will generate a search using this syntax. The search syntax indicates the type of thing being looked for, an optional symbol you can ignore for now, and the exact reference you are searching for. By right clicking in a Bible, I can generate the following searches:

<Place Midian (region)> is searching for text that has a "Place" tag indicating it is the region of Midian.
<LogosMorphHeb = NP-SA> is search for text that has a "hebrew morphology" tag indicating singular absolute proper noun.
<Lemma = lbs/he/מִדְיָן:2> is a search for text that has a "lemma" tag indicating that the word has a lemma of lbs/he/מִדְיָן:2

The problem with these is that you really can't manually build these searches until you are familiar with the type of data you are searching for, so unless it's a reference to a Bible passage you are looking for, just build them with the right click menu.

{ } doesn't really have any special meaning. What is significant is the first word you find after the opening {. This word indicates what kind of search is being made, and defines the parameters that need to be used. If you want to keep things simple, don't worry about it. Instead, build your search by right clicking on something that you want to search for, select the appropriate type of data on the right side of the menu, and then chose the search on the left side. This generates the search without having to worry about the syntax. More examples from the Bible:

{Section <PreachingTheme = Clothing>} is searching for a Section of text that is marked with a PreachingTheme tag (note the similarity to the syntax above) indicating the theme of clothing.
{Label Longacre Genre WHERE Primary ~ <LongacreGenre Expository: What things will be like>} is searching for text where a Longacre Genre Label has been added where the label has a primary... meh... it search for places that talk about what things will be like.

See how those really get to complicated to explain simply? Don't worry about them. Just right click and search.

If you rely on the right click menu technique to build your searches, then you only need to learn about how to connect multiple searches together to find places where tagging overlaps each other (for example, finding a certain morphology that is also in a section marked with the clothing preaching theme.

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/854170#Comment_854170

Okay, so to help make this clearer yet, can you explain the difference between the results of the two following searches (both return a highlighted paragraph/section) in the snapshot below and relate it to the role of < > and { } in each?

For the <PreachingTheme Wealth> search, that entire paragraph/article was tagged as a "reference" to that preaching theme. In my mind, this is incorrect tagging (and I've reported it to Content Production as such). It probably wasn't noticed because Preaching Theme data type references aren't hyperlinked by default. We'd actually like to make them hyperlinks now, but doing so would turn that entire article into a link, which isn't ideal. (This is a problem we're working on.)

Reference tagging in resources should generally be limited to a word or short phrase, which is why Mark contrasted them to "long sections".

For the {Section <PreachingTheme Wealth>} search, results are coming from some dataset (I don't remember which one) that links preaching themes to Bible references (probably at a pericope level). This will highlight large portions of text and is more useful for a WITHIN or INTERSECTS query, e.g., searching for “work” within passages tagged with the "Wealth" preaching theme.

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/854171#Comment_854171

Consult the corresponding dataset documentation for specific details.

Or as Andrew said, right-click text and let the software build the query.

https://community.logos.com/discussion/comment/854176#Comment_854176

Thank you Francis for the question, and thanks Bradley and Andrew for the answers.

For those of us (users) who don't (and shouldn't need to) understand the underworkings of the software, the distinction between <> and {} seem rather arbitrary.

E.g. Why does Place use <> while Speaker / Addressee use {} just from a commonsense, non-techie point of view? They both seem to be invisible, human-curated tags Faithlife added to enrich the text.

I can understand when the <> syntax was introduced; it made sense - you're searching for the invisible markings added by Faithlife. It's a distinction between the visible text and the invisible attributes about the text. When {} was introduced, I never understood why there's a need for a third kind of search syntax.

Are there plans to simplify / streamline / merge these at some point in the future?

Are we going to get Google style natural-language search in Logos anytime soon? (e.g. "all places where Jesus talks to God in the gospels")

Thanks,

Peter

Mark Barnes

https://community.logos.com/discussion/comment/854190#Comment_854190

E.g. Why does Place use <> while Speaker / Addressee use {} just from a commonsense, non-techie point of view? They both seem to be invisible, human-curated tags Faithlife added to enrich the text.

From a non-techie point of view, I've answered that above.

If you search for a place, you'll expect to get individual points of data in return. Search results will match single words (e.g. Jerusalem), or occasionally very short combinations of words (e.g. Kiriath Jearim).

If you search for {Speaker XXX}, you'll expect to get phrases and sentences in return, occasionally whole chapters.

Francis

https://community.logos.com/discussion/comment/854190#Comment_854190

Thank you to you both Bradley and Andrew. It is helpful to process these explanations and seek to find greater clarity from them.

A bit of feedback on certain aspects of the explanations, which perhaps may be a suggestion to move in time toward more of a user-oriented than in-house oriented typology of search syntax terms. It is not very helpful for the user to have, for instance, a differentiation between what is included in a full index and what is not, because this is under the hood, and in any case, too techie for most. It seems to me that the primary goal of search syntax terms should be to facilitate power usage of the software, and so, ideally, it would be great if there were efforts toward making the system clearer (even though, as I am sure, certain aspects were developed over time and time added unforeseen complications).

To return to <...> vs. {...}, the suggestion to use the context menu is a starting point, but not more than that. Using the context menu, I can generate a search such as {Section <PreachingTheme = Adoption>} from Romans 9:3 but understanding of what would happen if I just kept <PreachingTheme = Adoption> does not follow. The object of this thread is to enable users to have a better understanding of how to construct complex searches.

I am wondering if the following statement would be accurate:

<...> will search and find entities that can be identified by a word or short phrase (e.g., Abraham, Balaam's Donkey). The search will return places that correspond to that entity (e.g., "he" or "him" where the person Abraham is intended and <Person Abraham> is what is searched).

{...} is used to locate entities that are not inherently tied to one single word or short phrase but are more true of a section of text as a whole, like a characteristic or property. For instance, text divides into sections. I can search sections with { }. I can apply highlighting to the text (it becomes a property). I can apply a label. A paragraph or more may have a theme (e.g., preaching theme). The theme or the label are not intrinsically limited to a short term like the <...> entities. A highlight could be applied to a single word, but intrinsically does not have to. It is a property. A milestone indicates a property of the whole text, where the text as a whole could be characterised as "this text is about..." (such as a Bible reference). These can only be found, of course, where they have been tagged or are defined by user choices such as adding a highlight or a label.

Hence, <Preaching Theme> would return a location which is a preaching theme (like the title of a sermon, or a heading that indicates the theme such as "theme: the Kingdom of God"). {Section <Preaching Theme>} would return a section of which the following is true: it is about that preaching theme even if that section does not have a short title that would be found by <Preaching Theme>.

As a result, one can search for a <...> (because it is narrow) into a {...} because it is broad.

Mark Barnes

https://community.logos.com/discussion/comment/854190#Comment_854190

E.g. Why does Place use <> while Speaker / Addressee use {} just from a commonsense, non-techie point of view? They both seem to be invisible, human-curated tags Faithlife added to enrich the text.

From a more technical point of view, the tagging for datatypes (searched for using < >) are stored directly in the resource. So if you're searching for

{ } searches are much more powerful for several reasons.

First, they're stored in separate datasets, which means they can be applied to multiple resources. For example, {Section <Culture = Marriage>}, you'll get results from more than 350 resources. None of those 350 resources have been tagged for the Culture datatype. But there's a separate Cultural Concepts dataset that knows (for example), that Genesis 29:22 is a reference to marriage. When you search for {Section <Culture = Marriage>} Logos is looking at the Cultural Concepts dataset, finding all the references that match, then searching all your other resources for those references. It's a great way of extending search capabilities without the expense of tagging hundreds of resources. There are exceptions to this, {Milestone} being the most obvious example.

Second, you're usually able to search for datatypes as part of a search extension, so you can do things like:

{Milestone <Bible Jn 3:16>}
{Speaker <Person God>}

Third, they're expandable by the developers. Each search extension can support its own syntax:

{Label Journal Article WHERE Author ~ "F. F. Bruce" AND Date ~ <Date 1980>}
{Label Figure of Speech WHERE Description ~ "Exchange of Cases" AND Name ~ "Antiptosis"}

For those of us (users) who don't (and shouldn't need to) understand the underworkings of the software, the distinction between <> and {} seem rather arbitrary.

I agree with this, and the honest answer is you don't need to understand it all, just like you don't need to understand how your car works to drive it.

But if you want to do complex searches (and we all do), then we need a relatively complex syntax. Simplifying that syntax would be a big mistake, because we'd gain nothing, just lose the ability to perform complex queries. (And we wouldn't gain the ability to perform simple queries, because we already have that. You can ignore { }, and even < >, and you have simple queries.)

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.

Cynthia in Florida

https://community.logos.com/discussion/comment/854203#Comment_854203

As a result, one can search for a <...> (because it is narrow) into a {...} because it is broad.

I'm closely following this thread....and EUREKA, I think that with that ONE line above (in the context of everything else, of course), I GOT IT!

Mark Barnes

https://community.logos.com/discussion/comment/854203#Comment_854203

A bit of feedback on certain aspects of the explanations, which perhaps may be a suggestion to move in time toward more of a user-oriented than in-house oriented typology of search syntax terms.

I agree with this.

{Section <PreachingTheme = Adoption>} from Romans 9:3 but understanding of what would happen if I just kept <PreachingTheme = Adoption> does not follow.

I agree, and that's due to inconsistent tagging, as Bradley explained earlier. Either:

<PreachingTheme> shouldn't be searchable, or
The only thing tagged as <PreachingTheme = Adoption> would be the something like: "See also: Adoption".

I am wondering if the following statement would be accurate:

Everything I said was an attempt to give a simple, two-sentence concept which you can easily remember and put into practice. What I said is generally true, it's not a definition. IMO your definition adds complexity without improving accuracy, because it's trying to make a general principle into an absolute statement, which isn't going to work.

Francis

https://community.logos.com/discussion/comment/854208#Comment_854208

Everything I said was an attempt to give a simple, two-sentence concept which you can easily remember and put into practice.

Thanks, Mark. I don't claim that what I proposed was more accurate. This is why I asked for feedback. But I am striving for something some of us would better be able to relate to. I do not find what you proposed easy to put into practice because it remains blurry and so, not really dispelling my confusion. Too much of this is either vague or technical mumbo-jumbo. It is not criticism of you: as I said I am grateful for your help. At this point, what I have is still more concrete to me than what you proposed. But if you tell me what is wrong with it, I can try to refine it.

Cynthia in Florida

https://community.logos.com/discussion/comment/854205#Comment_854205

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.

MARK! I think that this is, by far, the best suggestion yet! The morph search, to me, is what I would think would be the most difficult to search, yet because of the way it is laid out, it is the easiest, and therefore one I use a lot! However, I also love that I can SEE the query, and therefore use it in another window when necessary.

This is a fantastic suggestion!!!

Mark Barnes

https://community.logos.com/discussion/comment/854229#Comment_854229

Too much of this is either vague or technical mumbo-jumbo.

I accept that, and that's my point really. 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.

But if you tell me what is wrong with it, I can try to refine it.

What's wrong with it is that it's built on an approximation. That's fine for a simple explanation, but probably insufficient for something more detailed.

As a minimum, I would suggest that you're not going to be able to define this difference until you are sure you understand what a datatype and a datatype reference is. They're both defined simply in the Logos help file under Glossary.

When you're searching for < >, you're searching for datatype references, so if you can define a datatype reference, you can define that search. Once you've done that, it will probably immediately clear that { } searches are NOT searches for datatype references, and I think you'll be able to articulate the difference much more clearly.

I hope that's helpful. I'm happy to try and answer questions about datatypes and datatype references if you need more info.

Simon’s Brother

https://community.logos.com/discussion/comment/854234#Comment_854234

Thanks Francis for the question and thanks Bradley, Andrew & Mark for taking time out to work through the question. Your answers were helpful.

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/854203#Comment_854203

I am wondering if the following statement would be accurate:

No, it is not.

<...> is used to find data type references. These are a core concept of the Logos digital library, and it will be hard to understand and formulate complex searches until you understand what a data type reference is, and when and why you would want to search for one. As Mark said, consult the glossary in the Logos help file.

{...} is used to find... well, other things. As the name “search extension” implies, they extend the search engine in various ways. Some of them, such as the {Milestone} search extension, use data type references; others don't. Each one is different and there's not a simple way to summarise them other than: they return results that aren't simply textual terms or data type references.

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/854190#Comment_854190

Are there plans to simplify / streamline / merge these at some point in the future?

Are we going to get Google style natural-language search in Logos anytime soon? (e.g. "all places where Jesus talks to God in the gospels")

We would definitely like to make advanced searches easier. This probably (probably! no promises [:)]) won't be by defining a new, simpler, query syntax but by making our advanced data sets easier to query in a more point-and-click fashion. If you're a Logos Now subscriber, try Bible Browser. I found 44 results for that query with just a few clicks and no complex syntax.

(By "places" I think you meant "passages", but if you actually meant "physical locations", then that's in Bible Browser too.)

MJ. Smith

https://community.logos.com/discussion/comment/854240#Comment_854240

Somewhere in this thread two points should get made:

if you are going to ask complex questions, you should expect to need complex search argument
for many people, the way to learn the complexities of the search is not definitions but practice, practice, practice ... don't just use the right click; read what it has built

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/854244#Comment_854244

I found 44 results

(If you try this, you'll find that 3 are false positives due to nested reported speech: Jesus repeating what a Pharisee addressed to God.)

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/854244#Comment_854244

I realised after posting the screenshot that it only shows direct reported speech. If you want to find instances of Jesus praying, then Person: Jesus + Sense: to pray (petition) will bring a different selection of results.

Simon’s Brother

https://community.logos.com/discussion/comment/854245#Comment_854245

for many people, the way to learn the complexities of the search is not definitions but practice, practice, practice ... don't just use the right click; read what it has built

Very important starting point to understanding searches.

Cynthia in Florida

https://community.logos.com/discussion/comment/854240#Comment_854240

I am wondering if the following statement would be accurate:

No, it is not.

<...> is used to find data type references. These are a core concept of the Logos digital library, and it will be hard to understand and formulate complex searches until you understand what a data type reference is, and when and why you would want to search for one. As Mark said, consult the glossary in the Logos help file.

{...} is used to find... well, other things. As the name “search extension” implies, they extend the search engine in various ways. Some of them, such as the {Milestone} search extension, use data type references; others don't. Each one is different and there's not a simple way to summarise them other than: they return results that aren't simply textual terms or data type references.

...and we're back at square one!

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/854267#Comment_854267

...and we're back at square one!

Not exactly [;)]

"Square one" was "I don't know what any of these symbols mean".

Hopefully you're now at: I've learned that data type references are important for advanced searching; now I need to learn what those are.

[:)]

Cynthia in Florida

https://community.logos.com/discussion/comment/854245#Comment_854245

Somewhere in this thread two points should get made:

if you are going to ask complex questions, you should expect to need complex search argument

for many people, the way to learn the complexities of the search is not definitions but practice, practice, practice ... don't just use the right click; read what it has built

I'm not really too sure of the meaning behind your words (if there is any) or whether you meant to be ironic, but I think the opposite is true here. Francis asked for a simple answer. I don't think the intent was complexity, but what this research HAS revealed is that there is a problem when the best of the best here cannot explain how to search to even the most desirous learner. Secondly, while I agree that we shouldn't just right click but read what is built, the question becomes WHY. For instance, if I right click something and say...it comes out in French, what good is it if I don't know French, or even the letters or sounds. See what I mean?

Something else this thread has taught me is that perhaps I'm not a dumb as I thought I was in this regard, as I have TRIED and TRIED and TRIED to learn how to search ever since I got this software back on Logos 3. When we are told that {...} is used for "well...other things," without specificity, clearly something needs to be done to teach the non-techie average user.

And...in my best Forrest Gump voice I say, "And that's all I have to say about that!"

PetahChristian

https://community.logos.com/discussion/comment/854268#Comment_854268

Not exactly

"Square one" was "I don't know what any of these symbols mean".

Hopefully you're now at: I've learned that data type references are important for advanced searching; now I need to learn what those are.

As someone who probably only knows about 10% of what is even possible with the software, I vaguely remember some of this from the 30-day challenge.

The thing I really like about Mobile Ed is that they include in-course activities which get you to use the software features to do your own research to learn more about the course material.

I definitely need to go through the 30-day challenge again, since all this is rusty, but have been holding off until LT271 is released, especially since it will support the Courses tool.

I hope that LT271 will include in-course activities which get us to actually do some advanced searches, as merely watching a video is never as effective in remembering, compared to watching then doing.

MJ. Smith

https://community.logos.com/discussion/comment/854270#Comment_854270

When we are told that {...} is used for "well...other things," without specificity, clearly something needs to be done to teach the non-techie average user.

Okay "well ...other things" translates into

{ } items for which one provides the values of one or more attributes / datatypes in contrast to
< > datatypes for which one supplies a value of the datatype itself in contrast to
" " text which is itself the value in contrast to
fields for which one provides no values or value of the field itself

MJ. Smith

https://community.logos.com/discussion/comment/854270#Comment_854270

Francis asked for a simple answer.

Francis is also assuming that there is a simple answer. While I have given a reasonably simple answer above, when one wishes to search discourse analysis mixed with morphological meaning mixed with sense information, one cannot reasonable assume that there is a simple answer ... a number of items we can search on require us to put some serious effort into learning the meaning of the various values and attributes. Because there is only a word or two identifying the values/attributes it is easy to make mistakes. I did that today with respect to "theme" in a Speaking to God search.

Cynthia in Florida

https://community.logos.com/discussion/comment/854281#Comment_854281

Francis asked for a simple answer.

Francis is also assuming that there is a simple answer. While I have given a reasonably simple answer above, when one wishes to search discourse analysis mixed with morphological meaning mixed with sense information, one cannot reasonable assume that there is a simple answer ... a number of items we can search on require us to put some serious effort into learning the meaning of the various values and attributes. Because there is only a word or two identifying the values/attributes it is easy to make mistakes. I did that today with respect to "theme" in a Speaking to God search.

Which is my point exactly! When the answer is "there is no simple answer," to something that a user should have basic knowledge of which is necessary to use the software in order to gather information from one's own resources, something is wrong.

i think I'm beating my head against a wall here, and it's starting to really hurt.

i just hope FL sees that there's a problem here, and works toward making Logos more user friendly in this area. what good is buying all these resources if we can't properly search them.

MJ. Smith

https://community.logos.com/discussion/comment/854287#Comment_854287

i just hope FL sees that there's a problem here, and works toward making Logos more user friendly in this area.

I am confident in Faithlife on both issues ... but my concern is that they don't increase the probability of misinterpretation in the process. At the moment I think the faceted approach that Logos has been extending is a promising approach. Bible Browser export to Search to change logical operators and grouping has possibilities. I'll have to see it's reception across a broader audience to evaluate the morphology grid approach.

Mark Barnes

https://community.logos.com/discussion/comment/854270#Comment_854270

Francis asked for a simple answer. I don't think the intent was complexity, but what this research HAS revealed is that there is a problem when the best of the best here cannot explain how to search to even the most desirous learner.

That's not what happened.

Francis did not ask us to "explain how to search". If he had, we would have answered very differently (e.g. step 1, step 2, apply this principle, etc.) He asked what the difference was between searches that use < > and searches that use { }. Specifically he asked, how he should determine which to use.

He's got a simple answer to that question, which he wasn't satisfied with! That's his prerogative, of course, and we were happy to give more depth.

If you'd like to know "how to search", create a new post, and we'll try again! But that's not what this discussion is about.

Francis

https://community.logos.com/discussion/comment/854318#Comment_854318

I am making one last time attempt at getting through although at this point I confess my hopes are not high.

I do not mean this as criticism but as (hopefully constructive) feedback to you both as MVP, Mark and MJ. You have both taken a turn for a more techie oriented perspective on using logos. The knowledge you have acquired benefit many to be sure. But there are times, like what goes on in this thread, when I feel that you have lost the perspective of what should be reasonably expected of a "normal" user who wants to take advantage of the advertised powerful capabilities of logos. It is a very reasonable question to want a straight answer to what the use of a search syntax term is. This thread is full of elliptical answers, ranging from sending us to links or the help file that do NOT elucidate this question, to telling us "it's okay, you can work around it" (use the context menu, the Bible browser"), to "you need to keep on experimenting with it, practice, practice, practice, for familiarity to develop" (or is it really that one would have memorised at this point what each one is used for?). On top of that, there is quite a bit of deflection: a "simple" answer was given but was not accepted, a reductionist, simplistic answer is being demanded for a powerful feature, etc. Please, step back. This is not good.

You may know the joke about Microsoft tech support "technically correct but completely useless". I would not say this has been completely useless, but there is something of that joke that rings true of what has been taking place here.

Now, in the thick of these various levels of smokescreens, there have been hints that perhaps the real problem is that these terms were not originally designed to be intelligible to users. The search capabilities they mediate were definitely built for the user, but perhaps the terms themselves were designed more to help programmers keep different needed route for implementation (e.g., using the full index or not) straight for their own in-house purposes. If this is the case, then indeed, the problem is that it is not possible to explain what these terms are without appealing to these under the hood technicalities. It is not that one can get no sense whatsoever of when to use what, but it must remain somewhat blurry because there is not a one-to-one correspondence between user-oriented categories and programming categories. Or is it that even the under the hood the situation is not that tidy, seeking to adjust its definitions on the way as new categories are being added (e.g., add a search capability, it's not a <...> so we put it in {...} like a "miscellaneous" folder)?

I don't claim that the paragraph above is accurate. I am just trying to make sense of what has been written and how this has been handled so far.

Mark Barnes

https://community.logos.com/discussion/comment/854328#Comment_854328

Francis,

Thank you for the feedback.

When I try and see things from your perspective, I do understand your frustration, I really do. I wish it was easier to search in Logos, and have said so in the past. I've also suggested a concrete way in which it could be improved (see above).

You said, "I feel that you have lost the perspective of what should be reasonably expected of a "normal" user who wants to take advantage of the advertised powerful capabilities of Logos".

Please remember that the thread originally asked for an explanation as to why there is a difference between < > searches and { } searches, and what that difference signified. This thread explains that difference, both in simple, generalistic terms, and in moderately technical terms.

I accept that the thread didn't explain the difference in terms you understood. I'm sorry about that. You can take it as a compliment, as it means we thought you understood more than you do :-). Had you been a new user, I think we would have answered differently.

Once we realised you weren't comfortable with words like "datatype" and "datatype reference", we tried to take a step back, and help you to be certain of your understanding of those terms. You'll have to take our word for it for now, but they really are fundamental to understanding this subject. That's not "appealing to under the hood technicalities". It's using building blocks to develop your understanding.

If you asked the question, "Why do some cars use spark plugs, and some cars use glow plugs?", it wouldn't be possible to give a clear answer to that question unless you understood some of the differences between gas (aka petrol) and diesel. That's not a "technicality", it's fundamental to the question. It's the same here.

The good news is that "datatypes" and "datatype references" are easy to understand. Once you've grasped the concepts, everything will fall into place. It really will.

MJ. Smith

https://community.logos.com/discussion/comment/854328#Comment_854328

I look at this problem from a somewhat different perspective. How often do we see questions in the forums similar to "how do I search for prayers of David that praise God in time of danger?" We have to make the questioner step back to define what they mean by "praise"? by "prayer"? by "time of danger"? What verbal constructions meet those requirements. When you add Logos tagging for searches into the mix, you not only need to know what the requirements are on the text itself but also what are the requirements using the assistance of Logos tagging. This requires that one learn some vocabulary related to that tagging ... otherwise you can't understand what you are asking for and if what you are asking for is what you actually want. This isn't programming vocabulary, it is application vocabulary analogous to Microsoft requiring that you know "style sheet", "references", "links" . . .

Dave Hooton

https://community.logos.com/discussion/comment/854175#Comment_854175

For the <PreachingTheme Wealth> search, that entire paragraph/article was tagged as a "reference" to that preaching theme. In my mind, this is incorrect tagging (and I've reported it to Content Production as such)

typing wealth in the Search 'Find' box and clicking 'Theme' ==> query <PreachingTheme Wealth> which gives results in 17 resources; then
right clicking a result in a resource and selecting 'Preaching Theme' ==> query {Section <PreachingTheme = Wealth>} which gives totally different results i.e. with NO results for resources in #1; whilst
typing light in the Search 'Find' box and clicking 'Culture' ==> query <Culture Light> which provides NO results from my library, whilst
right clicking light as #2 ==> query {Section <Culture Light>} and many results.

These inconsistencies (#1 & #3) need to be eliminated if users are to be encouraged to type words in the 'Find' box to formulate complex queries. Note that it is not the first time this has been reported.

All this may illustrate what {Section datatype reference} does but it confuses the definition and understanding of datatypes.

Francis

https://community.logos.com/discussion/comment/854330#Comment_854330

Help file excerpts and comments:

1. "<DataType ...> — indicates a data type reference of a specified type such as <Bible John 3:16>."

Comment: so far so good. As Jack Sparrow would say, "I like it: simple, easy to remember."

2. "Search terms come in a variety of types: plain text, such as Judah or John 3:16; a specific data type, such as <Person Judah (patriarch)> or <Place Judah (kingdom)> or <Bible John 3:16>; or a search extension term like {Speaker <Person Judah (patriarch)>}.

The type of term determines which dataset or kind of data will be matched. There’s a big difference between searching for the text Judah, which will only match those characters in sequence, and searching for the reference <Person Judah (patriarch)>, which (depending on your library and datasets) will not match where “Judah” refers to the place or the tribe, but will match places where the text “he” or “his” has been tagged as referring to the biblical person Judah son of Jacob."

Comment: what I learn is that there exists different types, and some extensions, and that they work differently depending on the specificity of each. No explanation is provided here that helps differentiate between a data type and an extension.

3. "Extension terms allow specialized searches introduced with version 6. They are always enclosed in curly braces — ’{’ and ’}’ — and always start with the name of the extension, for example, {PassageList ...} or {Highlight ...}. Each extension has content after the name which can be highly variable depending on the needs of the particular search extension. For example, the Highlight extension takes the name of a highlighter style, and the Label extension takes a series of constraints for defining a label instance in a special query language designed specifically for matching labels."

Comment: This paragraph is mainly a superficial description of extensions (they have curly braces...). The most interesting part of the paragraph is that they "can be highly variable...". This may suggest that this is not the case for data types, although it is not a necessary inference. Hence the suggestion I made earlier of thinking of data types as narrow and extensions as broad which was said to be inaccurate.

4. "Data Type: A kind or family of information as distinct from other kinds of information. Each data type has its own internal rules and structure. Some of the data types found in Logos:

• Bible
• Date
• Day of Year (for daily devotionals)
• Greek Strong’s Numbers and Hebrew Strong’s Numbers
• Louw-Nida Semantic Domains
• Nag Hammadi Codices
• Page Number
• Pseudepigrapha
• The Laws of Hammurabi
• Works of Philo"

Comment: A highlight, a section, a milestone are also kinds and families of information as distinct from other kinds of information, with their own rules and structure. The word "he" is tagged as referring to the person Abraham and is found by <Person Abraham>. My note on Psalm 23 is tagged as referring to Psalms and is found by {Label Psalms}. As I examined what kind of referents were listed as data types and what kind were extensions, I observed that the former are intrinsically narrowly identified with a word or short phrase while the latter were more properties that were not intrinsically narrowly located. My attempt to formulate this was rejected as inaccurate.

5. "Data Type Reference

A reference to a particular data type. Generally, data type references are marked as hyperlinks, so clicking on the link will open the most appropriate resource for that reference.

When a commentary on the book of Job mentions a particular passage, clicking on the hyperlink will open your preferred Bible to that passage. The hyperlink is a data type reference under the hood. Similarly, a reference to page 45 of the current book may be a data type reference to the page number, and clicking on it will open the book to page 45."

Comment: this does not add anything new to the above as far as I can tell.

Conclusion: According to what Mark wrote, "the good news is that "datatypes" and "datatype references" are easy to understand. Once you've grasped the concepts, everything will fall into place. It really will". Data types do not appear difficult to understand to me, what is difficult to understand is the difference with extensions, and no, I do not find that illumination readily comes from the first to the second. Let me recapitulate what I get from the above:

Various classes of referents are tagged in resources: places, things, persons, etc. The corresponding data type search finds the words or phrases that denote that referent. Some of these are "references" (a location in a resource, such as a Bible reference, a page number, a passage in the fathers). John 3:16 is a unique location in a Bible. The person Abraham, however, is not found at a unique location: it's a bunch of locations tagged as <Person Abraham>.

I still cannot see how this is not also true extensions: I have a bunch of locations tagged with the highlighter style Yellow which I can find using {Highlight Yellow} which is not a data type. Apparently my thought about how they otherwise differ is not right. So I am left to wonder what it is that I am supposed to find out from this that I am obviously not seeing.

Mark Barnes

https://community.logos.com/discussion/comment/854364#Comment_854364

Thank you Francis, for taking the time to read up on datatypes and comment. I have to go to church now, but I'll respond as soon as I get back.

Andrew Batishko

https://community.logos.com/discussion/comment/854364#Comment_854364

Francis, I hope you don't get frustrated and give up on trying to understand this. I feel like you are close. Hopefully some of this extra detail is useful without just making things more confused.

Extension searches exist because we needed a way to search for something that could not be represented in the existing syntax. Frequently (but not always) this is because the data you looking for is not contained directly in the resource like the text is, so a different syntax is needed to tell the application to look someplace else. Some types of extension searches might have more or less in common with searching for a datatype reference, but you really have to examine each type of extension search independently. Don't try to group all extension searches together.

A datatype reference is just an arbitrary piece of data that has been attached to some selection of text. In some cases (like a Bible reference) it has a lot in common with a hyperlink (click on a reference in the text, and it takes you to someplace that tells you about that reference). Searching for a reference means you are searching for all the places that link to information about what you are looking for. But other types of references might cover a larger block of text and not actually behave like a hyperlink.

To understand a {Milestone search, you have to know that most books contain one or more milestone indexes. Each index is a list of references of a particular datatype that point to a particular place in the book. Bibles obviously have a milestone index that use the Bible datatype. Each entry in the Bible milestone index is a Bible reference and points to a specific place in the book. This is what lets you jump to John 3:16 or Genesis 1:1. The {Milestone search lets you find those locations across all your books.

A {PassageList search is similar to a {Milestone search. Rather than finding a single milestone (represented by a datatype reference), it finds a bunch of milestones as defined by the datatype references found in a specific passage list.

A {Highlight search looks text which has been marked up by a particular highlighting palette or style. This is pretty straightforward. Depending on how you tend to mark up your text, this could find arbitrary amounts of text.

A {Section search is a somewhat unfortunate artifact of how some types of data get added to the system. Rather than searching the normal index where datatype references from the resource are stored, it searches for tags that are found in special supplemental resources, hence Bradley's comment about Adoption being mistagged. This type of search is extremely similar to a datatype reference search it's just that because the data is stored someplace different, a different syntax is used to be able to search the different location where the data is stored. See Bradley's comment below.

A {Speaker or {Addressee search is similar to a {Section search. It searches for the data in a special supplemental resource rather than search in the usual index that is built on your computer. It's different from a {Section search, because rather than looking for text that has been marked up with a particular datatype reference, it's instead looking just for text where the speaker or addressee is a particular datatype reference.

A {Label search is the most complicated of the extension searches. It searches for a special type of information that has been added to a block of text (in this way it's similar to a {Section search). Labels might be directly marked up in a resource, or added with a special supplemental resource, or might have been added by a user. A {Label search is complicated, because labels have multiple attributes of different types, and the search syntax allows you to limit exactly which labels are a match by constraining your search based on the values of those attributes.

Mark Barnes

https://community.logos.com/discussion/comment/854371#Comment_854371

Francis,

I've just typed a long post with lots of detail (I'll post that in a minute), but in that post is a single sentence which I wish I'd thought of earlier, because I think it might be the missing link in your understanding. So I wanted to isolate it here in case you missed it:

You search for datatype references, you search using search extensions.

So when you type <Bible John 3:16> that means you're search for references to John 3:16. But when you type {Milestone XXXX} it means you want to use the special Milestone search to find XXXXX.

I wish I had said that sooner. If the sentence above makes sense to you, it might be more helpful than everything else I've written on the subject, including the long post that follows!

Mark Barnes

https://community.logos.com/discussion/comment/854364#Comment_854364

First, let's talk about datatypes and datatype references on their own merits — irrespective of search syntax. That way, we won't muddy the waters.

Datatypes

We usually write datatypes between angle brackets, because that's how we search for them. But datatypes are used in other contexts without angle brackets, for example in specifying locations. For example, this is a link to the AYBD that uses the VolumePage datatype: https://ref.ly/logosres/anch;ref=VolumePage.V_1,_p_342

The help file says that a datatype is "A kind or family of information as distinct from other kinds of information. Each data type has its own internal rules and structure." There are hundreds of datatypes, and there can significant differences between datatypes:

Some datatypes can only support a single value <PreachingTheme Adultery>, whilst others can support ranges <LN 96-97>.
Some datatypes can have a hierarchy of values <Bible John>, <Bible John 3>, <Bible John 3:16>
Some datatypes work in a fairly generic way, whilst others are quite specific. For example, Morph datatypes allow you to specify wildcards in a search, which most datatypes don't (<LogosMorphHeb ~ Va?1?????>).

So if datatypes vary so much, what do they have in common? They're all a way of storing arbitrary pieces of structured data within a resource.

Datatype reference

If a datatype is a specification of structured data, a datatype reference is an instance of structured data. So "Bible" is a datatype. "John 3:16" (internally "bible.64.3.16") is a datatype reference.

Most datatype references are hyperlinked, so that when you click on them another resource that supports that reference opens, according to your prioritisation. (Datatype references are one of two types of hyperlinks. The other type are simple links that go directly to a specific resource.)

But datatype references can be used in other contexts. For example, they're used in milestone indexes to specify locations within resources. They're also generated by tools like Factbook, of course.

Searching for datatype references

When a datatype reference is attached to text, we can search for it using the syntax <DataType Reference>. This search will only ever find occasions where the datatype reference is attached to text. (So searching for John 3:16, will find places where John 3:16 is referred to, but it won't find John 3:16 itself.)

Search extensions

The issue noted above was a problem in Logos 4. We could only search for datatype references when they were attached to text. For example, we couldn't search for datatype references in a milestone index. A milestone index is the index of locations in most resources. The index could be of volume/page numbers, bible references, or any other datatype. It's the inability to search in a milestone index that meant we couldn't find John 3:16 itself.

Theoretically, it would have been possible for Logos to extend search so that <John 3:16> found both references to John 3:16 in the text, and references to John 3:16 in milestone indexes. But then there would be no distinction. Perhaps we only want to find references to John 3:16 in the text, and aren't interested in milestones. Or the other way around.

In addition, users were clamouring for other ways of searching. Some people wanted to search within highlights.Other datasets were being developed, which marked arbitrary sections of text, and we'd want to search those too.

So Faithlife decided to introduce a new category of search, which they called search extensions, and these were indicated with curly braces.

There's a lot of variety in search extensions, but there are also important differences between search extensions and datatypes. The primary purpose of datatypes is to store structured data in a resource. Search is secondary. The primary purpose of search extensions is to extend search capability. That means that you search for datatype references, you search using search extensions.

A search extension will often allow you to specify datatype references in a special way. So searches such as {Milestone <Bible John 3:16>} allows you to search for any datatype that occurs in a milestone index. But {Highlight Yellow} has a difference specification. Then you're not searching for datatypes at all.

I think I'll pause there. You probably have follow-up questions...

MJ. Smith

https://community.logos.com/discussion/comment/854373#Comment_854373

Extensions from Help documentation

Independent

Addressee
Highlight
PassageList
Speaker

Label

Biblical annotation datasets

Figurative Language
Longacre Genre

Interactive dataset labels

Intertext
Miracles
Proverbs
Psalm

Other datasets

Bible Books Supplemental Dataset
Bullinger's Figures of Speech
Propositional Outline

Resource labels

Bible Outline
Journal Article
Lectionary Reading
Personal Letter
Sermon

Milestone

finds citations; use resource information to identify relevant datatypes

Section

Culture
Event
Figurative language (FigLangCat, FigLangTerrn, FigLangType)
Grammatical Constructions
Literary Typing
Preaching Theme (when applied to the Bible text)
Sentence
Speech Act

The fact that the Morris Proctor materials only show how to initiate the search from the right click menu and do not show the search itself does not help in making these searches approachable.

The fact that there are datasets for Speaking to God and Sacrifices but no documentation of a Search function does not help in making these searches approachable.

The fact that Help is inconsistent in providing the link to potential values does not help in making these searches approachable.

However, it does appear to be true that the search terms for extensions are always either a datatype or an attribute of a label so In that sense they do form a cohesive unit that requires that the user know only two pieces of information both of which are widely used in the application.

GaoLu

https://community.logos.com/discussion/comment/854406#Comment_854406

I am finding this extremely helpful. Gives me hope enough to dig deeper into this. Please keep going

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/854373#Comment_854373

A {Section search is a somewhat unfortunate artifact of how some types of data get added to the system. Rather than searching the normal index where datatype references from the resource are stored, it searches for tags that are found in special supplemental resources, hence Bradley's comment about Adoption being mistagged. This type of search is extremely similar to a datatype reference search it's just that because the data is stored someplace different, a different syntax is used to be able to search the different location where the data is stored.

I'm going to disagree.

The {Section syntax is not needed because the data is stored in a different place. (The search engine would be quite capable of retrieving data from all sorts of different places and merging it together.)

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.

It became clear that searching for milestones would be a useful enhancement, so we introduced the {Milestone syntax.

At the same time, we began realising that the third kind of annotation wasn't supported well in the Logos format. (That's the root cause of <PreachingTheme Wealth> being added (incorrectly, in my view) as a reference in the example I cited earlier: the right kind of tagging wasn't available to the resource owners. In fact, if I could turn back time, I probably wouldn't have Bible Commentaries tagged with Bible milestones—which constantly causes problems when unwary users prioritise them above their Bibles—but tagged as being about that verse. But it's a little late for that now.)

So when we started making supplemental data resources searchable, we also introduced the {Section search extension. Consider the "PreachingTheme Wealth" example. The text isn't a definition of the preaching theme (that would be in the Preaching Themes Glossary resource). It's also not an explicit reference to the theme (e.g., "see Wealth"). Rather, it's a biblical text or a sermon that's topically related to that preaching theme, or is a discussion of it. All these "related" or "about" texts can be found through {Section (if the appropriate datasets are in your system).

If we need to make more fine-grained distinctions about the relationship of the text to the data type reference it's being annotated with, we will create labels with specific properties and then you would have to use a {Label search to find them.

Andrew Batishko

https://community.logos.com/discussion/comment/854484#Comment_854484

I'm going to disagree.

Outstanding! Thanks for the correction.