monarch-legacy
monarch-legacy copied to clipboard
Simsearch - change list of ids to list of objects with id and label
Example simsearch query for reference
In the resulting JSON, we store the input list of ids in the "a" property; however, it would be useful for phenogrid to instead store a list of objects containing the ID and primary label. Would this be an issue for other users of simsearch who are relying on a specific JSON structure to come back from the simsearch service? This would be a quick enhancement using the scigraph neighbors service to get labels, see https://github.com/monarch-initiative/monarch-app/issues/935 cc @cmungall @nlwashington
Thanks @kshefchek , this would be a great change if we can add the label of each input phenotype to the resulting JSON. Then I can get rid of those ajax calls and callbacks to get labels for unmatched phenotypes. It's also a performance improvement for phenogrid.
@kshefchek just to follow up with this API change idea, as you suggested earlier, I tried to use the scigraph neighbors service to get labels for a list of phenotype ids. But sometimes it took a long time to get the JSON so I heisted to merge that change. Right now Phenogrid is still using individual ajax calls for each phenotype id to grab the corresponding label. Wrapping them into the simsearch api result is still the best solution.
And we also need this for the compare api results.
@kshefchek is this API change still on your list? I've created functionalities around phenogrid unmatched phenotypes for IMPC integration, which all the phenotype labels are provided upfront so no external calls to get the labels for those unmatched phenotypes. And it worked out very well.
@yuanzhou, is this needed for IMPC? If so, can we prioritize?
@harryhoch this is not needed for IMPC since we have all the phenotype labels from their JSON, which makes things lot easier in terms of the number of function calls as well as performance. This is another reason why I waned to get this done for monarch-app use case.
ok. @kshefchek, this would require some changes to owlsim, right? I assume it would be non-trivial?