* Is there a 'Dead Flag'?

[jimstothers]

I am unclear about how to mark people as dead that I know are dead but don't know when they died. I know there is a Living Flag that can be used to mark people as living. But what about people who don't have a death event, but who are certainly dead - e.g. they were born 130 years ago? Does FH treat them as dead if there were born before a certain number of years ago? I'm thinking also about when happened when a GEDCOM file is exported to an online site - is there a generally agreed protocol whereby details of people born after a certain number of years ago won't be shown unless there is a death date (or a died before date) shown in their record?

[ADC65]

You can set some parameters in Preferences > Estimates as shown below:

Screenshot 2023-07-23 182832.png (31.3 KiB) Viewed 750 times

I don't think there is a 'dead' flag as such - if you want to mark people as such, you could create your own flag. Do you know how to do this? Just ask if not.

There isn't a generally agreed protocol for other sites, in my experience. Some will use 100 years, some use 110 years, and others (like TNG) will allow you to set your own parameter.

[Jane]

You can add a "blank" Death Fact which will enough to show they are dead. Reports will show "He died"

My own policy for Online sites is to completely remove all living people before uploading, anywhere but my own site.

As always the Knowledge base has extensive notes on this and other options.
https://fhug.org.uk/kb/kb-article/expor ... out-media/

[Mark1834]

My own policy for Online sites is to completely remove all living people before uploading, anywhere but my own site

Agree - I actually go further than that, and usually omit the dead siblings and spouses of living people as well for obvious sensitivity reasons, using the Private flag and my own custom export routine (as in the Ancestry Sync plugin).

[KFN]

In GEDCOM 5.5.1 the rule to mark an individual as dead when no additional information (place or date) is entered is:

1 DEAT Y

The flag should be removed when either the place or date is added. The following is invalid:

1 DEAT Y
2 DATE 2 MAY 1883

[tatewise]

You, don't need to do anything to add/remove the Y following the DEAT tag because FH deals with that GEDCOM detail.
(IMO it was confusing to call it the flag because it is not a FH Record Flag.)

If concerned about how other products interpret GEDCOM then it is best to add a Death Event even without any details.
Record Flags are a custom feature of FH and are not understood by other products.

[KFN]

Tatewise,

So are you saying that the
1 DEAT Y

Is not understood by FH?

My primary software uses and understands this GEDCOM standard perfectly and in future releases of GEDCOM more facts will have this flag in the specification.

[Mark1834]

I'm not Tatewise, but the answer is "yes and no"...

When importing a GEDCOM, FH understands 1 DEAT Y, and creates a blank Death fact. However, it will also import 1 DEAT N and create a blank Death fact without complaining!

It stores a blank Death fact internally as 1 DEAT, and exports it in the same non-compliant form, even when GEDCOM 5.5.1 (Strict) is specified as the destination format.

[jelv]

Does Mike's export do it correctly? (not at a computer to try)

[tatewise]

I have just performed some fairly exhaustive tests.

FH seems to ignore anything following the 1 DEAT tag when importing so is tolerant to the Y case but does not remove Death facts without Y and without any subsidiary fields.

FH always exports Death facts that have no subsidiary fields by using the 1 DEAT Y construct as defined by the GEDCOM specifications for 5.5. and 5.5.1. My Export Gedcom File plugin does not do anything with DEAT facts because it assumes FH always gets it correct.

Mark, can you show evidence of FH not using the 1 DEAT Y construct?

However, none of this is relevant to the OP question.
The best option is to always add a Death fact to people who are considered to have died.
That is more reliably exported to other products than any FH Record Flag which is a non-standard custom FH feature..

[Mark1834]

FH always exports Death facts that have no subsidiary fields by using the 1 DEAT Y construct as defined by the GEDCOM specifications for 5.5. and 5.5.1. My Export Gedcom File plugin does not do anything with DEAT facts because it assumes FH always gets it correct.

Mark, can you show evidence of FH not using the 1 DEAT Y construct?

Yep - When you add a new fact to an individual, it is created with blank Date and Place fields, and these are not removed until the project is next loaded into FH. If you export a GEDCOM in the same session where you added the fact, the blank fields are stripped out, but FH does not add the Y value, and exports it as 1 DEAT, even if the project has been saved. Subsequent sessions export correctly.

I would suggest your underlined qualifier is not relevant to real world use, as it is only the computer that distinguishes between empty and missing fields, not users. It's a relatively minor bug rather than a systematic non-compliance, but FH certainly doesn't "always get it correct".

[AdrianBruce]

This is an extract of Mary (Dowling) in the Sample Project "before" my experiments

Code: Select all

0 @I84@ INDI
1 NAME Mary /(Dowling)/
2 SOUR @S27@
1 SEX F
1 BIRT
2 DATE CAL 1867
2 PLAC Kirkwall,Orkney, Scotland
2 SOUR @S27@
...
1 OCCU fisherwife
2 DATE 31 MAR 1901
2 PLAC Kirkwall,Orkney, Scotland
2 NOTE Employer, Worker, or Own account: Worker
2 SOUR @S27@
1 FAMS @F34@
1 _FLGS
2 __1901_UK_CENSU 1901 UK Census
1 CHAN
2 DATE 25 JUL 2023
3 TIME 11:49:17

I then opened the Project in FH, added a Death event for her with no data and closed down FH. This is then the same bit of the GEDCOM:

Code: Select all

0 @I84@ INDI
1 NAME Mary /(Dowling)/
2 SOUR @S27@
1 SEX F
1 BIRT
2 DATE CAL 1867
2 PLAC Kirkwall,Orkney, Scotland
2 SOUR @S27@
...
1 OCCU fisherwife
2 DATE 31 MAR 1901
2 PLAC Kirkwall,Orkney, Scotland
2 NOTE Employer, Worker, or Own account: Worker
2 SOUR @S27@
1 DEAT
1 FAMS @F34@
1 _FLGS
2 __1901_UK_CENSU 1901 UK Census
1 CHAN
2 DATE 25 JUL 2023
3 TIME 11:50:41

The change is the appearance of
1 DEAT

Note that there is no "Y" and the empty DEAT tag has not been removed. It even remains in the file after a 2nd load into FH followed by edit and save. I'm not sure how expected this behaviour is - I would have assumed before this thread, that FH would have created "1 DEAT Y" at some point in the proceedings.

[tatewise]

Mark, I agree there is that minor bug, but in practice, it is unlikely to seriously affect any exported GEDCOM files, because performing an export immediately after creating 'empty' Death events is not a common occurrence.

Adrain, as Mark explained, if you open that Project in FH again and Save, then the 1 DEAT Y form is created.
The 'bug' only lasts for one Save and Open FH session.
I reported it long ago to CP.

You are welcome to report it again if you wish.

We are going way off topic.

[AdrianBruce]

... Adrian, as Mark explained, if you open that Project in FH again and Save, then the 1 DEAT Y form is created.
The 'bug' only lasts for one Save and Open FH session. ...

Yes - I've got the "Y" now. I think the first time I reopened it, I hadn't made any update before closing and so didn't have the "Y". Hence my puzzlement at Mark's statement. I've just made an update, saved it, checked and it's there.