Louis Kessler’s Behold Blog

Well I snuck a new version in, and no, it’s not an April fools joke.

It includes one small fix for a particular type of date that rarely occurs but two people have now encountered it. It’s bad because it causes Behold to be unable to read the GEDCOM file and gives an Access Violation and crashes.

The type of GEDCOM date that causes the problem is:

2 DATE INT 1861 ()

That is an interpreted date and the parenthesis is supposed to contain the text that is interpreted. In this particular case, there is no text, and when I check in Behold what is in the first character, it gives the Access Violation because it is looking in memory that is a no-no.

Unfortunately, the way Delphi (my programming language) handles this is with an exception to the program which crashes it. I can turn these access violation checks off, but it’s not a good idea because it indicates that something is being done wrong and needs to be fixed. I can turn it off in the release versions, but then the program may crash anyway but without being able to tell what the cause was.

Behold has very few of these type of crashes left in it. This was a rarely used date construct that was not output correctly (by RootsMagic in this case because GEDCOM requires at least 1 character between the parenthesis) and I hadn’t encountered it before in my testing.

The solution is easy for me. Before I check what is in the first character, I simply need to ensure that there is at least 1 character. It’s a fairly trivial fix and this is one bit of code where I had just missed making that fix. But now it’s done.

The reason why it’s version 1.0.4.3 was because I earlier had privately released version 1.0.4.1 (which improved sorting of Unicode fonts) and 1.0.4.2 which had this bug fix. 1.0.4.3 removed a bit of the sorting code that was doubling the time Behold was taking to load.

This 1.0.4.3 version is not a required download. You probably won’t notice anything whether you have it or don’t have it.

What I’m really working on and still promise to get to you as soon as possible, is version 1.1. The Life Events are coming together. That along with the ages and sorting of events and consistency checking, will make this a very important release.

Hopefully by the end of April (and I hope that’s not an April fool’s joke either).

I have to make a decision on how to implement some aspects of the Life Events that are going into Behold. I’ve run upon a couple of places where GEDCOM isn’t clear. I thought I’d document them here for the benefit of other developers and for future consideration in any future standard.

The lines in GEDCOM 5.5.1 under consideration are these:

The order in which GEDCOM lines are written to a GEDCOM file is controlled by the context and level number. When the lines are of equal level number but have a different tag name then the order is not significant. The occurrence of equal level numbers and equal tags within the same context imply that multiple opinions or multiple values of the data exist. The significance of the order in these cases is interpreted as the submitter’s preference. The most preferred value being the first with the least preferred data listed in subsequent lines by order of decreasing preference. For example, a researcher who discovers conflicting evidence about a person’s birth event would list the most credible information first and the least credible or least preferred items last.

Systems that support multiple fields or structures should allow their users to indicate their information (the first occurrence listed) and store the remaining information as an exception, preferably within an appropriate NOTE field or in some way that the patron has ready access to the less-preferred data when viewing the record.

Conflicting event dates and places should be represented by placing them in separate event structures with appropriate source citations rather than by placing them under the same enclosing event.

What this means is that if you have two conflicting sets of information for an event, such as a birth event, then there should be separate event structures for them, e.g.:

1 BIRT
2 DATE 1880
1 BIRT
2 DATE 1870

Presumably you’d have more information with each including the full dates, the places, your sources and notes about each bit of evidence. Because of the GEDCOM rule, the first of the two would be considered the preferred, i.e. most credible date.

This is all fine and good for events like Birth and Death that, other than extremely extended circumstances (e.g. brought back from a coma, or science fiction), normally occur only once in any person’s life.

The trouble is that almost any other event can occur multiple times in a person’s life: adoption, naturalization, census, education, retirement. There have been people who have had multiple baptisms and even multiple burials.

This results in a problem. For events other than Birth and Death, if the events are represented like the 4-line GEDCOM example above, how do you tell if they are two different events of the same type, or if they are two sets of conflicting information about the same event?

The answer is, you can’t. GEDCOM does not explain how to distinguish the difference.

