search

NCATSTranslator / TranslatorArchitecture

MIT License
9 stars 11 forks source link

Missing access point for KGX files? #14

Closed RichardBruskiewich closed 3 years ago

RichardBruskiewich commented 4 years ago

Hi @cbizon, after posting this issue, I noted the attribute KGX export URL metadata attribute in the proposed /info endpoint of TRAPI Issue https://github.com/NCATSTranslator/ReasonerAPI/issues/142.

This manages some notion of documentation of access of KGX files associated with a given TRAPI endpoint, but it seems to me that some facets of access remain unclear:

  1. If the endpoint is given as /info, and a given KP (or even, ARA) TRAPI endpoint is open ended in terms of knowledge graph (or rather, result subgraph) outputs, what actual KGX content is sitting at the end of that endpoint and how is it documented?

  2. Are most of the x-trapi metadata going to be relevant for other ad hoc generated KGX file sets which may not have a one-to-one association with a given KP (or ARA) knowledge graph "space"? Even if we wrap all KGX file sets in a TRAPI-like interface specification which can be registered in the Translator (aka modified SmartAPI) Registry, how do we differentiate between "full" TRAPI implementations versus KGX TRAPI wrappers?

Off the top of my head, would components of our pending "workflow operations" metadata help us with the above?

RichardBruskiewich commented 3 years ago

Obsolete PR? The https://github.com/NCATSTranslator/Knowledge_Graph_Exchange_Registry will likely resolve this concern at some point.