Skip to content
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

gbif api (and portal?) should tell about usage of extensions #55

Open
abubelinha opened this issue Jul 19, 2020 · 0 comments
Open

gbif api (and portal?) should tell about usage of extensions #55

abubelinha opened this issue Jul 19, 2020 · 0 comments

Comments

@abubelinha
Copy link

abubelinha commented Jul 19, 2020

I just discovered the regular API calls are not exposing concepts published through the usage of extensions (or at least, some extensions).

An example from a taxon checklist extended with vernacular names, species distribution, literature References and MeasurementOrFact extensions:

The portal entry overview tab shows at least some of those linked concepts (for some reason, only the distribution data but nothing else): https://www.gbif.org/species/164940120
But the equivalent API normal call doesn't show anything: https://api.gbif.org/v1/species/164940120

If you go to the verbatim versions, then no problem to find all linked data:
Portal verbatim tab: https://www.gbif.org/species/164940120/verbatim
API verbatim call: https://api.gbif.org/v1/species/164940120/verbatim

Of course a user who is browsing the portal overview tab (the default one), can always click the verbatim tab in order to see if there could be some extended information in there. In my opinion, there should be a visual notification in the page, to tell user about those additional extensions data available when clicking the verbatim tab.

But when you are programming a web app which uses the API, this notification is much more important: it would make sense to have some API flag notifying about that (something like extensionsUsage: boolean, or even better usedExtensions: [array of extensions], for example).
With such a notification, the app could decide wether or not to make a second API call to retrieve the verbatim data (only if those extensions are relevant for what the app needs to show).
Otherwise, the only way to retrieve those extended data is to always make verbatim calls. Which in most cases would be an useless bandwith waste.

@abubelinha

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant