Under "Couple Relationship", we need "unwed"
LegacyUser
✭✭✭✭
Melissa Johnson said: Under "couple relationship" we need "unwed". You now have living together, etc. Why not unwed? I have run across a number of women who had their child while single. No judgement.
Tagged:
0
Comments
-
Jordi Kloosterboer said: The unwed couple relationship has the same idea as the living together couple relationship. If a woman had a child while single and does not live with or marry another person, then there would be no couple relationship, either. Therefore, I think the unwed couple relationship is unnecessary.0
-
Tom Huber said: Living Together is the same as unwed. It means that the couple lived together, but were never married to each other. A handfast is a form of marriage, even though it typically lasts for one year and then is renewed.
When a couple has a child and lived together, then Living Together is used.
If a couple have a child and never lived together, then the child is listed twice -- once under the mother's name and once under the father's name. A note should be applied to the child's record about the mother in the child-parent relationship. The same is true of the child's record about the father in the child-parent relationship.0 -
Jeff Wiseman said: If you look closely, all of things that you are calling couple relationship "types" are NOT "types" at all. They are "Events" that have occurred during the Couple Relationship. They are defined by a time and a place. There is no such thing as a "Marriage" type couple relationship. There is only a Couple Relationship that may have had a Marriage event occur related to it.
"Unwed" is not an event. It is a fact.
However, "Unwed" is more vague than the "Lived Together" event. "Unwed" might mean they lived together raising a family without ever being married. But it could also mean that they DIDN'T ever live together and raised the family.
The Couple Relationship "Facts" intentionally do NOT include "Unwed" for two reasons:
1. If they were not married and living together, that "Lived together" event is already defined for their couple relationship.
2. If they were not married and did not live together, that "Fact" is not necessary as a Couple Relationship Fact because there was not ever a relationship in the first place. If there was no Couple Relationship "thing" between the two people, there is no place to store a relationship fact.
If no relationship existed between two people, they should not be showing up together inside of a "Couple Relationship Box" in the family grouping graphics. Documenting a relationship where none existed doesn't make any sense to me.
And then, if you document a relationship where none existed, and then have to ADD information to that relationship to clarify that the relationship didn't exist (even though you just documented that it did), well, that makes even less sense to me.0 -
Adrian Bruce said: "If no relationship existed between two people, they should not be showing up together inside of a "Couple Relationship Box" in the family grouping graphics."
You and I can bat this back and forth forever, of course. :-)
I would just say that it makes perfect sense to have "No" (in some fashion) in a "Couple Relationship" box. My inner design engineer prefers to have the confirmation.
And slightly less tongue in cheek - in all honesty, I could work in the way that you recommend but I wonder how many people have the requisite understanding of the "Couple Relationship" box - somewhere else recently, I saw a suggestion that FS should actually describe what is needed in various circumstances.0 -
Jeff Wiseman said: Understood. The only reason I can't get too riled about it is that there is NO clear definition of what a Couple Relationship is. The opinions that have been given here over the last 2 years on this subject by FS employees and others (myself included) have been just that--opinions. That's ok, except that many of them are in opposition to each other. What does it mean when two names are inside of a Couple Relationship box together? NOBODY can answer that question because it has never been set up as a standard in the database.
Instead of just using a clear and consistent meaning of what a "Couple Relationship" is in all cases, everyone seems to want to sidestep clearly defining what it is, and then put a bunch of types, events, checkboxes, and description fields in to attempt to clarify the fact that there is no clear meaning assigned to the main Couple Relationship "thing" in the first place!
Just like a person record, a relationship record is uniquely defined by a set of events that can occur within the context of that record. So if you really insist on documenting all "one-night-stand" events as being part of the formal definition of a Couple Relationship, then fine. Do it. But you'll need to add "One-Night-Stand" as an event type that can be recorded against a Couple Relationship. Then you can justify always putting biological fathers and mothers into the same Couple Relationship boxes regardless of whether or not they only spent a couple of hours of their entire lives together and the Father wanted nothing to do with children of any sort.
But if a Couple Relationship is supposed to be more than a fly by might affair, if it is supposed to be representative of commitments between couples specifically involving support of family (which is what I *THOUGHT* was the intended meaning on the FSFT), then define the meaning clearly, document it, and assign events and facts that support and are consistent with that meaning. If a relationship is not consistent with that meaning, then don't graphically show a relationship where there is none (based on the standard meaning of Couple relationship)
All of the meanderings around the events, facts, terminology, and implementations of Couple Relationships has just led me to believe that even FS does not yet fully understand what it is supposed to be. This is an anchoring principle like person data itself. Until it's meaning is clearly locked down, these vagaries will continue to evolve.0 -
Adrian Bruce said: "there is NO clear definition of what a Couple Relationship is."
And there we totally agree. I know Joe has used the term "Spousal Relationship" but I'm not sure that's any better understood - indeed, I think that it might have a legal meaning somewhere, which might or might not be appropriate for what FS wants.
"led me to believe that even FS does not yet fully understand what it is supposed to be" - I suspect that you may be right. If we delete the actual couple relationship, as I suspect we are supposed to do in some people's view, then the User Interface actually gives us a button to press to recreate it, nudging us to believe that the deletion was wrong...0 -
Jeff Wiseman said: Yea sorta like in Ancestry whenever you do a search for someone. It hunts through all the thousands of personal trees and gives a single button process to clone it into your own tree (event though it is likely a 10 generation clone to start with and has no sources).0
-
joe martel said: It's been a while since I brought this up. There are a number of dimensions that complicate the discussion: what is what object, compromise in UI to simply illustrate multiple attributes, evolution of a feature.
1. The objects: There are Persons, and Parent-child Relationships ( PCR)that have a child Person with 1 or 2 parent Persons, and the Spousal Relationship (SR) that represents two Persons who have a formal spousal Relationship almost always established by some formal or defined event.
2. In the Family members section (and in other views like Tree, changelog...) the bubble of two people is overloaded in the UI, as has been done in genealogy programs for a long time. That bubble can mean:
a. Two people who were formally espoused - married... through some formal or defined event and no children
b. One or two people who were parents of one or more children, but had no formal espousal
c. One or two people who were parents of one or more children, but had a formal espousal
a. has SR, and no PCR
b. has PCRs
c. has SR and PCRs
3. When FSFT was designed it followed the above rules and the SR meant there was some formal (government, religious, cultural) event or definition (say of time together) that made those two legally, or thru law, or religious joining/ceremony "married". I'm using that term loosely here. This marriage usually afforded some aspect of inheritance, property ownership..., rights.
User weren't satisfied with the limitation to the formal events (Marriage, Common law marriage, Divorce and annulment). After a number of year since release FS evolved and loosened the set of events of the spousal relationship to now include informal events like "lived together". Now users have requested many other non-formal aspects to "togetherness" like unwed, one-night-stand, acquaintance...
Additionally after request from users the aspect of NOT has been added to the Person further clouding the model of formal relationships. These include No couple relationship and No children.
So over time the model has become more complicated and cloudy. So "What does it mean when two names are inside of a Couple Relationship box together?" It depends, and by looking at 2a, 2b, 2c you have to look at this bubble and in the middle the existence of the "No Marriage event" says there is no spousal (now couple) relationship. If it doesn't say that then there is a couple relationship (formal or informal). The existence of the No Couple Relation ship and No children Person details Other info facts are independent and could be out of sync with what the couple bubble shows (looks like a good candidate for a data quality warning)
PCRs and no SR:
PCRs and SR:
0 -
Adrian Bruce said: Joe, thanks for that. And your text is, I feel, an excellent explanation. I am particularly intrigued by your suggestion that the meaning has drifted over time.
My only comment would be that there is an additional option - if you go into the Couple Relationship box as if to add an event, it is possible to delete the Relationship. The result is, IIRC, a couple who remain in the parental box for their children, but who have a prompt to add the relationship back in.0 -
Adrian Bruce said: So there would appear to be 2 meanings to that box - it surrounds the parents of a child and it surrounds the partners in some sort of formal or informal relationship. No wonder I'm confused.0
-
Juli said: One of the many problems with the current setup/model is that what "no marriage events" _actually_ means is that no event has been entered (yet). When only baptisms have been indexed, you end up with a *lot* of couples with ten or twelve children but "no marriage events".0
-
Paul said: Thanks for adding these comments here, Joe.
Interestingly, your first screenshot happens to relate to one of my distant, Tungate relatives. I'm happy you have put this here because it does illustrate one of a number of problems in how to make clear (without another user searching for notes against the ID) what "No Marriage Events" might mean. In this case, my screenshot below explains the reason there is no input.
There obviously was a relationship, as they had at least five children together and are found in the same household in census records.
However, in many cases - especially as we go much further back, say before civil registration and the census - it is sometimes impossible to establish if there was any relationship between a couple.
In an example I have posted here previously (see below), I found a married man recorded as the father of a child by (an apparently) single woman. This was a 17th century event so little other evidence is to be found. I will probably never know whether, before of after his wife's death, he had any sort of relationship with the mother or whether indeed the child was just the result of a "one night stand".
In the latter example I have received mixed messages over the years as to how I should position the child in Family Tree. Firstly, it was to place him separately under the two parents. I feel experienced users would immediately understand this meant that there was no evidence of any relationship - but I do feel this could still confuse the less experienced. The other suggestion has been to add him beneath both parents, the result looking just like the Robert Tungate example (above), but obviously the situation being somewhat different. Although there is the Relationship Notes section (under Couple Relationship) and Notes (in Collaboration section) in which to provide details of ones findings / theories, there is nothing on the page(s) that gives a clear explanation, without having to examine the sections more deeply.
In short, I still do not have a definitive answer on how to show such events in Family Tree. As circumstances are likely to vary so much in different instances, perhaps it is for the best to leave the decision to individual users, based on their knowledge (or lack of it) about the parents concerned.
(Regarding the below, the mother's name is shown just at "Dow" in the parish register - i.e. no indication of her first name)
0 -
Adrian Bruce said: Yes. Which suggests to me that
1 No *events* yet entered though I have as yet unrecorded evidence of them;
2 No formal relationship *events* yet found, although strong evidence exists that there was a formal relationship;
3 Evidence strongly suggests that there was no formal relationship;
4 No idea yet.
... all look the same unless someone adds visible notes to the person / person pair.
As I said, Confused I am.
PS - packing all that into a User Interface - with further variations not mentioned - is not simple!0 -
Jeff Wiseman said:
So there would appear to be 2 meanings to that box
There are AT LEAST 2 meanings and most likely more, depending on how somebody decides to define it for their own purposes.
A single mother with a new child needs a place to live, and so moves into the house of her divorced 1st cousin. They wind up living there for many years, while both working to raise the child. Can you really call that a "Spousal" type relationship?
I don't think so. That is an example of why you CANNOT get any more granular in relationship type than a "Couple" type relationship--i.e., a sometimes "parenting" type Relationship that involves two people. A "marriage" type relationship can exist after several years of a "Living together" or "common law" relationship. Attempting to support multiple "types" of relationships between two people other than the current "Couple" relationship is fraught with problems in support and implementation.
That is one of the reasons that there were so many issues when the couple relationship was called a "Marriage" as it was first supported in FS. A "Marriage" (i.e., the noun) is only a subset of all potential Couple/Parenting type Relationships that might exist. Also, one Couple type Relationship can (and does) frequently morph into another over time.
So by defining the Couple Relationship and then just recording relationship specific EVENTS against it (such as a marriage event), you can avoid having to actually clearly define what it means. To a certain extent, you can leave it ambiguous and get away with it.
But you can let it morph wherever you like. By allowing a "one-night-stand" type of relationship EVENT, you expand what the meaning of a "Couple Relationship" is. Shoot, you could even add a "passed each other on the street and looked at each other" type event which would certainly loosen up the meaning of "Couple Relationship" even farther!
But you need to draw the line somewhere, and that somewhere is based on what you need to use the record for. If someone insisted on having the "passed on the street" type event added to the domain of the Couple Relationship vital, it is not necessary as it is not "vital" in uniquely identifying a person(s) involved in the relationship. There are other places more appropriate for such information such as stories or memories.
But all of this random morphing of meanings has led to what we have today. You can't explain what it means to anyone, because it doesn't have a distinct meaning. It means what anyone wants it to mean and can convince FS to support it.As I said, Confused I am.
Yea. Go figure...0
This discussion has been closed.