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

[SED-ML-discuss] Hello and updates from COPASI

[Pedro M. <ped...@ma...>]

Hello all in SED-ML-discuss

Just joined the list and a few colleagues of mine will join too. As you 
may know, currently COPASI does not support SED-ML. This will change and 
we are committed to add SED-ML support. We will also bring in some ideas 
to develop further SED-ML, since currently our CopasiML has the 
functionality of what SED-ML aspires (ie it stores both the model and 
all the tasks to be carried out, so it is like SBML+SED-ML together). 
Many of the tasks that you can do in COPASI currently cannot be 
specified in SED-ML, so we would like to help development too.

The first step for us will be to create a library, in C++ (since that is 
what we use), to read/write SED-ML. Other colleagues from a FP7 project 
(Eric Boix and Bertrand Moreau at CoSMo) also want to use SED-ML and 
would like such a library. I suspect others here may also be interested?

Right now, it would be great to hear from anyone already writing such a 
a library (in C/C++) to avoid duplication of efforts. Our plan is to 
create a libSEDML following the same steps as libSBML -- written in 
C/C++ and then create bindings for other languages. Frank Bergmann has 
also expressed interest and that he'd help.

best
Pedro

-- 
Pedro Mendes
Professor of Computational Systems Biology
School of Computer Science
Manchester Centre for Integrative Systems Biology
University of Manchester

Manchester Institute of Biotechnology
131 Princess Street
Manchester, M1 7DN, U.K.

[SED-ML-discuss] [Combine-announce] HARMONY travel funds

[Moraru,Ion <mo...@pa...>]

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

Re: [SED-ML-discuss] [sbml-discuss] People, we need a reboot.

[Moraru,Ion <mo...@pa...>]

Just having each of the modules available in SBML format would have been (would be) useful to many. I thought about having some of my sysbio grad students do it in the fall, but too much work...

Interestingly enough, the connection between the modules (and thus the whole model), which all run independently for a second before cross-updating variables, could actually be specified in SED-ML using the repeated task proposal - if the modules themselves would be in SBML...

Ion

Sent from my iPad

On Apr 1, 2013, at 3:54 PM, "Chris J. Myers" <my...@ec...> wrote:

>> 
>> Further, the Covert group is currently working on another whole-cell model, presumably using their same MATLAB-based software. There's opportunity to get input from them, too.
>> 
> I can comment a bit on this one.  There are several issues which made it difficult for them to use SBML.  First, their model is actually composed of many different types of models for each cellular process.  There was no good way to hook together models in SBML, but I think this has largely been addressed with the recently finalized comp package.  Second, one type of modeling used was flux balance which was not well supported within standard SBML.  This issue has also been addressed with the recently finalized fbc package.  I feel reasonably confident that one could encode their model within SBML, but here is the rub, it could not be analyzed by any tool that I'm aware of.  This, as I mentioned before, is the critical issue which is people are not choosing to not code their models in SBML, they are simply unable to find a tool that allows them to code their models that supports SBML.  In this case, they must resort to a general tool like MATLAB that allows them to essentially
>  "program" their model.  So, I think that one thing that is important going forward is to (a) develop tools that allow hybrid modeling and analysis such as used in the whole-cell model and/or (b) develop means of connecting analysis tools that support the different types of analysis.  I think if either of these existed, then we would have an easy time convincing people to use this as they would have the added benefit of an exchangeable model.
> 
> Chris
> 
> ____________________________________________________________
> To manage your sbml-discuss list subscription, visit 
> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
> 
> For a web interface to the sbml-discuss mailing list, visit
> http://sbml.org/Forums/
> 
> For questions or feedback about the sbml-discuss list,
> contact sbm...@ca...

[SED-ML-discuss] [Combine-announce] HARMONY 2013 ; COMBINE forum 2013

[Nicolas Le N. <n.l...@gm...>]

Dear Colleagues,

As you know, HARMONY 2013 is kindly organised by the Virtual Cell group, 
University of Connecticut Health Center, USA. It will take place from May 
20 to 23 2013. Registration is now open at:
http://www.eventbrite.com/event/5472145334

We are delighted to announce that the COMBINE forum 2013 will be organised 
by the Bioinformatics unit of the Curie Institute, Paris. It will take 
place from Tuesday September 17 to Friday September 20. More information 
will be sent in due course.

Best regards

-- 
Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT
Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere
Skype:n.lenovere, n.l...@gm..., ORCID: 0000-0002-6309-7327
http://lenoverelab.org/, http://lenoverelab.org/perso/lenov/

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

[SED-ML-discuss] 2013 Workshop on Interoperability in Scientific Computing

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

2013 Workshop on Interoperability in Scientific Computing
**FINAL CALL FOR PAPERS - SUBMISSION DEADLINE 20th JANUARY 2013**
========================================================================
In conjunction with ICCS 2013 June 5-7 2013, Barcelona, Spain.
http://www.cs.ox.ac.uk/david.johnson/wisc13/


The 13th annual International Conference on Computational Science (ICCS 2013)
will be held in Barcelona, Spain from 5th - 7th June 2013. ICCS is an ERA 2010
'A'-ranked conference series. For more details on the main conference, please
visit www.iccs-meeting.org The 2nd Workshop on Interoperability in Scientific
Computing (WISC '13) will be co-located with ICCS 2013.

Approaches to modelling take many forms. The mathematical, computational and
encapsulated components of models can be diverse in terms of complexity and
scale, as well as in published implementation (mathematics, source code, and
executable files). Many of these systems are attempting to solve real-world
problems in isolation. However the long-term scientific interest is in allowing
greater access to models and their data, and to enable simulations to
be combined
in order to address ever more complex issues. Markup languages, metadata
specifications, and ontologies for different scientific domains have emerged as
pathways to greater interoperability. Domain specific modelling languages allow
for a declarative development process to be achieved. Metadata specifications
enable coupling while ontologies allow cross platform integration of data.

The goal of this workshop is to bring together researchers from across
scientific
disciplines whose computational models require interoperability. This may arise
through interactions between different domains, systems being
modelled, connecting
model repositories, or coupling models themselves, for instance in
multi-scale or
hybrid simulations. The outcomes of this workshop will be to better
understand the
nature of multidisciplinary computational modelling and data handling.
Moreover we
hope to identify common abstractions and cross-cutting themes in future
interoperability research applied to the broader domain of scientific computing.

The first instance of this workshop (WISC '11) was successfully held as part of
the IEEE eScience conference in 2011 in Stockholm, Sweden, where all
accepted papers
were published in the workshops proceedings by the IEEE Computer Society and
archived on IEEE eXplore. We look forward to your contributions and
participation
in WISC '13.

**FINAL CALL FOR PAPER SUBMISSIONS**

We invite submissions for high-quality papers (up to 10 pages in length) within
the context of scientific computing in any of the traditional sciences (physics,
chemistry, biology), engineering, or scientific/mathematical modelling
applied to
the social sciences and humanities. Papers should address progress, results or
positions in one or more of the following areas:

* Use of metadata standards for annotating scientific models and data.
* Curating and publishing digital models and data to online repositories.
* Meta-modelling and markup languages for model description.
* Theoretical frameworks for combining disparate models, multi-scale models.
* Using standardised data formats in computational models.
* Domain-specific ontologies for the sciences.

Proceedings of the ICCS 2013 workshops will be published by Elsevier
Science, and
will be made available online through the open-access Procedia Computer Science.
Selected papers from the conference will be considered for publication in
Elsevier's Journal of Computational Science.

SUBMISSION PROCESS

Authors are invited to submit papers with unpublished, original work of not more
than 10 pages, as per the rules of Procedia Computer Science. Selected
papers from
the conference will be considered for publication in Elsevier's Journal of
Computational Science.

Templates are available from here:

LaTeX template: http://www.iccs-meeting.org/iccs2013/procedia/ecrc-procs.zip

MS Word template:
http://www.iccs-meeting.org/iccs2013/procedia/ProcediaComputerScience_template.dot

Papers conforming to the above guidelines should be submitted through the ICCS
online submission system here:

http://www.iccs-meeting.org/iccs2013/papers/upload.php

Note, when submitting your paper please be sure to select the correct workshop,
otherwise it will not be directed to the workshop organisers.

It is expected that at least one author of each accepted paper attend
the conference
and workshop.

IMPORTANT DATES

Full papers due: **EXTENDED TO 20th JANUARY 2013**
Notification of acceptance: 10th February 2013
Camera-ready: 1st March 2013
Workshop date: TBC, June 2013

CHAIRS/ORGANISERS

David Johnson (University of Oxford, UK)
Steve McKeever (Uppsala University, Sweden)

Contact: dav...@cs...

[SED-ML-discuss] Fwd: [sbml-discuss] Systems Biology Simulation Core Library Version 1.2 now available

[Nicolas Le N. <n.l...@gm...>]

-------- Original Message --------
Subject: [sbml-discuss] Systems Biology Simulation Core Library Version 1.2 
now available
Date: Thu, 13 Dec 2012 16:58:34 +0100
From: Andreas Dräger <and...@un...>
Reply-To: SBML Discussion List <sbm...@ca...>
To: SBML Discussion List <sbm...@ca...>

Dear all,

The Systems Biology Simulation Core Library provides an efficient and
exhaustive Java implementation of methods to interpret the content of
models encoded in the Systems Biology Markup Language (SBML) and its
numerical solution. This library is based on the JSBML project and can
be used on every operating system for which a Java Virtual Machine is
available. Please note that this project does not contain any user
interface, neither a command-line interface, nor a graphical user
interface. This project has been developed as a pure programming
library. To support the MIASE effort, it understands SED-ML files. Its
abstract type and interface hierarchy facilitates the implementation of
further community standards, such as CellML.

Please see https://sourceforge.net/projects/simulation-core/for details.

Best regards
The developer team


       Simulation Core NEWS -- History of user-visible changes
======================================================================
Version 1.2 (2012-12-13)
======================================================================

   * New features:

     - A new pom.xml file has been added to the project in order to
       support Maven for this library.

     - The new interface ParameterizedDESystem has been implemented in
       order to facilitate the change of values for some elements of a
       differential equation system.

     - The user can now decide whether to determine the amount or the
          concentration of a species.

     - A wrapper class for the SBML Test Suite has been added.

     - Simulation Core Library now supports all models of the SBML test
       suite (release 23).

     - Import of CSV files is now possible.

     - Distance functions for comparison with experimental data
       are included in the library.

     - KiSAO terms of integration routines are included.

   * Changes in this version:

     - Renamed getNumAdditionalValues in RichDESystem to
       getAdditionalValueCount() in order to be compliant with many
       other Java classes.

     - The processing of the ASTNodes has been improved.

     - The API documentation has been improved.


   * Bug fixes:

     - There was an error in the calculation of the concentration of
       some species: Sometimes the amount was not divided by the
       associated compartment's size.


-- 
Dr. Andreas Dräger
University of Tuebingen
Center for Bioinformatics Tuebingen (ZBIT)
Sand 1
72076 Tübingen
Germany

Phone: +49-7071-29-78982
Fax:   +49-7071-29-5091

____________________________________________________________
To manage your sbml-discuss list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss

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

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

[SED-ML-discuss] 2nd call for papers - Workshop on Interoperability in Scientific Computing

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

2013 Workshop on Interoperability in Scientific Computing
==================================================
In conjunction with ICCS 2013 June 5-7 2013, Barcelona, Spain.
http://www.cs.ox.ac.uk/david.johnson/wisc13/

The 13th annual International Conference on Computational Science (ICCS
2013)
will be held in Barcelona, Spain from 5th - 7th June 2013. ICCS is an ERA
2010
'A'-ranked conference series. For more details on the main conference,
please
visit www.iccs-meeting.org The 2nd Workshop on Interoperability in
Scientific
Computing (WISC '13) will be co-located with ICCS 2013.

Approaches to modelling take many forms. The mathematical, computational
and
encapsulated components of models can be diverse in terms of complexity and
scale, as well as in published implementation (mathematics, source code,
and
executable files). Many of these systems are attempting to solve real-world
problems in isolation. However the long-term scientific interest is in
allowing
greater access to models and their data, and to enable simulations to be
combined
in order to address ever more complex issues. Markup languages, metadata
specifications, and ontologies for different scientific domains have
emerged as
pathways to greater interoperability. Domain specific modelling languages
allow
for a declarative development process to be achieved. Metadata
specifications
enable coupling while ontologies allow cross platform integration of data.

The goal of this workshop is to bring together researchers from across
scientific
disciplines whose computational models require interoperability. This may
arise
through interactions between different domains, systems being modelled,
connecting
model repositories, or coupling models themselves, for instance in
multi-scale or
hybrid simulations. The outcomes of this workshop will be to better
understand the
nature of multidisciplinary computational modelling and data handling.
Moreover we
hope to identify common abstractions and cross-cutting themes in future
interoperability research applied to the broader domain of scientific
computing.

The first instance of this workshop (WISC '11) was successfully held as
part of
the IEEE eScience conference in 2011 in Stockholm, Sweden, where all
accepted papers
were published in the workshops proceedings by the IEEE Computer Society
and
archived on IEEE eXplore. We look forward to your contributions and
participation
in WISC '13.

CALL FOR PAPERS

We invite submissions for high-quality papers (up to 10 pages in length)
within
the context of scientific computing in any of the traditional sciences
(physics,
chemistry, biology), engineering, or scientific/mathematical modelling
applied to
the social sciences and humanities. Papers should address progress, results
or
positions in one or more of the following areas:

* Use of metadata standards for annotating scientific models and data.
* Curating and publishing digital models and data to online repositories.
* Meta-modelling and markup languages for model description.
* Theoretical frameworks for combining disparate models, multi-scale models.
* Using standardised data formats in computational models.
* Domain-specific ontologies for the sciences.

Proceedings of the ICCS 2013 workshops will be published by Elsevier
Science, and
will be made available online through the open-access Procedia Computer
Science.
Selected papers from the conference will be considered for publication in
Elsevier's Journal of Computational Science.

SUBMISSION PROCESS

Authors are invited to submit papers with unpublished, original work of not
more
than 10 pages, as per the rules of Procedia Computer Science. Selected
papers from
the conference will be considered for publication in Elsevier's Journal of
Computational Science.

Templates are available from here:

LaTeX template: http://www.iccs-meeting.org/iccs2013/procedia/ecrc-procs.zip

MS Word template:
http://www.iccs-meeting.org/iccs2013/procedia/ProcediaComputerScience_template.dot

Papers conforming to the above guidelines should be submitted through the
ICCS
online submission system here:

http://www.iccs-meeting.org/iccs2013/papers/upload.php

Note, when submitting your paper please be sure to select the correct
workshop,
otherwise it will not be directed to the workshop organisers.

It is expected that at least one author of each accepted paper attend the
conference
and workshop.

IMPORTANT DATES

Full papers due: 13th January 2013
Notification of acceptance: 10th February 2013
Camera-ready: 1st March 2013
Workshop date: TBC, June 2013

CHAIRS/ORGANISERS

David Johnson (University of Oxford, UK)
Steve McKeever (University of Oxford, UK)

Contact: dav...@cs...

Re: [SED-ML-discuss] Results: Vote for the Nested / Repeated Task

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

Hello Stuart, 

The numbers are: 9/2/2

Frank

On Nov 21, 2012, at 3:28 PM, mo...@eb... wrote:

> HI Frank,
> 
> Out of interest what were the number of votes? Just for the main
> yes/no/revise vote I mean.
> 
> Best wishes,
> 
> Stuart.
> 
>> Dear all,
>> 
>> Thank you so much in participating in the vote on the RepeatedTask. The
>> majority of people was positive about the Nested proposal (version 3). We
>> have summarized the statistics in the attached document.
>> 
>> * 70% of you voted to accept the nested proposal (15% no, 15% revise).
>> 
>> This means that the proposal has been accepted and we (the editors) will
>> prepare a draft of a new specification that includes the proposal.
>> 
>> In the vote we also asked for feedback how you would like the proposal
>> implemented. Here the results:
>> 
>> - There was also a majority of people supporting multiple subtasks (69%).
>> - The executing order of multiple subtasks will be specified by an XML
>> attribute in the future (46%).
>> - There was no clear vote on the Task hierarchy. We will find a way to
>> make the hierarchy work, so that it will not invalidate existing L1V1
>> models.
>> 
>> Additional comments provided:
>> 
>> - While there are some outstanding tweaks to make to the proposal as it is
>> integrated into the SED-ML specification, these won't alter the semantics
>> of the proposal.
>> 
>> - Without something like this  I feel that  sedml will gain little
>> traction by the simulation community.
>> 
>> - It would be good to get something that is going to be more generic, this
>> is very much hard-coded to handling repeated solution of ODEs. In
>> Cooper-Mirams-Niederer (2011) we found we needed a slightly more flexible
>> approach, even to include some minor post-processing at each 'nesting'
>> level. I believe Jonathan Cooper outlined an adaption to this proposal at
>> Combine 2012, and I would prefer to go with that.
>> 
>> - I think there is a better way that avoid using a for loop structure and
>> is declarative rather than the imperative definition provided by the for
>> loop structure.
>> 
>> - I think SED-ML should remain targeted at declaratively representing
>> simulation experiments, not becoming a more general purpose programming
>> language. If people want the power of a general purpose, Turing complete
>> programming language to express complicated protocols that do not already
>> exist in an ontology like KISAO, they should use a general purpose
>> programming language. SED-ML can then be reserved for the case where
>> declarative representation is actually beneficial, which is where
>> structured declarative information about simulation experiments can be
>> applied for multiple different types of analysis and classification.
>> 
>> For more information see also the attached document.
>> 
>> Frank T. Bergmann,
>> on behalf of the SED-ML editors
>> 
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov_______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Results: Vote for the Nested / Repeated Task

[<mo...@eb...>]

HI Frank,

Out of interest what were the number of votes? Just for the main
yes/no/revise vote I mean.

Best wishes,

Stuart.

> Dear all,
>
> Thank you so much in participating in the vote on the RepeatedTask. The
> majority of people was positive about the Nested proposal (version 3). We
> have summarized the statistics in the attached document.
>
> * 70% of you voted to accept the nested proposal (15% no, 15% revise).
>
> This means that the proposal has been accepted and we (the editors) will
> prepare a draft of a new specification that includes the proposal.
>
> In the vote we also asked for feedback how you would like the proposal
> implemented. Here the results:
>
> - There was also a majority of people supporting multiple subtasks (69%).
> - The executing order of multiple subtasks will be specified by an XML
> attribute in the future (46%).
> - There was no clear vote on the Task hierarchy. We will find a way to
> make the hierarchy work, so that it will not invalidate existing L1V1
> models.
>
> Additional comments provided:
>
> - While there are some outstanding tweaks to make to the proposal as it is
> integrated into the SED-ML specification, these won't alter the semantics
> of the proposal.
>
> - Without something like this  I feel that  sedml will gain little
> traction by the simulation community.
>
> - It would be good to get something that is going to be more generic, this
> is very much hard-coded to handling repeated solution of ODEs. In
> Cooper-Mirams-Niederer (2011) we found we needed a slightly more flexible
> approach, even to include some minor post-processing at each 'nesting'
> level. I believe Jonathan Cooper outlined an adaption to this proposal at
> Combine 2012, and I would prefer to go with that.
>
> - I think there is a better way that avoid using a for loop structure and
> is declarative rather than the imperative definition provided by the for
> loop structure.
>
> - I think SED-ML should remain targeted at declaratively representing
> simulation experiments, not becoming a more general purpose programming
> language. If people want the power of a general purpose, Turing complete
> programming language to express complicated protocols that do not already
> exist in an ontology like KISAO, they should use a general purpose
> programming language. SED-ML can then be reserved for the case where
> declarative representation is actually beneficial, which is where
> structured declarative information about simulation experiments can be
> applied for multiple different types of analysis and classification.
>
> For more information see also the attached document.
>
> Frank T. Bergmann,
> on behalf of the SED-ML editors
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov_______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>

[SED-ML-discuss] Results: Vote for the Nested / Repeated Task

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

Dear all,

Thank you so much in participating in the vote on the RepeatedTask. The majority of people was positive about the Nested proposal (version 3). We have summarized the statistics in the attached document.

* 70% of you voted to accept the nested proposal (15% no, 15% revise).

This means that the proposal has been accepted and we (the editors) will prepare a draft of a new specification that includes the proposal.

In the vote we also asked for feedback how you would like the proposal implemented. Here the results:

- There was also a majority of people supporting multiple subtasks (69%).
- The executing order of multiple subtasks will be specified by an XML attribute in the future (46%).
- There was no clear vote on the Task hierarchy. We will find a way to make the hierarchy work, so that it will not invalidate existing L1V1 models.

Additional comments provided: 

- While there are some outstanding tweaks to make to the proposal as it is integrated into the SED-ML specification, these won't alter the semantics of the proposal.

- Without something like this  I feel that  sedml will gain little traction by the simulation community.

- It would be good to get something that is going to be more generic, this is very much hard-coded to handling repeated solution of ODEs. In Cooper-Mirams-Niederer (2011) we found we needed a slightly more flexible approach, even to include some minor post-processing at each 'nesting' level. I believe Jonathan Cooper outlined an adaption to this proposal at Combine 2012, and I would prefer to go with that.

- I think there is a better way that avoid using a for loop structure and is declarative rather than the imperative definition provided by the for loop structure.

- I think SED-ML should remain targeted at declaratively representing simulation experiments, not becoming a more general purpose programming language. If people want the power of a general purpose, Turing complete programming language to express complicated protocols that do not already exist in an ontology like KISAO, they should use a general purpose programming language. SED-ML can then be reserved for the case where declarative representation is actually beneficial, which is where structured declarative information about simulation experiments can be applied for multiple different types of analysis and classification.

For more information see also the attached document.

Frank T. Bergmann, 
on behalf of the SED-ML editors

[SED-ML-discuss] Parameter estimation in SED-ML

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

Dear all,
Over the last two days, a few of the SED-ML editors and COPASI 
developers have been discussing how to extend SED-ML in order to 
represent parameter estimation tasks. We have been working on a Google 
document which records the various use cases we're considering, some of 
the potential complications, and possible ways to structure the 
information needed in SED-ML. The document is open for public editing, 
so please add comments and suggestions there.
Document link: 
https://docs.google.com/document/d/1rrs0fYuKFr4fgL1b7eGwSnaLhRPW6NdXwAaJY0ZN_WY/edit# 

Best wishes,
Jonathan

[SED-ML-discuss] SED-ML meeting in Rostock and Evo

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

Dear SED-ML'er,

a couple of us (Frank Bergmann, Sven Sahle, Brett Olivier and myself) are meeting in Rostock from today to Wednesday to look at the recent results of the KiSAo and nested vote and start the process of bringing those extensions into the specification.

If you would like to meet us remotely to discuss questions related to nested, multiple-tasks, KiSAO... please, join us on Evo: 

http://evo.caltech.edu/evoNext/koala.jnlp?meeting=eleBevv8v2ataII2anIl

Wednesday is mostly for writing the spec.

Here is the link with our preliminary "agenda":

http://www.sbi.uni-rostock.de/research/meetings-events/sed-ml-workshop-2012/

Starting from 2:30pm GMT today we will look at the results of the nested vote (which in general has received positive replies), and discuss about the further schedule for the coming days.

Dagmar

Dagmar Waltemath, Dept. of Systems Biology & Bioinformatics,
University of Rostock, D-18051 Rostock, Germany
Web: http://www.sbi.uni-rostock.de
Skype: dagmar.waltemath

[SED-ML-discuss] SED-ML proposal vote: Nested

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

Dear SED-ML community,

we would like to invite you to vote on the Nested proposal:
SED-ML L1 V1 solely supports uniform timecourse simulations. Instead of 
redefining a large number of simulation types in the future to suit 
various simulation tasks, this proposal suggests a nested simulation 
task that breaks down complex tasks into separate steps.

You can vote on the proposal online at:
https://docs.google.com/spreadsheet/viewform?fromEmail=true&formkey=dEtjNFluTElibEg4WF9MYlhJdmRwdXc6MQ 


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


We'd like to thank you in advance for your time
and for helping with further developing SED-ML.

Dagmar (on behalf of the editors).

[SED-ML-discuss] [Combine-announce] HARMONY 2013 date survey

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

Hello COMBINE communities,

The University of Connecticut Health Center (UCHC) has kindly agreed to host HARMONY 2013, and they would like everyone to help choose the best dates.  Please fill out this short survey:

  http://www.surveymonkey.com/s/QNNV6NX

The deadline for submitting replies is November 1, 2012.

Thank you.
MH
--
Mike Hucka, Ph.D. -- mh...@ca... -- http://www.cds.caltech.edu/~mhucka
Computing and Mathematical Sciences, California Institute of Technology,
Pasadena, California, USA -- Twitter: @mhucka -- Skype: michaelhucka --
You can give me anonymous feedback via http://tinyurl.com/mhuckafeedback

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

[SED-ML-discuss] Summary of nested proposal breakout at COMBINE 2012

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

Dear all,

Dagmar, Frank & I had a discussion at COMBINE 2012 about the nested 
proposal. I'm going to try to summarise it here for the benefit of 
others and posterity. Hopefully as a result we can call a vote on the 
proposal very soon now :)

I emphasise that this is primarily my description of the discussion, but 
Frank and Dagmar have had a chance to check a draft for drastic errors.

The main issues discussed were (at a high level - some had sub-issues):

 1. Whether the proposal is at a stage where it's ready to be voted upon
 2. How to deal with multiple subTasks of a repeatedTask
 3. How to refer to variables in the protocol, in particular referring
    to ranges

There were also a couple of minor issues, which I'll deal with first.

  * The step attribute on oneStep (see
    http://sourceforge.net/mailarchive/message.php?msg_id=29653864).
    Consensus that the current spec means what's written - the step is
    fixed, and will remain so until we support parameterising
    simulations, which can be a separate proposal.
  * I asked about the type="log" attribute on uniformRange, which can be
    done with functionalRange.  Frank explained that the consensus at
    HARMONY was that it's a common use case and a short-hand should be
    provided.  We do need to specify which log in the spec (natural?
    base 10?).


        1. Are we ready to vote?

There are some issues that could do with tidying up (see e.g. below!) 
but the core idea is definitely, in our opinion, something that should 
be added to SED-ML.  It is hence worth voting to get approval for this, 
and we can tidy up loose ends as we prepare the changes for the 
specification, schema, etc.

As a general point, we want to avoid adding more complexity to the 
proposal in the process of tidying up. It's better to have many small 
complementary proposals than one large one. This may imply deferring 
some features in the original proposal to a later stage, if we decide 
that they are not sufficiently well motivated and described at present. 
This also applies to issues discussed below which are not currently part 
of the nested proposal - we do not want to add further features to this 
proposal! On the other hand, I think it is worth considering that if 
there are two potential ways of representing something, and one of those 
allows more possibilities in the future, then it might be better to go 
with that option.


        2. Multiple subTasks of a repeatedTask

The current proposal allows a repeatedTask to have multiple subTasks, 
with a notion of task dependency to allow for ordered execution, but 
doesn't include motivating use cases or examples. (Indeed, only one of 
the examples has a sub-task at all!) Do we need multiple subTasks within 
the nested proposal, or should this feature be deferred for a later 
proposal? This is closely tied to the question of whether (and how much) 
to change the Task class hierarchy in adding repeatedTask.

My talk 
(http://co.mbine.org/events/COMBINE_2012/agenda?q=system/files/2012-08-15-combine-cooper-sedml-proposals.pdf) 
suggested splitting out support for multiple subtasks into another task 
class: CombinedTask.  This would allow (almost) all the issues discussed 
in this section to be considered under a /separate proposal specifically 
for CombinedTask/, and we could proceed with RepeatedTask without 
multiple sub-tasks.  The /only /question remaining for the nested 
proposal under this approach would be whether to make RepeatedTask 
inherit from the current Task, or give them a common base class.

  * Frank's preference is to *extend* SED-ML L1V1 so that the nested
    task could be used in tools *as is*, without requiring a re-design
    of the language.
  * My main concern with this is that if it inherits then it needs to
    have simulationReference and modelReference.
      o There is a use for modelReference as a convenience, although it
        would in principle be possible for tools to use the subTask's
        model (assuming only one subTask; see also below).
      o Including simulationReference allows you to have a short-cut for
        the simple (and probably common) case where you want to repeat a
        task that's just running a given simulation on a given model
        (and not including a subTask at all). On the down side, it
        requires giving an empty simulationReference when you do have a
        subTask, which looks ugly, and means you have to change the
        language schema anyway to allow this.
  * Something I've thought of since: you might in general want multiple
    models referenced in a task, allowing you to (e.g.) parameterise one
    model based on another. But let's not include this in nested!


Several things still need to be figured out when dealing with multiple 
sub-tasks, hence my preference for deferring these to later proposal(s).

  * How to specify dependencies between tasks (and what these mean) - we
    didn't talk about this.
  * How to refer to the results arising from different sub-tasks (slide
    16 of my talk).
  * Which model the parent task refers to (if not given explicitly and
    the sub-tasks use different models).


With modelReference, there's a question over what this means if the 
subTask is a combinedTask with different models for each of /its/ 
subTasks.  Then there could be multiple model references.  I think (as 
alluded to above) that we might need to re-design the referencing scheme 
more widely if we allowed this, for example putting modelReference 
and/or taskReference on the variable element to specify which subTask's 
model you're interested in.  (See also slide 16 of my talk.)  It might 
no longer make sense to use the task's model implicitly when you have a 
variable reference within a task (as opposed to in a dataGenerator or 
model change).

Getting results with multiple sub-tasks is troublesome.  Currently the 
nested proposal leaves this undefined and describes it as a tool issue.  
(It happens anyway with pure repeated tasks, but it's easier to define a 
suitable behaviour here.) I think it's a bad idea in principle to leave 
something undefined and up to implementations in a specification though, 
if you can avoid it - it makes reliable exchange much harder.  Currently 
this just affects how the outputs (plots & results) consume the results; 
if you chain post-processing (see below) it affects that too.  For the 
nested proposal itself, I'd just suggest changing Frank's example for 
what to do with the results into a recommendation for tools to follow.

In summary, we need to make a decision over the class hierarchy, and, if 
we include multiple sub-tasks within the nested proposal, then we need 
some motivating examples and careful consideration of the implications.


        3. Referring to variables in the protocol, in particular
        referring to ranges

The setValue element needs to be able to reference range values in order 
to compute the new value, so it's just a matter of whether you do that 
in a way that allows for other uses too in future proposals.

The nested proposal currently has several alternative mechanisms in the 
spec:

 1. Using an index attribute on functionalRange
 2. Using <variable target="#id">
 3. Using an XPath expression into the SED-ML
 4. Possibly implicitly making all range ids addressable with <ci> in
    the math

We agreed that (3) should be dropped.  It's ugly, and there's great 
potential for confusion with XPath addressing a model.
We also agreed that (4) shouldn't be allowed.

Slide 17 of my talk proposes a variation of (2): adding an idref 
attribute to variable, as an additional alternative to the target 
attribute (just as we have a symbol attribute already). This then 
selects the part of the protocol with that id.

_Examples_
1) In functionalRange:
<functionalRange id="range_function">
     <listOfVariables>
         <variable id="index" idref="range_counter"/>
     </listOfVariables>
     ....

2) In setValue:
<setValue target="...">
     <listOfVariables>
         <variable id="range_value" idref="range_function"/>
     </listOfVariables>
     ....

3) In chaining post-processing (*NB*: I'm *not *suggesting to include 
this in the nested proposal!):
<dataGenerator id="datagen2">
     <listOfVariables>
         <variable id="v" idref="datagen1"/>
     </listOfVariables>
<m:math><m:apply><m:plus/><m:cn>5</m:cn>
         <m:ci>v</m:ci>
     </m:apply></m:math>
</dataGenerator>

And you could still allow option (1), with something like 
<functionalRange id="range_function" range="range_counter"> as a 
short-hand for the common case.  (I've changed the index attribute to be 
called range, for consistency with on repeatedTask itself, and on setValue.)

We discussed what happens if dataGen1 is multidimensional. Currently 
dataGenerators are populated by sweeping through elements, so while 
potentially multidimensional they are not yet.  I term this behaviour an 
implicit map.  Frank wondered if you needed to be able to refer to the 
n'th entry of a dataGenerator with this extension. I don't think we do 
yet - the chained dataGenerator is defined by sweeping through the 
original one, just as the original one sweeps through values of the 
model variable.

We also discussed needing to restrict what could be selected to 
constructs which make sense: probably just ranges and data generators 
(at present). We could reference parameters (all ids are global) but 
it's probably best not to allow referencing parameters of another 
dataGenerator or similar: both because it's harder to implement, and 
because we might want to make ids local in the future.

Chaining dataGenerators is something that only really becomes useful 
when you have more complex functionality in the post-processing, such as 
is allowed by my MathML extensions. My point is just that, given we 
might want something like this in the future, it makes sense for changes 
done now to be done in a way that would make such things easier, unless 
it makes our life more difficult now.

Best wishes,
Jonathan

Re: [SED-ML-discuss] Results of the Algorithm parameter vote

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

Hi,
I intended to write: The exceptional proposal was accepted.
But some letters got lost on the way... ;-)

Dagmar


Dagmar Waltemath, Dept. of Systems Biology & Bioinformatics,
University of Rostock, D-18051 Rostock, Germany
Web: http://www.sbi.uni-rostock.de
Skype: dagmar.waltemath

________________________________________
Von: David Nickerson [dav...@gm...]
Gesendet: Donnerstag, 16. August 2012 23:38
An: sed...@li...
Betreff: Re: [SED-ML-discuss] Results of the Algorithm parameter vote

> The proposal has been excepted as being useful to SED-ML. The results were as follows:

sorry, just need to clarify that the proposal was accepted, not excepted :)


Cheers,
David.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
SED-ML-discuss mailing list
SED...@li...
https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

Re: [SED-ML-discuss] Results of the Algorithm parameter vote

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

> The proposal has been excepted as being useful to SED-ML. The results were as follows:

sorry, just need to clarify that the proposal was accepted, not excepted :)


Cheers,
David.

Re: [SED-ML-discuss] Results of the Algorithm parameter vote

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

> I'd be inclined to keep the name attribute optional too, for consistency 
> with the rest of SED-ML. Surely editors can invent a suitable label if 
> needed?
> 

That works for me, especially since if we are resolving the kisao terms, we definitely have a name there already, so that editors don't even need to be all that creative in finding a suitable label. 

Frank

Re: [SED-ML-discuss] Results of the Algorithm parameter vote

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

Well, to continue the discussion...

One proposal I made at COMBINE yesterday was to add an optional "id" 
attribute to the algorithmParameter.  This will allow for it to be 
referenced from other parts of the proposal, enabling future extensions 
to (for instance) vary algorithm parameters at each iteration of a 
repeatedTask.

I'd be inclined to keep the name attribute optional too, for consistency 
with the rest of SED-ML. Surely editors can invent a suitable label if 
needed?

Best wishes,
Jonathan

On 16/08/2012 21:47, Dagmar Waltemath wrote:
> Dear SED-MLer,
>
> we have now closed the survey regarding the Algorithm parameter extension using KiSAO.
>
> The proposal has been excepted as being useful to SED-ML. The results were as follows:
> We had 11 participants.
> 10 participants voted for "yes"
> 1 participant voted for "revise"; the comment was: I would consider making the human readable attribute "name" a requirement rather than optional. For any tools that are developed to get/set these parameters it would be very helpful to have some sort of name to display.
>
> Going forward we encourage tool developers to support the extension and test it. In the meantime we will prepare an updated specification document and provide examples.
>
> However, accepting this proposal does not mean that the discussion is over, we are looking forward to it (in particular arguments for/against the revise comment are welcome).
>
> Thank you all for your participation.
> Dagmar Waltemath, on behalf of the SED-ML editors.
>
>
>
> Dagmar Waltemath, Dept. of Systems Biology & Bioinformatics,
> University of Rostock, D-18051 Rostock, Germany
> Web: http://www.sbi.uni-rostock.de
> Skype: dagmar.waltemath
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

[SED-ML-discuss] Results of the Algorithm parameter vote

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

Dear SED-MLer,

we have now closed the survey regarding the Algorithm parameter extension using KiSAO.

The proposal has been excepted as being useful to SED-ML. The results were as follows:
We had 11 participants.
10 participants voted for "yes"
1 participant voted for "revise"; the comment was: I would consider making the human readable attribute "name" a requirement rather than optional. For any tools that are developed to get/set these parameters it would be very helpful to have some sort of name to display.

Going forward we encourage tool developers to support the extension and test it. In the meantime we will prepare an updated specification document and provide examples.

However, accepting this proposal does not mean that the discussion is over, we are looking forward to it (in particular arguments for/against the revise comment are welcome).

Thank you all for your participation.
Dagmar Waltemath, on behalf of the SED-ML editors.



Dagmar Waltemath, Dept. of Systems Biology & Bioinformatics,
University of Rostock, D-18051 Rostock, Germany
Web: http://www.sbi.uni-rostock.de
Skype: dagmar.waltemath

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

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

> Actually, I don't think this is the case. As I understand it, the step attribute on oneStep means that for a given oneStep declaration, the output step is fixed, so if you wanted multiple output steps, you have to chain together multiple tasks associated with different oneStep simulations.  That's what lies behind my suggestion to allow the oneStep class to be parameterised by the next output point, so that a setValue within a repeatedTask can set this to the next desired point based on its ranges.
> 

