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

[SED-ML-discuss] SED-ML L1V2 and COMBINE Archive V1 support in VCell

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

We are pleased to announce that VCell 5.3 now includes export to SED-ML L1V2 (official spec) and COMBINE Archive V1 (April 2, 2014 draft spec).  All supported spatial and non-spatial stochastic and deterministic applications and simulations from any VCell BioModel can be exported as a packaged .sedx archive, including parameter overrides and parameter scans.  This includes a full implementation of the SBML L3V1 spatial v0.85 and of jlibsedml revision 390 (to be released as v2.2.0).

Ion I. Moraru, on behalf of the VCell team

Note: VCell 5.3 is not yet officially released to vcell.org, but it is deployed and publicly accessible (link available upon request) 

[SED-ML-discuss] Proposal & Prototype: Accessing data files with SED-ML

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

Hello, 

I would like to propose that at next week's HARMONY, we bring things back to
the roots, and start prototyping what we have been talking about over the
last two years. I went ahead and started to try out what we discussed in the
Google Document: accessing data files in SED-ML. This is done by referencing
a NuML description, and narrowing down the data contained within the files
to what is applicable. I wrote down precisely, what I feel is necessary to
do so. 

http://co.mbine.org/specifications/sed-ml.proposal.accessing-data.version-1.
pdf

If we continue that way at the end of next week we might have a prototype
for parameter estimation as well. Or at the least we could potentially
exchange a simulation experiment referencing data elements as well. 

All the best, hope to see you at HARMONY

Frank

[SED-ML-discuss] Release of libSEDML 0.3.0

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

Just in time for HARMONY 2014 I am pleased to announce the release of
libSEDML 0.3.0, the source of which is available for download from:

https://github.com/fbergmann/libSEDML/releases/tag/v0.3.0

New Features:
- Support for SED-ML L1V2
- Support for Notes / Annotations in both versions
- Support for AddXML / ChangeXML

Bug fixes:
 - sorted issues in supporting both versions and their namespaces
 - numerous improvements

Thanks of course to Sarah Keating, without whom the project would not have
been possible and to Bertrand Moreau for helping to improve the CMake build
and the Python Bindings.

Please report any issues with libSEDML to:

https://github.com/fbergmann/libSEDML/issues

or directly to me.


Thanks
Frank T. Bergmann

P.S: If you prefer there to be binaries available for any specific binding
language / platform, please let me know. 

Re: [SED-ML-discuss] Model identifiers

[Oliver R. <cu...@gm...>]

     Hello,

On Fri, Mar 21, 2014 at 5:56 AM, Nicolas Le Novere <n.l...@gm...>wrote:

> On 21/03/14 09:50, Oliver Ruebenacker wrote:
>
>>
>>       Hello,
>>
>>
>> On Thu, Mar 20, 2014 at 6:05 AM, Nicolas Le Novere <n.l...@gm...<mailto:
>> n.l...@gm...>> wrote:
>>
>>     Examples of versionned URIs:
>>
>>     http://identifiers.org/uniprot/P12345.1
>>     http://identifiers.org/uniprot/P12345.89
>>     http://identifiers.org/uniprot/P12345
>>
>>
>>    But these all refer to the same protein, while different versions of a
>> model are actually different models, or am I missing something?
>>
>
> Different versions of a Uniprot entry refer to the same protein, but can
> contain different or even contradictory information. Same with the model. I
> was merely giving examples of Identifiers.org pointing to versioned
> information.
>

  The age-old question: do these identifiers refer to things (protein,
model, etc) or to records about things? How do identifiers tell us whether
two things are the same?

     Best,
     Oliver


>
>        Best,
>>       Oliver
>>
>>
>>
>>     On 20/03/14 04:34, David Nickerson wrote:
>>      > Hi all,
>>      >
>>      > In several places in the SED-ML L1V2 specification, notably section
>>      > 2.2.2.1, the use of MIRIAM URN's (or URI's) is recommended for
>>      > identifying models. BioModels DB identifiers are used as an
>> example of
>>      > this "best practice". But as far as I know, following discussion at
>>      > COMBINE last year, BioModels DB identifiers are not persistent
>>      > identifiers for the same resource - inasmuch as a particular model
>>      > (SBML document) identified by a given ID can change between
>> releases
>>      > of the BioModels DB.
>>      >
>>      > If my understanding of this is correct (and it could well be very
>> much
>>      > the opposite of correct), then BioModels identifiers suffer the
>> same
>>      > problem as models in the Physiome Repository in that you need to
>> know
>>      > not only what model to use, but what version of the model to use,
>> in
>>      > order to unambiguously identify the model. For models in the
>> Physiome
>>      > Repository this would correspond to the actual version in the
>> history
>>      > of the model and for BioModels DB it would correspond to the
>> database
>>      > release number, I guess.
>>      >
>>      > Now, the Physiome Repository provides URLs for all versions of a
>> given
>>      > model or you can keep the SED-ML document in the same workspace and
>>      > use relative URLs to keep everything at the same version. But we
>> have
>>      > not yet been able to come up with a useful scheme to add this
>>      > repository as a MIRIAM resource.
>>      >
>>      > Does this mean that there are no useful MIRIAM resources which
>> provide
>>      > model identifiers? Should we look at removing that recommendation
>> from
>>      > future SED-ML specifications? or, better to look at how we can
>> define
>>      > MIRIAM resources which do meet the requirements of the first
>> paragraph
>>      > in section 2.2.2.1 of the SED-ML L1V2 specification? Something to
>>      > discuss at HARMONY perhaps...
>>      >
>>      >
>>      >
>>      > Cheers,
>>      > David.
>>      >
>>      > ------------------------------------------------------------
>> ------------------
>>      > Learn Graph Databases - Download FREE O'Reilly Book
>>      > "Graph Databases" is the definitive new guide to graph databases
>> and their
>>      > applications. Written by three acclaimed leaders in the field,
>>      > this first edition is now available. Download your free book today!
>>      > http://p.sf.net/sfu/13534_NeoTech
>>      > _______________________________________________
>>      > SED-ML-discuss mailing list
>>      > SED...@li... <mailto:SED-ML-discuss@lists.
>> sourceforge.net>
>>
>>      > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>      >
>>
>>
>>     --
>>     Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge,
>> CB22 3AT
>>     Tel: +441223496433 <tel:%2B441223496433>   Mob:+447833147074<tel:%2B447833147074>
>> n.l...@gm... <mailto:n.l...@gm...>
>>     orcid.org//0000-0002-6309-7327 <http://orcid.org//0000-0002-6309-7327>
>> http://lenoverelab.org/perso/lenov/
>>
>>     Skype:n.lenovere  twitter:@lenovere http://nlenov.wordpress.com/
>>
>>
>>
>>
>>     ------------------------------------------------------------
>> ------------------
>>     Learn Graph Databases - Download FREE O'Reilly Book
>>     "Graph Databases" is the definitive new guide to graph databases and
>> their
>>     applications. Written by three acclaimed leaders in the field,
>>     this first edition is now available. Download your free book today!
>>     http://p.sf.net/sfu/13534_NeoTech
>>     _______________________________________________
>>     SED-ML-discuss mailing list
>>     SED...@li... <mailto:SED-ML-discuss@lists.
>> sourceforge.net>
>>
>>     https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>>
>>
>>
>> --
>> Oliver Ruebenacker
>> Founder at Relomics Consulting <http://www.relomics.com>
>>
>> Be always grateful, but never satisfied.
>>
>
>
> --
> Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT
> Tel: +441223496433   Mob:+447833147074   n.l...@gm...
> orcid.org//0000-0002-6309-7327  http://lenoverelab.org/perso/lenov/
> Skype:n.lenovere  twitter:@lenovere  http://nlenov.wordpress.com/
>
>
>
>


-- 
Oliver Ruebenacker
Founder at Relomics Consulting <http://www.relomics.com>
Be always grateful, but never satisfied.

Re: [SED-ML-discuss] Model identifiers

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

On 21/03/14 09:50, Oliver Ruebenacker wrote:
>
>       Hello,
>
> On Thu, Mar 20, 2014 at 6:05 AM, Nicolas Le Novere <n.l...@gm... <mailto:n.l...@gm...>> wrote:
>
>     Examples of versionned URIs:
>
>     http://identifiers.org/uniprot/P12345.1
>     http://identifiers.org/uniprot/P12345.89
>     http://identifiers.org/uniprot/P12345
>
>
>    But these all refer to the same protein, while different versions of a model are actually different models, or am I missing something?

Different versions of a Uniprot entry refer to the same protein, but can contain different or even contradictory information. Same with the model. I was merely giving examples of Identifiers.org pointing to versioned information.

>       Best,
>       Oliver
>
>
>
>     On 20/03/14 04:34, David Nickerson wrote:
>      > Hi all,
>      >
>      > In several places in the SED-ML L1V2 specification, notably section
>      > 2.2.2.1, the use of MIRIAM URN's (or URI's) is recommended for
>      > identifying models. BioModels DB identifiers are used as an example of
>      > this "best practice". But as far as I know, following discussion at
>      > COMBINE last year, BioModels DB identifiers are not persistent
>      > identifiers for the same resource - inasmuch as a particular model
>      > (SBML document) identified by a given ID can change between releases
>      > of the BioModels DB.
>      >
>      > If my understanding of this is correct (and it could well be very much
>      > the opposite of correct), then BioModels identifiers suffer the same
>      > problem as models in the Physiome Repository in that you need to know
>      > not only what model to use, but what version of the model to use, in
>      > order to unambiguously identify the model. For models in the Physiome
>      > Repository this would correspond to the actual version in the history
>      > of the model and for BioModels DB it would correspond to the database
>      > release number, I guess.
>      >
>      > Now, the Physiome Repository provides URLs for all versions of a given
>      > model or you can keep the SED-ML document in the same workspace and
>      > use relative URLs to keep everything at the same version. But we have
>      > not yet been able to come up with a useful scheme to add this
>      > repository as a MIRIAM resource.
>      >
>      > Does this mean that there are no useful MIRIAM resources which provide
>      > model identifiers? Should we look at removing that recommendation from
>      > future SED-ML specifications? or, better to look at how we can define
>      > MIRIAM resources which do meet the requirements of the first paragraph
>      > in section 2.2.2.1 of the SED-ML L1V2 specification? Something to
>      > discuss at HARMONY perhaps...
>      >
>      >
>      >
>      > Cheers,
>      > David.
>      >
>      > ------------------------------------------------------------------------------
>      > Learn Graph Databases - Download FREE O'Reilly Book
>      > "Graph Databases" is the definitive new guide to graph databases and their
>      > applications. Written by three acclaimed leaders in the field,
>      > this first edition is now available. Download your free book today!
>      > http://p.sf.net/sfu/13534_NeoTech
>      > _______________________________________________
>      > SED-ML-discuss mailing list
>      > SED...@li... <mailto:SED...@li...>
>      > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>      >
>
>
>     --
>     Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT
>     Tel: +441223496433 <tel:%2B441223496433>   Mob:+447833147074 <tel:%2B447833147074> n.l...@gm... <mailto:n.l...@gm...>
>     orcid.org//0000-0002-6309-7327 <http://orcid.org//0000-0002-6309-7327> http://lenoverelab.org/perso/lenov/
>     Skype:n.lenovere  twitter:@lenovere http://nlenov.wordpress.com/
>
>
>
>
>     ------------------------------------------------------------------------------
>     Learn Graph Databases - Download FREE O'Reilly Book
>     "Graph Databases" is the definitive new guide to graph databases and their
>     applications. Written by three acclaimed leaders in the field,
>     this first edition is now available. Download your free book today!
>     http://p.sf.net/sfu/13534_NeoTech
>     _______________________________________________
>     SED-ML-discuss mailing list
>     SED...@li... <mailto:SED...@li...>
>     https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
>
>
> --
> Oliver Ruebenacker
> Founder at Relomics Consulting <http://www.relomics.com>
> Be always grateful, but never satisfied.


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

Re: [SED-ML-discuss] Model identifiers

[Oliver R. <cu...@gm...>]

     Hello,

On Thu, Mar 20, 2014 at 6:05 AM, Nicolas Le Novere <n.l...@gm...>wrote:

> Examples of versionned URIs:
>
> http://identifiers.org/uniprot/P12345.1
> http://identifiers.org/uniprot/P12345.89
> http://identifiers.org/uniprot/P12345
>

  But these all refer to the same protein, while different versions of a
model are actually different models, or am I missing something?

     Best,
     Oliver


>
> On 20/03/14 04:34, David Nickerson wrote:
> > Hi all,
> >
> > In several places in the SED-ML L1V2 specification, notably section
> > 2.2.2.1, the use of MIRIAM URN's (or URI's) is recommended for
> > identifying models. BioModels DB identifiers are used as an example of
> > this "best practice". But as far as I know, following discussion at
> > COMBINE last year, BioModels DB identifiers are not persistent
> > identifiers for the same resource - inasmuch as a particular model
> > (SBML document) identified by a given ID can change between releases
> > of the BioModels DB.
> >
> > If my understanding of this is correct (and it could well be very much
> > the opposite of correct), then BioModels identifiers suffer the same
> > problem as models in the Physiome Repository in that you need to know
> > not only what model to use, but what version of the model to use, in
> > order to unambiguously identify the model. For models in the Physiome
> > Repository this would correspond to the actual version in the history
> > of the model and for BioModels DB it would correspond to the database
> > release number, I guess.
> >
> > Now, the Physiome Repository provides URLs for all versions of a given
> > model or you can keep the SED-ML document in the same workspace and
> > use relative URLs to keep everything at the same version. But we have
> > not yet been able to come up with a useful scheme to add this
> > repository as a MIRIAM resource.
> >
> > Does this mean that there are no useful MIRIAM resources which provide
> > model identifiers? Should we look at removing that recommendation from
> > future SED-ML specifications? or, better to look at how we can define
> > MIRIAM resources which do meet the requirements of the first paragraph
> > in section 2.2.2.1 of the SED-ML L1V2 specification? Something to
> > discuss at HARMONY perhaps...
> >
> >
> >
> > Cheers,
> > David.
> >
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/13534_NeoTech
> > _______________________________________________
> > SED-ML-discuss mailing list
> > SED...@li...
> > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
> >
>
>
> --
> Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT
> Tel: +441223496433   Mob:+447833147074   n.l...@gm...
> orcid.org//0000-0002-6309-7327  http://lenoverelab.org/perso/lenov/
> Skype:n.lenovere  twitter:@lenovere  http://nlenov.wordpress.com/
>
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>



-- 
Oliver Ruebenacker
Founder at Relomics Consulting <http://www.relomics.com>
Be always grateful, but never satisfied.

Re: [SED-ML-discuss] Model identifiers

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

On Fri, Mar 21, 2014 at 10:39 AM, Nicolas Le Novere
<n.l...@gm...> wrote:
> On 20/03/14 20:18, David Nickerson wrote:
>>> As Nicolas just pointed out, identifiers.org URIs are capable of
>>> reflecting version information if it is part of the identifier.
>>
>> thats good to hear. Currently, however, BioModels DB identifiers do
>> not seem to have made use of that feature though. Is that correct? and
>> hence Camille's suggestion to add a version or release attribute as in
>> intermediate solution? It would probably be better to simply start
>> putting the .version onto the BIOMD identifiers though...e.g.,
>> BIOMD0000000048.12 and promote this usage via the SED-ML
>> specification.
>
> Camille's proposal does not address the problem. If in a SED-ML file we say "use model BIOMDXXX accessed on 01 January 2014", that is absolutely of no help if BioModels Database does not provide a way to access model BIOMDXXX as it was on 01 January 2014. If there is a mean to access BIOMDXXX of 01 January 2014, then this should have a unique identifier.
>

I think the proposal for BioModels would be more like "use BIOMDXXX
from release 12 of the database".

>> The issue with PMR is that the unit of information is a "workspace" -
>> which is a collection of data (CellML models, experimental data,
>> simulation results, SED-ML documents, etc.) - so its a bit harder to
>> identify a specific model or document.
>
> No it is not. This is exactly what the COMBINE archive is for.

I wasn't particularly clear on this, the problem is having a single
identifier similar to BIOMDXXX for PMR which correctly resolves to an
individual CellML document. The use of the COMBINE archive addresses a
different problem, one which isn't an issue at all when using a
workspace - but thats a whole different discussion.

>> If we can do this, then we no longer have a version/release problem
>> with PMR, but there is still a problem with using BioModels DB
>> identifiers until the version/release issue is addressed.
>
> Until the version/release issue is addressed, there is NO solution. It is not an Identifiers.org problem, it is not a SED-ML problem. It is a BioModels Database problem.
>

agreed. The only relation to SED-ML is the misleading promotion of
BioModels DB identifiers as the exemplar in the SED-ML text of the
specification.


Cheers,
David.

Re: [SED-ML-discuss] Model identifiers

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

On 20/03/14 20:18, David Nickerson wrote:
>> As Nicolas just pointed out, identifiers.org URIs are capable of
>> reflecting version information if it is part of the identifier.
>
> thats good to hear. Currently, however, BioModels DB identifiers do
> not seem to have made use of that feature though. Is that correct? and
> hence Camille's suggestion to add a version or release attribute as in
> intermediate solution? It would probably be better to simply start
> putting the .version onto the BIOMD identifiers though...e.g.,
> BIOMD0000000048.12 and promote this usage via the SED-ML
> specification.

Camille's proposal does not address the problem. If in a SED-ML file we say "use model BIOMDXXX accessed on 01 January 2014", that is absolutely of no help if BioModels Database does not provide a way to access model BIOMDXXX as it was on 01 January 2014. If there is a mean to access BIOMDXXX of 01 January 2014, then this should have a unique identifier.

> The issue with PMR is that the unit of information is a "workspace" -
> which is a collection of data (CellML models, experimental data,
> simulation results, SED-ML documents, etc.) - so its a bit harder to
> identify a specific model or document.

No it is not. This is exactly what the COMBINE archive is for.

> If we can do this, then we no longer have a version/release problem
> with PMR, but there is still a problem with using BioModels DB
> identifiers until the version/release issue is addressed.

Until the version/release issue is addressed, there is NO solution. It is not an Identifiers.org problem, it is not a SED-ML problem. It is a BioModels Database problem.

Cheers


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

Re: [SED-ML-discuss] Model identifiers

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

> As Nicolas just pointed out, identifiers.org URIs are capable of
> reflecting version information if it is part of the identifier.

thats good to hear. Currently, however, BioModels DB identifiers do
not seem to have made use of that feature though. Is that correct? and
hence Camille's suggestion to add a version or release attribute as in
intermediate solution? It would probably be better to simply start
putting the .version onto the BIOMD identifiers though...e.g.,
BIOMD0000000048.12 and promote this usage via the SED-ML
specification.

> We do have a data collection for PMR in the Registry, which has been
> sitting in the curation pipeline for the best part of two years. I have
> sent a few emails, and cornered CellML people at various meetings,
> usually COMBINE, to ascertain the best URL to use to access model
> information, but have not yet had any response. All we need to make PMR
> 'live' in the Registry is an access URL using a single identifier, which
> could contain version information.
>
> Right now I have a choice of 3 different styles:
>
> http://models.cellml.org/exposure/210f6601f6461be8443592ff071d2592/baylor_hollingworth_chandler_2002_a.cellml/view
> http://models.cellml.org/e/41/bondarenko_szigeti_bett_kim_rasmusson_2004_apical.cellml/view
> http://models.cellml.org/e/72/

The issue with PMR is that the unit of information is a "workspace" -
which is a collection of data (CellML models, experimental data,
simulation results, SED-ML documents, etc.) - so its a bit harder to
identify a specific model or document. For example, we have settled on
the base http://models.physiomeproject.org/workspace as the root URL
of all new workspaces with a workspace being identified with an
increasing hexadecimal number, e.g.,
http://models.physiomeproject.org/workspace/18a. As you can see, that
just gives you the listing of the contents of that workspace. For
SED-ML to identify a particular model source you need to use the full
URL for the actual CellML model of interest, e.g.,
http://models.physiomeproject.org/workspace/18a/rawfile/7a448e57e44977774884fe670a94732c2464970b/level0.xml.

And then we have "exposures", which are simply a specific revision of
a workspace given a nicer URL and potentially rendered in a more
user-friendly manner (e.g.,
http://models.physiomeproject.org/e/e1/tutorial). The base URL for
exposures is now http://models.physiomeproject.org/e and again each
exposure is identified with an increasing hexadecimal number, e.g.,
http://models.physiomeproject.org/e/e1. When creating exposures, the
user is able to define specific items in the workspace to promote to
the exposure view, which will then define an alias URL, e.g.,
http://models.physiomeproject.org/e/e1/components/stimulated.xml which
will actually resolve into the full URL
http://models.physiomeproject.org/w/andre/HH/@@rawfile/a473227af9cc9fd2990188203c50d434c310aeac/components/stimulated.xml.
So you could imagine using the base exposure URL as the PMR root in
the data collection and the exposure ID as the identifier, e.g.,
http://identifiers.org/pmr/e1. But to use this to identify a model for
use in SED-ML you would still need to use the full URL:
http://identifiers.org/pmr/e1/components/stimulated.xml. I think this
is not a bad way to go...but I have a feeling that there was some
reason why this goes against the philosophy of MIRIAM resources -
probably not an issue if we can accept the workspace as the unit of
information rather than a specific model.

If we can do this, then we no longer have a version/release problem
with PMR, but there is still a problem with using BioModels DB
identifiers until the version/release issue is addressed.

Food for at least one session at HARMONY?

>  From the BioModels side, we are currently working on the JUMMP
> infrastructure which will allow us to capture version information:
> https://bitbucket.org/jummp/jummp/wiki/Home

which will presumably face the same issues as PMR?

> Hope that clarifies the situation a little,

yep, thanks Nick.

Re: [SED-ML-discuss] Model identifiers

[Camille L. <la...@eb...>]

Hi Frank,

>>  From the BioModels side, we are currently working on the JUMMP
>> infrastructure which will allow us to capture version information:
>> https://bitbucket.org/jummp/jummp/wiki/Home
>>
>
> Hello Nick,
>
> is there a publicly available URL for an instance of BioModels running on JUMMP? There has been a biomodels-alpha in 2011 but that one has disappeared since then.
>
> thanks
> Frank

No, there is currently no publicly available instance of BioModels 
Database running on Jummp. However, this should come later this year. We 
will advertise it when ready.

Cheers.

-- 
Camille Laibe
BioModels.net Coordinator
European Bioinformatics Institute (EMBL-EBI), Cambridge, UK

Re: [SED-ML-discuss] Model identifiers

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

> From the BioModels side, we are currently working on the JUMMP 
> infrastructure which will allow us to capture version information: 
> https://bitbucket.org/jummp/jummp/wiki/Home
> 

Hello Nick, 

is there a publicly available URL for an instance of BioModels running on JUMMP? There has been a biomodels-alpha in 2011 but that one has disappeared since then. 

thanks
Frank

Re: [SED-ML-discuss] Model identifiers

[Camille L. <la...@eb...>]

Hi,

I addition to what everything that has been said to far, I think that 
versioning handled properly by the data providers and relying on 
perennial URIs is the best way forward.
Now, if currently most data providers do not handle versioning, instead 
of removing the URIs from the specs, I would suggest adding a 
version/timestamp/release attribute, which could help in the meantime.

Best regards.


On 20/03/14 10:52, N Juty wrote:
> As Nicolas just pointed out, identifiers.org URIs are capable of
> reflecting version information if it is part of the identifier.
>
> We do have a data collection for PMR in the Registry, which has been
> sitting in the curation pipeline for the best part of two years. I have
> sent a few emails, and cornered CellML people at various meetings,
> usually COMBINE, to ascertain the best URL to use to access model
> information, but have not yet had any response. All we need to make PMR
> 'live' in the Registry is an access URL using a single identifier, which
> could contain version information.
>
> Right now I have a choice of 3 different styles:
>
> http://models.cellml.org/exposure/210f6601f6461be8443592ff071d2592/baylor_hollingworth_chandler_2002_a.cellml/view
> http://models.cellml.org/e/41/bondarenko_szigeti_bett_kim_rasmusson_2004_apical.cellml/view
> http://models.cellml.org/e/72/
>
>   From the BioModels side, we are currently working on the JUMMP
> infrastructure which will allow us to capture version information:
> https://bitbucket.org/jummp/jummp/wiki/Home
>
>
> Hope that clarifies the situation a little,
>
> cheers,
>
> Nick
>
>
>


-- 
Camille Laibe
BioModels.net Coordinator
European Bioinformatics Institute (EMBL-EBI), Cambridge, UK

Re: [SED-ML-discuss] Model identifiers

[N J. <ju...@eb...>]

As Nicolas just pointed out, identifiers.org URIs are capable of 
reflecting version information if it is part of the identifier.

We do have a data collection for PMR in the Registry, which has been 
sitting in the curation pipeline for the best part of two years. I have 
sent a few emails, and cornered CellML people at various meetings, 
usually COMBINE, to ascertain the best URL to use to access model 
information, but have not yet had any response. All we need to make PMR 
'live' in the Registry is an access URL using a single identifier, which 
could contain version information.

Right now I have a choice of 3 different styles:

http://models.cellml.org/exposure/210f6601f6461be8443592ff071d2592/baylor_hollingworth_chandler_2002_a.cellml/view
http://models.cellml.org/e/41/bondarenko_szigeti_bett_kim_rasmusson_2004_apical.cellml/view
http://models.cellml.org/e/72/

 From the BioModels side, we are currently working on the JUMMP 
infrastructure which will allow us to capture version information: 
https://bitbucket.org/jummp/jummp/wiki/Home


Hope that clarifies the situation a little,

cheers,

Nick



-- 
--------------------------------------------------------
Nick Juty
BioModels Team
European Bioinformatics Institute (EMBL-EBI)
European Molecular Biology Laboratory
Wellcome Trust Genome Campus
Hinxton
United Kingdom
Cambridge CB10 1SD
--------------------------------------------------------

Re: [SED-ML-discuss] Model identifiers

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

Examples of versionned URIs:

http://identifiers.org/uniprot/P12345.1
http://identifiers.org/uniprot/P12345.89
http://identifiers.org/uniprot/P12345


On 20/03/14 04:34, David Nickerson wrote:
> Hi all,
>
> In several places in the SED-ML L1V2 specification, notably section
> 2.2.2.1, the use of MIRIAM URN's (or URI's) is recommended for
> identifying models. BioModels DB identifiers are used as an example of
> this "best practice". But as far as I know, following discussion at
> COMBINE last year, BioModels DB identifiers are not persistent
> identifiers for the same resource - inasmuch as a particular model
> (SBML document) identified by a given ID can change between releases
> of the BioModels DB.
>
> If my understanding of this is correct (and it could well be very much
> the opposite of correct), then BioModels identifiers suffer the same
> problem as models in the Physiome Repository in that you need to know
> not only what model to use, but what version of the model to use, in
> order to unambiguously identify the model. For models in the Physiome
> Repository this would correspond to the actual version in the history
> of the model and for BioModels DB it would correspond to the database
> release number, I guess.
>
> Now, the Physiome Repository provides URLs for all versions of a given
> model or you can keep the SED-ML document in the same workspace and
> use relative URLs to keep everything at the same version. But we have
> not yet been able to come up with a useful scheme to add this
> repository as a MIRIAM resource.
>
> Does this mean that there are no useful MIRIAM resources which provide
> model identifiers? Should we look at removing that recommendation from
> future SED-ML specifications? or, better to look at how we can define
> MIRIAM resources which do meet the requirements of the first paragraph
> in section 2.2.2.1 of the SED-ML L1V2 specification? Something to
> discuss at HARMONY perhaps...
>
>
>
> Cheers,
> David.
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>


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

Re: [SED-ML-discuss] Model identifiers

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

On 20/03/14 09:26, Pedro Mendes wrote:

> I think the idea of persistent model identifiers is a good one and
> repositories really should follow this and make such IDs stable and
> different from version to version of the model.

I entirely agree, but this is the job of the data providers, i.e. the model database. Versioning is quite high on BioModels Db's todo list.

There are no problems to cover for versions with Identifiers.org URIs. UniProt and Reactome provide versioning for instance. The advised form for dataset identifiers is MAIN_IDENTIFIER.VERSION, with a resulting URI

http://identifiers.org/database/MAIN_IDENTIFIER.VERSION

> On the other hand, my own preference would be to embed the model
> entirely within the SED-ML document. This would have the virtue of
> assuring the existence of the model together with the operations on it.
> (I know it makes the document too long, but is this not just a
> technicality?).

This is being addressed with the COMBINE archive, that contains the models, the simulation descriptions and whatever other information is necessary.

Cheers

> But yes indeed let's discuss this during HARMONY.
>
> best wishes
> Pedro
>
> On 03/20/2014 04:34 AM, David Nickerson wrote:
>> Hi all,
>>
>> In several places in the SED-ML L1V2 specification, notably section
>> 2.2.2.1, the use of MIRIAM URN's (or URI's) is recommended for
>> identifying models. BioModels DB identifiers are used as an example of
>> this "best practice". But as far as I know, following discussion at
>> COMBINE last year, BioModels DB identifiers are not persistent
>> identifiers for the same resource - inasmuch as a particular model
>> (SBML document) identified by a given ID can change between releases
>> of the BioModels DB.
>>
>> If my understanding of this is correct (and it could well be very much
>> the opposite of correct), then BioModels identifiers suffer the same
>> problem as models in the Physiome Repository in that you need to know
>> not only what model to use, but what version of the model to use, in
>> order to unambiguously identify the model. For models in the Physiome
>> Repository this would correspond to the actual version in the history
>> of the model and for BioModels DB it would correspond to the database
>> release number, I guess.
>>
>> Now, the Physiome Repository provides URLs for all versions of a given
>> model or you can keep the SED-ML document in the same workspace and
>> use relative URLs to keep everything at the same version. But we have
>> not yet been able to come up with a useful scheme to add this
>> repository as a MIRIAM resource.
>>
>> Does this mean that there are no useful MIRIAM resources which provide
>> model identifiers? Should we look at removing that recommendation from
>> future SED-ML specifications? or, better to look at how we can define
>> MIRIAM resources which do meet the requirements of the first paragraph
>> in section 2.2.2.1 of the SED-ML L1V2 specification? Something to
>> discuss at HARMONY perhaps...
>>
>>
>>
>> Cheers,
>> David.
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/13534_NeoTech
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>


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

Re: [SED-ML-discuss] Model identifiers

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

Hi David,

I think the idea of persistent model identifiers is a good one and 
repositories really should follow this and make such IDs stable and 
different from version to version of the model.

I think we should keep this in the spec, if anything to promote the 
appearence of such stable identifiers. Removing it from the spec will 
not achieve this goal...

On the other hand, my own preference would be to embed the model 
entirely within the SED-ML document. This would have the virtue of 
assuring the existence of the model together with the operations on it. 
(I know it makes the document too long, but is this not just a 
technicality?).

But yes indeed let's discuss this during HARMONY.

best wishes
Pedro

On 03/20/2014 04:34 AM, David Nickerson wrote:
> Hi all,
>
> In several places in the SED-ML L1V2 specification, notably section
> 2.2.2.1, the use of MIRIAM URN's (or URI's) is recommended for
> identifying models. BioModels DB identifiers are used as an example of
> this "best practice". But as far as I know, following discussion at
> COMBINE last year, BioModels DB identifiers are not persistent
> identifiers for the same resource - inasmuch as a particular model
> (SBML document) identified by a given ID can change between releases
> of the BioModels DB.
>
> If my understanding of this is correct (and it could well be very much
> the opposite of correct), then BioModels identifiers suffer the same
> problem as models in the Physiome Repository in that you need to know
> not only what model to use, but what version of the model to use, in
> order to unambiguously identify the model. For models in the Physiome
> Repository this would correspond to the actual version in the history
> of the model and for BioModels DB it would correspond to the database
> release number, I guess.
>
> Now, the Physiome Repository provides URLs for all versions of a given
> model or you can keep the SED-ML document in the same workspace and
> use relative URLs to keep everything at the same version. But we have
> not yet been able to come up with a useful scheme to add this
> repository as a MIRIAM resource.
>
> Does this mean that there are no useful MIRIAM resources which provide
> model identifiers? Should we look at removing that recommendation from
> future SED-ML specifications? or, better to look at how we can define
> MIRIAM resources which do meet the requirements of the first paragraph
> in section 2.2.2.1 of the SED-ML L1V2 specification? Something to
> discuss at HARMONY perhaps...
>
>
>
> Cheers,
> David.
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>

-- 
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] Model identifiers

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

Hi all,

In several places in the SED-ML L1V2 specification, notably section
2.2.2.1, the use of MIRIAM URN's (or URI's) is recommended for
identifying models. BioModels DB identifiers are used as an example of
this "best practice". But as far as I know, following discussion at
COMBINE last year, BioModels DB identifiers are not persistent
identifiers for the same resource - inasmuch as a particular model
(SBML document) identified by a given ID can change between releases
of the BioModels DB.

If my understanding of this is correct (and it could well be very much
the opposite of correct), then BioModels identifiers suffer the same
problem as models in the Physiome Repository in that you need to know
not only what model to use, but what version of the model to use, in
order to unambiguously identify the model. For models in the Physiome
Repository this would correspond to the actual version in the history
of the model and for BioModels DB it would correspond to the database
release number, I guess.

Now, the Physiome Repository provides URLs for all versions of a given
model or you can keep the SED-ML document in the same workspace and
use relative URLs to keep everything at the same version. But we have
not yet been able to come up with a useful scheme to add this
repository as a MIRIAM resource.

Does this mean that there are no useful MIRIAM resources which provide
model identifiers? Should we look at removing that recommendation from
future SED-ML specifications? or, better to look at how we can define
MIRIAM resources which do meet the requirements of the first paragraph
in section 2.2.2.1 of the SED-ML L1V2 specification? Something to
discuss at HARMONY perhaps...



Cheers,
David.

[SED-ML-discuss] 8th International CellML Workshop - April 14 & 15, Auckland, New Zealand

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

Hi all,

