Markus Döring
Markus Döring
This is fixed in the API, but still present in the exported DwC-A
Thanks. This is a really hard problem though. We explicitly intend to deviate from the verbatim classification as the whole purpose of the backbone is to align all occurrences onto...
is this needed urgently? I would really like to stop all work on the codebase and rather replace it as soon as possible with the COL ChecklistBank.
still the same in the latest build. That also exists in the current backbone though, so I would not consider this a blocker: http://api.gbif.org/v1/species/2489815 http://api.gbif.org/v1/species/match2?name=Basileuterus%20tristriatus
There are 44 datasets that have the same issue, not just the backbone. An accepted species record with species_fk not set. This looks more like a generic normalizer bug.
this does not happen for genus_fk or higher ranks.
When reimporting the same dataset the same usage keys have the problem, so it's unlikely a concurrency issue. The source data looks perfectly fine though.
I found a [small test dataset](https://www.gbif.org/dataset/7dbb1785-2e54-46f0-a823-7673b06c729b) with which I can reproduce the problem locally in a test!
The problem is bad data - if an accepted species has a parent of the same rank, the key will be nullified. For example Thuridilla kathae Gosliner, 1995 here has...
The issue lies in the homotypic grouping by the code: > Consolidating basionym group with HETEROTYPIC_SYNONYM primary usage Bostrichus fuscus (T.Marsham, 1802): Bostrichus fuscus (T.Marsham, 1802); Ptilinus fuscus (Geoffroy, 1785)...