search

NCATSTranslator / TranslatorArchitecture

MIT License
9 stars 11 forks source link

Metadata harmonization strategy in SmartAPI registry #59

Open sierra-moxon opened 3 years ago

sierra-moxon commented 3 years ago

While working through the development of the Information Resource Catalog (and for the predicates working group), we made heavy use of the nice metadata provided by the SmartAPI registry (thank you!).

We wanted to discuss adding a few new properties to the SmartAPI registry to support keeping the Information Resource Catalog up to date.

  1. A short name for the resource that can be automatically converted into an 'infores' identifier that registers create when registering a new service.
  2. A way to tell from metadata if a service in the SmartAPI registry is simply a registry entry for an existing resource (chembl api) vs. a resource developed by one of the teams in translator (automat-chembio).
  3. A consistently/harmonized version for an API entry itself (ie: can we sync on semantic versioning for these that is separate from TRAPI version?).
  4. Is there a better way to construct the URL to a specific endpoint like this one: https://arax.ncats.io/api/arax/v1.1/meta_knowledge_graph, besides concatenating the servers.URL and path values?

Also, is there documentation on how the registry handles updates and deletes?
Is there a way to tell if a registry entry has been updated? (something like a 'last updated date). Can a registry entry be deleted (or is there a metadata property for 'deprecated'? ).

newgene commented 3 years ago
  1. Based on the discussion at the architecture call, we will add an infores entry to the SmartAPI x-translator extension, but it will not be a requirement for the Translator teams till the next major SmartAPI metadata changes (e.g. TRAPI v1.2).
  2. Is this to tell if an SmartAPI entry a biolink:aggregator_knowledge_source v.s. biolink:primary_knowledge_source? If so, this can be covered in No. 1 as well.
  3. You mean to keep the metadata versions? Don't think SmartAPI will maintain all historic versions, typically a metadata source file is mentioned in a source-controlled repo (most likely a github repo).
  4. We are considering an optional x-trapi.endpoint_prefix field, so that the final URL will be servers.url+info.x-trapi.endpoint_prefix+path. This way API owner can specify any arbitrary url prefix, if their TRAPI endpoints are not hosted at the root path. Let us know if that's what you need.

And regarding SmartAPI entry update and deletion: