A different case for a NOT operator?

In another thread, I wondered if we could find exact matches for Jesus only speaking to John (rather than a group which also included John).

Bradley mentioned adding NOT INTERSECTS {Addressee <Person James (son of Zebedee)>} NOT INTERSECTS {Addressee <Person Peter>} ...

It seemed tedious to build a list of people to be excluded from the results.

So I thought about it, then recalled someone else's posts about "merging" passage lists.

If I built a passage list of everyone Jesus spoke to, then build a second list of everyone else Jesus spoke to (excluding John), I could get the "difference"(?) to get Jesus speaking only to John.

The search expression would be shorter, since it would only involves one NOT INTERSECTS, yet there's still some tedium of making two lists, then "merging" them.

Being me, and looking to get the program to do all the work for me, I thought to myself, "Wouldn't it be nice if we could just say something like "NOT INTERSECTS {Addressee NOT <Person John (son of Zebedee>}."

If the program supports an exact match, it must be able to support a logical operation to negate that exact match.

So, possible? Reasonable? (The solution seems too simple.)

Find more posts tagged with

Comments

Dave Hooton

In another thread, I wondered if we could find exact matches for Jesus only speaking to John (rather than a group which also included John).

Bradley mentioned adding NOT INTERSECTS {Addressee <Person James (son of Zebedee)>} NOT INTERSECTS {Addressee <Person Peter>} ...

It seemed tedious to build a list of people to be excluded from the results.

So I thought about it, then recalled someone else's posts about "merging" passage lists.

If I built a passage list of everyone Jesus spoke to, then build a second list of everyone else Jesus spoke to (excluding John), I could get the "difference"(?) to get Jesus speaking only to John.

The search expression would be shorter, since it would only involves one NOT INTERSECTS, yet there's still some tedium of making two lists, then "merging" them.

Being me, and looking to get the program to do all the work for me, I thought to myself, "Wouldn't it be nice if we could just say something like "NOT INTERSECTS {Addressee NOT <Person John (son of Zebedee>}."

If the program supports an exact match, it must be able to support a logical operation to negate that exact match.

So, possible? Reasonable? (The solution seems too simple.)

I like your original solution {Addressee = <Person John (son of Zebedee>}, rather than a double negative expression. It would work the same as in {Label..} i.e. Addressee has only that value. {Addressee <Person John (son of Zebedee>} would work the same as at present, or you could use {Addressee ~ <Person John (son of Zebedee>} i.e. Addressee contains that value.

Bradley Grainger (Logos)

Being me, and looking to get the program to do all the work for me, I thought to myself, "Wouldn't it be nice if we could just say something like "NOT INTERSECTS {Addressee NOT <Person John (son of Zebedee>}."

If the program supports an exact match, it must be able to support a logical operation to negate that exact match.

So, possible? Reasonable? (The solution seems too simple.)

Yes, this would be possible; I've created a case.

PetahChristian

https://community.logos.com/discussion/comment/989152#Comment_989152

Yes, this would be possible; I've created a case.

Thanks very much, Bradley!

PetahChristian

https://community.logos.com/discussion/comment/989136#Comment_989136

I like your original solution {Addressee = <Person John (son of Zebedee>}, rather than a double negative expression. It would work the same as in {Label..} i.e. Addressee has only that value. {Addressee <Person John (son of Zebedee>} would work the same as at present, or you could use {Addressee ~ <Person John (son of Zebedee>} i.e. Addressee contains that value.

You're right that it would be much better to understand, if the search extensions could behave like that. Addressee would need to:

handle non-ranges, i.e., = would only be John, but not others that include John,
support the range operator, i.e., ~ would be John, as well as others that include John.

Right now, since the Search Extensions have no support for ranges, it appears that we have a bit of a mix-up, where = is returning John, as well as others that include John.

That means that = is inadvertently behaving more like the range operator.

If we could fix that issue, we definitely wouldn't need the double negative as you suggested. I think we'd all prefer to see the issue fixed properly, rather than adding a "fix" to work around the broken behavior. Thanks for helping me realize that my suggestion wouldn't be the best way to proceed.

Clearly, search is a very powerful feature of Logos, but if more people are to properly be able to understand and use its power, we should correct discrepancies like this, that search operators could operate uniformly and be used uniformly, regardless of whether or not a search extension is in use.