Jump to content

Jerry Bryan

Member Since 06 Aug 2006
Online Last Active Today, 06:11 AM

Topics I've Started

Making a Named Group During Any Automated Merge

31 January 2018 - 08:08 PM

It is requested that all of RM's automated merge processes support an option to add each newly merged individual to a Named Group of the users's choice (including making a new Named Group specifically for the current merge). A new group created in this manner could serve as a "to do" list of individuals who might need post-merge cleanup. As a user performs any such post-merge clean-up, they could easily remove the cleaned up individual from the group with QuickGroups.




A More Targeted Ctrl-Shift-U

23 October 2017 - 06:56 AM

Doing a Ctrl-Shift-U to reset RM default settings is frequently recommended to solve any number of ills with a user's RM installation. A common problem is password problems with ancestry or familysearch. The Ctrl-Shift-U has the effect of resetting all RM default settings, and doing so usually does solve whatever problem is being addressed.


However, the Ctrl-Shift-U has the adverse effect of resetting all RM default settings, not just the one which is causing the problem. The Ctrl-Shift-U is much too obscure for most users to find on their own, and it's much too global in its effects. After a successful Ctrl-Shift-U, it can take a user a long time to get all their settings restored. Therefore, I wish for the ability for RM to display a list of all RM default settings with the list being easy to find within the RM user interface. And I wish for the ability for users to reset each default setting on an individual and case by case basis without changing any of the other settings. 




P.S. I can be very literal at times and "... display a list of all RM default settings" means all, unlike Find Evertwhere which doesn't really find everywhere.

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.

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.




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?