Show outdated ambiguous synonym decisions on task board

[mdoering]

We need a way to report ambiguous synonym update decisions that have only one name left in the project. Ambiguous synonyms should have at least 2 names (accepted or synonym) which share the same canonical name & rank, but can differ in authorship.

Report those decisions only, so they can manually be fixed or removed.

[mdoering]

There is a new resource method /dataset/{key}/decision/stale that will list these stale decisions. @thomasstjerne can you add that to the task board please? It can take an optional subjectDatasetKey parameter if you want to restrict it to a specific source, e.g. workbench reports

[mdoering]

The new method shows 5143 stale decisions on the COL project: http://api.checklistbank.org/dataset/3/decision/stale

I have checked the first entry Phellinus gilvus and there indeed is just one name at this stage. @yroskov it seems a lot of cleanup is needed on stale decisions.

16 decisions in SF+: http://api.checklistbank.org/dataset/3/decision/stale?subjectDatasetKey=2073

[yroskov]

Report those decisions only, so they can manually be fixed or removed.

I agree.

[mdoering]

The method is limited to 100 decisions now, but does report the totals if there are more

[yroskov]

@thomasstjerne, thank you for the implementation of this important report.

Would it be possible to change the label from Stale Decisions to Outdated Decisions? (CoL widely used terms "orphan names", "orphan references" through its history. But Geoff rejected my suggestion for Orphan Decisions, and Bing think that "Outdated Decision" is a better term than Stale Decisions "Orphan Decisions. This implies that the decisions are no longer relevant or suitable for the current situation or standards". We'll have "Broken Decisions" and "Outdated Decisions" in the interface).

Unfortunately, I do not quite understand how to do fixes for outdated decisions?

Seems, there is no option to delete all these decisions in CoL-3 (I cannot tick (all) boxes, as well as there is no "Delete All" button):

Beside that, GSD@CoL Task page has no report on outdated decisions (Species Fungorum plus as an example):

And the question, what will be happened, if I delete outdated decisions in the release? Hmm, nothing happened. I cannot delete in the release. Perhaps, Rematch & Delete buttons are obsolete in the release interface, aren't?

[mdoering]

"Outdated" sounds good to me. Orphaned really means there is no reference to it any longer, which is not true here. There is still one name to which the decision is linked, but for the ambiguous status change you want at least 2 to exist.

Also agree there should be a way to bulk delete, but I am unclear how that should work. If we want a Delete All button we need the API to support deletions with filters, e.g. stale, source dataset, mode, etc. Editors would not see all the decisions to be deleted in that case. In the workbench we instead allowed to select/deselect individual decisions with a select all link. That way the UI only deletes decisions by their id one by one and the editor knows exactly what has been removed. But when you need to remove thousands this still becomes a pain. Do we want select boxes or a full delete all button and API method?

Releases are immutable. You should never be able to change them retrospectively. Neither names, decisions, sectors, references or anything else. We only made an exception for its dataset metadata. Immutable releases are crucial for users to use them as a stable reference and also for technical caching of data.

[mdoering]

@thomasstjerne @yroskov @gdower do we need to remove all links/buttons that modify data from the UI when viewing a release? It would make things clear, but I guess it's a lot of work to do this all over. Personally I am happy enough if we just show a clear error message when someone tries to delete or modify release data - which I guess we don't do right now?

[mdoering]

There actually already Is a delete with filter method, but that only accepts a (source) datasetKey and a broken query parameter so far.

[mdoering]

I have added a request filter to the API that rejects all modifications to non project datasets and responds with a http 405 method not allowed.

[thomasstjerne]

There actually already Is a delete with filter method, but that only accepts a (source) datasetKey and a broken query parameter so far.

Would you be able to add stale to that?

[yroskov]

Results of my experiment (2023-12-13) with deletion of all Ambiguous Synonym outdated decisions for Collembola.org in CoL-3 project via trash bin button, one by one: https://www.checklistbank.org/catalogue/3/decision?offset=0&stale=true&subjectDatasetKey=2130

Cleaned up names: Hypogastrura monticola Onychiurus pseudofimetarius Sira elongata Achorutes filiformis Podura aquatilis Sminthurides assimilis Dicyrtomina minuta f. ornata Onychiurus octopunctatus edenticulata

Collembola.org re-synced.

Ambiguous Synonym status is still appear in Assembly-CoL (https://www.checklistbank.org/catalogue/3/assembly?assemblyTaxonKey=lEMYCBMbQzfY28Xlx_VZ_0):

PREVIEW id 281824 released 2023-12-13: Ambiguos Synonym status is still stay with all Collembola.org "cleaned" names: https://preview.catalogueoflife.org/data/taxon/4XX37

@thomasstjerne, @mdoering does "delete" decision work in Stale Decisions report?

I repeated experiment today (2023-12-14). It looks like "delete" decision works:

[yroskov]

• [ ] @thomasstjerne, would it be possible to include checklist Alias instead of full name in the report: https://www.checklistbank.org/catalogue/3/decision?limit=100&offset=0&stale=true

(It took a time, to figure out that "Synonymic Checklists of the Vascular Plants of the World" means "World Plants")

[gdower]

@thomasstjerne @yroskov @gdower do we need to remove all links/buttons that modify data from the UI when viewing a release? It would make things clear, but I guess it's a lot of work to do this all over. Personally I am happy enough if we just show a clear error message when someone tries to delete or modify release data - which I guess we don't do right now?

I think displaying an error message would be sufficient. The UI does animate the deletion, so it appears like it was deleted until you reload the page.