Add GEDCOM Extended ASSO structures by glamberson · Pull Request #185 · FamilySearch/GEDCOM-registries

glamberson · 2025-08-04T22:17:51Z

Summary

This PR adds extension structures to enhance the standard GEDCOM 7 ASSO (association) tag with additional capabilities while maintaining backward compatibility.

Extension Features

The gedcom-extended-ASSO extension adds six new substructures to ASSO:

_TYPE - Specifies the type of association beyond the standard ROLE
_PERIOD - Container for time boundaries of the association
_START - When the association began
_END - When the association ended
_CONF - Confidence level (0-4 scale matching GEDCOM 7's QUAY)
_PRIV - Privacy flag for sensitive associations

Example Usage

0 @I1@ INDI
1 NAME John /Smith/
1 ASSO @I2@
2 ROLE Business Partner
2 _TYPE General Partnership
2 _PERIOD
3 _START 1845
3 _END JUN 1867
2 _CONF 4
2 NOTE Wilson & Associates Mercantile

Backward Compatibility

Applications that don't support this extension will:

See and preserve the standard ASSO structure
Ignore all extension tags
Maintain data integrity on import/export

Documentation

Full specification: https://github.com/glamberson/gedcom-extended-ASSO
Examples: https://github.com/glamberson/gedcom-extended-ASSO/tree/master/examples

Validation

All YAML files have been validated using the registry validator.

Contact: Greg Lamberson lamberson@yahoo.com

This extension enhances the GEDCOM 7 ASSO (association) structure to support: - Time-bounded relationships (_PERIOD with _START/_END) - Confidence levels in relationship assertions (_CONF) - Specific relationship types (_TYPE) - Relationship-specific privacy (_PRIV) All structures are extension substructures of the standard ASSO tag. The extension maintains backward compatibility - applications that don't support it will simply ignore the extension tags. Specification: https://github.com/glamberson/gedcom-extended-ASSO Contact: Greg Lamberson <lamberson@yahoo.com>

dthaler · 2025-08-07T14:48:17Z

+    3 = Direct source, primary evidence, data considered reliable
+    4 = Well-supported conclusion from primary evidence
+
+    This scale matches GEDCOM 7's QUAY (quality) values for consistency.


If the intent is to match QUAY then why not use

payload: https://gedcom.io/terms/v7/type-Enum enumeration set: "https://gedcom.io/terms/v7/enumset-QUAY"

?

Currently with Integer, a validator would accept values of 5, 5000, etc., which with Enum it would reject.
And reusing the standard type means that any language translations of the standard YAML files would automatically apply here too.

Because it doesn't match QUAY which only provides 0-3 instead of the needed 0-4 or 1-5 . Having 5 levels matches genealogical standards, and 4 doesn't. Thus people don't like to use it. I didn't consider altering QUAY, but that's the rationale for not using it. I'll use it for now, though. This is wearing me down.

dthaler · 2025-08-07T14:53:57Z

+  "https://github.com/glamberson/gedcom-extended-ASSO/_END": "{0:1}"
+
+superstructures:
+  "https://gedcom.io/terms/v7/ASSO": "{0:1}"


This extension uses two structures of type Date rather than one structure of type DatePeriod.
I gather this is so you can use ranges etc with each end.
This concept doesn't seem specific to ASSO. Why not a superstructure of (say)
https://gedcom.io/terms/v7/DATE?

Great idea, but I clearly don't have the fluidity of thought about substructures and superstructures I should. There's certainly no reason to limit its use to ASSO.

dthaler · 2025-08-07T14:55:37Z

+
+uri: https://github.com/glamberson/gedcom-extended-ASSO/_PRIV
+
+extension tags: [ _PRIV ]


why not use a relocated RESN structure, since it already has a standard PRIVACY value?

Noted. Thanks.

dthaler · 2025-08-07T14:56:39Z

+
+type: structure
+
+uri: https://github.com/glamberson/gedcom-extended-ASSO/_TYPE


Why not use a relocated standard https://gedcom.io/terms/v7/TYPE structure?

Thanks again!

dthaler · 2025-08-07T15:19:39Z

+  - Association End Date
+  - |
+    The date when an association ended. Uses standard GEDCOM 7 date format,
+    allowing for exact dates, date ranges, and approximate dates.


Is a DatePeriod disallowed? Assuming so, say so.
It wouldn't seem to have any meaning here.

dthaler · 2025-08-07T15:21:00Z

+superstructures:
+  "https://gedcom.io/terms/v7/ASSO": "{0:1}"
+
+contact: lamberson@yahoo.com


Since there is no used by, I assume this is a proposal without any deployment yet, which is fine.
But in that case, you may want to use prerelease.

You may be right. My stance on these has changed at Gramps's approach has evolved. Still they're needed.

…h#185 - Changed _CONF to use standard QUAY enumeration instead of custom integer - Replaced _PRIV with RESN_relocated (standard RESN structure relocated to ASSO) - Replaced _TYPE with TYPE_relocated (standard TYPE structure relocated to ASSO) - Updated _PERIOD to be more general-purpose for any date period - Using structure relocation for standard GEDCOM structures per review guidance

glamberson · 2025-08-07T16:11:38Z

@dthaler I've addressed all your review feedback in commit ab54e98:

Changed _CONF to use standard QUAY enumeration instead of custom integer
Replaced _PRIV with RESN_relocated (standard RESN structure relocated to ASSO)
Replaced _TYPE with TYPE_relocated (standard TYPE structure relocated to ASSO)
Updated _PERIOD to be more general-purpose

All changes follow your guidance to reuse existing GEDCOM structures. Ready for re-review.

- Reset registry_tools/GEDCOM.io submodule to match upstream main branch

glamberson · 2025-08-12T09:59:58Z

i also reset this one. It shold be ok now too.

dthaler · 2025-08-14T14:46:41Z

+
+    This approach reuses the standard RESN structure and enumeration,
+    providing consistency with existing GEDCOM 7 privacy mechanisms.
+


Recommend adding to all YAML files in this PR:

documentation: - https://github.com/glamberson/gedcom-extended-ASSO

dthaler · 2025-08-14T14:47:31Z

+---
+lang: en-US
+
+type: structure relocation


https://gedcom.io/terms/format doesn't permit a value of 'structure relocation` here

The PR (#189) by @tychonievich doesn't talk about whether or how to register a relocated standard structure (since it focuses on "older" extensions), nor does the main README. I think we need more guidance here.

dthaler · 2025-08-14T14:54:36Z

+    1 = Questionable reliability of evidence  
+    2 = Secondary evidence, data probably reliable
+    3 = Direct source, primary evidence, data considered reliable
+    4 = Well-supported conclusion from primary evidence


This contradicts line 16. The standard QUAY enumeration has no value 4.

dthaler · 2025-08-14T14:55:43Z

+
+uri: https://github.com/glamberson/gedcom-extended-ASSO/_START
+
+extension tags: [ _START ]


Use block format

Suggested change

extension tags: [ _START ]

extension tags:

- _START

glamberson requested review from albertemmerich, clarkegj, dthaler and tychonievich as code owners August 4, 2025 22:17

dthaler reviewed Aug 7, 2025

View reviewed changes

Reset submodule to match upstream

9c00fb8

- Reset registry_tools/GEDCOM.io submodule to match upstream main branch

dthaler reviewed Aug 14, 2025

View reviewed changes


		uri: https://github.com/glamberson/gedcom-extended-ASSO/_PRIV

		extension tags: [ _PRIV ]


		type: structure

		uri: https://github.com/glamberson/gedcom-extended-ASSO/_TYPE


		This approach reuses the standard RESN structure and enumeration,
		providing consistency with existing GEDCOM 7 privacy mechanisms.


		uri: https://github.com/glamberson/gedcom-extended-ASSO/_START

		extension tags: [ _START ]

Conversation

glamberson commented Aug 4, 2025

Summary

Extension Features

Example Usage

Backward Compatibility

Documentation

Validation

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

glamberson commented Aug 7, 2025

Uh oh!

glamberson commented Aug 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants