New terms for mpbn about kisao HOT 8 OPEN

I added the above terms to #105. Before I release this as 2.31, I have a few questions/comments. @pauleve please share any thoughts.

"most permissive updating policy". I created this as a characteristic. Is it a property of an algorithm (characteristic) or an option to an algorithm that users can choose (parameter)?

for NEW_ALG2, I'm not sure how to specify that it returns only minimal trap spaces: should we introduce an additional sup-level algorithm "logical model minimal trap space identification method"? or a characteristic of the family of solution, or is it a parameter?

This sounds like a property of the algorithm (characteristic), rather than something the user can control (parameter). I added characteristics of types of solutions -- trap spaces (KISAO_0000695), minimal trap spaces (KISAO_0000697), and stable states (KISAO_0000696) and annotated the algorithms with them.

there is a semantic relationship between attractors and steady states (the latter being a particular case of the former); is it interesting to specify this somehow at the KiSAO level?

I created characteristics for these nested under "type of solution". I added a common parent "attractor". The hierarchy looks like this:

• type of solution (KISAO_0000235)
  • Attractor (KISAO_0000698)
    • stable state / steady state (KISAO_0000696)
    • trap space (KISAO_0000695)
      • minimal trap space (KISAO_0000697)

from kisao.

Great, many thanks!

"most permissive updating policy". I created this as a characteristic. Is it a property of an algorithm (characteristic) or an option to an algorithm that users can choose (parameter)?

It is really a property of an algorithm (it is an update policy different than asynchronous/synchronous)

for NEW_ALG2, I'm not sure how to specify that it returns only minimal trap spaces: should we introduce an additional sup-level algorithm "logical model minimal trap space identification method"? or a characteristic of the family of solution, or is it a parameter?

This sounds like a property of the algorithm (characteristic), rather than something the user can control (parameter). I added characteristics of types of solutions -- trap spaces (KISAO_0000695), minimal trap spaces (KISAO_0000697), and stable states (KISAO_0000696) and annotated the algorithms with them.

Yes, I agree.

there is a semantic relationship between attractors and steady states (the latter being a particular case of the former); is it interesting to specify this somehow at the KiSAO level?

I created characteristics for these nested under "type of solution". I added a common parent "attractor". The hierarchy looks like this:

* type of solution (`KISAO_0000235`)
  
  * Attractor (`KISAO_0000698`)
    
    * stable state / steady state (`KISAO_0000696`)
    * trap space (`KISAO_0000695`)
      
      * minimal trap space (`KISAO_0000697`)

At first, I was a bit reluctant with this hierarchy: there is no simple connection between attractors and trap spaces (and even less direct with minimal trap spaces).
But it depends the meaning of being "a subclass": these objects are indeed related in one way or the other (any attractor belongs to a trap space; any minimal trap space contains at least one attractor). That being said, the methods for computing attractors and trap spaces are, in general, very different, as the former depends on the update policy, and not the latter.
So, maybe having trap space (KISAO_0000695) as a direct subclass of type of solution (KISAO_0000235) is safer and will be easier for handling substitutions.

Before merging these changes, should we check for the substitutions they lead with libkisao? I can give a try later this week.

from kisao.

meaning of being "a subclass"

We can interpret this however we like. I was thinking about similarity between types of solutions. I didn't intend for this to suggest that the methods for calculating similar solutions are necessarily similar. I suggest annotating algorithms with multiple characteristics to keep track of multiple types of similarity between algorithms (e.g., result and method).

maybe having trap space (KISAO_0000695) as a direct subclass of type of solution (KISAO_0000235) is safer and will be easier for handling substitutions.

I can make this change

substitutions they lead with libkisao

I've written libkisao is use specific relationships. I can extend that to these algorithms. In what scenarios do envision wanted to substitute among the newly curated methods?

from kisao.

meaning of being "a subclass"

We can interpret this however we like. I was thinking about similarity between types of solutions. I didn't intend for this to suggest that the methods for calculating similar solutions are necessarily similar. I suggest annotating algorithms with multiple characteristics to keep track of multiple types of similarity between algorithms (e.g., result and method).

This makes perfect sense to me. Having trap space as a subclass of attractors can definitely be defended, so we can keep it as is.

substitutions they lead with libkisao

I've written libkisao is use specific relationships. I can extend that to these algorithms. In what scenarios do envision wanted to substitute among the newly curated methods?

I'll send you here later that week the substitutions that would be nice to have.

from kisao.

so we can keep it as is.

Will do

substitutions that would be nice to have.

For me, I found it helpful to think of this as a matrix (algorithm x algorithm). For each pair of algorithms, I thought about the degree to which I found them to be similar. Algorithms that produce different types of solutions (e.g., time course vs steady state, I felt to be substantially different, irrespective of whether the method might be similar). Algorithms that produce the same type of solutions (even if using different methods) I thought to be similar. We outlined several qualitative degrees of similarity (see https://docs.biosimulations.org/concepts/conventions/simulator-interfaces/#environment-variables).

In order to produce the substitutions you have in mind, we can add more characteristics as needed.

from kisao.

Here are the links between the algorithms ; the "over-approximation" can be ignored (and trreaded as NO).
The second table is just the first one replaced with IDs.

from kisao.

This is very interesting and helpful! I hadn't thought about qualifiers to SAME MATH. I had been thinking of examples such as SSA and NRM which simulate the same statistical distribution (in contrast to, for example, SSA and tau-leaping). Now that I see how you've thought about this, I see where this would make sense. On the flip side, this would increase the complexity of specifying a level of substitutability, and I think there might be value in keeping this simpler for investigators (i.e. coarse-graining substitutability a little bit).

What do you intend something like SAME_MATH with characteristics KISAO_0000697 to mean? Would this mean that this particular mathematical property of a particular output is the same?

from kisao.

Maybe that "provided characteristics XXX" would be more accurate: the algorithms in mpbn are designed for locally-monotone BNs only; thus one should ensure that the BN fulfill this condition for substituting for instance KISAO_0000663 with KISAO_000000692. Note that it is not symmetric: KISAO_000000692 can always be substituted with KISAO_0000663, as the latter allow a more general class of models.
As a first stage, one could ignore the characteristics and let mpbn throw an error if the model does not satisfy the requirements: that would be already really useful to demonstrate the tool substitution.

from kisao.