Some "Services" fields not showing up

[devinbalkind]

The following "Services" fields don't appear to be displaying in this application:

• Keywords
• Service Areas
• Wait

I've filled out these fields in the API here: http://ohana-api-demo.herokuapp.com/admin/locations/the-location-is-a-phone/services/31

But they don't show up here: http://ohana-web-search-demo.herokuapp.com/organizations/salvation-army/the-location-is-a-phone?keyword=housing&utf8=%E2%9C%93

Image of the fields filled out in the API interface attached.

[anselmbradford]

(Referencing codeforamerica/ohana-api#170 (comment) here)

This is intentional/a legacy of the project development. Here's the thinking behind not including these fields:

• Keywords. This is for aiding in matching an entry to a keyword search. It's not intended for an end user to view all the possible keyword matches, so it's excluded from the details view. Keywords could have redundancies, non-sensical phrases when viewed on their own, etc. They should be a part of the admin interface so they can be set, but the ohana-web-search interface has a different set of users in mind (info referrers and help seekers—not data admins).
• Wait times. Two reasons this field was excluded: (1) our original data set in San Mateo County had many different formats for this field and (2) this field in particular is very sensitive to being out-of-date. Without a reliable update mechanism for this data that approaches realtime, this field could do more harm than good in conveying information about an entry. It was therefore excluded.
• Service Areas. This field was excluded, because like wait times, it had issues with consistency in its data, but more importantly because the original project was for San Mateo County, so entries viewed automatically service a relatively confined geographic area. This just became another field that could become outdated and show a lack of service where there actually were services provided, therefore it was excluded.

That's the background. As to the future of these:

• For keywords I don't see a good reason to include them in the details display, as they are essentially metadata. However, I would be curious if anyone has a different opinion on that?
• For wait times, I could see us including this field but under a different label. As "wait times" it really implies more than what the system can currently provide. Perhaps something like "Service wait estimates" would be better. Thoughts on this?
• For service areas, this would be alright to include. We have another issue that talks about this field and including them would allow adding a filter on a service area.

[devinbalkind]

Thanks for this very thorough response.

It makes sense to me that keywords are meta data, but I do think providing an flat categorization option (tags) would be extremely useful for projects like mine which has descriptive terms that go beyond what's currently available in the Open Eligibility services taxonomy. I'm sure it's been discussed whether or not to include tags/tag clouds. I vote yes to it. :)

I agree with @monfresh about service area. In NYC a lot of services are only available to people in specific boroughs and neighbourhoods so having this displayed and filterable would be useful.

As an aside: who has the names and polygon files of of all the neighbourhoods in America? ;)

[anselmbradford]

It makes sense to me that keywords are meta data, but I do think providing an flat categorization option (tags) would be extremely useful for projects like mine which has descriptive terms that go beyond what's currently available in the Open Eligibility services taxonomy.

Mmm, yes the idea of 'tags' makes sense. I wonder though, semantically, aren't categories and keywords kind of the same thing? We differentiate them in the search algorithm, but for the UI in the details view I feel like they may seem like the same thing; though I recognize the difference the category hierarchy introduces. @monfresh or @spara can correct me if I'm wrong, but Open Eligibility is just a recommendation, and it's the taxonomy we're going with, but a community could theoretically take that categorization field and do whatever they wanted with it. However, we do enforce it through the UI on the admin interface.
For adding the notion of keywords/tags, there are few directions I can think of:

a) Add keywords to detail view as separate labelled section (called 'tags').
b) Add keywords to detail view combined with the categorization UI, perhaps so keywords appear to be top-level categories from the perspective of the end user.
c) Add feature to admin interface to add/edit the list of service categories.

Any thoughts on any of those directions?

As an aside: who has the names and polygon files of of all the neighbourhoods in America? ;)

Haha, yes, data is always the root of the issue, right! For the original dataset the service areas listed were for the most part at the county and state level (and mostly only for California), so theoretically much more manageable to map... but I think at this point #13 should be closed and Service Areas should be implemented in this issue as text to begin with.

[monfresh]

@devinbalkind, when you say you want a "flat categorization option", do you mean in the admin interface or in the web search app, or both? In the admin interface, keywords are your flat categorization option. You can add any keyword you want.

When you say "include tags/tag clouds", do you mean in the web search app? If so, how do you envision this being used? Do you mean you would like to present a list of tags that are clickable and that take you to locations that are tagged with those keywords? If so, perhaps the list of links on the home page would be a good place for that. The text for the links that appear on the home page are all customizable via the settings.yml file.

[anselmbradford]

