Jump to content


c24m48

Member Since 06 Aug 2006
Offline Last Active Today, 07:11 PM
****-

Topics I've Started

True Shared Facts

11 October 2017 - 08:44 AM

I'm going to make a fairly outrageous claim. Namely, I claim that RM doesn't support shared facts. My wish is that it do so.
 
RM does support a thing which it calls shared facts. However, RM's shared facts are actually fact roles that can be assigned to other individuals in the database. The original fact itself cannot be shared. Another way to say the same thing is that every fact has a role called principle which is for the person who owns the fact, and the principle role cannot be assigned to another individual in the database. Therefore, another way to express this wish is to ask that the principle role for a fact be able to be assigned to multiple people.
 
For example, suppose a large family moved from Tennessee to Missouri an 1857 and suppose you have a user defined fact type called MOVE. You can assign the MOVE fact to one of the family members but you can't directly share the MOVE fact with other family members. Instead, you have contrive some sort of role for the MOVE fact and assign that role to the other family members.
 
There is a longstanding wish that it be possible to copy a fact from one person to another. This would be a very useful feature. If it were possible to copy a fact from one person to another, then the putative MOVE fact could be assigned to one family member and then copied to the other family members. However, if something later changed about the MOVE fact for the family members, you would have to make the same change for every family member. As a true shared fact, the change would only have to be made once and the change would automatically be appled to all the family members.
 
Another example might be the birth fact. It's already possible and reasonable to assign the role of MIDWIFE to the birth fact and to use RM's role mechanism to assign that role to the person who assisted in the birth. But if there were twins and you wanted to share the birth fact with both twins to avoid double data entry, it's not so easy. True shared facts would make it easy to share the birth fact for twins.
 
Needless to say, if RM were to implement the ability for a fact to have multiple principles, it would be necessary for there to be an option to export such shared facts as unshared facts in GEDCOM and to exchange such shared facts with TreeShare and FamilySearch as unshared facts.
 
Jerry

Re-Imagining TreeShare

13 September 2017 - 11:15 AM

TreeShare has the potential to be the most popular enhancement that has ever been made to RM. But TreeShare has its problems

 

One of the most significant TreeShare problems is the absence of any kind of automated upload or download after the the initial syncing between RM and ancestry. I know from personal experience that I can spend one hour updating RM and then have to spend two or three hours approving those same updates to be moved from RM to ancestry. That is simply not acceptable.

 

When TreeShare was first announced, the absence of any kind of automated upload or download was presented instead as an advantage as compared to an automated sync process. The reason stated was that a manual sync process would assure a much higher level of data integrity than would an automated sync process. Even the beta testers were strongly supportive of this point of view. And some of them had horror stories to tell about sync between FTM and ancestry gone awry.

 

It has also been stated that TreeShare is not designed to be a sync process. That's one of the reasons it's called TreeShare rather than TreeSync. So let me try to imagine a safe way that TreeShare could be automated.

 

But before I do, let me go back into the history of RM just a little bit. Once upon a time, RM introduced a new feature called ShareMerge. Here's the description of ShareMerge, taken directly from the RM screen.

 

If you send a GEDCOM from your RootsMagic database to another RootsMagic user, they can import and make changes to that file, and return it to you. You can import that modified GEDCOM into your database and use this option to automatically merge the two copies of the database back together.

 

This makes ShareMerge sound pretty good. But in a very fundamental way, ShareMerge doesn't really work. The problem is that even though the matching and merging of people is automatic, the merging of facts and sources isn't. So there is still a great deal of manual work that has to be done to complete the ShareMerge process. What's really needed with ShareMerge is that the individuals in the the newly imported GEDCOM replace the corresponding people that are already in your database.

 

If this sounds similar to some of the problems with TreeShare, it's because it is. For example, suppose that you create an ancestry tree by using the TreeShare process to copy all of your RM database to ancestry. Furthermore, suppose you subsequently make all your updates in RM. Then you don't need a "sync" operation or a "share" operation. All you need is for all your updates in RM to replace or to be added to what is in ancestry. The process can be fully automated and is completely safe with no approvals whatsoever.

 

The exact same thing is true in the other direction. You can create your RM database from an ancestry tree and make all subsequent updates in ancestry. Again, all you need is a replace operation. The process can be fully automated and can be completely safe.

 

