type in the organization data model

[spara]

Type is not in the organization model, if we add it it should be called organization_type instead of just type. The reason is that if we use elasticsearch, type is a reserved word.

[anselmbradford]

My 2cents... I'd opt for "entry_type" to generalize the applicable data.

[spara]

Works for me; although I would like an enumerated list of entry_types a la openeligibility. I like bounds in my universe, string typing and all of that.

[monfresh]

If we use the OpenEligibility categories, then I think we should just rename our keywords field to categories. Each organization would have one or more categories (based on the services they provide), and each category belongs to one top-level category, defined in a separate collection. This is what I am proposing in issue #45.

[anselmbradford]

I think that's the structure here too: codeforamerica/ohana-web-search#30

[monfresh]

The API now supports both categories (for OpenEligibility taxonomy) and kind to define the general type of organization, such as farmers' markets, museums, libraries, parks, entertainment, human services, etc.. As an initial step towards making the search results more human services-centric, we are marking any non-human services locations as kind="other", and we can then filter out all "other" locations from SMC-Connect until we have tagged all human services locations, at which point we can use the kind=human filter.