What's the best way of dealing with all those ???? wives?
No, I'm not using ???? to hide an expletive, although I do get rather exasperated at seeing this issue, time and time again.
The history of the problem itself has been discussed here on several occasions and involves records that were imported to Family Tree in 2012. However, we are faced with the problem of how to deal with these IDs now. If it were down to my personal choice I would merely detach all the relationships between wives named "?" and their husbands, ensuring that no child remained attached to them (the "?"s). However, I have been advised on an earlier occasion that these (unknown / ?) records were used in ordinance work in the past, so am reluctant to do anything that might inflict damage on such work.
I will use a specific example to illustrate my problem - that of William Alderson GGZZ-3SW. I found existing IDs for his seven children, but six of these had different "?" IDs to represent their mother(s). In the past I have merged these* until I have got down to just the one ("?") ID. However, this still leaves me with a "profile" for which I have an "Invalid Characters" data warning flag.
Obviously, the situation would not arise under normal circumstances today - if a wife / spouse is unknown we simply do not add any record (wife / mother) until she can be identified - even if by just a first name. As you will see from the Details page for William Alderson (at https://www.familysearch.org/tree/person/details/GGZZ-3SW) the children are all "correctly positioned" under him (alone) at the top of the page.
I would be grateful for any thoughts on the situation, though do suspect my options are limited to those I can already think of myself! I would ask other users not to make any changes at present, so anyone else interested can view the page as it currently appears and add comments from that basis.
(** Of course, this has been on the assumption that there was the same mother for all children!)
Best Answer
-
Not all data errors can be corrected nor should they be if they cannot be corrected correctly.
It looks like you are confident all the children had the same mother. If that is the case, I would merge all the ? to be that single mother, add her as the spouse and mother where you currently don't have one, and put a note under her name: "? was entered as the unknown mother's name in a previous system where it was allowed. It is connected to underlying data for the family and so should not be removed. It could be replaced with Mrs. William Aldersen, Unknown, or NN but these are all just as meaningless placeholders as ? is so there is no need to at this point."
Building up a tolerance for blank lines on a form and data errors which are currently unsolvable mysteries is a good trait in a genealogist.
3
Answers
-
Sorry to anyone who might have been reading this whilst I have been editing. I just realised I do have a solution to one of my problems - sentence just deleted - in that I can set the preferred spouse, as illustrated, in order to see William and his children in Landscape view.
0 -
Thank you for the prompt response.
On the issue of the data error warnings, I admit I have become quite used to ignoring them: particularly those that have been carried across in "non-standardized format" when linking a source. Personally, I now try to avoid carrying across "High Street" / "Main Street" place names (in exactly that form) when I know the option will then be for me to (a) put up with seeing a red ! mark indefinitely, or (b) trying the often far-from-easy task of working out, "High Street 'where'?", so the address can be standardized!
0 -
A variant of this same question was raised this week in the Hungarian-language section: what to do with legacy profiles where the father of an illegitimate child was indexed — and therefore created — with the "name" "Unknown Father" (in whatever language).
Here are some examples of what these look like in Source Linker:
(I think the hinting system got the wrong specific profiles on that last one, but it is correct in that those are also legacy-data nonsense.)
Like Paul, my first instinct would be to detach the garbage, correct the index (if possible), and get rid of all evidence of cluelessness — but (also like Paul) I don't know how that would affect LDS stuff. Also, the thought of causing all those floating unknowns doesn't appeal.
The person who raised the question in the other section was specifically worried about people taking the legacy data as their model moving forward, i.e., people creating fathers "named" Unknown, because that's how it has been done since 2012. My thought is that a Help Center article addressing the issue might be a good thing — but of course, the fact that I can't get it to cough up such a thing doesn't necessarily mean it's not there. Has anyone encountered instructions about what to do with all those Mr. Ismeretlens?
2 -
During the few decades when church policy was that for "LDS stuff" the title Mother could be substituted when the mother's name could not be determined, it was still required that the father be identified by name. Indexed records with Unknown for the father should never have generated underlying data visible only to church members so don't worry about that complication.
I still don't know what to do with those Unknown father entries, however.
3 -
@Gordon Collett - said "… it was still required that the father be identified by name. Indexed records with Unknown for the father should never have generated underlying data visible only to church members so don't worry about that complication…"
Maybe I am missing who would be handling such profiles, but is there a possibility that the church members in question did not realise that the father was "Unknown" and actually thought that the chap's name really was "Ismeretlen" and thus created Church records for him? (Apologies to Julia if I got the precise Hungarian wrong there - I'm just Google translating…)
0 -
I would think that completing work with father's name "Unknown" in a language someone did not know would be invalid. But I don't really know how that would be handled.
0