(Untitled)

Francis said:

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

Francis said:

[

Graham Criddle said:

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

PL said:

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.

PL said:

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 said:

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.

Francis said:

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 said:

 {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 said:

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.

Mark Barnes said:

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

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

MJ. Smith said:

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.

Bradley Grainger (Faithlife) said:

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.

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

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