The 8th International CellML Workshop is rapidly approaching on April 14 &
15, to be held at the Goldie Vineyard on Waiheke Island in Auckland's
Hauraki Gulf (http://www.cellml.org/community/events/workshop/2014). Thanks
to the generous support of our sponsors there is no registration charge to
attend the workshop. We are limited in the number of attendees we can fit
in the location, so be sure to register quickly to avoid disappointment.
Registration is available at: http://goo.gl/q3R1JD.

This year the workshop will feature the following topics.

   - The CellML specification status, direction, and future requirements.
   - CellML-related software updates and demonstrations (including the
   CellML API and OpenCOR <http://opencor.ws/>).
   - The Physiome model repository <http://models.physiomeproject.org/> -
   infrastructure plans, updates, user requirements, and future directions.
   - Related standardisation efforts - SED-ML <http://sed-ml.org/>,
SBML<http://sbml.org/>
   , FieldML <http://fieldml.org/>, BioSignalML<http://www.biosignalml.org/>
   .
   - Metadata and data annotation.
   - Mathematical modelling best practices and workflows.

The 8th International CellML Workshop is jointly sponsored by the Auckland
Bioengineering Institute <http://www.abi.auckland.ac.nz/>, the Maurice
Wilkins Centre <http://www.mauricewilkinscentre.org/>, and the Faculty of
Science Initiative for Complex Biological
Systems<http://www.science.auckland.ac.nz/en/about/our-research/research-in-the-faculty-of-science/initiative-for-complex-biological-systems.html>
.


Cheers,
David.

[SED-ML-discuss] CfP: 2nd IEEE Workshop on Interoperability in Scientific Computing

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

2nd IEEE Workshop on Interoperability in Scientific Computing
====================================
http://www.im.uu.se/events/

In conjunction with IEEE COMPSAC July 22-24 2014, Vasteras, Sweden.

The 38th Annual International Computers, Software & Applications
Conference,
sponsored by the IEEE Computer Society and the IEEE Cloud Computing
Initiative, will
be held in Vasteras, Sweden from 21st - 25th July 2014. The 2014 Workshop
on
Interoperability in Scientific Computing (WISC '14) will be co-located with
the main
conference.

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
an increasing
trend in 'Big Data' science is in the long-term interest in allowing
greater access to
and preservation of models and their data, and to enable simulations to be
combined in
order to address ever more complex issues. Model-driven approaches, markup
languages,
metadata specifications, and ontologies 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. These interactions requires the ability to interoperate, and
is
characteristic of 'Big Data' applications that are becoming more prevalent,
even in the
sciences. 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 crosscutting 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 '14.

CALL FOR PAPERS

We invite submissions for high-quality papers within the context of
scientific computing in
any of the traditional sciences (physics, chemistry, biology), engineering,
economics 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
* Model-driven approaches to model and data integration
* Applying standardised data formats in computational models and data
* Domain-specific ontologies for the sciences.

Proceedings of the IEEE COMPSAC workshops will be published by the IEEE
Computer Society,
and will be made available online through IEEE eXplore. Selected papers
from the
workshop will be invited to submit extended versions for consideration for
a special
research topic on Interoperability in Scientific Computing and Health
Informatics to be
published in Frontiers in Physiology in late 2014.

SUBMISSION PROCESS

Authors are invited to submit papers with unpublished, original work of not
more
than 6 pages, as per the Paper Guidelines of the main IEEE COMPSAC
conference (see
http://compsac.cs.iastate.edu/mainconference.php for details). Please
follow the IEEE
Computer Society Press Proceedings Author Guidelines in preparing your
paper. Each accepted
workshop paper is required to be registered at full rate by one of its
authors.

Please submit via EasyChair (
https://www.easychair.org/conferences/?conf=compsac2014) and
take care to select the Workshop on Interoperability in Scientific
Computing track.

IMPORTANT DATES

March 23, 2014: Workshop papers due
April 20, 2014: Workshop paper notifications
April 28, 2014: Camera-ready copy, registration due
Workshop date: TBC, July 2014

CHAIRS/ORGANISERS

David Johnson (Imperial College London, UK)
Steve McKeever (Uppsala University, Sweden)

PROGRAMME COMMITTEE
David Nickerson (University of Auckland, New Zealand)
Jonathan Cooper (University of Oxford, UK)
Steve Harris (University of Oxford, UK)
Rutger Vos (Naturalis Biodiversity Center, The Netherlands)
Dagmar Waltemath (University of Rostock, Germany)
Daniele Gianni (Marconi University, Italy)
Mike Stout (University of Nottingham, UK)

Workshop contact: dav...@im...

Re: [SED-ML-discuss] [[cellml-discussion] ] Announcing the Mathematical Modelling Ontology

[Herbert M S. <hsauro@u.washington.edu>]

Excellent idea, nice to see it happening.

Herbert Sauro

Sent from my iPad

On Feb 11, 2014, at 4:49 AM, Nicolas Le Novere <n.l...@gm...> wrote:

> Dear Colleagues,
> 
> It is our pleasure to introduce the Mathematical Modelling Ontology (MAMO), an effort to describe and classify the mathematical models used in the life sciences (for the time being). MAMO provides the types of models, the variables they use, the readout to expect and other relevant features.
> 
> More information can be found about MAMO on its website
> https://sourceforge.net/projects/mamo-ontology/
> 
> Published versions of MAMO can also be found on the BioPortal
> http://bioportal.bioontology.org/ontologies/MAMO
> 
> We welcome submission of new terms or comment on existing terms, please visit:
> https://sourceforge.net/p/mamo-ontology/tickets/
> 
> To discuss MAMO's aims, usage, structure and development, feel free to sign up to the mailing list:
> https://sourceforge.net/p/mamo-ontology/mailman/mamo-ontology-discuss/
> 
> Minutes of our meetings can be found on Google Drive:
> https://drive.google.com/folderview?id=0B5fUQ08KR7JLNWExajRROTR2TEU&usp=drive_web
> 
> The current version of MAMO has been developed by:
> 
> Nicolas Le Novère, Babraham Institute, Cambridge, UK
> Dagmar Waltemath, Rostock University, Rostock, Germany
> Anna Zhukova, University of Bordeaux, Bordeaux, France
> Yann Le Franc, EU-dat project
> Maciej Swat, EMBL-European Bioinformatics Institute, Cambridge, UK
> Jon Olav Vik, Norwegian University of Life Sciences, Ås, Norway
> 

Re: [SED-ML-discuss] Regarding the attribute "outputStartTime" of "uniformTimeCourse" element.

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

Hi Felix,

You're right that it's not really the most logical place to have that 
information. I think it was done more for convenience! There are several 
challenges with removing it.

 1. The current post-processing support isn't flexible enough to trim
    the output in the way you suggest. There's no support for handling
    the outputs as a vector or array; rather (almost) every operation is
    implicitly mapped over the raw simulation outputs. Or you can view
    them as being applied in a streaming fashion to the data as it is
    returned from the simulator. But you certainly can't express 'just
    give me the data after this point in time.'
 2. For performance reasons, it's convenient for the simulation step to
    know if outputs are not needed for some part. Feeding this
    information back from the post-processing phase would be tricky to
    implement.
 3. We're probably closer to being able to do this using the
    repeatedTask constructs instead, since that would allow you to
    sequence two tasks: one doing the initial step up to when you want
    outputs, and another doing the uniform time course with outputs. But
    you'd need to be able to specify both that you didn't want to record
    outputs from the first task, and that you wanted to record the
    initial conditions for the second task, neither of which is
    currently possible. These might well be useful features to add
    generally, of course.

If we did have enough power in the language to implement either of the 
approaches above, there's still the question of whether having it on 
uniformTimeCourse is still a useful shorthand! This comes down to a 
discussion on what the nature of SED-ML should be, I suspect.

Best wishes,
Jonathan

On 07/02/2014 11:12, Felix Winter wrote:
> Hi everyone,
>
> Since SED-ML L1V1 the element "uniformTimeCourse" contains a mandatory attribute
> "outputStartTime", which is intended to tell the simulation software to suppress
> the output of the simulation before that time. While this seems to be a handy
> feature I fail to see why this is part of the "uniformTimeCourse" element. The
> other attributes and sub-elements of that element are necessary to run the
> simulation and can influence the result. Changing the value of "outputStartTime"
> however does not influence the result of the simulation. Choosing a particular
> part of the result is the first step of post-processing.
>
> If I understand the spec correctly, post-processing should be done in the
> "DataGenerator" element. This element contains the sub-element "math" which
> seems flexible enough to trim the output.
>
> Is there any reason to use "outputStartTime" instead of the "math" element for
> post-processing? If not, I would suggest to remove the "outputStartTime"
> attribute in the next level of SED-ML. Having different steps of post-processing
> scattered over several elements complicates the understanding and use of SED-ML.
> Removing "outputStartTime" would increase the clarity of the language which
> should be a goal for the future development.
>
> Best, Felix
>
> Felix Winter
> Thomas-Müntzer-Platz 63
> 18057 Rostock
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss

[SED-ML-discuss] Announcing the Mathematical Modelling Ontology

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

Dear Colleagues,

It is our pleasure to introduce the Mathematical Modelling Ontology (MAMO), an effort to describe and classify the mathematical models used in the life sciences (for the time being). MAMO provides the types of models, the variables they use, the readout to expect and other relevant features.

More information can be found about MAMO on its website
https://sourceforge.net/projects/mamo-ontology/

Published versions of MAMO can also be found on the BioPortal
http://bioportal.bioontology.org/ontologies/MAMO

We welcome submission of new terms or comment on existing terms, please visit:
https://sourceforge.net/p/mamo-ontology/tickets/

To discuss MAMO's aims, usage, structure and development, feel free to sign up to the mailing list:
https://sourceforge.net/p/mamo-ontology/mailman/mamo-ontology-discuss/

Minutes of our meetings can be found on Google Drive:
https://drive.google.com/folderview?id=0B5fUQ08KR7JLNWExajRROTR2TEU&usp=drive_web

The current version of MAMO has been developed by:

Nicolas Le Novère, Babraham Institute, Cambridge, UK
Dagmar Waltemath, Rostock University, Rostock, Germany
Anna Zhukova, University of Bordeaux, Bordeaux, France
Yann Le Franc, EU-dat project
Maciej Swat, EMBL-European Bioinformatics Institute, Cambridge, UK
Jon Olav Vik, Norwegian University of Life Sciences, Ås, Norway

[SED-ML-discuss] Regarding the attribute "outputStartTime" of "uniformTimeCourse" element.

[Felix W. <wi...@ka...>]

Hi everyone,

Since SED-ML L1V1 the element "uniformTimeCourse" contains a mandatory attribute
"outputStartTime", which is intended to tell the simulation software to suppress
the output of the simulation before that time. While this seems to be a handy
feature I fail to see why this is part of the "uniformTimeCourse" element. The
other attributes and sub-elements of that element are necessary to run the
simulation and can influence the result. Changing the value of "outputStartTime"
however does not influence the result of the simulation. Choosing a particular
part of the result is the first step of post-processing.

If I understand the spec correctly, post-processing should be done in the
"DataGenerator" element. This element contains the sub-element "math" which
seems flexible enough to trim the output.

Is there any reason to use "outputStartTime" instead of the "math" element for
post-processing? If not, I would suggest to remove the "outputStartTime"
attribute in the next level of SED-ML. Having different steps of post-processing
scattered over several elements complicates the understanding and use of SED-ML.
Removing "outputStartTime" would increase the clarity of the language which
should be a goal for the future development.

Best, Felix

Felix Winter
Thomas-Müntzer-Platz 63
18057 Rostock

[SED-ML-discuss] Results of editor election

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

Dear all,

The run-off election has now completed and the results been tallied. It 
was fairly close, but we did have a definite winner with 8 votes. I am 
thus delighted to announce that our two new editors for the next three 
years are:

Sven Sahle (University of Heidelberg)
Ion Moraru (University of Connecticut Health Center)

Many thanks to all of you for voting. On behalf of the editors, I would 
also like to thank David Nickerson and Nicolas le Novere for all their 
contributions as editors over the past years; I'm sure they will 
continue to be involved with future SED-ML developments.

Best wishes,
Jonathan

[SED-ML-discuss] Vote for new SED-ML Editor

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

Dear colleagues,

the vote for the new SED-ML editor closes on the 13th of January.

If you haven't yet voted, please do so at:
https://www.surveymonkey.com/s/3DNXJKF

Thanks a lot!
Have a nice weekend,
Dagmar


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