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

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

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

> 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 :) 

Cheers
Frank

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

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

On 08/02/12 10:34, Jonathan Cooper wrote:

> On 07/02/2012 23:52, Richard Adams wrote:
>> I agree with Jonathan on this - if a nested simulation can handle a
>> uniform time course, by specifying the range to use 'time' as a
>> target, why not go the whole hog and get rid of UniformTimeCourse? The
>> concept in l1v1 of a task relating a simulation and a model, while
>> elegant,  seems rather obsolete by this proposal.
>
> I don't think I'd get rid of UniformTimeCourse entirely, since it's a
> simulation type that occurs very frequently, and so it's useful to be
> able to specify it directly (and keep backwards compatibility more
> easily). But the spec could describe how it can be implemented in terms
> of a nested simulation, so implementers only really need to care about
> the latter if they want to.

I agree with that. I would even go further: I think we should introduce the 
steady-state primitive as it was originally planned.

Many tools do not allow nested simulations. And the implementation of the 
proposal will be a significant undertaking. I stand by my original 
proposal: Level 1 should go on with its current structure and the original 
plan. We add simulation types as needed. It is not true that this will 
result in an explosion of simulation type. The vast majority of papers out 
there use less than a handful of them. The nested simulation proposal is 
for SED-ML Level 2. In this level, we redefine the primitive of Level 1 in 
terms of nested simulations.

We start to have a few SED-ML Level 1 files out, and there is a flicker of 
support. We should not endanger it, while still moving ahead.

-- 
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...>]

Hi Franck,

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.

On 19/01/12 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


-- 
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...>]

Hi Franck.

In the uniformRange element, I think we should add an attribute to specify 
is the sampling is linear or logarithmic. I tried to think of a way to use 
functionalRange to do so, and I failed (but I may well be clueless, so 
people try as well).

Cheers

On 19/01/12 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


-- 
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

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

Hi Richard,

Two quick points on your very thorough email, responding inline.

On 07/02/2012 23:52, Richard Adams wrote:
> I agree with Jonathan on this - if a nested simulation can handle a
> uniform time course, by specifying the range to use 'time' as a
> target, why not go the whole hog and get rid of UniformTimeCourse? The
> concept in l1v1 of a task relating a simulation and a model, while
> elegant,  seems rather obsolete by this proposal.

I don't think I'd get rid of UniformTimeCourse entirely, since it's a 
simulation type that occurs very frequently, and so it's useful to be 
able to specify it directly (and keep backwards compatibility more 
easily). But the spec could describe how it can be implemented in terms 
of a nested simulation, so implementers only really need to care about 
the latter if they want to.

I do like your example though.

> One other suggestion: in the current nestedSimulations, inner loops
> are not reusable - they are defined with respect to the outer
> simulations. How about
> being able to define  1D parameter scans independently, which could be
> combined together simply, e.g.,
>
> <nestedSimulationTask>
>    <simulationTaskRef refid="paramscan1"/>
>    <simulationTaskRef refid="paramscan2"/>
> </nestedSimulationTask>
>
> indicating a   combination of two tasks to produce a 2D scan?  I.e.,
> each task is defined 'one-dimensionally' but can  be composed into N-
> dimensional simulations by linear combination.

This has the potential to be really nice, but the proposed approach is 
conceptually clunky I think. What it implies is that one of the 
referenced tasks (the first?) has to be modified so that instead of the 
original task specified in it, it uses the other referenced task. A 
cleaner way to do it would be to allow simulation tasks to be 
parameterised by the original task - these would then be more reusable 
components that could either be applied just to a model, or nested together.

Best wishes,
Jonathan

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

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

I agree with Jonathan on this - if a nested simulation can handle a  
uniform time course, by specifying the range to use 'time' as a  
target, why not go the whole hog and get rid of UniformTimeCourse? The  
concept in l1v1 of a task relating a simulation and a model, while  
elegant,  seems rather obsolete by this proposal.
The advantages of being able to define simulations independently of a  
model seem outweighed by the benefits of using Frank's primitive-based  
approach, to my mind.
Since the nestedSimulation can use XPath to identify the model  
variables that will be altered , it is already tied to a model - so  
perhaps it could use a model reference directly, rather than  relating  
to a model via a Task.
How about renaming nestedSimulation to 'simulationTask'. A base  
simulationTask can then refer to a model, or to  another  
simulationTask -  ultimately this will lead to a 'base task' that will  
point to a model element.

Here is an example of what I mean based on Frank's  1D parameter scan  
example:

Note that
a) UniformTimeCourse is replaced by a simulationTask.
b) 'Tasks' are removed altogether.
c) A simulation task can refer to another task ('originalTask') or a  
model.
d) Variables in DataGenerators now refer to simulationTasks rather  
than 'Tasks'.

  In a nested set of simulationTasks, the outermost one should always  
refer to a SED-ML model element.


<?xml version="1.0" encoding="utf-8"?>
<sedML level="1" version="1" xmlns="http://sed-ml.org/">
	<listOfSimulationTasks>
		<simulationTask id="utc" resetModel="false"
			model="model1" range="timestep">
			<algorithm kisaoID="KISAO:0000019" />
			<ranges>
				<uniformRange id="timestep" start="0" end="20"
					numberOfPoints="1000" />
			</ranges>
			<changes>
				<setValue target="urn:sedml:symbol:time" range="timestep">
					<math xmlns="http://www.w3.org/1998/Math/MathML">
						<ci> timeStep </ci>
					</math>
				</setValue>
			</changes>
		</simulationTask>

		<simulationTask id="nested1" resetModel="true"
			originalTask="utc" range="current">
			<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>
		</simulationTask>
	</listOfSimulationTasks>
	<listOfModels>
		<model id="model1" language="urn:sedml:language:sbml"
			source="http://libsedml.svn.sourceforge.net/viewvc/libsedml/trunk/Samples/models/oscli.xml 
" />
	</listOfModels>
	<listOfDataGenerators>
		<dataGenerator id="time1" name="time">
			<listOfVariables>
				<variable id="time" name="time" taskReference="nested1"
					target="time" />
			</listOfVariables>
			<math xmlns="http://www.w3.org/1998/Math/MathML">
				<ci> time </ci>
			</math>
		</dataGenerator>
		<dataGenerator id="J0_v0_1" name="J0_v0">
			<listOfVariables>
				<variable id="J0_v0" name="J0_v0" taskReference="nested1"
					target="/sbml:sbml/sbml:model/sbml:listOfParameters/ 
