Question DEATH = Yes, possibly change in display text

Currently the header displays "Death: Yes" if the gedcom reads:
1 DEAT Y
and simply "Death: " if the gedcom reads:
1 DEAT (yes, I know this is bad formatting, but GDBI added over a thousand of these to early records and there is no clean way to remove these without a serious GREP command on the text gedcom.)

Further, the header displays "Death: -- Indiana, USA" if the gedcom reads:
1 DEAT
2 PLAC Indiana, USA

I find this current solution dissatisfying and leaving me wanting. I propose that, if a date is unspecified, either with a 1 DEAT Y, or 1 DEAT, or 1 DEAT <cr> 1 PLAC xyz, USA, that the header display the calculated string:
"Death: date unknown"

Do others have an opinion?
-Stephen

As a master of grep and other such tools, my first response would be to clean up the data

Would you just want "date unknown" on DEAT records, or any others?

Yes, thanks on the GREP comment

I think it could be proliferated, but perhaps only a bit.
1 MARR Y should/could be 'date unknown'
1 DIV Y could be 'date unknown'

I don't see it relevant to the BIRT, Baptism/Christening, etc.

the hard thing on the GREP is the 1 DEAT exists a lot of times and I'd have to identify only those not followed by a 2 DATE or 2 PLAC or 2 SOUR fact. It makes me nervous. I've been fixing these since created 5 years ago, as I come across them.
Stephen

<< Yes, thanks on the GREP comment >>

Many years ago, I wrote the "batch update" module, to allow me to send exactly this sort of regulare expression search/replace operation to people.

Does the attached plug-in do what you want?

(Put it in the modules/batch_update/plugins directory, then run the batch update from the config link on the module admin screen)

<< Do others have an opinion? >>>

To do it for some events but not others seems a bit inconsistent, but I have no strong opinion either way. It would be trivial to implement.

Oops - that one won't catch "1 DEAT" when it is the very last line of a record.

Try this one.

NO. The batch file is quite useful for many projects, but here, it converts them all to DEAT Y when in fact, many of these people are not dead. There are too many of these in the data to cycle through each record to determine if the qualfier "Y" should be added. I would rather simply remove all of them as most are living persons.

GDBI's only bad habit was to add the 1 BIRT and 1 DEAT tag to each newly created person, leaving the Y/N blank. Early copies of PGV did not make the person DEAD if the 1 DEAT tag was present without the qualifier, but subsequent versions did, creating the problem.
Stephen

Sorry - I misunderstood what you were asking for.

Removing these would be just as easy.

I figured as much. Just never got around to it.

I still think the display of "Death: Date unknown" (and perhaps the other unspecified dates) is better than the gruff, but factual "Death: Yes"

Perhaps some others will chime in. I noted that some gedcom admins use the PLAC field to achieve this and enter "Date Unknown", but obviously this is placing non-factual data into the gedcom. I'm simply talking about an interpretation of the "DEAT Y" tag and 'translating it' to "Death: Date unknown", leaving the gedcom to standard.
Stephen

I certainly agree that changing "Yes" to "Date unknown" would be an improvement. I wouldn't see any reason to restrict it in any way though, other than to use it wherever we currently use "Yes" to indicate that an event HAS happened, but the date is is unknown.

We do need to be cautious that it doesn't get used where we don't know (or calculate using isDead rules) the event has happened.

Using Greg's experimental extra-lang patch, I've modified the Yes to Date unknown. For a visual examination of the display, check out:
Family Page
and
Indi Page

Of course this 'hack' may have other consequences where the code uses the word 'Yes', but it was good enough for displaying the effect of this RFE.
-Stephen

My inclination is that absence of a date means “date unknown”

How does it handle having the SOUR, DATE, and PLAC tags in a different order than usual (since the spec does not demand a particular order)?

Could 1 DEAT Y without a date be rendered as “(deceased)” reserving the “Death:” for when there is actually something to follow the colon?

Wes
Your reply has confused me. The current code translation for a GEDCOM notation of "1 DEAT Y" displays "Death: Yes", just like a "1 BIRT Y" displays "Birth: Yes" and a "1 MARR Y" displays "Marriage: Yes". As you can see from the sample FAM and INDI pages I proffered for review, this RFE would simply change the displayed text (in English) to "Date unknown". What difference would the order of these tags have on anything? Obviously, if this was accepted, translators would have to translate "Date unknown" to their native language equivalents. If there were no MARR, BIRT or DEAT tag in the GEDCOM, then there would be nothing to display as the code would have nothing to interpret.
-Stephen

