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

Add SUBM to every other record type #532

Open
albertemmerich opened this issue Aug 11, 2024 · 8 comments
Open

Add SUBM to every other record type #532

albertemmerich opened this issue Aug 11, 2024 · 8 comments

Comments

@albertemmerich
Copy link
Collaborator

So far

+1 SUBM @<XREF:SUBM>@                    {0:M}  g7:SUBM

is only allowed in some record types, however not in SOUR, REPO, OBJE, SNOTE. I do not see a good reason to prohibit to transfer this information, too.

It should be allowed in all record types, excluding SUBM itself.

@Norwegian-Sardines
Copy link

How would you use SUBM (Submitter) in the following record types:
Repository_Record, Shared_Note_Record?

I can see that some-one giving me a photo or provided to me a book could be considered a submitter to me (this is a providence question), I brought this up in #347

@Norwegian-Sardines
Copy link

I don't think I got a good answer on this question (Giver of a photo) and I'm still thinking about the providence of other gifted source material to me!

@albertemmerich
Copy link
Collaborator Author

Situations where I already use the SUBM (extension _SUBM) in all records:

  1. import of GEDCOM file to a database which is shared by a team. My application has an option to to put the SUBM taken from HEAD of GEDCOM file to every record imported by the GEDCOM file. So after several imports we can see who was submitter of any record. After merging there may be more than one submitter.
  2. team working in a database. My application offers the possibility to add the information, who in the team created a new record, and who updated the record. Again stored using SUBM (_SUBM).

I think "giver of a photograph" is different. It is more like author of a book, if it is the person who took the photograph. Submitter is more a transfer of data. So if "giver of a photograph" is a person who passed the photograph to a database, but did not take the photograph, then he would be the submitter. In this case we can use SUBM (_SUBM) in OBJE.

@Norwegian-Sardines
Copy link

So you are saying you want to track who added a “Repository” and “Note” to a shared database! Sounds plausible to me!

I would then also request that each SUBM (on all uses of the SUBM tag have a subtag of DATE. This way you can also track when they merged an update into the record. This SUBM.DATE is better than looking at the CHAN.DATE because any other change to the record would overlay the date of the merge. Also if multiple SUBM tags exist having this SUBM.DATE would help to maintain who created the record and who updated it and when!

@albertemmerich
Copy link
Collaborator Author

Correct.
And I follow your proposal to have the substructure DATE with DATE.TIME. So far I use another extension for it, example:

1 _SUBM @U13@
2 _UPD 2024-05-12T11:21:47Z

To document creation of record, I have

1 CREA
2 DATE 3 MAR 2024
3 TIME 10:56:37Z
2 _SUBM @U13@

which will not be overwritten by an update of same submitter. However could be modified by

1 SUBM @U13@
2 CREA
3 DATE 3 MAR 2024
4 TIME 10:56:37Z

if we prefer to have the SUBM only on level 1.

@dthaler
Copy link
Collaborator

dthaler commented Aug 13, 2024

My opinion: After merging multiple records from multiple submitters into one record, I find it increasingly less useful to have SUBM at the level of a record. That is, one ends up with (say) 4 SUBM structures in the record, and no way to know who submitted what part of the record. In contrast, having it at lower levels provides more details. For example, if SUBM were added to the <<SOURCE_CITATION> block.

@Norwegian-Sardines
Copy link

I agree that SUBM should be included at the lower levels. Most likely just below level 1, for example “facts”. We do need to be careful that we don’t get too detailed, such as a merge that changes a .DATE or .CAUS only. I realize that this level (below level 2) is valuable, but I would set a line for application based change control vs GEDCOM change documentation at this point! I’d have to think hard about adding SUBM to the <<SOURCE_CITATION>> block.

@dthaler
Copy link
Collaborator

dthaler commented Aug 20, 2024

Discussion during GEDCOM Steering Committee 20 AUG 2024:

  • SUBM on an event means that submitter only modified or contributed that event and other information in the record (unless the submitter is also under other places)
  • SUBM on a record means the submitter may have modified or contributed any or all of the information in the entire record.
  • The same two points above would apply to sources in <<SOURCE_CITATION>> at different levels as well.
  • Adding SUBM to SOURCE_CITATION (at level n not n+1) saves text. Unknown yet whether this is the best way but not sufficient as noted below. If we did, then maybe SOURCE_CITATION should be renamed, which is straightforward since that name is just a documentation construct and never appears in the GEDCOM file.
  • Some places like REPOSITORY_RECORD have no SOURCE_CITATION and would still need a SUBM added.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants