Page 1 of 3

nFS & temple ready place standardization

Posted: Tue Jul 08, 2008 6:18 am
by scion-p40
In the past, temple ready has "standardized" places for my ancestors thus:


  • moved pre-Germany Hamburg from Europe to the USA (YIKES!!)
  • plopped my Lithuanians into a different century by deciding that they were in the USSR
New FamilySearch continued this process by removing data from my great-grandfather's birthplace which was Precinct C, Seward County, Nebraska, but shows up as Nebraska. While this is not as drastic a change as the previous examples, it gives the appearance that I submitted it as "Nebraska" and that no better detail was available.

So, in addition to combining duplicates due to the manner in which the older databases were established, I also have to combine (although the consultant used a different term) myself as the submitter and "dispute" places randomly revised for no apparent reason. As a researcher, if I were extending my tree and found the above information which was then disputed by the submitter, I'd have serious concerns about the quality of that person's research.

Are there any plans to restore data to the original submission or fix this in some other manner?

Posted: Tue Jul 08, 2008 7:22 am
by garysturn
scion wrote:In the past, temple ready has "standardized" places for my ancestors thus:

  • moved pre-Germany Hamburg from Europe to the USA (YIKES!!)
  • plopped my Lithuanians into a different century by deciding that they were in the USSR
New FamilySearch continued this process by removing data from my great-grandfather's birthplace which was Precinct C, Seward County, Nebraska, but shows up as Nebraska. While this is not as drastic a change as the previous examples, it gives the appearance that I submitted it as "Nebraska" and that no better detail was available.

So, in addition to combining duplicates due to the manner in which the older databases were established, I also have to combine (although the consultant used a different term) myself as the submitter and "dispute" places randomly revised for no apparent reason. As a researcher, if I were extending my tree and found the above information which was then disputed by the submitter, I'd have serious concerns about the quality of that person's research.

Are there any plans to restore data to the original submission or fix this in some other manner?


newFamilySearch does not change any submitted information. What you are seeing is the combining results or standardized place names. When we combine multiple submissions, newFamilySearch can only display some of that information in the pedigrees and summary views. If you go to the Summary tab you can select which data is to be displayed. If no one has gone to the Summary tab and selected what informtation is to be displayed, then the default data will be sorted and you will see what ever is sorted to the top. The other possibility may be that you are seeing a standard place name displayed. If a standarad place name is displayed and it is not the place you submitted, then your place name should still show up in the details. The new standard place name function is a work in process and will improve over time. It attempts to find a standard place from the information submitted to display. You can go to FamilySearch Labs and look at the Standard Finder and leave feedback there on places you feel need to be updated. Your feedback is helpful so go there and leave feedback. I would also recommend leaving feedback at newFamilySearch.

Posted: Tue Jul 08, 2008 8:05 pm
by scion-p40
Yes, it does. I know what I submitted: Precinct C, Seward County, Nebraska. FS shows Seward County, Nebraska
nFS shows Nebraska
Not only was my original submission changed with FS, it was changed again with nFS.
The submitters are me & me.

Posted: Tue Jul 08, 2008 8:29 pm
by garysturn
scion wrote:Yes, it does. I know what I submitted: Precinct C, Seward County, Nebraska. FS shows Seward County, Nebraska
nFS shows Nebraska
Not only was my original submission changed with FS, it was changed again with nFS.
The submitters are me & me.

Was the submission to the Ancestral File? Some merging was done in the Ancestral File. Those records were added to nFS.

A place name is normally: city, county, state, country

Posted: Tue Jul 08, 2008 9:06 pm
by russellhltn
nFS uses the [color="blue"]Standard Finder[/color]. I'm not sure how your submissions got to nFS, if it came from an incorrect database or from the original submission to that database. But I'm sure it will try to standardize the name. This is important - not because it standardizes the text, but because it connect to a site ID. It helps when other comparisons are made. It doesn't have to try and match the text - it looks in it's database of place IDs. So it understands that your location is part of "newbraska" or even part of "каттышкан штаттары" (United States).

Just for fun I tried to submit "Precinct C, Seward County, Nebraska", but the closest I could come up with is "Seward, Nebraska, United States". A little digging suggested that "Precinct C Election Precinct, Seward, Nebraska, United States" is the correct place.

Posted: Tue Jul 08, 2008 9:34 pm
by scion-p40
Nope. It was on the time appropriate atlas that I read when researching that family. Farmland & prairies lacking towns were identified as Precinct A, B, etc. Changing submitted information makes the database even more unreliable than it was.

I have no desire to go through everything I have ever researched every time the church software changes it to see what is new and fix it. My family is an absolute mess on nFS. Furthermore, the links that I did on it do not show up for my first child to log on & view it.

Posted: Tue Jul 08, 2008 9:52 pm
by russellhltn
scion wrote:Changing submitted information makes the database even more unreliable than it was.


Not standardizing it makes it unsearchable. There is more then one way to spell a simple thing like the name of a country. Text comparison doesn't fly for a world-wide system.

As for "Precinct C" vs. "Precinct C Election Precinct", you'd have to take that up with the company that the church purchased the information from.

Posted: Tue Jul 08, 2008 10:21 pm
by scion-p40
I beg to differ. The "standardized" places are historically inaccurate, and in the case of moving Hamburg from Europe to the US, just plain wrong. It is not easier to search for a place in an unknown random year, than in the historically accurate place--let alone the wrong continent.

nFS also stripped several of my generations of their surnames (1800's in the US). They had surnames in FS & in my records. How, exactly, does this prevent duplications?

Hey, it even gave me a new spouse who absconded with two of my minor children. Can't delete "unknown" because their is no arrow by this particular "unknown", therefore the instructions to delete him are futile. It also added "unknown" spouses to ancestors who were mysteriously married on the same day as the known individuals.


A system that randomly "corrects" data like this makes a mess.

Posted: Tue Jul 08, 2008 11:06 pm
by russellhltn
scion wrote:The "standardized" places are historically inaccurate


For the goal at hand, does it matter if it's historically accurate? Yes, it would be nice to be that way, but it's more important that the location be accurately understood.


scion wrote:and in the case of moving Hamburg from Europe to the US, just plain wrong.


Agreed.

scion wrote:It is not easier to search for a place in an unknown random year, than in the historically accurate place


With standardized places it knows that someone born in the "13 colonies" is at least a place match for someone born in "amer colonies", "United States" or even "شتتهای متحدۀ امریقا".

scion wrote:nFS also stripped several of my generations of their surnames (1800's in the US). They had surnames in FS & in my records.


Different issue. I don't know what happened there. You still haven't answered how your data got into nFS. Your data may not have been in a format that nFS expected.

Posted: Tue Jul 08, 2008 11:56 pm
by scion-p40
The data was already on the old FS system.