-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate if ChecklistBank could expose the readonly GBIF v1 Species API #1320
Comments
|
Species suggest and search both have similar parameters and return types. The exact behavior of the search (scoring/ranking) is likely to be different:
Return type
|
Species response Type:
|
v1 methods which do not exist at all:
|
Identifiers are the biggest problem. ChecklistBank has compound keys with COL stable identifiers are short string, but can be converted bidirectionally into an int. That won't work for other dataset identifiers |
Backbone taxon keys are used in other GBIF APIs:
I can't think of an exposure of non-backbone keys, things like the IUCN Red List resolution during interpretation don't store the keys. |
Does that mean we cannot change the keys to not break the other APIs or is it a matter of (not) changing the data type from int to string? Note also that there are 17 accepted kingdoms in COL these days, mostly viruses. |
What are the differences between the v1 GBIF Species API and ChecklistBanks data model. Are there any true blockers?
The text was updated successfully, but these errors were encountered: