nFS comparing possible matches

In nFS very little data is provided when comparing individuals who are possible matches. The less data, the less likely I am to combine.

In contrast, when I use Legacy and click on merge, the next thing I see is a box of options for search parameters. I select a much more narrow search for my Smiths than for my less common surnames.

Additional features that would be helpful in nFS:
-warning that this is a parent child relationship
-option to flag as not a match
-multiple tabs identify specific types of data; those with an asterisk have differences between the two individuals
-general: name, birth, christening, death, burial, pref spouse, pref father, pref mother, living flag
-family: spouses, children, marriage, birth, christening, death, burial
-events, research, medical, address, & pictures: n/a to nFS
-notes: shows all notes of an individual (in nFS, this could be all notes that anyone added, or just select chosen notes)
-LDS: ordinances performed
Viewing this data side-by-side, one can make more educated analysis than is presently possible in nFS.

I agree that it would be helpful to have more info displayed when doing combining. Things I would like to see: (Some the same as scion)

- I would like to see the dispute symbol in the combining screens, so if someone has added a dispute you could read it before combining.
- I would like to see the parents birth and death dates, a lot of the combining errors are father-son combining errors where there are multiple generations of people with the same names.
- I would like to have the ability to add a note tag similar to the dispute tag that would follow that persons name and where we could leave a short note about that person or combining warnings.
- I would like there to be a option that says "This is not a Match". Once someone selects that option, any time in the future that match is presented to anyone, it would issue a warning like: "Someone else has determined that this is not a match, please use caution in combining." It could even list the name of the person who determined it was not a match so people could correlate if someone else thinks it is a match.
- I would like the ability to mark records as records which contain gross errors in some of the data. Records marked with these types of errors should generate a warning when presented for combining. Example: some records contain multiple sets of parents, some have real bad dates that show they died before they were born or were married after they died, they might have the person hundreds of years old, etc. Disputes might work for this if those disputes showed up everywhere but they don't show up in the combine screens.

We do have the ability to click on some of the records while combining and get some more data but many people do not realize that they can click on people and see more info while combining.

Besides the "Not a Match" option, I would also like to see the ability to uncombine individuals become easier. It is an incredible hassle trying to find and remove one individual in a list of 150. The uncombining page is even less useful than the combining page. It displays very little useful information. I would also like to see on the uncombining page which record has temple ordinance dates, and what those dates are. Additionally, I would like to see on the uncombining page an option similar to the "Possible duplicates" feature, a "possibly different individuals" feature which groups the combined records into sets of similar data.

For a taste of how impossible the uncombining task is, take a look at Heber C Kimball (KWNP-GNM)- this "individual" is made up of the following unique individuals (Many instances of each) -

Heber C Kimball
Herbert Kimball
Thaddeus Constantine Hix
Tyrus Walker Hurd

I can't even get into the "Combined Records" view, it sends me back an error saying "FamilySearch could not process your request" after 10 minutes of trying to load. 10 minutes after clicking on the details view, nothing seems to have happened. Not only is this individual improperly merged, but it's nearly impossible to uncombine. Lots of problems, indeed.

Also, I'd like to see an option to identify that a person is a possible match, but cannot be confirmed. This would in essence tag the individual with a note that says "Possible match - sources needed". It wouldn't prevent someone from merging it in, but would make someone think twice.

In lots of lines there are possible matches that cannot be confirmed, but should not be discounted. If a user confirms that it's a possible match, but cannot confirm that it is a match, there should be some sort of notation, or a different area to place the individuals "under investigation".

Come to think of it, there should be a way for a user to tag something as "needs sources" like in Wikipedia. Then the nuts and bolts family historians can go in and clarify problems and issues on their line that were identified by someone else. A list of research issues pertaining to your direct line would accompany this.

The uncombining problem and the problems with folders with to many records are the two problems that I hear discussed the most and there has been a lot of feedback submitted on them. I am sure they are both high priorities.

We have been getting updates about every 3 months, we had one in Nov 2007 then Feb 2008 and another in May 2008. The next update should be in Aug 2008. Maybe we will get some help on uncombining in that update.

It would also be nice if when the "advanced possible duplicates search" is selected, the option to "Search by Number" were given, just as it is given in the regular search. I have seen cases where I contribute a gedcom, and (by looking at the list of people in my contributed gedcom), I can see the PersonId of a person I want to combine with another person, but the search for possible duplicates can't seem to find the person I want. It would be really nice if I could just use a search by number feature in the possible duplicates to tell it that the person I am looking for has PersonId nnnn-nnn or whatever, so I can actually do the combine.
As of now, I can find no way to combine an individual that for some reason or another isn't meeting the computed threshold for a possible duplicate, even if I know what the id number of that person is.

