Inheritage of map lists
This is just an issue to start brainstorming on the map list inheritance and social scores. As it is implemented so far, there are several issues :
- we don't control from which group/team we inherit,
- You can inherit of some weird grouping that could be misleading in a map, and it take lot of time to fix (degrouping is time consuming)
The goal of map list inheritance is to spead up annotation, give new heuristic and improve collaborative work, but it should not lead to misleading first maps representation.
Here is an example of a group that appear in a private analysis although I have never group terms like this :
A new user that would take the first map at face value would think that drug could be linked to things associated to cancer treatment for example even if in the corpora there is no such thing (there are several cancer treatments that are not associated with drugs).
So my suggestion would be :
- differentiate the scores of the forms and the scores of the groups.
- default inheritance of groups should only take place within a team and not propagate to other teams or private spaces.
- social scores of forms is used in the NLP pipeline to select the forms on which to compute the inclusion/genericity score, so that forms with high social score are more likely to appear as candidates in the term table. But after this, only individual annotations are used by default to upgrade forms to maplists.
- All other maplisting or grouping should be explicitly made by the user after the NLP pipeline. The user go and import the map/groups from a particular team of a particular project directly form the term table or from the node modal.
- social scores could be displayed in the term table to make it easier to find forms with high social score and add them in the map.