Jump to content


Photo

WebHints "Problem" with FamilySearch Family Tree


  • Please log in to reply
9 replies to this topic

#1 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3662 posts

Posted 29 July 2018 - 01:45 PM

I have encountered an unusual WebHints situation for FamilySearch Family Tree. I'm just reporting a situation for informational purposes. I can't think of a way to fix it myself, nor can I think of a way that RM could fix it. Here follows a rather long winded description of the problem.
 
RM's WebHints for MyHeritage and I think for FindMyPast work by contacting the respective server which proposes sort of a soft and temporary match between a person in your RM database and persons on the server - either matches between the RM person and records for persons in a database on the server or or matches between the RM person and a person in a tree on the server. I call these a soft and temporary matches because the matches are generated on a just in time basis and the matches may or not be correct. You can readily approve or reject any such proposed hints. Any proposed hints are just for you and your RM database and cannot be seen or shared by any other RM user or MyHeritage user or FindMyPast user.
 
RM's WebHints for ancestry work very differently. They required that you have an RM database and a tree on ancestry that have been synced by TreeShare. The initial set up of an RM database and an ancestry tree really is a sync. Subsequently, updates between the two are not a sync but rather are a share. Having set up an RM database and an ancestry tree in this fashion, ancestry will calculate shaky leaves in the ancestry tree where the shaky leaves are hints. Any such proposed hints are just for you and your ancestry tree. Other users cannot see them. You can see them on ancestry, and via the magic of TreeShare you can also see them from RM. Such hints are hard and semi-permanent, meaning that they are actually stored as a part of your ancestry tree. They are calculated ahead of time instead of just in time, and they are already there before RM asks ancestry about them. You can readily approve or reject any such proposed hints, and you can do it either from ancestry or from RM.
 
So far, so good.
 
That brings us to FamilySearch's hints. They are similar to ancestry's hints in one respect. Namely, they are calculated ahead of time instead of just in time, and they are already there before RM asks FamilySearch about them. But instead of being hints just for you, they are hints for every genealogy user in the world. FamilySearch has a big tree of everybody in the world called Family Tree that is managed jointly by every genealogy user in the world (or all the ones who choose to do so). So the hints start out as hard and semi-permanent hints called Record Hints between Family Tree and the FamilySearch record colletions such as census records, death records, etc. Just because the hints are hard and semi-permanent does not make them correct, and you can logon to FamilySearch and approve or reject any such hints.
 
What RM does for you is to look for such Record Hints for you. It does so by sending a message to FamilySearch containing information about your person in your RM database. FamilySearch responds by attempting on the fly to find a soft and temporary match between your RM person and a person in Family Tree. At this point, FamilySearch is not really looking for Record Hints for you. It's just trying to do this soft and temporary match between your person in RM and a person in Family Tree. If it does find what it thinks is such a match, it then checks to see if there are any Record Hints for the person in Family Tree. If there are any such Record Hints, RM shows them to you as if they were your own hints. You can go in to FamilySearch and approve or reject the hints. But if you do so, you are not really approving and rejecting the hint between the record and you RM database. You are really approving the hint between the record and Family Tree. So you are approving or rejecting the hint for everybody in the world. It's a little strange and I think RM kind of hides and disguises what is really going on behind the scenes, but in practice it seems to work really well. Except when it doesn't.
 
What I have run into recently is Record Hints in FamilySearch that are perfectly valid and which need to be approved, but where the soft and temporary match between the person and my RM database and a person in Family Tree is totally invalid. Therefore, approving the WebHint in RM is totally incorrect and rejecting the WebHint in RM is totally incorrect. So far, I'm choosing to do nothing, but it is a very dissatisfying situation. Among other things, the WebHints in question are still there on my screen and there is no way to get rid of them.
 
Details, details,details. I have a couple in my database named Mary Sue Moore 1909-1997 and Frank Eddmon Wolfe 1917-2003. In the case of Frank Eddmon Wolfe, all his FamilySearch Family Tree WebHints in RM are fine. In the case of Mary Sue Moore, there are eight proposed WebHints in RM. Upon further review, all eight proposed hints are for a person named Mary Sue Mooney who married a man named Frank Wolfe. Mary Sue Mooney's FamilySearch ID is L89L-CG2. There are eight Record Hints in FamilySearch for Mary Sue money. Two of them have already been approved by somebody else and the other six look correct for Mary Sue Mooney. But none of them are correct for Mary Sue Moore because Mary Sue Mooney and Mary Sue Moore are not the same person. There does not seem to be a way to tell RM or FamilySearch for the purposes of WebHints and Record Hints that Mary Sue Moore and Mary Sue Mooney are not the same person.
 
