On 2011-05-22 22:05, Tom Wetmore wrote: > On Sunday, May 22, 2011 3:55:21 PM UTC-4, Peter J. Seymour wrote: >> I feel that you are approaching the topic from an intensely theoretical >> way (which is not necessarily a bad thing) while Gendatam is an existing >> system producing practical results (well certainly for me). We may >> therefore be seeing things in different ways. > > My intentions are intensely practical and not theoretical -- how to design a usable genealogical application to support the full genealogical research process. I accept we see things in different ways, and if we spent the effort needed we would finally understand each others' point of view! > >> For instance, the Person record in Gendatam is a type of persona in that >> it is mutable and while on the one hand not inextricably tied to a >> specific position in a tree (and therefore may be seen as not the same >> as a true person) it is nevertheless tied to Evidence records to the >> extent that the user has provided them. > > There is some misunderstanding here as a hallmark of a persona record is its immutability. Sorry, loose wording on my part - it is the linkage to the specific tree position which can be easily changed. This allows flexibility in diverting the set of data represented by a Person record from one real person to another if required. That was my point. I believe in some other programs the two cannot be separated. >>> This highlights a feature of >> Gendatam, it is not Person-based, it is not Event-based, it is not >> Evidence-based, but it is all or any of these depending on how you >> choose to look at it. > > This is a powerful idea and accommodates both different styles as both the preferred way of working by different genealogists, but also different styles as dictated by the different sources of information one works with. > >> Gendatam provides for the >> extraction of selected evidence data into new records, but I do not see >> that the makes the program "conclusion based". It is rather a way of >> highlighting and enabling analysis of particular pieces of evidence data. > > In my example of the 75 records I was trying to understand exactly this. How would I use Gendatam to extract the evidence from those 75 source records, and where where would I put it and in what format would I put it into Gendatam records? My point was, that if I understood the answer to that question I would be able to make a judgement about Gendatam's conclusion orientation. > I'm not sure I can advise you much further on this one. Gendatam does not require a set way of working. You would use it as a tool to explore the data, it does not offer a magic solution. You need to understand what your data might in principle provide, what in practice the data would probably provide and what sort of end result you want to achieve. It will not do the work for you (except for automation of some routine tasks). One aspect I find helpful is that it can highlight what data is missing. The general approach is that new data would if possible be entered as Evidence Records, but if you do not have the data in a substantive evidential form you might instead (as a "temporary" measure) enter it directly for instance as a Person record with a name or as an Event Record with a type and a date, etc. Evidence records are processed by extracting data to generate other record types. The purpose of data extraction rather than in-situ linking is to allow the possibility for you to generate those records even if there are no relevant evidence records, as suggested above. Once you have generated the possible records (which would be linked in various ways), the end result is to be able to run a report or chart showing a collection of related people. The overall process would be iterative where it may be possible to achieve successive refinements (clarification of existing data, adding extra data etc). I do admit this allows scope for cheating by adjusting the data to give the result you want, but I do not see any way of avoiding that exposure in the process. It is really a case of try it and see. That may provide ideas, both positive and negative. Hope that helps. Peter

