search

PhilanthropyDataCommons / service

A project for collecting and serving public information associated with grant applications
GNU Affero General Public License v3.0
9 stars 2 forks source link

Rank search results #332

Open slifty opened 1 year ago

slifty commented 1 year ago

Right now we're considering search results to be a filter, but probably we want to rank the results. This is another argument for splitting the search/nonsearch cases into separate queries. This is probably also future work, as I think we'd want to include the rank in the API response, and we don't need to blow up this PR or block on this suggested enhancement.

_Originally posted by @jasonaowen in https://github.com/PhilanthropyDataCommons/service/pull/320#discussion_r1183133196_

reefdog commented 1 year ago

@slifty in https://github.com/PhilanthropyDataCommons/service/pull/320#discussion_r1183775968:

do you think rank needs to be exposed as opposed to just sorted by? I'm not sure if rank will have meaning to a client since it's just gonna be a number between 0 and 1 with no real basis outside of the query context

I wouldn't display the rank in the Data Viewer interface, but I don't see the harm / do see some value in the API returning it. If nothing else it's an ordering redundancy (in a good way; rocket ships, not pink slips).

slifty commented 1 year ago

I hear you but I'd like to understand use cases a bit -- redundancy without purpose isn't necessarily a value add IMHO, since it introduces the opportunity for inconsistency in addition to adding to the payload size.

reefdog commented 1 year ago

Sure. I should have split my comment into more discrete comments:

  1. Feedback from an existing API consumer: I wouldn't display it on the front end, so prioritize accordingly. (As the Data Viewer dev actually using the API, @jasonaowen might know of more reasons than just "are we showing it in the interface".)
  2. Musings of an imaginary API consumer: I may want to only show search results above a certain confidence level. Might be nice to be able to make display choices independently.
  3. More musings of an imaginary API consumer: Do I really trust the result order of the API, or do I want to contextually enforce it by sorting by some attribute (createdAt some places, sort rank others)? While the Data Viewer is happy to essentially let the API dictate these things, Imaginary API Consumer X might not.

Just dropping some food for thought from my high chair like an infant with Cheerios.

jasonaowen commented 1 year ago

These are good points! I don't remember why it felt valuable to me to include in the API response, and this discussion hasn't come up with any sufficiently compelling reasons. If and when we come up with an actual use case, we can revisit!

reefdog commented 1 year ago

this discussion hasn't come up with any sufficiently compelling reasons

Hey!

reefdog commented 1 year ago

I mean, I agree, but still. Hey!

jasonaowen commented 1 year ago

Haha, sorry @reefdog, what I should have written out in more detail: those hypothetical use cases sound plausible, and if someone chimes in that they non-hypothetically want to do one of those things, then we should figure out the best way to include the ranking in that case! Until then, since we know the data-viewer doesn't want it and nobody else has asked for it, let's keep it simple.