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

On May 23, 2013, at 3:40 PM, Tim Lyons <guy.linton@gmail.com> wrote:

> John Ralls-2 wrote
>> On May 23, 2013, at 11:58 AM, Tim Lyons &lt;
>> guy.linton@
>> &gt; wrote:
>>> Seems like only the simple case (individuals) not the more complicated
>>> relationships is being dealt with!
>> No, it got incorporated in #236, then abstracted into a new Subject class
>> in
>> https://github.com/FamilySearch/gedcomx/pull/244
>> Event, Person, PlaceDescription, and Relationship are all derived from
>> Subject,
>> which carries both an "extracted" flag and an "evidence" list of
>> EvidenceReferences
>> to Subjects of the same subclass (i.e, the EvidenceReferences is an
>> Event's evidence
>> list must point to other Events).
>> This goes well beyond what Tom Wettmore has implemented in LifeLines or
>> proposed
>> for DeadEnds as well as the "Linkage Analysis" that Robert Charles
>> Anderson describes
>> in his forthcoming "Genealogical Analysis". I suspect that it will fail to
>> scale
>> just like attempts to implement the Gentech model did.
> It seems to me that relationships are much more complicated, because you
> derive other relationships from them. For example, you have evidence of a
> marriage, and then evidence of a child of that marriage. But you change the
> personas (to use the old terminology) that the people in the relationship
> point to, how does that affect the child relationship? (Perhaps that is what
> you mean by not scaling?)
> Anyway, has anyone in the GedcomX community worked through a use case of
> Relationships in a similar way to the Use Case #232?

No, nobody's worked through anything at all. AFAIK the only successful implementation of n-tier is LifeLines.
Wetmore's gone on at great length about the wonders of DeadEnds, but if you Google it you come up with a blog
that hasn't been posted to in 3 years and has only a few snippets of code:


Mind that Wetmore himself has only expressed interest in applying n-tier to persons. Thad Thomas (thomast73) pushed
for extending it to all of the top-level conclusion classes.

If you stick to tiering only the persons, then it's not too hard to figure out that if you find two records of a marriage event,
say a church record and a marriage license, then it's simple to just assert that the two bride-personas are the same person,
as are the two grooms, the two officials, etc.  But if you want to n-tier the events, and you assert that the two events are
the same, do you have the program fill in the person assertions as well? Is it redundant? Same question for relationships.
Do we really care about relationship and event objects outside of the context of the participants?  Then there's place
definitions. Is it really necessary to create separate PlaceDescriptions for every record you have from East Barnett and
assert that they're all the same place? Having done all of that, how do you present it to the user to help continue the research?
How do you turn it into a report that helps the user explain her reasoning to others, either in a compiled genealogy, a lineage
for a society application, or an article in their society's journal?

To directly answer your question about changing the personas, you don't. A persona represents a person manifested in a
record: It goes with the record. You combine personas to make a Person. If new evidence comes along that says that some
persona really represents another Person, you change the connections.  So your first record of the marriage will have a
persona A1 and B1, and the second will have A2, B2, and C1. A1 and A2 are asserted to be personas reflecting A, and that
assertion causes the program to recognize that C is A's child.

Note well that n-tier support is absolutely optional in GedcomX. If we were to implement an importer tomorrow we'd simply
merge all of the personas into a single person and be done with it, and I expect that every other genealogy app will include
the code to do the same -- and since there are no apps which implement n-tier, the code and effort is absolutely wasted.

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.

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.

What is best, I don't even think it's very hard to implement.

John Ralls

Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
Gramps-devel mailing list