sed-ml-discuss — Migrating to google groups: https://groups.google.com/d/forum/sed-ml-discuss

[SED-ML-discuss] New editors

[Nicolas Le N. <le...@eb...>]

Dear Colleagues,

On July 3rd, you were asked to nominate potential candidates for the 
position of SED-ML editor. Four people were nominated. Two declined the 
nomination. Jonathan Cooper, who was nominated three times, accepted. The 
comments attached to the nomination were:

"Jonathan has made significant contributions to the development of SED-ML 
and has experience as an active member of several related communities."
"Jonathan has extensive experience with markup and domain specific 
languages and has good ideas for the extension of SED-ML"
"Activity on the list"

I was also nominated once. The comment attached to the nomination was: "Who 
would be better suited?".

The current SED-ML editors therefore decided to stop the election procedure 
at the nomination step. Jonathan Cooper becomes SED-ML editor for a 3 year 
term, until summer 2015. I initially intended to decline the nomination, 
but due to the circumstances will become an editor for a year. At the next 
election in the summer of 2013, we will therefore replace two editors, 
David Nickerson and myself.

On the behalf of the editors, I would like to thank Richard Adams and 
Andrew Miller for their help, and all of you for your continuing 
participation and support.

Best regards

-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
le...@eb..., Skype:n.lenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [SED-ML-discuss] Nested Proposal V3

[Jonathan C. <jon...@cs...>]

Hi Frank,

Unfortunately I've run out of time to address all your points before 
going on holiday, but I did look at one.

On 22/07/2012 15:44, Frank T. Bergmann wrote:
>> Regarding especially the two points for discussion, I think the best 
>> solution is actually to have 3 concrete subclasses of an 
>> AbstractTask: ModelTask, NestedTask (or RepeatedTask if that name is 
>> preferred), and CombinedTask.  Frank's current RepeatedTask proposal 
>> combines aspects of all three of these concepts into one class, and I 
>> think things are clearer and easier to implement if they are separated.
>>
>
> While I can follow your reasoning, having implemented the proposal, I 
> can say that it was quite easy to do so. For me restricting the 
> RepeatedTask by breaking it out as proposed does make for a more 
> complex object structure than what would be currently needed when 
> using the V3 proposal. But it is true that more complex tasks could be 
> constructed through repeated applying of Nested + Combined + 
> ModelTasks. In any case it would be great to see concrete examples on 
> how you would like this to look.

A simple test example can be found at 
https://chaste.cs.ox.ac.uk/cgi-bin/trac.cgi/browser/projects/FunctionalCuration/test/sedml/data/test_combined_task.xml, 
with the test that runs it and checks the results at 
https://chaste.cs.ox.ac.uk/cgi-bin/trac.cgi/browser/projects/FunctionalCuration/test/sedml/TestSedmlExtensions.hpp.

I found the most complex part of implementing both nested and combined 
tasks, but especially the latter, was getting the result data back in a 
useful (n-d array) form.

Best wishes,
Jonathan

Re: [SED-ML-discuss] Nested Proposal V3

[Maciej S. <mj...@eb...>]

Hi Frank and list,

as far I can see, the proposal concentrates around 'simulation' tasks only, at least notation wise,
which would is quite restrictive from the PK/PD (pharmacokinetics/pharmacodynamics) point of view.

I would like to mention here tasks, like those supported by population PK/PD software tools (e.g. Monolix)
1 - estimation of population parameters
2 - estimation of individual parameters
3 - estimation of Fisher Information Matrix
4 - estimation of log-likelohood
E.g. 1 & 2 or 1 & 3 are strictly sequential in that order.

Usually, one would be interested in all these outcomes formulated in a single task or in a specific combination of these.

Also, in the (clinical trial) simulation domain, there are examples of sequential simulation only tasks, 
e.g. multiple dosing with dose every 12h. 
In this scenario 
step 1. single dose concentration profiles are simulated
step 2. they are superposed to a multiple-dose time course
step 3. application of the superposed signal to a PD or SB type of model
(I could send you some concrete examples if this helps.)

It's probably a minor correction, but it would be helpful to consider above mentioned scenarios as useful test cases for the proposal development.

Best Regards,
Maciej


On Jun 10, 2012, at 12:43 PM, Frank T. Bergmann wrote:

> Hello together, 
> 
> I have modified my original proposal and added the suggestions made by
> Nicolas and the discussions at HARMONY 2012. The key changes: 
> 
> - instead of a NestedSimultion class a RepeatedTask is used
> - the SteadyState simulation class is back
> 
> The proposal can be found here: 
> 
> http://identifiers.org/combine.specifications/sed-ml.proposal.nested-simulat
> ions.FB.version-3
> 
> And an implementation is available with the SED-ML Web Tools: 
> 
> http://sysbioapps.dyndns.org/SED-ML_Web_Tools/
> 
> where all examples are available to be run. 
> 
> 
> Points for discussion: 
> --------------------------
> - Stuart brought up the idea of having subTasks not specifying an order
> attribute 
>  but instead they would describe the tasks they depend on. The idea being
> that 
>  this would allow for a potential parallel execution of tasks. 
> 
> - Should we have further task subclasses or not? 
> 
> I look forward to your comments. 
> 
> Cheers
> Frank
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Nested Proposal V3

[Frank T. B. <fbe...@ca...>]

Hello Jonathan, 

Thank you for taking time to go through it!

> Regarding especially the two points for discussion, I think the best solution is actually to have 3 concrete subclasses of an AbstractTask: ModelTask, NestedTask (or RepeatedTask if that name is preferred), and CombinedTask.  Frank's current RepeatedTask proposal combines aspects of all three of these concepts into one class, and I think things are clearer and easier to implement if they are separated.
> 

While I can follow your reasoning, having implemented the proposal, I can say that it was quite easy to do so. For me restricting the RepeatedTask by breaking it out as proposed does make for a more complex object structure than what would be currently needed when using the V3 proposal. But it is true that more complex tasks could be constructed through repeated applying of Nested + Combined + ModelTasks. In any case it would be great to see concrete examples on how you would like this to look. 
> 
> 
> Now to more low-level details.
> The 'range' attribute on repeatedTask seems to be redundant and potentially confusing, especially as there can be multiple ranges.  What's the behaviour if there are multiple unrelated ranges with different numbers of values?  Presumably we should enforce that all ranges have the same number of values, and are all iterated over simultaneously, hence just providing different values for the benefit of changes. Since individual changes can specify range(s) of interest, "blessing" one range doesn't seem necessary.

For me the range attribute was vital whenever multiple ranges are applied. I've considered the use case, that you would like to have the nested task operate over one range but then parameterize other elements using for example a functional range.


> There are several methods presented for referring to a range value from a setValue change. I prefer the way shown in the examples on page 5 of Frank's proposal, where a variable element is used to link the range id to a variable id for use in the math block - this seems most in line with existing SED-ML behaviour, and also allows a change to reference multiple ranges cleanly, which the approach of giving a range attribute on the setValue element doesn't.
Both approaches, of either using an attribute on setValue or defining a variable works fine for me.  
> The same comment applies to the index attribute on a functionalRange. Again you could be explicit about it by defining a variable.  I can see the benefit of keeping the short-hand method for common cases, but suggest that it is explicitly defined as being a short-hand.
That works for me ...
> With resetModel, is the intention that it resets to the initial conditions of the model, or the model's state as it existed at the start of the task?  I think from page 4 you envisage the former, but the latter seems more flexible to me (and not much harder to implement). It would allow you, for instance, to have a sequence of tasks in which the first gets the model to steady state, and the second does a repeated simulation from that point.
Correct, for me it ought to be a full reset. I would prefer to be explicit about the different model states we want to keep around. So that would mean that I much rather see a different ChangedModel, that could be defined as the result of running a task. I see this as being useful in many cases. 
> 
> I don't particularly like having a step attribute on oneStep - I'd much rather have a simulation class on which I can specify the desired end point to reach.
I'm afraid I can't see how to achieve the same flexibility in defining simulation experiments, if we would always have to specify the end time in advance. If you like you could provide some examples. 
> 
> I also have a question on which I'd like input from others with more experience: the oneStep proposal specifies that it "defines a simulation step of a deterministic simulation." Is there any reason why you can't run a stochastic simulation up to a desired end point? 
There is no reason not to allow that if you feel it is useful. It certainly is no problem to stop stochastic simulations whenever they pick a next event that is outside the step to be taken and return the last values. I just never found it useful to do so.  

> There is also a related use case that might be worth considering here: what if you're simulating a cell-cycle model, and wish to run up until the model indicates cell division should occur? In this case you don't know what the ultimate end point will be, and you'll almost certainly want to resolve it to greater precision than a repeatedTask range or timecourseSimulation output granularity.
I appreciate that we might want to extend SED-ML to also cover this, but  feel that is independent of the one step. To do this i would define a different simulation class that would be given a root finding functions so it could run the given model until a root crossing is found. Or we could have a ChoiceTask, that would run one task, then check an arbitrary condition and based on that evaluation could decide what task to run next. The former would be the most accurate but would require more work on the simulators to implement this. I believe we could get to that once we have repeated tasks. 

All the best
Frank

[SED-ML-discuss] [Combine-announce] Time to register to COMBINE 2012!

[Nicolas Le N. <le...@eb...>]

Dear colleagues,

COMBINE 2012 will start in less than a month. In order to put together an 
interesting and robust agenda, we need to know who is attending. Please, if 
you intend to attend the meeting (and I hope you do), register ASAP:
http://co.mbine.org/events/COMBINE_2012

Best regards

-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
le...@eb..., Skype:n.lenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/


_______________________________________________
Combine-announce mailing list
Com...@eb...
http://listserver.ebi.ac.uk/mailman/listinfo/combine-announce

Re: [SED-ML-discuss] Nested Proposal V3

[Jonathan C. <jon...@cs...>]

Hi Frank et al.,

I've been thinking about this and playing around with ideas for the last 
few weeks; trying to see how it fits with our protocol language ideas 
too.  (Incidentally, our functional curation tool now supports (most of) 
SED-ML L1V1, and I should have the suggestions below implemented too in 
time for COMBINE.)

Regarding especially the two points for discussion, I think the best 
solution is actually to have 3 concrete subclasses of an AbstractTask: 
ModelTask, NestedTask (or RepeatedTask if that name is preferred), and 
CombinedTask.  Frank's current RepeatedTask proposal combines aspects of 
all three of these concepts into one class, and I think things are 
clearer and easier to implement if they are separated.

  * ModelTask provides the current L1V1 Task - it associates a model
    with a simulation algorithm. This would be the only task with a
    simulationReference and modelReference.
  * NestedTask provides the ranges, changes, and a single subtask that
    gets run repeatedly. The option to iterate directly over a
    simulation by providing a simulationReference and modelReference can
    be expressed just as well by providing a ModelTask as subtask, and
    avoids conflating different behaviours in one class.
  * CombinedTask allows tasks to be grouped: it has a listOfSubtasks,
    and a scheduling attribute that specifies whether they must be run
    in the order given (sequential) or whether order is immaterial and
    hence they could be parallelised (parallel).

CombinedTask allows you to structure dependencies between tasks that are 
as complex as you like, by having CombinedTasks as subtasks of another 
CombinedTask.  Personally I think it's also clearer and easier to 
implement than having either an order attribute or listing task 
dependencies.

Of course, this does change the Task class hierarchy.  But since the 
L1V1 Task class still exists unchanged in my proposed hierarchy (it's 
just not at the top) I don't think that's too much of an issue even if 
we wanted this to go in L1Vx; for L2 I think achieving a clean (and 
hence more easily comprehensible) design should be the most important 
concern.


Now to more low-level details.

  * The 'range' attribute on repeatedTask seems to be redundant and
    potentially confusing, especially as there can be multiple ranges. 
    What's the behaviour if there are multiple unrelated ranges with
    different numbers of values? Presumably we should enforce that all
    ranges have the same number of values, and are all iterated over
    simultaneously, hence just providing different values for the
    benefit of changes. Since individual changes can specify range(s) of
    interest, "blessing" one range doesn't seem necessary.
  * There are several methods presented for referring to a range value
    from a setValue change. I prefer the way shown in the examples on
    page 5 of Frank's proposal, where a variable element is used to link
    the range id to a variable id for use in the math block - this seems
    most in line with existing SED-ML behaviour, and also allows a
    change to reference multiple ranges cleanly, which the approach of
    giving a range attribute on the setValue element doesn't.
  * The same comment applies to the index attribute on a
    functionalRange. Again you could be explicit about it by defining a
    variable.  I can see the benefit of keeping the short-hand method
    for common cases, but suggest that it is explicitly defined as being
    a short-hand.
  * With resetModel, is the intention that it resets to the initial
    conditions of the model, or the model's state as it existed at the
    start of the task?  I think from page 4 you envisage the former, but
    the latter seems more flexible to me (and not much harder to
    implement). It would allow you, for instance, to have a sequence of
    tasks in which the first gets the model to steady state, and the
    second does a repeated simulation from that point.
  * I don't particularly like having a step attribute on oneStep - I'd
    much rather have a simulation class on which I can specify the
    desired end point to reach.
      o The main reason for this is that in moderately long-running
        simulations, the way in which you calculate time points can
        noticeably affect the results you get: if you use repeated
        addition of a time-step, accumulated floating point error can
        even mean you don't end up at the expected overall end time
        exactly, and have to take a very small or slightly larger final
        step.  If instead you compute output time points as
        num_steps*dt, they're computed more accurately and you don't get
        any issues for the final step (provided of course that dt
        divides the overall interval).
      o Another advantage to specifying end point rather than step is
        that you don't have the "step" information duplicated in both
        the range of the task and the step of the simulation. The task's
        range naturally provides the value up to which you want to solve
        in all the cases I can think of.
      o Specifying the end point based on the range value does require,
        however, that you can parameterise your simulation and/or task
        classes, and that setValue in a NestedTask can address these
        parameters as well as those in the model. For the latter point,
        we could extend the target attribute to allow values such as
        '#id' as well as XPath expressions; '#id' is not valid XPath so
        there's no potential for confusion. Whereas an XPath expression
        would address a model variable/parameter, the use of #id would
        select the protocol parameter with matching id. Specifying what
        parameters are available would require some more work, possibly
        building on Richard's proposal
        <http://sourceforge.net/tracker/?func=detail&aid=3391892&group_id=293618&atid=2532228>.
  * I also have a question on which I'd like input from others with more
    experience: the oneStep proposal specifies that it "defines a
    simulation step of a deterministic simulation." Is there any reason
    why you can't run a stochastic simulation up to a desired end
    point?  There is also a related use case that might be worth
    considering here: what if you're simulating a cell-cycle model, and
    wish to run up until the model indicates cell division should occur?
    In this case you don't know what the ultimate end point will be, and
    you'll almost certainly want to resolve it to greater precision than
    a repeatedTask range or timecourseSimulation output granularity.

Best wishes,
Jonathan


On 10/06/2012 11:43, Frank T. Bergmann wrote:
> Hello together,
>
> I have modified my original proposal and added the suggestions made by
> Nicolas and the discussions at HARMONY 2012. The key changes:
>
> - instead of a NestedSimultion class a RepeatedTask is used
> - the SteadyState simulation class is back
>
> The proposal can be found here:
>
> http://identifiers.org/combine.specifications/sed-ml.proposal.nested-simulat
> ions.FB.version-3
>
> And an implementation is available with the SED-ML Web Tools:
>
> http://sysbioapps.dyndns.org/SED-ML_Web_Tools/
>
> where all examples are available to be run.
>
>
> Points for discussion:
> --------------------------
> - Stuart brought up the idea of having subTasks not specifying an order
> attribute
>    but instead they would describe the tasks they depend on. The idea being
> that
>    this would allow for a potential parallel execution of tasks.
>
> - Should we have further task subclasses or not?
>
> I look forward to your comments.
>
> Cheers
> Frank
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

[SED-ML-discuss] SED-ML proposal vote: Algorithm parameters

[Dagmar W. <dag...@un...>]

Dear SED-ML community,

a while ago we discussed Richard's proposal of describing algorithm 
parameters (using KISAO) in SED-ML:
http://sourceforge.net/tracker/index.php?func=detail&aid=3391892&group_id=293618&atid=2532228 


We did not receive any objections to the current proposal and therefore 
would like to open up the voting on whether to integrate the proposal in 
the SED-ML standard.

To summarize briefly, the vote is about the following extension to SED-ML:
In SED-ML Level 1 Version 1, there is currently no mechanism to 
parameterize a particular simulation algorithm, for example with 
tolerances or algorithm-specific arguments. This proposal aims to 
develop the Algorithm class to support such parameterization.
Further information on the proposal is available from:
http://co.mbine.org/standards/sed-ml/proposal/kisao/RA/version-1

Please vote on the algorithm parameter proposal on:
https://docs.google.com/spreadsheet/viewform?formkey=dDNaeW1SeVhZWjhFMmkzQ2lBWjdCZHc6MA#gid=0 


The vote will close on the 3rd of August. All members of sed-ml-discuss 
are eligible to vote. A majority of the votes need to be in favor to 
accept the proposal. The vote includes yes-no-revise options and there 
is no minimum requirement for the number of votes needed. Further 
information on the voting process is available from 
http://sed-ml.org/specifications.html

With kind regards,
Dagmar Waltemath, on behalf of the SED-ML editors.

[SED-ML-discuss] Fwd: [sysbio] Reminder: please register for COMBINE 2012

[David N. <dav...@gm...>]

---------- Forwarded message ----------
From: Michael Hucka <mh...@ca...>
Date: Tue, Jul 10, 2012 at 6:53 AM
Subject: [sysbio] Reminder: please register for COMBINE 2012
To: sy...@ca...


Greetings, all you systems-oriented, biologically-inclined people:

With COMBINE 2012 only a month away, we encourage all attendees to
register as soon as possible so that the hosts can plan appropriately.
 Please also submit abstracts for talks and/or posters.

The Computational Modeling in Biology Network (COMBINE) is an initiative to
coordinate the development of the various community standards and formats,
initially in Systems Biology and related fields. The Annual COMBINE forum
is a workshop-style event with oral presentations, posters and breakout
sessions. The meeting provides an opportunity for those involved in many
related standardization and software efforts in systems biology to meet and
discuss their efforts, with the aim of working more closely together to
ensure smooth interoperability between systems.

http://co.mbine.org/events/COMBINE_2012

COMBINE 2012 will take place at The Donnelly Centre building at the
University of Toronto from Wednesday August 15 to Sunday Aug. 19, 2012,
immediately preceding the 13th International Conference on Systems Biology
(http://icsb2012toronto.com/). The COMBINE conference location is a short
walk from ICSB events and COMBINE 2012 is an official satellite meeting of
ICSB, so you can follow the same travel and accommodation instructions for
ICSB and use the same hotel discounts. Registration for COMBINE is $125
(Canadian) to cover costs associated with the meeting, including a workshop
dinner and catering.

We hope to see you there!
Gary, Nicolas and Mike
____________________________________________________________
To manage your sysbio list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sysbio

For a web interface to the sysbio mailing list, visit
http://bnmc.caltech.edu/Forums/

For questions or feedback about the sysbio list,
contact bnm...@ca...

[SED-ML-discuss] Nomination of candidates for editorship of SED-ML

[Nicolas Le N. <le...@eb...>]

Dear Colleagues,

A year ago, we elected our five SED-ML editors. In order to ensure 
continuity, it was decided to go for a gradual replacement of the editors. 
Accordingly, Andrew Miller is due to terminate his term in December 2012.
http://sourceforge.net/mailarchive/forum.php?thread_name=4DDA115A.9010307%40ebi.ac.uk&forum_name=sed-ml-discuss

In addition, because of personal circumstances, Richard Adams expressed the 
wish to be relieved of his editor duties. We will therefore elect two new 
editors, for a 3 years term, from January 2013 to December 2015.

By this e-mail, we are calling for nominations of possible candidates. The
nominations are anonymous. You may nominate anyone (including yourself)
that you believe is qualified and would act as a good SED-ML editor. You
may fill out this form more than once, for nominating multiple individuals.
I will gather the results and create a single list of all unique candidates 
along with the rationales for their nominations, then verify with each 
individual that they accept the nomination, and finally
issue a call for voting.

Please, nominate your favorite candidates before July 13th midnight GMT at:
https://www.surveymonkey.com/s/FLW78GD

Best regards,

-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
le...@eb..., Skype:n.lenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

[SED-ML-discuss] [Combine-announce] Registration is now open for COMBINE 2012. Aug.15-19 in Toronto, Canada

[Nicolas Le N. <le...@eb...>]

Dear Colleague,

The Computational Modeling in Biology Network (COMBINE) is an initiative to 
coordinate the development of the various community standards and formats, 
initially in Systems Biology and related fields. The Annual COMBINE forum 
is a workshop-style event with oral presentations, posters and breakout 
sessions.  The meeting provides an opportunity for those involved in many 
related standardization and software efforts in systems biology to meet and 
discuss their efforts, with the aim of working more closely together to 
ensure smooth interoperability between systems.

http://co.mbine.org/events/COMBINE_2012

COMBINE 2012 will take place at The Donnelly Centre building at the 
University of Toronto from Wednesday August 15 to Sunday Aug. 19, 2012, 
immediately preceding the 13th International Conference on Systems Biology 
(http://icsb2012toronto.com/). The COMBINE conference location is a short 
walk from ICSB events and COMBINE 2012 is an official satellite meeting of 
ICSB, so you can follow the same travel and accommodation instructions for 
ICSB and use the same hotel discounts. Registration for COMBINE is $125 
(Canadian) to cover costs associated with the meeting, including a workshop 
dinner and catering.

We hope to see you there!

-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
le...@eb..., Skype:n.lenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/



_______________________________________________
Combine-announce mailing list
Com...@eb...
http://listserver.ebi.ac.uk/mailman/listinfo/combine-announce

[SED-ML-discuss] [Combine-announce] Interested in hosting a future COMBINE or HARMONY?

[Michael H. <mh...@ca...>]

Standards-inclined systems biologists,

Are you interested in hosting a future COMBINE or HARMONY meeting?  Please let us know your interests as soon as possible by filling out the interest survey at 

  http://www.surveymonkey.com/s/combine-harmony-hosting-interest

We hope to settle the plans for 2013 in the next couple of weeks, so if you are interested, please let us know!

The COMBINE coordinators 
Nicolas, Gary, Mike
_______________________________________________
Combine-announce mailing list
Com...@eb...
http://listserver.ebi.ac.uk/mailman/listinfo/combine-announce

[SED-ML-discuss] Nested Proposal V3

[Frank T. B. <fbe...@ca...>]

Hello together, 

I have modified my original proposal and added the suggestions made by
Nicolas and the discussions at HARMONY 2012. The key changes: 

- instead of a NestedSimultion class a RepeatedTask is used
- the SteadyState simulation class is back

The proposal can be found here: 

http://identifiers.org/combine.specifications/sed-ml.proposal.nested-simulat
ions.FB.version-3

And an implementation is available with the SED-ML Web Tools: 

http://sysbioapps.dyndns.org/SED-ML_Web_Tools/

where all examples are available to be run. 


Points for discussion: 
--------------------------
- Stuart brought up the idea of having subTasks not specifying an order
attribute 
  but instead they would describe the tasks they depend on. The idea being
that 
  this would allow for a potential parallel execution of tasks. 

- Should we have further task subclasses or not? 

I look forward to your comments. 

Cheers
Frank

[SED-ML-discuss] nested proposal (CellML) examples

[David N. <dav...@gm...>]

I have been playing around with some examples of nesting in SED-ML. I
have put up some examples based on CellML models at:
http://models.cellml.org/w/andre/testing-Sed-ML-nesting (you can see a
bit of description about the current version of these at
http://models.cellml.org/e/c2/). I'll try to keep these relatively up
to date as the nested proposal develops following on from discussions
here at HARMONY.

If anyone has examples they would like to see, contribute, etc. please
let me know - happy to add anyone as authors in the workspace so you
can contribute directly to the repository.

Cheers,
David.

Re: [SED-ML-discuss] Nested Proposal v2

[Nicolas Le N. <le...@eb...>]

On 12/05/12 16:56, Frank T. Bergmann wrote:

> My main concern are still:
>
> - that there is no concept of continuing with a simulation between the
> repeated executions of the uniformTimeCourse elements. I don't think it is
> merely an issue of the initialTime. When using the oneStep element, it would
> yield precisely one row of data to be used (performing however many internal
> steps as need be). Between each steps the model state would remain the same
> (unless the reset attribute was specified). When we are combining now the
> elements of several uniformTimecourses it is not the same as using a oneStep
> (you couldn't even use the computeChange anymore to use a programmatic
> change of the values to be set later on).

I do not understand that. I am sure you are right, but you need to explain 
on a whiteboard next week :-)

> A couple of things I'm not clear about they are:
>
> - the sampling attribute you added to the uniformRange (you wrote several
> times sampling="linear")

We need to know if a sampling is linear, logarithmic or random.

> - I think the one simpleTask was just a typo ...

Yes.

> - In your example only the RepeatedTasks used ranges is that correct? Or do
> both use them?

Yes. The single task is executed once. So a range does not make sense.

> - how do repeats and list of subtasks work together? Is it "for each value
> of the range go through all subtasks" or is it "for each subtask go through
> each value of the range" ?

The former is what I had in mind. It is a hierarchical scheme.

> - What if there are multiple ranges defined? (I had an attribute defined on
> the nestedSimulation that took the id of a range contruct. Could we have
> something like that?)

I think there is not problem with that. But that is equivalent with nested 
task, each one with a range, no?

> - resetModel attribute on singleTask elements (when there is no
> listOfSubModels, how would they apply)

I am not sure I understand (even if I replace listOfSubModels by 
listOfSubtasks). You need the resetModel element. In the example of 
perturbation, for instance, you do not reset the values before executing 
the next task.

> To the examples:
>
> - example 1&  2&  5: can be implemented easily
>
> - example 3: not enough information
> - Perturbing a simulation: From the description it would seem that we could
> re-implement the same with SED-ML L1V1 currently using multiple timecourse
> simulation and changedModel constructs. I don't see how the singleTask
> helps.

This is almost true. Exept, at the moment we cannot order tasks. So I do 
not know how to feed the values from one simulation to the changeModel.

> - Perturbing a simulation: as output refers to output from one simulation
> task, it would be better to rewrite the example using a ListOfSubTasks, but
> then of course the simulationReference on the master task would not mean
> anything

I actually provided two alternatives for this one, the second using 
listOfSubtasks, as you write below.

> - example 4:  addresses the problem in 3, however constructing the example
> like this will be difficult for tool writers. Instead of describing the
> perturbation they want to perform they would need to subdivide the
> simulations / tasks and everything in a non-trivial way.

It is not more artificial than what we do at the moment. The way we "hack" 
the events to put time dependency only comes from the adaptation to SBML 
events and their abuse. And it becomes much clearer if you use several 
simulation tools simultaneously.

> - example 6: the master flag on task2 should be false right? Apart from that
> I'm still not quite sure how ranges and subtasks work together ...

Yes, sorry.

>> -----Original Message-----
>> From: Nicolas Le Novère [mailto:le...@eb...]
>> Sent: Friday, May 11, 2012 6:08 PM
>> To: sed...@li...
>> Subject: Re: [SED-ML-discuss] Nested Proposal v2
>>
>> Hello all,
>>
>> I finally blocked some time to come up with a modification of Frank's
> proposal
>> that uses nested tasks instead of simulations. In addition, I believed
> Frank tried
>> to kill two birds with one stone, i.e. multiple identical (but for a
> value)
>> simulations, and compounded simulations. In order to be both flexible and
>> expressive, I believe we should disentangle the problem. Here is what I
> propose:
>>
>> * Tasks are subclassed in singleTasks and repeatedTasks. The formers are
> Frank's
>> "oneSteps", and call a simulation once. The latter are for multiple runs
> and scans
>> and call a simulation multiple times.
>>
>> * Tasks (both single and repeated) can contain ordered subclasses, that
> refer to
>> other tasks. All the subtasks have to be executed once for a single task,
> and each
>> time for a repeated task. There is one task declared as "master".
>>
>> * We reuse Frank's ranges and changes.
>> I discovered a few issues that deserve separate discussions:
>>       ** We should be coherent in the naming (listOf or not listOf).
>>       ** The changes in "task" should be completely coherent with the
> changes in
>> "model". To be honest, model changes at initial time are just a specific
> type of
>> task changes. Should-we refactor that part of the spec a bit so we have
> all the
>> model changes in one place?
>>       ** The references to the current value of the range are a bit
> heterogeneous
>> according to the type of range. Some homogeneisation would be good for
>> clarity.
>>       ** I kept all the attributes as they were so far. We may have to
> re-organise
>> things a bit.
>>
>> * I kept the uniformTimecourse and reintroduced steadyState. To get rid of
>> them completely, we should suppress the simulation class and refer to a
> KiSAO
>> term directly in the task. But then, there is the issue of Richard's
> proposal, and
>> possible extra information we'll store. Honestly, I can't see the
> advantage of
>> getting rid of them. BUT, we need to rework on the parameters. Attributes
> like
>> "initialTime" belong to the task, not the simulation. That would solve the
>> parametrisation mentioned by Jonathan.
>>
>> The result is quite neat I think, and more readable for me (but that is
> just me).
>> Below, I encoded all the examples in Frank's document. I only included the
>> models, simulations and tasks. We can work on the output later. I also
> attach a
>> text file with better formatting.
>>
>> 1D kinetics parameter scan with repeatedTask
>> ============================================
>>
>>     <listOfModels>
>>       <model id="model1" language="urn:sedml:language:sbml"
>>
>>
> source="http://libsedml.svn.sourceforge.net/viewvc/libsedml/trunk/Samples/m
>> odels/oscli.xml"
>> />
>>     </listOfModels>
>>
>>     <listOfSimulations>
>>       <uniformTimeCourse id="timecourse1" initialTime="0"
>> outputStartTime="0" outputEndTime="20" numberOfPoints="1000">
>>         <algorithm kisaoID="KISAO:0000019" />
>>       </uniformTimeCourse>
>>    </listOfSimulations>
>>
>>     <listOfTasks>
>>       <repeatedTask id="task1" master="true" modelReference="model1"
>> simulationReference="timecourse" resetModel="true">
>>         <ranges>
>>           <vectorRange id="current">
>>             <value>8</value>
>>             <value>4</value>
>>             <value>0.4</value>
>>           </vectorRange>
>>         </ranges>
>>         <changes>
>>           <setValue
>> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
>> 0_v0']"
>>                     range="current">
>>             <math xmlns="http://www.w3.org/1998/Math/MathML">
>>               <ci>  current</ci>
>>             </math>
>>           </setValue>
>>         </changes>
>>       </repeatedTask>
>>     </listOfTasks>
>>
>>
>> 1D steady state parameter scan with repeatedTask
>> ================================================
>>
>> <listOfModels>
>>     <model id="model1" language="urn:sedml:language:sbml"
>>
>>
> source="http://libsedml.svn.sourceforge.net/viewvc/libsedml/trunk/Samples/m
>> odels/oscli.xml"
>> />
>> </listOfModels>
>>
>> <listOfSimulations>
>>     <steadyState id="steady1">
>>       <algorithm kisaoID="KISAO:0000407" />
>>     </steadyState>
>> </listOfSimulations>
>>
>> <listOfTasks>
>>     <repeatedTask id="task1" master="true" modelReference="model1"
>> simulationReference="steady1" resetModel="true">
>>
>>       <ranges>
>>         <uniformRange id="current" start="0" end="10" numberOfPoints="100"
>> sampling="linear"/>
>>       </ranges>
>>
>>       <changes>
>>         <setValue
>> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
>> 0_v0']">
>>           <listOfVariables>
>>             <variable id="val" name="current loop value"
>> target="//*[@id='current']" />
>>             <!-- I think this way of choosing the value in the range is
>> fragile.
>>                  I would rather create an attribute rangeid, that would
> only
>> take
>>                  local values, i.e. ranges defined within this task -->
>>           </listOfVariables>
>>           <math xmlns="http://www.w3.org/1998/Math/MathML">
>>             <ci>  val</ci>
>>           </math>
>>         </setValue>
>>     </changes>
>>
>>     </repeatedTask>
>> </listOfTasks>
>>
>> Perturbing a simulation
>> =======================
>>
>> <listOfModels>
>>     <model id="model1" language="urn:sedml:language:sbml"
>>
>>
> source="http://libsedml.svn.sourceforge.net/viewvc/libsedml/trunk/Samples/m
>> odels/oscli.xml"
>> />
>> </listOfModels>
>>
>> <listOfSimulations>
>>       <uniformTimeCourse id="timecourse1" initialTime="0"
>> outputStartTime="0" outputEndTime="4" numberOfPoints="40">
>>         <algorithm kisaoID="KISAO:0000019" />
>>       </uniformTimeCourse>
>>        <uniformTimeCourse id="timecourse2" initialTime="4"
>> outputStartTime="4" outputEndTime="6" numberOfPoints="20">
>>         <algorithm kisaoID="KISAO:0000019" />
>>       </uniformTimeCourse>
>>        <uniformTimeCourse id="timecourse3" initialTime="6"
>> outputStartTime="6" outputEndTime="10" numberOfPoints="40">
>>         <algorithm kisaoID="KISAO:0000019" />
>>       </uniformTimeCourse>
>> </listOfSimulations>
>>
>> <listOfTasks>
>>     <singleTask id="task1" master="true" modelReference="model1"
>> simulationReference="timecourse1" resetModel="false">
>>       <changes>
>>         <setValue
>> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
>> 0_v0']">
>>           <math xmlns="http://www.w3.org/1998/Math/MathML">
>>             <cn>  8</cn>
>>           </math>
>>          </setValue>
>>        </changes>
>>     </singleTask>
>>     <singleTask id="task2" master="true" modelReference="model1"
>> simulationReference="timecourse2" resetModel="false">
>>       <changes>
>>         <setValue
>> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
>> 0_v0']">
>>           <math xmlns="http://www.w3.org/1998/Math/MathML">
>>             <cn>  0.1</cn>
>>           </math>
>>          </setValue>
>>        </changes>
>>     </singleTask>
>>     <singleTask id="task3" master="true" modelReference="model1"
>> simulationReference="timecourse3" resetModel="false">
>>       <changes>
>>         <setValue
>> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
>> 0_v0']">
>>           <math xmlns="http://www.w3.org/1998/Math/MathML">
>>             <cn>  8</cn>
>>           </math>
>>          </setValue>
>>        </changes>
>>     </simpleTask>
>> </listOfTasks>
>>
>> Perturbing a simulation, alternative
>> ====================================
>>
>> <listOfModels>
>>     <model id="model1" language="urn:sedml:language:sbml"
>>
>>
> source="http://libsedml.svn.sourceforge.net/viewvc/libsedml/trunk/Samples/m
>> odels/oscli.xml"
>> />
>> </listOfModels>
>>
>> <listOfSimulations>
>>       <!-- initialTime should become optional or be defined in the task.
>> That way, we do not have to define
>>            10 simulations for 10 bursts of identical duration. outputStart
>> and End time must then be relative
>>            to the initialTime -->
>>       <uniformTimeCourse id="timecourse1" initialTime="0"
>> outputStartTime="0" outputEndTime="4" numberOfPoints="40">
>>         <algorithm kisaoID="KISAO:0000019" />
>>       </uniformTimeCourse>
>>        <uniformTimeCourse id="timecourse2" initialTime="4"
>> outputStartTime="4" outputEndTime="6" numberOfPoints="20">
>>         <algorithm kisaoID="KISAO:0000019" />
>>       </uniformTimeCourse>
>>        <uniformTimeCourse id="timecourse3" initialTime="6"
>> outputStartTime="6" outputEndTime="10" numberOfPoints="40">
>>         <algorithm kisaoID="KISAO:0000019" />
>>       </uniformTimeCourse>
>> </listOfSimulations>
>>
>> <listOfTasks>
>>     </singleTask>
>>     <singleTask id="task1" master="false" modelReference="model1"
>> simulationReference="timecourse1" resetModel="false">
>>       <changes>
>>         <setValue
>> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
>> 0_v0']">
>>           <math xmlns="http://www.w3.org/1998/Math/MathML">
>>             <cn>  8</cn>
>>           </math>
>>          </setValue>
>>        </changes>
>>     </singleTask>
>>     <simpleTask id="task2" master="false" modelReference="model1"
>> simulationReference="timecourse2" resetModel="false">
>>       <changes>
>>         <setValue
>> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
>> 0_v0']">
>>           <math xmlns="http://www.w3.org/1998/Math/MathML">
>>             <cn>  0.1</cn>
>>           </math>
>>          </setValue>
>>        </changes>
>>     </singleTask>
>>     <singleTask id="task3" master="false" modelReference="model1"
>> simulationReference="timecourse3" resetModel="false">
>>       <changes>
>>         <setValue
>> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
>> 0_v0']">
>>           <math xmlns="http://www.w3.org/1998/Math/MathML">
>>             <cn>  8</cn>
>>           </math>
>>          </setValue>
>>        </changes>
>>     </singleTask>
>>     <singleTask id="task4" master="true" modelReference="model1"
>> simulationReference="timecourse1" resetModel="false">
>>       <listOfSubTasks>
>>         <subTask order="1" task="task1" />
>>         <subTask order="2" task="task2" />
>>         <subTask order="3" task="task3" />
>>      </listOfSubTasks>
>>     </singleTask>
>> </listOfTasks>
>>
>> Repeated stochastic simulations
>> ===============================
>>
>>     <listOfModels>
>>       <model id="model1" language="urn:sedml:language:sbml"
>>       source="c:\users\fbergmann\documents\sbmlmodels\BorisEjb.xml" />
>>     </listOfModels>
>>
>>     <listOfSimulations>
>>       <uniformTimeCourse id="timecourse1" initialTime="0"
>> outputStartTime="0" outputEndTime="4000" numberOfPoints="1000">
>>         <algorithm kisaoID="KISAO:0000241" />
>>       </uniformTimeCourse>
>>    </listOfSimulations>
>>
>>     <listOfTasks>
>>       <repeatedTask id="task1" master="true" modelReference="model1"
>> simulationReference="timecourse" resetModel="true">
>>         <ranges>
>>           <uniformRange id="current" start="0" end="10" numberOfPoints="10"
>>    sampling="linear"/>
>>         </ranges>
>>       </repeatedTask>
>>     </listOfTasks>
>>
>> Steady state scan
>> =================
>> <listOfModels>
>>     <model id="model1" language="urn:sedml:language:sbml"
>>            source="c:\users\fbergmann\documents\sbmlmodels\boris.xml" />
>> </listOfModels>
>>
>> <listOfSimulations>
>>     <steadyState id="steady">
>>       <algorithm kisaoID="KISAO:0000407" />
>>     </steadyState>
>> </listOfSimulations>
>>
>> <listOfTasks>
>>     <repeatedTask id="task1" master="true" modelReference="model1"
>> simulationReference="steady" resetModel="false">
>>       <ranges>
>>         <vectorRange id="current">
>>           <value>1</value>
>>           <value>5</value>
>>           <value>10</value>
>>           <value>50</value>
>>           <value>60</value>
>>           <value>70</value>
>>           <value>80</value>
>>           <value>90</value>
>>           <value>100</value>
>>         </vectorRange>
>>       </ranges>
>>       <changes>
>>         <setValue
>> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
>> 1_KK2']">
>>           <listOfVariables>
>>             <variable id="val" name="current loop value"
>> target="//*[@id='current']" />
>>           </listOfVariables>
>>           <math xmlns="http://www.w3.org/1998/Math/MathML">
>>             <ci>  val</ci>
>>           </math>
>>         </setValue>
>>       </changes>
>>
>>       <listOfSubTasks>
>>         <subTask order="1" task="task2" />
>>       </listOfSubTasks>
>>     </repeatedTask>
>>
>>      <repeatedTask id="task2" master="true" modelReference="model1"
>> simulationReference="steady" resetModel="false">
>>       <ranges>
>>          <uniformRange id="current1" start="1" end="40"
> numberOfPoints="100"
>>    sampling="linear"/>
>>       </ranges>
>>       <changes>
>>         <setValue
>> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
>> 4_KK5']"
>>                   range="current1">
>>            <math xmlns="http://www.w3.org/1998/Math/MathML">
>>             <ci>  current1</ci>
>>           </math>
>>         </setValue>
>>       </changes>
>>     </repeatedTask>
>> </listOfTasks>
>>
>>
>>
>> On 07/02/12 11:43, Jonathan Cooper wrote:
>>> Hi Frank&   everyone,
>>>
>>> I'm afraid I've not properly read the most recent emails on this thread
>>> yet, as I've been away on holiday. However I made some notes on the
>>> proposal on my journey out which hopefully will be useful, so I'm
>>> sending them now, and will go through the discussion later this week
>>> hopefully.
>>>
>>> On the topic of nesting tasks (rather than simulations) - I think this
>>> does make more sense, as the nesting references a task, and this
>>> shouldn't be done from a simulation. Also you need to change model
>>> variables when looping, so need the model reference that a task gives
>>> you. It'd be nice to have some more flesh on the ideas in  Nicolas'
>>> second email on this sub-topic.
>>>
>>> This approach has the potential advantage that a nested task wouldn't
>>> have/need an algorithm element. However, tasks have a modelReference
>>> which also seems redundant. What would happen if the reference task
>>> referenced a different model? Could the modelReference be disallowed for
>>> this subclass? (The hierarchy would need tweaking a little to do this.)
>>>
>>>
>>> I have a few other queries/suggestions on the proposal.
>>>
>>> 1) I think it should be possible to use the nested features to specify a
>>> timecourse simulations. This isn't obvious or neat at present, which
>>> suggests that improvement should be possible.
>>>
>>> For instance, oneStep currently specifies the step value, but this would
>>> more naturally live in a range on the nested task (and would avoid
>>> having to make it optional to account for steady-state). So perhaps a
>>> better approach is to move towards parameterised simulation entities, so
>>> that (analogous to setting a model variable) you can set a parameter on
>>> a simulation object? This could link quite nicely with the
>>> algorithmParameter proposal for specifying simulation parameters. Then
>>> you could, for instance, set the "end time" for a oneStep of an ODE
> solver.
>>>
>>> For specifying the target of such a set, I don't really like the idea of
>>> XPath into the SED-ML document - it just looks ugly to me. Since we
>>> already have globally unique IDs within SED-ML, using those seems
> tidier.
>>>
>>> 2) It's not clear in the current proposal whether changes are applied at
>>> the start or end of each iteration; I assume (and suggest) start. It
>>> would also be nice to be able to apply a change at the start/end of a
>>> whole nested simulation/task.
>>>
>>> 3) Passing in range values. The various suggestions in the proposal all
>>> seem a little clunky.  Since ranges have globally unique IDs, could we
>>> make all ranges in the simulation/task implicitly accessible using this
>>> ID as a variable name? Since the ID space is shared across all object
>>> types, it can't conflict with a variable or parameter. The same feature
>>> could be used to avoid needing an index attribute in a functionalRange,
>>> and would make it easier to combine multiple ranges in other ways (a
>>> functionalRange could sum 2 ranges, for instance, or different variables
>>> could be set based on different ranges).
>>>
>>> Best wishes,
>>> Jonathan
>>>
>>> On 19/01/2012 07:17, Frank T. Bergmann wrote:
>>>> Hello,
>>>>
>>>> As many of you know early in 2010 I proposed a simple nested simulation
>>>> experiment for SED-ML. Of course that was well before the SED-ML spec
> was
>>>> released. Since then I listened to your feedback and made adjustments.
> With
>>>> the start of the new year it is time to get the Nested Simulation
> Proposal
>>>> for SED-ML ready for wide-spread adoption. I believe nested simulations
> are
>>>> vital for SED-ML so that we can cover a much larger variety of
> simulation
>>>> experiments.
>>>>
>>>> I've taken these past weeks to fully flesh out all the details and the
>>>> document is now available from Nature Proceedings:
>>>>
>>>> http://precedings.nature.com/documents/4257/version/2
>>>>
>>>> Unlike the last version this time there is a full description of each
>>>> element along with examples. If you only have a couple of seconds, have
> a
>>>> look at my blog where you see the examples:
>>>>
>>>> http://frank-fbergmann.blogspot.com/2012/01/sed-ml-nested-simulation-
>> proposa
>>>> l-v2.html
>>>>
>>>> Or try the SED-ML Web Tools, that I updated to be able to simulate the
>>>> nested experiment:
>>>>
>>>> http://sysbioapps.dyndns.org/SED-ML_Web_Tools/
>>>>
>>>> I look forward to your feedback!
>>>>
>>>>
>>>> Best
>>>> Frank
>>>>
>>>>
>>>>
> ----------------------------------------------------------------------------
> --
>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>> The most comprehensive online learning library for Microsoft developers
>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
> MVC3,
>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>> http://p.sf.net/sfu/learndevnow-d2d
>>>> _______________________________________________
>>>> SED-ML-discuss mailing list
>>>> SED...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>>
>>>
> ----------------------------------------------------------------------------
> --
>>> Keep Your Developer Skills Current with LearnDevNow!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-d2d
>>> _______________________________________________
>>> SED-ML-discuss mailing list
>>> SED...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>>
>> --
>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>> le...@eb..., Skype:n.lenovere, twitter:@lenovere
>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>
>
>


-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
le...@eb..., Skype:n.lenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [SED-ML-discuss] Nested Proposal v2

[Nicolas Le N. <le...@eb...>]

On 12/05/12 17:09, Frank T. Bergmann wrote:

>>       ** The references to the current value of the range are a bit
> heterogeneous
>> according to the type of range. Some homogeneisation would be good for
>> clarity.
>
> I only demonstrated both possible uses in my proposal. As far as
> implementation is concerned, both methods (via attribute and via XPATH) are
> implemented on all Range classes. IMO using the attribute is far superior.
> (If we allow the attribute value to be addressed in the expressions).

I fully agree.

>>       ** I kept all the attributes as they were so far. We may have to
> re-organise
>> things a bit.
>>
>
> I am still unsure about the master attribute. As far as I'm concerned it is
> not really needed. A task is "master=true" as long as it is not referred to
> from a listOfSubTasks. Also the reset attribute might need to be revisited.

You are right. It all depends the way we parse the XML and generate the 
objects. If a task knows its children, it is useful to quickly identify the 
master. If tasks know their parents, a simple test is sufficient. I guess 
the API developers (i.e. you :-) ) need to choose. I don't care super much.

>> * I kept the uniformTimecourse and reintroduced steadyState. To get rid of
>> them completely, we should suppress the simulation class and refer to a
> KiSAO
>> term directly in the task. But then, there is the issue of Richard's
> proposal, and
>> possible extra information we'll store. Honestly, I can't see the
> advantage of
>> getting rid of them. BUT, we need to rework on the parameters. Attributes
> like
>> "initialTime" belong to the task, not the simulation. That would solve the
>> parametrisation mentioned by Jonathan.
>>
>
> As far as I'm concerned the parameterization of the simulation class (i.e.:
> starttime, endTime, numPoints) is correctly placed at the simulation class.

But as they are, the numbers are absolute. So you cannot re-use a 
simulation at different points in time. The first thing is to move 
outputStartTime, and outputEndTime as relative to initialTime. But then, 
have initialTime as a parameter, would allow to run the same perturbation 
10 times in a row without multiplicating the simulations.

> If we move the simulation parameters to the task, there is no reason to have
> simulation classes anymore. But removing them goes too far as it breaks
> compatibility (Remember the initial proposal was to only "add" two
> simulation classes).

I agree. Actually, the more I think about it, the more I believe in Level 
2, Models and Simulations could be part of Tasks. But it depends to the 
answer to the following question: Do-we want SED-ML to describe workflows 
of only "simple simulations". IMHO, with the parameter scans, we are 
already entering the realms of workflows ...

Anyway, for the current topic, I agree.

> Instead lets still have the oneStep class, it is well defined and makes all
> perturbation tasks way easier to implement. It also allows us to sidestep
> the issue of the attribute placements.

I still do not understand the oneStep class, but I am sure you will explain 
it to me in Maastricht and every thing will become crystal clear. 
Meanwhile, I have no problem having it as a simulation class :-)


-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
le...@eb..., Skype:n.lenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

[SED-ML-discuss] HARMONY 2012 communication

[Nicolas Le N. <le...@eb...>]

Dear COMBINE community,

HARMONY 2012 starts in a few days. The main point of information is the 
webpage:
http://co.mbine.org/events/HARMONY_2012

A Google+ page is also available.
https://plus.google.com/118242948876683323405

The official twitter hashtag is #harmony2012
https://twitter.com/#!/search/%23harmony2012

The program is being designed and will evolve through a Google doc. More later.

As usual the presentations, video recording, and any material available 
will be made up available through the webpage.

I am looking forward to this second HARMONY

-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
le...@eb..., Skype:n.lenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

[SED-ML-discuss] Frank's proposals on co.mbine.org

[Nicolas Le N. <le...@eb...>]

Hello,

Frank's proposal is a good opportunity to show how the COMBINE 
specification infrastructure can be used to reference any of our working 
documents.

I created the pages and the links. See:

http://co.mbine.org/standards/sed-ml/proposal/nested-simulations/FB/version-1
http://co.mbine.org/standards/sed-ml/proposal/nested-simulations/FB/version-2

Those documents can now be accessed from the site in addition to Nat 
Precedings. And they have identifiers and can be quoted like any other 
COMBINE document.

-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
le...@eb..., Skype:n.lenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

Re: [SED-ML-discuss] Nested Proposal v2

[Frank T. B. <fbe...@ca...>]

Just to answer your questions: 

> * We reuse Frank's ranges and changes.
> I discovered a few issues that deserve separate discussions:
>      ** We should be coherent in the naming (listOf or not listOf).

Definitely ... 

>      ** The changes in "task" should be completely coherent with the
changes in
> "model". To be honest, model changes at initial time are just a specific
type of
> task changes. Should-we refactor that part of the spec a bit so we have
all the
> model changes in one place?

I think that is not that easily done. After all the referencing mechanism is
slightly different. 

>      ** The references to the current value of the range are a bit
heterogeneous
> according to the type of range. Some homogeneisation would be good for
> clarity.

I only demonstrated both possible uses in my proposal. As far as
implementation is concerned, both methods (via attribute and via XPATH) are
implemented on all Range classes. IMO using the attribute is far superior.
(If we allow the attribute value to be addressed in the expressions). 

>      ** I kept all the attributes as they were so far. We may have to
re-organise
> things a bit.
> 

I am still unsure about the master attribute. As far as I'm concerned it is
not really needed. A task is "master=true" as long as it is not referred to
from a listOfSubTasks. Also the reset attribute might need to be revisited. 

> * I kept the uniformTimecourse and reintroduced steadyState. To get rid of
> them completely, we should suppress the simulation class and refer to a
KiSAO
> term directly in the task. But then, there is the issue of Richard's
proposal, and
> possible extra information we'll store. Honestly, I can't see the
advantage of
> getting rid of them. BUT, we need to rework on the parameters. Attributes
like
> "initialTime" belong to the task, not the simulation. That would solve the
> parametrisation mentioned by Jonathan.
> 

As far as I'm concerned the parameterization of the simulation class (i.e.:
starttime, endTime, numPoints) is correctly placed at the simulation class. 

If we move the simulation parameters to the task, there is no reason to have
simulation classes anymore. But removing them goes too far as it breaks
compatibility (Remember the initial proposal was to only "add" two
simulation classes). 

Instead lets still have the oneStep class, it is well defined and makes all
perturbation tasks way easier to implement. It also allows us to sidestep
the issue of the attribute placements. 

Cheers
Frank

Re: [SED-ML-discuss] Nested Proposal v2

[Frank T. B. <fbe...@ca...>]

Hello Nicolas, 

Thank you for clarification of your concepts of nested tasks. I'll have a
detailed look at it and try to implement it. My main concern are still: 

- that there is no concept of continuing with a simulation between the
repeated executions of the uniformTimeCourse elements. I don't think it is
merely an issue of the initialTime. When using the oneStep element, it would
yield precisely one row of data to be used (performing however many internal
steps as need be). Between each steps the model state would remain the same
(unless the reset attribute was specified). When we are combining now the
elements of several uniformTimecourses it is not the same as using a oneStep
(you couldn't even use the computeChange anymore to use a programmatic
change of the values to be set later on). 


A couple of things I'm not clear about they are: 

- the sampling attribute you added to the uniformRange (you wrote several
times sampling="linear")
- I think the one simpleTask was just a typo ... 
- In your example only the RepeatedTasks used ranges is that correct? Or do
both use them? 
- how do repeats and list of subtasks work together? Is it "for each value
of the range go through all subtasks" or is it "for each subtask go through
each value of the range" ? 
- What if there are multiple ranges defined? (I had an attribute defined on
the nestedSimulation that took the id of a range contruct. Could we have
something like that?)
- resetModel attribute on singleTask elements (when there is no
listOfSubModels, how would they apply)

To the examples: 

- example 1 & 2 & 5: can be implemented easily

- example 3: not enough information
- Perturbing a simulation: From the description it would seem that we could
re-implement the same with SED-ML L1V1 currently using multiple timecourse
simulation and changedModel constructs. I don't see how the singleTask
helps.
- Perturbing a simulation: as output refers to output from one simulation
task, it would be better to rewrite the example using a ListOfSubTasks, but
then of course the simulationReference on the master task would not mean
anything

- example 4:  addresses the problem in 3, however constructing the example
like this will be difficult for tool writers. Instead of describing the
perturbation they want to perform they would need to subdivide the
simulations / tasks and everything in a non-trivial way.
- unfortunately the result from combining the 3 uniformtime course
simulations is not quite the same in my implementation with oneSteps (by
reintroducing that simulation class it would be trivial to encode these
examples!)

- example 6: the master flag on task2 should be false right? Apart from that
I'm still not quite sure how ranges and subtasks work together ...


As far as impact on the SED-ML elements and ease of implementation is
concerned I still prefer my proposal :)  

Cheers
Frank



