Hi Paul, Thank you for your suggestive comments, I try to give my views and encourage more open discussions: 1) I had requested KEGG staff for technical questions several times and they always give me very positive and quick responses, although I have never attempted to ask to update a KEGG graph directly. I think it is worth trying. In this sense WikiPathway is a good idea to collect wisdom of the community, although pratically there is some technical barriers at the moment, which we have discussed before, preventing users from using their graph attributes - for example I am still working on decryping the NFkB pathway they present, I have to admit that the edges stored in the XML files are extremely hard to tackle - maybe I will write you another email discussing this separately. 2) That's what all we want to do, I guess. I am also very interested in this topic. One of the problems we shall face, for example, is the ambigious edge annotation of pathways constructed from PPI data - how can we know an interaction represent phosphorylation, ubiquitination or something else? In this sense STRING is a good attempt, yet it is still far from a complete picture of pathways. 3) Good point. Graph and hypergraph classes are very good starting point from my point of view. It would be very interesting to try to parse networks in a certain framework. Reviews from W. Huber et al. ( http://www.biomedcentral.com/1471-2105/8/S6/S8) and many other distinguished authors may help and it is also worth we bioc devers sitting together to discuss. 4) I am working currently on several public databases trying to create similar interfaces with KEGGgraph, including NCI's and some others (like Human Cell Map and WikiPathway, although at the moment there is some difficulties). VJ Carey contributed the excellent Rredland which could help in BioPAX formats, rsbml package is used to parse SGML formats, RpsiXML is already able to parse PSI-MI formats, KGML files are interfaced by KEGGgraph. Hence we are holding many tools now which could help to bring public exchangable pathway data into a computational environment R. If you like we can further discuss, I hope that such a project could help both experimentalists and computational biologists to understand the pathways better. 5) The reason for such a design is efficiency, which I learned when I coded RpsiXML. In the case of many interactor/interactions, benchmark results favor the use of environment to retrieve the data, especially in the cases where the objects have to be copied. It may be changed in the future, but I would say until necessary - in a very early version I had once implemented list-like attributes, but then abolished it. Thank you very much for the kind helpful discussions. Wish you a nice weekend, Best wishes, David 2009/5/1 Paul Shannon <pshannon@systemsbiology.org> > Hi David, > > Thanks very much for your response. A few comments: > > 1) If the orphan status of TSC1 is the result of an omission in the kgml, > then I am all in favor or your suggestion to ask the KEGG staff if they can > fix it. Have you any had any luck with such requests in the past? Your > second 'guess' option might be worth adding if they are not very responsive. > > 2) You observe that TSC1 and TSC2 'physically interacting with each other > [is] supported by PPI data'. This suggests a topic we have been mulling > over; maybe you have some ideas. Judicious combination of interaction and > pathway data is our goal. The danger, of course, is that you get a rather > useless hairball. Have you experimented with merging PPI data with a KEGG > graph? > > 3) As pathway and interaction data matures, and as packages such as yours > and Tony Chiang's makes it available in bioc, we may try to identify some > good conventions for handling, within the bioc graph classes, things like > complexes, and multiple edges between nodes which are the result of > combining datasets. > > 4) The National Cancer Institute's "Pathway Interaction Database" offers > files in BioPAX level 2 format. Could you be tempted to create a package > (like KEGGgraph) for that data? > > 5) I notice that you store edge and node attributes for a KEGGgraph as > (respectively) a single large environment in nodeDataDefaults and > edgeDataDefaults. It seems a little more natural to me to separate the > environment out into single entries assigned to node- and edge- specific > nodeData and edgeData. What do you think? Your current approach is > certainly usable, of course. > > Thanks for all the good work! > > - Paul > > > > > On May 1, 2009, at 12:19 AM, Jitao David Zhang wrote: > > Hi Paul, >> >> Thank you again for the feedback. >> >> I have checked the KGML file ( >> ftp://ftp.genome.jp/pub/kegg/xml/organisms/hsa/hsa04150.xml), the reason >> for the discrepancy you have reported seems to be that KEGG did not record >> these two molecules as complex (which is given by a 'group' entry, mostly >> representing a protein complex, for example see ELK1/ELK4/SRF complex in >> MAPK pathway, http://www.genome.jp/kegg/pathway/hsa/hsa04010.html, KGML >> file can be downloaded at >> ftp://ftp.genome.jp/pub/kegg/xml/organisms/hsa/hsa04010.xml). >> >> Since at the moment KEGGgraph parses KGML files royally without any >> post-modification, it cannot reflect the relation between TSC1 and TSC2 in >> this example, even if visually it seems that KEGG wanted to present them as >> protein/functional complex (btw, these two are also physially interacting >> with each other supported by PPI data). I suggest that we could do 2 things: >> • Inform the staff at KEGG and discuss whether the relation between >> them should be related (maybe into a complex node containing TSC1 and TSC2, >> while all the interactions will be directed to the complex and an >> interaction must be established between the two) >> • Add a new feature to KEGGgraph pathway to 'guess' the >> relationship between nodes based on their graphical attributes: say, if two >> nodes shares boundary it may present a protein complex. This may, under >> certain circumstances, lead to errorneous results, hence I suppose not to >> add it to the functionality by default but rather an addinitioal feature for >> advanced users. >> A few words about using complex as a node: it is definely fine. Two >> potential problems arise: the edges to the complex may be ambigious if not >> annotated correctly (I had a 'bad' example for this but gonna find it out), >> and there is no uniform identifier available (so far as I know) for these >> complexes, while normally the KEGGgraphs are indexed by GeneID. A >> work-around may be to assign a complex name like 'C1', however these ids are >> not unique across graphs and will lead to problems when graphs from >> different sources have to be merged. Personally I tend to use cluster to >> represent these complexes. This feature is still in testing and I will >> update the package once it is stable and productive. >> >> Thank you again for the feedbacks and I am open to further discussion. >> >> Best wishes, >> David >> >> 2009/5/1 Paul Shannon <pshannon@systemsbiology.org> >> We have been using the admirable KEGGGraph package to obtain pathways in >> graphNEL form. It is very useful. >> >> mTor is the signalling pathway we are working with: >> http://www.genome.jp/dbget-bin/get_pathway?org_name=hsa&mapno=04150 >> >> We find that proteins which appear only as members of a complex are >> orphans in the graphNEL. >> >> For instance, "hsa:7248" (TSC1) forms a complex with "hsa:7249" (TSC2). >> TSC2 is well connected, but its complex partner TSC1 >> is an orphan. >> >> There are a number of ways to handle this, some quite sophisticated, some >> not. Once could define a node for the complex, create edges to that node, >> and then specify (with a 'complex membership' edge) that TSC1 and TSC2 both >> belong. >> >> mTor presents a good (though challenging) use case: there are two >> differently-acting complexes which include mTor and GBL. The third member >> of the complex is different, however, as are the interactions the two >> complexes participate in. This seems to argue for 'complex' being a node >> type. >> >> One simple improvement, which solves some of the 'orphan complex node' >> problem, could be this workaround: all members of each complex participate >> in all the interactions which belong to the complex. >> >> Here is some incomplete (but suggestive) evidence of the orphan status of >> TSC1. A more detailed search reveals that TSC1 is not found in the target >> nodes of any of the edges of g.mTor. >> >> f <- '~/s/data/public/kegg/hsa04150.xml' >> g.mTor <- parseKGML2Graph (f) >> tsc1 <- 'hsa:7248' >> tsc2 <- 'hsa:7249' >> tsc1 %in% nodes (g.mTor) # TRUE >> tsc2 %in% nodes (g.mTor) # TRUE >> tsc2 %in% names (edges (g.mTor)) # TRUE >> tsc1 %in% names (edges (g.mTor)) # TRUE >> edges (g.mTor)[[tsc1]] # character(0) >> edges (g.mTor)[[tsc2]] # "hsa:6009" >> >> Thanks, >> >> - Paul >> >> >> sessionInfo () >> >> R version 2.9.0 (2009-04-17) >> i386-apple-darwin8.11.1 >> >> locale: >> en_US/en_US/en_US/C/en_US/en_US >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> other attached packages: >> [1] RBGL_1.20.0 gaggle_1.12.0 rJava_0.6-2 >> org.Hs.eg.db_2.2.6 RUnit_0.4.22 KEGG.db_2.2.5 RSQLite_0.7-1 >> [8] DBI_0.2-4 AnnotationDbi_1.6.0 Biobase_2.4.0 >> KEGGgraph_1.0.0 graph_1.22.0 XML_2.3-0 >> >> loaded via a namespace (and not attached): >> [1] cluster_1.11.13 tools_2.9.0 >> >> _______________________________________________ >> Bioconductor mailing list >> Bioconductor@stat.math.ethz.ch >> https://stat.ethz.ch/mailman/listinfo/bioconductor >> Search the archives: >> http://news.gmane.org/gmane.science.biology.informatics.conductor >> >> >> >> -- >> Cheers, >> David >> > > -- Cheers, David [[alternative HTML version deleted]]