Use Organization.type for grouping Organization.category

[greatislander]

Reconsidering #90, it seems that we should include both Organization.type and Organization.category. Categories should be grouped by type, rather than by a standalone Organization.category_group field. So we should have the following:

Types:

• Cooperative
• Potential cooperative (platform-based business, exploring transition to a co-op model)
• Shared platform (platform-based business with shared ownership/benefit model, not exploring transition to a co-op model)
• Supporting organization (business, academic institution or non-profit organization which supports the movement in some way)

(Resources and individuals should be removed as types. There's only one individual which doesn't appear to be an individual, and many of the resources should be reclassified.)

In terms of categories, they should be assigned as follows:

• Any category that corresponds to a co-op should be assigned to the Cooperative type.
• Any category that corresponds to a platform-based business exploring transition to a co-op model should be assigned to the Potential cooperative type. This should only be used for those organizations actively exploring transition to a co-op model.
• Any category that corresponds to a platform-based business with shared ownership/benefit model that is not exploring transition to a co-op model should be assigned to the Shared platform type.
• Any category that corresponds to other business or organizations should be assigned to the Supporting organization type (e.g. a consultancy, a bank, a service provider/vendor, an academic institution, a foundation, etc).

Clustering would then be organized by type, not by category group (see #1).

[greatislander]

For your consideration, @cherylhjli @dayotte @erictheise.

[erictheise]

While it's true that the entity tagged individual was not an individual (like all entities with .type that entity came in via ioo.coop data) we do have Users and dropping them as a type complicates the question of how to bring them in for display on the map.

My initial idea was to use .type, of which an entity could have exactly one, as both the field that would be the header of the cards below the map, to have those color-coded by .type, and to use those same colors in a ring chart over the clusters on the map to show the makeup of entities in the cluster similar to this example.

[greatislander]

@erictheise This change is only meant to affect Organizations. I'm not sure if I'm understanding your concern fully. Wouldn't Users be brought in for map display separately (via the User model, which has an implicit type of individual)?

[greatislander]

@erictheise Ah, so the idea would be we add type (with singular value of individual) to all Individuals? That makes sense to me.

[greatislander]

Also the clustering approach looks great.

[erictheise]

So the proposal is to limit Organization.type to the values available in yesterday's addition, Organization.category_group, and then to drop .category_type again? Sounds like what we had before.

I haven't looked to see how many resources there are but the idea is that they would not go into the ring chart or be mapped unless they are an Organization with a recognized .type or are an individual?