Plant pedigrees

A pedigree (Figure 1) is a representation of how genetically discrete individuals are related (usually but not exclusively) in time to one another. It is therefore a representation of the genetic relationship between individual plant lines, their parents and progeny (predecessors and successors). Pedigrees are often used in human contexts to show the transmission of alleles responsible for genetic conditions of medical importance. In plants they are used as a framework along with environmental data, on which statistical analysis can be used to determine factors such as mode of inheritance (Identity by Descent, IBD and Identity by Association, IBA). Additionally, they are often used to check for potential genotyping errors, since these errors, by the very nature of Mendelian inheritance, are constrained by the pedigree structure in which they exist [5]. The accurate representation of pedigrees is therefore becoming increasingly important in plant breeding and genetics.

While there are defined standard nomenclatures for human pedigrees [7] there is no single formal system for plant pedigrees, however, there are moves towards defining standards. There are valid biological reasons for this including: the hermaphrodite nature of most plant species, the complexity of mating designs possible in plant genetics and, finally, the absence of any overseeing coordinating organisation.

While plant and animal breeding share routine breeding techniques such as standard crossing and back-crossing, pedigrees used in plant breeding display some subtle but important differences, often involving key shorthand conventions that are unique to plant mating designs leading to complex textual based records which can be difficult to read (see ‘Pedigree formats’ subsection). Firstly, the named entities in plant pedigrees may, but not always, represent a population of genetically identical individuals, not a single plant. While it is relatively simple to grow many plants from seed, potentially many decades after production, in humans and animals this is understandably not the norm. The generation of these genetically identical (homozygous) varieties is possible through doubled haploidy, inbreeding, or crossing of pairs of inbred lines to achieve what is termed an F1 hybrid. Successive inbreeding by self-pollination of these F1 generation plants leads to individual plants that are close to homozygous across all alleles. The exploitation of homozygous lines in crop species such as barley is a powerful tool in genetic analysis, removing some of the genetic complexities associated with species (such as humans) where there is a high level of heterozygosity.

Pedigree formats

Genetic transmission

Pedigree formats can be complex with no standard nomenclature; a. Purdy Notation System [8] was put forward by Purdy as a common format for representing small grain cereal pedigrees. Forward slashes ‘/’ are used to delimit lines. In this case A is crossed with B which is then crossed with C whose progeny is crossed with D. b. Lamacraft and Finlay notation [9] which was put forward as a format which could be more easily parsed by computers. The example here is the same as in the Purdy notation above. c. A typical pedigree that can be found in old records where a mixture of notations are used. These mixed notation systems are common and most breeders will use shorthand that is unique to them. These records are sometimes difficult to read and would benefit from being represented in a more user friendly way.

Data sets

There are a number of different data types used in this work. Our primary data set is composed of a large barley pedigree data set for 803 UK Elite cultivars as well as Single Nucleotide Polymorphism (SNP) genotypic data for 750 of these lines across 4,769 genetic markers. In addition, phenotypic data for these lines for 33 Distinctiveness, Uniformity and Stability (DUS) characters [10] across multiple years and sites was used (1980 - present which equates to 601,148 data points). Datasets covering UK wheat (Tritticum spp.) and Asian rice (Oryza sativa) were also used in this work although these are more limited in size. Data are stored in the Germinate 2 database system. [11]. The ability to connect to Germinate was an important design decision as allowing users to access all background information on plant lines that we had available was important.

Pedigree definitions

The nucleus of pedigree data are a series of parent/child relationships defined as encoded strings (see ‘Pedigree formats’ subsection) [8, 9]. Data was atomised into simple parent/child definitions which were used to dynamically reconstruct the pedigree. In addition there may also be information identifying whether the parent was male or female and the type of genetic cross performed. Something unique in plant breeding is where a plant can be both male and female parents in the same cross.

Complications may arise from either older pedigree data which is error prone and may be difficult to verify without expert guidance and from the re-use of names to describe varieties creating false relationship joins. It is not uncommon for a breeder’s favourite name to be used multiple times until a line is adequately different, and has sufficient performance to be accepted for wider distribution into the UK recommended list programme.

Genotypic data

The genotypic data set for our study is based on a set of SNP markers which are mapped to known chromosome positions in the barley genome. Each plant line within the test set has been genotyped for a set of 7,000 of these markers.

A given plant variety will have an allele call for each of a series of loci represented as a pair of nucleotide bases e.g. AA, GG (which are homozygous) or AG (which are heterozygous), for a locus. Due to the inbred nature of our barley germplasm there are low levels (less than 0.5%) of residual heterozygosity present.

