GEPS 040: Persona Support
- What is a persona?
- A persona (pl. personae) is the term used to describe the reference to some person from one specific source. There are no conclusions in a persona — only information — and so it is sometimes inaccurately referred to as an “evidence person” in order to distinguish it from the traditional “conclusion person” that we might have in a family tree. Hence, a persona is not equated with any actual person. (By Tony Proctor - parallax-viewpoint Blog)
Where are we now?
How does the Form gramplet store data?
Consider a person participating as a child in a birth event and also in a census event.
The source information is stored as attributes of the event and event reference. The attributes are defined in an xml definition file. The source citation is attached to the event and attributes.
Person -- [Name, Sex, Residence] -- Birth
\ -- [Name, Sex, Age, BirthPlace, Occupation] -- Census
(Mother and father in birth event and other census participants not shown)
The lists of attributes in the event references are personae. If the user decides to select a different person then the attribute list will be moved to a new event reference on a new person for them.
This works quite well, but attributes can only store text and users have been asking for other events to be created for them. We could easily create Birth, Residence and Occupation events.
Person -- [Name, Sex] -- Birth
\ -- Residence [Residence]
\ -- [Name, Sex] -- Census
\ -- Birth [Age, BirthPlace]
\ -- Occupation
However, this creates a couple of problems:
- The person now has two Birth events.
- Choosing a different person is more complicated.
Note: The Residence and BirthPlace are text so we cannot reliably choose a place. The Age can usually give us an approximate date of birth.
What is the solution? We could create a persona for each source and consolidate the birth events.
/-Persona A -- Residence [Residence]
Person \ -- [Name, Sex] -- Birth ---\
\-Persona B -- Birth [Age, BirthPlace] -- Consolidated Birth
\ -- [Name, Sex] -- Census
\ -- Occupation
(The person-persona links should contain reasoning)
Now changing a person is as simple as changing a link to a persona. The personae themselves should seldom need to be edited after creation. There is also a single consolidated birth event.
This diagram shows a 2-tier approach. An n-tier approach in which personae are bundled into other personae is also possible. In an n-tier approach any top-level node is a person.
Is the birth event in the census source actually a vital or fact rather than an event? The contents of a birth certificate provide more reliable information for a birth event than the contents of a census.
Is the occupation better kept as an attribute?
How should families be handled? In Gramps, we use them to model both relationships and family groups.
Is it worth having source level places, or is text sufficient?
See also
- "Gramps-devel" Implementing persona support in Gramps. From: Nick H. - 2016-01-21
- Genealogical Persona Non Grata 11 September 2013 By Tony Proctor - parallax-viewpoint Blog
- Our Days of Future Passed — Part III 10 December 2015 By Tony Proctor - parallax-viewpoint Blog
- GEPS 024: Natural transcription of records
- Attributes in Gramps
- 2051: Attribute - possibility to set predefined values
- 7441: Suppress printing of attributes with leading underscore in name eg: GEDCOM "_UID" tags