Hmm … well we need to work on the wording in that case … that is certainly how I was implementing the oneStep function :) It would be great to talk some time at COMBINE to talk it through … 

Frank

> Best wishes,
> Jonathan
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

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

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

Hi all,

I agree with Frank here in general, but there is one point I'd like to make:

On 09/08/12 07:39, Frank T. Bergmann wrote:
>>
>>
>> 1) The oneStep simulation element implies a uniform output step size, 
>> which is not what I want.
>>
>
> not true … the oneStep class advances the model to a next output time 
> performing an arbitrary big step (and allows the algorithm specified by 
> KISAO to carry out an unspecified internal number of steps as it needs to 
> in order to achieve this step), so if you like to have values at uneven 
> points you could pass them along quite easily into the onestep class.
>
Actually, I don't think this is the case. As I understand it, the step 
attribute on oneStep means that for a given oneStep declaration, the output 
step *is* fixed, so if you wanted multiple output steps, you have to chain 
together multiple tasks associated with different oneStep simulations.  
That's what lies behind my suggestion to allow the oneStep class to be 
parameterised by the next output point, so that a setValue within a 
repeatedTask can set this to the next desired point based on its ranges.

Best wishes,
Jonathan

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

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

Hello Stuart and Maciej, 

While it is true that the nested proposal in and of itself will not solve all your wishes for PK/PD modeling, it will bring it a large step forward. 

