20141022 - Phenotype2GO Pipeline

This page summarizes how the Phenotype2GO-based GO annotations will be handled for the WormBase builds and GO uploads.

Source of Annotations

• Phenotype2GO-based annotations are generated as part of the WB build based upon the presence of a phenotype associated with a perturbation of gene activity.
• The perturbation may be an RNAi experiment (or a variation).
• If the perturbation is an RNAi experiment, we will only associate the GO annotations with phenotypes resulting from disruption of the primary target. Secondary targets will not be used for Phenotype2GO annotations.
• All papers will be included in the pipeline (see below for some details on this).
• It will be up to Caltech to integrate the annotations into their curation database and perform any necessary editing and QC there.
• Phenotype2GO annotations displayed in WB will come from the Caltech .ace file uploaded with each build.

Source of Phenotype2GO Mappings

• All mappings between WB Phenotype Ontology and Gene Ontology terms are submitted during the build in a separate .ace file submitted by Ranjana.
• No mappings are present in the ?Phenotype objects submitted separately during the build, as this would have the potential to overwrite mappings coming from the GO curators.

GAFs

• The GAF generated as part of the WB build will contain all of the manual annotations and all IEA annotations.
• The Phenotype2GO-based annotations will be in a separate GAF and will use the IEA evidence code. This GAF will be the basis for what Caltech uploads to postgres after each build.
• Caltech will have to dump out a separate GAF from postgres for Phenotype2GO-based annotations to send to the GOC. Alternatively, if we've made no changes to the GAF from the build, we could append that GAF.
• The annotation date in the GAF will reflect the value of the Date_last_updated tag in the #Evidence hash when that information exists. Otherwise, the date in the GAF will reflect the date at which the GAF file was written as part of the build process.

Papers

• All papers will be included, but Caltech would like to exclude from the pipeline those phenotypes where the experiments reflect genetic interactions and not single-gene (presumed) phenotypes because we don't yet have a good way to express this correctly in the GAF.
• For example, the Lehner et al., 2006 paper has a large number of RNAi experiments, but these are all in the background of a genetic variation. Thus, the phenotypes are believed to be the result of an interaction.
• Could the Interaction tag in the ?RNAi object be used to exclude such experiments from the Phenotype2GO-based pipeline?
• If Caltech wanted, at some point we could review these papers and upload the annotations in bulk into using the IGI evidence code.

Uploading Annotations into Postgres

• Annotations generated by the Phenotype2GO pipeline will be uploaded into the postgres database at Caltech so they will be visible in the OA curation tool for review and editing.
• Caltech will need to devise an intelligent diff that will allow us to only upload those annotations that are new for any given build.
• Updates to annotations should be made in Protein2GO.
• Probably the best approach would be to compare the latest build GAF with the postgres GAF and a Protein2GO GAF and only upload those annotations where we don't have the combination of a gene and a paper. I don't think we can include GO term in this diff, since it is quite likely that the manual review will result in a more granular GO annotation.
• One complicating factor here is what happens when the curator simply removed the automated annotation? It will then appear as if the annotation is not in postgres but if it is still in the Phenotype2GO GAF, we will upload it again. Can we include a NO DUMP flag in the GO OA and instead of removing an annotation, we actually toggle the NO DUMP flag and then we have a GAF of NO DUMP annotations to compare to for upload? NO DUMP annotations would not be included in the .ace file and the GAF that goes to GOC, but would be used for deciding what annotations to upload to postgres.
• Also, there are papers where we probably don't want the GO annotations at all. We will need to keep this list at Caltech, but also need to define clearly why we aren't including the annotations from that paper, e.g., a certain threshold of annotations have been found to be incorrect.
• Also need to upload to postgres the variation Phenotype2GO annotations generated when Jolene was here.

Bigger Philosophical Issues

• Annotating to the process term versus annotating to the regulation of that process. This may be helped by the additional of a new explicit qualifier for GO, 'implicated_in', which is proposed to mean the gene product is somehow implicated in 'that process OR regulation of that process' but currently there is insufficient information to distinguish between the two roles.
• Creating more accurate annotations. One idea here is to combine a cellular-level process annotation with the Phenotype2GO-based organismal annotation.