Add autosomal DNA match list data to GEDCOM.

[RonTilby]

With the growth of autosomal DNA testing for genealogical purposes, and tools that utilize DNA match data. There is a need to store and transfer autosomal match list data as part of GEDCOM files.

If this capability was added to GEDCOM, and the PC Genealogical Database tools (Ancestral Quest, RootsMagic, etc.) were to add the capability to enter and maintain autosomal DNA match list data to their respective user interfaces, and include the data in GEDCOM export files, then tools such as What-are-the-Odds (WATO) and BanyanDNA could import the match data as part of a GEDCOM import.

This could dramatically improve user efficiency in the use of DNA match analysis.

The proposed data fields are:
RIN 1
RIN 2
Data Provider (Ancestry, 23andMe, GEDMatch, MyHeritage, Other)
Shared cM
Percent Shared
Number of Shared Segments
Unweighted Shared cM
Longest Segment cM

Note: This proposal DOES NOT include management of raw DNA data files.

[kiwi3685]

I 100% agree. I already do exactly that, but external to GEDCOM, in my own software. Having just those fields as part of GEDCOM would be a great help.
Those basic fields are all most users want.

[tychonievich]

I don't use DNA in my own research so I am missing some info here, but here's an effort to turn this list of data fields into an example of what we might add to GEDCOM:

0 @D1@ DNA
1 PERSON_1 @I1@
1 PERSON_2 @I2@
1 PROVIDER Name of some company
1 SHARED_CM 50
2 PERCENT 0.735
2 UNWEIGHTED 52
1 SHARED_SEGMENTS 18
1 LONGEST_SHARED_SEGMENT 7 
...
0 @I1@ INDI
1 NOTE First person being matched
0 @I2@ INDI
1 NOTE Second person being matched

This design isn't ideal from a "the way GEDCOM usually does things" standpoint. This kind of data feels to me more like an attribute or ASSO, but this design has it as a record. We could move it to be a substructure of one of the INDIs pointing to the other, but the data is symmetrical so it's not obvious which one should have host the data (nor which should be PERSON_1 vs PERSON_2 in this example).

---

Aside: it's not clear why we'd include both cM and percent. All the DNA genealogy sites I consulted suggested that these are defined in terms of on another; in particular $$\text{percent} \equiv \frac{\text{cM}}{68}$$ so it seems like including just one of the two would remove the chance of nonsensical data like "shared 50cM, 92%"

[kiwi3685]

My opinion:

Your structure works well. The second part needs be:

0 @I1@ INDI
1 DNA @D1@
0 @I2@ INDI
1 DNA @D1@

Re: "Aside: it's not clear why we'd include both cM and percent. All the DNA genealogy sites I consulted suggested that these are defined in terms of on another"
Yes that is correct. But some DNA provider sites use one, some both, and some the other. So it is valuable to be able to record both in the interest of genuine recording of source data as provided, without alteration.
The formula you provide would be of more interest at the data entry point as a quality control check.

Re: "so it's not obvious which one should have host the data (nor which should be PERSON_1 vs PERSON_2"
It doesn't really matter, and certainly doesn't need to be specified.

[theDNAgeek]

There is not a strict linear correlation between between percent and centimorgans. For genetic genealogy, centimorgans are more accurate, but that info is not always available (e.g., at 23andMe), so sometimes we have to make do with percent. In theory, the conversion factor should be around 70, but I've found empircally that 74.5 works better.

[GaryGriffin]

The segment-level info should be included, if available, as that widens the usage (DNA Painter and match analysis). Ancestry does not provide this level of detail, but FTDNA and GEDmatch, for instance, do.

Personally, I would use an ASSO . It could be part of either INDI since it is symmetrical.

[theDNAgeek]

Data fields for Y-DNA and mtDNA haplogroups would also be valuable. BanyanDNA does not currently use that information, but we plan to in the future.

[tychonievich]

Can you make this more concrete for me? What data are you proposing we store for segments (@GaryGriffin) and haplogroups (@theDNAgeek)? Would those belong to the same pair-of-people structure as the shared centimorgans data, or in separate single-person structures?

[theDNAgeek]

Haplogroups would be separate single-person fields, one field for the Y-DNA haplogroup and one for the mitochondrial haplogroup. No pair-of-people structure needed.

[GaryGriffin]

The segment-level info is a list of the specific matches for the pair of people. A matching pair of people would have 1 or more segment matches. A segment match includes the following info:

• chromosome number
• start location of match
• end location of match
• shared length (in cM)
• matching SNPs

For Example:
3,56950055,64247327,10.9,1404
Which means; Chromosome Number: 3, Start Segment: 56950055, End Segment: 64247327, shared length in cMs: 10.9, matching SNPs: 1404

There is additional info that may be available for the match (overall):

• whether the match is on the maternal or paternal side (which may be deduce-able with a known family tree).
• Testing company build (build 36, 37, 38) which has different lengths of each chromosome. This is important if you are comparing multiple people matches from different testing companies.

I agree that storing Y-DNA and mtDNA haplogroups is another 'good thing'. These are attributes of the person, not the match. Only males have Y-DNA haplogroup. Everyone has an mtDNA haplogroup.

R-M269 is the most common European Y-DNA haplogroup (https://en.wikipedia.org/wiki/Haplogroup_R-M269) .
U5a1 is a common European mtDNA haplogroup.

[tychonievich]

Discussed in steering committee 23 MAY 2024

• We like the DNA_MATCH record, and think it clearly matches the Absent and Needed criteria for new additions. It's not clear to our group if the Used criteria is met (we've been told that Family Tree Maker exports a _DNA structure but don't know what it stores in that). If anyone on this thread knows what current GEDCOM-using tools have structures for DNA matches, we'd welcome that information!
• We like the recommended addition of segment-level information and the back-references from INDIs to the record.
• We agree that haplogroup is also needed, but have several questions we want to investigate before moving forward; we know that the haplogroups are named by another organization and want to understand more about that before proposing a representation in GEDCOM in case that structure will inform how we incorporate it.

[RonTilby]

Existing software support:
Ancestral Quest has long had support for recording and exporting in GEDCOM Y-DNA and mtDNA markers and values. See the screenshots in this related discussion: #118

In June 2024, RootsMagic released support for entering Autosomal DNA Match info in RootsMagic version 10. My understanding is that they do not currently include DNA Match data in GEDCOM export files.

BanyanDNA and the What Are The Odds tools support import of GEDCOM files, but DNA Match data must be manually entered.