Schema Version: 1.3 Module: chado.sequence

Constraints 41

chado.sequence Tables

Table / View Referenced Foreign Keys Columns Type Comments
feature 30 3 13 Table

A feature is a biological sequence or a section of a biological sequence, or a collection of such sections. Examples include genes, exons, transcripts, regulatory regions, polypeptides, protein domains, chromosome sequences, sequence variations, cross-genome match regions such as hits and HSPs and so on; see the Sequence Ontology for more. The combination of organism_id, uniquename and type_id should be unique.

feature_contact 0 2 3 Table

Links contact(s) with a feature. Used to indicate a particular person or organization responsible for discovery or that can provide more information on a particular feature.

feature_cvterm 3 3 6 Table

Associate a term from a cv with a feature, for example, GO annotation.

feature_cvterm_dbxref 0 2 3 Table

Additional dbxrefs for an association. Rows in the feature_cvterm table may be backed up by dbxrefs. For example, a feature_cvterm association that was inferred via a protein-protein interaction may be backed by by refering to the dbxref for the alternate protein. Corresponds to the WITH column in a GO gene association file (but can also be used for other analagous associations). See for more details.

feature_cvterm_pub 0 2 3 Table

Secondary pubs for an association. Each feature_cvterm association is supported by a single primary publication. Additional secondary pubs can be added using this linking table (in a GO gene association file, these corresponding to any IDs after the pipe symbol in the publications column.

feature_cvtermprop 0 2 5 Table

Extensible properties for feature to cvterm associations. Examples: GO evidence codes; qualifiers; metadata such as the date on which the entry was curated and the source of the association. See the featureprop table for meanings of type_id, value and rank.

feature_dbxref 0 2 4 Table

Links a feature to dbxrefs.

feature_pub 1 2 3 Table

Provenance. Linking table between features and publications that mention them.

feature_pubprop 0 2 5 Table

Property or attribute of a feature_pub link.

feature_relationship 2 3 6 Table

Features can be arranged in graphs, e.g. "exon part_of transcript part_of gene"; If type is thought of as a verb, the each arc or edge makes a statement Subject Verb Object. The object can also be thought of as parent (containing feature), and subject as child (contained feature or subfeature). We include the relationship rank/order, because even though most of the time we can order things implicitly by sequence coordinates, we can not always do this - e.g. transpliced genes. It is also useful for quickly getting implicit introns.

feature_relationship_pub 0 2 3 Table

Provenance. Attach optional evidence to a feature_relationship in the form of a publication.

feature_relationshipprop 1 2 5 Table

Extensible properties for feature_relationships. Analagous structure to featureprop. This table is largely optional and not used with a high frequency. Typical scenarios may be if one wishes to attach additional data to a feature_relationship - for example to say that the feature_relationship is only true in certain contexts.

feature_relationshipprop_pub 0 2 3 Table

Provenance for feature_relationshipprop.

feature_synonym 0 3 6 Table

Linking table between feature and synonym.

featureloc 1 2 12 Table

The location of a feature relative to another feature. Important: interbase coordinates are used. This is vital as it allows us to represent zero-length features e.g. splice sites, insertion points without an awkward fuzzy system. Features typically have exactly ONE location, but this need not be the case. Some features may not be localized (e.g. a gene that has been characterized genetically but no sequence or molecular information is available). Note on multiple locations: Each feature can have 0 or more locations. Multiple locations do NOT indicate non-contiguous locations (if a feature such as a transcript has a non-contiguous location, then the subfeatures such as exons should always be manifested). Instead, multiple featurelocs for a feature designate alternate locations or grouped locations; for instance, a feature designating a blast hit or hsp will have two locations, one on the query feature, one on the subject feature. Features representing sequence variation could have alternate locations instantiated on a feature on the mutant strain. The column:rank is used to differentiate these different locations. Reflexive locations should never be stored - this is for -proper- (i.e. non-self) locations only; nothing should be located relative to itself.

featureloc_pub 0 2 3 Table

Provenance of featureloc. Linking table between featurelocs and publications that mention them.

featureprop 1 2 5 Table

A feature can have any number of slot-value property tags attached to it. This is an alternative to hardcoding a list of columns in the relational schema, and is completely extensible.

featureprop_pub 0 2 3 Table

Provenance. Any featureprop assignment can optionally be supported by a publication.

synonym 3 1 4 Table

A synonym for a feature. One feature can have multiple synonyms, and the same synonym can apply to multiple features.