Louis Kessler’s Behold Blog

As I was writing up my documentation for the release of Behold 1.1, I discovered a weird GEDCOM construct used in one of the sample GEDCOM files, Steve McCarthy Legacy.ged, that I supply with Behold. The file was created by Legacy version 5.0, and the weird construct is this:

0 @F3@ FAM
1 MARR
2 DATE 4 Jan 1925
2 PLAC Boston, Suffolk, MA
2 TYPE Death of Spouse

Of marriage types, I’ve seen “Common Law”, “Civil” “Religious” and all sorts of others including superfluous text like “Marriage of Martin Smith and Elna Jefferson” right in the TYPE tag. But what kind of marriage is a “Death of Spouse”? Sounds pretty morbid to me.

The very same GEDCOM file further down shows this:

0 @F39@ FAM
1 MARR
2 DATE 16 Oct 1965
2 PLAC Providence, Providence, RI
2 TYPE Death of Spouse
3 DATE 14 Apr 1984

Okay! Now there’s a date attached to the “Death of Spouse”. Now it makes more sense. It is not referring to the TYPE of marriage, but to the end of the marriage due to one spouse dying. I agree that this is a valid thing to document, and GEDCOM only has capabilities to record divorces and annulments as an end of a marriage, so it is good to include this.

But how on earth did the Legacy developers ever come to feel that the right way to handle this is adding a TYPE tag under a MARR tag?

And horrors of horrors, that Legacy file has yet another awful construct for the same thing:

0 @F39@ FAM
1 HUSB @I122@
1 WIFE @I3@
1 _STAT Death of Spouse
2 DATE 14 Apr 1984
1 MARR
2 DATE 16 Oct 1965
2 PLAC Providence, Providence, RI
2 TYPE Death of Spouse
3 DATE 14 Apr 1984

They use a level 1 custom tag _STAT here for the Death of Spouse. Well, that’s closer to what is proper. But a status is the state that something is in. A death of a spouse is not a status. It is an event indicating the change of status of one spouse from married to widowed and of the other spouse from married to dead.

To top it off, the 2 TYPE and 3 DATE tags are included even though the _STAT tag says the same thing. Yuck!

The proper way to do this is to put it in the FAM record as a top level event, like this:

0 @F39@ FAM
1 MARR
2 DATE 16 Oct 1965
2 PLAC Providence, Providence, RI
1 EVEN Death of Spouse
2 DATE 14 Apr 1984

Searching Google for the phrase “Death of Spouse” in GEDCOM files currently finds 120 results. It seems that most programs, like PAF, GENE and RootsMagic do it correctly the way I suggest above with the EVEN tag.

If the people at FHISO are listening, and if they ever get to actually starting to write a standard, I’ve got some recommendations based on some of the work I did to develop Life Events in Behold 1.1.

1. Whether or not the family unit is implemented, it is very important to know when partner relationships both start and end. The partner is only relevant to the rest of the family during the relationship.
2. The MARR marriage tag is a good indicator of when the marriage begins. But what about partnerships such as Common Law? For that, GEDCOM currently has no standard way to indicate when the two people become a couple.
3. The DIV divorce tag or ANUL annulment tag are good indications of the end of a marriage. But the death of a spouse (as described above) is also important. And DIV and ANUL don’t apply to Common Law relationships.
4. I haven’t fully thought this through, but maybe a PART partnership tag might work.  This could be under the 0 INDI record and look something like this:
   

   0 @I12@ INDI
   1 PART @I13@
   2 TYPE Common Law
   2 DATE FROM 13 Nov 1843 TO 28 SEP 1865

When I first started this blog post, I was thinking this problem with this “Death of Spouse” construct might be quite widespread and I’d need to handle it with a special case in Behold. To my actual surprise, it appears that my sample file might contain a relatively rare and isolated case. I have found other Legacy files (version 6 and earlier) with the technically allowable _STAT Death of Spouse construct, but I haven’t found any others with the illogical FAM.MARR.TYPE Death of Spouse construct.

So at this point, I’m not going to write special code to handle this. Behold’s flexible reading of tags does a decent job and handles it okay.

Followup: Sep 17, 2019: Coming back to this post after communicating with Tamura Jones about his GEDCOM 5.5.5, I now see that I never mentioned that the death of a spouse as an entered event is totally unnecessary. Any smart program would be able to figure it out if either or both spouses have their DEAT event recorded.

This has taken way too long and so much longer than I ever expected. It’s now almost two years since the last release of Behold (version 1.0.5.1). And it was earlier than that when I started developing my concept of Life Events as I first described in my Endless Possibilities post over 3 years ago.

