Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FAMC.PEDI.DATE #256

Open
dhesmer opened this issue Dec 23, 2022 · 5 comments
Open

FAMC.PEDI.DATE #256

dhesmer opened this issue Dec 23, 2022 · 5 comments
Assignees
Labels
awaiting use Waiting for evidence of vendor implementation and use next minor

Comments

@dhesmer
Copy link

dhesmer commented Dec 23, 2022

There are situations where individuals are foster children in different families at different times. In order to also document this in GEDCOM, a time stamp is required. Currently, this is not provided by the FAMC.PEDI structure.
+1 FAMC @XREF:FAM@
+2 PEDI
+3 PHRASE

To this current structure a
+3 DATE
should be added.

Currently the PHRASE could be used by a "FROM TO" Text.
Or ist a "+3 _DATE FROM ... TO ..." a better solution?

@tychonievich
Copy link
Collaborator

tychonievich commented Jan 24, 2023

Discussed in steering committee

We know of a practical need for this, including implementations today doing this as an extension. Adding FAMC.PEDI.DATE with a DateValue payload is planned for 7.1

@tychonievich tychonievich self-assigned this Jan 24, 2023
@tychonievich
Copy link
Collaborator

tychonievich commented Jan 31, 2023

Currently FAMC.PEDI is {0:1} so even with a date it can't have multiple such PEDI. My instinct is that this means we either want

(1) a date for the whole FAMC relationship

  +1 FAMC @<XREF:FAM>@                     {0:M}  g7:INDI-FAMC
     +2 DATE <DateValue>                   {0:1}  g7:DATE
     +2 PEDI <Enum>                        {0:1}  g7:PEDI

or (2) multiple PEDI for a single relationship

  +1 FAMC @<XREF:FAM>@                     {0:M}  g7:INDI-FAMC
     +2 PEDI <Enum>                        {0:M}  g7:PEDI
        +3 DATE <DateValue>                {0:1}  g7:DATE

not (3) a single dated-PEDI for an undated FAMC

  +1 FAMC @<XREF:FAM>@                     {0:M}  g7:INDI-FAMC
     +2 PEDI <Enum>                        {0:1}  g7:PEDI
        +3 DATE <DateValue>                {0:1}  g7:DATE

but I'd be interested in your take @dhesmer (as well as anyone else implementing this as an extension currently)

@dthaler
Copy link
Collaborator

dthaler commented Jan 31, 2023

Lets say a child was eventually adopted by their foster parents. So for some period of time PEDI FOSTER would apply and then eventually PEDI ADOPTED would apply to the same parents. Should that be two FAMC relationships, each with one PEDI, or one FAMC with two PEDIs?

This is a little similar to the case we dealt with in the remarriage1.ged and remarriage2.ged test files where we permit storing as either one or two families. So I think this argues for Luther's option (2) being at least permitted, even if multiple ways to represent are permitted.

@dhesmer
Copy link
Author

dhesmer commented Feb 2, 2023

As Dave Thaler noted that multiple PEDI relationships can occur, I prefer option 2.
This also corresponds essentially to my original request.

@dhesmer dhesmer closed this as completed Feb 2, 2023
@dhesmer dhesmer reopened this Feb 3, 2023
tychonievich added a commit that referenced this issue Feb 9, 2023
Also makes PEDI {0:M} not {0:1}, which could have use (e.g. when a child was both adopted by and fostered to the same family) even without knownig dates.
tychonievich added a commit that referenced this issue Mar 30, 2023
@dthaler
Copy link
Collaborator

dthaler commented Mar 7, 2024

PR #274 fixed this in the next-minor branch

@dthaler dthaler reopened this Mar 7, 2024
@dthaler dthaler added the awaiting use Waiting for evidence of vendor implementation and use label Mar 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting use Waiting for evidence of vendor implementation and use next minor
Projects
None yet
Development

No branches or pull requests

3 participants