Structure for proposing new events

[tychonievich]

This adds to the repository a set of documents where we can track the pros and cons of the 100+ events and attributes proposed in #117, along with a place to document the criteria we use to decide what should be included and what should not. It does not make any changes to the specification itself.

This PR also initializes the tracking documents with the event and attribute types found in the FamilySearch API documentation, for no better reason than that I happen to be working with that in my own code lately so it's fresh on my mind. If we like it we'd of course add many more proposals to the documents in the future.

[dthaler]

How would we track things like the child-parent relationship type from the FamilySearch API, which is on a per parent basis, not on a per FAMC basis? https://www.familysearch.org/developers/docs/api/tree/Create_Child_and_Parents_Relationship_usecase shows an example where one parent is BiologicalParent and the other is AdoptiveParent.

[tychonievich]

Discussed in steering committee. Various changes to format discussed, including:

• Move URI to description instead
• Make sections for NoChildren, etc
• Change "v7.x" to "Added" and look up 5.5.1 vs 5.4 etc
• Add all current 7.0 events/attributes to the tables, with links to section of spec
• Change the "proposed additions" text
• Add note in readme that things that aren't events/attributes can be filed as issues instead

[Norwegian-Sardines]

One of the “criteria” or comments connected with these discussions is the “Use” where do other software applications use/create Attributes/Events not in the v5.5.1 GEDCOM. I’ve stopped using most of these programs because they don’t support the TYPE tag I call this the lack of typification! So I’ve introduced multiple “facts” by using typification. So can just the concept of use by a large application solely justify inclusion if they currently don’t support typification?

If typification is not considered. Then many other tags could be added, many of then take into account better internationalization, historical constructs or non-western cultures.

[tychonievich]

@Norwegian-Sardines your example touches on all three criteria:

• Wanting to record something suggests it is valuable
• Preferring to do it as an existing structure with a TYPE suggests it is not absent
• Applications not having a specific structure for it suggests it is not used

The names of the criteria might not be the best (I'd welcome alternative names!) but if we find a lot of FACT.TYPE Military service in the wild that would suggest it is valuable but not used. If we find a lot of _MIL that would suggest it is used.

Event TYPE substructures have been part of the spec since 5.3. I wonder if its lack of support suggests some difficulty in implementation or user interface? I'd be interested in reaching out to those companies and asking why they don't support it.

[Norwegian-Sardines]

Event TYPE substructures have been part of the spec since 5.3. I wonder if its lack of support suggests some difficulty in implementation or user interface? I'd be interested in reaching out to those companies and asking why they don't support it.

Yes it would be very interesting to ask those companies why they don't use it. Two of the three programs I have installed don't use theml. One does and that is my primary application!

My suspicion is that their databases and large code base may have been designed interfacing with or emulating PAF and the GEDCOM v5.0 spec ('91), and that they did not see any advantage to go beyond that design. I've talked to some support people on other applications and they felt that GEDCOM gave them the ability to add custom tags so why not use them!

I have some thoughts about the main purpose of this thread, and will add them in a separate entry!

[Norwegian-Sardines]

Introducing New Attribute/Event Tags vs Better Typification

I have a few points that need to be outlined and investigated as part of this discussion.

1. GEDCOM files “in the wild”
2. Typification of base Attributes/Events.
3. Internationalization, cultural sensitivity, subject expertise

In the Wild GEDCOM

This body seems to rely heavily on GEDCOMs from the wild to drive its decision-making processes. I agree that having a collection of sample/example files is an important part of the data gathering process, specifically as a starting point for understanding what tags are used. However, have we done any analysis on these files to determine their validity and usefulness? In statistical analysis we must be sure that the members of the sample represent the entire population. The questions I have are:

1. What is the “origin application” for each of these files?
2. Are they a good cross section of all applications?
3. Have the files been checked for origin date from the producing software?
4. Are they culturally/regionally diverse?
5. Do these files produce “custom tags” that have valid GEDCOM alternatives?

Typification of Attributes and Events

In data design we struggle with containing the breadth and width of the data structure. A serious look at the types of data being represented to prevent the breadth of the Attributes and Events needed for inclusion in any future Standard. Part of the job of considering any new addition Attribute/Event is the possibility of the addition being similar to or a continuation of another Attribute/Event. Typification of Event/Attribute would allow for queries to group similar events together in a single query.
There are several examples of this in the suggested additions from GEDCOM-X.

• The addition suggests multiple new “union” types, but MARR can be Typified as either, a) Religious, b) Civil, c) Common Law, d) Partnership, e) other/phrase
• The additions suggest multiple “military based” events. A single event MILT with Typification of, a) induction, b) commission, c) discharge, d) engagement, e) registration, f) deployment, g) other/phrase (NOTE: GEDCOM X has a dozen or more of these, some are subset of others (there are over 300 separation codes as part of a “discharge”. AWOL, Desertion being one)
• The BURI event can be use in several ways, a) Inhumation, b) Burial at Sea, c) Cremation, d) Donation to Research, e) Lost, f) Natural, g) Green, h) Burial Tree or Scaffolding, i) cave, j) other/phrase
• The additions suggest “health based” events. A singular HELT event with Typification of, a) surgery, b) illness, c) hospitalization, d) other/phrase, with a set of definitions that explain the use cases could work to reduce the breadth of new events
• The additions suggest “travel related” events. I would like to rethink this entire concept. I’m not a fan of having separate IMMI and EMMI events rather (I’ve had need to document the “travel” between these events) I would like to see a Typification of moving events that encompass more variety in scope. I’m not sure if the event name Travel (TRVL), Movement (MOVE), Transit (TRANS) have possibilities to encompass the concept. Typification could be, a) Immigration, b) Emigration, c) Vacation, d) Visitation, e) other/phrase
• DNA. I’m not an expert in this area, but I would look to find a way to Typify the various options. One way could be:

