Release Pipeline

From GO Wiki
Revision as of 14:18, 13 May 2024 by Pascale (talk | contribs) (→‎Types of releases)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


The information below is intended for GOC members who are providers of annotations. It describes how GOC processes annotations, which can be viewed at locations like AmiGO, downloaded from our sites, and queried via the SPARQL endpoint.

Annotations integrated in the GOC pipeline

These annotations are ingested daily. All IBA annotations are coming from PAINT. Others are filtered out.

Annotation sources

  • Groups wishing to contribute their annotations to GO must have their group added into the GO groups metadata:
    • Annotation files produced by GOC members are accessed via the URL or address provided by each group's datasets metadata file, in the source field.
    • The files must be made publicly available via HTTP(S) or FTP to be pulled in by GO. Important note: the source URL must resolve to the latest annotation file produced by the submitting group, since that link is used directly when fetching the data.
  • More information about the format of the datasets metadata file can be found in the metadata schema.yaml file.
  • Currently all data is ingested in GAF format. In the future, the GOC will switch to using GPAD/GPI for all internal data exchange.
  • Note that UniProt-all file is processed differently - ie the file is loaded directly, without the checks to which other files are submitted.

Data processing

Annotation QC checks

  • As files are read some lines may be modified or filtered as described in GO Rules Documentation
  • A number of checks are run to ensure the integrity of the data (either at the parsing step or later in the pipeline). Checks include: data format, validity of identifiers, and a number of annotation rules. There are three types of checks:
    • filter: Violations of the rule lead to filtering of annotations not conforming.
    • repair: Violations of the rule lead to a replacement of an incorrect entry by the correct entry (for example, annotations to GO term alternate identifiers are changed to the GO term main identifier).
    • report: Violations of the rule are reported but no action is taken by the QC/QA pipeline.
  • Annotation lines that failed a check are collated in each group's reports.html page: Snapshot Annotation Reports.

Annotation merging and file generation

  • The annotation release pipeline generates many different products, including primary products such as annotation and GPI files and reports (such as error reports) and inferred annotations (predictions) for providing feedback to GOC contributing groups like MODs and UniProt). Once the upstream files have been loaded, checked, and merged, GAFs, GPADs, GPIs, TTLs, reports, and prediction files are produced.

Manual QC step during GO data release process

  • After all files are produced, the pipeline is automatically halted, and manual input is needed for the release to be finalized.
    • The release process can be monitored on the GO Jenkins page
    • Data used for QC: Release stats and AmiGO staging, which are compared to the current stats and AmiGO site
    • Observations/problems/queries/actions are noted in this Google doc (notes are here: 2021 releases candidates QC - notes - 2019 and 2020 releases candidates QC - notes).
    • If there are issues with data from upstream sources:
      • We always report to the source what we find. We give groups up to 5 working days to fix the issues, and trigger another release when the new data is available, or after 5 days (which ever is first).
      • If the issue is 'blocking' (ie the fluctuation in the number of annotations is too large, or something is very wrong wit hthe data), we may decide to use the previous version of the upstream's data. We do this by pointing the source of the annotation to the previous imported file, save at current/products/annotations/..-src.gaf.

In some cases (all IEAs missing, all qualifiers missing, etc), we might decide not to load the data as is.

  • Procedure
    • The go-annotation-changes.tsv file is copied into a blank Google spreadsheet created in the Release Checks directory of the GO Google drive.
    • The new file is named YYYY-MM-DD Release candidate
    • First the section SUMMARY: DIFF BETWEEN RELEASES is checked for large differences.
      • Large changes (5,000 - 20,000) are OK for annotations by evidence cluster PHYLO and annotations by evidence cluster IEA, since that represents an overall small fraction of the changes in these groups of annotations
      • In 2020, EXP increased by 2-5,000 each month
      • Any decrease to 0 in any category of the stats is suspicious of some error, either by the contributing group of by the processing of the GO pipeline.
    • Second the section CHANGES IN ANNOTATIONS BY QUALIFIER is checked for large differences.
      • If there are large differences (>1-2 %), the section CHANGES IN ANNOTATIONS BY MODEL ORGANISM AND EVIDENCE (ALL) THEN QUALIFIER is checked to see which group contributed those changes.
    • CHANGES IN ANNOTATIONS BY GROUP usually do not exceed 1-2%. If there are larger changes, the section CHANGES IN ANNOTATIONS BY MODEL ORGANISM AND EVIDENCE (ALL) THEN QUALIFIER is used to determine where changes come from. Decreases in NAS, TAS, IEA are often due to annotation reviews and are usually OK (unless they are suddenly 0). Usually expect increases in EXP annotations. ISS-types of evidence are relatively stable or have small increases.
    • CHANGES IN REFERENCES AND PMIDS are also usually of less than 1%.
  • For groups or species with few annotations (less than 100), relatively minor changes cause large percentage changes, so absolute numbers should be considered in those cases.
  • AmiGO's faceted search is useful when large differences are observed, for example by evidence code, by a species that is not part of the 11 model organisms.

