Guidelines for GO textual definitions

From GO Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
  BEING REVIEWED

General points about definitions of GO terms

  • All terms require a definition and a definition cross-reference.
  • Definitions should explain clearly to the reader what is meant by a particular term.
  • They should be concise, full sentences (they should begin with an upper-case letter and end with a period).
  • As with term names, avoid using abbreviations that may be ambiguous (e.g. "ER" can mean "endoplasmic reticulum" or "estrogen receptor").
  • See Chris' post OntoTip: Write simple, concise, clear, operational textual definitions

General principle: Use genus-differentia patterns for definitions

Ideally, definitions should follow the genus-differentia ("Aristotelian") pattern: they should take the form of a genus (generic term, an is_a parent) and differentia (discriminating characteristics which mark instances of the specific term as being different from is_a sibling terms). Hence, the general form should be: An A that B, where A is the parent (genus), and B is what differentiates it from the parent (differentia).

For example, a spindle microtubule is defined as "Any microtubule that is part of a mitotic or meiotic spindle; anchored at one spindle pole."

  • Genus: A microtubule
  • Differentia: part of a mitotic or meiotic spindle; anchored at one spindle pole

The genus and differentia should make the definition necessary and sufficient such that all terms that are subclasses of that term satisfy the definition of the term, and any term that is not a subclass of the term does not satisfy the definition.

In some cases, it is appropriate to add to the core definition to improve the comprehensibility. This can include further explanations of the genus and/or differentia or examples of the term usage.

For processes, as much as possible, provide a clear description of the beginning and end of the process.


Standard definitions for specific terms

Design patterns

When available, design patterns define a standard textual definition. GO editors should check if a term has a design pattern before adding a textual defintion to a new term, or updating a textual definition.

Catalytic activity and children

  • Catalysis of the reaction: a + b = c + d
  • GO represents undirected reactions, so we use = in the definition (and not <=>, ->, for example).
  • Chemicals are represented without parenthesis, as in RHEA.

Cellular component processes

Development

Membranes and Envelopes

Metabolic process

Transporter terms standard definitions

Utilization

Deciding whether redefining a term should result in term obsoletion

A GO ID is really associated with a definition rather than with the term name. If we change the wording but not the meaning of a term, the GO ID stays the same; a new meaning requires a new GO ID, even if the text string doesn't change. Here's a trivial example that illustrates when we do and don't change GO IDs:

Assume that we have a term mouse, GO ID GO:0000123, in an ontology; it is defined as a small furry mammal.

We decide to change the term wording to Mus musculus, keeping the definition the same. In this case we merely update the text; the GO ID stays the same because the meaning stays the same. We may choose to keep "mouse" as a synonym, but there would still only be one ID associated with the term.

We decide that the term "mouse" should instead mean a piece of computer equipment. In this case, the old term and ID are moved to the obsolete category, and "mouse", as newly defined, gets a new GO ID, GO:0000456. The old GO ID and definitions are saved for posterity in case we ever need to know what happened to them.

GO ontology editors should be conservative when obsoleting terms, as this causes large potential impact on annotations, on other ontologies using GO, and on the stability of analysis results using GO. Obsoletions should be done only when a change in definition would make existing GO usages incorrect and correction is needed.

Cross-references for definitions

Definition cross-references are references that have helped generate the term and term's definition. There are three types of definition cross-references:

  • scientific citations supporting the creation of the term and its meaning (ideally, minimum one reference). Can include:
    • PMIDs (ideally all terms should have a PMID, but we have many terms not having them yet) (PREFERRED)
    • ISBN
    • Wikipedia
    • A website (to avoid as much as possible, as these tend to not be very stable)
    • If no other source is available, GOC:curators should be used. Examples where this is useful include grouping terms (like NAD(P)-containing terms) for which there is no direct evidence because the activity doesn't exist.
  • cross-references to other databases that provided the information for the definition. Includes:
    • RHEA* for enzymes (PREFERRED). Note that RHEAs IDs that are not yet public cannot be used in definition cross-references.
    • EC*
  • Other sources should be used as cross-references; and only as definition cross-references if there is no RHEA or EC:
    • KEGG* or KEGG pathway
    • MetaCyc reaction* or MetaCyc pathway (BP)
    • TCDB* (for transporters)
    • *Only relevant for MF terms.
    • Definition database cross-references also need to be added as General database cross-references.
  • attribution to the contributing group(s) or individual(s) (optional). In this case, use the database abbreviation 'GOC' and the initials of the user or the group as described in the GO users.yaml file.

Guidelines for individuals and groups dbxref abbreviations

  • Curators: use the GOC and the initials in lower case as the ID; e.g. a definition written by Michael Ashburner has the dbxref GOC:ma.
  • Group of curators: use the database abbreviation with '_curators' appended; e.g. a definition written by several curators at TAIR has the dbxref GOC:TAIR_curators.
  • Experts from the community: use the expert's initials following 'GOC:expert_'; e.g. a definition from John Pringle has the dbxref GOC:expert_jrp.
  • For definitions created at meetings, the dbxref has 'mtg_' followed by the meeting start date; e.g. definitions written at the June 2006 content meeting on CNS development have the dbxref GOC:mtg_15jun06.)

Review Status

Last reviewed: September 13th, 2023

Reviewed by: Pascale Gaudet


Back to: Editing the Ontology