Lots of worthwhile info in your email but too many acronyms for me - for example, I can't decide if BGA is the acronym for Barista Guild of America or Battle Ground Academy?
Best Ron On Jun 17, 2013, at 12:48 PM, [email protected] wrote: > > I hope "changes to the old ones" includes updating the present DNA material > as well as upgrading to recognise recent advances. > > The list of those involved in testing looks tired. Under "Tests Available", > good luck with DNAH and Genetree. The former went belly up in 2011, public > database suppressed by FTDNA, and Ancestry ate the latter 6 months ago. Where > is 23andMe? If the intent was to list origin and data locations for the test > entries, SMGF is notably missing too, as the website and database still > function, though slaved to Ancestry. And in case no one has noticed, the BGA > chips are an obvious game changer... > > Entering yDNA data by hand is tedious and liable to error, better a .csv file > for 67 or 111 markers, and there's a case for entry in the native format with > program translation to a standard one, logically FTDNA's order with any > necessary data adjustment. > > Haplogroup is more useful than it was, but presently changes so frequently > that it's probably inappropriate for a program designed to produce books. > (Mine has changed about annually for the last 3 or 4 years.) Terminal SNP, as > tested or as implied, is a stable solution, and it's trivial to convert to or > from the latest haplogroup code if the entry instructions reference > (currently) the latest ISOGG tree. "Confirmed" is another can of worms. My Hg > shows as "implied" in all records, but that's because FTDNA has not bothered > to update them after I had my current terminal SNP tested, and that's the > general case. > > Then there's mtDNA and atDNA. It's probably well beyond the scope of Legacy > to directly address these, but it certainly isn't to provide for entering kit > or other ID number and database where information may be found. Further, for > those who use Legacy as a research tool rather than for just recordation and > presentation, atDNA is being successfully used to find actual or potential > family connections out 5 generations or more. That's a strong argument for > facilities to support concurrent work on unlinked individuals and families. > One possibility might be to permit split screen to be used to display a > tagged group present in the family file but unconnected to the principal > tree. Another might be provisional linking across gaps, lateral or > longitudinal. The confidence which may now be placed on yDNA matches, and the > substantial time spans which may be involved, bring need to deal with cases > where several generations may be missing but connection can be considered > proven to at least comparable standards to those accepted using paper trails. > Even mtDNA proved lineage recently for Plantagenet bones dug up from a > parking lot. > > Reaching further back, the pure genealogist may have to give up, but the > family historian may have much further to go regarding the questions, "Who, > what are we, and whence came we?" In my case, I'm a Britton, and the origin > of our family name goes back some centuries BC, certainly germane to a family > history if immaterial to a genealogy. Adoption of it as a surname is much > later, of course, but yDNA may reach back to identifiable family living in > Norman times - genealogy as well as history there. Millennia may just punt > and simply advise setting Report output to word processor compatible format, > then heading "The Family History" with material written using that. Kind of a > pain though with pagination, index etc. Is it impracticable to provide a > report option which accepts reserved space blocking and index entries for > such? Would it be impossible to extend timelines with perhaps a log time > scaling? Or to link back across descendancy gaps with "Mr Gap" placeholders? > > Back when I was doing a lot of this with Legacy 6, I became an advocate for > the Placeholder family. It's a surname which is easy to find and an > unequivocal disclaimer of actual identity if it leaks into a report or chart. > It's not just useful locally, as to permit linkage of siblings when the > parents are unknown or when descent is known but not from which sibling etc., > but it's also a solution for the longer linkages of the DNA domain. > Placeholders can have remarkably long lives for timeline purposes, or be > chained in estimated generations to facilitate lateral connection matching to > other genealogies or display most probable family structure from STR based > MRCA calculations. Given names beginning DNAxxx are also easy to find and > informative. So is Placeholder as a given name, normally surnamed with the > associated family name as in "Placeholder Pratt" for the case where descent > was amply documented from brothers, but not which one. All of these > propagated stably in anything I did with Legacy 6, needing no modification to > the program and providing associated fields for information. > > Millennia may elect to punt in this area, leaving it to be revisited for > Legacy 9, shilling for test providers rather than supporting the use of the > new tools, but that may prove short sighted. Stepping in now perhaps offers a > chance to set de facto standards for DNA data in genealogy - and to avoid > Legacy 8 becoming rapidly obsolescent. > > Not DNA but related, there's also the predictable increase in genealogy > interest, available data and exponential cross connecting of genealogies. Do > we, or will we soon, need blocks, sutures and skeletons? Giant genealogies > become unwieldy and have increasing connections with other work. For the > family historian(s), local interest and media files may be more important > than the "greater vision" when organising a get together. Most of that's > clutter to the big picture, which also may not be helped by numerous small > fiefdoms. One solution might be development of a standard system of > segmentation to reduce things to manageable sub-units. That might be achieved > by embedding blocks in databases to halt machine traversal for inspection, > functioning as flexible boundaries to define content. Matching that, there > would be needed standard sutures to connect elements so defined. The final > requirement would be matching skeleton and "rich" data copies of segments, > permitting "big picture" assemblies reduced to conventional minimal > information but co-existence of more voluminous or private data where > desired. In short, facilities for very flexible mix-and-match. > > kb > > > > > ----- Original Message ----- > From: "Sherry/Support" <[email protected]> > > Of course! > > Plus new Help files covering the new features and the changes to the old ones. > > > > > > Legacy User Group guidelines: > http://www.LegacyFamilyTree.com/Etiquette.asp > Archived messages after Nov. 21 2009: > http://www.mail-archive.com/[email protected]/ > Archived messages from old mail server - before Nov. 21 2009: > http://www.mail-archive.com/[email protected]/ > Online technical support: http://www.LegacyFamilyTree.com/Help.asp > Follow Legacy on Facebook (http://www.facebook.com/LegacyFamilyTree) and on > our blog (http://news.LegacyFamilyTree.com). > To unsubscribe: http://www.LegacyFamilyTree.com/LegacyLists.asp > > > Legacy User Group guidelines: http://www.LegacyFamilyTree.com/Etiquette.asp Archived messages after Nov. 21 2009: http://www.mail-archive.com/[email protected]/ Archived messages from old mail server - before Nov. 21 2009: http://www.mail-archive.com/[email protected]/ Online technical support: http://www.LegacyFamilyTree.com/Help.asp Follow Legacy on Facebook (http://www.facebook.com/LegacyFamilyTree) and on our blog (http://news.LegacyFamilyTree.com). To unsubscribe: http://www.LegacyFamilyTree.com/LegacyLists.asp
