GENEALOGY-DNA-L ArchivesArchiver > GENEALOGY-DNA > 2012-05 > 1337072267
From: "Anatole Klyosov" <>
Subject: Re: [DNA] 111-Marker Mutation rates
Date: Tue, 15 May 2012 04:57:55 -0400
> From: "Sandy Paterson" <>
> I've set up an FTDNA project for Father-son and brother-brother haplotype
> comparisons. It's at
> It's still in its infancy, bet the response has been encouraging.
Such a database can be only welcomed, however, it is a long time overdue. It
would be great to have it, say, 10 years back, but it would have been close
to impossible on a number of reasons. Now its main function is to marvel at
it, and hardly anything more. Well, maybe some unusual mutations happen,
such as a six-step mutation at once, however, it all is generally
predictable, and would hardly change our knowledge on those systems. This
Project falls into "out-of-curiosity" category, which is fine. Curiosity is
a nice occupation.
Two things have to be remembered when we marvel at this database. First,
that it should contain some 800,000 entries to be really functional. In that
case it would give a 10% margin of error with the 95% confidence regarding a
number of mutations per marker, and for it the database should have at least
400 mutations in each locus. Still, some "slowest" markers will have only a
few mutations in each, MUCH less than those 400 mutations. It still will be
statistically insignificant. For example, in almost 2000 father-son pairs
(Ballantyne et al, 2010) the following number of mutations were observed in
the first 12 markers: 3, 2, 7, 5, 3, 6, 0, 0, 6, 9, 1, 6.
Second, it still would be "per generation" and need to be translated into
years for any calculations of any "historical" significance. In history,
archaeology, etc. nobody measures in generations. Therefore, one needs to
calibrate the data anyway, and it was already done and published. Even in
"classical" genealogy a number of "generations" would not be functional,
since a length of a generation is a floating number in different lineages
amd generations, in different environments.
In other words, this database is fine, but it is hardly functional.