allData = document.getElementsByTagName("pre")[0].innerHTML;
What if your data is not tab-delimited? Well, think about it this way: All data is delimited. The only question is what the delimitation scheme is and whether it's consistent all the way through. JavaScript offers many ways to parse data. You're limited only by your understanding of the data, and of JavaScript. Bottom line, all data can be parsed. It's a matter of finding patterns.
Let's go through a quick example using some bio-data. The other day I talked about pulling codon tables down from genomevolution.org. I eventually stuffed a bunch of data into a text file. The data looked like this:
Plus much more like the above. Lots and lots of codon tables for lots and lots of organisms. How to parse it all? Since there's a carriage return at the end of each table (but not at the end of each line in the table), getting an array of tables just requires
codonTables = allTheText.split( "\n" );
If you're not a biogeek, here's a big chunk of molecular biology in a nutshell: DNA is a four-letter language (A,G,C,T) for spelling three-letter words called codons. If you do the math, there are 64 possible codons. Each codon corresponds to an amino acid (of which there are 20 in living organisms). The fact that there are 64 codons but only 20 amino acids means some amino acids have more than one codon. But also: three of the 64 codons have a special meaning. The codons TAG, TGA, and TAA are so-called stop codons. They don't code for any amino acid. Instead they tell RNA polymerase when to stop making protein.
The codon table for an organism tells you the usage frequency for each of the 64 possible codons. The frequencies (as you can see above) vary a lot, not only within a single codon table (for a single organism) but across organisms. Some organisms have DNA that's unusually high in G (guanine) and C (cytosine). Those organisms tend, not surprisingly, to use codons containing mostly G and C. Other organisms, like C. botulinum (yes, that botulinum), have DNA that contains hardly any G or C and hence use the codon AAA (which stands for lysine) a good deal more than, say, GCG (alanine).
If we know (as we do, from the above tables) the frequencies of occurrence of codons that contain 'A' (such as CAA, CCA, AAA, AAT, AGA, etc.), then it's a simple matter to sum all the 'A' frequencies to get the total frequency of occurrence of A in the organism's DNA (or at least in the coding regions of its DNA). We can do that also for C, G, and T to get their frequencies. Here's a routine that looks at a codon table's 64 entries and derives A, G, C, and T compositions for the DNA:
function getBaseComposition( table ) {
var codons = table.split("%"); // parse table into individual codons & freqs
codons.pop(); // get rid of empty final item
var bases = new Object( );
bases.A = 0;
bases.G = 0;
bases.T = 0;
bases.C = 0;
function analyze( item ) {
var percent = item.split(/\s/)[1] * .01; // get that percentage
var codon = item.substring(0,3); // get the actual codon
bases[ codon[0] ]+= percent; // base 1
bases[ codon[1] ]+= percent; // base 2
bases[ codon[2] ]+= percent; // "wobble" base
}
codons.forEach( analyze ); // loop over all codons
bases.A /= 3; // normalize the frequencies
bases.G /= 3;
bases.T /= 3;
bases.C /= 3;
return bases;
}The line codons = table.split("%") chops the codon table up into a bunch of pieces that look like CCA(P) 0.47 (that is: a codon, followed by one-letter amino-acid abbreviation in parens, followed by a frequency number). The "%" character happens to be convenient to parse on, but the presence of a % at the end of the table also means split("%") creates an empty item at the end of the array, which we don't want. We get rid of the empty item with .pop().
Parsing CCA(P) 0.47 into a codon and a frequency number is easy. To get the codon, take the first three characters of the string, by using item.substring(0,3). To get the number at the end, just split at the space using item.split(/\s/)[1] The bracketed 1 on the end means give me the second item in the array that was created by split(). The first item in the array (at index 0) would of course be CCA(P).
Note that we have to normalize frequencies (divide by 3) toward the end, because we're looking at 64 frequency percentages (that add up to 1.0) but we're counting 3 bases per frequency number (because codons have 3 bases each), hence if we don't normalize, we're going to end up with 300% total base content instead of 100%.
The internal method analyze( ) is a callback. We give it to the forEach( ) method of the codons array. In case you didn't realize it, JavaScript now has a built-in forEach( ) method as part of every Array object, and most modern browsers support it.
If we run this code against the first codon table shown further above (which happens to be for an organism named Abiotrophia defectiva strain ATCC 49176), we get back an object with fields A, G, T, and C containing the overall frequencies of occurrence of those bases in A. defectiva DNA (or at least the parts of its DNA that code for protein, which is well over 90%). What I got in Chrome's console looked like this:
The G+C percentage for this organism comes to 0.378 (or 37.8%). To me, what's more interesting than the G+C number is that no two base compositions match. G does not equal C (not even close, in fact) and A does not equal T. In theory, G should equal C (and A=T) according to Chargaff's second parity rule, which applies to single-stranded DNA. (Remember, that's what we're dealing with here: ssDNA. We're looking at codon values that correspond to sequences on the RNA-synonymous strand of the organism's DNA.) Obviously, Chargaff's second parity rule doesn't hold in this case, because G is almost twice C, and A is 150% of T! Moreover, A+G equals 0.5672, meaning the purine content is 56.72%. According to Chargaff's second rule, purines and pyrimidines should be 50% each. That's not the case here.
Things get really fun when it comes time to graph the data you crunch in the console window. If you're thinking "Google Charts," think again. There's a much easier and more powerful way to graph data (and no, it does not involve Excel). I'll tell you all about it in my next post.
No comments:
Post a Comment