sbml:parameter[@id='J0_v0']" />
			</listOfVariables>
			<math xmlns="http://www.w3.org/1998/Math/MathML">
				<ci> J0_v0 </ci>
			</math>
		</dataGenerator>
		<dataGenerator id="S1_1" name="S1">
			<listOfVariables>
				<variable id="S1" name="S1" taskReference="nested1"
					target="/sbml:sbml/sbml:model/sbml:listOfSpecies/ 
sbml:species[@id='S1']" />
			</listOfVariables>
			<math xmlns="http://www.w3.org/1998/Math/MathML">
				<ci> S1 </ci>
			</math>
		</dataGenerator>
		<dataGenerator id="S2_1" name="S2">
			<listOfVariables>
				<variable id="S2" name="S2" taskReference="nested1"
					target="/sbml:sbml/sbml:model/sbml:listOfSpecies/ 
sbml:species[@id='S2']" />
			</listOfVariables>
			<math xmlns="http://www.w3.org/1998/Math/MathML">
				<ci> S2 </ci>
			</math>
		</dataGenerator>
	</listOfDataGenerators>
	<listOfOutputs>
		<plot2D id="plot1" name="Timecourse  (Oscli) (for v0 = 8, 4, 0.4)">


			<listOfCurves>
				<curve id="curve1" logX="false" logY="false"
					xDataReference="time1" yDataReference="S1_1" />
				<curve id="curve2" logX="false" logY="false"
					xDataReference="time1" yDataReference="S2_1" />
			</listOfCurves>
		</plot2D>
	</listOfOutputs>
</sedML>


One other suggestion: in the current nestedSimulations, inner loops  
are not reusable - they are defined with respect to the outer  
simulations. How about
being able to define  1D parameter scans independently, which could be  
combined together simply, e.g.,

<nestedSimulationTask>
  <simulationTaskRef refid="paramscan1"/>
  <simulationTaskRef refid="paramscan2"/>
</nestedSimulationTask>

indicating a   combination of two tasks to produce a 2D scan?  I.e.,  
each task is defined 'one-dimensionally' but can  be composed into N- 
dimensional simulations by linear combination.


Finally one other benefit of the nested simulation approach in  
general, to include in the proposal ( I think it's been mentioned in  
discussions) is that it will no longer be
necessary to use SBML Events to encode time dependent changes to  
parameters in SBML - a vector range of time values. This will be  
really useful to reduce the pollution of model databases with  
structurally identical models differing only in runtime setup.

Cheers
Richard


On 7 Feb 2012, at 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
>

Dr Richard Adams
Centre For Systems Biology Edinburgh
University of Edinburgh
Tel: 0131 651 9019
email : ric...@ed...
Web: http://csbe.bio.ed.ac.uk/adams.php

*** Places available on CSBE modelling course  April 2012 ***
see http://www.csbe.ed.ac.uk/news-events/event/course-details








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

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

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

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

Re: [SED-ML-discuss] Future of SED-ML

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

On 02/02/12 09:57, Richard Adams wrote:

>>> Optimisation (parameter sampling)
>>
>> This could be done with the nested approach, provided we had a
>> simulation
>> class for optimization, where we would define the objective as well as
>> parameters and constraints.
>>
>
> Also we would need classes for the optimization procedure ( e.g.,
> simulated annealing, GA, etc., which each have specific arguments to
> configure them (mu, population size, mutation frequency etc., ) .
> These could be generic param name/value pairs, perhaps using Kisao
> terms? Would optimisation algorithms fit in Kisao ?

Yes, the specific algorithms are food for KiSAO, because this is an 
unbounded problem. Classes of simulation should be types of simulation, 
what we want to do, not how to do it.

>    And also time-series to reference, together with which parts of a
> dataset to use in fitting, time offsets wrt to simulation time etc.
> This would be needed when
> referencing public data sets of which we're only interested in a part.
>
> Cheers
>    Richard
>
>>> Population sampling (for PK models)
>>
>> This will be tough, especially without referencing experimental
>> data, so I
>> would want to hold off for this just a bit longer.
>>
>> Cheers
>> 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
>>
>
> Dr Richard Adams
> Centre For Systems Biology Edinburgh
> University of Edinburgh
> Tel: 0131 651 9019
> email : ric...@ed...
> Web: http://csbe.bio.ed.ac.uk/adams.php
>
> *** Places available on CSBE modelling course  April 2012 ***
> see http://www.csbe.ed.ac.uk/news-events/event/course-details
>
>
>
>
>
>
>
>


-- 
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] Future of SED-ML

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

>
> issue.
>
>> Optimisation (parameter sampling)
>
> This could be done with the nested approach, provided we had a  
> simulation
> class for optimization, where we would define the objective as well as
> parameters and constraints.
>

