Thank you again for the feedback.
I have checked the KGML file (
the discrepancy you have reported seems to be that KEGG did not record
two molecules as complex (which is given by a 'group' entry, mostly
representing a protein complex, for example see ELK1/ELK4/SRF complex
MAPK pathway, http://www.genome.jp/kegg/pathway/hsa/hsa04010.html
can be downloaded at
Since at the moment KEGGgraph parses KGML files royally without any
post-modification, it cannot reflect the relation between TSC1 and
this example, even if visually it seems that KEGG wanted to present
protein/functional complex (btw, these two are also physially
with each other supported by PPI data). I suggest that we could do 2
1. Inform the staff at KEGG and discuss whether the relation
should be related (maybe into a complex node containing TSC1 and
all the interactions will be directed to the complex and an
be established between the two)
2. Add a new feature to KEGGgraph pathway to 'guess' the
between nodes based on their graphical attributes: say, if two
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
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
annotated correctly (I had a 'bad' example for this but gonna find it
and there is no uniform identifier available (so far as I know) for
complexes, while normally the KEGGgraphs are indexed by GeneID. A
work-around may be to assign a complex name like 'C1', however these
not unique across graphs and will lead to problems when graphs from
different sources have to be merged. Personally I tend to use cluster
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
2009/5/1 Paul Shannon <email@example.com>
> We have been using the admirable KEGGGraph package to obtain
> graphNEL form. It is very useful.
> mTor is the signalling pathway we are working with:
> We find that proteins which appear only as members of a complex are
> in the graphNEL.
> For instance, "hsa:7248" (TSC1) forms a complex with "hsa:7249"
> TSC2 is well connected, but its complex partner TSC1
> is an orphan.
> There are a number of ways to handle this, some quite sophisticated,
> not. Once could define a node for the complex, create edges to that
> and then specify (with a 'complex membership' edge) that TSC1 and
> mTor presents a good (though challenging) use case: there are two
> differently-acting complexes which include mTor and GBL. The third
> of the complex is different, however, as are the interactions the
> complexes participate in. This seems to argue for 'complex' being
> One simple improvement, which solves some of the 'orphan complex
> problem, could be this workaround: all members of each complex
> in all the interactions which belong to the complex.
> Here is some incomplete (but suggestive) evidence of the orphan
> TSC1. A more detailed search reveals that TSC1 is not found in the
> 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"
> - Paul
> sessionInfo ()
> R version 2.9.0 (2009-04-17)
> attached base packages:
>  stats graphics grDevices utils datasets methods base
> other attached packages:
>  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
>  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):
>  cluster_1.11.13 tools_2.9.0
> Bioconductor mailing list
> Search the archives:
[[alternative HTML version deleted]]