Map CIP keywords to OpenEligibility terms

[monfresh]

Add Mongoid scopes to allow front-end app to filter search results by organization type. Create scopes for all keywords that currently exist from CIP data, such as: Markets, Parks, Food pantries, CalFresh assistance, Hot Meals, Food served.

[monfresh]

When I first opened this issue, I thought we would — in MVP fashion — simply display the keywords as they are currently labeled in the CIP data, but I don't think that's the right approach. It would result in too many keywords displayed, some of which might not make sense to our clients. Here's what I'm proposing:

• Go through all the keywords/subjects used by the CIP data and rename them to a sub-category they best fit in.
  • Let's use the OpenEligibilty taxonomy to start with, and add our own for government/county services like parks, sheriff's office, etc.
  • If a CIP keyword most closely matches a top-level category, then delete it
• Populate our database with these new keywords
• Create a new Mongoid collection for top-level categories and assign each top-level category a list of sub-categories
  • If we agree on OpenEligibilty, this can be done in parallel with the data cleanup above
• Create a Mongoid scope for each top-level category
• Create a Mongoid scope for each sub-category

[anselmbradford]

OpenEligibility or W3C's CivicServices? http://www.w3.org/wiki/WebSchemas/CivicServices

[monfresh]

From what I understand, schema.org is an attempt to standardize the way information is labeled on a website, in order to make it easier for search engines to parse the information. The Civic Services schema, which is still in the proposal stage (see PDF), serves a different purpose than OpenEligibility. It is not attempting to propose a new taxonomy for naming the services themselves, but rather, a way to mark up the services in HTML.

Here's a snippet from the schema proposal:

<div itemscope itemtype=”http://schema.org/GovernmentService”>
  <link itemprop=”url” href=”http://on.nyc.gov/fsep” />
  <span itemprop=”name”>NYC Food Service Establishment Permit Service</span>
</div>

The name of the service itself is not part of the schema. The way it is marked up in the HTML is. Those are two separate issues. Categorizing the data according to a taxonomy is an API feature that will allow any client that consumes the API to better filter the data. The schema.org markup is a front-end feature that is up to third-party clients to implement on their website.

[anselmbradford]

Gotcha, that makes sense. You're right, I see how this is two different problems. It may be beneficial to apply the CivicServices schema to the backend insofar as using the same database field names and hierarchy as what is defined in the CivicServices schema for applicable data.

[monfresh]

We have opted to keep both CIP keywords and the OpenEligibility taxonomy to enhance search results. Abbreviations that users might use and that aren't part of the OE taxonomy can be captured in the keywords field.