This thread is an offshoot from the Linux thread that is going off on a number of tangentsl. How should we store evidence in genealogical databases? You get a marriage record in the mail; you find an image of a census record at Ancestry.com; you find the record of an event on a page in a book you found on Google books. What are you going to do with those three records? Here are some possible answers. First, if you are careful genealogists, you're going to record the source of the records in your database as source records. Got that out of the way. Second, as far as the "physical records" are concerned, let's say you carefully file the paper marriage record away in your paper filing system, and you go to your big ancestry folder area on your computer and keep copies of those two images. Dandy. Now, what are you going to do with the information in those three physical records (let's say we can call those image files "physical" for sake of argument). Here's the "normal" answer in my opinion. You look at the physical records, you decide who the persons were who are mentioned in those records, you go you your genealogy program and you find the appropriate person records, creating them if need be, and you edit in the new information. In other words you extract information from the physical records and you add that information directly to person records. Note that the information from the physical records only enters into your database as items inside person records. Here's another possibility advocated by some genealogists. After you create the source records for where the physical records came from, you edit those source records, adding to them the information that you got from those sources that you believe is important. You probably have to do this as "unstructured notes." Then you link persons to those sources and you also "copy up" from the stuff you added to the source records into the person records. Here's another possibility advocated by programs like Gramps for Family Tree Maker. You first create event records from information in the physical records, say a birth or death or marriage events, and then you add a link from some person in your database, creating that person record if need be, to that event record. The events really don't stand alone; you have to link person records to them. All these techniques work fine while you are in the realm of "person-based genealogy" or "conclusion-based genealogy". When in this realm you either already know whom the people are that you are researching, or you have such a solid vital record and other record trail back to them that you can be sure whom you are researching. You know whether any particular record belongs to a person you are researching or not; you ignore the records that don't, and you simply copy information out of the records that do. In my opinion 98% of the genealogical software is devoted to people working in this mode. Eventually every genealogist reaches the point when he or she has delved far enough back in time that the solid, firm trail of records has dried up. When we reach this point our task changes from one of simply elaborating persons we know or can learn about easily, to one of true historical research. We embark on the chore of trying to find whatever sources we can, from whatever creative recesses of our minds or experience takes us. From the sources we manage to find, we have to keep whatever information that mentions people that might eventually be of interest to us, and we must record that information somehow so we can continually be able to refer to it. We have faith that at some time in the future we will have found enough records that we'll be able to figure out who all those people are and how they are related. At that time, maybe far in the future, maybe after many serendipities in our record searching, we'll be able to finally create new persons in our database and add the hard fought information to them. When we reach this point we are in the realm of "record-based genealogy." This has been described as "crossing a chasm." We are now true historians. We must collect lots of records, but we don't know yet whom they belong to. What are you going to do with this evidence? If you use some of the approaches above you're kind of stuck. You can add paper copies to your files, or images files to your computer, but what else are you going to do? There are no people records around to stick them to. You can bloat source records with notes, but how can you find any of that unstructured info in the future? To do your research effectively, to be able to reason about the data you've collected, you have to have some way of finding the information and arranging it. Are you going to do this by spreading sheets of paper on your desk, keeping lots of windows to image files open on your computer, taking lots of notes on 3x5 cards, sketching out possible family groups with paper and pencil? Wouldn't you want all that evidence information codified somehow inside your genealogy program so you can search for names, search for dates, search for places, see the relationships mentioned in the evidence, and so on? How would you want your genealogy application to support you after you have "crossed the chasm?" I have my answers to these questions, but I'll stop at this point. I hope you'll think about this. What would your dream software system to do support you? Say you collected 100 records that mention people with interesting names, that is, names that might be those of persons you are interested in. Because you are so far back and time, in the fog of uncertainty, you don't yet know who the real persons mentioned in those 100 record are, but you have reason to believe that some of them will be the persons you are looking for, and that some of those people are probably mentioned many times in those records. How do you want to record those 100 records so you can work with them to decide who the real persons were? Do you want them somehow in your genealogy program? Do you want that information not to be in your genealogical database until you feel you know who they were? What features or requirements would you want your genealogical software to have or meet to handle this evidence and facilitate your ability to work with it? Tom

singhals <[email protected]> wrote: >Have you been shown the members-only part of the >newfamilysearch databases? If you have not, I /urge/ you to >find a Mormon who will show you his own family there. >They eschewed the notion of "merge" for the more seductive >"combine" which, frankly, works no better than "merge" in >the hands of the hurried except that with "combine" you can >sometimes see who last did what. And... except that the source personas that went into the merge are not destroyed, and... that it is possible to uncombine, or to extract multiple personas from a combined record (indeed this is vital for some of the "combined" monstrosities of the 18th century and earlier, some of which have a half dozen names, a half dozen different parents and a half dozen different spouses, all contradictory, and 50 different birthplaces because a lot of non-standardized locations were in the various personas that were "combined"). >The results of that push me deeper into a belief that you've >got to plump for Yes it is/No it isn't at some point and >that point may as well be now, since you're never going to >get proof-absolute or even *all* potentially pertinent data >(since as has been said here before, data has the >uncomfortable habit of popping up where it has no earthly >reason to be ...). I have several times in the new-LDS data said "yes it is" and then had to go back a few days later and undo, because I found evidence that "no it is not". I have also had to extract a few sources that have been "combined" from a monstrosity. It is not hard to do directly, but it has to be done on the site - the Legacy interface that I use for most of my work does not support separations from a combined record (though one can extract individual data elements from a record to one's Legacy tree persona and then add that persona as a new one to the LDS data - that is generally a pain to do, though). lojbab --- Bob LeChevalier - artificial linguist; genealogist [email protected] Lojban language www.lojban.org

