Giters

biothings / biothings_explorer

TRAPI service for BioThings Explorer

Home Page:https://api.bte.ncats.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

overview and management of TRAPI 1.5 features (excluding set_interpretation/MCQ)

colleenXu opened this issue · comments

commented

This is to track the overall progress of implementing TRAPI 1.4.2 -> 1.5.0-beta. I'm mainly using git compare, not the changelog.

General info:

  • (Translator slack link) At the moment, we don't need to implement "set_interpretation"/MCQ, even though it is in the spec (PR, lines 881-896). The requirements/implementation spec haven't been set yet.
  • but other requirements may still change (TRAPI in beta)
  • Translator goal is to have this in Dev/CI by 4/12, so it's ready for a 4/12 request to TEST environ
    • may have messy/broken integration with other Translator tools, as they implement these features
  • all work is in BTE tool (aka I didn't see anything for Multiomics / Text-Mining teams to do)
  • It's related to the MCQ creative-mode prototype work

Features (all are minor):

Placeholder issue for "set_interpretation"/MCQ - #800

commented

Resolved:
TRAPI 1.5 adds some validation info. I don't think we break any of these rules in our normal queries/responses.

When we update bte-server's copy of the SmartAPI yaml, we'll use it to validate incoming queries. At the moment, we don't need to do more.

organized list of the added validation info

  • cannot be null
    • Query / AsyncQuery message (lines 268, 327)
    • AsyncQuery callback (line 312)
    • Response message (line 454)
    • Response logs, but it can be an array with no items (lines 475-476)
    • Response schema_version and biolink_version (lines 486, 491)
    • result.node_bindings (line 617)
    • result.analyses, but it can be an array with no items (lines 625-626)
    • NodeBinding id (line 644)
    • EdgeBinding id (line 753)
    • KG Node categories (line 1003)
  • array must have >=1 item
    • AsyncQueryStatusResponse logs (line 424): I'm not sure this is possible to do at the very beginning of execution…
    • Each result node_binding value (line 616)
    • Each KG Node categories value (line 1002)
  • message.results behavior (lines 511-515, 520)
    • if results shouldn't exist yet (ex: Query / AsyncQuery message), this property should be absent/null
    • if response has no results, this property should still exist as an array with 0 items
  • KG Node categories is required (line 1019)

commented

EDIT: discussion in today's group meeting is that we will add this error handling for set_interpretation.

@andrewsu @newgene @tokebe

In the update that we don't need to implement "set_interpretation"/MCQ (Translator slack link), Eric says that we could check QNodes for set_interpretation and return an error for now. I'm not sure if we want to add this or not...

commented

Note (@tokebe can confirm): we didn't implement a check/return an error for set_interpretation (mentioned in above comment). This ends up being a QNode property that isn't processed/used in any way.

commented

The sprint 2/Octopus release has been released to Prod.

Closing this issue - will track some of the not-quite-done issues separately.