Re: [cellml-discussion] Mailing list migration

[David Nickerson]

Hi again,

The migration is scheduled to go ahead this weekend. Any messages sent
to the mailing lists during the migration will be queued for delivery
once the migration is complete.

Cheers,
David.

On Tue, May 28, 2013 at 3:20 PM, David Nickerson
 wrote:
> Hi all,
>
> The CellML mailing lists are scheduled to be migrated to a new
> infrastructure from 10am - 5pm on Saturday, 8 June 2013 (NZST). During
> this time the mailing lists will not be available, although any
> messages sent to the lists will be queued for delivery once the
> migration is complete. Following the migration we will have a shiny
> new interface to the mailing lists and their corresponding archives.
>
>
> Cheers,
> David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Mailing list migration

[David Nickerson]

Hi all,

The planned migration did not proceed as expected. An unfortunate
side-effect of this is that the system set up to test the mailing list
migration may have sent you a reminder earlier today. Please disregard
any such reminders you may have received. Hopefully the actual
migration will go ahead this coming weekend.

Thanks,
David.



On Tue, May 28, 2013 at 3:20 PM, David Nickerson
 wrote:
> Hi all,
>
> The CellML mailing lists are scheduled to be migrated to a new
> infrastructure from 10am - 5pm on Saturday, 8 June 2013 (NZST). During
> this time the mailing lists will not be available, although any
> messages sent to the lists will be queued for delivery once the
> migration is complete. Following the migration we will have a shiny
> new interface to the mailing lists and their corresponding archives.
>
>
> Cheers,
> David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] CellML model flattening code

[David Nickerson]

Hi all,

I have just updated Jonathan Cooper's original VersionConverter code
(http://www.cellml.org/tools/translation-utilities) which flattens
hierarchical CellML 1.1 models into single document CellML 1.0 models.
The updated code is available at:
https://github.com/nickerso/flattenCellML. I'm still testing the code
out, but it seems to work so far for me on Mac OSX with the CellML API
1.12 SDK :)

Please feel free to try it out and let me know how it works for you.
You can even submit issues under that project on github
(https://github.com/nickerso/flattenCellML/issues) and I might be able
to help resolve them. Or better yet, fork the repository and help
improve the code!

There is also a tracker item in the CellML API tracker regarding such
a feature being natively available in the API:
https://tracker.physiomeproject.org/show_bug.cgi?id=3575.


Cheers,
Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Mailing list migration

[David Nickerson]

Hi all,

The CellML mailing lists are scheduled to be migrated to a new
infrastructure from 10am - 5pm on Saturday, 8 June 2013 (NZST). During
this time the mailing lists will not be available, although any
messages sent to the lists will be queued for delivery once the
migration is complete. Following the migration we will have a shiny
new interface to the mailing lists and their corresponding archives.


Cheers,
David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Fwd: [Combine-announce] Update on COMBINE 2013

[David Nickerson]

Hi all,

See the message below for some initial details on the programme for
the COMBINE meeting to be held in Paris this September. The website
for the meeting is: http://co.mbine.org/events/COMBINE_2013


Cheers,
Andre.


-- Forwarded message --
From: Nicolas Le Novere 
Date: Fri, May 24, 2013 at 8:31 PM
Subject: [Combine-announce] Update on COMBINE 2013
To: combine-annou...@mbine.org


Dear Colleagues,

The plans for COMBINE forum 2013 are shaping up nicely, thanks to the local
organisers - the bioinformatics unit of Institut Curie - and in particular
Eric Bonnet.

The meeting will start on Monday 16th September, with a scientific
conference. The theme will be the different modelling approaches used in
biology. There will be invited talks, short talks selected from abstracts
and poster sessions. So far, we have confirmation of lectures by:

Vincent Danos (CNRS, Paris-Diderot, Univ Edinburgh, rule-based modelling)
Marc Lavielle (INRIA, Paris-sud, pharmacometrics)
Benjamin Ribba (INRIA, multi-scale modelling of tumours)
Denis Thieffry (ENS, logical modelling)
Andrei Zinovyev (Curie, network analysis)

We are waiting for a couple more confirmations.

This meeting should give us an overview of what we cover or not, and fuel
the dicussions of the subsequent days.  The traditional COMBINE forum will
then take place from Tuesday 17 to Friday 20.

The first day will be open and free for all. It is anticipated that
participation to the remaining workshop will be subjected to the usual
minimal fees.

The registration system is not yet in place, but please book your week, and
spread the word.

Best regards

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



___
Combine-announce mailing list
combine-annou...@ebi.ac.uk
http://listserver.ebi.ac.uk/mailman/listinfo/combine-announce
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Harmony 2013

[David Nickerson]

Hi all,

HARMONY 2013 is coming up in a couple of weeks
(http://www.co.mbine.org/events/HARMONY_2013). Two of the CellML
editors will be present (Jonathan Cooper and myself) at the meeting,
so if any of you are planning on attending and have any CellML-related
topics you would like to discuss, please let us know so we can
schedule some time for such discussions.


Cheers,
David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Fwd: [Combine-discuss] ICSB Tutorial: Modelling and Simulation of Quantitative Biological Models on September 4th, 2013

[David Nickerson]

-- Forwarded message --
From: "Golebiewski, Martin" 
Date: Apr 29, 2013 8:22 AM
Subject: [Combine-discuss] ICSB Tutorial: Modelling and Simulation of
Quantitative Biological Models on September 4th, 2013
To: "combine-disc...@mbine.org" 
Cc:

Dear colleagues,

We cordially invite you to this full-day COMBINE (http://co.mbine.org/)
tutorial workshop:

Modelling and Simulation of Quantitative Biological Models
Wednesday, September 4th, 2013 (9:30 - 17:30)
Copenhagen (at the Technical University of Denmark)

This workshop is a satellite of the 14th International Conference on
Systems Biology (ICSB). You can sign in for the tutorial (free of charge)
when registering for the conference at http://www.icsb2013.dk.


Participants will learn setting-up quantitative computer models of
biological networks using experimental kinetic data and simulating them in
different systems biology platforms. Hands-on sessions, lectures and
software demonstrations will be included providing attendees with the
necessary skills to enable them to access experimental kinetics data from
available resources, assembling computer models with these data and finally
simulating the models within different tools.

The topics will include:
* Using experimental data for setting up quantitative models
* Parameter estimation, optimization and model fitting
* Simulation, analysis and visualization of biochemical models
* Integrated data management and model databases
* Community standards and formats for systems biology models


Covered tools, platforms, databases and standards:

BioModels database: http://www.ebi.ac.uk/biomodels-main/
CellDesigner: http://www.celldesigner.org/
COMBINE: http://co.mbine.org/
COPASI: http://www.copasi.org
JWS Online/OneStop: http://jjj.biochem.sun.ac.za/
SABIO-RK: http://sabio.h-its.org/
SBML: http://sbml.org
SYCAMORE: http://sycamore.eml.org
SysMO-DB: http://www.sysmo-db.org/
Virtual Cell (VCell): http://www.nrcam.uchc.edu/ Virtual Liver SEEK:
http://seek.virtual-liver.de/


Target audience:
Modellers and experimentalists with some basic experience in modelling and
simulation of biological networks.


Tutors:
Martin Golebiewski, Frank Bergmann, Akira Funahashi, Noriko Hiroi, Mike
Hucka, Nicolas Le Novère, Pedro Mendes, Ion Moraru, Sven Sahle, Jacky
Snoep, Dawie van Niekerk, Andreas Weidemann, Katy Wolstencroft


Best regards,

Martin Golebiewski


Phone: +49-6221-533-281
FAX: +49-6221-533-298
Email: martin.golebiew...@h-its.org

HITS gGmbH
Schloss-Wolfsbrunnenweg 35
D-69118 Heidelberg
Germany

http://www.h-its.org

_


Amtgericht Mannheim / HRB 337446
Managing Directors: Dr. h.c. Dr.-Ing. E.h. Klaus Tschira, Prof. Dr.-Ing.
Andreas Reuter



___
Combine-discuss mailing list
combine-disc...@ebi.ac.uk
http://listserver.ebi.ac.uk/mailman/listinfo/combine-discuss
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Fwd: [Combine-announce] HARMONY travel funds

[David Nickerson]

-- Forwarded message --
From: Moraru,Ion 
Date: Mon, Apr 22, 2013 at 9:17 AM
Subject: [Combine-announce] HARMONY travel funds
To: "combine-annou...@mbine.org" 


Dear Colleagues,



This is a reminder that HARMONY 2013 is just one month away.  If you
plan to attend, please make sure to book your hotel and, if needed,
apply for financial support as soon as possible.  See travel info and
details at http://www.co.mbine.org/events/HARMONY_2013



Ion





--
Ion I. Moraru, MD, PhD
Director, High Performance Computing Facility
Associate Professor of Cell Biology
Center for Cell Analysis and Modeling

Cell and Genome Sciences Building, R1635

University of Connecticut Health Center

400 Farmington Ave.

Farmington, CT 06030-6406



Tel: 860-679-2908
Fax: 860-679-1039
Cell: 860-978-8528
Video: 155.37.201.72##1635 (H.323) or 1...@uchc.edu (SIP)
Email: mor...@panda.uchc.edu




___
Combine-announce mailing list
combine-annou...@ebi.ac.uk
http://listserver.ebi.ac.uk/mailman/listinfo/combine-announce
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] OpenCOR 0.1 Released

[David Nickerson]

Hi all,

OpenCOR (http://opencor.ws) is an open source cross-platform modeling
environment which can be used to organise, edit, simulate and analyse
CellML files on Windows, Linux and OS X
(http://opencor.ws/user/supportedPlatforms.html). OpenCOR version 0.1
is now available from http://opencor.ws/download.php.

This first public release of OpenCOR enables users to annotate and
simulate CellML 1.0 and 1.1 models, including models containing ODE
and/or DAE systems which may require non-linear systems to be solved.

The source code for OpenCOR is available via the github opencor
repository: https://github.com/opencor/opencor. Also on github is the
issue tracker (https://github.com/opencor/opencor/issues) showing the
features that will become available in future releases
(https://github.com/opencor/opencor/issues?labels=Feature&page=1&state=open).


Cheers,
Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] CellML Workshop coming up next week

[David Nickerson]

Hi all,

The 7th International CellML Workshop will be running Monday and
Tuesday next week in Auckland, New Zealand. Details for the workshop
are available at:
http://www.cellml.org/community/events/workshop/2013/, including the
workshop programme. We will be using Google Hangouts On Air to
broadcast the workshop live on the Internet, so if you see any talks
in the programme that you would like to watch please feel free to tune
in and hangout with those of us there in person. Details will be
available on the workshop website as the broadcast for each session
comes online, and the recordings will be available via youtube soon
after.


Cheers,
Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Modular Modeling: Standards and Tools. Lucian Smith, Caltech

[David Nickerson]

Hi all,

Lucian Smith will be delivering web-presentation next week on the topic:

Modular Modeling: Standards and Tools. Lucian Smith, Caltech

Friday March 8, 2013 2pm EST (8am Saturday 9th, NZDT)

Model exchange and re-use has been greatly enhanced over the last
decade by the emergence of standard model exchange languages such as
SBML and CellML. Model design and re-use becomes even more tractable
with modularity: larger, more complex models can be built using
well-understood smaller models. CellML has long been modular, and SBML
now has a modularity 'package' which allows modular model
construction. We will present an overview of the capabilities of the
modeling standards and tools that facilitate modular modeling.
(http://antimony.sf.net).


Connection details will be available at:
http://www.imagwiki.nibib.nih.gov/mediawiki/index.php?title=Model_and_Data_Sharing_Working_Group#Presentations


Cheers,
Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Java error on Mac OSX10.8.2

[David Nickerson]

Hi Mark,

This error probably means that you need to install XCode and then from
within XCode you need to install the command line tools - XCode is a
1.3GB download :( With these installed, OpenCell does work on a Mac
(OSX 10.7, at least).

You might want to have a look at OpenCOR (http://opencor.ws), the
replacement for OpenCell and COR - but not yet with all the
functionality available in OpenCell. Hopefully there will be an
initial release of OpenCOR at the CellML workshop next month that has
most of the features of OpenCell implemented.

Cheers,
David.

On Tue, Feb 26, 2013 at 4:37 AM, Mark Cannell
 wrote:
> Hi All
>
> I've been trying to test the new open cell 0.8 on a mac but all I get is a 
> java runtime error and I have no idea how to get over it:
>
> [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) 
> [cellml_servicesICellMLIntegrationService.compileModelODE]"  nsresult: 
> "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: 
> chrome://opencell/content/util/Integration.js :: StartCollectingResults :: 
> line 18"  data: no]
>
> Has anyone run open cell on a mac? I used cor0.8 under a windows emulator and 
> that worked Ok but trying to use an integrated platform/interface for student 
> teaching is not working…
>
> Any ideas?
>
> Thanks
>
> Mark  B. Cannell Ph.D. FRSNZ
> Professor of Cardiac Cell Biology
> School of Physiology&  Pharmacology
> Medical Sciences Building
> University of Bristol
> Bristol
> BS8 1TD UK
>
> mark.cann...@bristol.ac.uk
>
>
>
>
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://lists.cellml.org/mailman/listinfo/cellml-discussion
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Editor election results and call for vote in run-off election

[David Nickerson]

Hi all,

The results from the run-off vote have been validated, and the results
are as follows:

Mike T. Cooling: 13
Andrew Miller:  4

Congratulations to Mike Cooling, the new CellML editor for the term 2013-2015.

Thanks to everyone participating in the election process. The editors
will now focus on getting the 1.2 specification moved forward...


Cheers,
Andre.

On Thu, Jan 31, 2013 at 9:41 AM, David Nickerson
 wrote:
> Hi all,
>
> The results from the recent editor election have been counted and
> validated. The results are as follows:
>
> Mike T. Cooling:   8
> Andrew Miller:  8
> Randy Thomas:7
>
> To resolve the tie, we will be having a run-off election between Mike
> and Andrew to determine the new editor. The run-off vote is now open
> and available at: http://goo.gl/02iwt
>
> Voting will close on February 8 2013.
>
> To be eligible to vote you must be a member of the cellml-discussion
> mailing list (lists.cellml.org/mailman/listinfo/cellml-discussion).
> All members of the mailing list get one vote, and in the case of
> multiple votes the last one is the one that will count (so you can
> vote again to cancel any previous votes).
>
> Thanks,
> David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] 7th International CellML Workshop - accommodation options

[David Nickerson]

Hi all,

I have just updated the workshop webpage with some information on
local accommodation options available at discounted University of
Auckland hotel rates. More information and the booking form is up at:
http://www.cellml.org/community/events/workshop/2013

Also, don't forget to register your intention to attend - head on over
to http://goo.gl/oZuPx to sign up now!!



Cheers,
David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Editor election results and call for vote in run-off election

[David Nickerson]

Hi all,

The results from the recent editor election have been counted and
validated. The results are as follows:

Mike T. Cooling:   8
Andrew Miller:  8
Randy Thomas:7

To resolve the tie, we will be having a run-off election between Mike
and Andrew to determine the new editor. The run-off vote is now open
and available at: http://goo.gl/02iwt

Voting will close on February 8 2013.

To be eligible to vote you must be a member of the cellml-discussion
mailing list (lists.cellml.org/mailman/listinfo/cellml-discussion).
All members of the mailing list get one vote, and in the case of
multiple votes the last one is the one that will count (so you can
vote again to cancel any previous votes).

Thanks,
David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Call for votes: one new CellML Editor for 2013-2015

[David Nickerson]

Final reminder, voting closes Monday - be sure to vote for your
preferred candidate!

http://goo.gl/XY3ww

On Fri, Jan 18, 2013 at 12:03 PM, David Nickerson
 wrote:
> just a reminder: a week left to vote for a new CellML Editor!
>
> http://goo.gl/XY3ww
>
>
> On Tue, Jan 8, 2013 at 9:52 AM, David Nickerson
>  wrote:
>> Hi all,
>>
>> The recent call for nominees for CellML Editor resulted in three
>> eligible nominees, all of whom have accepted their nomination. The
>> vote to select a new CellML editor to serve for the period Jan 2013 -
>> Dec 2015 is now open and available at: http://goo.gl/XY3ww
>>
>> Voting will close on January 28 2013.
>>
>> To be eligible to vote you must be a member of the cellml-discussion
>> mailing list (lists.cellml.org/mailman/listinfo/cellml-discussion).
>> All members of the mailing list get one vote, and in the case of
>> multiple votes the last one is the one that will count (so you can
>> vote again to cancel any previous votes).
>>
>> Thanks,
>> David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] 7th International CellML Workshop - registration now open.

[David Nickerson]

Hi all,

Registration for the 7th International CellML Workshop is now open.
The workshop will be held on the 25 & 26 March 2013 at the Goldie Room
on Waiheke Island, New Zealand. Please see the workshop page for all
the details: 
http://www.cellml.org/community/events/workshop/2013/cellml-workshop-2013.

Registration for the workshop is free and includes return Auckland to
Waiheke ferry transport and transport from the Waiheke ferry terminal
to and from the workshop venue.


Cheers,
David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Call for votes: one new CellML Editor for 2013-2015

[David Nickerson]

just a reminder: a week left to vote for a new CellML Editor!

http://goo.gl/XY3ww


On Tue, Jan 8, 2013 at 9:52 AM, David Nickerson
 wrote:
> Hi all,
>
> The recent call for nominees for CellML Editor resulted in three
> eligible nominees, all of whom have accepted their nomination. The
> vote to select a new CellML editor to serve for the period Jan 2013 -
> Dec 2015 is now open and available at: http://goo.gl/XY3ww
>
> Voting will close on January 28 2013.
>
> To be eligible to vote you must be a member of the cellml-discussion
> mailing list (lists.cellml.org/mailman/listinfo/cellml-discussion).
> All members of the mailing list get one vote, and in the case of
> multiple votes the last one is the one that will count (so you can
> vote again to cancel any previous votes).
>
> Thanks,
> David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Call for votes: one new CellML Editor for 2013-2015

[David Nickerson]

Hi all,

The recent call for nominees for CellML Editor resulted in three
eligible nominees, all of whom have accepted their nomination. The
vote to select a new CellML editor to serve for the period Jan 2013 -
Dec 2015 is now open and available at: http://goo.gl/XY3ww

Voting will close on January 28 2013.

To be eligible to vote you must be a member of the cellml-discussion
mailing list (lists.cellml.org/mailman/listinfo/cellml-discussion).
All members of the mailing list get one vote, and in the case of
multiple votes the last one is the one that will count (so you can
vote again to cancel any previous votes).

Thanks,
David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Call for CellML editor nominations for 2013

[David Nickerson]

Hi all,

Just a reminder that the below call for nominations for CellML editor
closes in a couple of days, so be sure to get your nominations in
before the end of the year!

Cheers,
Andre.


On Wed, Dec 12, 2012 at 7:55 AM, David Nickerson
 wrote:
> Hi all,
>
> Just to clarify, and until we publish an actual description of the
> process for electing CellML editors, there is a stand-down period of
> one year before previous editors become eligible for re-election. So
> while many of you are keen for Edmund to continue as editor he is
> currently not eligible for re-election. Needless to say, he will
> remain involved in the final push to complete the CellML 1.2
> specification process.
>
>
> Cheers,
> Andre.
>
> On Tue, Dec 11, 2012 at 9:43 AM, David Nickerson
>  wrote:
>> Hi all,
>>
>> As per the inaugural election for the CellML Editorial Board, Edmund
>> Crampin's term as editor finishes at the end of this year
>> (http://www.cellml.org/community/editorial_board). In preparation for
>> the election of a new member of the CellML Editorial Board we are
>> soliciting nominations of candidates for CellML Editor for the term
>> January 2013 - December 2015. The nomination form is available here:
>>
>> https://docs.google.com/spreadsheet/viewform?formkey=dFhQUTd5N29VN2hSbDNDT1dxd0tSQ0E6MQ
>>
>> The nomination deadline is 30 December 2012.
>>
>> You may nominate anyone (including yourself) that you believe is
>> qualified and would act as a good CellML editor. You may describe your
>> rationale in the nomination form. You may fill out this form more than
>> once, for nominating multiple individuals.
>>
>> The current CellML editors will gather the results and create a single
>> list of all unique candidates along with the rationales for their
>> nominations, then verify with each individual that they accept the
>> nomination, and finally issue a call for voting. The voting will take
>> place electronically using an online ballot form.
>>
>>
>> Cheers,
>> David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Call for CellML editor nominations for 2013

[David Nickerson]

Hi all,

Just to clarify, and until we publish an actual description of the
process for electing CellML editors, there is a stand-down period of
one year before previous editors become eligible for re-election. So
while many of you are keen for Edmund to continue as editor he is
currently not eligible for re-election. Needless to say, he will
remain involved in the final push to complete the CellML 1.2
specification process.


Cheers,
Andre.

On Tue, Dec 11, 2012 at 9:43 AM, David Nickerson
 wrote:
> Hi all,
>
> As per the inaugural election for the CellML Editorial Board, Edmund
> Crampin's term as editor finishes at the end of this year
> (http://www.cellml.org/community/editorial_board). In preparation for
> the election of a new member of the CellML Editorial Board we are
> soliciting nominations of candidates for CellML Editor for the term
> January 2013 - December 2015. The nomination form is available here:
>
> https://docs.google.com/spreadsheet/viewform?formkey=dFhQUTd5N29VN2hSbDNDT1dxd0tSQ0E6MQ
>
> The nomination deadline is 30 December 2012.
>
> You may nominate anyone (including yourself) that you believe is
> qualified and would act as a good CellML editor. You may describe your
> rationale in the nomination form. You may fill out this form more than
> once, for nominating multiple individuals.
>
> The current CellML editors will gather the results and create a single
> list of all unique candidates along with the rationales for their
> nominations, then verify with each individual that they accept the
> nomination, and finally issue a call for voting. The voting will take
> place electronically using an online ballot form.
>
>
> Cheers,
> David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Call for CellML editor nominations for 2013

[David Nickerson]

Hi all,

As per the inaugural election for the CellML Editorial Board, Edmund
Crampin's term as editor finishes at the end of this year
(http://www.cellml.org/community/editorial_board). In preparation for
the election of a new member of the CellML Editorial Board we are
soliciting nominations of candidates for CellML Editor for the term
January 2013 - December 2015. The nomination form is available here:

https://docs.google.com/spreadsheet/viewform?formkey=dFhQUTd5N29VN2hSbDNDT1dxd0tSQ0E6MQ

The nomination deadline is 30 December 2012.

You may nominate anyone (including yourself) that you believe is
qualified and would act as a good CellML editor. You may describe your
rationale in the nomination form. You may fill out this form more than
once, for nominating multiple individuals.

The current CellML editors will gather the results and create a single
list of all unique candidates along with the rationales for their
nominations, then verify with each individual that they accept the
nomination, and finally issue a call for voting. The voting will take
place electronically using an online ballot form.


Cheers,
David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] 2nd call for papers - Workshop on Interoperability in Scientific Computing

[David Nickerson]

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: david.john...@cs.ox.ac.uk
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] 7th International CellML Workshop - 25 & 26 March 2013

[David Nickerson]

Hi all,

We are pleased to announce that the 7th International CellML Workshop
will be held on the 25th and 26th of March 2013 in Auckland, New
Zealand. More details will be posted to this list and on the website
(http://www.cellml.org/community/events/workshop/2013) as plans
develop.


Cheers,
David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Fwd: [SED-ML-discuss] SED-ML proposal vote: Nested

[David Nickerson]

Please sign up to SED-ML-discuss if you'd like to contribute to this
important decision in the evolution of SED-ML.
(https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss)

Cheers,
David.


-- Forwarded message --
From: Dagmar Waltemath 
Date: Thu, Oct 25, 2012 at 9:57 PM
Subject: [SED-ML-discuss] SED-ML proposal vote: Nested
To: sed-ml-disc...@lists.sourceforge.net


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

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
SED-ML-discuss mailing list
sed-ml-disc...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Solicitation of feedback on CellML 1.2

[David Nickerson]

*Dear all,

At the 5th International CellML
Workshop,
we discussed the main list of features that were desirable to have in
CellML 1.2. The CellML Editorial Board has been discussing the
implementation of these features in regard to the next version of the
CellML standard. Early on, we decided that the entire list of features
arising from the workshop was too broad and far reaching to accommodate an
easy transition from CellML 1.1 to CellML 1.2 in a timely manner. We have
therefore selected a subset of these features which we feel address
immediate shortcomings in the CellML 1.1 specification and introduce a
minimal set of often requested new features.

Tracker item 
55shows
a detailed overview of our current plans. This is by no means meant
to be the final composition of CellML 1.2, but it reflects the current view
of the editorial board as to the types of models users wish to encode in
CellML and what is possible to implement in both the specification and
software tools.

Jonathan Cooper presented our thoughts on CellML 1.2 at the recent COMBINE
2012 meeting . Please see
the slides and video of the presentation to get a more consumable view of
the proposed changes.

This email is to solicit specific feedback from the community regarding the
subset of changes that we have selected for inclusion in CellML 1.2. The
CellML 1.2 specification will mark a significant change in the way the
CellML standard is specified, and we hope that this change will enable a
more rapid process for standardising new features that modellers require in
order to encode and share their models using CellML.

>From tracker item 55,
we would like to highlight the following main changes that we think should
be in CellML 1.2:


   - Remove reaction element (tracker item
49
   );
   - Remove the directional aspect of connections (tracker item
337
   );
   - Replace grouping with a simplified encapsulation-only mechanism (tracker
   item 356 );
   - Delayed variables (introduction of the evaluatedAt operator with
   reduced functionality to allow infinitesimal delays and initial
values) (tracker
   item 70 ).


In addition, we specifically ask for feedback on the issue of moving to
MathML 3.0 (tracker item
67)
and the inclusion of stochastic variation in models (tracker item
2809).
The editors generally agree that switching to MathML 3.0 at this time
provides too little benefit (mathematical clarity) for the cost involved in
making the change (tool support, interoperability with other exchange
formats). While the proposal for stochastic variation is fairly mature, we
feel that it requires further work to meet the requirements for inclusion
in the CellML standard. We also think that given sufficient impetus from
the community this could be one of the first proposals to pass through the
new development process for CellML.

The editorial board will shortly be releasing our proposed guidelines for
the development of the CellML standard. As mentioned above, we hope this
new process will allow new features (such as for stochastic variation in
models) to move more quickly from feature requests through to changes in
the standard specifications.

Thanks,
The CellML Editorial Board.*
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Fwd: [cellml-dev] Tool with partial cellml support

[David Nickerson]

A new tool that might be of interest to those working the field of
cellular electrophysiology...


-- Forwarded message --
From: Michael Clerx 
Date: Sat, Sep 15, 2012 at 6:48 AM
Subject: [cellml-dev] Tool with partial cellml support
To: cellml-tools-develop...@cellml.org


Dear all,

Over the past few months, I've been developing a python-based toolkit
to analyse and simulate electrophysiological cell models:
http://myokit.org

Partial CellML import is provided: only equations are supported, no
reactions, metadata or advanced units. This works fine for most
electrophysiological models found in the cellml database (although it
works even better if you manually rewrite the "pacing" part of the
model to use the native pacing mechanism).

Although it's still a work in progress I thought you might like to add
it to the list on your website.

kind regards,
  Michael

___
cellml-tools-developers mailing list
cellml-tools-develop...@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-tools-developers
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] naive questions about modeling blood-brain barrier and its disruption

[David Nickerson]

Hi Michel,

Thanks for the enquiry. Just because this is a completely new type of
application, to me at least, could you please provide a couple of
pointers to some more information. A quick google shows
http://openrave.org/ - is that the simulation tool that you are
referring to? But I can't find anything obvious for SOFA... And do you
know of any introductory papers or other documents which might provide
a bit of detail as to the mathematics you would like to encode in
CellML for this particular application.

Cheers,
David.

On Thu, Aug 16, 2012 at 7:07 AM, Audette, Michel A.  wrote:
> Dear CellML developers and users,
>
> I would like to write a white paper to the US Dept of Defense that describes 
> how CellML might be combined with SOFA and OpenRave-based robotic therapy 
> simulation, where in particular I would like to leverage your toolkit to 
> model an increase of porosity of the blood-brain barrier, which can be 
> triggered  by ultrasonic energy delivery, as well as the uptake of a drug.
>
> My knowledge of CellML is almost nil, and I'm open to any suggestion.
>
> Best wishes,
>
> Michel
>
> Michel Audette, Ph.D.
> Assistant Professor,
> Department of Modeling, Simulation and Visualization Engineering,
> Old Dominion University,
> Norfolk, VA.
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://lists.cellml.org/mailman/listinfo/cellml-discussion
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Fwd: [sysbio] Reminder: please register for COMBINE 2012

[David Nickerson]

-- Forwarded message --
From: Michael Hucka 
Date: Tue, Jul 10, 2012 at 6:53 AM
Subject: [sysbio] Reminder: please register for COMBINE 2012
To: sys...@caltech.edu


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

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

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

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

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

We hope to see you there!
Gary, Nicolas and Mike

To manage your sysbio list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sysbio

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

For questions or feedback about the sysbio list,
contact bnmc-h...@caltech.edu
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML 1.2 and MathML 3

[David Nickerson]

Hi Andrew,

Thanks for your input. I have a couple of comments that are relevant here.

Firstly, as noted on tracker item 55 for CellML 1.2, the editorial
board is just starting on the process of establishing what changes and
additions will go into CellML 1.2. Please don't view the current state
of tracker items 55
(https://tracker.physiomeproject.org/show_bug.cgi?id=55) and 2886
(https://tracker.physiomeproject.org/show_bug.cgi?id=2886) as final or
in any way set in concrete. The editorial board will announce the
proposed "changeset" for CellML 1.2 once we have it sorted. Part of
such an announcement will be setting out our reasons for the proposed
changes and an invitation for community discussion.

Secondly, as noted previously, the editorial board decided that it
would be best to make CellML 1.2 a relatively minor incremental
release beyond 1.1 in terms of the feature set of the CellML standard
but one which moves us in a direction better suited to future
evolution of the specification. Given such an approach, it is hard to
see how a fundamental change to such a core part of CellML would fit
into CellML 1.2. Hence the current location of MathML 3 under the
future versions rather than specifically 1.2. As noted above, this is
not set in concrete and the editorial board is considering all the
implications of the proposals under both tracker item 55 and 2886. I
would hope that with the release of 1.2 we will be in a position begin
the development of CellML 1.3 (or perhaps 2.0) relatively quickly (at
least at a pace much more rapid than historically shown for previous
versions of CellML).

Finally, it would be best for any specific justifications for the
adoption of specific proposals be added to the tracker item for the
proposal in order to best capture the information in a convenient
location for all to discuss.


Cheers,
Andre.


On Wed, Jun 13, 2012 at 1:05 PM, Andrew Miller  wrote:
> Hi,
>
> I'd like to suggest that using MathML 3 rather than MathML 2 be considered
> in the work to develop CellML 1.2; it is currently in the tracker as an item
> for future versions of CellML. I believe my proposal is well justified for
> the following reasons:
>
> 1. MathML 3 is more mathematically sound than MathML 2. MathML 2 relies on a
> number of poorly documented conventions, and has built in operators that are
> not very comprehensively defined. On the other hand, MathML 3 has two forms,
> strict and non-strict, with well-defined rules for translating from
> non-strict to strict form, and with every symbol in strict form mapping to
> an OpenMath content dictionary to give it mathematical meaning.
>
> 2. The semantics for extending MathML 3 are cleaner are more consistent -
> you use an existing OpenMath content dictionary that covers what you want,
> or define a new content dictionary.
>
> 3. The drafts that I put together (up at
> http://www.cellml.org/Members/miller/draft-secondary-spec-dae-events/toplevel.xhtml)
> are based on the assumption that MathML 3 will be used, as are the draft
> secondary specifications. For example, they refer to content dictionaries.
> This allows for certain things to be defined very easily in the secondary
> specifications, without the need to spell out things like the type semantics
> of operators. For example, my secondary specification draft for models with
> DAEs with events spells out which OpenMath STS types correspond to the
> CellML real type and which ones correspond to boolean, and refers to classes
> of allowed operators by referring to particular content dictionaries. Having
> to repeat all this information explicitly would make secondary
> specifications considerably more messy.
>
> 4. An effort to prototype my CellML 1.2 draft is well under way (code at
> https://github.com/A1kmm/cellml-testbed). This effort is based on MathML 3.
> Implementation experience helps to verify that a draft standard is feasible,
> because the process of implementation can identify issues with a
> specification. There is no corresponding implementation experience that
> combines the other proposed CellML 1.2 changes with MathML 2.
>
> Best wishes,
> Andrew
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://lists.cellml.org/mailman/listinfo/cellml-discussion
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Fwd: [sysbio] Reminder: Please register for HARMONY 2012

[David Nickerson]

-- Forwarded message --
From: Michael Hucka 
Date: Mon, Apr 16, 2012 at 12:26 PM
Subject: [sysbio] Reminder: Please register for HARMONY 2012
To: sys...@caltech.edu


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

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

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

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

Thanks!
--
Mike Hucka, Ph.D. -- mhu...@caltech.edu -- http://www.cds.caltech.edu/~mhucka
Computing and Mathematical Sciences, California Institute of Technology,
Pasadena, California, USA -- Twitter: @mhucka -- Skype: michaelhucka

To manage your sysbio list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sysbio

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

For questions or feedback about the sysbio list,
contact bnmc-h...@caltech.edu
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Open PhD student position in Rostock, Germany

[David Nickerson]

*Doctoral candidate position (PhD student) in Systems Biology/Database and
Information Systems*

Closing date: 1st of May, 2012

Junior research group „Simulation Experiment Management System“ (SEMS) at
the University of Rostock (Germany), Systems Biology and Bioinformatics
group of Prof. Olaf Wolkenhauer. 3yrs full position (TV-L E13), starting
from June 2012.

Area: Systems Biology, Database and Information Systems

The successful applicant for a PhD position will investigate* methods and
techniques for model version control*. Models are here regarded as XML
encodings of computational models of biological systems, annotated with RDF
meta-data. Today, version changes on these models are not sufficiently
stored, maintained, curated, classified and presented to the users of model
databases. This project will enable model version control to ensure
improved reusability of models in the computational biology field.
Knowing of XML and database management systems as well as having a strong
interest in systems biology are prerequisites for this position. Being an
open person, willing to work in a multi-disciplinary field and enjoying to
discuss ideas with collaborators our group will be the perfect
environment


You will find the full job announcement at:
http://www.sbi.uni-rostock.de/jobs/description/13/


Please forward.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Fwd: [Combine-announce] HARMONY 2012 registration is open

[David Nickerson]

-- Forwarded message --
From: Nicolas Le Novère 
Date: Thu, Mar 8, 2012 at 11:27 PM
Subject: [Combine-announce] HARMONY 2012 registration is open
To: combine-annou...@mbine.org


***
                                  Announcing

                            H A R M O N Y  2012

                            May 21-25, 2012
                         Maastricht, The Netherlands

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

***

Dear Colleagues,

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

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

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

 http://harmony2012.eventbrite.com.

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

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

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

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

www.co.mbine.org/events/HARMONY_2012


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

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

___
Combine-announce mailing list
combine-annou...@ebi.ac.uk
http://listserver.ebi.ac.uk/mailman/listinfo/combine-announce
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Registration for the 2012 CellML Workshop is now open

[David Nickerson]

Hi all,

Registration for the 2012 CellML Workshop is now open. Please see
http://www.cellml.org/community/events/workshop/2012 for information
on how to register. Registration for the workshop is free and remote
attendance at the workshop will be possible.


Cheers,
David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Fwd: [sbml-discuss] Draft Distrib Package Proposal

[David Nickerson]

Possibly of interest to some...

-- Forwarded message --
From: Stuart Moodie 
Date: Sat, Jan 7, 2012 at 12:47 AM
Subject: [sbml-discuss] Draft Distrib Package Proposal
To: SBML Discussion List 


Dear All,

I have been pulling together the current thoughts on the distrib package
into a draft proposal document. The document is heavily based on the
outcome of discussions at the Statistical models workshop which took place
in Hinxton on Jun 2011. You can get the document from here:
http://sbml.org/images/1/11/Sbml-level-3-distrib-package-proposal.pdf.

For those of you who are unaware of it the distrib package or
"Distributions and Ranges" to give it its full name provides:
"an extension to SBML Level 3 that supports models that supports variables
that cab take many values, for instance random variables obtained from a
statistical distribution. Applications of the package include for instance
descriptions of the alternative values based on prior knowledge (e.g.
experiments), encoding of uncertainty of value and mostly statistical model
or models that require the use of random values, such as PK/PD models."

There is still a bit or work to do not least because some important issues
remain unresolved (mainly because there has been little discussion about
them). My hope is that this draft will instigate further discussion about
distrib and will lead to the production of a final draft of the proposal in
the coming weeks or months.

As with all the Level 3 package proposals, distrib has its own mailing list
(sbml-dist...@lists.sourceforge.net) and I would urge you to sign up for it
as this will be the main forum for discussion about the package
specification. If you are unsure whether you are subscribed, then I posted
an email to the list at 9:30 GMT today. It's stating the obvious, but if
you didn't receive it then you are probably not subscribed.

Best wishes,

Stuart.
-
Stuart Moodie
Biomodels Team
EMBL-EBI
Hinxton, UK
moo...@ebi.ac.uk


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 sbml-t...@caltech.edu
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Summary of the inaugural CellML Editorial Board meeting

[David Nickerson]

*The CellML Editorial Board (consisting of Jonathan Cooper, Edmund Crampin,
Alan Garny, David “Andre” Nickerson and Poul Nielsen) had their inaugural
meeting on the 8th of December 2011. All members of the board were present.*

David Nickerson was unanimously elected chairman of the editorial board. At
this meeting we discussed the purpose of the CellML editorial board and all
agreed that while there is certainly a role in the guardianship of the
CellML specifications, we are also responsible for growing the CellML
community. To this end, we agreed that it is best to focus immediate
efforts on identifying any barriers preventing adoption of CellML. As such,
the editorial board is embarking on a review of the CellML API and the
CellML model repository in order to identify any existing issues and to
provide guidance for future development of these projects. Establishing the
process by which the CellML specifications will develop was deferred to the
next meeting of the editorial board.

The CellML Editorial Board aim to meet monthly with the next meeting
currently scheduled for the 12th of January 2012.



Cheers,
The CellML Editors.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Improved CellML support in latest version of JSim

[David Nickerson]

Thanks Lucian.

For CelML model developers and curators, I wrote a new section on using
> JSim to help curate the model:
>
> http://physiome.org/jsim/docs/MML_CellML.html#curation
>
>
that looks particularly helpful!
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Improved CellML support in latest version of JSim

[David Nickerson]

Hi all,

JSim 2.05 has just been released and now has improved support for CellML
models. See the release announcement below.

Cheers,
Andre.



Highlights:

o JSim now uses Java 6 rather than Java 5,  resulting in various minor
improvements.  If you're running JSim applets in your browser,  but sure to
update your Java to version 6.

o JSim's CellML importer has been substantially improved (thanks to LS).
JSim now runs 95% of the CellML 1.0 models in the CellML archive out of box
(no editing required).

o Parameter set functionality has been substantially improved, including
the addition of loops, sensitivity and optimization configuration to
parameter sets.

o Various minor fixes and feature improvements.

See the JSim home page for complete information on JSim, including
documentation, downloads, documentation and model repositories:

http://physiome.org/jsim/

For complete details on the latest release, click on "What's New?"
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Announcing the 2012 CellML Workshop

[David Nickerson]

Hi all,

On behalf of the Auckland Bioengineering Institute and the CellML
Editorial Board, I am pleased to announce that the 2012 CellML
Workshop (http://www.cellml.org/community/events/workshop/2012/) will
be held March 12 & 13 2012 at Goldwater Estate, the University of
Auckland vineyard on Waiheke Island. Please save the date and stay
tuned for further updates.


Cheers,
David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Independent variables, and delay

[David Nickerson]

> Would it be helpful to encode this information into the model itself, or
> semantically, do you want to keep them distinct?  I suppose it's edging
> into the SEDML territory of 'what you do with a model' instead of 'what
> the model is'--I can imagine models where you vary the components of the
> strain tensor in one simulation to determine some other value, and in your
> second simulation you vary the other value to determine the strain tensor.

exactly. Furthermore, with CellML 1.1 and modular reuseable models,
you can easily end up with the same variable in a specific component
being an independent or dependent variable depending on how that
component is imported and instantiated into a higher level model.

CellML just gives you a way to encode the mathematics.
Simulation/analysis tools would typically have to analyse the math in
order to work out what needs to be computed, or the user needs to
provide further information to let the tool know what to do with the
math. This is definitely starting to get more towards SED-ML. In the
CellML simulation metadata we explicitly defined the independent
variable for a given simulation (only one was allowed), whereas this
information in not in SED-ML L1V1.

>> > My second question is a bit simpler: ?is there a way to define a delay
>> > equation in CellML and if so, how do you do it? ?(A delay being
>> > something like 'x, 2 seconds ago'.)
>>
>> there is, but its not really used by any real models. The plan is to
>> make things easier in CellML 1.2, but the focus to date has been on
>> the use of instantaneous delays in event descriptions. You can see
>> https://tracker.physiomeproject.org/show_bug.cgi?id=70 and
>> https://tracker.physiomeproject.org/show_bug.cgi?id=1543 for some
>> comments along these lines, and hopefully Andrew or Randall will reply
>> with a better answer for you.
>
> What about tool support?  Is there support in any/some tools for delays?
> I ask from the perspective of a translator, converting models with delays
> from other systems to CellML.

None that I know of. There is some limited support in the CellML API
in terms of the code generation and possibly integration service, but
I'm not sure if that work has been shown to be correct for "real"
models. I seem to recall Andrew and/or Randall had some toy test
models that were getting correct behaviour. But probably best to wait
for Andrew or Randall to comment on this.


Cheers,
David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Independent variables, and delay

[David Nickerson]

Hi Lucian,

On Sat, Dec 17, 2011 at 7:53 AM, Lucian Smith  wrote:
> A couple questions.  One:  is there a defined way in CellML to find the
> independent variables?  The spec says (about 'initial_value'):
>
>  This attribute provides a convenient means for specifying the value of a
>  scalar real variable when all independent variables in the model have a
>  value of 0.0. Independent variables are those whose values do not depend
>  on others.
>
> From that definition, it would seem that if you defined 'pi' in your
> model, the initial value would apply when pi was equal to 0.

This is one of the known problems with using the initial value
attribute to set constants. It is true that setting something like pi
(although there is a mathml constant for pi, btw) using the initial
value attribute is a bit ambiguous. It is therefore now suggested that
numerical constants are set using an equation rather than by the
initial value attribute. See http://models.cellml.org/exposure/d79 for
an example defining fundamental constants in this manner.

> But more generally, if you have a single equation in your model:
>
> u = sin(t)
>
> That's a single equation with two variables--how do you decide that you
> want to vary t and not u?  Do you just apply heuristics, so if you see
> 'dx/dy' you assume y is the independent variable?  Is it part of what you
> do *with* a CellML model, that you present the user with t and u as
> possible options, and they pick one?

in this example, it is impossible to determine the independent
variable without further information. Of course, most tools would
probably assume t is the independent variable. Once you have a bound
variable in the model (MathML bvar element), that determines the
independent variable - this is one reason why some tools require at
least one differential equation in order to be able to run a
simulation.

In some of the tissue mechanics modelling we do we use CellML to
describe constitutive relationships which often are a series of
algebraic equations. In this case we need to define in our simulation
tool what the independent variable(s) are and provide the values for
them (i.e., the components of the strain tensor).

> My second question is a bit simpler:  is there a way to define a delay
> equation in CellML and if so, how do you do it?  (A delay being
> something like 'x, 2 seconds ago'.)

there is, but its not really used by any real models. The plan is to
make things easier in CellML 1.2, but the focus to date has been on
the use of instantaneous delays in event descriptions. You can see
https://tracker.physiomeproject.org/show_bug.cgi?id=70 and
https://tracker.physiomeproject.org/show_bug.cgi?id=1543 for some
comments along these lines, and hopefully Andrew or Randall will reply
with a better answer for you.


Cheers,
David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Fwd: [sbml-discuss] Survey for dates of COMBINE 2012

[David Nickerson]

-- Forwarded message --
From: Michael Hucka 
Date: Tue, Nov 22, 2011 at 9:24 AM
Subject: [sbml-discuss] Survey for dates of COMBINE 2012
To: SBML Discussion List 


SBMLers,

The third COMBINE forum, COMBINE 2012, is being planned as a satellite
workshop of the 13th ICSB in Toronto, Canada. The dates of ICSB will
be August 19-23, 2012. In order to choose the best possible dates for
COMBINE, we are running a survey of the COMBINE community. Please help
us by filling the very short survey form at this URL:

 http://www.surveymonkey.com/s/combine-2012-date-survey

On behalf of the COMBINE coordinators:
Gary Bader
Mike Hucka
Nicolas Le Novère

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 sbml-t...@caltech.edu
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] IEEE e-Science 2011 WISC Call for Participation

[David Nickerson]

IEEE e-Science 2011 WISC Call for Participation
---
The 7th IEEE International Conference on e-Science (e-Science 2011),
to be held in Stockholm, Sweden, during 5-8 December 2011, will bring
together leading international and interdisciplinary research
communities, developers, and users of e-Science applications and
enabling IT technologies. The Workshop on Interoperability in
Scientific Computing will be held on the morning of Monday 5th of
December, and is co-located with the main conference.

We have selected three high-quality papers for presentation at the
workshop. They are:

* Requirements Engineering for Scientific Computing: a Model-based
Approach by Yang Li, Matteo Harutunian, Nitesh Narayan, Bernd Bruegge
and Gerrit Buse.
* Achieving Semantic Interoperability Between Physiology Models and
Clinical Data by Bernard de Bono, Stephen John Sammut and Pierre
Grenon.
* A Profile of Today's SBML-Compatible Software by Michael Hucka,
Frank T. Bergmann, Sarah M. Keating and Lucian P. Smith.

The workshop is scheduled to take place from 09:00am to 10:30am on
Monday December 5, 2011, in Breakout Room 1 of the Stockholm City
Conference Centre. See http://www.cs.ox.ac.uk/david.johnson/wisc11/
for details of the workshop, and http://www.escience2011.org for full
conference details and to register.


WORKSHOP ORGANISATION


Organisers/Chairs
-
David Johnson, Steve McKeever (University of Oxford, UK)

Programme Committee
---
David Nickerson (University of Auckland, New Zealand)
Herbert Sauro (University of Washington, USA)
Steve Harris (University of Oxford, UK)
Jonathan Cooper (University of Oxford, UK)
Rutger Vos (University of Reading, UK)
Dagmar Waltemath (University of Rostock, Germany)
Daniele Gianni (European Space Agency)
Mike Stout (University of Nottingham, UK)
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] cellml-discussion Digest, Vol 87, Issue 10

[David Nickerson]

Hi Maxwell,

If you wrap the MathML into a CellML model/component, COR does a good
job generating Matlab. OpenCell should work as well. Actually, I think
OpenCell might be able to generate all the variables for you from the
equation, whereas in COR you might also have to create the variables
before it will let you export to Matlab.

Cheers,
David.

On Tue, Oct 25, 2011 at 7:58 AM, Maxwell Neal  wrote:
> Hi all,
>
> Does anyone know of a good java package for translating MathML into MATLAB?
> Many thanks,
>
> M
>
> -
> Maxwell Neal
>
> Post-doctoral researcher
> University of Washington
> mn...@uw.edu
> (206) 543-8769
> -
>
>
>
>
> On Oct 23, 2011, at 4:00 PM, cellml-discussion-requ...@cellml.org wrote:
>
>> Send cellml-discussion mailing list submissions to
>>       cellml-discussion@cellml.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>       http://lists.cellml.org/mailman/listinfo/cellml-discussion
>> or, via email, send a message with subject or body 'help' to
>>       cellml-discussion-requ...@cellml.org
>>
>> You can reach the person managing the list at
>>       cellml-discussion-ow...@cellml.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of cellml-discussion digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Re: cellml-discussion Digest, Vol 87, Issue 9 (Maxwell Neal)
>>
>>
>> --
>>
>> Message: 1
>> Date: Sat, 22 Oct 2011 19:02:16 -0700
>> From: Maxwell Neal 
>> Subject: Re: [cellml-discussion] cellml-discussion Digest, Vol 87,
>>       Issue 9
>> To: cellml-discussion@cellml.org
>> Message-ID: <28198366-57cf-471f-8882-34e73fc05...@u.washington.edu>
>> Content-Type: text/plain; charset=us-ascii
>>
>> Great. Thanks, Lucian and David.
>>
>> M
>>
>> -
>> Maxwell Neal
>>
>> Post-doctoral researcher
>> University of Washington
>> mn...@uw.edu
>> (206) 543-8769
>> -
>>
>>
>>
>>
>> On Oct 22, 2011, at 4:00 PM, cellml-discussion-requ...@cellml.org wrote:
>>
>>> Send cellml-discussion mailing list submissions to
>>>      cellml-discussion@cellml.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>      http://lists.cellml.org/mailman/listinfo/cellml-discussion
>>> or, via email, send a message with subject or body 'help' to
>>>      cellml-discussion-requ...@cellml.org
>>>
>>> You can reach the person managing the list at
>>>      cellml-discussion-ow...@cellml.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of cellml-discussion digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>  1. Re: nested components in CellML (David Nickerson)
>>>
>>>
>>> --
>>>
>>> Message: 1
>>> Date: Sat, 22 Oct 2011 14:30:37 +1300
>>> From: David Nickerson 
>>> Subject: Re: [cellml-discussion] nested components in CellML
>>> To: CellML Discussion List 
>>> Message-ID:
>>>      
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> On Sat, Oct 22, 2011 at 10:10 AM, Lucian Smith  
>>> wrote:
>>>> * Maxwell Neal  [2011-10-21 22:03] writes:
>>>>> Hi all,
>>>>>
>>>>> I was wondering - can CellML models have nested components? ?That is, are 
>>>>> there instances where some model component is a component in another 
>>>>> model component?
>>>>> Thanks,
>>>>
>>>> Yes--this is covered by the concept of encapsulation. ?See
>>>> http://www.cellml.org/getting-started/tutorials/tutorial/best_practice/#grouping
>>>> for more detail, but basically you set up a whole tree of nested
>>>> components, and this nesting determines the rules for how you can connect
>>>> the variables in those components.
>>>>
>>>> Also, an imported component from another file that encapsulates other
>>>> components brings those components (and corresponding connections) w

Re: [cellml-discussion] nested components in CellML

[David Nickerson]

On Sat, Oct 22, 2011 at 10:10 AM, Lucian Smith  wrote:
> * Maxwell Neal  [2011-10-21 22:03] writes:
>> Hi all,
>>
>> I was wondering - can CellML models have nested components?  That is, are 
>> there instances where some model component is a component in another model 
>> component?
>> Thanks,
>
> Yes--this is covered by the concept of encapsulation.  See
> http://www.cellml.org/getting-started/tutorials/tutorial/best_practice/#grouping
> for more detail, but basically you set up a whole tree of nested
> components, and this nesting determines the rules for how you can connect
> the variables in those components.
>
> Also, an imported component from another file that encapsulates other
> components brings those components (and corresponding connections) with
> it in the import.
>
> Is that a reasonable summary, list denizens?

yep, I think that summarises it nicely. Importing along with
encapsulation allows the definition of models where some components
are components from another model.


Cheers,
Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] ABI CellML Meeting Minutes, 14th September 2011

[David Nickerson]

> Regarding the link to SED-ML web-tools: Both do work for me right now, maybe 
> one was temporarily down...

yep - apparently a bit of a problem with the server/DNS that Frank has
now sorted out.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] ABI CellML Meeting Minutes, 14th September 2011

[David Nickerson]

> I saw that you are providing a SED-ML file together with your Lorenz 
> attractor model http://models.cellml.org/e/7f.
>
> I tried to run the example, and it does work perfectly on SED-ML web tools on 
> http://sysbioapps.dyndns.org/SED-ML%20Web%20Tools.
> I tried also the validators on SED-ML web tools 
> (http://sysbioapps.dyndns.org/SED-ML%20Web%20Tools/Home/Validate) and on CSBE 
> (http://www.sbsi.ed.ac.uk/html/sedml/index.html) and there seems to be a 
> problem with duplicated identifiers in the SED-ML file.
>
> I thought it would be nice to fix this to avoid confusion on the user side 
> when they validate the SED-ML file.

just to add that the SED-ML web tools provide a function to
automatically "fix" common errors, including duplicated ID's.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Fwd: [Combine-announce] COMBINE mailing lists

[David Nickerson]

-- Forwarded message --
From: Nicolas Le Novère 
Date: Sun, Sep 18, 2011 at 5:36 AM
Subject: [Combine-announce] COMBINE mailing lists
To: combine-annou...@mbine.org


Dear Colleagues,

Some of you may not have attended the last day of COMBINE2011, and may not
be aware of new means of communication for this community. We set-up three
mailing lists:

To receive announcements from COMBINE, subscribe to:
combine-annou...@mbine.org
This list if very low flux, and members should not normally post on it.
(Note that the main list of each of the core COMBINE standards is already
subscriber, which is why you receive this message).

To discuss the goals, organization and operation of COMBINE, subscribe to:
combine-disc...@mbine.org.
This list is open to all.

To report issues about the co.mbine.org website, send a mail to
combine-supp...@mbine.org.
You cannot subscribe to this list, but only post message.

Best regards,

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

___
Combine-announce mailing list
combine-annou...@ebi.ac.uk
http://listserver.ebi.ac.uk/mailman/listinfo/combine-announce
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML API 1.10rc1 available now

[David Nickerson]

> This release candidate will become the CellML API 0.10 if no-one finds any
> problems with it by next Wednesday (New Zealand time).

I guess the first problem is that should be 1.10 ? :)

but seriously, given most of the usual testers are at COMBINE this
week, I'd extend that deadline by at least one week, but more likely
two, if you would like any actual testing by users to happen.


Cheers,
Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] IEEE e-Science 2011 Workshop on Interoperability in Scientific Computing

[David Nickerson]

IEEE e-Science 2011 Workshop on Interoperability in Scientific Computing

5th December 2011, Stockholm, Sweden.
http://www.cs.ox.ac.uk/david.johnson/wisc11/
**FULL PAPERS DUE: MONDAY 18th JULY 2011**

The seventh IEEE e-Science conference, sponsored by the IEEE Computer
Society's Technical Committee for Scalable Computing (TCSC), will be
held in Stockholm, Sweden from 5th - 8th December 2011. The Workshop
on Interoperability in Scientific Computing will be held on the
morning of Monday 5th of December, and is 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 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.

FINAL CALL FOR PAPERS

We invite submissions for high-quality papers (up to 8 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

It is expected that the proceedings of the e-Science 2011 workshops
will be published by the IEEE Computer Society Press, USA, and will be
made available online through the IEEE Digital Library.

SUBMISSION PROCESS

Authors are invited to submit papers with unpublished, original work
of not more than 8 pages of double column text using single spaced 10
point size on 8.5 x 11 inch pages, as per IEEE 8.5 x 11 manuscript
guidelines.

Templates are available from here:
http://www.ieee.org/web/publications/pubservices/confpub/AuthorTools/conferenceTemplates.html.

Authors should submit a PDF or PostScript (level 2) file that will
print on a PostScript printer. Papers conforming to the above
guidelines should be submitted through the EasyChair submission system
here:
https://www.easychair.org/account/signin.cgi?conf=wisc11

Note, papers should NOT be submitted to the main e-Science 2011 paper
submission system, as they will not be directed to the workshop
organisers.

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

IMPORTANT DATES

**FULL PAPERS DUE: MONDAY 18th JULY 2011**
Notification of acceptance: 18th August 2011
Camera-ready: 16th September 2011
Workshop date: 5th December 2011

CHAIRS/ORGANISERS

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

PROGRAMME COMMITTEE

David Nickerson (University of Auckland, New Zealand)
Herbert Sauro (University of Washington, USA)
Steve Harris (University of Oxford, UK)
Jonathan Cooper (University of Oxford, UK)
Rutger Vos (University of Reading, UK)
Dagmar Waltemath (University of Rostock, Germany)
Daniele Gianni (European Space Agency)
Mike Stout (University of Nottingham, UK)
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Workshop on Interoperability in Scientific Computing

[David Nickerson]

IEEE e-Science 2011 Workshop on Interoperability in Scientific Computing

5th December 2011, Stockholm, Sweden.
http://www.comlab.ox.ac.uk/david.johnson/wisc11/

The seventh IEEE e-Science conference, sponsored by the IEEE Computer
Society's Technical Committee for Scalable Computing (TCSC), will be
held in Stockholm, Sweden from 5th - 8th December 2011. The Workshop
on Interoperability in Scientific Computing will be held on the
morning of Monday 5th of December, and is 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 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.

CALL FOR PAPERS

We invite submissions for high-quality papers (up to 8 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

It is expected that the proceedings of the e-Science 2011 workshops
will be published by the IEEE Computer Society Press, USA, and will be
made available online through the IEEE Digital Library.

SUBMISSION PROCESS

Authors are invited to submit papers with unpublished, original work
of not more than 8 pages of double column text using single spaced 10
point size on 8.5 x 11 inch pages, as per IEEE 8.5 x 11 manuscript
guidelines.

Templates are available from here:
http://www.ieee.org/web/publications/pubservices/confpub/AuthorTools/conferenceTemplates.html.

Authors should submit a PDF or PostScript (level 2) file that will
print on a PostScript printer. Papers conforming to the above
guidelines should be submitted through the EasyChair submission system
here:
https://www.easychair.org/account/signin.cgi?conf=wisc11

Note, papers should NOT be submitted to the main e-Science 2011 paper
submission system, as they will not be directed to the workshop
organisers.

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

IMPORTANT DATES

Full papers due: Monday 18th July 2011
Notification of acceptance: 18th August 2011
Camera-ready: 16th September 2011
Workshop date: 5th December 2011

CHAIRS/ORGANISERS

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

PROGRAMME COMMITTEE

David Nickerson (University of Auckland, New Zealand)
Herbert Sauro (University of Washington, USA)
Steve Harris (University of Oxford, UK)
Jonathan Cooper (University of Oxford, UK)
Rutger Vos (University of Reading, UK)
Dagmar Waltemath (University of Rostock, Germany)
Daniele Gianni (European Space Agency)
Mike Stout (University of Nottingham, UK)
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Fwd: [sbml-discuss] About the upcoming votes on L3 package proposals

[David Nickerson]

This is maybe something we want to work through and adopt in regard to
the secondary specifications to be included in CellML 1.2.


-- Forwarded message --
From: Mike Hucka 
Date: Fri, May 20, 2011 at 10:58 AM
Subject: [sbml-discuss] About the upcoming votes on L3 package proposals
To: sbml-disc...@caltech.edu


Dear SBML community,

Many SBML Level 3 packages have been proposed. Until recently, the
procedure for package acceptance was not fully elaborated, but the
SBML Editors have made progress on this front:

 http://sbml.org/Documents/SBML_Development_Process/SBML_Development_Process_for_SBML_Level_3

The process involves voting on proposals for Level 3 package,
something that has long been discussed but never actually implemented.
 We believe this step is important to achieve community consensus;
however, it also presents a problem, in that many long-proposed
packages did not receive the same kind of community vote that new
packages will receive from now on.  Therefore, in order that *all*
package proposals be treated equally and fairly, we are now
implementing a round of voting on all Level 3 package proposals.  The
goal of each vote is to reach consensus on whether the SBML community
believes (a) the need addressed by each proposed package is something
that should be addressed by SBML, and (b) whether the general approach
proposed by each package proposal is appropriate and desirable. This
is step 3 in the SBML Level 3 package proposal development process
described at the URL above.

Over the next couple of weeks, we will issue calls for electronic
votes on a dozen or so package proposals. In addition, in order to
expedite the entire process, we have pre-formed the Package Working
Group mailing lists for each existing package proposal.  The
forthcoming voting forms will allow you to sign up for the relevant
list right away, if you are interested in pursuing more detailed
discussions with the package developers and other interested parties.

We hope everyone will participate in this important process.

Thank you,
The SBML Editors

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 sbml-t...@caltech.edu
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] CellML Workshop 2011 programme now available

[David Nickerson]

Hi all,

The initial programme for the 2011 CellML workshop is now available:
http://www.cellml.org/community/events/workshop/2011/workshop-programme

You can also find the details required to attend the workshop remotely
using the EVO software:
http://www.cellml.org/community/events/workshop/2011/remote-attendance.
Please note that we are not currently planning on broadcasting the
discussion sessions unless there is interest in doing so. If you are
interested, please let me know or be in the EVO meeting room on the
day.


Cheers,
David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Registration for the 2011 CellML workshop is now open

[David Nickerson]

Registration for the upcoming CellML 2011 workshop is now open. Please
register at: http://www.cellml.org/community/events/workshop/2011/registration.
Registration is free for all participants. It will be possible to
present and participate in the workshop virtually - so don't worry if
you are not able to make it to Auckland for the event, you can still
take part!

If you are looking for a nice layover to break up your journey to New
York for HARMONY (http://www.biopax.org/harmony.php), consider
dropping by for a bit of pre-HARMONY hacking :-)

Full details about the workshop will be available at:
http://www.cellml.org/community/events/workshop/2011


We look forward to welcoming you to Auckland, New Zealand.


Cheers,
David Nickerson, on behalf of the organisers.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Announcing the 2011 CellML workshop

[David Nickerson]

This is the first announcement for the 2011 CellML Workshop
(http://www.cellml.org/community/events/workshop/2011).  We plan to
hold a two day meeting at The University of Auckland from 11th-12th
April. If you are interested in attending this event please mark these
dates in your calendar. More details will be available in the near
future.


Cheers,
David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] COMETS 2011 - 2nd International Track on Collaborative Modeling and Simulation - CfP

[David Nickerson]

ecision to paper authors: April 4, 2011
* Final version of accepted papers due to IEEE: April 29, 2011
* Conference dates: June 27 - June 29, 2011



Organizing Committee


* Andrea D'Ambrogio, University of Roma TorVergata, Italy
* Daniele Gianni, European Space Agency, The Netherlands
* Joachim Fuchs, European Space Agency, The Netherlands
* Giuseppe Iazeolla, University of Roma TorVergata, Italy

+
Program Committee
+

* Santiago Balestrini, Georgia Institute of Technology, USA
* Torsten Bieler, European Space Agency, The Netherlands
* Olivier Dalle, University of Nice Sophia Antipolis, CNRS & INRIA, France
* Joseph Giampapa, SEI, Carnegie Mellon University, USA
* Ralph Huntsinger, Beijng University of Aeronautics and Astronautics, China
and California State University, USA
* Axel Lehmann, Universitaet der Bundeswehr Muenchen, Germany
* Cristiano Leorato, Rhea, The Netherlands
* Brian Lewis, Vanguard Software Corporation, USA
* Steve McKeever, University of Oxford, UK
* David Nickerson, Auckland Bioengineering Institute, NZ
* Alfred Park, IBM T.J. Watson Research Center, USA
* Wolfgang Prinz, Fraunhofer FIT and RWTH Aachen, Germany
* José L. Risco-Martin, Universidad Complutense de Madrid, Spain
* Maarten Sierhuis, NASA and Palo Alto Research Center, USA
* Hans Vangheluwe, University of Antwerp, Belgium, and McGill University, Canada
* Gabriel Wainer, Carleton University, Canada
* Quirien Wijnands, European Space Agency, The Netherlands
* Heming Zhang, Tsinghua University, China

*** Contact Information ***
Daniele Gianni (track co-chair)
Email: daniele.gia...@esa.int
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Schematic diagram

[David Nickerson]

Hi Felix,

The diagrams in the repository are all drawn by hand - using Adobe
Illustrator, I think. The source format is SVG and I think there is a
collection of template objects that are used to create the diagrams
which should be available. Perhaps Dougal might be able to help if
that might be useful for you...


Cheers,
Andre.


On Wed, Oct 13, 2010 at 3:06 AM, Gerardo Felix Martinez
 wrote:
> Hi all.
>
> I just want to ask, how are the schematic diagrams shown in the cellml model 
> repository made? I'm just starting to use cellml, but i would like to make 
> diagrams like that for my models. Thanks for your help.
>
> Felix.
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://lists.cellml.org/mailman/listinfo/cellml-discussion
>
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] ABI CellML Meeting Minutes, 21st April 2010

[David Nickerson]

I think what Alan might be getting at, and something that I am also
concerned with, is that rather than letting the "solver do its job",
we are going down the route of replacing the well tested and supported
IDA initial condition solver with something that is perhaps better
suited to the types of models generally expressed in CellML. It would
be good to see the data which supports the decision to go down this
route as well as ensuring that CCGS and CIS can be used with the
default IDA initial condition solver if the user so chooses.


Cheers,
Andre.

On Tue, Apr 27, 2010 at 8:16 AM, Randall Britten
 wrote:
> From what I understand, this is exactly what Andrew is setting up.
>
> Regards,
> Randall
>
> On 26/04/2010, at 8:17 PM, "Alan Garny"  wrote:
>
>> Then, the approach that I would personally take (and the one that I people
>> take when solving ODE models, though I accept things might be different
>> with
>> DAE models!) is to start from the original ICs and let the solver do its
>> job. Now, I imagine there might be cases where user changes to some of the
>> parameters are such that the original ICs might not be suitable at all?
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Announcement of OpenCell 0.7rc3

[David Nickerson]

Hi Justin,

Does this also serve notice that there is a version 1.7 release
candidate of the API available for testing as well?

Thanks,
Andre.

On Fri, Mar 12, 2010 at 6:34 PM, Justin Marsh  wrote:
> Hi all,
>
> The third release candidate for OpenCell version 0.7 has been released.
>
> More information, and the released files themselves, are available at
> http://www.cellml.org/tools/downloads/opencell/releases/0.7rc3
> or alternatively, from SouceForge at
> https://sourceforge.net/projects/cellml-opencell/files/
>
> A release candidate will become a release one week from announcement on this
> list if there are no problems identified with it.
>
> Please report any bugs you find at https://tracker.physiomeproject.org/,
> or to this list, or directly to me at j.ma...@auckland.ac.nz
>
> Best regards,
> Justin Marsh.
>
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] ABI CellML meeting minutes 2009-09-30

[David Nickerson]

> I cc:ed Ion as I must confess I didn't follow developments on VCell neither.
> Maybe he could state on how things evolved.
>
> Additionally, Richard Adams at Edinburgh University did some work on Java
> library development for SED-ML.
> It is all at:
> http://miase.svn.sourceforge.net/viewvc/miase/sed-ml/jlibsedml/
> There also is an online SED-ML file validator at:
> http://www.bioinformatics.ed.ac.uk:8080/SBSVisualWebApp/html/sedml/
> Richard said, it is all still preliminary, but we were discussing on
> continuing the development,
> so maybe it would be a good idea to get in contact with him - so as not to
> do things twice...
> I also cc:ed Richard :-)

thanks Dagmar (and Richard for the correction), if I get a chance I'll
be having a look - although my Java is not particularly strong.

> SED-ML would allow you [being in Auckland] to send me [being in Rostock] the
> *description* of what you did, so that I can launch a simulation tool and
> repeat the steps you did.
> If you want to reuse the simulation data ("results"), you probably want to
> use efforts such as SBRML from Pedro Mendes' group to do so
> (http://www.comp-sys-bio.org/tiki-index.php?page=SBRML).
> You could include a reference to a result data set encoded in SBRML in your
> SED-ML file (as a note only, currently) to refer to the result data from
> your simulation description.
> ... if that is what you want ... :-)

yep. it will certainly be interesting to see how this evolves -
whether people actually want to share results or if you always want to
re-run the simulation in your own tool :)


Cheers,
Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] ABI CellML meeting minutes 2009-09-30

[David Nickerson]

Hi Dagmar,

Thanks for your comments! I'll just make a couple of notes inline below...

>   * Andre said that SED-ML does not yet support everything that we
>     need to do for simulation and graphing.
>
> I agree that SED-ML still is at quite an early stage and might not cover
> everything needed.
> However, even if the structure of SED-ML does not offer particular
> constructs for some of your needs, you are allowed (by definition of the
> SED-ML schema) to attach annotations to *any* SED-ML element. Thus, you
> could "extend" SED-ML towards supporting whatever additional needs you might
> have for information to put in the simulation description file.
> Do you think that would be sufficient? As Nicolas mentioned, that would
> actually be a nice benchmark for us to see in what way SED-ML needs to be
> extended (certainly by what you would put in the annotations often).

I agree. The way forward here is to start using SED-ML with CellML
models and see how things work out and what possible extensions are
required, and also whether these can be incorporated through the
existing annotation mechanism. I know that at least myself and maybe
others have volunteered to do this at some point, but I have yet to
sit down and do it :) We are also hoping that a core SED-ML supporting
library or tool might become available that we could work with in
order to implement support for CellML. From the Waiheke meeting, Ion
offered to make the VCell code available but I haven't had a chance to
follow up on this.

>   * Andrew said that we are still trying to convince the SED-ML group
>     to separate out graphing and simulation.
>
> I can say that SED-ML is *not* about graphing at all - in the sense that I
> understand graphing. SED-ML should provide the description of the data that
> is used to create the output, and also how these data relate, e.g. for a 2
> dimensional plot you would have to specify what to plot against what (x and
> y axes). Let me cite Nicolas again from an earlier mail: "E.g. we can create
> a report {time, var1, var2}, but some information will only emerge if we
> "plot" var1 versus var2. In some sense the relationship between var1 and
> var2 representation is part of the post-processing."

related to the point below, but what I think this is hinting at is
that we prefer to see a distinction between describing and performing
a simulation and processing/extracting/manipulating/graphing the
resultant data. I don't see this as a major sticking point at present
but rather something that will evolve over time if we can get the SBML
and CellML communities using a common simulation experiment
description framework.

>   * Andre said that you might want to change some of the graphing
>     metadata to get different graphs from the same simulation, or vice
>     versa.
>
> If we are talking about running one simulation and creating a number of
> different graphs (say, many 2D plots) from that simulation, this is already
> possible in SED-ML right now. All you have to do is to define a number of
> (what we call) data generators, referring to the variables/parameters you
> want to use for your output. Then you can define as many outputs as you
> want, referring to the same or different data generators and to the same of
> different simulation setups.
> If you look at the example given in the publication of CMSB 2008, on page
> 9/10 (http://www.springerlink.com/content/n67n137071431xt7/), we defined a
> data generator called "time" and we use it to create 2 different curves from
> one single simulation (only the x axis is varying here, using 2 different
> models).
>
> If we, however, are talking about producing the same graph one time with a
> red line, one time with a green line - those things are not part of SED-ML
> core information, and they should go to the above mentioned annotations.

no, what this is addressing that modellers should be able to reuse
different parts of the simulation experiment description without
needing to redefine it. For example, here in Auckland I define an
experiment using the Hodgkin-Huxley model with a certain stimulus
protocol and produce some action potentials. Now you over in Rostock
want to use that data to produce some current-voltage data. It would
be great if you were able to make use of my simulation description and
its resultant data without having to redefine the simulation
description locally or perhaps even re-running the simulation. I'm not
sure if this is already something that SED-ML can include, but it is
certainly something that we'd be keen to see in the future.

In terms of actually defining the presentation of specific outputs
(lines on a graph, surfaces, points, etc), this again is something
that we are very keen on in order to be able to unambiguously and
completely describe outputs from a simulation experiment. This is not
a small problem, although the current CellML graphing metadata begins
to address this in regard to specific types of outputs. As above, w

Re: [cellml-discussion] Auto-generate HDF5 from CellML?

[David Nickerson]

> I'm considering HDF5 for my storage needs in simulating a CellML model under
> multiple parameter scenarios. HDF5 is designed for efficient storage,
> retrieval, navigation and subsetting of huge data sets [1], with annotation
> [2].

> [2] http://www.hdfgroup.org/training/HDFtraining/UsersGuide/MF_Annot.fm1.html

this has been confusing me for a while, until I just realised that the
link [2] actually refers to a HDF4 user guide.

So without looking too far into it, I'm guessing that maybe object
attributes in HDF5
(http://www.hdfgroup.org/HDF5/doc/H5.intro.html#Intro-OAttributes)
have replaced the types of annotations discussed in [2]. Can anyone
confirm this? or suggest an alternative method to annotate specific
data objects in HDF5?


Thanks,
Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Auto-generate HDF5 from CellML?

[David Nickerson]

On Sat, Nov 15, 2008 at 3:55 PM, Jon Olav Vik <[EMAIL PROTECTED]> wrote:
> Alan Garny <[EMAIL PROTECTED]> writes:
>> > I think the searching should be performed with the CellML models
>> > rather than the HDF5 data files. The CellML models containing the
>> > various parametrizations of full models will contain a lot more useful
>> > data to query. You can then search your model archive for simulation
>> > descriptions (model instantiations) that meet certain criteria and can
>> > then retrieve the corresponding simulation data from the HDF5 data
>> > file. I'm currently not in favour of duplicating parameter values in
>> > the HDF5 data groups...but not sure about this yet :)
>>
>> Duplication of information in any form or shape should be prohibited in my
>> view. That's a recipe for disaster at some point down the line.
>
> Yes, but there needs to be *some* way of identifying the information in the
> HDF5 file, like "using parameter values as indexes". A purist solution might 
> be
> to have each simulation result annotated with the URI for that particular
> parameter set and model. However, any analysis would then require running back
> and forth between the CellML model (DOM API, metadata, ...) and the huge 
> output
> files (e.g. HDF5). Until the CellML tools (DOM, code generation, ...) fit
> seamlessly into more mainstream tools, I'd prefer not to lug around the CellML
> DOM API everywhere I take my data. (No offense. 8-)

but doesn't this get back to the issue of needing all the information
like units in the HDF5 data file also? If you'd prefer to have an HDF5
data file that can be unambiguously interpreted without reference to
the source CellML models and/or simulations, then that is a whole lot
more data that would need to be in the data file

if you want to interpret the data in the file without needing to go
back and forth with the CellML models then I'd guess you probably want
to add some tool-specific data to the HDF5 group that gets generated
by the proposed tool/service...or not. Maybe the below has convinced
me that this could be done in a nice way...

> I was thinking of this extra annotation as "write once, read many", just
> labelling the boxes. There exist external tools for exploring HDF5 files,
> http://www.hdfgroup.org/hdf-java-html/hdfview/
> and these will be a lot less useful if the data structure doesn't indicate
> which parameters a result is for. (That said, it might be useful to verify the
> integrity of the link between model, parameters and output e.g. by some kind 
> of
> hashing.)

This sounds more like you are after a complete translation of the
source models and simulations into HDF5. For a given model you'd have
a list of all the "unique" variables in the model annotated with a
string containing the full expansion of the variable's units into the
set of base units, and the variable's value field - which would be a
scalar for constant parameters and an array for dynamic variables. I
guess you'd also want some kind of reference to the index field (i.e.,
time). Not sure if you'd also want to keep track of all the actual
variables in the model that are used for each of the unique variables
in the simulation instantiation, but that could be done.

In such a tool you'd still lose a lot of the annotation in the source
CellML models. But I guess if you simply want an optimised data store
the above should give you everything you need and if required in
special cases you can also link back to the CellML models as there
should still be some URI's stored somewhere in the HDF5 data file. Of
course, if you want to do all this nice and quickly you'd likely
ignore the units anyway if you know that all your simulations are in
compatible or identical units so they can be left back in the CellML
model and can be looked up if needed.

One consideration with such a solution is that I have found the HDF5
packet table interface to be about the most efficient way to stream
simulation data to a persistent store. I have one packet table per
simulation and use the model variable URI's to set up a mapping into
that packet table for each dynamic variable. So rather than using the
variable field of dynamic variables for an array, it is probably more
efficient to set it up as an index or something into the packet
tablesounds like it should be workable :)


Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Auto-generate HDF5 from CellML?

[David Nickerson]

On Wed, Nov 12, 2008 at 9:38 PM, Jon Olav Vik <[EMAIL PROTECTED]> wrote:
> David Nickerson <[EMAIL PROTECTED]> writes:
>> As for generic generation of HDF5 data structures from CellML models,
>> I think this would need some thinking :) Is there a generic way to
>> define a useful HDF5 data structure for any given CellML model? I'm
>> not sure...
>
> To my layman's eyes it seems most CellML models are sets of coupled ordinary
> differential equations, for which it should suffice to save state variables 
> for
> each time point, a model identifier and parameter values. (Parameter values 
> must
> be easily searchable, allowing retrieval of results for a given parameter 
> set.)
> Adding results from post-processing should be left to the end user.

I think the searching should be performed with the CellML models
rather than the HDF5 data files. The CellML models containing the
various parametrizations of full models will contain a lot more useful
data to query. You can then search your model archive for simulation
descriptions (model instantiations) that meet certain criteria and can
then retrieve the corresponding simulation data from the HDF5 data
file. I'm currently not in favour of duplicating parameter values in
the HDF5 data groups...but not sure about this yet :)

> Actually, I think writing a HDF5 structure generator could be almost like just
> adding another output format to the code generator.

pretty similar, I think. Certainly something that would be based on
the current code generation service...

>> Do you imagine a tool which for a given CellML model (or perhaps more
>> realistically for a given chunk of CellML simulation metadata) will
>> produce essentially a template HDF5 data group with standardized
>> structure. Then your simulation tool would grab that data group and
>> populate the simulation results.
>
> Yes!

I have added this feature request/suggestion to the tracker
(https://tracker.physiomeproject.org/show_bug.cgi?id=1492) to better
enable tracking further developments along these lines. Anyone
interested in implementing or using such a feature, or simply
observing the developments, should add themselves to the CC list for
the tracker item.

>> Or would some kind of simulation data storage and retrieval service
>> sitting on top of the CellML API be more what you are after? Then I
>> guess that would allow for different underlying persistent data stores
>> to be utilised...
>
> Yes, though I personally don't feel the need for this at the moment.

agreed, although possibly the above could be used as a template to
help with a development like this...


Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Auto-generate HDF5 from CellML?

[David Nickerson]

> I'm considering HDF5 for my storage needs in simulating a CellML model under
> multiple parameter scenarios. HDF5 is designed for efficient storage,
> retrieval, navigation and subsetting of huge data sets [1], with annotation
> [2]. I plan on storing both raw and post-processed data, so that if I detect
> problems at a higher level, I can go back and look at details and possibly re-
> run those simulations. David Nickerson described a similar approach in an
> earlier post [3].
>
> However, setting up the data structure with annotations for physical units and
> such is quite time-consuming. On the other hand, the CellML representation
> holds all the required information. It would be very helpful to auto-generate
> an HDF5 data structure to hold output from simulations of CellML models.
>
> Such a tool should be fairly easy to write for someone familiar with both HDF5
> and CellML, and would apply to all possible CellML models. I guess it would be
> overly restrictive to make an output format part of the CellML metadata
> specification. However, offering a standard output format would save
> duplication of effort and make it easier to share simulation results for
> further visualization and analysis.
>
> I'd like the opinions of the CellML regulars, in particular whether anything
> similar has been discussed previously.

I'm not aware of this coming up for discussion in the past.

I certainly agree that there is little point duplicating data from the
CellML model, although when using unversioned model documents the link
between simulation outputs and input CellML models can become quite
tenuous. If you are building up a large collection of simulation data
for which you need to maintain a strong link to the input models
(which I think you do) you'll probably want to look into such issues
quite a bit. This is something PMR2 will address (I hope), although,
for use now, revision numbers in a subversion repository would
probably be sufficient.

As a side note, I am envisioning that in the long term such simulation
data would ideally be stored using FieldML (http://www.fieldml.org)
which underneath is likely to provide several options for the high
performance persistent storage (with HDF5 being one of the options
that crops up quite frequently). Unfortunately, I'm unsure what sort
of time frame a fieldML based solution might become available...

As for generic generation of HDF5 data structures from CellML models,
I think this would need some thinking :) Is there a generic way to
define a useful HDF5 data structure for any given CellML model? I'm
not sure...

Do you imagine a tool which for a given CellML model (or perhaps more
realistically for a given chunk of CellML simulation metadata) will
produce essentially a template HDF5 data group with standardized
structure. Then your simulation tool would grab that data group and
populate the simulation results.

Or would some kind of simulation data storage and retrieval service
sitting on top of the CellML API be more what you are after? Then I
guess that would allow for different underlying persistent data stores
to be utilised...


David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Auto-generate HDF5 from CellML?

[David Nickerson]

> Sounds really interesting - the one reservation I'd have, however, is that
> HDF5 doesn't appear to be open-source.

just to note that HDF5 is open source. License available here:
ftp://ftp.hdfgroup.org/HDF5/current/src/unpacked/COPYING


Andre.


>
> Cheers,
> James
>
> Jon Olav Vik wrote:
>>
>> Dear all,
>>
>> I'm considering HDF5 for my storage needs in simulating a CellML model
>> under multiple parameter scenarios. HDF5 is designed for efficient storage,
>> retrieval, navigation and subsetting of huge data sets [1], with annotation
>> [2]. I plan on storing both raw and post-processed data, so that if I detect
>> problems at a higher level, I can go back and look at details and possibly
>> re-
>> run those simulations. David Nickerson described a similar approach in an
>> earlier post [3].
>>
>> However, setting up the data structure with annotations for physical units
>> and such is quite time-consuming. On the other hand, the CellML
>> representation holds all the required information. It would be very helpful
>> to auto-generate an HDF5 data structure to hold output from simulations of
>> CellML models.
>>
>> Such a tool should be fairly easy to write for someone familiar with both
>> HDF5 and CellML, and would apply to all possible CellML models. I guess it
>> would be overly restrictive to make an output format part of the CellML
>> metadata specification. However, offering a standard output format would
>> save duplication of effort and make it easier to share simulation results
>> for further visualization and analysis.
>>
>> I'd like the opinions of the CellML regulars, in particular whether
>> anything similar has been discussed previously.
>>
>> Best regards,
>> Jon Olav Vik
>>
>> [1] http://www.hdfgroup.org/about/hdf_technologies.html
>> [2]
>> http://www.hdfgroup.org/training/HDFtraining/UsersGuide/MF_Annot.fm1.html
>> [3] http://article.gmane.org/gmane.text.xml.cellml.general/234/match=hdf5
>>
>>
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>
>
>
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>
>
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Finalising CellML Metadata 1.0 specification

[David Nickerson]

On Thu, Oct 9, 2008 at 8:55 AM, James Lawson <[EMAIL PROTECTED]> wrote:
> It appears nobody has commented on this directly within cellml-discussion. I
> understand you hold some opposition to finalising what you believe to be a
> draft specification, Andre. Could you please elaborate?

I just think that because the current draft has been clearly marked as
a draft that it is not unreasonable to correct known deficiencies
prior to releasing the a final 1.0 specification. I'm also a bit wary
of setting a precedent of "finalising" a specification with known
problems...

I guess I would prefer to see the current 1.0 draft not be finalised,
at least until a draft of the next version of the specification is
available. Then the status of the 1.0 draft would become more of a
historical reference which clearly directs users to a specification
which is much more useful.

> The current consensus (for reasons Andrew mentions below) is that we should
> proceed with this with a view to creating the next version of the metadata
> specification as soon as possible so we can fix the problems with the
> current spec. Peter Hunter's proposed for this work timeframe is by April
> 2009, in time for the planned CellML / SBO / MIASE, BioPAX combined
> workshop.

As I say above, I think work should begin on the next version without
waiting to release the 1.0 specification. People citing or adopting a
draft specification do so knowing that it is likely to change, and in
fact I have had reviewers ask for more detail to be specified when
referencing draft specifications in order to allow readers to be clear
what is "standard" and what is draft, and what version drafts were
used in the work to ensure readers are able to find the appropriate
specifications.

I think the proposed timeframe is reasonable to get the next version
of the specification, at least in draft form, and then at that point
the 1.0 specification could be finalised with the link to the new
(1.1?) specification draft.

Having said that, if releasing the current draft as-is is the only way
to make progress on the next version, then I have no strenuous
objections to doing so as the actual defects in the specification are
quite minor. If this approach is taken, then I would like to see the
status section of the specification note this and link to appropriate
tracker item(s) detailing the work being done to define a more useful
metadata specification.


Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML IRC

[David Nickerson]

On Thu, Aug 21, 2008 at 7:02 AM, James Lawson <[EMAIL PROTECTED]> wrote:
> Dear CellML community,
>
> We have had an IRC channel in the past, but I believe that it fell into
> disuse. I have been pretty interested in getting it going again for
> sometime, so I thought I'd canvass interest. Who thinks they'd be
> interested? I'd suggest we just put it on freenode...

If I remember correctly, while it did fall into disuse there was an
actual decision made not to continue with that line of community
communication. Especially now as the tracker is being proposed as the
place to have specific discussions that maybe are not of general
interest to the community, it would seem to me to be a bad idea to add
one more independent archive that would need to be searched by users
in order to ensure they cover all possible previous discussion
threads.

Perhaps if there was some way to integrate freenode searches into the
tracker search engine then this would make more sense? Better yet,
provide a single search and respond interface for the tracker, mailing
lists, and any other discussion forum and then people can easily
choose the most appropriate medium for them to interact on (with?).


Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Suggestions regarding search andbrowse utility for CellML Repository

[David Nickerson]

port as much as possible from
>>> other ontologies, and let Sarala's ontological framework stand as our
>>> contribution. Where we conclude that there is no ontology that covers
>>> what we are trying to do in a satisfactory manner, we'll create our own.
>>> I can see this happening in the area of synthetic biology, which is only
>>> just starting to be represented by formats like CellML and SBML. So a
>>> tree-like browsing structure as constructed from MeSH tags or similar
>>> could be one of a number of different ways of viewing the models. You
>>> could also do searching by terms, or construct trees according to terms.
>>> For example, you could have 'species' as the top level and 'organ' as a
>>> lower level, and 'cell type' as the bottom. So then you'd get a tree
>>> sorted first by species, then by organ type, say heart, pancreas, liver,
>>> etc. and then by cell type, so within the heart: myocardium, epicardium,
>>> etc. etc.
>>>
>>> The possibilities for how we display fully tagged models are huge, so we
>>> do need to form some kind of system of constraints - or at least provide
>>> a set of default viewing architectures based on what workflows we
>>> anticipate for users.
>>>
>>> When we decompose models into modular elements, this kind of tagging is
>>> going to be absolutely crucial for model reusability and for the process
>>> of figuring out what module you want and where to get it.
>>>
>>> As far as the technology for web services and programmatic access to the
>>> repository database, that isn't something we've thought about much until
>>> now, but on our travels Mike and I have realised that this is really
>>> quite important. In fact, it was often one of the first questions I was
>>> asked when I was discussing the CellML repository. A lot of people are
>>> seeing the repository not simply as a database containing individual
>>> models, but as an dataset in and of itself. We need to work on this -
>>> I'm told Mike mentioned it at the Auckland CellML meeting last week.
>>>
>>> Hope you found this of some interest,
>>> James
>>>
>>> Abhishek Tiwari wrote:
>>>
>>>> As growing no of models in CellML repository I feel that CellML
>>>> Repository can be made more user friendly by implementing one or more
>>>> suggestions mentioned below-
>>>> 1. A Tree like browsing mechanism in which end child node of tree will
>>>> have model. For that we need to have classification system for the
>>>> models based on Physiological system or better say using MeSH (Medical
>>>> Subject Headings,something like
>>>> http://www.nlm.nih.gov/cgi/mesh/2008/MB_cgi). Models can be in multiple
>>>> classes and basically model metadata can have details for the
>>>> classification purpose like keywords. Domain ontologies can be used to
>>>> give better description for tree like representation.
>>>> 2. For a given model at the end of overview similar models (basic or
>>>> improved models or more complex models) can be reported (Similar to
>>>> model variants).
>>>> 3. Web services to search and download CellMl models for non ABI 
>>>> tools (
>>>>   using  CellMl API or Web API for CellMl).
>>>>
>>>> I don't know if efforts to handle above is under development or already
>>>> exists so I thought to write you all.
>>>>
>>>> abhishek
>>>>
>>>> ___
>>>> cellml-discussion mailing list
>>>> cellml-discussion@cellml.org
>>>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>>>
>>>>   
>>> 
>>
>>
>> 
>>  
>>
>>
>>
>>  
>>> ___
>>> cellml-discussion mailing list
>>> cellml-discussion@cellml.org
>>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>>
>>> 
>>
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>   
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Call for community input: decision about theaddition of a CellML API side RDF parsing service

[David Nickerson]

Hi Justin,

As I mentioned on the tracker item, it would be really good if you could 
put together a proposal (perhaps as a document under your cellml.org 
member page) which describes exactly what it is you are proposing here. 
Something along the lines of what Andrew presented when putting forward 
the proposed refactoring of the code generation service. I'm really not 
sure how a "RDF parsing service" on its own is going to help meet the 
goals you describe.

I am also wondering exactly what you mean by an intermediate conclusion?


Thanks,
Andre.


Justin Marsh wrote:
> Hi all,
> 
> For those who may be interested, there has been some discussion amongst 
> those involved with the CellML API recently about a proposed addition of 
> an CellML API side RDF parsing service; this would, for example, allow 
> us to remove our dependency on patching Mozilla, allowing us to build 
> PCEnv from an unmodified build of the Mozilla framework. The discussion 
> has moved over to tracker item 358
> ( https://tracker.physiomeproject.org/show_bug.cgi?id=358 )
> 
> Other reasons for such an addition have been for use in any future 
> metadata service, the increasing use of rdf, and for use in annotating 
> systems of equations.
> 
> Reasons against such an addition have included the availability of 
> preexisting libraries, the possibility of scope creep, the possibility 
> of introducing changes or dependencies in the existing CellML API, the 
> broadness of the current proposal, and a possible conceptual uncleanness 
> or incorrectness.
> 
> I would appreciate any feedback, comments about, or refinements of this; 
> however, unless the discussion is still raging, we want to come to at 
> least an intermediate conclusion by Friday the 9th of May.
> 
> Best Regards,
> Justin Marsh
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] decompose - a model decomposition utility

[David Nickerson]

Hi all,

I have recently needed to revive an early CellML 1.0 model of mine which 
I need to use within some more recent modelling work. The model is very 
complicated it was going to take a long time to separate out the deeply 
embedded parameter values and initial conditions in order to make the 
model more amenable to use in a CellML 1.1 model hierarchy.

As I was feeling a bit lazy I decided instead to take a stab at writing 
some code which would do this automatically for me. I have done this 
(using the CellML API) and the code is now available on the CellML 
sourceforge.net project. More information about it and help on how to 
compile the code are available at 
http://cellml.sourceforge.net/decompose/index.html - on the off chance 
you look into the code, please bear in mind this was quite a rush effort 
to get something working :) also, while it seems to work well on the 
models I have tested it with (cellular electrophysiology), there are no 
guarantees for other models...see also the limitations section on the 
above web page.


Thanks,
Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Call for community input: final decisionson anumber of specification related issues

[David Nickerson]

> I think this creates a bit of a 'catch-22' situation because we need a 
> decision process to decide on a decision process. I think that until we 
> have such a process, we need to stick to the status quo, which has 
> generally been that we discuss things with the community, and if there 
> is disagreement, then a smaller group of people make the decision (I 
> personally would prefer a more formalised voting based system with a 
> fairly large number of eligible voters, but both Poul and Peter seem to 
> favour a system where we define a fairly small set of people from a 
> range of different groups who can vote, and only use this mechanism to 
> make a decision when the community has discussed an issue and not 
> reached agreement).

I'm not really commenting on whether the proposed system is suitable or 
not, at least not yet :) just that given we have a tracker, we have an 
item in the tracker discussing this issue, and we are encouraged to use 
the tracker for such discussion. So this solution and the justification 
for it should have been posted to the tracker item first before 
announcing that the solution has been decided upon.

Currently I am getting the impression that any discussion of tracker 
items is superfluous and decisions will always be made by the Auckland 
meeting.

> Just to clarify, are you objecting to all or any of the deadlines (on 
> any of the specific issues listed below) or are you happy with the 
> actual tracker items (as opposed to the decision-making process)?

the latter :)
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Call for community input: final decisions on anumber of specification related issues

[David Nickerson]

 CellML is too 
> general to be fully implemented).
> Tracker item 56 (https://tracker.physiomeproject.org/show_bug.cgi?id=56) 
> - That we consider the issues arising from the CellML subset resolved 
> (conditional on tracker item 332)
> Tracker item 84 (https://tracker.physiomeproject.org/show_bug.cgi?id=84) 
> - Proposal for a standardised real number format using a decimal point 
> (as opposed to a decimal comma or decimal momayez).
> 
> I haven't included tracker item 337, about removing directionality from 
> connections, because discussion on it seems to have stagnated without 
> reaching agreement on the details of the best approach.
> 
> Best regards,
> Andrew
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Auckland CellML GroupMeeting Minutes(2008-02-07)

[David Nickerson]

Randall Britten wrote:
> 
>> -Original Message-
>> From: David Nickerson
>> Sent: Monday, 11 February 2008 4:43 p.m.
>> To: CellML Discussion List
>> Subject: Re: [cellml-discussion] Auckland CellML Group Meeting
>> Minutes(2008-02-07)
>>
>> just a couple of points arising from these meeting minutes...
>>
>> Any outcomes from the breakaway session discussing the "if and how" of
>> creating an annotated or informative version of the normative 1.2
>> specification draft?
> 
> None yet, further discussion required.

I have added tacker item 338 
(https://tracker.physiomeproject.org/show_bug.cgi?id=338) perhaps the 
folks in Auckland could update this with discussions to date and then 
interested parties can take it from there


Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Auckland CellML Group Meeting Minutes(2008-02-07)

[David Nickerson]

just a couple of points arising from these meeting minutes...

Any outcomes from the breakaway session discussing the "if and how" of 
creating an annotated or informative version of the normative 1.2 
specification draft?

Under the SBML to CellML conversion, I'm just wondering what 
implementations are being referred to as being in C++ and Java?

Generating Fortran code from the CellML model repository does little in 
the way of helping to get CellML models into CMISS. As well as the 
Fortran code needing to adhere to a internal cmiss interface in order to 
be usable as a USER_CELL routine (the presumable goal of this 
suggestion), there needs to be suitable input files (most notably the 
ipcell file) generated when using a USER_CELL model in cmiss. The 
current use of CellML within cmiss will allow the user to be prompted 
for the input file creation, but this does not apply to USER_CELL 
models. A more useful alternative might be to create a standard 
USER_CELL routine which can map the internal cmiss interface to that 
currently defined by the C code which the repository is already capable 
of generating, and then providing a simple little tool to generate 
ipcell files from the CellML code. There is no need to restrict the code 
being used in cmiss to Fortran.


Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Using proposed CellML 1.2 features to createmore re-usable metabolic models

[David Nickerson]

gt; 
>   
>   
> f
>   
> 
>   
> 
>   
> 
>   
> 
>   
> 
>   
> 
>   
> 
>   
> 
>   
> 
>   
>   
>public_interface="yes" />
>public_interface="yes" />
>public_interface="yes" />
>public_interface="yes"
>   type="set_of_lambda_of_real"
>   units="mol_per_litre_per_second" />
>public_interface="yes"
>   type="set_of_lambda_of_real"
>   units="mol_per_litre_per_second" />
>public_interface="yes"
>   type="set_of_lambda_of_real"
>   units="mol_per_litre_per_second" />
>  initial_value="0.5" />
>  initial_value="0.1" />
> 
> 
>   
> overall_rate
> 
> 
>   
> kf
> concentration_a
> concentration_b
>   
>   
> kb
> concentration_x
>   
> 
>   
>   
> 
>   
> overall_rate
>   
> 
> flux_a
>   
>   
> 
>   
> overall_rate
>   
> 
> flux_b
>   
>   
> 
>   overall_rate
> 
> flux_x
>   
> 
>   
> 
>   
>   
>public_interface="yes" />
>public_interface="yes" />
>public_interface="yes" />
>public_interface="yes"
>   type="set_of_lambda_of_real"
>   units="mol_per_litre_per_second" />
>public_interface="yes"
>   type="set_of_lambda_of_real"
>   units="mol_per_litre_per_second" />
>public_interface="yes"
>   type="set_of_lambda_of_real"
>   units="mol_per_litre_per_second" />
>  initial_value="0.5" />
>  initial_value="0.1" />
> 
> 
>   
> overall_rate
> 
> 
>   
> kf
> concentration_a
> concentration_x
>   
>   
> kb
> concentration_y
>   
> 
>   
>   
> 
>   
> overall_rate
>   
> 
> flux_a
>   
>   
> 
>   
> overall_rate
>   
> 
> flux_x
>   
>   
> 
>   overall_rate
> 
> flux_y
>   
> 
>   
> 
>   
>public_interface="yes" />
>public_interface="yes" />
>public_interface="yes" />
>public_interface="yes" />
>    public_interface="yes"
>   type="set_of_lambda_of_real"
>   units="mol_per_litre_per_second" />
>public_interface="yes"
>   type="set_of_lambda_of_real"
>   units="mol_per_litre_per_second" />
>public_interface="yes"
>   type="set_of_lambda_of_real"
>   units="mol_per_litre_per_second" />
>public_interface="yes"
>   type="set_of_lambda_of_real"
>   units="mol_per_litre_per_second" />
>   
> 
>   
> 
> 
>   
>   
> 
> 
>   
>   
> 
> 
>   
> 
>   
> 
> 
>   
>   
> 
> 
>   
>   
> 
> 
>   
> 
>   
> 
> 
>   
>   
> 
> 
>   
>   
> 
> 
>   
>   
> 
> 
>   
> 
>   
> 
>   
>   
>   
>   
>   
>   
> 
>   
> 
>   
> 
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Base normative CellML Specificationfor further work

[David Nickerson]

;>> discussion underway about what to do with group - if only encapsulation
>>> is allowed, we can simplify it and get rid of name, otherwise we may
>>> need to re-add it.
>>> 3) The meaning of attributes without explicit namespace prefixes was
>>> defined in 1.1 to override the XML Specification. This had to be
>>> removed
>>> to prevent a conflict between the namespaces in XML normative reference
>>> and the specification text.
>>> 4) There is nothing in the specification corresponding to the
>>> restrictions on group in CellML 1.1 section 6.4.3.2 bullet point 2. The
>>> reason is that this is somewhat problematic when applied across imports,
>>> and the assertion in CellML 1.1 that having multiple group elements
>>> makes processing more complex has not been shown to be true in
>>> implementation experience (while testing the rule does make things more
>>> complex).
>>> 5) The restriction that grouping hierarchies must form a tree is only
>>> specified for the encapsulation. This could be extended to all groups
>>> if
>>> we decide to keep groups.
>>> 6) There are no restrictions on duplicate connection elements for the
>>> same pair of components (but there are for duplicate connections to the
>>> same variables).
>>>
>>> Best regards,
>>> Andrew
>>>
>>> ___
>>> cellml-discussion mailing list
>>> cellml-discussion@cellml.org
>>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>> 
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>   
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Survey on opinions for the backwardscompatibility levels for future CellML Specs

[David Nickerson]

nificantly increases the
>> expressiveness of the language. However, in normal circumstances,
>> compatibility should be maintained, so that when a model not using new
>> features is saved in the new version's most preferred format, it can
>> still be correctly loaded into software only supporting the old  
>> version.
>> Likewise, a model not using any removed features should be able to be
>> loaded in software supporting only the new version of the  
>> specification.
>>
>> Option C)
>> Future versions of CellML should make any changes which make it
>> conceptually cleaner, even if there is a less clean compromise  
>> available
>> that would have lesser compatibility implications. Software will  
>> need to
>> explicitly support more than one version as a completely separate  
>> format.
>>
>> My preferred choice is Option B. Despite being apparently at opposite
>> ends of the spectrum, Option A and Option C are, in my opinion, fairly
>> similar, because if we adopted Option A, larger changes would  
>> appear in
>> a new specification called something other than CellML. Although there
>> could be advantages of coming up with a more meaningful name than
>> CellML, I think that this would also set us back in terms of community
>> awareness of the specification, and so I think that Option C is
>> marginally better than Option A (i.e. my personal order of  
>> preference is
>> currently B:1, C:2, A:3).
>>
>> I look forward to any feedback on this you may have.
>>
>> Best regards,
>> Andrew
>>
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2

[David Nickerson]

> * Remove the CellML Subset / "fully MathML capable software" - instead, 
> delegate
>   the exact description of what mathematical expressions are allowed in 
> models
>   to secondary specifications which refine the mathematics allowed in 
> CellML to
>   the point that the secondary specification can realistically be completely
>   implemented for all cases.
> 
>   This will allow for tools to support multiple secondary specifications if
>   they deal with more than one problem domain.

this seems to be a good direction to be heading.

> * Remove the recommended prefixes for namespaces in the normative
>   specification, although this could go in the informative specification 
> as a
>   suggestion. This should help ensure that no one relies on things having a
>   particular prefix, which the current specification doesn't go out of its
>   way to prevent.

I don't see this as being a problem, but have no reason not to take it 
out of the normative specification.

> * Make CellML identifiers like _1a valid. The 1.1 specification currently
>   contradicts itself on whether this identifier is valid.

agreed.

> * Assume attributes without an explicit prefix are in the empty 
> namespace, in
>   accordance with 6.2 of the namespaces in XML document. This means that 
> it would
>   be invalid to explicitly put an attribute in the CellML namespaces.
>   http://www.cellml.org/cellml/1.1#";
>  xmlns:cellml="http://www.cellml.org/cellml/1.1#";
>  cellml:name="test">...
>   would be invalid, while
>   http://www.cellml.org/cellml/1.1#"; name="test">...
>   remains valid. This seems to be consistent with how people have actually
>   implemented CellML processing software.

