GEDCOM, problem with DEAT tag export

[elevator 0]

Good evening,

I have a problem with exporting GEDCOMs and the DEAT tag. I use GEDCOM to export data from TMG to my phpGedView website. I have a large number of individuals in my family tree going back to around 1500. I have no documented data on these people except their name, which means they have no death tag. However, I do set the Living flag to No because obviously these people are long dead. However when you export the GEDCOM from TMG there is no DEAT tag. If there is a date, it correctly exports:

1 DEAT

2 DATE 08 JAN 1590

but if there is no death date the DEAT tag is completely missing despite the fact that the Living flag is set to No. Shouldn't the DEAT tag still be exported showing the line:

1 DEAT Y

to indicate that the person is in fact dead, just no date is known.

 

I have seen other programs do this correctly, is there a reason why TMG does not? Or maybe I have just missed an option telling the export functions to export DEAT tags based on the Living flag?

 

Thank you for any help,

Ken.

[Vera Nagel 0]

Hi, Ken,

 

I have no documented data on these people except their name, which means they have no death tag.

 

If there is no death tag added to a person in your project according to my two cents there's no tag for TMG to export to a GEDCOM.

 

However, I do set the Living flag to No because obviously these people are long dead.

 

Settings of a Living flag or any other are generally totally independent from tags.

 

If there is a date, it correctly exports:

1 DEAT

2 DATE 08 JAN 1590

but if there is no death date the DEAT tag is completely missing despite the fact that the Living flag is set to No.

 

If there is a date for the death tag it implies that the death tag itself exists and so it is exported to the GEDCOM.

But even if the death tag exists (but you have to add it to your person first) and has nothing in it - say it is completely blank - it will be correctly exported to the GEDCOM.

 

Example:

1 NAME test /test/

1 SEX M

1 CHAN

2 DATE 28 SEP 2006

1 DEAT

 

But let's assume simply setting the Living Flag to N would create a DEAT entry in the GEDCOM and let's further assume because you don't know the date of birth and thus have not recorded / added a birth tag shouldn't then the BIRT entry also show up in the GEDCOM just because the person name does?

 

Anyway I have NO experience if any other genealogy program handles that different but I am totally happy that TMG doesn't.

[elevator 0]

Hi Vera,

Thank you for your reply. Standard GEDCOM specifications indicate that if a person is documented to be dead but no death date exists, you can still use the DEAT GEDCOM tag to indicate that a person died but that no date is given. It seems logical to me because TMG exports the Sex flag, why not the Living flag? They are both default flags. My problem is that there must be a way for an exported GEDCOM to indicate that a person has died, regardless of whether or not a death date actually is documented.

 

Exporting a birth tag if there is no birth date is absurd because if a person is in fact entered into your database I would assume that person was born (unless we're entering fictional characters)

 

Here's the GEDCOM 5 definition of the DEAT tag.

n DEAT [Y|<NULL>] {1:1}

 

The specifications says that if no death date is known two formats are allowed:

1 DEAT Y

or

1 DEAT

2 DATE UNKNOWN

 

Even though superfluous, the same is allowed for the birth tag. It then makes perfect sense that TMG should allow the implementation of this, especially since a standard flag exists (LIVING) that controls just this.

 

I could enter a blank death tag, but it seems like a bad procedure, because according to good research practice, all tags should have sources, and if I have no sources for the tag in question it makes perfect sense to use the GEDCOM standard mentioned above since: 1. it does exists, and 2. TMG has a flag controlling it. The LIVING flag in TMG even allows you to set it to ?, so if you do not know if the person is alive or not, leave it at that and no DEAT tag would be exported to GEDCOM. All bases are covered that way.

 

Ken.

 

But let's assume simply setting the Living Flag to N would create a DEAT entry in the GEDCOM and let's further assume because you don't know the date of birth and thus have not recorded / added a birth tag shouldn't then the BIRT entry also show up in the GEDCOM just because the person name does?

 

Anyway I have NO experience if any other genealogy program handles that different but I am totally happy that TMG doesn't.

[Vera Nagel 0]

Hi, Ken,

 

I know my birth tag comment was a bit nasty, so please don't take that to serious and don't shoot me to hell for it.

 

Here's the GEDCOM 5 definition of the DEAT tag.

n DEAT [Y|] {1:1}

 

The specifications says that if no death date is known two formats are allowed:

1 DEAT Y

or

1 DEAT

2 DATE UNKNOWN

 

That's correct.

And the SPEC's for 5.5 say further ....The occurrence of an event is asserted by the presence of either a DATE tag and value or a PLACe tag and value in the event structure. When neither the date value nor the place value are known then a Y(es) value on the parent event tag line is required to assert that the event happened.......

 

So you are saying that TMG's way to export an existing DEAT which has no date nor a place is not correct according to the specifications?

 

On the other hand according to SPECs one can't consider the explicitly predefined SEX VALUE to be equal with LIVING, sorry. The first one has nothing to do with any kind of event structure but the latter clearly has.

 

Anyway: Having the standard LIVING flag work the way you're describing (say regarding to SPECs "create" an event structure and a assign a value to it) may be a wishlist topic.

 

How should it work if LIVING is set to Y?

[elevator 0]

Hi again Vera,

No worries, a little fun is never taken personally. No I am not saying that TMG is doing anything wrong, because the Y identifier of the DEAT tag is clearly not REQUIRED, but from the standpoint of the standard it seems that it was intended specifically for situations where no DATE or PLAC tag is present, so why not take advantage of it? phpGedView for example uses this tag specifically to calculate privacy for living people in the family tree.

And the SPEC's for 5.5 say further ....The occurrence of an event is asserted by the presence of either a DATE tag and value or a PLACe tag and value in the event structure. When neither the date value nor the place value are known then a Y(es) value on the parent event tag line is required to assert that the event happened.......

 

So you are saying that TMG's way to export an existing DEAT which has no date nor a place is not correct according to the specifications?

 

I disagree. If you look at an exported GEDCOM from TMG it exports other "default" flags like the Ascendant and Descendant interest flags. Clearly these are far less valuable than the living flag. It seems to me like a vital part of a person's file is left out when exporting GEDCOM's. What can be more important to export if not wether or not a person is actually alive or not?

 

In the same way if the LIVING flag is set to Y, clearly there is no reason to export a DEAT tag because the person is still alive! Making it a wishlist topic may be a good idea, I just wanted to vent the idea to see if anyone has discussed the issue before.

 

Ken.

On the other hand according to SPECs one can't consider the explicitly predefined SEX VALUE to be equal with LIVING, sorry. The first one has nothing to do with any kind of event structure but the latter clearly has.

 

Anyway: Having the standard LIVING flag work the way you're describing (say regarding to SPECs "create" an event structure and a assign a value to it) may be a wishlist topic.

 

How should it work if LIVING is set to Y?

 

 

Just a short little anecdote. I have one person in my database born in 1935. I have no sources to document his date date or place, but I know he recently died so I set the Living flag to No. When exporting this to GEDCOM, as far as GEDCOM is concerned this person is still alive

 

Ken.