Open jonrkarr opened 3 years ago
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.
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.
Presently, SED-ML supports four specific types of operations on models
This excludes many other types of analysis of models, as well as some other types of simulations. Examples:
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:Simulation
a concrete rather than abstract classAbstractSimulation
class. ChangeSteadyState
,OneStep
andUniformTimeCourse
to inherit fromAbstractSimulation
. Create a newSimulation
class which also inherits fromAbstractSimulation
.Within SED and libSED-ML, this Simulation
class would functional identical to
SteadyStatein that neither would have additional attributes that aren't inherited from
AbstractSimulation. Despite this,
Simulationis needed because the specific semantic meaning of
SteadyState` 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 akisaoId
attribute to thisSimulation
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).