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

Anand Kumar akumar at
Wed Nov 2 13:35:05 PST 2005

Hello Peter,

Even if your responses are not directly to me, I would suggest that the 
with leaf-node classes being treated as an instance is not a mere issue of
compliance with GO. A documentation of using GO terms does not solve the

When you use GO classes as instances, you manage to change the 
semantics or real
objects which GO classes stand for. A nucleus class is instantiated in this
nucleus in this petridish, which then is recorded as a row in database. Those
are instances, irrespective of which level you are documenting at, either in
petridish or in database rows. But that is not what CCO is representing;
otherwise CCO would have had trillions of nuclues instances from various
databases. CCO represents the type nucleus. And even if I started this point
with GO, this is the same in any other place: biological or medical: 
NCI Thesaurus, Snomed and so on. These all, and not just GO, are ontologies or
terminologies for classes, types, universals. And so is CCO.

So the question here is not of documentation or of compliance with GO 
or any one
or two OBO ontologies. The question here is about interoperability in general
and derivation of correct inferences.

And the good part is, that this change is not so difficult to do. Our 
work  and
of other groups with formal analysis of GO, OBO, UMLS, NCIT to name a 
few, have
only removed these errors and helped them be more interoperable and be able to
derive inferences. Such criticisms come for free. And these are errors, these
are not luxuries of an information modeller.

It would be good to start with this corrections with a smaller but dedicated
group and make the CCO not only more interoperable but also robust in itself.

Kind Regards,

Anand Kumar MBBS, PhD
University of Saarland
Postbox 151150
D-66041 Saarbrücken

Zitat von Peter Karp <pkarp at AI.SRI.COM>:

> Larry, You make some perfectly reasonable points.  Our final
> response will have to be to amend the CCO web pages to give
> more elaborate answers to the questions you raise, and that will likely
> take 1-2 weeks.  In the meantime, here are some shorter answers.
> I wonder though if you saw the web page under the "[more]" link
> toward the top of the CCO page -- the page I am referring to is
> Larry.Hunter at wrote:
>> Dear Peifen & CCO folks,
>> Thanks for making public your Cell Component Ontology.  It's great to
>> have people contributing their ontological work to the public!  I've
>> also cc'd this message to the best email address I could find at new
>> NCBO (see, which, moving forward, I think will
>> probably be the best place to have these discussions.
>> I do have a couple of concerns about the CCO that I'd like hear your
>> responses to. First, I agree with Anand's concerns (below) about the use of
>> instances in the CCO ontology.
> I'll respond to these issues taking your next message into account,
> in my next message.
>> Second, I think that anyone proposing an ontology that overlaps with
>> the domain of an existing OBO ontology (in this case, the cellular
>> component branch of the GO) has an obligation to at least explain the
>> relationships between the new ontology and the existing one.  Even
>> better would be to provide the information necessary for a merge of
>> the two.  It seems to me that many of the concepts in the CCO appear
>> in the GO. I think you need to tell us which concepts are new, where
>> there are conflicts, and how this ontology improves on the existing
>> one.  One possibility, given the difference in size between the GO and
>> the CCO, is that the CCO might be useful as a sort of "GO Slim" for
>> cell components.
> OK, we will document these issues more in our web pages, but the CCOdocument
> page does already address these in some detail.  Again, I wonder if
> you saw it.  Our
> web pages do already acknowledge GO and the fact that we have built on
> many terms from GO.  Of the 149 classes+instances in CCO, 99 already have
> links to GO.  Thus, CCO already tells you which of its terms correspond
> to GO, and which are new (those that lack GO links).  Our main motivations
> for creating CCO were that GO lacked many terms we need, GO lacks the
> proper Is-A taxonomy structure for embedding and properly reasoning
> with these terms (which of course I have been complaining about for
> years -- will the GO developers ever properly implement Is-A?),
> and GO lacks relationships that we needed for our
> application, namely Component-Of and Surrounded-By.
> Please though, let's not treat OBO as if it had some special status.
> Your same point is true of any new ontology that overlaps with any
> existing ontology, or of any new bioinformatics database that overlaps
> with any existing bioinformatics database.
> P

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