Implementing the TRAPI Query Engine

[vemonet]

Each KPs will need to build separately their own Query Engine to resolve TRAPI queries

This document plan to give recommendations to implement the rules: https://github.com/NCATSTranslator/ReasonerAPI/blob/edeutsch-ImplRules/ImplementationRules.md

I am starting this discussion, to see if we can improve collaboration when implementing this query engine (which will help having a more stable network more quickly)

I have a question regarding to the potentially really complex that can be easily created by people writing TRAPI, even without noticing it, which will put a lot of stress on the KP queried, potentially crashing it if the right safeguards have not been set

The TRAPI query engine should be able to understand query such as :

"query_graph": {
      "edges": {
        "e01": {
          "object": "n1",
          "predicate": ["biolink:treated_by", "biolink:treats"],
          "subject": "n0"
        }
      },
      "nodes": {
        "n0": {
          "category": ["biolink:Disease", "biolink:Drug", "biolink:Pathway"],
          "id": ["OMIM:246300", "DRUGBANK:DB00002"]
        },
        "n1": {
          "category": ["biolink:Drug", "biolink:Disease","biolink:ChemicalSubstance"]
        }
      }
    }

Depending on how the user build the query it can potentially create really complex resolution matrix. This matrix size will grow as a cartesian product of all arrays provided in the query.

This lack of defined structure seems to leave a lot of room for interpretation, and most KPs will probably implement hardcoded safeguard to prevent crazy, but allowed, matrices to break their system (cf. the example query I provided)

Are there any thoughts on this? Maybe someone already looked into "cleaning up" this matrix? Maybe using some inference from the BioLink model?

[edeutsch]

The above query looks pretty simple and easy. As long as you are providing some curies, then it seems unlikely that one-hop queries can go bad. Your example is answered easily by 4 of our KP sources in parallel with the slowest taking 6 seconds.

We do have some safeguards to prevent CURIE-less queries. For example, this:

"query_graph": {
      "edges": {
        "e01": {
          "object": "n1",
          "predicate": ["biolink:treated_by", "biolink:treats"],
          "subject": "n0"
        }
      },
      "nodes": {
        "n0": {
          "category": ["biolink:Disease", "biolink:Drug", "biolink:Pathway"]
        },
        "n1": {
          "category": ["biolink:Drug", "biolink:Disease","biolink:ChemicalSubstance"]
        }
      }
    }

could easily go off the rails. You would probably want to intercept and decline that.

Multihop queries can also easily blow up quickly. Often some pruning strategy to prevent blow ups would be necessary and this is part of building an ARA.

It seems like it could be an amusing little project to write a class to estimate how expensive a query graph is.