Also we would need classes for the optimization procedure ( e.g.,  
simulated annealing, GA, etc., which each have specific arguments to  
configure them (mu, population size, mutation frequency etc., ) .  
These could be generic param name/value pairs, perhaps using Kisao  
terms? Would optimisation algorithms fit in Kisao ?
  And also time-series to reference, together with which parts of a  
dataset to use in fitting, time offsets wrt to simulation time etc.  
This would be needed when
referencing public data sets of which we're only interested in a part.

Cheers
  Richard

>> Population sampling (for PK models)
>
> This will be tough, especially without referencing experimental  
> data, so I
> would want to hold off for this just a bit longer.
>
> Cheers
> 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
>

Dr Richard Adams
Centre For Systems Biology Edinburgh
University of Edinburgh
Tel: 0131 651 9019
email : ric...@ed...
Web: http://csbe.bio.ed.ac.uk/adams.php

*** Places available on CSBE modelling course  April 2012 ***
see http://www.csbe.ed.ac.uk/news-events/event/course-details








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

Re: [SED-ML-discuss] Future of SED-ML

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

> What we should do so that everyone is happy, is to make sure we say
> 
> "task 1 is made of 100 task 2 with parameter X taking 100 values,
> logarithmically distributed between value a and b."
> 
> rather than
> 
> "perform task 1 by iteratively performing task 2 with parameter X taking
> successively 100 values logarithmically distributed from a to b."
> 
> I realise it is merely a semantic trick, but would-that satisfy everyone?
> 

I look forward to see you proposal on how you would like this realized in
SED-ML. It looks a bit like we are talking about whether it is tomAtos or
tomatOs, but maybe I'm missing a bit. 

> We can still have classes of simulation that would be used in those tasks.

In fact we will need to! Especially given your list below.

> Then we could move on the proposal itself, trying to see it it fits the
bill of the
> current needs:
> 
> Parameter scan (dose response)

This can be done 

> Steady-state analysis

This can be done to an extent. Where it currently falls short is the
description of model intrinsic /derived variables (control coefficients,
elasticities, the Jacobian). This again is independent of the nested
proposal. Any other kind of newly defined simulation will have the same
issue. 

> Optimisation (parameter sampling)

This could be done with the nested approach, provided we had a simulation
class for optimization, where we would define the objective as well as
parameters and constraints. 

> Population sampling (for PK models)

This will be tough, especially without referencing experimental data, so I
would want to hold off for this just a bit longer. 

Cheers
Frank

Re: [SED-ML-discuss] Future of SED-ML

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

I am not sure we reached a closure on that. I believe most people 
expressing their opinion were leaning towards Frank approach.

Personally, I think the nesting itself does not make SED-ML much more 
imperative than declarative. If this is the case, then CellML is imperative 
since we can nest components. And other language describing complex 
geometries for instance. In SBML, the multi proposal would be imperative, 
describing the building of species from other species.

What we should do so that everyone is happy, is to make sure we say

"task 1 is made of 100 task 2 with parameter X taking 100 values, 
logarithmically distributed between value a and b."

rather than

"perform task 1 by iteratively performing task 2 with parameter X taking 
successively 100 values logarithmically distributed from a to b."

I realise it is merely a semantic trick, but would-that satisfy everyone?

We can still have classes of simulation that would be used in those tasks. 
So it is not merely a generic declarative language either.

Then we could move on the proposal itself, trying to see it it fits the 
bill of the current needs:

Parameter scan (dose response)
Steady-state analysis
Optimisation (parameter sampling)
Population sampling (for PK models)
other?

On 20/01/12 00:09, Andrew Miller wrote:
> On 20/01/12 12:29, Frank T. Bergmann wrote:
>>
>>>> I would argue, that we are not re-inventing the wheel. What we are
>>>> doing is creating a language independent specification of simulations.
>>>
>>> If we are creating a new language to describe simulation procedures
>>> imperatively, it isn't language-independent - it is dependent on the new
>>> language we invent (you wouldn't be able to describe your simulations
>>> independently of the new 'nested simulations' language).
>>>
>>
>> Language independent here meant programming language independent. As XML
>> parsers are accessible in any programming language it would be straight
>> forward to use the new construct in all of them, with considerably less
>> overhead than it would take to embed / execute a description in any script
>> language we chose.
>
> My point is that the direction we are moving with nested simulations is
> to create a new scripting language marked up in XML - that is, we are
> creating a new programming language.
>
> Tools that work with SED-ML will already have an XML parser, but parsing
> is a tiny fraction of the work needed to implement a scripting language.
> Python's grammar itself is actually very simple
> (http://docs.python.org/reference/grammar.html) - likewise for Haskell
> http://hackage.haskell.org/trac/ghc/browser/compiler/parser/Parser.y.pp;
> many Lisp dialects are even simpler.
>
> Getting from the language to an abstract syntax tree is a bit easier
> with XML - but that step is a fairly minor part. From this point,
> everything is specific to the language, and the fact that it originally
> came from XML makes no different; for example, code might perform
> optimisations on the AST, and compile the AST to byte-code, or it might
> step through the AST in an interpreter - but in any case, the amount of
> machinery needed to make this work dwarfs the size of the parser anyway.
>
> There is therefore negligible difference in the code-size overhead of
> software tools between XML-based scripting languages and non-XML-based
> scripting languages.
>
>>
>>>
>>> This same argument applies equally to a newly created nested simulations
>>> language, except that a newly created language will have a far smaller
>> base of
>>> existing code to try to interoperate with.
>>>
>>
>> And so no, people are still free to choose the programming language for
>> their tools with minimal overhead.
>
> If the nested simulations proposal becomes a programming language (i.e.
> continues in the same direction) then people are not free to choose not
> to implement that programming language, and the code to support that
> programming language will add overhead to the tools.
>
> Python itself (as opposed to many of the libraries that come with
> CPython, which you probably wouldn't need just for sequencing
> simulations) can be implemented in 64k of code: http://www.tinypy.org/,
> and Python can already be embedded from a wide variety of programming
> languages (and Python is just an example - there are other choices than
> Python that may be even smaller and simpler to implement).
>
> Best wishes,
> Andrew
>
>>
>>> We are trying to do two slightly different things.
>>
>> I agree with this at least :) And I think your and my position is quite
>> clear at this point. We just need to sort out where the community wants this
>> to move.
>>
>> Cheers
>> 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] [Combine-discuss] SDCubes

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

Hi Richards,

Thank you for the pointer. That is very relevant for NuML, so I guess for 
SED-ML as the first NuML users (until the SBML distrib package gets more 
defined and official).

Cheers

On 26/01/12 22:02, Richard Adams wrote:
>    Hello,
>    Just thinking about  standard data representation, has anyone had
> any experience with this SDCube data format published in Nature
> Methods last year?
>    Is it worth looking into at all?
>
> http://www.nature.com/nmeth/journal/v8/n6/full/nmeth.1600.html
>
> Regards,
>    Richard
>
>
>
>
>>
>>
>
> Dr Richard Adams
> Centre For Systems Biology Edinburgh
> University of Edinburgh
> Tel: 0131 651 9019
> email : ric...@ed...
> Web: http://csbe.bio.ed.ac.uk/adams.php
>
> *** Places available on CSBE modelling course  April 2012 ***
> see http://www.csbe.ed.ac.uk/news-events/event/course-details
>
>
>
>



>
>
>
>


-- 
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

[Brett G. O. <bre...@gm...>]

On Thu, Jan 19, 2012 at 6:45 PM, Richard Adams <ric...@ed...>wrote:

> Hello All,
>
> > I see the place of a SED-ML document as a *description* of a
> > simulation
> > experiment, rather than merely a procedure for replicating a
> > simulation
> > experiment.
>
> I'm not sure what you mean by this - as I understand it, SED-ML should
> enable simulation descriptions to a sufficient level of details such
> that
> published results can be replicated and re-run with little effort by
> end-users. Many simulations include alterations in parameters during a
> simulation run.
> At present this could be done ( at least for SBML) by a combination of
> existing SED-ML and addition /manipulation of SBML events, but it's
> not as clean as explicit manipulation of parameter values by SED-ML.
> Frank's proposal is very flexible and can encode a wide range of
> different sorts of experiments. If we can come up with a similarly
> flexible handling for multidimensional data I think we're in good shape.
>
>
I agree with these sentiments and Frank's proposal, allowing multidimension
parameter scans and an experiment that could be defined as a sequence of
optimisations would make SED-ML useful in being able to also describe
steady-state (constraint based) modelling results.


>
>

> On 19 Jan 2012, at 07:45, Andrew Miller wrote:
>
> > On 19/01/12 20: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.
> >
> > Hi Frank and others,
> >
> > I think that if a proposal like this was included in SED-ML, it would
> > fundamentally change what SED-ML is, and make SED-ML into something
> > which has no distinct utility over and beyond a general purpose
> > programming language.
> >
> >
> >
> > From a description of a simulation experiment, it is possible to
> > replicate the experiment, but it is also possible to do other types of
> > analysis - for example, inferring the intent of the simulation
> > experiment and perhaps performing automated reasoning from the result.
> >
> > The nested simulations approach is getting dangerously close to simply
> > describing the procedure for performing simulation experiments, rather
> > than describing a simulation experiment.
> >
> > Someone wanting to code a procedure, without necessarily describing
> > higher level semantic information about the procedure, would be better
> > off using an existing general purpose imperative programming
> > language -
> > they don't need SED-ML for that. Languages like C and Python have a
> > large number of existing implementations which have already been
> > thoroughly tested, build on lessons learnt from previous languages to
> > give a huge amount of cumulate language design legacy, and have more
> > expressive power than the nested simulations proposal. If all SED-ML
> > is
> > going to be is a general purpose way to reproduce simulation
> > experiments, there is no point reinventing the wheel and competing
> > with
> > existing imperative languages.
> >
> > However, SED-ML is far more useful if it is targeted at describing
> > simulation experiments. This means that it does need to incorporate
> > facilities for a large number of different types of simulation
> > experiments. This is a significant amount of work, but it is the
> > meaningful approach consistent with the current SED-ML. It means we
> > need
> > to have very streamlined processes for adding new types of simulation
> > experiments to the language, and to make the language more extensible.
> >
> > Best wishes,
> > Andrew
> >
> >>
> >> 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
> >
>
> Dr Richard Adams
> Centre For Systems Biology Edinburgh
> University of Edinburgh
> Tel: 0131 651 9019
> email : ric...@ed...
> Web: http://csbe.bio.ed.ac.uk/adams.php
>
> *** Places available on CSBE modelling course  April 2012 ***
> see http://www.csbe.ed.ac.uk/news-events/event/course-details
>
>
>
>
>
>
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
>
> ------------------------------------------------------------------------------
> 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
>



-- 
Brett G. Olivier PhD

[SED-ML-discuss] Nested simulations

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

Hello all,

This discussion is becoming a bit too far from our immediate needs I 
believe. Why don't we look at what people do at the moment. Could-we have a 
look at how COPASI encodes parameter scans, steady-state and optimization 
for instance?

Cheers

-- 
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] Future of SED-ML

[Andrew M. <ak....@au...>]

On 20/01/12 12:29, Frank T. Bergmann wrote:
>
>>> I would argue, that we are not re-inventing the wheel. What we are
>>> doing is creating a language independent specification of simulations.
>>
>> If we are creating a new language to describe simulation procedures
>> imperatively, it isn't language-independent - it is dependent on the new
>> language we invent (you wouldn't be able to describe your simulations
>> independently of the new 'nested simulations' language).
>>
>
> Language independent here meant programming language independent. As XML
> parsers are accessible in any programming language it would be straight
> forward to use the new construct in all of them, with considerably less
> overhead than it would take to embed / execute a description in any script
> language we chose.

My point is that the direction we are moving with nested simulations is 
to create a new scripting language marked up in XML - that is, we are 
creating a new programming language.

Tools that work with SED-ML will already have an XML parser, but parsing 
is a tiny fraction of the work needed to implement a scripting language. 
Python's grammar itself is actually very simple 
(http://docs.python.org/reference/grammar.html) - likewise for Haskell 
http://hackage.haskell.org/trac/ghc/browser/compiler/parser/Parser.y.pp; 
many Lisp dialects are even simpler.

Getting from the language to an abstract syntax tree is a bit easier 
with XML - but that step is a fairly minor part. From this point, 
everything is specific to the language, and the fact that it originally 
came from XML makes no different; for example, code might perform 
optimisations on the AST, and compile the AST to byte-code, or it might 
step through the AST in an interpreter - but in any case, the amount of 
machinery needed to make this work dwarfs the size of the parser anyway.

There is therefore negligible difference in the code-size overhead of 
software tools between XML-based scripting languages and non-XML-based 
scripting languages.

>
>>
>> This same argument applies equally to a newly created nested simulations
>> language, except that a newly created language will have a far smaller
> base of
>> existing code to try to interoperate with.
>>
>
> And so no, people are still free to choose the programming language for
> their tools with minimal overhead.

If the nested simulations proposal becomes a programming language (i.e. 
continues in the same direction) then people are not free to choose not 
to implement that programming language, and the code to support that 
programming language will add overhead to the tools.

Python itself (as opposed to many of the libraries that come with 
CPython, which you probably wouldn't need just for sequencing 
simulations) can be implemented in 64k of code: http://www.tinypy.org/, 
and Python can already be embedded from a wide variety of programming 
languages (and Python is just an example - there are other choices than 
Python that may be even smaller and simpler to implement).

Best wishes,
Andrew

>
>> We are trying to do two slightly different things.
>
> I agree with this at least :) And I think your and my position is quite
> clear at this point. We just need to sort out where the community wants this
> to move.
>
> Cheers
> 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

Re: [SED-ML-discuss] Future of SED-ML

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

> > I would argue, that we are not re-inventing the wheel. What we are
> > doing is creating a language independent specification of simulations.
> 
> If we are creating a new language to describe simulation procedures
> imperatively, it isn't language-independent - it is dependent on the new
> language we invent (you wouldn't be able to describe your simulations
> independently of the new 'nested simulations' language).
> 

Language independent here meant programming language independent. As XML
parsers are accessible in any programming language it would be straight
forward to use the new construct in all of them, with considerably less
overhead than it would take to embed / execute a description in any script
language we chose. 

> 
> This same argument applies equally to a newly created nested simulations
> language, except that a newly created language will have a far smaller
base of
> existing code to try to interoperate with.
> 

And so no, people are still free to choose the programming language for
their tools with minimal overhead. 

> We are trying to do two slightly different things. 

I agree with this at least :) And I think your and my position is quite
clear at this point. We just need to sort out where the community wants this
to move. 

Cheers
Frank

Re: [SED-ML-discuss] Future of SED-ML

