On 05-20-2011 14:36, Tom Wetmore wrote: > That is, our databases should support the entire "evidence layer" of data, > which they don't do today, with the "conclusion layer" of data, which is > all they support. I believe that the evidence should be codified into > "person records" that are structurally very similar to the conclusion > person records. That is, all your John Smiths should be encoded into > their own "person records." Seems to me that if one chooses to do so, many systems will allow you to create additional INDI records and merge them when the evidence is sufficient. To me, that sounds like they do support what you describe. -- Wes Groleau There are two types of people in the world … http://Ideas.Lang-Learn.us/barrett?itemid=1157

On May 21, 12:58 am, Wes Groleau <[email protected]> wrote: > On 05-20-2011 14:36, Tom Wetmore wrote: > > > That is, our databases should support the entire "evidence layer" of data, > > which they don't do today, with the "conclusion layer" of data, which is > > all they support. I believe that the evidence should be codified into > > "person records" that are structurally very similar to the conclusion > > person records. That is, all your John Smiths should be encoded into > > their own "person records." > > Seems to me that if one chooses to do so, many systems will allow you > to create additional INDI records and merge them when the evidence is > sufficient.  To me, that sounds like they do support what you describe. Not really. The problem you get in most systems is that once you've merged individuals, you lose the ability to see what source actually said. It's often not possible to attach a particular spelling (or variant) of the name to a particular source. If information for a single event derives from multiple sources (e.g. the date of birth and place of birth from separ ate sources), it's often not possible to source those things separately. And trying to properly source relationships is impossible in all the current systems without implying information in the source that's simply not there. Consider the following example, slightly simplified from a real case in my family: * John is the grandson of Thomas. [Source: 1901 census.] * Thomas and Sarah's marriage only had one child. [Source: 1911 census.] * George is the son of Thomas and Sarah. [Source: baptism register.] * Thomas and Sarah were bachelor and spinster when they married. [Source: marriage cert.] * Thomas and Sarah lived into their eighties and were buried together. [Source: gravestone.] Taken together these five pieces of information make a pretty strong case for George as the father of John, as it seems unlikely that Thomas had any children other than George. But none of the sources actually say this. How would you encode this example in GEDCOM? For what it's worth, I thought Tom's post was spot on regarding the deficiencies in the current programs. Richard

On 05-20-2011 21:09, Richard Smith wrote: > single event derives from multiple sources (e.g. the date of birth and > place of birth from separ ate sources), it's often not possible to > source those things separately. Well, with GEDCOM strict, that is true. That's why I try to maintain images of sources when possible. For a long time, my "program" was a text editor, allowing me to do things GEDCOM supported (loosely) and genie programs didn't. Even the most flexible (LifeLines—thank you Thomas!) eventually frustrated me with limitations. But eventually, the file got big enough that the need for assistance overcame the distaste for limitations. Some of the things I did in the text editor were not GEDCOM-compliant in the strictest sense, but WorldConnect had no problem with them. (like attaching sources to dates and places, or putting multiple dates on one event.) -- Wes Groleau There are two types of people in the world … http://Ideas.Lang-Learn.us/barrett?itemid=1157