Therefore, in Behold, I’ll be going out on the limb and assuming multiple events listed are different events, except in the case of births and deaths where they’ll represent conflicting information for the same event.

You can see some of my earlier discussion about this when I was first considering the ordering of events.

—

That got me to wonder about marriages. The marriage event is considered to be the other “important” event in pure genealogy (not family history) research. Surely, people will want to show conflicting sets of marriage information.

Using the reasoning above, a person may get married multiple times. So a marriage is not a unique event in a person’s life. And the above reasoning says you cannot distinguish whether two MARR tags refer to one marriage or to different marriages.

But marriages are different because they are not associated with a individual (INDI) record. Instead they are associated with two people via a FAM record.

The FAM record was unfortunately misnamed as people always refer to it as a family of a husband and wife and their children. I’ll leave the definition of a “family” for some other discussion. Instead I’ll refer to what GEDCOM says about the FAM record:

The FAMily record is used to record marriages, common law marriages, and family unions caused by two people becoming the parents of a child. There can be no more than one HUSB/father and one WIFE/mother listed in each FAM_RECORD. If, for example, a man participated in more than one family union, then he would appear in more than one FAM_RECORD. The family record structure assumes that the HUSB/father is male and WIFE/mother is female.

So a FAM record is really a union of two people becoming the parents of a child. Whether or not they get married is irrelevant. Whether or not there is no more than one male and one female parent is technically irrelevant (there can be same-sex couples adopting a child) but GEDCOM requires it (Boooo).

By this definition, there can be one FAM record for every child. It’s a mosh-posh because events about the two parents (engagement, residence, census, divorce) are included with the FAM record. If there was a FAM record for every child, the two parents would be repeated multiple times and which one would you assign their combined events to? So the general implementation adopted by most developers is that one union with all their children would be put together in a single FAM record.

Now my question: What happens if two people break up and then get together again? There may be a second marriage event for the same two people. Does that go into one FAM record, or do you create two FAM records with it?

This is a key question. If you create one FAM record, then there can be more than one marriage event in the record and you will no longer be able to tell conflicting marriage information apart from two separate marriage events. But if they go in two FAM records, then there will be only one marriage event per FAM record.

What about the children from the remarriage? The children will be full brothers and sisters with those from the first marriage since they have the same parents. That reasoning would suggest just having one FAM record.

But there may be an intervening marriage with someone else in between, which could also result in children. Should there then be 3 FAM records or only 2.

The answer again is that again GEDCOM doesn’t help you and tell you how to do this. So the developers all had to decide for themselves.

Tamura Jones suggested to me that I test this out myself with some of the more popular genealogy programs and see what they do. Do they accept the data either way? Do they then output the data the same way? Maybe I can generalize a “best practice” from this.

So I built a tricky little 84 line GEDCOM file that I’ll try on several programs. It’s got Guy Main who marries Gal One and has MarriageOne Child. They divorce and he marries Gal Two and has MarriageTwo Child. The end of their marriage isn’t described but he then remarries his first wife Gal One again and they have MarriageThree Child. Just for fun, each of the three families has two marriage dates, a preferred date and an alternate date, and the one divorce also has a preferred date and an alternate date. Onto Guy Main, I’ve also added a preferred and alternate birth date and two census dates that shouldn’t be treated as preferred and alternate, but as two separate events.

Hmm. In setting this up, I ran it through Behold. Behold finds no problems with the GEDCOM file. However, I noticed some things the most recent version of Behold does wrong in displaying this file that’s already been fixed in my development version.

For a second check, I ran the GEDCOM through Tim Forsythe’s VGedX program. It complains only about too few ADDR tags, but I think that is wrong on VGedX’s part. And I ran it through Tim Forsythe’s Bonkers program, which says there’s no problems.

Now let’s see how some other programs handle it:

1. PAF 5.1.7.0

No errors reported on import.

- Treats the first birth date and first marriage date as the preferred one.
- Lists 3 spouses. (That’s when you click an “Other Marriages” button that is misnamed and should say “All Marriages”).
- Guy Main lists 3 other events: The alternate birth and the two census events.
- Notes are shown together for Guy Main, rather than on each event. Bad!
- Gal One marriage has alternate marriage and 2 divorces but dates are missing.
- Notes are shown together for marriage, rather than on each event. Bad!
- Exported marriages correctly.
- Exported preferred marriage date only. It did not export the divorce date, but somehow got it messed up because of the notes added to the marriage and divorce events. Bad!