Phenotypic data

The phenotypic data in our study has been either collected in field experiments or by molecular testing. Though many of the agriculturally important traits are controlled by many genes of small effect (quantitative traits) for simplicity we concentrated on traits under simple genetic control. Examples of such traits include DUS characteristics which are used in the varietal registration and seed certification process and allele data on disease resistance genes such as Mlo and Mla.

Table-based approaches

Table-based visualization tools such as Flapjack [14] address some of the problems associated with visualizing large datasets and are optimized for efficient sorting and querying of genotypic and phenotypic data, but currently lack the ability to display data on a pedigree-based scaffold.

While other tools such as PedStats [15] offer statistical validation of users’ pedigree data without visualization of the actual pedigree structure, it is difficult if not impossible to conceptualize pedigree structure for complex data sets without some visual representation.

Matrix-based visualizations to represent pedigrees use the intersection of the x and y edge to define relationships. Matrix-based visualizations have advantages over node-link or graph-centred layout approaches including the ability to create compact graph representations and the ability to remove edge overlapping. However, tests generating matrix visualizations using our pedigree data have shown that the data density is so low the resulting representations are not particularly insightful. The ability to easily track flow and identify paths is also removed.

Tools such as GeneaQuilts [16], offer a new visualization technique suitable for use with thousands of individuals but offer limited scope for addition of complex genotypic and phenotypic data and discussions with our users showed that they found it difficult to easily interpret such representations.

Finally, tools such as VIPER [17] offer novel pedigree visualization and genotypic error checking capabilities. VIPER is essentially a stack of nested table representations of generations where rows represent sires, dams or children and columns represent individuals which can span multiple columns where they are parents. VIPER’s primary use is in identification of genotyping problems in farmed animals and would be unsuitable for visualizing the complex crossing relationships that exist between crops where selfing is not uncommon. VIPER requires both separate male and female parents which is the norm in any applications handling animal or human data, but not always the case in plant breeding.

Graph-based

Unlike trees, graphs allow for the precise modelling of the complexity of a plant breeding programme. Techniques such as node link diagrams have long been used as a way of representing graph-based data and recent work has examined how effective the node-link model performs representing graph data when compared to matrix-based visualizations [18]. Work carried out by Purchase [19, 20] and Bennett [21] also indicated that while graph layout played an important part in a user’s understanding, it was not the major focus; this focus perhaps being the use of other aesthetics relating to node colour and shape.

Most of the current tools have been developed for human pedigrees where consanguineous mating events are negligible. This is not the case in plant and animal breeding which cannot be properly modelled using tools that use node-link or tree hierarchies such as Pedfiddler and Madeline [22].

Cranefoot [23] reports the use of mathematical graph structures to deal with between-relative mating but the approach is limited in its current form in the amount of information that can be attached to a node. Finally, HaploPainter [24] allows the drawing of genetic haplotypes, but suffers from being restricted in the number of individuals it is able to display.

A commonly used two-dimensional pedigree visualization tool is Peditree [13] which offers a tree-based view of data in a pedigree but this is not suited to our requirements as plant pedigrees are not trees (inbreeding and the use of older lines in more modern crosses prevents us from treating them as such). Other tools such as the Pedigree Visualizer by Wong [25] offer new layout algorithms. Wong suggests introducing duplicate “alias” lines in representations with multiple matings from the same individuals, phenomena that are commonplace in plant data. PyPedal [26] not only offers rudimentary graph drawing tools, restricted to changing node shape to represent male and females, but also error checking algorithms to try and identify potential pedigree errors where appropriate genotypic data exists.

Visualization techniques such as sunbursts [27] which are space filling versions of a node-link diagram have the advantage that a node’s position in a hierarchy is maintained. Additionally, Fan Charts [28] and H-trees [29] have also been described as a means for recounting human genealogy; these techniques however assume no inbreeding (they are trees and not graphs) and thus rule themselves out for use with plant pedigrees.

While the main problems with these additional techniques are that they are not appropriate for observing a pedigree in its entirety (indeed the complexity of the data may rule many of them out), they may be useful when trying to visualize a sub-section of data such as a sub-pedigree for specific lines.

Layout algorithms

Plant pedigrees often form what we describe as a pedigree net, whereby there is structure to the graph but it’s not as simple as traditional top-down pedigree representation that is seen in humans and to a lesser extent in farmed animals (Figure 2).This abstract representation does include a time component in the form of generations, but due to the viability of seed, and the existence of varieties and landraces that may be many hundreds of years old, there is the potential to use these older varieties in modern crosses. This situation leads to nodes at the top of the graph having edges connecting to nodes at the bottom - this is not common in animals and would be extremely unlikely in humans. The existence of a time component means that the use of a layout algorithm that preserves topology (top-down generations) is nonetheless important as most (but not all) crossing will be between newer varieties. Because of this, layout methodologies such as force-directed algorithms (Figure 3B) would not offer the ability for us to arrange our pedigree based on time. Force directed layouts are not well suited to our requirements. The lack of a visually identifiable pedigree structure is strikingly apparent.

The problem of very large pedigrees in humans has been identified and solutions proposed in tools such as PViN [30] which looks at windows on large datasets but only offers pedigree drawing with no scope for addition of other information onto the visualization. In addition, its traditional human family tree output is not the most efficient use of space for plant pedigrees which form a more dense net due to the nature of reproduction which is not seen in humans or animals (Figure 2A)

Although there are problems associated with 2D node-link layouts such as a lack of horizontal space and problems with crossing of edges [31] they are still well suited to displaying data of this type. 3D tools also have their problems, including visual occlusion and that they tend to visualise high-level features and not specifics, so while some trends are easy to spot, the actual detail is hidden from the user. From this point of view they are limited in use for our purposes and offer no advantages over their 2D counterparts. Notable examples of such tools are Walrus [32] and Celestial3D [31] but their success lies in alternate problem domains.

Discussion

It is clear that these techniques and tools contain many features that are useful, but none meet the exact requirements (including data abstraction) of our problem to be able to overlay genotypic and phenotypic data onto a complex pedigree structure.

There is a need for the development of tools that are tailored for the unique needs of plant breeding with the ability to explore pedigree structure, and paint additional genotypic and phenotypic data on top, to allow breeders to make informed decisions and visualize the way in which alleles for agriculturally important traits are transmitted through previous and subsequent generations. Such tools do not currently exist.

Through the examination of methodologies to display pedigree data we suggest that the best method to visualize plant pedigree data is a layered layout (Sugiyama-style) based approach (Figures 2A and 3A). Not only does this allow us to accurately map the exact specifics of how breeding programmes run (including inbreeding) but also provides a well-established framework onto which a visualization can be built. The use of graphs as our data structure means that features such as standard graph-traversal algorithms can be used to bring greater functionality to our pedigree structure in locating ancestors and descendants and as a logical framework which can be used to look for problems with underlying datasets. The layered layout representation also brings a coherent structure to sparse relationships and generations and topological layout are clearer compared to matrix style layouts. This is not the case with animal (Figure 2B) and human pedigrees whose top-down fan type shape is not well suited to a layered layout as they quickly become very large, consuming large volumes of horizontal space [17].

Tools that allow exploration of data to try and bring a greater understanding of complex relationships between individuals should bring greater insight into how plant breeding programmes operate at the genetic level and how to bring maximum potential benefit from them. The ability to detect patterns and associations (or even anomalies) within these datasets such as; the identification of problems with inheritance of alleles, the identification of lines from which additional information would allow inference of data on large parts of the pedigree, simple typos and errors, or looking for lines which are similar to unknown lines, will lead to increased depth of domain knowledge for plant breeders and geneticists.

Paper-based visualization

We wanted to test if our use of a DAG based data structure and layered layout approach would work with our barley pedigree data and would be accepted by our users. In order to do this a paper-based layout was implemented, overlaying basic character data on to the graph nodes represented by colour and sizing nodes based on the number of times they had been used in crosses in our data. In this prototype (which was implemented in Perl and the Graphviz dot library) our pedigree was modelled as graph nodes to represent plant lines and edges to show mating/parentage. While GraphViz has been used before in pedigree drawing [33], examples focus on a small number of individuals.While initially this prototype was run by users as a command-line computer program which generated images based on input _les and generated an image which could be viewed on their computer monitors it was decided that printing this static representation (2.5 m × 1 m see Figure 4) would allow domain experts to better interact with the visualization. We overlaid, by means of colouring nodes, the winter/spring ecotype category on this dataset as (along with the 2-row/6-row ecotype) it is the most commonly used physiological means of differentiating barley varieties, and one that all of our test users were familiar with. This tool was also implemented as a web-service which allowed us to include static (but dynamically generated) pedigree representations within our internal barley information portal.

Feedback on paper-based prototype

