Do we want an edge weighting operation?

[cbizon]

We have lots of EPC. Rankers can consume this information to create scores. One approach is that a ranker consumes all the EPC on an edge and produces a single-edge score (a weight). Subsequently these weights are combined into a score for the whole answer.

The mapping of various types of EPC to a single score is both an area that we'd imagine change and innovation over time, as well as a valuable piece of code to share. So should we create an edge weighting operation? It would I think take a TRAPI message with full qg, kg, results, and apply a numerical weight to the edge bindings.

[cbizon]

Idea coming from the Winter Relay merging & EPC session

[dkoslicki]

This is similar to what the ARAX ranker does: it weights edges based on a variety of info (eg. if SemMedDB edge, use citation count, if COHD edge, use p-value, etc.), then combines these (via max flow, Frobenius norm, and max path), the uses the average rank as the score.

The tricky thing is normalizing all the edge scores so they can be comparable

[cbizon]

Yep. Is it modularized out in a way that would make it easy to expose the weighting as an op?

[dkoslicki]

It is: you can call it via rank_results() in ARAXi, so would be simple to translate this to operations and workflow. Maybe then people could fiddle with the many, many, many heuristic choices that are made.

[cbizon]

Nice! Not to give other people work, but could we assign this ticket to Finn? (defining the operation yaml)

[dkoslicki]

Sure! He's been able to implement operations quite quickly, so it should be relatively straightforward. I assume the unique flag should be True, correct? Also, I see we have a score operation. Is the desire here to have an operation like weight_edges?

pinging @finnagin so he's aware

[cbizon]

Right, the idea is to have a weight_edges operation that takes a message and adds edge weights.

I think that the main decision is around where those weights should go. I would argue that they belong on the edge bindings, while I suspect that there will be a sizable constituency for putting them on the kedges.

I have to admit, I always forget which way unique=True means. I think that we should allow multiple implementations of weight_edges.

[finnagin]

@cbizon If unique=True that would mean we allow multiple implementations of weight_edges. Are edge weights a property allowed in the result edge bindings by TRAPI? ARAX doesn't use these so I don't know exactly how they are encoded if so.

[cbizon]

I think we can add attributes to edge bindings in TRAPI, but I might be wrong. There's probably a discussion to be had about whether the weights are better on the bindings or the KG edges themselves. The KG is in some ways simpler, but only allows for the possibility that the weight is an intrinsic property of the triple rather than a relation between the triple and how it is used.

[finnagin]

Should we add it to the agenda for next week for further discussion?

[cbizon]

I think that's a good idea