GEPS 003: Computed Ages and Probably Alive

From Gramps
Revision as of 11:28, 9 September 2010 by Bmcage (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This GEP is finished in Gramps 3.1

Proposed changes for enhancing GRAMPS by adding functions and infrastructure for supporting computed dates where dates are not known, and for creating a thorough "probably alive in year" functionality.

This GEP has been implemented in a number of ways:

Motivation

In almost every aspect of genealogy, having an idea of when someone was alive is necessary information. This proposal would allow for creating estimated or calculated dates for some events. In this manner, probably_alive could be based on these dates.

Details

Calculated and estimated dates are actually a defined date type in GEDCOM 5.5:

CAL =Calculated mathematically, for example, from an event date and age. 
EST =Estimated based on an algorithm using some other event date. 

An option in GRAMPS could be to create events where none exist, and fill in such a calculated date.

Alternatively, probably_alive could be stored as a date for each person with a start and stop, and associated confidence values for each start and stop points. These values could be used with the growing logic in Utils.probably_alive as substitute values when real values are not known. It would be very handy when sorting by dates to see these estimations. Also, in the main person view could show them to help distinguish between people with the same, or similar, names. Some other points:

  1. Filters based on probably_alive would be faster. No need to recompute for a different year, just compare any year to the start/stop points in person.probably_alive.
  2. People without birth/death events could use these values in displays and sortings.
  3. A different color/symbol/typeface might be used to show that these are gramps estimations (or just use EST or ABT).
  4. The timeline reports would be more useful as everyone would show up in their approximate places in time.
  5. (Almost) every person in the database has some connection to someone who has a date on an event. This might take a while to recursively find, but would only need to be done every once in a while. A highly-recursive update procedure would scour the data looking for evidence from various directions, and mark probably_alive and the confidence on birth/death. The user could initiate this process. Or by suggestion: "Your age estimates need to be updated. This will take about 5 minutes. Can I do that now?"
  6. A related function is "Age at year N". Often I am looking through records, and I see that Person A was 29 years old in 1851. Is that one of my ancestors? Which one? If there were a (virtual) field that showed the age on a given year, that would make this very easy.
  7. One downside: if every person has an estimated death date, you will see an estimation of your own demise :)
  8. The age span estimates should be configurable/learnable, and for a particular person, maybe even overridable. For example, you may have some reason to believe that Person B didn't live as long as Person C. You could enter manually these as ABT or EST dates, but the system would need to know that these are user estimates not system estimates.

Discussion

  • bmcage 01:54, 9 September 2007 (EDT)
  • Estimated and calculated are existing date qualifiers in GRAMPS. You can use them for probably alive today if you want.
  • We are very clear in GUI: editors are just that: the data as has to be entered. Derived values should not be present. Derived values needed for research should be created by reports, which can take their time to calculate everything. Eg, knowing the age in 1851, is something you need to know in terms of research you are doing at the moment, so you have one question, and you need to find the answer. That is what reports are for. Writing a good report for that is the key.
  • For the ages, you could make a tool : estimate ages, which creates events with CAL date, and stores them, deleting previous run CAL dates, then do reports for that. Please, think of solutions in terms of tools, reports, so without derived fields on editors, views or in the database