Attempting to add another marriage of Guy Main to Gal One gives a message box saying: “Gal One-2 is already in a marriage with Guy Mail-1. Do you want to create another marriage for them anyway?” This indicates that PAF prefers separate FAM records for remarriages of the same couple.

Conclusion: PAF understands preferred birth dates and preferred marriage dates but does not designate them as such. A remarriage is better as a separate FAM because PAF may mess up multiple marriages within one FAM.

2. RootsMagic 4.0.9.7

Nothing mentioned in its .lst file after import.

- Treats the first birth date and first marriage date as the preferred one.
- Lists 3 spouses.
- Guy main shows all events in date order. This is confusing because there are 2 births, 2 census and 6 marriages listed. You can’t tell which is primary and which is alternate here.
- Exports events in date order. It loses the preferential birth and marriage. Bad!
- Exports lots of extra junk in its default GEDCOM. 651 lines long. Bad!

Attempting to add another marriage of Guy Main to Gal One gives a message box saying: “These two people are already linked as a couple. If they were married twice to each other you can add a second marriage fact.” and it won’t let you add it! This indicates that RootsMagic must think the alternate marriage date is in fact a separate marriage event.

Conclusion: RootsMagic indicates it prefers one couple married twice to be two events under the same couple. RootsMagic does not handle alternate marriage dates but thinks of those as separate marriage events. It really doesn’t handle preferred and alternate birth dates either.

3. Legacy 7.5

The import box is sloppy and displays: “Individuals:6” without a space between the colon and the 6. That is just sloppy. But no messages are displayed.

- Legacy understands preferred and alternate birth events and lists the latter as an “Alt. birth” event. Excellent!
- Census events are listed as two separate events.
- Legacy understands preferred and alternate marriage and divorce events and lists them as such. Excellent!
- Unfortunately, Legacy has the first marriage set to preferred obviously to indicate who to include in reports. Is there such a thing as a “preferred” marriage? The wording “preferred” is inappropriate here.

Attempting to add another marriage of Guy Main to Gal One gives a message box saying: “Gal One [2] is already his wife. Do you want to link her again?” but it allows you to and creates a new FAM record.

Conclusion: Legacy understands preferred and alternate events the way GEDCOM may have intended. It thus prefers additional marriages to be in separate FAM records so that marriage and divorce dates within one.

4. Family Tree Maker 2008 (sorry, I don’t have a newer version).

I had the GEDCOM file marked as GEDCOM 5.5.1, so FTM gave the message: “GEDCOM file must be version 5.5 or greater” and would not read it. So I changed the 5.5.1 to 5.5 and reimported the file. No errors in the log file.

- FTM as did the other programs, correctly treated the first event as primary.
- FTM show the birth and marriage and divorce events and displays which are preferred. This, like Legacy, is the way GEDCOM may have intended it.
- FTM merges the info about Guy Main’s marriages to Gal One together, indicating its understanding that this is the same person who Guy Main remarried. This is excellent as none of the other three programs denoted this.
- However, the two Census events were listed with the first one as preferred. This is bad since it doesn’t indicate an understanding that there may be more than one event of this type.
- Although FTM tried to indicate its “smarts” about knowing that it married Gal One twice, on the Relationships page, it indicates that Gal One is now “Spouse – Divorced” and Gal Two is “Spouse – Ongoing” which is wrong, since Gal One has been remarried since the divorce. If FTM noted the order of the FAMS tags, it would have got this right.
- Exported the alternate birth first and the primary birth second. Bad.
- Exported only one of the two marriage and divorce dates. Bad.
- FTM 2008 crashed once while I was picking another tab in it.

