Allow instances of the base Simulation class to better support other modeling formalisms and other analyses of models

[jonrkarr]

Presently, SED-ML supports four specific types of operations on models

• SteadyState
• OneStep (of a time course)
• UniformTimeCourse
• Parameter estimation

This excludes many other types of analysis of models, as well as some other types of simulations. Examples:

• Without more flexibility in the data types of the attributes of the above classes, this excludes time course simulations of logical models.
• ODE integrations with independent variables other than time.
• Calculations of properties of models such as reachability, clustering cofficients, Lyapunov exponents, etc. which wouldn't be considered analyses of steady states.
• Generations of visualizations of models such as network diagrams.

One way to support other types of simulations and analyses is to add additional classes for each semantically distinct type of simulation/analysis (e.g., proposal linked to #8). Taken to its logical conclusion, this would likely require many additional classes, greatly increasing the complexity of SED (and libSED-ML). This would then necessitate bureaucracy to manage proposals for this. Because this would take effort to support, this would likely lead to further splintering in software support for SED.

I think a simpler way to provide more flexibility is to allow instances of Simulation. This could be done in a couple of ways:

• Make Simulation a concrete rather than abstract class
• OR add a separate AbstractSimulation class. Change SteadyState, OneStep and UniformTimeCourse to inherit from AbstractSimulation. Create a new Simulation class which also inherits from AbstractSimulation.

Within SED and libSED-ML, this Simulationclass would functional identical toSteadyStatein that neither would have additional attributes that aren't inherited fromAbstractSimulation. Despite this,Simulationis needed because the specific semantic meaning ofSteadyState` limits its application.

The semantic meaning of instances of Simulation would (indirectly) be conveyed through the use of KiSAO terms for its algorithms and their parameters. Semantic meaning could be conveyed more directly by, (a) adding a kisaoId attribute to this Simulation class and (b) using this to reference a new section of KiSAO which catalogs various types of operations on models (this doesn't exist, but it could be created; KiSAO seems like the logical to put this, but another ontology would work equally well).

Basically, this avoids the need for additional SED simulation classes with other semantic meanings by instead using ontology terms to define semantic meaning. The key advantage of this architecture is that this requires fewer classes and, in turn, less code. Because its generally easier to get consensus on contributions to ontologies, this would also provide a much simpler path for other domains to use SED-ML for other types of operations on models (i.e., a KiSAO term can be added in a few minutes versus a much lengthier process for adding classes to SED-ML and libSED-ML).

[luciansmith]

This is essentially what we did for https://github.com/SED-ML/sed-ml/issues/8 except that we called the new class 'Analysis' because logical modelers got stuck on the word 'Simulation'.

I'm leaving this here as an L2 suggestion because if we re-vamp things, I'd call the base class 'Analysis' and have 'Simulation' inherit from it.

[jonrkarr]

I'd advocate for L2 to eliminate all child classes and just use KiSAO terms to define all procedural and semantic meaning. If its desired to separate the annotation of "timecourse", "steady state", etc. from specific simulation algorithms that imply timecourse, steady state, etc. this could be captured with other KiSAO terms or maybe SBO terms would be more appropriate. This would allow more flexibility and granularity without forcing that complexity into more SED-ML classes.