QTL Data Model Description

Introduction to Proposed QTL Data Model

This is a description of a conceptual model for representing QTL data using a relational data model format. I have structured the information in the form of an entity relation diagram to help in the mapping of the QTL data types onto the existing MGD schema.

(Note that some of the links are probably not appropriate if taken literally. For example, I use jnum as the link to the reference in MGD. This is a conceptual link. It means that there should be a link to the MGD bibliographic tables, not that the link should be explicitly made using the J#. )

The model was designed to support basic queries such as:
***"How many QTLs are associated with Resistance/Susceptibility to viral infection?"
***"How many QTLs have been mapped to the region of chromosome 5 between markers D5Mityy and D5Mitxx?"
***"What genes have been mapped in the vicinity of QTLs associated with diabetes?"

Although a bit tricky, the data model can support some intra-specific comparisons.....(the tricky part is that QTL locations are often highly uncertain)

What this model does not do well is provide direct support for more complex queries that involve inter-specific comparisons

#######################

Table: Phenotype_Class

###################

Table: Phenotype

##############

Table: Trait

#############

Table: Mode

Mode describes whether the Phenotype is Induced, Spontaneous, or Hereditary. These divisions come from a review paper on QTL methodology written by Wayne Frankel (1995, TIG 11(12):471-477).

################

Table: KeyWord

Keyword is a type of synonymy table. I envision it as a means to link together studies that are about esentially the same complex phenotype but where the phenotypes are either slightly different or simply described differently. For example, a researcher that asks for all studies having to do with asthma would like to get back phenotypes like "bronchial hyperresponsiveness" in addition to those that have "asthma" explicitly in the complex trait name.

Because a Phenotype can have many Keywords I employ a linking table to join these two tables.

###############

Table: Strain

The Strain table is for linking information about the strain of the mice to the Phenotype. This is a skeleton table because the development of the vocabularies for these data types are under development by others in the MGI group.

#################

Table: QTL_Notes

QTL Notes is for comments about a QTL paper that can't be formally coded into the data model structure. Often times these are points raised by the authors of a paper in the discussion.

Some examples of the kinds of data that are important to record, but which may not fit into any of the currently defined categories are:

• brief descriptions of non-genetic effects such as litter effects, seasonal effects, age or sex effects
• information regarding provisional qtls (regions of the genome that may not have made the cutoff for statistical significance, but which the authors feel may be important)

#######################

Table: QTL_Experiment

QTL Experiment is the initial link to the heart of a QTL paper. Each manuscript (i.e., jnum) can have multiple QTL Experiments associated with it. However there is a one to one relationship between QTL Experiment and the Progeny population used for the experiment.

So, if a manuscript describes the results for an F2 population from cross X and and F2 population from cross Y. Those would be two separate QTL Experiments associated with the same jnum.

################

Table: Progeny

The Progeny table is for information about the progeny population upon which a QTL experiment is based. There can be multiple Mapping Crosses associated with a single Progeny. But there can be only one QTL_Experiment linked to a Progeny.

The # of strains and # of animals fields are meant for the animals used in the mapping component of a QTL experiment, not for the total number of animals evaluated for the trait or traits used to measure a complex phenotype. Varchar element types are indicated for these fields because often the information is reported best in text form. For example, the # of animals is often described as "4 animals per strain" which conveys more information to the user than just reporting the total number.

#####################

Table: Mapping_Cross

The Mapping Cross table provides links to the kinds of crosses used to generate the Progeny population. There can be multiple Mapping Crosses associated with a single progeny population. This generally is not the case, but the possibility exists. Representation of RI and RC sets is quite simple since controlled vocabs for those sets are in MGD already!

##################

Table: Marker_Map

Marker_Map is for representing data about how the marker map for the QTL analysis was constructed. There can be multiple marker types used for a single progeny population. For example, a microsatellite map could be combined with a few specific RFLP markers and some observable phenotype markers. A consequence is that there can be multiple marker map "methods" associated with a progeny used in a QTL analysis.

######################

Table: QTL_Detection

QTL_Detection is for representing the methods used to determine statistically significant associations between traits and markers. (The actual data are represented in the QTL_Marker table.) As with marker map methods, there can be multiple QTL detection methods used on a single progeny.

#######################

Table: QTL_Estimation

QTL_Estimation is for representing the methods used to estimate the location of QTLs.

##############

Table: Locus

The Locus table is for providing basic information about the putative QTL. The trait id is in this table because the locus needs to be associated with a specific trait name when there are multiple traits described or measured for a phenotype.

################

Table: QTL_Marker

QTL_Marker is for representing the association scores between traits and map markers. In other words, the table is for storing the results of a QTL_Detection method. Links to the marker symbol, name, and chromosome location can probably be accessed through the existing MRK_Marker table in MGD.

Two fields for the probability value are provided for when a range of probabilities are reported instead of a single value. The same is true for the association score. In some cases the association scores are listed as a range.

A note on the practicality of coding QTL_Marker information

While the QTL data model structure allows for any number of QTL_Markers to be described it is not practical to record every linkage reported in a manuscript. The suggested strategy is to record up to three of the most strongly associated (as measured by the probability values) markers with a particular QTL-trait combination.

The other table in this data model where marker-trait linkages are reported is the QTL_Location table. See the table description for more details.

#####################

Table: QTL_Location

QTL Location is for representing the predicted location for a QTL. This is a problem table because locality information is often very vague and the boundries of certainty are not clearly defined. For example, the flanking marker information is often not provided clearly so many of the locational data are purely text based descriptions.

Some Guidelines for Describing QTL Location:

• use proximal and distal support interval markers if reported,
• use other flanking markers if reported,
• use most tightly linked marker (according to Pvalue) if no flanking markers are given,
• use Peak LOD score instead of most tightly linked marker if both are given,
• if location of QTL is described vaguely (for example, "distal half of chromosome 3") use the comment field to report location

Ideally there should be a way to translate the location information encoded in this table into a "minimap" that MGD currently uses as a graphical report on locus position. QTLs might require a slightly different graphical representation to accomodate the location uncertainty. Maybe some kind of shaded rectangle to show approximate boundries. Of course this is only possible where the data supports the location inference. I'm not sure how useful it would be to provide a graphic with the distal or proximal part of a chromosome entirely shaded.

Another idea for down the road is to have authors submit the graphical output for QTL estimation from MapMaker in a gif format. I bet it would be easy to pop these things up on the Web. (This was actually Wayne and Ben's idea. They thought we might be able to scan the MapMaker images in from the manuscript. But I thought that might be a nightmare of copyright entanglements, etc. However, if the journal editors knew that the authors were going to submit the figures to MGD from the time the manuscript was submitted for consideration of publication it might not be such a big deal.) The image_id placeholder in the proposed table structure is for remembering this idea.

#######################

Table: Candidate_Genes

CandidateGenes is for representing what the authors claim are possible candidate genes for their QTL of interest. This will be static data of course. It would be nice to have a pointer to the most current list of genes that have been mapped to a QTL region since the publication of a study.

The criteria for being included as a Candidate Gene includes some justification by the authors as to why a gene might be involved in the expression of a complex phenotype. A statistically significant linkage or association with a gene in the putative QTL region is not sufficient justification for inclusion as a Candidate Gene.

The symbol, name, and chromosomal location information for the Candidate Genes are accessed through the current MRK_Markers table in MGD.