[API-users] numDescendants in species/?name response
Markus Döring
mdoering at gbif.org
Thu Jul 30 11:52:03 CEST 2015
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>
More information about the API-users
mailing list