[Andrew M. <ak....@au...>]

On 20/01/12 11:39, Frank T. Bergmann wrote:
>> I don't think anyone has made a convincing argument for reinventing the
>> wheel to create this domain-specific programming language.
>
> I would argue, that we are not re-inventing the wheel. What we are doing is
> creating a language independent specification of simulations.

If we are creating a new language to describe simulation procedures 
imperatively, it isn't language-independent - it is dependent on the new 
language we invent (you wouldn't be able to describe your simulations 
independently of the new 'nested simulations' language).

> That way it
> can be re-used in *any* language, at *any* time. Encoding the same protocol
> in  imperative code has several obvious drawbacks:
>
> 1. we would need to choose a language (and this will be a hard one to agree
> about)

There are far fewer decisions to make in picking an existing language 
compared to designing a new language from the ground up, because the 
existing languages have already taken these decisions and their 
respective communities have already come to consensus on them.

> 2. we would then *all* need to somehow embed this language in our
> applications (or use interop) / or write our own parsers for that language
> so we could adapt it in other languages

This same argument applies equally to a newly created nested simulations 
language, except that a newly created language will have a far smaller 
base of existing code to try to interoperate with.

> 3. we would be at the whim of the language designers (look what happened to
> python with v3 and compatibility to previous modules)

We could declare that the language to use is a particular version of the 
existing language. In terms of change control this would put us in an 
identical position to reinventing the wheel - if we don't do anything 
explicitly, the language doesn't change - but we would have a much 
better language available with a lot less work.

> 4. we would lose the capabilities for annotation that we currently have.

I'm not sure how you would annotate the imperative parts of a nested 
simulation anyway - it is essentially a black box, where you annotate 
the inputs and the black box as a whole, but not the internals of the 
black box. Likewise, if we embedded an existing imperative language, it 
would similarly be treated as a black box where you would annotate the 
inputs and the black box as a whole, but not individual instructions in 
the black box. If we allowed black boxes to refer to 'functions' defined 
other black boxes, you could still break up the imperative code into 
several blocks, and annotate those blocks separately.

>
> We have SED-ML now so I would be in favor of using it. It has taken us
> already 4 years to get to this point.

SED-ML is a purely declarative description; there is a clear place for 
something like that.

What we are talking about now can be thought of as a way to describe how 
different types of simulation experiments are performed, as opposed to 
just declaring the simulation experiment.

> I don't see that splitting the
> language into two separate ones is aiding our cause.

We are trying to do two slightly different things. Perhaps an 
alternative would be to at have least two different parts under the same 
specification for these things (declaring a simulation in terms of 
simulation types, and defining a simulation type); this would be 
analogous to what the W3C did with MathML, where both content and 
presentation MathML are described in a single specification.

> Neither would be us
> arguing about choosing another representation layer by moving away from XML.

We wouldn't have to move away from XML - we could embed fragments of 
another language in XML as a CDATA section.

Best wishes,
Andrew

Re: [SED-ML-discuss] Future of SED-ML

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

> I don't think anyone has made a convincing argument for reinventing the
> wheel to create this domain-specific programming language.  

I would argue, that we are not re-inventing the wheel. What we are doing is
creating a language independent specification of simulations. That way it
can be re-used in *any* language, at *any* time. Encoding the same protocol
in  imperative code has several obvious drawbacks: 

1. we would need to choose a language (and this will be a hard one to agree
about)
2. we would then *all* need to somehow embed this language in our
applications (or use interop) / or write our own parsers for that language
so we could adapt it in other languages
3. we would be at the whim of the language designers (look what happened to
python with v3 and compatibility to previous modules)
4. we would lose the capabilities for annotation that we currently have. 

We have SED-ML now so I would be in favor of using it. It has taken us
already 4 years to get to this point. I don't see that splitting the
language into two separate ones is aiding our cause. Neither would be us
arguing about choosing another representation layer by moving away from XML.


Best
Frank

Re: [SED-ML-discuss] Future of SED-ML

[Andrew M. <ak....@au...>]

On 20/01/12 08:35, Lucian Smith wrote:
> I also agree.  Another way of looking at this is that it's like the
> 'Methods' section of a paper.  And the problem with Methods sections is
> that they're tedious and people don't like to do them properly, so you
> end up with bits that just say "We followed the Haversham protocol here"
> and if you look up Haversham they claim to follow the Hawley-Smoot
> protocol from 1951, and while the general approach is the same, the
> specifics of what actually gets performed in the lab have changed over the
> years.
>
> So while it's fine to annotate a simulation protocol 'Haversham, 1992', it
> is best if you actually have something that can really be followed down to
> the last detail.  In that way, you allow people to see the nuts and bolts
> of what you did slightly differently to Haversham, and they can see for
> themselves if it's merely for efficiency, or if it makes a material
> difference in the simulation.
>
> So, yes.  SED-ML should ideally end up roughly equivalent to a
> domain-specific programming language.  I believe this will make it more
> procedural and less declarative (unlike the models they manipulate), but
> that's simply because of the nature of the problem it sets out to solve.

I don't disagree that something like this should exist - it would be 
great if there was a high-level language (like SED-ML is now) that could 
refer to a library of descriptions of general simulation experiment 
types. That way, high-level descriptions can be created, and if it 
doesn't do something that is required, you can code up the imperative 
description of a new type of simulation experiment, add it to the 
library, and then refer to it. I would prefer that SED-ML was the 
high-level language and we called the lower level one something else, 
but either way, we need both.

I don't think anyone has made a convincing argument for reinventing the 
wheel to create this domain-specific programming language. Frank said:

   "Again, the key point is to be able to *exchange* the description so
    it can be reproduced and validated using different software tools.
    Essentially to be able to apply the scientific method to simulation
    experiments. You don't get that with a general purpose programming
    language".

You absolutely can exchange imperative code - we could embed fragments 
of Python in a file, or perhaps use something like Haskell that runs in 
a custom monad and so doesn't have access to IO facilities; there are 
already different implementations of both Python and Haskell, and they 
could certainly be used from different software tools. Java applets are 
a good example of how imperative code descriptions of applets are 
exchanged between software implementations - the same applet can be run 
in different browsers, using different Java implementations.

Of course, the line between the software tool and the imperative code 
being exchanged can get a bit blurred if a significant amount of the 
logic for a software tool comes from a database, but this is inevitable 
and applies just as much if we reinvent an expressive imperative language.

Best wishes,
Andrew