yep - sounds like how it should be defined.

> * Software will be required to identify cases (and report an error) where
>   future CellML elements are present (unrecognised namespaces starting with
>   http://www.cellml.org/cellml/).

I think this one needs a bit of elaboration. I'm guessing this applies 
to all software which claims to be CellML 1.2 compliant/conformant to 
some degree, right? and would need to tie in with applications 
supporting the secondary specifications with regard to the type of 
MathML they support...

> * It will be valid to define presentation MathML from within extension 
> elements.
>   This should be legitimate content for an extension element.

didn't realise this was currently not allowed. Definitely good to allow 
it. On a related note, I presume it currently is and will continue to be 
valid to also provide presentation MathML using the annotation mechanism 
within MathML?

> * Software will no longer be encouraged to alert the user to unrecognised
>   extension elements. Extension elements shouldn't contain information 
> which is
>   essential to the model processing, so there is no need to warn the user.

agreed.

> * In CellML 1.1, only one connection element can be present for all 
> variables
>   being connected for a particular pair of components. This restriction can
>   make coding models unnecessarily hard and there is no evidence that it
>   reduces the implementation burden. Therefore, it makes sense to remove 
> this
>   restriction. It will still not be possible to connect the same 
> variables more
>   than once.

I don't recall the discussion on this issue ever being resolved, but 
this would imply that some resolution was achieved somewhere?

> * The current specification says:
>   "A variable with either a private_interface or public_interface attribute
>value of "in" must be mapped to no more than one other variable in the
>model. [ Note that a similar restriction does not apply to variables with
>interface values of "out". An output variable can be mapped to multiple
>input variables in various components in the current model. ]"
> 
>   The problem with this is that it doesn't properly account for mappings 
> where
>   a variable is forwarded into an encapsulated block. As an example, 
> consider
>   the following encapsulation hierarchy (higher components encapsulate lower
>   ones)...
> 
>A
>|
>B
>   / \
>  C   D
> 
>   Suppose that component A has, for variable v, public_interface="none",
>   private_interface="out", and B has for variable v, public_interface="in",
>   private_interface="out" (connected to A), and C and D have 
> public_interface="in",
>   private_interface="none", both of which are connected to B.
> 
>   There is no reason why this should not be valid. However, the 
> specification
>   contradicts itself on whether this is allowed. On one hand, because B has
>   private_interface="out", it "can be mapped to multiple input variables in
>   various components in the current model.", but because it has a public
>   interface of in, it "must be mapped to no more than one other variable 
> in the
>   model".
> 
>   This can be fixed by firstly defining

Re: [cellml-discussion] 'Modification' of variables

[David Nickerson]

this is starting to get complicated :)

I have typically been treating my components and models as "complete" 
pieces which I connect into various configurations for different 
purposes. In such an approach, I use the variable interfaces to 
essentially define an internal API for the components and then use 
encapsulation to provide a single external API for useful model 
hierarchies. I guess this is very much a procedural approach to using 
CellML.

What you are talking about is more a declarative approach, and you're 
right - that makes for much more reusable and extendable components and 
model hierarchies.

So perhaps the way that I need to start thinking about the interfaces is 
that they are simply hints at the original author's intent for the use 
of the component - but that is no reason to stop future users of the 
component changing an input to an output variable, especially given we 
now have the CCGS being capable of working out, at the simulation 
instantiation stage, which are which in the context of the entire model. 
The special hint of "none" is then simply an indication that the 
variable is used outside the component at the users risk with undefined 
behaviour?

I think you are starting to convince me that your original proposal is 
the right way to be going...but more thought is definitely required :)


Andre.


Andrew Miller wrote:
> David Nickerson wrote:
>> The good thing about the existing rules is that you can see from the 
>> variable interfaces for a given component what needs to be defined 
>> externally and what may be used externally. While I can see your point 
>> about the way mathematical expressions could end up modifying different 
>> variables depending on how the entire model is defined, I'm not sure 
>> that we want to start allowing variables with an interface off "in" to 
>> be modified in any way.
>>
>> I guess I'd prefer a set of rules that somehow flag "in" variables as 
>> constant within that component. If execution of the math in a particular 
>> instantiation of the component would result in any such constants having 
>> their value changed then that should be treated as an error.
> 
> This would severely limit the re-usability of CellML components / 
> imports, because it means that you have to decide ahead of time which 
> variables are going to be used in which way, and if you then tried to 
> use it in a different context for a different purpose, you would 
> potentially end up changing something from an input to an output.
> 
> If major recoding of a model is required to make minor changes to how 
> the some mathematics are used, this does not fit well with the model 
> sharing and reuse goals underlying the CellML project.
> 
> Perhaps you could explain the reasons behind why you don't think we 
> should allow this type of use case?
> 
>>  Essentially 
>> what the current rules state, but perhaps not quite the way the rules 
>> are being enforced in the CCGS?
>>   
> I don't know if anyone has correctly enforced these rules - I have heard 
> that COR simply expects that variable to be the second child element in 
> the MathML apply element that is the child of the math element, which is 
> rather arbitrary as the equations could be re-arranged and they would no 
> longer pass this validation stage (perhaps Alan could confirm or correct 
> this?).
> 
>> If we were to remove such rules, is there any need for the public and 
>> private interfaces at all?
>>   
> We don't want to expose all variables, because some are intended to be 
> component-local.
> 
> We could have used a 'true' / 'false' type undirected system in which 
> variables are either exposed or hidden on each interface. However, 
> changing this now would create 100% forwards and backwards 
> incompatibility both theoretically and with the actual software 
> implementations available, as opposed to having a few models with 
> theoretical 1.1-1.2 forwards compatibility issues that work in practice 
> in all current software which such models needing minimisation steps 
> would work in anyway.
> 
> Best regards,
> Andrew
>> Andre.
>>
>>
>> Andrew Miller wrote:
>>   
>>> Hi all,
>>>
>>> The current (CellML 1.1) specification has some wording like the following:
>>>
>>> ''The variable must also be declared in these components, which can then 
>>> use the value of the variable in their own equations but must not modify 
>>> it." (3.2.3)
>>>
>>>
>>> "
>>> 4.4.4
>>>
>>> * A mathematical expression defined using MathM

Re: [cellml-discussion] 'Modification' of variables

[David Nickerson]

The good thing about the existing rules is that you can see from the 
variable interfaces for a given component what needs to be defined 
externally and what may be used externally. While I can see your point 
about the way mathematical expressions could end up modifying different 
variables depending on how the entire model is defined, I'm not sure 
that we want to start allowing variables with an interface off "in" to 
be modified in any way.

I guess I'd prefer a set of rules that somehow flag "in" variables as 
constant within that component. If execution of the math in a particular 
instantiation of the component would result in any such constants having 
their value changed then that should be treated as an error. Essentially 
what the current rules state, but perhaps not quite the way the rules 
are being enforced in the CCGS?

If we were to remove such rules, is there any need for the public and 
private interfaces at all?


Andre.


Andrew Miller wrote:
> Hi all,
> 
> The current (CellML 1.1) specification has some wording like the following:
> 
> ''The variable must also be declared in these components, which can then 
> use the value of the variable in their own equations but must not modify 
> it." (3.2.3)
> 
> 
> "
> 4.4.4
> 
> * A mathematical expression defined using MathML must only modify
>   the values of variables that belong to the current component.
>   [ Variables that belong to a component are those that are not
>   declared with a |public_interface| or |private_interface|
>   attribute value of |"||in||"|. ]
> 
> "
> 
> It doesn't really make a lot of sense to talk about a mathematical 
> expression modifying a variable, because an equation really only 
> describes the relationships between variables, and doesn't specify which 
> variable is to be modified. At least in the current CCGS implementation, 
> exactly how an equation is used will vary depending on what other 
> components are connected to a given component, and so it is possible 
> that the rules would sometimes be met depending on what is connected to 
> a particular component, which is obviously not a robust way to develop a 
> model.
> 
> I suggest that this requirement be dropped in the next version of CellML 
> (I am also making a list of other changes from 1.1 I am proposing, which 
> I will send to the mailing list when it is completed).
> 
> Best regards,
> Andrew
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML terminology:distinguishingCellMLmodels from the XML in which they are represented

[David Nickerson]

Andrew Miller wrote:
> David Nickerson wrote:
>> Andrew Miller wrote:
>>   
>>> ...
>>> How about CellML Infoset, CellML Model, and Mathematical Model?
>>> 
>> That sounds good to me. While I guess this use of infoset is pretty 
>> common in the XML world, it might be useful to refer to the CellML XML 
>> Infoset? Or is it safe to assume that people reading the specification 
>> have some familiarity with XML concepts?
>>   
> I am not sure that having the words XML aid interpretation. Also, there 
> has been some work to create alternative, non-XML serialisations of the 
> infoset - see Fast Infoset for example, which is on an ITU-T 
> standardisation track. We are not talking specifically about the XML 
> serialisation in the places where XML Infoset is mentioned (although of 
> course XML serialisation is the standard for CellML, anything else would 
> be an extension). However, given that the definition of CellML Infoset 
> would reference the XML Information Sets specification, I am not sure 
> that we really need to repeat XML everywhere.

OK - makes sense to me.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Should groups be allowed to imply metadatainformation?

[David Nickerson]

Andrew Miller wrote:
> Hi all,
> 
> The CellML 1.1 specification says:
> 
> "
> 6.5.3  Groups must not imply metadata information
> 
> Modellers must not use CellML groups to associate properties or 
> classification information with sets of components. The metadata 
> functionality is the proper method for making such associations. This 
> increases the chance of that information being used by a range of CellML 
> processing software.
> "
> 
> If extension groups cannot be used to imply metadata or mathematical 
> information, then there is not really anything left for them to imply. I 
> think that we should do one of the following:
> 1) Non-standard relationship types be disallowed, and only encapsulation 
> and containment be kept (encapsulation does affect the mathematical 
> formulation of the model, while containment is really metadata 
> information), or perhaps only encapsulation should be kept, with 
> containment data represented in metadata, or,
> 2) Allow groups to be used for metadata information, but in the 
> informatively annotated specification encourage the CellML community to 
> standardise on exactly how a certain type of metadata should be 
> represented (this is required whether RDF/XML or groups is used to 
> express the metadata anyway).

I'd be in favour of option 1 combined with moving containment into metadata.

Just to add a link to the tracker, also see: 
https://tracker.physiomeproject.org/show_bug.cgi?id=316
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML terminology: distinguishingCellMLmodels from the XML in which they are represented

[David Nickerson]

Andrew Miller wrote:
> David Nickerson wrote:
>> I think option 1 would be much better than 2.
>>
>> An alternative might be the RDF and RDF/XML approach? Not too sure what 
>> that implies, but personally I see it as an RDF graph and then the XML 
>> serialisation of that graph. Could we use something like CellML Model 
>> and CellML Model/XML or maybe CellML/XML ?
>>   
> I think that this could be heading towards the right approach, although 
> I'm not sure that the XML serialisation is automatically the right layer 
> of abstraction to refer to (we are only defining XML parsing by 
> reference, although RDF/XML does as well) - perhaps the XML Information 
> Set could be the lowest level, and we describe how that relates to the 
> conceptual componentised model after import processing, and ultimately 
> the conceptual non-componentised mathematical model (when mathematical 
> equations are present).
> 
> How about CellML Infoset, CellML Model, and Mathematical Model?

That sounds good to me. While I guess this use of infoset is pretty 
common in the XML world, it might be useful to refer to the CellML XML 
Infoset? Or is it safe to assume that people reading the specification 
have some familiarity with XML concepts?
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] CellML terminology: distinguishing CellMLmodels from the XML in which they are represented

[David Nickerson]

ect within the current context).
> 
> Please let me know what you think on this issue. I personally think that 
> option 1 is the best, but based on the discussion at the CellML meeting 
> today it doesn't seem likely that I will get much support for that approach.
> 
> Best regards,
> Andrew
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] My specification draft in progress is nowpushed to the CellML site

[David Nickerson]

Hi Andrew,

> 1) Viewing a static page generated from the specification:
> 
> My current version of the specification (which may or may not represent 
> community consensus) gets pushed into Zope automatically every hour as a 
> static page. The URL is:
>http://www.cellml.org/Members/miller/draft-normative-spec/toplevel.xhtml
> 
> Others may modify the script used to do this to push into their own 
> members area if they want to do something similar.

Not sure if you have noticed, but this page doesn't appear to be updated 
with the changes you're making in the git repository.


Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] My specification draft in progress is nowpushed to the CellML site

[David Nickerson]

Hi Andrew,

A short wiki page with a summary of this specification development stuff 
(repository location(s), your static page link and others that people 
might add, docbook processing examples, etc) would be very useful for 
those of us that perhaps don't have time to work out how to use git 
and/or docbook but want to keep up-to-date with developments.


Thanks,
Andre.

Andrew Miller wrote:
> Hi all,
> 
> For those of you who are interested in looking at the drafts currently 
> being developed for the next CellML specification but don't have the 
> time to set up git, DocBook, etc..., I have provided two ways to view 
> the specification more easily:
> 
> 1) Viewing a static page generated from the specification:
> 
> My current version of the specification (which may or may not represent 
> community consensus) gets pushed into Zope automatically every hour as a 
> static page. The URL is:
>http://www.cellml.org/Members/miller/draft-normative-spec/toplevel.xhtml
> 
> Others may modify the script used to do this to push into their own 
> members area if they want to do something similar.
> 
> 2) Viewing from checked out versions of git in Firefox or other 
> Mozilla-based web-browser:
> 
> I have used the XMLHttpRequest and XSLT features present in Mozilla to 
> generate a Javascript-based page that processes XInclude and generates a 
> working output from the toplevel DocBook input file.
> 
> This doesn't work through the git web interface because the relationship 
> between URLs for files from the same revision is non-trivial. However, 
> you can check it out from my normative specification branch in git and 
> start looking at it straight away.
> 
> Best regards,
> Andrew
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] specification draft and docbook

