NOTE: We are working on migrating this site away from MediaWiki, so editing pages will be disabled for now.
Difference between revisions of "Chado Companalysis Module"
m |
m |
||
(9 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
− | = | + | The companalysis module is designed for the storage of computational sequence analysis. The key concept is that the results of a computational analysis can be interpreted or described as a sequence feature. |
+ | |||
+ | =Using the companalysis module= | ||
+ | |||
+ | The following are examples showing how to use this module to describe the results from a given computational analysis. | ||
+ | |||
+ | ==Alignment Results in Flybase== | ||
+ | |||
+ | Written by Andy Schroeder, the original Wiki page is here: http://cedar.bio.indiana.edu/mediawiki/index.php/Aligned_computational_analyses_implementation. | ||
+ | |||
+ | ===Background=== | ||
+ | |||
+ | Alignment of nucleic acids and conceptually back translated proteins to the | ||
+ | genomic chromosomal arms provides much of the evidence for gene model annotation. | ||
+ | Several different algorithms have been employed to produce alignments of various | ||
+ | types of features to the chromosomal arms. The aligned features and the | ||
+ | corresponding alignments are implemented in chado in a similar manner for each of | ||
+ | the analyses. | ||
+ | |||
+ | There also exists sets of data primarily derived from gene prediction algorithms | ||
+ | in which non-localized alignment match features and their associated genome localized | ||
+ | match features (analogous to hsp matches) are stored. These localized match features | ||
+ | are only localized via featureloc to the genome and not to a second type of feature. | ||
+ | |||
+ | ===General implementation=== | ||
+ | |||
+ | '''Nucleotide and protein alignments''' | ||
+ | <pre> | ||
+ | ---------------------------------------------- genome | ||
+ | ^ ^ | ||
+ | | _______A______ | alignment feature type = match | ||
+ | floc | ^ ^ | floc (rank = 0) | ||
+ | | | f_r f_r | | | ||
+ | --B---- ---C--- hsp feature type = match | ||
+ | | | | ||
+ | floc | | floc (rank = 1) | ||
+ | V V | ||
+ | ----D----- aligned feature type = EST, cDNA, protein etc. | ||
+ | </pre> | ||
+ | |||
+ | '''Predicted features''' | ||
+ | |||
+ | <pre> | ||
+ | ---------------------------------------------- genome | ||
+ | ^ ^ | ||
+ | | _______A______ | alignment feature type = match | ||
+ | floc | ^ ^ | floc (rank = 0) | ||
+ | | | f_r f_r | | | ||
+ | --B---- ---C--- hsp feature type = match | ||
+ | |||
+ | </pre> | ||
+ | |||
+ | ===Examples=== | ||
+ | |||
+ | See the diagrams above. | ||
+ | |||
+ | Feature A (uniquename = 4191059_sim4) is the alignment feature of type ''match''. | ||
+ | |||
+ | * ''feature.is_analysis'' = 't' | ||
+ | * this is an abstract feature used to group and order HSP features | ||
+ | * feature A is linked to the HSP features B and C via a ''feature_relationship'' with feature A as the object and features B and C as subjects with the ''feature_relationship'' rank indicating ordering of features | ||
+ | ** note that the rank has not been implemented for many of the current alignments (sim4 and sim4tandem) | ||
+ | * this feature is linked to ''analysis'' via ''analysisfeature'' | ||
+ | |||
+ | Feature B (uniquename = 10425228) and feature C (uniquename = 10425229) are HSP features. | ||
+ | |||
+ | * ''feature.is_analysis'' = 't' | ||
+ | * the HSP features linked via ''feature_relationship'' as described above to explicitly represent ordering and grouping and are linked via a ''partof'' relationship type | ||
+ | * these features are located to the genome (''srcfeature.id'' = arm) and this featureloc info has ''featureloc.rank'' = 0 | ||
+ | * the HSPs are also linked to the specific analysis via ''analysisfeature'' | ||
+ | ** for aligned sequences these features are also located to the aligned feature (i.e. cDNA, EST etc.) and this featureloc info has a ''featureloc.rank'' = 1 | ||
+ | * note that this only applies to aligned sequences and not gene predictions | ||
+ | |||
+ | Feature D (uniquename = CO056789) is the aligned feature i.e. cDNA, EST, protein. | ||
+ | |||
+ | * feature.is_analysis = 't' | ||
+ | * the aligned HSPs are located to this feature via ''featureloc'' with featureloc.rank = 1 | ||
+ | * ''featureloc.residue_info'' should contain the residues of this feature that correspond to the extent of the HSP | ||
+ | ** note that the ''residue_info'' is specific to the type of feature that is aligned (for example if a protein is aligned to the genome via blastx then the ''featureloc.residue_info'' should be aminoacid residues) | ||
+ | |||
+ | ===Evidence data types in chado=== | ||
+ | |||
+ | ====Aligned features==== | ||
+ | |||
+ | Here is a list from 'chado_dmel_r4_3_16a_reporting' of aligned feature types | ||
+ | and the algorithms used to align them (not filtered by species). | ||
+ | |||
+ | <pre> | ||
+ | SQL query: | ||
+ | SELECT DISTINCT c.name as feature_type, a.program | ||
+ | FROM feature alg, feature hsp, analysisfeature af, analysis a, cvterm c, featureloc fl | ||
+ | WHERE hsp.feature_id = af.feature_id and af.analysis_id = a.analysis_id | ||
+ | and hsp.feature_id = fl.feature_id and alg.feature_id = fl.srcfeature_id | ||
+ | and fl.rank = 1 and c.cvterm_id = alg.type_id | ||
+ | ORDER BY program; | ||
+ | |||
+ | results: | ||
+ | feature_type | program | ||
+ | ----------------------+------------------------------ | ||
+ | so | assembly | ||
+ | BAC | bdgp_unknown_clonelocator | ||
+ | EST | blastn | ||
+ | protein | blastx_masked | ||
+ | oligonucleotide | dmel_r3_to_dmel_r4_migration | ||
+ | protein | prosplign | ||
+ | RepeatMasker:dummy | repeatmasker | ||
+ | so | repeatmasker | ||
+ | EST | sim4 | ||
+ | alignment | sim4 | ||
+ | mRNA | sim4 | ||
+ | ncRNA | sim4 | ||
+ | pseudogene | sim4 | ||
+ | rRNA | sim4 | ||
+ | region | sim4 | ||
+ | snRNA | sim4 | ||
+ | snoRNA | sim4 | ||
+ | so | sim4 | ||
+ | tRNA | sim4 | ||
+ | transposable_element | sim4 | ||
+ | cDNA | sim4tandem | ||
+ | so | sim4tandem | ||
+ | cDNA | splign | ||
+ | protein | tblastn | ||
+ | EST | tblastx_masked | ||
+ | so | tblastx_masked | ||
+ | DNA | tblastxwrap_masked | ||
+ | so | tblastxwrap_masked | ||
+ | (28 rows) | ||
+ | </pre> | ||
+ | |||
+ | ====Predicted features==== | ||
+ | |||
+ | Note that this was determined by a process of elimination from the results of the following query: | ||
+ | <pre> | ||
+ | SELECT DISTINCT c.name, a.program | ||
+ | FROM feature map_feat, feature hsp, analysisfeature af, | ||
+ | analysis a, cvterm c, feature_relationship fr | ||
+ | WHERE hsp.feature_id = af.feature_id and af.analysis_id = a.analysis_id | ||
+ | and hsp.feature_id = fr.subject_id and map_feat.feature_id = fr.object_id | ||
+ | and c.cvterm_id = map_feat.type_id ORDER BY program; | ||
+ | |||
+ | and then removing those matches that corresponded to the alignment features for the | ||
+ | part A query | ||
+ | |||
+ | name | program | ||
+ | -----------------+------------------------------ | ||
+ | match | augustus | ||
+ | match | genewise | ||
+ | match | genie_masked | ||
+ | match | genscan | ||
+ | match | genscan_masked | ||
+ | match | promoter | ||
+ | match | repeat_runner_seg | ||
+ | match | tRNAscan-SE | ||
+ | syntenic_region | tblastn | ||
+ | match | twinscan | ||
+ | </pre> | ||
+ | |||
− | |||
=Tables= | =Tables= | ||
Line 169: | Line 325: | ||
---- | ---- | ||
+ | == UML diagram == | ||
+ | [[Image:ChadoMod-Companalysis.png|600px]] | ||
− | + | [[Category:Analysis]] | |
− | + | [[Category:BLAST]] | |
− | [[Category:Chado]] | + | [[Category:Chado Modules]] |
Latest revision as of 10:04, 26 May 2010
The companalysis module is designed for the storage of computational sequence analysis. The key concept is that the results of a computational analysis can be interpreted or described as a sequence feature.
Contents
Using the companalysis module
The following are examples showing how to use this module to describe the results from a given computational analysis.
Alignment Results in Flybase
Written by Andy Schroeder, the original Wiki page is here: http://cedar.bio.indiana.edu/mediawiki/index.php/Aligned_computational_analyses_implementation.
Background
Alignment of nucleic acids and conceptually back translated proteins to the genomic chromosomal arms provides much of the evidence for gene model annotation. Several different algorithms have been employed to produce alignments of various types of features to the chromosomal arms. The aligned features and the corresponding alignments are implemented in chado in a similar manner for each of the analyses.
There also exists sets of data primarily derived from gene prediction algorithms in which non-localized alignment match features and their associated genome localized match features (analogous to hsp matches) are stored. These localized match features are only localized via featureloc to the genome and not to a second type of feature.
General implementation
Nucleotide and protein alignments
---------------------------------------------- genome ^ ^ | _______A______ | alignment feature type = match floc | ^ ^ | floc (rank = 0) | | f_r f_r | | --B---- ---C--- hsp feature type = match | | floc | | floc (rank = 1) V V ----D----- aligned feature type = EST, cDNA, protein etc.
Predicted features
---------------------------------------------- genome ^ ^ | _______A______ | alignment feature type = match floc | ^ ^ | floc (rank = 0) | | f_r f_r | | --B---- ---C--- hsp feature type = match
Examples
See the diagrams above.
Feature A (uniquename = 4191059_sim4) is the alignment feature of type match.
- feature.is_analysis = 't'
- this is an abstract feature used to group and order HSP features
- feature A is linked to the HSP features B and C via a feature_relationship with feature A as the object and features B and C as subjects with the feature_relationship rank indicating ordering of features
- note that the rank has not been implemented for many of the current alignments (sim4 and sim4tandem)
- this feature is linked to analysis via analysisfeature
Feature B (uniquename = 10425228) and feature C (uniquename = 10425229) are HSP features.
- feature.is_analysis = 't'
- the HSP features linked via feature_relationship as described above to explicitly represent ordering and grouping and are linked via a partof relationship type
- these features are located to the genome (srcfeature.id = arm) and this featureloc info has featureloc.rank = 0
- the HSPs are also linked to the specific analysis via analysisfeature
- for aligned sequences these features are also located to the aligned feature (i.e. cDNA, EST etc.) and this featureloc info has a featureloc.rank = 1
- note that this only applies to aligned sequences and not gene predictions
Feature D (uniquename = CO056789) is the aligned feature i.e. cDNA, EST, protein.
- feature.is_analysis = 't'
- the aligned HSPs are located to this feature via featureloc with featureloc.rank = 1
- featureloc.residue_info should contain the residues of this feature that correspond to the extent of the HSP
- note that the residue_info is specific to the type of feature that is aligned (for example if a protein is aligned to the genome via blastx then the featureloc.residue_info should be aminoacid residues)
Evidence data types in chado
Aligned features
Here is a list from 'chado_dmel_r4_3_16a_reporting' of aligned feature types and the algorithms used to align them (not filtered by species).
SQL query: SELECT DISTINCT c.name as feature_type, a.program FROM feature alg, feature hsp, analysisfeature af, analysis a, cvterm c, featureloc fl WHERE hsp.feature_id = af.feature_id and af.analysis_id = a.analysis_id and hsp.feature_id = fl.feature_id and alg.feature_id = fl.srcfeature_id and fl.rank = 1 and c.cvterm_id = alg.type_id ORDER BY program; results: feature_type | program ----------------------+------------------------------ so | assembly BAC | bdgp_unknown_clonelocator EST | blastn protein | blastx_masked oligonucleotide | dmel_r3_to_dmel_r4_migration protein | prosplign RepeatMasker:dummy | repeatmasker so | repeatmasker EST | sim4 alignment | sim4 mRNA | sim4 ncRNA | sim4 pseudogene | sim4 rRNA | sim4 region | sim4 snRNA | sim4 snoRNA | sim4 so | sim4 tRNA | sim4 transposable_element | sim4 cDNA | sim4tandem so | sim4tandem cDNA | splign protein | tblastn EST | tblastx_masked so | tblastx_masked DNA | tblastxwrap_masked so | tblastxwrap_masked (28 rows)
Predicted features
Note that this was determined by a process of elimination from the results of the following query:
SELECT DISTINCT c.name, a.program FROM feature map_feat, feature hsp, analysisfeature af, analysis a, cvterm c, feature_relationship fr WHERE hsp.feature_id = af.feature_id and af.analysis_id = a.analysis_id and hsp.feature_id = fr.subject_id and map_feat.feature_id = fr.object_id and c.cvterm_id = map_feat.type_id ORDER BY program; and then removing those matches that corresponded to the alignment features for the part A query name | program -----------------+------------------------------ match | augustus match | genewise match | genie_masked match | genscan match | genscan_masked match | promoter match | repeat_runner_seg match | tRNAscan-SE syntenic_region | tblastn match | twinscan
Tables
Table: analysis
An analysis is a particular type of a computational analysis; it may be a blast of one sequence against another, or an all by all blast, or a different kind of analysis altogether. It is a single unit of computation.
F-Key | Name | Type | Description |
---|---|---|---|
analysis_id | serial | PRIMARY KEY | |
name | character varying(255) | A way of grouping analyses. This should be a handy short identifier that can help people find an analysis they want. For instance "tRNAscan", "cDNA", "FlyPep", "SwissProt", and it should not be assumed to be unique. For instance, there may be lots of separate analyses done against a cDNA database. | |
description | text | ||
program | character varying(255) | UNIQUE#1 NOT NULL Program name, e.g. blastx, blastp, sim4, genscan. | |
programversion | character varying(255) | UNIQUE#1 NOT NULL Version description, e.g. TBLASTX 2.0MP-WashU [09-Nov-2000]. | |
algorithm | character varying(255) | Algorithm name, e.g. blast. | |
sourcename | character varying(255) | UNIQUE#1 Source name, e.g. cDNA, SwissProt. | |
sourceversion | character varying(255) | ||
sourceuri | text | This is an optional, permanent URL or URI for the source of the analysis. The idea is that someone could recreate the analysis directly by going to this URI and fetching the source data (e.g. the blast database, or the training model). | |
timeexecuted | timestamp without time zone | NOT NULL DEFAULT ('now'::text)::timestamp(6) with time zone |
Tables referencing this one via Foreign Key Constraints:
Table: analysisfeature
Computational analyses generate features (e.g. Genscan generates transcripts and exons; sim4 alignments generate similarity/match features). analysisfeatures are stored using the feature table from the sequence module. The analysisfeature table is used to decorate these features, with analysis specific attributes. A feature is an analysisfeature if and only if there is a corresponding entry in the analysisfeature table. analysisfeatures will have two or more featureloc entries, with rank indicating query/subject
F-Key | Name | Type | Description |
---|---|---|---|
analysisfeature_id | serial | PRIMARY KEY | |
feature_id | integer | UNIQUE#1 NOT NULL | |
analysis_id | integer | UNIQUE#1 NOT NULL | |
rawscore | double precision | This is the native score generated by the program; for example, the bitscore generated by blast, sim4 or genscan scores. One should not assume that high is necessarily better than low. | |
normscore | double precision | This is the rawscore but semi-normalized. Complete normalization to allow comparison of features generated by different programs would be nice but too difficult. Instead the normalization should strive to enforce the following semantics: * normscores are floating point numbers >= 0, * high normscores are better than low one. For most programs, it would be sufficient to make the normscore the same as this rawscore, providing these semantics are satisfied. | |
significance | double precision | This is some kind of expectation or probability metric, representing the probability that the analysis would appear randomly given the model. As such, any program or person querying this table can assume the following semantics: * 0 <= significance <= n, where n is a positive number, theoretically unbounded but unlikely to be more than 10 * low numbers are better than high numbers. | |
identity | double precision | Percent identity between the locations compared. Note that these 4 metrics do not cover the full range of scores possible; it would be undesirable to list every score possible, as this should be kept extensible. instead, for non-standard scores, use the analysisprop table. |
Table: analysisprop
F-Key | Name | Type | Description |
---|---|---|---|
analysisprop_id | serial | PRIMARY KEY | |
analysis_id | integer | UNIQUE#1 NOT NULL | |
type_id | integer | UNIQUE#1 NOT NULL | |
value | text | UNIQUE#1 |