search

gbif / vocabulary

A simple registry of controlled vocabularies used for terms found in GBIF mediated data.
Apache License 2.0
6 stars 1 forks source link

Keys all over, but not the names that actually work as key #136

Open MortenHofft opened 4 months ago

MortenHofft commented 4 months ago

https://api.gbif-uat.org/v1/vocabularies/PreservationType/concepts/StorageFrozenMinus20?includeParents=true

That response has a lot of keys, but keys cannot be used for anything (there is no vocab 77)

example: vocabularyKey: 77 But there isn't really anyway for me to know what vocabulary I'm looking at except from trying to do a regex on other fields like "alternativeLabelsLink": "https://api.gbif-uat.org/v1/vocabularies/PreservationType/concepts/StorageFrozenMinus20/alternativeLabels",

Are they in the API response for a reason or is it internal values that gets leaked to the API? If they cannot be used for anything, then I think we should remove them. They are just a cause of confusion then.

And secondly: could we instead include names when then they aren't there. Such as the vocabulary name in above example

marcos-lg commented 4 months ago

I'll include the vocab names in that endpoint and review the others. There are some endpoints that still need the keys such as the ones to deprecate vocabs or to specify the parent of a concept. I can use names in all of them, it's just a hassle because for the concepts it requires an extra join in the DB queries.

Anyway, you can also find a vocabulary by its key https://api.gbif-uat.org/v1/vocabularies?key=77

Also, not sure about removing the keys from the responses, I don't think they do any harm as long as we make clear how to use the API and it can help us find concepts in the DB (concept names are unique only within a vocabulary and they are linked to the vocabulary by its key, not its name).

marcos-lg commented 3 months ago

Deployed to production the vocabularyName in the response.

I'll review the other endpoints at a later time.