I'm actually surprised that this situation doesn't happen frequently, but I have never seen it happen before.
 
Jerry


#2 Bob C

Bob C

    Advanced Member

  • Members
  • PipPipPip
  • 239 posts

Posted 29 July 2018 - 02:18 PM

Jerry,

 

I have found the same issue with some of my people that I have matched to FSFT and believe that the issue lies with FS's matching algorithm in that it seems to be using some artificial intelligence type of phonetic name for matching like soundex. What I have done is to open the hint and select  "Not a Match" and give a short reason "Not Same Person". After a few of these it seems to learn that and the web hints stop. Also, this clears the web hints reported back to RM. I know  that I am doing FS's work for them but in the long run I feel that I am improving the data for others. Give some and get some philosophy I guess.

 

Bob



#3 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3662 posts

Posted 29 July 2018 - 02:29 PM

In my case, the problem is that I believe that the proposed Record Hints between Mary Sue Mooney and her Frank Wolfe are valid hints for those two people with respect to each other. So I don't want to invalidate what I believe to be valid hints. It's just that those two people are not my two people.

 

Jerry



#4 Bob C

Bob C

    Advanced Member

  • Members
  • PipPipPip
  • 239 posts

Posted 29 July 2018 - 03:08 PM

That bring up another issue that I have run across. At some point there were 3 individuals named Frank Wolfe. Yours, another one that matched yours and a third that married Mary Sue Mooney. Someone could have merged the one that matched yours and the third one. That would seem to indicate to FS that your Frank Wolfe and the one married to Mary Sue Mooney are the same person. RM seems to pickup changed FSIDs when two people are merged and the surviving person is not the person you have linked  and change what is in RM to reflect  the merge. IMHO RM should break the link, flag the record with something like the problem flag and let you use your judgement as to what the correct link should be.

 

Added: I just came across this again with FSID KLLQ-52F. I had merged FSID 9NG6-X9G ​into KLLQ-52F in June and when I just clicked on the blue tree for the individual in RM it brought up 9NG6-X9G ​and when I clicked "Unmatch" it populated the match field with the K  number!



#5 Renee Zamora

Renee Zamora

    Advanced Member

  • Admin
  • PipPipPip
  • 8519 posts

Posted 08 August 2018 - 01:07 PM

Basically RM can only receive what the WebHint providers send us. The FamilySearch Hints are generated on the Person page for a matching individual. I believe if you match your RM person to the correct FamilySearch person you will get FamilySearch Hints specific to that individual. Then you can reject what really doesn't belong to the person. I have had to go in and reject hints for the wrong person when merging done earlier created issues. 


Renee
RootsMagic

#6 pbooth99

pbooth99

    Advanced Member

  • Members
  • PipPipPip
  • 47 posts

Posted 11 January 2020 - 09:30 AM

I hope that this comment/question makes sense.

 

I have used FamilySearch for about eight years. In the beginning I made many mistakes, often merging people who werent the same, through carelessness and ignorance. I got better, and over time the balance of my FS work changed to spending more time fixing problems created by others, than I spent creating problems for the future ;-).

 

When I began using RM7 I did so with wild abandon, and I quickly realized that enabling the switch "Match person to FamilySearch when hints found" created many bad merges. Since disabling that things have improved but I am still responsible for creating more issues than I would like.

I have noticed that there is a pattern to my bad merges, which might be related to the matching logic - if I have a Fred Jones, with parents Tom Jones and Mary, I will see matches with other Fred Jones records who have parents Tom Jones and Mary, but whose DOBs don't remotely match. It appears that if my RootsMagic record has a DOB, but the FamilySearch record only has a christening date that looks like so: 13JUL1845   then that date isnt compared with the DOB and used to discard the potential match. Of course, a christening or baptism isn't the same thing as a birth and frequently occurs in a different year than a birth - but if it occurs a century later than a DOB it suggests that its unlikeley these two people are the same.  

 

Does anyone have any insight into how the Rootsmagic matching works?

 

  1. Are DOBs and baptism/christening dates compared?
  2. How granular/fuzzy/intelligent is date comparison?

 

As a human being I can look at the following list of pairs of dates and deduce that each might suggest a different probability of a match - with strength getting smaller the further down the list. Any of items 1 through 7 could indicate a match. Writing code that is as smart as a human is very difficult. Does RM consider as many gradations as this, or is it more black and white?

 

             Date1          Date2
  1. 3-Oct-1865 3-Oct-1865
  2. 3-Oct-1865 4-Oct-1865
  3. 3-Oct-1865 3-Oct-1866
  4. 3-Oct-1865 1865
  5. 3-Oct-1865 7-Mar-1866
  6. 1865 1865
  7. 1865 1866
  8. 1865 1942


#7 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3662 posts

Posted 11 January 2020 - 10:37 AM

It leaves your question of how the matching algorithm works unanswered, but I don't think the matching is taking place inside of RM. I think it is taking place on the servers at familysearch.org.

 

I could be very wrong, but I think the following is the case. MyHeritage has some very sophisticated matching technology. I'm sure the details are proprietary and secret, but it appears to me that the MyHeritage  matching technology is using names, dates, and relationships such as parent/child relationships. I'm not sure if it is using spouse relationships of sibling relationships. There is a partnership agreement between MyHeritage and FamilySearch (https://www.familyse...sked-questions/). I believe that FamilySearch is using the MyHeritage matching technology in support of both its Record Hints process and its "web hints for RM" process.

Just within FamilySearch itself, here is what you have for Record Hints. These matches are already there and would be there even if RM didn't have a WebHints feature and indeed even if the RM product didn't exist at all.

FamilyTree person   <---match technology--->   FamilySearch record

Then RM adds in its WebHints feature for FamilySearch. I think the picture is something like the following.

RM person   <---match technology--->   FamilyTree person   <---match technology--->   FamilySearch record

It's the match between FamilyTearch person and FamilySearch record that appears on FamilySearch as Record Hints and which have been pre-calculated for all the world to see on Family Search. The match between RM person and FamilySearch person is what I believe is being calculated for you on the fly. But what is reported back to you in RM as a WebHint is a FamilySearch record and not a FamilyTree person. On the other hand, when you do the FamilyTree matching process in RM which very much pre-dates WebHints then the match is between RM person and FamilyTree person. RM even records the FamilyTree ID in the RM database.

 

I could certainly be wrong, and the actual technology could be working like the following for Rm's WebHints for FamilySearch.

RM person   <---match technology--->   FamilySearch record

But I just don't really think it works that way because what is being reported back to you is a pre-calculated Record Hint between a FamilyTree person and a FamilySearch record. I think it works like the first model I showed with the FamilyTree person being an intermediary between the RM person and the FamilySearch record. But no matter which of the two ways it works, I think the thing that I labeled <---match technology---> on my little picture is running on the FamilySearch servers rather than in RM and I think it is technology developed by MyHeritage that is cross licensed for use by FamilySearch.

And finally, when you do things like Duplicate Search Merge in RM, I think you are using 100% RM technology which I don't think is as sophisticated as the technology from MyHeritage. In particular, I think the RM technology is only looking at dates and names. I don't think RM technology is looking at relationships. In any case, I don't know if any of these technologies is using christening/baptism dates as surrogates for birth dates and I don't know any of the details of the fuzzy matching logic for any of these technologies. I'm sure that such things are proprietary and secret.

 

Jerry



#8 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3662 posts

Posted 11 January 2020 - 10:40 AM

 

When I began using RM7 I did so with wild abandon, and I quickly realized that enabling the switch "Match person to FamilySearch when hints found" created many bad merges.

 

I think it's a very dangerous feature. I wish it would be withdrawn from service.

 

Jerry



#9 Renee Zamora

Renee Zamora

    Advanced Member

  • Admin
  • PipPipPip
  • 8519 posts

Posted 13 January 2020 - 01:05 PM

It's my understanding that the matching is determined on the FamilySearch side. RM only sends the search data through the FT API for matching. Once the RM person is matched to someone on FamilySearch then FamilySearch will match against the FT person and not what you have in RM.


Renee
RootsMagic

#10 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3662 posts

Posted 13 January 2020 - 03:57 PM

It's my understanding that the matching is determined on the FamilySearch side. RM only sends the search data through the FT API for matching. Once the RM person is matched to someone on FamilySearch then FamilySearch will match against the FT person and not what you have in RM.

 

Ok, so RM sends the data through the FT API and the matching takes place at familysearch.org rather than locally on RM. There is no question about that.

 

Does familysearch.org match the RM data to Record Hints which then have possible matches to FT? Or does familysearch.org match the RM data to FT which then has possible matches to Record Hints? It makes more sense to me that it's the latter, but I could be wrong. I have never seen a detailed enough description of the process on the FS web site to be able to know for sure. The difference is probably important behind the scenes at familysearch.org, but the difference probably does not matter to an RM user who is getting Webhints from familysearch.org.

 

In any case, the important things for an RM user to know is that the matching is taking place on the FS web site rather than on your local copy of RM, and that you will see Webhints from FS only if there are Record Hints already there.

 

Jerry