RichardBruskiewich
commented
5 years ago details are one-to-one with statements, so if qualifications are important for interpretation of a statement, then both the statement and its details need to be retrieved and consumed, side-by-side. Of course, if we reconsider that qualifications should be "core" markup on the statement itself, then we can move them from details to the main statement result
@cmungall @RichardBruskiewich we will need a way to express qualifications in edges. The API already had qualifications in the statement details endpoint, but that's not right since they're not just details--they can drastically change what a statement is saying!
I figure that along with expressing a qualification it would be valuable to give an explanation of the qualification and the assumptions that went into it if it was inferred, and then to give a more generic unqualified statement that would be true even if the qualified statement was false.
For example, in Rhea a reactions equation is typically given with reactants on the left and products on the right. This isn't guaranteed, but it's something we might feel is safe to assume. We can then infer that an enzyme that catalyzes that reaction increases production of those compounds on the right side of the reaction. This of course is something we must say with qualification. But we can also say without qualification that the enzyme affects the production of those compounds on the right side of the reaction. The unqualified statement should always use a more generic form of the predicate that the qualified statement uses.
This is a first attempt, and probably a sloppy one. I welcome suggestions about how qualifications could be better expressed in our API. https://github.com/NCATS-Tangerine/translator-knowledge-beacon/blob/cf1cd685853bf0a521acd187e91050e769fb25c0/api/knowledge-beacon-api.yaml#L713-L743