Tom Wetmore <[email protected]> wrote: >Bob, > >I've used nFS and read all the API documentation. They have personas >and persons and the user interface allows you to rearrange >personas within persons. It's a two-tier system. I think it's a great >example of how personas can be made to work. I think their data is >pretty stinky, but that has no bearing on the technique in my opinion. 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). A lot of that old IGI stuff was pretty bad, but they had the option to throw everything away, or keep it and find ways to weed out the bad over time. They seem to be trying the latter, and in most cases it is working. They haven't solved the problem of what to do when someone 20 or 50 years ago conflated two people that weren't related, and recorded that conflation as a "fact". At some point they will possibly decide that certain "personas" aren't salvageable, and remove them. (I have the impression that they can and will do so now, but it is on a record by record basis after being presented with documented evidence.) >>> Eventually every genealogist reaches the point when he or she has delved >>> far enougback in time that the solid, firm trail of records has dried up. > >> I don't ever expect to reach that point. But then my genealogy has >> never been confined to direct ancestors. Try to find all the >> descendants of some ancestor born around the time of the revolution. >> Every single one of those descendants is a cousin, and in many >> families that task alone might take a lifetime. > >What I think you are saying is that you never plan to have to cross the chasm >from person-based genealogy to record-based genealogy. On the contrary, I have had to do some of what you call "record-based genealogy" in the 20th century (especially since many records for "living" persons are locked up), and my French work is back in the 17th century and is entirely record-based. But I never found a chasm to be crossed. Lots of little roadblocks, but they only affect one person or one record out of a zillion lines. When you reach the point where there are no records at all, then there is a chasm. I put no priority on trying to cross them. I have ancestors in pre-Revolution Russia and the Ottoman empire, but no significant likelihood in my lifetime to get access to records that I can use (though they might exist). So I've chosen other pursuits, mostly not for my own family, directly. >The whole genealogical application business, in my opinion, caters to people who >believe that. I think it caters to people who are interested in tree structures rather than source data as an organizing principle. Because that is what sells enough to warrant "catering". >Obviously from all I've written about this, I don't believe >that. 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. The source records I either leave where they lie (because I don't give a damn about building a pile of paper that no one including me will ever look at). Or in some cases, build spreadsheets for my extractions therefrom - I don't need a genealogical application for that. I would not imagine that there is would be any general solution for the problems of organizing records of random types that does not involve linking them together in SOME way, or possibly in MANY ways. >Here is my overall genealogical project. I descend from Loyalist Wetmores >who were exiled to Canada at the end of the American Revolutionary >War. By the 1850s many of the children and grandchildren of those >families were returning to the United States where the economy was >stronger. I descend from one of those returning families. My project >is to understand that return migration by finding all the families who >were involved, what their patterns of migration were, where they >ended up, and where all their descendants are living now. This is a >full research project. It is definitely a record-based project. You can >probably understand my needs for effective ways to record all my >evidence so I can access it in many ways to support the process of >making conclusions. But the ways you want to organize such evidence is not genealogical (i.e. not based on family relationships), because you don't KNOW the family relationships. You want a genealogical application to do a fundamentally non-genealogical task. >You might argue that this project is not a genealogical project, but >rather a historical project, so I have no business expecting a >genealogical application to be able to support me. I don't see it that >way. I believe that genealogy is history, and the farther back in >time we go, the more we have to act like historians to make >progress. I want a genealogical application that can support what >I am doing with this project. While one can consider genealogy a branch of history, once you leave the realm of family relationships, it is no longer genealogy. The market isn't there for such a general application covering historical projects as opposed to genealogical ones, in part because every "historical project" is different both in goals and in methods. If that were not the case, then professional historians would be using such applications. (some of them might be, but you'd have to consult such a professional historian). lojbab --- Bob LeChevalier - artificial linguist; genealogist [email protected] Lojban language www.lojban.org

