numDescendants in species/?name response

Hi, is there any modification made in numDescendants in species/?name response? For example, http://api.gbif.org/v1/species/?name=Lembus returened one record with 2 descendants (I remember it as http://api.gbif.org/v1/species/102321492 ) and two records with 16 descendatns arournt 2015-07-29 04:00 UTC (ish) but now only one record of GBIF Backborn Taxonomy with 16 descendants and others have no descendants. http://api.gbif.org/v1/species/?name=Lembus%20infusionum was shered lower name in there three records. http://api.gbif.org/v1/species/102321493 is one of Lembus infusionum which has parentKey 102321492. The parent key is the record had two descandants. The modified implementation requires to try /species/{int}/children even if numDescendants is zero, because there may be descendants. I prefer to the previous implementation to navigate classifications. James

Hi James, I am not sure if I understand the problem. 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-9b... <http://api.gbif.org/v1/species/?name=Lembus&datasetKey=d7dddbf4-2cf0-4f39-9b2a-bb099caae36c> 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> 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. The backbone itself has not changed at all. Markus
On 29 Jul 2015, at 16:15, Nozomi James Ytow <nozomi@biol.tsukuba.ac.jp> wrote:
Hi,
is there any modification made in numDescendants in species/?name response?
For example, http://api.gbif.org/v1/species/?name=Lembus returened one record with 2 descendants (I remember it as http://api.gbif.org/v1/species/102321492 ) and two records with 16 descendatns arournt 2015-07-29 04:00 UTC (ish) but now only one record of GBIF Backborn Taxonomy with 16 descendants and others have no descendants.
http://api.gbif.org/v1/species/?name=Lembus%20infusionum was shered lower name in there three records. http://api.gbif.org/v1/species/102321493 is one of Lembus infusionum which has parentKey 102321492. The parent key is the record had two descandants.
The modified implementation requires to try /species/{int}/children even if numDescendants is zero, because there may be descendants. I prefer to the previous implementation to navigate classifications.
James
_______________________________________________ API-users mailing list API-users@lists.gbif.org http://lists.gbif.org/mailman/listinfo/api-users

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-9b... <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-a1... tells numDecendants=0 but there is http://api.gbif.org/v1/species/?name=Lembus%20infusionum&datasetKey=9ca92552... 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

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@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-9b... <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-a1... tells numDecendants=0 but there is http://api.gbif.org/v1/species/?name=Lembus%20infusionum&datasetKey=9ca92552... 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@lists.gbif.org http://lists.gbif.org/mailman/listinfo/api-users

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@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@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-9b... <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-a1... tells numDecendants=0 but there is http://api.gbif.org/v1/species/?name=Lembus%20infusionum&datasetKey=9ca92552... 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@lists.gbif.org http://lists.gbif.org/mailman/listinfo/api-users
_______________________________________________ API-users mailing list API-users@lists.gbif.org http://lists.gbif.org/mailman/listinfo/api-users

Hi Markus,
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>
Thanks for quick fix. It works fine now. James
participants (2)
-
Markus Döring
-
Nozomi James Ytow