Follow-Up Friday - Comments about RootsMagic GEDCOM, Places, etc.

...
I've been trying to Follow-Up on Fridays to answer comments received on Genea-Musings posts and questions in email.  This post will cover issues raised concerning RootsMagic:

1)  In The Strange "Y" in a Death Description Field in a RootsMagic 4 GEDCOM File, there was a bit of discussion about the "Y."  Since I wrote the post, I have seen the "Y" in other GEDCOM files I've created, but had not noticed it before.  The comments are interesting:

*  Bruce Buzbee (creator of RootsMagic) said:

"No, this is not a flaw in RootsMagic (but apparently *is* one in FTM)."
"This is from the GEDCOM spec...

"All GEDCOM lines have either a value or a pointer unless the line contains subordinate GEDCOM lines. In other words the presence of a level number and a tag alone should not be used to assert data (i.e. 1 DEAT Y should be used to imply a death known to have happened but
date and place are unknown, not 1 DEAT )."

"So if you know there was a death but have no date or place (which you would in RootsMagic if the Living flag was unchecked but there was no death fact entered), then GEDCOM says to use:
1 DEAT Y "

*  Russ Worthington commented:

Bruce, which GEDCOM Spec is that in? Just curious. 

Randy: I just ran a Custom Report in FTM2012. What I was able to confirm is that IF there is a Birth Date and No Death Date, a "Y" will appear in the Description Field. If there is a Death Date, there will be no "Y".

There are 86 people in the file, and looking for people with a "Y", there are 49 people. When I look at the Report that Includes Death information, the is no "Y".

I think we have a better understanding of where the "Y" came from. For me, this isn't a finger pointing contest, but to understand the data.

*  Louis Kessler added:

"Russ: You'll find that in GEDCOM 5.5.1 on page 21, used as an example that all lines must have a value or a pointer (so you can't just say: 1 DEAT without the Y).

"The key thing is that the program should NOT change or set the value of DEAT for you. This should be set deliberately by the user because they know the person has died, but does not know the date or place. The program should never use any algorithm to impute it. The person must be the one to set it.

"All the program may do (not required) is to not include the 1 DEAT Y if there is any other death information entered, e.g. date or place."
and:

"... and RootsMagic does it backwards. They should not use a Living flag. They should use a Death flag.  Once a person is dead, they stay dead. That's why GEDCOM did it that way."

*  Sue Adams had interesting comments:

"This is an example of the inadequate data model GEDCOM uses. There are four different pieces of information here:
death date
death place
imputed death
living

"Each of these should be stored and handled separately, and have an associated source.

"Gedcom handles death data and place by expecting two bits of data for each DEAT tag. It does not allow separate sources for data and place, so you can't cite a grave marker for the date and a burial record for the place.

"It is sometimes useful to input whether someone is dead based on data stored in the database at a particular time (e.g. to produce a calender with birthdays and anniversaries of living people, to check data validity). However, this has problems associated with it. If a birth date is changed, the inputed death value must be updated. How this is handled depends on whether the value is stored or calculated 'on the fly'. The user should have a choice whether or not to use this flag. It should have a 'source' that tells us when it was calculated and from what data and the criteria used (e.g. born over 120 years ago).

"The living tag serves a different purpose. I suspect the RootsMagic introduced it because users wanted to be able to exclude particular people (usually living) from charts and reports intended for distribution. It is really a on/off switch for displaying data.

"So, Rootsmagic, or for that matter any other program vendor could improve their product and better serve genealogists as follows:
1. ensure that these four data items are stored separately within Rootsmagic
2. ensure that these data items are exported correctly and comply exactly with the Gedcom standard, since we do not yet have a viable alternative
3. ensure that all the functions of Rootsmagic continue to work properly
4. repeat 1-3 for each and every piece of data Rootsmagic currently stores
5. repeat 1-3 for any other data items that customers want and add functionality
6. develop a data model that works properly

"In short: Please don't feed the Gedcom zombie."

*  Bruce Buzbee responded:

"RootsMagic has a Living flag for each person that is checked by default. When the person dies the user can uncheck the box, or when the user adds a death type fact (death, burial, cremation, etc), RM will uncheck the box for them. So RM is *not* doing it backwards."

*  Sue Adams commented:



"The "Living" flag is checked by default?! That makes no sense to me as in reality the vast majority of people in genealogy databases are dead.

"Given that the "living" flag is really a means of the user choosing to whether or not to include individuals in GEDCOM files, reports, calendars or website, for privacy reasons it is mis-named. It is a different kind of information than the flag GEDCOM stores in the DEAT tag, so the two should not be confused."

And there the discussion ended.  I really appreciate the civility of the discussion and the "on point" focus of the discussion.  I learned a lot!  I hope my readers do too. 

It seems to me that the software users need to be aware of the need to check or uncheck the "Living" box (or whatever the software has) when they do not have a birth and death date (from which it might be imputed that someone was dead) and to check it when they know a person is still alive.  Russ noted that FTM 2012 also adds the "Y" for a person not known to be dead.

2)  I received an interesting email from Eddie about Place Names in RootsMagic:

"I have been using RM, 2, 3, and 4.  Getting close to a year ago I got frustrated with the ability to do research by county; so I began the process of reversing the place locations from municipality, county, state, nation to nation, state, county, municipality.  I found it very useful; the place list naturally sorted everything by county name and made county research easy.

"Now we have RM5 arrive; I immediately suspected I had a problem with my reverse order locations when I saw the "CountyCheck".  I sent an email to RM support and received a response from Renee that said, yes, the place list locations must be in order of municipality, county, state, nation for the "CountyCheck" feature to work.

"Are you aware of a program that would easily reverse my place list names?; it has been a lot of work."

My response to Eddie was:

"I have no ideas as to how you could reverse the place list order easily.  A smart programmer could do it by writing a program to read a GEDCOM file (plain text) and reverse the elements when it encountered a PLAC tag.  I used to be able to do that in FORTRAN, but now don't have the tools. 

"You might ask the question on the RootsMagic message board (http://boards.ancestry.myfamily.com/topics.software.rootsmagic/mb.ashx) or the RootsMagic Forums (http://forums.rootsmagic.com/).   Maybe someone else has your problem and has solved it, or can do the programming task.

"You could turn off the CountyCheck option in Tools > Program Options also and not be bothered by it."

That's all I have on RootsMagic.  I have some follow up to do on FTM 2012 and source citations too.  Maybe next week.