On 2011-05-22 03:47, Tom Wetmore wrote: > Peter, > > I've read all the Gendatum pages, and now I don't think you called me out. Maybe you can convince me. I don't see any good way that Gendatum can handle the persona concept, which in my mind is the hallmark of handling record-based genealogy. > > A persona is "codified evidence," that is, all the information that can be gleaned about a single person from a single item of evidence. It becomes a record in a database that is indexed, that can be searched for and indexed by name, that can be searched for and indexed by any date that might be mentioned in the evidence, that can be searched for and indexed by any place mentioned in the evidence, that can be searched for and indexed by any property of the person mentioned in the evidence. > > Does Gendatum handle these kinds of records? These are not the Gendatum concept of a person record, since those records are supposed to represent real persons, in other words, "conclusion persons" as I mentioned before. Looking at the diagram of the Gendatum model and reading the documentation in detail, I can't see how these kinds of records can be added to the database. > > Let me ask it this way. Say you collected 75 records about persons with names you were interested in, but you didn't yet know if they were the persons you were interested in. What could you do with Gendatum with respect to those 75 records? I assume you would want to be able to access all the information in those records quickly by computer, so you wouldn't want them just as paper copies or as image files. I assume you would want them codified in some way as records in your database, so you could search through them, sort them, group them into different groups and arrangements as you hypothesized about the real persons they might represent. What would you do with this information to help you do your reasoning and help you make your conclusions? > > I believe that how this question is answered defines whether a genealogical application is "just" conclusion based, or whether it also supports the evidence part of genealogy. As I said, most genealogical applications don't give you a good way to support this kind of evidence data. What you are "supposed" to do with nearly all genealogical program today, is to look at the physical evidence, then automatically know as if by magic exactly what real person that evidence applies to, and then simply add whatever new information you learned about the person from that evidence to the proper person record in your database. So evidence only appears in your database as attributes of other records. > > If Gendatum answers the question this way, and it looks to me like it does, then it is a conclusion-based system pretty similar to the others. But if Gendatum has a way to add those 75 records in such a way that the genealogist can truly use them, reason about them, rearrange them, build them into real person records, then I'd agree that Gendatum "crosses the chasm" (as this problem has been characteristic on the Ancestor Insider blog). > > I'd recommend that people read the "Crossing the Chasm" blog entries, as this is exactly the "first requirement" that was brought up by Richard Smith in the original post on this thread. > > Tom Wetmore I feel that you are approaching the topic from an intensely theoretical way (which is not necessarily a bad thing) while Gendatam is an existing system producing practical results (well certainly for me). We may therefore be seeing things in different ways. For instance, the Person record in Gendatam is a type of persona in that it is mutable and while on the one hand not inextricably tied to a specific position in a tree (and therefore may be seen as not the same as a true person) it is nevertheless tied to Evidence records to the extent that the user has provided them. This highlights a feature of Gendatam, it is not Person-based, it is not Event-based, it is not Evidence-based, but it is all or any of these depending on how you choose to look at it. Gendatam is a work in progress and in due course I expect it to make better use of the Assertion records which link Evidence to other records. It already has an interesting feature which attempts to automatically construct records from the data contained in Evidence records, such as Birth Certificates (Eg an extraction might involve Record type PERSON John Smith EVENT was born on DATE 1st Jan 1900 ADDRESS at 13 High Street, PERSON Mother was.... etc). The question was actually about the hypthetical 75 records. Suppose that I had concluded that the records were worth investigating, they could be entered firstly as independent records. I could then seek to draw conclusions about the relative merits of these records from seeing them tabulated and presented in a standard way. Gendatam provides for the extraction of selected evidence data into new records, but I do not see that the makes the program "conclusion based". It is rather a way of highlighting and enabling analysis of particular pieces of evidence data. The truth is that conclusions of various types must be drawn at numerous stages along the way,so the idea of "conclusion based" seems to me not a very useful one. There is clearly a question of emphasis. Peter

On 2011-05-22 11:07, Ian Goddard wrote: > Peter J. Seymour wrote: >> >> In my experience merging should be regarded as a one-way process, if >> you do it, you need to be confident you will not want to revert. > > Coming from a scientific background I have real problems with this view. > Any conclusion is simply the holder's best summary of available data at > the time. It is open to being falsified by better data becoming > available and hence the required confidence you mention must be lacking. > I suppose it depends on the extent to which a can of worms is being created. A difficulty with geneological data is that merged data may be built on by new data and so an improper merge may end up contaminating more than just the records immediately involved. There may be no clean way of backing out. On the other hand, if caught early it may be possible to backout tidily. Peter

On Sunday, May 22, 2011 3:55:21 PM UTC-4, Peter J. Seymour wrote: > I feel that you are approaching the topic from an intensely theoretical > way (which is not necessarily a bad thing) while Gendatam is an existing > system producing practical results (well certainly for me). We may > therefore be seeing things in different ways. My intentions are intensely practical and not theoretical -- how to design a usable genealogical application to support the full genealogical research process. I accept we see things in different ways, and if we spent the effort needed we would finally understand each others' point of view! > For instance, the Person record in Gendatam is a type of persona in that > it is mutable and while on the one hand not inextricably tied to a > specific position in a tree (and therefore may be seen as not the same > as a true person) it is nevertheless tied to Evidence records to the > extent that the user has provided them. There is some misunderstanding here as a hallmark of a persona record is its immutability. >>This highlights a feature of > Gendatam, it is not Person-based, it is not Event-based, it is not > Evidence-based, but it is all or any of these depending on how you > choose to look at it. This is a powerful idea and accommodates both different styles as both the preferred way of working by different genealogists, but also different styles as dictated by the different sources of information one works with. > Gendatam provides for the > extraction of selected evidence data into new records, but I do not see > that the makes the program "conclusion based". It is rather a way of > highlighting and enabling analysis of particular pieces of evidence data. In my example of the 75 records I was trying to understand exactly this. How would I use Gendatam to extract the evidence from those 75 source records, and where where would I put it and in what format would I put it into Gendatam records? My point was, that if I understood the answer to that question I would be able to make a judgement about Gendatam's conclusion orientation. Tom

On May 22, 4:59 pm, Tom Wetmore <[email protected]> wrote: > I advocate two changes to the nFS system. First, don't have two datatypes, just go for a > single one for both evidence persons and conclusion persons. Second, don't have any limits > on the tiers. Yeah, most times there will be only two tiers, three rarely, and more probably > never. Buy why limit it when it matches the way we think. There are a few situations where I can imagine wanting three tiers. I often mentally group a person's personae into two parts: those from their childhood (e.g. their birth, baptism, and appearing on censuses with their parents); and those from their adulthood (e.g. marriage, the birth and baptism of their children, and appearing on censuses with their spouse and children). I often find it easy to group childhood personae together, and to group adult personae, but much harder to workout which child grows up to become which adult. So I can imagine wanting to use one tier to represent personae which are almost certainly the same person and a second tier for less certain identifications. Another example is if some secondary/tertiary source has already compiled several personae into an individual, and you want to take that, document the origin of the grouping, and then build on it yourself. So yes, I think multiple levels would be good, but really it's the ability to have two that's critical. Richard

On May 22, 10:46 am, "Peter J. Seymour" <[email protected]> wrote: > In my experience merging should be regarded as a one-way process, if you > do it, you need to be confident you will not want to revert. Unfortunately, that's true in a lot of software, and it is one of the biggest reasons why a lot of existing software is inadequate for serious research. How can I possibly be certain that I've correctly associated the personae mentioned in various source records into the correct individuals? Sometimes the evidence is obvious and it's unlikely that I'll want to unmerge the individuals. But often, especially in earlier times, the research process is a continual cycle of finding new evidence and re-evaluating earlier conclusions. Software that can't cope with that is worse than useless -- without the software, you'd go through that process manually, but with existing software, you can't easily do the re-evaluation part of the cycle at all. Richard

On May 22, 10:34 am, Ian Goddard <[email protected]> wrote: > Nick Matthews wrote: > > I will be adding GEDCOM export/import for transfer to/from other programs, but I > > am not anticipating "round trip" accuracy, the idea will be to create a > > new database from a GEDCOM file and then attach it to your working > > database. > > Doesn't this give you problems?  You've designed the database to make a > distinction between the personae of original records and the conclusions > reached from them.  GEDCOM, AFAIK, makes no such distinction.  So are > you going to export just one of these categories or both?  How are you > going to tell the recipient?  And, most difficult of all, where are you > going to import a GEDCOM received from someone else? I guess you support both types of import (and export), and rely on out- of-band information -- i.e. information supplied with the GEDCOM file, but not in it -- to state which type of import is required. If I've downloaded a list of, say, IGI entries from FamilySearch.org, I probably have them in GEDCOM, and they're very definitely of the former type: each INDI is a persona. But if someone gives me a GEDCOM of their family, then this will be the latter type: each INDI really is a unique person, the result of merging many personae. Given that GEDCOM is, and, pragmatically, is likely to remain for some time, the most standard means of exchanging genealogical information, the ability to import and export both forms seems likely to be useful. If it were acceptable to move outside strictly-compliant GEDCOM, then maybe either a FORM value other than LINEAGE-LINKED, or a sub-tag to the FORM tag could be used to state which model is intended. Richard

On 22/05/2011 10:34, Ian Goddard wrote: > Nick Matthews wrote: >> I will be adding GEDCOM export/import for transfer to/from other programs, but I >> am not anticipating "round trip" accuracy, the idea will be to create a >> new database from a GEDCOM file and then attach it to your working >> database. > > Doesn't this give you problems? You've designed the database to make a > distinction between the personae of original records and the conclusions > reached from them. GEDCOM, AFAIK, makes no such distinction. So are > you going to export just one of these categories or both? How are you > going to tell the recipient? And, most difficult of all, where are you > going to import a GEDCOM received from someone else? > There's two ways of looking at this, firstly the program will allow you to enter family trees in the same way as any other program, "conclusion first" and add the supporting evidence later, or secondly, the GEDCOM file is also a "reference document" like any other and is, in itself, evidence. You may take the first approach if you are using a GEDCOM as the start of a new database, whilst the second would be useful if you just want add parts of someone else's tree. A quick note on reference documents, ideally they would fit on a single sheet of paper. Whilst there's no actual limit on size, if the document is large the user should consider creating a summary to work from or breaking it down into extracts. It shouldn't be shouldn't be too difficult for program to automatically break a gedcom down to manageable bits, the user can then select which bits they want to copy across to their database. Nick

Tom Wetmore wrote: > Today's programs don't allow it. Some, like Gramps, have an event record that can be used for the "eventa" concept (see my recent response to Peter), but not an independent (e.g., never merged or modified) "persona" concept. > > The question is, do we need/want the codified evidence records as separate records in our databases or not? My answer is a resounding yes. There are many opponents to the idea, however. One camp, represented by some of the Better GEDCOM contributors, believe that evidence, if it be codified into our databases at all, should be included within the source record of the source that the evidence came from, maybe codified ("marked up") or maybe just as unstructured notes. This is better than nothing, but evidence in that form is very hard to compute with. I think an event is a valid concept between evidence & persona. In many cases there will be a 1:1 relationship between evidence & event (if one discounts implied events). However, consider an evidential statement such as "William Brown's wife Mary died giving birth to their son John on 2 May 1738". This single piece of evidence records two events, the birth of the child and the death of the mother. Note also that Mary has two roles, as deceased in the death and as mother in the birth. To hold this we need a structure which imposes both event and role between evidence and persona. Note also that the statement implies a third event, the marriage of William and Mary. It's very much vaguer - no date except for 2 May 1738 as a /terminus ad quem/, no surname for Mary and no assurance that it actually happened, they may just have been living as man and wife. So it would be a matter of the user's discretion as to whether to add this to a database. However, if we do add such records then a great many records which seem to be 1:1 with events become 1:2. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