Attempting to add another marriage of Guy Main to Gal One gives a message box saying: “These people cannot be attached because one of them is already in a direct relationship of the other.” And it won’t let you do it. This is despite its seeming understanding that that Guy Main married Gal One twice. Since FTM recognizes primary marriages and forces you to put a remarriage under the same person, the other marriages will have to be non-primary and you will no longer be able to tell if they are alternatives of the same marriage, or a real new marriage. Too bad.

Conclusion: At least FTM indicates the primary event. But it does everything else wrong.

Overall Conclusion: This is one horrible exercise to do. Since GEDCOM isn’t clear about what to do, everyone has implemented it differently.

To me Legacy does it best. But to settle on one way that’s incompatible with everyone else is not really a good idea. The real solution may have to wait until a new standard to replace GEDCOM is created, one that will have a more rigorous way of defining preferred and alternate information for an event, and how to properly handle the various types of unions.

Below is a set of best practices as I see them. The format of this is inspired by Tamura who originated the idea.

—

Best Practice

GEDCOM reader

• Multiple BIRT or DEAT events in an INDI record should be treated as a single birth or death with conflicting sets of information.
• The order of the BIRT and DEAT events should be treated as the user’s judgemental ranking from most likely correct to least likely correct (or even incorrect).
• All other event/fact types that occur multiple times within an INDI record should be treated as separate events/facts.
• Multiple MARR or DIV events in a FAM record should be treated as a single marriage or divorce with conflicting sets of information.
• The order of the MARR and DIV events should be treated as the user’s judgemental ranking from most likely correct to least likely correct (or even incorrect).
• All other event/fact types that occur multiple times within a FAM record should be treated as separate events/facts.
• Two or more FAM records with the same HUSB and WIFE should be treated as multiple unions of the same two people. No warning should be issued. Children of these FAMs are full siblings and should be displayed as such.

GEDCOM validator

• Do not give any messages for allowed multiple events/facts of any type.
• Do not give any messages for multiple FAM records with the same HUSB and WIFE.

GEDCOM writer

• Export multiple BIRT or DEAT events in an INDI record when there is conflicting information, ordered from most likely correct to least likely.
• Export multiple MARR or DIV events in a FAM record when there is conflicting information, ordered from most likely correct to least likely.
• For all other events/facts, export multiple events of one type only when they are separate events/facts.
• Create a separate FAM record for each remarriage/reunion of a couple after they have divorced or otherwise separated and then got together again. Attach the children to the appropriate marriage/union.

Future GEDCOM Standard

• Eliminate the ambiguity caused by multiple events being allowed to represent conflicting information in some cases, but different events in other cases. Make conflicting information a substructure of the preferred event. Then multiple events will always represent different events.
• The current FAM record is defined as a marriage/union of a man and woman becoming a parent. This definition is wrong in many ways and the implication that it represents a family is misleading. Change the structure to be a UNI (union) of two (or more) people for any purpose. Allow same-sex couples. Don’t require a child but do allow them.
• Change the HUSB/WIFE tags to be a non-sex INDI tag. Whether INDI is a husband or wife will be able to be inferred by the sex of the person being pointed to and if the couple has a MARR event.

Although I’m not at #RootsTech this year, I’ve been very interested in seeing what has been happening there since last year. Last year when I was there, I blogged every day on the goings on.

For those who can’t be there, the live streaming that takes place from Room 1, the big room where the Keynotes talk, gives a good selection of presentations to give everyone a good cross-section of a range of topics.

Here’s a few of my observations from the first two days.

Last year, the first Keynote was Jay Verkler, the at the time outgoing CEO of FamilySearch who was handing the reins over to Dennis Brimhall who also spoke. Jay spoke like a visionary, of all the things he had been trying to put in place, but would no longer be in control of doing.

This year Dennis Brimhall spoke. He had much less enthusiastic vision, but takes a more direct businesslike stance. This definitely is going to be an interesting shift for FamilySearch. I don’t see it as being either better or worse. But it’s different. Change is often good, so by next year, we’ll see.

Then it was very interesting watching Syd Lieberman and Josh Taylor. Both were talking about the power of stories. Genealogy is more than just genealogy.

