BACKGROUND
genotyped pedigree data underpins many forms of genetic analyses that are performed by breeders and biologists to identify, map and select economically or biologically important genes or heritable traits.
for techniques such as linkage analysis, genotype scores for polymorphic markers distributed across the genome are analysed in the context of the pedigree structure and mendelian laws of inheritance .
the statistical algorithms applied in such genetic analyses are critically sensitive to any errors in the data that exhibit as 'inheritance inconsistencies', i.e.
patterns of inheritance for alleles that are not consistent with the asserted parent-child relationships recorded in the pedigree.
any such errors must be identified and cleansed from the data before downstream analyses.
error cleansing constitutes a complex, labour-intensive expert task, particularly given the scale of modern genotyping studies, where populations of several thousand animals may be genotyped for tens of thousands of markers.
pedigree and genotype data
roslin bioinformatics provides the web-based resspecies data system for recording and analysing animal pedigree-genotype data  <cit> .
the experimental pedigrees available in resspecies, particularly those from the five major farmed species  exemplify the variety in structure and scale of study populations with which we deal and these pedigrees have been used  for the generation of test datasets employed in the evaluation.
resspecies pedigrees range in size from  <dig> to  <dig> individuals, but more typical sizes range from  <dig> to  <dig>  the structure of each particular pedigree reflects the design of the breeding experiment, e.g.
inbreeding versus outbreeding, with the number of generations varying between  <dig> and  <dig>  similarly the number of founder animals in each pedigree varies between  <dig> and 1200; founders may be introduced throughout a breeding program, not only in 'generation 0', and the proportion of founders used in a study varies greatly from  <dig> % to 55%.
the proportion of males recorded in a pedigree ranges from  <dig> % to 94%, whilst the proportion of females varies between  <dig> and 98%.
some pedigrees, particularly fowl studies, may not record the sex of animals which are not kept for breeding, resulting in up to 98% of individuals unsexed, however, more typically only a few percent of animals are unsexed.
sexing becomes a particular issue when identifying the inheritance pattern of sex-linked markers.
the shape of pedigrees  also varies, with some experiments using very few individuals in earlier generations, but generating large numbers in the final generations.
the choice of mate selection is also study dependant, with some studies crossing a single individual  with multiple partners, even across generations.
this great variety in pedigree structure differs from typical human pedigrees, and the imbalances, multiple and cross generational pairings, and in some cases the size of families, present additional challenges for a successful pedigree visualisation which would allow the user to trace inheritance patterns from ancestors to descendants and siblings.
inheritance studies use genotypes scored for any number of detectable genetic markers distributed across the genome of the study organism.
a specific marker genotype is scored for each individual in the pedigree by detecting the  allele pair.
this allows the inheritance pattern of alleles to be traced through the pedigree structure.
current large scale genotype studies are based on snp-chip technology, i.e.
the identification of bi-allelic single nucleotide polymorphisms, allowing genotypes to be concisely represented by pairing single nucleotide characters  or '-' for null sex-linked alleles.
earlier genotype studies used a variety of less automated techniques to assay fewer, often multi-allelic genetic markers .
the potential scale of snp-chip datasets reflects the availability of tens or even hundreds of thousands of snp markers for study organisms.
real experimental datasets commonly contain missing genotype data.
whilst this may occur sporadically due to lost samples or failed assays, missing data frequently reflects a systematic decision not to analyse samples for some individuals or generations which may be considered uninformative.
the resspecies inheritance-checking algorithm infers inherited genotypes for missing data points using the principles of mendelian inheritance, which may result in either completely resolved or partially resolved  genotypes.
more complex partial inferences are possible for multi-allelic markers  but for simplicity this study only uses bi-allelic markers.
sex-linked inheritance patterns are observed for markers located on the sex chromosomes, where the heterogametic sex has a single allele for these loci.
if sex-linkage is known in advance a null allele may be recorded in a dataset , otherwise the genotype would typically be scored erroneously as homozygous , with the inheritance pattern of an unrecognized sex-linked marker exhibiting a distinctive error pattern .
viper software
we have previously described genotypechecker, a simplistic prototype tool for assisting data cleansing  <cit>  that combines the resspecies genetic consistency-checking algorithm with a tabular display of genotypes for individuals within a pedigree.
the tool highlights inconsistent genotypes and allows the interactive removal of identified erroneous data points.
the ability to explore inheritance patterns in a pedigree context is essential for pinpointing the exact data points in error, particularly in the case of incomplete datasets where the inheritance algorithm will infer logically consistent  data from the existing data points and thus 'move' reported errors down to the lowest possible point in the pedigree.
critically, however, the tabular display format does not allow the user to easily explore patterns of errors in the context of the family structures in the pedigree 'tree'.
to rectify this situation we have been developing viper - visual pedigree explorer - http://www.viper-project.org.uk/.
the priority of any candidate visualisation to solve our particular problem is to show information such as marker data or error reporting within the context of a pedigree structure.
a review of existing techniques for pedigree visualisation showed that current approaches fall short in either one of two categories: scalability and a lack of multivariate data display.
pedigree viewers emanating from a biology background such as pedidraw  <cit>  or peditree  <cit>  acknowledge and support the integration of biological data on top of a pedigree, but do not scale well, partly because they stick to layout and representation recommendations developed for displaying pedigree data by the biology community  <cit> .
often they are designed not for screen rendering but for outputting hard copy on high definition printers.
unbound by such representation guidelines, approaches to tackle pedigree drawing in the information visualisation field have focused on visual scalability through more compact layouts such as pvin and pedvis  <cit> , and through adding interactive features that handle large data sets with operations such as filtering, guided navigating and dynamic zooming like geneaquilts  <cit> .
however these focus on human genealogies and thus do not accommodate or consider displaying the type of data associated with animal pedigrees such as genotype data.
another specific problem that we recognised was that many pedigree visualisations are set up to show the global structure of pedigrees at the expense of quickly comparing immediate relations e.g.in most of these visualisations to connect between a parent and child involves tracing a link from one part of the screen to another, often through a sea of other links.
essentially, we could not find an existing solution that had both the ability to show a pedigree beyond a minimal size, and the ability to show information attached to the individuals within that pedigree.
following a number of design iterations  <cit>  which progressed from initial naive node-link representations, through matrix representations, we finally arrived at the pedigree view seen in figure  <dig>  which we term the 'sandwich view'.
the parent-child relationships between every two consecutive generations is viewed as a sandwich, the male parents  at the top, the female parents  at the bottom, with the children sandwiched in between.
the children are laid out such they lie directly above their female parent and directly below their male parent, making parental relationships much easier to follow on a generation by generation basis.
this representation provides the family-centric visualisation necessary to view and assess errors in the context of a pedigree structure.
within the viper display, a simple discrete four-level colour-coding is used to indicate the proportion of erroneous markers associated with an individual, from white  through light, mid and heavy colour shading for increasing error rates.
reported inheritance inconsistencies may be categorised into three types: genotypes where no allele is inherited from the sire, where no allele is inherited from the dam, or where a novel, non-parental allele is detected.
the three categories of error are represented in the offspring row as sub-parts of a hexagonal glyph, with the tips acting as stylised arrows oriented either up or down.
the tips point to the sire and dam rows, colour-coded as described for the number of sire/dam errors for that individual or group across the marker set, and the 'mid-stripe' of the hexagon is similarly coloured for the number of novel allele errors.
a single genotype may exhibit any or all of these three error categories, and figure  <dig> displays the six different possible combinations of these errors .
in the sire and dam rows, the combined error count  for all markers is used to colour the representation of an individual as seen in figure  <dig>
the user can toggle between an aggregated family overview , or the display of all individuals separately within each family or 'mating pair', as shown in figure  <dig>  the sandwich views can be ordered from left to right by a selection of metrics, including name, partner count, number of ratio of errors in the offspring groups, and number of errors from offspring to either sire or dam.
the offspring sets can be sorted internally by another group of metrics, again including error-related information.
the initial viper display looked promising and revealed information about the distribution of errors in the pedigree structure not seen in resspecies.
additionally, it also allowed child-parent comparisons that were intractable in other pedigree visualisation tools.
however, it still needed much in the way of development in terms of interactivity and specialised biological data display to make it useful for real users with the full range of real data they need to investigate.
we therefore embarked on a two stage evaluation of the software, which forms the structure of the rest of this paper.
firstly, an initial evaluation was performed on a small number of test datasets and used to identify and implement any critical features or improvements required for a subsequent functionality evaluation.
this second, in-depth evaluation performed by expert biologists tested the effectiveness of the visualisation in helping to identify a variety of representative error states deliberately introduced into simulated pedigree and genotype datasets.
we then give an insight into how the size of datasets has scaled since the beginning of the project, along with a description of a complementary node-link visualisation.
we then conclude with a discussion of the results and further work.
methods
the evaluation was performed in two stages.
the first stage validated the ability of viper to handle and display the types of datasets to be used in the second stage - a utility evaluation  <cit>  in which we tested the visualisation's ability to faithfully represent pedigree genotype datasets of the necessary scale, and to cope with and indicate errors and omissions within them.
this is distinct from usability or efficiency testing, as the primary aim was to ensure the necessary functionality of the system is present.
this allowed the identification of critical features for implementation to support data browsing and error localisation, necessary to support the data and events we wished to explore in the subsequent second evaluation.
the second evaluation stage was performed after this extra identified implementation was delivered, and involved testing the visualisation's capability for displaying differing error types commonly found in real-world pedigree genotype datasets.
each separate 'error type' under test was evaluated by creating an appropriate permuted pedigree and genotype data file pair, and then browsing the data visualized in viper to verify whether the pattern of inheritance inconsistencies revealed could be used to deduce the underlying, causative error.
simulated datasets were used in order that each error type could be evaluated independently, without the confounding effect of multiple overlapping and interfering errors as found in real datasets.
the two stages of the evaluation were performed by two geneticists from roslin with extensive experience in analysing and error-cleaning genotyped pedigree datasets.
such an evaluation might not have the numbers of other usability or utility inspection methods, but the expertise of the domain experts in helping assess the visualisation is the overriding factor here  <cit> , any assessment by novices to the domain would be much less informative.
one geneticist created and anonymised the datasets, and monitored the other exploring each dataset in one-to-one sessions lasting an hour.
the ease and accuracy with which errors were identified was qualitatively scored, and any issues with the interface or comments about desirable improvements were recorded.
these observations formed the basis for deciding which additional information and functionality is essential to present to the user, what modifications might be beneficial but not essential, and any general usability and navigation issues.
the approach has a similarity with expert reviews  <cit>  but the experts here are domain rather than visualisation experts, as they are the only ones who can truthfully assess whether the necessary functionality is present and correct.
the majority of the evaluations used a moderately-sized, anonymized chicken pedigree comprising  <dig> individuals, the details of which are listed in table  <dig>
alternately pedigrees with controlled numbers of individuals, generations and families per generation were generated de novo using a parameterizable script.
dummy genotype data files for pedigrees were similarly created using a suite of creation and permutation scripts, and desired errors were introduced into either the pedigree or genotype files manually or with further editing scripts.
the simulated genotype datasets reflect the data types found in current large scale studies based on bi-allelic snps, including sex-linked markers.
a suite of scripts was used to create and then systematically corrupt synthetic genotype data, and to partially erase data from the f <dig> generation to simulate incomplete data coverage.
initially consistent genotype data was generated using seven different randomly seeded markers.
each marker had bi-allelic snp alleles c and t, with  <dig> different c:t heterozygosity ratios ,  <dig> mammalian style male sex-linked pair , and  <dig> female  sex-linked pair .
consistent datasets were generated for  <dig>   <dig> and  <dig> markers by seeding with each marker one, ten or fifty times.
the  <dig> marker genotype dataset proved to be adequate for revealing the expected error pattern for the majority of error types in the data overview.
RESULTS
first stage evaluation
we initially validated viper's ability to handle and display representative datasets, with regards to four particular aspects of the data in question:
<dig>  the ability to handle pedigrees of a range of sizes.
<dig>  the effect of incomplete data which requires inferring over the missing data.
<dig>  the ability to report systematic errors in sex-linked markers were measured.
<dig>  the ability to restrict the display to the details of a single marker.
this stage of evaluation was spread over three separate hour-long periods, due to the time constraints of the geneticists involved.
this did however give an opportunity to correct many minor interface issues they found before they next investigated the prototype, effectively turning the evaluation into a mini rite-style process  <cit> , of which the who two-stage evaluation process could be considered a larger example.
these interface issues included the wish for individual's representations within a generation to be of the same size; previously individuals filled as much space as they could expand into, but the geneticists thought this was giving visual prominence to certain groups, especially families with only a few individuals, leading them to query if they were somehow more important.
also, labelling of sires and dams was switched to display vertically if the space for their display was taller than wide, with a draggable row header allowing the vertical size for such labels to be adjusted .
size and structure of pedigrees
a wide range of animal pedigrees extracted from the resspecies data source were tested to confirm the layout and display capabilities of viper over a realistic range of experimental pedigrees size and structures.
in addition, in order to test the limits of display resolution and usability a number of artificial pedigrees were created as described in the methods section with controlled numbers of total individuals, generations and families per generation, as listed in table  <dig>
pedigrees were displayed using viper on a standard 1280× <dig> monitor, and the limits of usable resolution determined, comparing the 'family' with individual offspring views.
in summary, it was demonstrated that the visualisation can cope with any realistic number of generations and over  <dig> families per generation at the overview level, although the labelling of parent names becomes problematic with over  <dig> families.
however, available space constrains the ability to distinguish the properties of individual offspring where there are a large number of families in a generation  or a large number of offspring in a family.
none of the experimental pedigrees available in resspecies exceed these thresholds.
display limitations could be ameliorated with higher specification monitors or by expanding across multiple monitors, but in the authors' experience the target user group for viper, e.g.
animal breeders, often lack high specification desktop hardware and monitors.
it is understood that in future pedigree breeding experiments the number of animals is not expected to get any larger than the figures already seen in resspecies or the examples quoted in table  <dig>  this is because breeding and looking after animals is a resource-thirsty operation requiring real estate and labour to achieve.
even within experiments it is not the case that every animal within a generation goes on to breed, thus avoiding an exponential increase in the number of animals per generation that we would otherwise need to accommodate in the display.
the exponential expansion in pedigree genotype data sets will be in the number of markers annotated in the data set as sequencing technology continues to improve.
the authors have recently seen data sets containing in the order of  <dig>  markers, and this is now not considered large.
the effect of incomplete data and genotype inference
as described above, in addition to reporting genotypes that are inconsistent with mendelian transmission, the resspecies inheritance algorithm infers missing genotype data by recursively applying allele transmission that must necessarily be true from known data points.
as a consequence of the algorithm traversing the pedigree from founders  down through descendants , errors are reported as low down the pedigree as possible, and particularly in the context of missing data and genotype inference, errors can be reported in individuals  removed from the actual source error.
the obfuscating effect of this became apparent when synthetic datasets were examined, where a proportion of genotypes were erased from the intermediate generation  individuals, see figure  <dig>  the 'non-presence' of such missing data would have to be recognised in the visualisation and suitably communicated to users  <cit> .
sex-linked markers
a common systematic error found in real datasets arises when unrecognized sex-linked markers are analysed.
typically this arises in mammals when the genotype assay scores males as homozygous for an allele, whereas in fact they should be heterozygous for the 'y-null'  allele; the effect is opposite in most birds with heterozygous 'w-null' females unrecognized.
as can be seen in figure  <dig> this causes a gross systematic error to be reported, immediately apparent as a preponderance of 'nil from sire' errors .
however the sex segregation of this effect was not readily apparent because the sex of offspring was not represented in the sandwich view.
to readily identify such errors, a method for distinguishing the gender of offspring in the display would have to be developed.
single marker view
the geneticists had mentioned the ability to select a single marker and view just its data would be important, and the previous subtleties arising from the sex-linked markers on top of the fact that errors and incomplete data differed from marker to marker reinforced their view.
functionality for displaying the data associated with just a single marker at a time would need to be developed, along with a mechanism for choosing which marker to display.
given that there could be thousands of markers within a pedigree genotype meant this selection would have to be guided by properties of the marker as searching blindly or exhaustively to find markers of interest would be both prohibitive and extremely frustrating.
improvements to viper
the initial evaluation of viper thus identified several major features which were required prior to performing a full functional evaluation.
these improvements are illustrated in the marker summary shown in figure  <dig> and in the single marker detail view shown in figure  <dig>
in order to support the exploration of individuals in any selected large family a 'detail view' window was implemented to complement the overview of the entire pedigree  <dig>  - one of the standard practices for solving such problems in information visualisation  <cit> .
this 'detail view' can readily accommodate families with hundreds of individuals on a standard monitor, overcoming the resolution constraints identified above.
secondly, to expose the degree of genetic inference in the data  a second colour map contrasting with the error colouring was implemented, showing the degree of missing data across the pedigree via the intensity of border colour on an individual or family.
as the viper display already has space allotted for each individual and family in the pedigree then adding such extra indicators for missing genotype information is not difficult, it would be a different case if there was missing data in the pedigree itself.
clashes between the dual colour highlighting used in the sandwich view to report inference and error rate are limited, because the inheritance algorithm does not infer 'erroneous' genotypes from incomplete data.
control of the colour schemes was provided by adding controls that allow the user to turn off or change the colour used for both the error reporting and the incompleteness maps, and also to choose which contrasting colour is used for user-selection highlighting.
thirdly, in order to expose the sex of individuals in a family, and hence assist the identification of sex-linked inheritance problems, a further level of colouring was rejected as it would reduce the pre-attentive 'pop-out'  <cit>  that the coloured error display currently enjoyed.
instead the  partitioning of offspring by sex was implemented, spatially separating the male and female offspring into different rows - in effect giving us a 'club sandwich' view.
in fact a third, intervening, row was required to accommodate individuals of undetermined sex, as many pedigree datasets include non-breeding individuals that have not been sexed .
in essence, we are using another visual attribute, spatial positioning, to communicate low-count categorical data attributes of the offspring, rather than overload the colour channel.
standard pedigree layouts use shape to represent gender in pedigree diagrams  <cit>  but spatial positioning is a more powerful communicator, especially when we wish to split a set of objects into groups.
in addition to partitioning offspring by gender, the same visualisation mechanism is used to allow segregation of family offspring by other characteristics, such as possession of offspring.
this sorting/partitioning mechanism allows the user to explore alternate aspects of inheritance patterns, and will have additional uses once we implement data-cleaning functions that allow modification of various properties of an individual and genotype data.
finally, the initial viper prototype provided only an 'overview' of summary information about inheritance errors averaged across all markers.
this summary view adequately exposes many types of systematic errors resulting from wrong pedigree information or sample misidentification, but it does not allow the discrimination of more sporadic errors, nor could the user explore the actual reported genotypes for a given marker.
this deficiency was addressed by adding a number of related components to the prototype.
firstly, a sortable 'marker table' was added to allow the user to select individual marker genotype data to explore.
markers can be sorted according to their name, counts of reported error types  and extent of data incompleteness.
a second complementary table for the individuals in the pedigree was also added, with an additional column for gender type.
selection of a named individual highlights it both in the table and the pedigree view, allowing the user to locate individuals of interest.
in reciprocation, individuals highlighted in the pedigree view are cross highlighted in the table view.
the combination of these two marker and individual information tables not only assists navigation of the data, but provides the detailed error information necessary for deep analysis of inheritance errors.
this is augmented by a pop-up tooltip that displays on mouse-over of individuals  within the sandwich view and details the same error information for individuals as reported in the tables.
the marker and individual tables use the same colouring schemes for errors and incomplete data as the sandwich view.
in this way the sandwich view and tables now form an example of a coordinated multiple view visualisation  <cit> .
within the marker table, an individual marker could be selected as a 'focal marker', allowing specific genotype information for that marker to be overlaid in the sandwich visualisation - as seen in figure  <dig>  the single marker pedigree display is essentially identical to the overview, but adds the actual or inferred genotype to the labelling of individuals, allowing the user to analyse in detail the inheritance patterns of alleles in the pedigree.
when data is visualised for a single marker , both colouring schemes become binary and mutually exclusive indicators for individual genotypes, as an incomplete data point cannot be marked as an error .
thus we are either indicating the presence of an error at that genotype, or that the recorded data was incomplete or absent for an individual genotype, and consequently any genotype shown has been derived by genetic inference, or thirdly no colouring is applied as the genotype is both present and correct.
in this mode, the individual table also shows only information for the selected marker, thus indicating for all individuals whether or not each category of possible error occurs.
the addition of these and other controls necessitated the removal of the 'sort' and 'display options' from a dedicated pane area in the first prototype to more traditional menu bar locations.
in addition the application now automatically saves a user's layout and colour scheme preferences as default values for the next time the application is run.
with these improvements applied to the viper prototype, the second stage of the evaluation proceeded.
second stage evaluation
the second stage of the evaluation explored the effect of introducing controlled errors into real and artificial pedigree genotype datasets, and whether they would be represented by the visualisation in a form recognisable to a domain expert.
pedigree errors
real datasets frequently contain errors in the asserted pedigree structure, which might be caused by the misidentification of animals, incorrectly assigned paternity or errors in record keeping.
furthermore sample misidentification or contamination can result in apparent pedigree errors.
in order to evaluate whether the viper visualisation adequately exposes the possible kinds of pedigree errors found in real datasets various pedigree disruptions were engineered in the categories given in table  <dig>  where appropriate these permutations were performed in separate generations  and upon both same sex and different sex pairs of individuals.
furthermore, to evaluate the potential effects of inference on the observed inheritance patterns, genotype files were derived with  <dig> or 100% of f <dig> genotypes erased.
all permutations  were readily identified in the sandwich overview apart from no.
<dig>  where inconsistent sex assertions in the pedigree file break the pedigree, causing a fatal error on file loading.
pedigree files drawn from the categories in table  <dig> were explored in viper using the  <dig> marker test genotype dataset  and with the 100%, then 50% then 0% erased f <dig> genotypes.
the ease with which the error types were located and identified was assessed, and the influence of genotype inference  on the inheritance pattern was considered.
the categories listed in table  <dig> were all successfully explored, with the exception of case  <dig>  which did not pass sanity checking by the resspecies algorithm.
permutations with erased genotypes clearly demonstrated the importance highlighting of data incompleteness , as attention is drawn to the possible obfuscating effect of inference over missing data.
as described above  the reported errors are pushed down to f <dig> when  <dig> or 100% genotypes are erased, making diagnosis of the root data error more difficult.
the improved viper prototype draws attention to the lack of genotype data for the wrongly assigned littermates, alerting the user to the possibility that the errors reported in f <dig> may be propagated from the f <dig> generation .
genotype errors
genotyping assays can give rise to systematic or sporadic errors.
unreliable assays may give rise to unusable data with very high error frequencies, however a low rate of sporadic 'wrong calls' cannot be discounted for any assay.
errors in sample or data handling may again be systematic or sporadic, and hence might give rise to inconsistency patterns resembling systematic pedigree errors, or to more random, less tractable patterns.
various types of errors were introduced into hitherto consistent  genotype files, as categorized in table  <dig>  where appropriate, errors were introduced to individuals in different generations , and in order to demonstrate the potential effects of inference on the observed inheritance patterns, alternate data versions created with  <dig> or 100% of the f <dig> genotypes erased.
the permutations and genotype mixings were also done on both same sex and different sex pairs of individuals.
all permutations  apart from no.
<dig> were readily identified in the sandwich overview visualisation.
although offspring can be sorted by litter information, there is as yet no suitable visualisation for litter mates; consequently attention is not drawn to errors restricted to a particular litter.
it was noted that errors in genotype information tended to result in the display of errors between both the children and parents of the affected individuals.
an erroneous genotype in an individual could not be reconciled upwards to one or both of its parents, and in turn that individual's offspring could not reconcile their genotype with the erroneous data in the individual, thus genotype-based errors tended to manifest themselves in two positions.
the exception to this was the scenario in which we swapped the ids of two siblings that shared both parents: in this case both their genotypes could be reconciled upwards as there was no difference in parentage between them, however their offspring reported errors.
example scenarios of introduced genotyping errors can be seen in figure  <dig> where the last column shows the case of full siblings being swapped - here we have highlighted the actual swapped ids of  <dig> and  <dig> showing that they themselves do not report errors upwards, but their children do.
in the pedigree-based scenarios only the relationship between the affected individual and its incorrectly assigned parents were flagged as error.
the individual's offspring were still correctly assigned in the pedigree to the individual.
this finding in turn has consequences for the effect of inferencing data and future masking capabilities.
inferencing  over a wrongly assigned individual in the pedigree will just push the errors down to that individual's children as they cannot reconcile with their grandparents any better than their parent could.
however, inferencing over a bad genotype will often remove the error as the individuals in either direction will reconcile once the bad genotype in between is removed.
in summary, identification of these various systematic id/genotype/parentage swaps proved readily tractable for experienced geneticists using the sandwich pedigree layout.
in particular the ability to select and highlight an individual and its ancestors and descendants allows inheritance patterns to be traced.
further informal evaluation
the viper tool, complete with data masking capabilities, was demonstrated at a meeting of poultry genetic researchers in the uk after the completion of the functional evaluation phase.
we found that they appreciated the importance of cleaning the data, and it was revealing that individual's comments focused on the ability to not just mask data but to "correct" data, e.g.
to automatically find "correct" parents for misplaced individuals.
similarly, feedback from a sole researcher working at a commercial animal breeder showed that they again quickly zeroed in on wanting to be able to suggest reorganisations of the pedigree and not just masking of erroneous information, however they did view the rest of viper's functionality as useful.
this is perhaps evidence of a drawback to relying on just the two experts as we did in the evaluation, or simply in a differing definition of what data cleaning entails i.e.
making the data good enough to run without error vs. making the data as accurate as possible.
though viper itself is not designed to accommodate any further analyses beyond the cleaning of data i.e.
to make it error-free within the constraints of mendelian inheritance laws, this could be an indication that any next stage in tools for pedigree genotype processing would be for the development of a suite of co-operating tools covering many processes, with data cleaning as just one necessary initial step.
large genotype data files
extremely large genotype files are now becoming commonplace in bioinformatics; as mentioned earlier in the paper this has meant a step-up from a few thousand markers to data sets with  <dig>  markers or more in the pedigree genotype domain.
however, as discussed, the viper sandwich view and associated histogram views aggregate marker information across the interface and so such an expansion in data is not detrimental to the visualisation, the breaking point is actually when the amount of data loaded overwhelms the available memory.
the data set shown in figure  <dig> consists of  <dig> animals over nearly  <dig>  markers, making for just less than  <dig> million data points.
currently this results in the host java process taking just short of  <dig> mb of memory.
individual markers, being separable from other markers, are computed in a time independent of the overall marker set size.
when an event affects an individual across all markers then recalculation will take a time proportionate to the marker set size, but for the data set described above this recalculation takes around half a second in total on a  <dig>  ghz pc so is not prohibitive to interaction.
viper is not concerned with any notion of dividing the marker collection into sets based on segregation patterns or linkage, instead treating each marker as an independent entity operating on top of a shared pedigree.
this viewpoint is taken as viper is concerned with cleaning the data set which is then passed downstream for further processing.
at this point other tools can then perform analyses on top of the data to decide relationships between markers.
alongside this development some of the 'pedigrees' supplied are now simply collections of triples; sets of father, mother and child unrelated to other triples.
this does not result in particularly interesting visualisations but viper is still able to display such information.
CONCLUSIONS
the viper prototype has been evaluated for the display, exploration and identification of errors in genotyped pedigree datasets, using a range of synthetic datasets which incorporate a wide variety of pedigree and genotype errors, and introduce degrees of data erasure to mimic data incompleteness.
the first evaluation exposed a number of critical features that were implemented prior to the full functional evaluation: a 'detail view' for large families, the colour map of genotype 'incompleteness', the ability to partition siblings by sex and other properties, the marker and individual data tables, and the single marker view functionality.
the results of the second functional evaluation confirmed the ability to discriminate the vast majority of single error types in pedigree and genotype datasets.
findings from the evaluations can be split up into two categories: what we learnt about viper in particular and what we discovered about the process of testing an application with domain experts in this manner.
for viper in particular, the space-efficient layout of the pedigree population in generational layers, organized by mating pairs  allows realistically large pedigree datasets to be explored, and the ability to toggle between a summary family view and detailed view of individual offspring provides a workable compromise between a simplified overview and individual detail.
the ability to split offspring into categories such as gender also revealed more information than is possible with existing interfaces to this data.
in general, we found that testing the application with datasets of the size and complexity that crop up in the everyday working practices of these domain experts was essential; it validated that the visualisation could cope with data it could expect to encounter in practice.
not having a visualisation that can cope with representative data would negate most, if not all, of the advantage of later bringing in real users to interact with it.
this was shown with the larger data sets that are now becoming available, as the layout design of viper means most of the effects of an increasingly large marker set do not impact on the visualisation.
note that we say representative; as well as having real data in the form of resspecies pedigrees, we also generated artificial datasets to test the effect of particular combinations of data size and granularity on the visualisation.
these artificially generated datasets have the advantage that we know what they should look like in the visualisation if all goes to plan.
such an approach has precedent not just in visualisation but in pedigree analyses, with  <cit>  similarly introducing errors into otherwise correct genotype pedigree datasets to understand their effects.
trying to analyse whether real datasets have rendered properly would depend on a working knowledge of that particular dataset, which approaches a paradoxical situation when considering that gaining such knowledge of that data is why we wish to visualize it in the first place.
this held true into the second evaluation stage where known errors were introduced into real and generated pedigree genotypes.
again, visualising an existing dataset known to have errors would have required deep knowledge of that particular dataset to see if viper was communicating those errors properly.
by artificially injecting controlled errors, both pedigree and genotype, into clean datasets we can quickly ascertain whether the visualisation is communicating the presence of error and then, according to the domain expert, whether that communication makes sense.
there is also the bonus that such datasets could make useful training datasets for new viper users in the future.
once the visualisation has been verified as having the functionality necessary to correctly inform an expert user we can then revert to the "real data and real users" mantra.
we also found that the interaction with the geneticists changed from what was expected to be a user-centred process in which they would comment on or test what was implemented to a more participatory approach in which they became much more involved in the design of the prototypes.
this is not perhaps entirely surprising given they were the source of the domain knowledge necessary to construct and successfully test the prototypes, and were also likely to be primary users of the finished tool.
as such, it was in their interests to shape it to their specific needs.
similarly, it was also a learning process for the visualisation developers as during the course of the project the domain experts made many necessary corrections to the visualisation developer's view of the data and problem.
there would not have been anywhere near the same level of mutual feedback if the users had not been domain experts in their field.
the future challenge is to build a data cleaning application that can cope when these errors occur in proliferation and are layered many times on top of each other, rather than the isolated errors we introduced into data sets here.
when this is achieved we will have produced a novel tool that not only accurately and compactly visualises error within pedigree genotype data but allows users to clean the errors from such data.
competing interests
the authors declare that they have no competing interests.
authors' contributions
al and jk conceived and lead this study.
al is responsible for the resspecies data resource and with tp develops the resspecies api.
tp created the test datasets and performed user testing with al as 'expert user'.
jk and mg designed the viper interface and mg implemented the application.
tp, mg and jk wrote this manuscript which all authors have reviewed and approved.

 genotyped pedigree data underpins many forms of genetic analyses that are performed by breeders and biologists to identify, map and select economically or biologically important genes or heritable traits. for techniques such as linkage analysis, genotype scores for polymorphic markers distributed across the genome are analysed in the context of the pedigree structure and mendelian laws of inheritance. the statistical algorithms applied in such genetic analyses are critically sensitive to any errors in the data that exhibit as'inheritance inconsistencies', i.e. patterns of inheritance for alleles that are not consistent with the asserted parent-child relationships recorded in the pedigree. any such errors must be identified and cleansed from the data before downstream analyses. error cleansing constitutes a complex, labour-intensive expert task, particularly given the scale of modern genotyping studies, where populations of several thousand animals may be genotyped for tens of thousands of markers. pedigree and genotype data roslin bioinformatics provides the web-based resspecies data system for recording and analysing animal pedigree-genotype data. the experimental pedigrees available in resspecies, particularly those from the five major farmed species exemplify the variety in structure and scale of study populations with which we deal and these pedigrees have been used for the generation of test datasets employed in the evaluation. resspecies pedigrees range in size from to individuals, but more typical sizes range from to the structure of each particular pedigree reflects the design of the breeding experiment, e.g. inbreeding versus outbreeding, with the number of generations varying between and similarly the number of founder animals in each pedigree varies between and 1200; founders may be introduced throughout a breeding program, not only in'generation 0', and the proportion of founders used in a study varies greatly from % to 55%. the proportion of males recorded in a pedigree ranges from % to 94%, whilst the proportion of females varies between and 98%. some pedigrees, particularly fowl studies, may not record the sex of animals which are not kept for breeding, resulting in up to 98% of individuals unsexed, however, more typically only a few percent of animals are unsexed. sexing becomes a particular issue when identifying the inheritance pattern of sex-linked markers. the shape of pedigrees also varies, with some experiments using very few individuals in earlier generations, but generating large numbers in the final generations. the choice of mate selection is also study dependant, with some studies crossing a single individual with multiple partners, even across generations. this great variety in pedigree structure differs from typical human pedigrees, and the imbalances, multiple and cross generational pairings, and in some cases the size of families, present additional challenges for a successful pedigree visualisation which would allow the user to trace inheritance patterns from ancestors to descendants and siblings. inheritance studies use genotypes scored for any number of detectable genetic markers distributed across the genome of the study organism. a specific marker genotype is scored for each individual in the pedigree by detecting the allele pair. this allows the inheritance pattern of alleles to be traced through the pedigree structure. current large scale genotype studies are based on snp-chip technology, i.e. the identification of bi-allelic single nucleotide polymorphisms, allowing genotypes to be concisely represented by pairing single nucleotide characters or'-' for null sex-linked alleles. earlier genotype studies used a variety of less automated techniques to assay fewer, often multi-allelic genetic markers. the potential scale of snp-chip datasets reflects the availability of tens or even hundreds of thousands of snp markers for study organisms. real experimental datasets commonly contain missing genotype data. whilst this may occur sporadically due to lost samples or failed assays, missing data frequently reflects a systematic decision not to analyse samples for some individuals or generations which may be considered uninformative. the resspecies inheritance-checking algorithm infers inherited genotypes for missing data points using the principles of mendelian inheritance, which may result in either completely resolved or partially resolved genotypes. more complex partial inferences are possible for multi-allelic markers but for simplicity this study only uses bi-allelic markers. sex-linked inheritance patterns are observed for markers located on the sex chromosomes, where the heterogametic sex has a single allele for these loci. if sex-linkage is known in advance a null allele may be recorded in a dataset, otherwise the genotype would typically be scored erroneously as homozygous, with the inheritance pattern of an unrecognized sex-linked marker exhibiting a distinctive error pattern. viper software we have previously described genotypechecker, a simplistic prototype tool for assisting data cleansing that combines the resspecies genetic consistency-checking algorithm with a tabular display of genotypes for individuals within a pedigree. the tool highlights inconsistent genotypes and allows the interactive removal of identified erroneous data points. the ability to explore inheritance patterns in a pedigree context is essential for pinpointing the exact data points in error, particularly in the case of incomplete datasets where the inheritance algorithm will infer logically consistent data from the existing data points and thus'move' reported errors down to the lowest possible point in the pedigree. critically, however, the tabular display format does not allow the user to easily explore patterns of errors in the context of the family structures in the pedigree'tree'. to rectify this situation we have been developing viper - visual pedigree explorer - http://www.viper-project.org.uk/. the priority of any candidate visualisation to solve our particular problem is to show information such as marker data or error reporting within the context of a pedigree structure. a review of existing techniques for pedigree visualisation showed that current approaches fall short in either one of two categories: scalability and a lack of multivariate data display. pedigree viewers emanating from a biology background such as pedidraw or peditree acknowledge and support the integration of biological data on top of a pedigree, but do not scale well, partly because they stick to layout and representation recommendations developed for displaying pedigree data by the biology community. often they are designed not for screen rendering but for outputting hard copy on high definition printers. unbound by such representation guidelines, approaches to tackle pedigree drawing in the information visualisation field have focused on visual scalability through more compact layouts such as pvin and pedvis, and through adding interactive features that handle large data sets with operations such as filtering, guided navigating and dynamic zooming like geneaquilts. however these focus on human genealogies and thus do not accommodate or consider displaying the type of data associated with animal pedigrees such as genotype data. another specific problem that we recognised was that many pedigree visualisations are set up to show the global structure of pedigrees at the expense of quickly comparing immediate relations e.g.in most of these visualisations to connect between a parent and child involves tracing a link from one part of the screen to another, often through a sea of other links. essentially, we could not find an existing solution that had both the ability to show a pedigree beyond a minimal size, and the ability to show information attached to the individuals within that pedigree. following a number of design iterations which progressed from initial naive node-link representations, through matrix representations, we finally arrived at the pedigree view seen in figure which we term the'sandwich view'. the parent-child relationships between every two consecutive generations is viewed as a sandwich, the male parents at the top, the female parents at the bottom, with the children sandwiched in between. the children are laid out such they lie directly above their female parent and directly below their male parent, making parental relationships much easier to follow on a generation by generation basis. this representation provides the family-centric visualisation necessary to view and assess errors in the context of a pedigree structure. within the viper display, a simple discrete four-level colour-coding is used to indicate the proportion of erroneous markers associated with an individual, from white through light, mid and heavy colour shading for increasing error rates. reported inheritance inconsistencies may be categorised into three types: genotypes where no allele is inherited from the sire, where no allele is inherited from the dam, or where a novel, non-parental allele is detected. the three categories of error are represented in the offspring row as sub-parts of a hexagonal glyph, with the tips acting as stylised arrows oriented either up or down. the tips point to the sire and dam rows, colour-coded as described for the number of sire/dam errors for that individual or group across the marker set, and the'mid-stripe' of the hexagon is similarly coloured for the number of novel allele errors. a single genotype may exhibit any or all of these three error categories, and figure displays the six different possible combinations of these errors. in the sire and dam rows, the combined error count for all markers is used to colour the representation of an individual as seen in figure the user can toggle between an aggregated family overview, or the display of all individuals separately within each family or'mating pair', as shown in figure the sandwich views can be ordered from left to right by a selection of metrics, including name, partner count, number of ratio of errors in the offspring groups, and number of errors from offspring to either sire or dam. the offspring sets can be sorted internally by another group of metrics, again including error-related information. the initial viper display looked promising and revealed information about the distribution of errors in the pedigree structure not seen in resspecies. additionally, it also allowed child-parent comparisons that were intractable in other pedigree visualisation tools. however, it still needed much in the way of development in terms of interactivity and specialised biological data display to make it useful for real users with the full range of real data they need to investigate. we therefore embarked on a two stage evaluation of the software, which forms the structure of the rest of this paper. firstly, an initial evaluation was performed on a small number of test datasets and used to identify and implement any critical features or improvements required for a subsequent functionality evaluation. this second, in-depth evaluation performed by expert biologists tested the effectiveness of the visualisation in helping to identify a variety of representative error states deliberately introduced into simulated pedigree and genotype datasets. we then give an insight into how the size of datasets has scaled since the beginning of the project, along with a description of a complementary node-link visualisation. we then conclude with a discussion of the results and further work. methods the evaluation was performed in two stages. the first stage validated the ability of viper to handle and display the types of datasets to be used in the second stage - a utility evaluation in which we tested the visualisation's ability to faithfully represent pedigree genotype datasets of the necessary scale, and to cope with and indicate errors and omissions within them. this is distinct from usability or efficiency testing, as the primary aim was to ensure the necessary functionality of the system is present. this allowed the identification of critical features for implementation to support data browsing and error localisation, necessary to support the data and events we wished to explore in the subsequent second evaluation. the second evaluation stage was performed after this extra identified implementation was delivered, and involved testing the visualisation's capability for displaying differing error types commonly found in real-world pedigree genotype datasets. each separate'error type' under test was evaluated by creating an appropriate permuted pedigree and genotype data file pair, and then browsing the data visualized in viper to verify whether the pattern of inheritance inconsistencies revealed could be used to deduce the underlying, causative error. simulated datasets were used in order that each error type could be evaluated independently, without the confounding effect of multiple overlapping and interfering errors as found in real datasets. the two stages of the evaluation were performed by two geneticists from roslin with extensive experience in analysing and error-cleaning genotyped pedigree datasets. such an evaluation might not have the numbers of other usability or utility inspection methods, but the expertise of the domain experts in helping assess the visualisation is the overriding factor here, any assessment by novices to the domain would be much less informative. one geneticist created and anonymised the datasets, and monitored the other exploring each dataset in one-to-one sessions lasting an hour. the ease and accuracy with which errors were identified was qualitatively scored, and any issues with the interface or comments about desirable improvements were recorded. these observations formed the basis for deciding which additional information and functionality is essential to present to the user, what modifications might be beneficial but not essential, and any general usability and navigation issues. the approach has a similarity with expert reviews but the experts here are domain rather than visualisation experts, as they are the only ones who can truthfully assess whether the necessary functionality is present and correct. the majority of the evaluations used a moderately-sized, anonymized chicken pedigree comprising individuals, the details of which are listed in table alternately pedigrees with controlled numbers of individuals, generations and families per generation were generated de novo using a parameterizable script. dummy genotype data files for pedigrees were similarly created using a suite of creation and permutation scripts, and desired errors were introduced into either the pedigree or genotype files manually or with further editing scripts. the simulated genotype datasets reflect the data types found in current large scale studies based on bi-allelic snps, including sex-linked markers. a suite of scripts was used to create and then systematically corrupt synthetic genotype data, and to partially erase data from the f generation to simulate incomplete data coverage. initially consistent genotype data was generated using seven different randomly seeded markers. each marker had bi-allelic snp alleles c and t, with different c:t heterozygosity ratios, mammalian style male sex-linked pair, and female sex-linked pair. consistent datasets were generated for and markers by seeding with each marker one, ten or fifty times. the marker genotype dataset proved to be adequate for revealing the expected error pattern for the majority of error types in the data overview.  first stage evaluation we initially validated viper's ability to handle and display representative datasets, with regards to four particular aspects of the data in question: the ability to handle pedigrees of a range of sizes. the effect of incomplete data which requires inferring over the missing data. the ability to report systematic errors in sex-linked markers were measured. the ability to restrict the display to the details of a single marker. this stage of evaluation was spread over three separate hour-long periods, due to the time constraints of the geneticists involved. this did however give an opportunity to correct many minor interface issues they found before they next investigated the prototype, effectively turning the evaluation into a mini rite-style process, of which the who two-stage evaluation process could be considered a larger example. these interface issues included the wish for individual's representations within a generation to be of the same size; previously individuals filled as much space as they could expand into, but the geneticists thought this was giving visual prominence to certain groups, especially families with only a few individuals, leading them to query if they were somehow more important. also, labelling of sires and dams was switched to display vertically if the space for their display was taller than wide, with a draggable row header allowing the vertical size for such labels to be adjusted. size and structure of pedigrees a wide range of animal pedigrees extracted from the resspecies data source were tested to confirm the layout and display capabilities of viper over a realistic range of experimental pedigrees size and structures. in addition, in order to test the limits of display resolution and usability a number of artificial pedigrees were created as described in the methods section with controlled numbers of total individuals, generations and families per generation, as listed in table pedigrees were displayed using viper on a standard 1280× monitor, and the limits of usable resolution determined, comparing the'family' with individual offspring views. in summary, it was demonstrated that the visualisation can cope with any realistic number of generations and over families per generation at the overview level, although the labelling of parent names becomes problematic with over families. however, available space constrains the ability to distinguish the properties of individual offspring where there are a large number of families in a generation or a large number of offspring in a family. none of the experimental pedigrees available in resspecies exceed these thresholds. display limitations could be ameliorated with higher specification monitors or by expanding across multiple monitors, but in the authors' experience the target user group for viper, e.g. animal breeders, often lack high specification desktop hardware and monitors. it is understood that in future pedigree breeding experiments the number of animals is not expected to get any larger than the figures already seen in resspecies or the examples quoted in table this is because breeding and looking after animals is a resource-thirsty operation requiring real estate and labour to achieve. even within experiments it is not the case that every animal within a generation goes on to breed, thus avoiding an exponential increase in the number of animals per generation that we would otherwise need to accommodate in the display. the exponential expansion in pedigree genotype data sets will be in the number of markers annotated in the data set as sequencing technology continues to improve. the authors have recently seen data sets containing in the order of markers, and this is now not considered large. the effect of incomplete data and genotype inference as described above, in addition to reporting genotypes that are inconsistent with mendelian transmission, the resspecies inheritance algorithm infers missing genotype data by recursively applying allele transmission that must necessarily be true from known data points. as a consequence of the algorithm traversing the pedigree from founders down through descendants, errors are reported as low down the pedigree as possible, and particularly in the context of missing data and genotype inference, errors can be reported in individuals removed from the actual source error. the obfuscating effect of this became apparent when synthetic datasets were examined, where a proportion of genotypes were erased from the intermediate generation individuals, see figure the'non-presence' of such missing data would have to be recognised in the visualisation and suitably communicated to users. sex-linked markers a common systematic error found in real datasets arises when unrecognized sex-linked markers are analysed. typically this arises in mammals when the genotype assay scores males as homozygous for an allele, whereas in fact they should be heterozygous for the'y-null' allele; the effect is opposite in most birds with heterozygous'w-null' females unrecognized. as can be seen in figure this causes a gross systematic error to be reported, immediately apparent as a preponderance of'nil from sire' errors. however the sex segregation of this effect was not readily apparent because the sex of offspring was not represented in the sandwich view. to readily identify such errors, a method for distinguishing the gender of offspring in the display would have to be developed. single marker view the geneticists had mentioned the ability to select a single marker and view just its data would be important, and the previous subtleties arising from the sex-linked markers on top of the fact that errors and incomplete data differed from marker to marker reinforced their view. functionality for displaying the data associated with just a single marker at a time would need to be developed, along with a mechanism for choosing which marker to display. given that there could be thousands of markers within a pedigree genotype meant this selection would have to be guided by properties of the marker as searching blindly or exhaustively to find markers of interest would be both prohibitive and extremely frustrating. improvements to viper the initial evaluation of viper thus identified several major features which were required prior to performing a full functional evaluation. these improvements are illustrated in the marker summary shown in figure and in the single marker detail view shown in figure in order to support the exploration of individuals in any selected large family a'detail view' window was implemented to complement the overview of the entire pedigree - one of the standard practices for solving such problems in information visualisation. this'detail view' can readily accommodate families with hundreds of individuals on a standard monitor, overcoming the resolution constraints identified above. secondly, to expose the degree of genetic inference in the data a second colour map contrasting with the error colouring was implemented, showing the degree of missing data across the pedigree via the intensity of border colour on an individual or family. as the viper display already has space allotted for each individual and family in the pedigree then adding such extra indicators for missing genotype information is not difficult, it would be a different case if there was missing data in the pedigree itself. clashes between the dual colour highlighting used in the sandwich view to report inference and error rate are limited, because the inheritance algorithm does not infer'erroneous' genotypes from incomplete data. control of the colour schemes was provided by adding controls that allow the user to turn off or change the colour used for both the error reporting and the incompleteness maps, and also to choose which contrasting colour is used for user-selection highlighting. thirdly, in order to expose the sex of individuals in a family, and hence assist the identification of sex-linked inheritance problems, a further level of colouring was rejected as it would reduce the pre-attentive'pop-out' that the coloured error display currently enjoyed. instead the partitioning of offspring by sex was implemented, spatially separating the male and female offspring into different rows - in effect giving us a'club sandwich' view. in fact a third, intervening, row was required to accommodate individuals of undetermined sex, as many pedigree datasets include non-breeding individuals that have not been sexed. in essence, we are using another visual attribute, spatial positioning, to communicate low-count categorical data attributes of the offspring, rather than overload the colour channel. standard pedigree layouts use shape to represent gender in pedigree diagrams but spatial positioning is a more powerful communicator, especially when we wish to split a set of objects into groups. in addition to partitioning offspring by gender, the same visualisation mechanism is used to allow segregation of family offspring by other characteristics, such as possession of offspring. this sorting/partitioning mechanism allows the user to explore alternate aspects of inheritance patterns, and will have additional uses once we implement data-cleaning functions that allow modification of various properties of an individual and genotype data. finally, the initial viper prototype provided only an'overview' of summary information about inheritance errors averaged across all markers. this summary view adequately exposes many types of systematic errors resulting from wrong pedigree information or sample misidentification, but it does not allow the discrimination of more sporadic errors, nor could the user explore the actual reported genotypes for a given marker. this deficiency was addressed by adding a number of related components to the prototype. firstly, a sortable'marker table' was added to allow the user to select individual marker genotype data to explore. markers can be sorted according to their name, counts of reported error types and extent of data incompleteness. a second complementary table for the individuals in the pedigree was also added, with an additional column for gender type. selection of a named individual highlights it both in the table and the pedigree view, allowing the user to locate individuals of interest. in reciprocation, individuals highlighted in the pedigree view are cross highlighted in the table view. the combination of these two marker and individual information tables not only assists navigation of the data, but provides the detailed error information necessary for deep analysis of inheritance errors. this is augmented by a pop-up tooltip that displays on mouse-over of individuals within the sandwich view and details the same error information for individuals as reported in the tables. the marker and individual tables use the same colouring schemes for errors and incomplete data as the sandwich view. in this way the sandwich view and tables now form an example of a coordinated multiple view visualisation. within the marker table, an individual marker could be selected as a'focal marker', allowing specific genotype information for that marker to be overlaid in the sandwich visualisation - as seen in figure the single marker pedigree display is essentially identical to the overview, but adds the actual or inferred genotype to the labelling of individuals, allowing the user to analyse in detail the inheritance patterns of alleles in the pedigree. when data is visualised for a single marker, both colouring schemes become binary and mutually exclusive indicators for individual genotypes, as an incomplete data point cannot be marked as an error. thus we are either indicating the presence of an error at that genotype, or that the recorded data was incomplete or absent for an individual genotype, and consequently any genotype shown has been derived by genetic inference, or thirdly no colouring is applied as the genotype is both present and correct. in this mode, the individual table also shows only information for the selected marker, thus indicating for all individuals whether or not each category of possible error occurs. the addition of these and other controls necessitated the removal of the'sort' and'display options' from a dedicated pane area in the first prototype to more traditional menu bar locations. in addition the application now automatically saves a user's layout and colour scheme preferences as default values for the next time the application is run. with these improvements applied to the viper prototype, the second stage of the evaluation proceeded. second stage evaluation the second stage of the evaluation explored the effect of introducing controlled errors into real and artificial pedigree genotype datasets, and whether they would be represented by the visualisation in a form recognisable to a domain expert. pedigree errors real datasets frequently contain errors in the asserted pedigree structure, which might be caused by the misidentification of animals, incorrectly assigned paternity or errors in record keeping. furthermore sample misidentification or contamination can result in apparent pedigree errors. in order to evaluate whether the viper visualisation adequately exposes the possible kinds of pedigree errors found in real datasets various pedigree disruptions were engineered in the categories given in table where appropriate these permutations were performed in separate generations and upon both same sex and different sex pairs of individuals. furthermore, to evaluate the potential effects of inference on the observed inheritance patterns, genotype files were derived with or 100% of f genotypes erased. all permutations were readily identified in the sandwich overview apart from no. where inconsistent sex assertions in the pedigree file break the pedigree, causing a fatal error on file loading. pedigree files drawn from the categories in table were explored in viper using the marker test genotype dataset and with the 100%, then 50% then 0% erased f genotypes. the ease with which the error types were located and identified was assessed, and the influence of genotype inference on the inheritance pattern was considered. the categories listed in table were all successfully explored, with the exception of case which did not pass sanity checking by the resspecies algorithm. permutations with erased genotypes clearly demonstrated the importance highlighting of data incompleteness, as attention is drawn to the possible obfuscating effect of inference over missing data. as described above the reported errors are pushed down to f when or 100% genotypes are erased, making diagnosis of the root data error more difficult. the improved viper prototype draws attention to the lack of genotype data for the wrongly assigned littermates, alerting the user to the possibility that the errors reported in f may be propagated from the f generation. genotype errors genotyping assays can give rise to systematic or sporadic errors. unreliable assays may give rise to unusable data with very high error frequencies, however a low rate of sporadic'wrong calls' cannot be discounted for any assay. errors in sample or data handling may again be systematic or sporadic, and hence might give rise to inconsistency patterns resembling systematic pedigree errors, or to more random, less tractable patterns. various types of errors were introduced into hitherto consistent genotype files, as categorized in table where appropriate, errors were introduced to individuals in different generations, and in order to demonstrate the potential effects of inference on the observed inheritance patterns, alternate data versions created with or 100% of the f genotypes erased. the permutations and genotype mixings were also done on both same sex and different sex pairs of individuals. all permutations apart from no. were readily identified in the sandwich overview visualisation. although offspring can be sorted by litter information, there is as yet no suitable visualisation for litter mates; consequently attention is not drawn to errors restricted to a particular litter. it was noted that errors in genotype information tended to result in the display of errors between both the children and parents of the affected individuals. an erroneous genotype in an individual could not be reconciled upwards to one or both of its parents, and in turn that individual's offspring could not reconcile their genotype with the erroneous data in the individual, thus genotype-based errors tended to manifest themselves in two positions. the exception to this was the scenario in which we swapped the ids of two siblings that shared both parents: in this case both their genotypes could be reconciled upwards as there was no difference in parentage between them, however their offspring reported errors. example scenarios of introduced genotyping errors can be seen in figure where the last column shows the case of full siblings being swapped - here we have highlighted the actual swapped ids of and showing that they themselves do not report errors upwards, but their children do. in the pedigree-based scenarios only the relationship between the affected individual and its incorrectly assigned parents were flagged as error. the individual's offspring were still correctly assigned in the pedigree to the individual. this finding in turn has consequences for the effect of inferencing data and future masking capabilities. inferencing over a wrongly assigned individual in the pedigree will just push the errors down to that individual's children as they cannot reconcile with their grandparents any better than their parent could. however, inferencing over a bad genotype will often remove the error as the individuals in either direction will reconcile once the bad genotype in between is removed. in summary, identification of these various systematic id/genotype/parentage swaps proved readily tractable for experienced geneticists using the sandwich pedigree layout. in particular the ability to select and highlight an individual and its ancestors and descendants allows inheritance patterns to be traced. further informal evaluation the viper tool, complete with data masking capabilities, was demonstrated at a meeting of poultry genetic researchers in the uk after the completion of the functional evaluation phase. we found that they appreciated the importance of cleaning the data, and it was revealing that individual's comments focused on the ability to not just mask data but to "correct" data, e.g. to automatically find "correct" parents for misplaced individuals. similarly, feedback from a sole researcher working at a commercial animal breeder showed that they again quickly zeroed in on wanting to be able to suggest reorganisations of the pedigree and not just masking of erroneous information, however they did view the rest of viper's functionality as useful. this is perhaps evidence of a drawback to relying on just the two experts as we did in the evaluation, or simply in a differing definition of what data cleaning entails i.e. making the data good enough to run without error vs. making the data as accurate as possible. though viper itself is not designed to accommodate any further analyses beyond the cleaning of data i.e. to make it error-free within the constraints of mendelian inheritance laws, this could be an indication that any next stage in tools for pedigree genotype processing would be for the development of a suite of co-operating tools covering many processes, with data cleaning as just one necessary initial step. large genotype data files extremely large genotype files are now becoming commonplace in bioinformatics; as mentioned earlier in the paper this has meant a step-up from a few thousand markers to data sets with markers or more in the pedigree genotype domain. however, as discussed, the viper sandwich view and associated histogram views aggregate marker information across the interface and so such an expansion in data is not detrimental to the visualisation, the breaking point is actually when the amount of data loaded overwhelms the available memory. the data set shown in figure consists of animals over nearly markers, making for just less than million data points. currently this results in the host java process taking just short of mb of memory. individual markers, being separable from other markers, are computed in a time independent of the overall marker set size. when an event affects an individual across all markers then recalculation will take a time proportionate to the marker set size, but for the data set described above this recalculation takes around half a second in total on a ghz pc so is not prohibitive to interaction. viper is not concerned with any notion of dividing the marker collection into sets based on segregation patterns or linkage, instead treating each marker as an independent entity operating on top of a shared pedigree. this viewpoint is taken as viper is concerned with cleaning the data set which is then passed downstream for further processing. at this point other tools can then perform analyses on top of the data to decide relationships between markers. alongside this development some of the'pedigrees' supplied are now simply collections of triples; sets of father, mother and child unrelated to other triples. this does not result in particularly interesting visualisations but viper is still able to display such information.  the viper prototype has been evaluated for the display, exploration and identification of errors in genotyped pedigree datasets, using a range of synthetic datasets which incorporate a wide variety of pedigree and genotype errors, and introduce degrees of data erasure to mimic data incompleteness. the first evaluation exposed a number of critical features that were implemented prior to the full functional evaluation: a'detail view' for large families, the colour map of genotype'incompleteness', the ability to partition siblings by sex and other properties, the marker and individual data tables, and the single marker view functionality. the results of the second functional evaluation confirmed the ability to discriminate the vast majority of single error types in pedigree and genotype datasets. findings from the evaluations can be split up into two categories: what we learnt about viper in particular and what we discovered about the process of testing an application with domain experts in this manner. for viper in particular, the space-efficient layout of the pedigree population in generational layers, organized by mating pairs allows realistically large pedigree datasets to be explored, and the ability to toggle between a summary family view and detailed view of individual offspring provides a workable compromise between a simplified overview and individual detail. the ability to split offspring into categories such as gender also revealed more information than is possible with existing interfaces to this data. in general, we found that testing the application with datasets of the size and complexity that crop up in the everyday working practices of these domain experts was essential; it validated that the visualisation could cope with data it could expect to encounter in practice. not having a visualisation that can cope with representative data would negate most, if not all, of the advantage of later bringing in real users to interact with it. this was shown with the larger data sets that are now becoming available, as the layout design of viper means most of the effects of an increasingly large marker set do not impact on the visualisation. note that we say representative; as well as having real data in the form of resspecies pedigrees, we also generated artificial datasets to test the effect of particular combinations of data size and granularity on the visualisation. these artificially generated datasets have the advantage that we know what they should look like in the visualisation if all goes to plan. such an approach has precedent not just in visualisation but in pedigree analyses, with similarly introducing errors into otherwise correct genotype pedigree datasets to understand their effects. trying to analyse whether real datasets have rendered properly would depend on a working knowledge of that particular dataset, which approaches a paradoxical situation when considering that gaining such knowledge of that data is why we wish to visualize it in the first place. this held true into the second evaluation stage where known errors were introduced into real and generated pedigree genotypes. again, visualising an existing dataset known to have errors would have required deep knowledge of that particular dataset to see if viper was communicating those errors properly. by artificially injecting controlled errors, both pedigree and genotype, into clean datasets we can quickly ascertain whether the visualisation is communicating the presence of error and then, according to the domain expert, whether that communication makes sense. there is also the bonus that such datasets could make useful training datasets for new viper users in the future. once the visualisation has been verified as having the functionality necessary to correctly inform an expert user we can then revert to the "real data and real users" mantra. we also found that the interaction with the geneticists changed from what was expected to be a user-centred process in which they would comment on or test what was implemented to a more participatory approach in which they became much more involved in the design of the prototypes. this is not perhaps entirely surprising given they were the source of the domain knowledge necessary to construct and successfully test the prototypes, and were also likely to be primary users of the finished tool. as such, it was in their interests to shape it to their specific needs. similarly, it was also a learning process for the visualisation developers as during the course of the project the domain experts made many necessary corrections to the visualisation developer's view of the data and problem. there would not have been anywhere near the same level of mutual feedback if the users had not been domain experts in their field. the future challenge is to build a data cleaning application that can cope when these errors occur in proliferation and are layered many times on top of each other, rather than the isolated errors we introduced into data sets here. when this is achieved we will have produced a novel tool that not only accurately and compactly visualises error within pedigree genotype data but allows users to clean the errors from such data. competing interests the authors declare that they have no competing interests. authors' contributions al and jk conceived and lead this study. al is responsible for the resspecies data resource and with tp develops the resspecies api. tp created the test datasets and performed user testing with al as'expert user'. jk and mg designed the viper interface and mg implemented the application. tp, mg and jk wrote this manuscript which all authors have reviewed and approved. 