1 DNA H
2 TYPE mtDNA

1 DNA R1
2 TYPE Y-DNA

• National ID Number (IDNO) and Social Security Number (SSN) are both “types” from the same concept and should be combined using Typification!
• Physical Description (DSCR) would be a great Attribute to use Typification to identify all values of an individual’s physical description, TYPE enumeration could include {height, weight, eye color, tattoos, skin color, hair color, scars, lost limbs, other/phrase}. Doing this would eliminate the need for adding a dozen attributes used by the military and other recording entities, as well as the cumbersome descriptive list suggested by v5.5.1 GEDCOM. For example:

1 DSCR Brown
2 TYPE Hair

• National or Tribal Origin (NATI) would benefit from Typification. The definition includes: national origin or other folk, house, kindred, lineage, or tribal interest. Use example:

1 NATI Norwegian
2 TYPE National Origin

1 NATI <Tribal Name>
2 TYPE Tribe

1 NATI <Farm Name>
2 TYPE Farm 

1 NATI Atreides
2 TYPE House

1 NATI Mackenzie
2 TYPE Clan

Internationalization, cultural sensitivity, subject expertise

I think that an important goal for this discussion is the inclusion of more data-points in the area of “Internationalization, cultural sensitivity, and subject expertise”.
I’ve already indicated that I’m not an expert in DNA so my concepts above may not be 100% correct. Genealogy is a science that requires some levels of expertise from various cultural and historical perspectives. My interpretation of some of the constructs of past GEDCOM Standards are that cultural concepts in recording Genealogical data were out of the scope and expertise of the original designers. This is not to condemn them for any wrongdoing, I’ve been doing genealogical research for over 40 years in various European locations, but I can’t say that I know all or understand all concepts, let alone understand those of Asian, Middle Eastern, South American or Native cultures.
While researching information for others I’ve come across historical uses for terms that are not covered by the current GEDCOM and may be out of the scope of understanding by the “steering committee”. One example is in Switzerland, the so-called "Bürgerort" (Place of origin). We know through historical context that many cultures (Asian, Middle Eastern) also used “place of origin” to record census information and collect taxes. Individuals/Families were required to return to their ancestral home to be counted. These cultures will use different names for these, and Typification can be used to support/provide a single GEDCOM “Fact” to record the location, but also provide value to support each culture’s term. For example:

1 ORGN <location name>
2 TYPE Bürgerort

Individuals with more expertise in other cultures should be found to investigate and bring together concepts that are found in multiple cultures but are called different things. Enumeration of TYPE values will also help in the translation effort that many applications could use to expand their customer base. The application I use does a lot of tag translations to support multiple languages from around the world and enumerated TYPE would be a step forward.