Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion registry_tools/GEDCOM.io
38 changes: 38 additions & 0 deletions structure/extension/RESN_relocated.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
%YAML 1.2
---
lang: en-US

type: structure relocation
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


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

# This relocates the standard RESN structure to ASSO context
# No custom extension tag needed - uses standard RESN

specification:
- Association Privacy Restriction
- |
Uses the standard GEDCOM 7 RESN (restriction) structure relocated
to the ASSO context. This indicates privacy or access restrictions
for this specific association.

Standard RESN values apply:
- CONFIDENTIAL: This association is confidential
- LOCKED: This association should not be changed
- PRIVACY: This association should be treated as private

Applications should respect these restrictions by:
- Excluding restricted associations from public reports
- Requiring additional authentication to view
- Preventing changes to LOCKED associations

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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Recommend adding to all YAML files in this PR:

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

relocated from: https://gedcom.io/terms/v7/RESN

superstructures:
"https://gedcom.io/terms/v7/ASSO": "{0:1}"

contact: lamberson@yahoo.com
...
39 changes: 39 additions & 0 deletions structure/extension/TYPE_relocated.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
%YAML 1.2
---
lang: en-US

type: structure relocation

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

# This relocates the standard TYPE structure to ASSO context
# No custom extension tag needed - uses standard TYPE

specification:
- Association Type
- |
Uses the standard GEDCOM 7 TYPE structure relocated to the ASSO context.
This provides a user-defined classification or type of the association
to supplement the ROLE value.

TYPE provides free-text description to accommodate various relationship
types across cultures and time periods, while ROLE provides the
standardized relationship term.

Examples:
- TYPE "Godparent" with ROLE "GODP"
- TYPE "Business Partnership" with ROLE "OTHER"
- TYPE "Military Service" with ROLE "OTHER"
- TYPE "Childhood Friend" with ROLE "FRIEND"
- TYPE "Next-door Neighbor" with ROLE "NGHBR"

This approach reuses the standard TYPE structure, maintaining
consistency with how TYPE is used elsewhere in GEDCOM 7.

relocated from: https://gedcom.io/terms/v7/TYPE

superstructures:
"https://gedcom.io/terms/v7/ASSO": "{0:1}"

contact: lamberson@yahoo.com
...
45 changes: 45 additions & 0 deletions structure/extension/_CONF.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
%YAML 1.2
---
lang: en-US

type: structure

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

extension tags:
- _CONF

specification:
- Association Confidence
- |
Indicates the confidence level in the association assertion.
Uses the standard GEDCOM 7 QUAY (quality) enumeration:

0 = Unreliable evidence or estimated data
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
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


This reuses the standard QUAY enumeration for consistency with
GEDCOM 7 and to benefit from existing language translations.

Examples:
- 4: Business partnership documented in legal records
- 3: Godparent relationship from church baptism record
- 1: Possible sibling based on census proximity and ages
- 0: Family legend of relationship, no documentation

label: 'Confidence Level'

payload: https://gedcom.io/terms/v7/type-Enum

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

substructures: {}

superstructures:
"https://gedcom.io/terms/v7/ASSO": "{0:1}"

contact: lamberson@yahoo.com
...
35 changes: 35 additions & 0 deletions structure/extension/_END.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
%YAML 1.2
---
lang: en-US

type: structure

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

extension tags: [ _END ]

specification:
- Association End Date
- |
The date when an association ended. Uses standard GEDCOM 7 date format,
allowing for exact dates, date ranges, and approximate dates.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


Examples:
- "15 MAY 1868" - Exact date ward reached majority
- "JUN 1867" - Month business partnership dissolved
- "8 MAY 1945" - End of military service (VE Day)
- "BEF 1960" - Friendship ended sometime before this date

label: 'End Date'

payload: https://gedcom.io/terms/v7/type-Date

substructures:
"https://gedcom.io/terms/v7/PHRASE": "{0:1}"
"https://gedcom.io/terms/v7/TIME": "{0:1}"

superstructures:
"https://github.com/glamberson/gedcom-extended-ASSO/_PERIOD": "{0:1}"

contact: lamberson@yahoo.com
...
53 changes: 53 additions & 0 deletions structure/extension/_PERIOD.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
%YAML 1.2
---
lang: en-US

type: structure

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

extension tags:
- _PERIOD

specification:
- Date Period Container
- |
Container structure for defining the time boundaries of any dateable item.
Allows specification of when something began and/or ended using full
GEDCOM 7 Date syntax (including ranges and approximations).

Either START or END may be omitted if unknown. If both are omitted,
the PERIOD structure should not be used.

This structure can be used with any context that needs to express
a time period with explicit start and/or end dates, not limited to
associations.

Examples in ASSO context:
- Godparent relationship: START at baptism, END at ward's majority
- Employment: START date of hire, END date of termination
- Military service: START at enlistment, END at discharge
- Friendship: May have only START if still ongoing

Could also be used with other contexts like:
- Residence periods
- Educational enrollments
- Memberships
- Any time-bounded relationship or status

label: 'Date Period Container'

payload: null

substructures:
"https://github.com/glamberson/gedcom-extended-ASSO/_START": "{0:1}"
"https://github.com/glamberson/gedcom-extended-ASSO/_END": "{0:1}"

superstructures:
"https://gedcom.io/terms/v7/ASSO": "{0:1}"
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

"https://gedcom.io/terms/v7/DATE": "{0:1}"

prerelease: true

contact: lamberson@yahoo.com
...
35 changes: 35 additions & 0 deletions structure/extension/_START.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
%YAML 1.2
---
lang: en-US

type: structure

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

extension tags: [ _START ]
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use block format

Suggested change
extension tags: [ _START ]
extension tags:
- _START


specification:
- Association Start Date
- |
The date when an association began. Uses standard GEDCOM 7 date format,
allowing for exact dates, date ranges, and approximate dates.

Examples:
- "15 MAY 1850" - Exact date of baptism for godparent relationship
- "1845" - Year-only for business partnership
- "ABT 1920" - Approximate date for friendship
- "BEF 1863" - Known to have started before a certain date

label: 'Start Date'

payload: https://gedcom.io/terms/v7/type-Date

substructures:
"https://gedcom.io/terms/v7/PHRASE": "{0:1}"
"https://gedcom.io/terms/v7/TIME": "{0:1}"

superstructures:
"https://github.com/glamberson/gedcom-extended-ASSO/_PERIOD": "{0:1}"

contact: lamberson@yahoo.com
...
Loading