Trying to understand advanced search operators and metadata fields

I have an (indexed) folder full of PDF files. If I do an advanced search in All for “stochastic near kinetics”, I get the expected results, which is many dozens of files, and this at the top:

Notice the name of the file that is the first result above. Now if I change the search to search in Name, I get an unexpected result:

The top result from the first search does not even appear in this result, even though I’m searching in the name field, where you can see the original search results contained the highlighted words.

And if I search in Filename, I get no result at all:

Which is really unexpected. Now, I might understand if something wonky is going on with searching filenames, but I can’t come up with an explanation for why there is a difference between the Name and All results for the file named “Gillespie 2007 — Journal Article — Stochastic Simulation of Chemical Kinetics”, when it seems clear that DEVONthink found the relevant terms in the Name field when I searched using All.

Can someone explain what is going on?

Addendum #1: I just tried using the BEFORE keyword, and I get a new, also curious, result – this time, the result from the first search does show up. But, this doesn’t make sense to me, because the NEAR operator is defined as essentially subsuming BEFORE, so using NEAR should have produced this search result too.

Addendum #2: I used FileRebuild database… to see if that would change the behavior. It did, but not for the better. Now I get even fewer results (This is wrong – this example accidentally used the wrong terms. See my follow-up posting below. The results are actually the same when I try the same search.)


1 Like

NEAR doesn’t imply BEFORE. The order doesn’t matter with NEAR.

There seems to be a bug with the NEAR operator but @cgrunenberg would have to comment on this.

It should match terms within 20 words of each other.
This works though…

Also BEFORE is acting oddly. This too should match within 20 words…

But this explicit reference does…

1 Like

(Wrote something but it was wrong. Writing another reply.)

I was wrong in my addendum, about the behavior following the FileRebuild database operation. The behavior did not change. The mistake I made was that I used the singular form of a word I was searching for (“kinetic”) instead of the plural (“kinetics”) as I had done in the original search. When I repeat the actual original search, I get the same results – having rebuilt the database did not reduce the number of results I get.

Thanks for the clarification.

Note: When you’re constructing your search, if Partial matches while typing is enabed under the magnifying glass, a wildcard asterisk is assumed at the end of the last term. This means kinetic would be treated as kinetic*, that is until Return is pressed. Once you press Return the wildcard is discarded and the final term is treated as a word. However, adding the asterisk explicitly would allow you to retain the flexible search as long as you’re using a matches criterion.

I can confirm that I also get the same difference in behavior described by Jim when I use, e.g., near/6 versus near, but I get even more peculiar results.

Here is near/6:

Here is near/10:

I would not have expected fewer results when using a larger N. Some experimentation with different values of N show that there’s a transition point at 8: from 4 to 8, it behaves like with the first result above, but if I use 9 to 11, it produces the second result, and if I use 12, it produces even fewer hits.

The behavior of before/N does not change if I use an N of 4 or larger (which makes sense for my particular data).

I have “Partial matches while typing” turned off (and it was for all these cases). Also, while it’s hard to tell from the screenshots, I was typing in the advanced search field, not the search field in the window titlebar.

Thanks for the follow-up. Criss will have to look at this when he has time.

1 Like

The default distance is 10 words.