* Set Individual as Deceased

[tatewise]

First of all there is NO standard Gedcom specification for record Flags.
Each genealogy product has its own concepts for such custom Flags, and some allow multiple values and others do not.
Such Flags do NOT usually migrate well between products.
Just because they are called Flags do NOT assume they all use the same concepts.

In FH the Flags can be assigned any interpretation you wish, but there are only two possible states.
Either the record has the Flag set, or it does not.
If the Flag is set then the Edit > Record Flags dialogue has a matching tick.
There is no concept of a Flag being Present on a record and unticked or disabled.

You are perhaps thinking that because a Flag is listed in Edit > Record Flags that it is present for the chosen record.
Not so, because the same list appears for EVERY record.
It is just like the list of Facts you can select for an Individual, they are just options you can add.

The only Flags that have any special consequences are Private and Living which have associated Privacy settings in Report Options, etc.

If the Living flag is set, then that implies the Individual is deemed to be alive, regardless of any Facts on their Facts tab, even if that includes a Death Event with a Date in the past.

If the Living flag is NOT set, then that implies nothing other than you don't want to apply the Privacy setting in Reports.

[David Potter]

Hi Peter. That cleared that up thank you. I was referring more to the FH user interface than to the Gedcom file as you have deduced.

My knowledge of Ged files and structure is not so strong. Apologies for that.

[LornaCraig]

I can see that you were probably confused by the list of all flags appearing, with tick boxes. But another way to see which flags have been set on an individual is to expand their record in the Records Window or in the All tab of their Property box. Scroll down to the bottom and you will see a line starting Flags: There are no tick boxes here, this just a list. If a flag is in that list the individual has that flag. If it is not in the list they don't have the flag. That is what I meant by 'absence' of a flag.

[David Potter]

Thank you Lorna. Got it now

[ronk]

I can see that you were probably confused by the list of all flags appearing, with tick boxes. But another way to see which flags have been set on an individual is to expand their record in the Records Window or in the All tab of their Property box. Scroll down to the bottom and you will see a line starting Flags: There are no tick boxes here, this just a list. If a flag is in that list the individual has that flag. If it is not in the list they don't have the flag. That is what I meant by 'absence' of a flag.

Lorna,

Not to beat this horse to 'death' , but I don't see a line starting 'Flags' in an individual's property box, and no flag list. Am I suppose to? Nothing there to scroll down to.

[LornaCraig]

As I said, you need to "expand their record in the Records Window or in the All tab of their Property box".

So in the Records Window click the little + sign in the box to the left of the name to expand the record.
Or in the Property Box switch to the All tab.
At the bottom of the expanded record is the Flags list. If the individual has no flags set, that line won't be there.

[ronk]

Alright, your explanation seemed to state a flags line was always there, and you look at it to tell if any flags are set.

[Gowermick]

Of course, this does mean that the GEDCOM standard or FH is flawed, insofar as one could tick both the Living and Dead flags for an individual. One would need to be very careful if one created a Dead flag, not to assign it to someone FH has flagged as Living!
To obviate this situation, the FH Living flag really needs to be tri-state, i.e1.Living; 2.Not Living or 3.Not Sure, and only create the Living GEDCOM flag if the person is actually marked as 1.Living

[tatewise]

The Gedcom standard is not flawed, because as I said it does NOT specify Flags at all.
If the Living flag were tri-state then it would have to be saved in the Gedcom as tri-state, otherwise when you next open the Project the tri-state value will have been reduced to two-state, because the Gedcom is the Project database.

There is also no such thing as a Dead flag, unless the user creates one, but then FH has no way of knowing its semantics, so cannot apply any logical rules. As I said, the Death Event is in effect a Death flag, in the same way that a Birth Event less than 110 years ago without a Death Event is in effect a Living flag.

The only two flags that FH gives any meaning to are Private and Living to apply Privacy options to Reports, etc.

There are innumerable ways a user can enter inconsistent or erroneous data, and FH cannot be expected to detect them all, but it has got better over the years. The Show Project Statistics Plugin highlights many such inconsistencies.

I suspect many other products allow their Living flag to be set even when there is a Death/Burial/Cremation Event.

[Gowermick]

Sorry Mike, but I think you are being too pedantic.

Gedcom has a DEATH Tag (not a flag I agree), which currently only allows Y or Blank.

The flaw is in the fact it does not allow Y, N or Blank (i.e tri-state)
Y=Person Dead
N=Person Living
Blank - Don't know

[LornaCraig]

I believe (from what Mike has said elsewhere) that the only purpose of the Y in the death event is to prevent an otherwise empty death event from being automatically deleted. It has no other purpose. A death event with a date, place or cause does not need the Y. It is the existence of the death event itself that signals that at a person has died.

Yes, it is possible to set a Living flag on an individual who has a death event. This looks odd to a human but not to a computer, which just takes the flag an a sign to hide certain data in reports etc. Personally I prefer to use the Private flag which has the same effect without implying (to a human) that the person is alive.

[AdrianBruce]

... Gedcom has a DEATH Tag (not a flag I agree), which currently only allows Y or Blank.
The flaw is in the fact it does not allow Y, N or Blank ...

As Lorna indicates, the purpose (in the GEDCOM Manual) of GEDCOM's Death tag is to record someone's death. To record the fact that someone is alive on the Death tag that should only be used when someone has died, is inherently contradictory.

One can certainly wish for a tri-state flag elsewhere - though my instinctive design comment is that the 3rd state of "don't know" would be served by absence of the flag, allowing the explicit values of the flag to be just two-fold.

Just as an incidental, to provide a diversion, Ancestry's interpretation of the Y on the Death tag is, or was, somewhat variable. There is a place in France called just "Y" and the Death tags with a Y were being interpreted as "Died at the place called Y".

[tatewise]

To complete the picture, it is a part of the standard Gedcom specification that demands the Y on any Event tag (not just Death) that has no other subsidiary details. It simply confirms that the otherwise empty Event should not be purged. It does not apply to Events with subsidiary details. Since it is part of the formal Gedcom specification, it is not something that FH would ever do differently.

The full GEDCOM specification says:

The presence of a DATE tag and/or PLACe tag makes the assertion of when and/or where the event took place, and therefore that the event did happen. The absence of both of these tags require a Y(es) value on the parent TAG line to assert that the event happened. Using this convention protects GEDCOM processors which may remove (prune) lines that have no value and no subordinate lines. It also allows a note or source to be attached to the event context without implying that the event occurred.

It is not proper to use a N(o) value with an event tag to infer that it did not happen. Inferring that an event did not occur would require a different tag. A symbol such as using an exclamation mark (!) preceding an event tag to indicate an event is known not to have happened may be defined in the future.