Nfs - q&a

[sbarnsley-p40]

Interesting statements made (in the Quality and Truth thread), yet we have a product in NFS that has absolutely no QA built in. The main premise of NFS was to stop duplication, yet duplication was never clearly defined. For example which types of duplications? One support missionary said that duplication was the same but different, yet the Oxford English dictionary clearly defines a duplication as exactly the same. If a product was built with no clear definition in place, then what exactly is it stopping? Second QA question is why doesn't NFS have quality control built in. It is easy to clear names/partial or other with no information. The less information that you have the more likely you are to duplicate work that has already been done, because the program is not going to know if *Ann* with no information is the same as Ann born abt 1830 or 1840 or 1850 in the US, or Canada or England or France or somewhere else. The least amount of information required the higher the probability of duplication regardless of the definition used.

There needs to be checks and balances built into the program, and a fair amount of quality assurance, without it, those duplications that were the premise behind this program in the first place will be meaningless, particularly when the program is adding to the problem it was built to stop because of its wish washy parameters.

[KathrynGZ]

It is easy to clear names/partial or other with no information. The less information that you have the more likely you are to duplicate work that has already been done, because the program is not going to know if *Ann* with no information is the same as Ann born abt 1830 or 1840 or 1850 in the US, or Canada or England or France or somewhere else. The least amount of information required the higher the probability of duplication regardless of the definition used.

There needs to be checks and balances built into the program, and a fair amount of quality assurance, without it, those duplications that were the premise behind this program in the first place will be meaningless, particularly when the program is adding to the problem it was built to stop because of its wish washy parameters.

Amazing... as I read Jeff's article, I was having very similar thoughts and then scrolled down to read sbarnsley's post! First, I LOVE nFS and use it regularly. That being said, I've expressed the following concerns elsewhere but I think they bear repeating since the problem still exists and is serious: nFS encourages duplicate temple work in two key ways:

1) It marks all names "Ready" by default (except when the birthdate is less than 110 years ago and there's no death date). This includes extraction records, Ancestral File/PRF records, and individual contributions. If we're trying to stop duplicates, "Ready" should not be the default.

2) It forces users to clear an ENTIRE family at once with every possible ordinance, rather than allowing the user to select the individual(s) who is/are ready.

If we're serious about preventing duplication, these issues need to be addressed--and the sooner the better, since Utah is coming on board now

I'm just curious: are the developers certified or trained in family history?

nFS is a marvelous tool and can be even better as it better supports the reality of doing quality family history work.

Kathryn

[aebrown]

1) It marks all names "Ready" by default (except when the birthdate is less than 110 years ago and there's no death date). This includes extraction records, Ancestral File/PRF records, and individual contributions. If we're trying to stop duplicates, "Ready" should not be the default.

NFS does not mark all names "Ready" by default; rather, it marks only those names as "Ready" that meet all the requirements for temple work. An ordinance will not be marked "Ready" if that individual's record does not meet all the requirements.

So you propose that "Ready" should not be the default. That raises some obvious questions:

1. What do you think the default should be?
2. If a record meets all the requirements for temple work, but is not "Ready" then what causes it to move from this new status to "Ready"?

Personally, I don't see how it makes sense to have the status be anything but "Ready" if all the requirements are met.

Or are you suggesting a different set of requirements for a record to be deemed to be ready? That would seem to be quite a different question. There may well be some tightening of the requirements that may be appropriate. If you have suggestions in this regard, it would be nice to hear specifics.

Clearly, it could also be the case that not all duplicate records have been combined, and one instance of an uncombined duplicate record appears "Ready" but really just needs to be combined with the records that show the ordinance work. But that's a separate question as well.

I'm just curious: are the developers certified or trained in family history?

I imagine that some are, but that really shouldn't matter. In any large-scale development project, you will have highly-qualified subject matter experts who help develop the requirements, and highly-skilled developers who write the code to meet the requirements (I'm oversimplifying, but that's the basic structure). Unless you're really lucky, your best developers are not going to be your best subject matter experts, so the best strategy is to combine the efforts of the best in both realms.

I guarantee that there are plenty of family history experts involved in creating the specifications for this project, which is as it should be.

[russellhltn]

Or are you suggesting a different set of requirements for a record to be deemed to be ready? That would seem to be quite a different question. There may well be some tightening of the requirements that may be appropriate. If you have suggestions in this regard, it would be nice to hear specifics.

Keep in mind that one of the reasons for the apparent loosening of restrictions is to accommodate other cultures whose genealogy reads like "Abraham begat Isaac; and Isaac begat Jacob; and Jacob begat Judas". As such, the genealogy is based on relationships, not dates and places.

My suggestion would be to have a different set of criteria based on the time and place.

[garysturn]

The duplication that nFS is intended to reduce is twofold. The attempt is to reduce the duplication of Temple ordinances for the same individual and to reduce the duplication of research effort. nFS accomplishes both, it is not perfect but it will continue to be refined as we time goes by.

Duplication of Research
In the past the process to do ones family history required each individual to first discover what family history information the church already has on our family then determine what temple ordinances have already been completed. Once that information was determined you could then begin researching on areas of your family lines that are missing. This process is then repeated by every individual in the church. It is estimated that if you go back 5 generations, that individual will have about 10,000 descendants. So if each of those 10,000 descendants spends 100's of hours to just discover what work has already been done, just look at the time nFS will save by organizing all this information one time then it is available to all.

Duplication of Ordinances
In the past the process to clear names for the temple was to check every name against the IGI and then run the names through Temple Ready. The names in the IGI and in Temple ready are not connected into family pedigrees so it is more difficult to identify duplicate individuals. With nFS all names are organized into family pedigrees and linked to other family members. This way you can easily tell if a person is a duplicate based on relationships. It will take some time to get all of the names from the IGI combined and linked into these pedigrees but once that is done future duplication will be greatly reduced.

[garysturn]

Qualification for Ordinances
The requirements for a name to be submitted for temple ordinances has changed in nFS. Before nFS the requirement included names dates and places. In nFS you are only required to have a name and a relationship. When a name is linked into a family Pedigree that is a very good way to determine who the person is and to find duplicates. It is always better to have as much information as possible, but you can have very good sources proving a name where you do not have any dates. It is better to enter the information you know and clear a name based on a relationship than under the old way by guessing what the birth date is and putting "of" for a place.

EXAMPLE: If you have a birth record for Denver Colorado, John Doe born 14 Sep 1845 son of James and Mary Doe. You have a good source for the name James Doe.

In nFS this would allow you to do James Doe's work. The nFS record would show James Doe father of John Doe born 14 Sep 1845 in Denver, Colorado and James was married to Mary.

Under the old system someone might submit that name as James Doe Born Abt 1824 of Denver, Colorado. There would be no relationship to the record and when someone found James Doe who was actually born in Missouri the name would be duplicted.

[russellhltn]

In the past the process to clear names for the temple was to check every name against the IGI and then run the names through Temple Ready.

It should be noted the that copy of the IGI that TempleReady checked against was last updated just prior to 2000. For all the warts the current system has, the old one had some serious problems. I don't know why the church didn't update the old IGI.

I suspect that trying to update the old system would have been a major distraction in getting the new system going

[jbh001]

I've heard that the original Ancestral File was taken offline because it wasn't Y2K compatible, and that the nFS is the result of trying to make Ancestral File Y2K compatible. But along the way the design/development team had many times when it was suggested "if we have to fix that problem why don't we also fix this other problem..." We are now seeing the results of all that re-designing.

That it has taken this long to even get to nFS in its current state is a testament to the myriad of complexities involved in trying to kraft an application that will scale to manage such an enormous data set.

It might be possible that IGI was not updated after 2000 for similar Y2K problems, or just because the demands of IGI exceeded the capacity of the then available technology. Remember the set of 80+ CD-ROMs you had to swap out? DVDs were available as a possible media replacement for CDs, but it would have been a financial and logistical nightmare to try and upgrade all those FHC computers around the world with DVD readers.

Since then, the Internet has made the need for producing a fresh batch of CDs, DVDs, BDs, or even HVDs unnecessary.

[russellhltn]

I've heard that the original Ancestral File was taken offline because it wasn't Y2K compatible,

I find that hard to believe. When you're dealing with ancestors, you're routinely dealing with dates in the 1800s and 1700s. If it was a Y2K issue, it wasn't the classic "last two digits" problem. Since I've never heard of anyone complaining about being unable to access the old AF CDs, I don't think there was a software library problem.

From what I heard, the real problem with AF is that it failed to deal with disagreements between submitters. Different people thought a given individual had slightly different dates. nFS allows multiple dates and even allows each person to see their own preferred "version of the truth". Edit: I've been informed this part is no longer true. But nFS still allows multiple dates for each event.

After AF was stopped (in 1996 if my sources are correct), the church moved on to PRF where each submission stood on it's own. No attempt to match them up into a master tree.

If the church had wanted to, there was a simple solution. Ohana Software had created PAFInsight which could search the on-line IGI and it worked great. Not only did it automate the process of checking individuals in one's PAF file, but the search results were much more through.

But ultimately, it didn't fix the bigger problems the church was looking at. A Gary pointed out, one problem was the need to reduce duplication. Another was to meet the needs of other cultures and allow work to be done based on relationships alone and not just western-style genealogy information.

Also, the church had a need to connect the temple work submissions to the submitter. The TempleReady system had contact information, but it was "frozen in time" and not easily connected to one's membership records. Nor was there any information indicating the relationship between the submitter and the person being submitted. This link should provide the back story on that requirement. I've heard the issue is not unique to this group.

Also, in the last few years, I think it's clear from examples like Wikipedia that not only is on-line the future, but so was the need for collaboration.

Lastly, there is an increasing realization that we need to move from conclusion based genealogy to source based. nFS is still in the very early stages of this, but I think we'll be seeing more as they start connecting Record Search with Family Tree.

We have to remember that nFS is not yet at "version 1.0". But the driving needs were great enough to force us to get in at beta level.

[jbh001]

I find that hard to believe. When you're dealing with ancestors, you're routinely dealing with dates in the 1800s and 1700s. If it was a Y2K issue, it wasn't the classic "last two digits" problem. Since I've never heard of anyone complaining about being unable to access the old AF CDs, I don't think there was a software library problem.

But remember that the original AF was designed on MS-DOS, which wasn't completely Y2K compatible. Even if the AF database itself was Y2K compatible the underlying OS it was developed on was not. I'm assuming that when they were forced to do something about the Y2K issue and the software interacting with the underlying OS, they also decided it was the right opportunity to finally address the other issues you mentioned.

I viewed PRF as a stop-gap measure while the successor to AF was being developed.