Through observation and talking to twelve geneticists and plant breeders while they interacted with our wall-mounted visualization it was clear that there were a number of issues associated with this implementation. Firstly, it was almost impossible to trace edges between nodes when the data was dense (even at a large output size) so we found ourselves falling back on examining text based records to confirm lineage. Secondly, it is incredibly challenging to quickly locate specific plant lines with this density of data. Commonly used lines are immediately identifiable due to the use of size to represent the number of uses in breeding crosses but these are not always what users are most interested in. Users used these larger nodes as reference points, almost as if they were notable points on a map [34, 35] and attempts at using slightly different layouts or orientations were not well received.

It was also clear that users were beginning to quickly spot pedigree problems. These problems related to the parentage of lines and in some cases the assignation of ecotype. These types of errors would be extremely difficult for a user without extensive experience to pick up on and this has not only shown that it is an effective technique for visualization but also an effective way of identifying errors with underlying datasets.

Users liked this representation of large pedigrees. Not only is it visually attractive, but geneticists were using it to identify problems with the underlying pedigree and phenotypic data in a way that is more interactive, social, and tactile compared to the examination of records.

When presented with our results, plant breeders told us that it gave them an overview of their data that was not currently available to them; indeed these representations uncovered interesting information relating to the relative frequency of use of particular \key” lines in the UK Elite Barley germplasm that would have been difficult to see from textual records in the format seen in ‘Pedigree formats’ subsection, such records have not been collated like this before. Missing data was also easily spotted thus allowing us to update our underlying datasets.

Problems do however exist, especially in the inability to search for particular plant varieties and tracing of edges to establish lineage. In order to try and address these, it was quickly realised that we would need to move towards the development of a more interactive software tool - Helium - named after the balloon type appearance of our static prototype.

General background profiling

The 16 expert users that undertook this study break down as follows; 5 bioinformaticians, 10 plant geneticists and breeders and 1 statistician. Out of the users 94% were educated to PhD/MSc level and the average length of time working in their areas was 17 years. The minimum experience was 1 year, maximum 36 years giving a median length of experience of 13.5 years.

While all users were familiar with pedigree data, 69% used it on a day-to-day basis as part of their research and 38% regularly used alternative tools.

It should be noted that through verbal feedback it was established that the researchers who were using pedigree data were using paper records and spreadsheets to curate and maintain pedigree data used in their work and not a specific pedigree tool.

Main user interaction study

Post-study questionnaires (attitudinal and open ended)

After carrying out our main interaction study the users were asked to fill in a series of questions that asked them to compare Helium to pedigree tools, or methods of handling pedigree data that they are familiar with using, and to get feedback on what they found easy and difficult to understand or perform with Helium. These results are presented in Table 2.

Test results discussion

The most common responses have been detailed by dividing them into features users liked and disliked. These were obtained from feedback gained in our post-study questionnaire.

Overview and data selection panel

This panel (Figure 6A) also includes selection mechanisms for choosing ordinal and nominal categorical phenotypic classes as well as tools for visualizing genetic similarity data (Figure 7). Users can use the overview to navigate to a particular region within the main visualization window if required.Interactive sliders allow users, in the case of similarity data, to set a percentage similarity value and in real time highlight lines which match the search criteria (Figure 7). In this way it is possible to see lines which should not be closely related appearing on the peripheries of our visualization as the slider is moved, which may indicate problems with pedigree definition or genotyping. Histograms have also been included, where appropriate, to show data distribution which can be an aid in the identification of problem markers. While the number of markers that have this problem is limited, it is nonetheless important to address.

Other features included in this panel are the ability to select more than one phenotype then recolour nodes based on the merged phenotype classes. While originally it had been intended to show each phenotype as a different section on a node it was decided, through speaking to users, that they would be interested in finding exact combinations and so it was decided to go with the single node colour to reduce clutter and keep the visualization clearer. There are however problems as the number of colours that may have to be used can be around 20. Such a high number has been shown to be ineffectual at differentiating between classes [40, 44, 45].

Main visualization panel

The main visualization window (Figure 6B) was modified in a number of ways from our prototype. Firstly, we have moved away from bundled orthogonal edge routing (Figure 5) which will make the tracing of lineage easier. Slightly modified colour palettes were used to account for the situation where there are more than eight categorical classes. The new colour palette will help with the problem our testing showed where adjacent classes were too similar in colour for users to accurately distinguish. In Table 1 the incorrect responses to “Identifying Children” were high at 43.75%. In order to address this visual prompts when hovering over a node were added which display the number of ingoing and outgoing edges from a node and the names of the line’s progeny (Figure 6B). This makes the number of progeny immediately obvious, which will help prevent some of the problems seen in testing. When a user selects a node the edges connecting nodes of interest are made more prominent by both removing edges which are not associated with the selected node, its ancestors, or successor, and by darkening the edges which are left. Hovering over a graph edge will show the names of the two nodes that it connects, in this way with long edges, while using the main visualization window, it is easier to track their origin and destination.

Local view panel

Our testing also showed that while users reported they found it easy to identify lineage there were some issues. These problems could be addressed by including a “local” implementation of our graph showing only the line of interest and its lineage (Figure 6C). This would be shown when a user selects a node in our visualization. This view was implemented below the main visualization window. The local view can be panned and zoomed in the same way as the main visualization window. Within the local view the user has control of how many generations, forwards and backwards, they want to go. This addresses the problems highlighted in Table 1 where there were 50% and 62.5% of users incorrectly answering the “Complex Grandparent Tracking” and “Great-Grandparent Tracking” questions respectively. With appropriate selection of generation level, grandparents, or indeed any other generation, are now immediately obvious in the simplified pedigree. Additionally, the ability to layout the graph using a number of edge routing algorithms was added. Any changes made to the main pedigree visualization are propagated to the local view. While the local view includes another copy of a portion of the main visualization, it will increase the accuracy of tracing lineage when unnecessary lines are removed and edges between nodes shortened, thus addressing the problems highlighted in testing and reducing the need to “chase edges”.

Detail panel

The details panel (Figure 6D) shows information about either the current selected phenotype(s) or information from Germinate about specific selected plant lines. This example shows the distribution of the DUS character “Anthocyanin Colour”. The histogram has been coloured in the same way as the phenotype classes in the main visualization window.

The details panel also houses a search functionality which allows searching for lines with usual search features such as wild-card matching and an option which we have called the “follow me” mode which jumps to a search hit, selects it and subsequently updates the detail panel and main visualization window.

During discussions with users it was also apparent that the ability to export line names would be a useful feature to allow scientists to make up lists for sending samples off for genotyping based on phenotypic or genotypic characteristics so the ability to allow users to export lists has been implemented. Users can select nodes then add them to an export list which can be saved to a text file.

Finally, a user history panel has been included which records the lines and phenotypes that have been selected over a session so that if required, users can go back and see what they had been doing previously. This is important as with large quantities of data it is easy for users to forget what they have been doing over time.

Examples of the layout and features offered by Helium can be seen in Additional file 1.

Discussion

An interesting outcome of the development of Helium is trying to quantify if this tool actually make a user's decision making better and does the software influence users into making more informed decisions about their data. One of the outcomes from our testing was to assure ourselves that the decisions that had been made around the design of the tool were actually good foundations that our target users can build knowledge on and to that end we seem to have made an impact. While we have used standard approaches to the visualization tool we have developed we have applied it directly to a specific domain, and tailored our application appropriately.

While users requested as much information as possible in the interface we need to be careful that we only include necessary information and do not turn Helium into a tool that presents so much unnecessary information to users it in itself becomes unusable or difficult to comprehend; we need to avoid a situation where we overload users with information. While this may seem like a problem that scientists would love to have it could have detrimental effects; do we need to actually present raw data or are overviews enough? Would a user’s understanding be affected by what we present them with?

Users have told us that the overlaying of data onto the pedigree structure has in some ways more impact than showing the division of data in a bar chart or as a table. Having areas of colour in your face brings insight both into the location of clusters of similar data and visual impact of nodes changing from one colour to another, it brings the representation of data to life and in logical an understandable ways.

Examples of the sorts of things that users wanted to be able to do with our tool include a) given genotype data for a line identify possible matches and b) basic error checking based on genotypic or phenotypic data. These are detailed below.

Given genotype data for a line identify possible matches

Helium will take a string of genotypic data and identify possible matches from data held in our Germinate database then display the possible hits on the pedigree display. This is useful as it is not uncommon for errors to be introduced through mislabelling or handling errors in the lab when genetic material is sent for genotyping. Using the pedigree framework may give users other ways of trying to identify what unknown or problem lines are, or they may point geneticists and breeders in the right direction as to their source, if for example two similar lines are mislabelled we may be able to deduce the correct naming through examination of pedigree records. Further investigation would be required to correctly identify the correct source of this germplasm as there is a possibility either it, or the genotyping is wrong. These types of error are not uncommon.

Basic error checking based on genotypic or phenotypic data

We can use the interface to look for potential errors with a given line. We know that the alleles of a line must be from either parent, so we can use this in basic error checking. For example, if two lines have been genotyped for allele A at given locus but the progeny has allele B then we know there is a problem. Additionally, we can expand this type of search to look at multiple loci within a dataset. Taking this a step further we can use genotypic data to highlight potential parents of a line and if one parent is known, make a guess at possible candidates for the second parent.