Re: [SED-ML-discuss] Discussion on SED-ML future from COMBINE 2013

[Lucian S. <luc...@gm...>]

The slides are now up:  http://co.mbine.org/events/COMBINE_2013/agenda
in the 'SED-ML future' section.

-Lucian

On Tue, Oct 1, 2013 at 9:00 PM, David Nickerson
<dav...@gm...> wrote:
> Hi all,
>
> At the recent COMBINE meeting in Paris we had a session where we
> discussed some potential future features and requirements that may be
> needed in SED-ML to make it more able to encode the requirements of
> various user communities. Slides and video from the session will
> (soon) be available at: http://co.mbine.org/events/COMBINE_2013/agenda
>
> The latter part of the session looked into some issues raised by Chris
> Meyers and his experiences in evaluating SED-ML for use with the
> iBioSim tool (http://www.async.ece.utah.edu/iBioSim/). As Chris was
> unable to attend the session at COMBINE, and because these issues are
> likely of wider interest to the SED-ML community, I provide here a
> summary of the discussion from that session (my recollection, at
> least, please correct me if I get anything wrong!). Everything is, of
> course, open for discussion :)
>
>> About a year ago, we implemented support for importing SED-ML files into iBioSim.  More specifically, the subset of SED-ML that is used in the SBML test suite.  This worked reasonably well, and we then considered potentially using SED-ML to describe internally the information that we store about our simulations, but we ran into several snags and have abandoned this for now.  Note that my comments are at least a year old, so some of these items may have been addressed, and others may have been our own ignorance of how to use SED-ML.  Also, this is likely not a complete list and some things are very specific to iBioSim.  However, you may find some of the limitations useful to know about.  Here are the items that we could not describe in SED-ML without using custom annotations:
>>
>> 1) Our SBML models are often converted to new models at various levels of abstraction.  Describing this process of conversion would not be easy to express.  We need to be able to say though which abstraction we are using.  This is likely a custom annotation.
>>
>
> agreed, this is a custom annotation. It would be nice to see these
> kinds of annotations and how they are used in SED-ML to see if anyone
> else uses this sort of information when performing simulation
> experiments. I wonder if this is somewhat similar to the idea of
> having a template simulation experiment which can be applied to many
> different models, as long as there is some systematic manner by which
> to identify the required data from the model... if so, there may be
> some overlap with Jonathan's functional curation work and some of the
> extensions he has been using with SED-ML might be worth investigating
> to see if there is any common ground that could be standardised and
> exchanged?
>
>> 2) It would be nice to know a general class of analysis algorithm being used (i.e., ODE, monte carlo, markovian, FBA, etc.)  as well as the more specific type of analyzer used.  Ideally, this can be handled by KISAO, but the support for KISAO did not make this very easy to do.  This may have been fixed by now.
>>
>
> This should now be handled by KiSAO and libKiSAO
> (http://biomodels.net/kisao/libkisao.html). If not, feature requests
> (or code!) should be submitted there.
>
>> 3) Since we develop new simulation methodologies, we are often creating new ones.  This would require a lot of back in forth with KISAO which is not very appealing especially since we abandon or consolidate methods as time goes by.  Perhaps, it is good to have custom analysis method term with a string for the custom method.  We also have methods like produce GraphViz file or xHTML file, etc.  Are these analysis methods for KISAO?  Not so sure that custom with string is not better for those as well.  Or in those, maybe term for display model and then a custom field for type of display.
>>
>
> Everyone agreed that being able to have a custom simulation algorithm
> would be a useful feature. I have added a feature request to the
> SED-ML tracker for this
> (https://sourceforge.net/p/sed-ml/feature-requests/5/). It would be
> good to get feedback from the community on this issue.
>
>> 4) We also have several options for an analysis that there is no field for, such as whether runs should be generated or just statistics, whether to use number of steps or a print interval (also have a minimal print interval for non-uniform stepping).  We need to be able to specify both minimum and maximum allowed time steps, absolute error, random seed, and number of runs.  Some of these may be supported but I pretty sure they are not all supported.
>>
>
> Some of these are possible in SED-ML L1V2 using the simulation
> algorithm parameters now available in KiSAO (http://goo.gl/Bg8Pm1).
> These can be specified in the new <algorithmParameter> construct
> introduced in SED-ML L1V2. Others can be implemented making use of the
> new nested tasks and simulation classes that will also be available in
> SED-ML L1V2. Others, such as random seed, might need extensions to
> KiSAO or SED-ML to be completely supported. Similar features may also
> be supported by the post-processing of simulation results in the
> SED-ML data generators.
>
> In any case, if there are specific use-cases not supported by any of
> the above we are very keen to hear about them and see them in action.
>
>> 5) I mentioned that we have various model abstraction techniques, things like applying steady state approximations, etc.  There is no way to specify these and their corresponding parameters.
>>
>
> SED-ML L1V2 introduces the steady-state simulation class which might
> address some of your requirements here. It would be great to see if
> you could encode your other abstraction techniques in SED-ML, perhaps
> using the custom simulation algorithm mentioned above along with some
> custom algorithm parameters.
>
>> 6) We have means to modify parameters and initial values for simulation, but I was not enamored with the method for this in SED-ML.  I feel like something like replacements and deletions in comp may work better.
>>
>
> People involved in the COMBINE discussion agreed that it would not be
> a good idea to make use of SBML's comp package directly and that the
> current methods available in SED-ML worked sufficiently well to meet
> peoples needs. If you have specific examples where something closer to
> the comp constructs might be better, then it would be great to discuss
> them here.
>
>> 7) We have a visualization tool that allows us to play back a simulation on a schematic, so we need a way to associate colors gradients to values from the simulation.
>>
>> 8) The graphing support in SED-ML is lacking things like colors to use, shapes to use, whether the points should be connected or not, or the shapes should be visible or filled.  Also, how to scale the plots, whether to have a log axis, should the legend be visible.  How about using an x-axis other than time?  We also support histograms for some types of data like the probability of each type of constraint being violated, and I don't think there is support for that.
>>
>
> SED-ML provides a method to encode the application of a simulation
> algorithm to a model to produce some data, along with pre- and
> post-processing steps. It doesn't have any concept for the graphical
> representation of the data, other than the possibly badly named plot*,
> curve, and surface elements. People at COMBINE feel that this is a
> good scope for SED-ML and that we don't want to start getting in to
> describing the graphical rendering of the resultant data. The output
> classes currently available in SED-ML are aimed at producing the
> required data, rather than what to actually do with that data - other
> than the hints provided by the element names such as plotting a curve
> on a set of axes. During the meeting, Nicolas pointed out the Charts
> Ontology (http://data.lirmm.fr/ontologies/chart), which might be
> useful if we want to extend the output classes in SED-ML in future
> versions if the community agrees that this is something we do need to
> address.
>
> Things like an x-axis other than time, scaling of data, and log axes
> are already a part of SED-ML.
>
> Issues like producing the data for a histogram or other more detailed
> post-processing are likely beyond the scope of the current data
> generators in SED-ML. One way to address this is by being able to link
> the results from one simulation as the inputs to another simulation,
> which would allow arbitrary complexity in the post-processing inasmuch
> as the modelling language you use to encode the model supports it.
> Feature requests and proposals for extensions to SED-ML are always
> welcome :)
>
>> I should probably look at SED-ML again and re-evaluate, but last time it seemed like our SED-ML file would be more custom annotation than SED-ML file which is why we abandoned it.  I'm not sure which items above are common across tools, but it would be interesting to see if there is at least some commonality that can be weaved into SED-ML.
>>
>
> It would be great if iBioSim were to be able to export SED-ML,
> especially given that you support (or will support) a large number of
> the SBML L3 packages and will therefore provide a great test-case for
> the usefulness of SED-ML with a wide range of types of SBML models. If
> you, or anyone out there, have any further questions or points for
> discussion, I'm sure there are people on this list happy to help out
> where possible.
>
> Stay tuned for the release of SED-ML L1V2 :)
>
>
> Cheers,
> David.
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss