Re: [cellml-discussion] Mailing list migration
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 david.nicker...@gmail.com 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
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 david.nicker...@gmail.com 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] Mailing list migration
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
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 n.lenov...@gmail.com 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
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
-- Forwarded message -- From: Golebiewski, Martin martin.golebiew...@h-its.org 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 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
-- Forwarded message -- From: Moraru,Ion mor...@panda.uchc.edu Date: Mon, Apr 22, 2013 at 9:17 AM Subject: [Combine-announce] HARMONY travel funds To: combine-annou...@mbine.org 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
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=Featurepage=1state=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
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
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
[cellml-discussion] 7th International CellML Workshop - accommodation options
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
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 - registration now open.
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
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 david.nicker...@gmail.com 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
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
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 david.nicker...@gmail.com 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 david.nicker...@gmail.com 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
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 david.nicker...@gmail.com 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
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
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
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
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 dagmar.waltem...@uni-rostock.de 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=trueformkey=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
*Dear all, At the 5th International CellML Workshophttp://www.cellml.org/community/events/workshop/2011/, 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 55https://tracker.physiomeproject.org/showdependencytree.cgi?id=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 http://co.mbine.org/events/COMBINE_2012/agenda. 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 55https://tracker.physiomeproject.org/show_bug.cgi?id=55, we would like to highlight the following main changes that we think should be in CellML 1.2: - Remove reaction element (tracker item 49https://tracker.physiomeproject.org/show_bug.cgi?id=49 ); - Remove the directional aspect of connections (tracker item 337https://tracker.physiomeproject.org/show_bug.cgi?id=337 ); - Replace grouping with a simplified encapsulation-only mechanism (tracker item 356 https://tracker.physiomeproject.org/show_bug.cgi?id=356); - Delayed variables (introduction of the evaluatedAt operator with reduced functionality to allow infinitesimal delays and initial values) (tracker item 70 https://tracker.physiomeproject.org/show_bug.cgi?id=70). In addition, we specifically ask for feedback on the issue of moving to MathML 3.0 (tracker item 67https://tracker.physiomeproject.org/show_bug.cgi?id=67) and the inclusion of stochastic variation in models (tracker item 2809https://tracker.physiomeproject.org/show_bug.cgi?id=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
Re: [cellml-discussion] naive questions about modeling blood-brain barrier and its disruption
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. maude...@odu.edu 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
-- Forwarded message -- From: Michael Hucka mhu...@caltech.edu 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
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 ak.mil...@auckland.ac.nz 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
-- Forwarded message -- From: Michael Hucka mhu...@caltech.edu 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
*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
-- Forwarded message -- From: Nicolas Le Novère le...@ebi.ac.uk 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
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
Possibly of interest to some... -- Forwarded message -- From: Stuart Moodie moo...@ebi.ac.uk Date: Sat, Jan 7, 2012 at 12:47 AM Subject: [sbml-discuss] Draft Distrib Package Proposal To: SBML Discussion List sbml-disc...@caltech.edu 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] Announcing the 2012 CellML Workshop
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] Improved CellML support in latest version of JSim
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] Summary of the inaugural CellML Editorial Board meeting
*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] Independent variables, and delay
Hi Lucian, On Sat, Dec 17, 2011 at 7:53 AM, Lucian Smith lpsm...@spod-central.org 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
Re: [cellml-discussion] Independent variables, and delay
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
[cellml-discussion] IEEE e-Science 2011 WISC Call for Participation
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
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 mn...@u.washington.edu 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 mn...@u.washington.edu 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 david.nicker...@gmail.com Subject: Re: [cellml-discussion] nested components in CellML To: CellML Discussion List cellml-discussion@cellml.org Message-ID: CADizRjhqHMOpDDm=8xoZLAD=bcognsm0xdlfma6yeox20k-...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 22, 2011 at 10:10 AM, Lucian Smith lpsm...@spod-central.org wrote: * Maxwell Neal mn...@u.washington.edu [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 End of cellml-discussion Digest, Vol 87, Issue 9 -- ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion End of cellml-discussion Digest, Vol 87, Issue 10 * ___ cellml-discussion mailing list cellml-discussion@cellml.org http://lists.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] nested components in CellML
On Sat, Oct 22, 2011 at 10:10 AM, Lucian Smith lpsm...@spod-central.org wrote: * Maxwell Neal mn...@u.washington.edu [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
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
[cellml-discussion] Workshop on Interoperability in Scientific Computing
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
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 mhu...@caltech.edu 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
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
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
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
* 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
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 gjfelix2...@hotmail.com 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
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 r.brit...@auckland.ac.nz 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 alan.ga...@dpag.ox.ac.uk 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
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 j.ma...@auckland.ac.nz 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
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
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, we
don't see this as a major issue blocking the
Re: [cellml-discussion] Auto-generate HDF5 from CellML?
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] CellML IRC
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
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
[cellml-discussion] decompose - a model decomposition utility
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: decision about theaddition of a CellML API side RDF parsing service
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
Re: [cellml-discussion] Call for community input: final decisions on anumber of specification related issues
) - 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] Call for community input: final decisionson anumber of specification related issues
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] 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? 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
/ c12:variable name=concentration_y units=mol_per_litre public_interface=yes / c12:variable name=flux_a public_interface=yes type=set_of_lambda_of_real units=mol_per_litre_per_second / c12:variable name=flux_b public_interface=yes type=set_of_lambda_of_real units=mol_per_litre_per_second / c12:variable name=flux_x public_interface=yes type=set_of_lambda_of_real units=mol_per_litre_per_second / c12:variable name=flux_y public_interface=yes type=set_of_lambda_of_real units=mol_per_litre_per_second / /component c12:connection component_1=substance_a component_2=reaction_a_b_x variable_ref variable_1=concentration variable_2=concentration_a / variable_ref variable_1=flux variable_2=flux_a / /c12:connection c12:connection component_1=substance_b component_2=reaction_a_b_x variable_ref variable_1=concentration variable_2=concentration_b / variable_ref variable_1=flux variable_2=flux_b / /c12:connection c12:connection component_1=substance_x component_2=reaction_a_b_x variable_ref variable_1=concentration variable_2=concentration_x / variable_ref variable_1=flux variable_2=flux_x / /c12:connection c12:connection component_1=substance_a component_2=reaction_a_x_y variable_ref variable_1=concentration variable_2=concentration_a / variable_ref variable_1=flux variable_2=flux_a / /c12:connection c12:connection component_1=substance_x component_2=reaction_a_x_y variable_ref variable_1=concentration variable_2=concentration_x / variable_ref variable_1=flux variable_2=flux_x / /c12:connection c12:connection component_1=substance_y component_2=reaction_a_x_y variable_ref variable_1=concentration variable_2=concentration_y / variable_ref variable_1=flux variable_2=flux_y / /c12:connection c12:connection component_1=substance_a component_2=abxy_system variable_ref variable_1=concentration variable_2=concentration_a / variable_ref variable_1=flux variable_2=flux_a / /c12:connection c12:connection component_1=substance_b component_2=abxy_system variable_ref variable_1=concentration variable_2=concentration_b / variable_ref variable_1=flux variable_2=flux_b / /c12:connection c12:connection component_1=substance_x component_2=abxy_system variable_ref variable_1=concentration variable_2=concentration_x / variable_ref variable_1=flux variable_2=flux_x / /c12:connection c12:connection component_1=substance_y component_2=abxy_system variable_ref variable_1=concentration variable_2=concentration_y / variable_ref variable_1=flux variable_2=flux_y / /c12:connection c12:encapsulation component_ref component=abxy_system component_ref component=substance_a/ component_ref component=substance_b/ component_ref component=substance_x/ component_ref component=substance_y/ component_ref component=reaction_a_b_x/ component_ref component=reaction_a_x_y/ /component_ref /c12:encapsulation !-- Units would also be defined here, as in CellML 1.1... -- /model ___ 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
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] CellML terminology: distinguishingCellMLmodels from the XML in which they are represented
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] specification draft and docbook
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
Re: [cellml-discussion] My specification draft in progress is nowpushed to the CellML site
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
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']
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
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
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] Include_in_CellML_1.2 requested: [Tracker Item193] CellML namespaces policy for CellML 1.2 (and beyond)
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
[cellml-discussion] Bug in API configure script?
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. Andre. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
[cellml-discussion] online subversion browser?
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
Re: [cellml-discussion] online subversion browser?
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
Re: [cellml-discussion] Proposal: Standardised CellMLreal numberformat
So something like (assuming my use of the syntax is correct): (\+|\-|)[0-9]+(\.[0-9]+|)((E|e)(\+|\-|)[0-9]+) Note that I have also 'simplified' the exponent part. I don't think the exponent should be mandatory, however, as this would break the majority of models in use. agreed. My bad, since I obviously agree with that. So, we should have: (\+|\-|)[0-9]+(\.[0-9]+|)((E|e)(\+|\-|)[0-9]+|) And if I have still got the syntax wrong, then please fix it, so we are done and over with it. while its possibly worth having for illustrative purposes, I'm pretty sure we don't want the actual normative definition of the rule to be based on a regular expressiondo we? ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML Versioning Strategy
- At the moment, CellML doesn't explicitly support the rem element (remainder function in MathML), even though CellML does allow its use (at the risk of ending in a situation where a model may work fine in a given CellML tool -- that supports the rem element --, but not in a nother -- that doesn't support the rem element --). Now, say that we officially want CellML to 'support' the rem element, how do we go about doing that? A lot of things are valid CellML but are not supported by everyone (really, the only thing widely supported are systems of ODEs). CellML provides the overarching structure for describing these things, and we need to start to narrow down exactly what tools should be supporting as well, using compatibility documents or something like that which describe a feasible subset of CellML to implement. The could be more than one of these, but we don't want there to be too many similar documents. However, I think we should keep them away from the core of CellML, because CellML's generality is quite useful when it comes to expanding into new types of problems (for example, constitutive laws, PDE systems, and so on). this seems a good approach to be taking. I'm personally in favour of removing the CellML subset of MathML and resorting to such compatibility or best practice documents to apply specific restrictions to what can be used in certain types of mathematical models represented in CellML. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] cellml poster for ICSB 2007 conference
1) Lower case 'c' in 'cellML': The usual spelling is CellML. The logo uses 'cellML' - I guess the person to ask is Poul, but I'll use 'CellML' for now. the logo is a graphic that also has extra writing beneath the word cellML and three arrows above the 'c', hence the lower case, as well as mixed black and red colours. 'CellML' has been the standard in scientific literature, at least in the articles that I have published :) 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: [TrackerItem153] Allow multiple connections between the same pair of components
Hi Jonna, Jonna Terkildsen wrote: Dear Andre, I appreciate that a change such as this would not be useful for you in terms of the way you set up your models. But I believe you have to consider the fact that every person who creates models has their own way of debugging or checking for errors. As such, this could (and would) be a useful change for those (such as myself) who like to list all the in connections to a component directly next to that component to be able to quickly see that they have made all the appropriate connections. I personally find this is a lot easier for debugging than having a big clump of connections at the end of a model. I appreciate that this may not conform to current best practice, but it works for me. But I'm not writing to debate the pros and cons of coding styles. It seems to me that this change would be useful to some users (namely myself and some others here at the Bioengineering Institute) and as it doesn't (in my mind at least) change the meaning of the CellML, I can't see why it should be an issue. while I think I point out some issues in my previous emails, I'm certainly not trying to say that my way is the best, merely pointing out that there are CellML users happy with the current standard. I think you'll also find that using CellML 1.1 a lot of these problems go away as you only ever have one, or at most a few, components per model so you can easily achieve a coding style like your current one without needing to change the specification. I'm similarly not really interested in a debate on best practices for coding CellML XML by hand, just putting forward my objection to making such a change to the specification. Andre. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] on a CellML format
Hi Taishin, Firstly, I think most people on the team list are also on the cellml-discussion list so I'm dropping off the CC to the team list. Rest on my comments inline below... Taishin Nomura wrote: Dear all, We had a discussion on CellML format in response to the comment made by Bandall. In our discussion, we tried to illustrate structure of coupled_pendulum.cellml. We are not sure whether or not you are interseted in this discussion. Nevertheless, we would like to make this clear so that we can continue our effort to completely support cellml API since we believe it has a definite meaning. A dominant part of the file we are going to argue may be like fig. 1 shown temporalily at http://www3.bpe.es.osaka-u.ac.jp/~suzuki/coupled_pendulum.pdf This page will be closed when dicussion stops. The corresponding structue may roughly be represented in fig. 2 as a schematic diagram. Then, possible implication of private_interface and public_interface, based on our understanding, is added to the diagram as fig. 3, where red lines indicate public_interface and blue lines private_interface. Can we share the understanding of this diagram? yep - very nice diagrams! Suppose yes, then we have several questions and comments. # On a Redundant definition of the initial value The initial value of variable name=b at component name=Pendulum and variable name=b at component name=PendulumLowerSegment are defined redundantly as indicated by fig. 4. Is there any reason for this redundant definition? Please let us know. This is becuase if these two redundantly defined initial values are not identical, it may cause a problem. definitely, as you describe the model the initial_value attribute for the b variable in the Pendulum component is not only redundant it is invalid CellML. (you can't have an initial_value if any of the interfaces is 'in'.) Note that we are aware of the fact that variable name=b at component name=Pendulum implies variable name=b at component name=PendulumLowerSegment using connection property. We are also aware of the fact that the redundant definition of variable name=b at component name=Pendulum and variable name=b at component name=PendulumLowerSegment is natural and necessary to allow other components to utilze variable name=b of component name=Pendulum which is encapsulated. yep - that all makes sense. # Policy on location of definition of equations and initial values For example, variable name=a_angular_velocity is defined both in component name=Pendulum and in component name=PendulumUpperSegment. This is okay for the same reason mentined above. However, in this case, the initial value is defined in component name=Pendulum, but no definition of equations, while the equation is defined in component name=PendulumUpperSegment, but no definition of the initial value. I think you have name=Pendulum and name=PendulumUpperSegment swapped around, but again this is invalid CellML. Since variable a_angular_velocity (and also b_angular_velocity) has a private interface of 'in', it is invalid to define the differential equation d(a_angular_velocity)/dt in the Pendulum component. Regarding this sort of distributed definitions of properties of an object, we would like to know your policy. Of course, the current situation is fairly lax and the user can define a property anywhere within an encapsuled component, even in a component in the encapsulated component. However, it could be a source of errors if we have to deal with a complicated model with many properties and components. I think this is because the model you are describing is invalid. This kind of distributed definition of properties is invalid CellML (as far as I can tell). Only the component which owns a variable (i.e., the component in which the variable is defined with no interface of in) is allowed to alter the variable's value - either with an initial_value or some mathematical equation. # An alternative way to describe the pendulum (A proposal) Fig. 5 is an alternative structure to describe the pendulum. It seems that this is natural in the following sense: every variable such as variable name=a_angular_velocity or variable name=b_angular_velocity has both the initial value and the equation together. Then, the encapsulted component name=Pendulum plays a simple role to put component name=PendulumUpperSegment and component name=PendulumLowerSegment together within a single component. There may be other kinds of structure such as a case illustrated in Fig. 6. Both of these look correct to me, although the one in Fig. 5 seems more natural to me :-) Looking back, I see this is the PCEnv test model that Randall mentioned a while back. And looking at that original code it certainly looks like an invalid model to me...and passing it through Jonathan's validator (https://chaste.ediamond.ox.ac.uk/cellml/)
Re: [cellml-discussion] CeVAS, CUSES, MaLaES
Thanks Andrew. So just to make sure I'm getting it right, in the trunk code CCGS is now a service sitting on top of CaVAS, MaLaES, etc., right? Andre. Andrew Miller wrote: David Nickerson wrote: Hi all, I have just done an update on my working copy of the CellML API C++ implementation and have found that new version of the code generation services (?) have arrived. While I presume the CCGS code is still complete and working (if I can get it to build), but I just wanted to check if the new code is ready for use and if there was any help available to ease changing from the old CCGS to the new methods? I'm hoping documentation and/or examples...(something like the current CCGS/tests/CellML2C.cpp would be good and may already be in there somewhere...) Hi Andre, The new services have landed a while ago on the trunk after being tested on a branch. There are still a few issues being ironed out (mainly regarding how invalid CellML models are handled, and ensuring that we don't crash on them and instead report a useful error), but the new CCGS is being used in PCEnv snapshot builds. Firstly, the interfaces for CCGS have been updated, and the comments on the interfaces have been updated to reflect what the interface now does. The interface changes are fairly minor (the major change is that the concept of iterating variables has now become iterating 'computation targets', which are basically variables plus a degree to which that variable is differentiated, as well as differences allowing you to configure the CCGS to generate languages other than C). Bound variables have been renamed to variables of integration, and the structure of the generated code if you don't do any configuration has changed somewhat, as there is now a separate array for algebraic and state variables rather than squashing everything into a single variables array. Also, CCGS/tests/CellML2C.cpp has been updated and should still be working with the new code (it is used for the automated tests, which still pass). Best regards, Andrew 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
Re: [cellml-discussion] CeVAS, CUSES, MaLaES
Andrew Miller wrote: David Nickerson wrote: Thanks Andrew. So just to make sure I'm getting it right, in the trunk code CCGS is now a service sitting on top of CaVAS, MaLaES, etc., right? Thats right, so you need to enable those services in configure in order to enable CCGS. ok, thanks. if I just do a '--enable-ccgs' on my configure, does that enable the new services or do I need to explicitly enable each one? (my current configure command is something like: ../source/configure --prefix $HOME/std-libs/physiome/ --enable-corba=no --enable-context=no --enable-ccgs --enable-cis=no --enable-server=no --enable-static --enable-shared=no ) Might be nice for the API documentation on the website to be updated to describe all this...although I guess its covered under the last item on the current milestone page (http://www.cellml.org/tools/api/Milestones). Thanks, Andre. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML technical question.
://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ 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 Tracker being tested athttp://bowmore.elyt.com/bugzilla/
Hi Andrew, Just to point out that you might want to update the front page to indicate that this tracker is not in fact maintained at the University of Auckland. David. Andrew Miller wrote: Hi all, Following discussions with the IT group yesterday, we have arranged to set up the Bugzilla based CellML tracker for testing on an externally hosted site. The URL is http://bowmore.elyt.com/bugzilla/ This will not be the final tracker URL (and may not be the final tracker technology), as there is currently a process underway to evaluate the best tracker. However, part of this process will require actually using a tracker to see what the final result is. Users are encouraged to try out the tracker to submit and view real questions and bugs (at this point in time, this tracker is the best place at least to report PCEnv and CellML API bugs, because at the very least the correct person should get an e-mail about your submission). You feedback on using the tracker will also be valuable, as it will help inform future decisions on what tracker technology to use and/or improvements to the tracker resources. If you are able to do so, putting it on the tracker would be a good way to handle such comments, otherwise they could also be e-mailed directly to the list. Note that all new tracker items are sent to this list (unless you choose one of the private question / security issue options), and you also have the option when commenting on an issue to send your comment to the list. Best regards, Andrew Miller ___ 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] embedded stimulus currents in CellML models
Still, I have managed to recompile it. Oops, this got sent too early and I have yet to get CellML2Dot to compile... In fact, I have given up and I think it does illustrate the point I made in a previous message of mine: documentation, documentation, documentation... :) I was a bit surprised that you had managed it :-) The first step is to get the CellML API built, from there it should be easy ;-) ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] [Tracker Item 43] New: typo in simplified (?)interface
just to follow up, submitting this tracker item resulted in An internal server error occurred. Please try again later. even though it would appear that the tracker item was successfully entered into the tracker database. [EMAIL PROTECTED] wrote: http://bowmore.elyt.com/bugzilla/show_bug.cgi?id=43 Summary: typo in simplified (?) interface Product: cellml.org site Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: Very high priority Component: CellML Tracker AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] on the page http://bowmore.elyt.com/bugzilla/enter_bug.cgi?product=Using%20CellMLformat=generalhelp there is a missing space in the second sentence of the Keep Private help text. -- 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_1.1.1 requested: [Tracker Item48]Deprecation of the reaction element
sorry, I was more meaning what it means that you have asked for something and what we're supposed to do about it? But, yes - inclusion_CellML_1.1.1 might be better, or maybe target_CellML_version_1.1.1? for_inclusion_in_CellML_1.1.1 ? Andrew Miller wrote: David Nickerson wrote: What does this mean? I guess that CellML_1.1.1 is a bad name for the flag. Flags are a generic facility in Bugzilla which are requested and then granted or denied. I intended for this to be used for proposals to be requested for CellML 1.1.1 (i.e. suggested for a given version of CellML), and then granted or denied based on community consensus. How about Inclusion_CellML_1.1.1 and Inclusion_CellML_1.2 instead? 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] curation of BioModels Database
For example, models that are designed simply as test-cases for particular expected software behaviour - where the structure and expected behaviour of the model are well known but not described in any specific published article. From what I remember, MIRIAM uses published articles as the reference description of a model in regard to MIRIAM compliance, but could another source reference description be used in model curation, albeit not in conjunction with MIRIAM compliance? This is actually incorrect. MIRIAM does not require publication in an article. It requires a unique reference description, that can be an article, a technical report, a web-page etc. ok - thanks for the clarification! finally that one can reproduce published results *using different software than the one used by the authors*. I think this is very important requirement for model curation, but one that is quite daunting for CellML models, especially CellML 1.1 based models. One question I have is how different different tools need to be to satisfy such curation? What I'm getting at is that there could potentially be many different tools based on a common library (the CellML API and code generation service, or libSBML for example), but to me these wouldn't be different enough as the actual interpretation of the model is essentially done by the common layer underneath whatever extra bits the specific tool is adding in. Or is throwing the model through a different numerical integrator, for example, enough to satisfy this requirement? :-) We did not formalise that far. You are entirely right of course. Let's say it very much depends on the model. Some can be simulated in many software and it is easy to get the results using different solvers. Some tricky models can only be simulated by a couple of software ... this is also a problem for CellML models since (currently) only applications built using the CellML API C++ implementation from the Auckland group can handle the newer CellML 1.1 models. While you'd hope it never happens, it is possible for errors in the API implementation to show up differently in different applications. Not much we can do about it though, except to be aware of such factors while curating and annotating CellML models. David. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] [TrackerItem 42]New: CellML1.1.1specification
Andrew Miller wrote: David Nickerson wrote: From what I gather, publicity. We need some way to direct people's attention to our intention to deprecate reaction elements. sure - but its still not clear to me if 1.1.1 is making clear our intention to deprecate reaction elements or if it is making reaction elements invalid in a 1.1.1 version model? I think that both are true: 1) Reaction elements would be invalid in the 1.1.1 specification I proposed. 2) Versions of CellML earlier than 1.1.1 would be deprecated by virtue of the fact that they are no longer the latest version of CellML, and therefore reaction elements are deprecated. but neither of these address our intention to deprecate the reaction element. I think that people who look at CellML at present are not sufficiently discouraged from using reaction elements, and I agree that a new version is reasonable to publicise what we as a community think is the proper direction for CellML. just to reiterate, when raising the issue of marking the reaction element for deprecation in the final 1.1 specification the decision was made to not do so and at the time it was also decided that the next version of cellml would be the one to formally mark the reaction element for deprecation. If this decision has been revisited and found in error, then the errata for the 1.1 specification should be updated to reflect that. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] embedded stimulus currents in CellML models
I think the current use of an embedded stimulus current is due to the repository being limited to CellML 1.0 models. The correct way to approach this problem is this: (1) define the mathematical model independent of parameter values and boundary/initial conditions; (2) (this is an optional step) import the mathematical model into a model which defines the common parameters and boundary conditions; (3) then import this model into any simulation specific models - it is at this level you define the particular stimulus protocol or other simulation specific parameter values and/or boundary conditions. For the case of a tissue/multi-cellular simulation, you'd probably use either (1) or (2) depending on the requirements of the tissue model and then connect the diffusive stimulus current to the single cell model stimulus current. While people (including myself) often point out the stimulus current as a special case, it is not really. Any extra or modified current being added to a model can be handled in the same way. For example, the way a (potassium) stimulus current is handled should not be any different to the case where you add the K(ATP) current to a model which does not already have one. This looks like a very sound approach to me, but this relies on using CellML 1.1 and though I would very much welcome a wider use of CellML 1.1, I cannot help but wonder what to do with CellML 1.0 models... Unfortunately, I can't see any way to do this with 1.0 models other than to have multiple copies of the entire model with and without various boundary conditions imposed. This is, of course, one of the main reasons for CellML 1.1 :-) Generally what I have done in the past for tissue models, is to use the simulation software to override aspects of the (1.0) cellular model as required for the particular tissue simulation. This would be enhanced by the use of the kinds of metadata mentioned below, which would allow software to automatically interpret certain key variables (stimulus currents, for example in electrophysiology models) - rather than the manual process currently employed (in CMISS). Personally, I would hope switching an application to using the CellML API and hence being able to handle CellML 1.1 models would be a much easier process than writing code to interpret certain pieces of metadata :-) There probably is a case for making stimulus protocols a little more explicit in domain specific interfaces. The proper way to handle this without compromising the generality of CellML would be to add metadata describing which variables are, for example, stimulus voltages, and which components (which will generally be imported components) are stimulus currents. This might be a very useful thing to have indeed (or rather: it wouldn't harm having such information available). yep - and I think this is part of the general annotation of variables in models. Again, there is really nothing special about a stimulus current variable in a model, just in the simulation software's use of the variable. A domain specific command could then perform tasks such as, for example, replacing the stimulus protocol connected to the designated variables with a 'standard' stimulus of a user defined nature (which could be an arbitrary mathematical function, or even a FieldML field). A curve-based graphical editor for some small subset of MathML (which lets you drag points around on the screen to edit MathML parameters) would also make it easier to input and edit stimuli. Yes, that's the kind of thing we had started doing long before CellML was available, and therefore something that some modellers would at least very much welcome indeed. Its also something that is currently available in CMISS :-) Andre. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Tracker for Roadmap
Hi Randall, Two quick points. PCEnv is an Auckland tool and as discussed previously it should be kept quite distinct from the community sections of cellml.org - i.e., there shouldn't be a common tracker for PCEnv and the specifications and cellml.org etc. Secondly, Matt and I have been looking into the use of the Plone Software Centre for dealing with the core CellML projects (specifications, model repository(s), and API). While not perfect this seems a good way to start collecting proposals and turning them into actual action items in associated trackers. While this effort has kind of stalled as things like the test server and python/plone upgrades are happening, you can see an initial start at http://www.cellml.org/Members/andre/andre-s-test-cellml-centre/. If you're looking into this sort if thing (or anyone else out there) it would be great if you can have a play around in there and let us know what your thoughts are. Andre. Randall Britten wrote: Hi At last week's meeting, we listed some items for the updated roadmap for PcEnv. The existing roadmap/milestones list is quite out of date. I am considering using the PcEnv tracker to manage this list, in the hope that as features are implemented, they will be marked as resolved in the tracker, facilitating keeping the list up to date. This approach could also be used for the other roadmaps, e.g. repository, specifications, general cellml site etc. In my experience on previous projects, using some form of tracker for roadmaps works well. Although PloneCollectorNG seems inferior (in my opinion) to other trackers (e.g. Jira), it has the advantage that it is integrated into the rest of the site. So, in the interest of taking small steps, I think we should stick with it for now. Your feedback would be appreciated. Thanks. Regards, Randall ___ 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 tracker
Andrew Miller wrote: Hi, At the Auckland CellML meeting today, we discussed the possibility of changing to a better tracker and moving some of the mailing list discussions onto that tracker. Everyone at the meeting agreed with this idea, so I am now looking for some input from the wider CellML community. By doing this, we are aiming to address several issues: 1) There is often lot of traffic on the mailing lists, but people are having difficulty following it. It was suggested that we could instead carry out these discussions on a good bug-tracker (which supports CC lists). We could broadcast newly created issues to the list, and everyone who was interested in following up on the issue could then add their address to the CC list and therefore see any comments being added to the tracker. This would ensure that everyone has the opportunity to follow topics they are interested in, but users don't get flooded with issues they don't care about. The problem I have with this approach is that issues initially submitted to the list have a tendency to expand into much wider discussions, as we have seen in some of the threads on the discussion list recently. So while I may not be interested in the initial topic and hence don't subscribe to it, the ensuing discussion might be very interesting. I would miss it all unless I continually check all the tracker items for possibly interesting followups - which would be a lot of work. I much prefer to have one place to look (my inbox) and use my tool of preference to filter that as I see fit. I guess such problems could be avoided if we could be assured that there is some moderation of the tracker items such that if the moderator decides the discussion has broadened sufficiently they could let the wider community know in case more people want to join the discussion. While I can still see many flaws in such an approach, it might work out ok in most cases. 2) Our present tracker makes it hard to browse issues by category (there are sort functions, but the user interface is not usable enough to use it regularly to see all the bugs for a given component and so on). The consequence of this is that we end up with lots of small trackers, e.g. one for PCEnv, one for the CellML API, one for the site, and moving issues between them is cumbersome (e.g. a bug filed by an end user about PCEnv might actually turn out to be a CellML API issue or even a CellML specification issue). I don't know if I see any problem here? As a novice PCEnv user I would submit a bug in the PCEnv tracker - to me it doesn't matter if that bug turns out to be a bug in the API, compilers, or anything else - to me its simply a PCEnv bug. I would expect a PCEnv issue would need to be reformulated by a PCEnv developer to make sense submitting it as a API or specification issue anyway, so it would not generally be a straight copy or move operation from one tracker to another. And the initial bug submitter is probably just interested in when the bug is fixed in PCEnv, not the API or specification. While it might be nice to simply tag a submitted issue with extra categories, I would see this as more of a convenience than any absolutely required functionality. There would need to be a more compelling reason for such a drastic move as dropping the current plone based trackers. If we had a good tracker, we could let all discussion take place on it. We could also have one big CellML tracker which collected bugs (in the general sense, which means everything from a concept through to a proposal through to an implementation) for everyone doing CellML related work (both at Auckland and for other groups which also wanted to use the tracker), which would hopefully increase the community focus of the CellML project, and make it easier for people to follow the issues they are interested in. As I pointed out to Randall in an earlier thread, we are currently working on this using the existing plone tools. Have a look at http://www.cellml.org/Members/andre/andre-s-test-cellml-centre/ and let us know what you think. If we used a Plone based tracker, we would be able to have a single search which searched both the CellML site and the tracker. However, I think that this is just one consideration, and as Randall pointed out today, it already doesn't integrate with mailman. I think that both PloneCollectorNG and Poi lack the sort of usability that we require to make the tracker useful. While they may be able to support some of the features we need with a bit of coding, I don't think anyone has the time to do this, and so a more well established tracker with a larger set of features available out of the box would probably be better. Whats wrong with using google to do a web search? Mailman itself doesn't provide any search functionality anyway, unless it just hasn't been enabled for the cellml.org mailing lists, so searching
Re: [cellml-discussion] Proposal: Local CellML team e-mail addresses
Andrew Miller wrote: David Nickerson wrote: Hi Andrew, I think this is an excessive response to a very minor problem. I very easily see this evolving into many separate and distinct local communities with little interaction. The intention is that these lists only be used for messages like 'There is a meeting on Level 6 at 10:00 am on Tuesday this week', or 'The recently announced release can be run by on Linux by local users from /people/blah/binaries/myprog', rather than significant CellML related issues, and that is the goal of my guideline. what is the benefit of a public archive of such messages? I think that there are already very separate and distinct local communities (we hardly ever hear from many of the communities who are working on CellML), and the idea is that by acknowledging this and providing an archived, open resource for local discussions with an encouragement to send non-local messages to the more general list, we can actively build stronger community interactions. Perhaps some examples of these local communities you envision might help? The ones that I know about that you might be referring to are (and the groups involved): - The integration of CellML with JSim (Washington, Singapore, Auckland) - The use of the CellML API in non-Auckland based tools (Kyoto, Osaka, Oxford, Singapore, Auckland) - Model curation (the definition of level 4 curation) (Washington, Wisconsin, Oxford, Singapore, Auckland) and probably others that I can't recall. Not sure how your idea of local communities would address these, and given the effort I have put into getting these discussion on the cellml-discussion mailing list, with little success, I don't see anything changing in the future. For the same reasons we removed the cellml-tools mailing list, I would very much like to see cellml-discussion remain as the only public forum for discussing CellML related issues, until such time as we decide that the list is being flooded with too many emails on one topic and we separate that topic off onto its own mailing list. I have yet to see any need for this. Although a lot of messages currently get sent directly to interested recipients to avoid flooding the list, and moving these onto a local list would cause them to be archived. as above, I'm not sure who your target is other than the Auckland group? and how you would get these personal discussions to take place on a publicly archived mailing list? and if you can achieve this it would be much more beneficial to the community to have them moved onto the cellml-discussion list rather than a local one. The idea of the team-cellml mailing list was for discussion amongst the original Auckland team on issues relating to the underlying functioning of the CellML project and a place to debate decisions when consensus could not be achieved amongst the wider CellML community. The [EMAIL PROTECTED] mailing list would not serve this purpose. I don't think that we need a separate mailing list for this, because there is no need to tie decision making processes to the mailing list. The process for developing a given resource is ultimately determined by whoever funds that resource, and the people who make the final decision can do so on the basis of discussions (which may include them) on the list. I don't see any need for a second mailing list for this. This is true and suitable for particular locally-based and driven resources (such as PCEnv). But for the larger community to succeed, there needs to be at some level a governing body of some kind that ensures (as best as possible within the constraints of time and money) that the project continues to progress with some consistency. The three community resources that I would see governed by such a body are the specifications (CellML and metadata), the model repository, and the API. But I think this is a different topic and not relevant to this discussion. Andre. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] [team-cellml] @cellml.org addresses
Matt wrote: On 6/25/07, David Nickerson [EMAIL PROTECTED] wrote: Matt wrote: This seems like it's going in circles. I'm not really sure why anyone would want to contact us personally with something they didn't want to send to the list. Thinking about this more we should probably try: 1) cellml-discussion@cellml.org 2) [EMAIL PROTECTED] - for specific enquiries that you don't want publicly available. It would make sense to have a nominated person or persons that address mail in there - James I would think - who decides if an email should be forwarded to the list because it really is a public issue - or respond and acknowledge the email and seek a response from those in the team that it seems appropriate to. for all the same reasons why we dropped [EMAIL PROTECTED], I can't see this being a good idea. Right. But I don't see any other resolution given the current circles. I think 'team' is a little more focussed than 'info'. I just vote to give it a try with James managing it actively and see how it goes. but if we go with 3 below why do we still need a [EMAIL PROTECTED] at all? 3) a team page where everyone who is on the team-cellml list has a picture and a small blurb (kind of like http://sbml.org/contacts/) ... which is really just to give a face to those who are quite deeply involved. I would imagine people like Penny Noble to be on that. If someone contacts someone on that page then it will likely be quite personal. this is exactly what we were originally discussing and the SBML page is what I thought we'd be working the cellml.org/team page into. good ___ 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] [team-cellml] @cellml.org addresses
Matt wrote: This seems like it's going in circles. I'm not really sure why anyone would want to contact us personally with something they didn't want to send to the list. Thinking about this more we should probably try: 1) cellml-discussion@cellml.org 2) [EMAIL PROTECTED] - for specific enquiries that you don't want publicly available. It would make sense to have a nominated person or persons that address mail in there - James I would think - who decides if an email should be forwarded to the list because it really is a public issue - or respond and acknowledge the email and seek a response from those in the team that it seems appropriate to. for all the same reasons why we dropped [EMAIL PROTECTED], I can't see this being a good idea. 3) a team page where everyone who is on the team-cellml list has a picture and a small blurb (kind of like http://sbml.org/contacts/) ... which is really just to give a face to those who are quite deeply involved. I would imagine people like Penny Noble to be on that. If someone contacts someone on that page then it will likely be quite personal. this is exactly what we were originally discussing and the SBML page is what I thought we'd be working the cellml.org/team page into. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] model upload problems
James Lawson wrote: Sounds like this is something we should broadcast with a megaphone. There is probably nothing that would irk someone more than uploading a file and it not working. or perhaps, if possible without too much effort, to detect XML files uploaded which don't have a document element of model in the CellML 1.0 namespace and give the user an error and not accept the model? Andre. James Tommy Yu wrote: David Nickerson wrote: Hi, I just tried to load the attached model into the model repository to use as an example with the graphing metadata specification but am having some problems. Firstly, it didn't pick up some of the model metadata during the upload process. At least there were some empty text boxes presented to me that I would have expected to be filled with the metadata from the model. Not sure if that is an error in the upload process or an error in my model metadata? These boxes are still empty later when I got to the metadata editor. Hi Andre, Your metadata is fine, it did get picked up. However, the namespace is CellML 1.1 which the XSLT that generates the documentation (from the tmp-documentation namespace) do not support. Ditto for CellML - MathML XSLT. I see that it is just one file, so I changed it to 1.0 and repository thinks it's okay now. Kind Regards, Tommy. I managed to get it into the repository as http://www.cellml.org/models/sine-approximations_version01 but it doesn't really seem to work. The overview page just says: error occurs during transform. See error log - can I see the error log somewhere or is this just for the site admin to see? The view math tab gives and XML parsing error - a bit strange since I can run simulations of the model fine using my tool based on the CCGS and API and the code generation tab works fine and gives me the expected C code. Anyone have any suggestions? 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 ___ 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] [team-cellml] @cellml.org addresses
In terms of the policy for allocating addresses, we don't want to become a free e-mail redirection host for anyone on the Internet, but I think as long as someone at least has some connection with CellML, they should be allowed an alias (subject to review of what that alias is to ensure it is unlikely to cause confusion or conflict with future lists / aliases we might want to assign). I suggest that we simply give an @cellml.org alias to anyone who asks for one and has a demonstrated interest of some kind in the CellML project (whether they are a modeller using CellML, a tool developer, or interested in some of the theoretical or mathematical aspects of CellML). Simply providing a form to fill out providing details to list, and having someone briefly review them should be sufficient to keep out people who just want the e-mail alias. While I am unsure how much interest or usefulness there is in providing such a service, I guess I have no problems with this suggestion. Although it will require input from the Auckland IT team as to what is required to implement such a service for a larger group than the core management team as we were originally discussing. I don't think we are talking about a very large group of people (there are currently 74 people on the mailing list, and I expect the majority of them wouldn't want to be listed as being contacted). As long as we ask that the alias only be used for CellML-related discussion, I don't see the volume of mail getting out of hand. The first problem with the idea of restricting this to the core management team is that there isn't one, and deciding on one is going to be inherently problematic. The second problem is that even if there was a core management team, they would primarily deal with the maintenance of the CellML specification and the cellml.org website, and not necessarily domain specific aspects of creating CellML models. The proposal to provide people a way to contact each other off-list would probably need to include people who actually create models of various types to be useful, and these people wouldn't be on the core management team. This is really going away from the original intention of this proposal. The idea was to simply provide contact details for the core project members on the Project Team page at cellml.org so that people have some way to contact the project if they preferred (for whatever reason) not to subscribe and send mail to the cellml-discussion list, or if someone has a private idea they would like to discuss with the core project team. The idea of using @cellml.org aliases for this purpose meant that when someone (like James or Catherine) were unlikely to be checking their email, we could ensure the aliases were at least redirected to another person who might be able to help. Following what you are outlining above, I really see no need for @cellml.org aliases. Given this, why not simply make the subscribers list for cellml-discussion visible? assuming there is some way for subscribers to still say keep me private... Having said that, I still see value in the original proposal. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Concerning the CellML Model Repository
Do we really want to proxy remote repositories? Can we start smaller for now but keep that in mind? I think this will be an essential feature of the model repository as we move forward. We are trying to present model authors with a common platform for the distribution and archiving of their models as they go through development and publication cycles. At some point we are going to want to provide some assurances to the community in terms of repository accessibility - things like uptime, backups, redundancy, etc. There is also a big question mark over the implications of the current geographical location of the model repository. For example, how will access scale when you start having tens, if not hundreds, of users around the world interacting with the repository on a regular basis? If things run too slow or access is a problem then people simply won't use the system. So while it makes sense to start out with less grand plans, I think any plan on moving the repository forward has to take these issues into account and discuss how they would be addressed in any future repository implementation. David. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Concerning the CellML Model Repository
It might also be worth looking into what the folks over at http://www.biomodels.net/ are up to. Given they seem to have curation built into their repository and maybe some other features worth looking into? And if we're going to be starting from scratch, there might be some value into seeing how the biomodels repository could be extended to support CellML? When you start seeing comments like BioModels Database ranked first data resource for Systems Biology in Nature Biotechnology, it might be a hint that they're doing something right and we should maybe be working with them rather than independently. David. Tommy Yu wrote: Hi, I have written down some of my thoughts on how the model repository could be put together. http://www.cellml.org/Members/tommy/repository_redesign.html It is still a pretty rough document. The usage example section gives a rough outline on what I see people might be doing with the repository and how this design could address those issues, which I think it will be of interest to users. It is not an exhaustive list, yet. I must also note the design outlined is quite a drastic departure from what we have now (it will be yet another new repository). However, it is more true to the one envisioned before according to http://www.cellml.org/wiki/CellMLModelRepositories, except I have an addition layer that will assist in pulling content and drawing relationships between models. Feel free to take it apart and/or build on top of it. Cheers, Tommy. ___ 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] model upload problems
Hi, I just tried to load the attached model into the model repository to use as an example with the graphing metadata specification but am having some problems. Firstly, it didn't pick up some of the model metadata during the upload process. At least there were some empty text boxes presented to me that I would have expected to be filled with the metadata from the model. Not sure if that is an error in the upload process or an error in my model metadata? These boxes are still empty later when I got to the metadata editor. I managed to get it into the repository as http://www.cellml.org/models/sine-approximations_version01 but it doesn't really seem to work. The overview page just says: error occurs during transform. See error log - can I see the error log somewhere or is this just for the site admin to see? The view math tab gives and XML parsing error - a bit strange since I can run simulations of the model fine using my tool based on the CCGS and API and the code generation tab works fine and gives me the expected C code. Anyone have any suggestions? Thanks, Andre. -- David Nickerson, PhD Research Fellow Division of Bioengineering Faculty of Engineering National University of Singapore Email: [EMAIL PROTECTED] ?xml version=1.0 encoding=iso-8859-1? model name=sine_approximations cmeta:id=sine_approximations xmlns=http://www.cellml.org/cellml/1.1#; xmlns:cellml=http://www.cellml.org/cellml/1.1#; xmlns:cmeta=http://www.cellml.org/metadata/1.0#; rdf:RDF xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#; xmlns:cmeta=http://www.cellml.org/metadata/1.0#; xmlns:bqs=http://www.cellml.org/bqs/1.0#; xmlns:dc=http://purl.org/dc/elements/1.1/; xmlns:dcterms=http://purl.org/dc/terms/; xmlns:vCard=http://www.w3.org/2001/vcard-rdf/3.0#; xmlns:cs=http://www.cellml.org/metadata/simulation/1.0#; xmlns:cg=http://www.cellml.org/metadata/graphs/1.0#; rdf:Description rdf:about= dc:creator rdf:parseType=Resource vCard:N rdf:parseType=Resource vCard:FamilyNickerson/vCard:Family vCard:GivenDavid/vCard:Given /vCard:N vCard:EMAIL rdf:parseType=Resource rdf:value[EMAIL PROTECTED]/rdf:value rdf:type rdf:resource=http://imc.org/vCard/3.0#internet; / /vCard:EMAIL vCard:ORG rdf:parseType=Resource vCard:OrgnameNational University of Singapore/vCard:Orgname vCard:OrgunitDivision of Bioengineering/vCard:Orgunit /vCard:ORG /dc:creator dcterms:created rdf:parseType=Resource dcterms:W3CDTF2006-12-21/dcterms:W3CDTF /dcterms:created /rdf:Description rdf:Description rdf:about=#sine_approximations dc:title Simple sine approximations model to illustrate graphing metadata. /dc:title cmeta:comment rdf:parseType=Resource rdf:value A very simple model describing different ways to calculate sine(x) over the range 0 to 2*pi. Used to illustrate the use of graphing metadata. /rdf:value dc:creator rdf:parseType=Resource vCard:FNDavid Nickerson/vCard:FN /dc:creator /cmeta:comment cs:simulation rdf:Description rdf:ID=simulation cs:simulationNameSine Approximations/cs:simulationName cs:multistepMethodadams/cs:multistepMethod cs:iterationMethodfunctional/cs:iterationMethod cs:boundIntervals rdf:parseType=Collection rdf:Description cs:boundVariable rdf:Description rdf:about=#x/ /cs:boundVariable cs:maximumStepSize rdf:datatype=http://www.w3.org/2001/XMLSchema#double; 0.1 /cs:maximumStepSize cs:tabulationStepSize rdf:datatype=http://www.w3.org/2001/XMLSchema#double; 0.5 /cs:tabulationStepSize cs:startingValue rdf:datatype=http://www.w3.org/2001/XMLSchema#double; 0 /cs:startingValue cs:endingValue rdf:datatype=http://www.w3.org/2001/XMLSchema#double; 6.283185307179586232 /cs:endingValue /rdf:Description /cs:boundIntervals /rdf:Description /cs:simulation cg:graph rdf:Description rdf:ID=sine_approximations_graph_black cg:titlesin(x) approximations/cg:title cg:x-labelx ()/cg:x-label cg:y-labely ()/cg:y-label cg:background-colour#00/cg:background-colour cg:colour#ff/cg:colour cg:traces rdf:parseType=Collection rdf:Description cg:labely = sin(x)/cg:label cg:type rdf:resource=http://www.cellml.org/metadata/graphs/1.0#line
[cellml-discussion] Draft graphing metadata specification updated
Hi All, I have updated the draft CellML graphing metadata specification. See the details here: http://www.cellml.org/news_items/draft-graphing-metadata-specification-updated Over the next few days I'll try to fill out the examples demonstrating the use of the graphing metadata and the expected outputs. 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] curation status of models in the repository
Jonathan Cooper wrote: On Thu, Jun 21, 2007 at 02:12:38PM +0800, David Nickerson wrote: Wilfred Li wrote: Maybe instead of the star system, which may be open to interpretation at first sight, an abbreviation or a specific word may be used to represent its status? I guess that if you use something that looks fairly common and standard people will think they know what it means without looking for an actual meaning (i.e., the more stars the better), whereas if you use something a bit different (plain text or graphical) then people are more likely to look-up and try to understand the meaning and implications. The trick is that if its too different, then it may just turn people off all together... Maybe just a simple list of checkboxes with the labels: Level 1, Level 2,... would suffice? The labels could then be links to the appropriate definitions. I like that sound of that. Certainly you need some format where it is possible to say that a model is level 2 without being level 1, which a simple row of stars cannot express. Stars are probably still appropriate for the tool-specific displays though: 1 if it loads, 2 if it also runs, etc. yep - I think thats still a good idea. And eventually you'd hope that level 2 curated models also satisfy level 1, but with the huge number of historical models we'll always need to support the case described above. it might also clear things up if there is just the appropriate number of stars rather than always having three and greying out the last one or two. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Concerning the CellML Model Repository
Hi Tommy, looks like a good starting point for some discussion. Just to help me think through some of the issues, is there any chance you could add a usage example illustrating how this system would deal with a model made from the combination of a bunch of papers (i.e., a single model where each component defines a new citation). I'm guessing this would be done by adding each of the components as separate models and then importing them into a single model? Another usage example that might be interesting to look at would be a model author adding a local CellML 1.1 model hierarchy to a remote repository and how all the import href's are handled in this case (i.e., imports throughout the model hierarchy might consist of a mix of relative, http, and file URLs). And another usage example might be the searching for models built using a specific set of data. It will hopefully become standard practice to annotate variable values with their source, where the source may be some data from a different article than the model's publication. Thanks, David. Tommy Yu wrote: Hi, I have written down some of my thoughts on how the model repository could be put together. http://www.cellml.org/Members/tommy/repository_redesign.html It is still a pretty rough document. The usage example section gives a rough outline on what I see people might be doing with the repository and how this design could address those issues, which I think it will be of interest to users. It is not an exhaustive list, yet. I must also note the design outlined is quite a drastic departure from what we have now (it will be yet another new repository). However, it is more true to the one envisioned before according to http://www.cellml.org/wiki/CellMLModelRepositories, except I have an addition layer that will assist in pulling content and drawing relationships between models. Feel free to take it apart and/or build on top of it. Cheers, Tommy. ___ 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] curation status of models in the repository
No, there are no stars, anywhere, that are on by default. They are all off by default until someone, probably me, certifies that the model meets the requirements to get itself a star, or two. Or maybe three. ok - good to know. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
