Thread: Re: [SED-ML-discuss] Nested Proposal v2 (Page 2)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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

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

I fully agree.

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

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

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

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

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

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

Anyway, for the current topic, I agree.

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

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

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

Thread: Re: [SED-ML-discuss] Nested Proposal v2 (Page 2)

SED-ML

sed-ml-discuss