Sharable Events – Find and Convert to Shared #sharedevent

Problem:

MarkVS posted:
I have still not tackled the task of going through my RM4 database to merge up events that were originally added separately for each individual (in RM3) but would have been added as a shared event in RM4, and RM5.

A Query that would show events that were likely to be suitable for merging would be very useful. In the vast majority of cases this would be a Census event – but it might apply to tohers.I was thinking along the lines of something that listed Census events where the following data was identical
a) the date of the event
b) Census type
c) identical address and place

Then sorted into date/address/place sequence so the likley identical events would be listed together for potential manual update in RM4/5.

Perhaps there would be a cleverer way to identify merge candidates across all Event types?

MVS.

Finding Sharable Events

SharableFacts2.sql for RM4 to RM7
SharableFacts2-RM8.sql for #RM8 2022-02-21

Working on Lee Irons request, I came up with this adaptation of the SourceList.sql query that displays and counts events having citations. His database, or at least those events he wants merged as shared events, is rigorously and systematically cited so that was the easier query to start with. The “Sharable” column lists the number of other persons or events having the same EventDate, “Cited by”, “Description”, “Event Place”, “Event Site”, “Source Name”, “Cit Fields” values.

Convert Sharable Events to Shared – A Start

Lee Irons posed the problem coming from Legacy Family Tree 7.5 that its nearest equivalent to RM’s shared events is to copy facts to different people. When imported to RootsMagic, it would be advantageous to merge these to shared facts. He outlined his preferred merging as:

This is how the merge would work for shared individual facts. Facts associated with different persons that are exactly the same in terms of Fact Type, Date, Place, Place Details, Description, and Sources but have different information for each person in the Note field would be merged into a single shared individual fact. This new shared indivdual fact would have the same Fact Type, Date, Place, Place Details, Description, and Sources as before, and all of the persons would be listed in the People Who Share This Fact with each person’s unique data from the Note field of their indivudal fact being moved to the Role Note for that person in the People who Share This Fact list of the new shared individual fact. The Note field for the new shared individual fact would be left blank.

This is how the merge would work for shared family facts. This function would merge macthing individual facts and a matching family fact into a new shared family fact. When there is (1) the same situation as identified above for individual facts and (2) the persons that have these matching individual facts are part of the same family and (3) there is a family fact with exactly the same Fact Name as the individual fact type and exactly the same Date, Place, Place Details, and Description as the matching indivdual facts of the persons in the same family, then all of these would be merged into a single shared family fact. The new shared family fact would (1) get the Family Fact Type, Date, Place, Place Details, Description, and Note of the original family fact, and (2) would get the source information of the matching individual facts, and (3) would have all of the individuals in the family who have a matching individual fact added to the People Who Share This Fact list of the new family fact, with each person’s unique data from the Note field of their indivudal fact being moved to the Role Note for that person in the People who Share This Fact list of the new shared family fact.

After many hours of feverish brain activity, I think I have a solution for RootsMagic 4-7 in
SharableEvents-Convert.sql (requires a RMNOCASE collation – see RMNOCASE – faking it in SQLiteSpy).
This query has been used with both RM4 and 5 but it does not yet do anything with media that may be linked to an event which has been deleted in favour of sharing another event. Media handling may have to be different for the two versions. Nor does it do anything about assigning roles to the sharers of an event – that could be automated with more grey cells fried. Already shared events that become sharers of another event have their own sharers reassigned to their new shared event; this appears to work correctly with limited testing.

One challenge was choosing which individual was to be the Principal for a group of sharable individual events. The eldest male was a natural choice for 19th century events but what if there was an older female, e.g., the widow with children – the eldest male might be a child. The algorithm I developed results in the eldest female as Principal if she is more than 10 years older than the eldest male. Of course that might result in the elderly woman being the Principal for a census event when she is resident in her son’s house.

As written, there is some duplication of procedures between the two blocks of code corresponding to Lee’s two merge outlines; these can be split apart and run independently. I would welcome any feedback on how it works with any database for which sharable events figure significantly.

Sample database imported from a GEDCOM from Legacy Family Tree 7.5

In the sample database Lee sent, about 3200 events were converted to sharers, resulting in a reduction of about 3200 citations. Everything else on the properties report remained the same.

Sample database Edit Person screen before and after conversion

As delivered, the GEDCOM resulted in identical Fact Names for both Person and Family facts for Cemetery, Occasion and Proximity. Renaming would distinguish them readily on the Edit Person screen but the Details give a clue. “Household of Irons, John …” is an Individual’s fact while “Household of Irons-Dunham, … – Henry A. Dunh…” is a Family fact. The highighted event in the Before window is an Indi fact that was converted in the After window to the highlighted share of a family fact. Hannah is one of 10 people sharing the family fact with the two Principals.

Sample database after conversion: the Role Note contains the Note formerly in the event which was deleted and replaced by sharing a master event.

With no automatically assigned role, and no role defined for this fact type, the program offers the opportunity to define and assign a new role type. However, it may not be necessary to do so if there is no intent to generate a sentence in reports. It is conceivable that the procedure could automatically assign a pre-existing role or even generate a new role but that may be more confusing than no role at all.

Discussions & comments from Wikispaces site

Inline comments