Types of releases

  • Official monthly releases: versioned and archived so that analyses performed with these data can be reproduced at any point in the future. Note that all files generated as part of the monthly release have a permanent, stable release identifier. Official releases are derived from snapshot (since 03-2024).
  • Weekly snapshot releases: intended for internal use by GOC members. Weekly snapshots are not versioned and not archived, therefore not citable. Note also that all files generated as part of the snapshot release DO NOT have permanent, stable release identifiers. (note also that these used to be daily; as of 03-2024 they are ran weekly).

Data publishing and access

Data produced by each release can be accessed at the URLs below:

Release Content

  • The release content may be accessed from the specific URLs listed above.
  • Each page of content is generally organized as:
    • Parent (a link to the parent directory)
    • Directories (a list of all directories or subdirectories within each specific location)
    • Files (a list of all files within each specific location)
  • The main list of directories, with information about the content found in each, follows below.


  • The annotations directory contains solely annotation files organized alphabetically by contributing group. The exception is the GOA/UniProt "all" files, which we filter and rename with a "filtered_" prefix.
  • The annotation files available here are those files produced *after* the QC/QA rules have been applied and include annotations from GOC annotations tools, i.e. PAINT.
  • Each group has three files, compressed using the gzip utility:
    • gaf
    • gpad
    • gpi
      • Note that the GPI file here corresponds to the GPAD annotation file, not the original GPI file produced by the contributing group.
  • An example of annotation files found in the annotation directory:


The metadata directory contains relevant metadata used by the pipeline. Examples include:

  • datasets.yaml (information about the groups that contribute annotations and where the associated files can be retrieved for the pipeline)
  • the list of valid GO_REFs
  • the list of GO rules


  • The ontology directory contains directories with ontology-related information as well as several different formats of the ontology.
  • Much of the content of this directory mirrors what is contained in
  • Directories that contain ontology-related information are:
    • extensions
    • external2go
    • imports (terms imported from external ontologies used in GO equivalence axioms)
    • reports
    • subsets (the yaml files for metadata on each GO subset)
  • Ontology files are:
    • go-base.owl
    • go-basic.json
    • go-basic.json.gz
    • go-basic.obo
    • go-basic.owl
    • go.json
    • go.obo
    • go.owl


The products directory contains six sub-directories:

  1. upstream_and_raw_data
    • As above, the annotations directory contains files that are at various stages of qc and not meant for general public consumption, organized alphabetically according to contributing group.
    • Files present in this directory are:
      • prediction.gaf (annotation predictions from annotation extensions and inter-ontology links)
      • src.gaf (original annotation source file)
      • gaf (PAINT only)
      • gpad (PAINT only)
      • gpi (PAINT only)
      • noiea.gaf (plus IEA filtered out (no PAINT annotations)
      • valid.gaf (original source file parsed and filtered after applying QA/QC rules but prior to merging with other files, e.g. PAINT)
  2. blazegraph
    • The production data available at
    • Includes:
      • All release GAF data, including PAINT
      • Production Noctua models
      • GO ontology
    • Note that there is also an internal blazegraph that also contains Noctua development models
  3. pages
    • These are HTML pages created during the pipeline for various purposes.
  4. panther
    • This contains PANTHER tree data, e.g. gene ids and PANTHER embedded tree structure.
    • This is used for AmiGO.
  5. solr
    • This contains the solr indexes that drive AmiGO.
  6. ttl
    • All production annotations available in ttl format (same information as contained in the blazegraph directory.


The release stats are files that are used to do quality assurance on the data (ontology and annotations) before GO releases. The code that generates the statistics is on the GO GitHub: (note that the same code is in go-site, which the the location from which the statistics are generated).

The files produced are:


The reports directory contains links to files that document the results of various QC/QA checks as well as a link to the gorule-report.html.

  • Report files are organized alphabetically by contributing group.
  • The types of reports are:
    • owltools-check.txt
    • prediction-experimental-report.txt
    • prediction-report.txt
    • report.html (this is the central report that contains all of the violations and other reports for a given resource)
    • summary.txt
    • report.json

Consuming and Displaying GO Data

GO Consortium Members (to confirm)

  • To get the most up-to-date data, contributing groups can download GO data (e.g. ontology and annotations) using the snapshot URLs. For example:
 Snapshot annotations:
 Snapshot ontology:
  • Groups may also present snapshot data on their individual sites.
  • However, for distributing annotation or ontology files, data from an versioned monthly release should be used.
  • Each contributing group should direct users to the appropriate group GAF in the current annotations directory
 Current annotations:
 Current ontology:

Groups using GO for research and analysis purposes

  • For citation purposes, groups should use the ontology and annotations from the official monthly release and cite the date and doi of the release they used.

GO Consortium Dataflow

GO consortium dataflow


Review Status

Last reviewed: May 18th, 2023

Reviewed by: Seth Carbon