Include subsumer classes in Exomiser output

[caufieldjh]

Exomiser format looks like this:

HP_0000033      MP_0004014      0.47058823529411764     2.6591341898231766      MP_0002160;
HP_0000033      MP_0020998      0.43478260869565216     3.300796258200725       MP_0009198;
HP_0000033      MP_0020957      0.36363636363636365     2.6591341898231766      MP_0002160;
HP_0000033      MP_0020869      0.2127659574468085      3.300796258200725       MP_0009198;
HP_0000033      MP_0020824      0.5     3.300796258200725       MP_0009198;
HP_0000033      MP_0002771      0.4     3.300796258200725       MP_0009198;
HP_0000033      MP_0008995      0.35    2.5184899921386523      HP_0000078;
HP_0000033      MP_0008994      0.4444444444444444      2.6591341898231766      MP_0002160;
HP_0000033      MP_0008984      0.375   3.283570838358968       HP_0000811;

With columns being subject, object, Jaccard, Resnik, and subsumer, in that order.

We would like to include something like this subsumer column in the output, with the knowledge that it may always or nearly always be a Upheno node.

[matentzn]

@caufieldjh how far are you going with this exomiser work? We are doing a lot of the same things now - especially setting up these comparative experiments etc. If you continue investing in things like converting OAK semantic similarity profiles to Exomiser tables, then we absolutely should add this to the ETL preprocessing in pheval rather than here..

[caufieldjh]

This isn't the OAK semantic similarity, it's a faster implementation that can be part of the usual Monarch KG build. If that essentially mean "run it through Pheval" then that's entirely doable, but for now we have a few different use cases and one of them is just seeing if we're improving on existing phenodigm scores. That use doesn't really require a whole ETL pipeline. In the slightly longer term though, sure, it can absolutely be used in the course of building Pheval comparisons.

[matentzn]

I don't care that much if it's going through oak, but it should export the oak semantic similarity format, not some custom table. In any case, this is all too close to home - We have a concrete mandate to implement what you are doing in PhEval, and I am more than happy for you to implement it, but we need to coordinate the code a bit - for now the most important thing is that semsim exports the standard semantic similarity profile format Chris defined, and I thought this was on someone's priority list?

Is there any way I can get a complete description of where your task starts and where it ends? What are you testing, tuning etc and what is the exact goal?