evaluation was performed as a two stage process with the assistance of domain experts. the initial evaluation drove the iterative implementation of further features in the software prototype, as required by the users, prior to a final functional evaluation of the pedigree display for exploring the various error types, data scales and structures. this paper describes an evaluation of how viper displays the different scales and types of dataset that occur experimentally, with a description of how viper's display interface and functionality meet the challenges presented by such data. the viper display was shown to effectively expose the range of errors found in experimental genotyped pedigrees, allowing users to explore the underlying causes of reported inheritance inconsistencies. we examine a range of possible error types found in real and simulated pedigree genotype datasets, demonstrating how these errors are exposed and explored using the viper interface and we evaluate the utility and usability of the interface to the domain expert. such datasets consist of hundreds of related animals genotyped for thousands of genetic markers and invariably contain multiple errors in both the pedigree structure and in the associated individual genotype data. in order to assist this process we are developing viper, a software tool that integrates an inheritance-checking algorithm with a novel space-efficient pedigree visualisation, so that reported inheritance inconsistencies are overlaid on an interactive, navigable representation of the pedigree structure. pedigree genotype datasets are used for analysing genetic inheritance and to map genetic markers and traits. these errors manifest as apparent inheritance inconsistencies in the pedigree, and invalidate analyses of marker inheritance patterns across the dataset.
 pedigree genotype datasets are used for analysing genetic inheritance and to map genetic markers and traits. such datasets consist of hundreds of related animals genotyped for thousands of genetic markers and invariably contain multiple errors in both the pedigree structure and in the associated individual genotype data. these errors manifest as apparent inheritance inconsistencies in the pedigree, and invalidate analyses of marker inheritance patterns across the dataset. cleaning raw datasets of bad data points requires expert exploration of the patterns of exposed inconsistencies in the context of the inheritance pedigree. in order to assist this process we are developing viper, a software tool that integrates an inheritance-checking algorithm with a novel space-efficient pedigree visualisation, so that reported inheritance inconsistencies are overlaid on an interactive, navigable representation of the pedigree structure. methods and  this paper describes an evaluation of how viper displays the different scales and types of dataset that occur experimentally, with a description of how viper's display interface and functionality meet the challenges presented by such data. we examine a range of possible error types found in real and simulated pedigree genotype datasets, demonstrating how these errors are exposed and explored using the viper interface and we evaluate the utility and usability of the interface to the domain expert. evaluation was performed as a two stage process with the assistance of domain experts. the initial evaluation drove the iterative implementation of further features in the software prototype, as required by the users, prior to a final functional evaluation of the pedigree display for exploring the various error types, data scales and structures.  the viper display was shown to effectively expose the range of errors found in experimental genotyped pedigrees, allowing users to explore the underlying causes of reported inheritance inconsistencies. this interface will provide the basis for a full data cleaning tool that will allow the user to remove isolated bad data points, and reversibly test the effect of removing suspect genotypes and pedigree relationships. 23- october 1st ieee symposium on biological data visualization providence, ri, usa 