Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

cell component ontology

Peter Karp pkarp at AI.SRI.COM
Wed Nov 2 23:53:26 PST 2005

Dear Michael,

First let me note that because I am on travel, it's difficult for
Peifen and I to confer before we reply, so please realize these
are my thoughts and I invite Peifen to chime in if she disagrees.
She certainly did much of the ground work on CCO, and I am
not an expert on every aspect of it by any means.

Here's how I view the situation.  We needed something that satisfies
our needs now.  Just as we have built on GO in building CCO (and
clearly acknowledged GO's valuable contribution to CCO), I hope GO
will incorporate CCO terms and Is-A ideas and relationships into
GO itself, as well as links back to CCO, just as we've included
links back to GO.  Once that is done, whenever that is, the ontologies
will be essentially identical.  There won't be a forking problem.
Translation between the two should be trivial because of the
links between equivalent terms.

So please consider CCO to be a request to add the new terms and
relationships we've defined to GO.  Perhaps you could view our
effort as one way groups might make proposals as to how
to extend GO.  We'd be delighted to see GO build on our work.

We're not trying to compete with GO.  We're trying to solve an
immediate need of ours, and to alert the community to what we've
done in the hope it may be useful to someone.

A few more detailed comments follow.

Michael Ashburner (Genetics) wrote:
> Peter and friends,
> I just want at this stage to comment on one statement from Peter:
> "Our main motivations
> for creating CCO were that GO lacked many terms we need .."
> Many databases use GO and they often come across terms that are absent from the GO
> but needed. We have a rigorous mechanism for allowing anyone to request new terms,
> via our Sourceforge site, and that is used very extensively. I would not like the
> absence of a term ... or of a number of terms ... to be used as a reason for not
> using the GO ! We have always been very responsive to requests for terms or large
> subtrees within the GO (witness our collaboration with the PAMGO folks).

I didn't say absence of terms was the only reason -- it's one of
several listed reasons, and it was the sum of those reasons that led
to our decision to create CCO.  Surely you will appreciate we can't
wait forever for GO to rectify certain shortcomings it may have
that are barriers to our work now.
> In principle GO also always has an is_a path to the root. I would admit that I am not
> sure that this has been completely fitted yet, but it is certainly what we want to have.

I'm afraid that "in principle" doesn't give us something tangible that
we can work with today.  I've already been waiting 4-5 years for these
is-a paths to be added, so you will understand why my expectation is
that it will be a while longer before they are all added.  Hopefully GO
can learn from some of our work on CCO and it will help the GO team to
speed their efforts.
> The new relationships in CCO are interesting, and I see no reason in principle why
> they could not be incorporated in the GO.

Ah, that is a pleasant shock to me.  My understanding is that from its inception
GO has had only two relationships, is-a and part-of.  So I had no reason to
expect addition of new relationships in the near future, nor for that matter
that a somewhat obscure relationship of interest to us (surrounds) should be
a high priority for you all.  By the way, I erred in my earlier message in
stating that Go didn't contain component-of; part-of certainly does fit the
bill there, but not for Surrounds.
> My concern, shared by Larry, is that one of the strengths of the use of GO by databases
> is that we achieve - in this domain - a de facto integration of these databases. Users
> can now query well over 20 very different databases for gene products annotated with GO
> terms. if the ontologies fork that will no longer be true. Had the MetaCyc databases
> used the GO then they could have submitted a MetaCyc gene_association table to the GO
> database and be included within this integrated set (within the domains of knowledge
> covered by the GO).

See my earlier comment about forking.

FYI, our next version of Pathway Tools will include support for annotating
genes with GO terms.


This message is from the GOFriends moderated mailing list.  A list of public
announcements and discussion of the Gene Ontology (GO) project.
Problems with the list?           E-mail: owner-gofriends at
Subscribing   send   "subscribe"   to   gofriends-request at
Unsubscribing send   "unsubscribe"  to  gofriends-request at

More information about the go-friends mailing list