new FamilySearch Beta2 Complete

Discussions around Genealogy technology.
Post Reply
ceburgoyne
New Member
Posts: 5
Joined: Tue Mar 06, 2007 9:40 am

#41

Post by ceburgoyne »

I am a new member of the forum, but an old family history teacher. All this discussion of more controls of what people can enter is a worthwhile concern, but as long as the member has the minimum data required and has done their best at finding it, their data should be accepted. Research is very important. Better training of those submitting names is the answer, but let's not discourage those who are trying to learn the system . Help them to understand what is needed and do the best they can. Just because all we know is the name is Maria and an approximate date should not keep her from her blessings.
rzamor1
New Member
Posts: 7
Joined: Wed Feb 07, 2007 5:05 pm
Location: American Fork, UT
Contact:

Foreign Countries

#42

Post by rzamor1 »

My understanding is that one of the reason for such "low" requirements for approving a name for temple ordinances in the system is because people from all over the world will be using it to clear their names. The example given was countries like Africa where genealogy has not been written down but given orally. Only names are given and no dates or places so you need to be able to estimate that type of information so everyone in the world can submit their names for temple ordinances. If you put a lot of error messages and warnings about needing more information to clear names you are not thinking of the impact it will have to everyone in the world using the system.

The Church is already having the difficult task of deciding on time limits names can be held for temple ordinances. The needs are different around the world, not everyone can go to the temple on a frequent bases. I think right now it would be difficult to add the problem of different requirements for information needed for temple submissions because the impact is world-wide.

I think desktop interfaces will be the only solution to information requirements for temple ordinances. You could have requirements then based on the locality of the person submitting the information. Or the time frame in which records are available. For example: you should be able to get a wife's maiden name after the 1900s but maybe never get it in the 1700s.
User avatar
garysturn
Senior Member
Posts: 606
Joined: Thu Feb 15, 2007 11:10 am
Location: Draper, Utah, USA
Contact:

Older Records don't give full data

#43

Post by garysturn »

You also need to have the ability to do sealings for people where the original records do not give madain names. You can have a good source record stating that there was a marriage of: Jane Hatch daughter of William and Anna Hatch on the 16 Apr 1662 with a spouse name, but all you have for the mother is Anna. In many cases this is the only record available with the mothers name. Should Anna not have temple work done for her?
Gary Turner
If you haven't already, please take a moment to review our new
Code of Conduct
JamesAnderson
Senior Member
Posts: 773
Joined: Tue Jan 23, 2007 2:03 pm

#44

Post by JamesAnderson »

Tthis is a common scenario, even in extraction work they found the records simply didn't give the maiden name of the wife. We'll see this come out more as we get some of those records indexed. Was seen alot in European and Spanish/Mexican records.

That being said, I've seen the opposite too, some records are very detailed. some of the Mexican records I loaded into the computer in the late 80s regularly had grandparents as well as the parents listed. And those will come out of the woodwork when they put up the trees they extrapolate from the data. And the wife's full maiden name was often listed on top of all of that.
cerebralmatters42-p40
New Member
Posts: 1
Joined: Wed Apr 25, 2007 4:06 pm
Location: Central Illinois

merging as a means of eliminating duplicates

#45

Post by cerebralmatters42-p40 »

I've been anxiously awaiting the rumored "online version of TempleReady" -- and, as a local FHC libriarian and ward family history instructor, fielding many questions from FHC patrons and others about all the rumors. This thread has been very illuminating.

My concern relates to the merge function which has been described by the beta testers. Although I use PAF as my primary genealogy program, I consider the PAF merge function to be its weakest function. I've spent (literally) hours rejecting "potential matches" such as Anna Smith matched with Amber Smelling -- but cannot get PAF to find such matches as Amber Smelling, born 1823 in KY with Amber Smelling, born 1823 in KY (yes, same parents, etc.). Thus, when I need to perform a merge, I port my data into Legacy, merge, then port back to PAF (am currently test driving Family Tree Maker for same function).

I am assuming that the match finding aspect of the merge function on the new Familysearch will be, fundamentally, the same code as PAF. Please tell me that I'm wrong -- that the match finding algorithm for Familysearch will be more accurate and efficient than PAF. I'm not hopeful, given the descriptions already provided on this thread. For example, Legacy will re-evaluate the data after every merge, offering additional suggested matches (vis-a-vis, "if these two individuals are the same person, perhaps the spouses, parents, and siblings of each are also duplicates . . ."); an earlier post suggests this feature is not built into the merge function for Familysearch.

This concern may seem trivial, but the fundamental purpose for this endeavor is to reduce duplication -- and without a good clean merge, duplicate data will not be eliminated, it will be proliferated. As one with many ancestors who have had their ordinance work performed more than 100 times, I'm very invested in reducing duplication and increasing efficiency.

Shanna
rmrichesjr
Community Moderators
Posts: 3827
Joined: Thu Jan 25, 2007 11:32 am
Location: Dundee, Oregon, USA

#46

Post by rmrichesjr »

I have not used the merge functions in PAF, but what I saw in NFS is much better than you described. The code in NFS has to be drastically different from the code in PAF. For one thing, it is clear NFS has a much more complex data model. For another, NFS is said to be written in Java and running on Linux servers, and I seriously doubt PAF was written in an object-oriented language, let alone in Java.

NFS does do some re-evaluation as you seem to want. After merging a batch of duplicate records, NFS would find more potential duplicates for me to evaluate. When I would combined a person down to a single record, then combine his/her parents or children, sometimes that would bring in more potential duplicate records to consider for the first person.

Combining the duplicate records will be an iterative, time-consuming job. (It will be worse if a bunch of patrons blindly upload huge GEDCOMS without merging in their records themselves, but that issue has already been discussed.) The heuristics in the beta weren't perfect, and the system presented a few obviously wrong cases (but not very many). Based on what I saw in the beta that just ended, I think most of us will be reasonably to very pleased with it. And, the API and open-source client record managers will give opportunity to potentially improve upon the base web-based system.
User avatar
garysturn
Senior Member
Posts: 606
Joined: Thu Feb 15, 2007 11:10 am
Location: Draper, Utah, USA
Contact:

NewFamilySearch Merge different than PAF merge

#47

Post by garysturn »

The newFamilySearch function is much different than PAF. You are shown several possible matches at a time and can put a check mark next to the matches, then you are shown a split screen for each match to confirm that they are the same. Merges also do not actually merge the data, it just links all the duplicates together. There are links to some screen shots in some of the other threads, you can see some of the merge screens in those.
Gary Turner
If you haven't already, please take a moment to review our new
Code of Conduct
User avatar
garysturn
Senior Member
Posts: 606
Joined: Thu Feb 15, 2007 11:10 am
Location: Draper, Utah, USA
Contact:

Merging

#48

Post by garysturn »

Here are some screen shots of the Merging: Screens More Screens
Gary Turner
If you haven't already, please take a moment to review our new
Code of Conduct
rmrichesjr
Community Moderators
Posts: 3827
Joined: Thu Jan 25, 2007 11:32 am
Location: Dundee, Oregon, USA

#49

Post by rmrichesjr »

Gary's screenshots are great. There is one cool thing about merging that is not apparent from the screenshot. As you mouse over the names of the person, the spouse(s), the parents, and the children, all names that represent the same Person ID (PID) number are highlighted. If you combine as you go back, the children will be (mostly) combined as individuals before doing the parents. As you check possible duplicate parents, you can use the highlighting to see that the child named Son Smith on both sides is definitely the same person, which adds a bit more assurance that the possible duplicate records for Mother Smith or Father Smith are the same people. The highlighting is done by javascript in the browser, so it's very fast.
scion-p40
Member
Posts: 259
Joined: Sun Apr 22, 2007 12:56 am

comparison for possible merges

#50

Post by scion-p40 »

I looked at the screenshots posted, but find them lacking. Possible matches in Legacy indicate where information differs--relationships, various notes, places, templework, etc. With an automatic split screen to review the notes & sources too, I feel much more comfortable about my merging decisions.
Post Reply

Return to “Family History”