GO Annotation Guide

Description

This document describes the use of GO terms for annotating gene products. It will be more useful if you first read the general documentation and usage guide for more general background information about the GO project and how the ontology works.

Collaborating databases annotate their gene products (or genes) with GO terms, according to two general principles: First, annotations should be attributed to a source; second, each annotation should indicate the evidence on which it is based.

The Annotation Conventions section contains guidelines; they apply to all annotation methods and are particularly useful for manual literature-based annotation. The Annotation File Format section describes the content of the "gene association files" (i.e. association between a database object and a GO term) in which annotation data are stored. A forthcoming section will describe different Computational Annotation Methods that have been used by various contributing databases.

GO Annotation Conventions

Database objects (the level of attribution)

Because a single gene may encode very different products with very different attributes, GO recommends associating GO terms with database objects representing gene products rather than genes. At present, however, many participating databases are unable to associate GO terms to gene products, and therefore use genes instead. If the database object is a gene, it is associated with all GO terms applicable to any of its products. See the Annotation File Format section for more information.

References and evidence

• Every annotation must be attributed to a source, which may be a literature reference, another database or a computational analysis.
  
• The annotation must indicate what kind of evidence is found in the cited source to support the association between the gene product and the GO term. A simple controlled vocabulary is used to record evidence:
  

  IMP	inferred from mutant phenotype
  IGI	inferred from genetic interaction [with <database:gene_symbol[allele_symbol]>]
  IPI	inferred from physical interaction [with <database:protein_name>]
  ISS	inferred from sequence similarity [with <database:sequence_id>]
  IDA	inferred from direct assay
  IEP	inferred from expression pattern
  IEA	inferred from electronic annotation [to <database:id>]
  TAS	traceable author statement
  NAS	non-traceable author statement
  ND	no biological data available
  IC	inferred by curator

More information on the meaning and use of the evidence codes can be found in the GO Evidence Codes documentation.

General recommendations

• A gene product can be annotated to zero or more nodes of each ontology.
  
• Annotation of a gene product to one ontology is independent of its annotation to other ontologies.
  
• Annotate gene products in each species database to the most detailed level in the ontology that correctly describes the biology of the gene product.
  
• Keep the True Path Rule in mind: annotating to a term implies annotation to all parents via any path, so it is a good idea to check the parentage of a term before annotating (and request new terms or path corrections if necessary).
  
• There is an important distinction between a gene/gene product annotated to "unknown" function, process, and/or component, and one that has not been annotated. "Unknown" means that someone has tried annotating the gene, but didn't find any information. Absence of annotation implies that no one has looked.
  
• Curators are encouraged to annotate to terms from all three ontologies, using "unknown" liberally if necessary (see item above).
  
• For annotations to "unknown" from any of the three ontologies, curators should cite a reference within their database that explains that they found no relevant biological information in the literature (or any other sources they may have considered). The evidence code is ND, for "no data." Exception: if a paper explicitly says that something is unknown, the paper can be cited as the reference, with TAS or NAS as evidence.
  
• Uncertain knowledge of where a gene product operates should be denoted by annotating it to two nodes, one of which can be a parent of the other. For instance, a yeast gene product known to be in the nucleolus, but also experimentally observed in the nucleus generally, can be annotated to both nucleolus and nucleus in the cell component ontology. Even though annotation to nucleolus alone implies that a gene product is also in the nucleus, annotate to both so as to explicitly indicate that it has been reported in the two locations. The two annotations may have the same or different supporting evidence. Similar reports of general and specific molecular function or biological process for a gene product could be handled the same way (come up with some good examples). You also can annotate to multiple nodes that conflict with each other if there are conflicting claims in the literature.
  
• A gene product should be annotated with terms reflecting its normal activity and location. A function, process, or localization (component) observed only in a mutant or disease state is therefore not usually included. In some circumstances, however, what is "normal" depends on the point of view taken by the annotator. For example, many viruses use host proteins to carry out viral processes. The host protein is then doing something abnormal from the perspective of the host, but completely normal from the perspective of the virus. GO annotators handle these cases by including two taxon IDs in the "Taxon" column of the gene association file (see Annotation File Format, below). When two taxon IDs appear, the first is that of the organism that encodes the gene product, and the second ID is that of the organism that uses the gene product, and whose perspective is considered "normal" for that annotation.
  
• An individual gene product that is part of a complex can be annotated to terms that describe the the action (function or process) of the complex. This is colloquially known as annotating 'to the potential of the complex', and is a way to capture information about what a complex does in the absence of database objects and identifiers representing complexes. It is especially useful in cases where a complex has an activity, but the individual subunits do not. One example is the subunits of nuclear RNA polymerases, where none of the individual subunits have RNA polymerase activity, yet all of these subunits are annotated to 'DNA-dependent RNA polymerase activity', to capture the activity of the complex. Another example is ATP citrate lyase (ACL) in Arabidopsis: it is a heterooctomer, composed of two types of subunits, ACLA and ACLB in a A(4)B(4) stoichiometry. Neither of the subunits expressed alone give ACL activity, but co-expression results in ACL activity. Both subunits can be annotated to ATP citrate lyase activity.

Annotation File Format

Collaborating databases export to GO a tab delimited file, known informally as a "gene association file," of links between database objects and GO terms. Despite the jargon, the database object may represent a gene or a gene product (transcript or protein). Columns in the file are described below, a table showing the columns in order, with examples, is available.

The entry in the DB_Object_ID field (see below) of the association file is the identifier for the database object, which may or may not correspond exactly to what is described in a paper. For example, a paper describing a protein may support annotations to the gene encoding the protein (gene ID in DB_Object_ID field) or annotations to a protein object (protein ID in DB_Object_ID field).

The entry in the DB_Object_Symbol field should be a symbol that means something to a biologist, wherever possible (gene symbol, for example). It is not an ID or an accession number (the second column, DB_Object_ID, provides the unique identifier), although IDs can be used in DB_Object_Symbol if there is no more biologically meaningful symbol available (e.g., when an unnamed gene is annotated).

The object type (gene, transcript, protein, or protein_structure) listed in the DB_Object_Type field MUST match the database entry identified by DB_Object_ID. The text entered in the DB_Object_Name and DB_Object_Symbol can refer to the same database entry (recommended), or to a "broader" entity. For example, several alternative transcripts from one gene may be annotated separately, each with a unique transcript DB_Object_ID, but list the same gene symbol in the DB_Object_Symbol column.

Note that several fields contain database cross-reference (dbxrefs) in the format dbname:dbaccession. The fields are: GOid (where dbname is always GO), DB:Reference, With, Taxon (where dbname is always taxon).

Computational Annotation Methods

This section includes descriptions of automated annotation methods used by participating databases (descriptions have been provided by each group listed).

Copyright © 1999-2000 Gene Ontology Consortium. Permission to use the information contained in this database was given by the researchers/institutes who contributed or published the information. Users of the database are solely responsible for compliance with any copyright restrictions, including those applying to the author abstracts. Documents from this server are provided "AS-IS" without any warranty, expressed or implied.