<{~":- !!!

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

Posts 3644
Francis | Forum Activity | Replied: Mon, Sep 26 2016 2:59 AM

PetahChristian:
I think one of the "problems" here is the lingo.

Seeking to "translate" the lingo in concepts that are easier for everyone to relate to is a large part of what I am trying to do here. I think we have made progress in the last round.

Thank you Andrew, Mark, Bradley, and MJ for your replies. I found most helpful this:

Bradley Grainger (Faithlife):

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.
  • reference to that reference, e.g., "see John 1:1". This is the most common use of data type references in the system, and what the syntax <John 1:1> searches for
  • text about that reference, e.g., a commentary on John 1:1

In the early days of the Logos search engine, the second kind of annotation (reference) was the only thing you could search for, and what the search syntax was designed to enable.

and that:

Mark Barnes:
you search for datatype references, you search using search extensions.

It feels indeed, as Andrew put it, that we are getting closer. There are still some bits and pieces that we can perhaps consolidate with these shorter, more to the point explanations:

The distinction about searching for and using is good, especially in relation to milestones and sections, but one also searches for a label and a highlighter style or a specific passage list, although it is also possible to search within (using) these. As I look on label, highlighter style, and passage lists, it strikes me that they all are user-defined annotations (they don't come with the resource or supplied through a dataset). This is not true of milestones and sections of course (they are not user defined), but it can be a useful additional criteria to distinguish between data types and extensions:

  • Data types are specific referents one can find because the resources are encoded with them (a place, a person, a thing). What one finds by searching for a datatype is an instance of this datatype: Abraham is a person, Jerusalem a place, a stone is a thing, etc. As a result, normally* what a data type finds cannot be more than one data type at a time (Abraham is a person, and not a thing, a place, etc) and you cannot find <Thing X> WITHIN <Person Y>.
  • Extensions allow one to either (a) find contexts in which instances of data types are found (a person or thing within a milestone or section) or (b) find information the user has tagged ("extended") resources with (label = Psalm, highlight = Yellow) or (c) the combination of both, find data types within user defined tagged text (a person within a highlighted text). What one finds is (except in b.) connected to a data type but not equal to it (a section in which a person is found is not itself a person, a text which has a preaching theme is not itself a preaching theme. Abraham is not a speaker or an addressee, sometimes he has that role but he is always a person). You can find <Thing X> WITHIN {Extension Y}. Except in (b), one does not search for an extension itself: you don't search for {Section 00149} if there is even such a thing.

I highlighted the sentence that I think is the key addition. 

* I put "normally" just in case there are exceptions although I cannot think of any just now and am not sure there are.

I want to thank you for persevering in this. It is a passion of mine to help people understand complex concepts and I think that with effort it is usually possible to communicate in layman's terms what is otherwise normally expressed in specialist terms. I don't think that it is only my understanding that has progressed here: I think you have also wrestled with and improved your explanations. The purpose of my summary is to check understanding (summarising in one's own words is a great way to check for correct understanding) but also an attempt to further the effort to make it more intelligible, concrete, and rounded for "the rest of us".

Gary Mendenhall:

My head is spinning after reading through this thread.  I guess that's normal.

My goal in starting this thread is not that one would have to read it all in order to "get it" but that hopefully, in the end, we have something is both reasonably accurate and accessible/elucidating to the average user. When we get there, I'd be happy to receive exceptional permission to edit the original post with an addendum that tells people they can skip to a specific post location for the best answer if they don't want to read it all and be overwhelmed by too much information. Hopefully this thread can also give ideas for a useful and needed addition to the help file and other help resources such as tip of the day and the wiki, and the latter would of course be more succint.

Posts 13210
Forum MVP
Mark Barnes | Forum Activity | Replied: Mon, Sep 26 2016 4:19 AM

Francis:
The distinction about searching for and using is good, especially in relation to milestones and sections, but one also searches for a label and a highlighter style or a specific passage list, although it is also possible to search within (using) these

{Highlighting Yellow} means you use a Highlighting search to search for Yellow highlighting.

<bible John 3:16> means you search for a bible reference to John 3:16.

Posts 119
Gary Mendenhall | Forum Activity | Replied: Mon, Sep 26 2016 4:24 AM

Francis, I appreciate your efforts here and hope your goals are reached.  I have followed this thread since your original post with the hope of gaining insight in an area that I am sadly inept but as the dialog continued on I just became mired in the language and all of the exceptions as well as the responder's assumptions that the readers of this thread have prior knowledge of some of the concepts mentioned.  Before this thread I had no idea what a "Milestone" was.  This thread is bringing to my attention a fear that I have had for awhile; maybe I'm just too stupid to be using Logos.

Thanks again for your efforts and blessings to you,

Gary

Posts 13210
Forum MVP
Mark Barnes | Forum Activity | Replied: Mon, Sep 26 2016 4:49 AM

Gary Mendenhall:
I have followed this thread since your original post with the hope of gaining insight in an area that I am sadly inept but as the dialog continued on I just became mired in the language and all of the exceptions as well as the responder's assumptions that the readers of this thread have prior knowledge of some of the concepts mentioned.

As I've said before, the people responding to this thread have been trying to give clear definitions and explanations of what's going on under the hood. We've not been trying to give training in advanced search techniques. There's definitely a place for that, but this thread isn't that.

If you want to learn how to do advanced driving, you wouldn't gain much from listening in to a lecture on automobile mechanics. If you stumbled into that lecture but didn't follow everything that was going on, it wouldn't mean you were stupid — it would mean you were in the wrong place!

This might be better for you: https://www.logos.com/product/51655/verbum-advanced-search-training,

Posts 3644
Francis | Forum Activity | Replied: Mon, Sep 26 2016 5:20 AM

Mark Barnes:

{Highlighting Yellow} means you use a Highlighting search to search for Yellow highlighting.

<bible John 3:16> means you search for a bible reference to John 3:16.

Either I don't understand you or you did not understand me:

I could just as well say that in <Bible John 3:16> I am using "Bible" to search for John 3:16 which is a Bible reference just as in {Highlight Yellow} I am using "Highlight" to search for Yellow which is a Highlight colour. In both cases I use a class to search for an instance. This is why I suggested that these terms did not apply as readily to the user defined searchable entities such as labels or highlights although they do apply very well to milestones or sections.

Gary Mendenhall:
maybe I'm just too stupid to be using Logos

I am a doctorate candidate, top of class, and I use five different languages and I still find some of the explanations obscure. I don't think it's you, so don't be discouraged about this. Hang in there and hopefully we will land in a better place. When you are learning to drive with a standard transmission, you can be taught to listen for when your engine starts roaring and feel in the pedal the vibrations that show it needs a different gear. Or you can be given a lecture about pistons, RPMs and so on (which will not teach you to drive!). You CAN effectively drive without knowing anything about pistons! And I am sure you and most of us can use Logos without having to learn what goes on under the hood. 

Mark Barnes:
As I've said before, the people responding to this thread have been trying to give clear definitions and explanations of what's going on under the hood.

As the OP, I disagree with the gist of your response to Gary. If you read my original post again you will see that I was specifically asking to limit jargon, and strive for something practical and easy to remember.

Posts 119
Gary Mendenhall | Forum Activity | Replied: Mon, Sep 26 2016 5:35 AM

Thanks for your reply Mark, I guess I've been schooled.  I've learned quite a lot from these forums over the years and I don't think it's too much of an expectation to think that I can still learn more by following a thread of interest.  Indeed this thread became a bit over my head but I guess I wouldn't have known that had I not followed it; right?  As I continued to follow the thread I kept hoping that things would be clearer and a bell would go off in my head but that didn't happen.  I guess it takes some people a little bit longer to find out that the water is a little to deep for their swimming skill.

Regarding your advanced driving and auto mechanic analogy; I don't buy it.  I have a sophisticated peace of software in Logos that has a sophisticated search capability.  The only way I'm going to be able to understand how to take advantage of those functions is if I know what they do and how they work.  In other words, "what's under the hood", or in your terms, "the mechanics".  The problem I was having was mostly in the language/terms being used and my unfamiliarity.  Was hoping to gain some insight here but see now that I was wrong and need to glean from another source for knowledge on such a sophisticated subject. 

.   Anyway, I have been in on the pre-pub for the advanced search training videos since it was offered and eagerly waiting for it to go live.  Keep up the good work.

Blessings,

Gary

Posts 119
Gary Mendenhall | Forum Activity | Replied: Mon, Sep 26 2016 5:46 AM

Thanks for the encouragement Francis.

Blessings,

Gary

Posts 13210
Forum MVP
Mark Barnes | Forum Activity | Replied: Mon, Sep 26 2016 5:55 AM

Francis:
I could just as well say that in <Bible John 3:16> I am using the Bible to search for John 3:16 which is a Bible reference just as in {Highlight Yellow} I am using Highlight to search for Yellow which is a Highlight colour. In both cases I use a class to search for an instance. This is why I suggested that these terms did not apply as readily to the user defined searchable entities such as labels or highlights although they do apply very well to milestones or sections.

You could say that, but that wouldn't make it correct :-). There's a subtle, but important distinction. To use your terms, when you're searching for <Bible John 3:16> the 'class' isn't "Bible". The 'class' is "datatype reference", and the 'instance' is "bible.64.3.16". ('64' because John is the 64th book of the Bible using Logos' way of counting - which includes apocryphal books).

Francis:
As the OP, I disagree with the gist of your response to Gary. If you read my original post again you will see that I was specifically asking to limit jargon, and strive for something practical and easy to remember.

We'll have to agree to disagree on that point. I entirely accept that in your original post you asked to limit jargon, and there was no jargon at all in my first five responses, which (IMO) were both practical and easy to remember, but ultimately unsatisfying to you. I only added jargon in my sixth response when you pushed me to specify what was wrong with your attempt at a definition. At that point I said, "We can either explain it simply (and leave stuff out), or explain it fully (and it will be overwhelming). I'm not sure there's a middle ground." I stand by that comment.

Posts 804
Cynthia in Florida | Forum Activity | Replied: Mon, Sep 26 2016 6:56 AM

Mark Barnes:

Francis:
The distinction about searching for and using is good, especially in relation to milestones and sections, but one also searches for a label and a highlighter style or a specific passage list, although it is also possible to search within (using) these

{Highlighting Yellow} means you use a Highlighting search to search for Yellow highlighting.

<bible John 3:16> means you search for a bible reference to John 3:16.

Mark:  I have to agree that the distinction between FOR and USE is the best, succinct piece of information on this thread.  And...the way you just used them as examples has really brought a great deal of clarity regarding the {...} and <...>. 

I too have to say THANK you to Francis for starting this thread, and Mark and MJ for sticking with it.  Also, thank you FL employees (sorry, I can't remember names), for following through.

I think it's important for me to clarify something I said earlier.  When I said that something is wrong when even the best of the best here cannot explain it to the most desirous learner, I wasn't putting the emphasis on the "best of the best" (i.e., the people).  I was putting the emphasis more by saying, "okay, come on, if these amazing people (i,e, "the best of the best") can't explain it in a way that people who REALLY want to learn can understand," then something is broken because you have excellent teachers matched with students who really want to learn, and it's like there's some sort of chasm. 

Someone in another thread said something fantastic.  They said that there has to be a bridge between "us" and "them."  The gap between those who REALLY known the program's search functions and "the rest of us" who are so frustrated because we know we have all these resources and are stuck in basic search functions (as evidenced by the many "how do you search for this threads), is so wide that something has GOT be done to bridge the gap.  So, if in my frustration it came across that I was in any way complaining about the way MJ or Mark (or anyone else here for this matter), was explaining things, that was not at all my intent, and so I want to make sure I clarify myself.  I am INCREDIBLY thankful, especially to our MVPs, who work so hard at helping and explaining things, and this thread is a testament to their tenacity in helping!  THANK YOU!

Cynthia

Romans 8:28-38

Posts 2042
LogosEmployee

Mark Barnes:

Francis:
I could just as well say that in <Bible John 3:16> I am using the Bible to search for John 3:16 which is a Bible reference just as in {Highlight Yellow} I am using Highlight to search for Yellow which is a Highlight colour. In both cases I use a class to search for an instance. This is why I suggested that these terms did not apply as readily to the user defined searchable entities such as labels or highlights although they do apply very well to milestones or sections.

You could say that, but that wouldn't make it correct :-). There's a subtle, but important distinction. To use your terms, when you're searching for <Bible John 3:16> the 'class' isn't "Bible". The 'class' is "datatype reference", and the 'instance' is "bible.64.3.16". ('64' because John is the 64th book of the Bible using Logos' way of counting - which includes apocryphal books).

If we were to express a reference search using search extension syntax (which doesn't actually exist, but makes it easier to compare), it might look something like: {Reference <Bible John 3:16>}

You are using Reference search to search for instances of the Bible reference John 3:16.

Posts 2042
LogosEmployee

Francis:

Data types are specific referents one can find because the resources are encoded with them (a place, a person, a thing). What one finds by searching for a datatype is an instance of this datatype: Abraham is a person, Jerusalem a place, a stone is a thing, etc. As a result, normally* what a data type finds cannot be more than one data type at a time (Abraham is a person, and not a thing, a place, etc) and you cannot find <Thing X> WITHIN <Person Y>.

"normally" indeed Big Smile

Try this Bible search: <Thing Fortress> WITHIN <Person God>

You can also find People within People, such as: <Person An Ancestor> WITHIN <Person God>

Posts 15805
Forum MVP
Keep Smiling 4 Jesus :) | Forum Activity | Replied: Mon, Sep 26 2016 10:52 AM

Andrew Batishko (Faithlife):

Try this Bible search: <Thing Fortress> WITHIN <Person God>

Thankful for 25 Bibles that have results:

Keep Smiling Smile

Posts 13210
Forum MVP
Mark Barnes | Forum Activity | Replied: Tue, Sep 27 2016 2:36 AM

Mark Barnes:
That doesn't mean that search shouldn't be made easier. It should. But the way to make it easier is to allow users to construct complex searches without understanding how they work. As the developers have said, the right-click menu is a good way to do that now. A better way, which I'm hoping for in the future, would be a system which would present options for { searches whenever you typed { on the keyboard (in exactly the same way as @ does in a morph search). That would allow people to construct complex queries without having to remember a complex syntax.

Today, I stumbled across a post I wrote last year that explained this idea in more detail, including this mockup:

FWIW, Eli responded:

Eli Evans (Faithlife):
Coincidentally, we are working on the spec for just such a contraption (though it may look a little different than your mockup since I don't know how much secret knowledge of each label type we'll be able to pump into the software, but we'll see).

Posts 3644
Francis | Forum Activity | Replied: Tue, Sep 27 2016 5:31 AM

When I started this thread, I could remember vaguely that Devin Roza had posted something helpful on this. I have found it since and I think it is still the best explanation of search extensions I have read so far:

Fr Devin Roza:

The <> is used to indicate a datatype. An introduction to datatypes is here. A relatively complete list of datatypes is here. When you search for a datatype, you are searching for a "reference". The most common type is the <Bible> datatype, where a search like <Bible John 3:16> will find all "references" to John 3:16, regardless of whether they are in a Bible, a commentary, or even if they are within a larger reference, like John 3:10-20. Datatypes also allow for prioritizing resources, so a single datatype reference can open many different resources to the correct place, and show each person the resource they have highest prioritized.

The {} is used for what I like to call "search extensions" (not an official name, BTW, but the best I've found so far, and I don't think there's an official name yet). Each {searchextension} "extends" the functionality of search. Let me try to explain what I mean.

Each "search extension" can have its own search syntax, and can do something entirely different. They are actually analogous to "search tabs", like the Basic, Bible, Morph, Clause, etc. search tab. For example, when you go to the Morph Search tab, when you type g:logos and then @, you will see a dropdown menu with all the morph options. If you do the same thing on the Basic tab, it won't work the same - no morph dropdowns! And the search syntax between the two tabs changes. Each search tab has different functionality, different search syntax, etc.

Well, the {search extensions} offer all of that power - each one can have an entirely different syntax, drop down options, etc. So, instead of creating a lot of new search tabs - one search tab for searching Milestone, another for Speaker, another for Passage Lists, etc. - Faithlife created a new type of search syntax, the {searchextension}.

The great thing about this is that it allows us to use lots of different {searchextensions} together. So we can do great things like search for {Speaker <Person Jesus>} WITHIN {Section <LiteraryType Quotation, Old Testament>} to find all the instances in which Jesus quotes the Old Testament. 

The only thing that is missing from it, I think, is the explanation about why {Label Psalms} and {Highlight Yellow} look so much like <Person Abraham> or <Thing Stone> (in that the constant {Label ...} is used to search for the label Psalms, just like the constant <Person...> is used to search for the person Abraham) (contrast with {Milestone <Person Abraham>} in which one must look for something else within the "tab" milestone). I think the explanation may be this (although I would not be surprised if I were told it is inaccurate): 

Unlike milestones, sections, etc., which are regions of text defined by logos, labels and highlights are defined by users and so receive a specific identifier. So, you cannot search for section 001 (or at least if it is technically possible it is certainly not upfront to the user) but since one called a label "Psalms", a highlight "yellow" or a passage list "Commandments in the Gospels" one can search for the specific instance(s) of Label = Psalms, Highlight = Yellow etc. as well as using them as "tabs" in which we search for something else as in {Label Psalm WHERE Genre ~ "Praise"}. Nevertheless, this particular property of the user-defined regions of text does not eliminate the fact that these are still extensions designed to work as "tabs" / extend searches. 

Posts 3644
Francis | Forum Activity | Replied: Tue, Sep 27 2016 5:39 AM

Andrew Batishko (Faithlife):

"normally" indeed Big Smile

Try this Bible search: <Thing Fortress> WITHIN <Person God>

You can also find People within People, such as: <Person An Ancestor> WITHIN <Person God>

Thanks, Andrew! It is not only good to get that right, but actually suggestive also of further ways to combine fruitfully different types of searches.

Posts 2042
LogosEmployee

Francis:

The only thing that is missing from it, I think, is the explanation about why {Label Psalms} and {Highlight Yellow} look so much like <Person Abraham> or <Thing Stone> (in that the constant {Label ...} is used to search for the label Psalms, just like the constant <Person...> is used to search for the person Abraham) (contrast with {Milestone <Person Abraham>} in which one must look for something else within the "tab" milestone). I think the explanation may be this (although I would not be surprised if I were told it is inaccurate): 

Unlike milestones, sections, etc., which are regions of text defined by logos, labels and highlights are defined by users and so receive a specific identifier. So, you cannot search for section 001 (or at least if it is technically possible it is certainly not upfront to the user) but since one called a label "Psalms", a highlight "yellow" or a passage list "Commandments in the Gospels" one can search for the specific instance(s) of Label = Psalms, Highlight = Yellow etc. as well as using them as "tabs" in which we search for something else as in {Label Psalm WHERE Genre ~ "Praise"}. Nevertheless, this particular property of the user-defined regions of text does not eliminate the fact that these are still extensions designed to work as "tabs" / extend searches. 

When it comes down to it, all the things you can look for are just "regions" of text, whether you are looking for a phrase or a reference or a block of highlighted text or text spoken by a particular person. All blocks of text have pieces of data that are associated with them. Each type of data has a different format and therefore can require a different syntax to identify.

There are lots of different datatypes, but datatype references all have the same format, so we can use a common syntax to identify them. The key pieces of information we need to identify are the datatype (some like Bible references we can cheat and figure out it's a Bible datatype without having to explicitly specify it) and the exact reference. This syntax is <...>

Highlighting data doesn't look like datatype reference data, so we need a different syntax. The only piece of information we need to identify a highlight is its name. Therefore we have the {Highlight ...} syntax.

Identifying label data requires the label name, and optionally some constraints on the label's attributes. Therefore we have the {Label ...} syntax.

Instead of having {Highlight ...} and {Label ...} and {searchextension ...} we could have come up with unique symbols for each (like ^Yellow^ for a highlight search and %Psalm% for the label search), but we'd probably run out of useful symbols.

The fact that {Label Psalms} and {Highlight Yellow} look similar to <Person Abraham> is actually coincidental. The first two are identifying one piece of information, the name of the label and the name of the highlight. The last is identifying two pieces of information, the name of the datatype and the reference. It's just that Label and Highlight require an extra word to identify the type of search being done, while the datatype reference search has the search type identified by the symbols surrounding the term.

Posts 2042
LogosEmployee

Oh, this makes me think of a new way to explain things...

Let's create a completely brand new search language (I'm sure you'll spot some similarities). In this search language we'll try to make all terms use as similar a syntax as possible.

All searches are a term followed optionally by an operator and another term followed optionally by any number of additional operator + term pairs.

Operators are things like: AND, OR, NEAR, etc.

A term looks like: {termtype termvalues}

termtype is one of the following: word, phrase, reference, highlight, label, etc. termvalues vary and depend on the termtype.

Example terms are:{Word heaven} The termvalues here are just the text of the word you are looking for.
{Phrase heavenly father} The termvalues here are the text of the phrase you are looking for.
{Reference Bible John 3:16} The termvalues here are the datatype and the reference (whose exact format is dependent on the datatype specified).
{Highlight Yellow} The termvalues here are just the name of the highlight you are looking for.
{Label Psalms} The termvalues here are the name of the label type, followed optionally by constraints on the label attributes.

This new search language behaves exactly like the existing Logos search language. However, some of the terms defined above use a simplified syntax.

Word terms are simplified so that only the text of the word is written. {Word heaven} becomes heaven.

Phrase terms are simplified so that the text is surrounded by quotes. {Phrase heavenly father} becomes "heavenly father".

Reference terms are simplified so that the reference is surround by <>. {Reference Bible John 3:16} becomes <Bible John 3:16>. In fact, for some datatypes (such as Bible) the datatype can be removed too and the term becomes <John 3:16>.

All the other terms remain the same.

Posts 791
LogosEmployee
Eli Evans (Faithlife) | Forum Activity | Replied: Tue, Sep 27 2016 9:31 AM

Late to the party, so just a quick note for anyone who wonders if we (FL) are a) aware that search syntax is too daggum complicated and if b) we intend to do anything about it in the future: Yes and yes.

I'm saving this thread as a design reference because I think it illustrates some key issues pretty well.

Posts 3644
Francis | Forum Activity | Replied: Tue, Sep 27 2016 10:29 AM

YES!!!

You would not believe it how many times I have thought during the conversation on this thread "Where's Eli when I need him?"

Posts 1501
Forum MVP
Fr Devin Roza | Forum Activity | Replied: Tue, Sep 27 2016 1:57 PM

Francis:

The only thing that is missing from it, I think, is the explanation about why {Label Psalms} and {Highlight Yellow} look so much like <Person Abraham> or <Thing Stone> (in that the constant {Label ...} is used to search for the label Psalms, just like the constant <Person...> is used to search for the person Abraham) (contrast with {Milestone <Person Abraham>} in which one must look for something else within the "tab" milestone). I think the explanation may be this (although I would not be surprised if I were told it is inaccurate): 

Unlike milestones, sections, etc., which are regions of text defined by logos, labels and highlights are defined by users and so receive a specific identifier.

I don't think this quite gets to the heart of the matter. Let me explain how I understand it (which I believe corresponds to what Andrew explains here, in different words).

I find it helpful to think of search extensions as types of searches and datatypes as types of data. I think you've got that pretty clear. But it's also important to keep in mind that even though datatypes are "types of data", there are "types of data" that are NOT datatypes!

What do I mean? The example you give here is a good one.

When I search for {Milestone <Bible John 3:16>}, I'm using a milestone type of search, and I'm searching for a type of data, the Bible type of data, and specifically the Bible reference John 3:16 .

When I search for {Highlights Yellow}, I'm using a Highlights type of search, and am also searching for a type of data! In this case, however, the type of data I'm searching for is not a datatype. It's a highlighting style, and specifically the style Yellow.

So, when you say above,

Francis:

contrast with {Milestone <Person Abraham>} in which one must look for something else within the "tab" milestone

this is imprecise.

In both Milestone and Highlight searches, we must search for something. In the case of Milestone searches, the type of data we're searching for is a datatype. In the case of Highlight searches, the type of data we are searching for is a highlighting style, and we're searching for yellow. In both cases we're running a type of search, and we're searching for something, which is always a something of a certain type of data.

There are many other types of data we search for all the time that are not datatypes, the most common being a text string.

What makes a "datatype" a "datatype" is the under the hood format it has, which is something Faithlife gives it, creates. So, we could imagine someone using "labels" to tag morphological information on the New Testament. We could search on that without using datatypes. Faithlife could then like that Label tagging so much that they decide to transform it into a morph datatype database, and sell it. We could then search for it using datatypes. Either way, the raw data could in theory be the same, just in a different behind the scenes format. The search format would change - in the first case, we could use a Label search without datatypes; in the second case, a Morph search with datatypes. And in both cases, we're using a type of search to find specific types of data.

Of course, this also implies that in theory there could very well be search extensions that accept both datatypes and other types of data as the "something" they are searching for.

Francis:

The only thing that is missing from it, I think, is the explanation about why {Label Psalms} and {Highlight Yellow} look so much like <Person Abraham> or <Thing Stone>

Basically it's because both the search tabs and the search extensions allow "shortcuts".

Every search needs three items to work: (1) type of search (2) type of data (3) data.

Oftentimes one, or even two of these three items is presupposed. This causes the confusing similarities you mention.

So, the search <Person Abraham> supplies 2 and 3, but is missing 1. It works because the search tab supplies the missing (1) type of search, which would be something like {Reference} or {Tag}.

The search {Label Psalms} supplies 1 and 3, but is missing 2. It works because the search extension supplies the (2) type of data. In cases like the Highlights or Label search extension, the type of data is considered always the same, so we don't need to supply it. It's presupposed. Note that it could have been implemented differently. We could imagine the type of data also being required - something like {Highlights Style Yellow}, or {Highlights Palette Solid Colors}.

This applies even to a search like "hello, it's me." The phrase is 3, and 1 and 2 are presupposed. It works because the search tab supplies the missing (1) type of search, which would be something like {Phrase}, and the search tab also presupposes the (2) type of data: text.

And in searches like {Milestone <Bible John 3:16>} the end-user supplies all three explicitly. Although even there, Bible can be omitted, as it is the default datatype and can be presupposed.

Of course, we are really glad we don't have to always explicitly supply type of search, type of data, and data! But it can at times make for some confusion, as the similarities you pointed out.

Hope this helps, sorry for the long answer!

Page 4 of 7 (121 items) « First ... < Previous 2 3 4 5 6 Next > ... Last » | RSS