<{~":- !!!

Page 1 of 7 (121 items) 1 2 3 4 5 Next > ... Last »
This post has 120 Replies | 9 Followers

Posts 3644
Francis | Forum Activity | Posted: Sat, Sep 24 2016 3:29 AM

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. 

Posts 21635
Forum MVP
Graham Criddle | Forum Activity | Replied: Sat, Sep 24 2016 3:46 AM

<...> 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?

Posts 957
Yasmin Stephen | Forum Activity | Replied: Sat, Sep 24 2016 5:18 AM

Francis:

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

What's this??? Stick out tongue (On a serious note, I have no problem with this; I actually like enigmatic titles Smile)

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?).

Posts 13205
Forum MVP
Mark Barnes | Forum Activity | Replied: Sat, Sep 24 2016 5:22 AM

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. 

Posts 3644
Francis | Forum Activity | Replied: Sat, Sep 24 2016 6:18 AM

Yasmin Stephen:

Touché! Big Smile

Graham Criddle:

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. 

Mark Barnes:

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"). 

Posts 799
Cynthia in Florida | Forum Activity | Replied: Sat, Sep 24 2016 7:00 AM

Francis:

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. 

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

Cynthia

Romans 8:28-38

Posts 799
Cynthia in Florida | Forum Activity | Replied: Sat, Sep 24 2016 7:06 AM

Francis:

[

Graham Criddle:

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!?

Cynthia

Romans 8:28-38

Posts 13205
Forum MVP
Mark Barnes | Forum Activity | Replied: Sat, Sep 24 2016 7:16 AM

Francis:
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.

Posts 3644
Francis | Forum Activity | Replied: Sat, Sep 24 2016 7:45 AM

Mark Barnes:
You need to be thinking about what searches will return

That's promising.

Mark Barnes:
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).

Posts 7920
LogosEmployee

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.

Posts 2042
LogosEmployee

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.

Posts 7920
LogosEmployee

Francis:
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.

Posts 7920
LogosEmployee

Bradley Grainger (Faithlife):
Consult the corresponding dataset documentation for specific details.

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

Posts 1332
PL | Forum Activity | Replied: Sat, Sep 24 2016 8:48 AM

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

Posts 13205
Forum MVP
Mark Barnes | Forum Activity | Replied: Sat, Sep 24 2016 9:56 AM

PL:
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.

Posts 3644
Francis | Forum Activity | Replied: Sat, Sep 24 2016 10:12 AM

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.

Posts 13205
Forum MVP
Mark Barnes | Forum Activity | Replied: Sat, Sep 24 2016 10:22 AM

PL:
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"}

PL:
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.

Posts 799
Cynthia in Florida | Forum Activity | Replied: Sat, Sep 24 2016 10:23 AM

Francis:

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!

Cynthia

Romans 8:28-38

Posts 13205
Forum MVP
Mark Barnes | Forum Activity | Replied: Sat, Sep 24 2016 10:36 AM

Francis:
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.

Francis:
 {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".

Francis:
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.

Posts 3644
Francis | Forum Activity | Replied: Sat, Sep 24 2016 12:37 PM

Mark Barnes:
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.

Page 1 of 7 (121 items) 1 2 3 4 5 Next > ... Last » | RSS