You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
4. (optional / less important): handling gene -> gene's response
I haven't written an operation for a gene->gene query, because the direction of the response's data isn't consistent. It's not important because the source of this info is BioGRID and Biolink API / Monarch also covers this information.
Perhaps, post-processing could get all associations "in the same direction" from input ID -> output ID and then response-mapping could be to those post-processed fields. However, we'd want to check that this doesn't mess up the meaning (is there a different meaning if a gene is a source vs a target?).
I think Biolink API / Monarch's post-query processing + SmartAPI yaml response-mapping (which is to fields that exist only after the post-processing) is able to handle this situation, so maybe a solution like that will work here.
The text was updated successfully, but these errors were encountered:
Intro: see intro section of #583 (comment). Originally noted in #558 (comment)
4. (optional / less important): handling gene -> gene's response
I haven't written an operation for a gene->gene query, because the direction of the response's data isn't consistent. It's not important because the source of this info is BioGRID and Biolink API / Monarch also covers this information.
For example, if I query CTD with gene CYSLTR1 (10800)...
some associations have input CYSLTR1 in the source fields
source = src
but others have input CYSLTR1 in the target fields
target = tgt
Perhaps, post-processing could get all associations "in the same direction" from input ID -> output ID and then response-mapping could be to those post-processed fields. However, we'd want to check that this doesn't mess up the meaning (is there a different meaning if a gene is a source vs a target?).
I think Biolink API / Monarch's post-query processing + SmartAPI yaml response-mapping (which is to fields that exist only after the post-processing) is able to handle this situation, so maybe a solution like that will work here.
The text was updated successfully, but these errors were encountered: