Hi Markus,
the issue is that some non-GBIF backbone records telling zero numDecendants althoug they have child record(s) in their dataset(s). I expcect non-zero numDecendants value if there is/are child/children record(s) in the same dataset, as previous.
If you search the GBIF backbone for Lembus you get 2 records. One synonym without descendants and one accepted taxon: http://api.gbif.org/v1/species/?name=Lembus&datasetKey=d7dddbf4-2cf0-4f3... http://api.gbif.org/v1/species/?name=Lembus&datasetKey=d7dddbf4-2cf0-4f39-9b2a-bb099caae36c
numDecendants works as previous for GBIF backbone records, but not for other dataset. For example, http://api.gbif.org/v1/species/?name=Lembus&datasetKey=9ca92552-f23a-41a... tells numDecendants=0 but there is http://api.gbif.org/v1/species/?name=Lembus%20infusionum&datasetKey=9ca9... of which parentKey designanates the record above. I expect the numDecendants of the Lembus record designated by the parentKey to have non-zero value.
That looks correct to me and the synonym also does not return any children correctly: http://api.gbif.org/v1/species/2386427/children http://api.gbif.org/v1/species/2386427/children
It is right bebause the record does not have child recods.
We did change the underlying checklistbank database today which introduces considerable new data as all data in there has been freshly crawled from scratch. Datasets that have been offline, e.g. NZOR, are therefore currently still missing. We also had some issue indexing wikipedia and Index Fungorum, so those 2 are also not yet in but I hope to get those indexed over the weekend latest. Lacking wikipedia unfortunately means there are much less vernacular names, descriptions and images available also for the GBIF backbone.
It might be side-effect of the change. I wait for a while...
The backbone itself has not changed at all.
It is not isssue of the backbone. Checklistbank is a good datasouce of taxon concepts captured in datasets.
James