The nested proposal was only made, so as to broaden what could be done with simulation classes. However, it never was meant to be the only thing that needs doing. Remember even though it introduces a oneStep simulation class, as that is what the author needed for the kind of simulation experiments that he does, it is nowhere written that that is the only class that ought to be added. 

I just don't see that *everything* ought to be in one proposal. These things ought to be cleanly separated, so in my mind there ought to be: 

- nested proposal: a way to combine different simulations and tasks 

which is what i proposed three years ago (and where i hope we are at a reasonable point to start using it). And then on top of that: 

- different output variables (to allow accessing implied model variables easily)
- different model classes (to allow storing the end point of one task / simulation as staring point for further experiments)
- additional simulation classes
- access to external data
- additional specialized data generator classes
- different output elements

All that is on the list of things to do … but these things should not be fuddled together and rushed through.

> I agree with Maciej. that the nested proposal is too focused on a specific set of simulation tasks.

as explained above, that is done on purpose … that is all it was meant to do in order to ease adoption … 

> I think you/we need to take a step back and think about solving this problem in a more general way.
> 
> I tried to do create an example PK/PD model using the nested proposal and came across a number of problems.
> 
> 1) The oneStep simulation element implies a uniform output step size, which is not what I want.
> 

not true … the oneStep class advances the model to a next output time performing an arbitrary big step (and allows the algorithm specified by KISAO to carry out an unspecified internal number of steps as it needs to in order to achieve this step), so if you like to have values at uneven points you could pass them along quite easily into the onestep class.


