From: Meier-Schellersheim, M. (NIH/N. [E] <mm...@ni...> - 2009-09-24 18:12:51
|
Hi Jim, Bill, wouldn't the attribute you would like to add not only make life a bit easier for your parser of the L3M model description? Parsing the feature state dependent possible reactions your parser would detect that a feature state has influence on the binding possibilities of a binding site. This would in principle allow you to use the state tag directly at the binding site in BNG. However, in cases where the state feature is not directly, physically associated (e.g. as phosphorylation state of the site) with the binding site you may not want to do that. But isn't that a limitation resulting from the attempt to specify the binding possibilities of a binding site strictly through attributes of the site itself while in reality features that are non-local (from the point of view of the binding site) may have influence on its binding possibilities? Martin ________________________________________ From: James Faeder [fa...@pi...] Sent: Thursday, September 24, 2009 1:15 PM To: Discussions of the SBML Level 3 'multi' package Subject: Re: [sbml-multi] StateFeature and BindingSite Hi all, I just wanted to throw my two cents in here. Bill is raising the same point that I brought up in our December, 2007 discussion, which is that there is some decoupling of structure and function that occurs when we separate binding sites and features. I haven't made a big deal about it because, as Martin and Nicholas have pointed out, functionally equivalent models can be developed with either approach. But I think what Bill is asking for here - a way to associate features and sites as an annotation - would be very helpful because it would enable us to make a one-to-one mapping between a BioNetGen model and its L3M encoding so that we can recover a BNG model from an L3M- encoded one. We could also achieve the same effect through BNG- specific annotations, but I don't see a compelling reason to go that route, especially because Kappa and BNG both would require that same type of annotation. -jim On Sep 23, 2009, at 7:31 PM, Bill Hlavacek wrote: > Hi Martin, > > There *is* a relationship encoded in the rule in that according to > this rule "feature" must have the state "state1" for interaction > between "binding_site1" and "binding_site2." However, there is no > documentation that "state1" is a property of "binding_site1" (e.g., > "feature" could be a property of some other part of the "Mol1" protein > that affects interaction, such as a lid that opens and closes to hide > and reveal "binding_site1"). As a result, we cannot write the rule in > BNGL as we normally do. We can however write a rule that is > functionally equivalent to the rule we would like to write - it is the > second rule in my earlier email. There are two problems with taking > this approach that are evidently not obvious. First, as I stated > earlier, we lose information that is useful for model annotation, > namely that "state1" is a property of "binding_site1." Second, the > graph that we are forced to use in a BioNetGen simulation to represent > "Mol1" has two vertices ("binding_site1" and "feature") instead of the > one vertex in the rule we would like to write. The extra vertex adds > an unnecessary computational burden. Generally, larger graphs mean > greater simulation costs, which is why we don't usually explicitly > represent how components of a protein are connected, even though we > could do that. The *optional* attribute I suggested would allow us to > detect that "state1" is a property of "binding_site1" and would allow > us to use the smaller graph in a BioNetGen simulation. If the > attribute is missing, it is not a problem. But being able to specify > the attribute would be nice. Because the attribute is optional, no > one needs to specify it if they don't want to. As things stand, when > we translate a model specification in BNGL format into multi format > and then translate back from multi to BNGL, we will lose information, > which will affect our ability to understand the model specification > and the efficiency with which we can simulate the model. The > simulation results obtained would be the same though. > > Bin Hu is preparing a BNGL-encoded model specification and the > corresponding multi-encoded model specification, which I think will > make the need for the suggested optional attribute clearer. > > --Bill > > On Sep 23, 2009, at 4:42 PM, Meier-Schellersheim, Martin (NIH/NIAID) > [E] wrote: > >> Hi Bill, >> >> maybe, I am missing something - why are you so concerned about not >> having a more 'explicit' relationship >> between binding_site1 and the feature state? By defining your 'new' >> rule you create a relationship >> between the two, no? >> In the ITAM example you provide, the phoshorylation happens to be in >> the physical region that is used as a >> binding site. The phosphorylation site could be somewhere else: in a >> region that determines (for instance, >> by controlling the way a molecule or molecule-complex folds back on >> itself) the availability of the binding site. >> Nevertheless, you could create a relationship between the two >> through the definition of the rule. >> >> For annotation purposes one could have (optional) information about >> the (sequence-) location of binding sites and >> feature states containing (optional) annotative free text details, >> such as information about phosphorylation locations. >> I don't know whether it would go too far to have certain standard >> feature categories, among which there could be >> 'phosphorylation'. >> >> Martin >> >> Martin Meier-Schellersheim, Ph.D. >> Team Leader, Computational Biology Group >> Program in Systems Immunology and Infectious Disease Modeling >> Laboratory of Immunology >> National Institute of Allergy and Infectious Diseases >> National Institutes of Health >> Building 10, Room 11N311 >> 10 Center Drive, MSC 1892 >> Bethesda, MD 20892-1892 >> USA >> Tel: 301-443-6017 >> FAX: 301-496-0222 >> http://www3.niaid.nih.gov/labs/aboutlabs/psiim/computationalBiology/ >> >> Disclaimer:The information in this e-mail and any of its attachments >> is >> confidential and may contain sensitive information. It should not be >> used by anyone who is not the original intended recipient. If you >> have >> received this e-mail in error please inform the sender and delete it >> from your mailbox or any other storage devices. National Institute of >> Allergy and Infectious Diseases shall not accept liability for any >> statements made that are sender's own and not expressly made on >> behalf >> of the NIAID by one of its representatives. >> >> >> ________________________________________ >> From: Bill Hlavacek [wi...@la...] >> Sent: Wednesday, September 23, 2009 1:11 PM >> To: Discussions of the SBML Level 3 'multi' package >> Subject: Re: [sbml-multi] StateFeature and BindingSite >> >> Multi enthusiasts, >> >> I think I follow what Nic wrote below in response to my query about >> StateFeature and BindingSite. I want to make sure I understand, and >> if I do, then I want to make a suggestion for a new multi extension. >> >> Consider the following rule, which is written in BioNetGen language >> (BNGL) or kappa, which is essentially the same as BNGL: >> >> Mol1(binding_site1~state1)+Mol2(binding_site2)<-> >> Mol1(binding_site1~state1!1).Mol2(binding_site2!1) >> >> This "rule" says that molecules "Mol1" and "Mol2" associate via a >> chemical bond between "binding_site1" and "binding_site2." Moreover, >> binding_site1 has a state, which is called "state1," and >> binding_site1 >> must be in state1 for the bond to form between binding_site1 and >> binding_site2. I hope I have done a good job of explaining what this >> rule means - let me know if I need to clarify anything. Anyway, as >> you can see from this rule, we think of molecules as having >> components >> (which can be binding sites) and we think of components as having >> states. If I understand correctly, according to the conventions of >> multi, binding sites do not have states; only molecules (or more >> precisely speciesTypes) have states. The important point is that >> multi does not associate states with binding sites. Do I understand >> correctly? >> >> If I understand correctly, then we cannot encode the rule above using >> multi. Instead, we would have to encode a different, but >> functionally >> equivalent rule: >> >> Mol1(binding_site1,feature~state1)+Mol2(binding_site2)<- >>> Mol1(binding_site1!1,feature~state1).Mol2(binding_site2!1) >> >> In this new rule, there is a StateFeature, "feature," associated with >> Mol1 that is assigned the state "state1." This is fine in that the >> new rule will behave the same as the first rule, i.e., the two rules >> are functionally equivalent. (I hope that makes sense.) However, >> there is some loss of information, information that is useful for >> annotation purposes. In the new rule, we have no idea that "feature" >> is associated with "binding_site1," which would be the case if >> "binding_site1" is an ITAM and "feature" is the phosphorylation >> status >> of the ITAM. The important point is that a StateFeature can be >> related to a BindingSite. I think it is useful to record >> relationships between StateFeatures and BindingSites for annotation >> purposes at least. >> >> On the basis of the prolegomena, I propose that a new multi attribute >> be introduced, which can perhaps be called "belongsTo" or >> "associatedWith," that can be used to record relationships between >> StateFeatures and BindingSites. The attribute could be optional. >> >> Thoughts? >> >> --Bill >> >> On Sep 22, 2009, at 3:39 PM, Nicolas Le novère wrote: >> >>> Hi Bill, >>> >>> Bill Hlavacek wrote: >>> >>>> I am concerned about how to represent a "binding site" that has >>>> multiple states. An example of binding site with multiple states >>>> is >>>> the ITAM in the alpha or beta chain of the B cell antigen receptor, >>>> which is a docking site for certain proteins that contain an SH2 >>>> domain, such as the protein tyrosine kinases Lyn and Syk. Such an >>>> ITAM is a docking site for Lyn when it is singly phosphorylated >>>> and a >>>> docking site for Syk when it is doubly phosphorylated. It is not >>>> reactive with either Lyn or Syk when it is NOT phosphorylated. The >>>> examples of BindingSite usage at the wiki do not account for this >>>> type >>>> of case, and it is not clear to me how it would be done. >>> >>> What you describe is not in fact a binding site with several >>> states. A >>> binding site can be bound or unbound. What you describe is a species >>> type >>> that contains a binding site, that can be bound or unbound, and a >>> state >>> feature that represents the phosphorylation state of two amino-acid >>> residues. The binding reactions are then affected by the states of >>> the >>> residues. What you need to do is to create: >>> >>> 1) a reaction representing the binding of B cell antigen receptor >>> with Lyn >>> 2) a reaction representing the binding of B cell antigen receptor >>> with Syk >>> >>> A rule on reaction 1) restricts it to take place only when the state >>> feature is monophosphorylated and a rule on reaction 2) restricts it >>> to >>> take place only when the state feature is biphosphorylated. >>> >>> Best. >>> >>> -- >>> Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome- >>> Trust >>> Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel: >>> +441223494521 >>> Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NOT >>> email) >>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/ >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry® Developer Conference in SF, >>> CA >>> is the only developer event you need to attend this year. Jumpstart >>> your >>> developing skills, take BlackBerry mobile applications to market and >>> stay >>> ahead of the curve. Join us from November 9-12, 2009. Register >>> now! >>> http://p.sf.net/sfu/devconf >>> _______________________________________________ >>> Sbml-multi mailing list >>> Sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-multi >> >> William S. Hlavacek, Ph.D. >> Theoretical Biology and Biophysics Group >> Theoretical Division >> Mail Stop K710 >> Drop Point 03041003U >> Los Alamos National Laboratory >> Los Alamos, NM 87545 >> Tel: 505-665-1355 >> Fax: 505-665-3493 >> E-mail: wi...@la... >> http://www.t6.lanl.gov/wish/ >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, >> CA >> is the only developer event you need to attend this year. Jumpstart >> your >> developing skills, take BlackBerry mobile applications to market and >> stay >> ahead of the curve. Join us from November 9-12, 2009. Register >> now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> Sbml-multi mailing list >> Sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-multi >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, >> CA >> is the only developer event you need to attend this year. Jumpstart >> your >> developing skills, take BlackBerry mobile applications to market and >> stay >> ahead of the curve. Join us from November 9-12, 2009. Register >> now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> Sbml-multi mailing list >> Sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-multi > > William S. Hlavacek, Ph.D. > Theoretical Biology and Biophysics Group > Theoretical Division > Mail Stop K710 > Drop Point 03041003U > Los Alamos National Laboratory > Los Alamos, NM 87545 > Tel: 505-665-1355 > Fax: 505-665-3493 > E-mail: wi...@la... > http://www.t6.lanl.gov/wish/ > > > > > > > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Sbml-multi mailing list > Sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-multi ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Sbml-multi mailing list Sbm...@li... https://lists.sourceforge.net/lists/listinfo/sbml-multi |