2013/5/24 John Ralls <jralls@ceridwen.us>

On May 24, 2013, at 12:22 AM, Benny Malengier <benny.malengier@gmail.com> wrote:
> You are right. But in my suggestion no persona is made, only the record is kept as part of our database. The Persona that come from it are the software that updates  existing Person objects.
> The software part can be repeated at every point, and is an addition. In the same way, you could do a substraction, and then add again all the remaining records that are connected.
> This allows to update and change Person objects from stored records like the census record, without having stored actual Persona in the database. It's just business logic of the generation part. We could present it as a sort of persona object in the GUI which the user must approve of, but we don't store.

That would be very bad practice. Remember, good genealogy demands that every statement is backed by
careful analysis of all of the evidence discovered from a thorough search. A persona is special because it's a
reflection of the evidence about a person from a single record: It's expected that a Person object consolidates
the various personas with analysis of the credibility of the underlying evidence for each to arrive at a conclusion
about the events, attributes, and relationships that describe the historical person's life. Only in that context would
it be permissible for a program to automagically change conclusions in a persona (*not* a Person) instance.

I'm not convinced. A record holds data, what is extracted from it should be independent of the person reading it. So that data, be it Persona or not, can be done automatic.

The missing piece in my opinion is then the Analysis Document (A.D.). That as you explain it is the human intervention. You see as date 1?/04/1713, You store an event and choose April or 10/04/1713 or whatever, and you indicate in the A.D why. You see a name, and you make a new person or use an existing person, and indicate why.

To repurpose notes for this is somewhat annoying though, as preferably it is something we can scan in code, and not something a user afterward can delete or edit with ease. The already existing Gramps model should not require it for it's operation.

My only beef is that the more objects come into play, the more our data model resembles spaghetti.


> I think this gives quite a lot of the benefits without actually:
> 1/ requiring people use Gramps in this way, the old way keeps working
> 2/ store n-tier system data model.
> The disadvantage is that the reason why a record leads to person A and not person B must or be stored somewhere else, or must be stored in the record object.
> Where in Gedcom X does one store this conclusion? So if two persona, how to indicate they are not the same based on your evidence.  You run the risk with equal names and date, that a tool to find duplicates keeps indicating they might be the same.

The missing piece that no one here is talking about is Analysis Document. GedcomX provides a class and has
"analysis" reference lists on SourceDescription and Conclusion and are intended to capture the researcher's
analysis at every step, whether using n-tier or more traditional methods. We already have Notes, we just need
some new Note Types to designate them.

N-tier or not, an Analysis Document will have to explain why a record that appears to describe the Person in fact
describes someone else. That A.D., attached to the Person, will have a reference to the persona, and an automatic
"persona finder" can see the reference and exclude the persona from the list. Note that a single A.D. can be attached
to more than one Person, so an argument about why personas 1, 2, and 3 apply to Person A and 4, 5, and 6 to
Person B need be written only once and attached to both.

John Ralls