GarysTurn wrote:a lot of the combining errors are father-son combining errors where there are multiple generations of people with the same names.

I'd like to see such combinations blocked. I can't see any logic in allowing someone to combine a father's record with a linked son's record. That creates an impossible relationship. If someone wants to combine a record with one that's already messed up, they have to clean it up before they combine any more to it.

Unfortunately, the current system encourages this problem by displaying so little detail during the combining process.

Maybe a program routine that checks large folders for gross errors could issue a warning when attempting any type of combining into of from a folder which appears to contain gross errors. PAF generates a report of possible errors. Maybe a program routine that looks for that types of errors in folders that posts a warning to check all details because the folder appears to contain combining errors. The routine could check for things like:
-Death Dates before Birth Dates
-Marriage Dates before Birth Dates
-Relationships between records in the same folder (Father Son)
-Birth Dates and Death Dates making the person greater than 100 years old
-Children born when the mother is over 60 years old
-Multiple parents
-Children born after the death of a parent
-Marriages to a spouse who died as a child

GarysTurn wrote:Maybe a program routine that checks large folders for gross errors could issue a warning when attempting any type of combining into of from a folder which appears to contain gross errors. PAF generates a report of possible errors.

That was a issue I pointed out in the beta - there was no "sanity checks". I had accidentally made a boy who had died at the age of 3 in 1700's the father of someone who was born in the 1800. A big oops on my part (I was working from notes and grabbed the wrong person of the same name), but I was surprised there wasn't anything that warned me either during the operation or after the fact. A "check for errors" function is needed.

Yes, a subroutine in the program that checks for the type of errors described would work.

Using an example based on what I knew of BASIC programming theory back in the early 80s, a simple 'IF-THEN' type of subroutine would trap some of those obvious ones.

IF birthdate is greater than x years after parents birth THEN flag as problematic

Then the individual would know he had to look elsewhere for the information to see if this was indeed accurate, such as an adoption record or record indicating a guardianship situation where an older person might have adopted or entered into a guardianship type of relationship for some reason. Or some other extenuating circumstance .

A 100-year difference is simply not plausible, lesser periods of time with wide gaps would be harder to trap sometimes.

It seems to me that there are virtually no search parameters. Looking for someone born in 1850 yields folks who died 120 years later, and a century or two earlier, too. It doesn't match continents, either. A search for a US birth includes Canada & Europe. Searches focus on a first or a last name match, rather than both are absurd. Under very rare circumstances would Herman Goeglein also be known as Herman Collin, Herman Hoksbergen, or Herman Gold. This is a time consuming waste just begging for errors.

Aside from my very common Colonial American ancestors with tons of researchers, I have a good number of very uncommon (for the US) surnames. Searching for my less common surnames brings matches that are not in within 100 years of each other and only share one name--usually a given name. For example:

What you searched for:
Stanislass Dabkus b 1882

There were no close matches found. Only partial matches are shown below.
Partial matches: 6,099

Stanislass Dopkus b 1882 Russia (This one is him.)

Stanisaw, Count Sierakowski b 1884 <Preworsk, Glzn, Astr>
Stanislaw Smith b 10 Dec 1877 Bay City, Bay, Michigan
Casimir Dabkus Lithuania
Stanislass Meuneir
Stanislass Collette b 1776 of Bouctouche, New Brunswick
Kasmir Stanislass b 3 Mar 1891 Cook Co, Illinois
Charle Stanislass Chemitte
Stanislass Collette b 1776 of Bouctouche, New Brunswick
Cleopha Stanislass Florent Larantin b 21 Apr 1869 Jumeaux, Deux-Sevres, France
Stanislass Collette b 20 Sep 1844 Bouctouche, New Brunswick
Stanislass Bussy b 29 Nov 1784 Moyen, Meurth-Et-Moselle, France
Stanislass Catharina b 4 Sep 1854 Klara Forsamlin, Stockholm, Stockholm, Sweden
Sebastiana b 27 Apr 1882 Nossa Senhora Do Amparo, Amparo, Sao Paulo, Brazil

etc., etc. Why, pray tell, does this system "match" people based on only one given name or on only the birth year?

We had a good example of how sometimes this type of search results might prove helpful. We were looking for a family in a Census. We had found them in the previous Census and in the Census after this one. We could not find them anywhere. We then did a search by the first name only in the locality where we thought he should be and got about 100 hits. One of those hits was the correct family. The person who had done the extracting of the Census for the index had misspelled the surname. We never could have found this family the way the surname was spelled in a normal search.

If you notice Record Search now has options as to how exact of a match you want to see in the search results. That might be a good future option for nFS.