@monfresh, @devinbalkind is talking about in Ohana Web Search. My question is just whether there's semantic a difference between categories and keywords (outside of search algorithm difference) and whether we're mandating the Open Eligibility taxonomy be used for the categories or if any community could choose its own taxonomy.

[monfresh]

The difference is that keywords are flat and categories use a tree/hierarchical structure. You can use your own taxonomy, as mentioned in the README.

[devinbalkind]

@anselmbradford Option "c" would be my preference but option "a' would be sufficient for my current needs.

When it comes to editing service categories, I think it would be ideal if:

• I could pick from existing taxonomies (such as Open Eligibility)
• Edit taxonomy from the UI, have all the changes recorded in a log and have the ability to revert to previous versions.
• Create my own taxonomy from the UI. The current process for creating my own taxonomy is something that I'll need a dev friend to translate for me but that seems doable. I'm not afraid of markup/XML
• Import/Export my own taxonomies (would need a format/template for that)

I agree that service areas should be implemented as text.

I like hierarchical categorization of services. That's what service providers seem to be comfortable with. That said, I do like how auntbertha uses tags for eligibility info. And to go one (or more) steps deeper, I'm wondering if eligibility tags could be turned into open badges (http://openbadges.org/) and social service orgs could use that system to document and share information about individual's eligibility. But that's definitely out of scope of this conversation. Sorry - couldn't help myself. :)

@monfresh Yes keywords is a good "flat categorization option". Having them appear in the web search interface on individual locations/services would be useful. The ability to click on the tag to see a filtered list of other locations/services with that tag would also be useful. I agree that the list of links on the home page would be a good place to display the tags. The YAML seems easy enough to understand/modify that even a non-coder like myself could make the necessary changes.

[anselmbradford]

Is there a difference between keywords and a category taxonomy that's one-level deep? A flat taxonomy is just a hierarchical taxonomy without any children. @devinbalkind does the customization of the taxonomy referenced by @monfresh help your needs? Or would (a) still be preferable to include?

[monfresh]

@devinbalkind The API only supports one taxonomy at a time, and does not support the maintenance of the taxonomy itself. You won't be able to export it easily, and the DB will not store multiple versions of the taxonomy.

For that, I recommend maintaining your taxonomy as a separate project, and you can then import whichever version of your taxonomy into the API. This is how we currently import the OpenEligibility taxonomy. They maintain it as a separate project here: https://github.com/auntbertha/openeligibility/blob/master/taxonomy

What I did then was convert their XML into JSON in this file: https://github.com/codeforamerica/ohana-api/blob/master/data/oe.json

And then I wrote a script to parse the JSON and create the Categories in the DB: https://github.com/codeforamerica/ohana-api/blob/master/lib/tasks/oe.rake

The script assumes that each Category has 2 required attributes: the name or title, and a unique ID, and that the JSON or XML defines the parents and children of each category so you can properly create the structure.

The advantage of creating and maintaining your taxonomy as a separate project is that other people can use it as well. You also get versioning out of the box if you use Git/GitHub to maintain it.

If you wanted to create the taxonomy directly in the app, you could do it from the command line with the help of a developer friend. It's quite easy. Here is an example that shows 2 top level categories and 2 children for each category:

# Go to the Rails console (after installing the app locally)
$ rails c
> top_level_1 = Category.create!(name: 'Emergency', oe_id: '101')
> top_level_2 = Category.create!(name: 'Health', oe_id: '102')
> child_1_of_top_level_1 = top_level_1.children.create!(name: 'Emergency Cash', oe_id: '101-01')
> child_2_of_top_level_1 = top_level_1.children.create!(name: 'Emergency Food', oe_id: '101-02')
> child_1_of_top_level_2 = top_level_2.children.create!(name: 'Medical Care', oe_id: '102-01')
> child_2_of_top_level_2 = top_level_2.children.create!(name: 'Vision Tests', oe_id: '102-02')

Basically, you use Category.create! for all top-level categories, and .children.create! for the subcategories.

[monfresh]

@devinbalkind when you say that you like Aunt Bertha's tags for eligibility info, I'm assuming you mean terms like "veterans", "in crisis", and "unemployed" that appear under the "WHO" section like in this screenshot:

If that's what you're referring to, then those tags are actually also part of the OpenEligibility taxonomy under the Human Situations section. Those seem worthwhile to add to the API, and then the Web Search app would allow users to search based on those situations.

[devinbalkind]

@monfresh I'll take you up on that recommendation of maintaining the taxonomy on as a Github project. That should work well for us. And yes, your assumption is correct: I'm talking about Human Situations.

Thanks.