New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Search + Taxonomy #19

Open
kinlane opened this Issue May 12, 2017 · 8 comments

Comments

Projects
None yet
4 participants
@kinlane
Contributor

kinlane commented May 12, 2017

This has been migrated from Ohana (codeforamerica/ohana-api#417 (comment)), and worth considering as part of specification:

As part of Code for Miami's involvement with the Knight Cities Challenge, we recently conducted a Civic User Testing Group in Miami with a reskinned version of the Ohana web search. You can find our thoughts here.

We then built a follow-up prototype and performed CUTGroup testing for that prototype as well.

While developing this follow up project, we noticed the API is not configured to return taxonomy data in a keyword search. To get around this, our app ran an initial keyword search to get category data, iterate through each result, and then a second search for that particular organization’s details.

As a result, if a search for the keyword “food” returns 50 organizations, the app must make 51 calls to the API (one for the initial search, and one for each of the 50 organizations in the results). As a result, the app suffered from noticeable performance issues that would not be sustainable at scale.

We can solve this in two ways:

Refactor the API to return taxonomy data in keyword search results; or
Create a second API that allows third parties to copy the vendor provider’s entire data set into their database, which they can then customize for more efficient searches.

@kinlane kinlane added the enhancement label May 12, 2017

@greggish

This comment has been minimized.

Show comment
Hide comment
@greggish

greggish May 12, 2017

Member

FYI, here is the CUTGroup report, and here is the analysis from the front-end development test.

There was some back and forth about this in the Ohana issue thread, but I don't think the issue was resolved. cc @ErnieAtLYD @davidjamesknight @monfresh

Member

greggish commented May 12, 2017

FYI, here is the CUTGroup report, and here is the analysis from the front-end development test.

There was some back and forth about this in the Ohana issue thread, but I don't think the issue was resolved. cc @ErnieAtLYD @davidjamesknight @monfresh

@kinlane

This comment has been minimized.

Show comment
Hide comment
@kinlane

kinlane May 24, 2017

Contributor

I'm proposing that we leave taxonomy out of v1.1 of the specification, and save it for consideration in v1.2 or beyond.

While the schema is straightforward, I think the access around this needs more discussion and thought -- also keeping v1.1 a simpler release.

Schema - https://openreferral.readthedocs.io/en/latest/reference/#taxonomy

Contributor

kinlane commented May 24, 2017

I'm proposing that we leave taxonomy out of v1.1 of the specification, and save it for consideration in v1.2 or beyond.

While the schema is straightforward, I think the access around this needs more discussion and thought -- also keeping v1.1 a simpler release.

Schema - https://openreferral.readthedocs.io/en/latest/reference/#taxonomy

@NeilMcKechnie

This comment has been minimized.

Show comment
Hide comment
@NeilMcKechnie

NeilMcKechnie Jun 15, 2017

To me this just illuminates the need to be careful about what to return (and not return) in search results so that a multitude of additional round trips through the API, in practical applications, are not necessary. The spec should assert an "opinion" about that so all implementers are aware of this and expose methods that are practically both useful and scalable.

NeilMcKechnie commented Jun 15, 2017

To me this just illuminates the need to be careful about what to return (and not return) in search results so that a multitude of additional round trips through the API, in practical applications, are not necessary. The spec should assert an "opinion" about that so all implementers are aware of this and expose methods that are practically both useful and scalable.

@kinlane

This comment has been minimized.

Show comment
Hide comment
@kinlane

kinlane Jun 16, 2017

Contributor

@NeilMcKechnie agreed. So much to think about when loading up a single API path, or spreading out across many specially designed API paths. Key is how to keep intuitive and simple, but allowing consumers to easily scratch and get more. Allow for wide use cases from bulk upload system to system, all the way to single phone number lookup using Amazon Alex. I'd like to see simple all the way to complex views of /search/, as well as taxonomy based dimensions where you can quickly filter, and navigate a database based upon many different taxonomies. I'd like to get a coherent /search plan articulated as part of next version v1.2.

Contributor

kinlane commented Jun 16, 2017

@NeilMcKechnie agreed. So much to think about when loading up a single API path, or spreading out across many specially designed API paths. Key is how to keep intuitive and simple, but allowing consumers to easily scratch and get more. Allow for wide use cases from bulk upload system to system, all the way to single phone number lookup using Amazon Alex. I'd like to see simple all the way to complex views of /search/, as well as taxonomy based dimensions where you can quickly filter, and navigate a database based upon many different taxonomies. I'd like to get a coherent /search plan articulated as part of next version v1.2.

@kinlane

This comment has been minimized.

Show comment
Hide comment
@kinlane

kinlane Jul 9, 2017

Contributor

Another data point I'd normally have from existing API management operations, and would like to gather from this group is mobile vs web, and increasingly messaging (slack, fb), and voice (alexa). With web connectivity returns everything someone desires is not really a problem, offloading on the web interface to sort it out. With mobile, returning everything becomes a problem. We need a precise schema to minimize network latency. The same is going to be true for the newer channels like messaging and voice.

Contributor

kinlane commented Jul 9, 2017

Another data point I'd normally have from existing API management operations, and would like to gather from this group is mobile vs web, and increasingly messaging (slack, fb), and voice (alexa). With web connectivity returns everything someone desires is not really a problem, offloading on the web interface to sort it out. With mobile, returning everything becomes a problem. We need a precise schema to minimize network latency. The same is going to be true for the newer channels like messaging and voice.

@NeilMcKechnie

This comment has been minimized.

Show comment
Hide comment
@NeilMcKechnie

NeilMcKechnie Aug 10, 2017

@kinlane , so where are we landing on this very important topic?

NeilMcKechnie commented Aug 10, 2017

@kinlane , so where are we landing on this very important topic?

@dsurrao

This comment has been minimized.

Show comment
Hide comment
@dsurrao

dsurrao Sep 16, 2017

Is Taxonomy ready to try out in the v1.2 draft API?
https://openreferral.github.io/api-specification/hsda-taxonomy/

dsurrao commented Sep 16, 2017

Is Taxonomy ready to try out in the v1.2 draft API?
https://openreferral.github.io/api-specification/hsda-taxonomy/

@kinlane

This comment has been minimized.

Show comment
Hide comment
@kinlane

kinlane Sep 19, 2017

Contributor

The taxonomy has been separated out into its own service, that works with HSDA v1.2. The definition has been reset has v1.0, and is up for feedback.

It is currently in a feedback phase, so I'd give another 30 days before it is ready, but I will be moving forward the demo code alongside the feedback, and happy to ping you when in a functional state (https://github.com/human-services/hsda-taxonomy).

Contributor

kinlane commented Sep 19, 2017

The taxonomy has been separated out into its own service, that works with HSDA v1.2. The definition has been reset has v1.0, and is up for feedback.

It is currently in a feedback phase, so I'd give another 30 days before it is ready, but I will be moving forward the demo code alongside the feedback, and happy to ping you when in a functional state (https://github.com/human-services/hsda-taxonomy).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment