Confused by the use of PHRASE in the ADOP tag.

[Norwegian-Sardines]

n ADOP [Y|<NULL>] 
+1 TYPE <Text>
+1 <<INDIVIDUAL_EVENT_DETAIL>>
+1 FAMC @<XREF:FAM>@ 
   +2 ADOP <Enum>
      +3 PHRASE <Text>

How is the tag PHRASE used in this context? The ADOP.FAMC.ADOP indicates one of the enum values as [WIFE | HUSB | BOTH], normally the use of PHRASE stems from a need to find another term not found in the standard enum list, and the enum list includes an OTHER option. Other does not make sense in the "Family" context if the only individuals that can adopt a child are the two principles ("the couple") in the family with the indication of WIFE/HUSB not referring to the "sex" of the principle but the position in the family_record.

Should PHRASE be removed, should OTHER be added? Explain the use case.

[tychonievich]

PHRASE can be used without OTHER; for example, it could share the text used to indicate who was doing the adoption in the source

1 ADOP
2 FAMC @F1@
3 ADOP BOTH
4 PHRASE Mr. and Mrs. Bruce Smith

[Norwegian-Sardines]

This would make more sense to me if it was name TEXT rather than PHRASE because of the use cases elsewhere in the standard.

[tychonievich]

Discussed in steering committee

• We agree that this case is not clear.
• We think that clarifying the cases where an enumeration set does not include OTHER but does have a PHRASE (including FAMC.ADOP and FAMC.STAT) would be worth doing, perhaps by adding examples to the specification. That example might belong in the enumeration set definition sections.
  • We should be careful in handling the difference between INDI.FAMC.STAT.PHRASE and INDI.FAMC.NOTE. We briefly discussed this in the committee meeting, but did not come to a clear distinction. We'll revisit that later.
• Changing PHRASE to TEXT for ADOP could only be done in 8.0, but might be worth revisiting then. Changing it for FAMC.STAT might not make sense.

[Norwegian-Sardines]

Changing it for FAMC.STAT might not make sense.

Again, I'd like to see the use-case that generated this requirement/need for the PHRASE. Are there design notes about the addition or was it added because PEDI had a PHRASE

The options are [CHALLENGED | DISPROVEN | PROVEN]

If we set a status (STAT):
Does the PHRASE become a NOTE like statement about how/why we decided the setting?
Does the PHRASE become a TEXT statement based on a quote from the source artifact telling us the status?

1 FAMC
2 STAT CHALLENGED
3 TEXT I. M. Helper says: "Many people in this town had similar names to this family, we are speculating about the connection." 

Personally, I think that the all PHRASE tags should have a common expected use-case, which should be only used when a superior tag is an "Enum" with an option of OTHER.

The current set of options are clearly "conclusion based" and "The Committee" thinks that GEDCOM is not a conclusion, so PROPOSED could follow their thinking which would require adding the option of OTHER, with an explanation of how it could be used!

[tychonievich]

Discussed in steering committee

• Are there design notes about the addition or was it added because PEDI had a PHRASE

  No, during drafting v7.0.0 we did not keep design notes about this decision. The members of the steering committee who were part of that also do not remember the reasoning.

• @Norwegian-Sardines comments about conclusions are interesting. Even what "conclusion" means is not clear (some committee members initially interpreted it differently than others): it is sometimes used to mean "the researcher made a decision not directly in a source" and sometimes used to mean "the data represents a view of history rather than the competing evidences considered by the researcher". It is true that different parts of GEDCOM appear to serve different goals, with more structures for describing history than for describing research, and that sometimes the interplay of these is not clear. We agree that this should be thought about in more detail and likely made more explicit for future versions of the specification.

  The need to think about this more was clear to the 7.0.0 drafting team too; for example, the specification says in describing QUAY "The structures for representing the strength of and confidence in various claims are known to be inadequate and are likely to change in a future version of this specification." While we had working groups discussing that then we decided there was too much to consider to allow a timely release of 7.0.0 and did not include it there. It's also a very old issue, with Bill Harten who drafted the first GEDCOM standard in the 1980s having considered it and introduced "LINEAGE_LINKED" into GEDCOM as a placeholder to allow future research-oriented versions to be created. We still list a hypothesis working group on gedcom.io, but it is currently inactive. If anyone is interested in joining that group, let us know.

  Several other issues and discussions here (such as several of @mother10's posts) have also addressed hypothesis and research design ideas. In general, we find many ideas but little consensus on them, and relatively few applications to use as models. That said, it is definitely something we want to tackle at some point.