Standardized Term Names--cell ontology and GO

Sue Rhee rhee at acoma.Stanford.EDU
Mon Feb 21 23:10:45 PST 2005


I agree with both Chris and Alexander's views. While the cell ontology is
much smaller effort than GO, Michael, Jonathan, and I are interested and
somewhat committed to improving the cell ontology to use
community-accepted terminology. May I suggest that you include Michael
Ashburner, Jonathan Bard, and myself in the recipients of the obol run and
we will try to resolve the name conflicts? Also, if anyone has any other
term-related issues relevant to cell ontology such as those brought up by
Alex in the thread below, please send them to Michael Ashburner, who is
the official curator of cell ontology.

Many thanks,
Sue

On Mon, 21 Feb 2005, Chris Mungall wrote:

>
> Hi Alex - I agree completely. I will create a specific cell ontology
> alignment report next obol run
>
> On Mon, 21 Feb 2005, Alexander Diehl wrote:
>
> > Chris,
> >
> > While I would like to see the cell ontology continued to be improved,
> > I think that its use in constructing GO terms cannot be forced at
> > this time for the reasons I mentioned previously.  In particular, I
> > don't feel the cell ontology can be considered authoritative at this
> > time and its naming conventions differ significantly from the GO.
> > Nevertheless, it would be useful for interested parties to compare
> > the cell ontology with the implicit GO cell ontology either
> > computationally or by hand to look for discrepancies between the two
> > and add appropriate synonyms where needed.  I would also suggest the
> > GO editors at EBI could make a point of comparing the two ontologies
> > whenever a GO term containing a cell type name is being coined or
> > modified in order to ensure the two ontologies are more in harmony by
> > suggesting changes to one or the other ontology.
> >
> > -- Alex
> >
> >
> > At 11:46 AM -0800 2/21/05, Chris Mungall wrote:
> > >Alexander,
> > >
> > >The cell ontology is still young and not yet seeing much active use, so
> > >it's not surprising it's incomplete and has problems. I had envisioned one
> > >of the main users of the cell ontology as being the GO curators. It seems
> > >that instead GO curators are focusing their energies on getting the
> > >implicit cell ontology within GO correct, and ignoring the cell ontology
> > >(I may be mischaracterizing here, I don't know to what extent annotators
> > >are doing curation).
> > >
> > >I guess this is perfectly understandable, given that this is the GO
> > >consortium and not the cell ontology consortium. However, I think it is
> > >extremely counterproductive in the long run.
> > >
> > >If we can somehow divert more energy to getting the cell ontology correct,
> > >then we can use this for automatic correction in GO.
> > >
> > >I realise this may seem quite daunting. There are indeed glaring
> > >inconsistencies. I'm not suggesting anyone sits down and manually sorts
> > >these out. The technology is there to automate this task. Obol currently
> > >reports inconsistencies, and obol is also capable of exporting the
> > >implicit cell (or anatomy or chemical or protein) ontology from GO.
> > >
> > >Soon we will have the ability to make genuine cross products between GO
> > >and CellOnt, with the cross-product recorded in the obo file. This will
> > >allow OBO-Edit to automatically flag inconsistencies (rather than having
> > >the curator examine a seperate text report).
> > >
> > >Of course, if this approach is to succeed, then it would require a slight
> > >shift in working practice. There would have to be more cross-talk between
> > >the cell ontology and GO. GO curators would still of course be free to
> > >define their 'own' cell ontology within GO that need not be consistent
> > >with the cell ontology (in either DAG structure, synonyms or spelling),
> > >but this would be deeply counterproductive. The correct approach would be
> > >to correct the cell ontology and have this automatically propagate into
> > >GO.
> > >
> > >Does this sound reasonable?
> > >
> > >Cheers
> > >Chris
> > >
> > >On Mon, 21 Feb 2005, Alexander Diehl wrote:
> > >
> > >>  The correct spelling is "eosinophil," which gets about 225000 hits in
> > >>  Google.  "Oesinophil" seems to be a mispelling, and gets about 30
> > >>  hits in Google.
> > >>
> > >>  As currently constituted, I would have a lot of problems with using
> > >>  the cell ontology as a source for correct nomenclature for cell types
> > >>  in the GO.  The cell ontology differs from standard usage for many
> > >>  terms and is far from complete.  It also lacks definitions for its
> > >>  terms as well as many commonly used synonyms.  There are glaring
> > >>  discrepancies between cell types in the GO and cell ontology terms,
> > >>  such as the use of T-cell in the GO and T_lymphocyte in the cell
> > >>  ontology, with no synonyms in either place to provide a mapping
> > >>  between the two terms.  All in all, one could probably construct an
> > >  > equally valid cell type ontology by deconstructing GO terms.
> > >>  Nevertheless, I do use the cell ontology in annotation notes to
> > >>  provide clarifying information when the GO term is inadequate, and I
> > >>  welcome its continued development.
> > >>
> > >>  GO term names should reflect actual usage and proper English, which
> > >>  was the source of my initial complaint.
> > >>
> > >>  -- Alex
> > >>
> > >>  At 10:05 AM -0800 2/21/05, Chris Mungall wrote:
> > >>  >[cc-ing Sue, even though I suspect she is already on the development
> > >>  >mailing list]
> > >>  >
> > >>  >Let me see if I understand
> > >>  >
> > >>  >You want to just have name='oesinophil differentiation', and not bother
> > >>  >having exact_synonym='oesinophil cell differentiation'?
> > >>  >
> > >>  >That seems very sensible, since it's not a good use of curator time to
> > >  > >insert these automatable synonyms. You certainly shouldn't be spending any
> > >>  >time on this to help an automatable parser like Obol!
> > >>  >
> > >>  >Are you also saying you'd like Obol to automatically add these synonyms?
> > >>  >We're not really set up for this kind of dataflow at the moment. There
> > >>  >would be some lag, during which time users search on Amigo for "oesinophil
> > >>  >cell differentiation" would come back empty handed (I think this should
> > >>  >actually be handled at the search level rather than at the synonym level,
> > >>  >though again we aren't set up for this yet).
> > >>  >
> > >>  >What Obol really cares about for these terms (and what I think we should
> > >>  >care about) is consistency with the cell ontology.
> > >>  >
> > >>  >Note that the cell ontology has "eosinophil" (NOT "oesinophil"). If this
> > >>  >is a genuine synonym then there should be a dialog with the cell ontology
> > >>  >curators to introduce that synonym in the cell ontology. Synonyms for GO
> > >>  >can then be computed automatically for this.
> > >>  >
> > >>  >Note also that the cell ontology has "chromophil cell" and "neutrophil".
> > >>  >Why not "chromophil" and "neutrophil cell"? If this reflects actual usage
> > >>  >then the term names should reflect this. If there are reasons to believe
> > >>  >that the cell ontology naming conventions are arbitrary, then the cell
> > >>  >ontology should be modified to be consistent with actual usage. The GO
> > >>  >should then take the cell ontology as the authorative source, and use the
> > >>  >corresponding naming convention.
> > >>  >
> > >>  >Cheers
> > >>  >Chris
> > >>  >
> > >>  >On Mon, 21 Feb 2005, Jennifer I Clark wrote:
> > >>  >
> > >>  >>  Hi Chris,
> > >>  >>
> > >>  >>  I was thinking more about the cell differentiation things. I reckon your
> > >>  >>  obol parser would be okay without the synonyms as long as I tell you a
> > >>  >>  few more naming rules.
> > >>  >>
> > >>  >>  We have the following kinds of differentiation terms:
> > >>  >>
> > >>  >>  x cell differentation
> > >>  >>  xblast differentation
> > >>  >>  xphil differentation
> > >>  >>
> > >>  >>  where the word endings 'blast' and 'phil' are synonyms for the word
> > >>  >>  'cell' in the first example. If I just tell you about these extra rules
> > >>  >>  then could you add them to the pareser? That way I wouldn't need to to
> > >>  >>  bother with the synonyms. I could add documentation to the website to
> > >>  >>  say that where these endings are in a term we don't add the word 'cell'
> > >>  >>  since it is redundant.
> > >>  >>
> > >>  >>  Thanks,
> > >>  >>
> > >>  >>  Jen
> > >>  >>
> > >>  >>  Chris Mungall wrote:
> > >>  >  >
> > >>  >>  >Whichever way we do it, I don't think we should mark up things in the
> > >>  >>  >ontology just to suit a particular piece of software.
> > >>  >>  >
> > >>  >>  >We should only do this if it doesn't impact curation time and if the
> > >>  >>  >notion of a 'formal' synonym for a term is useful to humans.
> > >>  >>  >
> > >>  >>  >Here are the criteria for a formal synonym:
> > >>  >>  >
> > >>  >>  >- it must be an exact synonym
> > >>  >>  >  [ and would still be designated as such in the obo file, it
> > >>  >>  >    would just have an additional qualifier ]
> > >>  >>  >
> > >>  >>  >- the existing term name is some kind of colloquial shorthand
> > >>  >>  >  that is readily recognised by most biologists, yet the naming
> > >>  >>  >  style of the shorthand is different from the consistent naming
> > >>  >>  >  style employed for similar terms
> > >>  >>  >
> > >>  >>  >- the existence of the synonym is a genuine rephrasing of the
> > >>  >>  >  term name, and does not exist by virtue of alternate spellings
> > >>  >>  >  of words.
> > >  > >>  >
> > >>  >>  >- the formal synonym must employ canonical spellings
> > >>  >>  >
> > >>  >>  >Why would this be useful to humans too? Well, sometimes it
> > >>may be useful
> > >>  >>  >to organise a set of terms such that either the formal synonym (or just
> > >>  >>  >the name if there is no designated formal synonym) is used as
> > >>the primary
> > >>  >>  >label. Thus the term with name "methanogenesis" will be
> > >>listed as "methane
> > >>  >>  >biosynthesis" and will have consistent labeling style with other "X
> > >>  >>  >biosynthesis" terms.
> > >>  >>  >
> > >>  >>  >If this isn't useful then we shouldn't bother.
> > >>  >>  >
> > >>  >>  >If we don't, then what I do think will be useful (and what
> > >>will be quite
> > >>  >>  >sufficient for obol) is to separate the useful exact_synonyms from the
> > >>  >>  >exact_synonyms that are derivable from the exact_synonyms of sub-terms.
> > >  > >>  >
> > >>  >>  >An example is "sulfite reduction/sulphite reduction". This is
> > >>only useful
> > >>  >>  >for the purposes of searching, and could be handled automatically.
> > >>  >>  >Displaying this synonym is of no use to the user.
> > >>  >>  >
> > >>  >>  >Cheers
> > >>  >>  >Chris
> > >>  >>  >
> > >>  >>  >On Fri, 18 Feb 2005, John Day-Richter wrote:
> > >>  >>  >
> > >>  >>  >
> > >>  >>  >
> > >>  >>  >>J Clark wrote:
> > >>  >>  >>
> > >>  >>  >>
> > >>  >>  >>
> > >>  >>  >>>If there was a way to mark the 'obol' synonym then I could easily
> > >>  >>  >>>assign the synonym type to that as I went along. Might this be a
> > >>  >>  >>>possibility with DAG-Edit John?
> > >>  >>  >>>
> > >>  >>  >>>
> > >>  >>  >>We have synonym types in OBO-Edit... just hang on! A beta-version will
> > >>  >>  >>be out soon (of course, you won't be able to save your changes to the
> > >>  >>  >>repository for a while after that, because everyone else will still be
> > >>  >>  >>using DAG-Edit).
> > >>  >>  >>
> > >>  >>  >>For now, I suggest you add a synonym dbxref to the OBO synonyms (like
> > >>  >>  >>"syntype:obol"). Once we move to full-fledged synonym types,
> > >>we can do a
> > >>  >>  >>quick search-and-replace to change those dbxrefs into synonym category
> > >>  >>  >>identifiers.
> > >>  >>  >>
> > >  > >>  >>    -John
> >
> >
>

-----------------------------------------------------------------------------
Sue Rhee                         	rhee at acoma.stanford.edu
The Arabidopsis Information Resource	URL: www.arabidopsis.org
Carnegie Institution of Washington	FAX: +1-650-325-6857
Department of Plant Biology		Tel: +1-650-325-1521 ext. 251
260 Panama St.
Stanford, CA 94305
U.S.A.
-----------------------------------------------------------------------------





More information about the Development mailing list