[API-users] numDescendants in species/?name response

[Markus Döring]

Hello again James,

I have found the issue and it was a true bug. It should be fixed now and in the future. 
http://api.gbif.org/v1/species/102321492 <http://api.gbif.org/v1/species/102321492>

If you still happen to find such cases please report them to me!

Thanks,
Markus


> On 30 Jul 2015, at 10:06, Markus Döring <mdoering at gbif.org> wrote:
> 
> Hi James,
> 
> good news first, the Wikipedia and Index Fungorum datasets have been indexed and are back online.
> 
> The descendants issue you see is indeed some bug and should not be that way. I cannot explain it right now, but I’ll try to find the reason for it and reprocess the data accordingly.
> You should still be able to rely on numDescandants for your browser.
> 
> best,
> Markus
> 
> 
>> On 30 Jul 2015, at 00:05, Nozomi James Ytow <nozomi at biol.tsukuba.ac.jp> wrote:
>> 
>> 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-4f39-9b2a-bb099caae36c <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-41a8-a140-01abaa31c931
>> tells numDecendants=0 but there is 
>> http://api.gbif.org/v1/species/?name=Lembus%20infusionum&datasetKey=9ca92552-f23a-41a8-a140-01abaa31c931
>> 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
>> _______________________________________________
>> API-users mailing list
>> API-users at lists.gbif.org
>> http://lists.gbif.org/mailman/listinfo/api-users
>> 
> 
> _______________________________________________
> API-users mailing list
> API-users at lists.gbif.org
> http://lists.gbif.org/mailman/listinfo/api-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gbif.org/pipermail/api-users/attachments/20150730/fd1a915f/attachment.html>