search

NCATSTranslator / minihackathons

MIT License
5 stars 5 forks source link

Query C.1: Reverse subject and object nodes #236

Closed rtroper closed 3 years ago

rtroper commented 3 years ago

A recent change in the Smart API spec for our EHR risk KP (which defines how TRAPI is converted to an equivalent Smart API query) requires that this query be defined in the reverse direction. Therefore, swap subject and object node IDs. I confirmed that COHD results we currently get still show up when reversing the nodes and EHR risk shows up (through BTE and ARAX) after reversing.

cbizon commented 3 years ago

I'm ok merging this change, but KPs do need to be able to respond to this (symmetric) query in either direction. There's no way for a user to know that inverting the subject and object is going to give a different result.

rtroper commented 3 years ago

I'm ok merging this change, but KPs do need to be able to respond to this (symmetric) query in either direction. There's no way for a user to know that inverting the subject and object is going to give a different result.

Yeah, I had interpreted this as a symmetric predicate as well. And as far as I know, the biolink model doesn't contain a corresponding inverse predicate. I should check in with @colleenXu (from Service Provider) who suggested the current implementation in the Smart API spec, which implicitly assumes directionality for this predicate. I agree we should treat it as a symmetric predicate. But, I'll need to find out how to implement it as such in the Smart API spec.

colleenXu commented 3 years ago

@rtroper @cbizon BTE is currently using biolink model 2.2.3, where the predicate is NOT symmetrical. The predicate was only made symmetrical very recently (biolink 2.2.4), and the BTE team has not reviewed this update and implemented it for BTE yet.

Therefore, to set up a "reversed edge" query, the inverse biolink predicate should be used.

The SmartAPI spec was set up so that the predicate "has real world evidence of association with" would be used when querying with the outcome of the logistic regression model (stored in the API's "object" fields) and return the features that had large coefficient magnitudes in the logistic regression model (stored in the API's "subject" fields).

Currently, there are no operations in the SmartAPI spec to query with the features and return the outcome (this would involve more than doubling the number of operations, BTE already has some issues with this API related to the number of operations it has).