Tables

Linking table: experiments to the protocols they involve.

A phenotype 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. There is a unique constraint, phenotypeprop_c1, for the combination of phenotype_id, rank, and type_id. Multivalued property-value pairs must be differentiated by rank.

Property-value pairs for a pub. Follows standard chado pattern - see sequence module for details

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 http://www.geneontology.org/doc/GO.annotation.shtml#file for more details

Provenance. Linking table between features and publications that mention them

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

stock_cvterm links a stock to cvterms. This is for secondary cvterms; primary cvterms should use stock.type_id.

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

tag-value properties - follows standard chado model

Part of a stock or a clone of a stock that is used in an experiment

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

Additional extensible properties can be attached to a cvterm using this table. Corresponds to -AnnotationProperty- in W3C OWL format

links fpc fingerprints to the builds that use them

This linking table should only be used for nodes in taxonomy trees; it provides a mapping between the node and an organism. One node can have zero or one organisms, one organism can have zero or more nodes (although typically it should only have one in the standard NCBI taxonomy tree).

Linking table: experiments to the phenotypes they produce. There is a one-to-one relationship between an experiment and a phenotype since each phenotype record should point to one experiment. Add a new experiment_id for each phenotype record.

A protocol can be anything that is done as part of the experiment.

The geo-referencable location of the stock. NOTE: This entity is subject to change as a more general and possibly more OpenGIS-compliant geolocation module may be introduced into Chado.

A unique, global, public, stable identifier. Not necessarily an eXternal reference - can reference data items inside the particular chado instance being used. Typically a row in a table can be uniquely identified with a primary identifier (called dbxref_id); a table may also have secondary identifiers (in a linking table _dbxref). A dbxref is generally written as : or as ::.

Extensible properties for stock 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 stockprop table for meanings of type_id, value and rank.

Any stock can be globally identified by the combination of organism, uniquename and stock type. A stock is the physical entities, either living or preserved, held by collections. Stocks belong to a collection; they have IDs, type, organism, description and may have a genotype.

A project can be composed of several smaller scale projects

Comparison of phenotypes e.g., genotype1/environment1/phenotype1 “non-suppressible” with respect to genotype2/environment2/phenotype2.

This is the most pervasive element in the phylogeny module, cataloging the “phylonodes” of tree graphs. Edges are implied by the parent_phylonode_id reflexive closure. For all nodes in a nested set implementation the left and right index will be between the parents left and right indexes.

A reagent such as a primer, an enzyme, an adapter oligo, a linker oligo. Reagents are used in genotyping experiments, or in any other kind of experiment.

Additional extensible properties can be attached to a cv using this table. A notable example would be the cv version

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 eg 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 (eg a gene that has been characterized genetically but no sequence/molecular info 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- (ie non-self) locations only; i.e. nothing should be located relative to itself

A term, class, universal or type within an ontology or controlled vocabulary. This table is also used for relations and properties. cvterms constitute nodes in the graph defined by the collection of cvterms and cvterm_relationships

Model relationships between contacts

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

stock_dbxref links a stock to dbxrefs. This is for secondary identifiers; primary identifiers should use stock.dbxref_id.

The reflexive transitive closure of the cvterm_relationship relation. For a full discussion, see the file populating-cvtermpath.txt in this directory

Linking project(s) to contact(s)

Phenotypes are things like “larval lethal”. Phenstatements are things like “dpp-1 is recessive larval lethal”. So essentially phenstatement is a linking table expressing the relationship between genotype, environment, and phenotype.

A controlled vocabulary or ontology. A cv is composed of cvterms (aka terms, classes, types, universals - relations and properties are also stored in cvterm)) and the relationships between them

each row represents a run of the fpc contig building program, with a result file, linked to a bunch of fingerprints that it uses, and containing a bunch of fpc contigs

Metadata about a dbxref. Note that this is not defined in the dbxref module, as it depends on the cvterm table. This table has a structure analagous to cvtermprop

links a feature to dbxrefs. This is for secondary identifiers; primary identifiers should use feature.dbxref_id

A database authority. Typical dbs in bioinformatics are FlyBase, GO, UniProt, NCBI, MGI, etc. The authority is generally known by this sortened form, which is unique within the bioinformatics and biomedical realm. TODO - add support for URIs, URNs (eg LSIDs). We can do this by treating the url as a uri - however, some applications may expect this to be resolvable - to be decided

Model persons, institutes, groups, organizations, etc.

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

features can be arranged in graphs, eg exon part_of transcript part_of gene; translation madeby transcript if type is thought of as a verb, each arc makes a statement SUBJECT VERB OBJECT 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 cant always do this - eg transpliced genes. its also useful for quickly getting implicit introns

This is for relationships that are not strictly hierarchical; for example, horizontal gene transfer. Most phylogenetic trees are strictly hierarchical, nevertheless it is here for completeness.

Handle relationships between publications, eg, when one publication makes others obsolete, when one publication contains errata with respect to other publication(s), or when one publication also appears in another pub (I think these three are it - at least for fb)

Simple table linking a stock to a genotype. Features with genotypes can be linked to stocks thru feature_genotype -> genotype -> stock_genotype -> stock.

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

A stock_dbxref can have any number of slot-value property tags attached to it. This is useful for storing properties related to dbxref annotations of stocks, such as evidence codes, and references, and metadata, such as create/modify dates. This is an alternative to hardcoding a list of columns in the relational schema, and is completely extensible. There is a unique constraint, stock_dbxrefprop_c1, for the combination of stock_dbxref_id, rank, and type_id. Multivalued property-value pairs must be differentiated by rank.

stockcollection_stock links a stock collection to the stocks which are contained in the collection.

For germplasm maintenance and pedigree data, stock_relationship. type_id will record cvterms such as “is a female parent of”, “a parent for mutation”, “is a group_id of”, “is a source_id of”, etc The cvterms for higher categories such as “generative”, “derivative” or “maintenance” can be stored in table stock_relationship_cvterm

Global anchor for phylogenetic tree.

Linking table between feature and synonym

Property/value associations for geolocations. This table can store the properties such as location and environment

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

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

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

each row is an contig in an fpc build, linked to clones it contains via fpc_contig_clone table

In addition to the primary identifier (cvterm.dbxref_id) a cvterm can have zero or more secondary identifiers/dbxrefs, which may refer to records in external databases. The exact semantics of cvterm_dbxref are not fixed. For example: the dbxref could be a pubmed ID that is pertinent to the cvterm, or it could be an equivalent or similar term in another ontology. For example, GO cvterms are typically linked to InterPro IDs, even though the nature of the relationship between them is largely one of statistical association. The dbxref may be have data records attached in the same database instance, or it could be a “hanging” dbxref pointing to some external database. NOTE: If the desired objective is to link two cvterms together, and the nature of the relation is known and holds for all instances of the subject cvterm then consider instead using cvterm_relationship together with a well-defined relation.

Genetic context. A genotype is defined by a collection of features, mutations, balancers, deficiencies, haplotype blocks, or engineered constructs.

Handle links to eg, pubmed, biosis, zoorec, OCLC, mdeline, ISSN, coden…

The environmental component of a phenotype description.

each row is a band in a gel lane or capillary run

For example, for orthology, paralogy group identifiers; could also be used for NCBI taxonomy; for sequences, refer to phylonode_feature, feature associated dbxrefs.

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

Property/value associations for protocol.

Relationships between reagents. Some reagents form a group. i.e., they are used all together or not at all. Examples are adapter/linker/enzyme experiment reagents.

The organismal taxonomic classification. Note that phylogenies are represented using the phylogeny module, and taxonomies can be represented using the cvterm module or the phylogeny module

Tracks citations global to the tree e.g. multiple sequence alignment supporting tree construction.

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

links fpc contigs with the clones that are a part of them

Cross-reference experiment_stock to accessions, images, etc

Linking table: experiments to the genotypes they produce. There is a one-to-one relationship between an experiment and a genotype since each genotype record should point to one experiment. Add a new experiment_id for each genotype record.

each row defines a composite dataset, downloadable at the url cxgn-resource://name, that is composed of other downloadable datasets, according to the expression column. See CXGN::Tools::Wget for the accompanying code

Provenance. Linking table between stocks and, for example, a stocklist computer file.

each row here is one fpc build series, like “China FPC builds”. captures when different fpc builds are different versions of the same build

Linking nd_experiment(s) to publication(s)

A documented provenance artefact - publications, documents, personal communication

A relationship linking two cvterms. Each cvterm_relationship constitutes an edge in the graph defined by the collection of cvterms and cvterm_relationships. The meaning of the cvterm_relationship depends on the definition of the cvterm R refered to by type_id. However, in general the definitions are such that the statement all SUBJs REL some OBJ is true. The cvterm_relationship statement is about the subject, not the object. For example “insect wing part_of thorax”

The table stockcollectionprop contains the value of the stock collection such as website/email URLs; the value of the stock collection order URLs.

Cross-reference experiment to accessions, images, etc

The lab or stock center distributing the stocks in their collection.

A stock 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. There is a unique constraint, stockprop_c1, for the combination of stock_id, rank, and type_id. Multivalued property-value pairs must be differentiated by rank.

an author for a publication. Note the denormalisation (hence lack of _ in table name) - this is deliberate as it is in general too hard to assign IDs to authors.

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

each row is a lane in a gel or a single capillary run of a single clone

Property/value associations for experiment_stocks. This table can store the properties such as treatment

A cvterm actually represents a distinct class or concept. A concept can be refered to by different phrases or names. In addition to the primary name (cvterm.name) there can be a number of alternative aliases or synonyms. For example, -T cell- as a synonym for -T lymphocyte-

Linking project(s) to publication(s)

A summary of a set of phenotypic statements for any one gcontext made in any one publication.

Provenance for feature_relationshipprop