Do not allow two pieces of "Residence" data to be carried across during source linking.
As illustrated, many FamilySearch sources have two pieces of Residence data. The second piece is nearly always either very vague (can even just read "High Street") or is completely incorrect.
In thist case, the location of the place needs to be standardized (on the Details page) in order to avoid the Data Problem warning sign - not necessarily easy to standardize "Wisbey", let alone examples that just show a street name - "High Street where?"
As a second example, indexed parish register records (not illustrated here) frequently show the name of the parish as the Residence place, even if the original register shows a place of a different name that lies within the parish.
It is just not helpful to be able to carry this second Residence line across to the Details page, so I wish the engineers would not allow for every piece of indexed detail to be carried across (this applies even more so to "Marriage" data - very often indexed as being for the actual marriage event, when it actually applies to a licence or banns - and allow for such data to be evaluated from the Details page, and added optionally to the Details page by the user.
This is for illustrative purposes only - I am not about to attach this source to the wrong ID!
Comments
-
This example illustrates a source where the originally indexed record is treated in a completely different way. There is no option available to carry across the 1888 "Marriage Date". True, this relates to a marriage registration document, but there isn't even the option to carry the source across as a Marriage Registration event (to "Other Information"). So it is possible to implement my suggestion, although I admit it would not necessarily be a popular change for many FT / FS users!
No information available to be carried across when linking to the person's ID....
....even though a marriage date is shown on the indexed source / record:
0 -
I've noticed this most often with the 1905 New York State census. It brings two variations of the same address.
0