Is RESN allowed at levels under level 1

[mariannevanharten]

In my Gedcom 5.5.1 tree some details are private, i.e.:
1 DEAT
2 DATE 3 FEB 1963
2 CAUS suicide
3 RESN CONFIDENTIAL

Only the cause is confidential, the date of death is public.
How to write this in Gedcom 7? I think:
1 DEAT
2 DATE 3 FEB 1963
snip
1 RESN CONFIDENTIAL
1 DEAT
2 CAUS suicide

What about using the same syntax of the Gedcom 5.5.1-tree?

[tychonievich]

The standard locations for RESN in 7.0 (and 5.5.1) are

• an entire INDI
• an entire FAM
• an entire OBJE (OBJE.RESN is a 7.0 addition, not in 5.5.1)
• an entire event or attribute

You can use the relocated standard structure feature of 7.0 to add a RESN in other locations; an example of relocating a RESN as a _RESN can be found in the technical FAQ, entry "How do I mark a parent-child relationship as confidential?" and adapted to this case would look like this:

0 HEAD
1 SCHMA
2 TAG _RESN https://gedcom.io/terms/v7/RESN
...
1 DEAT
2 DATE 3 FEB 1963
2 CAUS suicide
3 _RESN CONFIDENTIAL

You could also split the data into two DEAT structures: one with both a RESN and the CAUS and the other with neither RESN nor CAUS.

1 DEAT
2 DATE 3 FEB 1963
1 DEAT
2 DATE 3 FEB 1963
2 CAUS suicide
2 RESN CONFIDENTIAL

You could also make two INDIs, one with a RESN and the confidential information and one without, using ALIA to communicate that they are aspects of the same historical person; but ALIA is not very widely supported in applications today so I'd not recommend the ALIA approach.

None of these approaches is perfect. Some applications might complain about duplicate DEAT events, or ignore or complain about relocated standard structures, or even ignore RESN when it is used in accordance with the specification – many applications ignore parts of the GEDCOM files that they do not have user interface support for. Even with an application that supports everything, the FAQ note is still important: "with all confidential communications, it is important not only to mark the data as confidential but also to ensure that the recipient of the data understands in what cases they are to remove the confidential data and agrees to do so."