Enhance vital events plus cremation to have an additional field

Bruce Compton

I would like to request an enhancement to the vital events plus the cremation event to add a field to these individual events to store details that apply to the individual event. The current schema does not provide a place to store this information. Examples of how I would use these free-text fields:

Christening Details

·        Christened at home

·        Baptized in the Moravian Church

Birth Details

·        Born at 3:00 am

·        Born at cousin Fred’s house

·        He was likely born in Caroline County, Virginia

Death Details

·        Died at the age of 103

·        Died at his son’s home

·        He likely died in Orange County

·        He went down with the Titanic

Burial Details

·        Buried in plot 3, grave 8

·        Buried in the family cemetery

·        Buried in an unmarked grave in the southeast corner of the cemetery

·        He is though to have been buried in the family cemetery, but there are no markers

·        Not buried Forest Park Cemetery; marker is a cenotaph

·        Reinterred in Forest Lawn Cemetery

Cremation Details

·        His cremains were buried in the family plot in Forest Park Cemetery

·        His cremains were scattered across the East Bay

Marriage Details

·        The couple eloped

·        Married at the home of the bride’s parents

Additionally, I would like to see a Cause of Death field added to the Death event.

I would expect that this data can be imported and exported via the API. I would also like for this text to be included in the auto-generated About page.

NancyO

I REALLY LIKE

your idea about Cause of Death!!!

I have even wondered about that when I have read obits in the newspaper---especially when the deceased is a youngish person.

Nancy in Alabama

Julia Szent-Györgyi

Most of those examples are exactly the sort of thing I would use the "reason" box for. (I see no reason to also say "from birth register entry" if said birth register entry is attached as a source and tagged to the conclusion, so I leave most reason boxes blank -- but this leaves them handily available for things like "born on route to the market".)

Bruce Compton

The Reason box doesn't transmit via the API, and it doesn't appear in the About narration. In RootsMagic, I anticipate that the data would map into the note field of the <event> details.

This is the sort of information that makes reading family history interesting. The rather dry BMDB and who-begat-whom report needs color to make it something worth sharing.

Alan E. Brown

@Bruce Compton said:

The Reason box doesn't transmit via the API...

The reason statement is indeed available via the API. See the changeMessage in Attribution: https://www.familysearch.org/developers/docs/api/types/xml_gx_Attribution

RTorchia

He was likely born in Caroline County, Virginia

FS really isn't built for guesses and speculation. While it'd be nice to have, it's a huge ask. Besides, who determines what "likely" is?

Marriage Details

There's a Notes section in Relationships that's perfect for this.

Bruce Compton

Thanks, Alan E. Brown. I stand corrected. I'll have to figure out what RootsMagic does with the text of the Reason statement. It is not found where I expected to find it.

The problem with relying on the Reason statement is that is often contains both notes and reasons. What I am in effect requesting is a place to store publication-grade notes that is separate from the justifications for the data. To allow both in the Reason statement means that the API user must manually parse the string to isolate the notes. Creating a new field reduces manual labor and improves inter-system operability.

Bruce Compton

@RTorchia

Being a purist myself, I agree with you that is incorrect to state that someone was likely born in a given place. Unfortunately, there are many (and I cannot say 'many' enough times) FamilyTree contributors who enter facts not in evidence. I have stumbled into edit wars with users who insist upon entering unsupported birth or death dates or places. I have reached a satisfactory comprise with some of them by deleting the place and adding a note in the reason statement, e.g.:

Likely died in Caroline County, Virginia, but this fact is not documented.

FamilyTree does not deal well with uncertainty, estimation and proximity, and this, among other things, scares off serious researchers. That's a topic for another day. I am doing the best that I can do to work with the functionality as designed.

Gail Swihart Watson

I believe all speculative information is valuable, but never in vitals or other information. I believe it should be in the collaborate area in either discussion or notes. I personally would choose notes. At some point speculation may be provable as true or false if the right historical document comes to light, but the speculation has to be visible to researchers first. Put it somewhere in collaborate.

Bruce Compton

@Gail Swihart Watson -- Speculation is a tangential point. What about the need for new fields in the vitals?

Alan E. Brown

There is already a place to put every detail suggested:

• Some specifics about a date or place an event occurred can be placed in the date or place field, even if it is not a standardized date/place (the entered date/place and standardized date/place don't have to match).
• Some of the details can be put in the reason statement
• Notes, sources, documents, etc. can be used for items that require additional detail.

Although there can be some benefits to adding additional fields as suggested, it must be noted that every additional field or option that is added to the data model has multiple costs:

• Engineering costs to implement (and forever maintain) in the database, backend services, user interface (multiple user interfaces for web and mobile and partner applications), developer APIs, etc.
• Efforts to transition data currently stored in other places to the new place (costs borne by FamilySearch and/or many thousand users)
• Additional complexity in the user interface, including confusion about whether the current or new ways of storing data are best, which makes it even harder for users to find the relevant data.

Although some people may not like the current way that certain details are stored, rarely do they consider the many costs of adding additional options. Personally, I find it hard to think the possible benefits come close to justifying the costs.

Bruce Compton

I formerly worked in the software industry, so I am well aware of priorities, time constraints, costs and cost-benefit analyses. I don't envy the designers of this application who must design for both sophisticated users and those who are challenged by the power button. I am not afraid of more complexity. People are more complex than simplicity suggests.

There may be a way to store each and every piece of information that I mentioned, but the current model could be enhanced to work with the About narrative and with the API. Inter-system operability is a weakness of FamilyTree, and design decisions must take into account that there are users who may not be using a browser and may not be viewing the Details page.