cmungall
commented
6 years ago Yes, I think the client should get things back the way it asks for them. E.g if it asks for X-to-Y, it doesn't get Y-to-X.
This could be done in the biolink-api level or the underlying ontobio code, or even pre-populated in solr.
We will either have to invert the relationship type OR extend the model to add a property that says the relation is inverted (formally this is the same as making an OWL InverseOf(P) PropertyExpression). The latter is easier as we avoid any specific coupling between the code and the relations ontology (and not every relation has a named inverse, through we try to do this in RO). The client would just have to be smart enough to check this field. But then the client would need to look up the name of the inverse, unless we just display visually that this is inverted? OK, how about the API makes a best effort to return an atomic named relation that is valid, but in some cases it will return rel=P, inverse=true?
I thought we had some logic for doing this with symmetric relations like interaction. But I guess we just pre-materialize in both directions @kshefchek ?
cc @lhannest should beacons also have this inverse property?
kshefchek
putmantime
deepakunni3
To drive the associations tables, it would be useful if Biolink followed the subject object predicate pattern in return objects.
For example: /bioentity/disease/{curie}/phenotype returns the disease as the subject and phenotype as the object /bioentity/disease/{curie}/gene however, returns the disease as the object and the gene as the subject I realize this is a symptom of monarch unidirectional modeling, but after talking with @cmungall it seems the logic to implement this pattern is best implemented in biolink server api code.
The calls needed to support monarch association tables in this pattern are here:
Many of these are already implemented with the above pattern. Priority objects are variant, phenotype, model, disease, anatomy, homolog, literature, gene, function