Event and attribute reorganization

[tychonievich]

In #117 we have at time of writing) around 200 event and attribute types under consideration. Implementing that feels painful to me.

What if we introduce a streamlined event and attribute system with just a few tags based on (a) how the event/attribute type is edited and (b) what can be inferred from it?

Tentatively, I propose the following

• Events
  • Couple
    • FAM.JOIN relates to the creating a coupling
    • FAM.SPLIT relates to the removing a coupling
    • FAM.EVENT is other events related to a couple or family
  • Individual
    • INDI.CHILD connects a child to a family, either at birth or later; they have FAMC substructures
    • INDI.DEATH related to the end of life and events contingent on that
    • INDI.FAITH are events associated with a faith or religion
    • INDI.CHANGE marks the change of some attribute; they have a substructure identifying which attributes changed
    • INDI.EVENT is other events in a person's life
• Attributes
  • COUNT has an integer payload, like NCHI
  • FORMAL is a payload controlled by some external standard or body, like IDNO
  • INDI.MEMBERSHIP has a payload describing a group that a person is associated with in some way
  • PFACT is another property, fact, attribute, characteristic, or trait

We introduce two types of TYPE-like qualifiers: the current free-text TYPE and a new enumerated (or URI) KIND

We keep the current event and attribute tags (for backwards compatibility) but redefine them as short hand for the new system; for example, FAM.MARB might be redefined as short hand for FAM.JOIN with KIND MARB and INDI.NATI might be redefined as INDI.MEMBERSHIP with KIND NATI.

My hope is that this would allow code could be written to handle each structure type mostly without worrying about the specific KIND. KIND would be needed for labeling, but that could be done with a simple look-up table. There would probably still also be a few application-specific special cases such as how some applications currently look for BIRT.DATE to default privacy restrictions.

I realize this is a big proposed change; thoughts?

[cdhorn]

It is a lot, agree. I am unsure how many more you might end up with, probably not many, and maybe some in the list can be rationalized away. I think once the exercise is done you end up in that ballpark and have 80% or more of the use cases covered unlike today and then it likely shouldn't need to change. The remaining 20% gets handled under the generic tag for custom events or facts.

I interpret this proposal as just converting the tags so they represent categories and shifting the specific type down into the kind field. It would work, maybe I miss something but it also seems like it adds an unnecessary layer and more work than is needed.

In my mind the primary concern of a data transfer envelope like Gedcom should be structuring the data such that the importing application understands the context of the information so the content can be stored properly in the applications own data model. I am unsure adding an extra layer here does anything to improve context, how to categorize groups of types seems like an application level concern to me. At least those are my thoughts at the moment, maybe I am misunderstanding something.

[cdhorn]

@tychonievich I never got around to submitting a PR to add additional event and attribute information. I started looking at it again today for the first time in many months and stepped back from that for now. Instead I have gone ahead and compiled a survey of sorts of the predefined facts provided by FindMyPast, MyHeritage, Ancestry, Geneanet, Filae, FamilySearch, and Gramps since I am familiar with that. Filae was not of much interest, they only seem to support the predefined events/attributes provided by the Gedcom standard. The others all provide predefined ones for users to select that are not enumerated in the standard. A few platforms group them in categories and I captured that information as well. Some of that seems not well thought out. Anyway, the current copy of the compiled document is attached, I hope maybe it is of possible use to the committee and others:

facts_survey.ods

[kiwi3685]

That looks very useful. But what I think would make it better would be:
1 - instead of the "Y" mark, enter the actual tag each organisation uses. Presumably they all use them, even if only gor exporting data to GEDCOM files.
2 - add another column for GEDCOM, with it's existing tag for the same thing, where it exists.

[cdhorn]

1 - instead of the "Y" mark, enter the actual tag each organisation uses. Presumably they all use them, even if only gor exporting data to GEDCOM files.

Yes, that will take more time but is the next logical step.

I am wondering which ones the more popular desktop software packages for Windows and Mac based machines provide. Some of that was documented on the CompGen site but it was from the custom tag angle. I think this format may be a more useful approach.

[cdhorn]

1 - instead of the "Y" mark, enter the actual tag each organisation uses. Presumably they all use them, even if only gor exporting data to GEDCOM files.

Yes, that will take more time but is the next logical step.

I have started work on this process, and am going to include data from some desktop applications like Heredis and the AncestralQuest and RootsMagic "free" editions.

[cdhorn]

@tychonievich @kiwi3685 I iterated on my fact (attribute/event) survey document this weekend and the latest copy is attached. It could have some errors, it's a bit of data to try to gather and dig through. Should be easy enough to figure out. Gedcom rows are in bold of course. I added Gedcom and GedcomX columns. I include information on how the data is tagged in the Gedcom exports for the different platforms/programs. I hope you find this of use, I think this format works well, at least for what I think I may try to do with it.

facts-survey-2025-01-05.ods

[tychonievich]

Thanks, this is very helpful! I've sometimes looked for some of these individually, but never tried to compile a large list like this.