New operation suggestion: create_multivariate_table

[karafecho]

ICEES currently supports an open multivariate functionality that allows users to generate a multivariate table with a limited (but user selected) set of feature variables. We've demonstrated that we can use the output for multivariate modeling using GLM, random forest, etc. The functionality is currently command line only and involves iterative queries of the ICEES API.

David and Abrar's relay session on operations/workflows inspired an idea that may or may not make sense, but probably is worth exploring, imho. Specifically, I am wondering whether we could create a new workflow operation create_multivariate_table that would invoke the Python code to execute the multivariate functionality. For now, I think that ICEES might be the only KP capable of supporting the operation, but I suspect it might find broader application down the road, and it's worth noting that the proposed operation, as envisioned, would be applicable to both clinical and non-clinical KPs.

One caveat is that we are in the process of refactoring ICEES into two separate services: ICEES and ICEES KG, with ICEES as fully featured and capable of dynamic analytics and ICEES KG as a static service. The multivariate functionality, at least in its current form, would only support ICEES proper. However, with some creative thinking, we might be able to develop a variation that would allow ICEES KG (and other services) to be responsive to create_multivariate_table.

This suggestion obviously requires a bit more thought, but I thought I'd go ahead and post the ticket for reaction.

[cbizon]

Sounds cool. Does this operation consume and produce TRAPI?

[karafecho]

No, but I'm envisioning the operation to be applied to our existing TRAPI endpoint, sort of as an enhanced feature or our KP's special/secret sauce. So, for example, if our TRAPI one-hop endpoint received a query that included a request to execute operation create_multivariate_table with a defined set of parameters and in the context of a query biolink:DiseaseX - biolink:has_real_world_evidence_of_association_with - biolink:ChemicalEntity, then we would perhaps be able to annotate the query response with a multivariate table (JSON blurb) with contingencies maintained across feature variables (parameters, in this case, perhaps disease x chemicals).

If this operation was 'unique', then I think it might find broad applicability sooner rather than later.

Also, annotate_multivariate_table may make more sense than create_multivariate_table. I'm not sure.

Anyway, @maximusunc and I had a brief slack exchange shortly after yesterday's relay session to discuss this idea, and he suggested that I post the ticket, but we definitely need to give it more thought. In that regard, any and all additional feedback is most welcome!

[cbizon]

Hi @karafecho we are discussing this on the ops and workflow call. The operations so far are all TRAPI in / TRAPI out, and that's helpful because then workflows can chain these operation without worrying about types. So there will be a lot more appetite for this if we can figure out a way to represent the output information as TRAPI.

That said, maybe if you describe how you anticipate the non-trapi output being used maybe we can think of other approaches.

[karafecho]

I completely understand and agree that this idea requires additional thought/brainstorming. However, I'm pretty sure we can identify a way to represent the output as TRAPI 1.3.

We (Exposures Provider) recently deployed the initial ICEES KG instance, so I'll have to consider how this new service might be able to respond to an operation such as create_multivariate_table.

FWIW, I'm not considering this high priority (definitely not a goal for the September relay), but I do think it's worth additional thought/brainstorming.