Ian, > And how do you deal with: > > John, son of William Goddard bapt 30 Jun 1753 > John, son of Jonathan Goddard bapt 16 Sep 1753 > John Goddard, aged 61 buried 24 Dec 1814 > > Clearly the John in the burial (and various other records) could be > either of the first two. It took me years to gather various bits of > circumstantial evidence which, taken together, helped me decide which. > In the interim there is no S/W that I know of which would allow me to > record that I had an adult which could with 50/50 probability be either > of two infants because what's there follows alternative 1 which assumes > I will know who's who & merge the John of one of the baptisms with the > John of the burial with no error - because picking apart erroneous > merges is a complete pain. I have thought about this problem a little bit. First the obvious: In my model I would create 3 persona (evidence person) records for the 3 Johns (and also for the 2 other persons mentioned). Normally I would want to decide which of the first 2 Johns was the same as the 3rd and create a person record that bound those 2 together (in a 2-level record tree). But, if faced with your example, that is, no way to decide, possibly forever, what could you do? One obvious answer would be to put a note in the 3rd John saying that one of the first 2 is the same person but it can't be determined which. Another approach I have considered, and will likely implement in DeadEnds, is to allow the user to create 2 2-tier persons, one joining the 1st and 3rd, and the second joining the 2nd and 3rd, that is allow 1 persona record (the old John) to be joined and appear in TWO person/persona trees. Controversial? Sure, but the software could keep track of the ambiguous state of the persona records, even request that you add notes to the two overlapping person trees to describe the situation. I don't think there is much else one can practically do for your example. Have you any other ideas, given that you could define the software any way you wanted? Tom

Tom Wetmore wrote: > Ian, > >> And how do you deal with: >> >> John, son of William Goddard bapt 30 Jun 1753 >> John, son of Jonathan Goddard bapt 16 Sep 1753 >> John Goddard, aged 61 buried 24 Dec 1814 >> >> Clearly the John in the burial (and various other records) could be >> either of the first two. It took me years to gather various bits of >> circumstantial evidence which, taken together, helped me decide which. >> In the interim there is no S/W that I know of which would allow me to >> record that I had an adult which could with 50/50 probability be either >> of two infants because what's there follows alternative 1 which assumes >> I will know who's who & merge the John of one of the baptisms with the >> John of the burial with no error - because picking apart erroneous >> merges is a complete pain. > > I have thought about this problem a little bit. First the obvious: > > In my model I would create 3 persona (evidence person) records for the > 3 Johns (and also for the 2 other persons mentioned). Normally I would > want to decide which of the first 2 Johns was the same as the 3rd and > create a person record that bound those 2 together (in a 2-level record > tree). But, if faced with your example, that is, no way to decide, > possibly forever, what could you do? One obvious answer would be to > put a note in the 3rd John saying that one of the first 2 is the same > person but it can't be determined which. > > Another approach I have > considered, and will likely implement in DeadEnds, is to allow the > user to create 2 2-tier persons, one joining the 1st and 3rd, and the > second joining the 2nd and 3rd, that is allow 1 persona record > (the old John) to be joined and appear in TWO person/persona trees. > > Controversial? Sure, but the software could keep track of the > ambiguous state of the persona records, even request that you > add notes to the two overlapping person trees to describe the > situation. > > I don't think there is much else one can practically do for your example. > Have you any other ideas, given that you could define the software > any way you wanted? What I'd like to have done would been to have two types of entity. One, with several instances of John (and one each for Jonathan and William) would be for names from records. The other type of entity would be for reconstructions. I'd have a single entity of this type for John Goddard of Burnlee - I'd use suitable epithets to distinguish between this John & Johns of other generations. I'd have link entities between this reconstruction & the various personae. There's good evidence to link John of Burnlee to several baptisms of children at Burnlee & to a marriage so these would all be solid links as well as to the burial. I'd then have further links to the two 1753 baptisms with a 50% probability. As further evidence arrived (in favour of the son of Jonathan as it happens) I could vary the probabilities on these links to reflect my changing view until the wrong link could be dispensed with. This is somewhat similar to your approach but my preference is for two different types of entity because they represent two different types of thing, one's a name of a person and the other's a person. The use of link entities also simplifies things in the long run. They can record the confidence one places in the link and if they include a note field they can also hold the reasoning. Also the creation of a link is easy to reverse, unlike merging. In practice this accumulation of evidence took several years but with the nature of existing software the only way to handle this type of situation seems to be either to record it in some form of note or simply keep track of it mentally. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

Ian, Your two types of records are exactly what I call the persona record and person record. The persona record in the past has been called the "nominal" record for exactly the reason you indicate -- it is the name (plus whatever else info) gleaned from an actual evidence record. (Look up "nominal record linking or linkage on Google for an interesting historical perspective on the beginnings of inferential genealogy.) On the Better GEDCOM wiki the persona record is sometimes called a codified evidence record, since you would normally create them by looking at actual items of evidence and extracting (codifying) information from that evidence in order to create the name/nominal/persona records; In my software I use exactly the same data type for a persona and a person. A "person" is the conclusion person, the record you build up by linking it to persona records. I create multi-tier trees with the persona records at the leaves with a person record at the root (and others in the interior if this is a 3 or more level tree). I create the trees because I never want to destroy my evidence or my conclusions by "flattening" the information in the trees into single records. In nearly all current genealogical software, the person records are nothing more than these flattened, merged records that are nearly impossible to unwind or unmerge. My suggestion was to be able to create these person/persona trees where the same persona record could be in multiple person trees, in your terminology, can be linked to by different person records. This really is exactly the same tree you have when you say you are linking person records to your "name" records. I like your idea of adding estimated probabilities to handle the ambiguous cases. As far as I can tell our desired models are the same. The model is the "DeadEnds" model that I created more than a decade ago as the guide I use in writing my own personal genealogical software. Tom > What I'd like to have done would been to have two types of entity. One, > with several instances of John (and one each for Jonathan and William) > would be for names from records. The other type of entity would be for > reconstructions. I'd have a single entity of this type for John Goddard > of Burnlee - I'd use suitable epithets to distinguish between this John > & Johns of other generations. I'd have link entities between this > reconstruction & the various personae. There's good evidence to link > John of Burnlee to several baptisms of children at Burnlee & to a > marriage so these would all be solid links as well as to the burial. > I'd then have further links to the two 1753 baptisms with a 50% > probability. As further evidence arrived (in favour of the son of > Jonathan as it happens) I could vary the probabilities on these links to > reflect my changing view until the wrong link could be dispensed with. > > This is somewhat similar to your approach but my preference is for two > different types of entity because they represent two different types of > thing, one's a name of a person and the other's a person. The use of > link entities also simplifies things in the long run. They can record > the confidence one places in the link and if they include a note field > they can also hold the reasoning. Also the creation of a link is easy > to reverse, unlike merging. > > In practice this accumulation of evidence took several years but with > the nature of existing software the only way to handle this type of > situation seems to be either to record it in some form of note or simply > keep track of it mentally. > > -- > Ian > > The Hotmail address is my spam-bin. Real mail address is iang > at austonley org uk