I could anticipate that a fully automated and bi-directional sync between RM and ancestry could be extremely difficult to accomplish and might not be very safe. So as an interim measure, I would like to re-imagine what the product should look like. I would like to suggest an automated mode of operation that is one directional only and that replaces rather than syncs. The existing bi-directional mode of operation with a manual approval process could remain, but I think many, many RM users could benefit from a one-directional replace mode of operation - and the one-directional replace mode of operation would be very safe.

 

Jerry

 


The Adoption Fact and Other Facts with the Parents Field

04 September 2017 - 11:03 PM

I've been trying to get serious about adding some sort of Parentage fact to my RM database. I've talked about this before. The primary purpose would be to provide a place in RM to attach evidence of a person's parents. But as an additional benefit, it could improve narrative reports.

 

To that end, I've been looking at the built-in Adoption fact. It includes a field to enter the adoptive parents so I was wondering about using it as a model for a putative Parentage fact. However, it seems to me that there are two problems with this approach.

 

The first problem is that I don't think there is anything in the design of a new fact type that would let me mimic the way the built-in Adoption fact works. Well, you could create a role for Father and a role for Mother. But I don't think you can create a role for Parents as a couple, nor do I see any other way to enter parents that actually links to the parents. You can obviously include the parents as text, either in the description field or in the note field.

 

The second problem is that I don't see a variable in the Sentence Template Language called [Parents] or anything like that. So even for the built-in Adoption fact, I don't see a way to list the parents in a narrative report.

 

I guess my question is, am I missing anything obvious that would help me with the design of a Parentage fact and its use in narrative reports?

 

Jerry

 


Checklist for Missing Data

27 August 2017 - 07:35 AM

There's an interesting thread on RM's Facebook page about how to find missing data that you need to find, and the term "checklist" is used.

 

There are a variety of creative ways to create such checklists in the RM user interface. For example, you can use People View with the birth date as a column to find individuals without a birth date. You can use People View for other, similar purposes as long as the facts you are looking for are individual facts. You can use Find to identify a lot of missing items. There are a few reports that help you find a few specific missing items. But if you are looking for text dates that need to be fixed, people born over 100 years ago without a death date or a death fact, missing facts in general (birth, death, burial, census, etc.), facts without citations, citations without media, facts without media, citations at an inadequate proof level, etc. then there is no central reporting or searching facility that will identify all such missing items.

 

Therefore, I wish for a checklist reporting facility in RM to identify missing data of all sorts. The facility should be able to be customized and filtered, and hopefully it would reside in a non-modal window from which you could click on items and be taken immediately to the individual with the missing data.

 

Jerry

 

P.S. I create such checklists with SQLite scripts, and the scripts are customized for my personal research needs. These checklists essentially become my to do lists. Since the checklists are in SQLite which is a separate window from RM, I can go back and forth between RM and SQLite without losing my place in either one. The only thing that's not completely automated going back and forth is that I copy a RIN (RM id number for a person) from SQLite and paste it into a search in RM as a way to navigate quickly to the correct person in RM. But it would be much better if such a facility were in RM itself rather than being outboard of RM.


TreeShare 7.5.1 - Problem with Changed/Unchanged after Merge in RM

16 July 2017 - 08:28 AM

I disconnected my test RM database from ancestry, deleted the tree in ancestry, and deleted the test RM database that was connected to ancestry. I created a new, empty RM database and added one person by hand. The only data I entered was the person's name, the name of a real person about whom I have lots of real data. I synced the new RM database ancestry, creating a new ancestry tree with just the one person. So far, so good.

 

Next I dragged and dropped the same person from my production RM database  to my test RM database - just the one person, no relatives. I merged the two people together, keeping the original person I had entered by hand so the Record Number wouldn't change and hopefully would still match the same person in ancestry. Because the original person had no data other than the name, the merge was completely clean and the person now had all his relevant data without me having to type it all in again.

 

The newly merged person is not on the changed list, even though there were massive changes to his data. I can force him onto the changed list by making a dummy change, but the merge didn't do put him on the changed list.

 

Having forced him onto the change list, I synced between RM and ancestry. All seems well except that all my fact notes contain carriage returns. So the person is now unchanged but the data doesn't match between RM and ancestry. Removing the carriage returns from RM does make the data match between RM and ancestry, but the carriage returns are there for a reason and I can't really remove them in my production database. And the process of removing the carriage returns from the RM side of the house puts him back on the changed list even though he now matches between RM and ancestry.

 

Jerry