What measures are in place to prevent blatantly incorrect sources being attached?
Recently while researching the Sergeant family I found that two people who had been married in 1589 were split and the husband's source used to accommodate an 1800's marriage at the expense of the wife. I have detached the source from this 1800's marriage but I have no idea how to reattach it to the wife. see attached JPEG.
Kate
Answers
-
I have read your comments a few times and still can't work out exactly what you feel you need to do.
The marriage source is still attached to a female named "Sargent" with the ID M4NQ-34J. The only action that would be helpful is to create an ID for the Edmund Sargent who lived in the 16th century and attach the 1589 marriage event to him as well. Ideally, you should try to establish the identity of (Mrs) Sargent, so she can be provided with a more appropriate name.
Currently, the details / relationship attached to Edmund Sargent M4NQ-343 and his wife Mary Ann Werring look okay to me.
I don't feel the way you have worded the situation really reflects what has been done and what needs to be done here.
With regard to your main, general question there are certain warning flags that appear in certain circumstances (e.g. "Child born before mother"), but there is nothing to stop a careless user adding an event from a wrong century. In fact, occasionally there are even record hints given by "FamilySearch" suggesting a source of this type should be attached! The system works a little better when carrying out a merge ("Birth more than 3 years apart"), but there is little hinting provided to help prevent the kind of actions to which you are referring.
1 -
I, too, am having a hard time parsing your interpretation of the screenshot.
It appears to me that what happened was that a 16th century couple was conflated with a 19th century couple with a groom by the same name. The 16c couple was legacy data from a preceding system on FamilySearch, and was probably based verbatim on the indexed parish register entry for the marriage. The conflation was later partially undone: the husband was allowed to be hijacked to be the 19th century person henceforth, but the anonymous 16c wife was detached and left floating. The hijacking was incomplete, though, because the 16c source attachment wasn't cleaned up until you got to it.
While it's a useful tool, the change log has some properties that make it particularly difficult to use for this sort of disentanglement. It always shows the current values for all conclusions, rather than the values they had at the time when the change was made. This easily results in this sort of hijacking: the person who tried to clean up this mess in 2018 didn't see that the Edmund with the 19c dates was originally a 16c person, i.e. the 19c Edmund should've had a new profile created for him, and the 19c dates should've been removed from the 16c profile.
The 2018 contributor's change log reason of "incorrect merge" is also serving to confuse matters, because if there was any merging (combining of two distinct profiles into one), it was not in the current system. The 19th century Edmund did not have a profile before the 16c profile was edited to be his.
To finish cleaning up from this conflation, I think the easiest solution is to just create a new profile for the 16c Edmund. You can do this without even needing to retype anything: go to (Mrs.) Sargent's Sources tab, click on the marriage record, and click "Review Attachments". This will open Source Linker in a new tab, where you can create Edmund's profile by clicking "Add".
1 -
The only "measures are in place to prevent blatantly incorrect sources being attached" I am aware of, is to have the user understand that a Hint is meant to be computer-generated suggestion, and that the user take the precautions necessary to attach or reject, based on their careful research. Too many consider a Hint as a FamilySearch discovery that should be considered accurate; attaching low-lying fruit (Hints) to the incorrect individual can act as a magnet to collect other bad fruit.
0