Why is "Marriage Notice" not an option for a Relationship Event ?
I frequently encounter events that are of the type "Marriage Notice" such as Banns or other similar public announcements prior to the actual marriage.
In some cases these occur in a geographically distinct location nowhere near the actual marriage, so by virtue of date and location they must exist in their own right as a separate event.
.. But when I try to correct an existing event, or create a new "Notice" type of event concerning a couple relationship, the only available options are: Annulment, Common Law Marriage, Divorce, Lived Together, Marriage.
Please tell me how to either : correct an existing event that is wrongly shown as marriage; or, create a marriage notice event such as Banns, or 'Marriage Bond'
Note:.. a Custom Event that only applies to one person does not fit the criterion for a 'Relationship' event.
Answers
-
Could you share a PID of a person whose couple relationship currently has one of these non-standard events attached?
0 -
I find that more recent projects at least do not treat these sources as if it related to the actual marriage event. In other words, if such a source is carried across via the source linker, it does not replace the existing, later-dated marriage ceremony event on the individual's Profile / Details page.
There have been requests made on this forum, going back many years, for the Couple Relationship section to be enhanced, so such associated events (relating to newspaper notices, banns or licences) can be added - or, indeed, that multiple events can be included (e.g., civil and church marriage) and the item one wishes to be displayed on the Details page to be chosen from a pick-list. However, the Couple Relationship area is one that Family Tree management seems to have decided not to make a priority for enhancement.
(Note that even the "Couple Relationship - Facts" sub-section only has the option of adding a fact relating to "No Children"!)
2 -
I don't think any of us can answer the "why" that you led off with, other than with "because FS hasn't ever really addressed the couple relationship section properly". It's a weirdly-segregated, nearly-invisible area, and the other parts of Family Tree do not play well with it. Source Linker, in particular, basically puts sources there randomly, with zero visibility or user control. It is also largely invisible during merges, although at least the transfer of events is under the user's control there.
Because the person detail page only shows the earliest-dated event that has been entered in this obscure section, and because it shows that event without displaying any of the contributor information, it is my opinion that in the current setup, marriage banns/announcements and similar pre-wedding events should not be entered as anything other than Notes on the relationship. (For example, I've entered the newspaper announcement of a couple's engagement as a Note on their relationship: https://www.familysearch.org/tree/person/details/LTZB-W83.) Yes, this renders the event effectively invisible, but that's true of nearly everything in the couple relationship section.
3 -
There are countless thousands of them, Alan! The main problem lies in whether they have been indexed as a "Marriage" (most of the earlier FamilySearch Notice / Banns / Licence records fall into this category) or indexed for what they actually are (as seems to be the current practice with FS indexing**). In the latter case, they get added as Custom Events, but in the former (as Julia comments) they actually get added as a Marriage (Couple Relationship) event, leading to them (if they have an earlier date than the ceremony) to automatically replace the true marriage data on the Details pages of the couple concerned.
As commented, FamilySearch engineers / managers have never seemed to be able to tackle the whole Marriage / related events issue - especially (in the example raised by @Re Searching) when it comes to adding such events to the couple, rather than to the two, individual profiles.
** I use the term "indexing", but many of the problems that arise (this included the at-last-overcome distinction FS made between baptisms / christenings) are / were created in the "post-indexing phase". That is, the team that moves the indexed records across to the to FamilySearch database seems to be inconsistent with categorisation, leading to the problems (at least researching dealing with England & Wales records) we have had to try to get around from at least 2012!
0 -
If there are "countless thousands," then it shouldn't be too hard to supply just one, as I requested.
Note that I am asking for the specific kind of event described in the OP: a custom event attached to a couple relationship (not to a person). I don't recall ever seeing that, and so a specific PID would be helpful.
0 -
Alan, I think you've misunderstood the OP: there are no custom events in the relationship section. That's kind of the whole point: you can only enter such events either incorrectly, as marriages, or on the individuals rather than the couple, as custom events.
Here's a random example where it's entered as a marriage, but the image shows a page headed "Index To Marriage License Applications".
2 -
Thanks for the clarification. The original post began "I frequently encounter events that are of the type 'Marriage Notice'" and then went on to use the term "event" to refer to an actual bit of data in Family Tree, and so I assumed that the first usage of "event" was referring to the same thing. But now it does seem clear that the first reference was simply to a happening in the person's life, which is quite different, of course, from the entity in Family Tree.
1 -
@Alan E. Brown Example as requested : This is a "Marriage Notice" event: https://www.familysearch.org/ark:/61903/1:1:NFHV-3TL
The original researcher added the reason: "LDS GS microfilm 1542225 shows the marriage of Hannah Walker and Mark Scholer in 11 May 1828 at York, England."
The actual marriage (to Mark Scholes) took place on 25th May 1828 in All Saints Church, Dewsbury. https://www.ancestry.co.uk/imageviewer/collections/2253/images/32355_249319-00086
The first event type is shown as Marriage Notice but it is actually attached to the couple as a Marriage.
Because it has the wrong date and is in the wrong place for the marriage, I wanted to edit it to choose Marriage Notice as shown in the original record, but that is not an available option in the list of event types for a couple relationship.
I hope this clarifies the position.
2 -
I've just had a look at those Records I have in my analysis store that have relationship information on them.
Look at all the things indexers appear to have put on them as event types:
Marriage 26898
marriage 2526
Marriage Notice 1065
intended-marriage 704
Marriage Registration 238
MAR 209
Marriage License 147
Divorce 59
Marriage Banns 33
MarrBond 14
intended marriage 11
intendedmarriage 8(There are also a couple of Death entries for reasons unknown.)
A lot of the 'banns'/'intended' type ones are obviously from church registers of one sort or another, presumably not much standardised.
0 -
So, if the list of available options was increased to :
Annulment
Civil Partnership
Divorce
Intended Marriage
Marriage
Marriage Banns
Marriage Bond
Marriage License
Marriage Notice
Marriage Registration
Common Law Marriage
Lived together
Never married
SeparationWould that cover all contingencies, and if so, how do we get it changed ?
0 -
I was told at one point (in relation to the Data Quality score initiative) that FS were looking to improve the relationship bits of the UI - it would be good to get an update on that. (@Ashlee C.)
At present even navigating the tagging of a source against a Marriage event is non-obvious.
To be honest I would say that having proper visibility of relationships on the Detail tab was even more important than adding to the list of couple relationship event types (the lack of consistency at indexing time wouldn't help with the latter, either).
3 -
@Re Searching asked
"So, if the list of available options was increased to …"
The intention is good but I fear the execution is impractical. I can add various terms from Scottish practices such as "proclaimed…" and "put their names forward for proclamation…". I'm not actually certain what, if any, the difference is between proclamations and banns. I'd guess that other administrations will also contribute further terms. Therefore, I would suggest that some sort of custom events for the relationship would be a better idea for the less frequent terms.
Yes, there needs to be a core but, as @MandyShaw1 suggests, there are a number of things that need to be assembled, not just specific events and attributes re spousal relationships.
3 -
Extending Adrian's thought: the options list for event type needs to be kept fairly short, simple, and broad. I'm not sure about best labels, but I could envision having a use for the following:
Announcement, banns, notice, or proclamation of intended marriage
Annulment, divorce, or separation
Cohabitation, civil partnership, or common law marriage
License or marriage bond
Marriage registration
Marriage/wedding (including church and civil)
Other/custom eventThat's still a bit longer than I'd like. Perhaps it could be shortened by one by combining announcements and licenses etc. into a single "pre-wedding" event type, which could then be set to default to "not shown unless no other event is entered". But regardless of the exact specifics, all of the events should have a freeform description box or line, so that we could write in things like "newspaper announcement of engagement" or "marriage license application".
3 -
@MandyShaw1, @Adrian Bruce1, @Julia Szent-Györgyi
Good points and contribution. I imagine we could spend at while debating the intricacies of things that indicate intent, prove, prove the end of, and indicate did not exist.
Would it be too much to just get Marriage Notice added, or at least something that allows an event that is not the actual marriage to be added without being cajoled into choosing Marriage as the event type,
…. and if that can be done, then why not a few more to help distinguish the various types ?
I don't think that this is a big ask, and I'm fairly certain that it's not a huge amount of effort to add a few more names to an existing list of options. Unless perhaps it's "based on old technology"
0 -
The apparent difficulty of making any change at all to the UI at present makes me think that you may be right about the technology angle. Not a comforting thought. On the other hand this particular issue is just about reference data which is presumably picked up from somewhere external to the application anyway.
0 -
It's a cascade: if you add a pre-wedding event type, what do you do with the sorting and display? Do you still display the earliest-dated event, just with a different label, depending? Is there room for a different label in all of the interface languages? Or, do you revise the sorting in some fashion? Maybe display the earliest event with type=marriage, if there is one, or the earliest event of other types according to some ranking/ordering of the types? Or can users be allowed to choose both the preferred event and its label?
Nothing is ever as simple as it seems. :-)
2 -
But @Julia Szent-Györgyi I can't see why the Couple Relationship box needs to be limited to showing a single event in the first place. (Is this really less important than yards of Residence events, or my grandfather's 15 Immigration events, one for every business trip he made to the US? I'm especially thinking of where there is a Marriage followed by a Divorce.)
0 -
@MandyShaw1 - my initial reaction was that the issue is not so much the contents of the Couple Relationship box as all the other places where the marriage data is squashed in - such as in the (landscape) tree diagrams.
Having said that… I just tested something in Beta, giving my GG-GPs a sort-of-marriage event dated earlier than their true marriage. The landscape tree didn't change - it stayed fixed on the genuine marriage. But the contents of the Couple Relationship box did alter, replacing the genuine marriage with the earlier sort-of-marriage event. Therefore your comment about any limitation on the size of that specific box seems fair…
I've no idea whether that behaviour of the landscape tree is old or recent.
I've also no idea if there are other places where marriage dates appear.
2 -
@Adrian Bruce1's comment got me to brave Edge's high-handedness to try to answer the new question it raised: how the heck is the landscape pedigree view in Beta choosing what event to display, if it's not just going chronologically, the way the Family Members section does?
Based on my testing, it appears to me that the landscape pedigree chart in Beta only shows specifically "Marriage" events. If there's more than one of those, it shows the one with the earliest date. If two marriages have the same date, it shows the one that was originally entered earlier. If there are one or more events entered for a couple, but none of them has type = Marriage, then the chart shows a blank between the couple's names.
@MandyShaw1, the Couple Relationship box (i.e., the popup) isn't limited to a single event. It lists them all, chronologically. However, the mini-landscape-chart that is the Family Members section really doesn't have room for such a list, in my opinion. It would put too much separation either between the names of the couple, or between the names of the parents and their offspring (depending on whether couple events remained between the couple's names, as now, or went back to being after the two names, as in previous iterations of the person page). If anyone has any ideas on how to change that, I would welcome them; I haven't had any success in coming up with anything.
3 -
I got things backwards in last night's post: the current display has the marriage below the couple, between them and their offspring. It's the old display that had it between the couple's names.
0 -
This has been suggested in "Suggest an Idea",
0 -
@davidleelambert Nice find. It seems clear that nothing has been done to address that suggestion in the last 3 years. Nevertheless, I have upvoted it by 25% by adding 1 vote. I wonder wether that will make any difference.
0 -
The problem with the suggestion that David found is that the poster was mistaken about what actually shows in the Family Members section. As things currently stand, adding a pre-wedding event type would result in display of that pre-wedding event instead of the wedding.
Adrian's discovery of the completely-different behavior of the Beta landscape pedigree suggests one avenue that FS could follow to allow addition of such an event type without messing up the display: only display events of type = Marriage. This solution's use in Beta suggests that it's the direction the programmers are thinking in, for when they finally get around to fixing the couple relationship functionality and display. I'm not sure I like it much: it may be OK for summary views such as the pedigree charts, but on a person's Details page, I want to see the details. All of them. As I said, I just haven't come up with any ideas for how.
4 -
Just to clarify a point on the issue of marriage related events being added to the Couple Relationship area during the source linking process. There is currently no problem with any "overwriting" of existing, correct data if the record has been indexed as a Marriage Notice / Marriage Banns / Licence, etc. The main problem (hopefully not one that applies to more recently indexed batches) lies where these records have (in the past) been indexed as actual Marriages. I have found many examples of a Marriage Licence record appearing on the Details page due (as discussed previously) to it having an earlier date than that of the actual ceremony, but being indexed as though it applied to the marriage itself. As I say, hopefully FamilySearch are now classifying these records correctly, so that related events are not treated in the same way as the one for the main ceremony.
On the issue of whether these (related) events end up as Custom Events and / or find their way into the Couple Relationship area, I believe there is a good case for expanding the latter to include them - but as long as they are clearly separated from the main event (i.e., having their own sub-section). But - in case this section of the profile already does include the correct facts about the marriage - I have always argued that further Marriage data should not be allowed to be carried across when linking a source (at least not without a warning that data has already been added). That would encourage (as should always be the case, of course) the user to return to the Profile page / Couple Relationship section to compare the detail in the newly added source with the existing input for the event.
Having at last agreed that a baptism event is the same as a christening one, I would hope that "FamilySearch" will now work to ensure that the Marriage and marriage-related events are definitely recognised as being different!
4 -
I have noticed that recently the source linker refuses to attach a Marriage Notice event in a source. I managed to work out that an event defined as a Marriage Notice event cannot be attached by the Source Linker if there is an existing marriage event. My guess is that Source Linker is trying to convert the "Marriage Notice" to a Marriage event, and when it finds that one already exists, SL can't overwrite it or create another for the same couple. Very strange because we have already found that it could create mutiple marriage events in the past.
0 -
I don't think the problem is specifically connected to the Marriage Notice factor. I will try to test later on other examples, but believe this probably relates to Marriage events, too. You probably experienced the "Something went wrong…" message when trying to directly attach the source to the spouse - with which action there was no problem in the past. The "workaround" is to change the spouse to the focus person, but there the problem lies: the marriage event is attached to the spouse (not the focus person), so the event is then transferred to the other partner, which seems why it can't be carried across. I'm sure this has been reported within the New Source Linker group as a bug.
Again, I will try to replicate with a "Marriage" (rather than "Marriage Notice") event later. Might be a bit difficult to find an example though, as if there is already marriage data in the Couple Relationship area with the exact same detail, it can't be carried across. So, I'm relying on finding a second event that actually relates to a licence or banns, but has been indexed as if for the actual marriage event! There used to be plenty of these, but FamilySearch processes have improved over the last few years and notices, banns and licence events do now appear to be appearing as such, instead of with the incorrect categorisation (Marriage) they used to carry.
0 -
@Paul W If I can remember my sequence correctly, the issue occurred while I had the person page open for the bride, and I used the Source Linker to attach the Marriage Notice event that had been presented via Research Help. After attaching the bride and her father, I returned to the bride's person page and added the correct Marriage date and the proper place name. When I went back to source linker and renewed the page I then attempted attach the groom and to copy across the marriage notice event, the animation performed as expected, but then, as you say, the "Something went wrong…" message appeared. Changing the focal person did not allow the desired operation to be completed.
I tried changing the marriage date on the bride's page - no effect
I tried changing the marriage date and place on the bride's page - no effect
I tried adding an arbitrary spouse and changing the marriage date and place on the bride's page - no effect
It seems that Source Linker has decided that Marriage Notice is not an allowed event.
If you want to look for test cases, I would suggest Cheshire, England. There seem to be a lot of Marriage Notices in that county.
0 -
I apologise for not testing my idea before making my comments (above).
I did manage to immediately find an example where a Marriage Bonds and Allegations event (although correctly titled) had been categorised as a Marriage. As the source related to the licence, it carried a date three days earlier than the existing input for the marriage ceremony. I detached the source from both individuals, but was able to reattach it to both without problem (i.e., no need to change focus person and the event was carried across as soon as I attached the source to the second party / spouse).
Indeed, this does prove your point about the problem specifically applying to Marriage Notice sources, so apologies again for "doubting" your point!
Incidentally, as this (my example) is still categorised as a "Marriage", it has now replaced the accurate detail (of the actual marriage) on the Details pages of the couple. I will now have to go to the Couple Relationship area and delete the 7 November 1801 "marriage" at York, in order that the correct 12 November 1801 Eston, Yorkshire detail (relating to the ceremony) is the item displayed on the main profile (Details) pages! The fact we can't record multiple events events within the Couple Relationship area is another issue, of course: but particularly annoying where there have genuinely been two "valid" events: usually the example being a civil and a religious ceremony. (Well, both can be recorded, but the one with the earlier date will always appear on the main page(s), whether we prefer that or not.)
It might be worth posting this (Marriage Notice) issue in the New Source Linker group, or re-emphasising the problem if there is an existing post on the problem.
1 -
@Paul W Thanks for the detailed comment, nice work, it reminds me of some of Gordon Collett's,
I had anothertry at resolving the issue after deleting all the Marriage data from the couple, and no matter what, I could not get the Marriage Notice to attach using the source linker. I think you're right that it's probably the remit of the New Source Linker group, and I will post a comment there, but in view of the fact that that's a 'closed' group, I think this thread will be more easily discovered by ordinary users, so I'll keep this going too.
1