Tom Wetmore wrote: > As Wes pointed out, there is nothing preventing a user of "ordinary" programs creating separate persons for each "evidence person" and then merging them into the final person later when they decide who is who. This is what I have to do with my program now. The problem with this approach is that once you merge you loose your research history. We need nondestructive merges, which I believe is best done by just building up trees of person records. Have you been shown the members-only part of the newfamilysearch databases? If you have not, I /urge/ you to find a Mormon who will show you his own family there. They eschewed the notion of "merge" for the more seductive "combine" which, frankly, works no better than "merge" in the hands of the hurried except that with "combine" you can sometimes see who last did what. The results of that push me deeper into a belief that you've got to plump for Yes it is/No it isn't at some point and that point may as well be now, since you're never going to get proof-absolute or even *all* potentially pertinent data (since as has been said here before, data has the uncomfortable habit of popping up where it has no earthly reason to be ...). My genie program of choice has a free-form text section, into which I put my research notes (ie, birthyear extrap from census; month from census; day of month from tombstone; marriage name & date from copy of certificate; death from tombstone), and then when I merge two people, I also merge these notes, which creates a nice trail and enables me to see why I thought something (or didn't think so). Cheryl

Peter J. Seymour wrote: > > In my experience merging should be regarded as a one-way process, if you > do it, you need to be confident you will not want to revert. Coming from a scientific background I have real problems with this view. Any conclusion is simply the holder's best summary of available data at the time. It is open to being falsified by better data becoming available and hence the required confidence you mention must be lacking. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

Nick Matthews wrote: > On 21/05/2011 11:39, Ian Goddard wrote: >> Also, you have integers as PKs in the database design. This is the most >> efficient way to glue the tables together internally but if it's to meet >> the data exchange aim you need something in the external representation >> which will be unique across databases such as UUID/GUIDs. >> > I've yet to be convinced on the usefulness UUID/GUIDs, I'm never sure > what they're supposed to show. Facts should be linked to their source > and conclusions linked to the person who made them - anything else seems > to vague. > The advantage of UUIDs as part of an immutable record is that you can instantly disregard duplicates. And from that you can de-weight what might otherwise appear to be a consensus of opinion but which is just a single statement being repeated. Let me give you an instance. If you go to the old family search site and search for the baptism of Jonathan Goddard, 1779, you will get multiple hits (two IIRC) giving the mother's name as Christiana. You will also get multiple hits for the baptism of Christiana, the previous year. What I suspect has happened in each case is that one person has made a mistake re 1778, drawn an incorrect conclusion re 1779 & others have blindly copied them. If there had been a means of attaching UUIDs to original postings and copying them it would have been clear. As things stand would you believe apparently multiple claims to the above vs a single statement that the baptism of Jonathan did not give the mother's name and an alternative conclusion that it was Mary? -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

