INDI.NAME.RESN

[fisharebest]

Recent changes have added RESN to different objects/structures. This is great.

Do we also need to add it to INDI.NAME?

I use this a lot in my own tree/software. For example:

1 NAME Max /Mustermann/
1 NAME Max Adolf /Mustermann/
2 RESN confidential
2 NOTE Max asked that we hide his middle-name

[tychonievich]

Discussed 2022-11-29 Pro: RESN provides useful flexibility, and names can be confidential. Con: It's not clear why names are more worth restricting than many other kinds of data (e.g. birth years, participation in various events, having had a child later given to adoption, etc), and there may be programmatic overhead to allowing RESN to all structures. Proposed: we discuss instead the general problem "can we allow RESN everywhere"?

We are not yet ready to commit to adding universal RESN in 7.1; it seems likely that there are places where RESN will not work for many implementations (e.g. CHAN.DATE.TIME.RESN) but we cannot yet articulate the difference between it and INDI.NAME.RESN. Perhaps the difference is metadata (like CHAN) vs historical claim (like NAME) vs part-of-claim (like TRAN or PHRASE)?

It may be we cannot come up with a simple rule and will handle these case-by-case; if we do, we tentatively agree that NAME should allow RESN.

We'll revisit this in a coming steering committee meeting. Opinions from the community are invited.

[fisharebest]

It's not clear why names are more worth restricting than many other kinds of data

We allow restrictions on facts and events. Names are just a particular type of fact.

Many people have previous names which they would not want made public.

One example might be a woman who briefly took a married name of a man who then became a notorious criminal.

Proposed: we discuss instead the general problem "can we allow RESN everywhere"?

The only other place I have found where RESN would be useful is INDI.DEAT.CAUS. There are many causes of death which some societies consider shameful. e.g. suicide, AIDS, etc.

For this (and similar attributes of facts/events) there is a simple workaround available. Create two death records, one with CAUS+RESN and one without.

So at this stage, I don't think it is necessary to consider RESN at any lower levels.

[chronoplexsoftware]

We have supported restrictions on names for many years in response to client requests for this feature. Name privacy is also supported by several other applications. We currently have to use custom GEDCOM extensions to support this and being able to use standard tags for this would simplify our implemetation and future interoperability.

However, it may well be the case that the current design of RESN is flawed. More generally, there does not appear to be a clear rationale for why flagging data for confidentialty, and locking data to prevent changes are linked in this one field, except that they are some kind of restriction, and in the current cases where RESN is used, both make sense and could apply at the same time. Moving forward it may be more helpful to consider confidentiality and change control as separate concepts, the scope of use for which would be much simpler to define.

[tychonievich]

@chronoplexsoftware Thanks for your feedback. We agree that RESN is not the structure we would have designed, but it seems to work for the case you noted in that it can have CONFIDENTIALITY, LOCKED, or both. If we have missed something about this issue, please file a new issue about RESN and your recommendations for it.

[chronoplexsoftware]

Our comments about the design of RESN relate to the points you made in this issue on the challenges in determining rules on where to permit the use of RESN. To use RESN, it seems necessary that the associated structure would logically support a concept of confidentiality and change protection (and any future enumeration that may be added).

You suggested difficulty distinguishing between CHAN.DATE.TIME.RESN and INDI.NAME.RESN. For the former, we can see how LOCKED makes sense if the parent record is also LOCKED but it is not clear why a change date would need to be considered CONFIDENTIAL in the context of genealogical data. This would seem to be a clear distinction between the two uses.

Having separate tags for confidentiality and change protection, simplies the issue determining rules on where each can logically apply.

We provided extensive comments on RESN here: https://github.com/FamilySearch/GEDCOM/issues/280#issuecomment-1465187751

[dthaler]

Discussed in GEDCOM Steering Committee 3 SEP 2024:

• Reopened since this is not yet done in the v71 branch (the next-minor branch is not active any more).
• We believe this is likely to be used if added to 7.1 by at least two applications, based on feedback from implementers, so adding this to the 7.1 list.
• We need a PR to propagate the change from next-minor to the v71 branch.
• We also discussed cases where one might want to hide former names for privacy reasons (like a witness protection program for instance) that only matters while they are alive. However there's no current RESN value that means private-until-death. As a result, this might result in other databases/apps not knowing that two people are the same, after the need has passed to maintain confidentiality of the fact that they are the same person. As such, it might be good to add such a RESN value in the future if apps would use it.