Marital Status
I'd like to get other's feedback on documenting a Person's marital status as an event on the Person Details (not the Spouses relationship).
By default, records like Census records typically include a marital status like single, married, widowed or divorced, but when attaching a Census record, the date isn't added to that marital event. The result simply says the Person is Married, Single, etc., but without a date it really provides almost no useful information, so I usually don't include these events when attaching Census records.
An exception to this would be; if a Census record states one spouse is a widow/er and the date of death isn't known for the other spouse, then this is good to document, but it's important to go back and add the date and note on the event and also on the spouse's Death information.
My feeling is that the Spouses relationship is the best way to show this changing status for people.
I'm curious what others think.
Thanks,
John
Best Answer
-
I don't move the Marital Status to the right in Source Linker, but I do like to go back and put "Widowed" or "Divorced" as a description for that year of Residence. (This way it's not a separate, meaningless item in Events, but it has some context with the year where it applies.)
I don't usually worried about noting when someone is "Married" unless they had multiple spouses. Then I often put "Married to Alice" to specify who was the spouse at the time of that census record.
3
Answers
-
I raised a similar point some time ago in the Source Linker Feedback group, but received a negative response. The response suggested it would involve complicated programming to connect the year of the (census) record to items like Marital status or Occupation - and it is true we can add dates to these (one back on the profile page) if we wish.
Personally, I choose not to carry certain items across in the source linking process if I feel they will look pretty meaningless. For example, there are also the "Residence" fields, whereby there are often two on the record, one of which invariably needs standardising (e.g., "John Street" - John Street where, in any case).
Incidentally, another issue I rose was regarding Occupation. If this is identical to the one already on the profile page it cannot be carried across, but if just the case (upper / lower) is different, one can carry it across. I also raised that point quite some time ago: the point was acknowledged, but the "coding" hasn't been changed, in acceptance (say) that "Carpenter" is exactly the same as "CARPENTER"!
In summary, I choose to carry across only the items that I am willing to amend or add detail to (e.g. a date), when I return to the profile page after adding the source. Otherwise, I believe you'll have a job to persuade the engineers to make the change(s) required to address these issues.
3 -
Yeah, I'm not sure what exactly can be done programmatically for marital status, but in all but a few cases, marital status at a person level is fairly meaningless and really only makes sense for a relationship where you can see a list; married, divorced, etc.
I do the same with Occupation and Residence. It would be nice to be able to edit an existing value so that it's merged with a new one while attaching.
I'm glad it's just not me.
0 -
I have a lot of sympathy with @Paul W when he says "… Personally, I choose not to carry certain items across in the source linking process if I feel they will look pretty meaningless …".
Just because it's there doesn't mean it needs to be copied over to the person's Profile, and yet (sorry if anyone objects to me saying this but…) there are plenty who will copy stuff over without thinking whether it makes sense. If the Profile has a marriage event on it, then what on earth is the value of Marital Status "Single" sourced by censuses before the marriage event? Or Marital Status "Married" sourced by censuses after the marriage event? Frankly I delete them with the comment "Redundant".
This does not mean that all Marital Status items should be removed. A value of "Widowed" is invaluable to point someone towards looking for the death of a spouse, if I don't have time or incentive to find it myself. Or there's the case of the woman who married a distant relative of mine who burned through 5 different husbands with a relative lack of divorces and spousal deaths - her Marital Statuses (if dated) might provide clues to what was going on. Or at least, what she wanted you to think…
So basically, I think I'm in general agreement with @John Yungk for the above reasons
4 -
Well stated
0 -
It would be nice to be able to edit an existing value so that it's merged with a new one while attaching.
While it takes an extra step, it's possible to combine multiple references. We can tag a reference to race, marital status, or other Facts. If a find that a profile I follow has multiple references attached race, for example, I delete the extras and tag the several censuses or draft registrations to a single race Fact.
Some attached sources will create a race Fact with a single letter W, others use the full word White, while others may import Caucasian. We don't need 3 facts for the same thing.
4 -
Like others have stated - I too remove unhelpful entries in the Other Information box that are redundant and/or of no historical genealogical or personal benefit. Another example that eluding my exact memory of the wording, would be the filing (with date) of the social security program. Great, you filed a paper on such and such date; no location, no benefit to history.
To your specific Married/Single entry option — There is already a spot to enter a marriage date when known, or even a year that can be gleaned from a census record; that is entered in the Marriage box under Spouses and Children. You can also see that there was a relationship when you enter a Spouse under Family Members. Conversely that they are single if there is no spouse listed there. To have a single word entry is very redundant and unhelpful.
I do add Occupation & Home Address to the details on Residence entries when the record includes them, i.e.: census.
Here's what it looks like in data entry:
Yes, you can put the home address in the Place of Residence, and it won't foul the standardized place; but OCD me does not like it there when you don't have the same format on every entry. This detail is Very helpful in big (and small) cities with folks of similar names, as well as extended family living in close proximity.
2 -
I do pretty much the same, but tag all sources. Sometimes I'll comment about the dates if I think it's significant.
0 -
Race of W and White is particularly annoying, but glad to see you and others clean this up as I try to do also.
0 -
Sorry to say, but another example of how the quality of information and presentation in Family Tree is becoming an example of "junk genealogy". I agree that during the Source Linker process you don't have to move information into the individual's profile, but it's unrealistic to train people to analyze what is genealogically significant, especially as we become more "robotic" in our analysis and decision making processes. …. just sayin'
0 -
Widowed and Divorced are important pieces of information and the context is important. This is a nice way of adding this info.
1 -
We have dedicated fields for marriage, divorce and death dates. "Marital Status" offers nothing that isn't better accomplished using those other fields, and is fairly useless and annoying in its current implementation where no date is is automatically added to the event, especially when people add the the "single" designation.
The only use cases I can see for the using Marital Status is when you have a sourced marriage date buy absolutely no information about the spouse, and I'd still argues that using a ? profile for that is better than even a dated Marital Status event.
1 -
And for widowed, if I don't know the date of death for the Spouse, then I usually add it to the comments in the spouse's death information, opposed to using a "before" or "from/to" date range if it spans more than a couple of years because it's carried over correctly to the search.
Example: John Smith is Widowed on the 1930 Census and his spouse Mary was alive in 1920. If I were to set the date of death of "from 1920 to 1930" or "before 1930", then Search uses 2 years before and 2 years after the upper range, resulting in a search using 1928 to 1932.
0
