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.