Adding mtDNA and yDNA data support to GEDCOM 7.x ?

[atom888888]

I would propose that GEDCOM 7.x add the ability to store mtDNA and yDNA data in the file format, much like AncestralQuest program does.

https://ancquest.com/index.htm

atDNA (Autosomal DNA) would have like 700,000+ rows for a test kit result per individual and per test, so that would make the file VERY large, so I can understand NOT wanting to have that in the GEDCOM format, but mtDNA and yDNA data are very small datasets.

They have things like:

• mtDNA
• yDNA
• testing company
• test date
• haplogroup
• testID
• STR yDNA markers
• for mtDNA HVR1/HVR2 mutation list.

Here is a screenshot with what their UI looks like to give you an idea:
yDNA

mtDNA

[tychonievich]

I'm not an expert in this subject, but I've not found a consensus in how to present this information.

mtDNA can be presented as

• a full list of roughly 16K bases
• a full list of all positional differences from the CRS (the mutation lists you noted)
• a list of known single nucleotide pairs (SNPs), which have rare inconsistencies in naming by testing company. Around 500 mtDNA SNPs are known so far (https://www.snpedia.com/index.php/Category:SNPs_on_chromosome_MT)

Y-DNA can be presented as

• a full list of roughly 59M bases
• a list of known SNPs, again with some naming inconsistencies. At least tens of thousands of Y-DNA SNPs are know
• a small company-defined subset of the many possible STR markers

Additionally, some scientific knowledge is not yet represented in most family history DNA tests, such as the strong correlation between an individual's age and how likely different mitochondria in their body are to have different mtDNA (https://pubmed.ncbi.nlm.nih.gov/24792352/). This reduces my confidence that even if we could cover all ways these DNA are presented today that would remain valid in the future.

But again, I'm not an expert in this space and would be happy to see a design for storing DNA test results in GEDCOM.

[atom888888]

See my comments below on mtDNA, atDNA, yDNA and STRs/SNPs.

I think there is one principal to be kept in mind which is the addage: "don't let perfection be the enemy of progress". Just like a family tree, that is never really "done" if we wait until scientific knowledge is "done" or complete, there will never be any progress.

I think we can take the approach of most software and hardware development and get a 1.0 version of DNA data integrated in GEDCOM 7.x and then update to a 1.1, and 2.x. DNA data type added in as we get iteratively better at understanding the needs and benefit of DNA data in GEDCOM and family history.

If we leave out DNA data we are doing the family history / genealogical community a huge dis-service in GEDCOM 7.x.

Some companies like AncestralQuest and Ancestry and others are already incorporating DNA into their products and services, either directly or indirectly.

If we can help ease portability between testing companies by providing a standard to transfer the data in, we can help break the "vendor lock-in" that exists in places like: ancestryDNA, 23andme and others that want you to "pay to play" and get tested to get into their big database.

[tychonievich]

DNA data is

• very large
• created by specialized tools and not to be edited by hand
• best displayed by a specialized viewer, not by the same widgets use to show all other tree data

That makes it more similar to multimedia files like images and sound clips than to most 7.0 structures.

I propose we store DNA data in external files included in the GEDZIP and linked by FILE pointers. We could use the existing OBJE for that, adding a suitable OBJE.FILE.FORM.MEDI value. We could also add a new structure, something like INDI.DNA.FILE, which would make more sense if the external files fail to embed relevant metadata that we'd need to store in the INDI.DNA instead.

This proposal does not remove the need for a standard way to represent the data, but it does moves it out of the GEDCOM standard and into a separate DNA file format standard. I understand that most testing companies already provide some kind of "download raw data" option, and that these files are relatively consistent in their encoding. I don't know if they are actually standardized or not, but an external file pointer would allow us to leverage such a standard if it exists or to form a separate standards group, with its own domain experts and release cycle, to define one if it does not.

[atom888888]

There are really 3/4 types of DNA tests and data:

1. atDNA (Autosomal DNA), done by most major DNA companies that can consist of very large datasets, 700,000+ rows of data. For this type of data I feel a GEDZIP type of linked standard would make sense, or not to store it or support it at all, or perhaps provide a URL of a website/ company where data can be found with metadata (kit #, name, ID, company name, test date, DNA Chip array info, etc.)

2. yDNA - can be either: a) STRs (usually of the variety of a VERY small set of data: 12, 25, 37, 67, 111, 500 or 700 markers from familytreedna.com), with 37, 67 or 111 one might attempt to either enter it by hand or "import" a .zip file or some other type into your GEDCOM compatible file with little file size impact or b) SNPs (which can be a much larger data set), I think SNPs fall into the same category as atDNA