>
> -Lucian
>
> * Jonathan Cooper<jon...@cs...>  [2012-01-19 19:18] writes:
>> Hi all,
>>
>> Not really anything to add here, but I agree 100% with Frank and think
>> he expressed it very well!
>>
>> Best wishes,
>> Jonathan
>>
>> On 19/01/2012 17:34, Frank T. Bergmann wrote:
>>> Hello Andrew,
>>>
>>> I modified the subject for this one, as I believe it is a vital topic to be discussed and it certainly is independent of the nested proposal.
>>>
>>>> I think that if a proposal like this was included in SED-ML, it would
>>>> fundamentally change what SED-ML is, and make SED-ML into something
>>>> which has no distinct utility over and beyond a general purpose
>>>> programming language.
>>>>
>>> Yes it has, SED-MLs aim is to describe simulation experiments independently from a model definition language and independent from the original software application that gave rise to it. This is of great utility and IMO quite distinct from anything we have.
>>>
>>> If however we don't have a a general construct like the one outlined in the nested proposal, we end up with a small selection of highly specialized simulation classes that will fit a small number of experiments. Even if we allow those simulation experiments to expand over time, it will take a long time to be adopted by software. Essentially, for me this would make SED-ML no longer as interesting.
>>>
>>> Remember we have all facilities to annotate the protocol of how the simulation result was obtained in the first place. You are free to use miriam annotations and any ontology you'd like.
>>>
>>>>    From a description of a simulation experiment, it is possible to
>>>> replicate the experiment, but it is also possible to do other types of
>>>> analysis - for example, inferring the intent of the simulation
>>>> experiment and perhaps performing automated reasoning from the result.
>>>>
>>> And why could you not do this with a well annotated nested simulation? What would prevent you to annotate it with the same terms that you would use for a highly specialized parameterScan simulation class?
>>>
>>>> Someone wanting to code a procedure, without necessarily describing
>>>> higher level semantic information about the procedure, would be better
>>>> off using an existing general purpose imperative programming language -
>>>> they don't need SED-ML for that.
>>> Again, the key point is to be able to *exchange* the description so it can be reproduced and validated using different software tools. Essentially to be able to apply the scientific method to simulation experiments. You don't get that with a general purpose programming language.
>>>
>>>> However, SED-ML is far more useful if it is targeted at describing
>>>> simulation experiments. This means that it does need to incorporate
>>>> facilities for a large number of different types of simulation
>>>> experiments. This is a significant amount of work, but it is the
>>>> meaningful approach consistent with the current SED-ML. It means we need
>>>> to have very streamlined processes for adding new types of simulation
>>>> experiments to the language, and to make the language more extensible.
>>> This in my opinion would make SED-ML extremely unattractive to adoption, as it would always be a moving target with each version supporting a different number of simulation classes. As such it would impose a high maintenance risk to any software team. This will imply that descriptions encoded in one tool are very likely not to run in another, as they are extremely likely to support a different number of simulation classes.
>>>
>>> To close: with the nested simulation experiment we get the best of both worlds. We have a description of all the required steps to reproduce the results AND we have the capabilities to annotate it to allow reasoning over it.
>>>
>>> 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
>
> ------------------------------------------------------------------------------
> 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

Re: [SED-ML-discuss] Future of SED-ML

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

and I agree with Jonathan. Very nice explanation Frank.

Cheers,
David.

On Fri, Jan 20, 2012 at 8:15 AM, Jonathan Cooper
<jon...@cs...> wrote:
> Hi all,
>
> Not really anything to add here, but I agree 100% with Frank and think
> he expressed it very well!
>
> Best wishes,
> Jonathan
>
> On 19/01/2012 17:34, Frank T. Bergmann wrote:
>> Hello Andrew,
>>
>> I modified the subject for this one, as I believe it is a vital topic to be discussed and it certainly is independent of the nested proposal.
>>
>>> I think that if a proposal like this was included in SED-ML, it would
>>> fundamentally change what SED-ML is, and make SED-ML into something
>>> which has no distinct utility over and beyond a general purpose
>>> programming language.
>>>
>> Yes it has, SED-MLs aim is to describe simulation experiments independently from a model definition language and independent from the original software application that gave rise to it. This is of great utility and IMO quite distinct from anything we have.
>>
>> If however we don't have a a general construct like the one outlined in the nested proposal, we end up with a small selection of highly specialized simulation classes that will fit a small number of experiments. Even if we allow those simulation experiments to expand over time, it will take a long time to be adopted by software. Essentially, for me this would make SED-ML no longer as interesting.
>>
>> Remember we have all facilities to annotate the protocol of how the simulation result was obtained in the first place. You are free to use miriam annotations and any ontology you'd like.
>>
>>>  From a description of a simulation experiment, it is possible to
>>> replicate the experiment, but it is also possible to do other types of
>>> analysis - for example, inferring the intent of the simulation
>>> experiment and perhaps performing automated reasoning from the result.
>>>
>> And why could you not do this with a well annotated nested simulation? What would prevent you to annotate it with the same terms that you would use for a highly specialized parameterScan simulation class?
>>
>>> Someone wanting to code a procedure, without necessarily describing
>>> higher level semantic information about the procedure, would be better
>>> off using an existing general purpose imperative programming language -
>>> they don't need SED-ML for that.
>> Again, the key point is to be able to *exchange* the description so it can be reproduced and validated using different software tools. Essentially to be able to apply the scientific method to simulation experiments. You don't get that with a general purpose programming language.
>>
>>> However, SED-ML is far more useful if it is targeted at describing
>>> simulation experiments. This means that it does need to incorporate
>>> facilities for a large number of different types of simulation
>>> experiments. This is a significant amount of work, but it is the
>>> meaningful approach consistent with the current SED-ML. It means we need
>>> to have very streamlined processes for adding new types of simulation
>>> experiments to the language, and to make the language more extensible.
>> This in my opinion would make SED-ML extremely unattractive to adoption, as it would always be a moving target with each version supporting a different number of simulation classes. As such it would impose a high maintenance risk to any software team. This will imply that descriptions encoded in one tool are very likely not to run in another, as they are extremely likely to support a different number of simulation classes.
>>
>> To close: with the nested simulation experiment we get the best of both worlds. We have a description of all the required steps to reproduce the results AND we have the capabilities to annotate it to allow reasoning over it.
>>
>> 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

Re: [SED-ML-discuss] Future of SED-ML

[Lucian S. <lp...@sp...>]

I also agree.  Another way of looking at this is that it's like the 
'Methods' section of a paper.  And the problem with Methods sections is 
that they're tedious and people don't like to do them properly, so you 
end up with bits that just say "We followed the Haversham protocol here" 
and if you look up Haversham they claim to follow the Hawley-Smoot 
protocol from 1951, and while the general approach is the same, the 
specifics of what actually gets performed in the lab have changed over the 
years.

So while it's fine to annotate a simulation protocol 'Haversham, 1992', it 
is best if you actually have something that can really be followed down to 
the last detail.  In that way, you allow people to see the nuts and bolts 
of what you did slightly differently to Haversham, and they can see for 
themselves if it's merely for efficiency, or if it makes a material 
difference in the simulation.

So, yes.  SED-ML should ideally end up roughly equivalent to a 
domain-specific programming language.  I believe this will make it more 
procedural and less declarative (unlike the models they manipulate), but 
that's simply because of the nature of the problem it sets out to solve.

-Lucian

* Jonathan Cooper <jon...@cs...> [2012-01-19 19:18] writes:
> Hi all,
> 
> Not really anything to add here, but I agree 100% with Frank and think 
> he expressed it very well!
> 
> Best wishes,
> Jonathan
> 
> On 19/01/2012 17:34, Frank T. Bergmann wrote:
> > Hello Andrew,
> >
> > I modified the subject for this one, as I believe it is a vital topic to be discussed and it certainly is independent of the nested proposal.
> >
> >> I think that if a proposal like this was included in SED-ML, it would
> >> fundamentally change what SED-ML is, and make SED-ML into something
> >> which has no distinct utility over and beyond a general purpose
> >> programming language.
> >>
> > Yes it has, SED-MLs aim is to describe simulation experiments independently from a model definition language and independent from the original software application that gave rise to it. This is of great utility and IMO quite distinct from anything we have.
> >
> > If however we don't have a a general construct like the one outlined in the nested proposal, we end up with a small selection of highly specialized simulation classes that will fit a small number of experiments. Even if we allow those simulation experiments to expand over time, it will take a long time to be adopted by software. Essentially, for me this would make SED-ML no longer as interesting.
> >
> > Remember we have all facilities to annotate the protocol of how the simulation result was obtained in the first place. You are free to use miriam annotations and any ontology you'd like.
> >
> >>  From a description of a simulation experiment, it is possible to
> >> replicate the experiment, but it is also possible to do other types of
> >> analysis - for example, inferring the intent of the simulation
> >> experiment and perhaps performing automated reasoning from the result.
> >>
> > And why could you not do this with a well annotated nested simulation? What would prevent you to annotate it with the same terms that you would use for a highly specialized parameterScan simulation class?
> >
> >> Someone wanting to code a procedure, without necessarily describing
> >> higher level semantic information about the procedure, would be better
> >> off using an existing general purpose imperative programming language -
> >> they don't need SED-ML for that.
> > Again, the key point is to be able to *exchange* the description so it can be reproduced and validated using different software tools. Essentially to be able to apply the scientific method to simulation experiments. You don't get that with a general purpose programming language.
> >
> >> However, SED-ML is far more useful if it is targeted at describing
> >> simulation experiments. This means that it does need to incorporate
> >> facilities for a large number of different types of simulation
> >> experiments. This is a significant amount of work, but it is the
> >> meaningful approach consistent with the current SED-ML. It means we need
> >> to have very streamlined processes for adding new types of simulation
> >> experiments to the language, and to make the language more extensible.
> > This in my opinion would make SED-ML extremely unattractive to adoption, as it would always be a moving target with each version supporting a different number of simulation classes. As such it would impose a high maintenance risk to any software team. This will imply that descriptions encoded in one tool are very likely not to run in another, as they are extremely likely to support a different number of simulation classes.
> >
> > To close: with the nested simulation experiment we get the best of both worlds. We have a description of all the required steps to reproduce the results AND we have the capabilities to annotate it to allow reasoning over it.
> >
> > 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

Re: [SED-ML-discuss] Future of SED-ML

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

Hi all,

Not really anything to add here, but I agree 100% with Frank and think 
he expressed it very well!

Best wishes,
Jonathan

On 19/01/2012 17:34, Frank T. Bergmann wrote:
> Hello Andrew,
>
> I modified the subject for this one, as I believe it is a vital topic to be discussed and it certainly is independent of the nested proposal.
>
>> I think that if a proposal like this was included in SED-ML, it would
>> fundamentally change what SED-ML is, and make SED-ML into something
>> which has no distinct utility over and beyond a general purpose
>> programming language.
>>
> Yes it has, SED-MLs aim is to describe simulation experiments independently from a model definition language and independent from the original software application that gave rise to it. This is of great utility and IMO quite distinct from anything we have.
>
> If however we don't have a a general construct like the one outlined in the nested proposal, we end up with a small selection of highly specialized simulation classes that will fit a small number of experiments. Even if we allow those simulation experiments to expand over time, it will take a long time to be adopted by software. Essentially, for me this would make SED-ML no longer as interesting.
>
> Remember we have all facilities to annotate the protocol of how the simulation result was obtained in the first place. You are free to use miriam annotations and any ontology you'd like.
>
>>  From a description of a simulation experiment, it is possible to
>> replicate the experiment, but it is also possible to do other types of
>> analysis - for example, inferring the intent of the simulation
>> experiment and perhaps performing automated reasoning from the result.
>>
> And why could you not do this with a well annotated nested simulation? What would prevent you to annotate it with the same terms that you would use for a highly specialized parameterScan simulation class?
>
>> Someone wanting to code a procedure, without necessarily describing
>> higher level semantic information about the procedure, would be better
>> off using an existing general purpose imperative programming language -
>> they don't need SED-ML for that.
> Again, the key point is to be able to *exchange* the description so it can be reproduced and validated using different software tools. Essentially to be able to apply the scientific method to simulation experiments. You don't get that with a general purpose programming language.
>
>> However, SED-ML is far more useful if it is targeted at describing
>> simulation experiments. This means that it does need to incorporate
>> facilities for a large number of different types of simulation
>> experiments. This is a significant amount of work, but it is the
>> meaningful approach consistent with the current SED-ML. It means we need
>> to have very streamlined processes for adding new types of simulation
>> experiments to the language, and to make the language more extensible.
> This in my opinion would make SED-ML extremely unattractive to adoption, as it would always be a moving target with each version supporting a different number of simulation classes. As such it would impose a high maintenance risk to any software team. This will imply that descriptions encoded in one tool are very likely not to run in another, as they are extremely likely to support a different number of simulation classes.
>
> To close: with the nested simulation experiment we get the best of both worlds. We have a description of all the required steps to reproduce the results AND we have the capabilities to annotate it to allow reasoning over it.
>
> 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

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

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

