Steve Hayes wrote: > On Wed, 25 May 2011 21:36:21 -0400, in soc.genealogy.computing you wrote: > >> singhals wrote: >>> PAF produces a UID for each entry; I'm pretty certain other >>> programs do to, particularly the ones that allow >>> synchronization of multiple databases. >> >> Well color me surprised. >> >> PAF and Legacy both assign a UID, which one can see in the GED. >> >> Oddly enough, and despite what I've heard said, when I >> imported the PAF file into a LEGACY file (direct import, not >> GED), the UIDs changed. Seems to me that's a bit awkward >> for someone trying to use those UIDs for anything. > > What is a UID, and where can I find it? > Unique IDentifier -- new with PAF4 as I recall, and I think inspired by another program that used them. As I recall, we were told that if two people used two computers to enter the same data each computer would generate a different UID for that person. I don't /think/ you can see them anywhere but the GED. The computer can, and in PAF when you run the match/merge routine, it asks if you want to use UID. > I regularly export my data from FHS to Legacy. > > FHS assigns an RID, which Legacy callas a RIN, but if it imports them from the > GEDCOM file, Legacy scrambles them. > > So what I do is import the exported records to PAF 4, and import them directly > from PAF to Legacy. Then the Legacy RINs correspond to the FHS ones. > > But what is the UID? The UID is not a RID/RIN; it is specifically assigned to an individual record and does not mutate when moved around. Cheryl
Tom Wetmore wrote: >> Oddly enough, and despite what I've heard said, when I >> imported the PAF file into a LEGACY file (direct import, not >> GED), the UIDs changed. Seems to me that's a bit awkward >> for someone trying to use those UIDs for anything. > > Cheryl, > > In GEDCOM the UID's (not actually called that by GEDCOM) "belong" to > GEDCOM. That is, a GEDCOM import process is free to change the Uh, the two GEDs I created yesterday called 'em UID. The UID is created by the program when the entry is first made; matching these allows you to be sure you've picked up the right person. 0 @[email protected] INDI 1 NAME ss dd /NAME/ 2 SURN name 2 GIVN ss dd 1 SEX M 1 BIRT 2 DATE 17 Nov 1889 2 PLAC Elstie, Cambria, PA 1 DEAT 2 DATE 14 Oct 1964 2 PLAC Altoona, Blair, PA 1 _UID 59360E835210204B9F0FE0685C9D1B7F7635 1 FAMS @[email protected] 1 FAMC @[email protected] and 0 @[email protected] INDI 1 NAME ss dd /NAME/ 2 GIVN ss dd 2 SURN NAME 1 SEX M 1 BIRT 2 DATE 17 Nov 1889 2 PLAC Elstie, Cambria, PA 1 DEAT 2 DATE 14 Oct 1964 2 PLAC Altoona, Blair, PA 1 _UID 59360E835210204B9F0FE0685C9D1B7F7635 But, I see I erred mentioning it -- I picked up someone else with the same name when I looked at the GEDs. This UID did stay the same, which is what I thought would happen. > id values to anything it likes. You can see why this is needed > because of clashes between the ids on incoming records and the ids > already in the database. Most programs start assigning ids as I1, I2, I3 > for person ids, so if you import two files that were both exported by > the same program, even though the data is completely different, > there will be id clashes to resolve. > You're talking about RINs and internal markers specific to a database. Add someone, delete someone, and the RIN changes. A UID is said to be, er, immutable. > Many people feel they should "own" their ids, and they learn to > navigate through their databases by memorizing a few key ids. > GEDCOM has a solution or this in the REFN tag. The value of > the REFN tag is a user-assigned id value. If your program is > GEDCOM compatible it should allow you to search by REFN values > as well as id values. Of course, if you try to import a GEDCOM file > that has a REFN id that conflicts with one already in your > database, the import process will have to resolve that somehow. Yes, of course. But the UID is neither an RIN nor a REFN. Cheryl
Cheryl, I stand corrected. I was talking about standard GEDCOM. The _UID tag is an extension tag used by some systems. As you say, UID's should be immutable for all time and space. But since it's not a standard tag there's not telling what might happen to it on import to arbitrary programs. Any program that changes its value on import should be taken behind the barn and shot. Tom
"Bob LeChevalier" <[email protected]> wrote in message news:[email protected] > > That is the difference in my approach. I generally don't add someone > to my data base unless I have connected them to at least one other > person in my data base. Unlinked individuals are better dealt with in > a flat table (spreadsheet) than in a relational data base. How do you do that when the data in the record is inadequate to provide linkage? I used to keep my parish register extractions sorted in text files, but it became impossible to find things once the files became significantly large. Imaginr that you have the will of a John Smith which names his sons as William and Thomas. Imagine also that you have a marriage certificate for a Thomas Smith that names his father as John Smith. Clearly on the evidence I've presented they may or may not be the same people. Can you search your text files easily to find all candidates for the Thomas Smith who married, subject to the constraint that his father is called John? If, not having looked at the family for a few years, you later come across a document which confirms that Thomas has a brother William, or a document which suggests that Thomas has no brothers, can you rearrange your thought processes to take this into account? I certainly couldn't. I was going through old bits of paper thinking "I'm sure I decided that these two definitely weren't the same bit I haven't a clue why I thought that at the time". It was only when I started to build up possible persons from the available data that the more obscure coincidences or contadictictions started to jump out at me. So often previously I would build up a person, realise that this person wasn't relevant to my research and discard it. Then I'd do all the same work again a few years later. Now that person stays, fully formed, in my database, and if I can link an otherwise vague document to that person, I can tell, within a trivial amount of time, what the relevance of that document to me is. Steven
There has been some discussion in soc.genealogy.computing about event-based software, and also software for recording evidence. This has come up before, and I still feel the need for such software, and have yet to find it. We are spoiled for choice in lineage-linked programs, but I don't know of any event-based programs that will do what I want - namely to record events, and the people and organisations associated with those events. The links would not necessarily be genealogical, but should include friends, employers, yeachers, pupils, colleagues and even enemies. I think a program that could do this would ne of interest not just to family historians, but also to general historians, biographers and even detecitives (where the "events" could be related to a crime, or a series of crimes, and the "people" would be the suspects and their associates. I've tried to summarise the needs in a blog post at: http://su.pr/2vQjRv and sample database tables are available for download from the files section of the genealogy software forum at: http://groups.yahoo.com/group/gensoft/ I'm reopening this subject because I really would like to see (and be able to use) such a program before I die. -- Steve Hayes from Tshwane, South Africa Web: http://hayesfam.bravehost.com/stevesig.htm Blog: http://methodius.blogspot.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
"Steven Gibbs" <[email protected]> wrote: >"Bob LeChevalier" <[email protected]> wrote in message >news:[email protected] >> >> That is the difference in my approach. I generally don't add someone >> to my data base unless I have connected them to at least one other >> person in my data base. Unlinked individuals are better dealt with in >> a flat table (spreadsheet) than in a relational data base. > >How do you do that when the data in the record is inadequate to provide >linkage? Then I don't add it to the genealogical data base, and it remains in the spreadsheet. (Actually, for one parish, I simply add individuals unlinked, because my experience has been that 90-95% of the records will be linked in eventually as a parent, spouse or child of someone else. But this is a special case even for me.) >I used to keep my parish register extractions sorted in text >files, but it became impossible to find things once the files became >significantly large. That is why I use spreadsheets. The key fields are kept together in a single column, and I can sort or search or select from the entire sheet or a single column. Finding does not seem to be a problem (I have some 7500 vital records for one parish and 6500 for a second, so these aren't small files). >Imaginr that you have the will of a John Smith which names his sons as >William and Thomas. Imagine also that you have a marriage certificate for a >Thomas Smith that names his father as John Smith. Clearly on the evidence >I've presented they may or may not be the same people. Can you search your >text files easily to find all candidates for the Thomas Smith who married, >subject to the constraint that his father is called John? If, not having >looked at the family for a few years, you later come across a document which >confirms that Thomas has a brother William, or a document which suggests >that Thomas has no brothers, can you rearrange your thought processes to >take this into account? I've done a little work in British genealogy, including one line of Smiths, and indeed it is difficult. Alas, I don't accumulate evidence for such lines - if I can't find a link with what is immediately accessible, I simply move on - I have thousands more that I can spend time on. >I certainly couldn't. I was going through old bits of paper thinking "I'm >sure I decided that these two definitely weren't the same bit I haven't a >clue why I thought that at the time". I have occasionally made a text note that indicates that a certain record does NOT apply to a specific someone in my tree, and why it doesn't. >It was only when I started to build >up possible persons from the available data that the more obscure >coincidences or contadictictions started to jump out at me. So often >previously I would build up a person, realise that this person wasn't >relevant to my research and discard it. Then I'd do all the same work again >a few years later. Now that person stays, fully formed, in my database, and >if I can link an otherwise vague document to that person, I can tell, within >a trivial amount of time, what the relevance of that document to me is. If I have a person, fully formed, then likely I have several other people who are definitely attached to him, even though they might or might not be relevant to my tree. Your two Smith examples above, will and marriage certificate, each link (at least) 3 people. You thus have not several individual jigsaw puzzle pieces, but several connected groups of pieces - these tend to be easier to fit, and in any event are meaningful objects of study in themselves. lojbab --- Bob LeChevalier - artificial linguist; genealogist [email protected] Lojban language www.lojban.org
On Wed, 25 May 2011 21:36:21 -0400, in soc.genealogy.computing you wrote: >singhals wrote: >> PAF produces a UID for each entry; I'm pretty certain other >> programs do to, particularly the ones that allow >> synchronization of multiple databases. > >Well color me surprised. > >PAF and Legacy both assign a UID, which one can see in the GED. > >Oddly enough, and despite what I've heard said, when I >imported the PAF file into a LEGACY file (direct import, not >GED), the UIDs changed. Seems to me that's a bit awkward >for someone trying to use those UIDs for anything. What is a UID, and where can I find it? I regularly export my data from FHS to Legacy. FHS assigns an RID, which Legacy callas a RIN, but if it imports them from the GEDCOM file, Legacy scrambles them. So what I do is import the exported records to PAF 4, and import them directly from PAF to Legacy. Then the Legacy RINs correspond to the FHS ones. But what is the UID? -- Steve Hayes from Tshwane, South Africa Web: http://hayesfam.bravehost.com/stevesig.htm Blog: http://methodius.blogspot.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
On Thursday, May 26, 2011 5:09:09 AM UTC-4, Steven Gibbs wrote: > "Bob LeChevalier" <[email protected]> wrote in message > news:[email protected] > > > > That is the difference in my approach. I generally don't add someone > > to my data base unless I have connected them to at least one other > > person in my data base. Unlinked individuals are better dealt with in > > a flat table (spreadsheet) than in a relational data base. > > How do you do that when the data in the record is inadequate to provide > linkage? I used to keep my parish register extractions sorted in text > files, but it became impossible to find things once the files became > significantly large. > > Imaginr that you have the will of a John Smith which names his sons as > William and Thomas. Imagine also that you have a marriage certificate for a > Thomas Smith that names his father as John Smith. Clearly on the evidence > I've presented they may or may not be the same people. Can you search your > text files easily to find all candidates for the Thomas Smith who married, > subject to the constraint that his father is called John? If, not having > looked at the family for a few years, you later come across a document which > confirms that Thomas has a brother William, or a document which suggests > that Thomas has no brothers, can you rearrange your thought processes to > take this into account? > > I certainly couldn't. I was going through old bits of paper thinking "I'm > sure I decided that these two definitely weren't the same bit I haven't a > clue why I thought that at the time". It was only when I started to build > up possible persons from the available data that the more obscure > coincidences or contadictictions started to jump out at me. So often > previously I would build up a person, realise that this person wasn't > relevant to my research and discard it. Then I'd do all the same work again > a few years later. Now that person stays, fully formed, in my database, and > if I can link an otherwise vague document to that person, I can tell, within > a trivial amount of time, what the relevance of that document to me is. > > Steven Steven, That's the strongest argument for the persona method as the way to store evidence that I think I've seen, and you didn't use the word even once! It also sounds like you have solved the merge problem by just not doing any. So I surmise that when you decide that one of your personas ("fully formed" in your terms) is one of your persons of interest you add info from the persona to the person. So when you decide you were wrong you always have the original persona around to help you back out your change to the person record. I think this qualifies as another good approach to answering this thread's question. Tom
On Wednesday, May 25, 2011 9:42:46 PM UTC-4, Bob LeChevalier wrote: > Thinking about this, one simple solution would be to have a > genealogical data base of evidence personas only, and a second > genealogical data base of (generally linked) persons. I suspect that > most genealogical software can import from another data base created > by the same program fairly trivially. (It is drag and drop in > split-screen mode in Legacy). Putting a persona record into your > persons database (and linking or merging them with some other record > there) does not affect your persona data, so destroying an erroneous > merged record isn't a problem (assuming that you have created all your > persons from personas). I agree that this approach would prevent you from loosing you personas when you decide what person a persona belongs to. It would seem that you would still have the unmerge problem (that is, the difficulty of undoing the addition of a persona's data to a person), but with the original personas still around, I bet clever software might be able to figure out the undo. If a new software application were designed to support this idea you wouldn't have to have two databases. I think this ranks as a new answer to this thread's question. Tom
> Oddly enough, and despite what I've heard said, when I > imported the PAF file into a LEGACY file (direct import, not > GED), the UIDs changed. Seems to me that's a bit awkward > for someone trying to use those UIDs for anything. Cheryl, In GEDCOM the UID's (not actually called that by GEDCOM) "belong" to GEDCOM. That is, a GEDCOM import process is free to change the id values to anything it likes. You can see why this is needed because of clashes between the ids on incoming records and the ids already in the database. Most programs start assigning ids as I1, I2, I3 for person ids, so if you import two files that were both exported by the same program, even though the data is completely different, there will be id clashes to resolve. Many people feel they should "own" their ids, and they learn to navigate through their databases by memorizing a few key ids. GEDCOM has a solution or this in the REFN tag. The value of the REFN tag is a user-assigned id value. If your program is GEDCOM compatible it should allow you to search by REFN values as well as id values. Of course, if you try to import a GEDCOM file that has a REFN id that conflicts with one already in your database, the import process will have to resolve that somehow. Tom
Tom Wetmore <[email protected]> wrote: >I wasn't clear enough. The idea I was getting at is this. You have found >an item of evidence that you either copy onto your computer as a file >or you have as a URL text string. You are pretty sure this evidence refers >to a person you are interested in, but you haven't gotten enough info >yet to be sure of this or to know exactly what person it refers to. > >Cheryl made the point that she would keep a link to that file or URL in >a person record in her database. My question was directed to the >situation where you don't yet have such a person record to hold the link. > >My preferred approach is to codify that evidence into new persona >records and let them be sit in the database while you collect more data. >These persona records are indexed and searchable and manipulable >and editable as easily as regular person records. Thinking about this, one simple solution would be to have a genealogical data base of evidence personas only, and a second genealogical data base of (generally linked) persons. I suspect that most genealogical software can import from another data base created by the same program fairly trivially. (It is drag and drop in split-screen mode in Legacy). Putting a persona record into your persons database (and linking or merging them with some other record there) does not affect your persona data, so destroying an erroneous merged record isn't a problem (assuming that you have created all your persons from personas). It isn't quite as useful as the separating function on nsf. But I think it fits what you are describing. lojbab --- Bob LeChevalier - artificial linguist; genealogist [email protected] Lojban language www.lojban.org
singhals wrote: > Tom Wetmore wrote: >> On Wednesday, May 25, 2011 12:40:54 PM UTC-4, Wes Groleau wrote: >>> On 05-24-2011 16:26, Tom Wetmore wrote: >>>> That doesn't solve the problem of where to store those links. As Cheryl >>>> points out, if you put a link in a person record, you are making the >>>> explicit statement that the linked-to evidence refers to that person. >>> >>> Always? Many programs support some variation of GEDCOM's TYPE tag. >>> >>> No reason a link couldn't have a TYPE subrecord, or a NOTE or .... >>> Even if GEDCOM doesn't officially support it. >>> >>> Maybe some software out there somewhere has tried that. >>> >>> (Please don't take my comments as an enthusiastic endorsement >>> of GEDCOM) >>> >> Wes, >> >> I wasn't clear enough. The idea I was getting at is this. You have found >> an item of evidence that you either copy onto your computer as a file >> or you have as a URL text string. You are pretty sure this evidence refers >> to a person you are interested in, but you haven't gotten enough info >> yet to be sure of this or to know exactly what person it refers to. >> >> Cheryl made the point that she would keep a link to that file or URL in >> a person record in her database. My question was directed to the >> situation where you don't yet have such a person record to hold the link. >> > > Then I create a person-record/persona for it. Hence the > dozen or so different entries with a single name. > >> My preferred approach is to codify that evidence into new persona >> records and let them be sit in the database while you collect more data. >> These persona records are indexed and searchable and manipulable >> and editable as easily as regular person records. >> > > Apparently, you're calling what I do "codifying"; I call it > saving. > >> I personally find that this simple mechanism solves all problems >> I have with designing a single system that can seamlessly handle >> both record-based and person-based genealogy. I just need the >> software to give the UI to do this. > > PAF produces a UID for each entry; I'm pretty certain other > programs do to, particularly the ones that allow > synchronization of multiple databases. Well color me surprised. PAF and Legacy both assign a UID, which one can see in the GED. Oddly enough, and despite what I've heard said, when I imported the PAF file into a LEGACY file (direct import, not GED), the UIDs changed. Seems to me that's a bit awkward for someone trying to use those UIDs for anything.
Tom Wetmore <[email protected]> wrote: >> >At my point in genealogical research I have 1000s of records >> >that I haven't been able to assign to real people yet. >> >> As far as I am concerned, they are all assigned to real people. >> Whether I can attach those people to my tree is another question. I >> generally don't enter it into my database until I think such >> attachment is likely if not definite. > >This is pretty close to my point. When you refer to real people that you can't >attach to your tree yet, I would say you're talking about something close to >the persona concept. So to my way of thinking you are storing your evidence >that can't go directly into persons in your tree, into "holding personas". > >This is exactly what I am forced to do with my genealogy program, which I >guess I am now ashamed to say, I wrote (LifeLines). It is chockerblock full >of person records, some the real tree persons, and some my "on hold" evidence >personas. That is the difference in my approach. I generally don't add someone to my data base unless I have connected them to at least one other person in my data base. Unlinked individuals are better dealt with in a flat table (spreadsheet) than in a relational data base. >Except for the fact that I have no user interface mechanism that >allows me to group the personas into persons when I decide how to do it, the >system works middling well. I am still forced to merge, which I now believe >to be the wrong thing to do with personas. With a spreadsheet, you could "combine" records (without merging) by adding a column for a unique combined-person-id, and putting that id in all of the relevant records. You haven't merged them - separating them is merely a matter of erasing the id from the records that no longer seem to fit. A "person record" is merely the set of "persona records" that share a single id (sorting or selecting on values in one column is a basic spreadsheet function. >What do you do when you decide that one of those stand alone persons is the >same as one already in your tree, or if you decide that two of those stand >alone persons are the same person but you still are not ready to add him to >your tree. I have to manually add the data at that point. But I have to manually add the data at some point. I just don't do it until I have someone ready to be linked. >I assume you have to merge data, that is reduce the number of >your person records. I occasionally have to merge persons, especially since the data I am working on now often circles back to families I have already added, and I don't realize that two people I have added are the same person until I look at the index of persons (actually, I let the program look for dupes). But these persons being merged are already not-raw data. lojbab --- Bob LeChevalier - artificial linguist; genealogist [email protected] Lojban language www.lojban.org
Wes Groleau <[email protected]> wrote: >On 05-25-2011 11:20, Bob LeChevalier wrote: >> Their stinky data is merely the old IGI, PRFs and AFs (along with new >> stuff that is being constantly added, and which is generally better). > >Welll, .... > >One of the collections is images of marriage records where a column on >the left is "date license issued" and a column on the right is "date of >marriage." Both columns legibly labeled, yet the index consistently >reports the left one as date of marriage, even when the right one >legibly says "license returnedmarriage did not occur." Supposedly, if it is a consistent error, you can contact someone with specifics, and they'll fix it. It sounds like you are talking about one of the new databases on the search site, rather than the lineages on new.family.search.org >This makes all of the other collections suspect, since most of them >offer the indexes onlyno verification possible. > >Another one estimates the date of birth from the date of death, even >though the record _and_ the index has the actual date of birth stated. You definitely seem to be talking about databases of transcribed records here. Even such problems are trivial compared to some of the people in the lineages with 5 different first names, born in 5 different states and sometimes multiple countries, married to several people, some who were dead before they were born, and others simultaneously in multiple states, and listing someone as a son who is also one of their 5 different fathers. lojbab --- Bob LeChevalier - artificial linguist; genealogist [email protected] Lojban language www.lojban.org
On 05-25-2011 15:25, Tom Wetmore wrote: > Personally I think that the LDS should scrap all the data in the nFS tree > and then pre-load it with personas created from high-quality data > taken from vital records, censuses, and other sources from which it > is possible to derive quality, sourced, personas. Then don't allow Unfortunately, the records I complained about were created by volunteer indexers from images digitized from microfilm. Obviously there is a quality control inadequacy. They aren't in a "tree" -- Wes Groleau There are two types of people in the world … http://Ideas.Lang-Learn.us/barrett?itemid=1157
Tom Wetmore wrote: > >>> Cheryl made the point that she would keep a link to that file or URL in >>> a person record in her database. My question was directed to the >>> situation where you don't yet have such a person record to hold the link. > >> Then I create a person-record/persona for it. Hence the >> dozen or so different entries with a single name. > > I agree. > >>> My preferred approach is to codify that evidence into new persona >>> records and let them be sit in the database while you collect more data. >>> These persona records are indexed and searchable and manipulable >>> and editable as easily as regular person records. > >> Apparently, you're calling what I do "codifying"; I call it >> saving. > > Codify simply means to be systematic. To create those persona records you > have to take information found in evidence and systematically create > persona records from it. > >>> I personally find that this simple mechanism solves all problems >>> I have with designing a single system that can seamlessly handle >>> both record-based and person-based genealogy. I just need the >>> software to give the UI to do this. > > What's not mentioned here, is what happens with the personas when > you decide who they are. The usual answer is to 1) merge the data in > the persona record into the person record if the person record > already exists; or 2) create the first version of a new person record > from the persona record. Merging is key. This is the main thing I > object to. I want the personas to maintain their integrity/identity for > all time, since they are the extracted from of original evidence. This > is why I replace the merging operation with a tree-building > operation. This tree is not the genealogical pedigree tree, it is > the tree of records that represent the same person. The leaves of > this person tree are the persona records. The other nodes are the > person records. WHY would I want to keep them separate once I've decided they're the same person? My bc, my mc, and my son's bc all refer to ME as ME; what would be the POINT of keeping ME in there 3 times? Cheryl
Tom Wetmore wrote: > On Wednesday, May 25, 2011 12:40:54 PM UTC-4, Wes Groleau wrote: >> On 05-24-2011 16:26, Tom Wetmore wrote: >>> That doesn't solve the problem of where to store those links. As Cheryl >>> points out, if you put a link in a person record, you are making the >>> explicit statement that the linked-to evidence refers to that person. >> >> Always? Many programs support some variation of GEDCOM's TYPE tag. >> >> No reason a link couldn't have a TYPE subrecord, or a NOTE or .... >> Even if GEDCOM doesn't officially support it. >> >> Maybe some software out there somewhere has tried that. >> >> (Please don't take my comments as an enthusiastic endorsement >> of GEDCOM) >> > Wes, > > I wasn't clear enough. The idea I was getting at is this. You have found > an item of evidence that you either copy onto your computer as a file > or you have as a URL text string. You are pretty sure this evidence refers > to a person you are interested in, but you haven't gotten enough info > yet to be sure of this or to know exactly what person it refers to. > > Cheryl made the point that she would keep a link to that file or URL in > a person record in her database. My question was directed to the > situation where you don't yet have such a person record to hold the link. > Then I create a person-record/persona for it. Hence the dozen or so different entries with a single name. > My preferred approach is to codify that evidence into new persona > records and let them be sit in the database while you collect more data. > These persona records are indexed and searchable and manipulable > and editable as easily as regular person records. > Apparently, you're calling what I do "codifying"; I call it saving. > I personally find that this simple mechanism solves all problems > I have with designing a single system that can seamlessly handle > both record-based and person-based genealogy. I just need the > software to give the UI to do this. PAF produces a UID for each entry; I'm pretty certain other programs do to, particularly the ones that allow synchronization of multiple databases. Cheryl
> WHY would I want to keep them separate once I've decided > they're the same person? My bc, my mc, and my son's bc all > refer to ME as ME; what would be the POINT of keeping ME in > there 3 times? > > Cheryl Cheryl, You don't have yourself three times. You have yourself once. You just have separate records, if you want, for your birth, marriage, residence, and your own record refers to these. I know you think this doesn't make any sense with respect to yourself or your parents or grandparents or great grandparents. Nobody does. That it would even be crazy. You have to get over the hurdle of thinking about the people you know and the people it is easy to find by following a clear trail of vital records or census records or similar records. These problems with evidence only come to the fore when you are far enough back, and into the realm of uncertainty, that when you find evidence about people with names you might be interested in, you don't know enough yet whether the people really are the people you are looking for. That is the evidence that has to be worried about. There is no person in your database you can add that information to, because you haven't figured out who the people are yet. Say you have found 400 records like this. The question I am asking is what are you going to do with those 400 items of evidence so you can quickly search them, arrange them, and use them to help you make your conclusions about who the people really were?" We have gotten some very good answers to that question on this thread. I have my own preferred answer, which is just one of many that are being described here. My answer is to create persona records for each item of evidence and add those persona records to my database. Then when I decide that one of those persona records really does refer to one of the persons I am interested in I make the record of that person refer to that persona record. I don't want to merge the data in for two very good reasons: 1. I might be wrong and want to undo the merge. Undoing a merge is very messy, especially after multiple merges have happened. 2. I want the persona to be a codified representation of the real evidence. I want it to be a record in my database that contains exactly and only the information about a person that came from one item of evidence. There are many programs that allow you to create all the persona records you want in the guise of extra person records. Basically all of them. But when you decide that two of your records are the same person you HAVE to merge them. Well, the only exception I am aware of is the New Family Search Tree, that explicitly supports personas and persons. So you have the multiple persona records as the result of difficult research and not wanting to muddle your evidence. For people easy to research you can be as sloppy as you want. Tom
On 05-25-2011 04:25, Tom Wetmore wrote: > Given that a genealogical application does not support evidence it seems like It's still not a given to me. > askSam is almost ideal as the "second program" to handle evidence. > > I would sure like those askSam capabilities built into my genealogy app so I > didn't have to move back and forth between two program. I might be > naive, but I don't think it would be difficult to add the capabilities to a > genealogy app. Every genealogy record can be viewed as a tree of > structured name/value pairs (just think of any GEDCOM, XML, or jSON The basic search in webtrees (and probably other apps) is pretty much a full text search, with advanced having specific name/value pairs. (We had to add a little code to discard hits on ID fields)) -- Wes Groleau There are two types of people in the world … http://Ideas.Lang-Learn.us/barrett?itemid=1157
> > Cheryl made the point that she would keep a link to that file or URL in > > a person record in her database. My question was directed to the > > situation where you don't yet have such a person record to hold the link. > Then I create a person-record/persona for it. Hence the > dozen or so different entries with a single name. I agree. > > My preferred approach is to codify that evidence into new persona > > records and let them be sit in the database while you collect more data. > > These persona records are indexed and searchable and manipulable > > and editable as easily as regular person records. > Apparently, you're calling what I do "codifying"; I call it > saving. Codify simply means to be systematic. To create those persona records you have to take information found in evidence and systematically create persona records from it. > > I personally find that this simple mechanism solves all problems > > I have with designing a single system that can seamlessly handle > > both record-based and person-based genealogy. I just need the > > software to give the UI to do this. What's not mentioned here, is what happens with the personas when you decide who they are. The usual answer is to 1) merge the data in the persona record into the person record if the person record already exists; or 2) create the first version of a new person record from the persona record. Merging is key. This is the main thing I object to. I want the personas to maintain their integrity/identity for all time, since they are the extracted from of original evidence. This is why I replace the merging operation with a tree-building operation. This tree is not the genealogical pedigree tree, it is the tree of records that represent the same person. The leaves of this person tree are the persona records. The other nodes are the person records. Tom