[poll] control or baseline

[KaiWaldrant]

I think it's time to figure out what description we are going to use in all the openproblems repos: :+1: for control method :-1: for baseline method

@rcannood @scottgigante-immunai @mumichae @mxposed @dburkhardt

[rcannood]

Haha. Wouldn't call this an urgent issue, but it definitely needs to be resolved :)

I like being able to talk about positive controls and negative controls, so a :+1: from me.

Reminds me about a conversation with @slobentanzer about defining an ontology for all of the terms and concepts we use to talk about OpenProblems. I think that'd be a great idea.

[KaiWaldrant]

I know its not urgent, just a bit of fun on a saturday night :rofl:

[slobentanzer]

Still think that would be a cool thing to have. If you don't want to go full-blown semantic web immediately, we could also make drafts using the BioCypher framework (just defining some concepts in the configuration). Happy to brainstorm on that.

For instance, we could start by manually extending some subclass of EFO Information Entity.

[scottgigante-immunai]

I like being able to talk about positive controls and negative controls

Only concern about the term "control" is that in some cases (e.g. batch integration), a single baseline method can be a positive control for one metric, a negative control for another, and be totally irrelevant for a third.

[slobentanzer]

so

baseline method:
  is_a: method  # or whatever should be the superclass, e.g. from EFO

control:
  is_a: baseline method

positive control:
  is_a: control

negative control:
  is_a: control

something like this? not sure whether the semantic structure is exactly correct, but in essence, this is what needs to be figured out, right? are strictly all instances of control instances of baseline method?

[scottgigante-immunai]

I'm not familiar with EFO but control would probably be a relationship between a baseline method and a metric -- so a baseline method is a positive control for a given metric.

[rcannood]

Hmm.. It's true that in some tasks, some components will be a positive or a negative control metrics, but will be irrelevant to others. How about adding that information to the metric itself? In this way, the no_denoising baseline or control method doesn't need to specify whether it's a positive control or a negative.

Contents of src/denoising/metrics/mse/config.vsh.yaml:

functionality:
  name: "mse"
      - name: mse
        # ...
        positive_controls: [ perfect_denoising ]
        negative_controls: [ no_denoising ]

Contents of src/denoising/control_methods/no_denoising/config.vsh.yaml:

__merge__: ../../api/comp_control_method.yaml
functionality:
  name: "no_denoising"
  # ...

something like this? @ slobentanzer Regardless of how we decide to resolve this issue, I'm sure we can already many items we can define. However, I guess we should move that to a separate discussion.

[scottgigante-immunai]

Yes, that could work!