Re: [cellml-discussion] 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
models using this kind of functionality.
Taking both of these simplifications, we should be able to use
predicate calculus constructs in the same way we have been using
other equations in models, without sacrificing the declarative nature
of the language.
Regards,
Justin.
This message was sent using IMP, the Internet Messaging Program.
___
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 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
Where flux_a_member1 is defined in the MathML, something like: "declare
flux_a_member1 is lambda(-overallRate)".
Regards,
Randall
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:cellml-discussion-
> [EMAIL PROTECTED] On Behalf Of Andrew Miller
> Sent: Wednesday, 30 January 2008 5:52 p.m.
> To: For those interested in contributing to the development of CellML.
> Subject: [cellml-discussion] Using proposed CellML 1.2 features to
> create more re-usable metabolic models
>
> Hi all,
>
> To aid in working out what features we should include in CellML 1.2, I
> have been looking into one of the major difficulties with creating
> re-usable metabolic models at the moment: that to compute a derivative,
> you need to know all the fluxes, but when a model is extended, new
> fluxes can be added to the model. Ideally, we should be able to define
> CellML 1.2 so that structured types can be leveraged to avoid this
> issue.
>
> I have come up with an example of how this might look in CellML 1.2.
> This is based in part off a discussion that I had earlier with Poul, so
> most of the credit for this goes to him, while most of the blame for
> the
> inelegant parts goes to me.
>
> Note that the lambda constructs without any bound variables are there
> to
> defer interpretation of the fluxes until they are taken from the set.
> The rationale for needing this is that if we had two statements that a
> certain real-valued flux belongs in the set, and two of them happened
> to
> have the same value at a particular point in time, then summing over
> the
> set would only include the flux value once (e.g. saying x is an element
> of N, where N is in the natural numbers, means that the value of x is a
> natural number. Saying x=5, y=5, x in N, y in N does not mean that 5 is
> in the set of natural numbers twice). On the other hand, we can have
> two
> different zero argument lambda functions in a set, which just happen to
> evaluate to the same value. This is consistent with the declarative
> nature of CellML - we are not saying 'add this flux to the set of
> fluxes', but rather, we are making a series of statements about what is
> in the set of fluxes, and the processing software is then summing over
> all fluxes which have been explicitly mentioned. Because we can connect
> the set of fluxes up to an importing model, doing things this way gives
> a great deal of extra flexibility.
>
> Notes:
> 1) In practice, the substance could become an import which is re-used
> many times, and likewise for components representing various general
> types of chemical reactions.
> 2) I have invented a possible way in which we could remove
> directionality from connections. No one has come up with a formal
> proposal to do it this way yet.
> 3) I have followed Randall's earlier suggestion about how to structure
> connections without using component_ref. This again needs a formal
> proposal and discussion.
> 4) The model uses a potential way in which we could get rid of the
> generality of groups, by replacing group and relationship_ref with a
> simple encapsulation element. This again needs to be formally proposed
> and discussed at some point.
>
>
>xmlns="http://www.cellml.org/cellml/1.1#";
> xmlns:c11="http://www.cellml.org/cell
Re: [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models
> If two models contradict each other (such as by each stating a > initial value for concentrations of the same species, or a different > mechanism for the exact same reaction), then this contradiction has > to be fixed before the models can be composed. It's not just about composition - during model simulation work often initial conditions are altered before running. If we had two (or more) 'substances' that actually relate to the same substance, it would be easy to make a contradiction after the model has been composed just by altering one of those initial conditions. > I am therefore focusing on clean ways to compose non-contradictory > models which involve some overlap of chemical species (and so the > assumption is that the initial values are the same). I wonder if in general allowing duplications is not the best we could do. Especially if we hope to build larger models from smaller ones with the least cellml code editing (including resetting initial conditions). I think as well the good work you have done here it would be valuable to explore as an extension ways of resolving such conflicts possibly with cellml language elements, or at least not advocating the creation of higher level structures which could easily leads to such conflict (not that we can prevent people building them if they try hard enough :) ). Metadata and tools contribution to the model composition process notwithstanding. This message was sent using IMP, the Internet Messaging Program. ___ 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 create more re-usable metabolic models
Michael Cooling wrote: >> if both state variables have the same initial values and >> rates (which they would... >> > > why should they have the same initial values? I agree if they did then > it makes > no difference to the correctness of the model but it seems very possible to > create a model of system 1 with substance_b and a model of system 2 > with substance_b and give them > both different initial conditions, then try to combine them. In > practice I think this would happen more often than not, at least for > the systems I've dealt with so far. > > Are you talking about AFTER you've realised the conflict and have > already decided which value(s) to go with? Or have I missed something? > If two models contradict each other (such as by each stating a initial value for concentrations of the same species, or a different mechanism for the exact same reaction), then this contradiction has to be fixed before the models can be composed. I am therefore focusing on clean ways to compose non-contradictory models which involve some overlap of chemical species (and so the assumption is that the initial values are the same). Best regards, Andrew ___ 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 create more re-usable metabolic models
> not analogous to public and private in most object orientated > programming languages Quite right, I got confused. > if both state variables have the same initial values and > rates (which they would... why should they have the same initial values? I agree if they did then it makes no difference to the correctness of the model but it seems very possible to create a model of system 1 with substance_b and a model of system 2 with substance_b and give them both different initial conditions, then try to combine them. In practice I think this would happen more often than not, at least for the systems I've dealt with so far. Are you talking about AFTER you've realised the conflict and have already decided which value(s) to go with? Or have I missed something? > and that is a good assumption if you provide everything on the > interface Thanks, I see what you are doing with those now. Quoting Andrew Miller <[EMAIL PROTECTED]>: > Michael Cooling wrote: >>> because if connections don't have directionality, then it makes no >>> sense in the language to say >>> that a connection is from A to B, as opposed to from B to A, and we >>> wouldn't want to force users to duplicate information and provide both >>> >> >> Oops I didn't mean to imply directionality. I shouldn't have used the >> words 'from' and 'to', sorry. It's not the language that I want to >> change. >> >> >>> I'm not sure what you mean there. In CellML 1.1, there can be attributes >>> like public_interface="in" private_interface="out", I have used >>> something more like public_interface="yes" or public_interface="no" >>> here, thereby removing the directionality - in and out correspond to >>> yes, none corresponds to no. >>> >> >> Ah I see. I suspect just having an optional public_interface="yes" >> would be the way to go, private="yes" being always >> implicit. I.e. private by default, and public includes private. As you >> say this will no doubt be discussed later. >> > > This particular aspect has already been discussed. See > http://www.cellml.org/pipermail/cellml-discussion/2008-January/001144.html > and the follow on discussion for why public and private interfaces are > not analogous to public and private in most object orientated > programming languages, and why public does not imply private. > > By default, we have public_interface="no" private_interface="no", which > means that the variable cannot be used outside of the component. > public_interface="yes" means that encapsulating components can connect > to the variable, while private_interface="yes" means that encapsulated > components can connect to the variable. > >> >>> The mathematical model you get from this would be sub-optimal without >>> some intelligence on the part of software tools - there would be two >>> state variables with identical rates and initial values for the >>> concentration of b and the concentration of y >>> >> >> This is why I am wary of such convenience componentsthey imply an >> interface that doesn't really exist - I think they can be useful but >> since one never >> knows what might get connected to what >> > > Removing directionality, and using sets for the list of all fluxes mean > that it doesn't matter what the flux set is connected to behind the > interface. The duplication of state variables is unfortunate, but it > doesn't actually have any theoretical implications for the correctness > of the model, if both state variables have the same initial values and > rates (which they would, since they are the sum over the same set of > fluxes). This means that the model should just work in all cases. > >> If one tries to use them as an interface to the system that MUST be >> used (not that you were doing this) >> then you limit the usefulness of your model...essentially you are >> assuming that your interface is sufficient for all future >> requirements. > > Yes, and that is a good assumption if you provide everything on the > interface. > >> Even for ion channels, that might not be true in the future. >> I think duplications may also be resolved by chosing a particular >> substance_b >> (ie human decision) at model aggregation-time facilitated by tools >> identifying this situation. >> > > I don't think we want to do that manually. The duplication is only a > problem because it artificially inflates the dimensionality of the > model, creating a performance problem, and the algorithm to detect this > artificial inflation of dimensionality and merge the state variables for > computational purposes should be tractable if we limit it to the case > where identical variables are being put through an identical equations, > rather than going for a more general and costly isomorphic mathematical > structure detection. > > Best regards, > Andrew > > ___ > 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 create more re-usable metabolic models
Michael Cooling wrote: >> because if connections don't have directionality, then it makes no >> sense in the language to say >> that a connection is from A to B, as opposed to from B to A, and we >> wouldn't want to force users to duplicate information and provide both >> > > Oops I didn't mean to imply directionality. I shouldn't have used the > words 'from' and 'to', sorry. It's not the language that I want to > change. > > >> I'm not sure what you mean there. In CellML 1.1, there can be attributes >> like public_interface="in" private_interface="out", I have used >> something more like public_interface="yes" or public_interface="no" >> here, thereby removing the directionality - in and out correspond to >> yes, none corresponds to no. >> > > Ah I see. I suspect just having an optional public_interface="yes" > would be the way to go, private="yes" being always > implicit. I.e. private by default, and public includes private. As you > say this will no doubt be discussed later. > This particular aspect has already been discussed. See http://www.cellml.org/pipermail/cellml-discussion/2008-January/001144.html and the follow on discussion for why public and private interfaces are not analogous to public and private in most object orientated programming languages, and why public does not imply private. By default, we have public_interface="no" private_interface="no", which means that the variable cannot be used outside of the component. public_interface="yes" means that encapsulating components can connect to the variable, while private_interface="yes" means that encapsulated components can connect to the variable. > >> The mathematical model you get from this would be sub-optimal without >> some intelligence on the part of software tools - there would be two >> state variables with identical rates and initial values for the >> concentration of b and the concentration of y >> > > This is why I am wary of such convenience componentsthey imply an > interface that doesn't really exist - I think they can be useful but > since one never > knows what might get connected to what > Removing directionality, and using sets for the list of all fluxes mean that it doesn't matter what the flux set is connected to behind the interface. The duplication of state variables is unfortunate, but it doesn't actually have any theoretical implications for the correctness of the model, if both state variables have the same initial values and rates (which they would, since they are the sum over the same set of fluxes). This means that the model should just work in all cases. > If one tries to use them as an interface to the system that MUST be > used (not that you were doing this) > then you limit the usefulness of your model...essentially you are > assuming that your interface is sufficient for all future > requirements. Yes, and that is a good assumption if you provide everything on the interface. > Even for ion channels, that might not be true in the future. > I think duplications may also be resolved by chosing a particular substance_b > (ie human decision) at model aggregation-time facilitated by tools > identifying this situation. > I don't think we want to do that manually. The duplication is only a problem because it artificially inflates the dimensionality of the model, creating a performance problem, and the algorithm to detect this artificial inflation of dimensionality and merge the state variables for computational purposes should be tractable if we limit it to the case where identical variables are being put through an identical equations, rather than going for a more general and costly isomorphic mathematical structure detection. Best regards, Andrew ___ 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 create more re-usable metabolic models
> because if connections don't have directionality, then it makes no > sense in the language to say > that a connection is from A to B, as opposed to from B to A, and we > wouldn't want to force users to duplicate information and provide both Oops I didn't mean to imply directionality. I shouldn't have used the words 'from' and 'to', sorry. It's not the language that I want to change. > I'm not sure what you mean there. In CellML 1.1, there can be attributes > like public_interface="in" private_interface="out", I have used > something more like public_interface="yes" or public_interface="no" > here, thereby removing the directionality - in and out correspond to > yes, none corresponds to no. Ah I see. I suspect just having an optional public_interface="yes" would be the way to go, private="yes" being always implicit. I.e. private by default, and public includes private. As you say this will no doubt be discussed later. > The mathematical model you get from this would be sub-optimal without > some intelligence on the part of software tools - there would be two > state variables with identical rates and initial values for the > concentration of b and the concentration of y This is why I am wary of such convenience componentsthey imply an interface that doesn't really exist - I think they can be useful but since one never knows what might get connected to what If one tries to use them as an interface to the system that MUST be used (not that you were doing this) then you limit the usefulness of your model...essentially you are assuming that your interface is sufficient for all future requirements. Even for ion channels, that might not be true in the future. I think duplications may also be resolved by chosing a particular substance_b (ie human decision) at model aggregation-time facilitated by tools identifying this situation. Quoting Andrew Miller <[EMAIL PROTECTED]>: > Michael Cooling wrote: >> First just to check that in the the connection elements 'flux' should >> be 'fluxes'? For example, 'substance_a' component contains no variable >> 'flux', I assume you meant the set_of_lambda_of_real 'fluxes'? >> > > Thanks for pointing that out - it is hard to validate something before > there is a specification or tools, so I'm sure there are lots of little > mistakes like that in my example. > >> I think I like this! When will it be released? ;-P >> >> I don't know enough about the lambda elements in MathML to check the >> syntax (BTW which MathML spec would we use for CellML 1.2, MathML >> 2.0?) > > We really can't refer to the drafts for MathML 3, so we are stuck with > MathML 2 unless MathML 3 goes final before CellML 1.2 is frozen. > >> but I think I get the idea and presuming it works like how the >> species are tracking their own ODEs and the reactions just deal in >> fluxes for the species involved. > > I'm not sure what you mean by 'species are tracking their own ODEs' - > there is one state variable per species, representing the concentration, > and the ODE for [species] is in the component for that species. > >> We can do this with cellml 1.0 but >> better to minimise the 'gluing code' of course. >> > > You could express an equivalent mathematical model in CellML 1.0 or > CellML 1.1, but the point is that the model would not be re-usable if > you wanted to add a new chemical reaction to it. Instead, you would be > forced to take one of the following strategies: > > a) add an extra real scalar term into the rate equation, and expose > that all the way up through abxy_system, and then either connect it to a > variable with constant value 0 if you don't want to add anything to the > system, or connect it to the new fluxes otherwise. You would need to do > this for every species in the model, making it very cumbersome to work with. > b) actually change the original model to add in the new fluxes to the > rate equation every time you add in a new reaction (i.e. copy and edit > rather than re-use by reference). > >> Minor question: what is the purpose of the component abxy_system? Is >> this to help monitor the individual fluxes from one location? >> > > abxy_system is a convenience component which provides a top-level > interface to the system. The model could be run as it is right now, or > alternatively, you could import abxy_system into another model, and you > might also want to import the bcyz_system, which has some species in > common and some species different. The top-level model would import the > convenience components from abxy_system and bcyz_system, and would then > connect flux_b from abxy_system to flux_b from bcyz_system, and flux_y > from abxy_system to flux_y from bcyz_system. > > The mathematical model you get from this would be sub-optimal without > some intelligence on the part of software tools - there would be two > state variables with identical rates and initial values for the > concentration of b and the concentration of y (something tools mi
Re: [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models
Michael Cooling wrote: > First just to check that in the the connection elements 'flux' should > be 'fluxes'? For example, 'substance_a' component contains no variable > 'flux', I assume you meant the set_of_lambda_of_real 'fluxes'? > Thanks for pointing that out - it is hard to validate something before there is a specification or tools, so I'm sure there are lots of little mistakes like that in my example. > I think I like this! When will it be released? ;-P > > I don't know enough about the lambda elements in MathML to check the > syntax (BTW which MathML spec would we use for CellML 1.2, MathML > 2.0?) We really can't refer to the drafts for MathML 3, so we are stuck with MathML 2 unless MathML 3 goes final before CellML 1.2 is frozen. > but I think I get the idea and presuming it works like how the > species are tracking their own ODEs and the reactions just deal in > fluxes for the species involved. I'm not sure what you mean by 'species are tracking their own ODEs' - there is one state variable per species, representing the concentration, and the ODE for [species] is in the component for that species. > We can do this with cellml 1.0 but > better to minimise the 'gluing code' of course. > You could express an equivalent mathematical model in CellML 1.0 or CellML 1.1, but the point is that the model would not be re-usable if you wanted to add a new chemical reaction to it. Instead, you would be forced to take one of the following strategies: a) add an extra real scalar term into the rate equation, and expose that all the way up through abxy_system, and then either connect it to a variable with constant value 0 if you don't want to add anything to the system, or connect it to the new fluxes otherwise. You would need to do this for every species in the model, making it very cumbersome to work with. b) actually change the original model to add in the new fluxes to the rate equation every time you add in a new reaction (i.e. copy and edit rather than re-use by reference). > Minor question: what is the purpose of the component abxy_system? Is > this to help monitor the individual fluxes from one location? > abxy_system is a convenience component which provides a top-level interface to the system. The model could be run as it is right now, or alternatively, you could import abxy_system into another model, and you might also want to import the bcyz_system, which has some species in common and some species different. The top-level model would import the convenience components from abxy_system and bcyz_system, and would then connect flux_b from abxy_system to flux_b from bcyz_system, and flux_y from abxy_system to flux_y from bcyz_system. The mathematical model you get from this would be sub-optimal without some intelligence on the part of software tools - there would be two state variables with identical rates and initial values for the concentration of b and the concentration of y (something tools might be able to detect and optimise if there was sufficient demand to do so), but nevertheless, the two models would have been correct composited into a single model. > Very minor point: I notice the units for your kb terms should be just > 'per_second'? > Good catch. > directionality - I suspect we can just leave those redundant (in/out) > tags out? > I'm not sure what you mean there. In CellML 1.1, there can be attributes like public_interface="in" private_interface="out", I have used something more like public_interface="yes" or public_interface="no" here, thereby removing the directionality - in and out correspond to yes, none corresponds to no. > connections structure - makes me think about something that is more a > toolset UI issue: > One thing I've found when constructing models is that I don't think > about connections > from an A->B, then A->C then A->D perspective (letters here are > components), but by considering all connections from A to other > components. For example, if I have a new component A I'd much rather > declare something like: > > > > > > > if you see what I mean, rather than hunt around the CellML for each > variable connection which is, in my opinion, tedious and poor > workflow. Now I don't think what I've written there is as good a > structure as the current CellML and I'm not suggesting CellML should > be changed, but what I'm getting to is I think it would be helpful for > the PCEnv/COR tool if from the UI a more workflow-friendly linking was > possible, and it sorted out the more elegant connection components as > written in CellML from that. > Yes, this would have to be provided by tools, because if connections don't have directionality, then it makes no sense in the language to say that a connection is from A to B, as opposed to from B to A, and we wouldn't want to force users to duplicate information and provide both directions. Best regards,
Re: [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models
First just to check that in the the connection elements 'flux' should be 'fluxes'? For example, 'substance_a' component contains no variable 'flux', I assume you meant the set_of_lambda_of_real 'fluxes'? I think I like this! When will it be released? ;-P I don't know enough about the lambda elements in MathML to check the syntax (BTW which MathML spec would we use for CellML 1.2, MathML 2.0?) but I think I get the idea and presuming it works like how the species are tracking their own ODEs and the reactions just deal in fluxes for the species involved. We can do this with cellml 1.0 but better to minimise the 'gluing code' of course. Minor question: what is the purpose of the component abxy_system? Is this to help monitor the individual fluxes from one location? Very minor point: I notice the units for your kb terms should be just 'per_second'? directionality - I suspect we can just leave those redundant (in/out) tags out? connections structure - makes me think about something that is more a toolset UI issue: One thing I've found when constructing models is that I don't think about connections from an A->B, then A->C then A->D perspective (letters here are components), but by considering all connections from A to other components. For example, if I have a new component A I'd much rather declare something like: if you see what I mean, rather than hunt around the CellML for each variable connection which is, in my opinion, tedious and poor workflow. Now I don't think what I've written there is as good a structure as the current CellML and I'm not suggesting CellML should be changed, but what I'm getting to is I think it would be helpful for the PCEnv/COR tool if from the UI a more workflow-friendly linking was possible, and it sorted out the more elegant connection components as written in CellML from that. Cheers, Quoting Andrew Miller <[EMAIL PROTECTED]>: > Hi all, > > To aid in working out what features we should include in CellML 1.2, I > have been looking into one of the major difficulties with creating > re-usable metabolic models at the moment: that to compute a derivative, > you need to know all the fluxes, but when a model is extended, new > fluxes can be added to the model. Ideally, we should be able to define > CellML 1.2 so that structured types can be leveraged to avoid this issue. > > I have come up with an example of how this might look in CellML 1.2. > This is based in part off a discussion that I had earlier with Poul, so > most of the credit for this goes to him, while most of the blame for the > inelegant parts goes to me. > > Note that the lambda constructs without any bound variables are there to > defer interpretation of the fluxes until they are taken from the set. > The rationale for needing this is that if we had two statements that a > certain real-valued flux belongs in the set, and two of them happened to > have the same value at a particular point in time, then summing over the > set would only include the flux value once (e.g. saying x is an element > of N, where N is in the natural numbers, means that the value of x is a > natural number. Saying x=5, y=5, x in N, y in N does not mean that 5 is > in the set of natural numbers twice). On the other hand, we can have two > different zero argument lambda functions in a set, which just happen to > evaluate to the same value. This is consistent with the declarative > nature of CellML - we are not saying 'add this flux to the set of > fluxes', but rather, we are making a series of statements about what is > in the set of fluxes, and the processing software is then summing over > all fluxes which have been explicitly mentioned. Because we can connect > the set of fluxes up to an importing model, doing things this way gives > a great deal of extra flexibility. > > Notes: > 1) In practice, the substance could become an import which is re-used > many times, and likewise for components representing various general > types of chemical reactions. > 2) I have invented a possible way in which we could remove > directionality from connections. No one has come up with a formal > proposal to do it this way yet. > 3) I have followed Randall's earlier suggestion about how to structure > connections without using component_ref. This again needs a formal > proposal and discussion. > 4) The model uses a potential way in which we could get rid of the > generality of groups, by replacing group and relationship_ref with a > simple encapsulation element. This again needs to be formally proposed > and discussed at some point. > > >xmlns="http://www.cellml.org/cellml/1.1#"; > xmlns:c11="http://www.cellml.org/cellml/1.1#"; > xmlns:c12="http://www.cellml.org/cellml/1.2#"; > xmlns:m="http://www.w3.org/1998/Math/MathML"; > name="_1_2_example" > > > >units="mol_per_litre_per_second" public_interface="yes" /> >public_interf
[cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models
Hi all, To aid in working out what features we should include in CellML 1.2, I have been looking into one of the major difficulties with creating re-usable metabolic models at the moment: that to compute a derivative, you need to know all the fluxes, but when a model is extended, new fluxes can be added to the model. Ideally, we should be able to define CellML 1.2 so that structured types can be leveraged to avoid this issue. I have come up with an example of how this might look in CellML 1.2. This is based in part off a discussion that I had earlier with Poul, so most of the credit for this goes to him, while most of the blame for the inelegant parts goes to me. Note that the lambda constructs without any bound variables are there to defer interpretation of the fluxes until they are taken from the set. The rationale for needing this is that if we had two statements that a certain real-valued flux belongs in the set, and two of them happened to have the same value at a particular point in time, then summing over the set would only include the flux value once (e.g. saying x is an element of N, where N is in the natural numbers, means that the value of x is a natural number. Saying x=5, y=5, x in N, y in N does not mean that 5 is in the set of natural numbers twice). On the other hand, we can have two different zero argument lambda functions in a set, which just happen to evaluate to the same value. This is consistent with the declarative nature of CellML - we are not saying 'add this flux to the set of fluxes', but rather, we are making a series of statements about what is in the set of fluxes, and the processing software is then summing over all fluxes which have been explicitly mentioned. Because we can connect the set of fluxes up to an importing model, doing things this way gives a great deal of extra flexibility. Notes: 1) In practice, the substance could become an import which is re-used many times, and likewise for components representing various general types of chemical reactions. 2) I have invented a possible way in which we could remove directionality from connections. No one has come up with a formal proposal to do it this way yet. 3) I have followed Randall's earlier suggestion about how to structure connections without using component_ref. This again needs a formal proposal and discussion. 4) The model uses a potential way in which we could get rid of the generality of groups, by replacing group and relationship_ref with a simple encapsulation element. This again needs to be formally proposed and discussed at some point. http://www.cellml.org/cellml/1.1#"; xmlns:c11="http://www.cellml.org/cellml/1.1#"; xmlns:c12="http://www.cellml.org/cellml/1.2#"; xmlns:m="http://www.w3.org/1998/Math/MathML"; name="_1_2_example" > time concentration f f fluxes f overall_rate kf concentration_a concentration_b kb concentration_x overall_rate flux_a overall_rate flux_b overall_rate flux_x overall_rate kf concentration_a concentration_x kb concentration_y overall_rate flux_a overall_rate flux_x overall_rate flux_y ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
