An update on RM10's improved Set Relationships feature

As has been much discussed, RM10 added a new feature where it displays Spouse of relationships such as Spouse of second cousin three times removed. However, a number of users reported that a few Spouse of relationships were apparently missed. Such misses were rare and there seemed to be no pattern as to who was missed. So I wrote an SQLite script to find such misses.

I’m convinced there was a bug in this feature in RM 10.0.0.0 and the bug seems to have been fixed in RM 10.0.1.0, even though the fix list for RM 10.0.1.0 doesn’t list this issue. My script still seems to identify a very tiny number of misses, but I’m not sure if they should be considered true misses or not. I don’t think there is a bug in Set Relationships in RM 10.0.1.0 nor do think there is a bug in my script. I just think there is a minor difference in interpretation.

Here are the two differences I have found.

  1. RM 10.0.1.0 identifies Brother-in-law and Sister-in-law relationships. It does not identify Spouse of brother-in-law and Spouse of sister-in-law relationships. If you think about, that may or may not be strictly correct, but it sort of makes sense. You are not really related to your brother-in-law or your sister-in-law, but it’s still nice that Set Relationships identifies them. And you are really, really not related to the spouse of your brother-in-law or the spouse of your sister-in-law, so do you want Spouse of brother-in-law and Spouse of sister-in-law relationships identified? Well, whether you want it nor not, RM 10.0.1.0 doesn’t do it. On the other hand, my script is very simple minded. It doesn’t care what the relationship is. If there is a relationship there and if there is a spouse there and if the spouse doesn’t have a Spouse of relationship, the script points it out.
  2. RM’s Set Relationship has always identified the spouse of an aunt as an uncle and and the spouse of a an uncle as an aunt. RM10.0.1.0 continues this practice. These relationships are often known colloquially as uncles by marriage and aunts by marriage, but by blood you are not related to those people. But RM 10.0.1.0 does not mark any additional spouses of an uncle or aunt by marriage as a Spouse of an Uncle or as a Spouse of an Aunt. Once again, my script has no easy way to know that an uncle or aunt by marriage is not a real uncle or aunt and it reports their additional spouses, if any, as missing a Spouse of relationship.

So that’s it. Unless something else funny shows up, I think the problem in RM 10.0.0.0 is fixed in RM 10.0.1.0 and that’s it’s time for me to retire my script.

2 Likes

I am speculating that we will seem some tweaks in the future and maybe the changes in 10.0.1 will lead us to more fine tuning of what a use wants or does not want to see.
It seems that 10.0.1 is working as designed but not necessarily as desired for everyone.

:slight_smile:

There is another effect caused by the new “spouse of” relationship:
If relatives marry under each other, formerly, the kind of how the spouse was related was mentioned in RM9. Now in RM10 this information about the kind of how they are related is overwritten by the “spouse of” information.
I prefer the information of how the spouse is related compared to the more or less obvious information of their marriage.
For example, in RM9 the relative info was:

In RM10 now ist is:

I hadn’t noticed this one, but it’s not particular surprising because the problem RM is trying to solve is so tricky, what with multiple relationships and multiple spouses to take into account.

It’s always fraught trying to tease out the internal algorithms being used by software simply by observing the external behavior. But in this case, I suspect that RM10 is trying to make a single pass at all the relationships. In the case of relationships, I think the logic involved in making a single pass at the data would be convoluted beyond all imagination and could sometimes produce strange results such as you are describing.

I think I would approach the problem with a two pass approach. The first pass would simply be the old algorithm used by RM9. The second pass would then be a loop through the FamilyTable looking for individuals who are not a relative and whose spouse is. Then all you have to do is to copy the relationship fields to the non-relative and turn on the Spouse of flag. Well, you still would have to worry about a non-relative who had more than one spouse who was a relative and decide which one to pick. But even so, the logic with this sort of two pass approach should be fairly simple.

I could be wrong about the single pass approach and RM10 may already be using a two pass approach. If so, then I can’t explain why your Albert Lubberts Cremer was a first cousin nine times removed in RM9 and spouse of half seventh grand-aunt in RM10. It seems to me that an actual relationship should take precedence over a Spouse of relationship. But even that general rule is fraught. Suppose your first cousin married your seventh cousin. Which is more important to you, that the person was your seventh cousin or that the person was the spouse of your first cousin? So just as I have been composing this message, I’ve almost changed my mind. Only one relationship can be displayed for your Albert Lubberts Cremer. Who is to say if a distant actual relationship is more important to you than a closer Spouse of relationship? I can’t even agree with myself on this one.

1 Like

Recursive vs iterations vs shortest path etc. There is a lot of potential logic to deal with no matter what is used – and likely hard to “win” every scenario to everyone’s liking. My son-in-law has double 1st cousin marriages in the same family group for example (several)

It is not always obvious the displayed results with ‘the why’ etc
Kevin

That’s exactly what I had to do with my kinship list query in 2016 in order to get the Spouse ofs that pre-RM10 versions did not. And it executed faster than RM’s.