Hi Martin, you should be using the species/root call from our species API: http://www.gbif.org/developer/species#nameUsages
It takes the datasetKey you are interested in, for example for the GBIF backbone taxonomy this call is: http://api.gbif.org/v1/species/root/d7dddbf4-2cf0-4f39-9b2a-bb099caae36c Subsequent, pageable childs are then retrieved with: http://api.gbif.org/v1/species/1/children The search you have been doing is across all checklist datasets we have indexed so you get kingdoms from hundreds of different taxonomies. best, Markus -- Markus D?ring Software Developer Global Biodiversity Information Facility (GBIF) mdoering at gbif.org<mailto:mdoering at gbif.org> http://www.gbif.org On 19 Dec 2015, at 14:26, Martin Wendt <gbif at wwwendt.de<mailto:gbif at wwwendt.de>> wrote: I try to implement a lazy-loading taxonomy tree (as a demo for a open source javascript tree plugin). See here for an example: http://rawgit.com/mar10/fancytree/master/demo/taxonomy-browser/index.html#key=7348228 What JSON API should use to get the top level nodes (i.e. Kingdoms)? Currently I call http://api.gbif.org/v1/species/search?rank=kingdom but this returns much more than the ~7 entries I expect (Animalia, Plantae, Fungi, ?) I seem to get reasonable results, if I only display nodes with key == nubKey. But the search results retrieved by `species/search?q=homo sapiens` returns multiple hits, and some of them have keys different from nubKey. Those matches seem to be descendants of an `Animals` kingdom that also has nubKey != key. I guess my mental model of the data structure is too na?ve: - why are there different ?Animals? kingdoms with different keys but identical nubKey? - does it make sense at all to display a tree (with only one ?animals? node)? - when I restrict the search results to entries that have a kingdom with key == nubKey, what will the user miss? Thanks Martin Wendt _______________________________________________ API-users mailing list API-users at lists.gbif.org<mailto: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/20151219/bf7132d6/attachment.html>