Hello All,

> I see the place of a SED-ML document as a *description* of a  
> simulation
> experiment, rather than merely a procedure for replicating a  
> simulation
> experiment.

I'm not sure what you mean by this - as I understand it, SED-ML should  
enable simulation descriptions to a sufficient level of details such  
that
published results can be replicated and re-run with little effort by  
end-users. Many simulations include alterations in parameters during a  
simulation run.
At present this could be done ( at least for SBML) by a combination of  
existing SED-ML and addition /manipulation of SBML events, but it's  
not as clean as explicit manipulation of parameter values by SED-ML.  
Frank's proposal is very flexible and can encode a wide range of  
different sorts of experiments. If we can come up with a similarly  
flexible handling for multidimensional data I think we're in good shape.

Richard


On 19 Jan 2012, at 07:45, Andrew Miller wrote:

> On 19/01/12 20: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.
>
> Hi Frank and others,
>
> I think that if a proposal like this was included in SED-ML, it would
> fundamentally change what SED-ML is, and make SED-ML into something
> which has no distinct utility over and beyond a general purpose
> programming language.
>
>
>
> From a description of a simulation experiment, it is possible to
> replicate the experiment, but it is also possible to do other types of
> analysis - for example, inferring the intent of the simulation
> experiment and perhaps performing automated reasoning from the result.
>
> The nested simulations approach is getting dangerously close to simply
> describing the procedure for performing simulation experiments, rather
> than describing a simulation experiment.
>
> Someone wanting to code a procedure, without necessarily describing
> higher level semantic information about the procedure, would be better
> off using an existing general purpose imperative programming  
> language -
> they don't need SED-ML for that. Languages like C and Python have a
> large number of existing implementations which have already been
> thoroughly tested, build on lessons learnt from previous languages to
> give a huge amount of cumulate language design legacy, and have more
> expressive power than the nested simulations proposal. If all SED-ML  
> is
> going to be is a general purpose way to reproduce simulation
> experiments, there is no point reinventing the wheel and competing  
> with
> existing imperative languages.
>
> However, SED-ML is far more useful if it is targeted at describing
> simulation experiments. This means that it does need to incorporate
> facilities for a large number of different types of simulation
> experiments. This is a significant amount of work, but it is the
> meaningful approach consistent with the current SED-ML. It means we  
> need
> to have very streamlined processes for adding new types of simulation
> experiments to the language, and to make the language more extensible.
>
> Best wishes,
> Andrew
>
>>
>> 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
>

Dr Richard Adams
Centre For Systems Biology Edinburgh
University of Edinburgh
Tel: 0131 651 9019
email : ric...@ed...
Web: http://csbe.bio.ed.ac.uk/adams.php

*** Places available on CSBE modelling course  April 2012 ***
see http://www.csbe.ed.ac.uk/news-events/event/course-details








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

[SED-ML-discuss] Future of SED-ML

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

Hello Andrew, 

I modified the subject for this one, as I believe it is a vital topic to be discussed and it certainly is independent of the nested proposal. 

> I think that if a proposal like this was included in SED-ML, it would 
> fundamentally change what SED-ML is, and make SED-ML into something 
> which has no distinct utility over and beyond a general purpose 
> programming language.
> 

Yes it has, SED-MLs aim is to describe simulation experiments independently from a model definition language and independent from the original software application that gave rise to it. This is of great utility and IMO quite distinct from anything we have. 

If however we don't have a a general construct like the one outlined in the nested proposal, we end up with a small selection of highly specialized simulation classes that will fit a small number of experiments. Even if we allow those simulation experiments to expand over time, it will take a long time to be adopted by software. Essentially, for me this would make SED-ML no longer as interesting. 

Remember we have all facilities to annotate the protocol of how the simulation result was obtained in the first place. You are free to use miriam annotations and any ontology you'd like. 

> From a description of a simulation experiment, it is possible to 
> replicate the experiment, but it is also possible to do other types of 
> analysis - for example, inferring the intent of the simulation 
> experiment and perhaps performing automated reasoning from the result.
> 

And why could you not do this with a well annotated nested simulation? What would prevent you to annotate it with the same terms that you would use for a highly specialized parameterScan simulation class? 

> Someone wanting to code a procedure, without necessarily describing 
> higher level semantic information about the procedure, would be better 
> off using an existing general purpose imperative programming language - 
> they don't need SED-ML for that.

Again, the key point is to be able to *exchange* the description so it can be reproduced and validated using different software tools. Essentially to be able to apply the scientific method to simulation experiments. You don't get that with a general purpose programming language. 

> However, SED-ML is far more useful if it is targeted at describing 
> simulation experiments. This means that it does need to incorporate 
> facilities for a large number of different types of simulation 
> experiments. This is a significant amount of work, but it is the 
> meaningful approach consistent with the current SED-ML. It means we need 
> to have very streamlined processes for adding new types of simulation 
> experiments to the language, and to make the language more extensible.

This in my opinion would make SED-ML extremely unattractive to adoption, as it would always be a moving target with each version supporting a different number of simulation classes. As such it would impose a high maintenance risk to any software team. This will imply that descriptions encoded in one tool are very likely not to run in another, as they are extremely likely to support a different number of simulation classes. 

To close: with the nested simulation experiment we get the best of both worlds. We have a description of all the required steps to reproduce the results AND we have the capabilities to annotate it to allow reasoning over it. 

Frank

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

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

On 19/01/12 17:15, Frank T. Bergmann wrote:
>
>> One of my biggest concern with the current structure of the proposal
>> is that it disrupts the distinction simulation/model/task.
>>
>> I think that what should probably be nested is the task. I don't think
>> this would change your proposal much. We could still have
>> uber-simulations called by tasks, such as parameter optimisation (with
>> an associated method of sampling associated with a kisao term). More
>> difficult would be to keep the model changes in the model definitions
>> and calling them from the task.
>>
>>
>
> I would be fine with making it a subclass of Task, i see no immediate
> concerns. One question though, would we always reference exactly one
> original Task ? Or will we ever get into the situation where we would
> want to calculate solutions for more than one task?

I was thinking of nesting tasks. Generating a population of model instance 
would be a task. Running a simulation would be another task. Both would be 
linked to "simulation" types. For instance the generation of a population 
can be a uniform sampling (for a parameter scan) or a random sampling (for 
generating a population from a distribution-based model). In the case of 
some parameter estimations, the calculation of fitting scores could be 
another task.

Others, please react. Maybe I am just not making sense.

-- 
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/