On Wednesday, May 25, 2011 11:20:59 AM UTC-4, Bob LeChevalier wrote: > Tom Wetmore <[email protected]> wrote: > >Bob, > >What I think you are saying is that you never plan to have to cross the chasm > >from person-based genealogy to record-based genealogy. > > On the contrary, I have had to do some of what you call "record-based > genealogy" in the 20th century (especially since many records for > "living" persons are locked up), and my French work is back in the > 17th century and is entirely record-based. But I never found a chasm > to be crossed. Lots of little roadblocks, but they only affect one > person or one record out of a zillion lines. > When you reach the point where there are no records at all, then there > is a chasm. I put no priority on trying to cross them. I have > ancestors in pre-Revolution Russia and the Ottoman empire, but no > significant likelihood in my lifetime to get access to records that I > can use (though they might exist). So I've chosen other pursuits, > mostly not for my own family, directly. > I disagree. The chasm doesn't occur when you run out of records; it occurs when you cannot automatically assign the records you find to a real person yet. > >The whole genealogical application business, in my opinion, caters to > >people who believe that. > > I think it caters to people who are interested in tree structures > rather than source data as an organizing principle. Because that is > what sells enough to warrant "catering". Agreed. > >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. 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. I am working on a new application now where I use drag and drop to manipulate persona records in person records. I'll be using this to experiment with the mutli-tiered person tree approach. If I can't find a user interface metaphor that makes working with the data easy to comprehend I will likely be forced to conclude that the "person tree" concept, as beautiful as I think it is, just isn't practical for the real world. 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 assume you have to merge data, that is reduce the number of your person records. I don't like this because I think of the persona records as being a codification of evidence. Of course, you don't have to think of it that way. > The source records I either > leave where they lie (because I don't give a damn about building a > pile of paper that no one including me will ever look at). Or in some > cases, build spreadsheets for my extractions therefrom - I don't need > a genealogical application for that. I agree with the former, but think that genealogical applications can do more for you than spreadsheets can. > I would not imagine that there is would be any general solution for > the problems of organizing records of random types that does not > involve linking them together in SOME way, or possibly in MANY ways. Well, for doing genealogy there aren't that many kinds of record types you have to deal with. I'd add persona, event, place to the list, and maybe have a catch-all object for everything else. > >Here is my overall genealogical project. I descend from Loyalist Wetmores > >who were exiled to Canada at the end of the American Revolutionary > >War. By the 1850s many of the children and grandchildren of those > >families were returning to the United States where the economy was > >stronger. I descend from one of those returning families. My project > >is to understand that return migration by finding all the families who > >were involved, what their patterns of migration were, where they > >ended up, and where all their descendants are living now. This is a > >full research project. It is definitely a record-based project. You can > >probably understand my needs for effective ways to record all my > >evidence so I can access it in many ways to support the process of > >making conclusions. > > But the ways you want to organize such evidence is not genealogical > (i.e. not based on family relationships), because you don't KNOW the > family relationships. You want a genealogical application to do a > fundamentally non-genealogical task. But I'm trying to discover the family relationships. It's not complicated how I want to organize the data -- by name, by names of parents if known, by names of spouses and children when known, by important event dates and places when known. These are exactly the same properties that any genealogists wants any of his records organized by. > >You might argue that this project is not a genealogical project, but > >rather a historical project, so I have no business expecting a > >genealogical application to be able to support me. I don't see it that > >way. I believe that genealogy is history, and the farther back in > >time we go, the more we have to act like historians to make > >progress. I want a genealogical application that can support what > >I am doing with this project. > > While one can consider genealogy a branch of history, once you leave > the realm of family relationships, it is no longer genealogy. Technically, I agree. Practically I don't think it matters much. There is no real difference in my mind between researching persons for the purpose of finding their family tree, versus researching them for the purpose of finding out as much about them and their milieux as possible; one just goes a little further, but the process of finding records and reasoning from them is the same. > The market isn't there for such a general application covering > historical projects as opposed to genealogical ones, in part because > every "historical project" is different both in goals and in methods. > If that were not the case, then professional historians would be using > such applications. (some of them might be, but you'd have to consult > such a professional historian). I agree there isn't a market, but not for the reason you give. Historical projects do have different goals, but their methods are identical and easily supported by software. The methods are search for records, extract evidence from the records, reason about the evidence you have found, make and justify conclusions based on the evidence and your reasoning, and publish your findings. There are certainly lots of record types, and searching for them and extracting evidence from them can be pretty unique, but there is nothing different between projects in the overall process or in the fact that a single software application could support them all. I just think the market is small because it is small! Tom Wetmore

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

"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