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>
