I've already registered my complaints on the V6 'DNA' feature - while the implementation is competent, that's of little value when the design is so badly though out. As a result, it's basically useless.
Having said that, I've been thinking about it (I'm a software engineer myself and can't resist playing with such things). One of the characteristics of DNA information that make it different from most genealogical record information, is that it applies not only to the individual tested but to that individual's entire Y-line or mt-line (with exceptions that I'll get to later). Initially this seems as if it would be a whole new ball game, but on inspection it's hardly unique in the Legacy world. Similar relationships exist with 'master records' such as surnames, geo locations, and references, with many to one relationships between individual records and master records. That's the way that I'd handle this; when mt- or Y- information is entered, a master record would be created and a link to that master record inserted into the individual record. The link would also contain related information such as whether the link was tested or projected. Then because of the way that mt- and Y-DNA work, a tree walker in the code could follow that line back and insert 'projected' links in the other records for that line. (Mutations, which are rare) would be handled by a special connector between master records.) When the tree walker detects a collision with another projection (trivial to implement) a chunk of collision resolution code comes into play. If both projections reference the same master record (most probable result), there's no problem. Different records with identical signatures should in some cases be merged, but I would definitely pop up a message box first. If the patterns DON'T match, that means that there's one of two types of anomalies; a small (1 or 2) value difference at one marker is likely a mutation, while a significant difference at several markers would most likely be a paper trail error such as a mis-attribution or a false paternity event, and should be flagged as an error needing resolution. This complicates the tree walker code a bit, since in the event of something like an adoption it would have to look at both sets of parents, but that's not very much of a complication as long as the designer is aware of the requirement. This could also be integrated into the 'Research Guidance', since matching patterns appearing in different lines (especially close to the same place and time) might invite further consideration. A tree walker following a line back to a solid triangulation could also set or validate the 'Biological' child status flag. Well, you get the idea. Glen Legacy User Group Etiquette guidelines can be found at: http://www.LegacyFamilyTree.com/Etiquette.asp To find past messages, please go to our searchable archives at: http://www.mail-archive.com/legacyusergroup%40mail.millenniacorp.com/ To unsubscribe please visit: http://www.legacyfamilytree.com/LegacyLists.asp
