search

biigle / label-trees

:m: BIIGLE module to create, edit and manage label trees
0 stars 0 forks source link

Implement editable label color and name in the UI #24

Closed mzur closed 6 years ago

mzur commented 6 years ago

Only after I implemented the changes for #21 I realized that unconditionally editable labels might not be a very good idea. If you wanted to use a label tree controlled by someone else in your own project, you'd have to trust that person not to mess with the label names. Although used labels cannot be deleted, the owner of the label tree could change a label from "coral" to "stone", for example.

@dlangenk What do you think, should we explicitly disallow editing the name of a label once it is used somewhere? What about the color?

mzur commented 6 years ago

We haven't decided on what to do yet. Each option has trade-offs:

  1. Dont' allow any modification on labels that are in use. This prevents owners of label trees to mess with the annotations of other users. We want to make re-use and sharing of label trees as attractive as possible. Users should be able to trust BIIGLE that the label trees they want to use don't change in unexpected ways. However, this also prevents "legitimate" modifications to labels. Example: A label "not sure if species xy" is changed to "xy" once it becomes clear what species is observed.

  2. Unconditionally allow modifications to labels. This would allow a user (owner of the label tree) to modify annotations that they should not be able to access.

A middle way does not exist as far as I can tell. A possible (but quite complex!) alternative might be versioning of label trees. Projects then use only a specific, immutable version of a label tree. Whenever a label tree is modified, a new version is created.

mzur commented 6 years ago

We chose option 2, unconditionally allow edits to existing labels. Once forking of label trees ( #4 ) is implemented, users who don't trust owners of label trees can just fork them to their own version.