-
Notifications
You must be signed in to change notification settings - Fork 35
GenotypingPlates
Genotyping plates in Breedbase represent 96 or 384 well plates. A genotyping plate is defined with a unique plate name, a genotyping facility, a genotyping project name, a plate format, a sample type, a breeding program, a location, a year, and a description. The genotyping facility can be Cornell IGD, Intertek, or BGI; while the plate format can be 96 or 384 wells and the sample type can be DNA, RNA, or Tissue. Each well in the plate has its own unique name, a row and column position, and a source observation unit name; the source observation unit name is the plot, plant, or tissue sample name of the field trial entity from which the sample in the well originated. Optionally, each well can have its own ncbi taxonomy id, operator name, notes, tissue type, extraction method, concentration, volume, and whether the well is blank.
There are three methods for adding genotyping plates into Breedbase. The first method is by using an Excel spreadsheet; each row in the spreadsheet represents a well and defines its unique name, row and column position, and the source observation unit name. Optionally, the properties listed above can be included. The second method is using the Android Coordinate Application (http://www.wheatgenetics.org/research/software/89-coordinate); using this app, a researcher can scan the barcode of the source observation unit name and indicate the position of the well on the plate. The Coordinate App allows for interactively defining the layout of the genotyping plate and automatically assigns a unique name for each well; ts output can be directly uploaded into Breedbase. The third method is using Breedbase to design the layout of the plate. In this method, the researcher provides a list of source observation unit names, whether they are plots, plants, or tissue samples in a field trial. Then they can optionally define if any well must be blank, and they can define all other optional well properties mentioned above; Breedbase will then design and save a plate layout for the new genotyping plate, which can be downloaded and assembled later by the researcher.
Once the genotyping plate is saved in Breedbase, it can be downloaded on demand in two genotyping vendor specific formats: Intertek and Dart. These vendors are not working on becoming BrAPI compliant at the time of writing; however, genotyping plate layout downloaded from Breedbase can be e-mailed or ground-mailed to these genotyping facilities along with the physical genotyping plate. An alternative, is the stored genotyping plate can be transferred to the genotyping facility using Breedbase via BrAPI. This requires that the genotyping facility has a BrAPI enabled information system that can accept genotyping plates for submission through the BrAPI specification. Cornell IGD has been actively implementing this connection to Breedbase, allowing a streamlined and seamless interface for sending genotyping plates for processing.
When Breedbase exports a genotyping plate layout, either through a file download or via automated protocols, the sample names are exported using the following convention: ‘well sample name|||germplasm name’. This is the identifier for which the genotyping vendor associates the generated genotyping data to, and for which the genotyping data is returned to the researcher. The reason for this convention, rather than using only the well sample name, is that often researchers like to perform analyses on the genotyping data prior to uploading it back into Breedbase; when researchers perform analyses on the genotyping data directly, they prefer to use germplasm names because they are easily identifiable. However, when the genotyping data is loaded into Breedbase, the genotyping data is associated to the well sample name; in this way Breedbase maintains maximum data integrity. Exporting the sample names using the described convention allows both use cases to occur on the genotyping data when it is returned from the genotyping vendor.
The genotyping plate is stored as an entry in the project table with EAV entries in the projectprop table for year, location, genotyping facility, plate format, sample type, and an indicator for whether the genotyping plate was submitted to the genotyping facility; the projectprop entries are saved using type names from the ‘project_property’ controlled vocabulary. The genotyping plate’s project entry is linked to the breeding program via the project_relationship table using the type name ‘breeding_program_trial_relationship’ from the ‘project_relationship’ controlled vocabulary. The genotyping plate’s project entry is linked to a single nd_experiment entry via the nd_experiment_project linking table; the type name of the nd_experiment entry is ‘genotyping_layout’ from the ‘experiment_type’ controlled vocabulary. The genotyping project name is stored in an entry of the nd_experimentprop table using the type name ‘genotyping_project_name’ from the ‘nd_experiment_property’ controlled vocabulary. The wells in the genotyping plate are stored as entries of the stock table using the type name ‘tissue_sample’ from the ‘stock_type’ controlled vocabulary; in an EAV model, entries in the stockprop table record the well row e.g. ‘A’, the well column e.g. ‘12’, the well position e.g. ‘A12’, concentration, volume, extraction method, the extraction person, the tissue type, notes, the acquisition date, and whether the well is blank, all under type names from the ‘stock_property’ controlled vocabulary. Each well stock entry is linked to the same nd_experiment entry described previously via the nd_experiment_stock table. The well stock entries are linked to their source observation stock entry via the stock_relationship table using the type name ‘tissue_sample_of’ from the ‘stock_relationship’ controlled vocabulary; the tissue sample stock entry is always linked to its associated germplasm stock entry, and is further linked to its associated source field trial plot, plant, and tissue sample entry using additional stock_relationship entries.
For performance reasons, in a manner similar to what was described for field trials above, the genotyping plate is cached as a JSON formatted string via an entry in the projectprop table. The JSON formatted string is an object of objects, where the top-level key in the object is the well position in the genotyping plate, e.g. ‘A12’, and the value object contains all layout information for that specific well, e.g. all the aforementioned stock_prop and stock_relationship elements. The cached layout is regenerated whenever an element of the genotyping plate is changed and allows fast display and download of the genotyping plate layout.