Options for marriage data

LegacyUser

Cathy Anderegg said: I don't think you need to worry about ordinance information going with the correct person in FT. My understanding is that the temple data is kept in another place, and if you think there is a problem with the data on FT, you request a review from the other place.

LegacyUser

Venitar said: You hit the nail smack on the head! If the corrections we make/made in nFS are not reflected in FT, I suppose we'll have to ignore some situations until we get new tools.

LegacyUser

Jade said: Venitar, I think that is a good way to put it. A great many users have run into situations in n.FS where further combining of actual duplicates is not possible (and so often complicated by duplicated spouses, children and parents), and of course isolated persons (with no identifying information other than attachment to, say, wrong parents) cannot be deleted from that system either.

LegacyUser

Venitar said: I, too, vote for that last paragraph, Jade and Cathy. I am not a novice with either a computer or with family history. Obviously, I am a novice with the logic of this system.

For Seth, I first looked at the drop down menu of child/parent relationships, hoping that one might be "no relationship." Obviously it's not there. If it were, and if clicking it would delete the relationship, it would make things easier for the user.

This system seems to assume that all families are pretty much "normal" so they make the drop down lists options that would apply in normal relationships. In reality, we all know that "normal" is not necessarily normal. To add to that, screwy relationships are rampant in nFS for a variety of reasons, both child/parent and couples. If we users are to clean them up in FT, the options must be obvious and intuitive.

PS: My name is actually Venita - no "r." Venitar is my user name. 8o)

LegacyUser

Jade said: Venita, you have again touched on a problem with the FS-FT system.

I want it to treat each parent of a child separately, but there is some strong internal Leave-It-To-Beaver logic at work, presenting the user with the dilemma you described arriving at with Adam/Eve, Adam/Jane and Seth. I think this will confuse many, the more so because the way to substitute a correct parent for an incorrect parent is so hidden in the page that shows the child's relationship with a **couple**. And the "couple" relationships are burdened with a lot of cultural and terminological baggage.

I also want the system to treat relationship between parents quite separately from relationship with children, but still be able to show them both as parents when identity of each is known.

There are other terminology issues, such as the way changes are described in the "changes" box. Such as for a male it says "Father Added" when the male is added ***as*** a father. It should say "added ~as~ father" (but I want it to say "Added as Parent"). It should say "Father Added" if the person's own father is linked to this male person.

LegacyUser

Venitar said: If you'll move over just a tad, I'll step up on the soapbox with you. What we are discussing here will not be an unusual situation in FT. During the years I have worked in nFS (starting with the second beta version) with my own data and helped others with theirs, I have learned that finding a family line with correct relationships is unusual. It is more common to find relationship problems than to not.

LegacyUser

Jade said: Judging by comments on this board and in a few blogs in the past couple of months, we need rather a large soapbox just for program issues. For database error issues possibly thousands of actual evidentiary-records searchers would echo your comment.

My own impression is that n.FS as raw database-compilation is a morass, that as modified by users has not been improved as reflected in FS-Family Tree.

LegacyUser

Cathy Anderegg said: Remember, a merge function is coming, dare I say, soon? I personally have not waited for the merge function, and have figured out how to delete relationships of duplicate children, spouses and parents. I am assuming when the merge function is available, those relationships I sent spinning off into FT cyberspace somewhere, will pop up again and then I can take the best data, assuming a duplicate has data better than the other, and then the merge takes place. See the white paper describing this at familysearch.org/treetraining. There will not then be 2 records for one person. There will also be a Not a Match option that prevents, or at least warns, folks not to try to merge 2 records. We might just have to wait and see how this works and if we like it.

LegacyUser

Cathy Anderegg said: Venitar, go look at in Get Satisfaction, new idea: deleting relationships in FT. That discussion has some clear steps and good questions asked and smartly answered. Check it out.

LegacyUser

Ron Tanner said: Deleting the child in any case would simply remove that parent-child relationship. If one father, one mother, one child constitutes the family then yes, deleting the child removes the parent-child relationship as the relationship has no meaning without the child.

If there are multiple children with the same parents, you actually have several parent-child relationships; one for each child. So removing a child would not remove the entire set of children with the same parents.

LegacyUser

Venitar said: Ron,

You said, "...the relationship has no meaning without the child." There are many couples who never have children, as you know. Removing the child from a couple relationship does not and should not dissolve the couple relationship. If the "couple" was not a couple, that relationship should be deleted after the child(ren) relationship is deleted.

For the cases where the couple lived together as husband and wife but produced no children, it would be well to add another option to the drop-down for "Add a child" that would say "No children." This would not apply when the couple relationship was created only by a sealing, and there was no earthly relationship.

LegacyUser

joe martel said: Ron means, if there is no spousal/couple relationship and there are no children, then there is no family. A family view is created when 1. there is a couple/spousal realtionship, there is a child/children to a father and mother, there is a child to a single parent.

LegacyUser

joe martel said: Merge will help you do a number of actions during one merge. But today you can correct relationship by deleting relationship, or changing the persons referenced in those relationships. But you can not Delete a person yet.

LegacyUser

Venitar said: Sorry! My misunderstanding.

LegacyUser

Jade said: I will iterate here that the present display suggests a "relationship" regardless whether father was slave-owner and mother was owned slave, or whatever the situation, whether known or unknown. Yet there is no way to create a label that clarifies, only the implication that a marriage date/place has not been entered ("No Marriage Events").

Venita's "Not Married" label option suggestion would go a baby step toward tree accuracy.

LegacyUser

Venitar said: Pardon me for whining, and please pass the cheese.

I am annoyed that the goal of the church is to create a genealogy record for everybody that will in the end be "worthy of all acceptation," yet they ignore many of the basic rules of keeping such records. Two of the thorns that are in my side are the lack of clarity of relationships between couples, and the incompleteness of FS/FT sources. It would be very simple to add other options for couple relationships. There are several options for parent/child relationships; why not more for couples? The possibles are described above in other posts.

As for sources - that's another topic.

LegacyUser

Venitar said: How about this? How about putting the "Never Married" option above the couple box, next to "Add Spouse." It would be more obvious there, and easily clicked.

Just a sudden thought while working with distant cousin, Lydia, who died at the age of 69 having never married.

LegacyUser

Venitar said: And while you're at it, at the bottom of the couple box, why not add a "no children" button to be chosen when a couple married but produced not children.

Thanks for listening!

LegacyUser

Janice Byington said: Great idea Venitar.... Allowing the child to be deleted from the relationship with each parent individually. That would truly save time.

I love, love, love FamilyTree. Such an improvement.

LegacyUser

Janeen Lambert said: Right now, if there are no marriage events, the couple box says "No couple relationship". But if they had one or more children, they obviously had a relationship! Just not one that generated a written record. Maybe I am being too picky about the wording, but "No couple relationship" just looks weird when there is a list of children.

Another thing is that if the couple was not married and we could put "Not married" as a choice in the couple box, other people would know to not go looking for a marriage record because it does not exist.

LegacyUser

Janeen Lambert said: Another reason to indicate that a person never married would be to keep someone else from combining them with another person who did marry or putting them into a couple relationship because they had the same name as the person who was in the relationship. I have dealt with a lot of situations like this.

LegacyUser

Janeen Lambert said: I like this idea. It would keep people from adding children to the family when there weren't any.

LegacyUser

Venitar said: It's been more than three years since this discussion began, and it's time to re-visit it. With all the changes in format, etc., why not add the three options discussed above.

To review:

How about putting the "Never Married" option above the couple box, next to "Add Spouse." It would be more obvious there, and easily clicked. That would indicate that the individual had reached marriageable age, but never married.

In the options list for a couple (i.e. married, divorced, annulled, etc.) please add "Unmarried" or "Not married" indicating that they produced at least one child out of wedlock. This is a very common situation, as you know.

Where the list of children begins, please add an option of "No children."

Each of these options would require a brief definition, and they would be very helpful in identifying an individual's situation.

Thanks!

LegacyUser

Geneel Scott said: I think that 0 = s no children. Nothing will keep people from adding children that don't belong to the family except good research.

LegacyUser

joe martel said: Thanks.
There are two future enhancements:
1. Person "Never Married" declaration
2. These 2 Person "Not Married Together"
Not sure when these will be implemented.

LegacyUser

Geneel Scott said: I think that this is insufficient data for unmarried mothers who may have married later, or chose not to marry,
There are so many "Married" "unmarried" "single" Maybe there could be something that indicated someplace where a full explanation could be made.
For example: adding a link next to "add a spouse" that links to notes below
possibly saying "marriage notes" It would be more neutral and would allow you to explain why you think this person has no spouse.

LegacyUser

Venitar said: It is not unusual for a child to be born out of wedlock, and to later have the parents each marry someone else. Designating the first relationship as being "Not married" still allows for a marriage relationship to be added for each parent's marriage to someone else. Explanation in the notes is always helpful!

LegacyUser

Venitar said: "0" = "no children have been added." A statement that no children were born to this couple, i.e. "No children" explains why no children have been added.

LegacyUser

Janice Byington said: I understood that the current "Common Law" meant the same as "Not Married Together"?

LegacyUser

Janice Byington said: "no children born to this couple" would be very helpful. I've had so many children added to a step-parent (a marriage of either biological parent who continues to raise the children) because someone is going only by censuses, etc. While those who have personal knowledge of the family know otherwise.