GNIP: group categories functionality

[cezio]

Overview

GeoNode groups mechanism is a good way to manage users and resources. However, on large installations, additional management measures may be needed. Group categories can enhance group management by adding additional level of grouping, or by grouping in different dimension.

Proposed by

Cezary Statkiewicz GeoSolutions

Assigned to release

None yet.

Motivation

Group Categories is additional administration feature, which would help managing groups within large installations (working use case is an installation with over 200+ groups created). Groups would be categorized by arbitrary criteria, like type of group (local/country group, institutions, specific projects).

Proposal

Model changes

Group Categories functionality will enhance current geonode.groups.models module with GroupCategory model, which will allow m2m relation with GroupProfile.

UI changes

Group Categories will be added in several places in UI layer:

• new menu item in Data: Group Categories

  

• new Add Group Category view

  

• new Edit Group Category view:

  

• Group Categories will list available categories and member count.

  

  Each item in list will link to Group list view with groups in given category

  

• Add Group form will have categories selection

  

• Group list will have additional filter for categories

  

• Group detail view will have a list of Categories assigned to group

  

[afabiani]

+1

[jj0hns0n]

This sounds great. I do think adding the Group Categories to the menu might be overkill. You should also allow for a group category description possibly.

[jondoig]

Why category and not keyword? Why for groups and not for everything (layers, maps, documents, users)? Is there any relationship between group category and existing ISO19115 TopicCategory for layers?

At some point the data model offered in the base Geonode platform risks getting overloaded. Imho that is a risk here.

At my work I have been exploring the use of semantics with @rob-metalinkage to add arbitrary yet precise knowledge about resources to aid discovery and use. Semantics might be a better way to approach this as it is open and extensible without adding baggage. From the UI that might look more like an extended keyword feature that uses, and allows extension of, published vocabularies.

[rob-metalinkage]

If categories are really just classifications, then having descriptions and possible cross-references to related categories, etc - and of course potentially multi-lingual labels - it does seem as if its basically just a requirement for an enhanced semantics capability for tagging. Rather than N "myObjectCategory" models for each possible case, it is possible to upgrade generic tagging to more general model of "categorisation dimension" that can be added to any model and the dimension bound to a formalised vocabulary and semantic-relationship system (such as the django-skosxl).

Note in the updated django-skosxl module the dependency on taggit has been disabled - the idea was to connect it up again to a hierarchical tagging system - but havent yet identified the best candidate.

[cezio]

This sounds great. I do think adding the Group Categories to the menu might be overkill. You should also allow for a group category description possibly.

Yep, description is a good idea. I'm not sure however, where elsewhere attach group categories management in UI. Groups can be managed within user-facing UI (without admin part), so Group Categories should be available near by too for consistency.

Why category and not keyword? Why for groups and not for everything (layers, maps, documents, users)? Is there any relationship between group category and existing ISO19115 TopicCategory for layers?

There are several reasons for that: keywords are free-form, they are not normalized, and don't provide any additional functionality. Content categorization is completely separate from users categorization, so I don't think we should mix this (in terms of semantics and functionality).

At some point the data model offered in the base Geonode platform risks getting overloaded. Imho that is a risk here. At my work I have been exploring the use of semantics with @rob-metalinkage to add arbitrary yet precise knowledge about resources to aid discovery and use. Semantics might be a better way to approach this as it is open and extensible without adding baggage. From the UI that might look more like an extended keyword feature that uses, and allows extension of, published vocabularies.

I agree, it's a feature similar to features GeoNode has elsewhere. But use case is completely different - this is user management part, not content management. Besides, it's not mandatory - model allows to ignore Group Categories, so if you don't need them, you don't use.

[cezio]

closing, since PR has been merged