But I’ve finally implemented everything necessary for Version 1.1. I’ve tested many of my sample GEDCOMs to ensure it all works properly together, and in so doing had to handle hundreds of special cases – generalizing them wherever possible so that the widest range of possibilities can be handled.

It’s got to work well right off, since this is a production release. I have not encountered any crashes in my test version in a long time. This version of Behold appears to be quite solid and stable, ready to go out.

I’ve marked two more Version 1.1 items as done on the Future Plans page, bringing the total count to about 70 new features, improvements and fixes that are being included in the upcoming version.

There is now just one necessary thing to finish off. It is to update the Behold documentation to bring it in line with the new version. There are enough new features that need to be documented, and the contents of the Everything Report has significant differences that include a lot more useful information to help you with your research. So just about all the screen shots have to be redone.

This is not difficult and is actually rather enjoyable for me to document all the improvements and ensure that the Tutorial, How To’s and Reference Guide provides what’s needed. This is a very important step before the release, because it allows me to go through all Behold’s features methodically as a last check that everything’s working and I haven’t forgotten anything.

I have worked very hard over the past few years to get to this version. I’m excited and proud of what I’m about to release. Behold will provide your information to you in a very useful way that you won’t find anywhere else.

So keep checking my blog for any status updates and then the 1.1 release announcement.

My interest was tweaked earlier today by a discussion between Tony Proctor and Nick Hall on the mailing list for the FHISO Sources-Citations Exploratory Group. In particular, Nick made the following statement:

The problem with GEDCOM is that it heavily restricts the types of source that can be easily cited.  Citations in Gramps are based on GEDCOM, and this is an area that needs improvement.  I suppose one good thing about GEDCOM is that it doesn’t specify formatting - it just allows the transfer of elements such as TITL, AUTH, PUBL and PAGE.

I had to respond, and I think I’d like to document my response and my opinion about GEDCOM and sourcing here on my blog. This is what I said:

—

I’d like to defend GEDCOM for a moment. Its source structure is much more flexible than you state.

In the SOUR record, it provides TITL, AUTH, PUBL, and also DATA (with an AGNC - responsible agency and its own NOTE structure), ABBR, TEXT, multiple REFNs (each with a TYPE to describe it), RIN, a change date, a NOTE structure, and a Multimedia Link (which has its own title, a file reference, a multimedia format type, and a source media type: audio, book, card, electronic, fiche, film, magazine, manuscript, map, newspaper, photo, tombstone, video).

The source links to a Repository (REPO) record that contains the name of the repository, its address, phone number, email, fax, web page url, a note structure for the name, a REFN (with a type), a RIN and a change date.

Along with the link to the Repository is a NOTE structure, a CALN call number and source media type (same choices as above)

The conclusion data links to the source via their misnamed SOURCE_CITATION which includes PAGE, EVEN (event cited from and ROLE of the person in the event), DATA (including date the entry was recorded and TEXT from the source), a Multimedia link (as above), a NOTE structure, and a QUAY (quality assessment).

The power of the PAGE tag is often overlooked. It is to describe the specific location within the information referenced. The data in this field is in the form of a label and value pair, with each pair being separated by a comma. The labels are user defined, so anything goes. This gives this standard great flexibility. The example given in GEDCOM is: 

Film: 1234567, Frame: 344, Line: 28 

Note that this is GEDCOM 5.5.1 and includes some improvements over GEDCOM 5.5’s sourcing.   GEDCOM 5.5.1 is the de facto standard (as Tamura Jones has explained) because PAF used it and many programs followed.

I’m not saying GEDCOM’s sourcing is perfect. It is not. It does mix a bit of conclusions with sources and there are some source types that can be handled better. But it is far better than most people realize. There really is very little that cannot be reasonably described with GEDCOM’s sourcing.

The problem in my opinion was that programmers did not look into GEDCOMs sourcing deeply enough and did not attempt to use it in all its detail. Many instead invented their own non-standard schemes which results in their GEDCOM exports not transmitting their source data to other systems.

With regards to GRAMPS, I can’t believe any of the programmers have attempted to use GEDCOM sourcing to the extent it could be, or GRAMPS sourcing would be much better than you describe.

I do feel that this committee should be able to come out with some sort of system that is not much more complex than with what GEDCOM did as I described above.

—

(In response to another post about nested sources, I added the following)

With regards to nested sources, my opinion is that a simple reference within a source to another source will handle this easily (similar to Tom’s proposal for Personas), e.g.:
   0 @S1@ SOUR
   1 TITLE xxxxx
   1 SOUR @S2@
   2 PAGE …
   2 NOTE …