Is a system re-check on profiles possible?
This discussion was separated from the original post dated 11/20/24 to enable a sole issue in each discussion, https://community.familysearch.org/en/discussion/169653/residence-required-information-is-missing
@Áine Ní Donnghaile posted "After the user has reviewed and corrected the reported errors, would it be feasible to run a system re-check on those profiles to ensure the tree is as clean as possible?"
Kommentare
-
Unfortunately, my question above has been separated from my point making my query less clear.
0 -
@Áine Ní Donnghaile The engineers will understand this request quite clearly. Thank you for your assistance in developing CET.
0 -
Áine, The errors are generated during the tree creation process. Immediately following file upload a new empty tree is created. Then the data in the Gedcom file is ingested in phases, persons first, then relationships and then all the additional sources and notes.
If during this process, as data is read from the Gedcom and copied into the new tree, the system encounters data that it cannot parse or accurately represent in the tree it generates an error. Reimporting the gedcom would only throw all the same errors.
The error generation process isn't really a tree quality check, although we have noticed that many of the errors thrown do surface previously unrecognized genealogical data problems present in the original software database and/or exported Gedcom file (ex. a Residence event with only a date, but no place). There are several research quality features in the FamilySearch tree software that might address your need. On each tree person details page, the system displays Research Helps. There is a long and always growing list of data problems and research suggestions that are algorithmically identified and displayed in the top right corner of the page. There is also a new Profile Quality Score feature being rolled out that guides users on compliance with some of the generally recognized research standards (data and source completeness, data consistency, and lack of data conflicts)0 -
Robert,
Since my question HERE was separated from my original question, I'm sure it's not as clear now as I tried to make it when I posted.
What I was trying to point out with my original question was that it often very difficult to find what error was being called out. We could fix and change and edit forever and miss something because it's not clearly defined.
I've been a tester on the DQS since the first day it went into Alpha test. I'm well aware of what it can and can't do.
0 -
Áine,
I saw that concern as well in the separate post. I did not respond to that one here, where it seemed to focus on resolving the errors and re-running a process to see if there was anything new or unresolved.
Regarding the sometimes cryptic nature of the errors, we completely agree and it has been a matter of discussions for some time. Given the diversity of data that is seen in the Gedcoms and the number and types of errors, it may not always be possible to give rich detail about each issue. There is work underway now to group and categorize the errors we are seeing in an attempt to give richer more actionable info on as many as possible. The expanding set of early access testers and uploaded trees is helping with this effort.0