> 2) I need to describe multiple output variables with different time courses. For example in I may be interested in variables Cc at [0.5,4 : 4 : 48,52 : 24 : 192,192 : 4 : 250] and E at 0 : 24 : 288. I could merge the time-points and extract the ones I want for each variable during DataGeneration, but that is describing an implementation of the problem, not the problem itself.
> 

Well .. the above can be done with the nested proposal, but would require one nested task per variable. And that is the reason it was proposed, so this information can be encoded for those people that just want to use a standard format rather than waiting a long time until the community stands behind a standard. 

That does not mean that you could not propose a filtered data generator or any other element to ease your work. But I don't feel it needs to be part of this *general* nested proposal. 

> 3) In addition to the above I need to repeat the simulation for different dosing regimens. For example Dose = 0.25 mg/kg of body weight with the dose administered at at the following time points  0:24:192. There can be multiple dosing regimens with different doses over different time courses. Again I could define these as multiple simulation tasks that start at each dosing time and then superimpose the output. But again that is to describe an implementation.
> 

As hinted at during HARMONY, I'm all for it. In fact I would want to solve this issue separately using a nested task parameterized by external data. However, without having nested experiments I feel wary of adding other proposals.

Cheers
Frank

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

[Stuart M. <mo...@eb...>]

Hi All,

I agree with Maciej. that the nested proposal is too focused on a specific set of simulation tasks. I think you/we need to take a step back and think about solving this problem in a more general way.

I tried to do create an example PK/PD model using the nested proposal and came across a number of problems.

1) The oneStep simulation element implies a uniform output step size, which is not what I want.

2) I need to describe multiple output variables with different time courses. For example in I may be interested in variables Cc at [0.5,4 : 4 : 48,52 : 24 : 192,192 : 4 : 250] and E at 0 : 24 : 288. I could merge the time-points and extract the ones I want for each variable during DataGeneration, but that is describing an implementation of the problem, not the problem itself.

3) In addition to the above I need to repeat the simulation for different dosing regimens. For example Dose = 0.25 mg/kg of body weight with the dose administered at at the following time points  0:24:192. There can be multiple dosing regimens with different doses over different time courses. Again I could define these as multiple simulation tasks that start at each dosing time and then superimpose the output. But again that is to describe an implementation.

Coming across these issues I was reminded of Andrew Millar's posting at the beginning of the year advocating that the nested proposal should be more declarative than it is at the moment (https://sourceforge.net/mailarchive/message.php?msg_id=28697135). I think the problems I have encountered illustrate why this is desirable.

Best wishes,

Stuart.

On 23 Jul 2012, at 10:39, Maciej Swat wrote:

> 
> Hi Frank and list,
> 
> as far I can see, the proposal concentrates around 'simulation' tasks only, at least notation wise,
> which would is quite restrictive from the PK/PD (pharmacokinetics/pharmacodynamics) point of view.
> 
> I would like to mention here tasks, like those supported by population PK/PD software tools (e.g. Monolix)
> 1 - estimation of population parameters
> 2 - estimation of individual parameters
> 3 - estimation of Fisher Information Matrix
> 4 - estimation of log-likelohood
> E.g. 1 & 2 or 1 & 3 are strictly sequential in that order.
> 
> Usually, one would be interested in all these outcomes formulated in a single task or in a specific combination of these.
> 
> Also, in the (clinical trial) simulation domain, there are examples of sequential simulation only tasks, 
> e.g. multiple dosing with dose every 12h. 
> In this scenario 
> step 1. single dose concentration profiles are simulated
> step 2. they are superposed to a multiple-dose time course
> step 3. application of the superposed signal to a PD or SB type of model
> (I could send you some concrete examples if this helps.)
> 
> It's probably a minor correction, but it would be helpful to consider above mentioned scenarios as useful test cases for the proposal development.
> 
> Best Regards,
> Maciej
> 
> 
> On Jun 10, 2012, at 12:43 PM, Frank T. Bergmann wrote:
> 
>> Hello together, 
>> 
>> I have modified my original proposal and added the suggestions made by
>> Nicolas and the discussions at HARMONY 2012. The key changes: 
>> 
>> - instead of a NestedSimultion class a RepeatedTask is used
>> - the SteadyState simulation class is back
>> 
>> The proposal can be found here: 
>> 
>> http://identifiers.org/combine.specifications/sed-ml.proposal.nested-simulat
>> ions.FB.version-3
>> 
>> And an implementation is available with the SED-ML Web Tools: 
>> 
>> http://sysbioapps.dyndns.org/SED-ML_Web_Tools/
>> 
>> where all examples are available to be run. 
>> 
>> 
>> Points for discussion: 
>> --------------------------
>> - Stuart brought up the idea of having subTasks not specifying an order
>> attribute 
>> but instead they would describe the tasks they depend on. The idea being
>> that 
>> this would allow for a potential parallel execution of tasks. 
>> 
>> - Should we have further task subclasses or not? 
>> 
>> I look forward to your comments. 
>> 
>> Cheers
>> Frank
>> 
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

[SED-ML-discuss] Vote for algorithm parameter closes tomorrow

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

Dear colleagues,

this is just a short reminder that the vote for the algorithm parameter 
extension for SED-ML will close tomorrow.

If you haven't done so yet, please vote on:
https://docs.google.com/spreadsheet/viewform?formkey=dDNaeW1SeVhZWjhFMmkzQ2lBWjdCZHc6MA#gid=0 


Dagmar