Search filter parameters

[MikeThacker1]

I believe parameters to filter results are missing from the current API version. We're trying to standardise on the following for services in the UK:

• coverage - The postcode to use to check that a service applies to the specified area. (This is different from proximity as some people are only eligible for some services if they live in a specific borough.)
• day - Day(s) of the week on which a service is available
• end_time - Latest time(s) for which a service must be open on the specified day(s)
• maximum_age and minimum_age - These require our proposed extension to service eligibility
• postcode and proximity - To limit services to those within a given number of meters of the postcode's centroid
• start_time - Earliest time(s) for which a service must be open on the specified day(s)
• taxonomy_id - Taxonomy term identifier(s) that must apply to a service
• taxonomy_type - Type(s) of taxonomy relationship to which the taxonomy_id filter applies. This is needed if the UK proposed extension is implemented to allow taxonomy terms of different types (eg eligibility, target_audience, ...) to be applied. With the current Open Referral, it is not needed.
• text - text to perform a keyword search

[NeilMcKLogic]

Hey @MikeThacker1 and @greggish I provided a considerable amount of feedback on search several years ago. I did a quick search for "search" on the search page (see what I did there? :-) and found a number of issues being discussed.

I still think this is the biggest barrier to HSDA adoption and interoperability, especially because it would not be hard to formulate a spec and search is a primary use case for a social services API. At the time the standards body effectively chose to defer the topic until later (to my disappointment) and as far as I know, no one has taken it back up again.

Mike this list is a good start but I'd propose wading through those topics from a few years ago to perhaps consolidate the ideas and renew the efforts. From memory, here are the most salient ones to consider:

#62
#84

Neil

[MikeThacker1]

Thanks @NeilMcKechnie. It's normal that, as soon as I've posted an issue, someone points to it existing elsewhere (despite me having searched first). :-) #84 seems to provide a good summary of search points and you raise some important issues that we have not addressed in the UK, like sort order.

I fear that this is such big issue that individual implementations will only implement parts for search dependent on their own use cases. So we need a common framework for defining search (and/or filtering) and a way of knowing which parts are implemented by each API endpoint.

I'll try to steer UK implementations that try to be interoperable to follow any clear recommendation here until we get a formal search sprint.

[kinlane]

I am proposing we adopt an approach similar to GitHubs:

• Github
• Working thoughts