Note: The Rootsweb Mailing Lists will be shut down on April 6, 2023. (More info)
RootsWeb.com Mailing Lists
Total: 2/2
    1. Re: How Should We Store Evidence in Genealogical Databases?
    2. Steven Gibbs
    3. When I started a one-place study about ten years ago, I decided that standard software didn't do the job I wanted. So I wrote my own. Over the years I've developed the ideas into something fairly coherent, but, since I'd rather be getting on with data input than coding, the execution leaves a lot to be desired, and I'd do a lot different if I was starting from scratch. Basically, I really only have two types of object, persons and documents. I input a document and create a new persona for each name in the document. Then I check each persona to see if I am comfortable about merging it into an existing person. The only real linkage is that each person has a father and a mother. I treat names as attributes of a person, and estimate other attributes algorithmically, such as estimated date of birth. By clicking on a name I can bring up a complete list of documents referring to that person, and I can open multiple persons at any one time, allowing easy comparisons. An example is given as an appendix. I can search easily on multiple parameters - it's no problem to get a list of everybody with a spouse called Jane, a mother called Mary, and a connection to Cardington, for example. At the moment I have only coded up specific types of documents with fixed formats such as census records, parish registers and civil registration indexes. (Note that this is English research.) I haven't quite worked out a design for freeform text such as wills, but I would expect it to be something along the lines of delineating names, places and occupations with tags. I didn't cater easily for unmerging persons. If I need to unmerge a person, I have to create a new person for every original persona in the documents for a person, unlink any parents and children and then remerge each of the personas again. If I was starting again, I'd keep a record of each merge so I could recreate the last two persons that were merged, as experience shows that it's usually the most recent merge that was in error. Steven Appendix: Example of screen output. >From this I can easily see that I haven't found a baptism for Joseph (but it looks as though it should be at Cople), and that I haven't seen the marriage record - personally, I'm not bothered about the lack of sourcing for this, since it's a private project, but if I was to give this data to anyone I'd ensure that the IGI batch number I used was included. I can also easily see that there is a problem with the age of his daughter Sarah. I note that he's living with his sister Mary Ann, so that if I can confirm parentage for Joseph, I would hope to be able to confirm parentage for Mary Ann, or vice versa (while being aware that they might only be half-brother and -sister). Joseph's estimated birthdate of 1817 shows in the index, but not in the output. Joseph BRIMLEY _________________________________________________ Father: James BRIMLEY _________________________________________________ 1841 Census: Cardington, Bedfordshire Piece: HO107/9 Folio: 13 Page: 20 Dwelling: Joseph BRIMLY 25 M Bedfordshire Occ: Wheelwright Elizabeth BRIMLY 25 F Bedfordshire _________________________________________________ Joseph BRIMLEY Marriage Registered Q2 1841 at Bedford Registration District _________________________________________________ 24 May 1841: Marriage at St John, Bedford, Bedfordshire. Joseph BRIMLEY to Elizabeth WELLS Joseph BRIMLEY Age: Condition: Occupation: Son of James BRIMLEY, Elizabeth WELLS Age: Condition: Occupation: Daughter of Joseph WELLS, _________________________________________________ 1851 Census: Cardington, Bedfordshire Piece: HO107/1752 Folio: 262 Page: 18 Dwelling: Joseph BRIMLEY M 33 M Cople, Bedfordshire Rel: Head Occ: Wheelwright Elizabeth BRIMLEY M 33 F Harrold, Bedfordshire Rel: Wife Sarah BRIMLEY U 9 F Cardington, Bedfordshire Rel: Daughter Mary Ann BRIMLEY U 37 F Cople, Bedfordshire Rel: Sister _________________________________________________ 1861 Census: Cardington, Bedfordshire Piece: RG9/992 Folio: 53 Page: 22 Dwelling: (partial entry - boarder) Joseph BRIMLEY M 43 M Cople, Bedfordshire Rel: Head Occ: Wheelwright Elizabeth BRIMLEY M 43 F Harrold, Bedfordshire Rel: Wife Occ: Wheelwright's wife Sarah BRIMLEY U 12 F Cardington, Bedfordshire Rel: Daughter Occ: Scholar Mary Ann BRIMLEY U 47 F Cople, Bedfordshire Rel: Sister _________________________________________________ 1871 Census: Cardington, Bedfordshire Piece: RG10/1545 Folio: 33 Page: 10 Dwelling: Bedford Road Joseph BRIMLEY M 53 M Cople, Bedfordshire Rel: Head Occ: Wheelwright Elizabeth BRIMLEY M 53 F Harrold, Bedfordshire Rel: Wife Mary COWLAND U 22 F Wilstead, Bedfordshire Rel: Boarder _________________________________________________ 1881 Census: Cardington, Bedfordshire Piece: RG11/1624 Folio: 43 Page: 7 Dwelling: 1 Church Side Joseph BRIMLEY M 63 M Cople, Bedfordshire Rel: Head Occ: Wheelwright Susannah BRIMLEY M 61 F Willington, Bedfordshire Rel: Wife Mary COWLAND U 32 F Wilstead, Bedfordshire Rel: Boarder Occ: Companion Dom _________________________________________________ 30 September 1886: Burial at Cardington, Bedfordshire Joseph BRIMLEY, aged 69. _________________________________________________ Joseph BRIMLEY Death Registered Q3 1886 at Bedford Registration District Age: 69 _________________________________________________ Known children:- Sarah (1841/1848) _________________________________________________

    05/23/2011 06:47:11
    1. Re: How Should We Store Evidence in Genealogical Databases?
    2. Tom Wetmore
    3. On Monday, May 23, 2011 7:47:11 PM UTC-4, Steven Gibbs wrote: > When I started a one-place study about ten years ago, I decided that > standard software didn't do the job I wanted. So I wrote my own. Over the > years I've developed the ideas into something fairly coherent, but, since > I'd rather be getting on with data input than coding, the execution leaves a > lot to be desired, and I'd do a lot different if I was starting from > scratch. > > Basically, I really only have two types of object, persons and documents. I > input a document and create a new persona for each name in the document. > Then I check each persona to see if I am comfortable about merging it into > an existing person. The only real linkage is that each person has a father > and a mother. I treat names as attributes of a person, and estimate other > attributes algorithmically, such as estimated date of birth. By clicking on > a name I can bring up a complete list of documents referring to that person, > and I can open multiple persons at any one time, allowing easy comparisons. > An example is given as an appendix. > > I can search easily on multiple parameters - it's no problem to get a list > of everybody with a spouse called Jane, a mother called Mary, and a > connection to Cardington, for example. > > At the moment I have only coded up specific types of documents with fixed > formats such as census records, parish registers and civil registration > indexes. (Note that this is English research.) I haven't quite worked out > a design for freeform text such as wills, but I would expect it to be > something along the lines of delineating names, places and occupations with > tags. > > I didn't cater easily for unmerging persons. If I need to unmerge a person, > I have to create a new person for every original persona in the documents > for a person, unlink any parents and children and then remerge each of the > personas again. If I was starting again, I'd keep a record of each merge so > I could recreate the last two persons that were merged, as experience shows > that it's usually the most recent merge that was in error. > > Steven > Steven, Very nice. I'm working on a similar solution. I handle the unmerge problem by never really merging. Instead of merging I build up a tree of person records. If I decide two personae refer to the same person I create a new person record that simply refers to the two personae. I can add a justification to that new record to explain the rationale for joining. If I decide later that the personas refer to different people, I just delete the higher level person. I let the higher level person inherit facts from the lower level personae. This works fine unless there is some conflict in the facts in the different personae. If there are I let the person know which persona to use for which fact. I don't have different data structures for the persona and person, so there is no reason to restrict these "person trees" to just two levels. I like this approach because at the leaves of the trees we have all the personae, and at all other levels we have persons that were created explicitly because of some conclusion I came to as the result of analyzing all the evidence, and I can document that analysis at that point. The issues I am working through are really those of finding a user interface that makes these idease easy to work with. In summary, there are now four answers to my question that have appeared on this thread: 1. Use paper. 2. Use special associative or full text indexed databases (e.g., askSam). 3. Use spreadsheets. 4. Use roll-your-own software based on a persona concept. This is great; thanks. Tom

    05/23/2011 11:37:20