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

[colleenXu]

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):

• TRAPI 1.5: new query property bypass_cache #799
• TRAPI 1.5: add "attributes": [] to NodeBindings, EdgeBindings, AuxGraphs #801
• TRAPI 1.5: support source_record_urls #803
• TRAPI 1.5: update SmartAPI yamls for BTE + Service Provider #802
• change operation listed in workflow section of response #485

Placeholder issue for "set_interpretation"/MCQ - #800

[colleenXu]

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)

[colleenXu]

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...

[colleenXu]

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.

[colleenXu]

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

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