On 2011-05-21 22:15, Tom Wetmore wrote: > Peter, > > I do tend to hyperbole, so thanks for calling me out! > > The Gramps program allows you to add "events" to a database in a standalone manner (I believe). Later you can link those events to the persons. It's still a "person-based" system. > > As Wes pointed out, there is nothing preventing a user of "ordinary" programs creating separate persons for each "evidence person" and then merging them into the final person later when they decide who is who. This is what I have to do with my program now. The problem with this approach is that once you merge you loose your research history. We need nondestructive merges, which I believe is best done by just building up trees of person records. > > I will look up the Gendatam program. Thanks for the tip. > > Tom Wetmore In my experience merging should be regarded as a one-way process, if you do it, you need to be confident you will not want to revert. An inappropriate merge can be impossible to recover from without removing and re-entering amounts of data. A halfway house would be to have links or groups to bring the relevant records together in a controlled way. How much further you go depends on how purist you want to be about data and reasoning trails. I am all for working to eliminate such links by merging. The merge doesn't (or shouldn't) destroy the original evidence although it may discard some of the deductions made along the way. However, I am not offended by unmerged records. Peter

On May 22, 12:08 pm, Nick Matthews <[email protected]> wrote: > A quick note on reference documents, ideally they would fit on a single > sheet of paper. Whilst there's no actual limit on size, if the document > is large the user should consider creating a summary to work from or > breaking it down into extracts. The main example of a longer reference document that I can think of is a will. When I'm transcribing a will, I try to resist the temptation to summarise it, as there have been plenty of times when the seemingly- irrelevant information I would have omitted has turned out to be useful. On one occasion, I established that the farm left to a son in a 18th century will was the same farm whose copyhold was held a century earlier by someone of the same surname according to the manorial records. On another the particular church where the person chose to be buried turned out to be the village he had likely grown up in, and where his parents were from. Richard

Nick Matthews wrote: > I will be adding GEDCOM export/import for transfer to/from other programs, but I > am not anticipating "round trip" accuracy, the idea will be to create a > new database from a GEDCOM file and then attach it to your working > database. Doesn't this give you problems? You've designed the database to make a distinction between the personae of original records and the conclusions reached from them. GEDCOM, AFAIK, makes no such distinction. So are you going to export just one of these categories or both? How are you going to tell the recipient? And, most difficult of all, where are you going to import a GEDCOM received from someone else? -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

> I think an event is a valid concept between evidence & persona. In many > cases there will be a 1:1 relationship between evidence & event (if one > discounts implied events). > > However, consider an evidential statement such as "William Brown's wife > Mary died giving birth to their son John on 2 May 1738". This single > piece of evidence records two events, the birth of the child and the > death of the mother. Note also that Mary has two roles, as deceased in > the death and as mother in the birth. To hold this we need a structure > which imposes both event and role between evidence and persona. > > Note also that the statement implies a third event, the marriage of > William and Mary. It's very much vaguer - no date except for 2 May 1738 > as a /terminus ad quem/, no surname for Mary and no assurance that it > actually happened, they may just have been living as man and wife. So > it would be a matter of the user's discretion as to whether to add this > to a database. However, if we do add such records then a great many > records which seem to be 1:1 with events become 1:2. > > -- > Ian Ian, Again, I agree. I think there are three ways that event/relationship information should be able to "get into" our databases, and the three ways stem from the contexts in which the information is given: 1. If we get simple information about a vital event about a person (birth, death), then this info can be just added as an attribute of the persona. This is the GEDCOM approach. In my many posts on this subject I call this a "vital event" even though it's not really an event record per se. 2. If we get simple information about a relationship between two people (father, mother), then we just link the two persona records together with a link that carries as an attribute the type of relationship. 3. If we get detailed event information, with place, date, all the major role players, then we go whole hog and create an actual event record and persona records for all the role players. We link the personas to the event with role references and vice versa. The relationships are inherent in the roles and can be inferred by software. Let me analyze your evidence statement: "William Brown's wife Mary died giving birth to their son John on 2 May 1738". First there are three personas, William Brown, Mary ____, and John Brown. Since the three are named in the context of the birth, I would create an independent birth event with the three persons as role players in them. Since the word wife was used, but no details about the actual marriage are given, I would not create an independent marriage event. But I would link William Brown to Mary with a spouse link and vice versa. The point being the relationship implies the event just fine. Software can count this as a marriage just as easily as if there were a marriage event. Lastly I would add a "death vital event" directly to Mary, that is, not create an independent event for her death. I would add the cause of her death as being childbirth. And since I'm a good little researcher I also need to create a source record that says where the evidence statement came from, with the other records linking to it. In summary, I'd have records that look like this, here expressed in a JSON-like syntax: persona: {id: i1; name: William Brown; role: {type: father; event: e1}; relation: {type: spouse; person: i2}; source: s1} persona: {id: i2; name: Mary; role: {type: mother; event: e1}; relation: {type: spouse; person: i1}; death: {date: 2 May 1738; cause: childbirth}; source: s1} persona: {id: i3; name: John Brown; role: {type: child; event: e1}; source: s1} event: {id: e1; type: birth; date: 2 May 1738; role: {type: father; person: i1}; role: {type: mother; person: i2}; role: {type: child; person: i3}; source: s1} source: {id: s1; ... attributes of the source ...} In my humble opinion this is the optimal way to capture all the information in Ian's evidence statement as codified persona records, with an event record with the common event data, and a source record to document where the evidence comes from. All the pertinent facts are captured here and all are immediately amenable to computer processing, computer display, and so forth. Tom

On Sunday, May 22, 2011 11:24:22 AM UTC-4, singhals wrote: > Tom Wetmore wrote: > > > > As Wes pointed out, there is nothing preventing a user of "ordinary" programs creating separate persons for each "evidence person" and then merging them into the final person later when they decide who is who. This is what I have to do with my program now. The problem with this approach is that once you merge you loose your research history. We need nondestructive merges, which I believe is best done by just building up trees of person records. > > Have you been shown the members-only part of the > newfamilysearch databases? If you have not, I /urge/ you to > find a Mormon who will show you his own family there. > They eschewed the notion of "merge" for the more seductive > "combine" which, frankly, works no better than "merge" in > the hands of the hurried except that with "combine" you can > sometimes see who last did what. > > The results of that push me deeper into a belief that you've > got to plump for Yes it is/No it isn't at some point and > that point may as well be now, since you're never going to > get proof-absolute or even *all* potentially pertinent data > (since as has been said here before, data has the > uncomfortable habit of popping up where it has no earthly > reason to be ...). > > My genie program of choice has a free-form text section, > into which I put my research notes (ie, birthyear extrap > from census; month from census; day of month from tombstone; > marriage name & date from copy of certificate; death from > tombstone), and then when I merge two people, I also merge > these notes, which creates a nice trail and enables me to > see why I thought something (or didn't think so). > > Cheryl Cheryl, I did manage to get a New Family Search account and have worked with it a little bit. The problem with that system is simply that it is filled to overflowing with trash data. nFS uses the persona concept, but they have no way to enforce the idea that a persona comes from an item of evidence. Most of their personas are just stuff extracted from somebody's junk. I don't think you can draw any real conclusions about the persona idea from the way nFS was implemented. Note that nFS is a two-tiered system -- there is a datatype for persona and there is a datatype for person, and they are different. Personas are grouped into persons, and the user can select which persona to use for each of the important life events for the person. in other words, the user can choose which persona gets to be the "birth persona", which gets to be the "death" persona, and so on. However, there is no way a user can patch up persons when they get married off to the wrong persons! By and large I think the nFS approach with personas and persons is a quantum leap in the right direction. Their implementation of the idea might be lacking, and their choice of "stocking the tree" with garbage was an incredibly wrong thing to do, but the idea is right in my humble opinion. Just imagine the great world we would have if instead they stocked the tree with personas created from all the vital records they have, from all the census records they have, all the military records they have. We would start with a wonderful universe of personas extracted from the primary records of the world. Not to open too many pandora's boxes at once, but I also believe that if you can start with this universe of personas, you can take advantage of automatic combination algorithms to do a lot of the grouping of personas. I advocate two changes to the nFS system. First, don't have two datatypes, just go for a single one for both evidence persons and conclusion persons. Second, don't have any limits on the tiers. Yeah, most times there will be only two tiers, three rarely, and more probably never. Buy why limit it when it matches the way we think. Tom

On Mon, 16 May 2011 05:03:04 -0700 (PDT), Richard Smith <[email protected]> wrote: >On May 16, 8:20 am, "Peter J. Seymour" <[email protected]> >wrote: > >> This set me wondering: How large do single trees get? So here is a >> challenge for you all, What is the largest single-tree gedcom you are >> aware of, does it consist of sensible data, and more to the point how >> large is it (File size in bytes and number of individuals, both metrics >> are needed please? > >If you google for 'BUELL001.GED' you'll find a large GEDCOM file by >someone called Matthew James Buell. It is about 3MB and contains >about 9,900 individuals, virtually all of whom are related. (It's a >descent from the biblical Adam, so clearly parts of it are dubious.) >I'm sure I've seen larger databases, though I'm not sure I can point >you to one at the moment. But this one seems to have become a fairly >standard test database for applications as it's large enough that it >can starts hitting scalability issues and diverse enough to include a >large range of dates and nationality. I have something like 15500 individuals in my database, nearly all of whom are related in some way to my children. The exceptions are mostly the children of unrelated spouses -- if A is the relation and has children by B, then those children are related, but if B has children by C, those children are not related. I have sometimes included those. -- 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