nFS & temple ready place standardization

[garysturn]

The data was already on the old FS system.

nFS is a collection of all submissions from everyone for the same person. It is designed to allow us to clean up the records of the Church and prevent duplication of Temple work. Until you or other relatives clean up the files they may have many errors displaying in the system.

The changes to the place names were probably made in Ancestral File prior to being included in nFS if they show different than you submitted them. There are ways to look at the information in nFS and find what happened if you can give us person ID numbers, maybe we can find some answers. nFS retains all information that is added to it in the format it is submitted, it may display a standard place instead of the place submitted but it retains that orignial information in the details.

Part of what you are seeing in nFS are other peoples submissions which have been combined with yours. Those with first names only were likely submitted by others, you just need to go to the summary tab and select the more correct name from the folder to display. Information submitted by others may have been submitted incorrectly.

Standard place names are also designed to identify where records for that locality are located today. Some historical place names may not be in the system yet.

On the subject of links from you back to your dead ancestors, those links will not be visible to any other person, each person will need to add those links back to their dead ancestors in their own accounts. This is done because of privacy laws.

[jbh001]

nFS is a collection of all submissions from everyone for the same person. It is designed to allow us to clean up the records of the Church and prevent duplication of Temple work. Until you or other relatives clean up the files they may have many errors displaying in the system.

And having said that, I don't see what the big deal is. When nFS finally became live in my area, I went in and started making the corrections I've been waiting to make ever since AF was taken off-line for not being Y2K compatible. I had a smattering of "non-standard" place names that caused nFS to spit out a warning, but it seemed to accept the "non-standard" placename regardless.

In the past, temple ready has "standardized" places for my ancestors. . . . 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.

Just for fun, I added (and have subsequently deleted) an event for one of my ancestors and entered the placename of Precinct C, Seward County, Nebraska. When I clicked Done, nFS complained that I had entered a non-standard placename, but when I clicked Done a second time nFS accepted it anyway.

Additionally, even though the only submitters of this information are you and yourself, you might still have to end up disputing the information because for some of the entries there is probably not a way to link your nFS "Person Identifier" code with the submitter information. For me it seems that nFS HAS appropriately linked me to my Pedigree File submissions, and I THINK it has linked me to my submissions tied to my Ancestral File Number. But some of those submissions happened long enough ago that I really have no way to independently verify whether this is the case. I KNOW that submission I have made that are in IGI are not changeable even though I submitted them. Because I have since come across more complete and acurate information, I have disputed some information in nFS fed from IGI even though I am the original source for the IGI submission.

It's not perfect, but it is now a lot better than it was before nFS came along.

Regarding your son not being able to view the links/information you have added, I have noticed that any information you add to a living individual (as noted by that individual's name being displayed in italics) are only visible to you. This is probably why your son can't see it.

Additionally, even if you know the AFN of a living individual and search by that number for them in nFS, nFS wil list them as "Unknown" or as a restricted record. This is to comply with privacy regulations, and I expect that such entries will remain unviewable until they age out of the system (i.e. the current year is 110 years or more after the birth date listed on that record) or until the privacy laws are changed.

[jbh001]

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.

The first step to take to get this corrected is to check with your ward clerk since membership data feeds into nFS. The situation you described above reeks of a problem with the membership records in question. If I were a gambling man, I'd bet that somewhere between your "new spouse" and "absconded minor children" there are some variances in the membership record numbers associated with each.

For example, in one ward I was in there were three adult biological sisters. When their elderly mother moved into the ward for a while, I noticed that only one of her daughters showed up on her membership record. Even though on the daughters' membership records she was listed, there were minor variations in spelling and/or birth date that had caused totally different record numbers to be generated for the mother (and also the father) on each of the daughter's records. Once I fixed the daughter's records, mom's record was automatically fixed and her record magically regained her missing daughters.

I expect that you are experiencing a similar situation. I would have the ward clerk verify that your membership record number (as shown on the upper right-hand corner of your IOS) is the same record number listed for the spouse on your wife's record, regardless of the name and birth date listed. I would then have him check the membership records of your "absconded minor children" to make sure that the membership record numbers for their parents match those on yours and your wife's respective IOS's. I'll bet the record numbers either don't match or are missing altogether.

If there are corrections to be made, it would be interesting to see how quickly they populate from MLS to nFS. If they don't show up after a reasonable amount of time, then I would send a message to nFS support about it.

It also added "unknown" spouses to ancestors who were mysteriously married on the same day as the known individuals.

Probably because the spouses are still living and thus subject to privacy regulations since the haven't aged out of the system, or no one has submitted the death information on the "unknown" individual, or it somehow got unattached from the "unknown" individual.

[russellhltn]

I had a smattering of "non-standard" place names that caused nFS to spit out a warning, but it seemed to accept the "non-standard" placename regardless.

Yes, it will "accept" it, but it will hinder any search utilizing the place name because it's non-standard.

[BradJackman-p40]

You guys just don't get it. You're thinking like programmers and not like genealogists. The accuracy of the place name is MORE important than the standardization. You don't understand how many hours of research go into finding the exact location, do you?

The difference between "Precinct C, Seward County, Nebraska" and "Seward, Nebraska, United States" is probably around 10 hours of real research. But nobody at NFS really cares about genealogy, they're more concerned about deleting accurate input for the sake of standardization, and never deleting an interminable list of erroneous duplicate entries for the sake of "database integrity".

Removing the exact birth location, the exact church in which one was christened, or the exact cemetery one was buried in makes your database useless. You're willing to sacrifice the validity, accuracy and usefulness of your database for the sake of a place standard? You guys never learn.

Scion has a real, valid point. He's right. You've overlooked some serious problems in NFS. Instead of sending out the moderators to do damage control and tell all the users they're wrong, why don't you take notes, and ask how users would like the program to run. You don't realize that people like Scion, myself, and others who CARE about accuracy are the ones who will save NFS from the same fate that caught up with Ancestral File, Pedigree Resource File, and the IGI - the utter uselesness due to inaccuracy and vagueness. Duplication isn't the only killer.

Well, because none of you have figured out the right response to Scion's post (instead of just telling him he made mistakes and his desire for accuracy is sacraficed for the "greater good" of all those people in Yemen researching Seward County, Nebraska), let me present it:

"Scion, it's possible that NFS' automatic place standardization edited your entries. I understand that it's important to you to include the term "Precinct C" in the place name. This was an unanticipated result, and we're sorry for the many hours of duplicate work this will cause you. Can you propose an idea that will allow us to maintain standard place names, while giving you the flexibility to add more exact place identifiers?"

I'll give you my reply, though I don't know what Scion would propose (you might want to ask).

Keep your list of standardized places. Genealogists use commas to define smaller, more exact place names. If you can't identify a more exact place name, standardize everything to the right of that comma. Keep a list of un-standardized, more exact place names for every larger standardized locality. Thus instead of NFS reacting in the following manner -
[INDENT]User input, or data input from AF, PRF, IGI, VR, etc.:
Precinct C, Seward County, Nebraska

NFS standardizes the input as:
Seward, Nebraska, United States (or in Scion's case, just Nebraska)
[/INDENT]NFS would react in the new manner as such:
[INDENT]User input, or data input from AF, PRF, IGI, VR, etc.:
Precinct C, Seward County, Nebraska

NFS Standardized user input as:
Precinct C, Seward, Nebraska, United States
[/INDENT]where underlined terms are unidentified, unindexed terms that assist in further identification for users, and bold terms are searchable, standardized terms that can be displayed in multiple languages and searched using non-latin characters. A person from Yemen would thus see the returned search as "Precinct C, شتتهای متحدۀ امریقا" (who knows what that really means, but you get the point). If they don't really care about knowing what area of Seward County their cousin Habib lived in, great. If they do, they can do a search for "Precinct C" and find out what it means or where it is. Most other alphabets are using latin characters for some words that don't exist in their language anyway, like "Internet" or "Microsoft", so it wouldn't be out of the ordinary for foreign users.

There you have it, a practical solution - something forgotten in the mad rush to defend NFS from all those blasted users! Genealogists can keep "Old MacGregor Cemetery" in the burial location, and the programmers can get warm fuzzies about standard places. Then, if all the data really is kept somewhere in it's original form like you say it is, you can have the data re-analyzed to bring back all of those incredibly important names of churches, cemeteries, and forgotten towns that programmers could care less about. Scion gets Precinct C, and you get Nebraska. Deal?

Great. Now, before you slip back into the old "programmers and moderators are right, users are wrong" mentality that dominates this forum, take a deep breath and think about whether you really want to alienate the most powerful users NFS will ever have. Real genealogists.

[alan_wambold]

I too have a problem with the use of standardized place names in NFS. I always try and get the place names correct as to the time and place of the event and do not like how standardization tries to force a display of modern names. Or remove the township level of a cemetery location. A couple of examples:

For the birth of a person in Jones' Plantation, Lincoln, Maine, United States in 1786, the standard finder wants to display this as China, Kennebec, Maine, United States. I give it credit for mapping to the correct modern location, however the place did not become known as China until 5 Jun 1818, and Kennebec County was not formed until 1799. As Brad pointed out often a lot of research goes into getting these things correct and it does serve a purpose in furthering our research to know the correct historical jurisdiction that an event took place in.

The above person is buried in Time Cemetery, Hardin, Pike, Illinois, United States. The standard finder wants to display Time Cemetery, Pike, Illinois, United States or Hardin, Pike, Illinois, United States. Either the name of the township the cemetery is in gets scrubbed or we lose the name of the cemetery. I know of many counties that contain two or more cemeteries with identical names and indicating the township is the only way to distinguish them from each other. I also like to display the cemetery because some may want to visit the person's gravesite. I know there was some discussion on these forums about displaying the names of hospitals for births and deaths and churches for christenings as being similar to showing cemetery names. I feel they are different and that hospital and churches names could go in the notes fields, but that cemetery names should be displayed as they are a geographic feature in a way the others are not (churches and hospitals change location more that cemeteries).

I have resolved my issues with NFS by just making it accept my non-standardized place names, but I am sure many are intimidated into putting in a standard place name when they see the red box telling them they have entered a non-standardized place name. I do like Brad's suggestion of the search being flexible enough to look at all elements of the place name string and trying to match to the right of the elements it does not recognize.

I am a librarian and value standardization and controlled vocabulary for the purpose of organizing information. What I would like if for the standardization to be historically sensitive, for every place there is an accurate way to describe it for each point in it's history of human habitation. In terms of the first example given above for the period of European settlement that would be:

Jones' Plantation, Lincoln, Maine, Massachusetts Bay (1774 to 3 Jul 1776)
Jones' Plantation, Lincoln, Maine, Massachusetts Bay, United States (4 Jul 1776 to 5 Feb 1788)
Jones' Plantation, Lincoln, Maine, Massachusetts, United States (6 Feb 1788 to 2 Feb 1796)
Harlem, Lincoln, Maine, Massachusetts, United States (3 Feb 1796 to 19 Feb 1799)
Harlem, Kennebec, Maine, Massachusetts, United States (20 Feb 1799 to 4 Jun 1818)
China, Kennebec, Maine, Massachusetts, United States (5 Jun 1818 to 14 Mar 1820)
China, Kennebec, Maine, United States (15 Mar 1820 to date)

This could be simplified by ignoring that Maine was a province attached to Massachusetts until 1820.

If there is to be standardization I would rather see events taking place in this location being forced to use the historically accurate place name for the time period. A database of tables of information such as above could be created in a genealogical version of the Geographic Names Information System created by the US Board on Geographic Names. It looks like the Standard Finder has the ability to do this if the date information is added to it. Until then those for whom historically accurate place names matter will just have to enter non-standard place names.

[garysturn]

I understand both sides of this issue. I don't know if there is a real solution that will make everyone happy.

From the programmers side they need to lump all the records from the same approximate area into one search group for searches to be able to find the records that people are looking for in a search.

From the researchers side they want to be able to identify right down to the exact historical location of an event. Even right down to the Church where a baptism took place, to a hospital where someone was born, or to a cemetery where some one is buried. All these place details can always be included in the notes since the software requries standardized places for searches, but this solution doesn't seem to satasify everyone.

There have been some provisions that have been made to allow non standardized place names to be entered and stored in details along with a standard place. In this case only the standardized place is displayed in the summaries and pedigrees.

The standardized place routine still needs refining as well and we can all submit feedback to help in that threw the help center in nFS or at FamilySearch Labs in the standard finder project area.

[greenwoodkl]

I agree with Alan. A database could be produced of location names with dates - it could even have its own pedigree of a modern place name branching off into all historical place names that would be included. Thus a search for the modern location would iterate through all included historical place IDs. Thus ghost towns could be included in the current county even if they have no modern place name to be linked to. And a specific town that has just been renamed or survived several larger political boundary or name changes could have a list of names paired with dates all sharing a place identifier with the modern equivalent and the system would need to store somehow the equivalent names for certain dates.

I think if historical place names have their own tree-based, pedigree-like system it will satisfy the programmatic need for pulling all records people would look for in a search as well as the genealogical need for accuracy in research. It could serve as an additional help for those who don't have a historical knowledge of what locations they could search for records. i.e. "Click here for additional historical place names for this location." or "Click here for historically-accurate place name for this modern location at the date of this event on this record." As a beginning genealogist myself, I would be more than happy to allow the more advanced genealogists to research historical place names so I don't have to unless needed. While I may agree in general with flattening records, I am hesitant to whole-heartedly agree with flattening the geographical and historical place names in the name of standardization without providing (even a future) solution to not lose important historical data that will lead to further research. Relying indefinitely on user-based lists kept in homes of mapping old place names with modern replaced equivalents in nFS is inefficient and unfortunate if allowed for long.

As for Brad's comment for mixed standard and non-standard place names - Since I am unfortunate enough to be sitting here in Utah waiting for eternity to get my hands on the nFS system (end of rant), I am unable to test any theory in practice. Does the nFS system see non-standardized entries as a two-part deal? Non-standardized + standardized? Could it search on the standardized and ignore the non-standardized while keeping the data, or is it just a hope and dream?

[scion-p40]

Thank you, Brad Jackman & Alan Wombold. I'm too young to have contributed my own 4 generation sheets in the 1970's, but followed the church directions to contribute often to the AF and of course submitted family to the temple & performed ordinances (each of which creates a separate event). I understand that following past church leadership directions has resulted the need for LOTS of combining, even though I am the only LDS researcher for much of my family until I get back near my Colonial American ancestors.

One thing that would likely decrease issues in what is viewed once someone has done some combining is to default to view the most recent submission. This would reflect changes in the research process. For example:
1989 I figure out that grandpa had 3 siblings, unknown gender
1992 I find out that the oldest is male
1996 further research yields initials TB
1999 his first name is Tom, but no hint of what B stands for
2003 determine that his name is Thomas Benton
The most correct name for him is Thomas Benton LastName. It would help if the latest info for each field of a given person is the automatic default in combining.

Maybe place options need a historical and a corresponding modern location for each event. However, that would require support & cooperation of other software companies for future updates. This would protect the validity of the data, as addressed in the Maine example provided previously.

As for my mysterious spouse, nothing in the directions was helpful because there was no way to select this living "unknown" to do any merging. (I did merge for deceased ancestors with no problem.) The church records (the source) are accurate; I read the printout in provided annually very carefully, even though I have had no new family additions in several years. Someone at nFS support responded to my email by phone and told me that she fixed it.

In my unbiased humble opinion, the long-term end users of nFS are the genealogists and historians who spend years ferreting out details. Those who will mine it for a name to provide a teenager for this week's temple assignment only get involved when compelled to do so by an external source; hence, they won't be concerned about details that they didn't bother to research.

[garysturn]

One thing that would likely decrease issues in what is viewed once someone has done some combining is to default to view the most recent submission.

The current nFS system allows us to select in the summary view the most correct version of a name, date or location. Prior to the Feb 2008 update of nFS we did not have this function and each persons personal submission was displayed as the default. If they did not have a submission the data was sorted and you ended up with the result of a sort. It created a lot of duplication of records because everyone needed to enter the correct name to get it to display. This new feature works much better. Now everyone sees the same information in the pedigrees and summaries and if there is a disagreement there is more incentive to correlate with others.