> -----Original Message-----
> From: Nicolas Le Novère [mailto:le...@eb...]
> Sent: Friday, May 11, 2012 6:08 PM
> To: sed...@li...
> Subject: Re: [SED-ML-discuss] Nested Proposal v2
> 
> Hello all,
> 
> I finally blocked some time to come up with a modification of Frank's
proposal
> that uses nested tasks instead of simulations. In addition, I believed
Frank tried
> to kill two birds with one stone, i.e. multiple identical (but for a
value)
> simulations, and compounded simulations. In order to be both flexible and
> expressive, I believe we should disentangle the problem. Here is what I
propose:
> 
> * Tasks are subclassed in singleTasks and repeatedTasks. The formers are
Frank's
> "oneSteps", and call a simulation once. The latter are for multiple runs
and scans
> and call a simulation multiple times.
> 
> * Tasks (both single and repeated) can contain ordered subclasses, that
refer to
> other tasks. All the subtasks have to be executed once for a single task,
and each
> time for a repeated task. There is one task declared as "master".
> 
> * We reuse Frank's ranges and changes.
> I discovered a few issues that deserve separate discussions:
>      ** We should be coherent in the naming (listOf or not listOf).
>      ** The changes in "task" should be completely coherent with the
changes in
> "model". To be honest, model changes at initial time are just a specific
type of
> task changes. Should-we refactor that part of the spec a bit so we have
all the
> model changes in one place?
>      ** The references to the current value of the range are a bit
heterogeneous
> according to the type of range. Some homogeneisation would be good for
> clarity.
>      ** I kept all the attributes as they were so far. We may have to
re-organise
> things a bit.
> 
> * I kept the uniformTimecourse and reintroduced steadyState. To get rid of
> them completely, we should suppress the simulation class and refer to a
KiSAO
> term directly in the task. But then, there is the issue of Richard's
proposal, and
> possible extra information we'll store. Honestly, I can't see the
advantage of
> getting rid of them. BUT, we need to rework on the parameters. Attributes
like
> "initialTime" belong to the task, not the simulation. That would solve the
> parametrisation mentioned by Jonathan.
> 
> The result is quite neat I think, and more readable for me (but that is
just me).
> Below, I encoded all the examples in Frank's document. I only included the
> models, simulations and tasks. We can work on the output later. I also
attach a
> text file with better formatting.
> 
> 1D kinetics parameter scan with repeatedTask
> ============================================
> 
>    <listOfModels>
>      <model id="model1" language="urn:sedml:language:sbml"
> 
>
source="http://libsedml.svn.sourceforge.net/viewvc/libsedml/trunk/Samples/m
> odels/oscli.xml"
> />
>    </listOfModels>
> 
>    <listOfSimulations>
>      <uniformTimeCourse id="timecourse1" initialTime="0"
> outputStartTime="0" outputEndTime="20" numberOfPoints="1000">
>        <algorithm kisaoID="KISAO:0000019" />
>      </uniformTimeCourse>
>   </listOfSimulations>
> 
>    <listOfTasks>
>      <repeatedTask id="task1" master="true" modelReference="model1"
> simulationReference="timecourse" resetModel="true">
>        <ranges>
>          <vectorRange id="current">
>            <value>8</value>
>            <value>4</value>
>            <value>0.4</value>
>          </vectorRange>
>        </ranges>
>        <changes>
>          <setValue
> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
> 0_v0']"
>                    range="current">
>            <math xmlns="http://www.w3.org/1998/Math/MathML">
>              <ci> current </ci>
>            </math>
>          </setValue>
>        </changes>
>      </repeatedTask>
>    </listOfTasks>
> 
> 
> 1D steady state parameter scan with repeatedTask
> ================================================
> 
> <listOfModels>
>    <model id="model1" language="urn:sedml:language:sbml"
> 
>
source="http://libsedml.svn.sourceforge.net/viewvc/libsedml/trunk/Samples/m
> odels/oscli.xml"
> />
> </listOfModels>
> 
> <listOfSimulations>
>    <steadyState id="steady1">
>      <algorithm kisaoID="KISAO:0000407" />
>    </steadyState>
> </listOfSimulations>
> 
> <listOfTasks>
>    <repeatedTask id="task1" master="true" modelReference="model1"
> simulationReference="steady1" resetModel="true">
> 
>      <ranges>
>        <uniformRange id="current" start="0" end="10" numberOfPoints="100"
> sampling="linear"/>
>      </ranges>
> 
>      <changes>
>        <setValue
> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
> 0_v0']">
>          <listOfVariables>
>            <variable id="val" name="current loop value"
> target="//*[@id='current']" />
>            <!-- I think this way of choosing the value in the range is
> fragile.
>                 I would rather create an attribute rangeid, that would
only
> take
>                 local values, i.e. ranges defined within this task -->
>          </listOfVariables>
>          <math xmlns="http://www.w3.org/1998/Math/MathML">
>            <ci> val </ci>
>          </math>
>        </setValue>
>    </changes>
> 
>    </repeatedTask>
> </listOfTasks>
> 
> Perturbing a simulation
> =======================
> 
> <listOfModels>
>    <model id="model1" language="urn:sedml:language:sbml"
> 
>
source="http://libsedml.svn.sourceforge.net/viewvc/libsedml/trunk/Samples/m
> odels/oscli.xml"
> />
> </listOfModels>
> 
> <listOfSimulations>
>      <uniformTimeCourse id="timecourse1" initialTime="0"
> outputStartTime="0" outputEndTime="4" numberOfPoints="40">
>        <algorithm kisaoID="KISAO:0000019" />
>      </uniformTimeCourse>
>       <uniformTimeCourse id="timecourse2" initialTime="4"
> outputStartTime="4" outputEndTime="6" numberOfPoints="20">
>        <algorithm kisaoID="KISAO:0000019" />
>      </uniformTimeCourse>
>       <uniformTimeCourse id="timecourse3" initialTime="6"
> outputStartTime="6" outputEndTime="10" numberOfPoints="40">
>        <algorithm kisaoID="KISAO:0000019" />
>      </uniformTimeCourse>
> </listOfSimulations>
> 
> <listOfTasks>
>    <singleTask id="task1" master="true" modelReference="model1"
> simulationReference="timecourse1" resetModel="false">
>      <changes>
>        <setValue
> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
> 0_v0']">
>          <math xmlns="http://www.w3.org/1998/Math/MathML">
>            <cn> 8 </cn>
>          </math>
>         </setValue>
>       </changes>
>    </singleTask>
>    <singleTask id="task2" master="true" modelReference="model1"
> simulationReference="timecourse2" resetModel="false">
>      <changes>
>        <setValue
> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
> 0_v0']">
>          <math xmlns="http://www.w3.org/1998/Math/MathML">
>            <cn> 0.1 </cn>
>          </math>
>         </setValue>
>       </changes>
>    </singleTask>
>    <singleTask id="task3" master="true" modelReference="model1"
> simulationReference="timecourse3" resetModel="false">
>      <changes>
>        <setValue
> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
> 0_v0']">
>          <math xmlns="http://www.w3.org/1998/Math/MathML">
>            <cn> 8 </cn>
>          </math>
>         </setValue>
>       </changes>
>    </simpleTask>
> </listOfTasks>
> 
> Perturbing a simulation, alternative
> ====================================
> 
> <listOfModels>
>    <model id="model1" language="urn:sedml:language:sbml"
> 
>
source="http://libsedml.svn.sourceforge.net/viewvc/libsedml/trunk/Samples/m
> odels/oscli.xml"
> />
> </listOfModels>
> 
> <listOfSimulations>
>      <!-- initialTime should become optional or be defined in the task.
> That way, we do not have to define
>           10 simulations for 10 bursts of identical duration. outputStart
> and End time must then be relative
>           to the initialTime -->
>      <uniformTimeCourse id="timecourse1" initialTime="0"
> outputStartTime="0" outputEndTime="4" numberOfPoints="40">
>        <algorithm kisaoID="KISAO:0000019" />
>      </uniformTimeCourse>
>       <uniformTimeCourse id="timecourse2" initialTime="4"
> outputStartTime="4" outputEndTime="6" numberOfPoints="20">
>        <algorithm kisaoID="KISAO:0000019" />
>      </uniformTimeCourse>
>       <uniformTimeCourse id="timecourse3" initialTime="6"
> outputStartTime="6" outputEndTime="10" numberOfPoints="40">
>        <algorithm kisaoID="KISAO:0000019" />
>      </uniformTimeCourse>
> </listOfSimulations>
> 
> <listOfTasks>
>    </singleTask>
>    <singleTask id="task1" master="false" modelReference="model1"
> simulationReference="timecourse1" resetModel="false">
>      <changes>
>        <setValue
> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
> 0_v0']">
>          <math xmlns="http://www.w3.org/1998/Math/MathML">
>            <cn> 8 </cn>
>          </math>
>         </setValue>
>       </changes>
>    </singleTask>
>    <simpleTask id="task2" master="false" modelReference="model1"
> simulationReference="timecourse2" resetModel="false">
>      <changes>
>        <setValue
> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
> 0_v0']">
>          <math xmlns="http://www.w3.org/1998/Math/MathML">
>            <cn> 0.1 </cn>
>          </math>
>         </setValue>
>       </changes>
>    </singleTask>
>    <singleTask id="task3" master="false" modelReference="model1"
> simulationReference="timecourse3" resetModel="false">
>      <changes>
>        <setValue
> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
> 0_v0']">
>          <math xmlns="http://www.w3.org/1998/Math/MathML">
>            <cn> 8 </cn>
>          </math>
>         </setValue>
>       </changes>
>    </singleTask>
>    <singleTask id="task4" master="true" modelReference="model1"
> simulationReference="timecourse1" resetModel="false">
>      <listOfSubTasks>
>        <subTask order="1" task="task1" />
>        <subTask order="2" task="task2" />
>        <subTask order="3" task="task3" />
>     </listOfSubTasks>
>    </singleTask>
> </listOfTasks>
> 
> Repeated stochastic simulations
> ===============================
> 
>    <listOfModels>
>      <model id="model1" language="urn:sedml:language:sbml"
>      source="c:\users\fbergmann\documents\sbmlmodels\BorisEjb.xml" />
>    </listOfModels>
> 
>    <listOfSimulations>
>      <uniformTimeCourse id="timecourse1" initialTime="0"
> outputStartTime="0" outputEndTime="4000" numberOfPoints="1000">
>        <algorithm kisaoID="KISAO:0000241" />
>      </uniformTimeCourse>
>   </listOfSimulations>
> 
>    <listOfTasks>
>      <repeatedTask id="task1" master="true" modelReference="model1"
> simulationReference="timecourse" resetModel="true">
>        <ranges>
>          <uniformRange id="current" start="0" end="10" numberOfPoints="10"
>   sampling="linear"/>
>        </ranges>
>      </repeatedTask>
>    </listOfTasks>
> 
> Steady state scan
> =================
> <listOfModels>
>    <model id="model1" language="urn:sedml:language:sbml"
>           source="c:\users\fbergmann\documents\sbmlmodels\boris.xml" />
> </listOfModels>
> 
> <listOfSimulations>
>    <steadyState id="steady">
>      <algorithm kisaoID="KISAO:0000407" />
>    </steadyState>
> </listOfSimulations>
> 
> <listOfTasks>
>    <repeatedTask id="task1" master="true" modelReference="model1"
> simulationReference="steady" resetModel="false">
>      <ranges>
>        <vectorRange id="current">
>          <value>1</value>
>          <value>5</value>
>          <value>10</value>
>          <value>50</value>
>          <value>60</value>
>          <value>70</value>
>          <value>80</value>
>          <value>90</value>
>          <value>100</value>
>        </vectorRange>
>      </ranges>
>      <changes>
>        <setValue
> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
> 1_KK2']">
>          <listOfVariables>
>            <variable id="val" name="current loop value"
> target="//*[@id='current']" />
>          </listOfVariables>
>          <math xmlns="http://www.w3.org/1998/Math/MathML">
>            <ci> val </ci>
>          </math>
>        </setValue>
>      </changes>
> 
>      <listOfSubTasks>
>        <subTask order="1" task="task2" />
>      </listOfSubTasks>
>    </repeatedTask>
> 
>     <repeatedTask id="task2" master="true" modelReference="model1"
> simulationReference="steady" resetModel="false">
>      <ranges>
>         <uniformRange id="current1" start="1" end="40"
numberOfPoints="100"
>   sampling="linear"/>
>      </ranges>
>      <changes>
>        <setValue
> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J
> 4_KK5']"
>                  range="current1">
>           <math xmlns="http://www.w3.org/1998/Math/MathML">
>            <ci> current1 </ci>
>          </math>
>        </setValue>
>      </changes>
>    </repeatedTask>
> </listOfTasks>
> 
> 
> 
> On 07/02/12 11:43, Jonathan Cooper wrote:
> > Hi Frank&  everyone,
> >
> > I'm afraid I've not properly read the most recent emails on this thread
> > yet, as I've been away on holiday. However I made some notes on the
> > proposal on my journey out which hopefully will be useful, so I'm
> > sending them now, and will go through the discussion later this week
> > hopefully.
> >
> > On the topic of nesting tasks (rather than simulations) - I think this
> > does make more sense, as the nesting references a task, and this
> > shouldn't be done from a simulation. Also you need to change model
> > variables when looping, so need the model reference that a task gives
> > you. It'd be nice to have some more flesh on the ideas in  Nicolas'
> > second email on this sub-topic.
> >
> > This approach has the potential advantage that a nested task wouldn't
> > have/need an algorithm element. However, tasks have a modelReference
> > which also seems redundant. What would happen if the reference task
> > referenced a different model? Could the modelReference be disallowed for
> > this subclass? (The hierarchy would need tweaking a little to do this.)
> >
> >
> > I have a few other queries/suggestions on the proposal.
> >
> > 1) I think it should be possible to use the nested features to specify a
> > timecourse simulations. This isn't obvious or neat at present, which
> > suggests that improvement should be possible.
> >
> > For instance, oneStep currently specifies the step value, but this would
> > more naturally live in a range on the nested task (and would avoid
> > having to make it optional to account for steady-state). So perhaps a
> > better approach is to move towards parameterised simulation entities, so
> > that (analogous to setting a model variable) you can set a parameter on
> > a simulation object? This could link quite nicely with the
> > algorithmParameter proposal for specifying simulation parameters. Then
> > you could, for instance, set the "end time" for a oneStep of an ODE
solver.
> >
> > For specifying the target of such a set, I don't really like the idea of
> > XPath into the SED-ML document - it just looks ugly to me. Since we
> > already have globally unique IDs within SED-ML, using those seems
tidier.
> >
> > 2) It's not clear in the current proposal whether changes are applied at
> > the start or end of each iteration; I assume (and suggest) start. It
> > would also be nice to be able to apply a change at the start/end of a
> > whole nested simulation/task.
> >
> > 3) Passing in range values. The various suggestions in the proposal all
> > seem a little clunky.  Since ranges have globally unique IDs, could we
> > make all ranges in the simulation/task implicitly accessible using this
> > ID as a variable name? Since the ID space is shared across all object
> > types, it can't conflict with a variable or parameter. The same feature
> > could be used to avoid needing an index attribute in a functionalRange,
> > and would make it easier to combine multiple ranges in other ways (a
> > functionalRange could sum 2 ranges, for instance, or different variables
> > could be set based on different ranges).
> >
> > Best wishes,
> > Jonathan
> >
> > On 19/01/2012 07:17, Frank T. Bergmann wrote:
> >> Hello,
> >>
> >> As many of you know early in 2010 I proposed a simple nested simulation
> >> experiment for SED-ML. Of course that was well before the SED-ML spec
was
> >> released. Since then I listened to your feedback and made adjustments.
With
> >> the start of the new year it is time to get the Nested Simulation
Proposal
> >> for SED-ML ready for wide-spread adoption. I believe nested simulations
are
> >> vital for SED-ML so that we can cover a much larger variety of
simulation
> >> experiments.
> >>
> >> I've taken these past weeks to fully flesh out all the details and the
> >> document is now available from Nature Proceedings:
> >>
> >> http://precedings.nature.com/documents/4257/version/2
> >>
> >> Unlike the last version this time there is a full description of each
> >> element along with examples. If you only have a couple of seconds, have
a
> >> look at my blog where you see the examples:
> >>
> >> http://frank-fbergmann.blogspot.com/2012/01/sed-ml-nested-simulation-
> proposa
> >> l-v2.html
> >>
> >> Or try the SED-ML Web Tools, that I updated to be able to simulate the
> >> nested experiment:
> >>
> >> http://sysbioapps.dyndns.org/SED-ML_Web_Tools/
> >>
> >> I look forward to your feedback!
> >>
> >>
> >> Best
> >> Frank
> >>
> >>
> >>
----------------------------------------------------------------------------
--
> >> Keep Your Developer Skills Current with LearnDevNow!
> >> The most comprehensive online learning library for Microsoft developers
> >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
MVC3,
> >> Metro Style Apps, more. Free future releases when you subscribe now!
> >> http://p.sf.net/sfu/learndevnow-d2d
> >> _______________________________________________
> >> SED-ML-discuss mailing list
> >> SED...@li...
> >> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
> >
> >
----------------------------------------------------------------------------
--
> > Keep Your Developer Skills Current with LearnDevNow!
> > The most comprehensive online learning library for Microsoft developers
> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> > Metro Style Apps, more. Free future releases when you subscribe now!
> > http://p.sf.net/sfu/learndevnow-d2d
> > _______________________________________________
> > SED-ML-discuss mailing list
> > SED...@li...
> > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
> 
> 
> --
> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
> le...@eb..., Skype:n.lenovere, twitter:@lenovere
> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
> 

Re: [SED-ML-discuss] Nested Proposal v2

[Nicolas Le N. <le...@eb...>]

Hello all,

I finally blocked some time to come up with a modification of Frank's 
proposal that uses nested tasks instead of simulations. In addition, I 
believed Frank tried to kill two birds with one stone, i.e. multiple 
identical (but for a value) simulations, and compounded simulations. In 
order to be both flexible and expressive, I believe we should disentangle 
the problem. Here is what I propose:

* Tasks are subclassed in singleTasks and repeatedTasks. The formers are 
Frank's "oneSteps", and call a simulation once. The latter are for multiple 
runs and scans and call a simulation multiple times.

* Tasks (both single and repeated) can contain ordered subclasses, that 
refer to other tasks. All the subtasks have to be executed once for a 
single task, and each time for a repeated task. There is one task declared 
as "master".

* We reuse Frank's ranges and changes.
I discovered a few issues that deserve separate discussions:
     ** We should be coherent in the naming (listOf or not listOf).
     ** The changes in "task" should be completely coherent with the 
changes in "model". To be honest, model changes at initial time are just a 
specific type of task changes. Should-we refactor that part of the spec a 
bit so we have all the model changes in one place?
     ** The references to the current value of the range are a bit 
heterogeneous according to the type of range. Some homogeneisation would be 
good for clarity.
     ** I kept all the attributes as they were so far. We may have to 
re-organise things a bit.

* I kept the uniformTimecourse and reintroduced steadyState. To get rid of 
them completely, we should suppress the simulation class and refer to a 
KiSAO term directly in the task. But then, there is the issue of Richard's 
proposal, and possible extra information we'll store. Honestly, I can't see 
the advantage of getting rid of them. BUT, we need to rework on the 
parameters. Attributes like "initialTime" belong to the task, not the 
simulation. That would solve the parametrisation mentioned by Jonathan.

The result is quite neat I think, and more readable for me (but that is 
just me). Below, I encoded all the examples in Frank's document. I only 
included the models, simulations and tasks. We can work on the output 
later. I also attach a text file with better formatting.

1D kinetics parameter scan with repeatedTask
============================================

   <listOfModels>
     <model id="model1" language="urn:sedml:language:sbml"
 
source="http://libsedml.svn.sourceforge.net/viewvc/libsedml/trunk/Samples/models/oscli.xml" 
/>
   </listOfModels>

   <listOfSimulations>
     <uniformTimeCourse id="timecourse1" initialTime="0" 
outputStartTime="0" outputEndTime="20" numberOfPoints="1000">
       <algorithm kisaoID="KISAO:0000019" />
     </uniformTimeCourse>
  </listOfSimulations>

   <listOfTasks>
     <repeatedTask id="task1" master="true" modelReference="model1" 
simulationReference="timecourse" resetModel="true">
       <ranges>
         <vectorRange id="current">
           <value>8</value>
           <value>4</value>
           <value>0.4</value>
         </vectorRange>
       </ranges>
       <changes>
         <setValue 
target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J0_v0']"
                   range="current">
           <math xmlns="http://www.w3.org/1998/Math/MathML">
             <ci> current </ci>
           </math>
         </setValue>
       </changes>
     </repeatedTask>
   </listOfTasks>


1D steady state parameter scan with repeatedTask
================================================

<listOfModels>
   <model id="model1" language="urn:sedml:language:sbml"
 
source="http://libsedml.svn.sourceforge.net/viewvc/libsedml/trunk/Samples/models/oscli.xml" 
/>
</listOfModels>

<listOfSimulations>
   <steadyState id="steady1">
     <algorithm kisaoID="KISAO:0000407" />
   </steadyState>
</listOfSimulations>

<listOfTasks>
   <repeatedTask id="task1" master="true" modelReference="model1" 
simulationReference="steady1" resetModel="true">

     <ranges>
       <uniformRange id="current" start="0" end="10" numberOfPoints="100" 
sampling="linear"/>
     </ranges>

     <changes>
       <setValue 
target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J0_v0']">
         <listOfVariables>
           <variable id="val" name="current loop value" 
target="//*[@id='current']" />
           <!-- I think this way of choosing the value in the range is 
fragile.
                I would rather create an attribute rangeid, that would only 
take
                local values, i.e. ranges defined within this task -->
         </listOfVariables>
         <math xmlns="http://www.w3.org/1998/Math/MathML">
           <ci> val </ci>
         </math>
       </setValue>
   </changes>

   </repeatedTask>
</listOfTasks>

Perturbing a simulation
=======================

<listOfModels>
   <model id="model1" language="urn:sedml:language:sbml"
 
source="http://libsedml.svn.sourceforge.net/viewvc/libsedml/trunk/Samples/models/oscli.xml" 
/>
</listOfModels>

<listOfSimulations>
     <uniformTimeCourse id="timecourse1" initialTime="0" 
outputStartTime="0" outputEndTime="4" numberOfPoints="40">
       <algorithm kisaoID="KISAO:0000019" />
     </uniformTimeCourse>
      <uniformTimeCourse id="timecourse2" initialTime="4" 
outputStartTime="4" outputEndTime="6" numberOfPoints="20">
       <algorithm kisaoID="KISAO:0000019" />
     </uniformTimeCourse>
      <uniformTimeCourse id="timecourse3" initialTime="6" 
outputStartTime="6" outputEndTime="10" numberOfPoints="40">
       <algorithm kisaoID="KISAO:0000019" />
     </uniformTimeCourse>
</listOfSimulations>

<listOfTasks>
   <singleTask id="task1" master="true" modelReference="model1" 
simulationReference="timecourse1" resetModel="false">
     <changes>
       <setValue 
target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J0_v0']">
         <math xmlns="http://www.w3.org/1998/Math/MathML">
           <cn> 8 </cn>
         </math>
        </setValue>
      </changes>
   </singleTask>
   <singleTask id="task2" master="true" modelReference="model1" 
simulationReference="timecourse2" resetModel="false">
     <changes>
       <setValue 
target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J0_v0']">
         <math xmlns="http://www.w3.org/1998/Math/MathML">
           <cn> 0.1 </cn>
         </math>
        </setValue>
      </changes>
   </singleTask>
   <singleTask id="task3" master="true" modelReference="model1" 
simulationReference="timecourse3" resetModel="false">
     <changes>
       <setValue 
target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J0_v0']">
         <math xmlns="http://www.w3.org/1998/Math/MathML">
           <cn> 8 </cn>
         </math>
        </setValue>
      </changes>
   </simpleTask>
</listOfTasks>

Perturbing a simulation, alternative
====================================

<listOfModels>
   <model id="model1" language="urn:sedml:language:sbml"
 
source="http://libsedml.svn.sourceforge.net/viewvc/libsedml/trunk/Samples/models/oscli.xml" 
/>
</listOfModels>

<listOfSimulations>
     <!-- initialTime should become optional or be defined in the task. 
That way, we do not have to define
          10 simulations for 10 bursts of identical duration. outputStart 
and End time must then be relative
          to the initialTime -->
     <uniformTimeCourse id="timecourse1" initialTime="0" 
outputStartTime="0" outputEndTime="4" numberOfPoints="40">
       <algorithm kisaoID="KISAO:0000019" />
     </uniformTimeCourse>
      <uniformTimeCourse id="timecourse2" initialTime="4" 
outputStartTime="4" outputEndTime="6" numberOfPoints="20">
       <algorithm kisaoID="KISAO:0000019" />
     </uniformTimeCourse>
      <uniformTimeCourse id="timecourse3" initialTime="6" 
outputStartTime="6" outputEndTime="10" numberOfPoints="40">
       <algorithm kisaoID="KISAO:0000019" />
     </uniformTimeCourse>
</listOfSimulations>

<listOfTasks>
   </singleTask>
   <singleTask id="task1" master="false" modelReference="model1" 
simulationReference="timecourse1" resetModel="false">
     <changes>
       <setValue 
target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J0_v0']">
         <math xmlns="http://www.w3.org/1998/Math/MathML">
           <cn> 8 </cn>
         </math>
        </setValue>
      </changes>
   </singleTask>
   <simpleTask id="task2" master="false" modelReference="model1" 
simulationReference="timecourse2" resetModel="false">
     <changes>
       <setValue 
target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J0_v0']">
         <math xmlns="http://www.w3.org/1998/Math/MathML">
           <cn> 0.1 </cn>
         </math>
        </setValue>
      </changes>
   </singleTask>
   <singleTask id="task3" master="false" modelReference="model1" 
simulationReference="timecourse3" resetModel="false">
     <changes>
       <setValue 
target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J0_v0']">
         <math xmlns="http://www.w3.org/1998/Math/MathML">
           <cn> 8 </cn>
         </math>
        </setValue>
      </changes>
   </singleTask>
   <singleTask id="task4" master="true" modelReference="model1" 
simulationReference="timecourse1" resetModel="false">
     <listOfSubTasks>
       <subTask order="1" task="task1" />
       <subTask order="2" task="task2" />
       <subTask order="3" task="task3" />
    </listOfSubTasks>
   </singleTask>
</listOfTasks>

Repeated stochastic simulations
===============================

   <listOfModels>
     <model id="model1" language="urn:sedml:language:sbml"
     source="c:\users\fbergmann\documents\sbmlmodels\BorisEjb.xml" />
   </listOfModels>

   <listOfSimulations>
     <uniformTimeCourse id="timecourse1" initialTime="0" 
outputStartTime="0" outputEndTime="4000" numberOfPoints="1000">
       <algorithm kisaoID="KISAO:0000241" />
     </uniformTimeCourse>
  </listOfSimulations>

   <listOfTasks>
     <repeatedTask id="task1" master="true" modelReference="model1" 
simulationReference="timecourse" resetModel="true">
       <ranges>
         <uniformRange id="current" start="0" end="10" numberOfPoints="10" 
  sampling="linear"/>
       </ranges>
     </repeatedTask>
   </listOfTasks>

Steady state scan
=================
<listOfModels>
   <model id="model1" language="urn:sedml:language:sbml"
          source="c:\users\fbergmann\documents\sbmlmodels\boris.xml" />
</listOfModels>

<listOfSimulations>
   <steadyState id="steady">
     <algorithm kisaoID="KISAO:0000407" />
   </steadyState>
</listOfSimulations>

<listOfTasks>
   <repeatedTask id="task1" master="true" modelReference="model1" 
simulationReference="steady" resetModel="false">
     <ranges>
       <vectorRange id="current">
         <value>1</value>
         <value>5</value>
         <value>10</value>
         <value>50</value>
         <value>60</value>
         <value>70</value>
         <value>80</value>
         <value>90</value>
         <value>100</value>
       </vectorRange>
     </ranges>
     <changes>
       <setValue 
target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J1_KK2']">
         <listOfVariables>
           <variable id="val" name="current loop value" 
target="//*[@id='current']" />
         </listOfVariables>
         <math xmlns="http://www.w3.org/1998/Math/MathML">
           <ci> val </ci>
         </math>
       </setValue>
     </changes>

     <listOfSubTasks>
       <subTask order="1" task="task2" />
     </listOfSubTasks>
   </repeatedTask>

    <repeatedTask id="task2" master="true" modelReference="model1" 
simulationReference="steady" resetModel="false">
     <ranges>
        <uniformRange id="current1" start="1" end="40" numberOfPoints="100" 
  sampling="linear"/>
     </ranges>
     <changes>
       <setValue 
target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='J4_KK5']"
                 range="current1">
          <math xmlns="http://www.w3.org/1998/Math/MathML">
           <ci> current1 </ci>
         </math>
       </setValue>
     </changes>
   </repeatedTask>
</listOfTasks>



On 07/02/12 11:43, Jonathan Cooper wrote:
> Hi Frank&  everyone,
>
> I'm afraid I've not properly read the most recent emails on this thread
> yet, as I've been away on holiday. However I made some notes on the
> proposal on my journey out which hopefully will be useful, so I'm
> sending them now, and will go through the discussion later this week
> hopefully.
>
> On the topic of nesting tasks (rather than simulations) - I think this
> does make more sense, as the nesting references a task, and this
> shouldn't be done from a simulation. Also you need to change model
> variables when looping, so need the model reference that a task gives
> you. It'd be nice to have some more flesh on the ideas in  Nicolas'
> second email on this sub-topic.
>
> This approach has the potential advantage that a nested task wouldn't
> have/need an algorithm element. However, tasks have a modelReference
> which also seems redundant. What would happen if the reference task
> referenced a different model? Could the modelReference be disallowed for
> this subclass? (The hierarchy would need tweaking a little to do this.)
>
>
> I have a few other queries/suggestions on the proposal.
>
> 1) I think it should be possible to use the nested features to specify a
> timecourse simulations. This isn't obvious or neat at present, which
> suggests that improvement should be possible.
>
> For instance, oneStep currently specifies the step value, but this would
> more naturally live in a range on the nested task (and would avoid
> having to make it optional to account for steady-state). So perhaps a
> better approach is to move towards parameterised simulation entities, so
> that (analogous to setting a model variable) you can set a parameter on
> a simulation object? This could link quite nicely with the
> algorithmParameter proposal for specifying simulation parameters. Then
> you could, for instance, set the "end time" for a oneStep of an ODE solver.
>
> For specifying the target of such a set, I don't really like the idea of
> XPath into the SED-ML document - it just looks ugly to me. Since we
> already have globally unique IDs within SED-ML, using those seems tidier.
>
> 2) It's not clear in the current proposal whether changes are applied at
> the start or end of each iteration; I assume (and suggest) start. It
> would also be nice to be able to apply a change at the start/end of a
> whole nested simulation/task.
>
> 3) Passing in range values. The various suggestions in the proposal all
> seem a little clunky.  Since ranges have globally unique IDs, could we
> make all ranges in the simulation/task implicitly accessible using this
> ID as a variable name? Since the ID space is shared across all object
> types, it can't conflict with a variable or parameter. The same feature
> could be used to avoid needing an index attribute in a functionalRange,
> and would make it easier to combine multiple ranges in other ways (a
> functionalRange could sum 2 ranges, for instance, or different variables
> could be set based on different ranges).
>
> Best wishes,
> Jonathan
>
> On 19/01/2012 07:17, Frank T. Bergmann wrote:
>> Hello,
>>
>> As many of you know early in 2010 I proposed a simple nested simulation
>> experiment for SED-ML. Of course that was well before the SED-ML spec was
>> released. Since then I listened to your feedback and made adjustments. With
>> the start of the new year it is time to get the Nested Simulation Proposal
>> for SED-ML ready for wide-spread adoption. I believe nested simulations are
>> vital for SED-ML so that we can cover a much larger variety of simulation
>> experiments.
>>
>> I've taken these past weeks to fully flesh out all the details and the
>> document is now available from Nature Proceedings:
>>
>> http://precedings.nature.com/documents/4257/version/2
>>
>> Unlike the last version this time there is a full description of each
>> element along with examples. If you only have a couple of seconds, have a
>> look at my blog where you see the examples:
>>
>> http://frank-fbergmann.blogspot.com/2012/01/sed-ml-nested-simulation-proposa
>> l-v2.html
>>
>> Or try the SED-ML Web Tools, that I updated to be able to simulate the
>> nested experiment:
>>
>> http://sysbioapps.dyndns.org/SED-ML_Web_Tools/
>>
>> I look forward to your feedback!
>>
>>
>> Best
>> Frank
>>
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss


-- 
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
le...@eb..., Skype:n.lenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

[SED-ML-discuss] Fwd: [sbml-discuss] Please register for HARMONY 2012

[David N. <dav...@gm...>]

---------- Forwarded message ----------
From: Michael Hucka <mh...@ca...>
Date: Mon, Apr 16, 2012 at 12:27 PM
Subject: [sbml-discuss] Please register for HARMONY 2012
To: SBML Discussion List <sbm...@ca...>, jsbml developers'
mailing list <jsb...@ca...>


For all who are planning on attending HARMONY 2012, please register
soon.  Please don't wait until the last minute!  The organizers need
to make plans for the number of people who will be attending.

Here is a direct link to the registration page:
http://harmony2012.eventbrite.com/

Here is the event home page:
http://co.mbine.org/events/HARMONY_2012

H A R M O N Y 2012
May 21-25, 2012
Maastricht, The Netherlands

Thanks!
--
Mike Hucka, Ph.D. -- mh...@ca... -- http://www.cds.caltech.edu/~mhucka
Computing and Mathematical Sciences, California Institute of Technology,
Pasadena, California, USA -- Twitter: @mhucka -- Skype: michaelhucka
____________________________________________________________
To manage your sbml-discuss list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss

For a web interface to the sbml-discuss mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the sbml-discuss list,
contact sbm...@ca...

[SED-ML-discuss] [Combine-announce] HARMONY 2012 registration is open

[Nicolas Le N. <le...@eb...>]

***************************************************************************
                                   Announcing

                             H A R M O N Y  2012

                             May 21-25, 2012
                          Maastricht, The Netherlands

                   http://co.mbine.org/events/HARMONY_2012

***************************************************************************

Dear Colleagues,

We are happy to announce that the registration for HARMONY 2012 is open now.

HARMONY is a hackathon-type meeting, with a focus on development of the 
standards, interoperability and infrastructure. There is generally not many 
general discussions or oral presentations during HARMONY; instead, the time 
is devoted to allowing hands-on hacking and interaction between people 
focused on practical development of software and standards. The HARMONY 
2012 meeting will be hosted by the Department of Bioinformatics from 
Maastricht University.

The maximum number of participants is 70. Please register using the 
following form

  http://harmony2012.eventbrite.com.

We are trying to get more funding to support the accommodation costs of the 
participants. We have agreed to special room rates with the Apart Hotel 
Randwyck and the NH hotel. The participants have to book the hotel rooms 
themselves. For further information please have a look at

http://co.mbine.org/events/HARMONY_2012#Accommodation.

The conference dinner will take place on the evening of Wednesday 23rd May 
at Ipanema. On the first meeting day (Monday 21st May) there will be an 
open symposium with tutorials, talks and a reception/poster session in the 
evening.

A full schedule and further information will be provided on the meeting 
website

www.co.mbine.org/events/HARMONY_2012


We are looking forward to welcome you all in Maastricht.
For any further questions, please contact us 
(har...@ma...).

Best Regards,
Martina, Chris, Gary, Nicolas, Mike

_______________________________________________
Combine-announce mailing list
Com...@eb...
http://listserver.ebi.ac.uk/mailman/listinfo/combine-announce

Re: [SED-ML-discuss] Proposal to extend the use of Kisao ontology in SED-ML

[Jonathan C. <jon...@cs...>]

Hi Richard,

It looks good to me!

Best wishes,
Jonathan

On 10/02/2012 10:05, Richard Adams wrote:
> Hello All,
>
> I've created a proposal for an extension of the use of our use of the
> KISAO ontology in simulation descriptions, for the next version
>    of SED-ML.
>    The proposal is available as a pdf attached  to this link:
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=3391892&group_id=293618&atid=2532228
>
>    and also attached to this post.
>
> Look forward to hearing any comments!
>
> Best wishes,
>
> Richard
>
>

Re: [SED-ML-discuss] Nested Proposal v2 - oneStep optional step vs steadyState

[Jonathan C. <jon...@cs...>]

On 09/02/2012 19:01, Frank T. Bergmann wrote:
>> I disagree with the idea of optional attribute. If we need to specify a step of undetermined time, then we should specify it. We could use NaN for instance.
> I've only made that change after I received a request that 'steadyState' as
> simulation class could just as well be represented by a 'oneStep' without
> step and the proper KISAO term. I'd be happy to revert that to using the
> 'steadyState' class instead and then always having a valid step entered. NaN
> seems like a stop gap :)

As the original suggester of the idea to represent steady-state 
simulations with oneStep, I actually agree to some extent with both of 
you. My main concern was to avoid overlapping too much with KiSAO, which 
we already use and can specify a steady-state algorithm. However, 
"oneStep" of an algorithm that doesn't really have steps is incongruous. 
Perhaps instead what is needed is something like a GenericSimulation 
class, which (especially in conjunction with the proposal Richard has 
just emailed) would just run the referenced algorithm to completion? 
This could support at least the steady-state case I think; are there any 
other uses for it?

Together with the ability to specify an 'end time' for algorithms as 
suggested in my earlier email, could this remove the need for oneStep 
entirely?

Best wishes,
Jonathan

[SED-ML-discuss] Proposal to extend the use of Kisao ontology in SED-ML

[Richard A. <ric...@ed...>]

Hello All,

I've created a proposal for an extension of the use of our use of the  
KISAO ontology in simulation descriptions, for the next version
  of SED-ML.
  The proposal is available as a pdf attached  to this link:

https://sourceforge.net/tracker/index.php?func=detail&aid=3391892&group_id=293618&atid=2532228

  and also attached to this post.

Look forward to hearing any comments!

Best wishes,

Richard


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.