Who is rating user trees?
Comments
-
Who is rating user trees? I have a person with 31 attached sources. I defy whomever is giving this LOW rating to point out inaccuracies beyond a situation where the man was already deceased and yet enumerated. I wasn’t there. I don’t know what, but obviously a miscommunication occurred due to reporter error, language barrier, inept enumeration or all three. My other pet peeve is that FS is quick to jump on geographics being wrong by some several months per time period and yet does not offer the correct locale. I am generally copying directly from the Archeon Baptisms as it was recorded, so take it up with them or perhaps provide the answer that you want instead of what appears to be playing a game of “gotcha”!
Lastly, I think software very user unfriendly and not tuned in to Germanic naming customs. A person at birth was usually given at least four if not, five names! People often went by their rufname and later would change to one of the other names in order to better assimilate. Apparently assimilation is a foreign concept in the New World Order, not sure. But in our ancestors’ time it was a thing…all the rage to Americanize.0 -
1- Regarding the low data quality checker score: It sounds like you have run into something that has come up here before. Having certain events dated after a person's death is programmed to be a critical error and flagged with a low score. This includes such things as the person's birth, marriages, and residences. As you stated, there is clearly an error in a census record because the man could not be living somewhere after he died. Errors in records should not be added to profiles. So just delete what I am assuming is the residence created when the census record was attached to get rid of its contribution to the low score.
2- Place names are complex and the data quality score is trying to help us get places as historically accurate as possible. But the Places database which is used for standardized place names in Family Tree is incomplete. Germany has been discussed here frequently because it has a complex history and there are still a lot of place names that need to be added to the database. Do you have a specific place name you could give as an example of the trouble you are having that so that the problem can be clearly discussed?
3- What is the problem you are having with names? Family Tree is very flexible when it comes to names. If necessary, a person's profile could look like this:
What more do you need for names?
If part of the problem with the Data Quality Checker is that it is pointing out that a source has a name for a person that is again an error in the record and not appropriate to add as an alternate name, then just dismiss the flag.
2 -
@Karyn Castagna
You may wish to read some of the articles about the Data Quality Score or join in the discussion in the Data Quality Score Feedback group.
https://community.familysearch.org/en/group/323-data-quality-score-feedback
1 -
If I delete the census in question they will flag me for not attaching it to all the named people. I no longer care.
0 -
@Karyn Castagna , I'm sorry to hear you no longer care. However, since this is a public bulletin board and there may be others that run into this same situation I am going to go into a detailed explanation of the problem you have run into and its solution for them. Please feel free to stop reading now.
As I have seen how the Data Quality Checker works, the basic principles I have run across are the following:
- The DQS checks a profile's data for internal consistency.
- The DQS checks a profile's data against known statistical information for its time period and location.
- The DQS checks a profile's data against the data in attached sources.
- The DQS checks for minor housekeeping tasks such as making sure information is complete, data is tagged with sources, and standardized place names are correct for dates in the profile.
- The effect of any one flag on the final score depends on the severity of the inconsistency found.
- Since the DQS is comparing indexed sources which at times have a high rate of errors to, ideally, well researched profiles the flags can very often be pointing out errors in an index instead of an error on a profile.
Since life is inconsistent and indexes have errors, the DQS will identify items that are not actually a problem. Because of this, almost all DQS flags can be dismissed. As researchers, however, we need to have a good explanation as to why a flag should be dismissed. Flags that point out biological impossibilities, however, such as dying before being born, are not dismissible.
A final fact of history that just needs to be understood is that original sources can and often do contain errors. Genealogical research is not just blindly copying any and all facts from sources into a profile, but evaluating, assessing, and understanding sometimes conflicting source material and compiling it into the story of a person's life. Wrong information in a source should not be put on a person's profile.
Now to review one of the situations pointed out in the original post here: "I defy whomever is giving this LOW rating to point out inaccuracies beyond a situation where the man was already deceased and yet enumerated. I wasn’t there. I don’t know what, but obviously a miscommunication occurred due to reporter error, language barrier, inept enumeration or all three" and "If I delete the census in question they will flag me for not attaching it to all the named people."
I have adjusted data in the BETA FamilySearch to obtain images to illustrate what is going on.
Here is a profile with a High score. He has a residence derived from the 1940 census and the source for that is on his profile. The source is consistent with his life span:
If I change his death year from 1961 to 1939, the score immediately drops to Low.
This is entirely correct and appropriate. By definition a person cannot have a residence, that is, "the place where someone lives," after one has died.
The DQS explains the problem:
But it does not, and probably never will be able to, point out all the possible reasons for this conflict. Maybe the day will come when AI will be good enough to give all the likely reasons but by that time genealogy research will probably just be putting in our name and birth date then coming back a few days later to a full pedigree.
Some of the possible reasons for the conflict are:
- The death date is wrong.
- The Event is miscategorized and is not a Residence (this happens frequently with obitiuaries).
- The source is not for this person.
- The source really is for this person but is wrong and has incorrect information.
This flag, "death happened before a residence," is one of the few biological impossibilites that are checked for and cannot be dismissed. The data has to be dealt with. This is quite straightforward :
- Check the death date and correct it if it is wrong.
- Create a new, different, correct type of Event, a Custom Event if necessary, transfer the data to the new event, and delete the residence.
- If the source is not for the person then detach it. However, if it is for the person do not detach it as that creates the risk that someone will use the source to create a duplicate or an incorrect profile from the source.
- Put a note on the source as to what information in it is incorrect and why and remove from the profile all of the incorrect information that came from that source.
In this hypothetical situation and in the original poster's actual example:
- The death date is correct.
- The data really is for a residence.
- The source really is for the person.
- The source is wrong in that he should not have been enumerated in this census and he did not have that residence.
Therefore:
- The death date should not be changed.
- The data cannot be recategorized.
- The source should not be detached because it is for him and detaching it will just cause a hint for it to appear on his profile and the Unfinished Attachments notice to appear on the sources pages of other people in the source.
This leaves the fourth option:
- Since the source is wrong and he did not have a residence at the time of the census, his profile should not say that he did and that residence needs to be deleted.
Deleting the residence removes the flag and the score returns to High:
As seen here, the incorrect source that cause the problem is still attached:
A note should be added to it:
but there are no DQS flags that reference it at all.
This is a situation where the DQS correctly pointed out that incorrect information from an error-containing source had been incorrectly placed on a profile and needed to be removed.
7