At the beginning, you proposed that "date unknown" be used in place of "yes" and when there was a PLAC but no date.
I interpreted the latter as saying you would change
Death: -- New York
to
Death: (data unknown) -- New York
which I would prefer as
Death: New York
(in other words, no separator if there is nothing to separate, as opposed to creating something for the separator to separate)

The former, I interpret as changing
Death: Yes
to
Death: (date unknown)
which I agree is an improvement, but I was suggesting an alternative of
(deceased)
I was NOT suggesting
Death: (deceased)
which would be silly

The other point was just a question, i.e., what happens when the GEDCOM is in a legal but rarely used order of other than DATE PLAC SOUR

OK, time for me to chip in here....

1 - Yes, Stephen did raise the additional issue of what to do with the display of
1 DEAT
2 PLAC Indiana, USA

For clarity, I believe he meant "where there is no "2 DATE xx xxx xxxx tag for that entry".

The reason it currently displays Death: Indiana, USA is that it is coded to display:
a - Death: followed by a date then a place if they are there, or
b - Death: followed by Yes, then a place, if the tag is 1 DEAT Y, or
c - Death followed by nothing, then a place, if the tag is just 1 DEAT

In three cases, the entry is followed by the PLAC details if they exist.

Stephen's proposal to replace "Yes" with "Date unknown" only fully solves b. But could be done for c as well, although that is a little more complex. It also means coding for what is, I believe, technically incorrect GEDCOM entries. A 1 DEAT tag should either have a subsidiary 2 DATE tag OR an inline "Y" (1 DEAT Y). "1 DEAT" and no 2 DATE is illegal.

In terms of your question Wes, webtrees (and PGV) don't care what order tags OF THE SAME LEVEL are found in. They are only required to be below their level 1 tag, and before another level 1 tag.

Nigel
I'd be interested to know if the standard disallowed a
1 DEAT
2 PLAC Indiana, USA

or a
1 DEAT
2 SOUR @Sxxx)
3 PAGE personal family data, date unknown

notation without a "1 DEAT Y" as the current data entry 'cleanup' from an EDIT-INTERFACE removes the "Y". I've commented on this before where only a SOUR was notated and the DEAT tag is displayed without any notation following - i.e. "Death: "
I've asked Greg before if this was intended activity - removing the "Y" - and his response, as I interpreted it, was that any subordinate tags to the 1 DEAT fact should remove the "Y", as is currently coded.
Stephen

Now you forced me to check - and of course, I'm wrong (at least partly). Here's the spec:

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. For example
each of the following GEDCOM structures assert that a death happened:
1 DEAT Y

1 DEAT
2 DATE 2 OCT 1937

1 DEAT
2 PLAC Cove, Cache, Utah

So that means your example:

1 DEAT
2 SOUR @Sxxx)
3 PAGE personal family data, date unknown

is NOT confirmation that death occurred, but

1 DEAT
2 PLAC Indiana, USA

IS valid. Note also that it says when DATE or PLAC are not known, a "Y" is required.

I should add as well, that all this assumes you regard the spec as inviolate! I don't, and am therefore quite happy that we remove the "Y" if there is ANY subordinate data to the 1 DEAT tag. It just makes sense to me.

So, this would/could be an existing bug - I think - as the "Y" is removed by the code when a SOUR is added to a "1 DEAT Y" event.
-Stephen

My opinions:

1. I doubt the spec writers deliberately omitted SOUR from dropping the need for a “Y” I have an undated letter in Polish apologizing for not attending a funeral because she didn't find out about it until she came to that city for a visit some unspecified time later. It’s clearly evidence of a death but gives nothing to put in a DATE or PLAC tag. A “Y” would be just as redundant as if a DATE or PLAC were there.

2. A “Y” with nothing else: Steven’s Death: (date unknown) would be an improvement. So would my (deceased), i.e., without the “Death:” prefix. I prefer the latter (else I would not have suggested it) but I would not protest the former.

3. A “Y” with PLAC and/or DATE: treat as if the redundant “Y” were not there

4. No DATE or PLAC but SOUR, with or without redundant “Y”: Since sources are not shown here (and elsewhere if sources are “OFF”), treat as #2 above.

5. DATE or PLAC but not both: leave out the “ -- ” separator.