1 Feb 2008 04:31
Auckland CellML Group Meeting Minutes (2008-01-30)
Greetings, The minutes of the Auckland CellML group meeting of 2008-01-30 can now be found at: http://www.cellml.org/meeting_minutes/latest Kind Regards, Tommy.
1 Feb 2008 10:34
Re: Using proposed CellML 1.2 features to create more re-usable metabolic models
I think this is really neat, well done on an elegant idea.
One thing is bugging me: I'll illustrate by means of an example:
We would be inferring that the set fluxes consists of only the elements
{f1,f2,f3} from the three statements: "f1 in fluxes", "f2 in fluxes", "f3 in
fluxes".
But if fluxes={f1,f2,f3,f4,f5}, that would still be consistent with the
above three "in"/"is an element of" statements.
So, this proposal means that we are kind of hacking the "in" operator to
indicate an imperative action of "now adding this element to this set".
Anything that is not declared to be added to the set in this way is
considered not in the set. Whereas, the true spirit of the "is an element
of" operator is the weaker form, meaning that other elements could also be
in the set.
Perhaps we should just create a construct that unashamedly imperatively adds
the elements to the set. It would be a CellML construct, rather than a
MathML construct. Initial values are done under CellML and smack of an
imperative style rather than a declarative style, and could have been done
under MathML by saying the value of a variable at time t=t0 is such, so it
is not out of the spirit of CellML to break away from the declarative style
when it is pragmatic to do so.
So, I'm proposing removing the "in" statements from the MathML, and
replacing them with CellML statements like <addToSet set="flux_a"
element="flux_a_member1" />
Where flux_a_member1 is defined in the MathML, something like: "declare
flux_a_member1 is lambda(-overallRate)".
(Continue reading)
3 Feb 2008 13:55
Re: Using proposed CellML 1.2 features to create more re-usable metabolic models
> One thing is bugging me: I'll illustrate by means of an example:
> We would be inferring that the set fluxes consists of only the elements
> {f1,f2,f3} from the three statements: "f1 in fluxes", "f2 in fluxes", "f3 in
> fluxes".
> But if fluxes={f1,f2,f3,f4,f5}, that would still be consistent with the
> above three "in"/"is an element of" statements.
You could be saying two different kinds of things: either
"there exists some x such that x is in fluxes and x = f1"
or "for all x in fluxes, x = f1 or x = f2 or ... or x = f5".
Both of these are declarative in form, but the first one allows
one to add more fluxes simply.
With regards to the problem of whether a given object is in a set,
I would suggest that we firstly note that simulating all of
predicate calculus runs into computability problems.
One way to simplify things for ourselves is to assume that all
positive relations must be entailed by the model plus whatever
our base axioms are in order to be true (so, we are really looking
at derivability, rather than truth). So, if the model (including imports
and so forth) does not entail that q is in fluxes, then q is not in fluxes.
An alternative but equivalent way to view this is that we
choose to deal with the smallest positive model such that all of the
assertions that we make are true.
As long as we have a finite domain of quantification we do not
have any problems with determining entailment; we can avoid diagonalisation
and halting problems both. If we had to quantify unrestrictedly
over numbers this breaks down, but I do not see biological
(Continue reading)
4 Feb 2008 03:44
[Fwd: [Synthetic Biology] BBF working groups, SB4.0, and standard workshop]
Thought some of you folks might be interested in this:
Subject: [Synthetic Biology] BBF working groups, SB4.0, and standard workshop
Date: 2008-01-25 15:37:01 GMT
Hello,
A quick three part email providing updates on several important synthetic biology activities happening now.
*** 1. BBF working groups ***
The BioBricks Foundation (BBF) is launching four working groups.
Each working group will bring people like you together to discuss and work on issues important to the synthetic biology community. Note that you can join more than one group. And, if you don't like what you see, you can quit.
Join up by subscribing to one or more of the appropriate mailing lists here:
http://openwetware.org/wiki/The_BioBricks_Foundation:MailingLists
In launching these groups, the BBF is hoping that a diverse community from many countries, schools, companies, and organizations will continue to come together as synthetic biology develops, so that the technology of biology reaches its best constructive potential, and is available for all to use.
The BioBricks Foundation (BBF) is launching four working groups.
The first group is "SB4.0" If you want to organize a special topic discussion or session at the Fourth International Conference on Synthetic Biology (October 2008), sign up for this group.
The second group is "Technical." If you want to wrestle Tom Knight, working to define exactly what the heck a BioBrick standard biological part is, then please join this group.
The third group is "Legal." If you want to sue everybody then please don't join this group. But, if you want to help with figuring out the specific legal scheme that will keep BioBrick parts free to study, use, and modify, then join up here.
The third group is "Legal." If you want to sue everybody then please don't join this group. But, if you want to help with figuring out the specific legal scheme that will keep BioBrick parts free to study, use, and modify, then join up here.
The fourth group is "Volunteers." If you want to help with the workings, leadership, or activities of the BBF itself, or represent the BBF at meetings around the world, then this is the group for you. Somebody has to keep this thing running!
Each working group will bring people like you together to discuss and work on issues important to the synthetic biology community. Note that you can join more than one group. And, if you don't like what you see, you can quit.
Join up by subscribing to one or more of the appropriate mailing lists here:
http://openwetware.org/wiki/The_BioBricks_Foundation:MailingLists
In launching these groups, the BBF is hoping that a diverse community from many countries, schools, companies, and organizations will continue to come together as synthetic biology develops, so that the technology of biology reaches its best constructive potential, and is available for all to use.
*** 2. SB4.0 ***
The Fourth International Meeting on Synthetic Biology will take place 10-12 October 2008 at HKUST in Hong Kong. Given everything that is happening, and how much there is still to do, SB4.0 is going to be an amazing meeting. The organizers of the meeting, myself included, can't pretend that we understand everything that should be presented or discussed at the conference. Thus, we are asking for your help. If you would like to suggest a topic for discussion, or organize a breakout session, or can suggest whatever would work best for a particular idea, please let me know. We are developing tremendous resources in support of SB4.0 (including significant travel assistance) and will work very hard to make all good ideas happen. If you want to be part of a broader discussion on SB4.0 organization, please join the working group (as per above). Conference website here:
(Continue reading)
6 Feb 2008 21:57
Include_in_CellML_1.2 requested: [Tracker Item 337] Remove the directional aspect of connections
Andrew Miller <ak.miller@...> has asked for Include_in_CellML_1.2: Tracker Item 337: Remove the directional aspect of connections https://tracker.physiomeproject.org/show_bug.cgi?id=337 ------- Additional Comments from Andrew Miller <ak.miller@...> In CellML 1.1 and earlier, connections were directional. Because connections imply equality, and equality does not have a direction in a declarative environment, it doesn't really add any meaning to the model to give connections a direction. I have written up a draft version of the normative specification which makes connections undirected. It is available at: http://www.cellml.org/Members/miller/draft-normative-spec-simplify-connections/ toplevel.xhtml (and through git at git://repo.or.cz/srv/git/cellml-draft-miller.git branch simplify-connections). Note that this draft also removes map_components and replaces it with groups on connections, as another related measure to simplify connections.
6 Feb 2008 22:16
Proposal: Simplification of connections - removal of directionality and map_components
Hi all, I am proposing that in CellML 1.2, we make connections between variables undirected (that is, we don't have an in or out on public or private interfaces for variables). I am also proposing that we remove the map_components element and move the component_1 and component_2 attributes directly onto the connection element (suggestion originally from Randall Britten). I have created a draft containing these changes. It can be viewed at: http://www.cellml.org/Members/miller/draft-normative-spec-simplify-connections/toplevel.xhtml or retrieved via git from git://repo.or.cz/srv/git/cellml-draft-miller.git branch simplify-connections . There is a tracker item in the tracker at https://tracker.physiomeproject.org/show_bug.cgi?id=337 about this - if you want to be kept updated on this, then you can visit the URL, create a tracker account if you don't have one yet, and add yourself to the CC list for the tracker item. Best regards, Andrew
8 Feb 2008 04:47
Auckland CellML Group Meeting Minutes (2008-02-07)
Greetings, The minutes of the Auckland CellML group meeting of 2008-02-07 can now be found at: http://www.cellml.org/meeting_minutes/latest Kind Regards, Tommy.
11 Feb 2008 04:42
Re: 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.
11 Feb 2008 05:36
Re: Auckland CellML Group Meeting Minutes(2008-02-07)
> -----Original Message----- > From: David Nickerson > Sent: Monday, 11 February 2008 4:43 p.m. > To: CellML Discussion List > Subject: Re: [cellml-discussion] Auckland CellML Group Meeting > Minutes(2008-02-07) > > just a couple of points arising from these meeting minutes... > > Any outcomes from the breakaway session discussing the "if and how" of > creating an annotated or informative version of the normative 1.2 > specification draft? None yet, further discussion required.
11 Feb 2008 06:39
Re: Auckland CellML GroupMeeting Minutes(2008-02-07)
Randall Britten wrote: > >> -----Original Message----- >> From: David Nickerson >> Sent: Monday, 11 February 2008 4:43 p.m. >> To: CellML Discussion List >> Subject: Re: [cellml-discussion] Auckland CellML Group Meeting >> Minutes(2008-02-07) >> >> just a couple of points arising from these meeting minutes... >> >> Any outcomes from the breakaway session discussing the "if and how" of >> creating an annotated or informative version of the normative 1.2 >> specification draft? > > None yet, further discussion required. I have added tacker item 338 (https://tracker.physiomeproject.org/show_bug.cgi?id=338) perhaps the folks in Auckland could update this with discussions to date and then interested parties can take it from there.... Andre.
RSS Feed