Technology-wise, I was unhappy that the presentations were not visible on my Windows Phone. They are Adobe Flash videos, which unfortunately Adobe has decided that it is no longer developing a mobile version. Then, I was meeting an out-of-town friend at noon, which mean’t I’d be missing the 11 a.m. Future of Genealogy Panel. But I was very happy when I got back from lunch, that the streaming videos had the full stream in them, and you could go back to any point and start from there.

I was really looking forward to The Future of Genealogy panel, moderated by Thomas MacEntee with panelists Josh Taylor, Lisa Louise Cooke, Daniel Horowitz, Dear Myrtle, Alan Phillips and Dick Eastman. The most interesting answer to me was that of Daniel Horowitz who made the point that we cannot generalize the people who are genealogists. Every one of us is different and we each do our genealogy differently.

At the 3 p.m. streamed presentation, Jill Ball led a panel through each of their technological gadget bags. I had spent an enjoyable 8 days with Jill (and Alan Phillips from the earlier panel as well) on the Unlock the Past genealogy cruise last month.

A week ago, Jill posted on her blog her trepidation about moderating that session after she realized that it was going to be on the live feed. But she had nothing to worry about. She did fine!

At the 4 p.m. session, it was nice to listen to James Tanner who produces great genealogy posts on his blog: Genealogy’s Star. I was quite surprised to read what James wrote today about his interest in the Family History Information Standards Organization (FHISO). Hopefully he’ll get more involved with it.

Speaking of FHISO, there’s lots of activity going on for it at RootsTech this year. As a signal of FHISO’s commencement of open standards development work, FHISO announced their Call For Papers. And they’ve got their own booth in the exhibition hall. FHISO had an Open Standards panel today that included Bruce Buzbee, Josh Taylor, Drew Smith, Joshua Harman, Patrick Jones and Robert Burkhead. Here’s a picture of Gordon Clarke of FamilySearch talking to three of the panelists. This FHISO panel is the one event that I’m missing most by not being at RootsTech this year.

Today’s keynote included Tim Sullivan, CEO of Ancestry.com. Tim was very “nice” to FamilySearch this year, especially when you compare to his keynote last year when he said in as many words that Ancestry and FamilySearch were competitors. I did note that he did not mention at all the purchase of Ancestry.com by Permira late last year for $1.6 billion and any benefits that might bring to the company. I also very much enjoyed Jyl Pattee’s keynote.

Today, the winners of the RootsTech Developer Challenge were announced. There were winners in 3 categories.

In the “Find” category, the winner was BrowseHero (Tom Auga & Chris Giesey), a Windows utility that  shows the FamilySearch website and adds features to the FamilySearch interface that includes a Full Family Graph and the ability to find errors and maintain local research notes.

In the “Preserve” category, the winner was Our Family Health by Jaehoon Lee. This is not a publicly available tool yet, but they do have some demos. I think genealogy software does need to track health information, and it should also track DNA, pets, non-family relationships and all the stories that make up family history. Maybe I can get Behold to evolve to one day include it all. By the way, there does appear to be one other programs out there now that I’ve got listed on GenSoftReviews that does family health history: ItRunsInMyFamily.com

In the “Show” category, the winner was Treelines.com by Tammy Hepps. Tammy’s program also won the best overall out of the three winners.

The one other session I was really happy that was livestreamed was Ron Tanner’s FamilySearch Family Tree presentation. Ron is unapologetic in his presentation of Family Tree. He’s the project manager and he’s determined. He tells you what they want to do, but that they’re not there yet. Ron is also a hilarious presenter and a must-see. If he decided he wanted another job other than at FamilySearch, he could easily become a stand-up comedian.

That basically sums up what I thought of the first two streaming days of RootsTech. There is a lot going on at the conference. Lots of people are blogging about it and during these 3 frantic days, it’s hard to keep up with it all. Although I tend to hate the automated news-gatherer websites, I’ve found over the last two days that RebelMouse’s RootsTech2013 feed is the best to get the widest variety of tidbits.

The worst thing about the conference, as is true with most great conferences, will be the end of it tomorrow. Don’t forget to watch the keynotes tomorrow morning and read all the blogs for the follow up.