3. mtDNA - I would store it as HVR1/HVR2 with only differences from the CRS (Cambridge Reference set), doing this makes it a very small # that can even be entered by hand, which I have done. No need to store all data, just the "diffs" difference from the CRS or other similar standard (there is one more other than CRS that has been used in the past, whose name escapes my memory at the moment).

4. possibly storing the haplogroup and/or yDNA /mtDNA phylogenetic tree of: mtDNA and/or yDNA tests could also be helpful

An example of these phylotrees can be found here:
http://scaledinnovation.com/gg/snpTracker.html?snp=I-FGC76653&tab=data

FamilyTreeDNA, 23andme, livingDNA and other such companies have their own version(s) of these trees.

Metadata about the 3/4 types of testing could be stored as well to include things like the list below. This could be stored at a minimum, even if you don't store the raw test results. This could aid in understanding who is clearly likely related or not. Similar to race, but at a finer grained detail by providing population genetic type of information.

• test date
• testing company
• DNA chip and version used
• test taker's info: name, birthdate, locality, gender, kit #
• privacy settings
• test type: yDNA, mtDNA, atDNA
• haplogroup for yDNA and mtDNA
• URL / link to company website to get raw data, with appropriate access permissions TBD.

[ghost]

I agree that having another BLOB-like data contribution would be bad

[elyoh]

As far as I can tell, autosomal DNA (atDNA), mitochondrial DNA (mtDNA), and Y-chromosome DNA (yDNA) tests are the only kind of DNA tests available on the market. There are varying levels of support for these in tree builder applications. The only 3 commercial applications that I know of that are using GEDCOM and can store DNA data are Ancestra Quest, Legacy, and The Master Genealogist.

Louis Kessler documents how commercial DNA test providers are structuring this data in flat text files:
https://www.beholdgenealogy.com/blog/?p=2700

One application uses GEDCOM extensions and to store this data:
https://chronoplexsoftware.com/gedcomextensions/mft-gedcom7-extensions-1.0.pdf

These would be useful starting points.

In general, DNA test data contains:

• generic information applicable to any test such as test ID, test company, date of test, user notes, privacy etc.
• representation of a list of single nucleide polymorphisms (SNPs)
• representation of a list of series of single tandem repeats (STRs)
• special fields specific to a given type test e.g. a haplogroup, full sequence, or reference sample

SNPs
Require upto 4 fields:

• RSID (Reference SNP cluster ID)*
• Chromosome (normally a number bewteen 1 and 22 or letter X or letter Y - at least for humans!)
• Position (an integer number)
• Genotype (two letters from A T C G)

Some SNPs can be recorded more simplistically. For instance:

• Y DNA tests only include data on the Y chromosome, and therefore the chromosome letter can be omitted
• mtDNA tests store SNPs as differences with respect to a reference sample, normally in the form of an integer position followed by a single letter from A T C G. Interpretation of the position yields HVR1 or HVR2.

STRs
Require 2 fields:

• Marker (a named pattern of DNA)*
• Repeats (an integer number specifying how many times this named pattern repeats)

*meaning and relevance may change with time, and therefore should not be constrained by the spec.