unexpected result for api/rss/atom query that combines tag and user facets

[judell]

https://hypothes.is/api/search?tags=wisdom -> 8

https://hypothes.is/api/search?tags=wisdom&uri=https://posts.postlight.com/this-is-postlight-fe49148b014 -> expect 1, got 1

https://hypothes.is/api/search?tags=wisdom&user=judell -> expect 1, got 1242

(https://hypothes.is/api/search?user=judell -> 1235)

[nickstenning]

This is a result of this change: 7a9c8c7. Reverting back to a default AND rather than a default OR should be relatively straightforward. Say the word and it's done.

[judell]

Yes please!

[tilgovi]

I think that's a terrible idea. OR is a much more sensible default, to me.

I propose that instead of switching to AND you should remove the default order.

Either the stream view can specify the order or the a boosted created/updated facet could be used to consider a time/relevance trade-off.

In general, though, I think search APIs are much more user friendly when they return partial matches. Imagine if you got no results in a Google search every time you had a combination of words that didn't appear. Instead, Google shows you partial matches and tells you which words are missing.

[tilgovi]

If you removed the default order you would still get 1242 matches for https://hypothes.is/api/search?tags=wisdom&user=judell but the first one would be the one with the tag.

[judell]

In all of the API uses cases I'm aware of, default AND is the expected behavior. That's true also for interactive use cases I'm aware of, actually. So for our users, explicit search is the primary need.

To address the secondary need (fuzzy search) I'd like to start by surfacing our query facets explicitly in the UI, with inline prompts -- particularly for the any (wildcard) facet. That one arguably should offer an explicit choice between ANDing and ORing multiple terms.

[tilgovi]

I would consider whether these are just different APIs. To me, the stream search, as a user and developer, is much more useful if it's lenient. That's why I made that change.

If there's a need for a strict AND of the facets, maybe it's a different endpoint.

[tilgovi]

As I already said, Google is default OR. Elasticsearch itself defaults to OR for query string searches. If you're going to claim that every API you know does the opposite it might be good to name even one of them, @judell.

But I think the real issue is that filter/fetch is different intent than search.

[judell]

"But I think the real issue is that filter/fetch is different intent than
search."

True. The word "filter" better describes what the API and interactive users
I'm hearing from want to do. Once that's nailed down I'd like to revisit
what "search" would mean, and do so as part of a long-needed surfacing (and
inline documentation) of query facets (in particular, any) as first-class
elements of the UI.

On Mon, Oct 12, 2015 at 11:32 AM, Randall Leeds notifications@github.com
wrote:

As I already said, Google is default OR. Elasticsearch itself defaults to
OR for query string searches. If you're going to claim that every API you
know does the opposite it might be good to name even one of them, @judell
https://github.com/judell.

But I think the real issue is that filter/fetch is different intent than
search.

—
Reply to this email directly or view it on GitHub
#2540 (comment).

[judell]

Say the word and it's done.

"the word"

[jeremydean]

any progress here?

i have a teacher wanting to view individual user contributions within a tag, but has not been able to...

[seanh]

@jeremydean This is fixed but not deployed yet, so you'll see it fixed the next time we do a deploy (watch the releases channel in Slack)