Multiple deletion and updates of tags and links as bulk operation

[GiantEnemyCrab]

Is your feature request related to a problem? Please describe.

Being able to highlight multiple phrases, then click delete to apply deletion on multiple items at one time, rather than clicking every single entity to apply deletion.

Also, this could apply to semantic links. Select multiple from the right side pane where all the links are listed, and apply deletion at once.

Describe the solution you'd like

I ended up describing this above.

Describe alternatives you've considered

None, and just been rely on people to select every single tag or link.

Additional context

None

[reckart]

In INCEpTION, one can search for annotations and then bulk-delete the annotations.

[GiantEnemyCrab]

Thanks for quick response!
Also, I believe INCEpTION allows bulk-assign tags, too?

[reckart]

Also, I believe INCEpTION allows bulk-assign tags, too?

Yes.

That said, I think adding the ability to select multiple annotations might be doable as well. It's not a small change but also probably not one which would require major rewrites. So let's keep this one open.

[GiantEnemyCrab]

Thanks, and right, that an annotator or curator may very well wish to, rather than using "search", highlight the multiple tags of interest from text panel GUI and apply the change to them all, like assigning to the new and same tag.

In that case, may I rename the Github issue title to "Allow selection of multiple tags or links to apply batch change". (or bulk change, whichever phrase you are more comfortable with)

[reckart]

Well, these are somewhat different use-cases.

For bulk-deletion, one can select multiple annotations regardless of which layer they belong to and just delete all of them.

For bulk-change, the annotations must all belong to the same layer. Also, for layers with more than one feature, one would have specially handle the case where some feature may have the different values across the selected annotations (thing of for example a boolean feature which could be true, false, or "undecided" depending on the selected annotations). This second use-case is quite a bit more complicated and quite a bit more effort.

[GiantEnemyCrab]

I see about layers and how that would have higher complexity, and restriction of having to belong the same layer sounds appropriate (but code would have to check for if the tags belong to the same layer in GUI upon selection or upon value assignment ?). If bulk deletion is allowed across all layers, then checking for if all the selected tags belong to the same layer may not be relevant to do upon multiple tag selection.

Also, these could be probably implemented as separate features?

Like, first, implement multiple tag selection plus bulk deletion, which has less complexity. Then later on add the bulk-change. But I am making some assumptions and in reality this may not be as simple to implement features in sequence and separately.

[reckart]

I think if/when this is tackled, it definitely makes sense to first implement the multi-select + delete feature.

Then building on that, one could implement a basic version of multi-update which would only work if all selected annotations are from the same layer and. It might start with not filling in any values into the feature editors on multi-selected.

Then, a more sophisticated version of multi-update could check if all selected annotations share certain feature values and fill them into the respective editors (keeping those blank or in some "undefined" state where the values vary cross the selected annotations).

[GiantEnemyCrab]

Thanks for the insight, and makes sense, and initially apply the logic to allow multiple update if all selected tags are from the same layer. And such restriction may turn out to be fine in some sense, in that allowing any tags from all layers could result in accidental and unintentional changes in some situations.

[reckart]

Supporting bulk-changes on annotations from multiple layers IMHO doesn't make much sense at all, because usually they will have different or incompatibly configured features. I expect that the case where multiple layers have some feature with the exact same name and configuration is rather rare.

[GiantEnemyCrab]

Right, and I can share with you (I may have shared this with you already though), that at least in my team's use case, current projects are configured with 1 layer only.