[David Nickerson]

Randall Britten wrote:
> Is there a way we could use some kind of variable substitution for the term
> "CellML file"/"CellML document"?

I think it would actually be much better for the community to decide one 
way or the other fairly soon - and I was happy enough with Andrew's 
definition/explanation.

While I'm sure we could arrange some kind of variable substitution or 
entity solution such as Dave suggests, this would only work on the 
specifications - not any email discussions, meeting minutes, wiki pages, 
etc, which will severely confuse any community browsers.

So I propose that unless anyone else has strong feelings on the issue we 
continue with 'CellML File' for now and then if in the future we decide 
to change to something else then it should be changed everywhere.


Andre.

> 
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:cellml-discussion-
>> [EMAIL PROTECTED] On Behalf Of Andrew Miller
>> Sent: Wednesday, 28 November 2007 9:14 a.m.
>> To: For those interested in contributing to the development of CellML.
>> Subject: Re: [cellml-discussion] specification draft and docbook
>>
>> David Nickerson wrote:
>>> Hi Andrew,
>>>
>>> I have just starting looking at using git and checking your current
>>> draft of the specification. I have made a few changes and attach the
>>> patch (generated with git diff -p > andre.patch). Not really sure the
>>> best way to do things in order to share changes - I guess if there
>> are
>>> going to be many its worth signing up at the same place hosting your
>>> draft? but then I'll probably not have to much time to devote to
>> this...
>> It did prove very easy to set up the repository, however. If it is too
>> hard I guess we need to try to arrange our own CellML-specific hosting.
>>
>>> Anyway, about the only significant change I made was to turn all the
>>> sect1 and sect2's into section's - while this is probably more a
>>> personal preference, it seems to be a widely used one.
>> I have now pushed that change to my branch
>> (643b9d1260e9a64f6a0a20f79d6c88665e1dcc7a in git).
>>
>>> Hardcoding section levels just seems a bad thing to be doing to me,
>>> especially when you're using XInclude to include multiple documents
>>> into a single documentalthough maybe you are trying to force
>> those
>>> sections to a specific depth regardless of where they are imported
>> into?
>>> And then a couple of other things I changed that we can maybe discuss
>>> more on cellml-discussion. You are using 'CellML File' as the base
>>> unit whereas I generally think of them as documents - especially in
>>> the context of generated data which may never exist in an actual file.
>>> Again, just my preference :)
>> I created a branch normative-andre to track what your current opinion
>> of
>> the specification should be (of course, things like 'Change File to
>> Document' won't keep up with new instances where 'CellML File' is
>> added). This was pushed to my public repository on the normative-andre
>> branch as "92b7b3a7515c7aae22f42b417296ad263fee9433".
>>
>> Best regards,
>> Andrew
>>
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Cross references within annotations

[David Nickerson]

Hi all,

I have just been doing some work annotating a cellular electrophysiology 
model and more and more I find myself wanting to be able to provide 
cross-references to other resources, usually from within 
cmeta:comment's. So with the hope that someone out there might have 
already thought this through and arrived at a feasible solution, I just 
thought I'd put out this request for help :)

A typical example is that I would like to annotate a variable or 
equation with a human readable description which unambiguously links to 
a specific reference or other variables/equations in the model. For 
example, I currently do something like this (in RDF/XML):

...
 
   
 A voltage-dependent formulation of the activation gate time 
constant based on data from Amberg et al (2002). The definition of this 
variable includes the Q10 temperature correction.
   
   
 
 
   12381815
 
...

where the Pubmed_id refers to the Amberg et al (2002) article. What I 
would like to do is be able to link directly to the bqs:reference. 
Obviously I can give the bqs:reference an rdf:ID by which I can link to 
it, but how would that be included in the body of a cmeta:comment? 
Further refining the above example, I would also like to provide a link 
to the definition of the temperature correction scale factor from the 
cmeta:comment body.


Thanks,
David.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] specification draft and docbook

[David Nickerson]

>> I have just starting looking at using git and checking your current
>> draft of the specification. I have made a few changes and attach the
>> patch (generated with git diff -p > andre.patch). Not really sure the
>> best way to do things in order to share changes - I guess if there are
> That way is probably okay for small changes. I believe git has ways to
> e-mail patches while keeping the change identifier - that might make it
> easier to merge back and forwards in the future, because if I commit
> your change and you update, it would be good if there was no need to
> re-merge that patch. I have never actually tried git's e-mail features,
> although I believe that they are used extensively for Linux kernel
> development.

that sounds like something that could be quite useful. Guess it'll be a 
matter of how many more patches we will be creating and how many people 
run their own repository.

>> And then a couple of other things I changed that we can maybe discuss
>> more on cellml-discussion. You are using 'CellML File' as the base unit
>> whereas I generally think of them as documents - especially in the
>> context of generated data which may never exist in an actual file.
>> Again, just my preference :)
> I guess the only issue is that file implies it is always a single XML
> file, while document could potentially be more than one file.

maybejust trying to think of an example where someone might create a 
single "CellML Document" using something like XInclude or XML entities 
or something...can't think of anything off the top of my head though so 
maybe CellML File is a better term than a CellML Document.

>> And the second point, which I'm sure has been discussed in the past but
>> I can't quite recall is the statement that CellML processing software
>> should not attempt to process documents containing elements in the
>> CellML 1.0 namespace. Perhaps you could just refresh my memory as to
>> where that came up before?
> The idea is that CellML 1.0 and CellML 1.1 namespaces shouldn't be
> mixed. CellML 1.x (x > 1) processing software can also process CellmL
> 1.0 files, but it must do so in accordance with the CellML 1.0
> specification, and not in accordance with any of the future
> specifications, because CellML 1.0 documents are not valid under those
> later specifications. The annotated specification will probably need to
> explain this, but that explanation is not necessary to define CellML 1.2
> and so not really appropriate in a normative-only version of the document.

ok - thanks for the reminder, its slowly coming back to me and makes sense.


Andre.

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] [Fwd: Re: application 'ML']

[David Nickerson]

I can give my answer to this here and maybe someone in Auckland can 
forward it the Steve as I'm not sure he is on this list.

> Steven Niederer wrote:
>> Hi guys,
>>
>> Just checking if there was any work been done on the following:
>>
>> 1) creating maps of variable names to allow a user (me) to define a 
>> variable that I want to change in a one file and have that mapped onto 
>> the corresponding variable in a model. (I am batch processing analysis 
>> of 20+ models at the moment)
>>
>> ie I wish to set value for  intracellular calcium. I want to call the 
>> variable Cai but in the models that I have it is called cai, Cai  and 
>> Ca_i etc. so I wish to create a wrapper for each model to map the 
>> variables to a standard name.
>> Is there any work been done on things like this and if so is their a 
>> recommended format for the mapping wrapper?

this can be easily accomplished using CellML 1.1. If you want to have 
all the models run at once you can import all the 20+ models into one 
model and connect the various calcium variables to a single variable in 
the mega model. Otherwise, if you want to keep the models independent 
you create a wrapper for each model which imports the model and a common 
calcium model which defines the common calcium value. This variable can 
then be connected to each model in the wrapper model allowing you to 
change it in just one place for all models.

This would, of course, work for any variable(s) in the models. An 
applied electrical or mechanical stimulus would be another good example 
of this.

>> 2) Defining virtual experiment protocols.
>>
>> After defining the model variables that I wish to set as model outputs 
>> or inputs I would like to define how the input variables are set and 
>> if I want any post processing to be done on my output signals.
>> Again I wondered if there was a proposed format for these types of 
>> descriptions.

again - CellML 1.1 is perfect for this. You define your mathematical 
model independently of specific parameter values and boundary conditions 
and then simply import the mathematical model into specific 
"experiments" which define the specific inputs and post processing you 
wish to define. Generally I find it convenient to define different 
levels of models for importing with more and more specifics set at each 
level in order to make each model as reusable as possible.


David.


-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Representing the next version of the CellMLSpecification

[David Nickerson]

> For the purpose of presentation math, LaTex substrings get my vote.  

the problem with LaTeX math is that it is quite unfamiliar to a lot of 
people, whereas most people involved in CellML probably have a 
reasonable grasp of at least content MathML if not presentation MathML 
also. The conversion from content to presentation is quite 
straightforward using the W3C provided XSLT's.

> They are simple to express and their diffs in my opinion are easier  
> to interpret than diffs of MathML/XML.

Not sure I see how - there are many ways to lay out the same equation in 
LaTeX, especially if you are using one of the WYSIWYG editors, and even 
more so if you are using a different WYSIWYG editor from the last person 
to edit the document, so I wouldn't expect the diffs to be any better 
than MathML/XML diffs. In either case things can be improved by imposing 
certain style rules - much like Andrew suggested in another part of this 
thread...

In terms of diffs, are there not plenty of tools around that provide XML 
diff's based on the underlying content of a document rather than a 
simple text file diff? That would seem a more appropriate way to go to me.

> More generally, I think XML source formats should be avoided if  
> possible.

Just wondering if you can explain your reasoning for this?


Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Representing the next version of the CellMLSpecification

[David Nickerson]

> Another option would be to have our own simple XML markup language along 
> with XSLT that produces DocBook (I know nothing about CWML - is it XML 
> based? Can it be transformed into DocBook?)

The decision we made previously was to move from a custom XML language 
(CWML) to something more standard (docbook) - there were many good 
reasons for doing so, all buried in the minutes somewhere :)

I don't think we want to go back down the custom XML route.

In added support of docbook, the current documentation used in the model 
repository is essentially a restricted subset of simplified docbook, 
which Catherine (and others?) seem to handle with ease...not sure if 
thats the case, but its the impression I get.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Representing the next version of the CellMLSpecification

[David Nickerson]

> 1) can represent MathML in either content or presentation format and  
> can render MathML in the HTML output using image replacements instead  
> of expecting that the browser can render MathML (content or  
> presentation)

is the use of image based equations still required? if people are using 
a browser which is not capable of rendering MathML, either natively or 
via a plugin, they can browse the PDF version instead? Much like the 
current options for viewing the model mathematics in the model repository.


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Representing the next version of the CellMLSpecification

[David Nickerson]

 Pros:
>   * Allows for section references and generation of full 
> specification structure.
>   * Supports a lot of specification type metadata and concepts, and 
> will therefore delimit everything in specification very thoroughly.
>   * Used by the W3C for a large number of specifications, so 
> reasonably well field tested.
> Cons:
>   * Potentially hard to read diffs if they change lots of sections 
> and therefore include parts of the markup.
>   * We will need to make some changes to make it non-W3C specific.
> 
> 5) Use DocBook
> Pros:
>   * DocBook widely implemented - lots of tools, several output formats.
>   * Lots of semantic markup elements for a lot of different types of 
> data.
>   * Automated section numbering and content page references.
>   * Content page generation
>   * With the MathML extension module, embedded MathML can be used - 
> I'm not sure how well this works in practice
> Cons:
>   * Potentially hard to read diffs if they change lots of sections 
> and therefore include parts of the markup.
> 
> 6) Use the IETF's xml2rfc tools
> Pros:
>   * Widely tested.
>   * Section references.
> Cons:
>   * We would have to update it so it isn't IETF specific.
>   * Text-only - no images except ASCII-art
>   * Potentially hard to read diffs if they change lots of sections 
> and therefore include parts of the markup.
> 
> I personally favour options 4 and 5 - I think that option 5 might end up 
> being the easiest for us because of the wider tool-base.
> 
> Best regards,
> Andrew
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Physiome Project issue tracker now available

[David Nickerson]

Hi Andrew,

Just wondering if there is any easy way to import my bugs from the API 
tracker (http://www.cellml.org/tools/api/api_tracker) into this new one? 
Presumably the existing API tracker will disappear at some point in the 
future? I guess this also raises the issue of whether people should be 
using this new tracker or the existing ones at cellml.org? I see on the 
main page there is a comment that tracker.physiomeproject.org is the 
CellML Tracker test site - is that correct? and we should still be using 
the cellml.org trackers until testing is finished?

There still seem to be a few unresolved issues from the bugzilla 
evaluation and testing process, most notably 
https://tracker.physiomeproject.org/show_bug.cgi?id=158 and 
https://tracker.physiomeproject.org/show_bug.cgi?id=159. I was just 
wondering if these have actually been resolved but not marked as such, 
or if they are still outstanding issues? If the latter are there any 
plans is to resolve them?

a couple more comments below...

> We have now got an issue tracker for the CellML and other 
> physiome-related projects available at 
> https://tracker.physiomeproject.org/ .

This seems a very much CellML-centric tracker, just wondering how it 
relates to the other Physiome projects?

> If you find any problems with the tracker itself, then please submit a 
> tracker item (log in, then choose "Submit Bug Report" [navigation area 
> on the left] => cellml.org site => Choose 'CellML Tracker' as the 
> component and fill in the rest of the form). If you are unable to create 
> a tracker item, then you can let me know of the issue by e-mail.

This seems a bit misleading for a Physiome Project tracker. Surely this 
should be somehow tied to the physiomeproject.org website?


Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

[cellml-discussion] Bug in new code generation services?

[David Nickerson]

I have just added a tracker item in the API tracker 
(http://www.cellml.org/tools/api/api_tracker/10/) detailing a problem 
with component scoped units when using the CellML2C application built 
from current svn trunk code (revision 1826). The minimal example 
attached to this bug in the tracker demonstrates the problem and works 
as expected in a version of CellML2C built from source prior to the 
merging of the new code generation services into the trunk - not sure if 
that is related to this bug. I have tested with revision 1336.



Andre.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Include_in_CellML_1.2 requested: [Tracker Item193] CellML namespaces policy for CellML 1.2 (and beyond)

[David Nickerson]

xample, adding a new
> attribute into an element) work like this: the element with the old semantics
> is kept in the original namespace, but another element with the new semantics
> and with the same local name is added, but in the new namespace. If the new
> semantics are significantly better than the old semantics in all cases, then
> the old element is marked deprecated. If the new semantics extend the old
> semantics but in some cases are no better, then tools are encouraged to output
> the element in the original format unless they want to use a feature only
> available under the new semantics.
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Bug in API configure script?

[David Nickerson]

Hi Andrew,

In that case, I should probably mention that I filed a couple of other 
bugs in the old tracker yesterday in addition to this one.

It would be good if these issues could be updated in the old tracker 
with any progress (if any) until such time that the new tracker is 
available to the community.


Thanks,
Andre.

Andrew Miller wrote:
> David Nickerson wrote:
>> Hi all,
>>
>> Not sure if anyone checks the existing API tracker on cellml.org, but I 
>> just filed an issue 
>> (http://www.cellml.org/tools/api/api_tracker/7/pcng_issue_view) on the 
>> configure option requirements when building the API DOM implementation 
>> from source.
>>   
> Hi Andre,
> 
> No one checks the old tracker (in fact, it is scheduled to be deleted 
> very shortly, I believe), although now you have alerted us to the issue, 
> I have added a tracker item 190 at 
> http://bioeng44.bioeng.auckland.ac.nz:8000/cellml_tracker/ (you will 
> have to tunnel in to see this unfortunately, although IT are working on 
> getting the tracker up somewhere where it will be publicly visible).
> 
> Best regards,
> Andrew
>> Andre.
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>   
> 
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] online subversion browser?

[David Nickerson]

Thanks Matt. Would be nice to get a permanent solution soon...

Andre.

Matt Halstead wrote:
> There is this which I have still set up to sync every 5 minutes.
> 
> http://trac.bioeng5.bioeng.auckland.ac.nz/physiomesynctrac/browser
> 
> You would be after:
> 
> http://trac.bioeng5.bioeng.auckland.ac.nz/physiomesynctrac/browser/CellML_DOM_API/trunk
> 
> While this was put up for demonstration purposes, I don't see any
> reason to remove it until we have a permanent solution.
> 
> cheers
> Matt
> 
> 
> On 10/1/07, David Nickerson <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> I was just wondering if there is any possibility at providing a ViewVC
>> or similar interface to the subversion repository housing the API
>> implementation
>> (https://svn.physiomeproject.org/svn/physiome/CellML_DOM_API/trunk/)?
>> This would make (my) life much easier for browsing around the source
>> tree and comparing versions etc.
>>
>>
>> Thanks,
>> Andre.
>> ___
>> cellml-discussion mailing list
>> cellml-discussion@cellml.org
>> http://www.cellml.org/mailman/listinfo/cellml-discussion
>>
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

-- 
David Nickerson, PhD
Research Fellow
Division of Bioengineering
Faculty of Engineering
National University of Singapore
Email: [EMAIL PROTECTED]
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion